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

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

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

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

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

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

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

Yes, I said Django 1.2 comes with built-in user “messages” framework. Great, isn’t it? Django really needed a built-in contrib app to solve this problem. This doesn’t mean, however, that Django-Flash will be discontinued or abandoned.

So, if you use Django-Flash in your projects, don’t worry! Nothing will change. Django-Flash is already compatible with Django 1.2, and we’ll keep improving Django-Flash for a number of reasons.

First of all, we care about the people who use our software. We won’t break your stuff if you decide to upgrade to a newer version of Django – or if you decide to keep using the previous version.

Also, freedom of choice is a good thing. You know, there’s not only one true way to solve every problem. People should be free to choose whatever tool they think is right in a given situation.

For example, based on my first impressions, there are a couple of things I didn’t like at all about the new user “messages” framework:

1. It’s verbose even for the simple cases
2. It ties messages to priority numbers, encouraging you to use it like a logging/debugging framework. I mean, a user “messages” framework is not a logging/debugging framework, right?

But that’s just my opinion. I guess this is what makes open source so great!

Os amantes de Python provavelmente irão notar que o site foi criado com Sphinx, uma ferramenta para documentação bastante popular no mundo Python.

Isso por si só é bastante interessante; Sphinx pode ser usado para documentar softwares escritos em diferentes linguagens de programação, não apenas em Python! Inclusive, nossa experiência usando esta ferramenta para documentar um projeto JavaScript foi excelente.

Claro que ainda existem melhorias a serem feitas, mas acho que estamos chegando lá. Quem sabe…

All Python lovers out there will probably notice that the website was created with Sphinx, a very popular documentation tool in the Python world.

This is very interesting by itself; Sphinx can be used to document softwares written in a wide range of programming languages, not just Python! In fact, our experience using it to document a JavaScript project couldn’t be better.

Of course there’s a lot of room for improvements, but we think we’re getting there. Hopefully.

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

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

Para apreciar é preciso antes viver sem

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

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

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

Primeira versão da suite de testes

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

(Muitas) Limitações

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

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

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

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

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

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

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

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

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

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

Se QUnit é assim tão ruim…

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

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

Mas nem tudo está perdido.

Viva melhor com JsHamcrest

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

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

Gostou?

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

O resultado:

Relatório com dados detalhados das asserções

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

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

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

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

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

O resultado:

Mensagem de erro amigável

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

Posso usar JsHamcrest com outro framework?

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

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

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

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

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

E aí, o que achou?

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

Banner do evento

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

Nos vemos lá!

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

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

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

Por que aprender uma linguagem funcional?

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

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

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

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

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

Escolhendo a linguagem

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

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

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

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

Praticar é essencial

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

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

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

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

E vocês, o que recomendam?

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

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

Referências

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

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

Errata

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

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

Página 21

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

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

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

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

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

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

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

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

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

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

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

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

Página 39

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

Página 92

Trecho:

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

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

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

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

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

Francamente, eu achava que não iria dar certo, talvez por culpa de uma screencast horrível que eu acabara de ver, não sei. Mas o fato é que, contrariando minhas expectativas, o Django vem se mostrando uma ferramenta muito interessante. Se você ainda não conhece, veja você mesmo o que Django (e Python, claro!) podem fazer por você.

Mas voltando ao assunto, a primeira vez que precisei usar algo que o Django não oferecia por padrão foi quando tentei utilizar um recurso muito querido  pelo pessoal do Rails: as mensagens flash.¹ Por esse motivo, eu comecei um projeto open source chamado django-flash, cujo objetivo é (pasmem!) levar as mensagens flash do Rails ao Django.

O projeto vem sido desenvolvido no meu tempo livre e hoje chega à versão 1.4.1, oferecendo todos os recursos então presentes no seu irmão mais velho. Acredito que o projeto chegou num grau interessante de maturidade: API estável, documentação abundante, código extremamente bem comentado e apoiado por testes (unitários e de integração).

Portanto, se você precisa de algo semelhante às mensagens flash do Rails em seu projeto Django, não deixe de conferir o site do projeto. Conto com a ajuda de vocês para tornar este projeto cada vez melhor!

Um bom fim de semana a todos!