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.

Hace ya más de seis meses que empecé a utilizar (de nuevo) Arch Linux en el portátil, después de que el driver de Intel que venía con Mandriva 2009.1 hiciera de las suyas.

Lo cierto es que, por segunda vez, la experiencia está siendo más que positiva, así que me he animado a escribir acerca de esta singular distro. No voy a contarles cómo es el proceso de instalación, ni la configuración, ni voy a ponerles pantallazos. Simplemente me limitaré a explicar qué cosas me gustan de Arch Linux (y qué cosas no me gustan). Es una opinión personal y, por lo tanto, totalmente subjetiva.

Cosas que me gustan

• Control. La filosofía de Arch Linux implica que prácticamente todo te lo tienes que hacer tú mismo. Eso te permite tener un sistema que se ajusta perfectamente a tus necesidades a cambio de cierto esfuerzo a la hora de instalar y configurar el software.
• Documentación. El wiki del proyecto incluye un montón de documentación útil. Así que, aunque tengas que hacerte las cosas tú mismo, siempre dispones de una buena documentación. Esto me recuerda, en cierto sentido, a la buena época de Gentoo.
• Software actualizado. Arch Linux es una "rolling distro" (como Gentoo). Básicamente significa que, según salen nuevas versiones del software que se incluye en la distro, van saliendo paquetes actualizados. Esto permite a los que sufrimos "versionitis", disfrutar de las últimas versiones estables de un montón de software. Además, no hay que sufrir dolorosas como las actualizaciones de Ubuntu cada seis meses.
• Estabilidad. Lo crean o no, Arch Linux es una de las distros más estables que he probado. En estos seis meses, son contados los problemas de estabilidad que he sufrido. Por comparar, hace poco estuve probando Mandriva 2010.0 y una de las cosas que más me desanimó fue que el panel de GNOME se me caía sistemáticamente dos o otres veces al día.
• Consumo de recursos. La instalación de Arch Linux es bastante mínima y, sobre eso, ya vas instalando tú lo que necesitas. Así que, por fuerza, va a consumir menos recursos que otras alternativas. Esto, todo hay que decirlo, también tiene su parte negativa.
• Velocidad. Arch Linux está disponible para arquitecturas i686 y amd64 (nada de i386 o i586). Eso y la poca memoria que consume, tienen un impacto importante en la velocidad.
• ABS. Es un sistema que podríamos comparar con los ports de FreeBSD y que permite instalar el software compilando desde su código fuente. Rara vez lo he usado, pero ahí está.
• Atención a KDE. Creo que la experiencia para los usuarios de KDE con esta distro es bastante buena. Los paquetes están siempre actualizados y, al menos hasta el día de hoy, funcionan realmente bien. Además, existe un repositorio KDEmod con paquetes modificados. No los he probado aún, pero he leído buenas críticas al respecto.

Cosas que no me gustan

• Esfuerzo para configurarla. Mientras que cuando instalas una distro como Ubuntu, Mandriva o Fedora tienes todo el sistema configurado y preparado para empezar a usarlo, con Arch Linux aún tendrás que hacer unas cuantas cosas antes de sacarle partido. No sólo eso, sino que cada vez que instales algo nuevo -que implique cierta complejidad-, vas a tener que configurarlo a mano. Y, claro está, a veces uno no tiene tiempo que perder en eso. Este fue el motivo por el que dejé de usar Arch Linux la otra vez.
• Atento a las nuevas tecnologías. He comentado que el proceso de instalación de Arch Linux te instala lo mínimo para que puedas construir tu sistema a partir de ahí. Así que de Pulse Audio, PolicyKit, Upstart, etc. mejor ni hablamos. El problema es que si no estás atento a lo que se cuece en otras distros, es probable que no conozcas la existencia de ciertas tecnologías que podrían resultar de tu interés.

Conclusiones

Creo que Arch Linux es una gran distribución, aunque entiendo que no es para todos los públicos y nunca va a competir con Ubuntu, Mandriva, OpenSUSE, etc.

Evidentemente, es una alternativa que te va a obligar a aprender detalles que, usando otras, pasarían desapercibidos. Pero también es justo decir que esa "obligación" puede resultar frustrante en ocasiones -sobre todo cuando las prisas aprietan-.

