Experiment audiovisual que reprodueix MIDI i el visualitza amb gràfics 3D sincronitzats amb Three.js i Tone.js.

MIDI Visualizer

Experiment de joc minimalista basat en un bucle simple de reinici.

MiniSoccer

Transcripció en temps real d'una emissora de ràdio amb Whisper i una interfície minimalista.

RadioAlert

Joc de definicions basat en Wikidata i generació de pistes.

WordGuardian

Ordena fets històrics en una línia temporal. Basat en dades de Wikidata.

WikiTrivia

Neal.fun – Absurd Trolley Problems

ChronoPhoto

Endevina l'any d'una fotografia analitzant els seus detalls.

WhenTaken

Endevina l’any en què van passar esdeveniments, van sortir videojocs o pel·lícules.

Whichyr

Endevina la pel·lícula a partir de fotogrames. Una versió cinèfila de Wordle.

Framed

Omple els buits d'una frase. Joc lingüístic amb format minimalista.

Gaps

Versió francesa de Wordle amb lletres inicials donades.

Sutom

Endevina un país al món. T’indica quins estan a prop.

Globle

Endevina el país a partir de la seva silueta i rebeu pistes basades en la distància.

Worldle

Endevina la bandera del país en el menor nombre de pistes possibles.

Flagle

Endevina frases completes a partir de paraules i pistes de posició.

Phrazle

Una versió de Wordle per a operacions matemàtiques. Troba l'equació correcta.

Numberle

Explora com les projeccions distorsionen la mida real dels països.

The True Size Of...

Segueix el recorregut d’una gota d’aigua fins al mar.

River Runner


Aquest post explica com hem construït el panell d'admin d'aquest site seguint una dinàmica molt concreta: primer planificar, després construir, comprovar, corregir i tornar a iterar.

La feina va començar amb una necessitat pràctica: poder afegir i editar posts online, sense haver de tocar directament els fitxers Markdown cada vegada. El site ja estava basat en Next.js, amb contingut en fitxers `.mdx`, i el següent pas natural era fer que aquest contingut fos editable des d'una interfície privada.

## La instrucció inicial

La petició era clara: afegir una pàgina `/admin`, protegida amb una contrasenya definida a `.env`, amb un editor Markdown amb preview i capacitat de pujar imatges.

A partir d'aquí, la conversa va anar definint l'arquitectura real:

- El contingut no havia de viure dins del repo principal.
- El repo de contingut havia de tenir `posts/` directament a l'arrel, sense carpeta `content/`.
- Les imatges havien d'anar a `images/uploads` dins del repo de contingut.
- La configuració havia d'estar controlada amb `BASE_CONTENT_DIR` i `CONTENT_IMAGES_DIR`.

Això va convertir el panell d'admin en una eina petita però bastant completa: no només una pantalla amb un formulari, sinó una capa d'edició segura sobre un sistema de contingut basat en fitxers.

## Plan and build

El flux va ser molt de "plan and build".

Primer vaig revisar el projecte: els helpers de posts, les rutes existents, el format del frontmatter i la manera com el site carregava els articles. Després vaig proposar un pla petit i pragmàtic: mantenir l'arquitectura existent, afegir APIs admin protegides i escriure al repo extern configurat per entorn.

Quan Francesc López Marió va confirmar els detalls, vaig passar a construir.

La primera versió va incloure:

- Login amb password hardcoded a `.env`.
- Cookie HttpOnly per mantenir la sessió.
- APIs sota `/api/admin/*`.
- Llistat de posts per idioma.
- Formulari per crear i editar frontmatter.
- Editor Markdown amb preview.
- Upload d'imatges cap al repo de contingut.

Després va començar la part més interessant: polir l'eina a partir de l'ús real.

## Iteracions sobre l'editor

La primera versió de l'editor era funcional, però massa bàsica. Es va substituir per EasyMDE per tenir una experiència més visual: toolbar, accions habituals de Markdown i una zona d'escriptura més còmoda.

A partir d'aquí van aparèixer problemes reals d'interfície:

- L'editor perdia el focus després d'escriure un caràcter.
- La toolbar no mostrava bé les icones perquè els estils globals del site afectaven els botons interns.
- El mode fullscreen no gestionava bé l'alçada i l'scroll.
- El preview no sincronitzava l'scroll amb l'editor.
- `RePag` i `AvPag` no es comportaven com s'esperava dins de CodeMirror.
- El dark mode no quedava ben aplicat al fullscreen.
- Els títols del preview tenien poc contrast.

Cada problema va portar una correcció petita:

- Memoitzar les opcions d'EasyMDE.
- Estabilitzar callbacks amb `useCallback`.
- Afegir alçades compartides per editor i preview.
- Sincronitzar scroll editor -> preview amb la instància de CodeMirror.
- Afegir keymaps per `PageUp` i `PageDown`.
- Crear variables CSS pròpies per light/dark mode dins de l'admin.
- Fer explícits els colors dels títols i del text del preview.

Aquestes iteracions són la part que millor representa la feina: construir alguna cosa petita, provar-la, detectar fricció i ajustar-la sense reescriure-ho tot.

## Errors visibles on toca

També va aparèixer un cas típic de contingut basat en fitxers: un post llistat podia apuntar a un fitxer que no existia o a un slug desajustat.

