Dreamhost Promocode REFATORANDO - até 97 dólares de desconto

Todos os dados na sessão, afinal memória é infinita

September 3rd, 2007 by Carlos Oliveira
Categorias: Boa prática, Anti-patterns, Padrões

O título é brincadeira, mas reflete bem a realidade, é muito comum encontrar aplicações web que simplesmente acreditam que todos os dados podem ser guardados na sessão. Que a medida que os usuários tem sua sessão invalidada, o garbage collector irá cuidar de destruir tudo.

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:

JAVA:
  1. session.setAttribute("customerId", id);

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.

Como uma mudança de cor me ajudou na usabilidade e a não refazer um layout

August 9th, 2007 by Carlos Oliveira
Categorias: Usabilidade, Boa prática

Quem diria que um layout pré-aprovado pelo cliente seria sumariamente rejeitado na entrega do layout final. Atônito, já pensava em refazê-lo. É dura a vida de freelancer, nem posso pedir a um estagiário que refaça =D.

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.

Deixe que o Apache processe todos os recursos estáticos

August 6th, 2007 by Carlos Oliveira
Categorias: Performance, Boa prática

Pagamos barato ao contratar um serviço de hospedagem em servidor compartilhado, mas também pagamos caro se não criarmos um aplicação enxuta. Por mais simples que seja cada requisição no servidor utiliza ciclos do processador e memória, se não tomarmos cuidado o servidor irá gentilmente matar nosso processo para o bem das demais aplicações.

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 :D) 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!