
# El Proyecto

Este proyecto es un pequeño experimento para capturar y transcribir en tiempo real un flujo de audio de una emisora de radio (RAC1) y mostrar los fragmentos más relevantes mediante una interfaz web minimalista. Todo automatizado con Docker.

También es una prueba personal de *vibe coding*, hecha con un objetivo claro pero sin planificación previa—simplemente dejándome llevar por la intuición para ver hasta dónde puede acelerarse el desarrollo. Aunque el proyecto funciona, reconozco que con este proceso se pierde parte del placer de un conocimiento estructurado y de una planificación que haría la solución más robusta y escalable.

Este estilo rápido e improvisado de programar tiende a omitir ciertas abstracciones y estructuras que a menudo son las que permiten una creatividad más profunda: aquella que emerge cuando las herramientas no solo funcionan, sino que se entienden *por qué* funcionan.

## 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


Pequeño experimento que captura y transcribe en tiempo real un stream de radio con Whisper, y muestra las palabras clave en una web de estilo retro.

Transcripción en directo de una emisora de radio con Whisper en modo Vibe Coding


# 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.

Durante el último mes me he sumergido en un proyecto personal que quería ser juego, experimento, y quizá un poco protesta: **WordGuardian**.

Una web para jugar con definiciones absurdas, reales e inventadas. Pero también una ventana a la riqueza semántica de Wikidata y un baño de agua fría sobre la realidad de crear una web indie en 2025.

## 🧩 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/es/game)  
📖 Código abierto (pronto en GitHub)  

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

© Francesc López Marió, 2025


Durante el último mes me he sumergido en un proyecto personal que quería ser juego, experimento, y quizá un poco protesta: **WordGuardian**. Una web para jugar con definiciones absurdas, reales e inventadas. Pero también una ventana a la riqueza semántica de Wikidata y un baño de agua fría sobre la realidad de crear una web indie en 2025.

El proyecto WordGuardian


## 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.