“Philosophy is questions that may never be answered. Religion is answers that may never be questioned.”

(“Filosofia são questões que podem nunca ser respondidas. Religião são respostas que nunca podem ser questionadas.”)

Quando li essa frase imediatamente lembrei do que acontece no dia-a-dia do nosso mercado; do ambiente de trabalho a conferências e listas de discussão. Sem querer entrar em detalhes profundos ou em opiniões/flames sobre assuntos não-técnicos, vejo que existem dois tipos de programadores: os Religiosos e os Filósofos.

A palavra “religião” vem do latim “religio”, que significa “prestar culto a uma divindade”. Os programadores Religiosos fazem exatamente isso: aproveitam todas as oportunidades que podem para louvarem a sua linguagem ou framework favoritos. Os Religiosos dificilmente aceitam “religiões” diferentes da sua e os mais extremistas acreditam que a sua linguagem ou framework resolve todos os problemas do universo e são a chave da salvação da humanidade. Eles aceitam tudo cegamente e nunca reconhecem ou questionam os defeitos desses projetos que apoiam (e em alguns casos mais extremos até transformam esses problemas em “features”). Quando aparece um problema pela frente não precisa nem pensar: ele usará a sua ferramenta favorita para resolvê-lo, não importa o que seja (um padrão também conhecido como “One Ring to rule them all”).

“Filosofia” vem do grego “philos” (que ama) + “sophia” (sabedoria), ou seja, “que ama a sabedoria”. Filosofia é a investigação crítica e racional de questões, ou seja, um programador Filósofo não está procurando defender uma linguagem ou framework mas sim em investigar várias delas, analisar como elas funcionam e refletir sobre como elas podem ajudá-lo a resolver problemas. Os Filósofos são curiosos; eles sempre querem compreender e questionar o funcionamento e utilidade das ferramentas que usam. Quando precisam resolver um problema eles analisam de forma racional todas as opções que conhecem e se nenhuma delas for boa o suficiente eles pesquisam e procuram uma opção mais eficiente.

Um programador precisa resolver problemas complexos com qualidade e precisa ser cada vez mais produtivo/veloz para atingir um objetivo (desenvolver um produto, terminar um projeto da sua empresa e por ai vai). A melhor ferramenta não é a sua preferida ou aquela que você escolheu para seguir e amar, e sim aquela que te faz ser mais rápido, mais produtivo, com mais qualidade e que te dá mais conforto para trabalhar. A melhor ferramenta é a que melhor atende os requisitos da sua profissão e do seu projeto, não o seu ego (ou sua religião).

Seja menos “religioso” e mais “filósofo”! Com a mente aberta e sem encarar ferramentas como “a verdade definitiva” (ou descartando-as sem ao menos testar e conhecer como funcionam) você terá muito mais chances de ser bem-sucedido.

Colaborar com outros projetos é bem fácil no Github, basta fazer um fork do projeto que eu pretendo colaborar, fazer minhas modificações e depois um “pull request” para o dono do projeto avaliar e integrar (ou não) o meu código ao dele. Antes do Github não funcionava muito diferente disso mas o que ele fez de bom foi facilitar esse fluxo e criar uma rede social bem interessante em torno desse mundo.

Isso é bem diferente de como as empresas normalmente funcionam. No caso da Globo.com, por exemplo, todos os repositórios sempre estiveram amontoados nos servidores CVS e Subversion e consequentemente “escondidos” (pouco visíveis) de possíveis colaboradores. Alguns até tinham permissão de commit restrita para um pequeno grupo e o processo de colaboração era ainda mais difícil. Não dá nem para abrir um branch seu, você tem que fazer as modificações localmente e mandar um patch por e-mail, e o merge geralmente não é muito fácil de fazer quando você tem um grande fluxos de merge para lá e para cá. Imagina então quando você trabalha na versão “v1″ do código e enquanto você produz a “v2″ um outro desenvolvedor pede merge antes de você? Era preciso esperar o merge terminar para dar checkout da versão nova e ficar mais uma vez fazendo o inferno do merge.

No início desse ano resolvemos experimentar usar o Gitorious, que é uma ferramenta similar ao Github porém Open Source e que você pode instalar num servidor da sua empresa. Isso tinha 2 objetivos: (1) criar uma cultura de “enterprise” Open Source e (2) facilitar a colaboração em projetos em que vários times trabalham e commitam ao mesmo tempo.

No início foi um inferno e houve uma rejeição muito grande de muita gente. O modelo de trabalho com o Git é bem diferente do que com CVS e Subversion. Você tem branches (e clones – que é um conceito um pouco diferente) que podem ser locais ou remotos, commits locais que não vão direto para o servidor e pulls/pushes. As pessoas tendem a fazer relações do tipo “o push é o que manda as coisas para o servidor, então ele equivale ao commit”. Mas então o que é o commit do Git? Enfim, não dá pra trabalhar pensando assim, é preciso dar um reset e entender a arquitetura desses sistemas de controle de versão distribuídos para entender que faz sentido sim ter um commit e só depois do push que o código está no repositório (no remoto, porque no local já estava).

