Per chi non mi conoscesse, sono un ingegnere software con 20 anni di esperienza client/server/sicurezza che ha lavorato anche in California per aziende del calibro di Twitter e Facebook.

Che cosa è una variabile?

In programmazione, si assegnano dei valori generici a delle variabili tutto il tempo, così da poter poi riutilizzare, ogni volta che serve, tali valori.

var utente = {nome: "Andrea", cognome: "Giammarchi"}; // esempio:

// stampa nome utente (print = console.log)

print(utente.nome);

In qualunque corso di informatica base, i nomi delle variabili, come i nomi delle loro proprietà, in questo esempio nome e cognome , devono sempre essere facilmente riconoscibili e per una miriade di ragioni valide, inclusi possibili errori, dove leggere “errore blahBlahBlah” non aiuterebbe nessuno.

In passato …

Prima del 2007, anni in cui ho deciso di fuggire dal bel paese e senza aver mai avuto, da un punto di vista professionale, alcun rimorso sulla scelta fatta, ho anche collaborato con la pubblica amministrazione.

Uno degli incontri più raccapriccianti che abbia fatto prima di espatriare, è stato quello con uno dei responsabili manutenzione del CMS regionale, un software per gestire informazioni, dati, e messaggi all’interno dell’azienda.

Sono bastati letteralmente 5 minuti per capire che l’ingegnere software con cui avrei dovuto collaborare o, data la sua posizione da responsabile, imparare qualcosa, non avesse le più basilari competenze in materia Web: non solo aveva scelto un CMS già fatto e tutto, spiegandomi di non averlo mai toccato lato server, ma non aveva nemmeno idea di cosa fosse JavaScript, spiegandomi che il mio aiuto, come programmatore, sarebbe stato quello di aggiungere, testuali parole, “solo qualche script Java” nella pagina, indicandomi codice presente tra <script> e </script> in una delle pagine del portale, tendendo a sminuire il mio operato, quasi come fosse un favore farmi collaborare.

Confondere due linguaggi di programmazione completamente diversi, quali sono Java e JavaScript, è comune, se non sei di settore, ma è anche qualcosa che si impara durante “il primo giorno di scuola” in materia sviluppo Web.

“Una sciocchezza”, direte voi, “un errore comune, che sarà mai?”, penseranno altri, ma questi dettagli, queste minuzie, sono solo la punta di un gigantesco iceberg di incompetenza che troppo spesso rappresenta la qualità software della Pubblica Amministrazione.

var pippo

A quanto pare, il sito dell’INPS è costato complessivamente attorno ai 200 milioni di euro, e richiede, come tutto il software, aggiornamenti e manutenzione.

Ora vediamo come le aziende software serie sviluppano i loro prodotti:

c’è un problema da risolvere, o una nuova funzionalità da implementare;

uno sviluppatore scrive il codice per risolvere il problema, assicurandosi di non crearne di nuovi, tramite test di regressione, ma anche assicurandosi che il bug sia risolto, o la nuova feature funzioni correttamente;

a questo punto almeno un collega, di pari o superiori competenze, se non il responsabile del progetto stesso, analizza il nuovo codice e, solitamente, richiede cambiamenti allo stesso, finché non ci sia un OK per far si che il cambiamento possa essere applicato al prodotto finale;

per concludere, un team di Quality Assurance (QA) darà l’OK finale prima di fare una nuova release del prodotto software, che sia questo un portale Web, una App, o lo stesso Sistema Operativo;

Non ci sono “seee, vabbè …” in questo processo: se hai a carico la responsabilità dei dati sensibili di un paese, ed un fondo da milioni di euro, e punti ad offrire un prodotto serio, affidabile, sicuro, non puoi assolutamente saltare alcuno dei 4 passaggi elencati qui sopra.

Chi ha fatto la revisione codice del portale INPS?

Immagino nessuno. L’insieme dell’accozzaglia organizzata male di codice servito dal portale dell’INPS, contiene errori madornali, stili diversi, variabili scritte o scelte a caso, persino di dubbia utilità o logica, leaks di memoria, etc.

Sembra la fiera del copia e incolla del Far West, dove il cowboy di turno spara a caso sulla tastiera tutte le peggiori pratiche di programmazione.

Nessun team che prende il lavoro seriamente farebbe arrivare in produzione variabili chiamate pippo , come nessun professionista scriverebbe codice come quello presente nella maggior parte dei file serviti ad ogni utente.

Chi sta facendo QA nel portale INPS?

Immagino sia sempre lui: nessuno! Il sito INPS non è stato fatto revisionare da alcun esperto Web, e queste sono solo alcune ovvietà che lo dimostrano:

nessun test di penetrazione o carico sito effettuato, e non credo serva commentare oltre;

tutto il codice viene servito senza essere minificato, una procedura che qualunque professionista di settore conosce, un’operazione banale che si fa in pre-produzione per garantire che il codice scaricato da ogni utente sia compresso il più possibile (meno banda usata, ergo più utenti gestibili);

