Em relação as minhas impressões finais, conforme falei na primeira parte, o fato de terem introduzido muitas novidades no formato do evento foi essencial para não parecer uma repetição da edição do ano passado. O legal também foi ver que eles preocupados em colher o feedback do usuário e prover mudanças o mais rápido possível. No primeiro dia deixei no quadro “Não gostei” o fato de não ter café durante as palestras e deixei como sugestão o “Continuous Coffee”. E não é que a partir do segundo dia eles colocaram mesas com garrafas térmicas com café ao lado de cada sala! O mesmo ocorreu com água. No segundo dia teve também uma pessoa distribuindo a grade do dia impressa.

Em relação ao conteúdo, o nível dos keynotes foi excelente. Teve bastante palestra gringa também. Vi muitas pessoas reportando, no quadro “Gostei”, que a tradução simultânea estava bem legal também. Outro ponto positivo é que não houve apenas palestras. Teve workshops, tutoriais e os Lightning Talks que conforme já disse foi a novidade que mais gostei. Ao final do último dia teve sorteio de brindes e uma surpresa, um show de humor com o comediante Zé Modesto que animou bastante o pessoal.

Vou deixar aqui uma espécie de “Inicia-Para-Continua” para a próxima edição:

Inicia:

- Gravação de todas as palestras e disponibilização em um canal único.
- Stand para venda de livros.
- Mais spots para uso de notebooks.
- Continuous Coffee sempre!
- Resumo das palestras do dia.
- Mecanismo mais eficiente de confirmação de inscrição. A minha (e de outras pessoas) não foi confirmada. Precisei falar diretamente com um dos organizadores e mesmo assim no dia do credenciamento meu nome não estava no sistema.
- Keynote com Luca Bastos.

Para:

- Stands gigantes no meio do salão, dificulta muito a circulação.
- Mesa do coffee break em lugar quase inacessível.
- Muitas palestras sobre um mesmo tema (TDD). Talvez tenha sido uma melhoria do evento passado, pois ano passado teve poucas palestras sobre o tema.

Continua:

- Achados e perdidos.
- Stand de atendimento.
- Atualização das informações via Twitter, inclusive sobre pertences perdidos.
- Open spaces, lightning talks, palestras gringas.
- Tomadas e extensões para carregar o notebook em todas as salas.
- Diminuir a luz durante as palestras!
- “Auxiliar técnico” para os palestrantes.
- Tradução simultânea.
- Excelente qualidade do sistema de áudio.
- Coffee break sem miséria.
- Continuous Coffee.
- Folha com programação do dia.
- Internet rápida.
- Quadro para deixar o feedback.
- Sistema on-line para feedback de cada palestra.
- O valor da inscrição acessível.

Bem é isso. Recomendo a todos irem na próxima edição que será em São Paulo. Não sou bom nisso, mas creio que o número de participantes tenha sido parecido com a edição passada (cerca de 900 pessoas). Vamos aguardar o Agile Brazil 2012!

Continuous Inspection – An effective approch towards Software Quality Product Improvement

Como saber como anda a “saúde” de nosso código? Usei o termo “saúde” de propósito, pois foi a mesma analogia que Gabriel Moreira e Roberto Pepato usaram. Em um CTI, por exemplo, cada paciente possui um aparelho ligado ao seu corpo que fica o tempo inteiro monitorando suas funções vitais, tais como: pressão arterial, batimentos cardíacos, etc. Se o valor de qualquer um desses parâmetros entrarem em uma faixa não desejada, o monitor irá alertar. Será que existe alguma forma de usar esta abordagem para monitorarmos a qualidade do nosso código? Sim, existe. Existem diversas ferramentas capazes de fazer isso. Continous Inspection é o nome desta técnica. Entretanto, o importante aqui não são as ferramentas e nem os nomes. É interessante saber qual a motivação para tudo isso. Primeiramente é receber um feedback de nosso código o quanto antes. Reparem como os mesmos valores ágeis aparecem o tempo todo! Porém, neste caso o principal objetivo é conter o débito técnico.

Querendo ou não, o débito técnico está sempre presente.

Não cometa o mesmo erro.

Mas agora é que vem o problema. Manter o código manutenível e escalável é um desafio muito grande. Para agravar ainda mais, metodologias ágeis pregam pelo pragmatismo e desencoraja o foco na arquitetura. A grande questão aqui é não ser radical. A ideia é controlar o débito técnico e não eliminá-lo por completo. Controlar o débito técnico significa não apenas mantê-lo baixo, mas sim ser capaz de rastreá-lo também. Em muitos momentos no desevolvimento de um software, inevitavelmente, você terá que abrir mão do capricho no código em função do pragmatismo. Isto é perfeitamente aceitável. O problema é que quando não há um mecanismo de monitoramento, você acaba perdendo a rastreabilidade dos pontos que precisam ser melhorados no seu código. Além disso, conforme mostrado na palestra, muitas ferramentas de Continous Inspection podêm ajudá-lo a priorizar o seu trabalho identificado problemas no código das partes mais críticas do sistema. Por exemplo, refatorar uma classe que é alterada com maior frequência tem maior prioridade do que outra classe que é pouco alterada.

Ninguém quer carregar este fardo.

Esta foi a palestra mais útil para mim, pois tem tudo a ver com os problemas que enfrento hoje. Todas as imagens acima foram retiradas da apresentação dos palestrantes. Vale a pena conferir.

A sociedade do Dojo e os grupos de capoeira.

Confesso que não fazia a menor ideia de estava por vir nessa palestra. Entretanto, como sou entusiasta dessas analogias desconexas, acabei arriscando. E valeu o risco. Bruno Pedroso trouxe à tona um problema que é realidade em nossa comunidade: a dificuldade de organizar Coding Dojos. O problema parece o mesmo em todas as regiões do Brasil. Todo mundo gosta e está convencido que vale a pena, mas ninguém aparece nos dojo’s. Conforme Bruno mostrou, os grupos de capoeira passaram por esse mesmo problema no passado. Para resolvê-lo, foi criado o sistema de cordel que tem a ver com o reconhecimento que um capoeirista tem dentro do seu grupo. Bruno apresentou uma iniciativa do pessoal de Brasília que seria algo como um ambiente de pontuação inspirado (mas diferente) do sistema do stackoverflow. O bacana dessa palestra é que o autor trouxe não apenas um problema, mas sim uma proposta inicial de solução. Além disso, a parte final da apresentação virou quase uma mesa redonda onde muitos participantes mostraram ideias interessantes. Chegaram a propor incentivos financeiros. Eu sou um pouco contra esta ideia, pois as pessoas podem esquecer da real motivação dos dojo´s. Vou deixar registrado aqui uma ideia que me ocorreu durante a escrita deste post. Poderia-se pensar em uma espécie de incentivo por parte das empresas. Em vez de apoio financeiro, as empresas poderiam apoiar com horas de trabalho e/ou oferecendo o espaço/estrutura para realização dos dojos. Na minha opinião, o custo disto é bem inferior ao de um treinamento tradicional e a eficiência pode ser maior também. Creio que uma abordagem como esta, iria otimizar a capacitação do time a médio/longo prazo. Nessa história todos saem ganhando.

