2 files changed, 128 insertions, 0 deletions
diff --git a/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi b/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi
new file mode 100644
index 00000000..ed19cb36
--- /dev/null
+++ b/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi
@@ -0,0 +1,93 @@
+# 2026-04-05 Breve e incompleta historia del desarrollo web
+
+El primer navegador y servidor web aparecieron en 1990, pero hasta 1993 la web era mayormente documentos estáticos; los servidores web tiraban de una carpeta con ficheros HTML con los que se construían las primeras páginas web. Cada vez que ibas a una dirección de la web, veías siempre el mismo documento, que podía contener enlaces a otros documentos.
+
+Es decir, nada de teclear un término de búsqueda en un formulario y obtener un listado de sitios web, ni por supuesto nada muchísimo más completo como poder escribir correo o publicar nada en la web usando sólo un navegador.
+
+(¡Esto no es del todo cierto! WorldWideWeb, el primer navegador, incorporaba un editor de páginas web. Pero sólo servía para editar el sitio web hospedado en el mismo ordenador donde ejecutábamos el navegador.)
+
+Últimamente pienso que nos debíamos haber quedado ahí, pero en 1993 apareció el "Common Gateway Interface", unas siglas bastante inescrutables excepto por el "Interface", con lo que lo dejaremos en CGI a secas.
+
+El CGI permite que un servidor web responda a la petición de un navegador no yendo a buscar un documento HTML dentro del ordenador, sino ejecutando un programa que genere la respuesta.
+
+Si os atrevéis con el terminal y tenéis Python instalado, podéis viajar al pasado siguiendo los siguientes pasos:
+
+1. Cread un directorio vacío.
+
+2. Cread un directorio con el nombre cgi-bin dentro del primer directorio.
+
+3. Cread un archivo con el nombre hola dentro del directorio cgi-bin con el siguiente contenido:
+
+```
+#!/bin/sh
+
+echo Content-type: text/html
+echo
+echo Hoy es $(date)
+```
+
+4. Haced que este archivo sea ejecutable con el siguiente comando:
+
+```
+chmod ugo+x cgi-bin/hola
+```
+
+5. Ejecutad un servidor web apropiado:
+
+```
+python3 -m http.server --cgi
+```
+
+6. Visitad http://0.0.0.0:8000/cgi-bin/hola y comprobad el resultado. Recargad la página varias veces y veréis que se actualiza la fecha, con lo que ya tenéis una página dinámica.
+
+Con este invento relativamente sencillo ya prácticamente podemos llegar a tener gran parte de la web hasta 2004 o así.
+
+El CGI es sencillo, pero algo tedioso. Cuando un programador escribe más de dos o tres programas CGI, se da cuenta de que se repiten los mismos patrones una y otra vez. El ejemplo anterior utiliza el lenguaje shell, pero la historia que conservamos parece indicar que el lenguaje de programación Perl fue de los más usados en los albores del CGI pues era de las maneras más convenientes de reutilizar código para implementar sitios web dinámicos mediante CGI.
+
+Seguramente uno de los primeros módulos para escribir CGI en Perl es CGI.pm, del que la versión más antigua que se conserva en el principal repositorio de código Perl es la 2.10 de 1995.
+
+Perl es un lenguaje de programación de propósito general que apareció en 1987, mucho antes que la web y el CGI.
+
+Allá por 1993, un programador comenzó a escribir un lenguaje de programación con el propósito de implementar su página personal. La primera versión oficial salió en 1997, con el nombre PHP.
+
+A diferencia del CGI, hoy en día es muy complejo reproducir la experiencia exacta de desarrollo de las primeras versiones de PHP, pero si tenéis PHP instalado, podéis hacer algo relativamente similar creando un archivo con el nombre index.php y el siguiente contenido:
+
+```
+<form>
+ <label>a: <input name="a" type="number">
+ <label>b: <input name="b" type="number">
+ <input type="submit">
+</form>
+
+<?php
+ if ($_GET['a'] && $_GET['b']) {
+   echo $_GET['a'] + $_GET['b'];
+ }
+?>
+```
+
+Luego, ejecutad el siguiente comando:
+
+```
+php -S 0.0.0.0:8000
+```
+
+Entonces visitad http://0.0.0.0:8000 con vuestro navegador, introducid dos números en los campos de entrada, pulsad el botón y veréis la suma.
+
+Implementar la misma funcionalidad con CGI, incluso reutilizando código como CGI.pm, es bastante más tedioso y requiere más conocimientos que usar PHP. Por eso el ejemplo que os he puesto de CGI es algo tan inútil.
+
+Yo mismo descubrí PHP por el año 2000 y, como muchísima otra gente, quedé hipnotizado por lo que en el momento era una de las mejores maneras de hacer cosas útiles con un ordenador para otra gente.
+
+A diferencia del CGI, mediante el cual nacieron las webs dinámicas, PHP no trae nada nuevo directamente al usuario de la web, sólo intenta simplificar la vida al programador. Pero facilitando la vida al programador, seguramente PHP aceleró el desarrollo web permitiendo a los programadores traer webs más útiles.
+
+Como muchos sabréis, ni PHP ni Perl han sido el final. Hoy en día, prácticamente todos los lenguajes de programación se usan para desarrollo web, con todo tipo de código reutilizable que cada vez nos aleja más del CGI.
+
+Paralelamente al desarrollo de CGI, PHP y las webs dinámicas, en 1995 apareció el primer navegador con JavaScript. A diferencia de los ejemplos anteriores, donde el código que os he puesto se ejecuta en el servidor web, JavaScript se ejecuta en vuestro navegador. Esto permite otro tipo de interacciones que ejemplificaremos con Google Maps lanzado en 2005, que ya nos permitía desplazarnos por el mapa de una manera mucho más interactiva que lo que nos permite ninguna web dinámica sin JavaScript.
+
+Casi tres décadas más tarde, curiosamente el CGI sigue existiendo pero la mayoría del desarrollo web no tiene casi nada que ver con el de 1995 con PHP y JavaScript. En mi opinión, los ejemplos que os he puesto anteriormente omiten algo de tedio, pero son mayormente representativos de esas maneras de desarrollo, mientras que me marea simplemente pensar en poner un ejemplo mínimo de desarrollo web moderno.
+
+El fenómeno que observamos en mi opinión se repite por todo el ámbito del desarrollo del software: cada vez el paso inicial de desarrollo nos lleva más lejos, pero también es más difícil de abarcar.
+
+Lo que me ha llevado a escribir este artículo es que esta mañana he decidido jugar con una idea que tenía desde hace tiempo en la cabeza, y mi prototipo han sido 100 líneas de Python con WSGI, un descendiente directo del CGI. Para otras ideas sin duda me habría ido a algo mucho más moderno y potente, pero para esta en concreto dudo que hubiese encontrado un camino más corto que las maneras más primitivas del desarrollo web. Pero, ¿habría tomado este camino si me hubiese iniciado en la programación web allá por 2013 con la primera versión de React?
+
+Yo creo que no. Y quizá ni lo hubiese intentado.
diff --git a/blog/content/2026/04/el-enemigo-en-casa.gmi b/blog/content/2026/04/el-enemigo-en-casa.gmi
new file mode 100644
index 00000000..36eb9fa3
--- /dev/null
+++ b/blog/content/2026/04/el-enemigo-en-casa.gmi
@@ -0,0 +1,35 @@
+# 2026-04-08 El enemigo en casa
+
+Allá por 2013 cogí una webcam (diría que una de Playstation) y monté un pequeño sistema de videovigilancia para poder echar un ojo a la gata desde fuera de casa. Un programilla que sabía detectar movimiento y unos cuantos scripts hacían que recibiese un email con un vídeo cuando la gata pasaba delante de la cámara. Fue algo bastante práctico aunque dejé de usarlo en algún momento.
+
+Desde luego no fui un pionero, pero creo que poco después el tema de la domótica se puso muy de moda. No sólo entre la gente más acostumbrada a trastear, sino que además se sumó el público más general, en parte gracias a que comenzaron a aparecer muchos aparatos para estos menesteres con costes más bien asequibles que suponían mucha menos complicación que mi chapuza sujeta a base de chicle.
+
+Pero este boom se vio acompañado de mucha gente obsesionándose con aprender a marchas forzadas temas de seguridad informática para proteger su red doméstica por si estos nuevos y convenientes aparatos resultaban ser malignos. Ni trabajando en una empresa con muchos técnicos en redes había oído mencionar tanto el término vLAN.
+
+La verdad que en su momento tanta paranoia me parecía un poco exagerada. Mi razonamiento era más bien que a pesar de unos cuantos incidentes preocupantes, simplemente bastaría con usar productos de marcas más o menos establecidas con cierta necesidad de mantener su reputación. Es decir, no meter en casa un aparato de quién sabe qué empresa que igual desaparece al mes que viene debería bastar para dormir tranquilo.
+
+(En 2024 me hice con un par de aparatos de este tipo que sigo teniendo conectados y con los que realmente no he tomado muchas precauciones. Pero seleccioné cuidadosamente la marca que elegí, entre otros motivos porque me daba bastante confianza.)
+
+Además, incluso aunque nos colasen un dispositivo malicioso, tampoco me parecía una amenaza tan seria.
+
+Creo que en ese momento mi razonamiento ya no era muy acertado, pero además últimamente hay acontecimientos que me hacen replantearme mucho más mi postura y mis recomendaciones.
+
+Los ataques de denegación de servicio no son algo nuevo; desde hace mucho tiempo hay actores malignos que bombardean servicios de Internet con una avalancha de peticiones que pueden incluso tumbar el servicio y causar muchos problemas a su operador. Sin embargo, hasta hace poco estos ataques tenían más bien pocos objetivos y en general se trataba de objetivos que ya tenían que preocuparse de defenderse ante todo tipo de hostilidades, y en la mayoría de casos, podían disponer de recursos para protegerse.
+
+Sin embargo, en tiempos recientes estos ataques se han expandido significativamente. Incluso servicios muy pequeños hospedados por particulares reciben ataques de este tipo constantemente. Incluso yo mismo he recibido cierta carga que por suerte no ha tenido mayores consecuencias que costarme un par de euros mensuales, pero nada en comparación con lo que veo sufrir a otros.
+
+Es especialmente difícil defenderse de estos ataques; es muy complicado identificar y bloquear el tráfico malicioso, pues proviene de muchísimas conexiones a Internet domésticas.
+
+Que es precisamente lo que se conseguiría controlando una buena cantidad de dispositivos de domótica maliciosos.
+
+(Sí es cierto que no es la única manera de conseguirlo. Hay empresas que ofrecen este tipo de "acceso a Internet", en general porque controlan aplicaciones para móviles "dudosas" y que por tanto pueden canalizar tráfico a través de los dispositivos en los que alguien ha instalado estas aplicaciones.)
+
+Lo curioso del caso es que las precauciones que se pusieron de moda para controlar los dispositivos de domótica en general no serán efectivas para prevenir esto, pues estas medidas se centraban en aislar estos dispositivos para que no pudiesen acceder al resto de nuestra red. Pero para usarlos para lanzar un ataque no hace falta que se conecten a otros dispositivos de nuestra red; basta con que puedan conectarse a Internet.
+
+Y la mayoría de estos dispositivos necesitan conectarse a Internet para ofrecer su modo de funcionamiento "fácil" en los que usan la infraestructura del fabricante en vez de requerirnos mantener nuestra propia infraestructura. (Es decir, en el caso de una cámara, por ejemplo, la cámara va enviando el vídeo al servicio del fabricante donde queda almacenado, y a posteriori nosotros nos conectamos al servicio del fabricante para ver las grabaciones.) Y por otras modernidades, a no ser que el fabricante del aparato lo facilite expresamente, no es tan fácil restringir la conexión a Internet de estos aparatos para que sólo se puedan conectar a lo imprescindible para su funcionamiento y no puedan usarse para lanzar ataques de denegación de servicio distribuidos.
+
+Con lo que yo antes hubiese recomendado despreocuparse un poco del tema, pero ahora me veo obligado a recomendar mucha cautela.
+
+Lamentablemente, la única alternativa segura (aparte de no usar estos dispositivos) sería usar sólo aparatos que no necesiten conexión a Internet para funcionar, pero esto necesariamente implica mucho más trabajo por nuestra parte, e incluso en ocasiones no será viable.
+
+Fuera de eso, sólo puedo insistir en mi consejo de limitarse a fabricantes que tengan más que perder que que ganar participando en actividades maliciosas. Pero dentro de esto seguimos teniendo un riesgo real de facilitar estos ataques y no es fácil mitigar este riesgo.