8 files changed, 88 insertions, 6 deletions
diff --git a/blog/content/2020/07/soy-un-ser-determinista.gmi b/blog/content/2020/07/soy-un-ser-determinista.gmi
index d08258a4..6dc5a649 100644
--- a/blog/content/2020/07/soy-un-ser-determinista.gmi
+++ b/blog/content/2020/07/soy-un-ser-determinista.gmi
@@ -1,14 +1,12 @@
 # 2020-07-12 Soy un ser determinista
 
-Me recuerda un compañero que me repito más que el ajo:
-
-https://farside.link/nitter/javier%5C_tejero/status/1282208442686603265[1]
+=> https://nitter.tiekoetter.com/javier_tejero/status/1282208442686603265 Me recuerda un compañero que me repito más que el ajo.
 
 Javi supongo que se refiere al periodo en que trabajábamos en una pequeña consultora que hacía desarrollos centrados en redes sociales que había desaparecido de mi mente. Ahora se me aparecen vagos recuerdos del que probablemente fue el inicio de mi descontento con las redes, en especial, Facebook.
 
 He revisado un poco mis publicaciones recientes y extrañamente no he pontificado sobre estos temas últimamente por aquí, así que os fastidiáis.
 
-No me las voy a dar ahora de haber acertado de pleno ni de ser un adelantado, después de todo sospecho que la cosa iba más por las APIs de Facebook (aunque recuerdo que me parecían de un REST ejemplar) y de sus oscuras reglas (bueno, ahí sí que DHH se ha dado cuenta tarde[2] :). Pero sí me fascina mi determinismo en que al retomar la batalla una década después, me haya ido a exactamente la misma estrategia.
+No me las voy a dar ahora de haber acertado de pleno ni de ser un adelantado, después de todo sospecho que la cosa iba más por las APIs de Facebook (aunque recuerdo que me parecían de un REST ejemplar) y de sus oscuras reglas (bueno, ahí sí que DHH se ha dado cuenta tarde[1] :). Pero sí me fascina mi determinismo en que al retomar la batalla una década después, me haya ido a exactamente la misma estrategia.
 
 Francamente creo que en la comunicación unipersonal, es tan fácil enviar un e-mail (o incluso más fácil si queremos tener una conversación mínimamente elaborada) como usar la red social de turno para comunicarnos. Quizá perdemos la facilidad de que la conversación sea semi-pública, pero sinceramente, creo que salvo el bueno de Javi y yo, más gente (probablemente, sólo una, ciertamente :) verá este post que el tuit de Javi. Y qué más da.
 
@@ -16,6 +14,6 @@ Para comunicación pública yo tengo mi blog, y creo que hoy en día siguen exis
 
 Volviendo al mensaje de Javi, tiene más razón que un santo: "Hoy en día otras RRSS han ganado mucho terreno al e-mail, muy a nuestro pesar. Obviamente, no pinta bien.". No pinta bien, pero resistid. No creo que nadie haya comenzado a usar un lector de RSS después de que dijera que mis tuits no iban a ser más que enlaces a este blog. No creo que vaya a causar un efecto de red perceptible, así que igual sólo estoy haciendo activismo de sofá. Yo voy a seguir mirándome el Fediverse, Lemmy, Mastodon, etc. y al menos me entretendré a ratos.
 
+=> https://farside.link/nitter/dhh/status/1273748071298392065 [1] DHH despotricando sobre las oscuras reglas de las plataformas de las grandes plataformas comerciales
 
-=> https://farside.link/nitter/javier%5C_tejero/status/1282208442686603265 1: https://farside.link/nitter/javier%5C_tejero/status/1282208442686603265
-=> https://farside.link/nitter/dhh/status/1273748071298392065 2: https://farside.link/nitter/dhh/status/1273748071298392065
+(Nota 2026-07-09: cuando escribí esto no conocía ciertas posturas de DHH que ahora sí conozco y que hacen que me duela que le citase bastante en el pasado.)
diff --git a/blog/content/2026/07/la-anomalía.gmi b/blog/content/2026/07/la-anomalía.gmi
new file mode 100644
index 00000000..5d6cdc68
--- /dev/null
+++ b/blog/content/2026/07/la-anomalía.gmi
@@ -0,0 +1,41 @@
+# 2026-07-18 La anomalía
+
+(Llevo varios días con esta entrada en la cabeza, pero curiosamente hace unas horas un banco me ha notificado que no podré operar por Internet sin Android o iOS.)
+
+=> ../../2013/01/conecte-el-teclado-al-televisor En 2013 escribí sobre aquello de teclear y que aparezca lo que escribas en la tele, y cómo cada vez hay menos teclados.
+
+(Curiosamente, he encontrado ese post buscando si ya había escrito aquí la anécdota con la que quería abrir este texto.)
+
+=> ../../2025/01/los-sistemas-operativos-y-un-amanecer-de-internet En 2025 escribí sobre ese momento alrededor del cambio de milenio donde comenzamos a tener Internet y sistemas operativos robustos en casa.
+
+=> ../../2025/02/el-lento-adios-a-la-magia-de-los-ordenadores También en 2025 escribí sobre los aparatos programables, y cómo cada vez son menos programables y menos nuestros.
+
+Pero lo que hace que escriba oootra vez más de lo mismo es este maravilloso artículo de menos de 3000 palabras (pero en inglés) publicado en 2013 (curiosamente, el mismo año que el primer artículo mío que os enlazo arriba) que me fascinó el otro día:
+
+=> https://www.winestockwebdesign.com/Essays/Eternal_Mainframe.html The Eternal Mainframe
+
+(Le han enviado nueve traducciones, pero ninguna al español. Si me aburro igual lo intento.)
+
+Es muy difícil poner fechas e hitos a las cosas. Según la Wikipedia, a mitad de los setenta comenzaron a publicarse diseños de ordenadores que resultaban viables de montarse en casa. Destacan el Altair 8800, que costaba 400 dólares pero que ni siquiera tenía teclado de serie; se podía programar una secuencia de arranque de instrucciones directas al procesador mediante un panel de interruptores. Poco después se pudieron comprar hechos esos teclados conectados al televisor que más que sistema operativo tenían el lenguaje de programación BASIC (ese lenguaje que destaca por el curioso honor de tener en su leyenda a Mary Kenneth Keller, una monja, y a Microsoft).
+
+Este fue el inicio de una anomalía de unos cincuenta años, que dudo que dure cincuenta años más.
+
+La anomalía igual ya les resulta anómala a algunos. Una parte significante de la población finalmente tuvo acceso al ordenador programable. Como he explicado otras veces, hay incontables máquinas complejas, pero el ordenador programable es una de esas máquinas que podemos hacer más complejas (lamentablemente la RAE no recoge la palabra "complejar" y "acomplejar" se refiere a los complejos malos). Es como cualquier herramienta que se puede usar para construir algo, pero lo que construye son básicamente bailes de electrones, algo que pese a ser mucho más intangible hemos visto que sus resultados pueden resultar increíblemente tangibles.
+
+El ordenador programable existía claro desde hace tiempo. Pese a otras historias entrañables, diré que unos cuarenta años antes del Altair 8800. Pero eran esos monstruos que no cabían en ninguna casa y que costaban más que una casa.
+
+El acceso a la tecnología es lo que acelera su desarrollo. Tras cuarenta años contando cosas y calculando trayectorias balísticas, en prácticamente un par de años de ordenadores en casa nacieron las primeras BBS ("bulletin board service", la Wikipedia española propone "tablón de anuncios") que conectaban ordenadores domésticos. Internet ya existía desde hace tiempo, pero en universidades y empresas; Internet iría sustituyendo a las BBS poco a poco durante un par de décadas.
+
+Aparte de tener el mágico ordenador programable en casa, la otra parte de la anomalía es que este ordenador programable era prácticamente abierto y manipulable, pero a pesar de ello poco a poco lo pudimos usar para partes imprescindibles de la vida. No sólo para comunicarnos con otras personas, sino también para hacer trámites, comprar, escuchar música o ver la tele. Me parece alucinante que básicamente el sistema con el que puedo presentar la declaración de la renta sea un heredero de esos ordenadores que la gente ensamblaba siguiendo las instrucciones de una revista y usando un sistema operativo cuyos origenes están en el tiempo libre de estudiantes y peterpanes.
+
+Pero la tendencia es que esto desaparezca. Es cierto que ha habido muchos momentos en los que para hacer estos "trámites vitales" teníamos que pasar por sistemas cerrados como Microsoft Windows (sí, esos que aparecen unos párrafos más arriba por sus BASICs en esos ordenadores programables domésticos), pero hemos tenido largos destellos de unos usos sin restricciones que comenzamos a añorar.
+
+Es agridulce, porque creo que la anomalía ha pasado su punto álgido. Creo que no desaparecerá, pero simplemente pasará a un segundo plano (con malas consecuencias, creo yo). Lo de "The Eternal Mainframe" que me ha hecho escribir esto y mis escritos anteriores citados al principio intentan explicar el cómo y el por qué. Lo que sigue es cómo creo que sobrevivirá la anomalía. (Curiosamente, cuatro parráfos tras bastantes más de introducción.)
+
+Los trámites que hacíamos en un ordenador abierto y programable se irán cada vez más a los móviles poco programables y cerrados excepto para Apple y Google, de las empresas con más poder que existen (precisamente en parte por este control que ejercen). Lo mismo pasará con muchas otras cosas; los jóvenes ya no se reirán de los viejos porque insistan en hacer cosas en el ordenador, porque ya no podrán.
+
+Y la verdad, no pasa (casi) nada.
+
+Espero que durante más tiempo del que me importa, sigamos pudiendo comprar ordenadores programables y no tener que ensamblarlos a partir de instrucciones en papel. Las posibilidades del ordenador programable seguirán siendo infinitas como lo han sido siempre para el que ha querido dedicarse a ellas. El otro componente es que de una manera u otra seguiremos pudiendo enviar ceros y uno de una punta a otra del mundo a un coste ridículo. Incluso comenzamos a tener buenas piezas para evitar alguna de las perversiones de la estructura de Internet que han entorpecido la anomalía (curiosamente, veo que no he escrito aquí sobre la red Yggdrasil y que lo que encuentro rápidamente sobre este tema son doce palabras en 2005; nota mental: hay que escribir una entrega sobre este tema).
+
+Las comunidades serán más pequeñas y los efectos creo que también. Por verle el lado positivo, el esfuerzo masivo que se ha dedicado a hacer que el ordenador programable sea útil para el mundo real quizá ya no sean necesarios: la inacabable ingeniería inversa para hacer funcionar sistemas operativos abiertos sobre ordenadores no diseñados con ese propósito, los bizantinos navegadores que intentan seguir la estela de Apple y Google; todos esos esfuerzos quizá se puedan destinar a otras cosas que hagamos con esos ordenadores programables si le dejamos las cosas oficiales a un aparato que no nos suponga un gran esfuerzo económico. Y quizá si le dedicamos más atención al ordenador programable con teclado al que acudimos explícitamente en peregrinamiento en vez de al pequeño aparato que inconscientemente ocupa nuestra mente por estar siempre en el bolsillo, haremos cosas más interesantes gracias a usar el aparato más interesante.
diff --git a/blog/content/notas/comprar-bajo-en-sodio.gmi b/blog/content/notas/comprar-bajo-en-sodio.gmi
index 9af1e1ea..3c77f8b7 100644
--- a/blog/content/notas/comprar-bajo-en-sodio.gmi
+++ b/blog/content/notas/comprar-bajo-en-sodio.gmi
@@ -141,6 +141,11 @@ Sal: 0,5/100g
 
 Estos chips de plátano tienen algo menos de sal que la mayoría de snacks salados que encontramos en el supermercado.
 
