Felizmente, Django é um dos poucos frameworks web que tornam este um problema simples de solucionar.

Como resolvemos este problema

Um jeito simples é criar um módulo settings.py separado para a versão “mobile”. Isso nos permite rodar dois sites diferentes reusando a mesma base de código. Além disso, cada versão pode ter seu próprio diretório de templates, configurações de URL, etc.

Vamos fazer isso. No diretório-raíz do projeto, crie um arquivo m_settings.py com o seguinte conteúdo:

# Arquivo: myproject/m_settings.py
 
"""Configurações para a versão "mobile" do website.
"""
 
# Carrega as configurações padrão
from settings import *
 
# Domínio "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Usado em outras partes do código para determinar qual versão está rodando
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs para a versão mobile
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates para a versão mobile
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Outras configurações...

O fato de os dois sites compartilharem a mesma base de código não significa que eles devem ter as mesmas configurações de URL. Aliás, o normal é que versões próprias para dispositivos móveis sejam mais simples, com uma quantidade reduzida de mapeamentos de URLs.

Para definir as configurações de URL da versão mobile, crie um arquivo m_urls.py com o seguinte conteúdo:

# Arquivo: myproject/m_urls.py
 
"""Mapeamentos de URL para a versão "mobile".
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# URLs
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Apps internas
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Outras configurações...
)

Perceba que, neste exemplo em particular, a app Admin não é acessível através da versão mobile. Isso apenas serve para mostrar que temos total liberdade para estruturar ambas as versões de diferentes formas, sem muitas dificuldades.

Desenvolvendo

Você certamente já sabe como rodar o servidor de desenvolvimento para a versão padrão. O que a maioria dos desenvolvedores desconhece, entretanto, é que é possível escolher qual a porta e/ou módulo settings.py deve ser usado pelo script, o que nos permite rodar um servidor para cada versão do nosso site:

# Terminal 1: versão padrão
$ python manage.py runserver 8000
 
# Terminal 2: versão mobile
$ python manage.py runserver --settings=m_settings 8001

Pronto, agora é só continuar com o desenvolvimento da forma que você já está acostumado.

Testando

Você provavelmente notou que temos duas configurações que podem ser usadas para determinar qual versão do site está rodando, DEFAULT_VERSION e MOBILE_VERSION.

Por isso, é só uma questão de checar tais configurações quando for necessário fazer coisas diferentes em cada uma das versões do site. Isso é particularmente útil quando você tem uma app usada em ambas as versões e quer criar testes para cada uma das versões:

# Arquivo: myproject/myapp/tests/__init__.py
 
"""Testes para MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Testa a versão padrão
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Testa a versão mobile
    from mobile_models_tests import *
    from mobile_navigation_tests import *

Você pode rodar os testes para cada versão de uma forma semelhante a que fizemos com o comando runserver:

# Versão padrão
$ python manage.py test [appname...]
 
# Versão mobile
$ python manage.py test --settings=m_settings [appname...]

Colocando em produção

Apesar do que você possa achar, esta é a parte fácil.

Uma vez que a forma recomendada de colocar Django em produção é com Apache e mod_wsgi, é possível que você já tenha um arquivo WSGI parecido com o seguinte:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Tudo que precisamos fazer é configurar um outro sub-domínio WSGI no nosso servidor (ex: m.mywebsite.com) que referencia o seguinte arquivo de configurações WSGI:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # Esta linha
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

A única diferença entre esses dois arquivos WSGI é que cada um aponta para um módulo settings.py diferente. E não, você não precisa ter uma cópia do site para cada versão, afinal estamos usando a mesma base de código para ambas as versões, lembra?

Minimizando o tráfego

Por incrível que pareça, nem todo mundo dispõe de conexões ultra-rápidas. Por isso, é muito importante que você mantenha seus sites tão leves quanto possível.

Existem vários projetos open source que podem ajudar nessa parte. Um deles é o django-compress, uma app Django que fornece um sistema automatizado para compressão de arquivos CSS e JavaScript.

