Posts

Showing posts from May, 2007

AridPojos simplificando o desenvolvimento com Spring

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 .

Recursos avançados de Debug no Eclipse

Image
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

Benchmark aplicado: Clone Benchmark

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

Otimização prematura: A origem de todo o mal

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

XML VS Annotations VS Convenção

É, 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

Classpath Helper

Image
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

Desenvolvimento MVC RAD com Stripes

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