Como formar um programador 10x

Crédito: @cghenriques

Esta é o tipo de palestra que é impossível expressar com palavras o quão boa foi. Luca Bastos, sem papas na língua e com um vocabulário jovem, cativou toda a audiência. A sala ficou literalmente pequena para Luca. Muitas pessoas assistiram em pé, pois não havia cadeiras suficiente para todos. Luca apresentou ideias já conhecidas para aumentar o nível de conhecimento de programadores iniciantes. Ele discutiu, com muito bom humor, técnicas como pair programming, revisão de código e etc. Um dos momentos mais interessantes foi quando ele mostrou um slide com uma foto dele praticando pair programming com uma desenvolvedor que tinha um terço da idade dele. É uma pena que não lembrei na hora de fotografar esse slide para compartilhar aqui com vocês. O carisma do Luca é impressionante. Um fato curioso: durante a palestra eu postei no Twitter pedindo um keynote para o Luca Bastos no próximo Agile Brazil e em poucos segundos foi “retuitado” por dezenas de pessoas. A apresentação foi recheada de tiradas engraçadas, foi deixar algumas aqui:

• “Planning poker? Eu chuto tudo!”
• “Pair programming funciona, porque o desenvolvedor tem vergonha de fazer bacalhau ao lado do colega.”
• “Programar é do c@#$. Quando o teste passa você é f@#$, quando o teste falha você é um m@#$%.”
• “Sou contra pair programming 100% do tempo, porque o desenvolvedor precisa ter um momento de intimidade com seu código”.

Ciclos de Avaliação de Pressupostos: Entendendo Lean, Kanban e Agilidade sob uma nova perspectiva

Nesta palestra, Alisson Vale apresentou sua ideia sobre avaliação de pressupostos. A ideais de Alisson soam para mim como uma camada mais alta de abstração do conceito de feedback. Outro ponto que ele destaca é que avaliação de pressupostos é uma oportunidade de aprendizado e uma forma de avançar em um cenário repleto de incertezas. No entanto, existe uma variável importante neste sistema que não pode ser ignorada: o tempo. A proposta de Alisson é minimizar o tempo entre a criação de um pressuposto e sua avaliação. Para representar esse conceito foi proposta a seguinte expressão:

? – min(t) => !

onde, ? representa a criação de um pressuposto, ! representa a avaliação de um pressuposto e min(t) representa o objetivo em diminuir esse tempo.

Isso parece muito familiar, não ? Quem pensou em TDD acertou em cheio. O que torna o TDD tão poderoso é exatamente essa capacidade em minimizar o tempo em que um pressuposto surge e o tempo no qual ele foi avaliado. E o interessante é que isso ocorre em diversos aspectos do TDD. O primeira deles é o próprio resultado do teste. Quando um teste falha significa que sua nova especificação não está sendo atendida pelo código. Neste ponto, você acabou de minimizar o tempo t. O segundo aspecto que merece destaque é o tempo de identificação de uma regressão. Executar todos os testes após alterarmos nosso código é equivalente a validar o seguinte pressuposto: “Minha alteração regrediu o sistema?”. Reparem como estamos minimizando o t (em geral os test runners executam centenas de testes de unidade em um único minuto). Um terceiro, e não menos importante, aspecto é o constante feedback que o teste te dá a respeito da saúde do seu código, os tão comentados “code smells”. Interessante como o ato de escrever um único teste permite a avaliação de diversos pressupostos em um tempo mínimo! Para ilustrar o conceito, Alisson usou outros exemplos. Um deles foi relativo a avaliação de pressupostos durante a entrega de um produto. O gráfico abaixo mostra que quanto maior a frequência de releases, menor será o tempo de avaliação de alguns pressupostos tal como o feedback do cliente em relação a uma nova feature:

Para minimizar o tempo de avaliação de pressupostos devemos aumentar a frequência de release do produto.

Esse gráfico reforça a ideia de que Continous Delivery (entrega contínua) é o caminho a ser perseguido.

Lightning Talks

Conforme já falei, esta foi a novidade que mais apreciei nesta edição do Agile Brazil. Vou destacar alguns aqui e tentar escrever em poucas linhas o que achei:

TDD – Está na hora de aplicar no seu trabalho!

Daniel Wildt trouxe à tona uma dificuldade que acredito ser muito comum no desenvolvimento de software em nosso país: convencer outros desenvolvedores dos reais valores do TDD. Pelo incrível que apareça, ainda existe muito desenvolvedor que acredita que o objetivo do TDD é testar. A palestra não foi para apresentar nenhum processo ou ferramenta para disseminar o TDD, foi apenas uma injeção de motivação para não desistirmos da ideia.

Conhecendo Domain Driven Design

A tarefa de condensar um assunto sem perda de informações importantes é algo extremamente difícil (pelo menos para mim). Falando de DDD, pior ainda. É assunto denso e extenso, cheio de detalhes. Felipe Rodrigues conseguiu uma façanha: falar de DDD, de maneira consistente, em 10 minutos. Não foi útil para mim, mas para quem não conhece nada sobre o assunto, o talk parece ter sido excelente.

Ramones ou Jazz? Ou os dois? Buscando produtividade com músicas.

Embarcados na filosofia do Pomodoro, Daniel Wildt e Hélio Medeiros apresentaram o SongDoro. Uma proposta para maximizar a produtividade com músicas que estimulem o desenvolvedor usando os mesmos conceitos básicos da técnica Pomodoro. O bacana é que eles apresentaram a possibilidade de um ambiente colaborativo onde é possível obter recomendações (ou recomendar) de músicas por outros desenvolvedores.

Domain Game: Disseminando conhecimento através de diversão.

Rafael Camargo apresentou um jogo interessante para aumentar o conhecimento do time em relação ao domínio do software que estão desenvolvendo. O Domain Game é um jogo onde os membros do time deverão responder perguntas, geralmente feitas pelo PO, sobre questões do domínio. Se ele acertar, ganha algum “brinde” (Rafael usou bombons como exemplo). Caso erre, o membro do time deve “pagar” o PO com um bombom. Então, quem fica com mais bombons ao final do jogo é o vencedor? Não! O objetivo do jogo não é descobrir quem sabe mais sobre o domínio, mas sim nivelar o conhecimento de todo o time de forma divertida. Então se não há disputa não é jogo? Alguém aqui já venceu ou perdeu num jogo de frescoball ?