Também foi difícil aprender a trabalhar com merges. No modelo antigo você evita fazer merges o máximo possível porque o trabalho para fazer isso é enorme. Geralmente você só faz quando acabou de fazer tudo para ter trabalho uma vez só. Ainda bem que existem ferramentas para ajudar (como as ferramentas das próprias IDEs) senão seria complicado. Se você trabalha da mesma forma com o Git geralmente vai se dar mal, porque não existem (não existiam mas estão começando a melhorar) as mesmas ferramentas de merge visual do CVS ou Subversion, e era um parto para fazer a coisa toda funcionar após fazer um merge de uma semana de fork. Com o Git funciona ao contrário: como o merge é automático (na maioria dos casos ele consegue se virar) então a estratégia é fazer merge toda hora, várias vezes por dia, o máximo que der.

Depois de alguns meses de “fricção” hoje já dá para ver um monte de frutos começando a aparecer. Por exemplo, no último sprint do meu time nós precisavamos usar um cliente Python para acessar a engine de busca da Globo.com. Como esse cliente era novo tinha uma série de problemas pequenos que precisavam ser resolvidos, mas o time que é responsável pelo projeto estava com vários compromissos e demoraria 2 semanas para trabalhar nisso. Então o Bernardo e o Andrews decidiram fazer um clone no Gitorious para contribuir com o projeto do time de busca, e eles não só resolveram os problemas como devolveram o código refatorado e com a cobertura de testes bem melhor. O outro time rapidamente integrou o novo código ao projeto e gostou tanto do trabalho deles que eles viraram commiters e agora podem fazer as modificações que forem necessárias em colaboração com o time de busca. Exatamente como funciona no mundo Open Source.

Além desse exemplo, no projeto que estou trabalhando (que é um framework para sites de publicação de conteúdo) temos vários times trabalhando no mesmo código ao mesmo tempo. Nesse momento tem cerca de 10 clones do projeto no nosso Gitorious e talvez cerca de 10 times trabalhando usando o mesmo código para fazer seus “add-ons”. O Git facilita o trabalho dos times para atualizarem constantemente sua base de código com o que entra de novo no branch master do mainline (o repositório principal do projeto) e o Gitorious torna isso tudo mais visível para todos.

Enfim, as vantages que nós passamos a ter com o Git e Gitorious são várias:

• Todo mundo pode ver facilmente os projetos que existem e quando novos projetos são criados;
• Todo mundo pode ver o que todo mundo está fazendo e em que estão trabalhando;
• Todo mundo pode facilmente criar e gerenciar seus projetos (sem precisar do Sys Admin);
• É bem facil de navegar nos projetos, ver e pegar código dos outros;
• Todo mundo pode criar seus clones de repositórios para trabalhar em cima do seu código e do código dos outros;
• Todo mundo pode colaborar de volta sem precisar de um processo complicado para isso;
• É mais fácil de fazer merges constantes e gerenciar múltiplas colaboracoes simultâneas;
• Fora as outras features interessantes que o Git tem e os sistemas de SCM antigos não como o stash, clones, merge automático e por aí vai.

Só para dizer um ponto negativo, a documentação de usuários do Git não é das melhores (mas tem melhorado bastante) e alguns comandos não são tão intuitivos (como deletar um branch remoto), mas nada que você não descubra e que não se acostume com o tempo.

Aconselho fortemente a todo mundo que puder que faça isso. Instale o Gitorious e fomente a colaboração entre os desenvolvedores da sua empresa! Se você estiver com muita grana também pode dar uma olhada no Github Firewall Install, que deve ser bem legal mas também é bem caro.

Apresentada por Richard P. Gabriel e Guy L. Steele, a palestra 50 in 50 fala de 50 tópicos sobre linguagens de programação e 50 anos de história de computação em 50 minutos. Tem pérolas musicais como a sensacional “Eternal Flame” (também conhecida como “God had a deadline, so he wrote it all in Lisp”), representações teatrais de um programa escrito usando Shakespeare Programming Language e muito mais! É imperdível!

Para ver com qualidade melhor, acesse o video no Blip.tv da JAOO.

Uncle Bob Martin na RailsConf 2009 from Fabio Akita on Vimeo.

Conversando com o Peleteiro esses dias ele me deu uma idéia interessante. Ia ser o máximo se houvesse um post automático no meu Twitter toda vez que eu ganhasse um achievement no Xbox! Os achievements são como se fossem medalhas: na medida que você vai jogando os jogos e passando de fase ou conquistando coisas, você vai ganhando mais pontos e mais medalhas. Resumindo, é totalmente inútil mas bem legal.

Como nos últimos tempos andei fazendo uma porção de robôs de Twitter para fazer uma porção de coisas, na mesma hora pensei em fazer mais um deles, que ficaria dando requests na API do Xbox Live até que aparecesse um novo achievement e então ele faria o post.

Na mesma hora me bateu a mesma sensação de ineficiência que tive quando fiz os outros robôs. Pra fazer essas coisas eu tenho que ficar fazendo polling no serviço de “n” em “n” minutos para saber das atualizações… Apesar de ser eficiente nao é lá muito eficaz.

