Adolfo Sousa

May 22, 2009

Sem repetições

Filed under: automatização, ruby — Tags: , — Adolfo Sousa @ 10:11 pm

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.

May 19, 2009

E o manifesto ágil, meu caro CSP

Filed under: agile, carreira, eventos, scrum — Tags: , , , — Adolfo Sousa @ 1:28 am

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.

January 16, 2009

Becoming a Great Scrum Product Owner

Filed under: agile, livros, scrum — Tags: , , — Adolfo Sousa @ 10:24 am

É 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

January 2, 2009

Ano novo, novos e antigos planos

Filed under: carreira, geral, livros, open source, ruby, ruby on rails — Tags: , , , — Adolfo Sousa @ 2:59 pm

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.

December 1, 2008

De Advogados e Open Source

Filed under: carreira, open source — Tags: , — Adolfo Sousa @ 9:50 pm

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

November 25, 2008

Review - Why´s Poignant Guide to Ruby

Filed under: livros, ruby — Tags: , — Adolfo Sousa @ 9:13 pm

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.

November 19, 2008

Vamos traduzir os Rails Guides?

Filed under: open source, ruby on rails — Tags: , — Adolfo Sousa @ 9:23 am

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:

http://cassiomarques.wordpress.com/2008/11/14/convocacao-vamos-traduzir-os-rails-guides-para-portugues/

November 11, 2008

Minha trilha no Rails Summit 2008

Filed under: agile, eventos, rails summit, ruby on rails — Tags: , , , — Adolfo Sousa @ 11:46 am

Além da excelente palestra do Obie Fernandez, eu assisti a outras memoráveis apresentações no Rails Summit 2008. Aqui vai a trilha que segui no evento e o que mais me impressionou em cada uma delas:

  • David Heinemeier Hansson (DHH) - O criador do Rails participou do evento respondendo a perguntas da platéia por vídeo-conferência. A meu ver, a pergunta mais interessante foi a respeito de como a equipe que mantém o framework lida com as sugestões de novas features. A resposta pode ser interpretada como “nós respiramos Lean”; DHH contou que eles simplesmente incorporam ou implementam somente o que o framework necessita e se faz prioritário. Se não é necessário naquele momento, não fará parte do Rails, não importando se está na moda ou qualquer outra coisa.
  • Chad Fowler - o escritor de “My job went to India” fez uma palestra muito motivadora. Com o título “Being Remarkable”, Chad deu dicas sobre como nós, desenvolvedores de software, podemos nos destacar. Dentre as dicas, gostei das “machuque-se” e “seja o pior músico da banda”. A primeira diz respeito a nos colocarmos em situações em que nossos conhecimentos, habilidades e capacidades são postos à prova. A segunda nos diz que trabalhar com programadores melhores que nós é uma excelente maneira de aprender e evoluir. Eu nunca havia visto uma apresentação do Chad Fowler, mas agora posso dizer que é sensacional.
  • Dr. Nick - muito boa a apresentação desta figura simpática e brincalhona. “Path to awesomeness” é a palestra a que eu gostaria de ter assistido, juntamente com a “Being Remarkable” do Chad Fowler, no comecinho da minha curta carreira de programador. Ele, basicamente, deu dicas a respeito de como ser um bom profissional na nossa área. São elas: 1) aprenda sobre sistemas de versionamento de código (svn e git, atualmente) 2) aprenda a testar 3) comece um blog 4) aprenda a criar aplicações 5) melhore o seu código. Como julgo estas dicas muito importantes e tenho acréscimos a fazer, vou falar mais sobre isto num próximo post.
  • Jay Fields - falou sobre a imaturidade dos testes de desenvolvedores. O palestrante fez uma interessante análise das mais famosas ferramentas de testes existentes para ruby/rails. Eu não conhecia o Jay Fields nem tenho muita experiência com ruby e rails, mas me pareceu que ele sabia muito bem o que falava. Expôs claramente pontos positivos e negativos de cada ferramenta, bem como suas opiniões. Respondeu a perguntas e não ficou em cima do muro ao citar quais são as ferramentas que ele usa e prefere: para testes unitários, Expectation. Para testes integrados, Rspec. Para smoke tests, Selenium. Outro ponto importante que o Jay Fields fez questão de reafirmar repetidas vezes é que a sua suíte deve rodar muito rapidamente. Para ele, uma suíte que demora mais de 1 segundo já é problemática e deve ser melhorada.
  • David Chelimsky - David é o atual mantenedor do Rspec e falou, na sua primeira apresentação, sobre BDD. Quando comecei a ler sobre BDD, ainda estava tentando fazer TDD. Lá no comecinho, tinha muita dificuldade para começar a escrever um teste. Sempre parava e falava “e agora? que teste eu escrevo? o que eu faço?”. E o que me ajudou muito a vencer esta limitação foi escrever os meus testes à BDD com “should…”. Pra mim foi mais fácil desta maneira porque me ajudava a pensar a funcionalidade de fora pra dentro. Era mais fácil modelar e começar a escrever desta forma. E o David falou disso na sua excelente e didática a palestra.
  • Danilo Sato - falou das motivações que o levaram e das dificuldades que teve quando começou a escrever testes automatizados para os seus programas. Algumas das importantes lições citadas pelo Danilo são: testes grandes são difíceis de manter (escreva testes pequenos no estilo arrange-act-assert), é bom cobrir a funcionalidade do ponto de vista externo, código de teste também é código e cuidado com mocks para libs externas.
  • Vinícius Manhães Teles - a apresentação foi dividida com o Carl Youngblood da Surgeworks, que falou sobre o ambiente rails aqui no Brasil. Eu nunca tinha assistido a uma palestra do Vinícius, apesar de já o conhecer pelo seu livro de XP.  Foi uma ótima apresentação, mas o que me impressionou mesmo foi ouvi-lo falar sobre empreendedorismo. É impossível descrever ou expressar o valor daquilo falado por ele. É admirável o que o Vinícius fez como pioneiro e evangelizador de XP e vem fazendo, com o pessoal da Improve It, ao inovar o nosso mercado de software.

