Blogosfera | RubyOnBr

Rails i18n: interpolação, pluralização e valores default

Diego Carrion — Sun, 12 Oct 2008 23:30:19 -0300

Interpolação

Quando chamamos o método translate podemos passar algumas opções como parâmetro e elas serão interpoladas com a mensagem correspondente. Supondo que temos o arquivo de mensagens:

pt-BR:
  welcome : "Bem vindo {{name}}!"

quando executemos:

I18n.translate(:welcome, :name => "Diego Carrion")

o resultado ira ser:

Bem vindo Diego Carrion!

Pluralização

Algumas vezes quando interpolamos uma mensagem com um número queremos que o comportamento seja distinto quando o número representar uma ou varias unidades. Nesses casos podemos utilizar a opção count e definir uma mensagem para one (count == 1) e other (count > 1). Caso tenhamos as seguintes mensagens:

pt-BR:
  shoutt_received :
    one : "1 mensagem recebida"
    other : "Foram recebidas {{count}} mensagens

ao executar:

I18n.translate(:shoutt_received, :count => 1)
I18n.translate(:shoutt_received, :count => 10)

obteremos como resultado:

1 mensagem recebida
Foram recebidas 10 mensagens

Valores default

Ao chamar o método translate podemos especificar um valor a ser utilizado caso a mensagem para a chave passada como parâmetro não seja encontrada:

I18n.translate(:hello_world, :default => "Hola mundo loco!")

Rails i18n: populate agora é load_path

Diego Carrion — Sun, 12 Oct 2008 02:58:07 -0300

Em Julho escrevi um post descrevendo como trabalhar com o novo suporte a i18n do Rails. Na oportunidade mencionei que podíamos carregar nosso arquivo de mensagens com o método populate do modulo I18n, assim:

I18n.populate do
    require "caminho/ate/#{locale}.rb"
  end

Resulta que desde esse momento ate hoje, a tarefa de carregar o arquivo de mensagens passou de populate para load_translactions, de load_translactions para load_paths e de load_paths para load_path, pelo que se hoje quisermos carregar algum arquivo de mensagens, teremos que executar a seguinte sintaxe:

I18n.load_path = "caminho/ate/#{locale}.rb"

Links for 2008-10-11 [del.icio.us]

Flavio Granero — Sun, 12 Oct 2008 02:00:00 -0300

Squirrel Updates for Rails 2.1, now with Named Scopes!
Como usar o Squirrel para construir queries complexas com uma sintaxe Rubista, tudo de forma integrada com named_scopes

Links for 2008-10-11 [del.icio.us]

Flávio Maltempe — Sun, 12 Oct 2008 02:00:00 -0300

Squirrel Updates for Rails 2.1, now with Named Scopes!
Como usar o Squirrel para construir queries complexas com uma sintaxe Rubista, tudo de forma integrada com named_scopes

O TOMJobs é isso!

Carlos Eduardo — Sat, 11 Oct 2008 13:01:52 -0000

Imagine um site de emprego diferente, um site onde você não irá deixar somente seu currículo em pdf ou texto e nem precisará se deslocar até outras cidades para participar de uma entrevista em uma grande empresa após receber por email o contato para a primeira seleção.

O TOMJobs é isso! Uma forma diferente e interativa de conseguir aquele emprego em qualquer lugar do mundo sem sair de sua casa.

Cobertura de Testes em Flex

Daniel Lopes — Sat, 11 Oct 2008 04:57:00 -0000

Todo mundo sabe que fazer testes automatizados para seus códigos em Ruby é uma prática comum, temos vários frameworks de teste como RSpec, Should, Test::Unit e vários outros, não sou nenhum expert em nenhum deles mas conheço um pouquinho de RSpec e Test::Unit e de fato pode agilizar muito seu desenvolvimento e salvar sua vida em várias situações… mas e em Flex??? Não é tão comum assim, mas estou fazendo este post rápido apenas para indicar um link que econtrei hoje. Um projeto que faz para o Flex algo semelhante ao RCov do Ruby.

Ainda não usei o projeto e nem testei, mas parece legal. Fica aqui a dica e se alguem testar ou já tiver usado poste aqui nos comentários. ;)

Vejam o link do projeto:

http://code.google.com/p/flexcover/

Rails Summit: Últimos Dias!

Fábio Akita — Fri, 10 Oct 2008 13:08:02 -0300

Pessoal, não se esqueçam: as inscrições se encerram nesta segunda-feira. Quem não se inscrever online até lá e mudar de idéia ainda poderá participar mas precisará pagar na entrada no dia do evento.

Aconteceram alguns pequenos Cisnes Negros nos últimos dias :-)

Primeiro, o Carlos Villela não poderá vir. Ele ficou preso em projeto na ThoughtWorks e acabou tendo que declinar. Mas não se preocupem, em seu lugar palestrará o Carlos Brando, nome mais do que conhecido na comunidade Rails. E pelo que ele me disse, não apenas ele mas o pessoal da Surgeworks estará participando do evento e da palestra numa sessão de perguntas e respostas também. Não deixem de participar.

Outra coisa: o Charles Nutter e Tom Enebo viriam para palestrar, porém tiveram problemas de última hora com visto (quem já lidou com consulado sabe que às vezes é meio uma roleta-russa). De qualquer forma eles concordaram em participar online. Da mesma forma como o David Hansson já estava confirmado para participar via video conferência, então eles farão da mesma forma. O horário e dia ainda é o mesmo.

E falando no David Hansson, ele também teve problemas de última hora. No fim o que conseguimos fazer foi o seguinte: a palestra dele que seria no dia 16 às 11:30 agora será no dia 15 às 11:20. Dessa forma, a sessão paralela que seria eu e o Jay Fields mudou para o dia 16.

