Acredito muito que a organização e a qualidade do código são benéficas para qualquer projeto, principalmente para aqueles que possuem alta rotatividade de profissionais. Padrões de projetos, padrões estruturais e de escrita facilitam a “assimilação” do que já foi produzido, facilita a manutenção e “orienta” as novas produções.

Se você tem problemas em decorar convenções e boas práticas, não desanime! O Python possui algumas ferramentas “bacanudas” que vão te auxiliar a deixar o software mais próximo do “estado da arte”, seja garantindo as convenções de código, seja avaliando a qualidade do mesmo.

Python Enhancement Proposals

As “PEPs“ (Python Enhancement Proposal) são documentos que geralmente abordam alguma nova funcionalidade da linguagem, propósitos, procedimentos ou ambiente. Em suma, são “guidelines” que te orientam num melhor uso da linguagem e suas funcionalidades, bem como podem ajudar em questões como arquitetura, ambiente ou processos de sua aplicação.

Para saber mais sobre PEPs, acesse a PEP 1 que é justamente um documento explicando o que são e o que fazem as Python Enhancement Proposals.

pep8

O pep8 é uma ferramenta simples (e muito eficaz) que analisa o seu código Python segundo as convenções de código descritas na PEP 8.

Vamos analisar o código do Django Brasil (você não sabia? O site é open source!), mais especificamente o arquivo models.py da app blog:

$ pep8 src/djangobrasil/apps/blog/models.py
 
src/djangobrasil/apps/blog/models.py:42:65: W291 trailing whitespace
src/djangobrasil/apps/blog/models.py:62:1: E302 expected 2 blank lines, found 1
src/djangobrasil/apps/blog/models.py:105:80: E501 line too long (89 characters)

Como podemos ver, a ferramenta nos mostra a linha e coluna onde o problema foi encontrado, apresentando uma breve descrição da incoerência que estamos cometendo em relação às recomendações da PEP 8.

Para obter uma resposta mais “verbose“, podemos passar alguns parâmetros para o pep8:

$ pep8 src/djangobrasil/apps/blog/models.py --show-source --show-pep8
 
(...)
src/djangobrasil/apps/blog/models.py:105:80: E501 line too long (89 characters)
  return '/weblog/%s/%s/' % (self.pub_date.strftime('%Y/%m/%d').lower(), self.slug)
                                                                               ^
  Limit all lines to a maximum of 79 characters.
 
  There are still many devices around that are limited to 80 character
  lines; plus, limiting windows to 80 characters makes it possible to have
  several windows side-by-side.  The default wrapping on such devices looks
  ugly.  Therefore, please limit all lines to a maximum of 79 characters.
  For flowing long blocks of text (docstrings or comments), limiting the
  length to 72 characters is recommended.

Viu só?! Dessa forma podemos aprender sobre a PEP 8 enquanto “ferimos” as convenções de código em nossos projetos

Para finalizar, podemos contar as ocorrências de problemas com a PEP 8 em determinada região do projeto:

$ pep8 src/djangobrasil/apps/blog/ --statistics -qq --filename=*.py
 
1       E225 missing whitespace around operator
7       E302 expected 2 blank lines, found 1
1       E303 too many blank lines (2)
11      E501 line too long (89 characters)
4       W291 trailing whitespace
2       W391 blank line at end of file

Nenhum problema muito grave de convenções de código na app blog do DjangoBrasil

Confira: pep8 – Python style guide checker.

Referências

• Python.org - Index of Python Enhancement Proposals (PEPs)
• Python.org - PEP 1: Purpose and Guidelines
• Python.org – PEP 8: Style Guide for Python Code
• Viva o Linux – PEP 8: Guia de estilo para código Python
• GitHub – pep8

Nos próximos posts, vamos dar uma pincelada no pylint, pyflakes e clone digger.

Fonte: Klaus Laube

Vamos lá “decorar” nossos métodos Python!

Decoradores? Really?

Eu não saberia explicar de uma forma melhor do que foi explicado pela Wikipedia, o que é o padrão decorator:

• Intenção: Acrescentar responsabilidades a um objeto dinamicamente. Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe;
• Motivação: Objeto usado possui as funcionalidades básicas, mas é necessário adicionar funcionalidades adicionais a ele que podem ocorrer antes ou depois da funcionalidade básica. Funcionalidades devem ser adicionadas em instancias individuais e não na classe;
• Consequências: Mais flexibilidade do que herança.