+Cacahuetes a la sal y miel
+Sal: Mercadona 0.30/100g, Eagle's 0.60/100g
+
+Esta preparación de frutos secos clásica tiene bastante menos sal que otros aperitivos similares.
+
 ### Arroces
 
 Arroz cocido basmati Sabroz Brillante
diff --git a/blog/content/notes/index.gmi b/blog/content/notes/index.gmi
index 4f985750..b4ad7d0c 100644
--- a/blog/content/notes/index.gmi
+++ b/blog/content/notes/index.gmi
@@ -24,6 +24,7 @@ Notes about some books and long articles I like:
 => tech/migadu Migadu
 => tech/ripping Ripping
 => tech/about-apis About APIs
+=> tech/modularity Modularity
 => tech/about-relational-databases About relational databases
 => tech/containers-might-not-be-the-right-answer Containers might not be the right answer
 => tech/crud-is-an-important-unsolved-problem CRUD is an important unsolved problem
diff --git a/blog/content/notes/interesting-articles.gmi b/blog/content/notes/interesting-articles.gmi
index 5579a568..a08b5419 100644
--- a/blog/content/notes/interesting-articles.gmi
+++ b/blog/content/notes/interesting-articles.gmi
@@ -49,6 +49,9 @@ Second of a series of three articles comparing software engineering with traditi
 => https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html SMURF: Beyond the Test Pyramid
 Test categories and the pyramid are excessively limited models.
 
+=> https://abseil.io/resources/swe-book/html/ch11.html#the_beyonceacutesemicolon_rule The Beyoncé Rule
+"If you liked it, then you shoulda put a test on it."
+
 ### Python
 
 => https://lukeplant.me.uk/blog/posts/pythons-disappointing-superpowers/ Python’s "Disappointing" Superpowers
@@ -182,6 +185,9 @@ The approximate percentage of responses to a poll, survey, or quiz that are not
 => https://en.wikipedia.org/wiki/Solomonoff%27s_theory_of_inductive_inference Solomonoff's theory of inductive inference
 Under its common sense assumptions (axioms), the best possible scientific model is the shortest algorithm that generates the empirical data under consideration. Solomonoff's induction naturally formalizes Occam's razor.
 
