Hace ya algún tiempo que buscaba crucigramas en español, y no encontré nada que realmente me gustara.

Sin estar muy convencido empecé a jugar con algoritmos para generar mis propios crucigramas, hasta que hace dos días hice pública mi web para hacer crucigramas en español (¡ta-daaa!).

Aún quedan cosas interesantes por añadir, y algunas por mejorar, pero la base está ya ahí: se pueden hacer crucigramas (¡oh!).

El proyecto consta de 3 elementos diferenciados:

• El backend sobre MySQL donde se generan los crucigramas. He usado el ORM de Django, aunque esta parte corre desde cron y no es visible para el usuario.
• El frontend, sobretodo la administración, en Django. Es lo que uso a diario en mi trabajo, y la verdad es que es la parte más sosa y menos divertida de desarrollar :).
• Un cliente web hecho en Javascript y jQuery.

Precisamente esa última parte es lo que me ha llevado más tiempo, pese a que en realidad es muy sencilla. Digamos que no me queda tan claro que Javascript tenga alguna parte buena, y ha sido todo un reto dedicarle tiempo libre a esta parte :(.

A destacar que casi he conseguido que el cliente funcione al 100% en dispositivos con pantalla táctil (sin teclado), aunque no era una prioridad. Esta es una de las cosas que quiero mejorar el las próximas semanas.

Otra parte que debería mejorar es la generación de los crucigramas. Sobretodo porque en mis pruebas partía de unos datos de entrada reducidos, y en el entorno de producción los datos son distintos, sobretodo en lo que se refiere al volumen de los mismos :D.

Porque esa es la parte interesante de todo el proyecto: he pre-procesado alrededor de 30.000 definiciones de Wikcionario (un proyecto similar a la Wikipedia), y utilizo dichas definiciones para generar los crucigramas de una forma automática :).

Las definiciones se distribuyen bajo una licencia Creative Commons, y lo mismo he hecho yo con los crucigramas.

El diseño de la web es muy sencillo, así como su mecanismo: un crucigrama al día, y un navegador basado en un calendario para poder ir a los crucigramas de días anteriores.

Hay programados crucigramas para las próximas dos semanas (incluyendo unos especiales para los sábados :P), así que ese es el plazo que me doy para mejorar el algoritmo de generación y (quizás) las cosas que faltan en el proyecto :).

No está nada mal que mi primer proyecto personal del año venga tan pronto, que desde los motivadores del año pasado, no le había dado suficiente continuidad a ninguna idea.

Después de que el congreso de EEUU aplazara SOPA/PIPA gracias a las protestas en Internet, los grupos del presión tras la propiedad intelectual siguen con su agenda, esta vez con un viejo conocido: Anti-Counterfeiting Trade Agreement (ACTA).

El principal objetivo de ACTA es obligar a los países firmantes a implementar políticas contra compartir ficheros en Internet mediante el uso de duras sanciones penales y ejerciendo presión legal sobre los proveedores de servicios y contenidos para que persigan a sus usuarios.

