Devlog dal sito del Festival della Canzone Artificiale: dodici versioni in sei giorni, un motore di gara con televoto e giuria, settantacinque criticità chiuse. E il momento in cui il Thin Stack ha perso il suo client.
In questo periodo sto lavorando a due grandi progetti web, uno più grande dell’altro. Il primo, che è il tema di questo articolo, è allo stato attuale il capolavoro assoluto tra le mie produzioni, e ha ridefinito perfino il mio concetto di Thin Stack React + PHP. Dell’altro vi parlerò prestissimo.
Naturalmente questo articolo non vuole essere un annuncio: parla di una cosa che da ieri notte è attiva e pubblica, ma che non abbiamo ancora lanciato sui nostri canali, soprattutto su Runtime Radio. No, questo è un devlog. È un modo per raccontarvi in modo semplice la complessità che sta dietro il progetto. E poi, inevitabilmente, è anche uno spoiler. 😄
Il sito è questo:
👉 festivaldellacanzoneartificiale.it
Prima di tutto: che cos’è il Festival della Canzone Artificiale
Nel 2024 a Runtime Radio abbiamo fatto una cosa che in Italia non aveva fatto nessuno: un festival di canzoni scritte e cantate dalle macchine. Non un esperimento in una puntata, un festival vero, con le sue serate, i suoi brani in gara e il suo pubblico che vota.
Da allora ne abbiamo fatte tre edizioni. La quarta apre le candidature il 20 settembre, le chiude il 25 ottobre, e si tiene a metà novembre in tre serate: due semifinali e una finale.
Un festival, dal punto di vista di chi deve costruirgli il sito, non è una vetrina. È un affare complicato: raccoglie brani da estranei, li deve moderare, li deve far ascoltare a una giuria, li deve far votare da un pubblico che sta sul divano col telefono in mano, deve contare i punti senza sbagliare e deve pubblicare una classifica che nessuno possa contestare.
Il sito che serve a fare tutto questo l’ho rifatto da zero fra il 31 agosto e ieri. Sei giorni. Dodici versioni.
La decisione che ha ridefinito tutto FDCA: via React
Qui devo spiegare una cosa a chi non fa questo mestiere, perché è il cuore dell’articolo.
Da un paio d’anni un sito web moderno si costruisce quasi sempre in due pezzi. C’è un server, che custodisce i dati, e c’è un programma che gira dentro il vostro browser e disegna le pagine. Il secondo si scrive con strumenti come React. Il browser scarica il programma, il programma chiede i dati al server, e poi costruisce sotto i vostri occhi quello che vedete.
Funziona, ed è quello che ho fatto per anni. Ci ho scritto anche un manuale, React + PHP The Thin Stack, che spiega come tenere quei due pezzi leggeri invece di lasciarli ingrassare.
Il problema è che quei due pezzi devono sapere le stesse cose, e non c’è nessuno che li obblighi a essere d’accordo. Gli indirizzi delle pagine sono scritti due volte, una di qua e una di là. Le regole su chi può fare cosa, idem. E ogni volta che modifichi una riga devi far girare una macchina che impacchetta tutto, la cosiddetta build, prima di poter caricare qualcosa sul server. Se la build si rompe, non pubblichi.
Per il Festival ho fatto una cosa che tre anni fa mi sarebbe sembrata un passo indietro: ho tolto il pezzo che gira nel browser. Tutto.
Le pagine le compone il server, in PHP, e arrivano al vostro browser già fatte. Il JavaScript che resta serve al menu, ai moduli e a poco altro: un file solo, dodici chilobyte, cioè quanto una fotografia molto piccola. Niente build: modifico un file, carico quel file, è online.
Il Thin Stack ha perso il suo client. E il sito che ne è venuto fuori è il migliore che abbia fatto.
Le conseguenze si vedono subito. Le pagine sono già scritte quando arrivano, quindi Google le legge senza dover eseguire niente e chi ha una connessione lenta non aspetta due programmi in fila. Non esiste il momento in cui il sito è bianco perché sta ancora caricando sé stesso. E soprattutto non esiste più la doppia verità: le regole stanno in un posto solo, e quel posto è il server, che è anche l’unico di cui ci si possa fidare.
I numeri, per darvi la misura: novanta file PHP, ventimilacinquecento righe, quindici aggiornamenti dello schema del database, un foglio di stile da 62 KB scritto a mano senza nessun framework, e i caratteri tipografici ospitati sul nostro server invece che su quelli di Google, così nessuno viene schedato mentre legge una pagina.
Il pezzo difficile: il motore della gara
Tutto quello che ho scritto finora è la casa. Adesso viene l’impianto idraulico, ed è la parte di cui vado più fiero.
Le candidature
Un musicista arriva sul sito, compila un modulo, allega il brano e la copertina. Fin qui niente di strano. Poi ci sono due campi che il regolamento di quest’anno pretende e che rendono la cosa più interessante.
Il primo è il Manifesto dell’Opera: cinque righe in cui l’autore racconta che cosa ha voluto fare. Non è decorativo, è obbligatorio, e il sito non accetta la candidatura se sta sotto i trecento caratteri.
Il secondo è la Documentazione Tecnica: con quali strumenti è stato generato il brano e, se l’autore vuole, con quali istruzioni. In un festival di musica artificiale è l’equivalente della lista degli ingredienti.
Accanto a ogni campo c’è una riga di spiegazione sempre visibile e un blocco che si apre e racconta per esteso di che si tratta. Sembra una cortesia; è il modo di non ricevere venti moduli compilati male.
Il televoto, e il guaio che ci ha quasi fregati
Qui arriva la storia migliore di tutte, e comincia con una domanda semplice: come fai a impedire a una persona di votare cento volte?
La risposta che viene in mente a tutti è: guardi da quale connessione arriva il voto e ne conti tre per connessione. È quello che avevamo fatto. Ed è sbagliato in un modo che non si vede finché il sito non è in mano al pubblico vero.
Il vostro telefono, quando è sulla rete mobile, non ha un indirizzo suo. Gli operatori italiani mettono migliaia di clienti dietro lo stesso indirizzo pubblico. Per il nostro sito, tutta Milano collegata a un certo operatore era una persona sola.
Il che voleva dire: durante la serata, dopo il terzo voto arrivato da quella rete, tutti gli altri avrebbero trovato le urne chiuse. E la parte peggiore non è nemmeno quella. La pagina, a quel punto, mostrava «Voto registrato. Grazie» a gente che non aveva votato niente.
Sarebbe successo la sera della prima semifinale, davanti a tutti, e sarebbe stato impossibile capire perché.
La correzione ha richiesto di ripensare che cosa stia difendendo cosa. Adesso la difesa vera è l’indirizzo email: una scheda a testa, garantita dal database, e ogni voto va confermato con un clic su un messaggio. La connessione non limita più i voti validi. L’unico tetto per rete riguarda le schede ancora da confermare, cinque nell’ultima ora, perché ognuna costa un’email in uscita, e una rete che ne chiede cinquanta senza confermarne una non sta votando, sta usando il nostro sito per spedire posta.
E già che c’eravamo abbiamo sistemato due furbizie:
Il trucco del più. Su quasi tutti i servizi di posta, mario+1@, mario+2@ e mario+3@ sono lo stesso indirizzo, e le email arrivano tutte a Mario. Erano tre schede diverse per il sito. Adesso sono una.
Il trucco dei punti. Su Gmail, ma.rio@ e mario@ sono la stessa casella. Anche quelli, adesso, sono la stessa scheda.
La scheda che si perdeva senza dirlo
Ancora sul voto, perché il difetto successivo era più silenzioso e per questo peggiore.
Il sito mandava l’email di conferma e non guardava se fosse partita davvero. Se il servizio di posta faceva i capricci, il votante leggeva «controlla la tua casella» davanti a una casella vuota. La scheda restava lì in sospeso e scadeva da sola il giorno dopo. E se quella persona ci riprovava con lo stesso indirizzo, il sito le rispondeva «questo indirizzo ha già una scheda».
Cioè: la respingeva per colpa di un’email che non era mai arrivata.
Adesso il sito ci riprova una seconda volta, e se anche la seconda non parte lo dice: «la scheda è pronta ma non conta finché non la confermi, riprova fra un minuto con lo stesso indirizzo». E soprattutto la stessa email che rimanda una scheda in sospeso la rinnova invece di rifiutarla: scelte nuove, link nuovo, messaggio nuovo. È la via d’uscita per chi la posta non l’ha ricevuta.
La giuria, e la regola che non si negozia
Quest’anno accanto al televoto c’è una giuria tecnica: cinque giudici, ognuno con il suo accesso, che danno un voto da 0 a 10 a ogni brano.
Il sistema che tiene insieme le due cose ha qualche dettaglio di cui vale la pena parlare, perché sono decisioni prese per evitare litigi, non per far funzionare il codice.
La scheda si scrive in bozza e poi si consegna. Finché non è consegnata i voti non entrano in nessun conteggio, e dopo la consegna non si tocca più. È il gesto della busta chiusa.
Un giudice assente non falsa niente. La classifica di giuria si calcola sulla media dei voti dati, non sulla somma. Se uno dei cinque salta un brano, o non consegna la scheda, gli altri brani non ne guadagnano vantaggio.
I punti non sono scritti da nessuna parte. La formula è numero di brani − posizione + 1. Con dieci brani fa 10, 9, 8 e così via fino a 1. Con otto o con dodici si adatta da sola. Nessuna serata è cablata a mano dentro il programma, e questo vuol dire che il giorno in cui la direzione artistica decide di fare tre semifinali invece di due, non c’è una riga di codice da cambiare.
A pari merito si sale insieme. Due brani appaiati prendono lo stesso punteggio e la posizione successiva salta: secondo, secondo, quarto. Se il pareggio arriva in finale sui punti totali, prevale la media della giuria. Nessun titolo condiviso.
E poi c’è il vincolo che non si tratta, quello che ho scritto in maiuscolo dentro le specifiche:
Finché il turno è aperto, nell’area della giuria non compare nessun numero del pubblico. Né classifica, né conteggio delle preferenze, né «il più votato».
Perché sapere che un brano sta stravincendo il televoto cambia il voto di un giudice, anche di un giudice onesto, anche senza che se ne accorga. Alla chiusura del turno, quando i numeri sono congelati e non si muovono più, i giudici vedono tutto. Prima, niente. Non è una cortesia dell’interfaccia: è una regola scritta nel programma, e nella pagina della giuria quei numeri proprio non arrivano.
Alla fine si assegnano tre premi, e sono tre conti diversi: il Premio del Pubblico sul solo televoto della finale, il Premio della Giuria sui soli voti dei giudici, e il Vincitore del Festival sulla somma dei due.
La prova generale
Come faccio a sapere che tutto questo funziona davvero?
Non guardandolo. C’è un programma che si chiama prova generale e che percorre un festival intero dall’inizio alla fine: crea i giurati, apre le iscrizioni, manda candidature, le modera, apre un turno, fa votare il pubblico, fa entrare i giudici, consegna le schede, chiude il turno e legge la classifica pubblicata. Quarantuno controlli, due o tre minuti, e alla fine smonta tutto e rimette le impostazioni com’erano.
Due scelte lo rendono utile invece che rassicurante.
Guida il sito, non il database. Fa il login come farebbe una persona, manda i moduli con i loro controlli di sicurezza, vota dalle pagine vere. Un collaudo che scrive direttamente nel database dimostra che funziona il database, che non è la domanda.
Rifà i conti per conto suo. La formula dei punti è riscritta dentro il collaudo, da capo, senza usare una riga del sito. Se la formula del sito fosse sbagliata, un collaudo che usasse la stessa formula la confermerebbe invece di smentirla. È il genere di dettaglio che sembra pedanteria finché non ti salva.
E i dati sono scelti apposta perché la prova possa fallire: la giuria ribalta l’ordine del pubblico, un giurato salta un brano, un altro non consegna, e le preferenze non seguono l’ordine di scaletta — altrimenti «ordinato per scaletta» e «ordinato per voti» darebbero la stessa sequenza e metà dei controlli non distinguerebbero niente.
Accanto alla prova generale ci sono le prove delle singole versioni. In tutto, oggi, 245 controlli automatici.
Fra i quali il mio preferito: quello che misura, sul login vero, quanto tempo il sito ci mette a rispondere a un nome utente che esiste e a uno che non esiste. Se le due risposte durano diverso, uno che ci prova impara i nomi degli account cronometrando. Erano cento millesimi di differenza. Adesso sono sette.
Settantacinque cose che non andavano
In sei giorni il progetto ha attraversato due letture integrali del codice fatte con occhi ostili: una il 2 settembre, una ieri. Insieme hanno prodotto settantacinque criticità, dalle gravissime alle lievi, e sono chiuse tutte.
Non le elenco. Ne racconto tre, perché sono tre modi diversi di sbagliare.
Una porta che si apriva indovinando una parola. Quando si chiude il sito per manutenzione, appare la pagina di cortesia. Solo che bastava aggiungere ?preview=1 all’indirizzo, cioè indovinare la parola «preview», che non è esattamente un’impresa, e il sito si apriva a chiunque per ventiquattr’ore. Adesso serve una chiave che si genera nel pannello, e cambiarla scollega in un colpo tutti quelli a cui era stata data.
Una pagina bianca al posto di una spiegazione. Cancellare un giurato che aveva già votato, o un’edizione che aveva dei turni dentro, non dava un errore: dava una pagina vuota. Chi ci finiva non poteva sapere se avesse rotto qualcosa. Adesso il pannello conta prima cosa sta per succedere e lo dice a parole.
Un backup che sembrava non partire. Il salvataggio automatico del database è impostato alle 4:15 del mattino… del fuso orario della California, dove sta il nostro server. Che d’estate sono le 13:17 italiane. Il backup girava tutti i giorni, puntualissimo, nel primo pomeriggio. Chi guardava il pannello la mattina vedeva la data del giorno prima e concludeva che fosse saltato.
Nessuna di queste tre è un errore di programmazione. Sono tre modi in cui un sistema può dire il falso su sé stesso, ed è la categoria di guai che mi interessa di più.
Le cose piccole, che poi sono quelle che si vedono
Un paio di esempi di lavoro invisibile, perché un devlog onesto le racconta.
A 320 pixel il sito sforava di 31. Trecentoventi pixel è lo schermo più stretto ancora in circolazione. Il colpevole non era, come sembrava, l’intestazione: era la casella email della newsletter in fondo alla pagina. Un campo di testo lasciato libero chiede al browser la sua misura naturale, una ventina di caratteri, anche mentre il browser sta cercando di stringerlo, e col pulsante «Iscriviti» di fianco quella riga pretendeva 331 pixel in una colonna che ne aveva 280. Ricontrollate tutte e dodici le pagine a quattro misure diverse.
Le voci del menu sul telefono uscivano dallo schermo. Il corpo del testo guardava solo l’altezza dello schermo e mai la larghezza: su un telefono alto e stretto cresceva finché non chiedeva il doppio della colonna. Una voce sola è stata accorciata davvero — «Il Regolamento» è diventato «Regole», perché la parola tutta in maiuscolo chiedeva 274 pixel in una colonna da 230. E c’è un prezzo, che va detto: su un telefono alto adesso le voci sono più piccole di prima. Prima erano grandi a costo di uscire dallo schermo.
Una cosa che il sito non fa, per scelta
Non c’è Google Analytics. Non c’è nessun sistema di statistiche.
Era nella lista iniziale, e l’ho tolto io durante la lavorazione. Metterlo avrebbe voluto dire il banner dei cookie con il consenso da chiedere prima di tutto, l’informativa e la cookie policy da riscrivere, e le regole di sicurezza della pagina da aprire verso i server di Google. Cioè riaprire il capitolo privacy il giorno dopo averlo chiuso.
Il risultato è che non so quante persone visitano il sito, e mi va benissimo. I caratteri tipografici stanno sul nostro server, i visitatori anonimi non ricevono nessun cookie, gli indirizzi IP non finiscono mai nel database nemmeno per i controlli antispam, e quel poco che serve a far funzionare le cose è scritto in un registro dei trattamenti che elenca voce per voce che cosa conserviamo e per quanto.
Dove siamo, e lo spoiler
Il sito è in piedi e completo. Le candidature aprono il 20 settembre, e l’annuncio vero lo faremo quel giorno: finché la porta è chiusa, l’unica cosa che potremmo chiedervi è di iscrivervi alla newsletter, e non è per quello che abbiamo lavorato sei giorni. Il 20 la frase diventa «candida il tuo brano», ed è tutta un’altra cosa.
Nel frattempo il sito ha già dentro tutto l’archivio: cinquantanove articoli delle edizioni passate, recuperati uno per uno dall’Internet Archive quando il vecchio sito è sparito, le tre edizioni con le puntate del podcast, il regolamento in PDF, l’area stampa e il manuale della giuria in quattordici pagine.
Quanto all’altro progetto, quello «più grande» dell’incipit: è più grande davvero, e per adesso mi fermo qui. Diciamo che se questo è il capolavoro, quello è il problema che me lo ha fatto diventare.
Ci sentiamo prestissimo.
Il Festival della Canzone Artificiale è un progetto Runtime Radio. Sito: festivaldellacanzoneartificiale.it. Stack: PHP 8 server-rendered, SQLite, CSS e JavaScript scritti a mano, nessun framework, nessun passo di build