UI-TDD : Quem disse que não é possível?

Bruno Pedroso (o mesmo da palestra da capoeira) fez algo que parecia impossível: um LT prático. Ele extraiu alguns pontos do TDD que são aplicáveis no desenvolvimento de interfaces web. Usando um editor de textos, ele escreveu a especificação de um gráfico de radar como se fosse um teste unitário assumindo inicialmente que o teste estava quebrado. Em seguida, escreveu um código inicial em JS e o teste passou. Daí em diante, ele fez os passos comuns do desenvolvimento orientado a testes, evoluiu a especificação, refatorou o código até chegar ao ponto em que julgou que a especificação foi atendida. Dessa forma, Bruno conseguiu quebrar o mito de que não tem como aplicar TDD quanto estamos colocando funcionalidade na interface gráfica. É claro que não há o benefício da automação, mas pelo menos é possível criar um código com maior qualidade com essa abordagem.

That´s it. Aguardem o terceiro e último post sobre este feedback!

Crédito: agilebrazil.com

Eu tenho frequentado eventos sobre agilidade desde 2007, participando de pelo menos dois eventos por ano. O último que participei foi o Agile Brazil 2010 ocorrido em Porto Alegre. Apesar deste ter sido um evento excelente, confesso que este ano não estava com a mesma empolgação para encarar mais um evento sobre agilidade, pois achava que seria “mais do mesmo”. Entretanto, como os organizadores são bom agilistas, não esqueceram de um dos valores mais importantes de qualquer metodologia ágil: melhoria contínua.

O evento deste ano ocorreu na maravilhosa Fortaleza de 27/06 à 01/07.  Como no ano passado, os dois primeiros dias foram reservados a cursos. As palestras começaram no dia 29/06. O evento ofereceu 3 keynotes sensacionais (um em cada dia), diversas palestras, workshops, tutoriais, lightning talks e alguns open spaces. Houve mais expositores nesta edição. Destaque para os stands da ThoughtWorks e da Microsoft. O kinect foi a sensação em diversos stands. Senti falta apenas de stands com venda de livros.

Crédito: twitter.com/cghenriques

A estrutura do evento estava ótima. Bom coffee-break, spots para notebooks, uma “mini-central” de atendimento, achados e perdidos, etc. A organização registrava regularmente informações úteis e novidades via Twitter . Único ponto negativo ficou por conta dos dois stands maiores que ficaram bem no centro do salão principal dificultando, e muito, a circulação dos participantes. As salas das palestras eram ótimas. Todo palestrante tinha uma espécie de auxiliar para resolver eventuais problemas técnicos. Achei bastante interessante, não lembro de ter visto algo semelhante no evento de 2010.

Sem dúvida, a novidade que mais gostei foi a introdução de Lightning Talks (LT). LT é uma sessão divida em curtas apresentações de diversos temas. No Agile Brazil 2011, as sessões tinham mais ou menos 5 apresentações de 10 minutos. Em uma palestra tradicional, se esta não atender sua expectativa, você acaba perdendo aquele tempo. Tudo bem que você pode sair da palestra que não está gostando e ir para outra, mas não é bacana porque você acaba perdendo parte da palestra que entrou depois. Em um mesmo LT não existe, necessariamente, conexão entre os assuntos. Além disso, geralmente cada apresentação é feita por um palestrante diferente. Com isso, dificilmente você terá a sensação de tempo perdido em um LT. Além disso, em um evento como este, o que busco são pequenos insights para aplicar no meu dia-a-dia ou, então, saber como as pessoas resolvem um determinado problema. Não tenho a pretensão de sair de uma palestra dominando um tema. Neste contexto, penso que os LTs são mais eficientes. Então, a programação deveria ser composta apenas de LTs ? Não! Alguns assuntos merecem mais do que 10 minutos, porém poderia-se ter mais LTs o quê permitiria uma seleção melhor das palestras.

O que não gostei muito foi o excesso de palestras sobre TDD. Apesar deste ser um dos assuntos que mais aprecio, penso que deveria-se ter dado mais espaço a outros temas, até porque das 3 palestras que eu fui, duas estavam bem fracas. Por outro lado, não é de todo ruim, visto que TDD é essencial neste modelo de desenvolvimento de software e aqui no Brasil ainda existem dúvidas e muita resistência a este paradigma de programação.

Este post será dividido em três partes. Nesta primeira parte, falarei sobre os keynotes. Na segunda parte, abordarei as palestras e os lightning talks que assisti. Na terceira, e última parte, compartilharei minhas conclusões e sugestões para próxima edição.

Keynotes

Jim Highsmith

Ele é colaborador da Thought Works e possui diversos livros publicados. É também um dos autores do Manifesto Ágil e co-fundador da Agile Alliance. Trazer um nome desse peso dá bastante credibilidade ao evento. Jim baseou-se em um estudo da IBM que revelou que 80% dos executivos desejam que seu ambiente cresça consideravelmente mais complexo, mas menos da metade sabe como lidar com isso. Outro número importante apresentado por Jim, foi o de que organizações ágeis conseguem ganhos 30% maiores por ação do que empresas não-ágeis . Neste momento, os executivos presentes no local devem ter aberto um sorriso de orelha a orelha e eu me lamentando pelos executivos da empresa na qual trabalho não estarem lá. Entretanto, para atingir tal feito não basta tornar ágil apenas a área de desenvolvimento da organização. É necessário que toda a companhia esteja alinhada com os valores ágeis. Se pararmos para pensar isso faz todo o sentido. O principal objetivo de qualquer método ágil é responder o mais rápido possível às mudanças. Uma vez que as mudanças são motivadas pelo ambiente externo (riscos positivos, tendências de mercado, etc.), não faz sentido que os setores estratégicos da empresa não estejam alinhados com este pensamento. Para promover a agilidade além da área de desenvolvimento, Jim apresentou o conceito de liderança adaptável que nada mais é que “implementar” os valores ágeis na esfera do negócio. Ele chamou este processo de agilidade estratégica. Ao meu ver o “climáx” da apresentação de Jim foi quando ele colocou o seguinte gráfico:

Crédito: twitter.com/luty81

