Existen muchos comandos para manejar ventanas en Linux (xwininfo, wmctrl…) pero gracias a este comentario en el hilo de petición de soporte D-Bus para Spotify en Linux descubro xsendkey, un comando que permite enviar combinaciones de teclas a cualquier ventana con sólo indicar su ID, aún estando minimizada o en otro escritorio. Esto tiene un gran potencial, ya que en el caso concreto de Spotify puede utilizarse para enviarle pulsaciones de teclas en vez de tener que hacer la chapuza de automatizar movimientos de ratón.

Para compilarlo, es necesario descargarse xsendkey.c, instalar libx11-dev y crear el Makefile como se indica en este hilo de Ubuntu Forums:

CC=gcc
CFLAGS=-g -Wall
LDFLAGS=-L /usr/X11R6/lib -lX11

all: xsendkey

xsendkey: xsendkey.o

clean:
    rm -f xsendkey.o xsendkey

Es importante respetar la tabulación de la última línea. Luego basta ejecutar make para obtener el binario y poder utilizarlo.

Firefox Sync (o Mozilla Weave) es un sistema que permite sincronizar todos los elementos de Firefox (favoritos, historial, contraseñas…) entre diferentes equipos o dispositivos. Por el momento funciona en Firefox 3.5 o superior y en Fennec (disponible de momento para Maemo y Android). La aplicación es muy útil y si no deseas utilizar los servidores de Mozilla puedes instalar tu propio servidor, ya que publican el código fuente y sólo requiere de un servidor web con PHP y una base de datos MySQL.

Pero problema es que (como no podía ser de otro modo con Mozilla) el servidor es una tortura instalarlo. Por eso un usuario ha creado una versión mínima que reemplaza MySQL por SQLite y requiere poco más que descomprimir un archivo y añadir una configuración al servidor web (ya sea Apache, Nginx o Lighttpd). El código fuente con las explicaciones puede descargarse desde la página del autor.

NOTA: al configurar el servidor de sincronización es necesario indicar que ya se dispone de una cuenta debido a que esta versión mínima no soporta el alta de usuarios a través de la aplicación, han de darse de alta manualmente.

Code Igniter trae de serie una sencilla pero potente librería para la validación de formularios, con una serie de reglas de validación predefinidas. Es posible añadir nuevas reglas externas a la librería creando nuevos métodos en el controlador, pero si esas reglas han de reutilizarse en más de un controlador el principio DRY no se cumple.

La solución pasa por extender la librería nativa añadiendo nuevos métodos que equilvaldrán a nuevas reglas. Por ejemplo, para poder realizar una comprobación con la nueva regla valid_url se extendería la clase nativa del siguiente modo:

<?php

class MY_Form_validation extends CI_Form_validation
    {
    function valid_url($url)
        {
        return (bool) preg_match('/^http:\/\/', $url);
        }
    }

Después, la comprobación se realizaría así:

$this->form_validation->set_rules('url', 'lang:url_incorrecta', 'valid_url');

En caso de ser necesario, puede utilizarse $ci =& get_instance(); para obtener una instancia del controlador y poder utilizar así otras librerías o modelos que puedan ser necesarios. Por supuesto, este truco también sirve para sustituir las reglas de validación nativas

Actualización: esto puede resultar particularmente útil para crear una regla que permita comprobar la existencia de un elemento en la base de datos cuando un campo que el usuario debe introducir es UNIQUE.

Como programador web necesito probar mis desarrollos en múltiples navegadores en sus diferentes versiones sobre todo para dar soporte a versiones viejas que aún usa un porcentaje significativo de usuarios, aunque tambien para anticiparme a los cambios que traerán las nuevas versiones, utilizando los nighty builds o las betas.

En el caso de Firefox resulta bastante sencillo, ya que permite gestionar fácilmente perfiles separados y las rutas que utiliza son relativas por lo que no importa el directorio desde donde se ejecute. Basta ubicar las versiones en subdirectorios nombrándolas, por ejemplo, con los 2 primeros números: 4.0, 3.6, 3.5 o 3.0. Luego, con este script puede lanzarse una versión concreta ejecutando firefox -P 4.0, lo que sirve para tener también un perfil para cada versión:

#!/bin/bash

# base variables
export FIREFOX_HOME="/path/to/firefox"

# detects version to launch
if [ "x$1" == "x-P" ]; then
    export FIREFOX_VERSION="$2"
fi

# if version is not defined, uses last
if [ "x$FIREFOX_VERSION" == "x" ]; then
    export FIREFOX_VERSION="4.0"
fi

# check if version exists
if [ -f "$FIREFOX_HOME/$FIREFOX_VERSION/firefox" ]; then

    # tell user what version will be opened
    echo "Opening Mozilla Firefox $FIREFOX_VERSION..."

    # launch Firefox
    case "$FIREFOX_VERSION" in
      4.0)
        export GTK_PATH="/usr/lib/gtk-2.0"
        export MOZ_PLUGIN_PATH="/usr/lib/mozilla/plugins"

        exec "$FIREFOX_HOME/$FIREFOX_VERSION/firefox" -P $FIREFOX_VERSION "$@"
        ;;

      3.6|3.5|3.0)
        export GTK_PATH="/usr/lib32/gtk-2.0"
        export MOZ_PLUGIN_PATH="/usr/lib32/mozilla/plugins"

        exec "$FIREFOX_HOME/$FIREFOX_VERSION/firefox" -P $FIREFOX_VERSION "$@"
        ;;
    esac
