Cristiano Sanchez

Documentações do Glassfish V2 pode ser encontrada online em:

http://docs.sun.com/app/docs/coll/1343.6

Para o pessoal do curso que pediu os passos até gerar um app-client-jar, segue links da documentação (apesar da doc ser da GFV3, serve pra V2):

http://docs.sun.com/app/docs/doc/820-7701/package-appclient-1m?a=view

http://docs.sun.com/app/docs/doc/820-7701/appclient-1m?a=view

Mas o básico é:

Gerar o arquivo appclient.jar via comando package-client. Este comando se encontra no diretório $GLASSFISH_HOME/bin e irá criar um arquivo no próprio diretório.

Este arquivo deverá ser enviado para o cliente e pode ser descompactado junto ao JAR de sua aplicação. Contém, entre outros, os seguintes diretórios:

• /bin o comando appclient será encontrado aqui e deve ser executado para iniciar o cliente.
• /lib bibliotecas diversas necessárias para ativar os serviços do appserver no cliente
• /conf arquivos de configuração. Indique o caminho e porta do servidor em sun-acc.xml e outros caminhos em asenv.conf.

Agora basta executar o seu client:

bin/appclient -client MinhaApp.jar

E assim temos mais um cliente feliz e contente diante a beleza do IIOP!

O IntelliJ IDEA 8, no Mac OSX, cria o diretório $home/Library/Caches/IntelliJIDEA8x/ e neste diretório se encontrar o diretório tomcat (base) além de tomcat/work.

Você também encontrará outros diretórios com configurações utilizadas pelo IDEA.

Minha biblioteca particular é um pouco maior já que todo mês chega um novo pacote, geralmente da Amazon, eventualmente da Livraria Cultura. Este livros, juntamente com tudo o que se pode encontrar disponível na web, de tutoriais a blogs, formam minha base de aprendizado constante, além dos amigos programadores e eventos.

Vou relacionar aqui algumas das leitura (técnicas) interessantes que tive. Quase todo material que leio é inglês. Livros técnicos traduzidos são uma tijolada na cabeça. Quase todos contém erros graves de tradução. O maior problema sñao as traduções de termons técnicos que ouvimos todo dia. Esbarrar com uma tradução como “arranjos” para arrays, ou “classes internas” para inner classes torna a leitura desagradável. O cérebro tem que parar de seguir o conteúdo do livro para fazer o de-para dos termos. Além disso, dado que um livro técnico muitas vezes fica desatualizado em pouquíssimo tempo, esperar por uma tradução pode ser uma péssima idéia.

Estou relacionando os clássicos. Livros sobre framework não contam pois a lista não teria fim (EJB, Spring, Hibernate, JQuery, Struts, WebWork, JSF etc).

• Programming Ruby de Dave Thomas sem dúvida é “o” livro pra aprender Ruby.
• Agile Web Development with Rails de Dave Thomas e David Heinemeier. Ótimo início para conhecer e programar usando o framework Rails. Sugiro que pratique um pouco de Ruby antes o que tornará a leitura e programação fácil, fácil.
• The Mythical Man-Month de Frederick Brooks. Conta a estória do desenvolvimento do OS360 da IBM e como foi gerenciar o projeto. Muito interessante, um clássico.
• Refactoring de Martin Fowler. Apresenta técnicas de refactoring para deixar seu código sempre atualizado, limpo, daqueles que dá orgulho de mostrar pra mãe.
• C++ Effective Object-Oriented Software Construction de Kayshav Dattatri. Ah, bons tempos. Eu realmente gosto de C++ já que foi uma das primeiras que trabalhei e na época este livro ajudou muito. Aconselho a todos que estão iniciando sua carreira em C++.
• Code Complete de Steve McConnell. Leitura pesada. Aborda detalhes na codificação que vão desde a melhor forma de criar seus if/elses até como realizar testes unitários e documentar seu sistema.
• Design Patterns de Erich Gamma e amigos (GoF). Sem dúvida um dos que constam na lista dos de leitura obrigatória. Os exemplos são em C++/Smalltalk e se preferir outra alternativa sugiro o livro Head First Design Patterns, da Katy Sierra e Bert Bates. Fácil, didático e divertido (sim, livros de TI podem ser divertidos, seu pessimista!)
• Domain Driven Design de Eric Evans. Aborda a análise e o desenvolvimento do projeto OO através dos objetos de domínio além de patterns e boas práticas. Excelente.
• Effective Java de Joshua Bloch. Acha que sabe programar em Java? Leia este livro e depois conversamos.
• Extreme Programming Explained de Kent Beck. Fazer propaganda de metodologias Ágeis em pleno 2009 é como falar que a internet é uma “rede mundial de computadores”. Escrito pelo próprio criador da metodologia este material é o clássico sobre o assunto.
• Agile Project Management With Scrum de Ken Schwaber. Outro livro da série obrigatório, Scrum traz práticas para o desenvolvimento e gerenciamenteo de projetos (qualquer projeto).
• Joel On Software de Joel Spolsky. Coletânea dos melhores textos de um dos blogs pioneiros e mais lidos de TI desde 2000. Se não quiser ler o livro, acompanhe o blog.
• Só Por Prazer - Linux de Linus Torvalds. Há muito tempo esbarrei com este livro mas não tive curiosidade de lê-lo até 2006 quando um amigo voltou a sugerí-lo. Este livro conta a estória da criação do SO; um livro de leitura fácil e divertida para nós nerds.
• The Pragmatic Programmer de Andrew Hunt e David Thomas. Este livro é obrigatório para qualquer desenvolvedor. Espero que leiam este livro já nos primeiros contatos com progamação pois terão dicas que vão desde código, organização, metorologias, testes etc.
• Thinking in Java de Bruce Eckel, considero um dos melhores livros sobre Fundamentos Java e OO. Além de didático, o livro pode ser encontrado gratuitamente no site do autor.

