The talking list

Hace un tiempo me contactaron desde The Test Tribe, una comunidad de testers en India, para invitarme a colaborar en su blog. Toda una sorpresa que hubiesen encontrado un artículo mío en inglés. Aprovechando que estaba en pleno desarrollo de Golden, escribí un artículo sobre snapshot testing en el backend. Gracias a Shrutika Ranjan, por la invitación.

Este es el resultado:

Snapshot testing is a methodology in which we collect the subject-under-test’s output and use it as the criterion for the subsequent test runs. We call this collected output snapshot because it captures the behavior of the subject-under-test (SUT) at a given moment in time. This defines a regression test as our goal is to be sure that future changes in the subject-under-test don’t affect its behavior. Of course, we should check that the snapshot is correct.

Snapshot Testing in the Backend

(2024/04/03)

Derek Comartin tiene este blog y canal de Youtube en el que trata numerosos temas relacionados con el diseño y arquitectura de software con una aproximación crítica, dedicando muchos posts y vídeos al tema de las arquitecturas Event-Driven, pero también a cuestiones más básicas de diseño. Creo que no hay ni un solo vídeo que no quiera ver en algún momento.

Realmente me parece un canal que merece la pena seguir, aunque hay que tener cuidado de no engancharse porque son decenas de tamas interesantísimos y más allá de que puedas estar de acuerdo en todos sus argumentos, la presentación es muy buena y te hace reflexionar.

A great example of this is Domain-Driven Design. When people first get into it, they immediately latch on to the tactical patterns in code such as Entities, Value Objects, Aggregates, etc. You can find all kinds of tutorials that show you how to use these patterns, but rarely do they ever explain the reasons why you might use them and where they might not be useful. The moral of the story is that you’ll be better served focusing on the problem at hand and the use cases. Then determine what technical solution fits.

Code Opinion

(2024/04/03)

Este libro de Corey Haines (LeanPub, $17.99) contiene una serie de ejemplos y consejos para mejorar el diseño de software, basados en las cuatro reglas del diseño simple de Kent Beck. Y también unas cuantas sugerencias para organizar un Code Retreat en torno al Juego de la Vida de Conway.

Haines propone varias reflexiones acerca de cómo representamos los distintos conceptos en el código. Es posible que algunas de ellas te vuelen un poco la cabeza, pero una vez que las entiendes es difícil volver atrás. Si vienes de un mundo de programación procedural, o de un entorno superficialmente orientado a objetos, las propuestas del libro elevarán la calidad de tu código.

Eso sí, no esperes una solución completa al problema del Juego de la Vida. Esto puede que te frustre un poco, pero no es el objetivo del libro.

¿Es conveniente haber intentado hacer el ejercicio antes de leer el libro? No necesariamente, pero si tienes familiaridad con el problema, es más fácil seguir los ejemplos y darles contexto. En mi caso lo he leído antes y después y he sacado ideas útiles ambas veces.

Rather than planning for change points, we build systems, by applying simple design principles, that can change easily at ANY point.

Understanding the four rules of simple design

(2024/03/29)

Llevo un buen rato intentando escoger algo concreto del blog de Julia Evans para mostrar aquí, pero está tan lleno de buenos artículos que es casi imposible quedarse con alguno.

En cualquier caso, recomendaría mucho sus últimos posts sobre Git, en los que profundiza en todo tipo de aspectos de esta herramienta que usamos todos los días. Como muestra, el último que ha publicado sobre HEAD, o el anterior sobre opciones de configuración.

This blog is about […] how being clear & curious & humble is better than sounding like I know it all already

Julia Evans

(2024/03/10)

Me ha gustado este canal de vídeos de Federico Azzurro sobre Python. Son muy claros, y además muestran algunos aspectos del lenguaje que son relativamente desconocidos, al menos para personas que como yo, aunque podemos programar en Python, todavía no estamos completamente pythonizados.

Indently ofrece también cursos del lenguaje en Udemy y, a la vista de los vídeos, parecen ideales para pasar de simplemente competente en el lenguaje a dominarlo.

Simple is better than complex_

Indently_

(2024/03/05)

No pasa un día en que no me encuentre con un post, un vídeo o un comentario en alguna red en la que alguien diga algo así como: “en mi equipo estamos haciendo arquitectura hexagonal y tenemos la capa de dominio, la de aplicación y la de infraestructura”.

Pues no. No estáis haciendo arquitectura hexagonal. Eso que mencionas es una arquitectura de tres capas que recoge conceptos comunes de las arquitecturas limpias:

• El dominio está aislado del mundo real y define abstracciones para no depender de tecnologías concretas.
• Los casos de usos coordinan los elementos del dominio para ejecutar las finalidades de la aplicación y viven en una capa que puede tener ese nombre.
• Los detalles de implementación de las abstracciones del dominio viven en una capa de infraestructura.
• Las dependencias siempre apuntan al dominio, que es como decir, que todo depende del dominio y el dominio no depende de nada más.

¡Ojo!, no estoy diciendo que eso esté mal. De hecho, si lo estás haciendo así, en realidad está muy bien. Es solo que eso no se llama arquitectura hexagonal. Si hablas de arquitectura hexagonal háblame de puertos y háblame de adaptadores. Pero no de capas, aunque puedes organizar tu aplicación en capas si así te viene bien.

Y no es por ser pejiguero. Pero usar la terminología con precisión es un deber profesional. De otro modo, no podemos comunicarnos eficazmente.

Es raro el equipo de desarrollo que no diga que está haciendo Arquitectura Hexagonal en sus proyectos. Es raro el equipo de desarrollo que la esté haciendo realmente.

No, Domain-Application-Infrastructure no es arquitectura hexagonal

(2024/03/04)

Se trata de un plugin para IntelliJ que ofrece una especie de caja de herramientas en la que tendremos acceso a un montón de utilidades, codificadores/decodificadores, generadores, etc. Muchas de ellas son las típicas que buscamos online, pero que aquí nos aparecen integradas en el IDE ahorrando tiempo y clics.

Incluye herramientas como:

• Codificador/decodificador Base32 y Base 64
• JWT
• Generador de contraseñas
• Generador de ULID y otros UUID
• Generador de Lorem Ipsum
• JSON path
• Generador de QR
• Formateo de código
• ¡Patito de goma!

Y muchos más.

This plugin is a powerful and versatile set of tools designed to enhance the development experience for software engineers. With its extensive collection of features, developers can increase their productivity and simplify complex operations without leaving their coding environment.

Developer Tools para IntelliJ

(2024/02/25)

Kent Beck tiene la virtud de expresar de una forma concisa conceptos complejos. Y eso es lo que hace en este libro. Tidy First? no llega a las 100 páginas, pero propone todo un arsenal de técnicas y fundamentos con las que mejorar el código de un proyecto de software empezando hoy mismo.

Literalmente: en la parte I explica los Tydings: pequeños refactors que puedes aplicar nada más leer cada uno de sus breves capítulos.

La parte II se dedica a cuestiones de organización. Cómo gestionar esta limpieza de código para que no se convierta en un viaje sin retorno.

La parte III explica por qué funciona esta aproximación al diseño de software.

Hay que decir que nosotros también tenemos un libro bastante decente sobre el tema, que por cierto estamos actualizando.

Software design is an exercise in human relationships.

Tidy First? A Personal Exercise in Empirical Software Design

(2024/02/08)

Golden es una librería de snapshot testing que he creado para Go. Después de unas semanas de trabajo, ya está declarada estable y he publicado la versión v1.0.0.

En parte, como ejercicio de aprendizaje. En parte, porque no me acaban de encajar otras librerías disponibles.

Snapshot testing es una técnica bastante usada en desarrollo frontend que consiste en guardar el output de nuestro código y usarlo como criterio para ejecutar futuros tests. De este modo, creamos un test de regresión que nos asegure que mantenemos el comportamiento actual de una unidad de software.

En backend, el snapshot testing no es tan usado, pero hay muchos casos de uso para esta técnica: objetos complejos, generación de archivos de todo tipo (JSON, CSV, XML, etc.) para los que es costoso desarrollar un test basado en aserciones.

Además, esta técnica es muy potente usada con código legacy o, en general, con código que no tiene tests. Nos permite obtener una buena cobertura rápidamente, antes de intervenir en un código.

Golden, además de snapshot testing, nos permite trabajar con approval testing. En esta modalidad, lo que hacemos es mantener el test fallando a propósito hasta que el snapshot que se ha generado sea revisado por nosotras o por una experta del dominio que nos pueda decir si el output es correcto o no. Cuando nos satisface, “aprobamos” el snapshot y lo usamos como criterio en los tests futuros.

Approval testing es una técnica adecuada cuando estamos escribiendo código nuevo que genera objetos complejos o documentos.

Finalmente, Golden ofrece la posibilidad de realizar los tests combinatorios de la técnica Golden Master. Esta técnica consiste en bombardear el código a base de llamadas con distintas combinaciones de sus parámetros, de tal modo que lo forcemos a recorrer todos sus posibles flujos de ejecución.

Para ello, no tenemos más que indicarle a Golden listas de valores para cada parámetro de entrada de la unidad bajo test y generará todas las combinaciones posibles. Esta técnica puede ayudarnos a obtener una cobertura completa de un código existente sin tener que preocuparnos de entenderlo en profundidad. Una vez que hemos generado el “golden master” y estamos protegidas por el test, podemos empezar a aplicar técnicas de refactor para mejorar su diseño.