Aliás, não importa se seus websites são para dispositivos móveis ou não; você deve sempre tentar minimizar o tráfego.

O que falta?

Ainda temos um pequeno problema: quando alguém visita a versão padrão do site através de um dispositivo móvel, ou vice-versa, eles não são redirecionados para a versão apropriada. Mas isso é assunto para um próximo artigo!

Exim é um MTA open source que pode ser usado como alternativa ao Sendmail em sistemas operacionais Unix. Eu não tenho idéia de qual é a melhor alternativa disponível, mas se você procura por um servidor de relay para instalar na sua configuração de desenvolvimento, Exim é provavelmente a opção mais simples para começar.

Neste artigo, veremos como configurar o Exim para enviar mensagens através do Gmail.

Instalando o Exim

Primeiro precisamos instalar o Exim e suas dependências, o que é algo bastante trivial em distribuições Linux modernas como Ubuntu/Debian:

$ sudo apt-get install exim4

Usando Exim como servidor de relay

Existe um assistente que nos ajuda a fazer as configurações básicas; rode o comando abaixo para abrí-lo e preencha cada tela como segue:

$ sudo dpkg-reconfigure exim4-config

1. General type of mail configuration: mail sent by smarthost; received via SMTP or fetchmail
2. System mail name: seudominio.com
3. IP-addresses to listen on for incoming connections: 127.0.0.1 ; ::1
4. Other destinations for which mail is accepted: Deixe em branco
5. Machines to relay mail for: Deixe em branco
6. Host name for the outgoing smarthost: smtp.gmail.com:587
7. Hide local mail name in outgoing mail: Yes
8. Visible domain name for local users: seudominio.com
9. Keep number of DNS-queries minimal: No
10. Delivery method for local mail: mbox format in /var/mail/
11. Split configuration into small files: Yes
12. Root and postmaster mail recipient: Deixe em branco

Agora precisamos configurar as credenciais do usuário no arquivo /etc/exim4/passwd.client adicionando a seguinte linha:

# Troque [username] e [password] pelos dados corretos
*.google.com:[username]:[password]

Agora basta rodar o comando abaixo para terminar as configurações:

$ sudo update-exim4.conf

Testando o servidor

Um jeito simples — e nerd — de testar se as configurações estão corretas é usar o comando telnet:

$ telnet localhost 25
    Trying ::1...
    Connected to localhost.
    Escape character is '^]'.
    220 localhost ESMTP Exim 4.71 Wed, 23 Jun 2010 22:28:56 -0300
HELO localhost
    250 localhost Hello localhost [::1]
MAIL FROM: usuario@seudominio.com
    250 OK
RCPT TO: destino@email.com
    250 Accepted
DATA
    354 Enter message, ending with "." on a line by itself
SUBJECT: Assunto da mensagem
Testando Exim via Telnet. Massa!
.
    250 OK id=1ORbG5-0005uh-EF
QUIT
    221 localhost closing connection
    Connection closed by foreign host.

Abra os arquivos de log em /var/log/exim4 para ver se a mensagem foi transmitida sem erros. Uma tentativa bem sucedida se parece com o seguinte:

2010-06-23 22:29:47 1ORbG5-0005uh-EF <= local@seudominio.com H=localhost [::1] P=smtp S=345
2010-06-23 22:29:50 1ORbG5-0005uh-EF => destino@email.com R=smarthost T=remote_smtp_smarthost H=gmail-smtp-msa.l.google.com [74.125.45.109] ..."
2010-06-23 22:29:50 1ORbG5-0005uh-EF Completed

Caso você não receba a mensagem e os logs não acusem nenhum erro, verifique se a mensagem não foi parar na caixa de spam antes que você mude quaisquer configurações.

O poder do Python

