Trabe ya no escribe aquí. Puedes encontrarnos en nuestra publicación en Medium: medium.com/trabe.

4Trabes Historias de una empresa en 100 metros cuadrados

El blog de Trabe Soluciones

Rails 3.1: algunas impresiones y un temazo

| | Comentarios

Durante este verano hemos estado desarrollando una aplicación con Rails 3.1 para uno de nuestros clientes.

La nueva versión de Rails (y aquí me refiero a Rails 3.x) es un melocotonazo de miedo.


A nivel interno, las “tripas” de Rails han cambiado para mucho mejor y a nivel externo las mejoras se dejan notar en todas las partes del framework. En concreto, tras la experiencia de estos pasados meses, nosotros nos quedamos con esto:

Lo bueno

Bundler

Rails 3 y Bundler se integran tan bien que pensar en cómo desarrollábamos antes, cuando no había Gemfile, me da escalofríos. Con Bundler, la gestión de dependencias es chicle para cualquiera :).

Routing

El nuevo DSL para la definición de las rutas de la aplicación es mucho más directo y sencillo de utilizar. En concreto, la sintaxis controlador#acción, que permite decir cosas como:

1
 match 'login' => 'sessions#new'

ActiveRecord Query Interface

El API para consultas del “nuevo” ActiveRecord (básicamente, Arel) simplifica muchísimo el trabajo a la hora de escribir y utilizar los modelos de la aplicación. Cambiamos los hashes con miles de parámetros por el encadenamiento de métodos (y esto nos permite refactorizar el código de acceso a datos de una manera mucho más natural, ¡claro!).

ActiveModel

Gracias al esfuerzo de modularización llevado a cabo en Rails 3, extender el framework con nuestro propio código (y hacerlo sin recurrir a trucos oscuros) es casi trivial. En el caso de ActiveModel, proporciona mecanismos para disponer de todas las ventajas de los modelos Rails en nuestras clases: validación, internacionalización, callbacks, integración con los helpers de generación de formularios, etc.

Asset Pipeline

La joya de la corona de la versión 3.1. Como en el caso de ActiveRecord y Arel, aquí los cambios se pueden resumir en la adopción de Sprockets para la gestión de los assets de la aplicación. Además, el asset pipeline ha llegado acompañado de una decisión polémica: apostar por CoffeeScript como solución “por defecto” para escribir Javascript (sin escribirlo, claro); y de otra no tan polémica: Sass para escribir CSS.

En general, la impresión es muy positiva: CoffeeScript es mucho más compacto que Javascript y es realmente sencillo de usar (aunque creo que es muy interesante tener un background más o menos amplio en cuanto a Javascript, principalmente cuando llega el momento de depurar el código generado :P). No es un cambio que me parezca fundamental y escribir Javascript no me parece “peor”… pero el hecho es que hemos utilizado CoffeeScript :D

Sass (o LESS), por contra, no ofrece discusión. Escribir CSSs “a pelo” es tan desesperante que la mínima mejora es bienvenida. Y en el caso de este tipo de “extensiones” a las CSS, las mejoras son tantas y de tanto calado (reglas anidadas, mixin de estilos, variables, operadores, funciones, bucles, etc.) que uno lo tiene claro: jamás volveré a escribir CSSs “a pelo” si puedo evitarlo.

jQuery

Adiós Prototype, hola jQuery. Arrastrados por las anteriores versiones de Rails, siempre habíamos sido más “prototyperos”. Y ahora, arrastrados de nuevo por Rails, estamos reconvirtiéndonos y adaptándonos a jQuery. Y la verdad es que la experiencia, dejando a un lado los primeros — y tambaleantes — pasos, ha sido muy positiva. Es posible que se deba a haber adquirido un mayor y más profundo conocimiento del lenguaje (Javascript, me refiero) y no sea solo cuestión del cambio de framework, pero la sensación que me queda es que el “estilo jQuery” está más directamente ligado al Javascript que el “estilo Prototype”. Lo dicho, impresiones mías.

ActiveSupport

Hay mucho más en ActiveSupport, pero sólo voy a mencionar una cosa. Ahora se puede decir:

1
2
1.in? [1, 2, 3] #=> true
4.in? [1, 2, 3] #=> false

Y esto hacía falta :D

Lo no tan bueno

El asset pipeline, con todas sus ventajas, también trae de la mano algunos inconvenientes:

  • A la hora de desplegar en producción hay que ser especialmente cuidadoso con la configuración y con las referencias interassets (por ejemplo, las imágenes en las hojas de estilos). Hay nuevos helpers para ayudar con esto, así que no es para tanto.
  • En desarrollo todo funciona un poco más lento por la necesidad de compilar los coffeescripts y los scss. No es una barbaridad, pero a veces se nota.

Y poco más en este apartado :D

En resumen

Lo dicho: un melocotonazo de miedo.


Lo sentimos, pero los comentarios están cerrados

Buen resumen, a ver si te animas a publicar más, la siguiente con el Morito Juan ;)

bien explicado, especialmente para los que no hemos empezado con rails 3 todavia!

gracias por el articulo.

salu2,

20/Nov/2011 Ruben