Bene e benvenuti su github un'altra settimana e un altro ospite ma come ogni settimana vi tengo un po sulle spine E non lo svelo subito anche perché l'ospite di oggi è un altro ospite super Speciale ma prima di dirvi il nome di chiacchierare con lui vi ricordo rapidamente i nostri contatti siete sempre entrati in contatto con me utilizzando la mail a info@github.it o twitter @itbrainrapper Ma ormai l'unico canale vero per entrare nel nostro gruppo è il gruppo telegram che trovate semplicemente cercando et github gruppo telegram super affollatissimo iniziamo davvero a essere tanti vediamo un po quanti siamo 169 membri ad oggi quindi iniziamo a essere una bella famigliola Tra l'altro si parla del più e del meno per esempio oggi c'era una bellissima discussione su quel buco nero senza via di uscita che vim riusciremo poi a uscire è così facile uscire da vim La famosa battuta pillola rossa o pillola blu mi sa che siamo finiti nella tana del bianconiglio detto questo io lancio la sigla quindi come direbbero nel gruppo ispiro dico Bene, benvenuti e lancio la sigla e ritorniamo subito dopo con il nostro ospite 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 [Musica] Oggi ho con me, naturalmente un ospite come vi dicevo prima, super speciale.Per presentarlo posso dire che scrive Java ma legge Assembly, ha un berretto rosso sull'armadio, è Principal Software Engineer a Red Hat e si occupa prevalentemente di messaging.ciao Francesco benvenuto ciao ciao ciao a tutti mi stavo incasinando leggendo la presentazione io mi ero concentrato sullo speciale perché è sempre sai quella parola politicamente scorretta che mi fa pensare ok sono speciale no no non intendevi in quel senso allora potrei dire anche parzialmente conterraneo? Esatto sì, effettivamente sì, nella parte migliore.Allora Francesco ti faccio subito una domanda giusto per capire un po' chi non ti conosce, chi sei fondamentalmente.Quindi dovendoti guardare allo specchio come ti definiresti? Diciamo un tizio complicato perché alla fine ho iniziato con linguaggi ad alto livello nella mia vita professionale.Anzi, esattamente sono stato l'uomo delle scommesse sbagliate, perché ero quello che all'università, quando c'era il corso di TCP, il protocollo di rete, ha detto "sta cosa di internet non prenderà mai".E poi si è studiato l'intelligenza artificiale, ho lavorato anche un po', ovviamente non prendendo un becco di un quattrino, alla fine ho detto "ma sai che ti dico, neanche questa a futuro!".Alla fine sono andato nel mondo della consulenza.Negli anni successivi ho sviluppato una passione per nello scendere a basso livello e capire cosa succede sotto il cofano, fino a che mi sono ritrovato che il cofano lo vedo ben distante alle volte quindi siamo a quel livello.Quindi scendi veramente in in profondità.Come ho detto prima tu sei principal software engineer a Red Hat ma qual è il tuo ruolo cioè cosa fai tutti i giorni in azienda? Ah ok questa è una cosa che anche io mi chiedo spesso.Allora di base ovviamente ho un manager come tutti che mi dicono "guarda, abbiamo questa feature, abbiamo questi utenti che hanno bisogno di questa mano".Quindi assolutamente un software engineer infatti come tanti altri.Quello che cambia al massimo sono un pochettino la tipologia di problematiche che mi trovo ad affrontare.Spesso abbiamo casi in cui hanno bisogno di avere su un portale con un milione di connessioni insieme e il mio ruolo è quello non solo di sviluppare la parte software che aiuta a far sì che questa cosa avvenga, ma fare tutto il profiling delle performance che aiuta a capire cosa è andato storto, perché c'è sempre qualcosa che va storto.Non nei prodotti Red Hat, no sto scherzando, però scherzi a parte sì, è abbastanza comune.Poi questo è quello che faccio per il 90% del mio tempo, poi c'è il resto del tempo che è un 90% ancora, che sono il jolly dei miei colleghi per quanto riguarda le cose di performance, quindi problematiche, non lo so come funziona la JVM, come funziona il sistema operativo o ancora meglio, insomma diciamo che questo è un po' il mio lavoro quotidiano.interessante quindi quando ho detto scrivi in java e leggi in assembly è per quel motivo perché ti spingi a andare cosa succede a vedere cosa succede sotto il cofano e su questo cosa succede sotto il cofano ci andremo a fare una lunga chiacchierata oggi per capire in realtà quanto noi dobbiamo essere coinvolti nelle dinamiche che succedono appunto sotto questo cofano ma non mi porto avanti prima del tempo e ti faccio subito una domanda Mechanical sympathy, io non ne sapevo l'esistenza prima che tu me ne parlassi quindi ti chiedo che cos'è la mechanical sympathy? Ok, diciamo secondo me il modo più semplice per descriverla è l'analogia proprio che ha portato alla creazione, credo proprio, del termine che poi è stato ripreso anche nell'ambito informatico, ma questo termine è nato nell'automobilismo, quindi se pensiamo al preparatore di auto e all'autista, una persona che guida l'auto e contemporaneamente conosce bene a fondo come l'auto funziona, ha una marcia in più nel capire che cosa sta succedendo, è in grado anche di sedersi sulla macchina, sentire la vibrazione del sedile, il motore che rumore fa ed è in grado in questo modo di fare delle scelte informate mentre sta guidando.Questo ovviamente in contesti in cui c'è anche la reattività di mezzo, di guida, fa sì che un vantaggio del genere potrebbe essere completamente in completamente obliterato dalla necessità di essere reattivi nel fare questa cosa, ma nell'informatica non c'è questo problema, perché nell'informatica sapere di più non ha mai fatto male a nessuno, anche se fino in fondo fa male all'ego, spesso e volentieri.Questa è una cosa su cui sia assolutamente da dover fare i conti quando si parla di questa Mechanical Sympathy che rapportata al mondo dei computer significa questo, significa dire solo uno sviluppatore, quindi il mio lavoro non è il performance engineer, ma io mi chiedo dietro quella riga di codice che ho scritto che cosa succede e da lì si apre ovviamente un mondo, un buco nero, la tana del bianco nidio perché puoi scendere a un livello assolutamente folle, assolutamente folle, fino ad arrivare a come dice un mio caro amico Fusco, fino a spaccare il beat, perché letteralmente spacchi il beat in quel caso.Però diciamo è una curiosità, può chiedersi come sono fatti gli effetti speciali nei film.Sì, quindi in poche parole per Mechanical Sympathy si intende il prendere coscienza di dove stai posando il sederino quando stai andando a sviluppare qualcosa che è senza dubbio una cosa che andrebbe fatta al di là della parte meccanica della macchina quindi della parte più ferrosa della macchina quindi CPU, disco c'è un movimento molto interessante che è il movimento frameworkless che propone un altro livello di astrazione visto che noi davvero abbiamo il sederino seduto su millemila livelli d'astrazione, dice "Ehi, tu stai usando un framework, ma hai provato a capire che cos'è quello che stai usando? E dal mio punto di vista questo tipo di sensibilità ti aiuta a non essere solo il manovale del codice, ma essere qualcosina in più colui che prende delle decisioni un po più consapevoli però quello che ti chiedo io è essendo un buco nero una voragine che poi ti assorbe e noi abbiamo una quantità limitata di risorse e abbiamo degli obiettivi molto pratici da raggiungere qual è il limite l'equilibrio che dice ok da questo momento in poi non scendo più perché se no entro nel buco nero e non esco se se esiste un modo per individuare questo limite.Pillola azzurra fine della storia domani ti sveglierai in camera tua e crederai a quello che vorrai.Pillola rossa resti nel paese delle meraviglie e vedrai quanto è profonda la tana del bianconiglio.Se lo trovi dimmelo.No scherzo, scherzo.Però allora diciamo che perché anche lì è molto dipendente dal lavoro e dalla propria curiosità personale e ovviamente il mix del tempo a disposizione.Quindi a livello lavorativo avere la capacità di sapere indossare il cappello da manager di tanto in tanto ti permette di avere una forma di pragmatismo nello scegliere quanto tempo dedicare a queste cose è rapportato al beneficio che sicuramente ti fa fermare molto prima di grattare il fondo, sempre che ci sia un fondo in questa cosa.Di sicuro questa capacità aiuta a dimensionare quanto scendere a fondo.Invece dimenticandosi del cappello del manager, vestendo solo il cappello dell'ingegnere, del programmatore, dell'informatico o semplicemente della persona curiosa, dipende quanto puoi dedicare al lavoro di questo tempo.Se non è il tuo lavoro, allora diventa tempo extra, che i programmatori lo dedicano all'aspetto dell'informatica.Bisogna capire quanto questa cosa ti sollazia, quanto ti incuriosisce.Io ti posso raccontare la mia esperienza, passando dall'intelligenza artificiale, che per definizione viveva sprecando watt e watt per fare riconoscimento della lettera A, a passare a un mondo nel quale ti chiedi veramente quante volte stai andando a far dormire il processore, insomma il salto è enorme.Però ti dirò che mi ha fatto rivalutare molte cose e molte astrazioni ad alto livello, solo per il fatto che performano male in un'implementazione, ma che sono decisamente il male e che non ha nessun senso che siano state mai implementate, a meno di essere di puri artifici matematici che sollazzano un matematico.Lo so, è una posizione forte, scomoda, chiunque mi segue su Twitter credo che può cercare Linkedlist a caso e troverà a me che insulto qualcuno sui link del list che io stesso ho usato in vita mia e le uso tuttora.Però il principio è che ti dà consapevolezza nella scelta delle cose, a volte un po' di più di quella che vorresti.Però in fondo, non lo so, io ho trovato modo di guadagnarci, poi è quello il trucco.Se quella cosa davvero ti appassiona così tanto, la fai follemente, la fai spessissima, allora chiediti, ma forse non è il caso che diventi il mio lavoro? Probabilmente qualcuno nel mondo la troverà utile.Il problema è cercare a chi è utile.In questo modo stai sicuro che se anche gratti il fondo ti ringrazieranno.Certo, hai parlato di Linked List.L'altro giorno mentre stavamo chiacchierando tra di noi mi è venuto in mente, quando mi raccontavi appunto e mi parlavi di Linked List, una frase del tipo "Linked List is the new Comic Sans".però raccontaci un po' del perché questa tua antipatia verso le linked list.intanto cosa sono le linked list giusto per dare un po' di contesto e poi il perché tu vedi le linked list in quel modo? allora diciamo che di base è una struttura dati fatta a nodi, questi nodi possono essere collegati attraverso di loro con dei reference next e previous per muoversi al nodo precedente o al nodo successivo oppure solamente next o solamente previous a seconda della link del list e permette di avere sia un accesso granulare in una specifica posizione aggiungere in testo o aggiungere in coda È una delle strutture dati che spesso i morentieri viene fatta implementare nei primi anni di informatica per abituare i programmatori a come si programma.Ed è ok, nel senso che si fanno tante cose quando si è piccoli.Io mi mettevo il dito nel naso e mi davano uno schiaffo.di un certo punto, diciamo.No, no, detto così, non so, sonno già male.Allora, vi spiego però perché c'è tutta questa antipatia nei confronti di questa roba.Però parto prima con un aneddoto brevissimo su cosa può portare farne a meno.Allora, c'è un prodotto di Red Hat, questo non è un disclaimer di vendita, è una roba che ha dovuto fare per lavoro.Si chiama Dispatch Router, ma non lo so pronunciare.Guarda, se lo dici a me io sbaglio tutti gli accenti.Comunque è un coso che fa comunicare dei dispositivi IoT, se vogliamo renderla breve la spiegazione.Fatto stare, è implementato in C, e chiunque l'ha implementato sa che in C non c'è necessariamente il GearBase Collector quando allochi la memoria dovresti utilizzare quello che si chiama un allocatore l'allocatore è un algoritmo ci sono vari allocatori di vario genere e chiunque ha sviluppato questo dispatch router Qpid dispatch router si è detto "ma sai che ti dico?" "io non userò l'allocatore" "no, non lo farò" perché so che posso riutilizzare gli oggetti che ho fatto.Come faccio a riutilizzarli? Li metto in una Linked List dopo che ho finito.Però sarà una Linked List speciale, questa è particolare, dovete cercarla in giro perché non si trova, si chiamano Intrusive Linked List.Cos'è di speciale l'Intrusive Linked List? Che è una Linked List in cui nodo, cioè non c'è il concetto di nodo, tu sei il nodo.Quindi se vuoi aggiungere un elemento, quell'elemento deve avere next e previous.Quindi se noi stiamo facendo una linked list di persone, non avremo la struttura dati persona e la infiliamo nella linked list e ci sarà un nodo che la mantiene.No, sarà persona che avrà un next e previous alla stessa link.Insomma, diventa lei il nodo.Perché in questo modo dicono "Ah, ah, ah!" perché così risparmio di creare il nodo.Allora, questa roba bellissima, che sembra un'idea genialissima, è la base del motore grafico di Doom 3.Quindi Doom 3, le versioni prima di Xbox, per chi non lo conoscesse, è la terza iterazione di un gioco storico in cui si spara.È fidissimo.La storia dietro questa linked list è che è stata utilizzata lì, è utilizzato all'interno del kernel di Linux e questa specifica Intrusive LinkedList insomma, facendola breve ho fatto una sessione di profiling mi hanno detto i sviluppatori che sono sempre all'interno del team di messaging "guarda, non riusciamo a far scalare questo prodotto" "va male di performance" io, odiando le LinkedList, ho indicato "Ah, io penso che sia questo!" e loro "Ma va, ma questo roba legge dalla rete, scrive dalla rete, figurati se è quella!" Bene, l'ho sostituita con una cosa che è una linked list in cui i nodi sono degli array, quindi è una linked list che ammortizza un po' il fatto di non avere nodi dappertutto e magicamente il doppio delle prestazioni, il doppio è tanto per 12 righe di codice.Quindi sono stato bravo io? No, io odio LinkedIn e LinkedVista.Chi è che è stato bravo? È stato bravo il creatore di Doom 3.Perché il creatore di Doom 3, quando ha fatto il porting verso le nuove console, quindi Xbox 360 e PlayStation 3, del motore grafico di Doom 3, ha creato una cosa chiamata Postmortem di Doom 3 BFG, mi pare che si chiami la versione, c'è in internet, in cui dice "la colpa è la linked list" e io, non è che mi sia diventato qualcosa, ho letto questo bellissimo manuale e ho fatto "bazza, la colpa è la linked list" e ora arriviamo, quindi nel dubbio se ve lo sostituite va sempre bene.Ora vi dirò il perché però.Il perché è molto più semplice di quello che non sembra, è che la CPU è stupida, la CPU è estremamente stupida, soprattutto nell'accesso alla memoria.Cosa significa? Che se tu hai un nodo, quindi abbiamo il nostro nodo della link e del list e vogliamo navigare al nodo successivo e noi fino a che non siamo in quel nodo non possiamo leggere il campo next, giustamente.E se vogliamo andare a quello ancora successivo, a loro volta dovremmo arrivarci prima il successivo.Una volta arrivato potremmo leggere il next a sua volta.Ovviamente dobbiamo tenere presente che indipendentemente dal linguaggio, ma stinodi, dove sono nella memoria? Io intendo dire, ma sono vicini tra di loro? Sono lontani? La risposta è che non si sa, magari sono vicini, magari no.e quello è il problema maggiore perché le CPU, come ho detto, negli accessi non sono molto intelligenti quindi se devono leggere un punto devono muoversi almeno vicino a quel punto e in più, quando operano su un'area di memoria non operano alla dimensione di pochi byte ma in una quantità pari a quella che si chiama la linea di cache perché esistono le cache nelle CPU queste linee di cache sono generalmente 64 byte quindi in 64 byte quanti nodi ci posso trovare? se sono nodi di una linked list, dipende dove si trovavano in memoria se fosse un array, per esempio, è un bel po' perchè se supponiamo che ogni singolo elemento dell'array sono 4 o 8 byte fai subito il conto che sono un bel po' e oltretutto se voglio muovermi al precedente e al successivo elemento di un nodo, di un nodo in un array, è solo l'elemento primo o dopo, quindi sono già lì.Quindi diciamo questa è un'applicazione un po' di questa meccanica al simpatico, ricordarsi che la CPU non ragiona a singole aree di memoria piccole, non può speculare dove spostarsi a caso, ma solo nell'intorno, cioè nella località di memoria, di dove si trova, perché non puoi immaginare dove si troverà dopo e applicando questa cosa dici "ma allora perché erano fatta queste linked list? Ma quanto può andare peggio rispetto a una unread list? Il in quanto peggio dipende molto dall'ambiente, dalla CPU o altro.Nel caso specifico di quel prodotto il doppio era il collo di bottiglia maggiore, perché tutto il resto era fatto estremamente bene, ed era almeno il doppio più veloce.Generalmente può esserlo ancora di più.Quindi questo perché tanto odio su Dell'Incadrino, è colpa di Doom.colpa di doom fantastico no però dal discorso che stai facendo mi viene una domanda e la mia domanda è ma io che lavoro ad alto livello io che sono uno sviluppatore php uno sviluppatore javascript uno sviluppatore scala uno sviluppatore comunque ad alto livello come posso approcciare a quella consapevolezza che è la bandiera della mechanical Sympathy sventola perché quello che dici tu no della linked list può sembrare molto lontano molto in basso Nella voragine io per esempio tutto una serie di astrazioni tra me e quella linked list non sto sviluppando in c quindi come posso iniziare ad avvicinarmi a quel mondo è in realtà proprio il discorso del profiling è un buon modo perché come ho detto il profiling è proprio uno accanto di che cosa succede.Il primo passo è dire "ma succede qualcosa di strano? Succede qualcosa che non mi aspetto? Perché questa parte funziona male?" Quindi nasce tutto da una domanda, la domanda nasce da una necessità a sua volta, quindi se tutto va bene non ti poni la domanda.Allora a quel punto se è per hobby puoi supporre che immagini che qualcosa non va bene, quindi per un tuo piacere di investigazione inizi quel profiling e ti accorgi che c'è qualcosa che non funziona bene.A volte riesci a isolarlo, perché è chiaro nel profiling che il problema è là.Allora da là si parte a infilarsi coi gomiti proprio, a volte fino al collo, in tutto quello che sono le astrazioni che ti separano, che è un lavoro tedioso, soprattutto se sono tante, ma è un lavoro illuminante, perché di tanto intanto ti accorgi come il problema non è di performance, il problema è di API, spesso e volentieri, perché l'API è un bias mentale che si costruiscono le persone per darti in mano un linguaggio che sia semplice da maneggiare.Il linguaggio di dominio che esprime il fatto che l'oggetto persona ha una certa operazione legata ad esso.La modalità in cui tu fai fruire queste API crea un bias che nel caso in cui quello che c'è sotto funziona molto diversamente prima o poi stride e questa cosa spesso e volentieri impatta proprio sulle performance.Anzi, le performance spesso e volentieri nascono da una cattiva comprensione di quello che c'è sotto perché hai voluto coprire il gatto con l'interfaccia cane e gli hai voluto far fare bow.Ok, lo può fare, ma magari non è nella sua natura.A molte questo stridere non ha bisogno di arrivare fino al metanical sympathy.Te ne accorgi quando una struttura dati drappa altre 12 strutture dati e la modalità con cui opera su queste strutture dati è magari troppo ridondante, ti accorgi che crea delle inconsistenze, ci sono ripetizioni, codici ripetuti ovunque, dati che vengono copiati ovunque.Quando capitano cose di questo genere uno si deve chiedere, ma questa situazione che mi ha costruito è corretta? Sarebbe potuta essere fatta in un modo diverso? Chiaro, a volte non è il tuo lavoro farlo, ma a volte sta a te creare un nuovo codice e è lì che entra in campo il fatto che cose come la semplicità del porre l'API giusta, che in modo naturale riesce a risolvere il problema, spesso e volentieri piace poi anche all'hardware e la riduzione dei livelli di astrazione è un buon modo, spesso e volentieri, per capire questa cosa.Quindi il movimento free work less lo capisco, lo capisco anche se potrei dire magari per o magari per lavoro, perché a volte per questioni di deadline capisco benissimo che non si può fare meno di un framework, ma conoscere quali sono i punti sensibili di un framework, quelle cose che è meglio che non fai perché non performeranno come ti aspetti, beh quella comunque è una cosa utile, credo.Sì, da questo punto di vista ci tengo a ricordare un video che ho visto qualche tempo fa che era un'intervista anti-Rez a Salvatore Sanfilippo fatta dal mio amico Francesco Sciutti dove si parlava appunto di complessità e Salvatore Sanfilippo diceva in redis ci sono stati dei...soprattutto di astrazioni dice in redis ci sono stati dei passaggi dove scientemente volontariamente ho deciso di schippare tutti i livelli di astrazione cercare di rimanere più basso possibile per ottenere con la semplicità che la macchina mi riesce a dare ok il 5 è il caso gli riusciva a dare per rimanere più vicino al modo in cui la macchina ragiona rispetto all'uomo come ragiona.Tra l'altro su questo hai ragione tu quando dici guarda che nell'api quindi nei livelli di astrazione per rimanere più generico ci possono essere dei bias di chi ha costruito quel linguaggio d'astrazione dei modelli mentali di chi ha costruito quei livelli da strazione perché quando tu approcci a quei livelli da strazione quei modelli potrebbero non coincidere con i tuoi e ti ritrovi a fare qualcosa che noi sviluppatori conosciamo bene che ne so la famosa il concetto il famoso concetto di ed è del del tuo amored no usare uno strumento un tool un elemento nel modo molto diverso dal quale è concepito su questo ne parlavamo l'altro giorno si va a creare quel famoso percorso dalla meccanica al simpatico quindi più che andare a esplorare cosa ci sta sotto a livello di meccanico nel senso un pochino più stringente del termine mi piace più immaginarlo come avere la consapevolezza del contesto dove stai giocando no Quindi puoi anche non sapere come si muovono le rondelle ma sul fatto che sotto hai un differenziale quel differenziale Fa quella cosa poi come funzionerà il differenziale all'interno lo puoi esplorare solo se ne hai bisogno però devi sapere che il differenziale ti aiuta non tanto o non solo a capire perché non sta funzionando bene ma anche a sapere come usarlo quindi mi piaceva proprio il concetto di mechanical sympathy engineer engineer Empathy quindi quando tu capisci il contesto entri in empatia con chi ha sviluppato quella strazione sul quale sei seduto quindi capisci cosa aveva in mente quando è andata a realizzare a realizzare quel livello di astrazione fino ad arrivare a un livello di mechanical serendipity che è un po la scoperta delle dinamiche a più basso livello di te che tu scopri scopri e ti porti su come delle bolle che risalgono al tuo livello di complessità e riesci proprio a raggiungere l'obiettivo naturalmente questo percorso non è indolore e non è gratis e devi capire fino a quanto ti puoi spingere.Io faccio l'esempio del javascript capire che cos'è un task, quindi un macro task e un micro task ti aiuta a capire delle cose che succedono e tu dici "ah ma javascript è uno schifo vedi non si capisce niente di quello che fa" in realtà se tu sai o vai a guardare come funzionano alcuni elementi sotto il cofano poi alla fine capisci, anticipi la macchina anticipi, per macchina intendo il livello di astrazione sottostante e tutti a seguire e quindi riesci a performare meglio riesci magari a scrivere meno codice perché ti liberi di livelli di astrazione e riesce a raggiungere tutta una serie di traguardi tra l'altro la questione della mechanical sympathy mi piace perché in realtà non è molto lontano da un concetto che noi possiamo portare che ne sono l'uso del corpo umano se tu guardi gli atleti tutti gli atleti Sanno, professionisti comunque, chi si spinge a certi livelli, sa benissimo come gira la loro macchina, il loro corpo.Esattamente, ma anche dei piccoli rudimenti di scienze di nutrizione, ma proprio il minimo indispensabile per non fare delle castronate.E questa cosa diventa poi un'attitudine in qualche forma, che nasce dall'abitudine, se uno inizia ad applicare questo comportamento, che a livello lavorativo è utilissima.Se capita di utilizzare un framework è giusto concentrarsi sul problema di dominio, ma più conosci il framework, più qualcuno sarà risposto a chiamarti esperto in questa cosa.Non ti deve piacere, devi conoscerlo, devi capire cosa fa, quali sono le motivazioni che lo hanno portato a essere in quella forma.Non esiste l'affezione, esiste solo il fatto che la guidi e vorrai capire qualche volta se è accesa o spenta.Bisogna capire quelle due o tre cose.Poi nel momento in cui diventano di più, subentra un discorso di lavoro, se quello diventa il tuo lavoro, se no diventa piacere personale se uno lo vuole fare.Di base sì, è veramente una cosa applicabile a tanti livelli e si applica in altre discipline diverse dell'informatica.Perché noi abbiamo le deadline strette, abbiamo il mercato che che spinge sulla verticalità.Pensare che qualcuno sia trasversale rompe tutte le leggi del mercato, perché ci si chiede come lo incasello, come lo pago.La cosa importante è che tu decidi come vieni pagato, non lui.Se tu fai decidere al mercato, difficilmente riuscirai ad avere quello che ti serve, sempre che il livello economico è quello che ti ma detto tra di noi è anche una questione di soddisfazione che ti permette di aggiungere varietà a livello lavorativo è una forma di varietà come altre come affrontare problemi diversi So che la chiacchierata vi sta piacendo veramente tanto ma io inizio non so voi a sentire un po di Persura e penso con me anche franz quindi è il momento di bere una birra birra che c'è stata invitata Da due ascoltatori questa settimana due membri della nostra community il primo è aleron 75 che ci invita alla birra e quindi noi brindiamo Alla sua salute e dice io io beviamoci su e poi stefano sorrisina invece ci invita a tre birre scrivendo complimenti per il podcast e per il gruppo telegram il vostro livello di skills mi ha fatto capire Che sono ignorante come una capra e mi sta spronando a migliorarmi e imparare cose nuove Allora stefano sappi che siamo tutti ignoranti come come delle capre Infatti mi sa che cambio un po il nome del podcast lo chiamerò git farm scherzo comunque ognuno di noi è ignorante in qualcosa in ambiti specifici per esempio oggi franz ci sta parlando di mechanical sympathy e io non ne sapevo veramente veramente niente così come buona parte di quello che i nostri ospiti ci raccontano negli episodi quindi siamo tutti nella stessa barca e siamo tutti qua per scambiarci tra di noi informazioni e crescere.Gitbar è fondamentalmente questo.Detto questo però, la mia gola è *cof cof* abbastanza asciutta, quindi bevo anch'io queste birre alla salute di Stefano e di Aleron e continuiamo la nostra chiacchierata.Voglio per un attimo eh...farti una domanda, questa è una domanda personale.io per tanti anni ho lottato contro l'ottimizzazione prematura.Adesso col ragionare in termini di mechanical sympathy non lo vedi un po' come ripartire col concetto di ottimizzazione prematura? Allora diciamo che il culto originale sull'ottimizzazione prematura viene sempre riportato sulla prima frase, nel senso di non bisogna ottimizzare prematuramente, però c'è il resto del quote, che include anche la percentuale in termini di effetto che può avere su un progetto.Se un progetto è scritto ex novo, tutto il codice che tu stai scrivendo a un valore che tu sai bene come viene inserito all'interno del contesto del progetto.Quindi sai perlomeno se sarà codice caldo, codice che viene eseguito di più, non è pure infrastruttura e a maggior ragione se stai scrivendo pure infrastruttura chiaramente ti devi porre il problema delle performance, perché non hai la più pallida idea di chi la utilizzerà quella roba, per cosa la deve utilizzare, a meno che sei sicuro al 100% che l'infrastruttura che stai andando a creare è in un progetto che non è assolutamente performance critical, ma non essere performance critical non vuol dire performance sucker, bisogna ricordarsi che c'è quel giusto bilanciamento.Riguardo al mechanical sympathy, come ho detto è una questione di abnegazione di sé, in in fondo.Cioè tu devi conoscere la macchina conoscendo te come sei fatto.Quindi quando scrivi codice devi essere a conoscenza che ci sono dei pattern che funzionano male e capire quanto andare ad assecondare la macchina in questa cosa.È semplicemente un livello di consapevolezza in più, non implica che tutto il codice che scrivi debba necessariamente essere ottimizzato, ma che nel momento in cui lo vuoi scrivere ottimizzato sai che alcuni principi di base funzionano, ma alla fine solo la misurazione è in grado di dirti se quello che hai fatto è veramente valido, solo il profiling è in grado di dirti se all'interno del contesto in cui quello che hai fatto verrà eseguito, quello che hai fatto è una buona idea.Mi spiego meglio, se una persona fa una pagina web e per qualche ragione accede troppe volte, costringe ad accedere troppe volte alla rete quando non ce n'è bisogno, non si può parlare di ottimizzazione prematura, è semplicemente una buona idea.Lo stesso si può dire per quanto riguarda il Mechanical Sympathy, è una buona idea che hai lì, decidi tu quando applicarla e come applicarla, ricordandoti sempre che hai dei bias e quindi che la macchina non fa quello che vuoi tu, la macchina crede che lo faccia, ma poi devi misurarlo per saperlo e qui entra un altro buco nero che è il benchmarking, che è un'ulteriore cosa rispetto al profiling, è uno strumento utile per abbattere i propri bias, per incominciare a avere piano piano con gli anni quella sensibilità che ti aiuta a capire che hai sbagliato e in realtà a un certo punto dici "vabbè, ok, facciamo una cosa, misuro così almeno sono tranquillo" e quasi sempre va a finire così.Quindi ottimizzazione prematura va centelinata, come tutte le cose, alcune cose davvero davvero davvero è molto raro che funzionino bene.È bellissima l'immagine che hai dato col benchmarking io per un attimo ho pensato quando che ne so raggiungi 70 anni quindi quel livello di esperienza tale dove non sei più disponibile ai compromessi e quindi se una cosa non la vuoi fare perché sai che è sbagliata ma non esiste il compromesso dice le cose in faccia come il nonno che non ha alcuna paura a dire che sei un idiota quindi questa era l'immagine che mi è venuta mentre appunto raccontavi questa cosa.Ti faccio una domanda oggi viviamo in un contesto cloud native e il concetto di avere la percezione, l'illusione di avere tutte le risorse che si vogliono con uno schiocco di dita tende ad allontanarci un po' dal concetto di dire "sì vabbè tutte le risorse ma cosa sta succedendo quando perdo le risorse" secondo te come in un contesto cloud native si può cercare di alimentare quel tipo di consapevolezza? Quello aggiunge ulteriormente un altro livello di indirezione, che in realtà se ci pensiamo in questo enorme ciclo che è l'informatica, è un po' come funzionato quando è stata creata la memoria virtuale, il concetto di memoria virtuale, perché una volta quando si programmava il computer la RAM andava da 1 a 10 e se tu allocavi 11 non c'era un Tu dovevi nominalmente dire quant'era lo spazio a disposizione.L'illusione dell'infinito esiste solo in matematica, non c'è nessun dubbio e quel genere di astrazione è un'astrazione che parli.La memoria virtuale non è tanto diversa dalla containerizzazione, dal cloud native, dalla virtualizzazione, questa impressione di avere tutte le risorse a disposizione, quando ovviamente non le hai.La questione è come prima ho detto per il profiling, il profiling si basa sul cercare di spaccare il capello cercando lo spreco della risorsa che ti è più cara.Qual è la risorsa che ti è più cara? Quella che paghi.Qual è la risorsa che paghi? Dipende dal provider, quindi pensiamo a WS per esempio, quanto costa il tempo di CPU.Ammazza, costa un botto ragazzi, costa un botto.Se vuoi le CPU molto veloci, tanti core.Vuoi tanta RAM? Magari è quella che ti costa di più.Quindi, tramite degli strumenti appositi, sapendo l'ambiente in cui giri, sarebbe opportuno monitorare quelle risorse.Una volta viste quelle risorse e come vengono utilizzate dal tuo programma, allora puoi iniziare a porti il problema di cosa ho fatto di sbagliato nel modo in cui questo programma gira per me.A volte pare una banalità, ma per esempio, vi faccio questo esempio che addirittura con la programmazione quasi non c'entra perché è una cosa da DevOps, è da DevOps, però mi è capitata.C'era un cliente, di cui non farò il nome, che si lamentava che quando faceva girare su OpenShift dedicando 0.6% della CPU di un nostro applicativo spendeva un sacco di corrente ed era lentissimo, molto più di quanto non avrebbe mai immaginato l'applicativo.Addirittura aveva delle pause questo applicativo che moriva proprio.Allora i support gli hanno detto "e che fai, aggiungi un core".Quindi gli ha dedicato un core in più, Alla fine aveva un core a 0.6 e un altro a 0.8 quindi hanno utilizzato CG Group per sapere quanto dedicare a questo applicativo e ancora faceva schifo e allora sono stati costretti ad andare all'ingegneria quindi dal support la palla è passata all'ingegneria e io ho detto "ma cosa state utilizzando?" stiamo utilizzando un ambiente runtime con java la macchina java è runtime, fa un poto di cose ha un compilatore poi oltre che un compilatore ha il GameBase Collector il compilatore che esco qua similmente a quello di javascript V8, non so quale possa essere quello di adesso lui ha bisogno di far girare tante volte il codice e quando è caldo fa partire una serie di macchinazioni, di ottimizzazioni e produce del codice ottimizzato.Sì, ma chi è che la fa sta roba? Cioè, se il tuo programma sta già facendo qualcosa e sta sfruttando un core per rispondere, che ne so, alle richieste di una pagina web, chi è che lo fa sto lavoro di compilare? L'altro core, che era lo 0,6, Sì, ma c'è anche la memoria che viene allocata e allocata.Ahia! Quindi abbiamo bisogno di tre operazioni concorrenti.La compilazione, l'esecuzione vera e propria del programma e il garbage collector.È chiaro che se competono per le medesime poche e scarse risorse, quell'applicativo faceva schifo.E nel fare schifo ci metteva di più a rispondere.E se ci mette di più a rispondere vanno tutti in timeout.e se lo hanno tutti in timeout tutti risottomettono la richiesta.Il cliente non paga.Cioè quello che succede è che il cliente è insoddisfatto, c'è un consumo a lungo termine enorme di risorse di CPU perché tu non riesci mai a rispondere a queste benedette richieste e tutto nasceva dal bisogno solo di dedicargli le giuste risorse.Un'investigazione di questo tipo nasce appunto, se vedi spanna tutti i livelli, spanna dal dire chi esegue cosa, a chi interessa questa cosa, quindi nasce da un problema, da una necessità e cosa posso fare per cambiarla.Quindi in realtà si è esorto con una flag del JDK in cui ho rallentato un po' il compilatore e ho detto senti datti una calmata, non c'è bisogno di ottimizzare tanto qui, lui ha consumato un po' meno CPU, io ho dato un po' di più dissi più la macchina ed è andata liscia.Questo è nel caso in cui quelli sono quel genere di problemi.In altri è puro green computing, quindi voler consumare di meno perché se si consumasse un po' di meno risparmia i soldi e oltretutto distrugge un po' di meno l'ambiente per la dissipazione del calore.Quindi ci sono una serie di ragioni per cui può valer la pena fare questa cosa.Guarda, quando hai parlato di soldi più che di ambiente penso che hai catturato l'attenzione di molti anche perché le fatture di AWS penso che siano una cosa che...AWS o di Google o di Redshift sono una cosa che conosciamo bene tra l'altro su questo concetto ho letto un articolo dove si diceva che in realtà la cancellazione dei dei guadagni che l'industria dell'informatica fa lavorando sull'hardware è praticamente annullata da tutto ciò che invece è la strazione che poi si va a costruire sopra per capirci ci facciamo la macchina sempre più veloce per caricarci, che ne so, per fare le portiere di piombo fondamentalmente.Si, si, è un buon esempio.Ma infatti, addirittura, se vogliamo proprio essere un po' più insomma, provocare su questo argomento, ci sono un articolo che avevo letto da poco che mi ha lasciato abbastanza scioccato, che è stato "Se tutto il codice Python utilizzato su AWS per l'intelligenza artificiale venisse tradotto in Rust, ci sarebbe più o meno un risparmio del 600% di corrente elettrica.600%! È una cosa infinita.Si tratta di due linguaggi che per quelle 8 chiamate che fai a librerie di intelligenza artificiale, il problema non del linguaggio, è il problema dell'utilizzo del framework che c'è sotto.Insomma, cambi il chiamante, hai un risparmio esagerato di corrente.E già quello mi ha lasciato scioccato.Ma c'è un bellissimo quote di un ragazzo tedesco di cui non sono in grado di ripetere il nome che è "Internet is running in debug mode".Questa cosa è curiosissimo.Si ce ne ha parlato, ha cennato, anzi poi entriamo nel dettaglio se ci dai qualche informazione in più perché noi su internet ci lavoriamo e quindi è carinissimo approfondire la cosa.Ce ne ha parlato Luca, ce l'ha cennato Luca Molteni il tuo collega nell'episodio 50 quando abbiamo parlato di sviluppo web.Dicevi? Si perché diciamo a A me è capitato spesso per uno dei progetti, per cui capita che sono un committer, non lo faccio di lavoro, è proprio piacere personale, si chiama NETIC, un framework per lo sviluppo sul networking, quindi TCP, UDP, HTTP eccetera eccetera.Mi è capitato di scrivere diversi algoritmi per l'encoding e il decoding di testo e nell'utilizzare molti protocolli tra cui stomp, websocket o qual dir si voglia anche http l'utilizzo della trasformazione in testo che sia hash, utf8, utf16 o qual dir si voglia è un incubo a livello algoritmico è un incubo ma la CPU spende un sacco di tempo per fare una roba che dovrebbe essere letta solo in caso di debug perché far parlare due macchine col testo non ha nessun senso, perché le due macchine si capiscono sulla base di un accordo, di un contratto.Il contratto che è in forma di testo o in forma binaria non fa nessuna differenza, ma è utile per l'ispezione, è una cosa molto utile in fase di sviluppo, quindi idealmente i sistemi dovrebbero avere questa modalità debug in cui si scambiano dati testo, in chiaro, perché tutto sommato sono esseri umani che vogliono capire che cavolo succede.E poi una modalità binaria, oppure ancora meglio, possono scambiarsi sempre i dati in modalità binaria, ma noi abbiamo dei bellissimi editor binari che ci trasformano in testo solo quando dobbiamo ispezionare le cose.Quindi uno sforzo "minimo" perché supportaresti un solo tipo di formato un enorme risparmio di corrente, ma enorme, si parla proprio di veramente tanto, tanto tanto.E allora la mia domanda è automatica e la domanda è perché secondo te? E' proprio perché per questo discorso del mechanical symbol, è un discorso non scomodo, ma un discorso che chiunque ha realizzato ogni passo avanti a livello di protocolli, a vari livelli, sono figure ingegneristiche, tecniche completamente diverse e spesso e volentieri chiunque ha lavorato all'università o ha studiato si renderà conto facilmente quanto i reparti tecnici parlano pochissimo tra di loro.intelligenza artificiale, non parla con ingegneria del software, non parla con database, non parla con eccetera.Cosa significa? Che a un certo punto ognuno va a coltivare il proprio articello, quindi nel momento in cui viene creata la tal cosa utile, una volta fatta è fatta, funziona.Quindi il ritornare sui propri passi e risvilupparla in una maniera che queste risorse matematicamente che sembrano infinite in realtà sono decisamente finite, è uno sforzo che ci si chiede se ne vale la pena, ma bisogna ricordarsi che tutte queste cose nascono quasi sempre o in ricerca pura o ricerca orientata allo sviluppo, quindi non nascono e sono in produzione, c'è sempre una fase di ricerca, quindi se si poteva pagare quel costo di rifarla bene, valeva la pena farlo in quel momento.Adesso è chiaro che non si può abbiasimare nessuno.Il castello è troppo alto praticamente.Esatto, esattamente.Quindi diciamo che quando era fatto bisognava comunicare di più probabilmente tra di loro le persone, abnegare se stessi, quindi dire "sì sono fico, ma potrei essere più fico" e arrivare con il passo successivo.Anzi, dai tempi in cui è stata esposta la legge di Moore si sapeva che prima o poi queste risorse avrebbero avuto un termine, un po' come il cioccolato, il cacao che sta finendo, è in bagna della Nutella, poi vediamo quando finisce.Il problema è quello, prima o poi finirà, è un problema degli altri, è un problema futuro e qua si rivale nel discorso dell'empatia.Quindi empatia con gli esseri umani, a chi ci sarà dopo.Quindi dici che questo sviluppo di consapevolezza sarà l'elemento portante di quella resilienza tecnologica che ci permetterà, una volta raggiunti i limiti Soil, e lo sappiamo quali sono i problemi.Problemi sono per esempio del riscaldamento delle CPU e quant'altro.Quindi si arriverà a un momento dove in realtà rischieremo di avere un arresto di sviluppo da quel punto di vista.Sì, o perlomeno finché esisterà qualcuno disposto a pagare per queste risorse scarsissime, allora andrà bene, diventerà sempre più in Italia, mentre c'è stato un momento in cui tutti potevano avere una macchina su AWS, ma quando incomincerà il riscaldamento globale o qualsiasi cosa, rendere questa risorsa una risorsa preziosa, scarsa, ma di cui tutti hanno bisogno, ma pochi saranno in grado di pagare, come si farà? È un po' apocalittico, però il problema è un problema reale.Il movimento del green computing esiste ed è un movimento che ha decisamente senso e non verrà certo risolto da Apple M1 che è un po' più efficiente, perché finché ci scambiamo i stringoni di testo a voi è che utilizzi M1.Però questo è una posizione molto forte da assumere, però come ogni grande rivoluzione è fatta di piccoli passi, quindi già iniziare nel proprio piccolo a preoccuparsi del proprio orticello, cercando di risparmiare anche, che sicuramente non fa male a nessuna in azienda è un modo per guadagnare e alle volte è proprio il modo giusto anche che fa bene anche all'ambiente.Si, si concordo.Discorso fighissimo devo dire anche perché nasconde quel velo etico, quell'obiettivo etico che beviamo tutti dalle bottigliette di vetro per non fare plastica e poi abbiamo i bitcoin minati quindi in realtà un po' di strada sullo sviluppo di quel tipo di consapevolezza necessariamente farlo quindi questo percorso come dici tu puoi iniziare appunto dal provare a capire in quale contesto mi sto muovendo quando sto facendo la mia web application basta guarda si faceva il ragionamento ricordo leggevo dell'energia risparmiata mettendo google a fondo nero un esempio stupido no? però in questo contesto pienamente calzante perché già utilizzando quel tipo di piccolo trick perché è un piccolissimo trick ci rendiamo conto di quanto può essere possiamo...in realtà non so se esistono degli strumenti che misurano convertono in performance che ne so il risparmio che tu fai nella tua applicazione in Watt o qualcosa del genere? Allora io sapevo che c'era una cosa del genere però ti posso dire che non l'ho mai utilizzato anche perché vabbè ripeto ho la fortuna che devo fare tuning davvero su macchine dei clienti a volte non è fine tuning perché i clienti, quelli veramente grossi ce li hanno già quelli bravi bravi di ingegnero però di tanto in tanto è una prima scrematura alle cose più folli, la diamo direttamente noi dell'ingegneria e in quei casi rimani scioccato dei risparmi che puoi avere.Hai un cliente che ha 40 macchine su AWS, tu fai risparmiare all'anno il 10% che è un'inezia a ciascuna di esse, un milione di dollari, chiaro non mi entrano in tasca a me, però wow, davvero? Per un'azienda piccola non è il milione di dollari, è il migliaio, ci paghi le pulizie.La questione è che a seconda dei casi sarebbe bello avere una metrica che ti dice precisamente il risparmio nel fare quella cosa specifica, però con una buona attitudine, arrivi a metà anno, le bollette lo scopri subito.È un po' come a casa, si chiama l'economia domestica, quel principio del saper fare le cose in maniera tale che risparmi, non c'è guadagno migliore, letteralmente, si sa che è così, vale la pena.Poi le performance arrivi a giustificarle facilmente quando ti permette di risparmiare.Sì, la cosa che mi chiede in realtà è che la nostra professione nasce concettualmente dal concetto di hacker, dove l'hacker è colui che vuole esplorare, perché hacker non è colui che è il pirata informatico, hacker è colui che vuole esplorare come funziona la tecnologia per piegarla ai suoi obiettivi.Un po' si è perso questo approccio.Sì, ora siamo un po' più noi che siamo asserviti alla tecnologia, ma lo si evince anche leggendo il curriculum vitae.Io non scrivo che sono un programmatore, dico che sono un Java programmer e questo è male, non va bene.Sto mettendo quello come modo per identificare, perché è la casellina con la quale il mercato ha bisogno di identificarsi, se ci identifica ci può dare un valore, se ci può dare un valore ci può confrontare, se ci può confrontare in qualche modo siamo gestibili.L'hacker nel senso passato del termine senza essere il cracker, quello che rompe le cose, ma l'hacker è quello in cui è molti-paradigma, molti-tutto, è la sua mentalità che lo rende un programmatore, non il linguaggio.L'apertura alla scoperta.Esatto, e lo dico in maniera del tutto ipocrita, perché come ho detto io conosco tre linguaggi, quattro se aggiungiamo la bash, sono proprio Java, Assembly, conosco un po' di Rust, C, Shell e ciò nonostante ho in video ogni giorno i miei amici che mi parlano di Unkotlin, altri miei amici che mi parlano di Scala e quello è un percorso che è un multiparadigma che ti aiuta ad allontanarti da quella casellina che si chiama Java Programmer, JavaScript Programmer o addirittura chi ti identifica col nome del tuo framework che usi che wow davvero cioè e poi ma allora non diamo neanche un nome o un cognome a questa persona diamine.Il problema è che il mondo tecnologico non so se è un bene o un male però è un dato di fatto si è frammentato talmente tanto che alla fine I livelli di astrazione perché si è frammentato e ogni frammento ha sviluppato n livelli di astrazione tali per cui se tu sviluppi in react e sei un react programmer ok non è detto che tu sia un javascript programmer O sei un senior che hai sbattuto e guardato in X tempo di esperienza o in X WTF che hai urlato chiuso nel tuo ufficio, hai guardato cosa c'era sotto il cofano e sei andato a esplorare che cos'è un virtual dom no? per dire altrimenti tu hai quel livello di astrazione che sono già tante perché basta guardarsi la solo la documentazione di react e poi tutte le librerie a corollario io faccio sempre la battuta degli state manager, no? C'è sono ne avrai sentito parlare in senso ironico, no? 70.000 state manager per fare la stessa cosa quindi dici ne devo conoscere almeno almeno 3-4 per essere un react prog...si vabbè ma e poi non conosci l'event loop per dire e quindi è questo che ti rende poi questa frammentazione, questa stratificazione di complessità che si è accumulata ti rende meno sviluppatore, quindi meno artigiano e più manovale.Esattamente, perché vieni identificato solo con lo strumento che utilizzi e il prodotto che fornisci.La tua identità scompare in quello che fai, non in quello che sei.Non parliamo di qualcosa a livello esistenziale di complesso come la mia emotività, stiamo parlando di una cosa molto più semplice, le mie skill, che è quello che ho tra le orecchie, non è che sono in grado di pigiare sulla tastiera.Il mio consiglio, non so quanti ascoltatori siano giovani o non siano giovani, ognuno ha sicuramente la propria storia, il merito, ma io sono passato veramente dalla consulenza più becera alla ricerca più spinta, finendo poi in redat e ho ancora una strada sicuramente strana e lunga davanti a me, ma quello che ho imparato è che ne vale la pena, la curiosità ne vale la pena, è una cosa che non vogliono chi ha compagnie molto grandi in genere, se non sono compagnie sane, per lo meno, non vogliono che sviluppi, ma se sono compagnie sane capiscono quella tua curiosità e quella che fa sì che col tempo invecchi come un buon vino e non come il latte, perché è quello che succede.Invito le persone a esplorare, che sia Mechanical che sia un multiparadigma, seguite la curiosità.Vedrete che poi avrete un ritorno, se non nella qualità di quello che fate, avrete un ritorno sapendovi guardare intorno, che qualcuno darà un estremo valore a questa cosa.E ci sono, c'è chi lo fa.Assolutamente sì, secondo me è appunto il fatto di magari usare qualcosa ma esplorare cosa ci sta sotto, capire cosa stai usando perché lo stai usando è quello che ti rende libero è quello che ti rende veramente libero non schiavo di uno strumento anche perché diciamocelo lo strumento domani o il framework domani potrebbe non esistere.Allora tu che fai? E allora tutto quell'effort come lo capitalizzi? Sì, devi diventare padrone della metodologia che ti porta a fare le cose che fai, piuttosto che del punto di arrivo.Questa è una cosa che addirittura sfunciamo nella cultura indiana, che in fondo è che il percorso è il tuo punto di arrivo.Il tuo punto di arrivo è è solamente uno dei passi del tuo percorso e questo vale tantissimo per i linguaggi.Quindi qualsiasi metodologia che hai affrontato per vedere sotto il cofano, guardare i lati del cofano, guardare sopra e sotto, quella resterà sempre.Sempre.E' quella che ti permetterà di passare ad un altro linguaggio di programmazione.Farne uno forse, chi lo sa.Lasciare l'informatica e fare qualcos'altro con la stessa metodologia? Esattamente.e ritorna esattamente nello stesso modo.A me viene in mente di questa cosa un bel articolo su The Morning Paper, quindi se vi interessa cercatelo.L: sì, se lo linki, magari mi mandi il link, lo mettiamo nelle note del mio episodio.F: sì, sì.Allora è un articolo interessantissimo su una legge matematica che è stata dimostrata da poco che si chiama la Universal Scalability Law.In questo momento io so che se c'è qualche mio collega d'ascolto dirà "mazza e palle".Però effettivamente è una cosa molto fica e ti mostra come esiste una legge assolutamente intuitiva che si applica benissimo nella programmazione concorrente come si applica nella gestione dei team.Questo per quanto riguarda il fatto di dire switchare da un lavoro all'altro, sapendo bene il modello sotto come funziona, quanto ti può tornare utile.Riassumendo solo le parti più interessanti di questa legge, perché è molto interessante, dice che un sistema scala, dove scalare significa che a fronte di un maggior carico di lavoro sei in grado di soddisfare questo carico di di lavoro, aggiungendo un numero di risorse che non sia esponenziale, se ci sono una serie di fattori che vengono soddisfatti.Uno di questi fattori si chiama la contesa delle risorse, mentre l'altro si chiama la coerenza.Ve li spiego brevemente perché sono molto interessato.Facendo il paragone con i gruppi di lavoro.Quindi sei in un'azienda, hai un gruppo di informatici sotto di te e ti diverti con la metodologia agile.Quindi dici "ma sai che ti dico, facciamo scrum meeting ogni giorno, 20 meeting per far sì che le persone capiscono cosa stanno facendo e finito lo sprint di lavoro, più o meno corto quello che è, poi oltretutto divido in maniera completamente legale le cose che sono da fare e faccio sì che si creano i cosiddetti "temper programmers", i programmatori che sono in grado di caricarsi una gran quantità di lavoro perché è bello e meglio in intima, è un classico, il cosiddetto genio dello sviluppo, questa è una situazione che ho visto tante volte in molti ambienti di lavoro.Questa legge matematica dice che un sistema non scala bene in maniera lineare se ci sono delle risorse contese cosa sono le risorse contese? un esempio potrebbe essere il Temper Programmer quindi hai quel programmatore bravissimo tu lo carichi come un mulo di lavoro perché giustamente è quello che te sa fare tutto e cosa succede? che le richieste vengono accodate primo problema sicuramente non può scalare quindi è meglio averne un po' bravi non uno bravissimo Se poi c'è uno bravissimo, beh, venga! L'altro problema è, abbiamo detto, fattore di contesa sempre.Qual è l'altro modo in cui c'è maggiore contesa? Potrebbe essere se c'è uno specialista, perché vuol dire che tutte le richieste specialistiche passano da lui, e a un certo punto si accodano.Mentre se tutti sanno un po' di tutto, multi-paradigma, il sistema scala meglio.Poi c'è un'altra cosa, la coerenza.Che cos'è la coerenza? Bene, immaginiamo che io sto fabbricando una cosa nella quale mi serve la massima concentrazione e ogni 4 minuti e mezzo viene qualcuno, mi bussa alla porta e mi fa "Franzi, come va? Tutto bene? Vai? Oh sì, sì, grande, bella.1, 2, 3, 4, 5…" inizia a passare il tuo tempo a essere bloccato per comunicare a qualcun altro lo stato del tuo lavoro.Sono due robe banalissime.Esiste un foglio externo nella Universal Scalability Law in cui in base a quanto ci stai mettendo a fare un progetto, in base a quali risorse specialistiche hai, tu sei in grado di stimare come reagiresti se il carico di lavoro dovesse aumentare, è matematica.Questa roba funziona nelle strutture dati concorrenti, nei protocolli di comunicazione, le CPU funzionano così, hanno questi problemi di scalabilità e gli esseri umani.Quindi avere ben chiaro quali sono i modelli che muovono la realtà senza che la stragano in una maniera banale, ma che invece esprimano in una maniera più chiara quali sono le dinamiche che ci sono sotto, è qualcosa che puoi riciclare in qualsiasi lavoro.Che dovessi avere figli, speriamo, che dovessi avere un team di persone sotto di me, che io sia una parte del team, alzerò la mano e dirò al mio capo "senti, basta con questi scrambini, non riesco a lavorare, non riesco neanche a pensare".Quindi ci sono tutta questa curiosità del capire come funziona sotto la realtà, che io, come hai detto, tu hai assolutamente ragione, torna utile, si ricicla questa cosa.Mi ricorda i frattali, che li trovi in natura dappertutto, è dell'elemento che ritorna in praticamente ovunque e dici "ma che cos'è?" Allora è un'ulteriore astrazione questa che riesce a rappresentare il tutto, però in realtà si sono quelle dinamiche che poi fanno parte immagino di come funziona il nostro mondo e alla fine ritorna.Si parla di risorse, si parla di consumo delle risorse, si parla di produrre qualcosa e si parla di questi pochi elementi che a un certo livello d'astrazione poi sono sempre gli stessi.Sono sempre quelli sì sono d'accordo.Comunque è fighissimo questo articolo se mi mandi link lo condividiamo poi nelle note dell'episodio.Franz io non so come ringraziarti ma non ti lascio andare almeno non prima di averti chiesto se hai una risorsa, un articolo, un libro, un qualcosa che puoi condividere con noi e e che in qualche modo ha segnato la tua vita, la tua carriera di sviluppatore e conduco nel paese dei balocchi aaaah il paese dei balocchi eheheh niente a ridere perché allora quello che mi ha condizionato di più è un libro che non c'entra assolutamente nulla con l'informatica uno di quelli che ti danno al liceo o al distrito tecnico ed è "Sidarta" di Herb Agassi A me ha proprio cambiato a ogni livello la vita, perché in tutti i momenti in cui ho riletto questo libro, ogni qual volta ho trovato una lezione che mi è stata estremamente cara e ho potuto applicare, perché avevo io di più la visione del contesto di cosa stava succedendo nella mia vita, di come interpretare, avevo gli strumenti per interpretare che cosa mi voleva dire questo libro.Questo come libro in senso assoluto, ma immagino che pensi che molti se lo siano trovati davanti.Invece nel campo informatico, allora, vi spiace perché mi fai una domanda e io te la apro come un frattale, in realtà sono due.Allora, uno è Computer Architecture e Programmer Perspective.È molto lungo, si trova anche gratuitamente, dove intendo dire non che si ruba sul torrent, davvero gratuitamente.Ed è uno di quei libri terrificanti da mille passa pagine.Io lo rileggo ogni due anni, più o meno ogni tre, perché mi ridimentico tutto quello che c'è dentro, ho una persa in memoria.Praticamente è l'esempio di Mechanical Sympathy per eccellenza, cioè lui parte da un programma in C e ti dice che cosa succede fino ad arrivare all'esecuzione nel registro, passando per il sistema operativo, passando per la memoria virtuale, passando tutto.Quello ti fa tutto, quello a me ha condizionato tantissimo perché mi sono detto "Ma quanto è profonda 'Statana del Bianconiglio'?" Poi ho visto il numero di pagine e ho pensato "Ammazza, è profonda!" Ma io quanto ci metterò a capirla? L'affronti a piccole parti.Quel libro a me ha cambiato tanto e lo consiglio caldamente.Anche la prima edizione veramente già solo il fatto di sapere che esiste il sistema operativo, alle volte è è wow! Invece un altro libro è proprio quello relativo alla Universal Scalability Law, che si chiama The Guerrilla Planning.Premetto che avendo avuto una formazione anche in ambito universitario come ricercatore, un po' di statistica la masticavo, ma questo libro non è fatto per chi mastica statistiche, è fatto per chi vuole capire alcune cose e ti spiega in modo anche un po' macaronico la statistica, ma ti spiega quella roba che avevo detto prima, la Universal Scalability Law, quindi è un libro di Neil Gunther, che è uno dei creatori di questa teoria e ti spiega come applicarla a tutto, come se fosse la cosiddetta teoria del tutto, perché si applica effettivamente in tanti contesti.Quello a me ha cambiato tanto, per lo meno capire che esiste.Poi ovviamente non ci capivo una mazza di statistica, ma va beh, l'importante è cogliere il messaggio.Assolutamente sì, puoi distillarla e farlo tu.In un solo occorso hai riempito circa due mesi e mezzo o tre mesi di lettura.Mi derominate! *musica* Franzo io non so veramente come ringraziarti ci hai aiutato a vedere qualcosa che in realtà alle volte diamo per scontato o mea culpa facciamo finta di non vedere e questa cosa secondo me aiuterà molti a porsi delle domande che è l'ottimo punto d'inizio nel momento in cui noi ci poniamo le domande e iniziamo il percorso che è il fame, come hai detto prima tu visto che alla fine l'obiettivo è solo la benzina che deve aiutare a costruire quel valore che è il percorso quindi detto questo io ti ringrazio infinitamente grazie per aver condiviso con noi questa esperienza lo dico un po' in stile ecco gli s**ti anonimi ma fa nulla in un git bar fa stride un pochino ma va bene uguale e niente allora noi ci noi ragazzi noi della community ci riserviamo il diritto di romperti le scatole ogni tra qualche qua non tra un po' di tempo per chiederti se hai qualcosa di nuovo da raccontarci ma volentieri anzi è stato davvero davvero un gran piacere il piacere è tutto nostro Francesco vi ricordo rapidamente i contatti info@gitbar.it via email @brainrepo su twitter o nel gruppo telegram @gitbar se l'episodio vi è piaciuto ricordatevi che se avete un device apple potete aprire l'applicazione podcast e lasciare una recensione.Detto questo, da Lione è tutto, alla prossima, ciao! Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] [Musica]
