Archive for September, 2007

Você automatiza seus testes de aceitação?

Wednesday, September 26th, 2007

O Danilo Sato escreveu um post muito bom sobre automatização de testes de aceitação:

“Muitas equipes XP não automatizam seus testes de aceitação. Essa é uma afirmação dura, porém muito comum de acontecer. A equipe abraça TDD e testes de unidade automatizados, porém quando chega a hora dos testes de aceitação, a coisa complica. Por que isso acontece? Como melhorar essa situação?”

Testes de aceitação são essenciais e automatizá-los é extremamente desejável!

Quem acompanha meu blog já deve ter percebido que teste de software é um assunto que me interessa bastante. Ultimamente tenho trabalhado muito focado na qualidade dos softwares que entregamos na minha equipe e por isso estou constantemente explorando novas maneiras de testar ou procurando melhorar as maneiras antigas.

Nos últimos sprints temos feito da seguinte forma: o desenvolvedor que trabalhar no desenvolvimento de uma história não pode fazer testes de aceitação da mesma. Desta forma cada um sempre testa o que o outro fez (estamos usando Selenium para este tipo de teste).

Ao fim do 4o. sprint temos uma suite de testes expressiva que cobre praticamente 100% do que foi desenvolvido. Realmente percebemos que aqueles bugs extremamente simples que normalmente são encontrados em QA ou mesmo em produção foram encontrados em tempo de desenvolvimento e corrigidos com rapidez.

Rodando automaticamente estes testes são uma ferramenta poderosíssima para ajudar a garantir a qualidade da aplicação.

Recomendo fortemente a leitura do post do Danilo!

Refatorando para Fluent Interface

Tuesday, September 25th, 2007

Ultimamente tenho passado boa parte do meu tempo trabalhando numa aplicação chamada WebMediaAPI. Trata-se de uma… ahm… API de uso interno que tem como objetivo padronizar, centralizar e facilitar o acesso à mídias e seu consumo em sites da Globo.com.

Por exemplo, quando o pessoal do G1 quiser colocar vídeos no seu site, ao invés de dar vários SELECTs em tabelas que eles não entendem e não conhecem, a idéia é que eles possam usar um JAR na aplicação deles que encapsula várias funcionalidades oferecidas pela nossa infraestrutura de WebMedia, simplificando o trabalho deles (pois não terão que descobrir como inventar a roda) e o nosso (centralizando e organizando o consumo de mídias na empresa).

No início do projeto um dos maiores desafios foi estabelecer como seria a fachada desta API. Nós tentamos alguns formatos e como precisávamos lançar logo a primeira versão acabamos optando por uma interface “tradicional” e simplificada. Para ter uma idéia melhor, veja o código para selecionar os últimos vídeos publicados do programa “Altas Horas”:

int quantidade = 5;
long programaId = 456;
Set midias = new HashSet();
 
WebMediaServices webMediaServices = WebMediaFactory.getServices();
List idsMidias = webMediaServices
	.getIdsUltimasMidiasPublicadasPorPrograma(quantidade, programaId);
 
for (Iterator iter = idsMidias.iterator(); iter.hasNext();) {
   Long midiaId = (Long) iter.next();
   Midia midia = webMediaServices.getMidia(midiaId.longValue());
   midias.add(midia);
}

Não é muito difícil entender o funcionamento deste código… Só que ele poderia ser muito melhor!

Esta interface pode até funcionar mas não é nem um pouco intuitiva. A classe WebMediaServices como pode-se imaginar ficou com dezenas de métodos e virou basicamente um grande saco de funcionalidades. Qualquer método simplesmente ficava nesta classe – o que não é nem um pouco elegante.

Depois de algum tempo tive a idéia de refatorar a API para uma Fluent Interface. A idéia é tentar fazer algo que se assemelha a uma DSL interna, que não é nada mais do que uma API com nomes interessantes. Ao invés de um saco de métodos a WebMediaAPI agora é acessada através de uma interface semânticamente organizada e seu design é pensado para ser legível e… fluente!

Veja como ficou o novo código para selecionar os últimos vídeos publicados do programa “Altas Horas” (exatamente a mesma coisa que o código anterior faz):

