ASCIIcasts - Full Episode Feed

Spork

Sun, 16 Oct 2011 22:21:29 +0000

Spork es una gema de Ruby que acelera la carga de los tests de nuestras aplicaciones, en este episodio investigaremos cómo podemos usar esta gema para hacer que los tests se ejecuten más rápido.

Por lo general cuando ejecutamos la suite de tests de una aplicación Rails pasan unos segundos antes de que los tests empiecen a ejecutarse. Podemos medir la duración de esta pausa con la orden time.

$ time rspec .
.........

Finished in 1.98 seconds
9 examples, 0 failures

real	0m11.090s
user	0m9.735s
sys	0m1.306s

Aunque RSpec dice que los tests le han llevado sólo unos segundos el tiempo transcurrido desde que ejecutamos rspec y su finalización es mucho mayor, unos 11 segundos. El tiempo extra es el tiempo que se tarda en cargar el código de la aplicación Rails y, como puede verse, este tiempo puede ser incluso mayor que el tiempo de ejecución de los tests. Spork viene a resolver este problema.

Instalación

Spork se instala como cualquier otra gema, aunque como sólo se utiliza en el entorno de tests lo añadiremos al grupo test del Gemfile. Como lo estamos instalando para una aplicación Rails 3 tenemos que instalar la versión de pre-lanzamiento que es la 0.9.0.rc.

/Gemfile

gem "rspec-rails", :group => [:test, :development]
group :test do
  gem "factory_girl_rails"43675-19804-85759-03545-08577
  gem "capybara"
  gem "guard-rspec"
  gem "spork", "> 0.9.0.rc"
end

Como siempre, tras cambiar el Gemfile tenemos que ejecutar bundle para que se instalen todas las gemas y sus dependencias.

Lo siguiente que tenemos que hacer es lanzar la orden bootstrap de Spork para preparar el fichero spec_helper.

$ spork --bootstrap
Using RSpec
Bootstrapping /Users/eifion/auth/spec/spec_helper.rb.
Done. Edit /Users/eifion/auth/spec/spec_helper.rb now with your favorite text editor and follow the instructions.

Como puede verse, Spork ha detectado que estamos usando RSpec y ha modificado el fichero spec_helper. Echémosle un vistazo a los cambios que ha hecho.

/spec/spec_helper.rb

require 'spork'

Spork.prefork do
  # Loading more in this block will cause your tests to run faster. However,
  # if you change any configuration or code from libraries loaded here, you'll
  # need to restart spork for it take effect.

end

Spork.each_run do
  # This code will be run each time you run your specs.

end

Spork ha añadido dos métodos en el fichero spec_helper, cada uno de los cuales recibe un bloque. El primero es prefork, que se ejecuta cuando arranca el servidor de Spork. El otro, llamado each_run se ejecuta cada vez que ejecutamos la suite de tests. La idea es quitar todo el código que se pueda de spec_helper para pasarlo a prefork de forma que sólo se ejecute una vez. Moveremos todo el código de este archivo y veremos si los tests siguen pasando.

/spec/spec_helper.rb

require 'rubygems'
require 'spork'

Spork.prefork do
  # This file is copied to spec/ when you run 'rails generate ↵
  rspec:install'
  ENV["RAILS_ENV"] ||= 'test'
  require File.expand_path("../../config/environment", __FILE__)
  require 'rspec/rails'
  require 'capybara/rspec'

  # Requires supporting ruby files with custom matchers and ↵
    macros, etc,
  # in spec/support/ and its subdirectories.
  Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| ↵
    require f}

  RSpec.configure do |config|
    config.mock_with :rspec
    config.use_transactional_fixtures = true
    config.include(MailerMacros)
    config.before(:each) { reset_email }
  end
end

Spork.each_run do
  # This code will be run each time you run your specs.
end

Podemos usar la orden spork para arrancar su servidor.

$ spork
Using RSpec
Preloading Rails environment
Loading Spork.prefork block...
Spork is ready and listening on 8989!

Cuando el servidor arranca ejecuta el código del método prefork de forma que este código sólo se ejecuta una vez. Ahora podemos lanzar otra ventana de terminal y ejecutar nuestra suite de tests. Tenemos que ejecutar los tests mediante el servidor Spork, lo que se hace utilizando la opción --drb.

Cuando Spork ejecuta los tests, la suite tarda menos en terminar, lo que podemos comprobar ejecutándolo con la orden time otra vez. Esta mejora de velocidad se irá haciendo más notable según vaya creciendo nuestra aplicación.

$ time rspec . --drb
.........

Finished in 2.21 seconds
9 examples, 0 failures

real	0m4.125s
user	0m0.342s
sys	0m0.097s

Spork es muy útil porque carga todo el entorno de la aplicación una única vez y luego va ejecutando los tests tantas veces como queramos sin tener que volver a recargar la aplicación cada vez.

Uso de Guard con Spork

Guard es una gema que lanza la suite de tests de una aplicación cada vez que se hacen cambios en el código. La vimos en el episodio 264 [verlo, leerlo]. Guard se puede utilizar con Spork mediante una gema llamada guard-spork que se instala igual que Spork añadiéndola al grupo <ode>test</ode> del Gemfile y ejecutando bundle.

/Gemfile

gem "rspec-rails", :group => [:test, :development]
group :test do
  gem "factory_girl_rails"
  gem "capybara"
  gem "guard-rspec"
  gem "spork", "> 0.9.0.rc"
  gem "guard-spork"
end

Tras la instalación de la gema tenemos que ejecutar guard init spork para añadir Spork al Guardfile. Si luego inspeccionamos el Guardfile veremos la sección correspondiente a Spork bajo las configuraciones de RSpec.

/Guardfile

guard 'spork', :cucumber_env => { 'RAILS_ENV' => 'test' }, :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.+\.rb$})
  watch(%r{^config/initializers/.+\.rb$})
  watch('spec/spec_helper.rb')
end

Tenemos que poner esta sobre la de RSpec porque se tiene que ejecutar antes que el resto de guardas relacionadas con los tests. También tenemos que modificar la guarda de RSpec para añadir la opción :cli con el valor --drb. Con esto haremos que los tests se ejecuten contra el servidor de Spork. Lo mismo tendremos que hacer con el resto de guardas que tengamos para, por ejemplo, Cucumber.

guard 'rspec', :version => 2, :cli => '--drb' do
  # (se omite el contenido)
end

Con esto ya no tenemos que lanzar el servidor de Spork por separado. Cuando arranquemos Guard, éste lanzará automáticamente Spork en segundo plano y ejecutará la suite de tests cuando cambiemos cualquiera de los ficheros Ruby de nuestra aplicación.

$ guard
Please install rb-fsevent gem for Mac OSX FSEvents support
Using polling (Please help us to support your system better than that.)
Please install growl_notify or growl gem for Mac OS X notification support and add it to your Gemfile
Guard is now watching at '/Users/eifion/auth'
Starting Spork for RSpec 
Using RSpec
Preloading Rails environment
Loading Spork.prefork block...
Spork is ready and listening on 8989!
Spork server for RSpec successfully started
Guard::RSpec is running, with RSpec 2!
Running all specs
Running tests with args ["--color", "--format", "progress", "--format", "Guard::RSpec::Formatter::NotificationRSpec", "--out", "/dev/null", "--require", "/Users/eifion/.rvm/gems/ruby-1.9.2-p180@rails31/gems/guard-rspec-0.4.5/lib/guard/rspec/formatters/notification_rspec.rb", "spec"]...
.........

Finished in 4.29 seconds
9 examples, 0 failures
Done.

Esto es mucho más fácil que tener que gestionar Spork por separado. Cada vez que se cambie uno de los ficheros de nuestra aplicación se ejecutarán los tests relevantes aproximadamente un segundo después.

Configuración de Spork

Veamos ahora cómo configurar Spork. A veces cuando cambiamos un fichero en nuestra aplicación Spork no refleja el cambio, lo que implica que tendremos que reinicarlo. Esto ocurre porque el fichero se carga en el bloque prefork pero no se recarga en each_run y es algo que pasa con frecuencia si usamos Factory Girl. Las factorías se cargan en prefork por lo que los cambios que hagamos no surtirán efecto cuando se vuelva a lanzar la suite de tets. Como queremos que estos cambios ocurran automáticamente tenemos que recargar las factorías en each_run. Las versiones más recientes de Factory Girl tienen un método reload que nos pone las cosas muy fáciles:

/spec/spec_helper.rb

Spork.each_run do
  FactoryGirl.reload
end

Ahora los cambios que hagamos en las factorías surtirán efecto cada vez que se ejecuten los tests.

Puede ocurrir un problema parecido con los ficheros que se encuentren en /spec/support. De nuevo, estos archivos se cargan dentro del bloque prefork, por lo que no se cogerán cuando se vuelva a ejecutar la suite de tests. Podríamos mover el código de carga a each_run pero cuanto más código pongamos en este método más tardarán los tests en empezar a pasar. Sería mejor poder mantener el código en el bloque preload y recargar Spork automáticamente cada vez que se modifiquen los archivos en /spec/support.

Para esto nos puede servir guard-spork. El Guardfile contiene un listado de patrones de archivo en el bloque spork que define los ficheros a vigilar. Aquí podemos añadir el directorio spec/support para que se reinicie el servidor Spork cada vez que se produzca un cambio.

/Guardfile

guard 'spork', :cucumber_env => { 'RAILS_ENV' => ↵
  'test' }, :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.+\.rb$})
  watch(%r{^config/initializers/.+\.rb$})
  watch('spec/spec_helper.rb')
  watch(%r{^spec/support/.+\.rb$})
end

Con esto los cambios en spec/support serán detectados por Guard, que reiniciará Spork.

Ya que estamos mirando el fichero Guardfile veamos un truco para utilizar con suites de tests lentas. Si los tests tardan más de un minuto en pasar seguramente no querremos ejecutarlos con tanta frecuencia, por lo que hay dos argumentos a rspec guard que nos pueden ser de ayuda: all_on_start y all_after_pass. Podemos hacer que los dos sean false.

/Guardfile

guard 'rspec', :version => 2, :cli => '--drb', ↵
  :all_on_start => false, :all_after_pass => false do
  
# watch commands omitted.
end

Con estas opciones Guard no ejecutará todos los tests cuando pase un test que antes fallaba, lo que nos da más control sobre cuándo se ejecutan todos los tests. Para lanzar todos los tests podemos pulsar la tecla de retorno en el terminal de Guard (si utilizamos la última versión).

Otro truco que no tiene que ver con Spork pero que resulta útil cuando tenemos una suite de tests grande es añadir tres líneas en el bloque de configuración de RSpec (las tres líneas del final).

/spec/spec_helper.rb

RSpec.configure do |config|
  config.mock_with :rspec
  config.use_transactional_fixtures = true
  config.include(MailerMacros)
  config.before(:each) { reset_email }
    
  config.treat_symbols_as_metadata_keys_with_true_values = true
  config.filter_run :focus => true
  config.run_all_when_everything_filtered = true
end

Si ahora añadimos la etiqueta :focus en una especificación, sólo se ejecutará dicho tests en lugar de todos. Por ejemplo si añadimos :focus en un tests del modelo User:

/spec/models/user_spec.rb

require 'spec_helper'

describe User do
  describe "#send_password_reset" do
    let(:user) { Factory(:user) }

    it "generates a unique password_reset_token each time", ↵
      :focus do
      user.send_password_reset
      last_token = user.password_reset_token
      user.send_password_reset
      user.password_reset_token.should_not eq(last_token)
    end

	# Other specs omitted.
  end
end

Cuando guardemos este archivo, Guard detectará los cambios pero como se usa la etiqueta :focus sólo se ejecutará la especificación anterior.

Running: spec/models/user_spec.rb
Running tests with args ...
Run filtered including {:focus=>true}
.

Finished in 1.93 seconds
1 example, 0 failures
Done.

Hay otros casos en los que hay un fragmento de código que se ejecuta en el bloque prefork y no hay una manera sencilla de moverlo a each_run. Spork proporciona el método trap_method para controlar estos escnarios. Este método hace que el método atrapado no se ejecute inmediatamente y lo lanza después de lanzar el proceso. Esto es útil en algunos casos como con Mongoid o Devise, los cuales cargan cosas en el bloque prefork que realmente no queremos que se carguen ahí. Esto se explica en detalle en el wiki de Spork.

Con esto concluimos este episodio dedicado a Spork, que es una herramienta muy cómoda para acelerar el proceso TDD y que escala muy bien con proyectos Rails grandes si se combina con los trucos que hemos visto.

Active Admin

Sun, 16 Oct 2011 22:18:41 +0000

Vamos a dedicar este episodio a Active Admin, que es una gema con la que podemos añadir fácilmente una interfaz de administración a nuestras aplicaciones Rails. La interfaz que se genera tiene un aspecto cuidado y muy personalizable. Se puede ver en acción entrando en la demo en vivo.

En este episodio vamos a integrar Active Admin sobre una aplicación Rails ya existente. La aplicación con la que trabajaremos es una aplicación muy sencilla de comercio electrónico que tiene varios productos, cada uno de ellos con su precio y categoría. Utilizaremos ActiveAdmin para crear una interfaz de administración que permita gestionar nuestros productos.

Instalación de Active Admin

Active Admin es una gema que se instala, como es habitual, añadiendo una referencia en el Gemfile y ejecutando a continuación bundle. La aplicación es una aplicación Rails 3.1 por lo que debemos asegurarnos de incluir la gema sass-rails porque Active Admin depende de ella. En Rails 3.0 no nos haría falta incluirla.

/Gemfile

gem 'activeadmin'

Una vez que Bundler ha terminado, para añadir Active Admin tenemos que ejecutar un generador en nuestra aplicación. Este generador además nos dará instrucciones adicionales que podremos configurar después. Tenemos que añadir la opción host a la configuración del correo en el entorno de desarrollo y asegurarnos de que tenemos una URL raíz y mostramos los mensajes notice y alert en el layout de la aplicación.

$ rails g active_admin:install
      invoke  devise
    generate    devise:install
      create    config/initializers/devise.rb
      create    config/locales/devise.en.yml
  
==================================================================

Some setup you must do manually if you haven't yet:

  1. Setup default url options for your specific environment. Here is an example of development environment:

       config.action_mailer.default_url_options = { :host => 'localhost:3000' }

     This is a required Rails configuration. In production it must be the actual host of your application

  2. Ensure you have defined root_url to *something* in your config/routes.rb.
     For example:

       root :to => "home#index"

  3. Ensure you have flash messages in app/views/layouts/application.html.erb. For example:

       <p class="notice"><%= notice %></p>
       <p class="alert"><%= alert %></p>

Nosotros ya tenemos todo esto en nuestra aplicación por lo que podemos continuar.

La orden también crea alguna migraciones que tenemos que ejecutar.

$ rake db:migrate

Uso de Active Admin

En la documentación de Active Admin se indica que durante la migración inicial se creará un usuario con el nombre admin@example.com y la clave password. Podemos iniciar la sesión con estos credenciales (por supuesto estos valores se pueden modificar editando el fichero de migración devise_create_admin_users.rb antes de lanzar las migraciones) Visitando http://localhost:3000/admin con el servidor Rails en marcha veremos un formulario de inicio de sesión donde podemos introducir dichas credenciales.

Tras el inicio de sesión seremos llevados al cuadro de mandos de Active Admin, donde no encontraremos mucho que ver.

Como queremos gestionar nuestros productos añadiremos el recurso Product a Active Admin ejecutando la orden:

$ rails g active_admin:resource product
      create  app/admin/products.rb

Este generador crea un fichero llamado products.rb bajo el directorio app/admin de la aplicación. Si refrescamos el cuadro de mandos de la aplicación ahora veremos un enlace con el texto “Products” y si hacemos clic iremos a una página que tiene todo lo necesario para gestionar los productos.

En la página hay opciones para ordenar o filtrar el listado de productos por cualquier atributo. Active Admin detectará incluso las relaciones belongs_to con Category e implementará un menú desplegable para poder filtrar los productos por dicha categoría. Esto también ocurre cuando creamos un nuevo producto y se muestra un desplegable para escoger la categoría. El resto de atributos tendrán campos de entrada acordes con su tipo de datos.

Esta funcionalidad es fácil de modificar. Empecemos personalizando el índice de productos quitando columnas. Para ello modificaremos el fichero /app/admin/products.rb anteriormente generado. Podemos cambiar el listado principal redefiniendo el método index. Este método recibe un bloque dentro del cual podemos especificar las columnas que deseamos ver en la página invocando a column.

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column :released_at
    column :price
  end
end

Si recargamos la página de productos veremos que ahora muestra sólo las columnas que queremos.

Obsérvese que la asociación con Category ha sido detectada automáticamente y junto a cada producto se muestra la categoría correcta.

Podemos ir más lejos y cambiar el título de la columna pasando el título como primer argumento. Cambiaremos de esta forma el campo released_at.

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price
  end
end

Si queremos cambiar los valores de una columna podemos hacerlo pasando un bloque a column. El campo de precio no muestra un símbolo monetario, pero podemos cambiarlo para que lo haga. El método column puede recibir un bloque, en cuyo caso se le pasaría la instancia (en este caso un Product) y se mostraría en la columna lo que devuelva el bloque. Aquí tenemos acceso a los métodos helper por lo que podemos utilizar number_to_currency para mostrar correctamente el precio.

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price do |product|
      number_to_currency product.price, :unit => "&pound;"
    end
  end
end

Si recargamos la página veremos el título modificado y el precio correcto para cada producto.

Pero si personalizamos el valor devuelto para el campo price entonces ya no podemos ordenar por dicho campo, y tampoco tenemos enlaces de edición y borrado para cada elemento. Esto lo tenemos que corregir, siempre que usemos un bloque para personalizar un valor también debemos usar la opción :sortable para que Active Admin sepa cómo ordenar la columna. Añadiremos también default_actions para que vuelvan a aparecer los enlaces de edición y borrado.

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      number_to_currency product.price, :unit => "&pound;"
    end
    default_actions
  end
end

En el campo de precio ahora se muestra el símbolo monetario pero sería mejor poder alinear los valores a la derecha. Esto lo podemos hacer con CSS, pero para eso tenemos que poder identificar la columna. Active Admin proporciona una manera de generar HTML muy similar a Markaby, tan sólo tenemos que llamar un método con el nombre de la etiqueta que deseamos generar. Podemos pasar la opción :class para que la etiqueta tenga algo que podamos controlar desde CSS.

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      div :class => "price" do
        number_to_currency product.price, :unit => "&pound;"
      end
    end
    default_actions
  end
end

Ya podemos dar estilos a esta columna modificando el fichero active_admin.css.scss.

/app/assets/stylesheets/active_admin.css.scss

// Active Admin CSS Styles
@import "active_admin/mixins";
@import "active_admin/base";

// To customize the Active Admin interfaces, add your
// styles here:
.price {
  text-align :right;
}

Y la columna con precios se alineará correctamente.

Ámbitos

Otra interesante funcionalidad de Active Admin son los ámbitos, que se comportan como filtros predefinidos. Para crear estos ámbitos hay que seguir dos pasos. Primero añadimos una llamada a scope en el fichero de configuración de nuestros productos, pasándoles el nombre de un ámbito.

/app/admin/products.rb

ActiveAdmin.register Product do
  scope :unreleased
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      div :class => "price" do
        number_to_currency product.price, :unit => "&pound;"
      end
    end
    default_actions
  end
end

Y luego necesitamos escribir dicho ámbito en el modelo correspondiente:

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  scope :unreleased, where(:released_at => nil)
end

Si ahora volvemos a cargar la página de administración de productos veremos listado el ámbito. Si hacemos clic en él veremos un listado de productos filtrado por dicho ámbito.

Personalización del cuadro de mandos

A continuación veremos cómo personalizar el cuadro de mandos. Por defecto aparece vacío, así que mostraremos un listado de los productos más recientes, lo que haremos modificando el fichero /app/admin/dashboards.rb. En los comentarios del archivo se documentan las posibilidades de las que disponemos.

Para añadir una sección al cuadro de mandos se utiliza el método section. Queremos enumerar los productos más recientes en una tabla, lo que podemos hacer con table_for. En el bloque podemos definir qué columnas queremos mostrar con column de la misma forma que hicimos cuando personalizamos el índice de productos. También añadiremos un enlace a la página que muestra todos los productos.

/app/admin/dashboards.rb

ActiveAdmin::Dashboards.build do
  section "Recent Products" do
    table_for Product.order("released_at desc").limit(5) do
      column :name
      column :released_at
    end
    strong { link_to "View All Products", admin_products_path }
  end
end

Si ahora recargamos el panel de control veremos los cinco productos más recientes, así como el enlace.

La página sería más útil si cada producto del listado enlazase a la página de administración de dicho producto. Esto lo podemos hacer pasándole un bloque al método column, igual que hicimos con la columna price anteriormente.

/app/admin/dashboards.rb

ActiveAdmin::Dashboards.build do
  section "Recent Products" do
    table_for Product.order("released_at desc").limit(5) do
      column :name do |product|
        link_to product.title, admin_product_path(product)
      end
      column :released_at
    end
    strong { link_to "View All Products", admin_products_path }
  end
end

Hay una forma más breve de definir una ruta en link_to. En lugar de utilizar admin_product_path(product) podemos pasar un array con un símbolo como primer elemento y el producto como el segundo:

link_to product.title, [:admin, product]

Si recargamos el cuadro de mandos veremos el título de cada producto como un enlace que nos llevará a la página correspondiente de administración de dicho producto.

Ajustes en las hojas de estilo

Hay un problema que debemos tener en cuenta cuando utilizamos Active Admin en Rails 3.1, que podemos ver volviendo al sitio principal.

La página no tiene el aspecto que tenía antes porque ahora se incluye en todas las páginas la hoja de estilos de Active Admin. Rails 3.1 incluye todas las hojas de estilos por defecto, debido a la presencia de la línea con require_tree . en el fichero de manifiesto de application.css. Como esto no es lo que queremos (y además siempre es buena idea hacerlo para tener más control sobre los estilos de nuestras aplicación) vamos a cambiar require_tree . por require products.

/app/assets/stylesheets/application.css

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require products 
*/

/* Se omite el resto del archivo */

Una solución todavía mejor es pasarnos a la orden import de SASS. Podemos hacer que el fichero CSS de nuestra aplicación sea SASS añadiendo la extensión .scss a su nombre. Luego podemos quitar el manifiesto de la parte superior y añadir al final la orden import:

/app/assets/stylesheets/application.css.scss

/* (Se omiten los estilos)*/

@import "products";

Si recargamos la página principal sólo se incluyen las páginas de estilos correspondientes y la página tiene el aspecto correcto.

Configuración global

Hay otro archivo para configurar Active Admin en el directorio /config/initializers donde hay bastantes opciones de configuración que aparecen comentadas. Una que no lo está es el fichero con el título del sitio, que cambiaremos.

/config/initializers/active_admin.rb

ActiveAdmin.setup do |config|

  # == Site Title
  #
  # Set the title that is displayed on the main layout
  # for each of the active admin pages.
  #
  config.site_title = "Eifion's Store"

  # (Se omiten otras opciones de configuración)
end

Para que estos cambios surtan efecto debemos reiniciar el servidor, tras hacerlo aparecerá el título correcto.

Con esto terminamos este episodio. Hay muchas más cosas que se pueden adaptar en Active Admin y que no hemos repasado hoy, merece la pena ver la documentación para ver qué más cosas podemos hacer. Podemos modificar el aspecto y la funcionalidad de todas las páginas de Active Admin para adaptarlas a nuestras necesidades, por lo que es una solución muy poderosa para añadir la funcionalidad de administración en nuestras aplicaciones Rails.

Autenticación usando Sorcery

Sun, 16 Oct 2011 22:16:54 +0000

En el episodio 250 [verlo, leerlo] implementamos un esquema de autenticación en una aplicación Rails partiendo de cero. Si preferimos utilizar una solución ya construida hay varias gemas disponibles, en este episodio veremos una llamada Sorcery.

Sorcery es una solución muy sencilla. Tan sólo ofrece unos veinte métodos que se bastan para proporcionar todas las funciones de autenticación necesarias. A pesar de su simplicidad, es una solución completa y modular de forma que podemos activar sólo las partes que deseemos, por ejemplo la recuperación de contraseñas, registro de actividad, etc. Sorcery funciona a un nivel más bajo que otras gemas de autenticación dejando de nuestra parte la tarea de escribir las capas de vista y controlador. En este episodio lo utilizaremos para añadir autenticación a una aplicación Rails ya existente.

Empezando

La aplicación con la que vamos a trabajar es muy sencilla, tiene una página de bienvenida con un enlace a una página secreta. Dicha página puede ser vista por cualquiera pero queremos restringir el acceso sólo a los usuarios que hayan iniciado sesión. Usaremos Sorcery para implementar este tipo de autenticación.

Sorcery se distribuye como gema y se instala de la forma habitual añadiendo una referencia en el Gemfile y ejecutando a continuación bundle.

/Gemfile

gem 'sorcery'

Después de que Bundler haga su trabajo tenemos que ejecutar la siguiente orden para añadir el fichero de inicialización de Sorcery (que más adelante veremos).

$ rake sorcery:bootstrap

Lo siguiente es generar una migración con sorcery_migration. Aquí podemos escoger los módulos de Sorcery que deseamos incluir. Nosotros incluiremos la funcionalidad core que implementa una autenticación simple basada en clave y el módulo remember_me. Se puede ver un listado completo de los módulos en el README de Sorcery.

