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.

• GNU and Richard Stallman dancing at FISL 10!
• GNU dancing at FISL 10
• GNU dancing warm-up at FISL 10

Assim que possível subirei também alguns vídeos, inclusive um onde Richard Stallman dança com Gnu. Imperdível!

Banner do evento

Quando voltei do meu primeiro fórum, em 2007, prometi a mim mesmo que faria o possível para não perder as edições seguintes. Felizmente, essa promessa vem sendo cumprida à risca, já que este será meu terceiro fórum. E a empolgação, como não podia deixar de ser, já está começando a tomar conta!

Nos vemos lá!

De um tempo para cá, eu fui contactado por alguns desses usuários perguntando sobre a possibilidade de ter o nosso projeto incluído na distribuição do Django, na forma de uma Contrib app. Eu achei a idéia excelente, pois eu penso que um framework como o Django deveria se preocupar em resolver um problema tão recorrente quanto este que o Django-flash se propõe a resolver.

Se você utiliza Django-flash em seus projetos, não deixe de acompanhar essa discussão. Se possível, nos dê sua opinião sobre o que poderia ser feito para melhorar ainda mais o projeto e, assim, facilitar sua inclusão no Django.

Como o mercado é dominado por linguagens imperativas, é bem difícil encontrar pessoas que realmente conheçam e utilizem linguagens funcionais com certa regularidade. Mas isso não significa, de forma alguma, que não há espaço para tais linguagens. Na verdade, a tendência é que elas ganhem cada vez mais espaço.

Por que aprender uma linguagem funcional?

Em linguagens imperativas, a programação de um software consiste basicamente na definição e manipulação de seu estado interno, conduzida de modo a resolver um determinado problema. Portanto, pode-se dizer que softwares escritos em tais linguagens são movidos a efeitos colaterais, pois a forma e a ordem com que seu estado interno é modificado é o que define o funcionamento do software.

Em softwares triviais isso não chega a ser um problema, mas quando falamos de softwares grandes e complexos, essa volatilidade complica, e muito, a vida de quem os desenvolve e os mantém.

Linguagens funcionais, por outro lado, são conhecidas por evitar efeitos colaterais ao máximo, e isso nos trás uma infinidade de vantagens. Assim como na matemática, executar uma função f(x) com o mesmo argumento N vezes produz sempre o mesmo resultado, e por isso:

1. o código fica muito mais fácil de entender, debugar e testar. Tudo o que você precisa saber sobre uma função está nos seus argumentos;
2. o código, por também contar com estruturas de dados imutáveis, pode ser executado de forma concorrente, com poucas ou quaisquer modificações, e você nunca terá de se preocupar com locks, condições de corrida, deadlocks e coisas do tipo;
3. o compilador pode fazer otimizações impossíveis de serem feitas em linguagens imperativas, como automaticamente paralelizar ou reordenar chamadas a funções;

Enfim, esse é só um resumo das vantagens que linguagens funcionais têm sobre linguagens imperativas. Confira os links no final deste post para saber mais.

Escolhendo a linguagem

Clojure, Erlang, Haskell, J, (Common) Lisp, Scheme. E essas são somente algumas das linguagens com forte base funcional disponíveis por aí.

Mas qual delas escolher? Cada pessoa segue um ritual diferente ao escolher uma nova ferramenta e por isso não sou eu quem irá te dizer qual delas escolher. O que eu posso fazer é dar algumas sugestões:

• Quer saber como tudo começou? Aprenda Common Lisp.
• Quer uma linguagem parecida com Lisp, mas que rode na JVM? Clojure pode ser uma boa.
• Quer uma linguagem com uma sintaxe sucinta e poderosa? Dê uma olhada em J.
• Quer uma linguagem que facilite a construção de softwares distribuídos e de alta disponibilidade? Vá de Erlang.
• Quer uma linguagem que mude a forma com que você pensa sobre programação? Aprenda qualquer uma delas!

Erlang e Haskell estão na minha mira mas, no momento, eu optei por aprender Clojure.

Praticar é essencial

Ok, escolhida a linguagem de programação, o próximo passo é ler muito e praticar mais ainda.

Para quem está interessado em aprender Clojure, material não falta. Apesar de bem nova (apenas 2 anos de existência), a linguagem vem ganhando popularidade e muito vêm sendo escrito sobre ela. Aliás, o primeiro livro sobre Clojure foi publicado recentemente pela Pragmatic Bookshelf. (Pode comprar sem medo, o livro é excelente)

Agora, independente da linguagem escolhida, uma forma interessante de aplicar os conhecimentos recém-adquiridos é tentar resolver os problemas propostos pelo Project Euler, um website com centenas de problemas do tipo “What is the value of the first triangle number to have over five hundred divisors?”. No começo eu sofri um pouco para pegar as manhas da linguagem, mas depois de ter resolvido uns 10-15 problemas desse tipo, eu sinto que as coisas estão começando a fazer sentido.

Aos interessados, eu acabei de disponibilizar no Github um projeto contendo as soluções, todas em Clojure, para alguns dos problemas propostos.

E vocês, o que recomendam?

Depois de algumas semanas pesquisando sobre Programação Funcional, eu me sinto como se tivesse deixado de lado um vício: meio assustador no início, mas melhor a cada dia que passa!

Aos que já conhecem ou trabalham regularmente com linguagens funcionais, que dica vocês dão para quem acabou de tomar a pílula vermelha?

Referências

• On Lisp Book (Obrigatório!);
• Functional Programming For The Rest Of Us (Obrigatório!);
• The Promises Of Functional Programming (Atualização);
• Programming Clojure;
• Clojure – Functional Programming for the JVM;

