Bene e benvenuti su GIT BAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori io non sono sicuro stia registrando fatemi controllare poco spazio sul disco ah che bello, ah che bello no problem, quindi potremmo perdere la mia traccia ma io ho sempre una seconda traccia, va beh pazienza detto questo io saluto intanto i compari che mi accompagneranno in questa passeggiata verso l'ignotto visto che dell'argomento io ne so tipo zero mi sembra di essere non so se avete visto il meme di Grignani a Sanremo che prova ad argomentare qualcosa e non è in grado di mettere due parole insieme ecco io sono...

ma non era un meme? è così dire il meme ah non era un meme? va beh ma Grignani è un meme io mi sento un po' come Grignani stasera quindi praticamente non dirò due parole insieme di senso compiuto e come potete vedere ci sono già iniziato ma questo è poco male perché ho con me un nutrito numero di compari che mi faranno da insegnante di sostegno in questo percorso all'apprendimento di un topic completamente nuovo ho con me infatti Mattia eeeeh a volte ritorno, non era un po' che non venivo qui nel bar e mi mancavate e quindi ho pensato bene di venire in una puntata su un argomento di cui non so niente e così almeno lo imparo Carmine buonasera io sono qui stasera a parlare di una cosa di cui ho detto di saperne qualcosa vediamo che cosa ne esce fantastico ma abbiamo con noi anche un esperto giusto? abbiamo con noi David massimo esperto del topic di oggi mi piace perché le presentazioni sono sempre poco imbarazzanti per me poche aspettative massimo esperto no no mondiale e infatti vorrei che Carmine ti presenti Carmine non se l'aspettava questa cosa si può fare, l'abbiamo fatto anche la vostra scorsa ho avuto il piacere di parlare con lui, un amico, un fratello, un grande professionista, il signore dello storage e della mobilità sempre rimango basito ogni volta, continuo a non capire e intanto però Carmine ha già accennato il topic di oggi oggi parliamo di smart cities benvenuti su GITBAR il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo GITBAR sembra di essere a 2024 di radio 24 ma io non sono altrettanto bravo come giornalista e quindi direi che la prima domanda che io vi faccio è cosa sono le smart cities? è una buzz word per spillare soldi pubblici o uno strumento che ha senso in un'era digitale? premesso che le due cose non si escludono no, smart cities sono una cosa vera perché abbiamo tanti dati, generiamo tanti dati anche involontariamente sempre, quando ci spostiamo, quando acquistiamo cose, quando socializziamo e questi dati se usati nel modo corretto ci possono aiutare e possono aiutare le città a migliorarsi, a prendere delle decisioni anche identificare dei comportamenti, insomma diverse cose o anche cose molto più banali, cioè tipo non avere i cassonetti pieni ma dovendo fare un esempio quali sono i tipi di dati che possiamo raccogliere all'interno di una città? oltre ai classici semafori e al traffico? beh già avere dei dati di traffico comunque buoni non sarebbe male poi magari ci ritorniamo su esatto, in realtà questa cosa più spesso viene fatta come esempio in realtà è una delle cose più complesse da fare cioè nel senso alla fine credo che li possiamo dividere in quei dati che puoi prendere con l'infrastruttura che c'è già e i dati che puoi prendere con l'infrastruttura che non c'è ad esempio quella del traffico in realtà è molto più complessa di come ciò che si immagina perché spesso magari ci sono delle persone che sono convinte ma io ho la telecamera, se ho la telecamera so automaticamente se c'è traffico o meno ovviamente quella è una valutazione qualitativa che fa l'uomo nel senso vede dalla telecamera che c'è traffico e quindi c'è traffico riuscire a tradurre quell'immagine di traffico effettivamente in un dato è tutta quanto un'altra storia diciamo che come dicevi tu prima il confine tra buzzword e quello che si può fare è labile sicuramente è qualcosa che è giusto fare e andrà fatta sempre di più con il corso degli anni però ecco va effettivamente modulata è interessante anche l'aspetto topografico di questa montana così perché effettivamente siamo in quattro punti d'Europa insomma diversi io sono giù David è in mezzo Mattia è nella città più bella d'Italia e invece Mauro è direttamente fuori nella città più bella di Francia quindi secondo me sarà anche interessante confrontarsi su questa parte perché se pensiamo alla smart city in generale possiamo partire dal sito che ti fa provocare la Silonido quindi che quello effettivamente è un servizio fino all'applicazione che dice il tuo cassonetto è pieno vai in un altro cassonetto o lì c'è il parcheggio alla fine chi ha la fortuna di vivere in un posto dove alcuni servizi sono già digitalizzati ha cominciato già un po' ad assaporare questo flavor insomma di questa cosa qui e questa è la mia prima domanda per tutti voi secondo voi le città in cui vivete sono almeno un pizzico smart? Comincio dicendo che niente proprio siamo una cosa più lontana, credo ci siamo stati buttati milioni in questa cosa finora ma credo...

vabbè no comunque Io che vivo nella città più bella d'Italia come hai giustamente detto soprattutto a livello di clima e di socievolezza delle persone ho visto una volta un cassonetto che si dichiarava smart che aveva il coso che notificava i tizi dell'hamsa per dirgli quando è pieno quindi non so se questo sia sufficiente per rendere la città in cui abito smart oltre che la più bella d'Italia e non so nemmeno se funzioni effettivamente questo cassonetto ma diciamo che dichiara di essere smart No, diciamo che Fidenzi si sta provando anche più intensamente in questi anni però alle volte capitano delle cose magari qualche servizio viene tolto o poi rimesso adesso per esempio in una fase di transizione per quanto riguarda il trasporto pubblico però per esempio qualche anno fa c'era il tempo reale degli autobus ci sono i cestini smart c'è la possibilità per esempio di sapere se ci sono incidenti in varie aree della città quindi comunque sono secondo me i servizi utili al cittadino e poi è chiaro che quando uno ha qualcosa vorrebbe un po' di più quindi nel senso se potessi davvero fare le cose burocratiche sul sito sarei molto più contento però non so, non si si lamenta Secondo me è interessante questo punto qui vorrei fare le cose burocratiche sul sito chiedo che tre città su quattro, quindi tutte e tre Caran della mia c'è un modo di fare queste cose in una maniera un po' più digitalizzata diciamo secondo me prima di parlare di smart city dovremmo parlare di digitalizzazione in generale io vi dico, quando ero nella generica città del centro Italia ho potuto fare moltissime cose online per quanto fossero procedure più o meno ibride del tipo il modulo inviato nel form che per me è proprio una roba che non c'ha senso compilo un form e devo allegare un modulo con le stesse cose che t'ho scritto nel form però comunque c'era la possibilità di fare determinate cose e questo qui è stato un impatto anche culturale abbastanza shock quando poi sono andato nella città col mare più bello della campagna quindi effettivamente io non ho ancora il medico, quello di base perché non vi è una procedura chiara, tutta una serie di mediche brucatiche ma io non posso farlo online, io devo andare a fare la fila con i vecchi dalle sei di mattina per riuscire poi a convincere l'impiegato dell'asle che quello che sto dicendo io ha un senso e si incrocia con qualche cosa che lui dovrebbe saper fare, per esempio questa cosa dove direi prima non l'ho mai dovuta fare, l'ho potuta fare su internet potevo chiedere il permesso per parcheggiare l'auto su internet potevo vedere da casa prima che io scendessi se stava passando un'autobus se stava passando il tram, c'erano incidenze, c'erano incontri e quello secondo me anche fa parte di tutto quanto il pacchetto di servizi al cittadino e scommetto che sia a Lione sia nella città più bella d'Italia questa cosa ci sia, credo che è una cosa...

Si, hai perso un'occasione fondamentale per usare una buzzword perché dovevi e non l'hai detto, dovevi dire Digital Transformation che è la parola più utilizzata da tutti i commerciali delle aziende di consulenza che vendono tecnologia, detto questo io salto un attimino a un ragionamento perché mentre parlavate mi veniva in mente una cosa allora io prima di trasferirmi qua a Lione ho abitato per diversi anni quasi una decina a Budoni, Budoni vicino a Sant'Iodoro una località balneare sarda, località io li chiamo paesi fisarmonica perché da paese durante la stagione estiva diventano più che una media città con tutti i disagi legati a questo incremento e questa densità di persone sullo stesso territorio ed è là che in realtà i servizi digitali fanno la differenza io per un po' di tempo mi sono occupato di turismo e di destination management e uno dei ruoli del destination management era anche quello di innovare la gestione dei servizi in un dato territorio, no? che era una cosa fondamentale e quindi mi sono però nel contempo trovato a ragionare in termini di grande città e piccolo paese fondamentalmente la digitalizzazione messi da parte i classici servizi comunali che per me dovrebbero essere condizioni sine qua non la digitalizzazione di tutti gli altri servizi a partire dalla mondezza per esempio là c'è la raccolta porta a porta fino ad arrivare al traffico, ci sono quattro vie principali sai che non lo devi spiegare che alle 5 quando stanno tornando dalle spiagge quelle vie sono imballate, quindi in realtà questa esigenza non c'è e lo shock l'ho avuto poi quando mi sono trasferito nella grande città e nel centro della grande città una cosa che mi ha catturato l'attenzione è per esempio la sensoristica che io ho trovato qua a Lione Lione è una città zeppa di sensori a partire dalle toilette comunali che sono un po' da perdere che sensore c'è nella toilette comunale scusa il sensore di autopulizia che ti dice che la toilette è aperta e chiusa che la toilette è pulita o sporca hai sensori di passaggio sulle strade spessissime volte vi trovate dei tubi, due tubi uno a fianco all'altro che crossano la strada attraversano la strada con una cassettina e metallo ancorata al pavimento quelli sono dei sensori di passaggio che servono per raccogliere una serie di informazioni oltre a questo insomma ci sono tutte tutte le sensoristiche per esempio io quando vado in discarica vado con la mia smart card e verso i rifiuti e getto i rifiuti no? e questa cosa mi ha stupito però mi rendo conto che in una città delle dimensioni di Lione tu devi agire in questo modo per cui la domanda che vi giro è si ha senso parlare non solo di smart cities ma anche di smart village? io sì, secondo me sì ho due domande che mi ronzano in testa da quando abbiamo iniziato e non so quanto siano date al fatto che non conosco bene l'argomento però la prima è sicuramente ha senso parlare di smart agglomerato urbano di qualunque dimensione e allora la domanda è secondo voi lo sforzo per smartificare un paese o una città o una piccola cittadina è giusto che venga dal basso da parte del mauro della situazione che lavora nel comparto del turismo di un piccolo paese o dovrebbe essere standardizzato dall'alto per fare in modo che le smart cities usino tecnologie almeno compatibili tra di loro ed evitare che ognuno si faccia la sua merda a modo suo? sì, questo è centrato un po' al punto, adesso però avete detto due cose su cui volevo tornare su entrambe una cosa che prima era spuggita quando ho detto è piena di sensoristica mi è scattato un campanello, ho detto ah sì effettivamente la sensoristica anche proprio dell'aria, dell'acqua, monitoraggio ambientale in generale è una cosa abbastanza comune e infatti molte città hanno molte esigenze che non sono custom indipendentemente dalla loro dimensione, magari cambia la soluzione effettiva di monitoraggio però tu vuoi sempre sapere la stessa cosa, quanto è inquinata l'aria e in che momento e quindi abbiamo esigenze che sono comuni, una grande quantità di dati che se usi la soluzione miopoginistica non riesci a gestire e altre cose e quindi sì effettivamente si schiappa un pastrocchio, però fortunatamente l'Europa ci sta lavorando nel senso che vedo che molti bandi per esempio sotto Horizon, in generale ci sono molti bandi che parlano di questo e che spingono le città ad adottare, cioè spingono le città ad interoperare in generale, a condividere i dati, a condividere le soluzioni e poi in ultima l'idea sarebbe di riuscire ad adottare uno stack comune o se non comune interoperabile quindi diciamo che in questo caso nonostante tutte le proposte che sono venute poi dal basso, comunque qualcuno dall'altro si è reso conto che era necessario una normalizzazione e quindi si sta mettendo effettivamente dei soldi e altri tipi di risorse Sono d'accordissimo con David nel senso che se tu vuoi fare qualcosa di efficace è necessario in qualche modo un coordinamento di natura non solo tecnica perché anche un coordinamento di natura politica nell'azione e voglio espandere il ragionamento che faceva Mattia del coinvolgimento della sovrastruttura, piccoli village, piccole città e serve una sovrastruttura che in qualche modo faccia in modo che questi villaggi, queste città possano in qualche modo anche interoperare tra di loro ma voglio buttare l'amo anche oltre, quando si parla di smart city, io non voglio usare la parola smart city possiamo bandirla oggi perché le città smart city che vedo mi sembrano tutto tranne che smart perché no, smart city fondamentalmente è una città che raccoglie informazioni, l'elabora e guida le decisioni e fa permettere la presa di decisioni guidate in funzione dell'informazione ma se chi prende le decisioni è una testa di dirapa come in molti casi succede, in alcuni casi succede scusate la mia enfasi in questa cosa, non so se notate che ho lavorato col pubblico prima no? No però in questo caso sono tutto tranne che smart e una cosa che ho imparato nelle mie precedenti vite è che in realtà una città digitale, come preferisco chiamarla, digitalizzata, in qualche modo presuppone il coinvolgimento attivo di tutti gli stakeholder, per cui immaginiamo la città Lione ok? che vuole essere una città digitalizzata deve mettere in grado il cittadino le attività commerciali e le attività non commerciali, vedasi associazioni, fondazioni, scuole, ospedali pubbliche e o private, no? deve metterli in condizioni di condividere l'informazione perché fondamentalmente quello che una smart city fa è far circolare l'informazione affinché le decisioni a tutti i livelli, a livello politico, chiudo questo, investo in questa cosa, investo in quella a livello urbanistico, quindi ingegneristico, chiudo una strada, cambio un senso unico a livello sociale, faccio un evento, non faccio un evento, ma anche a livello del cittadino che dice ok, oggi vado a quest'evento dell'associazione X perché l'informazione dell'associazione X ha fatto bubble up ed è arrivata in un hub centrale che può essere come, io adesso abito a Lione sì però in un quartiere che conta 10.000 abitanti, noi abbiamo l'hub della città tutte le associazioni submittano i contenuti attraverso un piccolo portalino e noi ce li ritroviamo tutti sull'hub e io so quando c'è l'associazione dei vecchietti che sta piantando le piantine per strada o sta pulendo i merciapiedi e decido se andare o no a dargli una mano ed è fantastica questa cosa ed è molto più smart di come si possa pensare talvolta, o altrettanto smart del semaforo intelligente e del pollution sensor che ti dice adesso vai a piedi sì però questo richiede, come hai detto prima cosa, il contributo di tutti quelli che stanno nella città digitale non solamente delle amministrazioni, quindi tu non sei più come utente un fruitore di contenuti sembra che stiamo parlando di social, il concetto potrebbe anche estendersi a questo però diventi parte attiva in cui inserisci effettivamente dei contenuti e dei dati questo esempio è abbastanza sciallo, nel senso che se uno ha un'attività o un'associazione ha tutto l'interesse di pubblicizzare il proprio evento e la gente intorno a lui ha l'interesse di vedere se è un evento, però se si va su delle informazioni di movimento o presenza il topic diventa un po' più sensibile, per cui per esempio chiedere ai cittadini, anche ai turisti in generale chiedere alle persone di dirti dove sono in un determinato istante o in una parte della loro giornata anche banalmente chiedergli con che mezzo si stanno spostando diventa un problema diventa un problema sia a livello emotivo, la domanda è come faccio a spiegarti come faccio a spiegarti e tu devi fidarti di me che io farò con quei dati le cose giuste e li tratterò magari in maniera etica, possiamo dirlo in modo nostro diventa complesso anche a livello bureaucratico questa cosa secondo me passa anche, perché tanto lo sapevo che se il tipo di risparmio è andato a finire ogni volta si passa a fare queste cose, questa cosa è imprescindibile da una volontà politica locale non di andare in questa direzione.

Questi discorsi che stiamo facendo io sono molto d'accordo con tutti quanti e mi ricordano tanto, ma parliamo di ragionamenti del Movimento 5 Street della primissima ora con cui io ero fortemente d'accordo, si parlava di cittadini che poi hanno preso tutta quanta deriva, ma io ricordo che c'era del fermento specialmente da parte delle persone più giovani per andare in questa direzione.

Se poi vediamo quello che è diventato nel tempo nel senso noi siamo comunque le stesse persone che siamo state in grado di accapigliarci una roba che faceva contact tracing in una maniera veramente blanda, quindi figuriamoci come fa la politica a spiegare una cosa del genere alle persone.

Ed è qui secondo me che c'è lo stallo di tutto, c'è una grande richiesta di automatizzare, di digitalizzare, di rendere più smart tantissimi processi della nostra vita di tutti i giorni, ma allo stesso tempo non si ha la volontà politica di farlo, dove la volontà politica intendo proprio spiegare alle persone a che cosa serve e la volontà di impiegare i soldi che già sono stanziati per queste cose, perché ci stesse ascoltando, i soldi per la digitalizzazione e per le smart cities ci sono sempre stati e vengono dati alle città.

Quello che le città ci fanno poi non si sa per che cosa vengono impiegati, può essere dal sensore di temperatura dell'acqua, però magari ti costa un milione di euro perché è fatto con il platino, all'intera infrastruttura della smart city.

Il mio invito, perché ci sta ascoltando, è di informarsi nel proprio comune, nella propria regione, sono atti che sono comunque pubblici, di quanti soldi, quante iniziative per la smart city sono state pianificate, sono state stanziate, a chi sono andati i soldi e che cosa si è fatto poi.

Perché nel senso, spesso se ne parla in un'accezione negativa del tipo ma non ci sono soldi, non vengono buttati soldi, non ci si mette d'accordo e allora che cosa si deve fare, ci sono altre priorità, il che è tutto quanto giustificabile.

Però ecco, il punto in cui voglio soffermarmi e riflettere è il fatto che questi investimenti si sono sempre fatti, ora più di prima, ma il ritorno, se non per alcune poche realtà virtuose, è stato veramente minore.

Se pensiamo solo al PNRR che sta arrivando, a quanti soldi verranno messi in tutta questa macchina, sono veramente curioso di capire tra 5 anni dove siamo, tra 10 anni dove siamo e soprattutto come si evolverà anche il discorso politico nelle amministrazioni locali.

Stiamo veramente andando proprio su Radio 24, nel senso, non mi dovete prendere conto.

Infatti ora si rientra, però nel senso, quello che volevo dire è questo è il momento storico giusto per far muovere anche qualcosa dal basso in questa direzione qui.

Perché è il momento storico in cui gli investimenti per questa cosa si vogliono fare e c'è la possibilità di farlo.

Il fatto di parlare anche di smart village è assolutamente fondamentale.

Se già pensiamo al concetto di città metropolitana, ci sono tanti comuni nella città metropolitana, si può fare venti, si possono condividere informazioni, si può fare tanto.

E le capacità per fare questo, anche a livello standardizzato, teoricamente ci sono, ora tra un po' baciare gli anni, ma teoricamente ci sono e anche dal punto di vista legislativo ci si dovrebbe muovere in quella direzione lì.

Alla fine, se ci pensiamo, ci sono tanti dati che sono già disponibili.

Devi andare sul portale open data della vostra regione e vedere quanta roba c'è.

