¿140 caracteres? ¡A veces puede ser suficiente con un número del 1 al 5! En YourCon puedes indicar el estado actual de cualquier cosa medible usando un indicador inspirado en el DefCon de los EE.UU., popularizado gracias a la película “Juegos de Guerra“.
Pongamos que queremos contar a nuestros amigos qué tal nos va en la ΠWEEK. Creamos un DefCon llamado “ΠWEEK”, que el primer día valdrá 5 (todos empezamos super motivados). El miércoles hemos tenido una dificultad imprevista que nos hace ir más lento de lo esperado, así que lo bajamos a un 3 con una nota explicativa. El jueves vamos como locos intentando tener algo presentable para mañana, lo bajamos a 2 con mucho agobio… el viernes mostramos el proyecto, la demo sale estupenda y hemos ganado la ΠWEEK… ¡de nuevo al 5!
Los DefCon se pueden componer. Yo podría montar mi “molómetro general” de mi trabajo en Kaleidos, compuesto por el DefCon de calidad del trabajo, el del equipo, el del cliente, el de formación y aprendizaje… y el general valdrá la media ponderada de todos ellos. Luego Kaleidos podría crear un DefCon global, agregando los generales de todos sus empleados. Se pueden añadir hashtags para poder crear DefCons que agreguen cantidades grandes de otros DefCons distribuidos. Las marcas podrían crear DefCons que midan la satisfacción agregada de sus clientes. Se pueden crear sensores externos que conviertan en un DefCon cualquier medición automática….
Finalmente, los DefCon se pueden difundir por cualquier red social: se puede publicar el estado actual o el timeline de cambios en nuestro muro de Facebook o Twitter, se pueden hacer avatares personalizados, o widgets para incluir en cualquier blog o web.
El proyecto
Desde la primera edición de la ΠWEEK existía una versión preliminar de YourCon, pero la hemos reescrito entera al estilo más actual que usamos en Kaleidos, disociando el lado cliente (front) de una aplicación de el lado del servidor (back). En el back hemos construido una API REST que proporciona el acceso a los datos usado Python3 + Django 1.7 + Django Rest Framework 2.8 + PostgreSQL 9.4. En front hemos construido una single-page application gracias a la utilización de AngularJS + CoffeeScript + jade + SASS.
El proyecto desarrollado en la ΠWEEK es una versión básica que permite crear DefCons simples o compuestos, cambiar su estádo y ver el timeline propio y el de otros usuarios. A falta de pulir algunos detalles, el objetivo a corto plazo es montar una instalación de YourCon para uso interno en Kaleidos, y si vemos que resulta interesante, seguir desarrollando el producto para el exterior, en la línea que ya hemos seguido con Bokzuy o el propio Taiga.
Para el front hemos usado la misma tecnología que en Taiga. De hecho, hemos copiado mucho código de ese proyecto. Lo cual ha servido para comprobar que ese código es bastante modular y reutilizable. Pero por otro lado, al haber partido de una copia total de Taiga, sin haber tenido tiempo suficiente como para extraer bloques aislados, ha generado una gran proporción de “código muerto” que se deberá eliminar de inmediato para poder continuar con el desarrollo del cliente además de haber relentizado el desarrollo.
En cambio el back ha sido reescrito desde cero usando un esquema DDD estricto, haciendo la lógica de negocio un módulo completamente independiente del framework, e implementando la persistencia y el API REST como módulos separados. La experiencia ha sido muy informativa, aunque el resultado ha tenido diferentes interpretaciones.
La decisión de poner toda la lógica de negocio en un módulo propio con un interfaz explícito ha sido claramente positiva. En cambio el tener entidades de negocio separadas de los modelos del ORM de Django presentó dos cuestiones. Una es que las entidades aisladas son una capa de abstracción más por encima del ORM, lo cual siempre añade complejidad; aunque usando algo de magia de Python y Django se ha conseguido que la capa sea muy ligera. La otra es más complicada: al aislarnos del framework no se pueden usar algunas utilidades de Django y su ecosistema de aplicaciones, como por ejemplo los ModelViewSet, ModelSerializer y la paginación de Django Rest Framework.
Esto supone un compromiso que hay que evaluar en cada proyecto, dependiendo de los pesos que tengan las diferentes necesidades en cada caso. Nos gustaría mostrar el resultado al resto de Kaleiders, y comparar esta versión de DDD con la usada en otros proyectos, seguro que puede salir un buen debate de aquí con el que mejorar nuestras conslusiones y asentar nuestras posturas.
En resumen, nos hemos quedado un poco con las ganas de haber presentado en la demo un producto un poco más elaborado, pero ya habrá tiempo de seguir desarollándolo para darle un uso real. Y en cuanto a la ΠWEEK, nos parece que se sigue superando edición a edición, con proyectos muy interesantes y útiles.