TDD x Filosofia

Numa dessas conversas casuais com minha namorada, que é formada em comunicação social, resolvi me atrever a explicar para ela o que é TDD.

Não foi necessário eu exercitar minha didática, pois assim que eu ia começar a explicar (ensaiando mentalmente algumas analogias), ela meio que definiu muito bem. Como assim ? Bom, em seu dia-dia ela é responsável pelo jornalzinho interno da empresa em que trabalha, no nosso bate bola ela me explicou suas técnicas de redação: Primeiro ela enumera os pontos que deseja alcançar (nossos testes) e depois desenvolve o texto em acordo com os pontos (código).

TDD não se resume simplesmente a fazer testes unitários de código, já vi algumas situações em que se desenvolvia o sistema e depois eram criados os testes unitários, não, isso não é TDD.

Desenvolver orientado a testes é uma filosofia de desenvolvimento, onde primeiro você define o que você quer e depois cria-se a inteligência para se alcançar o resultado.  (Lembra quando a professorinha dizia “e melhor entender do que decorar”, pois então antes de sair fazendo testes unitários em seu sistema procure entender a essência do que esta fazendo, e os reais porques disso tudo, e esse é meu interesse nesse post )

Vamos la, com essa abordagem, sua aplicação fica concisa, pragmática, orientada aos reais objetivos, sem devaneios ou loucuras ou códigos monstro que tentam se aproximar o máximo possivel de uma bala de prata, aqueles em que se fica horas e horas pensando: “… mas e se daqui algum tempo precisarmos de bla bla bla….” , se cria um mecanismo ultra complexo, onde o real objetivo da aplicação se perde, e fatalmente as exceções começam a mandar na inteligência da aplicação

Além de grande interesse por tecnologia, também sou um amante da filosofia, a base do conhecimento da civilização ocidental vem dos gregos, sim, o TDD também, a essência dessa técnica vem do Crivo de Erastótenes que foi um matemático grego que viveu em 285 a.c e criou tal algoritmo para o cálculo de números primos, e na sua técnica, antes de efetuar o cálculo ele definia o que se esperava.

Já que falei um pouquinho de filosofia, caso você esteja lendo esse post certamente você é um aficcionado por tecnologia, desenvolvimento e afins. Minha sugestão é: abra a sua mente, não leia apenas blogs técnicos, livros sobre linguagens de programação a,b ou c, leia também romances, sociologia, psicologia, biografias e quantas “ias” mais você puder. Como assim ? sim, isso vai fazer com que você exercite outras área do cérebro e certamente isso ajudará você a ser um ser humano melhor

playframework + spring

Como disse no post retrasado, estamos usando o playframework em nosso projeto atual. Relatei um pouco sobre a facilidade de uso, mas, como nem tudo são flores, tivemos um pequeno problema.

Precisamos fazer um mock de uma dependência externa para realizarmos os testes unitários adequadamente.

Para isso a solução que encontramos foi utilizar injeção de dependencias, dentre seus plugins, o playframework  possui o spring, que é um framework que tem como funcionalidade fundamental: a injeção de dependências. Até aí tudo bem, desenvolvemos nossos testes como manda o figurino, tudo saiu redondo, até que quando fizemos o deploy para o ambiente de desenvolvimento, as coisas não deram muito certo ;-(

Por alguma razão quando rodávamos os testes explodia no log o seguinte erro: Spring Context not started.  Mas que raios ? se em nosso ambiente local de funcionava (cowboy code total :” na minha maquina funciona !”  ). Vamos lá a diferença era: no ambiente local funcionava rodando no webserver que o playframework levantava, mas, no jbossweb ja era diferente. Estavamos chegando perto, até que com ajuda do commiter principal do projeto descobrimos que o comando “play war” (empacota a aplicação para que ela rode em um container, no nosso caso o jbossweb) nao estava copiando alguns arquivos de configuração para seus respectivos lugares, dentre eles o play.plugins que era o responsavel por apontar o uso do spring, bingo !

Prontamente eles corrigiram o bug, é por essas e outras que cada vez mais acredito na filosofia open source, que busca sempre a evolução a partir do conhecimento coletivo !

Testes unitários com google app engine

Há algum tempo atrás, comecei a fazer alguns testes usando o google appengine, coloquei uma aplicação simples em produção em pouco tempo, apesar de estranhar um pouco algumas coisas, gostei muito da praticidade e da ferramenta de administração que eles disponibilizam.  Mas… minha aplicação estava sem testes unitários. Confesso que fui um daqueles que dizia “se nao der tempo, vamos fazer sem testes mesmo”, mas o TDD é um caminho sem volta, conforme se vai praticando, surge um clarão e tudo começa a fazer sentido, o que senti mais dificuldade foi fazer os testes antes do código. Quanto a isso agradeço ao meu grande parceiro de código Emerson, que me catequisou no TDD.

Nesse final de semana voltei a trabalhar com o google app engine, só que agora em um outro projeto,  lendo os tutoriais do google appengine não tinha encontrado muitos exemplos de TDD, até que encontrei um framework esperto de testes unitarios GAEUnit http://code.google.com/p/gaeunit/

Ainda não fiz muita coisa mas em breve venho com mais impressões =)

