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.

Suponhamos este exemplo de formulário abaixo.

Detalhe importante: o formulário acima não parece complexo pois é um pequeno exemplo com alguns campos para ajudar no entendimento do artigo, seria inútil criar um enorme cadastro sendo que o importante é o princípio que vou demonstrar =D.

Antes de criar o layout de um formulário desse tipo, devemos nos fazer duas perguntas:

É um formulário que o usuário irá utilizar constantemente ?

Se a resposta for sim então imaginem um típico trabalhador de almoxarifado, ele recebe várias notas fiscais todos os dias para dar entrada no sistema, ele já conhece de cabo a rabo, na sequência, todos os campos a serem digitados. Ou seja, o formulário fica melhor se for cada campo e rótulo em uma linha, exatamente como no artigo anterior, para que ele faça tudo sempre na mesma sequência. Automatize isso na mente dele.

Se a resposta for não então voltemos ao exemplo do formulário acima. Vamos supor que ele esteja disponível ao público. Nesse caso, o formato tem que ser mais defensivo, deixar a pessoa informada sobre o que é preciso para preenchê-lo. Exemplo remodelado:

Cada rótulo e campo juntos ocupam uma linha sozinhos, todos os rótulos no mesmo alinhamento à esquerda, assim como os campos. O que vai acontecer aqui é o seguinte, o usuário vai prestar atenção primeiro no que está escrito nos rótulos. Indo de cima para baixo ele irá ler "nome, rg, cic, etc" sem dar a mínima atenção para os campos. Por consequência, ele irá se preparar para o preenchimento deles e até mesmo pensar: "preciso dos meus documentos antes de começar". Aí sim, ele volta ao início de tudo, presta atenção no rótulo na esquerda e preenche o campo na direita, desce uma linha e prossegue assim até o fim, na mesma sequência de movimentação dos olhos.

Se tivesse utilizado o esquema de layout do artigo anterior, a pessoa ia ter a leitura dos rótulos atrapalhada pelos campos, e não se "preparia" para o preenchimento, esse "preparo" forçado é bom pois o usuário nunca viu este formulário.

Há um espaço em branco entre cada rótulo e campo, procurem minimizar este espaço não colocando rótulos de comprimento muito desiguais, pois atrapalharia a concentração na leitura da esquerda para direita.

É um formulário que pode ser agrupado em formulários menores ?

No exemplo, observem que podemos agrupar os campos:

Em um grupo temos os dados pessoais e em outro grupo temos os dados de usuário. É muito importante fazer essa separação, mantêm o usuário focado em um pequeno assunto dentro do formulário. Procurem colocar uma demarcação visual para separar estes agrupamentos, sem nunca esquecer as regras de posicionamento dos campos, mesmo nestes formulários menores, mantenham um padrão.

Claro que podemos ajudar ainda mais, é imprescindível colocar pequenas dicas e ajudas de preenchimento, mas nosso foco aqui no artigo é posicionamento dos objetos no formulário, fica para um futuro artigo falar sobre estes pequenos auxílios visuais.

Vejamos um exemplo:

Parece um inocente formulário, dados simples e fáceis de serem preenchidos, mas por um momento tente mentalmente preencher este formulário. Normalmente nossos olhos vão de cima para baixo, da esquerda para direita, mas por algumas vezes voltamos para verificar se preenchemos os dados anteriores e quando terminamos essa verificação temos que lembrar onde paramos. Mesmo após preencher tudo não sabemos exatamente onde focar nossa atenção.

É muito comum encontrarmos formulários assim, o designer tenta preencher todos os buracos vazios na tela, criar uma estética simétrica, sem pensar que o usuário irá interagir com esses campos.

As normas da usabilidade recomendam a forma abaixo para expor os campos para preenchimento:

A mudança é simples, cada campo e rótulo (label) ocupa sozinho uma linha, o usuário fará apenas uma única leitura de cima para baixo, sem chances de dispersar os olhos. Ele lê o rótulo, preenche o campo e segue para o rótulo seguinte até chegar no botão enviar. Muito mais rápido para preenchimento, o usuário foca em uma única informação por vez.

Claro que ficou um buraco branco no formulário, mas se formos criativos no design, o buraco branco será facilmente disfarçado.

Lembrem-se, quanto mais rápido e fácil um usuário preencher um formulário, mais chance temos que ele compre nossos produtos =D. Preencher formulários é tedioso, se o usuário sentir que é difícil continuar com o preenchimento ele não vai pedir ajuda para a atendente online, vai simplesmente comprar no site do concorrente. Sempre que possível procurem fazer um teste com pessoas não técnicas para preenchimento de seus formulários.

O que demonstrei acima é válido para formulários rápidos e comuns, como preenchimento de endereço. Para formulários mais complexos a recomendação é outra, no próximo post vou continuar com esta explicação.

O livro para download gratuito é simplesmente simples e simpático e o modo como TDD é mostrado encanta.

Não entendo a insistência de muitos programadores em não criar testes, o tempo que se gasta agora criando testes vai impedir que vários erros e transtornos com o cliente surjam no futuro, o custo é muito menor agora.

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.

