Este post serve mais como “cola” de referência, pois toda vez que vou fazer isso eu não encontro fácil no google e nunca lembro. Por sinal é mega simples, é só editar o config/application.rb e remover a linha:

require 'rails/all'

E substituir por:

require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "sprockets/railtie"

Após isso, já não aparece mais as tasks de testes, e você pode remover a pasta test.

$ git rm -r test/

Pra finalizar, já segue a dica de alterar a task default, no final do Rakefile é só colocar:

Rake::Task[:default].prerequisites.clear
task :default => :spec  #no caso do rspec

Sucesso!

Se você ainda não trabalha com Ruby pois acha complicado demais instalá-lo, chega de desculpas! Esse tutorial for dummies ajudará a instalar o Ruby através do RVM de forma direta, sem enrolação.

Partindo de uma instalação do Ubuntu 11.04 zerada, começamos com os pré-requisitos para instalar o RVM:

user@ubuntu:~$ sudo apt-get install git-core curl

Basta confirmar a instalação dos pacotes, em seguida executar o comando (extraído do site oficial do RVM):

user@ubuntu:~$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

A seguir, o output completo gerado por esse comando indicará os pacotes e libs necessários para a instalação do Ruby.

(...)

dependencies:
# For RVM
  rvm: bash curl git

# For Ruby (MRI & ree)  you should install the following OS dependencies:
  ruby: /usr/bin/apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake

(...)

Installation of RVM to /home/user/.rvm/ is complete.

Agora, basta instalar essas libs através do apt-get:

user@ubuntu:~$ sudo apt-get install build-essential bison openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake

Com as dependências instaladas, abra um novo console (para re-carregar o RVM), e comece a instalar o Ruby, no caso, o MRI 1.8.7:

user@ubuntu:~$ rvm install 1.8.7

Esta operação levará alguns minutos. Quando concluída, você terá o Ruby 1.8.7 e o Rubygems 1.8.6 instalados. Para testar tudo, execute os seguintes comandos:

user@ubuntu:~$ rvm use --default 1.8.7
Using /home/user/.rvm/gems/ruby-1.8.7-p352

user@ubuntu:~$ ruby -v
ruby 1.8.7 (2011-06-30 patchlevel 352) [i686-linux]

user@ubuntu:~$ gem -v
1.8.6

Pronto! Agora você tem o Ruby e Rubygems instalados e prontos para o uso. Caso queira conferir, o output dos comandos acima está disponível neste gist.

Fique ligado no próximo post: Gemsets e Bundler. Qualquer dúvida, use os comentários.

This is my first blog post and I decide to write in English because writing is a good way to learning and I’d like to improve my English, so post a comment if you see some grammar errors.

JRuby has helped me a lot bringing Ruby test “culture” into Java with RSpec.
In this series of blog posts I will show how I’m doing tests with Java legacy code. I will try cover topics including testing dao, service, controller and view layers.
In this part, we’re going to set up our development environment, write a RSpec example and implement with Java through JRuby. We’ll also get continuous testing running with infinity test gem.

The first thing we need is install rvm (Ruby Version Manager), JRuby and Ruby Gems.

bash << ( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

http://rvm.beginrescueend.com/rvm/install/ for more info.

Install JRuby:

rvm install jruby

Set rvm to use JRuby:

rvm use jruby

Install RSpec:

gem install rspec

Once you have finish installation let’s start code with a example that expresses a form of payment orders available in Brazil called Boleto.

Create the initial project structure like this:

-boleto
  -spec
  -src
    -com
      -legacy
  -build

Open up spec/boleto_spec.rb and make it look like this:

require "date"
require "java"
java_import "com.legacy.Boleto"
 
describe Boleto do
  it "calculates due days" do
    boleto = Boleto.new
    boleto.due_date = java.util.Date.new(Date.parse("2011-01-15").ctime)
    boleto.payment_date = java.util.Date.new(Date.parse("2011-01-25").ctime)
    boleto.due_days.should == 10
  end
end

Let’s run the example and watch it fail.

jruby -J-cp build -S rspec spec/boleto_spec.rb

NameError: cannot load Java class com.legacy.Boleto

Now write just enough code to make it pass on src/com/legacy/Boleto.java like this:

package com.legacy;
import java.util.Date;
public class Boleto {
  private Date dueDate;
  private Date paymentDate;
 
  public Date getDueDate() { return this.dueDate; }
  public void setDueDate(Date dueDate) { this.dueDate = dueDate; }
  public Date getPaymentDate() { return this.paymentDate; }
  public void setPaymentDate(Date paymentDate) { this.paymentDate = paymentDate; }
  public Integer getDueDays() { return 10; }
}

Also we need to compile the java class.

javac -d build/ src/com/legacy/Boleto.java

Instead of run the example by manual command again, let’s install a continuous testing gem:

wget --no-check-certificate\

http://www.github.com/tomas-stefano/infinity_test/tarball/master\

 -O infinity_test.tar.gz
tar -zxvf infinity_test.tar.gz
cd tomas-stefano-infinity_test-{version}
gem build infinity_test.gemspec
gem install infinity_test-1.0.2.gem

What we have done here is install infinity_test gem that contains a path to pass arguments to specific versions of Ruby.

Let’s run the example with continuous testing gem:

infinity_test --rspec --rubies=jruby+"-J-cp build"

Now we can write a test for code on spec/boleto_spec.rb and Infinity Test automatic runs the test.
Also we can create a .infinity_test file, like this:

infinity_test do
  use :rubies => %w(jruby),
    :specific_options => {'jruby' => '-J-cp build'},
    :test_framework => :rspec
  notifications :lib_notify   # for linux / growl for mac
end

And run:

infinity_test

https://github.com/tomas-stefano/infinity_test/wiki/Customize-Infinity-Test for more info.

However, we have to compile the java classes when they change. The solution we came up with is to use editors like eclipse or eclim. This kind of editor auto-recompile Java files whenever they change.

Last notes

• I’ve posted the code for boleto here https://github.com/andref5/rspec-java
• More info about JRuby
  • https://github.com/jruby/jruby/wiki
  • http://pragprog.com/titles/jruby/using-jruby
• More info about RSpec
  • http://relishapp.com/rspec
  • http://kerryb.github.com/iprug-rspec-presentation
  • http://pragprog.com/titles/achbd/the-rspec-book
• More info about Infinity_test
  • https://github.com/tomas-stefano/infinity_test
• More info about Ruby
  • http://mislav.uniqpath.com/poignant-guide/book/

Muito buzz se formou depois que o DHH tornou público que a versão 3.1 do Rails virá com CofeeScript por padrão.

Aproveitando a barulheira, que é comum a cada vez que o criador da plataforma abre a boca, vamos nos ater ao que é importante e apresentar uma introdução ao resumo simplificado do CoffeeScript básico.

Confesso que minha opinião sobre essa ferramenta mudou nos primeiros instantes em que comecei a usar. No site do CoffeeScript (ok se eu começar a chamar de CS daqui para frente?) existe um link onde você digita o código do lado esquerdo e, imediatamente, do lado direito aparece o equivalente em JavaScript.

Fiz uma brincadeira lá usando um código que sempre me vem à cabeça ao tentar explicar o básico de programação funcional para alguem. Segue:

mimimi = (operation, value) ->
   operation(value);

dobro = (value) ->
  value + value;

quadrado = (value) ->
  value * value;

zero = (value) ->
  value - value;

um = (value) ->
  value / value;

alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

Nada de outro mundo, certo? O equivalente JS é o código abaixo:

var dobro, mimimi, quadrado, um, zero;
mimimi = function(operation, value) {
  return operation(value);
};
dobro = function(value) {
  return value + value;
};
quadrado = function(value) {
  return value * value;
};
zero = function(value) {
  return value - value;
};
um = function(value) {
  return value / value;
};
alert(mimimi(dobro, 3));
alert(mimimi(quadrado, 3));
alert(mimimi(zero, 3));
alert(mimimi(um, 3));

CS permite também a checagem automática de valores e parâmetros opcionais, conforme o exemplo retirado do site:

fill = (container, liquid = "coffee") ->
  "Filling the #{container} with #{liquid}..."

Ou o equivalente em JS:

var fill;
fill = function(container, liquid) {
  if (liquid == null) {
    liquid = "coffee";
  }
  return "Filling the " + container + " with " + liquid + "...";
};

Sem dúvida, muito mais legível e expressivo.

É uma ferramenta que eu pretendo usar em algum projeto pequeno, para testar e ver o quanto acelera meu trabalho. Em projetos maiores talvez eu demore um pouco mais para usar mas, considerando que umas das minhas aplicações já conta com 79% de código total escrito em JavaScript, segundo o GitHub, imagino que isso vai melhorar consideravelmente a manutenção do código.

E no mais, se o CS não te chamou a atenção e você não quer mesmo utilizar, basta remover o require do arquivo Gemfiles e a vida segue como se nada tivesse acontecido.

Links recomendados:

• Site do CoffeScript: http://jashkenas.github.com/coffee-script/
• Mais do mesmo: http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
• Exemplo bacana de como utilizar CS dentro da sua view: http://geekiriki.blogspot.com/2010/08/jquery-meets-coffeescript.html

Pessoal, hoje estamos lançando a pesquisa de intenção do nosso próximo produto: Sitefique.me, uma ferramenta online para criação de sites focado na simplicidade.

Sobre o produto

A idéia surgiu há vários anos mas somente agora nos sentimos experientes o suficiente para tirá-la do papel mantendo sua principal característica: ser simples. Se você acompanha nosso blog já deve ter notado que nossa busca por simplicidade é uma constante (e não é uma coisa fácil de se encontrar nos ambientes corporativos).

Foi seguindo essa filosofia, de ser simples, que decidimos criar o Sitefique.me, voltado para pequenas empresas, que têm a necessidade de um site próprio, divulgar seus produtos e serviços ou até mesmo vendê-los pela internet, mas que ainda não encontraram a ferramenta na medida ou que coubesse no orçamento da empresa.

O Sitefique.me permite criar um site do zero em poucos minutos, escolhendo um layout que pode ser personalizado, e criar páginas a partir de modelos prontos como vitrine de serviços, álbum de fotos, localização com mapa e formulário para contato. Tudo muito simples e direto ao ponto.

Precisamos da sua ajuda

A versão final do produto ainda não está disponível. Estamos finalizando os detalhes, cuidando de alguns assuntos legais, e passando aquele pente fino no código, mas pretendemos lançá-lo nas próximas semanas.
Por enquanto, gostaríamos que respondessem nossa pesquisa de intenção, para nos ajudar a decidir sobre alguns pontos do produto, como valores e planos. Quem responder nossa pesquisa e tiver interessado no produto, será convidado para testá-lo antes do lançamento oficial e ainda ganhará o primeiro mês de mensalidade grátis, sem compromisso.

Infelizmente não possuímos capital para investir na divulgação. Tudo que fizemos até agora foi com nosso próprio dinheiro (servidores, etc) e nosso “tempo livre”. Por isso, pedimos sua ajuda para divulgá-lo:

• Se você apóia iniciativas de empreendedorismo como esta, indique o produto para seus contatos ou empresas que podem necessitar desta solução. Você também pode retuitar para seus seguidores.
• Se você é um desenvolvedor, como nós, nos ajude divulgando o produto para sua rede de contatos, como mais um “case” de Ruby on Rails. Você também pode retuitar para seus seguidores.
• Se você tem um tio ou um cunhado que pega no seu pé nos encontros de família: “Ei sobrinho, quando você vai fazer um site para minha lojinha”, nos ajude indicando o Sitefique.me. De qualquer forma, você também pode retuitar para seus seguidores.
• Ou se você simplesmente já sofreu com a famosa Síndrome do Sobrinho, com certeza nos ajudará a retuitar para seus seguidores.

Muito obrigado.

Retuite para seus seguidores. Assine o blog do produto. Conheça a empresa. Entre em contato.

Documentação é aquilo que você reclama para fazer e reclama quando não encontra.

Por Plínio “Chico Xavier” via Twitter.

Isto me fez refletir (bem rápido) sobre as possíveis causas da não-documentação:

• É muito chato ! Editar wiki, doc … é incrível como toda documentação geralmente é feita em algo não produtivo.
• Espaço e Tempo (ou seja, prazo!). Sempre é deixado por último e nunca sobra tempo pra ser feito.
• Não é levado a sério. Levanta a mão que já viu a secretária documentando “tela” de sistema …
• Normalmente o “investidor” do software não vê valor nisto, ou melhor, espera alguém pedir e repassa a tarefa com prioridade “faz rapidinho”.

Ok. Após reflexão feita, hora de atacar o problema.

Usando “guides” para criar um Guide !

Este é um resultado da experiência abaixo:

Com a gem guides, em segundos você tem um scaffold, pronto para ser preenchido.

$ gem install guides

 $ guides #mostra os comandos disponíveis

$ guides new sample

$ cd sample

$ guides build && guides preview

Pronto. Em http://localhost:9292 você terá acesso ao novo guia gerado.

Preenchendo o seu Guia

Em guides.yml (exemplo aqui), está o básico do seu Guia. Nele está o índice de “capítulos”, com resumo e nome do arquivo que o link deve seguir. Os arquivos textile  gerados/criados ficarão na pasta source, o resultado do “guides build” ficará na pasta output.

As páginas são em textile, o que facilita bastante. Mas o grande diferencial, está em alguns helpers disponibilizados pela gem, que torna muito simples criar áreas de destaque como INFO, WARNING … etc e adicionar comandos e códigos.

Para ter idéia de uma página em textile, segue o link source/getting_started.textile (raw).

Repensando a documentação

Com certeza, usando a gem guides, vocẽ consegue um boost na hora de documentar. Já evitando aquela chatice de editar wiki, .doc, controlando versão … etc. Usando textile, seu editor preferido e git, não tem mais desculpas.

Desenvolvendo Frameworks e APIs

Já faz um tempo que eu topo com a vibe Documentation Driven Development. Como tudo na vida, é questão de bom senso. Documentar uma API, nada mais é do que definir a interface dela, e dependendo do caso, isto ajuda bastante antes de começar o desenvolvimento.

Você é um Usuário !

Uma documentação com um monte de imagem e seta, descrevendo o óbvio não serve para nada (além de passar raiva). Uma documentação sucinta, com o básico, por exemplo Instalação, Modo de Usar, Configurações Disponíveis é bem melhor que muito dossiê por aí ! Tente ao máximo se colocar no lugar do usuário ao escrever alguma documentação ou ajuda.

—

Não deixe de contribuir com o post. Mande sugestões, comentários, reclamações etc.

Este é um assunto polêmico e que gera muita discussão nos escritórios de TI. Mesmo assim, tendo trabalhado em várias empresas, grandes e pequenas, presenciando vários projetos fracassarem por decisões arquiteturais (as gerenciais não contam nesse contexto), e os mesmos erros sendo cometidos repetidas vezes, sinto-me na obrigação de passar esta experiência e meu ponto de vista.

Escalabilidade, por definição

De acordo com a Wikipedia, escalabilidade é uma característica desejável em todo o sistema que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer. Em outras palavras, um sistema deve estar preparado para suportar uma demanda crescente.

Pode ser classificada como:

• Carga de escalabilidade: um sistema distribuído deve ser fácil para ser expandido e usar sua gama de recursos para acomodar tanto exigências do mesmo sendo elas pouca ou excessiva.
• Geograficamente escalável: um sistema é geograficamente escalável quando ele mantém sua utilidade e usabilidade, não obstante como são usados os seus recursos.
• Escalabilidade administrativa: não importa a variação de informação que diferentes organizações necessitam compartilhar em um único sistema distribuído, ele deve permanecer fácil de ser usado e gerenciado.
• Escalabilidade funcional: capacidade de melhorar o sistema, adicionando novas funcionalidades com mínimo esforço.

Pode ser aplicada como:

• Escalabilidade Vertical (scale up): significa adicionar recursos em um único nó do sistema (mais memória ou um disco rígido mais rápido).
• Escalabilidade Horizontal (scale out): significa adicionar mais nós ao sistema, tais como adicionar um novo computador com uma aplicação para clusterizar o software. Você pode encontrar escalabilidade horizontal nos sabores Sistemas Distribuídos, Serviços de Componentes, SOA, System of Systems, etc.

Do ponto de vista do custo de desenvolvimento, manutenção e suporte, eu defino escalabilidade como: caro (complexo) vs. barato (simples). Porém, o que é caro nem sempre é bom… e vice versa.

Analogias com o mundo real

Nós gostamos de fazer analogias com coisas reais, são ótimas para expressar idéias e facilitar a comunicação.

Call centers, ou centrais de atendimento. Se você mora no Brasil provavelmente já perdeu algumas horas de sua vida pendurado no telefone tentando resolver um problema com sua assinatura de celular, internet, TV, energia elétrica, etc. Mas por que isso acontece?
Provavelmente, essas centrais de atendimento começaram com poucos funcionários, porém foram “projetadas” para crescer conforme a demanda. Basta contratar mais funcionários, dar treinamento e pronto: mais “nós” atendendo as requisições. Entretanto, o processo passa a ser mais complexo e mais burocrático, pois é muita informação para disseminar entre os funcionários. Resultado: alto custo para empresa e pouco resultado para os clientes. A espera ainda existe e quando finalmente somos atendidos, a sensação é de estar falando com um robô, que dificilmente entenderá seu problema e dará uma solução padrão ou insatisfatória para o mesmo.

O processo é adequado para escalar a demanda horizontalmente, o que o torna complexo e não garante a qualidade. Vale lembrar que o software apenas automatiza ou apóia a realização dos processos reais. Se o processo é complexo, o software será tão complexo quanto (e em alguns casos até mais complexo).

Um exemplo diferente: o Fusca. É um dos carros mais simples que existem, não precisa nem de refrigeração a água. Costuma-se dizer que pode ser consertado com um alicate e um rolo de arame. Seu custo de fabricação seria mínimo se comparado com o custo de um carro popular moderno. Ok, não oferece a mesma segurança, velocidade e conforto de um carro moderno, mas ambos conseguem transportar 5 passageiros ao destino desejado.

Mas o que um Fusca têm a ver com escalabilidade? Bem, imagine um congestionamento na véspera de um feriado, por exemplo. Tanto o Fusca quanto o carro moderno ficarão parados na mesma fila de farofeiros. Toda tecnologia, complexidade e custo da fabricação do carro moderno não o livra de um congestionamento. Não há projeto que consiga prever ou contornar esse problema.

Voltando para nossa realidade, em certos casos o custo não paga o benefício. Mesmo um sistema bem planejado, distribuído, separado em camadas e serviços independentes, pode não suportar a demanda, seja de carga ou de funcionalidade. O mesmo aconteceria com um sistema mais simples arquiteturalmente, com certeza. Porém, o custo e velocidade de desenvolvimento e manutenção seria bem menor.

O que fazer então?

Sistemas precisam evoluir de acordo com a necessidade. Projetar um sistema prevendo todos os possíveis “casos de uso” bem como suas hipotéticas cargas (ou acessos) é uma forte característica do waterfall. Sistemas mais simples arquiteturalmente evoluem mais facilmente, em outras palavras, escalam mais facilmente:

• Keep it simple, stupid! Soluções simples geralmente custam menos e trazem retorno mais rápido. Qualquer funcionalidade ou recurso que não agregue valor deve ser descartada. Simples assim!
• Simplifique requisitos. Clientes sem software costumam viajar nos requisitos. Converse, escute e entenda exatamente seus PROBLEMAS, então negocie e sugira uma SOLUÇÃO simples e rápida. E a entregue logo!
• Busque soluções prontas. As necessidades dos clientes, em muitos casos, são parecidas. Provavelmente existe alguma solução pronta que você pode entregar para seu cliente ao invés de desenvolver um novo [software que todos conhecem] do zero.
• Otimize sua infra-estrutura. Procure a melhor forma de deploy da aplicação. Qual hardware é mais adequado, qual sistema operacional e arquitetura. Faça tunning do webserver (workers, pool, memória), módulos e load balance. Utilize uma versão otimizada do interpretador, como o Ruby Enterprise Edition, JRuby ou Rubinius.
• Monitore sua aplicação. Uma vez que esteja em produção, monitore-a em busca de gargalos e possíveis pontos de otimização. Existem várias ferramentas para ajudá-lo nessa tarefa, como o Hoptoad, NewRelic, ou até mesmo o Rubinius Profiler.
• Otimize sua aplicação. O log é seu melhor amigo no desenvolvimento. Não ignore queries demoradas ou que geram N+1, otimize-as! Faça profiling, analise e otimize o código. Utilize caching para serviços externos e para páginas. Caching pode ser a melhor alternativa para turbinar sua aplicação, mas use-o com sabedoria. Bancos de dados não devem ser um problema, por isso saiba escolher a melhor distribuição para seu caso. Mesmo que NoSQL esteja na moda, não quer dizer que é a melhor solução para sua aplicação (a menos que seja necessário para o negócio).
• Simplifique o desenvolvimento. Fameworks ajudam bastante, mas use-os com sabedoria para não inflar o stack da aplicação. Em certas situações, vale mais a pena desenvolver algo simples do zero do que utilizar algo pronto, pesado e que precise ser adaptado para sua necessidade. Escreva menos: quanto menor seu código, mais rápido será sua execução. Camadas são perigosas: evite rodeios e escreva código que realmente interessa. E lembre-se: sempre existe uma ferramenta certa para cada problema.

SIMPLIFIQUE!

Tenha sempre a palavra SIMPLES gravada na sua mente. Se uma coisa exigir muito esforço para ser feita, talvez nem valha a pena. Volte para o início, pense novamente e busque uma ALTERNATIVA mais rápida/fácil/barata. Quanto melhor for sua técnica, melhor serão suas escolhas. Pratique constantemente.

Se você está pensando em fazer o deploy da sua aplicação Rails em um server Nginx com Phusion Passenger, você está no caminho certo! Não apenas pela segurança e performance do Nginx, mas também pela facilidade de instalação e configuração quando comparado à outros web servers populares.

A instalação do Nginx bem como configuração do módulo do Passenger são relativamente simples. A documentação de ambos é bem completa. Você provavelmente não terá muita dificuldade. Eu recomendo seguir o passo-a-passo da instalação do Passenger:

  passenger-install-nginx-module

Uma vez que tudo esteja instalado, é hora de configurar o Nginx editando o arquivo nginx.conf (provavelmente localizado em /usr/local/nginx/conf/nginx.conf)

Usando sub URI

O deploy como sub URI torna sua aplicação acessível com o endereço http://dominio.com/app1, sendo app1 o nome da sua aplicação. Supondo que diretório público do Nginx esteja em /var/www e sua aplicação Rails em /var/rails/app1, configure-o assim:

http {
    ...
    server {
        listen 80;
        server_name dominio.com www.dominio.com;
        root /var/www;
        passenger_enabled on;
        passenger_base_uri /app1;
    }
    ...
}

Ainda é preciso criar um link simbólico para que o contexto da aplicação Rails seja visível pelo document root em /var/www:

ln -s /var/rails/app1/public /var/www/app1

Reiniciando o Nginx, sua aplicação já estará rodando. Para adicionar outras aplicações, basta adicionar:

        passenger_base_uri /app1;
        passenger_base_uri /app2;
        passenger_base_uri /app3;

E em seguida criar os links simbólicos como descrito acima. Nota importante: em alguns casos, será necessário informar a URL relativa correta nas configurações do Rails:

   config.action_controller.relative_url_root = "/app1"

Usando subdomain

O deploy como subdomain torna sua aplicação acessível com o endereço http://app1.dominio.com. Basta configurar o Nginx como segue:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
}

Note que o root aponta diretamente para o diretório “public” da aplicação Rails. Para fazer o deploy de outras aplicações como subdomínio, basta configurar outro “server”, alterando root e o server_name:

http {
    ...
    server {
        listen 80;
        server_name app1.dominio.com;
        root /var/rails/app1/public;
        passenger_enabled on;
    }
    ...
    server {
        listen 80;
        server_name app2.dominio.com;
        root /var/rails/app2/public;
        passenger_enabled on;
    }
    ...
}

Uma vez que o DNS do host esteja corretamente configurado, suas aplicações estarão acessíveis em http://app1.dominio.com, http://app2.dominio.com, etc.

Dúvidas ou sugestões, utilizem os comentários. Sucesso!

Enviar emails de uma aplicação Rails é muito simples. A parte complicada fica com a configuração do ambiente e do servidor de email. Se você não souber ou não tiver muita paciência para fazer isso (por exemplo instalar e configurar sendmail, mutt, etc), pode facilmente usar sua conta do Gmail para enviar as mensagens da sua aplicação.

Basta incluir as seguintes configurações no bloco config dos respectivos ambientes da aplicação (por exemplo, config/environments/production.rb):

  config.action_mailer.delivery_method = :smtp
  config.action_mailer.smtp_settings = {
    :enable_starttls_auto => true,
    :authentication => :plain,
    :address => smtp.gmail.com,
    :port => 587,
    :user_name => "seuemail@gmail.com",
    :password => "suasenha"
  }

O toque mágico é a chave :enable_startls_auto => true para habilitar TLS. Sucesso!

Quantas vezes você precisou buscar alguma informação externa para sua aplicação, como um número de telefone ou uma foto em algum site? A idéia é simples: criar um crawler script para fazer parse de algum conteúdo HTML. E basta apenas Ruby e Nokogiri.

Exemplo

Digamos que eu queira obter a última versão de uma dada gem consultando diretamente no site http://rubygems.org para me ajudar quando precisar instalar novas gems no meu ambiente. Vamos ao código:

#!/usr/bin/env ruby
 
require "rubygems"
require "open-uri"
require "nokogiri"
 
gem = ARGV[0]
site = open("http://rubygems.org/gems/#{gem}")
document = Nokogiri::HTML(site)
version = document.css(".title h3").text
 
puts "#{gem} version #{version}"

Vou salvar esse script no arquivo gem-version.sh, torna-lo executável com chmod +x gem-version.sh em seguida executar no terminal:

$ ./gem-version rails
  rails version 3.0.3

Pronto, agora você também pode brincar à vontade com Nokogiri no seu shell!