playframework = pure fun

Eis que nosso time recebe mais uma nova missão:  disponibilizar uma aplicação para que nossos usuários se inscrevam para um processo de seleção de perfis. A primeira vista simples, não ? Mas o buraco é muiiito mais embaixo, pois o nosso querido formulário tem cerca de 70 campos, dentre eles alguns dissertativos, com validações diversificadas,  integração com outros sistemas como o de autenticação e o  de envio de vídeos, além de um fator crítico: precisamos de alta disponibilidade, e sim, essa aplicação será MUITO acessada.

Esse é o cenário, agora a solução. A última aplicação que desenvolvemos era orientada a serviços, onde tínhamos o front-end feito em Flash/ActionScript, e os nossos serviços em python, utilizando o framework django, e posso te dizer que foi bem divertido, principalmente porque aprendemos muito. Nunca tínhamos feito nada expressivo em python e tivemos um grande avanço e satisfação. Tendo isso, pensamos “vamos fazer em python” sim, foi bem divertido a linguagem e pragmática, o django e muiito bom Mas… devido aos servidores que serão utilizados e o prazo apertado, é mais viável desenvolvermos a aplicação em Java. 

Eis que surge o playframework, um full-stack framework com um propósito bem semelhante do django / rails, só que para java.

Ficamos muito impressionados, e bem felizes com a curva de aprendizado e velocidade de desenvolvimento, com configurações simples e, funcionalidades poderosas, nosso projeto está de vento em popa em apenas 3 dias de sprint. Usamos, spring, hibernate,junit, log4j, selenium e etc.. etc.. tudo isso sem configurações monstruosas,  enfim.. tudo isso de uma maneira bem ágil e sem reinventar nada !! e nos concentrarmos efetivamente no real propósito da aplicação !!! na lógica de negócio.

Em tempo de desenvolvimento ele levanta um webserver muito leve, nao há a necessidade de restarts na aplicação, e como disse com configurações extremamente simples

Vai lá e da uma olhada no play !!

sqlalchemy simplejson utf-8

Atualmente, em conjunto com o time do qual faço parte estou desenvolvendo um aplicativo orientado a serviços REST utilizando django + sqlalchemy + mysql.

Para poupar codigo, criamos um método que recebe um objeto ResultProxy do sqlalchemy e nos retorna um json, até aí tudo bem, deu tudo certo até que tivemos um dado com carater UTF-8, como batemos bastante a cabeça e encontrei muitas informaçoes “picadas” googleando, resolvi compartilhar a solução.

1 – O banco deve estar como utf-8

2 – a conexao com o sqlalchemy também:

engine = create_engine(‘mysql://root:@localhost/banco?charset=utf8&use_unicode=0′)

3 – O campo do modelo (no caso estou usando o sqlexpression do sqlalchemy) deve estar assim:

minha_tabela = Table(‘minha_tabela’, metadata,

Column(’sua_coluna’,Unicode),

)

4 – No nosso caso utilizamos o simplejson, que converte um tipo de dado dictionary para json

return HttpResponse(simplejson.dumps(dicionario,ensure_ascii=False), mimetype=’text’)

Tipagem de variavel

Hoje iniciamos uma discussao sobre os seguintes conceitos: tipagem estatica vs dinamica & tipagem fraca vs tipagem forte. Pois bem, depois de alguma pequena confusao de ideias e algumas googleadas chegamos a seguinte conclusao que resolvi postar aqui justamente por nao ter achado nada tao resumido sobre o assunto. Vamos la.

– Tipagem estatica

O tipo de dado da variavel deve ser declarado explicitamente, e esse tipo nao muda em tempo de execucao

Exemplos: Java, C, C++

public String teste = “alo”;

– Tipagem dinamica

A variavel recebe o tipo de dado dinamicamente, sem declaracao explicita.

Exemplos: Ruby,Perl,PHP

$teste = “alo”;

– Tipagem Forte

A linguagem tem um conjunto de tipos de dado bem definidos, e nao existem os famosos tipos coringa que podem ser de um tipo, ou de outro ao mesmo tempo e por ai vai. Um int E um int e ponto final, e para tudo existe um tipo bem definido !

exs: Java,Ruby,VB.NET,Python

– Tipagem Fraca

Conjunto de tipos de dado fraco, nao tao bem definidos um float recebe um int, e por ai vai…

exs: C, vb6,PHP

Resolvi postar pois isso as vezes esses conceitos geram uma confusao, e muitos se convencem que tipagem forte e tipagem dinamica sao a mesma coisa, e que linguagens de script necessariamente tem tipagem fraca.

Exs:

Ruby – Tipagem forte e dinamica

C – Tipagem fraca e estatica

vraptor + hibernate = )

