martes, agosto 18, 2015

Podcasts/talks. Emptying the queue (I)

I have a long queue of interesting talks, so I'll post the talks links in small batches. Here come the first one.

Interesting Agile/Lean related talks:
Other development/systems related talks:
  • Protocols - The Glue for Applications  (Torben Hoffmann) Very interesting, distributed systems, fault tolerant and the desing process for this kinds of systems (full of advices from the Erlang community).
  • Keys to SRE (SREcon14)  (Ben Treynor) Good description about the term/role of SRE (from the google perspective).

When I empty the talks queue, I'll try the generate this kind of entries more often...

sábado, julio 18, 2015

Ultimo post de la PiWeek VIII

El último día de la PiWeek es una mezcla de nervios para  algunos y de ambiente festivo... La verdad es que en toda la semana me lo paso muy bien, pero el viernes es el día más divertido.

Algunos equipos controlan mejor que otros los nervios y son capaces de trabajar en el proyecto hasta el último minuto, yo no soy de esos y siempre prefiero trabajar con margen y dejar las cosas cerradas el día anterior.

Durante un rato  estuve preparando la demo, aunque no había demasiado que hacer.
Luego comente las notas que tenia del libro ClojureScript Unraveled e incluso creo que Andrey ya comenzó a hacer ciertos cambios a partir de ese feedback.

También tuve algunas enriquecedoras conversaciones, principalmente con David, sobre el coste real de una funcionalidad cuando se trata de un producto software y no de un proyecto que se transfiere a un cliente. También comentamos como hacíamos en Alea Soluciones para poder desplegar con un buen ritmo en nuestras aplicaciones. Le comenté como usaban feature toggles la gente de etsy y de facebook para poder tener un tren continuo de despliegues a producción.

Espero que David me tenga informado de si alguna de las cosas les ha ayudado a mejorar :-)

Sobre la una de la tarde llego el climax de la PiWeek... las presentaciones... como en otras ediciones, las siguientes dos horas y media fueron de presentaciones de unos 10 minutos por proyecto.
El ambiente fue de completa fiesta y de asombro por la calidad de todos los proyectos.

Es una mezcla de fiesta geek, nervios por hacer la presentación del proyecto en el que te has dejado la piel durante esta semana y de tomar notas para investigar las cosas que han hecho en otros proyectos.

Hay que tener en cuenta, que no hablamos de presentaciones powerpoint o equivalente... hablamos de código funcionando o diseños, algo real, palpable, nada de documentos de buenas intenciones...



Todos los proyectos tienen un nivel impresionante, pero lo que más me ha impresionado es el proyecto uxbox, realizado en clojure script. Además de lo bien y fluido que queda el interfaz de usuario, la velocidad de desarrollo que han tenido ha sido impresionante, sobre todo teniendo en cuenta que varios de los miembros del equipo eran la primera vez que trabajaban con ese lenguaje.

Como otras veces, me he quedado impresionado por todo lo que tiene que ver con Frontend, UX, diseño y similar. Toda mi experiencia ha estado siempre centrada en software que no ha requerido parte visual importante (sistemas industriales, backends, telecomunicaciones, retail, ...) así que siempre alucino con los proyectos de la piweek (se nota la experiencia acumulada en software muy visual). En especial en estos temas, me han impresionado Guild Empire, Zombie Time!, Baoqu, Mineralis, etc..

Cada PiWeek es distinta y en cada edición consigues más o menos avances personales, noto que esta edición, junto con la primera a la que asistí, son las que más han aportado a mi avance personal como desarrollador.

Así que otra edición más, reto conseguido...

Referencias:

PiWeek edición VIII (Cuarto Día)


Aunque lo escribo con retraso, este post corresponde al cuarto día (jueves) de esta edición de la piweek.

En el proyecto eventsview avanzamos hasta dejar una versión usable con búsqueda y los filtros activados. Estoy bastante contento, por que aunque no es nada vistoso nos va a valer como base para desarrollos que tenemos que hacer en Alea y que poco a poco voy cogiendo flujo en javascript y en la parte web. Hay que tener en cuenta que en mi día a día no suelo tocar para nada web, por lo que sólo puedo avanzar en este tipo de cosas con proyectos personales, así que algo como la piweek para mi es un "acelerador" para mi aprendizaje.
Una vez más, los consejos sobre usabilidad que  nos ha dado Esther han servido para hacer la interacción con el usuario mucho más sencilla.

