Quem lê meu blog sabe que gosto muito de estratégias de cache, principalmente usando o famoso memcached.

Porém às vezes o cache do seu file system atrapalha. Em procedimentos de benchmark (principalmente de DB), no qual você quer analisar apenas uma das camadas de software, o ideal é desativar o cache. Você pode fazer isso setando algumas opções no /proc, desativando o cache pelo /etc/fstab ou melhor ainda: use o uncache!

A vantagem do uncache é 'descachear' arquivos específicos, sem alterar os outros arquivos do disco. Afinal, você pode querer desativar o cache dos arquivos de banco de dados (que deveriam estar num disco separado, pra aumentar o throughput), mas não desativar o cache do restante dos arquivos.

E o código fonte (em C) é muito pequeno. Mais um ponto positivo.

Esse é um dos melhores do livro.

O teaser envolve objetos reais. A decisão é sua se você vai fazer o teaser com os objetos na frente da pessoa ou se vai deixar o cara pensar de modo abstrato.

Entrevistador: Tenho um pequeno baú com uma aba que pode ser trancada com cadeado. Quero te mandar o conteúdo do baú de modo seguro através de uma transportadora (meio físico não-confiável). Obviamente, não faz muito sentido mandar o baú e depois mandar a chave do cadeado ('segredo' do cadeado fica comigo). Como fazer?

Uma resposta aceitável seria:

Mande-me o baú trancado com seu cadeado. Irei trancá-lo uma segunda vez com um cadeado meu e manderei o baú de volta. Você poderá destrancar o seu cadeado e mandar o baú novamente pra mim. Quando ele chegar, basta destrancar o meu cadeado e terei acesso ao conteúdo. Durante todo o tempo na transportadora, o baú permanecerá trancado.

Não sou muito fã de brain teasers em contratações, mas gosto de discutir sobre eles.

São gravações das palestras que rolaram na NOSQL, em São Francisco, em maio. São palestras de 40 minutos com diversos bancos de dados "do momento", como Hypertable, CouchDB, MongoDB, Voldemort.

Fiquei com vontade de organizar algo assim. Estou pensando seriamente no assunto. =)

Estou usando o Ubuntu 9.04 Jaunty Jackalope mas com ruby compilado por mim. Não estou usando os pacotes do Ubuntu. Mas quero usar o ImageMagick pelos pacotes do Ubuntu, sem ter que compilar o fonte.

Então...

sudo apt-get install libmagickcore-dev libmagick++-dev
sudo gem install rmagick

Happy coding!

Ainda quero comentar melhor sobre o Summit, mas fica pra outro post... aguardem... =D

Quando estávamos perto de começar o nosso trabalho no Pagestacker, ficamos sabendo de um torneio mundial de programação em que os participantes tinham que construir um aplicativo web do zero em exatamente 48 horas.

Achamos que seria uma boa idéia participar e, de fato, dentre cerca de 200 projetos concorrentes, chegamos muito perto de vencer, tendo recebido uma vasta votação do público e uma menção honrosa ao seu final.

O torneio se chama Rails Rumble e a sua edição seguinte começou neste último final de semana.

Como o idioma oficial do torneio é o inglês, o aplicativo precisava ter interfaces nesse idioma.

Você pode ver abaixo um vídeo, em inglês, com a demonstração dessa primeira versão do Pagestacker (a criação deste vídeo fazia parte dos requisitos da competição) e notar o quanto nós evoluímos desde então, apesar de a maior evolução ter ocorrido mesmo na arquitetura e nos componentes de sistema que ficam "sob o capô" do aplicativo.

httpv://www.youtube.com/watch?v=NRR-XegqI50

Por outro lado, como desenvolvedores brasileiros, não queríamos construir um software cuja interface não estivesse disponível também em português (não havia restrições quanto a isso) e foi assim que o Pagestacker ganhou telas em dois idiomas.

Mas, como eu disse, ainda não é isso que faz do Pagestacker poliglota...

