La plataforma de reconocimiento de imágenes de Catchoom

Durante los últimos meses he estado trabajando en el Catchoom Recognition Service. Aprovechando que acabamos de rediseñarlo por completo, voy a explicar un poco de qué va el proyecto. Antes de nada, te invito a probarlo:

  1. Registra una cuenta gratuita, y probando la plataforma de Image Recognition:

    catchoom_recognition_service

  2. Usa la librería Python (catchoom-python), para integrar las APIs. Aunque no uses Python (ehem, empieza a usarlo ;-)), puedes aprovechar las herramientas de subir/reconocer imágenes y las imágenes de ejemplo.
  3. Visita la nueva web Catchoom.

Agradeceré mucho las opiniones, críticas y sugerencias :-)

 

¿Qué es el “Image Recognition”?

Básicamente, el reconocimiento de imágenes consiste en enviar una foto (por ejemplo, desde el móvil), compararla contra una base de datos de imágenes de referencia, y reconocer qué objeto aparece en esa foto.

A partir de ahí, los retos están en hacerlo lo más rápido posible (<0.5s), mejorar la detección (varios objetos en la misma imagen, imágenes borrosas/distorsionadas, 3D…), asociar metadatos a cada objeto (cada cliente tiene necesidades distintas), ofrecer estadísticas de uso, y, en general, tener una plataforma segura, escalable y automatizada.

Vale, ¿y para qué sirve el reconocimiento de imagen? ¿Qué se puede hacer con esto? Pues lo que se te ocurra:

  • integrarlo en aplicaciones móviles para reconocer logotipos o marcas comerciales
  • añadirlo a un videojuego para reconocer objetos (y darte bonus dentro del juego)
  • reconocer objetos para aplicar realidad aumentada encima, utilizarlo para reconocer cuadros, edificios, portadas de CDs, catálogos/revistas…
  • o, mi uso favorito: sustituir (y enterrar) a los códigos QR 😉

Catchoom rediseñado

Arquitectura de la plataforma de Catchoom

La plataforma está implementada en Python, los componentes usan Django, Tornado y Gevent. Toda la infrastructura está en Amazon Web Services.

A destacar, usamos Redis para varios servicios. Expliqué las ventajas de usar Redis en el NoSQL matters@Barcelona2012, el pasado Octubre, así que puedes ver el vídeo:

Y la presentación: (inexplicablemente llegó a portada en Slideshare, de ahí las visitas)

 

Gracias de antemano por probar el reconocimiento de imagen de Catchoom, espero tu feedback 😀

Python y la Arquitectura web de Flumotion

De vez en cuando hay gente que me pregunta por la arquitectura de los servicios web de Flumotion. En este artículo voy a tratar de  hacer una breve explicación técnica, empezando con los servicios web principales y acabando con los servidores.

Servicios:

En primer lugar hay que destacar que casi todo en Flumotion está hecho en Python, así que la elección para los servicios web era fácil. A las ventajas intrínsecas de Python (mantenibilidad del código, desarrollo rápido, gran cantidad de librerías, menos magia, etc) se le une la facilidad de integración con el resto de los componentes de la plataforma.

Flumotion.com es el típico web corporativo. Es un CMS multi-idioma, con algo de lógica específica. Utiliza DjangoCMS y un par de apps Django a medida.

Flumotion MediaConsole es el portal de cliente desde donde los usuarios pueden previsualizar contenidos, parar/arrancar flujos y componentes, gestionar la publicidad, alertas, seguridad (IPs autorizadas, tokens), etc. Destaca la sección de estadísticas, con todo tipo de métricas, filtros y consultas.

Los retos principales eran la complejidad de la gran cantidad de features, garantizar la accountability (saber en todo momento quien ha ejecutado qué, detectar los errores antes que el cliente, etc), y  la importación automatizada de todo tipo de datos (de bases de datos y ficheros de configuración existentes).

Es un típico proyecto Django, con unas 15-20 aplicaciones bastante independientes entre sí. Utiliza su propia base de datos MySQL, aunque también accede a varias bases de datos externas. Para la importación, muchas fixtures. A destacar: se implementó hace tres años (2009), cuando no existían el multidatabase de Django 1.2, ni South, ni Sentry ni todas esas cosas que hoy en día facilitan tanto la vida 😉