ogni variabile o funzione è globale, con rischio di conflitti tra variabili. Non utilizzano moduli, non c’è un bundle, ergo non c’è alcuna release software, si cambia qui e la quando serve, tipo il file app.js , dove la versione viene passata tramite una query string tipo ?v=201911281536 , dove le query strings sono piu pesanti da gestire per il server, mentre un file statico da CDN chiamato app.201911281536.js a cui puntare avrebbe già alleggerito il carico;

, dove la versione viene passata tramite una query string tipo , dove le query strings sono piu pesanti da gestire per il server, mentre un file statico da CDN chiamato a cui puntare avrebbe già alleggerito il carico; ci sono un’infinità di scripts Facebook, che non servono a far funzionare il sito. Alcuni scripts vengono persino bloccati dagli Ad blockers perché considerati insicuri per l’utente;

Il Web nel 2020

Esistono tantissimi programmi gratuiti per ottimizzare siti Internet, ma in Italia molti ancora non sanno nemmeno cosa significhi.

Questo esempio mostra come dimezzare il peso di app.js , file principale, con le tecniche più banali, utilizzate da sempre … ma non in Italia:

# peso attuale, in bytes, inclusa compressione

cat app.js | gzip | wc -c

# 26928 bytes # peso utilizzando uglifyjs + gzip

cat app.js | uglifyjs -c -m | gzip | wc -c

# 18436 bytes # peso utilizzando uno scope privato (tipo modulo)

echo "(function(){$(cat app.js)}());" | uglifyjs -c -m | gzip | wc -c

# 12951 bytes

Ecco qua: 52% di banda in meno per utente. Invece di schiaffare tutto globale, ho inserito il file principale in uno scope, permettendo al codice di essere piu sicuro, meno prone a conflitti nomi globali, e minificato anche meglio, ottenendo meno della metà delle dimensioni per utente, il tutto considerando solo un file … e invece, questo lo stato attuale del sito (punteggio da 0 a 100):

Nessuno, fuori dall’Italia, assembla più risorse siti in questo modo, ma alla nostra PA mancano le basi sul come si sviluppi un sito, nonostante i milioni di euro spesi, cifre che professionisti seri si sognano, cifre che fanno solo rabbia, soprattutto considerando i risultati.

WebPack, Parcel, solo un paio dei tantissimi tools capaci di fare tutto in automatico; andate a studiare come usarli questi tools, che Google, Facebook, e tante altre aziende, lo fanno da una vita.

“Aumentiamo la cache!”

Il sito dell’INPS si basa, specialmente in questi giorni, di invio dati e dati dinamici. L’invio dati si fa tramite POST, un’operazione che non ammette cache in invio dati.

Se un sito è tempestato di formulari da compilare, aumentare la cache in lettura è una mossa utile solo a sovraccaricare di più il server, ma ciò nonostante, qualcuno deve spiegarmi come mai pagine di altri utenti venivano visualizzate altrove a prescindere da questa fantomatica cache.

Una cache di sessione non dovrebbe mai materializzarsi altrove, sono le basi delle sessioni. Dal risultato sembra quasi qualcuno abbia puntato il load-balancer all’ultima pagina creata di successo, servendola come statica.

Che poi, a pensarci bene, un load-balancer avrebbe semplicemente reindirizzato utenti in eccesso in una pagina statica con scritto “ci scusiamo, troppa gente, riprovate”, ma chissà se lo hanno un load-balancer la.

Ci sono anche modi in database per ottimizzare cache, ma le query si devono fare lo stesso, non si servono pagine a caso ad utenti a caso: vergogna.

Se il problema è stato invece software, era chiedervi troppo di aggiornare il vostro software prima di richiamare milioni di Italiani sul vostro sito?

Aggiornamento

A quanto pare il load-balancer era stato previsto, tramite l’utilizzo dei server Azure di Microsoft, peccato non siano stati in grado di configurarlo.

Le 100 Richieste al secondo

Mentre girano meme sui “server di porn-hub” per aiutare l’INPS, un Raspberry Pi vecchio di 6 anni, ne gestisce dalle 50 alle 400 di richieste al secondo, e costa 30 euro, mentre un database come Redis gestisce minimo 70000 richieste al secondo, solo per fare un esempio, quindi fatemi un favore: state zitti, che fate più bella figura, grazie.

Un insulto alla categoria

In Italia ci sono persone che continuano a non fidarsi della tecnologia perché convinte non funzioni mai. Cambiate paese e scoprirete che sistemi complessi informatici, soprattutto molto costosi, esistono e funzionano da sempre, ed i governi sfruttano bene questi sistemi per semplificare la vita dei cittadini, o del loro stesso iter burocratico.

Non devi essere Google o Microsoft per scrivere software che funziona, devi banalmente avere basi di programmazione degne di tale nome ed esperienza.

Se prendi il tuo lavoro come uno scherzo, tipo “ahahah, ho scritto var pippo sul sito INPS!”, devi smetterla di essere pagato e trovarti un altro lavoro.

Per concludere