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.

Ya es oficial, ya se saben los premiados en el segundo concurso Open Movil Forum y ¡ah, sorpresa! no soy ninguno de ellos.

La verdad que no había tenido mucho tiempo y que los proyectos que había presentado eran un poco juguetes e igual difíciles de entender, pero me había hecho ilusiones de conseguir algún puesto.

Realmente que los proyectos ganadores se lo merecen.. pero ¿a quién le importa? ¡estoy enfadado!

Repasando qué es lo que he ganado con todo esto me salen suficientes razones para consolarme, y casi prefiero el resultado (¡mentira!) pues mis proyectos requieren de mucho más acabado para resultar realmente útiles y la rabieta puede ser un estimulante para animarme (¡mierda!).

He conseguido tener algo medio terminado en el caso de El Bautizador de Teléfonos y he conseguido unos buenos cimientos en el caso de GeoAlertas para seguir con él, ahora sí, usando una API de geolocalización más seria.

He sido un ingenuo al pensar que con mi poco experiencia en Rails podría estar al nivel de gente como Ernesto. Me merezco la decepción.

Me guardo las enhorabuenas para cuando deje de gruñir.

Actualizado 2008.05.22: Enhorabuena a los ganadores :)

¿Tu gusta Ruby? ¿Eres capaz de respirar el aire infectado de las calles de Madrid? ¿Tienes habilidades de comunicación como el habla y/o el oído? ¡Pues vente!

Hace poco se ha vuelto a dar vida al grupo Ruby-Madrid. El pasado jueves  24 se celebró la primera kdd de este nuevo ciclo.

Nos juntamos como unos 12 personajes entusiastas y desde las 19:30 puntuales que fuimos muchos la velada se alargó hasta más de las 24:00.

La idea es programar kdds todos los último jueves de cada mes. La hora aproximada será las 19:30 y el lugar a decidir en cada ocasión, la primera fué en el Starbucks que, pese a las dudas de muchos de los presentes, escaló lo suficiente para darnos cobijo a todos. La siguiente se está pensando ir al Aula The Cocktail.

Lo ideal es que cada kdd tuviera una temática central o una ponencia por parte de alguno de nosotros aunque no es imprescindible, es simplemente para darle un hilo conductor, todos sabemos que luego acabamos hablando de lo que surge, en realidad de mil cosas.

La lista de coordinación es esta: lista de coordinación del grupo Ruby-Madrid.

El calendario para estar atentos: calendario del grupo Ruby-Madrid.

¡Qué bonito y agradable es compartir opiniones, discrepancias y chistes temáticos! De verdad que agradezco mucho este tipo de iniciativas, es una gran motivación ver a gente motivada, relatar experiencias, despotricar de los clientes, pedir opinión y soluciones, … en resumen: sentirse acompañado y, por qué no, protegido.

Esto no es un tutorial, es una nota mental.

Entorno

• Ubuntu 7.10
• MySql 5.0

Instalar capistrano

Tanto en cliente como en servidor.

$ gem install capistrano

Configurar aplicación rails para Capistrano

En cliente.

$ cd #{RAILS_ROOT}
$ capify .

Editar fichero /config/deploy.rb:

require 'mongrel_cluster/recipes'

set :user, "username"
set :runner, "username"

set :application, "miaplicacion"
set :repository,  "http://www.mirepositorio.com/svn/trunk/"
set :scm_username, "username"
set :scm_password, "userpass"

set :deploy_to, "/var/www/railsapps/#{application}"  # path en el servidor
set :mongrel_conf, "#{current_path}/config/mongrel_cluster.yml"  # no tocar

role :app, "miservidor.com"       # si quieres indicar puerto miservidor.com:puerto
role :web, "miservidor.com"       # si quieres indicar puerto miservidor.com:puerto
role :db,  "miservidor.com", :primary => true # si quieres indicar puerto miservidor.com:puerto

Tuve problemas con el username y el userpass y al final les puse el mismo username y pass al usuario del sistema como al usuario del svn.

Editar /config/mongrel_cluster.yml:

---
cwd: /var/www/railsapps/miaplicacion"  # path en el servidor
log_file: log/mongrel.log
port: "5000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2      # puertos 5000 y 5001

Preparar servidor

En servidor.

Preparamos el directorio:

$ sudo mkdir -p /var/www/railsapps
$ sudo chown username /var/www/railsapps

Fichero configuración de VirtualHost /etc/apache/sites-available/miaplicacion.miservidor.com:

#we need this as on Ubuntu by default Proxy is not allowed
<Proxy *>
  Order allow,deny
  Allow from all
</Proxy>

#Proxy balancer section (create one for each ruby app cluster)
<Proxy balancer://miaplicacion.miservidor.com_cluster>
  BalancerMember http://127.0.0.1:5000
  BalancerMember http://127.0.0.1:5001
</Proxy>

#Virtual host section (create one for each ruby app you need to publish)
<VirtualHost *:80>
  ServerName miaplicacion.miservidor.com
  DocumentRoot /var/www/railsapps/miaplicacion/current/public/

  <Directory /var/www/railsapps/miaplicacion/current/public/ >
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    allow from all
  </Directory>

  ErrorLog /var/log/apache2/error_miaplicacion.miservidor.com_log
  CustomLog /var/log/apache2/access_miaplicacion.miservidor.com_log combined

  #Rewrite stuff
  RewriteEngine On

  # Check for maintenance file and redirect all requests
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]

  # Rewrite index to check for static
  RewriteRule ^/$ /index.html [QSA]

  # Rewrite to check for Rails cached page
  RewriteRule ^([^.]+)$ $1.html [QSA]

  # Redirect all non-static requests to cluster
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://miaplicacion.miservidor.com_cluster%{REQUEST_URI} [P,QSA,L]
</VirtualHost>

Activamos el VirtualHost:

$ sudo a2ensite miaplicacion.miservidor.com

Recargamos Apache:

$ sudo /etc/init.d/apache reload

Subir primera versión a servidor

En cliente.

$ cap deploy:setup

Preparar BD en servidor

En servidor.

Esto seguro que se puede hacer desde Capistrano:

$ mysql> create database midatabase;
$ mysql> grant all privileges on midatabase.* to username@localhost identified by 'userpass';
$ rake db:migrate

Próximos despliegues

En cliente.

$ cap deploy

Y si hay migraciones entonces hay que ejecutarlas en el servidor (aunque seguro que se puede hacer con el Capistrano).

Me piqué, me piqué.

Asistí a las conferencias rails 2007 y salí un poco mosqueado. Veía a la gente que se esforzaba en ser feliz, que tenían entre manos un lenguaje pensado por programadores para programadores.

Así que salí lanzado a probarlo. En dos semanas tenía montada una beta de la tienda online de unos amigos. Ahora la he retocado un poco y la he puesto en el aire para motivarme a afinarla.

Espero que a nadie se le ocurra criticar lo mal que está hecha, que si el diseño no mola, que si esto es de novatos.. porque efectivamente está mal hecha, el diseño hay que mejorarlo y está hecha por un novato.

El código no lo muestro porque entonces si que no podré asistir nunca más a ningún evento público.

Si os apetece probarla podéis hacerlo, al final de la confirmación del pedido hay un checkbox que pone “Es un pedido de prueba” lo seleccionáis y santaspascuas.

Tengo que decir en mi favor que ya me he devorado el “Ruby Cookbook” y el “The Rails Way”, devorado sin masticar, y que ahora voy a por el “Agile Web Development with Rails”.