Diego Pacheco Tech blog

Hoje em dia a predominância de frameworks e de sistemas web é de JSF . O JSF veio para padronizar aquilo que Struts da Apache já vinha fazendo anteriormente, com certeza ficou melhor. Hoje as implementações carro chefe são a da sun , tomawawk da apache , ADF da oracle . Eu gosto do JSF mas eu vejo algumas deficiências nele. São elas: - Muito XML, muita configuração. - Fazer um componente é um inferno, xml,dtd, class, muitos artefatos. - A navegação é muito dura, e de novo muito xml. - Não tem componentes, somente os básicos, somos obrigados a usar taglibs de terceiros como: RichFaces da JBoss . O JSF precisa ser mais RAD, eu gosto dos conceitos de navegação que o Stripes framework tem. Me agrada alguns conceitos do Click Framework também como a iteração da pagina(template) com o action. Se o JSF aplicasse políticas mais onRails e usa mais convenção e até mesmo annotations as coisas ficariam bem melhores. E concerteza fazer um componente deve ser mais facilitado, nisso ele me lembra...

Recomendo a leitura do artigo Introducing continuous integration é muito bom. Esse artigo fala sobre CI, em português integração continua. Esse artigo é muito interessante recomendo a leitura e se você não usa CI recomendo que comece a usar. Princípios básicos Assumir é ruim, se assumir que o parâmetro 'x' é passado para um método esse método vai falhar. Assumir é difícil que desenvolvedores vão adotar estilo de código e design. Assumir que arquivos de configurações não mudaram é perda de tempo. Quando se faz presunções no desenvolvimento de software você gasta tempo e aumenta os riscos. CI Desenvolver software requer planejar para mudar. Feedback imediato, ajuda a resolver mais rápido o problema. Processo de build continuo Peça central para a qualidade Continuidade, sem parar Praticas de CI Comite o código freqüentemente Não comite código quebrado Arrume os problemas de build imediatamente Faça testes automatizados Todos os testes e inspeções devem passar Rode todos os builds...

http://www.engadget.com/2007/05/30/steve-jobs-and-bill-gates-historic-discussion-live-from-d-2007/ Powered by ScribeFire .

Eu estava lendo Removing Checked Exceptions from Java e na minha opinião essa é uma faca de dois gumes. Se em uma via dos removemos as exceptions checadas e tudo que é deprecated ficaria:  - Mais simples, pois a API teria menos métodos.  - Não ter perigo de usar o 'método velho'.  - Mais fácil de desenvolver pois não teríamos que encapsular tudo em RuntimeException( Essa política já é adotada por frameworks como o Spring e o Hibernate , que só levantam exceptions Runtime). Não outra via:  - Não teríamos mais compatibilidade, pois a cada versão nova do Java ele iria anular a versão anterior e forçar que os desenvolvedores refaçam o código já pronto. Na minha opinião não devemos remover nada, devemos contar com o bom senso de evitar usar os métodos deprecated . Com uma ferramenta como o eclipse podemos localizar esses códigos e no futuro fazer um refactoring . Powered by ScribeFire .

Gostaria de recomendar a vocês que assistam o vídeo do Rod Johnson CEO da interface21 e criador do Spring Framework . Neste vídeo o Rod faz uma revisão do passado até os dias de hoje. Com certeza os Spring inovou muito quando utilizou DI , o que DI fato ele é, um container de injeções de dependências. Neste vídeo mostra alguns dos principais 'gols' que o modelo de programação voltado a Spring trouxe e os futuros 'gols' que o Spring pretende atingir.  O ponto que mais salta a minha atenção é a questão de AOP no qual mais uma vez ele provou estar muito na frente do modelo EJB 3.0. Foi uma escolha muito feliz o AspectJ ser incorporado ao Spring.A prova de que o suporte de AOP do Spring é superior ao mecanismo de Interceptação do EJB 3.0 foi dado no vídeo. Pois na solução de EJB 3.0 é necessário colocar annotations em classes e a 'interceptação' ocorre com a exata assinatura do método então é muito simples de esquecer alguma anotação ou configuração vi...