Quem não está acostumado a trabalhar com Django pode estranhar o fato deste utilizar um script Python para fazer a configuração do projeto: o famoso settings.py. E essa estranheza é justificada, afinal muitos desenvolvedores — principalmente os que vêm de outras linguagens — estão acostumados a trabalhar com ferramentas onde tal tarefa é feita com arquivos XML ou coisa assim.

O fato é que utilizar um script Python para tal é uma excelente idéia, pois você deixa de depender de algum tipo de estrutura estática (e muitas vezes inconveniente) para algo mais flexível e poderoso, que, no caso, é a própria linguagem de programação. Isso faz uma grande diferença em situações onde tal flexibilidade é necessária.

Quer exemplos?

Ambientes de desenvolvimento/produção

Eis como fizemos aqui. Primeiramente, defina a variável de ambiente WORKSPACE. No Linux, isso pode ser feito através do arquivo ~/.bashrc:

export WORKSPACE=1

A idéia é possibilitar a criação de perfis de configuração, cada qual correspondente a um ambiente de execução. A existência ou não da variável de ambiente é o que define o ambiente no qual a aplicação roda.

Continuando com o exemplo, no diretório raíz do seu projeto Django, crie o módulo environment.py, com o seguinte conteúdo:

import os
 
def production_mode():
    return not development_mode()
 
def development_mode():
    return 'WORKSPACE' in os.environ

Finalmente, modifique o módulo settings.py para que este utilize tais métodos onde for necessário definir configurações diferentes para ambientes de execução diferentes:

from environment import production_mode
 
# Configurações padrão
PREPEND_WWW = False
DEBUG = True
 
# Configurações para ambiente de produção
if production_mode():
    PREPEND_WWW = True
    DEBUG = False
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'pages.middleware.PageFallbackMiddleware',
    'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
)
 
# Habilitando caching em modo de produção
if production_mode():
    MIDDLEWARE_CLASSES += (
        'django.middleware.cache.UpdateCacheMiddleware',
        'django.middleware.cache.FetchFromCacheMiddleware',
    )

Não tenha medo de utilizar os recursos do Python onde eles se fizerem necessários, apenas tomando cuidado para não exagerar e acabar criando acidentalmente um Algoritmo Genético para configurar seu projeto!

Informações secretas (IPs, usernames, passwords, etc)

Praticamente não há quem ignore a importância de um bom sistema de controle de revisões (Subversion, Git, etc). O problema é que, muitas vezes, não tomamos o devido cuidado com o que colocamos dentro dos nossos repositórios. Sempre que possível, informações secretas — como endereços de IP, usernames e passwords — devem ser mantidas fora dos repositórios.

Em um projeto Django, as informações de acesso a servidores de e-mail e bancos de dados devem estar disponíveis através do módulo  settings.py. Felizmente, existe um jeito simples de manter essas informações separadas das outras configurações.

Primeiramente, abra o arquivo settings.py do seu projeto e remova todas as senhas e outras informações que você considere secretas. Em seguida, cole o seguinte trecho de código no final do arquivo:

try:
    from private import *
except ImportError:
    pass

Feito isso, crie o módulo private.py no diretório raíz do seu projeto Django. Coloque nele as configurações que você removeu do settings.py no passo anterior. Exemplo:

from environment import production_mode
 
SECRET_KEY = 'secret_key_do_seu_projeto'
 
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = 'senha_email_local'
 
DATABASE_HOST = 'localhost'
DATABASE_USER = 'username_db_local'
DATABASE_PASSWORD = 'senha_db_local'
 
if production_mode():
    EMAIL_HOST = 'ip_email_producao'
    EMAIL_HOST_PASSWORD = 'senha_email_producao'
 
    DATABASE_HOST = 'ip_db_producao'
    DATABSE_USER = 'username_db_producao'
    DATABASE_PASSWORD = 'senha_db_producao'

Certifique-se de adicionar o arquivo private.py no ignore (.cvsignore para CVS, .gitignore para Git, etc) correspondente ao sistema de controle de revisões sendo utilizado. Faça o commit e pronto.

