Fábio Akita, recentemente publicou uma entrevista com o famoso Uncle Bob Martin, grande personalidade da comunidade de desenvolvimento de software, métodos ágeis e software craftsmanship.
Uncle Bob é, sem dúvida, um grande exemplo para todos nós desenvolvedores de software, apesar de seus 46 anos de experiência com desenvolvimento de software, ele nunca parou de aprender. Programadores não devem nunca pensar que a linguagem que aprendem na faculdade ou que utilizam agora são A linguagem, ao invés disso, devem abrir suas mentes e estar sempre aprendendo uma nova linguagem de programação, disse ele.
Se você programar somente em Java, por exemplo, e não for além disso, você será um programador muito fraco, porém se for em busca de aprender novas linguagens e aprender novos paradigmas você voltará para o seu Java com muito mais conhecimento e será ainda mais eficiente, afirmou Bob. “Eu, por exemplo, estava aprendendo Ruby e agora estou estudando Clojure”, disse.
Depois de ter escrito o livro Clean Code (Código Limpo), Bob está escrevendo um outro livro agora, chamado Clean Coder (Codificador Limpo), falando sobre como gerenciar o tempo, como lidar com pressões, como estimar, como lidar com chefes, etc. Estamos aguardando ansiosos pela nova publicação.
Bob disse que toda boa idéia que fica popular, tornar-se um hype, muita gente usa isso para seus próprios interesses, muitas vezes invertendo os propósitos. Cuidado! Escolha bem quem o ajudará a aprender métodos ágeis. Volte as fontes, busque os livros de quem estava lá no inicio. Martin Fowler e Kent Beck, são ótimas referências.
Muita gente está agora em ágil, defendo ágil, alerta Bob, mas está apenas pela corrida do ouro, ou seja, não conhecem e nem acreditam nos princípios e valores dos métodos ágeis, apenas estão ensinando ou utilizando ágil para manter-se lucrativos em virtude do movimento do mercado que está sendo impulsionado pelo hype.
Veja o vídeo da entrevista, que foi gentilmente disponibilizado sob a licença Creative Commons pelo Akita.
http://blip.tv/play/AYHm7HIC
Siga os conselhos de Uncle Bob Martin, aprenda como um louco, leia, leia, leia.
Depois de ter me impressionado com a qualidade do evento Rails Summit 2008 e a força da comunidade Ruby, não poderia de forma alguma deixar de marcar presença novamente este ano. O evento foi realizado nos dias 13 e 14 de outubro na cidade de São Paulo no auditório Elis Regina do Anhembi, e com uma organização novamente fantástica, contando com excelentes palestrantes, e uma audiência que sem dúvida está acima da média, o evento foi mais uma vez um sucesso total. Parabéns Akita e equipe Locaweb!
Nesta série de posts que começa com este, quero registrar os pontos mais importantes e minhas principais impressões sobre a edição 2009 do evento.
Chad Fowler deu largada com a apresentação do keynote “Insurgência Ruby on Rails” em que explorou estratégias para insurgências de Ruby on Rails em ambientes pouco amigáveis. Logo no inicio da palestra Chad digiriu-se aos desenvolvedores dizendo “parem de fazer coisas que vocês sabem que estão erradas“, sabemos que todos os dias, muitos de nós desenvolvedores realizamos nosso trabalho de forma burocrática e pouco produtiva, nem sempre utilizamos as melhores práticas e nem sempre temos coragem suficiente para transformar essa realidade.
Segundo Chad, ao se tentar introduzir desenvolvimento ágil, ruby, rails e novas tecnologias nas organizações geralmente nos deparamos com monstros guardiões que tentam proteger suas empresas de mudanças a todo o custo, e eles o fazem por causa do fenômeno FUD (Fear, uncertainty and doubt – medo, incerteza e dúvida), por alguma razão eles tem medo, medo de sair da zona de conforto, medo de lutar contra a inércia, medo perder suas posições, medo de errar, e é então que buscam todo tipo de argumento estúpido para tentar evitar algo novo seja feito.
Esse é o caso da velha conversa mole de que rails não escala, isso graças aos problemas que o twitter, um famoso case de rails, enfrentou no passado, “o twitter não escalava por causa de sua arquitetura” disse Chad. A lista de desculpas dos tais guardiões não pára por aí, eles dizem que ruby é lento, “mas é claro que é, e quem se importa? O ruby é responsável por em torno de apenas 6% do tempo de request de uma aplicação web tradicional” afirma Chad. Eles perguntarão “mas dá pra fazer isso? e aquilo?” e não vão parar até que finalmente encontrem alguma coisas que lhes sirva de desculpa. Mas afinal de contas quem são esses caras? Será que você tem sido um deles?
Para ajudá-lo na batalha contra os guardiões, Chad recomendou a leitura do artigo “beating the averages” de Paul Graham e acrescentou procure fazer as coisas de forma gradual, se você tentar fazer uma mudança massiva, provavelmente vai acabar fazendo uma bagunça. Você pode até mesmo começar a usar rails como uma ferramenta case, é possível fazer algo parecido com o que propõe o naked objects com java. Use também Ruby para criar scripts. Use Ruby para testar java, .net, c++. Use Ruby para gerar código. Use Ruby como template engine. Automatize o seu deployment com capistrano. Use Ruby para construir protótipos de UI. Crie metas mensuráveis, meça e apresente resultados!
Um outro ponto importante é que para introduzir Rails você não precisa necessariamente jogar fora o seu investimento anterior, IronRuby, JRuby e etc estão aí para entre outras coisas, te ajudar com isso, mas tome cuidado para não acabar escrevendo código Ruby da mesma forma que você escreve código Java ou C#, entenda que os paradigmas são diferentes e não tente abrir a casa nova com a chave da velha.
Chad recomendou ainda a leitura de sua série de artigos “The Big Rewrite” e enfatizou conserve a paixão pelo seu trabalho.
Assista a palestra na integra gentilmente gravada e disponibilizada por Hugo Borges:
Em breve publicarei sobre mais palestras, assine o feed e acompanhe!