Categoria: Approfondimenti

Alcune riflessioni sulla digitalizzazione della PA

Per lavoro, mi occupo molto di digitalizzazione di processi “cartacei”, e mi trovo quindi, in Italia, a lavorare anche per la Pubblica Amministrazione, che è nel pieno di un processo veramente enorme di ricostruzione – e talvolta costruzione – dei sistemi informativi e dei processi digitali.

È un processo che sarà ancora piuttosto lungo, e più per le sue dimensioni veramente gigantesche – pochi di quelli con cui mi trovo a parlarne ne hanno idea -, che per le inefficienze e la resistenza al cambiamento, aspetti che comunque esistono.

Il Presidente del Consiglio in carica, Mario Draghi, presentando alla Camera dei Deputati il Piano Nazionale di Ripresa e Resilienza, ovvero il programma di investimenti nei quali sarà spesa la grande quantità di soldi in arrivo dall’Unione Europea per la ripresa dal COVID-19, ha parlato con una certa enfasi di come una parte di questi fondi andranno proprio alla digitalizzazione della Pubblica Amministrazione.

Da persona che ci lavora “da fuori”, volevo tirare giù qualche nota e riflessione su come le cose mi sembra vadano, e su come secondo me dovrebbero andare.

La cosa ovvia: le resistenze

I processi burocratici in Italia sono delle collezioni articolate di liturgie. Cose che a volte non hanno più neanche troppo senso, e che rimangono o per tradizione, o perché nessuno ha voglia di immaginare di meglio, o per sostenere enti e aziende che altrimenti non avrebbero motivo di esistere.

L’esempio principe di questo aspetto trovo siano le marche da bollo. Uno strumento nato per pagare comodamente le tasse sulla gestione dei documenti, ma che oggi a meno di complicarsi la vita con procedure molto contorte impone di stampare documenti e applicarci un bollino adesivo. Bollino che, peraltro, è la versione moderna, denominata addirittura “marca da bollo elettronica”.

Le resistenze sono tante, complesse e talvolta molto onerose. È però quel tipo di complessità che rende difficile la semplificazione: si tratta spesso di equilibri di cose aggrovigliate in cui si fatica a rimuovere qualcosa senza romperne altre dieci che magari andavano grossomodo bene.

Pian piano, però, queste resistenze stanno venendo demolite. E a volte sono state demolite quando chi è del settore neanche se lo aspettava troppo. Avreste detto qualche anno fa che Poste si sarebbe vista ridimensionare l’enorme affare dei bollettini? Oggi abbiamo PagoPA.

Insomma, questo aspetto molto ovvio della faccenda mi preoccupa poco: piano piano lo si tira giù.

La cosa ovvia ma meno: la concorrenza

Alcune esigenze di miglioramento sono proprie di ogni settore dell’apparato pubblico. I settori però sono veramente tantissimi. Alcuni sono davvero molto squattrinati, e difficilmente porteranno avanti grandi riforme. Altri, invece, stanno benone e hanno sia il know-how che le risorse economiche per innovare. E non sono pochissimi.

Questi settori “innovatori” dell’amministrazione, però, non hanno un reale sistema di coordinamento. Lavorano spesso in concorrenza, talvolta senza saperlo e talvolta sapendolo ma cercando di portare avanti il sistema più comodo per loro.

Questa concorrenza, volontaria o meno, genera sistemi paralleli e parzialmente incompatibili, ognuno coi suoi punti di forza e punti deboli, confondendo il cittadino e dando un aspetto eccessivamente complicato ai servizi pubblici digitali. Il cittadino – e no, non solo gli anziani – finisce per preferire il caro vecchio sportello all’arrabbattarsi tra mille cose tutte simili senza la chiarezza di cosa serva.

È per questo, ad esempio, che abbiamo due sistemi paralleli di accesso ai servizi pubblici. SPID ha l’enorme svantaggio di essere in mano privata e di essere abbastanza convoluto e il vantaggio di essere universalmente disponibile a chiunque voglia averli. CIE è in mano pubblica ed è di semplicissimo utilizzo, ma è legato al rinnovo DECENNALE della carta di identità. Decennale, gente. Decennale.

