Este método pode receber diferentes tipos de objetos como argumento.

• Uma instância de Date.
• Um UNIX Epoch Time.
• Uma string no formato RFC 8601.
• Uma string no formato RFC 2822, formato aceito pela função Date.parse.

A primeira implementação que eu tinha era apenas uma função que fazia tudo isso.

Utils.parseDate = function(timestamp) {
  var matches, date;
  var diff = 0;

  // we have a date, so just return it.
  if (timestamp.constructor === Date) {
    return timestamp;
  };

  matches = timestamp.toString().match(/(\d{4})-(\d{2})-(\d{2})(?:[ T](\d{2}):(\d{2}):(\d{2}))?(Z|[+-]\d+)?/);

  if (matches) {
    for (var i = 1; i <= 6; i++) {
      matches[i] = parseInt(matches[i], 10) || 0;
    }

    // month starts on 0
    matches[2] -= 1;

    date = new Date(Date.UTC(matches[1], matches[2], matches[3], matches[4], matches[5], matches[6]));

    // Check if timezone is available.
    matches = matches[7] && timezone.match(/^([+-])(\d{2})(\d{2})/);

    if (matches) {
      diff += parseInt(matches[2], 10) * 60 * 60 * 1000;
      diff += parseInt(matches[3], 10) * 60 * 1000;
      diff *= matches[1] === "-" ? 1 : -1;
      date.setTime(date.getTime() + diff);
    }
  } else if (typeof(timestamp) == "number") {
    // UNIX timestamp
    date = new Date();
    date.setTime(timestamp);
  } else if (timestamp.match(/\d+ \d+:\d+:\d+ [+-]\d+ \d+/)) {
    // a valid javascript format with timezone info
    date = new Date();
    date.setTime(Date.parse(timestamp))
  } else {
    // an arbitrary javascript string
    date = new Date();
    date.setTime(Date.parse(timestamp));
  }

  return date;
};

Embora a função não seja extremamente complicada, está fazendo mais do que deveria. A ideia aqui será extrair cada uma das condições em sua própria função construtora. Decidi criar um namespace chamado DateParser, que irá conter cada um dos adapters. O parsing do timestamp será feito na função parse(). Cada adapter pode estar em seu próprio arquivo, mas para facilitar este exemplo coloquei tudo junto.

Module("DateParser.Date", function(Adapter){
  Adapter.fn.initialize = function(timestamp) {
    this.timestamp = timestamp;
  };

  // The DateParse.Date adapter will receive a Date instance,
  // so we just have to return it.
  Adapter.fn.parse = function() {
    return this.timestamp;
  };
});

Module("DateParser.Timestamp", function(Adapter){
  Adapter.fn.initialize = function(timestamp) {
    this.timestamp = timestamp;
  };

  // We received a UNIX time, so we can just set it
  // through Date#setTime function.
  Adapter.fn.parse = function() {
    var date = new Date();
    date.setTime(this.timestamp);
  };
});

Module("DateParser.ISO8601", function(Adapter){
  Adapter.FORMAT_REGEX = /(\d{4})-(\d{2})-(\d{2})(?:[ T](\d{2}):(\d{2}):(\d{2}))?(Z|\+0000)?/;

  Adapter.fn.initialize = function(timestamp) {
    this.timestamp = timestamp;
  };

  Adapter.fn.parse = function() {
    var date;
    var matches = this.timestamp.match(Adapter.FORMAT_REGEX);
    var diff = 0;

    for (var i = 1; i <= 6; i++) {
      matches[i] = parseInt(matches[i], 10) || 0;
    }

    var year     = matches[1]
      , month    = matches[2] - 1 // remember that months starts on zero
      , day      = matches[3]
      , hours    = matches[4]
      , minutes  = matches[5]
      , seconds  = matches[6]
      , timezone = matches[7]
    ;

    // Always set the date as UTC. We'll consider the
    // timezone later on when is available.
    date = new Date(Date.UTC(year, month, day, hours, minutes, seconds));

    // Check if timezone is available.
    matches = timezone && timezone.match(/^([+-])(\d{2})(\d{2})/);

    if (matches) {
      diff += parseInt(matches[2], 10) * 60 * 60 * 1000;
      diff += parseInt(matches[3], 10) * 60 * 1000;
      diff *= matches[1] === "-" ? 1 : -1;
      date.setTime(date.getTime() + diff);
    }

    return date;
  };
});

Module("DateParser.RFC2822", function(Adapter){
  Adapter.fn.initialize = function(timestamp) {
    this.timestamp = timestamp;
  };

  Adapter.fn.parse = function() {
    var date = new Date();
    date.setTime(Date.parse(this.timestamp));
  };
});

A implementação da função DateParser.parse() vai mudar, pois precisaremos delegar o timestamp para cada um dos adapters. Vamos aproveitar para dar uma refatorada no modo como fazemos as condições.

Module("DateParser", function(DateParser){
  DateParser.parse = function(timestamp) {
    if (timestamp.constructor === Date) {
      return DateParser.Date(timestamp).parse();
    }

    if (typeof(timestamp) === "number") {
      return DateParser.Timestamp(timestamp).parse();
    }

    if (typeof(timestamp) === "string" && DateParser.ISO8601.FORMAT_REGEX.match(timestamp)) {
      return DateParser.ISO8601(timestamp).parse();
    }

    return DateParser.RFC2822(timestamp).parse();
  };
}, {});

Muito mais simples! Mas ainda temos espaço para melhorar essa implementação. Primeiro vamos extrair as condicionais para cada adapter. Note abaixo que estou exibindo apenas a função match().

Module("DateParser.Date", function(Adapter){
  Adapter.fn.match = function() {
    return this.timestamp.constructor === Date;
  };
});

Module("DateParser.Timestamp", function(Adapter){
  Adapter.fn.match = function() {
    return typeof(this.timestamp) === "number";
  };
});

Module("DateParser.ISO8601", function(Adapter){
  var FORMAT_REGEX = /(\d{4})-(\d{2})-(\d{2})(?:[ T](\d{2}):(\d{2}):(\d{2}))?(Z|[+-]\d+)?/;

  Adapter.fn.match = function() {
    return this.timestamp.toString().match(FORMAT_REGEX);
  };
});

Module("DateParser.RFC2822", function(Adapter){
  // Always return true, since this will be the default adapter.
  Adapter.fn.match = function() {
    return true;
  };
});

Agora, podemos alterar a implementação do método DateParser.parse para usar a função match() definido em cada um dos adapters. Note que esta função foi definida na instância. Isso significa que vamos ter que instanciar o adapter durante o processo de descoberta que faremos em um loop.

