Django Utilidades :: Marinho Brandao

Oportunidade de trabalho para desenvolvedor Django

O Sérgio Oliveira publicou a seguinte oportunidade de trabalho:

A Interzone Entertainment está em busca de mais um membro para o seu time brasileiro de desenvolvedores web. No momento o time esta envolvido na integração do game Interzone Futebol com a página web http://www.interzonefutebol.com.br (Django).
Conhecimentos requeridos:

Python

Linux

SVN

Javascript

HTML/CSS (W3C standards)

SQL

Inglês (para leitura)

Conhecimentos desejados:

Django

Pylons

ORMs

JQuery

WSGI

PHP

Postgres

Shell Script

Inglês fluente

Sobre a Interzone Games: http://www.interzoneentertainment.com/about/

Interessados enviem o cv para sergio.campos@interzonegames.com com o assunto "Web/Python"

Criando Aplicações Plugáveis

Nos dias 18, 19 e 20 de setembro, estive na PyCon Brasil, participando das palestras excelentes que foram apresentadas por diversas pessoas-chave em assuntos relacionados direta ou indiretamente ao Python, Django, Pylons, TurboGears, Plone, Google App Engine, Zope e outros.

No sábado, fiz a apresentação da palestra "Django: Criando Aplicações Plugáveis" quando falei sobre a criação de aplicações reusáveis para Django.

Segue abaixo o documento dos slides. O Scribd permite ainda que você faça download em formato PDF. Para isso, basta logar

Django - criando aplicações plugáveis - Upload a Document to Scribd

Migrando do mod_python para o mod_wsgi

Já faz alguns meses que eu queria fazer alguns testes com o mod_wsgi, a alternativa ao mod_python que vem sendo cada vez mais comentada e sugerida na comunidade Django.

Ontem eu aproveitei o dia tranquilo pra unir o útil ao agradável e colocar isso em prática.

O que é WSGI?

Vamos "começar do começo": WSGI é mais simples do que parece, trata-se de uma interface definida pela PEP 333 [1] para intermediar a comunicação entre servidores web e frameworks Python. Ela surgiu pela necessidade qualquer um de nós nota com um pouco tempo: Python tem quilos de frameworksmuitas delas excelentes, e às vezes o mod_python parece ser um ornitorrinco em um ninho de coelhos quando implantamos alguns sites. É esquisito.

Mudando para o mod_wsgi

Para usar o WSGI puramente, é bastante simples, vamos fazer um pequeno script para ilustrar

def application(environ, start_response):
    status_code = '200 OK'
    headers = [('Content-Type', 'text/html')]

    start_response(status_code, headers)

    return ['So testando!']

from paste import httpserver
httpserver.serve(application, port='8000')

Ao executar este script minúsculo e carregar em seu navegador a URL "http://localhost:8000", será exibido "So testando". Simples não? Veja

$ python my_app.py
serving on http://127.0.0.1:8000

No Django, a coisa exige só um pouco mais de detalhes, mas nada complexo. Como já explanado há poucos dias pelo Eric, da Metaphormedia, em [2], é recomendável que se crie dentro de seu projeto uma pasta "apache" com um script dentro chamado "django.wsgi" - estes nomes são escolha sua, mas eles têm sido usados por mais de uma referência. Com o conteúdo abaixo (modificado segundo as suas necessidades)

#!/usr/bin/env python
import os, sys

sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)+'/../'))

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

E configure seu apache, removendo o código que implementa o mod_python e adicionando o seguinte

WSGIScriptAlias / /caminho/do/seu/projeto/apache/django.wsgi

Agora, para funcionar, é preciso que seu sistema operacional tenha o mod_wsgi instalado. No Ubuntu/Debian você instala com o seguinte comando

$ sudo apt-get install libapache2-mod-wsgi

Pronto, ao reiniciar o Apache, seu projeto estará lá, bonitão, rodando através do WSGI :)

Porque mod_wsgi?

Bom, essa deve ser a pergunta que você deve estar se fazendo. Se o mod_python sempre foi a alternativa recomendada e funciona bem, porque mudar para o mod_wsgi?