In parte, ma le cose sono un po’ più complicate e richiedono di replicare su scala europea e mondiale lo stesso problema, è anche il motivo per cui molti di noi hanno due documenti palesemente trasformabili in uno (carta di identità e codice fiscale) e un terzo che sarebbe integrabile sempre nello stesso se non fosse per l’amore per i timbri che molti Paesi hanno (il passaporto).

Si è fatto un tentativo, sotto il governo di Matteo Renzi, per avere un coordinamento, che si è concretizzato nell’istituzione dell’AGID. Il problema è che, già dall’inizio, l’AGID è palesemente una struttura piena di ottime teste ma terribilmente sottofinanziata e a corto del personale necessario. Non ho dati per dirlo, ma è molto evidente dai fatti.

L’elefante nella stanza: l’integrazione

Arriviamo al punto secondo me abnorme ma di cui nessuno parla e su cui nessuno mi sembra stare pensando di investire.

La PA, come dicevo, è una cosa gigantesca. Ma gigantesca tanto.

I moltissimi settori che la compongono, dal più grande ministero al più piccolo albo professionale al commissariato di polizia di un comune in procinto di essere fuso ad altri otto ha la costante necessità di comunicare con gli altri.

Nella storia, questa cosa è stata fatta in molti modi diversi che sono l’evoluzione dello stesso modo del tutto analogico. Messi, fax, PEC. Messaggi tra persone.

Il risultato è che lo Stato, nel suo insieme, ha una quantità rilevante e potenzialmente molto comoda di informazioni su ogni cittadino, ma che messe assieme sono l’assenza di informazione. Enti diversi sanno cose diverse sullo stesso cittadino, potenzialmente in contrasto. Di una persona un ente può avere un codice fiscale, un ente un altro perché è cambiato e non lo sa, un altro ente non ne ha alcuno ma ha l’indirizzo di residenza, un altro sa che gli è scaduto il permesso di soggiorno.

Tutto dipende da chi ha comunicato cosa a chi, e da se lo ha fatto.

Un casino allucinante, che in parte si sta lentamente risolvendo con l’ANPR, il sistema anagrafico nazionale, ma in parte è completamente irrisolvibile nel medio termine.

Ancora peggiore è la situazione di specifici settori. Quasi ogni cittadino, può ad esempio aprire presso il sistema sanitario della propria regione un “fascicolo sanitario elettronico”, dove può recuperare alcuni referti e ricette mediche e dove può caricare cose da rendere disponibili al proprio medico o ai medici pubblici in generale. Tale sistema è quasi sempre regionale, e SEMPRE non contiene tutto. Un medico pubblico che non è il mio medico di medicina generale mi dà una ricetta? Non finisce sul mio fascicolo. Un istituto privato mi fa il tampone per conto del sistema pubblico? Non è detto che il risultato vada sul fascicolo. Mi sento male in un altra regione? Il pronto soccorso non ha accesso al fascicolo. Mi sento male in Germania? Auguri.

Se si vuole risolvere questa situazione, bisogna elaborare – possibilmente a livello europeo – degli standard pubblici di interoperabilità che non si fondino su persone che dicono cose ad altre persone, sia pure per posta elettronica financo certificata.

È una cosa molto più semplice a dirsi che a farsi, ovviamente. Richiede prima di tutto il cercare di capire cosa esiste e cosa serva, e già questo è un lavoro che richiede grandi investimenti e molto tempo, sicuramente di più di quello che si è investito sull’app IO, che mi pareva voler coprire alcuni – pochissimi – aspetti della faccenda.

Poi va stabilita un’architettura, con la grandissime difficoltà di dover stabilire, per ogni aspetto, chi detiene i dati. Per certe cose è già ampiamente stabilito: i dati anagrafici sono mantenuti dall’ANPR, ad esempio e prima erano mantenuti dai comuni. Su altre cose, come ad esempio i dati sanitari, le cose si complicano. Alcuni dati, tra l’altro, come quelli sanitari o come le cartelle esattoriali, richiedono particolari attenzioni.

