$.loading({
  onAjax: true,
  text: 'Carregando...',
  mask: true
});

A opção mask serve para adicionar uma div transparente que impossibilite novas ações ate a requisição acabar.

Esse funcionalidade é possível devido que as requisições Ajax do jQuery disparam certos eventos ao longo do processo, o que nos permite fazer coisas muito legais.

Isso quer dizer que você pode gerar um scaffold numa aplicação Rails, ir no modelo, trocar ActiveRecord::Base por ActiveLucene::Document e tudo deveria continuar funcionando, com a diferença do modelo estar sendo salvo num índice do Lucene e não num banco de dados relacional.

Dado que os documentos são salvos num índice do Lucene, podemos procurar eles utilizando a sintaxe de query do Lucene, sem esquecer que por ter uma interface similar à do ActiveRecord, podemos também procurar eles por um id.

A classe base do ActiveLucene se chama Document porque ao igual que os documentos de outros sistemas, não tem uma estrutura definida e todos os atributos são dinâmicos, pelo que você não tem que se preocupar com eles.

o ActiveLucene foi extraído do Lunr, um servidor do qual vou falar num futuro post, mas hoje também pode ser utilizado em aplicações nas quais ter um banco de dados relacionais no faz muito sentido e especialmente nas quais se deseja procurar documentos por texto.

A restrição do ActiveLucene é que somente funciona com JRuby, dado que o Lucene é uma biblioteca em Java que roda sobre a JVM. Mesmo assim, caso isso não for um problema, utilizar o ActiveLucene deve ser bem mais simples e leve que utilizar uma solução como o Sphinx ou o Solr, onde dependendo do caso pode resultar numa grande vantagem.

O Lucene tem um monte de funcionalidades e o ActiveLucene não suporta todas elas, mas dependendo das necessidades das pessoas elas serão indo adicionadas ao projeto. Hoje existe um suporte a highlighting e um pouco a paginação, como pode ser visto no seguinte video, junto com uma demonstração básica de como funciona a ferramenta:

Full text search in JRuby with ActiveLucene from Diego Carrion on Vimeo.

Se você gostou do ActiveLucene, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Umas das coisas que de cara ja não gosto no Locarails é que utiliza o Capistrano por debaixo dos panos. Eu ja expliquei por que não gosto muito do Capistrano mas em poucas palavras nesse caso isso se resume a ter um monte de pastas releases que não me servem para nada, ter tarefas como cap deploy e cap deploy:migration que não fazem muito sentido e para finalizar, ter um monstro chamado de receita.

Para entender melhor meu ultimo argumento podem visualizar esse gist, onde se encontra o arquivo deploy.rb configurado para trabalhar com Inploy e configurado para trabalhar com Locarails. Como podem ver, com o Inploy o arquivo de configuração fica bem mais simples e ainda faz mas coisas, aquelas que o Inploy faz por padrão, como por exemplo fazer um parse dos arquivos .less caso o plugin more exista. Essa funcionalidade foi adicionada também hoje.

Outra coisa que não gosto do Locarails é que por padrão ele funciona como modo “copy”, então fica copiando tudo o repositorio em cada deploy e ainda copia coisas que não deveria, como por exemplo arquivos de upload ou outros que se encontram no .gitconfig e não estão na lista de exclusão. Essa lista de exclusão pode ser configurada mas configurar é muito chato. Como resultado disso os deploy são mais demorados.

Como solução a isso, os colaboradores do Locarails parece que recentemente contornaram esse problema adicionando um modo “git”. Na minha máquina no chegou a funcionar mas foi excelente porque vendo o código percebi que tem um jeito muito possivelmente melhor de levar o repositorio para o servidor que o jeito atual utilizado pelo Inploy. A grão vantagem de utilizar Git no deploy é que em cada um somente vão as mudanzas, pelo que os deploys resultam ser bem mais rápidos.

Como puderam ver no arquivo de configuração, para utilizar Inploy na Locaweb basta declarar no arquivo de configuração (config/deploy.rb) que queremos utilizar o template :locaweb, o usuario e o host:

deploy.template = :locaweb
deploy.application = "hebraika"
deploy.user = 'dcrec1'
deploy.hosts = ['host.us']

Caso queiramos mandar a aplicação para uma pasta diferente de /home/:user/rails_app/:application, podemos configurar ela com deploy.path.

Gravei um pequeno video onde mostro muito rapidamente como utilizar o Inploy para realizar um deploy na Locaweb. Acho que o video esta bem claro mas se existir alguma duvida, não duvidar em questionar:

Deploy easily to Locaweb with Inploy from Diego Carrion on Vimeo.

Finalmente, queria deixar claro que eu acho o Locarails uma excelente solução para quem quer trabalhar com Capistrano, devido a que tira a responsabilidade de ter que configurar muita coisa. As coisas pelas quais eu não gosto do Locarais não são culpa dos colaboradores é sim do Capistrano, que era sem duvida a melhor opção na epoca em qual foi criado o plugin.

Se você gostou do plugin ou ele foi de alguma utilidade para você, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Existe uma gem chamada contacts que encapsula a comunicação com esses serviços, porém mesmo utilizando ela, muito código ficou repetido entre minhas aplicações, pelo que decidi encapsular mais um pouco e criar o contacts_rails.

Com o Contacts::Rails o único que devemos fazer é criar as rotas para algum controller:

map.import_google '/home/import/google',   :controller => "home", :action => 'import_google_contacts'
map.import_live   '/home/import/live',     :controller => "home", :action => 'import_live_contacts'
map.import_yahoo  '/home/import/yahoo',    :controller => "home", :action => 'import_yahoo_contacts'
map.import_csv    '/home/import/csv',      :controller => "home", :action => 'import_csv_contacts'

e depois incluir Contacts::Imports no mesmo:

class HomeController < ApplicationController do
  include Contacts::Imports
end

Quando um usuário acessar as diferentes rotas, ele sera redirecionado para o serviço correspondente, onde terá que se logar. Finalmente ele sera enviado para a view import com a variável @contacts contendo uma lista de contatos, onde cada contato é um array de dois items: nome e email.

Como podem ver nas rotas, também podemos importar contatos a partir de um arquivo CSV. Para isso devemos enviar no parâmetro csv_file um arquivo com a seguinte estrutura:

email, name
bob@marley.com , Bob Marley
che@guevara.com, Che Guevara
john@lennon.com ,John Lennon

A primeira linha existe porque podemos inverter a ordem das colunas, pelo que ela ajuda a identificar à que corresponde cada uma.

Atenção

Os serviços do Yahoo e do Live são bem mais burocráticos que o do Google, pelo que para utilizar eles precisaram configurar o arquivo config/contacts.yml após ter cadastrado suas aplicações:

http://developer.yahoo.com/addressbook/
http://msdn.microsoft.com/en-us/library/cc287659.aspx

Queria agradecer ao Hugo Baraúna da Plataforma, que me ajudou com a gem explicando a implementação que ele fez no seu fork do projeto contacts.

Basicamente permitem escrever código como o seguinte:

describe User do
  should_act_as_taggable_on :categories

  should_have_attached_file :logo

  should_index 'addresses.city', :as => :address
  should_have_index_attribute :priority
end

Se esses plugins ajudaram você, considera por favor também me ajudar me recomendando no Working With Rails.

A motivação

No processo de paginação, muitas vezes queremos trabalhar com as ultimas ocorrências de um modelo (comentários, posts, twitts, tickets, etc), pelo que terminamos executando algo assim:

Android.paginate(:page => params[:page], :order => 'id DESC')

O problema

O código mostrado não é ruim, mas eu me senti criando código repetitivo é decidi então criar um método que encapsulasse o processo e torne o código um pouco mais legível.

Minha primeira intenção foi adicionar um método chamado paginate_latests na classe ActiveRecord::Base, mas eu queria que o método criado pegasse o valor de params[:page] como convenção e params é uma variável que existe a nível do controller, pelo que essa não era uma opção.

Minha segunda intenção foi adicionar um método na classe ActionController::Base, de tal modo que eu tenha acesso à variável params e consiga delegar o processo para o método criado em ActionController::Base pela gem. Num primeiro momento pensei em criar um fork da gem will_paginate e adicionar esse comportamento, mas o problema com isto é que a intenção da gem é ser agnóstica, ser independente de algum framework, e meu interesse se reduzia ao Rails.

A solução

Como quando pensamos em Ruby criamos gems e quando pensamos em Rails criamos plugins, criei um plugin com o comportamento desejado, um plugin o qual chamei de will_paginate_latests. Em poucas palavras, will_paginate_latests é um plugin que nos permite executar o seguinte código em nossos controllers:

paginate_latests :androids

O código fica bem claro e a pagina não precisa ser especificada devido a que ela é automaticamente pega de params[:page].

Instalação

Para instalar o plugin basta executar na raiz do projeto Rails:

script/plugin install git://github.com/dcrec1/will_paginate_latests.git

O plugin will_paginate_latests utiliza a gem will_paginate pelo que ela devera estar instalada no sistema.

Eu estava utilizando ele numa aplicação que estou fazendo com suporte a internacionalização mas como ele não suporta tal funcionalidade ficava um pouco feio: todo o texto se encontrava em português e os botoes do campo editável em inglês. Foi por tal motivo que decidi meter a mão e terminei criando um fork do plugin, dessa vez com suporte a i18n.

O novo plugin com suporte a i18 se encontra aqui e para ser utilizado basta adicionar as mensagens nos arquivos para cada locale no formato in_place_editing.text.xxx. Segue um exemplo:

{
  :'pt-BR' => {
    ...
    :in_place_editing => {
      :text => {
        :cancel => "cancelar",
        :loading => "carregando...",
        :save => "salvar",
        :saving => "salvando..."
      }
    }
  ...
  }
}

O plugin ira procurar as mensagens para o locale I18n.locale mas caso outro seja o desejado ele pode ser especificado como parâmetro:

in_place_editor('some_input',
        :url => {:action => 'update_value'},
        :locale => 'es-PE')