Para finalizar, se o seu repositório já contém uma versão “insegura” do módulo settings.py, mude as senhas dos seus servidores.

E você, o que recomenda?

Tem alguma dica útil para compartilhar conosco? Nós adoraríamos ouvir o que você tem a dizer!

Um dos aspectos que se encontram em constante evolução é a parte de conectividade. O Network Manager, gerenciador de conexões utilizado nas versões mais recentes do Ubuntu, torna simples a tarefa de se conectar com praticamente qualquer tipo de rede, inclusive com as recém chegadas redes 3G.

Apesar de facilitar a vida na maioria dos casos, o Network Manager presente na última versão do Ubuntu parece não funcionar do jeito que deveria, principalmente quando tentamos conectar numa VPN PPTP (Point-to-Point Tunneling Protocol). Na versão anterior do Ubuntu, eu conseguia conectar em VPNs PPTP sem problemas, coisa que deixou de acontecer após a instalação da última versão do Ubuntu.

A boa notícia é que, depois de perder algumas horas pesquisando, eu consegui resolver o meu problema. E é isso que mostrarei a seguir!

Atualizando o Network Manager

A primeira coisa que fiz foi tentar substituir a versão pré-instalada do Network Manager pela versão distribuída pelos próprios desenvolvedores.

Para isso, abra o Synaptic e selecione o menu Settings – Repositories. Em seguida, selecione a aba Third-Party Software e clique no botão Add. Finalmente, cole a linha abaixo e confirme:

deb http://ppa.launchpad.net/network-manager/ubuntu intrepid main

Feche a tela e pressione CTRL+R para baixar as informações atualizadas dos repositórios. Após o término, pressione CTRL+G para iniciar o processo de atualização dos pacotes. Quando a instalação terminar, o Ubuntu irá pedir que você faça o reboot. Obedeça.

Configurando a VPN

Após o reboot, o sistema já deve estar funcionando com a nova versão do Network Manager. Clique no Applet do Network Manager e selecione o menu VPN Connections – Configure VPN. Aqui, basta configurar de acordo com as instruções que você deve ter recebido do pessoal responsável pela parte de redes da sua empresa.

Para não terminar o post aqui, eu vou mostrar como eu fiz para configurar a conexão VPN que estou utilizando atualmente. É obvio que cada empresa configura sua VPN de um jeito diferente, por isso o que segue abaixo é apenas um exemplo de configuração.

Informações básicas

Na primeira tela você deve informar os dados para conexão com a VPN, como IP do servidor da VPN, usuário e senha:

Informações básicas

Clique no botão Advanced para configurar em detalhes como deverá ser a comunicação entre seu computador e a VPN:

Opções avançadas

No meu caso, o servidor da VPN foi configurado para fazer autenticação via CHAP; marque ou desmarque as opções disponíveis na tela, se necessário.

Configurando as rotas

Prosseguindo, na aba IPv4 Settings você poderá configurar o seu IP na VPN. No meu caso, o IP local, juntamente com o servidor DNS e Gateway, são fornecidos automaticamente pelo servidor. Por isso eu optei por manter a opção Automatic (VPN) no campo Method.

Neste ponto você já deve ter a VPN funcionando, mas com um pequeno inconveniente: pelo menos aqui, a VPN passou a ser acessível através da rota padrão (IP 0.0.0.0). Isso significa que todo o tráfego é direcionado para a VPN!

Para solucionar esta questão, é preciso configurar uma rota através da qual a VPN possa ser acessada, mantendo inalterada a rota padrão. Para isso, basta clicar no botão Routes… e configurar a(s) rota(s):

Declarando rotas

Aqui, eu substituí as rotas obtidas automaticamente pelas rotas informadas na tabela. No meu caso, a faixa de IP da VPN é 192.168.0.X, por isso o Prefix foi configurado como 24 (aprenda aqui o que esse número significa). O campo Gateway foi configurado para o “IP remoto virtual” da VPN, fazendo com que os pacotes destinados a IPs 192.168.0.X sejam redirecionados para a VPN. O campo Metric foi deixado como zero.