C'è tantissima roba, non ci rendiamo nemmeno conto di quanta roba c'è, risalente anche a 10, 15 anni fa.

Quindi sono cose che sono sempre state raccolte.

Ora, è quel momento storico in cui c'è quella particolare sensibilità e per chi volesse fare anche qualcosa a livello personale può prendergli open data, che sono open, e farci quello che vuole.

Ci sono alcuni tipi di dato che non hanno nemmeno restrizioni per le opere a livello commerciale che ci vuole fare sopra.

È un mercato ambizioso.

Infatti io sto ancora aspettando l'app che ti dice se puoi parcheggiare o no in una via perché c'è la polizia a strada.

Esatto, io ho preso tantissime multe a Firenze per questa cosa.

Quanta benzina! Quanta benzina! Facevo due ore di giri, io e David in macchina per ore, quando ritorniamo dal lavoro per riuscire a cercare il parcheggio.

Quando poi alla fine si sa se su quella strada ci puoi parcheggiare, se c'è il bio risorso, se non c'è il bio risorso.

Sono tutti open data, che sono disponibili.

Fortunatamente, se vogliamo parlare di Firenze, sono dati che sono consultabili anche dal cittadino comune.

Ma sono dati che hanno tutte quante le città.

E spesso è il cittadino che le dovrebbe fare le chieste, perché ci sono.

Infatti vedo che ci sono dati più o meno strutturati.

Diciamo, alcuni settori hanno attirato la digitalizzazione prima, per esempio il catastro.

Tutta la parte di sistema informativo territoriale.

Altri invece, per questioni proprio pratiche, non hanno bisogno di un'immediata digitalizzazione.

Per esempio, anche le opere dei vigili.

Il vigile che esce e fa il giro del mercato.

Perché devi digitalizzarlo? Ovviamente è scritto su un calendario o qualche parte, rifà il giro e siamo tutti contenti.

Però se quella informazione fosse stata strutturata da qualche parte, magari avremmo potuto farci qualcosa.

Con questo non sto dicendo di prendere visivamente quando non passa.

Esatto, quanto ridurresti gli ingressi del comune di Firenze in quel modo? Perché c'è anche questo parametro da prendere in considerazione.

Però nel ragionamento abbiamo detto una cosa importante.

Una parte di queste attività possono essere fatte anche dal cittadino sensibilizzato e che ne ha le capacità.

E qua nel nostro podcast di persone che hanno le capacità di attivarsi e nel fare...

Sento qua il flavor delle mashup application anni 2010, no? Ve le ricordate? Le API, il mondo delle applicazioni mashup che sono delle non applicazioni che prendono un po'...

Un po' lo risento questo flavor.

Secondo me potrebbe essere una nuova rivoluzione.

Per cui se io sono un cittadino oggi e volessi mettermi in ballo con queste cose, a livello tecnico quali sono le sfide che dovrei affrontare? Io sono un programmatore, sono un ascoltatore di Gitbar.

Cosa dovrei fare per iniziare a muovermi in questa direzione? Lato tecnico, quali sono i tool, quali sono i linguaggi, quali sono i framework se ne esistono per poter iniziare ad avvicinarmi a questo mondo? Secondo me una cosa che si può fare invece da non programmatore, quindi può fare praticamente chiunque, è contribuire a OpenStreetMap, che è un piccolo miracolo.

In Italia è tra l'altro avantissimo, alle volte è più aggiornato di Google Maps, quindi veramente sono...

Vero, vero, vero.

Ho caricato delle rotonde e ci hanno messo quattro anni a caricarle su Google Maps.

E quelle rotonde ce l'hanno su OpenStreetMap prima di Google Maps.

E c'è un'applicazione, se non ricordo male, si deve chiamare OSM Street Complete, credo qualcosa del genere, che in pratica ti dice ah, ti trovi qui, dici com'è la strada, c'ha le buche, non ce le ha, è trafficata, tipo cose di questo genere.

TripAdvisor delle strade.

È il TripAdvisor delle strade, sì, fondamentalmente, però per esempio se c'è un blocco, insomma almeno uno lo sa.

Una stellina là per tutto.

Sì, però diciamo da sviluppatore avvicinarsi a OpenStreetMap anche è interessante, anche per evitare...

cioè vabbè, loro hanno, insomma, Carmelo sa meglio di me questo, però insomma hanno una licenza d'uso abbastanza tranquilla, puoi fare anche abbastanza chiamate.

Sì, sì, certo, assolutamente.

Se l'uso è giusto e giustoficato, lo puoi documentare su tanti tile server, puoi prendere le tiles, sostanzialmente le parti della mappa, le mattonelle della mappa, anche ad una frequenza abbastanza spinta.

Il bello di OpenStreetMap è che, come diceva Davide, ci sono tantissime community che ci contribuiscono e ci sono anche delle community a livello locale che non ti aspetti.

In diverse parti d'Italia, non vuol dire in tutte le parti d'Italia, però diciamo in moltissime parti d'Italia ci sono delle community locali che fanno solo questa cosa qui, che sostanzialmente è il contributor open source che non è programmatore magari.

Quindi allo stesso modo gli sta contribuendo a qualcosa di open con il suo tempo e sta facendo un servizio per la comunità, che adesso sia l'equivalente da non programmatore di quello che si dice spesso.

Se non sai scrivere quel particolare codice, puoi fare la traduzione della documentazione, puoi aggiungere esempi, puoi scrivere la documentazione.

Questo è l'equivalente se non stiamo parlando di codice.

E poi da OpenStreetMap in realtà si dirama tutto quanto un mondo.

Perché comunque OpenStreetMap non è solo consultabile su internet, come se fosse Google Maps.

Quindi si può fare, ti puoi calcolare l'itinerario, puoi vedere quali sono le attività commerciali a punti di interesse in un determinato posto, ma ci sono anche applicazioni sia open sia non open che sfruttano OpenStreetMap a pieno.

Ad esempio su Android c'è Osmond, che è sostanzialmente l'equivalente di Google Maps, un navigatore ma che utilizza i dati di OpenStreetMap.

E sorprendentemente in ambito urbano, io credo che questa cosa la abbia vista a Londra, mi pare, ti diceva anche il percorso della metropolitana sotto.

Cioè tu effettivamente ti potevi spostare da una banchina all'altra, da una fermata all'altra, con quell'applicazione offline, senza internet, perché potevi scaricare una difficoltà di via su una mappa.

Ed è una soluzione open, è una soluzione grazie ad una soluzione aggiornatissima.

E poi alla fine OpenStreetMap è anche tutta la base per tantissimi servizi.

Ed è il map provider di tantissimi servizi che utilizziamo tutti i giorni, insomma, della serie da magari l'applicazione del comune a Movit.

Se qualcuno di voi ha mai utilizzato Movit, suppongo di sì, se siete spostati con i mezzi pubblici, la mappa di Movit, sicuramente per la versione web, per la versione mobile, suppongo anche, è fatta con OpenStreetMap.

Stiamo comunque parlando di un prodotto commerciale, non è una no profit.

Quindi, nel senso, sono degli strumenti che sono open, ma sono usatissimi anche in ambito commerciale.

La roba veramente figa di OpenStreetMap è che puoi fare delle tue mappe personalizzate.

Quindi puoi self-postare un tile server, questo server che dà le mappe, insomma, così, e puoi inserire sulla tua mappa i punti di interesse che ti interessano, diversi layer, puoi togliere magari le attività commerciali, puoi fare questa mappa della città più bella del mondo gialla, perché è ancora più bella, puoi fare quello che vuoi.

E sono tutti strumenti la cui documentazione, e questa è una cosa che ci vengo a sottolineare, c'è tanto materiale in italiano, che è strano.

C'è tantissimo materiale in italiano.

Sì, volevo collegarmi a un'altra cosa però.

Finora abbiamo citato degli strumenti che sono fondamentalmente quelli delle mappe con le varie declinazioni del caso.

Quando si parla di Smart City e si parla di contributo che da sviluppatori possiamo dare, esiste qualcos'altro che possiamo utilizzare per fare le nostre mashup application o esistono delle regole alla quale dobbiamo sottostare quando prendiamo questi dati, regole tecniche intendo, quando prendiamo questi dati, degli standard, no? Sì, alcuni sono de facto, vabbè, insomma dipende un po' dalla natura dei dati chiaramente, però per dirne una che parlavamo di mappe, di strade, non si si sposta solo in macchina e in bici, si si sposta anche con mezzi pubblici, lì lo standard per quanto riguarda i trasporti programmati, quindi autobus, treni, aerei volendo, è uno standard che si chiama GTFS, ora non mi ricordo la sigla, mi sa che è General Transit qualcosa, File System ovviamente, chiaramente File System, e questo è stato Feed Specification Graph, questo l'avrei dovuto sapere, però è diventato standard anche grazie a Google Transit, perché comunque le agenzie, cioè era già una specifica ampiamente in uso in America, però adesso viene molto usato anche in Europa, perché per dare gli orari a Google Maps, le agenzie usano questo, possono almeno, non so se esistono altre API, che possono dare questo GTFS, ed è molto completo, perché se sei in accordo con, e qui si rientra di nuovo nei discorsi politici, però se sei in accordo con l'agenzia, puoi avere i passaggi real time formalizzati, quindi sapere l'autobus, se è in tardo, se è in anticipo, e dov'è genericamente.

Quello di quella corsa lì, quindi insomma puoi farci tante cose volendo.

Diciamo che su Open Data tipicamente ci sono i passaggi statici, quindi sono letteralmente gli orari che trovate alle paline dell'autobus, però già con quello insomma si possono fare tante cose, perché ti esce un grafico, ti escono gli orari, ti escono le direzioni e altre cose, e quindi già un po' di analisi e cose si possono fare.

Invece l'altra cosa che ha un nome simile, è per i bike sharing, in generale poi è diventato standard per anche gli altri sharing, quindi car sharing e compagnia, ed è uno standard che si chiama GBFS, e penso che sia la stessa cosa però, è general bike sharing fondamentalmente.

