AkitaOnRails.com

Rails Shops in Brazil

Tue, 23 Jun 2009 11:30:58 PDT

Uma coisa que eu vi nos vários eventos em várias cidades do Brasil, foi que mais e mais pequenas empresas ou mesmo departamentos governamentais estão avançando em Ruby on Rails. Até nos lugares mais inusitados. Muitos me perguntam para recomendar empresas que desenvolvem em Rails. Aqui fica a questão, você trabalha ou tem uma empresa que desenvolve Rails, dá cursos de Rails, ou tem equipes trabalhando full-time em Rails?

Deixe seu comentários neste post, com nome da empresa, contato, descrição do que fazem, website, etc para que todos possam saber. De qualquer parte do Brasil.

[37signals] Quem quer viver no Mundo Real?

Thu, 18 Jun 2009 08:07:49 PDT

Tradução: Who wants to live in The Real World?

O Mundo Real deve ser um lugar verdadeiramente deprimente de se viver. Aparentemente um lugar onde novas idéias, maneiras não-familiares, e conceitos estrangeiros sempre perdem. Me dizem que a única coisa que funciona no Mundo Real é que seus habitantes já sabem e já fazem. Não importa quão ruim ou ineficiente isso possa ser.

Define-se pessoas que vivem lá como vivendo uma Vida Real. Uma existência preenchida com pessimismo, desespero e todo gradiente de preto imaginável. E de forma estranha, essas pessoas vivendo Vidas Reais não parecem interessadas em sair. Eles não estão procurando por uma mudança no cenário do duro Mundo Real.

Em vez disso, eles na realidade estão recrutando! Em argumentos em todos os lugares, eles estão tentando convencer aqueles com comportamento mais ensolarado que eles devem se converter para o Mundo Real ou sofrer. Que resistir ao Mundo Real é fútil. Essa chamada persiste mesmo em face a experiências contrárias. Contos de pessoas que realmente fizeram as coisas de forma diferente e ainda vivem para ver o nascer do sol de manhã.

Por favor, não seja idiota, não existe nada nem remotamente atraente sobre o Mundo Real. É uma miragem miserável que serve somente como um lugar de comunhão para aqueles que perderam toda a esperança.

Relacionado: Defina o Mundo Real em 10 palavras ou menos

[Off-Topic] O Dilema do Blogueiro

Tue, 16 Jun 2009 15:44:06 PDT

Existe um pensamento que me cruza a cabeça de vez em quando. Como blogueiro eu tenho relacionamentos com muitas pessoas da blogosfera em geral, tanto do Brasil quanto fora, muitas pessoas que sempre encontro em conferências, tudo muito gratificante pois eu sempre aprendo mais. Além disso já trabalhei em muitos lugares então sempre existem contatos antigos e antigas experiências.

Por outro lado tenho um dilema, especialmente quando envolve assuntos sobre críticas porque muitas pessoas lêem e assumem a carapuça de formas interessantes que, obviamente, eu não posso controlar. Contexto é tudo.

Exemplo clássico, os artigos As 5 Disfunções em Equipe de Código, Conselho para Gerentes de Desenvolvimento de Software, ou Net Negative Producing Programmer. Razões para escrever eu nunca tenho uma única específica, a inspiração aparece, eu escrevo. Nos últimos meses tenho estudado muito material a respeito, diversos livros, dezenas de artigos, porque eu sempre gosto de entender o que faço mais a fundo e porque eu entendo que nunca vou saber tudo. (O que significa que tem mais artigos meus nessa linha ainda para vir :-) Em particular dois desses artigos foram inspirados numa conversa que tive durante conferências recentes com um bom amigo meu.

No meio disso, sempre vão surgir histórias, coisas que eu ou amigos meus já passaram e que eu descrevo. Mas não especifico um caso em particular, uma pessoa em particular, eu tento entender um comportamento geral e descrevo como tal. É como observar fenômenos naturais, tento descrever as consequências (como as 5 disfunções, NNPP) e tento entender quais as possíveis causas, às vezes até de forma propositadamente ingênua.

Às vezes os motivos são diretamente pessoais mesmo. Vejam artigos como Um Desabafo e Um Desabafo, parte II que escrevi no começo de 2007. Vale a pena ler porque num blog só os artigos recentes ficam em destaque, mas se verem o que escrevo desde 2006, observarão que de tempos em tempos eu escrevo artigos com temas provocativos de forma parecida.

O “problema”: até amigos próximos meus já ficaram um pouco mordidos com artigos como esses. Já recebi alguns hate-mails, algumas indiretas online e offline, essas coisas simpáticas :-) Sinceramente não me preocupo nem um pouco com isso, eu sempre vou pecar por mais do que por menos e a lógica é óbvia: se eu achasse que o que escrevo está errado eu não escreveria. Quando eu erro, me desculpo. Mas a popularidade do blog às vezes dá mais peso ao que eu falo do que acho que deveria.

Pelo menos para meus amigos e quem eu normalmente costumo conversar pelo menos via IM, fiquem sossegados, se eu estiver com problemas com você em particular, vou conversar diretamente, em particular. Da mesma forma a recíproca é verdadeira, eu prefiro que se você tem problemas comigo, que venha falar diretamente também. É sempre o caminho mais curto e o de entendimento mais rápido.

Mas, como eu disse, contexto é tudo. É como horóscopo, você lê e realmente se identifica “nossa, sou exatamente eu.” Isso são estereótipos, e poucas pessoas são tão monofacetadas assim e nem deveriam se considerar como tal. Um efeito que existe em textos gerais é o seguinte: não é difícil encontrar paralelos de qualquer coisa com qualquer coisa. Exatamente como eu apresentei em Somos Matematicamente Ignorantes, coincidências são muito comuns, muito mais do que achamos que deveria.

Meus artigos não tem o objetivo de estabelecer verdades absolutas, são pensamentos, opiniões, desenvolvimentos que eu apresento e que gostaria de receber feedback para poder observar outros argumentos (argumentos, não trollismos) e possivelmente aumentar minha visão sobre o assunto.

Não sei se outros blogueiros tem o mesmo “problema”. E eu digo entre aspas porque discordar do meu ponto de vista não é um problema. É para isso que existem os comentários: coloquem seu ponto de vista, especialmente se for contrária e se tiver bons argumentos, isso vai enriquecer o tema. Eu achava que isso deveria ser óbvio, mas pelo jeito não é então aqui vai a explicação.

Finalmente, reafirmo que não pretendo mudar em nada a forma como escrevo. Foi tudo isso apenas para dizer que nada muda :-)

[Tradução] Ruby na ThoughtWorks

Sun, 14 Jun 2009 22:50:21 PDT

Esta é a tradução em português do artigo original de Martin Fowler no seu Bliki. Você pode ler a versão original aqui

A ThoughtWorks começou a usar Ruby para projetos em produção em 2006, de lá até o fim de 2008 tínhamos 41 projetos em ruby. Preparando para uma palestra na QCon eu pesquisei esses projetos para examinar que lições poderíamos tirar dessa experiência. Eu descrevo nossos pensamentos até agora sobre questões comuns da produtividade, velocidade e mantenabilidade de Ruby. Até agora nossas conclusões são que Ruby é uma plataforma viável e que deve ser considerada seriamente para muitas formas de aplicações – em particular aplicações Web usando Ruby on Rails. Eu também avanço por sobre algumas lições técnicas, incluindo alguns pensamentos sobre testar Active Record.

A ThoughtWorks, minha contratante, é primariamente uma empresa de entrega de software. Nós construímos softwares para pessoas, incluindo produtos construídos para nós mesmos. Uma parte importante de nossa filosofia é abertura para usar diferentes plataformas de desenvolvimento, de forma que podemos escolher a plataforma apropriada para nossos diferentes clientes. Quando me juntei à ThoughtWorks em 2000, Java era nossa plataforma mais usada. Logo depois começamos a trabalhar com .NET e essas duas plataformas dominaram nosso trabalho pelo meio da década.

Algumas pessoas, entretanto, começaram com linguagens de script LAMP, em particular Ruby. A aparição do framework web Ruby on Rails deu um grande empurrão ao Ruby, o suficiente para que em 2006, começássemos a fazer alguns projetos sérios com a essa plataforma. Enquanto escrevo isto em 2009, a plataforma Ruby tem uma grande parcela de nosso trabalho, não tanto quanto Java e C#, mas uma porção significante.

Durante esses três anos aprendemos muito sobre Ruby na prática. Quando 2009 começou, eu fui convidado para falar sobre nossas experiências com Ruby para a conferência QCon. Me preparando para isso eu conduzi uma extensiva pesquisa de nossos projetos Ruby e questionei nosso líderes Ruby por seus pensamentos e experiências. Levou mais tempo do que gostaria para produzir este artigo também, mas aqui está ele.

Dividi este artigo em 3 partes. Para começar olharei para o perfil de experiência de nossos projetos Ruby, para dar uma sensação de quais tipos de projetos estivemos tocando nesses últimos anos. Em seguida vou para várias questões comuns sobre Ruby e como nossas experiências respondem a elas. Finalmente vou para algumas lições que aprendemos por usar Ruby.

A Forma de Nossos Projetos

De 2006 a 2008, a ThoughtWorks se envolveu em cerca de 41 projetos de Ruby. Eu defino um projeto de Ruby como um projeto onde Ruby foi a principal linguagem de desenvolvimento. Ruby apareceu em outros projetos também, existem muitos desenvolvimentos recentes usando ruby para automações ou testes funcionais para projetos de Java. Quase todos esses projetos envolveram Rails, e a maioria são projetos de web sites onde Rails é pelo menos tão importante quanto Ruby.

Figura 1: Gráfico de Dispersão de picos de contagem de pessoas vs. tamanho envolvido por projetos Ruby da ThoughtWorks de 2006 a 2008.

A Figura 1 dá uma sensação do tamanho dos projetos que estivemos envolvidos. A contagem de pessoas é o pico de todos os envolvidos (ThoughtWorks, clientes e outros; desenvolvedores, gerentes de projetos, analistas, etc.) O tamanho é a duração que estivemos envolvidos no projeto.

Projetos Ruby são geralmente vistos como mais curtos e menores do que outros projetos. Infelizmente não tenho dados comparativos com outros de nossos projetos em outras plataformas para ter uma sensação melhor se isso é verdade ou não. Certamente podemos ver que a maioria desses projetos envolve menos de 20 pessoas por menos de um ano.

Existem alguns projetos fora da curva. De longe nosso maior projeto é o que vou me referir como projeto Atlanta, com uma contagem de pessoas acima de 40. Outro grande e ainda corrente é o Jersey. Esses dois estão relacionados no sentido que houve muita rotação de pessoas entre eles, algumas de nossas mais experientes pessoas de Ruby estiveram em ambos.

O terceiro projeto é o Mingle, que é um caso particularmente interessante já que é um produto da ThoughtWorks Studios – e como tal podemos ser mais públicos sobre ele do que outros que fizemos para clientes. É um projeto longo e corrente e também internacional: começando na Austrália, movendo para Beijing e agora multi-site entre Beijing e São Francisco.

Figura 2: Gráfico de Tiras mostrando esforço por projeto a cada ano.

A Figura 2 olha para a forma do gráfico de maneira diferente, olhando para o esforço em vários projetos que estivemos envolvidos a cada ano. Cada ponto no gráfico representa o esforço total (todas as pessoas) em um projeto durante esse ano. Esse gráfico fornece uma boa sensação de quanto crescimento vemos em projetos Ruby durante os últimos três anos.

Figura 3: Gráfico de Tiras mostrando esforço de projetos por país.

A Figura 3 mostra projetos por país onde foram feitos. Não é muito exato já que não tentei lidar com alguns projetos multi-site que se moveram (Mingle, por exemplo, eu classifiquei como China embora sua história tenha variado.)

A divisão por país mostra que os Estados Unidos viram o maior interesse por trabalhos em Ruby. A Índia também viu uma boa quantidade – de fato nosso primeiro projeto de Ruby foi em Bangalore. A Inglaterra foi onde teve a menor quantidade. Isso provavelmente reflete o fato que nossos evangelistas de Ruby era na maioria baseados nos Estados Unidos e existiu ceticismo considerável sobre Ruby na Inglaterra. O nível de envolvimento da Índia é encorajador, tradicionalmente a Índia é vista como sendo atrasada no uso de novas tecnologias mas estamos conseguindo fazer um trabalho razoável de tornar nossos escritórios na Índia bem diferentes.

Nossa experiência vendendo trabalho de Ruby é que usar linguagens dinâmicas como Ruby se encaixa bem com nossa imagem geral. Nossa força é que contratamos pessoas talentosas que são difíceis de serem atraídos por organizações típicas de TI. Ruby tem filosofia de um ambiente que dá a um desenvolvedor talentoso mais vantagem, do que tentar proteger os desenvolvedores menos talentosos dos seus erros. Um ambiente como Ruby, portanto, dá aos nossos desenvolvedores mais habilidade para produzir seu verdadeiro valor.

Ruby também se encaixa com nossa preferência por processos ágeis de desenvolvimento de software. A filosofia ágil é sobre feedback rápido construindo software e revisando regularmente com o cliente. Quanto mais produtivo for um ambiente de desenvolvimento, mais freqüentemente podemos revisar o progresso e melhor o processo ágil de “inspecionar e adaptar” funciona.

Questões Sobre Ruby

Ruby foi a escolha correta?

Olhando para trás em nossos 41 projetos, talvez a questão mais importante para perguntar é se a plataforma Ruby foi a escolha correta. Uma forma de responder é perguntar aos líderes técnicos do projeto se, em retrospectiva, eles acham que foi a escolha correta.