$ rails g sorcery_migration core remember_me
      create  db/migrate/20110914221626_sorcery_core.rb
      create  db/migrate/20110914221627_sorcery_remember_me.rb

Esta orden crea varios ficheros de migración (dependiendo de los módulos que hayamos escogido), si examinamos la migración sorcery_core veremos los atributos que se añaden a la tabla users.

/db/migrate/20110914221626_sorcery_core.rb

class SorceryCore < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :username,         :null => false  
      t.string :email,            :default => nil 
      t.string :crypted_password, :default => nil
      t.string :salt,             :default => nil
      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

Por defecto la migración crea un campo username, que no queremos porque ya tenemos el email, así que dejaremos esa línea comentada.

/db/migrate/20110914221626_sorcery_core.rb

class SorceryCore < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      # t.string :username,         :null => false  
      t.string :email,            :default => nil 
      t.string :crypted_password, :default => nil
      t.string :salt,             :default => nil
      t.timestamps
    end
  end
end

A continuación tenemos que configurar Sorcery para que utilice email en lugar de username. Esto se hace modificando el código de inicialización de Sorcery. En la parte superior de este archivo tenemos que especificar los módulos que queremos activar, como además de core estamos usando remember_me será este el único que tenemos que añadir.

/config/initializers/sorcery.rb

# The first thing you need to configure is which modules you need in your app.
# The default is nothing which will include only core features (password encryption, login/logout).
# Available submodules are: :user_activation, :http_basic_auth, :remember_me, 
# :reset_password, :session_timeout, :brute_force_protection, :activity_logging, :external
Rails.application.config.sorcery.submodules = [:remember_me]

# Rest of file omitted.

Hay otras muchas opciones de configuración que podemos activar, documentadas en el mismo archivo. La mayoría no tendremos que tocarlas pero una que sí que tenemos que cambiar es username_attribute_name. Activaremos esta opción y cambiaremos su valor para que sea :email dado que ese es el campo que queremos usar para identificar a los usuarios.

/config/initializers/sorcery.rb

config.user_config do |user|
  # -- core --
  user.username_attribute_name = :email                                          
	# change default username
	# attribute, for example, 
	# to use :email as the login.                                                                                                                                                                          

	# Other options omitted.
end
# This line must come after the 'user config' block.
config.user_class = "User"                                                          	
# define which model authenticates                                                                   	
# with sorcery.
end

Al final del archivo existe un valor de configuración que especifica el nombre del modelo que Sorcery utiliza para la autenticación y que por defecto es User. Como nuestra aplicación todavía no tiene un modelo para los usuarios tenemos que crearlo, pero dado que ya tenemos la migración creada con los campos que Sorcery necesita tendremos que decirle a Rails que para este nuevo modelo no genere migración.

$ rails g model user --skip-migration

Tan sólo tenemos que añadir esta línea de código para activar Sorcery en el modelo User.

/app/models/user.rb

class User < ActiveRecord::Base
  authenticates_with_sorcery!
end

Esta línea añade varios métodos al modelo User que sirven para gestionar la autenticación. Sin embargo no añade validaciones o protege ningún atributo, esta tarea nos corresponde a nosotros.

/app/models/user.rb

class User < ActiveRecord::Base
  authenticates_with_sorcery!
  
  attr_accessible :email, :password, :password_confirmation
  
  validates_confirmation_of :password
  validates_presence_of :password, :on => :create
  validates_presence_of :email
  validates_uniqueness_of :email
end

Ya podemos lanzar las migraciones para que se cree la tabla de usuarios.

$ rake db:migrate

Controladores y vistas

Ahora que hemos configurado el modelo User debemos generar algunos controladores que lo acompañen. Primero crearemos el UsersController para gestionar el proceso de alta.

$ rails g controller users new

Nos hará falta también un SessionsController para controlar los inicios de sesión.

$ rails g controller sessions new

Todo esto es muy parecido a como hicimos en el episodio 250 cuando creamos la autenticación desde cero, por lo que aquí iremos más deprisa. El controlador UsersController será bastante normal, creando un nuevo User en la acción new y creando un nuevo User a partir de los parámetros recibidos en la acción create.

/app/controllers/users_controller.rb

class UsersController < ApplicationController
  def new
    @user = User.new
  end
  
  def create
    @user = User.new(params[:user])
    if @user.save
      redirect_to root_url, :notice => "Signed up!"
    else
      render :new
    end
  end
end

No habrá sorpresas con la plantilla para new que es tan sólo un formulario para crear un usuario con campos llamados email, password y password_confirmation así como el código que muestra los errores de validación.

/app/views/users/new.html.erb

<h1>Sign Up</h1>

<%= form_for @user do |f| %>
  <% if @user.errors.any? %>
    <div class="error_messages">
      <h2>Form is invalid</h2>
      <ul>
        <% for message in @user.errors.full_messages %>
          <li><%= message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="field">
    <%= f.label :email %>
    <%= f.text_field :email %>
  </div>
  <div class="field">
    <%= f.label :password %>
    <%= f.password_field :password %>
  </div>
  <div class="field">
    <%= f.label :password_confirmation %>
    <%= f.password_field :password_confirmation %>
  </div>
  <div class="actions"><%= f.submit %></div>
<% end %>

La cosa se pone más interesante con SessionsController. También tenemos una acción new donde no hace falta añadir más código así que pasaremos directamente a la plantilla donde nos hace falta poner un formulario de inicio de sesión con los campos email y password así como un checkbox para el campo remember_me.

/app/views/sessions/new.html.erb

<h1>Log in</h1>

<%= form_tag sessions_path do %>
  <div class="field">
    <%= label_tag :email %>
    <%= text_field_tag :email, params[:email] %>
  </div>
  <div class="field">
    <%= label_tag :password %>
    <%= password_field_tag :password %>
  </div>
  <div class="field">
    <%= check_box_tag :remember_me, 1, params[:remember_me] %>
    <%= label_tag :remember_me %>
  </div>
  <div class="actions"><%= submit_tag "Log in" %></div>
<% end %>

Tenemos que escribir la acción create para procesar el formulario de inicio de sesión. Sorcery nos da un método llamado login que recibe tres parámetros: un nombre de usuario o dirección de correo, la clave introducida y el valor de la casilla remember_me. Este método realizará la autenticación y devolverá un User si es que se ha encontrado uno que coincida. Podemos comprobarlo y redirigir a la página pricipal en ese caso, y si no mostrar un mensaje de error junto con el formulario de inicio de sesión.

/app/views/controllers/sessions_controller.rb

class SessionsController < ApplicationController
  def new
  end
  
  def create
    user = login(params[:email], params[:password], ↵
      params[:remember_me])
    if user
      redirect_back_or_to root_url, :notice => "Logged in!"
    else
      flash.now.alert = "Email or password was invalid."
    end
  end
end

En lugar de utilizar redirect_to para llevar al usuario a la página principal cuando éste se autentica correctamente, utilizaremos un método de Sorcery llamado redirect_back_or_to que se comporta de forma similar a redirect_to pero con la diferencia de que si Sorcery ha guardado una URL redirigirá a esta en lugar de a la que se haya especificado en el código. Esto es muy útil porque si exigimos que el usuario inicie sesión cuando visite cierta página, Sorcery lo llevará automáticamente a esa página cuando se autentique correctamente.

Todavía nos hace falta la manera de que el usuario cierre la sesión, así que añadiremos la acción destroy al controlador. Sorcery tiene el método logout, que es todo lo que tenemos que llamar para cerrar dicha sesión. Tras esto redirigimos al usuario a la portada del sitio web.

/app/views/controllers/sessions_controller.rb

def destroy
  logout
  redirect_to root_url, :notice => "Logged out!"
end

A continuación nos iremos al fichero de rutas y ajustaremos todos los cables, cambiando las acciones que han sido generadas automáticamente y poniendo estas rutas:

/config/routes.rb

Auth::Application.routes.draw do
  get "logout" => "sessions#destroy", :as => "logout"
  get "login" => "sessions#new", :as => "login"
  get "signup" => "users#new", :as => "signup"
  resources :users
  resources :sessions
  get "secret" => "home#secret", :as => "secret"
  root :to => "home#index"
end

Con esto ya tenemos varias rutas y un par de recursos con los que podemos gestionar toda la funcionalidad relacionada con la autenticación.

Con estas nuevas páginas implementadas sólo nos falta poner los enlaces para que los usuarios puedan llegar a ellas. Los añadiremos en la página de layout para que sean visibles en toda la aplicación. Podemos usar el método current_user para ver si tenemos una sesión iniciada en cuyo caso mostraremos la dirección de correo y el enlace para salir de la sesión. Si no hay usuario mostraremos los enlaces a las páginas de alta y de inicio de sesión.

/app/views/layouts/application.html.erb

<!DOCTYPE html>
<html>
<head>
  <title>Auth Example</title>
  <%= stylesheet_link_tag    "application" %>
  <%= javascript_include_tag "application" %>
  <%= csrf_meta_tags %>
</head>
<body class="<%= params[:controller] %>">
  <div id="container">
    <div class="user_nav">
      <% if current_user %>
        Logged in as <%= current_user.email %>.
        <%= link_to "Log out", logout_path %>
      <% else %>
        <%= link_to "Sign up", signup_path %> or
        <%= link_to "Log in", login_path  %>.
      <% end %>
    </div>
    <% flash.each do |name, msg| %>
      <%= content_tag :div, msg, :id => "flash_#{name}" %>
    <% end %>
    <%= yield %>
  </div>
</body>
</html>

Con esto ya está todo listo y podemos comprobar el sitio. Si vamos a la página principal veremos los enlaces de registro y de inicio de sesión.

Si hacemos clic en “Sign up” veremos el formulario de registro donde podemos darnos de alta. Luego podemos hacer clic en “Log in” para entrar con nuestros datos de inicio de sesión.

Autorización

Ahora que tenemos la sesión iniciada ya podemos visitar la página secreta. Pero si cerramos la sesión y visitamos la página secreta veremos que seguimos pudiendo acceder a ella. Nos hace falta implementar la autorización necesaria para que la página sólo pueda ser accedida por usuarios con sesión iniciada.

La página secreta es una acción de HomeController. Para limitar el acceso a las acciones podemos utilizar un before_filter de Sorcery llamado require_login.

/app/controllers/home_controller.rb

class HomeController < ApplicationController
  before_filter :require_login, :only => :secret

  def index
  end

  def secret
  end
end

Cuando se activa este filtro Sorcery llama a su método not_authenticated, que podemos redefinir en ApplicationController para poder controlar lo que ocurre cuando falla la autorización. De momento nosotros optaremos por dirigir a la página de inicio de sesión y mostrar un mensaje de alerta.

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  protect_from_forgery
  
  private
  def not_authenticated
    redirect_to login_url, :alert => "First log in to view ↵
    this page."
  end
  
end

Si intentamos visitar la página secreta sin una sesión abierta seremos llevados a la página de inicio de sesión, mostrándose un mensaje de alerta.

Tras iniciar la sesión volveremos a la página secreta porque Sorcery recordará la página a la que estábamos tratando de acceder cuando nos llevó al inicio de sesión.

Con esto terminamos nuestro episodio sobre Sorcery. Tiene muchas más funciones que hoy no hemos visto pero que se pueden encontrar en su documentación. Puede que nos merezca la pena considerar Sorcery si buscamos una solución de autenticación que trabaje a un nivel un poco más bajo que otras gemas.

Actualización a Rails 3.1

Sun, 18 Sep 2011 21:21:42 +0000

Ya ha salido por fin Rails 3.1. Podemos leer un repaso de sus nuevas funcionalidades en las Notas de Lanzamiento en el sitio RailsGuides, algunas de las cuales ya han sido estudiadas en Railscasts y aquí mismo. En este episodio nos centraremos en el proceso de actualización de una aplicación Rails 3.0 a la versión 3.1, y a modo de ejemplo veremos cómo se ha migrado el sitio Railscasts.

Preparativos

Antes de acometer la actualización a Rails 3.1 tenemos que dar algunos pasos previos. Si el sitio no está funcionando en la última versión de Rails 3.0 (a día de hoy es la 3.0.10) tendremos que actualizarlo. Esto lo podemos hacer escribiendo la versión en el Gemfile y luego ejecutando bundle.

/Gemfile

gem "rails", "3.0.10"

Lo siguiente que haremos es pasar la batería de tests de la aplicación para comprobar que todos siguen pasando y que no aparecen mensajes de aviso de fin de soporte. Si los hubiera tendremos que corregirlos antes de continuar. En el caso del código de Railscasts no hay estos problemas así que continuaremos con la actualización.

Actualización

Ya estamos listos para empezar con la actualización, que haremos dentro de una nueva rama Git llamada rails31.

$ git checkout -b rails31

La actualización a Rails 3.1 es muy sencilla, sólo tenemos que ir al Gemfile de nuestra aplicación y cambiar la versión a la última versión de 3.1 (que ahora mismo es la 3.1.0.).

/Gemfile

gem "rails", "3.1.0"

Ahora ya podemos ejecutar bundle update para instalar la nueva versión. El próximo cambio que tenemos que hacer es en el fichero de configuración development.rb donde tenemos que quitar o comentar la siguiente línea:

/config/development.rb

# config.action_view.debug_rjs = true

Si lanzamos ahora los tests veremos que siguen pasando. Podemos incluso arrancar el servidor Rails y cargar la aplicación en el navegador.

Cambios en la aplicación para usar el conducto de estáticos

El conducto de estáticos es una de las funcionalidades más importantes en Rails 3.1 pero por ahora nuestra aplicación no lo tiene en cuenta y aloja sus imágenes en el directorio /public. Esta funcionalidad es totalmente opcional y no tiene ningún efecto hasta que la activemos por lo que si no podemos o queremos usar el conducto de estáticos no tenemos por qué quedarnos sin migrar a Rails 3.1.

Si nos interesa usar el conducto de estáticos debemos añadir las siguientes líneas al Gemfile (son las que se generarían automáticamente si empezásemos con una aplicación Rails 3.1 desde cero).

/Gemfile

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', " ~> 3.1.0"
  gem 'coffee-rails', " ~> 3.1.0"
  gem 'uglifier'
end

gem 'jquery-rails'

Este código crea un grupo assets e instala varias gemas relacionadas con los estáticos. También incluye la gema jquery-rails para que podamos usar jQuery (los que prefieran usar Prototype pueden usar prototype-rails). También tenemos que modificar /config/application.rb, quitando este código:

/config/application.rb

# If you have a Gemfile, require the gems listed there, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(:default, Rails.env) if defined?(Bundler)

Y escribiendo este otro:

/config/application.rb

if defined?(Bundler)
  # If you precompile assets before deploying to production, 
    use this line
  Bundler.require *Rails.groups(:assets => %w(development test))
  # If you want your assets lazily compiled in production, 
    use this line
  # Bundler.require(:default, :assets, Rails.env)
end

El código añade el grupo assets a los grupos sobre los que Bundler hará un require. Aquí se efectúa también la activación propiamente dicha del conducto de estáticos, dentro de la clase Application:

/config/application.rb

# Enable the asset pipeline
config.assets.enabled = true

# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'

Este código activa el conducto de estáticos y genera un número de versión, que podremos cambiar para expirar los recursos estáticos.

Debemos cambiar también los valores de configuración en el fichero de configuración de cada entorno. Empecemos por development.rb. Tenemos que hacer aquí un par de cambios para permitir la depuración:

/config/environments/development.rb

  # Do not compress assets
  config.assets.compress = false
  
  # Expands the lines which load the assets
  config.assets.debug = true

El siguiente es production.rb.

/config/environments/production.rb

# Compress JavaScript and CSS
config.assets.compress = true
   
# Don't fallback to assets pipeline
config.assets.compile = false
   
# Generate digests for assets URLs
config.assets.digest = true

En producción nos interesa comprimir los estáticos, pero como éstos irán precompilados pondremos compile a false. También estableceremos digest a true para que las URLs lleven su propia huella. Estas opciones se pueden configurar de forma diferente para adaptarse al funcionamiento de nuestra aplicación en producción.

Por último modificaremos el entorno de pruebas. Aquí añadiremos opciones de forma que los recursos estáticos se sirvan y guarden en caché:

/config/environments/test.rb

# Configure static asset server for tests with Cache-Control for performance
config.serve_static_assets = true
config.static_cache_control = "public, max-age=3600"

# Allow pass debug_assets=true as a query parameter to load pages with unpackaged assets
config.assets.allow_debugging = true

Si utilizamos Git para llevar el control de versiones en nuestra aplicación deberíamos modificar el fichero .gitignore y añadir el directorio .sass-cache al listado de elementos ignorados porque no nos interesará guardar en Git la caché de SASS.

/.gitignore

.sass-cache/

Cambio de sitio de los estáticos

Ahora que ya tenemos el conducto listo, debemos crear el directorio app/assets para mover allí los directorios images, javascripts y stylesheets que teníamos en /public.

$ mkdir app/assets
$ mv public/images/ app/assets/
$ mv public/javascripts/ app/assets/
$ mv public/stylesheets/ app/assets/

Algunos de estos archivos ya no hacen falta, como por ejemplo los ficheros jquery.js, jquery.min.js y rails.js del directorio javascripts que ahora vienen incluidos en la gema jQuery así que los borraremos. También es un buen momento para decididr si queremos mover los plugins de jQuery a lib/assets o vendor/assets, como hicimos en el episodio 279 [verlo, leerlo].

A continuación debemos crear los manifiestos. La aplicación ya tiene su application.js y application.css en los directorios necesarios, así que no los tenemos que crear. Empezaremos con el fichero CSS. Para convertirlo en un manifiesto tenemos que añadir algunos comentarios en la parte superior para indicarle a Sprockets los ficheros que debe incluir. Nosotros le diremos que incluya el resto del fichero y el resto de archivos que residan en el directorio stylesheets y sus subdirectorios.

/app/assets/stylesheets/application.css

/*
*= require_self
*= require_tree .
*/

/* rest of file omitted */

Podemos hacer lo mismo en el fichero application.js, pero para incluir jQuery tenemos que hacerlo de forma un poco diferente:

/app/assets/javascripts/application.js

//= require jquery
//= require jquery_ujs
//= require_self
//= require_tree .

/* rest of file omitted */

De nuevo haremos require_self porque el propio fichero contendrá su código y también require_tree para incluir el resto de los ficheros del directorio.

También tenemos que ir al fichero layout y cambiar las líneas que incluyen las hojas de estilo y los ficheros de JavaScript de forma que sólo hagan referencia al fichero relevante, porque los otros los incluirá el manifiesto.

/app/views/layouts/application.html.erb

<%= stylesheet_link_tag "application" %>
<%= javascript_include_tag "application", "http://cdn.sublimevideo.net/js/3s7oes9q.js" %>

Nuestro JavaScript necesita incluir un fichero externo que no se encontrará en el conducto de estáticos por lo que debemos seguir incluyéndolo en la primera línea.

Ya podemos probar la aplicación en el navegador para ver si nuestros cambios funcionan, pero antes debemos ejecutar bundle para instalar todas las gemas necesarias. Tras esto podemos arrancar el servidor.

$ rails s

Funciona casi todo pero quedan algunas imágenes rotas, por ejemplo el logo en la parte superior.

El problema es que la URL de la imagen ha sido escrita a fuego en el fichero de layout.

/app/views/layouts/application.html.erb

<img src="/images/railscasts_logo.png" width="423" height="56" alt="RailsCasts = Ruby on Rails Screencasts"/>

Esto no funciona porque las imágenes de nuestra aplicación ya no se alojan en /public/images. La solución más sencilla sería cambiar la URL por /assets/railscasts_logo.png pero tendremos problemas en producción. Si tenemos la opción assets.digest se añadirá una huella al final del nombre de forma que no nos bastará con tener una referencia estática a este fichero. Deberíamos siempre utilizar los métodos helper para enlazar correctamente la imagen en desarrollo y producción:

/app/views/layouts/application.html.erb

<%= image_tag("railscasts_logo.png", :size => "423x56", :alt => "RailsCasts - Ruby on Rails Screencasts") %>

Tenemos que buscar globalmente en nuestra aplicación y cambiar todos los estáticos que estén referenciados a mano para pasar a usar los helpers de Rails como con la imagen anterior. Si ahora recargamos la página y vemos el logo esto querrá decir que el conducto de estáticos funciona correctamente.

Con esto hemos terminado la actualización a Rails 3.1 de nuestra aplicación. Hay otras funcionalidades extra de las que nos podemos aprovechar y que se pueden consultar en el resto de episodios dedicados a Rails 3.1 por si nos fueran de utilidad en nuestras aplicaciones.

Foreman

Sun, 18 Sep 2011 21:18:48 +0000

Hace poco Ryan Bates preguntó en Twitter cuál es la mejor manera de gestionar los procesos en segundo plano que necesita una aplicación Rails en desarrollo. En este episodio veremos la solución que le propusieron varios lectores: Foreman.

Por ejemplo, para la aplicación GoVsGo en desarrollo tenemos que lanzar de antemano varios procesos en segundo plano: Beanstalkd, un proceso script/worker y un servidor Faye. Tenemos que arrancar todo esto cada vez que queramos usar la aplicación en desarrollo, así que sería mucho mejor si hubiera una forma más sencilla de gestionar todos estos procesos. Aquí es donde interviene Foreman.

Foreman: instalación y uso

Foreman se instala como es habitual con el resto de gemas.

$ gem install foreman

Foreman lee los procesos que tiene que gestionar a partir de un fichero llamado Procfile en el directorio de la aplicación Rails, por lo que primero tenemos que crearlo. Cada proceso se define mediante un nombre y dos puntos, así como la ruta del proceso que queremos ejecutar, por lo que para nuestros tres procesos haremos lo siguiente:

/Procfile

beanstalk:  beanstalkd
worker:     ./script/worker
faye:       rackup faye.ru -s thin -E production

Una vez que hayamos escrito nuestro Procfile podemos comprobar su validez ejecutando foreman check.

$ foreman check
valid procfile detected (beanstalk, worker, faye)

Si utilizamos tabuladores en lugar de espacios para separar el nombre del ejecutable propiamente dicho veremos mensajes de aviso, lo que tendremos que tener en cuenta. Si el fichero es válido podemos ejecutar Foreman con la orden foreman start.

$ foreman start
20:06:35 beanstalk.1  | started with pid 23140
20:06:35 worker.1     | started with pid 23141
20:06:35 faye.1       | started with pid 23143
20:06:36 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:06:36 faye.1       | >> Maximum connections set to 1024
20:06:36 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop
20:06:38 worker.1     | [2011-08-29 20:06:38 +0100] Working 1 jobs: [ Game.move ]

Se ejecutarán cada uno de los procesos que hayamos especificado en el Procfile y su salida aparecerá en el terminal. Si escribimos CTRL+C en la ventana de terminal, se pararán todos los procesos.

Foreman dispone de una página de manual que documenta su funcionalidad y las opciones disponibles, algunas de las cuales veremos a continuación. Si sólo queremos arrancar un proceso podemos pasar su nombre directamente:

$ foreman start faye
20:35:41 faye.1       | started with pid 23322
20:35:41 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:35:41 faye.1       | >> Maximum connections set to 1024
20:35:41 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop

Si queremos arrancar múltiples copias de un proceso podemos hacerlo con -c. Por ejemplo, podemos ejecutar cuatro procesos en segundo plano de Beanstalk con foreman start -c worker=4.

$ foreman start -c worker=4
20:39:41 beanstalk.1  | started with pid 23366
20:39:41 worker.1     | started with pid 23368
20:39:41 worker.2     | started with pid 23370
20:39:41 worker.3     | started with pid 23372
20:39:41 worker.4     | started with pid 23374
20:39:41 faye.1       | started with pid 23376
20:39:42 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:39:42 faye.1       | >> Maximum connections set to 1024
20:39:42 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop
20:39:46 worker.3     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:46 worker.1     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:46 worker.2     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:47 worker.4     | [2011-08-29 20:39:47 +0100] Working 1 jobs: [ Game.move ]

Exportación de procesos

Con Foreman disponemos de una orden export que es útil para exportar el listado de procesos en formato inittab o upstart que podemos utilizar en un servidor de producción. Si ejecutamos foreman export upstart . Foreman escribirá los ficheros de configuración necesarios para upstart en el directorio actual. Si le echamos un vistazo veremos que ejecutará la orden necesaria para arrancar un servidor beanstalkd, gestionando correctamente los logs.

/govsgo-beanstalk-1.conf

start on starting govsgo-beanstalk
stop on stopping govsgo-beanstalk
respawn

exec su - govsgo -c 'cd /Users/eifion/govsgo; export PORT=5000; beanstalkd >> /var/log/govsgo/beanstalk-1.log 2>&1'

Con esto concluye nuestro episodio sobre Foreman. Ha sido un poco más breve que de costumbre, pero porque Foreman es una solución muy sencilla para un problema específico que hace bien su trabajo. Si tenemos que arrancar varios procesos para que nuestra aplicación Rails se encuentre operativa en modo de desarrollo, Foreman es una opción que merece la pena considerar.

Pry y Rails

Sun, 18 Sep 2011 21:15:49 +0000

Pry es una consola de órdenes alternativa a IRB pero con la diferencia de que incluye muchas funcionalidades extra, en este episodio veremos cómo funciona y cómo la podemos integrar en nuestras aplicaciones Rails.

Pry se instala fácilmente como gema. Instalaremos también la gema pry-doc, más adelante veremos por qué.