Encontramos na Wiki do Python uma explicação mais objetiva e esclarecedora:

Decorators alteram dinamicamente a funcionalidade de uma função, método ou classe, sem uso direto de subclasses ou alterando o código-fonte da função “decorada”.

O uso de decorators em Python

O Python começou a dar suporte a decorators a partir da versão 2.4.

Você terá a sua disposição alguns decoradores built-in e também poderá criar os seus próprios sem muito dificuldade. É possível identificar um decorator através do caractere @, por exemplo, a instrução abaixo declara o método say_hello da classe People como estático:

class People:
    @staticmethod
    def say_hello():
        print 'Hello!'

Vale notar que podemos reproduzir o comportamento acima sem utilizar a sintaxe especial de decorators (mas não deixamos de utilizar o conceito):

class People:
    def say_hello():
        print 'Hello!'
    say_hello = staticmethod(say_hello)

Quer conhecer mais sobre decorators em Python? Leia a PEP 318 – Decorators for functions and methods.

Um pouco de prática

Vamos por a mão na massa e criar o nosso próprio decorator:

# meu_decorator.py
 
def meu_decorador(alvo):
    def wrapper():
        print 'Chamando a funcao "%s"' % alvo.__name__
        return alvo()
 
    return wrapper
 
@meu_decorador
def meu_alvo():
    print 'Eu sou um alvo!'
 
meu_alvo()

Chamando o script acima, teremos o seguinte resultado:

$ python meu_decorator.py
 
Chamando a funcao "meu_alvo"
Eu sou um alvo!

Vou tentar seguir um fluxo que deixe claro o que o procedimento está realizando.

O comportamento da função meu_alvo é muito simples: imprimir “Eu sou um alvo!” na tela. Mas o @meu_decorador está lá para complicar a nossa vida

Com a chamada de @meu_decorador logo acima de meu_alvo, fica claro que na verdade estamos passando meu_alvo como um parâmetro (alvo) para o método meu_decorador, encontrado logo no início do arquivo. Note que o método retorna wrapper sem os parênteses no final (que caracterizam uma chamada de função), ele está retornando apenas a referência ao método wrapper, que será de fato “executado” externamente.

Dentro da função wrapper temos a impressão da string ‘Chamando a funcao “meu_alvo”‘ e a execução de meu_alvo. Isto deve-se ao fato de que alvo nada mais é que uma referência a função meu_alvo, que passamos como argumento para meu_decorador através do @meu_decorador logo acima da função meu_alvo, certo?

Então resumindo isso tudo, o resultado final é que meu_alvo() no final do arquivo na verdade é a execução da referência a wrapper, ou seja, é o mesmo que ler “wrapper()“. Ele fará o print e posteriormente retornará o resultado de meu_alvo, que nada mais é que a impressão de “Eu sou um alvo!”.

Bacana não? Aqui vai mais um para deixar as coisas um pouco mais claras… vamos simular o esquema de roteamento de uma framework Web:

rotas = []
 
def rota(endereco):
    def wrapper(fn):
        rotas.append((endereco, fn))
 
    return wrapper
 
@rota('/index/')
def home_view():
    return 'Pagina inicial'
 
@rota('/contato/')
def contato_view():
    return 'Pagina de contato'
 
print rotas[0][1]()  # Pagina inicial
print rotas[1][1]()  # Pagina de contato
print rotas          # [('/index/', < function home_view at 0xb736580c >),
                     #  ('/contato/', < function contato_view at 0xb7365b8c >)]

Referências

• Devlog – @decorators
• Five Minutes – A quick introduction to Python decorators
• Python.org – Design Patterns in Python
• Python.org – Python Decorators
• Siafoo – Python Decorators Don’t Have to be (that) Scary
• Wikipedia – Decorator

Até a próxima…

Fonte: Klaus Laube

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

Sabem aqueles conceitos, que a gente sempre utiliza e chega alguém com um nome “pomposo” para a parada (que você nunca ouviu falar)? Isso aconteceu comigo com closures.

What (the hell) are closures?

Entendi o conceito de closures enquanto estudava Ruby. Na verdade, fica a dica… se você quer aprender Orientação a Objetos, aprenda linguagens dinâmicas como Ruby, Python e até mesmo PHP. Depois parta para linguagens mais “hardcore” como Java e C++.

