Muitas pessoas reclamam que perdem o poder do SQL ao utilizar um mapeamento objeto-relacional como o Hibernate. Daniel Passos mostra que existem modos de “recuperar” este “poder”, caso necessário, claro.
No já clássico engarrafamento Barra da Tijuca x Resto do Mundo, vim lendo a Mundo Java. Tem uma matéria bem interessante do Eduardo Guerra sobre a construção de um framework de Negócios/Persistência.
A matéria é muito legal mesmo se você quer entender como um framework é criado, mas tem um problema. Ela é “vendida” como algo do tipo “Não use Hibernate/Outro ORM, use 100% Java!”. Nada explícito no artigo em si, mas nas chamadas e no marketing em torno deste.
Alguns pontos questionáveis:
Novamente: a proposta é louvável, só foi colocada de uma maneira muito ruim. Existem pessoas que realmente não podem utilizar frameworks em desenvolvimento por restrições políticas, um framework como o da matéria pode ajudar em alguns casos. Já vi gente que, no desespero, integra os fontes do spring/struts/etc no seu código para poder os utilizar – vi mais de uma vez, aliás.
Vale a pena ler e acompanhar tendo em mente que trata-se de um framework simples sendo construído didaticamente, e que a modelagem resultante é um CRUD sem Domain Model.
Segunda-feira é dia de apostila de Spring atualizada!
Desta vez temos uma breve explicação sobre a construção de domain models em Java utilizando POJOs e Spring. É algo próximo a um resumo prático do artigo publicado na MundoJava #17, se você quiser se aprofundar mais no projeto de aplicações a revista é a leitura indicada.
O desenvolvimento utilizando POJO é introduzindo com um paralelo entre este e o desenvolvimento com EJB. logo após temos uma breve e prática explicação sobre alguns padrões de Domain Driven Design. Como já mencionei, a idéia do curso de spring e consequentemente desta apostila é o bom uso do framework. Se for só para escrever arquivo de configuração a referência do mesmo e um bom editor de XML já são mais que suficientes!
…leia isso.
Adobe Flex
Dia: 13/novembro/2006 (Segunda-feira)
Horário: 19:00 horas
Duração: 2 horas
Local: Auditório do SENAC CIT - Rua Santa Luzia, 735 - 7o. andar, Centro
Dica de Acesso: Estação Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado AmericanoEntrada Gratuita e Sem Inscrições Prévias
Sorteio de assinaturas das Revistas “Mundo Java”, “Java Magazine” e “SQL Magazine”, para os presentes.
A Palestra:
As interfaces de usuário dos sistemas Web ainda não possuem a mesma interatividade das interfaces dos aplicativos desktop. O resultado disto é que, se por um lado ganhamos com facilidade de desenvolvimento e manutenção, por outro lado o produto final perde perante a pessoa mais importante: “O USUARIO” . Recursos simples como Drag and Drop só agora começam a voltar aos aplicativos web graças a iniciativas como o Ajax. Por sorte, o Ajax não está só nesta empreitada. A Adobe tem uma ferramenta que está revolucionando as interfaces dos aplicativos para a internet , que se chama “Adobe Flex”.
- Briefing sobre Flex;
- Desenvolvendo um aplicativo de visualização de imagens usando a API do Flickr em 5 minutos;
- Integrando Adobe Flex com Java;
- Desenvolvendo um Chat usando Flex Data Services em 5 munutos;
- Exemplos de aplicações desenvolvidas pela DClick com Flex.Os Palestrantes:
Beck Novaes: Especialista em desenvolvimento de Rich Internet Applications (RIA) com tecnologias Adobe; Bacharel em Ciências da Computação; Tem oito anos de experiência em desenvolvimento de aplicativos e trabalhou dois anos na Macromedia (adquirida pela Adobe) como Pré-Sales Enginner no Brasil e na América Latina.
Henrique Marino: Especialista em desenvolvimento de Rich Internet Applications (RIA) com tecnologias Adobe. Engenheiro Eletrico (POLI/USP); Sete anos de experiencia em desenvolvimento de software.
A DClick é uma empresa desenvolvedora de soluções voltadas ao segmento de Internet e Aplicativos Móveis, tais como telefones celulares, handhelds (PDAs) e smartphones. Especializada no conceito de usabilidade e facilidade na utilização de aplicativos web, tornando-a uma plataforma de desenvolvimento de aplicações semelhantes ao que encontramos em nossos desktops.
Conheci o Affonso da Dclick por intermédio do Paulo Silveira. Infelizmente não sei se vou poder ir (trabalhar na Barra é complicado…) mas certamente é uma ótima oportunidade para entender melhor o que a dona do Photoshop e do Flash pensa do futuro (ou do presente!) das aplicações web.
Mais informações: http://www.riojug.org/conteudo.jsp?id=571
A apostila de Spring do curso que começa terça-feira 7/11 foi atualizada. Os dois novos capítulos introduzem a teoria básica por trás de AOP e mostram como utilizá-la no Spring Framework.
A idéia é que você aprenda não apenas a configurar arquivos XML e escrever receitas de bolo mas compreenda o que o Spring faz para ser tão interessante. AOP e interceptores são como o framework (e diversos outros como EJB 3.0 e Hibernate) consegue dar todo o poder de um EJB para um simples POJO. Não sabe o que é POJO? Aguarde mais capítulos ou, melhor ainda, inscreva-se no curso!
Se você correr ainda pode participar desta turma, temos as 2 últimas vagas ainda em aberto. Não sei quando vai ser a próxima turma no Rio de Janeiro, então se você se interessa pelo tema não deve perder a oportunidade! Para verificar se o investimento (que, vamos e venhamos, é bem pequeno) compensa dê uma olhada neste material, que é a base do curso.
A pedidos deve ser aberta uma turma do curso em São Paulo em breve.
Há alguns meses eu passei por dias bem corridos. Precisávamos fazer a entrega de um grande produto e, como sempre, tudo resolve acontecer nos últimos dias, resultando numa lista de bugs que precisam ser corrigidos. O maior problema desta lista era um bug aparentemente simples, um include JSP que não funcionava. Acotnece que este código foi herdado de uma famosa empresa indiana CMM nível 5 e, como tal, está uma porcaria.
Como não havia tempo para refatorar o sistema (diria que 90% dele precisava mudar, isso caracteriza reescrita ou ainda posso chamar de refactoring?), tivemos que trabalhar com o que tínhamos em mãos. E o que tínhamos em mãos era: enderecodosistema.empresa.com.br, o endereço do próprio servidor. Essa era aúnica mensagem de erro, na verdade era algo assim que aparecia no log:
javax.servlet.ServletException: enderecodosistema.empresa.com.br
at atg.portal.framework.taglib.RenderPreparedGearTag.doStartTag()
at jsp_servlet._templates._claclacal._html.__full._jspService()
at weblogic.servlet.jsp.JspBase.service()V(Optimized Method)
at weblogic.servlet.internal(Optimized Method)
...
Detalhe que o erro só ocorria no servidor de produção, justo o que não podíamos manipular sem preecncher 15 formulários em várias vias. Após olhar o código (cada mais fundo que eu ia mais palavrões soltava e minha cara de espanto atraía os transeuntes) eu percebi que o sistema era baseado num padrão de projeto muito famoso em empresas, principalmente as consultorias com CMM, chamado “Vamos-Comer-Esta-Exceção-Com-Farinha”.
O código era mais ou menos assim (claro que isso era copiado e colado algumas milhares de vezes por todo o código, modularidade para quê?):
try{
algumaCoisaQualquer();
}
catch(Exception e){
String msg = e.getMessage();
throw new BussinesRuleException(msg);
}
Muito bom! Nossa mensagem simplesmente podia ser QUALQUER coisa. O tipo da exceção foi perdido, a stacktrace foi perdido… a única coisa que ficou foi o CMM nível 5.
Solução? Primeiro tentamos adicionar mais debugging. Isso podia dar certo mas ia demorar uma semana para conseguirmos colocar o sistema em produção com um log decente (i.e. StackTraces), fora o tempo de correção após termos descoberto o que acotnecia. Como o problema só ocorria em produção, um bom ponto de partida seria verificar se tudo que está neste servidor está em outros (o pessoal de infra sempre diz que tá, maaaas…).
Compara daqui, compara de lá e… dezenas de biblitoecas com versões diferentes. Uma coisa interessante é que haviam duas versões do Jalarta Commons HttpClient, removemos a versão anterior, consolidamos todas as bibliotecas, configurações e DataSources e… nada!
Após a derrota na hipótese das versões de bibliotecas, estava almoçando com meu chefe enquanto fazíamos uma chamada para os gerentes que podiam autorizar nossa versão com log melhorado ir para produção quando me deu um estalo. Ora, se tem HTTP client neste sistema e se a mensagem de erro é o hostname… ELE ESTA TENTANDO FAZER UMA CONEXÃO HTTP LOOPBACK! Acontece que o sistema estava em pré-produção, logo seu DNS não estava registrado. Aquela exceção só podia ser algo do tipo new HostNotFoundException("enderecodosistema.empresa.com.br");.
Relendo todo o código, suspeita confirmada. Uma linha no /etc/hosts e o sistema estava pronto para entrar em produção.
Agora, por que raios ele se conectava a ele mesmo? Lendo direito eu percebi que um dos programadores CMM nível 5 utilizava uma JSP para gerar um arquivo XML que era transformado via XSLT em HTML. Ou seja: ele precisava se conectar novamente para dar um GET na página JSP que retornava o arquivo! Ele usava uma tecnologia utilizada para criar HTML (JSP) apr agerar um XML que era transformado em HTML!
Qualquer API de XML meia-boca vai te dar um método que retorna o XML gerado como uma String mas acho que nosso amigo CMM nível 5 não sabia ler JavaDocs em inglês.
Eu poderia tentar concluir com uma reflexão sobre o design de aplicações, umas dicas básicas para trabalhar com XMl em uma aplicação web ou sei lá o que, mas em vez disso eu vou terminar com uma lição simples: cuidado com as mensagens das suas exceções, você nunca vai saber quando uma consultoria CMM nível 5 vai utilizar seu código.
Faça sua mensagem de exceção contêr pelo menos alguma coisa de útil caso não haja stacktraces nem o tipo da exceção esteja disponível. Eu sei que no caso reportado o problema não foi da API (afinal, HostNotFoundException: “host not found enderecodosistema.empresa.com.br” é, no mínimo, prolixo) mas pense que nem todas as pessoas que vão usar seu código são programadores, alguns são apenas CMM nível 5.