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

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

O Henrique Bastos divulgou na lista de discussão do Django a notícia que a Tiobe elegeu o Python como linguagem de 2010.

O Python agora ocupa a quinta colocação da tabela da Tiobe, atrás somente de Java, C, C++ e PHP.

O sucesso deve-se desde a rica documentação, até as excepcionais frameworks que tornam a linguagem uma das ferramentas modernas mais poderosas (e ágeis) para desenvolvimento de software.

Fonte: Klaus Laube

Compre este livro com 20% de desconto (código PTI20)!

Este livro é orientado ao iniciante em programação. Os conceitos básicos de programação, como expressões, variáveis, repetições, decisões, listas, funções e arquivos, são apresentados um a um com exemplos e exercícios. A obra visa explorar a programação de computadores como ferramenta do dia a dia. Ela pode ser lida durante um curso de introdução à programação de computadores e usada como guia de estudo para autodidatas. Para aproveitamento pleno do conteúdo, conhecimentos básicos de informática, como digitar textos, abrir e salvar arquivos, são suficientes. Todo software utilizado no livro pode ser baixado gratuitamente, sendo executado em Windows, Linux e Mac OS X.

Embora a linguagem Python (versão 3.x) seja muito poderosa e repleta de recursos modernos de programação, este livro não pretende ensinar a linguagem em si, mas ensinar a programar. Alguns recursos da linguagem não foram utilizados para privilegiar os exercícios de lógica de programação e oferecer uma preparação mais ampla ao leitor para outras linguagens. Essa escolha não impediu a apresentação de recursos poderosos da linguagem, embora o livro não seja fundamentalmente uma obra de referência.

Basta seguir o twitter @web2pybrasil e @treventos e tuitar a seguinte mensagem:

Quero ganhar uma vaga para o treinamento de Python e web2py - http://migre.me/16VWO @treventos @web2pybrasil

Importante: a URL http://migre.me/16VWO deve constar no tweet.

Data do sorteio: Quinta Feira : 26 de agosto

O sorteio será feito através da ferramenta: http://sorteie.me

O contato de aviso com o ganhador(a) será através de direct message. Assim, é importante que você seja um seguidor(a) da @web2pybrasil

O sortudo(a) ganhará:

• A inscrição para o evento
• Coffee Break (2)
• Certificado de Participação em papel especial
• Material Didático (apostila impressa, bloco de anotações e caneta)
• Oportunidade de conhecer profissionais do mercado com interesses similares ao seus, ou seja: ampliar sua rede de relacionamento.
• Pós-Evento: Download do material .pdf disponibilizado na apostila
• Oportunidade de dirimir dúvidas, pós evento, com o Especialista, via email, referente ao conteúdo apresentado.

Importante:

• O prêmio é intransferível
• É necessário que o contemplado seja seguidor do @web2pybrasil e @treventos no twitter
• A realização do treinamento está vinculada a um quórum mínimo de participantes, considerando que não haja este quórum, a pessoa que ganhar o sorteio será notificada sobre a nova data da realização da atividade com pelo menos 15 dias de antecedência para que possa se agendar.

Boa Sorte!