Adolfo Sousa

Na última semana, eu e mais três Locawebers (Antônio Marques, Fernando Amorim e Nando Vieira) estivemos em Baltimore para a Railsconf 2010. Com mais de 1000 participantes, incluindo grandes expoentes de importantes comunidades de software, é a maior conferência de Ruby on Rails do mundo.

Durante os 4 dias do evento, muitas palestras aconteceram. Mais importante do que escrever sobre cada uma delas, é falar um pouco sobre algumas novidades e sobre o que mais me impressionou na conferência:

• Rails 3 - talvez a maior expectativa da comunidade fosse o anúncio do lançamento do Rails 3. Ela não foi completamente atendida, porém foi lançada a versão beta 4 do framework. Adicionalmente, Gregg Pollack anunciou uma série de screencasts explicando as novidades da versão 3. Vale a pena conferir: http://rubyonrails.org/screencasts/rails3/

• Keynotes - fiquei impressionado com a quantidade e com a qualidade da grande maioria deles. Destaque para a apresentação do Yehuda Katz sobre “fazer”, dando dicas de como contribuir para projetos open source (http://en.oreilly.com/rails2010/public/schedule/detail/14132). Acredito que todos os keynotes podem ser encontrados no site oficial do evento: www.railsconf.com

• Palestras - assisti a algumas palestras ruins, algumas boas e outras excelentes. Entre as melhores a que assisti, estão as seguintes:

- Rocket Fueled Cucumbers: sobre como escalar testes de aceitação. A apresentação foi muito bem preparada e todas as ferramentas e dicas dadas pelo Joseph Wilk foram pertinentes. Vocês podem conferir os slides aqui e a gravação da mesma palestra apresentada na Scottish Ruby aqui

- Ruby on Rails Tasty Burgers: sobre os componentes, as diversas partes que formam o Rails. Aaron deu uma palestra muito divertida, didática e informativa. Além da excelente palestra, ele também recebeu um Ruby Hero Award

- Making Rails Really RESTful with Restfulie: quase que diariamente em listas ou em conversas, e também durante a conferência, vejo muita gente com conceitos incompletos ou equivocados a respeito de Rest. Sem dúvida, um dos desafios de quem defende e luta pela adoção deste estilo arquitetural é acabar com estes equívocos; foi um pouco do que fez o Fábio Akita. Além de explicar muito bem alguns conceitos, ele mostrou o que no Rails está e o que não está de acordo com as definições de Rest. Ele também falou um pouco sobre o projeto Restfulie (http://restfulie.caelumobjects.com/), uma excelente e inovadora iniciativa tocada principalmente pelo Guilherme Silveira da Caelum

• Birds of a Feather - as BOF na RailsConf acontecem todos os dias, durante o dia todo. O valor de conversar e programar com as pessoas que desenvolvem importantes projetos é impagável. Elas estavam lá o tempo todo e dispostas a conversar e mostrar o seu trabalho. Admirável.

• A comunidade Brasileira - na minha opinião, a força e importância da nossa comunidade está sendo reconhecida e valorizada pelo mundo inteiro. Por exemplo: o Fábio Akita deu uma das melhores e mais elogiadas palestras da conferência. O Guilherme Silveira e o Cauê Guerra fizeram um BOF a respeito do Restfulie e pudemos perceber que o projeto é o que há de mais avançado e inovador no assunto. Muitas pessoas vinham conversar com o George Guimarães da PlataformaTec sobre o Devise. Um dos palestrantes mostrou e elogiou umas das muitas gems criadas pelo Nando Vieira, nosso colega aqui da Locaweb. Muitas pessoas vinham falar conosco da Locaweb sobre o Rails Summit e sobre a comunidade Rails no Brasil. E, pra terminar, o José Valim foi um dos Ruby Heroes deste ano. Muito bom, não?

Há alguns meses, resolvi que aprenderia a utilizar alguma outra IDE diferente do Eclipse. Como muitos programadores imersos no mundo Java, eu estava encantado com Ruby e Ruby on Rails e a tendência natural nesta comunidade é utilizar o excelente Textmate. Paguei a licença de 1 ano pra macromates mas não estava confortável porque sabia que no próximo ano teria que desembolsar outros USD 60 ou piratear o software. Minha saída foi buscar alternativas gratuitas. Cheguei a brincar com o VIM por 2 dias e achei fantástico. Entretanto, estava lendo o SICP e uma velha vontade de conhecer o mítico Emacs não me deixava em paz. Resolvi atender minha vontade e dar uma espiada nele. Fiquei apaixonado pelas possibilidades de customização e criação de funcionalidades que esta fantástica ferramenta proporciona, por elisp e também pela produtividade que você ganha quando aprende a se virar sem o mouse.

O Começo

Comecei assistindo ao “Meet Emacs” da PeepCode. Ali aprendi rapidamente o básico e usei como configuração o emacs-starter-kit. Não demorei muito pra querer customizar algumas coisas e, depois de apanhar bastante por conta da bagunça do starter-kit, tomei a decisão de começar o meu projeto de configuração do zero, pegando do starter-kit somente aquilo que me interessava. Foi uma bela diversão. Gastei alguns dias brincando com elisp e terminei com todas as customizações que queria mas com um projeto também bagunçado.

Analisando em retrospectiva, acho que esse seja um bom caminho pra aprender e começar a mexer no Emacs:

1. Copie as configurações de alguém que você conheça ou acompanhe
2. Use uma colinha pra não ficar travado. Eu gosto bastante desta aqui
3. Use por um tempo até ter uma pequena lista das coisas que você quer mudar
4. Pegue um item por vez e customize à sua maneira
5. Crie um projeto com as suas configurações

As Minhas Configurações

Como disse anteriormente, cheguei a ter as minhas configurações guardadas num projeto bem bagunçado. Toda vez que precisava customizar ou adicionar um novo plugin ficava um pouco perdido e, às vezes, outra coisa parava de funcionar. Programador nenhum consegue viver com isso, então resolvi fazer uma grande refatoração no meu projeto (você pode acompanhar os meus commits e ver que na verdade foi uma reescrita).

Hoje, estou satisfeito como meu projeto. Ele está organizado, funcionando, elegante, tem a instalação automatizada e é extremamente fácil adicionar um plugin ou alterar alguma configuração. Se quiser utilizá-lo de alguma forma, o projeto está aqui:

http://github.com/adolfosousa/emacs-config

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas” a se conhecer: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software e, consequentemente, qualidade de maneiras bem distintas.

Para os adeptos das metodologias tradicionais, que encaram o processo como uma cascata (primeiro alguém tem a visão do produto, depois algumas pessoas especificam o software, outras implementam, umas outras testam, a próxima coloca tudo isto em produção de uma vez para que então uma outra equipe não possa manter o software vivo, gerando algum tipo de valor), o conceito de qualidade se assemelha ao usado em processos de produção industrial: conformidade com requerimentos definidos na fase de design ou em alguma “receita”. A palavra chave que define qualidade neste cenário é conformidade. Espera-se que haja uma pré-definição clara do que é qualidade, do que é esperado, e se o software estiver “conforme” é possível dizer que o usuário dele estará lidando com um software de qualidade. Como é possível notar, variabilidade e diversificação não são desejáveis aqui.

Já os adeptos das metodologias ágeis tendem a enxergar qualidade de forma parecida com a qual prestadores de serviços a enxergam. O cliente de um software não sabe o que é ou não está preocupado com a qualidade, pelo menos não de uma forma definida, exata e clara. Ele pode estar em busca uma boa experiência ou esperando que o software lhe ajude a resolver algum problema. Talvez queira que o sistema lhe entregue algum valor mas também pode ser que diversão ou experimentação/inovação sejam o seu fim. Aqui, nenhum requerimento, documento ou receita definida previamente serve para atestar a qualidade do software. Então se não podemos definir, quer dizer que não há qualidade? De forma alguma. Neste cenário, qualidade não precisa ser exata, imutável, não precisa ter uma definição clara, não é possível lhe darmos um nome. O que buscamos, na verdade, é Qualidade Sem Nome, ou QWAN (Quality Without a Name).

Neste contexto, em que tratamos qualidade de forma não determinística, em que as expectativas mudam de usuário para usuário, alguns cuidados devem ser tomados para que, quando perguntarmos a um deles se determinado software tem qualidade, tenhamos como resposta algo do tipo: “hum, deixe-me ver… eu sinto que sim. Ele me ajuda, gosto dele, sinto confiança, ele é, como posso dizer, consistente”. Tarefa difícil, não? Difícil porém possível se entendermos dois conceitos extremamente importantes [1]:

1. Integridade Percebida - o produto como um todo alcança um equilíbrio entre funcionalidades, usabilidade, confiabilidade e economia que agrada os clientes.
2. Integridade Conceitual - os conceitos e partes centrais do sistema trabalham harmonicamente, de forma coesa, como um todo. Os componentes ou módulos se integram e trabalham bem conjuntamente.

Como você pôde notar, a Integridade Percebida e a Conceitual estão intimamente ligadas e têm papel fundamental na qualidade do software desenvolvido. Por esta razão, vou dedicar o próximo post desta série para discuti-las mais a fundo.

Até a próxima.

[1] - Os conceitos de Integridade Percebida e Integridade Conceitual foram extraídos do excelente livro Lean Software Development - An Agile Toolkit da Mary e do Tom Poppendieck. Eles, por sua vez, adaptaram os conceitos de “Internal Integrity” e “External Integrity” contidos no livro Product Development Performance de Kim Clark e Takahiro Fujimoto

Qualidade de software é um assunto pouco discutido por nós, profissionais da área. Já ouvi repetidas vezes o argumento de que este fenômeno acontece porque se trata de uma “indústria” ainda muito nova. Pode ser nova se comparada com outras como a têxtil ou a automobilística. Entretanto, não podemos aceitar argumentos conformistas como este e nem tampouco encarar desenvolvimento de software como indústria, sob pena de nos colocarmos num ambiente pouco adaptável, repetitível, prescritivo e de inovação lenta e cara. Não acredito que esta seja a natureza dos projetos de software.

Independentemente da maturidade deste nosso ofício, ou melhor, arte, qualidade deve fazer parte do seu processo de desenvolvimento e, portanto, não há motivo algum para não discuti-la com a mesma frequência que discutimos outros assuntos como linguagens, frameworks, metodologias, arquiteturas, etc.

Pretendo iniciar uma série de posts para falar de qualidade de software. Sejam bem-vindos e sintam-se livres para fazer parte da discussão.

—————

Parte 2 - http://www.adolfosousa.com.br/blog/2010/02/10/o-que-e-qualidade-de-software/

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

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.

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:

• http://www.pomodorotechnique.com/
• http://www.infoq.com/news/2009/09/Pomodoro

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.

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.

É 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!

http://www.rgalen.com/publications.html