Figura 4: Ruby foi a escolha correta de plataforma para esse projeto?

Como a Figura 4 indica, o voto foi muito positivo com 36 contra 5 suportando a escolha. Como um grupo, nossos líderes técnicos normalmente não são tímidos em indicar se estão insatisfeitos com a escolha tecnológica. Então eu vejo isso como uma afirmação firme da viabilidade da plataforma Ruby como uma escolha razoável.

Eu me aprofundei mais nos cincos projetos arrependidos. A primeira coisa que se sobressaiu foi que em quatro dos cinco casos, os líderes sentiram que usar Ruby não foi uma escolha mais ruim do que as alternativas. Por Ruby não ser uma coisa comum significa que sentimos que usar Ruby tem que vir com mais benefícios que as alternativas. Quatro dos cinco também relataram problemas por causa de integração com tecnologias .NET, por exemplo. Outro tema que dois dos projetos relataram foram problemas sociais – as pessoas na organização dos clientes se opuseram a Ruby ou outras linguagens dinâmicas. O projeto na pior situação mostrou esse problema social – uma organização de TI que resistiu com unhas e dentes ao Ruby (o patrocinador de negócios nesse caso foi um fã de Ruby.)

De fato quanto mais eu perguntava sobre as bandeiras vermelhas por usar Ruby em um projeto de software, a única resposta clara foi a respeito de problemas sociais. Ruby era de forma geral aceita ou encorajada por nosso trabalho de desenvolvimento de software, mas o maior sinal para evitá-la seria uma resistência social da parte do cliente.

Ruby é mais produtivo?

Quando as pessoas perguntam porque Ruby deveria ser usado em um projeto, a resposta mais comum é que ele aumenta a produtividade. Um indicador inicial foi a afirmação de um projeto que sugeria que Ruby deu uma melhoria de uma ordem de magnitude na produtividade.

Como um resultado parecia óbvio perguntar aos líderes técnicos dos projetos sobre a produtividade – o ruby aumentou a produtividade e se sim, por quanto. Eu pedi que comparassem com projetos feitos em Java ou .NET da maneira mais produtiva que eles sabiam como.

Figura 5: Quanto Ruby melhorou a produtividade para este projeto? (Comparado com a melhor ferramenta mainstream que você conhece.)

Não leve esses resultados ao pé da letra. Afinal não existe maneira objetiva de medir produtividade de software. Esses são resultados subjetivos e qualitativos dos líderes técnicos de cada projeto (eu não consegui respostas para todos os projetos.) Entretanto eles ainda sugerem que existiu uma real melhoria de produtividade acontecendo.

A sugestão é mais reforçada considerando os envolvidos. Scott Conley, que gerencia nosso escritório de Atlanta, relata que uma vez que um projeto Ruby começa a andar, ele espera precisar de 50% mais pessoas focadas em preparação de requerimentos do que o esperado em outras tecnologias.

Uma coisa que vimos é que você não deve esperar melhorias de produtividade aparecer imediatamente. Eu ouvi diversas vezes que as pessoas ficavam alarmadas nas semanas iniciais sobre o progresso devagar de novas equipes de projetos Ruby – uma conseqüência do que chamamos de Ravina de Melhoria. Realmente leva tempo para uma equipe Ruby se inteirar sobre como a plataforma funciona e durante esse tempo eles serão mais devagar do que o esperado.

A ravina de melhoria é um fenômeno comum e um paliativo comum é garantir que existem algumas pessoas experientes na equipe. Nossa história, entretanto, é que a experiência mais importante aqui é com linguagens dinâmicas que suportam os tipos de meta-programação que o Ruby suporta, mais do que especificamente experiência com Ruby. Como o Scott Conley coloca: a diferença é entre risco de eficiência e risco de entrega. Uma equipe com experiência em linguagens dinâmicas mas pouca experiência com Ruby será mais devagar inicialmente (risco de eficiência) mas uma equipe sem qualquer experiência com linguagens dinâmicas podem produzir código ruim que poderia arriscar a entrega no geral.

Ruby é lento?

Em uma palavra, “sim”. Procure por aí por benchmarks na internet e verá numerosas pesquisas que mostram que, mesmo pelos padrões de linguagens de script, Ruby é uma tartaruga.

No geral, entretanto, isso tem sido irrelevante para nós. A maioria do nosso uso de Ruby é construindo websites ligados a bancos de dados. Eu visitei muitos projetos durante muitos anos, usando ruby e outras tecnologias, quase todo projeto gasta tempo trabalhando em problemas de performance e em quase todos os casos esses problemas eram no acesso a banco de dados. As pessoas gastam tempo tunando SQL e não tunando o código de processamento. Então, já que quase toda aplicação é limitada por I/O, o uso de linguagens mais lentas para processamento não trás um impacto tão importante à performance geral do sistema.

Vocês vão notar que eu usei o comum palavreado absoluto no parágrafo anterior. Embora quase todo projeto seja limitado por I/O, você ainda cai em exceções ocasionais – e um interessante é o Mingle. O Mingle é incomum em muitas maneiras. Sua forma de mostrar telas de forma dinâmica significa que ele não pode usar nenhum tipo de caching de página para melhorar performance, o que imediatamente a torna diferente da maioria das aplicações web. Como resultado ele não é limitado por I/O e para melhor performance precisa de mais hardware do que a maioria das pessoas espera (um box de quatro cores com 2Gb de memória para suportar equipes de 20-40 pessoas.)

Mas a equipe do Mingle ainda sente que fizeram a escolha correta com Ruby. Eles construíram muitas funcionalidades rapidamente e sentem que o ganho de produtividade que tiveram com o Ruby vale o custo de mais demanda de hardware no produto final. Como com muitas coisas, esta é uma troca de hardware vs. produtividade – uma das mais velhas trocas na computação. Cada equipe precisa pensar sobre qual importa mais. A boa notícia aqui é que o Mingle tem ótima escalabilidade horizontal (jogue mais processadores nele e terá proporcionalmente melhor performance). Escalabilidade de hardware é normalmente a coisa mais valiosa que você pode ter nessas situações enquanto o custo de hardware decresce.

Eu devo re-enfatizar. Para a maioria dos projetos a velocidade do Ruby tem sido irrelevante já que quase todos eles são limitados por I/O. Mingle é uma exceção, não o caso comum.

Um código de Ruby é difícil de entender?

Uma preocupação que freqüentemente ouvimos sobre Ruby é que sua tipagem dinâmica, suporte a meta-programação e a falta de ferramentas coloquem um risco de deixar um código difícil de seguir. Em geral isso não tem se tornado um problema na prática para nós. A história que eu ouço é que o fato de poder escrever muito menos código para a mesma funcionalidade significa que é mais fácil manter o código limpo do que é para a maioria das linguagens mais populares.

Isso dito, é importante lembrar do nosso contexto. Os desenvolvedores da ThoughtWorks tendem a ser muito acima da média em termos de habilidade e também altamente disciplinados em técnicas como Extreme Programming. Colocamos alto valor em testes (algo que é verdade na comunidade Ruby em geral) e esses testes ajudam muito a manter o código limpo. Então não posso dizer se nossa experiência é comparável a outros desenvolvedores menos disciplinados. (Mesmo as ferramentas e relativo controle de outras linguagens não nos impedem de ver código bem horrível, então é uma questão em aberto se um código ruim de Ruby seria tão mais ruim.)

Temos visto uma seqüência comum de atitudes sobre meta-programação.

Figura 6: Progressão de sentimentos sobre meta-programação.

Assustador e Ruim: as pessoas são prudentes quanto a meta-programação e não a usam muito.
Assustador e Bom: as pessoas começam a ver valor na meta-programação mas ainda não se sentem confortáveis usando.
Fácil e Bom: as pessoas ficam confortáveis e começam a usar demais, o que pode complicar o código.
Fácil e Ruim: as pessoas são prudentes com meta-programação e entendem que é muito útil em pequenas doses.

No fim, a analogia que gosto mais para esse tipo de técnica é que eles são como receitas de remédios. Muito valiosos em pequenas quantidades mas você precisa se certificar de não cair numa overdose.

Assim como muitas outras coisas, experiência é a maior ajuda aqui, podendo levá-lo por essa curva mais rápido. Em particular é importante esperar essa curva de adoção, particularmente a utilização excessiva. Quando se aprende alguma coisa nova é normal usar demais em algum estágio porque sem cruzar essa linha é difícil saber onde fica a linha. Também pode ser útil tentar construir um sandbox – uma área relativamente contida de código para as pessoas testarem meta-programação. Com um sandbox é mais fácil desfazer o uso excessivo depois.

Ruby é uma plataforma viável?

Todas essas questões se somam na pergunta chave para nós: Ruby (e Rails) é uma plataforma viável para nós e nossos clientes? A resposta até agora é um grande “sim”. Ele oferece ganhos palpáveis em produtividade, nos permitindo ser mais responsivos e produzir melhor software, mais rapidamente para nossos clientes. Isso não significa que é a escolha certa para todas as situações. Escolher uma plataforma de desenvolvimento nunca é uma escolha simples, particularmente porque normalmente é mais uma coisa social do que técnica. Mas a conclusão é que Ruby é uma escolha que vale a pena considerar, o suficiente para nós querermos manter essa ferramenta em nossa caixa de ferramentas.

Uma outra questão interessante aqui é o papel de outras linguagens menos comuns. Deveríamos usar Groovy, F#, Python, Smalltalk e outros? Eu não ficaria surpreso se muitas das mesmas trocas que vimos com Ruby forem também verdade para qualquer dessas linguagens. Espero ver algumas dessas em nossa caixa de ferramentas no futuro.

Também devo estressar que não é um caso de “e/ou” quando falamos em usar essas linguagens e outras mais populares como Java ou C#. Eu sempre defendi que equipes de desenvolvimento usando uma linguagem como Java/C# deveriam também usar linguagens de script para outras tarefas de suporte. Ruby é uma excelente escolha para isso, e estamos vendo essa combinação crescer em nossos projetos. Com o crescimento do suporte dessas linguagens na JVM e CLR, vemos mais oportunidades de misturar diferentes linguagens com diferentes pontos fortes – uma coisa que Neal Ford refere como Programação Poliglota.

Algumas Dicas de Desenvolvimento

Nessa última seção, vou passar por algumas lições que aprendemos usando Ruby.

Testando com Active Record

Logo no começo de nosso uso de Ruby, houve um debate de qual era a melhor organização de testes na presença da camada Active Record de banco de dados em Rails. O problema básico é que na maioria do tempo, a performance de aplicações enterprise é dominada por acesso a banco de dados. Descobrimos que usando Dublê de Testes podemos aumentar muito a velocidade dos testes. Ter testes rápidos é crucial para nosso processo de desenvolvimento que é intensivo em testes. Kent Beck recomenda uma construção básica de commit de menos de dez minutos. A maioria de nossos projetos conseguem isso hoje em dia, e usar um dublê de banco de dados é parte vital para conseguir isso.

O problema com Active Record é que ao combinar o acesso a código de banco de dados com lógica de negócios, é meio difícil criar um dublê de banco de dados. A reação da equipe do Mingle a isso foi aceitar que o Rails se liga ao banco de dados de forma apertada e portanto rodar todos os testes de commit contra um banco de dados real.

A visão contrária foi defendida de forma mais firme pelas equipes do Atlanta e Jersey. Ruby tem uma funcionalidade poderosa que permite redefinir métodos em tempo de execução. Você pode usar isso para pegar uma classe active record e redefinir os métodos de acesso a banco de dados como stubs. A equipe iniciou uma gem chamada unitrecord para ajudar nisso.

Nesses três anos, não vimos um vitorioso aceito nesse debate. A equipe do Mingle roda milhares de testes contra um banco de dados postgresql real em cerca de 8 minutos. (Eles paralelizam os testes para se beneficiarem de múltiplos cores.) As equipes de Atlanta e Jersey consideram valioso que seus testes de commit rodem em 2 minutos com stubs em vez de 8 minutos sem. A troca de simplicidade de acesso direto ao banco de dados vs. construções de commit mais rápidos com testes stubados.

Embora ambas as equipes estejam felizes no geral com suas posições nesse debate, o uso de stubbing levou a outro problema para as equipes de Atlanta/Jersey. À medida que elas se familiarizam com o método de stubbing, usam mais e mais – caindo no inevitável problema de usar demais, onde testes unitários fazem stub de todos os métodos menos o que está sendo testado. O problema aqui, como acontece normalmente no uso de dublês, são testes frágeis. À medida que você muda o comportamento da aplicação, também precisa mudar montes de dublês que estão imitando o comportamento antigo. Esse uso excessivo levou ambas as equipes a saírem de testes unitários stubados e a usar mais testes funcionais no estilo do Rails, com acesso direto ao banco.

Active Record Vaza

Uma situação comum que as pessoas relatam é tempo gasto mexendo com SQL. Active Record faz um bom trabalho de esconder muito do acesso ao banco de dados do programador, mas ele falha em esconder tudo – essencialmente, a abstração vaza. Como um resultado as pessoas gastam uma quantidade razoável de tempo trabalhando diretamente com SQL.

Esse vazamento é uma funcionalidade comum em frameworks de mapeamento objeto/relacional. Praticamente todas as vezes que converso com as pessoas em projetos, eles dizem que o framework de mapeamento O/R esconde SQL eficientemente cerca de 80-90% do tempo, mas você precisa gastar algum tempo trabalhando com SQL de forma a conseguir performance decente. Então sobre esse respeito o Active Record não é realmente diferente de outros mapeadores O/R.

