El Chumby

Chumby es adorable. Y no solo porque sea blandito como un peluche o porque puedas elegir los tonos de su carcasa de piel entre negro, perla o caramelo. Chumby, además, está construido sobre componentes y conceptos francamente atractivos:

• Por su aspecto y tamaño parece una radio despertador pero gobernado por un potente microprocesador con interacción del usuario vía pantalla táctil y conexión Wifi para el resto del mundo.
• Su hardware es de fuentes abiertas que no quiere decir que mañana puedas ponerte a fabricar y vender réplicas pero si comprenderlo y ampliarlo (hacking). Los esquemas (que incluyen hasta el patrón del forro para que puedas personalizar su aspecto) son públicos bajo las condiciones de su licencia HDK.
• En cuanto a periferia, la pantalla táctil es una TFT-LCD de 3 /2” con resolución QVGA. El resto: dos altavoces de 2W, salida estéreo, micrófono integrado, dos puertos USB, acelerómetro (en plan Wii) y un sensor que detecta los golpecitos que das en la parte superior del Chumby.
• En cifras: microprocesador ARM9 a 350 MHz con 64 MB de SDRAM y 64 MB de ROM flash.
• El sistema operativo, como no podía ser de otra manera, está basado en la distribución Linux de ARM de modo que propaga la licencia de GNU. También incorpora la versión 3.0 de Adobe Flash Lite 3.0.

Por tratarse de GNU, cualquier desarrollador puede programar pensando en Chumby. Uno se imagina la documentación de mil páginas de la API para escribir código en C durante las largas tardes de invierno. Sin embargo el desarrollo de pequeñas aplicaciones o widgets para Chumby se apoya en el reproductor de Adobe incluido en el producto. Una película Flash que cumpla las restricciones de tamaño en pantalla y que sea compatible con Flash Player 8 “debería” funcionar perfectamente en Chumby.

Otro elemento ingenioso en su política de desarrollo es que toda la administración de Chumby se realiza vía Web. Basta con conectar Chumby a Internet por Wifi (encenderlo) y entrar con un navegador desde un PC en su sitio web para descargar cualquiera de los widgets disponibles. Estos widgets incluyen, visores de noticias, de información meteorológica, relojes, calendarios, sitios sociales o juegos entre otros.

Para cargar tu propio widget basta con dejarlo primero en el sitio y descargarlo después en el Chumby mediante el procedimiento descrito.

Fue mi colega Alex quien me hablo hace un par de años del Chumby y quien hace un par de meses me animó a desarrollar un widget basado en Rockola.fm. Visto lo anterior y pensando que la cosa se limitaría a comprimir un poco nuestra interfaz me animé a intentarlo.

El Chumby no puede adquirirse desde fuera de los EEUU así que recurrí a otra fuente que se empeño en hacérmelo llegar en un sobre plano, previo desmontaje, en lugar de utilizar el embalaje original

Después de casi dos meses de espera, que merecen su propio post, Chumby llegó a la oficina. Siempre que abordo un nuevo desarrollo empiezo realizando una prueba de concepto. Esta prueba consiste en construir algo pequeño pero que suministre la funcionalidad más importante entre las esperadas incidiendo especialmente en los factores de riesgo. Con eso, se pueden cambiar radicalmente estrategias con un gasto pequeño de energía. En este caso, la funcionalidad más importante es reproducir audio y el factor de riesgo más delicado saber si el Chumby podría realizar una descarga http progresiva de un fichero mp3 con más de 3 Mb de información.

Quince minutos entre codificar el widget, probar en un navegador, subirlo a su sitio, bajarlo al Chumby y comprobar el resultado:

En segundo plano el widget “sonando” sobre la simulación que proporciona el sitio. Más cerca, el Chumby real sin decir ni “pio” ¿qué pasa?

El prototipo funciona desde mi Firefox con la versión 9.0 del Flash. Sin embargo, no suena nada en el Chumby. Una vuelta por los foros de desarrollo y resulta que el Flash Lite no es capaz de interpretar ficheros de audio en descarga progresiva. No conozco exactamente la razón pero probablemente se deba a un problema de licencias con el formato.

Sin embargo, no pienso rendirme tan fácilmente ya que el Chumby incluye aplicaciones no basadas en widgets de Flash que conectan con servicios de streaming como Icecast. Lo que si me temo es que tendré que revisar las mil páginas de la API.

Egosurfing rockolero o “Mamá, mira cuántas veces salimos en Internet!”