O mod_wsgi tem se comportado mais escalável que o mod_python. Por escalabilidade, entende-se a capacidade de um site de suportar o crescimento de uso sem perder a performance ou travar.

Ao ajustar um servidor para usar o mod_wsgi, pude notar essas diferenças. Elas não são tão grandes que se possa perceber com um simples teste com Apache Bench. É necessário forçar para notar a diferença, que tem sido até 10% superior.

Esse servidor que usei para fazer esses testes é uma VM (em Xen) com 512MB de RAM, rodando em um amd64, numa rede bastante estável, em Londres, enquanto que o Apache Bench foi executado em minha máquina.

Veja abaixo como os dois modos se comportaram:

Para compreender a legenda, o número após o "n" trata-se da quantidade de requisições enviadas e o número após o "c" trata-se da quantidade de requisições concorrentes, ou seja, "n1000c5" equivale a "1000 requisições enviadas de 5 em 5).

Tempo de resposta por requisição

Requisições por segundo

Load de 1 minuto

Load de 5 minutos

RSS / Memória real ocupada

Percentual da CPU

Conclusões

Todos os números apresentados acima não podem ser tomados como base exata para comparação, por alguns motivos, como a influência que o teste anterior efetua no subsequente, a oscilação da internet e a influência de outros processos.

Eu fiz questão de usar um servidor em produção onde está sendo servido um outro sistema da empresa, que mesmo que não estivesse em seu horário de pico, era usado normalmente por alguns usuários.

Há ainda toda a questão de controvérsias em torno do uso real da CPU e da memória.

Mas dá pra notar uma realidade clara: o mod_swgi se mostra mais vantajoso em memória e tempo de resposta. Não esqueçamos que 200 requisições concorrentes para um VPS com 512MB de RAM é uma senhora carga, equivalente a alguns milhões de pageviews por mês.

No teste de 2000 requisições a 200 concorrentes, ficou visível que a configuração de MaxRequestsPerChild (de 1000) entrou em cena e fez diferença no desempenho, tanto para segurar a carga quando para mudar um pouco a evolução do desempenho.

Por fim, devo avisar que no teste seguinte, de 5000 requisições a 200 concorrentes, o Apache caiu antes de completar 3000, em 3 tentativas.

Mais detalhes sobre o WSGI podem ser encontrados em [4], [5] e [6]

Links relacionados

[1]	http://www.python.org/dev/peps/pep-0333/

[2]	http://www.ericholscher.com/blog/2008/jul/8/setting-django-and-mod_wsgi/

[3]	http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

[4]	http://www.slideshare.net/hdiogenes/wsgi-a-resposta-para-a-questo-definitiva-sobre-python-a-web-e-tudo-mais-368429?src=embed

[5]	http://en.wikipedia.org/wiki/Wsgi

[6]	http://www.wsgi.org/wsgi/

[7]	http://del.icio.us/marinho/wsgi

Yadsel - Status

Bom, muita correria nos últimos dias. Pouco tempo para publicar qualquer coisa, mas o Yadsel, o Guia de Django e o Adorador.es estão vivos como nunca. Neste momento a prioridade é o Yadsel, por motivos de urgência em alguns aplicativos reais, em produção. O Guia segue caminhando para a conclusão e já com alguns contatos sobre publicação em curso. O Adorador.es também está de pé, esperando tempo hábil para atualização da versão 0.3. O Yadsel ainda está registrado como versão 0.1-unstable. Ainda que o nome impressione imaturidade, o software está caminhando para uma relativa maturidade, essencialmente sobre o driver de Firebird. Os drivers para MySQL e SQLite também foram melhorados e foi introduzido o driver para MSSQL (SQL Server). O foco é deixar toda a framework e core API maduras e partir daí para atacar os drivers em andamento, sempre preocupado com cases reais, nunca com teorias. A arquitetura está muito boa, minha impressão é de que superamos as espectativas, pois todas as manutenções necessárias até agora foram extremamente simples e claras, e o software está com uma performance também melhor que o esperado. Destaques das últimas tarefas efetuadas: yadseltool

