Viagens, opiniões e afins

Hoje o post é mais filosófico do que técnico. Quero mostrar para a seguinte mensagem: “Confie nos seus instintos.. eles podem te poupar um bom tempo”.

Estou trabalhando num projeto onde estou usando o Django/Python. Excelente produto. Isso mesmo produto. Acredito sinceramente que o Django é um excelente produto que a gente customiza para as nossa necessidades. Diferente dele, o Rails por exemplo é mais um conjunto de ferramentas que a gente usa para fazer nosso produto.

Bom dito isso, e voltando ao tema, estou fazendo um projeto com o Django. Não sou um profundo conhecedor dele. Estou bem longe disso, a cada dia que passa vejo que tem mais coisas. A quantidade de “moles” que e as dúvidas simples me provam isso.  Uma das coisas que acredita seja “killer” nele é o fato de dar um admin muito bom e relativamente simples de customizar. RELATIVAMENTE simples.

Em um post anterior mostrei, de forma bem superficial, como você pode alterar a forma que ele montar seus forms ou listagem. A princípio basta que sobrescreva seus templates padrão seguindo um padrão e tudo funcionará como mágica. Porém, se quiser customizar o fluxo dele… Ah ! aí começa toda a dificuldade.

O Django tem um fluxo bem definido para suas ações de CRUD e isso para muitos dos caso é o suficiente. Mas se tiver um bom designer em seu time e ele te peça algo relativamente simples: Quero que esse form abre dentro e um popin (lightbox) e que ao salvar atualize a listagem e caso tenha erro mostre erro e mensagem na cortina (alert), além disso eu quero poder abrir esse form em outra listagem e o comportamento será outro.  Ufa !!! Aí a brincadeira começa a ficar séria

Bom, não adianta temos recurso infinitos a nosso dispor se a gente não sabe usar.  Partindo desse pressuposto, pedi ajuda para meus amigos que são especialista no Django. E eles me disseram para insistir em usar o ModelAdmin do Django. Segui esse caminho, mesmo minha intuição dizendo para esquecer isso e fazer tudo do zero (usar uma view).

Foram 6 dias brigando com as coisa e no final não consegui avançar mais que alguns milimetros em direção a entrega. Resolvi confiar na minha opinião e fiz tudo com view. Foram 4 dias para fechar tudo. Ainda faltam alguns detalhes que fogem o escopo original.

Por isso, como disse, confie na sua intuição (entenda aqui na sua experiência, no seu “sentimento” em relação ao problema).  Sempre peça ajuda a alguém, pesquise… Não seja teimoso só por ser… Seja crítico e saiba escolher os seus caminhos.

A um bom tempo atrás (dezembro de 2009) escrevi um artigo sobre “decorators” em Python. O texto foi inspirado num post no blog do pessoal da Artima( mais precisamente do Bruce Eckel) que falava sobre o assunto.

De lá para cá, apareceram mais artigos e o uso de decorators ganhou bastante força em bibliotecas, frameworks, etc. Diante disso, e de diversos pedidos que recebo, resolvi re-visitar o assunto.

No wiki do Python, a definição de decorator, é de uma forma que temos para alterar um comportamento de um função ou métodos dentro de um código. Seria como se pudéssemos adicionar ou até alterar a lógica sem sermos muitos intrusivos.

Um bom exemplo seria o decorator classmethod. Veja abaixo:

Na classe acima, para usarmos o método “metodo1″, precisamos de uma instância de OlaMundo.

Para transformar o metodo1 ou escrever um metodo2 que pertença a classe e não a uma instância, você tem que fazer:

Já o decorator, como uma macro em C, tornar o código mais legível e faz essa “mágica” para a gente:

O que são os Decorators e como funciona:

Os decorators do Python são como macros ( já disse isso) que quanto o interpretador os encontra os substitui por um estrutura que foi definida. No caso do classmethod ele “substitui” pela a chamada original.

Claro que a definição acima é simplista, mas ajuda a entender.

Nos aprofundando mais, ele é semelhante ao with do Python. Ele é uma classe que no seu init recebe o objeto a qual foi associado e um método call (ele é um Callable). Esse método call é chamado e ai você pode fazer algo.

O código acima mostra bem (execute-o) como funciona um decorator. No meu caso, eu simplesmente coloquei um print. Mas no método eu posso abrir um conexão, colocar um log, medir tempo, colocar numa, fila, emitir um sinal, adicionar o método como callback numa evento, etc.

Para que servem e por que usar:

Decorators não trazem nenhum grande novidade a linguagem (está desde a versão 2.2 se não me engano), mas alteram e melhoram a sintaxe de nossos códigos facilitando a compreensão do que está acontecendo ali.

Referência.
[1] http://wiki.python.org/moin/PythonDecorators
[2] http://www.tocadoelfo.com.br/2009/10/python-decorators-uma-introducao.html
[3] http://devlog.waltercruz.com/python_decorators
[4] http://www.ibm.com/developerworks/linux/library/l-cpdecor/index.html
[5] http://wiki.python.org/moin/PythonDecoratorLibrary

A um certo tempo atrás trabalhava com Ruby, mais precisamente, desenvolvia utilizando o framework Rails. Dentro desse eco-sistema, existia uma “ferramenta” que sou apaixonado: Autotest (zentest).

Essa ferramenta fica monitorando seus arquivos ruby e caso faça qualquer alteração ele executa os testes (spec) do projeto. Isso é realmente uma “mão na roda” pois, para quem curte TDD, você fica o tempo todo monitorando as alterações no seu código e vai evoluindo bem.