Enthalpy se encarga de consolidar los logs de las sesiones de la plataforma y generar las estadísticas.

El primer reto era hacer un sistema escalable y distribuido, ya que su antecesor era centralizado – y se quedó corto: en ocasiones tardaba más de una hora en consolidar una hora de datos. El segundo reto era optimizar el espacio en disco: estamos hablando de una base de datos que crecía 300-400 GB al mes (truco: guardarlo en formato ARCHIVE te ahorra un orden de magnitud).

Está implementado en Twisted (Python asíncrono), utiliza MySQL con SQLAlchemy (excepto para las queries más pesadas, implementadas directamente en SQL). Ahora mismo se ejecuta en cuatro máquinas, que suman varios teras de datos consolidados.

Flumotion Backoffice es el portal de administración interna. Se usa para integrar y configurar los servicios de la plataforma de streaming. Utiliza Django y SQLAlchemy y está integrado con los servicios internos: LDAP, bases de datos, plataforma.

Livetranscoding Manager es (era) el portal de cliente de Livetranscoding.com. Desde allí el cliente podía comprar servicios (streams), inicializarlos (se arrancaban las máquinas en la nube, en tiempo real), previsualizarlos y configurarlos. Livetranscoding soportaba muchísimos formatos (a varias resoluciones, multi-bitrate…), y permitía elegir el CDN de salida.

Utiliza Django con Twisted, MySQL, South, y Fabric. Como todo tiene que ser asíncrono y a tiempo real, utiliza un sistema de colas (RabbitMQ) y, para comunicarse con el navegador, websockets.

Flumotion WebTV (también conocido como Online Video Platform) es la plataforma de TV y radio online.

Desde el punto de vista técnico, imagínate un clon de Youtube… pero con muchísimas más features, muchas opciones para gestionar la publicidad, mucha flexibilidad (cada cliente lo quiere un poco distinto), y una API potente que haga todo eso.

Utiliza Django, MySQL, South, Fabric, Celery, Sentry. Optimizaciones para escalabilidad web: memcache a varios niveles, servidores de estáticos a parte, balanceo de carga por DNS  entre máquinas de un cluster (actualmente hay dos clústeres).

Flumotion WebTV Backoffice es el portal desde donde el cliente gestiona su WebTV. Destaca entre las demás por que no está hecho en Python, sino en Flash (en el framework Flex). Internamente hace llamadas a la API de WebTV.

Servidores:

Para el hardware, usamos nuestra propia infraestructura. La plataforma de streaming está compuesta por varios cientos de máquinas, en centros de datos por ciudades de todo el mundo.

  • El sistema operativo es Red Hat.
  • Como servidor de aplicaciones usamos Gunicorn.
  • Para controlar las instancias de Gunicorn, Supervisord.
  • Como servidor HTTP, nginx. Redirige al servidor de Gunicorn, y también lo usamos para servir los estáticos.
  • Nota: anteriormente usábamos apache+mod_wsgi, era más difícil de configurar y menos eficiente que nginx+gunicorn.
  • Se usa virtualenv para gestionar la gran cantidad de servicios y versiones. De lo contrario, sería un caos de dependencias.
  • Para el control de versiones, git (algún proyecto antiguo sigue en svn). No hacemos paquetes para web, sino que desplegamos directamente a partir de un tag o una rama.
  • Para desplegar nuevas máquinas, o bien cambios de configuración, Puppet.
  • Integración continua con Buildbot.
  • Todas las bases de datos son máquinas dedicadas con MySQL, y las más críticas están en réplica master-slave.
  • Para la cache, memcached por todos los lados.

Si hay cualquier duda o pregunta, por favor deja un comentario :)

FOSDEM 2009: fotos y video

El pasado mes de Febrero asistí al FOSDEM 2009, junto a los compañeros de Flumotion.

Podéis encontrar algunas fotos en este set de flickr.

DSC02858

Además, Anika de Linux-Magazin Online nos entrevistó y aprovechamos para hacer un poco de recruiting :-)

Podéis ver el video original en linux-magazine.com o en linux-magazin.de, o bien la versión “recortada” que hay a continuación:


Flumotion at FOSDEM 2009

Flumotion mola: desarrollamos en Python (Twisted, Django), tenemos friday project y futbolín, y además nos pagan el viaje al Fosdem. ¿Que más se puede pedir?

