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.

Sobre a melhoria contínua, vou focar aqui nos aspectos (1) errar e (2) compromisso com a mudança.

Errar

O erro sempre foi um tabu nas empresas. Errar sempre foi considerado sinônimo de fraqueza ou incapacidade. No modelo que estavamos acostumado a trabalhar, erros geralmente eram punidos com severas advertências, demissões e/ou humilhações. No modelo em que estamos tentando trabalhar, os erros devem ser vistos como oportunidade para crescermos e melhorarmos como indivíduo e como profissional. Dessa forma, errar faz parte do processo, já que inevitavelmente erraremos algumas vezes ao longo da jornada.

Compromisso com a mudança

Quando pensamos em compromisso com a mudança no nível da empresa, talvez seja mais fácil, mas quando pensamos para o nível pessoal, complica um pouco. Mudar manias, paradigmas pessoais e outras coisas mais, geralmente é um processo bemmmm complicado. Porém, essa é a oportunidade que temos para aplicar na prática o que aprendemos com os nossos erros.

O compromisso em melhorar é fundamental para que haja resultados práticos. Errar e não melhorar, repetindo os mesmos erros, faz com que de nada tenha servido a oportunidade de reflexão.

Nosso papel quando os outros erram

Quando um colega seu errar, ajude. Criticar, humilhar, querer ver o mau dessa pessoa, de nada ajudará. Isso só fará com que você esteja piorando como profissional e como pessoa. Se for possível, ajude, se não for, torça para que essa pessoa consiga usar seu erro como uma oportunidade de melhoria. E não se esqueça: você também erra e vai continuar errando.

Testemunho pessoal

Recentemente, tive a infelicidade de cometer um erro. Foi um pequeno erro, mas que aconteceu e então isso me entristeceu bastante. No momento em que percebi essa falha, tratei de resolver o que precisava ser resolvido de forma mais urgente e deixei a reflexão para o primeiro momento oportuno.

Passado pouquíssimos dias, fiz uma profunda reflexão sobre a falha para que ela não viesse a ocorrer novamente. Dessa forma, além de melhorar como pessoa, acredito ter melhorado como profissional.

Talvez você pense: mas assumir assim um erro? Não tem vergonha disso não?

Digo com toda naturalidade: NÃO!!!

Quem erra é porque está evoluindo, quem erra é porque tenta alguma coisa, quem erra é porque pensa, quem erra é porque raciocina … quem erra, é porque está vivo. A diferença está em aproveitar isso como oportunidade.

Conclusão

Eu erro, você erra. Logo, nós erramos. Portanto, a melhoria contínua começa em nós!!!

Referências:

[1] http://visaoagil.wordpress.com/2009/01/06/melhoria-continua-e-efetiva-atraves-do-hansei-e-kaizen/

[2] http://www.slideshare.net/Comunidade_Lean_Thinking/melhoria-contnua

[3] http://en.wikipedia.org/wiki/5_Whys

[4] http://pt.wikipedia.org/wiki/Kaizen

[5] http://en.wikipedia.org/wiki/Hansei

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/

Como já mencionei em outros posts nesse mesmo blog, nossa área de desenvolvimento de software/informática está cheia de termos/nomenclatura que se confundem facilmente (e.g. as discussões no GUJ sobre DTO). Mais uma vez, falarei sobre um deles: a classificação júnior, pleno, sênior.

Dando uma passeada pelos sites de emprego de informática, é fácil ver vagas para analista de sistemas / programador / desenvolvedor júnior, pleno e sênior, etc. Acontece que a maioria das pessoas (inclusive os gerêntes de TI) não sabem muito bem fazer essa distinção entre os níveis, causando uma grande confusão na cabeça de todo mundo, inclusive na hora de negociar o cascalho. Portanto, vamos começar pelo básico …

Não sou uma pessoa entendida de RH, muito menos sei a história sobre como começou essa nomenclatura de júnior, pleno e sênior. Mas como trabalho na área de TI faz 12 anos e já passei por um bocado de empresas, acho que posso dar meu pitaco sobre o assunto. As melhores definições que consegui na internet para sênior foram: ancião, velho, pessoa com mais experiência em alguma profissão. De cara tem alguma coisa estranha na resposta que o tal gerente deu pro meu amigo, mas não para por ai.

No início da minha carreira, nas empresas onde passei, geralmente o cara sênior era um cara com mais experiência, uma pessoa que viveu mais situações, uma pessoa mais madura (não necessáriamente velha ou idosa). Por muitas vezes, essa pessoa não conhecia uma ferramenta ou outra de trabalho que eu conhecia, mas isso de maneira alguma me colocava no mesmo nível daquele profissional, pois tomando conhecimento da existência daquela ferramenta e utilizando um pouco do seu tempo, a tal ferramenta estava absorvida por este.

E o que eu quero dizer com isso? Eu quero dizer que se você começou agora, mesmo que você saiba python, ruby, java, erlang, haskell, xpto, brainfuck, você é Júnior ainda. Lógico que é ótimo saber diversas ferramentas e eu recomendo a todos estudar para isso. O mesmo princípio se aplica ao profissional sênior. Fatalmente tem algumas coisas que lhe fogem ao conhecimento, porém a diferência é que esse naturalmente conhece muitas ferramentas  devido a sua experiência ao longo dos anos. Não foi simplesmente um livro que leu ou um tutorial da internet que fez, mas projetos reais que participou. Um sênior deve saber debater com seus superiores sem medo, com argumentações bem formuladas, sabendo exatamente a sua posição, mas sem muito se intimidar quando conversa com outro profissional acima na hierarquia. Deve chamar a responsabilidade para si em momentos críticos, deve ajudar e ensinar os demais simplesmente porque isso é de sua responsabilidade.