# version doesn't exists
else
    echo "Mozilla Firefox $FIREFOX_VERSION not found"
fi

Como se puede ver, al utilizar un sistema de 64 bits es necesario realizar unos pequeños ajustes, ya que hasta la versión 4.0 (aún en beta) sólo había compilaciones oficiales para 32 bits. Si el sistema es de 32 bits pueden eliminarse sin problema los export previos al exec. Para terminar, el script puede ubicarse en /usr/bin/firefox para que el sistema lo tome como el ejecutable por defecto y pueda seguir siendo el navegador por defecto.

Ayer @xabierm me mostró cómo en su HTC Legend la predicción del tiempo se integraba automáticamente a través del calendario de Google (en los terminales con HTC Sense, al visualizar un evento en el calendario, al pie se muestra el tiempo del mismo modo que el widget de escritorio). En otros terminales Android no se muestra el tiempo con animaciones e imágenes, pero sí en modo texto, como puede verse en la siguiente captura:

Para activarlo, sólo hay que acceder a Google Calendar y en Configuración, en la pestaña General indicar la ubicación por defecto y cambiar la opción Mostrar el tiempo de mi localidad a ºC (si no eres de los raritos que prefieren grados Fahrenheit). Después de esto, en la próxima sincronización se mostrará la predicción del tiempo tanto en el calendario como en el widget del portada escritorio. Y por cierto, también funciona para cuentas en Google Apps.

Hace unos días me vi en la necesidad de implementar en una web un proceso que puede tardar uno o dos minutos dependiendo de varios factores. El problema reside en que es un proceso que inicia el usuario y el usuario normalmente es impaciente, por lo que es normal encontrarse con que se pulsa F5 (o un montón de teclas al azar) o se cierra el navegador pensando que la aplicación se ha colgado. Por eso pensé en implementar una barra de progreso con JavaScript (utilizando la estupenda librería jQuery UI) en la que el progreso fuera real y fiable. El proceso lento iría mostrando poco a poco el progreso y mediante JavaScript se interpreta y modifica la barra.

Para obtener progresivamente el contenido de una petición realizada con JavaScript hay varias técnicas y tecnologías (HTTP Streaming, Server-Sent Events…) pero opté por algo mucho más sencillo: cargar el script lento en un <iframe> que en teoría debería funcionar para todos los navegadores. Basta hacer que el proceso vaya mostrando poco a poco bloques de información procesable por JavaScript (JSON, por ejemplo) y con un setTimeout() se comprueba el contenido del <iframe>, obteniendo el último bloque. En mi caso, cada bloque contiene el porcentaje y un mensaje para que se vaya mostrando en la barra de progreso. El código PHP podría ser:

echo json_encode(array('percent'=>10,'text'=>'Iniciando el proceso...')); flush();
echo json_encode(array('percent'=>50,'text'=>'Proceso a la mitad...')); flush();
echo json_encode(array('percent'=>100,'text'=>'Proceso finalizado...')); flush();

El problema es sólo Mozilla mostraba el contenido tras cada flush() mientras que los navegadores basados en Webkit así como Opera e Internet Explorer no mostraban nada hasta que terminaba el proceso. Tras mucho curiosear dí con la solución gracias a este comentario en PHP.net que explica que (exceptuando a los navegadores con motor Gecko) los navegadores no mostrarán nada hasta recibir una etiqueta HTML. Por eso, tras cada echo es necesario añadir una etiqueta como <br> que fuerce al navegador a mostrar el contenido. Además, algunas versiones de Internet Explorer no mostrarán nada hasta haber recibido al menos 256 bytes y Firefox no mostrará las líneas con menos de 8 bytes. Así que con las correcciones, el código PHP anterior quedaría así:

echo str_repeat(' ', 256) . '<br>'; flush();
echo json_encode(array('percent'=>10,'text'=>'Iniciando el proceso...')) . '<br>'; flush();
echo json_encode(array('percent'=>50,'text'=>'Proceso a la mitad...')) . '<br>'; flush();
echo json_encode(array('percent'=>100,'text'=>'Proceso finalizado...')) . '<br>'; flush();

Es importante tener en cuenta que Internet Explorer procesa las etiquetas en mayúsculas, por lo que al acceder mediante JavaScript al contenido del marco oculto habrá que tenerlo en cuenta. En mi caso, al utilizar <br> como separador he de realizar la separación de los bloques mediante una expresión regular con el modificador /i.

También hay que destacar que hay ciertas cosas que pueden provocar que todo esto no funcione, como los módulos de compresión de los servidores web o ciertos módulos de seguridad como mod_security. En estos casos no se enviará nada al navegador hasta haberse completado la petición, por lo que no será posible obtener el contenido del marco oculto hasta que el servidor envíe todo de golpe.