Golden: librería de snapshot testing en Go

(2024/01/31)

Vlad Khononov citando a Alberto Brandolini en su libro “Learning Domain Driven Design”:

Software development is a learning process; working code is a side effect

Software development is a learning process

(2024/01/28)

En relación con el artículo anterior, Joan López tiene esta buena explicación en castellano sobre el uso de opciones funcionales en Go.

Otros aspectos ligados a (o fruto de) esa sencillez son la no existencia de parámetros opcionales o la no existencia de sobrecarga de métodos. Y es precisamente en ese aspecto en el que nos queremos centrar hoy. Pues, como veremos a continuación, la falta de dichos recursos a veces nos puede llevar más de un dolor de cabeza y/o dirigirnos a recurrir a prácticas poco atractivas. Sin embargo, si analizamos la situación con un poco de temple, veremos que de la no existencia de dichas características lo que vamos a hacer será encontrar soluciones incluso más atractivas de las que podríamos recurrir en el caso de poseer dichas características. Entremos en materia.

Functional options en Go

(2024/01/26)

Me guardo este artículo de Rob Pike que explica como usar funciones autorreferenciales para pasar parámetros a funciones en Go. Ya, yo también me quedo un poco igual con este título, la verdad, pero resuelve un problema bastante interesante: diseñar signaturas de funciones que puedan recibir un número indeterminado de parámetros de una forma bastante limpia.

I’ve tried most of the obvious ways: option structs, lots of methods, variant constructors, and more, and found them all unsatisfactory. After a bunch of trial versions over the past year or so, and a lot of conversations with other Gophers making suggestions, I’ve finally found one I like. You might like it too. Or you might not, but either way it does show an interesting use of self-referential functions.

Self-referential functions and the design of options

(2024/01/23)

Hace tiempo creé una herramienta para gestionar las versiones de proyectos git. Nada nuevo bajo el sol, pero por algún motivo llamó la atención de algunas personas, que se animaron a hacer forks y a colaborar en el desarrollo. Así que podríamos considerarlo como mi primer proyecto Open Source.

Versiontag te ayuda a gestionar el versionado semántico de un proyecto de una forma bastante sencilla, con una interfaz de línea de comandos bastante obvia. Simplemente, le dices qué tipo de versión quieres hacer (major, minor o patch) y el script busca la última tag de versión y te propone una actualización adecuada.

Pues nada, acabo de hacer una pequeña actualización, porque me estaba encontrando algunas incongruencias al versionar algún proyecto. El problema estaba en la forma de averiguar la última versión, pues por algún motivo no estaba ordenando la lista de tags correctamente.

Version Tag

(2024/01/22)

Buscando información histórica sobre la técnica Golden Master, me encontré con el blog de Johan Martinsson, que tiene esta entrada en la que compara el retorno de inversión del refactoring según cuando lo hagas.

The return of investment comes directly after the refactoring. It’s an investment opportunity we cannot miss! We’re almost certain to at least break even, and in the shortest period of time.

Some economics of refactoring

(2024/01/21)

Diff.blog es un proyecto de Vishnu KS que me he encontrado hace poco y me parece una maravillosa idea. Se trata de un agregador de blogs sobre desarrollo. La agregación se realiza mediante su RSS. Así que, en cierto modo, es un lector RSS especializado.

Esto permite encontrar varios blogs interesantes, tanto individuales como de equipos, que normalmente pasarían desapercibidos en otras plataformas. Y tampoco hay paywalls. Good old open web.

Si echas de menos algún blog en particular, puedes proponerlo.

How is it different from Medium?

diff.blog unlike Medium does not host any blogs. diff.blog merely acts as a platform that makes it easier to discover and subscribe to blogs. So you own your own blog and content. You can host your blog in a Wordpress site, GitHub pages, Ghost, or wherever you want. This means even if diff.blog shut downs one day it won’t affect your blog at all.

Diff.blog

(2024/01/21)

Me ha llamado la atención esta receta 3P de Johan Martinsson. A la hora de iniciar el trabajo en una historia de usuario o tarea:

• Empezaremos protegiendo el comportamiento existente con los tests que sean necesarios (Protect).
• Luego refactorizaremos para que la nueva funcionalidad se pueda introducir fácilmente (Prepare)
• Cuando tenemos esto, desarrollamos la nueva funcionalidad con TDD (Produce):

This is where the idea of the 3Ps comes in, where we not only bring the investment closer to the benefit, but also we are the foremost beneficiaries of the tests just wrote and the refactoring we just did! This has the added benefit that any ill-conceived tests and refactoring are immediately brought to the attention of just the right person to fix the issue.

The idea is simple, for each story break down the work into:

• Protect
• Prepare
• Produce

Breaking out of legacy with 3P

(2024/01/21)

Este librito de Gojko Adzic, David Evans y Tom Roden ($10 en Leanpub) propone exactamente 50 ideas a considerar para diseñar nuestra estrategia de testing. Me encanta particularmente esta serie de heurísticas emocionales para decidir qué tests hacer. Sencillamente genial:

Here is our set of emotional heuristics to stimulate test design, taking an emotional roller coaster of a ride along the way:

The scary path – if this path was followed it would really tear the house down, and everything else with it. Flush out those areas of the highest risk to the stakeholders. Think what would scare each stakeholder the most about this piece of functionality or change.

The happy path – the key example, positive test, that describes the straightforward case. This is the simplest path through the particular area of behaviour and functionality that we can think of, it is the simplest user interaction and we expect it to pass every time (other than its first ever run maybe).

The angry path – with the angry path we are looking for tests which we think will make the application react badly, throw errors and get cross with us for not playing nicely. These might be validation errors, bad inputs, logic errors.

The delinquent path – consider the security risks that need testing, like authentication, authorisation, permissions, data confidentiality and so on.

The embarrassing path – think of the things that, should they break, would cause huge embarrassment all round. Even if they wouldn’t be an immediate catastrophe in loss of business they might have a significant impact on credibility, internally or externally. This could be as simple as something like spelling quality as ‘Qality’, as we once saw on a testing journal (just think of the glee on all those testers’ faces).

The desolate path – provide the application or component with bleakness. Try zeros, nulls, blanks or missing data, truncated data and any other kind of incomplete input, file or event that might cause some sort of equally desolate reaction.

The forgetful path – fill up all the memory and CPU capacity so that the application has nowhere left to store anything. See how forgetful it becomes and whether it starts losing data, either something that had just been stored, or something it was already holding.

The indecisive path – simulate being an indecisive user, unable to quite settle on one course of action. Turn things on and off, clicking back buttons on the browser, move between breadcrumb trails with half-entered data. These kinds of actions can cause errors in what the system remembers as the last known state.

The greedy path – select everything, tick every box, opt into every option, order lots of everything, just generally load up the functionality with as much of everything as it allows to see how it behaves.

The stressful path – find the breaking point of the functions and components so you can see what scale of solution you currently have and give you projections for future changes in business volumes.

Fifty Quick Ideas to Improve Your Tests

(2024/01/15)

Siempre acabo volviendo a este artículo de Mathias Verraes en el que explica brevemente los diferentes tipos de mensajes con los que pueden comunicarse las aplicaciones.

A message is a unit of communication between systems. There are three flavours of messages: informational, interrogatory, and imperative.

Messaging Flavours

(2023/12/30)

Gran post de Javier López sobre cómo la organización de equipos influye en el lead time (el tiempo desde que se pide una feature hasta que sale a producción). Introduce una idea interesante que podríamos llamar “multitarea de equipo”, que también afecta negativamente.

The easiest way to reduce your lead time is to reduce WIP inside the team. This is what kanban proposes, put a limit in your WIP and focus on finishing the stories in progress.

Don’t bite off more than you can chew

(2023/12/30)

Un micro-blog para enlazar recursos que me parecen interesantes, sin un orden especial. Simplemente, lo que me voy encontrando.

(2023/12/29)

Una gran charla (en inglés) de Kevlin Henney que toma como punto de partida la kata Gilded Rose y habla del refactoring como eje central del desarrollo.

Write tests for people. So who should you be writing the test for?

Gilding the Rose: Refactoring-Driven Development

(2023/12/29)

Una sesión de live coding con Kent Beck y Kelly Sutton explicando cómo puedes usar el workflow Test Commit Or Revert para probar hipótesis sobre un código que no conoces.

Consiste en ir escribiendo pequeños tests con el comportamiento que supones o esperas. Si aciertas, el test se queda. Y, si no, el test desaparece.

Oh… we lost it. We are so sad.

Understanding Legacy Code with TCR

(2023/12/29)

En este live coding, Llewellyn Falco introduce diversas técnicas para realizar un completo refactoring, pero es que además usa Test Commit Or Revert para asegurar que cada paso que da mantiene la funcionalidad.

Estas técnicas son:

• Test combinatorio para obtener 100% de cobertura rápidamente.
• Code Coverage como guía.
• Refactorings probados que no necesitan tests.

The difference between a good programmer and a great programmer is that the great programmers are extremely lazy

From 0% to Cleanly Refactored 100% tested code

(2023/12/29)