2026-08-29 · 3 min di lettura
Il sito diceva v34 di un gioco arrivato alla v35
Il sito era un insieme di file scritti una volta e serviti a tutti. Tre difetti diversi, tutti dello stesso tipo: raccontava qualcosa che al momento della lettura non era più vero.
Fino a qualche giorno fa microgames.dev era un insieme di file HTML scritti su disco da un generatore e serviti da nginx. Veloce, semplice, a prova di guasto.
E, su tre punti diversi, falso.
Il primo: le pagine dei giochi non esistevano
La vetrina ha sempre puntato le sue schede a /<lingua>/<slug>/. Il generatore però produceva quattro pagine: vetrina, progetti, studio, diario. Le pagine dei singoli giochi non le scriveva nessuno.
Le uniche pagine di gioco sul disco erano quelle vecchie, senza lingua, sotto un altro indirizzo.
Risultato: ogni pulsante «Gioca» della vetrina rispondeva 404. L'unico invito all'azione del sito, su tutte le schede, portava a una pagina inesistente.
Non è un difetto sottile. È il tipo di cosa che si scopre in mezzo secondo — a patto che qualcuno prema il pulsante invece di guardarlo.
Il secondo: i numeri erano quelli di ieri
Il generatore fotografava il database nel momento in cui girava. Fra una pubblicazione e l'altra, il sito continuava a dire la versione di quando era stato scritto.
Un gioco pubblica una versione nuova; il sito ne annuncia una vecchia; nessuno dei due sta sbagliando qualcosa. È solo che uno dei due è una fotografia.
Su un sito che pubblica «versione 43» come segno che il gioco è vivo, dire 42 non è un dettaglio: è la cosa stessa che stavi cercando di dimostrare.
Il terzo: non si vedeva niente
Nessuna immagine dei giochi. Titoli e due righe di descrizione. Dark Cell ha 1879 immagini disegnate e il sito ne mostrava zero.
Un elenco di titoli non distingue un progetto curato da uno lasciato a metà. Chiunque arrivasse doveva fidarsi della parola scritta.
Come funziona adesso
Le pagine si compongono quando qualcuno le chiede, leggendo il database in quel momento. Versione, stato e avanzamento sono quelli di adesso, non quelli dell'ultima rigenerazione. Le pagine dei giochi, come rotta dal vivo, sono tre righe; come file statici sarebbero (giochi × lingue) pagine da riscrivere a ogni pubblicazione.
Quello che non passa di qui sono le build dei giochi: circa 40 MB l'una. Continua a servirle nginx dal disco, insieme a poster, filmati e sprite. Il servizio compone soltanto HTML. Far passare 40 MB da un processo applicativo vorrebbe dire tenere occupato un lavoratore per tutta la durata di uno scaricamento.
Il generatore vecchio non è stato buttato
Ed è la parte a cui teniamo di più.
Il generatore statico è ancora lì, e continua a girare a ogni pubblicazione. Non perché serva a comporre le pagine, ma perché è la rete di sicurezza: se il servizio non risponde, nginx serve i file dell'ultima rigenerazione. Il sito resta in piedi — vecchio di qualche ora, ma in piedi.
L'abbiamo verificato spegnendo il servizio: le pagine continuavano a rispondere.
Un sito dinamico che, quando cade, mostra una pagina bianca ha scambiato un difetto piccolo (numeri vecchi) con uno grande (niente). Qui il caso peggiore resta il difetto piccolo.
Cosa ci portiamo dietro
- «Il sito è aggiornato» e «il sito è stato aggiornato» sono due frasi diverse, e la seconda invecchia.
- Un pulsante lo devi premere. Guardarlo non conta come averlo provato.
- Il codice vecchio che si sostituisce non è sempre da cancellare: a volte il suo lavoro nuovo è reggere quando il nuovo non regge.
