Una data futura non è un calendario

Ogni articolo di questo sito porta una data di pubblicazione nella sua intestazione. Compare sotto il titolo, entra nei dati strutturati che legge un motore di ricerca ed è l’unica data che la mappa del sito arrivi mai a stampare. Dovrebbe essere un fatto.

Per un certo periodo ventiquattro di esse non lo erano. Portavano date distribuite sui sei giorni successivi, perché chi le ha scritte aveva in mente un ritmo di pubblicazione e lo ha messo nel file. Nove lingue ciascuno, quindi duecentosedici file. Ognuna di quelle pagine era in linea, esplorabile e indicizzata, e ognuna raccontava a un crawler, in forma leggibile dalla macchina, di essere uscita in un giorno che non era ancora avvenuto.

Non c’era nulla in rosso. La build era verde, i test erano verdi, le pagine venivano servite. L’unica cosa in grado di vedere la contraddizione era una macchina che leggeva la pagina, e le macchine non aprono segnalazioni.

Cosa diceva la cronologia

La prima cosa da stabilire era quale delle due date fosse vera. È un solo comando: chiedere a git quando ogni file è stato aggiunto per la prima volta. Tutti e ventiquattro sono stati aggiunti lo stesso giorno, in tre consegne, da tre cicli dello stesso lavoro notturno. Non c’è stata alcuna distribuzione su sei giorni. La dispersione era un’intenzione scritta in un campo riservato alle osservazioni.

Questa distinzione è tutto l’articolo. Un campo che registra ciò che è accaduto non può esprimere anche ciò che si progetta, perché un lettore non sa distinguere le due cose e un crawler nemmeno.

Perché non è stata costruita la pianificazione

La riparazione ovvia consiste nel rendere vere le date facendole rispettare dal sito: nascondere un articolo finché non arriva la sua data. Qui è la riparazione sbagliata per due motivi indipendenti, e vale la pena spiegarli entrambi perché il primo sfugge facilmente.

Questo sito è generato in modo statico. Le pagine sono composte una volta, durante la build, e servite come file. Un varco sulla data viene quindi valutato in fase di build e mai più. A mezzanotte non compare nulla; compare quando qualcuno costruisce. Un varco sulla data non produce perciò un calendario di pubblicazione, bensì un insieme di pagine assenti finché non capita che venga eseguita una distribuzione estranea.

Il secondo motivo è peggiore. Quei duecentosedici indirizzi erano già stati esplorati. Nasconderli fino alla loro data nominale significa servire un 404 per un massimo di sei giorni su pagine che un motore di ricerca ha già visto e indicizzato. Un 404 su un indirizzo già indicizzato non è un «torna più tardi», è un segnale di rimozione, e riprendersi costa assai più dell’inesattezza corretta.

Le date sono state quindi corrette al giorno in cui il lavoro è davvero atterrato, toccando solo quella riga in ciascuno dei duecentosedici file, e al suo posto è stata tolta la possibilità di scrivere una data futura.

Il varco sta alla fonte e non ha vie di fuga

La build dei contenuti rifiuta ora qualsiasi data di intestazione successiva al giorno in cui costruisce. Non un avviso: una build fallita, con il nome del file ed entrambe le date nel messaggio.

Due piccole decisioni al suo interno meritano un nome. Confronta con l’oggi nel fuso orario proprio del progetto e non con UTC, perché un articolo uscito qui a mezzanotte e mezza porta la data di qui, e un confronto con UTC rifiuterebbe un file proprio nel giorno della sua uscita. E non c’è di proposito alcuna deroga: nessuna variabile d’ambiente, nessuna opzione. Una via di fuga su una regola simile si usa una volta per un buon motivo e poi in modo permanente, e un calendario appartiene a un elenco di attività e non all’intestazione di un file già consegnato.

C’è un secondo varco più avanti, nel registro che compone gli articoli pubblicati, e lascia fuori ogni articolo la cui data di pubblicazione sia ancora nel futuro. È una rete per i percorsi che non passano dalla build: un file modificato a mano, una fusione che mescola due generazioni, un backup ripristinato. Controlla solo la data di pubblicazione e non quella di modifica, perché un refuso in un campo di data non deve far sparire una pagina già indicizzata.

E quel secondo varco viene valutato una volta, al caricamento del modulo durante la build. Sta scritto in un commento accanto, perché chi supponesse altro finirebbe per scrivere proprio la pianificazione contro cui questa sezione argomenta.

Una data che non si può dedurre è meglio ometterla

Lo stesso ciclo ha dovuto decidere quale data, se una, spetti alle pagine di documentazione, che non hanno alcuna intestazione. Si presentavano tre candidate, e tutte e tre sono false.

Le pagine di documentazione non portano perciò alcuna data di pubblicazione nei loro dati strutturati. Nulla è meglio di un numero plausibile, perché un numero plausibile è quello che nessuno verifica.

Lo stesso ragionamento valeva già per la mappa del sito. Le rotte fisse non portano alcuna data di modifica, e il motivo non è pigrizia: il loro contenuto è codice e il loro testo vive in nove cataloghi di traduzione, quindi qualsiasi data calcolabile seguirebbe qualcosa di diverso da ciò che il lettore vede. Un motore che preleva tre volte una pagina «cambiata» e la trova uguale impara a ignorare il campo, e allora il campo è peggio che assente sulle pagine in cui è reale. Gli articoli ne portano una, perché sta nell’intestazione accanto al titolo, dove chi riscrive il testo la vede davvero.

Dopo questo lavoro la copertura non è cambiata affatto: gli indirizzi degli articoli portano una data di modifica, tutto il resto no, esattamente come prima. È cambiato che duecentosedici di quelle date erano nel futuro, e ora nessuna lo è.

Un’altra contraddizione, risolta con l’identità

Rileggendo i dati strutturati è emersa una versione minore dello stesso problema: su alcune pagine l’autore e l’editore erano due entità distinte senza relazione dichiarata. Lette alla lettera, quelle pagine affermavano che l’articolo era stato scritto da un’impresa e pubblicato da un’altra. Entrambi puntano ora allo stesso identificativo. Nessuno si sarebbe lamentato, ed era comunque una nostra affermazione non vera.

Cosa metteremmo per iscritto

1. 01Non metta mai un’intenzione in un campo che registra un’osservazione. Un lettore non sa separarle, e una macchina nemmeno.
2. 02Confronti l’affermazione con la cronologia. Un comando sulla cronologia dei file ha stabilito quale delle due date fosse quella vera, e contraddiceva tutti e ventiquattro i file.
3. 03Un varco sulla data in un sito generato staticamente non è un calendario. A mezzanotte non compare nulla; compare alla build successiva.
4. 04Non nasconda indirizzi già indicizzati. Un 404 su una pagina esplorata è un segnale di rimozione, e la cura costa più del male.
5. 05Metta il varco dove l’errore si commette, faccia fallire la build e non aggiunga deroghe. Metta un secondo varco più avanti per i percorsi che saltano il primo.
6. 06Ometta una data che non può dedurre onestamente. Tre fonti plausibili, sbagliate tutte e tre, significano che l’uscita onesta è nessuna.

Per chiarezza su cosa sia tutto questo: questa è manutenzione di un sito pubblico, non una funzione di prodotto, e non ha cambiato alcun comportamento per cui qualcuno paghi. Una parte resta non provata. I dati strutturati sono stati validati sul loro stesso schema e riletti a mano, non da un crawler reale né da una vera scheda di anteprima. Nulla è stato misurato sull’indice di un motore di ricerca, perché quella misura richiede settimane e nessuno dovrebbe attenderla prima di togliere un’inesattezza.

Dal lavoro sul sito di Provibr. Quanto costa mantenere corretti sedicimila testi in nove lingue è in sedicimila chiavi, nove lingue, e come una collisione di numeri di campo in un protocollo sia rimasta nascosta è in due tornate, un solo numero di campo.