En cuanto a expects ya conseguimos tener todos los tests en verde y Jaime se encargo de generar una nueva versión release candidate y de actualizar doublex-expects que depende de expects.
Como mis objetivos para la PiWeek eran darle un empujón a mi aprendizaje de javascript, disponer de una base para desarrollar un visualizador de eventos y ayudar a Jaime a generar una nueva versión de expects, la verdad es que para el jueves a media mañana los objetivos estaban cumplidos...
El truco como siempre es tener unas expectativas bajas y gestionarlas bien ;-)


El caso es que a partir de ese momento me dedique a investigar cosas que me parece que a medio plazo pueden resultar muy interesantes.
Entre otras cosas estuve trasteando con react y creo que puede tener su sitio para crear partes del frontend reusables para la arquitectura de servicios que estamos desarrollando en Alea Soluciones.

También curiosee con clojurescript y la verdad es que me pareció impresionante las cosas que se pueden conseguir. En este caso, creo que si ahora mismo quieres aprender algo sobre clojurescript, tu sitio es la oficina de kaleidos.
En concreto repase un capitulo del libro de  Andrey Antukh y Alejandro Gomez,  ClojureScript Unraveled y tome algunas notas para poder enviarles feedback y pequeñas correcciones.
También trastee con ayuda de Alonso hasta tener una versión de clojurescript decente en mi equipo. Podéis ver las notas de la instalación en https://github.com/eferro/clojurescriptnotes

Me quede bastante impresionado con cómo se puede trabajar con el entorno creado usando https://github.com/bhauman/figwheel-template para crear un proyecto. En concreto el flujo de desarrollo en un proyecto con reagent parece de lo más interesante y el proyecto uxbox de la PiWeek así parece confirmarlo.



Desde luego, para la tarde del jueves ya estaba completamente Agotado!!!! el ritmo de piweek es bastante demoledor.

Referencias:


miércoles, julio 15, 2015

PiWeek edición VIII (tercer día)


Ya estamos en el ecuador de la piweek y parece que todos los proyectos están muy encarrilados... Como siempre se ve un nivel espectacular y además de las cosas en las que estoy metido, suelo intentar curiosear, sobre todo en los proyectos realizados con clojurescript, que tienen muy buena pinta...



Tengo pendiente darle un empujón fuerte a ClojureScript Unraveled el fantástico libro que están escribiendo sobre clojurescript Andrey Antukh y Alejandro Gomez
Me he comprometido con Andrey a leer y dar feedback de la parte de instalación y tooling para ver si es adecuado para alguien que no tenga ni idea (como yo :-) )
Así que mañana le dedicaré unos cuantos pomodoros.

En cuanto a los dos proyectos en los que estoy metido con Jaime, la verdad es que vamos avanzando a buen ritmo.



Eduardo - Piweek from kaleidos on Vimeo.

Con expect ya volvemos a estar en verde después del cambio de diseño para mejorar los mensajes de error :-) (hacia tiempo que no pasaba tanto tiempo con los tests rotos)

En cuanto al visor de eventos, hoy hemos metido gran cantidad de eventos medio reales y hemos realizado las adaptaciones para comenzar con el filtrado. En este caso el avance es mucho más lento, pero como el objetivo en mi caso es aprender javascript y no tanto el resultado final, pues estoy bastante contento.

Una vez más, Esther Moreno nos ha echado una mano con el UX, ayudandonos a aclarar las ideas.
Además, me he aprovechado de estar rodeado de mucho conocimiento para hacer preguntas de novato de javascript y del entorno.

En concreto, creo que era la única persona en el planeta tierra que no sabia que se podia poner un punto de ruptura para arrancar el debugger en el chrome con solo poner "debugger;"

Gracias Alonso, solo por ese detalle puede que ya tenga amortizada la piweek!!!
En otro orden de cosas, hoy en kaleidos se ha hecho una comida especial de piweek, como siempre, ambiente festivo a tope.
El que no se divierte en la piweek es por que no quiere.


Referencias:

martes, julio 14, 2015

PiWeek edición VIII (primer y segundo día)



