Tag: Rails - 1/5

Caso ainda não saiba, o bom e velho Ruby 1.8 desempenhou seu papel muito bem nos últimos anos e chegou a hora de aposentá-lo. Ele não receberá mais manutenção ou mesmo correções de segurança a partir de Junho deste ano (2013). Significa que seu irmão-gêmeo, o venerado Ruby Enterprise Edition 1.8.7, que nos apresentou a funcionalidade de Copy-on-Write e a possibilidade de refinar os parâmetros do garbage collector, também ser tornará obsoleto em breve.

O que acontece hoje é que existem muitos aplicativos ainda rodando em Ruby MRI ou REE 1.8.7, desenvolvido em Ruby on Rails 2.3, em produção, que ninguém sabe o que deve fazer. A resposta mais comum, caso pergunte aleatoriamente a um desenvolvedor, será "reescrever" em Ruby 2 e Ruby on Rails 3.2 (ou já arriscando para o Rails 4.0 que sairá em breve).

Minha resposta é diferente: se seu aplicativo está hoje em produção, com usuários acessando, minha primeira opção sempre será explorar a possibilidade de realizar o que chamamos de "migração técnica". Uma migração técnica:

• não envolve mudar funcionalidades ou criar novas;
• no máximo retirar funcionalidades desnecessárias;
• e apenas realizar a atualização para as versões mais recentes de Ruby e Rails.

Uma das gems que eu mais uso em projetos é o ActiveAdmin, de todas as opções de admin para Rails que surgiram até hoje, esta foi a que melhor se adaptou na maioria dos projetos. Longe de ser perfeita, mas o suficiente para atender bem as necessidades de uma simples coleção de CRUDs.

Outra vantagem é que pouco a pouco um pequeno ecossistema surgiu em torno do framework, adicionando funcionalidades como granularidade de permissões com CanCan, e eu já bloguei sobre sua excelente integração com o Best in Place. Desta vez experimentei outra extensão que gostei muito, o ActiveAdmin-WYSIHTML5.

Se você é desenvolvedor com certeza usa frequentemente os excelente sites Stack Overflow e Stack Exchange, em termos de conteúdo técnico se você está tendo um problema a probabilidade de encontrar a solução num desses sites é enorme.

O co-fundador, Jeff Atwood, resolveu iniciar um novo projeto de fóruns. Se pararmos para pensar temos centenas de "blog engines" por aí, do famigerado Wordpress até o geeky Jekyll. Isso sem contar os inúmeros CMS como Joomla, ecommerces como Magento e Spree. Mas uma categoria que evoluiu muito pouco foram os fóruns e até hoje ainda vemos os antigos phpBB por aí.

Com isso em mente Jeff juntou uma equipe e desenvolveu o Discourse. Mais interessante ainda: ele desenvolveu tudo usando Ruby on Rails, Ember.js, PostgreSQL e Redis. Tudo está open source e ele está ainda em ativo desenvolvimento.

O assunto não é nada novo, mas como caí nele esses dias resolvi anotar. Faz algum tempo que estou só desenvolvendo usando Vagrant, se ainda não conhece vale a pena ler o artigo Usando o Vagrant como Ambiente de desenvolvimento Windows do Nando Vieira sobre isso.

Em resumo é basicamente uma forma simples de configurar seu VirtualBox. Porém com isso vem alguns problemas, um deles é executar testes de aceitação, especialmente com Selenium. Isso porque o Vagrant vai subir um servidor VirtualBox headless, sem modo gráfico. E sem isso não dá para os testes abrirem o Firefox. Você pode executar em modo headless mas é mais divertido ver o Firefox abrindo e executando seus testes.

Para que isso funcione é simples: basta executar o Selenium em modo servidor e fazer a execução do Vagrant chamá-lo pela sua rede. Vamos passo a passo.

Alguns dias atrás me pediram para responder no Quora a pergunta "Ruby on Rails: Quais são algumas das piores práticas para aplicações Ruby on Rails?". Foi uma resposta que teve muitos votos positivos então resolvi que seria um bom post para meu blog. Segue minha versão extendida.

Existem diversas práticas ruins em desenvolvimento de aplicações em geral e em particular em Ruby on Rails. Eu mesmo já cometi e aprendi sobre várias elas na prática e em particular tive que pegar alguns projetos de resgate onde continuo vendo os mesmos erros acontecendo repetidamente, então vamos tentar resumir as principais que mais me irritam.

