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.

Alguns anos atrás escrevi diversos artigos num outro blog fora daqui entitulado "Gestão 2.0".

Na época me faltou tempo para escrever lá então ele ficou parado. Como ficou parado todo esse tempo, decidi transferir os posts que eu mais gostei para cá para garantir que meus textos estão (quase) todos num lugar só. Atualmente estou colaborando como colunista na Startupi, então não deixe de visitar lá também.

Separei uma dúzia de posts do Gestão 2.0 que já estão programados para aparecer na home...

Original de 27/4/2011: Gestão 2.0

Meu último artigo de tradução sobre “Padrões: Excelência vs. Mediocridade” gerou uma discussão separada interessante especificamente sobre “Design Patterns”.

Para quem não é de programação, nos anos 70 (e foi reforçado nos anos 90 pelo “livro do Gang of Four”) surgiu um termo chamado “Design Pattern” que, segundo a Wikipedia, em engenharia de software, um “design pattern” é uma solução reusável geral para um problema que ocorre comumente em design de software. Um design pattern não é um design fechado e acabado que pode ser transformado diretamente em código. É uma descrição ou template para como resolver um problema que pode ser usado em muitas situações diferentes.

Esta semana estava organizando meu blog e finalmente adicionei ao menu principal o ítem "Iniciante". Logo se tornou o ítem mais acessado do meu blog. É um sintoma de um problema que sempre acontece: muitos dos Rubistas que iniciaram 5 anos ou mais atrás e hoje são reconhecidos escreveram muitos posts, partipavam dos foruns. Muita de nossa inspiração veio de blog posts de outros grandes Rubistas de fora. Ryan Bates, o próprio DHH, Jamis Buck, Dave Thomas e muitos outros que também estavam ainda aprendendo e postando sobre as coisas que aprendiam.

Essa geração passou, uma nova surgiu, os blog posts agora tendem a ser mais avançados e, pior, existe uma abundância de material e pouca sequência. A vantagem de iniciar a aprender junto com o nascimento de qualquer plataforma é que você nunca se sente "ficando para trás" pois literalmente vimos absolutamente tudo que foi feito até então.

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.

Up until now I have almost 900 blog posts written over a period of 7 years. Some of those posts already "expired" as the piece of information got obsolete. Many of those are still very relevant and useful today.

People that have been following my blog for the past 7 years had the chance of reading most of those articles. But what about the new people? It's very hard to explore old good articles around a pool of almost 900.

Every blog still follows the very same structure: they are sorted by date in descending order, they show up one at a time in a long stream. Only new posts (or those manually chosen) show up at the top. As soon as I post a new article, the previous one become less relevant. If the blog is paginated, last month's posts will be buried and hidden in previous pages. Most people don't navigate to previous pages nor go through tags (which only help so far).

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.