Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio e questa settimana almeno in questo episodio dopo un primo episodio, quello della settimana scorsa dove ero solo soletto, sono in compagnia di Luca.Ciao Luca com'è? Ciao Mauro, tutto bene tutto bene, non volevo lasciarti solo allora sono corso in tuo aiuto oggi una birra con un amico non si rinuncia mai no? Assolutamente in realtà non siamo soli abbiamo un ospite anche oggi come nostro solito ma come sempre nostro solito prima di presentarlo il mio ruolo, il mio compito è quello di ricordarvi rapidamente i nostri contatti info@gitbar.it @brainrepo sono i modi canonici per contattarci e poi E poi, no, l'abbiamo chiuso, mi sembra.No, non l'abbiamo chiuso, sto scherzando.Abbiamo il nostro caro e amato gruppo Telegram, che forse può essere sfuggito nelle scorse puntate, ma ce l'abbiamo, ce l'abbiamo.Ed è raggiungibile cercando "gitbar podcast" o semplicemente "gitbar".C'è il faccione del nostro buon brain repo, con lo sfondo giallo e la scritta "gitbar".Non si può sbagliare.Siamo quasi vicini al secondo compleanno no? A dicembre il 31...il primo gennaio facciamo compiamo il secondo anno e quindi entriamo nel terzo anno dell'attività.Wow sembra ieri Dobbiamo organizzare il Geat Fighter di Capodanno allora? Assolutamente sì a questo punto potremmo invitare anche il nostro ospite se ha piacere di venire al nostro Geat Fighter Però ho preso un sacco di tempo abbiamo chiacchierato ma adesso andiamo alla ciccia quindi presentiamo l'ospite Benvenuti su github il podcast dedicato al mondo dei full stack developer I mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo Eccoci qua, abbiamo con noi Stefano Verna, founder di DatoCMS.Ciao Stefano, come stai? Ciao, ciao, bene, bene, grazie mille.Grazie a te di essere venuto qua a condividere parte della tua esperienza con il nostro podcast e la nostra community.Oggi ho un sacco di cose da chiederti.La prima che ti voglio chiedere è...Stefano come si è avvicinato al mondo dello sviluppo? E poi, anzi la seconda te la chiedo dopo, ma tu come sei entrato nel buco nero senza via d'uscita? Ma si sta parlando di un sacco di tempo fa in realtà.Il mio battesimo per quanto riguarda la proclamazione risale veramente alle forse ultimo anno degli alimentari, primo anno delle medie, qualcosa del genere.Andavo in biblioteca con mia madre e in biblioteca ho ho trovato questo libro sul QBasic pieno di illustrazioni molto bambinesche, molto carino con i giochini eccetera eccetera e nulla me lo sono portato a casa e da lì è partito tutto nel senso che mi sono iniziato a infognare come una bestia su provare a far funzionare questi puntati di codice sorgente, mi ricordo i pianti anche perché non mi riusciva e da lì è andata avanti.Continua a piangere da lì poi.Continua a piangere, oggi da questo punto di vista non è che cambia molto.Nulla, quindi è partito tutto molto presto.Poi diciamo che per quanto riguarda quelle superiori è stato fatto Geometra, quindi di fatto poi mi sono ritrovato anche lì a infilarci la programmazione dal vendere programmini a quelli dell'anno indietro rispetto a me con i cd-rom per fare gli esercizi in automatico che sapevo che sarebbero stati chiesti provarci a infilare in tutti i modi la programmazione.Dopodiché la direzione era già abbastanza definita, quindi ingegneria e poi da lì mi sono aperti i mondi, dal C alle cose fatte C'è una domanda che in realtà mi pongo e spesso pongo, c'è stato un elemento significativo della tua carriera che ti ha detto "da quel momento in poi sono un professionista del mondo dello sviluppo software" cioè il momento in cui hai preso consapevolezza che il valore generavi non era più marginale ma diventava importante? Non lo so, allora io ho sempre scelto, da quando ho iniziato a lavorare non sono mai stato dipendente, quindi ho sempre appena uscito all'università abbiamo fondato una cooperativa informatica che fra l'altro esiste ancora a Torino, si si chiama Wilayka, da lì mi sono spostato a Firenze, anche lì mi sono infilato in un'altra società, in un'altra agenzia web.Ho sempre cercato di metterci il massimo di quello che potessi dare, quindi magari non era il massimo, però ho cercato sempre di dare tutto quello che potevo dare da questo punto di vista.Più che una consapevolezza, adesso sono un professionista, magari ci sono state alcune esperienze che mi hanno dato un imprinting sul fatto che probabilmente in qualche modo ce la potevo fare.Mi ricordo alle scuole Mi ricordo appunto, ai primi anni dell'università, sempre completamente a caso, avevo rilasciato un'estensione per Firefox.Di nuovo, ripeto, completamente senza tanti pensieri, era per provare come funzionava questa cosa.Mi ricordo c'era l'IB nell'URL, quindi c'era l'alfanumerico crescente, All'estensione 201.E...E lì, diciamo, questa estensioncina che non faceva altro che dare un modo semplice e comodo per scaricare tutti i link di una pagina, fondamentalmente, che era qualcosa che Firefox all'epoca non metteva a disposizione, e tipo esplosa.Esplosa completamente.Siamo arrivati ad avere mezzo milione di utenti attivi al giorno.una roba fuori di cervello e in questa estensione c'era un bottocino donate che puntava Paypal anzi si dice Paypal e la gente donava soldi per una cosa che avevo fatto io, era incredibile, cioè ma anche solo 5 dollari ma avevo fatto io e qualcuno l'apprezzava e senza chiedergli nulla dava dei soldi per questa cosa e questo è stato il momento in cui ho detto "va bene, ok, facciamo questa cosa, piglia bene".Luca è un'esperienza quella dell'estensione che hai fatto anche tu no? Sì però ho messo il bottoncino donate ma non ho ricevuto niente, mi è andato un un po' malino.Avevo un centinaio di migliaia forse di utenti contemporanei perché era una estensione per Facebook che ad un certo punto esplosa, mi esplosa in mercati, non so, ho avuto la fortuna che qualche portale ha cominciato a consigliare questa estensione che non faceva altro che ingrandire la chat di Facebook sul desktop ovviamente e la potevi puoi trascinare in giro, quindi sostanzialmente miglioravo l'esperienza utente.E qualche portale mi aveva linkato e poi si copiavano tutti quanti tra di loro, ho avuto un'esplosione pazzesca, l'ho rilasciata anche open source, però...No, il fatto del bottoncino donate un po' te lo sto invidiando.Però ho delle soddisfazioni, soprattutto anche un paio di pull request sul repository delle traduzioni.Poi è successo quello che è successo, l'esperienza mobile l'ha vinta e quindi ho chiuso tutto, anche perché Facebook si era un po' arrabbiato del nome della mia estensione, allora ho preferito chiudere.Si chiamava Pretti Facebook Chat, poi giustamente hai utilizzato il nome Facebook, io avevo 23 anni, 24 anni, ero piccolo, giovane e inesperto, "Toi va bene, lo chiamo Prettifob Chat", no, non va bene nemmeno quello, ho detto "Va bene, allora la chiudo, perché non ho più voglia".Non nominare il nome di Facebook in vano.Beh, è un'estensione per Facebook, la chiamo Facebook, non posso nemmeno chiamarla Prettichat, sennò poi la gente credeva che era un'estensione per chattare con chissà chi senza Facebook, però va bene, basta così.questa storia mi ricorda un po' alla lontana la storia del famoso left pad come si chiamava la libreria? c'era stato proprio il problema del nome che aveva triggerato poi tutto il casino legato alla left pad però entriamo nel vivo dell'argomento di oggi tu Stefano come abbiamo detto prima sei founder di Dato CMS ma che cos'è Dato? Dato è un headless CMS questo probabilmente posso approfondire ovviamente quindi un headless CMS è uno strumento, un CMS quindi serve fondamentalmente per per gestire i contenuti di un sito, di un'applicazione, di quello che ti pare, ma ha la caratteristica di fermarsi al layer API.Quindi tutto ciò che è presentazione, noi non lo gestiamo.Noi e tutti gli altri ad SMS, ovviamente.Questa è un po' la caratteristica peculiare del termine headless, appunto sta a dire senza testa cioè senza front end quindi ci si ferma uno strato prima.Però il back end si mostra vero? Il back end fa parte del pacchetto diciamo che ti mettiamo a disposizione quindi back end e API ovviamente diciamo un layer quanto più più ricco lato API per permetterti poi di utilizzare lo strumento in tutti i possibili contesti che ti possano venire in mente compreso anche magari più di un frontend, no? Quindi uno dei benefici che si sente spesso associare agli SMS è proprio quello di poter avere magari un unico contenitore di contenuti che poi possono essere pulitati da più di un front end, quindi applicazioni mobile, sito web, totem interattivo, biglietteria o qualsiasi altra cosa che hai.Oggi il concetto di headless sta andando per la maggiore, ne sentiamo parlare un po' da per tutto, vuoi perché questo evolversi è in qualche modo connesso a uno sviluppo così veloce delle tecnologie front-end e legate prevalentemente alla user interface parlo di framework come react come view che comunque ti danno quella semplicità di sviluppo e soprattutto focalizzano tutto ciò che si sviluppa su quello che in realtà ha un qualche effetto nel nostro utente quindi la mia domanda è tutto il movimento headless può essere visto come da una parte il concetto di dividere timpera, dividere la complessità di un certo software in sezioni e dall'altra anche dare delle parti che possono essere generalizzate in outsourcing e quindi una sorta di e de-responsabilizzazione dello sviluppatore in questo caso? Sicuramente, il fatto di avere un decoupling tra contenuti e presentazione sicuramente ti porta a tutta una serie di benefici.Ovviamente questi benefici non ce li ha magari il sito piccolo, il sito del panettiere, è difficile che abbia la necessità, rimanendo a un livello di complessità mediamente basso, magari non riesce ad apprezzare i benefici.Però ovviamente più la complessità di un progetto che si vuole affrontare aumenta, più ovviamente ci troviamo in mezzo alla la complessità e quando c'è complessità sicuramente avere le cose ben separate tra di loro, quindi dare un nome alle cose e cercare di avere i contenuti il più possibile strutturati e quindi non legati necessariamente a un front end ti può aiutare.Le casistiche sono tante, dalla semplice volontà magari di cambiare tecnologia per il front-end.Cambiare tecnologia del front-end quando non è del CMS vuol dire quantomeno dimezzare il lavoro, nel senso che non è detto che tu voglia anche contemporaneamente cambiare il CMS, vuoi semplicemente cambiare per esempio da Gatsby a Next perché nel frattempo ci si è resi conto, visto che è un mondo, come dicevi tu, che si evolve molto rapidamente, può essere che ci si renda conto anche relativamente presto che una certa scelta non è magari la migliore per il tuo caso d'uso specifico.Ci sono altri benefici, quindi sicuramente dal mio punto di vista di sviluppatore c'è il fatto che tutti gli strumenti tipo Next, Gatsby, Naxxed, eccetera, sono oggettivamente superiori da un punto di vista di interazione con l'utente e di possibilità di ottimizzazione anche delle performance con il tema Wordpress, diciamo, standard.tutte le ottimizzazioni che ti trovi a gratis sfruttando questi framework oggettivamente te li scordi.Quindi questo è un altro punto, quindi se tu ti vuoi, se vuoi provare ad approcciarti allo sviluppo di un sito web con tecnologie diciamo non moderne, però diciamo attuali, quanto meno attuali, attuali sicuramente ti aiuta a utilizzare uno strumento di questo tipo perché sono proprio stati pensati più o meno nello stesso momento e quindi ovviamente un wordpress che è nato 15-20 anni fa non lo so fatica un po' ovviamente a stare dietro a tutta questa roba Pur provandoci perché ho visto che comunque wordpress sta spingendo in modo importante sull'API no? Certo, sì sì sì, assolutamente.E non è l'unico, c'è proprio un po' una corsa a loro in questo momento.Quindi strumenti anche che nascono come monolitici, e nascono come assolutamente bloccati in tanti aspetti, cercano in qualche modo di salire sul bandwagon nuovo, e provare a rivendersi anche con questa nuova funzionalità.quindi WordPress come SMS in questo momento è una cosa possibile, assolutamente possibile.Altri vantaggi possono essere la scalabilità, quindi è molto semplice tirare su, su Aruba, un sito WordPress magari, poche visite, funziona, 10 euro al mese, qualcosa del genere.Ovviamente non scala questa cosa, se si tratta di avere un sito web che deve essere con accessi da tutte le parti del mondo e magari con degli spai incredibili di traffico si passa dai 10 euro al mese a un tot di migliaia di euro magari e anche pagati upfront, quindi con delle macchine che devono essere dimensionate in anticipo per gestire questo tipo di carico.E anche se tu avessi una macchina carica, cioè bella pronta a gestire questa cosa, comunque tutte le persone del mondo andrebbero su un unico punto, su un unico server, che magari è molto distante da loro.Quindi un esempio proprio di vita vissuta.Noi abbiamo come cliente, diciamo, una grossa azienda americana che senza dirci assolutamente nulla ha pensato bene durante il Super Bowl di fare una bella pubblicità.Noi ci siamo resi conto del fatto che era andata online qualcosa il giorno dopo, che c'erano tipo non mi ricordo quanti tera di traffico non ci siamo resi conto assolutamente di nulla e loro anche quindi insomma diciamo che c'è un valore in questa cosa.Magari nel billing ma ne parleremo dopo di questo.Sì sì ma anche lì nel senso finché si parla di cdn i costi sono veramente insomma sono il minimo che tu puoi chiedere oggettivamente.Sì oggi le tecnologie per fare i siti web in realtà si sono evolute rapidamente.Ieri come dicevi tu prendevamo uno spazio condiviso su aruba, ci buttavamo il nostro wordpress, lancevamo il file php che faceva il setup e il nostro sito era pronto dal back end al front end.Oggi le cose si sono giustamente evolute in qualche modo possiamo anche dire che si sono complicate e impropria quello che sto dicendo io perché chi ha messo mani in wordpress sa quanto può essere complicato lavorarci perché in realtà wordpress era una chiave inglese con la quale provavi anche a fare i buchi per terra chiunque ha provato wordpress sa a cosa mi riferisco giusto per andare veloci il il famoso campo meta di post che conteneva praticamente tutto era un buco nero alla stessa stregua dei node modules che bello ricordare questi momenti del passato però tutto sommato la fase di installazione era abbastanza semplice bastava scaricare un tema e si era online con un headless CMS Riusciamo in qualche modo ad avere un'esperienza così leggera anche per lo gnubo di turno? Nì, nel senso, ovviamente per tutto questo ecosistema che poi prende vari nomi, il più famoso probabilmente è Gemstack, è un'esigenza un po' condivisa da tutti i player, quello di offrire un'esperienza il più comoda e veloce possibile, anche solo per rimettere nuovi sviluppatori nel mondo.Sicuramente, considerando che ci sono più parti in movimento, quantomeno devi capire qualcosa di cosa succede fra queste parti in movimento.Non necessariamente ognuno di questi oggetti come funziona, anzi, probabilmente, essendo spesso volentieri hosted, non è nemmeno necessariamente detto che tu debba capire troppo, però la parte di comunicazione e integrazione tra questi strumenti sicuramente può essere un po' più ostica, un po' più complicata, perché ti richiede un po' di comprendere quello che stai facendo.Non è un caso che comunque tutto questo mondo sia ancora molto riguardante non è solo la branchia dei developer, quindi non è che il cliente finale o il marketer oserebbe mai tirare su un sito gemstack.Dopodiché esistono ovviamente soluzioni che ti permettono di offrire dei template, quindi delle combo di strumenti che sono già state pensate per funzionare bene insieme e ci sono, diciamo, proprio, per esempio, Stackbit che si occupa proprio di provare a trovare una soluzione a questo problema quindi puoi associare un'antenna a tua scelta con un head cms a tua scelta cioè proprio graficamente puoi selezionare diciamo, gli adapter, tra virgolette, per ciascuna delle parti dello stack, premi deploy, colleghi ancora il tuo repo git, e si occupa di fare tutto per te, diciamo.Quindi su questi, diciamo, template, l'esperienza è molto simile.Sul sito di dato ci sono vari template, scegli i template, colleghi a Vercell o Netlify, colleghi a GitHub e se è a post nel giro di 5 minuti ce l'hai.Poi un conto è avere una roba che funziona senza sapere bene che cosa fa e un conto è capirci qualcosa.Quello è ancora un po' diverso.Sì, anche perché diciamo che i framework, come li chiamo, meta framework, front end, non sono esperienze proprio proprio frictionless, tanto per cittarne uno, Gatsby, prima di capire come funziona Gatsby, un po' di effort bisogna mettercelo, oppure si acquista un tema e si viaggia così però partendo dal fatto che molti degli headless CMS ti permettono di definire a monte la struttura dei dati e questa cosa diventa ancora più complessa cioè facciamo un passo indietro quindi noi diamo in outsourcing tutto uso delle parole forse improprie il pannello d'amministrazione e il database dove sta il nostro sito e anche la parte di storage dei nostri file e immagini deleghiamo tutto questo lavoro a un servizio terzo questo è fighissimo perché in un mondo dove si si parla tanto di API first questa diciamo è l'estremizzazione un po' del concetto e va bene dall'altro io devo realizzare il front end quindi sono o uno sviluppatore e mi butto su Gatsby, Nuxt, Next, quello in Go era...Yugo, Jigsaw, ce ne sono un gozziliardo alla fine oppure in alternativa utilizzo servizi come come quello che dicevi tu che automaticamente mi fa il pairing ma questi servizi funzionano anche quando le strutture di dati non sono il classico titolo sottotitolo testo con le immagini dentro.Intendi questi connettori automatici? Esatto.No.Ok.Io separerei fra due mondi quindi quelli che hanno sentito che Gatsby è figo, o che Next è figo, iniziano ad apprezzare il fatto che ci sono degli improvement da un punto di vista di usabilità del sito, di possibilità di animare un sito, come è molto difficile fare con un jQuery.E vogliono provare a vedere come funziona, quindi gli serve qualcosa...la classica esperienza di "non voglio perdere tre giorni per vedere qualcosa".fatemi vedere qualcosa e poi magari ci penso, se mi piace ancora, se continua a interessarmi mi ci metto.E' un conto poi l'utilizzo diciamo quotidiano da professionista.Ovviamente questi strumenti che provano un po' a fare la media dei vari servizi che ci sono a disposizione, a disposizione soffrono di un problema fondamentale che è ovviamente se io devo supportare una serie di possibilità, io devo supportare il minimo comune multiple di quello che mi offrono.Quindi riduco un po' la possibilità di sfruttare a pieno uno di questi servizi.Quindi se un SMS mette a disposizione qualcosa di particolare, Ovviamente su questi strumenti non lo riesci poi a sfruttare perché gli altri non lo supportano e quindi questi strumenti cercano di fare un fallback verso una tecnologia o un modo di ragionare che sia il minimo supportato da tutti quanti.A tutto questo, la ricetta di cui parlavamo poco fa, ci aggiungiamo anche il fatto che finalmente abbiamo dei provider che ci danno praticamente un hosting gratuito a gratis.Esatto, detto così fa ridere ma in realtà è una delle cose che molte persone guardano cioè quando devi startuppare il bloggettino dove scrivi quei quattro post, cioè tolto la spesa del dominio che tipo te lo prendi da con 2 dollari 3 dollari su pork bun se non lo conoscete buttateci un occhio perché se apro una parentesi molti di noi hanno dei side project che durano esattamente il tempo di pensarlo cioè 25 minuti esatto 25 minuti una volta che hai comprato il dominio diciamo che l'idea ti è già stancato e quindi l'hai messa da parte ecco bisogna ottimizzare anche le spese e quindi pork bun può essere un punto d'arrivo non siamo sponsorizzati da pork bun almeno fino ad oggi comunque volevo dire il potere ostare questi siti gratis è dovuto anche al fatto che tanti di questi siti sono staticamente generati quindi un po' si sta stravolgendo il modo in cui si vedono i siti web? Certo, sicuramente.Il ragionamento di base per il quale il pensare a un sito come Statico effettivamente ha molto senso.Quanti sono i siti veramente che richiedono più di 5 pubblicazione al giorno, oggettivamente parlando, ovviamente poi c'è Facebook o c'è la Repubblica, non lo so, però quanti siti sono la Repubblica e quanti siti sono molto più semplici e con un tasso di aggiornamento molto meno frequente.Più un sito non si aggiorna, quindi non subisce delle modifiche ai contenuti, più ovviamente l'idea di anticipare il lavoro di build del sito in anticipo e poi fornire l'esperienza di navigazione più rapida possibile agli utenti ha senso.Quindi tutto il movimento dei generatori di siti statici nasce proprio per su questa base e sulla base per esempio anche della sicurezza.Ovviamente non avendo parti in movimento tu riduci drammaticamente i costi perché una CDN costa pochissimo comparato a una macchina che per ogni visitatore deve servire una richiesta.Poi anche da un punto di vista di sicurezza.Ovviamente un file html non lo puoi bucare.Se non sei un senatore americano puoi dichiararlo, assolutamente.Non so se hai visto la news.No no scherzo, scherzavo però hai ragione e poi questa cosa può essere spostata fino ai boundaries, fino ai limiti quando per esempio parliamo di soluzioni come Next dove mette insieme le due cose crea una versione se la tiene in cache invalida la cache se c'è una versione...cioè per soluzioni complesse se si arriva ad avere delle funzionalità avanzate proprio per ottimizzare questo anche perché oggi le prestazioni contano e molta di questa complessità diciamo ce l'ho pure è astratta per cui oggi chi vuole fare un sito se ieri doveva studiarsi come scrivere un plugin o come hackare un tema di wordpress oggi si deve imparare react view e imparare che cosa un API e fare una chiamata fondamentalmente.Poi se usa Gatsby buona fortuna perché capire come funziona il pilastro centrale GraphQL e poi tutto tutto il sistema di generazione con i node qualcosa per generare le pagine è veramente impegnativo quindi mi chiedo se in realtà può essere una soluzione che può essere uno strumento per attaccare anche quel tipo di mercato.Ma intanto vorrei fare una parentesi nel senso anche lì, la potenza di WordPress e la facilità di WordPress è data dal fatto che c'è un ecosistema gigantesco di roba che qualcuno fatto per te, ok? Grazie, sono tutti bravi a patchwork di roba già esistente, però se qualcuno si è messo a lavorare su un tema WordPress o ha provato a sviluppare un plugin WordPress, ok, c'è GraphQL da una parte ma c'è Dloop dall'altra, cioè c'è una serie di concetti molto complessi e non molto amichevoli, anche il lato Wordpress, sommati a un continuo sviluppo sopra questo strumento che va avanti da 15 anni, quindi ci sono una valanga di funzioni che puoi usare però sono deprecate.Insomma, non è quando si tratta di fare qualcosa davvero a mano, più o o meno qualsiasi strumento ha bisogno di un po' di tempo per entrarci e capire come funziona.Ovviamente WordPress vince perché ha un ecosistema gigantesco e un ecosistema altrettanto gigantesco lato Jamstack oggettivamente in questo momento non c'è.Pur se guardiamo Gatsby, io mi sembra di aver visto plugin per tutto, anche per fare il quindi se a questo ci aggiungiamo l'API che in realtà ci sono 70 mila servizi per fare qualunque cosa più o meno ci avviciniamo forse serve ancora un percorso di sviluppo proprio dell'approccio al web verso non tanto gli sviluppatori più avanzati come possiamo essere io, tu, Luca o buona parte della nostra audience ma verso il singolo sviluppatore che fa il sitino della macelleria sotto casa, l'ancora c'è tanta strada da fare in termini di...Certo, questo ha molto a che fare con il fatto che il web continua a cercare di migliorarsi, continua a tirare fuori un sacco di soluzioni, un sacco di concetti che hanno molto a che che si può fare con le performance, con l'ottimizzazione dello scaricamento delle pagine e ovviamente se tu ignori tutta questa roba qua è più semplice ragionare, perché ragioni come si ragionava magari dieci anni fa con HTML, CSS e una spruzzatina di JavaScript.Il problema è che è proprio il web che sta diventando più complicato non è il singolo framework tipo React che complica le cose.Cioè, prova...diciamo anche, ci mettono anche loro un bel carico e fra l'altro le ultime versioni di React, ho temo che si peggiori la situazione, perché quando si inizia a parlare di prova in parallelo, concorrente, insomma, inizia a diventare complessa la situazione.Però, diciamo che se tu non inizi a ragionare di responsive, non inizi a ragionare di cercare di scaricare le immagini alle dimensioni corrette o ottimizzate per la risoluzione, è ovviamente tutto più semplice e puoi fare questa cosa un po' con qualsiasi strumento, puoi andare a segare via parti di complessità perché magari non ti interessano, però è un dato di fatto che ovviamente gli strumenti che nascono oggi cercano di embrace, di abbracciare tutta questa complessità, cercare di inglobarla in una soluzione che sia ovviamente al passo coi tempi.Non ho una risposta per questa cosa, però mi viene da chiederti, questo nuovo modo di vedere il web e di fare web, in qualche modo può aiutare verso un concetto di resilienza del web, cioè il fatto di per esempio spingere così tanto verso delle pagine statiche può aiutare? Non ho una risposta, ripeto.Sicuramente tutto ciò che può essere staticizzato è viva, secondo me, sia da un punto di vista, ma anche da un punto di vista proprio di storicizzazione un po' dei contenuti.Pensiamo alla percentuale di pagine del web magari di 5-6 anni fa che non esistono più, perché nel frattempo è cambiata la tecnologia, perché lo statico è un gran valore, oggettivamente.Ti aiuta in tanti contesti, ti aiuta a semplificare i ragionamenti da un punto di vista proprio di scalabilità e ti aiuta anche da un punto di vista di fare delle fotografie che poi in qualche modo hanno un po' più di vita magari del progetto web medio che magari nel giro di 4-5 anni viene completamente rivoluzionato e nessuna voglia di fare retrocompatibilità sui contenuti passati.E poi soprattutto per la sicurezza, perché come hai detto un HTML non si può bucare, o almeno credo.Un sacco di siti che adesso, Wordpress è nato nel 2003, mi sono informato poco fa e quindi ha comunque, rialciandomi al discorso di prima, ha fatto crescere un ecosistema enorme e si è evoluto anche col tempo, però mi chiedo se il web si sta complicando o lo stiamo complicando noi? Quando hai detto quella frase il web sta diventando più complesso, da un lato è vero, a parte che ci sono tante regole che adesso, soprattutto i browser, Google, Firefox, soprattutto per quanto riguarda la sicurezza ci sta cominciando a mettere paletti sempre più stringenti, però ci stanno anche dando gli strumenti per lavorare meglio.Pensiamo anche alle animazioni che prima si dovevano fare con il plugin di jQuery, jQuery sempre sia lo dato e usatelo per riconoscenza.Adesso con due regoline di CSS lo fai, quindi io da un lato vedo che noi forse lo stiamo complicando un po' troppo, noi stessi il web, ci stiamo creando una sorta di barriera all'ingresso per tutti gli altri, io ho questa sensazione.è la classica un po' polar opinion che adesso verrà fustigato in pubblica piazza su Telegram per questo, però mi piacerebbe avere una controopinione su questo.È un dato di fatto che le cose si stanno complicando e io secondo me non ci si può fare un granché, è anche un dato di fatto che rispetto a dieci anni fa la popolazione di gente che vive sull'Internet è parecchio aumentata e quindi bisogna aumentare i casi d'uso supportati, bisogna gestire un sacco di casistiche che prima semplicemente non esistevano.Il tasso di aggiornamento dei browser, del linguaggio JavaScript stesso avanti a passi da gigante rispetto a quello che era solo pochi anni fa, cioè per arrivare a s5 eravamo lì e sono passati anni prima che si riuscisse a tirarlo fuori.Ora il tasso di aggiornamento, il tasso di miglioria che vengono fatte all'intera infrastruttura, quindi javascript è una parte, ma tutto il resto è incredibilmente ampia e passa dal fatto che ormai le applicazioni desktop a meno che per pochissime cose non si usano.O si usa il mobile, con tutte le problematiche del mobile, quindi chiusura del codice, dover ricompilare perenne sistemi operativi, oppure si va di web.Però se vuoi far passare tutto dal web, è qualcosina che perché altrimenti i web worker, per fare un esempio, prima non servivano perché non c'era bisogno di fare computazioni incredibili all'interno di un browser.Se dovevi fare computazioni complesse, il browser si piantava, aspettavi lì e usciva il dialog di Firefox che ti dice "questa pagina ci sta mettendo un po' troppo tempo, cosa vuoi fare? Bloccarla?" E fine.Ora è tutto molto più complesso.WebGL, avete fatto una puntata qualche tempo fa, e se WebGL è sul browser e aspettarti che funzioni, o il WebAssembly, è tutta roba che prima semplicemente non esisteva.Quindi sì, si sta complicando, non so se noi ci stiamo mettendo anche un bel carico su questa complicazione.Quello che si sta cercando di fare anche lì è cercare, secondo me, di andare nella direzione di offrire un'esperienza al più immediata possibile ai visitatori finali.Quindi anche quello 0,2 secondi in meno per vedere un'interazione, la prima interazione, la prima renderizzazione della pagina.Se vuoi lavorare su questi minuzzi, ovviamente le cose si complicano drammaticamente.Sì, effettivamente io consideravo tutti gli strumenti nuovi come qualcosa che facilitavano, però effettivamente aumentando gli strumenti aumenta anche la complessità e quindi hai pienamente ragione.cambiano anche le esigenze come aumentando la penetrazione nella vita di tutti i giorni di quello che è il web aumentano anche le esigenze e quello che noi chiediamo al web no? Adesso però cambiamo pagina e ti voglio fare una domanda che è guidata dalla mia curiosità.Ma ci puoi raccontare cosa c'è sotto il cofano di Dato? Cioè come fa a funzionare? Almeno quello che puoi dirci.Sì sì ma non siamo la Bicorp quindi non c'è nessuno che ci fustiga se diciamo troppo.Allora Dato è un oggetto che ovviamente come tutte le cose appunto che diventano complesse ha una miriade di derivazioni il cuore pulsante è un'applicazione Rails che gira Procube, quindi zero minate sistemistiche sul 300.000 righe di codice, penso più o meno e che è il cuore dell'intero sistema ed è quello che fornisce l'API al mondo esterno.I dati prevalentemente vengono salvati all'interno di Postgres che regge, devo dire, nonostante noi dobbiamo per nostra natura supportare degli schemi liberi Infatti la mia domanda stava per essere chiara.Esatto, sì.Noi gestiamo ovviamente una delle cose diciamo belle del dienare dell'SMS è quello che tu hai diciamo la possibilità di cucire su misura del tuo sito diciamo i contenuti, no? Quindi hai bisogno di un articolo? Benissimo, non è che ti offro l'articolo fatto in questo modo, tu lo costruisci tu, quindi ti creai un oggetto, un modello articolo e il modello di particolo è una composizione di campi a tua scelta.Puoi scegliere tra un pool di possibili campi e di modalità di presentazione di questo campo.E il backend ovviamente si adatta in tempo reale al tipo di contenuto che tu desideri stoccare all'interno del tuo progetto personale.Per fare tutto questo usiamo incredibilmente Postgres con JSON B, che va come le palle di fuoco, nel senso che oggettivamente pensavamo ci avrebbe dato problemi molto prima, Ora siamo a milioni e milioni di versioni di record perché tutto quanto è versionato puoi tornare indietro alla versione di una settimana fa, per esempio, del record e tutti i dati principali di un record sono salvati all'interno di un'unica colonna JSON B e funziona per quanto riguarda il filtraggio quindi dammi tutti quelli che su quel campo hanno un certo valore eccetera eccetera e insomma, sì, sono stupito anche io di questa cosa usiamo Postgres anche per una parte di ricerca a full text Anche lì con gli stammer, modificando un minimo gli stammer messi a disposizione dei default, anche lì si riesce ad andare molto molto veloce e questo ci permette comunque di avere direttamente sotto all'API di gestione dei contenuti, quindi non la parte di API, ma GraphQL in modalità questa è la lettura che ti serve per interfacciarti al tuo front-end, ma l'API REST che ti permette invece di creare nuovi record, modificarli, eccetera, lì avere un constrain di atomicità sulle operazioni, quindi avere la garanzia che faccio una update e la richiesta successiva sicuramente il dato è aggiornato invece di aspettare che le cache si propaghino, eccetera, è un grosso valore.Sopra l'applicativo Rails abbiamo due strati di cache quindi abbiamo Fastly e sopra ancora Cloudflare per motivi divertenti, che volendo possiamo approfondire [Risate] Allora, diciamo che, per esempio, come si può fare, noi ovviamente dobbiamo far pagare l'utilizzo delle nostre risorse, quindi numero di chiamate API, band, eccetera, eccetera.Una cosa molto semplice che si può fare è mettere sopra la propria API, Worker Cloud, per esempio.Quindi avere delle funzioni che vengono chiamate, che fanno, diciamo, da proxy intelligenti.I worker di Cloudflare sono codici JavaScript, quindi puoi far girare più o meno quello che ti pare.E quindi è come avere, non so, un Nginx che però puoi moddare pesantemente.Quindi tutte le richieste che vengono effettuate, per esempio, all'API, io faccio da passacarte e chiedo all'API REST di darmi una risposta.però nel frattempo per esempio Conto inizia a contare che c'è stata una richiesta da parte di quell'utente o che quella data risposta che abbiamo fornito all'utente ha pesato un certo tot.E tutta questa roba qua, direttamente da Cloudflare, viene sparata a uno Statsd, che non so se conoscete o meno, comunque è un coltivatore di metriche, fondamentalmente, che gira in RAM, quindi molto molto rapido e funziona in UDP, quindi non dà problemi di lentezza e quindi questi worker sono allo strato più esterno e ti danno tutta una serie di utili che ci servono per far funzionare tutto il servizio.Tra Cloudflare e il nostro servizio API almeno per quanto riguarda la parte GraphQL c'è Fastly Le chiamate GraphQL sono problematiche da cachiare.Perché sono problematiche da cachiare? Innanzitutto perché sono delle POST e non sono delle GET.Quindi quello che noi attualmente facciamo è sempre in questi worker Cloudflare, quindi a livello superiore, per quanto possibile cerchiamo di convertire le richieste POST che ci vengono fatte dagli utenti finali in richieste GET.In maniera tale che Fastly riesca a caciarle come sa fare lui.Quindi immaginiamo una specie di Apollo che gira...Sì, ma in realtà è molto...è abbastanza semplice.Non facciamo nulla di troppo complesso, anche perché questi worker Cloudflare devono essere abbastanza rapidi, ci sono dei constraint da un punto di vista di RAM e di CPU, di utilizzo di CPU.Quello che facciamo attualmente è semplicemente prendere il body della richiesta, comprimerlo, gziparlo, e incodarlo ulteriormente in maniera tale che sia compatibile con un URL, un URL in GET, quindi una query string, e poi lo spariamo sotto.Ovviamente se è troppo grande per fare questa trasformazione ci sono poi strati successivi di cache direttamente lato applicativo con Redis che offrono un secondo strato di cache sopra il primo.Ti faccio una domanda Stefano, ma questa è una mia curiosità.Specie con le API GraphQL Tu non hai il problema di verificare quanti livelli sotto vai? Perché avendo l'articolo in JSON-B tu ce l'hai là, giusto? Non devi fare query a relazioni, storie che poi...No, in realtà, diciamo, sono contenuti comunque strutturati.Un MongoDB, per parlare di un database a documenti, non funzionerebbe un granché, perché sarebbero fondamentali per qualsiasi CMS se c'è un campo relazione verso altri record, per esempio.Quindi cerchiamo comunque di avere un database normalizzato, nel senso che ogni record ha le sue informazioni, però ci sono poi degli ID che puntano ad altre risorse, che possono essere collegamenti ad altri record, o magari dei blocchi, diciamo, non li chiamiamo blocchi, comunque sono delle strutture dati che puoi ancora anidare all'interno di un record per creare degli array, una sorta di struttura dati tipo array di oggetti.Mettiamola così.Sì.Sì.E poi cosa c'è? Lato Rails non facciamo nulla a livello di viste, ovviamente per noi è fondamentale offrire tutto quello che può fare dato anche lato API quindi noi siamo i primi utilizzatori, diciamo, delle nostre API e tutta la parte di dashboard amministrativa, diciamo, lato account quindi con billing, eccetera eccetera sia la parte proprio di back-end amministrativo di un progetto sono tutti applicativi in Rails, in...scusate, in React Domanda.Sì.Noi dobbiamo ammetterlo ci siamo già sentiti e nella precedente telefonata però hai citato Elixir.Io l'ho detto a un nostro amico comune, Cost del podcast che è Alessio, Dottor Blaster, innamorato di Elixir come come non mai.Per cosa lo usate il XIR.Questa è una domanda da parte di Alessio.Ciao Alessio, ora ti rispondo.No, lo usiamo per una parte importante però non core dell'esperienza di dato, che sarebbero un ulteriore API che mettiamo a disposizione per ottenere delle e le subscription in tempo reale sull'aggiornamento dei dati.E' ovviamente la morte sua.Quindi avere tante connessioni persistenti, tutte belle lì che sono in ascolto, e qua c'è un trigger che spara direttamente.Non sono WebSocket, ma sono ServerSendEvent, che sono una tecnologia fra l'altro interessante.tutti i browser moderni la supportano senza bisogno di nessuna libreria esterna sono fondamentalmente come dei websocket ma monodirezionali quindi solo dal server al client però sono connessioni persistenti per questa parte qui ho bisogno di fare una query nei dati però voglio poi essere aggiornato in tempo reale quindi voglio per esempio che il mio sito in modalità staging, mettiamola così appena salvo un contenuto all'interno di dato il sito web si aggiorni istantaneamente senza nemmeno bisogno di un reload.Lì usiamo Elixir.Figo, un giorno ritornerai a parlarci di questa tecnologia io me lo sono appena appuntato sappilo.Sì io non sono un esperto di Elixir io sapevo di avere questa necessità No, parlo dei server send event.Si, si, volentieri.E' molto semplice, non ci sarà una grande puntata, però volentieri.Adesso voglio farti una domanda.Heroku, tu hai parlato di Heroku.Io ho appena terminato un progetto lungo sette mesi su Heroku per una startup, un e-commerce che fatturava gozziliardi di dollari e Heroku funzionava tutto sommato bene e soprattutto faceva far soldi che era la cosa con veramente poco effort.Ti chiedo, quali sono stati i big win su Heroku e quali i pain point? Beh, allora, Heroku perché? Perché è uno strumento che conoscevamo, noi per tutto lo stack, essendo tre persone e mezza a gestire duemila clienti, tutto ci serve tranne dell'esoterismo nel codice, ci faccia impazzire più di quello che già facciamo.Ero a cui lo conoscevamo, sapevamo che funzionava e quindi l'abbiamo scelto fin dall'inizio in una fase in cui ovviamente i costi erano ridicoli e ci risolvevamo un grosso problema, cioè quello di essere tranquilli dal lato sistemistico.E di fatto siamo semplicemente andati avanti per la stessa strada finora.Io sono dell'idea che fin tanto che riusciamo a ficcare soldi per risolvere problemi, io sono la persona più felice del mondo.Tutto sta nell'assunto che questa cosa ovviamente funzioni e non ti dia problemi di vario genere.Heroku di base è un strumento molto solido, con un pastore spalle ormai, non si può dire che sia una start up e da un punto di vista di problemi non è che ci ha dato un gran anche da un punto di vista tecnico.I problemi li abbiamo iniziati ad avere paradossalmente da quando abbiamo accettato la proposta di Heroku di passare al piano enterprise.Da lì in poi Heroku nel frattempo non so se lo sapete ma è stata acquistata da Salesforce.qui si inizia a vedere quando si parla di giga corp gli aborti che possono generare da un punto di vista amministrativo.Da un punto di vista tecnico tutto funziona perfettamente da un punto di vista amministrativo è stata la morte.Abbiamo switchato all'enterprise, appena abbiamo switchato all'enterprise non c'è più nessuna dashboard per la fatturazione.mail che ti arrivano minatorie del tipo "non abbiamo ricevuto il tuo pagamento, sospenderemo l'account" o "se entro 10 giorni non pagato" tutto questo pagando, sono mail lanciate a caso per far prendere male la gente.Sono sistemi interni a Salesforce che non comunicano tra di loro.Quindi fin tanto che sei nella modalità sas normale c'è Roku che faceva le cose bene prima e continua a farle adesso.Lato enterprise hanno switchato tutto a Salesforce quindi c'è la banda di sales che in qualche modo fa cose, vede gente e non funziona niente.Con la giacca e la cravata per citare carmi.Ma a parte gli scherzi abbiamo vissuto veramente settimane di inferno perché non si capiva se veramente si parlavano di società di credito che sarebbero venuti da noi a richiedere soldi con tutto già pagato in anticipo e non si capisce con la paura di non sapere ok se i vostri sistemi non funzionano veramente non è che ci buttate veramente giù tutto.Perché in realtà quando tu hai 2.000 clienti, 1.000 clienti e hai come voi avete anche delle grosse aziende che utilizzano il vostro servizio? Allora gestiamo circa 15 milioni di richieste, quindi qui si sta parlando di problemi non tecnici ma burocratici, che vuol dire che ci sono persone dei mezzi, persone che magari sono a fusi orari differenti, che non ti rispondono, che non sanno cosa sta succedendo perché nessuno ha più paura dell'idea di cosa veramente stia succedendo.Quindi da questo punto di vista qua, insomma, panico.La soluzione è stata fare per ora, considerato che comunque l'idea di iniziare a gestire noi la parte sistemistica sinceramente ci fa un po' paura e è stata semplicemente cercare di concordare con loro pagamenti anticipati, garanzia di un risultato da questo punto di vista.Poi casualmente da quando ho tweetato con un thread lunghissimo tutti questi accadimenti il mood stranamente è cambiato, super gentili, super proattivi nel risolvere le situazioni e cedere a Celi.Beh ma questo è normale.Ti faccio una domanda, io sono sicuro che tu almeno per un quarto d'ora, 20 minuti, voi guidato dal driver dell'incazzo, della rabbia, hai cercato soluzioni alternative, io lo so.Certo, certo.Adesso non ricordo il nome del servizio, ma credo che AWS abbia qualcosa di simile a un pass come i Roku, mi è sembrato di capire.Questa è una roba che ho visto tipo ieri di sfuggita.Ci sta che abbia qualcosa, sicuramente una buona parte dei soldi fra l'altro è sul database che è molto grosso e ha bisogno di parecchi giga di ram per fare in modo che tutto giri correttamente, gestisca gli spike di gente che si mette una volta all'ora a aggiornare milioni di record e fare query complicatissime.Quindi il primo step sarebbe quello di provare sicuramente a usare RDS invece di Heroku.Anche lì si tratta di una soluzione completamente gestita con backup, restore point in time, tutto il cucuzzaro.quindi molto probabilmente, visto che è considerato anche che a breve dovremmo per forza gestire uno sharding dei dati perché il mono di B inizia a cedere, diciamo, leggermente molto probabilmente questa è la prima operazione che proveremo a fare.Lato pass, quindi una soluzione completa, non ti saprei dire di preciso.Ci sono soluzioni sicuramente che con docker e tutto quanto ti permettono di avere qualcosa di relativamente semplice in realtà.Il punto è semplicemente che non abbiamo internamente queste competenze, non siamo degli esperti AWS e AWS può essere una brutta bestia con configurazioni incredibili, gli AMOL che ti fanno passare la voglia di vivere.Quindi diciamo che...e considerando anche che la parte di scalabilità da quel punto di vista non ci dà problemi, probabilmente finché funziona tutto rimarremo lì.L'Atlix.Xeer e Roku invece ha delle problematiche perché il singolo nodo ha un limite sul numero di connessioni massime che può ricevere in parallelo, lì ovviamente l'Xeer con 2 giga di RAM ti tiene su 10.000, 20.000, 30.000 connessioni ma Heroku ha un cap sul numero massimo di connessioni penso sia intorno ai 1000, qualcosa del genere più altre problematiche che non lo rendono diciamo, uno strumento ideale.Quindi molto probabilmente un altro pezzo a breve si sposterà sarà quella parte lì, perché ci permette di scalare un pochino meglio.Diciamo che lo slider classico di Heroku, aggiungi il numero di Dino, su Heroku, su Elixir, dove abbiamo tante condizioni persistenti, non funziona un granché, perché molto spesso sbilanci su un nodo piuttosto che un altro, perché un conto se hai tante richieste rapide quindi più o meno si equilibrano.Connessioni persistenti vuol dire che può essere benissimo che c'è un nodo pieno ZEP e un altro invece svuoto e rooting di Heroku che diciamo che uno pseudo round robin non è la soluzione ideale.Comunque è stato fighissimo guardare sotto il cofano non so se Luca ha conviene con me ma è stato bello capire come in realtà un progetto poi scala con delle tecnologie perché noi siamo sempre portati a over engineerizzare qualunque cosa.Dobbiamo fare il nostro sito e allora inizia a pensare ok allora come sistemo le performance del backend ma c'è tre chiamate allora che faccio lo sharing del database ai due utenti chi di noi non l'ha pensato dai ammettiamolo e poi alla fine ci ne diamo conto che il valore generato non segue la stessa linea delle nostre segmentali.No decisamente no.E quindi vedere come in realtà si sono trovate delle soluzioni per la realizzazione di un prodotto che funziona, genera valore sia per l'azienda che lo promuove che per i suoi clienti, insomma è assolutamente interessante.Luca hai qualche domanda? Io ho monopolizzato un po' lo...No no, io come dicevi prima è stato interessantissimo, ho preso un sacco di appunti, un sacco di parole nuove che ho imparato, tra cui questa database, questa parola nuova, no scherzo, i server sent event carini non li conoscevo, anche questo stats che lavora in ODP sotto sembra molto interessante, mi piacerebbe chiederti di più ma forse potremmo anche fare un'altra puntata.Però è stato interessantissimo, al momento mi coglio alla sprovvista, non ho domande perché ero troppo impegnato a immaginarmi tutta la scena, tutta l'infrastruttura di DatoCMS.Io invece una domanda ce l'ho e voglio per un attimo lasciare il mondo della roba tecnica dei nostri giocattoli nerdosi.Per farte invece una domanda sul dato perché so che dato ha un approccio un po' diverso nel senso oggi si parla tanto di start up però l'altro giorno mi dicevi che l'approccio di dato un po' differisce dal classico approccio della start up con una crescita pompata tanti soldi sopra il cofano per fare...cosa è la differenza? Dov'è la differenza? Sì, allora diciamo che per natura, ok? Io non voglio lungi da me contestare o polimizzare il concetto di startup all'americana.Diciamo che per il nostro team, per come siamo noi, per come ci divertiamo a fare le cose, la crescita smodata, l'aumento progressivo di risorse umane, aumentare, aumentare, aumentare, aumentare, scalare, scalare tutto, non ci piace tantissimo.Fondamentalmente ci diverte questa scala, quindi una scala in cui è tutto gestibile e l'obiettivo nostro è un po' l'opposto di quello che normalmente si sente, cioè cercare di rimanere il più piccoli possibile, compatibilmente con quello che è la richiesta del mercato, Ovviamente.Io posso farmi tutti i miei progetti a 5 anni dicendo "Voglio rimanere tre persone e mezza", come siamo in questo momento, di cui tre developer, però se il mio peccato continua a crescere come sta crescendo e continuiamo a raddoppiare di anno in anno, oggettivamente non c'è una strada non si può fare.O chiudiamo tutto oppure ci dobbiamo adattare.Però c'è proprio un approccio un po' differente.C'è l'obiettivo di andare a cercare necessariamente un per 10 in 5 anni a tutti i costi o di iniziare a strutturare un'azienda in maniera tale che inizia ad avere già fin da subito un certo tipo di organigramma con dei ruoli ben definiti eccetera eccetera.Ci piace l'idea di provare a rimanere piccoli, di provare a fare le cose bene, con una grossa attenzione anche a quello che sono i feedback da parte degli utenti, risolvere gli problemi che hanno in produzione nel giro di due ore, contro avere layer e layer, per esempio di strati tra chi ti risponde e l'esperto dall'altra parte.L'altro punto è quello di, se possibile, di non spostare l'azienda in America, perché poi se vai a fare start-up all'americana in Europa è ridicolo.L'unica cosa che ottieni è un quarto dei soldi di quelli che potresti e tenere negli Stati Uniti.E allora però vuol dire spostare tutto in America e a me sinceramente un po' dispiacerebbe.Abbiamo già pochi esempi virtuosi di cose che funzionano.Diciamo che ci piace l'idea di provare a vedere se riusciamo a fare tutto il nostro percorso in Italia, che comunque tanto si dice ma per quanto riguarda il mondo delle startup ci sono tanti strumenti che ti permettono comunque di avere una fiscalità accettabile, assolutamente accettabile e niente più o meno è questo poi non voglio allungarmi troppo da questo punto di vista Gitbar è un podcast di sviluppatori e per sviluppatori e vicini di casa e quindi la mia domanda è questo tipo d'approccio come impatta nella qualità della vita e nella qualità del lavoro dello sviluppatore? Ma allora diciamo che è molto divertente almeno io me la vivo può essere ovviamente stressante come tutto ciò che sta avendo un qualche tipo di successo e quindi c'è grossa richiesta, però di base è molto divertente.Io non potrei mai fare il CEO che sta otto ore al giorno al telefono in chiamate e fa good business con altri soggetti.Non ce la faccio fisicamente, ho l'orticaria nel giro di pochi minuti.Quindi, non è un problema Ovviamente nascendo da me questa cosa prende un po' l'imprinting mio e quindi io continuo a codare come un disperato dalla mattina alla sera, tutti gli altri continuano a codare dalla mattina alla sera.Abbiamo fortunatamente un paio di persone che ci aiutano lato supporto e lato sales, diciamo tecniche anche loro, ed è molto divertente perché abbiamo finito adesso di rilasciare una feature grossissima, diciamo molto complessa, che è la possibilità di avere per esempio blocchi annidati, quelli che ti dicevo prima all'interno di un record, avere queste strutture date all'interno che possono rappresentare per esempio le fascione di una landing page.Una richiesta che abbiamo ricevuto per un anno almeno, la richiesta con più upvotes in assoluto era renderle nestabili a piacimento.Quindi da un livello di blocchi a un albero di blocchi.Divertente.Vuol dire rifattorare completamente il codice, vuol dire vedere, aggiungere test, vuol dire...è bello.Appena finito questo, stiamo già lavorando sulla successiva feature che è una cosa completamente diversa, quindi questa era molto più server-side come tipo di funzionalità.Ora stiamo cercando di lavorare su tutto l'ecosistema di plugin, quindi offrire lato modalità per personalizzare l'interfaccia attraverso dei plugin JavaScript custom, quindi vuoi aggiungere delle pagine, vuoi aggiungere modalità differenti di presentazione di un campo completamente custom insomma.C'è tantissimo...Ci sono tantissime tecnologie, ok? Ovviamente siamo anche sempre a lavorare su tutta questa roba nuova, quindi Next, quindi Gatsby, quindi no? Vercel che continua a tirare fuori roba.Perché giustamente dovete documentare tutte le possibili integrazioni da fare in modo da...solo ma abbiamo client specifici per ognuno di queste cose quindi il modo più semplice e immediato per poterti integrare con ciascuno di questi sistemi.Bello volevo volevo arrivare proprio a quello è una domanda che mi sono appuntato mentre guidavo oggi nel senso l'ho fatta vocalmente non avevo il telefono in mano come ben potete immaginare.Che valore ha un sdk in un contesto di un prodotto headless che ragiona con api rest e GraphQL che sono facilmente consumabili? Ma allora sono due necessità differenti quindi lato api ovviamente quello strato li serve per interfacciarsi col front end e quindi lì non ci sono plug in da quel punto di vista, cerchiamo semplicemente di avere un api GraphQL che sia la più estesa e comoda possibile, quindi per esempio c'è un'immagine che mi applaudi, evitiamo di far ragionare l'utente finale sull'SRC set, il sizes o l'anteprima in blur up dell'immagine prima ancora che l'immagine stessa venga caricata, ti offriamo tutto noi, ok? E questo più o meno cerchiamo di, è l'approccio che seguiamo un po' per tutte le necessità, al SEO, insomma tutto quello che ci può essere.Lato back-end ovviamente lì le cose sono un po' differenti perché ogni azienda ha un po' i suoi flussi, ha le sue necessità specifiche, c'è le sue modalità di gestione della localizzazione per esempio.Quindi da questo punto di vista per quanto noi si provi a cercare di offrire la più ampia gamma di soluzioni, di presentazione e di impostazioni senza far diventare un pannello della NASA allo strumento e ovviamente lo sbocco più naturale è quello di offrire direttamente un'interfaccia plug-in che permetta all'utente finale di farsi esattamente la cosina.Anche perché fare noi una feature è molto più complesso che farla fare a un utente finale perché noi se introduciamo una feature deve funzionare per tutti gli utenti e tutti i casi d'uso e tutti i possibili casi d'uso mentre invece magari fare una piccolezza specifica per quel progetto arcodando qua e là un po' di idee e condizioni capisci che è più semplice per loro è più semplice per noi è più semplice per tutti chiaro, chiarissimo bene, bene, bene guardavo l'orologio stiamo andando lunghi lunghi Quindi è arrivato il classico momento tipico e topico del nostro podcast, il famoso momento "Il Paese dei Balocchi" e quindi io chiedo a Stefano, hai qualcosa da condividere con la nostra community? Che sia esso un libro, un video, un podcast, un...e conduco nel paese dei balocchi.Ah, il paese dei balocchi.Sì, sì, sì.Allora, io ho un libro che non è...Non vorrei scontentare gli host di questo esimio podcast, però non è propriamente per developer, anche se ha delle derivazioni nel mondo di tutti i giorni.È un libricino molto breve, si chiama "The Mum Test".Cioè, il test della mamma.che fondamentalmente parla di come facilmente chiunque di noi, sviluppatori compresi, ci convinciamo, provando anche a chiedere feedback su qualcosa che abbiamo realizzato, ci convinciamo, facendo le domande sbagliate, che il nostro progetto o la nostra idea sia una figata colossale.La mamma che cosa ti dice se gli chiedi questa cosina qua? Cosa ne pensi? Cosa vuoi che ti dica? Ti dice bravo, complimenti, ma che bella idea no? E questa cosa qui ovviamente è estremizzata con la mamma, ma nel mondo di tutti i giorni con i clienti con i quali ci interfacciamo, con i feedback che chiediamo, è a fare le domande sbagliate un attimo.e l'output che esce fuori poi può essere disastroso perché magari perdiamo poi mesi dietro a una certa idea quando in realtà era meglio insomma bere una birra.No è assolutamente figo come come libro e tra l'altro me lo recupero e lo leggo perché proprio il famoso discorso delle ore spese a fare qualcosa il cui valore poi alla fine risulta marginale sia per te e sia per la persona a cui la stai facendo diciamo che la situazione di cui parlavamo prima dell'acquistare il dominio per il side project e lasciarlo da parte può anche essere visto in modo positivo in quest'ottica nel senso che ci si accorge molto presto l'utilità del side project quindi si limita il danno però ci sono certe volte delle situazioni dove ci buttiamo a capofito a scrivere il codice salvo poi renderci conto che l'idea era completamente idiota.Perlomeno io parlo per me non so.Non si può mai sapere però ecco se ti convince del fatto che funziona perché fai le domande sbagliate no, quella parte lì si può migliorare.Fantastico Luca tu hai qualcosa per noi? Allora intanto grazie Stefano per il libro che l'ho in questo momento acquistato, anch'io ho un altro libro, mi piaceva, anch'io ho un altro libro che non è per programmatore, pian piano ho finito tutti i balocchi, mi dispiace, tra poco consiglierò matite o temperamatite, anzi un temperamatite elettrico se non ce l'avete compratelo perché che mi ha salvato nel temperare le cento matite dei miei figli.A parte questo, un libro che ho finito di recente, "L'unica regola è che non ci sono regole", in italiano, Erin Mayer, "Redistincts", è praticamente la storia, la cultura di Netflix, una azienda che è nata spedendo DVD per posta oggi è diventata quella che noi tutti conosciamo.È carino, ovviamente ci sono delle cose che possono funzionare solo in America, cose che non funzionano qui in Europa, neanche meno in Italia, altre cose però sono carine ma hanno dato un po' di spunti interessanti.Basta così.interessante anche questo lo metto nel carrello io la mia paura di questo momento paese delle balocchie è che riempio il carrello di amazon svuoto la carta di credito e poi i libri rimangono o nel kindle oppure nella libreria a casa perché come ben sapete c'è lambda che ormai fagocita ogni millisecondo della mia vita però questa settimana sono riuscito a trovare del tempo perché dovevo iniziare un nuovo progetto dovevo farlo in Vue.js io posso dire che il mio vero amore è React e quindi dovevo fare uno skill up su Vue Vue che non è poi così male adesso farò arrabbiare dai lo voglio fare far arrabbiare praticamente tutti gli ascoltatori di Gitbar che amano Vue io l'ho trovato un po' come i duplo vedendo react come le lego technics dai io sono d'accordo un po' questa è la sensazione però ho dovuto fare sto skill up dovevo farlo in modo molto rapido quindi ho seguito un consiglio che carmene mi ha dato qualche tempo fa e ho rinnovato l'abbonamento a frontend master ho scoperto che ci sono tantissimi corsi di cui molti parecchio fighi l'avevo fatto quando volevo buttare un occhio su Apollo e non riusciva a fare un POC o qualcosa per provarlo e quindi mi ero fatto un corso all'epoca.Ho fatto due corsi di Vue, un totale di otto ore però fatte all'1.5x e devo dire che in giro di 6 ore 5 ore ho visto praticamente buona parte di quello che c'era da vedere su Vue quindi se dovete approfondire argomenti che non sono necessariamente solo frontendo, ho già puntato un corso su Rust che potrei vedere seduto nel cesso quindi se vi fa piacere frontend master è un po' caro perchè l'abbonamento costa 39€ al mese ma credetemi sono ben spesi bene siamo arrivati alla fine di questo episodio tra l'altro sono le 10 e mezza e io non ho ancora cenato tipo o lomino dello stomaco che sta dicendo "ho fame, ho fame, ho fame" comunque devo ringraziare Stefano per esserci venuto a trovare per averci svelato un po' i segreti di DatoCms.Grazie a voi, quando volete ci sono.Vi ricordo che Stefano tu ci sei nel gruppo Telegram giusto? ma certo, quindi pingatelo pure lo trovate nel gruppo per qualunque domanda, insomma io sono sicuro che lui sarà super disponibile.Luca tu questa cosa del temperare le mattite mi ha messo un perore aggiuntivo.Come ti ho detto mille volte ti abituo a piano piano a tutto quello che c'è da fare pian piano si scala la montagna facendo un passo per volta è stato super interessante quello che ci ha detto Stefano e poi fighissimo guardare sotto il confronto di Labrì è bellissimo, è bellissimo ma io davvero ho preso appunti adesso non te lo voglio far vedere no ma te lo faccio vedere guarda sta qui ma sul podcast non si vede magari farò una foto e metterò metterò l'immagine sul penegrama, no, davvero, davvero interessante.Dovremmo farlo più spesso questo di provare a guardare sotto il cofano, è che non tutti si sono così aperti come lo è stato Stefano e apprezziamo tantissimo la sua disponibilità, la sua gentilezza e la sua apertura, dimostra secondo me proprio il concetto di cui parlava prima dell'azienda che ha come obiettivo quello di creare qualcosa in un concetto di sostenibilità e non necessariamente proteggersi per massimizzare il profitto.Cioè si percepisce da questo approccio, per lo meno io l'ho percepito.Comunque io ringrazio nuovamente Stefano, anche Luca per avermi fatto compagnia e aver fatto delle domande puntuali, forse anche più puntuali delle mie.Io vi do appuntamento alla prossima settimana, non fare quelle smorfie però che io poi mi metto a ridere e non riesco a fare la mia.No, invece sì.Io vi do appuntamento alla prossima settimana e vi ricordo come mio solito i contati info@gitbar.it @brianrepo su twitter e il gruppo telegramma no dicevamo il gruppo telegramma, gitbar su telegramma, ma i donatori ci sono stati questa settimana ce li stiamo scordando o non ci sono stati? sto lasciando in silenzio perché qua taglio e metto i donatori della prossima settimana perché per questa settimana abbiamo un'appuntata un altro episodio se no taglio tutto no no no, anche perché devo ricordare del finanziamento del microfono tra l'altro è importante quello che mi hai appena detto per ricordarvi che dalla settimana scorsa è partita la nostra campagna di finanziamento dei nuovi microfoni per gli amatinari.Quindi se vi fa piacere sostenerci mi raccomando entrate nel nostro sito c'è un link donazioni trovate un modo insomma per darci una mano.Detto questo io vi do appuntamento alla prossima settimana ringrazio di nuovo Stefano ringrazio di nuovo Luca e alla prossima.Grazie a te.Ciao.Ciao ciao GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
