Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori.

Ormai Natale è andato, il mio digital detox ha raggiunto la fine e ahimè sono riapparso, ho riprovato a usare i social, cosa che in realtà non sono bravo a fare, ma oggi vi anticipo che avremo uno dei ninja di questo topic, almeno per quanto riguarda i developer e parleremo con lui insieme a Leo e Carmine.

Ciao ragazzi, com'è? Ciao, tutto bene, il digital detox è andato bene, però adesso ci siamo dentro fino alle spalle.

Non vi siete fermati? Io ho proprio spento tutto.

Sì sì, anch'io ho spento tutto, il problema è quello che c'è fuori.

Io vi svelo un segreto, avevo deciso di fare digital detox, quindi ho veramente usato pochissimo il telefono, non mi son portato il computer appresso, però praticamente il mio tempo libero l'ho speso leggendo Rust in Action e quindi è stato un digital detox analogico, però non troppo lontano dal digitale, quindi una roba un po'...

non saprei come definirlo, forse potremmo coniare un neologismo per questo.

Hai allargato la comfort zone, cioè sei rimasto nei tuoi topic però senza troppi schermi.

No, esatto, ho capito niente, quindi...

Come andare a un museo, vai lì, non capisci nulla, però ci sei andato.

Si metti la sciarpina e dici, questo è interessante, giusto per...

no, per darti un tono, no? Questo è un po' il mio tentativo.

In realtà ci sto provando davvero, poi nelle prossime puntate vi racconterò la mia odissea con Rust e ne parleremo un po' anche oggi, perché oggi parliamo di informazione, di personal branding e in realtà ritornata a studiare da zero un topic mi ha messo davanti una serie di sfide che in realtà non vivevo da un bel po', quindi ciao.

La puntata di oggi è tutta da scoprire, ma prima di iniziare io direi che vi ricordo rapidamente i nostri contatti, infochiocellagitbar.it, atbrainrapple su Twitter...

sto dimenticando qualcosa? Stai dimenticando di contattare Carmine su Telegram che vi dirà...

Ah, finalmente questa musica è finita.

Lo dico a tutti, se avete un gruppo punk rock che possa registrarci la nuova musichetta e togliere via questa schifezza, la tiriamo via.

Lanciamo rapidamente la sigla.

Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.

Il più conosciuto dei formatori in ambito IT, la personalità social più presente in assoluto, abbiamo con noi Fabio Biondi.

Ciao Fabio! Ciao ragazzi, buonasera.

Grazie dell'invito.

Guarda, ci abbiamo messo un po' ad avverti qua, ma sono super super felice di condividere con te questa birra oggi.

Intanto la mia prima domanda è, come stai? Tutto bene, ma in realtà un po' stanco perché in realtà non ho staccato, come hai fatto tu, anche se staccato appunto come hai detto in modo analogico.

Quindi ci ho dato un po' dentro, poi magari ne parliamo un pochino.

Però comunque tutto bene, tutto bene, grazie.

Anzi felicissimo di essere qui.

Ci avete messo 150 episodi per avermi, però felicissimo.

Eh vabbè sì, mea culpa, facciamo facciamo mea culpa.

In realtà avremmo dovuto avverti prima, però abbiamo aspettato un po' proprio per fare una puntata sulla formazione.

Volevamo fare una puntata specifica su questo topic proprio perché la formazione è un elemento ricorrente nelle nostre discussioni, nel senso che oggi nella nostra community ci sono persone che si formano in ambiti diversi, anche i senior si formano, quindi il discorso della formazione ritorna a tutti i livelli della ladder a livello di carriera e riuscire ad avere un modo sistematico per formarsi è anche quello che contraddistingue chi riesce a raggiungere più rapidamente un obiettivo da chi riesce a raggiungerlo con più fatica.

Ad oggi nel mondo della formazione IT, o in generale nella formazione front end, quindi riduciamo un po' lo scope, quali sono le difficoltà più grandi che vedi? Eh lì bisogna distinguere se si parte già da un livello, quindi ovvero si parla già con programmatori che sviluppano e bisogna quindi formare su altri linguaggi o se si parte da zero, che quindi i classici bootcamp per imparare a programmare, diciamo così.

Quindi in quel caso lì, in quest'ultimo caso, mancano già le basi, quindi in realtà è molto più complesso il percorso.

Nell'altro caso in realtà ci si scontra con problemi di solito di sintassi e di paradigmi completamente diversi, per esempio la maggior parte delle persone che insegno vengono da Java,.NET, si trovano più o meno a loro agio con magari un typescript rispetto a usare un semplice javascript, piuttosto utilizzano molto più facilmente un Angular perché esposa il più, in realtà virtualmente il paradigma ad oggetti, però comunque si trova subito di fronte a una classe, quindi magari per loro è più familiare decoratori, vi dicendo, rispetto a per esempio l'utilizzo di React, dove è completamente magari diverso.

Quindi non c'è come sempre la bruttissima risposta che posso darti e dipende dalle circostanze.

Quello che manca sempre, diciamo di fondo, è proprio di solito la base, però quasi a qualunque livello si tende spesso a non avere una base solita sul linguaggio, banalmente, che è javascript e typescript nel nostro caso, e nel voler subito partire con i framework.

Siccome sappiamo che javascript non è questo gran linguaggio, insomma non è basato su delle fondamenta proprio solide, alla fine si sta poco ad avere un bug dovuto a reference o ad altri problemi, magari che sono dovuti, ripeto, a questo linguaggetto di scripting che si è evoluto nel tempo, però ha un po' i suoi limiti.

Quindi di solito si tende a tralasciare un po' le fondamenta, questo è un po' se vogliamo il problema fondamentale.

Javascript è il linguaggio democristiano, un linguaggio basato sul compromesso, però devo dire che tra me e Leonardo hai due amanti spassionati di javascript, anche se tu Leo lo tradisci ogni tanto con PHP se non mi sbaglio.

Sì, sempre meno, per motivi di lavoro, diciamo mi sto adattando a dover utilizzare javascript, anche se io sono un grande amante dei linguaggi tipati, quindi diciamo mi sono adattato, mi sono lasciato prendere dal flow, però vorrei qualcosa, cioè io java l'ho studiato solo all'università, ma mi sarebbe piaciuto anche lavorarci.

Ok, l'ho detto e mi muto.

Cosa ho sentito io? No, è come quando uno viaggia per lavoro, dici ah sarebbe bellissimo farlo, poi parli con la gente che viaggia per lavoro e basta, dici è una merda, perché sei sempre in hotel, c'hai il colesterolo alle stelle perché mangi sempre al ristorante e tutti i soldi che ti danno non li puoi spendere perché sei sempre in viaggio, quindi lo dico solo perché non l'ho fatto.

Io ho una domanda per Fabio, proprio su questo, quando tu dici è necessario solidificare le basi e io nelle basi ci metto anche tutto ciò che riguarda il problem solving, perché il mio modo di vedere il codice è quello di vederlo come un tool per il problem solving, cioè il codice è lo strumento che noi utilizziamo per fare problem solving, quindi dobbiamo essere in grado di fare problem solving.

Adesso lo dico da ex formatore, cioè da persona che ha avuto una parentesi per quanto piccola della sua vita sulla formazione, cazzo, una delle cose più difficili da dire a chi stai formando è hai bisogno di queste basi, basi che non sono entusiasmanti talvolta e che sono le classiche basi che fanno scendere il latte alle ginocchia, tipo che ne so qualche cosa degli algoritmi, tipo un po' di problem solving, sapere queste cose.

Ecco tu da formatore come ti poni? Cioè hai trovato un modo per dirlo, per addolcire la pillola? Ma guarda fortunatamente io parto dopo, nel senso che io comunque insegno le aziende a team che già programmano, quindi non mi occupo di tutta la parte di bootcamp iniziale, cioè faccio anche di bootcamp ma su determinate verticalizzazioni o comunque determinate tecnologie, quindi ho la fortuna e lo dico anche spesso di non dover insegnare a programmare, perché non saprei farlo, secondo me è un altro mestiere e quindi tutta quella parte lì sai, la si impara di solito o alle superiori se scegli una direzione tecnica o in realtà non ci sono problemi se uno ha fatto università dall'ingegneria all'informatica, quindi già comunque sono abituati ad avere una certa elasticità mentale, al contrario invece è molto difficile vedo per tutti i ragazzi che vengono fuori appunto dalle famose bootcamp e academy, quelle che ormai sono molto famose e quindi lì è un po' un problema, però per fortuna non è un mio compito e più che altro ogni tanto mi scontro su questo problema nelle community e allora lì sì che magari effettivamente noto che è molto difficile, anche perché poi sapevo bene che tante volte magari basta ragionare un po' di più su un problema e poi in realtà il codice si scrive quasi da sé, se uno alla fine, meglio pensarci magari quella mezz'ora in più che non invece scrivere codice da subito pensando di essere più veloci nel farlo e questa cosa è a tante volte proprio oscura, è qualcosa che non esiste proprio, quindi mi rendo conto, concordo con te sul problema, però per fortuna per lavoro non ci sbatto la testa.

Domanda, perché a questo punto viene naturale, nella puntata di Natale, la puntata speciale di Natale, ho fatto un inciso dove parlavo del famoso read the fucking manual, tu Fabio l'hai sentita dal vivo a Bari quel pezzettino, dove che ragazzi dobbiamo ammetterlo talvolta nel mondo delle community leggiamo delle domande dove la risposta ci viene quasi automatica senza essere cattivi, senza essere provocatori, però ti viene automatico da dire cacchio c'è la documentazione, sta là, ecco esiste un modo per controllarsi dal dare questa risposta, cioè almeno tu in tanti anni di attività nelle community hai sviluppato un modo tuo per autocensurarti dal...

No, in realtà non gli rispondo proprio con l'acronimo di read the fucking manual che è un pochino effettivamente poco delicato, ho notato che effettivamente anche su uno scherza bisogna sempre stare attenti alle sensibilità di ognuno, qualcuno si offende proprio se uno gli risponde male, ma anche prima guarda, in una volta in maniera gentile un ragazzo mi ha chiesto delle informazioni su quale percorso fare per iniziare a lavorare nel mondo web e io gli ho proposto due cose, in particolar modo React era prenditi dei corsi Udemy e leggiti la beta doc di React, questa è stata la mia risposta che effettivamente è sottovalutata, ma per quanto mi riguarda in realtà il primo punto da cui parto è sempre quello alla fine della documentazione, però in modo gentile non c'è, magari lo si dice senza insultarlo troppo, velatamente però non ho ancora questa...

poi anche io, guarda che non è che sia questa grande...

non ho questa grande pazienza come dovrebbe essere per uno che fa formazione o che gestisce community, quindi ho molte difficoltà a tenermi, non so alcune risposte che dovrei dare, però insomma cerco davvero di essere pacato alla fine di dargli, più che altro semplicemente do le informazioni che reputo utili, leggi la documentazione, comprati un po' di corsi Udemy, scorda, l'ho fatto pubblicità, poi bippami...

