Publicado por: andrefaria em: 30 Novembro 2009
O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.
Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.
O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.
O termo foi criado com a publicação do livro de Pete McBreen em 2002. Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.
Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.
Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.
Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.
Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves e simples de usar.
Use ferramentas para teste como jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.
A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.
Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.
Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo
Publicado por: andrefaria em: 19 Outubro 2009
Depois da palestra de Chad Fowler, Gregg Pollack do scaling rails series apresentou “On The Edge Of Rails Performance“. Gregg falou sobre diversas estratégias e ferramentas que podem ajudar a tornar um aplicativo rails mais performático. A seguir veja os principais tópicos e soluções apresentados.

Gregg Pollack no Rails Summit
Gregg abordou caching em diversos níveis, tais como page caching, fragment caching, object caching, memcache e client-side caching (etags & last-modified), falou também sobre a importância de saber a hora certa de otimizar e não otimizar prematuramente.
Em se falando banco de dados, é inevitável que este tenha grandes chances de se tornar um gargalo, por isso, não abuse dele. Para ajudá-lo a melhor utilizar seu banco de dados, Gregg sugere as seguintes ferramentas:
De acordo com a Wikipedia, Code Bloat é a produção de código que desnecessariamente longo, lento e/ou desperdice recursos. Para prevenção de bloat, Gregg apresentou as seguintes ferramentas:
Assista a palestra na integra que foi gentilmente filmada e disponibilizada por Hugo Borges:
Fique ligado, informações sobre as outras palestras serão disponibilizadas em breve!
Publicado por: andrefaria em: 15 Outubro 2009
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!