Desde que foi lançado, tenho observado o número de “Plus” recebidos pelo painel do Webmaster Tools.

Lembro-me de ter ficado impressionado com a quantidade de webmasters que votavam no sistema a cada dia. De 30k saltou para 42k, para 68k e assim por diante: uma avalanche de votos. Eis que há alguns dias o número não passa de 120 mil. Estaremos nos aproximando do número total de usuários do WT? Ou é apenas uma pequena pausa?

Há alguns dias venho recebendo erros 500 Internal Server Error do principal servidor Apache hospedado em instância EC2 do Amazon Web Services.

Não se tratava de um “bug da manhã” do MySQL porque haviam conexões suficientes ao servidor de banco de dados para manter o handle DBH válido.

O erro aparentava ser aleatório, não era relacionado a uma página específica, ou uma query mais longa. Às vezes ocorria logo que o servidor era reiniciado, às vezes tardava em ocorrer. Um tipo problema realmente difícil de diagnosticar porque é um “alvo móvel”, nem sempre acontece, e quando acontece não há uma causa clara.

Algumas das mensagens encontradas no log de erros do Apache incluiam:

DBI Connection failed
ou
Can't connect to MySQL server on [...]
ou
DBI Connection failed: Lost connection to MySQL server at 'reading authorization packet', system error: 0 at [...]


Após algumas horas de testes, cheguei a relatórios de “bugs” do MySQL, a maioria dos quais eram apenas pedidos de suporte técnico onde o MySQL levava a culpa, e o pedido era “mascarado” de um bug no sistema.

O problema era a latência de rede do EC2 da Amazon. Já havia ouvido falar no assunto, porém não tinha tido problemas no passado. Aparentemente os mega-servidores XEN podem ter seus altos e baixos também, e a “conversa de rede” entre milhões de instâncias virtuais pode ficar um pouco lenta.

Aumentando o timeout de rede do servidor MySQL para conexão e leitura solutionou o problema.

Editando a seção [mysqld] do /etc/my.cnf, inserí:

connect_timeout=30
net_read_timeout=45


E pronto.

Nota: O problema em exagerar o timeout, como exagerei acima elevando o tempo máximo para conexão a 30 segundos, é que em caso de falha pode-se criar uma imensa fila(“backlog”) de conexões aguardando decorrer o timeout para serem canceladas. No caso de uma rede local de velocidade aceitável, jamais precisei modificar o valor padrão de 5 segundos. Porém, em uma rede virtualizada como aquela do Amazon EC2 a latência de rede pode se tornar um problema. Deve haver um equilibrio entre um timeout seguro para não haver erros e que, porém, não cause enormes filas para conexão. Posteriormente reduzí o timeout a 8 segundos e ficou tudo ok. Três segundos à mais eram a margem de erro que precisava para a latência da rede Amazon.

As dicas de SEO em inglês podem todas serem aplicadas à lingua Portuguesa. Só que, devemos nos atentar para algumas peculiaridades que nossa lingua traz à arte de otimizar sites para sistemas de busca.

Um detalhe a ser observado é a acentuação. Para tanto, vamos usar um exemplo prático. Veja a diferença entre as buscas abaixo.

Compare com esta:

Observe que:

• Há 300 mil páginas a mais na versão acentuada.
• Os resultados são completamente diferentes.
• Não acentuei a palavra Kaka e o Google reconheceu que era o Jogador

O que isso significa? O leitor poderá observar mais fatos interessantes sobre a diferença nos resultados de acordo com a acentuação, porém, tenho em mente algumas conclusões.

1. É possível deixar de acentuar algumas palavras menos conhecidas para competir com menos sites.
2. O Google possui um Tesauro com sinônimos de palavras mais conhecidas, como Kaka.
3. A busca é binária, ou seja, maca e maçã são inteiramente diferentes.

E você, enxergou mais alguma dica para compartilhar sobre acentuação nos resultados de busca?

O marketeiro que inventou isto ou está podre de rico, ou é perseguido pelas ruas por onde anda. Talvez ambos.

Buscando aprender mais sobre o HTML 5 e o componente Canvas, realizei um pequeno experimento com trajetórias balísticas.

O script é bastante simples. Após inicializar um canvas com 800×400 pixels, o Prototype dispara o evento dom:loaded. O handler deste evento prepara o canvas com um degradê inteiramente feito via Javascript, e liga o botão “Shoot” em um handler para desenhar no Canvas a trajetória balística de um projétil com a velocidade e o ângulo desejado.

Não há tempo real, portanto não inserí unidades. A velocidade seria m/s na vida real, porém não tendo referência poderiamos criar qualquer unidade. O movimento também recebeu ampliação de 2x no sentido horizontal, de modo a deixar mais harmônico com o canvas 800×400. A variável de proporção pode ser alterada apenas ajustando a largura e altura do canvas no código Javascript. Estas medidas poderiam ser lidas diretamente do canvas, sem serem hard coded no Javascript – fica aí como sugestão.