The philosophy of Mongoid is to provide a familiar API to Ruby developers who have been using Active Record or Data Mapper, while leveraging the power of MongoDB’s schemaless and performant document-based design, dynamic queries, and atomic modifier operations.

Aquí les dejo la presentación, cuando tenga fotos las subo.

➜ ~ cd code
➜ code mkdir proyecto_nuevo
➜ code cd proyecto_nuevo
➜ proyecto_nuevo rvm use malev@proyecto_nuevo –rvmrc –create
Using /home/malev/.rvm/gems/ruby-1.9.2-p290 with gemset proyecto_nuevo
WARN: .rvmrc is not empty, moving aside to preserve.
➜ proyecto_nuevo rvm gemset list

gemsets for ruby-1.9.2-p290 (found in /home/malev/.rvm/gems/ruby-1.9.2-p290)
global
mobilenews
=> proyecto_nuevo
webui

➜ proyecto_nuevo

Es decir, voy a mi directorio donde guardo mis proyectos / experimentos, creo un directorio, creo un nuevo gemset y listo! Todas las gems que instale en ese gemset van a estar aisladas del resto.
Lo interesante es que gracias a la magia de rvm, cada vez que entre en el directorio de mi proyecto nuevo, rvm me va a cambiar al gemset ahí usado:

➜ code pwd
/home/malev/code
➜ code rvm gemset list

gemsets for ruby-1.9.2-p290 (found in /home/malev/.rvm/gems/ruby-1.9.2-p290)
=> global
mobilenews
proyecto_nuevo
webui

➜ code cd proyecto_nuevo
=========================================================
= NOTICE =
=========================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands. =
= =
= Examine the contents of this file carefully to be sure the contents are =
= safe before trusting it! ( Choose v[iew] below to view the contents ) =
=========================================================
Do you wish to trust this .rvmrc file? (/home/malev/code/proyecto_nuevo/.rvmrc)
y[es], n[o], v[iew], c[ancel]> yes
➜ proyecto_nuevo rvm gemset list

gemsets for ruby-1.9.2-p290 (found in /home/malev/.rvm/gems/ruby-1.9.2-p290)
global
mobilenews
=> proyecto_nuevo
webui

➜ proyecto_nuevo

Si no tienes rvm instalado, corred e instaladlo por favor!

class UsersController < ApplicationController
  def create
    @user = User.new(params[:user])
    @account = Account.create :user => @user
  end
end

Sin embargo, estaríamos contaminando nuestro controller con lógica de modelo. Una primera aproximación, podría ser, usar un callback: after_create. Se ejecuta siempre que se crea un objeto y se lo guarda en la base por primera vez:

class User < ActiveRecord::Base
  #...
  def after_create
    Account.create :user => self
  end
  #...
end

Esta aproximación funciona y está buena, pero tiene algunos problemillas: el nombre del método no describe lo que hace y si tenemos que hacer varias cosas, tendríamos un método gigante. Aquí entran en acción el método de clase: after_create:

class User < ActiveRecord::Base
  #...
  after_create :create_account
 
  def create_account
    Account.create :user => self
  end
  #...
end

Una vez creado el objeto, ActiveRecord buscará un método llamado “create_account” y lo ejecutará. Esto nos permite tener varios métodos que se ejecuten como callbacks, he inclusive podemos llamarlos de manera secuencial:

class Snippet < ActiveRecord::Base
  after_create :test1
  after_create :test2
 
  def test1
    puts "test 1"
  end
 
  def test2
    puts "test 2"
  end
end

ruby-1.9.2-p136 :002 > s = Snippet.new
 => #<Snippet id: nil, content: nil, user_id: nil, created_at: nil, updated_at: nil, language_id: nil, public_sha: nil, private_sha: nil, private: false> 
ruby-1.9.2-p136 :003 > s.save
test 1
test 2
 => true 
ruby-1.9.2-p136 :004 >

Por supuesto, after_create no es el único callback. Hay mucha información al respecto aquí. Aquí solo voy a listar los callbacks disponibles:
Creando un objeto
before_validation
after_validation
before_save
before_create
around_create
after_create
after_save

Actualizando un objeto
before_validation
after_validation
before_save
before_update
around_update
after_update
after_save

Eliminando un objeto
before_destroy
after_destroy
around_destroy

Su uso es ampliamente recomendable y una cosa a tener en cuenta es… no podemos evitarlos! No son como las validaciones, en las que a veces podemos no ejecutarlas. Aquí si alguna vez necesitamos saltearlos algún callback, vamos a tener que repensar la lógica del modelo de vuelta. Usar con responsabilidad.

Yo mientras voy a seguir investigando del tema, si encuentro algo más, prometo publicarlo.

Nota: ninguna foto es mía, las robe de muchos sitios, espero nadie se enoje.