martes, septiembre 28, 2010

Heroku y MongoHQ con Mongoid en Rails3

He tenido la necesidad de mostrarle en linea a un cliente un prototipo de una aplicación Rails3 que usa MongoDB como base de datos, para mi la opción por excelencia para estos prototipos es usar Heroku, un hosting de aplicaciones en la nube para Rails muy fácil de usar.

Lo interesante de Heroku es que tiene cuentas gratuitas - aunque con ciertas limitaciones -, que son perfectas para mi propósito. (En la primera reunión de @tijuanarb, @bitfon platico sobre Heroku).

Pero Heroku no tiene soporte directo para bases de datos MongoDB, aunque si ofrece un addon para integrarse con MongoHQ, servicio también en la nube para este tipo de base de datos, y al igual que Heroku, también tiene cuentas gratuitas, excelente también para prototipos. (También en la primera reunión de @tijuanarb, @fcastellanos hablo sobre MongoDB)

Hasta aqui todo bien, mi detalle vino al revisar la documentación de Heroku de como configurar la conexión a MongoHQ, ya que se requiere de una variable ambiente MONGOHQ_URL donde se coloca una URL que MongoHQ proporciona para cada base de datos, la forma de agregar esta variable en nuestra aplicación de Heroku es la siguiente:

$ heroku config:add MONGOHQ_URL="mongodb://mi-url-de-la-db-que-me-dio-mongohq"

Nota: a comentario de @fcastellanos, a la url de MongoHQ ha que agregarle el usuario y clave que tiene acceso a la base de datos, ejemplo:

$ heroku config:add MONGOHQ_URL="mongodb://[usuario]:[password]@[url_mongohq]"

Mi detalle viene a partir de que la documentación de Heroku no indica ningún paso adicional para configurar MongoID, la libreria de Ruby que mi aplicación usa para comunicarse con una base de datos MongoDB, sin embargo si hay pasos adicionales para otras librerías similares.

Así que asumí que todo estaba bien, me conecto a la aplicación y me indica un error, al revisar el log veo que no encuentra la base de datos, por lo tanto al parecer MongoID no estaba haciendo uso de la variable de ambiente MONGOHQ_URL.

Revisando el archivo config/mongoid.yml donde se configura la base de datos veo que espera obtener los valores de varias variables de ambiente:

host:

port:

username:

password:

database:

Así que lo que procedí a hacer es cargar esas variables al momento de iniciar mi aplicación para esto modifique el archivo config/applicacion.rb y justo a partir de la segunda linea y antes de los "require" agregue el siguiente código:

# MongoHQ Setup

require 'uri'

if ENV["MONGOHQ_URL"]

mongo_uri = URI.parse(ENV["MONGOHQ_URL"])

ENV["MONGOID_HOST"] = mongo_uri.host

ENV["MONGOID_PORT"] = mongo_uri.port.to_s

ENV["MONGOID_USERNAME"] = mongo_uri.user

ENV["MONGOID_PASSWORD"] = mongo_uri.password

ENV["MONGOID_DATABASE"] = mongo_uri.path.gsub("/", "")

end

Después de esto, volví a lanzar mi aplicación y ahí estaba finalmente funcionando, por fin Heroku y MongoHQ estaban trabajando juntos.


domingo, septiembre 26, 2010

Manos, un framework ligero para aplicaciones web en .NET/Mono

Hace unos días platicando con @fcastellanos, me hizo notar un nuevo framework para el desarrollo de aplicaciones web para .NET/Mono, el framework es Manos.

Manos esta siendo desarrollado por el hacker de Mono Jackson Harper, quien comenta en su manifesto que le gusta desarrollar aplicaciones web y le gusta el lenguaje C#, pero no le gusta ASP.NET, cree que ASP.NET en general hace que las cosas sencillas sean muy complicadas y por eso decidió crear Manos y dejar a ASP.NET fuera de la ecuación.

Los objetivos de Manos es ser un framework:

  • Escalable y de alto rendimiento
  • Con un sistema "pipes" que permita conectarse y extender cualquier punto de la solicitud HTTP
  • Un sistema de rutas facil y simple, por medio de concordancia de texto y expresiones regulares
  • Auto conversion de parámetros en la ruta o post
  • Que funcione con HTML5 por omisión
  • Un sistema de plantillas basado en HTML
  • Linea de comando simple para la creación de aplicaciones, construcción y "hosteo" de aplicaciones, sin necesidad de IDEs
  • Basado en la reutilizacion de componentes, modular y facil de probar.
