Developers Italia

Esperienze di sviluppo per il software della Pubblica Amministrazione

Come Developers Italia e Designers Italia hanno aggiornato uno dei tasselli fondamentali del design system del Paese. Ce lo racconta Andrea Stagi, del Dipartimento per la trasformazione digitale

Ingegnere che disegna una città

Il cuore pulsante del nuovo design system del Paese

Designers Italia e Developers Italia hanno avviato una completa revisione del design system del Paese, ovvero degli strumenti e delle risorse necessarie alla realizzazione delle interfacce per i siti e i servizi digitali della Pubblica Amministrazione, così da renderle coerenti, semplici e fruibili da tutti i cittadini. Tra questi strumenti il cuore pulsante è rappresentato dalla versione 2.0 di Bootstrap Italia, un framework di sviluppo front-end basato su Bootstrap 5, del quale si ereditano tutte le funzionalità, completamente open source, e corredato di componenti, griglie e classi di utilità per progettare con qualità tenendo l’accessibilità al centro del design system del Paese.

Togliere la ruggine e rilanciare la community

Il framework Bootstrap Italia è, secondo noi, il modo più semplice e sicuro per costruire interfacce web moderne, inclusive e semplici da mantenere. La sfida di quest’anno è stata quella di aggiornare il vecchio Bootstrap Italia basato sulla versione 4 di Bootstrap e, di seguito, portarlo a Bootstrap 5, migliorando i tool di sviluppo e i componenti grazie a strumenti e tecnologie più moderne e valorizzando i contributi della community.

Come primo passo, abbiamo aggiornato la versione iniziale di Bootstrap Italia risolvendo le issue segnalate e revisionando le pull request (le proposte di contributi) degli utenti. A questa prima fase, è seguito il rilascio di una versione 1.5.0 che comprendeva numerosi miglioramenti delle fondamenta, del core. Insieme a quest’ultima versione abbiamo quindi introdotto Docker (guarda il video della community call su Docker), al fine di facilitare la configurazione dell’ambiente di sviluppo per chi volesse contribuire al codice senza dover impostare un ambiente locale. Ci siamo poi dedicati al rilascio di altre versioni del primo Bootstrap Italia che comprendessero aggiustamenti sull’accessibilità: gli esperti di AgID competenti sul tema hanno collaborato con noi aiutandoci a migliorare accessibilità e usabilità. Questo precedente Bootstrap Italia basato su Bootstrap 4 si trova attualmente alla versione 1.6.3, e da questa versione in poi necessita soltanto di interventi di manutenzione.

Grazie ad un approccio all’accessibilità by design e alle evolutive fatte sulla versione 1.6.3, abbiamo poi avviato la creazione di un repository temporaneo (che sarà presto riportato all’interno del repository principale bootstrap-italia) dove sono iniziati i lavori per il porting a Bootstrap 5, importante passaggio per dare scalabilità e futuribilità a questo progetto, oggi fondamenta del design system del Paese.

La scelta degli strumenti: da Jekyll a Rollup.js

Per mantenere la generazione della documentazione abbiamo confermato, in questa prima fase, la scelta di Jekyll: questo ci ha permesso di concentrarci sulla lavorazione del core evitandoci di dover agire anche sulla parte di documentazione. Docker e Vercel sono stati ugualmente confermati, in quanto tool fondamentali per avere sempre a disposizione anteprime delle modifiche e delle pull request.

Rimaneva da migliorare l’aspetto relativo alla creazione degli asset e dei bundle finali, fino ad adesso gestita con Gulp.js: era necessario sostituirlo con qualcosa di più aggiornato e funzionale alle esigenze di sviluppo web moderne. La nostra scelta è ricaduta su Rollup.js, che oltre a produrre una versione minima di JavaScript e CSS, permette anche di suddividere i vari componenti in moduli JavaScript. Grazie a questa separazione, lo sviluppatore può importare i soli componenti necessari per l’applicazione che sta sviluppando, attuando quello che in termine tecnico si definisce tree-shaking.

Ottimizzare il codice

