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.

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?

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.

Todavía estoy en estado de "shock": parece que los desarrolladores de Ruby on Rails y Merb (otra plataforma de desarrollo web hecha con Ruby) van a unir sus fuerzas.

Con un artículo titulado Merb gets merged into Rails 3!, David Heinemeier hace un resumen de cuáles son sus expectativas:

• Rails será más modular. De forma análoga a Merb, al construir una aplicación con Rails se podrá partir de un "rails-core" e ir añadiendo funcionalidades a medida que sean necesarias. Así no mataremos moscas a cañonazos.
• El rendimiento es otro área en el que puede haber mejoras sustanciales ya que este es un aspecto en el que los desarrolladores de Merb han invertido mucho esfuerzo. De hecho, han reescrito partes de Rails con ese objetivo en mente, así que su experiencia en este sentido tiene mucho valor. Además, no les temblará la mano a la hora de modificar la arquitectura donde sea necesario.
• Rails 3 será "agnóstico". La idea es que los desarrolladores puedan elegir entre diferentes ORMs (ActiveRecord, Sequel, Datamapper...), plataformas de pruebas (test unit, RSpec...), bibliotecas para AJAX (JQuery, Prototype...), otros lenguajes para plantillas como Haml, etc.
• Otra cosa que a Rails le falta es una API estable y clara para aquellos que desean desarrollar plugins. Según admite el propio Heinemeier, eso lleva a que al actualizar Rails se "rompan" muchos de estos plugins. Merb cuenta con una API estable cubierta con baterías de pruebas para minimizar estos problemas.

Por su parte, Yehuda Katz, desarrollador de Merb, también comparte sus impresiones en su artículo Rails and Merb Merge. Pero creo que lo más destacable es su promesa de no "dejar tirados" a aquellos que están usando Merb hoy en día. Creo que la intención se puede resumir en esta afirmación suya: Merb 2 es Rails 3.

En cuanto a fechas, Heinemeier comenta que, siendo optimista, le gustaría tener una beta para la RailsConf 2009, que se celebrará en mayo en Las Vegas. Y si no es así, espera que a esas alturas el desarrollo esté ya bastante avanzado.

En definitiva, una gran noticia que puede dar muchas alegrías tanto a los usuarios de Merb como a los de Rails en un futuro cercano. Esperemos que el proyecto llegue a buen término.