Si estuviese leyendo estos puntos y no sabría que se esta hablando de C# y .NET, pensaría que me están describiendo Rack y muy probablemente la combinación con Sinatra, pero no es así.

Estuve viendo los ejemplos y no puedo evitar pensar en términos de Rack/Sinatra, por ejemplo:

$ manos -init myapp # Crea un directorio con mi aplicación con jquery, algunos css y el modulo .cs

En nuestro modulo podremos escribir nuestra aplicación "Hola mundo" tan fácil como:

Get ("/", ctx => ctx.Response.Write("Hola mundo!"));

Lo compilamos, por ejemplo con Mono:

$ gmcs -target:library -out:myapp.dll myapp.cc StaticContectModule.cs

Y finalmente dentro del directorio ejecutamos

$ manos -server

Navegamos a localhost:8080 y nuestra aplicación debe de responder.

Increíblemente sencillo y facil, en el sitio de Github hay un ejemplo mas elaborado, junto con 2 tutoriales sobre Manos, tutorial1 y tutorial2.

Por cierto Manos es Open Source con licencia MIT X11, bastante permisiva.


jueves, septiembre 23, 2010

Reunion del grupo tijuana.rb

El dia de ayer miércoles, se llevo a cabo la 1ra reunion de grupo de usuario de ruby/rails tijuana.rb, en la cual Sergio Lopez (@bitfon) habló sobre Heroku y el flujo de trabajo para publicar aplicaciones en ruby en la nube y Fernando Castellanos (@fcastellanos) sobre mongodb y como usarla en Rails.

El lugar fue la parte exterior del Starbucks Lucerna en zona rio, y tengo que admitirlo llego mucha mas gente de la esperada, en un punto éramos alrededor de 15 o poco mas, y aunque las condiciones del lugar no fueron las optimas - no nos alcanzo el espacio donde estábamos -, creo que estuvo bastante bien para la primera reunión. Así que para la siguiente reunión vamos a tratar de tener un lugar adecuado.

Ambas platicas interesantes y con muchas preguntas por parte de los asistentes.

En la reunion tambien nos acompañaron Jed Sundwall (@jedsundwall), Edward O'Connor (@hober) y Patrick Crowley (@mokolabs) del grupo de @SDRuby y SANDPYT - San Diego Phyton -. Y aunque solo uno de ellos hablaba español participaron de manera activa; y trajeron algunos regalos para rifar con los asistentes.

De lo interesante de que ellos nos acompañaran, es que tuve la oportunidad de platicar con Patrick, y salió la posibilidad de realizar eventos en conjunto, ya sea aqui en Tijuana o San Diego, lo cual es de lo mas interesante. De entrada ya veremos la posibilidad de realizar un "carpool" para asistir a la próxima reunión de @SDRuby.

Gracias a los que asistieron y esperamos verlos el siguiente mes, con mejores condiciones de espacio y gracias a @bitfon y @fcastellanos por su participación.








miércoles, septiembre 22, 2010

Calcular fechas laborables con Ruby

Hoy me encontré con este post llamado "Calculate Business Days using LINQ" donde explican como usar C# y LINQ para de un rango de fechas obtener solo las fechas que son laborables, es decir excluir las fechas que caigan en sábado y domingo.

El código se muestra a continuación donde se haca primero una llamada al método GetAllDates y se le pasa una fecha inicial y otra final, después con Where de LINQ se evalúa cada fecha un método que regresa falso o verdadero si la fecha cae en fin de semana o no, obteniendo al fina un arreglo con las fechas laborables.


Después de revisarlo, me pregunte, que tan complicado es hacer lo mismo en Ruby. Después de unos minutos me di cuenta que es ridículamente simple hacer lo mismo que LINQ y C# en solo 1 linea de código.

A mi metodo wroking_days se le pasa una fecha inicial y una fecha final y como resultado tenemos una arreglo de fechas excluyendo las que caen en fin de semana.




lunes, septiembre 20, 2010

La complejidad de Ruby On Rails

A raíz de mi post anterior y algunos comentarios expresados en él acerca de la complejidad para tener una aplicación de Ruby On Rails funcionando con MongoDB, he decidido escribir este post, el cual lo voy a tratar desde la vista de un ex(o casi)-desarrollador de .NET y aunque quizás algunos de mis comentarios parezcan un ataque a un .NET, no es esa mi intención, así que por favor tomenlos relajados. Ni tampoco es mi intención decir cual es mejor o cual es peor, ese es un ejercicio que cada quien forma personal debe de realizar

Comencé a desarrollar en .NET desde las versiones beta del mismo, ya hace mas de 10 años, e inclusive desarrolle para Web desde antes, ya sea con código escrito en C a modo de cgi-bin o Perl, al igual me toco desarrollar para Web en Visual Basic 4 - 6. En esos tiempos era realmente algo complejo hacer paginas dinámicas y era muy sencillo tomar decisiones incorrectas y hacer que el desarrollo se complicara enormemente.

Con la llegada de .NET Microsoft proponía otro paradigma un tanto diferente de como desarrollar a Web, proponía hacerlo tal y como se escribían aplicaciones de escritorio, solo haciendo "drag and drop", "right click", configurar aqui y alla y listo, tener aplicaciones sin - o casi sin - escribir una linea de código, digo cuantas veces no hemos visto a empleados de Microsoft haciendo este tipo de demos en eventos de la empresa.

Desde mi punto de vista - si desde mi punto de vista y experiencia - esto funcionada super bien para aplicaciones muy simples y predecibles, mi problema siempre venia cuando se quería hacer "algo mas" con la aplicación, la complejidad de desarrollo iba en aumento y en ocasiones se convertía en algo nada trivial. Durante ese tiempo también me toco hacer desarrollo con Java, varios frameworks para Web y Tomcat, y la experiencia no fue mejor.

Llego un punto en el cual casi casi decidí dejar de escribir aplicaciones para Web y únicamente escribir aplicaciones para escritorio, pero los clientes seguían solicitando aplicaciones Web, así que busque alternativas en .NET - PHP realmente nunca me gusto ni me gusta, quizás no tengo argumentos técnicos para decir porque, simplemente no me gusta -.

La alternativa que encontre fue MonoRail, comencé a ver los ejemplos y a entender sus dependencias, MonoRail es un framework para ASP.NET que trabaja con los patrones de MVC y ActiveRecord, inspirado por Action Pack. Al investigar que es Action Pack, descubrí Ruby On Rails, pero en ese momento le encontre un problema, tenia que aprender otro lenguaje de programación y tenia algunas semanas para entregar una aplicación Web para un cliente.

Así que me decidi por MonoRail, pero había algunos "detalles", tenia muchas dependencias, no tenia "Wizards" ni componentes o controles como se les llama en ASP.NET WebForms, en lo personal no lo vi como problema ya que en lo personal es raro que use los "Wizards" o que utilice controles de 3ros, así que para mi no había perdida ahí, aunque si me ha tocado conocer y dar cursos a desarrolladores de .NET que si no tiene un "Wizard" o no pueden poner su "Grid" súper "fancy" no son capaces de desarrollar una aplicación.

Por otro lado, si bien la configuración de un ambiente de trabajo con MonoRail requeria de un poco de trabajo y entendimiento por arriba de "Drag and Drop" y "Right click", no me pareció gran cosa y mas cuando es algo que solo haces una sola vez. MonoRail me permitió entregar varias aplicaciones de manera muy rápida, quede impresionado y eso me llevo a investigar sobre Ruby On Rails. Por cierto hace algunos días anunciaron, parte de "Roadmap" de MonoRail.

El motivo por el cual MonoRail me permitió entregar aplicaciones muy rápido fue porque no tuve que tomar decisiones, MonoRail lo hizo por mi, por ejemplo no tuve que decidir como organizar mi aplicación, no tuve que decidir como conectarme a la base de datos, todo lo decidió MonoRail, así solo tuve que enfocarme en la funcionalidad que era importante para mis clientes y ya. MonoRail al igual que Ruby on Rails es opinioted software.

Al llegar a Ruby on Rails, obviamente la primera barrera fue el lenguaje Ruby, pero es muy facil acostumbrarse a el, aunque todavia escribo código a la C#, pero creo que voy mejorando.

Para la gente acostumbrada a los IDEs hay una gran variedad de opciones a elegir, en lo personal no soy fan de las IDEs, prefiero ambientes mas ligeros y que me hagan usar la consola de comandos, por lo tanto en Windows se puede seguir esta guia y en Linux estas dos guias, puede parecer complicado, pero es algo que solo se tiene que hacer una vez, si se usa un IDE en cuestión de minutos se tiene un ambiente complete y configurado.

