*musica* Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è me medesimo e l'ho scritto giusto ieri *musica* Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flake pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto, e dentro ce l'appella tutti i santi."C'è un bestemmio, guarda!" Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile se hai le risorse, tempo e budget illimitato.Siamo noi quelli che lei ha IVA regolamentata, ma hai visto questo nuovo modello che disegna gatti di funambuli? Quelli che il dipende e un esci gratis da prigione e quelli che la RAL...no vabbè fa già ridere così Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente ormai rassegnati che la definition of ready è solo una più illusione Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram ma meglio Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al GITBAR e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su GITBAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Ciao Leo com'è? Ciao, tutto bene? Volevo partire subito suggerendo a qualcuno di fare un corso in vendita a 797 euro su come si recupera dei git stash lasciati settimane fa, perché oggi ci ho lottato e sono riuscito a recuperare i blog e riscrivere sul mio main quello che ho fatto.È veramente un casino, l'help non mi ha aiutato.e suggerisco a tutti anche mentre siete a lavorare sul vostro progetto di fare git stash list e farvi venire un groppo in gola Sento odore di bruciato Fortunatamente è andata bene però quando ho detto "cazzo l'ho messo nel git stash" insomma ho rotto main ma insomma niente non siamo in produzione Va benissimo e siamo tutti felici.Vedo che, insomma, dopo la giornata di oggi hai proprio bisogno di una birra e questo è il motivo per cui ci hai raggiunti qua.Non sono uscito al bar apposta perché dovevo registrare, per cui...Però subito dopo l'episodio bisogna festeggiare il successo.No, no, no, durante.Ah, ecco.Non ti chiedo quindi come sei tutto a posto, come stai? No, no, tutto a posto.È solo che oggi ho pensato...Git viene usato, tutti si sentono abbastanza pro di Git, Git Flow, ok, Rebase, Squash, Merge, perfetto.E poi quando vai a vedere lo stash trovi sempre quella lista e poi quello che cerchi magari non è nemmeno il primo della lista e sai che è una pila, allora comincia a parlare strutture date, allora devo tirare fuori prima quelli prima.Io oggi non ci ho capito nulla e ad un certo punto ho dovuto andare di terminale e andare a vedere i diff dentro i Git Object.diciamo che ci sono tanti livelli di utilizzo di git e spesso molti di noi, me compreso, si fermano al livello super entry cioè commit, forse se proprio proprio ne abbiamo voglia un fix up ok? lo stash nel senso lo metto da parte ma me lo riuso subito, poco di più forse qualche merge incazzato, il cherry picking, ok? Ma poi, alla fine...Sì, già il cherry picking.Guarda, io mi sono scritto "git stash" qua davanti con una lavagnetta manuale, col pennarello qui davanti alla tastiera, per ricordarmi che c'è uno stash che devo tirare fuori, perché se no me ne dimentico, dico "ah, lo rifò" e ti viene quella cosa tipo "ma a me mi sembra di averlo già scritto, sto codice", ed è un git stash di due settimane prima quando hai dovuto fare il branch.Sull'utilizzo di di git, guarda, mi è venuta in mente una cosa che ho letto ma mille anni fa di uno che la usava tipo per nascondere le foto dell'amante della stessa directory, cioè ce l'aveva su un altro branch, quindi se la ragazza li controllava il computer non trovava nulla e switchava i branch.Sembra un'idea geniale.Esatto.Dovremmo implementare le memorie del telefono versionabili con il git, no? Si.Potrebbe essere interessante.intanto cominciamo a mettere git ovunque perché ho lavorato in aziende anche abbastanza rinomate dove non si usa e credo che sia più popolare di quello che noi pensiamo, il fatto che non si usi nemmeno un subversion.comunque tutto bene al di là di questo.qualche tempo fa quando facevo corsi andai in un'azienda e usavano Dropbox per versionare il codice e e con questo credo che possiamo chiudere l'episodio qua, è stato un piacere, alla prossima settimana ma invece no, dobbiamo ricordarvi i nostri contatti info@gitbar.it @brainrepo su Twitter e il nostro canale Telegram che trovate scrivendo Gitbar su Telegram, facile e veloce Nel frattempo sentite Lambda che urla e mia moglie che mi dice di abbassare le voci perché l'ho svegliata e questo è super figo ma detto questo io direi che è arrivato il momento di presentare l'ospite, l'ospite, l'oste.Devo capire bene di oggi.Sigletta.Wella, wella, ciao ragazzi.Che voce, l'ho già sentita da qualche parte.Ti dà delle vibes, ti dà qualche vibes? Sì, sì, sì, sì.bellissimo.Ma in realtà si fuma acchia.Ciao Mauro, ciao Leo.Si, qua anarchia completa come buon ghetto.Allora io mi sono portato la birra, visto che siete al bar.La mia turba.No, questa è la mi turba, perché questo è il birrificio Lami, così facciamo anche la sponsorizzazione.Questa puntata è sponsorizzata da birrificio Lami.Questa è la birra Lami.se la provi, l'ami.questa poi ne parliamo giu' poi è toscana, l'ami turba e che la mi smuove qualcosa esattamente toscana, bravo, esatto comunque sapete che il mio sogno per github quando si parlava di sponsor era avere github sponsorizzata da una nota a casa di birre? a forza! a forza! quello è lo sponsor perfetto di ogni podcast non filtrata magari esatto, quella era la mia idea devi provarci, devi insistere basta con queste vpn quando saremo abbastanza maturi da avere uno uno sponsor di quel calibro volentieri ma sì, ma sì perché si sa che gli sviluppatori sono mediamente astemi, tanto che il boulmer peak è qualcosa che nasce in un contesto di astemi.Meraviglioso, meraviglioso.Comunque...Sai che hanno fatto dei test anche su quella roba? No, davvero? Vabbè, ma ne parleremo in altri.Hanno fatto dei test sul Balmer Peak e hanno scoperto che non è vero.Ma sono passi molto belli.Io non lo so questa storia.Pensa a te, pensa a te.Non è vero.Pensa a te...Vabbè, hanno fatto test su una persona, però...Pensate che Balmer dice qualcosa di sensato.No, è ovvio.Comunque, detto questo io vi devo presentare l'ospite di oggi che, come ben sapete, conoscete.Abbiamo iniziato quel cazzeggio alle stelle proprio perché l'amicizia che ci lega a questo ospite è di lunga data.Avrete sicuramente ascoltato Continuous Delivery, Il Buongiorno di Edo o D'Aedo, non ricordo bene ma il buongiorno.Uno di quegli speaker e podcaster che ci hanno guidato per diversi anni e ci hanno accompagnato per diversi anni nonché compare di Fosdem, dei nostri bellissimi Fosdem.Esatto, con puntata epica al seguito.Esatto e con...devo ricordarvi di andare a vedere i primi minuti della parte della puntata che pubblicamo su Gitbar dove commentavi il microfono sporco della telecamera e quella parte della puntata è arrivata nel canale YouTube e nel feed del podcast.Però non siamo qua per parlare delle puntate, ma siamo qua per parlare di un topic che mi sta particolarmente a cuore e per farlo in realtà abbiamo oggi Edo in una veste nuova un po' desuetada come eravamo abituati a vederlo in realtà no non troppo perché lo vedevamo come come DevRel e è ancora un senior DevRel però questa volta lavora a Storyblock Storyblock è una piattaforma che si occupa di content management system potrei sbagliare no? e quindi oggi è Investe di esperto di CMS e andiamo a provare a ragionare su CMS e evoluzione del CMS, senso dell'headless CMS, proviamo a filosofare attorno al concetto di CMS e vediamo un po' dove dove ci porta.Però in realtà la puntata di oggi mi piacerebbe iniziarla con un off topic/follow up proprio oggi guardavo Linkedin e lo sto aprendo giusto adesso e il nostro amico Livio ha scritto un post su Linkedin che mi piacerebbe commentarlo con voi.Lui scrive "sono rimasto agganciato ad un'osservazione di Mauro che diceva che il sugo del discorso il fatto di avere così tanti framework non evita che le persone sappiano cosa c'è dentro.La mia risposta è di fatto un'altra domanda.Alle aziende interessa che i propri dipendenti sappiano cosa c'è dentro Angular o come funziona RxJS? La mia risposta è secondo me no.La diretta conseguenza di questo è che dovendo per forza approfondirlo fuori dal contesto lavorativo spesso le persone non approfondiscono ma non è solo la persona che ci perde ma anche l'azienda per il tempo necessario che serve per percorrere altri percorsi necessari a portare avanti le attività giornaliere non conoscendo i concetti che aiuterebbero ad affrontarli senza sforzo.Naturalmente non voglio fare tutta un'erba, un fascio ero curioso di sapere cosa ne pensavano e chi ha voglia di condividere la propria questa è un topic caldissimo e complicato avete un'opinione in merito? ma Mauro io ho un'opinione su tutto quindi basta che mi chiedi io inizio a parlare mi devi fermare te quindi partiamo subito da questo.Guarda su questo topic in particolare per me la cosa è molto semplice dipende da che tipo di professionista e sviluppatore vuoi essere te e se te ti accontenti di conoscere le cose in superficie, di usarle per quello che ti serve quella giornata, quello sprint, quel progetto in particolare, consegnare il tuo lavoro, andare a casa, passare al successivo e sei in un contesto che ti richiede solo questo, secondo me ti stai tu accontentando di questo, no? Quindi implicitamente stai dicendo che ti va bene così, non ti stai neanche lamentando di questo.Ci sono invece contesti dove l'andare oltre la superficie, approfondire il conoscere cosa c'è dentro che poi anche cosa c'è dentro è un po' ampia come definizione bisognerebbe approfondire però diciamo conoscere i internals o quantomeno i pattern ecco che stanno dietro che è una cosa che mi interessa molto anche questa approfondire comunque i pattern che stanno dietro i framework oppure le tecnologie che stanno al cuore di certi framework ecco approfondire quelli ti rende un professionista migliore e ti rende anche in grado di passare contesti migliori, contesti dove queste tue conoscenze sono apprezzate, non solo apprezzate, ma sono anche richieste.Perché vi assicuro che ci sono contesti in cui ti è chiesto di conoscere certi problemi interni, perché poi li devi risolvere, perché poi ti si presentano dei problemi e li risolvi soltanto se hai capito come funzionano all'interno alcuni framework, alcuni programmi, alcuni software, alcuni pattern.Quindi tutto ricade su di te, secondo me, in questo.Che tipo di sviluppatore vuoi essere? Vuoi essere lo sviluppatore che domani potrà essere sostituito da Cloud 4.5 o vuoi essere uno che riesce ad andare oltre e offrire un punto di vista molto senior sulle tecnologie, sui pattern da utilizzare che prenda in considerazione contesti, costi, benefici eccetera e proporre magari soluzioni nuove? Ecco questo secondo me sta un po' un po' a te.Quindi io dico a Livio, quelli che magari commenteranno questo post, pensate al tipo di sviluppatore che siete, a quale punto della vostra carriera siete e dove vorreste poi diventare, perché dipende fondamentalmente in questo momento, dipende da voi.Sì, secondo me Edo è arrivato nel punto dove volevo iniziare io, cioè forse diventa quasi obbligatorio o o necessario conoscere, nel senso, mettiamo che lavori in un'agenzia e prendi un progetto dove, prendono un progetto dove non c'è tutta questa conoscenza su, diciamo, Angular o quello che è, e alla fine ti ci devi scontrare.Magari te non lo conosci, cominci a studiarlo, cominci a fare le cose, poi quando cominci a vedere, non so, troppi rendering, cominci a cercare in giro e in quel momento diventi esperto.E non lo so, dovrebbe essere un percorso che viene naturale non per forza dal fatto che uno voglia impararlo, ma magari sono proprio delle richieste del cliente.Quindi secondo me ci si arriva a forza di lavorarci, per forza, non lo so, io stando sempre o sulla superficie, che poi la superficie può essere spessa a quanto ti pare, perché All'inizio conosci poco, poi cominci a conoscere tanto, ma quella rimane sempre la superficie, c'è sempre un livello sottostante.E a un certo punto, secondo me, ti incontri e cominci a, come si dice, allargare la tua comfort zone in quel framework.Però ci vuole la voglia di studiare, senza dire "no, non si può fare".Perché tanto quello che facciamo è risolvere problemi che qualcun altro sicuramente ha già fatto, se no i vari co-pilot eccetera sarebbero stupiti quanto noi.Io sono un po' pignonato e ho notato che entrambi avete preso, analizzato tutto dalla prospettiva dello sviluppatore e siccome Gitbar è il bar degli sviluppatori è giusto che abbiate fatto così.Però sapete io devo rompere i coglioni per forza quindi devo arrivare a rompere le carte.Ok facciamo un esperimento.Noi siamo l'azienda.Nella nostra azienda abbiamo solo bisogno di sviluppatori che approfondiscono ogni dettaglio e che diventano super frustrati quando devono fare per 70 volte il crudino della chiesa o devono fare cose stupide perché talvolta le cose stupide si devono fare.O abbiamo bisogno di un gradiente di competenze che va dai junior ai senior.Questo dipende molto dal tipo d'azienda che abbiamo davanti.Se abbiamo un'azienda di prodotto, prendiamo l'esempio un'azienda di prodotto, ci sono delle cose super noiose tipo fixare il one pixel fuori posto che il grafico ci dice "no guarda questo bordo è troppo arrotondato, troppo poco abbiamo bisogno di sviluppatori che facciano questo abbiamo bisogno però talvolta potremmo aver bisogno di sviluppatori esterni che sviluppatori schillati non esterni scusate schillati che si vanno a guardare i flame graph e vanno a vedere dove è il problema o che si vanno a guardare quanti rendering sta facendo la pagina un certo cambiamento no se parliamo di front end giusto per fare un esempio di scendere o che si vanno a guardare come dicevamo la precedente puntata l'event loop utilization.Adesso dal punto di vista dell'azienda il discorso è molto semplice.Quanto spesso io da imprenditore cosa farei specialmente di una piccola media azienda mi chiederei quanto spesso questi edge case problem mi vengono al pettine? Quanto spesso questi challenge di natura tecnica arrivano a rompermi le scatole a una delivery.Guardando questa questa questa questa presenza di problemi io riesco a tarare perfettamente il mio team.Quindi capisco quanta seniority ho bisogno e posso mettere nella bilancia il famoso trade off di avere dipendenti junior senior e magari qualche consulenza ad alto livello che mi spacca l'event loop ok? se però l'event loop si spacca troppo ok a quel punto devo tirare sulle skill tenendo sempre la bilancia del profit cost attiva ok? per cui ci sarà secondo me nonostante le I.D.turno ci sarà bisogno sempre dei junior che utilizzano le I.D.turno per metterle insieme, che capiscano cosa un PO vuole chiedere, perché il PO non si capisce manco se stesso, immaginate se riesce a spiegarlo a un'intelligenza artificiale, spero non ci sia nessun PO all'ascolto, però in realtà salutiamo tutti i PO, tutti tutti, però però in realtà abbiamo questo tipo di problemi, quindi questo se lo vediamo dall'azienda, i junior servono, due, una cosa che ho imparato, specie lavorando in quest'ultimo periodo in grandi corporation è che c'è l'insieme degli sviluppatori e poi c'è l'insieme, il sotto insieme degli sviluppatori appassionati e degli sviluppatori per lavoro.Non è sbagliato essere uno sviluppatore per lavoro, cioè timbrare il cartellino, fare il dipendente delle poste, fare proprio lo stesso approccio no? Io vado a casa faccio il mio lavoro, vado a lavoro faccio il mio lavoro meccanico, me ne torno in casa e poi magari sono bravissimo allevando pesci o un costruttore di orologi presissimo bene.Io ho degli amici sviluppatori che fanno il loro lavoro ma non vogliono sentire di programmazione quando tornano a casa però nel frattempo montano e costruiscono orologi e lo fanno in maniera eccelsa.Ok? Noi siamo un sotto insieme quindi tutto quello che voi due avete detto va benissimo perché qua in Gitbar siamo e stiamo parlando di quel sottinsieme ma il landscape è molto più ampio quindi alle aziende interessano dipendenti super schillati sì se la bilancia di costo guadagno si equilibra al dipendente interessa e dipende da come il dipendente vede il proprio lavoro quindi fondamentalmente tutta sta pappardella per dire dipende.Ma perché per un programmatore dovrebbe essere diverso per qualsiasi altro lavoro? Non so, ritrauto? Quello che voglio dire è esattamente quello, cioè c'è il geometra che fa frazionamenti o accattastamenti tutta la vita e poi c'è il geometra o l'architetto che si prende quel lavoro challenging di design architetturale super complesso, ma sta nell'architetto e sta nel contesto dove lavora ed entrambi si scelgono no? Almeno noi abbiamo grosso modo la fortuna di avere ancora un mercato che nonostante la flessione regge e possiamo cambiare lavoro.Sì però attenzione che il mercato può cambiare anche rapidamente come abbiamo visto e la skill migliore sarà quella di essere insostituibili perché se tu sei sostituibile ecco che allora il tuo lavoro non sarà più così al riparo come pensi che sia oggi visto il mercato perché poi il mercato cambia quindi per questo per questo che dicevo state state nel senso che certo per me ci sta benissimo che tu faccia il programmatore operaio che a fine giornata non pensi neanche minimamente a quello che hai fatto e riprenderà giorno dopo va benissimo certamente però attenzione che queste sono le figure che quando ci sono cambiamenti di mercato cambiamenti tecnologici non solo le IA, ma anche l'arrivo dei programmatori nuovi che propongono prezzi più bassi, eccetera, lo vediamo, no? Ecco, quella roba lì poi fa sì che il tuo posto non sia più tanto al riparo e per metterti al riparo l'unica cosa che puoi fare è offrire qualcosa che non possa essere sostituito da qualcun altro o da qualcosa altro.Ecco perché non vedo di più andare a analizzare il programma dal punto di vista del suo sviluppatore, perché secondo me, Mauro, dal punto di vista dell'azienda quello che alla fine conta è quanto paga, perché se tu sei un programmatore senior, junior, pro o 'sti cazzi, poi alla fine quello che l'azienda conta è quanto pago per te e quanto mi torna da quello che tu mi fai.Non mi frega niente se poi tu la sera studi o no, che cazzi tu hai, però io ti devo pagare, mi deve arrivare un valore da questo, se ti pago meno sono più felice, l'azienda è più felice se ti paga meno, se ti paga meno avendo di più tanto meglio, cioè quindi è sempre un discorso economicoli.Da quel punto di vista io sono d'accordo a metà con te, nel senso che d'accordo con quello che hai detto tranne che con la parte iniziale del insostituibile, perché dipende da quanto sei ancorato al concetto del programmatore.Io ricordo 15 anni fa, tutti erano programmatori, 20 anni fa, 15-20 anni fa, tutti erano programmatori jumla, tutti, anche il tabaccaio era un programmatore jumla poi però è cambiato un po si è passati a wordpress e tutti facevano siti wordpress e poi si è passato e il lavoro si è evoluto e tutti sono diventati social media manager adesso questo questa evoluzione io non dico che chi fa il programmatore oggi senza passione e non vuole approfondire poi sarà sulla strada secondo me ci sarà un'evoluzione anche di quel livello junior.Nel senso mi viene in mente per esempio servirà qualcuno che guida i prompt, servirà qualcuno, i prompt naturalmente per cose semplici, servirà qualcuno che gestisce i low code.Ma che sono tutti strumenti fatti apposta per non essere gestiti eh, peraltro voglio...Eh, sì, fai qualcosa con un low code e guarda il tempo che ti brucia e guarda l'effort che ci metti.Ma sì, ma sono comunque tutte pensate per essere facilmente gestibili, quindi si andrà in una direzione di renderli sempre più facili, non sempre più difficili, no? Quindi il bisogno di avere qualcuno che gestisce sarà calante, non crescente.C'è il disaccopiamento dal codice.La tendenza è quella del disaccopiare tutto dal codice.Sul complesso e facile parliamone, perché se tu sei un individuo che fa qualcosa per a quel punto può essere facile farti qualcosa con un low code ma se sei un enterprise che fa qualcosa per te io il manager facendosi le dashboard non l'ho mai visto il manager si prende un cazzo di data viz che trascina blocchetti qui e là nella dashboard della situazione semplice o complessa che sia che è un un low code che non ha code quindi non si deve più programmare con D3 i vari grafici quello che si faceva prima e facevamo noi prima dieci anni fa ok? Non lo deve fare trascina blocchetti qui e là ridimensiona così ed è una cosa che si può fare l'utente finale ma quell'utente finale in un contesto più ampio è una figura professionale.Ecco questo voglio dire quindi...Si però non è un programmatore quello che voglio dire.Eh va beh ma scusa se tu lo fai per lavoro e lo fai senza passione, o per te è solo un lavoro, che tu scrivi codice o che trascini i blocchetti qui e là, non ti cambia un cazzo.Insomma non sono così d'accordo.Se lo fai solo per lavoro non ti cambia un cazzo, se lo fai per passione a quel punto sì ti incazza.Però il livello di complessità che tu devi superare per essere proficiente in quello che fai è un po' diverso secondo me.Il low code è pensato per essere accessibile, quindi la barra d'ingresso è bassa.La programmazione in un certo senso è pensata per essere accessibile perché è un livello di astrazione, va bene.Però l'avanzamento tecnologico della programmazione non crea linguaggi e programmazioni più semplici da usare, crea miglioramenti in altri ambiti.Il miglioramento del low-code crea tool low-code più semplici da usare.Questo che voglio dire, capisci? Cioè, se tu guardi l'avanzamento in futuro di low-code e AI come interfaccia, allora la traiettoria è quello di renderli sempre più facili da usare, di abbassare sempre di più la barra.Se tu vedi l'avanzamento dei linguaggi di programmazione, dei framework, del cloud, eccetera, non mi pare che stia andando in quella direzione.in realizzazione di creare pattern nuovi, di sfruttare meglio alcune risorse, di far pagare di più gli utenti, ma questo lo diremo in un altro momento, ma comunque sta avanzando tecnologicamente per essere usato da chi conosce lo strumento.Il linguaggio di programmazione non credo che abbia alcune intenzioni di rendersi il più accessibile possibile, a parte i linguaggi didattici non credo che ci siano linguaggi che nascono con questo intento, no? Per cui vedo le due cose molto diverse secondo il mio punto di vista.Secondo me sai l'unica paura che si può avere è la retention nel lavoro nel senso che il mercato sia ampia e chiunque può entrare però comunque quando parliamo di semplificazione dei tool non stiamo parlando di rimozione di categorie professionali ma di trasformazione di categorie professionali quindi secondo me ancora c'è della posizione però il mercato si...l'offerta di lavoro si ampia e quindi c'è un rischio da quel punto di vista ma secondo me qualcuno che fa il lavoro sporco ci sarà sempre qualcuno che fa il lavoro sporco a pagamento che sia configurare retool ok che sia configurare retool o che sia fare qualunque altra cosa qualcuno lo deve pur fare però magari ieri se ne servivano 5 oggi se ne servono due non è che rimane sempre quella la massa di programmatori a cui ti serve attingere.ma quanti programmatori super skillati ti servono? tutti i programmatori che hai oggi? quello dipende dal tuo progetto, dal tuo progetto, dalla tua azienda, dalla tua visibilità futura non lo so, secondo me c'è ancora spazio.io direi che possiamo cambiare i topic e potremmo rimanere a parlare altri.a me era venuta in mente una cosa 20 anni fa uno faceva il programmatore e io insomma quando iniziavo, non 20 anni fa che faccio all'università, ma insomma faccio il programmatore, cosa è? Web.Ora siamo front-end e back-end, cioè le cose specializzano e ci sono molte più persone che lavorano.Quindi secondo me non sul fatto che ci sia, come diceva Edo, avevi cinque persone su quello, ora te ne servono due.Sì, quell'altra te però fanno qualcos'altro su un altro ambito.Ti vedo molto ottimista su questo, non sarei così ottimista io.Io lo spero tantissimo.non ne sarei così certo.certo molti si trasformano magari crescono ma non tutti crescono.non hanno intenzione di crescere.magari smettono e si mettono a fare altro.io noto che spesso noi che siamo dentro la categoria ci sentiamo un po' sto cazzo.nel senso si può smettere tranquillamente di aprire un ristorante.se a me mi casca un'eredità da 2 milioni io non so se continuo a programmare.Magari aprono un B&B pur piacendomi la programmazione.A me sembra che per ora ci sia ancora spazio per tutti e spazio di crescita.Lo vediamo molto dalla nostra nicchia, dalla storia.A me per esempio l'AI non fa paura, io non ho mai usato Copilot e magari se vedete i miei progetti open source sicuramente me ne accorgete.Non lo so, non è una cosa che mi ha mai attirato e magari te lo posso stare senza lavoro, però non posso forzarmi a fare una cosa che non preferisco fare qualcos'altro.Un altro pensiero che mi era venuto in mente, poi apriamo mille parentesi, ma un programmatore junior che conosce non so 20 linguaggi, comunque junior o… come fai a essere junior se conosci 20 linguaggi? si conosce 20 linguaggi, usa, usa e conosce.ma ce ne saranno 20 in tutto il mondo? come fai a conoscerli tutti? appunto se ne conosce tutti, cioè che sa scrivere… ma può essere una risorsa versatile che nel momento in cui esce… ora dico i linguaggi, potrebbe essere una tecnologia… ma questo dopo una settimana già conosciuto su superficie può essere più o meno dipendente.bisognerebbe capirsi cosa vuol dire conoscere allora.sì certo.Intendevo sulla superficie, come dicevo prima.Conoscere la superficie di tante cose può essere un vantaggio, una diversità, può essere una cosa per l'imprenditore.Non dico che deve essere così, me lo sono chiesto.Quando io sono uscito dall'università, quindi tre anni di università, sapevo, conoscevo, adesso poi dovresti definire conoscere, ma conoscevo Java, C, C++, Scheme, javascript, jp, html, css, siamo a 8.Matlab.Forse qualcun altro.Però non voglio dire niente, perché conoscere a quel livello lì non è che sia proprio utile a livello professionale.Sì, ti è utile per capire dove vuoi andare, ma...puoi dire proprio un d.Guarda, io invece, quando avevo l'azienda, avere una persona così che non conosceva niente e faceva tutto, aveva senso.Puoi dipendere dalla persona.E' il famoso cugino, no? Che bene o male ti ripara il cancello col fil di ferro, ok, però il cancello rimane in piedi, rischia di caverti sui piedi e farti male, però rimane in piedi per due o tre giorni e quella cosa ti salva il culo in condizioni limite.Secondo me sapete che se tu hai una struttura capace di supportarti tecnicamente poi il dopo, avere una persona che ti arraffazzona qualcosa rapida rapida e che non ti rompe i coglioni perché il codice è sporco, all'imprenditore fa comodo, poi quella cosa non va avanti per più di cinque giorni, però quei tre giorni ti ha aiutato a prendere tempo per fare in modo che gli altri sviluppatori bravi potessero mettersi a fare le cose in grazia di Dio.Nel contesto della piccolissima impresa se c'è un supporto di qualche sviluppatore bravo secondo me torna utile.Cioè non voglio essere il classico a dire "No servono solo sviluppatori bravi dobbiamo sempre fare il codice bello pulito, disaccoppiato, testato".Cazzo io sono andato in produzione e non avevo un test e ci ho fatto i soldi senza i test.E cazzo no diciamolo! Perché va bene.Ma sì ma dipende dal contesto.Metterci la giacca di "ah che fighe che siamo, tdd, uncle bob".Va bene, tutto perfetto, abbiamo ragione, però nella vita reale esiste.Il best case scenario è il worst case scenario e talvolta nel worst case scenario tu c'hai dieci dipendenti e a fine mese devi pagare lo stipendio e lo stipendio talvolta viene sbloccato da codice senza test anche se poi magari ti metti a rischio lo stipendio dei prossimi dieci mesi ok però intanto tu quel mese te lo sei portato a casa e hai preso il tempo per fare i test.Ma sì ma dipende dalla complessità dei problemi che affronti perché voglio vederti se devi debuggare una cosa che non hai idea il manco di dove sbatta la testa io voglio vedere se non conosci cosa stai guardando, che cose ci stai leggendo, voglio vedere come fai.Ti va da culo? Se ti va da culo allora c'è un compaccio di tutti.Sì, è come avere l'operaio tutto a fare che magari lo fai lavorare, non so, alla seconda casa al mare che ci va una settimana l'anno, ma in casa tua vuoi qualcosa con gli uomini.C'è un problema, magari smartella due volte "ah l'ho trovato" e farà "genio, totale" ma è andata di culo.Però se lo chiami per una cosa io non mi farei.te secondo te anche i senior non smartellano quella talvolta quando debuggano? Ma sì, ma per carità certo.Ma però dipende dal contesto.Ripeto, se tu hai davanti un software complesso e devi capire come mai qualcosa non funziona, sei quella roba che non hai la minima idea di dove partire.Puoi anche essere veramente molto molto bravo e intelligente a capire i riferimenti logici, ma se quella roba non la sai, non la sai, te la devi studiare.Allora nel team ti metti uno schillato, un paio schillati e ti tieni comunque quelli i junior che ti lavorano a cambiare colore i bottoni magari usando cloud o coppailo.Certo, che sono che sono quelli che fra un po' verranno sostituiti da un AI o da qualcuno che costa meno.Se tu guardi quanto mi rompo i coglioni a scrivere i prompt secondo me è quasi meglio avere un junior.Ma perché tu oggi sei così, oggi sei pessimista.Oggi sei tutti...non dovete sapere un cazzo, oggi tanto usate il low code, chi se ne frega.Io sono ottimista, se tu sei il pessimista vi perdete tutto il lavoro.No, sbagli.Io invece sono ottimista perché dico se noi siamo bravi noi non verremo sostituiti da dei robot.Tu invece no, invece pensi che vabbè tanto, che ci può.Sì sì sì.È bello, vedi, quando cedo così è bello perché la pensiamo sempre, siamo sempre d'accordo a metà.E questo è fantastico.Perché sennò che noia.No, però adesso parliamo del topic del giorno.Perché ne abbiamo già fatto 36 minuti, potremmo continuare a oltranza sul topic.Bellissimo.Prima c'era PHP Nuke.c'è stato Joomla, Wordpress, Drupal e poi sono apparsi nel mercato gli headless CMS è simpatico perché in realtà era ancora l'epoca di Wordpress quando io lavoravo nella mia azienda in Sardegna per una soluzione che stavamo progettando insieme a un paio di amici che abbraccio, abbiamo sentito l'esigenza di disaccoppiare la parte di rendering, la parte di UI dalla parte di contenuto.Stiamo parlando di EBO 2009-2010 e ancora non si parlava di headless CMS, no? Eravamo venuti fuori con questo concetto di CMS UI agnostic, no? Fondamentalmente un cazzo di database però la cosa la cosa la cosa figa era che in realtà noi potevamo definire gli schema automaticamente si componevano dei form con gli schema che l'utente definiva e venivano esportati i dati venivano esposti per essere consumati da template modulari che avevano un corrispettivo per ogni quello che oggi chiameremo component avevano un corrispettivo UI scritto in php no? E poi corsi di corsi storici sono, mi sono trovato davanti agli headless CMS, me ne sono innamorato proprio del concetto e ho notato quanto in realtà possa essere un concetto interessante il disaccopiare l'informazione dal come è rappresentata, anche se poi la rappresentazione ritorna a doppio filo con le ultime generazioni di headless CMS, che hanno degli editor visuali e quindi che alla fine non so più se sono veramente headless o cosa siano.A questo punto mi chiedo e vi chiedo Secondo voi come vedete l'evoluzione dei CMS negli ultimi vent'anni? Voi che comunque siete vecchietti come me e avete visto un po' del protrarcici Vedete come qualcosa ha pensato proprio sull'idea di disaccoppiare l'informazione o come qualcosa ancora molto UI driven? Vado io Leo o vai te? Vado io, ti vedo mutato Allora, guarda...Sì, vuolo dirti vai te.Guarda, parto subito da un concetto molto semplice.Headless CMS è una definizione, è un'etichetta, e come tale, come tutte quelle che noi appoppiamo in informatica, non significa un cazzo.Cioè, non vuol dire niente.Come noi parliamo di back-end, front-end, full-stack, non vogliono dire niente.Sono così, etichette.Ci piace mettere etichette sulle cose, ma non significa niente.Il discorso di disaccoppiare il contenuto dal rendering, rendering, ma l'abbiamo sempre fatto, grazie al cazzo che ti raccoppi il contenuto del rendering, cosa fai? Metti il template dentro il dato? Un po' complicato.No, è sempre stato così, fin dai tempi, addirittura se tu ti ricordi il mitologico periodo in cui si facevano XML e XSLT per stilizzare quella roba, cos'era quella roba lì? Non era altro che un dato da una parte e il rendering dall'altra, cioè il concetto di spostare, cioè di avere il templating, quindi il tema, quindi la UI e quindi l'ad da una parte e il contenuto da un'altra c'è sempre stato.Poi a livello tecnologico, quando non eravamo ancora nell'epoca XML, HTTP request, visto che stiamo parlando di cose vetuste, è chiaro che il rendering veniva eseguito tutto nel server dove c'era il contenuto, quindi era opportuno creare un qualcosa di monolitico che facesse tutta la fase, sia di fetch nel contenuto che di rendering della UI, che poi sparava al browser.Quando poi la tecnologia è evoluta e siamo diventati invece in grado di spostare la fase di rendering sul browser e qualcuno ha detto "sai che renderizzare sul browser mi sembra un'ottima idea" poi in realtà si è cambiata opinione quasi subito, però sembrava un'ottima idea no? Perché così il lavoro computazionale te lo fai te, che c'hai il browser, che c'hai il pc potente, invece me lo togli da me, dal server e quindi spostiamo.Come facciamo a spostare beh dobbiamo creare qualcosa che prenda il dato grezzo ci applichi sopra dei template e faccia un po di stile quindi creiamo dei framework front-end bla bla bla bla quindi poi si è tornati indietro se vedi perché poi adesso siamo tornati server components e quindi corsi e ricorsi no però fondamentalmente è sempre stato un problema di dove mettiamo la roba cosa ci fa più comodo cos'è opportuno e più economico fare e quindi sempre a riguardo allo stack tecnologico.Ma adesso li chiamiamo headless semplicemente perché neanche manco ci pensano più i CMS headless alla parte di UI, di rendering, di templating.Cioè proprio ti danno, ti forniscono, questo per dare una definizione di CMS headless, se proprio ci vuol definire, ti fornisce il dato grezzo come te lo fornisce con un API tipicamente, un API REST o un API, ne so, GraphQL o qualunque altra JSON API, qualunque altre API si possono inventare.Ti fornisce il dato, poi come te lo manipoli sono fatti tuoi.Potrebbe anche essere che non te lo manipoli in JavaScript, è possibile anche essere che te lo pigli e te lo fai in PHP o te lo fai in Go, te lo fai con un'altra lingua, te lo fai server-side.Rimani sempre nel discorso di tu mi dai il dato, io me lo mastico, me lo renderizzo, me lo stilizzo e poi lo salvo al browser.Però ecco, volevo dire questo che l'etichetta è giusto così per farsi capire ma non vuol dire niente.Sì, sì, è una cosa tipo di marketing, un nuovo nome per una tecnologia che poi è sempre stata la stessa perché i database ci sono sempre stati, come dicevi te.Ok, renderizziamo sul browser perché ora abbiamo fitch veloci, però poi probabilmente l'aspettativa degli utenti è che ora la pagina si deve caricare in 100 millisecondi.Se il browser non ce la fa più, allora torniamo Poi torniamo sul server, perché in realtà i server sono un po' più potenti del browser, allora facciamolo fare a loro.Quindi un po' questa rincorsa per avere...Cioè, prima non era un problema, prima, 15 anni fa, che una pagina si caricasse in 3 secondi, 5 secondi.Era una roba che se avete ledge, se andate in montagna col telefono, aspettate 5 secondi per una pagina.Non potete fare altro perché non c'è segnale, però sentite che vi scoccia.Prima era normalissimo.quindi fondamentalmente sono d'accordo con Edo che l'ha spiegato molto bene, molto nel dettaglio.Quindi il discorso secondo me non è tanto tecnologico, perché su quello secondo me è abbastanza assodato e il discorso più interessante invece è quello della logica di business, cioè se tu hai un prodotto, adesso io lavoro in Storyblock quindi ti parlo di Storyblock, però ci sono tanti prodotti simili.C'è un prodotto che si prende cura del tuo dato, te lo gestisce, ti assicura l'integrità, lo scaling orizzontale, la security, il management di permessi d'accesso, di organizzazioni in cartelle, anche visual editing, ma questo poi diventa secondario.Ecco, se il tuo dato, che poi è il tuo valore di business, è da qualche parte che se ne prende cura e te lo offre in un modo modo che poi per i tuoi sviluppatori o per qualcun altro diventa facile fruirne, lì sta il valore come prodotto, no? Allora tu sei incentivato a comprare un prodotto del genere perché ti abilita a svilupparci sopra delle cose interessanti.Cosa che magari con un CMS invece monolitico puoi sempre fare, però hai più difficoltà, ma non difficoltà tanto tecnologiche, quanto a livello di offerta proprio di prodotto sul mercato, perché tu oggi non vedi un'offerta di "ti teniamo il dato poi ci fai quello che vuoi" con CMS monolitico, lo vedi con CMS headless perché hanno una serie di vantaggi da questo punto di vista.Quindi il vero vantaggio dell'headless è nel business, è nell'avere, nell'occuparti soltanto della parte meno diciamo sensibile, quello che ti puoi giocare meglio, ti puoi giostrare, sei più flessibile, puoi costruire tante UI diverse, tanti front-end, puoi andare sul mobile, puoi andare dove ti pare, ma il dato rimane sempre là, sempre se ne occupa qualcuno, non devi preoccuparti di fare migrazioni, non devi preoccuparti di replicarlo, di controllare gli accessi, non ti interessa niente, lascia che se ne occupi qualcuno che sa come fare e tu occupati della parte invece che ti dà magari più visibilità, nella parte visiva, grafica, quello, quello è interessante.Io ho una domanda e mi chiedo dove secondo voi finisce la responsabilità di quello che etichettiamo magari erroneamente headless CMS e dove inizia la responsabilità di un concetto un po' più ampio che possiamo chiamarla data management app o qualunque cosa vogliate nel senso mi è capitato nella mia esperienza di lavorare e di utilizzare headless CMS posso fare alcuni nomi directus, strapi ok questi sono prevalentemente open source e in alcuni contesti si porta all'estremo l'utilizzo di questo headless CMS utilizzandolo come interfaccia d'accesso per una data platform perché buona parte degli headless CMS espongono degli api per consumare i dati che possano essere GraphQL o REST e molti di loro hanno delle interfacce abbastanza carine per gestire i dati, hanno un decente sistema di diritti d'accesso, per esempio posso parlare di Directus, no? Directus ha un ottimo sistema di gestione di diritti d'accesso con un rule engine molto bellino e mia esperienza personale io ho iniziato a utilizzare direct us come cms e ci ho finita a fare il back office di un'applicazione di booking applicazione complessa quindi è questa cosa la sto vedendo in giro fatta molto spesso ok secondo voi dove finisce se esiste un boundary no per il il CMS è quando diventa qualcos'altro e secondo voi è prendere dai capelli e strecciare il concetto di CMS con relativi dischi o non vedete questa distinzione tra contenuto e dati strutturati, dato generico? Bisognebbe un po' vedere il caso specifico e capire, ma anche lì secondo me sono sempre etichette no? C'è contenuto, che cos'è il contenuto, cos'è il dato, non lo so qua mi sembra che la cosa importante sia sempre l'astrazione, cioè allontanare il cliente, l'utente eccetera dalle beghe di dover gestire davvero le problematiche che danno i dati quindi dove gli stori, gli accessi, la replica, il backup, la ridondanza che è la stessa cosa di replica, lo scaling, queste robe qua, il gdpr, queste cose qua.Poi che tu lo faccia perché gli attacchi un CMS o che tu lo faccia con un tool specifico, boh, questo poi dipenderà da come sei comodo te, non credo che ci siano particolari...dipende dai tool che ti offrono, ecco, non ci vedo particolari problematiche in questo, dipende dalla comodità.L'importante è che hai qualcosa che ti leva dei problemi, perché queste cose servono se ti levano dei problemi, non se te ne creano degli altri.Volevo fare una domanda che mi è venuta in mente, perché noi usiamo il platformatic storyblock per la nostra home page e mi chiedevo, diciamo voi storate i dati che diciamo tipicamente escono fuori in JSON e poi noi renderizziamo.Ma esiste qualcosa per cui io ti dico, te Storyblock, questi dati tanto io li renderizzo sempre così, ti posso dare il codice e le renderizza e mi rendi direttamente una cosa? Esiste già, non esiste o non serve? No, ok.No, snaturerebbe il prodotto e non credo che sia...se il mercato lo chiedesse, magari l'azienda si sviluppa.se tu intendi come rendering, invece di avere la stringa a testo, di avere il markup, nulla ti aiuta di salvare del markup.se questo ti intendi.puoi pure farti un CMS di puro markup, ti crei dei blocchi di puro testo dove ci sbatti il tuo markup, secondo me fai una brutta cosa, però lo potresti sempre fare.eppure ci sono casi d'uso dove questa è una bella cosa avere qualcosa che ti sputa fuori dal markup? sì, sì ma...ho visto un caso d'uso una settimana fa di un'azienda che vende prodotti fatti da altre aziende che danno delle pagine HTML dei blocchi HTML già pronti col CSS con il marketing content che rispecchia esattamente il formato dell'azienda partner ma sì ma certo questo non c'è dubbio sì sì ma che qualcuno lo faccia non lo metto in dubbio è obbligato tanto però...non li chiamavamo iFrame prima ma guarda che qualcuno lo faccia non lo metto in dubbio non capisco perché dovresti farlo ma capisco che ci sia chi lo fa certo no, ripeto, capisco che non si vede il problema, però secondo me il problema...ma sai perché poi Mauro? perché una delle delle value, come si dice in italiano, delle cose migliori che ti offrono questi prodotti, lo dicevi pure te prima, sono gli editor visuali.se tu gli togli questo, perché tu gli sbatti dentro il tuo markup, l'editor visuale per chi non è un modo per collegare il tuo front-end, quindi il tuo framework, che ne so, React, Next, quello che ti pare, ma anche PHP, insomma il tuo front-end, collegarlo direttamente nella tua dashboard di Storyblock per dire, o di un altro headless, e vedere in tempo reale le modifiche che tu fai sul contenuto direttamente renderizzate nel tuo, nel tuo front-end.Quindi questa è una feature che, per cui tu magari sei disposto a comprare quel prodotto è una delle delle delle offerte principali se tu questa gliela togli perché dici no no io ti sbatto direttamente dentro il markup non voglio più vederti va bene nulla ti vedi rifarlo però stai togliendo al prodotto una cosa per cui tu l'hai comprato ti basta un database esatto a questo punto vai su firebase sbatti i tuoi dati non paghi niente oppure vai su una cdn sbatti i tuoi dati proprio come file statici è finito lì cioè gli togli capito la sua ragione d'essere essere se gli togli questa roba qua.Sono sono sono d'accordo con te rimango però per ritornare al fatto di dove sono i confini del CMS e dove iniziano altri confini secondo me bisogna fare un ragionamento diverso sospendiamo per ora l'editor visuale che è una roba molto custom e non c'è in tutte le soluzioni di headless CMS ok? E parliamo giusto di del motivo per cui utilizziamo degli headless CMS.Prima cosa fare il crudino della chiesa ha rotto il cazzo.Proprio papale fare crud, fare crud è una grande rottura di balle ed è per esempio uno dei motivi per cui per esempio il prodotto dell'azienda per cui lavora Leo è nato semplificando il crud.ok? è qualcosa di difficile.ma intanto i dati vanno salvati, letti, cancellati.è una cosa pallosa.è una di quelle cose che impiega tantissimo quei junior di cui parlavamo prima, no? perché chi si verticalizza non vuole fare crude, punto.però ti posso obiettare Mauro che qualunque CMS, credo da php nuke appunto, ti risolve questo problema.è la prima cosa che ti sì però i dati erano difficilmente strutturati.ti posso fare l'esempio del campo meta di wordpress minchia ci abbiamo messo di tutto là dentro ok? di tutto, di tutto.Drupal era un pochino più evoluto da quel punto di vista ok però stiamo sempre parlando di CMS ok e se noi dovessi dovevamo fare qualche applicazione quindi non più siti ma un'applicazione specifica non usavamo i CMS.Adesso che quel livello di complessità è stato risolto gratis da questi tool alcuni open source e li abbiamo citati altri software as a service, la tendenza è quella di dire "oh cacchio devo fare un'applicazione di booking, oh cacchio devo fare la mia applicazione per ristorante vuoi vedere che i piatti i prezzi i menu eventualmente i bottoni li metto là dentro vuoi vedere che le feature flag me le metto nel CMS io queste cose le sto vedendo fare vuoi vedere che la sequenza delle pagine della mia applicazione me la metto nel CMS vuoi vedere che mi modello anche i menu dell'applicazione nel CMS.Figo! Molto figo! Ma a questo punto non stiamo più parlando di CMS.A questo punto entrano in gioco tutta un'altra serie di elementi che mettono alla prova anche l'architettura stessa del CMS che ti sta offrendo la strazione del crude.faccio un esempio alcuni headless CMS storano roba in blobboni su S3 ok ne ho visto diversi open source che lo fanno credo tutti facciano perché non farlo? tra l'altro sì altri li storano su database però mi chiedo la tentazione di usare questi CMS per buttarci dentro il 90% dei dati della nostra applicazione, spesso rischia di scontrarsi con i limiti tecnici di alcune scelte tecniche pensate in un'ottica di headless CMS, quindi di content management system, e secondo me ecco questo rischio viene evidenziato poco, è difficile da spiegare quello che vedo perché più un feeling che è un'idea chiara ok sto cercando di svilupparla con voi però secondo me questo disco viene evidenziato poco cioè il fatto che i CMS rischino di diventare quello che era wordpress per e-commerce ok? volevo dire esattamente la stessa cosa cioè wordpress post che ce n'è uno dopo l'altro e pagine che sono statiche fine e ci hanno fatto e-commerce dove gli articoli sono post di tipo prodotto, che gli ordini sono post e quello è un adattamento che funziona così tanto bene che lo hackeriamo.Io ho avuto una mensola per tenere sulla televisione che aveva i piedini che erano di una cucina, però erano bellini satinati, quelli dell'Ikea costavano un euro e la gente...c'è un Reddit dove hackerano la roba dell'Ikea per trasformarla in qualcos'altro.è uguale.Eppure e commerce, ora forse con Shopify meno, ma commerce...Assolutamente.Ti parli a passato Drupal e Wordpress, ma sono vivi e lottano con noi.No, no, Drupal è passato.Wordpress penso che sia il 85% dei siti...Dicevano dei blog, però non considerano gli e-commerce, perché anche tanti e-commerce...No, no, ma sono prodotti vivi e vegeti.Cosa volevo dire? Volevo dire che dipende un po', lì si torna nel concetto senior, junior, no? Tu perché usi un tool come un CMS? Tu lo usi perché ti deve semplificare un lavoro, no? Se tu potessi facilmente accedere al dato creato dal database, ma tu faresti quello, che te frega? Invece no, tu devi avere a disposizione delle astrazioni che ti facilitano quella roba lì, perché oggi tu salvi la home page sul database, fai una query, te la pigli, finita.domani dica "no, aspetta, però di notte fai vedere questo, di giorno fai vedere quest'altro" "no, allora devo aggiungerci uno script" benissimo, poi domani ti dicono "aspetta, fai un'altra pagina, poi ci metti anche un altro editor che può vedere soltanto quella pagina, anzi facciamo così, può vedere soltanto una parte di quella pagina" "ah no, allora devo aggiungerci un altro pezzo, quindi crei complessità su complessità" "no, allora aspetta" tutto questo discorso qua te lo gestisce qualcun altro, non ci devi pensare, tu pensa soltanto a fare le tue paginette.Quindi a questo punto la competizione non è più sul che cosa ti offro perché abbiamo capito che ti offro la soluzione a questo problema ma è come te la offro.Cioè che cosa ti do? Qual è il livello tecnico dell'API che ti offro come soluzione? E lì se tu sei sufficientemente in grado di capire che un API è meglio di un'altra sulla soluzione del tuo problema, qui allora magari poi sei più in grado di scegliere.Se invece sei semplicemente uno che dice "Vabbè, be', piglio quello che c'è e leggo il getting started, sperando che sia buono e lo uso", ok? Non fai quel passetto oltre.Però in realtà, la vera, il vero valore di un prodotto, che sia un CMS monolitico o headless come storyblock, è il come ti offre il dato, che tipo di accesso ti offre, l'API, la cache sul dato, queste cose qua, sono tutte cose in più che tu hai con un prodotto di questo tipo.Ed è anche il motivo per cui magari uno passa a headless provenendo da Wordpress o Drupal, perché con Wordpress o Drupal molte cose te le devi costruire tu, non sono nell'offerta, non sono nel prodotto.Invece con un headless che tu paghi, ecco lì, ce l'hai già.Sempre parlando di headless, no? Stavo ragionando in un attimo di una cosa.Prima stavamo dicendo, no, che l'evoluzione tecnologica porta generalmente a una semplificazione, no? e mi dico ma se tanto stiamo stiamo semplificando prima wordpress o comunque gli ad non so come definirli i full cms ok? potevano essere usati...monolithico...ok yeah le cms monolitico poteva essere usato dal pinkopallo della strada mio cugino con 7g per farmi il sito arrivano gli headless CMS che essendo headless ti gestiscono i dati e lasciano a te la responsabilità di fare il frontend di fecciare i dati di farti i tuoi bottoni come li vuoi scrivendo il codice bim bum bam e questa è un'inversione di tendenza in un'ottica di una semplificazione generale ma è più una verticalizzazione giusto? Dipende da cosa vuoi semplificare perché cosa è più costoso fare la UI o gestire il dato, il database, la security, lo scaling? Cioè dove è il costo vero per un enterprise? Perché stiamo parlando del sito della parrocchia naturalmente ma su volumi più grandi dove dov'è il costo vero il front end o tutto quello che ho detto da gestire dietro visto il front end lo deleghi perché c'è il lsms no ma non solo non voglio dire che le skill di front end valgono meno è no ma è ovvio che il costo di creare mantenere e deployare un un front-end è enormemente inferiore a quello di gestire, mantenere, deployare, eccetera, un sistema di back-end che gestisce il dato, che gestisce il database, eccetera.Quindi, stai spostando il costo, stai spostando l'effort dove ti costa meno.È vero che per fare il sito stiamo partendo da uno scalino maggiore.Devi affrontare uno scalino, perché devi crearti tu il front-end.Non te lo do.Non ce l'hai out of the box.con Wordpress ce l'hai, quindi a livello base non partiamo alla pari perché con Wordpress hai tutto, perché questo si chiama monolitico, perché hai tutto in un pacchetto, lo installi quando fai l'avvio vedi già la tua UI, la tua home page, ma lo step successivo a questo e ogni step successivo a questo diventano sempre più costosi, mentre con un ad SMS e non hai questo tipo di progressione, la tua progressione è su quanta complessità vuoi mettere nel front end.Questo sta da te, potrebbe anche diminuire per quanto ne so.Al crescere del tuo business non è detto che cresca la complessità del tuo front end, invece ti assicuro che al crescere del tuo business crescerà la complessità del tuo back end.Quindi lì il costo cambia.Ti ho convinto Mauro? Non ti vedo convinto.No sì sì sì assolutamente.Da questo punto di vista sono d'accordo con te.e nelle soluzioni open source hai comunque il vantaggio di per esempio avere dei sistemi di diritti già pronti, di avere dei form che sono una grande lottura di cazzo già fatti con dei component anche abbastanza evoluti per imputare dati di una certa complessità, no? Su questo sfondi una porta aperta.Pensavo e provavo a fare un esercizio mentale, no? E pensavo oggi stiamo disacopiando o comunque separando dato da visualizzazione da template perché stiamo ragionando in termini di headless CMS e stiamo sostituendo la parte di gestione dati.Cosa succede se proviamo a immaginare un eventuale servizio che faccia la cosa opposta, quindi astraga la sorgente dati e in qualche modo offra una semplificazione nelle visualizzazioni, in come le cose debbano essere visualizzate, essendo sorgente dati agnostica.Stavo provando a fare questo esercizio mentale, lo so, è tipo un trippo, no? Non siamo un rave.Però se noi abbiamo astrato la complessità da quella parte, disaccoppiando le due componenti, potremmo in qualche modo astrare la complessità anche nella parte di destra, tenendo questo disaccoppiamento? No, perché ti mancano gli standard.Cioè tu lato...quando tu vuoi offrire il dato tu hai degli standard.REST è uno standard, JSON API è uno standard, GraphQL è uno standard, ma anche il formato del dato in generale è uno standard.Lato frontend tu non hai uno standard.Quindi ognuno fa come gli pare.Finché non hai degli...posto che poi mi potresti anche dire che HTML è uno standard.No, HTML in realtà è un linguaggio che ti permette di creare quello che potrebbe diventare il tuo standard, però non hai uno standard, no? Nel formato.Ce l'avevi forse con con XHTML, però beh, si entra in un altro un altro problema.Quindi non avendo standard tu non puoi avere un...non puoi astrarre al contrario.Non puoi avere qualcosa che gli puoi cambiare la sorgente e rimane uguale.È un concetto che una volta forse qualcuno aveva pensato a ipotizzare, ma se tu non hai uno standard lato front-end non puoi avere qualcosa che...a cui puoi cambiare la sorgente a piacere perché perché lo standard è l'altra parte, funziona al contrario.Sì, e poi avendo il dato più egrezzo puoi comunque comporre un dato complesso, non puoi fare il...per esempio Instagram e Amazon probabilmente prendono i dati in JSON tutte e due, però hanno delle funzioni completamente diverse e comunque partiamo dallo standard che è il dato e probabilmente i dati sono molto più spezzizzati rispetto al JSON che arriva dall'eventuale API.Sì, sì, lo standard è in come offriamo il dato, non in come lo richiediamo.Quindi lo standard è in quella direzione lì, non si inverte.Ti ho stunnato.No, ho trovato la quadra.Oddio, adesso ho fatto un critico.Ho trovato la quadra, sì, ero da un'altra parte rimbolla perché penso di aver trovato la quadra Questo perché non è scriptato questo podcast No, manco per il caso Non è fatto con AI Se da una parte abbiamo l'headless CMS e se provassimo a mettere i low code dall'altra avremmo a parte una combinazione immortale No, però, mi immagino un retool, no? O un web flow dall'altra parte, no? o un qualcosa che che ti permette la composizione visuale a quel punto cazzo è esattamente quello il corrispettivo nella parte di visualizzazione e in realtà sì ma non credo che i due sistemi di locode abbiano utilizzato lo stesso formato sì almeno c'è uno standard dello code consumano non è pià il resto.Ma consumano vuol dire che lo standard è dall'altra parte.L'APA è lo standard, non il front end.Voi state ascoltando in podcast e non state guardando questo video.Immaginatevi Mauro con tutti i numerini sopra la testa.Non presenti quel meme della tizia che si guarda intorno con i numerini sopra la testa? Mauro è così.credo che abbiamo raggiunto dei livelli di astrazione un po' troppo… no, magari ci vogliamo provare a capire, forse non ci arriviamo, forse non c'è davvero, perché ci può anche stare che non ci sia… no, perché non credo che ci sia il bisogno di farlo.per questo che forse non c'è, perché nessuno forse aveva avuto il bisogno di creare uno standard di quel senso lì.ve lo dico chiaro.vedo l'avvento degli gli headless CMS come una rottura di quel processo di democratizzazione della creazione di siti web che era stato attivato in periodi quando ero giovanotto io addirittura PHP, Nuke, Joomla e WordPress ok? perché l'headless CMS risolve un altro bisogno ok? risolve un altro bisogno e l'hai detto chiaro tu Leo ehm...Edo risolve un altro bisogno.Adesso mi chiedo siccome l'headless CMS fa bene una cosa e la fa molto bene ti permette di modellare le tue strutture dati e di ciucciarne via i dati ti fa il crew di modo eccezionale più altri additional perks ma il crew te lo fa molto bene nel senso che spesso i form generati con gli headless CMS sono io porto la mia esperienza in Directus per alcune soluzioni mie in azienda nella mia azienda in Sardegna uso Directus come back office proprio perché sono riuscito a customizzarmi talmente tanto i moduli che fa esattamente quello che mi serve ok per caricare i dati.E questa cosa secondo me ha un valore inestimabile se democratizzata, quindi si è resa accessibile questo tipo di soluzione, si è resa accessibile i più che non sono sviluppatori.Però rimane comunque il problema della parte di visualizzazione.La parte di visualizzazione è delegata a qualcuno che conosce l'HTML bene, che sa consumare un API REST o GraphQL ed è una di quelle cose che ancora ci tiene il lavoro come diceva Edo prima, no? però in realtà per molti di questi headless CMS, quasi tutti, dico tutti gli headless CMS espongono gli schemi dati in GraphQL al resto, almeno questi due formati ok? Adesso rimane fuori dall'analisi tutta la parte di visualizzazione che è delegata lo sviluppatore.Però oggi abbiamo un mercato vasto, enorme, di soluzioni per low code o no code, ok, che risolvono una serie di problemi che è costruire la parte visuale nonostante o qualunque sia la forma del dato che arriva, ok? E secondo me la soluzione low code per creare la parte visuale che si sposa al headless CMS insieme compongono quello che prima era fatto da framework monolitici da CMS monolitici in un'otica di democratizzazione nell'uso degli strumenti.Ho un mega pappardellone parzialmente filosofico spero di avervi di essere riuscite a spiegarmi quello che c'avevo nella testa e che sto provando a dire da 25 minuti senza riuscirci ecco.Guarda secondo me è che risolvono problemi diversi quelli che tu metti in competizione in realtà probabilmente risolvono problemi diversi cioè non credo tu oggi parli di democratizzazione quindi mi immagino chiunque può farsi il sito web no? Questo tu intendi come immagino democratizzazione.Chiunque può farsi il sito e gestirsi il suo lato.Ok, però strumenti per fare questo esistono già, non c'è bisogno di crearne uno nuovo.Esistono, ci sono e non sono necessariamente CMS monolitici perché uno può aprirsi su Wix o su una marea di robe che ti permettono di fare dei siti.Te lo fai, è finita lì.Non credo che ci sia bisogno di risolvere quel problema perché non è un problema credo.Cioè non credo che l'avvento degli ad SMS come prodotto abbia tolto a chi prima faceva uso di quei siti lì, di quei prodotti lì qualcosa.Quelli continuano a esistere e risolvono, rispondono a quell'esigenza lì.Sì però introducono il concetto di dato strutturato e rintroducono il concetto del dato strutturato che secondo me ha senso e molti dei tool che abbiamo per la creazione di siti forse Webflow ha qualcosa per creare strutture date ma è sempre molto naive sono comunque tutti tool molto focalizzati sulla parte di visualizzazione più che dalla parte di gestione dei dati invece gli headless CMS spesso hanno un'ottima gestione del dato almeno quelli che ho provato io Mi è venuta in mente una cosa mentre parlava Mauro.JSON.Io finora ho considerato JSON come un dato, come un dato grezzo, ma non è che in realtà è una visualizzazione di un dato, che un po' si avvicina a quel discorso che faceva Mauro della standardizzazione della visualizzazione di un dato.Poi si può andare filosoficamente a capire qual è veramente il dato e non la sua visualizzazione, perché probabilmente anche il byte è una visualizzazione di un dato.Beh, aspetta, non esageriamo adesso, mi pare un po' azzardato.Ok.Beh, insomma, no, ok, lì si va proprio sul fisico.Allora anche una vocale è una rappresentazione di un dato.No, no, cioè il dato è il dato.La struttura è la forma che tu vuoi dare a quel dato.Quindi il byte è il dato.Ok.organizzi quei byte è la struttura che da il dato quindi il JSON è una visualizzazione o è un dato? il JSON è un linguaggio che rappresenta un dato o una struttura dati o una configurazione, rappresenta un significato è un linguaggio che ha, come tutti i linguaggi, hanno un significato.Cosa ci comunica? JSON potrebbe essere la home page del tuo sito web o qualcun altro è semplicemente un linguaggio che mette in comunicazione due esseri.I due esseri sono il database e chi consuma quel dato.Siccome serve un linguaggio comune per capirsi, il linguaggio è JSON.Sì, ok, mi torno perché stavo per dirti, allora anche un grafico su D3 è la rappresentazione di un dato, di una serie di punti.Certo.Però non è standardizzato perché se non hai le assi banalmente non sai di cosa si parla.Esatto.tu potresti anche servire i tuoi dati, potresti anche servirli in JPEG per quanto vi riguarda.Però poi bisogna di tutti quegli altri si mettere in accordo e vadano a leggere il tuo dato dentro il JPEG.Però è una convenzione, come decidiamo noi di parlare di strutturalità.Ho visto bandi pubblici pubblicati in JPEG.Esperto di JSON.No, però titolo dell'episodio "Jason è significato o significante?" Così veramente perdiamo… Guarda che io sono stato perculato vari anni da miei colleghi perché dissi che Jason era un linguaggio di programmazione.Su questo venni perculato perché non è un linguaggio di programmazione su cui poi possiamo stare seriamente a magari a dibattere, ma invece tra il serio e il faceto possiamo anche dirci che non è un linguaggio di programmazione perché con la programmazione devi eseguire delle cose e Jason non esegue niente, va bene, ma Jason è un linguaggio.Il dato sta da un'altra parte, Jason non è il dato, Jason è una rappresentazione di quel dato.No, ma è chiaro quello che Leo secondo me intendeva era il dato in formato Jason.È il dato o una rappresentazione del dato stesso? è un po' come il macinato per il ragù, che è un ingrediente o è il prodotto della macinazione? è una cosa nel mezzo ma no, è come dire, se io ti dico cielo, la parola cielo non è il cielo, è la parola che io e te usiamo per riferirci al cielo, capito? quindi è una rappresentazione di quel concetto in parole, ma allora come siamo andati alto però, hai visto? Gitbar è anche questo e io non ho bevuto non so voi...ah sì, io invece sì No pensavo In realtà sì, questa cosa ha preso praticamente il 100% dei miei neuroni Sono è andato, è andato, è andato...no, il bello è che sono andato in blocco ed è una cosa che sta succedendo spesso in questo periodo Comunque allora dico io una cosa, prima stavo cercando, perché mi ricordo che wordpress aveva la parte headless e sono andato a cercare wordpress headless, ho trovato solo articoli che spiegano wordpress headless, che in realtà è la wordpress api che non viene assolutamente archettizzata, venduta, come se dice "ok, vi abbiamo lasciato l'API perché ci chiedevate l'API", ma noi non siamo quello perché io pensavo "ok, questo è WordPress edless, lo potete usare per questo e per quello".In realtà evidentemente WordPress si focalizza su un altro problema, vuol dire che come dici, che gli address CMS, questa divisione, questa Insomma, divisione tra dato e del dato proprio visuale, Wordpress se la vogliono tenere proprio incollata, cioè quasi la sua mission.È che si rivolge a un altro tipo di mercato, un altro tipo di utente, Wordpress.Ma per esempio Drupal è un CMS che offre dati dati in strutturati come JSON, API o come GraphQL o anche come semplici REST in maniera anche molto evoluta.Io ho fatto progetti in passato con Spark in in contesti di address CMS utilizzando Drupal come back-end.Lì il discorso è che cosa hai a disposizione, che cosa ti serve e qual è il tuo obiettivo.Se tu hai a disposizione dei back-end PHP con Drupal e perché magari hai molta esperienza in quello, sai come gestirlo eccetera eccetera, sai perfettamente come adattare quel caso d'uso ma vuoi anche avere la flessibilità di front-end dinamici, vari tipi di front-end magari per sparare il tuo dato dove ti pare, ecco lì il il fatto che un CMS come Drupal ti esponga delle API ti può aiutare.Viceversa, se il tuo punto di partenza è "Io non voglio pensare al dato e al backend, voglio soltanto creare frontend", ecco, magari allora starti a installare un CMS monitico ti va a pesantire una cosa che ti puoi cavare se usi un prodotto come quello.Quindi il discorso è sempre il tuo requisito di business.Ecco, qual è il tuo requisito di business, qual è il tuo scenario, quanto vuoi pagare banalmente, quanto vuoi scalare eccetera eccetera adesso ti faccio una domanda puoi anche chiedermi di tagliarla ma figurati qual è la tua RAL? no perché le discussioni che ci sono su telegram assegno No, pensavo...abbiamo parlato di problemi risolti da un headless CMS, la mia domanda è qual è il misuse più eclatante che hai mai visto che riguarda un headless CMS? Allora, intanto io in Storybook ci lavoro da tre mesi, quindi non è che posso aver visto tutti questi casi incredibili.Però, per esempio, quello che diceva Leo prima di sbattere il markup dentro i blocchi, dentro il dato, e poi sbatterlo nel visual editor, ecco, questo secondo me è un caso di misuse, ma non perché sono contro di te che lo usi in questo modo, puoi pure farlo, ma è che gli togli la sua ragion d'essere, quindi di fatto stai...non lo stai utilizzando.Cioè per me tu dovresti utilizzare gli strumenti al massimo di come puoi utilizzarli.Cioè Storyblock oggi è un prodotto che ti offre, tra l'altro ti posso per esempio dire, un ecosistema di SDK open source per vari framework eccetera.quindi a quel punto tu puoi pure usarlo come usi strapi o altri facendoti le tue query eccetera però perché non sfruttare qualcosa che storieblog ti mette a disposizione anche solo in parte nel suo ecosistema cioè quando tu vai a comprare un prodotto secondo me tu dovresti vedere cosa ti offre quel prodotto e sfruttarlo al massimo al massimo no per massimizzare l'investimento che tu ci fai.Se tu non lo fai e lo usi male parzialmente, secondo me lo stai usando male, ci perdi proprio anche economicamente, perché non stai usando quello che il prodotto ti offre.Quindi usi un SMS per metterci dentro il dato in markup e poi lo prendi facendo delle query non cached in HTTP e sbatterele.Poi te le fetchi sul database di WordPress e le visualizzi sul il tuo blog, vabbè puoi pure farlo, fai quello che ti pare.Secondo me stai sprecando il tuo denaro.No? No.Quando ho parlato di salvare dell'html c'è uno use case preciso in mente, dove ha proprio un senso di business metterlo là, però potremmo rimanere ore a discutere di questo.Fidati prego amico mio, fidati di me, c'è un caso specifico dove è necessario fare questo perché tu devi mostrare in coda alla pagina del markup specifico fatto da altri che non ti osservano da parte.Sì ma stiamo parlando di un prezzo.Quindi ci sono degli use case, è uno su un miliardo, uno su un miliardo, però ci sono.pensavo pensavo a una cosa in realtà sempre riguardo riguardo gli headless cms e pensavo a una nuova tecnica di utilizzo del cms o della creazione delle applicazioni basate su headless cms che ho visto e mi piacerebbe avere il vostro feedback mi è capitato di specie negli ultimi tempi di confrontarmi con delle applicazioni disegnate per essere CMS driven.Sappiamo che le nostre applicazioni spesso, specie se il contesto nel quale operano è complicato e vario, ci sono un gozziliardo di persone che decidono che questa label in questo posto specifico è gestito dal team A e quell'altra label in basso a destra e gestita dal team B, poi c'è il team di marketing che deve mettere un elenco puntato ma che possiede solo le prime tre voci e il team di prodotto che ne possiede le altre cinque.Ci sono questi casi quando andiamo nelle grandi enterprise no? E questi casi si manifestano spesso anche nelle web application.Una tendenza che ho visto e che mi piaceva discutere con voi è quella di fare delle web application CMS driven.Cosa vuol dire? E questo l'ho visto proprio con Storyblock ma è una cosa che può essere fatta con qualunque CMS anche con Directus.La struttura della web application viene creata nell'headless CMS così come la struttura delle pagine.Molti di questi headless CMS ti permettono di creare dei modelli di dati pensando al concetto di component quindi il blocchetto e il concetto di componente non ci siamo, non abbiamo approfondito secondo me dovremmo dedicarci qualche minuto su questo concetto che secondo me è molto interessante quindi c'è il concetto componente che noi modelliamo nelle nostre nelle nostre applicazioni e questo concetto paradossalmente ha due rappresentazioni fisiche una rappresentazione in fase di inputing dei dati di ingesting dei dati di inserimento dei dati e una in fase di visualizzazione quindi se noi modelliamo la nostra applicazione all'interno dell'headless CMS noi stiamo modellando tutta l'applicazione.Creiamo il concetto pagina.La pagina ha il corpo che è un altro input del dato e il corpo può ospitare una lista più o meno varia di componenti, questo dipende molto da chi ha modellato l'oggetto pagina e ognuno di questi componenti come dicevamo prima ha una rappresentazione in fase di input e in fase funzionale.Una cosa che vedo fare spesso è creare la pagina e nel concetto corpo mettere dentro la modellazione del componente che magari è il modulo di booking, ok, dentro il CMS, quindi una sua modellazione con i blocchi di input per caricare i dati, nel CMS, nel corpo della pagina e a quel punto creare poi i componenti nel mio caso specifico React e quindi la pagina si compone prendendo dati della struttura del CMS che poi prende i componenti React e ti compone la tua pagina di booking.È un casino da spiegare, io spero di esserci riuscito però l'idea è che ogni componente per quanto funzionale e poco legato al contenuto possa essere viene modellato nel CMS che ne prende una serie di proprietà che possono essere feature flag oppure nel mio caso di booking che adesso faccio la pagina di Gitbar e nel mio modulo di booking di Gitbar metto l'id del servizio Gitbar, ok? Come vedete questo approccio? E' secondo voi una rivoluzione nella creazione delle delle app? Guarda, rivoluzione non lo so, ti posso dire che anche io vedo molto utilizzato questo paradigma, specie perché, almeno per quanto riguarda Storyblock, vedo molto, molto lavoro nell'atto di customizzazione, nelle offerte di customizzazione proprio dei blocchi.Oggi in Storyblock è possibile installare plug-in dal marketplace che si integra con servizi infiniti, infiniti, un po' di servizi, e ti permettono anche di creartene di tuoi, cioè tu puoi crearti dei dei plugin che fanno quello che ti pare, che poi ti gestisci in pagina come se fossero dei blocchi, dei componenti, insomma, ti gestisci in pagina.Quindi se quello poi è la configurazione di una tua app o della tua web app di quello che è, va benissimo, è un caso d'uso assolutamente previsto.Perché a noi è facile spiegare l'headlessms come appunto la pagina perché è il concetto più semplice.ma è assolutamente applicabile a tante cose, come a una configurazione, una configurazione di componenti, di configurazione di prodotti.E c'è chi usa Storyblock per creare i configuratori delle macchine.Sai quando compri le macchine e ti personalizzi la macchina con i tuoi vari componenti? Ci sono aziende che usano Storyblock per creare quei componenti lì, per poi creare dei configuratori, quindi delle web app con i configuratori, eccetera.Ma è assolutamente estendibile questo discorso.Quindi sì, trovo interessante che hai trovato qualcuno, ha pensato a un modo per semplificare la parte di configurazione, che se no magari era delegata a salvarsi queste configurazioni magari su un Firebase da qualche parte, che però poi avevano bisogno di un qualche front end per essere poi gestite, perché poi andassi a gestire il lato grezzo è complesso.In questo caso tu hai una sorta di front end sulla configuratore, sulla configurazione della tua web app.che effettivamente è interessante perché ti permetta a quel punto di essere più flessibile, quindi di ridurre il costo in quella parte lì perché puoi formare qualcuno per configurare quelle pagine utilizzando un address CMS senza dover andare a guardare il dato grezzo ma avendo un'interfaccia che gli da questo strumento più semplice.Ecco questo mi pare assolutamente interessante come approccio.Non so se è rivoluzionario, in senso che non so se prima esistesso dei tool per semplificarti questa cosa qua non lo ricordo però sicuramente è un bel caso d'uso io ricordo che nella maggior parte delle applicazioni quando tu sviluppavi l'applicazione se c'era qualcosa di customizzabile tu ti scrivevi il codice per customizzarlo, sai quante volte io ho perso del tempo giusto per permettere al super admin per esempio di muovere il blocco a destra o a sinistra secondo come gli girava o di cambiare un certo testo qua o di schippare uno step già con un feature flag ok? il feature flag secondo me è l'esempio perfetto il feature flag potrebbe essere certo un'intera feature di un'app ma potrebbe banalmente anche essere l'attivazione o meno di un banner pubblicitario o di un banner di una promozione potrebbe essere un feature flag del tuo contenuto dare in mano al editor, quindi non ha un programmatore, uno strumento che semplicemente gli fa attivare o disattivare una cosa, quindi una configurazione effettivamente è un caso d'uso ottimo perché appunto le aziende poi a questo punto non hanno più bisogno del programmatore che gli va a spegnere o accendere quel banner ma lo configurano dal loro dashboard.Sì e vi dirò di più Pensavo a un'altra cosa ed è sicuramente una cosa che farò con l'azienda in Sardegna nel sistema di booking che abbiamo creato, perché l'ho visto utilizzato in alcuni contesti dove lavoro.L'idea è di avere un workflow, ok? Tu hai questo workflow che è fatto da step 1, step 2, step 3.Se attiva una nuova normativa, tu devi integrare lo step 4, che deve stare tra lo step 2 e lo step 3.Quello che succede è questa normativa dura un mese e tu devi chiamare lo sviluppatore per farti fare il form, cambiare tutti gli schemi di workflow della web app per mettere questo step prima e poi richiamare lo sviluppatore per rimuovere.Quello che avere un'app fully driven da un headless CMS permette è quello di chiamare lo sviluppatore e dire non mi fare tutta la pagina, fammi il blocco che mi risolve questo dato specifico, che ne so, un modulo di booking, io metto data e quando voglio partire, quando voglio tornare e poche altre informazioni, poi c'è lo step del caricamento delle informazioni del cliente se io gestisco tutto con un headless sms in coda alla pagina del caricamento di informazioni clienti io posso aggiungere un altro modulo ok dove mi configuro che tu possa caricare la foto e eventualmente due foto una del documento identità e una di qualunque cosa voi vogliate ok chiamo lo sviluppatore e gli dico non mi cambiare tutto il workflow fammi solo la visualizzazione e la funzione di caricamento della foto legata a quel flow così che io un componente nel mio headless CMS un componente a visualizzazione l'applicazione se vede quel componente chiamato dal CMS mi renderizzerà la quel componente e io business non developer e io business mi faccio la mia pagina, mi faccio la mia web app come mi serve e ve lo dico perché io ho fatto una cosa simile per un tool che ho sviluppato con Directus, ho creato un componente a visualizzazione con una mappa 3d di Mapbox, ho creato un componente in Directus, l'ho scritto in Vue.js, per puntare una serie di punti della mappa che mi salvava quel blob in JSON dentro Directus, a quel punto posizionavo quel blocco nella parte che mi interessava dell'applicazione e quel blocco veniva visualizzato.Quindi non stiamo più parlando, ecco perché prima dicevo i boundaries di CMS arrivano fino a pagina 2, qua stiamo parlando di web application, non stiamo parlando di CMS.Eppure l'headless CMS gioca un ruolo importante proprio per la sua capacità di semplificare l'ingesting dei dati e la visualizzazione anche in contesti dove si parla di web application.Certo.Secondo me possono diventare il luogo dove tu sposti tutta la gestione del dato inteso come sorgente dato delle tue app in contesti aziendali, cioè la sposti totalmente lì.Non hai vari sorgenti, ma te ne mantieni uno solo, che ti mantieni i dati dei tuoi siti, i dati delle tue app, le configurazioni, tutto quanto, perché lì è il punto dove ci accedi più facilmente, te le gestisci più facilmente.E soprattutto è unico, potenzialmente.Sì, quando la complessità poi espone io sono un pochino ristio a vedere a vedere l'headless CMS come il data hub della situazione questo un po mi spaventa perché forse perché venendo dal non enterprise penso a data hub come una cosa molto articolata però consumabile dall'applicato.No no, non fratendo mi, dati, dati veramente dati importanti quindi stiamo parlando del classico database, insomma il data warehouse rimane data warehouse ma il contenuto che tu usi per tutti i tuoi front end quindi tutto quello che tu esponi al pubblico potenzialmente te lo gestisci tutto in un unico punto te lo gestisci lì poi se ti serve anche il dato dal data warehouse ok ti fai te lo prendi utilizzando soluzioni che ti piacciono di più dei plugin o delle altre API insomma però domanda ve la faccio a entrambi immaginate di dover fare il sito di un albergo ok la disponibilità delle camere la mettereste mai in un headless CMS? Cioè hai inteso quante camere ho in un dato momento? Si e quel dato mi serve per fare poi la stanza è disponibile prenotala e poi fermami la stanza.Dipende dal tuo ma dipende secondo me dalla complessità del tuo caso d'uso eccetera cioè se hai un albergo da centinaia di stanze con ordini online e offline contemporanei eccetera probabilmente non ti conviene ti conviene avere questo dato sul database che gestisce concorrenza eccetera e invece utilizzare led SMS per la parte di presentazione di quel dato.Allora siamo allineati.Sono d'accordo anch'io, lo vedo più come una cosa di database.Il led SMS è una cosa nel mezzo, un pochino più elaborato, pronto per la visualizzazione, come la vuoi vedere te.Anche perché secondo me oggi il database lo vedo di più come un qualcosa che viene letto è scritto da macchine, mentre il CMS è qualcosa che viene scritto da esseri umani, poi letto potenzialmente da macchine, ma scritto da esseri umani.Cioè il CMS è pensato per essere, per essere, perché la ingesto, la scrittura del dato venga fatta da una persona, non da una macchina.Cioè ce l'ho l'APA in scrittura, va bene, ma serve per casi specifici l'APA in scrittura, non è il suo caso principale, è un di più che tu puoi utilizzare in certi momenti che ha assolutamente senso ma il caso principale è la lettura del dato.Si risolve il problema.Quindi il database più come storage dei dati, quindi si scrive più che si legge, in realtà si legge per poi produrre, nell'address CMS in realtà si legge molto più di quello che si scrive.non lo so io magari shifterei la visione, la porterei più su...il database come sorgente di un processo di tipo computazionale, il CMS come sorgente di un output legato alla visualizzazione no? perché vi ho fatto la domanda del booking per quello perché le disponibilità delle camere e tutte queste belle cose presuppongono un'elaborazione computazionale on top e come abbiamo detto prima avere i dati del CMS elaborarli a transazioni ACID e consistency dei dati insomma potrebbero essere un problema io credo che secondo me abbiamo snocciolato praticamente tutto ma non abbiamo parlato il visual editor.Last question, siccome lo vista implementato da tanti tool anche tool open source il visual editor, secondo voi qual è il valore aggiunto di un editor visuale dove semplifica il processo? Lato business o lato sviluppatore? Prima lato Ok, perché le sviluppate, le semplifica entrambi in realtà.La "to business" chiaramente tu quando modifichi qualcosa che ti serve a presentare, tu vuoi vedere che cosa fa quella tua modifica e lo vuoi vedere subito, vuoi vedere il prima possibile, non vuoi aspettare che qualcuno ti bigli di quella roba eccetera, vuoi vedere in tempo reale le tue modifiche.Il visual editor non è altro che una preview del tuo contenuto, di quello che stai mettendo nella pagina, quindi questo è, insomma, in ottica business è fondamentale, tanto che secondo me i prodotti che non lo offrono poi sul mercato in realtà richiedono a chi li usa di implementarsi da solo, perché è un componente di cui non puoi fare a meno, cioè non puoi andare blind, no? Metti il dato, poi vuoi vedere cosa succede.Con il visual editor tu vedi una preview di fatto, non è il dato che tu hai pubblicato in produzione, cioè non è la pagina che tu hai già pubblicato, la pagina che hai in una preview in memoria in quel momento lì.Questo è fondamentale, no? Lato business avere la preview di quello che stai mettendo dentro, se no non ha senso.Volevo dirti che ti semplifica quindi questo, eccetera, ma lato sviluppo, siccome se tu vendi una soluzione di questo tipo a qualcuno da sviluppatore non puoi fare a meno della preview perché nessuno ti mette il contenuto blind, appunto, e se tra i dei sviluppatori devi sviluppare te, ci sono vari problemi da affrontare e chiaramente un headless CMS con visual editor integrato te li risolve tutti e siccome l'ho fatto, un CMS headless con preview, ti assicuro che ci sono una marea di cazzi che ti devi risolvere e ecco un prodotto che te lo risolve già è ben accetto anche dal dev.In pratica quello che devi fare con un visual editor è semplicemente infilargli il tuo front-end, anzi addirittura l'url del tuo front-end e sei a posto come fa il visual editor a correlare il field con il blocco specifico nella pagina html? c'è un bridge javascript ma sono io che quando faccio il template devo dire "eh qua ci metto il titolo" e qua ci metto il corpo, qua ci metto...- Ma quello è il tuo template, quello è il tuo template e già risponde alla struttura della pagina REST come deve essere, no? Cioè quella rimane immutata, tu non cambi la struttura, se no devi cambiare anche il template.Ma poniamo che la struttura rimanga uguale, tu cambi soltanto il contenuto, quel contenuto è semplicemente il...fai conto che sia il JSON che ricevi dal back end.Se io quel JSON lo sostituisco con qualcosa che cambia in memoria live, ecco che allora quello che vedo è semplicemente quello che ho in memoria in quel momento lì.Cioè io prendo il JSON dal back end, poi te lo manipolo sostituendolo live con qualcosa che è la rappresentazione di quello che stai scrivendo te.Quindi quella roba lì quando tu rifresci la pagina asparisce.Aspetta un attimo, io ho un sito che consuma il mio headless CMS ok e mi visualizza la mia pagina dell'episodio di gitbar, titolo, testo, immaginetta e whatever.Tutto succede server-side perché sono figo e mi piace PHP e sto usando twig per renderizzare la pagina, quindi faccio una chiamata HTTP alla API REST dell'headless CMS, TWIG mi compone i blocchetti e mi restituisce una pagina renderizzata ok col titolo e quant'altro.Come fa l'headless CMS a sapere che il titolo sta esattamente in quel div annestato al settimo livello o in quel A1 proprio proprio là e non in un altro h1, scusa in quell'h1 e proprio là e non in un h3 che sta un po più sotto perché quello lì l'hai definito tua template, cioè tu nel tuo template hai scritto in questo h1 ci voglio il blocco 2.titolo come lo scrivo se sto consumando un API e sto prendendo i dati in json e li sto mettendo là ci devo mettere un id una classe specifica css per dire qua dentro ci sto mettendo questo dato? no allora tu quando prendi il json tu hai il tuo json ok e dipende dalla chiamata che fai all'api dipende dall'api poniamo che tu prenda il json di una pagina specifica sarà un elenco di blocchi componenti di quella pagina quindi a quel punto tu devi avere un modo per accoppiare i tuoi componenti del tuo front end, mettiamo i componenti di un framework react o anche PHP, tu devi avere un modo di mappare questi due componenti con i componenti backend.Ok, me lo fa una pagina PHP custom, un codice PHP custom.Si, si, te lo fai tu, cioè tu mappi, quando tu registri il client, le prime chiamate, mappi queste due componenti, tu dici che ogni volta che incontri una pagina di tipo pagina, ecco, usa questo template qui.Dentro il template gli dirai qua nel titolo metti il campo titolo, qua nel body metti il campo body.Questo nel mio codice PHP.Nel tuo codice template PHP, perché sai che arriva la struttura che è fatta in quel modo lì e non muterà, quindi tutte le successive chiamate la struttura rimarrà uguale.quello che cambierà sarà il contenuto di quella struttura.Quindi titolo rimarrà titolo, body rimarrà body, quello che c'è dentro cambierà.In preview, semplicemente, tu invece di chiamare il backend tutte le volte, tu sostituisci questa chiamata con un oggetto che hai in memoria sul browser, perché lo stai editando in quel momento.Ma il PHP gira server? Sì, ma le chiamate ti arrivano sempre dal browser, la richiesta di visualizzare qualcosa ti arriva sempre da un browser quindi se io dal browser ti dico visualizzami questa cosa però aspetta ce l'ho già il dato eccolo qua capisci se io ho qualcuno che legge questa mia istruzione dice ah ce l'hai già il dato ok allora uso questo invece di andarmelo a pigliare da là oppure me lo piglio da là ma poi lo sostituisco col tuo cioè tu la comunicazione tu dal browser devi sempre passare comunque perché tu lo stai usando? Sì ma io al browser sto parlando a Storyblock nella visualizzazione o al mio headless CMS o sto parlando al mio motore di rendering PHP? Stai parlando a entrambi perché da Storyblock prendi il dato e dal tuo motore di PHP lo usi per renderizzarlo quindi stai in realtà parlando a entrambi no? No.Quindi il visual editor si mette in mezzo tra il tuo front-end, anche front-end PHP, e il back-end storyblock o qualunque altro.Se ci metti in mezzo.Quindi il mio front-end PHP chiama il visual editor, non chiama più direttamente la sorgente dati.Chiamerà sempre la sorgente dati, ma in presenza di qualcuno, in questo caso uno script che gli dice guarda che sei in preview e guarda che il dato è questo qua farà un comportamento diverso prenderà il dato dal browser invece quindi il mio il mio il mio script php deve ricevere un parametro che deve dire che serve per quando chiama storyblock o l'sms gli deve dire oh mica sono in preview sì sì è praticamente così se tu guardi nei codici puoi vedere, potete, chiunque può vedere i codici dei vari SDK open source di Storyblock, per esempio, e si vede come sono implementate le varie preview mode, gli bridge, eccetera.Cioè sono, sono dei JavaScript che dicono al, al tuo framework, in questo caso il tuo template, che stanno parlando con il visual editor e il visual editor quindi gli passerà dei dati che potrebbero sostituire quelli che arrivano dal backend.In realtà è molto semplice il concetto, si tratta semplicemente di mettersi in mezzo tra questi qua, tra questi dati, cioè a livello tecnico di comunicazione è molto semplice, poi è complesso come gestito il visual editor in sé, ma è molto semplice come viene passato il dato, è semplicemente lo stesso oggetto solo che invece di provenire dal backend, proviene dal browser, perché il dato in questo momento sta sul browser, tu immagina di avere il form con titolo due punti, no? Quello lì è un campo che sta sul browser, quindi tu cambi quel campo lì, quando lo salvi, quel campo lì, quel JSON che contiene quel campo viene generato dal tuo visual editor, quindi viene generato dal browser.In quel momento rimane un oggetto in memoria che poi diventa il tuo contenuto della pagina.Ok, no perché ripeto, quello che mi confonde è la parte server side.Io posso capire se tutto avviene nel browser, allora sì è facile perché posso fare uno string mapping se io trovo quel testo nella pagina io vado a fare un replace e questo è il comportamento che ho visto spesso nei visual editor, quindi cosa fanno? Nell'episodio c'è Edo, perfetto, mi prendo quella stringa, vedo dove è nella pagina con quella formatazione e la sostituisco, oppure in altri visual editor ho visto che quando tu fai il mapping tra dato e tag HTML in fase di renderizzazione ti viene chiesto di mettere uno specific ID o spesso te lo fa il template engine ti dice in questo div in questo h1 ci sta il campo nome titolo punto stringa ok in quel caso è facile ma se tutto avviene nel in uno script php che gira server side, questa sostituzione un po' mi viene difficile.Io posso capire che lo script PHP swappi la sorgente.No, no, no, devi per forza essere in contesto JavaScript, devi avere un pezzo di JavaScript che ti passa il dato.Questo pezzo lo chiamiamo bridge.Sì, ecco, ho difficoltà a vederlo funzionare perché il JavaScript me l'immagino client-side, no? E ho difficoltà a vederlo funzionare esatto e ho difficoltà a vederlo funzionare in un contesto dove il rendering l'applicazione del template avviene server side perché quando la HTML che mi arriva in visualizzazione dentro la funzionalità di customizzatore ok, la HTML che mi arriva perde tutti i riferimenti di cosa è mappato dove ok? è l'unico riferimento che ho sulle stringhe perché se io ti sputo dal php...certo ma tu rirenderizzi comunque quella pagina ogni volta che fai un cambiamento del dato che la pagina viene rirenderizzata soltanto che a questo punto il contenuto non sta più nella richiesta ipi ma stanno nel browser.possiamo semplificarla al massimo fai conto che io pigli il contenuto che ho del form dell'editing del contenuto sul browser e gliela submitto al mio server al mio bhp e gli dico bene ora renderizzami sta pagina utilizzando questo contenuto.Buono, fatto.Ok, mi guarda l'Sndk perché mi ha incuriosito.Me lo prendo come esercizio, compiti a casa, però guardando l'orario siamo a 1 ora e 51.Minchia! E va bene, non abbiamo ancora fatto il Paese dei Balocchi a questo punto allora andiamo."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Il paese dei balocchi, il momento in cui i nostri guest, i nostri host condividono con noi un libro, un tool, un qualunque cosa abbia catturato la loro attenzione e reputino interessante, importante, bello, condividere con la nostra community.A questo punto la mia domanda è avete qualcosa da condividere con noi? Ed ho! Allora, siccome io sono diventato un DevRel da qualche anno e lo sono diventato anche chiedendo che cosa potessi leggere per diventarlo Credo proprio tu mi abbia suggerito alcune cose e io una di queste cose l'ho letta e la consiglio a mia volta che è questo libro qua Questo libro qua è Developer Relations, una fantasia infinita nel nome che però corrisponde anche a un valore, una ricchezza di contenuto notevoli.Quindi Developer Relations scritto da Caroline Levko e James Parton.Chi volesse approcciarsi alla professione del...Ecco, voi ora vedrete che Mauro sta orgogliosamente mostrando la sua copia.e tra l'altro mostro con vari segnalibri.Questo libro qui secondo me è il punto di ingresso perfetto per chi voglia capire che cos'è la professione del DevRel, di che cosa si tratta, di come anche nasce, in che contesti nasce nel mercato, per poi magari proporsi come tale, avendo appunto una visione non soltanto da fuori, quindi ok, vedo che cosa fanno queste persone, mi piace, voglio farlo anche io, però leggendo un libro come questo capisci anche perché un'azienda interessa questa figura, quali sono le motivazioni di business, quindi che cosa cerca da te quando ti fa un colloquio, ecco, e queste cose mi hanno aiutato parecchio quando ho switchato a questa professione e credo che sia appunto di valore anche consigliare di nuovo questo libro.Non so se qualcuno l'ha già consigliato nel podcastone, ma se no, ecco, sono io.Bellissimo libro, ho trovato con cosa rilanciare.Vai! Leo! Allora, io vi volevo proporre un sito, una guida, non so nemmeno come chiamarla, si chiama cpu.land.Visto che parliamo molto di astrazioni e siamo andati molto in alto nell'astrazione, a volte bene ricordare anche quello che succede sulla CPU quando eseguiamo dei programmi.E questa è una bella guida che si legge online, mi sembra 6-7 capitoli, ma si legge in un oretto, un'oretta e mezzo, che spiega in termini abbastanza semplici ma tecnici, con qualche vignetta divertente, cosa succede ogni volta che noi facciamo eseguire una istruzione alla CPU.È una bella lettura che ci può anche introdurre poi a dire "aspetta, forse voglio usare un linguaggio un pochino più a basso livello, non a quel basso livello, però capire cosa succede sotto il cofano".E questo è il mio primo balocco.Il secondo balocco serve solamente a chi ascolterà il podcast, immagino, nei prossimi giorni, perché l'11 dicembre a Firenze gli amici di Firenze Dev.Insieme a loro organizziamo un meetup, un open mic, quindi un meetup dove ci saranno tre o quattro talk da venti minuti dove chiunque si può candidare purché sia in presenza a Firenze.L'undici dicembre la Impact Hub, metterò tutti i dati in descrizione, sarà un meetup per farci gli auguri e per ritrovarci tra noi della toscanità, ma ovviamente chiunque si trovi nei paraggi può venire.Se ascoltate questo podcast nel futuro è stata un'esperienza incredibile.Trovate tra l'altro tutto nelle note dell'episodio.Io ho un altro blocco perché volevo rilanciare mio amico Edo, è un altro libro che parla di DevRel, il cui titolo è "Developer Marketing Does Not Exist".Molto carino, buttateci un occhio.Sfatta alcuni miti e soprattutto fa profondamente capire cosa l'audience dei devrel vuole e cosa spesso gli si dà in realtà nella registrazione andrà tutto avanti quindi noi ci stiamo proprio sovrapponendo sì sì ma tranquilli tranquilli non c'è problema non è successo niente io sono caduto perché le alte tecnologie dicevo developer marketing does not exist nelle note dell'episodio io ho un altro balocchino piccolo piccolo che però è molto molto bellino se riesco a prenderlo spesso ci capita di scerare degli snippet di codice e spesso anche nei social li sceriamo così, magari alla cazzo di cane facendo screenshot da Visual Studio Code, whatever.I ragazzi di Raycast, che è il launcher di cui ho parlato qualche episodio fa, hanno fatto un bellissimo sito chiamato ray.so dove potete share delle bellissime e dico bellissime anteprime dei vostri snippettini di codice per farvi diventare un developer devrel migliore un social influencer e il mi mi farebbe da dire la Chiara Ferragni dei social, però Chiara Ferragni ormai è un po' bollita.Fabio Biondi dei social network.Un abbraccio allo storico Fabio.Io stavo per dei più giallucavacchi e con Fabio Biondi tu hai riportato la sticella abbastanza in alto, molto più in alto.Sì, non credo che potremmo più superare questo.Anche perché il codice su redot.so non fa i balletti.non credo neanche Fabio però, tra l'altro mandiamo un mega abbraccio a Fabio sì sì sì, no io no, io mi dissocio da questa brisola, manderò questo snippet audio a lui prestissimo detto questo io direi che siamo arrivati al momento un po' più rilassante, post episodio come è andata leo? edo.ah molto bene molto bene sì sì devo dire sono contento di essere finalmente anche ospite di hitper.finalmente.hai chiamato dopo ben 460 episodi.ma che cazzo stai dicendo? di 40 episodi fa eri conduttore.ma quello è stato un episodio crossover non c'era niente, è un'altra cosa.Hai detto che c'era un merda sul microfono.Cazzo, più crossover di quello.Ho capito, ma quello però era un progetto comune, congiunto.Questo mi ha invitato come ospite.E' ben diverso.Sì, è vero.Ma infatti quando ho visto il nome ho detto "ma scusa, non c'è mai già stato?" e invece ti dico "come non c'è già stato?" Ma non c'eri? Tu hai chiamato prima di me molta più gente che non meritava di essere prima di me.Tu hai chiamato Luca del Pupo prima di me, per esempio.Tu pensi a quante gente hai chiamato prima di me? Persino...Luca, Luca, rispondi a questa provocazione.Facciamo il dissing, facciamo i Tony F contro Fedez.Esatto.No, no, sono stato molto bene, mi è fatto molto molto piacere questo invito e essere dei vostri quindi grazie mille e spero di aver portato qualcosa di interessante e anche una puntata un po frizzantina.Sì, molto frizzante.Domanda Edo, quest'anno ci vai o non ci vai al Fosdem? Penso di sì, ma come l'anno scorso, cioè come l'anno, come 2023, no 2024 madonna, insomma Andrò nel 2025, molto probabilmente, come sono andato nel 2024, ma allo stesso modo credo che entrerò in poche aule.Questo è il mio obiettivo, è andarci, ma frequentare più gli ambienti comuni ed esterni rispetto alle aule che sono di difficile frequentazione.E anche di difficile supervivenza.In alcune andrò.Di difficile supervivenza.In alcune magari andrò, soprattutto su temi che mi interessano di più, se saranno praticabili, oggettivamente spesso sono proprio impraticabili, cioè a volte c'è un arrest che arriva al bagno e non riesci proprio manco a passare e quando riesci a passare devi anche resistere a quello che c'è dentro, senza approfondire ulteriormente.Comunque vedremo cosa farò, penso però ad una ottima probabilità che sarò lì in quella università in quel giorno.Allora ci si vede là, quindi magari ci vediamo.assolutamente sì.io un paio di microfoni li porto sempre.quindi poi dici "ci siamo e..." guarda, nell'equipment per il FOSDEM c'è sempre un piede di porco e un paio di microfoni.quindi un'aula possiamo aprirla? per quello serve il piede di porco.poi due anni fa è bastato girare la maniglia.Per colpa vostra quest'anno ci hanno dovuto nel corridoio perché le aule le avevano tutte blindate.Quest'anno erano gli amici di VLC che hanno praticamente spugnato l'aula per un'intera giornata.Quindi disinstallate VLC! No scherzo anzi, maledetti, maledetti, supportati i ragazzi di VLC che hanno fatto un ottimo e fanno un ottimo lavoro.Detto questo...comunque c'è anche l'alternativa no? Giusto, giusto.Quando ci sono battute frizzanti bisogna tirare fuori clip frizzanti.comunque c'è l'alternativa come windows media player.che alternativa puoi usare a vlc? non esistono.quick time? no no per anni fa ho sentito di un altro player.l'avevo anche usato su mac os che girava anche abbastanza bene.era un po a sherbo quindi uso vlc per un altro po e poi mi sono dimenticato non ho mai dimenticato il nome di quell'altro.Ma esiste ancora il bisogno di utilizzare dei player? Non lo trovo.Non basta trascinare il video nel browser e calcare play? Eh no, se tu vuoi installarti dei codec nuovi, tanti auguri.E poi se vuoi avere delle opzioni un pochino più...Eh sì, perché VLC...Ina, Ina.Ina.I-I-N-A punto I-O.Modern Media Player for MakeOS.Stanno diventando vecchie.se ti arriva un video con un codec particolare...no, la cosa del codec l'ho completamente persa mi ricorda l'eco quando ho installato il codec lo streaming ha salvato tutto e ha distrutto VLC no, perché viene usato per il pezzo 8 il VLC ma non solo, non solo...anche per scaricare l'eiso di Linux Ma no, noi per esempio che siamo anche creatori di contenuti, quindi registriamo e scambiamo video, potrebbe anche darsi che usiamo dei codec che poi devi anche installarti per poterli poi utilizzare.Con VLC è super facile, con Bo, Pina, Vina, Ina.Ma davvero esistono ancora i video che si scambiano? No, pensavo fosse una cosa, sai...Una cosa del passato.davvero davvero ormai pensavo fossero degli standard ma integrati in tutti i video player invece no bello bello bello edo grazie di cuore di essere venuto a trovarci tu lo sai no ormai non della tessera ma c'è la tessera punti fidelity card a questo punto quindi appena becchi qualcosa di figo o insomma hai qualche topic che ti fa piacere condividere con la nostra community pingaci pure visto che sei parte della nostra community quindi c'è sempre una birra fresca una come si chiamava la sua birra? una Lami birra questa è la Lami turba trovate varie birre sui sui siti di Lami Beer.Amici di Lami Turba, se ci state ascoltando, noi abbiamo bisogno di uno sponsor, quindi...Guarda, visto che sono a Empoli, ci passo io in questi giorni magari...Potete pagare in beer, tranquilli, non cerchiamo denaro per forza...Conoscendo Leo non ne arriverebbe una bottiglia...Ah no, forse gli conviene pagare piuttosto che mandare birra, ok.No, scherzo, non è vero, Leo non beve astemio.Detto questo, grazie di nuovo, Edo.Non beve neanche un cume.È stato un super piacere averti qua.Grazie, Edo.A voi.Leo, allora tu da oggi quanto sei preso bene dalla questione headless, CMS e si è messo in genere.Non più nemmeno da prima.Di solito vengo preso dalle cose che intervengono nella mia carriera professionale.Non è una cosa che utilizzerai perché non ho casi d'uso per cui utilizzarlo.Cos'era sto rumore? Ho sentito il rumore di vetro rotto, pensavo fosse una clip.Però mi è piaciuto il livello di discussione dove abbiamo espresso anche opinioni differenti, momenti di riflessione, quindi è stata una cosa impegnativa anche nel filosofeggiare sulla questione di dati, di visualizzazione.Non la vedo in quello che potremmo utilizzarlo, nonostante noi utilizziamo Storyblock per la nostra home page.Vorrei andare a vedere, mi è interessato molto il discorso sul visual editor, vorrei andare a vedere un po' gli internals su come funziona, ma per curiosità, perché in realtà sono stato un po' silente perché stavo pensando a come...in realtà il visual editor, l'ho visto su Wordpress, è una cosa molto seamless, cioè funziona, però...ho detto "aspetta, in realtà come funziona fare la preview, però te stai chiamando il tuo server quando dicevi di mandare un parametro per dire che sei in preview?" Mi ha un po' drippato quella cosa, però non potevo mettermi sul codice, quello è interessante.è un aiuto per i non sviluppatori che vogliono mostrare qualcosa sul web e questo è comunque un bene Sì, vero, vero.Tra l'altro dovremmo farla una puntata sulla democratizzazione della creazione delle applicazioni dobbiamo Sentire Luca, che so che ha preparato un bellissimo talk su quello Leo, anch'io ti saluto, anzi prendiamoci due minuti per chi supporta github, chi fa sì che il nostro podcast possa uscire ogni settimana puntuale arrivare alle vostre orecchie.Per farlo naturalmente devo aprire un'applicazione che ci mette i suoi minuti per aprire, sfortunatamente c'è uno spinner che gira ma tra qualche secondo sarò in grado di ringraziare chi supporta github.Per supportare Gitbar lo si può fare in diversi modi a me piace ricordare che Gitbar può essere supportato con una filosofia Time Talent and Treasure cioè potete dedicare del tempo a Gitbar, dedicare il vostro talento a Gitbar oppure supportarci con una donazione.Oggi abbiamo una serie di donazioni da ricordare.Allora dobbiamo ricordare che Giuseppe ci ha invitato ben tre birre scrivendoci "Scusate per non averlo fatto prima, grazie per l'impegno, la passione e la simpatia che ci mettete in ogni episodio grazie a te Giuseppe e credo che per questa settimana sia...ah no, sì per questa settimana in tutto.Detto questo vi ricordo anche che nello store di Gitver, questa è una mega marchettona abbiamo anche la bellissima maglietta di video terminalista metal meccanico se non l'avete presa prendetela perché è una maglietta super mega hiper bellissima e detto questo io ringraziando nuovamente edo e leo vi do appuntamento alla prossima settimana Ciao a tutti, ci sentiamo la prossima settimana.Ciao Edu.Io sto ancora cercando la sigletta però fate finta di averla già sentita.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo ma il Gitbar è davanti a una birra, tutto ci sembra un po' meno grave.[Musica]
