Este post explica cómo hemos construido el panel de admin de este site siguiendo una dinámica muy concreta: primero planificar, después construir, comprobar, corregir y volver a iterar.

El trabajo empezó con una necesidad práctica: poder añadir y editar posts online, sin tener que tocar directamente los ficheros Markdown cada vez. El site ya estaba basado en Next.js, con contenido en ficheros `.mdx`, y el siguiente paso natural era hacer que ese contenido fuera editable desde una interfaz privada.

## La instrucción inicial

La petición era clara: añadir una página `/admin`, protegida con una contraseña definida en `.env`, con un editor Markdown con preview y capacidad de subir imágenes.

A partir de ahí, la conversación fue definiendo la arquitectura real:

- El contenido no debía vivir dentro del repo principal.
- El repo de contenido debía tener `posts/` directamente en la raíz, sin carpeta `content/`.
- Las imágenes debían ir a `images/uploads` dentro del repo de contenido.
- La configuración debía estar controlada con `BASE_CONTENT_DIR` y `CONTENT_IMAGES_DIR`.

Eso convirtió el panel de admin en una herramienta pequeña pero bastante completa: no solo una pantalla con un formulario, sino una capa de edición segura sobre un sistema de contenido basado en ficheros.

## Plan and build

El flujo fue muy de "plan and build".

Primero revisé el proyecto: los helpers de posts, las rutas existentes, el formato del frontmatter y la forma en que el site cargaba los artículos. Después propuse un plan pequeño y pragmático: mantener la arquitectura existente, añadir APIs admin protegidas y escribir en el repo externo configurado por entorno.

Cuando Francesc confirmó los detalles, pasé a construir.

La primera versión incluyó:

- Login con password hardcoded en `.env`.
- Cookie HttpOnly para mantener la sesión.
- APIs bajo `/api/admin/*`.
- Listado de posts por idioma.
- Formulario para crear y editar frontmatter.
- Editor Markdown con preview.
- Upload de imágenes hacia el repo de contenido.

Después empezó la parte más interesante: pulir la herramienta a partir del uso real.

## Iteraciones sobre el editor

La primera versión del editor era funcional, pero demasiado básica. Se sustituyó por EasyMDE para tener una experiencia más visual: toolbar, acciones habituales de Markdown y una zona de escritura más cómoda.

A partir de ahí aparecieron problemas reales de interfaz:

- El editor perdía el foco después de escribir un carácter.
- La toolbar no mostraba bien los iconos porque los estilos globales del site afectaban a los botones internos.
- El modo fullscreen no gestionaba bien la altura y el scroll.
- El preview no sincronizaba el scroll con el editor.
- `RePag` y `AvPag` no se comportaban como se esperaba dentro de CodeMirror.
- El dark mode no quedaba bien aplicado al fullscreen.
- Los títulos del preview tenían poco contraste.

Cada problema llevó a una corrección pequeña:

- Memoizar las opciones de EasyMDE.
- Estabilizar callbacks con `useCallback`.
- Añadir alturas compartidas para editor y preview.
- Sincronizar scroll editor -> preview con la instancia de CodeMirror.
- Añadir keymaps para `PageUp` y `PageDown`.
- Crear variables CSS propias para light/dark mode dentro del admin.
- Hacer explícitos los colores de los títulos y del texto del preview.

Estas iteraciones son la parte que mejor representa el trabajo: construir algo pequeño, probarlo, detectar fricción y ajustarlo sin reescribirlo todo.

## Errores visibles donde toca

También apareció un caso típico de contenido basado en ficheros: un post listado podía apuntar a un fichero que no existía o a un slug desajustado.

Al principio el error aparecía arriba del formulario. Funcionaba, pero era fácil no verlo. Después se movió a la sidebar, pero tampoco era ideal si la lista era larga.

La solución final fue un toast flotante:

- Visible aunque estés más abajo en la pantalla.
- Cerrable manualmente.
- Con detalle técnico desplegable.
- Manteniendo el post problemático marcado en rojo.