Vejam a programação atualizada no site do evento

Palestrante Rails Summit: George Guimarães

Fábio Akita — Fri, 10 Oct 2008 11:02:54 -0300

O Rails Summit é semana que vem! Estamos nos dias finais de inscrição. E aproveitando, vamos conhecer mais um de nossos palestrantes, George Guimarães, da startup brasileira Pagestacker.

Essa palestra será particularmente importante para aqueles que já estão com a mão na massa em projetos de Rails e agora precisam colocar suas aplicações em produção. O George explicará as minúcias sobre infra-estrutura e como colocar aplicações web ao público.

Vamos conhecer o George:

AkitaOnRails: Poderia se apresentar e falar um pouco mais sobre você? Principalmente suas experiências anteriores em tecnologia ou empreendedorismo pré-Rails?

George Guimarães: Meu nome é George Guimarães, tenho 23 anos, sou formado em Engenharia Elétrica pela Escola Politécnica da USP e sou um dos fundadores do Pagestacker. No Pagestacker, sou responsável pela parte de infra-estrutura.

O Pagestacker é um aplicativo de bookmarking diferente, com forte ênfase em simplicidade e em seu mecanismo de busca interno. O resultado disso é um modelo de uso voltado para o armazenamento de altos volumes de informações e facilidade de localização de documentos e nem tanto a sua categorização.

Sempre estive ligado na área de infra-estrutura, servidores, e afins, desde a época da Poli, como no meu trabalho no LSI-USP (Laboratório de Sistemas Integrados), onde conheci o Fábio Kung.

Também atuei por muito tempo na empresa júnior da faculdade, a Poli Júnior, gerenciando projetos de TI e liderando algumas equipes da empresa.

Recentemente, trabalhei na Gemalto, multinacional francesa líder em segurança digital.

AkitaOnRails: Como se encontrou com Ruby on Rails? O que foi que o convenceu a apostar seus recursos em aprender e usar essa tecnologia? O que você mais gosta sobre Ruby e Rails?

George Guimarães: Quando tivemos a idéia de montar uma empresa de engenharia de software, pesquisamos diversas alternativas. Já havíamos trabalhado com plataforma .NET, mas o Rails acabou superando nossas expectativas.

O que eu mais gosto sobre Ruby e Rails? Bem… sou o responsável pela infra, e como eles não escalam, significa mais desafios para mim (risos).

Brincadeiras à parte, acho a linguagem Ruby a mais legível de todas que eu já trabalhei. Isso pra mim é muito importante. Legibilidade do código. Facilita pra todo mundo (revisão de código, mudança de equipe, reuso de código…). E isso acaba transbordando pro mundo Rails. Facilidade de estender o framework, facilidade de adaptar o código pra sua necessidade. O
que acaba também gerando uma comunidade fantástica de desenvolvedores.

AkitaOnRails: Você participa da comunidade brasileira de Ruby e Rails? Tem blog,
participa de projetos open source, ministra palestras ou cursos?

George Guimarães: Blogo esporadicamente no http://blog.georgeguimaraes.com, mas tem sido cada vez mais difícil atualizar o blog por conta do alto volume de trabalho no Pagestacker.

Participei de palestras no RejectConf’SP 07 e no WebDevCamp’SP. Também procuro responder os emails que recebo com dúvidas sobre Rails e infra-estrutura.

Da nossa equipe, o José Valim se tornou o mantenedor oficial do Footnotes (anteriormente mantido pelo Dr. Nic), além de publicar os plugins que criamos para usar com o Pagestacker no blog dele.

Já o Hugo Barauna contribuiu com o desenvolvimento do Contacts, para integração com os webservices do Gmail, Hotmail e Yahoo Mail.

AkitaOnRails: O Rails Summit será uma grande oportunidade para conhecer pessoas, ver o que os outros estão fazendo, trocar idéias e ver o rumo da tecnologia. Sobre o que será sua palestra?

George Guimarães: Será um apanhado sobre escalabilidade, capacity planning e algumas técnicas que considero que todo desenvolvedor (seja ele railer ou não) deveria estar atento.

É fácil começar a desenvolver em um framework como o Rails e “esquecer” aspectos básicos de arquitetura e focar apenas no desenvolvimento de código. Mas é preciso pensar na aplicação como um todo.

Isso não é culpa do framework não. Longe de mim falar mal do Rails (risos), mas o desenvolvedor também precisa ter outros conceitos importantes em mente.

AkitaOnRails: O que você tem a dizer aos desenvolvedores brasileiros que gostariam de usar Rails mas se vêem na situação de aprender apenas a tecnologia que tem maior marketshare?

George Guimarães: Aprender linguagens e frameworks novos é necessário! É o exercício de cada dia do desenvolvedor. Praticamente um hobby. Mesmo que você não vá usar Rails diretamente no seu trabalho, isso vai tornar você um desenvolvedor
melhor, com certeza.

Se você é um desenvolvedor que tem uma base sólida em software, conhece os conceitos básicos de computação, então você não precisa se preocupar com modismos ou maior penetração no mercado.

E nunca se sabe… Vai que tem uma startup precisando contratar um pessoal gabaritado! =D

Autospec Autotest-Notification = Autospec-Notification (e novidades)

Diego Carrion — Fri, 10 Oct 2008 01:21:11 -0300

O outro dia sem querer percebi que o RSpec-Rails cria um arquivo chamado autospec na pasta script do nosso projeto Rails. Isso quer dizer que ao executarmos script/autospec criaremos um processo que ficara atento as mudanças no código e quando achar uma ira executar os testes correspondentes. O comportamento é similar ao do autotest, com a diferença que os testes executados serão os da pasta spec (RSpec) e não os da pasta test (Test/Unit).

