Desenvolverdor Java mudando de Windows para Linux(Ubuntu)

Dae guriazada...

No início do ano meu notebook estragou. Demorei uns 4meses para mandar arrumar. Mas consegui! :D:D:D

Então, resolvi mudar e largar de mão o windows vista.

Faça a mudança acontecer. Não mude.

Mudança é sempre uma palavra complicada. Nós, profissionais de TI, sempre adoramos mas organizações nem tanto.

Depios de uma certa experiência, que relaciono com as "vivências" não com o tempo, aumentamos nosso poder de obsevação e nossa análise crítica. Apartir daí, somos capazes agregar valor ao nosso trabalho de forma mais intensa.

Quando trocamos de empresa essa vontade de trazer nossas experiências a tona é dispertada. Normalmente nos deparamos com diversos pontos que podemos melhor, agregar, modificar, etc, no novo contexto. Isso acontece devido às experiências carregadas na mocihla.

Neste momento vejo o primeiro equívoco.

Trazer as crenças da empresa para nós, não trazer a nossas crenças para a Empresa

Não é bom chegar em um lugar e querar mudar diversas coisas. Apontar diversos falahs. Não e bom porque mal entendemos o ambiente, o contexto, como as coisas funcionam.

Viver a rotina da empresa para depios apontar pontos de melhoria é um bom começo. Dessa forma, é possível projetar o impacto das mudanças. Ao conseguir projetar o impacto das mudanças pode-se argumentar para que elas sejam efetuadas.

Devemos fazer parte do negócio, enteder os fluxos de trabalho, conhecer as causas e efeitos, o porquê as coisas são como são.

A partir daí...

Faça a mudança a contecer, não mude

Normalmente temos idéias que, com certeza, vão mudar o mundo. A empresa vai lucrar muito mais, eu vou ganhar uma promoção, tudo vai melhorar. Mas...

Apesar da mudança ser uma constante, ela tem que ser controlada pelas organizações. Afinal, qualquer mudança tem custo. Se cada funcionário que entra resolver mudar tudo, a empresa ta ferrada!

Por isso, para fazer com que suas idéias possam ser atendidas não proponha simplesmente mudanças. Provoque a inquietude nas pessoas. Provoque a mudança nas pessoas. Seja um agente de mudanças. Levante faíscas para que todos envolta possam acender o fogo. Isso sim que vai fazer todoas ganharem.

Ser um agente de mudanças
Acredite nas pessoas. Seja humilde. Ouça o que os outros têm a dizer.Valorize o conhecimento de quem está a sua volta.

Se você mostrar estas características ANTES de sair mudando tudo, será ouvido.


Pense fora da caixa
Um dos passos para ter idéias novas é questionar.

Não seja "palpiteiro". Questionar sem argumento é palpite. Isso não agrega nada.

Questione, entenda, reflita, então provoque a inquietude nas pessoas. Para que todos façam os mesmos questionamentos.



Resumindo, tenho três idéias principais sobre mudanças:

• Entenda o contexto. Não "jogue" tudo que você conhece propondo mudanças em tudo.
• Provoque mudanças em quem está a sua volta.
• Pense fora da caixa.Questione, entenda e refilta sobre o contexto.

Não sei porque resolvi escrever isso...

Mas... são 3h da madruga e veio a inspiração... amanhã eu leio como ficou... heheheh

Abraço!

RMI e HIbernate... lições aprendidas

Estou participando de um projeto onde decidimos utilizar RMI para conversação de dois módulos do sistema. A decisão não vem ao caso agora, mas achei interessante gurdas alguns "causos"...

RMI e Hibernate, onde tudo começou

Como falei anteriormente, decidimos utilizar RMI para integrar dois módulos do sistema. Um módulo responsável pela parte de negócio( persistência também) e outro por uma parte específica bem baixo nível (baixo nível = bytes.. 01010101...etc...).

Então, o gênio projetista teve a seguinte idéia: "Vamos utilizar as classes persistentes para trafegar via RMI".

Resultado: LazyInitializationException -LIE.

Em um determinado método de uma classe acessada via RMI o retorno era um objeto que foi buscado do Hibernate. Este objeto tinha outros objetos, que tinham outros objetos, que tinham outros objetos... blá blá blá...

Soluções:

1º) Colocar "transient"(do java não do JPA) nos atributos que não deveriam trafegar via RMI. Puramor de Deus, Nãããão!!!

Imagina ficar colocando transiente em tudo que é atributo espalhado pelo código inteiro. Loucura!!!

2º) Modificar o design

Interessante... muito interessante...

O Design... (não é de moda porr!!)

Tentei fazer algo que representasse o problema. Então abaixo estão algumas classes de domínio, mapeadas no hibernate.

OBS: Para quem não sabe, em RMI devem existir interfaces comuns nos dois lados da comunicação. Então a interface PessoaData é conhecida pelos dois módulos.


Agora, viram o que o projetista gênio fez ?!?!?!

A classe Pessoa implementa a interface PessoaData. Na imagem acima temos somente um exemplo, mas no contexto real são umas 20 classes que irão trafegar via RMI. Todas essas classes são entidades persistentes.

Observe que a interface PessoaData retorna byte[]. Isso mesmo.. o "carinha" que utiliza estas classes vai precisar dos dados convertidos em bytes. Guarde esta informação.

Confesso que o projetista gênio(agora já deve-se saber quem é o projetista... :D ) percebeu a burrada somente quando ocorreu o erro com hibernate.

O que vocês conseguem enchergar ai?

Bom, vou dizer o que eu consegui enxergar:

• Uma classe persistente implementa uma interface utilizada para comunicação entre sistemas. Acomplamento! Entidade persistente conhece uma interface onde o objetivo é comunicação de dados entre sistemas... "nada a vê"
  
• Pelo motivo acima, a entidade persistente é responsável por converter String, Integer, Date em bytes. Coesão! Tava tudo misturado, conversões com bytes em uma classe onde o objeto é enviar e obter informações do banco de dados.

Solução tomada

Utilizamos os famosos Transfer Objects. Segue o exemplo:

Matamos o problema de coesão, onde a classe PessoaTo é responsável por trabalhar os dados para comunicação.
Matamos o problema de acomplamento onde a classe Pessoa não sabe que a classe PessoaTo existe.
Matamos o LazyInitializationException. A classe TO contém apenas o que será necessário para transferência.

Lições aprendidas

• Colocar tudo em uma classe é diferente de economizar tempo
• Preguisoço trabalha em dobro... :D
• Projetos iterativos minimizam os erros. Descobrimos o problema no início e retrabalho foi de aproximadamente 5hs.
• Enviar objetos utilizados para persistência via RMI-> ... LazyInitializationException
• Spring RMI exporter facilita muito!
• Cuidar as dependências das classes

Era isso..

Abraço!

Quer aprender Adobe Flex?

Acabei de chegar de uma palestra de demonstração do Adobe Flex na T@rgetTrust.

Eu não sei nada sobre Adobe Flex, mas achei muito interessante o que vi hoje.

Segue algumas referências para quem estiver afim de iniciar os estudos:

Referências:

• Adobe TV
• Flex Developer Center
• Tour de Flex

Listas Brasileiras

• FlexBrasil
• FlexDev

Bibliotecas (outros componentes):

• Flexlib
• Flex MDI
• Flex Object Handle
• Ilog Elixir
• Degrafa

Frameworks para integração com Java:

• BlazeDS – Free
• OBS: O spring tem um projeto para integração com BlazeDS
  
• LCDS - Pago

Tutoriais:

• http://www.adobe.com/devnet/flex/flex_java.html
• http://www.javaworld.com/javaworld/jw-01-2009/jw-01-javaee-flex-1.html?page=1
• http://www.adobe.com/devnet/livecycle/articles/blazeds_gettingstarted.html
• http://blog.digows.com/integrando-adobe-flex-blazeds-springframework-hibernate-uma-soluo-opensource-para-sistemas-web-parte-1/ (Muito Bom!!!)
  

IDE

• Flex Buildes ($249)
• Flex Builder plugin para Eclipse ($249)
• Flex SDK (Gratuito)
• Flex versão para estudante

Esse post é mais para eu anotar em algum lugar os links do que qualquer outra coisa..

Abraço

Simundi

Padrões de Projeto - Gerador de Gráficos com Template Method

Dae gurizada...

Algum tempo atrás eu e um amigo, Marcos Brião, fizemos uma oficina (workshop) na Confraria do Java, grupo de estudos da Ulbra em Canoas/RS, sobre Desgin Patterns.