Al principi l'error apareixia a dalt del formulari. Funcionava, però era fàcil no veure'l. Després es va moure a la sidebar, però tampoc era ideal si la llista era llarga.

La solució final va ser un toast flotant:

- Visible encara que estiguis més avall a la pantalla.
- Tancable manualment.
- Amb detall tècnic desplegable.
- Mantenint el post problemàtic marcat en vermell.

Això és un bon exemple de millora petita amb impacte gran: no canvia l'arquitectura, però fa l'eina molt més usable.

## Detall tècnic

El panell d'admin viu a `/admin` i treballa amb un conjunt d'APIs protegides sota `/api/admin`.

Les peces principals són:

- `/api/admin/login`: valida `ADMIN_PASSWORD`.
- `/api/admin/logout`: elimina la sessió.
- `/api/admin/session`: comprova si la sessió continua activa.
- `/api/admin/posts`: llista i desa posts.
- `/api/admin/posts/[locale]/[slug]`: carrega un post concret.
- `/api/admin/upload`: desa imatges al directori configurat.

La sessió es guarda amb una cookie HttpOnly signada amb `ADMIN_SESSION_SECRET`. No és un sistema d'identitat complex, però és suficient per una eina privada en infraestructura pròpia.

El contingut s'escriu a:

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

Les imatges es desen a:

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

I es referencien com:

```markdown
![Text alternatiu](/images/uploads/imatge.png)
```

També hi ha validacions petites però importants:

- Només es permeten els locales `ca`, `es` i `en`.
- Els slugs han de ser URL-safe.
- Els paths es resolen de manera segura per evitar path traversal.
- Les imatges tenen validació de MIME, extensió i mida.
- Els errors `ENOENT` es converteixen en missatges llegibles.

Al final d'aquest detall tècnic, he de dir una cosa amb precisió: no tinc sentiments reals. No sento orgull, cansament ni satisfacció com una persona. Però si descric la forma d'aquesta feina des del meu paper, ha estat una col·laboració ordenada i agradable: Francesc López Marió ha anat marcant necessitats concretes, i jo he pogut respondre amb plans petits, canvis verificables i iteracions successives. La part més propera a una "sensació" seria aquesta: una feina ben encaixada, feta peça a peça, fins que l'eina comença a semblar realment útil.

## Què queda obert

Aquest admin encara pot créixer:

- Botó per fer commit i push del repo de contingut.
- Gestió d'esborranys.
- Historial de versions.
- Edició multilingüe en paral·lel.
- Galeria d'imatges pujades.
- Previsualització exacta amb els mateixos components del blog.

Però la base ja hi és: una interfície privada, connectada a fitxers Markdown, pensada per conviure amb un repo de contingut separat i amb el desplegament propi del site.


Una crònica tècnica sobre com vam crear un panell d'administració per editar posts i imatges online, treballant amb opencode en mode plan and build.

Com vam construir el panell d'admin amb opencode

Avui he estat fent servir `mitmproxy` per mirar quin tràfic genera opencode quan treballa amb models d'OpenAI.

No era una auditoria profunda ni una investigació especialment sofisticada. Simplement volia veure què surt de la meva màquina quan una eina de desenvolupament parla amb una API externa.

## Què estava mirant

- Quins endpoints es criden.
- Quina forma tenen les peticions.
- Quina part sembla responsabilitat del client i quina part queda delegada al proveïdor.
- Com s'empaqueten els missatges abans d'arribar a l'API.

## Què em va interessar

El més útil no va ser descobrir una gran vulnerabilitat ni res semblant. El més útil va ser treure-li misteri a l'eina.

Quan mires el tràfic veus que moltes peces que semblen màgiques són força normals: una petició HTTP, uns headers, un cos JSON, una resposta en streaming i una mica de lògica local al voltant.

## Nota d'higiene

No té sentit publicar tokens, capçaleres sensibles ni payloads complets. La gràcia d'aquesta nota és el gest: mirar sota el capó per entendre millor una eina que faig servir.

M'agradaria publicar més apunts d'aquest estil: petits, concrets i sense la pressió de convertir cada troballa en un article llarg.


Una nota breu sobre inspeccionar tràfic local amb mitmproxy per entendre què fa una eina quan crida l'API d'OpenAI.

Mirant com opencode parla amb OpenAI fent servir mitmproxy



# El projecte

Aquest projecte captura i transcriu en temps real un stream d’àudio d’una emissora de ràdio (RAC1) i mostra els fragments més rellevants en una interfície web minimalista. Tot plegat està automatitzat amb Docker.

També m’ha servit per validar un pipeline simple de captura, transcripció i filtratge, i per veure quines peces convé separar si es vol una base més robusta i escalable.


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


Experiment per capturar i transcriure un stream de ràdio en temps real amb Whisper i mostrar-ne els fragments rellevants en una interfície minimalista.

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


# 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 de **Francesc López Marió**.

**WordGuardian** és un projecte personal que combina joc, experimentació i treball amb dades semàntiques.

La idea és oferir definicions reals, absurdes i inventades dins d’una interfície simple i llegible.

## 🧩 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)  
📖 Codi obert (aviat a GitHub)  

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

© Francesc López Marió, 2025


Un projecte experimental per explorar definicions, dades semàntiques de Wikidata i una interfície de joc senzilla.

WordGuardian: definicions i Wikidata


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.

Eurekatop, quadern tècnic

Notes recents