De fato um comentário que ouço é que com Active Record, a abstração quebra de forma mais limpa. Quando conversei com o DHH, ele sempre estressou que acredita que desenvolvedores que usam um banco de dados relacional devem saber trabalhar com SQL. Active Record simplifica os casos comuns, mas uma vez que você começa a chegar em cenários mais complicados ele espera que você use SQL diretamente.

Eu não vejo o vazamento de abstrações O/R como uma condenação a esses frameworks. O objetivo deles é melhorar a produtividade tornando mais fácil fazer as coisas comuns. Eles permitem a uma equipe focar seus esforços nos poucos casos que realmente interessam. O problema somente aparece quando uma equipe acredita que a abstração é perfeita, e não coloca nenhum esforço em trabalhar com SQL. É uma falha comum, mas não é uma razão para abandonar as reais vantagens de frameworks O/R quando usados corretamente.

Requisições Demoradas

Um problema comum que vimos são aplicações que caem em levar tarefas que demoram para terminar. Feitas de forma ingênua, isso pode resultar no controlador das requisições web de caírem no escuro por um longo e preocupante tempo enquanto lida com a requisição.

Isso é um problema muito comum com qualquer interface humana, e tem uma solução comum – jogar a tarefa a um processo ou thread em background. Qualquer um que tenha programado uma aplicação cliente de GUI reconhecerá que fez algo assim. As pessoas acabam caindo em problemas, entretanto, se essa troca e comunicação são feitas da maneira errada.

A rota que eu prefiro, e felizmente parece que a maioria dos ThoughtWorkers concordam, é usar um ator. Nesse modelo o controlador da requisição web pega qualquer tarefa demorada, embrulha em um comando e coloca em uma fila. O ator no background então monitora a fila, tirando comandos da fila e os executando, sinalizando ao ator de interação humana quando termina com cada um. A fila normalmente começa como uma tabela num banco de dados e então pode migrar para um sistema real de mensagens se precisar.

Sobre o vazamento do Active Record, eu aponto não porque é um problema de aplicações Rails, nós vemos isso em todo tipo de aplicação. Vale a pena apontar porque parece muito fácil para muitas pessoas usando Rails de esquecer que esse tipo de coisa acontece, e portanto precisam usar esse tipo de padrão. Descobrimos que Rails torna muitas das partes repetitivas de aplicações web fáceis e mais rápidas de fazer – mas as partes mais envolvidas permanecem.

Deployment

Aplicações Rails são fáceis de construir, mas infelizmente já foram mais chatas de fazer deployment. O cenário comum de usar um pacote de muitos servidores web mongrel é ruim de configurar. Isso era uma coisa que ficou marcada pelo contraste com a suavidade do resto da experiência ruby.

O consenso comum é que Phusion Passenger torna essa coisa toda muito mais simples agora e é o jeito recomendado de deployment com MRI.

Também vimos grandes fãs em usar JRuby para deployment. JRuby permite que as pessoas usem a pilha padrão de aplicações web Java, o que pode tornar muito mais fácil de lidar em muitas configurações corporativas. Mingle também usou esse jeito para facilitar a instalação para clientes. De fato a equipe Mingle faz todo o desenvolvimento com MRI mas faz deploy com JRuby. Eles fazem isso porque o tempo de início mais rápido do MRI torna o desenvolvimento mais rápido. (JRuby requer o início da JVM, que é perceptivelmente hesitante.)

Controlando Gems

Ruby inclui um sistema de gerenciamento de pacotes, Ruby Gems, que torna muito fácil instalar e atualizar bibliotecas de terceiros. Rails também tem plugins que faz uma tarefa semelhante para Rails. São boas ferramentas, mas é fácil equipes caírem numa cilada com máquinas diferentes configuradas com diferentes versões de diferentes bibliotecas.

Existem algumas maneiras de lidar com isso. O primeiro jeito envolve copiar o código fonte com todas as bibliotecas e colocar tudo no repositório de controle. Desta forma um simples checkout lhe dará todas as versões corretas das bibliotecas. Um segundo jeito é usar um script que faz o download e ativa as versões corretas de todas as bibliotecas. O script precisa ser mantido no repositório. (AkitaOnRails: o terceiro jeito é usar o próprio controle do Rails para indicar as versões corretas como eu explico neste artigo).

Na mesma linha, a maioria das equipes também colocam uma cópia do próprio código fonte do Rails. Isso lhes permite aplicar patches ao Rails diretamente para consertar qualquer bug ou outros problemas vitais. Esses patches podem ser enviados à equipe principal do Rails. Usar sistemas de controle distribuídos, como git, tornou isso um pouco mais fácil de gerenciar. É certamente muito mais fácil do que nossas lembranças de ter que decompilar servidores de aplicação Java para aplicar patches no passado.

Tempo Cronogramado de Atualizações

Ruby no geral, e Rails em particular, movem de forma rápida. Existem atualizações freqüentes ao sistema Rails, com funcionalidades que queremos usar. Descobrimos que precisamos garantir um tempo cronogramado para lidar com atualizações do Rails e incluí-los no nosso processo de planejamento. Eles são mais significativos que outras plataformas, mas a boa notícia é que existe uma linha constante de novas capacidades.

Desenvolvendo em Windows

Ruby nasceu num mundo unix, e muitas pessoas que trotaram à plataforma usam barras não invertidas para caminhos de diretórios. É possível rodar, fazer deploy e desenvolver para ruby na plataforma Windows, mas também é mais complicado. Nossa recomendação geral é usar uma plataforma unix para todo o desenvolvimento. Macs são mais comumente preferidos, mas muitas pessoas usam outros Unixes FOSS também.

Esperamos que essa situação vá mudar enquanto o Iron Ruby é desenvolvido. Seria legal ter a opção de fazer deploy de aplicações Ruby em Unix, JVM e CLR. De fato isso tornaria Ruby uma opção particularmente flexível para suporte de runtimes em múltiplas plataformas. Também ajudaria projetos .NET a ter Ruby como uma linguagem de script em conjunção com as linguagens mais populares em .NET.

[Off-Topic] Padrões, Commodities e Inovações

Sun, 14 Jun 2009 18:17:45 PDT

Recentemente a Apple atualizou toda sua linha de notebooks Macbook Pro para não terem mais baterias removíveis. As baterias agora são internas e duram de 7 a 8 horas, o dobro do resto da indústria e, teoricamente, devem durar até 5 vezes mais.

Olhando em termos de valor ao cliente eu imagino que a Apple pode ter pensado: “por que as pessoas precisam de baterias removíveis?” As respostas variam, mas eu particularmente imagino que existem apenas duas razões: como as baterias normais duram cerca de 3 ou 4 horas, para usar um dia inteiro de trabalho você precisa de pelo menos 2 baterias, especialmente se você está viajando ou em conferências que duram o dia inteiro. O segundo motivo é porque a baixa qualidade das baterias atuais faz com que elas se “viciem” muito rápido e uma bateria que durava 3 horas começa a durar 2 ou menos horas.

A Apple resolveu isso de diversas formas. Ela repensou o processo todo de construção da bateria, possui engenheiros e cientistas especializados em química e montagem de baterias. Ela as constrói em formatos customizados que utilizam o espaço da forma mais otimizada possível. O fato de torná-las não-removíveis é para retirar o desperdício dos mecanismos móveis, baias, mecanismos de encaixe, abertura, etc. Isso permite uma área muito maior. Fora tudo isso, colocaram inteligência na forma de chips que alteram a voltagem de recarga dinamicamente, evitando com que a bateria se vicie prematuramente.

É uma coisa que pode passar despercebido mas eu quis comentar aqui – e recomendo que vocês assistam ao vídeo deles. O que eles fizeram foi inteligente. Eliminaram desperdícios que eram considerados “normais” em qualquer notebook. Eles repensaram algo que já era considerado maduro. Quebraram paradigmas considerados senso comum como “óbvio que baterias tem que ser removíveis” e com isso criaram um produto que entrega mais valor ao cliente. Pessoalmente, eu acho que isso é um pensamento bastante Lean.

Eu gosto de pensar em Lean não como um processo – mesmo porque ele não é. Lean é uma filosofia e uma cultura – assim como Agilidade. No centro dela está o pensamento de fluxo contínuo, uma das formas de atingir isso é eliminar desperdícios. Por outro lado, existem outras filosofias envolvidas, uma delas é o Kaizen, melhoria contínua e, como objetivo final de tudo, levar o máximo valor ao cliente e remover tudo aquilo que não leva benefício direto ao cliente. Em tudo que a Apple faz, é exatamente isso que eu vejo: inovação é o resultado desse tipo de pensamento, ao mesmo tempo conseguindo um processo mais enxuto, eficiente e que leva o máximo valor direto ao cliente.

É a mesma coisa que leva a coisas como o Magsafe, o touchpad MultiTouch, o teclado luminoso, a integração íntima do sistema operacional com o hardware – e isso é muito mais importante do que muitos acham -, e assim por diante. O que justifica o acabamento superior dos notebooks Apple. E isso não é fanboyismo, é fato, o valor de um notebook Apple é indiscutivelmente superior.

Zara

Esse tipo de pensamento me relembra os livros de James Womack. Não lembro se foi em Lean Thinking onde li sobre o case da Zara e que depois revi numa palestra da Mary Poppendieck, da Agile 2007, sobre Liderança, o mesmo case. Eu gosto desse caso porque, por coincidência, a Zara é uma das lojas que eu mais gosto de frequentar.

Zara é uma grande rede de lojas de roupas, pelo menos em 2007 eles tinham mais de 990 lojas pelo mundo, principalmente na Europa, e faturamento de 5 bilhões de euros, nada pequeno. Eles tem capacidade de ir do design das roupas até a loja em 2 semanas, esse é o tempo de produção deles.

A premissa deles é simples – e óbvia – de que eles não sabem o que os clientes querem. Portanto dependem dos gerentes nas lojas constantemente reportando à matriz o que os clientes mais procuram. Por exemplo, numa determinada cidade talvez os locais queiram mais roupas de cor vermelha porque é a cor do time local de baseball que acabou de ganhar um campeonato. A resposta da Zara é entregar o que eles querem o mais rápido possível, e eles conseguem fazer isso em 2 dias. Para isso eles fabricam pequenas quantidades de cada ítem e não grandes lotes. Mais do que isso, indo contra o que muitos considerariam “bom senso”, eles não terceirizam a fabricação em massa para a China ou outros países asiáticos porque a logística para entregas rápidas seria muito mais cara e não compensa a mão de obra mais barata. Portanto eles tem fábricas no Leste Europeu mesmo.

Por causa disso, a Zara fabrica cerca de 11 mil ítems por ano, contra uma média da indústria de 3 mil peças apenas. A Zara consegue vender cerca de 85% de tudo que fabricam ao preço cheio, enquanto o resto da indústria vende 60%, no máximo 70% a preço cheio. Isso é por causa do desperdício de fabricar demais – novamente, forecasts não funcionam. Podemos ver isso o tempo todo com “queimas de estoque”, “liquidações”, “outlets”. A Zara fica com menos de 10% de ítens não vendidos, enquanto os outros ficam com pelo menos 20% de ítems não vendidos. Com isso você vê de onde a Zara tira seu lucro, não é fazendo economia porca e terceirizando para a Ásia para mão de obra barata, é em tendo um processo de produção mais eficiente. Esse é mais um exemplo do pensamento Lean. (obs: Infelizmente acho que a Zara do Brasil não segue o mesmo processo, tem muita peça velha e pouca novidade ultimamente.)

A Zara e a Apple não descobriram nenhuma fórmula mágica. Nem mesmo a Toyota quando criou o famoso Toyota Production System, o melhor exemplo do pensamento Lean. “Entregar valor ao cliente” parece óbvio e a maioria das empresas acha que está fazendo isso, quando na realidade não está. Focar em entrega rápida ao cliente é bastante difícil e não é algo que estamos acostumados a fazer.

Padrões

Isso me leva a outra coisa que vi na palestra da Mary e nos livros do Womack. Na maioria das empresas temos coisas como “padrões” ou “políticas” ou simplesmente “regras”. Independente da palavra, vou usar “padrão” para significar a mesma coisa.

Para a maioria dos gerentes, “padrões” são feitos para que qualquer novo funcionário consiga trabalhar como todos os outros. Padrões foram feitos para serem seguidos, e não questionados.

Esta é a maneira mais idiota de se pensar em padrões. Para Taiichi Ohno, pai do TPS, padrões são outra coisa. Padrões são o “as-is”, ou seja, como as coisas funcionam hoje. Não são visões de como as coisas deveriam ser, mas uma descrição fiel de como se trabalha e se produz no presente, sendo certo ou errado.

O trabalho de um líder de produção lean é garantir que os padrões não permaneçam fixos por muito tempo. Se depois de um mês o padrão ainda for o mesmo, seu chefe poderia lhe fazer até a pergunta “você trabalhou no mês passado? porque os padrões não mudaram.” Numa cultura de melhoria contínua, a equipe deve estar constantemente procurando maneiras melhores de fazer a mesma coisa, e não apenas idioticamente seguir o que o padrão diz. Padrões são “baselines”, são pontos de partida que devem ser constantemente questionados e melhorados. O padrão de hoje tem que ser melhor que o padrão de ontem.

A partir do momento em que você tem na cabeça “é assim que sempre fizemos e portanto é assim como vou fazer hoje e é assim como vou fazer amanhã” você criou um funcionário estagnado, desmotivado, conformado e, pior de tudo, que não evoluiu. Funcionários que não evoluem significa uma empresa que não evolui.

