Livro sobre C e Linux

Hoje decidi abrir uma exceção e postar esse link aqui. É um livro que escrevi há 9 anos e nunca foi revisado nem publicado, mas que ainda pode ser útil para muitos novos programadores.

 


It’s all over.

Current blog is http://musta.sh


cyclone ganha um site: cyclone.io

Há pouco mais de 2 anos atrás, o FriendFeed havia sido comprado pelo Facebook, e uma das coisas mais interessantes pra nós, na época, foi a publicação do web server que eles haviam desenvolvido para uso interno. Era Setembro de 2009.
Sua descrição permanece a mesma até hoje:

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


Puts! Só de pensar que já fiz crawler pra classificação do brasileirão… e agora o globoesporte.com tem isso: classificacao.json

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


Spark Daemon no OSX

Sem isso dai não rola usar nem o Safari nem o Terminal.

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

como eu uso o git

Faz tempo que não escrevo aqui. Nesse meio tempo estive em 3 países diferentes, e muita aconteceu. Agora chegou a hora de um post simples e rápido sobre como tenho usado o git, que talvez ajude muita gente.

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.


twisted adbapi: nomes de colunas em query

Quem já usou o twisted.enterprise.adbapi deve ter notado a falta de uma funcionalidade muitas vezes necessária na execução de queries (SELECT) no banco, seja ele qual for: colocar o nome das colunas no resultado, de forma que cada linha seja um dicionário e não um simples set.

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.