Iniciei o desenvolvimento de uma ideia que ja tenho ha algum tempo, e agora resolvi botar em pratica. Estou reservando cerca de 3 horas do meu dia nesse projetinho que promete bombar (ou nao =)), enfim.. devaneios a parte…

De cara pensei, bom…. vou fazer em ruby on rails, mas….. como nunca tinha feito nada usando o hibernate, resolvi encarar o bicho. Apesar de eu ter apanhado um pouquinho, consegui botar tudo p funcionar gerando um carinha que gera a tabela, e outro que insere um registro no banco. Beleza ate ai tudo tranquilo.

Ao mesmo tempo pesquisei alguns frameworks MVC, struts2,spring….e …. decidi usar o vraptor,  para quem nao sabe e um framework brasileiro desenvolvido pelo pessoal da caelum.

No primeiro exemplo do tutorial me deparei com um exemplo onde o modelo fica separado da logica de negocio, em classes diferente, prematuramente isso me remeteu a um caso tipico de um objeto anemico… mas… depois de muito guj e google, cheguei a conclusao que aquele exemplo e meramente ilustrativo, e o framework procura ser o menos anemico possivel.

Bom, agora maos a obra ! vraptor + hibernate, sem modelo anemico !!

Desenvolvimento x otimismo

Uma pergunta que me intriga, porquê todo desenvolvedor é otimista na hora de estimar prazos ?

Por mais ágeis que os processos de desenvolvimento de software sejam, as vezes nos deparamos com aquela clássica pergunta: “Em quanto tempo você acha que faz isso ?” Antes que vocês pensem que eu esteja louco e continue teimando em desenvolver software a moda antiga ignorando o manifesto ágil

Digo que não, trabalho em um time multidisciplinar, utilizamos SCRUM, procuramos aplicar ao máximo as metodologias ágeis. Mas… por que raios teimamos em ser otimistas em nossas estimativas, coisas do tipo “isso eu faço em 15 min..” ok, ok… faria em 15 minutos em um cenário extremamente otimista, mas…. sabemos que as coisas não são assim e nosso colega Murphy sempre dá um sinal de vida

Justo nós que algoritmizamos ao máximo as coisas, as vezes deixamos de fazer um “TDD” em nossa estimativa, e os 15 minutos se tornam 8 horas… Mas continuo me perguntando, porque raios teimamos em continuar fazendo isso ?? Alguém ? alguém ??

Aguardo comentários !

Effective Java 2

Como muitos já sabem, o clássico Effective Java teve sua 2 edição publicada recentemente. Eu não li a primeira, mas ja tenho o PDF do livro e iniciei meus estudos. Para quem nunca ouviu falar, taí uma boa leitura, o livro fornece exemplos de boas e más práticas de programação orientada a objeto com Java, o autor ? Joshua Block, que atualmente trabalha no google, e participou do design e implementação de diversas features da plataforma Java, resumindo… o cara é ninja, e com certeza seus conselhos nos ajudarão… e muito !!

Programação em par

De todas as práticas do desenvolvimento ágil, creio que a programação em par seja uma das mais interessantes e coerentes.

Venho praticando bastante no projeto em que participo e posso afirmar que funciona muito bem. Quando se programa em dupla, a sensação de segurança é muito maior o que acaba estimulando a produtividade e criatividade no desenvolvimento.

Creio que toda metodologia deve ser adaptada as mais diversas situações.

Levando isso em conta não é legal sermos xiitas e usar programação em par 100% do tempo em 100% das situações, um dos casos clássicos onde o pair programming se adequa muito bem é o processo de debug, que as vezes (quase sempre) vira um multi programming

Encontrei um pdf bem interessante aqui.