Bene e benvenuti su Geek Bar, nuova settimana e nuovo episodio e come sempre il giovedì siamo qua a tenervi compagnia per un'oretta, un'oretta e mezzo nel nostro e nel vostro bar preferito.Anche questa settimana non sono solo, ho un super ospite con noi e gli ammutinati si uniranno tra un pochino quindi sarà una puntata veramente interessante da tutti i punti di vista.però prima di svelarvi l'ospite, voi lo sapete, quello che faccio sempre in inizio puntata e credo che sia anche quello che poi schippate utilizzando i capitoli dell'episodio è il ricordarvi i contatti.Info@gitbar.it, via email @brainrepo su Twitter sono i punti di contatto canonici.In realtà però la nostra vera casa è il gruppo Telegram.siamo 531 membri quindi siamo una bella famiglia e ci incontriamo là per dire delle fesserie ma anche parlare di robe tecniche e proprio oggi di robe tecniche andremo a parlare e lo faremo con...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 Ecco qua! Vi è piaciuto il cliffhanger? Vi ho lasciato col fiato sospeso? In realtà l'ospite di oggi è Francesco Strazzullo.In realtà tutti lo chiamano Straz, è un socio sviluppatore per Flowing, autore di due libri super interessanti il primo è "Frameworkless Frontend Development" e su questo chiacchiereremo un po' e il secondo è "Decision Making for Software Development Team" e parleremo anche di questo.Ciao Straz, come va? Ciao Mauro, tutto bene e grazie per mi ha invitato e sono molto contento di partecipare a Geek Park.Anch'io sono super felice di averti qua, tra l'altro non so cosa sia successo, la mia webcam è appannata, io non sono ubriaco, non sono andato fuori.Ah ok, quindi non è un effetto voluto, chissà, mi hanno voluto lasciare appannato.Non ne ho idea ma per ora va bene così, proverò a capire cosa è successo.Ah ecco qua.Ah questo adesso funziona, perfetto.È ritornato tutto, l'autofocus magico di questi giocattoli.Come va intanto? Finalmente ti hanno ristorato la DSL, la fibra.Sì esatto, ti chiedo ancora scusa ma c'era stato un problema con la fibra per qualche giorno, non avevo connessione, non volevo fare l'intervista affidandomi al tethering, ero un po' preoccupato, quindi ho detto che si deve spostare.Però si, adesso fare che gira tutto.Beh avremmo potuto registrarla in audiocassetta tipo ti avrei mandato le domande registrate tu la cassettina.No scherzo però vedi caspita quanto dipendiamo poi da internet oggi ogni tanto ci penso io ho passato l'estate giù in Sardegna con una DSL orribile gli ascoltatori lo sanno tutti i problemi tecnici e le vicissitudini che ho dovuto passare.È stato tragico tragico siamo completamente dipendenti ormai per fortuna direi.- E poi in realtà un'altra cosa divertente che mi ha fatto molto riflettere sempre sulla dipendenza è che c'è stato facebook down e uno dice vabbè succede.Un'altra cosa che mi ha fatto ridere è che io gioco spesso a ping pong in realtà virtuale con il casco della oculus e non non si accende, mi ha detto "no, non riusciamo a connettere su account facebook, non puoi giocare online" mi ha sbattuto fuori.E ta, giusto, è vero.A volte le dipendenze sono anche più sottili di quello che uno crede.Sì, tra l'altro ho letto proprio ieri un bellissimo tweet che dice "chi stava giocando con la Oculus durante quel down è rimasto impigliato nella realtà virtuale e non può più uscire".Questa situazione alla Matrix "Caspita però questo periodo ci sono stati tantissimi malfunzionamenti e down di servizi anche importanti senza andare molto lontano l'attacco e il leak di twitter di twitch di oggi stanno succedendo tutta una serie di cose e allora quello che mi chiedo io è ma tutte queste cose le sto percependo io perché sono più sensibile siamo più dipendenti o perché in realtà tutto il sistema ha una stabilità che via via sta iniziando a degradarsi? Bella domanda, in realtà credo che un po' è perché ci stiamo attenti noi, nel senso noi ce ne rendiamo conto perché se no ci sono alcune cose che non vediamo tutti i giorni, Slack è down un giorno, GitHub è down un giorno, ti rende molto più consapevole di alcune cose.Ovviamente, chi non fa il nostro lavoro, si ne accorge il giorno in cui va giù Facebook, in cui magari va giù Twitch, che se vuoi è già molto più verticale, se vuoi è anche più di nicchia rispetto a Facebook, Whatsapp, Instagram.Lascia perdere l'oculus crea più una battuta, nel senso che va beh, fa niente, però non sono sicuro che si sia tutto sfasciando, più che altro è un mondo molto fragile, che è quello che vogliamo raccontarci noi tra ingegneri, la verità è che è fragile e sta cominciando a diventare complesso, nel senso che non sempre è facile capire causa-effetto di queste cose se rompo un dns io non gioco a ping pong, adesso sembra cazzata ma le conseguenze non sono facili da calcolare e questo è il problema, perché non è affrontabile da un punto di vista prettamente ingegneristico, in un sistema così interlacciato.Sì, il numero delle relazioni e delle connessioni diventa altissimo, parlo di connessioni di sistemi complessi e alla fine più questo diventa intricato e più diventa anche intricato poter gestire i casi limite che possono verificarsi anche se diciamo sul caso di facebook e dei dns ci si potrebbe fare un episodio secondo me perché anche la consapevolezza noi tutti i giorni sviluppiamo software, questo software gira da qualche parte e noi spesso abbiamo contezza di solo una parte dell'infrastruttura dove giriamo però non abbiamo la benché minima percezione, perché comunque il sistema è veramente complesso, di tutto l'ambaradan che tiene in piedi quello che facciamo tutti i giorni e avere questa percezione diventa veramente un lavoro disumano.Quindi, non lo so, certe volte facciamo qualcosa senza avere quasi il controllo di quello che facciamo nel suo contesto complessivo.È vero, però in realtà secondo me ci sono anche un sacco di… e e che a volte, secondo me, siamo abituati a ragionarla con "prevedo quello che può succedere e agisco le conseguenze".In realtà poi sono emerso negli anni anche nelle tecniche di Chaos Engineering, sto pensando ad esempio a, non ricordo come si chiamano, Chaos Monkeys, cioè quei tool di Netflix che continuamente attaccano la rete in produzione simulandolo per essere sempre certi che loro siano resilienti.Robbe di questo tipo.Simulano che si staccano i cavi, cioè proprio roba di questo tipo qua.Perché? Perché tanto non riesci a prevedere.È tutto troppo connesso.E il cloud, in realtà, poi questa cosa l'ha accentuata, nel senso che se ci pensi serverless è una frase finta nel senso che da qualche parte un pezzo di ferro c'è, un pezzo di ferro ci deve essere, il fatto che tu non lo veda o che sia nascosto sotto dei layer, a parte i vantaggi di quello, ti rende tutto a un certo punto nebuloso, c'è la nuvola cloud e tu lì dentro ci arrivi e non ci arrivi insomma.Assolutamente sì e tra l'altro voglio per un attimo prendere la scusa per collegarmi a un argomento la percezione del contesto che fa girare la nostra applicazione.Tu sei stato autore di un libro che si chiama framework less front end e in realtà non si allontana molto dal discorso che stiamo facendo di percezione di quello che ci sta sotto.Che cos'è il concetto di frameworkless? Allora il concetto è nato come una… perché il libro è arrivato parecchio dopo che ne abbiamo cominciato a parlare e che anche qualche mio ex collega e amico ne abbiamo parlato anche in vari talk.Ma è nato con una domanda che… facciamo una macchinetta del caffè… c'è un mio collega all'epoca chiese "ma cosa dovremmo fare per far durare per sempre un software o per lo meno il più lungo possibile?" e allora da lì varie considerazioni e poi ci rendemmo conto che una delle più grosse realtà fallace della durata di un software poteva anche essere il framework, inteso in senso lato, nel senso anche il cloud è un framework, nel senso che è una serie di regole a cui tu deleghi qualcosa.Ora, nel caso dei framework software, tu stai delegando una serie di decisioni architetturali a qualcun altro, prima ancora del codice, nel senso che se tu lavori in Angular, tu non solo stai delegando l'esecuzione del codice a qualcun altro, ma stai delegando anche una decisione che è sempre cosa di essere, di usare la reactive programming, ok? Perché è tutto basato su RxJS, che è giusto o come no, cioè nel senso, poi, però il punto è, non lo stai decidendo te, o perlomeno probabilmente non è consapevole, stai dicendo che usi Angular perché ti fa comodo per una serie di motivi.E da lì poi è cominciato un po' il "rendesi anche corto che all'epoca, perché è anche passato qualche anno, perché dal mio libro sono passati due, quasi tre anni, no, sì, augusto 2019, due anni, ma comunque la discussione è stata molto più lunga e soprattutto all'epoca c'era poca consapevolezza di tante cose nel mondo frontend, perché, e in questo ne ci metto anch'io, il mondo frontend, diciamo, un pochettino più professionale anche a livello di codice, cioè in un senso applicazioni più complesse, nell'enterprise è nato un po' con AngularJS, quell'epoca lì.E quindi in realtà avevamo una serie di persone che o prima facevano un altro mestiere, o in qualche modo non conoscevano abbastanza JavaScript per poter porsi quel problema lì.E quindi abbiamo cominciato a creare workshop, materiale, eccetera, e poi alla fine ho deciso di scrivere un libro in cui ho raccolto un po' di considerazioni su come si scrivono alcune parti del codice, completamente da zero, o con qualche libreria, nel senso che non è una questione di essere nazisti, e più a dire "ok, guarda, un modello di rendering basato su Virtual DOM è più o meno scritto così.Quindi sia formativo, ma in realtà poi alcune di quelle tecniche le uso anche poi tutti i giorni al lavoro, tal cui oggi.Oggi ho dovuto creare un'architettura di eventi front-end, in un'applicazione già esistente abbastanza grossa, non ho installato Redux, ho scritto un pub/sub al volo, poi eventualmente deciderò di aggiungerci Redux.ed è nato più o meno così, nel senso che il punto era proprio la consapevolezza delle connessioni e delle dipendenze tra le scelte tecnologiche e un po' il contesto.Credo che però, ragionando in termini front end, correggimi se sbaglio, credo che un po' questa superficialità nella scelta dei framework o comunque questa fiducia smisurata nella scelta dei framework venga anche da come è strutturato e pensato NPM il gestore pacchetti nel senso ci sono un gozziliardo di pacchetti come dice il buon Luciano Mammino nel suo libro la superficie del pacchetto è piccolissima per cui fa una cosa specifica è solo quella boom prendi lo butti dentro lo importi ed è fatto.Quindi questo approccio frictionless all'utilizzo del codice di altri spesso è talmente frictionless, talmente leggero, talmente indolore da non fare in modo di fermarsi un attimo e dire "ok io devo fare un left pad, ok c'è la libreria left pad su npm, prendo e la uso, magari non guardo neanche quante stelline ha, quante è grande la community, chi la supporta, prendo e la uso salvo poi buttare, mandare a ramengo tutto perché la libreria non è mantenuta o la libreria si rompe o sparisce da NPM.Era proprio l'F-pad che poi è stata buttata giù? Esatto, infatti era una citazione apposta perché è veramente un punto della via crucis dei javascriptali.Però dico, da una parte abbiamo questa leggerezza nell'utilizzo delle librerie a prescindere, dall'altra abbiamo comunque il bisogno di essere produttivi subito.E quindi prendere un angular e dico angular più che React per un motivo specifico che ha già una serie di decisioni prese e tu non ti devi sbattere ti concentri sulla logica di dominio prendi piglie boom e sei online è comodo.E a quel punto hai un trade off no? A quel punto hai un trade off, cioè da una parte vai in produzione veloce con un prodotto e fatturo subito, oppure mi metto a ragionare su come funziona un router, come funziona lo stato, tutte queste belle robe, vado a vedere come funziona sotto il cofano e magari rischio di non andare in produzione dopodomani.Quindi come secondo te ci si gestisce in questa situazione? Allora, in realtà, poi non vorrei passare il messaggio sbagliato, io uso i framework tutti i giorni, solo che quello che cerco di far passare, anche parlando con i miei colleghi o con i sviluppatori un po' più junior, è renditi palese quello che stai facendo.Cioè, il punto è, è ovvio che tutti noi abbiamo bisogno di concentrarci sulla logica del dominio, però per esempio il leftpad, che sembra stupido, ma in realtà è indice di un problema, è "Vuoi prenderti una libreria, una libreria molto specifica che fa una cosa sola, non vuoi scrivertela, ok, ma piuttosto che importartela da NPM, va a vedere il codice su GitHub e prendi il codice su GitHub e mettitelo nel tuo codice", cioè perché quello che secondo me i sviluppatori sottopalano è questo.Allora, da un certo punto di vista, tu hai ragione, noi dovremmo concentrarci sulla logica di dominio, giusto per essere prodotti di subito, fatturare, eccetera, però il punto è, anche il codice scritto da qualcun altro è nostra responsabilità, anche se non vogliamo ammetterlo.Cioè, tutto quello che io mando in produzione è responsabilità del team di sviluppo che l'ha messa, quindi se io ho FPAD, l'FPAD ha un bug critico, è comunque colpa mia, il punto è fare attenzione, cioè l'heft pad invece che installarla la guardi e dici "ah ok, sarà?" Le intrighe, a parte che non sono come se fa un heft pad a mano, però lo guardo, penso di riuscire a capirlo, o anche se non lo capisco, mi porto nel mio progetto il codice e i test, esempio.Se ci sono esperienze, lo sforzo è molto simile, cioè nel senso in realtà la posso scaricare con MTPM, ma me la prendo, se non è codice eccessivamente astruso, perlomeno diventa mio, va sotto controllo di versione.E diciamo che è già un alto processo.Poi questo vale per le librerie.Con i framework il problema è più complesso, ovviamente, tu non puoi dire "mi ricostruisco tutto da zero", però anche lì c'è modo e modo.Per esempio, se tu hai esempio della logica di dominio abbastanza complessa, e ti faccio sempre l'esempio di Angular, perché è la quintessenza del framework secondo me, nel senso che prende molto spunto solamente da framework enterprise pensati per il back-end, nel senso che le annotation ricordano molto Spring, Symphony, quello che vuoi.Se tu hai ad esempio della logica del medio veramente complessa che tu vuoi salvaguardare, perché quella durerà più del framework probabilmente se il tuo progetto è successo, non c'è bisogno che la fai esattamente per forza con Rx.La puoi iniettare all'interno di un framework esistente.E' un po', se vuoi, principi di architettura esagonale, principi di… anche clean code, non c'è nemmeno per forza framework.Però, ad esempio, se non sai come si fa un pub/sub alla Redux da zero, la verità è che poi, dopo un po', non ti verrà naturale prendere certe parti e portarle fuori.Soprattutto nel mondo front-end, che secondo me c'è ancora un po' questa friction, mi piace molto la parola perché è proprio così, nel senso che ci vuole installare Redux su un progetto.Lo metto, lo importo e via.Però ecco, farlo sempre, sei completamente, come dire, numb, dicebbero gli anglosassoni, stai sei un po' intontito dal fatto che è talmente facile che sembra non un tuo problema, mentre in realtà non lo è.È chiaro, oggi quello che andiamo a fare è nell'ecosistema nel quale viviamo, specie nel front end, si è sviluppato a tal punto, anche diciamo le esigenze di questo contesto, sviluppato a tal punto da rendere praticamente impossibile sviluppare un qualcosa strutturato o comunque molto faticoso partendo da zero e senza neanche una libreria questo dobbiamo dircelo.Allo stesso tempo il ragionamento che dicevi tu, io prima ho fatto l'avvocato del diavolo mettendo sulla bilancia la produttività la messa in produzione in tempi distretti e il controllo completo però secondo me la discriminante vera è quello che hai detto il ragionamento sulla responsabilità del codice per essere responsabili del codice dobbiamo grosso modo conoscere cosa ogni pezzo di codice ogni libreria ogni pacchetto che importiamo grosso modo faccia anche se poi con node tu ti perdi perché nei meandri dei node modus ci trovi anche i dinosauri.Ovviamente è a grandi linee nel senso left pad ok dipenderà da qualcos'altro magari però a un certo punto dovrei riuscirci nel senso capire quello che fa.Però quello che dicevo io è secondo me il punto centrale è il concetto di responsabilità.una responsabilità che noi possiamo esercitare utilizzare avendo il controllo diretto del codice che scriviamo è una responsabilità che abbiamo pur non avendo tanti strumenti per poterlo gestire perché nelle librerie di terze parti noi non abbiamo la stessa libertà che abbiamo nella nostra code base perché appunto sono le terze parti vero noi possiamo fare pure quest possiamo fare quello che vogliamo ma rimane comunque una libreria di terze parti che dobbiamo grosso modo conoscere sapere cosa fa c'è una giusta dose di fiducia perché altrimenti non manderemo in produzione niente e poi vedo che piano piano col tempo si stanno sviluppando dei sistemi che vanno a cercare le falle di sicurezza a dirti ehi non hai aggiornato una libreria quindi in qualche modo ti rendono, ti aiutano a rendere un pelino più consapevole.Non lo so, magari un domani ci inventeremo anche uno strumento che lavora nell'ottica dello sviluppo della consapevolezza delle librerie di terza e parte che usiamo nel nostro progetto.Ci si potrebbe pensare in realtà in questa direzione? Ah sì, allora, è interessante, nel senso che… allora, in realtà è che a volte è difficile valutare nell'impatto, no? Nel senso, perché l'heftpad, so che adesso sei… è proprio quello che ha staccato l'heftpad, eh, che volevamo esagerare, però lì è proprio quello il punto.È impossibile a volte capire causa e effetto.Anche perché nelle scelte tecnologiche, soprattutto quanto riguarda il codice legacy, c'è un di fattore umano e che non possiamo trattare solo dal punto di vista ingegneristico.Vi spiego.Una volta sono andato in un'azienda perché mi hanno chiamato per aiutarli a scegliere il prossimo framework front-end.La situazione era più o meno questa.Loro avevano Angular JS e volevano decidere se iscrivere la versione 2.0 in Angular o in React.E loro avevano già fatto tutta una serie di prove che propendeva verso React, ok? Dopo, in realtà, io l'ho aiutato con una serie di esercizi a aprire un po' la mente, cioè a dire "ok, ma qual è il vero problema che avete?" e in realtà la verità è che AngularJS di per sé non aveva nessun problema, nel senso non avevano falle di sicurezza evidenti, avevano anche fatto fare dei test a un'azienda separata.Le performance in realtà non erano un problema, e come ho fatto a dimostrarlo, passami il termine, al tavolo ho portato il capo del customer support e ho detto "15 anni di software, qualcuno si è mai lamentato alle performance?" "No"."Ok, il tempo medio di risposta della chiamata HTTP?" e 3 sia un po' lento, a volte anche un secondo.E allora volete veramente parlare di millisecondi di performance di rendering? Cioè, nel senso… però sapete qual è il punto? È che dopo che sono andato via ho parlato dopo tipo sei mesi con le stesse persone, metà delle persone saranno licenziate.E andrò a lavorare in una startup a Londra per lavorare in React.Quindi il punto è… io non avevo preso una decisione per loro, io l'avevo solo messa di fronte al fatto che, se mi parlate da un punto di vista tecnologico, non aveva senso effettuare un cambio di framework in corsa, che poi in realtà era una roba enorme, parlavamo anche veramente di un progetto complesso.Però il punto è, se erano nascosti dietro le performance, era un problema di carriera, cioè dovevano lavorare in React, e si sono licenziati.Quindi ecco, è proprio per dire che a volte la connessione causa-effetto che riguarda le scelte tecnologiche è veramente difficile da gestire.Quindi, anche lì, qual è la via di mezzo? La via di mezzo è probabilmente quella di dire "ok, prendi ad esempio il framework per lavorare, ma quando devi esempiore un slack time vuoi studiare, piuttosto che studiarti l'ennesimo framework, prova a fare qualcosa da zero, se proprio vuoi imparare.E non dico fare i kata, nel senso che i kata poi sono quelle robe che in realtà ti allenano il cervello.Dico, ok, crea uno state management basato, che ne so, parlo sempre del front end perché poi mi pone quotidiano, ma in realtà varrebbe anche nel backend.Fate uno state management basato su eventi come ti pare da zero.Questo già un primo passo, perché? Perché già capisci come funzionano le cose e poi nel tempo migliori.Cioè questo già sarebbe un altro approccio secondo me.Vero, beh, il mondo JavaScript corre veloce e giustamente, dico, i dev un po' tirano l'acqua al loro mulino, nel senso che in realtà se ti fai una passeggiata tra gli annunci di lavoro oggi o trovi React, trovi Angular, però davvero i nomi di questi framework stanno prendendo quasi più spazio del nome, del linguaggio che si utilizza sotto.React developer, cosa vuol dire React developer? Questo è poi il problema, nel senso che una volta ho parlato con un ragazzo in un'azienda "Noi assumiamo solo programmatori Angular".E poi era proprio il momento in cui Angular era uscito, quindi abbiamo, come tutti i front-end, abbiamo anche passato tutti insieme l'epopea del Angular 1, Angular 2, che era un momento totalmente caotico, eppure quell'azienda puntava, non so se è ancora aperta, a onore del suo Angular, e diceva "dovresti trovare un minimo dei programmatori JavaScript, cioè non per forza focalizzate lì, perché sei fragile, il senso della verità è questo.Come tutte le applicazioni AngularJS, e lo dico per esperienza, perché è tanto tempo che io lavoro con le applicazioni legacy frontend, sono diventate fragili perché la gente non ci vuole andare a lavorare.Fra dieci anni sarà uguale con React, cioè non crediamo che adesso React sia meglio di come era AngularJS una volta.Sicuramente lo era da un punto di vista tecnologico.Non li sto paragonando in quel punto di vista lì, ma sto paragonando il React di oggi con il JavaScript del 2030.Chiaro.Se vuoi la gente che sta in piedi deve fare anche questi ragionamenti.Sempre se ci sarà ancora JavaScript nel 2030 e non sia tutto WebAssemblyX.Esatto.Poverissima.Ok, l'eco è più ampio, però posso inserirmi? Vai Mattia! Tra l'altro è arrivato Mattia, ciao! Ciao, io parlo anche un po' con la voce sexy perché ho il mio figlio che dorme nella stanza di fianco e non voglio svegliarlo però quello che hai detto rispetto agli sviluppatori Angular è una cosa in cui io mi ritrovo tantissimo io sono un giavista di vecchia data e nell'ecosistema Java questa cosa succede esattamente uguale come Spring Spring è stato per una decina di anni buoni, dominatore assoluto in contrasto dell'ecosistema, non potevi fare Java senza fare Spring e gli sviluppatori Java di fatto a un certo punto sono diventati sviluppatori Spring.Adesso le cose nuove, cose fighe, le cose con cui fai hiring, con cui fai retention della gente brava, non le fai con Spring.e se fai gli annunci di lavoro, diciamo, che cerchi sviluppatori che conoscano Spring, ti dicono "oh, ancora Spring? Io voglio fare le cose con ARCA, voglio fare le cose con Play, voglio fare le cose in Kotlin con Ktor, Spring però ha una codebase gigante che esiste".Adoro Ktor, grazie che l'hai citato.Ktor è bellissimo.A me piace molto.Tra l'altro io lavoro con Spring, tra l'altro.Faccio anche backend Java e Kotlin in Spring.Sì, sì, pure io.Capisco.Però è assolutamente una roba… Assolutamente, in realtà poi Spring c'è anche un'altra cosa, in realtà, bellissima, ed è proprio tipica dei framework.Spring è stato talmente famoso che è arrivato prima delle specifiche Java, e le specifiche specifichiamo adesso, in realtà hanno copiato Spring o viceversa, cioè nel senso è stato anche lì è stato veramente un dramma alla scena ingegnata napoletana, quasi, è stato molto divertente negli anni.Poi io per qualche anno l'ho più seguito, però fino a qualche anno fa è stato abbastanza divertente.E poi Spring secondo me è particolare perché in qualche modo Spring ha la stessa caratteristica di React, cioè è un false friend.Prima Mauro, parlavi di Angular contro React, dicendo che React è più una libreria.Il che è vero, tecnicamente parlando sì, è una libreria, nel senso che in teoria fa una cosa sola, ma come Spring è nato, se non sbaglio, come sistema independent injection, e poi è diventato mostro e attenzione perché React sta, secondo me, andando verso quella direzione, non per colpa tanto di Facebook, della libreria, ma perché, per esempio, ci sono librerie tipo React Fetch, non ricordo mai cosa si chiama così, però è definire delle chiamate HTTP come dei componenti React, quindi con dei componenti innestati l'uno dentro l'altro, il che è molto figo, nel senso che quando lo guardi hai una sensazione di ordine dentro la testa, fantastica, ma la verità è che fare una chiamata HTTP per prendere un JSON non è una roba difficile, cioè nel senso che oggi la puoi fare con Windows Fetch, tra l'altro.È quella, quella è quella che io chiamo la via del framework, cioè il punto è il framework cambia talmente tanto il tuo modo di pensare che non riesci più a uscirne, come per Spring.Ragioni come ragioni a Spring, non come ragioni a Java.è assolutamente una cosa totalizzante, nel senso che è vero, è nato 15 tu come libreria di dependency injection e poi on top ci sono nati Spring Data, Spring Security, Spring IoT, Spring Laq qualunque per cui adesso tu puoi fare tutto con Spring ed è diventato appunto un framework che ti impone un modo di pensare e per carità ti risolve un sacco di problemi perché sono magari problemi noti su cui non vale la pena che tu stia a perdere la testa perché il tuo mestiere è un altro e la tua logica di business sta da un'altra parte.Però appunto a lungo andare ti incasella anche in una costruzione a fare tutte le cose con Spring quando magari non ce ne sarebbe bisogno esattamente come fai tu l'esempio di Windows Fetch.Vero, verissimo.Tra l'altro il ragionamento che facevo l'altro giorno da solo, stavo proprio ragionando sul concetto di framework, è il fatto che quel vantaggio di avere dei punti di riferimento globalmente condivisi, perché un framework fondamentalmente se parliamo dal punto di vista dello sviluppatore è quell'elemento dove alcune decisioni e quindi conseguenti punti di riferimento che vengono nella codebase da queste decisioni sono un elemento globalmente condiviso cioè se io uso symphony tutti sanno che i servizi si definiscono in quel modo.Quando mi arriva uno sviluppatore io non glielo devo dire perché già lavora con symphony, vede i servizi sa dove andarle a prendere quindi questo in realtà per chi vuole partire a palla è molto comodo.Il problema è sempre quella famosa coperta corta che se tiri troppo da una parte allora ti spogli e rimani scoperto dall'altra.Uno dei modi in realtà per preservare il nostro codice dai framework può essere quello dell'implementazione del domain driven design in modo da tenere completamente separata la logica di business da tutto il resto dell'ecosistema.Io, Strazio, ho visto che tu mi hai parlato e mi hai parlato anche riferendoti al mondo del front-end e quindi un po' la cosa mi ha incuriosito.Cosa vuol dire per te portare il domain-driven design nel front-end? Allora, significa, te lo dico in maniera molto brutale, ma cominciare a utilizzare il più possibile oggetti JavaScript puri.Sembra una cavolata, ma fondamentalmente in un'applicazione complessa ci sono pochissimi oggetti JavaScript che non hanno dipendenze da altre parti, ok? Il domain design nel front end è proprio una roba del tipo, guardate, che se dovete fare una validazione complessa, se devi fare una validazione particolarmente complessa, ad esempio di un ordine prima di evaderlo, puoi facilmente disegnarlo come un oggetto ok? Sto lasciando perdere poi classi, interfacce, perché in realtà poi quello non c'entra niente con il domain di design, quello è un'implementazione.È semplicemente il marcare il comportamento di un oggetto all'interno di un oggetto senza dipendenza esterna.Nel front-end questa cosa diventa difficile per due motivi.Uno, il primo motivo che dicevi te, socialmente non è accettato, nel senso la gente è abituata a ragionare con i framework, si trova davanti un oggetto senza dipendenze fa fatica a capire come lo si incasta all'interno di altro, ok? Perché a volte devi accettare dei compromessi, compromessi del tipo non ti funziona bene con l'idea del yoke di React, per dire.Perché? Perché tu hai un API che non è reattiva e quindi devi crearti degli adapter di qualche tipo, ok? Questa cosa qui, chi la guarda del primo acchitto, non dico che non la capisce, però ha una sensazione strana, non nel senso di disordine.D'altra è che manca letteratura, nel senso sul tema, nel senso che il domain driven design è sempre stato appannaggio del backend, se non sbaglio in painting, domain driven design, il famoso libro rosso è in Java, o Java C#, la voce sciarpa, adesso non mi ricordo, però è in quel tipo di linguaggio lì.Quindi manca completamente una letteratura sul front-end.Potrebbe anche essere giusto, qualcuno mi ha criticato, ho fatto un talk su questo a conferenze a Londra, una delle critiche che ho ricevuto è stata "il dominio non dovrebbe stare nel front-end", perché il front-end solo una delle declinazioni, in teoria, la logica dominia, una dovrebbe stare sul server.Sì, va bene, ok, però la verità è che se io ho un'applicazione frontend complessa non capisco perché, tanto voglio dire, per come oggi siamo abituati, no? Anche a lavorare da utilizzatori, io non accetto che compilo una form e poi il server mi da 400 perché faccio una bad request perché non passa un invariante di dominio, ok parliamoci chiaro, lo devo sapere mentre la sto scrivendo, io me lo aspetto così anche da utente e quindi è normale che parte di quei controlli valgano anche sul front end, parte di quei comportamenti.Vero, anche perché il border, il confine tra back end e front end più si va avanti più è sfumato.Io posso portare il caso di Hospital Run, non so se lo conoscete, dove praticamente una parte del sistema è solo front end che si collega a OCDB e non c'è un un back end.No esatto, il punto è un po' questo, nel senso che tu hai talmente tanta frammentazione anche lato back end, hai le lambda per esempio, quindi tu potresti fare una serie di funzioni stupide ma tenere molto controllo sul front end perché ti fa comodo tenendoli.Quindi per me è una roba che non regge, direi che in realtà il dominio è solo uno, deve stare da una parte.Però anche lì è un problema di comunicazione.Ho partecipato a qualche conferenza sul DDD, non ho mai sentito parlare di JavaScript o in generale di frontend, avrai qualcosa in odda anche se… e a conferenze JavaScript non ho mai sentito parlare di dominio.Si parla sì di business logic, ma non nell'ottica del dominio in design e della centralità del dominio rispetto all'applicazione.Se questo è un altro degli ambiti che sto esplorando, come vedi ogni tanto ho delle bolle nuove che voglio fare.No, no, no, anch'io in realtà è un periodo che sto provando a ragionare in quella direzione.Allora la mia domanda è quale delle varie tattiche, più che strategie, porteresti e e porti nel front end dal DDD? Allora sicuramente gli aggregati, nel senso che… allora in realtà le cose più semplici sono repository e service.Ok, li andiamo a vedere un attimo perché potrebbe esserci qualcuno che non sa cosa sono quindi… Allora aspetta, li andiamo a vedere e provo a spiegarteli a voce.Sì sì sì sì, beh è un podcast audio.Esatto hai ragione, già stavo prendendo il codice.Le slide.Eh ma qua le cose si fanno difficili anche perché siamo in un bar davanti a una birra a strada.Esatto.Allora in realtà, cominciamo dal repository, che è il concetto più semplice.Il repository è un qualcosa che ti serve per, la dico molto brutale, adesso qualcuno potrebbe avere l'aria di dire, ma sono anche quasi le 10, sono anche stanco, abbiate pietà, ma serve per prendere e salvare oggetti da un qualche tipo di storage, di qualche tipo, ok? E questo storage deve essere indipendente, scusa, la forma di questo repository indipendente dalla sorgente dati.Cioè posso prenderli da un database, da un file in memoria e in questo modo l'applicazione non si deve rompere.Questa è la logica.Ma in realtà questa cosa qui, che è un concetto base del DDD tattico, è una roba che noi facciamo sempre sul frontend, perché noi scarichiamo dei JSON da dei server, di solito, che restituiscono delle promise.E guarda un po', è un'interfaccia standard del JavaScript.Quindi in realtà quello che io faccio spesso quando devo cominciare a sviluppare e non ho ben idea di come saranno fatti i JSON, io me li genero localmente e me li restituisco con delle promise, perché perlomeno non romperò tutto nel momento in cui metterò una base dei dati veri.Questo sembra un concetto stupido, ma in realtà già rendelo palese ai frontender di far parlare la stessa lingua dei colleghi backender.E' importante, ed è paradossale, è anche abbastanza ironico, visto che il DDD fa anche una capa tanta, come direbbe mia nonna parlando dell'ubiquitous language, eppure in realtà i frontender hanno sempre usato delle stesse tecniche dei backender senza saperlo.E se ci pensate da un punto di vista, come dire, architetturale, è esattamente la stessa cosa.Un server rest, per me, è un database, anche perché rest di solito espone delle operazioni che sono delle crude, fondamentalmente, su delle risorse.E quindi è molto simile a un database, tant'è che per usare come repository anche su un backend, dell'API REST dell'altra parte.Quindi questa è proprio la cosa che quando la racconti la gente effettivamente fa "ah, hai ragione".L'altra poi invece sono gli aggregati.Gli aggregati sono, ho detto già questo è più complicato, ma fondamentalmente sono degli oggetti di dominio che mescolano più entità, più entità di database o JSON, ok? REST, e fanno sì che le regole che regolano queste entità siano costanti all'interno del dominio, le famose invarianti queste si chiamano.La seconda esempio è ordine e riga d'ordine.Non posso creare una riga d'ordine se non c'è l'ordine.Non posso cancellare una riga d'ordine se l'ordine è evaso.Sono tipo di relazioni, che di solito sono due entità separate, ordine e riga d'ordine, ma l'ordine come aggregato viene gestito da solo.Ad esempio, trovo molto comodo utilizzare gli aggregati a volte per fare validazione di form o stati complessi del frontend.Però, questi sono anche paroloni, fondamentalmente gli aggregati sono dei grossi oggetti JavaScript dei metodi, l'unica cosa è che devono essere immutabili, nel senso se io ho riga d'ordine non posso fare una push su quella array, ma devo fare un metodo che si chiama aggiungi riga d'ordine, perché? Perché dentro quel metodo devo mettere dei controlli, però voglio dire l'immutabilità, un deep clone dello dash è object freeze, adesso scusate, non volevo farlo più semplice di quello che è, però effettivamente si può già ottenere buoni risultati.Tant'è che è quello che poi faccio in quel talk che avevi citato.Si si.Grossi object freeze fondamentalmente.Vero.Tra l'altro un'altra cosa che in realtà è presente, non strettamente legata al DDD ma che va così di pari passo con quel mondo e quel modo di lavorare è l'event sourcing.Nel front end ne abbiamo a cassette come si dalle nostre parti.Esattamente, nel senso che quando Redux saltò alla ribalta ebbe due stati d'animo, era un bipolare, nel senso che da un lato era "ah, che figo!", e che comunque effettivamente c'era a dire che il talk di Lehmann che presentò Redux era abbastanza elettrizzante, come era fatto, e anche in realtà aveva un senso quello che diceva.Dall'altra, però, è fondamentalmente eventsourcing per il frontend.È vero che non c'è molta della liturgia che c'è dietro eventsourcing, però parliamoci chiaro.Eventi che cambiano un'unica sorgente dati.A livello architetturale di alto livello assomigliava come idea.Eppure i front-end si sono tutti buttati su Redux senza ascoltare quelli che Evansourcing l'avevano usato per anni, dicendo "guardate che non è che va usato dappertutto perché comunque ha delle complessità".Nel senso, se dovete fare una to-do list, guardate che il classico database con create, insert, update e delete va più che bene.però ecco vedi torniamo sempre lì e il non riuscire a capire le conseguenze delle scelte guarda hai toccato una ferita aperta ancora sanguinante che sto cercando di far rimarginare perché tipo è da una settimana che ho finito un progetto basato su Next.js con uno stato Redux, le saga e lo stato si andava a sincronizzare tra la parte server, side rendering, la parte del server, la parte del frontend...un delirio totale quando in realtà si poteva semplicemente fare una roba super easy, super semplice senza piangere.No, la volevo semplificare troppo perché poi in realtà non volevo...c'è ci sono delle cose sensate, per esempio una volta in un progetto, grazie a Redux, abbiamo creato degli eventi impotenti tra client e server, da una parte c'era il rinsourcing, alcuni degli eventi del database, del back-end venivano mappati con un socket sul client e viceversa, quindi puoi creare anche delle cose interessanti, però non era venuto in mente a nessuno dei dei back-ender e dei front-ender.E' un po' questo il punto.Non parlando la stessa lingua non si capiscono.Ritorniamo sempre al concetto che serve un po' di consapevolezza dello strumento che si usa.Perché noi è vero che possiamo mettere un chiodo con la chiave inglese, poi però quando sfondiamo il cartongesso e nostra moglie non ci parla per una settimana forse cioè un problema ce l'abbiamo quindi fermarci un attimo per capire quello che stiamo usando ovvero è che nel mondo javascript con la javascript fatigue è complesso ma è anche una delle nostre responsabilità il tempo corre e io in realtà ho tipo una marea di domande da farti Ma volevo passare a un altro concetto che vedo che stai portando un po' in giro e quindi volevo fermarmi un attimo su questo.Allora è uscito il tuo libro "Decision Making for Software Development Teams".Non è ancora finito, è sull'Inpub.Ok, ma di che parla? Parla di alcune tecniche e attenzioni che i team di sviluppo software dovrebbero tenere a considerazione quando prendono decisioni, diciamo, critiche, diciamo così, linguaggi, framework, architetture, cose di questo tipo qua.Nel senso, questa è a grande linea di cosa parla.Ci sono un paio di casi studio, uno lo sto scrivendo adesso, uno è già uscito, e poi una serie di esercizi che sono quelli che poi io come consulente e flowing come azienda facciamo o aiutiamo a fare quando bisogna partire con un progetto nuovo o un progetto legacy.In realtà perché i progetti legacy la gente se li dimentica spesso, però in realtà vanno a mangiare un sacco di gente.Parla praticamente un po' di questo, nel devi scegliere un nuovo tool, devi scegliere se andare al microservizio o no, ok, non ti posso dire sì o no, ti posso aiutare a dire quali sono le domande che ti devi fare e poi capirlo da solo, fondamentalmente.È un libro molto più teorico del primo, non c'è codice, è anche molto più difficile da scrivere, ho scoperto scrivendolo.In realtà pensavo a una cosa mentre stavi parlando, che è una cosa che un amico mi ricorda sempre, che è la famosa legge di Conway, spero di citarla bene, un certo Mattia me la ricorda sempre, ogni volta che ci sentiamo.Allora io lo so che la stavi pensando te questa domanda.Abbiamo parlato di organizzazioni, abbiamo parlato di codice e allora la mia domanda è secondo te come l'organizzazione lascia la sua impronta nel codice che va a realizzare? Questa è una bella domanda.La legge di Conway dice proprio questo, che ogni organizzazione che disegna sistemi, crea sistemi che sono copie della struttura comunicativa dell'azienda.In che modo? In che modo è difficile da definire, però l'esempio più palese che noi abbiamo il mondo dello sviluppo software è il mondo DevOps.Il mondo DevOps è nato perché fa quella che viene chiamata di solito "manovra inversa di Conway", e cioè, se la legge di Conway è vera, quindi tu sei obbligato anche per regole mentali non scritte a scrivere il codice di merda se la tua organizzazione è di merda, e questo è quello che dice Conway in maniera molto più aulica di me.Il punto è, tu potresti rovesciare il meccanismo e dire "ok, costruisco la mia organizzazione in modo tale che quell'architettura software in particolare venga bene".E questo è qui che secondo me poi nasce, probabilmente il DevOps.Nasce perché c'erano gli Ops, c'erano i Dev.Nasce per risolvere un problema anche se ci pensate all'organizzativo non è mai stato tecnico di per sé, perché la legge di Conway faceva sì che tu potevi sviluppare con il tuo bello Scrum e ogni due settimane tu facevi le tue belle user stories e il tuo prodotto andava avanti, ma se poi gli ops non lo pubblicano, tu non hai il vero feedback, cioè il feedback dal tuo produttone, ma nessuno sta suonando il tuo codice.Questo è l'emblema della legge di Conway per quanto riguarda noi.Altri esempi più sottili sono gli esempi micro servizi.I micro servizi funzionano se hai dei piccoli team che sono abbastanza autonomi.Perché? Perché se no, se io ho un team che lavora da solo le 50 persone, ok che posso avere 20 deploy, come dire, separati e indipendenti, ma la verità è che se ho del, come dire, se ragiono come un team da monolite produrrò dei microservizi che sono talmente interdipendenti da loro che saranno peggio di monolite.Questo è un esempio.Un'altra roba che ho letto ed è interessante è che spesso quando si vuole introdurre un microservizio all'interno di un'organizzazione, si cambia anche un po' l'organizzazione dei team.Per questo motivo, perché se lavori in maniera che è o monolitica o a silos, questa cosa si repercuote poi nei processi e poi anche nel codice, perché se io non ho feedback dal mio codice per mesi, poi ce l'ho tutto in una botta, perché c'ho la demo day in cui gli ops pubblicano tutto, indovinate un po' quanto sarà bello il mio codice a sei mesi e un giorno quando devo lavorare di notte per fare bar fixi.E questo secondo me è il concetto, cioè il modo in cui si rende palese nel nostro lavoro la legge di Conway.Mentre parlavi facevo un esercizio mentale, forse sarò matto io, senza forse, e provavo a portare tutto il ragionamento che stavi facendo sulla legge di Conway al ragionamento invece che abbiamo fatto prima sull'uso del feedback e del framework.Cioè è possibile che uno dei problemi che abbiamo con i framework è che spesso non c'è un fit 1 a 1 con l'organizzazione? Non so, questa è una domanda che mi stavo provando a porre.Allora, non sono certo che le cose siano collegate, quello che è certo è che c'è un antipattern decisionale che io vedo sempre, spesso, che viene chiamato, e che c'entra invece con l'organizzazione e con i framework, che io chiamo in inglese "the usual path", cioè la solita strada.Cioè quelle aziende o quei team che possono passare dieci anni e hanno fatto tutti i prodotti, tutte le feature, tutte con lo stesso stack tecnologico.Facendole, ok, e quindi tu le guardi e da fuori dici "ma non è possibile, come fai ancora oggi a usare AngularJS?" Quello di solito, sempre perché Poretta è brava per questo AngularJS, come se potrebbe ucciderne altri 10.000, questo ad esempio è un anti-pattern che viene dall'organizzazione, perché quando parli con questi team, vengono fuori spesso due cose principali.Il primo è… tre cose, scusate, abbiamo scadenze impossibili e quindi non possiamo permetterci di sbagliare, quindi dobbiamo sempre andare con la cosa che conosciamo meglio.E l'altra è "non abbiamo tempo per imparare" e quindi non mi sento pronto, poi c'è la sindrome dell'impostore e tutto il resto, non mi sento pronto a lavorare con React perché non ho mai avuto tempo di studiarlo.Ma tutte e due poi vengono aggravate dalla blame culture che spesso c'è nell'azienda dell'informatica, cioè hai una scadenza stringente che magari è anche giusta, io non sto criticando l'esistenza della deadline, nel senso che la deadline può anche essere un vincolo sensato da un punto di vista ingegneristico, nel senso che l'ingegneria e l'arte è compromesso, quindi da qualche parte dei paletti qualcuno li deve mettere, se vuoi fare l'ingegnere, se no non funziona.Sono un'azienda di architetto, e tutti i miei amici vengono dal mondo edile, quindi in realtà io le botte architettura contro ingegneria le ho beccate da quando ho 16 anni, quindi sono preparatissimo su le due scuole di pensiero.Però ecco, a parte gli scherzi, può essere che c'è una deadline stringente, ma il problema nasce quando quel team si sente colpevole dell'eventuale ritardo e quindi quello che fa è, per non prendermi la colpa, io faccio la scelta più sicura.E questa è una cosa che io ho visto capitare spessissimo nei team.Anche poi in situazioni disparate.Una volta ho collaborato con un'azienda, questa è divertente, che era fortissima in Fox Pro, Visual Fox Pro.È uno di quei linguaggi visuali tipo VB6, che andava da moda fino anni '90, finché nei primi anni 2000, 2002-2003, Microsoft, no scusate, era più avanti, nel 2002 era l'ultima versione.Nel 2008-2009 Microsoft disse "basta, avete stufato, non è più compatibile con nessun sistema operativo da qui in avanti".Queste aziende erano talmente disparate, perché erano vent'anni che sapevano lavorare solo in FoxPro, che proposero, ancora me lo ricordo, di comprare dei pc con dentro Windows XP ai clienti per continuare a fargli usare il loro software.Per dirvi come è capito, è l'Iepalese che è un problema organizzativo e non è un problema di codice.Allora lo fai apposta, cioè tu veramente stai riportando alla galla tutte le mie sofferenze più grandi, io per anni sono stato uno sviluppatore ActionScript, quindi questo dolore l'ho vissuto.tra l'altro mentre parlavi di domain driven design sul front end io davvero il primo approccio al domain driven design tipo value object, DTO, li avevo visti in action script un gozziliardio anni fa.No però quello che dici è sacrosanto quindi alla fine tu dici il vero problema è di natura organizzativa, è di natura contrattuale e comunque si poggia su questo tipo di basi, no? Sì, non tutto, nel senso che non è che gli sviluppatori sbagliano anche perché sbagliano, amano la moda, c'è una serie di problemi, ma io stesso, non è che lo sto dicendo dall'altro una torre da Borio.Però sì, l'organizzazione, la cultura aziendale spesso ha un impatto molto profondo e molto nascosto su questo tipo di problemi.L'esempio di FoxPro è palese, nel senso che erano talmente disperati che volevano comprare i PC, quando arrivi a quel punto non è "Mandover, vendor, lock-in", c'è qualcosa di più.Hai continuato a fare eroi tecnologici talmente profondi che sono diventate l'unica cosa che ti tiene in piedi.Trovo sempre molto interessante.Alla fine abbassi la Claire perché poi soccombi, mi viene in mente la Mi-Varra se dovessimo parlare di televisore.Abbiamo parlato un po' in realtà di tutto quello che mi è venuto in mente di chiederti.Chiedo a Mattia se invece ha qualcosa da chiedere.No in realtà no, nel senso che appunto mi interessava un sacco questa cosa della Luigi di Pong e di come effettivamente tante architetture poi ma qui l'organizzazione aziendale più che un vero problema tecnologico e avalle il tema appunto della strada più comune che è una cosa su cui tutti ci siamo fatti male, credo, due volte.Quindi io aggiungo solo il mio dolore comune, non è legato ad ActionScape come quello di Mauro, ma appunto avendo già fatto Coming Out come esperto di Spring immagino che possiate capire quanto io abbia visto delle cose fatte con Spring dove Spring non serviva perché abbiamo sempre usato Spring Raga c'è stato un periodo della mia vita che io installavo Symfony per fare applicazioni a linea di command line application Quindi non sapete...Beh, lo facete tutti C'è questa roba gigante No, invece adesso una domanda mi è venuta in mente Partendo dallo Stratz Junior, allo Stratz che invece si mette questo tipo di problemi e si fa questo tipo di domande, e dovendo riassumere il percorso professionale in step, pietremiliari, qual è stato il percorso proprio che ti ha portato a ragionare di queste cose partendo dal codice? LM: "che domandona per le 10.10, ci penso.Allora, in realtà, io ho iniziato la mia carriera professionale in situazione veramente critica, nel senso che ero entrato in un'azienda dove cercavano un amatore Java per un progetto molto molto grande, in un'azienda che storicamente non conosceva Java.Era un team di 7-8 persone, quindi anche abbastanza corposo, però sai, sai come, quando tu fai partire un nuovo prodotto e sei nuovo, sei l'unico che ci lavora otto ore al giorno.Gli altri, come dire, hanno lo strascico, ok? E quindi ero trovato a degli stack che non conoscevo, mi sono buttato un po' dappertutto.Quindi ho visto tante cose velocemente, tutte male, in senso questo lo ammetto, cioè in senso veramente delle robe di cui non avevo capito assolutamente niente, però i framework effettivamente mi avevano aiutato.Dopo quella fase, in realtà c'è stata una fase interessante in cui, questa è una cosa che penso non l'ho mai raccontato nella stessa sessione in cui parlavo di framework, ma in cui per due anni ho sviluppato un framework Java per l'azienda in cui lavoravo, interno, per sviluppo interno.E quello mi ha fatto capire tante cose, cioè nel senso ho fatto capire che stavo nascondendo complessità ai miei colleghi e stavo risolvendo il problema sbagliato.Avrei dovuto aiutare a crescere i miei colleghi, invece stavo nascondendo il problema dietro a College.Questa è stata la prima volta che ho cominciato a capire qual era il problema, perché mi sono trovato casualmente al centro di quel problema lì.E poi casualmente in quel periodo, abitavo nelle Marche all'epoca, ero andato a una Gile Day proprio da Ancona, in cui Matteo Vaccari parlava di semplicità dell'architettura, se non sbaglio, e lui fece vedere una sephirlet in Java dicendo che in realtà per scrivere cosa dice bene, basta partire da lì e non da Spring.E da lì, l'anno dopo, cambiai azienda, ero in un ambiente un pochettino più vivace, domande più interessanti, ed eccoci qua.La domanda sul cosa serve per rendere un'applicazione eterna, ecco.Quindi sì, nel senso, in realtà, non saprei replicarlo, nel senso che mi sono trovato per caso dove affrontare una cosa che era più grande di me e da cui sbagliai completamente il punto di vista.Poi ecco, ci è voluto qualcuno che mi prendesse a sberlo.Ci sono state un altro paio di occasioni in cui qualcuno mi fece notare che, a prescindere da quello che potevo scrivere, stavo risolvendo il problema sbagliato.Allora ho cominciato a capire che il codice non era tutto.Nel senso che nella mia mente di ingegnere informatico era ovvio che il codice fosse tutto e invece crescendo mi fecero capire che non era quello il punto.Però la verità è che sono partito dal framework, c'è poco da fare.Mi piacerebbe dire a un junior o al me junior di partire da design pattern, di partire da clean code, di partire da domain driven design, ma la verità è che per fare quello devi già avere una maturità purtroppo che possono dare solo i framework perché hai bisogno di qualcuno che ti dà l'omogenizzato quello purtroppo è imprescindibile secondo me quindi non demonizzo i framework anche per questo nel senso che poi in realtà io ho imparato come si fa alcune robe su javascript studiando il codice di angular non perché di angular js, non perché sia particolarmente dotato in javascript No hai ragione, credo che in realtà, a parte che tutto quello che hai detto è sacrosanto, ma credo che in realtà è importante capire che per arrivare a questo livello di consapevolezza si deve partire dal problema, per partire dal problema lo si deve vivere il problema, viverlo ci si deve mettere nella condizione di appunto di farlo apparire nella nostra strada in quella condizione alle volte ci si arriva quasi sempre mettendosi a fare qualcosa e quindi anche utilizzando i framework e qua mi ricollega una frase che il buon Mattia hai da dire qualcosa? No no vai vai Sì, sì, sì, ho alzato la mano perché in effetti è una cosa che ha detto Straccia rispetto all'utilità dei framework come tool di apprendimento e di acquisizione di esperienza, secondo me è importantissimo, nel senso che è vero che quando sei uno sviluppatore esperto, se vuoi passate di termine senior, ragioni in termini di design pattern, hai hai letto un code e lo sai applicare e quello che vuoi, ma invece se tu hai appena iniziato a lavorare non riesci a pensare in quell'ottica lì perché hai bisogno del framework che ti aiuta.E rispetto a questa cosa mi viene in mente una conversazione che ho avuto tanto tempo fa con Gabriele Lama, che è di più grande esperienza di cui mi fido, e ci dicevamo che quello che distingue probabilmente uno sviluppatore esperto da uno sviluppatore meno esperto è la quantità di cicatrici che ti sei fatto, sbattendo la testa magari su un limite del framework che stavi usando e andando a vedere come funziona e perché il framework che stavi usando funziona in quel modo che non è quello che ti aspettavi e magari imparando appunto come fa il framework a fare una cosa che vuoi fare tu.E a quel punto ti sei fatto quella cicatrice lì e hai imparato un modo di fare le cose che per il quale però ti serviva avere un framework prima, perché magari non avresti approcciato il problema in quel modo, magari non saresti nemmeno arrivato a quel punto senza la riduzione di attrito che ti dà il framework all'inizio.Quindi secondo me c'è un grosso valore di facilitazione della curva di apprendimento nell'uso di un framework.Poi è vero che a un certo punto, quando diventi esperto, sei in grado di superarlo il framework.Però prima devi conoscere le regole del gioco per riuscire a giocare con le tue poi.Chiaro, beh sì in realtà capisci solo dopo aver fatto un macello che lo zabbaglione col trappano non si monta.LM: "è una questione di cicatrici, ma è anche una questione del senso di proprio di… ti devi trovare a affrontare problemi che non sai risolvere.La prima volta che ho approcciato un meccanismo di rendering totalmente front-end, senza framework, era in una situazione abbastanza critica, nel senso lavoravamo per una banca, questa banca vogliava un rifacimento AJAX, rendevo più interattivo un'applicazione bancaria, che era molto statica, perché era tutta server based.Però, magia delle magie, non potevamo aggiungere dipendenze, se non jQuery che già c'era, perché se no dovevamo chiedere l'autorizzazione del CTO della banca, cioè una roba tipo mandare mail, fax, una roba incredibile, e quindi lì ho detto "ok".E niente, all'inizio stava un macello, avevamo solo jQuery e una libreria per le utilities, una specie di load hash antelitram, ancora prima di underscore.E niente, lì con le string, con catenazione, fu un delirio, cioè nel senso fu tipo un un mese, ma fu panico totale, e poi a tempo comodo, ok, cosa avrei potuto fare meglio? Però ecco, quello per dire che a volte sono situazioni che capitano, sembra strano, però in realtà può succedere di dover andare a scrivere un meccanismo di rendering o di event handling a mano nel front end.Perché a volte qualcuno mi dice "ma perché è codice che tu non lo saresti mai.In realtà non è vero.Non sono fatto lavori particolarmente brutti, perché può essere uno sfortunato, però a me è capitato.Le situazioni anomali in cui devi attaccare ai frame uno dentro l'altro, poi nel frontend può capitare veramente di tutto o di più sotto alcuni aspetti.E quindi sì, sono le cicatrici.Quello mi ha segnato è stato un mese in cui non dormivo la notte e poi non è che il risultato è stato bello.Cioè stavo in bacello e il colice faceva pena.Però ho imparato.No però prendo quello che hai detto come spunto per dire un'altra cosa.Io come te faccio il consulente quindi in realtà ci troviamo a dare consulente a delle aziende che hanno bisogno di fare degli improvement in certe aree specifiche e secondo me un po' il vero approccio del senior sta nell'arrivare in queste codebase un po' X con la consapevolezza e la conoscenza che viene da questi framework e saper giocare ste carte anche dove ci sono dei limiti, degli ostacoli che per altri sono o causa di codice di merda oppure insuperabili quindi in realtà la consapevolezza proprio è l'utilizzo del frameworkless In questo approccio chiedo che sia centratissimo.Sì, a nord è vero, il talk che mi hai citato prima sul DD nel front end viene da un caso reale di refactoring.Perché? Perché il team del cliente voleva aggiungere un altro framework dentro il vecchio framework.detto no, no, prima mettiamo in sicurezza quello che c'è togliendolo dal framework che c'è adesso e quindi lì poi architettura esagonale e poi di di di.Sì, me trovo di accordo, però il problema è che purtroppo c'è il passaggio di pancia a terra, nel senso non vede un'altra strada se non quella di provare uno, due framework, fai passare il ciclo di vita, quindi per arrivare a quel punto in cui ti rendi conto che il tool che stai usando non è abbastanza, perché o è passato e non può essere più utilizzato, o perché ha dei limiti, il famoso 10% che occupa il 90% del tempo, però non è una roba che puoi raccontare e dire "fate come me".Quello che puoi fare sì è dire "questa cosa se fa così, però penso che su certi argomenti uno ci debba passare per forza addosso in un certo modo.Io credo che vista l'ora possiamo anche accingerci a chiudere l'episodio di oggi, però come nostro solito non prima di aver dedicato qualche istante al momento il paese dei balocchi cioè quel momento dove condividiamo qualcosa che ci ha catturato l'attenzione che sia esso un libro un talk un pezzo di codice qualunque cosa quindi straz la mia domanda è cosa ci porti in dote oggi? Vi conduco nel paese dei balocchi.Ah il paese dei balocchi.Allora vi porto un libro che sto leggendo, mi sta piacendo molto, che è "From Objects to Functions" di Uberto Barbini, che è un libro...È stratosferico, ho fatto Tecnical Review della prima metà, è clamoroso.È bellissimo, infatti l'ho comprato ancora in beta e...Ho rotto le palle a tutto il gruppo Telegram per mesi mentre facevo Technical Review, è veramente stupendo.Io lo adoro anche perché poi adoro Kotlin, nel senso, in realtà penso che Kotlin sia veramente l'anello di congiunzione che ha portato Java nel mondo moderno, nel senso perché tutto debotto poi.Io giuro che non ci siamo messi d'accordo su questa cosa, ma c'è una puntata intera del podcast in cui io dico esattamente questa cosa.e penso che quel libro sia poi quello che manca ai programmatori Java per fare il salto, nel senso che toglie un po' di quella mutabilità che tutti già visti hanno nell'anima, che tanto è così, nel senso che hanno insegnato che il code si fa con i setter, è così, uno dopo vent'anni non te lo toglie.Quel libro invece ti aiuta molto.E il fatto che è fatto in Kotlin e per me è indice il fatto che Kotlin ha centrato dove altre linguaggie hanno fallito, semplicemente perché è incredibilmente pragmatico, cioè nel senso è funzionale, ma è il giusto che permetti anche a un giornalista medio di portare un sacco di valori, semplicemente togliendoti la mutabilità degli oggetti con poche righe.Questo è un libro che fa il salto, questo se lo devo dire, mi ha colpito particolarmente.L'ho segnato e lo recupero subitissimo.Mattia tu hai qualcosa? Vedo la tua faccia del tipo "no".Sono assolutamente impreparato.Tranquillo, nessun problema, io però ho qualcosa.In in realtà il mio balocco lo ho rubato a Straz, anzi ce l'ha regalato lui quindi è un suo balocco, sono due codici sconto per i suoi i suoi libri che ricordiamo i cui titoli sono facile così.I titoli sono "Frameworkless Frontend Development" e "Decision Making for Software Development Teams".Li mettiamo nelle note dell'episodio e intanto ringraziamo Strats per averceli condivisi.In realtà il mio vero balocco sono due libri che non ho iniziato ancora a leggere ma mi sono arrivati si promettono mi promettono di imparare gli algoritmi visto che praticamente non ci sono mai riuscito quando era all'università perché quello che ho imparato l'ho allegramente dimenticato come una parte di di noi ingegneri di re imparare gli algoritmi.Il titolo è "Algorithms Illuminated" scritto da un docente della Columbia.Sono scritti in modo...si promettono di essere abbastanza semplici e metabolizzabili con poca roba matematica e formule strane.È una serie di tre libri, ho acquistato i primi due.Il primo è "The Basics" e l'altro è "Graph algorithms e data structures e nulla quindi se vi interessa buttateci un occhio perché dalle recensioni che ho letto parevano più accessibili degli altri dove ho studiato ai tempi dell'università e che come vi dicevo prontamente dimenticato.Bene ormai si sono sono fatte le dieci e mezza dopo una giornata di lavoro insomma abbia fatto tutte e tre bella pesante che hai visto allora io vi accompagno ci accompagniamo alla porta del nostro bar finisco di dare l'ultimo passato l'ultima passata di straccio al bancone ringrazio strats per esserci venuta a trovare come noi solitamente diciamo sempre da oggi githbarra è anche tuo ti appartiene quindi vieni quando vuoi c'è sempre un angolino dove chiacchierare di queste cose in serenità bevendo una birra.Quando volete è molto piacevole ripasserò quando è finito il secondo libro.Ok allora ho una traccia da seguire mettiamo mettiamo la nota e ti aspettiamo sicuramente grazie anche a te Mattia per avermi fatto compagnia in questa serata con la voce calda è sempre un piacere sembri sembri Albertino di notte grazie grazie davvero ragazzi per sono l'Alessio Bertallot di Gitbar grazie davvero noi ci diamo appuntamento alla prossima settimana con un altro episodio ricordo rapidamente i contatti info@gitbar.it via email @brainrepo su twitter e il gruppo telegram mi raccomando se non l'avete ancora fatto iscrivetevi lasciate una recensione su Apple Podcast ditelo ad amici e parenti il bar è sempre aperto 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.