Em suma, o que esse gráfico diz é que o débito técnico aumenta o custo de mudança, este por sua vez afeta negativamente a velocidade de entrega (do produto) que se reflete em uma diminuição da capacidade de resposta de uma empresa (a seus clientes). Em outras palavras, o débito técnico diminui a agilidade da empresa. Percebam o poder destas informações. Nós conhecemos uma poderosa arma  para conter o crescimento do débito técnico: refactoring. Por mais que tenhamos boa cobertura de código e mesmo usando os melhores padrões de design, sem refactoring constante o débito técnico vai crescer, isto é fato. Como costumo dizer, código é como um jardim: mesmo usando uma boa terra com os melhores fertilizantes, se não regarmos todo dia, o jardim resistirá. Este gráfico, é um ótimo argumento para convencermos gestores e os executivos de nossas as empresas de que devemos colocar o pé no freio na hora de empurrar toneladas de novas funcionalidades em nosso produto (muitas vezes inúteis como veremos no keynote do Joshua logo adiante) . Em vez disso, devemos priorizar a “ordem na casa”. É o que Jim chamou de “Do Less” (faça menos) que na visão dele é um dos quatro elementos-chave da dimensão “Do Agile” da liderança adaptativa. Entretanto, estas informações não servem apenas para nossos executivos. Ela também deve ser usada por nós desenvolvedores para refletirmos a cerca do que andamos fazendo por aí. Antes de lançarmos aquele bacalhau “inofensivo” no código e sempre que negligenciarmos o refactoring, estamos assumindo que iremos diminuir a capacidade de resposta da empresa. Em outras palavras, estamos “assinando um contrato” onde concordamos que reagiremos mais lentos às mudanças externas e seremos menos ágeis em atender as novas necessidades de nossos clientes.

Crédito: twitter.com/cghenriques

Joshua Kerievsky

Crédito: twitter.com/cghenriques

Autor do livro “Refactoring to Patterns” e dono da Industrial Logic, uma empresa que vende treinamentos sob o formato e-Learning, Joshua parecia mesmo obstinado a cativar o público brasileiro: iniciou a palestra com um “Bom dia” com aquele sotaque gringo e depois falou alguma coisa que não entendi, mas que tinha a palavra “caipirinha” no meio, arrancando risos da plateira . A palestra de Joshua foi baseada na felicidade. Segundo ele, devemos focar nosso trabalho priorizando a felicidade, mas não apenas de quem desenvolve o produto, e sim de todos os indivíduos envolvidos no processo de desenvolvimento e entrega do software. Em última instância, estes indíviduos são representados pelos nossos clientes ou usuários do produto. Para mostrar como tornar seus clientes mais felizes, Joshua citou alguns valores do pensamento Lean e trouxe um número já conhecido por nós: mais de 60% de todas as funcionalidades da maioria dos softwares nunca foram utilizadas. Então, para fazer nosso cliente mais feliz, precisamos descobrir que funcionalidades ele espera ou deseja que o software possua. Para fazer isto, Joshua usou o conceito de “Fake Feature”.

Crédito: twitter.com/cghenriques

Ele e seu time colocaram na interface gráfica de seu produto, botões e links que representariam uma funcionalidade hipotética. Entretanto, quando o usuário tentava utilizá-la, o sistema informava que aquela funcionalidade não estava disponível e, em seguida, questionava se o usuário gostaria de ter essa funcionalidade no sistema. Joshua não entrou no mérito de como ele usou essas informações coletadas. Entretanto, é bem fácil imaginar que esse dado poderia compor (ou até mesmo representar por completo) o business value das user stories de um produto, permitindo assim, uma priorização mais eficiente do product backlog. Em linhas gerais, a mensagem que Joshsua tentou nos passar é que pessoas mais felizes trazem mais resultados para empresa. Um membro do time mais feliz vai produzir com mais qualidade, e um cliente mais feliz vai, não apenas comprar mais, mas colaborar com o desenvolvimento do produto (com sugestões, feedbacks, etc).

Crédito: twitter.com/cghenriques

Uma prova de que ele realmente se preocupa com isso, ele pediu para traduzir sua apresentação para Português! Toda sua apresentação, exceto as imagens, estavam em nosso idioma. Além disso, ele participou de um open space que irei falar mais na segunda parte deste post.

Vinicius Teles

O keynote do Vinícius pode ser resumido em um choque de realidade carregado de bom humor, como de praxe. Ele iniciou citando aquela “profecia” de que o mundo acabará em 2012. Mas, segundo ele, não será um cometa ou coisa parecida que detonará a Terra, mas sim uma grande tela azul. Para mostrar isso, Vinícius coletou alguns depoimentos em vídeo durante o próprio evento. Os depoimentos eram experiências de participantes do evento ao utilizarem sistemas on-line de empresas grandes empresas públicas, bancos e de telecomunicações. De problemas de usabilidade, passando por bugs, até questões sobre performance, Vinícius nos mostrou o quanto um software defeituoso atrasa nossa vida.

Crédito: twitter.com/cghenriques

De acordo com ele, só existe um culpado por isso: nós desenvolvedores. Em outras palavras, ele mostrou como nós, às vezes, atrasamos o mundo. Esse foi o choque de realidade da apresentação. É muito legal quando alguém influente na comunidade menciona algo que reflete o que você pensa. Vinícius falou de uma coisa que já conversei com alguns colegas de profissão: Temos que parar! Parar no sentido de querer absorver toda novidade (tecnologia, linguagens e etc) que aparece pela frente. Às vezes, nós parecemos poodle de apartamento quando vai à rua: corri para todo o lado, mas sem objetivo nenhum. De nada adianta aprender a linguagem do momento, se a gente continua entregando software de péssima qualidade. Faz muito mais sentido revermos como estamos desenvolvendo software do que aprender uma nova tecnologia. Outro momento marcante e polêmico do keynote foi um slide com a seguinte frase: “Talking is cheap. Show me the code.”.  Muitas pessoas levaram para um lado de que tudo o que importa é o código e resto que “se exploda”. Vi algumas pessoas postando no twitter que outras áreas também são importantes, outras falando que não apenas o código é importante, que a interface gráfica, por exemplo, tem importância também e coisas do gênero. Eu acho que não foi essa a mensagem que o Vinícius tentou passar. Antes de mostrar este “polêmico” slide, ele estava questionando as certificações. Mostrou o perfil de vários desenvolvedores sem certificação que são reconhecidos, pela nossa comunidade, como excelentes programadores . Ele também fez a seguinte indagação: “Quem te certifica desenvolve software?”. Quem assina seu certificado, sabe o que é programação? Logo em seguida, ele mostrou o slide em questão. Ao meu ver, ele quis passar a mensagem de que certificados não possuem tanto valor, uma vez que não é possível transformar papel (certificado) em código. Por exemplo, é como se ele dissesse: “Em vez de você falar que é certificado em Java, mostre o código Java que você é capaz de desenvolver.”. Se eu não me engano ele comentou em seguida que só código importa, mas isso foi somente em relação a certificação ao meu entender. Em outras palavras, não me diga o que você sabe e nem os certificados que possui, mostre o código que você é capaz de escrever. Pelo menos, essa foi a forma que eu entendi.