Feito!

Isso deve bastar. Tente conectar com a VPN:

Conectando na VPN

Não conectou? Confira os dados de conexão e modifique os parâmetros avançados de conexão (métodos de autentiação, encriptação, etc). Tente encontrar o motivo nos logs /var/log/messages e /var/log/syslog. Conectou? Ótimo, agora faça o seguinte teste:

1. Dispare um ping contra algum computador da VPN;
2. Dispare um ping contra algum computador da sua rede local;
3. Dispare um ping contra algum computador da Internet (ex: google.com);

O teste falhou? Com certeza tem algo errado com a(s) sua(s) rota(s). Ainda conectado na VPN, utilize os comandos ip route e/ou route -n para ver como ficaram as rotas; faça os ajustes necessários, reze e tente novamente. O teste foi um sucesso? Parabéns, você conseguiu!

Update: Aos usuários do Fedora 10, o procedimento de configuração é praticamente o mesmo. O que muda é a configuração das rotas:

Declarando rotas (Fedora 10)

Essa automatização por si só já quebra uma árvore, mas ela possibilita ainda o uso de Integração Contínua, uma prática extremamente importante que costuma ajudar muitas equipes a manter seus projetos nos trilhos. Para mais informações sobre Integração Contínua, eu recomendo a leitura deste artigo, até porque este post terá um enfoque mais prático.

Neste texto será mostrado como configurar um projeto Python no Hudson, um servidor de Integração Contínua muito simples de configurar e utilizar. O sistema de controle de versões que eu utilizo aqui é o Git, mas usuários de outros sistemas também poderão achar este texto útil.

Baixando o Hudson

Acesse o site do Hudson e baixe o arquivo .war através do link disponível na página principal. Quando o download terminar, basta rodar o comando abaixo para subir o servidor na porta 8080:

java -jar hudson.war

Tela inicial do Hudson

Perca uns cinco minutos dando uma navegada no Hudson para ter uma idéia melhor do que é possível de ser feito com ele.

Hudson e plugins

O Hudson vem com suporte a Maven e Ant, duas das mais populares ferramentas para build de aplicações Java. Mas não se engane: o Hudson pode ser aproveitado em praticamente qualquer projeto, independente da linguagem e dos frameworks utilizados.

As funcionalidades do Hudson podem ser estendidas através de plugins, sendo que neste artigo utilizaremos dois deles: o Git Plugin, necessário para que o Hudson consiga trabalhar com repositórios Git, e o Violations, que consegue interpretar a saída de diferentes verificadores de código (dentre eles o pylint, um analisador de código Python!) e exibir informações a respeito da qualidade do código-fonte.

Para instalar esses plugins, basta acessar a tela de gerenciamento de plugins, marcar o Git Plugin e o Violations, e confirmar:

Instalando os plugins

Assim que a instalação terminar, reinicie o Hudson.

Integrando testes escritos com PyUnit ao Hudson

Apesar de existirem várias opções para criação e execução de testes unitários para Python, o PyUnit costuma ser o mais usado pelo fato de já estar incluído na distribuição padrão do Python.

Quem já fuçou no código do PyUnit sabe que ele define apenas um TestRunner, o TextTestRunner. O que este TestRunner basicamente faz é gerar em um fluxo qualquer (geralmente no sys.stderr) uma saída parecida com a seguinte:

.....
----------------------------------------------------------------------
Ran 5 tests in 0.067s

Apesar de eu me contentar com essa saída mais simples, bom, ferramentas como o próprio Hudson não se contentam; elas preferem algo como o bom e velho XML, que, convenhamos, é muito mais fácil de parsear.