O melhor de tudo o mencionado é que o script autospec utiliza o autotest por embaixo dos panos, pelo que podemos utilizar o autotest-notification para ir recebendo alertas com os resultados em quanto estamos programando, xavecando uma mina em algum IM ou qualquer outra coisa no computador.

Ah! Graças ao Lucas Uyezu agora o autotest-notification também informa sobre testes pendentes e caso estejam um pouco enjoados dos ícones padrões, Samuel Flores adicionou um novo modelo de icones que podem ser ativados na instalação com o parâmetro buuf:

an-install --buuf

Update: para ativar a notificação de testes pendentes é necessário o parâmetro pending:

an-install --pending

Off-Topic: O Manifesto Ágil, ou Como se Tornar o Google

Fábio Akita — Thu, 09 Oct 2008 20:07:54 -0300

Não sou um dos melhores estudiosos de metodologias Ágeis que existe, nem de longe. Por isso vou me dar ao luxo de seguir uma visão talvez “ingênua” sobre o que eu pessoalmente enxergo sobre o assunto. E eu sei, eu sei, a palavra “Google” no título é mais para chamar a atenção. No final eu explico ;-)

Antes de mais nada, quero separar duas coisas: metodologia e filosofia. A parte mais relevante sempre é a filosofia. Se uma empresa/profissional não absorveu a filosofia Ágil dificilmente será verdadeiramente Ágil por mais que se implemente uma metodologia, ou seja, uma série de procedimentos. Você pode até ler receitas de pratos franceses, mas até entender como um cozinheiro de verdade pensa, até adquirir a cultura francesa, dificilmente terá pratos franceses decentes, apenas cópias mecânicas de baixa qualidade.

O importante não é o “como” e sim o “porquê”. O Manifesto Ágil diz isso já no seu primeiro valor. Vamos relembrar os quatro valores Ágeis:

Estamos descobrindo melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazê-lo. A partir desse trabalho temos os seguintes valores:

Indivíduos e interações mais que processos e ferramentas

Software que funciona mais que documentação completa

Colaboração do cliente mais que negociação de contratos

Responder à mudança mais que seguir um plano

Quer dizer, mesmo que exista valor nos ítens da direita, nós valorizamos mais os ítens da esquerda.

O primeiro valor já diz tudo: indivíduos mais que processos.

Neste artigo quero mostrar porque a grande maioria das empresas não é efetivamente Ágil, mesmo quando implementam “metodologias” Ágeis.

Princípios por trás do Manifesto Ágil

Para recapitular, será útil citar os 12 Princípios por trás do Manifesto de Valores. Muita gente já leu todos esses ítens. Mas “ler” e “entender” são duas coisas completamente diferentes. Para efeitos da minha explicação, vou colocar algumas palavras-chave em negrito para me referir a elas mais tarde.

Nós seguimos estes princípios:

Nossa maior prioridade é satisfazer o cliente através de entregas mais rápidas e contínuas de software que agrega valor.

Recebemos bem mudanças de requerimentos, mesmo mais tarde no desenvolvimento. Processos ágeis gerenciam mudanças para a vantagem competitiva do cliente.

Entregamos software que funciona frequentemente, de algumas poucas semanas a poucos meses, com preferência para intervalos mais curtos.

Pessoas de negócio e desenvolvedores devem trabalhar juntos diariamente pelo projeto.

Construímos projetos através de indivíduos motivados. Dê-lhes o ambiente e suporte que precisam, e confie neles para ter o trabalho executado.

A maneira mais eficiente e efetiva de transportar informação para dentro e para fora da equipe de desenvolvimento é através de conversa face-a-face.

Software que funciona é a medida principal de progresso.

Processos Ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores, e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Atenção contínua à excelência técnica e bom design melhora a agilidade.

Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.

As melhores arquiteturas, requerimentos, e designs emergem de equipes auto-organizadas.

Em intervalos regulares, as equipes refletem sobre como se tornar mais efetivos, então ajustam seu comportamento de acordo.

O Quinto Elemento

“Construímos projetos através de indivíduos motivados. Dê-lhes o ambiente e suporte que precisam, e confie neles para ter o trabalho executado.”

Eu realmente não sei como os fundadores do Manifesto chegaram a estes princípios, mas baseado apenas neste ponto imagino que eles sejam realmente muito experientes. Este elemento, para mim, é o mais denso de todos os Princípios.

Corolários ao Quinto Elemento são o 11_o e 12_o Elementos. Vou explicar porque.

Escalando Agilidade

Recentemente eu citei um capítulo do livro Scaling Lean and Agile Development: Successful Large, Multisite and Offshore Products with Large-Scale Scrum. Acredito que muita gente não teve paciência para ler, por isso vou resumir a parte que me interessa.

Esse PDF discute as diferenças entre Feature Teams e Component Teams. De forma simplificada, uma equipe Ágil é necessariamente uma Feature Team, ou seja, uma equipe que é o mais independente possível e assume um produto ou uma feature completa de um produto, do começo ao fim, dos requerimentos até o contato com o cliente.

Um Componente Team é o estilo tradicional e departamental. Cada equipe é responsável apenas por um trecho de vários produtos. Equipe de interfaces, equipe de infra-estrutura, equipe de arquitetura, equipe de componentes visuais, equipe de banco de dados, equipe de qualidade e assim por diante.

Uma Feature Team é uma equipe cross-funcional, normalmente formada por generalistas. Uma Component Team é uma equipe limitada, formada normalmente por especialistas. Uma Equipe Scrum é, por definição, uma Feature Team, capaz de realizar todo o trabalho de um ítem de um Product Backlog.

Como eu disse antes, esqueça o “como” por enquanto.

Lei de Conway