Vou fazer uma brincadeira para mostrar o tamanho do problema. Somando só os robôs que fiz para a Globo.com, eu faço diariamente cerca de 72.000 requests para o Twitter (cerca de 25 robôs x 2 requests por minuto x 60 minutos x 24 horas). Ok, nem todo mundo faz robôs de Twitter, eu sei, mas vamos supor que uma pessoa em cada 100.000 faz robôs que nem eu. Isso significaria que só eu e mais uma pessoa fazemos isso no Brasil inteiro (o que não deve ser verdade, mas vamos continuar assim fazendo a conta por baixo). Então considerando que a população mundial é de quase 7 bilhões de pessoas, temos cerca de 70.000 pessoas fazendo o mesmo em todo o mundo. Sendo assim, pela minha conta de padaria o Twitter recebe algo em torno de 5,04 bilhões de requisições por dia, 210 milhões de requisições por hora, quase 60.000 requisições por segundo (só de robôs)!!!

Ok, o número deve ser bem diferente disso. O fato é que com certeza é muito alto.

Eu faço polling no Twitter para buscar por usuários que falaram uma determinada palavra (usando o RSS da busca do Twitter) e então adicioná-los. Funciona assim: quando uma pessoa escreve alguma coisa que eu estou procurando, eu adiciono ela como amigo(a). Apesar dessa quantidade imensa de buscas e requests, um robô adiciona apenas na faixa de 25 usuários por dia. Se houvesse alguma forma de saber que algum usuário escreveu alguma palavra que eu busco, nesse meu cenário só seria necessário fazer algo em torno de 625 requests por dia (menos de 1% da quantidade que eu faço).

O que eu estou propondo aqui não é nada novo. Além dos mecanismos tradicionais de polling (fazer “pull” de arquivos de tempos em tempos), estes tipos de serviços deveriam disponibilizar um mecanismo para o servidor avisar o cliente que alguma informação que ele deseja está disponível (”push”).

Depois da apresentação “Beyond REST? Building data services with XMPP” que rolou na OSCON 2008, o XMPP entrou na moda como uma possível solução para esse problema. Nessa arquitetura, os clientes se “inscrevem” em um serviço de mensagens instantâneas e mantém uma conexão aberta com o servidor para que, quando determinada informação estiver disponível, ela seja enviada ao cliente ao invés dele ter que ficar fazendo “polling”. Isso reduz consideravelmente a carga de requests recebida pela aplicação, mas é mais difícil de escalar para uma quantidade muito grande de usuários.

Uma solução que surgiu na nossa conversa foi um “pingback ao contrário”. Seria algo como o webhook do Github. Quando o usuário fizer um GET em um recurso, ele poderia mandar um header com uma URL, e quando houvesse alguma atualização do recurso o servidor poderia fazer um GET para esta URL com o objetivo de informar ao cliente que há informações novas disponíveis. Essa solução escala mais do que a primeira, mas tem um lado negativo: não funciona se o cliente não tiver um IP real disponível. No meu caso, por exemplo, que tenho robôs rodando no meu desktop da Globo.com (que não tem IP real), não seria possível usar esse tipo de serviço.

Também dá pra fazer algumas soluções mais criativas usando coisas que a princípio parecem esquisitas mas podem fazer sentido. Por exemplo, um servidor de e-mail como o Postfix poderia fazer esse trabalho com o pé nas costas. Quando o cliente acessasse um recurso, ele poderia informar em um header um e-mail para ser notificado quando houvesse atualização. É uma solução bem fácil de escalar e de fácil implementação – tanto pelo lado do cliente quanto do servidor – apesar de não ser muito comum.

Pelo que eu andei lendo o pessoal do Twitter já pensou nesse problema e para resolvê-lo criaram o Firehose, que é uma solução baseada em XMPP. Como eu falei, o problema não termina por aí – eles terão vários problemas novos para escalar XMPP para uma grande quantidade de usuários.

Enfim, esse problema é bem interessante… Na próxima oportunidade que tiver vou tentar fazer uma prova de conceito de todas essas opções para ver no que dá.

E para aqueles que ainda não entenderam, talvez fique um pouco mais claro agora: escalabilidade é muito mais uma questão de arquitetura de software e infra-estrutura do que de linguagens e frameworks.

Mas ainda ficou a pergunta que não quer calar: Java é ruim mesmo? A resposta, como sempre, é que depende do caso…

Em um projeto de desenvolvimento de software, mesmo antes de começar o desenvolvimento você já tem algumas restrições para escolher tecnologias. A finalidade do software por si só pode já restrigir muito a tecnologia que terá que ser usada.

Por exemplo, se você estiver fazendo um website, provavelmente você não escapará de fazer uma interface em HTML, Flash ou qualquer outra coisa específica para desenvolver uma camada de apresentação web. Provavelmente você não vai querer usar Assembly para fazer a parte server-side, já que não seria muito produtivo (apesar de não ser impossível). Eventualmente esse site pode ser um portal como a Globo.com que têm milhões de acessos por dia e você terá que escolher uma plataforma/linguagem/arquitetura que priorizem performance e favoreçam escalabilidade. Ou então pode ser um site com pouquíssimos acessos e você nem precisará se preocupar com isso…

