Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Oggi sono con me Carmine e Alessio, ciao ragazzi! Ciao! Alessio che tra l'altro flexa il suo nuovo portatile fighissimo Esattamente, è arrivato oggi e non potevo credere quando è uscito dalla scatola che ci avesse veramente i 64 giga di ram che mi aveva detto il venditore Fantastico, tra l'altro ti ricordo che dobbiamo organizzare, lo dico anche a Carmine, una puntata su come fare il setup di una workstation linux per lavorare quindi dobbiamo farlo assolutamente anche perché a me tra un po' arriva il computer nuovo quindi siccome sono uno nubo di serie A uso Apple Dabbo tempo immemore e ho bisogno di aiuto quindi perché non utilizzare Gitbar per fini del tutto personali? faremo impresa diretta allora, vi aiuteremo a configurare una distribuzione Linux sottofisso e poi manderemo lo stream, lo streamiamo, lo portiamo e via esatto però oggi non siamo da soli e tra l'altro non ci allontaniamo molto come discorso.Abbiamo un ospite ma prima di presentarvelo il mio ruolo è sempre quello di rompervi le scatole ricordandovi i nostri contatti.Info@gitbar.it via email @brainrepo su Twitter oppure...[cricchietto] - Oppure il gruppo Telegram - Ah, il gruppo Telegram! [risate] Io pensavo che ci fosse Princeado, sta di manforca - Se c'hai il coraggio la metti proprio così nelle visite [risate] - Il gruppo Telegram è che è la parte più bella di Ghiardo dopo il jingle e ci potete trovare su Telegram scrivendo @gitbar insomma e siamo tutti lì, siamo una fantastica community inclusiva dove si parla molto poco di retribuzione e salari, quindi vi invito a iscrivervi e vi aspettiamo e poi nel senso siamo comunque diversi da quelle community che hanno Italia nel nome noi siamo Gitbar con un flavor che è molto più internazionale esattamente e soprattutto io da bravo arpagone che ormai porta la nomina di questa cosa all'interno del gruppo degli ammutinati e Mauro incluso ormai che è ammutinato pure lui presso se stesso.Vi ricordo che abbiamo una scatola delle donazioni quindi mi raccomando quando passa il piattino dell'offerte mettetece la banconota dentro e non rubate dal piattino delle offerte perché se no il vostro messia preferito che sia insomma Gesù o diciamo che noi siamo messia agnostic, Vostro messia preferito piange Esatto, esatto L'interfaccia messia è comunque quella cosa che c'ha sia fustiga, piange e dona Tipo c'ha questi tre metodi qui Ora decidete voi come lo volete implementare Anche perché il prossimo obiettivo di Geetbar è quello di riuscire ad acquistare i microfoni per tutto il team Quindi diventate parte di questa missione visto che siamo in tema comunque bando alle ciance i contati li abbiamo ricordati allora possiamo iniziare benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Allora, iniziamo con un ospite di eccezione, Senior DevOps Engineer, mio collega, mio amico, signore dello storage del networking e del linux, David Costa.Ciao David! Ciao direttore, buongiorno a tutti! Senti, ma di che si parla oggi quindi? Oggi si parla di una cosa che se la dici dici "ah ma è quella cosa che forse conosco e in realtà no, perché parliamo di Nix.In questa puntata ci sono diciamo due Nix enthusiast di cui uno non sono io, io sono semplicemente un novizio.Però eccoci qui.Non so, ci vuoi parlare un po' di te e poi ci dici che cos'è Nix in parole veramente veramente proprio come se stessi parlando a tua tua zia, quella zia un po' che non capisce, un po' di...No, infatti lo so che adesso riesce a spiegarsi molto bene con sua zia, invece purtroppo non mi capisco.- Sì, però vero.Sì, parliamo di Nix, che è una tecnologia con un acronimo di tre lettere e praticamente è introvabile su Google.Quindi, insomma, inizierò dicendo che probabilmente parlo più di Nix, Nix Packages o Nix Language, poi vediamo la differenza.comunque niente non è da confondersi ovviamente con un unix con l'asterisco davanti è una roba ben precisa e probabilmente si trova molto meglio cercando un x package manager quindi così giusto per fare subito un po di confusione insomma ecco con i termini.Esatto io mi sono già perso.Ti sei già perso? Bravissimo infatti come tutti.Anche perché io in questo episodio recito l'ignorante della situazione quindi in realtà...No allora sì questo è un problema che hanno tutti quelli che si approcciano al mondo di Nix.Nix nasce come un package manager e il tentativo, tentativo insomma, è un'idea che nasce da una tesi di dottorato di questa persona, si chiama Erico, e praticamente lui dopo anni di dottorato ha detto "ok sai che c'è, il problema delle dipendenze lo voglio risolvere completamente", aggirando completamente il problema e quindi nasce questo package manager, Nix, mi pare che derivi dall'olandese "niente", perché i pacchetti che tu installi non condividono niente tra di loro se non strettamente quello che gli serve e quindi come fa a fare questa cosa? semplicemente cerca di isolare tutte le applicazioni che tu utilizzi in modo tale che queste vadano a pescare solamente le dipendenze che gli servono quindi togliendo tutte quelle cose che sono in comune del sistema operativo quindi se uno installa per esempio Chrome che dipende non so da una libreria di rendering e poi installa un altro programma che dipende dalla stessa libreria di rendering in realtà se le due applicazioni usano la stessa identica precisa definita versione della libreria allora lavorano in comune altrimenti saranno installate come due librerie separate questa diciamo è l'idea di base del package manager.Ma scusa ti faccio una domanda e scusate a Carmine perché qua a questo punto i punti interrogativi sopra la mia testa iniziano ad abbondare ma oggi allora i classici sistemi come linux non funzionano così? No, in realtà il punto principale diciamo delle varie distribuzioni è proprio questo infatti si chiamano distribuzioni perché scelgono un certo insieme di pacchetti che funzionano molto bene tra di loro e e le cui dipendenze sono condivise e sono una versione che va bene a più o meno tutte le applicazioni che sono installate all'interno del sistema.Ah ok, chiaro.Adesso...Sentivo del sarcasmo.Non credo che sia sarcasmo, è semplicemente che è un concetto nuovo, financo per me, Linux geomastico, però effettivamente Mix è una cosa che è sempre passata sopra la mia testa, io ho sempre abbassato la testa tipo tartaruga e non l'ho mai studiata, però in realtà ho visto parecchie volte Mix il package manager su cui poi è basato il sistema operativo, installato su altri sistemi operativi che non fossero NixOS.Tu sei al corrente di questa pratica, me la consiglieresti se fossi un piazzista di Nix? In generale io personalmente la utilizzo, quindi sì, tendenzialmente ho NixOS, che quindi è il sistema operativo basato su questo package manager, come sistema operativo principale dei miei computer non di lavoro e poi magari ne vediamo anche come mai e invece sui computer di lavoro o magari un'altra distribuzione, ora by the way non vorrei dire quale distribuzione preferisco, con sopra Nix che installa diciamo delle utility o delle applicazioni o delle librerie o quello che serve.Esatto, in particolare io mi sono trovato in questa situazione perché non so perché, probabilmente perché nella descrizione c'è scritto "Purely Functional", però io mi sono trovato sbattuto in faccia a Nix per l'ultima volta, tra virgolette, cioè nel senso quella più recente, quando sono entrato in contatto con svariate community di Haskellisti che, diciamo, consigliano Nix come modalità preferita per installare sul proprio computer per la Skel Stark, questo è il mio racconto in merito.In particolare, io ti faccio questa domanda che non so se è una stupidaggine, però se è una stupidaggine ti prego di dirmi, Alessio, questa è una grandissima stupidaggine.Io non mi offendo e i nostri ascoltatori meno che meno.che differenza c'è secondo te, insomma, veramente me puoi pure rispondere non lo so e non penso che succeda niente tra Nix, il package manager e Flatpak o Snap allora, si, diciamo, salta abbastanza all'occhio che ci sono delle somiglianze perché entrambi i sistemi, cioè entrambi, Snap, Flatpak e anche AppImage, per esempio, cercano di risolvere il problema delle dipendenze semplicemente ignorando le dipendenze che hai del sistema e portandosi il loro sistema di packaging.Differenze ce ne sono, va visto caso per caso, però per esempio Flatpak, partiamo da un formato che è molto più comune, sono i DMG, i mega filoni di Mac per installare le applicazioni, perché anche questi hanno la stessa idea, si portano dentro, fanno bundle di tutte le loro dipendenze e quindi il vantaggio è che uno scompatta quell'archivione ed è a posto.lo svantaggio è che i DMG tra di loro non condividono le dipendenze in comune.E la stessa cosa vale parzialmente per Flatpak, per esempio, perché le applicazioni impacchettizzate con Flatpak hanno di base un run time, quindi c'è una scelta abbastanza arbitraria su cosa è una libreria comune, che può essere comune a tante applicazioni, e cosa invece non lo è.Nix invece fa un calcolo automatico perché ogni dipendenza, cioè ogni cosa che viene gestita da Nix, che si chiama tecnicamente derivation, ha un hash crittografico per cui se due applicazioni usano lo stesso hash crittografico sei sicuro che possono essere condivise.Diciamo quindi la condivisione rispetto a Flutter che è automatica.e rispetto a Snap, la Snap è molto diversa perché cerca di risolvere anche problemi di security e quindi ha delle funzioni in più di confinement ed altre cose e soprattutto ha bisogno di un demone, quindi devi gestire tutto con il demone di Flatpak Nix ha un demone però volendo è opzionale, si può anche installare single user senza demone Ok, non solo mai risposto, ma mai anche impressionato.Però qui la domanda strana, ora la faccio quella lì strana, da amante delle vecchie guie per sua nostalgia di un tempo che non ha mai vissuto.Ma se io installo Nix su Mac, quindi ipotizziamo che io ho il mio bellissimo Mac come state persone.È scontato che si possa fare però...Io dopo scontato che si può fare perché mi ricordo che ci fu un periodo in cui ne parlavamo, quindi ipotizzando che si possa fare, che io installi Nix su Mac, ovviamente ho comunque accesso solamente a quei pacchetti che sono compatibili con Darwin, insomma, che sono pacchettizzati per quel tipo di sistema operativo.Quindi, diciamo, ha un registry per i pacchetti Nix oppure funziona in una maniera diversa? Questa cosa qui te la chiedo perché ogni tanto ti vedo che fai hit pull delle cose di Xpengages.Ha effettivamente un registry o ha una struttura diversa? Se lo dovessimo paragonare a...- NPM? - No, no, a Brew con le sue formule e con i suoi cask.Insomma, giusto così per rimanere in tema Mac.No, certo, certo, è una domanda legittima e questo va a fare una enorme parentesi su un altro progetto che ovviamente va di pari passo insomma con Nix.Nix di per sé non ha nessun pacchetto, nel senso che è un package manager e lo sviluppo del package manager va su binari quasi separati rispetto a quell'altro progetto che invece è Nix Packages, che è un mon repo gigantesco che contiene effettivamente le definizioni di tutti i pacchetti.Quindi normalmente, a meno che uno non voglia proprio farsi del male, tipicamente si installa Nix e ci associa a Nix Packages e a quel punto a tutte le definizioni di tutti i pacchetti che sono, diciamo, definiti dalla community.poi se uno vuole aggiungere le proprie derivation, quindi i propri pacchetti, a partire da altre sorgenti, è liberissimo di farlo.Ci sono delle funzioni proprio di...dentro le definizioni dei pacchetti puoi aggiungere dei sorgenti tuoi, insomma, da qualsiasi cosa.Anche Mercurial, se ti va da un file.- Ok, le proprie derivation intendi...cioè le derivation sono dei repository o delle cose che estendono un pacchetto esistente e tipo ce fanno cose, cioè che ne solo buildano in maniera diversa o qualcosa del genere? [DEMA] Allora, la derivation è una cosa che per iniziare è molto facile capire come un pacchetto.Quindi c'è la derivation di Firefox e c'è la derivation di TiddlyWiki, per dire.Però perché usare questo nome così generico per una cosa che tutti gli altri chiamano pacchetto? Perché in realtà Nix ha un sistema cosiddetto source binary, cioè le definizioni di queste derivation sono in realtà delle ricette per buildare le applicazioni.Quindi come buildano applicazioni possono buildare anche altre cose.per esempio una cosa che si può buildare, se ne parlava per l'appunto nel canale, nel gruppo Telegram, è che Nix può buildare per esempio delle immagini di Docker.Perché no? Basta che ci siano le istruzioni giuste per poterlo fare.Quindi è questo il concetto di derivation, che uno parte da qualcosa, che tipicamente è un sorgente di un'applicazione, parte anche da qualcos'altro che di solito è un compilatore e facendo fare un incidente alle due cose esce l'applicazione pronta per essere eseguita.E quindi le tue derivation possono essere qualsiasi cosa, possono essere un'applicazione oppure possono essere un wrapper di un'applicazione già esistente o qualsiasi altra cosa.- E la cosa che mi esce? C'è la nuova...beh io sto in fissa, [Riccardo]: In questo modo facciamo una puntata di 6 ore, ragazzi.[Alessandro]: No, no, no, aspetta, però giusto sì, per fare un riassuntino per le persone come me che sono poco Nix-compliant.Quindi che cosa significa? Diciamo che possiamo dire che una derivation di Nix possiamo paragonarla al package build o a un makefile, tipo.quindi diciamo ha una ricetta per buildare qualcosa con delle task, insomma.Quindi diciamo un insieme tra un ipotetico make file e la definizione di una formula di brew, insomma.Sì e no, essenzialmente sì, nel senso che normalmente dentro il codice, infatti non abbiamo detto che cos'è il codice delle derivation, non voglio dire che c'è del codice, non è come un package build che ha uno script, praticamente l'idea dietro a Nix ed è il motivo per cui è purely functional, è che le derivation si definiscono, e qui purtroppo le proprie estra parentesi un po' matematiche, sono definite proprio come delle funzioni che prendono i parametri, come il compilatore, il sorgente, e ci fanno cose.Quello che esce è una definizione della parte che non è pura, che è il builder.Quindi, diciamo, il codice per esempio di VLC avrà come parametro gcc ffmpeg, per esempio, la libreria grafica che è quella di VLC che non ricordo, mi sa che è gtk, non lo so, e niente, e dentro praticamente inizierà a dire, ok, con questa dipendenza ci faccio questa cosa qui.e tipicamente questa cosa qui è un pezzo di Bash che poi viene interpretato da Bash però potrebbe essere anche un altro applicativo per esempio, questo è un esempio proprio facile è che io per esempio gestisco il mio curriculum con Nix c'è proprio un file che spiega come partire dal LaTeX e fare il PDF è un comando facilissimo che è PDF LaTeX quindi praticamente nel Nix c'è scritto parti dal sorgente, chiamo PDF Latex e basta.E quindi questo è dichiarativo fino a che non si chiamano gli strumenti per davvero.Poi a quel punto l'ordine in cui fai le cose conta.- Però quelli sono strumenti monadici e fanno i side effects sull'hard disk? sì esatto e quindi infatti tutto quello che viene buildato con Nix può essere buildato dentro una sandbox che è una sandbox che non permette ai builder di per esempio aprire dei file che non erano stati dichiarati prima o aprire connessioni verso internet e questo serve per garantire che le build siano più più riproducibili possibile.Ragazzi scusate io da gnubo mi inietto così di petto allora io ho bisogno di riportare il discorso al mio livello quindi a livello di battiscopa.Ricapitolando abbiamo detto che Nyx è un package manager correggetemi se sbaglio ho anche un package manager il quale ci permette di avere delle build ricollegandomi alle prime cose che avete detto quando si parlava di os delle build predecibili usando un approccio funzionale ho capito bene? ok quindi io controllo quello che entra e per quello che entra io c'è per quella combinazione di elementi entranti che possono essere le dipendenze sputo fuori un'uscita che è sempre uguale.Si, esatto, l'idea è che se entrano le stesse cose teoricamente dovrebbe uscire le stesse cose.Cosa che...per diverse ragioni questa cosa non è sempre vera per esempio perché ogni tanto i compilatori mettono banalmente anche dei log in cui dicono l'ora in cui è stata abilitata un'applicazione e quindi non necessariamente si entrano le stesse cose, escono le stesse cose e quindi questa cura di chi scrive poi la derivation stare attento a queste cose qui per renderlo più riproducibile possibile se ce n'è la necessità e se no te ne puoi fregare però in realtà quello di cui abbiamo parlato non è un package manager adesso che sto ragionando si tratta più che altro di un task runner, no? questo comportamento specifico Cioè sono un po' confuso sulle cose che fanno in realtà.Eh no esatto, esatto.Allora diciamo l'altro concetto, diciamo i due concetti base di Nynx, uno era la derivation, che è questa cosa che abbiamo appena detto, e poi ce n'è un altro che è il concetto di profilo.E questo profilo utente per esempio, queste due cose rispondono a due domande diverse, molto zen secondo me.e la prima è "cos'è un pacchetto?" cioè la derivation risponde alla domanda "cosa diavolo è un pacchetto?" è fisicamente un pacchetto è fisicamente un pacchetto questo pacchetto azionario ma che cos'è un pacchetto azionario è fisicamente un pacchetto o no? si spacca spacca sfuga e quindi diciamo normalmente siamo abituati che un pacchetto è qualcosa che tu scompatti e ci metti il file nel posto giusto e sei a posto, e al massimo esegui un scrittino.Invece qui addirittura non esegui niente e poi vediamo come mai.Quindi diciamo l'idea di mix di un pacchetto è qualcosa che deriva da qualcos'altro e questo scarico a barile arriva fino ai fondamentali che il qualcos'altro è qualcosa che io ho già, qualcosa che posso scaricare da internet già pronto.>> C'è una domanda però, io ho capito come funziona sta roba perché chiaramente se il tuo oggetto di dominio, di ragionamento non è più il pacchetto che è fisicamente un pacchetto che tu lo spacchetti ma diventa la derivazione di una serie di operazioni, l'output è uno snapshot del disco fisso come quelli dei docker per esempio? ma allora diciamo che in parte è vero, cioè quando uno builda una derivation c'è una cartella che è la cartella di output e lì si finiscono tutte le cose della singola derivation, quindi quindi quando uno guarda come è fatta una derivation assomiglia molto a Stow, che è quella roba di GNU vecchia, quindi hai la cartella /nix/store, una roba illegibile, Mozilla Firefox 97000 e poi slash e dentro lì ci sono le varie cartelle, i usr, i hobeen, i lib, altre cose Ok, questo porta alla mia domanda finale, tra virgolette, di tutto questo ragionamento il file system di Nix è un file system normale? è fisicamente un file system? cioè c'è user local bin come tutti i file system? oppure è una cosa diversa? è una cosa diversa, infatti ora arriviamo all'altra cosa che era il profilo che risponde invece alla domanda cosa vuol dire avere qualcosa installato sul sistema? E la risposta è tipo, ho qualcosa installato sul sistema, se lo posso usare, che è una cosa abbastanza auto-evidente, però significa che se è una libreria, le altre applicazioni la riescono a utilizzare, se è un'applicazione deve stare nel path, per esempio, se è un'icona la devo poter vedere.Quindi, come funziona questa cosa delle derivation che si diceva prima con lo snapshot del sistema che mi padre comprò? Funziona così, che ogni pacchetto ha la sua cartella e tutte queste cartelle stanno in un unico guglione, in un unico store immutabile che è pieno di queste cartelle con nomi dieci a decimali seguiti dal nome dell'applicazione.Quindi le varie applicazioni sono compilate in questo ambiente, per cui tutti i loro riferimenti punteranno sempre all'interno dello stesso store.Quindi dentro il sistema operativo, ma anche usando un X stand alone, avrai come utente nel path una roba che dice che è proprio un sim link che dice punta a questa generazione del tuo profilo che praticamente è una specie di snapshot del tuo profilo e poi da lì ci sono tutti i vari collegamenti quindi è una specie di link farm in cui tu raccogli link a cose che puntano ad altre cose che puntano ad altre cose che finalmente puntano all'applicazione vera e questa dentro avrà tutti i riferimenti del next store quindi non andrà a leggere niente del tuo sistema operativo originale, a meno che non lo voglia proprio."Wow!" È calato il silenzio perché io volevo aspettare tre secondi prima di dirti "è il futuro" che è la frase quella tipica della fondata.Allora, però...È ottimo, di solito mi dicono, a questo punto di solito mi dicono "non ho capito niente".Allora, guarda...Presente, non ho capito niente.Nel senso, se io ti dovessi chiedere a che cosa può servire veramente Nix ad uno sviluppatore che non l'ha mai provato, in che cosa potrebbe semplificargli la vita? Ad esempio, stavo leggendo un po' di tempo fa, tra l'altro magari poi lo lasciamo anche nelle note di descrizione dell'episodio, che Shopify, che lavorano naturalmente con con Rails e con Ruby, che ricordiamo essere la migliore tecnologia, il miglior linguaggio di programmazione esistente.Che è notorialmente Bundler, non è il package manager più ordinato del mondo.eppure...quindi comunque c'è un'azienda che è comunque grande che utilizza Nix per quanto riguarda la parte di development environment.Quindi prendiamo uno sviluppatore che ha un setup più o meno normale, magari ha diversi version manager per i vari linguaggi o i vari tool che usa.In che cosa potrebbe trovare realmente beneficio in un mix per strutturare proprio development e environment e magari non avere quel disallinamento mistico tra te ed un tuo collega che usate proprio la stessa versione di, non so, JS, proprio la stessa versione di quella libreria, ma ti ha tirato dentro il binario strano e quindi c'è quel comportamento, insomma, diverso.Secondo te, utilizzare un mix può effettivamente aiutare ad uniformare questa cosa e a avere un development environment che sia quanto più possibile semplice e immediato da utilizzare.Questo qui è tutto praticamente un invito a parlare di Shell.nix, insomma, che sono me e una delle parti più interessanti.Sì, sì, sì, sì, sì, si capiva insomma.No, vabbè, diciamo che secondo me ci sono da dividere un attimo due casi d'uso, anzi tre.Il non sviluppatore che usa NixOS 99% è uno sviluppatore, quindi diciamo che è un caso che per il momento non si pone.Però insomma si stanno facendo dei passi in avanti.ora su questa cosa speriamo che si riesca a trovare qualcosa di un po' più user friendly per cominciare.Invece gli altri due casi sono un X per il deployment e un X per lo sviluppo.Allora, per il deployment la situazione è molto facile perché una volta che tu hai finito, la tua applicazione è pronta, hai tutto pinnato, quindi è tutto riproducibile, a quel punto è sempre tutto uguale ed è esattamente quello che vuoi per il deployment.Per lo sviluppo la situazione è un po' più complicata perché chiaramente tu aggiungi dipendenze, togli dipendenze, cambi dipendenze tutto il tempo.Quindi se il tuo team usa Nix, a quel punto diciamo ci sono dei comandi tipicamente che trasformano il file delle dipendenze normale di quel linguaggio come può essere un requirement o un file go mod, insomma dipende, un cargo, cargo lock, quello che è, composer, in un file nix e quindi a quel punto uno può scrivere questo file che si chiama shell.nix, insomma lì si può dare anche altri nomi, se uno non e a quel punto c'è l'effetto wow perché scrivendo nix shell e basta viene valutato questo file e l'utente viene buttato in una shell che ha esattamente le dipendenze che servono per poter compilare il progetto e questo vale anche per le derivation che già esistono quindi se io domani voglio fare una patch a non so a Visual Studio Code perché non è completamente free però per esempio a Codium allora entro nella derivation di Codium, scrivo un xshell e a quel punto ce l'ho ho già tutti gli strumenti che mi servono per compilare Codium.Ti faccio una domanda allora da Gnuvo, che differenza c'è tra utilizzare questo approccio e invece utilizzare docker in dev che ci è stata venduta in tutti in tutti i modi, il fatto di usare container così il dev setup è un attimo è bello pronto.Questa è una grandissima bugia per tantissime ragioni.Esatto, e allora diciamo le due cose possono coesistere e infatti molte aziende, ora non ricordo non ricordo non ricordo Shopify però diciamo ci sono alcune aziende che usano Nix per buildare le immagini Docker del loro developer environment, quindi diciamo è possibile anche usare approcci ibridi.Diciamo il problema principale di avere veramente environment con con docker è che alcune immagini docker non necessariamente sono riproducibili perché in docker i tag sono completamente non immutabili quindi quello che scarichi oggi non è quello che scarichi domani.Prima cosa.Seconda cosa i risultati delle build intermedie e i risultati delle build locali sono difficili da condividere, per cui diciamo devi avere qualcuno che fa push e poi dall'altra parte fa pull e insomma è un po' meno automatico rispetto a usare Nix con una cache per esempio e in quel caso diciamo si fa un setup, una tantum in cui si dice io mi fido di questa cache e a quel punto niente, scarichi da lì come si scaricherebbe da un Docker Hub, per esempio.Quindi diciamo alla fine puoi ritrovarti in una specie di, ora qui si ritorno in modalità "newb" insomma, giusto per dare un po' di contesto, in una sorta di virtualenv che puoi avere con Python insomma, dove hai sostanzialmente il tutto autocontenuto e hai una shell che ha a quelle di dipendenze lì, no? Ok.Però diciamo, una cosa che mi viene in mente è che non hai solamente le dipendenze di quel singolo progetto, però magari puoi avere anche, diciamo, degli strumenti che sono collaterali a quel progetto, che magari può essere il Tiddle Wiki che si carica con quello wiki già caricato, oppure ghi tk, oppure magari hai effettivamente il setup completo con magari anche delle cose che sono delle GUI, che è spesso una cosa cui magari non si pensa, ma in alcuni contesti possono comunque far comodo.No, certo, certo, ma infatti diciamo il vantaggio principale allora se uno mantiene uno shell.nix separato a quel punto niente, se l'ha separato o se non può tenere anche il codice della derivation e poi ottenere una shell automaticamente perché la shell si ferma ai prerequisiti della derivation quindi semplicemente io ho questo progetto che ha 12 librerie come dipendenza e poi ho bisogno, non so, di...o per qualche ragione ho bisogno di un computer per creare quella versione lì, semplicemente io prendo il code che già userei per il deploy, lo faccio diventare una shell e a quel punto le versioni sono giuste.Se invece si mantiene lo shell.nix separato, si possono fare altre cose un po' più strane, per esempio se uno lavora su un progetto che fa estensivo uso della rete e vuole importarsi Wireshark, per esempio, lo può fare.Quindi io facendo un XShell mi ritrovo che solo in quella shell, ricordo, quindi se apro un'altra tab non ce l'ho più, solo in quella shell ho la disponibilità di Wireshark.Oppure gli altri tool.A me è stato scritto nella chat che noi a Modinati utilizziamo per coordinarci che dobbiamo uscire dal pantano Perché chiaramente stiamo andando proprio nell'iperuraneo e secondo me ci siamo persi tre quarti degli ascoltatori che hanno fatto anche unsubscribe di rabbia al podcast.E se sono anche venuti a riprende, credo con dei forconi, mi stanno suonando alla porta i soldi delle donazioni.Mi raccomando, donate a proposito, soprattutto se vi sta piacendo quello che sentite, a parte scherzi, quello che appunto era stato donato negli episodi passati, ma soprattutto la cosa che non è stata considerata da Carmine che mi ha scritto questa cosa è che io in realtà voglio restare nel pantano e che io rimarrei ad ascoltarti veramente per sempre.Ti volevo chiedere una cosa si fa un gran parlare di mutable file system, tu che cosa puoi dirci a proposito di questo più di quello che già ci hai detto insomma? Immutable file system proprio? Si non lo so è una cosa che avevo letto online poi non lo so probabilmente sentite che google nel frattempo perché l'ho letta in giro non lo so era una cosa immutable infrastructure - Allora, parlando solo di Nix, posso dirti che le applicazioni girano tutte in un ambiente che è ridondi.Una cosa bruttissima che però so che uno affezionato lo fa per la mia sicurezza, le applicazioni non si auto-aggiornano, perché chiaramente non lo possono fare, non ne hanno i permessi perché questo chiaramente violerebbe qualsiasi cosa che ti aspetti da un sistema Nix.L'altra cosa è che può essere usato per buildare delle immagini che tu puoi usare con quelle cose tipo infrastruttura immutabile, quindi dal codice Nix della mia applicazione posso fare abbastanza facilmente un'immagine di Amazon per AWS.- Oppure vuoi buildare un container in generale? - Oppure posso buildare un container, sì.Allora questo è un po' strano perché all'inizio è un po' strano perché quello che ti esce è sempre dentro un XStore, quindi diciamo devi fare docker load poi della tua immagine che è un po' diverso di ciò che tu sei abituato a fare, docker pull, ma fondamentalmente è la stessa cosa solo che da locale invece che da token hub.Io voglio fare l'avvocato del diavolo.A me sto Nix mi pare troppo bello.Quali sono gli aspetti negativi e volendo ritornare anche a quella cosa che hai detto prima che secondo me è interessante.Che diciamo sui computer personali sì e sul computer di lavoro no.Quali sono magari magari quei problemi che non sono insormontabili, ma che comunque magari possono alzare l'asticella di un minimo utilizzando Nix tutti i giorni, magari diciamo con un classico progetto JavaScript oppure Go, oppure qualunque cosa che sia.Insomma, secondo te qual è lo stato di maturità della cosa e come facciamo a far venire incontro il mondo Nix, che comunque ultimamente sta prendendo tantissima attrazione e gli ecosistemi classici con cui sviluppiamo.Penso che come tutte le cose i vari mondi si influenzino un po' a vicenda, quindi alcuni package manager stanno prendendo un po' spunto da queste soluzioni Linux che tra parentesi se ne parlo ora ma c'ha 15 anni penso, o zutti lì, quindi insomma un progetto molto maturo da questo punto di vista.E dall'altra parte l'ecosistema di Nix cerca di venire in contro alle esigenze, quelle un po' più quotidiane, no? Solo che spesso non lo può fare, proprio per le assunzioni dei vari package manager.Per cui, diciamo, se ti va bene, non so, hai tipo un progetto Rust, allora a quel punto Cargo fa tutto da solo e quindi è facilissimo pacchettizzare una roba Rastro e tu gli dici qualcosa tipo Cargo.tunix e ti esce il .unix, sei a posto.Mentre invece nel caso di altri linguaggi che sono tipicamente interpretati, tipo Python, se hai la libreria che dipende da centomila cose native e non te lo dice e non è già pacchettizzata si soffre un po' per farlo.Quindi diciamo "your mileage" come si dice in hondo, il tuo chilometraggio può cambiare.Se ti va bene, ti va molto bene, se ti va male potrebbe andarti molto molto male.questo sì.Poi c'è l'altra cosa che è questo linguaggio super specifico con cui si scrive on the derivation che insomma diciamo di primo di primo occhito è terribile.Quindi io stavo provando a immaginare una roba del genere con l'utilizzo in un contesto javascript con npm sarebbe impossibile? Diciamo che visto che javascript è molto utilizzato anche python ovviamente molto utilizzato, per la maggior parte delle librerie, per la maggior parte dei casi, gli strumenti si rendono conto che ci sono delle situazioni e le correggono.Quindi una cosa che per esempio NPM supporta, che sono le dipendenze opzionali sostituite a tempo di installazione, questa cosa qui Nix non lo può supportare e quindi semplicemente semplicemente sceglie lui quale è la dipendenza che serve e quindi avrai sempre quella una volta inserito il .nix.Però ci sono questi tool tipo npm tunex e quindi ti esce sempre questo file .nix, che è un po' diverso rispetto ad avere il docelfile perché chiaramente se hai una seconda versione un altro progetto che c'ha le stesse librerie non serve di scaricarle o ricompilarle perché ce l'hanno già nello store.Chiaro, almeno questo pezzo.Io sto cercando di prendere qualche punto di riferimento, un po' come quando si esplorano le codebase nuove, che ci si cerca di attaccare a qualunque cosa possa essere un punto di riferimento da riconoscere in altri posti però il problema guarda il problema di questa di questo approccio qua è che secondo me l'unico punto di riferimento che io ci sto trovando perché nel frattempo david spiega le cose io le assorbo e nel frattempo per velocizzare leggo anche il manuale problema è che l'unico punto di riferimento che io trovo in tutto questo ecosistema è portage e gnto, perché ci sono gli overlay, perché ci sono i pacchetti overrideati, perché in realtà vengono gestiti disorgenti.Sì sì esatto esatto sì diciamo è l'esperienza più simile da questo punto di vista l'unica cosa è un po più veloce perché di solito la roba è già compilata.Certo, quindi abbiamo detto package manager, build tool e poi ti ho sentito accennare anche a un linguaggio un dsl giusto? Esattamente praticamente per, ripeto Nix ha diversi anni alle spalle e per definire le derivation si usa questa cosa che si chiama Nix language con buona pace di tutti i metodi di ricerca per cui uno cerca Nix e trova tutto e non trova niente e quindi questo è un linguaggio funzionale però è orientato al packaging che sembra un po' strano però effettivamente è così.che GD&Development.Si davvero, e quindi diciamo volendolo puoi fare genere da qualcosa, però chiaramente è molto limitato insomma, quindi ed è soprattutto tutto dinamico e sensativo e quindi paradossalmente no perché adesso diciamo ho incontrato degli aschilisti e loro volevano usare Nix ebbene hanno deciso che i tipi in questo caso forse non servivano, adesso mi ammazza qualcuno.completamente.No, niente, è molto specifico per cui per esempio uno fa la repl classica, uno apre un xrepl e fa 2+2 gli esce 4, 2-2 gli esce 0 e poi fa 2/2 e gli esce un pat con un esodecimale dentro perché lui il diviso lo interpreta come un pat con dentro gli slash e quindi in realtà per fare la divisione devi scrivere il post "builtin.div" e fare la divisione vera il fatto sta che per repachettizzare firefox non è mai capitato di dover fare le divisioni questo è la motivazione chiaro ti faccio una domanda siccome ci sono una serie di elementi che mi hanno attratto se volessi convincermi a utilizzarlo mettendo da parte tutta la parte di attrazione verso il tool interessante tutta la parte di funzionale che a me da wannabe functional developer mi attrae sempre ma dovendo riassumere quindi i vantaggi nell'utilizzo sia delle nostre build delle applicazioni che dei dev environment quali sono dovendoli elencare in un elenco puntato ok quindi dici i vantaggi nel dividiamo? cioè perché dovrei usarlo? perché figo va bene tanto perché se il team di sviluppatori è grande il problema delle differenze di versione sui sistemi è non banale, quindi diciamo questo ti può aiutare.Secondo me uno dei punti forti è riciclare proprio le espressioni, per cui le puoi condividere e a quel punto puoi pacchettizzare l'applicazione, puoi avere la console, diciamo la Shell da sviluppatore, puoi avere l'immagine docker, l'immagine di AWS e addirittura puoi anche avere una virtual machine di QEMU che fa dei test sulla tua applicazione e questa è una cosa tipo molto molto divertente perché a quel punto puoi usarlo per la CI e a quel punto anche la CI avrà le stesse dipendenze.Quindi diciamo se ci sono dei problemi di dipendenze e di release, diciamo questo tool ti può aiutare a mettere via questo tipo di problemi se non ce li hai chiaramente a quel punto forse potrebbe non valere ancora la pena di usato oltre a Shopify ci sono altri casi importanti di utilizzo? che ricordi? Allora, aziende che diciamo secondo me è uno di quei tool, adesso potrei dire una cosa molto improporale, però secondo me è uno di quei tool che qualcuno che lo usa lo porta in azienda e poi se ne va e quindi la gente si ritrova a mantenere queste espressioni in X.Quindi molto spesso ci sono queste aziende che se si cerca su internet usano X e poi dicono no, non lo usiamo più.Quindi eleggerò soltanto le aziende che lo usano stabilmente.Shopify, appunto abbiamo detto che lo usa stabilmente, Chatroulette lo usa per l'ambiente di sviluppo e poi diversi progetti open lo usano invece come sistema di build, tipo lo stesso build H, che è del progetto containers, lo usa per fare la versione statica, perché evidentemente è più facile, E tra le aziende di riferimento invece c'è questa azienda che si chiama Twig, che magari, non so quanto è conosciuta, però dà una mano a Cardano.quindi diciamo Cardano indirettamente, direttamente o indirettamente insomma ultreme a Duskel infatti dicevamo che è una bella accoppiata - A lei si dicevi qualcosa su Cardano? - No io Cardano, cioè nel senso Twig non la conoscevo però Cardano sì, assolutamente.Eh sì, diciamo Twig era un'azienda di...cioè era, è tuttora insomma, un'azienda di consulenza specializzata in cose functional e a un certo punto Echo, che è il creatore di Nix, è andato a lavorare per Twig, insomma, e tuttora lavora lì.Quindi diciamo, azienda flagship della consulenza Nix.E se vuoi, se si adela...Tra l'altro...No, scusa, diciamo solo che tra l'altro quello che succede è che questo Nix Language che è tutto strampalato, più di qualcuno ha detto "forse dovremmo anche farne un altro" e quindi loro stanno sviluppando un altro linguaggio.Ah, molto bello.Per la parte delle configurazioni e che ha i tipi, se non sbaglio.Due parole su Cardano per chi non la conosce, se è una blockchain, se siete allergici alle buzzwords, il prossimo minuto schippatelo, ma è una blockchain basata su Proof of Stake, una crypto, in particolare io l'ho identificata perché loro usano parecchio Haskell e nonostante tutti i miti su Haskell in realtà hanno deliberato la loro blockchain in produzione, tra virgolette, per quanto possa andare in produzione una blockchain super velocemente, senza far troppe pugnette in realtà.Askel è uno dei loro linguaggi principali e hanno un background functional solidissimo.comunque niente, diverse aziende hanno provato anche Tumblr, a un certo punto lo usava per la OSCI o il progetto QMK, questo magari lo conoscono più persone perché è il firmware che si mette sulle tastiere meccaniche, se uno vuole buildarsi il firmware QMK sta nell'equazione Ti faccio una domanda David, la mia domanda è se uno volesse iniziare quali sono le risorse per capirne un po' di più e esiste un qualcosa in stile "Hello World" per poter iniziare a intanto a capire dove si è e prendere un po' confidenza? Negli ultimi anni c'è stato uno sforzo abbastanza intenso di restyling e ristrutturazione del sito proprio di Nixos, che è nixos.org, credo.Praticamente già su un page si trovano delle le animazioni che mostrano dei vari esempi di utilizzo di Nix così intanto uno si fa un'idea di quello che può fare.Dopodiché mancano dei tutorial intermedi, però la community di solito è abbastanza welcoming da questo punto di vista.Quindi se uno non trova nel manuale il modo giusto di imparare le espressioni, può iniziare a guardare le espressioni altrui che spesso vengono condivise, insomma, su GitHub.Questa cosa è un po' brutta, ma si sta lavorando sul materiale a livello intermedio.Ci sono diversi blog che ne parlano e spesso salta fuori questo Nick Spils, che se non erro è anche scritto in italiano.però NixBuilds non lo consiglio per iniziare perché lo consiglio per iniziare se vi interessa il dettaglio di come funziona sotto Nix ma se vi interessa pachettizzare qualcosa è molto più facile prendere il progetto di NixPackages, vedere un programma che ti piace e vedere come è scritta quell'espressione lì quello sì Carmine so che avevi una domanda, è possibile? Certo, certo, avevo giusto un problema con il microfono perché Pals Audio ha detto sì.Allora, praticamente che cosa ti porti di Nix fuori da Nix? Alla fine abbiamo comunque parlato di tutte queste cose belle, di queste best practice.Che cosa ti porti dell'esperienza di Nix nella tua esperienza di DevOps e di C-Savving anche fuori dal contesto Nix? Che cosa hai imparato? Questa è una bellissima domanda e incredibilmente ho già una risposta.La cosa più importante secondo me non me l'ha data Nix in sé, ma me l'ha data NixOS perché in NixOS le applicazioni, i servizi, sono pacchettizzati in un modo un po' particolare per cui tengono separato, e per separato intendo completamente separato, lo stato Quindi quando vado a gestire un server di qualsiasi tipo, un database o qualcosa, inizio a farmi delle domande un po' diverse, tipo dove sta il server e la sua configurazione? L'altro è dove stanno i dati? E soprattutto cosa capita ai miei dati quando io inizio ad aggiornare, a muovere, a riavviare e cose di questo genere? e niente, questa è una cosa che mi ha impresso perché ovviamente lo Stato non lo gestisce e quindi per fare certe cose, il concetto di aggiornamento di un programma non esiste esiste quello di ho il vecchio sistema, ops, ora ho il nuovo sistema e quindi la fase di transizione viene gestita in qualche modo cioè lanciando delle cose che poi provvedono a fare gli aggiornamenti ai dati.E quindi, ora, diciamo, questa cosa di tenere i dati separati, molto ben separati da tutto il resto, sì, me l'ha data NixOS, insomma.E mi aiuta molto, perché so già cosa beccappare.*musica* Devo interrompere la chiacchierata perché è doveroso ringraziare Sam Salvatico che questa settimana ci ha invitato una birra.Grazie.*sussurro* Sam, l'hai fatto mandandoci un messaggio che vi leggo, dice "Portate la sete di sapere a un livello successivo".proprio per questa sette che ci dona appunto una birra.Grazie Sam, ci tengo a ricordare una cosa da questo momento in poi tutte le donazioni andranno a costituire un fondo per l'acquisto dei nuovi microfoni di Geekbar quindi come diceva lei sia inizio puntata se vi fa piacere e volete sostenere il nostro podcast, il vostro podcast, il nostro bar, allora potete farlo entrando nel sito e cliccando su "portaci".Questo ci permetterà di avere dei microfoni nuovi per tutti, ci permetterà quindi di avere un audio migliore e un podcast migliore.Ti faccio una domanda che mi viene un po' triggerata da quella di Carmine, ma come sei arrivato a scoprire questo mondo? La domanda è in aspetto su quelle cose che capitano per sbaglio.Allora, la prima volta in assoluto che ne ho sentito parlare era sei anni fa, credo, sette, ed è il mio ex capo che a un certo punto posta su Slack questo link e dice "oh ma questa distro la conosciamo?" Sì, e quindi io apro questo post e dico "ah, Purely Functional, questa roba qua", e dico "Come è possibile che mi esfugi da questa cosa? A me piace la programmazione funzionale, perché non ho mai sentito parlare di questa distro".E niente, poi ho iniziato a interagire con la community che all'epoca stava su IRC.E basta, poi subito mi sono affiondato a una delle prime conf su Nix a Monaco.E niente, lì ho visto che la gente era tutta entusiasta, tutta presa e da quel punto là è tutta stata in discesa.capito quindi ci sei arrivato fondamentalmente esplorando l'edistro aiuto io oggi ho provato a buttare dentro una serie di informazioni che sicuramente non riuscirò a metabolizzare però è normale però non serve fare il passo per l'occhio tra capo e questo software può anche iniziare installando Cilixx e basta senza fare nient'altro e intanto puoi giochicchiarci un po' con i comandi di esempio che si trovano come tutto si parte un passo alla volta non serve iniziare a deployare un database distribuito con XOS da domani questo secondo me è una cosa che ti permette di esplorare gradualmente e invece se volessi approfondire cosa dovrei andarmi a cercare? per questa cosa che dicevo prima in realtà lo stesso repository di Nix Packages ha tutte le derivation quelle più facili e poi c'è anche delle derivation più complicate ma soprattutto il codice è strutturato in una maniera particolare Diciamo che per scelta, ora vediamo se la community deciderà di fare diversamente, il posto migliore dove approfondire sono i tre manuali.Il manuale di Nix in sé, il manuale di NixOS e il manuale di Nix packages, che ha dentro le linee guida su come si pachettizzano le cose.E quindi c'è anche una sezione per ogni linguaggio, insomma dice "per JavaScript fai così, per PHP fai così" e da lì si capisce insomma come pacchettizzare le cose.E poi se uno vuole andare a vedere proprio le cose più advanced c'è Nixpills che nominavo prima con le cose di basso livello e se no basta aprire la chat di NixOS su Metrix e basta vedere i primi cinque minuti che capita qualcuno che deve pacchettizzare qualcosa di allucinante.Ok, noi abbiamo già praticamente spoilerato la sezione successiva del nostro podcast che è il Paese dei Balocchi, quel momento in cui condividiamo delle robe che siano libri, video, audio, qualunque cosa ci abbia catturato l'attenzione e portato a gasarci talmente tanto da volerla condividere per cui io ti chiedo David hai qualcosa che sia un libro un talk da condividere qua? "E conduco nel paese dei balocchi" "Ah il paese dei balocchi" Allora sì c'è un libro che è molto filosofico a quanto pare lo devo ancora leggere ce l'ho lì che mi attende e che parla del "The Promise Theory" di Mark Bursa.La teoria della promessa che in pratica analizza i sistemi software come un insieme di agenti che si fanno delle promesse tra di loro praticamente questo è quello che ho capito dalla quarta di copertina e niente mi sembra molto interessante sicuramente vi farò sapere.Attendiamo feedback nel gruppo telegram.Carmine e Alessio avete qualcosa per noi? Addirittura mi dai la precedenza Io non so perché, volevo aspettare il tuo balocco, perché è quello che hai detto in chat.Sì, sì.Allora, diciamo, io ne ho due, di cui uno di quello che ti ho detto.Ok, io ti volevo rubare il secondo, esatto.Allora, in realtà, il primo è quello che ho detto in chat, ok? che è "L'elogio del lozio" di Russell, che non è un libro tecnico, questa cosa qui diciamo si va un po' a rialacciare anche al consiglio letterario che ho dato nella puntata diciamo sulla biblioteca di Bibar.Non è un libro, diciamo, non è un libro un libro tecnico credo che sia un libro che deve essere letto.Si chiama quindi "L'elogio dell'ozio", non parla solo dell'ozio, anzi diciamo che ne parla nella parte iniziale, però alla fine è un excursus sulla nostra vita, sul nostro essere umani, sulla religione, sull'ozio, sulla politica ed è secondo me un libro che in questo periodo storico di grandissimi cambiamenti può farci veramente capire dove siamo e dove stiamo andando.L'altro libro invece è un libro tecnico che ho sul Kindle ormai da mesi e ne ho letto pochissimo, però so che David ne ha una copia fisica ed è "Categorie e teorie for programmers", che non è for programmers nemmeno per sbaglio, secondo me perché già parte da una conoscenza la matematica che non ho appieno per poterlo comprendere, ma con una lettura ad altre fonti mano a mano, secondo me può essere un bel libro anche per approfondire tutto il mondo della programmazione funzionale, al di là del filter, map, reduce, insomma tutto ciò che già ritroviamo nelle librerie standard dei nostri linguaggi di programmazione preferiti e quindi Ruby.Aggiungo una cosa che tra parentesi è for programmers perché c'è dentro del codice che però nella versione originale è ASCEL ed è C++ con i template, fortissimamente template e ce n'è una nuova versione invece che è anche in scala.dicono che sia più legibile, magari vale la pena guardarla, sta online.Io l'ho comprato e nel kindle non ho ancora avuto il coraggio di aprirlo, per cui il mio balocco è semplicemente il...visto che siamo in argomento scusale se ti sono passato davanti...tranquillo, sto cercando il mio balotto.È semplicemente il libro che ha scritto il buon Canty sulla programmazione funzionale con typescript, una roba ben più accessibile dal dal mio punto di vista quindi lo metto nelle note dell'episodio.Allora, no in realtà non ho capito...nel frattempo Carmine mi sta scrivendo "mio Dio scusa in realtà non mai rubato nessun balocco" perché in realtà io volevo ricordare, cioè ricordare per chi sta nel gruppo Telegram a cui iscrivetevi, mi raccomando, ai nostri ascoltatori che non mi ricordo quale giorno ci sarà un talk del Kubernetes Cloud Native Tuscany User Group dove credo sempre David parlerà di building OCI images without docker e anche lì in mezzo credo che Nix farà parte del mix.Sì sicuramente però diciamo una delle difficoltà di questo episodio secondo me è quella di parlare di Nix che chiaramente magari con un approccio un po' più hands on risulta un po' più commestibile quindi sì sarà sarà sarà un po' più hands-on questa cosa.Diciamo potete poter venire per vedere Nix se non ci capite niente c'è la birra comunque, quindi posto.E soprattutto dato che ormai siamo nella vibe Linux hardcore io volevo consigliare una serie di post di Daniel Robbins di cui non trovo più tracce in rete che è gravissimo perché è una una delle mie letture preferite, che è costruire una distribuzione in inglese "Making the Distro" e Daniel Robbins, il creatore di Gentoo Linux, scrisse questa serie di tre post su IBM Developer Works, per Carmine che è un grande fan delle cose un po' datate, e di IBM, in cui spiegava come era nata Gentoo e quali erano state le difficoltà che avevano superato all'inizio il team di sviluppo e come era nata anche e soprattutto l'idea di Portage, che è una delle ispirazioni principali, in realtà, mi sembra di capire, per Nix Package Manager.E quindi niente, siccome è una cosa che a me mi ha dato tanto, professionalmente e anche filosoficamente parlando, quando si parla dei sistemi operativi, della Regalos e la riesco a ritrovare, se no ve la declamo perché la so a memoria in un prossimo puntato di Geek Park.Ma questo balocco è giusto sempre per rendere accessibile il contenuto di questo episodio, è nubito da me.No però è comunque piacevole ascoltare di cose che portano la sticella un po' oltre il conosciuto perché nel guardare l'oltre abbiamo una serie di stimoli che invece possiamo utilizzare quotidianamente nel lavoro di tutti i giorni quindi capire per esempio quello che ha detto davide su applicazione dati come gestirli è da un argomento così complesso è una cosa che io anche io da gnubo mi porto casa.Nelle puntate precedenti.Eh, vuoi prenderti una libreria, una libreria molto specifica che fa una cosa sola, non vuoi scrivertela, ok, ma piuttosto che importartela da npm, va a vedere il codice su github e prendi il codice su github e mettitelo nel tuo codice, cioè perché è quello che secondo me i sviluppatori, secondo me, sottopalano, è questo.Allora Da un certo punto di vista tu hai ragione, noi dovremmo concentrarci sulla logica di dominio, giusto per essere prodotti di subito, fatturare eccetera eccetera.Però il punto è, anche il codice scritto da qualcun altro è nostra responsabilità, anche se non vogliamo ammetterlo.Cioè, tutto quello che io mando in produzione è responsabilità del team di sviluppo che l'ha messa.Quindi se io ho F.P.A.D.e la F.P.A.D.ha un bug critico, è comunque colpa mia.quindi il punto è fare attenzione cioè l'heft pad invece che installarla la guardi e dici "ah ok, sarà" intrighe a parte che non so neanche come si fa un left pad a mano, però io lo guardo penso di riuscire a capirlo o anche se non lo capisco ne porto, ne progetto il collice e i testi per esempio [Musica] Bene, credo che siamo giunti al termine.Una puntata abbastanza hardcore, lo ripeto, ma noi siamo forti quindi queste puntate ogni tanto ci piacciono.ringraziamo david perché ci ha portato in dono una cosa che per noi altrimenti sarebbe stata inarrivabile e ha fatto un po' di luce in un argomento un po' desueto, non c'è molto materiale infatti sono io che ringrazio voi perché si parla di DevOps però le sfide del packaging e del deployment spesso rimangono non ascoltate, non so come dire, poco discussi quindi insomma vi ringrazio davvero per questa possibilità grazie a te per essere venuto a trovarci sappi che come diciamo sempre Gitbar è da oggi anche un po' tuo in realtà lo era anche da prima visto che sei una delle parti attive del nostro gruppo telegram quindi vienici a trovare ogni qualvolta c'è qualcosa di interessante di cui chiacchierare grazie di nuovo io ringrazio anche carmine e alessio per avermi aiutato nel momento più buio della puntata quando mi sono sentito perso nella selva oscura.No, il momento più brutto della puntata è quando Carmine ha nominato la parola con la R.Il momento la parola con la R? Rattel! No, Raze! Raze, stavo parlando del miglior framework per applicazioni web, giusto? quello lì, il framework di quell'azienda dove si parla liberamente su Slack che non mira con ammirazione al monolita MyFos MyFos grazie, grazie davvero a tutti, grazie di nuovo David, grazie per esserci venuto a trovare e noi ci diamo appuntamento al prossimo episodio ma non prima di avervi ricordato i nostri contatti.Info@gitbar.it @brainrepo su twitter ma soprattutto anche se ma soprattutto non si dice il gruppo telegramma.gruppo telegramma è pit bar dove potete trovare anche David, perché ti scuso David, io ho sentito tutta quanta la puntata ma quindi è Linux giusto? Esatto, e si ricomincia subito nel gruppo.Tutto con messaggi vocali mi raccomando per rendere il tutto più accessibile.Minimo 13 minuti se non il messaggio vocale viene scartato dal gruppo.il messaggio vocale è un talk dell'anima quindi più lungo è più possiamo far finta di averlo ascoltato pensavo di avere un animo ah anche possiamo parlare noi ciao ciao donate visto che Alessio dice che la ragazza chiede a quanta monta il riscatto mia moglie ha già bussato due volte nella porta della camminar patio dalla quale sto registrando e quindi io vi do appuntamento alla prossima settimana grazie a mio amico Dany, grazie a Carmine, grazie Alessio, ciao! [Musica]