O Desafio

Nossa interface em inglês e o destaque internacional (ainda que breve) decorrente do nosso resultado no Rails Rumble nos trouxeram uma ativa comunidade de usuários estrangeiros, principalmente nos Estados Unidos e na Índia.

Por causa disso, os resultados do nosso mecanismo de busca e os rankings de páginas e de sites mais populares no Pagestacker quase sempre mostravam links de diferentes idiomas na mesma tela, independentemente do idioma de interface escolhido pelo usuário.

Nossos usuários nos avisaram de que isso era um grande incômodo para eles (mesmo para os que falam bem os dois idiomas) e decidimos tomar uma providência.

Aprendendo a falar vários idiomas

Em nossa pesquisa por métodos de detecção automática de idiomas, encontramos alguns modelos interessantes (como o de bloom filters), mas nenhum deles atingia resultados completamente satisfatórios para nós.

Finalmente, descobrimos o método estatístico das n-grams através do artigo científico abaixo:
"N-Gram Bases Text Categorization", William B. Cavnar and John M. Trenkle (PDF Download)

Em seguida, procuramos por implementações desse método em software de código aberto (reuso de código é uma virtude).

Encontramos implementações em Perl e em C e fizemos testes de benchmark com elas. A primeira era até bem feita e tinha um índice de acerto razoável, mas era muito lenta. A segunda tinha uma boa performance, mas o algoritmo não estava bem implementado e por isso seus resultados deixavam a desejar.

Inconformados mas decididos, fizemos a nossa própria implementação. Para isso, usamos a linguagem Ruby (já que boa parte do Pagestacker é feita com o framework Ruby on Rails).

Resultados

Nossa implementação não só superou as demais nos mesmos testes de benchmark que tínhamos feito antes, tanto em performance como em taxa de acerto, como na verdade chegou a taxas de acerto muito próximas de 100%.

Alguns exemplos de resultados de testes abaixo:

>> "je suis an ingénieur".lang
=> [:fr] Francês
 
>> "お元気ですか".lang
=> [:ja] Japonês
 
>> "您好吗".lang
=> [:zh] Chinês
 
>> "idziemy".lang
=> [:pl] Polonês
 
>> "olla mundo".lang
=> [:es, :it] Espanhol, Italiano

No Pagestacker

Ao acessar o Pagestacker pela primeira vez, o idioma da interface que o usuário vê é definido pela sua localização geográfica.

Esse idioma pode ser facilmente alterado pelo usuário, se assim ele quiser, como indicado na imagem abaixo:

Além disso, durante o processo de criação da sua conta no Pagestacker, o usuário pode escolher o idioma da interface que quer ver quando estiver logado.

Daí em diante, sempre que o usuário voltar ao Pagestacker, o idioma da interface será aquele em uso na sua última visita (tenha ele criado uma conta, feito login ou nenhuma das duas ações).

Quanto ao idioma das páginas nos resultados de busca e nos rankings de páginas e de sites, ele é, a princípio, o mesmo idioma da interface. No entanto, o usuário pode expandir essa opção para incluir as páginas de todos os idiomas, como visto na figura abaixo:

Assim, sempre que o usuário desejar ver apenas as páginas em um dado idioma específico, ele só precisa mudar o idioma da interface tal como indicado na primeira das imagens.

No momento, apesar de já conseguirmos fazer a identificação automática de dezenas de idiomas, oferecemos interfaces apenas em Português e em Inglês.

Interfaces em mais idiomas estão a caminho. =D

Como o Google faz

Fizemos todo esse trabalho no Pagestacker de forma completamente independente e empírica, sem referências externas iniciais.

Pouco tempo depois de colocarmos esses resultados no ar, estivemos no evento do Google para webmasters, o Google Search Masters 2008, aqui mesmo em São Paulo.