Grazie al tree-shaking è possibile limitare la dimensione del JavaScript finale, in modo da velocizzare le performance del sito. Un esempio lo potete trovare in questo repository dove abbiamo inserito all’interno di una singola pagina web alcuni componenti di Bootstrap Italia 2.0.

screenshot di Bootstrap Italia 2

Ma come si utilizzano questi componenti e come entra in gioco il tree-shaking? Ad esempio se volessi utilizzare solo il componente Carousel di Bootstrap Italia, occorre creare il codice markup ad hoc come da documentazione, importare il solo componente “CarouselBI”

import { CarouselBI } from "bootstrap-italia"

e istanziare il componente passando il riferimento all’elemento radice che abbiamo nel markup (nell'esempio un div con id “myCarousel”).

const carousel = new CarouselBI(document.getElementById("myCarousel"))

Utilizzando un bundler che supporta il tree shaking (come Rollup o Webpack), solo Slider e la parte comune di JavaScript verranno inseriti nel bundle finale e non l’intero Bootstrap Italia.

screenshot di tree shaking su Bootstrap Italia 2

Da alcuni test fatti, le dimensioni del JavaScript finale sono risultate nettamente ridotte rispetto all’importazione dell’intero framework Bootstrap Italia. Ecco qualche dato qui sotto, relativo alla demo:

Dimensioni Bootstrap Italia JS: 344 KB Dimensioni Demo JS: 133 KB

Ovviamente, è possibile intervenire anche sul CSS, in quanto tutti i fogli di stile sono suddivisi per componente e disponibili in formato SASS.

@import "bootstrap-italia/src/scss/custom/slider";

un altro screenshot di tree shaking su Bootstrap Italia 2

Sempre guardando l’esempio qui sopra, possiamo anche notare una notevole riduzione delle dimensioni del CSS finale:

Dimensioni Bootstrap Italia CSS: 501 KB Dimensioni Demo CSS: 209 KB

L’evoluzione del design system del Paese

Grazie al nuovo Bootstrap Italia, i siti e i servizi digitali della Pubblica Amministrazione e i modelli proposti da Designers Italia per i Comuni e le scuole, permettono di rispettare con più facilità i criteri di accessibilità definiti dalle Linee guida accessibilità e dalle relative WCAG 2.1, permettendo quindi una progettazione e uno sviluppo by default, e by design, più accessibile. Questo, inoltre, consente di facilitare l’adesione alla misura 1.4.1 del PNRR (Esperienza del Cittadino nei servizi pubblici) e di migliorare, in generale, le performance, l’usabilità e la soddisfazione d’uso di tutti i siti internet e i servizi digitali della Pubblica Amministrazione.

Tutti i cambiamenti effettuati su Bootstrap Italia nel passaggio a Bootstrap 5, e i consigli utili per effettuare la migrazione dal precedente Bootstrap 4, sono disponibili sulla pagina dedicata della documentazione.

Scopri di più e partecipa


Questo blog è pubblicato sul canale Medium di Developers Italia

Questo blog è redatto da Developers Italia

Vincenzo Di Nicola ci racconta come INPS ha adattato un software di qualità per identificare e segnalare malfunzionamenti tecnici, al fine di migliorare la qualità dei propri servizi.

Home page di bugs.inps.it

Nessun prodotto software è perfetto, ed è sbagliato pensare altrimenti. Ricordo bene come 15-20 anni fa chi comprava il Mac era solito recitare il dogma “i sistemi Apple sono sicuri e non hanno virus”.

La realtà è però ben diversa e se ne infischia degli slogan del marketing. Gli stessi colossi tech americani come ad esempio Meta (capitalizzazione 500 miliardi di dollari) hanno spesso problemi tecnici, come abbiamo tutti toccato con mano con i “down” di WhatsApp, Instagram e Facebook.

INPS, Istituto Nazionale Previdenza Sociale, non è un’eccezione, e come tutti i sistemi informatici ha le sue sfide da risolvere. E per alcuni versi quelle di INPS sono ancora più complesse di quelle di una Twitter o una Coinbase. Perché? Queste appena citate sono compagnie tech nate negli ultimi 15 anni, e hanno costruito organicamente la loro codebase da zero e nativamente nel cloud.

INPS invece è stata una pioniera informatica nella Pubblica Amministrazione a livello mondiale, digitalizzando i servizi già negli anni ‘80 (grande merito va alla lungimiranza di Gianni Billia. Va però sempre tenuto bene a mente che i meriti informatici non migliorano nel tempo come un buon vino. Tutt’altro. Senza costante e assidua innovazione, quello che 40 anni fa era un punto di forza oggi si trasforma in una debolezza. Come?

L’INPS serve gli Italiani tramite più di 450 servizi online, in continuo adeguamento soprattutto normativo. Alcuni, i più recenti, sono costruiti secondo le migliori tecnologie moderne. Altri invece affondano le proprie radici su mainframe e Cobol: sistemi e tecnologie che hanno fatto la Storia dell’Informatica, ma che ormai mostrano tutti i segni del tempo.

Sia ben chiaro, questo non riguarda solo INPS e l’Italia: pubbliche amministrazioni, e anche istituti finanziari, ovunque nel mondo hanno lo stesso problema, che si è acuito pesantemente durante la pandemia. I governatori di vari stati degli USA se ne sono ben resi conto: come fai a sostenere emergenze e mettere mano a tecnologie di mezzo secolo fa, quando chi le conosceva ormai è in pensione se non deceduto?

In INPS abbiamo preso una decisione consapevole. Invece di metterci le classiche pezze e creare i cosiddetti “accrocchi”, che nulla fanno se non complicare la situazione, aumentare i costi e posticipare l’inevitabile, in INPS abbiamo deciso di affrontare la situazione di petto e aggiornare man mano sistemi e architetture. Sforzo titanico che, come si dice in America, “will pay dividends” nei prossimi anni. Allo stesso tempo, come conseguenza di questo processo di crescita, potrebbero crearsi malfunzionamenti temporanei o nuovi bug.

Collaborare con la cittadinanza: i primi risultati

40 Milioni di utenti con esigenze molte volte uniche, e più di 450 servizi digitali basati su tecnologie sia moderne che legacy. In una frase questa è la sfida quotidiana all’INPS, e non è sempre semplice affrontarla.

Allo stesso tempo, da quando lavoro in INPS mi ha colpito vedere come tante persone abbiano espresso il loro desiderio di aiutare noi (e di conseguenza, tutti gli Italiani).

Per questo, lo scorso novembre in INPS abbiamo lanciato uno strumento per recepire al meglio la loro voce e fare tesoro dei loro commenti: bugs.inps.it. Si tratta di un sito dove gli utenti possono segnalare malfunzionamenti tecnici e dare ad INPS informazioni utili per la loro risoluzione.

Uno sforzo congiunto della Struttura Tecnica per l’Innovazione Tecnologica e la Trasformazione Digitale e della Direzione Centrale Tecnologia, Informatica e Innovazione in cui, in ottica di totale apertura e trasparenza, abbiamo chiesto aiuto ai cittadini per i cittadini. La risposta è stata davvero incoraggiante. Personalmente ci tengo a ringraziare tutti quanti hanno dedicato un po’ del loro tempo per comunicarci i problemi sperimentati, specialmente se con dettagli e i cosiddetti repro steps. Un esempio è qua sotto.

Reazione su LinkedIn di un utente su bugs.inps.it

Non è retorica. È davvero di grande aiuto a noi in INPS per comprendere meglio i malfunzionamenti che, una volta sistemati, risolvono di conseguenza problemi che affliggono tante altre persone. Il commento qui sotto evidenzia molto bene questo circolo virtuoso.

Commento interno in INPS in seguito alla segnalazione di un bug.

Sia ben chiaro. Stiamo parlando di uno strumento utile ed efficace, ma non certo “rocket science” a livello tecnologico. Questo dimostra che l’innovazione si porta avanti con vari mezzi a grado diverso di sofisticazione: sia a volte usando il bazooka dell’Intelligenza Artificiale, sia altre volte (come questa) abbattendo muri tutti assieme. L’importante è sapere scegliere la soluzione giusta, evitando complessità tecnologiche inutili e focalizzandosi solo sui veri bisogni del cittadino.

Il percorso tecnico: scegliere il sistema

Un’INPS aperta al cittadino deve anche essere aperta nella sua tecnologia. Per questo sin dall’inizio abbiamo pensato a quale sistema Open Source fosse il più adatto per bugs.inps.it. D’altronde, inutile re-inventare la ruota quando ci sono già molti sistemi collaudati che possono essere usati con relativamente poco sforzo di integrazione: il risparmio in termini di tempo, qualità e denaro è evidente.

Bugzilla

Tra i molti prodotti che abbiamo valutato, la scelta iniziale è stata Bugzilla. Soluzione un po’ “vintage” e con una user experience lontana dalla sensibilità attuale, ma allo stesso tempo solida e usata come sistema di bug tracking da progetti come Eclipse e compagnie come Red Hat. Però quando si sceglie un sistema open source la sua storia lascia il passo ad altri parametri ben più importanti, in primis la sua comunità e la manutenibilità del codice.

Valutando Bugzilla, abbiamo constatato che l’ultima sua release stabile risale a 3 anni fa, e c’è scarsa attività di manutenzione del progetto. Abbiamo anche considerato la possibilità di diventare noi, come INPS, contributori attivi del progetto. Purtroppo Bugzilla è scritto in Perl: linguaggio glorioso che amavo usare quando ero sviluppatore a Yahoo! 16 anni fa. Ma ormai è anacronistico pensare di costruire futuro partendo da Perl. Abbiamo quindi abbandonato Bugzilla e valutato altre soluzioni.

Phabricator

La scelta a questo punto è caduta su Phabricator: un sistema moderno di collaborazione e sviluppo software, al cui interno c’è la componente di bug tracking a noi utile. Il sistema è stato sviluppato inizialmente da Facebook, venendo poi rilasciato in modalità open source e usato da enti come Wikimedia (la fondazione creata da Wikipedia).

Phabricator è basato su PHP: linguaggio con tanti pro e contro, la cui popolarità sta progressivamente scemando, ma comunque con una comunità ancora attiva di sviluppatori. Il 29 Maggio decidiamo quindi di usare Phabricator come base per bugs.inps.it e di partire col progetto. Sennonché, come da manuale della legge di Murphy, esattamente il giorno dopo vediamo questo tweet di Hacker News:

Il tweet di Hacker News su Phabricator

Phabricator quindi non ha più un supporto attivo di manutenzione: viene a mancare proprio la cosa più importante di un progetto open source.

Niente da fare. Siamo punto e a capo.

Entra in gioco Developers Italia

“Uniti ci ergiamo, divisi crolliamo”. È una celebre frase di uno dei padri fondatori degli Stati Uniti d’America, e ben riassume l’importanza del lavoro di squadra in questi contesti.

Uno dei problemi che ho percepito in Italia è che le organizzazioni, sia pubbliche che private, spesso tendono a fare tutto da sole senza valutare sinergie o guardare se altrove sia stato già sviluppato software a loro utile. Per questo, a prescindere dall’invito a inaugurare questo blog, ci tengo a ringraziare Developers Italia: il suo ruolo è stato determinante per il successo tecnico di questo progetto.

Come prima cosa, abbiamo valutato assieme a loro il Catalogo del software open source a disposizione della Pubblica Amministrazione. Purtroppo non abbiamo trovato nulla che soddisfacesse i nostri requisiti e che fosse comunque semplice da customizzare. Su consiglio di Developers Italia abbiamo quindi valutato un progetto esterno di una startup spagnola, sempre comunque disponibile in modalità open source: Taiga.

Taiga

Così come Phabricator, Taiga consiste in una suite di servizi di collaborazione e sviluppo software, tra cui il bug tracking. Semplice da usare e scritto in un linguaggio e framework moderno come Python 3 e Django. Ci tengo sempre a rimarcare l’importanza della tecnologia sottostante: è il motore sotto il cofano di una macchina; non si vede, ma l’impatto di una scelta giusta si percepisce immediatamente e diventa determinante nelle evoluzioni future. Nel nostro caso, avevamo bisogno di customizzare Taiga introducendo nuove funzionalità specifiche ai bisogni INPS. Ce ne sono state varie, ma qui ne cito due in particolare:

  1. Visibilità pubblica opzionale
  2. Login tramite SPID
Visibilità pubblica opzionale

La prima customizzazione (“visibilità pubblica opzionale”) è fondamentale se pensiamo che il cittadino sta segnalando un bug, e potrebbe inserire informazioni personali nei repro steps o negli allegati con dati sensibili. Per questo, a differenza del Bugzilla di Red Hat dove tutto è pubblico, qui abbiamo introdotto il concetto di ruoli e di visibilità pubblica opzionale, con default privato: in questo modo nessun altro utente (a parte chi ha ruolo di operatore di servizio) può vedere il bug. Questa funzionalità è piaciuta così tanto anche al team di Taiga che, in pieno spirito collaborativo e open source, ha deciso di integrarla nei propri prossimi rilasci. Un win-win per tutti.

Login tramite SPID

La seconda customizzazione rilevante riguarda l’integrazione SPID per il login. Oltre ad essere sempre più spinto dalle nuove norme per standardizzare l’interazione cittadino – Pubblica Amministrazione, il login tramite SPID risolve anche alla radice il grande problema dello spam che affligge i sistemi con username/password generati da qualsiasi utente. Un esempio di questo problema, non ancora risolto, lo evidenzia bene Eclipse in questo thread su Bugzilla.

Nel nostro caso invece, l’apertura a tecnologie web moderne e diffuse ci ha semplificato il compito, spalancandoci altre porte. Infatti, abbiamo potuto riutilizzare il codice già pronto e sviluppato da Developers Italia: la Django app per integrazione SPID con SAML2. L’apoteosi del DRY (Don’t Repeat Yourself) & KISS (Keep It Simple, Stupid) nella vera pratica, e per di più tra enti pubblici. Un qualcosa di cui andiamo davvero orgogliosi.

E sulle ali dell’entusiasmo ci siamo permessi qualche licenza “poetica” sugli errori 404 e 401: piccole cose da nerd, che siamo contenti siano state apprezzate dalla comunità tecnica.

Commento su LinkedIn di un utente sulle pagine di errore di bugs.inps.it.

Considerazioni finali

Cosa serve per accedere a bugs.inps.it? Non c’è bisogno di alcuna registrazione. Solamente SPID. Il sito è utilizzabile da mobile, consente visibilità pubblica/privata, e mostra gli avanzamenti di stato della segnalazione tecnica. Il tutto gira su public cloud Azure su macchina Debian 11, ed è scritto in Python 3 con framework Django.

In tema di totale trasparenza, crediamo nell’asserzione “soldi pubblici = codice pubblico”. Per di più, essendo bugs.inps.it basato sul progetto Open Source Taiga, ovviamente il codice è pubblico e consultabile alla pagina GitHub di INPS. Commenti e suggerimenti sono benvenuti. Questa è infine la prima attuazione di “Sirio”, il Design System INPS. Infatti, oltre a questo sito, stiamo lavorando attivamente per fornire una esperienza d’uso piacevole e coerente attraverso tutti i servizi INPS. Cos’altro aggiungere? È stata una bellissima collaborazione tra INPS, Developers Italia (iniziativa del Dipartimento per la trasformazione digitale e Agenzia per l'Italia Digitale) e Taiga (progetto di una startup spagnola), con l’implementazione di AlmavivA.

Pubblica Amministrazione, enti del Governo, startup, privato: tutto al servizio del cittadino.

Il mio augurio personale è che questo sia solo il primo di una lunga serie di esempi che facciano comprendere che sì, in Italia si può costruire tecnologia moderna e utile. E soprattutto che la collaborazione tra enti, per quanto diversi tra loro, è la chiave determinante per questo successo.

Vincenzo Di Nicola, INPS – Responsabile della Struttura Tecnica per l'Innovazione Tecnologica e la Trasformazione Digitale

Vuoi segnalare un bug in un servizio INPS? Vai su https://bugs.inps.it e contribuisci.

Questo articolo è pubblicato anche sul Medium di Developers Italia

Questo blog è redatto da Developers Italia