Bene e benvenuti su Gitbar, anche questa settimana un nuovo episodio in nostra compagnia.Chiedo scusa per il ritardo ma è solo, solo colpa mia.Infatti sto preparando il trasloco per rientrare in Francia e quindi il mio tempo è risicatissimo.Però grazie agli ammutinati anche questa settimana, per colpa mia con un leggero ritardo, riusciremo ad avere il nostro episodio.Prima di introdurvi all'episodio il mio compito, come ormai sapete, è quello di ricordarvi i contatti.Info? Chiuso alla github.it la nostra email @brainrepo il nostro recapito twitter ma soprattutto, anche se ma soprattutto non si dice, il nostro gruppo telegram la nostra famiglia dove tutti i giorni chiacchieriamo tra di noi, ci scambiamo informazioni ma anche cazzeggiamo lo trovate prendo il client di telegram e cercando gitbar tra l'altro ci avviciniamo al numero fatidico numero fatidico di 500 ascoltatori infatti in questo momento siamo 495 quindi ancora un po' di amici e saremo pronti per il numero magico 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 Eccoci qua, eccoci qua.Questa settimana andiamo a parlare di libri.Ognuno di noi ha infatti la sua libreria personale, il suo archivio di stimoli, come lo chiamo io.E in realtà per una puntata proviamo a trasformare GitBar da bar dove si parla di informatica a caffè letterario, nel nostro piccolo naturalmente, e con estrema modestia.E quindi condividiamo un po' di libri che ci hanno in qualche modo cambiato la vita professionale e personale.E voglio iniziare io con un libro molto interessante che ho letto qualche tempo fa il cui nome è "Micro front end in action".è un libro molto carino che in qualche modo introduce al mondo dei micro front-end non deve essere preso come una guida esaustiva bensì come un'introduzione a un mondo che passa da prima verso utilizzando appunto delle implementazioni che io avevo già visto nella mia esperienza lavorativa ma che mai ho chiamato micro front-end per poi arrivare a utilizzare delle tecniche e dei framework che in qualche modo sono un pochino più moderni.Manca di una parte che è tutta la parte di webpack utilizzato nell'ottica dei micro front-end però in qualche modo introduce.Lo fa in un modo molto pratico con la creazione di una applicazione, un e-commerce di trattori in quel caso ma comunque ci costringe il lettore a in qualche modo applicare quello che sta imparando e l'ho trovato molto molto interessante.Poi molti di voi sanno che io sono un wannabe functional programmer e quindi ogni tanto mi vado a cercare dei libri che in qualche modo mi possano accompagnare nell'esplorazione del mondo della programmazione funzionale.In realtà ne ho letto tanti ma comunque i concetti rimanevano fumosi nel senso che via via che le cose si complicavano diventava difficile schematizzare, io sono poi uno molto schematico, tutte le cose che venivano e calarle da un punto di vista pratica.Ho trovato un bellissimo libro introduttivo per la functional programming si chiama "Groking Functional Programming" un libro molto carino perché in realtà ha una particolarità fa parte di tutto il filone di Groking se non mi sbaglio è dito da Map che ha la particolarità di essere un libro in questo caso parzialmente illustrato quindi c'è degli schemi e dei disegni che aiutano nella comprensione.E tratta l'argomento functional programming in modo crescente ma sempre con degli esempi pratici esempi che se non ricordo male sono fatti in scala ma comunque super comprensibilissimi.Inizia parlando delle funzioni pure, delle mutabilità per poi arrivare a concetti come la programmazione sequenziale e la gestione dei side effects con io per poi alla fine arrivare a parlare di stream e di programmazione concorrente ricordo che questo libro una volta comprato ha poi diciamo un suo mirror all'interno del sito di mia me app penso si lega così è un sito che oltre al libro quindi lo potete leggere anche dal computer all'interno di questo sito vi permette di avere una sorta di discuss al lato per discutere delle parti specifiche del libro e spesso interviene anche l'autore quindi è comunque interessante perché oltre al libro ho acquistato anche qualcosa di più fondamentalmente.Sempre nell'ambito della programmazione funzionale vi cito perché non posso fare altrimenti domain modeling made functional di scott sblashing sicuramente non si legge così il cognome ma nessun problema però non vi dico niente perché di questo libro ve ne parlerà Alessio dopo.L'unica cosa che vi dico è che è stato il miglior libro tecnico che ho letto negli ultimi due anni.Nel top della classifica c'era "Implementing domain-driven design" il libro rosso che era super prolisso ma essendo un libro che parlava dell'implementazione c'era da aspettarselo.Naturalmente Modeling Made Functional ha preso, diciamo, il trono, l'ha soffiato, appunto, al libro "Implementing DDD".Con questa parte voglio finire quei libri tecnici e voglio aggiungere altri due libri che però di tecnico non hanno nulla.Tutti o quasi tutti sapete che da poco è nata l'hambda e una delle mie esigenze era quella di capire come gestire questa bimba all'arrivo.Allora un libro che mi è stato utile è stato...adesso vi farà ridere, ma "The Baby Owner's Manual".In realtà che cos'è? È un libro che è a metà tra un articolo tecnico, un tutorial su Medium e le istruzioni dell'IKEA e spiega fondamentalmente come approcciare al bambino o alla bambina nel mio caso in modo molto pratico fondamentalmente è una fac romanzata e illustrata e con un sacco di disegni soprattutto fatti molto bene e anche con una bella dose di ironia se avete dei bambini piccoli o se li state per avere mi raccomando leggete questo libro perché vi farà pisciare dalle risate ma allo stesso tempo vi insegnerà un pacco di cose.Inizia parlando della preparazione e dell'allestimento prima dell'arrivo del bebè e poi parla della cura generale, dell'alimentazione tra l'altro è bellissimo perché tratta il bambino, assimila il bambino a un qualunque dispositivo meccanico o elettronico e queste similitudini, questa appunto questo paragonarlo a un dispositivo fa sorridere ma allo stesso tempo fa capire che il bambino di per sé è un sistema complesso e noi in quanto ingegneri sviluppatori siamo abituati ad affrontare i bambini e ad affrontare i sistemi complessi quindi perché un bambino dovrebbe spaventarci tra l'altro è bellissimo perché c'è tutto un capitolo che spiega come il titolo è "Programming Sleep Mode" cioè come programmare il bambino per il sonno oppure manutenzione generale dove è spiegato come cambiare il pannolino insomma è molto molto carino se avete la possibilità buttateci un occhio perché secondo me ne vale la pena e voglio finire questo mio piccolo blocco lasciando spazio anche ai miei colleghi ammutinati parlandovi di un altro libro che per me è eccezionale Il libro si intitola "In the back of the napkin" tradotto sarebbe "Nel retro del tovagliolo" esiste anche una versione italiana e questo libro non fa altro che insegnare a rappresentare le proprie idee.Una cosa che faccio spesso è quella di scarabocchiare quando penso.Bene, quando si scarabocchia esistono diversi modi per poterlo fare.Esiste un modo controllato e con tecnica e un modo libero.Il modo controllato con tecnica ci permette di aggiungere un valore a quel pasticcio che stiamo facendo.Un valore che può essere utilizzato su due filoni.Il filone dello sviluppo delle idee e quindi di tutto il lavoro che facciamo nello sviluppo del nostro pensiero e poi il filone della vendita di queste quindi del comunicare con l'altro.Io nel mio ufficio qua in Sardegna ho una lavagna lunga 4 metri e alta quasi 2 e il compito è proprio quello di trasformare quella lavagna in uno strumento per la comunicazione.La lavagna l'ho acquistata subito dopo aver letto questo libro perché? Perché in realtà mi sono reso conto che non è necessario essere un artista per saper comunicare con le illustrazioni ma è necessario capire quello che si fa sul foglio per esempio già utilizzando le forme noi possiamo dare un significato a quello che stiamo pasticciando oppure basta semplicemente governare le dimensioni per dare una certa importanza aggiungere informazioni a quello che stiamo scarabocchiando.Grande, piccolo, lontano, vicino, a destra, sinistra, davanti, dietro.Tutte queste cose che noi possiamo scarabocchiare e soprattutto non dobbiamo essere artisti per poterlo fare ci aiutano da una parte per rappresentare in modo chiaro le nostre idee per noi stessi, dall'altra per riuscire a comunicarle in modo efficace.Allora, premettiamo che Mauro non ci ha dato alcun preavviso sulla produzione di questa puntata, quindi me, come gli altri ammutinati, andremo a braccio, almeno spero di non essere l'unico ad andare a braccio.Io sono, direi, avido lettore ma non così tanto rispetto a altre persone che conosco e leggo soprattutto cose non solo tecniche ma anche di crescita personale quindi la mia lista dei libri sarà molto sarà molto varia per quanto un campione di quattro può essere molto vario.Inizierei con il primo che è "Factfulness" che non so nemmeno pronunciare di Hans Rosling.I motivi per cui lo cito è perché mi ha aiutato a eliminare il rumore di sottofondo delle cose negative che ci vengono addosso in ogni momento della nostra giornata.Se pensate ai titoli dei giornali, ai titoli dei telegiornali o di qualsiasi fonte di informazione senza scadere nel clickbait più bieco, vi accorgete di come le notizie negative abbiano molto più risalto di quelle positive, perché il nostro cervello è fatto per dare più risalto alle cose negative e pericolose piuttosto alle cose positive, alle cose che vanno bene, eccetera.Factfulness ti mette davanti alle evidenze comprovate che viviamo davvero nel migliore dei mondi possibili o quantomeno viviamo molto meglio ora rispetto a 50 anni fa.Vengono riportati vari esempi non solo di paesi del terzo mondo, preferisco dirlo delle nazioni in via di sviluppo, ma della Svezia, la Svezia di 50 anni fa, che era molto più arretrata rispetto a quello che possiamo pensare.I miglioramenti che sono stati fatti in tutto l'ambito della vita in questi in questi paesi anche che noi consideriamo sviluppati sono incredibili anche negli ultimi 50 anni quindi non è vero che tutto va male non è vero che ci sono solo guerre e morti ci sono molte meno guerre e molti meno morti rispetto a 100 anni fa questo mi ha aiutato anche professionalmente a cercare di evitare le notizie negative diciamo notizie negative pareri molto negativi su determinate tecnologie perché appunto avere un'opinione negativa su qualcosa è come se ti portasse ad avere un po' più audience.Questo libro mi ha aiutato a filtrare queste cose, a vedere solo le cose che mi servono, sapere che comunque stiamo andando avanti, stiamo progettando e stiamo migliorando.Quindi questo è il primo consiglio che vi do.Il secondo libro che voglio citare è "Office of Cards" di Davide Cervellin.Di cui ho scoperto adesso c'è pure un podcast.Non ve lo sto a consigliare perché non l'ho ascoltato, ma ho visto la serie di ospiti e probabilmente è qualcosa che inizierò ad ascoltare.A cosa serve "Office of Cards"? serve a imparare come ci si comporta in azienda.Diciamo che è una lettura ideale per chi lavora in un'azienda direi medio-grande e vuole fare carriera all'interno di questa azienda.Non ci sono trucchi di PNL eccetera per comunicare meglio, per cercare di manipolare la mente di quello che sta davanti.ci sono raccontate alcune esperienze di come una persona può cercare di scalare, di mettersi in evidenza, di portare valore soprattutto perché si parla di quello fondamentalmente all'interno di un'azienda.L'obiettivo è raggiungere delle posizioni più in alto nella scala girarchica o diciamo nel organigramma dell'azienda.Questo vuol dire non per forza avere lo status di C-level o qualsiasi altra cosa, quanto capire che tipo di skill ci vogliono per andare avanti all'interno dell'azienda.Quindi si parla soprattutto di soft skill, si parla di come valorizzare le persone di cui siamo responsabili, quindi non che stiano per forza sotto di noi, di come overperformare, passatemi il termine, e cose di questo tipo.Io, pur non essendo distante da questo tipo di ambiente lavorativo e forse anche di questo tipo di ambizione a dirla tutta, devo dire che è stata una lettura che mi sono mangiato, tant'è che avevo intenzione di scrivere a Davide per dire "guarda, grazie, perché sono così tante informazioni all'interno di questo libro, pur non essendo coinvolto in prima persona, che vorrei ringraziarti di questo.Non l'ho fatto perché poi sono super lazy, quindi questa è anche una mia confessione.Però devo dire che mi ha colpito molto.Terzo libro.The 5am Club.Questo l'ho scelto in un insieme di libri sul sonno che ho letto in questo ultimo periodo.È una specie di romanzo, perché parla di una storia, di persone che si incontrano quasi casualmente, hanno un certo tipo di avventure, conoscono un personaggio che gli spiega i benefici dell'alzarti presto, del seguire il ciclo del sole, eccetera, eccetera.Non scadiamo troppo nella filosofia o nello zen o queste cose qua.Diciamo che l'uomo per il 99% del tempo della sua esistenza, quindi da milioni di anni fa fino a 200 anni fa, andava a letto quando aveva sonno, seguiva il ciclo della luce.La rivoluzione industriale l'ha portato a fare turni di otto ore, a dormire la notte.Ma questa cosa non è naturale.Io faccio da qualche anno il suono polifasico a fasi alterne, quindi senza essere troppo estremo e senza essere troppo rigido, perché queste tecniche, chiamiamole tecniche, non per forza devono seguire lo schema che ti viene detto in un libro.Devi anche seguire il tuo metabolismo, quello che senti e quello che ti fa trovare meglio.comunque io ho scoperto che alzarmi molto presto la mattina quindi alle 5 la mattina mi rende non per forza attivo ma comunque felice di essere sveglio perché nel mio caso per esempio so che sto facendo qualcosa di produttivo mentre gli altri dormono poi magari dormo mentre qualcuno fa qualcosa di produttivo però questa cosa mi fa mi fa stare bene e comunque ti aiuta a capire come il sonno è una cosa così importante che spesso che spesso viene trascurata.Invece non va trascurata, va coltivata e va...ognuno deve capire qual è la sua migliore condizione di sonno, posto che la vita che va avanti per tutto il giorno ti porta ad avere...a forzarti determinati orari.Però questo libro dà molta consapevolezza su quella fase, quella cosa che noi facciamo per tante ore al giorno e senza di quella non potremmo vivere, però gli diamo così poca importanza.Quindi consiglio questa lettura a chiunque, anche chi è costretto a lavorare la notte o chi è costretto a non poter seguire uno schedule regolare.Questo aiuta diciamo anche a portarti a dire "ok io sto facendo questa cosa, sto dormendo male, secondo me proviamo a cambiare, proviamo a chiedere al mio capo se posso dormire dopo pranzo su una brandina che mi porto.Non c'è niente di male.Se te dopo sei più produttivo perché i tuoi cicli circadiani migliorano ne gioverà anche il tuo capo.Quindi cercate di leggere cose sul sonno.L'ultimo libro che porto è "High Performance Browser Networking".È un libro che è stato suggerito da Matteo Collina, non mi ricordo se in questo podcast o da qualche altra parte, non me ne voglia Mauro se faccio pubblicità occulta, ma non mi ricordo chi ha fatto la pubblicità.E' un libro molto interessante, forse è l'unica lettura tecnica che porto qua.Questo libro parla in maniera molto tecnica e puntuale di cosa succede quando facciamo una richiesta web, o...sì, diciamo facciamo una richiesta web, prendiamola molto in generale.Questo libro fa capire l'importanza delle cdn, l'importanza di quanto costa fare effettivamente una richiesta, quanto costa mandare dei file grossi che devono essere spezzati in più pacchetti tcp, che devono fare magari molti round trip diciamo che non cambierà il vostro modo di lavorare radicalmente però vi farà rendere conto se già non lo sapete chiaramente di quanta complessità c'è sotto una semplice richiesta http per una pagina web e di quante possibilità ci sono di ottimizzare queste richieste perché vi portare avanti a delle piccole cose che moltiplicate per centinaia di migliaia di file di byte trasferiti possono portare veramente un vantaggio vantaggio nell'ordine del 10 per cento di page load per dare un'idea semplicemente facendo alcune accortezze capendo come funzionano i protocolli Quindi questa è una lettura che serve a chiunque lavori sul web.E niente, queste sono le mie quattro proposte, tirate fuori non a caso, però, diciamo, dalla lista dei libri che ho letto recentemente, di cui non ho potuto rileggermi i riassunti perché appunto Mauro non ci ha dato il tempo.queste sono le sensazioni che mi rimangono dopo aver letto.A disposizione, chiaramente sul gruppo Telegram, per avere delucidazioni o qualche altro scambio di idee su questi libri.Ciao a tutti! Ciao a tutti! Allora, era un po' che non ci si sentiva.Allora, questa lista dei libri che sto per farvi è una lista ovviamente non omnicomprensiva per questioni proprio di tempo ma secondo me sono effettivamente quei libri che mi hanno aiutato di più nella mia carriera professionale e per l'ultima chicca non solo.Allora il primo libro diciamo per per chi ha sentito magari altri puntati o è nel gruppo gitbar che vi invito comunque a seguire se non siete già iscritti al nostro gruppo gitbar è Clean Architecture.Clean Architecture è un libro di Uncle Bob, di Robert Martin ed è sostanzialmente un libro che appunto illustra questo tipo di architettura software che è chiamato Clean Architecture.Clean Architecture io trovo che sia un libro utile sia per imparare e per apprezzare quella che la Clean Architecture ma anche per apprezzare sia l'hexagonal architecture sia l'Onyon architecture che sono sostanzialmente le fondamenta della clean architecture.Sicuramente un libro del genere può essere divisivo, ho visto molte opinioni contrastanti, c'è chi preferisce l'hexagonal, c'è chi preferisce un'architettura diciamo un po' più tradizionale per lo sviluppo web come può essere l'architettura mvc ma credo sia comunque uno di quei libri da leggere per poter capire come far fare l'level up diciamo al proprio software e alla propria architettura generale perché magari non userete appieno quella che la Kinal Architecture ma magari vi renderete conto che è meglio l'hexagonal o magari questo sarà solo uno spunto per per approfondire poi diciamo il discorso delle architetture software ma credo sia un libro da leggere sicuramente leggere con il giusto spirito critico e soprattutto leggerlo con l'intenzione poi di approfondirlo praticamente perché diciamo quello che fa il libro è fare un discorso che non voglio chiamare teorico ma comunque un discorso architetturale e calare diciamo nei panni di ogni linguaggio di ogni caso d'uso questi concetti può essere diciamo un po complesso e ci sono obiettivamente linguaggi che aderiscono meglio di altri insomma diciamo che se venite da un background più object oriented probabilmente riuscite a metterlo in pratica prima nonostante comunque siano concetti validi in qualunque linguaggio con qualunque framework con qualunque strumento voi vogliate utilizzare insomma anzi io ho fatto planking in ruby in go in javascript op funzionale insomma un po come vi pare sicuramente un libro da leggere è un libro da leggere in inglese almeno io l'ho letto in inglese non ho letto anche in italiano perché mi è stata regalata una copia di questo libro in italiano ed è di apogeo mi sembra.La traduzione è fatta abbastanza bene diciamo ovviamente è una traduzione quindi è assolutamente fedele al libro in inglese se volete leggerlo in italiano sì non credo ci siano grandissime differenze ma se avete una buona conoscenza dell'inglese vi consiglio comunque di leggerlo in inglese vi aiuta anche ad entrare meglio nella terminologia.Il secondo libro e qui si va sulla banalità della banalità è Clean Code.Clean Code come Clean Architecture è un libro di Robert Martin e su Clean Code se ne può dire veramente di tutto e di più insomma.E' un libro che ovviamente ha i i suoi anni.Se andiamo nell'internet possiamo leggere dei pareri che sono molto discordanti tra chi dice che la maggior parte sono delle banalità e credo che con l'occhio critico di una persona senior possono effettivamente essere banalità.Alcune cose lo sono di meno ma comunque diciamo è una raccolta di best practice per scrivere del codice pulito.E' un libro che sinceramente consiglio l'ho letto diciamo parecchio tempo fa anche un po' agli inizi così e mi ha dato degli ottimi spunti di riflessione.Che se ne dica su Clean Code, su Clean Architecture, su Uncall Bob potete davvero pensarla come volete ma vi consiglio comunque di leggerlo può aiutarvi anche a capire meglio le varie critiche che ci sono state fatte alcune fondate alcune secondo me meno però è un libro che onestamente leggerei diciamo fa parte di quella serie di libri come anche "The pragmatic programmer" che sicuramente sarà stato citato già prima oppure poi non so in che ordine sono diciamo è uno di quei libri secondo me da leggere da leggere da apprezzare o quantomeno diciamo saper necogere lo spirito.Un altro libro è "The philosophy of software design" anche qui è un libro di cui abbiamo parlato spesso sul gruppo e anche in altre puntate di Kitbar.Possiamo sostanzialmente riassumerlo in un prontuario diciamo di principi di software design.E' un libro che anche questo va preso abbastanza con le pinze o meglio va sempre letto con il giusto spirito critico.Secondo è un bellissimo libro che dà tantissimi spunti ovviamente ci sono cose con cui sono più o meno d'accordo anche online comunque si trovano delle ottime recensioni ma magari ci sono alcuni punti che diciamo che non sono condivisibili diciamo dai più ma nel complesso è un ottimo libro che vi consiglio di leggere è un libro non grandissimo, qui davanti sono più o meno 170 pagine 180 pagine è scritto bene ed è sostanzialmente diviso in sezioni una cosa molto molto carina è il fatto che sull'ultima parola sto sfogliando proprio in questo momento qui sto vedo che abbastanza ASMR.C'è sostanzialmente un sommario di quelle che sono le red flag e i the same principles che vengono affrontate nel libro con la relativa pagina.Una sorta di indice ma anche diciamo un reminder riassuntivo di tutto ciò di cui parla il libro.Ho visto su reddit qualcuno che le ha replicate una specie di poster quelli più interessanti insomma e quindi questo poi un altro libro che vi consiglio è sicuramente diciamo è un libro che non è tecnico ed è sul buon uso della lentezza.Sul buon uso della lentezza possiamo considerare un saggio che parla diciamo è un viaggio alla riscoperta della lentezza questo perché la lentezza è vista spesso nel nostro mestiere e non solo come qualcosa di negativo come qualcosa diciamo di diciamo da evitare e da non inseguire perché è uno scoglio è un ostacolo per la produttività, per la propria carriera, per la propria vita.In realtà la lentezza spesso è lo strumento più potente che abbiamo per riappropriarci di noi stessi, del nostro tempo e per riappropriarci anche della nostra produttività questo perché andare sempre veloce andare sempre di corsa non dare la giusta importanza alle pause alla lentezza al diciamo al che posso dire ad apprezzare le piccole cose, il buon vivere e anche solo fermarsi a ragionare su noi stessi, sul nostro tempo, su quello che abbiamo, sto divagando tantissimo, è una cosa sicuramente positiva.È un libro che mi ha aiutato dal punto di vista professionale ma soprattutto dal punto di vista personale per riuscire a riapprezzare le piccole cose per arrivare poi alla consapevolezza che correre sempre è quella cosa che nel breve termine ci fa sentire bene, ci fa sentire produttivi, ma nel lungo termine è qualcosa che può veramente privarci di una parte di noi e può farci sentire scarichi.Alla fine, non lo so, la nostra vita, la nostra carriera non è tanto una gara di velocità, ma una gara di resistenza.Bisogna saper bene dosare le nostre energie e sapere anche andare piano per poter per poter arrivare fino alla fine nella maniera più serena possibile.Io spero che questi libri vi siano vi sono piaciuti o comunque siano uno spunto di riflessione anche anche per voi e vi lascio agli altri miei colleghi.Ciao! Dunque parlo piano con tutta la voce sexy così perché il mio figlio dorme nella stanza di fianco.Quattro libri che mi hanno aiutato a crescere come sviluppatore.Il primo probabilmente sarà già stato detto da qualcun altro di noi ma lo ribadisco perché è imprescindibile, è dei pragmatic programmer, ne abbiamo parlato qualche tempo fa anche in fase di balocchi ma è veramente mai più senza, ci sono un sacco di idee e di pratiche che mi trovo ad applicare quotidianamente, per esempio quella dei tracer bullet per provare a fare qualcosa e vedere come funziona in gergo moderno e della gente giusta assomiglia molto a quella cosa di fare gli spike però è un libro che veramente ti spiega come scegliere dove investire le tue energie che per definizione sono limitate.Un altro molto bello è "Programming Practice" in italiano credo si chiami "Programmazione nella pratica di Kernigan, di Kernigan e Ritchie, di quelli che hanno inventato il C, e Rob Pike, e anche quello è bellissimo, non ha molte cose concrete e autocontenute, nel senso che ok ha degli esempi di codice, ma parla di cose trasversali a una singola tecnologia o a un singolo contesto e dice per esempio perché è importante fare testing, come si analizzano le performance, come si fa refactoring, è abbastanza corto ma è molto molto denso e quindi per questo mi fa veramente impazzire, l'ho riletto di recente ed è davvero un missile.Un altro molto bello è il mio libro preferito, anche quello è stato il mio primo balocco della mia prima puntata di Gitbar, è il mio preferito della serie di tutti i Pragmatic Programmers, è Pragmatic Thinking and Learning, è molto bello perché parte da temi di neuroscienze, neurologia e biomeccanica di come funziona fisicamente e chimicamente il cervello e ti spiega un po' come rifattorizzarlo perché il titolo è proprio "refactor" il sottotitolo è "refactor your wetware" e spiega come rifattorizzarlo per individuare quali sono i momenti di maggior produttività di maggior efficacia e volendo anche come proprio truffarsi la mente per massimizzarne l'efficienza e fare in modo appunto di guidare la propria mente a funzionare al meglio è molto molto bello è molto efficace scritto molto bene anche.Quarto un libro che invece non c'entra non è assolutamente un libro tecnico e non fa parte di nulla di tecnico ma è un libro davvero stratosferico si chiama "Nonviolent Communication" anche di questo forse ho parlato in fase di balocchi sono una persona ripetitiva oppure credo molto nei libri che mi piacciono è un libro che è scritto da un tizio che prima di fare quello che fa adesso faceva il negoziatore coi terroristi quindi era quello che diceva se liberate un ostaggio vi diamo un elicottero e queste cose qui e spiega proprio come strutturare la comunicazione non solo con gli altri ma anche il proprio monologo interiore in un modo non violento, come dice il titolo, ed è una cosa che davvero ti cambia il modo sia di comunicare con le persone perché fa in modo che tu empatizzi con la persona che hai di fronte e cerchi di capire quali sono i suoi bisogni e ti spiega come farlo, ti fa vedere proprio delle strategie, delle tecniche per metterlo in pratica e empatizzando con la persona che hai di fronte riesci a comunicarci in maniera appunto più efficace perché partite dal presupposto che entrambi comprendete i bisogni dell'altro e volete risolverli ma la cosa che secondo me è devastante appunto applicare la stessa cosa anche alla comunicazione con se stessi, alla comunicazione tra se stesse.Io storicamente ho il problema che mi dico un sacco di cattiverie da solo, come credo molti di noi, e riuscire a riformularle e rifrasarle in una maniera appunto non violenta, non giudicante e più empatica anche con me stesso per me è stato un cambiamento devastante mi ha veramente cambiato la vita però quasi bonus point un libro che si chiama "The effective engineer" è un tizio ex facebook ex google se non vado errato e che fondamentalmente come tanti saggi americani ti dice l'idea centrale nelle prime 30 pagine e poi te la ripete con molti esempi ma l'idea fondamentale è che devi fondamentalmente scegliere le battaglie che combatti e scegliere quelle che massimizzano il tuo impatto.Tutti i software ingegneri americani sono mega fissati con questa cosa dell'impatto è uscito quando c'era tutta la questione dei 10x developers e di queste cose qui e lui fondamentalmente dice che per essere un 10x developer devi essere uno che sceglie le battaglie in modo da massimizzare l'impatto e poi ti racconta un po' la rava e la fava di come fare a farlo esempi casey story e quant'altro.Basta questi sono i miei quattro non cito The Phoenix Project perché credo che sicuramente ne parlerà un altro giorno.Allora, improvvisiamo questo piccolo episodio...mi sentite anche che chiudo questa porta? Scorrevole...Improvvisiamo questa particella di questo episodio parlando di quattro libri che ci hanno cambiato la vita professionale.E' molto complesso scegliere effettivamente 4 libri su tanti che ne leggi e ti cambiano la vita professionale.Io personalmente scelgo...ormai so un disco rotto riguardo queste cose, sono veramente un giradischi incagliato.Io vi raccomando Pragmatic Programmer, perché nonostante gli esempi datati, risulta sempre, secondo me, il miglior libro riguardo lo sviluppo software attualmente mai scritto perché quello che succede è che mette a nudo tantissimi esempi di cose che non vanno e che vanno durante lo sviluppo di un prodotto software sia esso un software as a service, sia esso un software che installiamo dai clienti, o anche un'applicazione desktop.In realtà il caso d'uso, tra virgolette, di tutti gli esempi che loro fanno durante il libro, che gli autori fanno durante il libro, sono tutte applicazioni desktop, perché in realtà all'epoca si programmava tanto così.Però in realtà i concetti si applicano veramente in ogni ambito e continueranno ad essere super applicabili sempre.In particolare il concetto del "Tracer Bullet" o il concetto, che ne so, ve l'avrà detto anche il maestro Luca Rainone, che non so se in questo episodio verrà prima o dopo di me, la minestra di sasso.C'è veramente tra l'aneddotica, il concetto per esempio delle finestre rotte, delle broken windows che un progetto può avere e a cui noi dobbiamo stare attenti.Le broken windows io da quando ho letto quel libro le monitoro, sono tipo un KPI dei miei progetti personali e non.Il secondo libro che vi voglio regalare è Domain Modeling Made Functional di cui parliamo molto spesso nel canale Telegram di Kitbar, è un libro che introduce a due tematiche senza risultare per niente prolisso, due tematiche che secondo me soprattutto nel campo dello sviluppo web sono, nella mia opinione personale, fondamentali.Considerando le cose che uno può pensare, in generale, sono argomenti di peso.Queste due tematiche sono il Domain Driven Design e la Programmazione Funzionale.sono due tematiche che vengono trattate in maniera estremamente squisita da questo libro senza mai risultare prolissi in nessun modo, soprattutto senza sfoderare concetti che il lettore non possa comprendere immediatamente.Per esempio, nel libro la parola "monade" viene citata una volta sola e viene citata quasi come una parolaccia.quindi l'altro punto diciamo è appunto il domain driven design, viene fatto anche un esempio di event storming, tantissime cose, tantissime keyword, tantissimi argomenti che nello sviluppo specie web di oggi sono dei bei pilastri e sicuramente questo libro ci dà una bella infarinatura di tutto senza scendere nel bike shading eccessivo, quindi senza commentare eccessivamente le pratiche, ci dà un modo per approcciarci a questi due argomenti senza risultare non noioso, ma soprattutto facendoci vedere immediatamente i benefit del DDD, del functional programming e delle due cose poi combinate, che è la cosa allucinante che si comincia a vedere verso me dal libro.L'altro libro che volevo citare è "The 5 Disfunctions of a Team", che è un...penso che ci sia anche la traduzione italiana che è le 5 disfunzioni di un team, appunto.In realtà vado a fiducia perché è un libro di cui mi hanno parlato estremamente bene e è un libro che sto per leggere e sono sicuro che cambierà la mia carriera.In realtà non parla di sviluppo software ma parla di team building e di come aiutare un team a performare al meglio.E dato che siamo nell'ambito di libri che cambiano la carriera, libri che comunque...dato che, come dice sempre un carissimo amico, la programmazione è la parte facile del lavoro, in realtà, dato che appunto il nostro lavoro principalmente si fa in squadra e costruire squadre performanti, secondo me è il 99% in realtà di questo mestiere.L'altra cosa che vi consiglio in realtà come quarto libro è Dungeons & Dragons 5° edizione manuale del giocatore perché secondo me la cosa...il miglior team building del mondo è il gioco di ruolo e sicuramente se sarete in grado di giocare di ruolo con i vostri compagni di team, con i vostri colleghi, sicuramente metterete in atto delle dinamiche che vi aiuteranno molto nella vita professionale a, se non altro, a mettersi nelle scarpe di qualcun altro quando poi ci so' diciamo delle difficoltà.Spero che questi consigli vi illuminino...scusate ma è quasi ora di cena e ho una fame assurda.spero che questi consigli vi illuminino la strada verso la grandezza.tema i quattro libri che hanno cambiato la mia vita professionale svolgimento.non cito i libri più blasonati che sicuramente saranno o sono stati citati più volte che ovviamente in un modo o nell'altro hanno inciso sul mio modo di lavorare sia è sopprodurre codice che coordinare un team.Mi riferisco a tutti i libri clean punto asterisco, the pragmatic asterisco eccetera eccetera invece alla fine c'è un gioco che si può fare ed è quello di trovare applicazioni pratiche per il nostro lavoro in libri che col nostro lavoro centrano poco o lo toccano di striscio.E' un magistrale esempio l'episodio 52 di git/monologo del nostro buon Brain Repo sul refactoring secondo Italo Calvino, episodio splendido che se non avete ancora sentito dovreste provvedere eppure di corsa.Detto questo il primo libro che cito è "The Art of Game Design" di Jess Schell.In realtà mi ha profondamente colpito perché è stato il primo libro sull'argomento game che ho letto e in generale il primo libro tecnico che non fosse un tutorial di un linguaggio.Io ho cominciato a programmare proprio sui giochi come come perfetto autodidatta andavo un po' a sentimento un po' a caso.Ho creato dei giochini nello specifico delle chat game flash che avevano anche tanti giocatori, si parla di qualche centinaio fissi e qualche migliaio di registrati, uno di questi era tema Matrix che quasi quasi è il caso di rispolverare visto che nel 2022 esce il quarto film a stenersi i commenti negativi perché Matrix non si tocca anche se il 2 e il 3 sono quello che sono Matrix non si tocca.Dicevo quel passaggio dal fare le cose a sentimento a strutturare un gioco pensandolo con metodo è stata una cosa che a 28 anni mi ha segnato ora ne ho 40 fatevi un po' i conti, parlo di altre epoche dove i social erano ancora semivergini senza l'ampia gamma di influencer di oggi dove sicuramente non c'era Amazon Prime o almeno io non ce l'avevo e soprattutto non c'era Gitbar, questo sono abbastanza sicuro.Non chiedetemi di che cosa parla perché ormai non me lo ricordo più questo libro e credo che non è importante sapere a memoria i concetti che si trovano in questo libro, l'importante e cosa ti ispirano quei concetti quando li leggi, quando li apprendi e soprattutto quando li metabolizzi o magari li scopri in altri libri che trattano magari altri temi.Questo libro infatti mi ha dato le basi per capire la gamification.Game e gamification sono due cose diverse ma la teoria di base è esattamente la stessa e la gamification ormai si trova ovunque anche soprattutto nella moderazione dei brainstorming, nelle retrospettive che per me sono quasi l'ordine del giorno.Se non conosci la base del gaming tendrei a sottovalutare dei dettagli sul come moderare un brainstorming che invece sono essenziali per mantenere la soglia dell'attenzione alta, equilibrare il gioco tra tutti i partecipanti e migliorare così l'esperienza di tutti i partecipati di un brainstorming.Il secondo libro è "La caffettiera del masochista" di Donald Norman.Parla del design degli oggetti quotidiani.Si comincia partendo dalle porte che non ti suggeriscono mai se devono essere tirate o spinte o le devi far scorrere di lato, passando dall'esempio del bancomat che se non ti sputasse prima la carta e poi i soldi ci sarebbero ogni giorno centinaia di denunce di carte smarchite.Pensateci non è un caso che tutti in Bancomat vi chiedono prima di ritirare la carta e poi vi danno i soldi perché voi siete lì davanti per i soldi per quelli che usano ancora i contanti almeno.Una volta capite le basi, l'utilità delle affordance e le inutilità delle etichette che appiccichiamo sopra le cose con la speranza che qualcuno le legga, capisci come migliorare non solo l'usabilità delle app, dei siti e di tutto quello che programmiamo, ma anche la development experience di ogni giorno.Quindi io professionalmente ho cominciato a migliorare la development experience prima che conoscessi la development experience, prima che sapessi che si chiamasse in questo modo, proprio applicando i principi questo libro che ho letto, insomma con un libro solo generico che ti dà delle profonde basi, sono molto tecniche, molto sul design e sulla progettazione delle cose piuttosto che sulle app, però insomma con questo libro un po' più generico ti puoi risparmiare gli altri 4-5 libri specifici sul design del tipo Domainic e libri di altro tipo.Una piccola nota se lo leggete comincerete a odiare tutti i progettisti di cose.Io nel periodo in cui l'ho letto l'ho litrigato con il mio arredatore che stavo facendo casa all'epoca.Terzo libro.Questo libro mi fu consigliato da Bill Gates in persona, nel senso tramite la sua pagina facebook con un messaggio su skype.Il libricino si chiama "mentire con le statistiche" di Darrell Huff.Le statistiche sono ovunque e anche forse più della media nel nostro lavoro da sviluppatori non solo vedendo le statistiche del nostro sito, i sondaggi di stack overflow, le fluttuazioni dei nostri bitcoin ma anche nelle statistiche di utilizzo dei framework nostri preferiti e magari riusciamo a capire perché su npm jquery sempre sia lo dato e usatelo sempre per riconoscenza, continua a crescere nei download nonostante la nostra esperienza ci dica che è leggermente desueto ma soprattutto ci insegna a non farci ingannare dai grafici, i grafici quelli creati ad hoc apposta per noi.Noi siamo inondati da grafici ogni giorno anche soprattutto al lavoro, forse non ce ne accorgiamo nemmeno, secondo me dovremmo faremo bene ad accorgercene.Per una strana coincidenza ho letto questo libricino proprio mentre al lavoro stavamo lavorando sulle statistiche da mostrare ai clienti, le statistiche dei nostri prodotti da mostrare ai nostri clienti.In quel contesto mi sono divertito a manipolare i grafici e torturarli per far dire loro quello che volevo.L'ho fatto in fase di sviluppo e il solo scopo didattico, non ho messo le modifiche in produzione perché la trasparenza è per me un valore imprescindibile e lo è anche per me quindi solo in fase di sviluppo preciso.Detto questo, UGABUKA TONGA BANGA questo lo dico per vedere se mi state sentendo ultimo libro ma non ultimo non è tanto un libro ma è una favola c'è in varie versioni è citata anche nel libro dei pragmatic programmer che sicuramente sarà citato da qualche mio collega qui si può trovare in vari libri di favole per bambini io sono nel libro storie illustrate della buonanotte questa favola si chiama la minestra di sasso.La minestra di sasso è una squisita parabola il cui scopo è insegnare a fare il primo passo per un progetto anche se non hai gli strumenti o per farla coerente con il racconto gli ingredienti giusti.Così mettendo a bollire una pentola d'acqua e un sasso, l'unico ingrediente che hai, cominci a suscitare la curiosità delle persone vicino che hanno ingredienti ben migliori più adatti.Puoi dire "faccio una minestra di sasso è buonissima" e ti dico "certo ci andrebbero delle patate ma purtroppo non le ho" ed ecco che magicamente qualcuno arriva e dice "ehi ma io ho delle patate se vuoi" e così la zuppa di sasso si trasforma in una zuppa di patate finché il profumo non attira qualcun altro che magari è un paio di cipolle che decide di mettere a disposizione e poi verranno le carote, le salsicce eccetera eccetera.Tutti ingredienti che erano nella dispensa di tutti erano lì a portata di mano ma nessuno aveva avuto l'idea o forse il coraggio o l'intuizione o la stessa fiducia di metterli per primo in una pentola.Alla fine rimuovi i sassi che hai messo e vi godete insieme una minestra, una squisita minestra.questo effettivamente l'ho applicato personalmente in un progetto in azienda avevamo il classico mastodontico back office vecchio di 12 anni di sviluppo dentro c'era codice php3, c'erano mani di programmatore di ogni generazione, razza, religione, sesso, orientamento eccetera eccetera nessuno aveva il coraggio di posare la pietra per un refactoring come si fa un refactoring di una roba del genere? avremmo dovuto chiuderci mesi a rifare roba che tutto sommato funziona chi ce lo faceva fare? poi ho avuto alla fine un'idea per far convivere il codice nuovo in un'interfaccia vecchia e programmato una base più developer-friendly che avrebbe dimezzato il lavoro di creazione di moduli nuovi non ho dovuto chiedere nessuna autorizzazione per farlo l'ho fatto e basta perché erano alla fine quattro sassi erano proprio un lavoro di un paio di nerdi quindi non era nulla di particolare poi ho cominciato a chiedere a chi configurava il server di dire "Fai un redirect quando chiamo questo path" anziché prendere il path del mastodontico giralo su questo folder nuovo perché mi serve e quindi ho cominciato a fare il primo modulo, il secondo modulo e alla fine anche tutti gli altri del team cominciato a usare l'engine nuovo hanno cominciato anche a migliorarlo perché alla fine io come detto avevamo messo quattro sassi e alla fine è venuto fuori un qualcosa di nuovo di più moderno e soprattutto ci velocizzava il lavoro della creazione dei nuovi moduli.Poi pian piano quando venivano richieste di modifiche dei moduli vecchi facevamo prima a rifare i moduli vecchi nel nuovo sistema piuttosto che fare le modifiche al vecchio e in pochi anni ma senza fermare i nuovi lavori abbiamo rifatto praticamente tutto il massato antico back office o almeno diciamo tutta la parte che conta.Questa è stata proprio l'applicazione pratica di questa parabola ed effettivamente ha cambiato la mia vita professionale e alla fine anche un po' le sorti dell'azienda perché ha velocizzato parecchio il lavoro e basta spero che questi libri e questa puntata async vi sia piaciuta devo ringraziare tutti per avermi spedito il contributo io naturalmente la sto pubblicando in ritardo quindi mea colpa ma è solo colpa mia appunto perché completamente preso da questo trasloco prima di lasciarvi vi ricordo se non avete ancora fatto l'iscrizione al nostro gruppo telegram cosa state aspettando siamo tutti là vi ricordo anche i nostri contatti info@gitbarra.it o @brainrepo mi raccomando se l'episodio vi è piaciuto lasciateci una recensione all'interno dell'applicazione podcast di Apple o qualche stellina oppure trovate un modo per dirlo a qualcun altro.Più siamo, più la nostra famiglia cresce, più abbiamo occasioni di confronto e proprio dalle occasioni di confronto del nostro bar virtuale in qualche modo stiamo crescendo tutti.Detto questo io vi ringrazio, vi do appuntamento alla prossima settimana dalla Sardegna è tutto.Ciao! GIT BAR 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 dav.[Musica]