Esses dias tava revirando meus arquivos e encontrei essa apresentação. Nessa oficina fizemos um Gerador de Gráficos simples com alguns patterns. O sistema ficou bem interessante.

Screenshot:

Faça os downloads:

• Apresentação (PDF)
• Aplicação Exemplo

Essa aplicação basicamente gera gráficos com informações digitadas na tela. Com o uso de Design Patterns como Template Method e Facade, conseguimos ter uma aplicação fácil de fazer manutenção e entendimento.
Utilizamos o framework JFreeChart(link) para gerar os gráficos.

Esse é o diagrama de classes:




Template Method
Definição:

Definir o esqueleto de um algorítimo em uma operação, postergando (deferring) alguns passos para subclasses. Template Method (Gabaríto de Método) permite que subclasses redefinam certos passos de um algorítimo sem mudar a estrutura do mesmo.

Padroes de Projeto -GoF

Vamos imaginar um algorítimo qualquer, com esse exemplo, gerar gráficos.

Quando vamos gerar gráficos a lógica para criar o ojeto JFreeChart é sempre a mesma. A única parte que muda, de um gráfico para outro, é quando vamos adicionar os dados ao gráfico.

Nesse contexto poderíamos ter uma classe que faria a lógica para gerar o gráfico e quando fosse adicionar dados, passaria a responsabilidade para uma classe filha.

Fizemos exatamente isso. Temos uma classe abstrata chamda GraficoTemplate, que tem a lógica para gerar os gráficos.

Veja a classe:

Como vocês podem ver essa clase é bem simples.

Temos um método criarGráfico, que recebe uma lista de dados e retorna um objeto JFreeChart. Esse método esta declarado como final. Isso significa que nenhuma classe que extender esa classe poderá alterar essa lógica. Esse detalhe do método ser final não faz parte do padrão Template Method.

Dentro do método criarGrafico eu chamo dois métidos: "carregarDados" e "configurarLegenda".

O método "configurarLegenda" é implementado dentro dessa classe mesmo. Ou seja, tem uma implementação padrão, mas qualquer classe que pode sobrescrever o método e alterar essa configuração de legenda.

O método "carregarDados", muita anteção! Aqui que está o Pattern.

Viu que o método esta marcado como "abstract" e por isso não tem implemetação ?

Na linguagem java todo método declarado como "abstract" indica que esse método deverá ser implementado na primeira classe concreta que estender essa classe.

O comportamento é igual ao de uma interface. Até por que uma interface, para o compiladora java, é uma classe abstrata com métodos abstrados, mas isso é outra história.

Vamos ver uma classe que estende a GraficoTemplate.

Vamos ver a classe que gerar o grafico de Pizza:


A classe GraficoPizza estende a GraficoTemplate e, obrigatoriamente, implementa o método "carregarDados(List dados)".

É aqui, na classe filha, que é definido como será carregado o gráfico.

Simplesmente itero a lista e populo o objeto "grafico", que está definido como protected na classe GraficoTemplate.

Veja que nessa implementação eu usso o método "createPieChart3D" da classe ChartFactory.

Quando fomos implementar outra classe, como a GraficoLinha, esse método "carregarDados" será diferente.

Veja:

A implementação do método "carregarDados" na classe "GraficoLinha" está um pouco diferente.


Esse exempo é bem simples. Mas se você conseguiu entender a "lógica"do pattern com certeza irá utlizar muitas vezes esse.

O que fizemos aqui é delegar parte da lógica de gerar gráficos para suas classes filhas.

Você pode estar pensando que a lógica que está no classe GraficoTemplate é bem simples. E realmente é. Mas poderías implementar nela outros métodos como alterar as cores do gráfico, definir um padráo de tamaho, etc..

Isso seria simples e se aplicaria a todos os gráficos da aplicação.


Esse exemplo foi construído para explicar, de forma simples, a lógica de 1 padrão de projeto e como é vantajoso sua utilização.

Tem pontos da aplicação que estão "feias" quanto a Design. Como por exemplo, não ter utilizado interfaces e utlizar Array de object para transferir dos dados da View para os gráficos.


Mas, nem tudo é perfeito...heheheh

Conforme irei estudando os Design Patterns vou postando ai...

Mais uma vez: Críticas sempre são bem vindas, obrigado.

Abraço a todos!