Personalmente, seguiré probando otras distribuciones de cuando en cuando para ver qué se cuece por ahí, pero Arch Linux seguirá siendo, de momento, mi sistema de escritorio.

Por cierto, si te interesa esta distro pero no quieres pelear con el proceso de instalación, quizás te interese el proyecto Chakra.

Banot.net ha publicado la segunda versión beta de Classroom, un módulo de e-learning para Drupal.

Classroom empezó a gestarse hace unos meses, cuando uno de nuestros clientes nos pidió que integráramos en su web (desarrollada por nosotros con Drupal) una plataforma de e-learning para dar cursos. Valoramos alguna de las opciones disponibles, especialmente Gradebook, y nos dimos cuenta de que no se ajustaban a nuestras necesidades.

Classroom

A día de hoy, Classroom cuenta con la siguientes funcionalidades:

• Gestión de cursos, tareas y recursos (apuntes, enlaces, etc.).
• Responder tareas y poner notas.
• Gestión de alumnos/profesores y suscripciones a los cursos.
• Integración con los módulos forum y Privatemsg para la comunicación con los compañeros/profesores del curso.
• Integración con Quiz, de modo que podemos usar ese módulo para poner tareas.

Flexibilidad

Classroom se apoya en cuatro conceptos fundamentales: los cursos, las tareas, los recursos y las respuestas. Parte de la flexibilidad de este módulo radica en que el usuario decide qué tipo de contenido puede actuar como cada uno de esos conceptos. Un ejemplo claro son los recursos: pueden ser ficheros, enlaces o un tipo de contenido que nosotros hayamos creado a tal efecto.

Las tareas son otro ejemplo: podría tratarse de un nodo con un campo para que el usuario ponga su respuesta, podría ser un Quiz o simplemente un fichero.

Simplicidad

Desde mi punto de vista, muchas veces se habla de "simplicidad" cuando lo que realmente se quiere es enmascarar la falta de funcionalidad. Pero en esta ocasión, realmente queremos que Classroom sea simple y sencillo de utilizar. Si alguien quiere algo más completo, creo que debería optar por una solución como Moodle.

El futuro

A corto plazo, el objetivo es tener una versión estable en cuestión de pocas semanas. Pero, evidentemente, ya hay algunas ideas para una próxima versión. Entre ellas destacaría:

• Integración con el módulo Views.
• Soporte para taxonomías (usando los mecanismos nativos de Drupal).
• Uso de triggers para gestionar eventos (desde una petición de suscripción de un curso hasta la corrección de una actividad).
• Soporte para avatares.
• Mejora en la integración con los foros.

Por supuesto, estaríamos encantados de recibir sugerencias.

El día 3 de julio comienza en la capital grancanaria el Gran Canaria Desktop Summit, celebrándose de forma simultánea la Akademy y la GUADEC. Por unos días, nuestra isla se convertirá en un importante punto de referencia en el mundo del software libre.

Desde Banot.net hemos venido colaborando, en la medida de nuestras modestas posibilidades, en la organización del evento y estamos convencidos de que puede ser un auténtico éxito. Para que se hagan una idea de su magnitud, no está de más echar un vistazo a la lista de patrocinadores.

Sin embargo, a falta de poco más de una semana, aún siguen faltando voluntarios que esos días puedan echar una mano en la organización de un evento al que asistirán alrededor de 800 personas. Da igual si pueden dedicar una hora o 6 días, lo importante es que puedan aportar su granito de arena. Hay un montón de áreas en las que colaborar y no tienes que ser profesional de la informática para ello. De hecho, nos vendrían muy bien unos cuántos traductores :)

Así que todo aquél que pueda ayudar, no tiene más que suscribirse a la lista de correo "workteam" o contactar con nosotros en el canal de IRC #gcds (en Freenode).

¡Te necesitamos!

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.

Anoche tuve la ocasión de asistir al concierto que Mägo de Oz ofreció en Gran Canaria (en la Carpa Dorada en Vivo) y lo cierto es que salí bastante decepcionado. Iba con muchas ganas de ver el espectáculo que nos ofrecían Txus y los suyos y terminé, como dirían en el mundo del fútbol, pidiendo la hora.

La noche no empezó nada mal: Semper, la banda canaria a la que le tocó el papel de telonero, sonó realmente bien y descargó toda su energía en el escenario. Reconozco que no es mi estilo favorito y al final se me hizo un poco largo, pero eso ya es cuestión de gustos. Hay que felicitarlos, desde luego.

