Diego Pacheco Tech blog

Quando estamos construindo um sistema OO, a base desse sistema é fundamental. Já é bíblica a frase " O Homem que construiu sua casa sobre a areia" . Para termos uma aplicação robusta, modular, escalável precisamos ter uma base muito bem fomentada, para isso o design é essencial. Pois como podemos construir artefatos que atendam essas premissas sobre uma base podre? A resposta é obvia, mas nem sempre o obvio é tão obvio. O Design de uma aplicação é mais importante do que qualquer tecnologia de implementação até mesmo a JEE. Não adianta usarmos Spring, Hibernate, MVC, etc se não temos: Alta coesão Baixo acoplamento A Questão chega a ser fetal, acoplamento gera merda. Quanto mais acoplamento pior, se os artefatos estão todos amarrados é muito difícil modificar o código e conseqüentemente a manutenção é penosa. Mas como podemos diminuir o acoplamento e aumentar a coesão? Utilizando Design Patterns Modelagem UML Divisão de papeis Utilizando Interfaces e Herança Re-utilizando des...

Quem quiser ter um 'preview' das novas features do java 7.0 pode acessar esse endereço: http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf e conferir as novas funcionalidades de ante mão. A Principal novidade é que vamos ter 2 implementação do JDK, o JDK desenvolvido pela própria Sun que vai sair sobre licensa GPL 2.0 e uma outra implementação que será desenvolvida pela comunidade java, esse projeto se chama OpenJDK. Vocês podem achar mais informação sobre o OpenJDK aqui .

Ultimamente eu ando estudando sobre Scrum. Scrum é um processo de desenvolvimento de software, que basicamente pode ser utilizado em java, .net, ruby e outras linguagens. Scrum é uma forma de desenvolvimento agile, porem está muito focado nas pessoas e no 'time' em si. Uma diferença significativa é que no Scrum nos não temos fazer incrementais como no RUP. Nos temos no mesmo ciclo: analise, arquitetura, codificação e teste. No Scrum são feitos releses rápidos que duram entre 2-4 semanas, como ele é um processo não uma metodologia ele pode ser adaptado conforme a sua necessidade. Esses releses curtos são chamados de sprints que são 'corridas', ou seja, entregas rápidas, assim nos vamos ter entregas incrementais. A Data da entrega(sprint backlog) é sacro-santa, isso é, não pode ser mexida, o que pode ser feito é diminuir o número de products backlogs(requisitos) , mas nunca alterar a data. A partir da figura a cima, podemos ver em sintese como é o ciclo de processo no ...

Em sintese depende do cenário. Considerando as possíveis formas de remoting do Spring: RMI Http Invoker Hessian Burlap Jax RPC JMS EJB RMI: Acredito que todos conhecem essa abordagem. É na verdade semelhante ao RPC só que para objetos, vocês podem achar mais informações aqui . A Desvantagem é ter que disponibilizar uma porta na maquina. Http Invoker : Estratégia especial de remoting que faz comunicação via protocolo http via serialização. A vantagem é por que trafegamos por um protocolo caracter que já está disponível para nos, leia-se já é utilizado por uma aplicação web. Hessian : É um protocolo leve baseado em http binário, que é provido através do Caucho. Você pode encontrar mais informações sobre esse protocolo para Web Service binário aqui . A Vantagem é que é bem leve. Burlap : É uma solução baseada em XML como alternativa do Hessian, também desenvolvido pelo Caucho's. É muito utilizado em comunicações com dispositivos moveis, como o telefone celular, já que alem de simp...

No Dia 07/08/2007 eu ministrei a palestra de Spring Framework 2.0 na T@rget Trust em Porto Alegre. Agradeço a presença de todos. Vocês podem baixar a apresentação em ppt aqui . Spring Framework View SlideShare presentation or Upload your own. (tags: jee framework )

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

