

# El projecte

Aquest projecte és un petit experiment per capturar i transcriure en temps real un stream d’àudio d’una emissora de ràdio (RAC1) i mostrar-ne els fragments més rellevants mitjançant una interfície web minimalista. Tot plegat, automatitzat amb Docker.

És també una prova personal de *vibe coding*, feta amb un objectiu clar però sense planificació prèvia, simplement deixant-se portar per la intuïció i fins a qui punt pot accelerar el desenvolupament. Tot i que el projecte funciona, reconec que amb aquest procés s’hi perd part del plaer d’un coneixement estructurat i d’una planificació que faria la solució més robusta i escalable.

Amb aquesta manera de programar, ràpida i improvisada, es tendeixen a obviar certes abstraccions i estructures que sovint són les que obren la porta a la creativitat més profunda: aquella que emergeix quan les eines no només funcionen, sinó que s'entenen perquè funcionen.


## Accedeix a la demo

👉 Prova’l: [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ó de la imatge"
  style={{ alignSelf: 'center', width: '80%', maxWidth: '80%', height: 'auto', borderRadius: '12px' }}
/>


## Backend: Transcripció Automàtica amb Whisper

La base del projecte és un script en Python que escolta el stream com si fos un navegador. En un primer intent he provat d'utilitzar `ffmpeg` per capturar el stream, però ha fallat perquè l'emissora té proteccions antibot i la connexió no va ser acceptada. 

Com alternativa he trobat que utilitzant `httpx.stream()` es pot llegir el flux d'àudio sense problemes. Sempre que la petició sembli que és la d'un navegador real. Per això cal afegir alguns headers...

El script s'ha separat en dos parts: una per la captura del stream i una altra per la transcripció i filtratge de paraules clau. Aquesta transcripció es fa en paral·lel amb la captura del stream, perquè no cal esperar a que acabi la transcripció per poder seguir capturant.

L’àudio llavors es processa per blocs de 4 segons i es transcriu usant el model *Whisper* optimitzat (`int8`).

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

Un cop transcrit, es busca si apareixen paraules clau com “barça”, “avui” o “lamine yamal”, i si és el cas, es genera una alerta i s'escriu tot a un fitxer `.log`. Per exemple:

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

El sistema afegeix una petita cua de l’àudio anterior per evitar talls entre frases perquè el model necessita context per entendre bé les primeres paraules del stream. 

Tot plegat, automatitzat amb Docker.

## Frontend: Visualització en Directe

Un petit servidor en Node.js mostra les línies transcrites en directe des d’un fitxer `.log`, enviant-les via Server-Sent Events a la interfície web tipus “consola de 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`))
})
```
Al client, la connexió es manté oberta amb EventSource() del navegador, que rep automàticament les actualitzacions en temps real:

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

---

## 💡 Aprenentatges

- Whisper és força fiable, fins i tot en català.
- Afegir una cua d’àudio anterior millora la precisió en frases tallades.
- Amb `httpx.stream` i fils lleugers es pot capturar àudio de manera estable sense saturar el procés principal. En un primer intent s’havia provat d’utilitzar `ffmpeg`, però s’ha descartat perquè la idea era evitar les proteccions antibot de l’emissora simulant una connexió de navegador real.
- Server-Sent Events és una eina molt simple però efectiva per enviar dades en viu a una web.

## Stack i tècniques

- 🐍 Python + [faster-whisper](https://github.com/guillaumekln/faster-whisper)
- 📡 httpx per capturar streams d’àudio
- 🎛️ Transcripció en català amb el model Whisper-small optimitzat
- 🐳 Docker per encapsular el servei
- 🟩 Node.js + Express per exposar el fitxer com a feed SSE
- 🎨 HTML + CSS en mode consola de terminal

---

Un experiment en vibe coding per Francesc López Marió, 2025



Petit experiment que captura i transcriu en temps real un stream de ràdio amb Whisper, i en mostra les paraules clau en una web estil retro.

Transcripció en directe d'una emissora de ràdio amb Whisper en mode Vibe Coding


# El projecte   
**Versió 1.0**  
✍️ Assistit amb AI: Aquest article ha estat redactat amb l’ajuda de ChatGPT (OpenAI), a partir d’esbossos i idees originals.

Durant el darrer mes m’he submergit en un projecte personal que volia ser joc, experiment, i potser una mica protesta: **WordGuardian**.

Una web per jugar amb definicions absurdes, reals i inventades. Però també una finestra a la riquesa semàntica de Wikidata i un bany d’aigua freda sobre la realitat de crear una web indie el 2025.

## 🧩 Objectiu  
Volia fer un joc on els usuaris endevinessin definicions plausibles, generades o extretes de forma automàtica.  

**Però el camí no ha estat gens simple.**  
He usat Astro i Preact per evitar el FUOC i fer-ho responsive, i he treballat amb dumps gegants de Wikidata descomprimint amb `pbzip2`, `zstd` i scripts en **Rust** paral·lels.

## ⚙️ Stack i tècniques  

- **Frontend**: Astro, Preact, Shoelace, Vanilla Extract  
  > *Astro ha estat una joia inesperada.* Permet combinar components amb diferents frameworks i, sobretot, fer **renderitzat del costat del servidor (SSR)** molt eficient. Això facilita que els cercadors indexin el contingut sense problemes —una diferència clau si vols tenir opcions reals a SEO el 2025. A més, exposar una petita API del servidor (amb endpoints tipus `/api/xyz`) és directe i sense complicacions, sense haver de muntar un backend sencer.  
- **Backend**: Node.js per scrapings, scripts paral·lels en Rust per parsejar Wikidata  
- **Processament**: dumps de Wikidata amb p31, p279, p1629... tot un món  
- **NLP**: generació de distractors amb Groq, heurístiques amb embeddings.
- **Altres**: Càrrega sense *FOUC* (*Flash of Unstyled Content*), és a dir, evitar que la pàgina es vegi "lletja" durant unes mil·lèsimes de segon abans que es carreguin els estils. També he fet una optimització mínima i, com sempre, moltes línies de consola.

També he utilitzat el projecte [**Wiktextract**](https://github.com/tatuylonen/wiktextract), desenvolupat per **Tatu Ylönen**, i la base de dades publicada a [**Kaikki.org**](https://kaikki.org), que ofereix els continguts de Wiktionary de forma estructurada i usable. Sense aquesta font, hauria estat molt més lent construir una base lèxica fiable per al joc.

## 💡 Aprenentatges  

- **Wikidata és un tresor**, però navegar-hi sense mapa és una odissea: items, propietats, lexemes, glosses, referències creuades... i consultes **SPARQL** que semblen rituals màgics.  
- He descobert eines com:
  - [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)
- Els dumps de Wikidata venen sovint en **format JSONL** (JSON Lines): un fitxer on cada línia és un objecte JSON independent. És perfecte per processament en streaming, perquè no cal carregar-ho tot a memòria. Però quan tens 90 GB... qualsevol estratègia requereix paciència, molta.
- **Diferència de compressió**:  
  - `bz2` és molt comú en els dumps oficials, però *lentíssim* de descomprimir.  
  - `zstd`, en canvi, és **molt més ràpid**, especialment amb múltiples fils. Amb `pzstd -d -p10` pots accelerar bastant la càrrega, encara que després el coll d’ampolla és el teu codi 😅
- Generar distractors plausibles no és trivial. Fer-ho amb Groq ha estat divertit, però no sempre fiable.  
- Generar definicions falses però creïbles no és trivial. Amb Groq o HuggingFace, millorant amb prompts, però cal filar prim.  
- **Els dumps no són per dèbils.** I menys si pesen 90 GB.
- També he après a encapsular petits serveis NLP amb Docker, exposant APIs locals de forma senzilla. Amb una imatge lleugera basada en `python:3.11-slim` i un `requirements.txt`, vaig poder desplegar ràpidament un servei per fer càlculs semàntics o similituds entre frases. Ideal per fer proves locals sense embolics de dependències.
- També vaig estar explorant el projecte [**Common Crawl**](https://commoncrawl.org/) per extreure URLs de la web pública. Tot i que finalment no ho vaig integrar, vaig preparar un script per filtrar els enllaços  i construir un corpus propi. La idea era utilitzar-lo per generar preguntes o validar definicions amb contingut real, però va quedar en stand-by... per ara.


## 📉 Monetització? Ai...

Tenia la il·lusió de cobrir ni que fos el hosting amb anuncis. Però les dades són clares:

- 462 visites
- 22 usuaris actius
- 0,00 € d’ingressos
- Una mitjana de 7 minuts per usuari... però ningú clica

> Al 2025, si no tens TikTok, una newsletter o 1 milió de pàgines vistes, la publicitat no paga ni el cafè.  
> Fer una web no n’és prou. Has de ser showman, tenir diners, o fer màrqueting diari.

## 🎯 I ara què?

No el mataré.  
**WordGuardian seguirà viu** com a projecte experimental i com a petit homenatge a les paraules i a Wikidata.  

Potser evolucionarà cap a una app educativa. Potser serà la base d’un joc nou.  
O potser quedarà com a monument al temps invertit en una idea que encara em fa somriure.

També em ronda pel cap començar a **investigar com fer servir l’ontologia de Wikidata per generar preguntes alineades amb camps de coneixement**: ciència, història, cultura popular, etc.  
Aprofitar la jerarquia de subclasses (`p279`) i instàncies (`p31`) per construir *nivells temàtics* o *quizzes per àmbits*, i fer que el joc sigui una mica menys "psicodèlic" i una mica més navegable.  



👉 Prova’l: [https://eurekatop.com/wordguardian](https://eurekatop.com/wordguardian/ca/game)  
📖 Codi obert (aviat a GitHub)  

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

© Francesc López Marió, 2025


Durant el darrer mes m’he submergit en un projecte personal que volia ser joc, experiment, i potser una mica protesta: **WordGuardian**. Una web per jugar amb definicions absurdes, reals i inventades. Però també una finestra a la riquesa semàntica de Wikidata i un bany d’aigua freda sobre la realitat de crear una web indie el 2025.

El projecte WordGuardian


Quan pensem en "intel·ligència artificial" i "generació de contingut", sovint ens centrem en textos, imatges o respostes conversacionals. Però les arrels d’aquest fenomen són més profundes i antigues del que pot semblar. I, curiosament, una part important d’aquesta història comença amb la música.

## 🎶 L’origen: música escrita per màquines

La música algorítmica no és un invent del segle XXI. Ja al segle XX, compositors com Lejaren Hiller o Iannis Xenakis exploraven la creació musical mitjançant regles matemàtiques i algoritmes. Aquest enfocament no buscava només generar melodies aleatòries, sinó explorar nous camins expressius on el càlcul substituïa la intuïció.

A diferència de la música improvisada, la música algorítmica pretenia deslligar-se del jo creatiu per donar pas a l’abstracció pura: com sonaria una simfonia creada per una regla? El repte era (i és) trobar sentit en allò generat per un procés que, en teoria, no té emocions ni intencions.

## 🐒 La metàfora del mico infinit

El [teorema del mico infinit](https://es.wikipedia.org/wiki/Teorema_del_mono_infinito]) afirma que si un mico prem aleatòriament les tecles d'una màquina d'escriure durant un temps infinit, eventualment escriurà qualsevol text imaginable —inclosa l'obra completa de Shakespeare

Aquesta idea, tan absurda com inquietant, és fonamental per entendre el cor de moltes tecnologies de generació algorítmica actuals: no es tracta de comprensió, sinó d’estadística. Quan un sistema genera una frase, no “sap” què diu. Simplement calcula quina paraula és més probable que vingui després.

## 🤖 De l’atzar al llenguatge

Els models de llenguatge com ChatGPT no funcionen exactament com un mico que prem tecles, però la lògica subjacent és similar: produir text coherent a partir de patrons estadístics extrets d’un enorme corpus d’entrenament. El resultat pot semblar màgic, però és pur càlcul.

Ara bé, si els sistemes generen cada cop més contingut a la xarxa… què passa amb la qualitat? Si internet s’omple de textos escrits per IA, entrenats sobre altres textos generats per IA, es pot [arribar a un bucle on l’originalitat desaparegui i la repetició regni](https://aeon.co/essays/who-needs-ai-text-generation-when-theres-erasmus-of-rotterdam?utm_source=rss-feed)?

## 🧠 Entre l’automatisme i l’inconscient

La idea d’escriure sense consciència no és nova. Al segle XX, els surrealistes practicaven l’**escriptura automàtica** com una manera d’accedir a l’inconscient creatiu sense filtres racionals. André Breton, Artaud o Dalí escrivien deixant fluir el pensament, sense censura ni estructura preestablerta.

No és tan diferent de com treballen alguns sistemes generatius: repeteixen patrons, produeixen sortides inesperades i, de vegades, creen obres d’un encant estrany.

## 📚 I què té a veure Horace Walpole amb tot això?

A finals del segle XVIII, l’escriptor anglès Horace Walpole va publicar [*Cuentos Jeroglíficos*](https://isbndb.com/search/books/Cuentos%2BJerogl%C3%ADficos), un recull de relats satírics plens d’absurds, jocs de paraules i absurditats semi-narratives. Alguns crítics han vist en aquesta obra una mena de "proto-generador de text": un intent literari d’explorar el caos del llenguatge i el significat quan les regles no són clares.

Aquesta aproximació, lúdica però també crítica, ens fa pensar: fins a quin punt els algoritmes poden ser creatius? I nosaltres, com lectors, com identifiquem allò que té valor enmig de tanta repetició estadística?

## ❓I ara què?

Estem davant d’una revolució silenciosa. Milions de textos, cançons i imatges són generades per sistemes que no pensen, però que imiten el pensament. Això ens obliga a replantejar la creativitat, la propietat i, fins i tot, el sentit de la cultura.

- Podem considerar art una melodia generada per un algorisme?
- Té sentit escriure un poema si ja en pots generar mil?
- Com distingim el soroll de la veu humana?

I potser el més inquietant de tot: **si llegir ja no implica escoltar una persona, sinó un sistema... a qui estem escoltant realment?**

---

> ✍️ Aquest article pot haver estat generat per un algoritme. No se sap si el que diu és cert, però sens dubte, sona coherent.


De la música algorítmica a ChatGPT: com la IA genera contingut, què hi té a veure el mico infinit i quines preguntes obre sobre la creativitat.

De la música algorítmica al ChatGPT


## Com evitar la filtració de secrets quan publiques un projecte en producció

El dia 2 de maig del 2025, a les 02:41:37 del matí, una IP d’Amsterdam (213.232.87.232) va començar un escaneig sistemàtic del teu servidor. No buscava pàgines web. No volia veure contingut. Buscava secrets. I tu, estaves preparat?

Aquest tipus d'atac és més comú del que et penses. I no, no és “hacking” de pel·lícula. És només una màquina fent peticions. Però les peticions són intel·ligents. I perilloses.

### 🔍 Què buscava?

La llista és esgarrifosa:

-   `/.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`
    
-   i molts més...
    

Tots ells són fitxers que han estat exposats per error a producció en centenars de projectes al món. I tots poden contenir claus privades, secrets d'API, credencials, configuracions sensibles, còpies de seguretat... tot.

### 📉 Una sola fuita = desastre

Quan publiques un projecte, especialment si uses frameworks com Laravel, Node.js, Django, etc., és fàcil oblidar-te fitxers com `.env`, `config.yml` o directoris sencers com `.git/`. A StackOverflow i a Hacker News, hi ha múltiples històries de desenvolupadors que han patit aquest error, com el cas famós on algú va commitejar per error les claus AWS en un repositori públic i, en menys d’una hora, va tenir factures de milers de dòlars per ús maliciós de serveis ….

### 🔐 Bones pràctiques per protegir secrets

Segons plataformes de detecció de secrets com [ScatteredSecrets](https://scatteredsecrets.com) … i informes sobre tràfic maliciós …, aquestes són algunes mesures que haurien de ser obligatòries:

-   **Mai publiquis el teu `.env` o fitxers de configuració sensibles.** Usa `.gitignore`.
    
-   **Configura correctament el teu servidor.** Tot arxiu que comenci amb punt (`.`) hauria d'estar denegat per l’HTTP server.
    
-   **Evita exposar directoris com `.git`, `.svn`, `node_modules`, `vendor` o `storage`.**
    
-   **Audita el teu repositori.** Hi ha eines com [`git-secrets`](https://github.com/awslabs/git-secrets) o [`truffleHog`] per buscar secrets abans de fer `push`.
    
-   **Desplega només l’artefacte de producció.** Mai la font sencera. Usa pipelines per netejar i empaquetar.
    
-   **Monitoritza els logs.** Les peticions rebudes com les que t’hem mostrat són una alerta clara que algú t’està escanejant.
    

### 🛡️ El teu servidor ha resistit… aquesta vegada

Fixat bé: de les peticions de l’atac, moltes han tornat un `403 Forbidden` o un `404 Not Found`. Afortunadament. Però només cal una fuita mal configurada per obrir la porta.

El futur dels teus sistemes depèn del que facis avui. No esperis a veure un `GET /.env` amb un `200 OK` al teu log per actuar.

Evita filtracions de secrets en producció. Analitzem un intent real d’atac i t’expliquem com protegir el teu servidor amb bones pràctiques de seguretat.

Vigila amb els secrets: l’atac que va tocar el teu servidor


**Has perdut les teves aventures preferides? No, només estaven amagades en un emulador.**

Vivim en un món sense estanteries. Ja no hi ha capses de cartró polsoses, ni etiquetes marcades amb retolador sobre disquets de 3½. En una època on tot és núvol, *streaming* i subscripció, correm el risc de perdre la nostra memòria digital col·lectiva: aquells jocs que ens van marcar, que van modelar el nostre gust per l’aventura, l’estratègia o l’acció. Emular videojocs antics no és només una nostàlgia: és arqueologia digital, és memòria autobiogràfica en píxels.

Els portals com [CPC-Power](https://www.cpc-power.com/index.php?page=detail&num=298) són temples de la [retroinformàtica](https://es.wikipedia.org/wiki/Retroinform%C3%A1tica). Preserven jocs que, sense la comunitat, s'haurien evaporat com tants disquets deteriorats. La retroinformàtica no és una moda friki: és una forma de resistència cultural davant l’obsolescència programada i el progrés amnèsic. És el record d'una època on cada joc portava el segell del seu creador i cada carregada de cinta era un ritual.

Avui no guardem les caràtules a la prestatgeria. Però podem guardar-ne l’essència. Igual que la [Wayback Machine](https://ca.wikipedia.org/wiki/Wayback_Machine) captura webs desaparegudes, els emuladors permeten reviure experiències que d’altra manera es perdrien per sempre. I això té una dimensió profundament humana. Tal com descriu la psicologia de la memòria, els nostres records emocionals són fonamentals per entendre qui som. Quan emulem *La Abadía del Crimen* o *Rick Dangerous*, no només juguem: ens reencontram amb una versió més jove de nosaltres mateixos.

No és només “recordar quan”, és **sentir-ho**. Emular videojocs antics és mantenir viva una part de nosaltres, una biblioteca d’Alexandria digital que, si no preservem, pot desaparèixer.


Emular videojocs antics no és només nostàlgia: és preservar la memòria digital col·lectiva i reviure una part de nosaltres mateixos.

La memòria digital: quan emular videojocs és reviure el passat


Quan el concursant escull una porta, un presentador en treu una altra... i l’univers de la probabilitat tremola. Parlem del **problema de Monty Hall**, un trencaclosques matemàtic que desafia la intuïció i revela com poc entenem realment l'estadística.

## Què és el problema?

Basat en el programa americà *Let's Make a Deal*, l'experiment funciona així:

- Hi ha tres portes.
- Darrere d'una hi ha un cotxe. Les altres dues amaguen cabres.
- Tu esculls una porta (per exemple, la 1).
- El presentador, que **sap** on és el premi, obre una altra porta (diguem la 3) i mostra una cabra.
- Llavors et pregunta: *"Vols canviar a la porta 2?"*

La intuïció ens diu que és 50-50. Però no ho és.

## La resposta correcta que (quasi) ningú accepta

La probabilitat que el cotxe estigui darrere la porta escollida inicialment és d’**1/3**. I que estigui a una de les dues restants és de **2/3**. Quan Monty obre una porta amb una cabra, tota la probabilitat de 2/3 es transfereix a **l'altra porta no escollida**. Canviar **duplica** les teves possibilitats de guanyar.

Aquest resultat és tan contraintuitiu que fins i tot **matemàtics professionals** han argumentat erròniament que no hi ha diferència. Marilyn vos Savant, considerada una de les persones més intel·ligents del món, ho va explicar correctament a *Parade Magazine*... i va rebre milers de cartes dient-li que s’equivocava.

## Per què ens costa tant?

El cervell humà **no entén la probabilitat condicional** de forma natural. Pensem en percentatges com si fossin fixes, oblidant com l’evidència nova altera les regles del joc. És el mateix motiu pel qual ens equivoquem amb testos mèdics, prediccions i decisions de risc.

## Un experiment real

En un estudi, quan es va fer l’experiment amb alumnes, només un **10% va escollir canviar** la seva opció. Després d'explicar-los el funcionament, aquest percentatge es va multiplicar. Però cal **veure-ho repetit** per començar a creure-ho.

## El que el problema revela

Monty Hall no només és un joc. És un mirall. Reflecteix com **preferim la intuïció a la lògica**, i com l’educació matemàtica sovint falla en ensenyar el *per què* de les coses, no només el *com*.

---

**Referències**:

- [Blog mutiitu sobre Monty Hall](https://blog.mutiitu.com/articles/5)
- [Viquipèdia: 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 posa a prova la nostra intuïció sobre probabilitat. Canviar de porta duplica les opcions de guanyar!

No obris la porta número 1! El misteri estadístic que desconcerta al món


En un món hiperconnectat, on la tecnologia marca el compàs de la nostra vida quotidiana, sembla impossible pensar que tot va començar amb una web tan senzilla com revolucionària. Però la primera web —una simple pàgina del CERN creada per Tim Berners-Lee— no només va transformar la manera com compartim el coneixement, sinó que també ens recorda la força del treball en equip. I és que, igual que el futbol, cap geni solitari pot arribar lluny sense un equip que creï l'espai perquè brilli.

Al futbol modern, aquest principi es fa evident amb noms com Lamine Yamal, l'estrella adolescent del Barça. El seu talent és indiscutible, però el que permet veure’l desplegar-se és la xarxa de companys que li alliberen terreny, l'entrenador que confia en ell i un sistema tàctic que l’empeny cap a la glòria. Així com a la primera web la connexió entre documents va fer possible la navegació, en un partit de futbol és la connexió entre jugadors la que transforma un moviment en gol.

Aquest paral·lelisme es veu reforçat en les activitats de teambuilding com el repte dels espaguetis: equips que en 18 minuts han de construir una estructura amb recursos limitats. Els grups que cooperen, escolten i es coordinen acaben superant amb escreix aquells que tenen un líder brillant però aïllat. En el futbol, com a la web i com en aquests reptes, la suma supera la brillantor individual.

Així com la Biblioteca d'Alexandria guardava el saber antic, internet ens connecta avui amb tota la saviesa del món. Però com al futbol, cal equip, confiança i joc col·lectiu per fer que un sol jugador o una sola idea arribin realment lluny.

---

**Referències**  
1. [FC Barcelona empata explorant límits](https://www.elperiodico.com/es/deportes/20250430/barcelona-explora-limites-cordura-empata-116923837)  
2. [Repte dels espaguetis](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Història del futbol - Viquipèdia](https://es.wikipedia.org/wiki/Historia_del_f%C3%BAtbol)  
4. [Lamine Yamal - Viquipèdia](https://ca.wikipedia.org/wiki/Lamine_Yamal_Nasraoui_Ebana)


La primera web i el futbol modern comparteixen una lliçó clau: la connexió i el treball en equip són la clau per brillar individualment.

La primera web mai feta… i com el futbol ens ho recorda cada diumenge


El 26 d’abril del 2025, Espanya es va apagar. Literalment. Una apagada elèctrica massiva va deixar milions de llars, negocis i infraestructures a les fosques durant hores. Semblava el preludi del caos: sistemes col·lapsats, trens aturats, hospitals amb generadors d’emergència i una població connectada que de sobte quedava incomunicada.

Però el que podia haver estat una pel·lícula de terror social, es va transformar en una demostració de maduresa col·lectiva. Gràcies a una societat amb cultura cívica i una educació que fomenta el respecte i la col·laboració, no hi va haver disturbis ni pànic. Les botigues van mantenir la calma, els veïns van compartir espelmes i informació, i les autoritats van poder treballar sense entrebancs per recuperar el servei.

El comportament de la ciutadania va recordar al clàssic exercici de construcció d’estructures amb espaguetis: quan els grups cooperen i escolten, el resultat és sòlid i estable. I així va ser. El personal tècnic va actuar com una orquestra ben coordinada, amb protocols de resposta ràpida i comunicació eficient.

Segons Red Eléctrica Española, el sistema de gestió de la demanda i el treball conjunt amb les comunitats autònomes van permetre reestablir el servei en temps rècord. A més, el coneixement adquirit sobre eficiència energètica i green computing va jugar un paper clau per evitar un col·lapse tecnològic total.

Quan la llum va tornar, no només es va encendre l’electricitat. També va quedar clar que la millor infraestructura d’un país és la seva gent. I que, fins i tot en la foscor, una societat cohesionada pot ser la llum que evita el caos.

---

**Referències**  
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 minuts](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Gestió de la demanda elèctrica - REE](https://www.esios.ree.es/es/gestion-de-la-demanda)  
4. [Green computing - Viquipèdia](https://es.wikipedia.org/wiki/Green_computing)


L'apagada d'Espanya del 2025 va demostrar que una societat cohesionada pot il·luminar fins i tot la foscor més inesperada.