Foi interessante descobrir durante uma das apresentações que a análise estatística com n-grams é utilizada também pelo Google e não só em seus serviços de tradução automática como também em outras funções como sugestão de correções ortográficas em termos de busca (aquele famoso "Você quis dizer:") e reconhecimento de comandos de voz.

http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html

Posteriormente, descobrimos que as n-grams são ainda empregadas em outras áreas como em seqüenciamento genômico.

Concluindo

Este post acabou ficando mais longo do que eu gostaria, mas não mais que o mínimo necessário para fazer justiça a mais essa "aventura" que tive a oportunidade de vivenciar no dia-a-dia do Pagestacker.

Acredito que isso ilustra bem os tipos de problemas com que nos deparamos e nossa forma de trabalho para resolvê-los.

Nossa preocupação número 1 é sempre a qualidade da experiência de uso do nosso aplicativo e não medimos esforços para maximizá-la a fim de tornar o Pagestacker útil e relevante para todos os usuários.

Nossa equipe ainda é pequena e por isso ainda não pudemos fazer tudo aquilo que temos em nossa lista de prioridades nesse sentido, mas estamos avançando de forma sistemática e constante.

Não sabemos de tudo, mas abordamos os problemas de uma forma empírica que freqüentemente tem nos levado a boas soluções (não raramente as melhores possíveis), como no exemplo acima.

Por fim, se você se identifica com esse tipo de rotina e essa forma de trabalho, pode me procurar. =D

O escopo do que fazemos envolve não apenas software, mas também hardware, network, estatística, matemática e usabilidade.

Estamos à procura de engenheiros (e de programadores, designers, estatísticos, matemáticos e cientistas da computação) com esse perfil para nos ajudar em nossa missão com o Pagestacker.

Ainda somos um time de apenas 5 pessoas. Estamos só começando. =D

Como exemplo, o comando top nos mostra:

top - 15:48:52 up 58 days, 23:14,  1 user,  load average: 0.13, 0.11, 0.07
Tasks:  85 total,   1 running,  84 sleeping,   0 stopped,   0 zombie

Na primeira linha, temos as três métricas do load. Já vou adiantando e dizendo que elas se referem a uma média de 5, 10 e 15 minutos da carga do computador.

Essa métrica é importante do ponto de vista de planejamento de operações de servidores e data centers. Contudo, é difícil obter mais informações de como essas métricas são obtidas.

O Neil Gunther, um pesquisador renomado em capacity planning e autor do excelente Guerrilla Capacity Planning publicou uma série de artigos sobre o load average no TeamQuest. Pra resumir um pouco, os pontos principais (fugindo um pouco do formalismo matemático):

Intuitavamente, aprendemos que devemos nos manter longe de números altos no load average. Mas ninguém sabe direito o quão alto.

O load aproxima a curva do tamanho da fila de processos no kernel (em estado RUNNING ou RUNNABLE). Como essa fila muda muito rapidamente, o load é, na verdade, uma média móvel com atenuação exponencial. Na verdade, isso é um filtro passa-baixas, muito comuns em engenharia elétrica. Ou melhor ainda, é um sistema de primeira ordem (para os engenheiros de controle de plantão) com diferentes constantes de tempo (5, 10 e 15min).

Exemplo do Load Average

Bem, não vou ficar repetindo o artigo todo. Quem tiver curiosidade de saber mais sobre esses números mágicos, os artigos principais são:

UNIX Load Average Part 1: How It Works

UNIX Load Average Part 2: Not Your Average Average

Boa leitura!

Além disso, o Hugo é criador da biblioteca Contacts, para acessar os webservices do Gmail, Hotmail e Yahoo Mail.

Confira aqui.

Ela consiste em realizar qualquer tarefa (job) mais pesada em termos de recursos computacionais em um processo ou até mesmo máquina separada, fora do workflow natural do seu aplicativo web.