+=> https://en.wikipedia.org/wiki/Planning_fallacy Planning fallacy
+A phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.
+
 See also:
 
 => greek-task-list Greek task list
diff --git a/blog/content/notes/tech/about-apis.gmi b/blog/content/notes/tech/about-apis.gmi
index f1732cc9..7f604a2c 100644
--- a/blog/content/notes/tech/about-apis.gmi
+++ b/blog/content/notes/tech/about-apis.gmi
@@ -24,3 +24,7 @@ We propose that the architecture benefits of level 4 are also present in levels
 Note also that level 3 can provide many benefits of level 4, but with less development overhead, so it's a level we recommend considering explicitly, as it is often overlooked.
 
 Level -oo is typical of legacy applications. Note that we consider the distance between level -oo and the rest of levels much bigger than the distance between the rest of levels.
+
+## Further reading
+
+=> ./modularity Modularity
diff --git a/blog/content/notes/tech/misc-linux-stuff.gmi b/blog/content/notes/tech/misc-linux-stuff.gmi
index fd881dac..2f187203 100644
--- a/blog/content/notes/tech/misc-linux-stuff.gmi
+++ b/blog/content/notes/tech/misc-linux-stuff.gmi
@@ -124,3 +124,7 @@ To enter an environment with the Nix flake configuration, run the following comm
 ```
 nix --extra-experimental-features nix-command --extra-experimental-features flakes develop
 ```
+
+## Miscelaneous
+
+=> https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail Bash Pitfalls / set -euo pipefail (problems caused by)
diff --git a/blog/content/notes/tech/modularity.gmi b/blog/content/notes/tech/modularity.gmi
new file mode 100644
index 00000000..606ada09
--- /dev/null
+++ b/blog/content/notes/tech/modularity.gmi
@@ -0,0 +1,23 @@
+# Modularity
+
+In 2012, I started working on a company to maintain a critical internal system implemented in Django. A key part of this system was a complex web form. This form was a massive mess involving serialized data structures in the database (Python pickles), complex form inputs and manipulation in a big, unmaintainable ball of code that no one wanted to touch. I would like to say that I went in and fixed this problem, but this is not what happened. This would have unlocked a ton of productivity gains, as our users would frequently have to do bulk updates one by one with this form and I believe at some point someone implemented some browser automation to deal with it.
+
+This form reinforced something I had known for quite a long time: do not mix form handling and business logic. And perhaps do not mix business logic and database manipulation, if you are feeling fancy.
+
+In 2006 I worked under someone deep into software architecture. We would have screaming matches because he wanted to modularize a lot, including multiple classes to represent our business data; data transfer objects, data objects, value objects and all sorts of complex structure which I felt was overkill.
+
+In the world before single page applications (SPAs), I think these conversations made plenty of sense. People suffered from web applications that were massively painful to add programmatic APIs to. While I think that just having an internal clean API that form handling interacts with is more than enough, even 20 years ago we were already discussing things that continue today with concepts such as hexagonal architecture.
+
+However, SPAs, despite the many problems I believe them to have, started with an API and then implemented a human interface for the API.
+
+Despite I think modularity is still a complex and valuable topic to discuss, I get the feeling that many of the modern discussions about "bounded contexts", hexagonal architecture, and others... try to solve the problems I had in 2012 and earlier with that unmaintainable web form, but which do not exist to that degree in modern web applications.
+
+What is more curious is that I think that some people proposing hexagonal architecture have not experienced the pre-SPA world in which those problems truly caused issues. This week I saw the main proponent of a hardcore architecture at work with much modularization walk back into some of the code structures they proposed, tying back into the discussions I had with my boss in 2006 about the tediousness of DTOs. Once put in place, the architecture they proposed felt to them a slog and they started to explore ways to dial it down a bit.
+
+What I told them is that the problems might be more basic. The database schema below my unmaintainable 2012 web form was completely against any good database schema design practices- with a proper database schema, we would have been able to write an API on top of it from scratch without so much effort. The form was also devoid of any kind of automated testing, which would have made refactors much less scary. Also, the rest of the application that contained that web form was completely fine with the excessive coupling it had; only that web form had enough complexity to cause problems and the rest of the application we were productive enough maintaining and extending even without a good architecture, schema design, or automated tests.
+
+In my opinion, with a good data schema and automated tests, just writing the simplest code that you want is likely the most productive way of starting. And with a good data schema and automated tests, adding a better architecture later should be easy.
+
+## Further reading
+
+=> ./about-apis About APIs