Melvin Conway, em abril de 1968 escreveu uma pesquisa onde um trecho dela entraria para os anais da história da computação:

“Qualquer organização que faz design de sistemas (definição ampla) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da empresa”

Como está explicado em seu site, o famoso Frederick Brooks citou essa pesquisa e sua idéia no clássico (que todo profissional da área de tecnologia deveria ler) The Mythical Man Month, chamando essa idéia de Lei de Conway. Brooks reconheceu que a lei tinha corolários importantes em teorias de gestão. Aqui vai uma afirmação sua:

“Como o design que acontece primeiro quase nunca é o melhor possível, o conceito de sistema que permanece pode precisar de mudanças. Portanto, flexibilidade da organização é importante para design efetivo.”

Como eu já disse em Matando a Média até hoje ainda aplicamos metodologias e processos Gaussianos. Ainda não consegui escrever um material mais completo que explique isso, portanto assista ao vídeo que gravei e leia os materiais de referência que indico nele. Por enquanto apenas entenda que a grande maioria do que conhecemos como verdades incontestáveis da Teoria das Organizações não se aplica mais.

Essas Teorias antiquadas, que delineiam cadeias de comando rígidas, diversos departamentos “feudais”, cultura baseada em cargo e poder político, foram feitos essencialmente para dar grande grau de controle a chefes de seção em linhas de fábricas do século XIX, onde o máximo que se esperava de um trabalhador era que ele apertasse parafusos e não executasse muitos trabalhos que exigissem o cérebro.

Como diz a Lei de Conway: as equipes tendem a criar estruturas que espelham a estrutura da organização. O corolário disso é: tenha uma empresa que incentiva o trabalho medíocre e suas equipes serão medíocres. Como eu falava sobre o Quinto Elemento: “… dê-lhes o ambiente e o suporte que precisam …”

O PDF de Larman menciona Brad Silverberg, VP sênior do Windows e Office que enfatizou:

“O software tende a refletir a estrutura da organização que a construiu. Se você tiver uma organização grande e lenta, você tende a construir software grande e lento.”

Uma afirmação irônica, mas verdadeira.

Generalistas vs Especialistas

Empresas tradicionais que se iludem achando que conseguirão controle total de suas equipes apenas conseguem criar funcionários pouco produtivos, sem atitude, sem perseverança, comodistas, limitados e que nunca aprenderão nada de novo.

Isso porque o estilo de Controle Total, prefere a divisão de trabalho, como em linha de chão de fábricas, onde cada equipe faz uma parte do todo. Nesse estilo de gestão reina o incentivo aos Especialistas.

Especialistas são aqueles funcionários que normalmente começaram determinado pedaço do sistema e apenas eles sabem como aquele pedaço funciona. Eles não se sentem muito confortáveis em dividir esse conhecimento e se sentem menos confortáveis ainda em aceitar mudanças externas. Ele costuma ser tratado como herói porque quando há urgência, não há tempo para outra pessoa aprender sobre aquele pedaço e apenas ele consegue resolver o problema.

Se você tem heróis desse tipo em sua empresa, esses devem ser os primeiros a ser despedidos.

Não é à toa que equipes Scrum são, por definição, Feature Teams. Caso contrário o primeiro efeito que vem à tona é o seguinte:

Reconhecem isso? Cada Component Team faz seu Sprint, sua iteração. Somente quando a iteração de uma equipe acaba, a da outra pode começar. Isso justamente porque nenhuma das equipes comanda a Feature completa e depende de pedaços das anteriores.

Isso tem um nome: bem vindos de volta ao Waterfall! Não importa que costumem chamar isso de mini-waterfall, cascata é cascata, não importa o tamanho delas.

Outros grandes efeitos colaterais de Component Teams: como ninguém é efetivamente o dono do produto, nenhuma das equipes se sente responsável pelo todo, apenas por sua parte. Naturalmente emergem os comportamentos de “a minha parte eu fiz, a culpa é da outra equipe.”

Além disso, Component Teams, por sua própria natureza de lidar apenas com um tipo de problema, força seus integrantes a se tornarem especialistas. E fazendo assim, força esse profissional a limitar seus conhecimentos, não dando absolutamente nenhuma motivação para aprender coisas novas.

Lembram do Quinto Elemento? “Construímos projetos através de indivíduos motivados …” Onde estão os indivíduos motivados numa organização que força todos à mediocridade? Claro, não quer dizer que todos devem saber tudo de tudo, sempre haverá uma ou mais disciplinas onde cada profissional se adeque mais, mas todos devem ser incentivados a saber um pouco de todo o resto. Por isso mesmo Feature Teams são importantes: você tem vários especialistas onde cada um sabe um pouco das coisas diferentes que seu colega do lado sabe fazer. E com isso Pair Programming ganha novo significado.

Além disso Test Driven Development começa a fazer muito mais sentido se a equipe é realmente responsável por um produto/feature que agrega valor de verdade ao cliente final. Uma vez que não há dependência entre equipes fica muito mais claro como realizar os testes completos. Mas há outra questão sobre testes que vou explicar mais abaixo.

Auto-Organização

Este é o ponto crucial nas novas teorias organizacionais. Don Tapscott e Anthony D. Williams chamariam isso de Wikinomics ou a economia da colaboração.

As organizações tradicionais tem horror ao caos e por isso perseguem controle absoluto de maneira patológica, o suficiente para ser prejudicial.

E eles deveriam mesmo ter horror ao caos. Mas o que elas precisam entender é que existe o fenômeno de ordem que emerge a partir do caos.

Estamos acostumados a pensar em eventos isolados, em resultados baseados na soma de eventos independentes. Coloque uma colher de açúcar e o chá fica doce. Coloque duas colheres de açúcar e o chá fica duas vezes mais doce.