qua facciamo pubblicità a tutto e tutti, ma chi se ne frega, siamo un posto libero, magari lo chiamiamo come sponsor per Gitbert o forse no, Udemy comunque sia, lo cito molto spesso perché è molto economico, quindi non stai proponendo a qualcuno una soluzione che ti costa centinaia di euro, chiunque chiunque può investire 10-15 euro per prenderci un corso, e non ci sono scuse, questo è il punto, non ci sono scuse per dire non ho budget, 10 euro li tiri fuori, e quindi sono i primi punti da cui iniziare, soprattutto quando uno non ha magari ancora molte skill, quindi non sa, il problema è un altro, che non si sa come studiare, perché uno che arriva da un percorso universitario magari ha già un proprio metodo, negli altri casi, oggigiorno magari ci sono dei ragazzi che arrivano dalle superiori o anche prima, ultimamente, ma vale anche per chi in realtà ha già fatto un percorso universitario talvolta, il problema è non sapere come approcciarsi allo studio, magari alcuni perdono tempo sui fronzoli magari, andando troppo nel dettaglio e magari per mesi e mesi e mesi si studia senza mettere in pratica nulla, altri fanno il percorso contrario, magari vanno subito a produrre qualcosa, scrivono subito codice senza avere le basi, quando invece sarebbe bastato guardarsi la documentazione, farsi un'idea in generale di quello che offre un linguaggio, un framework, una libreria per non dover reinventare la ruota, nel senso che molto spesso uno tende a fare le cose quando a reinventare tutto un processo, inventarsi qualcosa che in realtà esisteva già nel framework, magari con due righe risolveva il problema e quindi lì si nota subito la carenza di formazione e di preparazione quando vedi queste cose.

E' questo il problema in realtà, più che altro è educare allo studio, non so neanche io come definirla questa cosa.

Ecco, e credo che sia una delle cose più difficili, è il problema più grande che io oggi ho studiando Rust, cioè per quanto Rust sia un mondo, possiamo dirlo, con uno scopo un po' più contenuto di JavaScript, che tipo è San Paolo durante il Carnevale, no? No, è Rio durante il Carnevale, non so perché c'è San Paolo in testa.

È Rio durante il Carnevale, il mondo JavaScript è rumoroso, sempre brulicante di nuove robe dove orientarsi, però alla fine qual è il metodo che si può utilizzare per essere pragmaticamente effettivi poi nello studio? Cioè mi leggo la documentazione ma come fisso i concetti? Mi metto a fare un POC? Sì, vabbè, ma mi sto perdendo un certo livello di informazione che mi permetterebbe di andare più veloce.

Quale delle due strade prendere? È complesso.

Io ho un mio approccio che cerco anche di trasferire poi in generale quando faccio formazione.

Secondo me, però ripeto sempre ovviamente la mia umile e inutile opinione, è quella, l'approccio migliore è quello di cercare di assimilare i singoli concetti, no? Io cerco sempre parlando di un linguaggio, di una tecnologia, di affrontare tema per tema, come può essere capitolo per capitolo di un libro per capirci o comunque sia delle API e cerco di comprenderle.

A quel punto mi creo dei piccoli snippet degli esempi che sfruttano nel modo specifico quella, quella, quelle API, quel contesto, insomma quel tipo di informazioni che mi sono studiato in quel momento.

Poi una volta creato degli esempi, penso di aver comunque assimilato il concetto, vado a quello successivo, vado a quello successivo.

A un certo punto poi dipende un po' da che cosa sto studiando, da quanto è complesso o meno, o da quanta roba c'è da studiare.

A quel punto dopo un po' cerco di metterla in pratica con un micro progetto, un micro progetto che talvolta può essere stupido, cioè semplicemente qualcosa di inutile, un piccolo time track, ma senza neanche la necessità di completarlo, no? Un piccolo time tracking, una micro applicazione che fa qualcosa, poi dipende a che cavolo stiamo studiando, no? Ovviamente se stai studiando RAS probabilmente non farai quello.

Però a un certo punto quello che dicevo prima, no? Manca una volta le fondamenta e questo vale anche quando studi una libreria, un framework, no? Ci si mette subito a sviluppare e magari si conosce il 10% di una specifica funzionalità e si esclude tutto il resto di chicche e di informazioni che conoscendoti avrebbero semplificato la vita notevolmente.

Questo perché non si apre la doc, appunto, perché in realtà quasi qualunque framework o linguaggio ad oggi per quanto riguarda il front end ha tutto quello che ti serve online, nella documentazione ufficiale e la puoi prendere da lì.

Alcune cose magari più avanzate a volte non sono neanche documentate tanto bene, però il problema è che molto spesso sfugono proprio le basi, no? Quando avresti veramente tutto quello che ti serve.

Allora, quello che dicevo io è, cerco prima di mettere i tasselli, no? Del puzzle, alla fin fine, studiandomi argomento per argomento, poi metto tutto insieme.

L'ideale poi alla fin fine è quello di farlo sfociare in un micro prodotto.

Facciamo l'esempio di recente di cui abbiamo parlato anche insieme, il blog Astro, no? E altra tecnologia Astro.

Alla fin fine, dopo aver creato un po' di micro progettini stupidi, un po' di esempi, avendo letto ovviamente tutta la documentazione, alla fin fine mi sono detto dove la posso applicare se effettivamente poi reputo che abbia senso utilizzare da qualche parte.

E' il mio blog.

E allora lì ovviamente mi sono messo a svilupparlo da zero e ho dato anche un po' un senso, no? Anche allo studio, no? Nel caso di Svelte, Svelkit che di recente ho studiato, invece non è che mi abbia esaltato più di tanto la tecnologia, però volendo mettere in pratica qualcosa mi sono sviluppato un mio piccolo video player per i miei, una sorta di piccolo Netflix di Fabio Biondi, nel senso che da lì puoi consultare tutti i miei video di YouTube organizzati in modo diverso, mixando un po' le playlist, cosa che invece trovo un po' limitato su YouTube.

Però, sai, ho speso 4-5 giorni, no? Ho sbattuto la testa, ho avuto modo anche di farmelo non piacere ulteriormente poi, no? Grazie a questa esperienza.

Però tu hai detto, prima mi sono, ho fatto sedimentare quelli che sono i concetti base, no? Del tool, del framework, della libreria, di quello che è, insomma.

Sai, per me, mettendo da parte la mia esperienza con React, che è stata completamente diversa, è stata un po' atipica, l'ho raccontata in una precedente puntata del podcast, perché con React mi sono studiato tutta la documentazione, ho studiato a fondo, ho fatto due POC e poi ho ottenuto due corsi di React.

E quindi, preparando il corso, ho dovuto studiarmi la documentazione, però non sono più riuscito a fare la stessa cosa.

Ti faccio l'esempio di Rust.

Ho provato a leggere il manuale, ma ho visto che questi concetti, se tu non ti fermi e non li trasformi in esperienza, che può essere il tuo snippet di codice, ecco, volano via.

Cavolo, mi capitava di rileggere 70 volte la stessa cosa a distanza di una settimana.

No, tipo, una settimana mi studio un argomento, che sono, cosa ne so, i...

come funziona i lifetime su Rust, per esempio.

Adesso ce l'ho fresco, quindi mi viene quello.

Ok, la settimana dopo, magari mollo per una settimana, ma la settimana dopo devo riprendere da capo e mi devo ristudiare quel concetto.

E così, via via, finché non si sedimenta.

Alla fine mi sono ritrovato completamente bloccato, cosa che invece non è successa nel momento in cui mi sono messo a fare un POC, che è un semplice web service, davvero due rotte cagate, sono due rotte cagate, dove però ho sbattuto, ho sbattuto il muso contro il problema e a quel punto il leggere la documentazione, per me, ha assunto un valore completamente diverso.

Mannaggia, era un'altra documentazione.

E quindi mi chiedo, ma allora non esiste un metodo e soprattutto come cavolo faccio a essere rapido in questo? Perché in realtà facendo il POC io ho visto che ho rallentato tantissimo l'ingestione di concetti, ma nello stesso tempo li facevo sedimentare.

Questa cosa mi ha fatto notare una roba molto interessante, che è ciò che sappiamo, e l'ho già detto da qualche altra parte nel podcast, ma ciò che sappiamo non corrisponde con ciò che conosciamo.

Scusatemi, ti interroppo però, può essere anche che in questo caso stai confrontando un framework di un linguaggio che già conosci con un nuovo linguaggio di basso livello, dove probabilmente sono concetti non nuovi, però un pochino più più profondi, per cui ha bisogno anche di questa esperienza, come dire, tattile, piuttosto che solo leggere la documentazione.

No, Leo, guarda, ti posso...

secondo me no, e ti spiego perché.

Posso farti lo stesso esempio, mi è successa la stessa dinamica quando per la prima volta ho guardato Redux usando le saga.

La prima volta che ho visto quella roba, che adesso non me ne vogliano i backender, ma ha un livello di complessità che io percepito molto più alto rispetto a tanti back-end che ho visto nella mia vita, no? Perché banalità, devi conoscere come funzionano bene le saga, non è banale e soprattutto Redux di per sé, proprio come concetto, non è banale.

Fate un esperimento, prendete il primo back-ender che conoscete e gli dite, gli fate vedere Redux e gli dite, mi sai leggere a primo colpo d'occhio cosa fa questo pezzo di codice, vi manda a cagare, ma alla velocità della luce.

Esperimento fatto, è timbrato, in più circostanze.

Quindi in realtà il problema non è del nuovo linguaggio, è proprio il problema di approcciare dei paradigmi, no? Al di là del frame, cioè React è un paradigma, tu o lo capisci o non lo capisci, però in quel caso la pragmaticità di sbattere il muso contro il problema diventa un elemento che ti permette di comprendere profondamente quel problema.

Il vero, la vera cosa strana in realtà è che questa è una contraddizione, perché se noi prendiamo dei libri di psicologia, che ho studiato qualche tempo fa quando stavo approfondendo tutte le teorie del carico cognitivo, i libri di psicologia, specie gli studi di Sueller, ci dicono che noi non possiamo, cioè la parte del cervello, della capacità cognitiva utilizzata per risolvere un problema, si overlappa con la parte della capacità cognitiva che viene utilizzata per apprendere.

Questo vuol dire che noi non possiamo apprendere concetti risolvendo un problema.

E questo è uno studio di psicologia cognitiva, ma nel nostro contesto mi sembra proprio che sia tutto il contrario.

Però prima di applicarlo l'hai studiato, quindi l'hai fatto in una fase precedente in realtà, nel tuo caso.

Quindi almeno hai letto prima la documentazione, poi la metti in pratica.

Quindi in realtà quando la stai mettendo in pratica, in questo caso che hai citato anche tu prima, che poi è anche identico a quello che più o meno menzionavo io prima, la stai consolidando in quel caso, la stai apprendendo.

Almeno io lo intendo così.

In realtà per esempio un approccio che ho trovato utile in alcuni casi è quello di partire da un Hello World, un pezzo di codice di esempio, che è quello che sto facendo con Rust per il web service.

Una volta che incontro qualcosa che non comprendo o che ho un problema che non riesco a risolvere, a quel punto vado sulla documentazione.