Además el proceso está siendo completamente opaco, buscando la mínima resistencia civil evitando el debate democrático. Por lo que parece, la estrategia está teniendo un éxito retundo :(.

Ya se ha firmado el tratado por la mayoría de los países de la EU (aunque solo hubo protestas en Polonia), incluyendo a España, y ahora debe ratificarlo el parlamento europeo.

Si quieres saber cómo actuar en contra de este tratado, puedes consultar este extenso dossier sobre el tratado, o echarle un vistazo a este wiki sobre como actuar contra ACTA.

Si Internet pudo detener una amenaza como SOPA/PIPA ¿por qué no parar ACTA?

El 31 de Julio de este año, OAuth sustituirá a FlickrAuth como mecanismo para autenticar aplicaciones que utilicen el API de Flickr. Esto implica cambios en Nautilus Flickr Uploader, que utiliza Flickr::API (implementa el sistema que desaparece).

En principio la aplicación no debería cambiar mucho desde el punto de vista del usuario, porque OAuth surgió tras FlickrAuth y se nota la influencia (positiva) del arte previo.

Internamente ya es otro tema, como se puede ver en esta comparativa por Jef Poskanzer.

He contactado con el autor de Flickr::API para ver qué planes tiene (ya intercambié correos con él al empezar el desarrollo porque la licencia no era lo suficientemente clara como para incluir el paquete en Fedora). En cualquier caso, creo que OAuth no es tan complicado y me parece una ocasión excelente para aprender cómo funciona.

La única pega de todo esto es que las versiones viejas de NFU dejarán de funcionar pasada la fecha (espero que los token viejos sigan siendo válidos, aunque no se puedan conseguir nuevos); y la única solución va a ser instalar la nueva versión :(.

Una de las (¡muchas!) cosas que no me gustan de Javascript es que no parece haber suficiente consistencia entre las diferentes implementaciones que encontramos en los navegadores.

No es nada positivo cuando los detalles del lenguaje te distraen de lo que estás programando, pero ¿qué pasa cuando una funcionalidad se comporta de forma distinta dependiendo del navegador?

Por ejemplo, en el trabajo tuve que pelear con un bug bastante complicado de localizar porque hay características de substr que no están disponibles en la implementación de Microsoft Internet Explorer.

Al final un x.substr(-1) se debe expresar x.substr(x.length-1), o no será portable. Algo que debes de saber y solo da la experiencia, y que convierte a una funcionalidad en inútil (a no ser que no quieras soportar IE, claro :P).

Ah, pero no siempre es IE el problemático. Aquí hay otro caso, para el que incluso di de alta un bug para Firefox:

// constructor usando milisegundos
var a=new Date(0);

// ¿cuál es el resultado? :D
console.log(a.getHours() + ", " + a.getMinutes() + ", " + a.getSeconds());

El resultado en Firefox es 1, 0, 0 mientras que en Chromium/Chrome es 0, 0, 0.

La vedad es que la explicación no es nada sencilla, pero Firefox es el que muestra el resultado correcto: el segundo 0 corresponde con 00:00h UTC del 1 de Enero de 1970, y como mi huso horario es Europa/Londres, en ese día se aplicaba el horario de verano y... la hora era 1am y no medianoche.

Al final con usar los métodos UTC (por ejemplo, getUTCHours), el problema se soluciona y podemos seguir adelante con nuestro trabajo... y mejor no pensar en el tiempo perdido :).

Actualización: parece que mi informe de error ha sido aceptado y sí hay un problema en la implementación de Firefox :).

»Gnome shell, o cómo aprendí a dejar de preocuparme y a amar a la bomba · Hace ya algo más de un mes que actualicé a Fedora 16 y me metí de cabeza en Gnome 3. Primero lo ignoré, usando el teclado como se viene haciendo ya desde hace 10 años, y luego empecé a encontrar algunas funciones interesantes y otras completamente rotas; pero para ser justos ahora no puedo negar lo evidente: es mucho más estable que Unity (uso Ubuntu 11.10 en el trabajo, plagado de bugs nuevos y viejos; launchpad on fire!). Es cierto que Gnome ha sufrido una pérdida de funcionalidades, pero al menos lo que trae la versión 3.2.1, es estable.

En el trabajo contribuimos a varios proyectos Open Source (uno de ellos liberado y mantenido por nosotros: sftpcloudfs), y muchos de ellos incluyen servicios en Python.

Para mi que vengo de C, las excepciones son esa característica del lenguaje que más amor/odio inspiran. Capturar todo suele ser mala idea, porque dependiendo del problema hay que dar una solución u otra, aunque hay veces que algunos módulos no son muy claros con sus excepciones.

Un ejemplo de eso son los ssl.SSLError que nos pueden caer en cualquier momento con httplib y otros módulos que implementan el mismo interfaz (como el interfaz Python para Cloud Files; que algún dolor de cabeza me ha dado :S).

Los servicios tienen la característica común de ser un daemon, es decir: una aplicación no interactiva que se ejecuta de fondo y no tiene una terminal asociada.

Este tipo de aplicaciones suelen llevar un registro en un fichero o vía syslog (el logger del sistema), pero las excepciones que normalmente vemos en la terminal cuando el intérprete de Python detecta una excepción que no ha sido capturada, se pierden.

Por mucho control de calidad que se haga a un servicio, es posible que aparezcan algunos errores en un entorno de trabajo real, que son precisamente muy complicados de reproducir. Para evitar que perdamos la información de esas excepciones no capturadas, podemos usar: sys.excepthook.

Podemos incluir fácilmente información sobre las excepciones en nuestro código de log de la siguiente forma:

import logging
import sys
import traceback

