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!

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.

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.

• 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.

A especificação é o caminho para a iluminação

Quer fazer a prova de certificação de EJB e ter sucesso de primeira? Baixe a especificação do EJB 3.0 e estude por lá. Infalível!!

Outros livros?

Um dos melhores livros de EJB é o Head First EJB, da Kathy Sierra e Bert Bates. Daquele jeito meio brincalhão, com muitos desenhos e diagramas, você pode levar seu livro e estudar EJB até na praia. Infelizmente até este momento o livro não foi atualizado para a versão EJB 3!!

Certificação

Um ótimo guia de estudo pode ser encontrado no site http://java.boot.by/scbcd5-guide/

Agile Manifesto

Metodologias Ágeis!! Na prática, um conjunto de ações e princípios técnicos e gerenciais que tornam seu desenvolvimento menos arriscado e com certeza mais divertido. Um ótimo começo é o Agile Manifesto que foi escrito por um grupo expert de programadores que num dia chuvoso resolveram se reunir para beber e discutir as boas práticas que cada um usava em seus projetos. No link About the Authors você encontrará o site de cada um dos participantes com mais informações sobre metodologias além de diversos outros temas importantes.

UML Tools

Se quer começar a desenhar UML neste exato momento use a ferramenta JUDE UML, que não é open-source mas tem uma versão community (gratuita!!).

Spec UML

A UML é especificada e mantida pela OMG. No site você poderá baixar a especificação da última versão da UML. Mas aviso: não é dos documentos mais didáticos. Sugiro algum livro escrito em linguagem para humanos.

Outros livros?

O livro Head First Object Oriented Analysis and Design aborda os assuntos discutidos no curso OO-226 de uma forma divertida - diferente das piadas sem graça do seu instrutor!

Uma ótima abordagem sobre UM pode ser encontrado no livro UML Distilled, do Martin Fowler.

Outro livro fantástico é Extreme Programming Explained de Kent Beck. Fala sobre metodologia XP. É a referência obrigatória no assunto.

Por último o livro Agile Project Management With Scrum de Ken Schwaber explica a metodologia Scrum e sua aplicação no gerenciamento de projetos.

As várias APIs da J2ME podem ser encontradas on-line. Confira também todas as especificações no site da JCP. Você deverá ter as principais:

185 - JavaTM Technology for the Wireless Industry
139 - Connected Limited Device Configuration 1.1
118 - Mobile Information Device Profile 2.0
120 - Wireless Messaging API

Esses indianos…

Sathya Srinivasan organizou resumos das especificações para certificação J2ME (além de outras certificações).

Outros livros?

O livro Beginning J2ME From Novice to Professional é um ótimo complemento ao curso. Você poderá utilizá-lo como reforço para sua certificação.

Convenção de Código Java

Neste documento está descrito qual o padrão que os programadores Java utilizam ao codificar, desde nome de variáveis, classes e métodos, até nomes de packages e comentários. Veja o documento aqui.

API da linguagem Java

Se você passou o curso inteiro fugindo do JavaDoc (v6) é hora de criar vergonha na cara e abrir a documentação das classes da API. Se quiser ser um programador de verdade e não perder tempo (e gerar bugs) tentando “adivinhar” os métodos existentes, consulte sempre!!

Investigue o código dos outros

Uma boa fonte de inspiração são os milhares de código open-source que você encontra em sites como java.net ou então Sourceforge. Um boa alternativa é baixar e brincar um pouco com um projeto antigo mas ainda bem didático e atual: o Robocode.

Persista!

Persista… não, você não… suas informações!! Aprenda a conectar e persistir seus dados utilizando um banco de dados relacional. Você pode baixar o MySQL ou usar o JavaDB que já vem com a J2SE. É fácil, rápido e indolor… mas você terá que ler um pequeno tutorial em http://java.sun.com/docs/books/tutorial/jdbc/.

Outros livros?

Se Java ainda é uma nuvem negra e pesada e sufocante e amarga e feia… bem, sugiro que corra até a livraria mais próxima e adquira o livro Head First Java, da Kathy Sierra. Caso você esteja interessado em fazer a prova de certificação (Certified Programmer), sugiro o livro SCJP, também da Kathy… essa mulher não é demais?! E por último, sugiro o livro Core Java 2 Advanced com capítulos sobre multithreading, JDBC, RMI, XML entre outros.

Object Serialization

Serializar objetos é da-hora!! Você pega um objeto e transforma ele em bytes chamando o método writeObject() que então… bom… melhor você ler com calma este documento.

RMI

Java Remote Method Invocation (RMI) é o mecanismo que permite que um objeto executando em uma Java Virtual Machine chame métodos de um objeto executando em uma Java Virtual Machine remota. RMI permite a comunicação entre programas escritos em Java. Saiba mais aqui.

1) Baixar o SVNAnt (http://subclipse.tigris.org/svnant.html)

2) Copiar *.jar de svnant_home/lib para o diretório ant_home/lib

3) Indicar no arquivo build.xml a taskdef: 

<taskdef name=”svn” classname=”org.tigris.subversion.svnant.SvnTask” />

4) Ver documentação das tags em http://subclipse.tigris.org/svnant/svn.html