No começo do ano um amigo foi para os States e me trouxe (obviamente após eu muito implorar) um Kindle. Devo dizer que o dispositivo é sensacional (mesmo ainda não sendo a versão touch ou com andróid que saiu recentemente) e que eu nunca li tantos livros como tenho lido ultimamente.

Portanto, nada mais justo do que uma recomendação dos últimos livros que li e que julgo serem fundamentais para qualquer programador que queira melhorar a qualidade do seu trabalho, ou melhor, da sua arte.

• Effective Java 2nd. Edition - Fundamental para qualquer programador java. (ponto !)

• Clean Code - Gostei muito deste livro. O Autor, Uncle Bob, escreve muito bem e é super didático em seus textos. Há algumas polêmicas, como por exemplo o capítulo de comentário, e o de TDD, mas em suma é um excelente livro. Altamente recomendado se você também acredita que programar é uma arte e que, como toda arte, pode ser melhorada continuamente.

• The Clean Coder - Estou quase terminando de ler, e também estou gostando muito. É do mesmo autor do livro acima, porém eu indicaria esse livro mais para líderes técnicos, pois fala muito sobre profissionalismo e a postura que um programador deve ter em relação ao trabalho, ao time de negócio / produto, etc.

Se você acredita que já é bom o bastante, ou que aprende tudo o que quiser através do google, saiba que eu também tinha um pensamento parecido, e me surpreendi com os livros acima. Hoje posso dizer que a minha forma de programar, de pensar, minha política de sempre tentar melhorar um código que estou lendo e que não necessariamente escrevi (“boyscout rule” – Clean Code), e a minha postura profissional, evoluiu muito.

Com certeza o Rafael versão 2011 é bem melhor que o Rafael 2010, e também muito mais humilde =p.

Algum outro livro interessante para o meu Kindle ?

Quando escrevi o meu primeiro código executável (Visual Basic 3.0 em 1997) me perguntei se o havia feito do jeito “certo”, se era legível, se outras pessoas entenderiam, enfim, questionei-me se havia escrito o código da melhor maneira possível.

Já se passaram 12 anos desde então e eu ainda tenho essa dúvida! Incrível, não ? Mas acho que isso é algo que levarei comigo para o túmulo. Evidentemente há várias técnicas para melhorar a qualidade (caramba, não queria utilizar esta palavra) do seu código. Ultimamente tenho estudando bastante isso e me forçado a não me corromper com códigos ruins, por conta de prazos apertadíssimos. Eis que cheguei em algumas conclusões:

1. Tente não violar a Lei de Demeter. Se você ainda não compreender a beleza por trás da sua simplicidade, não tem problema você pode segui-la mesmo assim, ou dar algumas cabeçadas e ver que o problema todo é que suas classes falam com muitas outras que não deveriam.
2. TDD! Ok, isso é polêmico, mas pense assim: Quando você se utiliza de TDD, você se torna o primeiro cliente do seu código, e acredite, você vai querer mudar bastante suas interfaces para agradar a você cliente.
3. Já que falei de interfaces, lembre-se: “Programe para interfaces!!!!” (ok, 4 exclamações acho que basta =p ).
4. Codifique pensando no teste (unitário) e teste pensando no código. Se a criação dos testes estiver se tornando uma tarefa árdua, há algo de errado no seu design
5. Nunca se acomode com o design de suas classes. Acredite, sempre pode ser melhorado.

Acho que consegui resumir o que ando fazendo para tentar melhorar o meu jeito de codificar, de forma que a manutenção do código que eu escrevo não seja tao árdua. E agora, para finalizar, uma frase do Martin Fowler que eu adoro:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

E é isso o que estou perseguindo. Um dia eu chego lá.

Eu trabalho no desenvolvimento Java EE desde 2004 e isso me deixou bem por fora do que acontecia no mundo Java SE. E desde sempre eu utilizei o Eclipse e sempre o preferi ao Netbeans. Porém, esta semana resolvi desenvovler um aplicativo desktop, para agilizar uma tarefa meio monótona que tenho no trampo. A primeira versão foi com Eclipse e o plugin Jigloo, que eu não conhecia e até que achei ok. Ai conversei com um amigo meu (cassolato) e ele me disse que para Java SE, ele utilizavao netbeans, pois o Matisse dava problema com o Eclipse. Bom, resolvi testá-lo, e realmente me surpreendi. Não olhava pra cara do netbeans desde a versão 4.0, e realmente a evolução é notória. Sem falar que ele deu um banho no eclipse no quesito Desktop. Consegui fazer uma nova versão bem mais rápido e com um visual bem melhor.