Saber ou não uma determinada linguagem ou ferramenta não faz necessáriamente de você nem júnior nem sênior, pois isso as vezes depende da sua trajetória de carreira. Eu por exemplo não sei nada de ABAP, pois nunca trabalhei com SAP ou algo que use essa linguagem. Talvez você esteja aprendendo Java nesse momento mas tem 10 anos de experiência com C/C++ e tem ótimas práticas de programação. Em fim, é bem relativo.

Pra finalizar, certa vez um amigo me disse que sênioridade é algo como um estado de espírito. Vou até um pouco além disso. Acredito que sêrionidade é um estado avançado de profissionalismo aliado a maturidade alcançada ao longo do tempo.

Disclaimer:

Para que não pareça que defendo regime de quartel, quero deixar bem claro que hoje em dia de nada adianta você ser maduro e experiente se você é um profissional encostado e desatualizado. E o talento, é claro, sempre fala mais alto.

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.

Aplicativos Open Social parecem algo como uma brincadeirinha de criança, coisa que qualquer pessoa faz. Mas na verdade, desenvolver esse tipo de aplicação para um programa como o Big Brother Brasil não é tão simples. Aplicações de grande volume geralmente usam arquiteturas recheadas de cache, processamento assíncrono usando fila, criptografia, alguns servidores e um bocado de outras coisas que o torna tão complexo quanto qualquer outro sistema.

Quero aproveitar também e destacar, que conseguimos desenvolver o produto completo “do zero”, em pouco mais de 1 mês. Isso inclui configuração de todos os servidores (inclusive produção que são várias máquinas), ambiente interno de desenvolvimento, servidor de integração contínua, desenho dos bonecos dos brothers de forma personalizada, vários testes de carga em ambientes que simulam produção e muita comunicação. Estou falando disso, pois usamos metodologias ágeis e acredito fortemente que se não fosse assim, não teria sido possível entregar o aplicativo nesse tempo (e não trabalhamos nenhum fim de semana). No caso específico aqui da globo.com, SCRUM é a metodologia usada, mas poderia ser Extreme Programming ou alguma outra qualquer. Um detalhe também importante é que nosso time tem apenas 10 pessoas, o que contraria um pouco o modelo tradicional que diz que com mais gente o trabalho anda mais rápido.

Se você gosta de Big Brother Brasil e deseja expressar sua opinião sobre algum brother, entre na seção de aplicativos do orkut e procure por: BBB - Voodoo Brother.

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.

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á?

Pensando sobre essa situação imaginei nós, os desenvolvedores. Muitas vezes trabalhamos com muito stress, sobrecarga de trabalho e umas boas horas extras.

O que será que acontece quando sobrecarregamos um servidor? Quando estressamos o mesmo? Quando fazemos testes de carga e performance, vemos que num determinado momento o servidor não aguenta e literalmente abre o bico.

Agora, se os servidores (que são máquinas, não humanos) precisam estar abaixo da capacidade produtiva pra não perder sua qualidade, imagine pessoas sem um tempo pra respirar, pensar e descansar?

Trabalhar no limite da sua capacidade produtiva torna o trabalho improdutivo, apesar de ser contra-intuitivo, talvez.

Passeando um pouco pelo dicionário, algumas definições me chamaram um pouco a atenção:

• Criar: inventar; imaginar; dar existência a; desenvolver;
• Fabricar: executar ou fazer executar certos produtos por processos mecânicos; manufacturar; construir;

É difícil perceber a diferença? Acho que não …

Se formos na Wikipedia podemos encontrar algumas informações ainda mais relevantes. Vejamos parte do texto:

… trabalhadores manufaturam bens ou supervisionam o funcionamento de máquinas que processam um produto, transformando-o em outro. A maioria das fábricas atuais têm grandes armazéns e depósitos com equipamentos pesados, utilizados na produção da linha de montagem …

Oito anos atrás, Fowler escreveu sobre isso, explicando claramente que a parte de “fabricar” o software é geralmente uma simples task do ant ou um goal do maven ou alguma coisa no rake, etc.

Já foi falado zilhões de vezes nos foruns de tecnologia que fábrica presupõe trabalho repetitivo, fazer o mesmo produto várias vezes (você faz o mesmo software várias vezes ou quando precisa de uma cópia simplesmente faz um cp arquivo1 arquivo2?), desenvolvimento em fazes (i.e. waterfall). Portanto, não faz sentido comparar nosso trabalho com trabalho de fábrica.

O trabalho do desenvolvedor é criar o software, fazer design do código em todo o tempo, assim como os arquitetos da contrução civil fazem no autocad, ou no bom e velho papel. A diferença é que nós temos a condição de construir (i.e fabricar) o nosso software com custo “zero”. Não precisamos de pedreiros, tijolos, vigas, argamassa, etc. Agente usa o Ant, Maven, Rake, Make ou wathever ora bolas. É tudo de graça. O resultado do trabalho deles é físico, o nosso são bits e bytes.

O erro sempre foi fazer a associação: desenvolver = construir/fabricar. A associação mais correta é desenvolver = projetar/arquitetar/desenhar.

Até a próxima …