Qual è il problema? È che là non hai un learning path definito, cioè là stai saltando di palo in frasca e quindi sei tu che poi devi riorganizzare le informazioni.

Diventa una cosa parecchio dispendiosa, però nel contempo c'è quello che possiamo chiamare stickiness, dato dall'obiettivo che ti stai ponendo.

Perché se tu dovessi leggere solo il libro, solo i concetti fondamentali della documentazione, probabilmente se sei uno come me, al terzo concetto ti romperesti i coglioni e molleresti tutto.

Perché mi sono letto tutta la documentazione di React prima di fare il POC? Semplicemente perché l'obiettivo era preparare il corso e quindi quella roba la dovevo conoscere, cioè dovevo preparare le lezioni in funzione di quella roba.

Se avessi dovuto fare un progetto, probabilmente non sarebbe stato quello l'approccio.

Insomma, questo pippone per dire non ho alcuna idea di come cazzo si impara una tecnologia.

Fabio, tu approcci a diverso tipo di documentazioni, nel senso quando prepari un corso, tu hai detto la prima cosa che io faccio è mi cerco quelli che sono i concetti basici, le radici di questa nuova tecnologia e faccio in modo che mi possa sviluppare delle strategie di insegnamento per farsi dimentare questi concetti.

Ecco, la fonte che ci hai citato è la documentazione.

Per quanto riguarda invece la documentazione, cosa vedi dalla documentazione di tool e dei framework moderni, come la vorresti o quali sono le carenze che percepisci? Allora, innanzitutto una piccola ancora aggiunta a quello che avete detto prima, perdonami, ma poi si collega a tutto il discorso.

La documentazione non la leggo una volta sola, quindi è importante dire quello, la leggo più volte e più volte anche nel tempo, negli anni, perché comunque viene aggiornata soprattutto quella di framework o diciamo tecnologie che ovviamente sono molto attive dal punto di vista della community, del team, dei maintainer e quelle più piccole magari fanno un pochino più fatica.

Tornando al discorso anche un attimo di prima, il problema molto spesso è che se uno legge una parte della documentazione, così mi ricollego anche l'ultima domanda e arrivo, faccio un esempio stupido, alla comunicazione auto frontend con una API REST e devo iniettare un token perché a un API mi serve il token o un API key banalmente.

Alla fin fine, se io sono arrivato al capitolo di comunicazione con il server, userò quello approccio, ma se avessi aspettato quattro capitoli più in là avrei visto che esistono tipo gli HTTP interceptor che intercettano tutte le chiamate e trovo un unico punto in cui gestire gli errori, o iniettare il token in modo da non doverlo fare ogni volta.

Quello che voglio dire è che va benissimo secondo me il discorso di andare a fare subito un POC o appunto sviluppare qualcosina, ma ok, dopo bisogna andare avanti e probabilmente nell'arco di una settimana o un mese quella POC l'avresti sviluppato in modo totalmente diverso.

Perché il problema è che se uno si riesce a studiare tutta la doc, ma anche non solo parlo della doc, anche proprio API intendo, andarsi a vedere cosa offre il framework nel momento in cui c'è un problema tu non rispondi con un'unica soluzione che conosci, ma puoi attingere da un ventaglio di soluzioni maggiore, già lato angular per fare un componente posso avere o gestire un determinato problema, potrei avere 5, 6, 7 approcci e quale si sposa meglio, non lo so, devo scalare, forse è meglio questo, deve essere una libreria, forse è meglio quest'altro approccio, e quindi questo è il problema secondo me nel non approfondire, questo non vuol dire che da subito, perché anche Carmine aveva ragionissimo quando diceva ci vuole una gratificazione, è chiaro che se io studio, studio, studio e non sviluppo nulla dopo un po' mi annoio, però l'approccio che io in realtà seguo anche non per la didattica verso gli altri, ma per me stesso, è quella di, e qua rispondo un altro a tua problematica, rispondo insomma, ti dico quale cosa faccio io, a quella che dici, dopo una settimana mi dimentico, io ho tutto un sistema di note, di appunti dove sono infiniti, uso Gitbook per esempio per organizzarle in libri, sotto categorie, a sua volta gli articoli in altre sotto categorie, e praticamente mi salvo quasi qualunque cosa faccio, ma non quando faccio così tanto per fare, ma se mi studio e form, probabilmente perdo una settimana solo su quello a capire come gestire form, con dentro form, validazione sincrona, di gruppo, del singolo controllo, form array e via dicendo, cose che in realtà solo spiegarle ci potrei perdere tre giorni, figuriamoci ad impararle, quando in realtà vedo spesso in realtà persone che usano i form, flat, quattro campi di input, poi nel momento in cui si devono incastrare più cose, si reinventano la ruota, ma se avessi studiato i validatori asincroni, il fatto che ci sono i form array, dicono due cose a caso, probabilmente non avreste dovuto reinventare la ruota, rifare a mano validazioni che erano automatizzate e via dicendo, e questo devo dire che a me nel tempo ha ripagato molto, oltre al fatto che se domani faccio React, lo faccio per due mesi, tra due mesi ritorno sui miei appunti e ho tutto.

Infatti quello che prima non ho menzionato è che spesso quando parlo di fare degli snippet, intendo realizzare quelli che in alcuni casi chiamano kitchen sink, non so se avete presente, però sono dei repo dove per esempio devo creare multipagina, già li imparo il router, perché devo creare una pagina per i form e lì faccio magari form con delle sottosezioni, e tra l'altro imparo a fare router con sottosezioni, dopo di che passo all'altro argomento, i componenti, ma in uno integro una libreria esterna, in uno faccio qualcos'altro, cioè mi creo tante piccole casistiche, questo è un po' difficile per chi è principiante, obiettivamente, perché non sa da dove iniziare, ma se uno ha già un po' di esperienza, devo studiarmi un nuovo framework frontella, però c'è lo stesso praticamente, parto dall'ABC, vedo quello che ho fatto prima in un altro framework, dico come lo risolverei con quest'altra tecnologia, c'è la possibilità, non c'è, devo reinventare la ruota, o è già prevista.

Allora per questo secondo me la documentazione è importante, e come hai detto tu, non basta una volta, quando dopo ci hai lavorato un po', alla fine, se la rileggi di nuovo tutta, assume tutta un'altra visione, effettivamente, comprendi quelle sfaccettature che prima magari avevi tralasciato e che invece magari sono fondamentali per fare lo step oltre.

E quindi, solo per questo ci tenevo a puntualizzare questo aspetto che prima in breve l'abbiamo un po' banalizzato, però è tutto un percorso che richiede tanto tempo, in effetti, e fatica, anche solo per la stesura di questo materiale.

Adesso sono quattro giorni che sto ristudiando la parte di testing in Angular, che è una vita che non faccio, perché ultimamente mi sono focalizzato solo su React da quel punto di vista, e sono quattro giorni che creo tutti gli snippet, provo le varie… ecco, praticamente quello che ho fatto in React per Cypress e per Unit Test, quindi end-to-end test e Unit Test, lo sto replicando pari pari per Angular, perché tanto sono problemi che ho già affrontato da una parte, e a quel punto dico, beh, come li affronterai da quest'altra, come testo un componente? Allora, alle volte, anche se con qualcosa non mi serve domani, però affrontando oggi il problema e messa nel cassettino, innanzitutto quando mi si porrà di nuovo davanti, dico, ah, però io l'avevo già fatta sta cosa.

Il problema è come l'avevo fatto? Allora, se mi sono salvato, anche non serve degli appunti in un Gitbook o in una Notion, basta anche avere dei repository ben organizzati, alla fine, un bel repo dove gli esempi sono ben classificati, con dei nomi, o c'è una piccola guida che è in ritmo iniziale, che ti fa capire cosa tratti in quel repo, e già anche quello è importantissimo, riutilizzo non tanto dei componenti, ma riutilizzo delle nozioni che ho imparato in qualche modo, anche perché se no uno si dimentica, soprattutto se poi cambi mille volte frame o linguaggio, o quello che è.

Quindi perdonami, ho divagato un po' su questo aspetto.

No, no, no, era un po' quello che volevo sapere da te, nel senso che mi incuriosiva.

Tra l'altro, così, mentre parlavi pensiero laterale, ho lasciato la mente libera di volare tra le parole che dicevi, e ho visualizzato questa situazione, in realtà, proprio quello che dici è, io scrivo il codice, poi ritorno più volte nella documentazione, perché potrei implementare il form in un modo completamente diverso, no? Perché magari leggendo il capitolo 7, 8, x, 10, 1000, capisco che il tool che sto usando mi mette a disposizione una serie di utilities che mi semplificano la vita.

Nella mia esperienza professionale, ho trovato utilissime le code review per questo tipo di cose.

Cioè, io ricordo ancora i calci nel culo che ho preso in alcune code review, perché utilizzavo con la zappa alcune caratteristiche del linguaggio, caratteristiche del tool, e mi si diceva, no, guarda Mauro, read the fucking manual, io chiedevo, sì, vabbè, ma quale parte di questo dannato manuale che sono 2000 pagine, mi dicevano, guarda, approfondisci questo capitolo, e a quel punto, diciamo, c'era il trigger più forte, lo stimolo più forte per poter fare questa cosa.

E adesso mi chiedo, dato che abbiamo gpt3, abbiamo codex e quant'altro, probabilmente un uso intelligente di questo tipo di tool potrebbe essere una sorta, non so se esiste già, perché se esiste già sarei curioso di andarla a vedere, una sorta di code review automatizzata che basta che in funzione delle funzionalità che tu metti nel tuo codice ti rimanda alla documentazione scritta da un uomo per un uomo, no? Quindi è solo una sorta di linker che collega questi due mondi.

E a questo punto, vedi, si andrebbe a colmare quel gap tra going deep e soddisfazione immediata, così no? Giusto un volo pindarico provando a immaginare qualcosa.

Prego, scusami, anzi.

No, no, vai, vai, vieni a sedere.

Posso dire una cosa? Li dipende, però se parliamo di sintassi probabilmente ce la può fare senza problemi, però se parliamo a volte di utilizzare un approccio idiomatico, per esempio quando applichi il paradigma funzionale, o nel caso mio, per esempio, il paradigma reattivo, quindi con re.js, gli observables, sai lì non è proprio una questione di sintassi, è anche un po' subito alla volta, no? Trovare appunto quale può essere il punto non ottimale del tuo codice, perché è una questione di approccio, no? Anche se vai a applicare un design pattern, penso sia difficilissimo trovare appunto, che non so, per quanto riguarda un'intelligenza artificiale, trovare quale può essere la magagna o il problema che appunto, perché magari non hai seguito il pattern nel modo corretto, perché implica tante più cose insieme, no? E quindi quello sarebbe figo, quello sicuramente.

Ecco, adesso lo dico, cazzo GPT3, visto che sei così figa, risolvilo sto problema adesso, risolvilo.

E tra l'altro, sì, ma tra l'altro a parte che lo sto usando quasi quotidianamente, no? Per tutti i lavori noiosi in realtà, convertimi la data di YouTube in un formato umano, fammi questo.

Cioè, la roba è più stupida, però quelle più noiose possibili le sto facendo fare, però in realtà non è così smart come sembra, secondo me.

Cioè, c'è un po' da ignorantissimo nel mondo dell'intelligenza artificiale, però posso dire che ho notato che è un misto di figaggine mixata con fuffa per farti vedere che è più figa forse di quello che sembra.

Non lo so, mi sembra così.

Poi molto spesso o sbaglia, poi non è aggiornata, ha dei PI abbastanza recenti, quindi nel nostro mondo rischia di darti consigli sbagliati, a volte comunque non mi consiglia proprio nella maniera corretta, quindi poi per altre cose è una figata pazzesca, per carità.

Guarda, io… Però, per derivare a quello… Però, insomma, visto che è tanto idolatrata… Sì.

Però, proprio su questo, agli ascoltatori probabilmente si ricorderanno che ebbi accesso in Closed Preview a Copilot.

Seguendo il consiglio di Alessio lo disinstallai ancora prima che uscisse in versione commerciale.

Ti viziava troppo, scommetto.

Sì, abbassava il mio livello d'attenzione, Fabio, credimi, lo abbassava drasticamente.

Io non ero più in grado di fare una cazzo di espressione regolare, mi credi? Non che adesso ne sia in grado.

Sì, di famosi laboratori di cui parlavo prima, infatti.

Io non ero più in grado di farlo.

Non ero più in grado di farmi una cavolo di struttura dati se mi serviva.

Perché? Perché lo chiedevo a Copilot e me la scriveva e funzionava.

Poi, quando mai ho verificato che quello che faceva era formalmente corretto? Magari il test passava ed è ok.

E fai scrivere anche il test.

Eh, sì, così siamo posti.

Restability one and done.

Esattamente, esatto.

Però a quel punto è diventato anche, dal mio punto di vista, un problema di tipo etico, così come, e qua lo dico davanti a tutti, è diventato un problema di tipo etico quello della stesura del contenuto.

Ho visto dei contesti dove l'AI viene utilizzata pesantemente per scrivere del contenuto.

Tenete prento che io vengo da un background giornalistico e non vi dico le porcherie che stanno facendo alcuni miei colleghi con queste robe e con dei tool enterprise a pagamento per fare queste robe.

E oggi mi dico, io che sto iniziando a scrivere anche gli articoli un po' cicciosi in inglese, mi dico no, preferisco sudare sangue per rendere bene questo concetto, strutturare bene una storia, piuttosto che utilizzare questa roba.

I miei colleghi giornalisti mi dicono, ma allora sei un coglione.

Sì, sì, però penso che la generazione di rumore che avremo tra qualche anno sarà, verrà proprio da questo.

Immaginatevi un mondo JavaScript per qualunque tipo di contenuto.

Più o meno il rumore, me l'immagino simile.

Non so, avete sentito una delle ultime puntate di Continuous Delivery, che è un podcast amico, quindi non dobbiamo… Un abbraccio grandissimo.

Un abbraccio.

Dove c'era Michele Riva, che è un amico, quindi un altro abbraccio.

Un altro abbraccio.

E mi hanno fatto fare l'introduzione a Michele Riva a chat GPT.

E l'introduzione erano un po' di righe, il 50% di quello che era stato generato era corretto, l'altro 50% no.

E Michele lo sapeva qual era la parte.

Te immagina di scrivere una cosa di cui non sai e devi andare a trovare qual è il 50% delle informazioni.

Cioè devi fare te una review comunque su quello che ti scrive lui, se non sai nulla dell'argomento.

Se no rischi di pubblicare qualcosa che gli esperti si accolgono e non è corretto.

Quindi poi io sono un po' scettico nel senso di non sarei così sicuro dal dire, guarda mi generi 100 articoli su JavaScript per il mio blog, ne faccio uscire uno ogni tre giorni e per tre anni sono a posto.

Non mi fiderei tanto, perché comunque un po' di verifica va fatto.

Va beh, ma anche parlando della qualità del contenuto generato.

Però molto sta nella parte editoriale che ci metti tu dopo.

Scusa, il giornalismo è un'altra cosa, non è portare emozioni.

Che cos'è il giornalismo Gileo? Di cosa ti parli? No, io chiedo, dimmelo te che sei aspetto.

Sì, ma oggi buona parte dei contenuti sportivi e dei contenuti finanziari sono automaticamente scritti.

Non c'è bisogno di intelligenza artificiale, cioè ci esistono degli algoritmi stupidi che matchano tabelle con delle frasi già pronte e questo si risolve.

La cosa però interessante di chat GPT3 è il fatto che in realtà però la documentazione che generava e le spiegazioni che generavano erano maledettamente efficaci.

Ed erano maledettamente efficaci perché ricalcava dei pattern d'apprendimento belli consolidati che evidentemente stavano nel modello in quel caso e cazzo funzionano.

Adesso la mia domanda è, dal punto di vista della formazione, noi uomini diventiamo solo dei revisori? Guarda, mi hai anticipato metà discorso infatti.

Scusami.

No, no, no, ma va benissimo anzi perché così so che sei d'accordo già da subito.

Ma infatti stavo per dirti che magari non per un beginner ma per intermedio livello, quindi se voglio approfondire una figata pazzesca, l'altro giorno provavo a interrogarlo come gestiresti, sempre parlando di form che sono le robe un po' particolari, magari più, in realtà quelle più che vengono seguite più frequentemente, come gestiresti la validazione di due password che devono matchare insieme e vieni dicendo e volevo vedere se era furbo da usarmi l'API ad hoc che ha il framework per gestire non il validatore del singolo controllo ma di gruppo e in effetti l'ha usata.

Se io fossi stato un newbie e vi assicuro che un validatore di gruppo a molti non viene neanche in mente che esista perché di solito si valida il singolo controllo e se devo matchare due password faccio un if e verifico, invece esistono in Angular avrei scoperto quella cosa se non l'avessi saputa prima e quindi una figata anche per scoprire come creeresti un color picker da zero che si integra in un form di Angular.

Anche quello in Angular, adesso sto promuovendo Angular non so perché, però in realtà è figo perché puoi creare di custom form control e anche lì mi ha creato una classe e mi ha esteso l'API del form e mi ha fatto questa cosa qua e vi assicuro che anche quella non è una cosa non complessissima ma non per che da un principio, cioè è la classica cosa che nella guida leggi e non capisci la prima volta, tornando al discorso di prima, quando mi servirà mai a stendere sta cosa qua e da quel punto di vista lì ha gran potenziale e come hai detto tu anche le spiegazioni a corredo fanno tanto e probabilmente meno male che a meno che non c'è un trick e vorrei saperlo casomai, quando fai una domanda ci sta un po' di tempo a digitarla, meno male che c'è quella cosa lì se non lo riempirei di domande, tanto un po' un'artura di scatola, aspettare che scriva tutto il testo, tutto il codice eccetera, però forse questa è la fortuna in confronto a Copilot dove magari c'è la risposta subito, lì per fare una domanda devo aspettare almeno quei due minuti che me la scriva, se non lo riempirei di domande.

E da quel punto di vista lì per apprendimento è tanta roba, infatti ho pensato subito il mentor, la figura del mentor potrebbe essere ben non dico sostituita ma in realtà potrebbe fare tanto questa tecnologia per il supporto agli sviluppatori, tanta roba, tanta roba secondo me.

Poi come avete detto bisogna verificarle, però poi si scherzava anche sul fatto di scrivere testi, gliel'ho fatto di scrivere un po' di testi per vedere più che altro se li avrebbe pensati, se li pensava nello stesso modo in cui li ho scritti io.

Ti prego non usa la parola pensati però che mi mette paura a caso.

Tra l'altro a proposito di questo, scusami, giusta osservazione, ma prima dicevi si crea un sacco di rumore di fondo, si creano tanti articoli e anche Leonardo diceva probabilmente da revisionare eccetera, la differenza è che il tuo contenuto è originale e questo sicuramente già esiste, perché dubito che riesca ad assemblare, non lo so qua non voglio entrare in un ambito che non è il mio, però queste sue informazioni le prende da qualche parte ovviamente.

Poi non so quanto in grado di mixarle, far emergere, non ho provato a interrogarle su cose troppo particolari probabilmente, però ovviamente l'obiettivo adesso è creare contenuti che non esistono, che sono recenti o che trattano tematiche non dico sconosciute perché impossibile, quanto ecco ci si può giocare il 2022 quantomeno, perché tanto è aggiornata fino al 2021.

Però bisognerebbe vedere se chiediamo in che modo potresti usare l'aspirina per creare una libreria in legno, magari ChatGpt ti fa un articolo anche di 500 parole.

Sì, di supercazzole.

Non lo so, siamo noi a dire che sono supercazzole perché facciamo una revisione, però lui magari riesce a tirarti fuori un discorso al riguardo, non lo so.

Sembra aver senso, ci proverò dopo.

Non è lì che bisogna vedere.

Sì, senza dubbio, io non voglio essere un luddista, anche se sono tentato tanto, però non voglio fare il luddista della situazione.

Bisogna capire bene come posizionare lo strumento.

Per esempio quella della code review che ti suggerisce approcci diversi allo stesso problema, secondo me è una cosa intelligente perché continua a tenere la parte creativa dello sviluppo software.

Però anche qua secondo me il topic è un po' più grande di quello che posso essere io, quindi se siete d'accordo ritorniamo su cose più alla mia portata.

Probabilmente il topic è alla vostra, non è alla mia.

No, no, stesso, però...

No, però abbiamo parlato di documentazione.

Ti ho fatto già la domanda su come vorresti la documentazione.

Qual è la migliore documentazione oltre a quella beta di React? Per certi versi è ben fatta, devo ammettere che anche se non ho ancora, perché richiede un po' di sforzo per essere scritta, non l'ho ancora implementata proprio così nel blog.

A livello tecnico l'ho implementata copiando quella di React e poi era il problema che dovrei scrivere il materiale ovviamente, quindi quello è l'altro problema.

Però mi piace un sacco per la parte interattiva che spezza il codice con tanti code snippet, scusatemi, spezza la documentazione ogni tanto con dei code snippet dove puoi giocare, sperimentare e via dicendo.

Sarebbe figo, che è un po' quello che mi piacerebbe fare nel blog ma richiede tempo in realtà, dar la possibilità anche di avere questi playground, che è tecnologia che gli ho rubato clamorosamente, visto cosa hanno usato e l'ho usato anch'io, per integrare i playground all'interno con tanto di unit test ed è carino a fare delle micro sfide, anche magari si preparano i test, devi far passare i test per insomma andare allo step successivo.

Comunque questo mix tra doc e playground è molto figo.

Ti dico la verità però a un certo punto molto carino anche l'approccio per esempio di Svelte, che invece penso che sia più simile a quello che diceva Leonardo prima, che ha invece dei playground, perché praticamente la doc sono vari esempi di codice che hanno anche una spiegazione, però vicino, quindi infatti è banalmente un menu laterale dove trovi form, trovi router, esempio 1, 2, 3, 4 e ogni esempio ha una caratteristica che ti descrive il framework.