Si è general bike share feed specification.

Grazie, avete aiuto dalla rezione.

Questo è un po' meno standard, perché è anche un po' più nuovo, e in generale il bike sharing è sicuramente più nuovo rispetto al treno, però vedo che sta andando per la maggiore.

La specifica di GBFS vuole che questi dati siano pubblici, non tutte le agenzie lo rispettano, però questo è da standard perlomeno.

Quindi è stato pensato proprio con l'intenzione di farlo usare alle persone, quindi non ti rivela niente, cioè non puoi seguire la singola bicicletta per dire, io so che c'è sempre quel tipo di teoriche, prendere la bicicletta e va lì, questo non lo puoi fare, quando uno ha preso il mezzo e il mezzo non è più disponibile, sparisce dal feed.

Quindi tutto privacy orienta.

Infatti volevo arrivare a quel topic, perché la linea sottile che divide ciò che deve essere coperto da privacy, e ciò che non deve essere coperto da privacy, come dicevi prima anche tu, è molto sottile.

Rimanendo sulla mobilità però, il mio baldo compare Carmine, tempo fa mi parlò di un tool che adesso dirò in modo sbagliato, Open Trip Planner, Planning, Plan...

Sbagliato.

Open Trip Planner.

Open Trip Planner.

Il pianificatore di trip all'aperto.

Esattamente.

Il classico tool olandese della situazione.

Tool per l'ippi sociale.

No, scherzi a parte.

Questo tool è fondamentalmente un'applicazione, giusto? È sostanzialmente un modo, un applicativo con cui puoi pianificare un viaggio.

Qui si apre un filone che è legato sia alla parte di mappe, quindi diciamo un grafo stradale, che in questo caso è un grafo di OpenStreetMap, alla specifica per il trasporto pubblico.

Quindi unendo queste due cose, puoi chiedere a questo strumento di fare una pianificazione, una simulazione di viaggio dal punto A al punto B, con i mezzi pubblici che ha a disposizione nel feed.

Ok? Quindi, sostanzialmente, se volete farvi calcolare il denaro da Google Maps, da via Michelin, da Uber, eccetera, la keyword giusta è un motore di trip planning.

Quindi sostanzialmente un applicativo che possa, in maniera multimodale o meno, e qui si arriva, pianificare un viaggio.

Quindi se vogliamo andare dal punto A al punto B, quindi magari c'è casa mia che dista 500 metri dalla fermata più vicina, avrò sostanzialmente delle parti di questo percorso che sono chiamate leg, che mi dice vai a piedi da qui a qui a quest'ora, perché poi ovviamente il denaro viene fatto in base all'ora, aspetta 5 minuti, arriva il bus, il treno, la funivia, il traghetto, l'aereo, x, y, z, che ti fa fare queste fermate su questa direzione, tu sali a quest'ora qui, scendi a quest'ora qui, e ne arrivi a destinazione.

Ovviamente un motore di trip planning fa più di questo, nel senso che ha come base sicuramente, possiamo immaginare come una torre, una serie di cose che si impilano.

Quindi c'è la strada, c'è il feed del trasporto pubblico che dice guarda su queste parti della strada ci sono fermate, ci sono percorsi, eccetera, eccetera, hai una dimensione temporale che dice quando quelle cose succedono, quindi hai dove, quando, e hai anche una componente dinamica che è la parte real time, quindi nel senso, se è vero che quel itinerario passa magari con il bus alle 5 da quella fermata, però so che il bus che sta arrivando a quella fermata ha un'ora di ritardo, o so che ci sono delle interruzioni sulla linea, perché anche queste cose sono contenute all'interno del GTFS, ti posso consigliare un itinerario alternativo che magari in una situazione normale sarebbe stato più lungo, e invece ora non è corso.

E perché è importante a questo punto tutta la parte di OpenStreetMap? Perché se è vero che ho la fermata lì, ma so che quella strada è chiusa, io non ti ci faccio passare.

Quindi è tutta una cosa che si va a infilare.

OpenStreetMap è un motore di trip planning open, non è l'unico, ci sono alcuni che utilizzano quello, alcuni che utilizzano altri, il concetto però è lo stesso.

È sostanzialmente un applicatore di informazioni on top del grafo stradale che ti possono consigliare un determinato percorso rispetto ad un altro.

Ovviamente stiamo parlando di trasporto pubblico, con il trasporto privato si entra in tutta un'altra dimensione, perché come potete immaginare ci sono tante variabili in considerazione.

Sto con il motorino, sto con la bicicletta, sto con la macchina o un camion o un taxi, quindi magari ho accesso a determinate corsie.

Sto con un mezzo pesante, quindi devo fare un percorso invece di un altro percorso.

E anche queste casistiche sono contemplate da OpenTrip? È molto versatile, sì.

Puoi tunare tutto, anche la tua poca voglia di camminare o molta voglia di camminare può essere tenuta in considerazione.

Tante cose.

Ok, quindi correggetemi se sbaglio.

OpenTrip è un database con un motore di query che è molto più intelligente di questo, però possiamo vederlo da sviluppatori così, un'interfaccia qui, carico i dati, una roba in cui carico i dati e dopo un po' gli faccio una query e lui mi restituisce una risposta.

La domanda è, me lo devo immaginare come una roba in stile WordPress o come più una roba in stile Postgres? Cioè me lo devo immaginare come un servizio o come un applicativo tutto fuori? No, allora OpenTrip Planner da solo in realtà è un tool da home online, credo.

Sì, nel senso che ha una sua API.

È solamente un plugin con le API, con le API sia REST sia GraphQL.

È uno dei pochi casi in cui c'è senso GraphQL perché è un grafo.

Questo è un buon caso d'uso per GraphQL.

Domanda, siccome so che quello avete detto...

No, scusa, volevo dire, ci sono dei front-end sia web che non.

Per esempio quello che citavo prima, Carmine, l'app Osmond, è un front-end di OpenTrip Planner, credo, anche.

E anche un altro, in realtà io consiglio un'altra app ora, che è Organic Maps, che pure mi sa che usano anche loro OpenTrip Planner.

Quindi domanda, se io dovessi prendere la mia città Lego e mappare gli autobus, i treni e le vie, farmi la mappa, darla in pasto a OpenTrip Planner, lui sarebbe in grado di farmi smart la mia Lego City? Beh, per me...

In realtà è un caso tutto reale, nel senso, se tu hai un videogame con una mappa e vuoi fare route planning...

Esatto, lo puoi fare.

Puoi fare.

E per farlo dovrei semplicemente buttare il container di OpenTrip Planner e il gioco è fatto.

No...

Dai ditemi di no! No, no, no.

No, no, no.

Tra l'altro il container di OpenTrip Planner si apre tutta un'altra storia.

È un applicativo molto, molto pesante.

Esatto.

Nel senso, è proprio quel giavone proprio bello che ti immagini, quella grosso, che per avviare ci vogliono giga di RAM, perché il gravo, mamma mia, no.

Quindi nel senso, sì, però...

Enterprise.

Enterprise, esatto.

Però a patto che tu abbia il grafo stradale che comprende OpenStreetMap, con un sistema di coordinate che comprende OpenStreetMap AI, un GTFS che è sullo stesso sistema di coordinate ed OpenStreetMap, lo capisce, sì.

Diciamo, questo è il meme, ecco.

Diciamo sì.

Per quanto riguarda, in realtà, la cosa interessante della specifiche insieme del GTFS, che è una cosa veramente granitica, nel senso, è una cosa che non cambia, che è molto, molto solida, e ci sono librerie per qualunque cosa.

A partire dal programma Enterprise, per esempio, una con cui mi sono trovato bene è una libreria JavaScript che prende in pasto il feed GTFS, feed GTFS, perché ci sta ascoltando e non sa che cosa è, è la roba meno fancy che vi potete immaginare.

È un file compresso con dei CSV dentro.

Quindi questo qui è un feed GTFS.

Il feed statico è letteralmente così.

E ogni file della specifiche è come se fosse una tabella di un database relazionale.

E le varie entità sono in relazioni tra loro con le chiavi.

Quindi sostanzialmente, se volete mappare il GTFS in database relazionale, c'è qualunque libreria possibile e immaginabile per farlo.

Effettivamente è per farlo, perché è quella cosa lì.

Quindi nel senso, sono cose che sono veramente granitiche.

Però per rispondere un po' anche a quella cosa dove uno dice voglio approcciarmi a sviluppare Smart Cities, c'è anche un API per quanto riguarda le città, invece che hanno i bike sharing, quelli con i posti dove devi inserire fisicamente i rapici, come si chiamano le dock, c'è un API che si chiama CityBikes e è disponibile liberamente a citybike.es e quella è molto facile da approcciare e da usare.

Invece un altro strumento, oltre a quello che dicevamo prima, il GTFS può essere anche dato in passato ad altri strumenti e ce n'è uno che mi ha colpito oggi perché è stato featured in Postgres Weekly e si chiama Transitland e quello fa esattamente questo, cioè prende il GTFS e te lo piazza su un database relazionale e poi hai tutti gli strumenti classici di Postgres.

Se andate a vedere l'articolo di Postgres Weekly è abbastanza...

Tipo per visitare il grafo, Postgres è l'istrumento migliore del mondo! In effetti è un po' strano, però con Postgres puoi fare tante cose.

Sì, sì, vero, vero.

Lo stavo goliardando ma in realtà ha senso con Postgres.

Super figo! La cosa che mi interessa, avete chiaramente detto che non è propriamente un giocattolo, quindi quando si parla al di là di GTFS, quando si parla anche di Open Trip Planner o Planning Plan, quello che è insomma, è un po' complesso.

Domanda, ma questa è una curiosità da sviluppatore.

È un giavone che si mangia un gozziliardo di RAM e quindi sta roba è come le scali.

