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.

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.

Los que me conocen saben que he probado ya algunas distribuciones de GNU/Linux, aunque tampoco una cantidad fuera de lo normal. Por orden cronológico: RedHat (incluida la RedHat Enterprise Linux unos años más tarde), Mandrake (conocida como Mandriva después de la fusión de Conectiva y Mandrake), Debian (la que he usado más tiempo y mi favorita para los servidores), Gentoo, ArchLinux, Ubuntu, Kubuntu y, de un tiempo a esta parte, Mandriva. También he tonteado con otras, pero las he usado tan poco tiempo que no puedo decir que realmente las haya probado, como los casos de Fedora, OpenSUSE y Slackware (no considero que pueda decir que he probado distribuciones que sólo he usado cuatro o cinco días).

En 2005 empecé a usar (K)Ubuntu y anduve con ella hasta principios de 2008. Sin embargo, algunos problemas de estabilidad (con la wifi, la suspensión, los paquetes de KDE 4...) con la 8.04 y mi sensación -supongo que subjetiva, aunque compartida con más de un compañero- de que con cada versión se retrocedía un paso en esta cuestión, hicieron que me planteara probar alternativas.

Sobre mayo del año pasado, y después de que mi portátil no despertara de la suspensión por enésima vez, me cambie a Mandriva 2008.1. Había leído algunos reportajes muy favorables y me pareció una buena opción. Unos cuantos meses después, puedo decir que soy un usuario de 2009.0 muy satisfecho.

De Mandriva destacaría que:

• Me da la sensación de que es bastante estable -muchas veces esto se reduce a una cuestión de "sensaciones"-. No he tenido grandes problemas con ella en este sentido, aunque la 2008.1 me parecía más sólida que la 2009.0. Claro, que con la primera usaba KDE 3 y con la otra KDE 4 (y encima ahora uso paquetes experimentales, que por otro lado, van bastante bien).
• Es muy fácil de configurar. Su centro de control es de lo mejorcito que he visto y, aunque reconozco que muchas veces prefiero hacer las cosas a mano -por aprender-, hay ocasiones en las que te ahorra una cantidad de tiempo importante. Por cierto, eso me recuerda un chiste genial de la TiraEcol.
• Tiene una gran cantidad de paquetes disponibles, aunque no es Debian. Además, el software que incluye está bastante "al día".
• Si te gustan las emociones fuertes, tienes disponible Cooker, que es la versión de desarrollo.

Y, en general, funciona (y muy bien). Así que si alguien está buscando distribución para su máquina de escritorio, Mandriva puede ser una buena opción.

Hace algo más de un año, y por "culpa" de mi profesora de guitarra, empecé a aficionarme al blues. Empecé por Gary Moore (que tuvo su incursión en el mundo del blues) y luego fui aficionándome a artistas como B.B. King, Albert Collins, Muddy Waters, Steve Ray Vaughan o, mi preferido a día de hoy, Albert King.

Precisamente de este último quiero proponerles un tema: Born under a bad sign, que dio título al disco que Albert King publicó en 1967 con el sello Stax.

Lo cierto es que ese disco me parece genial y, aunque he destacado el Born under a bad sign, hay otros temas que no deben perderse como, por ejemplo, Oh, pretty woman, Kansas city o Laundromat Blues.

Así que, si no has escuchado el álbum, ya estás tardando. Y si ya lo has hecho, cualquier momento es bueno para volver a disfrutarlo, ¿o no? ;)