codificando.com

O Rails Summit terminou. Foi um evento bem legal, com ótimas palestras e a galera de sempre, que já conhecemos.

Vou fazer um resumo das palestras que assisti.

Chad Fowler – http://chadfowler.com

A palestra do Chad foi como sempre focada em carrreia. Ele advertiu os desenvolvedores que produzem porcaria todo dia sem peso algum na consciência. Ele pensa (e eu também) que nós não devemos investir tempo desnvolvendo coisas que já sabemos que são porcaria. E isso não é pessimismo, simplesmente é não perder tempo.

Chad falou também sobre os FUDs que sempre usam contra Ruby/Rails. Isso não foi nenhuma novidade mas ele abordou de forma bem divertida e valeu muto a pena.

Uma das partes mais legais foi a estatística mostrando que Ruby só faz parte de 6% da requisição do usuário. Na verdade não só ruby, mas outra tecnologia também. Isso bom para refletirmos sobre as discussões sobre performance e escalabilidade das aplicações web.

Gregg Pollack – http://envlabs.com

O foco da palestra do gregg foi sobre como atacar alguns pontos para o otimizar sua aplicação Rails. Dentre as formas, ele apresentou algumas gems/plugins que ajudam a identificar alguns pontos para melhoria de performance em uma aplicação. Vou destacar algumas:

• Bullet – Ajuda a identificar queries com alguns problemas. Ex: N + 1
• Rails Indexes – Identifica colunas onde deveriam ter índices. Se baseia nas buscas do sistema.
• Scrooge – Faz com que o ActiveRecord passe a buscar somente os campos que estão sendo usados, ao invés de buscar todos os campos. Ex: em um find(:all), após a primeira execução, o scrooge identifica quais campos foram usados e ná próxima vez modifica a query para não buscar os campos desnecessários.
• Rack Bug – É uma Monitor para aplicações Rack. Fornece basicamente todas as informações. Sessões, CPU, Memória, etc. Bem útil
• oink – Mostra detalhes dos requests de cada controller. Ex: consumo de memória.
• Cloud Crowd – Servidor para rodar tarefas em background. Feito em sinatra.

Ilya Grigorik – http://www.igvita.com/about/

Ilya falou sobre integração/comunicação de aplicações baseadas em web, utilizando-se de tecnologias como XMPP, AMQP, Webhooks, PubsubHubbub. Foi bem interessante, pois a maioria do auditório conhecia pouco sobre o assunto.

Fabio Akita – http://akitaonrails.com

A palestra do akita foi sobre agile. Ele falou bastante sobre a teoria do caos, sistemas complexos e a evolução das coisas. No fim, o recado maior foi alertar que agile não é o último estágio no desenvolvimento de software, deixando claro que temos (e vamos) que evoluir ainda mais.

Glenn Vanderburg – http://blog.thinkrelevance.com

Palestra sobre o framework Tarantula, que tem por objetivo fazer testes de ataques XSS, SQL Injection, entre outros. Achei bem interessante, pois é possível automatizar esse passo, que geralmente fazemos manualmente. Glenn inclusive sugeriu que faça parte do build antes de lançar um release.

Fabio Kung – http://fabiokung.com/

Fabio fez uma ótima palestra sobre DSLs (Domain Specific Languages) internas usando Ruby. Ao invés de apresentar exemplos simples ele apresentou um exemplo real de uma necessidade de uma aplicação que trata de instâncias de máquinas na cloud da Locaweb.

Carlos Vilella http://lixo.org

Carlos fez uma palestra bem curta, falando sobre o uso de Ruby na Thoughtworks. Falou sobre os poucos projetos que falharam e deixou o restante do tempo para perguntas.

Tapajós – http://tapajos.me/

A palestra do Tapajós foi sobre bancos de dados não relacionais. Focado bastante em CouchDB e Rails, ele explorou algumas features chaves na utilização dessa abordagem de banco de dados, também fazendo uma curta palestra e deixando boa parte do tempo para perguntas.

Bruno Miranda – Rails não escala

Eu gostei muto da palestra do Bruno, apesar de achar que o que ele falou é básico para qualquer Arquiteto de Software experiente.  Bruno falou bastante sobre filas, sharding, Cache, Proxy reverso, otimização de queries e sobre rodar processos em background. Acho que a palestra dele foi válida pois qualquer um hoje em dia que aprende tecnologias como Rails sai fazendo aplicações sem um conhecimento mínimo de arquitetura de software. Quando as coisas não dão certo culpam a tecnologia, gerando FUDs.