para sistema operacional Windows, agora ofecere um executável standalone para poder ser embutido em aplicações sem necessidade da máquina virtual.
melhorado toda a forma de interpretar os argumentos, agora em forma de atribuição.
oferece agora 4 modos: hidden (persiste sem exibir mensagens), output (apenas escreve o script na tela, sem persistência), steps (persiste exibindo uma mensagem de progresso a cada etapa), interactive (confirma cada etapa antes de persistir - não implementado ainda)
agora suporta modo de teste - sem persistência
agora suporta controle do histórico embutido

HistoryControl

Recurso para embutir controle das atualizações. Antes este controle era feito externamente, pelo utilizador.

PartialVersions

Foi implementado o recurso de partial versions - conceito semelhante ao PartialClass, do Delphi - através do qual se pode quebrar uma só versão em várias classes e arquivos, juntando tudo numa Version só. Muito bom para situações de script completo ou grandes modificações.

ZipFile

O suporte a arquivos ZIP como repositório das versões foi liberado e será até mesmo recomendado, dado que é mais seguro e limpo.

DocTests

Alguns doctests foram criados para automatizar os testes de funcionalidades básicas:

PartialVersions
Persistencia
ZipFiles

GTKYadsel Uma ferramenta de manutenção de projetos foi criada para auxiliar o desenvolvedor e, num futuro ideal, tornar desnecessário o conhecimento de programação a quem for construir modelos de banco. Esta ferramenta trabalho no sentido de construir projetos e dar a ele uma ou mais conexões, ao qual também se pode adicionar versões e editar em um editor com highlight de sintaxe. Evidentemente, funciona melhor no Linux, mas a screenshot abaixo, tirada sob o Windows, demosntra que ele pode ser eficaz em qualquer ambiente. Ainda não está bom o suficiente para recomendar o uso, mas eu já o uso normalmente.

FullVersionBuilder Por fim, este também é um recurso cada vez mais estável. A versão completa de um dos casos reais onde o Yadsel é utilizado foi toda gerada a partir deste, com pequenos ajustes posteriores relacionados a valores DateTime. Conclusão Como podem ver, o Yadsel caminhou a passos largos. O tempo disponível não é grande, é realmente curto, mas está indo muito bem. Espero soltar a versão 0.2-stable rapidamente, ainda esta semana provavelmente. Boa sorte para todos nós!

Vagas na Visie

A Visie está precisando de gente que domine Python, Ruby e PHP. Se quiser dar uma olhada, clique aqui.

DBMigrations será YADSEL

O project DBMigrations terá o nome definitivo de "yadsel", sigla de "Yet Another Database Schema Evolution Library". O motivo para eu tomar esta decisão se deve ao fato de que o nome antigo era provisório e também porque descobri que já existia um projeto com o mesmo nome.

DBMigrations 0.1

A versão 0.1 do DBMigrations já está disponível [1]. Muito distante do que o que o escopo propõe [2], mas já me serve e deve servir para você também. Esta versão oferece:

CoreAPI num nível bem avaçando; [3]
MySQL Driver; [4]
SQLite Driver; [5]
Driver genérico, para implementar ANSI SQL / SQL-99 [6]
Alguns exemplos e testes, bem tímidos, mas podem ser úteis [7]

A novidade é que o Andrews [8] entrou no projeto e vai cuidar dos drivers de Oracle e Postgres. O próximos passos serão:

Efetuar conexão e rodar o script gerado na sequencia certa;
Implementar a funcionalidade de gerar o script da primeira versão a partir de um banco existente (desafio);
Disponibilizar um driver pra Django, o mais transparente possível;
além, é claro do que a participação do Andrews e mais alguém gerir :)

Links relacionados:

DBMigrations

Publiquei a seguinte mensagem nas listas python-brasil e django-brasil:

Saudações!

senhores, como eu havia comentado há uns dias atrás, estive
trabalhando em um "migrations" para um projeto em Django e outro em
Delphi.

