Aruba - Como testar suas linhas de comando com Cucumber
Que tal testar seus scripts ruby com Cucumber? Agora é possível e da mesma forma que testamos as nossas aplicações web. Aruba, do mesmo criador do Cucumber, fornece uma ambiente familiar para testes de saída, status e comandos do sistema. Abaixo um pequeno exemplo para um teste de status de saída:
Para usar aruba, basta instalar a gem:
sudo gem install aruba |
e, em seguida, adicione em seu env.rb ou em qualquer arquivo em features/support
require 'aruba' |
Modismo - Ágil e Rails
Todos aqui devem saber que eu sou um defensor de Metodologias Ágeis e de Rails. Tive o prazer de começar com Rails a uns 3 anos atrás, e a uns 2 anos com Ágil - Scrum, XP, Lean. Durante este tempo tenho colhido bons frutos das minhas escolhas e, como bom evangelista, eu prego aquilo que acredito e o que faço.
Mas nem tudo são flores, tenho me deparado com algumas coisas que me deixaram um pouco frustrado: O modismo. Modismo? Sim, Modismo. Modismo, é aquela tendência de comprar, fazer, falar e ser o que todos são no momento, ou seja, um indivíduo sem idéias fixas e definidas, que são guiados pela mídia - A ditadura que domina a cabeça das pessoas.
Mas isto é legal. Todos usando Rails e sendo "ágil"!!! Não é este o problema, vamos fazer uma análise: Quando comecei com Rails, tínhamos poucos desenvolvedores, tanto no Brasil quanto lá fora, e era mais do que nossa obrigação divulgar. Era o que podíamos fazer para conseguir expandir o mercado de trabalho e poder trabalhar profissionalmente com aquilo que aprendemos a gostar. E sabe o que tínhamos na época? Um monte de feras como o Akita, Tino Gomes, Lucas Húngaro, Tapajós, Ronaldo Ferraz, Rodrigo (caffo), Demetrius Nunes (dema), Bruno Miranda e outros. Isto era muito bom, porque era uma comunidade super pequena mas de alto nível, qualquer assunto levantado era discutido por quem sabia o que estava falando. Hoje nós temos uma comunidade “inchada”, com poucos excelentes programadores Ruby/Rails e um monte de “usuários” do framework.
Conheço um monte de “usuários” Rails que não sabem nada de Ruby. Alguns outros chegam a chamar o Rails de linguagem, pasmem, isto é o cumulo da ignorância. A rails-br se tornou uma lista de newbie, com perguntas que são facilmente respondidas fazendo uma busca no Google ou no próprio grupo, tornam-se extensas threads inúteis.
O mesmo está acontece com as metodologias ágeis: todos estão falando de ágil, cursos novos, certificações e um monte de blah, blah, blah. Está cheio de consultores e consultorias pronto para moldar um Scrum para sua empresa. Conseguem criar um produto "bonito" e cheio de marketing sem entender os conceitos, regras e fundamentos das metodologias. São apenas aberrações.
Já trabalhei com diversas metodologias, incluindo RUP, Espiral, Cascata e Incremental - que eu lembre foram estes, e o que diferencia estas metodologias tradicionais são o enfoque e os valores, a idéia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos, a preocupação de gastar menos tempo com documentação e mais com a implementação. Mas para alcançar resultados é exigido muito de cada pessoa, da equipe e da organização, precisa de comprometimento, sacrifício, acreditar – ter fé, saber trabalhar em equipe, o que diga-se de passagem é impossível para a maioria das pessoas - no seu orgulho besta e infantil. Não adianta rotular como ágil sua empresa e não ter atitude. Melhor continuar sem o rótulo ou você vai ferrar com seu projeto/empresa.
Tenha em mente que Ruby não é a solução para tudo, e Ágil também não. O importante não é o que você usa: é quem e como usar. As pessoas ficam entusiasmadas com tudo que escutam e acabam por colocar o carro na frete dos bois.
Leia também:
- Agile indo para o buraco?
- Agile não é para todos
- The Decline and Fall of Agile
- The Decline and Fall of Agile
- Skipping Their Vegetables
- Rails não é solução para tudo
- Como Ruby on Rails pode o tornar um programador pior
Ágil vs. Cascata
Tradução: "Está tudo OK para você?"
Achei esse artigo interessante, o título original é "Is everything OK for you?" - the question you should never ask your developers. É minha primeira, de muitas outras, traduções que pretendo trazer para vocês:
"Está tudo OK para você?" - A pergunta que você nunca deve fazer ao seus desenvolvedores
Eu falei com um amigo meu recentemente e ele queixou-se sobre o seu líder (na verdade ele estava me explicando por que razão o seu líder era ruim). Não é sobre sua personalidade ou atitude, mas meu amigo queixa-se das perguntas que seu líder fazia, por exemplo:
- "Está tudo OK para você?"
Muito bem... Como você pode responder a esta pergunta? Será que ele está perguntando sobre minha vida privada? sobre meu ambiente de trabalho? Sobre minhas tarefas? O que ele espera como resposta? Se quase tudo está OK para mim, mas eu tenho algumas idéias sobre como melhorar a performance da equipe, devo responder "Sim", "Sim, mais..." ou "Não"? Na minha humilde opinião, está é uma pergunta errada - isto demonstra falta de respeito, porque meu líder não se importante realmente com a resposta, é igual a "Como vai você?".
Se você é líder de Equipe ou Projeto ou está a frente de uma equipe de desenvolvimento você deve ler este artigo e conhecer o ponto de vista dos seus engenheiros.
Por que essas questões não são boas ?
Vamos supor que eu trabalho em uma equipe e vejo que estamos produzindo um código que não está sendo bem testado, e a nossa equipe não tem qualquer ferramenta de integração contínua. Eu gostaria de compartilhar minhas idéias sobre como lidar com estes problemas, mais meu líder é difícil de compreender e está sempre ocupado.
Embora ele sempre me faça perguntas como "Você está OK com a equipe?", "Está tudo OK para você?", eu devo falar sobre Integração contínua e dos problemas de testes que temos aqui? Será que é um bom momento para falar sobre minhas idéias? Estas questões não me incentivam em expor os verdadeiros problemas que a nossa equipe possa ter.
Quais perguntas os engenheiros aguardam?
Os engenheiros são pessoas concretas e eles esperam perguntas concretas. Claro, que às vezes é dolorido, mas o que estamos fazendo é freqüentemente tão complexo que fazer perguntas gerais refere-se a nada - você realmente quer saber sobre o nada? (Será que não é um exemplo de gerenciamento?). No exemplo do meu amigo, as questões do seu líder são genéricas demais.
Seria muito mais fácil se ele pergunta-se:
- Você vê qualquer problema no projeto que estamos desenvolvendo?
- Você pensa que os nossos processos de desenvolvimento estão corretos? Você tem qualquer idéia sobre como podemos melhorá-los?
- Você precisa de alguma ajuda no que está fazendo?
- Você tem alguma idéia como ...?
Use sua criatividade com as pessoas
Se você tiver gerenciando uma equipe de desenvolvimento de software você deve aprender quais questões deve fazer. Você deve fazer perguntas que não se pode responder com um simples "sim" ou "não". Faça perguntas que permitam aos seus engenheiros se expressarem, exporem seus sentimentos, idéias, medos. Seus engenheiros são criativos (Eu tenho certeza disso) - deixe eles falar com você e compartilhar suas idéias, deixe-os pensar e criar!
Faça perguntas certas - você receberá as respostas certas
Se você estiver fazendo perguntas erradas como "Está tudo OK para você?" não espere uma resposta certa (o que significa). O que você espera do seu engenheiro quando faz uma destas pergunta? Você espera que ele lhe fale sobre sua semana? Peça a ele sobre o final de semana. Você está esperando que ele fale sobre seus filhos? Pergunte sobre seus filhos.
Fazer perguntas corretas é a chave para uma boa e aberta comunicação - e é o fator mais importante para ter uma equipe eficiente de desenvolvimento (ver também as Práticas de XP). Fazer perguntas corretas, você vai obter respostas coerentes ou seja, a resposta correta para sua questão - sem equívocos. Se você quiser fazer perguntas gerais, só para ver se não está dormindo (mante-los acordados?), basta dizer "Olá!". Se você quiser fazer uma pergunta e não espera qualquer resposta (ping?) - Então não faça!, você não vai ganhar respeito fazendo isto.
Se você estiver a sorte de trabalhar em um ambiente Ágil, esse problema pode ser resolvido de alguma forma durante o Daily Scrum Meeting, onde você pode compartilhar suas idéias e problemas, ou através das retrospectivas, quando a equipe é encorajada a analisar a sua maneira de trabalhar.
Conselho
Se você é um líder de equipe ou projeto, significa que você é esperto o bastante para encontrar perguntas certas que deixarão seus desenvolvedores falarem sobre os verdadeiros problemas e soluções reais. Faça suas perguntas freqüentemente e você verá quantas oportunidades irá encontrar ao seu redor.
Tome cuidado, ao fazer perguntas genéricas. Pode ser pior do que não fazer nenhuma pergunta.
Eu estou muito curioso sobre suas opiniões:
- Você é um engenheiro (desenvolvedor) e estão lhe fazendo essas perguntas sem sentido? Qual é a sua resposta?
- Você que é líder de equipe, faz estas perguntas? O que espera nas respostas? Por que você está perguntando?
Fique a vontade para compartilhar suas idéias aqui.
