Xucros

Participamos!

Sobre o Dash: É um campeonato de Django, onde o seu time tem que construir uma aplicação Django funcional em 48 horas. Ele aconteceu das 2 da manhã de sábado 30/maio até as 2 da manhã de segunda 1/junho.

Porque entrei nessa? Simplesmente por que venho estudando Python desde algum tempo atrás. Não pretendo abandonar o Ruby e o Rails, só acho perfeitamente possível trabalhar com as duas linguagens e os dois frameworks. Chamei o povo pelo Twitter e o @lpirola me procurou uns dias depois. Alguns minutos de conversa depois, eu, ele, o @wilerson e o @ottohenrique estávamos cadastrados.

Resolvemos fazer uma aplicação similar ao orangotag. Resolvemos homenageá-lo, chamando de gorillatag. Diferente do orangotag, o gorilla é um tracker de filmes. O esquema é bem simples: você se cadastra, adiciona seus amigos, e marca os filmes como assistidos. Daí, nos feeds rss dos seus amigos aparece um item avisando que você viu o filme em questão. Você também pode comentar filmes e deixar mensagens para os usuários.

Pra deixar as coisas mais interessantes, eu nunca tinha usado Django. Ninguém tinha. E acho que alguns deles nunca tinham usado Python também. Mas tudo isso acabou sendo um fator positivo.

Nós entregamos a aplicação. O que já é um ponto positivo. Mas perto da concorrência, fomos mal. Muito mal. Agora temos o que olhar e comparar.

Depois de 48 horas usando Django, posso fazer uma comparação simplista de alguns pontos bons e não tão bons, em comparação ao Rails:

• Schema: O Django não mantém histórico das mudanças no banco. Tirando operações básicas como criar tabelas, ele não faz muita coisa. Se você adiciona um atributo a um model, tem rodar um comando do django que imprime o schema na tela. Daí você pega esse esquema e atualiza no seu banco de dados. Bem diferente das migrations do Rails.
• Models: No Django os atributos reconhecidos por ele tem que ser declarados no model. Isso é bom em relação aos models do Rails porque você tem tudo num lugar só, não depende de plugins que olham o schema e colocam os campos em comentário, por exemplo.
• Performance: Sejamos sinceros: Python está num nível de maturidade bem maior do que o Ruby. A performance dele chega a assustar depois que você passa um ano e alguns meses usando Ruby. Ele “compila” os seus scripts em arquivos .pyc. Os arquivos “compilados” são carregados mais rapidamente pela virtual machine, mas não alteram a velocidade de execução. Mesmo assim é uma ajuda tremenda.
• Django “environment”: Uma das coisas que difere bastante o Django do Rails é a forma como eles tratam o “ambiente”. No Rails, pondo as coisas nos lugares certos, você sempre tem tudo à disposição, carregados certinho. No Django você precisa importar tudo. Vai usar um model numa view? Precisa importar. Vai usar coisas simples como datetime? import. Posso estar falando besteira, mas não carregar as coisas pode ser um motivo para a velocidade do shell do django e outras coisas ser tão mais rápido do que o equivalente no Rails.
• Plugins: O Django vem com uma engine de autenticação out-of-the-box, que te deixa plugar um model de “profile” nela. Vem também com um models de comentários, sendo que as instâncias desse model podem ser associadas a qualquer outro model do Django. E ainda tem mais: implementar feeds rss é simples ao ponto de criar uma classe, implementar os métodos de título, link, descrição e items e pronto. Creio que isso tudo aconteceu pelo fato do Django ter nascido dentro de um jornal.

Vamos esperar umas duas semanas até sair os resultados do campeonato. Estamos pensando em continuar com o projeto e lançar um beta. Aguardem.