splinter – Testando a sua aplicação com um navegador

É perfeitamente possível criar testes de aceitação em Django com a TestClient e lxml. Mas vamos ser sinceros, é deveras trabalhoso “parsear” os resultados das suas views.

Com a Splinter, uma ferramenta para testes de aplicações web, você pode automatizar ações executadas por navegadores, como visitar uma página, preencher um formulário ou clicar em um link; tudo isso sem preocupar-se com parsing, nós, DOM, nem nada do tipo:

from splinter.browser import Browser
browser = Browser()
# Visitar uma URL
url = "http://search.twitter.com"
browser.visit(url)
browser.fill('q', "#cobrateam") 
 
# Procurar e clicar no botão 'search'
button = browser.find_by_css("#searchButton input").first 
 
# Interagir com os elementos
button.click()
if browser.is_text_present("No results for #cobrateam"):
    print "nobody likes us =("
else:
    print "we're popular =)"

O que eu acho mais bacana nesta ferramenta são os seletores, facilitam muito na hora de checar resultados e comportamentos.

A comunidade em volta desta ferramenta está em constante crescimento e atividade. Portanto, caso você queira contribuir com o projeto, vá agora mesmo para o repositório no GitHub e colabore.

nose – Caçando testes em seu projeto (Python)

E quando queremos fugir da regra? Aposto que chegará um momento em que a estrutura de diretórios padrão, necessária para a execução dos seus testes em Django, não te satisfará mais. O que fazer neste caso? Simples, recorra ao Nose!

O Nose estende os recursos da unittest e facilita a escrita e carregamento dos testes em projetos Python. De uma forma mais detalhada, ele percorre o seu projeto (ou uma determinada região de seu escolha) executando subclasses da unittest.TestCase ou funções que contenham “test”. Por exemplo:

# test_subclasse.py
import unittest
 
class SubclasseTest(unittest.TestCase):
    def test_um_eh_verdadeiro(self):
        self.assertTrue(1)
 
# test_funcao.py
def test_zero_eh_falso():
    assert 0 == False

Ao executar o comando nosetests o nose se encarregará de procurar e carregar os testes:

$ nosetests
..
----------------------------------------------------------------------
Ran 2 tests in 0.005s
 
OK

É claro que existe uma “mágica” aí. Na verdade o nose pesquisará por arquivos Python com “test” em seu nome, por funções com “test” em seu enunciado, e por classes com métodos “test” em sua declaração. Ele age mesmo como um “runner“, tendo a capacidade de lidar com testes escritos com unittest ou não.

Essa é só a ponta do iceberg. É possível construir plugins para o nose, permitindo melhorar ainda mais o seu ambiente de testes (como por exemplo, permitir que o nose funcione em subprocess separados).

Caçando testes em seu projeto (Django)

Para facilitar ainda mais a escrita de testes em Django existem plugins como o django-nose, que permite que você substitua o Test Runner padrão da framework por um específico que utiliza o nose, unindo assim a facilidade e “add-ons” do nose com o ambiente de testes do Django.

lettuce - BDD em Django

E se você estava se perguntando sobre BDD em Django, eu apresento a Lettuce!

Esta ferramenta, baseada na Cucumber, permite com que você escreva estórias utilizando linguagem ubíqua, mais próxima da área de negócios do que da área técnica, e automatize a validação delas.

O mais bacana é que ela já vem preparada para o Django, permitindo que a gente execute os testes de comportamento de forma fácil e rápida:

Feature: Rocking with lettuce and django
 
    Scenario: Simple Hello World
        Given I access the url "/"
        Then I see the header "Hello World"
 
    Scenario: Hello + capitalized name
        Given I access the url "/some-name"
        Then I see the header "Hello Some Name"

Estória escrita, vamos escrever o script Python que validará se está tudo de acordo:

from lettuce import *
from lxml import html
from django.test.client import Client
 
@before.all
def set_browser():
    world.browser = Client()
 
@step(r'I access the url "(.*)"')
def access_url(step, url):
    response = world.browser.get(url)
    world.dom = html.fromstring(response.content)
 
@step(r'I see the header "(.*)"')
def see_header(step, text):
    header = world.dom.cssselect('h1')[0]
    assert header.text == text

Basta executá-lo da seguinte maneira:

$ python manage.py harvest

Confira mais informações sobre como utilizar o lettuce com Django.

fudge – Ajude o Python a mentir

O Fudge é um módulo Python que auxilia na construção de objetos “dublês” (mocks e stubs), que permitem escrever testes sem necessariamente possuir um serviço ativo ou um objeto construído.

Um caso comum: Você está construindo uma API que autentica via OAuth ao Twitter e está utilizando testes para guiar o seu desenvolvimento. Não é interessante que nossos testes sejam dependentes da disponibilidade do serviço do Twitter, portanto, escrevemos um “objeto mentiroso”, que simulará este serviço, aceitando uma entrada e gerando um saída:

import fudge
@fudge.patch('oauthtwitter.OAuthApi')
def test(FakeOAuthApi):
        (FakeOAuthApi.expects_call()
            .with_args('', '',
                         '', '')
            .returns_fake()
            .expects('UpdateStatus').with_arg_count(1))
 
post_msg_to_twitter("hey there fellow testing freaks!")

Pronto! Sabendo que valores serão passados, e quais os resultados, podemos simular o comportamento daquele serviço. Prático, não?

Considerações finais

Estas são as ferramentas que eu costumo utilizar em meus projetos Python/Django. É claro que existem outras, na verdade existem várias. Tenha em mente que a ferramenta é apenas um meio de garantir, através de testes, que você está guiando a sua aplicação para o lugar certo. Os testes automatizados no final servem para garantir que ela ainda segue este caminho, que contribuições realizadas tardiamente não “quebraram” o comportamento que você escreveu no início do desenvolvimento.

Tenho a intenção de escrever um post mais prático sobre testes e Django. Fiquem no aguardo

E você? Tem alguma ferramenta para recomendar? Utilize os comentários abaixo para compartilhá-la.

Referências

• CillianO – Django Full Stack Testing and BDD with Lettuce and Splinter
• Danilo Sato – Introduzindo Desenvolvimento Orientado por Comportamento (BDD)
• django-nose – GitHub repository
• Fudge – Using Fudge
• JPz’log – nose: Testing in Python made easy
• Nose – Writing tests
• Splinter – Test framework for web applications

Até a próxima…

Fonte: Klaus Laube

Afinal, testar é preciso

Testar em Django é possível?

Sem dúvida nenhuma! Mas não espere que o framework adeque-se a você, você precisa ter a iniciativa de tentar compreender as melhores maneiras para escrever testes em Django.

Por exemplo, se você tem por hábito isolar os modelos para testá-los de forma unitária, pode passar por certa dor de cabeça com o Python/Django. Não que seja impossível, mas o comportamento default do framework é criar uma base de dados “fake” para você não precisar ter este trabalho.

Enfim, talvez a forma de utilizar estas ferramentas caiba em um outro post, o objetivo deste é apenas apresentá-las.

unittest – Testando unidades através de classes

A unittest é uma biblioteca padrão do Python que ajuda (e muito) a escrever testes automatizados com a linguagem.

Os testes são escritos através de classes, onde utilizamos os esquemas de assertions para garantir o comportamento do código testado (nenhuma novidade até aqui). Para quem utiliza testes unitários no Java não vai sentir grandes mudanças na abordagem, já que a unittest é inspirada na JUnit (sendo muitas vezes até chamada de PyUnit):

import unittest
from myapp.models import Animal
 
class AnimalTestCase(unittest.TestCase):
    def setUp(self):
        self.lion = Animal.objects.create(name="lion", sound="roar")
        self.cat = Animal.objects.create(name="cat", sound="meow")
 
    def testSpeaking(self):
        self.assertEquals(self.lion.speak(), 'The lion says "roar"')
        self.assertEquals(self.cat.speak(), 'The cat says "meow"')

O test runner padrão do Django irá procurar por subclasses de unittest.TestCase nos arquivos models.py e tests.py. A suíte de testes tenta facilitar ao máximo a sua vida… execute a seguinte instrução e confira se a sua aplicação está ok ou não:

$ python manage.py test

Peraí que não acabou! Apresentando a TestCase

Testar aplicações Web com a unittest pode ser dureza. Pensando nisso o Django disponibiliza a TestCase, que estende a unittest adicionando funcionalidades como carregamento de fixtures, roteamento de urls e um client para fazer requisições Web e testar as suas views (o TestClient, detalhado mais abaixo).

doctest – Testando através de docstrings

Admito que escrever documentação de software não é o meu forte… mas com doctests pode-se documentar métodos ao mesmo tempo em que escreve-se testes!

A doctest é uma biblioteca padrão do Python que procura e interpreta docstrings na aplicação. A sintaxe nesses trechos de docstrings é diferenciada, simulando um interpretador interativo do Python:

# models.py
 
from django.db import models
 
class Animal(models.Model):
    """
    An animal that knows how to make noise
 
    # Create some animals
    >>> lion = Animal.objects.create(name="lion", sound="roar")
    >>> cat = Animal.objects.create(name="cat", sound="meow")
 
    # Make 'em speak
    >>> lion.speak()
    'The lion says "roar"'
    >>> cat.speak()
    'The cat says "meow"'
    """
    name = models.CharField(max_length=20)
    sound = models.CharField(max_length=20)
 
    def speak(self):
        return 'The %s says "%s"' % (self.name, self.sound)