A primeira edição do Rails Summit foi um incontestável sucesso pelo valor de tudo aquilo falado pelos palestrantes. Tivemos verdadeiras aulas de empreendedorismo, inovação, idéias e agilidade. Tenho certeza de que todos os participantes do evento aprenderam muito. Mais uma vez, meus parabéns à Locaweb e ao Akita pela histórica realização.

October 21, 2008

Agilidade, por Obie Fernandez

Filed under: agile, eventos, rails summit, ruby on rails — Tags: , , , — Adolfo Sousa @ 11:42 pm

Vou relatar aqui uma das palestras com as quais mais me impressionei no Rails Summit 2008, brilhantemente organizado pela Locaweb e pelo Fábio Akita. Pra quem não o conhece, Obie Fernandez foi um dos pioneiros e responsáveis pela adoção do Ruby on Rails na Thoughtworks, escreveu o famoso “The Rails Way” e fundou a Hashrocket. Esta figura simpática, didática e inovadora nos presenteou com o Keynote de encerramento do evento.

Obie listou os 4 princípios do Manifesto Ágil e explicou o que faz para aplicá-los em sua empresa. Em suma, foi uma aula a respeito de agilidade e boas práticas para quem já trabalha ou pretende trabalhar seguindo esta filosofia. Com vocês, o “Hashrocket Way”:

  1. Valorizar indivíduos e interações mais do que processos e ferramentas
  2. Nesta parte da apresentação, ele falou muito a respeito das pessoas com as quais trabalha. Mostrou muitas fotos do seu escritório (com vista para o mar), das reuniões diárias e alguns vídeos engraçados do pessoal se divertindo enquanto trabalhava. O mais marcante, porém, foram as suas idéas a respeito de pair-programming. Para Obie, é fundamental ter um monitor com dois teclados e dois mouses para se programar em par. Isto impede que a pessoa mais imperativa domine o teclado e força a participação das duas pessoas. Falou que uma pessoa pode escrever um teste e a outra o pedaço de código para passar aquele teste. Ficou claro que ele enxerga esta prática, quando bem aplicada, como um bem para as pessoas, já que elas aprendem e crescem com mais rapidez, as tornam mais produtivas e, por conseqüência, realizadas. Outro ponto interessante é o número de pessoas nos seus times: segundo Obie, em um time com mais de 4 pessoas você já pode ter problemas de comunicação e perder o auto-gerenciamento. Seus times são de 2 ou 4 pessoas. E sobre contratações, ele contou que publica um post no seu blog, as pessoas respondem, e ele convida algumas para trabalhar para eles por 1 semana. Ele não se importa se o sujeito tem bilhões de diplomas e títulos, se tem 30 anos de experiência ou se já passou por muitos empregos. Ele quer ver como a pessoa se comporta trabalhando num projeto real e em par. Ele não espera perfeição, mas a candidato deve ser capaz de trabalhar em pares, aprender rapidamente e lidar com a pressão de um projeto verdadeiro.

  3. Valorizar software funcionando mais do que documentação extensa
  4. Aqui ele deu o recado citando a divertida palestra de um rapaz chamado Brian Liles: TAFT - Test All The Fucking Time. É bem curta e divertida, assistam!

  5. Valorizar a colaboração do cliente mais do que (re)negociação de contrato
  6. Ele mostrou uma espécie de contrato em que o cliente não é obrigado a pagar pelo software caso não fique satisfeito. Porém, deixou bem claro que é preciso se proteger. Se o cliente não é obrigado a pagar, ele também não pode processar a Hashrocket e pedir uma indenização maior do que pagaria. Depois, mostrou fotos de alguns clientes realmente trabalhando com a equipe em alguns projetos especiais que eles chamam de “3, 2, 1, launch”. São projetos que eles fazem em 3 dias, desde que o cliente esteja presente e que eles tenham a parte visual da aplicação já definida; este é o único caso em que ele não segue uma prática da XP (design simples).

  7. Responder às mudanças mais do que seguir um plano
  8. Neste final da apresentação, ele mostrou a ferramenta Pivotal Tracker. Falou que sempre estimam as tarefas em pontos (com tamanho máximo de oito) e também sobre a importância das reuniões diárias.

Como não consegui os slides, estou escrevendo a partir daquilo que lembro e anotei, e com a ajuda do post que acabo de ler no blog do próprio Obie Fernandez. Pretendo escrever mais a respeito das outras palestras a que assisti e gostei no Rails Summit 2008.

Até mais!!!

Powered by WordPress