Instalando unos plugins para NetBeans me encuentro con un plugin que instala SakilaSampleDB. ¿Y qué es eso, me pregunto yo?. Pues una base de datos de ejemplo para testear todas las funcionalidades de MySQL: integridad referencial, vistas, triggers, stored procedures y demás cosillas. Es algo así como la famosa base de datos Neptuno de Microsoft Access.

Por supuesto, es gratuíta y puede descargarse desde la página de documentación de MySQL.

Mail Notification es un pequeño programa del que ya he hablado. Su mejor característica es la integración con Gnome Evolution, ya que te permite marcar como leídos los correos recién llegados sin necesidad de abrirlos, cosa que no puedes hacer con el formato mbox o via POP3/IMAP. Pero como lleva bastante sin actualizarse, el conector no funciona correctamente con la versión 2.26 de Evolution. El mensaje que muestra es:

“Notificación de correo no puede contactar con Evolution. Comprueba que Evolution está en ejecución y que está cargado el conector con Notificación de correo.”

Si comprobamos el contenido del paquete mail-notification-evolution podremos comprobar que el plugin se instala en un directorio incorrecto, dependiente de la versión 2.24. La solución es sencilla:

cd /usr/lib/evolution/2.26/plugins/
sudo ln -s ../../2.24/plugins/liborg-jylefort-mail-notification.so .
sudo ln -s ../../2.24/plugins/org-jylefort-mail-notification.eplug .

Luego, basta con reiniciar Gnome Evolution para que Mail Notification tenga acceso al correo.

Hay modos para hacer que VirtualBox Open Source Edition tenga soporte USB, pero si no eres un talibán del software libre y no te importa utilizar la versión Personal Use and Evaluation License (PUEL), la cosa se simplifica mucho. Lo único que hay que hacer, es instalar los binarios que proporciona Sun Microsystems y agregar tu usuario al grupo vboxusers, así de sencillo.

Actualización: si os aparecen los dispositivos USB desactivados, esto os será de ayuda

Hoy he tenido que mibrar un repositorio Subversion que lleva meses con la versión 1.5 a otra máquina con la versión 1.6. La configuración y demás ha ido bien, pero al intentar acceder al repositorio, me he encontrado con el siguiente mensaje:

bdb: Program version 4.4 doesn't match environment version 4.6

Evidentemente se debe a las diferentes versiones de Berkeley DB que usan las dos máquinas, por lo que es necesario realizar la conversión de las bases de datos. Una opción es utilizar db4.X-utils, pero no siempre está disponible en los repositorios de las distribuciones (por no hablar de Windows), por lo que es mucho más fácil volcar el repositorio con los comandos de Subversion, e importarlo en la nueva máquina. El volcado se realiza con el siguiente comando:

svnadmin dump repositorio > backup.dump

Y en la nueva máquina, en vez de copiar el repositorio tal cual, se crea uno de cero y se realiza la importación:

svnadmin create --fs-type fsfs repositorio
svnadmin load repositorio < backup.dump

Con esto nos ahorramos pelearnos con conversión de versiones

Localizar y optimizar consultas SQL problemáticas es muy laborioso y complejo a veces. Uno de los mayores problemas con los que me he encontrado, es localizar exactamente desde dónde se ha ejecutado esa consulta para así reproducir el problema lo más fielmente posible en un entorno de desarrollo.

Un SHOW PROCESSLIST permite visualizar la lista de consultas que se están ejecutando, con su tiempo y el host desde donde se ha realizado la conexión pero sin más información, cuando lo realmente interesante es ¿desde dónde se ha ejecutado esta consulta?. La solución es muy sencilla: utilizar comentarios SQL dentro de las consultas.

Hoy en día, cualquier aplicación mínimamente grande utiliza una capa de abstracción (bien integrada en un framework, bien propia) por lo que no suele resultar difícil interceptar las consultas para añadir los comentarios. Si combinamos esto con funciones como debug_backtrace() de PHP (o su equivalente en Ruby o Python), tendremos una valiosísima información, ya que es posible determinar desde qué función, clase+metodo e incluso la línea concreta:

SELECT /* controlador test, metodo database, linea 17 */ field1, field2 FROM table

Este pequeño truco faciltará mucho el trabajo de detectar consultas conflictivas especialmente en casos en los que se ejecutan desde muchos lugares en diferentes archivos, y a efectos prácticos el rendimiento no se ve mermado.

Cuando se tiene una tabla MyISAM dañada de 5 GB y 15 millones de registros, repararla puede ser una tarea que dure dias. Se debe principalmente a que la reparación se realiza mediante Repair with keycache en vez de Repair by sorting, infinitamente más rápido. Si se ejecuta el primero es porque el segundo suele fallar al no tener unos parámetros de memoria adecuados, resultando en un error como este:

myisamchk: error: myisam_sort_buffer_size is too small

Tras mucho trastear, mi solución resultó ser la siguiente:

myisamchk --sort_buffer_size=256M --read_buffer_size=2M
          --write_buffer_size=1M  --sort-recover tabla.MYI

Esto hace que en vez de procesar 1.000 consultas por segundo procese 100.000 con el evidente ahorro de tiempo y gasto de energía.

Suelo consultar Compostela Cultura para informarme de los eventos de Santiago, pero por desgracia no hay disponible ningún formato (como RSS o ICS) que permita sindicar/sincronizar los eventos. Por eso le he dedicado un momento para crear un parser que interprete el código HTML de las páginas y genere un archivo ICS, que puede utilizarse para añadirlo a cualquier programa que lo soporte, como Mozilla Sunbird o Microsoft Outlook. De este modo tendremos como un evento más del calendario, con su fecha, hora, ubicación, título y descripcion (este último campo sólo para los eventos para hoy).

Está programado como no en PHP, por lo que puede usarse con un servidor web o via comandos. Este es el código fuente y por defecto obtiene los eventos de música, pero indicando el parámetro GET tipo puede cambiarse.

Sugerencias y dudas, en los comentarios

La actualización a Gnome 2.24 en Debian está siendo lenta debido al lanzamiento de Debian GNU/Linux 5.0, y poco a poco se van añadiendo paquetes que funcionan sin problemas con la estable en los repositorios, la 2.22. Como es lógico, han cambiado bastantes cosas y por ejemplo, gedit ha dejado pasado a usar GVFS. Eso provoca que al actualizarlo deje de funcionar la edición de todo lo que no se a local: FTP, SFTP, SMB…

Tras trastear un poco encontré la solución, sencilla y elemental como siempre: instalar el paquete gvfs-backends. Eso habilita la edición en todos los sistemas soportados por la nueva capa de abstracción incluyendo el ansiado FTP.