Diario #1

2017-10-05

Diario #1

Este es el primer post de lo que pretendo que sea un registro de cosillas que voy aprendiendo durante las semanas. Además trato de usarlo no solo como un recordatorio personal sino también como una forma de desarrollar el hábito de escribir en mi blog. Debo agradecer a Edu por su recomendación.

CQRS

Esta semana gracias a una conversación con Modesto y Miguel, he comprendido el valor que te puede aportar modelar los comandos como parte de tu negocio. Es decir, tener un objeto que represente a un comando (que pudiera ser fácilmente serializable). Hasta ahora, normalmente había entendido los comandos como algo conceptual. Solía pensar en ellos como acciones (bajo el paraguas de IDD), un servicio de dominio de DDD con un método execute (este sería mi command conceptual). Modelar el comando como un objeto del modelo, considero que tiene dos ventajas:

  • Modelar en tu negocio un concepto que es tan importante como los eventos
  • Pasar ese comando a otro servicio en un futuro sería más sencillo

Puesto que modelar ese comando no supone un incremento notable en complejidad y es relativamente barato, lo veo un gran aporte que podré poner en práctica a partir de hoy.

Ember-Redux

Estamos empezando a meter Redux en nuestra aplicación web. Estos últimos meses hemos estado tratando de desacoplar nuestro frond-end del framework que estamos usando, en este caso Ember. La razones principales son:

  • Queremos pasar a usar una librería como Glimmer, React…
  • Queremos ser más dueños de nuestra arquitectura
  • Nos simplifica el testing
  • Reducimos complejidad accidental
  • Queremos menos magia

Redux nos permite tener bastante lógica asociada al estado fuera del framework. Esto nos favorece porque tenemos componentes que están al mismo nivel de jerarquía que necesitan compartir estado. Por tanto, se nos ocurrieron varias opciones: crearnos un router propio, crearnos nuestro propio gestor de estado o usar redux. Así que curiosamente, la complejidad que mete redux, nos pareció la más sencilla de nuestras opciones. Excluyendo los propios componentes de Ember, el resto del código sería similar a lo que escribiríamos con la dupla React/Redux por ejemplo.

Por último, resaltar que Redux no es algo que usaremos en todos nuestros componentes. De hecho, la necesidad de usar único estado compartido es que nos han surgido componentes al mismo nivel de jerarquía que comparten estado. En el resto de casos seguiremos teniendo componentes de Ember que serán dueños de su estado y lo pasarán a sus componentes hijos.

PyConES2017

Algunos compañeros de TheMotion estuvimos en la PyConES2017. Las charlas que más me han gustado de las que he asistido son:

  • Metaclases. Una charla muy chula que te ayuda a entender como Python está construido. El mensaje principal de la charla fue que los objetos son para las clases, lo que las clases son para las metaclases. Así mismo, destacaron que los casos de uso para las metaclases son muy reducidos, generalmente escenarios en los que necesitas crear clases en tiempo de ejecución. El ejemplo más común es un ORM. No sé si algún día lo usaré, pero está bien saber que están ahí.
  • Herramienta para ser un experto en Pyton. Presentaron una herramienta bastante chula que detecta cuánto de pytonico es el código dado un repositorio de github. Considero que es muy útil si estás aprendiendo Python, pero no lo usaría como una herramienta para evaluar la calidad del código. En mi opinión, la calidad de nuestro código depende de muchos otros factores que considero más importantes: testing, principios de diseño, simplicidad…

Mob programming

Hablando con los compañeros de OCOSO surgió el tema de cómo ellos aplicaban Mob Programming. La idea principal es que el driver no piensa y se dedica a escribir lo que los navigators le dicen. De manera que, si el driver quiere intervenir en el debate, ha de pasar el teclado a otro. Todos los que hemos hecho mob alguna vez, sabemos la presión que se siente cuando estás de driver en ocasiones. La reflexión de ellos es que esta modalidad ayuda a que el driver no se sienta presionado.

Literate Programming

Literate Programming es básicamente un paradigma de programación que te permite crear documentación interactiva que incluye código que compila. Podríamos tener documentación que ejecuta código real. He encontrado esta librería de python

Extra

tox.
Pharo Smalltalk. Muchas ganas de probarlo, según los de OSOCO me reventará la mente :-P
Concourse CI.
Guide To Python.
Guía para actualizar Ember
Breaking Up The Benemoth, Sandi Metz