$ gem install pry pry-doc

Como estamos usando gemsets de RVM instalaremos Pry para que esté disponible globalmente en todos los gemsets que tengamos. Esto lo podemos hacer con las siguientes órdenes:

$ rvm gemset use global
$ gem install pry pry-doc

Tras la instalación de Pry podemos ejecutarlo con pry. Como con irb podemos ejecutar el código Ruby que queramos.

$ pry
pry(main)> 1 + 2
=> 3

Pero Pry es mucho más que una simple calculadora. Antes de adentrarnos en su funcionamiento veremos cómo se configura para trabajar con una aplicación Rails. La aplicación que utilizaremos es la conocida aplicación de blog que hemos usado en varios episodios anteriores.

blog."/>

Si ejecutamos rails c en el directorio de la aplicación se activará IRB. Para utilizar Pry sólo tenemos que ejecutar pry pasando el fichero de entorno de Rails. Cuando lo hagamos tendremos acceso a todos los modelos de nuestra aplicación igual que con una consola estándar de Rails.

$ pry -r ./config/environment
pry(main)> Article.count
=> 3

Con esto ya podemos pasar a ver las funcionalidades de Pry. Si escribimos help veremos un listado con todas las órdenes soportadas pero las dos que usaremos con más frecuencia son cd y ls. La orden cd cambia el ámbito actual, por lo que si escribimos cd Article nos moveremos a la clase Article. Podemos comprobar el ámbito en todo momento escribiendo self.

