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.Bene, benvenuti a un nuovo episodio di GITBAR.In questo episodio ho un ospite speciale, una persona che seguo da diverso tempo e che produce dei contenuti interessanti oltre che a regalare il suo tempo alle community in modo veramente veramente importante.Parliamo di Massimiliano Arione, lo conoscerete probabilmente col nickname di Gracchio, presidente del Pug Roma, uno storico membro del Grusp, attivissimo nel mondo dell'open source, infatti sue sono, qualcuno se lo ricorda, le traduzioni della documentazione di Symphony, è la traduzione, cosa di pochi mesi fa, del libro di Fabien su Symphony 5.Sviluppatore freelance, un ninja in PHP e Symfony e un amante del DDD.Ce l'abbiamo qua a Gitbar, Massimiliano Arione.Ciao, benvenuto! Ciao Mauro, grazie per l'ospitalità.Grazie a te per averci regalato un po' del tuo prezioso tempo che sappiamo, insomma, insomma avere un valore importante specie per un freelance che comunque immagino sia un freelance come te immagino sia particolarmente impegnato questo periodo.Ti faccio subito una domanda a brucia pelo.Tu sviluppi da tantissimi anni e hai focalizzato buona parte della tua attenzione sul linguaggio PHP ma perché il PHP? Beh dunque sì è vero io sviluppo dalla fine degli anni 90 poi sono diventato professionista solo nel 2001, però ho fatto alcuni anni giochicchiando.Per quel periodo sicuramente il VHP era esploso, stava proprio nel suo momento migliore e io, come un po' credo tutti quelli di quel periodo, l'avevo preso in considerazione perché era semplicissimo, consentiva di fare rapidamente delle cose e quindi di essere produttivi molto velocemente.cosa che tra l'altro era poi come ha ammesso lo stesso creatore del linguaggio, insomma un po' lo scopo con cui era stato creato.E poi negli anni però che è successo? Che io sicuramente penso di essere maturato insomma come sviluppatore e ho visto che anche il linguaggio però è maturato, insomma non è più quel linguaggio un po' da script kiddi se vogliamo, da quel linguaggio amatoriale, insomma è diventato un linguaggio che ha fatto dei passi molto importanti e per cui alla fine insomma io sono andato credo di pari passo insomma che è stata un'evoluzione mia, professionale, personale un'evoluzione del linguaggio per cui io mi trovo molto bene, ecco cosa posso dire? mi trovo molto bene con questo linguaggio, mi trovo bene anche con la community di questo linguaggio per cui ecco sono rimasto sicuramente anche per motivi affettivi insomma legato a questo linguaggio linguaggio poi non voglio dire che non ho approfondito qualcos'altro però questo è rimasto diciamo il mio il mio core.Sì è come il famoso meme che sì sei fidanzato ogni tanto butti un occhio alle ragazze che ti passano attorno ma sei comunque fedele alla tua compagna.Credo che questo possa essere davvero un'immagine che lo descriva.La mia domanda è ti sei mai sentito hai mai sentito i limiti del linguaggio nei progetti? probabilmente non tantissimo qualche volta sì spesso quando vado a guardare le feature che usciranno nella versione successiva o forse anche quelle successive ancora penso "vabbè effettivamente questa cosa mi mancava" per cui la vedo sempre in in prospettiva ecco, in una prospettiva da ottimista voglio dire, questa cosa ancora non c'è in PHP però ci sarà tra poco.Quindi la culina? Beh se ci sono sicuramente quindi voglio dire sappiamo che PHP non è un linguaggio perfetto è sicuramente perfezionabile però come dicevo prima ha il suo ritmo di miglioramento abbastanza costante anche poi negli ultimi anni.Credo proprio di sì e poi uno degli elementi importanti che vedo hai abbracciato a piene mani nella tua carriera professionale è il framework Symphony che secondo me subito dopo tutto il lavoro che aveva fatto Zend con il famoso Zend framework è riuscito a dare uno sprint e una spinta verso il mondo enterprise a questo linguaggio.Questo è il mio punto di vista poi può essere più o meno condiviso.Assolutamente con me sfondi una porta aperta insomma su questo lo sai.Perché la dico che comunque il background già vista di Fabian è riuscito a regalare a questo framework un approccio anche più enterprise Anche se devo dire che molto dell'hype dietro PHP in questo ultimo periodo lo sto vedendo dal mondo Laravel che invece è uno fratto symphony pur utilizzando i components però diciamo che è pieno di anti pattern permette un rad piacevole però alla fine se devi sviluppare un prodotto enterprise magari potresti avere dei limiti.Come vedi invece l'Aravel da sviluppatore symphony? beh hai detto bene che c'era un background da Java inizialmente per Symfony, ma in realtà secondo me ce n'era uno ancora più forte da Ruby on Rails negli anni 2000, quindi quando è nato Symfony 1 diciamo, quindi molto focalizzato sul RAD, molto focalizzato su costruire questi CRUD, sviluppare velocemente generare codici addirittura, quindi prendere file di confezione e generarci interi CRUD proprio in maniera automatica, non semiautomatica, proprio automatica e la Ravel secondo me è un po' il ritorno a quello lì a me la Ravel ricorda moltissimo Sinfoni 1 e quindi anche Rubio Rays un approccio che quindi punta molto alla velocità punta molto al prototipare velocemente che poi voglio dire potrebbe anche avere il suo senso effettivamente non solo in ottica adesso, ma molto inoltre, le start up in questa ottica qui potrebbe anche avere senso effettivamente Poi, parecchie volte però questo tipo di sviluppo si scontra con l'evoluzione.Io appunto avendo sviluppato vari progetti in Sinfonino, me ne sono accorto parecchie volte che finché si restava lì, nell'ambito dei crude, andava tutto benissimo, poi appena si usciva un attimo da quell'ambito, diventava molto complesso mettere mano a questi crude generati per farli diventare qualche cosa che fossero più aderenti alla logica di business.E per cui Lara tira molto verso questo approccio.Io lo capisco, capisco l'esigenza, non la condivido però perché purtroppo a lungo andare è un approccio che non rende.se il progetto si sviluppa ti porti dietro un debito tecnico che alla fine ti schiaccia assolutamente, assolutamente questo si però su symphony col tempo sono emerse anche tutta una serie di buone pratiche e una di queste è appunto il rich model quando si parla di rich model e dynamic model a cosa ci si riferisce Massimiliano? essenzialmente il rich model è un modello in cui effettivamente il modello è annesso al centro, è preso come punto di partenza.Quindi ci sono delle classi PHP, ovviamente dobbiamo molto semplificare per il tempo, che rappresentano gli oggetti di dominio che contengono la business logic e quindi questi oggetti consentono di gestire e anche di autovalidare la business logic, di tenerla tutta contenuta insomma è autovalidata.In opposizione a lui c'è il modello Anemic, che solitamente è quello tipico appunto dei crude, quindi un modello appiattito sulla persistenza, quindi ragionato direttamente sui campi delle tabelle e quindi come se avessimo proprio un database in cui poi accedendo a questo database noi possiamo fare quello che vogliamo, quindi cambiare qualsiasi valore senza poter conservare nessuna coerenza interna e quindi si fa tutto molto velocemente ma nel momento in cui bisogna assicurare dei vincoli perché il dominio più è complesso più ha dei vincoli e questo con la DemiCompat non siamo più in grado di farlo.E tra l'altro ci ritroviamo quindi queste classiche che alla fine sono piene semplicemente di metodi per accedere alla proprietà, per quindi scrivere o leggere le proprietà e magari nel momento in cui ci andiamo a mettere dei metodi veri quindi di business logic si perdono un po' in questo marasma di Getter e Setter.esatto di Getter e Setter, al contrario con Rich Model invece abbiamo tutte le classi più punite in cui abbiamo esclusivamente la logica di business appunto poi solo ci costruiamo tutto quello che è necessario per persistere eccetera eccetera sì assolutamente d'accordo con te, tra l'altro uno dei problemi appunto che scontro spesso anche con delle codebase un pochino vecchie su Symfony appunto quello di avere delle entità che sono quelle che poi tengono, dovrebbero ottenere nel nostro approccio la logica di business, annegate ai milioni di getter e setter.Esiste un modo per tenere le entit, quindi l'entità, in questo caso parliamo di symphony dove tu sei un ninja, modo per tenere le entiti più pulite pur in qualche modo interfacciandoci con, che ne so, i form di Sinfony o strumenti di questo tipo? Allora io vorrei fare un passo indietro Sinfony in realtà ha un'enorme flessibilità per cui effettivamente noi oggi possiamo usare anche Sinfony alla Laravel se vogliamo, no? Oppure al vecchio o alla Sinfony 1 quindi ci possiamo fare effettivamente anche i crude esistono anche dei progetti per esempio Easy Admin Bundle che effettivamente ti consentono di sviluppare con Symfony in questo modo, quindi entità anemiche eccetera eccetera, ma perché poi a monte diciamo lo stesso Doctrine consente questo approccio voglio dire, sia anemico che ricco.Ecco forse è proprio questa la potenza secondo me di Symfony, è proprio in questa flessibilità, in questo consentirti anche di sbagliare, diciamo anche di non avere approccio migliore possibile, però se tu lo vuoi avere lo puoi avere, altrimenti puoi anche averlo quello migliore, insomma, proprio perché ti lascia più spazio.Tornando alla tua domanda, il metodo per tenere le entità più isolate, quindi per fare meglio riccio domain model è quello di sicuramente innanzitutto non mapparle con le annotation, perché lì automaticamente ci siamo riportati ad entità anemiche, voglio dire, che conoscono la persistenza, che sanno troppo, perché come tu sai nel DDD ci sono degli strati, gli stati più bassi non devono conoscere quelli più alti, mentre deve vedere solo il contrario, quelli alti conoscono quelli bassi.- Le vediamo tra un pochino.- Quindi le senti di InSymphony sicuramente non devono essere annotate né con le annotation di doppio, né con le annotation della validazione, perché se facciamo Rich Model devono essere tutte valide già nel momento in cui vengono costruite.Per cui il sistema migliore è quello di farsi dei DTO e attaccarci su ORM di Symfony, mappare chiaramente alla fine mappiamo sempre su Doctrine perché è quello che abbiamo a disposizione.La mappatura di Doctrine su file di configurazione esterni, c'è chi preferisce YAML, c'è chi preferisce XML, non cambia molto.E i DTO appunto mappati su ORM e poi dal DTO si costruisce l'entità il suo stato valido.Mi sembra abbastanza semplice a dirlo poi magari implementarlo ci vuole un po' più di pratica però non è nemmeno difficile da implementare.Sì, probabilmente una delle cose che sento più spesso dire a quest'approccio anche da colleghi è quello che risulta particolarmente verboso, quello di dover scrivere un DTO, fare poi un entity a partire dal DTO.Hai qualche suggerimento in merito per semplificare o è diciamo una verbosità essenziale anche per fermarci un attimo e riflettere un pochino di più sulla struttura della nostra applicazione? L'obiezione che posso fare a questa critica è che avere più classi significa rispettare di più il principio della singola responsabilità che è un principio abbastanza importante.Quindi il DTO fa solo il DTO, l'entità fa solo l'entità, il form fa solo il form e quindi necessariamente bisogna avere più classico.Se ognuno deve fare solo una cosa e la deve fare bene, non posso mettere nel momento in cui carico l'entità invece di compiti che non gli competerebbero, necessariamente sto violando il principio di SRP per cui è ovvio che è un sistema che richiede di fare due classi al posto di una, tu dici "ho il doppio delle classi" però sono classi tutte più specifiche e necessariamente anche più piccole e quindi alla fine migliori, insomma, cioè migliori intendo che si possono capire meglio, si possono manutenere meglio, si possono evolvere più facilmente e questo è il discorso.Sì, quindi sono anche più facili da gestire.Io ripeto, quando proponevo questo approccio, alla fine l'abbiamo usato perché in un progetto dove la complessità di business era molto alta, ci siamo trovati davvero ad avere il progetto sviluppato con un crude e dire "no, questa roba non potrà mai funzionare così" e quindi abbiamo dovuto riscrivere tutto ripensando il modello in funzione appunto della logica di business, staccandoci completamente dal database in fase di analisi e poi trasformando appunto il database, collegandoci con la base di dati attraverso uno strato esterno che è lo strato appunto platform, diciamo così e quindi creando un livello di astrazione tra i due elementi uno dei problemi però che in quel progetto abbiamo avuto era quello che scrivendo anche tante entity con magari, sai, quando sviluppi l'aggregato poi alla fine ti rendi conto che dentro l'aggregato ci stanno anche n livelli di entity, no? Quindi ci siamo ritrovati a sbattere il muso, forse anche per una superficialità in termini di sviluppo, con il famoso N+1 query problem di Doctrine.Come suggerisci, o cosa suggerisci per gestire queste situazioni? non so se sono riuscito a spiegarmi bene.Sicuramente è un problema a cui prima o poi bisogna far fronte.Io consiglio di non preoccuparsi troppo presto, di non ottimizzare troppo presto, però sicuramente a un certo punto poi quando esce fuori bisogna in qualche modo risolverlo.risolverlo.Io non trovo particolar difficoltà a risolverlo dentro ai repository, quindi poi curando nello strato della persistenza le join di doctrine in modo appropriato, che poi diventeranno join del database sottostante.Però voglio dire, tornando a questo discorso della complessità e della logica di business secondo me questo approccio paga tantissimo quanto più la logica di business è effettivamente importante, insomma è complessa perché veramente si riesce anche a progetto avanzato ad aggiungere logica, modificare logica, togliere, mettere pezzi senza problemi.Però perché è stato tutto costruito in modo molto più accurato, più...tra l'altro la fine è aderente, perché poi non è quello che dobbiamo inseguire secondo me, non è l'aderenza alla realtà.Il modello si chiama modello proprio per questo, perché è qualche cosa che deve...- Rappresentare, in qualche modo.- Esatto, rappresentare qualche cosa di reale che poi sono le esigenze del nostro cliente.Giusto, una piccola domanda che poi si base e viene anche un pelino dalla mia esperienza.approcciando al rich model e animic model con zero competenze quando a suo tempo avevo visto il tuo talk e poi ho aperto questo mondo mi sono ritrovato poi a confrontarmi in modo un pochino più compiuto un pochino più completo col mondo del domain driven design il mio accento inglese fa schifissimo prendilo per quello che vuoi che cos'è il DDD e come ci può aiutare nell'appunto intercettare la complessità delle nostre applicazioni? Beh, l'IDE, come possiamo dire in italiano, è una progettazione guidata dal dominio, questa è alla fine la traduzione del termine, ed è una progettazione in cui appunto si parte dal dominio, quindi la fase importantissima è quella in cui insieme al cliente, inliamente con tutti gli stakeholders del progetto, si raccolgono i requisiti e quindi si butta giù proprio quello che è il dominio a livello proprio di entità, proprio di entità in senso astratto.questo è un lavoro importantissimo in cui spesso il cliente va anche un po' guidato perché ovviamente non essendo lui l'esperto di progettazione, essendo noi magari dobbiamo un po' anche guidarlo, è una fase importantissima che se viene svolta correttamente poi ci porterà a lavorare in maniera molto semplice ma anche in maniera corretta quindi dandoci anche una soddisfazione.Quindi una volta stabilito il dominio, poi si può costruire sopra il dominio semplicemente lo strato applicativo e sopra lo strato applicativo ci si mette lo strato infrastrutturale in cui poi interviene effettivamente il framework che può essere Sinfoni o può essere per me in realtà qualsiasi altro framework, perché diciamo che secondo me alla fine è più importante fare DDD che scegliere il framework, voglio dire.C'è anche gli ha fatto DDD con l'Aravel, gli ho guardato un tour di un l'Aravel Day sicuramente ho apprezzato tantissimo questo sforzo purtroppo la mia impressione è che poi in questo caso il framework ti rimane un po' contro e a questo punto che posso dire, meglio sceglierne uno che invece ti aiuta invece che uno che ti ostacola anche perché poi rischi di far uscire un mezzo Frankenstein con uno sforzo in mane da quel punto di vista è perfetto perché in realtà tu riesci a disaccoppiare completamente la logica di business dalla tuta l'apparato infrastrutturale per cui veramente riesci a gestirlo in modo eccezionale.Spesso nel mondo del domain driven design incontriamo concetti come l'entità, quelle che abbiamo visto poco fa, di cui parlavamo qualche minuto fa, ma anche gli aggregati.Cosa sono gli aggregati e come faccio io ad identificare che quel concetto nel dominio, quindi nel mondo che stiamo andando a modellare nella nostra applicazione, è un aggregato e non un'entità? Quali sono i consigli che dai per per riconoscere un aggregato? L'aggregato alla fine è un insieme di oggetti di domenica, insieme di identità che solitamente può essere isolato, può essere visto come un gruppo omogeneo.Non è sempre facile fare questa distinzione e capire qual è il punto in cui tracciare la linea di questo insieme.Ma comunque voglio dire, credo che uno possa anche, anzi io spesso preferisco magari sbagliare prima su questo aspetto e magari poi correggere e spostare qualche entità su un altro aggregato o trasformarla o trasformare qualcosa che non è un aggregato in un aggregato o viceversa.credo che sia anche lecito cambiare in corsa, non credo sia così importante aggregare molto presto.Questo voglio dire.Ah ok, quindi partiamo prima dalla rappresentazione delle entità e poi dovrebbe emergere l'aggregato.Esatto, anche perché alcune entità si aggreghino molto più facilmente di altre, quindi alcune si individuano molto velocemente e quindi lì si va un po' a botta sicura.Per altre invece è un po' più difficile, ma secondo me non bisogna nemmeno avere paura di rispostare, di rifattorizzare in questo senso.Non è che bisogna vederle troppo scolpite nella pietra.Ma questa poi è una linea guida molto generale, perché anche tutta la questione di cui accennavo prima della progettazione quella che fa emergere il dominio col cliente, pure lì non bisogna avere paura di modifiche in corsa che succedono, lo sappiamo, che succedono spessissimo.Una costante.Ma noi sappiamo anche che avendo organizzato poi il progetto con tutti questi accorgimenti saremmo in grado di accogliere questi cambiamenti in maniera molto più facile, mentre con l'approccio vecchio, ricordo che questo era un incubo, quando il cliente cambiava idea perché tutti dovevano metterli lì a rifare le cose, veramente era una cosa molto...che ti frustrava anche insomma a livello lavorativo, mentre adesso è proprio...è una cosa che ti migliora sia il lavoro, quindi il lavoro migliora l'umore, voglio dire, sia anche il rapporto col cliente che percepisce che le sue richieste di modifiche non vengono accolte sbuffando, ma dicendo "Vabbè, se tu mi dici che adesso è così, prima ce l'avevamo sbagliati..." Poi voglio dire, l'importante è che appunto, avendo chiarivenuto all'inizio, lui non possa dire "Ah, ma pensavo che avessimo detto così, invece abbiamo concordato insieme, se tu mi dici che c'è un cambiamento vuol dire che non l'abbiamo sevicellato bene all'inizio, probabilmente o forse ha cambiato qualche cosa nel frattempo".Comunque deve essere sempre un processo condiviso, molto condiviso.Sì io ti posso dire che quel tipo di lavoro sono riuscito in realtà a gestirlo abbastanza bene con le specifiche scritte in gherkin che dal mio punto di vista sono state veramente una svolta.Che cos'è? Questo lo dico anche soprattutto per i nostri ascoltatori.Sono delle specifiche scritte comunque in inglese ma tra l'altro so che esistono delle libri anche per farli in italiano non so quanto utile ma comunque esistono in modo che si possano scrivere queste specifiche in linguaggio quasi comune o comunque comprensibile al business che però poi girano come dei test sotto sotto il cofano quindi in realtà da là non si scappa o quantomeno si riesce a limitare anche questo tipo di comunicazione che Massimiliano stava stava evidenziando e secondo me ripeto mi han cambiato la vita o almeno l'hanno fatto quando sviluppavo con con quelle tecnologie.Quelle sono ottime secondo me in contesti in cui magari si lavora con aziende più strutturate quindi che probabilmente hanno un reparto di Q&A delicato voglio dire per cui lì veramente c'è qualcuno che ti segue da quel punto di vista.Io purtroppo non li utilizzo perché quasi tutti i miei clienti sono medio piccoli quindi mettere un ulteriore livello qui mi appresenterebbe un po' non vuol dire che non sia utile anche in questo caso qui secondo me potrebbero essere utili anche con clienti meglio piccoli però è magari un po' più difficile voglio dire è comunque un livello in più per cui assolutamente bisogna farsene carico magari quindi potrebbe diventare un po' pesante.si potrebbe schiacciarti tra l'altro perché se sei uno o due sviluppatori con un progetto piccolo da gestire con anche budget limitati no? perché viviamo in italia queste situazioni sono all'ordine del giorno specie magari anche per i freelance si verificano più spesso quando lavori in termini di progetti e non di prodotti queste situazioni si verificano però devo dire che in qualche modo sono state utili, sai come? per monitorare parti specifiche dell'applicazione che magari sono quelle un po' più delicate dal punto di vista del business dove magari anche il cliente usciva con delle astronavi è costretto, e quando lo costringi a scriverti le stories o ad aiutarti nella stesura delle stories percepisci anche la complessità delle stesse stories e quindi questo tipo di approccio aiuta anche a limitare lo scopo, il contesto della funzionalità.Devo dire che ci sono state delle situazioni dove anche in progetti piccoli, magari non tutto il progetto, però ci hanno aiutato.Ti è mai capitato di tirare su dei progetti dove magari una parte un pochino più delicata, come quella che ti stavo raccontando, è sviluppata secondo un approccio appunto di DD e invece accanto un altro modulo, altre funzionalità della stessa applicazione utilizzano un approccio un pelino più crude, like, quindi meno strutturato? In realtà no, la gran parte dei miei progetti sono persona singola, insomma dev singolo, io per cui io alla fine purtroppo non riesco più a fare le cose, una volta entri in questo meccanismo voglio dire non ci riesco più a fare le cose, a fare i crude, ecco, è più forte di me ti capisco, ti capisco assolutamente, io devo dire che in realtà in alcune parti di progetti abbiamo utilizzato questo approccio salvo poi ritrovarci in una grande palla di fango e e quindi portare a DDD anche quelle parti un pochino più...- beh sì, voglio dire, se uno poi fa un rapporto costi-benefici e vede che potrebbe risolvere una cosa in fretta sapendo poi che la deve rifattorizzare, quindi, diciamo, accumulandoci una piccola parte di debito tecnico voglio dire, perché no, non è che voglio fare l'assolutista però appunto valutando questi costi benefici quindi sapendo che comunque ci dovrei rimettere mano se poi invece ho una scusa per lasciarlo lì per sempre così allora meglio di no - altra domanda difficile anche puoi tranquillamente mandarmi a quel paese dopo questa domanda hai tutto il diritto di farlo quando si sviluppa utilizzando l'approccio del DDD spesso si rischia di cadere in una trappola quella di modellare tutto lo scibile umano.Noi sappiamo che il contesto anche quello aziendale o del processo aziendale che stiamo andando a modellare la nostra applicazione aziendale o meno è vasto.Cioè la realtà in realtà ha un'infinità di variabili e se noi andiamo a modellarla spesso siamo tentati di modellare tutte le possibili variabili con una marea di scope.Il DDD è la tua esperienza, ci mette a disposizione, ci mettono a disposizione degli strumenti per maneggiare questo tipo di complessità e questo tipo di trappola? Guarda sinceramente io non mi sono mai trovato in questa situazione, probabilmente perché, non lo so, forse non ho mai affrontato progetti enormemente complessi forse mi piace pensare sono riuscito a tenere a freno il cliente cercando di fargli capire che stavano cercando di mettere troppa carne sul fuoco per cui questa cosa qui voglio dire se stiamo modellando dobbiamo modellare tutto quello che c'è da modellare però ecco bisogna anche capire se effettivamente tutto quello che il cliente ci propone è effettivamente necessario.Poi non lo so, bisogna sempre cercare un equilibrio insomma, non bisogna mai appunto ragionare per assoluti.Però non so, forse non ho molta esperienza su questo specifico argomento per dare risposte allo Steven.Sei riuscito a gestirla sicuramente meglio di come abbiamo fatto noi.il ragionamento era appunto quello...io ti posso condividere la nostra esperienza alla fine siamo riusciti attraverso l'uso dei context, dei bounded context no? perdona, rinuovo il mio inglese cioè quello di dire ok, ragioniamo in questa parte di modello ma qual è lo scope? qual è il contesto? limitarne il contesto e poi magari sviluppi due entity che sono la stessa cosa vista da prospettive diverse però questo in realtà ci ha dato una grande mano per gestire questo tipo di complessità e questo tipo di sprint a modellare tutto da parte del business se riesci a spezzare e a sviluppare dei piccoli pezzi in modo limitato tutto il guadagnato io ho sempre usato approccio bottom up voglio dire ma credo che sia senza non mi sono inventato niente, credo che sia la cosa più logica da fare, sia in DDD sia anche prima.Il famoso "divida e t'impera".Quello, ma comunque voglio dire, credo che un po' tutto il concetto di sviluppo agile, adesso se vogliamo un attimo scavallare, si fondi un po' sul bottom up, insomma, e in contraposizione al top down del waterfall.assolutamente sì d'accordo d'accordo con te un'altra curiosità questo periodo non so perché ho un po' la fissa della programmazione funzionale e ho notato che in realtà i concetti del DDD stanno arrivando o sono arrivati e io ci arrivo un po' in ritardo possibile nel mondo della programmazione funzionale ed è una cosa che mi affascina particolarmente no? Il fatto che per esempio si possano usare i tipi per definire i modelli e invece tutto il resto delle operazioni, dei processi venga modellato attraverso le funzioni una cosa particolarmente interessante hai sentito parlare di questo approccio? Qual è la tua opinione in merito? non sono operatissimo sulla funzionale sicuramente ho visto delle cose interessantissime non so quanto PHP sia pronto per abbracciare il funzionale quantomeno mi sembra che quello che c'è di funzionale in PHP fino adesso forse sia un po' un compromesso esatto, sì, concordo con te a pieno proprio per cui io per adesso non mi sono lanciato ancora nella programmazione funzionale quindi non vorrei diciamo ecco sbilanciarti Esatto, su argomenti che conosco troppo in modo superficiale.Però vedo che...Però credo che...Guarda, credo che col DDD, voglio dire, si possa tranquillamente passare a funzionale nel momento in cui il linguaggio, diciamo, lo supporti a pieno senza stravolgere i processi, ecco.Sì, vero.Io, guarda, ti dico la verità, la cosa che più mi ha affascinato è che in realtà...poi il php ti ripeto l'ho un po' trascurato questo periodo però una cosa che mi ha affascinato tantissimo è il fatto che come dicevi prima, una cosa sacro santa, le entity devono essere valide sin dall'inizio che è un assunto imprescindibile e in realtà questo tipo di verifica, vederla fatta a quei tipi in realtà non so perché ma in qualche modo mi ha catturato l'attenzione e ho detto beh Allora con l'arrivo di strumenti come gli Union Types nelle prossime versioni di PHP o comunque un sistema di tipi un pochino più evoluto rispetto a quello che abbiamo adesso magari in un modo, come dicevo prima, un po' "Frankenstein" però qualche esperimento lo si può provare a fare anche solo magari per stimolare quelle esigenze che portano come dicevi prima a guardare oltre a trovare quella nuova feature da implementare poi nel linguaggio anche se non so quanto poi alla fine il php possa evolvere in quella direzione proprio a livello strutturale guarda su questo io posso consigliare senz'altro di guardare il talk di Marco Privetta del il PHPD del 2019, quindi l'ultimo attualmente perché 2020 siamo ancora in attesa, e lui ha fatto un talk che parlava proprio di...era molto incentrato sulla programmazione funzionale e a me è piaciuto molto.Ecco però mi ha lasciato con questa impressione come dire "questa potrebbe essere the next big thing, ma per adesso io non credo di essere in grado di metterci in mano.Però voglio dire lui era uno che parlava di "rich domain model" quando non c'era nessuno e quindi quando anche io forse non riuscivo a capire bene di cosa diavolo stesse parlando.Per cui posso pensare che se mantiene la sua fama di precursore dei tempi, anche in questo argomento nei prossimi anni...eh sì, beh sì.non so come, ripeto, perché vedo i limiti del linguaggio ad oggi anche se le fatta raw function elementini che un po' ci accompagnano verso quel mondo iniziano ad apparire anche un sistema dei tipi che piano piano sta diventando sempre più robusto sono sempre secondo me cose che si influenzano a vicenda, voglio dire le tecniche influenzano il linguaggio e il linguaggio influenza le tecniche.Il tolkai che tu hai ricordato, il mio tolkai all'inizio era proprio basato su questo principio, ti ricordi? Si basava sul fatto che io volevo passare a PHP 7, esatto, si ricorda, provando a mettere i tipi mi trovavo scontrarmi col modello nemico perché non potevo mettere questi tipi per cui la spinta per passare a Richelieu Ben Maudet a me è venuta da quell'evoluzione del linguaggio per cui quello che dici tu sulle prossime evoluzioni del linguaggio sicuramente sono assolutamente d'accordo.Rimaniamo comunque in attesa adesso della della nuova release di PHP che come dato Hulk di Enrico Zimmel ha tante sorprese nel cofano.Insomma, il php comunque in un modo o nell'altro sta correndo e sta si sta evolvendo anche abbastanza rapidamente dopo php 7 io credo che è mutato talmente velocemente, talmente tanto da poter dare agli sviluppatori quei tool che in realtà servivano per quegli elementi quelle strutture che poi servivano per poter sviluppare in modo moderno.devo dire anche se non mi convince appieno anche tutto il mondo magari della della reactive programming in php un po sta in qualche modo e della programmazione asincrona sta aprendo delle strade che poi vediamo se il linguaggio le batte le percorre o se le ignora certo è un argomento molto interessante anche quello io posso consigliare su questo allora mi perdonerai se sono in modalità pubblicità no devi anche perché poi avevo anche prevista una modalità pubblicità quindi stai tranquillissimo fai sentiti libero di dire quello che vuoi dunque l'ho proposto questo Manuel Baldassarri in modalità online perché è che è repentissimo, che lo abbia pubblicato un mese fa, forse poco più, poche settimane fa su Swole, quindi su PHP con Swole.Dovrebbe stare, credo, sul canale YouTube del Gruspo questo talk di Manuel.Ok, poi me lo vado a guardare e romperò le scattole anche a Manuel, magari, per venircelo a raccontare in uno di questi episodi, anche perché voglio comunque coprire un po' il linguaggio PHP che in questo periodo ho trascurato e che rimane comunque uno dei miei affetti più grandi quindi tra l'altro anche perché la community PHP è una community eccezionale e tu diciamo che sei uno dei pilastri sia come presidente del...no è la verità sia come presidente del Pugro ma sia come tutta l'attività che fai di mentoring anche sui social e io sono stato uno di quelli che ti ha rotto le scatole probabilmente non ti ricorderai di me ma ai primi anni penso di aver scritto una una ventina di domande una trentina di domande e tu rispondevi a tutte quindi come vedi questo tipo di lavoro? lo vedi come una missione? lo vedi come promozione? lo vedi come una crescita personale? come vedi il mondo delle community del mentoring dalla prospettiva di Massimiliano Arione? Dunque io molto semplicemente la vedo come un restituire quello che ho preso io ho preso tantissimo dalla community penso che tutto quello che so voglio dire l'ho imparato seguendo gli stimoli di altri in presentazioni, o lavorando insieme a qualcuno, nelle community, ho sempre ricevuto tantissimi stimoli e quindi darne a mia volta credo che sia proprio semplicemente un naturale processo per continuare questa diffusione del sapere, per cui io veramente lo faccio sempre molto volentieri.Qualche volta ho fatto anche un po' di formazione diciamo professionale, quindi a pagamento, non tantissimo devo dire, non è molto facile perché richiede un po' di organizzazione e io insomma non sono un manager, non sono, non è quello il mio lavoro, però anche lì voglio dire mi sarebbe anche piaciuto fare un'insegnante, perché no? Poi se magari c'è un giorno che fosse l'occasione non mi dispiacerebbe, trovo che sia un mestiere assolutamente appassionante.Guarda, io sto facendo formazione, ho provato qualche po' di mesi fa, mi ci son buttato e devo dire che in realtà la soddisfazione più grande, formazione, mentoring, poi metto tutto nello stesso calderone, è quando qualcuno realizza qualcosa dopo che ti ha chiesto delle informazioni perché tu non hai bisogno che ti dicano bravo, tu vedi che quella persona cresce e dici "caspita, vuol dire che nel mio piccolo, in quel lato io ho contribuito a fare anche quella cosa" quindi quella soddisfazione, quel essere pagato indietro che poi immagino abbia spinto anche le persone che hanno insegnato a noi.Se posso aggiungere una cosa importantissima è che nel momento in cui tu ti proponi per aiutare gli altri, ti proponi per insegnare non direttamente in modo classico, nel classico rapporto insegnante allievo, ma anche quello che è l'aiuto nelle community, in quel momento tu necessariamente devi fare uno sforzo per imparare, ovviamente qualcosa necessariamente già la sai, alprimenti non ti metteresti lì a insegnare cose che non sai, però devi comunque approfondire, devi comunque andare a rivedere delle cose, per cui questo è un processo in cui non solo tu passi della conoscenza ma acquisisci anche della conoscenza.e qualche anno fa c'era uno speaker che si chiamava Kodrabai e lui era così alto in clima, non ricordo esattamente il suo vero nome, che fece un keynote e lui disse proprio questa frase, mi è rimasta molto impressa che disse "ho imparato dai miei maestri, ho imparato molto anche dai miei colleghi ma ho imparato ancora di più dai miei allievi" Guarda, quello che hai appena detto è fondamentale ed è alla base di questo podcast.Perché il ragionamento che stai facendo è importante per due motivi.Il primo è quello che comunque il fatto di provare a insegnare qualcosa a qualcuno.C'era un grande fisico che diceva una cosa del genere che è l'unico modo reale che hai per imparare una cosa è quando provi a spiegarla.perché se tu non la conosci profondamente, non hai capito le dinamiche più intime, non potrai mai spiegarla la persona che avrai davanti non la capirà mai quindi devi fare uno sforzo d'apprendimento e di validazione e poi l'insegnamento diventa la validazione dell'apprendimento ed è un po' quello che faccio col podcast, quando mi studio un argomento e poi mi fermo e dico "ok, faccio l'esempio della reactive programming, come la posso raccontare affinché venga capito?" la devi capire bene profondamente per poi decidere magari di raccontare la reactive programing come un abbonamento a sottoscrizione che ne so a un giornale o qualcosa del genere.Quindi da quel punto di vista è importantissimo.È veramente importantissimo il confronto all'interno delle community cosa che in realtà mi ha mai il grado vuoi perché viaggio e mi è mancata tanto cioè gli eventi perché poi alla fine sai io sono su in Francia o sono in Sardegna e la Sardegna, perlomeno la mia zona, zona di Olbia, è un po' povera di questo tipo di community.Tu magari stando a Roma hai la possibilità di avere anche un mercato di colleghi che ti permettono di poterti confrontare in un certo modo.Qua insomma siamo un po' limitati da questo punto di vista.E gli eventi nazionali a cui ho partecipato sono stati diversi.Ne parlavamo con Stefano l'altro giorno perché in realtà il suo primo php day nel 2016 era anche il mio primo php day quindi lui veniva da Catania, io dalla Sardegna e ci siamo ritrovati catapultati in un mondo di stimoli, di opportunità, di esperienze alla fine fai un bilancio e posso dire che durante questi eventi io sono cresciuto cento volte tanto rispetto magari al lavoro che potevo fare da solo le letture che potevo fare da solo.Quindi il consiglio che do sempre è frequentate le community, andate al Pug Roma se siete da quelle parti e frequentate gli incontri perché la crescita professionale e anche le opportunità professionali, perché poi si apre comunque un mercato.Se hanno delle competenze in quei contesti spesso si riesce anche a trovare delle opportunità, è importantissimo.Prima di salutarci Massimiliano mi piacerebbe ricordare i tuoi contatti, come ti possono raggiungere anche a livello professionale, se qualcuno ti vuole contattare, a dei progetti, non so come funzioni, quindi fai tu.assolutamente io ho un piccolo sito vetrina massimilianoarione.it altrimenti solitamente cercandomi su google come massimilianoarione quindi nome e cognome mi si trova abbastanza facilmente in tutte le mie varie estensioni sociali quindi linkedin e via dicendo perfetto io massimiliano ti ringrazio infinitamente a nome mio e di tutti gli ascoltatori di github bar.Naturalmente ti romperò le scatole magari qualche altra occasione al prossimo talk che fai se vuoi venire qua a raccontarcelo sentiti a casa tua quindi le porte sono aperte quando vuoi sei libero di venire da noi a condividere con noi insomma le tue esperienze Naturalmente ti dobbiamo una birra per cui alla prima occasione utile che passeremo a Roma, giusto? Ci sentiamo liberi di romperti le scatole per invitarti una birra o una pizza compatibilmente con i tuoi impegni e nulla, grazie infinitamente, grazie davvero Grazie a te Mauro per questa opportunità GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e degli strumenti immancabili nella cassetta delle attrezzi dei fullstack dev.d'aria.[Musica]