Vamos precisar de um array que define a ordem dos adapters.

Module("DateParser", function(DateParser){
  DateParser.parse = function(timestamp) {
    var adapters = ["Date", "Timestamp", "ISO8601", "RFC2822"];
  };
}, {});

Nós iremos usar a função Array.prototype.some para saber qual o adapter deve ser usado. Essa função para de ser executada quando um dos callbacks retornar true, o que é exatamente o precisamos fazer.

Module("DateParser", function(DateParser){
  DateParser.parse = function(timestamp) {
    var adapters = ["Date", "Timestamp", "ISO8601", "RFC2822"];
    var parser;

    adapters.some(function(name){
      // Retrieve the adapter and instantiate it with the
      // provided timestamp.
      parser = DateParser[name](timestamp);
      return parser.match();
    });

    // Finally return the parsed timestamp.
    return parser.parse();
  };
}, {});

É isso aí. Agora estou satisfeito com esta implementação!

Finalizando

No nosso exemplo, extrair cada parser e unificar a API desses adapters, automatizando o processo de descoberta de qual o adapter mais indicado para o timestamp passado como argumento tornou o nosso código muito mais simples de entender. Você não precisa, por exemplo, ler toda a função para saber como um determinado parser funciona.

Uma outra coisa que você precisa saber é que toda implementação possui espaço para melhorar. Mais importante que saber como fazer este tipo de melhoria é saber quando parar, pois isso pode ser uma coisa sem fim.

Estou fazendo o fórum do HOWTO e comecei a trabalhar no textarea de resposta. Minha ideia foi seguir a mesma linha do Disqus. Veja o objetivo final abaixo:

Sempre que preciso implementar esse tipo de coisa, começo pelo jeito mais simples, que é usar o "modo jQuery" de fazer as coisas. Primeiro vamos definir o markup (ou uma versão simplificada dele; na versão real estou usando atributos data para fazer algumas coisas com AJAX).

<div class="postbox">
  <textarea placeholder="Escreva sua resposta..."></textarea>
  <button class="reply-button">Enviar esta resposta</button>
</div>

Todas as animações são feitas com CSS3. Note que o CSS abaixo não contém as versões com prefixo, apenas para simplificar (eu uso Bourbon para isso).

.postbox {
  background: #f3f6f7;
  border: 1px solid #ccc;
  overflow: hidden;
  position: relative;
}

.postbox .reply-button {
  background: #606b73;
  border: none;
  bottom: -1px;
  color: #fff;
  display: none;
  float: right;
  overflow: hidden;
  padding: 10px 15px;
  position: relative;
  right: -1px;
}

.postbox textarea {
  box-sizing: border-box;
  border: none;
  height: 50px;
  outline: none;
  padding: 8px 10px;
  transition: height .2s ease-in;
  width: 100%;
}

.postbox textarea.is-taller {
  height: 300px;
}

.postbox.did-focus textarea {
  height: 150px;
}

.postbox.did-focus .reply-button {
  display: block;
}

.postbox.is-contracted textarea {
  height: 50px;
}

O textarea possui três alturas distintas. Quando ele não teve foco, sua altura é de 50px. Se ele teve foco, sua altura muda para 150px. Por fim, quando atingir 5 quebras de linha, ele mudará para 300px. Todas essas mudanças são feitas com classes CSS (ou a ausência delas).

Para lidar com o foco do textarea, comecei com a implementação abaixo. Toda vez que um textarea recebe o foco, adicionamos a classe did-focus e removemos a classe is-contracted.

$(".postbox textarea")
  .on("focus", function(){
    $(this).closest(".postbox")
      .addClass("did-focus")
      .removeClass("is-contracted")
    ;
  })
;

O próximo passo é ouvir o evento keyup, para fazer a contagem de linhas do textarea. Se tiver pelo menos cinco linhas, adicionamos a classe is-taller; caso contrário, removemos esta mesma classe.

$(".postbox textarea")
  .on("focus", function(){
    $(this).closest(".postbox")
      .addClass("did-focus")
      .removeClass("is-contracted")
    ;
  })

  .on("keyup", function(){
    var lines = this.value.split(/\r?\n/);
    var textarea = $(this);

    if (lines.length >= 5) {
      textarea.addClass("is-taller");
    } else {
      textarea.removeClass("is-taller");
    }
  })
;

Por fim, precisamos ouvir o evento blur para saber se o textarea possui algum conteúdo ou não e adicionar a classe is-contracted ao container .postbox de acordo com essa verificação.

$(".postbox textarea")
  .on("focus", function(){
    $(this).closest(".postbox")
      .addClass("did-focus")
      .removeClass("is-contracted")
    ;
  })

  .on("keyup", function(){
    var lines = this.value.split(/\r?\n/);
    var textarea = $(this);

    if (lines.length >= 5) {
      textarea.addClass("is-taller");
    } else {
      textarea.removeClass("is-taller");
    }
  })

  .on("blur", function(){
    if (!this.value) {
      $(this).closest(".postbox").addClass("is-contracted");
    }
  })
;

Esta implementação funciona, mas ela não é das melhores. Normalmente eu prefiro escrever códigos mais modulares, que são mais fáceis de testar, entender e dar manutenção.

Para começar, vamos definir um módulo deste componente, que irá receber o container .postbox durante sua inicialização. Além disso, iremos extrair os elementos usados pelo componente, fazendo caching e facilitando a referência aos elementos.

Module("HOWTO.Postbox", function(Postbox){
  Postbox.fn.initialize = function(container) {
    this.container = container;
    this.textarea = container.find("textarea");
    this.button = container.find(".button");
  };
});

Eu estou usando uma biblioteca chamada Module.js. Note que o objeto fn é apenas um atalho para prototype.

Vamos adicionar os eventos do textarea. Os bindings são feitos através da função HOWTO.Postbox.fn.addEventListeners.

Module("HOWTO.Postbox", function(Postbox){
  Postbox.fn.initialize = function(container) {
    this.container = container;
    this.textarea = container.find("textarea");
    this.button = container.find(".button");

    this.addEventListeners();
  };

  Postbox.fn.addEventListeners = function() {
    this.textarea
      .on("focus", this.onTextareaFocus.bind(this))
      .on("keyup", this.onTextareaKeyUp.bind(this))
      .on("blur", this.onTextareaBlur.bind(this))
    ;
  };
});

Perceba que estou usando a função Function.prototype.bind para forçar o contexto this para a instância de HOWTO.Postbox. Isso é uma coisa que sempre faço, e que é um dos motivos de confusão do JavaScript.

O modelo de eventos do JavaScript faz com que o contexto this seja sempre o elemento que lançou o evento. No exemplo acima, seria sempre o textarea, mas isso impossibilitaria o acesso à instância de HOWTO.Postbox.

Agora podemos implementar as funções que lidarão com os eventos. Elas permanecem essencialmente como na implementação original. A única diferença é que precisamos acessar o elemento através de event.target, já que o contexto this não é mais o próprio textarea.

Module("HOWTO.Postbox", function(Postbox){
  Postbox.fn.initialize = function(container) {
    this.container = container;
    this.textarea = container.find("textarea");
    this.button = container.find(".button");

    this.addEventListeners();
  };

  Postbox.fn.addEventListeners = function() {
    this.textarea
      .on("focus", this.onTextareaFocus.bind(this))
      .on("keyup", this.onTextareaKeyUp.bind(this))
      .on("blur", this.onTextareaBlur.bind(this))
    ;
  };

  Postbox.fn.onTextareaFocus = function(event) {
    this.container
      .addClass("did-focus")
      .removeClass("is-contracted")
    ;
  };

  Postbox.fn.onTextareaKeyUp = function(event) {
    var lines = event.target.value.split(/\r?\n/);

    if (lines.length >= 5) {
      this.textarea.addClass("is-taller");
    } else {
      this.textarea.removeClass("is-taller");
    }
  };

  Postbox.fn.onTextareaBlur = function(event) {
    if (!event.target.value) {
      this.container.addClass("is-contract");
    }
  };
});

Para usar o nosso componente, você pode ter algo assim:

$(".postbox").each(function(){
  HOWTO.Postbox($(this));
});

Finalizando

O código final é ligeiramente maior que a implementação original, mas tem uma vantagem: ele é mais simples de entender e manter. Isso porque as responsabilidades de cada função são bem definidas, em vez de termos um espaguete de código dentro de uma única função.

Lembre-se que em projetos maiores, seu JavaScript não é composto por poucas linhas e, no fim, a legibilidade e facilidade de manutenção são muito mais importantes que todo o resto.

class ProductsController < ApplicationController
  def index
    @products = Product.with_state(:published).limit(34).load
    respond_with @products
  end
end

Embora seja apenas uma única linha de consulta, fiz um refactoring alterando essa única linha para isso:

@products = Vitrine.load(34)

Essa abstração introduziu uma nova classe chamada Vitrine, que quebrei em diversos métodos menores.

class Vitrine
  def self.load(size, finder = Product)
    new(size, finder).load
  end

  def initialize(size, finder)
    @finder = finder
    @size = size
  end

  def published
    @finder.with_state(:published)
  end

  def limit
    @finder.limit(@size)
  end

  def scope
    published.merge(limit)
  end

  def load
    scope.load
  end
end

OMG! Trocar uma linha com 56 caracteres por um novo arquivo com 26 linhas e 347 caracteres? Faz sentido?

Ao meu ver, faz todo o sentido. Por ter quebrado essa consulta em uma nova classe, tive a flexibilidade de poder escrever testes completamente desacoplados do Rails.

require "test_helper_lite"
require "./app/models/vitrine"

class VitrineTest < ActiveSupport::TestCase
  test "delegates to the initializer" do
    finder = stub
    instance = stub

    instance.expects(:load)

    Vitrine
      .expects(:new)
      .with(10, finder)
      .returns(instance)

    Vitrine.load(10, finder)
  end

  test "scope searches by state" do
    finder = stub
    vitrine = Vitrine.new(10, finder)

    finder
      .expects(:with_state)
      .with(:published)

    vitrine.published
  end

  test "limits result" do
    finder = stub
    vitrine = Vitrine.new(10, finder)

    finder
      .expects(:limit)
      .with(10)

    vitrine.limit
  end

  test "merges scope" do
    published = stub
    limit = stub
    finder = stub
    vitrine = Vitrine.new(10, finder)

    vitrine.stubs(limit: limit, published: published)
    published.expects(:merge).with(limit)

    vitrine.scope
  end

  test "loads products" do
    finder = stub
    scope = stub
    vitrine = Vitrine.new(10, finder)

    vitrine.stubs scope: scope
    scope.expects(:load)

    vitrine.load
  end
end

Perceba que estou apenas validando a interface desta classe, o que exige que eu escreva testes de integração, ou estarei testando apenas stubs.

O ponto é o seguinte: até onde esse tipo de abstração traz benefícios? Fui questionado sobre a vantagem de ter trocado uma única linha por vinte e cinco delas.

Minha alteração foi movida pela segurança que escrever este tipo de testes me traz. É infinitamente mais simples encapsular este comportamento e ter testes isolados, do que deixar em um controller e ter testes por lá.

Justificar a implementação de uma determinada funcionalidade não deve ser motivada apenas pelo teste, mas eu quase sempre não consigo fazer a desassociação. Se é difícil de testar, deve existir uma maneira melhor.

Eu continuo acreditando que ter uma classe desacoplada com testes isolados que validam sua interface, juntamente com testes de integração é a melhor abordagem, mas confesso que bateu uma dúvida.

O que você acha? Esse tipo de abstração faz sentido ou é apenas overengineering? O que você faria de diferente?

O SPDY não veio para substituir o protocolo HTTP. Na verdade, ele modifica o modo como as respostas e requisições HTTP são realizadas. Em vez de realizar diversas requisições para carregar os elementos de uma página, o SPDY estabelece uma única conexão e trabalha com multiplexing, ou seja, pacotes de diversas requisições são combinados e enviados por esta única conexão. Com isso, é possível ter até 64% de redução no tempo de carregamento das páginas.

Mas e quanto aos navegadores que suportam o SPDY? O suporte ainda não é completo, mas a lista já é bastante promissora.

• Firefox 15+
• Chrome 11+
• Opera

Instalando o NGINX com suporte ao SPDY

Se você se interessou, saiba que o NGINX possui suporte experimental ao SPDY. Esta funcionalidade foi patrocinada pela Automattic, empresa por trás do Wordpress.

Para instalar o NGINX com suporte ao SPDY, você vai precisar compilá-lo à partir do código-fonte.

$ wget http://nginx.org/download/nginx-1.3.13.tar.gz
$ tar xvfz nginx-1.3.13.tar.gz
$ cd nginx-1.3.13
$ wget http://nginx.org/patches/spdy/patch.spdy.txt
$ patch -p1 < patch.spdy.txt
$ ./configure --with-http_ssl_module --with-http_spdy_module
$ make
$ make install

Se você está usando o Ubuntu 12.04 Precise Pangolin, pode usar o repositório Debian da Hellobits, que possui o pacote nginx-plus, com algumas outras extensões como Redis, Websockets e outras.

Primeiro, adicione a chave pública GPG.

$ wget -O - http://apt.hellobits.com/hellobits.key | sudo apt-key add -

Depois, adicione o repositório.

echo 'deb http://apt.hellobits.com/ precise main' | sudo tee /etc/apt/sources.list.d/hellobits.list

Agora basta atualizar a lista de pacotes e instalar o pacote nginx-plus.

$ sudo apt-get update
$ sudo apt-get install nginx-plus

Configurando o NGINX

Você vai precisar de um certificado SSL para poder usar o SPDY. Se você precisa de certificados SSL, recomendo o site CheapSSLs. Um certificado de 5 anos da PositiveSSL custa apenas $25.

Para configurar o NGINX, basta adicionar poucas linhas ao seu bloco server. Veja, por exemplo, as configurações que estou usando no Simples Ideias.

server {
  listen 443 ssl spdy;
  server_name simplesideias.com.br;
  root /var/www/simplesideias/current/public;

  ssl_certificate /etc/nginx/ssl/simplesideias.com.br/ssl.crt;
  ssl_certificate_key /etc/nginx/ssl/simplesideias.com.br/ssl.key;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;
  ssl_prefer_server_ciphers on;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers RC4:HIGH:!aNULL:!MD5;

  # other config
}

Verifique se as configurações estão corretas e reinicie o servidor.

$ sudo nginx -t
$ sudo nginx -s reload

Se você usa o Google Chrome, existe uma extensão que permite verificar se o site que você está visitando possui suporte ao SPDY. O Firefox possui uma extensão semelhante.

Se você ainda está preso no Ruby 1.8, a história é muito diferente. À partir de Junho de 2013 ele deixará de ter atualizações. E isso inclui atualizações de segurança. Por isso, meu conselho é que você comece a fazer a migração o mais rápido possível.

Neste artigo irei mostrar as principais mudanças introduzidas pela nova versão, lançada no dia 24/02/2013.

Trivia: Você sabia que o lançamento do Ruby 2.0 foi exatamente no dia em que o Ruby completou seu vigésimo aniversário?

Argumentos nomeados

Nós já estamos acostumados a usar hashes quando precisamos passar muitos argumentos para um método. Assim, não temos que nos preocupar com sua ordem e obrigatoriedade.

Agora você pode usar argumentos nomeados, que na assinatura do método se parecem muito com a definição de hashes.

Veja o método abaixo. Ele aceita um único hash com diversas chaves. Se você quiser extrair seus valores em variáveis, é preciso fazer isso manualmente.

def link(options = {})
  href = options[:href]
  text = options[:text]

  puts "href: #{href}"
  puts "text: #{text}"
end

No Ruby 2.0 isso não é mais necessário. Basta definir seus argumentos com o valor de inicialização e a variável será definida automaticamente.

def link(href: nil, text: nil)
  puts "href: #{href}"
  puts "text: #{text}"
end

Se você quiser, pode executar o método com os argumentos em ordem arbitrária.

link href: "http://simplesideias.com.br", text: "SimplesIdeias"
link text: "Hellobits", href: "http://hellobits.com"

Mas o que acontece se passarmos argumentos que não foram definidos?

link rel: "external", text: "Codeplane", href: "http://codeplane.com"
#=> ArgumentError: unknown keyword: rel

Neste caso, uma exceção ArgumentError será lançada, informando qual argumento não foi definido. Se você quiser, pode pegar uma referência para todos os argumentos que forem passados mas não definidos na assinatura do método. Basta usar o double splat.

def link(href: nil, text: nil, **keywords)
  puts "href: #{href}"
  puts "text: #{text}"
end

Todo e qualquer argumento nomeado que não for definido na assinatura do método será armazenado em um hash, que aqui foi chamado de keywords.

Como fica, então, a assinatura do método se eu tiver parâmetros ordenados misturados com parâmetros nomeados?

def catch_all(*args, **keywords)
  p args
  p keywords
end

catch_all "WOW!", "Ruby 2.0 rules!", message: "It rules indeed!"
#=> ["WOW!", "Ruby 2.0 rules!"]
#=> {:message=>"It rules indeed!"}

Note que não é possível mudar a posição do double splat. Se você quiser mesclar argumentos ordenados e nomeados, passe primeiro os ordenados e depois os nomeados.

Uma outra restrição dos argumentos nomeados é que você não pode ignorar os argumentos não definidos sem passar uma variável. Com argumentos ordenados você pode simplesmente usar o *.

def catch_args(*)
end

No caso de argumentos nomeados, ainda não é possível definir apenas **, mas isso já foi corrigido e deve entrar no próximo release.

def catch_keywords(**)
end

catch_keywords a: 1
#=> ArgumentError: unknown keyword: a

O método Method#parameters identifica argumentos nomeados com o símbolo :key e :keyrest.

def inspect_parameters(a, b = nil, *args, c: nil, **keywords, &block)
end

p method(:inspect_parameters).parameters
#=> [
#     [:req, :a],
#     [:opt, :b],
#     [:rest, :args],
#     [:key, :c],
#     [:keyrest, :keywords],
#     [:block, :block]
#   ]

Arrays de símbolos

O Ruby já possuia muitas construções literais para arrays, strings e expressões regulares, como %w[], %() e %r[]. O Ruby 2.0 adicionou mais uma construção, que agora permite criar arrays de símbolos.

platforms = %i[mac windows linux]
[:mac, :windows, :linux]
#=>

O literal %i não permite interpolar valores. É aí que entra o %I.

%i[#{Time.now}]
#=> [:"\#{Time.now}"]

%I[#{Time.now}]
#=> [:"2013-02-26 19:13:13 -0300"]

Encoding

No Ruby 1.9, o encoding padrão é US-ASCII. Isto significa que se você quiser usar caracteres acentuados, por exemplo, precisa definir o magic comment ou uma exceção será lançada.

puts __ENCODING__
#=> US-ASCII

text = "áéíóú"
puts text
#=> invalid multibyte char (US-ASCII)

Agora, o encoding padrão é UTF-8. Você não precisa mais adicionar o magic comment, há menos que queira manter a compatibilidade com o Ruby 1.9, o que é uma boa ideia. Veja este mesmo código ao ser executado no Ruby 2.0:

puts __ENCODING__
#=> UTF-8

text = "áéíóú"
puts text
#=> áéíóú

Module#prepend

Você já deve ter sentido a necessidade de estender o comportamento de um método. Imagine que você tem uma classe chamada MyClass, que possui um único método MyClass#foo. Você precisa estender este método, executando algo antes e depois da implementação original.

class MyClass
  def foo
    puts "foo"
  end
end

Você tem duas alternativas para resolver este problema. A primeira usa os métodos Module.define_method e Module.instance_method e é a mais recomendada, já que não causa efeitos colaterais.

class MyClass
  foo_method = instance_method(:foo)

  define_method :foo do
    puts "before foo"
    result = foo_method.bind(self).call
    puts "after foo"
    result
  end
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

A segunda alternativa, muito comum diga-se de passagem, seria renomear o método e executá-lo com este novo nome. O problema acontece se alguém teve a mesma ideia que você e também renomeou o método para MyClass#foo_original.

class MyClass
  alias_method :foo_original, :foo

  def foo
    puts "before foo"
    result = foo_original
    puts "after foo"
    result
  end
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Se você está no Rails, é possível usar o método Module#alias_method_chain, que segue a mesma ideia do Module#alias_method.

require "active_support/all"

class MyClass
  def foo_with_puts
    puts "before foo"
    result = foo_without_puts
    puts "after foo"
    result
  end

  alias_method_chain :foo, :puts
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Com o método Module#prepend isso se torna muito mais simples. Ele permite alterar a hierarquia de classes e módulos de modo que este módulo seja adicionado antes da própria classe. Assim, podemos trocar todas as soluções anteriores por esta, que usa o super.

module FooExtension
  def foo
    puts "before foo"
    result = super
    puts "after foo"
    result
  end
end

class MyClass
  prepend FooExtension
end

MyClass.new.foo
#=> before foo
#=> original
#=> after foo

Mas como isso funciona? Se você executar o método Module.ancestors, verá que o módulo FooExtension foi adicionado na hierarquia antes mesmo da própria classe MyClass.

MyClass.ancestors
#=> [FooExtension, MyClass, Object, Kernel, BasicObject]

Por isso é possível chamar o super, que por sua vez irá executar o método MyClass#foo.

Protocolo to_h

Finalmente temos um protocolo oficial para converter objetos em uma representação em Hash. Trata-se do método to_h, que agora é implementado em várias classes do Core como NilClass, Struct e OpenStruct.

Veja, por exemplo, como fica isso com a classe OpenStruct:

require "ostruct"

user = OpenStruct.new(:name => "John Doe", :email => "john@example.org")

# Ruby 1.9
user.to_h
#=> nil

# Ruby 2.0
#=> {:name => "John Doe", :email => "john@example.org"}

Com a classe Struct o comportamento é semelhante.

User = Struct.new(:name, :email)
user = User.new("John Doe", "john@example.org")

user.to_h
#=> {:name=>"John Doe", :email=>"john@example.org"}

No caso de nil, um Hash vazio é retornado.

nil.to_h
#=> {}

No Ruby 1.9 os métodos NilClass#to_h e Struct#to_h não existem.

Expressões Regulares

O Ruby 2.0 mudou seu engine de expressão regular mais uma vez. O Oniguruma saiu para dar lugar ao Onigmo, um fork do Oniguruma com novas funcionalidades.

Uma das novidades introduzidas pelo Onigmo é a possibilidade de se ter condicionais na expressão regular. Também foram adicionadas algumas funcionalidades do Perl 5.10+.

Para saber quais sintaxes são aceitas no Ruby, acesse a documentação do Onigmo.

Refinements

Uma das grandes preocupações de quem começa a usar Ruby é em relação às classes abertas. A justificativa quase sempre envolve o perigo que existe em modificar classes existentes. Na prática, isso quase nunca acontece, embora vez ou outra você vai dar de frente com um código que faz algo muito bizarro (e que não deveria), mais por culpa do desenvolvedor meia-boca que do Ruby.

Tentando amenizar este problema, o Ruby 2.0 introduziu o Refinements, que é uma maneira de fazermos Monkey Patching de modo mais controlado.

Para mostrar como o Refinements funciona, vamos estender a classe Integer com o método Integer#minutes, que retorna a quantidade de segundos. Você poderia adicionar este método diretamente à classe Integer.

class Integer
  def minutes
    self * 60
  end
end

class MyLib
  puts 3.minutes
  #=> 180
end

puts 5.minutes
#=> 300

É exatamente isso que o ActiveSupport faz, estendendo classes do Core como Time, Date, Hash, Array, dentre outras. O questão é que essas extensões são aplicadas em todo o Ruby.

Para resolver este problema, o Ruby 2.0 adicionou os métodos Module.refine e Module.using. A ideia é adicionar este tipo de extensão de um modo mais controlado. A proposta inicial permitia fazer isso.

module TimeExtension
  refine Integer do
    def minutes
      self * minutes
    end
  end
end

class MyLib
  using TimeExtension

  puts 3.minutes
  #=> 180
end

puts 5.minutes
#=>  undefined method `minutes' for 5:Fixnum (NoMethodError)

Infelizmente a implementação presente no Ruby 2.0 é experimental e reduzida. Este exemplo acima não funciona no Ruby 2.0.0-p0, mas funciona no Ruby 2.0.0-preview1. Em vez disso, você precisa fazer a chamada do método using() no contexto principal. As extensões aplicadas por este serão aplicadas apenas ao arquivo que fez a chamada.

# file: time_extension.rb
module TimeExtension
  refine Integer do
    def minutes
      self * 60
    end
  end
end

# file: with_refinement.rb
require_relative "time_extension"
using TimeExtension

puts 5.minutes
#=>  300

# file: without_refinement.rb
require_relative "time_extension"

puts 5.minutes
#=> undefined method `minutes' for 10:Fixnum (NoMethodError)

Existem muitas incertezas quanto ao modo como o Refinements deve funcionar. O Charles Nutter escreveu um ótimo artigo falando sobre a complexidade e problemas que o Refinements introduz.

Warnings

o Ruby gerará um warning toda vez que você executar um programa com o flag -w se você declarar uma variável e não usá-la.

def parse_name(full_name)
  first, last = full_name.split(" ")
  first
end

parse_name("John Doe")

Ao executarmos esse código:

$ ruby -c -w unused_var.rb
unused_var.rb:2: warning: assigned but unused variable - last
Syntax OK

No Ruby 2.0, variáveis começadas com _ não irão mais gerar estes warnings, mesmo quando não utilizadas.

def parse_name(full_name)
  first, _last = full_name.split(" ")
  first
end

parse_name("John Doe")

E ao verificar a sintaxe:

$ ruby -c -w unused_var.rb
Syntax OK

Constantes

Imagine que você tem uma constante A::B e quer pegar uma referência através do seu nome. Se você utilizar o método Object.const_get, verá que uma exceção será lançada.

module A
  module B
  end
end

Object.const_get("A::B")
#=> NameError: wrong constant name A::B

Para pegar a constante A::B você tinha iterar cada parte do nome da constante.

"A::B"
  .split("::")
  .reduce(Object) {|scope, name| scope.const_get(name) }
#=> A::B

Agora, isso ficou muito mais simples e funciona exatamente do jeito que você espera:

Object.const_get("A::B")
#=> A::B

Enumerator#lazy

O Ruby 2.0 introduziu um modo de criarmos enumerators que podem ser executados em conjuntos grandes ou mesmo infinitos. Veja o intervalo abaixo, por exemplo.

range = (1..Float::INFINITY)

Imagine que você quer pegar os 10 primeiros números primos maiores que 50. Com o método Enumerator#lazy, o estilo de programação não muda nada.

require "prime"

range = (0..Float::INFINITY)

primes = range.lazy
  .reject {|number| number < 50 }
  .select(&:prime?)
  .first(10)

primes
#=> [53, 59, 61, 67, 71, 73, 79, 83, 89, 97]

Se você tentar executar isso sem o método Enumerator#lazy, prepare-se para usar o Ctrl+C. Isso porque o Ruby tentará criar um objeto contendo o intervalo de 0 a infinito, o que obviamente não irá funcionar.

Já com o método Enumerator#lazy, apenas os elementos solicitados é que serão gerados, o que no nosso caso é bastante rápido de fazer, porque estamos acessando apenas 97 números.

Você não precisa ser tão radical quanto ao tamanho da coleção. Mesmo em uma lista muito menor, é possível ver a diferença. Vamos fazer um benchmark com este mesmo exemplo, mas desta vez usando uma coleção com apenas 1000 números.

require "benchmark"
require "prime"

range = (0..1000)
cycles = 1_000

def primes(range)
  range
    .reject {|number| number < 50 }
    .select(&:prime?)
    .first(10)
end

Benchmark.bmbm do |x|
  x.report("with lazy") do
    cycles.times{ primes(range.lazy) }
  end

  x.report("without lazy") do
    cycles.times{ primes(range) }
  end
end

O diferença é muito grande!

Rehearsal ------------------------------------------------
with lazy      0.250000   0.000000   0.250000 (  0.243124)
without lazy   4.800000   0.000000   4.800000 (  4.808169)
--------------------------------------- total: 5.050000sec

                   user     system      total        real
with lazy      0.290000   0.000000   0.290000 (  0.290303)
without lazy   4.250000   0.000000   4.250000 (  4.244091)

Já em coleções menores, usar o Enumerator#lazy pode não ser uma boa ideia. Mudando a quantidade de números gerados para 0..100, temos um resultado um pouco diferente.

Rehearsal ------------------------------------------------
with lazy      0.260000   0.000000   0.260000 (  0.260372)
without lazy   0.220000   0.010000   0.230000 (  0.226624)
--------------------------------------- total: 0.490000sec

                   user     system      total        real
with lazy      0.260000   0.000000   0.260000 (  0.262915)
without lazy   0.200000   0.000000   0.200000 (  0.200987)

TracePoint

O Ruby possui o método Kernel#set_trace_func, que permite rastrear diversos eventos durante a execução do código. Ele aceita um bloco, que pode receber até seis argumentos.

set_trace_func proc {|event, file, line, method, binding, class_name|
  puts "%8s %s:%-2d %10s %8s" % [event, file, line, method, class_name]
}

class Foo
  def initialize(options = {})
    @options = options
  end
end

Ao executar este arquivo, teremos uma saída como esta:

$ ruby trace.rb
  c-return trace.rb:1   set_trace_func     Kernel
      line trace.rb:5
    c-call trace.rb:5        inherited      Class
  c-return trace.rb:5        inherited      Class
     class trace.rb:5
      line trace.rb:6
    c-call trace.rb:6     method_added     Module
  c-return trace.rb:6     method_added     Module
       end trace.rb:9

Você pode ouvir até oito eventos diferentes:

• line: uma nova linha foi executada
• class: uma nova definição de classe/módulo
• end: fim da definição de classe/módulo
• call: um método foi executado por um método Ruby
• c-call: um método foi retornado por um método C
• return: um valor foi retornado por um método Ruby
• c-return: um valor foi retornado por um método C
• raise: uma exceção foi lançada

O Ruby 2.0 introduziu uma nova classe chamada TracePoint, que permite utilizar a mesma funcionalidade do método Kernel#set_trace_func usando uma API orientada a objetos.

Usando a classe TracePoint, o exemplo acima seria definido assim:

trace = TracePoint.new do |t|
  puts "%10s %s:%-2d %15s %10s" % [t.event, t.path, t.lineno, t.method_id, t.defined_class]
end

A saída é um pouco diferente, pois o nome do evento possui _ em vez de -.

$ ruby trace.rb
  c_return trace.rb:9           enable TracePoint
      line trace.rb:11
    c_call trace.rb:11       inherited      Class
  c_return trace.rb:11       inherited      Class
     class trace.rb:11
      line trace.rb:12
    c_call trace.rb:12    method_added     Module
  c_return trace.rb:12    method_added     Module
       end trace.rb:15

Se você quiser, pode ouvir um evento específico. Para isso, basta passar seu nome para o initializer.

trace = TracePoint.new(:class, &block)

Diretório corrente de um arquivo

Agora é possível pegar uma referência do diretório atual de um script que está sendo executado com o método Kernel#__dir__.

puts __FILE__
#=> ruby20_dir.rb

puts __dir__
#=> /Projects/samples

O método Kernel#__dir__ é equivalente a:

File.dirname(File.realpath(__FILE__))

Note que ele é todo em minúsculas, ao contrário de __FILE__. Isso acontece porque __FILE__ é apenas uma expressão, enquanto Kernel#__dir__ é um método. Não que isso seja uma justificativa, já que podemos criar um alias para este método, adicionando uma versão toda em maiúsculas.

module Kernel
  alias_method :__DIR__, :__dir__
end

puts __dir__
#=> /Projects/samples

puts __DIR__
#=> /Projects/samples

DTrace

O Ruby 2.0 trouxe integração com o DTrace, uma ferramenta que permite fazer a análise de performance e errors do sistema operacional e programas executados. O probes reconhecidos pelo Ruby estão disponíveis no wiki do projeto.

Outras mudanças

• A classe Iconv foi removida. A recomendação é que use o método String#encode. O uso do Iconv já era desaconselhado na versão 1.9.
• Os métodos String#chars, String#lines, String#codepoints e String#bytes agora retornam um Array, em vez de Enumerator. Use os métodos String#each_(char|line|byte|codepoints) se você quiser um Enumerator.
• A biblioteca net/http agora suporta Server Name Indication (SNI), uma extensão do protocolo SSL que indica o hostname no início do processo de handshake. Assim, é possível usar múltiplos certificados SSL com um único endereço IP.
• O método Kernel#require teve algumas otimizações que diminuem o tempo de boot de um app Rails.
• A classe CGI agora implementa o HTML5.

Finalizando

Como você pode perceber, o Ruby 2.0 tem muitas novidades. Eu não listei aqui tudo o que tem novo. Para saber exatamente o que entrou nesta versão, acesse a documentação.

Tenho que dizer que estou muito empolgado com esta versão! Se o Rails 4 der uma forcinha e exigir o Ruby 2.0, seria excelente! E isso não é nada impossível, já que em todos os projetos que testei o Ruby 2.0, nenhum precisou de mudanças para rodar o Rails 3.2.

O Ruby 2.0 trás uma série de novidades como argumentos nomeados em métodos, array literal para criação de símbolos, UTF-8 como encoding padrão, e muito mais. Se você já estava rodando seus projetos no Ruby 1.9 não precisará mexer quase nada. Algumas gems podem não estar funcionando, mas a tendência é que tenhamos uma série de atualizações nas próximas semanas. Vale notar que nenhum dos projetos que testei teve falhas desse tipo.

Veja à seguir como instalar o Ruby 2.0 em seu Ubuntu.

Removendo o ruby-stable/ruby-ichi

Se você já tinha instalado o Ruby 1.9 seguindo este outro tutorial, você precisará remover o Ruby.

$ sudo apt-get remove ruby-stable

ou

$ sudo apt-get remove ruby-ichi

Instalando o ruby-ni

Primeiro você precisará adicionar a chave pública GPG. Para isso, execute o comando abaixo em seu terminal. Se você já tinha instalado o pacote ruby-stable/ruby-ichi, pule esta etapa.

$ wget -O - http://apt.hellobits.com/hellobits.key | sudo apt-key add -

Agora, adicione o o repositório. Basta criar o arquivo /etc/apt/sources.list.d/hellobits.list. Você pode fazer executando o comando abaixo.

$ echo 'deb http://apt.hellobits.com/ precise main' | sudo tee /etc/apt/sources.list.d/hellobits.list

Finalmente, basta instalar o pacote Ruby.

$ sudo apt-get update
$ sudo apt-get install ruby-ni

Se tudo deu certo, o Ruby já deve estar disponível em seu sistema.

$ ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]

É importante que você apague todas as gems instaladas na versão anterior. Caso, contrário você terá alguns erros por causa da compilação.

$ rm -rf $(gem env gemdir)

Finalizando

Testei alguns projetos no Ruby 2.0 e até agora nenhum deles teve problemas. Ainda não coloquei em produção, mas devo fazer isso em breve (vou esperar um pouco para ver se nenhum novo release é lançado).

Se você precisa de pacotes para o Ubuntu 10.04 Lucid Lynx, deixe seu pedido nos comentários. Inicialmente não é minha ideia manter este pacote para o Ubuntu 10.04, mas se muita gente pedir, posso mudar de ideia!

É muito comum, por exemplo, termos um link para a página de login no header e no footer. Veja o exemplo abaixo:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
    <title>Awesome Site!</title>
  </head>

  <body>
    <header>
      <h1>Awesome Site!</h1>
      <a href="/login">Log in</a>
    </header>

    <!-- content -->

    <footer>
      <a href="/login">Log in</a>
    </footer>
  </body>
</html>

Na Capybara 1, você poderia referenciar este link sem ter que definir o contexto. Um simples click_link "Log in" já era suficiente. No Capybara 2.0 isso não é mais possível. Se você tentar fazer isso irá receber uma exceção dizendo que o seu matcher é ambíguo.

Failure/Error: click_link("Log in")
     Capybara::Ambiguous:
       Ambiguous match, found 2 elements matching link "Log in"

Agora é preciso que você seja específico quanto ao elemento que deseja utilizar. Neste caso, a solução mais recomendada é usar o método within, definindo o contexto de seleção do elemento.

within("header") do
  click_link "Log in"
end

Embora esta sugestão funcione, ela traz dois problemas. O primeiro é que você irá, provavelmente, duplicar este código em mais de um lugar e todos nós sabemos que duplicar código quase sempre não é uma boa ideia. O outro problema é que seu teste terá um ruído desnecessário que, dependendo do contexto, pode torná-lo muito mais difícil de ler e entender.

Minha sugestão, neste caso, é criar helpers que irão fazer isso por você. Assim você acaba com os problemas que citei acima.

Primeiro, crie um arquivo chamado "spec/support/feature_helpers.rb". Neste arquivo nós iremos criar um módulo com helpers que iremos utilizar no grupo de features. Em vez usar o método within, nós iremos usar o método find, que retorna um contexto onde podemos buscar os elementos que precisamos.

module FeatureHelpers
  def main_header
    find("header")
  end
end

RSpec.configure do |config|
  config.include FeatureHelpers, :type => :feature
end

A maior vantagem de se criar um método como esse é que o seletor está totalmente encapsulado. Se você precisar mudar o contexto por algum motivo, basta alterar em um único lugar!

Agora, basta alterar o nosso teste para usar este contexto.

main_header.click_link "Log in"

Você pode usar esta técnica sempre que perceber que está fazendo muitas coisas durante os testes.

Muitos bancos utilizam módulos de segurança em Java Applets, que podem ser executados à partir do navegador. No entanto, essa tecnologia é constantemente questionada, pois as falhas de segurança são constantes.

Para você ter uma ideia de quão séria foi a última falha de segurança, o Departamento de Segurança americano fez uma recomendação para que todos usuários desativassem imediatamente o Java de seus navegadores. Nos últimos 24 meses foram lançadas 16 atualizacões críticas e de segurança.

A verdade é que ninguém mais usa Java Applets. Ninguém além dos bancos brasileiros. Essas falhas extremamente críticas simplesmente deixam você de joelhos. Como é que bancos dizem que isso é uma medida de segurança? Não dá para entender.

Ontem criei um site chamado Módulos de Segurança, que tem o objetivo de avisar sobre os problemas que esses módulos trazem.

Passe a palavra adiante. Só assim teremos a chance de nos livrarmos deles.

Mesmo com esta medida, que usa o método ActiveRecord::Base.attr_accessible, foram iniciadas discussões sobre outras maneiras de se resolver o problema. O Rails 4 virá com uma funcionalidade que permite filtrar quais parâmetros pode ser recebidos, mas que pode ser usada hoje mesmo em seu app através da biblioteca strong_parameters.

Configurando seu app

Se você quiser, pode desativar a whitelist dos atributos que podem ser atribuídos. Para fazer isso, basta editar o arquivo "config/application.rb".

require File.expand_path("../boot", __FILE__)

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

Bundler.require(*Rails.groups(:assets => %w[development test]))

module HOWTO
  class Application < Rails::Application
    config.active_record.whitelist_attributes = false
  end
end

Particularmente acho uma boa ideia continuar usando o ActiveRecord::Base.attr_accessible, principalmente se você terá vários perfis de atribuição, como o exemplo abaixo:

class User < ActiveRecord::Base
  DEFAULT_ATTRIBUTES = [:name, :email, :password, :password_confirmation, :username]

  attr_accessible *DEFAULT_ATTRIBUTES
  attr_accessible *DEFAULT_ATTRIBUTES, :role, :as => :admin
end

Uma outra motivação é que o ponto de entrada de dados pode mudar na aplicação, como background jobs e importadores de conteúdo, e nem sempre queremos que todos os atributos sejam definidos por atribuição em massa.

Na prática, isso significa que um usuário que é admin, pode facilmente definir atributos extras usando este novo perfil.

User.new(params[:user], :as => :admin)

Independente de sua escolha, você precisará incluir o módulo ActiveModel::ForbiddenAttributesProtection em cada modelo que pretende proteger. Supondo que você queira fazer isso no modelo User:

class User < ActiveRecord::Base
  include ActiveModel::ForbiddenAttributesProtection
end

Não é preciso dizer que isso pode ser extremamente chato de se fazer. Uma alternativa é incluir este módulo diretamente na classe ActiveRecord::Base. Crie um arquivo "config/initializers/strong_parameters.rb" com o conteúdo abaixo. Óbviamente, isso fará com que todos os modelos sejam protegidos.

ActiveRecord::Base.class_eval do
  include ActiveModel::ForbiddenAttributesProtection
end

Agora você pode definir no controller quais atributos são obrigatórios, além da lista de atributos permitidos durante a atribuição.

class SignupController < ApplicationController
  def create
    @user = User.create(user_params)
    respond_with(@user)
  end

  private
  def user_params
    params
      .require(:user)
      .permit(:name, :email, :password, :password_confirmation, :username)
  end
end

Perceba que estou usando o método SignupController#user_params para definir quais serão os atributos utilizados. Se um atributo não permitido for atribuído, uma exceção ActiveModel::ForbiddenAttributes será lançada. E caso o atributo params[:user] não seja enviado, uma resposta 400 Bad Request será retornada com o texto Required parameter missing: user.

Uma das coisas que não gostei desta abordagem foi ter justamente estas configurações em meu controller. Eu penso que isso introduz um ruído um tanto quanto desnecessário. Pensando em uma forma de como diminuir este ruído, decidi criar uma classe chamada PermittedParams, que contém todas essas definições. Além disso, sobrescrevi o método ActionController::Base#params para que ele use esta mesma configuração.

Primeiro vamos sobrescrever o método ActionController#params. Abra o arquivo "app/controllers/application_controller.rb" e adicione as linhas abaixo:

class ApplicationController < ActionController::Base
  private
  def params
    PermittedParams.new(super)
  end
end

Nossa classe PermittedParams irá delegar todas as chamadas para a implementação original, definindo apenas nossos filtros.

class PermittedParams < SimpleDelegator
  def user
    params
      .require(:user)
      .permit(:name, :email, :password, :password_confirmation, :username)
  end

  private
  def params
    __getobj__
  end
end

Agora, precisamos alterar o nosso controller. Para isso, remova o método SignupController#user_params, substituindo pela nossa nova implementação.

class SignupController < ApplicationController
  def create
    @user = User.create(params.user)
    respond_with(@user)
  end
end

Todos os filtros de outros modelos devem ser adicionados à classe PermittedParams. A grande vantagem desta abordagem é que fica muito simples ver todos os filtros existentes no sistema. Além disso, em apps com um grande número de filtros, é muito fácil fazer a organização desses métodos em módulos que podem ser incluídos na classe PermittedParams.

Eu costumava usar o localtunnel pelo fato de ser gratuito, mas ele é muito lento. E pagar por um serviço desse tipo, onde só preciso expor serviços exporadicamente não faz muito sentido. Além disso, no caso do localtunnel pelo menos, se sua conexão cai, você receberá um novo endereço ao se reconectar. Isto nem sempre é um problema, mas às vezes é preciso configurar o serviço que está testando com esta nova URL (como é o caso do PagSeguro), o que não é nada prático.

Existe uma maneira muito simples de fazer isso usando SSH e um servidor web. E como uso o servidor do Simples Ideias como um playground, vou mostrar como foi simples fazer isso usando NGINX.

Depois de ter instalado o NGINX, você só precisa criar um novo arquivo de configuração de host, como no exemplo abaixo.

upstream tunnel {
  server 127.0.0.1:3000;
  server 127.0.0.1:1234;
  server 127.0.0.1:9292;
  server 127.0.0.1:4567;
}

server {
  listen 80;
  server_name dev.simplesideias.com.br *.dev.simplesideias.com.br;
  client_max_body_size  10M;

  location / {
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_pass http://tunnel;
  }
}

A primeira coisa que você deve notar é que estou usando um bloco upstream, que permite definir os servidores que o NGINX usará para responder à requisição (na prática, você irá configurar o NGINX como um load balancer). Neste caso, adicionei as portas que normalmente uso para Rails, Node.js, Rack e Sinatra.

Outra coisa que você deve notar é que este servidor responderá a qualquer requisição no subdomínio *.dev.simplesideias.com.br. Isso é muito interessante se você também precisa testar apps que usam subdomínios. Para configurar o seu servidor de DNS, basta criar um registro ALIAS (registro próprio da DNSimple) como o abaixo.

Após reiniciar o servidor, você já poderá redirecionar a porta local de sua máquina para este servidor remoto. Imagine que eu queira redirecionar a porta 3000 do Rails. Neste caso, basta executar o comando abaixo na máquina local:

ssh simplesideias.com.br -R 3000:localhost:3000

Este comando diz que vou redirecionar a porta localhost:3000 para a porta 3000 do servidor simplesideias.com.br. Note que neste caso não é preciso ter nenhuma permissão especial, já que a porta é maior que 1024.

Simples, e funciona que é uma maravilha! ;)