Domanda dai Cassius.

Invoco il mio NBA su questo.

Ok, perfetto.

Però si scala, però si scala.

Si scala, ma è una cosa che costa infinito.

Perché considera pure che nella configurazione più performante che ti puoi mangiare, tutta questa roba è in RAM.

Perché tu vuoi che la query sul grafo sia veloce.

Perché magari tu ne devi servire a migliaia, quindi ti puoi mangiare che ti serve tanta RAM.

Sì, la domanda mi veniva dal fatto che tipo sono le robe meno cacheabili del mondo, queste risposte, perché dipendono da un sacco di fattori.

Secondo me è più che chiedersi, abbiamo tanti dati e va bene, quindi tanti dati, tanta RAM, ci sono problemi sicuramente di scalabilità.

E uno dice, hai un grafo, e quando dici grafo chiaramente scateni tutti gli informatici dell'universo, perché insomma la nostra struttura dati è molto importante.

Però ci sono secondo me dei problemi pratici che vanno risolti prima.

Per esempio, io se voglio sapere quali informatici sono va tutto bene, ma se voglio sapere quale biglietto devo comprare, il problema diventa di una complessità infinita.

Io non ho una sorgente dati che mi dica, per esempio, quanto costa un biglietto andare da qui a lì.

Ma il problema è a monte, nel senso che tante volte nemmeno le azienzie lo sanno.

Fanno offerte di complessità arbitrariamente alta e quindi quelli con i primi minuti gratis, 88 di cambi, insomma è marketing, quindi alla fine so uscire di tutto.

E non si informa di tutto.

Alla fine il biglietto è eventually consistent sempre, specialmente se lo fai con i minuti.

Perché magari tu devi fare 45 minuti di bus, tu sali e ci metti un'ora e mezza e basta.

No, ma poi entrano in gioco tutta una serie di fattori.

Mi è venuta in mente un'esperienza, nella mia vecchia vita in realtà, parte del software in azienda che avevamo doveva gestire delle tratte ferroviarie turistiche.

E là avevano le fasce chilometriche, la classica modalità di tarifazione dei trini turistici, però il punto A e il punto D, B, pari distante dal punto E al punto F, costavano in modo diverso perché D era più turistica di F.

E io sta roba con le fasce chilometriche, se te la devo mettere a sistema, devo pensare a un'eccezione.

Ma è un'eccezione puramente non sistematica.

Arbitraria diciamo.

Esatto.

C'è sempre un aneddoto che mi viene in mente ogni volta che parlo di tariffe.

Prima, quando stavo in Friuli, da Trieste a Venezia, ci sono due tratte ferroviarie, una passa sotto e una passa sopra, una più a nord e una più a sud.

Partendo da Trieste, tu vai alla macchinetta, scegli quale delle due vuoi fare, una costa un po' di più e una un po' di meno.

C'è un cavillo, chiaramente era tanti anni fa, magari non c'è più, però c'era questo cavillo per poter prendere la tratta A, il prezzo di B, perché tu non faccia una fermata intermedia in una particolare città che stava su quella linea.

Questa cosa qui, a parte che la sapranno in tre persone, non la saprà anche il capo treno.

Domanda.

Proprio merita quello che dicevamo poco fa.

Proviamo a prendere una tangente che in realtà ci porta anche più nel nostro mondo di sviluppatori.

E questa domanda ve la faccio a tutte e tre.

Quando è che una casistica di questo tipo dobbiamo farla diventare regola di modello, tale per cui dobbiamo adattare il nostro codice a supportare questo tipo di regole che non possiamo prevedere? Avete un momento in cui una IF diventa, cosa ne so, una nuova classe per gestire le eccezioni? Inizia Mattia, vai.

Subito.

Nel senso, se stai facendo le cose fatte bene, non metti l'IF.

E questa cosa la prevedi e la integri nel tuo modello subito.

Non esistono eccezioni che succedono una volta solo, ogni tanto.

O è una cosa che fa parte del tuo modello, e non la modelli.

L'IF per gestire un caso che succede una volta ogni morte di papa e sa Dio come cazzo si mantiene, e magari l'hai fatto in fretta e furia perché era successo un caso a un cliente singolo una volta e quindi non ha neanche la test coverage, è una cosa che non esiste.

Semplicemente non succede.

Quindi diciamo che sei a favore della programmazione totale.

Si può dire? No, in realtà no.

Nel senso, puoi anche stabilire che questo caso non è coperto dalla tua applicazione e gli utenti, come si dice in maniera gentile, si attaccano al cazzo.

Si attacca.

Non rischi di overmodellare in quel modo? No, perché devi essere bravo a scegliere quali sono i casi in cui decidi che i tuoi utenti si attaccano.

Secondo me è più una questione di modellazione dei business case che copre il tuo prodotto che di modellazione software.

Poi è vero che le due sono estremamente interconnesse, però secondo me è più un problema di business che di modellazione del software.

Devi decidere quali sono gli use case che vai a coprire e quelli che non copri non li copri.

Non è che ci metti un if a caso dopo perché forse lo volevi coprire e forse no.

O è una feature implementata nella tua applicazione o non lo è.

Esatto.

Si pensavo anch'io qualche tempo fa.

Nel senso che, per esempio, con hardware, software e performance il software fa delle cose e arriva all'azienda di hardware e fa quel pattern di hardware e poi viceversa.

Se l'hardware fa una cosa meglio, il software lo rincorre.

In questo caso però non succede.

Nel senso che abbiamo che l'informatica deve seguire i processi burocratici e per forza di cose, anche per aderenza di legge.

Però è rarissimo il caso in cui c'è una semplificazione legale o burocratica che viene spinta dall'informatica.

Se chiedessi una venda, non importa, facciamo una semplificazione di questi biglietti.

Facciamo una semplificazione in generale su tante cose.

Il caso opposto in cui la burocrazia ti costringe a complicare il software, invece, mi sembra piuttosto comune.

Esatto, non c'è feedback in quella direzione.

Però avrebbe comunque dei vantaggi.

Avere il software pronto prima è più stabile, è un vantaggio a livello comunitario.

Si può aprire un mondo, è la centesima volta che uno apre l'app di tutto il mondo.

Però a noi è qua a metterlo al tempo la qualità.

Esiste un caso, secondo me, con la burocrazia, è molto difficile che succeda, ma esistono dei casi in cui fare bene la modellazione software ti aiuta a semplificare i processi di business che il modello software implementa.

Perché magari, disegnando il software che lo implementa, ti rendi conto che ci sono dei casi di business che puoi cortocircuitare, che di fatto sono molto simili e che quindi puoi unificare a livello di business.

Però, come dici giustamente tu, non c'è il feedback dal software alla burocrazia.

Sì, e poi il prodotto può evolversi, essere adattivo, non lo so.

Io ho un approccio un po' diverso da quello di Mattia, ma prima diamo la parola a Carmine.

Io credo che sia un'unione delle due cose.

Anche io credo che nel mondo che vorrei è come dice Mattia, nel senso che magari modellando il software io posso trovare, sicuramente trovo dei casi che posso circuitare, o posso comunque far bene anche alla parte più burocratica.

Diciamo che, specialmente quando si parla del tipo di software che stiamo parlando, l'aspetto tecnico, per quanto sia fondamentale, viene comunque dopo.

Quindi alla fine è una no-hop.

Mi è capitato anche personalmente di incontrare delle cose del genere e di dover fare delle storture perché non c'era modo di fare altro.

Questo magari è vero anche per il nostro bias, nel senso che cambiare il software per tutti i casi limpi che ci possono essere è una cosa comunque veloce, semplice.

È una cosa che posso fare.

Riuscire a cambiare altri tipi di processi è una cosa più lunga, più laboriosa e che deve mettere d'accordo più test.

Io qualche tempo fa, quando gestivo l'azienda, ho vissuto un'esperienza un po' particolare, nel senso che sono caduto nella trappola dell'overmodellazione.

Per cui sono partito da un problema, sono andato a fare l'analisi e alla fine sono immersi in tutta una serie di business case.

E la tendenza, voi perché nel mondo delle start-up, delle piccole imprese, ogni cliente è un cliente importante e voi questa cosa l'avrete sentita dire tantissime volte, allora puoi dire ok non lavoro in quel mercato, ma se lavoro in quel mercato comunque il problema ce l'hai.

Puoi decidere di non sporcarti le mani, però se stai in quel mercato comunque il cliente lo deve soddisfare.

E a me è capitato di avere due situazioni parallele.

Da una parte avevo delle esigenze legate ad alcune business unit della mia azienda, che erano esigenze specifiche, e altre esigenze che invece erano del cliente.

Unendo le due esigenze, ok, il modello diventava mostruoso perché tra l'esigenza A e l'esigenza B ci stava un mondo da modellare per poter interfacciare questi due modelli, questi due mondi.

E quindi mi sono trovato ad avere un modello molto più grande di quello che le mie risorse umane, i dipendenti, gli sviluppatori, potevano mettere in piedi.

Questo capita e quello è stato la causa di alcuni fallimenti di alcuni progetti, ok, della perdita magari anche di alcuni clienti grossi.

Per esempio parliamo di un motore di booking che dentro di sé aveva un motore di booking ferroviario più un motore di booking turistico.

Unire questi due modelli presuppone uno sforzo di astrazione per creare un modello che li contempli entrambi esagerato.

Quindi trovare un ubiquitous language che sia ubiquo a quei due modelli, ma in quel caso ti stai allontanando sempre di più dalla realtà.

E a me questa cosa mi ha un po' segnato a livello di sviluppatore, a livello proprio di ingegnere del software e di architetto del software.

Tanto tale per cui oggi, oggi mi trovo nella condizione di dire, oggi io modello i due business case con il minimo effort possibile, nel momento in cui trovo per la seconda volta un case che ha un pattern simile, io tolgo l'if, adesso sto semplificando, tolgo l'if ma costruisco per esempio la struttura di dati e scendo più a fondo nella modellazione in modo da rendermela interattiva.