Um ano atrás eu gravei um screencast sobre Instalando um Ambiente Ruby onde mostro como instalar e configurar um ambiente em Linux/Ubuntu, Mac e Windows 7.

Por curiosidade, resolvi dar uma olhada no Ubuntu mais recente o 12.04 LTS Precise Pangolin. Já explorei sobre Rbenv recentemente mas continuo preferindo usar RVM. A partir de um Ubuntu 12.04 recém-instalado entre no site do RVM e siga as instruções, como vou mostrar neste artigo.

After a long gap I finally managed to contribute a bit to RubyLearning.org. I’ve written a 2 part article about Internationalization (i18n) in Brazilian Portuguese a few days ago. I’ve adapted it into English and you can read it at Satish’s blog. I’m showing snippets of code from a demonstration app and you can see the code at my Github repo and you can also see the app up and running here, thanks to Heroku’s free accounts. I hope you enjoy it!

Vocês devem ter notado que agora as tags de cada post estão listadas e são clicáveis, levando a uma listagem de todas as posts com a mesma tag. Essa funcionalidade já existia nos outros sistemas de blog que usei, mas desde que comecei o blog eu nunca gerenciei as tags corretamente. Só que hoje eu tenho mais de 860 artigos. Eu preciso olhar uma a uma e reeditar as tags. Mas o fluxo normal de:

• abre no admin a listagem de posts;
• navega pela lista paginada;
• encontra um post para editar, clica e abre outra página;
• edita as tags;
• salva, retorna pra listagem;

São muitos passos nos admins antigos. Eu queria navegar pela listagem e editar as tags “in place”, mas sempre tive preguiça de implementar :-)

Este artigo inicia na Parte 1. Leia primeiro antes de continuar.

Se quiser ver como essa aplicação se comporta de verdade, eu subi uma versão numa conta free do Heroku, então clique aqui e veja.

Aviso: Não se esqueçam que dias 30 e 31 de Agosto teremos a Rubyconf Brasil 2012! Já garantiu seu ingresso? Compre agora mesmo!

Este é um artigo que eu queria escrever há muito tempo, finalmente consegui formatá-lo como queria. Um dos assuntos que até hoje ainda é difícil de explicar para iniciantes é como utilizar o suporte de I18n do Rails. Todos sabem que o Rails possui uma excelente infraestrutura para internacionalização (i18n) e localização. Porém, a instalação básica do Rails fornece somente a infraestrutura, ou seja, o desenvolvedor é quem deve escolher quais componentes adicionais instalar sobre essa infraestrutura para retirar o máximo que o Rails pode oferecer.

I18n e L10n vai muito mais do que a simples tarefa de substituir strings de texto. Formatação de dados (data, hora, moeda) variam. Codificação dos dados (o padrão sempre tem que ser UTF8!). URLs sensíveis à localização. Modelos sensíveis à localização. Para começar, não pretendo repetir o que todo desenvolvedor Rails já deveria saber, portanto se ainda não leu o Guia Oficial sobre a API de Internacionalização do Rails sugiro que faça isso antes de continuar lendo este artigo.

Aproveitei o dia hoje para testar o tão falado Rbenv. Tecnicamente não tenho nenhum motivo para mudar do RVM a não ser curiosidade de testar alguma coisa diferentes (fator “geek”, se quiserem). Desde que o Wayne lançou o RVM eu venho utilizando sempre a versão mais recente instável (rvm get head) e ao contrário do que muitos dizem, eu nunca tive nenhum problema do tipo precisar reinstalar tudo depois de uma atualização.

A grande maioria dos problemas que eu já vi são relacionados à atualização de sistema operacional, em particular do Snow Leopard para Lion, mudança no XCode do compilador GCC para Clang, de 32-bits para 64-bits, coisas desse tipo.

Não perca o início deste artigo, na Parte 1

Este é provavelmente um dos assuntos mais confusos para quem está iniciando com Ruby on Rails. Antigamente, as regras eram simples:

• coloque todos os seus assets (imagens, stylesheets e javascripts) organizados nas pastas public/images, public/stylesheets, public/javascripts;
• utilize helpers como image_tag, stylesheet_link_tag e javascript_include_tag;
• configure seu servidor web (Apache, NGINX) para servir URIs como /images/rails.png diretamente de public/images/rails.png para não precisar passar pelo Rails;

Pronto, está tudo preparado para funcionar. Porém, existiam e ainda existem muitas situações que essa regra não cobria e diversas técnicas, “boas práticas” e gems externas precisaram ser criadas para resolvê-las. Em particular, temos as seguintes situações cotidianas em desenvolvimento web:

• quando se tem muitos assets, como javascripts, é considerado boa prática “minificá-los”, ou seja, otimizar ao máximo a quantidade de bytes eliminando supérfluos como espaços em branco e quebras de linha, nomes de variáveis e funções longas, etc. E além disso concatenar a maior quantidade de arquivos num único quanto possível. Em desenvolvimento, precisamos ter todos abertos e individuais para facilitar o debugging, mas em produção o correto é “compilá-los”
• cache precisa ser usado o máximo possível e escrever o caminho a um path manualmente, como <img src=“/images/rails.png”/> é ruim, pois se precisarmos mudar o conteúdo dessa imagem, os usuários precisariam limpar seus caches pois o correto é configurarmos os servidores web com diretivas para manter assets no cache local por um longo período de tempo (1 ano ou mais). Helpers como image_tag criavam caminhos como <img src=“/images/rails.png?12345678”/>, sendo esse número derivado do timestamp de modificação do asset. Assim, se o asset era atualizado esse número mudava. Mas isso não funciona bem com muitos tipos de caches e proxies, que ignoram o que vem depois do “?”
• quando uma página possui dezenas ou às vezes centenas de pequenas imagens e ícones (setas, botões, logotipos de seção, linhas, bordas, etc), o correto é usar a mesma técnica que usamos com stylesheets e javascripts: concatenar muitas imagens em um único arquivo maior e então utilizar CSS para manipular a posição x e y dentro dessa única imagem grande para posicioná-la corretamente onde precisamos.
• começamos a utilizar vários tipos diferentes de geradores de templates, como LESS e SASS para gerar stylesheets, CoffeeScript para gerar Javascript, além do próprio ERB para adicionar conteúdo dinâmico nos templates.

Para resolver essas e outras situações é que foi criado o chamado Asset Pipeline, que é um conjunto de bibliotecas e convenções para resolver o problema de assets da melhor forma possível. O Asset Pipeline sozinho não resolve tudo, ele é um framework para que seja possível integrar diferentes soluções de forma organizada.

Tudo que será explicado neste artigo vale para o Rails 3.2 e superior, existem diferenças importantes nas versões anteriores que não serão tratadas aqui. Leia o Rails Guides, especialmente os Release Notes de cada versão.

Durante Julho e Agosto de 2010 eu havia acabado de sair da Locaweb e com o tempo livre inicialmente resolvi tentar criar screencasts com qualidade mais “comercial”. Disso surgiu um “piloto” que foi uma palestra que dei na época e 3 tutoriais técnicos. A experiência foi ver se havia viabilidade comercial para screencasts desse tipo. Infelizmente a aceitação na época foi bem baixa embora eles ainda tenham saída constante até hoje, quase 2 anos depois. Como agora estou tempo integral dedicado à ...

Ano passado minha equipe colocou um grande projeto em produção. Por conta do NDA assinado com o cliente, não podemos divulgar, posso dizer que era internacional e com grande tráfego. Porém quero descrever uma situação que passamos que talvez possa ajudar outros projetos mesmo sendo um bug antigo.

Pesquisando esses dias esbarrei com este Gist do John Nunemaker. Não afirmo que é exatamente o mesmo bug mas a descrição é idêntica. Em nosso caso, os servidores de produção estavam todos funcionando bem, mas aleatoriamente quando monitoramos víamos algumas das CPUs em 100%, se deixássemos mais algum tempo em breve todas as CPUs estavam no máximo e parando de responder.

Faz tempo que não posto uma dica técnica, vou retornando aos poucos. Hoje uma dica bem simples mas que muitos ainda desconhecem.

Muitos aplicativos Rails tem seções com páginas estáticas, páginas de conteúdo como institucional, instruções, etc. Digamos que para organizar isso você tenha criado um controller chamado “Page”, assim:

bundle exec rails g controller Page

O problema é que eu sempre vejo algo parecido com isto no config/routes.rb

  match "page/hello" => "page#hello"
  match "page/help" => "page#help"
  ...

Daí no app/controllers/page_controller.rb encontro:

  def hello
  end

  def help
  end
  ...

If you follow my feeds, you probably saw that I’ve been tweaking my website since this weekend. So I decided to undertake yet another brain surgery and learn some new stuff in the process.

You can see the result at this staging subdomain. Let me know if you find any bugs. This is a heavily customized Enki blog adapted for Rails 3.1 beta running over Ruby 1.9.2 and Nginx/Passenger.

The very first step that I recommend is David Rice’s article on how to upgrade your Rails app to 3.1. It was invaluable in my process. First and foremost, the advice that applies to any Rails upgrade:

• Make sure your tests all pass and that you have good enough coverage to feel confident on heavy upgrades of this kind.
• git checkout -b rails3.1 – create a new branch where all the changes will be.

I’ll go over David’s bullet points on the upgrade process and you can compare my article with his to understand a few differences and how you can adapt those steps for your own projects.

Com o lançamento do Rails 3, estou migrando meu blog também. Para quem não lembra, estou usando uma versão (bem) modificada do Enki que é um sistema bem minimalista. Eu já mexi tanto nele que nem dá mais para dar merge, por isso também não posso publicar o código já que tem muita coisa específica do meu blog.

De qualquer forma, o Enki usar RSpec para seus testes e é o que estou usando também. A meu ver, existem muitos problemas com esses testes. Eu particularmente não gosto de usar specs de rotas, prefiro deixar isso pra testes de aceitação com Cucumber, por exemplo. Outra reclamação minha é que eu acho que o Enki usa muito mais mocks do que eu gostaria. Prefiro usar factory_girl e usar os models diretamente. Esses dois pontos deram trabalho na hora de migrar para RSpec 2. Em muitos casos ou eu retirava os testes ou trocava de mocks para factories e as coisas voltavam a funcionar.

O RSpec 2 é uma reescrita do RSpec anterior, na maior parte dos casos a API se manteve, mas algumas coisas quebraram. Vamos dar uma olhada em alguns dos pontos que eu tive que passar. Lembrando que algumas das coisas que vou dizer já haviam mudado desde o RSpec 1.3.x mas meus testes ainda estavam mais antigos do que isso.

O Rails 3 foi liberado há 1 minuto! Versão 3.0 FINAL! O DHH acabou de fazer o anúncio oficial.

Foram quase 2 anos no forno, desde o anúncio da junção dos projetos Merb e Rails no dia 23 de dezembro de 2008.

Muita coisa mudou desde então. O Yehuda Katz liderou esse projeto de ponta a ponta e contou com a ajuda de diversos excelentes rubistas como nossos amigos latino americanos Emilio Tagua, Santiago Pastorino e o brasileiro José Valim. Parabéns a todos os envolvidos por este grande projeto!

Para instalar, claro, agora basta fazer o de sempre:

gem install rails

Atualizado 26/05: Ajustei o artigo de acordo com os comentários do Tapajós :-)

Essa dica é meio velha, mas como muita gente ainda desconhece vamos falar dela. Um recurso que surgiu no Rails 2.2 é o suporte a ETAG. Se você ainda não usa, deveria. Isso porque é super simples, vai melhorar a performance do seu site para seus usuário e sai praticamente de graça, sem efeitos colaterais.

Atualizado 25/05: A versão 2.3.7 saiu rápido demais, tentando corrigir um bug e acabou expondo outro. O Jeremy Kemper (@bitsweat) se desculpou pelo lapso e acabou de soltar, finalmente, a versão estável 2.3.8

Atualizado 24/05: Parece que havia alguns bugs ainda no novo suporte a XSS por isso o pessoal lançou uma correção na forma da versão 2.3.7

O pessoal do Rails Core acabou de lançar o Rails 2.3.6, provavelmente a última revisão da série 2.3 antes do lançamento da esperada versão 3.0 (atualmente em Beta 3). Ela trás algumas funcionalidades para servirem de “ponte” entre as duas séries. Vejamos algumas modificações.

Para começar, instale essa nova versão:

gem install rails --version=2.3.8