Empresas que tem departamentos que devem ficar criando novos padrões, processos ou políticas para empurrar goela abaixo no resto da empresa são empresas que considero “burras” ou, pelo menos, “cegas” porque eles ignoram os seus verdadeiros olhos: os seus funcionários. Ao mesmo tempo ela sinaliza uma cultura onde ninguém deve tentar se destacar, todos devem ser iguais, se vestir iguais, chegar nos mesmos horários, almoçar na mesma hora, até ir no banheiro em horários constantes. É uma empresa que valoriza a média – meus velhos inimigos, as curvas gaussianas, ou “normais” – uma empresa que valoriza, por definição, a “mediocridade”.

Empresas Lean, por outro lado, valorizam a meritocracia. Valorizam espaço para erro que, no processo correto de Hansei e Kaizen, levam à melhoria contínua. Por sua vez, isso eleva os padrões de forma cumulativa.

Este artigo segue a linha do anterior Conselhos para Gerentes, sugiro que leiam este também.

[Tradução] Conselhos para Gerentes de Desenvolvimento de Software

Thu, 04 Jun 2009 23:35:59 PDT

Obs: alguns dias trás eu escrevi um desabafo sobre o comportamento ruim de um gerente de projetos. Nesta tradução, vamos ver soluções e os cenários corretos. Vamos à tradução:

Em 2004, a revista ‘Software Development Magazine’ entrevistou Gerald Weinberg. Aqui vão algumas de suas respostas (a entrevista completa está no site dele):

Qual foi o melhor conselho relacionado a gerenciamento que você já deu?

Se você culpa seus funcionários, você é um péssimo gerente. Você os contratou, os aceitou, os supervisionou, e dirigiu seu treinamento. Você é responsável. Se você não gosta do que está acontecendo, veja seu próprio comportamento. Mas, se há crédito a ser dado, é deles.

E sobre gerentes que foram contratados em um grupo onde alguns ou todos os funcionários já foram contratados por outra pessoa?

Você não assume um trabalho de gerência de forma passiva. Antes de aceitar a posição, você entrevista todos em seu grupo, e você consegue o apoio deles, ou se livra deles – ou não aceita a posição. Eu não sei porque gerentes não entendem isso. Eles assumem novas responsabilidades como colegiais em seu primeiro encontro às cegas.

E se um funcionário começa a demonstrar mal comportamento depois que ele ou ela o contratou – comportamento que não era aparente na fase de entrevista?

Bem, isso acontece, e é para isso que gerentes são pagos. Pode ser um retrocesso, mas é seu trabalho cuidar disso e terminar o serviço. Infelizmente, poucos gerentes técnicos tem qualquer preparação para isso, é uma coisa que venho tentando remediar por anos – então, por um lado, eu sou culpado, porque fui bem sucedido apenas em alguns casos. Ei, se tudo desse certo o tempo todo, você não precisaria de gerentes.

O que é atribuir a Culpa?

Obs: Leia o artigo completo Beyond Blaming no site oficial do Jerry.

Em uma organização congruente, seu gerente pergunta, “Como anda seu projeto?” e sua resposta, “Estou um pouco receoso que vou atrasar no cronograma.” Isso inicia uma discussão para resolver o problema, de onde vocês dois fazem novos planos para colocar o projeto de volta em dia. Em uma organização de culpa, entretanto, seu gerente pode lhe dizer que somente pessoas inferiores tem pouca confiança. Nesse caso, resolução de problema será substituído por evitar-a-culpa.

Do ponto de vista de um escritor, interações congruentes não são muito dramáticas; as pessoas apenas agem sensivelmente, tem consideração uns pelos outros, terminam seus trabalhos, e se divertem com o que fazem. Esse tipo de comportamento pode não dar uma boa cena de novela, do que seu gerente gritando em ira e você se encolhendo num canto, mas definitivamente resulta em projetos melhores.

Não que uma cultura de atribuir a culpa conduz toda interação de forma culposa, dramática. Sob circunstâncias ordinárias, resoluções congruentes são a regra, mas se as circunstâncias fossem sempre ordinárias, não precisaríamos de gerentes. Quando sentimentos de auto-estima estão em baixa, elas se manifestam de maneira mais dramática em resoluções incongruentes características: atribuir culpa, apaziguamento, ser super-razoável, amável ou odioso e agir de forma irrelevante. Não podemos lidar com tudo isso num artigo curto, então vamos discutir ‘atribuir a culpa’, talvez a forma mais comum e mais diretamente destrutível de estilo de resolução.

Sob estresse as pessoas tendem a perder o equilíbrio, e um ou mais de três componentes essenciais podem ser ignorados, levando ao característico estilo de resolução incongruente. Por exemplo, quando as pessoas falham em levar outras pessoas em consideração, eles caem em uma postura de jogar a culpa nos outros. Aqui vai uma típica ação de atribuir culpa que você vê em organizações de software (palavras em itálico são enfatizados nesse estilo de falar – porque múltiplas palavras enfatizadas em uma sentença linguística são sinais de jogar a culpa):

Gerente, quando o programador chega atrasado para uma reunião: “Você está sempre atrasado. Você nunca demonstra qualquer consideração pelas outras pessoas.”

Por que isso é incongruente? Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele não está sendo congruente ao dizer isso? Sim, mas não é isso que esse gerente disso. Ele não disse, “é minha impressão que você está sempre atrasado para minhas reuniões.” Em vez disso, ele pronunciou sua impressão de atraso como se fosse um fato científico, nunca oferecendo a possibilidade do programador poder ter uma impressão diferente. Ele generalizou a experiência da sua reunião como se isso necessariamente se aplicasse a todas as reuniões, nunca permitindo a possibilidade de sua experiência não ser a única que conta.

Se o gerente realmente está sentindo e pensando que o programador está sempre atrasado e não tem consideração, ele deveria dizer, “eu acho que você está sempre atrasado, e eu acho que você não está tendo consideração comigo e com os outros. Essa é sua percepção também?” (e deixando de lado as palavras estressadas). Estilo de gerenciamento ainda melhor seria dar ao programador a chance de dar uma percepção diferente antes de lançar qualquer interpretação. No mínimo, isso evita embarassamentos em situações como a seguinte:

Gerente, quando o programador chega atrasado para uma reunião: “Parece para mim que você está sempre atrasado. Essa é sua percepção também?” Programador: “Sim, e eu me sinto mal sobre isso. A razão de eu estar sempre atrasado é que eu tenho que doar sangue para meu filho de 9 anos, que está morrendo de leucemia, e a única hora para doações é bem antes desta reunião.” Gerente: “sinto muito sobre seu filho. Não sabia disso. Vamos marcar a reunião para outro horário para que você não precise se atrasar.”

De forma geral, isso permite a possibilidade de que possa existir outras considerações que contem além daquelas desse único gerente. Por exemplo, talvez o programador está chegando de uma reunião com clientes – uma reunião que por acaso cruza horários com a reunião do gerente.

Mas e se o programador realmente está sempre atrasado, sem uma explicação razoável? O gerente não está no seu direito de culpar o programador? Na realidade não, porque essa situação não é sobre “se tem direito”, mas sim sobre ter o projeto finalizado. Para esse propósito, o problema é resolvido de forma mais efetiva confrontando sem jogar a culpa; com fatos sobre o comportamento inaceitável. Pulando a atribuição de culpa, o gerente mantém a comunicação clara e aberta, maximizando a chance do programador receber a mensagem intencionada. E, claro, receber a mensagem intencionada maximiza a chance (embora não garanta) que o problema irá se resolver.

Quando se atribui culpa, a resolução do problema tem menor chance de acontecer porque os fatos do caso se tornaram uma fator minoritário – o maior fator na atribuição de culpa é “quem é importante e quem é insignificante.” Quando se atribui culpa, a pessoa está dizendo, “Eu sou tudo, você não é nada.” Claro, isso não vem de realmente pensar “Eu sou tudo,” mas do oposto. Dirigir a atenção para outra pessoa – e jogar a culpa é normalmente acompanhado de apontamento de dedo – é um dispositivo de auto-proteção para distrair os outros do desconforto que o inquisidor sente.

Como toda resolução incongruente, atribuir culpa é reforçado por sentimentos de baixa auto-estima. Quando você culpa, você tenta se colocar no alto através de puxar o tapete dos outros, porque você não tem a segurança de que pode aguentar muito – ou mesmo sobreviver – de qualquer outra forma.

Jogar a culpa nos outros engana as pessoas pouco sofisticadas, ou cuja própria auto-estima seja bem baixa. O observador inteligente, entretanto, enxerga a quantidade de atribuições de culpa como uma medida segura de quão inadequado o inquisidor se sente. Mais do que isso, se jogar a culpa nos outros é o estilo de comunicação de projeto preferida, então se torna uma medida de quanto um ambiente se degradou – quão pouca comunicação é dirigida a assuntos de projeto, comparado à quantidade que é dirigida diretamente a estufar a baixa auto-estima do comunicador.

Em uma organização onde se joga culpas, não é somente o gerente que faz isso, como ilustrado por estes exemplos:

Programador, quando o gerente pede para falar com um candidato ao trabalho: “Por que você não faz isso você mesmo? Não vou fazer seu trabalho por você. Se fosse mais organizado, não precisaria me pedir essas coisas.” Cliente, quando o gerente de projeto pergunta sobre a possibilidade de rever os requerimentos: “Você nunca acerta nos requerimentos da primeira vez. Se eu digo uma vez, já disse mil vezes. Faça o trabalho certo da primeira vez, daí não vai precisar me perturbar com revisões.”

Como Jogar a Culpa Machuca um Projeto

Claro, pessoas não são perfeitas, então é impossível conduzir um projeto grande sem ocasiões onde as pessoas são incongruentes. Gerenciamento normal de projetos pode lidar com essas situações – quando elas são excepcionais. Mas quando todo o ambiente encoraja jogar a culpa, cada nova situação complica ainda mais a incongruência. Fred Brooks uma vez perguntou, “Como um projeto de um ano acaba ficando dois anos atrasado?” Sua resposta foi “um dia de cada vez.” Nossa resposta é “uma comunicaçao incongruente de cada vez,” como o exemplo seguinte ilustra:

Um dos programadores estava desenvolvendo um módulo que produzia relatórios impressos quando era testado. O gerente colocou muita pressão no programador para que ficasse pronto no prazo, sem desculpas permitidas. O programador produziu um relatório e o gerente estava contente (embora ele tivesse demonstrado isso, claro – era “somente uma parte esperada do trabalho” na cultura de jogar a culpa). Um mês depois, outra pessoa tentou usar esse módulo e descobriu que ele não havia sido finalizado de jeito nenhum. O programador usou um Word para produzir um relatório falso que se parecia exatamente como um relatório de teste deveria se parecer. Ele pensou que isso lhe daria mais tempo (levou um mês, afinal de contas, até alguém descobrir) para finalizar o módulo. Infelizmente, como era muito trabalho, um mês não fora o suficiente.

O gerente culpou o programador. O programador não disse nada, porque nessa cultura de jogar a culpa, dizer alguma coisa só trás mais acusações na cabeça. A pessoa que reportou o incidente disse que nessa organização, falha não é permitida sob nenhuma circunstância. Pessoas que tem problemas em um projeto e conseguem prever atrasos não conseguem gritar por AJUDA! e receber assistência apropriada. De acordo com os gerentes, cada programador é responsável por atingir os prazos que concordaram. Estimativas inexatas “não eram permitidas” e perfeição deve ser atingida no primeiro dia – caso contrário você é colocado no pilar da culpa. Nessa situação, relatórios falsos são a regra, não a exceção (nota do Akita: para ser mais claro, substitua ‘relatório falso’ por qualquer dessas ‘gambiarras’ que vemos comumente em código.)

Jogar a culpa é o segredo negro do fracasso de muitos projetos. Uma cultura de jogar a culpa machuca um projeto de pelo menos seis grandes maneiras:

As pessoas se comprometem com planos que sabem que não conseguem atingir, pelo menos para atrasar o recebimento da culpa. (nota do Akita: já ouviu aquele programador que parece sempre “tenho muita coisa pra fazer, por isso não posso nem fazer direito, nem ajudar os outros” – o paradoxo: como pode “ter muita coisa” se foi ele mesmo quem concordou, em todas as vezes, com o que fazer?)
As pessoas escondem fatos que os gerentes precisam para controlar o projeto, como no exemplo acima. (nota do Akita: lembrem-se, “não ter problemas, é um problema” – significa que estão sob o tapete.)
Quando os problemas são finalmente revelados, as pessoas evitam sair com idéias de soluções criativas, por medo de levarem a culpa caso não funcione, ou simplesmente se fazem de joão-sem-braço.
Em operações de rotina, uma grande parcela dos esforços de cada um é devotado em se posicionar para não levar a culpa quando a hora chegar. (nota do Akita: exemplo, “a culpa é da outra equipe, a responsabilidade não é minha, ou só minha.”)
As pessoas que porventura se sentem seguras o suficiente para se focar no trabalho, se vêem gastando bastante tempo checando a confiabilidade na comunicação com os outros.
As pessoas se sentem mal a maior parte do tempo, e gastam muito tempo em tarefas improdutivas ou simplesmente olhando para as paredes.

A Aparência e Sentimento da Incongruência