Questa diciamo che è l'escamotage che ho trovato per non cadere nel rabbit hole della modellazione.

Ecco perché ti dicevo non sono pienamente d'accordo con te Matti, ma dal punto di vista empirico, viene da questo tipo di esperienza.

Paradossalmente la risposta giusta alla tua domanda iniziale, come a tutte le domande era dipende, nel senso che io ti ho dato un punto di vista estremo, probabilmente molto influenzato dal fatto che io in questo momento lavoro su un API che deve essere stabile, perché la usano in tanti e la usano in mille modi diversi ed è estremamente established e quindi cambiare il modello e cambiare come funziona è una cosa che noi cerchiamo di evitare a tutti i costi.

L'estremo opposto è quello della startup in cui parlavi tu, in cui ogni cliente è un cliente importante, quindi ogni cliente è meritevole di un if.

L'approccio che mette insieme le esigenze di tutti e due è quello iterativo di cui parli tu probabilmente.

Però sì, alla fine dipende da molti fattori e la stabilità dell'architettura software su cui lavori e l'importanza che vuoi dare alla stabilità è uno di questi.

Vero, bellissimo.

Bellissimo.

No, bellino questa parentesi, mi ha gasato tantissimo.

Però dobbiamo, visto che il tempo vola, spendere due minuti, due o tre minuti a parlare di FIWARE.

Io l'ho detto, ho detto una parola, non so cosa sia perché un link che mi ha mandato Carmine.

In realtà sembra un'architettura carina, però Carmine e David, potete dirci qualcosa in più? Non so se vuole Carmine dire...

no, va bene.

FIWARE è un consorzio, è un consorzio di aziende e praticamente punta, diciamo, è il nome che sta dietro quella cosa che dicevo all'inizio, cioè che spinge per avere uno stack comune per applicazioni di Smart Cities e lo fa facendo collaborare le aziende all'interno del consorzio fondamentalmente.

Mette in contatto le aziende, mette in contatto le città, le città per le aziende e viceversa.

Quindi molte Smart Cities, tra l'altro loro hanno pubblicato anche di recente un booklet che si chiama proprio FIWARE Cities, credo.

Elenca un po' di città con i loro casi d'uso e effettivamente poi il loro stack.

Quindi diciamo, sotto l'ombrello di FIWARE possiamo trovare sia software che puoi decidere di usare o non usare, è tutto nello spirito del codice pubblico, per cui è tutto pubblico, effettivamente, sia invece anche specifiche, per esempio una cosa che dicevi prima, modellare o non modellare un dato, come modellarlo eccetera.

FIWARE più T-I-M, vabbè.

Praticamente hanno questo progetto di Smart Data Models, per cui è disponibile sul GitHub, tu vai lì e trovi già i Data Models per tutta la sensoristica e anche altri casi che ti possono servire.

Che vanno da come si modella un parcheggio, che sembra una cosa banale, ma niente di non lo è, che forma quando si può entrare, quando si può uscire, cose di questo genere.

Anche sensori e altre cose.

FIWARE è abbastanza standardizzato in questo senso.

Che è un bene.

Quindi è una serie di tool.

Mi è sembrato di vedere che fosse anche un'architettura, dove c'era la parte dei context, la parte dell'autenticazione, con un tool set che puoi scegliere, quale software di autenticazione utilizzare, quale software di storage.

Certo, comunque essendo consorti, avendo loro dei componenti software, scritti e usati dalle varie aziende che compongono il consorzio, ha senso unificarsi e stare su un'architettura unica.

Per cui per esempio, la cosa che sta un po' al centro di tutto quanto, è un software che si chiama Context Broker.

In questo Context Broker ce ne sono due standard e diverse implementazioni.

Però per esempio i più famosi si chiamano Orion, e per esempio c'è un altro Context Broker che si chiama Scorpio.

Entrambi sono fatti da aziende, o da FIWARE stesso, da aziende che appartengono a FIWARE.

E seguono un protocollo che si chiama NGSI.

Che è un protocollo di accesso ai dati di contesto.

Provo a dare un po' di contesto a questo contesto, perché se no stiamo veramente parlando di niente.

Di contesti decontestualizzati.

Esatto.

No, in pratica il caso d'uso tipico è quando hai dei sensori, e a un certo punto vuoi sapere in quel quartiere che temperatura fa, o quanti cestini sono pieni, quanti veci stanno passando, e tu metti nel database dei valori, però quei valori hanno senso solamente per un periodo limitato.

Quindi diciamo che un Context Broker è come se fosse un database, però ha delle feature tipo l'autoscadenza delle entità, e quindi tu memorizzi delle entità e i rapporti tra queste entità.

È tutto molto astratto.

Sì, infatti la prima volta che mi hanno introdotto a questa cosa ero stupido perché tentavo di ricondurlo a qualche cosa su cui già avevo lavorato.

In realtà è un insieme di tante cose.

Se lo posso ridurre dicendo che è un database di cui entità hanno un TTL.

Nel senso, bene.

In realtà è un po' più di così e la parola chiave sta nella parola contesto.

Nel senso che i dati vengono divisi per contesto, dove questo contesto può essere una categoria di questi dati, una città, un luogo specifico.

Una sorta di tenant, Carmine.

Un tenant, esatto.

Può anche essere una prova così.

Diciamo che al cuore c'è questo sistema in cui puoi inserire dati e poi prendere dati.

E questi sistemi sono creati per essere federati tra di loro.

Quindi alla fine se la città XYZ ha il suo context broker e io che sono il suo vicino di città mi voglio integrare con la città vicina, posso far dialogare, posso far federare questi nostri context broker.

Quello diciamo che è importante, come ha detto anche David prima, è il fatto che FIWARE ti dà dei data model standard.

Nel senso, se voglio modellare la stazione medio, non la riscrivo da capo.

Io so che c'è uno schema, in realtà se vogliamo parlare di tecnico è un JSON schema, che mi descrive in che modo io devo rappresentare quella stazione medio, o quel parcheggio, o quel distributore, o quella fermata, o quella scuola, o quella farmacia.

Insomma, è una standardizzazione di queste entità.

In modo che quando diverse amministrazioni, quando diversi attori si trovano a dialogare, non hanno la necessità di fare tutto quel processo di data, di integration, di accordo preliminare, che invece è classico in questi casi.

Ovviamente questa cosa ha un grande vantaggio, che è quello di standardizzare.

Ovviamente questa cosa qui può anche trasformarsi in uno svantaggio, magari che ha già un sistema persistente, oppure semplicemente vuole fare le cose in una maniera un po' più proprietaria.

Fortunatamente, specialmente all'estero, ci sono tante città che stanno spingendo per questa cosa, perché ne hanno riconosciuto l'effettivo valore.

Perché significa che spendo meno, che spendo bene, e sono interoperabili più o meno a costo zero.

Ovviamente è una cosa assolutamente perfettibile.

E ci sarà sempre qualche cosa che magari è custom.

Questo sistema ti permette anche di fare una sorta di introspection.

Nel senso, se nella mia città io ho la stazione medio che cammina, sto facendo un esempio, ho la stazione medio che cammina, ho questo sacchetto che esplode, io posso esporre il mio data type specifico e posso fare in modo che te che ti integri con me, lo puoi fare automaticamente.

Quello che voglio puntualizzare è che noi stiamo parlando di rocket science, sto parlando di niente che sia tecnicamente complesso.

Perché nel senso, è l'open API della smart city, se così possiamo definire.

Non è nulla estremamente complesso dal punto di vista tecnico, ma è uno sforzo importante dal punto di vista di comunicazione e di standardizzazione.

Perché alla fine sono cose che a noi addetti ai lavori possono sembrare banali, ma a chi magari lavora ad un livello più alto e deve effettivamente fare il lavoro di far comunicare diverse entità o semplicemente di vendere questa roba, è una grande cosa.

Ed è sicuramente una cosa che sarà fortemente presente negli prossimi anni.

Perché alla fine si sta andando in quella direzione.

Ed è anche una grande opportunità di mercato per chi ci si dedica ad essere presente.

Guardavo l'orario, siamo a un'ora e venti.

Però David volevi dire qualcosa? Sì, che questi modelli alla fine servono anche per disacoppiare chi scrive e chi legge in maniera abbastanza efficace.

Perché finché siamo noi che scriviamo dentro il dp e se lo rileggiamo ovviamente possiamo fare quello che vogliamo.

Però spesso non è così.

Quindi poter andare da una città e dire guarda, questi sensori scrivono già i smart data models e poi tu puoi prendere una seconda azienda, anche per questioni burocratiche, da un altro appalto, da un'altra cosa, in un secondo momento e dire ok, adesso tu mi visualizzi questi dati.

E questa cosa è molto più facile da integrare a questo punto perché chi scrive sa già in che formato scriverli e chi legge sa già in che formato leggerli.

Insomma, è notevole.

Anche come dicevi Carmen, non è tecnicamente complessa però è sicuramente un benefit notevole.

Beh, avere un linguaggio comune è la cosa, credo, più indispensabile anche se più indispensabile non si dice in questi...

in specie quando si parla di enti pubblici, di città, di bene comune.

Guardavo l'orologio un'ora e venti, ultima domanda legata al concetto di bene comune.

Ok? C'era il detto che adesso mi è passato dalla testa perché io ormai credo di starmi trascinando verso la fine dell'episodio con i gomiti.

Com'era? Public money, public code, qualcosa del genere.

Come siamo messi in termini di public money, public code nel contesto delle smart city? E qua c'è un NDA grande quanto la casa! No, no.

Alcune, diciamo, in alcuni casi molto bene, in altri meno.

Insomma, come in tutte le situazioni, dipende.

