rails summit | André Faria Gomes

Rails Summit – Gregg Pollack

Posted by andrefaria on Oct 19, 2009 in Eventos | 0 comments

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

Posted by andrefaria on Oct 15, 2009 in Agile, Eventos | 0 comments

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!

ruby is slow? of course it is but who cares? ruby is reponsible of about 6% of a web request in typical application.

Participação no "Rails Summit Latin America"

Posted by andrefaria on Oct 20, 2008 in Agile, Eventos, Software | 3 comments

Nos dias 15 e 16 de outubro participei do Rails Summit Latin America 2008. O evento recebeu grandes nomes do desenvolvimento de software e da comunidade Ruby On Rails, o nível técnico foi inquestionável. Os palestrantes apresentaram temas como testes, qualidade, empreendedorismo, desenvolvimento ágil, open source, REST, Git, Escalabidade, e claro, Ruby e Rails.

Auditório Principal

Como o Alexandre Gomes falou “a impressão que me deu é que a grande bandeira desta comunidade não é a tecnologia em si, mas os princípios em que acreditam.” Assino em baixo.

Não entrarei em grandes detalhes sobre as palestras porque tem gente que já falou muito bem, mas registrarei as principais lições que aprendi nestes dois dias de evento.

O Dr. Nic Williams e o Chris Wanstrath falaram bastante sobre a importância de contribuir com projetos Open Source, ser ativo na comunidade e gastar menos tempo com coisas que podem não ser assim tão importantes. Os grandes conselhos foram:

Aprenda Git
Aprenda Testes Unitários
Aprenda a Testar Primeiro
Crie um Blog para compartilhar coisas que você aprende
Mantenha um Currículo online
Participe de reuniões de desenvolvimento (como o DojoSP, por exemplo)
Concerte código de outras pessoas
Responda perguntas em fóruns
Traduza artigos para mais pessoas terem acesso.

Jay Fields, Danilo Sato e David Chelimsky falaram sobre Testes. Licões aprendidas:

Selenium é lento e grandes suites podem ser insustentáveis, você não precisa testar tudo, mantenha o foco no que for mais importante.
Remova débitos técnicos.
Faça o que funciona bem para você (ou sua empresa).
Fique atento aos Code Smells.
Aprenda Behavior Driven Design (BDD = DDD + TDD + Aceptance Test Driven Planning) e teste comportamento.
Defina os testes de aceitação nas reuniões de planejamento.
Use o código de teste para comunicar suas intenções e o “você do futuro” vai te agradecer.
Teste não é custo, é investimento!

Pra fechar com chave de ouro, Obie Fernandez apresentou um pouco do dia-a-dia da Hashrocket (empresa fundada por ele) e como eles aplicam os quatro princípios do manifesto ágil. Sem sombra de dúvidas, essa foi a palestra que eu mais gostei, por isso comentarei um pouco sobre ela.

Para aplicar o primeiro princípio “Indivíduos e Iterações são mais importantes do que processo e ferramentas” eles fazem o seguinte:

Programação em par: Na Hashrocket, a programação em par acontece com um computador, dois desenvolvedores, um monitor dois teclados e dois mouses. Segundo Obie, ao programar em par, o código é revisado o tempo todo e os desenvolvedores se tornam seniors muito rápido.
Nada de Entrevistas: Quando é necessário contratar novas pessoas para equipe, um post é publicado no blog informando que eles contratando. Quem se enquadrar melhor no perfil é convidado a trabalhar por uma semana (em par), algo como um trial…
Não cresça demais e forme equipes Pequenas: Porque é fundamental manter as pessoas unidas. Forme equipes auto-organizáveis de 2 a 4 pessoas e escolha as pessoas certas, não se tem gerentes de projetos.
Guest Star Program: Faz-se convites para grandes estrelas da comunidade de desenvolvimento de software para que estes trabalhem junto com a equipe durante um determinado período de tempo. Assim é possível trocar experiências e aprender com os melhores.

Para aplicar o segundo princípio “Indivíduos e Iterações são mais importantes do que processos e ferramentas“:

TAFT – Test All The Fucking Time: Esse é o título de uma apresentação do Brian Liles cujo a principal mensagem é Teste Todo o Tempo.
RSpec: Utiliza-se esta ferramenta que permite escrever testes em forma de especificação executável.
Mínimo Produto Viável: Desenvolve-se o mais importante, o que realmente dá valor ao software.
Releases Curtos: Entrega-se software em pequenos intervalos.

Para aplicar o terceiro princípio “Colaboração do Cliente é mais importante do que negociação contratual”:

OnSite Custumer: O Cliente (ou alguém que responda por ele) deve fazer parte da equipe.
Visual Design First: O Design Visual deve estar pronto antes do inicio do desenvolvimento do software.
User Stories: Utilizam user stories como especificação, as user stories devem conter narrativas sobre funcionalidades a serem implementadas no software, devem ter um critério de aceitação e devem ser estimadas.
Master Service Agreement: negociação contratual da Hashrocket.

Para aplicar o terceiro princípio “Responder as mudanças é mais importante do que seguir um plano”:

Pivotal Tracker: Utilizam o Pivotal Tracker como ferramenta colaborativa para gerenciamento de projetos baseados em user stories.
Reuniões de Pé: São reuniões diárias muito conhecidas em metodologia ágeis como XP e Scrum em que a equipe geralmente reponde a três perguntas: “O que fiz desde a última reunião?”, “O que farei até a próxima reunião?” e “Quais são meus impedimentos?”. Essa reunião proporciona transparência e mantém todos informados da situação atual do projeto.
Pivotal Standup: Uma reunião onde as pessoas respondem rapidamente “Tenho alguma coisa interessante para compartilhar com todos?“.

Para concluir sua apresentação Obie apresenta o princípio mais importante que é o grande segredo do sucesso: “Divirtam-se Juntos“, e mostrou algumas fotos de situações (participando em reuniões de grupos de usuários, passeando de barco, tocando instrumentos musicais, jogando vídeo games, indo à praia, bebendo, pulando na piscina, etc) em que ele e sua equipe estavam se divertindo.

Para maiores informações, visite o site do Obie, o site da Hashrocket, o blog do Obie, e sua galeria do Flickr.