Ou então você pode precisar fazer um pequeno script para fazer backup automatizado de um banco de dados MySQL. Seria totalmente incoerente usar Delphi, Fortran ou Piet. Provavelmente você vai querer usar algo como Shell script e resolver o problema em meia dúzia de linhas. Alguns bancos como o SQL Server têm mecanismos de agendamento de backup automático que são super fáceis de configurar e usar, portanto nesse caso usar Shell script seria trabalho desnecessário.

Meu ponto aqui é que não dá para dizer que Java (ou qualquer outra coisa) é ruim por sí só. Java pode ser ruim ou bom dentro de um contexto. Por exemplo, em 2005 eu trabalhei num projeto de Call Center à distância via Internet onde precisei desenvolver um softphone e a melhor opção foi usar Java Applets. Além de existirem bibliotecas Java para trabalhar com IAX (que é um protocolo como o SIP, só que proprietário do Asterisk), o usuário não precisava instalar nenhum programa para falar com o Call Center, bastava acessar o site. Eu odeio Applets com todas as minhas forças, mas foi ótimo para esse projeto (eu diria até que foi relativamente fácil). Seria correto então dizer que Ruby on Rails é ruim só porque seria impossível de fazer esse projeto com tanta facilidade? É óbvio que não!!!

Jamais existirá uma única linguagem ou plataforma para resolver todos os problemas. O desenvolvedor de software precisa conhecer vários tipos de ferramenta e saber escolher a melhor delas para resolver cada problema. Que fique claro que eu não sou defensor de Java, Ruby ou de qualquer outra coisa. O caso é que é incoerente dizer que X ou Y é bom ou ruim por sí só; é preciso analisar as opções dentro de um contexto.

Quando eu estava lendo o livro, um trecho de um capítulo que fala sobre os princípios de design acendeu uma lâmpada na minha cabeça e me fez atentar para uma coisa que acontece diariamente no desenvolvimento de software:

“Design can make things easier for the viewer or the user. Design is not decoration. If anything, design is more about subtraction than addition. Visually, we do not want to include too much, nor do we want to exclude too much. Generally, people err on the side of including too much visual information, which often results in clutter and confusion.“

É verdade. Existe uma tendência grande das pessoas acharem que mais funcionalidades e complexidade é sempre melhor. As pessoas pensam exatamente como descreve o livro Getting Real da 37 Signals:

“Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.“

Transportando para o mundo do desenvolvimento de software, eu vejo que muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar, adoram usar EJBs em qualquer coisa, adoram inventar seus frameworks malucos… Enfim, adoram fazer tudo que é complexo e trabalhoso. Assim como no design, entulhar o código com essas coisas só fazem ele ficar muito mais difícil de ser mantido e entendido!

Talvez um dos motivos disso acontecer seja que nem sempre o desenvolvedor tem senso de urgência e visão do negócio. Nem sempre ele entende que não dá para perder 3 dias fazendo um menu JavaScript que abre e fecha, ou passar 80% do tempo tentando encaixar design patterns no código, ou criar uma arquitetura com 36 camadas para diminuir o acoplamento. Essas coisas podem ser extremamente prejudiciais para o projeto, porque o cliente está esperando triplicar o faturamento e o número de visitantes do seu site e essas coisas não vão ajudar em absolutamente nada. A oportunidade de usar design patterns, criar camadas no software ou qualquer outra coisa surgirá naturalmente no decorrer do projeto. Se isso não acontecer, então simplesmente não os use.

Uma dica para descobrir se você ou alguém está fazendo uma coisa útil ou não é tentar responder a seguinte pergunta: “Qual problema será resolvido com isso?”. Ultimamente tenho feito essa pergunta para todo mundo e percebí que muito mais da metade das coisas não são justificáveis. É incrível como as pessoas criam coisas sem nenhum motivo, que só deixam o software mais complexo sem necessidade, tanto internamente (código) quanto externamente (interface).

Por isso eu gosto e recomendo trabalhar sempre com uma das regras básicas do XP. Independente de usar XP ou não, a simplicidade é uma ótima regra:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.”

Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:

Desenvolvimento de software não tem absolutamente nada a ver com construção!

No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt fazem uma analogia muito mais apropriada: fazer software não é como constriur prédios mas sim como jardinagem. É muito mais “orgânico” do que “concreto”. Inicialmente você planeja muitas coisas para o seu jardim de acordo com as condições atuais de terra, clima, etc. Você precisa plantar as sementes, regar todo dia e cuidar para que as pragas não acabem com tudo. Você pode com o passar do tempo mover suas plantas de lugar para tirar vantagem de fatores como exposição ao sol, sombra ou até mesmo para fazer a rotatividade da terra. Você poda suas plantas constantemente e move alguns tipos de flores de um lugar para o outro para que o jardim fique melhor esteticamente. Se alguma planta cresce demais, pode ser que o espaço que você planejou para ela tenha ficado pequeno, e então é necessário movê-la de lugar. Enfim, não é uma coisa que você planeja, mas sim uma coisa que você tem uma idéia inicial e trabalha ao longo do tempo para fazer o melhor possível dentro daquela idéia.