Ripeto, secondo me questo è più facile, in realtà è più facile per chi inizia, subito perché trova degli esempi già fratti e per chi in realtà anche io che ho già magari un pochino più di esperienza mi trovo subito a mio agio perché comunque più o meno li capisco già solo leggendo il codice, se non li capisco è il momento di leggersi la doc, in quel momento lì.

Quindi anche lì purtroppo non c'è un vincitore, mi piace un sacco quella di Angular che in realtà è immensa, non finirò mai di leggerla, e approfondisce un sacco di roba anche su tematiche per esempio che esulano dal framework, tipo la sicurezza web.

Molto spesso qualcuno chiede come o banalmente il classico problema, butto su un'applicazione statica con un router, una single-space application su un server, però se accedo direttamente alla pagina X non funziona, eccetera, solo se parto dall'index perché devo prevedere la fallback, eccetera.

Una cavolata, ma non è spiegata mai da nessuna parte, nessun framework sta cosa.

In quella di Angular te lo spiegano, però il bello è che è così tanto dettagliata che uno ci si perde, quindi purtroppo vince da una parte e perde dall'altra.

Anche qui ci vorrebbero diversi percorsi, se sei un beginner e inizi in questo modo, vuoi approfondire vai dall'altra parte, però sappiamo già che scrivere documentazione è lunga.

Però nei videogiochi c'era il livello easy, medium, hard e lo stesso videogioco che abbiamo, ma nella documentazione non c'è.

Dici come sei? Andiamo a livelli di profondità di però già è una menata scriverla una volta la documentazione, immagina tre e saper suddividere chi è intermediate o hard.

Domanda, come ti orienti tu nella scelta delle tecnologie e soprattutto come ti poni per guidare le persone verso una tecnologia o un'altra o anche verso un metodo di scelta? Questo è un problemone, nel senso che prima non mi sono riallacciato al discorso in cui dicevi, avevi fatto la domanda sulle code review, in effetti avere dei colleghi che ti insultano in maniera positiva, ti criticano il codice, ti fanno scoprire che esistono nuovi pattern, nuove tecnologie, quello è tanta roba.

Io lavoro da freelance quindi spesso non ho questa fortuna, d'altra parte però ho la fortuna di scegliere quello su cui lavorare e l'unico modo che ho per farlo è, ci sono anche lì vari problemi, per esempio seguo l'hype, se seguissi gli hype del momento probabilmente oggi non lavorerei perché dovrei sviluppare con tecnologie che sono sempre i massimi livelli dei sondaggi di stack overflow o di state of the art di javascript o quello che è e allora dovremmo usare solid, svelte, view probabilmente, ma anche no, ma anche no, dai me la tirata proprio, ma alla fin fine dovrei usare recoil che avrebbe dovuto uccidere redax, dovrei usare remix che ucciderà next eccetera eccetera, quando poi nella realtà di fatti è tutta altra roba.

Allora gli hype mi aiutano anche un po' a sapere cosa esiste, cosa potrebbe andare e per questo twitter e linkedin alla fine sono le fonti migliori perché vedi la gente a condividere e ti fai un'idea.

Il problema è poi ok, di questo che ce faccio? Intanto mi piacerà, allora lì faccio una cernita, vedo quello che secondo me è appunto un mix tra, prima valuto l'hype, se c'è tanto hype bene, se c'è tanto hype un motivo ci sarà e niente mi metto a studiarlo, in alcuni casi la boccio clamorosamente, vedi che non senta nessuno, vedi, view.js, perché non mi piace, per vari motivi, non è simile fare la crociata anche qui, anche più, comunque si, a parte le battute.

In altri casi mi rendo conto che per me la developer experience fa schifo, proprio senza troppi giri di parole, secondo me sono meglio altre soluzioni, quindi c'è anche un minimo di rischio che mi sono preso.

Angular io l'ho studiato e ho fatto mi ricordo il primo talk, tra l'altro in una conferenza importante in Italia, CodeMotion, nel 2015 ed ero in alfa, ero in paranoia totale, già era un primo talk davanti a 200 persone ancora su qualcosa che era in alfa, poi, quindi questo era un problema, in più avevo già investito tanto tempo su quella credendoci molto, devo ammettere che finora l'intuito mi ha suggerito bene, insomma, come all'inizio con react o altre tecnologie varie, poi alcune volte invece ci ho clamorosamente perso tempo, preso, studiato, buttato via totalmente, come poteva essere astro, sai, ci investi tanto tempo, ci investi magari un paio di mesi, che vedi un po' le situazioni, com'è, e poi dici ma perché, perché devo usare sta cosa, oppure qual è il contesto che mi copre questa tecnologia che non si è già coperta da altre? Nessuno, faccio un esempio di Svelte, bellissimo, a me piace un sacco, come framework, però dove l'utilizzerei? Ho bisogno di un'applicazione enterprise, molto probabilmente se la giocano prima a Angular, poi a React, devo fare un tool per una start-up che, non so, foto editor, Facebook, il tool che si connette al Bluetooth, se la gioca molto bene magari un React, e perché devo andare a scegliere un framework esoterico che probabilmente avrà più break in change, morirà e via dicendo, allora no, lì bisogna stare un pochino attenti a non buttarvi a tempo, a non mettersi in situazioni scomode, soprattutto per il futuro, e quindi l'unica è, alla fin fine, seguire un po' i trend e poi ognuno ha una testa, quindi provare un po', o fidarci di quello che ti dice il collega che l'ha provato, però l'unica è sperimentare, soprattutto se usiamo robe di ultima generazione, quindi non è neanche uno storico di review, di pareri, che poi i pareri, tornando al rumore, in realtà i pareri sono fatti da sviluppatori che sono persone, e devo dire la verità, se dovessi seguire il 90% dei tutorial che ho d'articoli su React, probabilmente, in realtà non userei React stesso, faccio l'esempio stupido, il fatto che una context possa sostituire un red, uno state manager, o il fatto di utilizzare un altro approccio piuttosto di un altro, sono cose in cui non credo totalmente, sono totalmente in disaccordo, eppure le leggo un giorno sì e l'altro pure, e quindi anche lì è sempre da prendere con le pinze il parere e l'opinione di qualcuno, basti pensare all'hype che c'è stato intorno a Remix, grazie al fatto che comunque sia ci sono sviluppatori di spessore che lo portano, diremmo Ken C.

Dodds all'inizio, Michael Jackson, non il cantante però, e quindi alla fin fine sono React router, per capirci, alla fin fine per chi non lo sapesse, e gente super in gamba, sembrava dovesse spopolare, come ripeto, Recoil al tempo di Redux, eppure, ad esempio su quelli io li ho provati, non mi piacciono proprio farlo di Recoil e Remix in questi casi, e li ho scartati, avrò fatto bene o male, sono sempre in tempo a cambiare, intanto mi sono fatto un'idea.

Lo stesso idea che avevo per esempio su Vite, Vite.js, per creare scaffold in React ed Angular, l'ho sempre trattato male, ho usato sempre Create React App per quanto riguarda React, perché per vari motivi devo ammettere che ultimamente lo sto provando, ecco, lo sto provando e va benissimo.

No, quello che non mi piaceva, se volete, ma adesso parente di 30 secondi più dettagliata, era che c'era YesBuild, che è fighissimo, però non ha il TSC, non fa type checking, e allora era inutile, non posso lavorare senza, però ho scritto un post tre giorni fa su questo, e in realtà alla fine, però, devo dire che con il plugin esterno per TypeScript va bene, va molto bene.

E quindi mi sono ricreduto, cioè ci sta, per l'amor del cielo.

E invece per chi sta imparando, come puoi aiutarlo nell'orientarsi? L'unica, e quello che faccio in realtà giornalmente, ecco, quello che comunico, ecco, ci tengo tanto a sta cosa, quello che comunico è quello a cui credo e che amo.

Cioè non esiste un post, guarda oggi ho fatto un post, oggi, non mi ricordo neanche più, su chat gpt e già mi son pentito di averlo fatto, perché già esula dalle mie competenze, da quello che voglio fare che è divulgare alla fin fine, io amo questo, te lo condivido.

Basti pensare, guarda, non hai idea di quanti blog stanno uscendo che mi scrivono in astro tra un po', perché ho iniziato a condividere un po' di queste cosine, quindi ci ho creduto, spero che non esploda, ho qualche timore che tra un anno non riesca ancora a compilare tutti i markdown.

No, ti prego, ti prego, cazzo, perché io quel sito di Gitbard non lo riscrivo.

Però tu ne hai una settimana, io, e forse non so quanti markdown hai, io vedo che inizi a far fatica adesso.

No, io non ho markdown per fortuna, ma chiama l'API del feed RSS, quindi ancora peggio forse.

No, bara, è che devo processare un sacco di cartelle e devo processare un sacco di file, di immagini, che sono un sacco di immagini gif animate anche da un mega, due mega, eccetera, quindi che poi comprime lui.

Le immagini le metto in 4k perché non ho voglia di ritagliarle, poi tanto le ritaglia lui, oppure chi morirà prima o poi, però vabbè, questo è un altro discorso.

Però a parte questo l'unica cosa che posso fare io è quello di dare i consigli su quello su cui credo io, cioè quindi divulgare quello che mi piace ed eventualmente consigliarte, è l'unica cosa.

E per uno che invece si trova alle prime armi è un casino, perché sappiamo bene che il mondo JavaScript è incasinato, all'inizio fare le scelte giuste è difficile anche se comunque si stanno delineando, no? Cioè lato single page application non mai sappiamo cosa usare, poi adesso c'è la guerra di meta framework e di tutta la parte serve essere rendering, edge rendering, React server, bla bla bla, no? C'è tutto un altro mondo e la guerra sembra essere lì e lì in realtà non ci capisce niente nessuno, perché ormai ognuno sta portando avanti le proprie tecnologie, le proprie dinamiche, vedremo chi vincerà no? Tra tutti, no? Però è un casino, però ci sono alcune scelte che ormai, cioè, sai già che se vuoi fare web designer o web developer devi studiare quelle quattro cose, quattro cose per modo di dire, intendo HTML, CSS, JavaScript, TypeScript e poi in base al framework o alla libreria che scegli ne sposi una delle due, tre, se proprio vogliamo mettere la terza che non nominerò più, però le due tecnologie Angular e React alla fin fine, cioè, vinci e comunque uscirà il nuovo framework che farà solo client side rendering e lo farà benissimo, è la novità del 2023.

È strano, non è la novità, mai.

No, comunque, super interessante, volevo aggiungere una piccola cosa su quello che riguarda l'apprendere in funzione del codice che si scrive, che è una cosa molto semplice, vengino signori, anzi facciamolo così qua.

Vengino signori, se volete calci in culo gratis c'è un mondo open source che ha bisogno del vostro contributo, quindi mandate le vostre PR e avrete dei revisori che vi daranno abbondanza di calci nel culo sulle correzioni.

Ok, dopo aver fatto questo siparieto super cringe, lo ho detto io e me ne prendo tutta la responsabilità, vedete che stiamo provando i nuovi tool, ci siamo un po' rimodernati.

Ma è nuova questa, io non l'avevo sentito, ho già spuntato fuori.

No, questa è una roba che ho configurato l'altro giorno, giusto per provare.

Alla fine le donazioni servono a qualcosa.