Hoje participei de uma entrevista “evil”. Aquela onde você perde tempo, se estressa e ninguém ganha nada com isso. Entrevista mal elaborada, mal feita, mal aplicada.

Tudo começou quando cheguei até a consultoria. Procuro filtrar antes onde faço meu CV correr para não cair nas empresas fundo-de-quintal-zona-leste-com-pagode. Mas enfim, nem sempre o filtro funciona. Um site bonitinho engana muita gente!

Ao chegar, primeira decepção: um formulário em papel questinando dados pessoais (que estão no meu CV), últimos empregos (que estão no meu CV), idiomas (no CV), skill (no CV) e… vocês entenderam! Considerando que, apesar de eu ser uma pessoa muito calma, em São Paulo, por causa do trânsito, você sempre chega estressado nos lugares, receber um formulário destes é o começo de uma longa lista de erros. Mas já que eu estava por lá e já tinha pago R$10,00 num estacionamento só pela primeira hora, vamos adiante.

Desta vez a pessoa que me recebeu foi até que muito simpática. Não vou mencionar outros momentos “evil” como nas muitas vezes em que fiquei esperando quase uma hora para ser “entrevistado”, uma outra vez que a “menina do RH” me pediu explicações sobre a diferença entre “servidor de aplicação e Java” pois ela achava que era tudo a mesma coisa e ainda outra onde a entrevista foi “coletiva” com pelo menos 12 programadores na mesma sala de reunião com direito a falar 5 minutos; a empresa precisava agilizar o processo de contratação.

Queridas meninas que trabalham no RH, façam testes bizarros como continuar o desenho inacabado, ligar os pontos, grifar adjetivos ou questione sobre “qual nosso maior defeito”. Mas por favor, coloque alguém da área técnica cara-a-cara, frente-a-frente para nos entrevistar.

E é por isto que o post veio ao blog. Entrevistas que não sabem avaliar técnicamente o candidato, especificamente, pedidos pra que você codifique em papel.

Programação SIM; Perder tempo NÃO!

Vou classificar as entrevistas de duas formas daqui pra frente: as que respeitam e as que não respeitam os programadores.

Respeito com os programadores é pedir para que codifiquem um programa e entreguem uma solução válida, compilada e executável como aparentemente é o que encontramos por aí no trabalho. Ou alguém anda commitando código em papel, talvez num arquivo morto pixado em vermelho CVS? E código em planilha Excel? E no Word? Alguém aí é privado de consultar APIs enquanto trabalha? Livros? Internet? Algum chefe como lema “ou programa sem consultar nada ou furo seu olho esquerdo”?

Nas últimas 5 entrevistas que realizei ao longo deste ano somente 2 me pediram pra codificar. O que é lamentável, já que estava fazendo testes para programar! Porém os dois testes de programação foram feitos de forma errada: um em papel, outro em Excel.

Programar em papel já é um velho conhecido de todos os que passaram por testes em consultorias de bodyshop que não tem o mínimo interesse no profissional a não ser limar os que realmente não tem capacidade nem de escrever public static void main... . Programar em papel é tão “evil” quanto tomar chá de boldo do Chile. Simplesmente porquê programação não é a arte de decorar… programação é a arte do saber fazer (e fazer bonito).