Tras cerca de una hora de "caña", llegó el turno de Mägo de Oz. Y todo empezó a torcerse.

En favor de la banda madrileña hay que decir que se encontraron con múltiples dificultades técnicas, incluyendo un pequeño percance de uno de sus técnicos al que tuvo que asistir una ambulancia (creo que al final no pasó nada grave). ¡Incluso a Txus se le rompió la caja!

Pero lo cierto es que empezaron a sonar mal desde el inicio y no me refiero a una cuestión técnica. Como decía un amigo, parecía que les faltaba rodaje. Luego, con todos los problemas que fueron surgiendo, ya era complicado que levantaran cabeza.

Pero lo peor, desde mi punto de vista, fue la actitud. Lejos de crecerse ante las adversidades, Mägo de Oz se limitó a cubrir expediente y sacó el compromiso como pudo.

El final del concierto resultó también un poco extraño. Los madrileños hicieron un bis (con tres o cuatro canciones) y se retiraron dejando en el tintero algún tema como Hasta que tu muerte nos separe. Luego salió un tipo con una linterna pidiendo al público que animase, o al menos eso entendimos mi hermano y yo. Supongo que la idea sería pedir otro bis o algo así, pero lo cierto es que la gente estaba tan fría que todo acabó ahí. Y es que, si ofreces un concierto mediocre, no puedes pedir que la gente se vuelque contigo.

En definitiva, una decepción de un grupo que hace mucho que dejó de ser aquél que me enganchó con La Leyenda de la Mancha.

Ah, por cierto, comentar en favor de Mägo de Oz que el set list fue brutal, ya que tocaron casi enteros Jesús de Chamberí y La Leyenda de la Mancha. Si llega a ser un concierto con temas más nuevos, me hubiese ido antes del final.

En Banot.net hace ya un tiempo que escogimos Drupal como CMS para nuestros proyectos. Consideramos que, aunque está escrito en PHP y ese no es precisamente nuestro lenguaje favorito, está bastante bien diseñado, tiene una API potente y una buena documentación. Además, hay módulos casi para cualquier cosa.

Si te dedicas al desarrollo y usas herramientas como Drupal, lo normal es que, como mínimo, acabes haciendo algún arreglo o modificación a ciertos módulos.

En el mundo del software libre lo "educado" es, una vez que termines el parche correspondiente, enviárselo al autor para que él evalúe si le interesa, cosa que no siempre ocurre.

Este artículo está dedicado a la gestión de esos parches usando Mercurial y apoyándonos sobre las extensiones Convert (para pasar de CVS a Mercurial) y Mq (para gestionar los parches).

Lo he enfocado al desarrollo de módulos de Drupal, pero lo cierto es que puede aplicarse en muchos otros casos.

De CVS a Mercurial

Drupal es uno de esos proyectos que aún usa CVS. Creo que con la evolución de los sistemas de control de versiones distribuidos, los centralizados han quedado obsoletos y ya no tienen razón de ser. Sin embargo, sería estúpido pensar que proyectos como Drupal o FreeBSD pueden migrar de la noche a la mañana a un sistema centralizado. Es un paso que acarrea mucho trabajo y supone enfrentarse a no pocos obstáculos. Así que, de momento, tendremos que lidiar con CVS.

Para convertir el repositorio CVS a nuestro repositorio Mercurial, sobre el que trabajaremos, tendremos que usar la extensión Convert, que soporta la conversión desde CVS, Darcs, Subversion y Git.

Para activarla, como viene siendo habitual, basta con añadir la siguiente línea en la sección extensions de nuestro fichero .hgrc:

hgext.convert=

La conversión tendremos que realizarla sobre una copia de trabajo, ya que esta extensión no permite convertir directamente a partir del repositorio CVS original. Como ejemplo, voy a tomar el módulo Gradebook de Drupal.

$ export CVSROOT=:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib
$ cvs login
Logging in to :pserver:anonymous@cvs.drupal.org:2401/cvs/drupal-contrib
CVS password:
$ cvs -z6 checkout -d gradebook-HEAD contributions/modules/gradebook/

