Esqueçam o que eu disse: o RVM é melhor
Sei que parece coisa de ex-presidente mas é isto mesmo: por favor, desconsiderem o que eu disse no post anterior.
Depois do comentário do Levy, resolvi instalar o RVM (Ruby Version Manager). Passei o comecinho da noite brincando com ele e realmente é uma opção melhor do que a proposta inicialmente.
Eu tinha a preocupação de ser obrigado a fazer alterações grandes e complicadas no meu bash_profile ou bashrc. Entretanto, a instalação do RVM se mostrou extremamente simples:
Com a ferramenta instalada, é necessário somente adicionar o seguinte ao bash_profile:
A partir de agora, qualquer novo terminal bash (ou zsh) que você abrir terá acesso ao RVM. E para saber como instalar as versões do Ruby ou alternar entre elas:
O projeto está no Github, caso queiram dar uma olhada http://github.com/wayneeseguin/rvm
Mais de uma versão do Ruby no Snow Leopard
Explorar a versão mais recente de um framework ou linguagem é prática comum entre programadores que têm paixão pela sua arte. E este simples gosto pela experimentação exige que tenhamos uma maneira prática e rápida para alternar entre o bleeding edge e outras versões que utilizamos nos nossos projetos. Vou mostrar aqui uma maneira de manter várias versões do Ruby no Snow Leopard (MacOS 10.6.2). A mesma abordagem funciona para o Leopard (MacOS 10.5.8).
O Snow Leopard já vem com o Ruby 1.8.7 instalado em /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr. O meu objetivo é poder alternar facilmente entre o Ruby 1.8.7 e o Ruby 1.9.1. Para tanto, me falta a versão mais nova do Ruby:
Resumidamente, baixamos, descompactamos e configuramos o Ruby 1.9 pra ser instalado na pasta /usr/local/ruby-1.9.1. Para efetivamento instalá-lo na pasta configurada, basta fazer o seguinte:
A execução do comando abaixo indica que já temos o Ruby 1.9.1 instalado e funcionando:
O próximo passo é destruir os links para o Ruby que o Snow Leopard guarda em /usr/bin/
Agora, precisamos criar um link em /usr/local
E depois colocar o nosso novo link no path:
E para alternar facilmente entre as versões existentes, costumo criar aliases que redirecionam o link /usr/local/ruby para a versão que eu desejo utilizar
O resultado:
Esta é somente a forma com que eu lido com o problema de ter mais de uma versão de uma linguagem no meu ambiente de trabalho. Podem existir outras, mas gosto da praticidade e do controle que ganho com esta abordagem.
Técnica Pomodoro
No dia 15/08/2009 nós realizamos na Locaweb o nosso quarto Tech Day. Gostamos de um formato que obriga que as palestras não tenham mais do que 25 minutos. Mas o que isto tem a ver com a Técnica Pomodoro (The Pomodoro Technique)? Bem, neste último evento eu fiz uma rápida palestra sobre esta técnica de gerenciamento do tempo. Eu sei que preciso melhorar minhas apresentações em público, mas o vídeo é útil como uma introdução à técnica.
Hoje é dia de pomodoro from Locaweb on Vimeo.
Pra quem ficou curioso, seguem as principais referências:
Sem repetições
Há uns 2 meses, meu amigo Saroka e eu preparamos uma apresentação para falar de automatização de tarefas. Falamos para um público técnico da Locaweb sobre algumas melhorias que estamos realizando no nosso processo de deploy.
Achei legal registrar aqui pra me lembrar que sempre dá pra automatizar alguma coisa. Toda vez que rodo uma task e economizo meu tempo e paciência, lembro de que é muito bom deixar de fazer tarefas repetitivas. Um ótimo post sobre o assunto foi escrito pelo ‘louco por automatização‘ Guilherme Chapiewski.
Pra quem quiser ver a nossa apresentação no 3o. Locaweb Tech Day, segue um link para o vídeo.
Locaweb - Automatizando suas tarefas usando Capistrano from Locaweb on Vimeo.
E o manifesto ágil, meu caro CSP
Já faz algum tempo que não tenho tanta paciência para ficar discutindo metodologias ágeis para desenvolvimento de software. A minha cabeça de alguma forma passou a pensar que tudo se resume a aplicar bem o manifesto ágil. E isto, por si só, não é nada fácil. Exige muita disciplina, capacidade, atenção e profissionalismo. Nenhuma metodologia, ferramenta ou gerente vai resolver o real problema do nosso mercado: escrever software útil e de qualidade.
Danem-se os selos CMMI, as certificações do PMI e da Scrum Alliance, os programadores que enchem currículos de siglas e código de sujeira. O que vai resolver o nosso problema é gente competente, disciplinada (no sentido dado pelo Uncle Bob no seu keynote da RailsConf), capaz de ouvir o cliente e criar uma relação verdadeira de parceria com ele, com características para evoluir constantemente. Se você ou a sua empresa são capazes de fazer isso bem, não se preocupe em dar um nome para os métodos que você usa para fazer o seu trabalho. É feio sair por aí dizendo que aplica scrum (ou qualquer outra coisa da moda), encher o bolso de dinheiro e se esquecer os princípios básicos do manifesto ágil.
Esta introdução longa é para desabafar a raiva acumulada pelo monte de besteiras que eu ouvi em algumas palestras no Scrum Gathering 2009. Muita gente já escreveu e/ou tocou em pontos polêmicos sobre o evento. Quero dar os meus pitacos, então vamos ao que mais me irritou naqueles dois dias:
- Times auto-gerenciáveis - pelo menos 2 palestrantes (Ricardo Vargas e Fábio Câmara) afirmaram categoricamente que nunca viram um time capaz de se gerenciar. E somente isso. Não contaram alguma experiência ou analisaram o motivo pelo qual isso é impossível no ambiente deles. Este é um assunto muito interessante e qualquer discussão é válida.
- Ken Schwaber - imagine que você vai ter uma aula de futebol com o Ronaldinho Gaúcho e o cara gasta o tempo falando que no futebol a bola é redonda, os times têm 11 jogadores, o objetivo é fazer o maior número de gols, etc, etc, etc. Pois é, assim foi a palestra de um dos criadores do scrum. O sujeito ficou quase uma hora falando o básico e o óbvio, fez uma brincadeira mais do que manjada para falar de “comando e controle” versus “times auto-gerenciáveis” e finalizou anunciando que a Scrum Alliance vai lançar o treinamento para CSD (Certified Scrum Developer) e que este vai ser baseado em ferramentas da Microsoft. Precisa falar mais alguma coisa?
- Fábio Câmara - a palestra do Fábio foi a mais polêmica, ainda mais sabendo que ele é um CSP (Certified Scrum Practitioner). Li o título “Usando scrum com o Visual Studio Team System” e fiquei curioso para saber o que faz alguém precisar tanto de uma ferramenta para usar scrum. No meio da palestra o Fábio algumas afirmações, dentre elas: “eu questiono o uso de testes, principalmente os unitários, em projetos time-driven”; “eu tinha um estagiário que eu chamava de controller porque ele ia todo dia de manhã de mesa em mesa perguntando para o desenvolvedor se ele estava fazendo a tarefa que ele deveria estar fazendo. O VSTS me diz isso, uma vez que ele cria um link entre o requisito e o pedaço de código que foi escrito para atender aquele requisito. Eu também consigo saber quem escreveu cada linha, porque quando você pergunta numa sala ‘quem escreveu essa linha aqui?’ fica todo mundo assobiando”; “é incrível como o princípio de pareto se aplica em quase todos os projetos de software. 20% das pessoas fazem 80% do trabalho”; “os desenvolvedores, no final do dia de trabalho, fazem check-in do que eles produziram. No VSTS eu consigo ver cada check-in e passar a mão no telefone pra perguntar por cara lá em Recife porque ele subiu só 25 linhas de código quando a média dele era de umas 200″; “o scrum master e responsável por distribuir as tarefas para o time”. Logicamente algumas pessoas começaram a questionar tudo isso e ele descreveu um cenário para ‘justificar’ tudo isso: “imagine uma equipe grande. Eu já gerenciei equipes com 60 pessoas, algumas trabalhando em outros estados, etc …”. As minhas sugestões para o Fábio são as seguintes: 1) demita umas 50 pessoas da sua equipe (olha o problema do princípio de pareto sendo resolvido) e forme um time com os 20% que fazem 80% do trabalho e no qual você possa confiar e não controlar (opa, pode mandar o controller embora também). Pare de procurar culpados, isso não resolve nada, é desperdício. Se alguém fez alguma coisa errada no código, esse alguém foi o time e ele mesmo resolve (você já deve ter ouvido falar de propriedade coletiva do código e programação em par). Você não vai precisar ficar bancando o detetive pra descobrir quem foi o infeliz que escreveu a linha 1567 da classe XXXX ou bancando o leão-de-chácara do repositório. Deixe os seus programadores escreverem muitos testes e automatizá-los. 2) se vocês estão sem tempo para escrever os testes, peça a colaboração do seu cliente; explique que o time precisa escrever testes para entregar um produto de qualidade, trabalhem com ele na priorização das histórias, mostre as vantagens de desenvolver um produto iterativamente, melhorando continuamente, respondendo às mudanças. 3) pare de valorizar mais o Visual Studio do que a sua equipe. 4) nunca, jamais, de forma alguma, esqueça do manifesto ágil 5) e, POR FAVOR, pare de falar que o que você está fazendo é scrum.
Na minha opinião, o evento contou com palestras muito boas (Juan Bernabó, Alexandre Magno e Luiz Cláudio Parzianello), mas estes 3 fatos citados bastaram para fazer do Scrum Gathering 2009 - Brazil e da Scrum Alliance um baita fiasco.
Becoming a Great Scrum Product Owner
É bem provável que aqueles que se interessam por metodologias ágeis de desenvolvimento já leram (ou ao menos ouviram falar) do livro Scrum & XP from the Trenches. Ele é um excelente relato da experiência prática de Henrik Kniberg com estas duas metodologias. Inspirado pela idéia de Henrik, Bob Galen disponibilizou um “rascunho” do seu livro Becoming a Great Scrum Product Owner.
Mais uma fonte para quem se interessa pelo papel de PO do Scrum e sente falta de referências na literatura especializada. Aproveitem!
Ano novo, novos e antigos planos
2009 está aí e nada melhor do que começar o ano com um planejamento bacana. Aí está o meu:
Créditos - Eu usei o FreeMind pra desenhar o meu mapa mental.
De Advogados e Open Source
Eu sou um programador. Talvez nenhuma outra categoria profissional se beneficie tanto do trabalho alheio quanto a nossa. Os benefícios a que me refiro não precisam ser tão claros e diretos como dar um pé no Windows e usar uma distribuição Linux totalmente grátis. Há outros, muito importantes embora não tão evidentes, como ter liberdade para usar linguagens e frameworks escritos por pessoas que resolvem compartilhar o seu trabalho com o mundo, sem cobrar por tudo o que fazem. Além de usar, nós podemos aprender porque muitos e excelentes programadores fazem software open source, ou seja, qualquer pessoa pode baixar o código escrito, aprimorá-lo, usá-lo e aprender com ele. Como se não bastasse, participamos de fóruns e nos organizamos em grupos para nos ajudar e trocar experiências.
Por considerar tudo isto de extremo valor para o crescimento das pessoas e também da nossa comunidade, às vezes penso no que os profissionais de outras áreas fazem ou poderiam fazer para se ajudar e aprender uns com os outros. Já pensou se algum bom advogado, depois de sair do seu escritório, tocasse um processo para reduzir 1/7 valor do IPVA dos veículos da cidade de São Paulo (já que somos proibidos de usar o carro em 1 dos 7 dias da semana, não seria justo pagarmos somente 6/7 do IPVA?) ou dar aos usuários do transporte público desta metrópole maluca o direito de não pagar para se amassar num ônibus lotado (eu não acho justo pagar para andar em linhas completamente lotadas, em carros sujos, com motoristas loucos e, às vezes, ainda ter que esperar por uma destas latas de sardinha por quase 1 hora).
Sou realmente leigo nesta matéria de leis e talvez seja uma idéia absurda ou impraticável, mas se eu fosse um advogado gostaria de ter um projeto destes. Me sentiria orgulhoso de ganhar um processo, oferecer esta jurisprudência a outras pessoas, praticar e aprender coisas referentes a minha profissão e ainda poder compartilhar com os meus pares todos os detalhes do meu trabalho. Será que existe alguma desvantagem em ser um “advogado open source”?
Review - Why´s Poignant Guide to Ruby
Acabo de ler o Why´s Poignant Guide to Ruby e só posso dizer uma coisa: o cara é maluco!
Pra quem nunca ouviu falar, o “Poignant Guide” é um livro de introdução à linguagem Ruby escrito por um sujeito misterioso conhecido como Why The Lucky Stiff. É um excelente material para quem está querendo aprender esta linguagem. O livro é divertido, cheio de histórias malucas e engraçadas, tirinhas com personagens doidos e mais um monte de exemplos e explicações muito bons.
Se você se interessar e quiser estudar por ele, precisa saber que não é um livro muito fácil de se ler em inglês. O autor utiliza muitas gírias, expressões idiomáticas, etc. Se o seu inglês ainda não estiver afiado, tem uma galera fazendo uma tradução pro português.
Pra resumir: se você está estudando e/ou se interessa por Ruby, deve ler o livro.
Vamos traduzir os Rails Guides?
Estava consultando as novidades no meu leitor RSS quando vi um post no blog do Cássio Marques. Ele estava fazendo uma chamada para traduzir os “Rails Guides”. Como eu não conhecia os guias, resolvi dar uma olhada e, pelo pouco que vi, achei o material muito bom. Fiquei empolgado com a iniciativa e resolvi ajudar. Comecei anteontem a contribuir com a tradução do “Getting Started With Rails”.
Você pode estar se perguntando “mas por que você vai traduzir um material para um público que tem obrigação de saber inglês?” Ora, simplesmente porque eu estou estudando a dupla Ruby/Rails e também porque tem gente na nossa área que realmente não sabe inglês suficiente para ler os guias. Embora acredite que para nós programadores o domínio desta língua é fundamental, entendo que muita gente talentosa nunca teve acesso ao ensino decente de inglês na escola ou em cursos particulares. Se é bom para mim e pode ser útil para todos, por que não fazer?
Se interessou? Quer ajudar? Vá ao post do Cássio e encontre mais informações: