Chi sono

Sono Giorgio Alfredo Pagano, sviluppatore Drupal in SparkFabrik. Il mio terreno sono i servizi digitali degli enti pubblici italiani, dove il nodo è riconoscere la persona: SPID, single sign-on, federazione identitaria. Su drupal.org firmo sjpagan, e uno dei sette moduli che porto avanti gira oggi su otto siti.

Di cosa mi occupo, esattamente?

Scrivo software per il web, e da undici anni lo faccio quasi sempre con Drupal.

Non è una scelta di comodo. Drupal è uno dei pochi CMS che tratta la struttura del contenuto come un contratto: i tipi di contenuto, i campi, i ruoli e i flussi di pubblicazione sono dati espliciti, versionabili, e non convenzioni sepolte in un template. Un ente pubblico che deve mostrare gli stessi dati su un portale, un'app e un'API, e dimostrare su richiesta che coincidono, finisce per appoggiarsi a quella esplicitezza. Quello che sembrava un dettaglio tecnico è ciò che tiene in piedi il progetto.

Il mio lavoro quotidiano è modellazione dei contenuti, gestione della configurazione, architetture disaccoppiate, pipeline di migrazione e sviluppo di moduli custom.

Cosa ho pubblicato?

Sei moduli su drupal.org, come sjpagan. Due li uso come biglietto da visita perché rispondono a problemi che ho incontrato davvero.

Native Observability (si apre in una nuova scheda) porta il tracciamento delle richieste dentro Drupal: correlation ID, span di esecuzione, metriche di performance, analisi forense delle rotte, ed esportazione verso OpenTelemetry, Prometheus e Grafana. Nasce da una domanda concreta: perché per capire quale hook sta rallentando una pagina devo montare un APM esterno in ogni ambiente? Al 20 settembre 2026: pubblicato il 12 febbraio 2026, versione stabile 2.0.0 del 17 settembre 2026, compatibile con Drupal 10 e 11, PHP 8.2 o superiore, otto siti dichiarano di usarlo, ed è coperto dalla security advisory policy di Drupal.

DOC to HTML (si apre in una nuova scheda) lo porto avanti dal 2017. Converte documenti caricati dal form del nodo in HTML pulito passando da LibreOffice, con revisione in CKEditor e salvataggio nei campi di testo. È il modulo che nasce dalla realtà di ogni redazione pubblica: i contenuti arrivano in .docx, e continueranno ad arrivare in .docx. Al 20 settembre 2026: pubblicato il 20 gennaio 2017, versione stabile 2.0.1 del 2 maggio 2026, compatibile con Drupal 10.1 e 11, PHP 8.1 o superiore, tre siti dichiarati, coperto dalla security advisory policy.

Gli altri cinque sono moduli più piccoli. Style Management, Views Field Percentage, Vsauce Sticky Popup e AI Disclosure sono nati ciascuno da un problema specifico e lasciati pubblici perché a qualcun altro servivano le stesse quindici righe. Views custom link ha una storia diversa: lo ha creato luxx91 (si apre in una nuova scheda) nel gennaio 2019 e io ci sono entrato come co-maintainer; oggi lo usano quindici siti e cerca qualcuno che se ne prenda cura.

Che un modulo sia coperto dalla security advisory policy significa una cosa precisa: se qualcuno ci trova un buco, esiste un processo formale per segnalarlo e io mi sono impegnato a rispondere. È il motivo per cui pubblicare un modulo non è la stessa cosa che caricare del codice su un repo.

Cosa mi ha insegnato lavorare per la Pubblica Amministrazione?

Ho collaborato alla realizzazione di piattaforme per la Pubblica Amministrazione, ed è il contesto in cui ho imparato di più, perché è il posto dove gli errori si vedono.

Il pubblico di un servizio pubblico è obbligato a restare: chi deve richiedere un certificato o seguire una pratica ha quel sito e basta. Questo cambia le priorità. L'accessibilità esce dalla categoria delle caselle di conformità: decide se il servizio esiste per tutti o solo per una parte. L'identità digitale smette di essere una schermata di login e diventa il punto in cui lo Stato riconosce una persona.

