Hace unos meses, los desarrolladores de Arch Linux decidieron que la versión de Ruby por defecto para su distribución iba a ser la 1.9.1. Lo cierto es que en nuestros proyectos aún usamos la rama 1.8, así que el cambio no me venía del todo bien.

Para evitar la actualización, puede hacerse uso de la opción de configuración IgnorePkg de Pacman, el gestor de paquetes de Arch Linux. Así, con algo como esto en el fichero pacman.conf, debería bastar:

IgnorePkg = ruby rubygems

Como solución temporal no está mal, pero tampoco es que me vuelva loco. Afortunadamente, poco después tropecé con Ruby Version Manager (a.k.a. RVM).

Esta herramienta nos permitirá tener instaladas todas las versiones de Ruby que queramos, permitiendo que cambiemos entre ellas según sea necesario. A grosso modo, lo que hace es instalar todas las versiones en ~/.rvm, de forma que cuando queramos cambiar de versión, no tiene más que ajustar la variable PATH.

Por ejemplo, si queremos instalar la última versión 1.8.7 disponible:

$ rvm install ruby-1.8.7

Si ahora deseamos usar esa versión:

$ ruby -v
ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]
$ rvm use ruby-1.8.7
$ ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-linux]

Si queremos que esa sea la opción por defecto, basta con teclear:

$ rvm use ruby-1.8.7 --default

Por supuesto, cada versión tiene su propio "entorno". Quiero decir, si tengo las versiones 1.8.6 y 1.8.7 e instalo una gema en la primera de ellas, estará disponible sólo para esa versión (no para la 1.8.7).

Algo que quizás les pueda resultar interesante, es que RVM no se limita a la instalación de versiones del MRI, ya que también permite instalar JRuby, Ruby Enterprise Edition, Rubinius y el repositorio de shyouhei (que no sabía yo de su existencia).

En definitiva, una solución simple a un problema que se me había planteado ya en alguna ocasión.

Los que me conocen saben que PHP no es santo de mi devoción. Sin embargo, es un lenguaje con el que tengo que lidiar a menudo y, por qué no decirlo, me permite comer todos los días (una costumbre que adquirí hace ya muchos años :P).

La cuestión es que hoy tropecé con una de esas cosas que, no por sabida, deja de tocarme las narices. Hay que reconocer, de todos modos, que no es algo exclusivo de PHP.

Resumiendo mucho, en PHP la siguiente comparación es cierta:

'rock' == 0

La explicación "lógica" es que el intérprete de PHP es un cachondo y realiza conversiones automáticas de tipo así que, si intentamos comparar una cadena y un entero, pues convertirá la cadena en un entero y realizará la comparación.

A esto hay que añadir que la conversión de la cadena 'rock' a entero es 0 (sí, tampoco es exclusivo de PHP). Así que, al final, pasamos a tener algo como 0 == 0.

Claro, el resultado de combinar estos dos comportamientos son escenarios tan surrealistas como este:

$genres = array('rock', 'blues', 0, 'jazz');
print in_array('rock', $genres); // cierto
print in_array('heavy', $genres); // ¡también cierto!

Lo que no deja de maravillarme es cómo los informáticos aceptamos esta clase de cosas como si fueran "lógicas".

Afortunadamente, otros lenguajes gestionan mucho mejor este tipo de situaciones. Como ejemplos, tomemos Ruby y Python. Tanto en uno como en otro, la comparación 'rock' == 0 devuelven falso. Incluso la comparación 1 == '1' también resulta falsa: una cosa es un entero y otra una cadena (aunque a nosotros puedan parecernos lo mismo en este caso).

En cuanto a la conversión de cadenas a números, he de reconocer que prefiero el modo en que lo hace Python, quien al intentar convertir una cadena como 'rock' a número, lanza una excepción.

En Ruby:

'rock'.to_i == 0 # cierto

Mientras que en Python:

>>> 0 == int('rock')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: 'rock'

En fin, antes de que alguien se enfade, supongo que es justo decir que es una cuestión de gustos. Pero yo tenía que desahogarme :-)

PD: si no me falla la memoria, que es posible, la etiqueta 'berrinche' la copié miserablemente del antiguo blog (ya cerrado) de Esteban Manchado.

Gracias al blog de Antonio Cangiano, me entero de la existencia de dos revistas dedicadas a Ruby y Rails respectivamente: The Rubyist y Rails Magazine.

Ambas publicaciones están disponibles de forma gratuita en PDF, aunque también se puede obtener la versión en papel. Lo que pasa es que sólo se distribuyen en Estados Unidos, Canadá y Reino Unido (a un precio de 9 USD para The Rubyist y 8 USD para Rails Magazine).

Evidentemente, ya me he descargado los PDFs y, aunque no he tenido tiempo de leerlos, sí que he podido echarles un vistazo por encima. Lo cierto es que ambos tienen un acabado muy profesional y hay algunos artículos realmente interesantes.

En el segundo número de The Rubyist, podemos encontrar artículos acerca de la fusión de Ruby on Rails y Merb, la próxima versión de RubyGems, BDD, Git y ActiveMerchant, entre otros.

En cuanto al contenido del primer número de Rails Magazine, hay artículos referentes a los plugins de Rails, la recepción de correo electrónico, delegación, Shoulda, JRuby y análisis de rendimiento, entre otros.

Lo cierto es que en una primera impresión me ha atraído más The Rubyist. Pero supongo que sacaré tiempo para leer ambas con algo más detenimiento y ver hasta qué punto ofrecen contenidos que no estén ya en la web que es, al fin y al cabo, de muchas publicaciones destinadas al mundo de las nuevas tecnologías.

Con la salida de Ruby 1.9, una pregunta recurente es si tal o cuál gema funciona con esta nueva versión. Afortunadamente, Brightbox ha publicado un interesante proyecto para ayudarnos ante estas cuestiones: is it ruby 1.9?.

La idea es que los usuarios se registren e informen de si una determinada gema funciona o no con Ruby 1.9. Sin duda alguna, es un proyecto muy útil que nos puede facilitar la transición.