Aguardem a segunda parte onde irei falar sobre as palestras e os lightning talks que assisti.

Um lance bem legal do heroku é que ele faz uso de uma gem e de um hook do github para facilitar a sua vida na hora de fazer deploy.

Sendo assim, você consegue fazer deploy de uma aplicação ruby com poucos passos:

1) Instale a gem do heroku

   sudo gem install heroku

2) Criar uma app

   heroku create nome_da_sua_app

3) Deploy

  git push heroku master 
  heroku rake db:migrate

Dificil né?

Até aqui tudo são flores, o problema é como eu falei anteriormente, o default é Ruby 1.8.7 e particulamente eu prefiro rodar uma app Rails3 com Ruby 1.9.2 apesar de que no site oficial do Rails é recomendado tanto a 1.8.7 quanto a 1.9.2

Agora só precisamos de mais dois passos
1) Executar um migrate para nossa app passar a usar a mri-19.2

heroku stack:migrate bamboo-mri-1.9.2

2) Em seguida preciamos fazer um novo deploy para relaizar essas alterações, o problema é que se você não tiver nenhuma alteração para subir o deploy não vai ser feito, então edite o seu arquivo README por exemplo, é em seguida rode os seguintes comandos:

git commit -am "Migrando MRI para 1.9.2"
git push heroku master

E pronto!! temos uma app publicada no Heroku, rodando no Ruby 1.9.2

Abraços!
até a próxima!

Reduz o GAP entre a introdução, identificação e correção de bugs.

O National Institute of Standards and Technology (NIST), realizou um estudo em 2002 chamado “The Economic Impacts of Inadequate Infrastructure for Software Testing” que constatou que defeitos em Software custaram aos EUA, nada mais nada menos que, 60 BILHÕES de Dólares. O estudo foi realizado em empresas de tamanho e domínio variados. Uma das mais importantes conclusões do estudo foi que este elevado custo ocorre não apenas pela enorme quantidade de defeitos, mas também pelo elevado tempo que um defeito leva para ser identificado e corrigido. Como assim? Felizmente, o mesmo estudo concluiu que o custo de correção de um defeito cresce de forma exponencial ao intervalo de tempo entre a introdução e correção do mesmo. Ora, se o problema é este GAP, só temos uma solução: reduzí-lo o máximo possível. E se pudéssemos reduzí-lo de tal forma que os bugs fossem identificados no ato da codificação? É aí que entra o TDD, pois ele permite que a maioria dos bugs sejam identificados imediatamente após terem sido introduzidos. Esta detecção “real-time” vai lhe poupar de um generoso tempo de depuração e compreensão do código defeituoso. É claro que, mesmo usando TDD, você não tem garantias de que todos os bugs serão identificados. É imporante ressaltar também que as vantagens do TDD podem ser potencializadas com o uso de outras práticas do eXtreme Programming, tais como programação em pares, integração contínua, entre outras.

Segue abaixo o gráfico proposto por Scott Ambler que ilustra bem isto:

A tabela abaixo foi retirada do estudo acima citado e faz um cruzamento entre a fase onde o bug foi introduzido com a fase onde foi identificado e o custo médio em horas de correção deste bug:

Para ilustrar, uma das leituras que podemos fazer a partir da tabela acima é que o custo (em tempo) de correção de um bug que foi introduzido na fase de codificação será três vezes maior caso o mesmo seja identificado após esta fase, podendo chegar a ser cinco vezes maior caso o mesmo seja identificado apenas após o lançamento do produto.

Abaixo segue algumas outras conclusões interessantes publicadas neste trabalho do NIST:

• 80% do tempo de um desenvolvedor é dedicado à identificação e correção de bugs.
• Mais de 50% dos bugs não são detectados até a fase de homologação.
• Aproximadamente 50% dos bugs são introduzidos na fase implementação.
• Cerca de 50% do orçamento total de um projeto de software é gasto em correção de bugs.

Facilita a criação de código com alta coesão e baixo acoplamento.

Imagine que lhe passem a tarefa de fazer um desenho composto de polígonos regulares. O seu desenho será avaliado em relação a sua semântica e o quão preciso estão os lados e ângulos dos polígonos. Não vamos entrar em detalhes do que seria a semântica (ou harmonia), mas considere que a criação de uma boa semântica seja tão complexa que vai consumir quase todo o tempo que você tem para construir o desenho. Além disso, você não pode utilizar uma régua. Qual o problema desta tarefa? Por melhor desenhista que você possa ser, você vai precisar gastar um bom tempo desenhando e validando se cada figura é um polígono regular. Com isso, você vai ter menos tempo para pensar na parte mais complexa do tarefa. Se você pudesse usar uma régua, você poderia gastar quase todo o tempo da tarefa pensando na “semântica” do desenho, uma vez que a régua lhe auxiliaria a desenhar os polígonos de forma muito mais rápida e precisa. É exatamente assim que ocorre na codificação. Sempre que começamos a codificar um novo pedaço de um sistema (tarefa de desenhar), temos o desejo de criar o melhor código (ou arquitetura) possível (assim como o desenhista deseja construir os polígonos regulares com “boa semântica”). Entretanto, para criar um bom código (ou arquitetura), você precisa a cada novo passo, validar a evolução do mesmo. Essa validação só pode ser feita forçando a execução do seu código. Sem TDD, a única maneira de fazer isso é testar funcionalmente seu código. O problema disto é que, por ser um processo manual, é lento e improdutivo. Além disso, você precisa a cada novo passo na codificação, re-testar tudo o que já fora testado e isso recai sobre o problema de ser um processo manual. E um último problema é que não é tarefa do desenvolvedor gastar muito tempo na execução de testes funcionais (e tão pouco gostamos de fazer isso). Mas como somos espertos, o que fazemos? Simples, codificamos toda a arquitetura num passo só e validamos tudo num único teste funcional. Estratégia pouco inteligente. É como se o desenhista tentasse construir todo o seu desenho e validar a “semântica” apenas após desenhar o último polígono. A chance da “semântica” não ficar boa é grande. Além disso, ao detectar os polígonos culpados pela “semântica” ruim, a correção isolada dos mesmos provavelmente vai causar um efeito colateral na harmonia geral do desenho.