Organizações podem mudar de uma cultura de jogar a culpa para uma cultura de congruência. Para fazer essa mudança, o primeiro passo é medir, ou pelo menos detectar – mas como medir atribuição de culpa? Na realidade, um consultor experiente consegue detectar uma organização de atribuição de culpa com poucos minutos de contato, porque os sintomas estão por todos os lados. De fato, as pessoas da organização já sabem que é uma cultura de jogar a culpa – mas, claro, numa cultura dessas, jogar a culpa é indiscutível e, mais ainda, a indiscutibilidade também é indiscutível. Paradoxalmente, a existência da indiscussabilidade torna mais fácil detectar a atribuição de culpa. O gerente de um projeto manda um e-mail dizendo que não haveria mais discussão sobre a moral do projeto, e que ele não prestaria mais atenção a questões do assunto porque todos deveriam estar gratos por estar trabalhando num projeto tão legal. Esse tipo de coisa só poderia acontecer numa organização onde se joga a culpa.

Executivos

Uma cultura de jogar a culpa começa no topo. Membros do nível superior de gerenciamento tem costume de enxergar as outras pessoas da organização como fontes de problemas. Os funcionários são vistos como “ingratos” por seus trabalhos, salários, benefícios e oportunidades dadas a eles. São vistos como tendo “falta de ética apropriada de trabalho”, “não saber dar valor”, “ter problemas de autoridade” e “resistir a mudanças”. Essas percepções deixam a alta gerência num dilema: “será que eu as demito, ou demito quem as contratou?”

Esse tipo de gerente sente que está tentando realizar uma visão sem ter o suporte necessário, o que os deixa no limbo. A experiência interna de inércia desses executivos é normalmente uma dor de cabeça contínua e crônica – a menos que as margens de lucro estejam muito baixas. Nesse caso, eles tem sentimentos mais apurados, como dor no peito e queimação no estômago. Suas baixas auto-estimas se refletem adiante na forma de frequentes downsizings, re-engenharias (nota do Akita: aqueles que em vez de encarar os problemas, ficam achando mais uma “metodologia” da moda para implementar, achando que isso resolve alguma coisa), evitar problemas mais sérios, e-mails fúteis e, claro, humilhar subordinados (nota do Akita: aqueles que largaram seu sub-gerente trabalhando, achando que estavam fazendo direito, e só recebem feedback negativo meses depois, quando é conveniente – que é um tipo de humilhação). A si mesmos, eles normalmente praticam comportamentos viciados e auto-destrutivos (que não podem ser discutidos, mas costumam ser assunto de fofocas.)

Gerência do Meio

Enquanto a alta liderança é incongruente, os gerentes do meio constantemente recebem mensagens misturadas. Cantarolam aos gerentes de projetos de sua importância e, então descobrem que seus sêniores os “bypassaram” (passaram sobre eles) para intervir diretamente em projetos ou mudaram as regras sem os consultar. Eles se sentem como se estivessem vivendo numa montanha-russa – sem conseguir prever se um determinado dia ou semana será bom ou ruim. Depois de serem publicamente humilhados algumas vezes, eles decidem que sua melhor estratégia é tentar ficar longe de problemas, sem chamar a atenção (nota do Akita: aqui começa a rotina do batedor-de-cartão conformado).

Em uma organização de atribuição de culpa, a alta gerência tenta (talvez de forma inconsciente) ensinar os gerentes do meio suas próprias atitudes de jogar a culpa. Quando um gerente de projetos reclamou da sua inabilidade de fazer os programadores trabalharem mais rápido, o Vice-Presidente de Desenvolvimento disse, “se seus cachorros não vão pular mais alto, encontre uma vara mais longa para bater neles.” Vivendo num inferno de incongruência vindo de cima, aparecem os problemas de sobrevivência da gerência do meio. Como faziam quando eram crianças, eles descobrem como acalmar, agradar ou evitar os donos do poder. Ao fazer isso eles asseguram sua sobrevivência – e passam a culpa para níveis mais baixos.

Funcionários

Na parte de baixo de uma organização de atribuição de culpa, os funcionários normalmente estão procurando por outro lugar para trabalhar a menos que a empresa esteja em uma condição estável e com pouca competição – ou se suas aposentadorias estão próximas. A maneira para sobreviver é se esconder e aparecer somente para pegar o contra-cheque (nota do Akita: e em épocas de depósitos automáticos, nem isso.)

Funcionários são desencorajados de pensar criativamente – novas idéias são interpretadas como jogar a culpa na gerência ou tentar usurpar seus poderes e prerrogativas. Funcionários não são recompensados por competência – mas são frequentemente punidos por “descuido” percebido. Funcionários não procuram seus gerentes – exceto quando há problemas. Então, a maior parte do esforço é gasto em tentar dar nome aos bois em vez de resolver o problema.

O estilo de jogar a culpa varia de organização para organização. Pode ser de forma dura, vingativa, direta ou indireta – mas é sempre contagiosa. Algumas organizações refinaram sua maneira de jogar a culpa a um alto grau de sutileza – sem gritos, meramente lançando um olhar, ou um e-mail, ou um telefonema, ou uma visitinha se as coisas são realmente ruins. Em outras organizações, a atribuição de culpa é na gritaria, raivosa e frequentemente feita na frente de uma platéia – para assegurar que todos entenderam a mensagem de quem está certo, quem é o “bonzão”, quem está no comando, e quem deve ficar invisível.

Nesse tipo de ambiente, se defender se torna comum. Para aqueles sem poder formal ou autoridade, parece que aqueles com poder não se importam com eles – e os baniriam sem nenhum remorso. Então eles se sentem no direito de retaliar (adiantado, e em segredo), e em evitar seus gerentes e seus problemas.

Independente do estilo, jogar a culpa do topo sempre gera medo, desconforto, erros, acidentes e respostas passivo-agressivas de baixo. Aqueles embaixo se sentem pequenos e agem de um lugar sem poder. A falta de segurança emocional efetivamente corrói os níveis de confiança e torna qualquer tentativa de congruência extremamente arriscada. O ambiente deles soa assustador e é – tanto para a pessoa que regrediu para imaturidade emocional e, tristemente, para a pessoa no topo que está jogando a culpa.

Aqueles na camada de baixo de qualquer grande organização podem facilmente vir a sentir um senso de dependência àqueles acima deles na hierarquia. Quando jogar a culpa é o modo primário de lidar com pessoas, essa dependência é exacerbada (nota do Akita: quase uma síndrome de Estocolmo). Então, de um sentimento de dependência, as pessoas facilmente geram um sentimento de hostilidade. À medida que essa hostilidade aumenta também aumenta a experiência debilitante de vergonha – aquele juíz excessivamente crítico que existe latente em todos nós, humanos.

A Aparência e Sentimento de Congruência

A maioria das pessoas que experimentaram uma organização congruente não vão tolerar a miséria de trabalhar em uma organização de atribuição de culpa. Mas muitas pessoas sequer tiveram essa experiência, e tem dificuldade em acreditar em congruência. Vamos ver o que aconteceria se uma dose saudável de congruência pudesse ser magicamente aplicada em larga escala a uma organização incongruente de projetos.

Executivos

Se pudéssemos magicamente instalar congruência nos programas internos desses executivos que jogam culpa, o estilo deles mudaria dramaticamente. Por exemplo, se eles verdadeiramente considerassem os outros envolvidos em sua comunicação, possivelmente acreditariam nas intenções das pessoas de contribuir, de serem produtivos, de pertencer e de aprender – e interpretariam desvios desse ideal como evidência de gerenciamento não efetivo. Sua crença no valor inerente de todas as pessoas com respeito saudável pelas limitações do contexto do trabalho traria energia, esperança, agradecimento, compreensão e gratidão entre seus funcionários.

Um executivo congruente que realmente não acreditasse nas boas intenções dos funcionários diria ‘Sem desculpas! Você terá isso pronto em Outubro.’ Mas, com funcionários cujas intenções são ruins, esse estilo (ou qualquer outro) não funcionaria mesmo.

Quando a alta gerência mantém seu compromisso com congruência, eles vêem que a maioria dos trabalhadores aprecia a oportunidade que o negócio lhes proporciona para desenvolver suas capacidades, sentido, relacionamentos e recompensas monetárias. Eles também sabem como agir quando o trabalhador ocasional não parece apreciar ou ser produtivo. Gerentes que sabem como usar seu poder de forma congruente geralmente conseguem os resultados que procuram – não perfeição, que eles sabem que não devem esperar.

Esses líderes sabem que possuem um tipo especial de poder – poder que usam com consciência e sensibilidade. Eles não deixam de cobrar daqueles que lideram, mas demonstram o mesmo nível de integridade que procuram nos outros. E se não conseguem encontrar os níveis de comprometimentos que requisitam dos outros, eles são abertos quanto a isso. Eles sabem que de vez em quando serão fracos e vulneráveis e precisam de apoio – talvez até para ver o valor de suas próprias visões. Eles usam sua consciência dessa realidade humana para cultivar sua capacidade de empatizar e de ter compaixão por si mesmos e pelos outros.

Executivos congruentes sabem que seu trabalho principal é desenvolver as capacidades de sua organização, não apenas empurrar os mesmos velhos produtos e serviços porta afora. Eles se envolvem de maneira séria nos esforços de melhoria da organização e simultaneamente envolvem outros da organização para conseguir os esforços na vida real, prática operacional e tomada de decisão. Eles sabem que sinergia é necessária para o desenvolvimento da organização e sabem que sinergia vem com conexões de alta qualidade entre as pessoas – independente de nível.

Gerência do Meio

Quando o pessoal do topo começa a operar com congruência, os gerentes do meio recebem mensagens claras e diretas – não mensagens misturadas com duplos sentidos. As comunicações são mais abertas, tornando mais fácil saber mais sobre o que está acontecendo. Dada informação de alta qualidade, eles sabem mais como podem ser úteis, conseguindo mais facilmente se unir a seus líderes em suas visões. Saber mais claramente as direções estratégicas desejadas, e sentir que eles contam nesse processo, os libera para contribuir de forma mais generosa e consciente – em vez de meramente jogar com segurança. Sucesso se torna um objetivo que todos podem compartilhar.

Dada sua posição única de vantagem, as pessoas do meio tem dados mais úteis para ajudá-los a prever problemas, projetar linhas do tempo realistas e predizer tendências. O que eles vêem, ouvem, pensam e sentem é valorizado e eles estão numa posição de iniciar comportamentos que evitam que fraquezas dos projetos cresçam até o fracasso. Eles conhecem a necessidade de interdependência, então se problemas maiores acontecem, eles podem ser considerados para oferecer – e também procurar – por informações importantes. Eles não estão envergonhados nem com medo daqueles que os contrataram. De fato, têm orgulho de seus compromissos com a organização – e sabem que não se trata apenas de compromissos como prazos e orçamentos, mas sobre a verdade sobre esses prazos e orçamentos.

E como congruência que vem do topo também vai para baixo, gerentes do meio notam a diferença entre seus líderes. Eles respondem ao modelo passando isso a seus constituintes. Todos na organização sabem o que está em jogo em cada trabalho bem feito, então todos se sentem seguros em dizer o que está errado, o que está atrapalhando e o que precisa ser consertado. Relatórios honestos de fatos e sentimentos são genuinamente apreciados e não colocam as pessoas em risco de serem humilhadas ou perderem seus empregos. É por isso que organizações congruentes entregam seus projetos como prometido.

Gerentes do meio congruentes encorajam comunicação de alta qualidade. Sua crença na habilidade das pessoas de aprender e mudar em direção a mais congruência tornam aqueles ao seu redor mais responsivos. Com radiação de congruência a partir do centro da organização, todos podem ter um lugar, posição e função de importância e valor – então as coisas acontecem da maneira correta.

Funcionários

Trabalhar na linha de frente de um negócio onde a liderança de cima é congruente, é uma experiência inteiramente diferente de trabalhar numa organização de atribuição de culpa. Compromisso e energia são a norma, não a exceção praticada por novos funcionários até eles “aprenderem como as coisas funcionam por aqui.”

Organizações congruentes suportam uma ideologia que fazer direito no mercado está ligado a lidar direito com os funcionários assim como com os clientes. A perspectiva da liderança inclui consciência global sobre a existência de múltiplos fatores não-lineares, a importância das conexões entre as várias partes do todo e a necessidade de todas as partes saberem seu valor. Os funcionários sentem que esta é uma empresa indo para algum lugar, onde crescimento é um estado natural e o esforço de todos conta. (nota do Akita: essa é a semente para equipes auto-gerenciadas.)

Trabalhadores numa organização congruente tendem a ter uma visão ampla e podem normalmente manobrar como necessário para atingir as mudanças demandadas pelos clientes. Os funcionários confiam que o que vêem e ouvem é real. Eles compartilham do entusiasmo de criar o futuro. Eles podem não gostar de tudo que acontece – por exemplo, nem sempre acham que estão sendo recompensados adequadamente pelo o que estão dando – mas não se sentem num padrão crônico de diminuição, descrédito e desvalorização do que fazem. Eles podem arriscar a congruência sabendo que isso vai agir como um catalisador para otimizar resultados de sucesso que beneficiam a todos.

Congruência é o grande segredo por trás dos sucessos de muitos projetos. Uma cultura de congruência ajuda um projeto de pelo menos seis grandes maneiras:

As pessoas se comprometem com planos somente depois de negociações abertas, então os planos tem mais chances de serem realistas logo no começo. (nota do Akita: a equipe se compromete apenas com aquilo que realmente acredita que vai entregar – não existe “tenho coisas demais para fazer”)
As pessoas vêm rapidamente com fatos, que os gerentes precisam para controlar o projeto, tão logo se tornarem conhecidos, então os gerentes podem agir mais rapidamente com movimentos pequenos para corrigir os problemas. (nota do Akita: cultura ágil que aceita a mudança.)
Quando problemas são revelados, as pessoas vêm rapidamente com idéias de soluções criativas, aumentando as chances de soluções rápidas e efetivas.
Uma boa parte dos esforços de todos é devotado a terminar o trabalho e ajudar os outros a terminar o trabalho deles.
Porque a falabilidade humana é considerada normal, uma quantidade apropriada – mas pequena – de tempo é gasto garantindo a confiabilidade da comunicação.
As pessoas se sentem bem a maior parte do tempo, e por isso são produtivas a maior parte do tempo.