Porém, sistemas dinâmicos não podem ser definidas dessa forma. Certos sistemas são muito sensitivos a condições iniciais, dando resultados não lineares. Em particular, fenômenos naturais como relacionamentos sociais, cadeias alimentares, eventos econômicos, são todos sistemas não lineares.

Isso retorna à minha palestra sobre Distribuições Power Law, ou Distribuições de Pareto. Recapitulando, um mundo platônico e linear pode ser modelado segundo Gauss. Esse tipo de distribuição é extremamente confortável para os analistas pois possui média definida e desvio padrão constante, estável. Power Laws, por sua vez, são caracterizados pela ausência de média e desvio padrão que tende ao infinito!

O ponto mais óbvio é que “Bell Curves” (curvas em forma de sino) como a Normal/Gauss, exigem eventos independentes, isolados, como jogar dados ou tirar cara ou coroa em uma moeda ~~não viciada~~. Não é difícil ver, por exemplo, que comportamento de seres humanos pode ser tudo, menos independentes: por definição, humanos se relacionam entre si, logo formamos sistemas altamente dependentes.

Mas algo importante em redes dinâmicas, ao contrário do que se imaginava, não formam redes com conexões aleatórias – cuja distribuição seria Normal – mas sim exibem distribuição de Pareto. Albert-László Barabási explica em mais detalhes a formação de Redes Scale-Free

Como eu dizia, se alguém pensa em nós (pessoas, animais, neurônios, vírus) e conexões (amizade, transmissão, sinapse), é mais natural primeiramente imaginar que os nós se conectem de forma aleatória e caótica. Porém, os estudos de Barabási e as observações detalhadas dos fenômenos naturais levou à conclusão que elas tendem a formar redes scale-free, cuja distribuição de nós segue Pareto, ou seja, poucos nós concentram a grande maioria das conexões e muitos nós dividem as poucas conexões restantes, formando algo assim:

Para nós de tecnologia, isso se pareceria com a representação da Internet, onde os nós são websites e as conexões são, literalmente, os links entre elas. Mas é isso mesmo: a Internet segue uma distribuição de Pareto.

Para os que tem tendências socialistas, esqueçam Marx, ele estava obviamente errado ao se inspirar na curva de Gauss e tentar rebaixar toda a sociedade à média. O pensamento de “tirar dos ricos para dar aos pobres” é totalmente anti-natural. O natural é exatamente o oposto: poucas pessoas vão sempre deter a grande maioria da riqueza do mundo, enquanto a maioria das pessoas terá menos riquezas. A única forma de os pobres enriquecerem é fazer o sistema inteiro enriquecer, incluindo os próprios ricos. A natureza sempre privilegia a meritocracia, nunca a mediocridade.

Assumindo que todos estudem mais um pouco sobre Barabási, Poincaré, Mandelbrot, Zipf, Pareto, Bak e assuntos como redes scale-free, power laws, self-organized criticality, phase transition, chaos, fractals, vamos concluir algo rapidamente: a ordem costuma sim emergir do caos, redes se formam como Barabási descreveu, através de mecanismos como preferential attachment e no final teremos redes scale-free, auto-organizadas.

80/20

A famosa regra 80/20 de Pareto não veio a partir do nada. Num estudo na Itália muitos anos atrás, Wilfredo Pareto constatou que 80% do território italiano esta nas mãos de não mais do que 20% da população. Daí o “80/20”.

Essa divisão é justamente o que mostra uma distribuição de Pareto, conforme figura abaixo:

Como Chris Anderson explica em seu livro The Long Tail, pensa na famosa Wikipedia. Na época da publicação de seu livro em 2006 a Wikipedia já tinha 860 mil artigos, contra 80 mil da Enciclopédia Britannica.

A idéia de Jimmy Wales foi ousada e bastante controversa apesar da boa intenção de fornecer uma rica e extensa enciclopédia gratuita a todas as pessoas do mundo, incluindo crianças pobres em países sub-desenvolvidos que de outra forma talvez nunca tivessem acesso à informação.

Wales começou com o projeto Nupedia em 2000, com apenas alguns poucos verbetes e uma idéia que na realidade se popularizou antes disso, com Linus Torvalds e seu Linux: criar uma plataforma totalmente aberta (livre, liberdade) onde qualquer pessoa que quisesse poderia contribuir, revisar, refinar.

Olhando hoje, em 2008, todos diriam que Jimbo (como é conhecido) é um gênio. Mas no ano 2000, ele foi considerado um louco. Quando vemos as coisas em retrospectiva sempre é muito mais simples de criar uma narrativa que encaixa-se perfeitamente nos eventos que já aconteceram. Como Nassim Nicholas Taleb diria: depois que um Cisne Negro acontece, é fácil explicá-lo, mas antes que ele aconteça é impossível prevê-lo.

Seguindo o exemplo de Torvalds, Jimbo criou um ambiente adequado para colaboradores. Ele foi capaz de motivar as pessoas e, principalmente, confiar nelas, pois ao contrário do sistema editorial tradicional, não haveria editores ou filtros: tudo o que qualquer um digitasse estaria imediatamente disponível. Sua esperança é que erros grosseiros seriam rapidamente corrigidos pelos próprios colaboradores, assim como Eric S. Raymond descreve no clássico The Cathedral and the Bazaar:

“Dada uma quantidade suficiente de olhos, todos os bugs são superficiais”

Eric chamou essa afirmação de “Lei de Linus”, que também pode ser explicada como “dada uma quantidade suficiente de beta-testers e co-desenvolvedores, quase todo problema será encontrado rapidamente e a correção será óbvia para alguém.”