Assim como o jardim, se o software não receber todos os cuidados necessários ele apodrece. Quando um software apodrece, é impossível implementar qualquer funcionalidade num tempo aceitável, é impossível colocar em produção sem que alguém tenha que ficar de babá, enfim, tudo passa a ser imprevisível. Nos piores casos passa a ser até impossível “tocar” no software, e esses monstros viram aqueles softwares que “se o servidor desligar ele não liga nunca mais”. E o pior é que isso acontece toda hora. Quantas vezes você já não pegou um projeto tão ruim, mas tão ruim que seria mais fácil fazer do zero do que consertá-lo? Isso é um sinal claro de software podre.

Para evitar que isso aconteça, o que se deve fazer é reavaliar a situação do software a cada história/funcionalidade implementada. Um bom desenvolvedor sempre avaliará se não é hora de mover algumas coisas de lugar, generalizar algumas funcionalidades, reescrever algumas porções de código e etc. – assim como faria um bom jardineiro. Isso deveria ser uma lei, não uma opção.

Os times ágeis trabalham com um conceito que é a “definição de pronto” (DOD – definition of done). A definição de pronto diz quando é que uma funcionalidade pode ser considerada pronta ou finalizada. Na minha opinião, para se considerar uma funcionalidade “pronta” é necessário no mínimo:

• Desenvolver a funcionalidade
• Testar unitariamente (melhor ainda se for fazendo TDD)
• Testar a integração com outros componentes (quando for o caso)
• Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado
• Testar segundo os critérios de aceitação estabelecidos pelo cliente
• Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código
• Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema
• Atualizar a documentação (quando necessário)

Pode parecer um exagero ou muito trabalho, mas não é. A questão é que você não pode deixar para fazer nenhum desses itens depois de 2 meses de desenvolvimento, você precisa fazer isso desde o primeiro dia! Quando você deixa para depois, você acaba acumulando o famoso débito técnico, e depois poderá ter que pagá-lo com juros, que poderão ser muito altos. O melhor é fazer aos poucos, a cada passo dado, porque desta forma o trabalho sempre será muito menor e não irá onerar o projeto. Mais uma vez fazendo analogias, é como câncer: você pode se previnir e tentar evitar que ele aconteça, ou você pode esperar ficar doente para depois ter que fazer uma arriscada cirurgia invasiva (e mesmo assim pode não dar certo, e aí perde-se o paciente).

Como o Paulo Silveira comentou no GUJ, Knuth tem algumas opiniões controversas e polêmicas sobre testes unitários, eXtreme Programming, Open Source e programação concorrente. O Phillip Calçado também comentou o assunto, referindo-se a opinião do Keith Braithwaite, que tem ótimos pontos.

Sobre testes unitários em particular, Knuth fala o seguinte:

[...] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

Basicamente ele parece não acreditar em testes unitários.

O problema é que hoje em dia, além da complexidade da programação em sí, é necessário lidar com a complexidade do domínio do software, com o fato de que as empresas devem responder rapidamente às mudanças (e o software deve acompanhar), o fato de que não existem “desenvolvedores solo” mas sim equipes de desenvolvimento e por aí vai. Por isso é essencial que os softwares sejam bem testados e que esses testes sejam executados constantemente para garantir o bom funcionamento do sistema ao longo dos incrementos que serão feitos durante seu ciclo de vida. Mesmo com todas essas precauções, como bem disse o Phillip, se nos dias de hoje alguém ou alguma empresa pagasse $2.56 por cada bug encontrado nos seus programas (como faz o Knuth), provavelmente já estaria falida. Já imaginou então se não houvessem os testes como que seria?

Convenhamos, o caso do Knuth é um caso a parte. Ele está na ativa desde os anos 60 quando nossos pais ainda eram adolescentes, e possivelmente por isso tem práticas e opiniões que não necessariamente se aplicam às situações de hoje. É claro que ele merece todo o respeito por tudo que ele fez e faz pela computação, mas não acho que a opinião dele sobre práticas ágeis em especial possa ser levada em consideração ao pé da letra. E o que mais me preocupa nisso tudo é que, por ele ser um ícone da computação, as pessoas tomem tudo que ele falou como verdade absoluta e comecem a achar que testes unitários não servem para nada, quando na verdade eles são essenciais para qualquer programador profissional!

Para mim, os programadores que não testam poderiam ser chamados de Programadores de Schrödinger.

Falo isso por causa da teoria do Gato de Shrödinger. Resumindo a história, o físico Erwin Schrödinger uma vez sugeriu que se puséssemos um gato numa caixa fechada, onde a vida do gato dependesse do estado de uma partícula sub-atômica, haveria uma superposição de estados que faria com que, do ponto de vista da mecânica quântica, o gato estivesse vivo e morto ao mesmo tempo até que a caixa fosse aberta. Seria impossível determinar o seu estado até abrir a caixa! Na minha imaginação eu fico pensando no momento que a caixa é aberta e aparece um gato vivo (ou morto) o que aconteceu com o outro gato… Provavelmente ele está em algum outro universo paralelo onde todas as coisas são ao contrário (e as pessoas acham guarda-chuvas ao invés de perdê-los). Enfim, não se sabe de forma alguma o que pode acontecer.

Finalizando toda essa viagem, os Programadores de Schrödinger simplesmente não sabem o que vai acontecer quando o seu sistema entrar em produção. Pode ser que nenhum bug apareça e que eles fiquem ricos e comprem milhares de jatos particulares. Ou não.