Eh sì, la licenza di questo programma l'abbiamo comprata con le donazioni.

E a proposito delle donazioni tra qualche minuto ringrazieremo i supporter.

Voglio però fare un paio di domande su una cosa che mi interessa parecchio.

Fabio oltre ad essere un formatore è anche una web personality, tra amici e scherzando, noi gli diciamo che è posso dirlo la Chiara Ferragni dello sviluppo in Italia, lui naturalmente si incazza, no scherzo.

Però in realtà perché diciamo questo? Perché sui social è una personalità ben definita.

Adesso quando tu diventi così visibile probabilmente le persone si aspettano qualcosa da te.

Tu hai mai percepito questa silenziosa richiesta, questa esigenza, il fatto che i tuoi follower abbiano bisogno che tu continuamente produci il materiale? È stato un peso per te, ed è un peso per te questa cosa, come gestisci questo elemento della tua vita? Non è neanche troppo silenziosa, nel senso che il vero problema sono i messaggi privati, il vero problema è quello da gestire, perché per quanto riguarda i contenuti sai alla fine il tempo è quello che è, quindi eventualmente posso rispondere dicendoti che effettivamente in questo periodo non ho tanto tempo, però ci sono altri periodi come in questo invece che sto sfornando materiale su materiale.

Il problema tante volte è il messaggio privato, perché magari sai, sono con una premessa gentilissima, tanti complimenti, poi fanno una domanda che non è solo una domanda tecnica, a volte semplicemente reindirizzo a per favore puoi farla nel gruppo Facebook che abbiamo o nel gruppo Telegram in questo caso, e la puoi fare lì, dai che così è anche utile agli altri, e soprattutto hai altri punti di vista, non solo il mio alla fine, perché comunque ci sono altri che rispondono.

Il problema però invece quando sai, ti iniziano a chiedere problemi, anche personali, che riguardano il lavoro, come migliorare, oppure che ho già 35 anni, cosa devo fare, e lì un po' mi sento in dovere, di dover comunque dare, infatti anche chi ascolterà potrà dire che cerco di rispondere più o meno sempre, il problema è il tempo che richiede qualunque risposta, quindi quello è il problema maggiore che ho, perché per i contenuti onestamente sai non c'è un pagamento, non hai una sub che richiede sempre, che ogni mese tu debba sfornare per forza contenuti nuovi, quindi quello è relativo.

E poi tra l'altro avrai visto, penso anche tu che sono un po' uccel di bosco, nel senso che sperimento anche un po', c'è stato un periodo di Twitch dove ho sperimentato parecchio, poi a volte ho investito su YouTube, adesso sto investendo tantissimo su LinkedIn, quindi in realtà sai, magari in un certo periodo chi mi segue su YouTube non vede più contenuti, d'altra parte chi è su LinkedIn mi trova più lì a rompere le scatole quasi giornalmente, sto ancora lì sperimentando un po' per cercare di trovare un po' la quadra.

Spoiler, la quadra per me è LinkedIn, chiuso lo spoiler, perché è l'unico social che mi permette di crescere un pochino di più, ma questa è un'altra storia.

Sai che l'ho notato anch'io, a parte che io odio i social, tipo non ci sono buono, sono boomer nell'anima, per me potrei veramente scrivere le lettere a mano e probabilmente sarebbe meglio, però ho visto che quello che se hai dei contenuti un po' più strutturati funziona, è un po' meno polarizzante degli altri, è un po' più aperto alle discussioni pulite, non so come dirlo, non so se hai avuto gli stessi pensi.

No, mi sembra anche abbastanza meritocratico, nel senso che certo non valuta la qualità dei contenuti, però quanto meno è premiata la costanza.

Poi io non so, ho una rete di contatti che è abbastanza verticale, però intendevo che molto verticale, quindi voglio dire che il mio feed è anche abbastanza pulito alla fin fine, cioè raramente trovo roba che non mi interessi, cioè trovo roba su AWS, non uso AWS, non me ne frega niente, però sai a tema comunque, quindi in realtà mi sembra abbastanza, tra virgolette, intelligente dal propormi quello che mi interessa e da in realtà far vedere andare su con like, perché poi c'è questo algoritmo che ovviamente va a premiare certi tipi di contenuti piuttosto che altri, e noto in effetti che quelli che hanno più visibilità sono chi se lo merita anche perché ha una certa costanza, pubblica sempre contenuti, dicendo poi che alcuni sono, faccio un esempio, lato codice, molto spesso sono anche interessanti, più o meno da beginner, più o meno di nicchia, in altri casi sono molto fuffa, soprattutto quando parliamo di coaching e via dicendo, lì è molto facile andare su chi ti racconta la cosa banale e chi in realtà fa veramente sul serio il proprio lavoro, allora magari trovi anche dei post banali che hanno 18.000 like e 4.000 commenti, però è una foto di Dubai, con la foto da Dubai poi, con la cortina.

Ecco, per fortuna io non so se è perché non seguo, perché su YouTube siccome mi piace vedere quella roba trash, perché io adoro, i miei momenti comici sono quando vedo i video di Big Luca, non volevo fare nomi, però ce ne sono, Mako e Big Luca, sono tanta.

Poi devo fare pubblicità a un gruppo Facebook, perché è bellissimo, non ho nulla a che fare con il gruppo, si chiama Fuflix, di Germano Limite, io lo adoro, perché c'è altro che sfogliare le storie di YouTube, lì è bellissimo.

Comunque, a parte questo, su LinkedIn non so se è perché non seguo tanto quella cosa come su YouTube, quindi lì mi propongono proprio cose, però in realtà è un bellissimo social secondo me.

Ecco, un consiglio che sicuramente già do spesso è vai subito su LinkedIn, inizia a avere una presenza, inizia a condividere anche se sei un junior, perché comunque crei contatti, crei network, fai vedere che hai voglia di fare qualcosa.

Ci sono dei ragazzi e ragazze che vedono che sono palesemente junior, ma io ormai non li conosco e allo stesso tempo li conosco, perché ogni settimana, non è ogni giorno in realtà, pubblicano il loro avanzamento, fanno la demo, ricreano questa cosa, provano questa cosa.

Alla fine se io dovessi consigliare, se non c'entra nulla quel discorso, chiedo Venia per l'off topic, però se dovessi consigliare ad un'azienda di assumere qualcuno, una persona del genere fa vedere l'impegno che ci metti.

E a parte tutto poi magari la persona è già nelle relazioni anche di quest'altra, quindi si crea un contatto anche più facile.

Quindi va, confermo bellissimo social.

Scusa, ho divagato su un argomento sul punto off topic.

No, no, no, assolutamente.

L'importanza del learning public è veramente potentissima.

Io devo dire che hai detto una cosa interessante, che tu dici il mio feed alla fine, essendo molto verticale, si è pulito e io dentro LinkedIn vedo dei topic che mi interessano e sto nella mia bolla e sto bello sereno.

Sai che in realtà era un po' quello che mi mancava dall'ultimo Twitter, l'ultimo periodo che stavo usando Twitter e da lì ho deciso, voglio condividerla questa cosa perché secondo me è importante, ho deciso di fare un passo indietro.

Carmine, Leo e Alessio l'hanno visto perché ho chiesto consiglio a loro e sono ripassato ai feed RSS, ho smesso di documentarmi sui social e ho smesso di consumare, come li possiamo chiamare, bites, morsetti di informazione, piccole pillole di informazione e quindi ho deciso di privilegiare, magari un libro, privilegiare dell'informazione molto più, un paper, ho mi presa a leggere paper, io non so quando è l'ultimo paper che avete letto, a me sta gasando tantissimo il fatto di leggere paper su come funzionano i database, su come funzionano gli algoritmi, su come funzionano le cose, tra l'altro ce ne sono alcuni interessanti anche sul mondo del front end, di studi che sono stati, che diciamo hanno una profondità, al di là poi degli snippet di codice, del tutorial di come si fa, di come si gestisce la memoria su RAST, che comunque preferisco, siano delle pillole quelle, però è possibilmente indolore anche se sono abbastanza painful, no però il fatto di fermarmi e di scendere dritti su queste cose mi è utile, vero è che però io non sono una web authority, una web personality, quindi in questo modo posso permettermelo.

Sì, no infatti, infatti, e guarda è un problema che mi pongo molto spesso, infatti io su TikTok non ci sono, lo trovo decisamente cringe, tornando a riutilizzare questa parola, difficilmente riesco a trovare qualcosa che non lo sia in ambito professionale, a meno che effettivamente non ci sia il commercialista, l'avvocato che ti esprime un concetto o anche un programmatore che tu esprimi seriamente, ma devo dire che spesso sfocio più sul cringe che sulla parte seria, perché altrimenti non farebbe numeri, più di tanto, probabilmente, questo non vale per tutti, per carità, però e se non è cringe è inutile molto spesso, cioè vengono date frasi motivazionali o banali o anche trick tecnici, che però, che trick può essere in 30 secondi? La pillola, quanto può essere uno snippet condiviso su LinkedIn? Per esempio, per quanto mi riguarda, infatti io è difficile fare numeri, proprio perché non mi va di fare questo genere di comunicazione e appunto alla fin fine mi sono focalizzato su semplicemente andare a condividere solo roba tecnica, che poi possono essere, a volte anche possono essere le pillole, ma ultimamente sto cercando di fare carousel, ho fatto dei nuovi tutorial step by step, tra l'altro una vita che non si vedono in giro secondo me su web, cioè proprio puoi seguirli step by step e fare passo passo ricreando il tutto per fare pratica.

Ma tipo quelli di io programmo? Eh, fai la, installa la CLI, fai tutto step by step, cioè se vai sul mio blog, ne ho già fatti tre, domani esce fuori quello di VIT e VITest, no? Quindi per fare i test, è la stessa roba, ti spiego come configurarlo, non te lo dai dritte, fai questo, fai questo, lanci il test, metti il code coverage, ma questo dà problemi, fai quest'altra mossa e bla bla bla, no? Tornando al discorso di come si fa a consolidare, spesso dagli esercizi alla fine, che sono degli esercizi step by step perché alla fine ti do anche la challenge, risolvi la, però molto spesso c'è chi non sa neanche da che parte iniziare, quindi ti ritrovi in una classe ad avere gente che ha finito in due minuti, gente che è lì che guarda il monitor per un'ora, ma questo è ancora un altro discorso.

Però tornando al discorso di social, il problema è che non diventerò mai ricco così, no? Perché mi vendo, mi potrei vendere in altro modo, ma insomma è legato poi anche un po' alla reputation, visto che magari poi se ne accennava ancora prima di iniziare questa registrazione, il fatto è che stai poco, tanto per crearla, stai pochissimo per distruggerla, no? Una minima reputazione, quindi sai, alla fine inizia a condividere solo fuffa o inizia a condividere solo roba banale, perché? Perché la roba banale tira su sicuramente più like, nel senso che riesci a raccogliere, paradossalmente le cose che vanno di meno sono tutti quelli che si lamentano di non scrivere test, ma tutti i post, i video, le cose che ho fatto sui test, gli end to end test ultimamente, sono quelli che rendono meno, meno in assoluto, no? O quando parliamo magari di pattern particolari, eccetera.