Conclusão: O que é melhor, eclipse ou netbeans ? Bom, prefiro muito mais o eclipse, mas jamais vou tentar fazer um aplicativo desktop outra vez nele, rs…

Começa amanha a Developer’s Conference 2008, evento organizado pela globalcode e votlado ao público de desenvolvedores Java EE, bem como para gerentes de TI. Este ano a grade de palestras está muito legal, com algumas bem interessante, inclusive uma com Ed Burns falando sobre o JSF 2.0. A programação completa pode ser vista aqui e prometo que quem não puder comparecer lá, não vai perder nada, pois irei postar aqui no blog tudo o que julgar interessante para a comunidade Java EE. Pretendo, inclusive, postar via celular mesmo, caso algo seja realmente bombástico!

Então é isso, fique ligado no blog, que amanhã o dia será cheio de novidades.

Sim, eu fiz um plugin para maven2 (como descrito aqui). E realmente, foi beeeeem mais fácil do que imaginei, mesmo tendo que integrar uma API que nunca tinha ouvido falar na vida para copiar arquivos com o protocolo scp (Jsch).

No fim das contas o plugin ficou muito facil de se usar. Evidentemente ele segue a filosofia do “Convention over Configuration”, então, se você tem um projeto Java EE, com EJBs, assumo que estrutura será mais ou menos assim:

MyProject
    +------ MyProject-core
    +------ MyProject-ear

Para um simples “Hello World” com EJB3, por exemplo. Sendo que seus EJBs estao em MyProject-core, e o seu MyProject-ear é apenas um wrapper para todos os seus artefatos.
Para este exemplo, no pom.xml do MyProject-ear, basta inserir essas linhas dentro de build/plugins:

    <plugin>
<groupId>uol.maven.plugin</groupId>
<artifactId>maven-deployer-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<configuration>
<remote>false</remote>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>delivery</goal>
</goals>
</execution>
</executions>
</plugin>

Com isso, faremos um delivery no jboss local, utilizando a porta 8080 (padrão do plugin). Para alterar este comportamento, podemos fazer, por exemplo:

<configuration>
<serveHost>myServer</serverHost>
<serverPort>8080</serverPort> <!-- 8080 é o padrao -->
<remote>true</remote> <!-- na verdade true é padrao -->
</configuration>

Agora, basta ir na raiz do seu projeto e digitar:

mvn install

e com isso, será feito o delivery do seu ear (não esqueça de que o JBoss tem que estar rodando para funcionar).

Simples né?

Baixe aqui o plugin:Maven Deployer Plugin

Vamos, lá, algo bem corriqueiro: Você tem seu projeto Java EE com a build automatizada via Maven2. Ótimo! Ponto para você. Obviamente você quer fazer o deploy deste teu projeto no teu servidor favorito, então você chama:

mvn deploy

Ok ? Bom, infelizmente este comando apenas copia os artefatos do seu projeto (ear, jar, war) para o repositório remoto, ao invés de colocar um ear, por exemplo, no diretorio de deploy do seu JBoss, Tomcat, Weblogic, etc. Frustrante né ? Bom, mas deve haver alguma maneira de eu fazer isso de forma automatizada. Ficar copiando os jars/ears/wars/ na mão é tão, digamos, chato e antiquadro! Bom, para isso existe o plugin Cargo, que até agora não consegui fazer funcionar satisfatoriamente. Ah, também existe um tal de jboss-maven-plugin (que nem merece um link aqui no meu blog =p).

Já que nenhum desses serviu pra mim, resolvi fazer um plugin. E não é que é bem mais simples do que parece ? Em pouco tempo fiz um plugin que copia o EAR do padrão de aplicação que temos aqui na empresa para o servidor remoto, e chama um JMX para fazer o hot-deploy do mesmo. Bacana né ? Bom, o plugin ainda está em estágio inicial, só funciona no JBoss-4.0.4.GA, e não funciona de forma local (JBoss na sua máquina), mas pe bem promissor, uma vez que uma tarefa bem corriqueira e que ninguem da conta.

Estou preparando uma melhor documentação e logo logo disponibilizo aqui no site um tutorial de como usar o plugin, bem como o plugin em si.

Até breve.