Es muy sencillo crear una nueva aplicación con Ruby On Rails (RoR) haciendo uso de las decisiones que el framework hace por nosotros, por ejemplo:

$ rails new mi_super_app

$ cd mi_super_app

$ rails generate scaffold client name:string, address:string

$ rails server

Dirigimos nuestro navegador a http://localhost:3000/clients y listo ya podemos comenzar a dar de alta y modificar clientes, simple, fácil y rápido.

Si bien esto funcionara tal y como esta en un gran numero de casos, la gente en RoR pensamos en la regla 80/20, hay momentos en que se tiene que hacer algo un poco diferente para configurar nuestra aplicación, donde podemos cambiar las decisiones que RoR hace por nosotros y adaptarlas al 100% de nuestras necesidades, como las modificaciones propuestas en mi post para usar MongoDB en lugar de una base de datos relacional.

Si bien la intención de mi post es servir como una guia o receta, paso a paso de como hacerlo, también podemos hacerlo sencillo con el uso de Templates - así como existen también templates en Visual Studio para crear aplicaciones con ciertas características y defaults -, en e siguiente video de Railscasts se explica el concepto. De hecho existe ya un template para pre-configurar una aplicación de RoR para usar MongoDB y Rspec, con el cual se puede omitir mi post y solo ejecutar:

$ rails new mi_super_app -JOT -m ~/path_a/mongodb_template/templater.rb

Ya viendolo así, ¿ya no se ve que sean muchos pasos no?

Sobre el tema de las dependencias, al igual que en cualquier otro framework o lenguaje podemos tener dependencias a librerías de terceros o podemos elegir no hacerlo. En el caso de Ruby y sus diferentes frameworks, hay librerías para casi todo lo que nos podamos imaginar, RubyGems es un buen lugar para descubrirlas y Bundler nos permite manejar esas dependencias de forma sencilla y a nivel aplicaciones, es decir podemos tener la misma dependencia pero hacia diferentes versiones de la librería sin conflictos, no hay "DLL Hell".

Para determinar como elegir que dependencias tener en nuestra aplicación, va en relación directa de nuestras necesidades, pero creo que puedo sumarizar algunos criterios:

  • Librerías que fueron extraídas del framework de RoR
  • Librerías mantenidas por miembros del equipo de desarrollo de RoR
  • Librerías que son tan viejas como el mismo framework de RoR y que evolucionan paralelamente
  • Librerías mantenidas por empresas de desarrollo en RoR
  • Librerías populares y que tengan pruebas

Con respecto al soporte de los librerías disponibles en Ruby, este varia, pero el común denominador es que son OSS y el código de casi todas esta disponible en Github. En experiencia personal no he tenido problemas con esto, ya que a través de los grupos, IRC, reportando bugs o correo directo he tenido solución cuando se me ha presentado algún problema, inclusive, he enviado parches que han sido aceptados y generalmente la corrección a mi problema puede llevar algunas horas en lugar de tener que esperar días si fuese un bug en una librería comercial.

De las librerías que he utilizado realmente no me ha tocado alguna que pierda el soporte, cuando el desarrollador principal se retira generalmente sale alguien a continuar trabajando en ella, lo que si me ha tocado experimentar es el reemplazo de librerías por otras mejores, por ejemplo, cuando entre a RoR restful_authentication era "la librería" para el manejo y autentificacion de usuarios, posteriormente authlogic la reemplazo y actualmente devise es la librería popular, no es que las otras tengan algo malo o funcionen mejor o peor, es solo la manera en como evolucionan las cosas.

Creo que personalmente lo que encontre en RoR es que no me tengo que pelear contra el framework para poder entregarle aplicaciones a mis clientes, todo lo contrario, me puedo olvidar un poco del framework y dedicarme a implementar la funcionalidad que le da valor a mi trabajo.

Y afortunadamente puedo decir que aquí en Tijuana no he sido el único que ha encontrado este valor, ya que desde que comencé a platicar sobre RoR varios amigos implementaron soluciones para sus empresas y clientes de estas que están en linea y en tiempo record, y traen todavía mas proyectos nuevos que están siendo desarrollados en RoR, de mi parte igualmente tengo un par de proyectos en RoR que pronto verán "la luz", proyectos para mis clientes. Al mismo tiempo se de empresas que están tomando cursos y evaluando RoR para el desarrollo de nuevas versiones de sus productos, todo esto solo en Tijuana.