Na dúvida, eu escrevo testes.

Fala GC!

Cara, o que voce faria se entrasse em um projeto para implementar umas melhorias, mas esse projeto não tivesse nenhum tipo de teste, o código não fosse testável e você soubesse que daqui a 3 meses ia sair do projeto? Você perderia tempo fazendo refactoring, implementando testes, configurando CruiseControl e tal, ou ia simplesmente ligar o foda-se???

Isso acontece pelo menos 32409 vezes todos os dias em algum lugar do planeta.

Os desenvolvedores acostumados a programar com testes têm uma dificuldade enorme de trabalhar em aplicações que não tem testes. A primeira coisa que os desenvolvedores mais experientes fazem quando pegam uma aplicação nova é olhar a base de testes. Por alí já é possível descobrir uma série de comportamentos e detalhes da implementação do sistema, bem como as intenções de quem o programou. Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

<história>
Uma vez eu trabalhava numa empresa e meu chefe me pediu para fazer um protótipo de um sistema que integrava um website com um PABX para fazer determinadas tarefas. Como era um protótipo e eu só tinha duas semanas, eu fiz ZERO testes (e a aplicação funcionava por milagre divino). Só que para o meu azar, esse protótipo era para fazer uma demonstração para um cliente, que adorou a idéia e comprou na mesma hora! Como meu chefe achava que já estava parcialmente pronto e funcionando, meu prazo para terminar era de mais quatro semanas. Duas semanas depois eu estava desesperado por não conseguir avançar na aplicação e não conseguir fazer o negócio funcionar. Aconteciam bugs estranhos, daqueles que te fazem pensar que você está na profissão errada. Todos os dias eu me arrependia profundamente de ter deixado os testes para trás. Meu chefe ficou desesperado e colocou mais um desenvolvedor para me ajudar. No primeiro dia ele me perguntou: “GC, onde estão os testes para eu dar uma olhada?”. Er.. bom… não tinham testes… E eu fiquei totalmente desmoralizado, fui humilhado, massacrado e apanhei quase até a morte.
</história>

Hoje em dia não abro mão dos testes. Se você entregar uma aplicação que não funciona, a culpa é sua! Então, faça tudo que é possível para garantir que tudo esteja funcionando.

Finalmente, respondendo o e-mail do meu amigo acima (que não posso dizer o nome porque não tenho permissão), eis algumas dicas para você não ficar em maus lençóis:

Dica número 1: faça sempre o melhor que puder! Mesmo que você ache que vai ficar 2 semanas ou 3 meses em um projeto, seu gerente pode mudar de idéia e você pode acabar ficando bem mais tempo do que isso. Então, tire essa idéia da cabeça já e comece a se preocupar com os testes. E mesmo que você com certeza absoluta só fique 3 meses, como que você vai sair de cabeça erguida e com a certeza de que o que você fez está funcionando se você não tem os testes para comprovar?

Dica número 2: conserte as janelas quebradas. Se alguém chega na sua casa e metade das janelas estão quebradas, então não tem muito problema se quebrar mais uma. Porém, se todas as janelas estiverem impecáveis, quebrar uma janela é péssimo! Siga este mesmo princípio para o seu código, não tenha janelas quebradas. Se você tiver 90% de cobertura de testes, todos eles forem impecáveis e nenhum falhar no CruiseControl, o próximo desenvolvedor que chegar se sentirá na obrigação de manter tudo funcionando da mesma forma, porque esta é a cultura do projeto. Já se todos os testes estiverem quebrados ou não houverem testes, não faz a menor diferença.

Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido, além de que não vai conseguir implementar as features. Neste caso, minha estratégia seria refatorar o código na medida que precisasse implementar as features. Faria o ciclo normal de TDD: implementaria os testes fazendo refactor na implementação para torná-la testável, implementaria a feature, garantiria seu funcionamento e depois um novo refactor para deixar tudo bonito.

Dica número 4: get them Test Infected! Faça um workshop com os outros desenvolvedores do time e mostre para eles a importância de escrever testes. Ensine-os a usar o CruiseControl, JUnit, JMock, injeção de dependência e tudo mais que for necessário para que os testes aconteçam. Mesmo que você “perca” dois ou três dias de trabalho, com certeza ganhará muito mais desse dia em diante.

<piada>
Dica número 5: só por via das dúvidas, para ajudar nos momentos de fraqueza, coloque alguém para te vigiar em tempo integral. O “Dijkstra is watching” é ótimo para isso, tenha ele sempre por perto.
</piada>

Fiquei então com a idéia de criar uma demonstração de uso de Fluent Interfaces na cabeça, mas eu queria usar um domínio fácil para que as pessoas pudessem entender melhor. A WebMediaAPI pode ser até legal, mas o fato é que ninguém conhece o modelo de mídias da Globo.com e fica difícil de explicar ou discutir o que está sendo feito.

Há duas semanas, conversando com o Evandro sobre uma apresentação que faremos mês que vem no evento de tecnologia da Globo.com, ele deu uma idéia super simples e bem legal. Todas as pessoas já trabalharam com e-mail, seja enviando mensagens para outras pessoas ou então escrevendo código para enviar e-mails em diversas linguagens. Esse é um domínio extramanete fácil para todo mundo, e também, é pequeno o suficiente para ser implementado rapidamente em um dia.

