Sobre Raíles

Solución de problemas extraños con rake gems:install

2009-07-23T00:00:00+02:00

Aprovechando mis vacaciones me encuentro con el siguiente problema. Tengo un proyecto al que afanosamente estoy añadiendo las dependencias de las gemas que utiliza en ''config/environment.rb'', pero me topo con que para instalar una gema usando ''rake gems:install''... ¡la tarea de Rake aborta diciendo que no puede instalar la gema que precisamente pretendo que instale!

Algo así en ''config/environment.rb''

gem.install 'wadus-gem', :lib => 'wadus_gem', :version => '1.0.0'

produce:

Missing these required gems:
  wadus-gem

You're running:
  ruby 1.8.6.110 at /opt/local/bin/ruby
  rubygems 1.3.5 at /Users/juan/.gem/ruby/1.8, /opt/local/lib/ruby/gems/1.8

Tras algo de investigación resulta que tenía una tarea de Rake que requería explícitamente ''config/environment.rb'' antes de que la tarea ''gems:install'' pudiese instalar ninguna gema, lo que provocaba el error (se trata de un proyecto que ha sido migrado a Rails 2.3.2, de forma que no es precisamente nuevo).

Simplemente bastó eliminar dicha linea

require File.join(File.dirname(__FILE__) + "/../../config", 'environment')

y la tarea ''rake gems:install'' vuelve a funcionar correctamente.

Arreglando MSIE con un middleware de Rails

2009-06-30T00:00:00+02:00

En otro de los alardes de simpatía de Internet Explorer, el otro día nos topamos con este conocido problema Explorer

El comportamiento de Explorer a la hora de establecer la cabecera HTTP_ACCEPT: la primera vez que carga una URL pondrá la muy extraña cabecera

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, 
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*

mientras que las posteriores peticiones llevaran un escueto */*. Por qué tiene MSIE 6 la costumbre de solicitar tantos tipos de contenido MIME pero no un básico text/html se me escapa (y más aún por qué en posteriores peticiones cambia la cabecera) pero seguro que hay una razón perfectamente justificada para ello.

En todo caso esta curiosa manía de MSIE puede hacer que se rompan cosas en Rails. En concreto, una aplicación con un controlador de esta guisa devolverá el contenido incorrecto a MSIE:

def index
  respond_to do |format|
   format.xml { ... }
   format.html { ... }
  end
end

dado que Rails no recibe explícitamente la petición de devolver HTML, asumirá que la petición se satisface correctamente devolviendo XML y por tanto Internet Explorer recibirá nuestra vista XML cuando el usuario simplemente quería cargar una URL.

Por supuesto, la solución trivial es reescribir el código

def index
  respond_to do |format|
   format.html { ... }
   format.xml { ... }
  end
end

pero esto no siempre es tan fácil: en nuestro caso, estábamos usando el excelente plugin inherited_resources de José Valim, y la búsqueda no era trivial (aunque desde luego al final se encontró y resolvió de esta manera)

Pero me quedé con la duda de si no sería posible blindarse contra este tipo de escenarios...

Los middlewares al rescate

Como contaba el otro día los middlewares nos permiten manipular el entorno de una petición HTTP y su respuesta justo antes de inyectársela a Rails. Así que parecen un candidato ideal para lo que queríamos hacer, a saber: dada una petición HTTP, detectar si el navegador que la envía es MSIE y, si en la cabecera HTTP_ACCEPT aparece el contenido MIME */* la manipularemos para insertar justo antes text/html

Veamos cómo. En primer lugar, crearemos nuestro middleware en, por ejemplo, lib/fix_msie_accept_header.rb

class FixMSIEAcceptHeader
  def initialize(app, logger = nil)
    @app = app
  end

  def call(env)
    if is_msie?(env) && !has_format?(env)
        env['HTTP_ACCEPT'] = 'text/html ,' + env['HTTP_ACCEPT']
    end

    status, headers, response = @app.call(env)

    [status, headers, response ]
  end

  def is_msie?(env)
    env['HTTP_USER_AGENT'] =~ /MSIE/
  end

  def has_format?(env)
    !(env['HTTP_ACCEPT'].include?("*/*"))
  end
end

¡ya está! Ahora solamente tenemos que decirle a Rails que cargue nuestro middleware, por ejemplo en config/environment.rb

Rails::Initializer.run do |config|
  # Settings in config/environments/* take precedence over those specified here.
  # Application configuration should go into files in config/initializers
  # -- all .rb files in that directory are automatically loaded.

  # Add additional load paths for your own custom dirs
  # config.load_paths += %W( #{RAILS_ROOT}/extras )

  config.middleware.use "FixMSIEAcceptHeader"
  ...
end

Podemos comprobar que está todo listo ejecutando rake middleware en el raíz de nuestra aplicación:

use Rack::Lock
use ActionController::Failsafe
use ActionController::Reloader
use ActionController::Session::CookieStore, #<Proc:0x01af6a08@(eval):8>
use ActionController::RewindableInput
use ActionController::ParamsParser
use Rack::MethodOverride
use Rack::Head
use FixMSIEAcceptHeader
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
run ActionController::Dispatcher.new

como se ve, en la versión 2.3 mucha de la funcionalidad clásica de Rails se encuentra ahora implementada como middlewares (por ejemplo el primero es el mutex global que impide la ejecución concurrente del framework) Estos middlewares forman una cadena por la cual va pasando la petición HTTP hacia el framework y por la que volverá la respuesta, dando la oportunidad para que cada middleware haga su labor. Tenemos la posibilidad de configurar nuestros middlwares en la posición que más nos convenga.

Logs de trazas en middlewares de Rack en Rails

2009-06-18T00:00:00+02:00

Los middlewares de Rack son probablemente una de las características más excitantes de las añadidas recientemente a Rails dado que permiten alterar dramáticamente todo el entorno de la petición y respuesta HTTP en forma de plugin de quita y pon.

Sin embargo cuando estamos desarrollando alguno de estos monstruitos nos topamos con que dentro de un middleware no tenemos acceso al logger de Rails, con lo cual es difícil poner trazas. Aunque existen middlewares pensados para trazar logs en el formato de Apache, lo cual no siempre nos da la información necesaria para depurar.

Siempre podemos salir del paso con...

Novedades en Edge Rails #21

2009-04-25T00:00:00+02:00

Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 24 de Abril de 2009 en el blog de Ruby on Rails.

Durante la última semana se han estado realizando operaciones quirúrgicas en Edge Rails, en preparación para un lanzamiento alfa de Rails 3.0 en la RailsConf. Hemos visto unas 5 entreags en la rama maestra de Github durante esta semana. He aquí una visión general de los cambios más recientes.

Cambios en Rails 2.3.x

Antes de empezar con los cambios en la rama maestra, ha habido un par de entregas en la rama 2-3-stable, que ya han sido trasladadas a la rama maestra.

Se han corregido un par de errores que tenían que ver con las condiciones en hashes, especialmente para garantizar que :dependent => :delete funcionará en todos los casos.
El adaptador de Active Record para PostgreSQL ahora hace lo correcto si utilizamos tablas en esquemas distintos a los de por defecto. Por supuesto hay que poner el nombre de tabla en la clase del modelo, por supuesto: set_table_name 'other_schema.customers' commit
También en el adaptador de PostgreSQL se han corregido un par de bugs relativos al entrecomillado incorrecto de nombres con letras mayúsculas.

Refactorización de ActionView::Path

Una gran parte de los cambios de esta semana en Rails 3 vienen dados por la continuación del trabajo de refactorización de ActionPack. Esta vez el objetivo era ActionView::Path. En estrega se incluye el desacoplamiento de ActionView::Path, ActionController y ActionMailer, lo que conlleva dos beneficios. En primer lugar el código es más fácil de mantener y comprender porque se encuentra consolidado en un único lugar. Y en segundo, al abstraer este tipo de cosas y dar una API clara se permite que otros componentes participen en la capa del controlador, además de los mailers y los controladores tradicionales.

Queda bastante por hacer en el futuro: el plan es desacoplar también las plantillas del sistema de archivos, así como desacoplar las traducciones de ActionView. ¡Permanezcan atentos!

Soporte JSON de quita y pon

Tal vez recuerden que Rails recibió hace poco el soporte XML de quita y pon. Esta semana, gracias al trabajo de Rick Olson, le toca el turno a JSON, lo que significa que podemos reemplazar el soporte de JSON por defecto basado en YAML por la gema JSON:


ActiveSupport::JSON.backend = "JSONGem"

Como parte de este cambio Rails ahora utiliza ActiveSupport::JSON.encode() cuando necesita generar JSON, lo que reemplaza al antiguo #to_json. El equipo de Rails recomienda que todos hagamos lo miismo. Si escogemos seguir utilizando #to_json debemos saber que tal vez algunas librerías lo reemplacen. Podemos utilizar este patrón para saber si estamos usando la propia definición de Rails de #to_json:


gem 'json'
# Se carga la gema JSON, que sobreescribe to_json
ActiveSupport::JSON.backend = "JSONGem" 

class ActiveRecord::Base
  # reeemplaza el método to_json de la gema con el de Rails
  alias to_json rails_to_json
end

Active Support a la carta

En Rails 2.x, require "active_support" recupera todas las extensiones del core a la vez. En Rails 3, esto sólo hace que las extensiones estén disponibles; y por tanto hay que requerir todas las que queramos usar. Muchos de los cambios de esta semana trataban de desmenuzar Active Support de forma que podamos tomar sólo lo que queramos usar y nada más.

El resultado final es que es fácil escoger prestaciones de Active Support sin tener la sensación de cargar con un señor grandullón a nuestras espaldas. Y de regalo, toda la documentación se encuentra ahora consolidada en un único sitio: la clase principal. No hay que ir mirando en cada módulo para averiguar qué hace un método.

Todas las extensiones se han reorganizado de forma que se pueden requerir directamente sin asumir que todo ActiveSupport está dipsonible. ¿Queremos inflexiones como "car".plugarilze? Basta con hacer require "active_support/core_exte/string/inflections" y las tendremos. Nota: la implementación y organización probablemente sufrirá cambios en el futuro.

Otros cambios en Edge

Se han eliminado las extensiones de Rails a la clase Pathname, dado que sólo se usaban en un único lugar del código. commit
Se ha eliminado el soporte para DRb como almacenamiento de cache. commit
El adaptador de SQLite se une al de PostgreSQL en el soporte de resoluciones de microsegundos. commit

Novedades en Edge Rails #20

2009-04-18T00:00:00+02:00

Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 17 de Abril de 2009 en el blog de Ruby on Rails.

Por si se les ha escapado la última hora: la rama edge se ha despertado y comienzan a aparecer los cambios relacionados con Rails 3 en la rama maestra en Github. Así que vamos a tener mucho que tratar esta semana. Si desean profundizar en la historia técnica detrás de la rearquitectura en Rails 3, lo mejor es seguir los muy detallados posts que viene publicando Yehuda Katz.

¿Que rama debería usar?

El trabajo de lo que será Rails 3.0 se está efectuando en la rama master del repositorio Rails en Github. Si queremos estar al día con los últimos cambios esta es la rama a seguir, con la advertencia de que se trata de código alfa, si bien es perfecta posible construir una aplicación totalmente operativa utilizando la rama maestra de Rails. El equipo del core de Rails se ha conjurado para hacer que esta rama principal pase todos los tests, y de hecho una de las mejoras en Rails 3 es mejorar la covertura y políticas de integración continua en los tests. Pero es importante que tengan en cuenta que los cambios en Rails harán que algunos plugins tengan que ser reescritos antes de funcionar bien en Rails 3 (por supuesto, habrá plugins que necesiten más trabajo que otros) Esto hará que sea complicado utilizar Rails en despliegues en producción durante algún tiempo.

Para las aplicaciones existentes en producción, deberemos seguir los cambios en la rama 2-3-stable en GitHub. Esta rama contiene correcciones y mejoras en el código de la versión 2.3, y deberá permanecer compatible con los códigos y plugins que venimos usando.

¿Debo seguir enviando parches a Rails

¡Absolutamente! Rails siempre ha sido una obra de muchos y en Rails 3 esto no va a cambiar. Recibimos parches tanto para Rails 2.3 o Rails 3.0; por favor utilicen la etiqueta apropiada (2-3-stable o 3.0) en los tickets de Lighthouse para que sea fácil distinguir en qué rama están basados y probados sus parches. La guía para contribuir a Rails les ayudará en la mecánica de enviar un parche a Rails.

David resumió la visión general para Rails 3 en diciembre y este sigue siendo el plan básico. Si hay algo en lo que deseamos involucrarnos la lista Ruby on Rails: Core nos ayudará a ponernos en contacto con el equipo de desarrollo para coordinar los planes y evitar dolores de cabeza. La mayoría de las tareas ya están en marcha, pero sabemos que las ideas y contribuciones de la comunidad son esenciales para que Rails 3 tenga éxito.

Cambios en Rails 2.3.x

Centrándonos en Rails 2.3, en las últimas semanas hemos visto algunas correcciones, y una funcionalidad bastante interesante: ActiveRecord::Base#touch. La idea es que conseguimos un atajo para insertar la hora actual en los campos updated_at y updated_on:


@customer.touch

Lo que hace que esto sea algo más que un ahorro de pulsaciones el teclado es que también está implementado como opción en las asociaciones belongs_to:


class Order < ActiveRecord::Base
    belongs_to :customer, :touch => :last_order_update
end

Con esta declaración, al guardar o destruir un objeto Order se actualizará el campo correspondiente en el objeto padre Customer. Esto puede ser muy útil cuando estamos tratando de invalidar una copia cacheada del padre.

commit commit

Cambios en Rails 3.0

Al igual que en la 2.3, ActiveRecord::Base#touch también se ha añadido a Rails 3.0. Por lo general va a ser siempre este el caso: cualquier nueva funcionalidad en Rails 2.3 se va a propagar a Rails 3. El equipo del core dedica especial esfuerzo para asegurar que la actualización a Rails 3 sea sencilla cuando se produzca el cambio de versión. Pero ha habido más funcionalidades nuevas en Rails 3, y de eso vamos a tratar en el resto de la anotación.

Organización modular

Hay algunas partes del código de Rails donde hay niveles múltiples de inclusión, herencia y configuración. Como parte del esfuerzo para que sea más fácil entender qué es lo que hace, Rails 3 introduce las nuevas abstracciones depends_on, use y setup, que deberían hacer más legible y obvio lo que hace el código:


module AbstractController
  module Helpers
    depends_on Renderer

    setup do
      ...
    end
    ...
  end
end

module ActionController
  class Base2 < AbstractBase
    use AbstractController::Callbacks
    use AbstractController::Helpers
    ...
  end
end

commit más información

AbstractController

Probablemente el cambio arquitectural más grande hasta ahora en Rails 3 es la introducción de la clase base AbstractController. Se trata de una nueva implementación de la funcionalidad compartida entre ActionController::Base y ActionMailer::Base. La intención no es sólo proporcionar código que utilizarán las aplicaciones y los plugins directamente, sino también construir una API sólida sobre la que puedan depender otras cosas. Por ejemplo, un consumidor de AbstractController podrá implementar su propia lógica para encontrar plantillas, o añadir opciones adicionales al método básico render.

commit commit Más información

ActionDispatch

Otro cambio de arquitectura es la introducción de ActionDispatchmiddlewares y librerías HTTP que antes vivían en ActionController, incluyendo cosas como la gestión de peticiones, análisis de parámetros, códigos de estado, y nuestra propia copia de Rack. commit



Definición de la superficie de trabajo

Uno de los objetivos de Rails 3 es distinguir claramente entre los métodos públicos de API en los que pueden confiar las aplicaciones y los plugins y los métodos internos de Rails que podrían estar sujetos a cambios.  Un ejemplo de esto puede ser la refactorizaión que se ha hecho en ActionView::Template. Aquí el cambio ha consistido en identificar laos métodos que no son usados por ninguna otra clase y hacerlos privados.  Esto hace que se pueda entender de manera más clara la API de esta clase y a largo plazo significa que le dará a los plugins un contrato acerca de cómo pueden interactuar con el código del core.  Después de que esta superficie de trabajo se haya definido formalmente, probablemente dará lugar a una API más limpia.  commit

AJAX y los testigos de autenticación

Si hemos estado escribiendo mucho javascript a mano, habremos descubierto la molestia de tener que incluir el testigo de autenticación de Rails en nuestras peticiones.  Un análisis más detallado del problema revela que realmente no es necesario incluir este testigo en las peticiones AJAX porque la política del origen único que aplican los navegadores ya las protege. Así que Rails 3 dejará de coprobar estos testigos en las peticiones AJAX, así que tendremos un poquito menos de javascript que escribir. commit

Mejoras en los tests

Otra área de trabajo en Rails 3 consiste en poner al día los tests internos con las mejores prácticas.  Hay algunos puntos en el códgo donde los tests son menos sistemáticos de lo que podrían ser; los cambios se han venido aplicando con cobertura de tests pero nadie se ha ocupado de garantizar que haya una cobertura de test completa del flujo de ejecución de una petición feliz.  Para echar un vistazo a lo que se viene haciendo en este aspecto, véase algunos de los ficheros de test en  actionpack/test/new_base (el código new_base es una reescritura en curso de ActionController::Base).  También se está trabajando en mejorar las historias de integración continua y agrupar algunos tests de integración de altov nivel que puedan ejercitar Rails como un todo.

Cabos sueltos

Hay algunas funcionalidades de Rails 2.3 que aún no están implementadas en la rama 3.0.  Algunos cambios no han podido ser fusionados con la nueva arquitectura y otros están siendo vueltos a implementar de diferente manera.  Encontrarán más detalles en este mensaje de entrega pero las piezas que faltan incluyen la mejora de rendimiento en el procesado de plantillas en modo de desarrollo y su recompilación en producción, así como alguna lógica en el código que las escoge.   Los desarrolladores han manifestado su intención de hacer que intentan conseguir la paridad de funcionalidades lo antes posible.  De hecho ya se ha hecho una pasada sobre estos cambios: committed.

Eliminado: Soporte de CGI

Rails 3 dejará de servir peticiones a través de CGI.  Esto fue declarado a extinguir en Rails 2.3 así que no debería sorprender a nadie que se elimine por completo.  Por supuesto, si necesitan procesar CGI por algún motivo recuerden que se soporta a través de Rack.  commit



Novedades en Edge Rails #19
2009-04-04T00:00:00+02:00



Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 3 de Abril de 2009 en el blog de Ruby on Rails.





Todo ha estado también bastante tranquilo esta semana en la rama de desarrollo: sólo ha habido 5 entregas.  Aún no se fusionado en la rama maestra todo el trabajo hacia Rails 3.0, así que si necesitamos cualquiera de los parches posteriores a la versión 2.3 aún podemos actualizarnos a la rama edge sin preocuparnos.


Cambios




¿Cuando 24 horas no equivalen a un día...?  Cuando nos movemos a través de la fecha de cambio de horario de verano a invierno.  O, al menos, hasta que se ha aplicado este parche.  Podemos leer más detalles en el ticket en Lighthouse.

¿Has mirado últimamente en /rails/info/properties?  Mira otra vez después de esta entrega y aparecerán todos los módulos Rack que tengamos instalados en nuestra aplicación.



Novedades en Edge Rails #18
2009-03-28T00:00:00+01:00



Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 27 de Marzo de 2009 en el blog de Ruby on Rails.





Ha sido una semana aparentemente tranquila en Rails; tan sólo ha habido una docena de entregas durante estos siete días.  Pero entre bastidores se está trabajando para fusionar lo avanzando en Rails 3.0 en la rama maestra del repositorio de git.  Les tendremos al tanto.


Mientras tanto, se han resuelto algunos problemas menores de la verisón 2.3:



Ahora se gestionan adecuadamente los parámetros en los tests con muchas peticiones POST en el mismo bloque. commit

Ahora funciona en Windows render :file con rutas absolutas. commit

El reconocimiento de extensiones de plantillas se ha hecho más robusto (si han tenido problemas con archivos parecidos a show.erb.orig). commit



Por último, recordar que si han tenido algún problema con Rails 2.3, nos gustaría saber de ellos y nos encantaría aún más si proporcionasen un caso de prueba del error o un parche.  Comprueben los detalles en la guía Contributing to Rails.


Novedades en Edge Rails #17
2009-03-23T00:00:00+01:00



Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 20 de Marzo de 2009 en el blog de Ruby on Rails.





Por supuesto la gran novedad de esta semana en Rails ha sido el lanzamiento de Rails 2.3.  Pero desde luego esto no significa que la historia de Rails Edge ha concluido antes bien nos estamos embarcando en uno de los proyectos más ambiciosos relacionados con Rails: la creación de Rails 3.0  Continúen leyendo para ver dónde estamos.


Cambios finales en 2.3



Algunas cosas fueron incluidas en Rails 2.3 en los días anteriores a su lanzamiento:



Transacciones en el lenguaje de definición de datos para bases de datos SQLitecommit
Compatibilidad entre render :file y Pathname commit
Convenciones de denominación de clases de ActionController para Metal commit



 Rails 2.3.2.1



Muy poco después de la publicación de Rails 2.3, que era la versión 2.3.2, se hizo necesario crear una etiqueta 2.3.2.1 porque a la versión etiquetada como 2.3.2 en el repositorio de Rails le falta una corrección importante (la versión instalable por gemas sí la incluye)  En resumidas cuentas rake rails:freeze:edge RELEASE=2.3.2 congelaría la versión equivocada de Rails en nuestra aplicación.


Para corregirlo, el equipo de Rails ha reetiquetado el árbol principal en un punto seguro, después de la corrección.  Esta nueva etiqueta es la versión 2.3.2.1 así que si estamos congelando Rails 2.3 en nuestra aplicación (en lugar de instalarlo como gema) debemos asegurarnos de utilizar rake rails:freeze:edge RELEASE=2.3.2.1.


El camino a Rails 3.0



Ahora que 2.3 está en la calle, ¿qué viene después?  Rails 3.0, que ha sido un hito distante en el horizonte hasta ahora, se acerca con más velocidad.  El equipo del core de Rails está discutiendo exactamente como proceder, pero debemos quedarnos con la idea de que dentro de poco veremos una gran cantidad de cambios en la versión inestable de Rails, según el trabajo que ha ido desarrollándose en diferentes forks del repositorio comienza a fusionarse en la rama maestra.   Tendremos que ser cautos a la hora de utilizar la versión edge en las aplicaciones ya existentes.  En particular, los cambios en el interior de Rails puede hacer que muchas extensiones tengan que ser reescritas.  La versión de desarrollo de Rails continuará siendo el último grito, pero tendremos que estar al tanto de los cambios y estar preparados para trabajar con ellos si escogemos utilizar esta versión en desarrollo de Rails.


Pero esto tampoco quiere decir que Rails 2 se haya quedado congelada en el tiempo.  Hay una nueva rama  2-3-stable en el repositorio de Rails que alojará todas las revisiones de mantenimiento que sean necesarios en la rama actual.  Se continuará trabajando para garantizar que las versiones 2.x funcionan bien pero el centro de gravedad de Rails rápidamente se desplazará hacia Rails 3.0.


Así que permanezcan a la escucha.  Continuaremos publicando los avances en el desarrollo de Rails 3.0 según vayan ocurriendo.  El proceso será, como siempre, transparente y cualquier idea o comentario serán bienvenidos.


Novedades en Edge Rails #16
2009-03-20T00:00:00+01:00



Nota: Esta entrada es una traducción de la publicada por Mike Gunderloy el 13 de Marzo de 2009 en el blog de Ruby on Rails.





Ha habido mucho ajetreo en la parte de desarrollo desde el lanzamiento de Rails 2.3 RC2. El equipo del core ha estado haciendo un serio esfuerzo para revisar todos los errores abiertos y parches enviados con vista a tener una versión sólida.  En este punto, el listón para aceptar nuevas funcionalidades está bastante alto pero incluso así ha habido 94 entregas esta semana desde RC2.  En su mayoría son correcciones para garantizar el comportamiento y estabilidad esperados.  He aquí lo más destacado.



Parsers intercambiables para XMLmini


El soporte para lectura de XML en ActiveSupport se ha hecho más flexible permitiéndonos quitar y poner diferentes analizadores.  Por defecto, utiliza la implementación estándar REXML pero se puede especificar fácilmente las implementaciones LibXML o Nokogiri en nuestras propias aplicaciones siempre que tengamos por supuesto las gemas instaladas:


XmlMini.backend = 'LibXML'
XmlMini.backend = 'Nokogiri'



commit commit


Reescritura de la tarea rake gem


Las interioridades de las varias tareas rake gem se han revisado de manera sustancial para que el sistema funcione mejor en una variedad de casos.  El sistema de gemas ahora conoce las distintas dependencias de los entornos de desarrollo y producción, tiene un sistema de desempaquetado más robusto, da más información cuando se le pregunta acerca del estado de las gemas y es menos dado a tener problemas de dependencias (del estilo de la gallina y el huevo) cuando se instala todo desde cero.  También hay correcciones del uso del comando gem bajo JRuby y para las dependencias que intentan instalar copias externas de gemas que ya están en el directorio /vendor

commit commit commit


Correcciones en las rutas


Ha habido un par de correcciones menores en el motor de rutas.  En primer lugar, las rutas miembro con requisitos funcionan ahora (anteriormente se ignoraban estos requisitos):


map.resources :orders, 
   :requirements => { :id => %r([^/;,?]+) }, 
   :member => { :accept => :get }



commit


También las rutas llanas funcionan adecuadamente con los espacios de nombre (commit) y podemos utilizar ahora el verbo OPTIONS en las condiciones de la ruta (commit).


Mejoras en la caché del lado del cliente


Los métodos expires_in, stale, y fresh_when aceptan la opción :public para que funcionen adecuadamente bajo proxies de caché.


  expires_in 10.minutes, :public => true
  fresh_when :last_modified => @user.updated_at.utc, 
             :public => true
  fresh_when :etag => @user, :public => true



commit


Esto y lo otro


El método String#parameterize ahora acepta un carácter separador opcional.


  "Mi gran pato".parameterize =>      "mi-gran-pato" 
  "Mi gran parto".parameterize('_') => "mi_gran_pato"



commit


El método ActiveRecord::Base#invalid? ahora funciona como el contrario de ActiveRecord::Base#valid?. (commit)


El método  ActiveSupport::Json.decode ahora gestiona secuencias de escape de tipo \u0000. (commit)


Ahora podemos definir tipos de contenido como multipart/mixed en Action Mailer. (commit)


Rails 2.3 incluirá una versión propia de Rack, pero si tenemos instalado Rack 1.0 como gema utilizará dicha versión (commit)


Novedades en Edge Rails #15
2009-03-02T00:00:00+01:00



Esta anotación es una traducción de la publicada el 27 de Febrero de 2009 por Mike Gunderloy en el blog de Ruby on Rails.





El lector avispado se habrá dado cuenta de que esta semana cubrimos no una sino dos.  Según se acerca la fecha de lanzamiento de Rails 2.3 el equipo del core es cada vez más exigente con lo que entra en el código y se concentra en arreglar errores.  Podemos esperar la versión Rails 2.3 RC2 para dentro de muy poco, y puede que sea la última candidata.  Así que si aún no han probado sus aplicaciones en Rails 2.3, ahora es el momento de hacerlo.  A estas alturas el código edge es bastante estable así que ya es hora de echarle un vistazo.


Procesado por lotes


Se pueden procesar un gran número de filas de un modelo ActiveRecord provocando menos estrés en la memoria utilizando find_in_batches:


Customer.find_in_batches(:conditions => {:active => true}) do |customer_group|
  customer_group.each { |customer| customer.update_account_balance! }
end



A find_in_batches se le puede pasar la mayoría de las opciones de find, sin embargo no se puede especificar el orden (siempre se devolverán en orden ascendente de la clave primaria, que además tiene que ser un entero), ni utilizar la opción :limit.  Para limitar el número de registros de cada lote, debe usarse la opción :batch_size, que por defecto vale 10


El nuevo método  each es un recubrimiento de find_in_batches que devuelve registros en lotes de 1000::


Customer.each do |customer|
  customer.update_account_balance!
end



Nótese que sólo se debería usar este método cuando el número de registros justifique el procesamiento por lotes: para números pequeños de filas (por ejemplo menos de 1000) deberían usarse los finders normales con su propio bucle.


commit


Notas sobre la carga de plantillas


Después del trabajo exhaustivo de algunos autores (aquí está el ticket de Lighthouse), Rails 2.3 proporciona la capacidad de habilitar o desactivar la caché de plantillas para un entorno en particular.  Las plantillas cacheadas dan un extra de velocidad porque no hace falta comprobar la existencia de un nuevo archivo de plantilla cada vez que se muestran; pero por el contrario implican que no podemos cambiar las plantillas al vuelo sin reiniciar el servidor.


Por lo general querremos tener activa la caché de plantillas en producción, lo que puede hacerse configurando lo siguiente en nuestro production.rb:


config.action_view.cache_template_loading = true



En las aplicaciones Rails 2.3 nuevas esta línea se generará automáticamente.  Pero obsérvese que si actualizamos el código de una aplicación Rails más antigua no tendremos este valor y la caché de plantillas estará desativada por defecto.  A no ser que estemos absolutamente seguros de que tendremos la necesidad de actualizar las plantillas en producción sin reiniciar los servidores, deberíamos asegurarnos de añadir este valor cuando actualicemos a Rails 2.3