O AridPojos é um mini-framework que facilita a vida de quem trabalha com Spring . Ele gera todas as definições de beans automaticamente, necessitando apenas informar o package e o modo de auto-wire. O Mais legal é que são apenas 5 classes, ele se utiliza dos novos recursos do Spring 2.0 com suporte a XSD para fazer essa grande facilidade. O mini-framework faz a adição programaticas dessas definições de beans do Spring diretas no container. Eu fiz alguns testes, consegui usar com extrema facilidade.  Ainda  é possível customizar as peculiaridades com uma tag extra. No artigo Chris Richardson's Spring library to autocreate bean definitions tem um exemplo de como se usa. Eu ia até postar aqui mostrando como se faz, mas de tal fácil que é acho que seria até inútil. No site do criador Chris Richardson tem mais exemplos. Powered by ScribeFire .

Na minha opinião o melhor IDE para java é o eclipse . Vou mostrar algumas funcionalidades avançadas do mecanismo de debug do eclipse. Acredito que essas funcionalidades são as melhores. O que vamos ver? Break Points Programaticos Evaluação de expressões em tempo de runtime Break Points Programaticos: Este é um recurso muito poderoso do eclipse que possibilita que nos possamos programar quando o eclipse irá disparar um break point. Assim evitando perda de tempo ao passar por uma serie de operações só pra chegar em um determinado ponto do programa. Evaluação de expressões em tempo de runtime: Esta feature possibilita que programar expressos em tempo de runtime para saber determinado valor, ou setar algum valor para teste. Muitos outros IDEs tem essa facilidade, estou citando por que acredito que é uma boa feature. Então vamos fazer um passo a passo de como fazer essas duas belezinhas funcionarem. Vamo lá!!! Break Points Programaticos 1. Vamos tomar como base a classe ForTest , o código d...

