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 ;).

Trabajar con Internet ha hecho que cambie nuestra percepción en muchas cosas. Sobretodo la web, que está ahí esperando a que la visitemos sin pedirnos nada a cambio (como esta bitácora :P).

Ayer leía una anotación de Maciej Ceglowski, creador del gestor de marcadores Pinboard (es de pago; curioso que haya que especificar, ¿los servicios en Internet son siempre gratis?), en la que comenta varias cosas interesantes: Don't Be A Free User.

Habla del fenómeno que es precisamente uno de los motores del movimiento start-up de Silicon Valley: un servicio o producto gratuito, que se hace relativamente popular, hasta que una empresa grande y ya establecida lo compra.

Los fundadores y/o empleados hacen caja y pueden quedarse en el proyecto o quizás vuelvan a empezar con otra historia. ¿Y qué pasa con el servicio o producto? Pues muchas veces desaparece dejando colgados a los usuarios (algo que vamos a ver cada vez más: software como servicio se llama).

Solo atendiendo a Google, su lista de adquisiciones es impresionante, así como la cantidad de proyectos que han desaparecido, porque han sido absorbidos por otros productos de la empresa o simplemente... se han perdido (bueno, para ser justos: podría ser peor... al menos Google publica los cadáveres en forma de Open Source).

No es que se pueda culpar a las grandes empresas, porque si no hay un modelo de negocio sostenible tras el proyecto adquirido (el modelo era: ¡que te compren!), es normal que se rentabilice la operación... y eso no tiene en cuenta a los felices usuarios.

Lo que no sé es si se puede decir, como insinúa Ceglowski (como parte interesada, él mismo lo dice :P), que las start-ups podrían mantener la independencia y crecer como empresa si los usuarios contribuyeran económicamente al proyecto.

Es el llamado modelo freemium, donde la mayor parte de la funcionalidad es gratis y una parte premium se ofrece a cambio de dinero, y que suele compatibilizarse con otros modelos que cada vez funcionan menos como el de financiarse en base a publicidad.

Estos planes de negocio tienen una efectividad limitada, quizás por lo que comentaba al principio: ¿pagar por un servicio en Internet? El rechazo de los usuarios puede ser tan apasionado como la calidad del producto. Por ejemplo Spotify, que pasó de es maravilloso (está lleno de estrellas) a rasguémonos las vestiduras (malditos) porque la empresa tocó el todo gratis para intentar ser rentable.

Fuera de Internet decidimos pagar por muchos servicios que nos proporcionan valor, pero aquí el todo gratis dificulta las cosas y nos hace tomar malas decisiones, por ejemplo convirtiéndonos nosotros mismos y nuestra información en el producto.

Estaba leyendo la anotación y pensaba: como el Software Libre y el soporte (aunque la mecánica es diferente porque las interacciones con una comunidad no son solo transacciones de dinero por servicios, sino que hay otras formas de aportar).

El caso más claro es el de Red Hat Enterprise Linux y CentOS.

Cada vez que oigo en un contexto empresarial mejor CentOS que es gratis o estando CentOS, ¿por qué vas a pagarle una subscripción a Red Hat?, confieso que no entiendo nada. A parte de la desinformación acerca de lo que se ofrece (parece que se da a entender que se trata de una licencia -cuando no se dice licencia directamente-, los comerciales de Red Hat tienen que trabajárselo más), nadie parece saber qué es CentOS ni de donde viene.

CentOS es una distribución de software basada en el código fuente de Red Hat Enterprise Linux, al que se le quita todo el tema de marcas -que tienen limitaciones legales-, produciendo una distribución Linux que es 100% compatible con el sistema de Red Hat. Esto es perfectamente legal, gracias a que es Software Libre.

Pero igual que Red Hat contribuye mucho al Software Libre, porque debe proteger uno de los principales activos de su modelo de negocio (igual que CentOS se beneficia de RHEL, Red Hat empaqueta y usa mucho software de terceros), ¿por qué las empresas se centran en lo gratis y están dispuestas a prescindir de la parte premium del producto?

No sé cuál es la respuesta a esta pregunta, pero con el retraso de la publicación de CentOS 6 y las protestas de muchos usuarios, intuyo que puede estar muy relacionada con el mensaje y las consecuencias que quiere transmitir la anotación de Ceglowski: si te gusta, contribuye.

»Primeros 20 días con Fedora 16 · En realidad debería ser con Gnome 3.2, pero no quiero darle más vueltas al tema. En general me parece una buena entrega: rápida, funcional, y sin demasiados fallos nuevos. Respecto al escritorio: he descubierto que apenas lo uso, gracias a los atajos del teclado, y ninguna de las novedades en la forma de trabajar me aporta ventajas (aunque sí algunas molestias, algo es algo :P). Más o menos es el mismo caso que con Unity en el trabajo, aunque el escritorio de Ubuntu 11.10 tiene más fallos que me afectan en el día a día, y menos problemas derivados de su diseño. Habrá que esperar 6 meses para ver qué dirección toma cada uno.