Creo que después de esta explicación algunos estarán de acuerdo conmigo y otros no, a final de cuentas debemos de ser apasionados con el lenguaje/framework que elijamos para trabajar, porque para bien o para mal a estos le vamos a dedicar nuestro tiempo laboral; pero el ser apasionados también implica el ser críticos de lo que usamos y si es posible conocer y probar otras herramientas, aunque si trabajamos para una empresa "casada" con una compañía/tecnología va a ser un poco difícil cambiar su visión, ya que generalmente se usan x tecnología por cuestión política o de mercadotecnia o gusto personal de la persona que toma las decisiones.


sábado, septiembre 18, 2010

Aplicación de Rails 3 con MongoDB

En los últimos días he tenido que iniciar un par de proyectos en Ruby On Rails, donde la base de datos que se ha requerido es una base de datos no relacional, en este caso MongoDB.

La idea de este post es documentar la configuración de una nueva aplicación en Rails 3 para usar con MongoDB, donde vamos a desactivar ActiveRecord e instalar las siguientes herramientas:

  • Generadores Rails para Mongo
  • Rspec para pruebas
  • Factory Girl para fixtures
  • Haml como plantilla de vistas y jQuery.

Como paso inicial es necesario crear una nueva aplicación de Rails 3 - Se asume que ya se tiene instalado Rails 3 y MongoDB -, pero vamos a pasar las opciones -O para que no se creen archivos de ActiveRecord, -J para que no se instale la librería de javascript Prototype y -T para que no cree el fólder para Test::Unit

$ rails new mi_app -O -J -T

Después de creada la aplicación, seria buena idea inicializar un repositorio de Git.

Una vez creada nuestra aplicación hay que realizarle algunas adiciones nuestro archivo Gemfile para agregar las dependencias de nuestra aplicación:

  • mongoid y bson_ext => Mongoid es la librería que usaremos para conectarnos a la base de datos de MongoDB y bson_ext es una extensión en C para acelerar la serializacion de BSON
  • haml => Lenguaje de plantilla alternativa para vistas en Rails, desde mi punto de vista menos verbal y mas "developer friendly" que html y erb.

Dentro de un grupo llamado :development agregamos las siguientes gemas:

  • rails3-generators => varios generadores para Rails 3, lo que nos permite ejecutar rails generate
  • haml-rails => generadores de haml para Rails 3
  • jquery-rails => generadores de jquery para Rails 3

En el grupo :test agregamos:

  • rspec => framework para pruebas en Ruby
  • rspec-rails => utilerias para pruebas en RSpec para Rails
  • factory_girl_rails => utileria para la creación de modelos para pruebas
  • remarkable_mongoid => librería para pruebas de modelos de mongoid con RSpec

El archivo Gemfile debe de quedar como se muestra a continuación.



Para instalar las gemas solo ejecutamos

$ bundle install

Para conocer mas de las gemas instaladas aquí les dejo los vínculos a sus referencias

Una vez instaladas las gemas hay que realizar algunas configuraciones, lo primero es configurar mongoid para trabajar con Rails y desactivar ActiveRecord, para eso ejecutamos el comando:

$ rails generate mongoid:config

Este comando va crear el archivo config/mongoid.yml donde vamos a configurar el acceso a la base de datos de MongoDB, también va a modificar el archivo config/application.rb y va a eliminar la dependencia de ActiveRecord, la parte superior de config/application.rb deberá quedar algo similar a:

# require "active_record/railtie"

require "action_controller/railtie"

require "action_mailer/railtie"

require "active_resource/railtie"

#require "rails/test_unit/railtie"

Ya que estamos en el archivo config/application.rb vamos indicandole a Rails que en nuestra aplicación deseamos usar haml, rspec y factory_girl por omisión, para esto dentro de la declaración de la clase Application < Rails::Application, pero al final agregamos el siguiente código



A partir de este punto instalamos el soporte para jQuery y Rspec en nuestra aplicación de la siguiente forma:

$ rails generate jquery:install #--ui para activar jQuery UI

$ rails generate rspec:install

Como ultimo paso vamos configurar RSpec para que trabaje con factory_girl y remarkable, ademas de eliminar el soporte a ActiveRecord y hacer que RSpec elimine las colecciones creadas en MongoDB por nuestras pruebas antes de la ejecución de cada prueba, esto es necesario para asegurarnos que al correr cada prueba la base de datos este "limpia" y así no crear conflictos y/o dependencias en las pruebas.

Al inicio del archivo spec/spec_helper.rb hay que requerir:

require 'factory_girl'

require 'remarkable/mongoid'

Un poco mas abajo indicamos que cargue los archivos Factory de factory_girl

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

Después eliminamos el soporte a ActiveRecord comentando las siguientes lineas:

config.fixture_path = "#{::Rails.root}/spec/fixtures"

config.use_transactional_fixtures = false

Y finalmente dentro y al final del bloque de configuración de RSpec indicamos que antes de cada prueba elimine las colecciones de MongoDB

config.before :each do

Mongoid.master.collections.select {|c| c.name !~ /system/ }.each(&:drop)

end

El archivo spec/spec_helper.rb deberá quedar muy parecido a



Una vez en este punto ya podemos proceder a crear nuestra súper aplicación usando MongoDB como base de datos, si ejecutamos el generador para model, o controller o scaffold, Rails 3 generara modelos para MongoDB o vistas en haml y creara los archivos necesarios en spec para realizar pruebas con RSpec.


lunes, septiembre 13, 2010

Primera Reunion de tijuana.rb

Ven y asiste a la primera reunion del grupo de usuario Ruby/Rails de Tijuana, tijuana.rb, este proximo miércoles 22 de Septiembre en el Starbucks Lucerna de la Zona Río, a partir de las 7pm.

En esta primera reunión, Sergio Lopez (@bitfon) nos platicará sobre @heroku, un hosting para Ruby/Rails con cuentas gratuitas. Estamos a la espera de la confirmación de una plática más. Fernando Castellanos(@fcastellanos) ya se apuntó con una platica sobre como usar MongoDB con Rails.

Para los que me han preguntado sobre como iniciar con Ruby, le dejo esta liga a un post "larguísimo" que escribí con ejemplos y aunque es sobre IronRuby funciona igual con Ruby. Si alguien lo quiere ver en video aquí esta la sesión grabada en ALT.NET Hispano.

Para estar al pendiente de lo que sucede con tijuana.rb únete al Google Group o sigue a @tijuanarb en twitter.


miércoles, septiembre 01, 2010

Localización de fechas en Rails

Al estar trabajando en un sitio/aplicación para un cliente bajo el CMS RefineryCMS, cambie el idioma de CMS a español, pero las fecha seguían apareciendo en formato en Inglés, ej: September 01, en lugar de 01 de Septiembre.

Aun y cuando ya tenia instalado el archivo es-MX.yml en el directorio locale y Rails estaba localizando otros textos pero no las fechas. En el archivo yml encontramos la siguiente estructura:

date:

order: [:day, :month, :year]

abbr_day_names: [Dom, Lun, Mar, Mie, Jue, Vie, Sab]

abbr_month_names: [~, Ene, Feb, Mar, Abr, May, Jun, Jul, Ago, Sep, Oct, Nov, Dic]

day_names: [Domingo, Lunes, Martes, Miércoles, Jueves, Viernes, Sábado]

month_names: [~, Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto, Septiembre, Octubre, Noviembre, Diciembre]

formats:

short: "%d de %b"

default: "%d/%m/%Y"

long: "%A, %d de %B de %Y"

formal: "%d de %B"

time:

formats:

short: "%d de %b a las %H:%M hrs"

default: "%a, %d de %b de %Y a las %H:%M:%S %Z"

long: "%A, %d de %B de %Y a las %I:%M %p"

am: "am"

pm: "pm"

En donde en Date:Formats:Formal encontramos "%d de %B, con lo que esperaria formatos de fecha 01 de Septiembre.

Resulta que con:

t (:formal, :scope => [:date, :formats])

podemos leer el formato "%d de %B del archivo de localización, pero ahora el problema es ¿como le indicamos a la fecha que formato usar?, bueno para eso usamos I18n, donde pasamos la fecha a formatear y el formato de acuerdo al idioma de la aplicación:

I18n::localize(date, :format => t (:formal, :scope => [:date, :formats]))

Ahora el único problema es que este código es bastante largo para colocarlo dentro de una vista, por lo que podemos mandarlo a un método helper de la siguiente forma:

def localize_short_date(date)

I18n::localize(date, :format => t (:formal, :scope => [:date, :formats]))

end

Con esto en nuestra vista solo llamamos:

<%= localize_short_date Date.now %>

Y nos aseguramos que la fecha es desplegada en el formato definido y localizada al idioma de la aplicación Rails.