Assim como com a unittest, o test runner padrão do Django procurará por ocorrências de docstests em models.py e tests.py.

Django Test Client – Testando a sua aplicação como se fosse um navegador

E como fazer para testar requisições Web? Por exemplo, você não quer testar a sua view de forma isolada, quer testar desde a parte de roteamento ao comportamento com o banco de dados, como se você se estivesse realmente visitando a página. Neste caso entra a test client.

Toda a classe TestCase possui uma instância da Django Test Client. Então escrever testes com requisições à sua aplicação fica muito simples utilizando classes:

from django.test import TestCase
 
class SimpleTest(TestCase):
    def test_details(self):
        response = self.client.get('/customer/details/')
        self.assertEqual(response.status_code, 200)
 
    def test_index(self):
        response = self.client.get('/customer/index/')
        self.assertEqual(response.status_code, 200)

É perfeitamente possível utilizar a test client em doctests também:

"""
>>> from django.test.client import Client
>>> c = Client()
>>> response = c.post('/login/', {'username': 'john',
...        'password': 'smith'})
>>> response.status_code
200
"""

Considerações finais

Particularmente, tive a oportunidade de implementar testes unitários já no início do meu aprendizado em Django. Deixar os testes te guiarem é uma prática excelente!

Tudo parte do bom senso, óbvio. Nenhum processo ou ferramenta deveria substituir o “feeling” do profissional… também não é muito sadio ser extremamente “by the book“. Mas se puder utilizar testes para guiar o seu desenvolvimento, use-os!

Na segunda parte deste post pretendo apresentar algumas ferramentas que irão turbinar ainda mais o seu desenvolvimento orientado a testes.

Até lá!

Referências

• Django Documentation – Writing unit tests
• Django Documentation – Writing doctests
• Django Documentation – TestCase
• Python Documentation – unittest: Unit testing framework
• Dougal Matthews – Testing your first Django app
• Konrad’s Kode, Konfigs & Konstructions – Testing Django
• Marinho Brandão – Programação dirigida a testes no Django

Fonte: Klaus Laube

Para vocês que desenvolvem em Python e Django preocupando-se com internacionalização, já devem ter feito a seguinte pergunta: Quando usar gettext e gettext_lazy?

Acredito que antes de responder esta pergunta, temos que responder outra questão pertinente: Devo utilizar gettext ou ugettext?

gettext vs ugettext

Essas duas funções seguem o mesmo princípio dos métodos mágicos __str__ e __unicode__. Onde gettext retornará um texto traduzido como uma string “comum”, e ugettext retornará um texto traduzido como uma string Unicode.

Como nosso idioma nativo abusa do uso de caracteres especiais, aconselho sempre que possível a utilização do ugettext. Na verdade, é uma forma de garantir sucesso na tradução de qualquer idioma sem quebrar a cabeça com encoding (já que o Unicode tem uma ampla tabela  de caracteres).

Além disso, passe a mensagem como Unicode para a função sempre que necessário:

texto_traduzido = ugettext(u'Descrição do produto em estoque')

ugettext vs ugettext_lazy

A principal diferença entre ugettext e ugettext_lazy é que o último é literalmente um preguiçoso. Ele faz uma referência para a string (e não necessariamente para a tradução), fazendo com que a operação seja executada apenas quando a renderização da string é necessária (ao contrário de ugettext que é processado assim que a expressão é interpretada).

Confuso? Talvez o Marinho Brandão possa ser mais claro:

A função "ugettext_lazy()" é preguiçosa. Isso significa que a 
tradução é feita somente quando ela é requisitada, o que é
relativamente melhor para o caso de classes de modelo, pois elas
são constantemente utilizadas sem que a tradução de um termo seja
necessário de fato.

Por outro lado a função "ugettext()" traduz a string
instantaneamente, o que é melhor para casos como o de formulários
dinâmicos e views, pois eles não são usados de maneira tão constante
quanto classes de modelo.

Então… utilize ugettext_lazy nos campos e meta-informações dos modelos (onde a tradução pode ser feita sob demanda), e ugettext em métodos, funções e views (onde a tradução tem quer ser “instantânea”).

Referências

• Python Documentation – gettext
• Django Documentation – Internationalization
• The Django Book – Internationalization
• Aprendendo Django no Planeta Terra – O mesmo site em vários idiomas

Até a próxima…

Fonte: Blog Klaus Laube

Dando continuidade a micro-série “Como versionar projetos Django com o Mercurial” (confira a parte 1 e a parte 2), vamos finalizar com um exemplo prático de um projeto Django usando o  Mercurial.

Começando…

Vamos reutilizar a estrutura dos posts anteriores. Para isso, inicie um projeto com o virtualenv:

$ cd ~/Projetos/
$ virtualenv DjangoComHG --no-site-packages
$ cd DjangoComHG/

Vamos aproveitar os procedimentos descritos na parte 2 deste post. Caso você ainda não tenha criado um repositório no Bitbucket, essa é uma boa oportunidade.

$ hg clone <caminho> django_com_hg

Não esqueça de mudar o caminho para o endereço do seu repositório.

Instalando o Django

Com o virtualenv ativado, vamos instalar o Django apenas para o nosso ambiente virtual através do pip:

$ source bin/activate
$ pip install django

Só para ter certeza que ele instalou o Django dentro do nosso ambiente virtual, vamos abrir o terminal do Python e digitar as seguintes instruções:

$ import django
$ django.__path__

Você deverá obter como resposta uma string semelhante a esta:

$HOME/Projetos/DjangoComHG/lib/python2.6/site-packages/django/

Iniciando um projeto

Vamos fazer uma pequena brincadeira de troca de nomes de pastas, para que possamos criar o nosso projeto Django com o mesmo nome do repositório Mercurial:

$ mv post_django_com_hg post_django_com_hg.bk

Agora mandamos o django-admin.py iniciar o projeto:

$ django-admin.py startproject post_django_com_hg

Movemos os arquivos do nosso repositório para dentro de post_django_com_hg:

$ mv post_django_com_hg.bk/* post_django_com_hg/
$ mv post_django_com_hg.bk/.hg post_django_com_hg/
$ mv post_django_com_hg.bk/.hgignore post_django_com_hg/

Entre no diretório post_django_com_hg e dê um hg status. Os arquivos base do Django não estão no projeto. Vamos adicioná-los, comitá-los e dar um push deles para o repositório Mercurial no Bitbucket:

$ hg add .
$ hg commit -m "Projeto Django iniciado"
$ hg push

Nos changesets do repositório, veremos a contribuição enviada:

Pronto! Basicamente, para termos o Mercurial versionando um projeto Django, são estes os procedimentos… mas eu sei como deixar a coisa ainda mais interessante

Hora de congelar!

Digamos que você tenha um colaborador envolvido com o projeto. Quer dizer que ele vai ter que criar um virtualenv, clonar o repositório e instalar as dependências do projeto? A resposta é “sim” – Mas podemos facilitar esta última parte através do pip:

$ pip freeze
Django==1.3
wsgiref==0.1.2

O comando pip freeze vai coletar os pacotes Python instalados (nesse nosso caso, dentro do nosso ambiente virtual através do virtualenv) e exibir para a gente em formato de lista. Com isso, podemos criar um arquivo que armazene as dependências do nosso projeto:

$ pip freeze > requirements.txt

Vamos desativar o ambiente atual, criar um novo e instalar as dependências listadas nesta arquivo requirements.txt neste novo ambiente:

$ deactivate
$ cd ~/Projetos/
$ virtualenv DjangoComHG-2 --no-site-packages
$ source DjangoComHG-2/bin/activate
$ pip install -r DjangoComHG/post_django_com_hg/requirements.txt

Veja a mágica acontecendo… o pip instalará todas as dependências contidas em requirements.txt em nosso novo ambiente virtual.

Podemos resumir os comandos acima em:

$ pip install -E DjangoComHG-2 -r DjangoComHG/post_django_com_hg/requirements.txt

Versionando dependências do projeto

Logo o requirements.txt sendo um arquivo de texto, pode ser facilmente versionado pelo Mercurial:

$ cd ~/Projetos/DjangoComHG/post_django_com_hg
$ hg add requirements.txt
$ hg commit -m "Adicionado arquivo de dependências do pip"
$ hg push

Finalmente, temos um projeto Django versionado com Mercurial, disponível no Bitbucket, e com dependências facilmente gerenciáveis através do pip em conjunto com o virtualenv.

E você… utiliza controle de versão com o Django de uma outra forma? Conte-nos através dos comentários abaixo.

Até a próxima…

Fonte: Blog Klaus Laube

hg? Mas não era Mercurial?

Mercury em português significa mercúrio (nenhuma novidade até aqui), que é um elemento químico com o símbolo Hg e o número atômico 80 (assim disse a Wikipedia (:  ).  É devido a isso que você utilizará o Mercurial em linha de comando através de comandos iniciados por hg.

Antes de iniciarmos, vamos dizer ao Mercurial quem nós somos. Abra o arquivo .hgrc do seu home:

$ vim ~/.hgrc

É fundamental que nossos commits estejam marcados com nosso nome, e um e-mail para contato. Vamos escrever estas duas informações neste arquivo:

[ui]
username = seu nome <seuemail@provedor.com>

Salve o arquivo… e estamos prontos para iniciar.

Primeiros passos…

Os passos que vou exemplificar aqui não são muito diferentes dos que você encontrará na página oficial do Mercurial. Preguiça minha? Talvez… mas você verá que usar o Mercurial é extremamente simples! As dificuldades são as exceções do dia-à-dia.

Para deixar o exemplo mais interessante, vamos utilizar o virtualenv. Dúvidas? Confira o post Python, Django e virtualenv e visualize aonde pretendemos chegar:

$ cd ˜/Projetos/
$ virtualenv DjangoComHG --no-site-packages
$ cd DjangoComHG

Agora sim, vamos criar um projeto através da seguinte expressão:

$ hg init django-com-hg

Projeto criado… vamos partir para as tarefas mais comuns no Mercurial.

Altere, adicione e “comite”

O Mercurial é DVCS, isto quer dizer que, quando você clonar um repositório remoto você terá uma cópia exata dele em seu computador. Logo, as alterações que você “persistir” estarão disponíveis apenas na sua cópia local. Pode parecer um pouco confuso, mas com o tempo faz todo o sentido.

Para o primeiro commit (persistir nossas alterações localmente) escreva um arquivo .hgignore (saiba mais do que se trata) e um arquivo README:

$ cd django-com-hg/
$ ls -a

.hg     .hgignore     README

A pasta .hg na verdade é quem vai identificar e armazenar todas as informações do nosso projeto. Sem ela, você deixa de ter o controle sobre as versões dos arquivos e subpastas do projeto.

Execute o comando hg status e veja o que aparece… acredito que o resultado seja auto-sugestivo. O Mercurial ainda não sabe o que fazer com os arquivos no projeto, portanto diremos a ele que queremos versionar estes arquivos:

$ hg add .hgignore README

Uma nova execução do hg status vai apontar que os arquivos foram marcados para adição, porém, ainda não foram adicionados. Você vai confirmar está operação através do comando commit:

$ hg commit -m "Primeiro commit com .hgignore"

O parâmetro -m serve para passarmos uma mensagem de descrição do commit que estamos fazendo. Isto facilita na leitura do log de commits realizados:

$ hg log

Estes serão os comandos que provavelmente você usará constantemente enquanto desenvolve.

Compartilhando as suas produções

Se você ainda não tem uma conta no Bitbucket, essa é uma grande oportunidade para fazer uma.

Vamos criar um repositório para praticarmos o comando push. No Bitbucket:

• Eu vou dar o nome de “post-django-com-hg” ao repositório, fique a vontade para dar o nome que você desejar;
• Escolha o Python como linguagem;
• Coloque uma pequena descrição;
• Eu vou marcar a opção Issue tracking, caso haja algum problema com o código e vocês queiram sugerir melhorias.

Confira o resultado.

No repositório local vamos utilizar o comando push com o endereço do repositório no Bitbucket. Isso enviará todas as alterações que persistidas em nosso repositório local para o repositório remoto, mesclando-as com as contribuições de outros usuários envolvidos no projeto:

$ hg push https://bitbucket.org/kplaube/post-django-com-hg

Lembre-se de mudar o endereço acima para o endereço do seu repositório no Bitbucket. Visite a página do seu repositório e veja o que aconteceu… bacana, não?

Mas dessa forma, teremos que sempre executar o comando push informando o endereço do repositório. Vamos deixar esta tarefa mais simples editando o arquivo hgrc dentro da pasta .hg do projeto:

$ cd ~/Projetos/DjangoComHG/django-com-hg/
$ vim .hg/hgrc

Coloque o seguinte:

[paths]
default = https://kplaube@bitbucket.org/kplaube/post-django-com-hg

Lembre-se de mudar o endereço acima para o endereço do seu repositório no Bitbucket.

Pronto! Quando você for “pushear” não precisará mais informar o endereço do repositório remoto.

Altere alguns arquivos… commit. Adicione alguns arquivos… commit. Ao final do dia, dê um push e deixe o resto da equipe saber o que você fez

Referências

• Site oficial do projeto Mercurial
• Artigo na Wikipedia sobre Mercurial
• Artigo na Wikipedia sobre Mercúrio (o elemento químico)
• Mercurial Hg – Controlando as Versões do seu Software
• Mercurial: The Definitive Guide

No próximo post, vamos concluir a trilogia mostrando uma forma bacana de utilizar o Mercurial para versionar seus projetos Django.

Até a próxima…

Fonte: Blog Klaus Laube

Se você está começando em Django, e nunca utilizou uma ferramenta de controle de versão (as vezes por trauma do SVN ou por simples desinteresse) esta será uma grande oportunidade para você conhecer o Mercurial, e saber a forma que venho utilizando para versionar meus projetos Django.

Peraí! Por que não Git?

Sem dúvida o Git é a ferramenta do momento em se tratando de controle de versões, e vem sendo muito utilizada por rubistas e pythonistas (eu incluso nessa última galera).

Por que não falar de Git aqui? Simples! Você vai ouvir falar sobre Git em todo o lugar. O Google vai te trazer toneladas de informações sobre Git. Você vai “ouvir” o pessoal falando que Git é melhor do que qualquer outra ferramenta. Você vai até enjoar de tanto ouvir falar sobre Git.

O Mercurial foi o primeiro DVCS que utilizei (de verdade). Na minha opinião, ele é mais simples que o Git, é feito em Python, e me atende no desenvolvimento dos meus projetos pessoais.

Concordo com o pessoal que diz que o Git é bom, e concordo com o pessoal que fala que o Mercurial é bom. É perfeitamente possível utilizar estas duas ferramentas, não precisamos ser radicais e iniciar um flame em cima deste assunto. A opção é melhor que não ter opção…

GitHub x Bitbucket

Agora uma coisa eu não posso deixar de concordar: O GitHub é (na minha opinião) melhor que o Bitbucket.

Ambos são repositórios de código na nuvem, o primeiro usando Git e o segundo usando Mercurial. O detalhe é que o Git tem algumas funções mais apuradas que o Bitbucket, principalmente as funcionalidades que tornam a ferramenta muito mais “social”.

Embora o Bitbucket recentemente tenha sido adquirido pela Atlassian e tenha recebido uma forte injencão de melhorias… o GitHub ainda é, para mim, a melhor forma de compartilhar código que existe no momento.

Venho utilizando o Bitbucket pela opção de poder manter repositórios de código “fechados”. Coisa que com o “rival” só é possível através de uma conta paga.

Mais uma vez… é perfeitamente possível viver utilizando as duas ferramentas.

Na próxima parte deste post vamos abordar o básico do Mercurial, e também pretendo mostrar como organizo os meus projetos Django “versionando-os” com o Mercurial e Bitbucket.

Até a próxima…

Fonte: Blog Klaus Laube

Pretendo compartilhar com vocês a forma que venho utilizando para organizar meus projetos Django com o uso do virtualenv. Não entrarei em muitos detalhes, até porque você verá que é um procedimento muito simples, mas que poderá garantir melhor organização dos seus projetos e dos seus ambientes de desenvolvimento.

É interessante que você leia o post “Python, Django e virtualenv” antes de continuar.

Simplesmente um projeto Django

Antes de conhecer (e utilizar) o virtualenv, utilizei algo parecido com o modelo “tradicional”  de organização de pastas e códigos em um projeto Django. Ou seja, parecido com aquela estrutura padrão gerada pelo comando django-admin.py startproject.

O modelo é bom, e funcionou para mim durante muito tempo. Mas de uns tempos para cá venho utilizando o esquema abaixo (confira um exemplo real):

mysite/
    apps/
        __init__.py
        eggs/
            fixtures/
                eggs_testdata.json
            tests/
                __init__.py
                models.py
                views.py
            __init__.py
            models.py
            urls.py
            views.py
    core/
        __init__.py
        extras.py
    __init__.py
    manage.py
    settings.py
    urls.py

A diferença principal está na utilização da pasta apps para encapsular as aplicações do projeto, e a criação de uma pasta (ou pacote, como preferir) core. Nesta última, gosto de armazenar snippets de código que serão aproveitados pelo projeto inteiro.

Outro ponto que vale ser notado é a criação de uma pasta chamada tests para cada app. Embora haja casos em que um arquivo tests.py seja o suficiente, podemos nos deparar com um arquivo gigantesco testando vários aspectos de uma app (o que pode dificultar a legibilidade de código). Categorizar os testes por tipo, e em arquivos separados, irá facilitar a adição de novos testes e funcionalidades.

A abordagem dos testes também pode ser utilizada para o urls.py. Quando o seu arquivo de roteamento ficar muito grande, crie uma pasta urls e “quebre” suas rotas em arquivos diferentes. Categorize-os, sinta-se “zen” e nunca mais tenha medo de criar URLs novamente

Comecei a utilizar esta estrutura após “xeretar” alguns projetos Django open source. Posso dizer por experiência própria que é uma prática interessante, e que tem me ajudado muito na organização de código.

O projeto Django com o virtualenv

Tratando-se do ambiente de desenvolvimento (construído pelo virtualenv), já utilizei-o de duas formas:

• O environment em uma pasta separada do projeto: Você pode possuir uma pasta “environments” e lá ter diferentes ambientes para diferentes projetos.
• O projeto Django ficar dentro da pasta de environment: Você primeiramente constrói um ambiente com o virtualenv, e depois cria um projeto dentro dessa mesma pasta (como demonstrado neste post do Osvaldo Santana).

Particularmente eu prefiro a segunda opção (nunca precisei de 2 environments idênticos). Além de manter todo o seu projeto agrupado, fica mais fácil para criação de scripts de automatização de deploy, por exemplo.

No fim das contas, geralmente a estrutura de pastas dos projetos Django fica assim:

MySiteProject/
    bin/
    include/
    lib/
    mysite/
        apps/
            __init__.py
            eggs/
                fixtures/
                    eggs_testdata.json
                tests/
                    __init__.py
                    models.py
                    views.py
                __init__.py
                models.py
                urls.py
                views.py
        core/
            __init__.py
            extras.py
        __init__.py
        manage.py
        settings.py
        urls.py

E você? De que forma organiza os seus projetos em Django? Conte-nos através dos comentários abaixo!

Até a próxima…

Fonte: Blog Klaus Laube

Você está começando em Python e vive ouvindo falar sobre um tal de virtualenv? Pois bem, vamos aproveitar para dar uma pincelada nesta útil ferramenta, e como usá-la com nossos amigos Python e Django.

Python

Conheça alguns motivos que lhe convencerão a usar Python.

O Python já vem instalado na maioria das distribuições Linux. Na verdade, até hoje nunca usei uma distro Linux que não tivesse o Python préviamente instalado. No Slackware 13.1, o Python está na versão 2.6.4. No Debian 6, o Python está na versão 2.6.6.

O portal Python Brasil possui um excelente material para você instalar e dar os primeiros passos com Python.

virtualenv

A linguagem Python não vem “de bobeira” nas distribuições Linux, ela faz parte delas, sendo utilizada para criação de uma série de scripts fundamentais. Passei por uma situação peculiar com o Python: estava usando o OpenSuse (não recordo a versão) e decidi atualizar a versão do Python utilizando o sistema de pacotes da distro… confirmei algumas operações de remoção (que não deveria ter autorizado) e acabei danificando minha instalação do SO.

Então, para aqueles que programam em computadores pessoais, e não querem comprometer tanto o SO quanto o workspace, podem criar ambientes isolados para os projetos utilizando o virtualenv.

No Slackware vamos instalar o setuptools, que é um framework que facilita a instalação e criação de pacotes Python:

wget http://peak.telecommunity.com/dist/ez_setup.py

Para instalá-lo é necessário ser root:

python ez_setup.py

Em seguida, vamos instalar o virtualenv com a ajuda do easy_install (que faz parte do pacote setuptools):

easy_install virtualenv

Esta é uma forma interessante para você instalar módulos Python em seu sistema sem recorrer ao sistema de pacotes do SO.

Agora, como um usuário comum, vamos criar um ambiente em nosso home para testarmos o virtualenv:

virtualenv ~/projeto_django

Entrando nesta pasta, você irá se deparar com três diretórios:

• bin: Os executáveis do seu ambiente isolado estarão aí. Você poderá notar o executável python, o easy_install, o pip e um carinha chamado “activate” (falaremos deste mais tarde).
• lib: Nesta pasta você encontrará os módulos e bibliotecas Python utilizadas por este ambiente.
• include: Segundo o Osvaldo Santana, dentro desse diretório estão os links simbólicos para todos os headers do Python que são necessário para se compilar extensões escritas em C para ele.

Você apenas criou seu ambiente… para ativá-lo basta dar o seguinte comando:

source ~/projeto_django/bin/activate

Pronto! Se você executar o Python agora, você estará utilizando as libs deste ambiente. Isso pode permitir que você mova este ambiente entre máquinas, que você instale libs somente neste ambiente (deixando o Python do seu SO “limpo”, isso pode te garantir maior performance da distro) e que você tenha um controle maior sobre as dependências do seu projeto.

Para “sair” do ambiente, basta executar o comando deactivate:

deactivate

Pronto… muito simples, não?

Django

Saiba um pouco mais sobre a programação Python para Web.

Vamos instalar o Django neste ambiente isolado. Ativaremos novamente o virtualenv e usaremos o easy_install para nos ajudar com esta tarefa:

source ~/projeto_django/bin/activate 
easy_install django

No final da operação, você irá se deparar com uma saída similar a esta:

Installed /home/user/projeto_django/lib/python2.6/site-packages/
Django-1.2.5-py2.6.egg 
Processing dependencies for django 
Finished processing dependencies for django

Isto é a garantia que o Django foi instalado dentro deste ambiente, e não está visível para o escopo global da distribuição. Tente importa o django no terminal interativo do Python da sua distro e do Python do seu ambiente isolado e veja o que acontece…

Entenda o que é o Django e como ele funciona.

Até a próxima…

Fonte: Blog Klaus Laube

p = Pessoa.objects.get(id=1)
carro = p.carro

Na primeira consulta, o Django busca na tabela de pessoas um registro único no qual o atributo id tem valor 1. Na segunda consulta, o Django busca na tabela de carros o carro que possui o valor da foreign key correspondente ao id do objeto p (instância da classe Pessoa).

Partindo deste pressuposto, é possível ver um número muito grande de problemas. Se for dado um novo modelo de classes, com seis classes: Cliente, Bairro, Cidade, UF, Pais e Continente. Essas classes possuem relacionamentos em cascata: Cliente com Bairro, Bairro com Cidade, e assim sucessivamente, até Continente. Qual seria o comportamento do Django ao tentar acessar o continente de um determinado cliente? O interpretador interativo do Python responde esta questão de maneira bem simples:

>>> cliente = Cliente.objects.get(id=1)
>>> continente = cliente.bairro.cidade.uf.pais.continente
>>> from django.db import connection
>>> queries = connection.queries
>>> for query in queries:
...    print query
...
{'time': '0.003', 'sql': u'SELECT "clientes_cliente"."id", "clientes_cliente"."nome", "clientes_cliente"."idade", "clientes_cliente"."bairro_id" FROM "clientes_cliente" WHERE "clientes_cliente"."id" = 1 '}
{'time': '0.000', 'sql': u'SELECT "clientes_bairro"."id", "clientes_bairro"."nome", "clientes_bairro"."cidade_id" FROM "clientes_bairro" WHERE "clientes_bairro"."id" = 1 '}
{'time': '0.000', 'sql': u'SELECT "clientes_cidade"."id", "clientes_cidade"."nome", "clientes_cidade"."uf_id" FROM "clientes_cidade" WHERE "clientes_cidade"."id" = 1 '}
{'time': '0.000', 'sql': u'SELECT "clientes_uf"."id", "clientes_uf"."sigla", "clientes_uf"."pais_id" FROM "clientes_uf" WHERE "clientes_uf"."id" = 1 '}
{'time': '0.000', 'sql': u'SELECT "clientes_pais"."id", "clientes_pais"."nome", "clientes_pais"."continente_id" FROM "clientes_pais" WHERE "clientes_pais"."id" = 1 '}
{'time': '0.000', 'sql': u'SELECT "clientes_continente"."id", "clientes_continente"."nome" FROM "clientes_continente" WHERE "clientes_continente"."id" = 1 '}
>>>

Aí está a resposta quanto ao comportamento do Django: duas linhas de código, seis consultas ao banco de dados. Se esta fosse uma informação muito importante em um sistema, é possível notar o quão doloroso seria manter tudo isso num banco de dados relacional. É necessária uma abordagem diferente, com apenas um join seis consultas virariam apenas uma e o programador poderia dormir sem medo do DBA.

A instrução select_related responde à esta necessidade: ao ver esta instrução, o Django sabe que ele tem que fazer os joins, e que ele deve “passear” por todos os relacionamentos obtendo os dados. Se o cliente for buscado no banco de dados utilizando select_related, o objeto estará completamente em memória, e não será necessário acessar o banco de dados novamente para obter informações de nenhum dos relacionamentos, o interpretador interativo prova isso:

>>> cliente = Cliente.objects.select_related().get(id=1)
>>> continente = cliente.bairro.cidade.uf.pais.continente
>>> from django.db import connection
>>> queries = connection.queries
>>> for query in queries:
...      print query
...
{'time': '0.010', 'sql': u'SELECT "clientes_cliente"."id", "clientes_cliente"."nome", "clientes_cliente"."idade", "clientes_cliente"."bairro_id", "clientes_bairro"."id", "clientes_bairro"."nome", "clientes_bairro"."cidade_id", "clientes_cidade"."id", "clientes_cidade"."nome", "clientes_cidade"."uf_id", "clientes_uf"."id", "clientes_uf"."sigla", "clientes_uf"."pais_id", "clientes_pais"."id", "clientes_pais"."nome", "clientes_pais"."continente_id", "clientes_continente"."id", "clientes_continente"."nome" FROM "clientes_cliente" INNER JOIN "clientes_bairro" ON ("clientes_cliente"."bairro_id" = "clientes_bairro"."id") INNER JOIN "clientes_cidade" ON ("clientes_bairro"."cidade_id" = "clientes_cidade"."id") INNER JOIN "clientes_uf" ON ("clientes_cidade"."uf_id" = "clientes_uf"."id") INNER JOIN "clientes_pais" ON ("clientes_uf"."pais_id" = "clientes_pais"."id") INNER JOIN "clientes_continente" ON ("clientes_pais"."continente_id" = "clientes_continente"."id") WHERE "clientes_cliente"."id" = 1 '}
>>>

Problema de consultas resolvido, DBA feliz = programador feliz = cliente feliz!

Depois de meses de desenvolvimento, a versão stable do Django 1.1 finalmente vê a “luz do dia”.

Com uma série de implementos, correções de bugs e aprimoramentos em segurança, o Django 1.1 já vinha enchendo de orgulho a sua comunidade, ainda mais agora com o anúncio da NASA declarando que utiliza Django em sua plataforma de cloud computing.

Nada como acordar pela manhã e saber que fez a escolha certa

Tá esperando o que pra baixar?

Até a próxima…