No podía más. Tenía que hacer este post después de ver que salimos en un vídeo chino! (supongo que es chino…).

Rockola.fm un vídeo en chino

No entiendo ni palabra, lo mismo nos están poniendo a caer de un burro, pero noooo, no creo, tienen cara de buenas personas :-). Aquí está el vídeo completo (hacia el minuto 3:35 es cuando hablan de Rockola.fm).

En este post recojo algunas de las referencias que hemos ido encontrando en Internet a Rockola.fm desde más o menos marzo de 2008 hasta ahora.

Desarrollo (Sistemas I)

Un número razonable de años (tampoco tantos) te da la ventaja de haber probado muchas cosas y tener perspectiva para comparar. De hecho, descubrí los sistemas abiertos, o “el lado oscuro”, hace relativamente poco, como cinco o seis años, después de una larga temporada en el lado luminoso.

Tras este tiempo sigo sin entender la defensa de algunas soluciones en base a términos como el TCO. Algo así como “Si, si, ahora es gratis pero ya verás a la larga”. Igual esto será aplicable para sistemas heredados, sobre los que no has tenido control, o cuando el equipo humano con el que cuentas necesita apoyo vía consultoría o vete tú a saber.

Como experiencia real en Rockola.fm el coste en ingeniería de sistemas, donde incluyo la localización de productos, pruebas de concepto, cambios de idea, integración, esto no vale… probemos otra cosa, y puesta en producción; ha estado controlado hasta el escándalo. Nada que ver con el equivalente en el lado luminoso.

Y esto no es sólo aplicable a la implantación de la solución final, también lo es en otros lugares como en la gestión del proyecto, el desarrollo, las pruebas, la depuración y la monitorización.

A partir de aquí puede que el texto se vuelva un poco críptico pero nada que no se pueda aclarar vía comentarios al post. Se trata de algunos ejemplos de uso de herramientas útiles y libres que empleamos en Rockola.fm durante el desarrollo de aplicaciones.

Desarrollo, pruebas integradas y preproducción: si, son equipos de sobremesa pero con doble procesador, la memoria a tope y sus discos duros en RAID 1

Crear instancias independientes del Apache es fácil de modo que durante el desarrollo disponemos de nuestro propio entrono de ejecución. Los desastres que puede provocar uno no afectan al rendimiento del resto aunque tu código te mande directo al hiperespacio.

Subversion es perfecto como sistema de gestión de versiones pero también es el eje central para nuestra metodología de pases entre entornos. Desde que salimos en febrero de 2008 todos los pases han sido “en caliente” y sin un solo error gracias a que los scripts de automatización eliminan todos los posibles puntos de fallo.

El entorno de pruebas integradas permite validar la calidad funcional del desarrollo pero para verificar que no hay fallos por inconsistencia con la arquitectura de sistemas necesitamos un entorno lo más próximo al de producción. Que mejor que el VMware (versión libre para Linux) con seis máquinas virtuales para simular alta disponibilidad y balanceo en http, base de datos y streaming.

¿Para que gastarse tres o cuatro mil euros en hardware en preproducción cuando puedes simular balanceo de carga por software mediante Pen y sin pérdida apreciable en el rendimiento?

Monitorizamos, igual que en producción, con Nagios que nos proporciona alertas por correo electrónico y SMS en los casos críticos. Analizamos gráficamente el comportamiento de nuestros sistemas mediante Cacti.

En cuanto a las copias de seguridad, usamos LVM, tenemos configurado un snapshot cada dos horas y una copia diaria con retención de una semana sobre un dispositivo de almacenamiento externo.

Siempre hay quien prefiere usar Windows en su puesto de trabajo. Como no somos talibanes, una instancia de Samba y a correr.

No son más que ejemplos (me dejo otros por describir como la gestión de incidencias, el wiki de proyecto, las VPN, el LDAP y un largo etc) pero tal vez lo más interesante del software libre es el código abierto cuya peculiaridad queda bien descrita en el ensayo La catedral y el bazar. Aclaración con un simple hecho:

Actualmente nuestro gestor de base de datos es MySQL en alta disponibilidad. Se trata de un cluster de dos servidores en el que sólo uno da servicio. El otro replica la actividad del primero y toma el control en caso de fallo. Estamos probando un modelo que incluya también balanceo de carga basado en Pen. La idea es que las operaciones de consulta se realicen sobre cualquiera de los servidores. Sin embargo existe un problema de sincronismo que no garantiza el éxito de las órdenes de lectura sobre datos que acaban de escribirse. En otras circunstancias, esto hubiera sido motivo suficiente para buscar otra solución. Sin embargo, Google tiene en marcha un proyecto (google-mysql-tools) que resolverá este problema. Esto sólo es posible en el lado oscuro.

