Este tipo de problema não existiria se a aplicação fosse usada por alguns poucos usuários. Tentem imaginar centenas de atendentes de telemarketing, trabalhando continuamente, entrando em todas as telas possíveis do sistema, executando todo o tipo de ações, e em cada ação mais e mais dados na sessão que somente serão retirados após 6 horas de jornada de trabalho (ou pelo menos deveriam ser 6 horas perante a lei trabalhista, não vou entras nestes detalhes =D). Mas e aí, nestas condições, quanto tempo até chegarmos a um OutOfMemory ?

É muito fácil colocar algo na sessão, por exemplo a lista de cidades de um estado, se a intenção é ajudar no desempenho, esta é a pior estratégia que se pode escolher. Para isso que existem excelentes técnicas de caching e várias bibliotecas que as implementam, a qual garantirá que existe apenas uma única lista em cache para qualquer usuário, além de implementar o padrão Observer para possíveis alterações na lista.

Claro que não estou dizendo que devemos banir o uso de sessões, muito pelo contrário, devemos usá-la, mas tome o cuidado de gerenciar o conteúdo. Um meio simples de se fazer isso é controlar todas as requisições via Servlet Filter em Java ou Filters em Rails, colocando/retirando dados conforme a necessidade.

Tão ruim quanto já colocar tudo na sessão é utilizar péssimas chaves, por exemplo:

Não sabemos de onde veio isso, para onde vai e pior ainda, alguma outra ação pode sobrescrever este valor. Sem uma identificação correta, nem um controle com filtros vai ajudá-lo.

Pensem duas vezes antes de usar o escopo session, em boa parte dos casos usar os escopos page e request é suficiente, analisem cada situação, vai tomar pouquíssimo tempo e cada bit de memória economizado é bem vindo. Há o velho pensamento: "Depois faço um profiling para eliminar alguns gargalos", isto só irá trazer várias dores de cabeça em um código session-macarrônico.

Antes de recomeçar, é sempre importante parar e pensar: "Onde está o erro, qual o problema desse layout ?", pense como seu cliente, como ele gosta de ver sites e como é o seu público. Foi exatamente o que fiz, percebi que o meu cliente e também o público alvo do website possuem pelo menos mais de 45 anos e segundo suas próprias palavras "Este site parece coisa de gente jovem!"

Voltando no tempo, nas aulas de IHC da faculdade, minha professora já tinha dito "Com o passar dos anos as pessoas vão ficando mais sensíveis às cores, portanto o vermelho que vemos hoje não é o mesmo que veremos amanhã, por isso os idosos acabam preferindo cores mais opacas", claro que há exceções, sempre existem idosos radicais =D

Na verdade o website não parecia muito de gente jovem, o problema foram as cores usadas que tinham tonalidades fortes para alguém mais velho.

Pois bem, lembrando disso minha alteração foi apenas abrir o CSS e diminuir as tonalidades das cores, deixa-as mais opacas e enviei ao cliente.

SUCESSO! Layout aprovado com honras. Nem perceberam que era o mesmo layout...

Portanto entendam seu cliente, pensem como ele, somente o cliente é capaz de fornecer dicas valiosas sobre o público alvo, depois disso façam o website pensando nesse público alvo. O conteúdo é a parte mais importante de um website, dedique sempre muito mais horas a isto mas não se esqueça da embalagem. Pensar em uma cor parece uma coisa boba, mas me salvou horas de retrabalho.

Recentemente tive problemas com um website na Dreamhost, o processo estava sendo sumariamente assassinado, a princípio estranhei, por ser uma aplicação simples em Rails e era feito cache de boa parte das páginas. Uma conversa com o suporte técnico e me disseram que o website em questão estava gastando muita memória.

Cinco minutos depois o Google (sempre ele ) já tinha uma solução para o meu caso. Eu simplesmente esqueci que existe o Apache para servir minha aplicação web. Para variar, bastaria alterar o bom e velho .htaccess. Estava acontecento o seguinte: todas as requisições de imagens, pdfs, htmls estáticos, rhtml, etc,... tudo que fosse estático ou dinâmico era processado pelo fastcgi em Ruby, que é claro fica dedicado a minha aplicação e possui um limite de memória para não prejudicar o servidor.

Com isso bastou algumas alterações no .htaccess para dizer ao Apache que cuide de processar todas as requisições de recursos estáticos:

RewriteCond %{REQUEST_URI} ^/images/(.*)$
RewriteCond %{REQUEST_URI} ^/javascripts/(.*)$
RewriteCond %{REQUEST_URI} ^/stylesheets/(.*)$
RewriteCond %{REQUEST_URI} ^/*.txt$
RewriteCond %{REQUEST_URI} ^/*.xml$
RewriteCond %{REQUEST_URI} ^/*.pdf$

E o problema foi resolvido, acompanhei os processos no servidor via ssh durante alguns dias e o uso de memória tinha diminuido assustadoramente, com isso tive tempo para estudar alguns outros detalhes para melhorar a aplicação.

Não tenho muita experiência em fazer melhorias no .htaccess, estejam a vontade para apontar outras melhorias.

E é isso, vou aproveitar e fazer uma propaganda da Dreamhost a qual até hoje só tenho elogios, muito eficientes e gentis no suporte, além do preço camarada e muita banda. A quem estiver interessado em criar uma conta por lá e ganhar um desconto de até 97 dólares, podem utilizar meu código de promoção: REFATORANDO. Que me desculpem aqueles que acham que blog não deveria ter propaganda, nada na vida é de graça ^_^

Uma boa semana a todos!

Observem o exemplo:

Algo que tem-se pregado por aí é retirar o totalmente o Javascript do HTML, ou seja, o exemplo acima ficaria assim:

E teríamos um arquivo .js com o seguinte código para ligar o evento onclick do button:

Puxa vida, toda essa volta só para não usar a propriedade onclick no HTML e se livrar totalmente do Javascript, isso vale a pena ?

Há vários motivos para que eu não concorde com isso:

• Mais código para dar manutenção, foram criadas várias linhas de javascript para algo que funcionaria no primeiro exemplo usando a propriedade onclick da tag input.
• E quando eu quiser saber qual evento o button aciona, será fácil de achar ? Podem haver vários objetos na página, todos com seus eventos ligados apenas no momento do onload da página. Vários objetos é igual a várias linhas de código javascript com as ligações, se você estiver usando um editor de textos comum, bem... boa sorte, e mesmo com uma IDE não é tão simples assim.
• A propriedade onclick, onkeypress, etc faz parte da especificação HTML, justamente para facilitar isso, porque iria deixar de usá-los ?

Então muito cuidado ao seguir padrões ao extremo, questione-os, cada um tem o seu lugar e hora certa.

Martin Fowler, em seu famoso livro Refactoring: Improving the design of Existing Code (em português "Refatoração: Aperfeiçoando o Projeto de Código Existente"), já dizia que refatorar é: "modificar um sistema de modo que seu comportamento não se altere, mas que sua arquitetura melhore, fique mais limpa". Um dos meus livros prediletos, praticamente livro de cabeceira. Inúmeras técnicas de como melhorar seu código.

É muito comum encontrarmos código duplicado, e mais comum ainda observar que o programador não reaproveitou o código porque precisava refatorá-lo, por puro medo de "quebrar" outra parte do sistema. Oras, pra isso existe TDD (Test Driven Development), se criássemos testes não haveria nenhum medo em quebrar outras partes do sistema, as quebras seriam imediatamente visíveis. E refatorar ficou ainda muito mais simples com as IDEs atuais, qualquer uma possui mecanismos poderosos para auxiliar esta tarefa.

Refatorar nosso código, mesmo código antigo, constitui menos manutenção no futuro, pois refatorar é também diminuir a complexidade e quantidade de código. As partes duplicadas no sistema, se contiverem quaisquer erro ou necessidade de mudança na regra de negócios, vai realmente tirar seu sono, pois obviamente nunca sabemos onde estão as cópias. Uma regra de negócio ou erro poderia ter sido resolvido com uma única "martelada" no lugar certo em um código "enxuto".

Então sem medo de refatorar, você não está perdendo tempo agora, está na verdade economizando tempo de manutenção.

O ponto onde quero chegar é que na maioria dos projetos que vejo, a documentação é escassa, não há tutoriais ou documentação sequer no código fonte.

Quanto a documentação em código, eu reconheço o que Rod Johnson, criador do Spring, sabiamente afirmou em seu célebre livro Expert One-on-One J2EE Design and Development, um código bem escrito, seguindo padrões claros, sem classes, métodos ou variáveis obscuros, não necessita de documentação, o código fala por si, qualquer programador olha e entende sem medo, mas isso serve somente para quem participa do projeto.

O problema é que ninguém está interessado em olhar dúzias e dúzias de classes para entender como usar. São necessários tutoriais e documentação farta para que consigamos manter alguém usando o que criamos, por melhor que ela seja.

O criador se desespera, óbvio que para muitos é maçante documentar código, mas é necessário, e não é preciso escrever duas vezes, uma em código e outra em documentação pública. São muitas as ferramentas que resolvem o problema. Mas lembre-se que é necessário documentar seguindo padrões, para o pessoal de Java, use JavaDoc, embora limitado/criticado por muitos, é muito fácil de ser utilizado, quantos já não recorreram a documentação do JDK, alguém teria a paciência de ter lido o código ? Eu já tive que ler código várias vezes em muitos frameworks sem documentação, sendo que um mero comentário explicativo na documentação da classe teria resolvido o problema rapidamente.

Eu não sou muito fã da Microsoft, mas tenho que dar o braço a torcer, felizes os usuários do MSDN, quando necessito tirar uma dúvida quanto ao uso de CSS, HTML, ou outras áreas relacionadas, vou direto nele, tudo bem explicado e com ótimos exemplos. A Microsoft pode até não abrir o código fonte de suas ferramentas, mas ela compensa muito bem isso fornecendo aos seus usuários toda a documentação necessária para utilizá-la.

Então na próxima vez que alguém reclamar que seu framework é complicado, para e pense um pouco? "Será que tenho bons tutoriais e documentação ? Será que descrevi de forma concisa o que ele faz ?". Não espere que o usuário simplesmente baixe e fique tentando adivinhar como usar, não o chame de estúpido, o código do framework/biblioteca é simples para você que criou.

O usuário terá que perder um tempo precioso estudando, e a não ser que seja algo revolucionário, existem alternativas para vários frameworks/bibliotecas. Temos que aprender a cada dia, cada vez mais, não temos tempo a perder tentando adivinhar o que foi codificado. Queremos algo claro e rápido, bem documentado, para finalmente decidir se vale a pena investir tempo.

Pois bem, o problema foi ocasionado durante testes de migração pra o JBoss 4.x, a inicialização do DWR estava falhando, não conseguia de forma alguma encontrar as classes informadas em seu arquivo de configuração xml, o famigerado NoClassDefFoundError, algo que não apresentava problemas no JBoss 3.x. Após olhar em empacotamento, meta-infs, jars, configurações do JBoss, nada, nenhuma pista, nem o Google ajudou. O jeito foi descer mais fundo, ler o código fonte do DWR. A linha onde o erro ocorre, executa apenas um carregamento de classe:

this.classDefinition = Class.forName(className) ;

A classe é guardada para que possa ser instanciada por reflexão posteriormente, o interessante é que tudo isso ocorre na inicialização do JBoss, depois que a aplicação levanta, tentamos via debugger, executar o mesmo comando e voilá... funcionava perfeitamente... o que raios estava acontecendo ? Não sabíamos....

Bom, não teve jeito, a classe do DWR teve de ser alterada para testar outra possibilidade de carregamento. Com isso trocamos a linha para:

this.classDefinition = Thread.currentThread().getContextClassLoader().loadClass(className);

Linha monstruosa.... mas funcionou!

Boa prática aprendida: o Class.forName() não sobe na hierarquia de ClassLoader, fica apenas no ClassLoader local, enquanto o ClassLoader.loadClass() sim, ou seja, por questão de robustez e boa prática, sempre utilize a segunda forma, para não ficar com cara de "ué", quando este tipo de problema surgir.

Mas por que no JBoss 3.x funcionava e no 4.x não ? A resposta é que o ClassLoader o 4.x foi reescrito para ficar mais aderente as especificações, com isso o Class.forName() pegou todo mundo desprevinido, houve claras reclamações da comunidade, mas temos que viver com isso..., existem práticas a serem seguidas.

Ainda bem que não tivemos que usar o código alterado do DWR, estávamos na versão 1.1.3, por curiosidade, baixei a versão estável mais recente (1.1.4) e pra minha grata surpresa essa linha já havia sido alterada do mesmo modo que fizemos , só fiquei chateado por essa alteração não estar presente no release notes, teria me economizado tempo durante busca por pistas...