Quando invece condividi lo snippet di come filtrare un array, 700-800 like in un post, però se inizi a condividere solo quella, hai una certa fama anche perché poi i sviluppatori parlano e quindi tra di noi siamo tutti amici e quindi si sa bene come uno la pensa rispetto a un altro, cioè quindi vedi un po' come l'andazzo, no? E quindi cerco di evitare il più possibile di espormi in questo modo e poi oh, non è che uno è il guru, cioè tra l'altro, tanti mi dicono sei il migliore sul front end, no! Probabilmente sono quello che si espone di più perché c'è molta gente più brava di me e allora ovviamente devo stare anche attento nel trovare un giusto equilibrio per riuscire a raccogliere comunque consensi e allo stesso tempo condividere qualcosa che abbia un minimo di senso e cercare di non scrivere minchiate, scusate il francesismo, perché poi anche lì c'è un problema, c'è sempre l'hater dietro l'angolo che non vede l'ora che sbagli per fartela pesare, per fartela notare e via dicendo.

Quindi è un equilibrio difficile da raggiungere.

Devo ammettere che ultimamente lo faccio, c'è stato un periodo in cui, cioè non ho bisogno, in realtà a me questo serve perché sono freelance e quindi è il mio modo di pubblicizzarmi.

Io non pago l'advertising, questo è il mio advertising, quindi in realtà ha un costo perché comunque per produrlo richiede tanto tempo e quindi questo è quello che in realtà faccio per avere un po' di visibilità.

In realtà dovrei farlo rendere un po' di più avendo degli upselling o altre cose che non ho perché il mio tempo è quello, in realtà mi hanno già pronotato per tutto il 2023 quindi non c'è più posto se qualcuno di voi volesse fare formazione, quindi non sto vendendo nulla e devo trovare anche il modo di monetizzarlo un po' di più questa cosa, però questa è un'altra storia ancora.

E quindi no, è difficile, è difficile trovare il giusto equilibrio, però ho scartato di default certi atteggiamenti, certe cose che già su Twitch ho perso metà della mia reputazione perché è venuto fuori di tutto e di più in quei due anni di Twitch, succedeva di tutto fino alle 5 di mattina, meglio di tutto adesso.

Hai fatto anche ASMR? Mancava solo quello, però e quindi ho già provato un minimo, ecco lì ero veramente, tra virgolette, fragile nel senso che sei tanto esposto a tutte le tue debolezze, no? Perché parlavi prima del learning public e lì a volte imparavo, a volte facevo, sbagliavo un sacco di volte, quindi fai vedere le tue debolezze da cune, quindi molto diverso da quello che si vede nel video tutorial pre registrato o nel post scritto.

E' una fragilità che all'inizio soffrivo tanto, poi in realtà ho iniziato a non fregarmi più nulla e a un certo punto non lo faccio più per altri motivi che sono in realtà non mi piaceva, cioè proprio non mi sentivo a mio agio a fare questa cosa, come non mi sento a mio agio a metterci la faccia su TikTok o a fare tante altre cose, quindi non mi faceva stare tanto bene, quindi lo faccio raramente, ogni tanto.

Quindi questo è quel motivo, cioè il modo in cui lo cerco di evitare a monte di essere troppo cringe, perché penso a me stesso che vede questi video nel futuro, sperando di non poterlo fare, l'ho formulata male, però insomma spero di non vergognarmi il futuro di quello che ho fatto oggi, quindi cerco di evitarlo direttamente a monte.

Ma soprattutto perché io trovo cringe quello degli altri, da una parte invidio, scusami, da una parte invidio perché dico cazzarola però, hanno fatto 20.000 like, c'è una ragazza bravissima su Instagram che lavora in Discord adesso, è indiana, in realtà è americana di origine indiana, adesso non mi viene in mente il nome, che però fa mille, 1200 like su Instagram, però fa dei video abbastanza banali, ma sono simpatici e la vedo molto naturale, quindi ci sta.

Ce ne sono altri invece che li vedi palesemente costruiti e allora diventa cringe, no? E bisogna saperli fare, io non so, non sono capace, quindi diventerebbe cringissimo, poi ormai sono boomer anch'io, quindi già tanto che sono sesso.

No, ha super senso quello che hai detto, specie nel framing che gli do io personalmente, posto che come anche tutti gli ascoltatori sanno, messi da parte i miei timidi tentativi di comunicare qualcosa nei social, ho capito che forse preferisco parlare con le persone o stare davanti a un microfono a dire le cazzate mettendogli effetti vocali.

Hai trovato la tua strada, quella che preferisci, che ti fa sentire meglio, come dicevamo.

Però, però, io sono cringe a cassette nel podcast, sono cringhissimo.

Quello che voglio dire è che secondo me dipende molto da come approcciamo.

Posto che io TikTok l'ho cancellato dopo subito, appena ho visto che ci stavo passando troppe ore, a far niente, a far niente, la cosa è molto semplice.

Noi da sviluppatori, quando facciamo formazione, per noi quella formazione, nel 90% dei casi, è anche intrattenimento.

Ed ecco perché nel nostro Twitter, nel nostro Facebook, nel nostro LinkedIn abbiamo dei feed pieni di roba di programmazione.

Perché per noi è anche intrattenimento.

Messi davanti all'intrattenimento puro, che è quello che facciamo.

Allora, mi ricollego al discorso che facciamo prima, perché è esploso tutto nel frattempo.

Dicevo, fondamentalmente il nostro entertainment spesso corrisponde col nostro approfondimento.

Per cui, probabilmente, è per quello che non riusciamo a vedere alcuni contenuti di TikTok come interessanti.

O perlomeno io li ho sempre percepiti come una perdita di tempo.

Quindi probabilmente è questo.

C'è da dire che però, sul fatto del concetto di reputazione, io non lo farei mai.

Non ci riuscirei.

Eh sì.

Una scelta personale che è molto soggettiva.

Non che a me non importino i numeri, però sono numeri ridicoli alla fin fine.

Quindi stiamo parlando praticamente del nulla in confronto a chi fa veramente i numeri.

Però c'è sempre un mix tra avere un buon risultato e mantenere una certa integrità professionale, quantomeno.

Abbiamo una domanda però, che mi viene dal mio passato di mezzo marchettaro, anche se non si direbbe.

Tu lavori tanto sulle piattaforme, no? Sei stato Twitch partner, lavori molto bene su LinkedIn.

Una delle cose che ritornava nei discorsi di marketing che facevo una vita e mezzo fa, era il fatto di poter tirar fuori l'engagement dalla piattaforma in qualcosa di più proprietario.

Per esempio il problema è che se domani a LinkedIn succedesse qualcosa tipo quello che sta succedendo a Twitter, no? Tipo una mezza diaspora che ancora non ho capito.

Su quello potremmo approfondire perché sono veramente curioso di come andrà a finire la faccenda.

Però hai paura di una potenziale situazione del genere dopo che hai investito una fatica, immagino, grossa nel costruire quella mole di relazioni? Sì, sì, soprattutto perché già parlavate, cavolo non mi viene in mente qual era il discorso del fatto che, vabbè non mi viene in mente, però in realtà ci sono già passato legandomi con Adobe, con Flash eccetera, dove per un anno non ho fatturato.

Questa è una storia che sanno in tanti, però io lavoravo su tecnologia Adobe, a un certo punto ho chiuso il Flash Player e io per un anno non ho fatturato più.

Fratello, ti voglio bene, stesso Pain, uguale.

Ecco, e allora io ho il terrore perché ho messo su un blog, pubblicavo su DevToo, o su Medium poco in realtà, non mi è mai piaciuta tanto come piattaforma, ma più che altro non mi è piaciuta, ecco vedi, anche lì non divento ormai ricco.

So che paga anche abbastanza bene tutto sommato gli articoli, però in realtà non mi piaceva proprio l'editor, cioè alla fine dovevo mettere gli ghist esterni per gli snippet, adesso mi sembra che l'hanno migliorato questo aspetto.

Quindi usavo DevToo perché era Markdown, sai, era vecchia maniera, però il contenuto è mio, il contenuto è mio e voglio che rimanga sul mio blog in questo caso.

Per quanto riguarda lo streaming è più una necessità, ma infatti ho creato Player FabioBiondi.dev che in realtà è stato l'esperimento di SvelteKit della scorsa settimana per portare tutto lì dentro.

È ovvio che però i source, insomma i sorgenti sono su YouTube, però in realtà ho il terrore ed è uno dei motivi per cui purtroppo, ed è un lavorone, non sono su una sola piattaforma.

Su Facebook ho le community da 40.000 membri più il mio gruppo Facebook, su LinkedIn sto cercando di creare una presenza, su YouTube il mio canale, su Twitch sono partner e su Twitter non faccio un cazzo perché in realtà non riesco a far andare i suoi libri.

Tanto dici che durerà poco? Hai mai pensato, o non so se ce l'hai, di spostare tutti sulla tua mailing list? Allora, spostare tutto in che senso? Cominciare a promuovere la tua mailing list dove qualsiasi sia la piattaforma, te hai l'indirizzo e email e puoi mandare i link agli articoli se non mandare una specie di substack.

Assolutamente sì, infatti il blog o in ogni articolo ho messo la newsletter che non sto ancora spingendo, ma ho ricominciato a mandare qualcosina, non voglio neanche martellare più di tanto, ed è proprio questo il problema di Twitch, uno degli altri, oltre che non sentirmi a mio agio nel fare live, era il problema che non rimaneva nulla, non mi rimaneva nulla a livello né di contenuti perché spariscono dopo un tot, quindi manco la soddisfazione di avere lo storico di tutte le live, forse meglio in realtà che sia così, che spariscano dalla faccia della terra, il problema è che non ti rimane neanche un contatto, ed è proprio questo l'enorme problema.

Infatti avevo pensato proprio di iniziare a fare delle live su Zoom in realtà, proprio perché Zoom mi permetteva di comunque avere lo storico di tutti i partecipanti e di poter eventualmente fare poi, adesso in maniera venale, upselling, cioè se un video corso mio devo venderglielo in qualche modo, come le becco queste persone qua se mi chiude Linkedin effettivamente.

No, no, poi quello è il punto.

Sì, sì, sto iniziando di nuovo a puntare su quello, ma che poi è il motivo per il quale io, sono boomer, io ho il terrore del cloud, o di qualunque servizio as a service, io non uso quasi nessun CMS esterno o feature del genere perché? Perché ce la prendiamo sempre nel culo alla fin fine in un modo o nell'altro, quindi tra cinque anni o non esisterà più quel servizio o ci costerà quantomeno due, tre, se non cinque volte tanto.

Quindi ci stiamo legando a servizi come anche Google Drive o per esempio io non ho iCloud, io non metto nulla su iCloud pur avendo tutta piattaforma Mac, io ho un account Google che è il Workspace, che così lo uso anche per altre cosine e alla fin fine uso quello per fare lo storage di tutto che al limite prendo me lo scarico e me lo porto da un'altra parte, no? E praticamente non ho quasi nessun servizio cloud, non servo su Notion, l'unico che ho è Gitbook, perché? Perché tutti i repository sono versionati su Git, quindi muore e c'ho i markdown di tutto.

