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.Bene, benvenuti in questo nuovo episodio di Gitbar.anche questa settimana.Eccomi qua! Però non vi romperò le scatole con uno dei soliti monologhi perché abbiamo un ospite super interessante qua che sta attendendo dall'altra parte del territorio nazionale.Perché, so, qualche chilometro di distanza ce l'abbiamo.Prima però di presentarvi l'ospite, lo sapete, il mio ruolo è quello di ricordarvi i nostri contatti.Info@gitbar.it via email oppure @brainrepo su Twitter per scrivermi.Mi raccomando iscrivetevi al gruppo Telegram o nel gruppo Telegram.Siamo già in tanti e ogni giorno ci confrontiamo su argomenti diversi.Però non voglio rubare altro tempo e vi presento il nostro ospite di oggi.Lo presento così, vediamo se s'arrabbia.Intanto lo introduco come Microsoft MVP.MVP recidivo, quindi occhio, nonché alchimista part-time.Se poi andate a spulciare nel suo profilo di github trovate una frase che è bellissima, per questo merita, secondo me, davvero mille stellette aggiuntive, che io non scrivo spaghetti code, piuttosto rigatoni.Abbiamo con noi Alessio Biancalana.Ciao Alessio! Ciao a tutti! Grande, guarda, come ho letto questa frase ho riso tra me e me per circa un quarto d'ora ed è fantastica.Guarda, la cosa che penso dei profili di tab, a parte come sentirete la mia pronuncia dell'italiano, non è perfetta come quella di Mauro perché...Sì, vabbè, la mia è perfetta, che stai a dio.L'ho contagiato da dove abito che, come sentirete, è a Bergamo Bassa.No, a parte gli scherzi di profili GitHub ne ho girati parecchi e questa frase è mia però è ispirata allo stile umoristico che tanti sfoggiano e che...niente, mi sono messo a ridere da solo quando ci ho pensato.È fantastica, credimi.Ma dovendo raccontare chi è Alessio Biancalana allo specchio, quindi lo racconti a te stesso, chi è? Chi sei? è un casino, è un casino Alessio Biancanone, nel senso che sono Senior JavaScript Engineer by day, alchimista part-time by night e poi parleremo soprattutto dell'alchimia e dell'alchimistica.Andando indietro, adesso sono Senior Software Engineer per WoodSuite, partiamo dalle cose serie.Mi occupo principalmente di front-end, di JavaScript e di veramente all things browser dentro la piattaforma di WoodSuite.Quindi, esposi le due anime, no? Alchimista di note, poi andremo ad approfondire cosa vuol dire alchimista e qual è il tuo ruolo oscuro, no? Esatto, il mio ruolo di oscuro signore.Esatto.Invece quello che faccio per vivere che è un lavoro vero che è signor software engineer a WoodSuite, holding browser.Cosa fate ad WoodSuite? WoodSuite è un prodotto per social media, è una immensa dashboard che consente a social media manager, agenzie e lavoratori di quel tipo di settore, di fare un milione di cose.La cosa principale che noi facciamo è pianificare la creazione di post su vari social network, tra cui Twitter, LinkedIn, Facebook, etc.La parte che segue il mio team, abbiamo tanti grossi tronconi.La parte che segue il mio team è quella delle sponsorizzate su Facebook, questo perché facevamo parte di una startup che è stata acquisita da Woodswith che è Adespresso e noi siamo il team originale di Adespresso.Woodswith ci ha preso e ci ha riallocato andando a fare quella cosa lì internamente, collocando poi sul mercato Adespresso una maniera un po' più enterprise e sviluppando delle alternative interne per chi non vuole mettersi a fare ads da power user, ma ha bisogno di una cosa un pochino più semplice.Per questo abbiamo fatto quello che il mio team e in maniera estesa il mio portfolio sta facendo in questo periodo che è Boost, che praticamente è una soluzione di Utsuit creare ads su Facebook e su LinkedIn in maniera molto semplice, diciamo, ci sono pochi settaggi, l'utente non si può perdere.Per fare cose più complicate c'è Woodstreet Ads, che è tutto un prodotto che è il derivato di Adespresso quando ci hanno acquisito, nel quale negli anni passati io, da primo sviluppatore front-end e andando poi a allargare il team con tanti amici, abbiamo integrato Google Ads all'interno di questa piattaforma e è stata tecnicamente veramente una grande sfida.Quindi tu ci sei praticamente dagli albori di Adespresso? Dagli albori no, nel senso che Adespresso è partita parecchi anni fa e è partita come un tool che ti consentiva di fare a bitesting delle pubblicità su Facebook, quando al tempo Facebook ancora non aveva la funzionalità integrata e è stata disruptive sul mercato, tant'è che in tanti dicono che Facebook ha copiato ad express quando ha introdotto la propria funzionalità di split testing.La cosa interessante è che poi, diciamo, consolidato, il calderone Facebook Adespresso doveva decidere in che direzione muoversi e in quel periodo ero entrato io come software developer.Io mantenevo una cosa che mi piaceva un sacco e che ancora oggi ricordo con tantissimo affetto che è l'asset manager di Adespresso, che consente di trattare le audience di Facebook, le immagini che carichi e tutte queste cose qua come una una sorta di explorer risorse di Windows, un grosso file manager per qualsiasi tipo di asset pubblicitario e a me piaceva un sacco questo progetto.Però una sera il mio team leader mi chiama e mi dice "guarda, ti comunico con mio sommo di spiacere perché andavamo molto d'accordo che cambi team, andrei a fare una cosa Greenfield, per oggi siete solo in tre a fare questa cosa, eravamo un team leader e due persone sotto il team leader ancora non faceva il manager e programmava e basta.E sarete in tre e farete l'integrazione dei Google Ads dentro ad Espresso e quella è stata la prima volta in cui non stavo in consulenza, quindi sai quando sei un po' buttato da qualche cliente e ti dicono "fai questo e lo devi tirare su", no? È stata la prima volta dentro una società di prodotto consolidata che stava facendo scale up comunque, in cui mi sono trovato a pagare poi le conseguenze delle mie scelte tecniche, diciamo.Fortunatamente non ho pagato così tante, Google Ads funziona abbastanza bene, l'integrazione dentro ad espresso, sono molto contento e dopo questo poi mi hanno cambiato team e mi hanno messo a fare un boost.Insomma, la vita dentro WoodSuite stata piena di sorprese, di dinamica.Ho sempre cambiato team.Cioè, in realtà, il team è rimasto sempre un po' quello.Abbiamo cambiato progetto tante volte e prima di quello c'è stata la startup blockchain, c'è stata la società di consulenza, c'è stata la partita IVA.Un po' come tutti credo, no? Sì, sì, alla fine è il viaggio che facciamo tutti.Si cerca di racimolare gli euri, si cercano di racimolare gli euri un po' qua e un po' là, ovvio.Dimmi una cosa, ed è una domanda che mi pongo spesso, quando tu lavori a un prodotto e non a un progetto, quando passi da una parte del prodotto, un elemento del prodotto o un prodotto a un altro, come vivi questo passaggio? Come un pezzo di cuore che lasci oppure lo vivi come qualcosa di più leggero? Allora dipende, la risposta come sempre dipende e diciamo che ci sono progetti e progetti, alla fine sono più o meno come i progetti, però praticamente il prodotto vive una, ha un suo life cycle e all'interno del prodotto vivono determinate determinate aree.Quando tu cambi prodotto, cambi sottoprodotto, chiaramente per quanto mi riguarda ci sono progetti che ho adorato e progetti a cui ho detto addio ben volentieri, ma non tanto perché erano una schifezza tecnicamente.Per esempio l'asset manager di Adespresso, lo ricordo con tantissimo affetto perché ci ho lavorato tipo sei mesi cioè nel senso non è stato troppo per stancarmi di quel progetto e dire no vabbè voglio fare un'altra cosa.Google Ads lo ricordo ancora più con affetto perché è una cosa a cui ho dato il via io, cioè io ho scritto letteralmente la prima riga di codice javascript di Adespresso Google Ads che era la tabella delle campagne e il primo componente React è stato quello e proprio la prima riga di questa cosa è stata Import React from React.Però dall'altra parte ho fatto quello per due anni, ho detto, vabbè, comunque si gociperava che ci avrebbero un po' riallocato, ho detto lo sai che c'è alla fine voglio nuove sfide, voglio nuove cose, quindi quando è arrivato il cambiamento, io poi quando arrivano i cambiamenti so sempre propenso ad abbracciarli, non faccio mai resistenza, quindi in realtà sono stato super contento.Spesso le nuove stime ci portano davanti a comunque nuovi modi per apprendere, nuovi contesti con i quali confrontarsi, anche perché poi alla fine se no si rischia davvero di entrare in dinamiche di stagnazione e anche a livello professionale stai buttando il tempo nel cestino e professionalmente il nostro tempo è l'asset più importante che abbiamo da giocare, l'elemento più importante che abbiamo a disposizione.Guarda, io personalmente la cosa che ho visto è che il modo migliore per misurare il...ti vorrei dire una parola da super acculturato che è "throughput" ma non è nemmeno così l'efficacia di uno sviluppatore e qualsiasi cosa, il rendimento nel tempo di uno sviluppatore, è prendere un altro team di sviluppo e metterlo a lavorare sulle cose che ha fatto quello sviluppatore.Meno cose devono riscrivere, più è alto il gain, il guadagno che hai su quello specifico progetto, e più sai di poterti fidare delle scelte tecniche di quella persona.Questa è una cosa che con Google Ads ancora non ci aveva avuto, e nel momento in cui è subentrato un altro team ho detto ok questo è il momento in cui se tutti quanti mi mandano a quel paese perché ho introdotto quella libreria, quello stack, ho adottato quel design pattern questo è il momento in cui qualcuno mi arriverà su Slack e mi manderà un Mortacci 2 fortissimo.Quel momento ancora non è arrivato credo credo di aver fatto un buon lavoro diciamo che non è sommerso di debiti tecnici da pagare il team che poi a quel punto la misura del debito tecnico avviene così no il WTF factor del team che sviluppa il progetto dopo esatto però proviamo per un attimo a sfogliare un po l'album delle fotografie e tornare ai primi anni no? io ricordo e poi ne ho avuto la conferma leggendo su internet alcuni articoli che ti riguardano, che sei stato autore di diversi pezzi per html.it, che fu pietra miliare della nostra cultura informatica.Sì, ormai io quando sono entrato in realtà a html.it era quasi alla fine, nel senso che io sono stato, non mi ricordo 4-5 anni, editor di One Open Source, che era uno dei principali blog del network OneBlog.Principalmente per me era un modo per guadagnare dei soldi mentre stavo all'università con una passione che era quella di scrivere e di correggere le altre persone che scrivono.Perché all'inizio ho iniziato come blogger, poi la redazione ha visto che se poteva fidare un po' di più di me, hanno detto "guarda, ti vorremmo proporre questa sfida nuova di fare tu l'editor in CIF, diciamo, e di lasciarti un po' più di banda, di briglia per html.it, per One Open Source".È stata un'esperienza fichissima, la rifarei, e sì, la cosa interessante che è sapere che ho comunque contribuito a quello che tanti consideravano sì come un must have nei preferiti, capito? Comunque html.it era veramente un punto di riferimento, soprattutto quando andavo al liceo per esempio e quindi quando poi ho parlato con la redazione, sono andato a fare le riunioni di redazione in redazione, è stato, cioè per me è stato un momento veramente emozionante.Assolutamente sì, guarda, io credo che html.it sia stata tappa in buona parte delle carriere professionali dei millennial che adesso lavorano nel mondo IT.Non possono non esserci passati.Tu pensa che io ho dei colleghi di università che adesso fanno i docenti e html.it è diciamo l'antologia per il docente.Voi perché la qualità dei contenuti per essere un prodotto Made in Italy riguardante quel settore specifico era molto alta? Sì, comunque le persone che c'erano erano preparate.Quando per esempio io prendevo un blogger per per integrare lo staff di One Open Source, preferivo gente che usava veramente Linux per esempio e quindi le persone portavano notizie fresche, cioè in generale le notizie che venivano consegnate erano magari recensioni proprio in prima persona dei software.Sì figlia dell'esperienza comunque.Sì sì era tutto, anche gli articoli dominione, i miei, quelli di Davide Ferrara, comunque erano scritti da persone che stavano in quel ecosistema là e quindi potevano portare quel tipo di punto di vista.La cosa interessante soprattutto è che la redazione, il far parte della redazione One Open Source presso la comunità Linux mi ha dato delle credenziali veramente interessanti per interagire con alcuni sviluppatori molto preparati e "distributori" molto preparati, principalmente gente dello staff di Ubuntu e Arch Linux.Comunque Arch Linux è sempre stata la mia distro Linux del cuore e vuoi vere il mio mio impegno è proprio in Arch Linux, nel senso che negli stessi anni ho impacchettato un po' di software per Arch Linux.Voi, l'effort speso su One Open Source mi hanno reso molto vicino, per esempio, a persone come Andrea Scarpino, che saluto, che non lo sento da un po', ma lui per esempio era la persona che manteneva KDE per Arch Linux, insomma c'erano tante scelte tecniche dietro ogni cosa che veniva fatta e ancora oggi viene fatta e aver avuto l'opportunità di interagire con queste persone e capire la ragione d'essere di quelle scelte tecniche è qualcosa che poi mi sono portato dietro nella mia carriera di sviluppatore.Infatti era la domanda che ti volevo fare cioè dovendo portare ad oggi quell'esperienza quali sono gli elementi che poi ritornano in quello che fai day by day? Allora, io in quello che faccio day by day ritorno innanzitutto, numero uno, anche se non è il mio job title, io sono la persona del mio team che più spesso mette mano alla pipeline de Jenkins della continuous integration e della continuous delivery, perché praticamente quando ho iniziato poi a lavorare come partita IVA ho fatto principalmente il sistemista perché quello era il mondo da cui venivo.In realtà poi che è successo? Che l'esposizione a questo tipo di esperienze mi ha permesso di fare tanta roba, nel senso che io perché so diventato un front-end engineer, perché comunque all'università del sistemista, capito? Infatti gli antipodi.Veramente assurdo perché praticamente che cosa era successo nel frattempo tra le cose a parte che javascript mi sono accorto che pagava un sacco di sordi ma questo in generale è una cosa che ogni professionista informatico si trova.Alessio javascript o cobble scegli tu, entrambi pagano bene.Io quello che voglio fare è fare bene sia javascript che COBOL, veramente.Io tengo la mente aperta.Tra l'altro c'è anche COBOL on COGS che è tipo Ruby on Rails.Questa non lo sapevo.A me piace in realtà quando uno mi dice...io mi studio qualsiasi cosa che mi capita sotto mano, quello è secondo me la cosa che ogni sviluppatore dovrebbe fare.La curiosità.curiosità e mantenere una mente aperta e uscire ogni tanto dal seminato, cioè dai paradigmi che conosci, come quello per esempio della programmazione oggetti, se vogliamo.Che è successo? Che mi ha fatto diventare un programmatore front-end? Non è l'unica cosa, però è stata la prima volta in cui ho fatto qualcosa che non fosse relativo all'ingegneria dei sistemi, proprio come la chiamavano all'università da me.Luca Ferretti e Flavia Paisic a un Linux Day a Roma, Luca Ferretti che credo ancora oggi sia il membro dello staff di Ubuntu e Flavia pure era di Ubuntu Italia, hanno fatto un talk sull'infrastruttura di X.Org, cioè del server X, il server grafico di Linux, e in quel momento io ho capito che non c'è non capivo solo i processi che erano istanziati da una shell ma mi interessava anche altro e quello è stato il momento in cui io ho cominciato a approcciarmi ai sottosistemi grafici diciamo per cui mi sono molto appassionato all'architettura del server grafico dell'evox e quel talk è stato illuminante io non so se è stato registrato ma dovrebbe essere se c'è su youtube poi lo vado a cercare lo mettiamo se ce lo mettiamo nelle note dell'episodio è veramente carino e quello là è un talk molto architetturale in cui spiega non solo i processi ma quello che dalle persone che hanno studiato viene detto ipc cioè inter process scommunication, cioè la comunicazione tra quei processi che vengono messi in piedi.Da là, chiaramente, lavorando spesso con internet, con Wordpress, eccetera, la passione per i motori di rendering e i browser era il passo dopo.Quando poi ho cominciato a a vedere che le mie capacità erano monetizzabili, in termini di codice, di quello che sapevo fare, che all'epoca era principalmente la Shell, ma poi è diventato pure JavaScript.A quel punto ho visto che l'effort che avevo speso su browser stava tornando indietro o qualcosa e quindi ho detto lo sai che c'è alla fine javascript dirò qualcosa per cui gli ascoltatori mi diranno che so tipo Gianni Morandi però me piace.Stava già diventando un pochino funzionale stava gli applicazioni si architettavano in maniera già diversa per non avere casini con la keyword is no? No ma poi tra l'altro probabilmente coincide con quel momento in cui la complessità della parte front end si stava sviluppando e tu hai detto una cosa molto importante che io condivido e la condivido anche con altri amici tra l'altro è una cosa che condivido anche con Francesco Sciuti altro MVP di Microsoft che è il fatto che è importantissimo conoscere lo strumento dove gira il tuo codice, cioè la conoscenza delle web API del browser è fondamentale nel momento in cui stai andando a lavorare con il browser e tu mi confermi questo dicendomi io son partito da conoscere il browser, come funzionava per poi arrivare a JavaScript e trovarmi a mio agio.Questo, guardate, facciamo un altro passo, non solo questo ma poi quando ho iniziato lavorare con JavaScript, io ho avuto la fortuna anche di lavorare con persone molto preparate, per esempio Paolo Mariotti, che saluto se mai ascolterà l'episodio del podcast, che è stato il mio mentore quando poi sono approdato al JavaScript sul lato professionale, e lui la prima cosa che ha fatto mi ha regalato una copia del JavaScript dei GoodParts.e ce l'ho in libreria, purtroppo non ce l'ho qua perché ce l'ho a casa dei miei, però praticamente che è successo? Io mi sono studiato javascript siccome io le cose, come ho detto pure prima, me le studio abbastanza bene, quello che è successo è che mi sono andato a studiare javascript per come funziona javascript e quando poi ho approcciato cose non volendoli chiamare framework perché non tutti sono framework ma librerie framework entità software di peso diverso tra react angular io ho scritto pure software in angular 1 e ho scritto un sacco di jquery in vita mia e ragazzi prima di react non c'e stava dollaro.Io ricordo con piacere prototype.js, modules che tra l'altro stavo provando a cercare il creatore adesso non ricordo il nome ma un italiano tra l'altro.Firebug si a voglia, c'e stava un sacco di roba e quello che è successo è che io mi studiai javascript come semantica base e poi la riapplicai ogni volta che mi sono studiato qualcosa tipo Angular, tipo React, tipo Vue.js, che ne so, tipo Svelte.Poi dopo un po', qual è stato il segno di maturazione? Che invece di fare domande sui gruppi di Facebook, ho cominciato a rispondere alle domande sui gruppi di Facebook e spesso il pattern di domanda più simile su un gruppo di Facebook su Slack o su Discord o su Telegram, non lo so, è "perché non mi funziona questo?" E molto spesso il pattern di risposta è "perché non hai capito come funziona JavaScript?" Nel senso che tante volte, che ne so, becco anche persone, volendo fare un esempio leggermente più fuori da questo, tante volte becchi persone che non sanno come funziona la programmazione asincrona, cominciano a scrivere il codice con un sacco di promise innestate e poi dicono "ah no, però c'è il promise L, il callback L, sì ok, quello è una realtà vera, però finché tu non stai scrivendo una business logic veramente allucinante è difficile che in realtà vai a sbatte al callback L".Magari se tu riarchitetti un pochino il codice, se hai capito come funzionano le promise, se hai capito che non c'è sta solo promise.resolver oppure bromist.org per esempio, magari facendo qualcosa di leggermente fatto meglio riesci a non sbattere la cavoccia.Sì, ma poi vedi anche errori banali tipo o hosting non compreso bene o TDZ.Quindi in realtà sì, la cosa più importante è veramente capire come funziona sotto il cofano le cose.ne parlavo da poco, adesso non ricordo in quali episodi ma quando parlavo di framework, cioè noi utilizziamo dei tool che ci semplificano la vita, che automaticamente ci risolvono dei problemi, ma se noi capissimo dove sta l'automagia probabilmente sì, potremmo continuare a usarla, ma con una consapevolezza diversa che mi può anche dire ok, oggi quell'automagia non mi serve, ho bisogno di altro per risolvere questo tipo di problema.Per esempio, io una cosa che odiavo un sacco, per cui mi sono battuto, è stato redarguire i miei colleghi riguardo l'uso di Async/Await prima che venisse supportato da Node, perché c'erano delle bellissime Transform the Bubble che prendevano il tuo Async Await e lo mandavano, diciamo lo trasfilavano in codice che runnava Telepromise.Scusate siamo in un podcast italiano e runnava è una cosa bruttissima da dire però non ti preoccupare.Semplicemente io la cosa che dice "guai, regà, ma voi sporzatevi dei capi le promise soprattutto perché siete persone intelligenti, cioè non è che siete usciti adesso dal liceo e non capite come funzionano le promise, attenetevi ai costrutti nativi del linguaggio".Poi quando è arrivato la SYNC-A-WAIT ho detto "vabbè, io personalmente adoro la sintassi delle promise perché è dichiarativa e funzionale, cioè nel senso è dichiarativa, è asincrona e ti permette di toccare con mano la sincronia di quello che stai facendo.Async/await è a un livello sopra, quindi tante volte per non scordarti, per non fare await ogni due righe dei codici, tante volte è meglio che cambi paradigma un pochettino.Invece le ho dei colleghi che stanno a rota quasi tutti.Quindi è stato un momento veramente divertente in cui anche là da JavaScriptaro poi ho imparato ad affrontare quel tipo di dibattiti tecnici non solo con persone che ne sapevano meno di me ma anche con persone che ne sapevano quanto me, che lavoravano per un'azienda di mille persone e che semplicemente erano convinte del contrario, lo sta? Secondo me la svolta sta nel momento in cui siamo in grado di capire quando è il caso di usare Async/Await e quando è il caso di usare le Promise.Se noi arriviamo a quel punto probabilmente abbiamo raggiunto un buon livello professionale.E' lo stesso discorso che facevo da poco su un corso ho ottenuto un corso su React e quando ho spiegato il paradigma Redux poi il mio inglese è un po' come...però quando ho spiegato quel paradigma la cosa più importante era proprio capire il paradigma al di là del fatto che tu lo applicassi in un modo o in un altro.Tu devi capire come funziona la macchina.C'è un bellissimo libro di Francesco Strazzullo sul concetto del frameworkless che ha proprio come base questo tipo di ragionamento cioè tu capisci come funziona bene una cosa.Adesso là siamo a un livello un pochino diverso, siamo un pochino un altro livello, un livello un pochino più alto, però se tu capisci come funziona lo strumento che stai usando tu lo pieghi per quello che serve a te oppure probabilmente dici "no ok non mi serve questo questo mega palazzo per fare sta cosa, posso farmelo con tre righe di vanilla javascript e nessuno...A volte è possibile, a volte no, o soprattutto impari che cosa ti fornisce il framework rispetto alle tre righe di vanilla javascript perché ci sono per esempio 10.000 articoli su Medium che ti spiegano come scriverti la tua versione di React Però effettivamente poi quando lo fai capisci anche tante cose che React fa che magari tu nella tua implementazione non curi, trascuri e impari a usare quelle.Dici "ah, io a quel punto ho la risoluzione dei context", mi ho perdito una cosa che ho letto qualche tempo fa, perché ho letto come funzionano i utes, bene, dopo mesi che li usavo e ho detto "ah, forse fammeli studiare un po' più sotto il cofano".Che ne so, c'è la risoluzione dei context che React va in un modo assurdo, magico, fichissimo e secondo me quella è la stessa cosa che tu ti leggi da solo e dici "ah, ammazza, questa cosa è figa" e migliori come ingegnere del software anche perché impari qualcosa di nuovo che non è necessariamente costruire un API ma è, che ne so, come risolvere context all'interno dei React.Anche modelli di pensiero, cioè come altri sviluppatori hanno approcciato a un problema per studiare un'eventuale soluzione.Però torniamo per un attimo al mondo dell'open source dal quale siamo partiti.Per un attimo mi piacerebbe chiederti intanto quali sono i fronti open source dove sei attivo, operativo, dove spendi il tuo tempo.Dico spendi e non monetizzi il tuo tempo per ovvie ragioni.E poi cosa questo tipo di esperienze hanno portato nella tua vita professionale quella che poi invece converti in denaro, in moneta sonante? Allora innanzitutto siccome io sono una persona, l'unica cosa che so veramente bravo a fare è fare economia del mio tempo, nel senso a me non piace lavorare a vuoto e sono una persona molto pigra.Quindi rispondo subito alla seconda domanda, tutto quello che io ho fatto nella mia vita professionale è stato in qualche modo portato dai progetti open source, nel senso che comunque la visibilità che ti costruisci e l'aura di autorevolezza che ti crei attraverso un progetto open source, secondo me al giorno d'oggi è impareggiabile, anzi forse è pareggiabile solo dal dire "ho lavorato 4 anni a Facebook".Se un progetto open source di successo o comunque un numero di contribution adeguato, alto, per me significa quello, significa fare parte di un collettivo tra virgolette, di persone che stanno imparando cose alla velocità della luce.E questo te lo permettono solo determinati tipi di team e di aziende, che sono i team che io, per esempio, adesso da senior developer, mi occupo di creare e di mantenere.Cioè quei team che costantemente si scambiano risorse, che ne so, approcci, design pattern, mente aperta e anche qualche ceffone quando serve perché uno dice "oh no, sta cosa fa cagà" e quello è una cosa importante però perché significa dare feedback, saper dare feedback non necessariamente in maniera maleducata, però soprattutto in maniera aperta.Per quanto riguarda i fronti su cui sono attivo ultimamente, la cosa di cui abbiamo parlato anche prima Piero Lequinte è Apache Foundation, perché qualche anno fa è successo che mentre ero a una conferenza su Elixir a New Orleans, mi è arrivato un tweet di un amico che mi diceva che Apache CouchDB cercava persone che estendessero la suite dei test di integrazione che era tutta scritta in Elixir e questa persona mi ha detto "questo è un lavoro per te" e io all'inizio pensavo di non capisce niente, non so se mi senti bene perché io nel frattempo ti vedo un po'...Sì, sì, ti sento, ti sento.Ah, ok.Io all'inizio pensavo di non capisce niente perché non avevo in realtà mai messo le mani su un progetto open source di quella entità grossa, perché CouchDB ha tipo un mille anni e soprattutto così in profondità, nel senso andando subito a scrivere codice senza occuparmi di altre cose.Io personalmente preferisco iniziare magari con qualche traduzione, iniziando magari leggendo qualche issue molto lentamente, invece là ho visto effettivamente un segno di maturazione anche come software engineer, è stato che ho preso il progetto e un segno anche bellissimo di maturità per il progetto è stato che io l'ho preso e tempo di arrivare in albergo e lanciare due righe di bash e ero operativo e ho cominciato a scrivere questa...a estendere questa suite di test di integrazione in Elixir che sarebbe dovuta andare a sostituire la suite di test di integrazione che c'era, che era scritta in javascript, loro la volevano portare a Elixir perché CouchDB è tutto scritto in Erlang e avendo la suite del test di integrazione scritta in Elixir praticamente avrebbero avuto la suite del test scritta e eseguita soprattutto con la stessa virtual machine con cui girava anche il database.Quindi avrebbero semplificato lo stack, no? Avrebbero praticamente semplificato lo stack e tra l'altro Elixir ci avrebbe avuto qualche e qualche buon punto a favore anche verso la sintassi perché sarebbe stato tutto uguale sostanzialmente anche a livello dei processi oriented design, per esempio.E...effettivamente ci siamo riusciti, è stato un finale buono, nel senso che qualche, mi pare un mese fa, è arrivata la mail della project leader che stava spegnendo la suite test JavaScript perché avevamo fatto un buon lavoro, esatto.È stato un effort grosso perché è stato, cioè è durato tipo due anni e comunque all'interno di questo c'è stato il fatto che la Apache Foundation ha notato la mia e altre contribution e a noi che mantenevamo questa, ma mantenevamo si dice in italiano, non lo so, noi che aiutavamo con questa con questa suite di test ci hanno proposto di diventare committer proprio all'interno del progetto, il che significa che adesso abbiamo diritto di veto e di voto su qualsiasi decisione tecnica presa dal committee di CouchDB perché poi Apache Foundation è divisa in n progetti e ogni progetto ha il suo committee e i suoi executor, i suoi programmatori.E anche una bella stellina nel curriculum è un grande valore a livello professionale no? Effettivamente si, ha giocato un valore anche a livello professionale perché quando è stato il momento di rivedere le mie performance anche con i miei capi insomma, tra le voci c'era che ne so, fa tipo volontariato e attivo all'esterno dell'azienda su qualche progetto software e non io ci ho potuto mettere la OCD.Capito questo è molto interessante anche se ho visto ho visto che tra i tuoi linguaggi non c'è solo Elixir ma mi è sembrato di vedere un tuo progetto che si chiama Siren.Ah, grande! Allora è studiato! Scritto in Rasta, ma io studio sempre, mi chiamo 007, nel senso che vado a indagare, a guardare le ripo di tutte le persone con le quali vado a chiacchierare, anche perché poi ho bisogno, sono curioso, ognuno sviluppa la curiosità.Io sono un po' come si chiama quel giornalista che fa la testa della rivista scandalistica.Ah no io non ti posso aiutare.Ma neanche io sono super ferrato.Insomma sono il novella 2000 per tornare indietro.No scherzo però ho visto questo progetto.Puoi dirci qualcosa in più e soprattutto dirci perché hai scelto Rust come linguaggio? - Ah, allora, mo me stai veramente a mette la carne sul barbecue.Praticamente, allora, il discorso è questo.Io ho preso delle macchine in affitto da un cloud provider che costa molto poco e che me le ha fatte pagare Lifetime una cifra ridicola.Solo che queste macchine, siccome costano molto poco, cascano un botto.Cioè, cascano tipo una volta a settimana.La cosa che io volevo era controllare l'uptime di queste macchine, se erano su, se erano giù, e se i software che c'erano deploiati sopra, software che scrivo io così, tanto per bot di Telegram o altro, se i software che c'erano deploiati sopra stavano su o giù.Quindi come prima cosa ho detto, uso Nagios come soluzione di monitoring per controllare quello che sta su quelle macchine e se i servizi rispondono.Però ho detto "così mi servirebbe un altro server, dentro quella stessa infrastruttura, che cadrebbe pure lui".Quindi questo non è una soluzione viable.Quindi mi sono scritto una versione mia di Enagios, che si chiama Siren appunto, che è praticamente un...è la stessa cosa di Nagios, nel senso che è una specie di motorino di Nagios che praticamente tu esegui dalla command line, lui si prende un file JSON che tu gli dai in pasto ed esegue gli script che sono gli stessi che possono essere usati anche come check di Nagios, rispetta quella specifica tranquillamente, perché è una specifica basata sugli exit code del processo che fa il check, e praticamente controlla senza bisogno d'endemone, ma on demand, con un comando da riga di comando, se una macchina sta su o qualsiasi altra cosa, nel senso che è scrittabile, perché rispetta le specifiche di Nagios.Ho scelto Rust perché mi servivano delle prestazioni alte, semplicemente perché volevo...questo qua è un esperimento di system programming.I linguaggi che vanno per la maggiore per il system programming sono il buon vecchio C, Go, che già conoscevo e che è alla base di tutti i nostri servizi dentro WoodSuite e quindi non mi interessava perché volevo fare qualcosa di nuovo.volevo studiare Rust e comunque mi avrebbe permesso di avere un eseguibile che aveva un determinato, diciamo, grado di rendimento a livello di performance.La cosa interessante è stata che ho toccato con mano il fatto che, qua comincia veramente la parte da testimone del Geo, quindi non so se poi la taglierai, Però la cosa che ho verificato con Manu è che Rust, grazie al type system, grazie a un approccio funzionale e grazie a un po' di goodies, di magia che prende da un mostro sacro che troppo spesso viene citato per la sua complicazione estrema, in realtà io lo adoro un sacco, che è Haskell, Rust consente comunque di avere una correttezza formale del codice che viene scritto, che diciamo che a livello di errori a runtime ne dà abbastanza pochi.Questo è stato un side effect allucinante.L'altro side effect è stato che io l'ho scritto, Siren, e l'unico momento in cui ci ho rimesso le mani sopra era per aggiungere la serializzazione dell'output in JSON per potergli scrivere un demone sopra che facesse tipo un agios per esercizio e quella cosa l'ho scritta nell'exe.La cosa allucinante è che io non ho dovuto mai toccare il codice, perché se compila e se il compilatore ti dice che va bene così, quello funzionerà tipo per sempre, che è detto da una persona che scrive Java, scrive linguaggi interpretati, fa ride.Però effettivamente io ho scritto anche Java tanti anni quando stavo in consulenza e un livello di certezza di questo tipo non ce l'ho mai avuto, e un livello di certezza di questo tipo non ce l'ho avuto nemmeno quando facevo i progetti in C per l'università, perché in realtà c'avevi sempre il caso in cui c'avevi che ne sono stack overflow, impuntatore, eccetera.Quello che ti consente di avere RAST è invece anche il meccanismo di verifica delle variabili che vengono usate e del loro life cycle.L'ultima cosa allucinante è che io non conoscevo Rust, cioè semplicemente io ho iniziato a scrivere codice leggendomi proprio tipo testo a fronte con l'Odyssea, mettendo il manuale da una parte e l'editor di testo da un'altra.Quello che è successo è che io cominciavo a fare a botte con il compilatore per far funzionasta fare.La cosa allucinante è che quando io ho...quando la cosa ha funzionato, io ho ritenuto di aver scritto del pessimo codice perché avevo fatto a botte con il compilatore per farlo funzionare, ma siccome il compilatore Terasta è fatto talmente bene che ti dà degli insight allucinanti esatto e ti consente di andare solo sul percorso dritto, quando poi ho riguardato il codice mio ho detto "oh, vedi, ma chi l'ha scritto questo codice, è veramente figo!" e niente, quindi per quanto riguarda piccoli eseguibili, tool, etc., etc., Rust è veramente una cosa che non tanto sul curriculum, perché non lo conosco così bene, ma nella mia tool belt personale lo metto più che volentieri.Sì, poi tra l'altro è un linguaggio che adesso si trova proprio nella cima dell'hype.Sì, come è successo a Elixir quattro anni fa.Esatto, però la cosa interessante è che per esempio Dino è stato inizialmente iscritto in Ingo, poi è stato ripreso tutto e riscritto in Rust per ovvi motivi di Garbage Collector, ne abbiamo parlato.Sì.Al suo tempo però è molto interessante e dimostra anche il fatto che non ci si deve fossilizzare su un unico linguaggio ma andare a provare diversi linguaggi ci apre la forma mentis e per cui io immagino che anche quell'esperienza di scrittura in codice di scrittura di codice Rust abbia portato comunque del valore alla tua professione di sviluppatore javascript.Io mi convinco così come il fatto di dover scrivere del codice elixir.Ma ti tengo ancora buono prima di farti indossare i panni dello stregone perché voglio sapere qualcosa in più di CouchDB.Guarda, ti dico solo un'altra cosa.Vai, spara.Il The Pragmatic Programmer, che è un libro che penso che debbano leggere tutti di quelli che si avvicinano alla disciplina e alla professione, che sono due cose diverse del software development, ti dice che devi imparare un linguaggio l'anno.Non ci stanno secondo me così tanti linguaggi che valga veramente la pena imparare, però effettivamente la trovo giusta, è un'osservazione completamente corretta, perché tante volte uno si fossilizza sempre sugli stessi pattern che sono i pattern poi sponsorizzati dalla piattaforma su cui stai e in realtà tante volte invece è veramente figo vedere qualcosa di strano.Guarda Alessio, lo dico sempre questo ma voglio ripeterlo, sul fatto del linguaggio a me piace ricordare questo ragionamento con una frase che mi disse una mia amica poetessa che ormai non c'è più che disse "guarda Mauro una cosa molto semplice impara una lingua perché le tue lingue sono i modelli con i quali crei i tuoi pensieri più lingue conosci in modi diversi in più modi tu puoi sviluppare i tuoi pensieri e quindi sei senza dubbio una persona che pensa meglio non solo che pensa di più ma che pensa proprio meglio" e allora siccome abbiamo introdotto un po' l'exilio, c'era una frase che spulciando sulla rete ho trovato, che dice un professore di Yale che si chiama Alan Persil, che dice una cosa che io sposo al 100% e dice "il linguaggio che non cambia il tuo modo di pensare non vale la pena che sia studiato" cioè non perdere tempo a studiare dei linguaggi che non alterano, modificano, evolvono il tuo modello di pensiero.E' così, io sono completamente 101% d'accordo.Io voglio...io so...come si dice in inglese si dice "I champion it" in italiano non so come dire...Ci metto il timbro va benissimo.Me ne faccio veramente portatore di un valore del genere.Assolutamente sì, questa cosa è molto molto importante.Però torniamo per un attimo a CouchDB.Che cos'è CouchDB? Allora CouchDB è un database.La cosa mi fa molto ridere che tu mi chieda questa cosa nel senso che io mi sono approcciato a CouchDB come contributor.Mazzo, ok.Mi sono mi sono approcciato a CouchDB come contributor perché era una pipa con i database e quindi volevo imparare a progettarne uno.Dopo mille anni non so ancora come progettarne uno però so molto bene come funziona comunque.Allora, CouchDB è un database, è un database non relazionale che consente di memorizzare dei documenti al suo interno.Detto così, sembra molto simile a MongoDB, e lo è.La differenza è che, innanzitutto, delle cose allucinanti perché è scritto in Erlang e in C.La cosa veramente carina è il Sync Multi Master, cioè praticamente tu puoi mettere due o tre istanze, ognuna con i suoi replica set, e queste istanze però possono parlare tra di loro attraverso il meccanismo dell'Erlang cookie e praticamente attraverso vari master tu puoi tenere in sincrono varie master copy dello stesso database e questa è una cosa che non lo so, da pippa con i database appunto io penso che nessun database faccia una cosa del genere, cioè multimaster sync è una cosa che quando l'ho vista mi ha esplosa la testa.L'altra cosa interessante è quella di creare delle proiezioni, dei propri dati, attraverso i design document.Praticamente tu uploadi un documento di design, che è un documento che risiede all'interno del tuo database, di cui quando tu fai la query, lui semplicemente fa la query a sua volta perché c'è un query language interno che è in javascript e praticamente tu gli passi queste funzioni e è un json praticamente chiami tu passi le funzioni viene fatta la query, costituiti i dati come tu li hai progettati e questo è un meccanismo alternativo a quello delle query SQL dei database.È una cosa con cui all'inizio ho fatto un po' a botte, però effettivamente poi che cosa ti consente? Ti consente di avere delle applicazioni molto scarne nella parte di modellazione del dato, perché semplicemente la modellazione del dato viene fatta attraverso i design document e tu semplicemente mandi la query al database per per quel documento ti vengono ritornati i dati, con CouchDB si parla in HTTP REST e quindi semplicemente come il motto del database è "relax" perché tu in teoria stando sul tuo divano col cellulare sono i dati che arrivano da te, non sei tu che devi andare dai dati.Mi piace tantissimo il concetto alla base di CouchDB.Ne abbiamo parlato a suo tempo con (c'è un ritorno, Alessio, scusami) ne abbiamo parlato a suo tempo con Max Sinek, il maintainer di Hospital Run che utilizza tra l'altro CouchDB con PouchDB nella parte frontend e la cosa è fighissima perché lui mi disse "guarda Mauro noi abbiamo ridotto quasi a zero il codice back-end" perché buona parte del lavoro lo facciamo fare al sistema di sincronia dei database.Ci sono dei sistemi di ACL che ci permettono di gestire bene i diritti e noi la parte di back-end puro la utilizziamo solo per interfacciarci ad API esterne per l'importazione dei dati altre cosettine che riguardano standard medici e così di questo tipo.E la cosa è molto interessante specie per quei sistemi che permettono il concetto di offline perché tu hai CouchDB alla prima connessione, si sincronizza tutto con il sistema di gestione dei conflitti, di redeem dei conflitti, per cui è veramente interessante.Un altro concetto che mi ha affascinato.Ripeto, non l'ho studiato CouchDB, so di CouchDB quanto posso saperne di neurochirurgia, quindi pari praticamente a zero, però mi è sembrato di vedere che utilizza ampiamente dei concetti presi dal mondo dei big data, come il concetto di MapReduce.CouchDB ha MapReduce, a voglia.Semplicemente all'interno del design document, quando tu fai le query, oltre a definire la shape del dato che ti viene restituito, puoi definire all'interno del JSON una funzione di map e una funzione di reduce.Questo è particolarmente utile per quando hai Big Data, per cui non hai il bisogno per forza per i tuoi dati di tirarti su, che ne so, Apache Adobe, queste cose qua, o ClusterFS, ma semplicemente puoi avere uno stack un pelino più semplice anche da amministrare.Da amministrare soprattutto perché la cosa che mi ha colpito dei CouchDB è soprattutto la parte di provisioning di un cluster, perché chiaramente i repository sono 200 dei CouchDB, il centrale è CouchDB, ma poi ci sono una serie di repository satellite, Un repository che seguo con tanto amore, perché lo sto studiando comunque in questi mesi, è l'ELM Chart dei CouchDB per Kubernetes.Anche quello è mantenuto dalla Paci Foundation e dai maintainer dei CouchDB, e comunque è molto facilitata la messa in produzione di un cluster di CouchDB.La via, fa tutto lui.No, piuttosto mi chiedevo una cosa.Tu dici noi le nostre query fondamentalmente le strutturiamo attraverso la definizione di un documento, no? Volendo, nel quale definiamo la struttura dei dati di ritorno.E l'API è un API di tipo REST.Unire questi due concetti A me portano un'associazione di idee, dimmi se è una blasfemia, ripeto, non conosco Cao CDB quindi potrei dire un c***o, censurami.Però mi riporta alla mente il concetto di GraphQL.Fammi pensare, allora è ancora di più, nel senso che GraphQL ha il, la spec è definita comunque dal server, la spec del dato, e tu semplicemente chiedi, definisci la shape, però chiedi comunque determinati field.All'interno di CouchDB questo è ancora di più spinto su un altro livello perché sei tu che passi una shape e dici "fai questa query, mappala su questa shape e ritorna i dati in questo modo" quindi è ancora di più.Perché scende a un livello più profondo.Sì, scende a un livello assolutamente più profondo.cioè il design document è un documento che fa design della specifica del dato che poi ti verrà ritornato.E questa è una cosa, è una cosa figa, perché nel momento in cui, per esempio, il front-end ha bisogno di determinate, di determinate chiavi, determinati valori, eccetera, eccetera, si può abbandonare il conflitto, tra virgolette, tra back-end e front-end che tante volte avviene sulla definizione dei contratti e semplicemente mandare...non so se non te vedo più, non lo so...Ci sono, ci sono, ti sento benissimo.Quello che avviene è che quando tu hai il conflitto tra back-end e front-end nella definizione del contratto, ti stavo dicendo, puoi attraverso il design document abbandonare questo tipo di conflitto, semplicemente lasciando gestire al front end la cosa, perché lui ti uploada il documento di design, è ancora più, come te posso dire, più profondo di GraphQL, che invece utilizza una metodologia diversa perché ti obbliga in qualche modo a far sedere tutti gli stakeholder intorno al tavolo per dire ok questa è la nostra API con i nostri concetti.Questa è la base.Esatto questa è la base.Io ho lavorato con tutti e due con molta soddisfazione con CouchDB molto di più a livello dei test di integrazione però...No, mi chiedevo perché un po' ritona, quando vedi che CouchDB implementa l'interfaccia REST, la questione dei documenti, dici "ma caspita, aspetta, faccio uno più uno?" Dico, un po' ci avviciniamo al mondo GraphQL.E mi chiedevo, a questo punto, allora perché CouchDB non implementa un'interfaccia simil GraphQL? Questa era la domanda che mi facevo.Io dovrei cercarlo, perché sicuramente qualche add-on di qualche tipo c'è.Non lo so.Potrebbe essere una PR che potrei fare da qualche parte.In realtà, Cautly B consente anche un'altra cosa, che è l'implementazione di Query Server Custom.e secondo me quello è un altro modo in cui si possono integrare GraphQL e CouchDB questo è interessante, c'era un'altra cosa dell'ultima domanda promesso che faccio su CouchDB ma è un dubbio che mi porto dalla puntata che ho fatto con Maxim se io mi posso interfacciare direttamente lato frontend al mio database utilizzando queste API REST che poi magari posso proxare, tutto quello che ti pare.Però lui mi parlava di un sistema di ACL evoluto e di utenza evoluto.In realtà io non riesco proprio a immaginarmi come possa funzionare e come possa essere configurato.Riesci a darmi qualche informazione per snebbiare un po' questa questa visione? Allora ad oggi io credo che i test sulle ACL siano pochi quindi userò le conoscenze che ti distillo adesso anche per andarne a scrivere qualcuno, però praticamente funziona così, tu sei un utente e fai una query e in base chiaramente, per esempio ad oggi, CouchDB 3 ha anche il supporto a JWT, a JSON Web Token, quindi le le informazioni del tuo utente vengono deserializzate e decriptate.Sei l'utente Mauro, magari l'utente Mauro rispetto all'utente Alessio ha dei permessi di lettura un po' differenti che tu puoi settare all'interno del database proprio.Cioè ci sono le ACL attraverso cui tu puoi definire determinati permessi per determinate utenze, sì.Questo viene fatto a livello proprio utente così grezzo, viene fatto attraverso una cosa che è la Web UI di CouchDB, che si chiamava un tempo Futon, poi quando l'hanno rifatta con con React e vari altri componenti, si è chiamata Falkston.Non so se sia veramente il nome pubblico, però effettivamente si chiama così.C'è la WebUI, tu attraverso la WebUI dici "guarda, per tutti gli utenti applica questi permessi, per questo utente applica questi permessi in più", puoi restringere o allargare la vista un utente ha dei dati in maniera abbastanza semplice e semplicemente il server quando arriva la query poi applica le ACL e ti dice guarda c'hai i permessi oppure no non c'hai i permessi e tornata dove sei venuto questo è abbastanza il...Adesso mi è più chiaro anche perché questo magari è unito a un approccio da usare CaosDB come event storage a quel punto hai praticamente tutto, hai le ACL, usi per memorizzare gli eventi, quindi gestisci anche i conflitti.Lo usi sempre come event store, però per esempio agli utenti non darai permesso in lettura a quella specifica collection.Certo, grazie.Grazie che hai un po' snebbiato la prospettiva.Nebbia che ci mette pochi secondi a riformarci perché cambiamo argomento ed entriamo nel mondo alchimistico, se così si può dire, di Elixir.Allora, premesso che io sono una capra ignorante, per ciò che riguarda Erlang ed Elixir le mie conoscenze si basano su 45 minuti di un talk del 2015, di un Code Motion del 2015 e basta, niente più.Quindi la prima domanda che ti vado a fare è che cosa è Elixir e perché hai scelto Elixir come linguaggio da andare ad approfondire e non un altro? Allora, Elixir è un linguaggio di programmazione, ti faccio tipo Wikipedia, Elixir è un linguaggio di programmazione.Il...praticamente come funziona? Il linguaggio in sé, come semantica, è molto simile a Ruby e questo perché la necessità storica di Elixir era che...è stata che Jose Valim, il creatore, stava facendo la sua tesi di laurea e la sua tesi di laurea che gli è stata assegnata, non mi ricordo se era la tesi di laurea oppure un task al lavoro oppure tutti e due, però praticamente gli è stato chiesto una di quelle cose tipo "non tornerai mai vivo" di rendere Ruby thread safe e lui all'inizio ci ha provato, solo che ha dovuto riscrivere mezzo ruby.Poi a un certo punto, sempre in virtù di quello che dicevamo prima, si è studiato un po' di Erlang.Ora, che succede? Che Erlang funziona in una maniera del tutto particolare, perché oltre ad avere le istruzioni classiche tipo, mi viene da dire tipo "if then else", ma Erlang non c'ha, tra virgolette, nemmeno quelli, perché c'ha tantissimo pattern matching Erlang dentro.Però praticamente, oltre ad avere istruzioni più tradizionali, Erlang ha un approccio alla concorrenza molto spinto, perché all'interno della virtual machine di Erlang vengono utilizzati quelli che in quel contesto si chiamano processi, che sono molto simili a dei processi del sistema operativo, però hanno un tempo di start-up e di preparazione molto basso.Vengono in particolare utilizzati per fare quello che si chiama actor modeling, cioè praticamente prendi un processo e trattalo male, nel senso fagli fare solo una cosa, fallo reagire a determinati messaggi, solo a quelli, e in questo modo fai una separazione delle preoccupazioni e dei mestieri molto simili a quella che fai con la programmazione per funzioni, però schianti le cose direttamente dentro i processi e quelli diventano delle entità impenetrabili, se non attraverso i messaggi.Cos'è Valim se legge sta roba? E dice "fermate, questo è molto meglio di quello che sto a fa' io", per cui decide di cambiare paradigma, decide di scrivere.Siccome Erlang si presta alla creazione di linguaggi basati su Erlang, attraverso l'uso delle macro e della metaprogrammazione, lui decide di inventare un linguaggio che semplicemente traspila nel codice della compila, anzi perché è bytecode, nel codice compatibile con la virtual machine di Erlang e che fa uso di queste cose qua come primitive di concorrenza.e chiama questa cosa Elixir.Quindi Elixir è un linguaggio di programmazione che gira sulla virtual machine di Erlang, fortemente orientato alla concorrenza, con cui si possono fare un milione di cose diverse, e che usa non solo la parte di processo oriented design per il codice, ma ha anche una buona, buonissima sintassi molto dichiarativa e molto espressiva, per cui a volte se l'ha scritto qualcuno di veramente magico e stregonesco non si capisce niente, però in realtà con un po' di allenamento dell'occhio, in realtà ci sono tante cosette carine che vale la pena approfondire.Quella è stata la prima volta con cui sono venuto a conoscenza e in familiarità col pattern matching che per me è stato una svolta cioè non dove più scrivere 400 if ma solo 400 richiede codice corrispondenti ai vari casi dello strategy pattern per esempio che sta implementando è stata una bomba.Guarda io ho conosciuto il pattern matching grazie a una presa da parte di mia moglie che è una programmatrice matrice Scala, le sviluppa Scala, ha guardato il mio codice, ha visto case, if, dice "Paolo, ma cos'è sta roba? Cancella tutto e scrivi su Scala".Eh, forse no, però in realtà poi guardando il suo codice dici tre righe, tre casistiche diverse analizzate e risolte in modo così pratico che il giorno dopo ho aperto, ho svuotato il mondo cercando il pattern matching, un modo per implementare il pattern matching in TypeScript.E ci sta, hai trovato il PTS di Giulio Ganti.Esatto, infatti tra l'altro devo cercare di portarlo qua su GitBar perché secondo me c'ha tanto da raccontarci.Per chi non lo sapesse, Alessio, che cos'è il pattern matching? Allora, il pattern matching è difficile spiegarlo senza una lavagna a disposizione, ma solo per audio messaggio.È una cosa tipo un if con gli steroidi, nel senso che praticamente tu dichiari una variabile, tra virgolette, in entrata, o semplicemente il risultato di un'espressione, e poi dichiari vari casi, vari pattern, appunto, attraverso cui questa espressione può risultare.E che ne so, cioè, semplicemente lo se il numero è pari o dispari, e dichiari tutti questi casi che possono essere, nel caso di esecuzioni di funzioni con tanta business logic dentro, possono essere svariate.Semplicemente il linguaggio si occupa, attraverso il ritorno che tu dichiari, di selezionare il pattern più aderente alle casistiche che tu hai dichiarato, e esegue il codice di conseguenza.In base ai casi che tu dichiari, dichiari anche le esecuzioni del codice che vanno gestite dopo e semplicemente lui dice la cosa che ci si avvicina di più è quella e quindi esegue.Una specie di super switch.A me piace proprio immaginarlo così.In realtà molto simile allo switch case, solo che mentre il case dello switch case è fisso, è imperativo e fisso, il case del case construct dei linguaggi funzionali, che è quello che fa pattern matching poi, è dichiarativo e quindi praticamente tu puoi dichiarare costanti e variabili dentro lo stesso case che poi andrai a utilizzare, come dice un mio carissimo ex collega che adesso scrive l'exir per lavoro, a sbrappare dentro il codice.Sì, è bellissimo.Tra l'altro vi suggerisco di buttarci un occhio perché è uno di quegli elementi che cambiano il modo di pensare.E' proprio uno di quegli elementi, io ne ho messi pochi, cioè ne ho pochi di questi elementi, però è proprio uno di quelli che ti cambia completamente.Un altro è per esempio le pipe o la function composition che a me ha cambiato completamente il modo di approcciare al codice.Però proprio il pattern matching è molto interessante per questo metto un link nelle note dell'episodio e andiamo ad approfondire perché in realtà lo sforzo che ho chiesto ad Alessio è stato titanico provare a spiegare solo con le parole questo concetto quando poi se guardate tre righe di codice di te ah era questo è semplicissimo proprio da vedere.Ti chiedo un'altra cosa riguardo Elixir.Elixir ha una tipizzazione dinamica quindi si distingue tra altri linguaggi funzionali come Haskell, come Scala che sono staticamente tipizzati.Quali sono i vantaggi che tu vedi nella tipizzazione dinamica di questo linguaggio e quali sono invece secondo te i limiti? Allora, limiti è difficile che me lo chiedi a me, nel senso che per quanto riguarda i limiti io sono un javascriptaro di professione e quindi in realtà io i limiti dei linguaggi debolmente divisati non è che li soffro, anzi li piego al mio volere, anche in passato anche in maniere improprie, poi ho imparato che da grandi poteri derivano grandi responsabilità.Il principale vantaggio è che somiglia molto di più il codice che scrivi a un classico linguaggio di scripting, quindi non ha la forza formale del...lo svantaggio principalmente è quello che non hai la qualità formale del linguaggio tipizzato che ti consente di andare a vedere qual è il tipo di ritorno di una funzione, di fare, che ne so, type-driven development, come puoi fare per esempio ad esempio con TypeScript.Chiaramente il vantaggio è che ogni funzione, quello che ti ritorna è buono perché non c'hai tipi, c'hai solo i costrutti del linguaggio che sono principalmente liste e mappe e semplicemente, oltre ai tipi primitivi che sono numeri, stringhe, bit string, atomi, ci sono anche svariati tipi primitivi all'interno di Elixir, che non sono solo quelli un po' monchi di JavaScript, ci sono anche delle sofisticazioni degne di nota, per esempio gli atomi.E quello che succede chiaramente è che, non avendo un codice formalmente provato, dall'altra parte puoi fregartene, faccia a botte finché non funziona, è molto di bocca buona la piattaforma quando poi ci vai a programmare sopra.Mi chiedo se esistono, immagino di sì, degli strumenti tipo analizzatori statici di codice e quanto vengano usati poi nell'utilizzo professionale.Allora, La mia risposta che farà arrabbiar tantissimi è "troppo".Nel senso che, secondo me, se devi scrivere un programma con un linguaggio fortemente divisato, usi Rust, usi TypeScript, usi Java, usi quello che ti pare.Non usi per esempio JavaScript con le Flow Annotation, non usi Elixir.Esistono dei tool del genere che sono Dialyzer per Erlang e praticamente un superset di Dialyzer che è Dialixir che consente di usare le annotation di Dialyzer per annotare le funzioni di Elixir.È una cosa che secondo me ha senso quando hai uno specifico modulo di cui devi essere sicuro del comportamento e che la gente non lo usi Admincam.Mi fa piacere che possiamo usare queste parole in trasmissione.Se vuoi essere sicuro che le persone non usino a muzzo il tuo modulo, tu lo denoti con le annotazioni di Dialixir, però secondo me c'è un caso d'uso che è molto, molto, molto, perché il vantaggio che ti dà è far finta che la tua codebase sia fortemente tipizzata, quando in realtà tante volte non è così, perché poi questi sistemi sono un po' come...una volta facevamo un esempio su RomaJS, in realtà, mi pare, il type system non è un carceriere, cioè non è una persona con cui tu devi combattere per uscire da una cella, è uno strumento di sviluppo che va utilizzato come uno strumento di sviluppo, non come una babysitter.In particolare, questi sistemi tipo Flow o tipo Dialyzer possono essere molto facilmente corrotti come carcerieri, semplicemente buttando dentro, che ne so, TypeScript che c'ha l'ENI, per esempio, se tu metti un "any" dentro una codebase di TypeScript, stai dicendo a...diciamo, da persone che scrivono TypeScript, ti dicono, stai dicendo al compilatore che tu sai che cosa stai facendo.In realtà, da persona, da...il sottoscritto che ha studiato Haskell, ti dice che se tu metti un "any" dentro una codebase TypeScript, stai avvelenando il pozzo.Cioè, non...in quel momento è molto facile che finisce al punto di non ritorno.Quindi personalmente io non vedo una una grossa utilità in questo tipo di sistemi, io vedo una grossissima utilità in realtà di un team di sviluppo responsabile che sa che cosa sta facendo nell'uso di questi sistemi.Ok, io intanto ti ringrazio perché hai reso meno fumoso questo mondo, il mondo di Elixir, degli stregoni magici, con pozioni, zampa di ragno, però in realtà è un mondo che affascina tanto e che a tono del 2015 aveva un hype alle stelle, un po' come può essere Rust oggi.Secondo te cosa ha fatto sgonfiare la PIL verso questo tipo di linguaggio, sempre se si è sgonfiato o se invece si è strutturato? Allora, purtroppo si è sgonfiato, per fortuna si è strutturato, nel senso che sgonfiando si ha trovato il suo posto, forse come tutte le tecnologie, perché quando vengono gonfiate troppo poi vengono usate per use case che non sono i loro.Come per esempio ci stanno tantissimi che stanno in fissa a scrivere le web app con Rust.Io personalmente penso che a livello di performance sia un gain estremo, nel senso che ci avremo un'applicazione velocissima e sicuramente memory safe.È un pain? Però sì, il pain è che sicuramente...personalmente io una codebase estesa con Rust ancora non l'ho vista e insomma è difficile anche un po' da leggere per carità, questo è una cosa sia di un programma che ha 5 righe di codice sia di un programma che ce n'ha un milione però comunque devi anche cambiare tecnologia secondo me, nei confronti del problema che stai affrontando.E l'XIR sicuramente ha trovato il suo posto, che è...in realtà, cioè, ci stanno tantissimi progetti, tantissime società di consulenza che lo usano soprattutto per fare diciamo, lavorazione di dati in batch, per esempio, perché ha delle librerie di concorrenza e di data pipeline molto carine, tra cui Genstage e Broadway e Flow.So di aziende che lo usano per fare praticamente il loro back-end, i loro servizi back-end.Sicuramente quello che l'ha fatto un po' sgonfiare, che l'ha fatto gonfiare prima e poi sgonfiare, è che all'inizio era stato, siccome è un Ruby con rossetto, è molto imbellettato rispetto a Ruby e ha un decimo del memory footprint, quindi all'inizio era considerato un'alternativa a Rails molto buona.Purtroppo, siccome si appoggia sulla VM di Erlang e magari, che ne so, gli errori non sono così verbosi per una persona che ha appena iniziato a programmare, chiaramente un po' si è smontato questo hype, complici anche altre tecnologie che sono arrivato a prende piede e che hanno un po' eroso un po' di quel mondo.Personalmente io non l'ho mai percepito, cioè io l'ho sempre percepito come una micchia perché io sono arrivato dopo.Io nel 2015 ho iniziato a studiarlo seriamente, però solo nel 2018 ho cominciato a scrivere codici a Elixir che facessero realmente qualcosa Personalmente io lo trovo un'ottima scelta quando devo fare un backhand, quando devo prototipare qualcosa, perché c'è un framework molto carino che si chiama Phoenix, che permette di scaffoldare.Io ho fatto un prototipo di una startup in quattro settimane.L'ho visto, quello del menù.Sì, esatto.Il classico prototipo della startup dei menù digitali al tempo del covid io l'ho fatto in quattro weekend con Phoenix Framework e poi dopo mi sono divertito con un po' di actor modeling perché Elixir è quello che ti consente di fare, ti consente di avere bounded context glamorosamente definito.Bellissimo, per esempio su Phoenix guardavo la funzionalità per quanto riguarda la presence senza appoggiarsi a database o a sistemi terzi, insomma c'è una serie di funzionalità.c'è però un passaggio che volevo condividere con te prima di salutarti che in realtà lo leggevo proprio stanotte mentre cercavo un po' di informazioni cercare di farti delle domande che fossero un minimo intelligenti e ho trovato una frase non so chi l'abbia detta ma che dice che insomma Elixir è fortemente ispirato a Ruby per quanto riguarda la parte sintattica ma in realtà profondamente diverso per quanto riguarda la parte semantica perché porta con sé tutto il mondo functional che in realtà è molto trascurato in Ruby o comunque non è diciamo il central pillar del linguaggio.Adesso partendo da questa frase ti faccio veramente l'ultima domanda è dalla tua esperienza con Elixir cosa ti sei portato dietro invece nel tuo sviluppo quotidiano day by day su JavaScript? Allora, è complicato.Innanzitutto il pattern matching, nel senso che comunque ci sono oltre FPTS c'è anche Ramda che è una libreria JavaScript funzionale.Mio amore! Bravo! All'inizio ero refrattario perché era un po' complicato leggere quando fai full ramda, diciamo, quando lo adotti in maniera massiccia, il codice che scrivi è parecchio complicato da leggere, quindi devi dosare la dosazione di ramda.Io però, quando scrivevo Google Ads, per un periodo, mi hanno messo vicino un collega, perché avevamo bisogno di una mano su alcune cose, e il collega è Gabriele, che saluto, e questa persona ha letteralmente proprio droppato dentro il progetto Randa e ha scritto tutta la validazione della creazione degli ads su Google Ads da noi con Randa e mi ha insegnato a usare Randa e io, cioè, là ci ho ritrovato tantissimi concetti dell'XIR compreso, tra virgolette, il pattern matching perché c'è il costrutto, ci sono i cond, i match dei Randa che comunque emulano avvicinano.Esatto, emulano quel tipo di logica, chiaramente la piattaforma non te la offre, perché non c'hai runtime che faccia pattern matching, però qualcosa riesci a fare.Quindi chiaramente la dichiaratività delle pipeline me la so sicuramente portata dietro, io mi sono riscritto per non portarmi dentro tutto ramda, mi sono riscritto la funzione pipe da solo per esercizio e me la so salvata come package javascript e tutt'oggi la riuso perché secondo me una programmazione di business logic pesante senza pipeline perdi qualcosa, sì, a un certo punto perdi il controllo.L'altra cosa interessante è stata l'approccio alla concorrenza, nel senso che Elixir come Erlang fa uso dei processi di Erlang e dell'actor model.Questi processi parlano tramite messaggi che vengono inoltrati agli attori tramite pattern matching, cioè praticamente all'interno della firma delle funzioni tu puoi fare pattern matching per ricevere determinati messaggi da attori esterni e la cosa interessante è che io, proprio me l'hai me l'hai fornita sul piatto d'argento, quindi faccio self advertising a manetta.Io ho scritto, in questo ottobre che sta finendo, di Octoberfest, ho scritto una libreria JavaScript che praticamente emula le primitive di concorrenza di Erlang all'interno di Node.js, usando dei worker threads per fare i processi.Figo! e puoi a quel punto ricevere dei messaggi, fare send e receive dei messaggi.E niente, quindi questa cosa si chiama Overlord.Overlord.Me lo segno perché tutto questo va a confluire sulle note dell'episodio.Grazie per tutte queste informazioni.Io guardavo l'orologio e in realtà siamo lunghissimi e tu stai per iniziare un altro meeting, quindi non ti rubo ulteriormente.Giusto qualche minuto perché nel nostro podcast abbiamo un momento che si chiama "Il Paese dei Balocchi", un po' ispirato a Pinocchio, e dove ti chiedo di farci un regalo.Ecco, tra che ne so, tools, piuttosto che librerie, libri, qualunque cosa ti senti di condividere con noi? Quali sono quello che...la cosa che ci consigli, il regalo che ci metti sul piatto."E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Allora c'è un articolo di Paul Graham di cui io ti darò poi il link.Sì? E io non mi ricordo come si chiama questo articolo, maledetto.Allora, Paul Graham è il tizio che ha fondato Y Combinator e l'ha fondato dopo una exit particolarmente...è un acceleratore di startup famosissimo, e l'ha fondato praticamente dopo la exit molto fortunata di una sua startup il cui stack tecnologico principale era scritto in NISP.e lui ha scritto un articolo clamoroso dove lui diceva sostanzialmente "a me me prendevano tutti in giro perché io usavo l'ISP, hanno smesso di prendermi in giro quando si sono accorti che per me l'ISP era un vantaggio competitivo perché io usando un linguaggio che semplicemente la maggior parte della gente non conosceva, scrivevo le feature nella metà del tempo delle start-up che erano basate su Java, per esempio".Nonostante fosse per esempio un linguaggio molto vecchio, tra virgolette, nel senso che poi da lisp sono nate varie moderne alternative, per esempio closure.Però lui scriveva in lisp e spigneva su lisp veramente da paura e lui ci ha fatto una fortuna con lisp.La cosa che lui dice all'interno di questo articolo è "non andate solo dietro alle modi, guardate bene che concetti ci avete intorno e sedimentateli e usateli quando serve, bene, e in questo modo ci avrete un vantaggio competitivo, che non è solo che il vostro stack è incomprensibile, ma è magari una facilità di onboarding, una facilità nell'integra del codice terzo, una facilità di qualsiasi tipo vi permetterà, lo dico col tono da manager, a fine sprint di avere il triplo della velocità.A me questo è uno degli articoli che mi ha cambiato la prospettiva del software development e mi ha permesso di approcciare gli step professionali che mi hanno portato da intermediate a senior dentro una corporation.Sì, croppa le fondamenti della guerra da tifoseria calcistica.A me non piace la tifoseria tra linguaggi, infatti.Alessio, io a nome mio e a nome di tutti gli ascoltatori e la community di Gitbar ti ringraziamo.sapi che githbar come bar, il bar degli sviluppatori, è un po' anche casa tua quindi mi ha fatto piacere condividere questa birretta virtuale durata un'ora e mezzo, ti avevo promesso un'ora ma sono super chiaccherone, quindi magari ti sei bruciato la tua pausetta prima del meeting, io non posso far altro che ringraziarti e rinvitarti quando hai qualcosa di interessante da condividere con noi se ti fa piacere insomma qua nel nostro bar degli sviluppatori Quindi grazie Alessio.Perfetto, grazie a te.Noi ci sentiamo la prossima settimana, qua sempre su Gitbar.Vi ricordo, info@gitbar.it, via email @brainrepo su Twitter e poi il nostro gruppo Telegram che trovate semplicemente cercando Gitbar.Insomma, da Roma con Alessio e Elione con me è tutto.Alla prossima settimana.Ciao! Ciao! [Musica]