Congruências em Grandes Esforços de Desenvolvimento de Sistemas

No percurso de desenvolvimento de sistemas, as pessoas engajam em numerosos atos de comunicação – sobre requerimentos, prazos, problemas interpessoais, designs, progresso e mais. É por isso que comunicação individual efetiva é importante em todos os projetos, grandes e pequenos. Isso dito, isso se torna ainda mais importante à medida que crescem os esforços de desenvolvimento. A quantidade de comunicação necessária sobe de forma não-linear com o tamanho do projeto, então o efeito de estilo de comunicação imperfeita é aumentada. Portanto, se a qualidade individual de comunicação se mantém constante à medida que o projeto cresce, a qualidade geral da comunicação decai. (nota do Akita: quantidade de conexões entre pares cresce segundo uma Lei de Potência.)

Por exemplo, um certo nível de congruência de comunicação pode ser adequado para produzir um produto com 25 mil linhas de código, mas totalmente inaceitável para um produto com 2,5 milhões de linhas de código. Para desenvolver sistemas grandes ou complexos, então, não é suficiente prestar atenção aos problemas técnicos – aceitando que o estilo existente de comunicação será adequado. Gerentes também devem melhorar a cultura de comunicação do projeto e, portanto, precisam prestar atenção à congruência.

Para tornar as coisas piores, se não for gerenciado direito, projetos difíceis tendem a diminuir a congruência – porque o estresse tende a subir quando a expectativa de qualidade decai. Não somos criatura altamente lógicas o tempo todo, mas temos sentimentos, assim como pensamentos em resposta a responsabilidades difíceis. Quando esses sentimentos internos são fortes o suficiente, eles se traduzem em estilos característicos de resolução sob estresse. Se nosso estilo característico é incongruente, as comunicaçoes se tornam menos efetivas e o trabalho se torna ainda mais difícil, criando um ciclo vicioso.

Congruência, claro, é apenas um dos fatores em comunicação efetiva – outros fatores incluem coisas como tempo, memória, platéia adequada e dados precisos. Mas sem congruência, seus esforços de melhorar esses fatores “lógicos” serão sempre seriamente sabotados, junto com sua habilidade de construir sistemas maiores, mais complexos ou mais confiáveis.

Atingindo Congruência

Quando Deming disse, “Coloque o medo fora do ambiente de trabalho,” nós achamos que ele estava falando sobre mudar a organização que atribui culpa a uma organização congruente. Esse tipo de mudança é apresentada a uma pessoa de cada vez – de preferência começando do topo – um passo de cada vez. Os passos podem ser quebrados em seis partes: Conscientização, Aceitação, Autoria, Articulação, Aplicação, Ativismo. Vamos olhar como cada um deles aparece no contexto de um indivíduo tentando mudar a organização que atribui culpa.

Conscientização

Conscientização diz, “Isto está acontecendo. Isto é real.” Conscientização vem da experiência, quando eu me permito experimentar o mundo ao meu redor como ele é – não como deveria ser, ou como eu acho que deveria ser, ou como alguém me diz que deveria ser.

Conscientização é sempre o primeiro passo e provavelmente o mais difícil, porque geralmente não estamos conscientes que não estamos conscientes. Aqui vai um exemplo pessoal de como falta de conscientização pára o processo de mudança antes mesmo de começar:

Jerry estava participando de uma reunião de projeto em uma empresa de software – uma reunião chamada pelo presidente da empresa para descobrir o que estava acontecendo em um projeto atrasado. Depois de alguma persuasão, um dos programadores disse que estava com medo de ir até o Nat, o Gerente de Desenvolvimento, com problemas, por causa da recepção que teve. Nat ficou com a cara vermelha, se levantou e gritou nervoso “Como pode dizer isso? Minha porta estava sempre aberta para ouvir seus problemas! A única coisa que não vou tolerar é se você fica todo tenso quando chega, ou se não tem uma solução para propor!” Na voz mais calma que conseguia (é difícil ficar calmo quando alguém está tão nervoso, mesmo se não diretamente a você), Jerry se virou ao Presidente e perguntou se Nat alguma vez foi até ele com problemas. Quando o Presidente disse que sim, Jerry perguntou se o Nat estava sempre calmo e carregando uma solução proposta. Antes do Presidente poder responder, Nat interrompeu: “Por que eu iria com um problema se não era importante o suficiente para se excitar a respeito? E, se eu tivesse uma solução, por que eu iria até ele?” Embora estivesse claro para todo mundo na sala que o Nat estava demandando que os outros “façam como eu digo, não como eu faço”, ele era incapaz de ver a incongruência. Faltando conscientização, não havia jeito do Nat mudar – e de fato ele nunca mudou, até o dia que o Presidente o demitiu para que pudesse procurar por pastos mais verdes.

O caso do Nat é bem típico. Já que incongruência é uma defesa, pessoas incongruentes sobem todos os tipos de escudos que fecham a informação sobre congruência. Sua própria incongruência e a dos outros é invisível – isso é aceito, especialmente se é o normal na organização. Essa invisibilidade torna muito difícil alcancá-los com qualquer tipo de informação sobre o assunto.

Em outras palavras, quando você está sendo incongruente, você está perdendo sua habilidade de ver o que está acontecendo no mundo (dentro e fora). Então, não sabe que precisa mudar. E, mesmo se souber, não tem nenhuma idéia do que mudar para. Não admira que é tão difícil transformar uma cultura incongruente, quando o primeiro passo – conscientização – já é tão difícil de conseguir.

Conscientização vem da experiência, quando você se permite experimentar o mundo ao seu redor – não como ele deveria ser, ou você gostaria que fosse, ou como alguém lhe diz que gostaria que fosse. Mas numa organização que atribui culpa, onde as pessoas se protegem dessa experiência, se tornar consciente normalmente requer ajuda. Ajudar os outros a se conscientizar demanda habilidades para desenvolver ambientes seguros e construir relacionamentos. Demanda paciência e carinho para observar por sinais de conscientização e ajudar a construí-lo. Também demanda fé e um comprometimento de que “parte do meu trabalho é ajudar as pessoas da minha equipe a se desenvolver – a parte mais importante.” Se não acredita nisso, então certamente não tente ajudar. Caso contrário, vai se encontrar dizendo “Você não está consciente de quão ruim você é, mas eu vou torná-lo consciente!”

Mas conscientização da situação geral não é suficiente – você também precisa de auto-conscientização. “Este sou eu. Isso é meu.” Você pode estar consciente da jogatina de culpa, mas enquanto meramente apenas disser “Esta é uma organização de atribuição de culpa,” você não está fazendo coisa alguma para mudar isso. Quando você diz, “Eu sou parte desta organização de atribuição de culpa,” você está dando um passo. Você deve ver a jogatina de culpa como uma parte de si mesmo e de seu comportamento – não apenas alguma coisa que “eles” fazem (a você).

Auto-conscientização é normalmente seguido ou de vergonha ou de culpa. Algumas pessoas reagem com raiva, a si mesmos ou a algum alvo conveniente. Ainda assim, auto-conscientização dá sensação de poder – o pensamento de que já que me pertence, é meu para eu fazer alguma coisa a respeito.

Aceitação

Aceitação move o processo de mudança além de alto-culpa e diz, “Eu não sou uma pessoa má porque faço isso. Minhas intenções são boas, embora minhas ações possam não ser efetivas.”

Aceitação significa que você entende que tomar a responsabilidade não é a mesma coisa que se culpar. Portanto, você tem clemência de si mesmo e de suas imperfeições humanas. Você pára de ser raivoso. Perdoa a si mesmo por não ter feito melhor no passado, baseado no seu entendimento presente e padrões. E, enquanto perdoa e aceita a si mesmo, você ganha compaixão pelos outros envolvidos – aumentando as chances de conseguir se comunicar com eles e efetuar mudanças.

No ponto quando você está tentando alcançar aceitação, é crítico que não seja punido ou humilhado por alguém. Você precisa de ajuda em suportar suas costas, do contrário você pensa tão pouco sobre si mesmo que não poderia fazer qualquer coisa sobre a situação. Claro, em uma organização que atribui culpa, pode ser difícil, por um tempo, evitar esse tipo de punição, que é o motivo pelo qual autoria e aceitação normalmente acontecem internamente, e se mantém internos por algum tempo.

Autoria

Autoria é o primeiro ponto de decisão, quando você diz, “Eu tenho escolhas. Eu posso fazer alguma coisa a respeito.” Com algum encorajamento, você aceita que é responsável por escolhas na sua vida. Você entende que não precisa reagir, mas que pode escolher suas respostas – que você consegue criar, em grande parte, seu próprio contexto interpessoal. Você sabe que existem algumas partes do contexto que pode controlar e algumas que não pode; e sabe precisamente qual é qual.

Articulação

Articulação é o compromisso público de mudar e dizer “Eu vou a público com isso (para assumir responsabilidade e conseguir suporte.)” Articulação não é efetiva se tentada antes dos pré-requisitos estarem nos lugares. Se não consegue aceitar a si mesmo ou como você se refletia para o mundo, ou se não sabe que tem escolhas ou sente que pode ganhar suporte com essas escolhas, então falar para fora é meramente uma bravata não efetiva.

Mas quando os pré-requisitos estão nos lugares, você não consegue ser efetivo mantendo silêncio – você precisa decidir falar. No processo de falar você transforma sua conscientização interior para outro tipo de experiência. Você se ouve e nota a resposta que recebe dos outros. Você torna público, se quiser, a si mesmo – sua posição mental e emocional.

Inicialmente, claro, você precisa procurar lugares para abrir suas expressões verdadeiras e honestas de seus pensamentos e sentimentos. Quando se acostuma mais com o poder de seu verdadeiro você, então consegue procurar o tipo de suporte que o desafia e o confronta, em vez do tipo de suporte que o protege ou consola.

Passos iniciais da articulação congruente normalmente são desajeitados. É por isso que um ouvinte responsivo e receptivo satisfaz um dos requerimentos para promover desenvolvimento e congruência.

Aplicação

Aplicação diz, “Estas são minhas escolhas (minhas novas maneiras de resolução).” Você consegue aprender a ser congruente, primeiro no contexto mais imediato, seguro e encorajador. Então expande os contextos nos quais consegue responder congruentemente. Não tente “não ser incongruente”. Esse comando paradoxal somente envolve incongruência e perfeccionismo. (“Se não consigo ser perfeitamente congruente o tempo todo, eu não valho nada.”) Foque na congruência, pratique congruência e os “músculos” da incongruência vão simplesmente atrofiar.

Com suporte e prática você consegue começar a usar e testar congruência nos seus relacionamentos imediatos. Sugerimos que continue a desenhar para o sucesso, de tal forma que esses testes iniciais de sua nova habilidade sejam feitos dentro de ambientes onde seja mais factível que lhe dêem o benefício da dúvida. À medida que experimenta sucesso, então você consegue se centrar até mesmo em arenas mais turbulentas e de conflito. Em outras palavras, uma vez que você “entende o recado”, não marche à sala do presidente e anuncie que, a partir de agora, todas as partes culpadas devem parar de jogar a culpa, ou caso contrário.

Ativismo

Ativismo diz, “Agora que eu consigo fazer diferença em mim e em meu mundo mais familiar, vou ajudar a espalhar isso pela organização.” Ativismo é liderança aplicada, começando pelo ponto onde você tem competência suficiente em ser congruente para alcançar e ser pró-ativo – antecipando, iniciando, instigando – mas não infligindo. Você não consegue operar de uma posição de incongruência e forçar outras pessoas a serem congruentes. (“Eu preciso culpá-los, porque eles também jogam tanto a culpa (nota do Akita: “sabonetam”). Quando eles mudarem, então eu serei capaz de mudar.”)

De qualquer forma, você não deve infligir congruência a qualquer um. Congruência é contagiosa – quando dirigida de forma consciente para criar um ambiente seguro, de cultivo, produtivo. Pode se espalhar mais devagar do que você gostaria, mas uma vez que começa a se mover, é difícil parar.

Notícias do Front #5

Mon, 01 Jun 2009 17:18:39 PDT

Desta vez faz apenas pouco mais de um mês desde minha última compilação de notícias. Este mês foi interessante, principalmente com a RailsConf Las Vegas que aconteceu no começo do mês. Quem quiser acompanhar tudo o que eu venho lendo, assine o feed do meu Google Reader, meu Delicious e, claro, para as últimas novidades, sigam-me no Twitter. Vamos às notícias:

PDF + Rails + RGhost – Now in the View – quando se pergunta sobre suporte de PDF no Ruby/Rails, a maioria se lembra primeiro do PDFWriter. Porém não podemos esquecer que temos uma solução nacional, o RGhost, criado pelo Shairon Toledo. Agora ele criou uma nova gem que integra ainda melhor o RGhost às convenções do Rails para conseguir criar views que geram PDF de forma bem mais simples.

Enforcing Ruby code quality – hoje temos diversas ferramentas que checam qualidade de código, no caso flay, flog, reek, roodi, metric-fu. Neste artigo o Marty Andrews explica como começar a usá-los para melhorar a qualidade do seu código.

