Site: musta.sh
Código fonte: GitHub

Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed. The FriendFeed application is written using a web framework that looks a bit like web.py or Google’s webapp, but with additional tools and optimizations to take advantage of the underlying non-blocking infrastructure.

Muita gente reclamou pelo fato do FriendFeed não ter procurado o pessoal do Twisted, pois desde os primórdios já era a lib padrão pra programar servidores assíncronos em Python. Ao invés disso, os caras do FriendFeed postaram coisas reclamando do Twisted – que era lento, mal documentado, etc; tudo que ainda reclamam nos dias de hoje. Veja aqui o anúncio do lançamento do Tornado, por Bret Taylor.

O fato é que o Tornado usava um IO loop próprio, e era bem mais rápido que a API nativa do Twisted pra web, Twisted Web. Além disso, o Tornado era baseado no framework que se chamava de anti-framework, web.py, por ser absurdamente simples. Mais ainda, o próprio Google havia publicado no mesmo ano o App Engine, que também era baseado no web.py. O resultado é que escrever um web service usando Tornado era muito mais interessante e obviamente mais simples que usar o Twisted Web.

Mas, como quase tudo, o Tornado tinha um grande problema: nenhum protocolo nativo do Python funcionava naquele IO loop. Nem mesmo coisas básicas como fazer uma query em DNS, ou acessar um PostgreSQL. O Twisted, já naquela época, tinha uma lista enorme de protocolos nativos, todos implementados pro IO loop do Twisted, e ainda mais protocolos que a própria lib padrão do Python. Protocolos como IRC, SSH, e suporte nativo pra qualquer database suportado pela DB API do Python, todos podiam ser mixados de maneira assíncrona no mesmo app, e coisas alucinantes podiam acontecer dentro de um web server.

Mas, justamente o protocolo HTTP era implementado pro Twisted Web, e o grupo de pessoas que cuidava disso havia criado o que seria um framework completo pra desenvolver aplicativos web, chamado Divmod. Por isso, eles não deram muita atenção pro Tornado, e pareciam focados nos componentes do Divmod que incluíam entre outros, até um sistema de banco de dados alternativo.

Dois dias depois do anúncio do Tornado, o glyph (cara que criou o Twisted) publicou um texto em seu blog dizendo o que ele gostaria que o Tornado fosse. Esse texto fez com que várias pessoas ficassem reclamando e chorando na teia, tipo esse post aqui.

Naquela época, eu estava desenvolvendo algumas coisas com Twisted Web, e obviamente fui testar o Tornado. No #twisted da freenode havia mais gente como eu, e o que mais havia progredido com algo interessante era um cara chamado Dustin Sallings. Ao invés de ficar chorando, ele havia portado o Tornado pra Twisted. Era exatamente o que deveria ter sido desde o começo. Em algumas conversas, ele havia dito que “estava pronto”.

Então, nasceu o cyclone. O motivo era simples: o Twisted Web era uma API pra criar web servers, e muito bagunçado pra criar web apps. O Tornado, era uma API muito decente, mas servia apenas pra criar web apps, sem suporte a nenhum outro protocolo além de HTTP. O cyclone, um mix dos dois: a API do Tornado pra criar web apps, mas que interagem com todos bancos de dados possíveis, e ainda todos protocolos do Twisted – incluindo os protocolos que se comunicam com sub-sistemas de telefonia.

Nos seus 2 anos de vida, o cyclone evoluiu muito. Muita gente contribuiu, mandou patch, arrumou bugs, adicionou coisas… e recebo alguns emails por semana de gente que usa e gosta, e agradece por ter algo como o cyclone disponível. Além de ser extremamente estável, passou a ter suporte nativo a sqlite, redis, mongodb, e uma gigantesca lista de features – tem até uma API semelhante à do bottle como opção. Coisas muito interessantes como o Nuswit, o RestMQ e o FreeGeoIP são baseados no cyclone.

Finalmente, peguei o domínio e o Gleicon comandou no site: cyclone.io

Agora vou atrás do calendário compartilhado do Brasileirão 2011.

Com o Spark Daemon, costumo criar uns atalhos (shortcuts) que executam código Apple Script, específico por aplicativo.

No Safari, por exemplo, os shortcuts Cmd+1 até Cmd+9 servem pra mudar a aba (tab) do browser, usando este código:

tell front window of application "Safari" to set current tab to tab 1

No Terminal, mesma coisa…

tell front window of application "Terminal" to set selected tab to tab 1

E ainda, o shortcut Cmd+Shift+M pra maximizar apenas na vertical:

tell application "Finder"
	set _b to bounds of window of desktop
end tell

tell application "Terminal"
	tell front window
		set {_x, _y, _w, _h} to (get bounds)
		set _vz to item 4 of _b
		set bounds to {_x, 10, _w, _vz}
	end tell
