Posts made in October, 2009
Rails Summit – Carlos Brando
Carlos Brando do blog Nome do Jogo em sua palestra “Yet Another Ruby Framework – Como o Rails funciona por dentro” apresentou um pouco sobre a sua experiência no desenvolvimento de um framework em ruby para criação de aplicativos sociais baseados na plataforma open social, o sociably.
Carlos Brando
Depois de tentar adaptar o rails para atender a essa necessidade e chegar a conclusão que essa não era a melhor opção, Brando e sua equipe enfrentaram o desafio de desenvolver o framework que será disponibilizado, segundo ele, em código livre no futuro. Foram apresentados alguns conceitos que devem ser pensados antes de se construir um framework web como arquiteturas push-based e pull-based . Brando ressaltou ainda a importância de se considerar o projeto rack, ORM para banco de dados e geradores de código.
Veja os slides de Brando no SlideShare:
Rails Summit – Gregg Pollack
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
Caching
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.
Banco de Dados
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:
- Bullet Plugin – Criado por Richard Huang, este plugin pode melhorar a performance de sua aplicação diminuindo a quantidade de consultas que realizadas no banco de dados. Para maiores informações ouça este podcast da EnvyLabs.
- Rails Indexes – Ferramenta que ajuda-o a encontrar indices que deveriam existir em seu banco de dados.
- Scrooge Plugin – Otimiza consultas ao banco de dados para que seja obtido somente os dados que realmente forem necessários para construir as páginas requisitadas.
Prevençao de Bloat
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:
- rack-bug – Barra de ferramentas para aplicações Rack que exibe informações como tempo de CPU e SQL.
- memorylogic – Acrescenta IDs de processos e uso de memória nos logs do Rails.
- oink – Encontra causas de incremente no tamanho do heap de memória da aplicação.
Escalabilidade
- rubber – Um plugin capistrano e rails que facilita deploy, gerenciamento e escalabilidade para Amazon EC2.
- cloud crowd – Gerenciamento de procesamento paralelo de processos de segundo plano.
- Mad Mimi – Aplicativo de e-mail marketing que possui um API de fácil integração.
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!
Rails Summit 2009 – Chad Fowler
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.
Chad Fowler por Daniel Cukier
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?
Two dragons... (the gate to the end) por Giampaolo Macorig
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!
Retrospectivas Ágeis
Restrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma execente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas:
- O que está indo bem?
- O que pode ser melhorado?
Alguns preferem perguntar:
- O que devemos parar de fazer?
- O que devemos continuar fazendo?
- O que devemos começar a fazer?
No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima restrospectiva, a equipe seja melhor do que era na última.
PDCA
Alguns dias atrás o Vinicius Teles da Improveit twitou o link de uma palestra que foi apresentada no Google por by Esther Derby e Diana Larsen sobre restrospectivas ágeis. As duas são especialistas sobre assunto e já até escreveram um livro que pode ser comprado por $20 em PDF. Vale a pena assitir a palestra:
Creio que uma das coisas mais importantes que as duas destacaram na apresentação é a necessidade de dividir as responsabilidades de tomar as ações entre os membros da equipe para que as mudanças realmente aconteçam. De nada adianta reuniões de retrospectivas que apontam problemas que nunca são resolvidos por ninguém. Para evitar que isso aconteça na Bluesoft, ultimante em toda reunião de restrospectiva nós lemos os itens que identicamos como coisas que poderiam ser melhoradas no sprint anterior e então rapidamente discutimos se realmente já estão resolvidos, e caso não estejam, voltamos a incluir o item e insistímos até que finalmente seja resolvido.
Um outro ponto interessante levantando por meu amigo Ricardo Almeida, é que devemos tomar cuidado para não transoformar a reunião de restrospectiva em uma mera busca de culpados. O foco deve estar sempre na solução.
No inicio desde ano Linda Rising apresentou na QCon Londres 2009 um tutorial sobre retrospectivas, uma de suas dicas, foi que as pessoas anotassem os acontecimentos bons e ruins ao longo do sprint em post-its para que não os esquecessem. Na Bluesoft, reservamos uma área do Kanban para que estes post-its sejam anexados.
Para maiores informações sobre retrospectivas, visite o Agile Restrospective Resource Wiki, um wiki (em inglês) com uma série de dicas, exercícios e ferramentas para realização de retrospectivas. O site cmcrossroads possui uma lista bem completa de sites onde você pode encontrar excelente material sobre o assunto.
Boa Restrospectiva!