Perdi algumas horas na Internet procurando por um TestRunner que conseguisse gerar arquivos XML no mesmo formato que os gerados pelo Ant e Maven, mas não encontrei nenhuma opção que fosse minimamente confiável. Por isso, eu tomei a liberdade de escrever meu próprio TestRunner: XMLTestRunner. O código deste “projeto”, disponibilizado no Github, contém instruções de uso e scripts de exemplo. Clonem e forkem à vontade!

Antes de prosseguirmos, baixe o módulo xmlrunner.py do site do projeto e o copie em algum lugar dentro do seu PYTHONPATH.

Integrando um projeto Python no Hudson

Para não perdermos tempo criando do zero um projeto de exemplo em Python, eu mostrarei como fazer para integrar o próprio XMLTestRunner com o Hudson.

Abra o console administrativo do Hudson e clique no link New Job:

Criando um projeto "free-style"

Na próxima tela, precisamos configurar o Job com os dados necessários:

Configuração de projeto

Configuração de projeto

Isso é tudo! Confirme as alterações e clique no link Build now. Aguarde alguns segundos enquanto o projeto é baixado do repositório Git e testado:

Exemplos de builds feitos pelo Hudson

Relatório de execução de testes

Análise de código feita pelo pylint

Como disparar o build de forma automática?

Uma vez que o projeto tenha sido configurado corretamente, basta um clique do mouse para que o Hudson faça todo o trabalho sujo. O problema agora é lembrar de fazer o build sempre que alguém modificar código no repositório.

Felizmente, temos duas opções para nos livrar de mais essa tarefa manual: a primeira seria configurar, nas propriedades do Job, uma expressão Cron que indique de quanto em quanto tempo o build deve ser feito; a segunda alternativa é apenas disparar o build quando alguém modificar código no repositório.

Como acontece com outros sistemas de controle de revisão, o Git possui hooks que nos permite executar ações em determinados momentos. Esses hooks nada mais são do que scripts executáveis localizados no diretório .git/hooks.

Mas enfim, quando disparar o build? Se o repositório Git e o servidor Hudson não são capazes de se comunicar diretamente, talvez a única alternativa seja disparar o build periodicamente. Para isso, você deve configurar um ou mais Build Triggers, na tela de configuração do Job.

Entretanto, se você mantém o repositório Git e o servidor Hudson na mesma máquina, ou mesmo em máquinas diferentes mas capazes de se comunicar via rede, podemos considerar a utilização dos hooks como ferramenta de integração entre o repositório Git e o Hudson.

Agora a pergunta que não quer calar: como integrar o Git e o Hudson? Bem, isso ficará como exercício para o leitor.

Dicas:

• O Hudson disponibiliza uma API através da qual se pode agendar builds, alterar as configurações do Job, criar Jobs, entre outras coisas.
• Para conhecer os hooks oferecidos pelo Git, consulte a documentação.

Conclusão

Já faz algum tempo que eu venho utilizando o Hudson para integrar projetos Java, e esta ferramenta vem se mostrando muito útil no meu dia-a-dia. Só quem pratica Integração Contínua sabe o quanto é complicado não contar com a segurança que ela proporciona ao desenvolvimento.

O problema, no entanto, começou quando eu optei pelo Python em vez do Java em certos projetos. Obviamente, eu queria aproveitar o ambiente de Integração Contínua que eu já utilizava, o que foi bastante complicado já que o PyUnit, framework de testes que eu costumo utilizar, não oferece uma forma de gerar relatórios XML, da mesma forma que Ant e Maven fazem.

Depois de estudar o funcionamento interno do PyUnit, eu decidi implementar um TestRunner que fosse capaz de gerar arquivos XML no formato esperado pelo Hudson. Deu um bocado de trabalho, é verdade, mas pelo menos agora eu consigo utilizar os excelentes relatórios gerados pelo Hudson para acompanhar a execução dos meus testes PyUnit.

Como o Brasil é grande, seria burrice achar que eu fui o único a enfrentar esse tipo de dificuldade. Por esse motivo, eu resolvi escrever este texto e, quem sabe, ajudar àqueles que enfrentam um problema semelhante.