a Freelance Web Developer

Estaba yo viendo el screencast éste sobre notificación de excepciones del grandísimo Ryan Bates y me puse a instalarlo, que son, calculando por lo alto, un par de minutos. Y cuando intento acceder al listado de excepciones veo que no funcionan los links ni las acciones ajax de borrar y tal… ouch¡.. resulta que está pensado para trabajar con Prototype y yo tengo todo por defecto con jQuery… así que nada, gracias al gran poder forkeador de github me puse a modificar el plugin para que soporte jQuery y aquí tenéis el resultado:

Exception_Logger_jQuery.

Instalarlo tal que así:

$ git clone git://github.com/fguillen/exception_logger_jquery.git vendor/plugins/exception_logger

Si queréis paginación hay que instalar la gema will_paginate y tocar el init.rb:

$ sudo gem install will_paginate

# init.rb
require 'will_paginate'
$PAGINATION_TYPE = 'will_paginate'

El nuevo generador de scaffold de RoR 2.2 no se lleva bien con Texmate, la nueva sintaxis para tests impide que usemos el utilísimo atajo de teclado ‘ctrl + shift + R‘ para ejecutar solamente uno de los tests de todo el fichero.

Este script convierte las líneas tipo:

test "should get new" do

en:

def test_should_get_new

Seguro que esto le espanta a más de uno, pero mientras Texmate no soporte la nueva sintaxis yo tampoco la soporto :). El script es la primera versión que me ha salido, se aceptan mejoras.

El script:

if ARGV[0].nil?
  puts "Indica la ruta al fichero" 
  exit
end
 
if not File.exists?(ARGV[0])
  puts "Fichero no encontrado: #{ARGV[0]}" 
  exit
end
 
result = ""
 
File.open(ARGV[0]).read.each do |line|
  if line =~ /^\s*test ".*" do$/
    line.gsub!( /\"\sdo\s*/, "" )
    line.gsub!( /"/, "" )
    line.gsub!( /^\s*/, "" )
    line.gsub!( /\s/, "_" )
    line.gsub!( /^/, "def ")
 
    line = "  " + line + "\n"
  end
 
  result << line
end
 
File.new( ARGV[0], "w+" ).puts( result )

Esto de Ruby on Rails es tan agradable y ligero que se nos olvidan hasta las buenas costrumbres en la mesa.

¿Cuántas veces te has ocupado de la intregridad referencial desde que trabajas con Rails?, si eres como yo, hasta ahora ninguna. Y es que Rails ofrece un potente sistema de validación que impide que llegue a la base de datos ningún modelo que no cumpla las reglas que has definido.

Pero aún así, es muy peligroso no indicarle a la BD unas mínimas normas de estructura para que no empecemos a tener registros huérfanos o que hagan referencia a otros registros no existentes.

Hoy comenzaba un nuevo proyecto y cuando he acabado las migraciones me he puesto a investigar a ver que encontraba para poder crear claves foráneas en mis tablas, y he encontrado a la gente de RedHill que tienen bastantes plugins interesantes, y entre ellos el RedHillonRails Core, que permite lo que estamos buscando y alguna cosilla más. También tienen el Foreign Key Migrations que extiende del core pero que lo que aporta no me gustaba ya que obliga (permite) indicar los índices directamente donde declaras el campo. Yo prefiero indicar todos los índices en una migración todos juntos.

El plugin es muy sencillo, lo instalas y ya puedes hacer cosas como esta:

add_foreign_key( :payments, :user_id, :users, :id, :name => :fk_payment_user )

Funciona a la perfección.

Hace ya bastantes meses que debería haber escrito este post pero la entrada ha sido tan suave que casi no encuentro el punto de inflexión, cuando verdaderamente ya podía decir que estaba dentro.

Creo que el día D fué cuando Blat me dió acceso a la rama master de la LaCoctelera y me dijo “¡commitea sin miedo!“.

Hace ya como 7 u 8 meses desde aquella reunión de primer contacto en los vagones de la línea 1 del metro de Madrid entre Álvaro, Blat y un servidor. Los inicios fueron lentos, limitados por mi inexperiencia y por mi preferencia a no tener mucha responsabilidad, acordamos que le dedicaría un día a la semana a la implementación de módulos cercanos a LaCoctelera pero que no formaban parte del core. Incluso manejaba mi propio repositorio.

Hace ya tres meses que hemos ampliado mi participación en este equipo, ahora sí que hay cachitos en el corazón de este magnífico proyecto Ruby on Rails que han sido desarrollados con estos deditos.

Desde que me llegó el flechazo con Rails hace ya exactamente un año uno de mis objetivos profesionales era formar parte del equipo de LaCoctelera, para mí el buque insignea de la flota Rails hispana, ahora ese sueño se ha cumplido, mi agradecimiento a Álvaro por la confianza que ha depositado en mí y a Blat por convertirse en mi mentor :).

Entonces fué justo hace 1 año cuando de verdad abrí mi mente y corazón a Rails, no se lo puse fácil pero venció todas mis defensas.

La rueda da una vuelta más y ya tenemos justo en la esquina la siguiente convocatoria de uno de los más interesantes y populares eventos del mundo Rails hispano: Conferencia Rails 2008.

Tendremos a uno de los personajes hispanos más aclamado por la comunidad en la keynote de apertura. A un encantador, gurú y gran difusor de Rails en la keynote de cierre.

Un montón de charlas técnicas iluminadoras, casos de éxito inspiradores, concursos, contactos, Ruby on Rails en ebullición, consulta el calendario para hacerte una idea.

Un evento organizado y construido sin ningún ánimo de lucro por entusiastas y amigos de esta afable comunidad entre la tecnología y la filosofía.

La fecha de inscripción y pago se cierra el día 5 de Noviembre osea que no debes perder tiempo de confirmar tu plaza.

Ayer en el madinspain presentaron la futura web de domestika.org a bombo y platillo.

Borja Delgado se encargó de la presentación del proyecto usando modos y técnicas muy propias de predicador evangelista :).

En mi opinión la web tiene muy buena pinta, más allá del diseño sobrio y la utilidad de las funcionalidades mostradas, denota conocimiento, atrevimiento y acierto por parte de sus responsables. Le auguro un buen futuro.

Uno de los caprichos más divertidos y rompedores de esta futura web es el soporte para el desarrollo de mini-aplicaciones que se conectarán a los contenidos de domestika.org mediante una API pública y se ejecutarán en la web de manera background hasta que el usuario acceda a ellas mediante una combinación de teclas. No se pronunciaron en la conferencia palabras prohibidas como dashboard y widgets pero me temo que me entenderéis mejor si yo sí las uso. Me parece que esta funcionalidad marcará un antes y un después en el mundo de las aplicaciones web.

Otra funcionalidad que denota la sabiduría de los responsables del proyecto es la externalización de los portafolios cuyos contenidos serán almacenados en un servicio externo del que se alimentará tanto la sección de portafolios de domestika.org como una aplicación aparentemente independiente en dónde cada usuario podrá personalizar sin límites la estética y presentación de su portafolio. Ayudándose además de dominios personalizados.

Pero lo más emocionante para mi es darme cuenta de que conozco personal y profesionalmente a gran parte del equipo de desarrollo de este fantástico proyecto, me siento afortunado y espero saber empaparme de todo el talento del que últimamente me veo rodeado.

Más que mi enhorabuena lo que expreso mi agradecimiento.

Estaba yo haciendo unos testecitos y veo que no se me estaban borrando los datos de la base de datos al ejecutar cada test lo cual me estaba generando unos poltergeist horribles.

Un comportamiento de Rails en el que confiaba como era este: “La base de datos vuelve al estado original en cada test“, me estaba traicionando.

Bueno el problema era que como mis tests no usaban fixturas no las estaba cargando y resulta que es la carga de las fixturas lo que borra la bd y no la propia suite de tests.

Solución:

fixtures :mimodelos

Aunque no use las fixturas es lo que he tenido que hacer para que la tabla se borrase con cada test.

¡Qué cosas!

Aclaración: En este texto repito mucho la palabra Rails, todo el mundo entiende que me refiero a Ruby on Rails. Pero creo que en muchos de los contextos debería haber puesto Ruby. Para mí Rails no sería nada sin Ruby y Ruby no sería nada sin un framework como Rails.. pero Rails es más suplantable que Ruby.

He estado viendo una de las charlas de las Conferencias Rails 2007.

Concretamente la de Fernando Blat sobre caché en Rails. Estoy intentando integrar esto de las cachés en un proyectillo basado en Rails que estoy haciendo.

La paradoja es la siguiente: resulta que sale uno haciendo una pregunta (minutos 41:40 al 43:00) que justamente me ha surgido a mí mientras videaba la charla. Resulta que el que hace la pregunta soy yo, resulta también que el proyecto en el que estoy trabajando lo hago bajo la supervisión del mismo Fernando Blat y es a quién se la iba a preguntar en persona. Resulta que no me acordaba de nada de esta charla. Resulta que no tenía ni idea de Rails en ese momento y que justamente ahí y entonces es cuando estaba pasando la etapa de la ironía y del rechazo para pasar a la de la aceptación.

Han pasado exactamente 9 meses de esa charla y las cosas han cambiado realmente mucho.

Conferencias Rails 2007

Fuí a las Conferencias Rails 2007 con una actitud completamente escéptica. Ya había oído hablar de Rails a los más freakies de mi cuadrilla, y también al más experimental de mis socios, pero había obviado sus comentarios con bastante incredulidad, yo soy una vieja mole de Java y estaba encantado con ser así.

Normalmente actúo con esta actitud ante la presencia de cualquier nueva tecnología que me presentan, no me gusta ser pionero en experimentar, me gusta vigilar desde la costa hasta ver si el barco sigue navegando cuando el viento amaina.

Voy en la cola de la comunidad, un paso por detrás de la cresta. Esto puede que me haga retrasarme un poco pero conozco el esfuerzo que requiere adquirir experiencia en cualquier tecnología, y lo que es peor, el esfuerzo que requiere dejarla cuando ha sido una decisión desacertada, por lo que cuando pongo algo en el punto de mira lo hago con mucha energía ahorrada.

Si me hubiera dejado llevar por todo canto de sirena que he escuchado me habría perdido en el baile eterno de ruidos como EJBs o Google Web Toolkit.

Durante las Conferencias Rails 2007 yo era un convencido de Java, no creía que nada de lo que oyera ahí fuera a convencerme, tengo la experiencia de que este tipo de conferencias endogámicas suelen ser un circuito de palmaditas en las propias espaldas vacías de contenido.

El primer día lo pasé discutiendo con la gente que se me acercaba, incluso con los conferenciantes ( Arquitectura hardware en Rails minutos 46:00 al 50:45, Tomatine minutos 18:30 al 20:30, Mtv.es minutos 26:20 al 28:00, y alguna más que no quedá grabada.. menos mal :) ) , expresando mi escepticismo hacia el cúmulo de bondades que este semi-nuevo framework estaba trayendo al mundo del desarrollo de software. Lo llaman la fase de la negación. Ya había pasado la fase de la ridiculización.

El segundo día llevaba un cabreo de la leche. No podía ser, no era cierto. No quería cambiar, quería que Java siguiera siendo lo mejor. Pero dentro de mí empezaba a solidificarse una revelación: Rails era mejor, no para el desarrollo web, sino para mí.

Era la primera vez que oía tantas veces repetida como feature de un framework: “la búsqueda de la felicidad del programador“. Me estaban hablando a mí, eso es lo que he buscado siempre en mi profesión: la felicidad. Entiéndase la felicidad del programador no como currar poco y cobrar mucho sino como ‘resolver‘ una necesidad de una manera elegante y ágil.

Me entró un temblor débil, dejó de ser desagradable. Recuperé el entusiasmo que cíclicamente me viene: Cuando hice mi primer FOR en el BASIC del MSX, cuando moví mi primer Sprite, cuando parcheé mi primera interrupción de teclado, cuando hablé con una bombilla vía puerto paralelo, cuando hice mi primera función C, cuando accedí por primera vez directamente a la memoria de vídeo, cuando inserté mi primer registro en una base de datos, cuando envié mi primer mensaje entre dos sockets, cuando hice mi primera web dinámica, … creo que a partir de entonces lo había perdido, todo se había vuelto pesado y costoso.

Rails había venido para rescatarme.

Las conferencias acabaron pero del poso en el estómago surgió una inquietud indomable.

Dejo Constela

Todo se había juntado, a mi agotamiento como desarrollador se sumaba el peso y responsabilidad de ser socio de una empresa que había empezado ha crecer y a comer recursos y presupuesto con avidez.

En Constela, con la compañía de mis socios Jesús y Miguel y del resto de equipo que juntamos, me hice fuerte, me hice duro, conseguí una experiencia que solo se consigue con la lucha. Les debo mucho.

Pero me sentía pesado, mis movimientos se habían vuelto costosos, el barco era fuerte pero su timón era muy duro y me bajé. Me dejaron una barca y empecé a navegar, remando, despacito, cantando.

Me pongo a comprar libros Rails como un loco

El entusiasmo había vuelto, la avidez autodidacta solicitaba información, ahora tengo casi todo lo recomendable traducido al castellano y casi todo lo imprescindible sin traducir.

Devoro información, todo es demasiado diferente, el click en mi cabeza tardó en llegar y todavía oigo su eco por lo reciente que ha sido.

Entro en la lista ror-es

La lista de desarrolladores de Rails en castellano, una comunidad muy pequeña pero inspiradoramente entusiasta y animada. Duramente moderada por @mort a quien he temido e incluso odiado en mi primera etapa, ahora casi-superada.

Hago la tienda de Hola Por Qué

Mi primer Hola Mundo en Rails no es una paginita con un mensaje insulso, es una tienda online :)

Muy pocas líneas de código picadas con el método de prueba y error, sin haber conseguido todavía hacerme con la sintaxis de Ruby ni el intríngulis de Rails, escribía instrucciones y declaraba variables al tanteo hasta que ningún Sintax Error ni nigún Error 500 aparecía.

Todo montado sobre sólo 2 tablas de base de datos.

Fichado por La Coctelera

Para mí La Coctelera ha sido, desde que conozco Rails, como el buque insignia español de este framework.

Escribo a Álvaro para comunicarle mi deseo de entrar a formar parte de un equipo con experiencia y entusiasmo como el suyo.

A los pocos días me encuentro con una seudo-entrevista de trabajo en un vagón de metro de la línea 1 con Álvaro y Fernando Blat.

Yo no llevo nada para enseñarles sólo les transmito mi entusiasmo y mi seguridad de que simplemente “se me dá bien esto del desarrollo web”. (Bueno, igual mi experiencia como responsable de tecnología en Constela y jefe de proyecto en el desarrollo de Kroonos fueron una buena carta de presentación).

Tienen entre manos un proyectillo que parece pensado para mí y me pongo manos a la obra. Y aún hoy sigo dando guerra por sus oficinas.

La experiencia de trabajar con un equipo de desarrollo ágil como el que tienen aquí en La Coctelera y The Cocktail en general, además de estar bajo la continua supervisión y apoyo de un joven gurú de nuestros tiempos como es Fernando Blat me está haciendo recuperar a grandes zancadas el retraso provocado por mi, aún valorado y mantenido, escepticismo.

Voy al Euruko

Y cojo y me voy a Praga, al Euruko 2008. Unas conferencias temáticas sobre Ruby. No disfruto tanto dentro como fuera de las conferencias.

Afuera me acoge con un pequeño grupo de raileros que también habían venido desde España, casi todos gurús de Rails y todos un encanto de personas.

Son las primeras conferencias de programación en las que se mezclan de manera perfecta las experiencias freakies con las amorosas.

La foto con el creador de Ruby

Y subiendo escalas en mi incipiente carrera como gruppy de Ruby aquí me tenéis, en una foto de pésima calidad, con el creador de Ruby Yukihiro ‘Matz’ Matsumoto y uno de los gurús al que llaman Dr Nic.

Red de amigos raileros y madrid-rb

El Euruko, las charlas, las comilonas y las risas crean pequeños vínculos que se comienzan a reafirmar con el reempuje de la comunidad Ruby de Madrid, del que soy testigo.

El último jueves de cada mes es la kdd oficial del grupo de Ruby de Madrid y aunque esta comunidad sea mucho más pequeña el karma de este lenguaje hace que las kdds sean mucho más populares que las de Java que solía convocar con la gente de Java-Madrid hace unos años.

Ahora ya conozco en persona a prácticamente la totalidad de los conferenciantes de esa mítica Conferencias Rails 2007 :)

Miembro fundador de rsug

Y me encuentro firmando el acta como uno de los socios fundadores de la asociación Ruby Spanish User Group, que aunque ahora no tenga los conocimientos ni experiencia suficiente espero aportar/devolver algo de lo que siempre tanto recibo a la comunidad.

Participo en el 2º concurso de programación de OpenMovilForum

E hinchado de orgullo por mis rápidos progresos me incribo al concurso de programación del OpenMovilForum con unas expectativas desorbitadas de llevarme el primer premio.

Presento no 1 sino 2 proyectos desarrollados en unas 3 semanas. Algo imposible de imaginar para mí hace pocos meses.

El resultado: me como los mocos. Pero empiezo a notar la soltura, empiezo a sentirme ágil.

Lluvia de ofertas de trabajo

Aunque no todas han acabado en acuerdo, sí que noto que mi perfil empieza a ser apetitoso.

Los principales escollos que veo es que el cliente sigue pensando que esto del desarrollo web es una baratija o que un freelance es intrínsecamente mucha más barato que una empresa.

En cualquier caso me siento cómodo y sé que cada vez me siento más capacitado para dar a los clientes lo que de verdad quieren: opinión, una persona resolutiva, prototipos rápidos y desarrollo iterativo.

Me compro un mac

¿Es este un paso que tiene que ver con mi incursión en Rails?…

Indudablemente sí, contagiado por la fiebre maquera que afecta a esta comunidad. Pero sobre todo tiene que ver con la búsqueda, mucho más antigua, de la agilidad.

¿Soy más feliz ahora?

Sí.

¿Será por Rails?, ¿por volver al mundo freelance?, ¿por mi nuevo Mac?… ¿por el amor?.. qué más da!

Revisando el log de tus queries te puedes encontrar que si estás buscando registros por un campo VARCHAR te salte un warning de “long key length“.

Esto es porque el índice que has puesto en este campo VARCHAR es muy grande, aunque MySQL soporta índices de hasta 1000 bytes si son muy grandes pueden ralentizar las búsquedas.

La solución está en limitar el tamaño del índice a un número bastante pequeño.

En MySQL esto se indica así:

ALTER TABLE mi_tabla ADD INDEX ( campo_del_indice(4) )

ó también:

CREATE  INDEX `nombre_del_indice` ON mi_tabla (`campo_del_indice`(4))

El problema es que si estamos usando ‘migrations‘ de Rails y queremos ser puristas nos encontramos con que la sintaxis estándar de las migraciones de Rails no soporta el campo ‘longitud’.

Como bien dice Jaime Iniesta existe un parche que da soporte a las migraciones para admitir el campo ‘length’.

Yo sin embargo he preferido no tocar el código de mis gemas y meter este fichero (rails_migraions_hack.rb) en el ‘/lib‘ de mi aplicación:

module ActiveRecord
  module ConnectionAdapters # :nodoc:
    module SchemaStatements
      def add_index(table_name, column_name, options = {})
        column_names = Array(column_name)
        index_name   = index_name(table_name, :column => column_names)
 
        if Hash === options # legacy support, since this param was a string
          index_type = options[:unique] ? "UNIQUE" : ""
          index_name = options[:name] || index_name
          index_length = options[:length] ? "(#{options[:length]})" : nil # only mysql
        else
          index_type = options
        end
        quoted_column_names = column_names.map { |e| quote_column_name(e) }.join(", ")
        # execute "CREATE #{index_type} INDEX #{quote_column_name(index_name)} ON #{quote_table_name(table_name)} (#{quoted_column_names})"
        sql = "CREATE #{index_type} INDEX #{quote_column_name(index_name)} ON #{table_name} (#{quoted_column_names}#{index_length})"
        p "SQL: #{sql}"
        execute sql
      end
    end
  end
end

Y cargarlo con un:

require 'rails_migrations_hack'

En mi environment.rb.

Funciona perfectamente y vemos como saca por pantalla las querys de las creaciones de índices con cosas como esta:

"SQL: CREATE  INDEX `idx_forums_forums_nicetitle` ON forums_forums (`nicetitle`(4))"

Es interesante consultar toda la discusión en la lista de ror-es.

Actualizado (2008-08-13):

Al parecer no estan cubiertas todas las posibilidades.

En el caso de estar creando un índice compuesto el atributo length se lo asigna al último campo y esto puede no ser lo adecuado:

add_index :tabla, [:campo1, :campo2], :name => 'idx_tabla1', :length => '10'

lo que intenta es hacer:

CREATE  INDEX `idx_tabla1` ON tabla (`campo1`, `campo2`(10))

Si el campo varchar que queremos limitar es el primero la hemos cagado..

Habría que intentar modificar la sintaxis del length para que coja algo como esto:

add_index :tabla, [:campo1, :campo2], :name => 'idx_tabla1', :length => { :campo1 => '10' }

No sé si es que soy yo el liante o es que me da por hacer las cosas raras.

El caso es que me he encontrado con otro dolor de cabeza haciendo algo, en principio, relativamente sencillo.

Se trata de insertar en la BD un modelo desde un script, que más adelante será un rake. Todo iba bien, no es complicado:

m = MiModelo.new( :nombre => 'el nombre' )
m.save

Pero, algo olía mal, pues los listados de este modelo tienen una vista, y esta vista está cacheada, y si insertaba el modelo desde el script la vista no cambiaba, osea: no estaba expirando la caché.

El problema estaba en que todos los engranajes de expiración de cachés estaban en los sweepers y éstos sólo se activan si el código pasa por el application.rb, padre de todos los controladores, concretamente con el método: cache_sweeper, y no encontraba manera de activar los sweeper sin pasar por un controlador.

Estuve dando unas buenas vueltas y preguntando a colegas, resulta que la caché en Rails está altamente integrada con el controlador. Y esto tiene su sentido pues no hay caché sin renderizado y no hay renderizado sin llamada a un controlador. Pero cuando hablamos de expirar cachés no veo tan claro que deba seguir estando integrado con el controlador, pues, como vemos en mi ejemplo del script, pueden existir muchos escenarios donde sea necesaria una expiración de caché sin necesidad de pasar por un controlador.

Googleando por ahí encontré un post que según creo entender también se queja un poco del exceso de integración entre la caché y los controladores.

La primero aproximación que parece ocurrírsenos es la de usar un observer en vez de un sweeper pero el sweeper tiene implícitamente un montón de métodos muy útiles para realizar la tarea de expiración de caché, como son los expire_* y los renderizadores de urls al estilo mi_modelo_url.

Además si empezaba a migrar todos los sweepers a observers empezaba a salirme del camino de como le gusta a Rails que se hagan las cosas.

Pero es que resulta que al parecer a Rails no le gusta que se expiren cachés desde un script y el workarround para conseguirlo no es del todo limpio pero se ha conseguido activar los sweepers desde un script para que se disparen al insertar un nuevo modelo en la BD.

El workarround es obra de Daniel Rodriguez Troitiño y aquí podéis revivir la lucha hasta conseguirlo.

Está funcionando para 2.0.1 y no sé si funciona en otras versiones.

require 'action_controller/test_process'
 
ActiveRecord::Base.observers = [MiSweeper]
ActiveRecord::Base.instantiate_observers
 
MiSweeper.instance.controller = ActionController::Base.new
 
tr = ActionController::TestRequest.new
MiSweeper.instance.controller.request = tr
MiSweeper.instance.controller.instance_eval( '@url = ActionController::UrlRewriter.new(tr, {})' )
 
m = MiModelo.new( :nombre => 'el nombre' )
m.save

Vemos que se activa el sweeper como un observer y luego se inicializa con todo lo necesario para que funcione.

Muchas gracias a Daniel que se lo ha tomado como reto personal ;).