A Wikipedia se valeu dessa mesma Lei: num sistema dinâmico, aberto, onde os colaboradores começam a participar lentamente, evoluindo para uma rede scale-free auto-organizada, erros vão acontecer, mas a maioria deles será rapidamente corrigida. O benefício de se conseguir informações de milhares de pessoas espalhadas pelo mundo é ordens de grandeza superior aos pequenos defeitos que aparecem de vez em quando.

Num modelo de controle tradicional, costuma se pensar como na Britannica: poucos verbetes mas todos muito corretos. Qual vale mais: 80 mil verbetes com taxa de erro perto de zero, ou quase 1 milhão de verbetes com uma pequena taxa de erros? Alguns críticos retrógrados continuam achando que 1 pequeno erro na Wikipedia invalida 1 milhão de grandes acertos.

Software como Arte

Pete McBreen já escreveu em 2001 sobre Software Craftsmanship e eu sou um defensor dessa definição.

Muita gente pensa em Software, programação como Engenharia. Sinto informá-los de que não é. Software é música. Desenvolvimento de Software é muito próximo de se compor uma música.

Software é pintura. Desenvolver Software é como pintar um quadro. Sem querer diminuir a área da engenharia, que já nos trouxe maravilhas incríveis pelo mundo todo como a Muralha da China, as pirâmides do Egito, mas no caso específico de software é muito mais simples pensar nela como Engenharia do que como Arte.

Novamente, o mesmo motivo: tentativa de controle, afinal engenharia é previsível, é controlável, é mensurável. Arte é criativa, rebelde, imprevisível, caótica. Acho muito interessante que muitos dos grandes nomes do passado como Pitágoras, Da Vinci, foram grandes generalistas, artistas mas com muitos trabalhos nos campos da ciência e matemática. É exatamente isso que um desenvolvedor de software precisa ser: um artista da Renascença.

Como eu disse antes, um membro de uma Feature Team tem algumas especialidades, mas tem a mente absolutamente aberta a tentar novas coisas, a aprender novos ofícios, a explorar e criar.

Arte não pode ser implementada apenas lendo procedimentos. E é exatamente isso que muitos dos que se entitulam “desenvolvedores” ou “programadores” fazem: aprendem uma (ou poucas) maneira de fazer as coisas e continuam fazendo conforme lhe foi ensinado. Artistas aprendem a partir de mentores, treinam incansavelmente num longo processo de tentativa e erro, inspiram-se nos trabalhos de outros mestres, entendendo suas técnicas e tentando mesclá-las às suas próprias.

Apesar de não ser uma verdade absoluta, eu tendo a achar que desenvolvedores de software que participam ativamente de projetos Open Source, como um Linux, são programadores muito mais completos do que programadores que saíram da faculdade e passaram a integrar “Component Teams” dentro de organizações tradicionais. Especialmente se ficaram anos demais na mesma organização.

Um programador especialista, membro de um Component Team, numa organização gaussiana tradicional, é exatamente como um pintor de parede: sabe apenas passar o rolo de cal de cima para baixo, simetricamente, sem um pingo de criatividade e sem absolutamente nenhum talento ao aprendizado e à auto-evolução.

80% do perfil profissional de um funcionário é reflexo direto da organização onde trabalha – os outros 20% são culpa do próprio funcionário que não aceita sair da zona de conforto. Ambos tem 100% da culpa por apenas 29% dos projetos de software serem considerados sucessos. Ambos tem 100% da culpa pelo custo de USD 55 bilhões gastos em projetos de software cancelados. (fonte: Standish Chaos Reports)

Mundo Open Source

Acredito que não seja necessário explicar muito mais sobre projetos open source. Não há milagres: não significa que simplesmente porque um projeto é de código-aberto que ele automaticamente terá tanto sucesso quanto o Linux. Muito pelo contrário: centenas de projetos nunca chegam a ver a luz do dia.

Novamente, estamos falando de Pareto, talvez apenas 20% dos projetos open source realmente tenham grande sucesso. Porém, os outros 80% são identificados como fracasso muito mais rapidamente, alguns se mesclam em projetos maiores, alguns simplesmente páram. A decisão de parada é muito mais rápida e efetiva do que em projetos tradicionais corporativos que já investiram recursos (tempo e dinheiro, além da reputação de alguns dos envolvidos).

Com tudo que expliquei acima, fica fácil entender que projetos Open Source começam com condições iniciais simples: uma idéia, uma pequena implementação, poucas pessoas. Também começa a fazer sentido entender como elas evoluem do caos para redes scale-free através de auto-organização.

Não é difícil entender que esses projetos não tem como ser implementados através de consenso prévio muito rígido, só poderia evoluir para Feature Teams onde os colaboradores normalmente tem habilidades diferentes e complementares.

Também não é difícil entender que, como na Wikipedia, os verbetes mais importantes e/ou mais conhecidos são preenchidos primeiros, depois os mais obscuros são preenchidos com o tempo. No melhor estilo Pareto, 20% das prioridades acontecem primeiro. Num ambiente onde os recursos costumam ser escassos (não existe presença física, os colaboradores são voluntários, motivas as pessoas é ainda mais importante), realmente as prioridades – que dão mais valor ao grupo como um todo – são implementadas primeiro.

Em se entendendo Software como Arte, também fica simples entender que desenvolvedores que participam de vários projetos open source estão automaticamente expostos a muitas diferentes expressões de arte e, como tal, a diferentes maneiras de se implementar software. Um bom desenvolvedor começará a incorporar essas diferenças em seu próprio estilo, automaticamente melhorando muito a qualidade do seu trabalho.