Vinicius Teles (http://improveit.com.br/) – Empreendorismo

A palestra do Vinícius foi ótima para quem pretende desenvolver um produto e/ou abrir seu próprio negócio. Ele abordou pontos como Fluxo de Caixa, oportunidades vastas que existem no Brasil e o impacto de pequenas decisões certas ou erradas que tomamos na nossa vida profissional.

Obie Fernandes – http://obiefernandez.com/

A palestra do Obie encerrou o evento em grande estilo, falando sobre talento, esforço e reforçando bem o que eu disse há um tempo atrás nesse blog. Não adianta você saber um monte de coisas se não souber bem, se não tiver experiência com isso, treino, treino e mais treino. Você só ganha nível com tempo e treino, isso é fato.

Pra finalizar, gostaria de parabenizar ao Fabio Akita e a Locaweb pelo excelente evento mais uma vez.

E ano que vem tem mais.

Dias 13 e 14 de outubro estarei presente no Rails Summit 2009. Acontecerá em São Paulo com a organização do Fabio Akita da Locaweb.

No ano passado pude estar presente e realmente foi um evento excelente e de muito alto nível. Fiquei super satisfeito e esse ano acredito que será melhor ainda. Participaram diversos palestrantes internacionais e os nossos colegas palestrantes nacionais também mandaram muito bem.

E você, está esperando o que para se inscrever?

http://www.railssummit.com.br/

No mês passado, resolvi aplicar BDD em um projeto Java que estava desenvolvendo. Atualmente, existem ferramentas em outras linguagens que podem ser usadas para esse fim. Por uma série de razões, resolvi usar o JBehave para resolver o meu problema nesse projeto em específico (lembre-se, não existe bala de prata). Acontece que o JBehave é todo em Inglês e não dá suporte a i18n.

Quando comecei a usa-lo no meu projeto, logo percebi que usar em inglês não seria legal, pois o projeto só fazia sentido no Brasil e portanto o interessante era escrever os cenários em português. A partir desse momento, comecei a escrever algumas classes pra fornecer esse suporte. Felizmente, as classes Scenario e Steps permitem fácil extensão para resolver esse problema. Após as modificações necessárias, o arquivo de cenário passou a se chamar nome.cenario e o texto no arquivo ficou da seguinte forma:

Cenário: Nome em português do Brasil

Dado que eu quero rodar o Jbehave em português do Brasil
Quando eu usar o meu idioma
Então tudo deve funcionar perfeitamente

Feito isso, achei legal disponibilizar uma biblioteca para que outros desenvolvedores que precisem usar o JBehave no nosso idioma possam faze-lo de forma trivial. Nesse momento nasceu o projeto jbehave-br, extraido desse projeto e disponibilizado no GitHub aqui. O projeto é muito simples e pequeno, com o objetivo de resolver especificamente esse problema e nada mais.

Depois de criar o projeto, pervebi que seria simples modifica-lo para posteriormente suportar qualquer idioma. Em breve estarei liberando essa nova versão. Por conta disso o projeto talvez mude de jbehave-br para outro nome.

Quem nunca chegou numa empresa ou projeto, deu de cara com um código horroroso e logo disse: Que droga, quem foi o infeliz que fez esse código tosco? Ou o contrário: Quem foi o cara que fez esse código maneiro?

Essas situações são muito frequentes, principalmente a primeira, com códigos fedorentos. Por isso, eu adoto uma postura: Sempre assino meus códigos.

O que seria assinar o código? Bem, assinar o código é aquela simples documentação que vem logo acima do arquivo, como por exemplo em Java, usando o famoso javadoc:

package xpto;
import x;
/**
* @author Emerson Macedo
*/
public class Abc {
// ...
}

Assinar o código pode parecer meio arrogante mas o objetivo não é esse. O propósito de assinar o código e se expor. Quando você assina alguma coisa, explicitamente está colocando a sua autoria naquilo, ficando sujeito tanto a críticas, quanto a elogios.

Quando algum pintor faz um quadro, ele sempre vem assinado em alguma parte. Dificilmente o autor dessa obra de arte vai terminar esse quadro antes que ele tenha certeza que está com ótima qualidade (pelo menos na visão dele).

E no que isso implica? Isso implica que você (1) vai pensar 2 vezes antes de colocar aquela habitual gambiarra no seu código, (2) vai pensar bem antes de concluir alguma coisa sem devidos testes automatizados e (3) vai ser muito mais responsável com o código que você está desenvolvendo.

Conclusão

Como qualquer desenvolvedor, já desenvolvi códigos ruins em diversos projetos pelos quais passei. Aquele que nunca desenvolveu código fedorento que atire a primeira pedra. Hoje em dia, não desprezo a qualidade daquilo que desenvolvo. Acredito muito que quando assinamos nossos códigos e nos damos conta que outro desenvolvedor/programador irá utiliza-lo futuramente, isso gera um maior cuidado com a qualidade.

Alguns acontecimentos me fizeram refletir um pouco sobre a relação entre o desenvolvedor de software e os testes automatizados.

Muitas vezes parei pra explicar pra vários colegas de trabalho sobre a importância do assunto, fiz pair-programmming pra ensinar como se faz, em fim, investi muito tempo pra ajudar diversas pessoas com isso. Por incrível que pareça, tem muiiiiiita gente que ainda não entendeu muito bem. Portanto, resolvi classificar a relação entre o desenvolvedor e os testes automatizados em 5 níveis.

São eles:

1. Ignorante: Esse é o nível no qual o desenvolvedor não sabe direito o que são testes automatizados ou sequer ouviu falar sobre o assunto (acredite, ainda tem gente assim em pleno 2009).
2. Indiferente: Nesse nível, o desenvolvedor já sabe o que é, mas acha que essa prática/tecnica não serve pra nada. Apenas toma tempo e atrasa a entrega do produto que está sendo desenvolvido. A sensação dele é que sem os testes a entrega seria mais rápida (e a quantidade de bugs tb vão aparecer mais rápido).
3. Prequiçoso: Nesse nível eu encontro muita gente. É nesse nível onde a ficha caiu mas o camarada não toma coragem pra aprender a fazer os testes automatizados. Ainda existe o medo de perder muito tempo com essa prática e a preguiça impera, impedindo o progresso.
4. Decidido: Esse pra mim é o nível mais importante. É nessa hora que o desenvolvedor se dá conta que não dá mais pra desenvolver software sem testes automatizados. É nessa hora que o cara pensa: “como eu pude desenvolver sem testes até hoje?”. É nesse momento que inicia-se o aprendizado.
5. Profissional: Nesse nível, o desenvolvedor já não se sente mais confortável desenvolvendo sem testes automatizados. Desenvolver sem testes o incomoda profundamente. Nesse momento o mesmo está maduro quanto a importância dos testes e a aplicação na prática. O mesmo começa a se tornar um evangelista para os demais desenvolvedores e sempre que pode, fala sobre o assunto. Nesse momento o desenvolvedor pode realmente dizer que é um profissional, pois hoje em dia não se admite mais desenvolver sem ter testes automatizados que garantam qualidade daquilo que se desenvolve.

Em qual nível você está?

A Revista Visão Ágil, que sempre apresenta artigos muito interesantes, publicou este mês de outubro a edição número 5 com um artigo meu sobre Os 7 Pecados Capitais de Um time Ágil. O editorial está de parabéns pelo trabalho que fizeram. Realmente a revista ficou ótima.

O Artigo fala um pouco sobre erros comuns de times ágeis. Isso inclui não somente o time, mas P.Os, Scrum Masters e todos os demais envolvidos. Vale a pena conferir.

Os demais artigos também são de excelente qualidade e a leitura dos mesmos é extremamente recomendada.

Meus sinceros agradecimentos ao Manoel Pimentel e Felipe Rogrigues.

Certa vez, passei por uma situação que acredito que você já passou um dia na sua vida profissional. Tive que implementar uma funcionalidade nova num projeto e precisava alterar diversas partes do código desse projeto para implementar essa funcionalidade. Infelizmente esse projeto não tem uma boa cobertura de testes automatizados. Existem até alguns testes, mas não o suficiente.

Dentro do “possível”, adicionei testes no projeto para melhorar o nível de confiança nas alterações e conseguir trabalhar um pouco mais sossegado quanto a qualidade do que estava sendo desenvolvido. Aproveitei a oportunidade para estimular meus colegas no uso de testes automatizados. Eu poderia simplesmente ignorar os testes e manter o “padrão” atual do projeto, mas como bem disse uma vez o Guilherme Chapiewski num excelente post sobre inclusão de testes num projeto, no momento em que comecei a modificar o código desse projeto foi o momento em que comecei a colocar testes nele.

Nessa experiência, enumerei 3 sintomas que podem ser um indício de que seu código está virando o Código do Pânico. São eles:

1. Classes/Metodos/Atributos que aparentemente não são mais usados não são removidos, pois não existe certeza de que a remoção deles não vai causar problema.
2. Existe um medo enorme em modificar um método. Geralmente cria-se outro que faz “quase a mesma coisa” e com um nome parecido, pois estragar aquele método pode gerar até uma demissão.
3. Desenvolvedores adicionam gambiarras (ou bacalhau pra quem prefere) sem a menor pena, afinal de contas, o código já está cheio delas mesmo.

A maioria dos problemas que tornam o código do seu projeto um Código do Pânico se resolvem com praticas como TDD, mantendo uma boa suite de testes e também retirando as gambiarras do seu código, que quando não removidas, estimulam outros desenvolvedores a adicionar mais um pouco sempre que a pressa pede.

O quanto você tem medo de alterar o código do seu projeto?