
# The Project

This project is a small experiment to capture and transcribe in real time an audio stream from a radio station (RAC1) and display the most relevant fragments using a minimalist web interface. All of it is automated with Docker.

It's also a personal *vibe coding* test, done with a clear goal but no prior planning—just following intuition to see how far one can accelerate development. Although the project works, I acknowledge that with this process you lose part of the pleasure of structured knowledge and planning, which would make the solution more robust and scalable.

This fast and improvised way of coding tends to skip certain abstractions and structures that are often what enable deeper creativity: the kind that emerges when tools not only work, but you understand *why* they work.

## Access the Demo

👉 Try it: [https://eurekatop.com/radioalert](https://eurekatop.com/radioalert)  
👉 SSE Endpoint: [https://eurekatop.com/radioalert/events](https://eurekatop.com/radioalert/events)

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

## Backend: Automatic Transcription with Whisper

The core of the project is a Python script that listens to the stream as if it were a browser. At first, I tried using `ffmpeg` to capture the stream, but it failed because the station has anti-bot protections and the connection was not accepted.

As an alternative, I found that using `httpx.stream()` allows reading the audio stream without issues—as long as the request looks like a real browser's. That’s why you need to add some headers...

The script is split into two parts: one for capturing the stream and another for transcription and keyword filtering. This transcription runs in parallel with the stream capture, so there's no need to wait for it to finish before continuing to capture.

The audio is processed in 4-second chunks and transcribed using the optimized *Whisper* model (`int8`).

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

Once transcribed, it checks for keywords like “barça”, “avui”, or “lamine yamal”. If any are found, it triggers an alert and logs everything to a `.log` file. For example:

🕒 [2025-06-09 14:10:23] 🗣️ [12] avui a catalunya hem vist que...  
🚨 🕒 [2025-06-09 14:10:23] ALERT: Keyword detected: avui

The system includes a short queue of previous audio to avoid cutting off sentence beginnings, since the model needs context to understand the stream correctly.

All of it is automated with Docker.

## Frontend: Live Visualization

A small Node.js server displays the transcribed lines live from a `.log` file, sending them via Server-Sent Events to the terminal-style web interface.

```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`))
})
```

On the client side, the connection remains open with the browser's `EventSource()`, which automatically receives real-time updates:

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

---

## 💡 Learnings

- Whisper is quite reliable, even in Catalan.
- Adding a buffer of previous audio improves accuracy in clipped sentences.
- With `httpx.stream` and lightweight threads, you can capture audio stably without overloading the main process. `ffmpeg` was initially used but discarded to avoid anti-bot protections by simulating a real browser connection.
- Server-Sent Events are a very simple yet effective tool to stream live data to a web app.

## Stack and Techniques

- 🐍 Python + [faster-whisper](https://github.com/guillaumekln/faster-whisper)
- 📡 httpx for capturing audio streams
- 🎛️ Catalan transcription with the optimized Whisper-small model
- 🐳 Docker to encapsulate the service
- 🟩 Node.js + Express to expose the file as an SSE feed
- 🎨 HTML + CSS in terminal-console style

---

A vibe coding experiment by Francesc López Marió, 2025


A small experiment that captures and transcribes a radio stream in real time using Whisper, and displays the keywords on a retro-style web interface.

Live Transcription of a Radio Station with Whisper in Vibe Coding Mode


# The Project  
**Version 1.0**  
✍️ AI-assisted: This article was written with the help of ChatGPT (OpenAI), based on original sketches and ideas.

Over the past month, I’ve immersed myself in a personal project that was meant to be a game, an experiment, and maybe a bit of a protest: **WordGuardian**.

A site for playing with absurd, real, and invented definitions. But also a window into the semantic richness of Wikidata and a cold reality check about building an indie website in 2025.

## 🧩 Objective  
I wanted to create a game where users guessed plausible definitions, either automatically generated or extracted.  

**But the journey was anything but simple.**  
I used Astro and Preact to avoid FOUC and keep it responsive, and I worked with massive Wikidata dumps, decompressed with `pbzip2`, `zstd`, and parsed using parallel **Rust** scripts.

## ⚙️ Stack & Techniques  

- **Frontend**: Astro, Preact, Shoelace, Vanilla Extract  
  > *Astro turned out to be a hidden gem.* It lets you combine components from different frameworks and enables efficient **server-side rendering (SSR)**. This helps search engines index the content properly —a key difference if you care about SEO in 2025. Also, exposing a small server API (via `/api/xyz` endpoints) is simple and clean, no need for a full backend.  
- **Backend**: Node.js for scraping; parallel Rust scripts for parsing Wikidata  
- **Processing**: Wikidata dumps using p31, p279, p1629... a whole world of data  
- **NLP**: distractor generation with Groq, heuristics using embeddings.
- **Other**: Load without *FOUC* (*Flash of Unstyled Content*) —making sure the page doesn’t flash ugly before styles kick in. Minimal optimization, and as always, lots of console logs.

I also relied on the [**Wiktextract**](https://github.com/tatuylonen/wiktextract) project by **Tatu Ylönen**, and the dataset from [**Kaikki.org**](https://kaikki.org), which offers Wiktionary content in a structured, usable way. Without it, building a solid lexical base would have taken much longer.

## 💡 What I Learned  

- **Wikidata is a treasure**, but navigating it without a map is a nightmare: items, properties, lexemes, glosses, cross-references... and **SPARQL** queries that look like arcane rituals.  
- Tools I discovered:
  - [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)
- Wikidata dumps often come in **JSONL** (JSON Lines) format: a file where each line is a standalone JSON object. Great for streaming —you don’t need to load everything into memory. But with 90 GB... even the best strategy requires patience.
- **Compression formats matter**:  
  - `bz2` is common in official dumps, but *painfully* slow to decompress.  
  - `zstd` is **much faster**, especially with multiple threads. With `pzstd -d -p10` you can speed up decompression, although your own code becomes the bottleneck 😅
- Generating plausible distractors is not trivial. Doing it with Groq was fun but inconsistent.  
- Making fake but believable definitions is tricky. You need precise prompting with Groq or HuggingFace.  
- **Dumps are not for the faint of heart.** Especially when they’re 90 GB.
- I also learned to wrap small NLP services in Docker, exposing local APIs with ease. Using a lightweight image like `python:3.11-slim` and a `requirements.txt`, I quickly deployed a service for semantic comparisons and phrase similarity. Perfect for local tests without dependency chaos.
- I explored [**Common Crawl**](https://commoncrawl.org/) to URLs from the public web. Although I didn’t end up using it, I built a script to filter the links and create a custom corpus. The idea was to use it to generate or validate questions with real content. It’s on hold... for now.

## 📉 Monetization? Yikes...

I had hoped to at least cover the hosting with ads. But the numbers speak for themselves:

- 462 visits  
- 22 active users  
- €0.00 revenue  
- An average of 7 minutes per user... but no clicks

> In 2025, if you don’t have TikTok, a newsletter, or a million page views, ads won’t even buy you coffee.  
> Making a website isn’t enough. You have to be a showman, have money, or do daily marketing.

## 🎯 So, what now?

I’m not killing it.  
**WordGuardian will live on** as an experimental project and a small tribute to words and to Wikidata.  

Maybe it will evolve into an educational app. Maybe it’ll become the base for a new game.  
Or maybe it’ll stand as a monument to the time spent on an idea that still makes me smile.

I’m also toying with the idea of **exploring how to use Wikidata’s ontology to generate questions by topic** —science, history, pop culture, etc.  
Using subclass (`p279`) and instance (`p31`) hierarchies to build *thematic levels* or *topic-based quizzes*, making the game a bit less “psychedelic” and a bit more navigable.  

👉 Try it: [https://eurekatop.com/wordguardian](https://eurekatop.com/wordguardian/en/game)  
📖 Open source (coming soon on GitHub)  

A project by [**mutiitu.com**](https://www.mutiitu.com)

© Francesc López Marió, 2025


Over the past month, I’ve immersed myself in a personal project that was meant to be a game, an experiment, and maybe a bit of a protest: **WordGuardian**. A website for playing with absurd, real, and invented definitions. But also a window into Wikidata’s semantic richness and a cold shower on the reality of building an indie web in 2025.

The WordGuardian Project


When we think of "artificial intelligence" and "content generation," we often focus on text, images, or conversational responses. But the roots of this phenomenon are deeper and older than they might seem. And, interestingly, an important part of this story begins with music.

## 🎶 The origin: music written by machines

Algorithmic music is not a 21st-century invention. Back in the 20th century, composers like Lejaren Hiller and Iannis Xenakis explored musical creation through mathematical rules and algorithms. This approach wasn't just about generating random melodies, but about exploring new expressive paths where calculation replaced intuition.

Unlike improvised music, algorithmic music aimed to detach from the creative self and give way to pure abstraction: what would a symphony created by a rule sound like? The challenge was (and still is) to find meaning in something generated by a process that, in theory, has no emotions or intentions.

## 🐒 The infinite monkey metaphor

The [infinite monkey theorem](https://en.wikipedia.org/wiki/Infinite_monkey_theorem) states that if a monkey randomly presses the keys of a typewriter for an infinite amount of time, it will eventually produce any conceivable text—including the complete works of Shakespeare.

This idea, as absurd as it is unsettling, is key to understanding the heart of many current algorithmic generation technologies: it's not about understanding, it's about statistics. When a system generates a sentence, it doesn’t “know” what it's saying. It simply calculates which word is most likely to come next.

## 🤖 From randomness to language

Language models like ChatGPT don’t work exactly like a monkey hitting keys, but the underlying logic is similar: to produce coherent text based on statistical patterns extracted from a massive training corpus. The result may seem magical, but it’s pure computation.

Now, if systems generate more and more content online... what happens to quality? If the internet fills with AI-written texts trained on other AI-generated texts, could we [end up in a loop where originality vanishes and repetition reigns](https://aeon.co/essays/who-needs-ai-text-generation-when-theres-erasmus-of-rotterdam?utm_source=rss-feed)?

## 🧠 Between automatism and the unconscious

The idea of writing without consciousness is not new. In the 20th century, the Surrealists practiced **automatic writing** as a way to access the creative unconscious without rational filters. André Breton, Artaud, and Dalí wrote by letting thoughts flow, without censorship or predefined structure.

It’s not so different from how some generative systems work: they repeat patterns, produce unexpected outputs, and sometimes create works with a strange kind of charm.

## 📚 And what does Horace Walpole have to do with all this?

In the late 18th century, English writer Horace Walpole published [*Hieroglyphic Tales*](https://isbndb.com/search/books/Cuentos%2BJerogl%C3%ADficos), a collection of satirical stories full of absurdities, wordplay, and semi-narrative nonsense. Some critics have seen in this work a kind of "proto-text generator": a literary attempt to explore the chaos of language and meaning when rules aren’t clear.

This approach—playful yet critical—makes us think: to what extent can algorithms be creative? And we, as readers, how do we identify what has value amid so much statistical repetition?

## ❓What now?

We are facing a silent revolution. Millions of texts, songs, and images are being generated by systems that don’t think but mimic thought. This forces us to rethink creativity, ownership, and even the meaning of culture itself.

- Can we consider a melody generated by an algorithm as art?
- Does it make sense to write a poem if you can generate a thousand?
- How do we distinguish noise from the human voice?

And perhaps the most unsettling question: **if reading no longer means listening to a person, but to a system... who are we really listening to?**

---

> ✍️ This article may have been generated by an algorithm. It’s unclear whether what it says is true, but it definitely sounds coherent.


From algorithmic music to ChatGPT: how AI generates content, what the infinite monkey has to do with it, and what questions it raises about creativity.

From Algorithmic Music to ChatGPT


## How to Avoid Secret Leaks When Publishing a Project to Production

On May 2, 2025, at 02:41:37 AM, an IP address from Amsterdam (213.232.87.232) began systematically scanning your server. It wasn’t looking for web pages. It didn’t want to see content. It was looking for secrets. Were you ready?

This type of attack is more common than you think. And no, it’s not Hollywood-style “hacking.” It’s just a machine making requests. But the requests are smart. And dangerous.

### 🔍 What was it looking for?

The list is chilling:

-   `/.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`
-   and many more...

All of them are files that have been mistakenly exposed to production in hundreds of projects around the world. And all of them may contain private keys, API secrets, credentials, sensitive configs, backups... everything.

### 📉 A single leak = disaster

When you publish a project—especially if you’re using frameworks like Laravel, Node.js, Django, etc.—it’s easy to forget about files like `.env`, `config.yml`, or entire directories like `.git/`. On StackOverflow and Hacker News, there are plenty of stories from developers who made this mistake, like the famous case where someone accidentally committed AWS keys to a public repository and within less than an hour, received bills for thousands of dollars due to malicious use of services like EC2 and S3.

### 🔐 Best Practices to Protect Secrets

According to secret detection platforms like [ScatteredSecrets](https://scatteredsecrets.com) and reports on malicious traffic, these are some practices that should be mandatory:

-   **Never publish your `.env` or sensitive config files.** Use `.gitignore`.
-   **Properly configure your server.** Any file starting with a dot (`.`) should be denied by the HTTP server.
-   **Avoid exposing directories like `.git`, `.svn`, `node_modules`, `vendor`, or `storage`.**
-   **Audit your repository.** Tools like [`git-secrets`](https://github.com/awslabs/git-secrets) or [`truffleHog`] can help detect secrets before pushing code.
-   **Deploy only the production artifact.** Never the entire source. Use pipelines to clean and package.
-   **Monitor your logs.** Requests like the ones shown above are a clear alert that someone is scanning you.

### 🛡️ Your Server Withstood It… This Time

Take a close look: many of the attack requests returned a `403 Forbidden` or a `404 Not Found`. Fortunately. But all it takes is one poorly configured leak to open the door.

The future of your systems depends on what you do today. Don’t wait to see a `GET /.env` with a `200 OK` in your logs to take action.


Avoid secret leaks in production. We analyze a real attack attempt and explain how to protect your server with security best practices.

Watch Your Secrets: The Attack That Hit Your Server


**Have you lost your favorite adventures? No, they were just hidden in an emulator.**

We live in a world without shelves. No more dusty cardboard boxes or hand-labeled 3½” floppy disks. In an age of cloud, streaming, and subscriptions, we risk losing our collective digital memory: the games that shaped us, that defined our love for adventure, strategy, or action. Emulating old video games isn’t just nostalgia — it’s digital archaeology, autobiographical memory rendered in pixels.

Portals like [CPC-Power](https://www.cpc-power.com/index.php?page=detail&num=298) are temples of [retrocomputing](https://en.wikipedia.org/wiki/Retrocomputing). They preserve games that, without the community, would have vanished like so many decaying floppies. Retrocomputing isn’t a geeky fad — it’s a form of cultural resistance against planned obsolescence and amnesiac progress. It’s a tribute to a time when each game bore its creator’s imprint and every tape load was a ritual.

Today, we don’t keep the covers on the shelf. But we can preserve their essence. Just like the [Wayback Machine](https://en.wikipedia.org/wiki/Wayback_Machine) captures lost websites, emulators let us relive experiences that would otherwise be lost forever. And this has a deeply human dimension. As memory psychology suggests, our emotional memories are central to understanding who we are. When we emulate *La Abadía del Crimen* or *Rick Dangerous*, we’re not just playing — we’re reconnecting with a younger version of ourselves.

It’s not just about “remembering when,” it’s about **feeling it**. Emulating old video games keeps part of us alive — a digital Library of Alexandria that, if we don’t preserve, might disappear forever.


Emulating old video games is not just about nostalgia: it's about preserving our collective digital memory and reliving a part of ourselves.

Digital Memory: When Emulating Video Games is Reliving the Past


When the contestant picks a door, the host opens another... and the universe of probability starts to shake. We're talking about the **Monty Hall problem**, a mathematical puzzle that defies intuition and reveals how little we truly understand statistics.

## What is the problem?

Based on the American game show *Let's Make a Deal*, the setup goes like this:

- There are three doors.
- Behind one is a car. The other two hide goats.
- You pick a door (say, door 1).
- The host, who **knows** where the prize is, opens another door (say, door 3) and shows a goat.
- Then he asks you: *"Do you want to switch to door 2?"*

Intuition says it’s 50-50. But it’s not.

## The correct answer almost no one accepts

The probability that the car is behind your initial choice is **1/3**. The probability that it’s behind one of the other two is **2/3**. When Monty opens a door with a goat, the full 2/3 probability transfers to **the other unopened door**. Switching **doubles** your chances of winning.

This result is so counterintuitive that even **professional mathematicians** have wrongly argued there's no difference. Marilyn vos Savant, considered one of the smartest people in the world, explained it correctly in *Parade Magazine*... and received thousands of letters saying she was wrong.

## Why is it so hard to grasp?

The human brain **doesn’t understand conditional probability** naturally. We think of percentages as fixed, forgetting how new evidence changes the rules of the game. It’s the same reason we get confused by medical tests, forecasts, and risk decisions.

## A real-life experiment

In one study, when students were given the problem, only **10% chose to switch**. After the logic was explained, that percentage multiplied. But it takes **seeing it repeated** to truly believe it.

## What the problem reveals

Monty Hall isn’t just a game. It’s a mirror. It reflects how we **prefer intuition over logic**, and how math education often fails to teach the *why*, not just the *how*


The Monty Hall problem challenges our intuition about probability. Switching doors doubles your chances of winning!

Don't Open Door Number 1! The Statistical Mystery That Baffles the World


In a hyperconnected world where technology sets the rhythm of our daily lives, it seems impossible to imagine that it all started with a website as simple as it was revolutionary. But the first website —a basic CERN page created by Tim Berners-Lee— not only transformed how we share knowledge, it also reminds us of the power of teamwork. Just like in football, no lone genius can go far without a team creating the space for them to shine.

In modern football, this principle becomes evident with names like Lamine Yamal, the teenage star of Barça. His talent is undeniable, but what allows it to flourish is the network of teammates opening up space, a coach who trusts him, and a tactical system that propels him toward greatness. Just as the first website’s interconnected documents enabled navigation, in football, it’s the connection between players that turns a move into a goal.

This parallel is reinforced by team-building activities like the spaghetti challenge: teams have 18 minutes to build a structure using limited materials. The groups that collaborate, listen, and coordinate far outperform those led by a brilliant but isolated individual. In football, as in the web and in these challenges, the whole is greater than the sum of its parts.

Just as the Library of Alexandria preserved ancient knowledge, the internet now connects us with all the wisdom in the world. But, as in football, it takes a team, trust, and collective play for a single player or idea to truly go far.

---

**References**  
1. [FC Barcelona draws while exploring limits](https://www.elperiodico.com/es/deportes/20250430/barcelona-explora-limites-cordura-empata-116923837)  
2. [The spaghetti challenge](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [History of football – Wikipedia](https://es.wikipedia.org/wiki/Historia_del_f%C3%BAtbol)  
4. [Lamine Yamal – Wikipedia](https://ca.wikipedia.org/wiki/Lamine_Yamal_Nasraoui_Ebana)


The first website and modern football share a key lesson: connection and teamwork are the foundation for individual brilliance.

The First Website Ever Made… and How Football Reminds Us of It Every Sunday


On April 26, 2025, Spain went dark. Literally. A massive power outage left millions of homes, businesses, and infrastructures without electricity for hours. It seemed like the prelude to chaos: collapsed systems, halted trains, hospitals running on emergency generators, and a hyperconnected population suddenly disconnected.

But what could have been a social horror film turned into a display of collective maturity. Thanks to a society with a strong civic culture and an education system that fosters respect and collaboration, there were no riots or panic. Shops remained calm, neighbors shared candles and information, and authorities were able to work without obstacles to restore service.

Citizens’ behavior resembled the classic spaghetti tower challenge: when teams cooperate and listen, the result is solid and stable. And that’s exactly what happened. Technical staff operated like a well-coordinated orchestra, with rapid response protocols and efficient communication.

According to Red Eléctrica Española, the demand management system and collaboration with the autonomous communities allowed the service to be restored in record time. Moreover, the knowledge gained from energy efficiency and green computing played a key role in preventing a total technological collapse.

When the power returned, it wasn’t just the electricity that came back on. It became clear that a country’s best infrastructure is its people. And that even in darkness, a cohesive society can be the light that prevents chaos.

---

**References**  
1. [Massive blackout in Spain](https://elpais.com/economia/2025-04-28/apagon-electrico-masivo-en-espana.html)  
2. [Build with spaghetti in 18 minutes](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Electricity demand management – REE](https://www.esios.ree.es/es/gestion-de-la-demanda)  
4. [Green computing – Wikipedia](https://es.wikipedia.org/wiki/Green_computing)


Spain's 2025 blackout proved that a cohesive society can shine even in the most unexpected darkness.

Blog