Para quem não viu, recentemente colocamos no ar o Licensator, uma aplicação web que, além de reunir informações sobre as licenças open source mais populares, é capaz de indicar as licenças apropriadas para cada caso.

A linguagem escolhida para implementar o projeto foi Clojure, que se mostrou excelente para resolver esse tipo de problema. Veremos hoje como o principal algoritmo da aplicação funciona.

REPL: onde tudo começa

Um dos pontos fortes das linguagens dinâmicas é a facilidade em transformar idéias em código funcional, e com Clojure não é diferente. A idéia por trás do Licensator surgiu justamente em uma dessas sessões de codificação no REPL, o ambiente interativo da linguagem. Após alguns minutos brincando, vi que o problema era simples de resolver.

Apesar do elevado número de licenças, podemos facilmente extrair informações comuns a todas elas, como: se a licença é copyleft, se pode ser usada por código fechado (proprietário), entre outras coisas.

Por exemplo, vamos pegar a licença Apache v2.0:

(def *licenses*
     [{:id :apl-v20
       :long-name "Apache License v2.0"
       :short-name "Apache v2.0"
       :url "http://www.opensource.org/licenses/apache2.0.php"
       :copyright true
       :patent true
       :closed-source-linking true
       :derivative-work true
       :affero false
       :copyleft false
       :charge-for-distribution true
       :charge-for-use true
       :compatible-with [:apl-v20 :afl-v30 :cddl-v10 :epl-v10 :freebsd
                         :new-bsd :mit :mpl-v11 :public-domain]}])

A lista completa de licenças pode ser vista aqui.

Considerando que todas as licenças têm esse mesmo conjunto de informações, como podemos saber quais licenças não são recíprocas e possuem cláusulas explícitas de copyright?