criei então o DBMigrations (ainda não tive idéia para um nome melhor),
que é basicamente uma ferramenta que pode ser usada como executável ou
como modulo de um software em Python, para controle de evolução de
bancos de dados, sob a LGPL, e independente de ORMs e SGBDs e que
possa ser útil para projetos feitos em outras linguagens.

a notação é mais ou menos semelhante ao Active Record Migrations, do Rails.

ele fornece um grupo de classes (uma espécie de API), que é
interpretada por um driver (por enquanto somente o MySQL está
implementado, os proximos serão o Firebird e o SQLite), e este driver
aplica as especificidades de cada SGBD.

da forma como ficou estruturado, ele permite que sejam criados drivers
para ORMs, como Django, SQLAlchemy ou SQLite, etc.

a primeira versão (0.1) ainda não foi devidamente testada, pois irei
utiliza-la oficialmente amanhã, numa virada de versão. E ainda não
suporta stored procs, triggers, views, sequences ou indices (este
ultimo não concluído).

o repositório do projeto é:

http://code.google.com/p/dbmigrations/

quem gostar da idéia e tiver interesse em participar, principalmente
criando drivers, será bem-vindo :)

espero que seja útil.

É “identado” ou “edentado”?

O assunto rendeu debate por aqui. A Wikipedia diz que ambas as formas estão corretas. E ainda estou com a pulga atrás da orelha... Mas o que importa é que o Python é uma linguagem semântica, que obriga o desenvolvedor a organizar seu código atravás da edentação. E você, o que me diz? Identação ou edentação?

Python: agilidade e robustez

Montei esta apresentação para um seminário que teremos no sábado e achei que pode ser de seu interesse.

Python - Agilidade e Robustez A finalidade é mostrar o que é o Python, dar uma primeira pitada sobre o Django e argumentar porque eu acredito que o futuro reserva uma boa posição para quem adotá-las. Boa leitura.

OpenID: de onde vem e para onde vai?