end tell

Os projetos de código aberto ficam normalmente hospedados no github. Também mantenho uma cópia na minha máquina do slicehost, que vai pro backup. Já os projetos de código proprietário, mando apenas pra minha máquina do slicehost.

Nessa máquina do slicehost, uso gitosis pra administrar o repositório. Ele é simples, prático, e funciona via ssh, o que é bem conveniente. Melhor ainda, é fácil de instalar e gerenciar, e usa o próprio git pra configurar o repositório. No README já tem toda a explicação sobre como instalar e gerenciar.

Se você está pensando em usar git também, e vem do svn, veja este link. O que posso te adiantar sobre o git, em relação ao svn (ou mesmo cvs, ou pior ainda, clearcase) é o seguinte: sistema de controle de versão offline é absurdamente mais produtivo. Especialmente no caso do git, criar e gerenciar diferentes branches é muito melhor, o merge entre diferentes branches ou até entre diferentes revisões (usando repositório remoto) é muito bom, e mesmo quando falha é bem simples de resolver. Tem todos os recursos que você já está acostumado, e os que precisa: tag, branch, archive.

Ainda é possível manter uma working copy local com git, e usar o repositório svn. Veja este manual. Se precisar usar git com clearcase, tem este e este link.

O manual do usuário (do kernel.org) é bem completo e cheio de exemplos. Também tem o video do Linus falando sobre o git no Tech Talk, no Google.

Considerando que o adbapi é apenas um wrapper do Python Database API v2.0 (PEP-249), obviamente existem motivos pra essa funcionalidade não estar lá (além da preguiça de alguns). No documento, o primeiro item do FAQ:

Question: 

       How can I construct a dictionary out of the tuples returned by
       .fetch*():

    Answer:

       There are several existing tools available which provide
       helpers for this task. Most of them use the approach of using
       the column names defined in the cursor attribute .description
       as basis for the keys in the row dictionary.

       Note that the reason for not extending the DB API specification
       to also support dictionary return values for the .fetch*()
       methods is that this approach has several drawbacks:

       * Some databases don't support case-sensitive column names or
         auto-convert them to all lowercase or all uppercase
         characters.

       * Columns in the result set which are generated by the query
         (e.g.  using SQL functions) don't map to table column names
         and databases usually generate names for these columns in a
         very database specific way.

       As a result, accessing the columns through dictionary keys
       varies between databases and makes writing portable code
       impossible.

Na busca por uma solução, até encontrei um patch pro twisted, que adiciona um método runQueryMapped e retorna uma lista de dicionários, como eu queria. Porém, aplicar patch no twisted é furada, pois o código só funcionaria nas máquinas cujo twisted tem o tal patch. Fora de cogitação.

A solução mais simples (e tosca) que encontrei foi a que funcionou melhor:

# coding: utf-8
# hack for twisted.enterprise.adbapi.ConnectionPool class, providing
# a new method mapQuery (just like runQuery) whose return value
# is a list of dictionaries that map column names to values.

from twisted.enterprise import adbapi

class hackPool(adbapi.ConnectionPool):
    def _mapQuery(self, trans, *args, **kw):
        trans.execute(*args, **kw)
        rs, new_rs = trans.fetchall(), []
        names = [d[0] for d in trans.description]
        for values in rs:
            row = dict()
            for k, v in zip(names, values):
                row[k] = v
            new_rs.append(row)
        return new_rs

    def mapQuery(self, *args, **kw):
        return self.runInteraction(self._mapQuery, *args, **kw)

Dessa maneira, o hack fica no próprio código e não requer nenhum patch. Dá-lhe gambi.

Já estou mais que convencido que o caminho pros próximos anos dessa década não pode ser outro, ainda mais com o WebSocket no w3c.

Para contribuir com a interwebs, tenho mantido os seguintes projetos:

http://github.com/fiorix/cyclone
Um clone do Tornado, webserver assíncrono do FriendFeed, que desde o ano passado é do Facebook. Essa implementação, batizada de Cyclone, tem algumas diferenças:

• Core I/O baseado no Twisted
• Suporte nativo a XMLRPC
• Suporte a localização baseada no gettext – ao invés do CSV, original do Tornado

Com vários aplicativos de exemplos, todos os plug-ins do Tornado para autenticação no Google, Twitter, Facebook, OAuth, OpenID, etc…

O RestMQ (coisas do Gleicon, que ajudei a implementar) é baseado nele. A nova versão do Nuswit também será.

http://github.com/fiorix/twisted-twitter-stream
Uma API bem simples para acessar a Streaming API do Twitter. Provê suporte a todos os métodos publicados pela API.

Não depende do TwistedWeb, a implementação do HTTP 1.1 está inteira no código – na verdade, apenas o lado do client com suporte a Comet.

