Bene e benvenuti su github bar siamo su github bar vero penso penso di sì Siamo su github bar italia siamo tantissimi ragazzi era era da tempo che non eravamo quasi così Tanti no da quando non c'eri te esatto quindi devo andare via Infatti con me c'è leo luca mattia Carmine, Andrea, insomma siamo davvero tanti e siamo pronti per fare una super puntata che sarà controversa, una delle più controverse di Gitbar, infatti parleremo di framework ognuno di noi ha un'arma Leo ha la mazzacchiodatta, Luca la lancia, Mattia la sciabola qualcuno la tromba Solo Boldo pigna per favore Assolutamente sì, siamo belli pronti per difendere con la spada i nostri framework preferiti tranne Luca che difenderà il non usare il framework, no? Assolutamente sì, sono qui per questo e qualcuno doveva farlo questo lavoro ho pescato la spiga più lunga o era la più corta, una delle due Siamo belli che pronti io però prima vi devo ricordare i nostri contatti info@gitbar.it la nostra mail.Gruppo Telegram, aprite il vostro client preferito di Telegram e potete trovarci digitando Gitbar.E tra l'altro mi sa che siamo quasi in 700 o più di 700? Dipende quando ascolteranno la puntata, probabilmente più di 700.Secondo la mostura siamo almeno 6.5.Ricordiamo comunque che al 1500esimo membro verrà regalata una tazza con il sangue di Jan Pol Bon.In realtà siamo ad oggi 636 quindi un po' lontani da 700 ma 700 è un traguardo che vogliamo vogliamo raggiungere.Detto questo però io direi che possiamo iniziare.Benvenuti su 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 prima cosa che mi viene da chiedervi è se noi dovessimo definire il significato di framework come potremmo definirlo? a questo punto mi faccio avanti io a questo punto direi no, dipende ovviamente dipende in realtà la mia definizione di framework è una definizione probabilmente sto spoilerando delle cose che avevamo in mente di dire dopo, è una definizione che esce in contrapposizione con un'altra definizione che è quella di libreria, nel senso che un framework, a differenza di una libreria, è un componente software che usi per fare delle cose che però ti impone il suo mindset e che quindi è molto più pervasivo rispetto alla tua applicazione di una libreria, nel senso che una libreria è un componente che usi per fare una cosa che può essere vasta o o meno, mentre un framework è un oggetto che ti impone anche il suo modo di ragionare.Nel mondo da cui arrivo io, che è quello Java, il framework è Spring, che ti impone il suo modo di fare le cose tantissimo.Non è tanto uno strumento per fare una cosa, ma è uno strumento per farci tutta l'applicazione e per avere quel modo di ragionare e di disegnare tutta poi, se vuoi, anche tutta l'architettura dell'applicazione.Quindi è una cosa che impatta sulla tua applicazione a un livello molto più profondo di una libreria che invece può essere contenuta per fare solo una cosa.Aggiungerei anche che un framework spesso utilizza delle librerie e non viceversa, quindi il discorso è che il framework è una cosa un po' più grossa, diciamo di regole che ti accetti nel momento in cui lo vuoi utilizzare per probabilmente semplificarti le cose.Alla fine il framework fa sì che la convenzione ti guidi nello sviluppo software, alla fine c'è tutta una serie di convenzioni che se segui puoi fare il software in quel modo lì, perché secondo me è anche la differenza, ad esempio nel mondo Go questa cosa qua hai a dirla sbagliata, poi arrivano le forche.C'è anche la differenza tra framework e toolkit, che secondo me è una differenza molto sottile che però in realtà è una differenza che conta alla fine.In Go esistono tantissimi toolkit e pochissimi framework web e alla fine il toolkit è un insieme di librerie che stanno bene tra virgolette insieme, ma non sono opinionate, quindi non ha una particolare convenzione.Così giusto per far stare tranquilli anche chi fa Go all'ascolto.Per me invece, no, non è "noi invece", perché molte delle cose che avete detto sono correttissime, quindi cancellate invece, backspace, backspace, backspace, per me è un driver, cioè è un acceleratore, è un qualcosa che mi porta in maniera molto veloce a raggiungere il mio obiettivo e se questo framework utilizza anche componenti di librerie è ancora che è ancora migliore, a mio avviso un framework più è a componenti e a librerie differenti che li utilizza, migliore è esso e quindi tornando al discorso di driver, di acceleratore, perché questo mi rende immediatamente produttivo? Mi porta in maniera, come diceva giustamente Mattia, mi veicola quasi in maniera obbligata a utilizzare dei pattern e sono dei pattern diciamo affermati, scelti dalla community e riusabili e quindi imparo anche cose che potenzialmente non conosce non conoscerei utilizzando un framework quindi banalmente è proprio un drive che mi porta direttamente alla raggiungere l'obiettivo utilizzando molte librerie.Questo mi piace di dire.In fondo quello che noi facciamo tutti i giorni è unire dei pezzettini di robe per farle funzionare insieme mettendoci un po' non tanta perché come dice Carmine il 90 per cento delle nostre applicazioni sono il crudino della chiesa però un po' di business logic per far funzionare il tutto come le ricette di Benedetta Parodi.Fondamentalmente il framework è quella colla, però è una colla opinionata che alla fine diventa il responsabile di una serie di decisioni che noi non vogliamo prendere perché il peso cognitivo di prendere tutte quelle decisioni in fase di start up è maggiore del beneficio che ne hai, perché il beneficio poi lo vedi naturalmente nel lungo periodo.Quindi io non voglio prendere tutte quelle delle decisioni, ho trovato il bel pungiball sul quale scaricare quella sorta di responsabilità.Questo può essere un modo diverso di vedere il framework, poi lo analizzeremo anche questo aspetto nel dettaglio.Luca? E qui mi inserisco a camba tesa, hai ragione, uno dei motivi principali per cui lo so che dovrei in un certo senso difendere il non usate il framework, però in realtà proprio per esperienza dico che il framework ti dà già un libro di istruzione di scelte già prese di cui tu non ti devi preoccupare, però non è tanto tu, è tutto il tuo team, tutta la tua squadra, tutta la tua azienda o tutto, insomma tutti quelli che dovrebbero fare riunioni, su riunioni per definire standard, per definire una direzione, anche le più banali convinzioni, non convinzioni, convenzioni, quelle sono già decise dal framework e quello già vi assicuro vi risparmia un due o tre mesi di lavoro in 4-5 persone.Mi volevi fare un'altra domanda? No, no, era quello che volevo sapere in realtà poi ti avrei chiesto perché non usarli ma quello lo vediamo dopo.A questo punto però facendo il ragionamento sulla responsabilità, la domanda che mi chiedo è, guardandola dall'ottica di chi usa il framework? Il framework è sempre la stessa cosa al cambiare della figura che lo utilizza o cambia? Cioè inquadrando bene la domanda, se il framework viene usato da un senior developer o developer che lo usa in un certo modo, il framework è la stessa cosa dello stesso framework utilizzato da un junior? Assolve allo stesso ruolo? Hai gli stessi dischi? Ed ecco che droppo il primo dipende della serata.Dipende dal framework.Ci sono framework che sono particolarmente user friendly e se vuoi poi anche un po' più limitati nello scope.E in questo senso sono più facili a essere usati allo stesso modo da sviluppatori diversi con background diversi.Sto pensando per esempio a Rails, che è estremamente opinionato e ha il modo Rails di fare le cose.Ed è molto difficile scappare, è molto difficile per sviluppatori diversi fare le cose in modo diversi, è molto difficile per un junior sbagliare, è molto difficile per un senior inventarsi un modo astruso di fare le cose.Spring, invece, che è molto component-based, io questa sera dirò Spring un centinaio di volte, perché è il framework che conosco bene, ma Spring che è costruito molto a componenti, è molto articolato e che fa un sacco di cose diverse, e si presta molto di più a essere usato in modi diversi.Quindi è un framework con molta più elasticità nell'essere usato e quindi in questo senso si cambia molto a seconda che lo usi uno sviluppatore diverso.[Enrico] Secondo me la differenza tra queste due cose, giusto, Sip, per entrare anche io a gamba tesa, è che il senior davvero conosce il framework, usa il framework, e lo sviluppatore junior piega il framework alle sue esigenze.Secondo me la differenza è pure quella lì.Alla fine ci sono un framework, tra l'altro Rails, che è un framework che ho utilizzato parecchio e che utilizzo tuttora.Io ho conosciuto tantissimi sviluppatori che soffrono della sindrome Rails oppure Ruby.Questo perché comunque Ruby ti permette di fare qualunque cosa a runtime.Nel caso specifico di Rails c'è una dipendenza che è ActiveSupport che sostanzialmente inietta dei metodi e dei behavior nella standard library Ruby e quindi tu ritrovi dei metodi o comunque dei pattern con cui puoi utilizzare quegli strumenti che con linguaggio base non si resta.Ed è questa sindrome per cui non riesci a distinguere qual è il linguaggio e qual è il framework, e anche questa è la vera differenza tra lo sviluppatore junior e lo sviluppatore senior.Io questa cosa qui l'ho vista anche ad esempio in Laravel, l'ho vista in Python.Django fa tante magie, così come le fa Pulley Rails, e ci sono veramente persone che non sanno distinguere quello che è il framework e quello che è sostanzialmente il linguaggio base.e secondo me è una cosa pericolosissima, perché alla fine conoscere il framework, ma non conoscere il linguaggio secondo me è una cosa che nel breve termine ti può far fare con quell'MVP fissimo, col tuo collega senior a cui dici "ah, hai visto, scemo, ho fatto il bellissimo crude su Ethereum per gli smart contract in 25 minuti" ma dopo due ore è già immanutenibile, insomma.io non so come funziona, in spring lo utilizzavo pochissimo, però secondo me il linguaggio fa anche tanto la differenza.Se hai uno strumento che ti permette di martellare non c'è Ferrimore Cattang, almeno questo è quello che penso io.E in rails ho visto tante cose martellate, delle cose veramente brutte.Io invece facendo un passo indietro, per il tutto bisogna un po' ribilanciare la classifica perché qui stanno facendo un sacco di nomi e ancora più volte spring, più volte rails e ancora non si è detta la parola symphony, quindi vorrei dire symphony, symphony, symphony, symphony, symphony ed è ovviamente per me l'ecosistema migliore che conosco io per me il framework è symphony.La domanda fatta da Mauro e che i brain repo sicuramente è molto intelligente e pone riflessioni.Sì, sicuramente esistono framework più adatti a senior e più adatti a junior perché ovviamente un framework può avere una curva di apprendimento molto ripida, come potrebbe non averla e quindi è facile, diciamo, incrementare, ingaggiare più facilmente sviluppatore per un framework più questa curva meno ripida.però c'è anche da dire che il framework per il senior sfrutta al 100% le potenzialità del framework conosce cosa c'ha sotto al cofano quel framework e molto spesso invece il junior non riesce a fare quel passaggio in più per andare un po' più in profondità e quindi si è installato framework però poi continua a fare le cose come le sapeva fare anche dentro al framework creando facendo la cosa peggiore perché vai a creare del debito tecnico su un framework che è appena installato tra virgolette e scrivi anche molto più codice perché non conoscendo ciò che ti metteva a disposizione avresti potuto fare iniettando una cosa una configurazione aggiungendo un componente e avresti già risolto.Quindi tornando alla domanda bomba, sì, un framework può essere a occhi diversi in base alla seniority e utilizzi diversi in base alla seniority.Volevo un attimo agganciarmi a una parola che ha detto Mauro in fase di startup.Poi Andrea che lavora a immobiliare.it che parla di framework e visto che proprio oggi ho visto una polemica su Facebook sul gruppo Asterisco Italia che dicono "sì il framework è buono per iniziare però poi dopo uno deve sviluppare qualcosa".Secondo me no, voi Andrea utilizzate Sinfony cioè immobiliare.it gira su Sinfony? Ampiamente, ampiamente.Anche perché tutto questo ti aiuta appunto quando c'è software grandi con tante mani che mettono dentro a quel software avere delle linee guida che ti aiutano a sapere immediatamente dove stanno le logiche di business per una cosa o un'altra.Anche questo è acceleratore, se ci pensate al discorso di prima.Però nel tuo caso non è più acceleratore perché voi siete un business che è già in corso quindi nel senso come acceleratore può essere anche a fare la nuova funzionalità risolvere il bug cioè non per forza acceleratore a partire io quando prima mi riferivo a raggiungere l'obiettivo non è soltanto mettere online l'mvp o il poc per la nuova startup ma è anche aggiungere una nuova funzionalità fissare quel bug anche anche qui il framework mi avviso ti viene in aiuto perché in automatico sai già dove andare a mettere le mani o già dove devi aggiungere la nuova funzionalità perché conosci lo scaffolding, conosci la struttura, come funziona il ciclo di vita e tutto questo per me è acceleratore.Io devo dire che quando ho iniziato a sviluppare ho sempre visto da prima i CMS iniziavano a mettere le mani su forse qualcuno si ricorda nuke, php, quella cosa, in realtà se qualcuno conosce, era bellissimo Andrea, se qualcuno conosce di persona chi l'ha sviluppato, che era un italiano e soprattutto se, visto che è passato tanto tempo e ancora vivo, vi prego pingatemi con il contatto perché sono tre giorni che sto cercando questa persona e non riesco a trovarla, non c'è più traccia su internet.Io mi sono fatto delle domande del perché.Comunque io vorrei dire che PHP non era bellissimo, eravamo solo più giovani noi.Beh, erano anche più giovani internet.Però, dicevo, gran parte del mio percorso di formazione è passato per i framework.Non so quanto condividiamo questa cosa a livello di percorso di sviluppo professionale e ho passato gli anni più belli della mia vita con Symphony.Una cosa che ho notato poi con l'evolvere della mia carriera, con lo svilupparsi della mia carriera, è che ho iniziato a trovare i framework un pochino limitanti.Non so se era di peso da me o è solo un bias, però ho iniziato a vedere quelle decisioni come prese e qualcosa da collatto dall'alto che avrei dovuto in qualche modo sposare ma potevo anche non essere d'accordo cioè si iniziavano a sviluppare quegli elementi di pensiero critico che mi dicevano beh ma allora se io non volessi usare, ne dico una, façade ok e volessi usare meglio la dependency injection non devi usare l'arabel ecco qua no però sto facendo l'esempio su symphony potrei fartene un'altra se io non volessi scrivere quintali di configurazione sta indietro ora c'è l'autowire e l'autoconfiguratore.Altre convenzioni, decesa altra.Per dirvi, nel senso se io non accettassi questo tipo di convenzioni e se fossi in grado di sviluppare quel pensiero critico, come potrei con quel livello di seniority approcciare al framework? framework, cioè si tratta solo di una questione di produttività, cioè dico vabbè usare le fasade o usare questo certo pattern mi sta sul culo, mi turo il naso siccome sono produttivo ciccia, continuo a farlo oppure questo è un non problema, c'è un altro motivo per cui usare il framework da senior? Io faccio una cosa scortese che non si fa e rispondo alla tua domanda con una domanda.La domanda è "ma perché non vuoi usare le convenzioni del framework?" Perché se il punto è "a me stanno sul cazzo le facade perché mi sono svegliato così", credo che l'errore sia quello.Se il punto è "io non voglio usare le convenzioni del framework perché credo di essere più bravo io di tutta la community di sviluppatori a cui le convenzioni piacciono", Anche quello non mi convince.Ha detto framework.E' un po' una cosa da fassino.No, no, la contraddomanda è corretta.Però framework e framework utilizzano delle convenzioni e delle posizioni diverse, no? Però assumono un set di posizioni e di pattern, una combinazione di questi pattern.e io adesso non ti potrei, non ti saprei dire il caso specifico, però può capitare che in realtà queste combinazioni di partner, una volta che hai sviluppato quel livello di pensiero critico, non fittino con il tuo pensiero critico.Io capisco che utilizzare un framework è come avere un impianto, specie se lavori in un team, questo l'avete detto prima voi, un impianto dove la consistenza intesa in un insieme di regole è condivisa non solo all'interno del progetto, all'interno dell'azienda, ma addirittura all'interno di una community, quindi tutto questo è un vantaggio.Però da senior in realtà come approccio o come dovrei o dovremmo approcciare al fatto di "ok perfetto questo set di decisioni non le condivido, acco il framework, forco il framework o mi turo il naso?" Secondo me dipende dal framework.Allora nel senso io posso fare quei 3-4 esempi che conosco Insomma, ad esempio Rails è un framework monolitico.Punto.Nel senso io sfido chiunque a integrare delle librerie di terze parti, anche abbastanza famose, diciamo, con le standard de facto, in una applicazione Rails, dove si è deciso allo startup, allo scaffolding, di non usare l'ORM.Quindi di non includere ActiveRecord come dipendenza.Non lo fai.non lo fai, o meglio inizialmente lo fai e poi ti si rompe qualcosa.Quindi nel senso se operi con un framework monolitico come può essere Rails, che io chiamo, e non solo io, chiamo monolitico anche se Rails è comunque fatto da tanti componenti, c'è ActiveRecord, c'è ActiveModel, c'è ActionCable, bla bla bla.Se si usa un framework del genere, questa cosa effettivamente è complessa.È vero pure che questa cosa dipende anche tanto dall'architettura che hai.Il framework ti forza nelle sue convenzioni anche una certa architettura.È vero anche che con uno sforzo, che anche qui dipende dal tipo di framework, si può lasciare che il framework sia solo un dettaglio, per dire insomma come direbbe Uncle Bob.quindi del framework usi la parte architetturale HTTP per gestire le sorsi HTTP, tu utilizzi la parte infrastrutturale del LORM per interagire con il DB, ma nulla ti vieta comunque di avere una parte di dominio che è pura e si inserisce comunque nelle dinamiche del framework.Questa è una cosa che è comunque capitata, l'ho fatta con Rails.L'ho visto fare con Symfony di VersiTool, che in realtà abbiamo parlato di hexagonal architecture in Symfony anche qui su Gitbar, una vecchia puntata, che invito a recuperare.Adesso andrò a vederlo anche io.Esattamente.E che invito comunque a recuperare.Si sta parlando proprio anche di questo.Insomma, se fosse possibile inserire il framework in un'architettura più complessa.Secondo me si fa, però lo sforzo dipende dal framework.ad esempio se domani in un'applicazione Rails vuoi fare qualcosa senza l'auto loading delle classi non lo fa ad esempio o comunque se lo fai lo fai in una maniera diciamo che è controintuitiva e dove devi scrivere di più.Ad esempio in Rails ho fatto un architetture delle gemme della collection, la chiamo così, collection, non so in realtà come chiamarla, del toolkit di dryRB dove c'ha diverse cose per riuscire a fare un architettura un po' più libera.Se invece andiamo su una cosa più a componenti, non lo so, mi viene da pensare a Nami, che è fatto comunque in Ruby, tra l'altro è fatto anche da un italiano, mi sembra, o comunque io in realtà lo sto facendo in queste settimane con l'Aravel, sono riuscito abbastanza ad isolare le cose, quindi a non usare le fasad, perché anche mi stanno abbastanza sul culo come concetto, ma lì la dependency injection di service container ti vengono comunque in aiuto e puoi farlo senza, insomma.Puoi comunque avere tutta la parte di dominio che è indipendente, eccetera.Alla fine dipende dal framework e dipende anche dal...e qui faccio giusto, buttano una cosa così.Secondo me utilizzare un framework ti costa meno.Anche proprio a livello di budget, soldi.Avere comunque qualche cosa che ti dà delle linee guida, che ti dà un'architettura di base che può essere corretta o meno, ti costa meno nel delivery, nella formazione, ti costa meno in diverse cose.Se invece, in rapporto a un'altra esperienza di tutti i giorni, che è quella con Go, dove esistono dei framework che tentano di minimare quello che fa Rails, quello che fa Laravel, ma di veri framework così strutturati ce ne sono pochi e quelli che ci sono a maggior parte sono un accrocchio.In quel mondo lì fatto di dominio che è costruito in un certo modo, architettura, una progettazione prima, un mondo di microservizi, eccetera, lì effettivamente ho visto il beneficio di non avere un framework, perché parla comunque di uno scope piccolo, di un dominio che è stato, diciamo, delineato e sandboxato bene e quindi allora lo fai.Questo non sto dicendo che non puoi fare micro servizi o architetture più complesse con il frame, non è vero, ho fatto anche i servizi in Rails, conosco gente che lo fa con l'Umen per non usare l'Arabel.Ho visto tanti micro servizi che sono fatti con Zymphony.Secondo me dipende di...Alcune volte, ad esempio io mi sono ritrovato, ho avuto l'invidia del framework e dicevo "ah, questi framework fanno schifo perché non ce li avevo a disposizione".Ad esempio, quando programmo con Node ho questa invidia.Quando faccio Go e sto facendo il crude di merda, a me fa invidia il fatto di non avere degli strumenti opinionati che ti rendono quella cosa semplice.perché è vero che c'è l'Orma anche in Go, che funziona come funziona, è vero che c'è il Query Builder, è vero che puoi scrivere SQL, però spesso dici "va bene, basta".Secondo me, diciamo, il perfetto bilanciamento, almeno io, tra il reinventare la ruota e utilizzare il framework, io non l'ho ancora trovato.Infatti oscillo tra "che bello il framework" e "ho invidia del framework".Allora, da quello che hai detto in realtà emerge quello che in fondo è una cosa che mi chiedo da tanto e a momenti penso che questo ragionamento, quello che vi sto per fare sia una cazzata, ad altri frangenti reputo che sia in realtà la risposta, però spesso penso, sono sicuro che sia la cosa corretta quindi non incazzatevi.Spesso penso che la necessità di un framework è inversamente proporzionale alla quantità di business logic specifica che dobbiamo scrivere.Non sono sicuro che sia la risposta corretta quindi non l'accendiamo però credo che sia un elemento determinante nel senso che, questo lo provo a ricondurre al ragionamento che facevo prima, nel senso che con l'avanzare della carriera mi son trovato a scrivere sempre meno crude e a fare sempre più business logic e alla fine il framework mi aiutava ma in una condizione marginale e poi mi sono ritrovato a fare sempre più microservizi dove la parte, come diceva Carmine, dell'architettura del microservizio stesso, non dell'ecosistema, ma del microservizio è assolutamente marginale, è piccolissima, Quindi, alla fine, non ne ho sentito l'esigenza e l'unire di queste cose mi ha un po', insomma, portato ad allontanare un po' dal mondo dei framework.Allora, la mia domanda è, usarli o non usarli? Ma io estendo addirittura il tuo ragionamento, secondo me il bisogno che hai di un framework non è inversamente proporzionale tanto alla quantità di business logic che hai, ma quanto alla non standardness della tua applicazione, nel senso che se, come ci dicevamo prima, la tua applicazione è il crude della chiesa, se non usi un framework sei un pervertito, nel senso che non c'è nessun motivo.I framework, probabilmente c'è un framework che ha il comando della CLI, generate crude della chiesa e poi non scrivere codice.Se la tua applicazione invece fa delle cose molto non standard o magari è un microservizio, magari appunto è molto lontana dall'essere un crude della chiesa, allora sì, a quel punto il tuo bisogno di un framework si riduce.Quindi probabilmente il tuo bisogno di framework è una funzione della tua distanza dal crudello chiesa, in buona sostanza.Ma non si rischia poi, non usando un framework, scrivendo le logiche per conto nostro, di scrivere un framework noi? Perché alla fine scriviamo delle funzioni che ci aiutano a fare delle cose tediose, e in bancari scriviamo un framework che poi distribuirà il nostro team.Cosa cambia? Cambia che quel framework che abbiamo scritto solo noi invece che una community, allora forse tanto vale appoggiarsi sulle spalle dei giganti? La provocatoria forse rientra in questo tema.Ti vorrei dire di no, però didi sì.Sì, ovviamente la retorica è all'emblema del del tavolo del bar di chi...Dobbiamo fare un po' di engagement...Si potremmo anche parlare del Presidente della Repubblica, Toppo.Dobbiamo fare della retorica insopportabile.Cercavo di spostare un po' il concetto di framework che molto spesso lo si pensa, ovviamente, un linguaggio, ha un qualcosa da fare con quel linguaggio, ma il framework potrebbe essere anche altro.Lo Scrum è un framework? Esatto, bravissimo, dalle parole di bocca, ma il flow che abbiamo deciso insieme al nostro team da utilizzare con Git, con GitLab, BitBucket, eccetera eccetera, non è anch'esso un framework? Sì, è vero.Decidere di fare le salle retrospettive stand up, usare Kanban oppure la board, anche questo è framework.Quindi perché buttare fango su tutti questi framework di cui ci circondiamo per aumentare la nostra velocity? Io questo proprio non riesco a capire.Però a parte che non stiamo buttando fango, anzi io potrei dire viva l'Aravel e quindi cioè alla fine poi vi spiegano anche il perché.E lo posto di Purio dopo tanti anni, che bello, basta voglio far solo L'Ara.Da lì alla pensione.Che ricordiamo essere la brutta copia di Reiss però basta.No però la differenza, quello che diceva Andrea è interessante però voglio aggiungere una cosa, la differenza tra framework come solo set di decisioni e di strumenti coordinati e framework dal punto di vista del codice sta nel fatto che c'è un elemento che ha un'incidenza maggiore, nel codice c'è l'elemento che a me viene da chiamare glue, la colla che tiene insieme i pezzi dove a livello di strumenti con io uso scrum, uso le retrospettive in un certo modo, uso i task con gira, faccio i task in gira in questo modo, li grummo, non so se esiste la parola italiana grummo, però sa molto di succo d'arancia.le...scusami, in parentesi ti prego spiega che cos'è grumma.Che anche in inglese non è che torna tanto.Cioè nel senso che significa? Ah, grumma, g r o o m che li pulisce.Il gruming è dare il peso ai ticket.E credo che venga da un framework l'utilizzo di questa parola.Sì, Sì però l'evidenziazione che voglio dare è che i framework di cui parlavamo prima hanno un elemento che è molto incidente che è la glue code, quello che potremmo chiamare la colla che tiene insieme i pezzi quindi non sono solo delle decisioni ma c'è anche, ereditiamo anche il coordinamento di questi pezzi.Alla fine questo coordinamento assume un peso molto importante in quello che andiamo a fare e spesso è anche una di quelle cose, l'elemento che coordina il tutto, di cui non ci possiamo o difficilmente possiamo spogliarli.Ecco perché la mia domanda era, ok, il framework visto l'atto codice è un insieme di decisioni, ma non è solo un insieme di decisioni.Quando queste decisioni più questa colla possono essere limitanti secondo voi, oltre naturalmente a quello che abbiamo detto prima e quando invece, perché nei flame che troviamo nei gruppi spesso se io uso il framework io non li uso come partito preso, come posizione.Fondamentalmente le posizioni invece devono essere due, cioè quando usarli e quando non usarli, non io li uso o non li uso.Una super bold opinion, se non lo usi significa che te lo sei fatto.Più uno.Quindi secondo me la scelta è soltanto sul quale usare e quale usare è molto vicino alla strada che stai prendendo tu con la domanda, nel senso se so che il mio caso d'uso mi porteranno in una direzione e dovrò stuprare questo framework per fargli prendere quella direzione, allora non è il framework adatto al mio caso d'uso.Oppure non è un framework di livello per poter abbracciare tutti i possibili casi d'uso, perché ovviamente la scelta di un framework deve andare incontro anche a questa, perché io conosco l'esigenza del mia azienda oggi, ma non so fra cinque anni, tre anni, quale direzione prenderà il mio prodotto o altro.Quindi la scelta deve essere molto mirata e più è versabile, customizzabile il mio framework, componibile meglio voglio sarà.Quindi il corollario è che non esiste il framework perfetto per la persona perfetta, esistono per questo tanti framework, quindi la domanda se utilizzare il framework oppure no non ha tanto senso, la domanda è quale framework utilizzare tra le diverse offerte disponibili che ci dà il mercato o anche il proprio se proprio ci vogliamo mettere il nostro.Non dobbiamo anche dimenticare che oltre a, ovviamente come detto, il set di decisioni già prese ci sono anche tutta una serie di layer di di astrazioni che sono nati, sono fatti dalla community per soddisfare quante più esigenze possibili, però a volte questi layer possono diventare anche troppi per il tuo caso, per il caso d'uso.Ecco lì che a volte un framework magari potentissimo che però appunto ha decine di questi layer può non essere la scelta adatta, puoi andare, puoi virare verso una libreria, verso un toolkit oppure il framework che ti sei fatto il sabato per fare quelle due cose stupide.I vantaggi quali sono? Questo dipende da quanto, quando, che tipo di lavoro vuoi fare.Una delle valutazioni che feci all'epoca è se noi siamo un'azienda che prende in pacchetta le commesse, cioè prende le commesse, prende in pacchetta il software lo distribuisce e poi se lo scorda allora cavolo quel framework che prendi quello che usi usi va benissimo perché ti permette di lavorare velocemente ti permette di consegnare rapidamente dai il tuo anno anno e mezzo di assistenza e poi non è più un tuo problema quindi la logica che avevi è rimasta anzi se cambia tanto meglio tornano da te e li fai pagare ancora e via.Diverso è se devi costruire un software che ti devi piangere tu nel corso degli anni.Lì questa è una valutazione che all'epoca noi in azienda abbiamo fatto e questo dipende anche da quante persone sono composto il tuo team.Devi avere persone che devono star dietro al framework, agli aggiornamenti, alla sicurezza, devi avere di contro la parte dei sysadmin o dei devops che aggiornano i sistemi, che ti permettono di usare i framework aggiornati, eccetera eccetera.Per cui dalla mia esperienza dipende da una catafracca di fattori, se usarli e non usarli e quali usarli e quali non usarli.Simponi l'ho detto? No.Ma secondo voi c'è un set di cose imprescindibili che non si possono fare senza strumenti esterni? Secondo me il primo quello principe è l'autenticazione.Io quando sento, sai quando ho fatto login, registrazione, recupero password da solo, comincio ad avere tipo questo freddo che mi sale sulla penna.Immagina se hanno fatto out due.Noi abbiamo fatto il nostro identity server o auto2contact da soli.Madonna mia.Ok.Vedete il senso? Ci sono delle cose da cui non puoi prescindere di utilizzare una soluzione quanto uno standard.Ad esempio, prima dicevo, magari se faccio qualche mio servizio in Go o in Node, uso anche, diciamo, dei toolkit delle librerie.non mi sonierei mai di fare tutta la parte di autenticazione e autorizzazione dei miei servizi da zero, perché dal giorno uno che sto scrivendo "if" qualcosa, sono già una nuova vulnerabilità sul sito dell'OWASP.LM: Ti dimentichi un caso sicuro, 100% 100% Il fottuto, sì esatto, alla fine è quello.Alla fine è bello fare il microservizio, è bello utilizzare il toolkit.Ma lo usi vero? Esattamente, ma ci sono delle migliaia di cose che o esternalizzi o lo fai con una iberia, con un framework o comunque con uno strumento adatto.Ad esempio io ho utilizzato sia Keyclock che è un gigante, fa 1600 cose e se avete il codice di merda, no, lasciate stare.Ma ma c'è Kratos oppure magari se sto usando il framework c'è Spring Security, c'è l'autenticazione di Laravel, ci sta Sanctum, ci sta Symfony Security o chi per lui, ci sta Device che sta facendo Rails, nel senso ci sono delle ogniate cose a cui secondo me è imprescindibile o esternalizzare o utilizzare delle...e a questo punto secondo me non...ecco qui, altra bolda opinione.Ci sono dei topic, dei domini che sono così complessi che la libreria non c'è.C'è sempre il framework.Insomma non esiste la libreria per l'autenticazione, esiste il framework per l'autenticazione.Perché sono domini così complessi che non possono non essere standard, non possono non avere delle convenzioni.Però ragazzi...E ti dirò di più, non lo porteremo mai in produzione se non è una cosa open source che ha 3 miliardi di merge request che sta alla settima major con 100 sviluppatori sopra che ci lavorano che gli arrivano potenzialmente issued, non si sa quanti client e quanti fix hanno fatto perché c'è una spropositato numero di possibili complicazioni che non ti verranno mai in mente e che non riuscirai mai a gestire.Quindi "love of source" e "love of insource", libreria o premorche che sia.Ecco, io devo compensare questa cosa però.Io volevo droppare una bold opinion ulteriore sulla bold opinion di Carmine, nel senso che per me non è che ci sono alcuni contesti in cui è giusto usare una libreria per tutti i motivi che ha detto giustamente Andrea, ma secondo me non ce ne sono davvero molti in cui non ha senso fare una cosa del genere.L'esempio più grosso che mi viene in mente è il logging, che è una roba in cui tutti usano un toolkit o un framework o una libreria...- Io l'avrei detto un mocking, però.- Eh, un mocking è bellissimo.Il logging è una roba in cui tutti di solito usano un toolkit, un framework o una libreria, comunque non se lo fanno in casa perché è una roba di cui tendenzialmente te ne fotte così poco e lo dai così per scontato che lo usi quello che ha fatto qualcun altro.Quando poi si rompe, come è successo a fine dell'anno scorso con l'Open4j, che si è rotto in maniera davvero grossa, se ti si rompe una cosa che è gestita dalla Apache Foundation, che ha un'adoption spropositata, perché praticamente nessuno che fa Java non usa l'Open4j, il fix per l'Open0day esce mezza giornata dopo.Se ti esce uno zero day su un framework che ti sei iscritto da solo, secondo me prima che te ne accorgi passa un anno e mezzo e il tuo conto in banca è stato tutto trasferito in Cina da un po'.Diventa un 1500 day.No, io voglio dire questo in realtà.Il mio vedere framework è un po' cambiato, cioè da framework come Laravel ho iniziato ad apprezzare framework molto più light come Fastify e tutto quell'insieme di librerie, tutte quell'insieme di librerie che io avrei buttato dentro o mi sarei trovato dentro già pronte ho iniziato a seconda del caso d'uso non so se come scelta è la migliore da fare a fare il replace con dei servizi.Ecco perché ho scelto Fastify, nel senso che essendo un framework che non è un framework e che fondamentalmente mette pochissima colla nei pezzi, alla fine ho detto ma perché utilizzare questo sistema di autenticazione se esistono dei servizi che me lo fanno e si sbattono loro e a livello enterprise sono supportati, parlo di un Cognito o di un Octa o di un Outzero no? E mi tolgono via tutto a quel livello di complessità, per quanto riguarda il lavoro di tutti i giorni in ambito enterprise vedo che in tutti i progetti dove vado a questo tipo di servizi chi più che meno sono abbracciati perché eliminano complessità non solo nello sviluppare e nel mantenere ma anche nel gestire perché non dimentichiamoci che c'è anche quel tipo di complessità a livello sistemico e poi invece nel POC ho trovato che questo tipo di servizi sono comodi anche per sviluppare le mie proof of concept perché hanno dei free tire talmente grandi che io non mi devo neanche preoccupare tanto tutti i miei side project vanno a finire una cartellina nel mio desktop quindi non è un grande problema però cioè a questo punto perché prendermi una roba che ha già preso mille decisioni quando in realtà io posso delegare direttamente un servizio se voglio spogliarmi di quella roba.Questa è una boldissima opinion e non sono sicuro di sposarla neanche al 100%.Qua stai accoppiando un po' il vendor lock-in con il servizio terzo con una cosa che mantieni tu e fai tu, sono due cose differenti.Anche se è la green code.Sì ma Andrea, al 100% al discorso di Pastify, ottimo framework, che anche lui ha il suo sistema a componenti, che nel suo ecosistema si chiamano plug-in e ti permettono di fare la qualunque e ti permettono anche di inserirti sul layer della qualunque per interagire ed è fantastico tutto questo.Però andare a scomodare i servizi fuori non lo so, sono in dubbio.Non lo so.Vabbè Mauro sta sposando il no code pian piano, quindi è ovvio che sta andando via via in quella direzione.A quel punto mandiamo la società in outsourcing, anche quello è il no code, non me li ho preoccupati niente.Ti è piaciuta questa? Si chiama product manager.Sì alla fine lo so che finirò a scrivere specifiche e non scriverò più codice.No, però...- Ma noi ti vorremmo bene lo stesso.Per il proof of concept lo trovo molto più pratico di un configurare l'autenticazione con Symfony.Vabbè, vengo da un vecchio Symfony, penso di averlo abbandonato attorno alla 3, 2, passaggio con la 4, là mi sono staccato.Però dovevo scrivere una tonnellata di robe per collegare l'autenticazione e poi perdere un botto di tempo per sistemare quei maledetti template.Andrea mi ricorda su l'acciate che siamo alla 6 adesso e il tempo passa la barba si bianca.Però per esempio una cosa che ho trovato con l'Aravel ed ecco perché ho detto viva l'Aravel, è che in realtà ed ecco la posizione un po' confusa che ho, cioè con tu clicchi un pulsante e hai tutto pronto, cioè ti fa il tuo crudino è finito e lo mandi in produzione.Già con Fastify ci metti molto più tempo, però l'utilizzare di questi framework vuole anche prendersi, abbracciare una responsabilità grande sulle decisioni che non hai preso tu, perché l'insieme di librerie che utilizza il framework dovresti in qualche modo conoscerle, dovresti sapere cosa ti sta girando sotto il sedere e facciamo anche un po' di mea culpa che non sempre guardiamo cosa ci sta girando sotto il sedere.Secondo me non ci guardi se...Scusami, pensavo che sti finito, c'ho il ritardo.No, aggiungo solo un altro...e se le decisioni che sono state prese dal al fremuo sono molte di più di quelle che ti servono, tu stai ereditando codice da mantenere e responsabilità anche per quelle decisioni che in qualche modo non ti servono.Questo è un altro tipo di ragionamento.Scusa Carmine.No, no, anzi scusa, tu purtroppo mi sento in ritardo oggi, la Winda ha detto che la mia banda è poca.Nel senso, secondo me, non guardi sotto al cofano finché devi veramente fare il crude della chiesa.Perchè, ad esempio, io ho utilizzato pochissimo Spring, ma ho ho dovuto capire come funziona l'auto wiring di Spring dall'XML fino alla bestemmia finale quando metti la notation.La stessa cosa con l'Aravel, anche lì comunque alla fine possono andare a vedere quello che c'era sotto.Secondo me, ecco, noi facciamo una puntata sulla metà programmazione che mi invito a rivedere di un po' di mesi fa, dove alla fine si diceva questo, "la differenza tra la persona che conosce il linguaggio e che usa il linguaggio sta nel conoscere come funziona".E secondo me anche questa qui è la differenza.La differenza tra saper usare il linguaggio e conoscere il framework sta nella padronanza che hai dello strumento anche perché prima o poi ce l'hai comunque quel bug sugli OC container, sull'ORM, sullo scope, eccetera, eccetera.Devi comunque andare a vedere come funziona.Però, almeno secondo me, se perdo tra brevette tempo a vedere come funziona il framework se ho un bug è un investimento che sto facendo.se devo perdere tempo a capire come mai ho fatto quell'interface vuota e il casting che c'è nel file, nella libreria, al coso ecc.l'ho fatto bene o meno, è un investimento fino a se stesso, se non alla risoluzione di quel bug lì.sono questo un discorso senza senso per me è ovvio perché sono una persona curiosa magari un altro dice a me che cazzo mi frega l'importante è che fasse l'ex star però boh secondo me è una cosa da considerare alla fine io credo che la differenza anche di RAL e ricordiamo che il gruppo Telegram di Gitbyre è uno dei gruppi dove si paga pochissimo di RAL se non si parla mai di RAL anzi a volte proprio scriviamo "ma perché non parliamo di RAL?" e nessuno risponde.La differenza secondo me anche di guadagno e di expertise sta proprio tra lo sviluppatore che ti fa il crude e lo sviluppatore che sa come funziona quel crude.Aggiungo a questa cosa, tra l'altro, che nell'ecosistema Java una delle cose che si dicono spessissimo quando c'è uno che dice "ah, come faccio a diventare senior? Come faccio a diventare più bravo?" Gli si dice "ah, leggiti del codice open source" e subito dopo gli si dice "leggiti il codice di Spring, che è bellissimo".È in effetti vero.E soprattutto nell'ecosistema Java, questa cosa che hai detto tu, della differenza tra chi sa usare il framework e fa il crudella chiesa e chi conosce un po' come funziona dentro quindi possa usare al massimo del suo potenziale.Poi la solita differenza tra chi sa guidare una macchina e chi sa come funziona un motore è molto, molto vicina la distinzione tra junior e senior in ambito Java.Chi conosce bene come funziona Spring dentro, perché magari si è passato del tempo a guardarci dentro o ci ha sbattuto la testa per tanto tempo, tipicamente ha una RAM maggiore.Tra l'altro vorrei addressare anche, secondo me, un mezzo elefante nella stanza.Ho detto "addressare", quindi oltre alla spunta su RAL e alla spunta su Mocking, mettiamo la spunta anche su parole inglese dette a caso.L'elefante nella stanza, secondo me, è che la scelta se usare o meno un framework piuttosto che un altro, ha un grosso impatto anche sull'iRing.nel senso che a me è capitato per dire, lavoravo in un'azienda che a un certo punto era una startup e poi quando sono entrato io non lo era più perché era sopra le 100 persone, ma in fase di startup aveva deciso che la scelta di fare gli MVP e tutto il prodotto che poi sarebbe stato il core dell'azienda sarebbe stato fatto con Grails.A un certo punto mi ricordo che parlavo col CTO dell'azienda e lui mi diceva "cazzo non riusciamo più a trovare nessuno che sappia Grails" e io mi sono guardato intorno e gli ho detto "Zio, probabilmente in Italia tutte le persone che conoscono Grails sono in questa stanza" perché Grails è carino, simpatico, però non è che abbia questa adoption gigantesca e non è esattamente un gioiellino.Allora rifacciamo tutto in Cobble.Infatti Mattia quello che volevo dire a questo punto è che spesso c'è un momento dove il carico cognitivo si sposta dal linguaggio e dal dominio e va a posizionarsi sul framework.Esiste un momento, non nello sviluppo, dove questo accade e quello che mi chiedo è quando questo succede ci troviamo in una condizione innaturale dove lo strumento che dovrebbe semplificarci la vita diventa invece lo strumento che ce l'accomplica a livello anche di apprendimento e dove io non studio più come si scrive il codice IPHP ma non sto più scrivendo codice IPHP, sto scrivendo Symfony, non sto più scrivendo Java ma sto scrivendo Spring, non sono più un programmatore...Scusate, abbiamo dei problemi tecnici...La banda in Francia è poca...Publicità! Mandare pubblicità, per favore! Donatori! Ti presenti quando arrivano dei video porno sullo schermo durante la conferenza di 5 Stelle? stelle, sono potute accadere delle cose di questo tipo, ma non vi state a preoccupare perché tra poco torneremo con voi a parlare di Fremo.No, dicevo, esiste un momento però dove la complessità e il carico cognitivo si sposta dal dominio e dal linguaggio e va a posizionarsi sul framework e questa situazione accade spesso e allora mi chiedo è forse innaturale questa situazione? E' forse il framework uno strumento che dovrebbe complicarci la vita e diventa poi invece elemento centrale di una certa complessità? Dipende se stiamo parlando di Spark oppure di Laravel, secondo me dipende da quella cosa qui.La complessità è anche strettamente legata al caso d'uso in cui si inserisce quel framework, così che non si fia niente.No, secondo me dipende un po' anche dall'attitudine dello sviluppatore.Molto spesso parli con persone che conoscono benissimo un framework, diciamo il nome perché dobbiamo sempre ribilanciare Symfony, però non hanno la minima idea di come funzioni sotto al cofano o non hanno la minima idea dei pattern che utilizza sotto, quindi sa soltanto utilizzare quello.Questo molto spesso l'ho visto succedere anche con React.Lo so, React non è un framework, ok, molti di voi forse diranno "sì è un framework, no è una libreria" per me è una libreria, però essendo molto vicino a posizioni, linee guida eccetera eccetera, anche lì molto spesso c'è gente che conosce React ma non ha la minima idea di come funziona JavaScript, Vanilla eccetera eccetera e quindi un po' il framework sì, più o meno la Velocity ti nasconde anche un po' di complessità e quindi potenzialmente se non sei molto attento ti potrebbe rendere anche un po' gnubo nel senso io la vedo come una black box quindi fa le cose che deve fare a me non mi interessa quello che sta sotto beh parliamone è molto importante conoscere cosa c'è sotto perché domani quella parte va a finire che la devi modificare la devi fare tua la devi portare via dal framework per customizzarla e quindi conoscere tutto quello che li utilizza e come lo utilizza è molto molto importante.Entro a gamba tesa dicendo una parola, jQuery.Cioè davvero, va bene, non è un framework o forse sì, chi lo sa, però jQuery ti nascondeva tanta di quella complessità, ti nasconde ancora ma molto di meno, tanta di quella complessità che però non ti serviva sapere e non ti serve tuttora sapere, almeno tutta la complessità di 10-12 anni fa, tutte le compatibilità tra browser e compagnia bella.Quindi sì, alla fine si torna sempre lì, dipende da che cosa devi fare e chi sei, junior, senior, per quello specifico linguaggio e che cosa vuoi fare? Cioè, qual è il tuo scopo? Lo scopo è produrre software e venderlo per portare la pagnotta a casa o lo scopo è imparare un linguaggio? Se devi imparare un linguaggio, ha senso cominciare subito con framework? Se sì, quale framework? Uno un po' più opinionato, uno un po' meno opinionato? Libreria? Guardiamo il codice sorgente, però dobbiamo sapere di quale codice sorgente, di quale framework guardare perché potrebbe nascondere qualche spiacevole sorpresa.Per cui dipende, è stato già detto? Dipende? Sì, però la domanda che facevo io in realtà è, ok, bene, uso un framework, uso Angular, per dirne una, perché React l'abbiamo già detto, Disbelte ne parliamo dopo, io non ne voglio manco parlare, usiamo un framework angular, la complessità nel gestire angular può capitare che diventi maggiore, ci mettiamo lo state manager, ci mettiamo la programmazione reattiva, ci mettiamo cose diventa altissima, tanto più che quel il tipo di complessità lo si è spostato dal linguaggio al framework.Il linguaggio è uno dei tool insieme alla programmazione reattiva, quindi devo prendere il framework, smembrarlo in tool e dire ok la complessità è di tutti questi tool o è del framework? Ho sbagliato la domanda.È complessa, è difficile da inquadrare, nel senso che esiste un momento in cui il framework diventa più difficile da usare del linguaggio.Questa cosa è naturale per uno strumento che dovrebbe semplificare? Dipende da quanti problemi ti risolve da sotto al sedere e magari non sai nemmeno che ti sta risolvendo tutta una serie di problemi, vedi appunto l'esempio sulla autenticazione fatto prima, cioè ci sono tutta una serie di tutta una famiglia di problemi in uno specifico dominio in cui non hai nessunissima idea dei problemi che ci sono alla base e come pro condizione non ti interessa saperlo perché il tuo obiettivo è fare quello che viene dopo l'autenticazione.LM: guarda io faccio una provocazione, faccio l'esempio degli state manager nel front cioè spesso si sono costruite delle astrazioni come diceva Luca su astrazioni su astrazioni su astrazioni su astrazioni che alla fine viene da dire sì vabbè ma qual era il problema che stava risolvendo perché noi ce lo siamo dimenticati e capita nel mondo javascript a me è capitato più volte di vedere queste queste queste situazioni e a quel punto boom nuovo framework all'ultimo grido, elimina tutta questa complessità, ritorniamo al server side rendering, remix, ti elimina static site, tutto questo casino, ritorniamo al vecchio, ritorniamo alle chiamate HTTP, ritorniamo al vecchio posto del buon vecchio form.Quindi alla fine mi chiedo, ok, astrazioni che ci semplificano la vita, ma spesso questo semplificare la vita talvolta è anche una scusa che ci permette di accettare i livelli di astrazione che si accumulano.Però secondo me il tuo punto è assolutamente sensato, però io ci metto di mezzo quello che diceva Andrea all'inizio, nel senso che un framework dovrebbe essere una cosa che ti permette di essere più rapido, di essere più produttivo ed è un acceleratore.Nel E nel momento in cui il framework non lo è, come dici tu, forse lo stai usando per risolvere il problema sbagliato.Forse, ed è un errore che facciamo tutti, io stesso l'ho fatto tante volte, e nell'ecosistema Java è frequentissimo, cerchi di avvitare le viti con uno spremiagrumi, perché conosci Spring molto bene e cerchi di fare tutto con Spring, anche le cose per cui magari Spring è overkill o per cui Spring è proprio sbagliato.Secondo me, in quel caso lì, l'errore di fondo è scegliere acriticamente di usare un framework.Di nuovo è una cosa che stavi dicendo tu prima.Se tu scegli di usare un framework solo perché è una cosa che conosci bene e pensi che ti ci troverai bene, anche se stai facendo una cosa che non rientra nei casi d'uso del framework, ti stai di fatto sparando nei piedi, secondo me.Ed è il motivo poi, tra l'altro, per cui in questo momento, ad esempio, nell'ecosistema Java ci sono diverse alternative.C'è stato un momento della storia di Java in cui davvero esisteva solo Spring e nessuno al mondo faceva Java senza usare Spring.Adesso ci sono diversi casi d'uso per cui Spring non è la scelta migliore e quindi ci sono diverse alternative.però a volte capita anche che l'ecosistema ti forzi a usare un framework perché sembra davvero che sia l'unica scelta possibile.Secondo me è vero anche che il framework è una volta un trendsetter che può fare emergere delle necessità che non sapevi avere o comunque che non hai.Poi alla fine sono tutti corsi storici.alla fine.Se pensiamo a, proprio per dire la roba nuovissima, ma in realtà non lo è, se pensiamo a Inertia Adlesse, se pensiamo a HTML Overdue Hire, quello insomma di Rails e la controparte Symfony, se pensiamo a Turbolinks o la controparte Symfony e Laravel, insomma, Se pensiamo a queste cose qui, alla fine è come se ci fosse un ritorno a prima della single page application, a prima del framework JavaScript.Io ho avuto questa impressione da qualche anno a questa parte.C'è stato React, c'è stato Angular, c'è stato AngularJS, c'è stato Svelte, tutto si faceva sul client.E io mi sono sempre chiesto, ma quelli che devono fare SEO, cioè sono sempre rimasti con GQuery e con i template fatte a mano la risposta è sì - a me è interessante che io usi GQuery - nel senso, la risposta è sì e secondo me il fatto di esistere, ritornando verso questa cosa qui se vediamo come fa LiveWire o HTML Over the Wire o anche, insomma, inercia, o quello che fa live wire, in realtà, se vogliamo essere in ambito l'arade.E quello che si faceva anni fa, quando ti mandavi sulla post lo script javascript, che faceva query.appendchild e ci scherzava a detto l'html, con una sovrastruttura in più, ora è tutto più bello, ora è tutto più figo, ora va sul websocket.Ma alla fine quella cosa lì.E quando si diceva, io mi ricordo cinque anni fa, ma anche io quando lo dicevo, scusami, ma qui stiamo veramente inviando questo pezzo djs che fa dollaro punto appena? Sì, fuori esistono questi framework che fanno grossomonto la stessa cosa, sì, in una maniera sicuramente più elegante, più astratta, ma si sta ritornando verso quella cosa lì.Quindi secondo me il framework importa e mette sul mercato dei trend con cui poi ci devi convivere per X anni.E per questo nel mio modo è importante la scelta del framework.Non me ne vogliono gli affezionati a Gatsby o a Next o a Nuxt, ma non fare mai se sono Netflix e ho il budget, ho le persone e il turnover che ha Netflix allora io domani mattina dico si parte anche con il cerchio sviluppo e si fa la nuova sezione del mio prodotto in Gatsby.Ci sono siti Gatsby che non si buildano più.Sì, sono di Gitbar.Ok, ora tutto può essere che io non so utilizzare Gatsby, che non ho capito la tassonomia funzionale della bellezza di Gatsby.Io non capisco niente, va bene.Però è vero comunque che scegliere avere tutti questi strumenti con molta leggerezza può portare a delle conseguenze anche nel medio termine, perché non è che è nato 15 anni fa, questo ovviamente non significa che dobbiamo fare i siti con le servlet e con la server page, ma sicuramente avere giudizio quando si sceglie qualcosa, anche se comunque c'è un bellissimo fascino.io credo che è entrato il punto cioè nel progetto precedente al quale sto lavorando mi sono ritrovato a dover lavorare con un sito fatto in Next il cui stato Redux che utilizzava Redux Saga doveva girare sia sul server che sul client e doveva essere riconciliato.Questo per fare un e-commerce, che doveva mostrare dei prodotti e basta! E adesso, cioè, fondamentalmente eravamo dieci persone che lavoravano su quella roba, ma ne bastavano tre! Però, usare Next in quel modo era una moda.E allora mi chiedo, ed ecco perché la domanda partiva nel dire quando il livello di complessità esplode a livello framework forse abbiamo preso un granchio.Forse stiamo creando complessità per giustificare le nostre RAL e un po' meno per produrre qualcosa per andare nel mercato.Ed è un po' quello che in realtà il team di RemixJS si è posto cioè ad oggi anche per i piccoli progetti si stanno utilizzando degli stack il cui 90% è overkill io ho visto gente che per un progetto piccolissimo stava usando i micro frontend e ci hanno chiesto una consulenza sui micro frontend per un progetto di 6 visi e io mi incazzo e sveglio anche la bambina.Io mi arrabbio perché in realtà è anti economica sta roba, cioè domani mattina questa bolla esplode.Non lo so nel senso io qui ci appoggio veramente un dipende gigantesco nel senso che dipende davvero da tante cose dipende dallo scope temporale che pensi che avrà il progetto come diceva Luca prima se è una roba che fai adesso la mantieni per un pochino e poi te ne dimentichi, alla fine anche sticazzi.Dipende tanto dal team che hai a disposizione.Se hai un team di gente che conosce già perfettamente con lo strumento perché magari l'ha scritto, allora vabbè.Per dirti, a me è capito una volta che l'azienda per cui lavoravo assunse un team di consulenti perché dovevamo rifare tutto il front end di un'applicazione e a un certo punto era appena uscito React, quindi era usiamo React, usiamo Angular e loro ci dissero "no, usiamo jQuery" perché? Perché noi siamo main contributore di jQuery.Ok, scusate, ci avete ragione voi.Cazzo che vuoi dire.Quindi quello anche è un fattore, secondo me davvero la decisione di dire "usare un framework overkill o no" è una cosa che è molto facile da dire in generale ma ci sono tantissimi dipende sotto dipende dipende davvero da tanti fattori e quindi non so dirti sì anche secondo me overkill oppure no secondo me no nonostante nonostante al progetto però nonostante a un primo impatto ti direi assolutamente sì, cazzo hai ragione, sei visto i micro front-end overkill, però...Dipende anche da cosa stiamo guardando, perché se guardiamo il front-end c'è un ecosistema completamente diverso rispetto ai framework che ci sono a back-end, sono problemi diversi, sono molto diversi, diciamo così.Infatti a volte nei ragionamenti saltavo a seconda se stavo pensando a un framework JS o a un framework PHP.Una domanda che forse c'entra o forse non c'entra, mi rivolgo a chi usa framework massicciamente o per lavoro.Gli aggiornamenti, come li fate? le major release.Grazie per la domanda.Passare dal 4 al 5 perché adesso, tornando al discorso di Mauro, tutte domande che noi ci siamo fatti all'epoca l'azienda e spoiler, alla fine ci siamo fatti un nostro framework perché tra i vari dipende c'era anche il fatto che ce lo sapevamo fare.Ovviamente per problematiche molto banali, poco più che un crude e cose di questo tipo, però quando stavamo pensando se usare un framework oppure no e se sì quale io stavo vedendo ancora il codice che avevo avuto in eredità che c'era nel phpZend 1 e stava lì tatuato nel sistema, ma proprio tatuato, tutt'oggi non riesco ancora ad estrapolarlo quel cavolo di Zen 1 del sistema.Allora abbiamo detto sì, qualsiasi scelta facciamo adesso, i programmatori fra 7-8 anni, se siamo noi o non siamo noi, ci manderanno quel paese di sicuro.Però forse qualcosa mi sfugge, cioè ci vuole un piano per per aggiornare i framework che oggi decidi di utilizzare.Se faccio un mega...ovviamente parlo di progetti che devono avere una lunga durata, 7-8 anni almeno di vita.Io l'aggiornamento del framework lo vedo come un task, come un altro da mettere in pianificazione quando insieme al prodotto concordi cosa fare nel quarter.Quando passi da Symfony 1.4 a 2 soprattutto.Però secondo me anche lì c'è...Cioè, allora, su questo sono d'accordissimo.Secondo me lì c'è un dipende.Il dipende, in questo caso, almeno per l'esperienza che ho io recente, è che la tua necessità di aggiornare un framework dipende dalla velocità di aggiornamento di quello che ci sta attorno.Per dirti, noi usiamo tanto Spring per la parte back-end e usiamo Angular per la parte front-end.Quindi io ho un po' di contatto con l'ecosistema JavaScript e TypeScript e Java e Kotlin per il back-end.Spring è un framework super maturo e con una buona quantità di glitz stabili in un ecosistema che non è particolarmente avvezzo al seguire la moda del momento, per cui noi credo che siamo un discreto numero di versioni indietro di Spring e non ci crea problemi.Mi è capitato, nell'ultimo paio d'anni, almeno tre volte, che devo aggiornare un componente "No, puttana merda, Echo è compatibile solo con l'ultima versione di Angular e devo perdere due giorni ad aggiornare tutto Angular".Per cui, secondo me, dipende non tanto dal framework in sé, perché quando un framework è abbastanza stabile non capita di frequente che tu debba aggiornarlo per forza, perché sennò muore, ma dipende da quello che ci sta attorno, dipende da magari altri componenti che ci metti on top che hanno bisogno dell'ultima major.perché se no non funzionano e questa cosa succede più di frequente con alcuni framework piuttosto che con altri nella mia esperienza.Te ne dico un'altra, scusami Carmine, un piccolo parentesi.Immagina che tu vuoi scalare, sei su virtuale o su fisico, sono passati diciamo anni e vuoi creare una nuova macchina ma quando la vai a ricreare la nuova Debian ha tutte le estensioni di cui hai bisogno, le precate, non te le fa installare eccetera eccetera.E lì come la mettiamo? Ehi boss non posso scalare le richieste perché non abbiamo ancora aggiornato Spring? Eh questa è una bella riflessione ragazzi eh.vero, verissimo e soprattutto tu stai facendo una cambiale fondamentalmente quando scegli un framework, perché tu non sai quanto impattante sarà la prossima major release, lo puoi intuire ma non puoi saperlo e questo io prima ho fatto la battuta ad Andrea scherzando, parlavo del passaggio da Symphony 1 e 4 a Symphony 2, però la dicevo anche tra i denti perché è stata una di quelle cose che per la mia azienda è costata mesi di lavoro e mesi di lavoro quando ci sono tanti sviluppatori sono decine di migliaia di euro e sono mesi che sei fermo non puoi rilasciare nulla e quindi fondamentalmente tu stai firmando un accordo dove però hai una prospettiva più o meno chiara a seconda di quanto è chiaro il percorso di sviluppo del framework, ci sono alcuni framework tipo symphony che hanno le timeline definite, Laravel ancora adesso stanno iniziando da qualche release a questa parte a definire bene con chiarezza le timeline, non conosco altri sistemi, però comunque è un problema e alla fine è una cosa da considerare.Per cui, sì sei veloce, ma arriva un giorno dove tu sta roba la paghi.Quanto la paghi, vediamolo, però la paghi.Sì, ti impone il seguire anche lo sviluppo del framework che non è nelle tue mani e quindi stare dentro la community per capire quali saranno le cose che metteranno alla prossima release e vedere se si applicano poi nella tua applicazione.Quindi comunque è un costo in più piuttosto che magari avere il proprio framework dove sei padrone delle tue decisioni che magari sono più adatte all'applicazione che stai facendo.Quindi diciamolo, usare il framework non è gratis.Adesso voglio dire un'altra bold opinion.Ne abbiamo parlato in altre puntate di Gitbar, ne abbiamo parlato nella 90 con Francesco Strazzullo, ma ne abbiamo parlato in modo dettagliato con Alessandro minocchieri nella '78, no? Di hexagonal architecture.La mia è una provocazione, prendetela come tale, però quanto utilizzare l'hexagonal architecture è un alibi? Cioè, se noi ho una giustificazione che ci diamo o un modo per darci la pacchetta sulle spalle e dire "ah vabbè dai stai tranquillo che in fondo hai usato l'architettura esagonale quindi non sei proprio fino al collo nella merda, la merda ti arriva fino al busto ma non fino al collo, nel senso che proviamo a spogliare la nostra applicazione di tutto quello che l'impianto, che il framework ci dà, di tutte quelle che le decisioni ci danno, quanta business logic in realtà salviamo della nostra applicazione e quindi quanto siamo al sicuro utilizzando l'eseguente architettor.Queste sono quelle cose da fare maniera tra i dev e non far andare nella board tipo nel senso abbiamo tolto l'arabel e ci sono sei righe di business logic che cosa stiamo vendendo? Secondo me è una domanda interessante però poi alla fine nel senso, altra boldopino adesso la lascio qui, i framework dei linguaggi passano, l'architettura resta.Alla fine, se pensiamo all'MVC, come concetto, come architettura, non cambia, sono i framework che cambiano.L'investimento secondo me è sì sullo scegliere il framework giusto, ma anche secondo me è sull'uscire a prevedere e su riuscire a prevedere la futuribilità dell'architettura.Nel senso a me è capitato di fare un aggiornamento da Rails 5.2 a Rails 6.Mesi, destemmie, non si capiva niente, ma non perché DHH era il peggior capo della Silicon Valley, ma perché noi abbiamo fatto delle pesanti modifiche al framework.Alla fine si ritorna a quella cosa lì, se abbracci il framework va tutto bene, se cominci a martellarlo non lo aggiorni più.Cioè ci sono cose che sono inaggiornabili.Io ho visto delle patch che abbiamo dovuto fare a a mano in ActiRecord, in Puma, in Rake per poter andare verso l'aggiornamento e poi toglierle.Ma a questo punto, se l'aggiornamento del framework ti frena così tanto e non ti lascia e impatta così tanto sul tuo prodotto, non è forse un problema del prodotto e non del framework? a me è capitato ed è capitato e la scelta mia è stata ok quello sta bene là io faccio new repository prendo il framework aggiornato ad oggi riconfiguro tutto ci riporto le logiche di business ci riapplico i test che avevo di là e porta a casa questo pure un altro approccio quando qualora è passato talmente tempo molto spesso guardiamoci chiaro c'era davvero costoso farlo aggiornare quindi io preferisco l'approccio faccio poco ogni tanto a breve termine poco ogni tanto poco ogni tanto anche se non arrivo sempre all'ultima LTS ma però ci sto sempre vicino ok? Puoi pure arrivare fino a lì, ti spingi fino a lì senza problemi però se ti rimani troppo indietro ragazzi poi o so davvero madonna oppure accanni e fai "gnu" e ti riporti la roba.E sui progetti nuovi cosa succede se il team sa usare il framework, non sa usare il linguaggio, sa usare il framework alla versione X e il progetto nuovo sei costretto a farlo alla versione X nonostante sia vecchia questa cosa che io ho visto.Secondo me quello lì è la morte completa quando sei costretto a cominciare qualcosa di nuovo già con il debut.A quel punto di chi è la colpa? Del team, del manager o del friend? È una bella domanda.E con questa domanda io direi che ci avviciniamo alla fine dell'episodio.Posso dire solo una cosa.Io ho fatto il nuovo tutto, ok, riscriviamo eccetera eccetera, ho eliminato ogni cosa.Ovviamente si parla dal PHP, ero talmente tanto scottato da Smarty che avevo ereditato, ho detto "no, il template adesso si fa in PHP puro", così come era nato, fatto un piccolo wrapperino che fa le scape eccetera eccetera da solo, guai a voi se inserite una libreria che fra dieci anni vi sputo in un occhio, no? Facciamo in PHP puro, è un po' più verboso, pazienza, ci conviviamo.Lato PHP, lato JavaScript c'era ancora, c'era Angular, e Dio grazie che non l'abbiamo utilizzato perché sto parlando angularjs non angular 2 quindi mi sono mi bacio ancora le chiappe cosa facciamo ho usato require ma non require cioè la una funzione require semplicemente in vanilla per...vabbè c'è tutto l'ecosistema dietro qualche riga di codice di javascript di libreria che ci siamo fatti dietro.Non abbiamo usato un cazzo, cioè non abbiamo usato nessuna libreria, nessuna niente, a parte Gequery ovviamente, però non abbiamo problemi di aggiornamenti, non abbiamo più dipendenze.Sta ormai da sette anni, abbiamo aggiornato anche il PHP, l'ho cominciato dal 5.4, adesso sta alla 7.3 e tra poco andremo alla 8.1, non ho dovuto toccare niente.Ed è per questo che io sono contro i framework in toto.Visto che Luca ha aperto un trend, io direi che ringrazio un attimo i due donatori di questa settimana e poi facciamo, prima dei ballocchi, un giro velocissimo dove fate da avvocati del vostro framework, quindi da commerciali per il vostro framework preferito e poi andiamo a chi lo Ringrazio Mirko Introini che ha donato una birra scrivendo grazie per l'ottimo lavoro che fate, vi meritate proprio una birra ghiacciata anche se parlate male del mio amato PHP.Dai non stasera, dai non stasera.Chi è che parla male di PHP o chi è che si permette di fare una cosa del genere? E abbiamo anche Vincenzo Masciullo che ci ha donato un'altra birra.devo dire che abbiamo spostato la funzione di donazione quindi la trovate nel sito col pulsante supportaci perché ci siamo spostati direttamente su paypal.Aiutateci a testare se funziona donandoci dei soldi.Volevamo scrivere un framework per ricevere i pagamenti e tutto però ci siamo appoggiati su altri framework.Facciamo un giro rapido iniziamo da Leo.Leo hai un minuto per venderci il tuo framework preferito.Se state ascoltando questa puntata forse volete fare partire il vostro progetto e se volete farlo partire volete anche monetizzarlo.Al di là che PHP usa i dollari per identificare le variabili, quindi va già a capire dov'è che starete andando, io vi consiglio di utilizzare l'Aravel che ha una curva di apprendimento non ripida e vi permette di andare in produzione su un server bucatissimo, però tanto quello non è un vostro problema.Perché prototipate l'applicazione velocemente, fate le cose, capite cosa non va e poi scrivete il vostro framework? Infatti io non ho un framework da consigliare, però potrei consigliare di scegliere saggiamente il framework da utilizzare.Prima di buttarvi a capofitto nello scegliere un framework quale esso sia, pensate innanzitutto dovete capirlo, dovete sapere bene dove finisce il linguaggio e comincia il framework e viceversa.Alla fine penso che voi dovete usare il framework quando probabilmente pensate di non averne bisogno.Perché ormai siete padroni del linguaggio e quindi potete fare le vostre cose e è lì che potete utilizzare il framework, opinionato, non opinionato, quello che volete, perché saprete i limiti del framework e del linguaggio.Questa è la mia perla di saggezza.Io l'ho già nominato più volte, quindi mi tocca dire di nuovo che Spring è vita, Spring è tutto, Spring ti vuole bene, Spring fa tutto quello che vuoi e anche di più, perché Spring è modulare, Spring fa un sacco di cose, ma lo puoi spacchettare come vuoi tu.Quindi ti aiuta a non dover prendere delle decisioni perché il signor Spring le ha già prese per te, ma puoi decidere tu quali di queste decisioni vuoi nella tua applicazione e quali no.Soprattutto Spring, ho scoperto di recente che in alcuni dei suoi componenti, come Spring Security, nei suoi test usa il framework di mocking più bello del mondo.E quindi questo è un ottimo motivo per usare Spring.Carmine? Allora, io non posso fare altro che dire "Viva Ruby, viva Rails, viva Basecamp".No, vabbè, io vi...Viva la nipote di Mubarak.Io consiglio di utilizzare Rails, se avete un progetto che volete far partire in maniera veloce, volete scrivere del codice che è elegante, volete utilizzare un framework che è stato progettato così come il linguaggio stesso per la felicità dello sviluppatore, utilizzate Rails.Pensate macro, non pensate micro.Volete partire fin da subito con l'ultimo framework per i microservizi, volete spacchettare il dominio, volete fare tutte quelle cose fighe, ma non sapete che cosa volete fare davvero, quindi pensate macro.Questo con qualunque framework avrete tutto il tempo se sarà necessario per diventare micro.Rails ha tanti componenti, ha una grandissima community, ha una libreria per ogni cosa e vi permette con la giusta a concortenza di concentrarvi sul prodotto e non sul reinventare la ruota.Una volta che avete fatto il vostro prodotto con Rails e lo avete messo in produzione, potete fare tutti i vostri round di finanziamenti per poi aprirvi una bella pizzeria in Puglia.Andrea.Siete uno più bravo degli altri.No, io vorrei dire, vi consiglio di ascoltare quest'ottima sinfonia per raggiungere il vostro obiettivo in maniera più fastify possibile poi essere sempre un next davanti agli altri.Beh l'hai detto in modo poetico e apprezzo.Io in realtà sono bitesta oggi, le mie due personalità mi spingono in due lati diversi.Da una parte c'è la parte pragmatica che urla "make the monolith great again" e quindi vi dico se dovete fare qualcosa di veramente rapida la Ravel è il modo più rapido per farlo.Dall'altra mi sono innamorato di Fastify e non è una scelta aziendale, è proprio una roba, non amore a prima vista non solo perché è veloce ma perché poi cioè alla fine è davvero plastico anche se qualcuno dice che non è un framework ha anche ragione, che non so cosa sono i framework, cosa sono le librerie.Alla fine di questo episodio sono più confuso di come l'abbiamo iniziato, quindi ho visto allora possiamo anche chiudere.Che ne dite ragazzi? Dire di sì, ma devo ancora, scusate, devo dire una cosa che mi sono scordato prima, perché io l'ho sempre per scontata, però la dobbiamo dire.Scegliete il framework, quello che volete come ho detto io, però non scordatevi di usare jQuery per riconoscenza.Includetelo e non usatelo.Includetelo e non usatelo.Includetelo sempre.Un paio di richieste al giorno al cdn di jQuery per la riconoscenza.E poi soprattutto in questa puntata non si ha parlato di SAP, ma si farà proprio una puntata dedicata solo a SAP e perché costruire la vostra villa in Abruzzo dopo aver lavorato con SAP.Perché fare dei muratori! E arriva l'acqua e era subito! Qualcuno vuole parlare anche di...Salutiamo il signor SAP che viene ci siamo dati la sap sui piedi.Io lo sap evo.Questo è evidente segnale che dobbiamo chiudere, ma prima di chiudere abbiamo il nostro momento, il paese dei balocchi, il momento in cui in questo caso i nostri baristi condividono con noi un libro, un talk, qualunque cosa abbia catturato l'attenzione.A questo punto iniziamo in ordine inverso da Andrea."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" "Andrea ho appena scritto in chat che non lo so, dammi il tempo di trovarlo, che ne Aiutami, no? Ok, non l'avevo vista la chat, allora partiamo da Leo.Allora, io ruberò sicuramente il balocco a qualcuno, perché casualmente metterò un balocco che è in tema con la puntata, cosa che non faccio mai.Questo è un articolo che si chiama "Why I Hate Frameworks", che è una storiella molto carina e divertente perché l'autore non vuole utilizzare i framework.Non spoiler nulla, spoiler solo una cosa, questo articolo è del 30 settembre 2005, ma tuttora attuale.Mi raccomando mandalo perché mandamelo se no ce lo dimentichiamo.Luca? Io ho un balocco proprio preso così al di sfuggita e dalla libreria che c'ho dietro, ho preso un libro, un libro a caso ed è "Tecniche di memoria e lettura veloce".Lasciamo stare la lettura veloce perché secondo me è una minchiata, però le tecniche di memoria, leggendo quel libro, le ho studiate, non le ho memorizzate perché avevo bisogno del libro, ma via via che leggevo me ne sono scordate però mi sono tornate molto molto molto utili soprattutto se sei come me che ha problemi di memoria si può sopperire si può si può riuscire a provare a padroneggiare delle tecniche per memorizzare tutto quello che i framework ci dicono di memorizzare per usare il linguaggio e per usare il framework in modo veloce ed efficiente.Sono sono le 23.05, mi sto parlando proprio a caso.Mattia? Allora, io ho il solito vizio di ballocare il libro che sto leggendo, sono credo al 20%, quindi magari il rimanente 80% è una merda, ma il 20% che ho letto è davvero, davvero molto bello, e ve lo consiglio molto.È un libro che si intitola "Staff Engineer, Leadership Beyond Management Track", e praticamente parla di tutta quella categoria di sviluppatori che sono senior developer da un po', perché hanno sbattuto la testa contro il framework abbastanza, magari ci hanno guardato dentro, magari hanno anche scritto dei framework o pezzi di e vogliono fare il passaggio successivo della propria carriera, che tipicamente nella scala di carriera italiana è, ok, sei molto bravo a scrivere il codice, se smetti di scrivere il codice, gestisci le persone.E questa cosa si è scoperta di recente che non a tutti piace.Per le persone a cui non piace, appunto, c'è questa serie di consigli, strategie, guide, esperienze reali di gente che lo fa, di come fare a fare lo staff engineer, che è il livello sopra il senior engineer, che è quindi quello che, ok, scrive del codice, ma non solo, e fa quello che nelle aziende grandi si chiama individual contributor, quindi non fa il people manager soltanto, ma fa anche quello in termini di leadership, mentoring, coaching, disegno delle architetture e quant'altro.È super interessante perché, almeno nel mio caso, è molto spot on sul momento in cui sono io, nella mia carriera in questo momento, per cui mi riconosco davvero in tante delle storie.Quindi mi piace un sacco.Interessante.Carmine? Io ho tutta una serie di balocchi democristiani per far conto di tutti.Innanzitutto c'è la doctrine di Rails, che possiamo definire come il manifesto, la dottrina, se vogliamo tradurla in italiano, di Rails e dei valori fondamentali di Rails.di Rails.Vi invito a leggerlo anche se non utilizzate Rails, perché ha degli spunti interessanti per poter capire anche il perché del percome degli strumenti che utilizziamo.Poi la triade bellissima che è gorails.com per imparare Rails, sono degli screencasts, LaraCast per Laravel e SymfonyCast per Symfony.Io ho imparato il PHP e Symfony su SymfonyCast tutti e tre, o almeno sicuramente sia l'Aracast sia Symphonicast, hanno anche un free tier se sei studente e Symphonicast e Go Rails sono inclusi anche nel GitHub Student Pack, quindi è un'occasione per tutti per poter veramente imparare qualche cosa di nuovo.confermo l'Aracast è fatto veramente bene allora, bravo inpreparato, non sono riuscito a trovare nulla che mi convincesse quindi non vi lascio, la mia scelta è del balocco, è di non lasciarvi un balocco ma di ribadire il concetto di quanto sia importante utilizzare il framework e non soltanto a livello di layout e applicativo ma anche a livello di oro di ora.Ebbene siamo arrivati al momento di chiusura, momento dove ci salutiamo e voglio dire una piccola cosa, l'argomento di oggi era un argomento difficile, diciamolo pure perché parlare di un framework che sono ormai davvero tanti importanti nel nostro lavoro di tutti i giorni non è poi così facile perché bisogna anche ammettere che talvolta o lo si usa male o comunque bisogna posizionarlo nella nostra visione complessiva di lavoro e fare questo in modo consapevole non è per niente semplice e spesso il framework sono anche padri di grandi guerre di religione.Parlavo proprio oggi con una persona pensando a queste guerre di religione e alla fine ne ho concluso che fondamentalmente il nostro mondo si muove in modo molto veloce, forse anche troppo veloce ed è un mondo ampissimo, guardate solo oggi abbiamo parlato di, ridendo e scherzando, almeno 10 framework e apprenderli tutti diventa un carico cognitivo importantissimo.Per cui alla fine secondo me queste guerre di religione non sono altro che un modo inconsapevole che abbiamo per giustificare le nostre scelte cercare di ridurre lo scopo.Io non so ancora se questo ragionamento è corretto o meno però ne sono sempre più convinto.A questo punto credo che quando si parla di framework, cioè sui framework in realtà non c'è nulla di sbagliato tranne quando pensi che non ci sia nulla di sbagliato.Che povereta! In guerra, in amore così come nel web development tutto è illecito e ogni framework è illecito.Nessuna pietà! Nessuna pietà! Fuori dai framework nessuno è perfetto! detto questo io ringrazio ancora Leo, Luca, Matti, Andrea e Carmine grazie per aver raggiunto le 11 e mezza e non essere collassati davanti alle cam in una giornata di duro lavoro noi ci diamo appuntamento alla settimana prossima quindi ciao ragazzi, grazie, ciao a tutti, gruppo telegram Gitbar.Lupo Tega mi raccomando solo Drupal e Magento sempre.Sapo, sapo, sapo.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 strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
