The talking list

El micro-blog de The Talking Bit

Developer Tools para IntelliJ

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)

Tidy First? A Personal Exercise in Empirical Software Design

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, librería de snapshot testing en Go

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)

Functional options en Go

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)

Self-referential functions and the design of options

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)

Version Tag

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)

Some economics of refactoring

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

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)

Breaking out of legacy with 3P

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)

Fifty Quick Ideas to Improve Your Tests

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)

Messaging Flavours

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)

Don’t bite off more than you can chew

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)

Presentando The Talking List

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

(2023/12/29)

Understanding Legacy Code with TCR

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)

From 0% to Cleanly Refactored 100% tested code

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)

Temas

good-practices

refactoring

php

testing

tdd

python

blogtober19

design-principles

design-patterns

bdd

misc

tb-list

legacy

golang

dungeon

ruby

tools

tips

hexagonal

ddd

bbdd

soft-skills

books

oop

javascript

api

sql

ethics

typescript

swift

java

agile