BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Gregg Pollack e o How-To de Escalando Rails

Gregg Pollack e o How-To de Escalando Rails

Favoritos

Gregg Pollack do Rails Envy Podcast e envycasts tem tratado o tópico de escalar Ruby on Rails numa série de podcasts, em cooperação com a New Relic, chamada Escalando Rails. Gregg Pollack mora em Orlando, Florida onde produz mídia educacional para sua companhia, Rails Envy. Ele é muito ativo na comunidade Orlando Tech, ajudando a organizar o BarCampOrlando, o Grupo de Usuários Ruby de Orlando, e CoLab, o primeiro espaço de Orlando de co-working.

InfoQ teve a oportunidade de conversar com Gregg sobre os novos screencasts e como eles ajudarão desenvolvedores a escalar Ruby on Rails.

Robert Bazinet (RB) : Vejo que vocês começaram a série envycasts com o tema de escalar e agora com a nova série Escalando Rails. É uma coincidência?

Gregg Pollack (GP) : Eu percebi alguns meses atrás que queria fazer alguns envycasts sobre Escalando Rails, mas cheguei ao ponto que percebi que deveria começar com o básico, com Ruby. Por isso eu lancei inicialmente um envycast “Escalando Ruby”. O próximo envycast da série deveria então “Escalando Rails”, mas tive a sorte de achar patrocínio com a New Relic que me permitiu lançá-lo gratuitamente.

RB : Quais foram as razões para finalmente decidir fazer a série Escalando Rails?

GP : Há várias razões:

  • Dar a desenvolvedores Rails toda a informação necessária para escalar com sucesso uma aplicação Rails. Um desenvolvedor talvez nunca precise usar estas técnicas, mas esperamos que os vídeos lhes deem a confiança para dizer a seus clientes que eles podem criar aplicações Rails que vão lidar com milhões de usuários simultâneos.
  • Mostrar a desenvolvedores de outras linguagens o quanto é fácil escalar uma aplicação Rails.
  • Desencorajar, esperamos, a percepção que algumas empresas ainda tem de que “Rails Não Escala”. Agora qualquer desenvolvedor Rails nessa situação pode indicar os screencasts Escalando Rails e dizer “Rails escala, e aqui está como”.

RB : Como você teve a ideia dos envycasts e depois do Escalando Rails?

GP : Duas das minhas maiores paixões são produção de filmes e desenvolvimento web. Os envycasts me proporcionaram um jeito de combinar essas duas paixões e talvez fazer dinheiro suficiente para alimentar meus filhos. Honestamente, não estou fazendo fortuna nesses vídeos, sou pago mais por contrato, mas como disse, adoro tudo isso.

O objetivo dos Envycasts é fornecer vídeos educacionais num formato divertido.

RB : Parece que a New Relic tem interesse em escalar Rails uma vez que sua série é parte do Rails Lab deles. Gostaria de explicar esse relacionamento e o sobre o que são esses screencasts?

GP : New Relic tem interesse em ajudar no crescimento da comunidade Rails, e encorajando a adoção do framework Rails em empresas. Faz sentido, eles querem mais clientes e um jeito de conseguir isto com uma comunidade pequena como a nossa é investindo na própria comunidade. Já vimos a Engine Yard fazer isso no passado, investindo nos projetos Rubinius e Merb.

A New Relic criou o site Rails Lab para produzir conteúdo sobre os tópicos de performance em Rails. Eles patrocinaram meus vídeos para que eu pudesse disponibilizá-los de graça no Rails Lab.

RB : O que você vê no futuro do Rails sendo adotado pelas empresas? Você vê esses screencasts como uma maneira de ajudar o Rails a chegar lá?

GP : Estou aos poucos cada vez mais vendo jovens desenvolvedores dentro de empresas grandes convencendo as gerências a usar Rails em projetos. Geralmente começa com aplicações internas, e aos poucos vai para produção. Não tenho dúvida de que veremos mais grandes empresas 'de nome' no próximo ano lançando suas próprias aplicações Rails em produção.

Agora é uma excelente hora para começar a usar Rails, especialmente por causa da economia. Com Rails podemos fazer mais com menos código e o custo de manutenção (ao menos na minha experiência) é muito menor que outras linguagens e frameworks.   Empresas maiores que perceberem mais cedo que outras poderão manter uma vantagem sobre a concorrência de um jeito mais fácil.

Gostaria de ter a esperança de que algum desenvolvedor por aí possa usar estes vídeos para convencer seu chefe a usar Rails no seu próximo projeto. Só espero.

RB : O que você tem planejado para futuros screencasts de Rails sobre escalando Rails?

GP : Honestamente não sei no momento, 13 episódios estão disponíveis agora:

  • Episódio #1 - Resposta de Páginas
  • Episódio #2 - Cache de Página
  • Episódio #3 - Expiração de Cache
  • Episódio #4 - New Relic RPM
  • Episódio #5 - Cache de Página Avançado
  • Episódio #6 - Cache de Ações
  • Episódio #7 - Cache de Fragmentos
  • Episódio #8 - Memcached
  • Episódio #9 - Taylor Weibley & Bancos de Dados
  • Episódio #10 - Cache Client-side
  • Episódio #11 - Cache de HTTP Avançado
  • Episódio #12 - Jesse Newland & Deployment
  • Episódio #13 - Jim Gochee & RPM Avançado

RB : Por que algumas pessoas tem a impressão de que Rails não escala?

GP : Eu acho que a maioria da propaganda negativa sobre escalabilidade veio do Twitter e do Tech Crunch alguns anos atrás. Twitter, como você provavelmente sabe, é uma plataforma de mensagens que pode suportar milhões de requisições por segundo. Enquanto Rails talvez seja bom para o front end de uma plataforma de mensagens como o twitter, a infraestrutura de back end precisa escalar de uma maneira que a maioria dos frameworks web não pode fazer de imediato.
Uma vez que o twitter teve alguns problemas de escalabilidade, muitos tomaram isso como um sinal de que aplicações Ruby on Rails em geral tinham problemas de escalabilidade, o que claramente não é o caso.

RB : Que conselho você daria para desenvolvedores, começando a criar aplicações Rails em suas empresas, para criar aplicações Rails escaláveis?

GP : Assista a todos os meus screencasts Scaling Rails! Shameless Self Promotion (Propaganda Própria Sem-vergonha)

Agora sério, aprenda como tirar vantagem dos vários mecanismos de cache que já vem com o Rails. Instale uma ferramenta de monitoramento de servidores como o RPM da New Relic para que você possa monitorar sua aplicação em produção. Use esta informação para encontrar onde sua aplicação está lenta, e onde otimizar.

Recentemente tenho visto empresas já usando memcached muito cedo. Não comece a usar memcached para guardar objetos de banco de dados antes que você tenha passado um tempo otimizando suas consultas de banco de dados.

Por último, bem no começo do projeto reserve um tempo no cronograma de lançamento para “otimizar a aplicação” antes de ir para o ar. Não deixe ninguém tirar este tempo de você.

RB : Que recursos você sugere, além dos screencasts que você criou, para ajudar desenvolvedores a criar aplicações escaláveis?

GP : Eu sugiro:

  • Leia o livro de Cal Henderson “Building Scalable Websites”.
  • Aprenda a usar YSlow e tire apenas A's.
  • Se você é um desenvolvedor Ruby, leia o “blog de Ilya Grigorik
  • Se você é um desenvolvedor Rails, leia o “Guia de Cache com Rails

RB : Que benefícios você vê em desenvolvedores de empresas usando Ruby e Ruby on Rails?

GP : Bem.. isso está fora do escopo do que estávamos falando, mas o grande benefício de usar Rails na empresa vem na fase de manutenção de um projeto.

  • Há uma maneira comum de construiur uma aplicação Rails. Isso significa que você pode adicionar membros ao seu time e você não tem que “esperá-los ganhar velocidade”. Isso também significa que você tem mais segurança, se alguma coisa acontece com a firma que está construindo uma aplicação Rails para você, você pode facilmente pegar e ir para outra firma.
  • Ruby permite aos desenvolvedores serem mais produtivos, e escrever menos código que faz mais coisas. Isso significa que haverá menos bugs e será mais fácil de manter. Isso também significa que será mais fácil se manter Ágil, uma vez que mudanças simplesmente requerem menos trabalho.
  • Código Ruby também é muito expressivo, o que significa que é fácil de ler. Ou seja, é o que vai fazer a economia na fase de manutenção, porque levará menos tempo para entender o código de outra pessoa.

RB : Gregg, obrigado por falar comigo hoje.

Gregg Pollack é co-apresentador do podcast Rails Envy e membro do Time de Ativistas Rails. Encontre todos os 13 episódios da série Escalando Rails series no web site Escalando Rails para baixar os screencasts e exemplos de código.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT