a Freelance Web Developer

Estuve un día volviéndome loco con uno de estos tantos poltergeist que todo lenguaje o framework oculta, en este caso RoR.

Aprovecho para señalar mi opinión de que es imposible conocer un lenguaje/framework en unos pocos meses, por muy listo que seas y por muchos libros que seas capaz de leer en ese periodo. El verdadero conocimiento se esconde después de enfrentarte a un gran número de problemas/errores/bugs/y poltergeist que el lenguaje/framework en cuestión esconde, conocerle como si se tratara de conocer el carácter de una persona con la que convives hasta que entiendes como tratarle y entenderle. Es a lo que aveces nos referimos como la intuición.

Siguiendo con el poltergeist que nos ocupa: se trataba de que al activar la caché de acción en determinados controllers no se me estaban ejecutando los before_filters (aunque curiosamente si se ejecutaban los before_filters del padre ApplicationController  no de mis propios Controllers).

Esto no era muy normal y estaba claro de que algo estaba haciendo mal, pues precisamente una de las peculiaridades de la caché de acción es que siempre ejecuta los filtros, a diferencia de la caché de página que no ejectua nada.

Bueno, después de seguir el sabio consejo: si te estás espesando déjalo para otro día, hoy ya he encontrado lo que ocurría y no es ni más ni menos que el orden en el que se declaran los before_filter y los caches_action.

Yo lo tenía así:

class MiController < ApplicationController
  caches_action :show
  before_filter :ejecutar_antes, :only => [ :show ]
end

Y se solucionó cambiándolo a:

class MiController < ApplicationController
  before_filter :ejecutar_antes, :only => [ :show ]
  caches_action :show
end

Es muy fácil de probar:

class MiController < ApplicationController
  before_filter :X1
  caches_action :show
  before_filter :X2
 
  private
    def X1
      p "XXXXXXXXXXXX1"
    end
 
    def X2
      p "XXXXXXXXXXXX2"
    end
end

Si ejecutas :show una vez que ya está cacheada verás como sólo se ejecuta el primer filtro ‘X1′ y no el ‘X2′.

Si conoces algún sitio dónde se indique el órden en el que hay que hacer estas declaración pega el link en un comentario.

Es lo que tiene ruby.

Llevo un par de horas intentando sacar un Float en formato ‘d.ddd.ddd,dd’. Hay muchas cosas en internet para conseguirlo, pero no todas funcionaban bien, y otras funcionaban demasiado bien, con un montón de opciones.

El caso es que hay un helper del ActionView que tiene la función number_to_currency pero es un cabroncete de helper y no podía acceder desde el modelo. También teníamos la gema Currency pero era un pedazo monstruo para la tontada que yo quería.

Al final la gema Scruffy me ha dado la pista y esto es lo que tengo:

class Float
  def en_euros
    parts = sprintf("%01.#{2}f", self).split('.')
    parts[0].to_s.gsub(/(\d)(?=(\d\d\d)+(?!\d))/, "\\1.") + "," + parts[1].to_s
  end
end

Es un parchecito del Float para poder hacer esto:

>> 1234.566.en_euros
=> "1.234,57"

Este es mi primer apunte seudo-técnico sobre RoR. No es muy profundo, en realidad lo dejo caer aquí como nota mental.

Resulta que cuando instalas el interesantísimo plugin para testear cachés y sweepers: cache-test, éste tiene en su configuración la activación de las cachés en modo test:

ActionController::Base.perform_caching = true

Tanto en el fragment_cache_test.rb como en el page_cache_test.rb.

Hasta ahora esto no me había causado ningún conflicto pues sólo hacía una llamada a una página get/post cacheada en cada test y con la misma llamada comprobaba todo.

Pero con Shoulda se hacen varias llamadas a la misma página en cada llamada se comprueba una cosa y si la página está cacheada hay varias cosas que pueden fallar como éstas:

context "on GET to :show" do
  setup do
    get( :show, :id => '1' )
  end
  should_assign_to :variable1
  should_assign_to :variable2
  should_assign_to :variable3
  should_render_template :show
end

Aquí se hace una llamada get para cada should_ , el primero funcionará pero los posteriores al estar activada la caché fallarán porque la variable o la vista buscada tendrá valor ‘nil‘.

Este no es un problema de Shoulda, simplemente no me había aparecido hasta ahora. Con los tests normales surgirá igual si tienes la caché activada y haces 2 llamadas a la misma página cacheada y esperas encontrar una variable asignada, la segunda en ejecutarse fallará.

Workarround

Lo único que he encontrado por ahora es poner esto en el setup de los tests:

ActionController::Base.fragment_cache_store.reset

Para mí me funciona, para mis tests y para la configuración de mis cachés, puede que a ti no te funcione.

Y lo que si puede ser es que tengas una solución mejor, plis coméntala.