jueves, 20 de diciembre de 2018

Consideraciones para multihilo

Un buen post para adentrarse en el mundo del multihilo sin liarla parda:


Bueno... asumámoslo, la vas a liar parda de todas maneras pero al menos tienes un buen comienzo para averiguar la que has liado y cómo arreglarlo. ;-)

miércoles, 12 de diciembre de 2018

The big idea is messaging

Esta es la continuación de la entrada enterior.

Pues sí, mensajes; el concepto más importante de la P.O.O. y el más ignorado y olvidado tanto por desarrolladores como por los diseñadores de lenguajes de programación O.O. Y eso es una pena porque los mensajes aportan un cosa imprescindible: Contexto. Y ese contexto es lo que nos permite diseñar agregados que no tengan que ser elementos persistibles y que no filtren detalles de su implementación.

viernes, 7 de diciembre de 2018

Los agregados no son elementos persistibles.

Si habéis leído ciertas entradas en este blog; alguna vez me habréis visto comentar que hacer que un agregado sea un elemento que se guarda en persistencia a bloque (y por ende se lee de persistencia a bloque) es un detalle de implementación que no es obligatorio y no debe afectar al diseño del agregado ni que este dependa del esquema de persistencia.

viernes, 30 de noviembre de 2018

Ambiente tóxico

Voy a enumerar unas cuantas situaciones que desprenden tufo a lugar de trabajo tóxico; esto incluye management y compañeros de trabajo gañanes. Si más de uno de ellos te es familiar en el lugar donde estás trabajando ahora:


viernes, 31 de agosto de 2018

WebForms Dependency Injection

Entrada dedicada a Micha-kun; último bastión de defensa de WebForms; quien, según la fecha de su última entrada en su blog, esta MIA. Sospecho que los EmeUveCeros lo han raptado y lo tienen en una especie de Guantanamo tecnológico en Silicon Valley lavándole el cerebro.


Ahí lo tenemos! Los sueños húmedos de la especie en extinción de desarrolladores de WebForms hechos realidad.

Micha; si te escapas, te conectas a Internet y lees esto; deja un mensaje en los comentarios con la esteganografia necesaria como para encontrarte y traerte de nuevo al excitante mundo de los WebForms.

miércoles, 1 de agosto de 2018

Hidratar agregado con event sourcing.

Esta entrada, al igual que las anteriores (las que van entre ésta y ésta), es generada por la conversación que tuve con unos desarrolladores de software hace no mucho.

Cuando comentábamos los pormenores de la implemntación de un pequeño test de código, uno de ellos hizo un comentario con terribles implicaciones; puesto que denota una falta de profundidad en el entendimiento y comprensión sobre agregados, eventos y event sourcing (ES).

miércoles, 11 de julio de 2018

Los eventos nunca fallan III

Épica la transparencia de la charla de ClearMeasure de Jeffrey Palermo con respecto a los "fallos" de los eventos:


viernes, 6 de julio de 2018

Los eventos nunca fallan II

Me han puesto un ejemplo de un "fallo" de evento y creo que ya entiendo algunos de los casos por los que alguien puede llegar a creer que un evento falla. Vamos a ello.

jueves, 5 de julio de 2018

Los eventos nunca fallan

Seguro que cuando has leído el título has pensado: "!Y un huevo que no!". Déjame explicarme un poco más para que se entienda el título de esta entrada.

Hace poco he charlado sobre arquitectura con otro desarrollador de software y me hizo un par de preguntas que no tienen sentido sobre que pasa cuando falla un evento que me dejó bastante mosqueado con respecto a si ese desarrollador tiene completamente claras las cosas o tiene algún concepto que le baila un poco y no está del todo encajado en el puzle.

miércoles, 4 de julio de 2018

Meditando un test de código.

Hace poco he realizado un test de código y he discutido los pormenores de la implentación con otros desarrolladores de software. Como en medio de una conversación en tiempo real siempre es más complicado estructurar tus pensamientos y materializar en palabras lo que la experiencia en un tema te da; en forma de "feeling in the guts"; voy a poner aquí mi posicionamiento de la implementación al respecto para estructurar mis propios pensamientos y mejorar mis dotes debatidoras, que son un poco patéticas y de paso puede interesarle a algún lector.

El código es el cálculo de una factura de un contratista de reformas. Para el cálculo de la factura existen reglas de tarificación según el tiempo invertido y además tenemos un descuento en el trabajo más largo.

Voy poniendo el código y explicando que hace y porqué he tomado tales decisiones:

lunes, 18 de junio de 2018

La perversión repositoria.

Querido lector:

¿Se ha planteado, verdaderamente y a fondo, el propósito y la responsabilidad de un repositorio cuando está implementando una arquitectura que facilite DDD?

miércoles, 4 de abril de 2018

Vega ahí esos Funtores, esos Funtores Aplicativos y esas Mónadas bien explicaditos.

  • Funtor: es una function de una categoría a otra que lleva objetos a objetos y morfismos a morfismos de manera que la composición de morfismos y las identidades se preserven. 
  • Monada: es un endofunctor (un functor desde una categoría hacia ella misma), junto con dos transformaciones naturales.
  • Funtor Aplicativo: funtores monoidales laxos con fuerza tensorial.
¿A qué vienen esas caras?¿No ha quedado claro? Bueno vale; entonces os recomiendo que le echéis un vistazo a esto:

lunes, 5 de marzo de 2018

Lecturas recomendadas.

Un blog muy fino e interesante con respecto al desarrollo de software:


Un libro estupendo que te guía sobre el maravilloso camino de convertir tu arquitectura y tu código en la documentación de tu proyecto para que nunca esté desactualizado y descontextualizado:


Compradlo bastardillos que merecen la pena los 4 duros que vais a invertir en él.

Otro estupendo libro que ayuda a salir del "arroyo" del "computer think", el cual  nos guía a desarrollar software cuyo único contexto es "el orden en que la máquina ejecuta cosas" y nos lleva a grandes despropositos:

jueves, 22 de febrero de 2018

Crazy FizzBuzz in C#

Si programas casi seguro que te has encontrado con el test FizzBuzz o has leído alguna reseña o referencia a él; y si no, aquí dejo una de un blog famoso.

Pero, aparte de su principal uso para filtrar profesionales de la programación, me he dado cuenta de que los matices inherentes de este test (condiciones no exclusivas y salida incremental) lo hacer muy bueno para demostrar técnicas que fomenten DRY, separación de responsabilidades y organización de código.