Atualmente mudei de time e passei a trabalhar em projetos com django/python. Logo, comecei a procurar dentro desse novo ambiente, uma ferramenta similar que me permitisse fazer a mesma coisa. Vi que o pessoal do Dojo usa uma ferramente desenvolvido pelo Flávio Amieiro. O tempo foi passando e não encontrei nenhuma que me agradasse ao ponto do autotest (facilidade de uso e instalação).

Foi quando encontrei o Peon, desenvolvido pelo Bernardo Heynemann. O Peon é uma ferramenta que é fácil de instalar (pip install ou baixa e executa make install) e fácil de usar basta:

O comando acima é para quando alguém alterar algum arquivo .py no diretório tests ele irá executar o comando make test. Se você apenas chamar o peon, ele irá executar o nosetests para toda mudança em qualquer arquivo python do projeto.

Além disso, ele tem uma integração com a notificação do linux, permitindo em caso de falhar algum teste – por exemplo, ele te avisar. Entretanto, como eu uso o Mac OS, queria poder ter esse mesmos avisos com o Growl.

Pesquisando encontrei uma forma de fazer isso.

Existe uma biblioteca python (py-Growl) que faz essa integração ( semelhante ao pynotify da libnotify do linux). Abaixo um código mostrando como fazer. A explicação é bem simples:

Primeiro você cria um notifier, informando o nome da app (ela será usada para identificar quem está mandando algo para o Growl. Isso é importante), lista de tipos de mensagem que serão enviadas e um dicionário com ícones.

Depois você registra seu notifier e usa o método notify, passando o nome da app que você informou na criação do objeto, um título (um dos tipos que você informou) e a mensagem. E pronto!

Esse código já está no fork que eu fiz do Peon e vou fazer um pull request em breve. Fica a dica de usar o Peon e o Growl. Fica muito maneiro.

No artigo passado da série “Estudo compartilhados”, abordei mais a questão da Orientação a Objeto e como ainda não nos entendemos bem com ela.  No finalzinho do artigo, rapidamente, falei sobre os testes automatizados no famoso TDD.

TDD virou um buzzword. Traduzindo: Uma palavrinha da moda.  Hoje as empresa já colocam nos seus anuncios de vagas que o candidato que conhece TDD é um diferencial, outras até exigem. A questão é: Você sabe realmente o que é TDD?

TDD é a sigla em inglês para TEST DRIVEN DESIGN ou design dirigido por testes.

Mais uma vez para me ajudar com essa questão, pedi a ajuda para meu amigo Alexandre Martins, e ele me recomendou ( meio óbvio), o livro do Kent Beck , criador do TDD,  TEST-DRIVEN DEVELOPMENT . Além desse, Nunes também me recomendou alguns artigos e outros livros como o Growing Object-Oriented Software, Guide by Test, que mostram o caminho das pedras e como o teste pode ser o melhor amigo do desenvolvedor.

Numa conversa com outra pessoa, Rafael Martins (Cabra) da Globo.com,  concluímos que muita gente acaba por ter uma visão torta do que vem ser testar antes. Testar antes parte da premissa, na minha concepção, de que é preciso um problema para procurarmos a solução. Seria mais ou menos assim:  Você tem que comer quando sentir fome, pois do contrário, você está sendo guloso e indo além de suas capacidades.

Quando você cria os seus teste antes, baseado em suas necessidades, está de certa forma, criando um problema a ser resolvido. Se for disciplinado e apenas resolver aquele problema e repetir esse ciclo até que todos os requisitos sejam atendidos, a solução literalmente emerge. Isso mesmo: EMERGE.

Muitas das pessoas que me ouviram falar disso, respondem dizendo que é mentira ou exagero da minha parte que a solução EMERGE. Convido, os descrentes, a assistir e participar de uma sessão de dojo.

No livro Agile Software Development, também do UncleBob,  existe um capítulo em que ele descreve o desenvolvimento de um sistema para pontuação de boliche em que faz um par (pair programming) com outra pessoa e segue  conceitos como TDD e baby steps. É simplesmente revelador. Sei que exagerado mas é isso mesmo: REVELADOR ; pois ele simplesmente vai fazendo o sistema “sem pensar”. Dando pequenos passos, e sempre mantendo um dialogo e trocas constante com seu amigo, o design vai surgindo diante deles e se mostrando diferente do que se imaginava de inicio.

TDD evita desperdício

Um outro livro que recomendo muito é o Pragmatic Programmer. Nesse livro ele procura mostrar que o pragmatismo é uma boa filosofia para nós que fazemos software. Dentro disso, uma das coisas é a questão de evitar o desperdício.

Evitar desperdício é algo muito amplo e engloba diversas atitudes que devemos ter como: automatizar tarefas repetitivas,  tornar simples fazer o certo,  não fazer mais do que é preciso, etc.

Muitos se perguntam o que fazer para ser um programador ou ter um time altamente eficiente. Eu acredito que a solução vem de evitar desperdício e fazer o “justo necessário”. Isso também é conhecido como evitar o OverDesign. Sabe aquela aplicação simples para enviar arquivo para um servidor que o pessoal quer fazer com um monte de camada, abstrações, etc, justificando que isso facilitará uma possível modificação futura…Isso é um excelente exemplo de gasto desnecessário.

Quando fazemos TDD e nos disciplinamos a fazer o teste passar (isso mesmo) a gente fica focado; ao ficar focado evitamos desvios e perdas de tempos fazendo coisas para necessidades que não existem ainda.

ATENÇÃO: ISSO NÃO SIGNIFICA QUE VOCÊ DEVE FAZER ARQUITETURA PORCA. SEU CÓDIGO DEVE SER LIMPO.

Testar depois é apenas automatizar. TDD é mais uma ferramenta de design.

Até a próxima pessoal.