Una edición más me ha apuntado a la piweek. En esta ocasión me he apuntado a última hora puesto que en principio en estas fechas iba a estar de vacaciones.

En esta ocasión, del equipo de Alea Soluciones, he conseguido liar a https://twitter.com/jaimegil
Cómo sigo con mi cruzada personal por aprender algo de javascript, hemos decido implementar un pequeño visualizador de eventos https://github.com/aleasoluciones/eventsview
No tenemos muchas pretensiones en cuanto a las funcionalidades a realizar, el objetivo en mi caso es seguir aprendiendo, por lo que me importa mucho más tener la mente abierta que realmente tener una funcionalidad interesante.


De momento hemos realizado un pequeño listado de eventos que se va refrescando por ajax y lo hemos separado en dos objetos de vista, un presenter y un repositorio.
Estábamos planteándonos probar a implementarlo usando react (una vez más, sólo por aprender).

Una cosa muy interesante que he aprendido es lo importante que es tener acceso a alguien experto en UX. En este caso Jaime y yo teníamos la idea preconcebida de como queríamos hacer el visor de eventos, pero una conversación de unos 10/15 minutos con Esther Moreno (experta en UX de kaleidos) y hemos cambiado y simplificado la idea que teníamos.  Nos hemos ahorrado un montón de trabajo innecesario y gran cantidad de software a mantener :-)

En Alea Soluciones, nos vendría muy bien contar con algún tipo de "UX as a service" para mejorar la interacción con nuestras aplicaciones, que aunque no es mala, si que se nota que está pensada por un grupo de programadores con buenas intenciones pero a los que nos faltan conocimientos avanzados de UX y de diseño. Concretamente en mi caso, se nota mucho que siempre he trabajado en procesos de backend.

Además del visor de eventos, estamos dándole un empujón a la fantástica biblioteca de asertos expects que usamos al hacer TDD en python.
Está biblioteca creada por Jaime nos permite crear aserciones en los tests al estilo rspec y aunque es muy potente, Jaime  tenia algunas mejoras pendientes que no estaba pudiendo llevar adelante. Así que mejor ocasión que la piweek para darle un poco de cariño.



En esta ocasión hemos comenzado por un cambio interno de diseño para mejorar los mensajes generados cuando los asertos no se cumplen. Este cambio que puede parecer menor, en realidad es muy importante puesto que en este tipo de utilidades los mensajes son los que ayudan al desarrollador a identificar el problema lo antes posible, por lo que sucede como con los lenguajes en que los mensajes de error pueden ser una diferencia significativa en su facilidad de uso...


Esto es lo que han dado de si los dos primeros días de piweek... seguiremos informando


Referencias:





viernes, julio 10, 2015

Bounded contexts en Domain Driven Design


En el AOS 2015 de Gijón me apunte a una Sesión de Diseño con DDD (@carlospeix), se uso un ejemplo del grupo de ddd-es para iniciar una conversación sobre el posible diseño de un pequeño modelo. Después de la sesión, comente con Carlos la importancia que tiene comenzar a aprender DDD centrandose en la division en Bounded Contexts/subsistemas y en el lenguaje de domino de cada uno de estos Bounded Contexts, en vez de centrarnos en modelado estático (entidades y relaciones) que puede derivar en que intentemos modelar de forma global todo el dominio del sistema (con la complejidad que tiene y el riesgo de hacer una megaconstrucción que no se pueda mantener).

Carlos me propuso explicar mi punto de vista en un hangout público...

El hangout lo hicimos ayer y se puede consultar en la página del evento o en el video de youtube que subio Carlos a su canal:



A continuación unas notas y referencias relacionadas...

Domain Driven Design

  • Útil para dominios complejos
  • Nos centramos en el negocio y intentamos modelar el comportamiento y los procesos de negocio con la ayuda de expertos del dominio
  • Usamos el lenguaje de los expertos del dominio
  • Dividimos en bounded contexts/subsitemas
  • Cada bounded context se implementa con el modelo de dominio como parte central
  • Se dispone de ciertos tácticas/patrones para facilitar la implementación de estos bounded contexts (ValueObjects, Agregados, Entidades, Repositorios, Eventos de Dominio,  etc…)

