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!

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.

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.

Os que odeiam, normalmente já odeiam Javascript também, e odeiam ainda mais quando os que amam exageram absurdamente no uso da técnica, conseguem fazer o site ficar inutilizável, uma usabilidade de dar medo, o teclado simplesmente não serve mais. E não me venham falar pra usar o mouse pois usabilidade é para todos os dispositivos. E o motivo principal de usar AJAX (desempenho), foi esquecido a muito tempo.

Dou certa razão para os que odeiam, a usabilidade é item prioritário na construção de um website, de que adianta ser lindo se não conseguimos utilizá-lo. Existem padrões web, utilize-os sempre na medida das possibilidades. Antes perder em semântica do que usabilidade.

Mas vamos lembrar primeiro que AJAX não é um framework, tecnologia, API ou biblioteca. AJAX é uma técnica que pode envolver o uso de várias tecnologias (Javascript, XML, DOM, etc), e pra espanto de vários, foi iniciativa da Microsoft, a própria criou o objeto XMLHttpRequest, responsável pelas requisições assíncronas, embora seja uma técnica que pode ser alcançada usando iFrames também.

Desempenho! Afinal banda de internet é cara, os serviços de hospedagem no Brasil que o digam... AJAX serve para melhorar o desempenho para todos, seja do sobrecarregado servidor ou do usuário que ainda utiliza modem (sem piadas, 53% dos internautas brasileiros ainda utilizam modem). Um bom exemplo de uso da técnica pode ser vista no sistema de creditar do Infoblogs, um simples clique e pronto lá foi o crédito, sem precisar que a página seja renderizada novamente para atualizar uma única tag, simples e ótimo para todos.

Agora um péssimo exemplo é quando temos mega formulários em alguns sites e o submit é uma chamada usando AJAX. Se não utilizar um framework decente, isso dá um trabalho enorme para implementar. E o que ganhamos com isso ? Mais manutenção, o ganho de desempenho é minúsculo. Os vários dados do formulário terão que ser enviados de qualquer forma, todo um processo de parse deve ser feito via javascript e parse de dados é algo que o próprio browser já faz naturalmente ao fazer o submit, ou seja, apenas processando à toa.

Então devemos pesar bem quando utilizar a técnica, pode até ser para algo bonitinho, mas vale mesmo a pena ganhar mais manutenção ? Pense sempre em desempenho e não perca a usabilidade de vista.

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.