La parte che mi ha coinvolto più da vicino è la federazione identitaria: SPID, single sign-on, integrazione fra sistemi che per vent'anni si sono autenticati ciascuno a modo proprio e adesso devono parlarsi. Nessuno se lo mette in portfolio, e perdona pochissimo. Un flusso di autenticazione ha un margine che vale zero: o riconosce la persona giusta, o si scrive un rapporto di incidente.

Cosa c'entrano la stampa 3D e i droni FPV?

C'entrano più di quanto sembri, e non sono un elenco di hobby.

Stampo in 3D con una Prusa. È una macchina che arriva dalla tradizione RepRap dell'hardware aperto: si ripara, si aggiorna e si modifica invece di sostituirla, e i pezzi di ricambio spesso te li stampi con la stampante stessa. Vale anche fuori dall'officina: è la stessa idea per cui pubblico moduli su drupal.org invece di tenermeli in un cassetto.

La stampa 3D mi ha insegnato una cosa che il software nasconde bene: una tolleranza sbagliata non si negozia. Un pezzo progettato con due decimi di millimetro di troppo resta fuori: non entra un po' meno, resta fuori e basta. E non c'è modo di scoprirlo rileggendo il modello: si scopre stampando, aspettando due ore e provando a incastrarlo. Da quando disegno pezzi che devono entrare in pezzi veri ho smesso di fidarmi delle verifiche fatte a mente, e ho preso l'abitudine di misurare prima di dichiarare.

Volo con droni FPV. FPV sta per first person view, visuale in prima persona: invece di guardare il drone da terra e manovrarlo a vista, si indossano degli occhiali che ricevono in diretta il video di una telecamera montata a bordo. Si vola dal punto di vista del drone, non dal proprio. La differenza va oltre la comodità: sei dentro l'oggetto invece che fuori, e la percezione dello spazio e della velocità cambia completamente.

Ed è proprio lì che la cosa diventa istruttiva per chi scrive software: la latenza è un budget, non un aggettivo. Fra quello che accade davanti alla telecamera e quello che vedi negli occhiali passa un ritardo, e quel ritardo si spende: in codifica, in trasmissione, nella catena radio. A quella velocità lo scarto fra ottanta e centocinquanta millisecondi decide se voli o finisci contro un albero. Quando poi progetto un sistema in cui una persona aspetta una risposta, quel modo di ragionare resta: mai «è veloce», sempre quanto e misurato dove.

Sono anche due pratiche in cui il ciclo di correzione è brutalmente onesto. Il pezzo entra o non entra, il drone vola o cade. Nessuna delle due ti lascia credere di aver capito quando non hai capito, ed è esattamente ciò che manca al software, dove un errore può restare invisibile per mesi.

Come lavoro?

Tre abitudini, che valgono anche quando lavoro da solo.

La specifica prima del codice. Ogni cambiamento non banale comincia da un documento che dice perché si fa, cosa cambia e come si verifica che sia fatto. Serve meno a coordinarsi che a scoprire, mentre lo si scrive, che il problema era un altro.

Le decisioni a verbale. Le scelte architetturali finiscono in un registro datato, con le alternative valutate e le conseguenze attese. Il valore sta nel poter tornare sei mesi dopo e capire se una decisione era sbagliata o se erano cambiate le condizioni. E, ogni tanto, dover scrivere che i dati hanno smentito quello che si era deciso.

Misurare invece di supporre. Vale per le prestazioni, vale per i costi, vale per gli strumenti nuovi. Un'intuizione plausibile e un numero rilevato non hanno lo stesso peso, e quasi sempre il numero dice qualcosa che l'intuizione non prevedeva.

Come si verifica quello che c'è scritto qui?

Tutto ciò che ho affermato sopra è controllabile, e questo è deliberato.

• Il profilo con i moduli, le release e le date: drupal.org/u/sjpagan (si apre in una nuova scheda)
• Il codice che sta fuori da drupal.org: github.com/sjpagan (si apre in una nuova scheda)
• I moduli, con i numeri di adozione aggiornati da drupal.org stesso: Native Observability (si apre in una nuova scheda) · DOC to HTML (si apre in una nuova scheda)

I numeri riportati in questa pagina sono rilevati al 20 settembre 2026. Quelli su drupal.org cambiano da soli: se trovi una differenza, ha ragione drupal.org.