Permite criar sistemas como este.

http://github.com/fiorix/txredisapi
Um driver assíncrono pro Redis, também baseado no Twisted. O protocolo de comunicação já existia, mas era carente de algumas coisas, que implementei:

• Métodos de conexão com Auto-Reconnect
• Lazy Connections (para usar em web servers)
• Connection Pools
• Sharding baseado em Consistent Hashing (+Gleicon)
• Sharding com Connection Pools

Além de estável, é muito rápido! Também foi usado no RestMQ, e aparentemente, está se tornando popular. Hoje achei algumas referências enquanto procurava no Google.

http://github.com/fiorix/mongo-async-python-driver
Outro driver de banco de dados, pro MongoDB. O driver original para Python é síncrono, o que dificulta (embora não impossibilita) de usar em sistemas assíncronos, especialmente baseados no Twisted.

Boa parte da implementação é baseada no pymongo original, inclusive o codec de BSON (em C), formato binário usado pelo Mongo, baseado em JSON.

Provavelmente se tornará o driver assíncrono oficial do Mongo para Python+Twisted, e está em vias de se tornar estável – isso devido às várias mudanças na API, e implementação de vários recursos incluindo Lazy Connections, e Document Reference.

Também, já tem algumas pessoas de olho no GitHub, acompanhando o desenvolvimento.

Entre os vários dbs nosql (couch, redis, etc) o Mongo é um dos mais completos, com uma linguagem de query muito decente, entre os vários outros recursos nativos. O fato de usar mmap para acessar os dados também faz com que ele seja muito rápido.

A foto amarela e sem foco é cortesia do iPhone.

cash:~ lame$ sudo sysctl machdep.cpu
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Core(TM)2 Duo CPU     E8335  @ 2.66GHz
machdep.cpu.features:  FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM SSE3 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1

O boot é realmente rápido, e logo aparece a primeira tela: login. Procurei um pouco e descobri que o usuário e senha é o mesmo do Google Accounts. Porém, não funcionou pra mim, e tudo que consegui foi um erro informando: Network not connected and offline login fail.

Usando a rede da máquina virtual como NAT ou Bridge, não fez com que o login funcionasse. Procurando mais um pouco, encontrei a solução: usuário chronos, sem senha.

Usei um pouco, procurei algo sobre configuração de resolução, e nada. Também, não há botão algum para desligar ou reiniciar o sistema operacional. Logo, procurando um pouco mais, descobri como abrir um terminal: Ctrl-Alt-T. É um linux, bem simples e pequeno, com a interface baseada em GTK, e o Chromium.

Nada especial, mas essa simplicidade é bem interessante.

Para virar root, pode-se usar o sudo, e a senha é chronos. Não tem muito o que fazer no terminal, apenas um sudo reboot ou sudo halt.

Curti.

Pra quem ainda não baixou o Chromium, aqui tem todos snapshots para os sistemas operacionais suportados: http://build.chromium.org/buildbot/snapshots/

Um dos casos onde um banco de dados baseado em objetos como o MongoDB se encaixa perfeitamente, é em um dos meus sistemas comerciais de telefonia, o Nuswit.

Lá, o usuário pode criar uma campanha de tele mensagem e colocar variáveis, que serão usadas para ligar para as pessoas e falar algumas coisas dinâmicas, sintetizando o texto em voz. Hoje, cada vez que o usuário cria uma campanha, pode importar uma planilha ou arquivo CSV, e então o sistema uma cria nova tabela no Sqlite com os campos que o usuário definiu na campanha, de acordo com essas tais variáveis.

Por isso, não é possível ter uma tabela estática, muito menos fazer relacionamentos pra usar a tabela no estilo chave=valor, pois essa mesma tabela é usada pros relatórios que o usuário baixa após o término da campanha.

Nesse caso, o MongoDB se encaixa perfeitamente. É muito mais simples criar uma coleção de dados com o mesmo nome da campanha, e importar documentos tipo JSON (nome=x, telefone=y, cpf=z) do que criar uma nova tabela com esses campos.

Além do mais, a API do pymongo é muito mais decente do que qualquer coisa parecida com SQL, pois os databases e collections são objetos do Python.

O único problema com o pymongo é que ele foi feito pra controlar e manter um pool de conexões com o banco, totalmente síncrono. Pra usar o pymongo em servidores como os que tenho feito ultimamente, assíncronos, baseados em Twisted, é necessário mandar todas as chamadas do banco pra um thread (usando callInThread ou deferToThread).

Pra solucionar esse problema, passei a frequentar o #mongodb na freenode, e em contato com o autor do pymongo, acabei criando uma versão assíncrona do driver, baseado em Twisted, que mantém o mesmo estilo da API original.

Agora, a integração entre Twisted e MongoDB está muito mais decente, usando pymonga.