Si lo he pintado bien, y te interesa la oferta de trabajo, puedes enviarme tu CV 😀

Migración del blog

Como comentaba el otro día, he cambiado de hosting. Antes de nada, por favor suscribiros a la nueva dirección del RSS (la actual se mantendrá durante un tiempo, pero no garantizo que siga funcionando para siempre).

El cambio ha sido a mejor: el servidor compartido de Dreamhost daba una pings muy altos para España, una latencia horrible a la hora de gestionar por SSH, lentitud en servir las páginas, etc. Ahora este blog (y el resto de mis servicios) estan alojados en un servidor dedicado OVH, y la mejora en velocidad se nota muchísimo.

Me han pedido que hable de la migración, así que haré un resumen. En mi caso, fue complicado porque hice tres migraciones a la vez:

  • Migración de servidor: No es excesivamente complicado: guardar los backups de cada proyecto, hacer dumps de las bases de datos, y restaurarlo en el servidor nuevo. Además, configurar en la máquina nueva los vhosts de apache y redireccionar los DNS para todos los dominios.
  • Migración de directorio: Anteriormente el blog estaba en http://www.davidarcos.net, mientras que ahora está en http://www.davidarcos.net/blog. Mediante reglas de .htaccess logro una redirección transparente, los enlaces externos existentes siguen llevando al artículo que toca y, como devuelve el código 301 (Moved Permanently), los buscadores no me penalizan por el cambio de URL. Por ese motivo el RSS antiguo sigue funcionando, aunque seguramente vuestro lector de feeds os habrá devuelto un montón de noticias antiguas, lo siento. Insisto: actualizadlo, que algún día dejará de funcionar.
  • Migración de versión de WordPress: esta tenía bastante riesgo, pues estaba usando una versión muy desactualizada, no existían los tags ni los widgets, contenía varias tablas generadas por plugins (algunos incluso parcheados por mí…). Para hacer la migración no he seguido los pasos “clásicos” (restaurar backups y dumps, desactivar plugins, instalar versiones nuevas, etc), sino que he aprovechado el exportador/importador de WP. Los pasos a seguir:
    1. Antes de nada, eliminar todos los comentarios de spam. Esto servirá para aligerar muchísimo el tamaño del fichero resultante (con spam, ocupaba unos 20 Mb; sin spam, alrededor de 1,5 Mb)
    2. En el blog “antiguo”, exportar mediante el gestor de WP. Se exportan entradas, páginas, categorías y comentarios.
    3. Descargar la última versión de WP, e instalarla. Ya tenemos blog nuevo.
    4. Ir al importador, e importar el archivo generado en el paso 2. Nota: el tamaño máximo del archivo es de 2Mb, así que es muy importante haber eliminado el spam. Si aún así se supera el tamaño, hay dos opciones: partir el archivo en varios (es XML, no es difícil), o bien modificar el código para que nos permita tamaños superiores a 2 Mb (tampoco es difícil, pero hay que ponerse el sombrero de sysadmin).
    5. Descargar la última versión del tema (yo  uso vSlider 3.2), configurarla, añadir plugins y widgets a discreción.
    6. Sorpresa: el blogroll no se ha importado en el paso 2. Para importar, utiliza el formato opml: investigando un poco, resulta que el propio WP genera ese formato en /wp-links-opml.php.
    7. Los tags y yo teníamos una pelea pendiente. Por suerte WP trae de serie un componente, el wp-cat2tag, que como su nombre indica sirve para convertir las categorías existentes en tags. Funciona sin problemas. ¡Por fin una nube de etiquetas como el FSM manda!
    8. Me olvidaba, ¿te has fijado en la cabecera del blog? 😉

La actual versión de WP funciona de maravilla, parece se acabaron las sorpresas de incompatibilidades con plugins. Tenía previsto abandonar WordPress y migrar el blog a ByteFlow (un blog programado en Django), pero se ha ganado la amnistía. Es una lástima, justo ahora que me he commiteado la traducción de Byteflow al español

Ya he tenido suficiente migración por una temporada. Lo próximo que haré será montar un entorno de desarrollo/producción de Django, y en cuanto tenga tiempo ir programando alguna cosilla. Por cierto, se aceptan ideas en los comentarios :-)