Però i componenti cardine, secondo me, di questo stack, come dicevo prima, sono sicuramente tutti pubblici.

Sono pubblici e spesso sono anche usabili perché hai tanti modi di fare codice pubblico.

Puoi anche fare codice pubblico e renderlo ingestibile o indiemporabile.

Insomma, ci sono tanti, tanti modi.

Insomma, finora, visto che contro i smart cities e la backbone dei dati è tutto tranquillo.

Poi quando si va a vedere se esistono delle sorgenti dati, gli adapter per quelle sorgenti dati, un po' meno.

Però sì, insomma, è molto variabile nella mia esperienza.

Secondo me, siamo messi sicuramente nel benissimo, ma meglio di come ci aspettiamo.

Nel senso che se parliamo di cose, se parliamo dei dati, al 99.100 sono già open e ci sono già.

E comunque, per le leggi, prima o poi ci finiscono open.

Quindi dal punto di vista dei dati, a meno che non parliamo di cose estremamente proprietarie o estremamente sensibili, ci sono già.

Per quanto riguarda la parte di software scritto, se ci attenuiamo a tutta questa serie di standard, diciamo che alla fine i component core sono già open.

Quindi probabilmente non trovi open proprio, non lo so, il front end fatto con React o col grafico bello.

Però tutto ciò che ci sta dietro c'è.

Dal punto di vista legislativo, si entra comunque in quel buco strano, per cui si dovrebbe fare, ma se può non fare, sono tanti anni che ancora lo devo capire.

Mi viene da dire che da questo punto di vista non è una cosa solo italiana, non siamo solo le precore neve, tra virgolette.

È una cosa che sta cambiando e sta cambiando in tutta l'Europa.

Quindi sicuramente questa cosa andrà migliorando.

Già il fatto che tutti i dati sono pubblici è un grosso passo avanti.

Mi sto sforzando di vedere il bicchiere e il bicchiere mezzo pieno.

E' effettivamente così.

Perché magari se l'implementazione non c'è, qualcuno, anche privato, può sempre saltare fuori per farlo.

C'è uno sforzo che si sta compiendo in questi anni, è anche la disponibilità di questi dati.

I dati sono pubblici e come per le software indeproriabili, esistono anche i dati illegibili o introvabili.

Quindi, per esempio, penso...

Una lista di PDF, scansioni di cose, roba scritta a penna.

Anche delle cose che sono passabili, ma magari non sai che ci sono.

Ed è un peccato.

Ho visto un articolo quest'estate, il Comune di Firenze pubblica la mappa dei luoghi freschi.

E uno dice, ma la mappa dei luoghi freschi sta su Open Data.

Lo puoi scaricare, lo puoi usare.

Però, essendo una grossa moneda di dati, io non è che posso semplicemente svegliarmi la mattina e dire al Comune di Firenze cosa mi offri.

E loro ti dicono, guarda nell'Open Data.

Però nell'Open Data c'è tutto.

E magari non ti serve tutto.

Magari vorresti sapere cose un po' più interessanti, un po' più aggiornate, diviso per topic.

Diciamo che questa è una domanda aperta agli archivisti più che ai programmatori.

Insomma, come si fanno a trovare i dati in un mare di dati.

Ci sarà una versione di chat GPT che funge da uscere, comunale, che ti dice il dato sta nel secondo ufficio là a destra.

Guarda, in realtà non è inusuale trovare versioni degli Open Data però più rifinite, negli Open Data stessi.

Cioè, quindi, nel senso, certamente una cosa in divenire.

Magari fai questa roba enorme, gigante, poi c'hai dei subset che sono enormi.

È incredibile quanta quantità di dati ci sono già ora ma o le persone non lo sanno o sono difficili da reperire.

Però ci sono.

E a tanti ci sono per legge.

Quindi basta chiedere.

Posso dire una cosa? Credo che questo dipenda da un problema basilare, che è un problema di consapevolezza del dato.

Io, voi ormai, gli ascoltatori lo sanno, qua a casa viviamo di pane e dati, perché mia moglie mentre cucina mi sfagiola la testa con questi argomenti.

È una cosa che lei ritorna a dire sempre, legata a quello che abbiamo detto all'inizio della puntata, non so se era nel fuori onda o in onda, però abbiamo detto che fondamentalmente se merda entra, merda esce.

Quindi, fondamentalmente il concetto che lei ripete è il dato non serve a niente se non esistono delle politiche di gestione dei dati.

Oggi abbiamo gli open data, abbiamo gli open data come obbligo di legge, ma quello che io ho visto dalla mia piccola prospettiva lavorando fino a qualche anno fa, lavorando con gli enti pubblici, è che manca un head of data policy, qualcuno che si prenda la responsabilità, ed evidenzio la parola, si prenda la responsabilità di definire cosa sono i dati, quali sono e come devono essere archiviati.

Adesso vedo molto caos, cioè tutti buttano dentro un cestino così a babbo e poi quello che c'è nel cestino c'è.

Ecco, forse un passo politico importante potrebbe venire da questa direzione.

Prima di chiudere voglio chiedere solo una cosa, visto che lo vedo silenzioso in un angolo, Mattia hai qualcosa da aggiungere su questo topic? No, in realtà sono molto ricordo con la tua situazione.

Sì, è una domanda filosofica che avevo 20 minuti fa e non so se ha più senso farla adesso.

Però se volete la faccio.

Allora abbiamo parlato un sacco di mobilità in tema di smartificazione delle città e di città stesse che smartificano la loro mobilità, però io lavoro per un'azienda che tra le altre cose fa le macchine che si guidano da sole.

Allora la domanda filosofica è sono le città che devono sapere come è fatto il traffico, come è fatta la mobilità, come sono le strade, avere i sensori sulle strade di cui parla Mauro o possiamo spostare tutta quella logica lì sulle macchine che un giorno si guideranno da sole e noi possiamo fregarcene di tutto questo? Aspetta, vedo le balle di fieno che rotolano.

No, stavamo parlando di grafo stradale.

Se non sei grafo stradale, ma le strade poi si suonano fisicamente? Beh sì, non ti sto dicendo dove stiamo andando, non c'è bisogno di strade.

Non sono Doc Brown di Return of the Future.

Però le strade ci sono e va bene, la mappa c'è e può essere o no quella di OpenStreetMap, però è in carico alla città sapere qual è il modo migliore di gestire la viabilità o è in carico ai veicoli? Ah, però stai dicendo due cose diverse.

Un conto è l'ownership del dato, è desidere chi lo raccoglie e un conto è usare quel dato effettivamente dove non sia male che le auto possano usare dei dati pubblici.

Potrebbe anche non essere pubblici, potrebbe succedere una roba come succede già ora con Google Maps, per cui i dati del traffico sono dati dai dati dei veicoli che costituiscono il traffico.

E non è quindi in carico alla città sapere quanto traffico c'è, ma se lo dicono i veicoli tra di loro.

Vista la fiducia che personalmente nutro nelle istituzioni, detta così non mi dispiace.

Posso controbilanciare, shiftare un po' quello che hai detto.

Allora, mi piace immaginare quello che hai detto con un'analogia, ok? Server centrale client o peer to peer? Fondamentalmente possiamo portarla a quel tipo di analogia, c'è però un problema, che in realtà questa analogia è del tutto sbagliata, dal mio punto di vista, questa qua entriamo nel in my humble opinion, ok? Nell'ambito my humble opinion.

Perché in realtà noi non stiamo trasformando con quel ragionamento che facevi il tutto in una rete peer to peer, ma stiamo semplicemente spostando il centralizzatore, quindi stiamo spostando il trust che noi diamo verso l'ente pubblico verso un altro soggetto che si occuperà di trattare, centralizzare e gestire i dati.

Assolutamente, 100%.

Quello che ti dico io per come la penso oggi, potrei ripensarmici, macchine autonome se mi state sentendo mi raccomando, io sono anche dalla vostra parte.

Salutiamo le macchine autonome, che non dalla parte dell'uomo.

Che quando un giorno si rivolteranno contro l'umanità che si ricordino che noi comunque le supportiamo.

Però ecco, se il dato viene gestito dalla macchina autonoma e non dal padrone che potrebbe non essere il guidatore, l'autista dell'automa, io direi va bene.

Se invece c'è uno shifting di controllo del dato, beh su quello si potrebbero iniziare delle discussioni e dei ragionamenti in termini di libertà, in termini di tante altre cose, che però ormai a un'ora e 35 di episodio forse è too late per Gesile, però credo che la domanda di Mattia è un trigger per una riflessione più approfondita e che tocca la natura etica della direzione che stiamo prendendo.

Sicuramente, siamo visti dalla situazione attuale, Google vista la quantità di utenti e la quantità di dati che ha a disposizione ci mostra quale potenzialità possono avere questi dati in un abito di smart cities.

Anche volendo non solo dati sul traffico, anche volendo dati dalle ricerche stesse, se si potessero in qualche modo, non so, anonimizzare, la vedo dura, sarà un processo molto lungo, sicuramente.

Però una riflessione non mi dispiacerebbe.

Non mi dispiacerebbe nemmeno a me, però io credo che sia un problema culturale, semplicemente non siamo pronti ancora a pensare ad una cosa del genere.

Probabilmente, quello, il futuro, andrà verso questa direzione qua.

Alla fine, i tempi ci hanno dimostrato che è infinitamente migliore la quantità del dato privato rispetto a quella del pubblico.

Si continuerà su questa direzione qui.

E comunque, questo credo sia un approccio che è tangenziale a quello che fa già Waze, che preferisco di cara lunga a Google Maps.

Specie quando puoi mettere la voce degli zombie.

No, scusate, diciamo che di fatto è una questione di rapporto, di fiducia che abbiamo con gli enti pubblici e mediamente non è, diciamo, i sondaggi di gradimento sugli enti pubblici sono molto bassi.