Então, nasceu a Fluent Mail API. A Fluent Mail API é uma API simples que utiliza a JavaMail API da Sun para enviar e-mails. Meu objetivo não é criar mais uma ferramenta para envio de e-mails, é apenas demonstrar o uso de Fluent Interfaces como wrapper de um framework maior, simplificando seu uso. A idéia é fazer com que enviar um e-mail seja tão fácil quanto isso:

new EmailMessage()
    .from("demo@guilhermechapiewski.com")
    .to("destination@address.com")
    .withSubject("Fluent Mail API")
    .withBody("Demo message")
    .send();

Você pode ver os códigos-fonte e uma descrição mais detalhada no site do “projeto”. Se alguém quiser discutir, opinar, tirar dúvidas ou qualquer outra coisa, é só comentar.

Desenvolvido em 6 meses como um “pet project” (projeto pessoal) usando 20% do tempo de 3 engenheiros, o Hibernate Shards foi lançado internamente no Google em dezembro de 2006 e depois doado para a JBoss em maio de 2007.

“Shard” é um termo que o pessoal do Google usa para falar de divisão/particionamento. O Hibernate Shards é um framework de persistência baseado no Hibernate, usado para dividir os dados entre vários bancos de dados diferentes, criando um particionamento horizontal das informações.

Resumidamente, o particionamento horizontal é usado quando você têm aplicações com bancos de dados monstruosamente grandes e você precisa distribuí-los em vários bancos de dados. Então, você tem várias instâncias de banco de dados diferentes, todas com o mesmo schema, e com os dados divididos entre elas. Quem gerencia onde está cada banco de dados e em qual “shard” (partição/bucket/o que você quiser) estão os dados é o Hibernate Shards, de forma transparente para a aplicação. O Shards pode usar qualquer banco de dados suportado pelo Hibernate (ele tira vantagem dos dialects).

Os criadores do projeto queriam que fosse fácil e natural para os usuários de Hibernate usá-lo, por isso ele usa vários conceitos familiares como, por exemplo, a ShardedSessionFactory, que implementa a interface SessionFactory. Eles tem uma ShardedSession, e por aí vai.

Apesar do Shards ser totalmente compatível com Hibernate do ponto de vista da aplicação (porque usa as mesmas interfaces), ele não suporta JPA, a implementação de Query ainda não funciona 100% e vários outros probleminhas e “gaps” em relação ao Hibernate…

Confesso que fiquei um pouco decepcionado, porque pelo que eu tinha conversado com o pessoal por aí, parecia que ele seria uma forma de ter um schema distribuído em vários bancos de dados diferentes, e isso ia resolver um problema gigante que tenho. Mas descobrí que isso que eu preciso é particionamento vertical. Perguntei para o Max se daria para fazer alguma adaptação e ele falou que até seria possível escrever um ShardStrategy que quebrasse um galho, mas eu teria muitos problemas maiores pra resolver.

Ao menos serviu para conhecer esses conceitos de banco de dados, que de certa forma eu conhecia mas não da maneira formal.

É óbvio que o criador dele só poderia falar que ele é ótimo, então a opinião dele é suspeita. Mas o fato é que na Globo.com temos usado JBoss Web em várias aplicações e de fato ele é muito bom. Ele realmente aguenta o tranco de milhares de acessos e definitivamente é muito mais estável que o Tomcat, e muito mais leve que o JBoss. IMHO, ele é o mais completo da atualidade e é a minha primeira escolha para os tipos de projetos que tenho trabalhado (web applications que não usam EJBs, JMS e as parafernalhas mais complexas do Java EE).

As principais vantagens do JBoss Web sobre o Tomcat são:

• Ótimo para conteúdo estático. Como ele usa a mesma engine do Apache, benchmarks mostram que ele consegue praticamente os mesmos resultados de performance.
• Melhor integração com o sistema operacional, usando JBoss Native.
• Networking é melhor devido a extensões na JRE.
• Usa features modernas de sistema operacional para zero-copy.
• Melhor solução de clustering.
• Usa menos CPU e memória.
• Tem uma implementação de mod_rewrite em Java.

O objetivo do JBoss Web não é substituir o Apache, nem o Tomcat, nem o JBoss. Se você tiver aplicações tradicionais onde um Apache é suficiente (conteúdo estático + PHP, por exemplo), use-o. Se você for usar JSP/Servlets para um site pequeno-médio, talvez a melhor opção seja mesmo o Tomcat. Se você precisar processar EJBs, certamente vai precisar de um full JEE application server. Além disso, o JBoss Web não têm a variedade de módulos que o Apache tem, e também não tem um foco grande em segurança. Mesmo assim, é mais uma excelente carta na manga.

Como esse é um assunto que muita gente não conhece, vou colar aqui a definição da wikipedia sobre virtualização:

“[Virtualization is] a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources. This includes making a single physical resource (such as a server, an operating system, an application, or storage device) appear to function as multiple logical resources; or it can include making multiple physical resources (such as storage devices or servers) appear as a single logical resource.”