Se non si inizia, però, non si fa. E trovo sia veramente necessaria una volontà politica condivisa, su questo. O ci troveremo alla prossima pandemia a dover andare ancora a comprare una marca da bollo e appiccicarla su un foglio stampato in cui richiediamo un certificato, per poi inviare il foglio via PEC all’albo professionale di appartenenza.

Se ve lo steste chiedendo, sì, è l’attuale procedura.

Giuro.

E il certificato va stampato per appiccicare un’altra marca da bollo.

Ultimo ma non irrilevante: privato e pubblico

Io sono fermamente convinto che si debba evitare per quanto possibile di dare infrastrutture e dati ai privati, fossero pure di proprietà pubblica (non ho mai capito lo status di PagoPA, ad esempio, che di dati ne ha tanti).

La progettazione e lo sviluppo, però, difficilmente potranno essere pubblici. Sebbene sia bello immaginare una bella azienda di ingegneria statale che possa prendere in mano l’innovazione della PA, è un sogno impossibile. Sogno peraltro più volte tentato, dal Sogei in poi, ma mai davvero riuscito.

Il motivo è semplice: il know-how costa e lo Stato difficilmente può giustificarne, politicamente ma anche finanziariamente, i costi. Una struttura in grado di fare una cosa del genere, con personale e dirigenti competenti, può potenzialmente avere costi di diversi ordini di grandezza superiori a quelli che lo Stato può pagare.

Nella necessità di dover appaltare l’innovazione, bisogna quindi mantenere l’attenzione necessaria a non appaltare più di quello che è impossibile non appaltare. Cose come SPID, molto in balia dei privati che talvolta lo offrono best-effort senza alcuna responsabilità sui malfunzionamenti vanno ad esempio evitate.

Conclusioni

Spero di essere stato un po’ ordinato e comprensibile nel mio esporre le cose. Ne dubito, perché sto scrivendo e mi sto rileggendo di notte, ma nel caso ditemi nei commenti nel subreddit.

Spero in una discussione che vada un po’ oltre il “boh pubblico merda”, perché onestamente credo che il pubblico non meriti tutti questi lanci di pomodori. È una macchina complessa, antica, delicata da toccare e che ha una serie di interessi e inefficienze talvolta più articolate di quello che sembra. Diciamo che ho visto privati gestire molto peggio cose molto molto più semplici, forti del loro vivere di rendita o – peggio – del loro vivere sottraendo risorse al pubblico che non può permettersi di dargli il benservito.

Libmodule: libreria C per creare progetti modulari

Ciao a tutti! Sono u/nierro. Forse vi ricorderete di quando vi raccontai di un mio progetto proprio qui: https://tldr.italyinformatica.org/2017/05/clight-demone-utente-per-linux/.

Bene, libmodule nasce come “spin-off” di quel progetto: il codice di clight è molto modulare, e ha al suo interno tutta una serie di accorgimenti per gestire questi “moduli”.

Circa un mesetto fa mi resi conto che da un lato per clight questa gestione dei moduli era over-engineered, e dall’altro mi tornava utile in tanti progetti, personali e lavorativi.

Decisi quindi di mettermi al lavoro per creare una libreria come si deve, con lo scopo ultimo che dovesse essere semplice ed elegante.

Nasce così libmodule.

Cos’è libmodule?

È una libreria C, che ad oggi supporta linux, osx e BSD (tornerò su questo punto più in là), per scrivere progetti modulari e standardizzati.