En el libro DDD Tackling Complexity in the heart of software Software en el que Eric Evans presentaba está forma de hacer software, la descripción de Bounded Contexts y otros conceptos para hacer el diseño estratégico aparecen en la segunda parte del libro.
Y entre que el libro es bastante pesado de  leer y que en la primera parte se tocan temas más "divertidos" para los desarrolladores de software, el mensaje general que ha transcendido está mucho más centrado en las tácticas y patrones con el que implementar (agregados, repositorios, etc).


Posteriormente, Eric Evans en varias entrevistas ha comentado que lo central de esta forma de diseño es el lenguaje ubiquo y los bounded contexts.

“Ubiquitous Language and Context Mapping and Core Domain are at the center, with aggregates in close orbit. Why, I ask myself, did I put context mapping in Chapter 14? Core domain in Chapter 15?!” Eric Evans (What I’ve learned about DDD since the book)

Subdomains y bounded contexts

En el DDD exchange de este año Eric Evans y Udi Dahan llegaban a la conclusión que subdomains y bounded contexts tienen un mapeo 1 a 1, siendo los bounded contexts del dominio de la implementación. Así que dicho esto, de forma pragmática se puede considerar como bounded context cada uno de los sub sistemas  que conforman la implementación de un sistema complejo.

Por supuesto cada uno de estos bounded context/subsistemas:
  • tienen su propio lenguaje de dominio (una palabra puede tener distintos significados en cada uno de los bounded contexts)
  • internamente tienen gran cohesión
  • tienen un bajo acoplamiento con otros bounded contexts
  • para implementar cada uno de los bounded contexts podemos tomar distintas decisiones
    • tipo de arquitectura
    • infrastructura usada
    • incluso lenguaje de desarrollo

Por supuesto cada bounded context tiene sus propios datos, no están acoplados usando la misma BD compartida… (eso cae de cajón).

Esta forma de dividir los sistemas es muy compatible con un SOA bien entendido o lo que se está denominando como arquitectura de microservicios. En caso de crear bounded contexts que se comuniquen mediante eventos, también se facilita la creación de aplicaciones reactivas (http://www.reactivemanifesto.org/)

Ejemplo de descomposición en bounded contexts 

Supongamos que estamos encargados de implementar un sistema de venta online de viajes.
Durante el desarrollo nos centraremos en hablar con los expertos del dominio para ir extrayendo los comportamientos, acciones y eventos que se producen el sistema.
Por ejemplo podemos identificar las siguientes acciones:
  • Añadir hotel al catalogo
  • Realizar reserva en una cadena de hoteles
  • Cobrar una reserva
  • Recomendar un viaje a un viajero
  • Registrar experiencia de un viajero en un hotel
  • Generar billetes de avión
  • Cobrar reservas
  • etc...

De estas acciones, de los diversos departamentos de la empresa, de la información que necesita cada acción, de los eventos que se generan podremos ir identificando las los límites entre cada bounded context.
En el caso anterior puede que nos salgan bounded contexts como:
  • Catalogo de vuelos/hoteles
  • Sistema de recomendaciones
  • Contabilidad
  • red social de viajeros
  • ...
La verdad es que como no tengo ni idea de ese dominio, no se si estos bounded contexts tienen sentido, pero para el ejemplo pueden valer. :-)

En cualquier caso debe quedar la clara la importancia de hacer esta división y de implementar cada uno de esos subsistemas de la forma más autonoma posible. Esto permitirá tomar decisiones de forma flexible puesto que lo podremos hacer independientemente para cada bounded context.

Tendremos que decidir el estilo de comunicaciones que vamos a usar entre los distintos bounded contexts y los  patrones generales que vamos a usar en el sistema.
Luego podremos coger cada bounded context e implementarlo con la arquitectura, herramientas y enfoque que sea adecuado al problema a solventar (en vez de forzar un mismo enfoque para todo el proyecto).

Recursos

Por cierto que el resto de videos de Carlos Buenos Vinos sobre DDD están muy bien.

Una última nota

Si os ha parecido interesante y tenéis preguntas no os cortéis a ponerlos en los comentarios o por twitter (@carlospeix @eferro)
Lo mismo si os parece interesante que se hiciesen más hangouts sobre el tema invitando a más gente.

Cualquier opinión será muy bienvenida.