Vamos deixar a Wikipedia nos explicar o que é uma closure:

Uma closure ocorre normalmente quando uma função é declarada dentro do corpo de outra, e a função interior referencia variáveis locais da função exterior. Em tempo de execução, quando a função exterior é executada, então uma closure é formada, que consiste do código da função interior e referências para quaisquer variáveis no escopo da função exterior que a closure necessita.

Ok… sou a favor das pessoas que dizem que é difícil compreender alguns conceitos apenas por parágrafos formados por palavras bem escritas.  Vamos ao exemplo:

var digaSeuNome = function( nome ) {
    var msg = "Olá " + nome + ". Seja bem-vindo!";
    var exibeMensagem = function() {
        alert( msg );
    };
    exibeMensagem();
};
 
digaSeuNome("João");    // Olá João. Seja bem-vindo!

Temos uma função definida dentro de outra função. A função interna utiliza de parâmetros e variáveis da função externa…  basicamente, este é o conceito de closure.

Não achou muito útil? Dê uma olhada no exemplo abaixo:

var FabricaDeUsuarios = function( ) {
    var id = 0;
    var criaUsuario = function( nome ) {
        id++;
        return {
            id: id,
            nome: nome
        };
    };
 
    return criaUsuario;
};
 
var novoUsuario = FabricaDeUsuarios();
var joao = novoUsuario( "João" );
var jose = novoUsuario( "José" );
alert(joao.id);    // 1
alert(jose.id);    // 2

Utilizamos o conceito de closure no exemplo acima. Abusamos do contexto da linguagem, onde, mesmo que estejamos “chamando” a função fora do escopo de FabricaDeUsuarios, na verdade novoUsuario trata-se de uma referência a função criaUsuario. Logo, ainda estaremos utilizando os recursos do contexto de FabricaDeUsuarios.

Referências

• Javascript Closures – They’re not magic
• Morris Johns – Javascript Closures for Dummies
• Mozilla Developer Network – Closures
• Walter Cruz – Closures

E você… tem algum exemplo bacana sobre closures? Não deixe de comentar.

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

Embora a linguagem (em sua essência) seja Orientada a Objetos, temos que admitir que ela foge um pouco do convencional através do estilo de escrita prototype. Quero dizer que, é possível utilizarmos conceitos como encapsulamento, herança, atributos e métodos públicos e privados, etc. Mas de uma maneira um pouco diferente se comparada a linguagens como Python ou PHP.

Encapsular para conquistar!

A linguagem é composta por alguns objetos muito utilizados no cotidiano, como os objetos Array, Math e String. Estes (e outros objetos de core) são instâncias do objeto Object, que você pode representar através da seguinte expressão:

var meuObjeto = { };
typeof(meuObjeto); // object
typeof(Math);      // object

Você encontrará uma forma (muito bacana por sinal) de construir objetos através de expressões como essas:

var fooBar = {
    init: function() {
        console.log("Posso funcionar como um inicializador!");
    },
    _private: function(tipo) {
        console.log("Testando chamada " + tipo + ".");
    },
    eggs: function() {
        console.log("Eggs.");
        fooBar._private("interna");
    },
    spam: function(msg) {
        console.log("Spam: " + msg + ".");
    },
};
 
fooBar.init();                 // Posso funcionar como um inicializador!
fooBar.eggs();                 // Eggs. // Testando chamada interna
fooBar._private("externa");    // Testando chamada externa
fooBar.spam("Eggs and Spam");  // Spam: Eggs and Spam

Pode-se observar que é uma prática válida para organizar código através de namespaces.

Referência: Using Objects to organize your code

Função ou Classe?

Já utilizei algumas vezes o modelo acima… mas devo dizer que sou adepto a uma outra forma de construirmos classes em Javascript:

var Pessoa = function() {
    console.log("Pessoa instanciada!");
};
 
Pessoa();                      // Pessoa instanciada!
console.log(typeof(Pessoa));   // function
var pessoa1 = new Pessoa();    // Pessoa instanciada!
console.log(typeof(pessoa1));  // object

No exemplo acima, podemos reparar que seguindo o comportamento normal de uma função, não há surpresas na execução da expressão Pessoa. Porém, quando adicionamos o operador new na frente, o Javascript cria uma instância do tipo Pessoa. Basicamente é como se a expressão function fosse “multiuso”, sendo útil para definir funções e classes.