L’approccio è piuttosto simile all’OOP; in particolare mi sono fortemente ispirato ad akka (https://akka.io/) e più in generale all’Actor Model per l’API.

Cos’è un modulo?

Un modulo è, manco a dirlo, l’entità chiave di libmodule; ogni modulo espone determinate callback che verranno usate per gestire il suo ciclo di vita.

Un modulo può inoltre reagire agli eventi, mettendosi in ascolto su dei File Descriptor.

Libmodule offre poi un loop interno che automaticamente ascolta su tutti gli eventi di tutti i moduli chiamando le callback corrette per ciascuno.

Supporta il mio OS?

Libmodule usa, per il suo loop interno, una struttura a compile-time-plugins; dipendentemente dalla piattaforma su cui viene compilato, seleziona il plugin corretto per implementare l’interfaccia di poll.
Ad oggi supporta epoll() su linux, e kqueue() su osx e bsd.

Lo svantaggio è che questi “plugins” dovranno avere una interfaccia simile a epoll.

Questa è una scelta specifica: l’ovvia soluzione portabile sarebbe stata usare poll(); trovo però l’API di kqueue/epoll molto più elegante e flessibile.

Esiste della documentazione?
Ovviamente: una libreria è completamente inutile se non esiste della documentazione.

La si può trovare qui: http://libmodule.readthedocs.io/en/latest/?badge=latest.

Tutto bello..ora però tira fuori il codice!

Mi sembra corretto ricompensare quei pochi coraggiosi giunti fin qui mostrando loro un breve esempio.


#include <module/modules.h>
#include <module/module.h>
#include 

MODULE("Test");

static void module_pre_start(void) {

}

static void init(void) {
     m_add_fd(STDIN_FILENO);
}

static int check(void) {
     return 1;
}

static int evaluate(void) {
     return 1;
}

static void receive (const msg_t *msg; const void *userdata) {
     if (!msg->msg) {
          char c;
          read(msg->fd,&c,sizeof(char));
               if (c=='q'){
               modules_quit();
          }
     }
}

int main () {
     modules_loop();
     return 0;
}

Per compilare, è sufficiente linkare libmodule tramite il linker flag “-lmodule” o usando lo script pkg-config installato.

Questo semplice programma crea un modulo, che si chiamerà “Test”, che ascolta su stdin.

Alla pressione di ‘q’, il programma uscirà.

Ben più utile, al fine di capire come funziona la libreria, è l’output generato (libreria compilata in debug, che la rende verbosa):

./sample.out Libmodule: Initializing libmodule 1.0.0. Libmodule: Creating context ‘default’. Libmodule: Registering module ‘Test’. a b c q Libmodule: Deregistering module ‘Test’. Libmodule: Destroying context ‘default’. Libmodule: Destroying libmodule.

 

Da qui appare ben chiaro lo scopo della macro MODULE(): registra un modulo in libmodule automaticamente all’avvio del programma, proprio come un ctor.

Il modulo viene poi de-registrato automaticamente da un dtor implicito.

Non mi dilungo su cosa sia un context, nella documentazione è ben spiegato.

Dall’esempio si possono evincere le caratteristiche principali di libmodule:

* Modularità (ovviamente)

* Semplicità

* Compattezza

Idealmente, ogni modulo costituisce un sorgente separato annotato dalla macro MODULE (anche se questa regola può essere aggirata utilizzando la “complex API”, che poi non è altro che l’API usata internamente dalla macro); forzando di fatto una standardizzazione del proprio progetto.

Hai citato gli actor, non vedo nulla però…

I moduli possono anche dialogare tra loro con un sistema PubSub: possono quindi inviare un messaggio a un altro modulo, o pubblicarlo su un “topic” che verrà ricevuto da tutti i moduli sottoscritti al suddetto topic.

Last, but not least (aka “la roba pallosa”)

Al momento mi sto concentrando sulla scrittura di unit test prima di rilasciare la prima versione stabile. Si noti che i test sono eseguiti automaticamente tramite travis sia su linux che su osx; inoltre su linux sono anche testati per la ricerca di memleak con valgrind.

L’API è in freeze in attesa della release; non ho comunque in mente alcun api break nel breve periodo.

Qualora per sbaglio dovessi aver stimolato il vostro interesse o la vostra curiosità, vi invito a farvi un giro al repo github: https://github.com/FedeDP/libmodule 🙂

La Forza Kinectica

Il sensore Kinect è ben famoso nella community videoludica, infatti era principalmente indirizzato ai giocatori quando Microsoft lo ha creato. La prima versione del dispositivo era per la console Xbox 360 e col suo sensore 3D ha introdotto un nuovo modo di giocare, cioè usare l’intero corpo o almeno le braccia dell’utente. Può facilmente tracciare l’intero corpo umano e dare in output una collezione completa di informazioni sulle posizioni e sui movimenti di ogni articolazione. Nella figura seguente si può vedere a cosa mi riferisco con articolazione, sono i ”Joints” che formano lo ”Skeleton” di un utente.

(altro…)

Alla scoperta di D: un completo linguaggio di programmazione

Negli ultimi anni abbiamo assistito all’ascesa di un gran numero di linguaggi di programmazione, in particolare [Go](2009), [Rust](2010), [Kotlin] (2011), [Elixir](2011), [Crystal] (2014), [Pony](2014).
Questa esplosione di nuovi linguaggi è dovuta, fra le molte motivazioni, alla necessità di adottare paradigmi di programmazione non immediatamente recenti come cittadini di primo tipo.
(altro…)

I testi generati ovvero le catene di Markov

Per chi non mi conoscesse, sono /u/timendum , il creatore di /u/italy_SS , cioè il /r/SubredditSimulator per i contenuti in Italiano.

In questo articolo cercherò di spiegarvi il meccanismo dietro la generazione di testi casuali usati in questi due subreddit.

(altro…)

Crackare password? Facciamolo!

Questo articolo sarà un po’ diverso dagli altri: oltre a parlarvi dell’argomento (Crackare password n.d.r.), voglio proporvi una piccola sfida.

Sappiamo che le password devono essere lunghe, devono essere complesse e solo una di queste due proprietà non basta: avere la stessa password per ogni sito web, sappiamo, non è cosa giusta. Tutte queste accortezze per cosa? Per non farsi rubare le password ovviamente: ma se volessi provarci? Vi è mai capitato di crackare password?

(altro…)

Entrare nella community di Envato? Difficile ma si può!

Envato, con oltre 1 milione di utenti, è sicuramente uno dei più grandi market mondiali per quanto riguarda la vendita di contenuti multimediali quali temi per ogni cms, plugins, addons, audio, video, app totalmente modificabili dall’utente finale se acquistati. In envato troviamo themeforest, videohive, graphicriver, audiojungle, 3docean, photodune, codecanyon. Se vuoi guadagnare qualcosa dal tuo codice, Envato è quello che fa per te (o quasi). In questo articolo vorrei raccontare la mia breve esperienza su cosa e come ho fatto per farmi accettare un plugin WooCommerce in Envato.

(altro…)

Diritto alla riparazione: informazioni e consigli utili

Ci troviamo in un’epoca in cui il concetto di proprietà di un oggetto sta cambiando, in alcuni aspetti in maniera subdola e che non ci aspetteremmo: il “diritto alla riparazione” dei nostri dispositivi.
Siamo oggi circondati da telefoni, tablet, indossabili, portatili che ogni giorno diventano più sofisticati, compatti, costosi e delicati.
Quando acquistiamo uno di questi, la facilità o, al contrario, l’impossibilità di poter intervenire sugli elementi che li compongono per ripararli o migliorarli sono fattori che difficilmente consideriamo, ma a cui da consumatori dovremmo fare più attenzione, per diversi motivi.

(altro…)

Anti-DDoS Amazon Web Services Infrastructure

Con oltre un milione di clienti in 190 paesi, Amazon Web service è sicuramente una delle collezioni di servizi di cloud hosting più utilizzate. Nei clienti, troviamo aziende protagoniste nel mondo dell’informatica come Adobe, Vodafone e molte altre. “ Da grandi poteri derivano grandi responsabilità”, stessa frase vale se si offrono servizi che devono stare online 24 h su 24.

(altro…)