Catalogación u opinión

Si sacara mi colección de CDs del trastero estoy seguro que podría recordar mirando las carátulas como conocí a cada grupo. Casi siempre por la recomendación de algún amigo con el que compartí gustos musicales o por descubrirlos escuchando la radio tradicional. Una vez alcanzado el nivel de saturación, un buen taco también cayó simplemente por compartir estante en la tienda de discos con otros que ya conocía.

Estos motivos, evidentes y aplicables a todo el mundo, siguen siendo perfectamente válidos pero con un cambio radical en su contexto. La radio ya no es preceptora de música e Internet tiene capacidad, a partir de la pura interacción, para localizar, además de a mis amigos, a otra gente con mis gustos.

Al sintonizar cualquiera de las radiofórmulas disponibles en el dial te encuentras con la repetición constante de los éxitos de los noventa e incluso de los ochenta. La única posibilidad de sorpresa está en los programas especializados de los que van quedando pocos.

Y todo esto a pesar de que nunca ha habido tantos artistas produciendo obra musical como ahora. Por no hablar del “fondo histórico”… la última vez que descargue CDDB creo recordar que contenía unos dieciséis millones de registros.

Allá por abril de 2007 Joaquín Guzmán y Carlos de Otto me pidieron que les ayudara con la definición de la solución tecnológica (y más tarde el desarrollo) de un proyecto de música a la carta en Internet. Fui a nuestra primera reunión de trabajo con algunas ideas sobre el aspecto de la interfaz para que un usuario pudiera seleccionar temas y componer sus play-lists. Cosas como introducir el título del tema mediante escritura predictiva o navegar por la jerarquía artista–álbum-tema. Tiempo perdido.

Carlos y Joaquín estaban ya dos o tres niveles por encima y habían profundizado en el análisis con el que comienza este post. Se trataba de construir un sistema que, partiendo de lo que el usuario conoce, le suministre eso mismo y además recomendaciones profesionales (espíritu radio), recomendaciones de otros usuarios (esos amigos con los que comparte gustos) y similitud técnica (los del mismo estante, vaya).

Indudablemente, el peor de los escenarios posibles. Una solución de recomendación guiada por la opinión del resto de usuarios tiene una gran complejidad técnica pero una vez resuelta son los propios usuarios quienes realizan el trabajo. Una solución de recomendación guiada por criterios profesionales y técnicos es mucho más simple técnicamente pero requiere catalogar uno a uno cada tema del repertorio. Para complicarlo todo, los tres habíamos leído La Larga Cola con lo que el problema además de ser difícil en la dimensión cualitativa también lo es en la cuantitativa.

Los proyectos de catalogación son arriesgados. He tenido la fortuna de participar en algunos de gran éxito (repertorio legislativo y jurídico de la Editorial Aranzadi o Enciclopedia Universal de Micronet) y la mala suerte de otros absolutos fracasos (que no mencionaré aquí por lo del tejado y la piedra). Además, no existe la posibilidad de “tirar de talonario” ya que todas las iniciativas en este sentido están orientadas a lo que antes era la “mínima unidad de venta”. Es decir: el CD o el LP. No tengo constancia de productos comerciales de calidad que lleguen al nivel de “track”. Afortunadamente, el proyecto cuenta con un experto en estos temas como Joaquín Guzmán (con parte de sus tareas hechas) de modo que con eso y la experiencia en otros proyectos de catalogación (curiosamente, Carlos no conocía esta faceta cuando me llamó) asumimos el reto:

Litos enfrentándose a nuestra interfaz de administración (todo un proyecto de desarrollo en si mismo) y sin quitar ojo del DFD (pegado en la mampara a la izquierda del monitor) que describe el proceso.

Ya llevamos un año catalogando temas y el proceso se ha ido perfeccionando en todo este tiempo. Aún queda mucho por hacer pero nuestro equipo de catalogadores es cada vez más efectivo y el número de temas en Rockola.fm continúa creciendo semana a semana. Además, Joaquín ha tenido la habilidad de hacerlo crecer horizontalmente de forma que el crecimiento vertical promete ser espectacular.

Describiré en un futuro post la forma en la que hemos unido, en un solo sistema, los dos métodos de recomendación.