Como mostram exames de Raio-X em quadros de artistas famosos, quando pintam um quadro, começam com um esboço a lápis. Um fundo branco. Testes com alguma côr, testes com outra, e desta forma, constroem pouco a pouco uma peça de arte perfeita. Tudo leva dias, meses, anos. A obra está pronta na cabeça do pintor mas não na tela.

Quando me pedem pra programar algum código, minha cabeça começa a pensar rápido e a juntar peças e conhecimentos que adquiri no passado e novas idéias até formar a solução para o problema proposto. Porém na prática a construção é bem diferente.
Apesar de digitar código frenéticamente toda a construção é refeita a todo momento até que o código vire uma obra de arte. Código grande? Extract Method. Construção confusa? Simplifique. Classe comprida? Componentes. Esqueceu um método? Consulte a API. Existe uma classe pronta pra isto? API. Que biblioteca faria isso? Google! Qual o melhor design para este problema? Conversa com amigos durante o almoço. Chegando em casa e ainda querendo aprimorar? Livros, blogs, conversa com amigos nerds no barzinho mais próximo!

Bem, voltando as entrevistas, a gota d’agua foi pedirem novamente pra codificar em papel (ok, era pra codificar num WordPad e depois colar tudo numa célula no Excel (oque dá na mesma)). Além disto, questões mal formuladas e respostas ambíguas as quais você não tem o direito de reclamar e questionar e discutir porquê está sozinho em uma sala minúscula e mesmo porquê a menina simpática que lhe entregou o teste é do RH e não sabe a diferença entre um HD e um cooler.

O que me deixa muito irritado é saber que estes testes são criados por programadores e serão avaliados por programadores. Então, você está sendo avaliado por um programador ruim! Isto é triste. E o resultado final é um cara ruim dando uma nota pra um teste mal feito dizendo que você não tem competência para programar um sistema que usa Struts 1.x, DAO e zilhões de código Java no JSP. Lamentável.

Como se faz uma entrevista

Eu não sou expert em contratação. Não estudei psicologia e quase tudo que li em “O Corpo Fala” eu já esqueci. Mas tem coisas que são óbvias na avaliação de alguém que irá programar.

Primeiramente, o curriculum diz muita coisa sim. Candidatos que mencionam algo como “Conhecimento avançado em Word, Excel e HTML” ou “Curso Data Byte” estão automaticamente eliminados a não ser para a vaga de trocador de galão de 20L de água. Particularmente eu olho apenas 4 coisas num CV: onde trabalhou, idiomas, palavras chaves e a organização do texto. Palavras chaves mudam de tempos em tempos. Nesta época por exemplo, 2009, palavras chaves são por exemplo Ruby, Rails, XP, Scrum, Python, Scala, Haskel, meu usuário no twitter é x, o endereço do meu blog é y. Mostram interesse pela área e um perfil atualizado, que pode ser conferido numa entrevista posterior. Onde estudaram e se estudaram em uma faculdade realmente não me diz nada. Certificações? Se foi por motivação pessoal, aplausos. Se foi esperando uma melhor colocação, perdeu tempo!

Feito o primeiro corte, existem pelo menos 3 coisas a avaliar num candidato: avalie seu código, avalie sua redação e avalie a pessoa.

Código

Mas é claro que um candidato a programador deverá programar. Show me the code! Ofereça condições de avaliar o que ele fará quando estiver trabalhando. Caso o código seja feito durante a entrevista isto inclui deixá-lo a vontade, servir um café, ter acesso a internet para consulta, uma estante cheia de livros atrás, um editor de texto e um compilador. No final, o código tem que executar, óbvio. E SE executar, aí vamos ver a estética, a lógica, a criatividade, a simplicidade, enfim, se o código é ou não de fazer orgulho pra mãe. Sente com o programador e discuta o código. Questione os pontos que podem melhorar e veja se ele dá outras soluções.

Numa das melhores entrevistas que já fiz a empresa me enviou algumas propostas de código por email. Eu poderia escolher qualquer uma, codificar em casa, enviar por email e durante uma entrevista como pessoal técnico discutir meu código! Simples e brilhante!

Redação

É incrível a quantidade de pessoas que NAUM sabem mais escrever. Obrigado Orkut e escolas públicas. Me critiquem se for apenas preconceito mas todos bons programadores que eu conheço sabem escrever corretamente. Como é possível contratar alguém que sabe escrever um código de forma simples e legível e não sabe escrever um português com a mesma elegância? Faça o candidato escrever. Sugira por exemplo para que ele escreva uma crítica sobre o último livro técnico que leu. Aí você já matou dois coelhos!

Pessoa