handler = logging.FileHandler('test.log')
log = logging.getLogger()
log.addHandler(handler)
sys.excepthook = lambda exc_type, exc_value, exc_traceback: \
    log.critical('UNCAUGHT EXCEPTION %r: %s' % (exc_type, traceback.format_tb(exc_traceback)))

raise KeyboardInterrupt()

Es un ejemplo muy sencillo que usa la funcionalidad de log de Python para registrar en un fichero las excepciones no capturadas (en el ejemplo un KeyboardInterrupt).

Además he usado el módulo traceback para dar formato al mensaje que registramos, en lugar de usar el ejemplo que viene en la documentación... porque usando el parámetro exc_info la estructura de los logs se puede fastidiar por los saltos de linea (¡sobretodo si usamos syslog!).

Este ejemplo genera entradas como:

UNCAUGHT EXCEPTION <type 'exceptions.KeyboardInterrupt'>: ['  File "test.py", line 11, in \n    raise KeyboardInterrupt()\n']

Por lo demás es muy sencillo, y nos puede servir como garantía de que cualquier problema no esperado en nuestro servicio aparecerá registrada en nuestro log, aunque la aplicación termine de forma imprevista ;).

Me parece que me quedan un par de usuarios de correo electrónico en este servidor, pero por algún motivo los clientes de correo no avisan cuando el certificado SSL caduca :(.

He generado uno nuevo, aunque el que veníamos usando dejó de ser válido en Julio sin que me hubiera dado cuenta (igual es porque como es self-signed, internamente ya cuenta como malo, así que al caducar no cambian las cosas).

Este año ha sido diferente respecto a la última vez (gracias a la sección Un Día Como Hoy me he dado cuenta del problema :P), porque el servidor corre ahora una Ubuntu server:

• Recogemos el fichero cnf recomendado por la documentación de Dovecot y lo ajustamos a nuestras preferencias: dovecot-openssl.cnf (por algún motivo, el empaquetador de Ubuntu no incluye el fichero o yo al menos no lo he encontrado :S).
• Ejecutamos dentro de /etc/ssl/certs:

  # make-ssl-cert dovecot-openssl.cnf mail.usebox.net.pem --force-overwrite

• Copiamos el nuevo .pem en /etc/ssl/private (no es completamente necesario, dependerá de como esté nuestro dovecot.conf).
• Recargamos los servicios.

La nueva huella para el nuevo certificado es:

# openssl x509 -subject -dates -fingerprint -in mail.usebox.net.pem -md5 | grep Finger
MD5 Fingerprint=3F:68:33:89:FD:9F:D2:B3:00:DB:50:BE:31:BB:7A:29

Al menos cuando se cambia el certificado, los clientes protestan mostrando los nuevos datos (me ha pasado con Evolution), protegiéndonos así de posibles ataques reemplazando el servidor.

Otra cosa interesante es que si no indicamos -md5 al inspeccionar el certificado con openssl, nos muestra el hash SHA1 (¿será ahora el hash por defecto?), pero Evolution nos indica la huella del nuevo certificado a usar empleando MD5.

»Pues no son 10 años · Pensaba yo que ya hacían 10 años de Kleenux (no hay nada que ver), pero no: la asociación se constituyó el 29/08/2002 (aunque es cierto que las actividades empezaron antes). En cualquier caso, anoche tuvimos la cena/reunión anual (sin fotos, no como el año pasado), y fue un éxito total de convocatoria con 7 asistentes; que a algunos amigos no los veíamos desde las últimas jornadas.

»Microsoft implementando XMPP en Messenger · Suena a broma, aunque no son fechas: Anyone can build a Messenger client—with open standards access via XMPP. Aunque hay peros: como que hablamos de clientes messenger, con lo que usan un mecanismo de autenticación que, en principio, ningún cliente XMPP implementa (otra vez con OAuth; hace falta un ID para la aplicación :P); y nada de federación. Esto de usar los estándares sí, pero a nuestra manera (el embrace and extend, o no todo va a ser el buenrollismo de Google).

»Oraje Applet abandonado · Hoy he publicado versión con algunas correcciones y un par de traducciones nuevas para mi applet del tiempo, y será la última. No es realmente abandonado, sino que no tiene ningún sentido porque los applets ya no existen en Gnome 3. Por cierto: no he encontrado una forma de recuperar la funcionalidad perdida, así que... no tengo información meteorológica en el portátil de casa. El futuro del escritorio Linux que dicen ;).