Agora, falando em português curto e grosso e transportando para o nosso contexto (aplicações web): virtualização seria basicamente fazer com que as aplicações que rodam em clusters de várias máquinas passem a rodar em clusters de menos máquinas, onde em cada uma delas teria várias instâncias de sistemas operacionais. Ou seja, rodar vários sistemas operacionais em uma mesma máquina em paralelo. Com isso você mantêm o número de instâncias da aplicação, porém usando menos máquinas. Para isso pode-se usar VMWare ou Xen, por exemplo.

Muitas empresas hoje gastam milhões de dólares com hardware, como uma solução de contorno para software de qualidade ruim. E quando se gasta milhões comprando, naturalmente se gasta vários outros milhões mantendo essa infraestrutura, e não dá para crescer. Muitas vezes o hardware é super-dimensionado, e fica “90% idle” na maior parte do tempo.

As aplicações cliente-servidor de antigamente muitas vezes precisavam apenas de 1 servidor de banco de dados para funcionar (só para centralizar os dados, na verdade). Nos dias de hoje, com N-camadas e arquiteturas baseadas em SOA, as aplicações podem ser resultado da composição de dezenas de serviços, e cada um desses serviços pode estar instalado em dezenas de máquinas. Resumindo: hoje em dia temos aplicações que rodam em centenas, talvez milhares de máquinas.

E onde que a virtualização se encaixa nisso tudo? Vamos lá, vamos imaginar um cenário. Imagine uma aplicação que roda em um cluster de 20 máquinas, e que nos horários de pico a utilização de CPU chega a no máximo 5% ou 10%. Ou seja, você tem 90% de máquina sobrando o tempo inteiro! Com virtualização, uma estratégia poderia ser fazer com que esse mesmo cluster funcionasse em 5 máquinas, e cada máquina teria 4 instâncias de sistema operacional. Ou seja, cada sistema operacional ficaria com 25% da máquina original, que como vimos, é mais do que o dobro e o suficiente para ela funcionar. Resumindo: mesmo resultado e 1/4 dos recursos necessários.

Temos várias vantagens com essa abordagem:

• Corte de custos.
• Maior aproveitamento dos recursos existentes.
• Liberação de recursos para outras aplicações que podem estar precisando mais.
• Melhorar os planos de recuperação de desastre e backup, mantendo instâncias de aplicação prontas para funcionar em qualquer lugar.
• Maior maleabilidade de recursos: se houver um pico em uma ou outra aplicação, os recursos podem ser gerenciados (até via script) para atender a demanda momentânea.
• Redução do espaço físico necessário para os datacenters, bem como redução de consumo de energia e redução de custos para resfriamento.
• Etc.

Sou apenas um curioso e não um especialista nesse assunto, mas com certeza essa é uma área que vai crescer muito nos próximos anos.

No nosso laboratório na Globo.com, já fazemos experiências com virtualização há algum tempo e temos inclusive deploys virtualizados de algumas aplicações para teste. Agora precisamos colocar para funcionar!

Essa apresentação teve muito a ver com o artigo que ele publicou no InfoQ sobre como portar aplicações HTML tradicionais para Flex, escrito em conjunto com Shashank Tiwari (mais detalhes no blog do James).

No início ele mostrou um demo sensacional de uma aplicação de seguros que eles migraram de “web 1.0″ para Flex. Realmente o poder das interfaces ricas é impressionante. Outro demo interessante foi do eBay Desktop, que tem uma boa combinação de HTML e Flash (usando o Adobe AIR), resultando em uma interface muito bonita e funcional.

Ultimamente na Globo.com temos trabalhado muito com Flash, por causa do player do Globo Vídeos. Antes disso eu nunca tinha trabalhado com Flash e talvez por isso nunca tenha tido a oportunidade de sentir tão de perto seu potencial. Flash/Flex/AS3/AIR/etc abrem um novo mundo de possibilidades, dando o poder de criar interfaces com usabilidade e interatividade excelentes, e ainda com um forte apelo visual.

Ele apresentou o conceito de “SOARIA” (aliás, quando ele falou isso eu comecei a rir sozinho, parecia que ele estava falando “sorria”). O que ele chama de SOARIA significa SOA + RIA, ou seja, aplicações ricas (RIA) que interagem com o back-end através de serviços (SOA). IMHO, acho essa abordagem muito legal, porque evita aquela dependência cíclica que sempre acaba se formando entre o Flash e a aplicação.

No final, vimos um benchmark interessante, comparando vários modelos de carregamento de dados em aplicações RIA usando Flex, Laszlo e Javascript/Ajax, integradas com serviços SOAP, pure-XML, HTML e JSON. O benchmark analisa como cada um desses modelos impacta em performance, consumo de banda e consumo de memória na máquina cliente. Fiquei surpreso com os resultados… Por exemplo, a aplicação mostra que o Dojo tem uma performance surpreendentemente ruim quando comparado a aplicações Flex, que têm uma performance normalmente superior a todas as outras (atenção, se você for rodar os testes não se esqueça de desabilitar o Firebug antes!).

A Adobe realmente acertou com o Action Script 3, Flex, AIR e todos esses novos produtos que têm sido lançados. Tenho que tirar o chapéu.