Seguindo a linha do post anterior vou mostrar um exemplo de como poderíamos fazer um benchmark. Vamos partir de um problema, depois de algumas premissas, teremos um cenário(contexto) e a duvida(?). Problema: Preciso saber se a operação de clonar beans atual utilizada pela aplicação está sendo eficiente em questão de performance. Premisas: A aplicação já está com 70% desenvolvida e testada, o tempo de alteração é escasso. Contexto: Existem 2.000 beans(pojos) com a implementação default. Esses beans não implementação a interface Clonnable e por seqüencia não tem um método clone. Dúvida: Estou clonando beans através do framework beans utils e tenho duvidas se o método clone da classe Object não seria mais rápido? Eis os códigos do benchmark package org.diegopacheco.clonebenchmark.model; import java.util.Date; public class Pessoa { private String id; private String nome; private String telefone; private boolean casada; private Date nasc; public Pessoa() {} public Pessoa(String id...

Certa vez um colega de trabalho, um grande amigo meu me disse: "Cara a otimização prematura é a origem de todo o mal" . O que esse mestre quis dizer foi o seguinte: devemos pensar duas vezes ou mais antes de fazermos uma rotina mirabolante que nem a pessoa que fez vai entender depois de um mês. Sempre devemos avaliar o quão será esse ganho para tal loucura. Como mensurar isso? Acredito que com duas coisas podemos fazer isso: Conhecimento do Negócio: Conhecendo o contexto e sabendo se teremos muitos usuários acessando a aplicação, sabendo se a rede é rápida ou não,  sabendo se esse ponto é critico ou não. Benchmark: Esse é o cara. Vai nos dizer o quão será esse ganho, podemos ter vários tipos de benchmarks, focando em diversos pontos como: Gasto de memória Tempo de lock em banco e outros recursos REDE Grau de complexidade para tal implementação Tempo Acredito que os fatores hoje em dia mais importantes são o tempo e o grau de complexidade . Não tem sentido optar por ...

É, essa é uma briga dura. No inicio do desenvolvimento de aplicações java a tecnologia de configuração de recursos e meta-dados era com certeza o XML . E com certeza hoje acredito ainda ser, mas existe uma tecnologia ganhando cada vez mais força as Annotations introduzidas no java 5.0 e para complementar esse trio temos as convenções mais velhas que a minha avó mas cada vez crescendo mais. Este conceito de convenções está ganhando muita visibilidade com o RoR que está cada vez mais influenciando o mundo java. As configurações em arquivos XML seriam uma evoluções de configurações em arquivos texto(seqüências) como pro exemplo os .ini do windows e da microsoft. Com a entrada das Annotations se iniciou um guerra literalmente e as coisas ficarm divididas entre XML e Annotations você verá que nesse contexto temos gregos e troianos. As vantagens do XML seriam: Possibilidade de validação através de DTD ou XSD . Flexibilidade Independência de plataforma Definição de formato e modularização P...

Navegando pela web esses dias eu encontrei um plugin interessante para o eclipse 3.2.X. Esse plugin se chama classpath helper. A Jogada desse plugin é visualizar em forma de arvore todas as dependências de um projeto no eclipse( no caso pode ser o que está selecionado pelo package explorer ou navigator)  ele mostra as dependências com outros jars que estão resolvidas, mostra quais recursos dependem dessas dependências e mostra todas as outras dependências insatisfeitas. A baixo tem uma foto que eu tirei do plugin. De fato eu vejo um problema com esse plugin, ele não tem a possibilidade de ignorar algumas dependências que estejam faltando. Por exemplo: supondo que eu estou usando Spring framework 2.0.4 no meu projeto eu só estou usando os recursos básicos de injeção de dependências, o classpath helper íra lenatar diversos problrmas por que não temos os jars de jdbc,hibernate,jms,jakarta*,etc.. no classpath, mas isso não chegar a cer um erro pois o classloader do java só carre...

MVC É de fato um padrão desenvolvimento em camadas, que basicamente se caracteriza por separar a camada de negócio(Model) da camada de apresentação(View). Nesta arquitetura temos diversas soluções consolidadas como: Struts , Spring MVC , MyFaces(JSF) , ADF(JSF ORACLE) , JBoss RichFaces(JSF) , entre tantos outros. Mas hoje eu venho lhes falar do Stripes , que é uma framework baseado na arquitetura MVC porem o Stripes é muito RAD , com ele podemos desenvolver uma solução WEB com pouco esforço e praticamente zero de configurações xml. O Stripes utiliza o conceito onRails e consegue fazer mais convenções e menos configurações. Alguns pontos importantes sobre o Stripes: Desenvolver aplicações Web de maneira fácil. Prove soluções simples e poderosas para problemas comuns. A Curva de aprendizado é muito baixa. Se você necessita configurações muito especificas pode usar annotations . Eu baixei o Stripes versão 1.4.2 e fiz alguns testes. Foi bem simples de aprender como usa-lo o apren...

é um framework java feito na arquitetura REST . Podemos conferir a lista de features do Restlet aqui: features . O Restelet vem como uma alternativa completa para API Servlet. Ainda mais agora a que vai entrar uma JSR para Rest em java. Confira no Link: JSR311 . Fiz alguns testes com o restlet nas partes de Guard,Invocação de Webservices com JSon e bowser list. Talvez mais para frente eu poste algum desses teste aqui. Na minha opinião nesses itens que testei achei bem simples e intuitivo o uso do restlet. Agora é esperar essa JSR311 começar a bombear. Mas eu acredito que o restlet será uma boa pedida.

O Steve Anglin escreveu um artigo no onJava sobre os 10 mais comuns erros em relação ao Spring. São erros conceituais. Neste Artigo ele traz dados de empresas como bancos, empresas governamentais, empresas aéreas. A empresa Voca da inglaterra fez em 2005 mais de 5 bilhões de transações utilizando Spring. Leiam o artigo do Steve Anglin, acredito que irá esclarecer muitas coisas.

Mais uma vez: Spring Framework .Eu confesso que tenho uma certa queda por este framework, mas não poderia ser diferente o Spring é uma excelente solução com ótimo suporte, documentação impecável, Poderia escrever 1.000 linhas de elogios ao Spring aqui. Mas o ponto agora é JMS Assíncrono verdadeiramente baseado em POJOs, Essa integração do Spring com JMS acontece muito bem. No exemplo do Mark Fisher Message Driven POJOs , ele mostra como construir essa solução, utilizando JMSTemplate do Spring. Recomendo a leitura e tentar fazer o exemplo que ele mostra, eu fiz é bem simples e rápido. Depois Mark escreveu um outro artigo Request-Reply JMS with Spring 2.0 este por sua vez se baseia no anterior porem, ele mostra uma outra abordagem utilizando: JmsInvokerServiceExporter e JmsInvokerProxyFactoryBean que nos possibilitam trabalhar com JMS de maneira que o Spring abstrai totalmente o modelo de Queue Request/Response. Eu fiz os dois exemplos que ele mostra, achei muito fácil e acredito ser...

O Design Pattern DAO é um padrão para se encapsular o acesso a banco de um determinado Objeto. Existem muitas criticas sobre esse padrão, dentre elas a que você prolifera muitas classes do estereótipo DAO pelo seu projeto e ma verdade elas só tem um conjuntos de métodos find*. Eu concordo com isso, achei um artigo no Developer Works da IBM, que na minha modesta opinião é uma ótima solução. Você cria uma DAO Genérico e depois só precisa criar interfaces e named querys no Hibernate. A solução envolve Hibernate e Spring + AOP. É Muito bem bolada. Recomendo a leitura do artigo, no final do artigo tem um link para os fontes. Vou resumir o que a solução faz: Existe uma interface GenericDao que define o comportamento de um DAO, temos uma implementação padrão para essa interface que é a classe GenericDaoHibernateImpl essa classe implementa mais três interfaces: FinderExecuter que é o que o interceptor do Spring ira interceptar. E a outra é FinderArgumentTypeFactory Que define uma factory...

Gostaria de recomendar a leitura do artigo no ONJava sobre as 12 melhores praticas sobre configuração de XML no Spring. Estou esperando ansiosamente que o Spring possibilite fazer sua configuração através de annotations, enquanto esse dia não chega é valido utilizar o xml da maneira mais correta. O Link para o artigo está aqui!

O DWR permite Javascript no browser interagir com o servidor e a manipular paginas com resultados. DWR Significa: Direct Web Remoting, ele é um framework para fazer a conversação de paginas com o lado server, utilizando Ajax. Vou mostrar um exemplo de como integrar o DWR com o Spring Framework . web.xml: Aqui é um web.xml padrão onde definimos os servlets do DWR e Spring. <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">    <!-- Registro do Servlet do DWR -->       <servlet>       <servlet-name>dwr-invoker</servlet-name>     ...

Ao falar nesse assunto provavelmente venha a cabeça de cada um... VELOCITY da apache. Mas hoje vou "falar" de Freemaker . O Freemaker é muito semelhante ao velocity, eles tem o mesmo propósito. A partir de um template e objetos Java, é gerado um output que pode ser html,pdf,txt,classes java,arquivos de configuração,etc... Esse framework se destaca em relação ao velocity por que: Tags mais evoluidas estilo java 5.0 Mas simples de programar o template Transformation Template Bean Wrapper Method Call Transformation: Com esse recurso podemos especificar uma tag e ai efetuar um determinado processamento sobre todo o conteúdo que estiver sobre essa tag. Vou dar um exemplo de um Transformation que passa o texto para maiusculo e coloca em negrito(html). Classe java class UpperCaseTransform implements TemplateTransformModel {     public Writer getWriter(Writer out, Map args) {        ...

Ao ler o artigo A Definition of Closures do Neal Gafter Criador do Google Calendar e ver sua apresentação no JavaPolis6 Acredito que o java será melhor com Closures. A entrada de Generics no java 5.0 deixou o desenvolvedor com pais poder, apesar de o código ficar consideravelmente mais complicado. Acredito que com Closures o código ficará mais complicado ainda en determinadas situações mas o poder do desenvolvedor será mais forte. Vejam a apresentação do Neal no JavaPolis que valhe a pena.

Recomendo a leitura do artigo The top Java EE best practices , eu quero comentar os dois primeiros itens da lista de 19 melhores praticas. Use MVC e não re-invente a roda. Use MVC: Sempre use MVC. Eu trabalhei em uma empresa que entre a camada de apresentação e a camada de modelo sempre trafegava os dados em xml e depois fazia o bind para um objeto, não gosto desse modelo pois o xml deve ser usado para comunicação entre tecnologias distintas, não entre camadas da mesma tecnologia como view e model. Era um inferno isso além de gerar um over-head não tinha ganho algum. Não re-invente a roda: Acho que essa é a grande lição para as empresas e os desenvolvedores, não cometa os mesmos erros que as outras pessoas cometeram aprenda com o passado dos outros. No artigo fala que varias empresas fizeram seu próprio "framework" de GUI(camada da view do MVC) isso também é um grande erro, pois passando por aquilo que muitas outras pessoas já passaram e sofrendo a mesma dor. Use frameworks j...

Um dos freatures interessantes do java 6.0(Mustang) é a Java Compiler API resultante da JSR 199 . Vou mostrar um exemplo de como usar essa API, esta api nos permite usar a compilação de artefatos java de uma maneira mais elegante sem precisarmos invocar o javac via algum CLI da vida. Além de proporcionar compilação de código java em uma String em memória e listeners java compilação. Esta é a classe java que eu quero compilar. package org.diegopacheco.java6comilerapi.model; public class Hello {      public static void main(String[] args) {           System.out.println("Ola mundo");      } } Este é a classe java que irá compilar a classe Hello.java package org.diegopacheco.java6compilerapi.util; import java.io.File; import java.io.IOException; import javax.tools.JavaCompiler; import javax.tools.ToolProvider...

Pessoal talvez vocês em uma primeira impressão achem graça disso, mas acredito que nem todos os desenvolvedores java conhecem bem esses padrões. Segue o link de referencia: code conventions Por que isso? Esse dias ao conversar com outros desenvolvedores e ao ver códigos via algumas coisas que me deixaram inquieto como: public boolean validaCPFandCNPJ(String arg0){...} public class CNPJ{...} Segundo o documento da Sun esses dois exemplos estão errados. O correto seria: public boolean validaCpfAndCnpj(String arg0){...} public class Cnpj{...} Para métodos é preciso respeitar o camelCase. Mas uma dais coisas mais bizarras que eu via foi uma classe da oracle que vem no driver jdbc deles o jdbc14.jar tinha uma classe com esse nome: STRUCT olha só que legal isso(ironia rsrsrs): STRUCT struct = new STRUCT(); Horrível... Mas a sun, dentro do jdk e da API também tem alguns nomes esdrúxulos. A Nomenclatura e padrão de codificação é muito importante, leiam esse documento e sigam. Se não que Crom...

O XFire é a proxima geração de frameworks SOAP com um modelo de mensagens leves usado para integrar mensagens SOAP via STAX. Ele tem uma integração muito boa com o Spring Framework . Vou mostrar um exemplo de como fazer isso. primeiro passo é definir uma interface neste exemplo vou definir a interface hora. package org.diegopaheco.springxfire.model; import javax.jws.WebService; @WebService public interface Hora {   public String getDateTime(); } Como vocês devem ter percebido eu só usei a annotation @WebService no XFire. Agora vamos criar um serviço que implementa essa interface. package org.diegopaheco.springxfire.model; import java.util.Date; import javax.jws.WebService; @WebService(serviceName = "HoraService", endpointInterface = "org.diegopaheco.springxfire.model.Hora") public class HoraImpl implements Hora {      @SuppressWarnings("deprecation") ...

Em um projeto java, normalmente, usamos java doc para documentação de código/api. Algumas vezes os programadores mais preguiçosos não fazem esse papel e a documentação fica incompleta e em muitas vezes ela nem existe. Essa ferramenta da Sun Sun Doc Check Doclet Gera estatísticas sobre os fontes de um projeto java e assim podemos ver quantos artefatos,quais,como estão documentados. Assim podemos ter um controle e garantir uma boa documentação e o uso correto de java doc. Valhe a pena seguir o padrão de documentação java . Para usar a ferramenta é simples, só precisamos colocar o jar doccheck.jar no classpath e utilizando ant fazemos a geração, segue um script de exemplo. <project name="Sundoccheck-test" default="all" basedir=".">      <!-- This build file compiles the Doc Check source files,        builds a library ...