(map :id
  (filter #(and (:copyright %) (not (:copyleft %))) *licenses*))
=> (:afl-v30 :apl-v20 :epl-v10 :freebsd :mit :new-bsd :bsd)

Se você conhece um pouco sobre programação funcional, este código deve ser fácil de acompanhar. De qualquer forma, o que ele faz é retornar o :id de todas as licenças onde :copyright é verdadeiro e :copyleft é falso.

Outro exemplo: quais licenças são compatíveis com Apache v2.0 e CDDL v1.0?

(use 'clojure.set)
 
(map :id
  (filter #(subset? (set [:apl-v20 :cddl-v10])
                    (set (:compatible-with %))) *licenses*))
=> (:apl-v20 :cddl-v10 :epl-v10)

Aqui usamos a namespace clojure.set, que conta com algumas funções úteis para álgebra relacional. O código é muito parecido com o anterior; a mudança é que agora usamos a função subset? para buscar as licenças compatíveis com [:apl-v20 :cddl-v10].

Último exemplo: quais licenças recíprocas são compatíveis com Apache v2.0?

(map :id
  (filter #(and (subset? (set [:apl-v20]) (set (:compatible-with %)))
                (:copyleft %)) *licenses*))
=> (:cddl-v10 :agpl-v30 :gpl-v30 :lgpl-v30 :mpl-v11)

Neste ponto já se pode perceber que não existe mágica nenhuma por trás do algoritmo; o que ele faz é filtrar as licenças com base numa função.

A solução

O código que acabamos de ver funciona, mas não é apropriado para resolver o problema uma vez que a lógica de consulta se encontra fixa no código.

O ideal seria se os critérios de busca fossem expressados como um map…

(def cmap
     {:patent true, :closed-source-linking true, :compatible-with [:mit :new-bsd]})

…portanto precisamos de uma função que faça a filtragem das licenças com base nesse mapa, algo como:

(defn find-matches [cmap data]
  (filter (where cmap) data))

No caso, essa função where, que ainda não definimos, deve retornar uma função que filtre os elementos (licenças) em data de acordo com o mapa de critérios cmap.

Vamos por partes. Quais condições em cmap são verdadeiras para a licença Apache v2.0?

(defn criteria-matches? [license [kval cval]]
  "Verifica se o critério 'centry' é verdadeiro para a licença 'license'."
  (let [lval (kval license)]
    (if (nil? cval)
      true
      (if (coll? lval)
        (subset? (set cval) (set lval))
        (= cval lval)))))
 
(map (partial criteria-matches? apl-v20) cmap)
=> (true true true)

Uma licença só pode ser considerada compatível com os critérios se a lista retornada contém apenas valores verdadeiros. Portanto, neste caso, a licença Apache v2.0 é considerada compatível com os critérios informados:

(every? true? (map (partial criteria-matches? apl-v20) cmap))
=> true

Logo, uma possível implementação para a função where seria:

(defn where
  "Retorna função que diz se todos os critérios em 'cmap' são verdadeiros para a licença 'lentry'."
  [cmap]
  (fn [lentry]
    (let [res (map (fn [centry]
		     (let [cval (val centry)
			   lval ((key centry) lentry)]
		       (if (nil? cval)
			 true
			 (if (coll? lval)
			   (subset? (set cval) (set lval))
			   (= cval lval))))) cmap)]
      (every? true? res))))

Este código é uma junção dos dois anteriores. A função where recebe o mapa cmap com os critérios de pesquisa, e retorna uma segunda função. Esta função recebe uma licença lentry e verifica se todos os critérios informados são verdadeiros para esta licença.

Como where é usada em conjunto com filter na função find-matches, isso fará com que todas as licenças compatíveis sejam retornadas:

(map :id (find-matches cmap *licenses*))
=> (:afl-v30 :apl-v20 :cddl-v10 :epl-v10 :lgpl-v30 :mpl-v11)

Uma das coisas legais de Clojure — e outras linguagens funcionais — é a quantidade ridícula de código necessário para resolver certos problemas. Este algoritmo, por exemplo, tem apenas 15 linhas (muito curtas) de código. Onde está seu Deus agora?!

O código da aplicação está no Github para quem tiver interesse em ver o restante do código.

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!

E com a Copa do Mundo vem os bolões. Muitos bolões.

Todo mundo já sabe como funciona um bolão, embora a mecânica possa mudar de um lugar para outro:

1. Cada palpite tem um valor fixo (ex: R$2,00).
2. Cada um pode dar quantos palpites quiser.
3. No final, o montante arrecadado é dividido igualmente entre os vencedores. Se não houverem vencedores: (a) o bolão “acumula”¹, ou (b) todo mundo recebe seu dinheiro de volta, ou (c) sua-regra-maluca-aqui.

Esse tipo de bolão é interessante, mas ele podia ser melhor em alguns aspectos.

Primeiro, o organizador acaba perdendo muito tempo correndo atrás de troco, afinal não é todo mundo que anda com dinheiro trocado na carteira. Além disso, valor fixo de palpite é muito chato, pois o valor arrecadado é dividido por igual entre os ganhadores. O bolão fica muito mais interessante quando o valor do palpite é variável e o valor arrecadado é dividido proporcionalmente entre os ganhadores. Assim, no caso de vários ganhadores, ganha mais quem apostar mais.

O problema de se fazer bolões com palpite variável é ter que ficar calculando o valor proporcional a ser dado a cada ganhador. Portanto eis o desafio: criar um programa que receba uma lista com todos os palpites e retorne uma lista com os palpites vencedores juntamente com o valor proporcional a ser pago a cada ganhador.

E aí, topa?

Resolvendo o problema… em Clojure

Como escrever mais código do que necessário está saindo de moda, optei por codificar uma possível solução em Clojure. Por ser uma linguagem funcional, Clojure é excelente para esse tipo de tarefa. Basta iniciar o REPL e mãos à obra!

Primeiramente, devemos definir como um palpite deve ser representado:

(defstruct bet :name :amount :guess :rate)

Todos os palpites possuem o mesmo conjunto de informações, por isso definimos um StructMap com as chaves :name, :amount, :guess e :rate.

Abaixo, uma possível lista de palpites:

(def pool
     [(struct bet "Daniel"  2.0 [2 0]) ;; Daniel aposta R$2,00 no placar 2x0
      (struct bet "Antônio" 4.0 [0 0]) ;; Antônio aposta R$4,00 no placar 0x0
      (struct bet "Marcela" 1.0 [2 0]) ;; Marcela aposta R$1,00 no placar 2x0
     ])

Certo, já sabemos como os palpites são representados. Agora, como saber o montante total de uma lista de palpites (a.k.a. bolão)? Simples, basta calcular o somatório dos valores de todos os palpites:

(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
;; testando
(pool-amount pool)
=> 7.0

Beleza, mas quanto cada palpite representa em relação ao total arrecadado? Afinal, precisamos calcular o valor proporcional a ser pago a cada ganhador.

Sem problemas, basta dividir o valor de cada palpite pelo montante total:

(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
;; testando
(map :rate (pool-rates pool))
=> (0.285 ..., 0.571 ..., 0.142 ...)
 
(reduce + (map :rate (pool-rates pool)))
=> 1.0

Repare que, se todos os participantes ganhassem um bolão, o valor recebido pelo Antônio seria o dobro do valor recebido pelo Daniel, que seria o dobro do valor recebido pela Marcela. Justiça, finalmente!

Pronto, agora só falta uma função para filtrar os ganhadores da lista de participantes e calcular o valor proporcional a ser pago a cada um deles:

(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))
 
;; testando
(pool-winners pool [1 0]) ;; sem ganhadores
=> ()
 
(pool-winners pool [0 0]) ;; apenas um ganhador
=> ({:name "Antônio", :amount 7.0, :guess [0 0], :rate 1.0})
 
(pool-winners pool [2 0]) ;; vários ganhadores
=> ({:name "Daniel", :amount 4.66 ..., :guess [2 0], :rate 0.66 ...}
    {:name "Marcela", :amount 2.33 ..., :guess [2 0], :rate 0.33 ...})

Uma grande vantagem dessa solução é que ela permite que você aposte em qualquer coisa. Quer apostar no sexo de um bebê logo após a boa notícia (ou má notícia, sei lá)?

;; :male = masculino, :female = feminino
(def pool [(struct bet "Daniel"  3.0 :male)
           (struct bet "Antônio" 5.0 :female)
           (struct bet "Fran"    1.0 :female)])
 
(pool-winners pool :female) ;; testando
=> ({:name "Antônio", :amount 7.5, ...} {:name "Fran", :amount 1.5, ...})

Aí está, uma solução simples para um problema simples. Como deveria ser sempre.

Minha solução, na íntegra

Embora seja possível resolver isso com um one-liner em Lisp/Clojure (afinal o Reader não trabalha com linhas, mas com estruturas de dados), eu optei por escrever um código que fosse o mais legível possível para quem não conhece ou está aprendendo Clojure:

(defstruct bet :name :amount :guess :rate)
 
(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))

Levando adiante

Você programa em Haskell? Python? Ruby? Brainfuck? Qual seria a sua solução para este problema de extrema importância para o desenvolvimento da raça humana?

Atualização (03/11/2010). Solução em Common Lisp, usando copy-* para evitar mutabilidade:

(defstruct bet name amount guess rate)
 
(defun pool-amount (pool)
  (reduce #'+ (mapcar #'bet-amount pool)))
 
(defun pool-rates (pool)
  (let ((sum (pool-amount pool)))
    (mapcar (lambda (bet)
              (let ((x (copy-bet bet)))
                (setf (bet-rate x) (/ (bet-amount x) sum))
                x)) pool)))
 
(defun pool-winners (pool result)
  (let ((sum (pool-amount pool))
        (winners (loop for bet in pool when (equal (bet-guess bet) result) collect bet)))
    (mapcar (lambda (winner)
              (let ((x (copy-bet winner)))
                (setf (bet-amount x) (* (bet-rate x) sum))
                x)) (pool-rates winners))))

Sim, eu disse que o Django 1.2 traz incluso um framework de “mensagens”. Bom, né? Django realmente precisava vir acompanhado de uma app para resolver essa questão. Isso não significa, no entanto, que Django-Flash será descontinuado ou abandonado.

Então, se você usa Django-Flash em seus projetos, não se preocupe! Nada mudará. Django-Flash já é compatível com Django 1.2, e nós ocontinuaremos a mantê-lo por algumas razões.

A primeira delas é que nos importamos com quem usa nosso software. Nós não quebraremos seus projetos se você decidir fazer o upgrade para uma versão mais recente do Django – ou se decidir continuar usando uma versão anterior.

A outra é a liberdade de escolha. Você sabe, não existe uma única forma de se resolver todos os problemas. As pessoas devem ser livres para escolher a ferramenta apropriada a uma determinada situação.

Por exemplo, baseado nas minhas primeiras impressões, existem algumas coisas que eu realmente não gostei no novo framework de “mensagens”:

1. Ele é verboso mesmo nos casos de uso mais simples
2. Ele associa mensagens a números de prioridade, encorajando os usuários a usá-lo como um framework de logging/debugging. Quero dizer, um framework de “mensagens” não é um framework de logging/debugging, certo?

Mas essa é apenas a minha opinião. Talvez seja isso que faz do open source algo tão formidável!

No fim das contas eu acabei com um Nokia 5800 XpressMusic, um smartphone relativamente barato e com features interessantes. Especificamente, o fato de poder rodar aplicações Python nesse aparelho foi um fator decisivo!

Mas, o que exatamente podemos fazer com Python para S60? Eu decidi implementar uma aplicação não trivial para ver exatamente o que pode ser feito com ele. A aplicação em questão é um controle remoto Bluetooth chamado Pytriloquist. (veja também screenshots e vídeo de demonstração.)

O que é Bom

Independência de Plataforma. A SDK para S60 só roda em Windows (que novidade). Isso obviamente é ruim para quem costuma usar outros sistemas operacionais. Felizmente, você não precisa de uma SDK gigante para desenvolver e distribuir aplicações para S60 se você escrevê-las em Python; tudo o que você precisa é do Python para S60, um editor de texto e um aparelho para testes.

Linguagem e Biblioteca Padrão. Python é uma linguagem excelente: compacta, bonita, poderosa e tem uma biblioteca padrão sensacional. A boa notícia é que a maioria dos módulos rodam bem no S60. Por exemplo, é possível até localizar suas aplicações usando o módulo gettext!

O que é Ruim

Trabalho em Andamento. Python para S60, até onde me consta, é um trabalho em andamento. Isso significa que a linguagem em si funciona bem, mas você pode dar falta de certos módulos ou encontrar bugs na biblioteca padrão. Por exemplo, enquanto eu escrevia o código Bluetooth para minha applicação, eu dei de cara com um bug muito chato onde você só pode chamar btsocket.bt_discovert() uma vez!

Código Multi-Módulos. Se você está testando sua aplicação com Python ScriptShell, tudo irá funcionar de cara desde que você mantenha todo o código dentro de um único — e enorme — módulo. Se você quebrar seu código em vários módulos (ou pior, pacotes), você não poderá ter módulos importando uns aos outros, a menos que você ajuste o PYTHON_PATH de acordo.

Documentação Incompleta e Desatualizada. Existem alguns PDFs e algumas documentações de API disponíveis, mas elas estão incompletas e desatualizadas, o que é ruim quando se trata de uma linguagem dinâmica; nós não temos um compilador para nos dizer o que há de errado com nosso código. Esse é o motivo pelo qual desenvolvedores Python são tão cuidadosos com documentação pra começo de conversa.

O que é Feio

Acesso Limitado a Recursos Nativos. Especialmente em se tratando do sistema de UI nativo: você não pode mudar o texto das duas soft keys padrão, nem adicionar soft keys, nem adicionar mais que duas abas, nem ter um Listbox vazio, nem um monte de outras coisas. Você pode escrever UIs simples sem muito esforço, isso é verdade, mas essas deficiências todas tornam Python para S60 simplesmente inutilizável em projetos mais complexos.

Inatividade do Projeto. O projeto parece estar em modo “stand by”. Novos bug reports são enviados de tempos em tempos, mas nenhum bug foi fechado há mais de seis meses.

Conclusão

Espero que as coisas mudem para melhor após o último anúncio feito pela Fundação Symbian, mas, enquanto isso, se você pretende criar aplicações sérias para S60, o faça em C++.

Ultimamente, tenho visto a forma como certos desenvolvedores escrevem seus JSPs, e o que me preocupou foi ver o quanto eles desconhecem a tecnologia. Não é raro achar páginas cheias de scriptlets, includes malucos, código du-tri-quadri-plicado e nenhuma taglib além da fornecida pelo framework web em uso.

É muito fácil escrever JSPs da forma errada, mas fazer as coisas de um jeito melhor é mais fácil ainda. Ao contrário do que muitos pensam, é possível sim criar JSPs limpos sem o uso de qualquer framework de layout (como Sitemesh) ou biblioteca (com exceção da JSTL, é claro).

Um exemplo

O primeiro passo é definir o template base para as páginas da aplicação. Considere o seguinte exemplo de XHTML e sua representação gráfica:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords"    content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <div id="header"></div>
            <div id="content"></div>
            <div id="footer"></div>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts (e.g. Google Analytics)
        </script>
    </body>
</html>

Representação gráfica do layout

O que costuma acontecer, mesmo em um layout simples como esse, é o alto índice de duplicação de código entre as diferentes páginas, principalmente em função do uso de Copy and Paste Programming. Muitos desenvolvedores por aí escreveriam o seguinte JSP para representar o layout proposto:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
        <meta name="keywords"    content="keyword1, keyword2, keyword3" />
        <meta name="description" content="Page description" />
        <title>Page title</title>
 
        <!-- Essential scripts -->
        <jsp:include page="scripts.jsp"/>
 
        <!-- Extra header -->
        <script type="text/javascript" src="js/util.js"></script>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <jsp:include file="header.jsp"/>
            <div id="content">Page content here</div>
            <jsp:include page="footer.jsp"/>
        </div> <!-- Main -->
 
        <script type="text/javascript">
            // Other scripts
        </script>
    </body>
</html>

Viu o problema? De nada adianta separar os pedaços com e continuar duplicando código. O ideal seria traduzir o layout em algo assim:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<layout:page title="Title" description="Page description" keywords="keyword1, keyword2, keyword3">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        // Other scripts (e.g. Google Analytics)
    </jsp:attribute>
    <jsp:body>
        Page content here
    </jsp:body>
</layout:page>

A boa notícia é que isso é possível, através de tag files.

Reúso de conteúdo com tag files

Existem pelo menos três formas de se criar custom tags em JSP, cada qual com seu propósito: classic tag handlers, simple tag handlers e tag files. Neste post tratarei somente das tag files, mas saber como e quando utilizar simple tag handlers também é extremamente recomendado a todos que usam JSP no dia-a-dia.

A primeira coisa a fazer é criar o diretório WEB-INF/tags/layout. É nesse diretório que as tag files referentes ao template devem ficar. Agora, crie dois arquivos neste diretório, um para o cabeçalho e outro para o rodapé:

header.tag

<%@ tag body-content="empty" description="Header tag file" %>
<div id="header">
    <!-- Header section here -->
</div>

footer.tag

<%@ tag body-content="empty" description="Footer tag file" %>
<div id="footer">
    <!-- Footer section here -->
</div>

Como podemos ver, as tag files são como JSPs, mas com algumas propriedades especiais.

A última tag file, page.tag, define o esqueleto das páginas da aplicação:

<%@ tag description="Page layout" %>
 
<%@ attribute name="title"       required="true" description="Page title" %>
<%@ attribute name="keywords"    required="true" description="Page keywords to improve SEO" %>
<%@ attribute name="description" required="true" description="Page description" %>
 
<%@ attribute name="extraHeader" fragment="true" description="Extra code to put before </head>" %>
<%@ attribute name="extraBottom" fragment="true" description="Extra code to put before </body>" %>
 
<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
 
        <!-- Displaying the attributes using EL -->
        <meta name="keywords"    content="${keywords}" />
        <meta name="description" content="${description}" />
        <title>${title}</title>
 
        <!-- Essential scripts -->
        <link rel="stylesheet" type="text/css" href="css/style.css"/>
        <script type="text/javascript" src="js/query.js"></script>
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraHeader"/>
    </head>
    <body>
        <!-- Main -->
        <div id="wrapper">
            <!-- Renders the page header -->
            <layout:header/>
 
            <!-- Renders the tag body inside a DIV -->
            <div id="content"><jsp:doBody/></div>
 
            <!-- Renders the page footer -->
            <layout:footer/>
        </div> <!-- Main -->
 
        <!-- Process the given input fragment -->
        <jsp:invoke fragment="extraBottom"/>
    </body>
</html>

Esta última tag file é mais complexa que as anteriores, pois recebe dados e blocos de código (através de fragments). Além disso, ela aceita um corpo, que é executado com <jsp:doBody/>.

O exemplo usado aqui é razoavelmente simples e, por isso, não precisamos apelar para outros recursos mais avançados como variables e dynamic attributes. De qualquer forma, procure conhecer bem a tecnologia, pois você nunca sabe quando um ou outro recurso lhe pode ser útil.

Exemplo de uso

Novamente, um exemplo de uso das tags que criamos:

<%@ taglib tagdir="/WEB-INF/tags/layout" prefix="layout" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<layout:page title="Index page" description="This is the index page of my amazing app" keywords="amazing, app">
    <jsp:attribute name="extraHeader">
        <script type="text/javascript" src="js/util.js"></script>
        <script type="text/javascript" src="js/some_jquery_plugin.js"></script>
    </jsp:attribute>
    <jsp:attribute name="extraBottom">
        $(function() {
            // Call some JQuery function here, specific for this page
        });
    </jsp:attribute>
    <jsp:body>
        Welcome to my amazing app!<br/>
        1+1 = ${1+1}
 
        <ul>
        <c:forEach items="${objects}" var="obj">
            <li>${obj.attr}</li>
        </c:forEach>
        </ul>
    </jsp:body>
</layout:page>

Embora a aplicação como um todo siga um mesmo padrão visual, cada página pode necessitar de recursos adicionais (JavaScript, CSS, etc). Isso não chega a ser um problema, pois nosso template contempla a inclusão de conteúdo extra, se necessário.

Outra vantagem é que as tag files permitem o uso de custom tags e unified EL, mas proíbem o uso de scriptlets, o que já é meio caminho andado rumo a um JSP mais limpo.

Leitura recomendada

• The Java EE 5 Tutorial;
• Head First Servlets & JSP;

Muita coisa aconteceu nessas 48 horas. O pessoal da Ticketmaster teve trabalho para manter o website no ar e, em razão da enorme carga, é possível que apenas poucos milhares de fãs tenham sido sortudos o bastante para comprar seus ingressos através da internet.

Além disso, a Ticketmaster admite que os e-mails de notificação podem não ser enviados, o que significa que não podemos depender deles para acompanhar nossos pedidos. Na verdade, eles até recomendam que seus clientes chequem os pedidos diariamente, na mão. Caramba…

Eu odeio fazer certas tarefas manualmente, especialmente as que podem ser automatizadas. Então, neste post eu mostrarei uma ferramenta escrita em Python que mostra a situação dos seus pedidos Ticketmaster na tela¹, usando uma técnica conhecida como web scraping.

O código, que também está disponível no Github, pode ser visto abaixo:

#!/usr/bin/env python
#-*- coding:utf-8 -*-
 
import urllib
import urllib2
import pynotify
 
 
_BASE_URL  = 'https://ticketing.ticketmaster.com.br'
_LOGIN_URI = '%s/shwLogin.cfm' % _BASE_URL
_ORDER_URI = '%s/shwCompraDetalhe.cfm?pedidoID=%%s' % _BASE_URL
 
_ORDERS_LINK = '<a href="%s">More...</a>' % _LOGIN_URI
 
_PRIORITY_LOW      = pynotify.URGENCY_LOW
_PRIORITY_NORMAL   = pynotify.URGENCY_NORMAL
_PRIORITY_CRITICAL = pynotify.URGENCY_CRITICAL
 
_NOTIFICATION_TITLE = 'Ticketmaster Order %s'
_STATUS_CODES = {
    'Livre'      : ('Not processed yet'      , _PRIORITY_LOW),
    'StdReserva' : ('Reserving your tickets' , _PRIORITY_NORMAL),
    'StdCobranca': ('Charging your tickets'  , _PRIORITY_NORMAL),
    'VendaOk'    : ('Billed'                 , _PRIORITY_CRITICAL),
    'Recusada'   : ('Rejected'               , _PRIORITY_CRITICAL)
}
 
 
def initialize_notification_system(app_title):
    if not pynotify.init(app_title):
        import sys
        sys.exit(1)
 
 
def display_message(title, message, priority=_PRIORITY_CRITICAL):
    message = pynotify.Notification(title, message)
    message.set_urgency(priority)
    message.show()
 
 
def check_orders(email, password, order_ids):
    try:
        opener = urllib2.build_opener(urllib2.HTTPCookieProcessor())
        login(opener, email, password)
        try:
            for order_id in order_ids:
                show_order_status(opener, order_id)
        except:
            title = _NOTIFICATION_TITLE % order_id
            display_message(title, 'Cannot check status')
    except:
        display_message('Ticketmaster', 'Login failed')
 
 
def login(opener, email, password):
    params = urllib.urlencode({'email': email, 'senha': password})
    response = opener.open('%s?tentaLogin=1' % _LOGIN_URI, params)
 
    # Invalid credentials check
    if response.read().find('senha incorreta') >= 0:
        raise Exception
 
 
def show_order_status(opener, order_id):
    response = opener.open(_ORDER_URI % order_id)
    content = response.read()
 
    # Search for the order status codes
    for key, value in _STATUS_CODES.items():
        if content.find(key) >= 0:
            title = _NOTIFICATION_TITLE % order_id
            message = '%s. %s' % (value[0], _ORDERS_LINK)
            display_message(title, message, value[1])
            break
    else:
        display_message(_NOTIFICATION_TITLE % order_id, 'Status not found')
 
 
def main():
    initialize_notification_system("Ticketmaster Order Status")
 
    import optparse
    p = optparse.OptionParser()
 
    # Required command line options
    p.add_option('--email'    , '-e', \
        help='E-mail address used in your Ticketmaster credentials.')
    p.add_option('--password' , '-p', \
        help='Password used in your Ticketmaster credentials.')
    p.add_option('--order-ids', '-o', \
        help='Order IDs to be checked, separated by collons.')
 
    options = p.parse_args()[0]
    if not options.email or not options.password or not options.order_ids:
        p.print_help()
    else:
        order_ids = map(lambda s: s.strip(), options.order_ids.split(','))
        check_orders(options.email, options.password, order_ids)
 
 
if __name__ == '__main__':
    main()

A razão pela qual eu optei por web scrapping é porque a Ticketmaster não fornece uma API da mesma forma que o Flickr fornece, por exemplo. Ainda assim, o código é bastante simples.

Como você pode ver, ele primeiro envia uma requisição HTTP para a URI de login com o objetivo de validar as credenciais do usuário. Se a autenticação for bem sucedida, nosso opener receberá os cookies de sessão do servidor e os usará nas requisições seguintes, que buscam a situação de cada um dos pedidos informados.

Rodando o script agora:

Current order status

Finalmente, inclua uma nova entrada no seu crontab para que o script rode sempre que necessário (ex: a cada 10 minutos):

*/10 * * * * python ticketmaster_order_status.py --email=seu@email.com --password=senha --order-ids=1234

Boa sorte e let there be rock!

Infelizmente, coisas assim estão acontecendo por aqui com uma certa frequência. Por isso, resolvi escrever o script abaixo, cuja função é mostrar uma mensagem de notificação sempre que algum dos sites pré-determinados saiam do ar: ¹

#!/usr/bin/env python
# -*- coding: utf-8 -*-
 
import httplib
import pynotify
 
def display_message(title, message):
    if pynotify.init('Website Status'):
        n = pynotify.Notification(title, message)
        n.show()
 
def check_status(*websites, **kwargs):
    timeout = kwargs.get('timeout', 5)
    for website in websites:
        conn = httplib.HTTPConnection(website, timeout=timeout)
        try:
            conn.request('GET', '/')
            response = conn.getresponse()
            if response.status != 200:
                raise Error()
        except:
           display_message(website, 'Web site could not be reached!')
 
if __name__ == '__main__':
    check_status('www.awebsite.com', 'www.anotherwebsite.com')

O script em funcionamento:

Exemplo de notificação

Para completar, se você deseja que esse script seja executado uma vez a cada 5 minutos, basta inserir a linha abaixo no seu crontab:

*/5 * * * * /path/to/script.py

Pronto! Agora, se o seu serviço de hosting continuar deixando a desejar, talvez a melhor solução seja mesmo mudar para outro lugar…

A boa notícia é que a importância dos testes automatizados vem aumentando com o tempo e hoje, felizmente, já não é mais necessário “vender” a idéia. O aumento absurdo de ferramentas destinadas a facilitar a aplicação desta prática é uma prova disso.

Falando em ferramentas, neste texto mostrarei o JsHamcrest, um projeto open source desenvolvido pela Destaquenet cujo objetivo é fornecer uma versão incrementada, em JavaScript, da biblioteca Hamcrest. Para quem não conhece, Hamcrest é uma biblioteca de matchers que permite que regras sejam definidas declarativamente para uso em outros frameworks e bibliotecas.

Para apreciar é preciso antes viver sem

Para dar uma idéia do quão útil JsHamcrest pode ser, segue abaixo um exemplo de suite de testes criado com QUnit, ainda sem apoio do JsHamcrest, onde testamos o funcionamento de algumas funcionalidades da classe Array:

$(document).ready(function(){
    test("Literal", function() {
        var arr = [];
        ok(arr instanceof Array);
        equals(arr.length, 0);
    });
 
    test("Reverse", function() {
        var arr = [1, 2, 3, 4, 5].reverse();
        equals(arr.length, 5);
 
        // This assertion fails
        // equals(arr, [5, 4, 3, 2, 1]);
 
        // These assertions work, but in an ideal world you shouldn't do such a thing
        for (var i = 0, j = 5; i < arr.length; i++, j--) {
            equals(arr[i], j);
        }
    });
 
    test("Slice", function() {
        var arr = [1, 2, 3, 4, 5, 6, 7].slice(2, 5);
        equals(arr.length, 3);
 
        // This assertion fails
        // equals(arr, [3, 4, 5]);
 
        // These assertions work, but in an ideal world you shouldn't do such a thing
        for (var i = 0; i < arr.length; i++) {
            equals(arr[i], i+3);
        }
 
        // Another example of complex assertion
        for (var i = 0; i < arr.length; i++) {
            ok(arr[i] >= 3 && arr[i] <= 5);
        }
    });
});

O código, mesmo sendo feio e confuso, funciona:

Primeira versão da suite de testes

O código desta suite de testes está disponível para download.

(Muitas) Limitações

O primeiro teste, que verifica o funcionamento do literal [], foi muito simples de implementar até porque não há praticamente nada a ser testado. Mas não fique feliz; no mundo real, as chances de seus testes serem assim tão simples são muito baixas.

Isso começa a ficar evidente à partir do segundo teste, onde é preciso apelar para o bom (?) e velho for para conferir o conteúdo do array, uma vez que QUnit não os suporta em comparações de igualdade.

Obviamente a mesma coisa também acontece no terceiro teste. E para mostrar que a a sitiuação só tende a piorar, ainda no terceiro teste temos um outro exemplo de asserção (tão feio quanto) que verifica se todos os elementos do array estão num determinado intervalo.

Infelizmente, a “feiura” não é a única coisa que incomoda nesse código. Para ilustrar, suponha que o terceiro teste estivesse quebrado:

test("Slice", function() {
    var arr = [1, 2, 3, 4, 5, 6, 7].slice(2, 5);
    equals(arr.length, 3);
 
    // ...
 
    // Another example of complex assertion
    for (var i = 0; i <= arr.length; i++) {
        ok(arr[i] >= 3 && arr[i] <= 5);
    }
});

Como esperado, ao rodar os testes, o relatório mostra a ocorrência de um erro. O problema é que esse relatório faz um péssimo trabalho ao tentar mostrar o que de fato falhou:

Relatório de erro não muito amigável

Uma forma de se amenizar este problema é passar um texto descritivo aos métodos ok() e equals():

ok(num1 >= 3 && num1 <= 5, "Expected num1 between 3 and 5");
equals(num2, 10, "Checking value of num2");

O problema é que, ao fazer isso, passa a ser necessário um certo cuidado para manter os textos descritivos em sincronia com o código das asserções.

Se QUnit é assim tão ruim…

…por que não o trocar por outra coisa?

Apesar de existirem várias alternativas ao QUnit, nenhuma delas parece ser capaz de resolver problemas como os mostrados aqui. Portanto, trocar de framework, por enquanto, não é a solução.

Mas nem tudo está perdido.

Viva melhor com JsHamcrest

O código mostrado anteriormente pode ser facilmente adaptado para usar JsHamcrest:

// Integrates JsHamcrest with QUnit
JsHamcrest.Integration.QUnit();
 
$(document).ready(function(){
    test("Literal", function() {
        var arr = [];
        assertThat(arr, instanceOf(Array));
        assertThat(arr, empty());
    });
 
    test("Reverse", function() {
        var arr = [1, 2, 3, 4, 5].reverse();
        assertThat(arr, hasSize(5));
        assertThat(arr, equalTo([5, 4, 3, 2, 1]));
    });
 
    test("Slice", function() {
        var arr = [1, 2, 3, 4, 5, 6, 7].slice(2, 5);
        assertThat(arr, hasSize(3));
        assertThat(arr, equalTo([3, 4, 5]));
        assertThat(arr, everyItem(between(3).and(5)));
    });
});

Gostou?

A primeira coisa que salta aos olhos é a simplicidade do código. Basta uma olhada rápida para saber exatamente o que ele faz. Note que mesmo asserções mais complexas como as mostradas nos dois últimos testes são implementadas com facilidade.

O resultado:

Relatório com dados detalhados das asserções

O código desta suite de testes está disponível para download.

E não é só isso. Ao mesmo tempo em que temos um vocabulário riquíssimo de asserções, JsHamcrest também fornece informações detalhadas sobre as mesmas, numa linguagem fácil de entender. E isso tudo isso sem nenhum esforço!

Mais informações sobre a API podem ser encontradas no pacote de documentação do projeto, também disponível para download.

Mas, e quanto ao problema do relatório de erro? Vamos quebrar uma asserção e  ver o que acontece:

test("Slice", function() {
    var arr = [1, 2, 3, 4, 5, 6, 7].slice(2, 5);
    assertThat(arr, hasSize(3));
    assertThat(arr, equalTo([3, 4, 5]));
    assertThat(arr, everyItem(between(3).and(4)));
});

O resultado:

Mensagem de erro amigável

Muito melhor! Basta olhar a mensagem de erro para descobrir o que está errado.

Posso usar JsHamcrest com outro framework?

Atualmente, JsHamcrest integra com cinco frameworks: JsTestDriver, JsUnitTest, jsUnity, YUITest e QUnit.

Outra coisa legal é que integração feita pelo JsHamcrest leva em conta as convenções definidas pelo framework escolhido. Veja, por exemplo, como ficaria o código se tivéssemos optado pelo YUITest em vez do QUnit:

// Integrates JsHamcrest and YUITest
JsHamcrest.Integration.YUITest();
 
YAHOO.namespace("array");
YAHOO.array.TestCase = new YAHOO.tool.TestCase({
    name : "Array tests",
 
    testLiteral: function() {
        var arr = [];
        Assert.that(arr, instanceOf(Array));
        Assert.that(arr, empty());
    },
 
    testReverse: function() {
        var arr = [1, 2, 3, 4, 5].reverse();
        Assert.that(arr, hasSize(5));
        Assert.that(arr, equalTo([5, 4, 3, 2, 1]));
    },
 
    testSlice: function() {
        var arr = [1, 2, 3, 4, 5, 6, 7].slice(2, 5);
        Assert.that(arr, hasSize(3));
        Assert.that(arr, equalTo([3, 4, 5]));
        Assert.that(arr, everyItem(between(3).and(5)));
    }
});

Mas meu framework predileto não está nessa lista…

JsHamcrest pode vir a suportar outros frameworks no futuro. Se seu framework predileto não está na lista dos atualmente suportados, entre em contato conosco.

E aí, o que achou?

Gostou? Odiou? Tem sugestões de melhorias? Gostaríamos muito de ouvir sua opinião!

Temos portanto dois problemas a serem resolvidos. O primeiro problema, relacionado a automatização de tarefas repetitivas, pode ser facilmente solucionado com Fabric, uma ferramenta muito útil para criação de scripts de build e deployment de aplicações. Já escrevemos um texto introdutório sobre a mesma, não deixe de conferir.

O segundo problema, entretanto, é um pouco mais complicado de se resolver, mas não é nenhum bicho de sete cabeças. Com VirtualEnv, é possível criar ambientes Python isolados com o objetivo de testar e executar aplicações em uma espécie de sandbox onde temos total controle sobre as bibliotecas ali instaladas.

Instalando as diferentes versões do Python

O primeiro passo é instalar as versões do Python a serem usadas nos testes. Rode o comando abaixo para instalar os diferentes interpretadores, supondo que você utilize Debian e sua aplicação precise funcionar nas versões 2.4, 2.5 e 2.6 do Python:

$ sudo apt-get install python2.4 python2.4-dev \
    python2.5 python2.5-dev \
    python2.6 python2.6-dev

A versão atual do Ubuntu já inclui o Python 2.6 por padrão. Veja também que aproveitamos para instalar os arquivos de desenvolvimento para cada versão, pois eventualmente precisamos deles para compilar bibliotecas com extensões escritas em C.

Instalando Fabric e VirtualEnv

Da mesma forma:

$ sudo apt-get install python-setuptools

Após a instalação do SetupTools, execute o seguinte comando para instalar o Fabric e o VirtualEnv:

$ sudo easy_install Fabric virtualenv

Configurando ambientes isolados para sua aplicação

O próximo passo é criar ambientes de execução isolados para sua aplicação, sendo que cada ambiente deve usar uma versão diferente do interpretador do Python. Para fazer isso, execute os comandos abaixo, substituindo o APP pelo nome da sua aplicação ou biblioteca:

$ mkdir ~/.virtualenvs
$ cd ~/.virtualenvs
$ virtualenv --python=/usr/bin/python2.6 --no-site-packages APP-py2.6
$ virtualenv --python=/usr/bin/python2.5 --no-site-packages APP-py2.5
$ virtualenv --python=/usr/bin/python2.4 --no-site-packages APP-py2.4

Primeiramente criamos o diretório ~/.virtualenvs, que é por convenção o diretório padrão para armazenamento dos ambientes. Em seguida, criamos três ambientes para nossa aplicação APP. A flag --no-site-packages é opcional e indica que as bibliotecas instaladas no diretório site-packages do Python em questão não devem ser visíveis ao ambiente sendo criado.

Finalmente, não esqueça de instalar, em cada um dos ambientes, as dependências exigidas pela sua aplicação:

$ source ~/.virtualenvs/APP-py2.6/bin/activate
(APP-py2.6) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN
(APP-py2.6) $ source ~/.virtualenvs/APP-py2.5/bin/activate
(APP-py2.5) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN
(APP-py2.5) $ source ~/.virtualenvs/APP-py2.4/bin/activate
(APP-py2.4) $ easy_install biblioteca1 biblioteca2 ... bibliotecaN

Supondo que sua aplicação utilize o SetupTools para a configuração dos metadados do projeto (através do script setup.py), os comandos abaixo devem indicar se a aplicação funciona nos ambientes que criamos:

$ source ~/.virtualenvs/APP-py2.6/bin/activate
(APP-py2.6) $ python setup.py test
...
(APP-py2.6) $ source ~/.virtualenvs/APP-py2.5/bin/activate
(APP-py2.5) $ python setup.py test
...
(APP-py2.5) $ source ~/.virtualenvs/APP-py2.4/bin/activate
(APP-py2.4) $ python setup.py test
...

Automatizando!

Se tudo funcionou até aqui, estamos prontos para criar um script que nos permita rodar os testes de forma automática, nos diferentes ambientes.

Supondo que sua aplicação utilize o SetupTools para a configuração dos metadados do projeto, o exemplo abaixo resolve o problema:

# -*- coding: utf-8 -*-
 
# Environment info
config.project = 'APP'
config.virtualenv_dir = '~/.virtualenvs'
 
# Supported Python versions
config.versions = ('2.4', '2.5', '2.6',)
config.default_version = '2.6'
 
def setup(command, version=config.default_version):
    """Executes the given setup command with a virtual Python installation.
    """
    local('%s/%s-py%s/bin/python setup.py %s' % (config.virtualenv_dir, config.project, version, command))
 
def test():
    """Runs all tests in different Python versions.
    """
    for version in config.versions:
        setup('test', version)

Agora é só alegria:

$ fab test
Fabric v. 0.1.1.
Running test...
[localhost] run: ~/.virtualenvs/APP-py2.4/bin/python setup.py test
...
[localhost] run: ~/.virtualenvs/APP-py2.5/bin/python setup.py test
...
[localhost] run: ~/.virtualenvs/APP-py2.6/bin/python setup.py test
...

Devo lembrar que o script mostrado é só um exemplo. Você pode (e deve) modificá-lo para que este atenda às suas necessidades.

(Bônus!) Distribuindo sua aplicação para diferentes versões do Python

Com mais algumas linhas de código, podemos criar tasks que nos permitam gerar arquivos para distribuição da aplicação para diferentes versões do Python:

def dist_src():
    """Create source archive.
    """
    setup('sdist')
 
def dist_eggs():
    """Create binary archives, one for each Python version.
    """
    for version in config.versions:
        setup('bdist_egg', version)

(Bônus!) Automatizando geração de documentação e upload para o PyPI

Ainda acha pouco? Este outro exemplo de script vai além e mostra, numa aplicação real, como automatizar o registro e upload dos pacotes para o PyPI, atualizar site de documentação, entre outras coisas.