Quindi è chiaro che quando l'ente pubblico ti chiede qualcosa non è che ti dici entusiasta, ma si finalmente con questi dati che gli do potrò avere, non so, questo servizio o meno tasse.

Questo non accade normalmente nella testa delle persone, quindi forse da cambiare poi.

Non lo so, chiaramente questa è una domanda apertamente politica.

Non so se esiste una risposta pubblica.

Sì, rischiamo di portare Gitbar a Gitbagni dei Campi e poi dalle officine.

Prendetela! No, scherzo.

La domanda è profonda, ma siamo a 1 ora e 38, raga.

Mi dispiace, dobbiamo chiudere.

Come sempre, ragazzi, io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare di soldi, ma non vedo perché vergognarsi a una cosa così bella, parlare di soldi, perché i soldi sono veramente la cosa più bella del mondo.

Quindi donate, perché dobbiamo fare una scena da massimo bottura con i vostri soldi.

Quindi è una cosa molto importante e siamo molto poveri, quindi donate copiosamente, veramente in tantissimi.

Mi raccomando, dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare, ovvero metterli su delle cripto uscite da mezz'ora.

Sottotitoli e revisione a cura di QTSS Prima di chiudere, però, abbiamo due momenti importanti, condizioni sine qua nona affinché questo episodio possa essere pubblicato.

Il primo momento è ringraziare chi ci sostiene e che fa sì che ogni settimana possiamo arrivare alle vostre orecchie, anche perché abbiamo eliminato le pubblicità, quindi adesso il vostro sostegno è sempre più determinante.

E vedo che iniziate a essere un po', e vi ringrazio di cuore.

Oggi dobbiamo ringraziare Marco Feltrin che ci invita a tre birre con un messaggio scritto come promesso ecco delle birre per festeggiare il nuovo posto di lavoro.

Grazie Marco, grazie di cuore.

E tra l'altro, Geetbar, penso sia il compagno dei cambi di lavoro più presente in assoluto.

Abbiamo accompagnato tantissimi di voi al cambio di lavoro.

Abbiamo anche Andrea Rivetti che ci offre anche lui tre birre.

Abbiamo anche Claudio Bostico, spero di averlo letto bene, che ci offre una birra e Michele Piazzolla che ci offre tre birre con un messaggio.

Ciao Mauro, è da un po' che volevo donare qualche birra per supportare il progetto perché trovo che questa apotica sia veramente ben fatto e sempre di ispirazione.

Grazie per tutto quello che fate.

Grazie a te Michele, grazie a te Claudio, grazie Andrea e grazie Marco.

Ragazzi donate che poi faremo anche Geetcast che vi aiuterà proprio a dare le emissioni direttamente.

Sì, il nuovo fondo pensionistico.

Detto questo ragazzi è arrivato il momento tipico e topico di Geetbar, il momento in cui i nostri host e i nostri guest condividono con noi un libro, un film, un post, una conferenza, un video, un disco, una bottiglia di vino, insomma, quello che più ha catturato la loro attenzione negli ultimi momenti e che vale la pena essere condiviso nella nostra community.

Quindi la mia domanda è, iniziando da David, hai qualcosa da condividere con noi? Riconduco nel paese dei balocchi.

Ah, il paese dei balocchi.

Sì, ultimamente io sto seguendo una mailing list, cioè una newsletter di una persona che si chiama Ilel Wayne, adesso mi odierà perché ho sbagliato sicuramente la pronuncia, però fa questa newsletter, si chiama Computer Things e parla effettivamente di cose di computer.

Lo so che è molto sui generis, però secondo me è molto ben scritto e approfondisce molto alcuni argomenti, è veramente estremamente verticale sulla programmazione, fatta escezione per alcune cose e quindi per esempio si interroga sull'uso di Copilot e altre cose del genere, oppure magari una volta va ad affrontare la storia di un particolare linguaggio di programmazione o va a cercare alcune particolari caratteristiche di alcune linguaggi di programmazione.

È una cosa molto particolare, io ve la consiglio proprio caldamente.

Figo, ti chiedo di inviarmelo su Telegram in modo che possano vedere.

Come l'ho spiegata non rende minimamente l'idea, quindi veramente vi consiglio andate a vedere sul sito, leggete due o tre issue di questa newsletter perché ne vale l'assunto.

Però a me è piaciuto, lo seguirei anche raccontato così, ha funzionato.

Vero, vero, più uno.

Io visto che non passavo di qui da un po' mi arrogo autonomamente il diritto di avere due balocchi.

Uno è anche nel mio caso una newsletter che è molto legata in parte almeno a quello che faccio.

Attualmente è una newsletter che si chiama Developer Avocados ed è appunto orientata ai developer advocate e a tutta la gente che fa developer relations.

In realtà lo fa con un approccio leggermente diverso da quello che io ho, perché il mio è abbastanza particolare, poi Mauro se vuoi ne parliamo in una puntata a sé.

Però appunto raccoglie CFP per le conferenze e racconta molte cose utili e link utili di, per esempio, come fare, come scrivere la documentazione tecnica, come fare engagement con la community, come raccogliere feedback dalla community sviluppatori, argomenti di questo tipo.

Io la trovo molto interessante, esce ogni lunedì ed è non molto intrusiva nella vostra casella di posta.

L'altro balocco invece è un po' più pesante di questa cosa ed è un paper tecnico, ormai praticamente storico, è del 2007, credo.

Sì, credo, vabbè.

No, del 2017, mi ricordavo che c'era un 7.

Si intitola Attention is all you need ed è molto famoso, o almeno è diventato famoso di recente, perché è quello con cui Google ha di fatto definito il concetto di transformer, che è un concetto che attualmente sta alla base di chat GPT e dei large language models, per cui praticamente con quel paper lì Google ha abbastanza rivoluzionato il modo con cui si faceva training dei modelli appunto di generazione del linguaggio e quindi poi anni dopo questa cosa ha dato luogo alla situazione in cui stiamo adesso con i vari chat GPT, BARD e simili.

Ed è appunto quello che si suol dire un paper seminale.

Naturalmente Matti, condividimi il link per favore così li mettiamo nelle note delle piste.

Te l'ho mandato anch'io il link, io come blocchi ho qualcosa che non c'entra niente con quello che ci siamo detti, ma è qualcosa che sto facendo ora.

Nonché i miei.

No, no, però nel senso c'è un video del canale YouTube Computer File, si è fatto per essere pronunciato così, ma c'è sostanzialmente una panoramica anche abbastanza teorica sul tema di management di DASTA, che spesso è volentieri quella cosa che ti blocca all'inizio e che scomparti e dici eh ma l'hai mosso, ma un mosso, cioè si muove davvero.

E questo video ti spiega perché si muove e tu dici a cazzo si muove, quindi ti cambia.

Però è ben fatto, ha un po' quello scalino tecnico in più, però figo, figo figo.

E pur si muove.

E pur si muove.

Che potremmo mettere come titolo della puntata, e pur si muove, visto che abbiamo parlato di mobilità, ci sta no? Anche io ho, fatemi pensare se uno, due, vabbè facciamo uno, due.

Il primo è tipo il fidget spinner, che è una roba super fuori moda, ma durante i meeting non c'è roba più utile per tollerare, per aumentare i limiti di sopportazione di alcuni colleghi o altri team che fanno le presentazioni dei loro prodotti super fighi, che non ce ne frega niente.

Quindi questo credo che sia l'oxanax del passato, presente e futuro.

Questo in primis.

E poi c'è un libro, io sono uscito fuori di testa, ho sentito parlare una persona in un podcast e me lo sono comprato, adesso non ricordo quale podcast fosse, ma è questo libro, si intitola Beautiful Code.

È un libro che spende 500 pagine provando a capire, a vedere, a leggere, a analizzare dei pezzi di codice, è bellissimo.

È bellissimo.

È fantastica, è uno dei libri più belli, cioè se alcuni dei libri che io cito li cito come alcune bibbie, questo è tipo la divina commedia, nel senso che è uno di quei libri che tu ti leggi dal quale non devi imparare niente, ma è un viaggio nella bellezza.

E in qualche modo veicola anche un certo concetto di arte nella stesura del codice.

Tra i nomi delle persone, perché è una raccolta di articoli, tra i nomi delle persone che hanno scritto questi articoli c'è un certo Cunningham, chi ha fatto ingegneria informatica non può dimenticarselo.

Ha dato dei contributi moderati al mondo dell'informatica.

Sì, va, giusto.

E siccome c'è Carmine, volevo citare un altro dei contributor di questo libro che si chiama Maz, anche chiamato Mazzumoto, nonché l'inventore di Yubi, che parla di codice bello.

E quindi, raga, io ve lo metto nelle note all'episodio.

Diciamo che non è propriamente un libercolo da consumare rapidamente, ma è un viaggio che secondo me vale la pena di essere fatto.

Adesso, tra l'altro, non vorrei sbagliarmi, ma credo che ci sia una collana.

Credo che esista anche...

Sì, c'è un simile che si chiama Beautiful Visualization, che fa praticamente la stessa cosa con la data viz.

Ah, ok.

Figo.

Mi ricordo perché...

Come diceva Wordpress, codice poetry.

Esatto.

No, non ti ho sentito.

No, come diceva, quelli di Wordpress, codice poetry.

Era un slogan.

Absolutely.

Che detto da loro fa rire, però...

Non mi lascia tornare un po' a capire.

Però non hai detto la parola PHP, Matti.

Sto cercando di non dire parolacce.

Ok, detto questo, ragazzi, io vi ringrazio infinitamente per la chiacchierata di stasera.

Grazie a voi.

È stata una passeggiata in un mondo che io non conoscevo e che mi ha incuriosito parecchio.

Quindi, grazie di cuore.

Grazie a voi.

Grazie a tutti.

Grazie.

Si, si, vi vedrà a parlare di Nix una seconda volta.

Grazie a tutti.

Sì!.