Aprendemos isso desde o começo do Pagestacker. Na primeira versão, a que ficou pronta em 48 horas para o Rails Rumble 2007, a importação de itens do delicious era síncrona. Ou seja, assim que o usuário clicava em 'importar', o processo Rails acessava o webservice do delicious, baixava o XML, lia o arquivo todo e começava a processar cada item e adicionar ao Pagestacker.

Obviamente, se o usuário tivesse poucos itens no delicious, a importação funcionava sem problemas. Porém, se o cara tivesse mais de mil itens, o processo Rails demorava tanto que ele "esquecia" de responder ao navegador do usuário, e um erro de timeout ocorria (geralmente na conexão TCP do sistema operacional do usuário).

Uma das primeiras mudanças que fizemos após o Rails Rumble foi deixar esse processamento assíncrono. Agora, o processo Rails apenas baixa o XML do usuário e retorna à operação normal. Um outro processo, em background, cuida de ler esse XML e criar os bookmarks dentro do Pagestacker.

Temos portanto, três componentes fundamentais:

• o produtor, que vai gerar os jobs que serão executados;
• o consumidor, que vai executar os jobs;
• a fila, que é a "cola" (ou seja, a interface) entre o produtor e o consumidor.

Na minha opinião, o componente mais importante é a fila. Ela tem um trabalho crítico. Guardar as mensagens com os jobs a serem executados e distribuir essas mensagens quando for requisitada.

Um jeito simples de construir essa fila é guardando essas tarefas em uma tabela no banco de dados. Não é muito escalável, há alguns problemas de concorrência, mas é um jeito simples e em 99,9% dos casos o banco de dados já está lá pronto e rodando.

Para fugir de banco de dados, sugiro usar o Amazon Simple Queue Service (SQS). É parte da Amazon Web Services, o serviço de "cloud computing" da Amazon (isso mesmo, a livraria).

O SQS é, sem dúvida, o serviço mais simples da Amazon Web Services (AWS) e uma excelente forma de começar a usar a AWS. Mas não se deixe enganar pelo conceito simples, usar o SQS pode trazer benefícios enormes à sua aplicação.

Claro que você pode utilizar outros "gerenciadores de fila", como o beanstalkd, ActiveMessaging e mesmo o BackgroundRB. Mas ter mais um serviço rodando na sua infra pode ser trabalhoso demais. E o SQS aguenta muito tráfego. E, como eu já disse, é um jeito simples de começar a usar os serviços da Amazon.

Idempotência

Quando estiver programando sua lógica para funcionar assincronamente, é importante que seu código seja idempotente.

O que é isso? Simples. Às vezes, algumas mensagens podem ser processadas duas vezes. Seja porque a mensagem foi gravada duas vezes pelos produtores, seja porque o gerenciador de fila enviou a mesma mensagem duas vezes.

Seu código deve ser capaz de consumir a mesma mensagem diversas vezes e não "quebrar" por causa disso.

Uma característica interessante do SQS ligada à idempotência é que quando você lê uma mensagem da fila, você define um tempo no qual essa mensagem não será mais exibida. Ela ficará invisível por um tempo. Assim você pode processar a informação da mensagem (executá-la) e só depois apagar a mensagem da fila (geralmente antes que a mensagem fique "visível" novamente).

Conclusão

Usar o conceito de programação assíncrona será certamente um benefício dentro do seu código.

É interessante notar como um conceito simples como um gerenciador de fila pode mudar totalmente a forma como você constrói aplicativos.

A fila está gigante e os jobs estão acumulando? Lance mais consumidores. Simples assim, pois eles já estão configurados para ler da fila. Pode ser em outra máquina, ou até mesmo em outro datacenter.

Tenho mais alguns estudos de casos, mas isso eu deixo para quem for assistir à minha palestra no Rails Summit 2008, na semana que vem! =D

Íncrivel como você acaba canalizando sua vontade de escrever para um serviço que só te deixa escrever 140 caracteres de cada vez.

Mas agora estou voltando com o blog.

Stay tuned! (Enquanto isso, meu twitter é @georgeguimaraes =D ).