Ho il terrore, ho il terrore perché non uso io neanche un Firebase per esempio che in realtà ogni tanto uso, ma perché ogni tanto non solo potrebbero chiamare, parlo di quello come potrebbe essere qualunque altro servizio, ma perché in realtà anche lì non solo mi cambiano le policy, che poi tra l'altro potrebbero essere policy anche che riguardano GDPR o altri problemi che devo affrontare e me la prendo di nuovo del culo due volte, ma il discorso che a volte mi cambiano la piattaforma sotto i piedi e cosa faccio? Finché è un docker prendo, sposto, faccio quello che… cioè ci può anche stare, ma un servizio su cui mi baso, che è unico e la mia piattaforma si basa esclusivamente su questo servizio, io son fottuto se chiude, no? Cioè va bene per una startup, va bene per validare un'idea, ma poi devi costruire secondo me una tua infrastruttura.

È una vita che voglierei farmi il mio software di backup da mettere da qualche parte che posso prendere e spostare anche per tutte le fotografie e tutto quanto, ma non c'avrò mai la voglia di farlo.

Però quindi non ricordo più la domanda originale, però so che bisognava parlare ormai di questa cosa.

Ragazzi io guardavo l'orologio e tipo siamo a due ore, ci siamo fatti un po' prendere la mano e tipo mezzanotte noi abbiamo iniziato a registrare alle nove.

Hai visto i nomi delle aziende e forse riusciamo ad arrivare a un'ora e mezza.

No, allora datemi giusto un secondo prima di andare in chiusura perché abbiamo un momentino che non possiamo schippare.

È il momento di ringraziare i donatori della settimana, le persone che mi hanno dato il nome, ci prendono sulle spalle e ci accompagnano facendo in modo che ogni settimana possiamo portare del contenuto fresco.

Abbiamo questa settimana alcuni donatori, questo perché sono un po' di più del solito perché ci siamo fermati qualche settimana per Natale.

Il primo è Giovanni Italiano che ha replicato una donazione facendo una donazione di 5 birre con un messaggio auguri di buone feste e grazie per il podcast.

Grazie a te Giovanni, abbiamo anche Leonardo Sabato o Sabato, io sbaglio tutti gli accenti, li metto in modo randomico, abbi pazienza di me Leonardo.

Grazie per tutto il tempo che togliete a voi per dedicarlo al podcast e soprattutto grazie per la condivisione.

Bravi tutti, grazie a te perché fai in modo che noi possiamo arrivare alle vostre orecchie ogni settimana.

Ma abbiamo un altro donatore, 3 birre Andrea Quintino che insieme a Leonardo e a Giovanni hanno fatto in modo che noi questa settimana abbiamo potuto pubblicare l'episodio.

Il Paese dei Balocchi, il momento in cui i nostri ospiti e host condividono una roba che è particolarmente interessante, ha catturato l'attenzione, insomma è degna di nota.

Quindi la prima domanda va per Fabio.

Fabio hai qualcosa da condividere con noi? Questa è la domanda più difficile di tutta la serata, però visto che eravamo in tema potrei dire di un bel libro su algoritmi, semplice per iniziare così, per chi vuole metterci un piedino dentro, che è Grokin Algorithm, non so se lo conoscete, è uno dei libri che è uno dei primi, in realtà ho fatto qualche anno fa degli acquisti di libri di algoritmi, di cui alcuni sono ancora praticamente vergini incartati, sono aperti, siccome non ci capivo moltissimo questo è stato quello da cui sono partito ed è quello che mi è piaciuto di più.

Sono pochissime nozioni matematiche, ma pochissime che eventualmente comunque si possono colmare, mentre altri, per esempio, cavolo non mi viene in mente il nome con la cinizia del librone di informatica da mille pagine che viene usato all'università.

Aspetta, tiro fuori il volo.

Il Corman, suggerito da tutti, non so se mai lo sfoglierò realmente, l'ho comprato, ma non so.

Tornando tra l'altro al discorso della carta, vedi che sono tornato anch'io alla carta.

Vedo, vedo, il libro Groking Algorithm per me è un capolavoro.

Mi fa piacere, perché è un po' sempliciotto da un certo punto di vista, però è quello che veramente mi ha permesso di capire alcune cose.

Siccome non l'ho fatto all'università, alla fine, ecco, grosso gap da colmare, questa parte degli algoritmi, e in realtà grosso gap da colmare la matematica, che vanno a braccio, praticamente, un po' nel nostro lavoro in realtà.

Comunque, è un bel libro.

Se ne posso suggerire un altro che ho letto in questi giorni, ma non così ormai, ormai che abbiamo fatto tardi faccio fare tardi due volte, anche Modern Front-End Development in Node.js.

È un bellissimo libro per i front-ender, perché parla di qualcosa che avrei voluto sentire.

Infatti farò una piccola recensione nei prossimi giorni di qualcosa che...

Sono curioso di leggerlo.

Ma allora, è banale, non serve leggerlo a te, però sai, all'inizio ti fa capire che cosa sono le differenze tra CommonJS, MD, RequireJS e dei tempi di Node.

Ti fa capire che cos'è un module bundler, quindi che cos'è Babel, piuttosto che Webpack, piuttosto che adesso non so se parlerà poi di YesBuild, eccetera.

Quindi è una piccola introduzione, no, per capire un pochino a cosa serve effettivamente perché Node in un mondo front-end, no? E sono quelle basi che è difficile all'inizio, no, è nata da raccogliere come...

cioè da capire, insomma, queste cosine, queste sfaccettature, no? Ed è simpatico.

Un po' caro, perché mi sa che viene 26 euro la versione stampata, ecco, quello non lo consiglierei perché ha tipo 150 pagine, però mi pare che l'ebook, sto vedendo adesso 5 euro di roba, quello è simpatico.

Siccome me l'hanno regalato, per quello mi hanno costretto a leggerlo, no? Però alla fine l'ho letto anche con piacere perché ho detto che cavolo, no, no? È stata una lettura veloce, molto leggera e come si è avuto prima, non era male.

Bello, bello, bello.

Ci butto, ci butto un occhio.

Grazie dei balocchi.

Leo, hai qualcosa per noi? Sì, io volevo suggerire una...

un'estensione per tutti i browser, si chiama Daily Dev, quindi.dev, che sostituisce l'home page di Chrome, Firefox o quello che usate con delle card con delle notizie sul mondo dello sviluppo.

All'inizio fa scegliere un profilo, sceglie quali sono i tuoi interessi, non fa vedere per forza articoli pubblicati recentemente, ma anche a me mi capita anche roba fatta qualche mese fa.

Non so in che modo, però diciamo può sostituire chi non vuole andare dentro la marea di Twitter e venire in ondato.

Quella lì è una selezione di qualche cosa che può far iniziare a...

È un problema quando uno cerca...

apre una nuova tab per cercare qualcosa, poi si mette a leggere gli articoli e si dimentica cosa ha fatto.

Ma è il problema di tutti i feed, di tutti i social network, quindi almeno questa è roba abbastanza utile.

Bello.

Ah no, avevo preso io un...

un granchio.

Allora io praticamente il mio balocco l'ho già spoilerato, però ho un'altra cosina da condividermi.

Sono capitato nel blog di un tizio, non mi ricordo cosa ha fatto, è uno abbastanza grosso, fatemi guardare, tipo il creatore di Trello, di Glitch, ok, che è senné uscito verso Natale con un articolo dove propone la creazione di un blog protocol.

Praticamente avete visto l'editor di Medium, la possibilità di inserire dei blocchi all'interno del nostro contenuto, che possono essere blocchi di test, immagini, tabelle, altre robe che ci possono buttare dentro.

Quello nuovo, che ho letto che è uscito quello nuovo, è un editor nuovo, recente? Allora, in realtà non si tratta di un editor, questo tizio, che è comunque abbastanza conosciuto alla community, almeno nella community americana per quanto riguarda il frontend, ha detto fermi tutti, ognuno sta facendo l'editor a cazzo, ok, troviamo un modo per standardizzare un protocollo per la creazione di questi blocchi.

Ogni blocco deve avere...

questo protocollo definisce i blocchi di input dai blocchi di visualizzazione, tu li puoi fare come ti pare, è uno schema.org dei blocchi, non saprei come definirlo, siamo ancora ai primi mattoncini, però è una roba che secondo me, siccome abbiamo parlato molto di frontend, è interessante da seguire e vedere come si evolve e perché no, anche ritagliarci uno spazio nelle discussioni, visto che comunque ci occupiamo di questo, possiamo portare il nostro contributo.

Quindi questo era il mio balocco.

Per favore, mi ricordaresti il nome di questa tecnologia di cui hai appena parlato? Il nome si chiama Block Protocol, il tizio è Joel Spolsky, ma comunque metto il link nelle note dell'episodio, tra gli altri link sarà presente.

Una cosa molto molto molto interessante, hanno già implementato delle robe su WordPress, che è un plugin di WordPress, che utilizza questo protocollo che però, essendo un protocollo, in realtà è un insieme di regole, l'obiettivo è quello di portarlo a tutti i CMS.

Sarebbe anche ora esatto che qualcosa si muovesse in modo semantico da quel punto di vista, visto che abbiamo i micro data, abbiamo tutto, ci manca però la struttura, il protocollo che orchestra sta roba.

Non potevo non incasinarmi col pulsante delle musichette, ormai, vabbè, almeno nella parte dei saluti.

È mezzanotte e dieci, Fabio ti abbiamo distrutto oggi.

No, era stato un piacere, anzi abbiamo visto un tecchiaralla, mi sono perdito.

Ti ho tratto in inganno dicendoti un'oretta, in realtà, come bene hai visto, ci dilunghiamo un po', però è stato veramente un super piacere averti qua ai nostri microfoni.

Come diciamo sempre, in realtà, da oggi, Gitbar è anche un po' casa tua, per cui quando c'è qualcosa di nuovo, quando hai qualcosa che bolle in pentola, vieni a raccontarcelo.

L'altro giorno non ti ho raccontato, ma stai facendo qualcosa di nuovo? Cosa bolle in pentola? Ma guarda, in realtà, cosa forse mi onbolle in pentola, nel senso che penso che farò molti miei non published speech quest'anno, già te lo accennavo che non amo troppo questa parte, mi dedicherò più alla content creation, quindi nuovo blog, fabbiabiondi.dev e da lì partirà un po' tutto, dai, insomma, penso che qualche, creazioni contenuti, dai, la diciamo, diciamo la così.

Questo è un po' l'obiettivo di quest'anno, è migliorare il mio inglese, il mio primo speech in inglese, i pochi che farò cercherò di farli in lingua e come dicevate prima, eh, si, tocca farlo, come dicevate prima, è più importante l'inglese, forse, che non imparare a programmare.

Un salto nel tuo blog, io ti ringrazio nuovamente per essere venuto a trovarci, un abbraccio enorme e alla prossima, allora.

Ciao ragazzi, ciao ciao ciao.

Gitbar, il circolo dei fullstack developer.

Una volta a settimana ci troviamo davanti a due birre e con Brerepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev..