No sé si Zed es tan “awesome”, pero “funny” lo es sin duda. Que cachondo el papá de mongrel.

PD: No os perdáis el post Rails is a ghetto que lo ha convertido en “infame”.

Este post va dedicado: al hombre detrás de Jasypt para que no me diga que lee el blog pero no entiende nada.

Ya casi llevamos dos años de Trabe, así que los balances, las miradas atrás, las lecciones aprendidas, etc. comienzan a cobrar un poco de sentido. Todavía somos una empresa joven (muy joven, dirán algunos) pero el tiempo es inexorable y ya ha transcurrido suficiente como para que empiecen a notarse los “posos” que la experiencia va dejando acumulados.

Creo que lo que más ha marcado estos dos años a nivel tecnológico ha sido el uso de Rails como framework de desarrollo web. Como ya hemos dicho otras veces (creo recordar), y como siempre decimos en nuestras escasas charlas y ponencias, somos muy poco dogmáticos a la hora de utilizar tecnologías, de modo que todo lo que diga a continuación no se debería interpretar como una loa a Rails, ni mucho menos como una muestra de desprecio hacia otros frameworks. Son sólo una serie de pensamientos, incluso no demasiado meditados :P, pero aquí los dejo de todas formas.

Trabe y Rails

Lo primero que pensé cuando vi por primera vez código Rails (es decir, Ruby), antes de que montaramos la empresa, fue algo así como “¿qué demonios…?”. Por aquel entonces estaba trabajando con las primeras versiones de Monorail y quería saber de donde había sacado el amigo Hammet su inspiración. Lo vi y me volví rápidamente al confortable mundo de los lenguajes compilados (aunque fuese un mundo .NET), eso sí, con la sensación de que, aunque por aquel entonces no entendiese nada, algo bueno tenía que haber en todo eso de Rails, porque Monorail era realmente bueno.

Cuando montamos la empresa todos teníamos experiencia en el desarrollo de aplicaciones web con frameworks “tradicionales” como Struts o ASP.NET y sabíamos, porque los habíamos sufrido en nuestras carnes, cuáles eran sus problemas; así que decidimos darle una oportunidad a Rails. Empezamos desarrollando nuestra propia Intranet y un pequeño proyecto de comercio electrónico, y una vez comprobamos que realmente era posible utilizar Rails (y que éramos capaces, que es algo que hay que comprobar y demostrarse a uno mismo, y que mucha gente parece obviar) empezamos a ofrecerlo como solución a nuestros clientes.

Desde esos inicios hemos montado desde pequeñas webs casi estáticas hasta una completa (y compleja) solución de comercio electrónico, sufriendo las carencias y problemas de Rails (aquí nadie se libra, amigos) y disfrutando de sus muchas ventajas.

Rails y Ruby

Y es que, si bien Rails es un framework al que se puede acusar de muchas cosas, cuenta con una ventaja sobre muchos de sus competidores: está escrito en Ruby. Y es que Ruby es un lenguaje realmente peculiar (supongo que en realidad es muy parecido a muchos otros, pero mi experiencia con lenguajes dinámicos no es muy amplia, así que tendréis que disculparme). Es peculiar, decía, porque, aunque al principio resulta complicado de entender, una vez te acostumbras permite escribir de manera terriblemente compacta pero a un tiempo perfectamente clara algunas construcciones que en otros lenguajes necesitan diez veces más líneas y cinco veces más llaves, paréntesis y puntos y coma.

Así, lo compacto de Ruby, unido a las buenas ideas que el señor DHH aplicó en Rails, dan como resultado un framework que permite desarrollar realmente rápido, sin la sensación de pesadez, lentitud y “mamotretismo” (disculpas por la palabrilla) que son inherentes a otras opciones (léase en este caso, si así se desea, Struts).

Rails, Ruby y el hip-hop

Este es un símil que surgió hace un par de semanas por Trabe:

RubyOnRails es como el hip-hop

No sé muy bien a cuento de qué venía, pero sí sé cuál es su sentido: muchas veces, la sensación al desarrollar con Rails es la de estar encadenando rimas. La base del tema son esas tareas repetitivas a las que al final se reduce el 80% de cada aplicación, ese continuo leer datos, mostrar datos, modificar datos, repetido una y otra vez. Y sobre esa base, Rails – gracias principalmente a Ruby – permite escribir código con flow. Mientras que con otros frameworks tienes la sensación de estar en un monasterio entonando un canto gregoriano (que no digo que no sea bonito, pero a veces se hace lento, repetitivo y pesado), con Rails tienes la sensación de estar rimando, fluyendo sobre la base, buscando la estructura que mejor se ajusta a cada nuevo problema. Y, como en el rap, dices mucho en poco espacio, mientras que hace falta mucho tiempo de canto gregoriano para cantar unas pocas frases.

Y es que puede que el hip-hop no tenga la solera del canto gregoriano, pero no se puede negar que tiene ritmo :D.

Trabe, Ruby, Rails y el hip-hop

Resumiendo, que en Trabe nos gusta Rails (a unos más que a otros, eso sí), que nos gusta el estilo que imprime al desarrollo. Y que también nos gusta el hip-hop (de nuevo, a unos más que a otros :).

Y termino, como no podía ser de otra manera, con una cita de SFDK, extraída del tema Mi nombre es rap, de su nuevo álbum Los Veteranos:

La lengua se me afila
ve y cuéntale a tus amigas que has conocido al rap
que ya conoces mi nombre de pila

Listo.

Hoy os recomiendo que le echéis un vistazo a la entrada Evil Twin Plugin en err the blog donde comentan una técnica muy sencilla para modificar el comportamiento de los plugins que uséis sin tener que modificar su código (cosa mala, caca, no tocar).

Consiste, resumiendo mucho, en crear un plugin con el nombre ”#{nombre_del_plugin_a_modificar}_{override|extensions|tu_palabra_favorita}” que se inicializará después del original (ya que Rails carga los plugins en orden alfabético) para poder modificarlo al gusto.

Nosotros lo habíamos hecho alguna vez, pero no lo había visto antes por escrito y bien explicado. Así que, gracias y ahí queda eso.

Y ya que últimamente es costumbre en este blog, una cita… El orgullo y la debilidad son hermanos gemelos (James Russell Lowell)

Por si el título no lo deja claro, lo repito aquí: NetBeans se ha convertido desde hace unos meses en la opción a la hora de elegir un IDE para desarrollar aplicaciones Rails. Al menos ha sido nuestra elección y, por lo que puedo decir tras varios meses de trabajo, primero con las versiones beta y ahora con la release definitiva, creo que hemos acertado de pleno al abandonar nuestro querido Aptana RadRails y pasarnos a la “competencia”.

NetBeans proporciona un entorno de trabajo muy cómodo, manejable y potente, del que me gustaría destacar las siguientes características:

• Integración con SVN de serie
• Syntax highlight
• Autocompleción de tipos, variables, funciones, parámetros, columnas de BD, etc.
• plantillas inline à la Textmate (o casi, vale)
• Hints sobre posibles errores en el código
• Control de los generadores Rails y las tareas Rake desde el propio IDE
• Depuración de código Rails

Es una pequeña lista. Para obtener información más detallada sobre NetBeans podéis echarle un ojo a su propia página (el enlace está ahí atrás, donde dice “netbeans” :-P) o bien googlear un rato: hay un montón de gente ahí fuera encantados con este magnífico IDE para Rails.

De todos modos, por aquello de dejar salir mi lado negativo a pasear, antes de despedirme voy a comentar lo que menos me gusta de NetBeans en comparación con RadRails (es decir, Eclipse)

• La vista de sincronización de SVN. Prefiero la vista de los Eclipse, me da una noción más clara de qué ha cambiado (NetBeans muestra un listado plano de los ficheros con cambios, mientras que el plugin de Eclipse permite ver los ficheros en un árbol, colgando de sus carpetas padre)
• La gestión de las preferencias. En Eclipse se puede controlar casi cualquier aspecto del IDE, y encontrar cada preferencia es muy sencillo gracias al maravilloso sistema de búsqueda integrado en los diálogos de configuración. Por contra, encontrar en el NetBeans un determinado parámetro es una tarea de rastreo casi lineal hasta dar con ella que puede llegar a desesperar (por ejemplo, cambiar los atajos de teclado se convierte en un infierno)
• Por último, falta una opción (al menos yo no he conseguido encontrarla) que permita enlazar el editor de código con el árbol del proyecto. Se puede seleccionar el fichero que se está editando en el árbol del proyecto utilizando una combinación de teclas (ctrl+shift+1 si mal no recuerdo), pero a veces se hace tedioso. Aquí de nuevo gana el Eclipse, al permitir enlazar o desenlazar el editor y el árbol al libre albedrío del desarrollador, como debe ser.

Efectivamente, son tres pijadas. Y por eso mismo recomendamos NetBeans como IDE para Rails: porque los únicos argumentos que tenemos en contra no son argumentos, son pijadas.

(Y ya para terminar, una cita de la introducción a La lucha contra el demonio, de Stefan Zweig, a cuento de las comparaciones) [...] la comparación enriquece, pues realza los valores, dando una serie de reflejos que, alrededor de las figuras, forman como un marco de profundidad en el espacio.

...podemos olvidarnos de algunas costumbres adquiridas con otras plataformas (léase J2EE o .NET) y aprovechar ciertas construcciones de Ruby que en un entorno multihilo sería problemático usar libremente. ¿A qué me refiero?, a variables de clase.

Las amigables variables de clase almacenan valores compartidos por todas las instancias de dicha clase, y a estas alturas todos deberíamos saber que si más de un hilo puede leer/modificar una de estas variables, tenemos que gestionar la concurrencia. No obstante, el caso de Rails es diferente. Podemos asegurar que cada instancia de nuestro servidor (normalmente un mongrel) sólo va a ejecutar un hilo por cada petición y por tanto podemos utilizar las variables de clase impunemente.

Supongamos, como ejemplo, una página que muestra varios valores monetarios sujetos a tipo de cambio. Supongamos el siguiente código que gestiona ésto (sin entrar a discutir si es adecuado o 100% correcto, que no lo es, ya lo sé, pero para ilustrar la idea vale).

class Currency
  TYPES = %w(euro dollar)

  attr_accessor :value

  def initialize(value)
    self.value = value
  end

  def to
    Exchange.new self
  end

  alias :in :to  
end

class Dollar < Currency
  def to_s
    "#{value}$" 
  end  
end

class Euro < Currency
  def to_s
    "#{value}€" 
  end
end

class Exchange
  cattr_accessor :rates

  def initialize(currency)
    @currency = currency
  end 

  for currency in Currency::TYPES
    class_eval %{
      def #{currency}        
        rate = self.class.rates[:#{currency}][@currency.class.name.downcase]
        #{currency.classify}.new @currency.value * rate
      end

      alias :#{currency.pluralize} :#{currency}
    }
  end
end

class Fixnum
  for currency in Currency::TYPES
    class_eval %{
      def #{currency}
        #{currency.capitalize}.new self
      end

      alias :#{currency.pluralize} :#{currency}
    }
  end
end

De tal modo que, para cada petición sólo es necesario fijar una vez las tipos de cambio, usando para ello un before_filter ...

def exchange_rates_set_before_filter

  # ... Lógica real para obtener los tipos de cambio ...

  Exchange.rates = HashWithIndifferentAccess.new({ 
    :dollar => { 
      :dollar => 1, 
      :euro => 1.49 
    }, 
    :euro => { 
      :euro => 1, 
      :dollar => 0.67
    }
})

Y así poder escribir en nuestras vistas cosas sencillas y elegantes como:

1.dollar.in.euros #=> 0.67€
2.euros.in.dollars #=> 2.98$