Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel circolo, nel bar degli sviluppatori Oggi non sono solo e ho al posto di uno ben due ospiti Però prima di introdurli il mio compito, il mio ruolo un po' noioso ormai lo sapete è quello di ricordarvi rapidamente i nostri contatti info@gitbar.it o @brainrepo sono i modi canonici per contattarci poi naturalmente c'è il nostro amato gruppo telegram, gruppo telegram dove proprio oggi abbiamo condiviso le foto dei setup delle nostre scrivanie, è stato un momento flex dove devo dire che quest'ultimo, in queste foto ho visto che i monitor ultra wide vanno per la maggiore, prima o poi dovrò comprarne uno, magari quando la casa me lo permetterà però bando alle ciance e direi che possiamo iniziare Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo [Musica] Oggi ho con me Luca Lusso e Marco Primitivo.Ciao ragazzi! Ciao, buonasera! Ciao, buonasera! Grazie per l'invito! grazie a voi per averla accettato.Siete due Sparkfabriker o come vi chiamate tra di voi? Sparkers! Sparkers! Ecco qua, due Sparkers d'eccezione.Qualche tempo fa, in una puntata, il buon Carmine aveva aperto una sorta di flame nei confronti di Drupal.trovato a lavorare su Drupal e ha buttato una battuta di lì.Paolo, che è molto attento, non se l'è lasciata sfuggire e quindi tornando a casa sua, Spark Fabric, ha scelto le migliori lance della società per andare a difendere questo CMS.In realtà non è una battaglia tra CMS però è sempre interessante approfondire l'argomento e capire come Drupal in realtà ha sposato questi anni 2020 successivi.Allora la prima domanda che voglio fare a Luca e Marco è come siete entrati in contatto con Drupal? Era, credo, il 2006-2007, al tempo Drupal era la versione 5, quindi il medioevo dello sviluppo.Per quanto riguarda Drupal mi serviva, se stavo lavorando, a un progetto con un amico per appunto un sito di una scuola sostanzialmente, che doveva poter essere gestito poi dai professori e quant'altro.Arrivavo ad un'esperienza di cose fatte super custom sempre in PHP e derivazioni con altre CMS.Se non che è capitato su Drupal, mi è piaciuto praticamente da subito la sua possibilità di strutturare contenuti, di poter costruire cose via interfaccia web molto complesse ma molto facilmente e da lì è cominciata un po' la mia esperienza.Io invece era il 2009, fresco di laurea, appena cominciato un nuovo progetto, un nuovo lavoro, e mi hanno presentato...il cliente voleva Drupal, semplice.Quindi full immersion, tanto lavoro, da subito.In quel momento in realtà avevo già messo mani, diciamo, durante l'università, su altri framework che i PHP o altre cose così.E Drupal era a livelli superiori proprio, anche a livello di integrare cose complesse da subito anche se non avevo tantissima esperienza.Da lì è cominciata l'avventura.Fantastico.Marco ha risvegliato CakePHP che è stato credo una delle cose che è apparso in tutte le vite, davanti a tutti gli sviluppatori PHP, i quali hanno sempre cercato di tenersi alla larga ma in un progetto o nell'altro ci sono cascati.Mi sbaglio.e siamo cominciati da là poi subito Drupal, da lì ho provato altri CMS però Drupal è stato il primo amore l'ho portato avanti fino ad oggi con molto orgoglio diciamo, molto contento di averci messo le mani dall'inizio Quali erano le feature che distinguevano Drupal da altro tipo di CMS? Avete riconosciuto come killer feature? Cosa condizioni si ne equanon per adottarlo? Su Drupal 6, che è stata la mia prima versione di Drupal su cui ho messo mani, sono stati gli hooks che praticamente ti permettevano con il codice di agganciarsi in ogni punto del flow della request, quindi fare tutte le alterazioni dovute per quella feature quella è stata all'inizio la funzionalità che mi ha colpito di più insieme ai blocchi può sembrare banale, però quella cosa rudimentale in Drupal 5, credo fosse, quando è stato introdotto, il block...Sì, direi di sì.Io non ho mai usato il versione prima della 5, però nel 5 c'era.Era una funzionalità, diciamo, in quel tempo, non dico innovativa, però era molto interessante da esplorare il fatto di poter mettere pezzi di componenti, chiamiamoli così, in un punto della pagina, in una regione della pagina con molta facilità attraverso una user interface.Quelle sono state le prime cose, poi man mano ne sono arrivate tantissime altre.In quel periodo c'era la...anzi faccio due passi indietro.Cosa vi ha spinto ad adottare Drupal piuttosto che fare qualcosa con quelli che poi erano i framework che emergevano quel periodo? Io ricordo un primo Symphony.Cioè perché andare verso un CMS quando si aveva un framework che era magari un pelino meno opinionato o potevi fare cose diverse magari più più ampie.Chiaro, ma allora nel mio caso io arrivavo appunto ad aver sviluppato cose custom, forse senza neanche framework, quindi praticamente da zero.Il grosso vantaggio di Drupal in quel contesto lì e soprattutto nei confronti di siti e portali con contenuti particolarmente strutturati era appunto la possibilità di definire l'interfaccia quindi senza dover necessariamente sviluppare niente, definire la struttura dei content type, quindi le scatole in cui si possono mettere i contenuti all'interno di Drupal, che sono a loro volta delle collezioni di campi di diverso tipo, test, immagini, o qualsiasi altro tipo di widget possa servire per costruire una pagina.Questo, dal mio punto di vista, è stato molto più efficiente, probabilmente piuttosto che implementarsi anche usando un framework, le cose da zero, per la velocità sostanzialmente e per magari venire incontro ai repentini cambi d'idea dei clienti, voglio questo campo lì, questo campo là, questo sopra, questo sotto.In Drupal si configura tutto quanto con un'interfaccia web, questa parte della costruzione delle strutture dati.e questo è molto potente.Dopodiché Drupal è costruito sopra un framework al tempo era tutto proprietario, nel senso coscritto dagli sviluppatori di Drupal adesso e Symphony anche lì, che ti permette poi di estendere questa cosa in maniera molto facilmente, quindi non esiste il tipo di campo che ti serve, non esiste la struttura dati che ti serve, è molto facile contribuire al tuo pezzettino e estendere Drupal stesso per fargli fare le cose che ti servono.Quindi in realtà mi stai dicendo io posso costruire, o potevo, posso, la mia struttura dati, semplifichiamola, il mio articolo del sito, la sto banalizzando, no? Io posso costruirla direttamente tramite UI e se mi manca un particolare dato, un particolare Fonofield, faccio poi io? Esatto esatto, è un po' ne parlavamo con Marco l'altro giorno, Drupal mette un po' insieme il meglio diciamo così di questi tre aspetti, è un framework, quindi posso costruirmi i miei pezzi che mi servono e un CMS fatto è finito, quindi posso installarlo e usarlo senza dover scrivere codice ed è una una community con migliaia di moduli che contribuiscono pezzi che mi mancano.Quindi posso scrivermeli, posso usare il core per fare già parecchie cose, posso scaricare un componente già pronto.Ad esempio, nel mio articolo che citavi devo inserire un punto sulla mappa dove si svolge un evento o qualcosa del genere.Ho il mio componente che mi porta dentro il tipo di campo Georeferenza, clicco sul punto su Google Maps, lui si salva le coordinate e sul front end posso rendere quello che voglio.Quindi è un po' il meglio che si può avere da questi tre aspetti diciamo.Quindi uno dei ruoli poi dello sviluppatore che lavora su Drupal è quello di creare questi campi custom.Anche, ma non solo.Nel senso, la parte della struttura dati è un pezzo, diciamo, di una costruzione.Quindi i campi servono lì per solo contenere del dato.Che tipo di dato? Questo lo definisce il tipo di field.Come diceva Luca, può essere un geo field che contiene una latitudine o longitudine, piuttosto che un email, un semplice testo, un testo formattato, ma qualsiasi altra cosa.però ci sono tanti altri punti di intervento che si possono ottenere sia operando in modo custom, ma anche sfruttando i moduli o i temi della community.Esempi, non lo so, per esempio estendere Drupal per supportare un file system per il cloud.Drupal di core non ce l'ha, ti dà un set di strumenti per avere un file system e gestire quello locale.Però quegli strumenti ti permettono di estendere il core per avere un altro tipo di file system, che può essere un S3 o un NFS o qualsiasi altra cosa.ma come il file system, il database.Di base te ne dà alcuni, mi pare ci sia MySQL, Postgres e SQLite di base, però ti dà anche gli strumenti per sviluppare i tuoi driver per connetterti a un altro tipo di database.Questo è quello che ti dà il core di Drupal.Ti dà accessibilità in ogni punto della sua logica e flow per intervenire in qualsiasi modo insomma come richiesto da specifiche o needs di un cliente.Quindi fondamentalmente quello che si fa è quello di attaccarsi a degli ucco o esiste anche una logica per costruire degli handler a delle rotte fatte? Assolutamente sì.Come posso dirti completamente in PHP cioè io voglio un modeller che mi fa sta roba custom, lo collega a una rota e a quel punto...Sì sì sì sì il core di Drupal si basa sul routing di Symfony quindi le definizioni dei routing diciamo sono quelle classiche di Symfony, tu le definisci in PHP, definisci il il tipo di root, su quale callback, classe, eccetera, eccetera, logiche di accesso, e lui su un determinato path ti andrà a chiamare quella funzione lì, metodo, classe che è, per fare quell'operazione, se hai gli accessi.Quindi Drupal, diciamo, di core ti permette già di fare questo.In più, la questione del look, diciamo, si è evoluta sfruttando l'event dispatcher sempre di symphony quindi ci sono degli event subscribers sia di core ma anche custom che possono sviluppati o di altri moduli che ti permettono di agganciarti a qualsiasi tipo di evento dispacciato dal core per fare gli handler quindi le operazioni richieste Mi sembra di ritornare a quando ancora lavoravo su Symfony qualche anno fa.Quello che mi viene da chiedere è se Drupal usa i Symfony Components e basta, oppure utilizza proprio il framework Symfony con la sua Glue Code e tutto il suo contesto.No, esatto.Drupal non è un'applicazione Symfony, quindi non è costruita sul full stack di Symfony, ma utilizza, credo, almeno una quindicina di componenti di Symfony per fare quello che deve fare, dal routing, la dependency injection, l'event manager, l'event plugin, esatto.Le cose forse significative che non usa di Symfony sono le form, che sono ancora una struttura tipica di Drupal, quindi la gestione delle form, e l'interfaccia col database, quindi non si usa Doctrine, ma un layer sempre sviluppato dalla community di Drupal per interfacciarsi ai database.Gran parte del resto è Symfony, fino a Twig.Ah ecco, una parte quindi mi hai già risposto perché volevo arrivare al template engine.No, facciamo due passi invece verso le form.Come funziona il sistema di form? Nel senso, quando tu vai a creare le tue strutture dati custom, da cosa parti? definizione di una classe PHP che è una sorta di entity o lavori sulla form che definisce l'entity all'interno.Come funziona la gestione appunto di queste strutture dati? Sia quando tu ti crei le primitive, quindi quei moduli che estendono poi quelli che non hai in attivi, oppure quando lo vai a a fare da UI? Sì, sostanzialmente Drupal tutta la parte di contenuto gira attorno al concetto di entità.Entità che possono essere di configurazione o di contenuto.Adesso lasciamo da perdere da parte un secondo l'entità di configurazione.L'entità di contenuto sono quelle in cui vengono appunto memorizzate le informazioni e come dicevamo prima sono collezioni di campi.Il core del gruppo ne mette a disposizione un top di entità di contenuto già esistenti, quella principale è il nodo, che è poi l'informazione che viene utilizzata per costruire le pagine, insieme a un'altra entità particolarmente significativa, che sono le tassonomie.Quindi poi alla fine usi nodi e tassonomie per rappresentare l'informazione.Queste entità sono poi collezioni di campi.Ciascuna di queste cose, sia i nodi che i campi, sono rappresentati da classi che caratterizzano quello che devono fare.Competito dello sviluppatore all'interno del gruppo è definire nuove entità.Quindi, ad esempio, devi fare un e-commerce, potresti voler l'entità prodotto, che è diversa da un'entità contenuto perché magari ha un ciclo di vita o delle caratteristiche differenti.E all'interno dell'entità definire i campi che la compongono.Campi che possono essere o definiti programmaticamente, o aggiunti da interfaccia web sulla stessa entità.Quindi io posso avere la mia entità nodo con alcuni campi R-coded in codice e quindi a disposizione di tutti.E altri campi invece contribuiti da poi chi userà il tuo modulo, la tua funzionalità direttamente dall'interfaccia web.Quindi è un ibrido, possono essere ibridi.Quindi quando io aggiungo, faccio un modulo, ok? Questo modulo mi serve per memorizzare il prodotto, come detto prima, questa entity.Bene, hai detto che l'utilizzatore potrebbe definire dei campi aggiuntivi, no? Esatto.Questi campi aggiuntivi dovevano affinire nella struttura della entity o nel database? Questa domanda perché? Io ho utilizzato Strapi.Una cosa che Strapi fa, che a me è piaciuta tantissimo, è che in realtà funziona con un approccio in stile code generation, quindi quando crei un entity lui ti va a generare proprio il codice del controller, il codice che ti serve per far funzionare, anche se tu lo stai facendo da UI.Funziona così anche Drupal? No, allora la definizione dell'entità e dei campi che contribuiscono all'entità diciamo Arcoded sono in codice e anche tu se devi crearti una tua entità devi scrivere la tua classe con tutti i metodi che sarai ereditando probabilmente da qualche classe del core di Drupal e lo scrivi in codice.Insieme alla tua entità devi definire la struttura dati che verrà salvata sul database in modo che Drupal sappia su che tabelle memorizzare le informazioni, mentre invece tutti i campi che aggiungi da interfaccia web generano nuove tabelle sul db.Quindi tutte le volte che aggiungi un campo a un'entità Drupal crea la sua tabella che avrà colonne in numero e in tipo specifica a seconda del campo che hai aggiunto.Quindi se è un testo avrà una colonna per memorizzare il testo, se è un punto geografico avrà una colonna per longitudine, una per longitudine e così via.Durbar poi, quando mostra le informazioni, ricostruisce tutto quello che gli serve a partire dalle sue tabelle che ha definito sul database e ripopola la tua entità che può essere poi visualizzata sul front end.Per cui, correggetemi se ho capito bene.Allora, fondamentalmente io creo.c'è una sfumatura un po' diversa che devo evidenziare tra il concetto di entity quando si lavora in un ecosistema di framework e il concetto di entity come lo stiamo vedendo adesso perché in realtà un entity può contenere delle entity al suo interno che sono i possiamo immaginare i fields, i modulati latitudine e longitudine del campo geo per capirci allora quello che mi chiedo è Drupal genera delle tabelle a partire dalla UI esatto e genera una tabella per ogni modello per ogni tipo di campo che tu vai ad aggiungere e poi gestisce tutto con le relazioni se ho capito bene anche ma non solo allora l'informazione che è quel tipo di nodo a quel tipo di field è memorizzata in una config entity che è l'altra medaglia di quello che diceva prima luca.Di quello che abbiamo parlato adesso sono le content entity quindi nodi tassonomie le config entities sono strutture dati che contengono informazioni tecniche per la configurazione di qualcosa.In questo caso sono dei fields.Quindi quando io creo un nuovo field tramite UI, Drupal lo va a generare due config entities per quel field.Una è il field storage che va a definire tutto ciò che è la parte di storage di quel field.quindi le tabelle, se ha il revisioning, anche la tabella di revisioning, qua le colonne, eccetera, eccetera.Un'altra è la field instance, che dice quel tipo di field è agganciato a quell'entità.Tramite questi trick, diciamo, si mette in relazione la content entity con una field.Le relationship, le entity relationship, sono dei tipi di field che mettono in relazione una content entity con un'altra content entity per creare queste relazioni di non lo so oggetti di contenuti che relazionano non lo so fai finta di avere il contenuto taggato dev tu vuoi sempre lo stesso tagger utilizzato su tot2pagine quella è una relazione che c'è tra la tassonomia e un nodo Quindi ricapitolando perché qua il gioco si fa duro e si inizia a complicare specie perché non avendo una lavagna o comunque uno schermo davanti magari è un pochino più impegnativo ditemi se ho capito bene allora io ho il mio contenuto, la mia struttura dati di un articolo bene c'è il titolo, c'è il testo e c'è la nostra georeferenza la georeferenza è fatta da latitudine e longitudine per una sorta di componente custom questo componente custom non c'è immagino, non lo so, la butto là, non c'è nel core magari c'è anche ma in questo momento facciamo che non ci sia non c'è infatti non c'è, è un contri modulo ok c'è questo modulo, questo modulo che cosa va a fare? cosa vado a fare io programmatore che lo realizzo? io definisco la struttura dati e quando poi lo appiccico alla struttura dati del mio articolo devo definire sì da una parte c'è l'entity che è quella che definisce lo schema dell'articolo dall'altra c'è anche la config che la collega all'entity che definisce quel campo.Esatto sostanzialmente quando definisce un nuovo campo aggiuntivo a quelli che gruppo aggettiva devi e dirgli tre cose.Come sarà salvato sul database, qual è la form, come dicevamo prima, che il redattore userà per imputare il campo dentro l'entity, e il formatter, quindi come poi quel campo verrà mostrato sul frontend all'utente finale.Questi tre pezzi costituiscono il campo, che poi attraverso le configurazioni viene attaccato all'entità a cui vogliamo, e quindi permette al redattore di trovarselo tra i campi che deve compilare quando crea un articolo e a chi crea il front end di ritrovarselo tra gli elementi che può posizionare nella pagina sostanzialmente.Chiaro.Domanda, invece la form come la definisci? Perché hai detto "sì, c'ho l'entity, ma poi c'ho anche la form e poi il formatter", no? Sì, esatto.Come viene definita la form? Allora, le form sono forse uno dei pochi talloni d'Achille che sono rimasti anche nell'ultima versione di Drupal e che è un retaggio delle versioni precedenti perché le form sono ancora un enorme array multidimensionale PHP con dentro cose.Quindi senza una grossa struttura ben definita.Quindi hai un array che contiene un insieme di chiavi che descrivono quel campo, quindi se quel campo è un text field, qual è il suo titolo, qual è la sua descrizione, quali sono le sue funzioni di validazione, gli suoi handler di submit, tutto però molto grezzo.Cioè uno dei grossi cantieri aperti è il sostituire questo meccanismo con qualcosa di più obietto-oriente ed o strutturato, ma è ancora un cantiere, non ci sarà ancora neanche nel prossimo Drupal 10 che esce tra poco.E l'atto di interattività quindi che ne so io vengo dal mondo React per me le form sono delle robe responsive che clicchi lì, esplode là, fa questo trascini, muovi, fai, mostri come puoi raggiungere questo risultato? Parlo dell'admin panel, quindi dell'administratore e ve lo dico perché ho avuto un problema simile con strappi la possibilità di definire dei tipi custom programmaticamente ti permette di definirle ma hai dei problemi con i form field pur essendo strappi iscritti in react cioè se voglio fare un field che inserisco il valore e fa una chiamata per verificare se l'indirizzo è corretto, diventa rosso mi evidenzia i pezzi sbagliati neanche là si possono fare.In questo caso esiste un modo per aggirare l'ostacolo con Drupal? Sì, allora, esatto, allora, le form e quindi tutto il pannello di amministrazione di Drupal e comunque HTML, i generatori in HTML, quindi del server-side, quindi per adesso niente React o altri sistemi.Hanno sviluppato però nel core di Drupal uno strato molto interessante interessante, che loro chiamano State API per le form, sia che vi ho fatto metà, metà in PHP e metà in JavaScript, non usa un framework alla React, ma sul frontend in JavaScript, che permette a chi definisce la form lato PHP di implementare degli eventi che poi succederanno sul client.Il tipico "scelgo la provincia e mi cambia la città piuttosto che riempi un campo a validazione remota e mi ritorna un cambio allo stato della form o mi fa comparire altri elementi di una forma seconda della risposta.Tutto questo è molto flessibile il Core di Drupal su questo punto.E la cosa interessante soprattutto per uno sviluppatore di back-end è che tutto funziona senza scrivere JavaScript.Quindi tutto fatto lato PHP, in cui viene descritto tutto l'interscambio di informazioni ad AJAX e quello che deve succedere sul front-end, e poi sul front-end questo layer JavaScript che sta nel core, magicamente rende tutto dinamico.C'è da dire che on top of that c'è un modulo contrib, si chiama conditional fields, che permette tramite UI fare tutte queste interazioni senza scrivere una linea di php quindi se la check box è flaggata mostrami questo gruppo di fields e cose varie lo fai tramite dei settings nella user interface senza scrivere una linea di codice.E tutta è tutta sta roba però queste configurazioni dove vanno sempre in config entity del caso? Sì esatto, nelle config entity del field.Me le devo immaginare come il campo meta di WordPress.Sono dei file YAML in realtà, che descrivono con una struttura molto ben determinata perché ogni modulo, ogni elemento del core definisce quali sono le sue configurazioni col suo schema.Quindi non sono campi buttati in un blob di testo, ma sono strutturati in YAML, quindi sono un'installazione standard di Drupal a centinaia di questi file YAML che descrivono ogni singola, un po' alla config di Symfony, descrivono ogni singola configurazione.E questa è stata un po' il grosso, la grossa innovazione del Drupal 8 in poi, quando Drupal è passato a Symfony, Sostanzialmente perché tutte queste configurazioni, oltre a essere standard, quindi ogni modulo sa come esportare configurazioni utilizzando questa struttura, essendo in file sono facilmente trasferibili via ghietta da un ambiente all'altro.Quindi io aggiungo un campo in locale, esporto le configurazioni, committo, faccio un deploy in stage, importo le configurazioni e stage diventa identico al mio ambiente locale come configurazione.Ricapitolando, tutte le configentity vanno a scriversi su questi YAML, invece le contententity vengono nel database.Se io oggi prendo e apro, perché è un gioco che faccio spesso con tanti CMS, dopo aver utilizzato WordPress e aver visto i campi meta, la prima cosa che mi viene in mente è prendo, guardo il database e dopo aver fatto dei magheggi sulla UI per costruire delle strutture dati più o meno complesse vado a vedere cosa ne ottengo.Perché questo? Questo perché mi sono reso conto che spesso l'elaborazione poi di dati che io sto salvando nel mio CMS fatta da strumenti terzi può essere più o meno facilitata da come i dati sono scritti all'interno.Se dovessi fare questa cosa con Drupal, riuscirei a capire a colpo d'occhio, questa è una domanda cattiva, come è strutturato il mio contenuto o rischiere di perdermi nei meandri di cose, di tabelle, relazioni e cose? Sì, ti perdi, più che altro perché per ogni field, ripeto, ci possono essere diverse tabelle, poi ogni tabella ha la sua funzione, il suo dato e come vengono messe in relazione, sono tutte informazioni che sono specifiche di quel field e quindi dipende dalla sua configurazione.Quindi non dico che è impossibile, perché anche noi lo facciamo spesso, quindi se dobbiamo andare a cercare dei dati nel DB comunque ci si arriva con un po' di esperienza.Però a primo occhio effettivamente può essere come dire overwhelming.Esatto, sicuramente il vantaggio è che tutte le tabelle, essendo generate da Drupal, tutte le tabelle dell'entità e dei campi dell'entità hanno tutta la stessa struttura.Quindi una volta che è chiaro come lui genera le tabelle, le colonne sono sempre le stesse, a parte quelle specifiche del campo, però le tabelle che mettono in relazione tutti i pezzi sono poi le stesse.Quindi è complicato perché come diceva Marco, un campo in Drupal sia revisionabile, quindi che si mantiene la storia dei cambiamenti passati, sia traducibile, crea quattro tabelle.È self-delettabile, è soft-delettabile, magari ne crea cinque.No, sono sempre quattro perché questo concetto in Drupal lo fai con la pubblicazione, pubblicazione, magari, però sì, quattro tabelle è il massimo del solito che puoi avere per singolo campo.Sì, no, e per campo diciamo non la primitiva, l'input field, ma campi un pochino più strutturati, giusto? No, anche il singolo, tu aggiungi al tuo articolo di prima, aggiungi una text field per inserire il nome dell'autore inventando un campo che crea le sue, se quell'articolo è revisionabile traducibile, le sue quattro tabelle sul database.Sì sono tante, le tabelle vengono tante, quello sicuramente.Ecco, io pensavo, sai, che fosse un po' tipo strappi, nel senso che se il campo è una primitiva, un big int, int, una data, una stringa, lui ti avrebbe aggiunto solo una colonna o...Era così fino a Drupal 7.In Drupal 7 i campi primitivi avessi aggiunto appunto esatto una stringa che avrebbe aggiunto una colonna alla tabella dell'entità, se non ricordo male.Drupal 8 no, crea una tabella specifica per tutto molto denormalizzata come struttura sul database.Ed esistono dei moduli invece che ti aiutano nell'esportazione dei dati con un formato human readable? I dati, nel senso quelli del database esportati, ci sono tanti modi sì sì sì assolutamente anche nel core stesso in realtà lo trovi si chiama VIEWS che è praticamente un query generator, quindi tramite interfaccia si riescono a creare le select con i field, i filtri, le joints, li chiama in altro modo, non li chiama così, però praticamente è quello.Quindi tu potenzialmente potresti creare una view per visualizzarla in html piuttosto che esportarlo in json o csv o qualsiasi altra cosa.Anzi la mia domanda sul trovare un modo per vedere i dati era proprio idiotica al chiedervi esistono delle API cioè io posso querare il contenuto perché diciamoci la verità prima di passare alla parte di front end lato utente oggi viviamo nell'epoca dei CMS Headless qualcosa in realtà è tutto un po Headless oggi Booking Engine Headless e e-commerce Headless CMS Headless chissà perché probabilmente tutti vogliono fare i frontender ma la mia domanda è esiste un modo per vedere e accedere a questi dati via API? Esiste un modo che permette a Drupal di essere usato in modalità headless? Assolutamente sì, d'accordo ci sono due modi, c'è il modulo REST che ti permette di esporre i tuoi dati, entità e quant'altro in delle REST endpoints JSON API, che è il formato più comune, più standard, quindi ti permette di esporre tutti i tuoi dati tramite JSON API.Poi ci sta un modulo Contrib, che ti permette di esporre i tuoi dati in GraphQL.Tutte e tre sono comunque customizzabili su molti livelli, quindi ci sono moduli Contrib intorno a questa roba qui per fare un po' di tutto, quindi si riesce assolutamente.Drupal si offre molto bene, in questa ottica, tutto headless, tutti i frontendisti, si lavora bene, si trova bene in questo ambiente.Esatto, questo se posso aggiungere, appunto per chi ha visto Drupal, magari la prima volta che si è trovato lì, Drupal 7 generava HTML e poi con qualche giro se non riuscivi a tirargli fuori via API e cose.Da Drupal 8 e soprattutto Drupal 9 si è invertito il meccanismo, quindi entrambi sono API first, quindi il primo output del CMS sono API e poi gli è stato costruito un frontend davanti per chi non vuole usare React ma Twig per farsi le pagine.Chiaro, perché la modalità normale e la modalità classic usa Twig.E invece per quanto riguarda la parte JavaScript, come la gestisce? cioè c'è un bundler out of the box mi viene in mente mix che troviamo su symphony mi sa che fosse la laravel forse mix, symphony usa webpack and core esatto sì da un po' che sono ha qualcosa del genere per la gestione minificazione compilazione del javascript o lascia tutto libero all'utente? no, tutta questa parte qui è fuori dal core di Drupal in Drupal esiste questo concetto di distribuzione la distribuzione è nient'altro che il core di Drupal più una selezione di moduli fatta da qualcuno e impacchettata, pronta per uno scopo specifico, tipo la distribuzione per gli e-commerce, la distribuzione...Due di queste distribuzioni, una schema contenta CMS, l'altra non me la ricordo, hanno fatto questo grosso lavoro, però sono fuori dal core, hanno fatto questo grosso lavoro di implementarsi due o tre reference, front-end reference di esempio, una in React, una in Angular, ne hanno fatte due o tre, sostanzialmente.C'è un grosso progetto adesso, è un'agenzia americana che ha fatto tutto questo front end di Next.js quindi per consumare l'API di Drupal e esporle come entità in Next.js e parte di il tuo front end e così, però sono tutte che arrivano dal community non fanno parte del core di Drupal.Ma c'è una decisione politica in merito? nel senso di dire ok il nostro boundary, il nostro confine sta qua, tutto quello che sta fuori lo lasciamo a non opinionato quindi non prendiamo delle posizioni oppure magari qualcosa legata più alla competenza del team core di Drupal che era più focused sulla parte magari PHP? No, allora sicuramente è più una questione storica, politica, diciamo così.Anzi, le prime versioni di Drupal avevano… il core faceva pochissime cose.Finché non installavi moduli con trib non ci facevi praticamente niente.Nelle ultime versioni di Drupal invece, se installi Drupal 9 o Drupal 10, comunque il tuo sito non troppo complicato, lo porti a casa senza installare nient'altro probabilmente.E c'è stata una grossa frizione della community che l'avrà aggiunto nel core più cose.Scusa Luca, puoi spegnere la webcam perché penso abbiamo un po' di problemi con la banda.Mi sentite? Adesso sì, meglio.Ok, va bene.Grazie.E quindi no, è stata più una scelta politica di come funziona lo sviluppo in Drupal.Quindi loro si sono concentrati a mantenere nel core la funzionalità, anche perché storicamente Drupal ha avuto come punto di riferimento dove a cui fare concorrenza WordPress, ovviamente per lo share di mercato che ha WordPress.Uno degli obiettivi di Drupal è restare solo Ubai funziona.Drupal 9 non resta solo Ubai perché non ce la fa.quindi da un lato sono stati molto orientati a "te lo installi e funziona, non devi fare nient'altro e quindi non ti complichiamo la vita magari a installare più cose".Anzi nell'ultima versione, dato il fatto che il PHP adesso ha il suo server interno potenzialmente con un paio di comandi tiri su il locale un'installazione di Drupal con già dei contenuti fatta finita vestita di esempio senza neanche installare o configurare una pagina.Esatto cose particolari.Ovviamente dall'altra parte loro puntano alla community, puntano a fare concorrenze invece a HMS Enterprise, Sitecore, Adobe e quindi sono un po' a metano tra questi due modi vogliono fare concorrenza a entrambi i livelli, il sitarell in wordpress e il portalone in adobe e quindi devono gestire un po' tutto.Certo è che però rimanendo con questi focus e guardandosi attorno probabilmente di spunti realtà che dal mio punto di vista almeno per la per la parte per la parte più più frontende potrebbe prendere perché sapete io non so forse anch'io sono su cube del mondo delle mode però e soprattutto sono un innamorato di react a livelli totali quindi per me non esiste altro.Però oggi, 2022, dover farmi un front end con twig ti può dire anche di no.Certo.Ma proprio avrei questa repulsione.E quindi non lo so.Fondamentalmente secondo me la parte che potrebbe in un sviluppo futuro prendere Drupal potrebbe essere quella di fare il replace di alcune tecnologie come Twig con la butola, un React server side rendered un pochino più potente, un JSX scusatemi, un pochino più potente di Twiggy in termini anche di espressività e al passo coi tempi.Non lo so, pensate che la storia di Drupal, quindi la lunga storia perché ormai quanti anni esiste? Parecchi no? Sono 20.È una ventina d'anni sì.Pensate che questa storia così grande, così così anche intensa, possa in qualche modo essere una sorta di piombo che un po' rallenta l'abbracciare nuovi approcci, nuove dinamiche, nuove tecnologie.Ma vai Marco.Non lo so, non ne sono sicuro perché comunque in tutto ciò, forse io sono troppo backhandista, differenza tua, che adori React, comunque sono ottime tecnologie, però diciamo dal dal punto di vista server side ci sono così tanti challenges ancora da affrontare che forse non è proprio la top priority adesso fornire le interfacce in React piuttosto che Angular o Vue o Next diciamo, no? Però non lo vedo come un piombo, perché comunque le iniziative sono sempre tante, sono sempre nuove, ci sono sempre cose nuove che vengono introdotte.Probabilmente ci sta già una iniziativa del genere, non ne sono a conoscenza nella community.Sì, allora le chiamano iniziative, la community di Drupal queste linee guida che si danno ogni anno dice "quest'anno lavoriamo su queste iniziative specifiche".Una di queste è il rifare il back-ending React.Ci stanno lavorando, è una delle cose...Forse, ovviamente, Drupal ha una community open source enorme, forse è una, si dice che sia una delle community open source più ampie.Ovviamente mettere d'accordo tutti è complicato, quindi bisogna anche cercare di trovare i compromessi per andare sempre più avanti e avere qualcosa di stabile.Sì, no, veramente la mia perplessità era, forse anche un po' naiva come domanda, ma avere il focus.L'avete detto prima anche voi, no? il guarda con un occhio i CMS Enterprise e a me è capitato di approcciarci alle volte nel mondo dell'editoria e cioè volevo morire dopo cinque minuti non dirò il nome del CMS ma era un vomito totale e dall'altra parte la famosa e storica competition con WordPress però tante cose in realtà con l'avvento dei CMS edless e dell'API first sono cambiate molto in questi ultimi tempi e quindi la mia perplessità era ok ma perché Drupal non diventa un modulo core che gestisce solo la parte back-end che fa solo la persistenza delle strutture date alla definizione degli schemi e poi un admin panel completamente separato con solo tecnologia front-end è un template base, buttiamola così, con solo tecnologia front-end, quindi proprio la la divisione delle responsabilità chiara, bella, definita però percepita dal suo esterno come un'entità unica, completa, che butti là dentro e funziona.Mi chiedo, questo tipo di soluzione sono io che guardo un po' troppo preso dalle mode e penso che Drupal si sia focalizzato nella competizione solo in questi due fronti o c'è questo tipo di cosa? Non lo so.chiaro, chiaro, è assolutamente lecito e soprattutto secondo me lato front end verso il cliente finale, avere qualcosa di più reattivo, comunque di facilmente sviluppabile con tecnologie front end ci sta assolutamente.Non la vedo tanto utile, poi probabilmente Anche lì, come diceva Marco, noi siamo più back-endisti che non avevamo questo grande vantaggio di avere un pannello di amministrazione fatto in Reactor e Reattivo, nel senso che alla fine quelle sono forme per inserire dei dati.Il fatto che già in gruppo si può fare drag and drop di cose qua e là, aggiungerci un altro livello di interazione sopra, non so quanto può essere...Non è che non si può fare, si può fare perché tecnicamente parlando è già fattibile questo, quindi ci sono già tutte le API per sviluppare tutta questa roba qua, però dal punto di vista dello sviluppatore noi utilizziamo la linea di comando proprio, cioè molta roba, non apriamo proprio la user interface, eseguiamo direttamente la linea di comando, quindi dal punto di vista dello sviluppatore non c'è vantaggio in questo, Dal punto di vista dell'utilizzatore del sito, chi è, se un amministratore, un editor, manager o quel che è, Drupal ha già tutte queste, offre già tante cose a livello di user experience da questo punto di vista.Sicuramente si può fare di più, sì, si possono introdurre, o su richiesta, non so se dal punto di vista della community avrebbe senso, perché comunque già vengono forniti depecchiando amministrativi, c'è modo per estenderli e tanta altra roba.Però, volendo, non è che siamo bloccati, tipo se viene un cliente e chiede questo, diciamo sì, chiaramente è fattibile, si può fare, non è un problema.È solo che non arriva dal core di Drupal tutto qua, bisogna metterci mano.chiaro? Chiaro, chiaro, chiaro.No, il mio più che un approccio frontendista era più legato alla separazione di con sé, no? Delle aree, dell'imitazione delle aree.Magari è una sovrastruttura che viene dalle tecnologie che utilizzo.domanda, altra domanda cattiva questa in realtà un po' l'avete citato avere una struttura dati così articolata con uno schema database così complesso può essere un problema a livello di performance e di lì la seconda domanda è come Drupal gestisce le performance perché mi è sembrato di leggere che è un po' un tallone da kill questo ma forse lo era una volta adesso in realtà siamo già da Drupal 8 ci sono state introduzioni molto interessanti dal punto di vista del del caching layer se possono influire sulle performance tutti questi field sì se non esiste un caching layer o se non è ottimizzato, se è impostato male o se qualche sviluppatore ha sviluppato pezzi di logica custom che in qualche modo spengono, bypassano il caching layer.Se il caching layer viene sfruttato in modo adeguato e ti posso assicurare già nativamente Drupal è molto performante già da Drupal 8, Drupal 9 anche di più, I problemi di performance sono, diciamo, secondari, non di basso livello, perché comunque si tiene sempre l'occhio alla performance, per qualche caso specifico.Però rispetto a Drupal 7, dove c'era solo il cache for anonymous user, quindi banalmente gli utenti anonimi avevano qualche tipo di caching, tutto ciò che era logato era una preghiera ogni volta per vedere se tutto reggeva, in Drupal 8 queste cose sono cambiate tantissimo.A livello di core, Drupal ha introdotto tre moduli nel core, più tutta la sua tecnologia per il caching.Ci sono il page cache, quindi la famosa Drupal for anonymous user di Drupal 7, il Dynamic Page Cache, che è soprattutto utilizzato per comunque gli utenti loggati, e BigPipe.Sono tre iniziative con moduli contrib che sono arrivati nel core di Drupal e tutti insieme aiutano tantissimo dal punto di vista delle performance.Questo ma non solo, perché questo è uno strato software, diciamo.Poi c'è il backend layer del cache, che potrebbe essere di base quello di Drupal, quindi tutta la cache viene generata e storata nel DB, ma è facilmente swappabile con qualcos'altro, potrebbe essere un Redis, un Elastic, un Memcache, o qualsiasi altra cosa serva in quel progetto, diciamo.Quindi in un modo o nell'altro la cache aiuta, la cache aiuta tantissimo.Esatto, forse una cosa interessante della cache da Drupal 8 in poi è che sia la cache che si è salvata a Drupal che eventualmente quella che poi a Valve finisce salvata in una CDN potenzialmente taggata con tutte le entità di cui parlavamo prima che sono state usate per costruirla con la cache e quindi è anche molto semplice invalidarla che poi il problema di quando hai una cache.E quindi Drupal è in grado, dal core stesso, sulla home page, di usare il nodo 27, perché era l'articolo in primo piano, e l'hai modificato.Drupal è in grado di riconoscere quali sono gli HTML che ha generato, che utilizzano il nodo 27 e invalidare solo quelle cache lì, senza dover ricostruire tutto.Si è passati da un time to live vecchio stampo più a un tagging di pezzi di cache.Quindi quello che viene invalidato persiste finché non viene invalidato.Sia per l'HTML che per le API, quindi le API usano lo stesso meccanismo.E invece è una cosa che sta andando tanto di modo a che lo static rendering, quindi la generazione di file html old play, il nuovo 94, il nuovo 92.Però ti dico che in alcuni casi a me è capitato di lavorare per un e-commerce che faceva tanti milioni di view, per noi era la soluzione veramente più semplice, almeno alcune pagine statiche, fare else e lo static side generation.C'è qualcosa del genere? Esiste, esiste un modulo, contrib non fa parte del core, che si chiama Totome, che Si si occupa proprio di fare questo, ad esempio è stato usato anche noi abbiamo usato in un progetto.Genera la versione statica del sito anche intelligentemente, quindi ovviamente rigenera solo le parti che sono cambiate, la generazione quella dopo, gestione di lingua e tutto quello che dovrebbe fare un generatore, un tipico generatore di HTML.Quindi anche lì ho sfruttato il modulo che si aggiunge e estende quello che fa il cordo senza necessità di dover modificare cose.Quindi è tutto molto da gameplay.Questo termine piacevo molto a 94.Sì, sa un po'.Adesso la sparo grossa giusto per farvi arrabbiare, per fare un po' di flain perché noi abbiamo "Ah, ci sarà la CMS Word" Ha un po' il flavor di plugin di WordPress Eh, no, beh alla fine il meccanismo è quello Poi se guardi lo spaghetti code di WordPress Però...WordPress era spaghetti code, spaghetti data, spaghetti tutto E' rimasto così E' rimasto un po' così e allora visto che abbiamo tirato in ballo wordpress una secondo me delle rivoluzioni di wordpress era il pulsante siccome wordpress parlava all'utente più che allo sviluppatore e questo ne siamo tutti consapevoli altrimenti non ci sarebbe stato poi il mercato di plug in o il mercato dei temi che credo che fosse uno dei mercati più redditi al mondo.Però Wordpress, io adesso sono tanti anni che non lo uso fortunatamente, però ricordo aveva un bel pulsantone quando usciva una nuova versione che era "L'Aggiorna".Questo era un modo per mettere una pezza alle tante versioni collaborato che uscivano da Wordpress e quindi mi chiedo il processo di updating di Drupal invece come funziona? Si basa sul package di Composer quindi Drupal stesso è un pacchetto e tutti i moduli contrib sono dei pacchetti, quindi tutta la parte di upgrade viene gestita tramite composer.Non viene fatto da interfaccia nel senso che ci sono i moduli, anche qui per fare gli aggiornamenti, hai le notifiche di aggiornamenti di sicurezza e quant'altro, però credo che la via ancora più scelta al momento sia quella di sfruttare il composer per pushare nuovi aggiornamenti.Scusami Luca.Scusa, anche perché, soprattutto sui siti in cui lavoriamo in Spark, un aggiornamento non andrà mai in produzione senza averlo testato prima, quindi avere il pulsante dove si farà comunque in stage l'aggiornamento per poi testare, quindi alla fine non è tutto questo vantaggio nell'aggiornamento automatico dovresti comunque far girare tutta la suite di test per verificare che tutto sia posto.Ma poi nell'ottica di cloud native diciamo per noi è fondamentale che la code base sia uguale per ogni istanza tirata su, quindi avere un'immagine docker che ha esattamente quella versione dell'applicativo con quel set pinnato di moduli e e quant'altro è fondamentale per noi perché se l'applicazione scala deve scalare automaticamente con la stessa codebase, non ci possiamo permettere sia partito un upgrade mentre scala e mezza roba in un modo e mezza nell'altro.Ma infatti la cosa simpatica è che quando io guardo Drupal io non lo guardo in un'ottica enterprise e quest'altra parte di mondo me lo perdo perché? perché vengo da quel pregiudizio da quel preconceto da quel wordpress vengo da quegli anni fondamentalmente che è il periodo in cui ho abbandonato questi strumenti dove avevo questo tipo di problematiche però da utente riconosco anche che se non lavoro in un ecosistema complicato come quello dove lavorate voi cioè il poter uploadare un file che contiene il modulo è tanta roba e vi dico sto pensando a un side project che dovrebbe fare qualcosa tipo quello che ha fatto Drupal, Wordpress per i CMS negli anni 90...quando è che hanno iniziato? 98, 97? Drupal è 2001 come data di...facciamo il 2001...però quegli anni lì comunque.In realtà una domanda che mi chiedevo è se io permetto la creazione di moduli esterni, l'installazione di questi moduli esterni, come mi conviene permetterla? Siccome il progetto sarebbe basato su Fastify che già si basa sul concetto di plugin, devo farli come moduli npm che si installano e con una sorta di autoloader oppure devo fare lo zip pozzo che si prende e si butta oppure devo supportare tutti e due perché in realtà sono due use case completamente diversi come avete evidenziato voi.Esatto allora in Drupal tu potrai allora per un certo numero di moduli potresti caricare lo zip sul tuo server e installi il modulo e hai finito.In realtà una certa fetta di moduli necessita di dipendenze a sua volta, che arrivano da pacchetti di composer, ad esempio, e ovviamente se scarichi lo zip del modulo dentro non c'è la dipendenza, per questioni di licenza ma anche solo di dimensioni e quindi poi sul server comunque composer dovresti lanciarlo per poter avere il pezzetto che ti manca.Quindi su qual funzioni chi ancora per quei moduli che non dipendono da niente sul modulo che hanno dipendenza devi passare da composer.Nel mondo di HP è comunque lo strumento principale, lo standard gestire l'installazione di qualsiasi cosa.E infatti mandiamo un abbraccio gigante a Giordi Boggiano che sappiamo che ci sta ascoltando.Mamma mia che personaggio, tanti tanti cuori per Giordi, è stato un amore di quando ancora utilizzavo PHP.Assolutamente.Una testa matta.Altra domanda interessante.Io so che Luca è anche il contributor di Drupal, giusto? Sì, esatto.Cittavamo prima a Jordi, quindi a Monologue, per esempio, che è un suo pacchetto PHP, io mi occupo del componente del modulo Drupal che espone Monologue come back-end di log in Drupal e quindi ti permette di loggare attraverso monologue, ad esempio.Drupal è community quindi e Drupal è open source.Quanto è attiva la community open source di Drupal e quanto è facile o difficile contribuire? Allora, la community è molto attiva.Una delle massime che circola è "Vieni per il Codi Terrestre e per la Community" perché comunque è molto inclusiva e sicuramente interessante partecipare alla community.Loro fanno due grosse conferenze, una in Nord America e una in Europa all'anno, e poi alcune conferenze minori organizzate dalle varie associazioni locali in cui ci si incontra e fanno pod sprint, è tutto molto interessante.Quindi contribuire a livello di altre persone, di supporto che puoi avere, è molto facile, è molto interessante.La contribuzione in sé non è semplicissima, nel senso che la community di Drupal ha da poco spostato su GitLab tutta la gestione dei progetti, ma la gestione degli issue è ancora su un loro meccanismo proprietario dentro Drupal.org.Quindi se si sta traghettando verso GitLab, siamo ancora a metà della traversata, quindi a volte devi creare un issue sull'interfaccia di Drupal.org e poi forkare i repository di GitLab e poi copiare e incollare e è ancora complesso.Un grosso lavoro che si sta facendo è quello di semplificare soprattutto perché si avvicina per la prima volta a Drupal a semplificare il contribuire una patch al core o ai moduli country durante le conferenze, l'ultima giornata, di solito c'è proprio una stanza per i contributori che vogliono sperimentare la community, quindi i mentor che aiutano tutti quanti a… A scegliere una issue, a seguono, esatto, ti seguono, ti aiutano, cercano di indirizzarti, comunque ti incoraggiano ad aprire una prima issue perché è divertente anche quello.Esatto, anche perché si va da issue di codice, documentazione, front end, qualsiasi cosa, quindi c'è spazio per tutti.Chiarissimo.E allora adesso visto che vedo che il tempo vola, vi faccio un'altra domanda alla quale mi piacerebbe rispondeste tutte e due.La domanda è per quale tipo di progetto potreste dire che Drupal è la best fit e per quale tipo di progetto vi sentireste di dire "no vabbè, fa una cosa, lascia stare".Vabbè allora vado io, comincio io.Sicuramente alcuni dei progetti su cui stiamo lavorando e sui quali Drupal ha dato il meglio di sé.Quindi a nostro avviso a scenso, probabilmente sono tutto il mondo delle università, pubblico e amministrazioni, l'industria, quindi c'è un grosso portale con un sacco di contenuti, un sacco di informazioni strutturate in maniera differente.Quindi diverse, immagino, università, contenuti per rappresentare corsi, piani di studio, attività formative, qualsiasi cosa.Quindi è molto comodo poterle modellare come strutturati differenti e poterle inserire con un'interfaccia web.Quindi le intranet, tutti questi paletti che manipolano contenuti molto strutturati, che magari hanno dei front end ben definiti e cose del genere.Ad esempio invece un caso in cui forse Drupal non è lo strumento ideale sono Web, anche perché con CMS e con tutto quello che riguarda il gestionale ovviamente è più difficile da mettere in piedi, così come dall'altra parte.Chi è abituato magari a creare una landing page, drag and drop, trascinare cose.Ci sono alcuni modi per farlo in Drupal, ma non è lo strumento ideale per costruire un'interfaccia molto complessa.Sono trascinando cose magari di qua e di là.chiaro, chiaro Marco invece? un po' di meno sulla stessa linea in realtà tutto ciò che è un po' più grosso e complesso come dice Luca che richiede tante customizzazioni tanti come dire, tante richieste specifiche del cliente è ottimo Drupal si presta bene a qualsiasi richiesta, anche la più strana mentre se bisogna fare delle piccole semplici pagine forse è meglio andare più sul semplice e non tirare su Drupal se è un attantum ogni tanto.Se è un attantum, poi magari alla fine deve diventare una cosa più di sistema che ogni 15 giorni deve essere fatta con lo stesso template e così colà, allora lì si potrebbe di nuovo risfruttare Drupal per generare quel tipo di pagina, però se una tantum molto piccola, molto semplice, diciamo all'amico della salumeria non gli farei un sito in drool, capito? >> DIMARZO ALBINATI All'amico della salumeria non gli farei il sito, tra l'altro.>> MICKAEL Non gli farei il sito, assolutamente, ma anche loro proporrei perché di solito ti chiamano, ti chiedono, allora gli amici.No no no vero vero, gli amici che brutta cosa.No è stato interessante scoprire Drupal e saperne l'evoluzione.In realtà tante cose stanno succedendo in questi punti fermi del software open source che ci sono da tanti anni.Basta pensare alla transizione di Magento verso un approccio più headless.Quindi è interessante seguire, capire e soprattutto identificare e saper differenziare gli use case.Avete detto una cosa importantissima che è quello di se devo fare una web application ci penso 3 4 5 10 volte prima di utilizzare Drupal perché perché il content magari il concetto su come è strutturato il content su Drupal non fitta perfettamente gli use case che ho io come diceva invece qualche tempo fa "Francesco se devo fare un cms sicuro non me lo scrivo in Aravello o in Javascript perché non io voglia" diciamoci la verità.Ma non ha senso oggigiorno reinventarsi la ruota quando ci sono già strumenti molto potenti e soprattutto open source? Si lo so però la possibilità di avere e qua e qua e qua arrivo io con la rabbia che mi contraddistingue.La possibilità di avere un back end con quattro click dove ti definisci le strutture dei dati da storare e con quello c'è un crude fatto è allettante anche per chi deve far sviluppare una web app e spesso è quello il il tranello nel quale si cade e su questa cosa ci sto pensando da un po' perché mi sono reso conto, lo dico sempre nelle puntate, che il 90% del software che andiamo a scrivere nelle nostre web app, non parlo precisamente di siti ma di web app è un crude ma cribbio, cioè io non ho voglia di fare un crude è sempre la stessa cosa, quindi se c'è Drupal che lo fa per me allora sposo Drupal, se c'è qualcosa altro che lo fa per me allora sposo quella soluzione e poi scopro però che Drupal in realtà si porta appresso una complessità che non sto utilizzando ma che comunque pago la pago in termini di performance, la pago in termini di di manutenibilità e quindi sono felice che abbiate evidenziato quel passaggio detto questo guardavo l'orologio siamo a un'ora e quindici minuti mamma il tempo vola e quindi è arrivato il momento tipico e topico dei nostri episodi che è il momento Paese dei Balucchi io so che voi ne eravate sprovvisti e questa chiacchiera non vi ha dato il tempo di andarlo a trovare ma siccome io sono veramente bastardo dentro io ve lo chiedo lo stesso quindi qual è la cosa la prima cosa che vi viene in mente è che vi vi vien da condividere con la nostra community Luca hai qualcosa? Così diamo tempo a Marco di pensarlo e conduco nel paese dei balocchi aaaah il paese dei balocchi e quindi io ok quindi io invece devo dirla sul brusco così ahahahahah vabbè se volete inizio io così per eh insomma spezzare un po' il ghiaccio vai vai allora allora intanto io devo ringraziare anche Spark Fabric ok quindi vi è mai capitato mi raccomando andate a vedere il sito andate a vedere quello che fanno e mando anche un abbraccio a tutti e so che a Sparkfabric siete presi benissimo dal cloud native no? E allora oggi volevo condividere un un balocco che è cdk8s che è una specie di cdk fatto da AWS.Che cosa fa cdk? Abbiamo fatto un episodio, andatevelo a cercare, ne ho parlato con Leo qualche tempo fa è semplicemente un modo per scrivere "infrastructure as a code" dentro architettura e dentro il provider AWS però hanno sviluppato questa specie di cloud development kit per kubernetes quindi si scrive codice typescript python e come risultato si hanno i bellissimi e tantissimi e lunghissimi file YAML di Kubernetes.Quindi buttateci un occhio perché in realtà non lo so io lo sento quasi lo sento più vicino all'ambito dev e mi ha incuriosito non l'ho provato non so se funziona bene quindi insomma declino qualunque tipo di responsabilità però ha catturato comunque la mia attenzione e pensavo fosse una cosa carina da condividere.Poi vediamo cosa Paolo dirà di questo.Proverà sicuramente.Oppure dirà "che schifo, devi scrivere i bellissimi file, gli ama la mano e soffrire mentre lo fai e non usare neanche helm".Bene allora mi è Ho tenuto in mente una cosa, intanto che parlavi, siamo ovviamente nel mondo Drupal e visto che magari per dare la possibilità a chi non ha mai utilizzato, mai sperimentato Drupal ma non ha voglia di mettersi lì a capire come si installa, come si scarica, come si tira su e quant'altro perché è solo provarlo, in realtà la community ha un sito, si chiama simplitest.me e un'interfaccia web, si può lanciare una sandbox con dentro o un Drupal uoto o questa distribuzione che loro chiamano Umami, che è un po' il Drupal out of the box, ma quello che fa Drupal già preconfigurato con un po' di cose.È un'istanza cloud che viene su e la si può utilizzare per provare un po' cosa può fare Drupal, come è fatto, lato ovviamente utente da interfaccia web, ma è interessante come progetto.Assolutamente sì, grazie mille.Marco ti è venuto in mente qualcosa? Io vorrei andare sul classico, ma molto classico, visto che abbiamo parlato di questa evoluzione di Drupal, Drupal 8 e Drupal 9, e l'adozione di molti design patterns, a me piacerebbe suggerire i design patterns della Gengo 4.è un classico dell'object oriented programming secondo me è un must da leggere almeno una volta nella vita eccolo c'è in tutte le librerie credo è un best seller altro che Harry Potter è una delle sacre bibbie degli sviluppatori Poi non ne usiamo neanche uno, quelli che usiamo li usiamo male però c'è in tutti i comodini.Aiuta tantissimo anche a leggere il codice, a capire quello che viene implementato in questi framework da Symfony al Corro e comunque ti aiuta anche ad applicare le best practices quando vai a sviluppare un nuovo progetto.vero, vero, è un libro interessantissimo e diventa sempre più interessante quando poi col passare degli anni che i capelli diventano più bianchi, che tu invecchi di più nell'industria, inizi anche a metterli in discussione, nel senso che le prendi come basi, ci fai l'esperienza sopra e poi capisci quando usarli o quando non usarli.Esattamente, esattamente non sono un diktat diciamo però li assimili, li fai tuoi.Esatto, quando entrano alla cassetta degli attrezzi tu ce li hai, se ti servono sono là.28 gradi e mezzo all'ombra Non ci ave più da 20 giorni E non c'è un aleto di vento Caldo, tanto caldo, quanta sete Ia, ia, ia Portaci da bere Uno shot di birra, ma presto Portaci da bere Uno shot di birra, ma presto Alcuno senza schiuma Scuro, chiara, ma che sia una birra Una birra, please! Oh, yes, sir! *musica* E' arrivato il momento di ringraziare chi supporta in modo attivo il nostro progetto Chi infatti, grazie a una donazione, ci invita ad a bere E fa si che Geetbar possa continuare ad andare avanti Perché si, vero è che Geetbar è gratuito Perché io e i nostri ospiti non riceviamo alcun compenso gratuiti non vuol dire che non abbiamo delle spese e questa settimana grazie a Marco Damiani e Enrico Bianchi abbiamo coperto le spese della settimana.Marco Damiani ci invita a 5 birra e Enrico una e Enrico ci lascia anche un messaggio scrivendo "sono tirchio non prendeteci gusto" e tanti cuori per Marco e di Enrico, grazie davvero per aver supportato in modo fattivo ed efficace il nostro il nostro podcast e anche grazie a voi che possiamo raggiungere le vostre orecchie.Quindi tiriamo su i calici, un pò di buona birra e brindiamo alla salute di Enrico e di Marco.Grazie! Ragazzi è stato un super super super piacere avervi qua a Github e bere una birra con voi, grazie di essere venuti.Grazie mille, grazie davvero è stato un piacere esserci, mi sono divertito.Grazie.Noi come solitamente diciamo, Gitbar da oggi è anche un po' casa vostra, quindi quando avete qualcosa di interessante, disruptiv, rivoluzionario dal mondo Drupal, mi raccomando veniteci a trovare, c'è sempre una birra fresca, venitecelo a raccontare e e soprattutto mandate un abbraccio a tutti la Spark Fabric, Paolo, Stefano, Claudio, Edo, tutti.Grazie, grazie a me.Veramente, grazie davvero.Salutate Anna Lisa che poi è quella che sotto ha organizzato tutto.E nulla, io credo che è arrivato il momento dei saluti.Io vi ringrazio nuovamente nome mia ma di tutta la community di GIT, non solo mia ma anche di tutta la community di GITBAR e nulla da qua è tutto alla prossima grazie ciao GITBAR il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e combrir repo, parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
