Archivo de la etiqueta: Django

’12 tips on Django Best Practices’ en la PyConES 2013

En Noviembre de 2013 se celebró por primera vez una PyCon en España. La PyConES reunió en Madrid a la flor y nata del panorama Python español. Muchas caras conocidas, y mucha gente por fin desvirtualizada.

Durante ese fin de semana se realizaron multitud de charlas (3 tracks en paralelo durante 2 días), y eventos de la comunidad. Es importante felicitar el excelente trabajo que hizo la organización, asegurándose de que todo transcurriese con normalidad y no nos faltase de nada: ¡todos los detalles estaban pensados al milímetro!. También me sorprendió el gran número de patrocinadores: eso demuestra que Python está en auge 😀

Os dejo con el vídeo y la presentación de mi ponencia, ‘12 tips on Django Best Practices‘:

Además, el reunirnos tanta gente nos ha inspirado para re-lanzar el Python Barcelona Meetup: el propósito de año nuevo es hacer reuniones mensuales.

¡Nos vemos en la Pycon 2014! 🙂

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 😀