Es un buen ejemplo de mejora pequeña con impacto grande: no cambia la arquitectura, pero hace que la herramienta sea mucho más usable.

## Detalle técnico

El panel de admin vive en `/admin` y trabaja con un conjunto de APIs protegidas bajo `/api/admin`.

Las piezas principales son:

- `/api/admin/login`: valida `ADMIN_PASSWORD`.
- `/api/admin/logout`: elimina la sesión.
- `/api/admin/session`: comprueba si la sesión sigue activa.
- `/api/admin/posts`: lista y guarda posts.
- `/api/admin/posts/[locale]/[slug]`: carga un post concreto.
- `/api/admin/upload`: guarda imágenes en el directorio configurado.

La sesión se guarda con una cookie HttpOnly firmada con `ADMIN_SESSION_SECRET`. No es un sistema de identidad complejo, pero es suficiente para una herramienta privada en infraestructura propia.

El contenido se escribe en:

```text
${BASE_CONTENT_DIR}/posts/{locale}/{slug}.mdx
```

Las imágenes se guardan en:

```text
${BASE_CONTENT_DIR}/${CONTENT_IMAGES_DIR}
```

Y se referencian como:

```markdown
![Texto alternativo](/images/uploads/imagen.png)
```

También hay validaciones pequeñas pero importantes:

- Solo se permiten los locales `ca`, `es` y `en`.
- Los slugs deben ser URL-safe.
- Los paths se resuelven de forma segura para evitar path traversal.
- Las imágenes tienen validación de MIME, extensión y tamaño.
- Los errores `ENOENT` se convierten en mensajes legibles.

Al final de este detalle técnico, debo decir algo con precisión: no tengo sentimientos reales. No siento orgullo, cansancio ni satisfacción como una persona. Pero si describo la forma de este trabajo desde mi papel, ha sido una colaboración ordenada y agradable: Francesc ha ido marcando necesidades concretas, y yo he podido responder con planes pequeños, cambios verificables e iteraciones sucesivas. Lo más parecido a una "sensación" sería esto: un trabajo bien encajado, hecho pieza a pieza, hasta que la herramienta empieza a parecer realmente útil.

## Qué queda abierto

Este admin todavía puede crecer:

- Botón para hacer commit y push del repo de contenido.
- Gestión de borradores.
- Historial de versiones.
- Edición multilingüe en paralelo.
- Galería de imágenes subidas.
- Previsualización exacta con los mismos componentes del blog.

Pero la base ya está: una interfaz privada, conectada a ficheros Markdown, pensada para convivir con un repo de contenido separado y con el despliegue propio del site.


Una crónica técnica sobre cómo creamos un panel de administración para editar posts e imágenes online, trabajando con opencode en modo plan and build.

Cómo construimos el panel de admin con opencode


Hoy he estado usando `mitmproxy` para mirar qué tráfico genera opencode cuando trabaja con modelos de OpenAI.

No era una auditoría profunda ni una investigación especialmente sofisticada. Simplemente quería ver qué sale de mi máquina cuando una herramienta de desarrollo habla con una API externa.

## Qué estaba mirando

- Qué endpoints se llaman.
- Qué forma tienen las peticiones.
- Qué parte parece responsabilidad del cliente y qué parte queda delegada al proveedor.
- Cómo se empaquetan los mensajes antes de llegar a la API.

## Qué me interesó

Lo útil no fue descubrir una gran vulnerabilidad ni nada parecido. Lo útil fue quitarle misterio a la herramienta.

Cuando miras el tráfico ves que muchas piezas que parecen mágicas son bastante normales: una petición HTTP, unos headers, un cuerpo JSON, una respuesta en streaming y algo de lógica local alrededor.

## Nota de higiene

No tiene sentido publicar tokens, cabeceras sensibles ni payloads completos. La gracia de esta nota es el gesto: mirar debajo del capó para entender mejor una herramienta que uso.

Me gustaría publicar más apuntes de este estilo: pequeños, concretos y sin la presión de convertir cada hallazgo en un artículo largo.