beta test rake-compiler: fat binaries functionality implemented – se você é mantenedor ou colaborador de RubyGems, especialmente se elas tem extensões em C, leia esse artigo do Luis Lavena. Ele está aperfeiçoando um processo para tornar possível criar gems que contenham “fat-binaries”, ou seja, múltiplos binários para múltiplas plataformas na mesma gem, um processo que no mundo Mac ficou conhecido como “Universal Binary” (por ter um único executável com binários para PowerPC e Intel). Essa é, de longe, a maneira mais inteligente para suportar múltiplas plataformas e será excelente se as gems de Ruby começarem a sair dessa forma.

Sunspot: A Solr-Powered Search Engine for Ruby – felizmente uma coisa que nunca faltou no mundo Rails foi integração com engines de procura. O mais usado acho que ainda é o Sphinx junto com o plugin Ultrasphinx ou Thinking Sphinx. Porém existe outra alternativa: o Lucene, famoso em Java, com seu par Solr, um servidor que implementa o Lucene como serviço. O Sunspot tenta ser uma alternativa para integar ao Solr, dando uma DSL que permite integração mais intuitiva a esse engine de procura. Pode ser uma boa alternativa ao antigo plugin acts_as_solr.

Internbot Chronicles #4: CI & Test Metrics – ainda falando de qualidade, teste é um assunto constante em nossa qualidade, em especial Integração Contínua (CI). Neste artigo o Nick Quaranto explica como montar seu próprio CI.

MacRuby, changing the Ruby ecosystem – fiquem de olho no MacRuby. Na atual versão 0.4 ele já é bastante usável e inclusive permitiu a criação de aplicações desktop nativas de Mac como o Blogo, totalmente feito em Ruby mas que você nem perceberia. A versão experimental 0.5 está andando de vento em popa e trás uma nova virtual machine e performance – até agora – espetacular. Especula-se que ela venha inclusive a se tornar uma VM usada oficialmente pela Apple como ambiente de desenvolvimento rápido de aplicações Desktop de Mac e também de iPhone/iPod Touch! Neste artigo, o Matt Aimonnetti, colaborador do projeto HotCocoa, dá uma prévia do que está acontecendo. Aproveitando, não deixe de comprar o último excelente screencast do Peepcode, MEET MACRUBY.

Hg-Git Mercurial Plugin – a comunidade Ruby adotou o Git praticamente como a ferramenta de versionamento distribuído de código “oficial”. Porém, nós não acreditamos em “uma única maneira de fazer as coisas.” Durante a RailsConf, o Scott Chacon, que trabalha para o Github.com, lançou um plugin para Mercurial (hg), que permite a clientes Hg conversarem com repositórios remoto em Git de forma transparente. Isso permite que usuários de Mercurial consigam consumir repositórios do Github, por exemplo. Excelente exemplo de como a comunidade Ruby resolve seus problemas.

Scotland On Rails Presentations Now Online: 27 Awesome Videos – o evento Scotland on Rails liberou os vídeos das apresentações. Vale a pena dar uma olhada.

Ward Cunningham on Wikis and Agility – vídeo muito legal de uma entrevista com ninguém menos que Ward Cunningham – dentre milhares de outras coisas, criador do Wiki – , mostrando o ambiente de sua empresa, a AboutUs. Muito interessante para quem está interessado em criar ambiente realmente ágeis para seus funcionários.

rinterface: a pure Ruby client to talk to Erlang – mais uma maneira de fazer chamadas remotas a procedimentos (RPC) a partir de clientes Ruby, enviando chamadas a processos Erlang. É uma forma de integração, pode ser útil em muitos casos. Neste outro artigo, Dave Bryson explica algo similar, conectando-se diretamente na porta TCP do processo Erlang.

Clone TinyURL with 40 lines of Ruby code on Google AppEngine for Java – o título já diz tudo, mas aqui vai mais uma maneira de se criar mais um clone de TinyURL – que, aliás, deve ser a aplicação mais clonada dos últimos tempos. A idéia é usar Sinatra rodando sobre JRuby no Google App Engine. Pode ser um bom exercício para quem quer entender essas tecnologias.

ruby pong with shoes and bloopsaphone – quer aprender a criar o jogo mais simples de todos os tempos em ruby? Pong é o avô dos videogames modernos, mas ainda é divertido, especialmente de reimplementá-lo pela milésima vez. Neste caso usando o framework Shoes, do _why.

Heroku 0 to 60 in 15 minutes – neste tutorial a Elctech demonstra como criar, configurar e instalar uma aplicação Rails no Heroku. É tão simples que o tutorial é quase uma redundância :-) Na realidade metade do tutorial é gasto explicando como se registra domínios.

23 links e recursos úteis do Ruby 1.9 – não deixem de visitar o site RubyInside.com.br, a versão brasileira do site britânico de mesmo nome. Neste artigo há uma coletânea importante de 23 links para aprender mais sobre o Ruby 1.9. Todos os rubistas precisam estar atualizados quanto a este assunto para ajudar a comunidade a migrar gems e outros projetos para 1.9.

Railsconf 2009 in Review – este ano a RailsConf foi em Las Vegas. Se quiser mais detalhes também veja este vídeo da RailsEnvy ; a segunda edição da Rails Magazine ; o wrap up da thoughtbot ; os artigos que meus amigos da Locaweb que foram comigo escreveram; o round up da RubyInside ; o wrap up do wycatz ; o wrap up do Matt Aimonnetti. Finalmente, meus próprios artigos estão na categoria RailsConf2009, dêem uma olhada.

Rubystein – durante a RailsConf, uma das coisas que mais chamou a atenção foi a palestra dos garotos da Phusion, onde eles demonstraram um jogo feito em Ruby puro, uma reimplementação (não um port) do famoso jogo Wolfenstein 3D. A idéia foi demonstrar que o Ruby é lento mas não tão lento quanto dizem, e para provar, eles fizeram algoritmos que exigem muito processamento, como ray tracing, diretamente em Ruby. Leia a respeito também na RubyInside.

Sam’s Blog – Railsconf: Don’t mock yourself out – Dave Chelimsky – durante a RailsConf o David Chelimsky explicou mais uma vez sobre Mocks, Stubs. Neste artigo da Pivotal Labs, o Sam Pierson resume o assunto.

RabbitMQ – Um sistema de fila rápido e confiável para Rubistas – por favor, toda vez que precisarem de algum mecanismo que simule uma “fila” (lembram-se da faculdade, First In, First Out), não comecem implementando uma tabela chamada “fila” onde cada linha é um elemento! Já existem dezenas de soluções para isso. Especialmente se você precisa de uma fila realmente robusta, com as características básicas de garantia de entrega e garantia de entrega apenas uma vez. O RabbitMQ é uma fila muito capaz e, o melhor, não é difícil integrar com Ruby. E eis mais um exemplo de Ruby integrando com produtos Erlang.

rufus-decision 1.1, ruby decision tables – você tem aquele código feio, cheio de copy e paste, com vários ifs, dentro de ifs, dentro de ifs … resumindo, uma lógica que liga diversas condições em cruzamento a ações. Você precisa de uma tabela de decisão. Em Ruby, o rufus é uma implementação disso que pode ser muito útil para tornar sua lógica de negócio bem mais simples de dar manutenção, evitando duplicações desnecessárias.

Typhoeus: A High Speed, Parallel HTTP Library for Ruby – para quem quer realizar múltiplas requisições HTTP em paralelo, esta biblioteca pode ajudar. É algo até que simples em conceito mas que não havia de forma fácil em Ruby. Basicamente trata-se de realizar chamadas assíncronas não-bloqueantes que respondem a eventos. Pode ser útil quando você quiser criar spiders ou crawlers de sites.

is it jruby? – recentemente a Brightbox lançou o site is it ruby 1.9?, onde a comunidade poderia testar gems e dizer nesse site se ela é ou não compatível, em seus testes, com o ruby 1.9. Agora foi lançado mais uma com o mesmo objetivo mas desta vez para avaliar a compatibilidade de gems com o jruby. Mais e mais a comunidade está se conscientizando que as gems precisam receber mais tratamento para ficarem compatíveis com múltiplas virtual machines. Isso é muito bom e espero que todos colaborem.

[Off-Topic] As 5 disfunções de equipes em código

Sun, 31 May 2009 15:10:11 PDT

Eu costumo repetir a todas as equipes que eu gerencio, que 99% dos problemas de qualquer projeto são especialmente devidos à “comunicação”. Estresses que duram dias e poderiam ser resolvidos numa conversa de corredor de 30 seg. Eu uso “comunicação” mas é um pouco mais do que isso, é falta de respeito, falta de confiança, falta de empatia (não “simpatia”, “Empatia”). Vamos à tradução do artigo de Mark Needham

Eu recentemente esbarrei em um post interessante do meu colega Pat Kua onde ele fala sobre alguns padrões que ele notou em código poderiam ser ligados à lei de Conway, que sugere que as estruturas de sistemas desenvolvidos em organizações vão refletir a estrutura de comunicação dessa organização. (AkitaOnRails: leiam também o The Mythical Man-Month, onde o assunto de Conway também é explorado e entendam Cross Functional Teams para entender uma das soluções.)

Também recentemente li um livro chamado As Cinco Disfunções de Equipes que descreve alguns comportamentos em equipes que não funcionam de maneira efetiva.

Jogando como o advogado do diabo eu fiquei intrigado se existia algum tipo de ligação entre essas disfunções e se elas se manifestam em nosso código como anti-padrões.

As 5 disfunções são:

Inexistência de Confiança – membros da equipe não querem ser vulneráveis dentro do grupo
Medo de Conflito – equipe não consegue engajar debates honestos de idéias
Falta de Comprometimento – membros da equipe raramente se comprometem em decisões
Evitar Responsabilidade – membros da equipe não chamam a atenção de seus pares a respeito de ações/comportamentos que prejudicam a equipe
Falta de Atenção a Resultados – membros da equipe que colocam suas necessidades individuais antes daquelas da equipe

Inexistência de Confiança

Acho que ter checagens por null por todo o código é o indicador mais óbvio que as pessoas não confiam no código com que estão trabalhando.

Se a pessoa escrevendo o código tivesse fé em seus colegas que escreveram o código que ele precisa agora, acho que seria mais provável que ele confiaria que o código fará a coisa certa e não se sentiria na necessidade de ser tão defensivo.

Medo do Conflito

Medo do conflito em uma equipe parece se manifestar da maneira mais óbvia em código quando temos muitas duplicações acontecendo (síndrome do “copy & paste”) – existem diversas razões para duplicações mas acho que uma delas é quando as pessoas não estão engajadas em discussões quando eles não concordam com alguma coisa que um colega escreveu e por isso acabam escrevendo suas próprias versões de alguma coisa que já foi feita.

Isso provavelmente se manifesta de maneira ainda mais óbvia quando você acaba com múltiplos diferentes frameworks na mesma base de código e todos fazendo as mesmas coisas só porque as pessoas não querem engajar em conversações para escolher qual a equipe toda vai usar.

Falta de Comprometimento

Esse é um que parece cruzar muito com os dois anteriores, embora uma maneira específica que este se manifesta em código quando vemos erros básicos ou falta de cuidado demonstrado em código (síndrome de “fazer nas coxas”) – um exemplo disso pode ser mudar o nome da classe e então não garantir que todos os lugares onde o nome antigo era usado tenham sido atualizados.

Isso deixa o código numa situação meia-boca e torna muito difícil para as outras pessoas trabalharem e eles precisam ficar limpando as coisa antes de conseguir efetivamente fazer algum trabalho.

Evitar Responsabilidade

O anti-padrão de código que mais salta aos meus olhos é quando nós permitimos que as pessoas escrevam código sem testes e colocamos no repositório de código.

Pela minha experiência até agora isso nunca funcionou bem e eu acho que isso demonstra falta de respeito pelo resto da equipe já que não temos uma maneira simples de verificar se o código efetivamente funciona e as outras pessoas não podem usar isso em outro lugar com nenhum grau de segurança.

Falta de Atenção a Resultados

Membros da equipe colocando suas necessidades individuais antes da equipe se manifesta no código quando acabamos com código que foi escrito de tal maneira que apenas quem escreveu o código é capaz de entendê-lo.

Acho que isso se manifesta em “código esperto” que não tem problema se o projeto for só seu, mas no contexto de uma equipe é muito detrimental à medida que você se torna o gargalo quando outras pessoas querem fazer mudanças nessa área do código e não podem porque não conseguem entender o que está acontecendo.

Outra coisa que cai nesta mesma situação é quando existem convenções a serem seguidas mas decidimos sair por fora e fazer do nosso jeito. Tudo bem, algumas vezes não tem problema se estamos trabalhando para tornar o código realmente melhor e o resto da equipe sabe e concorda com isso. Caso contrário, não é algo inteligente de se fazer.

Em Resumo

Acho intrigante que em minha mente, pelo menos, alguns dos problemas que vemos em código parecem ter alguma correlação aos problemas que vemos nas equipes.

Uma coisa que eu me lembro ao ler Os Segredos de Consultoria, de Gerald Weinberg é sua afirmação de que não importa qual seja o problema, sempre é um problemas de pessoas – se de fato isso for verdade então, em teoria, problemas que vemos em código devem ser indicativos de problemas com pessoas, que eu acho que até certo ponto realmente é verdade.

Eu acho certamente que nem todo problema de código está ligado às disfunções de equipes – certamente alguns anti-padrões entram no seu código devido à inexperiência de membros da equipe, mas de qualquer forma isso também demonstraria a falta de sêniors na equipe trabalhando de forma mais próxima com seus colegas!