Um desenvolvedor, sozinho, ou numa equipe conhecida, tem muito pouco motivo para criar testes do seu próprio código. Mas quando se vê numa situação onde está colaborando numa comunidade onde qualquer desconhecido poderá ver seu código e, portanto, aferir sua reputação, a motivação para criar código de boa qualidade, decentemente coberta com testes, fica mais óbvio. Daí porque eu disse antes que Test-Driven Development começa a fazer não só mais sentido como se torna uma real necessidade.

O idealizador do projeto, o desenvolvedor ou grupo de programadores que iniciou o projeto, necessariamente serão obrigados a gerenciá-lo. E num ambiente aberto, onde as pessoas não tem cargos, não tem salários, não tem chefes nem clientes diretos, vai por baixo qualquer tentativa de se usar técnicas gaussianas de gerenciamento tradicional de projetos. Agora estamos falando de projetos de verdade, sem a zona de conforto do cubículo. O mantenedor do projeto se verá numa posição onde será obrigado a tomar decisões. Entenderá rapidamente que é impossível obter unanimidade em todos impasses e por isso vestirá o chapéu de ditador benevolente, ou seja, um ditador que se for rígido e autoritário demais irá afastar todos os seus colaboradores (que não tem obrigação nenhuma de seguí-lo) e que se for flexível demais se arriscará a demonstrar insegurança, indecisão, morosidade e por fim poderá motivar um coup um tipo de “golpe de estado”, onde seu projeto será clonado e outro mantenedor mais carismático e efetivo poderá tomar seu lugar. Ou pior: seu projeto pode simplesmente parar e deixar de existir.

Não existe ambiente mais hostil mas ao mesmo tempo mais recompensador para um verdadeiro gerente de projetos do que projetos open source. Tire de um Gerente o seu cargo e seu poder e só então poderá avaliar se ele realmente sabe o que significa “gerenciar”.

Princípios Ágeis, Redux

Tudo isso dito, acho que podemos recapitular o 6_o, 11_o e 12_o princípios novamente:

Construímos projetos através de indivíduos motivados. Dê-lhes o ambiente e suporte que precisam, e confie neles para ter o trabalho executado.

As melhores arquiteturas, requerimentos, e designs emergem de equipes auto-organizadas.

Em intervalos regulares, as equipes refletem sobre como se tornar mais efetivos, então ajustam seu comportamento de acordo.

Os outros princípios são consequência:

Dado um ambiente adequado, com profissionais efetivamente elevados acima da média, motivados podemos realmente confiar em suas capacidades de auto-organização, onde a própria estrutura orgânica e não hierarquizada naturalmente levará seus membros a reajustarem sua rotina de acordo com os problemas enfrentados, levando-os a gerar código de qualidade, onde apenas o essencial está realmente sendo produzido, com alta qualidade, atenção à refatoração, testes, integração contínua, o que leva também naturalmente às melhores arquiteturas, e o sistema como um todo se retro-alimenta num ciclo contínuo de feedback positivo, criando um ambiente sustentável, sempre produtivo, com profissionais pesquisando e implementando inovações tecnológicas que de tempos em tempos dão saltos de qualidade e produtividade para a empresa como um todo.

Como resultado, o cliente estará recebendo produtos que lhe agregam real valor, mudanças de requerimentos podem efetivamente ser aceitos sem maiores problemas, uma vez que a organização é flexível e cada membro se sente responsável pelo todo. Além disso nesse tipo de ciclo virtuoso, os profissionais estão em constante aprendizado, aumentando suas habilidades em ritmo crescente indeterminado, gerando uma empresa inovadora, acima da média, que não se baseia no passado para tentar, futilmente, prever o futuro: eles não precisam mais pois os profissionais finalmente estão preparados para seja lá qual for o futuro que chegar. Em vez de tentar prever o futuro, as pessoas estarão capacitadas para qualquer futuro, e isso é fundamental: mudanças constantes não os assusta mais, pelo contrário, eles querem mudanças.

Como chegar Lá?

Não foi à toa que eu falei sobre:

Os dois artigos primeiros focam na figura do profissional: uma tentativa de acordar os funcionários-batedores-de-cartão de que o mundo não é estático, o futuro não é estável e o mundo gaussiano é uma ilusão.

Os dois últimos artigos falam especificamente de uma ferramenta: Git. É uma dica para criar o ambiente que suporte o que o desenvolvedor precisa, como está no Quinto Princípio. Mas ferramenta, assim como metodologia, não serve para nada se tanto empresa quanto funcionário não incorporarem os Valores e Princípios Ágeis.

Daí este artigo.

Como eu disse no começo, não me considero nenhum grande estudioso dessa filosofia, mas por alguma razão me identifico com suas bases e observo claramente sua aplicação na prática em projetos Open Source. Também está claro que no mundo de Pareto esse modelo não só sobreviveu como deu frutos impressionantes, como a Wikipedia, como o fato de mais de 60% dos servidores web do mundo serem Apache e assim por diante.

Você é uma empresa onde software faz parte do seu core business? Aplique o modelo “Open Source”, ou o modelo “Bazaar”, segundo Eric Raymond. Não necessariamente abra seu código para o público em geral na internet, claro.

Crie um repositório simples, que todos os funcionários tenham acesso irrestrito, onde a barreira de adoção seja baixa. Incentive-os a participar de projetos fora de seus departamentos tradicionais. No começo, código mal feito, de baixa qualidade, sem testes, e toda qualidade de defeitos será revelada. Mas o objetivo não é apontar o dedo e sim parar o ciclo vicioso que gera esse tipo de software.

“Programador ruim fará código ruim, não importa que linguagem, ferramenta você dê a ele.” Portanto, o objetivo é criar Programadores excelentes, não mudar de ferramenta. De forma impressionante, um programador bom fará código bom até mesmo em ASP ou Perl (novamente, sem querer denegrir o Perl, mas apenas falando pela reputação – criada principalmente pelos programadores ruins).