Como todo novato, apanhei feio no início, e é claro ainda estou tropeçando, mas o que mais me fez rir foi não ficar atento a filosofia do Rails de "convenção ao invés de configuração", ou seja, seguir padrões de nomes de métodos, classes, estrutura de diretórios, etc. Há um "jeito" certo de se estruturar o código seguindo esta filosofia, e quando você sai dela é que sua dor de cabeça começa, é normal encontrar pessoas zangadas com erros estranhos que só acontecem por não ter seguido as regras. As pessoas ficam bravas pois estão acostumados a seguir um modo rotineiro de estruturação. Bem estas pessoas que se adaptem às coisas novas. Pessoalmente se um framework segue "convenção ao invés de configuração" já consegue me atrair logo de cara pois eu entendo isso como "me faça ter menos trabalho pra utilizar você".

O meu erro foi ter "apenas" criado no modelo uma coluna com nome "type". O que eu não sabia, é que para o Rails, uma coluna "type", é reservada automaticamente para salvar o class-name do objeto na tabela, para caso você necessitar de um modelo de herança simples. Vamos supor um objeto Cachorro e outro Gato, ambas descendem do objeto Animal, mas há uma única tabela (Animal) para salvar Cachorro e Gato, a coluna "type" seria automaticamente preenchida com o class-name correspondente do objeto, para que ao consultar o registro, o Rails saiba que objeto deve criar. Óbvio que esta não era minha intenção, após ver sucessivas vezes o erro ":in `instance_eval': compile error" e consultar a documentação, descobri o motivo.

Não posso culpar o Rails, é um padrão dele, assim como outros nomes também são reservados como created_at e id, são os chamados MagicFieldNames. Resumindo: ao trabalhar com "convenção ao invés de configuração" lembrem-se sempre de olhar quais convenções são estas, vai te prevenir muitos erros e com certeza vai aumentar em muito sua produtividade, afinal o padrão está lá pra ser seguido.

Ah sim, caso você realmente precise de uma coluna chamada type para outros fins, basta sobrescrever o seguinte método no modelo:

def self.inheritance_column
"<nome da coluna a ser utilizada ao invés de type>"
end

Pronto, agora o Rails utilizará esta coluna para salvar o class-name e a type fica livre para fazer o que melhor convier, embora eu não recomende fazer isso.

Bom não tem jeito, Google ao resgate... minutos depois problema encontrado e resolvido, o que ocorre é um limitação imposta pelo próprio compilador, um método em Java pode ter um tamanho máximo de 65534 bytes, portanto quando o JSP era convertido em Servlet acabava gerando esse método monstrinho gordinho, mais informações sobre este e outros limites você encontra aqui na especificação da Virtual Machine.

Para resolver o problema foi necessário, adivinhem ? Simmmm, REFATORAR..... basta dividir o JSP em arquivos menores que façam mais sentido e uni-los com <jsp:include>. Para ajudar ainda mais não se esqueça de utilizar padrões web para o HTML gerado, mais tableless, o código fica muito mais enxuto, e quando possível, pense bem antes de criar uma tela com tantos dados, para uma melhor usabilidade.

Claro que, embora seja uma limitação imposta pelo compilador, NUNCA crie um método tão grande, isso vale para qualquer linguagem.

"Nelson, acho que aconteceu algum problema, o PDF abriu mas só tem uma página aqui!"

Pensei: "Bom enquanto ele não responde vou dar uma olhada na capa". Pra minha surpresa, ao vislumbrar a imagem abaixo, percebi que nada havia de errado com o arquivo, lá estava tudo o que precisava ser dito, ou no caso mostrado =D, sobre padrões em um página HTML.

Simples assim.

Tudo que eu já havia lido sobre padrões nessa área, tudo o que muitas pessoas de bom senso pregam como ideal, está aí. Ao invés de um calhamaço de 600 páginas, uma imagem que é compreendida em alguns segundos.

Javascript, CSS e HTML separados. Quem dera todos os designers fizessem isso, as vantagens são absurdas: menos consumo de banda, afinal os mesmos arquivos de CSS e Javascript serão usados em todos os outros arquivos HTML, reusabilidade e o principal, um padrão de separação entre o comportamento e apresentação da página, maravilhas das maravilhas para futuras manutenções. Basta apenas ligar os arquivos .css e .js com uma tag no arquivo HTML e pronto.

É claro que não poderia deixar de dar crédito a autora pela obra de arte.

Standards For Life

Preciso criar um cartaz bem grande com isso, talvez alguém olhe e crie juízo. =D

Óbvio que não é possível programar com a melhor flexibilidade e reusabilidade, aliás nem devemos tentar, como já disse Tony Hoare: "Premature optimization is the root of all evil" ("Otimização prematura é a raiz de todo mal"). Mas devemos sim estar atentos a código inútil, mal escrito ou ambos. É aí que entra o que considere o pior dos anti-patterns. O God object, o objeto que faz tudo, ele é onisciente, conhece a todos e todos dependem dele, assobia e chupa cana ao mesmo tempo, são classes com milhares de linhas, e o pior de tudo, assim como o próprio Deus, ninguém sabe de onde veio e nem para onde vai, mas com certeza levará todo o sistema junto em colapso.

Muito cuidado com esse tipo de objeto, se você notar que sua classe ou mesmo um único método está fazendo mais do que uma tarefa, pare... reflita... e RE-FA-TO-RE, nunca tenha medo de mexer no que está feito, lembre-se que alguns instantes refatorando lhe trará muitos benefícios no futuro.