En este punto ya tenemos un directorio gradebook-HEAD con la copia de trabajo que vamos a convertir a nuestro repositorio Mercurial. La conversión la llevaremos a cabo con la siguiente orden:

$ hg convert gradebook-HEAD
assuming destination gradebook-HEAD-hg       
initializing destination gradebook-HEAD-hg repository
using builtin cvsps                                  
collecting CVS rlog                                  
258 log entries                                      
creating changesets                                  
64 changeset entries                                 
connecting to :pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib
scanning source...                                                 
sorting...                                                         
converting...                                                      
63 Initial API placeholders
...

Con ello tenemos en el directorio gradebook-HEAD-hg un repositorio sobre el que podemos empezar a trabajar.

Gestión de parches con Mercurial Queues

Mercurial Queues nos permite gestionar un conjunto de parches que se apoyan en un repositorio Mercurial. Estos parches no son como los "changesets" habituales, sino que podemos ponerlos, quitarlos, reordenarlos, modificarlos, etc. cuando queramos.

Para entender mejor lo que quiero decir, pueden acudir a la página de la extensión o a la sección correspondiente del libro Mercurial: The Definitive Guide.

Creación de parches

Empezaremos a trabajar con el repositorio Mercurial haciendo uso de la extensión Mq (Mercurial Queues). Como uso y costumbre, si no lo hemos hecho ya, tendremos que habilitar la extensión añadiendo hgext.mq= en la sección extensions de nuestro .hgrc.

Acto seguido, tenemos que inicializar Mq en nuestro repositorio:

$ hg qinit

Si nos fijamos, se ha creado un directorio .hg/patches que va a contener los parches, además de información adicional.

Ahora ya podemos ponernos a trabajar. Primero vamos a implementar una nueva funcionalidad que pensamos que puede ser de interés para el autor del software que estamos modificando. Así que creamos el parche (qnew) y hacemos los cambios oportunos en el código:

$ hg qnew feature-1.patch

En cualquier momento (y cuantas veces queramos), podemos refrescar el parche, con lo que se guardarán los cambios hechos hasta el momento.

$ hg qrefresh -m "Feature #1 bla bla bla"

Los parches se tratan como una pila que se sitúa sobre el último cambio del repositorio. La orden qrefresh se aplica, únicamente, a la cima de esa pila. Por cierto, no tenemos que repetir el parámetro "-m" cada vez que "refresquemos" un parche.

Supongamos que damos por terminada nuestra nueva funcionalidad. Ahora, vamos a arreglar un poco la hoja de estilos. Crearemos, por tanto, un nuevo parche:

$ hg qnew fix-css.patch

Trabajamos y, una vez que hemos terminado, refrescamos el parche.

$ hg qrefresh -m "Fix CSS"

Por hoy ya está bien. Hemos generado dos parches que enviaremos al autor por si los quiere incluir en el proyecto.

$ hg log
changeset:   2:f0b4bc5eb904
tag:         qtip
tag:         tip
tag:         fix-css.patch
user:        Imobach González Sosa 
date:        Mon Apr 13 07:32:36 2009 +0100
summary:     Fix CSS

changeset:   1:c9533ffc01f3
tag:         qbase
tag:         feature-1.patch
user:        Imobach González Sosa 
date:        Mon Apr 13 07:31:46 2009 +0100
summary:     Feature #1 bla bla bla

changeset:   0:2b8ed3e38ff7
tag:         qparent
user:        Imobach González Sosa 
date:        Mon Apr 13 07:30:44 2009 +0100
summary:     initial

Reordenando y modificando parches

Sin embargo, cuando estamos probando que todo está correcto, nos damos cuenta de que tenemos un fallo en el primer parche. Vaya, tendremos que crear otro parche para arreglar el primero... ¡no hace falta! Mq nos permite, entre otras cosas, modificar parches en cualquier momento.

Para ello, el parche que queremos cambiar tendrá que encontrarse en la cima de la pila. Lo más sencillo es retirar -momentáneamente- los parches posteriores:

$ hg qpop feature-1.patch
now at: feature-1.patch

$ hg qapplied
feature-1.patch

$ hq qunapplied
fix-css.patch

$ hg log
changeset:   1:c9533ffc01f3
tag:         qtip
tag:         qbase
tag:         tip
tag:         feature-1.patch
user:        Imobach González Sosa 
date:        Mon Apr 13 07:31:46 2009 +0100
summary:     Feature #1 bla bla bla

changeset:   0:2b8ed3e38ff7
tag:         qparent
user:        Imobach González Sosa 
date:        Mon Apr 13 07:30:44 2009 +0100
summary:     initial

Arreglamos el fallo, refrescamos el parche, y volvemos a ponerlo todo tal y como estaba.

$ hg qrefresh

$ hg qpush -a
applying fix-css.patch
now at: fix-css.patch

Ya hemos terminado nuestro trabajo y podemos enviar los parches a quien corresponda.

Actualizando nuestro repositorio

Lo normal es que los parches que enviamos tengan que pasar por un proceso de revisión y no sean incorporados inmediatamente al CVS. De hecho, es probable que no resulten interesantes para los desarrolladores del software original y decidan no aceptarlos.

En cualquier caso, en ocasiones nos podemos ver en la necesidad de mantener nuestros parches y, a la vez, incorporar los cambios que se van haciendo en el CVS.

En nuestro caso, supongamos que aceptan los arreglos a las hojas de estilo (fix-css.patch) pero que deciden tomarse algo más de tiempo para evaluar la nueva funcionalidad que hemos desarrollado. Al mismo tiempo, en el CVS aparecen arreglos a algunos fallos que nos pueden resultar de interés. Es momento de sincronizar.

Los primero que hacemos es retirar, temporalmente, los parches.

$ hg qpop -a

Ahora sincronizaremos el repositorio Mercurial con el CVS. En primer lugar, habrá que actualizar nuestra copia de trabajo del repositorio CVS:

$ cd gradebook-HEAD
$ cvs update -dPA

La extensión Convert nos permitirá incorporar los cambios hechos en el CVS:

$ cd ..
$ hg convert gradebook-HEAD-hg

Conviene ahora echar un vistazo a los cambios que hemos incorporado (hg log). Así, nos daremos cuenta de que han incorporado los arreglos en las hojas de estilos, por lo que no necesitaremos más ese parche. Podemos borrarlo:

$ hg qdelete fix-css.patch

Ya sólo resta actualizar el repositorio y volver a aplicar nuestros parches.

$ hg update
$ hg qpush -a

Ni que decir tiene que es posible que tengamos problemas a la hora de volver a "aplicar" nuestros parches, ya que se han introducido cambios al repositorio. Así que tendremos que hacer algo de trabajo "manual".

Conclusiones

Mercurial Queues es una de esas extensiones que estaba en mi lista de cosas a mirar y la verdad es que ha supuesto una agradable sorpresa. De hecho, hace que en cierto modo me recuerde a Darcs (salvando las distancias, que son bastantes).

En cuanto a la extensión Convert, la pena es que no tenga la capacidad de comunicación "bidireccional" que tiene, por ejemplo, git-svn. De todos modos, en este caso tampoco nos hubiera servido de nada (no tenemos permisos de escritura en el repositorio original).

En este artículo he dejado fuera algunas cosas importantes -por ejemplo, cómo compartir estos parches en el repositorio-, pero creo que es suficiente como introducción... ¿o no?

Son más de las 4:30 de la mañana y estamos ultimando los detalles para, en quince minutos, comenzar nuestro viaje a Madrid para ver esta noche a AC/DC en uno de los conciertos que la mítica banda australiana dará en España este año (tal y como adelanté hace unos meses).

Lo obvio, por tanto, sería que mi recomendación fuera un tema de los hermanos Young y compañía. Pero en cambio, voy a sugerirles una canción de Airbourne, otra banda australiana en la que muchos ven a los sucesores -no a nivel de popularidad, evidentemente- de AC/DC.

El tema escogido es Too much, too young, too fast, de su disco Running' wild (2007).

Ya es oficial (bueno, realmente hace un par de días que lo es): Banot.net ya tiene un nuevo miembro. Manolo Padrón, a quien cuento entre mis mejores amigos, se ha sumado finalmente a nuestro equipo.

Manolo participará durante los próximos meses en un proyecto de I+D que hemos iniciado en colaboración con el Grupo de Investigación en Interacción Radiación-Materia de la Universidad de Las Palmas de Gran Canaria.

Pero mejor, esperemos a que él mismo nos vaya desvelando los detalles en su blog.

Así que, ¡bienvenido a bordo, crack!

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.