Alguns anos se passaram e a coisa ficou bem diferente. Conhecer JavaScript e suas peculiaridades é requisito obrigatório. Qualquer aplicação decente utiliza a linguagem em partes importantes do seu código, bibliotecas para as mais variadas funções são criadas a cada dia, as engines estão cada vez mais velozes. Isso tem que significar alguma coisa.

Teria o JavaScript deixado de ser uma linguagem de script e se tornado uma… plataforma?

Claro que o JavaScript tem problemas. Nada é perfeito. Só que antes de dizer que a linguagem é ruim, ou que não é tão “sexy” como Ruby (ui!), muitos esquecem que JavaScript é a linguagem (plataforma?) que dispõe da maior base de potenciais usuários. Maior até que ActionScript/Flash.

Se formos parar para pensar, isso nem é assim tão surpreendente: a única coisa que, por enquanto, impede que um usuário rode uma aplicação escrita em JavaScript é a ausência de um browser. Tirando os servidores, quais as chances de um computador não possuir um browser instalado? Praticamente zero, eu diria. E o mesmo vale para os smartphones, netbooks e outros dispositivos.

Por isso, aos que gostam de profetizar sobre qual será a próxima grande linguagem, fica a lição de que não existe uma bola de cristal que funcione. Afinal, ninguém imaginava que JavaScript, o então ex-patinho feio nascido em 1995, viria a chegar onde chegou.

E o melhor ainda está por vir.

Não deixe de baixar o livro e, claro, aprender Python. O único problema é que você provavelmente não irá querer olhar para trás…

Errata

O livro ainda é bem novo, por isso é meio óbvio que existem ajustes a serem feitos. Por isso, para ajudar a tornar o livro ainda melhor, eu resolvi dar a minha humilde contribuição.

Como infelizmente eu não consegui contato com o autor do livro, resolvi publicar aqui os erros que eu encontrei no mesmo.

Página 21

Creio que a explicação dos operadores lógicos and e or está simples demais, considerando que o público-alvo do livro é de desenvolvedores, ou seja, pessoas com um pouco mais de experiência na área. Trecho:

and: retorna verdadeiro se e somente se receber duas expressões que forem verdadeiras.

Na verdade, o operador and não retorna verdadeiro ou falso. Se ambos os operandos são valores considerados verdadeiros, ele retorna o último operando avaliado. Do contrário, ele retorna o primeiro operando considerado falso:

'' and True # Retorna: ''
0 and ''    # Retorna: 0
1 and True  # Retorna: True
True and 1  # Retorna: 1

A mesma idéia vale para o operador or. Trecho:

or: retorna falso se e somente se receber duas expressões que forem falsas.

Este operador também não retorna valores literais de verdadeiro ou falso, e sim o primeiro operando considerado verdadeiro ou o último considerado falso se não existirem operandos verdadeiros:

False or "" # Retorna: ''
True or 1   # Retorna: True
0 or 1      # Retorna: 1
False or [] # Retorna: []

Na minha opinião, desenvolvedores Python devem saber que os operadores and e or têm essas propriedades. Isso até ajuda a deixar os códigos mais “pythonicos”. Um exemplo (idiota, mas enfim) seria:

# Versão não muito pythonica
def not_so_good(**kwargs):
    params = kwargs
    if not kwargs:
        params = {'default': 1234}
    print params
 
not_so_good()         # Imprime: {'default': 1234}
not_so_good(a=1, b=2) # Imprime: {'a': 1, 'b': 2}
 
# Versão um pouco melhor
def good(**kwargs):
    params = kwargs or {'default': 1234}
    print params
 
good()         # Imprime: {'default': 1234}
good(a=1, b=2) # Imprime: {'a': 1, 'b': 2}

Páginas 27, 30, 75, 131, 140

Em vários lugares o autor diz que X é mais eficiente que Y, mas não especifica em que especificamente essa eficiência se traduz: menor consumo de memória, processamento mais rápido, coisas do tipo. Seria legal saber em que exatamente X é mais eficiente que Y.

Página 39

No 7o item da lista, faltou um espaço após a vírgula.

Página 92

Trecho:

Na herança múltipla, a nova classe deriva de várias classes já existentes. A diferença mais significativa em relação à herança simples é a ordem de resolução de métodos (em inglês, Method Resolution Order- MRO), que segue o chamado algoritmo diamante. No algoritmo diamante, a resolução será feita a partir da esquerda, descendo até encontrar a classe em comum entre os caminhos dentro hierarquia. Quando encontra a classe em comum, passa para o caminho à direita. Ao esgotar os caminhos, o algoritmo prossegue para a classe em comum e repete o processo.

A herança múltipla funciona de forma diferente em classes clássicas e classes de estilo novo. A “resolução diamante”, onde a pesquisa de herança é estritamente profunda primeiro, depois da esquerda para direita, é usada somente em classes clássicas. Nas classes de estilo novo, a pesquisa de herança é feita da esquerda para direita primeiro, depois em profundidade:

# Hierarquia de "classes clássicas"
class A: attr = 1
class B(A): pass
class C(A): attr = 2
class D(B, C): pass
 
d = D()
d.attr # Retorna: 1
 
# Hierarquia de "classes de estilo novo"
class A(object): attr = 1
class B(A): pass
class C(A): attr = 2
class D(B, C): pass
 
d = D()
d.attr # Retorna: 2

O código mostra claramente que, dependendo do tipo de classe (clássica ou de estilo novo), a resolução do atributo attr é feita de forma diferenciada.

Bom, por enquanto é isso! Espero que o autor leve esses pontos em consideração para fazer do livro Python para Desenvolvedores um livro ainda melhor!

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!

Consumo de memória do Firefox 3.0.7

Medo.