Reduz o tempo gasto em depuração e em correção de bugs.

Quando iniciamos o processo de correção de um bug, a primeira coisa que geralmente fazemos é tentar reproduzir o erro, para em seguida depurar o fluxo onde ocorre o bug para enfim analisar o estado dos objetos em busca da raíz do problema. Quando você não possui testes, você precisa mais uma vez realizar os passos de um teste funcional para depurar. Se você escrever um teste unitário que “estimule” o sistema a passar pelo código defeituoso, você estará “reproduzindo” o erro sem necessidade de executar a aplicação que, como vimos, é bem mais produtivo do que testar funcionalmente o código.

Serve de suporte para testes de regressão.

É comum, ao corrigir um bug, introduzir um novo bug. Em outras palavras, a correção de um bug pode ter como efeito colateral que uma parte do software que antes funcionava deixe de funcionar. Quando isto ocorre, dizemos que o software regrediu. Chamam-se “teste de regressão” os testes que visam verificar a integridade geral do sistema quando um bug é corrigido, ou até mesmo quando uma nova funcionalidade é implementada no sistema. O uso do TDD vai reduzir a introdução de efeito colaterais junto com alterações no código. É claro que apenas na parte do código que seja coberta pelo testes unitários. Além disso, quando um teste passa a falhar após sua alteração, você acabou de identificar o bug num momento muito próximo de sua introdução, o que é uma enorme vantagem como vimos acima.

Encoraja o refactoring.

O refactoring é uma atividade bastante importante dentro do processo de desenvolvimento de software. É através dele que mantemos o código legível e escalável. Quanto mais tempo ficamos sem refatorar o código, mas ele vai “perecendo”. Em outras palavras, quanto mais tempo ficamos sem refatorar, mais custoso e arriscado será mudá-lo. Entretanto, inúmeras vezes em nossa carreira temos medo de alterar um código. Esse medo muitas vezes ainda é ratificado por um colega que diz: “Não mexe aí que está funcionando!”. Esse medo vem do fato de termos ciência de que ao alterar um código que funciona, a chance de não testar todos os casos onde código é estimulado é muito grande. Além disso, algumas mudanças requerem testes exaustivos que muitas vezes não temos tempo hábil para realizar. Quando usa-se TDD, a execução dos testes é automatizada e temos garantia que todos os casos onde temos cobertura serão testados. Realizando TDD e refactoring com frequência acaba tendo como resultado um ciclo vicioso positivo na qualidade do código, pois uma vez que o processo lhe permite refatorar de forma mais constante, o código apresenta uma melhoria continua o quê o torna cada vez mais testável, ou seja, “realimentando” a coragem em refatorá-lo.

Serve como documentação.

Testes unitários, se bem escritos, podem servir como forma de documentação do sistema, onde o comportamento do sistema é descrito pelos testes. Além disso, os testes também podem servir como forma de documentação de uso de alguma API, ou framework do qual o sistema dependa.

Referências.

Aquela velha historia

A maioria dos projetos, tem uma documentação inicial, onde são colocadas as necessidades do cliente. Num projeto tradicional, ou não, esta documentação será entregue aos desenvolvedores para fazer o milgre de transformar texto impresso no papel, em software. Até agora não contei novidade alguma, mas a coisa vai ficar mais interessante a partir de agora.

Os desenvolvedores começam então, a escrever o software baseado nas informações contidas na documentação entregue a eles. Agora imagine que boa parte do software já está implementada e o gerente de proejetos está super feliz em ver o gráfico do project bonitinho, mostrando que o projeto está até adiantado. Quando… acontece o que sempre acontece em projetos de software. Uma grande mudança, uma alteração tão radical que afetará varios pontos do sistema. Vocês já viram este filme, e sabem que numa situação dessas é comum ter que fazer tudo pra ontem e sem prejuizo ao cronograma. O que se traduz em horas extras e trabalho nos finais de semana. O ambiente de trabalho legal para os desenvolvedores costuma acabar neste ponto. Como as alterações são todas urgentes, é muito comum que a equipe concentre forças na alteração do código fonte, enquanto a alteração da documentação fica pra depois. Um depois que geralmente nunca acontece.

TDD e Documentos… onde você quer chegar?

Pronto agora cheguei onde queria =). Comecei falando de TDD e no paragrafo anterior falei de documentação desatualizada. Que relação essas coisas podem ter?

Bem, a documentação incial do projeto, em papel, descreve o que o software deve fazer (comportamento), os métodos das classes escritas pelos desenvolvedores são responsáveis por realizar este comportamento. Em um cenário, como posso dizer, “mais comum” depois do desenvolvedor implementar o software, uma pessoa seria encarregada de testar o comportamento do software, para isso ela precisaria recorrer a documentação do projeto. Mas depois da mudança a documentação vai estar desatualizada o que abre margem para problemas maiores.

Uma maneira de resolver este problema seria automatizando os testes, e neste ponto entram os testes de unidade. Imagine que nossos desenvolvedores escreveram testes de unidade automatizados para checar o compotamento de cada um dos métodos implemetados por eles. Agora não precisarimos de mais uma pessoa para testar, e o mais importante, agora temos uma documentação executável. Isso mesmo pense nos testes de unidade como sendo uma documentação executável, uma documentação que quebra se não for atualizada.

Documentação Executável

Como todos sabem a documentação mais atualizada de um software é o código fonte. O problema é que ele não é “amigavel e legivel” para todos.  Pode ser pouco agradavel ter de ficar olhando varios arquivos, classes e métodos para entender o que eles fazem realmente. Na tentativa de melhorar, esse cenário pessoas passaram a utilizar uma técnica para escrita de testes que tenta expressar mais a intenção daquele comportamento. Esta técnica é conhecida como Behaviour Driven Development (BDD), foi um termo cunhado por Dan North mais informações aqui. Mas continua sendo muito código, e fica ainda complicado identificar o que é uma pré-condição, o que realmente está sendo testado é o que é a pós-condição. No JUnit por exemplo, a responsabilidade de descrever o comportamento testado fica no nome do método, que pode ficar quilometrico (nada contra), como por exemplo: deveSerCapazDeCriarUmaListaDePedidosAPartirDoXML.

Na tentativa de tornar os comportamentos mais evidentes, sugriam framework’s como RSpec utilizado por desenvolvedores ruby.
Veja abaixo um exemplo de código do RSpec

describe "Uma Conta"
it "nao deve permitir saques superiores ao valor de seu saldo" do
   conta = Conta.new
   conta.deposita 100
   lambda{ conta.saca 200}.should raise_error ArgumentError
end