Long altasHoras = new Long(456);
Set videos = WebMediaAPI.videos().recentes().doPrograma(altasHoras);

Bem mais elegante!

O lado negativo é que quanto mais fácil a API torna-se para o cliente mais difícil torna-se sua implementação. Construir uma fluent interface muitas vezes me fez perder algumas horas pensando como certas coisas seriam feitas, mas eu gostei do resultado final e acho que para esse tipo de aplicação valeu a pena.

Para mostrar a diversidade e simplicidade da nova API, veja mais alguns exemplos (repare que eu não tenho que dizer nada sobre o que eles fazem para você entendê-los):

// exemplo 1
Set programas = WebMediaAPI.programas().comTitulo("Fantastico");
 
// exemplo 2
Long multishow = new Long(123);
Set videos = WebMediaAPI.videos().favoritos().doCanal(multishow);
 
// exemplo 3
Long destaquePrincipalGloboVideos = new Long(123);
Integer quantidadeMaxima = new Integer(10);
Set videos = WebMediaAPI.videos().relacionados().aoCanal()
	.doVideo(destaquePrincipalGloboVideos, quantidadeMaxima);

Ainda temos um longo caminho pela frente e muita coisa ainda será melhorada, mas já dá para perceber uma difirença significativa entre as duas versões.

Now, discover your strengths: StrengthsFinder 2.0

Saturday, September 22nd, 2007

Livro - StrengthsFinder 2.0Depois de ler no blog do Nick Carroll fiquei extremamente curioso para fazer o teste do StrengthsFinder. Ontem finalmente o meu livro chegou e como é bem curtinho já acabei com ele!

Resumindo, o StrengthsFinder é um teste que serve para te ajudar a descobrir quais são os seus melhores “talentos” naturais. Uma pesquisa feita pelo Gallup International Research & Education Centre mostra que as pessoas têm resultados muito melhores quando se focam em melhorar seus talentos naturais ao invés de tentarem melhorar as áreas que são mais fracas.

Segundo o autor Tom Rath, Capacidade = Talento x Esforço. Não importa o quanto você se esforçar, se você não se esforçar nas coisas certas nunca conseguirá ser excepcionalmente bom. Focando e desenvolvendo suas melhores qualidades você terá muito mais chances de crescer profissionalmente e como pessoa.

Os pesquisadores que desenvolveram o teste identificaram e catalogaram 36 qualidades básicas que as pessoas podem ter. O teste de 177 perguntas te mostra quais são suas 5 maiores qualidades/talentos e te dá um relatório personalizado das atitudes que você pode ter para estimular o desenvolvimento do seu talento. O resultado do meu teste foi o seguinte:

  • Futuristic: People who are especially talented in the Futuristic theme are inspired by the future and what could be. They inspire others with their visions of the future.
  • Achiever: People who are especially talented in the Achiever theme have a great deal of stamina and work hard. They take great satisfaction from being busy and productive.
  • Analytical: People who are especially talented in the Analytical theme search for reasons and causes. They have the ability to think about all the factors that might affect a situation.
  • Competition: People who are especially talented in the Competition theme measure their progress against the performance of others. They strive to win first place and revel in contests.
  • Responsibility: People who are especially talented in the Responsibility theme take psychological ownership of what they say they will do. They are committed to stable values such as honesty and loyalty.

Livrinho rápido, barato (US$ 10) e interessante. Vale a leitura :)

Em qual língua você programa?

Saturday, September 22nd, 2007

Muitas vezes fico em dúvida sobre qual língua usar nos meus sistemas. Sempre me sentí muito mais confortável programando em inglês do que em português mas nunca achei isso muito certo já que nossa língua nativa é o português. Já houveram casos de eu trabalhar com alguém que só sabia português e apesar de achar que nessa profissão quem não sabe inglês não vai à lugar nenhum não podia simplesmente inviabilizar o trabalho da equipe.

No último projeto que participei nossa equipe usou somente português. Algumas coisas boas aconteceram como o fato de termos incorporado a linguagem do negócio ao sistema. Isso é muito bom porque a grande maioria das entidades do sistema são coisas do mundo real e as discussões são sempre sobre coisas reais e não sobre metáforas (frequentemente mal feitas).