Como (nem todos nós sabemos) o OpenId tem caminhado lentamente mas tem conquistado sólidos apoios, e aos poucos vai conseguindo atingir seu objetivo. Para quem ainda não sabe do que se trata, o OpenId é um projeto criado pelos caras do LiveJournal que tem a finalidade de unificar contas de acesso espalhadas na rede em uma identificação única por usuário, possibilitando que este se passe por facetas diferentes, segundo a sua preferência. Digamos que é paradoxalmente uma forma descentralizada de centralizar a identificação do usuário. Este modelo apresenta muitas vantagens e desafios novos, assim como perguntas desconfiadas como: "será que isso é confiável?", que é uma questão que deve ser conferida ao seu servidor do OpenId, já que o projeto apenas especifica as metas e o protocolo, mas quem os implementa são servidores espalhados pelo mundo. E assim, como poucos sabem, se você já possui uma conta no WordPress, a sua url (sim, da mesma forma que a minha é http://marinho.wordpress.com) é uma identificação para OpenId. Atualmente o serviço mais conhecido de servidor de identificações é o MyOpenID. Acontece que, como toda idéia recém-nascida, o projeto depende de ser implementado, preferencialmente por grandes empresas (leia-se Google, Microsoft, Yahoo e mais uma meia-dúzia de mega-corporações) para que se alavanque. O primeiro serviço popular a adotá-lo além dos criadores foi o Technorati - o que não é nenhuma novidade porque aqueles meninos adoram uma inovação, e eles geralmente acertam na mosca. Depois foi a vez de ver o Zoomr e o WordPress, mas nada ainda se compara ao anúncio da Microsoft de que passaria a apoiá-lo, o que levou a marca do projeto a vários noticiários mais populares do meio tecnológico e acabou incentivando muitas pessoas a conhecê-lo e adotá-lo. Já é possível pesquisar em um diretório, quais são os serviços da rede que suportam o protocolo e esta lista aumenta cada dia mais, e as incertezas vão sendo sanadas aos poucos, à medida que a idéia é compreendida por mais pessoas. E para a nossa alegria, já existe uma forma (muito fácil, como tudo o que envolve o framework) de se implementar OpenId no Django que você pode encontrar nos endereços abaixo:

Para mais informações:

“Não aguento mais Java”

Bom, antes que derramem em cima de mim toda a fúria religiosa pró-Java, vou me explicando: este post é apenas um resumo de algumas mensagens na lista Python-Brasil, que podem ser vistas em sua totalidade aqui. Mas a minha opinião está bem próxima da média vista abaixo. decopzp: " A galera nas faculdades no meio de programação so fala em Java. Queria saber como começar a aprender Python, gostei muito só que estou com algumas duvidas em relação a classes methodos e etc...Na verdade que saber tudo como fazer o que fazer...Não aguento mais java" Luciano Ramalho: "Em Java, existe uma aberração sintática chamada "inner classes" que foi parida para suprir a grotesca falta de um jeito de se passar funções como parâmetros. Apenas uma das diversas falhas gritantes de projeto da linguagem Java. Mas é uma ótima linguagem para quem está em busca de um emprego chato. Agora sério: Java é um excelente substituto para C++. Empresas e instittuições que antes desenvolviam em C++ agora têm uma alternativa mais segura e confiável para seus projetos. Faz todo o sentido a Apache Foundation e a IBM usarem Java, por exemplo. O grande erro que muitas empresas no mercado estão cometendo é substituir linguagens de mais alto nível por Java, e achando que a queda de produtividade é apenas passageira, enquanto a equipe não ganha fluência na linguagem." Rodrigo Senra: " No contexto particular de ensino *introdutório* de programação, eu diria que Java como primeira linguagem é no mínimo nocivo. > Java está na moda. Piercing também está. Fumar já esteve na moda. Particularmente eu não sou um cara que liga para a moda. Prefiro mais a média, ou até mesmo a mediana ;o) Em suma, o fato de Java estar na moda para mim só não é irrelevante porque me atrapalha. Atrapalha pois tenho que convencer semi-leigos de que o fato de Java estar na moda é irrelevante ;o) Eu não digo para o Padre qual vai ser o sermão, eu não digo para o padeiro como fazer o pão nem para o médico qual o tratamento que quero receber antes dele dar o diagnóstico. O computeiro, apesar do nome cacofônico, merece respeito. Uma tecnologia ditada pela moda, e não fundamentada pela análise prática e teórica, é uma falta de respeito para a nossa classe. > Ela é uma otima linguagem Aqui concordo, ela tem seu nicho e suas vantagens. E ainda é melhor que *muita* linguagem por aí. > Vamos com calma. Python está sendo usada em cursos > introdutorios de programação pois é uma linguagem de fácil acesso... > mas isso nao quer dizer que seja a melhor linguagem do mundo. Melhor é um conceito extremamente dependente de contexto. No contexto de ensino introdutório, ainda não vi nada melhor do que Python." Luciano Ramalho: "tenho plena consciência de que existem milhões de programadores brilhantes que preferem Java. Mas eu não resisto a uma oportunidade de criticar o Java, exatamente porque "está na moda". Isso tem duas consequências lamentáveis, a meu ver: (1) muitos gerentes que não sabem distinguir uma referência de um ponteiro escolhem Java para projetos que poderiam ser muito melhor resolvidos em PHP, Python, Ruby, Perl, VBScript etc, e acabam submetendo equipes inteiras de desenvolvedores a uma linguagem e uma API que são otimizadas para projetos imensos e complexos, e consequentemente acabam induzindo projetos pequenos e simples a ficarem imensos e complexos também. (2) é tão sofrido aprender e ficar produtivo em Java que muitos de programadores estão ficando sem vontade de aprender uma segunda, terceira ou quarta linguagem, com medo de passar pelo mesmo calvário de novo; pior, depois de suar tanto a camisa para aprender Java, muitos se convencem de que complexidade == qualidade, e que uma linguagem mais fácil de usar, como Python, tem que ser necessariamente inferior ou mais limitada, o que absolutamente não é verdade." Luciano Ramalho: " > E como ensinar herança múltipla, sobrecarga de operadores e tipagem > dinâmica em uma linguagem que não os suporta/não os tem? Sua lista de conceitos de OO está contaminada por uma perspectiva javista, Gleidson. Smalltalk, a primeira e até hoje uma das melhores linguagens orientadas a objeto já criadas tem tipagem dinâmica e não tem interfaces. C++ tem sobrecarga de operadores e não tem interfaces. Ninguém pode dizer que Smalltalk e C++ não são exemplos de linguagens orientadas a objetos (*). Enfim, o que é essencial em uma linguagem orientada a objetos? A resposta não é simples, nem única. > A questão do Java é meio que a popularidade dele. Sim, é o que eu tenho dito: a popularidade do Java é ao mesmo tempo sua maior virtude e seu maior defeito. O defeito está no fato de qua a "popularidade" está levando milhares de empresas a usarem Java para desenolver aplicações que seriam feitas de forma muito mais simples com uma linguagem mais ágil, como Python, Ruby, Perl ou até mesmo PHP e VBScript. > É fácil achar um > computador que tenha um ambiente java instalado. Agora vai achar um que > tenha o python instalado pra poder rodar os programas? A Microsoft parou de distribuir Java com o XP, lembra? Há anos o Java perdeu a vantagem de sair pré-instalado em milhões de máquinas Windows. No Linux, praticamente qualquer distribuição vem com Python, mas não com Java. E no MacOS X vem as duas. > Fora que em Python não é compilado, então tens que > dar o código-fonte para que alguém possa rodar seu programa. Não é verdade. Python é compilado para um bytecode, assim como o Java. E eu posso distribuir este bytecode em vez do fonte. Mas existem ferramentas capazes de regenerar o código-fonte a partir do bytecode, tanto no caso do Java quanto no caso do Python. De qualquer forma, para 90% dos desenvolvedores essa questão é irrelevante, porque não somos pagos para produzir software proprietário que vai ser vendido em caixinhas, e sim para desenvolver soluções customizadas para clientes, internos ou externos, que exigem o fonte de qualquer maneira." Luciano Ramalho: " > Ninguém pode dizer que Smalltalk e C++ não são exemplos de linguagens > orientadas a objetos (*). Faltou explicar o (*)... O Alan Kay, líder da equipe que criou Smalltalk, uma vez disse: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." "Eu inventei o termo Orientado a Objetos, e posso lhe dizer que não estava pensando em C++." Se tem alguém que pode dizer o que é ou deixa de ser OO, é o Alan Kay." Luciano Ramalho: "Gleidson, talvez vc não saiba ou passou batido, mas interfaces são uma gambiarra no java para fornecer herança multipla. A unica coisa que é bom em interfaces é que elas fornecem duck typing para java, o que não é necessario em python justamente por causa da tipagem dinamica." PS: bom, só pra não deixar em branco, estas frases foram tiradas de uma discussão na lista de Python, e eu destaquei as argumentações pró-Python, porque evidentemente sou usuário e divulgador desta linguagem. As pessoas citadas acima disseram estas frases no contexto de forma muito ponderada, e obviamente não podem ser mal-interpretadas (da mesma forma que deve acontecer com comunidades de quaisquer outra linguagens). Na minha opinião, a informática é uma ciência que oferece ferramentas para facilitar o dia-a-dia. E ferramentas são assim: uma hora você precisa do martelo, outra hora do porrete, o martelo sozinho não resolve as coisas, ele precisa de um prego, uma tábua e do principal: o carpiteiro. Um carpinteiro qualificado saberia fazer com o martelo o mesmo que se faria com o porrete, e vice-versa, porque ele está preparado pra fazer aquilo. Outra metáfora que pode ilustrar aqui é o de comparar um sedã, uma scania e um trator. Digamos que o Python seja o sedã, o Java seja a scania e o C seja o trator: cada um tem sua aplicabilidade.

PythonWare usa Django

Tive uma grata surpresa ontem ao notar que o site da PythonWare foi migrado para Django.

O que falta ao Rails e ao Django para o cheque-mate

Nos últimos meses temos visto uma locomotiva atropelar paradigmas antigos, linguagens "perfeitas" e conceitos tidos como clássicos. Na verdade a locomotiva já existia há tempos... o que faltava eram os trilhos. Pois agora não falta mais: o Ruby on Rails é a grande coisa dos últimos anos em assunto de programação e deve permanecer assim por bastante tempo. Com a mesma disposição - mesmo que em doses leves - a cobrinha do Python vem "picando" uma boa parcela do mercado há anos, tanto que pouco percebem que ela já está em todo lugar, seja com o aclamado Ubuntu, seja nos bastidores do Google e do YouTube, seja nas manchetes da Microsoft. Ela está lá, criaram uma pista de dança e botaram a cobra pra dançar, e como ela dança bem, aos passos de Django. Estamos vivendo hoje um período muito semelhante ao de cerca de 10 anos atrás, quando o Java aparecia e o C# era anunciado no Slashdot, pela primeira vez, mas Ruby e Python possuem uma qualidade que Java e .Net não possuem: elas se amam. Enquanto a maioria dos "embates" sobre Java e .Net terminam com alguns mortos e muitos feridos, Ruby e Python sempre terminam com lições apreendidas e trocas de elogios. É a maturidade no ambiente do desenvolvimento. E, é claro, existe espaço também para o Java, o C#, o PHP, etc... Pois bem, mas então, se a sentença já está dada, porquê essa constância em afirmá-la? A resposta é simples: porque não há sentença, nada está garantido. Da mesma forma que há 10 anos atrás, o momento é de suposições - bem embasadas, é claro - mas ainda há muito caminho a trilhar (e muita música pra dançar). E existem algumas características, digamos "básicas", que estas duas maravilhas frameworks precisam conquistar, para que convençam nossos patrões de que elas são eficazes como cantamos a todo momento. Portanto, bolei a lista abaixo com o que eu acredito ser o que falta para o Rails e para o Django - observando que sou um "djanger" falando sobre Rails, portanto, qualquer deslize, o espaço para comentários abaixo é ilimitado e democrático, ok? O que falta no Django

atualização do banco, através de controle de versões;
suporte a alguns SGBDs "coringas" do mercado
- SQL Server (não me fale de adodb que me dá calafrios)
- Oracle
- DB2
- Firebird
um pouco mais de clareza sobre o MVC (o mercado adora patterns);
uma definição melhor sobre widgets e forms em ajax - o newforms foi uma evolução, mas está longe de ser um AjaxScaffold;
melhor suporte a SOAP;
um repositório de contribs à là RailsLodge ou CodePLex;
uma maior comunidade brasileira;

O que falta no Rails

compilação em bytecode, para proteção do código;

O que falta nos dois

um gerador de relatórios;
grandes cases;
um bom recurso para chamadas SQL de valores agregados (sum, avg, min, max, count) e agrupados (group by);
um bom recurso para chamadas SQL de união (union);
planos de hospedagem em provedores mais populares, como a LocaWeb, por exemplo;

Bom, como você pode ver, eu tenho mais a dizer sobre o Django do que sobre o Rails, mas mesmo que eu fosse expert nos dois, é explícito que o Rails está alguns passos à frente (ainda que "explícito" seja uma característica mais marcante no Django do que no Rails), mesmo que o Django venha evoluindo rapidamente. Uma afirmação que não posso deixar passar vagamente, é que nossa comunidade Django Brasil, está funcionando cada vez melhor em seu embrião, portanto, ela precisa crescer, mas ela está cada dia mais ativa. Por fim, acho que está bem claro que temos muito trabalho pela frente, mas contando com as duas frameworks que temos em mãos, o trabalho é bem mais gostoso e rápido do que seria antigamente! Update: este artigo está concorrendo um livro sobre Rails, que o Nando Vieira está promovendo em seu SimplesIdeias.com.br