Apesar de ter menos “ruido”, muito também devido a linguagem ruby,  este código ainda tem muito apelo programático. Fica dificil usar um negocio desses com seu cliente, ou especialista de negocios. Então o bacana mesmo seria escrever especificações/documentação, usando o bom e velho português, e ter algum vodoo que tornasse essa documentação executável.

E esse Vodoo existe?

Sim esse vodoo existe e se chama Cucumber.
O Cucumber é um framework que permite a escrita de funcionalidades, no estilo user story, uma especie de caso de uso. Vejamos um exemplo:

#language: pt
Funcionalidade: Saque de conta
   Para retirar dinheiro do banco
   Como um correntista do banco
   Devo realizar um saque
 
Cenario: Saque com sucesso
   Dado que a "minha conta" possui "saldo" de "100" reais
   Quando eu sacar "70" reais da "minha conta"
   Entao "minha conta" devera ter "saldo" de "30" reais
 
Cenario: Saldo Insuficiente para Saque
   Dado que a "minha conta" possui "saldo" de "100" reais
   Quando eu sacar "200" reais da "minha conta"
   Entao um erro de "Saldo Insuficiente" deve ser exibido

Pra começar as historias descrevem funcionalidades (features), e é comum se apresentarem neste formato:
Para alguma coisa
Como um papel,
Devo fazer alguma coisa.
Logo depois definimos os cenários, nosso exemplo tem dois cenários um de sucesso e outro de falha, você pode escrever quantos cenários quiser.

Aham Cláudia senta lá…

Então agora eu escrevo a especificação que eu quiser usando português e pronto vai funcionar? Quase isso, o cucumber permite o uso do português para descrevermos a funcionalidade e seus cenários, mas lembre-se que no fundo no fundo tudo isso é um grande teste. A grande diferença é que o apelo programático é retirado, mas a intenção do teste ainda está lá. O JUnit nos fornece os chamados TestCase para que possamos agrupar nossos testes. O cucumber nos fornece o recurso de features (funcionalides) no qual descrevemos uma funcionalidade. Cada funcionalidade do sistema costuma ser descrita por em um arquivo separado que possui a extensão .feature, o exemplo da funcionalide saque de conta ficaria num arquivo chamado: saque_conta.feature. Além disso o cucumber impõe que estes arquivos “vivam” dentro de uma pasta que se chame “features”. As features podem conter vários cenários. Dá pra fazer um paralelo entre os cenários e os métodos de teste de um TestCase do JUnit. Os cenários descrevem de maneira mais intuitiva os 3 componentes do teste: pré-condição, teste e pós-condição, como podemos ver abaixo:

Cenario: Saque com sucesso
   Dado que a "minha conta" possui "saldo" de "100" reais #pré-condição
   Quando eu sacar "70" reais da "minha conta"             #teste
   Entao "minha conta" devera ter "saldo" de "30" reais  #pós-condição

A primeira linha define a pré-condição a segunda deixa claro o que queremos testar e a útlima linha checa a pós-condição, tudo sem apelo programático.

E cadê o código que faz isso funcionar?

Bem a gente precisa escrver esse código, não tem jeito. Porém o bacana é que ele fica totalmente separado do texto da funcionalidade e dos cenários. O cucumber espera que você forneça para cada passo dos seus cenários, um bloco de código fonte, para que ele consiga executar os testes. Estes blocos de código são definidos dentro de um arquivo, que geralmente é chamado de “step.rb”, e precisa ficar dentro da pasta “features/step_definitions”.

Quando o cucumber interpreta o arquivo da feature e identifica  passos “indefinidos”, ele gera uma especie de template do passo, para que este possa ser implementado no arquivo de definicao de passos, o step.rb por exemplo. Um exemplo deste template seria:

Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |arg1, arg2, arg3|
  pending # express the regexp above with the code you wish you had
end

Repare que tudo que foi informado entre “” foi considerado como parametro pelo cucumber, repare também que o template já abre um bloco de código onde ele nós fornece os argumentos. Entre este “do” e “end” é que colocamos a implementação do nosso passo. Veja agora um exemplo de implementação:

Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
   conta = obter_conta_pelo_nome(nome_da_conta)
   atributo = change_spaces_for_underlines(atributo)
   conta.instance_variable_set( "@#{atributo}", valor.to_f )
end

O bacana é que os steps são reapoveitaveis, repare que o step do exemplo acima também é utilizado no cenário de saque com saldo insuficiente. No início vamos implementar muitos steps, mas depois vamos passar mais tempo escrevendo cenários e novas features do que implementando steps efetivamente. É possivel configurar o cucumber para fazer o output de seus testes em html. O interessante deste formato é que as funcionalidades e cenários ficam com “cara” de documentação “formal”.

Conclusão

É foi isso… A ideia aqui era focar no teste como forma de documentação. Apesar desta não ser uma ideia nova, vimos que o ruido programático dos testes pode atrapalhar. Terminamos vendo que o Cucumber resolve o problema do ruído na documentação executavel seprando a definicao das funcionalidades e cenários do código que faz tudo funcionar.

Abraços e até a próxima,

Sérgio Junior

Abaixo está a implementação completa da funcionalidade descrita neste post:

require 'lib/conta/conta'
 
Dado /^que a "([^\"]*)" possui "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
   conta = obter_conta_pelo_nome(nome_da_conta)
   atributo = change_spaces_for_underlines(atributo)
   conta.instance_variable_set( "@#{atributo}", valor.to_f )
end
 
Dado /^que a "([^\"]*)" esta bloqueada$/ do |nome_conta|
   conta = obter_conta_pelo_nome(nome_conta)
   conta.bloqueada = true
end
 
Quando /^eu transferir "([^\"]*)" reais da "([^\"]*)" para "([^\"]*)"$/ do |valor, origem, destino|
  conta_origem = obter_conta_pelo_nome(origem)
  conta_destino = obter_conta_pelo_nome(destino)
  begin
    conta_origem.transfere :para => conta_destino, :valor => valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Quando /^eu sacar "([^\"]*)" reais da "([^\"]*)"$/ do |valor, nome_conta|
  conta = obter_conta_pelo_nome(nome_conta)
  begin
    conta.saca valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Quando /^eu depositar "([^\"]*)" reais na "([^\"]*)"$/ do |valor, nome_conta|
  conta = obter_conta_pelo_nome(nome_conta)
  begin
    conta.deposita valor.to_f
  rescue Exception => e
    @erro = e
  end
end
 