Por último avalie a pessoa. Como eu já disse, não sou mestre em avaliar questões subjetivas como, candidato desenhou a linha pra esquerda? É psicopata. Linha pra direita? Matou a mãe! O que eu converso com o programador é o que eu converso com meus amigos programadores. Converso sobre tecnologia específica sim, seja Java ou C# mas converso a maior parte do tempo sobre livros, blogs, linguagens de programação, frameworks, eventos, open-source, web, twitter, etc. Eu converso para saber se a pessoa gosta da área, se ela está atualizada e se vai saber o que procurar e o que fazer no dia-a-dia.

Concluíndo

Entrevistar é uma arte e fazer uma entrevista efetiva é trabalhoso. Custa muito caro pra empresa contratar alguém que não retorne todo o tempo e investimento. Por mais criterioso que seja o processo eu não conheço nenhuma empresa que acerte 100%. Só o trabalho lado-a-lado mostra como uma pessoa reage a pressão, a prazos, a demanda por inovação, a criativadade necessária para as soluções mais complexas. Contudo, fazer da entrevista um processo agradável e avaliar com critérios é o começo para encontrar bons profissionais e criar desde o início uma imagem boa da empresa e das pessoas.

Mês passado iniciei um projeto usando JSF, com a implementação ICEFaces. Após 1 ano sem mexer com JSF resolvi apostar no framework, não por capricho, como nenhuma escolha deve ser, mas pelas seguintes razões:

• O projeto é composto por 80% de operações CRUD (create, read, update e delete). Já temos o modelo de domínio pronto e alguns testes via IDE (netbeans e eclipse) mostraram que a criação de telas e operações seriam automatizadas;
• Outro ponto chave do projeto é a criação de um painel com a responsabilidade de apresentar de forma gráfica (estrutura de organograma) os dados cadastrados. Aparentemente a criação de um componente JSF é bastante atraente;
• A equipe é pequena, composta de 3 pessoas, e com níveis diferentes de conhecimento. Mas o fato de estarem juntas no mesmo projeto e ambiente facilitará a comunicação e transferência de conhecimento. A aposta deveria ser em um framework produtivo e de fácil absorção. Minha impressão sobre Struts2 e SpringMVC, apesar do modelo Action/Command já bastante difundido, é de que trazem uma curva de aprendizado maior que JSF;
• Existe muito material sobre JSF disponível em português, inglês; livros, blogs, apresentações e exemplos não seriam um problema;
• Alguns projetos em que a equipe é responsável por suporte e manutenção utilizam JSF;
• Escalabilidade não será um problema já que o projeto será utilizado por pouco mais de uma centena de usuários.

Resolvemos utilizar o Netbeans, apesar deste ainda utilizar a implementação Woodstock de JSF, a qual aparentemente será descontinuada dando lugar ao ICEFaces. Desta forma, os CRUDs gerados necessitaram de migração de Woodstock para ICEFaces, nada muito complicado, mas trabalhoso. Este não foi o único problema. Vários CRUDs mais complexos, onde existiam relacionamentos entre domínios, foram gerados com erro. Muita correção manual foi necessária e a tão desejada, tranquila e rápida geração de CRUDs baseada em domínio não aconteceu. Sem o auxílio de um IDE para auxiliar a programação JSF o framework perde muito de sua magia. As criação de views, managed beans, xml, etc traz lentidão ao trabalho.

Mesmo com problemas de produtividade o aprendizado do JSF se mostrou rápido entre a equipe mesmo entre os que não tem conhecimento avançado de JavaEE, especificamente, componentes web. O JSF abstrai bastante toda a iteração entre cliente, container e código. A criação de métodos-evento, o mapeamento das views, a criação de conversores e validadores, tudo é realmente fácil.

Configuramos o SiteMesh para gerenciar e compor as views, mesmo com todos avisos sobre a integração problemática entre JSF e SiteMesh. Está funcionando e não tivemos problemas.

Alguns acoplamentos do bean com o framework tornam testes unitários mais difíceis de realizar do que no SpringMVC, por exemplo. Contudo, pasmem os que acharem isto uma heresia, não teremos testes unitários na camada de apresentação por vários, vários motivos, que darão outro post sobre o assunto. De qualquer forma, a deficiência do JSF quanto a isto não será um problema.

Ainda é cedo para dizer como ficará o resultado final. O prazo é apertado e pode-se dizer que mesmo com todos as dificuldades de usar o JSF, estamos caminhando para uma entrega dentro do esperado, com uma boa curva de aprendizado pela equipe e com a promessa de que o IDE, Netbeans, melhore cada vez mais a integração com JSF.