Tag: dicas e tutoriais - 1/7

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.

Muitos instalam e mantém seu próprio servidor num VPS. Uma aplicação web hoje é formada por diversos componentes como o web server (NGINX), banco de dados (PostgreSQL, Redis), workers de fila (Resque ou Sidekiq), serviços agregados (como SOLR).

Como já disse antes, fazer "rodar", é simples. Agora e se o processo der crash por alguma razão ou o servidor reiniciar?

Atualizado 7/5/2013: adicionado procedimento que não existe na documentação oficial para conseguir fazer deployments "corretamente" no Appfog.

Como disse antes comecei a usar o AppFog pra várias coisas. Mas tem um problema, diferente do Heroku ele não é bom pra executar assets:precompile (primeiro porque pode estourar memória, segundo porque dá timeout se o processamento demorar muito).

O processo de deployment não é via git push mas via o comando af update. Ele simplesmente faz um upload dos arquivos no diretório do projeto ao servidor (se entendi direito). Portanto o melhor a fazer é executar o assets:precompile localmente antes do deploy (lembrar de colocar turbo-sprockets pra ir mais rápido).

O problema é que agora em modo de desenvolvimento o servidor local vai começar a puxar os assets direto da pasta public/assets em vez de processar dinamicamente da pasta app/assets que é o que você precisa em desenvolvimento. Vide meu artigo Asset Pipeline para Iniciantes caso ainda não esteja bem familiarizado com o processo.

A opção mais antiga, antes de existirem os Platform as a Service (PaaS) como Heroku, AppFog, OpenShift e outros são os Virtual Private Servers ou VPS. Os termos confundem pois costumamos chamar de "cloud" as soluções que caem nas categorias SaaS (serviços), PaaS (plataforma), IaaS (infraestrutura) e muitos tendem a deixar VPS numa categoria à parte.

VPS são máquinas virtuais, assim como um VirtualBox, Parallels, VMWare na sua máquina local, só que hospedado no data center de alguém. Eu particularmente acho que VPS está na mesma categoria que IaaS.

Outra coisa que muita gente se confunde: "preciso do meu próprio servidor, instalado do zero, porque tenho vários serviços não-web que preciso instalar e manter na mão, como SOLR, postfix, etc"

Não, a menos que você tenha uma operação grande, não precisa. Utilize os diversos Software as a Service (SaaS) que existem. Muitos deles oferecem planos gratuitos para pouca utilização - pois obviamente, se você vai utilizar bastante é porque sua aplicação fatura o suficiente pra pagar a infraestrutura, caso contrário porque investir nela?

Como disse no artigo anterior, na dúvida, use o Heroku. Mas depois disso, alguns perguntam se existem outras alternativas. De fato existem várias. Agora é a vez de outra opções, o AppFog foi uma das mais interessantes que usei.

Ela tem algumas características semelhantes e outras diferentes do Heroku. Vamos a alguma delas:

Muitos ainda devem ter dúvidas de onde colocar suas aplicações Rails. Nos últimos dias andei testando algumas alternativas.

Na prática está entre as opções:

1. Instalar do zero seu próprio servidor e se responsabilizar pela manutenção
2. Usar um PaaS (Platform as a Service) e deixar um serviço cuidar da infraestrutura por você

Em ambas as opções as peças mais importantes são:

1. servidor web (nginx, apache2)
2. banco de dados (SQL: PostgreSQL, MySQL; NOSQL: MongoDB, CouchDB, Redis, Riak), incluindo facilidade em escalar verticalmente (mais CPU/RAM) e horizontalmente (replicação)
3. load balancer (HAProxy), incluindo facilidade em aumentar os servidores web
4. opcionais (Memcached)
5. manutenção (aplicação de patches de segurança, backup)

No próximo artigo vou falar de outra opção que estou gostando, o AppFog, mas no geral o PaaS que oferece o melhor balanço entre funcionalidades, facilidade, serviços ainda é o Heroku. Se ainda não viu, leia meu artigo Enciclopédia do Heroku. A grande vantagem é realmente preocupação perto de zero com infraestrutura.

Se você sabe o que é Tail Call Optimization (TCO), provavelmente também já deve ter ouvido falar que Ruby não suporta TCO. Se você não sabe o que é 'tail call' vale definir:

Em ciência da computação, um 'tail call' é uma sub-rotina que acontece dentro de uma procedure como sua ação final; ela pode produzir um retorno que é então imediatamente retornada pela procedure que a chamou.

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!

Hoje alguns sites ficaram inacessíveis porque o provedor de DNS Zerigo sofreu um ataque de Denial of Service (DDoS). Levaram várias horas para estabilizar.

Normalmente nunca nos preocupamos com DNS porque se existe um serviço que atualmente é praticamente transparente é DNS, mas esse ataque nos relembra da importância de redundância e backup.

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.