O mais legal disso é que, como você já deve ter reparado, com o uso do new ganhamos de graça um constructor (ou inicializador, como preferir) em nossa classe Pessoa.

Referência: Introduction to Object-Oriented Javascript

Métodos, propriedades e um pouco de confusão

Do constructor em diante, já me deparei com algumas vertentes de implementações do Javascript. Já encontrei algumas bem simples, outras um pouco mais complicadas… vou mostrar aqui a que eu acredito ser a mais usual. Não tenho propriedade para dizer se é o  modo certo ou mais elegante, apenas é o modo que incorpora características de OOP que melhor me atendeu:

var Linguagem = function(nome, versao) {
    this.nome = nome;
    this.versao = versao;
};

Acima temos a construção da classe Linguagem. Em seu constructor aproveitamos para setar alguns atributos, como nome e versao, que são passados imediatamente na hora de instanciá-la.

Para criar um método para esta classe, vamos recorrer ao prototype do Javascript:

Linguagem.prototype.descricaoCompleta = function() {
    return this.nome + " vr. " + this.versao;
};

Resumidamente, estamos adicionando um método de instância na estrutura da classe. Fazemos isso adicionando uma função ao prototype da classe. Dessa forma o método terá acesso as propriedades do objeto na hora que for instanciado.

Se tentarmos executar a expressão Linguagem.descricaoCompleta, iremos nos deparar com um erro de método inexistente. Mas, se instanciarmos a classe veremos que o método está acessível:

var python = new Linguagem("Python", "2.7");
console.log(python);                      // Linguagem
console.log(python.descricaoCompleta());  // Python vr.2.7

Acima utilizamos o conceito de métodos e atributos de instância. Através do modelo Object Literal podemos ter um comportamento parecido com o conceito de métodos de classe:

var Linguagem = function(nome, versao) {
    this.nome = nome;
    this.versao = versao;
    // Chamando um método que está fora do prototype da classe
    this.meuId = Linguagem.incId();
};
 
// Adicionando uma propriedade através de Object Literal
Linguagem.id = 0;
// Adicionando um método através de Object Literal
Linguagem.incId = function() {
    this.id++;
    return this.id;
}
 
var javascript = new Linguagem("Javascript", "1.5");
console.log(javascript);        // Linguagem
console.log(javascript.meuId);  // 1

Esta forma de criar classes e objetos em Javascript é executada com muito sucesso na biblioteca RGraph.

Referências: Javascript is Object Oriented Programming

Herdar é preciso

Para entender como criar heranças com o prototype do Javascript, vamos primeiramente criar um tipo chamado Framework:

var Framework = function(nomeFramework, nome, versao) {
    this.nome = nome;
    this.versao = versao;
    this.nomeFramework = nomeFramework;
};

No caso acima, iremos sobrescrever o comportamento do constructor da classe Linguagem.

E é aqui que a mágica acontece… instanciamos o tipo Linguagem no prototype da classe Framework. Isto fará com que o tipo Framework possua todas as propriedades de Linguagem. Depois corrigimos o constructor, apontando ele novamente para Framework:

// Cria herança com Linguagem
Framework.prototype = new Linguagem();
// Corrige o ponteiro do constructor para Framework (está apontando para Linguagem)
Framework.prototype.constructor = Framework;

Vamos adicionar um método exclusivo da classe Framework:

Framework.prototype.feitoEm = function() {
    return this.nomeFramework + " é feito em " + this.nome;
};

Instanciamos algumas vezes a classe Framework, e teremos o comportamento esperado de uma herança:

var django = new Framework("Django", "Python", "2.7");
console.log(django);                      // Framework
console.log(django.descricaoCompleta());  // Python vr.2.7
console.log(django.feitoEm());            // Django é feito em Python
 
var jquery = new Framework("jQuery", "Javascript", "1.5");
console.log(jquery);                      // Framework
console.log(jquery.descricaoCompleta());  // jQuery vr.1.5
console.log(jquery.feitoEm());            // jQuery é feito em Javascript

Existem algumas frameworks (como a Mootools) que facilitam a criação de classes e heranças em Javascript.

O exemplo completo está disponível para download em: http://github.com/kplaube/post-javascript-oop

Até a próxima…

Fonte: Blog Klaus Laube