Talvez possamos identificar maneiras de como melhorar nossas equipes começando dando uma olhada no seu código.

Ranting

por AkitaOnRails: de fato, estou muito convencido que problemas que acontecem no código são apenas sintomas de problemas estruturais das equipes e das organizações.

Começa pela falta de respeito: quando membros da equipe vêem seu chefe (não usem “líderes” para designar chefes hierárquicos. Eles nunca são “líderes” de verdade) usando de “carteirada” para conseguir as coisas com outras equipes, entre desenvolvedores também fica uma briga de braço do tipo: “eu fiz minha parte, se o outro reclamar mando meu chefe falar com eles e pronto.” Na minha experiência, quase todos os problemas de equipes ineficientes e problemáticas é o gerente.

Gerentes que exercitam “comando-e-controle” são exatamente os tipos que devem ser execrados de uma organização. Gerentes que não confiam na equipe, que gritam, que usam de força do cargo, que insistem em ser o gargalo da comunicação, que insistem que tudo tem que passar por eles, que não tem conhecimento real – o que é notório na sua falta de capacidade de argumentação. Gerentes que não sabem dar feedback honesto e diário, pelo bem ou pelo mal, e deixam para jogar tudo na cara dos outros meses depois – que, para mim, é a maior demonstração de covardia em alguém que deveria ser um “líder”.

O Gerente que gosta de “micro-gerenciar” quando bem lhe convém, mas não explica quais são suas expectativas e cujo feedback é positivo ou negativo não de acordo com o trabalho feito, mas de acordo com seu humor em geral, o que torna as coisas muito cômodas para ele, óbvio. Os gerentes que, para parecerem que não são tão ruins, gastam seu tempo tentando fazer as outras equipes parecerem ruins: os famosos caçadores de pelo em ovo, aqueles que vão procurar os motivos triviais como horário, vestimenta, pequenas conversas, e coisas desse tipo como desculpas para falar mal, em vez de resultados reais como lucro, custo, etc.

Se você está realmente preocupado em porque suas equipes não estão performando como deveriam, olhe para a camada de gerentes. Especialmente, ou principalmente, aqueles que estão há muitos anos na mesma organização. Viciados, que já conhecem todos os “jeitinhos” da organização. Eles são perigosos: sorriem para todo mundo, parecem confiantes, parecem eficientes, a maioria dos seus subordinados o elogiam (porque estão sob efeito de coerção, obviamente).

A equipe reflete o sistema e a estrutura que lhes é colocado sobre eles. Tire-lhes a autonomia, trate-os como crianças, deixe-os confusos e com medo e é exatamente esse o resultado que você vai ter: trabalho mal feito, de má qualidade, que dá defeitos o tempo todo, que custa caro. Alguns acham que isso é exagero, especialmente diretoria alheia e pouco participativa (qualquer coisa diferente de ‘todos os dias’ não é participação) ao que acontece no chão de fábrica, eles ficam surpresos ao ver que seus funcionários se tornaram não somente estagnados, incompetentes, obsoletos mas também distantes e despreocupados com o futuro da organização. A única coisa que os preocupa nesse momento, são seus empregos.

Enquanto isso, os tais “gerentes”, continuam em situações confortáveis: quando as coisas – por sorte, e apenas sorte – dão certo, recebem os louros. Quando as coisas dão errado a culpa é de membros da equipe que eles já iam dar um jeito mesmo, ou a culpa é de outras equipes, a culpa é da organização inteira que não o ajudou, a culpa é das decisões históricas que agora não tem mais jeito. Mas a culpa nunca é dele mesmo. Lembrem-se: anos de casa não pode significar imunidade. Anos de casa deve ser irrelevante se a intenção da organização é ser eficiente. E não se preocupe em mandar um gerente desses embora com o medo “mas só ele sabe como fazer as coisas”; as “coisas” não vão desandar, confie nas equipes, devolva-lhes a autonomia, elas saberão o que fazer.

Portanto, sim, a grande maioria das disfunções de uma equipe é resultado direto das disfunções de sua organização. Não adianta tentar aplicar técnicas localizadas como pregar pair programming, test driven development, refactoring, etc se a organização permanece a mesma. Quer mudar? Mude tudo. Ou nem se dê ao trabalho.

[Off-Topic] Se quiser melhorar a cultura, 20 expressões a se evitar

Sat, 30 May 2009 23:28:57 PDT

Do blog de Jason Yip

Fonte: 40 anos, 20 milhões de idéias: The Toyota Suggestion System

Todo mundo entende isso!
Nunca fizemos isso antes, não vale a pena tentar.
Eu tentei isso antes, e eu sei que não funciona.
Isso não é atualizado o suficiente.
Isso está dentro do orçamento?
Tem planos demais sendo feitos—vou pensar na sua opinião quando tiver tempo
Vamos falar disso outra hora.
Vamos esperar mais um pouco e ver como as coisas ficam.
Por que você quer mudar? As coisas não estão indo bem agora?
Existem regras, então não é bom fazer as coisas desse jeito.
Eu não acho que isso seja tecnicamente possível.
Essa idéia está muito fora, o gerente nunca vai concordar.
Essas coisas não se fazem nesta empresa!
Isso pode funcionar em outros lugares, mas não aqui!
O mundo real é mais complicado que isso.
Você não entende realmente a situação, não é?
Sua sugestão é boa, mas a empresa não pode bancá-la.
Isso vai criar problemas mais para frente.
Mesmo que eu te dê conselhos, ainda assim não vai dar.
Que sugestão é essa? Não dá para torná-la um pouco melhor?

AkitaOnRails: relembrei isso depois de ter conversado com o Juan Bernabó recentemente: “insanidade é querer resultados diferentes fazendo as mesmas coisas.”

Ward Cunningham: Um amador diz “eu só faço as coisas do meu jeito.” Um profissional deve ser capaz de dizer “vamos tentar do seu jeito por um tempo e ver o que acontece.”

Campanha: Ajude o One-Click Ruby Installer

Thu, 21 May 2009 03:58:16 PDT

Eu tenho tentado, na medida do possível- windows-part-2, ajudar a crescente comunidade rubista que, por diversas razões, vivem em um mundo Windows.

Infelizmente, existem muito poucos desenvolvedores – incluindo dentro da própria comunidade Windows – ajudando nisso. Atualmente existe um Ruby estável e usável em produção no Windows graças ao esforço, quase individual, do Luis Lavena, o argentino que mantém o excelente projeto One-Click Ruby Installer

Porém ele precisa de ajuda. Por isso ele começou uma campanha para angariar fundos ou qualquer tipo de colaboração para melhorar a visibilidade do projeto, criando um novo website, um novo wiki e ele começou primeiro no blog dele, depois na lista ruby-talk# e, finalmente, numa página para doações que você pode acessar por aqui

Vamos ajudar, twite sobre a campanha, espalhem por blogs, doem. Nenhuma quantia é pequena demais.

Promoção Ruby Learning: Ganhe o Livro do Urubatan

Sun, 17 May 2009 21:07:26 PDT

O bom e velho RubyLearning.org, um dos mais antigos cursos de Ruby online está com promoções para ganhar livros. No caso, você pode concorrer ao livro Desenvolvimento Fácil e Rápido de Aplicações Web do nosso amigo Rodrigo Urubatan.

A idéia é criar uma maior interação nos fóruns com os autores dos livros em promoção. Quem o autor achar que está fazendo mais interações relevantes irá ganhar o livro.

A promoção do livro do Urubatan corre a partir do dia 19 agora até o dia 21. Não deixem de participar. Para isso cadastrem-se neste link com a chave (enrollment key) BPCE101.

RailsConf 09 - Ninh Grosenbach Bui

Sun, 10 May 2009 23:12:03 PDT

RailsConf is not your “normal” tech conference. You will have people ranting, doing real rocket-science and lot’s of people having real and genuine fun. We are very lucky to have people such as Geoffrey Grosenbach, Jason Seifer, Peter Cooper, Ninh Bui and so much more to remind us that there is an upper layer to technology: geeks love to have fun.

RailsConf 2009 – Ninh Grosenbach Bui from Fabio Akita on Vimeo.

And don’t miss the awesome Rubystein, Phusion’s reimplementation of Wolsfenstein 3D in Ruby. They wanted to prove that Ruby is fast enough even to write games on it, and they succeeded in spades!

A RailsConf não é sua conferência “normal” de tecnologia. Você verá pessoas reclamando, fazendo coisas realmente avançadas e muitas pessoas genuinamente se divertindo. Somos muito afortunados em ter pessoas como Geoffrey Grosenbach, Jason Seifer, Peter Cooper, Ninh Bui e tantos outros para nos lembrar que existe uma camada ainda acima da tecnologia: geeks adoram se divertir.

RailsConf 09 - Message from Bryan Liles (TATFT) to Brazil

Fri, 08 May 2009 04:26:35 PDT

Bryan Liles’ Test All The Fucking Time video really struck a cord and people have been repeating his motto ever since. He was so kind to send a message to the Brazilian programmers as well, check it out:

RailsConf 2009 – Mensagem de Bryan Liles para Brasileiros from Fabio Akita on Vimeo.

O vídeo do Bryan Liles, Test All The Fucking Time realmente tocou num ponto importante e as pessoas vem repetindo seu lema desde então. Ele foi muito legal em enviar uma mensagem aos programadores Brasileiros, dêem uma olhada ;-)

RailsConf 09 - Exclusive Audio Interviews

Fri, 08 May 2009 04:07:01 PDT

I’ve had a great time interviewing several interesting Rubysts and Railers on their new projects. I think you will like to hear what they have to say.

My first guest was Joshua Timberman. He is a fervorous evangelist for the Chef project. Chef could be seen as a more modern Puppet, which by itself, already is a modern systems configuration manager. Chef is composed of several pieces, cookbooks and details that Joshua explains in his interview.

Download (22:24)

One project that I am particularly very interested is Spree. Sean Schofield started this Rails based e-commerce system to support developers that had to reinvent the wheel all the time, and e-commerce systems are notoriously not easy to do. Spree is a fairly complete project, with many nice features, including integration with ActiveMerchant, shipping support, tax categories and so on. I helped a bit doing the Brazilian Portuguese internationalization of the project as well. Highly recommended.

Download (22:15)

By now I think we all know New Relic, Fiveruns and Rails monitoring systems. But there are more competition coming up, from the guys of Highgroove Studios we have Scout a non-nonsense approach to Rails monitoring and data analysis. They are willing to go an step further: instead of just presenting raw data as reports, they are analyzing this data and giving you relevant recommendations so you can further optimize your application. And more than that: they are highly competitive in price. And the client agent that gathers data and send to their servers is open source and extensible through plugins, so you can add even more to what they already offer. Definitely worth checking out:

Download (13:43)

At RailsConf 2008, last year, I interviewed James Lindenbaum about Heroku. They were still in beta at that time. Now they finally released a commercial version with lots of new features. I was particularly surprised to find Ryan Tomayko at their booth, working for Heroku. I think Heroku really nailed easy deployment for Ruby applications over Amazon EC2. If you don’t want to worry about infrastructure, Heroku may be the answer:

Download (33:49)

Again, last year, everybody was blown away by the announcement of Gemstone – traditional Smalltalk software-house – showing a very preview version of Ruby actually running over a very mature Smalltalk VM. This is the Maglev project. Since then the development has been quite secretive. But they are finally disclosing more and more information on how the project is going. This year, they were able to show a small Sinatra application already running – albeit, with some tweaks. I think they are evolving very fast. Ruby is notoriously not an easy language to implement and Maglev will be incredible when released. In this interview we have Monty Williams, Peter McLain and Michael Latta discussing about the current development and future roadmap.

Download (36:42)

Finally, I think everybody knows Ilya Grigorik by now, from igvita.com. He received last year’s Ruby Hero Awards, and it was well deserved. He is one of the few developers that can tackle very advanced subjects in a way that anyone can understand. He started a new company recently and they have a very very interesting product called PostRank. The overall idea is fairly simple: they went a step further over Google’s own PageRank system. Instead of just considering link tracebacks, they now weigh in social network behavior. For example, a single Digg page traces back to a website with just one link. But this same page at Digg can have something like hundreds of comments, or “engagements” as Ilya calls it. This gives a totally different weigh to this traceback instead of just a simple link. So companies are starting to pay attention to social networks such as Digg, Reddit, Twitter and others and now Ilya comes up with the tool to deliver them the necessary metrics. I highly recommend you to test-drive this site, I think you will be impressed.

Download (21:43)

And this wraps up my series of interviews at RailsConf 2009. I wish I had more time to interview more people. There were very insightful and smart developers there, and I would have to git clone myself many times to be able to talk to all of them. I hope you enjoy this set of interviews.

RailsConf 09 - Message from Peter Cooper to Ruby Inside Brazil

Fri, 08 May 2009 03:11:19 PDT

Maybe not everybody knows it but the well known Ruby Inside website now has a new branch in Brazil. It was recently released and we have a bunch of highly motivated Railers that are doing a great work posting everything that is news in the Ruby and Rails world both in Brazil and in other countries. Check it out Peter Cooper’s take on this:

RailsConf 2009 – Peter Cooper from Fabio Akita on Vimeo.

Talvez nem todos saibam, but o bem conhecido site Ruby Inside agora tem uma nova filial no Brasil. Eles iniciaram recentemente e tem uma equipe de Railers muito motivados que estão fazendo um grande trabalho publicando notícias do mundo Ruby e Rails tanto do Brasil quanto de outros países. Dêem uma olhada na opinião do Peter Cooper sobre isso.