Assim como numa escultura, é hora de aparar as pontas, refazer alguns pedaços, remoldar o que não parece certo e levar essa peça a se tornar realmente uma obra de arte, de forma colaborativa. É a melhor maneira de se evitar desperdícios, uma vez que pessoas com um pouco mais de tempo sobrando numa equipe, podem ajudar seus colegas que estão mais atarefados na outra.

No começo haverá desordem e sinais de caos. Haverá duplicação de trabalho. Acontecerá dessincronia, problemas de comunicação (afinal, ninguém estava habituado a realmente se comunicar). As deficiências de habilidade e conhecimento ficarão óbvias. Todos os problemas existentes virão à tona e isso será feio, desconfortável.

Porém, se houver apenas um pouco de insistência e confiança nas pessoas, verá que o grupo como um todo sairá do caos. Os verdadeiros líderes vão emergir como hubs na rede scale-free. O fenômeno de preferential attachment começará a delinear a ordem. Com tempo suficiente, as pessoas se auto-organizarão de forma orgânica.

A partir daí sim, realmente poderemos começar a falar em crescimento sustentável com ritmo constante ou crescente de produtividade.

Um dia de Inovação

No Google existe aquela velha história de que todos os seus funcionários tem direito a um dia por semana para fazer o que bem entender.

Dito apenas dessa forma a primeira coisa que me vem à cabeça é um monte de garotos passeando de bicicleta, jogando videogame, tomando uma caipirinha à beira da piscina do campus.

Porém, assumindo que você leu todo meu artigo, imagine o Orkut Büyükkökten num desses dias. Ele tem o ambiente correto, tem a cultura correta, tem a motivação correta, tem o conhecimento correto. Ele resolve iniciar um certo projeto pessoal para experimentar com conceitos de redes sociais.

Ele tem um local onde colocar seu código. Também entende que deve se desapegar dele. Entende naturalmente como funciona a colaboração no estilo “open source”. Por causa disso sabe como se comunicar.

Ele divulga seu projeto internamento. Os membros de sua equipe ou de outras, também todos sintonizados na cultura correta de pró-atividade, inovação, aceitação de mudanças e colaboração, imediatamente entendem o valor da idéia. Mais do que isso: sabem de onde baixar o código e como começar a colaborar.

Eu não sei realmente como funciona o Google, nunca trabalhei lá e provavelmente ela deve ter tantos problemas quanto qualquer empresa normal. Mesmo assim eu fantasio que muitos produtos deles começaram dessa forma: num ambiente permissivo, voltado à inovação. Não basta apenas apenas contratar phds. do MIT ou de Stanford se não houver ambiente e cultura adequadas para realmente fazê-los produzir de verdade. Como Larry e Sergey tiveram um começo nesse mundo permissivo de open source eu fico imaginando se eles não criaram uma organização que segue exatamente esse modelo, mesmo que tenha sido de forma instintiva.

Muitas empresas querem ser o próximo Google. Porém, quero lembrá-los que é preciso muito mais do que sofás confortáveis, mesas de pebolim, salas de videogame e restaurantes de comida japonesa dentro da empresa para se tornar um Google. Isso é fácil: basta comprar.

O difícil é cultivar uma cultura. Muitas empresas reclamam que profissionais de boa qualidade pedem demissão e procuram outras empresas. Óbvio: pessoas realmente inteligentes não aceitam uma cultura gaussiana por muito tempo. Nós não gostamos da mesmice, não gostamos de pensamento retrógrado e falta de atitude. Verdadeiros artistas precisam de ambientes de inspiração para serem criativos.

O cubículo da maioria das empresas é um péssimo lugar para se criar.

Bibliografia

Finalmente, uma vez entendida a filosofia, podemos voltar à metodologia. Agora faz sentido aplicar as ferramentas que metodologias como XP ou Scrum advogam: Pair Programming, Planning Game, Test Driven Development, Continuous Integration, Refactoring, Small Releases, Collective Code Ownership, Simple Design, Sustainable Pace, etc.

Leiam com outros olhos minhas recomendações de leitura:

Larman, Craig & Vodde, Bas – Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
Fowler, Chad – My Job Went to India: 52 Ways to Save Your Job
Christensen, Clayton M. – The Innovator’s Dilemma: The Revolutionary Book that Will Change the Way You Do Business
Beck, Kent – Extreme Programming Explained: Embrace Change
Poppendieck, Mary – Lean Software Development: An Agile Toolkit
Brooks, Frederick P. – The Mythical Man-Month: Essays on Software Engineering
McBreen, Pete – Software Craftsmanship: The New Imperative
Raymond, Eric S. – The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary
Don, Taps & Williams, Anthony D. – Wikinomics: How Mass Collaboration Changes Everything
Anderson, Chris – Long Tail, The, Revised and Updated Edition: Why the Future of Business is Selling Less of More
Gladwell, Malcolm – The Tipping Point: How Little Things Can Make a Big Difference
Gladwell, Malcolm – Blink: The Power of Thinking Without Thinking
Taleb, Nassim Nicholas – Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets
Taleb, Nassim Nicholas – The Black Swan: The Impact of the Highly Improbable
Mandelbrot, Benoit – The Misbehavior of Markets: A Fractal View of Risk, Ruin & Reward
Sagan, Carl – The Demon-Haunted World: Science as a Candle in the Dark
Sagan, Carl – Pale Blue Dot: A Vision of the Human Future in Space
Dawkins, Richard – The Selfish Gene

Dica: A maioria desses livros tem traduções em português.

Sei que alguns desses livros não tem a ver diretamente com este assunto (como os de Carl Sagan), mas acredite: faz muita diferença para a maneira como formamos nossas idéias.