[Musica] Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al GITBAR e davanti a una birra, tutto ci sembra un po' meno grave.[Musica] Bene e benvenuti su GITBAR, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Questa volta veramente in una location speciale e non siamo soli tra l'altro, come potete vedere dietro, tipo...lato, abbiamo tanti amici con noi in realtà non ancora tanti perché abbiamo espugnato l'aula, è stato bellissimo scrivere Gitbard appertutto sui fogli quest'anno però l'aula dell'anno scorso che l'anno scorso abbiamo espugnato furtivamente, che è quella a fianco tra l'altro dove verrà registrata un'altra puntata tra l'altro, esatto, è stata assegnata ai BOF, come si chiamano? tipo...non lo so...gruppi auto organizzati che è stata veramente una bella idea e soprattutto è stato un colpo di culo trovarla vuota.Trovarla libera, sì sì sì che tra l'altro qui a fianco di noi ci sono gli amici, amicissimi di VLC che prete hanno la stanza per tutto il giorno ed è effettivamente piena quindi ha un suo senso.Ha un suo perché e noi intanto per registrare siamo qui - Sì, perché siamo su Mac e quindi giustamente bisogna fare un quick time, bisogna rimanere nell'ecosistema.Detto questo io direi che possiamo introdurre questo argomento, questo è un pre-episodio di quello che anticipa quello che verrà tra un po' registrato anche con...ah non vi posso dire con chi? - No, no.- Ah sì perché l'avete già sentito quell'episodio.- Ah perché esce prima.- Esatto.un loop del programma con i ragazzi di continuous delivery l'episodio che vi da presto allora noi che andiamo a registrare di là la puntata che abbiamo appena registrato di là.Io mi sono già perso che questi salti temporali iniziano a essere difficili specie perché la mia sveglia stamattina era prevaleva abbastanza presto io alle 4 ero già in viaggio quindi è stato un lungo viaggio però detto questo cerchiamo di introdurre l'argomento di oggi.Oggi vogliamo parlare di podcasting che è un po' un ulteriore loop, no? Un podcast che parla di podcasting.Però ci sono un sacco di cose che interessano gli sviluppatori e che in parte stiamo trattando col progetto FURVIE.Lo so, vi ho già rotto le palle all'ennesima potenza e al mio amico Carmine le ho rotte ancora di più.- Ma in realtà il retroscena è che prima che uscisse il repository di Furvier è uscito un vecchio repository che era tutto quanto JS prima di quello c'era anche un repository fatto con l'Aravel quindi proprio la notte dei tempi però ecco da qualche mese è partito veramente a grande velocità il progetto Furvier grazie anche all'aiuto di Flavio e di Luca e quindi vogliamo parlare di questo progetto e vogliamo parlare di podcasting e di open podcasting.Allora posso fare io l'intervista tuo? Ti intervisto? Mi intervistassi signore! Ciao Mauro! Ciao! Ti ringrazio per essere qui con noi oggi.Bene e benvenuto! Bene e benvenuto! Oggi parleremo del tuo progetto "Fourvier", anzi il tuo progetto, progetto della community, non so come definirlo in realtà.Che cos'è Fourvier? Allora per capire cos'è Fourvier bisogna fare un passo indietro e provare a capire che cos'è il podcasting.Tutti oggi parliamo di podcast qua, podcast là, vediamo due perlozzi, uno e due, a parlare davanti a una telecamera, ok loro stanno facendo un podcast.Io sono abbastanza opinionato su cosa sia un podcast e cosa non lo sia.Per me un podcast è un contenuto audio distribuito attraverso RSS, lo so sono molto audio/video scusatemi distribuito attraverso rss sono molto old school in questo.No, infatti quando hai detto audio sto dicendo "ah cazzo, allora sto facendo il video, sto facendo qualcosa" in realtà no perché per esempio uno dei motivi per cui ho sempre detto che geet bar è un podcast nell'episodio è perché geet bar nasce come contenuto audio anche quando registriamo le puntate in video, le puntate sono pensate per essere un contenuto audio.Il video poi aggiunge quel tocco che aiuta magari a contestualizzare visivamente quello che si sta facendo però fondamentalmente gli episodi generalmente possono essere fruiti anche solo audio.Sì, sì, sì, sì, ma sì poi alla fine che credo sia anche lì la difficoltà e la bellezza del podcast.Ci sono concetti che è più semplice di spiegare in video perché effettivamente se voglio parlare di Laravel o di Angular vs React, il fatto di avere delle slide o comunque qualcosa che posso far vedere aiuta.Il fatto di produrre un contenuto solo audio significa che devi essere in grado di trasmettere il tuo messaggio che può essere anche complesso e chi ha ascoltato le precedenti puntate di Gitpark a questo punto non so dire qual è il numero perché non so effettivamente che numero sarà, avrà anche ascoltato dei contenuti che erano complessi.Cioè noi abbiamo parlato di kernel, abbiamo parlato di java, abbiamo parlato di tante cose, di intelligenza artificiale, abbiamo parlato di kubernetes ma senza nessun supporto video, cioè non c'erano le slide.Questa è la sfida secondo me che tocca e abbraccia il podcasting di natura tecnica.Allora noi siamo nel nostro lavoro siamo dannatamente visivi, il codice lo vediamo, lo scriviamo, abbiamo i nostri punti di riferimento visivi dappertutto.Quando poi il codice lo dobbiamo andare a raccontare dobbiamo avere nella nostra testa talmente chiare le strutture da non sentire la necessità di puntare il dito su "oh questa linea fa questo" vero è che quando tu fai dei contenuti audio comunque non puoi parlare di codice, devi parlare di altri, dei concetti che ci sono intorno, parli dell'idea, che è molto molto bello, molto romantico.Esatto, utilizzi una marea di figure rettoriche, a me prendono in giro dicendo che sono il ninja delle figure rettoriche, le uso anche quando non dovrei usarle, e questo è vero però in realtà le figure rettoriche, le metafore, le analogie sono gli strumenti giusti per rappresentare questi elementi perché fondamentalmente come dissi a Code Emotion e ho detto qualche volta qua nel podcast il nostro cervello lavora per...stiamo venendo dalla sala elixir, no? lavora per pattern matching quindi noi prendiamo un concetto, ne estraiamo un pattern, cerchiamo le similitudini con esperienze che abbiamo già fatto e le portiamo poi ai nostri ascoltatori e a noi stessi nella vita lavorativa di tutti i giorni.Quindi questa è la sfida.Però c'è un problema, in questi ultimi anni il podcasting è diventato mainstream, tutto è un podcast, anche il mio meccanico, anche il mio macellaio poco ci manca che voglia fare il podcast.giusto va benissimo questa parte la tagliamo giusta l'inquadratura Ciao ragazzi, confermo quello che dice Mauro, che il podcast è diventato il nuovo WordPress dell'audio, prima si improvvisava nel fare siti web, oggi il podcast è diventato sdoganato sostanzialmente.A questo punto io faccio anche un'altra domanda per tutti i presenti, anche per i ragazzi di lingua straniera che sono qui dietro di noi.Che podcast ascoltate? Perché secondo me è quella la cosa, alla fine ci sono diversi tipi di contenuti e in base al tipo di contenuto è anche un tipo diverso di linguaggio.Qual è secondo voi la differenza tra ascoltare Gitpart o un qualunque altro altro podcast tecnico rispetto ad ascoltare un podcast che non sia tecnico? Io ascolto tantissimi podcast, trascendo il genere true crime, una cosa a sé, mi metto ansia terribile e non ne ascolto però quello è effettivamente una cosa a sé.Cioè come cambia il linguaggio? Come cambia anche, non so, Qual è il tucco per fare un podcast tecnico di successo? E mi piace perché noi lo stiamo facendo, però io sto chiedendo qual è il tucco.Di successo per Gitbar? Anche no.Però, ci proviamo nel nostro piccolo.Credo che il successo di Gitbar, perché a mio avviso può considerarsi un successo, sia stato quello di arrivare a più persone possibili con delle cose complicate ma spiegate in un modo molto semplice.e sostanzialmente credo che sia questa poi la chiave e secondo me sta alla base anche di quei podcast di True Crime per esempio, no? Elisa True Crime, dove sono state spiegate delle cose molto complesse con parole molto semplici quindi credo che sia un po' questo - Io quando penso al podcast True Crime mi viene sempre in mente Bluenotte Ok, Blu Notte...allora, prima che uscissero tutti questi podcast "True Crime" in italiano, insomma, io ascoltavo anche su Spotify sostanzialmente le versioni audio di Blu Notte, dove c'era Luca Redi, che effettivamente si chiama Luca Redi, sto facendo una gaff terribile...va bene se qualche cosa non vogliamo essere querelati insomma comunque dove c'era Blue Notte ed era riversato praticamente in formato audio ed era fruibilissimo ed è ancora fruibilissimo perché le cose non erano spiegate ma erano narrate che secondo me sono due cose completamente diversa.Non si cercava di spiegare qualcosa ma di raccontarla.Credo che sia la stessa cosa che noi facciamo qui su Gitbar e sia quella la differenza per un podcast tecnico che è fruibile e uno che non è fruibile.Mi spiego peggio.Quanti di voi hanno mai provato a seguire il video di un talk, ma solo l'audio.Io sì, ci ho provato più volte, non si capisce nulla, nonostante spesso si racconti qualcosa, ok? Però ci sono quelle volte in cui non si capisce nulla, perché effettivamente il supporto visivo è importante.Poi secondo me ci sono tutta quella serie di contenuti, come ad esempio Bluenoth, che sono così fatti bene che il contenuto visivo diventa secondo me un accessorio.Cioè nel senso, se io ora dovessi guardare una puntata di "Blue Notte" e le guardo spesso, non ho proprio bisogno di vedere, a parte la maggior parte sono immagini comunque di repertorio, comunque sceneggiati che sono fatti apposta per accompagnare quello che si sta insomma dicendo.Però effettivamente, non so se sia stata una cosa che sia stata fatta apposta oppure no, il contenuto video è un accessorio perché ti sta raccontando qualcosa.Allora che cosa è il podcast? È una favola per adulti? Il podcast è uno spazio libero dove condividere concetti e contenuti.Perché dico concetti e contenuti e rimarco la cosa? Perché quello che tu hai raccontato è una tipologia specifica di podcast.Tra l'altro GitBurn, il nostro piccolo, abbiamo fatto esperimenti.Basta pensare alle avventure di Java, Sturing, durante l'esplorazione del codice che poi ho portato a CodeMotion come poi.Italo Calvino che parla di refactoring, i tre porcellini che parlano di monoripo.Alla fine quelli erano degli esperimenti proprio per provare a ricalcare quel tipo di format, ok? Che poi è il modo in cui io aprendo le cose per cui però gitbar è anche altro gitbar è un contenitore dove chi ha del valore lo mette a disposizione gitbar è quella stanza questa stanza dove ci incontriamo e chiunque abbia qualcosa da condividere può dire la sua mi direte no Mauro gli ospiti li scegliete voi.Sì ma non li scegliamo totalmente a caso insomma.No ma poi noi riceviamo costantemente delle proposte nella nostra mail, le persone ci contattano, valutiamo il contenuto, valutiamo quante in linea con la community e a quel punto la porta è aperta perché come dico sempre è un po' dopo lavoro opposto.Ma poi alla fine anche la persona sia importante, cioè nel senso il contenuto sì, ma anche la persona e il valore che può portare all'AquaMudi.Nel senso comunque la differenza tra invitare un ospite che ha qualcosa da dire e un ospite invece che vuole fare personal branding o comunque vuole fare scalpore, dare magari opinioni che sono di un certo tipo su un certo argomento insomma alla fine si tende ad evitare pure questo ma a questo punto ti faccio una domanda perché so che hai fatto entrambe e qual è la differenza tra il podcast e la radio? - Ma non voglio inimicarmi chi ha fatto radio, chi lavora nella radio perché io faccio radio da quando avevo tipo 12 anni.Sono i contenuti Carmine.Quando tu fai radio hai una cosa chiamata tempi radiofonici e soprattutto hai una audience che è un audience definita audience casuale.Per cui tu hai pochi minuti più o meno dipende se lavori a RDS o nelle altre emittenti perché i poveretti quelli di RDS dicono "ah però gli mettono il disco" però insomma più o meno tempo per passare una serie di informazioni e poi c'è il disco.Uno di quelli che prova a passare il più contenuto possibile che mi vengono in mente è Linus, la radio dj.Perché? Perché lui è il presidente della radio, il direttore della radio e quindi può fare il cazzo che vuole.Ma anche Radio 24, cioè nel senso...Sì, però vedi, ok, io Radio 24 l'ascolto dalla mattina alla sera e quando non radio 24 ascolto BMF Business che è la radio 24 francese, BFM, BMF non me lo ricordo, vabbè sapete la mia lingua.Là ci sono un po' di contenuti, perché? Perché comunque parla un segmento specifico però o sono contenuti o sono intrattenimento e è molto, o almeno forse perché non sono un economista ma molto difficile trovare entrambi.Senti prendo l'esempio del programma che adoro, uno di quelli che adoro di più che è La Zanzara.Ah ok, lo stavo per dire, ho detto aspetta non voglio fare nessuna fuorimmerda, voglio tagliare.No in realtà io volevo che tu lo dicessi.No, La Zanzara è una cosa che io ascolto con grandissima frequenza.Per dirti un'altra puntata perché in realtà il mio il mio programma di preferito a radio 24 era Oscar Giannino assolutamente e poi è passato a radiocapital ora che non faccio più niente e mi faceva arrabbiare tantissimo però vabbè detto questo la zanzara i contenuti che porta sono quello che sono tutti per intrattenimento è mero intrattenimento quello che invece col podcast puoi fare che con la radio non puoi fare e rimanere due ore come nella...tre puntate fa, stavo facendo il calcolo, come tre puntate fa a parlare di un topic per davvero due ore e l'audience ti ascolta perché? Perché l'audience non è più un cliente, l'audience è parte della community, l'audience è figlia della community e a questo punto ti puoi permettere delle licenze e delle libertà che altrimenti non ti potresti permettere certo dobbiamo lasciare l'aula mi sa carmino si dobbiamo lasciare l'aula continuiamo dopo ma dobbiamo lasciare l'aula? alle 3 dobbiamo lasciare l'aula aspetta però voglio capire sorry we are moving we leave in one minute we are recording a podcast episode quindi siamo già...- Gioco la carriera così.- Rifeghi.- Cagiavo è come il cristianesimo, dice che sei cristiano pure se non lo conosci.- Sono accesi i microfoni? - Sì.- A bomba.- Ok, cosa stavamo dicendo Carmine? - Non so mai cosa...- Livello 3.- Perfetto.- Stavamo parlando di podcast prima, no? E si parlava di come un po' i vari format del podcast possono in qualche modo non essere perfettamente applicabili al nostro dominio quindi alla parte di sviluppo software perché raccontare il codice con lo sviluppo software e raccontare il codice col podcast è pressoché impossibile.Abbiamo anche detto che per quello Gitbar si è un po' evoluto ed è diventato una scatola vuota, un contenitore dove le persone che hanno del valore da portare che fanno qualcosa di interessante nel mondo delle community che sono attivi in qualche settore specifico, vengono e parlano dei loro progetti, di quello che sanno, o lo condividono con la nostra community.In realtà, dicevo, il podcast è uno spazio di libertà, a prescindere rispetto alle radio, a qualunque tipo di comunicazione e lo è stato almeno fino a qualche anno fa.Da qualche anno il podcast è diventato un po' mainstream, dicevamo tutti hanno un podcast, il mio macellaio, fondamentalmente...Ma non stai registrando? Poi sì.No Carmine, registriamo domani.Ah no no, pensavo che...Io lo voglio bene, adesso gli vado...Non ho visto il rosso sulla telecamera.Amico mio, vuoi la qua? Ah, ho capito, perdonatemi, questa...non la tagliamo, mi sono scontato di pensare stranamente a design.No, dicevo, a questo punto volevo introdurre un concetto che è il concetto di open podcasting.ho parlato un po' di tempo fa sul podcast del progetto furvie fondamentalmente quello che sta succedendo è questo il podcast per me, sono un po' opinionato, lo metto le mani davanti per me è un file xml, con la specifica rss che distribuisce un file multimediale che può essere video o audio fine, questo è il podcast un strumento basato su uno standard uno strumento fruibile a tutti con i tool e le applicazioni che tutti possono realizzare un po' come l'email però anche come è successo nel mondo dell'email abbiamo visto gli strumenti di messaggistica che si sono affacciati la stessa cosa è un po' successa col podcast abbiamo iniziato a vedere strumenti che operavano come provider noi fino a oggi siamo su speaker quindi strumenti come speaker e come speaker ce ne è tanti altri, blueberry e tanti altri.Poi piano piano è arrivato anche il momento di Spotify che è Spotify/YouTube hanno applicato il concetto classico di questo tipo di corporation del "wallet garden" quindi il giardino cintato.Tu carichi l'episodio stai nel mio giardino cintato e quello è.E il primo ad averlo fatto in questo modo è stato Apple podcast no? Dio sono bullito.Stiamo parlando tipo di un servizio tipo Spotify? E' stato Spotify.Perfetto avete presente quando la cosa è banale? è stato spotify in quel in quel modo così cosa ha fatto? fondamentalmente ha graspato i feed ingestando i feed e in più ha offerto uno strumento che ti permettesse di creare dei feed all'interno della loro piattaforma.adesso quello che spotify faceva a livello tecnico era cacciare i contenuti.Questa cosa non è buona per me che sono creatore di podcast perché se tu mi cacci i contenuti io non ho le chiamate http quindi io non so chi mi sta ascoltando per saperlo devo entrare nella tua piattaforma.Questa cosa si è poi amplificata con la questione delle ads.Tutti sono andati, quando il podcast è diventato mainstream, anche i canali mainstream sono entrati nel podcasting, i canali mainstream hanno bisogno di monetizzare e quindi il mondo delle ads è entrato di petto.Qual è il problema? Il problema è che se tu o sei Spotify che traccia gli utenti in modo così capillare e preciso che mi sa dire questo è un utente che ha 18 anni che ascolta che ne so FedEx e sente due podcast di True Crime oppure se sei un podcaster indipendente sei completamente fuori dal mondo delle app, delle ads, ma va bene lo stesso.Contestualmente però se ti ascoltano un podcast libero che tu stai distribuendo via RSS con Spotify, Spotify inserisce le ads.Quindi tu stai fruendo del mio contenuto fatto da una community che si autofinanzia, con difficoltà spende il soldo e tu stai iniettando dell'advertising alla stessa community.Ecco perché durante gli episodi mi incazzo e mi dico "utilizzate delle app di terza parte, delle app indipendenti".A questo aggiungiamo il fatto dell'elemento delle esclusive.Il problema è è stato che stanno arrivando un po' di persone.Faccio community manager.Il problema delle esclusive è stato che sono arrivati hanno preso dei podcaster che avevano un certo mercato e hanno detto ok il tuo podcaster lo trasmetti solo su Spotify stesso gioco sta facendo youtube oggi e allora qual è il problema? il problema è che i podcast indipendenti si devono appoggiare a delle piattaforme lo speaker di turno, lo spotify di turno per produrre la parte tecnica del podcast perché non tutti sono tech savvy che sanno scrivere un xml a mano e i tool per generare questo tipo di contenuti è quello che è diciamo così per cui c'è questo problema, quindi serve un tool user friendly per newbie, anzi per persone non tecniche, che in qualche modo aiuti le persone a pubblicare gli episodi, esattamente quello che fanno le applicazioni di Spreaker, le applicazioni di Spotify, che però hanno un budget enorme per poterlo fare.e comunque Spricker non è che sia questa grande cosa comunque rispetto a quanto si fa a pagare Non lo so, noi lo usiamo Ha sempre performato abbastanza bene, il problema che io vedo in Spricker è che io non sono owner dell'url del mio feed quindi se domani Gitbar decide di trasferirsi dobbiamo chiedere a Springer di farci un redirect quindi siamo in qualche modo in una situazione per quanto Springer l'abbia sempre fatto e siano, io ho avuto modo di conoscere alcuni ragazzi che ci lavorano, siano delle persone super trasparenti e tra l'altro è il meno debil di tutti tra l'altro però ecco devi sempre passare per un'entità terza e la tua ownership, la tua sovranità nel podcast non ce l'hai Altro problema che hanno questi tool è che non si adattano all'evolversi dello standard.Con il diventare il podcast mainstream ci sono stati tutta una serie di movimenti dell'open podcasting, quindi Adam Carey, uno dei fondatori del podcast, del podcasting, e Dave Jones hanno messo insieme questa community per ripensare le specifiche del podcasting.Cosa vuol dire ripensare le specifiche del podcasting? pensare per esempio delle specifiche che possano contemplare i capitoli, le transcriptions, le persone invitate all'interno degli episodi e il value for value, quindi le donazioni attraverso canali terzi che non passino per forza da uno strumento centralizzatore e questi tool difficilmente si adeguano a queste richieste.Ti faccio una domanda perché io non ho usato Spricker da punto di vista di amministratore, cioè sì l'ho utilizzato ma non ho idea di come funzioni sotto, quindi c'è una differenza magari tra l'XML che ti può produrre Spricker e l'XML che potresti fare da solo? Allora diciamo che Spricker supporta un set limitato di field di tag xml perché per esempio il value for value non ha nessun interesse o potrebbe non avere nessun interesse a supportarlo una delle cose che springer non supporta ad oggi sono la possibilità di inserire nel feed chi viene in episodio quindi le persone i profili delle persone non lo permette così come non permette un solo autore praticamente ecco anche per chi mettiamo i nomi delle persone nella descrizione.Però la specifica del podcast si è evoluta talmente tanto da arrivare a dire se io faccio una puntata dove ho un ospite X ok le persone donano attraverso nel caso specifico attraverso lightning le persone donano io posso decidere di instradare una porzione delle donazioni all'ospite del podcast.Adesso, ragazzi, noi siamo tecnici queste cose ci gasano tantissimo perché ci fanno capire quanto profondo è la specifica e l'adeguamento è lentissimo, l'adeguamento a questa specifica è lentissimo e questo è un altro dei problemi quindi c'è sovranità e poi c'è il fatto che le specifiche si evolvono molto più velocemente di quanto un'impresa interesse evolvere.Questi due elementi hanno fatto sì che un po' il movimento si muovesse creando dei tool come sovereign feed che è un editor di feed che però sono limitati di per sé.Allora è da un paio d'anni che ci chiediamo possiamo fare qualcosa? Cacchio! Sappiamo sviluppare, abbiamo delle competenze tecniche conosciamo gli standard abbiamo l'esigenza e allora è il caso di iniziare a mettere in piedi qualcosa perché possiamo farlo e così è nato il progetto fur vie cioè un editor di feed rss che gira sul computer che open source chiunque può estenderlo fatto con tecnologie che grosso modo utilizziamo tutti i giorni o comunque che sono abbastanza mainstream da poter essere utilizzate fondamentalmente il front-end è un'applicazione react il back-end è un c'è un po di rust e un po di javascript anche la fine è il javascript sì va bene sia sia react c'è un po di typescript ma comunque non sono tecnologie lunari che mi sto facendo un programma in c++ per cui ho un bacino limitato e a quel punto essendo elemento libero e soprattutto sulle spalle della community si può evolvere con i ritmi e con gli interessi della community.Tu puoi hostare i tuoi feed rss e i tuoi file dove vuoi, adesso vi farò ridere, la prima funzionalità che abbiamo sviluppato era quella di hostarli via ftp e vi verrà ridere, da ridere ma siamo italiani.Chi parte col podcasting la prima cosa che fa è entra su www.aruba.it o www.topost.it e si compra il dominio mio podcast.it questi hosting la prima cosa che ti danno è uno spazio ftp il vecchio modo per avere ownership del proprio podcast era installarsi wordpress, installare pod un'estensione di wordpress, chi conosce wordpress può immaginare come è stata fatta entrare quell'estensione dentro wordpress e così in qualche modo distribuire.Il problema è che installare wordpress e installare quell'estensione per quanto wordpress sia semplice per noi qualcosa comunque da persone tecniche piuttosto che...mia mamma non lo installa, il mio macellaio non lo installa allora serviva qualcosa che si installasse con un doppio clic si potessero copiare le credenziali dall'email che ricevi di conferma direttamente dentro l'applicazione e il gioco doveva concludersi così questa era l'idea - Lo so, ho parlato tantissimo.- No, no, no, no, no, no, no, no.- Ma sono già entrati in modalità sindacalista? - Sì, sì, sì, assolutamente.C'è stata questa rivendicazione di classe per il podcasting, quindi possiamo anche andare avanti.Ok, ma io ti voglio fare delle domande dal punto di vista tecnico, così giustosi per...- Sparami.Eh, spara.- Qual è...quando tu parli di standard e di open podcasting, come si concilia questa cosa con quelli che sono delle differenze peculiari per esempio per iTunes? Allora, in realtà fondamentalmente noi nel podcasting abbiamo una serie di tag, di specifiche che sono abbastanza condivise.iTunes si, ha alcuni field particolari ma in un modo o nell'altro un po' si sta in qualche modo adeguando.Fondamentalmente quello che si fa è fallbackare con due o tre field di iTunes però per esempio il problema di iTunes è che l'immagine le vuole in un certo modo, ma è l'unico caso specifico.Quando tu mi parli dei tag di iTunes, sono perché li usa solo iTunes o sono una specifica che ha un peso iTunes ma anche altri diciamo player non so come definirli? Alcuni altri player li potrebbero utilizzare, la buona pratica in questo caso è fare i democristiani, nel senso supportare un po iTunes finché non muore.Non ci vorrà molto però...- Ma iTunes ha iTunes o anche Apple Podcast? - Parlo di Apple Podcast, non iTunes.Apple Podcast sta provando a svernare, adesso per esempio ha regalato le tre iscrizioni gratuite per tutti i podcast, però in realtà quello che Apple in tutti questi anni, essendo stata la prima a disinfettare, non è riuscito a fare è una community di podcasting legata al podcast, cioè tu hai un media così forte e e allora sono rimasti questi tag che abbiamo come legacy che non possiamo tirare via rapidamente, ce li portiamo appresso ma sono abbastanza pochi, saranno una decina i tag in tutto, che vengono dal namespace di iTunes.Diciamo per chi stesse immaginando questo xml effettivamente è il namespace dei tag.Welcome, bentornati negli anni 90.Ci sono delle accortenze particolari, tu hai parlato prima di 4vier, che tra l'altro se volete vedere com'è 4vier su github c'è anche il sito.Si, 4vier.io ok e quindi diciamo potete vederlo, potete contribuire.Siamo vicino anche alla 0.1.0 Perfetto.Quindi la prima versione che funziona e che accompagna tutto il ciclo di vita del podcasting perché ci manca da concludere la funzione di upload del feed.Abbiamo l'upload dei media, abbiamo fatto tutto però dobbiamo ancora terminare.Quando tu parli di upload del feed, quindi magari io voglio utilizzare 4v per fare il mio podcast, ho registrato la mia traccia con audacity insomma quello che sia.Che cosa succede? Cosa succede? Cosa molto semplice io ho un file audio perché questo alla fine della registrazione audio video un file multimediale cosa faccio? Ho questo file, apro furvier, la prima cosa che devo fare è creare il podcast se non ce l'ho quindi inserire una serie di informazioni che poi mi andranno a popolare il feed rss nella parte più generica chiamata channel queste informazioni in realtà le devi inserire una sola volta perché è il mio channel in realtà posso poi editarle quando voglio però lo creo una sola volta se io ho già un podcast magari creato con qualunque altra cosa furvieti permette direttamente di importare il file xml lui se lo parsa se lo valida, converte tutte le inconsistenze coi tag, per esempio per gestire l'immagine ci sono due o tre modi per farlo, lui le converte nel suo modo interno standard e a quel punto ti viene mostrato una UI già pre compilata con le tue informazioni, quindi abbiamo creato le informazioni del podcast, fase 2, devo creare l'episodio 1 o l'episodio 0, altra scheda aggiunge episodio, mi viene presentato una UI dove io posso compilare le cose e creo l'episodio questo viene salvato nello stato locale che cos'è lo stato locale? niente di magico un file xml dentro la mia library folder o rispettivamente nel sistema operativo dove ci troviamo una cartella per windows una cartella per linux cosa faccio adesso c'è questo file multimediale lo devo upload dare posso decidere di upload darmelo in autonomia io voglio applaudarlo tramite...cosa ne so...piccione viaggiatore ciò una volta applaudato un url io lo metto nel campo url e il software pensa a tutti ok però poi bisogna anche fare l'upload del feed stesso insomma sì questo verrà subito dopo ok qual è il discorso? che io posso volerlo applaudare invece con dei metodi standard noi abbiamo pensato a due modi però in realtà questa cosa può essere stesa open source, chiunque vuole implementare un altro adapter può farlo.Un adapter è verso FTP, come vi ho spiegato prima è la soluzione più ovvia dal mio punto di vista.Il secondo adapter in realtà è verso S3.Perché verso S3? Perché è pieno di provider che supportano questa specifica vi faccio un po di esempi cloudflare tu ti registri in 10 minuti in 10 secondi perché nome utente e password ti registri selezioni un flag e entri nella zona r2 mi pare si chiami quella di cloudflare e tu c'è spazio gratis poi puoi pagare l'abbonamento attaccarci un dominio amazon eccetera non lo cito perché registrarsi su amazon è tipo un bagno di sangue però c'è digital ocean a me è capitato che il macellaio sotocasa avesse un'istanza application di digital ocean per il sito oppure c'è google cloud cioè s3 è un po' una lingua franca per per per rostare questo tipo di file poi naturalmente possiamo sviluppare qualunque tipo di driver e là su sull'upload si è poi giocata una partita interessante perché i file che dobbiamo applaudare sono grandi e noi dobbiamo farlo ciancando quindi spezzettando il file e inviandolo pezzettino per pezzettino qual è il problema? il problema è che quella parte è fatta in Rust perché l'architettura dell'applicazione è un front end in JavaScript, in TypeScript React col suo state manager, con le sue cose è un back end in Rust, stiamo parlando di app stand alone quindi che gira nel nostro desktop.Le librerie di S3 di Rust non sono le migliori possiamo anche dirlo abbiamo dovuto fare un po di magheggi anche con Tauri che è il tool che utilizziamo poi per fare l'applicazione e alla fine però morale della favola noi abbiamo il file inviato chunk per chunk presto faremo la feature di resumability quindi tu ne hai uploadato la metà hai chiuso il computer lo riapri ricalchi play e ti continua da quel punto in poi anche perché se stai applaudando non lo so un video di una puntata di github pesa generalmente 11 giga prima della compressione quindi se ho un video medio o un audio medio di github pesa almeno 100 mega solo l'audio se hai una fibra non li senti se sei con una connessione a dsl sappiamo che l'Italia per quanto riguarda il gap tecnologico insomma ci sarebbe da fare un altro episodio.Io ho una 70 mega nel senso quindi posso capire.e quindi insomma questa questa feature è utile anche per l'audio.A questo punto io ho caricato il mio file mp3 nel mio hosting, ho questi dati nell'applicazione ho finito di lavorare, calco sync, calcando il pulsante sync che poi è la funzione che stiamo facendo che a livello tecnico è molto interessante perché diventa una macchina stati finiti.Adesso capite perché.Calcosync lui cosa fa? Prende i dati che ho in pancia, l'applicazione è in pancia, per quel podcast e li spedisce, li converte in xml seguendo le specifiche e li spedisce al mio provider di piacimento, sarebbe S3, S3, S3, FTP, S3, FTP, se non ne ho configurato nessuno al posto di spedirlo mi restituisce un file xml.Lo posso mandare al mio webmaster insieme ai file mp3 e ci pensa lui.La cosa interessante è il pulsante di sync.Furvie è pensato per non essere uno strumento invasivo, per essere uno strumento che ragionando in termini di specifica parli una lingua franca per cui non diventi l'owner del feed.perché a quel punto qualunque tipo di provider ti permette di importare il tuo feed.Noi vogliamo essere quello strumento che ti permette di modificarlo ma non gli appartiene.Per farlo noi, come vi ho detto prima, dobbiamo validare il feed che è in ingresso ma anche controllare la versione online e la versione che l'applicazione è in pancia per fare il check dei conflitti.attualmente abbiamo iniziato a sviluppare la parte del check dei conflitti ma il check iniziale è un check di data quindi last update, last upload e questo ci permette di dire all'utente il feed che tu stai provando ad uploadare è più vecchio, l'ultima modifica, è più vecchia della modifica che c'è online perché lo specifica del feed rss lo permette perché c'è un last update e last upload non si chiamano propriamente così però ci sono questi due informazioni nel feed rss a questo punto puoi decidere se mostrare un prompt possiamo decidere se mostrare un prompt e dire overwrite oppure ripartire tutto da capo naturalmente questo ho detto con le parole facile se poi sotto ci metti anche la logica di capire che upload system deve utilizzare come mandare il pacchetto, il file lo deve chunkare quindi lo deve lo deve tagliare deve lanciare un thread per ogni piccolo chunk che viene, no, tecnicamente è bella challenging infatti la parte rust se ci buttate un'occhia è parecchio interessante e questa cosa cavolo facendo questa cosa ho pensato noi possiamo avere in qualche modo un impatto giocando con i giocattoli tecnici, io non conoscevo una riga di last prima di iniziare a scrivere questa cosa e divertendoci, cioè e soprattutto supportando uno standard e facendo quello che ci piace fare.Stiamo facendo il comizio politico - Ma stai registrando? - Sì.- Quindi questo...- Sì.- Meglio, merda! Facciamo una cosa, wrappiamo questa e partiamo con l'altra.Abbiamo parlato un sacco di podcasting, di open podcasting, io ci tengo a dire che coda di questo episodio ci sarà un pezzo che Flavio, il ragazzo che si è occupato della parte Rust, farà dove spiega come abbiamo dovuto estendere il modello degli eventi di Tauri e di come abbiamo gestito la parte del multi upload che è una roba particolarmente interessante dal punto di vista tecnico ci abbiamo perso un mesetto buono tra pensarla e farla, tra l'altro da quel progetto è nato poi un plug-in per Tauri che stiamo rilasciando anche quello open source sotto il cappello di Fourvier.Ciao Mauro grazie per l'invito e un saluto a tutti i ragazzi e gli ascoltatori di Wittbar.Io sono Flavio e sto aiutando da un po' di mesi Mauro sul progetto Fourvier podcast, progetto che penso abbiamo sentito tutti quanti nominare nelle ultime puntate di Wittbar che punta a voler essere una desktop app per la gestione del proprio podcast.In particolare, in queste prime versioni, l'obiettivo è quello di garantire la gestione del feed RSS, fondamentalmente con i tag classici del mondo del podcasting, in futuro l'aggiunta dei tag che stanno portando alla rivoluzione podcast 2.0, quindi commenti, value for value e anche all'introduzione di strumenti per la gestione di tracce audio e magari anche del video è un progetto sicuramente molto interessante e si basa su Tauri Tauri è un framework scritto in Rust che permette di scrivere attualmente sullo desktop app ma la versione 2.0 permette anche di andare su mobile utilizzando JavaScript, il proprio framework di frontend preferito in JavaScript per la parte di frontend e di utilizzare codice Rust invece per tutto ciò che riguarda la parte di backend e si basa fondamentalmente su due grandi strumenti il primo è il runtime di esecuzione che è basato su Tokyo Tokyo è fondamentalmente il runtime per Rust per quanto riguarda l'esecuzione asincrona, il più famoso e Vry è una webview scritta in Sessiatori di Tauri scritta in Rust che per l'appunto contiene tutto ciò che viene eseguito in JavaScript e io sto aiutando Mauro per quanto riguarda la parte di Rust, quindi la parte di backend dove sono un po' più schillato, come possiamo dire e in particolare per quanto riguarda la gestione e il caricamento dei file sul server esterni attualmente sono supportate come protocolli l'S3 e l'FTP per il caricamento del feed RSS, ma in generale di tutti i file e la problematica che abbiamo avuto davanti era quella di gestire l'upload di questi file ovviamente per caricare il file bisogna far sì che in qualche modo il frontend indichi al backend il file e il backend deve poter comunicare al frontend lo stato di avanzamento o eventuali errori ovviamente la parte di interfaccia utente, in modo asincrono scollegato perchè in modo asincrono? questo lo dico perchè Tauri permette l'interazione tra le due parti di frontend e backend attraverso due strumenti il primo strumento corrisponde ai Tauri Command cioè sono delle funzioni RAST annotate con passate un termine annotate con la macro Tauri Command che fa sì che siano riamabili dalla parte JavaScript utilizzando TAU_API_INVOKE nome funzione, così come l'abbiamo scritto in Rust, arrei di parametri che quella funzione prende in input e questo è un metodo per il quale io vado a chiamare direttamente funzioni del backend c'è un'altra modalità di interazione che attraverso eventi eventi che possono essere di nuovo una duplice natura una natura global, quando sono pubblicati sotto l'appendle l'oggetto appendle, oppure relativa a una singola window in particolare gli eventi sono caratterizzati da un nome e dal payload quindi per realizzare la funzione di upload sicuramente abbiamo bisogno di tutti e due gli strumenti cioè la parte backend deve mettere a disposizione un entry point dal quale il frontend chiede di caricare un file e deve fornire le coordinate per ascoltare gli eventi relativi al caricamento cioè al progress, fondamentalmente parliamo di un intero da 0 a 100 e eventualmente un messaggio di errore nel caso in cui ci siano problemi di caricamento quindi Tauri ci mette a disposizione questi due strumenti e per la comunicazione rimane da fare la divisione, lo splitting in chunk di un file fortunatamente abbiamo trovato una libreria che è possibile specificare quanto grande deve essere un chunk lui in modo del tutto asincrono legge da disco e ci ritorna ogni volta il chunk specifico e il caricamento è stato quindi il caricamento verso l'esterno si basa fondamentalmente sulla divisione in chunk e il caricamento degli stessi se per quanto riguarda FTP la libreria che stiamo utilizzando su pftp non sembra dare la possibilità di caricare in parallelo i chunk ma onestamente non so se il protocollo proprio lo permette per quanto riguarda S3 invece è possibile parallelizzare il caricamento degli stessi e utilizzando in multipart upload, noi stiamo utilizzando la funzione S3 Rust quindi quello che succede è che il frontend ci chiama e dice "me lo devi caricare su S3" queste sono le credenziali questo è il file, io ti ritorno fondamentalmente un id che verrà utilizzato come event name sul quale ascoltare gli eventi specifici quindi io ritorno questo id, il frontend si mette in ascolto su event name=id il backend piano piano, specialmente nella parte S3 dopo aver diviso Inchunk e tutto quello che fa, per ogni Inchunk crea un Task Tokyo in modo totalmente asincrono questi task procedono in parallelo con l'upload e ognuno di loro comunica la propria percentuale al frontend quindi in particolare il caricamento su S3 risulta essere molto molto veloce è nata poi l'esigenza di dire "beh, ma io un upload lo posso anche interrompere" e quindi dopo che ho avviato il tutto e io sto comunicando in modo asincrono gli eventi ho bisogno di nuovo di essere richiamabile dal frontend per dire "guarda, l'utente per esempio ha deciso di annullare il caricamento del file git/xml" e questo di nuovo lo potevamo fare in due modi quindi potevamo fare una gestione ad eventi al contrario in questo caso era il frontend che pubblicava eventi per il backend oppure semplicemente la soluzione che poi abbiamo adottato è quella di creare un altro tauri command che non fa altro che entrare una hashmap statica che per pigrizia abbiamo implementato con Cached, che è una macro che permette di storare i risultati di un'elaborazione lunga nel nostro caso, quando il Task Reapp Loader nasce, non fa altro che storare un Cancellation Token in questa mappa che è un oggetto fornito dal Crate Tokyo Util per il quale mette a disposizione un future che viene risolto nel momento in cui qualcuno segna quel Cancellation Token come Cancelled quindi il frontend entra in questa mappa, segnale, cancella il token e tutti i task che sono in ascolto su questo token vengono notificati della cancellazione quindi escono da loro la ramo di esecuzione ovviamente il sistema funziona il problema è che è un po' farraginoso l'utilizzo in particolare è scomodo il fatto di doversi sottoscrivere ad un evento cioè il desiderata e che semplicemente il back-end ritorni un oggetto che dica affrontando "guarda" chiama la funzione listen su questo oggetto e riceverai tutti gli aggiornamenti che io ti pubblico senza dover esporre in qualche modo modo lì sul quale può mettersi in comunicazione quindi quello che è stato deciso di fare è di scorporare questa gestione degli eventi creando un layer proprio minimale al di sopra di questa primitiva di Tauri, primitiva nel senso che veramente è un blocchetto di base ed è stato apportato alla costruzione del Tauri Channel Plugin i plugin sono un'altra funzionalità di Tauri che permette di attaccare al contesto di esecuzione vari plugin che mettono a disposizione sia delle API da parte JavaScript che parte Rust quindi quello che è stato fatto è stato di creare delle struct per quanto riguarda la parte Rust e delle classi, delle interfacce, interfacce e poi classi nella parte javascript che vadano a replicare quello che è il funzionamento di un channel come li vediamo in Go, come li vediamo nella STDSync di Rust o anche in Tokyo quindi un channel in realtà è composto da due entità, un sender e un receiver poiché vogliamo permettere la comunicazione in entrambi i sensi quindi backend to frontend e frontend to backend abbiamo sender e receiver nel backend e sender e receiver nel frontend dove i sender del backend parlano al receiver del frontend e viceversa, in questo modo abbiamo una comunicazione da entrambi i versi quindi riusciamo sia a pubblicare gli eventi del progress dell'upload sia a comunicare quando per esempio l'upload deve essere stoppato e il frontend non si deve preoccupare di nulla, cioè attraverso il plugin chiama la funzione che ritorna un oggetto di tipo channel che automaticamente viene scomposto dall'API che abbiamo creato in javascript nella parte di sender e receiver della parte di frontend allo stesso modo viene restituita in RAST il sender e il receiver e diciamo la funzionalità che abbiamo ottenuto, uno dei vantaggi che abbiamo ottenuto in questo sistema è lo smontaggio automatico del componente, nel senso che quando nella parte JavaScript si ascolta degli eventi e quel componente va ad AutoScope, bisogna fare l'unlisten degli eventi per esempio quando va a autoscope, quello che è stato implementato è dire se non ci sono sender dalla parte Rust, il componente in ascolto sulla parte JavaScript può fare semplicemente la listen e se prova di nuovo ad ascoltare quegli eventi riceverà picche perché effettivamente non ci sono sender dalla parte Rust quindi quello che è stato fatto parterasta è dire "beh, io ho il sender non è altro che un atomic reference counter verso un'altra struttura interna quindi io posso avere n sender, quando questi sender vengono droppati in realtà quello che succede è che io vado a droppare l'oggetto dentro all'arc che a sua volta, quando viene droppato, è un fatto che inviare un evento gestito dallo stesso plugin lato javascript un evento del tipo "unlisten" cioè vuol dire che quando l'upload è terminato la parte javascript non deve preoccuparsi di fare l'unlisten ma è tutto automatizzato e se l'upload finisce e la parte javascript non è in ascolto non potrà di nuovo collegarsi perché io non ho più i sender a disposizione cioè non c'è nulla da ascoltare questo è lo stato attuale del plugin e proprio in questi giorni sto cercando, poiché il plugin è stato spostato da un repository a parte sto cercando di riscrivere tutto il codice in FurBear Podcast basandomi su questo plugin in realtà questa è anche una chiamata alle armi nel senso che ci sono un paio di issue e un paio di implement da fare sul plugin in particolare attualmente è prevista che la creazione di questo channel avvenga dal back-end verso il front-end ma non vedo il perché non si possa fare il contrario, cioè il front-end che fornisce direttamente lo strumento al back-end quindi questo per esempio è una issue aperta, non dovrebbe essere troppo complicato, è una good first issue e poi per esempio abbiamo una issue per fare il test end-to-end perché in questo caso è inutile basarsi sul mocking delle API a parte Rust che è Tauri, che è front-end e quindi abbiamo bisogno di metterci un test end-to-end utilizzando WebDriver I/O ovviamente ci sono anche le issue se non si è interessati a plug-in ci sono un bel po' di issue anche su Furbier Podcast sia parte Rust che parte JavaScript quindi chiunque volesse contribuire è il benvenuto ciao! bom! adesso siamo pronti per registrare il secondo episodio di oggi - Carmino, io ho finito le parole.- Anch'io.- Quindi il balocco ce lo mettiamo...- Il balocco è furvie.