pry(main)> cd Article
pry(#<Class:0x1022f60e0>):1> self
=> Article(id: integer, name: string, content: text, created_at: datetime, updated_at: datetime, published_at: datetime)

Una vez que estamos dentro de la clase Article podemos invocar cualquiera de sus métodos, como first, que devuelve el primer artículo, igual que si escribiésemos Article.first.

pry(#<Class:0x1022f60e0>):1> first
=> #<Article id: 1, name: "What is Music", content: "Music is an art form in which the medium is sound o...", created_at: "2011-08-24 20:35:29", updated_at: "2011-08-24 20:37:22", published_at: "2011-05-13 23:00:00">

También podemos hacer cd en cualquier objeto por lo que si hacemos cd first en el ámbito Article cambiaremos al ámbito de ese artículo donde podemos llamar métodos de instancia como por ejemplo name.

pry(#<Class:0x1022f60e0>):1> cd first
pry(#<Article:0x102300c98>):2> name
=> "What is Music"

También podemos hacer cd al atributo name del artículo y trabajar con los métodos de dicha cadena.

pry(#<Article:0x102300c98>):2> cd name
pry("What is Music"):3> upcase
=> "WHAT IS MUSIC"

Pry toma nota del nivel de anidamiento en que nos encontramos.

pry("What is Music"):3> nesting
Nesting status:
--
0. main (Pry top level)
1. #<Class:0x1022f60e0>
2. #<Article:0x102300c98>
3. "What is Music"

Esta orden devuelve la lista de objetos en los que hemos entrado. Si escribimos exit volveremos al objeto anterior, en este caso el primer artículo. Y si volvemos a salir , volveremos a la clase Article.

La siguiente orden más utilizada es ls, que enumera las variables y sus métodos. Por defecto lista todas las variables del ámbito actual, por lo que si estamos en Article, veremos todos los métodos disponibles:

pry(#<Class:0x1022f60e0>):1> ls
[:_, :_pry_, :inp, :out, :@_create_callbacks, :@_defined_class_methods, :@_save_callbacks, :@_update_callbacks, :@_validate_callbacks, :@arel_engine, :@arel_table, :@attribute_methods_generated, :@cached_attributes, :@column_names, :@columns, :@columns_hash, :@finder_needs_type_condition, :@generated_attribute_methods, :@inheritable_attributes, :@inheritance_column, :@parent_name, :@quoted_primary_key, :@quoted_table_name, :@relation]

Algunas órdenes de Pry soportan modificadores, que podemos consultar ejecutando la orden con la opción -h. Si ejecutamos ls -h veremos todas las opciones soportadas, incluyendo -m que podemos usar para mostrar un listado de métodos de la clase y -M que devuelve el listado de los métodos de instancia. También podemos pasarle cualquier objeto o clase para ver sus métodos en lugar de los del ámbito actual.

Otra orden muy útil de Pry es show-doc. Supongamos que queremos saber cómo funciona el método in_groups_of de la clase Array. Podemos hacerlo con show-doc Array#in_groups_of.

pry(#<Class:0x1022f60e0>):1> show-doc Array#in_groups_of

From: /Users/eifion/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.10/lib/active_support/core_ext/array/grouping.rb @ line 19:
Number of lines: 15

signature: in_groups_of(number, fill_with=?)

Splits or iterates over the array in groups of size number,
padding any remaining slots with fill_with unless it is false.

  %w(1 2 3 4 5 6 7).in_groups_of(3) {|group| p group}
  ["1", "2", "3"]
  ["4", "5", "6"]
  ["7", nil, nil]

  %w(1 2 3).in_groups_of(2, '&nbsp;') {|group| p group}
  ["1", "2"]
  ["3", "&nbsp;"]

  %w(1 2 3).in_groups_of(2, false) {|group| p group}
  ["1", "2"]
  ["3"]

También podemos invocar show-doc directamente sobre objetos. Nuestro ámbito es la clase Article por lo que podemos invocar all para devolver el listado de artículos. Podemos invocar show-doc all.in_groups_of para recuperar la misma información que antes.

Otra orden útil es show-method, que muestra el código fuente de cualquier método. Podemos utilizarlo para ver el código fuente de in_groups_of (cabe destacar que Pry ofrece autocompletado de los métodos que vamos introduciendo con la tecla de tabulación).

pry(#<Class:0x104e63de0>):1> show-method all.in_groups_of

From: /Users/eifion/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.10/lib/active_support/core_ext/array/grouping.rb @ line 19:
Number of lines: 19

def in_groups_of(number, fill_with = nil)
  if fill_with == false
    collection = self
  else
    # size % number gives how many extra we have;
    # subtracting from number gives how many to add;
    # modulo number ensures we don't add group of just fill.
    padding = (number - size % number) % number
    collection = dup.concat([fill_with] * padding)
  end

  if block_given?
    collection.each_slice(number) { |slice| yield(slice) }
  else
    groups = []
    collection.each_slice(number) { |group| groups << group }
    groups
  end
end

Igualmente tenemos la orden edit-method. Si lo ejecutamos contra un método abrirá el fichero de texto correspondiente en un editor de texto, llevándonos a la línea adecuada.

También podemos ejecutar órdenes de la shell si vienen precedidas por un punto. Si ejecutamos .ls en Pry, éste ejecutará la orden ls de la shell y veremos los ficheros del directorio actual.

Pry resulta útil para depurar. En nuestro modelo Article tenemos el método word_count que debería devolver el número de palabras que tiene el atributo content de un artículo. Pero hay un error en dicho código porque siempre devuelve 0 independientemente del contenido que tenga el artículo. Podemos mirar el método haciendo cd al primer Article y luego invocando edit-method word_count. El método tiene el siguiente aspecto:

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments

  def word_count
    words = content.scan(/\\w+/)
    words.size
  end
end

Podemos poner un punto de ruptura en el código con binding.pry. Si lo hacemos justo antes de la línea words.size y guardamos el archivo, la próxima que ejecutemos word_count se parará en la invocación de binding.pry y nos devolverá a la interfaz de órdenes de Pry.

> word_count

From: /Users/eifion/blog/app/models/article.rb @ line 7 in Article#word_count:

     2:   attr_accessible :name, :content, :published_at
     3:   has_many :comments
     4: 
     5:   def word_count
     6:     words = content.scan(/\\w+/)
 =>  7:     binding.pry
     8:     words.size
     9:   end
    10: end

Tenemos acceso a todas las variables locales del método, por lo que podemos invocar words para ver los contenidos del array.

pry(#<Article:0x1008c3f38>):3> words
=> []

Parece que hay algo mal con la expresión regular que recupera el contenido, porque éste se encuentra vacío. Examinándola con más detalle veremos que hay dos barras invertidas donde debería haber sólo una. Para corregir esto podemos ejecutar edit-method word_count, arreglar la expresión regular, quitar la línea binding.pry y guardar el archivo.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments

  def word_count
    words = content.scan(/\w+/)
    words.size
  end
end

Podemos comprobar nuestro arreglo llamado a word_count de nuevo, y esta vez funciona como sería de esperar.

pry(#<Article:0x1008c3f38>):3> word_count
=> 55

<o>A veces querremos depurar algo en las capas de vista o controlador de la aplicación y no necesariamente por la consola. Pry puede ayudarnos, primero tenemos que poner una referencia a Pry en el Gemfile.</o>

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.10'
gem 'sqlite3'
gem 'nifty-generators'
gem 'pry', :group => :development

Luego podemos ejecutar bundle para instalar las gemas y luego rails s para arrancar el servidor, y ya podemos ir dejando llamadas a binding.pry en nuestros controladores para establecer puntos de ruptura.

/app/controllers/articles_controller.rb

def index
  @articles = Article.all
  binding.pry
end

Si abrimos dicha página con un navegador se quedará pegada durante la carga pero en el terminal veremos la interfaz de Pry que ha detenido la ejecución en el punto de ruptura, donde podemos inspeccionar los valores de las variables locales o de instancia del modelo. Una vez que hayamos terminado podemos hacer exit para que la petición finalice.

From: /Users/eifion/blog/app/controllers/articles_controller.rb @ line 4 in ArticlesController#index:

     1: class ArticlesController < ApplicationController
     2:   def index
     3:     @articles = Article.all
 =>  4:     binding.pry
     5:   end
     6: 
     7:   def show
     8:     @article = Article.find(params[:id])
     9:   end

Con esto terminamos este episodio sobre Pry. Se trata de una gema muy útil que hace mucho más que lo que hemos visto hoy. El wiki detalla mucha más información e incluye un enlace a un vídeo realizado por Joshua Cheek.

El conducto de estáticos

Sat, 10 Sep 2011 20:58:10 +0000

El conducto de estáticos (N. del T: asset pipeline en inglés) es una de las funcionalidades más importantes de Rails 3.1, pero también es de las más confusas. En este episodio vamos a tratar de aclarar cómo se usa para gestionar los estáticos de nuestras aplicaciones Rails. Los que no estén familiarizados con esto pueden empezar por la Guía Rails sobre el conducto de estáticos porque cubre muchas de sus funcionalidades.

Los que ya hayan escrito una aplicación Rails 3.1 sabrán que si visitamos http://localhost:3000/assets/application.js veremos un archivo con todo el JavaScript que utiliza nuestra aplicación. Pero, ¿cómo funciona esto?

El fichero application.js no tiene nada de especial; de hecho cualquier fichero que se ponga en el directorio /app/assets/javascripts será accesible igualmente. Por ejemplo si en dicho directorio creamos un fichero llamado greeting.txt podemos verlo con el navegador cargando la URL http://localhost:3000/assets/greeting.txt. Nótese que aunque el fichero se encuentra en el directorio /app/assets/javascripts la URL que usamos para acceder a él es /assets/greeting.txt. Esto se aplica para cualquier subdirectorio de /app/assets en el que pongamos el archivo, podemos incluso crear un nuevo directorio y ponerlo ahí, que el fichero seguirá estando accesible en la misma URL (aunque si hacemos esto tendremos que reiniciar el servidor).

El directorio /app/assets no es el único sitio donde podemos añadir este tipo de estáticos. Si creamos un directorio en /lib/assets cualquier fichero que pongamos ahí podrá ser accedido igual que si hubiese sido puesto en /app/assets, y lo mismo para todos los ficheros que cuelguen de /vendor/assets.

Si tenemos archivos estáticos que no son realmente específicos de la aplicación nos puede venir bien ponerlos o bien en /lib o en /vendor. Por ejemplo si usamos un plugin de jQuery el directorio /vendor/assets es un buen sitio para poner los ficheros JavaScript porque es otra persona quien los mantiene. Igualmente podemos poner en /lib aquellos estáticos que mantenemos nosotros pero que no son específicos de la aplicación.

Simplificando, el conducto de estáticos no es más que una lista de rutas de carga. Podemos ver dicho listado consultado en la consola Rails.application.config.assets.paths:

> y Rails.application.config.assets.paths
--- 
- /Users/eifion/store/app/assets/images
- /Users/eifion/store/app/assets/javascripts
- /Users/eifion/store/app/assets/stylesheets
- /Users/eifion/store/lib/assets/greeting.txt
- /Users/eifion/store/vendor/assets/stylesheets
- /Users/eifion/.rvm/gems/ruby-1.9.2-p180@railspre/gems/jquery-rails-1.0.13/vendor/assets/javascripts

La salida muestra todos los directorios debajo de app/assets, de /lib/assets y de /vendor/assets. Al final aparece un directorio interesante que viene de la gema jquery-rails que hemos incluido en nuestra aplicación. Podemos ver sus contenidos con la orden bundle open.

$ bundle open jquery-rails

Con esto abriremos la gema con el editor de texto definido por las variables de entorno BUNDLE_EDITOR o EDITOR. Si examinamos los ficheros de la gema veremos un directorio llamado vendor/asset/javascripts y que contiene varios ficheros de jQuery que podemos cargar a través del conducto de estáticos.

Tal y como es de esperar, podemos acceder a cualquiera de estos archivos en la ruta assets en el navegador, porque todos estos directorios se encuentran en la ruta de carga del conducto de estáticos.

Lo más interesante de esto es que las gemas de Ruby ya no sirven sólo para gestionar código Ruby, también podemos usarlas para gestionar JavaScript y otro estáticos. Probablemente veamos en un futuro más librerías de JavaScript distribuidas como gemas de Ruby de forma que puedan aprovecharse de la gestión de dependencias de Bundler.

Gestión de estáticos con Sprockets

Volvamos al fichero application.js de nuestra aplicación, y echémosle un vistazo.

/app/assets/javascripts/application.js

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery
//= require jquery_ujs
//= require_tree .

El fichero sólo contiene comentarios, pero son importantes. Este tipo de archivo se conoce como manifiesto y lo gestiona Sprockets internamente. Cuando llega una petición para este archivo, Sprockets mira el manifiesto y recopila todos los ficheros mencionados y pone sus contenidos antes del código que aparezca en este archivo.

Aquí también funcionan las rutas de carga. En este fichero tenemos require jquery (la extensión .js es opcional). Sprockets buscará en los directorios mencionados en la ruta de carga en busca de este archivo y, en este caso, lo cargará del directorio vendor/asset/javascriptsde la gema.

Se puede poner aquí cualquier fichero JavaScript que se encuentre en la ruta de carga. Así, si añadimos require jquery-ui a este archivo, se incluirá el código jquery-ui de la gema. Esto también se aplica a los ficheros de CoffeeScript, si incluimos require home se analizará e incluirá el fichero /app/assets/javascripts/home.js.

Sin embargo no hace falta incluir dicho fichero home porque al final de este archivo tenemos require_tree ., y el punto aquí quiere decir el directorio actual. Todos los ficheros JavaScript o CoffeScript que haya en este directorio y sus hijos serán automáticamente incluidos.

Podemos excluir algunos archivos si queremos. Supongamos que tenemos unas páginas de administración y sólo queremos incluir su JavaScript cuando estamos viendo una de estas págias. Por defecto estos ficheros serían incluidos para todas las páginas de nuestro sitio.

Si queremos ver qué ficheros se están incluyendo podemos añadir el parámetro debug_assets=1 a la URL, con lo que impediremos que se combinen los archivos JavaScript y si vemos el código fuente de la página veremos todos los archivos que Sprockets habría incluido, y veremos que también aparecen los del directorio admin.

Esto lo podemos soslayar de un par de formas. Por un lado podríamos utilizar require_directory en lugar de require_tree y esto incorporaría los ficheros del directorio actual, y no los del subdirectorio, y por otra parte si queremos tener más control podríamos hacer require de forma separada en lugar de incluir todo el directorio. Alternativamente podríamos mover los ficheros JavaScript a un directorio public y luego usar require_tree ./public para incluir sólo dichos archivos.

Cabe preguntarse qué comandos hay disponibles en el manifiesto de Sprocket, por desgracia no hay una fuente definitiva de documentación pero en el fichero directive_processor.rb existen comentarios que explican cómo funciona, así como las distintas órdenes que se le pueden pasar.

Preprocesado

El conducto de estáticos también puede preprocesar. Para ver cómo funciona esto crearemos un fichero llamado greeting.txt en el nuevo directorio /app/assets/anything. Podemos añadir otra extensión al nombre de archivo y especificar un procesador, por ejemplo .erb. Si ahora le añadimos código ERB a este archivo se evaluará correctamente.

/app/assets/anything/greeting.txt.erb

hello world <%= 1 + 1 %>

Si cargamos el fichero en un navegador veremos que el código ERB se ha ejecutado correctamente. Nótese que no incluimos la URL no incluye la extensión del preprocesador.

Así es como básicamente funcionan SASS y CoffeeScript. Cuando un fichero tiene la extensión .sc ésta indica que hay que preprocesarlo con SASS. Podemos encadenar este tipo de extensión y crear un fichero con la extensión, por ejemplo .scss.erb, con lo que el fichero primero pasaría por ERB y luego por SASS.

El preprocesador es muy configurable. Podemos añadir nuestros propios procesador o intercambiar los ya existentes, todo esto se controla con la gema Tilt, en cuya documentación se puede encontrar toda la información necesaria.

Diferencias en modo de producción

Con esto terminamos esta pequeña guía sobre la funcionalidad del conducto de estático, pero hay algunas diferencias de funcionamiento en producció. Primero, arrancaremos el servidor en modo de producción.

$ rails s -e production

Si visitamos la página principal de nuestra aplicación y vemos el código fuente compobaremos que los estáticos se sirven de forma diferente.

<link href="/assets/application-412fe22651f4486c51e54176003a9f57.css" media="screen" rel="stylesheet" type="text/css" />
  <script src="/assets/application-3e3a5167191afa70c7b72440eee7dd40.js" type="text/javascript"></script>

Por motivos de caché, ahora los nombres de archivo aparecen con un guión. Esto da mejor resultado que el viejo método que usa Rails 3.0 de añadir una cadena porque cambia realmente el nombre del archivo. También si vemos el contenido del fichero veremos que el JavaScript ha sido minimizado, lo que ahorra ancho de banda.

Estos estáticos se cachean automáticamente y son servidos por el middleware Rack Cache, lo que es bastante rápido. Si queremos que sea el propio servidor web quien sirva estos estáticos podemos precompilarlos lanzando

$ rake assets:precompile

Con esto se precompilarán los estáticos en el directorio /public de forma que serán accesibles desde el servidor web.

Con esto concluimos este episodio sobre el conducto de estáticos. No olvideis visitar la Guía de Rails que contiene más información.

Búsquedas con Sunspot

Sat, 10 Sep 2011 20:48:49 +0000

Con Sunspot podemos añadir búsqueda de texto completo en nuestras aplicaciones Ruby. Utiliza Solr en segundo plano y tiene muchas características interesantes. En este episodio veremos cómo usar Sunspot para añadir este tipo de búsquedas en una aplicación Rails, utilizando la sencilla aplicación de blog que hemos visto en los episodios anteriores.

En esta aplicación hay una página que muestra varios artículos y en la que queremos implementar la posibilidad de buscar texto en ellos. Esto se puede complicar considerablemente si utilizamos SQL para hacerlo, así que el mejor enfoque suele ser utilizar un motor de búsqueda de texto completo como Sunspot.

Instalación de Sunspot

Sunspot se instala como una gema de la forma habitual, añadiéndolo al Gemfile y ejecutando bundle.

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.9'
gem 'sqlite3'
gem 'nifty-generators'
gem 'sunspot_rails'

Una vez que hayamos instalado la gema y sus dependencias tenemos que generar el fichero de configuración de Sunspot, lo que podemos hacer ejecutando

$ rails g sunspot_rails:install

Esta orden crea un fichero YAML en /config/sunspot.yml. No tenemos que hacer por el momento ningún cambio en los valores configurados por defecto.

No tenemos que instalar Solr por separado porque viene incluido en la propia gema por lo que funciona tal cual, lo que hace que su uso en tiempo de desarrollo sea bastante más cómodo . Para arrancar Solr tenemos que ejecutar

$ rake sunspot:solr:start

Los que estén ejecutando OS X Lion y no hayan instalado el entorno de ejecución de Java podrán hacerlo al lanzar la orden. La orden también creará más archivos de configuración avanzada, que no veremos por el momento y cuyo funcionamiento podemos consultar en la documentación.

Uso de Sunspot

Una vez que hemos instalado Sunspot podemos utilizarlo sobre nuestro modelo Article. Para añadir la búsqueda de texto completo utilizaremos el método searchable.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :content
  end
end

Este método recibe un bloque en cuyo interior definiremos los atributos sobre los que queremos realizar las búsquedas, para que Sunspot pueda saber qué datos tiene que indexar. Podemos usar el método text para definir los atributos sobre los que se lanzarán búsquedas de texto completo. En el caso de nuestros artículos lo haremos contra los campos name y content.

Sunspot indexará automáticamente los nuevos registros, pero no los ya existentes. Podemos decirle que vuelva a generar todo el índice con

$ rake sunspot:reindex

Una vez que todos los artículos se encuentren en nuestra base de datos Solr ya podemos añadir un campo de búsqueda en la parte superior de la página.

/app/views/articles/index.html.erb

<% title "Articles" %>

<%= form_tag articles_path, :method => :get do %>
  <p>
    <%= text_field_tag :search, params[:search] %>
    <%= submit_tag "Search", :name => nil %>
<% end %>
<!-- rest of view omitted -->

Este formulario se envía a la acción index utilizando GET por lo que los parámetros aparecerán en la URL. Para realizar una búsqueda con Sunspot invocaremos a search sobre el modeloy le pasaremos un bloque, en el cual podemos invocar a varios métodos para gestionar búsquedas más complejas. Empezaremos con el método fulltext y le pasaremos los parámetros recibidos por el formulario. Por último le asignaremos los resultados a la variable @search a la cual podemos invocar el método results para recuperar los artículos.

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
  end
  @articles = @search.results
end

Ya podemos probar esto recargando la página de artículos y buscando una palabra cualquiera. Cuando lo hagamos veremos el listado de los artículos que la contienen.

La búsqueda devuelve un listado de los artículos que contienen el término de búsqueda, ya se encuentre en las columnas nombre o en su content.

Por supuesto, en el bloque searchable podemos hacer muchas más cosas. Podemos utilizar boost para ponderar los resultados, de forma que si hay una correspondencia en el título del artículo tenga más peso que si se encuentra en el contenido.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content
  end
end

Esto es muy importante si queremos ordenar los resultados por relevancia. En este caso los artículos cuyos título contengan el término de búsqueda aparecerán antes en los resultados.

Los atributos que aparezcan en el bloque searchable no tienen por qué ser columnas reales de la base de datos: podemos utilizar cualquier método definido en el modelo. Por ejemplo podemos crear una columna publish_month que devuelva una cadena conteniendo el nombre del mes y el año de publicación del artículo, y luego buscaremos sobre este atributo como si estuviese almacenado en la base de datos.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

Antes de poder hacer búsquedas sobre esta nueva columna tenemos que volver a indexar los registros ejecutando rake sunspot:reindex, y una vez que lo hagamos podemos buscar los artículos por el mes de su publicación.

Como alternativa a la creación de un método podemos pasar un bloque y realizar la búsqueda contra los resultados de dicho bloque. Por ejemplo, un artículo tiene muchos comentarios por lo que queremos tener la posibilidad de buscar en dichos comentarios.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

El contenido dentro del bloque es una instancia de Article por lo que en su interior podemos recuperar los comentarios y mapear el contenido de cada comentario. Aunque esto devuelve un array Sunspot lo gestionará e indexará todos los comentarios de forma que luego se pueda buscar sobre ellos.

Búsqueda contra atributos

¿Y si queremos añadir algún tipo de búsqueda que vaya más allá de la búsqueda de texto completo, tal vez buscar algún atributo específico? Para esto le podemos decir el tipo del atributo que queremos buscar: cadena, entero, flotante o incluso una fecha. Para que el atributo published_at sea indexable podemos utilizar el método time.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
    time :published_at
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

Podemos utilizar esto en ArticlesController para restringir las búsquedas sólo a aquellos artículos cuya fecha published_at sea anterior a la hora actual, usando el método with.

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
  end
  @articles = @search.results
end

Con esto la búsqueda ya no devolverá artículos que no hayan sido publicados todavía. Los atributos que se pueden pasar están bien documentados en el wiki de Sunspot.

Búsqueda facetada

La búsqueda facetada permite filtrar los resultados de búsqueda basándonos en ciertos atributos tales como el mes en que se publicó el artículo. Supongamos que queremos un listado de los meses en los que hay artículos publicados. Cuando hagamos clic en uno de estos enlaces se filtrará el listado de artículos de forma que sólo aparecerán los que hayan sido publicados en dicho mes.

Para esto primero tenemos que añadir un atributo string al bloque searchable de nuestro método publish_month.

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
    time :published_at
    string :publish_month
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

Podemos convertir esto en una faceta llamando a facet en el bloque search de ArticlesController.

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
    facet(:publish_month)
  end
  @articles = @search.results
end

Ya podemos listar dichas facetas en la página index con el siguiente código:

/app/views/articles/index.html.erb

<div id="facets">
  <h3>Published</h3>
  <ul>
    <% for row in @search.facet(:publish_month).rows %>
      <li>
        <% if params[:month].blank? %>
          <%= link_to row.value, :month => row.value %> (<%= row.count %>)
        <% else %>
          <strong><%= row.value %></strong> (<%= link_to "remove", :month => nil %>)
        <% end %>
      </li>
    <% end %>
  </ul>
</div>

En este código iteramos sobre los elementos de la faceta publish_month y los mostramos. Si invocamos a .facet en nuestro objeto @search y le pasamos el atributo por el que queremos filtrar la faceta (en este caso :publish_month) y luego invocamos a .rows devolverá todas las opciones de facetas para dicho atributo.

Si invocamos row.value devuelve el valor de dicho atributo, esto es “January 2011”. También podemos invocar row.count para devulver el número de artículos que coincidan con dicho valor. Si hay un parámetro month en la cadena de búsqueda mostraremos el valor así como un enlace “remove” que quitará dicho parámetros, con lo que tenemos la funcionalidad de que podemos especificar una faceta determinada y pasarla mediante el parámetro month.

Si ahora recargamos la página (tras volver a generar los índices) veremos un listado de facetas en un panel, cada una de las cuales muestra un mes y el número de artículos publicados en dicho mes. Si escogemos un mes veremos que aparece como parámetro month en la URL pero los artículos no se filtran. Para corregirlo, tenemos que añadir otra llamada a with en el controlador para que filtre por el mes si aparece como parámetro month.

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
    facet(:publish_month)
    with(:publish_month, params[:month]) ↵ 
      if params[:month].present?
  end
  @articles = @search.results
end

Cuando ahora seleccionemos un mes el listado se filtrará correctamente y sólo aparecerán los artículos publicados en dicho mes.

Si se pulsa en el enlace “remove” volveremos al listado completo. Esto funciona también en conjunción con los resultados de búsquedaasí que si buscamos una cadena de texto el listado del panel mostrará los meses con artículos en los que aparezca dicha cadena.

Las facetas son un gran complemento a las búsquedas de texto completo.

Con esto finalizamos este episodio. Sunspot permite añadir búsqueda de texto completo en nuestras aplicaciones Rails y tiene muchas funcionalidades extra que no hemos visto hoy. Para más información, se puede consultar el wiki de Sunspot.

Engines montables

Sat, 10 Sep 2011 20:38:23 +0000

Gracias al trabajo de los participantes en el Rails 3.1 Hackfest ya se encuentra disponible la quinta versión candidata de Rails 3.1, que incorpora correcciones importantes en el montaje de engines que permiten montar una aplicación Rails dentro de otra, lo que estudiaremos en este episodio.

Recordemos el plugin de Notificación de Excepciones que vimos en el Episodio 104 y que se podía añadir a una aplicación para almacenar en la base de datos todas las excepciones que ocurriesen. También proporcionaba una interfaz de usuario que permitía mostrar las excepciones. En este episodio reescribiremos dicho plugin como un engine.

Empezando

Antes de empezar a escribir nuestro engine tenemos que asegurarnos de estar con la versión candidata 5 de Rails 3.1, podemos hacerlo con

$ gem install rails --pre

Una vez que tengamos instalada la versión adecuada de Rails podemos empezar a generar nuestro engine. No tenemos por qué crearlo dentro de una aplicación Rails: de hecho, la creación de un engine es muy parecida a la creación de una aplicación Rails normal, incluyendo la generación del código porque la única diferencia es que ejecutaremos rails plugin new en lugar de rails new. Como nuestro engine gestiona excepciones, lo llamaremos uhoh. Tenemos que pasar la opción --mountable para que sea un engine que se pueda montar sobre otras aplicaciones.

$ rails plugin new uhoh --mountable

La estructura de directorios de la aplicación tiene todo el aspecto de una aplicación Rails normal y básicamente lo es, sólo que está diseñada para ser montada sobre otra aplicación por lo que hay algunas diferencias. Hay varios directorios con su propio espacio de nombres, por ejemplo el fichero application_controller vive dentro de /app/controllers/uhoh y lo mismo sucede con los ficheros debajo de assets, helpers y views Esto hace que el código del engine quede limpiamente separado del resto de la aplicación dentro de la que vivirá. Como ya existe un directorio en assets esto quiere decir que ya no tenemos que preocuparnos de copiar los recursos estáticos al directorio /public cuando montamos el engine dentro de la aplicación.

engine."/>

Los recursos estáticos también tienen su propio espacio de nombres así que cuando los enlacemos tendremos que hacerlo a través de dicho directorio. Podemos ver esto también en la carpeta de layouts, aunque parece que todavía queda algún error en la RC5 porque tenemos dos application.html.erb. Podemos borrar con tranquilidad el que está fuera de la carpeta uhoh. Si abrimos el otro veremos que las referencias a los recursos llevan todas el directorio extra uhoh. Siempre que enlacemos a imágenes u otros recursos tenemos que hacerlo a través de dicho espacio de nombres.

/app/views/layouts/uhoh/application.html.erb

<!DOCTYPE html>
<html>
<head>
  <title>Uhoh</title>
  <%= stylesheet_link_tag    "uhoh/application" %>
  <%= javascript_include_tag "uhoh/application" %>
  <%= csrf_meta_tags %>
</head>
<body>

<%= yield %>

</body>
</html>

A continuación veremos uno de los ficheros clave llamado engine.rb que se encuentra en la carpeta /lib/uhoh.

/lib/uhoh/engine.rb

module Uhoh
  class Engine < Rails::Engine
    isolate_namespace Uhoh
  end
end

Se trata de una clase que hereda de Rails::Engine y es donde ocurre toda la configuración personalizada. Ya existe una llamada a isolate_namespace en esta clase, lo que significa que el engine será considerado como su propia unidad aislada y no tendrá que preocuparse de la aplicación en la que se encuentre montado.

La parte final del engine es el directorio /test. Bajo /test/dummy hay una aplicación Rails que está ahí para que veamos cómo funciona nuestro engine cuando se monta sobre otra aplicación. El directorio config/ de dicha aplicación contiene un fichero routes.rb, con la llamada a mount en la que se pasa la clase principal del engine asignándola a una ruta.

/test/dummy/config/routes.rb

Rails.application.routes.draw do
  mount Uhoh::Engine => "/uhoh"
end

Esto es exactamente lo que cualquiera que quiera instalar el engine en una aplicación tendrá que hacer, montarla en la ruta que escoja. Se trata de una aplicación Rack por lo que si una petición llega a /uhoh será nuestra clase Engine quien la reciba. No es mala idea añadir esta línea a las instrucciones de instlación en el fichero README de la clase para que los usuarios sepan cómo montarla en el fichero de rutas de su aplicación.

La aplicación de pruebas sirve también para probar manualmente el engine, aunque se encuentre en el directorio test. Podemos ejecutar la aplicación de prueba ejecutando rails s en el directorio de nuestro engine. Y si visitamos http://localhost:3000/uhoh/ iremos al engine porque hemos cargado la URL en la que se encuentra montado. Sin embargo aparecerá un error al cargar dicha página porque no hemos escrito todavía ningún controlador.

A continuación crearemos un controlador failures. Podemos usar los generadores de Rails igual que en una aplicación normal. Aunque estamos en un engine no tenemos por qué explicitar el espacio de nombres ya que ésto se gestiona automáticamente.

$ rails g controller failures index

Esta orden genera los mismos archivos que con un controlador normal, excepto que todo se coloca automáticamente en el directorio correspondiente al espacio de nombres adecuado. A continuación modificaremos las rutas del engine para tener una ruta root a la acción index del controlador. Esto se hace en el fichero /config/routes del engine.

/config/routes.rb

Uhoh::Engine.routes.draw do
  root :to => "failures#index"
end

Si visitamos http://localhost:3000/uhoh/ veremos la vista de la acción.

En esta página queremos mostrar un listado con las excepciones que han ocurrido. Necesitamos un modelo para guardar esta información, por lo que crearemos el modelo Failure que sólo tendrá un campo para el mensaje de la excepción.

$ rails g model failure message:text

Con este modelo ya creado, ¿cómo ejecutamos las migraciones? Dentro del propio engine podemos ejecutar normalmente rake db:migrate y todo funcionará como sería de esperar. Pero cuando el engine se encuentre montado sobre otra aplicación esto no funcionará porque la tarea rake no cogerá las migraciones que se encuentren dentro de los engines. Tendremos que especificar a los usuarios de nuestro engine que deben ejecutar la tarea rake uhoh:install:migrations, que copiará las migraciones del engine junto con las de la aplicación de forma que se ejecuten cuando se lanza rake db:migrate como es habitual. Es buena idea incluir esta información en las instrucciones de instalación.

La consola de Rails también funciona como cabría esperar, por lo que la utilizaremos para crear un Failure de ejemplo.

Uhoh::Failure.create!(:message => "hello world!")

Obsérvese que tenemos que incluir el espacio de nombre siempre que hagamos referencia a una de las clases. Ahora que tenemos un registro Failure lo mostraremos en la acción index de nuestro failuresController.

/app/controllers/uhoh/failures_controller.rb

module Uhoh
  class FailuresController < ApplicationController
    def index
      @failures = Failure.all
    end
  end
end

Al contrario de cuando estamos en la consola no tenemos que especificar un espacio de nombres, porque ya estamos dentro del módulo Uhoh. En la vista escribiremos el código necesario para iterar sobre todos los errores y mostrarlos en una lista.

/app/views/uhoh/failures/index.html.erb

<h1>Failures</h1>
<ul>
  <% for failure in @failures %>
  <li><%= failure.message %></li>
  <% end %>
</ul>

Cuando recarguemos la página veremos el mensaje Failure que acabamos de añadir.

Captura de excepciones

Ya tenemos una manera de guardar los errores, ahora sólo tenemos que usarla cada vez que ocurra una excepción en la aplicación sobre la que hayamos montado nuestro engine. Para probar esto tenemos que poder simular una excepción en la aplicación de prueba, para lo que nos moveremos al directorio de la aplicación de prueba y generaremos un controlador llamado simulate con una acción failure.

$ rails g controller simulate failure

En la acción elevaremos una excepción.

/test/dummy/app/controllers/simulate_controller.rb

class SimulateController < ApplicationController
  def failure
    raise "Simulating an exception"
  end
end

Si visitamos con el navegador dicha acción veremos, como era de esperar, la excepción.

Tenemos que cambiar el engine de forma que esté pendiente de dicha excepción y cree en ese momento un nuevo registro Failure. La solución que proponemos no es especialmente eficiente pero al menos es sencilla y servirá como ejemplo. Empezaremos creando un inicializador en el engine, aunque no exista un directorio initializers en el directorio config de nuestro engine lo podemos crear. En este directorio pondremos un fichero llamado exception_handler.rb.

/app/config/initializers/exception_handler.rb

ActiveSupport::Notifications.subscribe ↵
  "process_action.action_controller" do ↵
  |name, start, finish, id, payload|
  if payload[:exception]
    name, message = *payload[:exception]
    Uhoh::Failure.create!(:message => message)
  end
end

En este fichero nos suscribimos a una notificación (vimos las notificaciones en el episodio 249 [verlo, leerlo]). Dicha notificación nos indica que se ha terminado de procesar una acción. En este momento es cuando podemos comprobar si el atributo payload contiene una excepción en cuyo caso sabemos que se ha elevado una excepción y podemos guardar el mensaje en su correspondiente Failure.

Para probarlo tenemos que reiniciar el servidor. Podemos visitar http://localhost:3000/simulate/failure para que se lance la excepción. Si luego vamos a http://localhost:3000/uhoh encontraremos que dicha excepción ha quedado registrada.

Gestión de URLs en los engines.

Los helpers de URL que se utilicen dentro de un engine generarán URLs para dicho engine. Por ejemplo si se añade un enlace a la URL raíz desde nuestra vista index, el enlace apuntará a la URL del engine, no a la de la aplicación en la que se ha montado.

/app/views/uhoh/failures/index.html.erb

<p><%= link_to "Failures", root_url %></p>

El enlace apunta a http://localhost:3000/uhoh que es la URL raíz del engine. En este caso se trata de la misma página porque la URL raíz se define en las rutas del engine como la acción index de FailuresController. Podemos crear enlaces a la aplicación propiamente dicha utilizando el prefijo main_app de la siguiente manera:

/app/views/uhoh/failures/index.html.erb

<p><%= link_to "Failures", root_url %></p>
<p><%= link_to "Simulate Failure", main_app.simulate_failure_path %></p>

Con esto tenemos un enlace a la página de simulación de excepciones, que se encuentra en http://localhost:3000/simulate/failure.

¿Y si lo que queremos es justo lo contrario, tener un enlace al engine desde la aplicación principal? Lo primero que tenemos que hacer es cambiar la línea en el fichero de rutas donde montamos el engine y darle un nombre utilizando la opción :as.

/test/dummy/config/routes.rb

Rails.application.routes.draw do

  get "simulate/failure"

  mount Uhoh::Engine => "/uhoh", :as => "uhoh_engine"
end

Tras esto podemos acceder a los helpers de URL del engine como métodos de uhoh_engine. Para demostrar esto vamos a cambiar temporalmente nuestra acción que genera excepciones para que en lugar de elevar la excepción redirija a la URL raíz del engine.

/test/dummy/app/controllers/simulate_controller.rb

class SimulateController < ApplicationController
  def failure
    redirect_to uhoh_engine.root_url
  end
end

Si ahora visitamos http://localhost:3000/simulate/failure seremos redirigidos a http://localhost:3000/uhoh porque estamos usando el helper de dicho engine para generar la URL. Esta es otra funcionalidad que cabe mencionar en el fichero README de nuestro engine.

Con todo esto ya tenemos la funcionalidad de nuestro engine prácticamente completa, pero la página que muestra los errores tiene un aspecto muy sobrio, por lo que le pondremos varios adornos. Primero añadiremos una imagen, que pondremos en el directorio /app/assets/images/uhoh, y para incluirla en la página podemos usar image_tag igual que con cualquier otra imagen.

/app/views/uhoh/failures/index.html.erb

<%= image_tag "uhoh/alert.png" %>
<h1>Failures</h1>
<ul>
  <% for failure in @failures %>
  <li><%= failure.message %></li>
  <% end %>
</ul>

<p><%= link_to "Failures", root_url %></p>
<p><%= link_to "Simulate Failure", ↵
  main_app.simulate_failure_path %></p>

Incluyamos también algo de CSS. SASS y CoffeeScript no pueden usarse por defecto en los engine pero se pueden añadir como dependencias. Si añadimos CSS al fichero failures.css éste se incluirá automáticamente.

/app/assets/stylesheets/uhoh/failures.css

html, body {
  background-color: #DDD;
  font-family: Verdana;
}

body {
  padding: 20px 200px;
}

img {
  display: block;
  margin: 0 auto;
}

a {
  color: #000;
}

ul {
  list-style: none;
  margin: 0;
  padding: 0;
}

li {
  background-color: #FFF;
  margin-bottom: 10px;
  padding: 5px 10px;
}

Lo mismo con el JavaScript. El código que incluyamos en failures.js se incluirá automáticamente.

/app/assets/javascripts/uhoh/failures.js

$(function() {
  $("li").click(function() {
    $(this).slideUp();
  });
});

Si ahora recargamos la página tendrá mucho mejor aspecto, y podemos ocultar la excepción haciendo clic en ella, con lo que sabemos que el JavaScript ha sido incorporado correctamente.

Con esto terminamos este episodio. La posibilidad de montar engines es una gran funcionalidad de Rails 3.1, que merece la pena estudiar.

Tests dependientes de la hora y peticiones web externas

Sat, 13 Aug 2011 20:34:34 +0000

En el episodio anterior vimos como seguir un proceso de desarrollo basado en tests. Esta forma de trabajo funciona bien por lo general pero hay veces en que las aplicaciones tendrán funcionalidades especialmente difíciles de probar. Veamos dos de estos escenarios en este episodio.

Tests sobre la hora actual

Recordemos que en el otro episodio creábamos un número de pruebas sobre el modelo User. Las escribimos muy deprisa así que volveremos a una de las especificaciones para inspeccionarla.

/spec/models/user.rb

it "saves the time the password reset was sent" do
  user.send_password_reset
  user.reload.password_reset_sent_at.should be_present
end

En este test se comprueba que cuando se envía un mensaje de restablecimiento de contraseña la hora de envío queda guardada en el campo password_reset_sent_at de la base de datos utilizando la función be_present de RSpec, que llama al método present? de Rails que comprueba la existencia de un objeto.

Pero este test está incompleto: comprueba que existe el valor de password_reset_sent_at pero no que tenga la hora correcta. Establecemos password_reset_sent_at a Time.zone.now en el método send_password_reset del modelo pero la especificación pasaría independientemente del valor que pusiésemos aquí. Idealmente deberíamos comprobar que el valor es correcto con algo parecido a:

/spec/models/user.rb

it "saves the time the password reset was sent" do
  user.send_password_reset
  user.reload.password_reset_sent_at.should eq(Time.zone.now)
end

Por desgracia este enfoque no funciona. La hora actual en el instante en que se ejecuta la especificación será ligeramente distinta de la hora cuando actual cuando se ejecute la línea siguiente. Ante un problema como este merece la pena preguntarse si nos compensa meter más complejidad en el test para probar un caso como este, donde parece razonable pensar que basta con comprobar la presencia del valor de tiempo dado que hay muy poca posibilidad de que se ponga la hora incorrecta en la única línea de código que lo hace. Sin embargo hay veces que nos interesa hacer pruebas sobre la hora actual así que investigaremos cómo hacerlo.

Tenemos Guard ejecutándose y podemos ver que falla la especificación. Aunque los valores de tiempo son idénticos hasta el segundo, no son exactamente iguales y esto es suficiente para hacer que falle la especificación.

Failures:

  1) User#send_password_reset saves the time the password reset was sent
     Failure/Error: user.reload.password_reset_sent_at.should eq(Time.zone.now)
       
       expected Mon, 25 Jul 2011 20:34:46 UTC +00:00
            got Mon, 25 Jul 2011 20:34:46 UTC +00:00
       
       (compared using ==)
       
       Diff:
     # ./spec/models/user_spec.rb:16:in `block (3 levels) in <top (required)>'

Finished in 1.95 seconds
9 examples, 1 failure

Para este tipo de problemas podemos usar Timecop, con la que podemosmanipular la hora actual de diferentes maneras, pudiendo incluso congelarla. Esto quiere decir que podemos congelar el tiempo durante el tiempo que se ejecuta el test de forma que el momento en que se genera el valor de tiempo será el mismo que cuando se comprueba que sea el correcto.

Timecop se incorpora en nuestra aplicación añadiéndolo al Gemfile y ejecutando bundle. Como sólo lo necesitamos para los tests lo añadiremos al grupo test.

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.1.0.rc4'

gem 'sqlite3'

# Asset template engines
gem 'sass-rails', "~> 3.1.0.rc"
gem 'coffee-script'
gem 'uglifier'

gem 'jquery-rails'

gem "rspec-rails", :group => [:test, :development]
group :test do
  gem "factory_girl_rails"
  gem "capybara"
  gem "guard-rspec"
  gem "timecop"
end

Es buena idea ir al fichero spec_helper y añadir una llamada a Timecop.return en el bloque config.before(:each) de esta forma los cambios que hagamos con Timecop dejarán de surtir efecto antes de ejecutar la siguiente especificación.

Ya podemos invocar a Timecop.freeze en cualquier de los tests y el tiempo se parará durante su ejecución. Esto significa que ya podemos comparar los instantes de tiempo:

/spec/models/user.rb

it "saves the time the password reset was sent" do
  Timecop.freeze
  user.send_password_reset
  user.reload.password_reset_sent_at.should eq(Time.zone.now)
end

Cuando Guard ejecute las especificaciones, éstas pasarán correctamente.

Existe otro escenario inesperado que puede hacer que los tests fallen. Por ejemplo si vamos a una conferencia de Ruby en una zona horaria diferente nos podemos encontrar con que de repente los tests relacionados con la fecha fallan. En lugar de recorrer medio mundo de vuelta resultará más barato establecer la zona horaria correspondiente en las especificaciones. Esto se hace estableciendo Time.zone.

Time.zone = "Paris"

Para establecer temporalmente la zona horaria dentro de un único test podemos llamar a Time.use_zone.

/spec/model/user_spec.rb

it "saves the time the password reset was sent" do
  Timecop.freeze
  user.send_password_reset
  Time.use_zone("Paris") do
    user.reload.password_reset_sent_at.should eq(Time.zone.now)
  end
end

El código dentro del bloque se ejecutará como si estuviésemos en París. Podemos aprovechar esto para comprobar que las especificaciones siguen pasando aunque estemos en una zona horaria diferente.

Siempre que escribamos tests que dependan de la hora actual deberíamos utilizar algo como Timecop para comproba que la fecha se utiliza de forma consistente y que la funcionalidad no cambia si lo hace la zona horaria de nuestro equipo o durante el horario de verano, con lo que además podemos comprobar que nuestra aplicación funcionará en todo el mundo.

Peticiones de web externas

A continuación vamos a ver cómo escribir tests que hacen peticiones a web externas. Esta sección está basada en un problema que se encontró Ryan Bates cuando reescribió la web de Railscasts, específicamente la funcionalidad de mostrar el tamaño de archivo para cada vídeo cuando se pasa el ratón sobre el enlace de descarga.

Como los archivos se encuentran alojados en un servidor externo, hay que lanzar una petición web externa para calcular su tamaño. Veamos cómo se escribieron los tests para esto utilizando el ejemplo de una pequeña aplicación. Tiene un recurso WebRequest y un formulario con un campo de texto que recibe una URL.

Cuando se introduce la URL de un video en la caja de texto y se envía el formulario, se muestra la URL así como el tamaño del archivo que como puede verse tiene cero bytes.

El tamaño de archivo es cero porque todavía no hemos implementado esta funcionalidad. Tenemos un método content_length en nuestro modelo WebRequest que está forzado para devolver siempre 0. Implementemos este método usando TDD.

/app/models/web_request.rb

class WebRequest < ActiveRecord::Base
  def content_length
    0
  end
end

Tenemos varias gemas con las que escribir tests de peticiones web externas, pero nosotros vamos a usar Fakeweb. Esta gema puede usarse para registrar una URL y definir cuál es la respuesta que se debe devolver cuando se utilice Net::HTTP para recuperar dicha URL. Por lo tanto, Net::HTTP no lanzará la petición real sino que devolverá lo que hayamos establecido.

Fakeweb se instala de la forma habitual, añadiéndolo al Gemfile y ejecutando bundle. A continuación añadiremos la configuración de Fakeweb haciendo dos cambios en el archivo spec_helper.

/spec/spec_helper.rb

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rspec'

Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

FakeWeb.allow_net_connect = false

RSpec.configure do |config|
  config.mock_with :rspec
  config.use_transactional_fixtures = true
  config.include(MailerMacros)
  config.before(:each) do
    Timecop.return
    reset_email 
    FakeWeb.clean_registry
  end
end

En la parte superior del archivo establecemos Fakeweb.allow_net_connect a false, lo que hace que las especificaciones no lancen ninguna conexión externa HTTP. Esto es útil porque quiere decir que si hemos dejado otras peticiones web en las especificaciones, éstas no ralentizaran la suite, y Fakeweb nos avisará que la especificación se está conectando a la web. En before(:each) invocamos a Fakeweb.clean_registry para que cada especificación comience en el mismo estado.

En la especificación de WebRequest escribiremos un test que comprueba que se recupera el tamaño del contenido.

/spec/models/web_request_spec.rb

require 'spec_helper'

describe WebRequest do
  it "fetches the content length" do
    FakeWeb.register_uri(:head, "http://example.com", :content_length => 123)
    WebRequest.new(:url => "http://example.com").content_length.should eq(123)
  end
end

Llamamos a Fakeweb.register_uri para registrar nuestra URL falsa. El primer argumento del método recibe el tipo de petición que queremos hacer. Del archivo nos interesa recuperar su tamaño a partir de la información del encabezado HTTP, por lo que usamos :head. Los otros argumentos son la URL y cualquier otra cabecera que queramos, en este caso sólo Content Length. Luego creamos un nuevo objeto WebRequest de nuestra aplicación que por dentro invocará esta URL y comprobamos que el valor devuelto por el método content_length es igual al valor establecido en la cabecera.

Por supuesto, cuando la ejecutamos esta especificación falla porque nuestro método content_length siempre devuelve 0. Para que pase tenemos que modificar el método para que devuelta el verdadero valor de tamaño del contenido requerido.

/app/models/web_request.rb

class WebRequest < ActiveRecord::Base
  def content_length
    uri = URI.parse(url)
    response = Net::HTTP.start(uri.host, uri.port) { |http| http.request_head(uri.path) }
    response["content-length"].to_i
  end
end

Ahora el método invoca a Net::HTTP.start utilizando la URL recibida en el modelo. El bloque luego recibe llamadas a request_head para obtener las cabeceras de la URL solicitada. Por último devuelve el valor de la cabecera content-length.

Por defecto Rails no incluye Net::HTTP así que tenemos que hacer un require en nuestra aplicación. Lo haremos en el fichero application.rb.

/config/auth.rb

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

require 'net/http'
require 'rails/all'
# resto del archivo

Con esto pasarán todos nuestros tests y si volvemos a cargar la página de nuestra petición web se mostrará el tamaño correcto.

Fakeweb es una solución muy buena para gestionar peticiones a web externas en nuestros tests.