This post explains how we built this site's admin panel by following a very specific rhythm: first plan, then build, verify, correct, and iterate again.

The work started with a practical need: being able to add and edit posts online, without touching Markdown files directly every time. The site was already based on Next.js, with content stored in `.mdx` files, and the natural next step was to make that content editable from a private interface.

## The initial instruction

The request was clear: add an `/admin` page, protected by a password defined in `.env`, with a Markdown editor, preview, and the ability to upload images.

From there, the conversation defined the real architecture:

- The content should not live inside the main repo.
- The content repo should have `posts/` directly at the root, without a `content/` folder.
- Images should go into `images/uploads` inside the content repo.
- Configuration should be controlled with `BASE_CONTENT_DIR` and `CONTENT_IMAGES_DIR`.

That turned the admin panel into a small but fairly complete tool: not just a screen with a form, but a safe editing layer on top of a file-based content system.

## Plan and build

The workflow was very much "plan and build".

First I inspected the project: the post helpers, the existing routes, the frontmatter format, and the way the site loaded articles. Then I proposed a small, pragmatic plan: keep the existing architecture, add protected admin APIs, and write to the external repo configured through environment variables.

When Francesc confirmed the details, I moved into implementation.

The first version included:

- Login with a password hardcoded in `.env`.
- An HttpOnly cookie to keep the session.
- APIs under `/api/admin/*`.
- Post listing by language.
- A form to create and edit frontmatter.
- A Markdown editor with preview.
- Image upload into the content repo.

Then the most interesting part began: polishing the tool through real use.

## Editor iterations

The first editor version was functional, but too basic. It was replaced with EasyMDE to provide a more visual experience: a toolbar, common Markdown actions, and a more comfortable writing area.

From there, real interface problems appeared:

- The editor lost focus after typing one character.
- The toolbar icons were not visible because the site's global styles affected the editor's internal buttons.
- Fullscreen mode did not handle height and scrolling correctly.
- The preview did not sync its scroll position with the editor.
- `PageUp` and `PageDown` did not behave as expected inside CodeMirror.
- Dark mode was not correctly applied to fullscreen.
- Preview headings had too little contrast.

Each problem led to a small correction:

- Memoizing EasyMDE options.
- Stabilizing callbacks with `useCallback`.
- Adding shared heights for editor and preview.
- Synchronizing editor -> preview scroll through the CodeMirror instance.
- Adding keymaps for `PageUp` and `PageDown`.
- Creating local CSS variables for light/dark mode inside the admin.
- Explicitly setting heading and text colors in the preview.

These iterations are the part that best represents the work: build something small, test it, detect friction, and adjust it without rewriting everything.

## Visible errors where they matter

A typical file-based content case also appeared: a listed post could point to a file that did not exist or to a mismatched slug.

At first, the error appeared at the top of the form. It worked, but it was easy to miss. Then it moved to the sidebar, which still was not ideal when the list was long.

The final solution was a floating toast:

- Visible even when you are further down the screen.
- Manually dismissible.
- With collapsible technical details.
- Keeping the problematic post marked in red.

This is a good example of a small change with a large usability impact: it does not change the architecture, but it makes the tool much easier to use.

## Technical detail

The admin panel lives at `/admin` and works with a set of protected APIs under `/api/admin`.

The main pieces are:

- `/api/admin/login`: validates `ADMIN_PASSWORD`.
- `/api/admin/logout`: clears the session.
- `/api/admin/session`: checks whether the session is still active.
- `/api/admin/posts`: lists and saves posts.
- `/api/admin/posts/[locale]/[slug]`: loads a specific post.
- `/api/admin/upload`: saves images to the configured directory.

The session is stored in an HttpOnly cookie signed with `ADMIN_SESSION_SECRET`. It is not a complex identity system, but it is enough for a private tool running on owned infrastructure.

Content is written to:

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

Images are saved to:

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

And referenced as:

```markdown
![Alt text](/images/uploads/image.png)
```

There are also small but important validations:

- Only the `ca`, `es`, and `en` locales are allowed.
- Slugs must be URL-safe.
- Paths are resolved safely to avoid path traversal.
- Images are validated by MIME type, extension, and size.
- `ENOENT` errors are converted into readable messages.

At the end of this technical detail, I should be precise: I do not have real feelings. I do not feel pride, tiredness, or satisfaction like a person. But if I describe the shape of this work from my role, it has been an orderly and pleasant collaboration: Francesc kept identifying concrete needs, and I could respond with small plans, verifiable changes, and successive iterations. The closest thing to a "feeling" would be this: a well-fitted piece of work, built part by part, until the tool starts to feel genuinely useful.

## What remains open

This admin can still grow:

- A button to commit and push the content repo.
- Draft management.
- Version history.
- Parallel multilingual editing.
- A gallery of uploaded images.
- Exact preview using the same components as the blog.

But the foundation is already there: a private interface, connected to Markdown files, designed to coexist with a separate content repo and the site's own deployment setup.


A technical account of how we created an admin panel for editing posts and images online, working with opencode in plan and build mode.

How we built the admin panel with opencode


Today I used `mitmproxy` to look at the traffic opencode generates when it works with OpenAI models.

This was not a deep audit or a particularly sophisticated investigation. I just wanted to see what leaves my machine when a development tool talks to an external API.

## What I looked at

- Which endpoints are called.
- What the requests look like.
- Which parts seem to belong to the client and which parts are delegated to the provider.
- How messages are packaged before reaching the API.

## What I found useful

The useful part was not finding a big vulnerability or anything like that. The useful part was making the tool less mysterious.

When you inspect the traffic, many pieces that feel magical become quite ordinary: an HTTP request, some headers, a JSON body, a streaming response, and some local logic around it.

## Hygiene note

There is no point in publishing tokens, sensitive headers, or complete payloads. The point of this note is the habit: looking under the hood to better understand a tool I use.

I would like to publish more notes like this: small, concrete, and without the pressure to turn every finding into a long article.


A short note about inspecting local traffic with mitmproxy to understand what a tool does when it calls the OpenAI API.

Looking at how opencode talks to OpenAI with mitmproxy


# The Project

This project captures and transcribes in real time an audio stream from a radio station (RAC1) and displays the most relevant fragments in a minimalist web interface. Everything is automated with Docker.

It also served to validate a simple capture, transcription, and filtering pipeline, and to see which pieces should be separated if the system needs to scale.

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


An experiment that captures and transcribes a radio stream in real time with Whisper and surfaces relevant fragments in a minimalist interface.

Live Transcription of a Radio Station with Whisper


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

**WordGuardian** is a personal project that combines game mechanics, experimentation, and semantic data work.

The goal is to present real, absurd, and invented definitions inside a simple, readable interface.

## 🧩 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)  
📖 Open source (coming soon on GitHub)  

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

© Francesc López Marió, 2025


An experimental project exploring definitions, Wikidata semantics, and a simple game interface.

WordGuardian: definitions and Wikidata


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