Porém também houveram pontos negativos. Por exemplo, uma determinada classe de serviços, que em inglês seria algo como MediaServices, teve que ser chamada de ServicosDeMidia. No fim das contas acabei optando por tirar a preposição (acho que o “de” é uma preposição, certo?) ficando somente ServicosMidias. Resolví retirá-la porque inúmeras classes ficaram com “De” no nome e ficou meio esquisito. O ruim é que não é exatamente assim que a gente fala naturalmente e fica um pouco estranho…

No fim das contas acho que o ideal é utilizar a língua do negócio, seja ela português ou inglês. Desta forma quando você for conversar com os clientes (product owners) você não terá o overhead de mapear todos os conceitos reais para a linguagem ou metáforas usadas no sistema. Com isso a conversa entre os clientes e os desenvolvedores fica muito mais produtiva já que todos estão falando sobre as mesmas coisas.

Coordenando o RioJUG

Thursday, September 20th, 2007

Desde o início da semana sou o mais novo coordenador do RioJUG! Recebí um convite dos coordenadores atuais para ajudar na coordenação deste grupo, que é um dos maiores do Brasil. Com mais de 1000 usuários, o RioJUG é o grupo oficial de usuários de Java do Rio de Janeiro.

Vou trabalhar para levar novidades para a comunidade e vou me obrigar a fazer mais apresentações nas reuniões mensais! Já tenho alguns temas interessantes na cabeça. Em novembro pretendo apresentar algumas coisas que vou ver na Qcon. Vamos ver se vai dar tempo, senão fica para janeiro.

Uma coisa que também sinto falta é dos eventos. Ultimamente não teve um evento sequer que prestasse aqui no Rio de Janeiro. Vamos ver se conseguimos ressucitar o Rio Java Summit e criar mais oportunidades para trocarmos experiências! Quem sabe também não está na hora de rolar um coding dojo no Rio, a exemplo do que já tem feito o pessoal de Floripa?

Dijkstra is Watching

Thursday, September 13th, 2007

Há duas semanas postei sobre a história de uma moça aqui do trabalho que acha que o Dijkstra é um jornalista só porque a foto dele está pregada na minha baia (veja a história completa).

Depois disso recebi uma meia dúzia de mensagens de pessoas interessadas em aderir ao “movimento” Dijkstra is Watching!

Dijkstra na minha baia

Eis a filosofia por trás disso tudo:

Este mesmo “pôster” está pregado em várias baias do pessoal da minha equipe de desenvolvimento porque Dijkstra era um cara extremamente intolerante com idiotices e colocá-lo “olhando” para os nossos monitores é um estímulo psicológico para que não cometamos nenhuma barbaridade enquanto estamos programando, sob pena de ridicularização e humilhação em praça pública.

Baixe o pôster (em PDF), imprima e coloque na sua baia também!

Créditos para o Phillip Calçado, designer do pôster e criador do clã.

Don’t hurt the web!

Friday, September 7th, 2007

Don’t hurt the web A coisa mais chata da mundo é quando você desenvolve um site e precisa fazer 258,4 gambiarras pra ele funcionar em todos os browsers.

Um exemplo clássico é o Internet Explorer, que não utiliza o XmlHttpRequest padrão. Se você for programar alguma coisa com AJAX perceberá que o XmlHttpRequest que funciona no IE é de um jeito e para quase todos os outros browsers é outro! Justamente por isso você acaba tendo que usar uma biblioteca como a prototype.js, que facilita uma implementação multibrowser.

Outro exemplo é quando você desenvolve um plugin OpenSearch (a caixinha de busca do browser). Se você precisar fazer qualquer coisa além do feijão com arroz terá problemas porque o Internet Explorer segue o padrão quase à risca enquanto o Firefox tem um monte de tags adicionais fora do padrão! Isso torna extremamente difícil fazer um plugin que funcione nos dois ao mesmo tempo.

Por isso o Mozilla Developer Center apoia a utilização de normas para desenvolvimento web:

Normas Web são cuidadosamente projetadas para entregar os maiores benefícios para o maior número de usuários da web enquanto assegurar a viabilidade a longo prazo de qualquer documento publicado na Web. Projetar e construir com estas normas simplifica e baixa o custo de produção, entregando sites que são acessíveis à mais pessoas e mais tipos de distribuições de navegadores. Sites desenvolvidos ao longo destas linhas continuarão a funcionar corretamente enquanto os navegadores de desktops tradicionais evoluem, e com novos dispositivos da Internet chegando ao mercado.

Promova o Mozilla Developer Center e a utilização de Normas Web, assim podemos fazer nosso trabalho mais rápido e de forma mais eficiente!

Web programável

Wednesday, September 5th, 2007

Uma das coisas mais legais que surgiu nesses últimos tempos foi a web programável (a.k.a. programmable web).

A web programável não é uma tecnologia mas sim um conceito. Tecnologicamente falando não há nenhuma novidade. Todas as tecnologias que fazem parte da web programável já estão aí há um tempão: JavaScript, XML, webservices, HTTP, RSS, Atom… O grande barato disso é a idéia, que consiste em os sites disponibilizarem além de suas tradicionais interfaces web HTML, uma interface que possibilite que programas utilizem os serviços que o site oferece.

Isso possibilita por exemplo que você coloque um mapa do Google Maps no seu site, que você tenha um site de comércio eletrônico inteiro usando a infraestrutura de pagamento e shopping cart do PayPal, que você faça um sistema de backup armazenando os seus arquivos no sistema de arquivos S3 do Amazon, que você codifique vídeos em vários formatos utilizando a HeyWatch API e por aí vai… O limite é a imaginação.

Vários grandes players do mercado já disponibilizam suas APIs públicas como o eBay, Google, Yahoo, Skype, PayPal, Amazon, além de muitos outros.

O site ProgrammableWeb é um lugar legal para acompanhar as últimas APIs lançadas por aí. Na última semana com a adição das novas APIs do Google eles anunciaram que já tem mais de 500 APIs catalogadas!

Para que você vai usar isso?

Tuesday, September 4th, 2007

Quando você se reune com seus usuários para definir um sistema é muito comum que alguém apareça com requisitos que não fazem o menor sentido e que não agregam o menor valor para o software.

Uma vez fazendo levantamento para o desenvolvimento de um sistema alguém me pediu para mostrar em algum lugar da tela a quantidade de pessoas logadas. Tá, eu confesso que era uma coisa relativamente simples de ser feita. O que acontece é que no meio de tantas coisas realmente importantes fazer aquilo me parecia completamente estúpido e inútil.

Então, tentando espremer o usuário, fiz aquela pergunta clássica: “e para que você vai usar isso?”. Normalmente o cara responde alguma coisa vazia como: “eu preciso saber quantas pessoas tem logadas no sistema para ver se tem um número bom de pessoas trabalhando”. E você fica sem saber o que responder e acaba aceitando.

Segundo Scott Bellware, uma forma eficiente de resolver este problema é perguntar para o usuário da forma correta. Ele escreveu um post no Code Better sobre como utilizar uma abordagem de behaviour-driven development para discutir funcionalidades de um sistema.

Neste caso, eu poderia ter perguntado para o usuário: “você poderia me descrever uma história com este requisito?”. Desta forma eu faria com que o usuário percebesse que nenhuma situação de uso real do sistema iria requerer que tal funcionalidade existisse. Na verdade este é o benefício principal de Behaviour-Driven Development. A idéia é que pensando na forma como o software irá se comportar você consegue perceber com mais clareza qual é o comportamento realmente necessário e não o que você imagina que seja necessário.

Desenvolver um sistema a partir de um comportamento necessário faz com que você desenvolva software que atende aos usuários. Já desenvolver um sistema a partir um dado que deverá ser apresentado pode fazer com que você desenvolva software inútil sem se preocupar ou entender o que realmente importa.

Parte da nossa missão trabalhando com desenvolvimento de software é guiar o usuário e fazê-lo entender o que ele realmente precisa, não o que ele acha que quer ou acha que precisa.