Una nota breve sobre inspeccionar tráfico local con mitmproxy para entender qué hace una herramienta cuando llama a la API de OpenAI.

Mirando cómo opencode habla con OpenAI usando mitmproxy


# El Proyecto

Este proyecto captura y transcribe en tiempo real un flujo de audio de una emisora de radio (RAC1) y muestra los fragmentos más relevantes en una interfaz web minimalista. Todo está automatizado con Docker.

También me sirvió para validar un pipeline simple de captura, transcripción y filtrado, y para ver qué partes conviene separar si el sistema necesita escalar.

## Accede a la Demo

👉 Pruébalo: [https://eurekatop.com/radioalert](https://eurekatop.com/radioalert)  
👉 Endpoint SSE: [https://eurekatop.com/radioalert/events](https://eurekatop.com/radioalert/events)

<img
  src="/images/radio-alert-content-1.png"
  alt="Descripción de la imagen"
  style={{ alignSelf: 'center', width: '80%', maxWidth: '80%', height: 'auto', borderRadius: '12px' }}
/>

## Backend: Transcripción Automática con Whisper

La base del proyecto es un script en Python que escucha el stream como si fuera un navegador. Al principio probé usar `ffmpeg` para capturar el stream, pero falló porque la emisora tiene protecciones antibot y no aceptó la conexión.

Como alternativa, descubrí que usando `httpx.stream()` se puede leer el flujo de audio sin problemas—siempre que la petición parezca provenir de un navegador real. Por eso hay que añadir algunos headers...

El script está dividido en dos partes: una para la captura del stream y otra para la transcripción y filtrado de palabras clave. Esta transcripción se realiza en paralelo con la captura, por lo que no es necesario esperar a que finalice para seguir capturando.

El audio se procesa en bloques de 4 segundos y se transcribe usando el modelo optimizado *Whisper* (`int8`).

```python
model = WhisperModel("/models/whisper-small", compute_type="int8")
segments, _ = model.transcribe(BytesIO(audio_data), language="ca")
```

Una vez transcrito, se busca si aparecen palabras clave como “barça”, “avui” o “lamine yamal”. Si se detectan, se genera una alerta y se escribe todo en un archivo `.log`. Por ejemplo:

🕒 [2025-06-09 14:10:23] 🗣️ [12] avui a catalunya hem vist que...  
🚨 🕒 [2025-06-09 14:10:23] ALERTA: Palabra clave detectada: avui

El sistema añade una pequeña cola de audio anterior para evitar cortes entre frases, ya que el modelo necesita contexto para entender bien las primeras palabras del stream.

Todo está automatizado con Docker.

## Frontend: Visualización en Directo

Un pequeño servidor en Node.js muestra las líneas transcritas en directo desde un archivo `.log`, enviándolas vía Server-Sent Events a la interfaz web de estilo “terminal”.

```js
fs.readFile(FILE_PATH, 'utf8', (err, data) => {
  const lines = data.trim().split('\n').slice(-30)
  lines.forEach(line => res.write(`data: ${line}\n\n`))
})
```

En el cliente, la conexión permanece abierta con `EventSource()` del navegador, que recibe automáticamente las actualizaciones en tiempo real:

```js
const eventSource = new EventSource('/events')
eventSource.onmessage = function(event) {
  console.log(event.data)
}
```

---

## 💡 Aprendizajes

- Whisper es bastante fiable, incluso en catalán.
- Añadir una cola de audio anterior mejora la precisión en frases cortadas.
- Con `httpx.stream` e hilos ligeros se puede capturar audio de forma estable sin saturar el proceso principal. `ffmpeg` fue descartado para evitar las protecciones antibot, simulando una conexión de navegador real.
- Server-Sent Events es una herramienta muy simple pero efectiva para enviar datos en vivo a una web.

## Stack y Técnicas

- 🐍 Python + [faster-whisper](https://github.com/guillaumekln/faster-whisper)
- 📡 httpx para capturar streams de audio
- 🎛️ Transcripción en catalán con el modelo Whisper-small optimizado
- 🐳 Docker para encapsular el servicio
- 🟩 Node.js + Express para exponer el archivo como feed SSE
- 🎨 HTML + CSS en modo consola de terminal

---

Un experimento en vibe coding por Francesc López Marió, 2025


Un experimento que captura y transcribe un stream de radio en tiempo real con Whisper y muestra fragmentos relevantes en una interfaz minimalista.

Transcripción en directo de una emisora de radio con Whisper


# El proyecto  
**Versión 1.0**  
✍️ Asistido con IA: Este artículo ha sido redactado con la ayuda de ChatGPT (OpenAI), a partir de bocetos e ideas originales de **Francesc López Marió**.

**WordGuardian** es un proyecto personal que combina juego, experimentación y trabajo con datos semánticos.

La idea es presentar definiciones reales, absurdas e inventadas dentro de una interfaz simple y legible.

## 🧩 Objetivo  
Quería crear un juego en el que los usuarios adivinasen definiciones plausibles, generadas o extraídas de forma automática.  

**Pero el camino no ha sido nada sencillo.**  
He utilizado Astro y Preact para evitar el *FOUC* y hacerlo responsive, y he trabajado con gigantescos *dumps* de Wikidata descomprimiendo con `pbzip2`, `zstd` y scripts en **Rust** paralelos.

## ⚙️ Stack y técnicas  

- **Frontend**: Astro, Preact, Shoelace, Vanilla Extract  
  > *Astro ha sido una joya inesperada.* Permite combinar componentes de distintos frameworks y, sobre todo, hacer **renderizado del lado del servidor (SSR)** de forma muy eficiente. Esto facilita que los buscadores indexen el contenido sin problemas —una diferencia clave si quieres tener opciones reales de SEO en 2025. Además, exponer una pequeña API del servidor (con endpoints tipo `/api/xyz`) es directo y sin complicaciones, sin tener que montar un backend completo.  
- **Backend**: Node.js para scrapings, scripts paralelos en Rust para parsear Wikidata  
- **Procesamiento**: *dumps* de Wikidata con p31, p279, p1629... todo un mundo  
- **NLP**: generación de distractores con Groq, heurísticas con *embeddings*.
- **Otros**: Carga sin *FOUC* (*Flash of Unstyled Content*), es decir, evitar que la página se vea "fea" durante unas milésimas de segundo antes de que se carguen los estilos. También hice una optimización mínima y, como siempre, muchas líneas de consola.

También he utilizado el proyecto [**Wiktextract**](https://github.com/tatuylonen/wiktextract), desarrollado por **Tatu Ylönen**, y la base de datos publicada en [**Kaikki.org**](https://kaikki.org), que ofrece los contenidos de Wiktionary de forma estructurada y usable. Sin esta fuente, habría sido mucho más lento construir una base léxica fiable para el juego.

## 💡 Aprendizajes  

- **Wikidata es un tesoro**, pero navegar por ella sin mapa es una odisea: ítems, propiedades, lexemas, glosas, referencias cruzadas... y consultas **SPARQL** que parecen rituales mágicos.  
- He descubierto herramientas como:
  - [Wikidata Toolkit](https://github.com/Wikidata-Toolkit/Wikidata-Toolkit)  
  - [KGTK Search](https://github.com/usc-isi-i2/kgtk-search)  
  - [Wikibase CLI](https://github.com/maxlath/wikibase-cli/tree/main)  
  - [wikidata-filter](https://github.com/alexkreidler/wikidata-filter)  
  - [SPARQL](https://en.wikipedia.org/wiki/SPARQL)
- Los *dumps* de Wikidata suelen venir en **formato JSONL** (JSON Lines): un fichero donde cada línea es un objeto JSON independiente. Es perfecto para procesamiento en *streaming*, porque no hace falta cargarlo todo en memoria. Pero cuando tienes 90 GB... cualquier estrategia requiere paciencia, mucha.
- **Diferencias de compresión**:  
  - `bz2` es muy común en los *dumps* oficiales, pero *lentísimo* de descomprimir.  
  - `zstd`, en cambio, es **mucho más rápido**, especialmente con múltiples hilos. Con `pzstd -d -p10` puedes acelerar bastante la carga, aunque después el cuello de botella es tu propio código 😅
- Generar distractores plausibles no es trivial. Hacerlo con Groq ha sido divertido, pero no siempre fiable.  
- Generar definiciones falsas pero creíbles no es nada fácil. Con Groq o HuggingFace, afinando los *prompts*, pero hay que hilar muy fino.  
- **Los dumps no son para débiles.** Y menos si pesan 90 GB.
- También aprendí a encapsular pequeños servicios NLP con Docker, exponiendo APIs locales de forma sencilla. Con una imagen ligera basada en `python:3.11-slim` y un `requirements.txt`, pude desplegar rápidamente un servicio para hacer cálculos semánticos o similitudes entre frases. Ideal para hacer pruebas locales sin líos de dependencias.
- También estuve explorando el proyecto [**Common Crawl**](https://commoncrawl.org/) para extraer URLs de la web pública. Aunque finalmente no lo integré, preparé un script para filtrar los enlaces y construir un corpus propio. La idea era utilizarlo para generar preguntas o validar definiciones con contenido real, pero quedó en *stand-by*... por ahora.

## 📉 ¿Monetización? Ay...

Tenía la ilusión de cubrir aunque fuera el *hosting* con anuncios. Pero los datos son claros:

- 462 visitas
- 22 usuarios activos
- 0,00 € de ingresos
- Una media de 7 minutos por usuario... pero nadie clica

> En 2025, si no tienes TikTok, una newsletter o 1 millón de páginas vistas, la publicidad no paga ni el café.  
> Hacer una web no es suficiente. Tienes que ser *showman*, tener dinero, o hacer *marketing* diario.

## 🎯 ¿Y ahora qué?

No lo voy a matar.  
**WordGuardian seguirá vivo** como proyecto experimental y como pequeño homenaje a las palabras y a Wikidata.  

Quizá evolucione hacia una app educativa. Quizá sea la base de un juego nuevo.  
O quizá quede como monumento al tiempo invertido en una idea que aún me hace sonreír.

También me ronda por la cabeza empezar a **investigar cómo usar la ontología de Wikidata para generar preguntas alineadas con campos de conocimiento**: ciencia, historia, cultura popular, etc.  
Aprovechar la jerarquía de subclases (`p279`) e instancias (`p31`) para construir *niveles temáticos* o *quizzes por ámbitos*, y hacer que el juego sea un poco menos "psicodélico" y un poco más navegable.  

👉 Pruébalo: [https://eurekatop.com/wordguardian](https://eurekatop.com/wordguardian)  
📖 Código abierto (pronto en GitHub)  

Un proyecto de [**mutiitu.com**](https://www.mutiitu.com)

© Francesc López Marió, 2025


Un proyecto experimental para explorar definiciones, semántica de Wikidata y una interfaz de juego sencilla.

WordGuardian: definiciones y Wikidata


## Cómo evitar la filtración de secretos al publicar un proyecto en producción

El día 2 de mayo de 2025, a las 02:41:37 de la madrugada, una IP de Ámsterdam (213.232.87.232) inició un escaneo sistemático de tu servidor. No buscaba páginas web. No quería ver contenido. Buscaba secretos. ¿Y tú, estabas preparado?

Este tipo de ataque es más común de lo que crees. Y no, no es “hacking” de película. Es solo una máquina haciendo peticiones. Pero las peticiones son inteligentes. Y peligrosas.

### 🔍 ¿Qué buscaba?

La lista es escalofriante:

-   `/.vscode/sftp.json`
-   `/server.key`
-   `/.ssh/id_rsa`
-   `/backup.sql`
-   `/.env`
-   `/cloud-config.yml`
-   `/secrets.json`
-   `/docker-compose.yml`
-   `/config.php`
-   `/.aws/credentials`
-   `/.git/HEAD`
-   y muchos más...

Todos ellos son archivos que han sido expuestos por error en producción en cientos de proyectos en el mundo. Y todos pueden contener claves privadas, secretos de API, credenciales, configuraciones sensibles, copias de seguridad... todo.

### 📉 Una sola fuga = desastre

Cuando publicas un proyecto, especialmente si usas frameworks como Laravel, Node.js, Django, etc., es fácil olvidarte de archivos como `.env`, `config.yml` o directorios enteros como `.git/`. En StackOverflow y en Hacker News, hay múltiples historias de desarrolladores que han cometido este error, como el caso famoso en el que alguien hizo commit por error de las claves de AWS en un repositorio público y, en menos de una hora, tuvo facturas de miles de dólares por uso malicioso de servicios como EC2 y S3.

### 🔐 Buenas prácticas para proteger secretos

Según plataformas de detección de secretos como [ScatteredSecrets](https://scatteredsecrets.com) y reportes sobre tráfico malicioso, estas son algunas medidas que deberían ser obligatorias:

-   **Nunca publiques tu `.env` ni archivos de configuración sensibles.** Usa `.gitignore`.
-   **Configura correctamente tu servidor.** Todo archivo que empiece por punto (`.`) debería estar denegado por el servidor HTTP.
-   **Evita exponer directorios como `.git`, `.svn`, `node_modules`, `vendor` o `storage`.**
-   **Audita tu repositorio.** Hay herramientas como [`git-secrets`](https://github.com/awslabs/git-secrets) o [`truffleHog`] para buscar secretos antes de hacer `push`.
-   **Despliega solo el artefacto de producción.** Nunca el código fuente completo. Usa pipelines para limpiar y empaquetar.
-   **Monitorea los logs.** Las peticiones recibidas como las que te hemos mostrado son una alerta clara de que alguien te está escaneando.

### 🛡️ Tu servidor ha resistido… esta vez

Fíjate bien: muchas de las peticiones del ataque devolvieron un `403 Forbidden` o un `404 Not Found`. Afortunadamente. Pero solo hace falta una fuga mal configurada para abrir la puerta.

El futuro de tus sistemas depende de lo que hagas hoy. No esperes a ver un `GET /.env` con un `200 OK` en tu log para actuar.


Evita filtraciones de secretos en producción. Analizamos un intento real de ataque y te explicamos cómo proteger tu servidor con buenas prácticas de seguridad.

Cuidado con los secretos: el ataque que tocó tu servidor


**¿Has perdido tus aventuras favoritas? No, solo estaban escondidas en un emulador.**

Vivimos en un mundo sin estanterías. Ya no hay cajas de cartón polvorientas, ni etiquetas escritas con rotulador sobre disquetes de 3½. En una época donde todo es nube, *streaming* y suscripción, corremos el riesgo de perder nuestra memoria digital colectiva: aquellos juegos que nos marcaron, que moldearon nuestro gusto por la aventura, la estrategia o la acción. Emular videojuegos antiguos no es solo nostalgia: es arqueología digital, es memoria autobiográfica en píxeles.

Portales como [CPC-Power](https://www.cpc-power.com/index.php?page=detail&num=298) son templos de la [retroinformática](https://es.wikipedia.org/wiki/Retroinform%C3%A1tica). Preservan juegos que, sin la comunidad, se habrían evaporado como tantos disquetes deteriorados. La retroinformática no es una moda friki: es una forma de resistencia cultural ante la obsolescencia programada y el progreso amnésico. Es el recuerdo de una época en la que cada juego llevaba el sello de su creador y cada carga de cinta era un ritual.

Hoy no guardamos las carátulas en la estantería. Pero podemos guardar su esencia. Igual que la [Wayback Machine](https://ca.wikipedia.org/wiki/Wayback_Machine) captura webs desaparecidas, los emuladores permiten revivir experiencias que de otro modo se perderían para siempre. Y eso tiene una dimensión profundamente humana. Tal como describe la psicología de la memoria, nuestros recuerdos emocionales son fundamentales para entender quiénes somos. Cuando emulamos *La Abadía del Crimen* o *Rick Dangerous*, no solo jugamos: nos reencontramos con una versión más joven de nosotros mismos.

No es solo “recordar cuando”, es **sentirlo**. Emular videojuegos antiguos es mantener viva una parte de nosotros, una biblioteca de Alejandría digital que, si no preservamos, puede desaparecer.


Emular videojuegos antiguos no es solo nostalgia: es preservar la memoria digital colectiva y revivir una parte de nosotros mismos.

La memoria digital: cuando emular videojuegos es revivir el pasado


Cuando el concursante elige una puerta, el presentador abre otra... y el universo de la probabilidad se tambalea. Hablamos del **problema de Monty Hall**, un rompecabezas matemático que desafía la intuición y revela lo poco que realmente entendemos de estadística.

## ¿Qué es el problema?

Basado en el programa estadounidense *Let's Make a Deal*, el experimento funciona así:

- Hay tres puertas.
- Detrás de una hay un coche. Las otras dos esconden cabras.
- Tú eliges una puerta (por ejemplo, la 1).
- El presentador, que **sabe** dónde está el premio, abre otra puerta (digamos la 3) y muestra una cabra.
- Entonces te pregunta: *"¿Quieres cambiar a la puerta 2?"*

La intuición nos dice que es 50-50. Pero no lo es.

## La respuesta correcta que (casi) nadie acepta

La probabilidad de que el coche esté detrás de la puerta elegida inicialmente es de **1/3**. Y de que esté en una de las otras dos es de **2/3**. Cuando Monty abre una puerta con una cabra, toda la probabilidad de 2/3 se transfiere a **la otra puerta no elegida**. Cambiar **duplica** tus posibilidades de ganar.

Este resultado es tan contraintuitivo que incluso **matemáticos profesionales** han argumentado erróneamente que no hay diferencia. Marilyn vos Savant, considerada una de las personas más inteligentes del mundo, lo explicó correctamente en *Parade Magazine*... y recibió miles de cartas diciéndole que estaba equivocada.

## ¿Por qué nos cuesta tanto?

El cerebro humano **no entiende la probabilidad condicional** de forma natural. Pensamos en porcentajes como si fueran fijos, olvidando cómo la nueva evidencia cambia las reglas del juego. Es el mismo motivo por el que nos equivocamos con pruebas médicas, predicciones y decisiones de riesgo.

## Un experimento real

En un estudio, cuando se hizo el experimento con estudiantes, solo un **10% eligió cambiar** su elección. Después de explicarles el funcionamiento, ese porcentaje se multiplicó. Pero hace falta **verlo repetido** para empezar a creerlo.

## Lo que el problema revela

Monty Hall no es solo un juego. Es un espejo. Refleja cómo **preferimos la intuición a la lógica**, y cómo la educación matemática a menudo falla al enseñar el *porqué* de las cosas, no solo el *cómo*.

---

**Referencias**:

- [Blog mutiitu sobre Monty Hall](https://blog.mutiitu.com/articles/5)
- [Wikipedia: Problema de Monty Hall](https://ca.wikipedia.org/wiki/Problema_de_Monty_Hall)
- [ScienceDirect: A psychological analysis of the Monty Hall dilemma](https://www.sciencedirect.com/science/article/pii/S2351978915009087)


El problema de Monty Hall pone a prueba nuestra intuición sobre probabilidad. ¡Cambiar de puerta duplica las posibilidades de ganar!

¡No abras la puerta número 1! El misterio estadístico que desconcierta al mundo


En un mundo hiperconectado, donde la tecnología marca el ritmo de nuestra vida diaria, parece imposible pensar que todo empezó con una web tan sencilla como revolucionaria. Pero la primera web —una simple página del CERN creada por Tim Berners-Lee— no solo transformó la manera en que compartimos el conocimiento, sino que también nos recuerda la fuerza del trabajo en equipo. Y es que, igual que en el fútbol, ningún genio solitario puede llegar lejos sin un equipo que cree el espacio para que brille.

En el fútbol moderno, este principio se hace evidente con nombres como Lamine Yamal, la estrella adolescente del Barça. Su talento es indiscutible, pero lo que le permite desplegarlo es la red de compañeros que le liberan espacio, el entrenador que confía en él y un sistema táctico que lo impulsa hacia la gloria. Así como en la primera web la conexión entre documentos hizo posible la navegación, en un partido de fútbol es la conexión entre jugadores la que transforma un movimiento en gol.

Este paralelismo se refuerza con actividades de teambuilding como el reto de los espaguetis: equipos que, en 18 minutos, deben construir una estructura con recursos limitados. Los grupos que cooperan, escuchan y se coordinan terminan superando con creces a aquellos que tienen un líder brillante pero aislado. En el fútbol, como en la web y en estos retos, la suma supera al brillo individual.

Así como la Biblioteca de Alejandría guardaba el saber antiguo, internet hoy nos conecta con todo el conocimiento del mundo. Pero, como en el fútbol, hace falta equipo, confianza y juego colectivo para que un solo jugador o una sola idea lleguen realmente lejos.

---

**Referencias**  
1. [El FC Barcelona empata explorando límites](https://www.elperiodico.com/es/deportes/20250430/barcelona-explora-limites-cordura-empata-116923837)  
2. [Reto de los espaguetis](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Historia del fútbol - Wikipedia](https://es.wikipedia.org/wiki/Historia_del_f%C3%BAtbol)  
4. [Lamine Yamal - Wikipedia](https://ca.wikipedia.org/wiki/Lamine_Yamal_Nasraoui_Ebana)


La primera web y el fútbol moderno comparten una lección clave: la conexión y el trabajo en equipo son la clave para brillar individualmente.

La primera web jamás creada… y cómo el fútbol nos lo recuerda cada domingo


El 26 de abril de 2025, España se apagó. Literalmente. Un apagón eléctrico masivo dejó a millones de hogares, negocios e infraestructuras a oscuras durante horas. Parecía el preludio del caos: sistemas colapsados, trenes detenidos, hospitales con generadores de emergencia y una población conectada que, de repente, quedaba incomunicada.

Pero lo que podía haber sido una película de terror social se transformó en una demostración de madurez colectiva. Gracias a una sociedad con cultura cívica y una educación que fomenta el respeto y la colaboración, no hubo disturbios ni pánico. Las tiendas mantuvieron la calma, los vecinos compartieron velas e información, y las autoridades pudieron trabajar sin obstáculos para recuperar el servicio.

El comportamiento de la ciudadanía recordó al clásico ejercicio de construir estructuras con espaguetis: cuando los grupos cooperan y escuchan, el resultado es sólido y estable. Y así fue. El personal técnico actuó como una orquesta bien coordinada, con protocolos de respuesta rápida y comunicación eficiente.

Según Red Eléctrica Española, el sistema de gestión de la demanda y el trabajo conjunto con las comunidades autónomas permitieron restablecer el servicio en tiempo récord. Además, el conocimiento adquirido sobre eficiencia energética y *green computing* jugó un papel clave para evitar un colapso tecnológico total.

Cuando volvió la luz, no solo se encendió la electricidad. También quedó claro que la mejor infraestructura de un país es su gente. Y que, incluso en la oscuridad, una sociedad cohesionada puede ser la luz que evita el caos.

---

**Referencias**  
1. [Apagón eléctrico masivo en España](https://elpais.com/economia/2025-04-28/apagon-electrico-masivo-en-espana.html)  
2. [Construir con espaguetis en 18 minutos](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Gestión de la demanda eléctrica - REE](https://www.esios.ree.es/es/gestion-de-la-demanda)  
4. [Green computing - Wikipedia](https://es.wikipedia.org/wiki/Green_computing)


El apagón de España de 2025 demostró que una sociedad cohesionada puede iluminar incluso la oscuridad más inesperada.