Entao /^"([^\"]*)" devera ter "([^\"]*)" de "([^\"]*)" reais$/ do |nome_da_conta, atributo, valor|
  conta = obter_conta_pelo_nome(nome_da_conta)
  atributo = change_spaces_for_underlines(atributo)
  conta.instance_variable_get( "@#{atributo}" ).should == valor.to_f
end  
 
Entao /^um erro de "([^\"]*)" deve ser exibido$/ do |mensagem|
  @erro.message.should == mensagem
end
 
private
  def obter_conta_pelo_nome(nome_da_conta)
    conta_simbolo = name_to_symbol(nome_da_conta)
    @contas ||= {}
    if @contas[conta_simbolo]
      conta = @contas[conta_simbolo]
    else
      conta = Conta.new
      @contas[conta_simbolo] = conta
    end
  end
 
  def change_spaces_for_underlines(name)
    name.gsub(/\s/,'_')
  end
 
  def name_to_symbol(name)
    change_spaces_for_underlines(name).to_sym
  end

def seja_educado(saudacao, pessoa)
  puts "#{saudacao} #{pessoa}"
end
 
seja_educado("Bom Dia","Iuri")
=> Bom Dia Iuri

Essa foi muito fácil! Afinal de contas já sabemos “tudo” sobre criar métodos em ruby.
Então vamos tornar o exemplo mais interessante. Eu quero poder usar o metodo seja_educado das seguintes formas:

seja_educado("Boa Tarde","Joao")
=> Boa Tarde Joao
seja_educado("Joao")
=> Olá Joao

Uma típica solução seria usar o velho truque do metodo sobrecarregado então vamos tentar.

def seja_educado(saudacao, pessoa)
  puts "#{saudacao} #{cidadao}"
end
 
def seja_educado(pessoa)
  puts "Ola #{pessoa}"
end
 
seja_educado("Joao")
=>Olá Joao
seja_educado("Bom dia", "Luiz")
=> ArgumentError: wrong number of arguments (2 for 1)

Porque este erro meu Deus? Porque?

Bem, a triste verdade é que Ruby não da suporte sobrecarga de métodos. Quando escrevemos o metodo pela seja_educado pela segunda vez, na verdade o que fizemos foi redefini-lo e nao criar um outro metodo de mesmo nome. Por isso, quando executamos: seja_educado(“Boa dia”,”Luiz”) obtivemos o erro relacionado ao numero argumentos.

Tem algum jeito de resolver isso?

Sim, a falta de sobrecarga de métodos pode ser compensada se utilizarmos alguns recursos do ruby como por exemplo: o de valor default para argumentos. Vamos fazer com que o argumento saudacao receba a string “Ola” sempre que alguem “se esquecer” de informar um valor para ele. O código fica assim:

def seja_educado(saudacao="Ola", pessoa)
  puts "#{saudacao} #{pessoa}"
end

Ao colocar o sinal de = e a string “Ola” ao lado do argumento saudacao dizemos que se ninguem mandar valor para este argumento, entao ele deverá assumir o valor “Ola”. Desta forma as chamadas abaixo fucionarão:

seja_educado("Iuri")
=> Ola Iuri
seja_educado("Bom dia","Luiz")
=> Bom dia Luiz

Incrementando o Exemplo

Agora eu quero evoluir ainda mais o nosso metodo seja_educado. Eu quero ser capaz de informar zero, um ou vários nomes de pessoas para cumprimentar, ou seja, as seguintes chamadas de método devem ser suportadas:

seja_educado("Iuri")
seja_educado("Bom dia", "Luiz")
seja_educado("Bom dia", "Luiz", "Iuri", "Sergio")

Bom como já sabemos apenas as duas primeiras irão funcionar, já a última chamada vai ocasionar um ArgumentError. O problema agora é que a quantidade de pessoas que devem receber a saudacao pode variar de zero até qualquer número.

Como resolver isso?

Para nossa sorte ruby possui um tipo de argumento conhecido como opcional (optional argument), que muito se parece com o varargs do Java. Para usar este tipo de argumento, basta pôr um asterisco (estrela) na frente do argumento, após fazer isso seu argumento poderá receber zero ou N valores.
Vamos então aplicar o recurso de optional argument e fazer um teste:

def seja_educado(saudacao="Ola", *pessoas)
  if pessoas.empty?
    print "#{saudacao} "
  else
    pessoas.each { |p| print "#{saudacao} #{p} " }
  end
end
# Teste com varias pessoas
seja_educado("Bom dia", "Luiz", "Iuri", "Sergio")
=>Bom dia Luiz Bom dia Iuri Bom dia Sergio
# Teste com apenas uma pessoa
seja_educado("Bom dia","Joao")
=>Bom dia Joao
# Teste sem pessoas
seja_educado("Bom dia")
=>Bom dia

Tivemos que modificar um pouco o método, e acabamos usando o método each que pode receber blocos de código como parâmetro, se você não “pegou” bem essa parte de uma olhada aqui.
Agora sim hein…. Podemos usar o método seja_educado com nenhuma ou uma quantidade arbitrária de pessoas, como vimos no exemplo anterior.

Momento de Reflexão

Uma ideia me veio a cabeça agora. Repare que no método seja_educado, o argumento saudacao possui um valor default (padrão). O que pode acontecer se utilizarmos este método informando apenas o nome de uma pessoa, ou informando o nome de duas, ou quem sabe com três pessoas? Vamos ver:

#teste com apenas uma pessoa
seja_educado("Luiz")
=>Luiz
#teste com duas pessoas
seja_educado("Luiz","Iuri")
=>Luiz Iuri
#teste com tres pessoas
seja_educado("Luiz","Iuri","Sergio")
=>Luiz Iuri Luiz Sergio

Curioso! Em nehuma das chamadas anteriores o valor default do argumento saudacao foi usado. *(1)
E se tentarmos inverter a ordem dos argumentos? Vamos ver no que vai dar: *(2)

def seja_educado( *pessoas, saudacao="Ola" )
  if pessoas.empty?
    print "#{saudacao} "
  else
    pessoas.each { |p| print "#{saudacao} #{p} " }
  end
end
# Agora nosso novo teste
seja_educado("Luiz")
=>syntax error, unexpected tIDENTIFIER, expecting tAMPER or '&'
def seja_educado(*pessoas,saudacao="Ola")

def metodo_teste( a, b="oi", *c )
  p "a = #{a}, b = #{b}, c = #{c}"
end
metodo_teste( 1,2,3 )
=> "a = 1, b = 2, c = 3"
metodo_teste( 1,2,3,4,5 )
=> "a = 1, b = 2, c = 345"
metodo_teste( 1,2 )
=> "a = 1, b = 2, c = "
metodo_teste( 1 )
=> "a = 1, b = oi, c = "