Benvenuti su GITBAR 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.Bene e benvenuti, prima di iniziare la puntata, l'episodio di oggi voglio ricordarvi i contatti.potete trovarci digitando www.gitbar.it entrando direttamente nel nostro sito dove trovate per ogni episodio la sua scheda con la trascrizione, le due righe di nota dell'episodio stesso e i link che sono spesso un punto di riferimento importante per andare poi ad approfondire quello che io vi racconto durante la puntata anche perché non ho abbastanza tempo per entrare nei particolari degli argomenti che tratto quindi se avete voglia appunto di esplorare un pochino di più un pochino più a fondo gli argomenti che andiamo a vedere ogni episodio beh quello può essere un ottimo starting point per entrare nel mondo che insomma visitiamo episodio per episodio detto questo e ricordato che potete mandare i messaggi a info@gitbar.it e @brainrepo su Twitter possiamo partire alcune puntate fa vi ho parlato di come avevo intenzione di realizzare il sito base, la casa, l'elemento centrale di Gitbar beh questo sito è già da diverse settimane che è in produzione e che funziona tutto sommato abbastanza bene.Vi voglio in questo episodio raccontare come è stato strutturato anche un pochino nel dettaglio tecnico.Devo dire che proprio strutturando, pensando e progettando questo sito internet mi sono approcciato a Gatsby.Gatsby, ve ne ho parlato diversi episodi fa, è un motore tra virgolette per la realizzazione di siti statici in javascript che utilizza ampiamente react e graphql.Vi consiglio di andare a sentirvi l'episodio vediamo un po' adesso vi dico anche il numero dell'episodio l'episodio è il numero 9 quando parlo di Jamstack per andare a scoprire un po' come funziona Gatsby.Allora, nella realizzazione di Gitbar io cosa ho fatto? Avevo una sorgente di dati che erano le API di Spreaker.Utilizzo Spreaker perché in realtà mi permette in modo molto rapido di caricare dei contenuti senza preoccuparmi di gestire spazio scalare fare insomma tutti tutte le cose necessarie quando in realtà poi si cresce o un servizio che tutto sommato mi genera anche i feed RSS già pronti per essere distribuiti nelle varie reti non varie piattaforme come quella di podcast di Apple o quella di Google Podcast o quella di Spotify quindi in realtà semplificandomi questo tipo di processo riesce e è riuscito soprattutto a farmi andare in produzione veloce e farmi produrre questo questo podcast senza perdere troppo tempo a pensare agli elementi di tipo tecnico perché uno dei problemi che si hanno quando in realtà si vuole realizzare un prodotto in termini di contenuto se si è uno sviluppatore, un appassionato di tecnologia, spesso si scade, si cade nella ricerca del tecnicismo migliore se si parla di sito web della piattaforma più performante magari si fanno mille ottimizzazioni preliminari non necessarie o si sceglie l'attrezzatura, i microfoni più fighi per rendere l'audio sempre migliore, spesso si perde di vista il contenuto quindi si esce con una puntata, due puntate, spesso anche povere di contenuto e poi il progetto va a morire beh io per evitare questo problema, siccome so che ci casco spesso in in questo tranello, per evitare questo problema sono partito veramente super base, pensate che il primo sito era una paginetta html e le prime puntate le ho registrate con le cuffiette dell'iPhone per poi passare alla registrazione con lo zoom e infatti sentite questo audio stereofonico molto particolare in alcune puntate per poi migliorarmi volta per volta acquistando un microfono anche di una certa caratura e delle attrezzature che hanno reso insomma la qualità anche audio un po' superiore però chiudiamo questa parentesi perché poi divago torniamo all'architettura dopo un paio di puntate attraverso più o meno attorno alla sesta e la settima ho iniziato a realizzare il sito web del progetto quindi vi dicevo mi baso prevalentemente sull'API di Spreaker per ora cosa succede? quando pubblico una puntata beh, monto l'episodio, lo carico su un'applicazione che si chiama Forecast se non mi sbaglio che mi permette di inserire anche i capitoli sull'mp3 carico la cover, scrivo il contenuto di introduzione con i link e butto tutto su Spreaker Spreaker che mette a disposizione delle API mettendo a disposizione queste API io ho la possibilità di accedere in modo di accedere direttamente utilizzando il mio sito a questi dati ed è infatti quello che vado a fare con Gatsby in fase di building infatti di generazione del sito statico Gatsby fa una chiamata a Spreaker, ottiene gli episodi e partendo da questi episodi va a generare da una parte una pagina statica per ogni puntata dall'altra va a generare la lista degli episodi che poi vengono renderizzati nella pagina episodi appunto ma questo non è l'unica cosa che in realtà va a fare perché i dati che ottiene da da Spreaker sono in qualche modo arricchiti e viene per esempio generato il numero consecutivo di puntata perché le API di Spreaker non restituiscono un ID, un numero sequenziale di puntata, quindi puntata 1, puntata 2, puntata 3.Per farlo viene generato un nodo nel GraphQL, negli elementi appunto che si vanno a convertire per Gatsby e in quel modo riesco ad ottenere insomma dei dati un pochino arricchiti, miglioro la qualità del testo converto i link all'interno della descrizione in elementi HTML cliccabili e faccio tutta una serie di piccole elaborazioni che mi permettono di generare la pagina dell'episodio in modo fruibile insomma tra l'altro per ora inserisco il player di Spreaker conto di bypassare a breve l'utilizzo del player di Spreaker e realizzarne uno mio con un mio piccolo sistema di statistiche, poi vi dirò come ho intenzione di farlo però per ora c'è il player di Spreaker che funziona abbastanza bene e quindi lo tengo.E' più o meno questo il flow della generazione delle pagine per episodio però in realtà c'è un passaggio intermedio che vi voglio raccontare che è la generazione della trascrizione e diciamo in qualche modo il motivo per cui vi sto parlando in questo episodio.Come si realizza la trascrizione? Il processo è molto semplice, è un processo che in qualche modo ho voluto realizzare anche per mettermi alla prova, provare a utilizzare una tecnologia che non mi era comune e infatti ho deciso di utilizzare le lambda di AWS, quindi servizi di Amazon e ho provato a utilizzarle utilizzando un framework chiamato serverless.Ve ne ho parlato anche di questo se non mi sbaglio nella puntata delle lambda, l'episodio numero 14.Quindi cosa vado a fare? In realtà intanto cosa sono le lambda? Sono delle funzioni che girano all'interno dei server di amazon dove tu non hai bisogno di provisionare il server e fare tutta una serie di configurazioni necessarie per far eseguire questa funzione.quindi cosa ho fatto? ho realizzato una prima funzione che viene chiamata una volta al giorno questa funzione non fa altro che aprire il feed rss del podcast e andare a verificare se c'è un episodio il cui file non è presente in un bucket s3 quindi nello spazio fisico se in realtà l'mp3 degli episodi, del nuovo episodio non è presente all'interno dello spazio fisico, beh il compito di questo script è quello di scaricare questo mp3 che in questo caso risiede nei server di speaker e andarlo a mettere dentro il mio bucket s3 e qua finisce il suo primo compito.Quindi è semplicemente un'operazione di scaricamento di file.Questa è la prima funzione serverless.La seconda funzione cosa fa? Viene attivata nel momento in cui viene generato un nuovo file nel bucket delle registrazioni quindi dove ci sono tutte le puntate.Nel momento infatti che viene generato un nuovo l'oggetto viene avviata questa funzione serverless che non fa altro che chiamare un altro servizio di Amazon AWS che si occuperà di fare la trascrizione dell'episodio quindi la trascrizione in realtà viene avviata nel momento in cui c'è questa chiamata attraverso l'API però la trascrizione di per sé è un'operazione di tipo asincrono quindi non abbiamo una risposta immediata tanto più che sarebbe quasi impossibile averla visto che le puntate durano dai 18 ai 20 minuti all'ora e mezza delle interviste insomma delle puntate più lunghe quindi in realtà amazon ha bisogno del suo tempo ho calcolato che mediamente per una puntata di un'oretta ci mette circa un'ora un'ora e mezzo per generarmi la trascrizione cosa succede automaticamente quando lancio una transcript quindi una chiamata al servizio di trascrizione viene generato su un nuovo bucket S3 quindi su un nuovo spazio fisico memoria un file JSON contenente appunto la trascrizione alla fine cosa ho? la prima lambda che si occupa di scaricarmi il file quando questo file non esiste solitamente è lo stesso giorno che io vado in pubblicazione con il nuovo episodio e questo file viene inserito sullo spazio s3 poi ho un'altra lambda che una volta che vede che viene creato un file nuovo non fa altro che avviare il chiamare attraverso l'API il servizio di trascrizione e avviare appunto l'operazione di transcript e poi c'è una terza lambda cosa fa questa funzione? questa funzione non fa altro che applicare i diritti di lettura quindi intanto viene chiamata quando viene generato un file di trascrizione quindi quando il motore di transcript di amazon finisce il suo lavoro e mi genera sull's3 delle trascrizioni un nuovo file e cosa fa? non fa altro che intanto impostare i diritti di lettura in questo nuovo file e chiamare la compilazione nuova del sito attraverso un webbook.sì proprio così perché il sito è ospitato nei servizi di netlify.che cos'è netlify? ve ne ho probabilmente parlato sempre quando vi ho appunto spiegato abbiamo chiacchierato sui Jamstack è un provider molto basico che però permette di ostare a titolo gratuito o con dei costi molto limitati dei siti statici generati con vari motori tra cui appunto gasby cosa succede questo provider si interfaccia al repository git e ogni push all'interno del repository o comunque ogni azione che cambia la struttura del codice beh avvia una nuova compilazione del sito statico naturalmente voi poi potete indicare quali sono le azioni che deve fare quando i comandi da lanciare quando appunto riconosce che c'è una nuova push ha una funzione però al suo interno molto interessante che è quella del webhook quindi la possibilità di avviare la ricompilazione del sito chiamando un endpoint url.questa cosa è molto interessante perché in realtà mi permette in modo completamente automatico una volta che c'è stata la trascrizione di ribuildare il sito e inserire il transcript.Questo è più o meno come funziona il processo di trascrizione degli episodi all'interno poi del sito di github.it.Diciamo che non è ancora un processo pienamente limato ma devo dire che il suo sporco lavoro lo fa.Devo ancora fare un po' di tuning coi tempi in modo da permettere una generazione più rapida possibile dell'episodio una volta pubblicato, della trascrizione una volta pubblicato l'episodio e altri piccoli affinamenti che mi permetteranno di renderlo ancora più performante.Più che altro è un esercizio, ed è stato un esercizio per avvicinarmi a questi mondi che in realtà mi hanno mi hanno catturato quindi ho iniziato a usarle a pieno anche nei miei processi lavorativi.Quali sono gli obiettivi che mi pongo per migliorare ancora di più il sito? Beh uno è la realizzazione o l'utilizzo di un player terzo che non sia Spreaker.Questo perché in realtà Spreaker inserisce tutta una serie di tracker che mi piacerebbe evitare di inserire.2) liberarmi di google analytics all'interno del sito perché in realtà non servono.Posso fare insomma le mie statistiche in modo un pochino meno pesante di come le fa google e magari realizzare sempre serverless, dei piccoli motori di statistiche per contare il numero di ascolti per episodio in un modo un pochino più dettagliato rispetto a come può fare Spreaker e soprattutto in un modo un pochino più libero nel senso che ho i dati grezzi e posso farne quello che voglio senza dover sottostare alle strutture di Spreaker.Insomma in un modo o nell'altro staccarmi, sganciarmi un po' da quelli che sono i servizi offerti e da questa piattaforma che devo dire funziona da dio però ha dei limiti.Vi faccio un esempio molto semplice che è l'esempio che sto c'è il problema che sto affrontando questo periodo è la gestione dei capitoli.Spricker ha una gestione dei capitoli per fatti suoi nel senso che nel mio processo di lavoro io devo caricare i capitoli con un altro software forecast e poi quando upload il file su Spreaker devo ricaricare i capitoli quindi da una parte o mi libero di Spreaker e realizzo tutto da me ma come vi dicevo non voglio entrare nel loop di sospendere tutto perché devo realizzare la piattaforma o preferisco fare passo per passo e svincolarmi volta per volta da alcune dipendenze che utilizzo tra cui appunto Spreaker.Vi dicevo cosa sto realizzando e cosa intenzione di terminare a breve di terminare un piccolo scriptino a linea di comando che prende semplicemente un file Markdown dove ci sono anche i capitoli elencati il titolo, il numero dell'episodio, l'immagine base della cover e questo script in modo automatico mi deve generare da una parte la copertina dell'episodio dall'altra mi deve inserire nei metatag tutti i capitoli tutti i capitoli con appunto il tag TOC che mi permette di avere anche la lista dei capitoli una volta che ha fatto questo non deve fare altro che in questo caso perché uso speaker, chiamare le API di speaker, uploadare il file, inserire i capitoli di speaker in questo caso e insomma in qualche modo automatizzare il processo di upload e di pubblicazione dell'episodio.Questo diciamo è la fase, il processo che sto andando a sviluppare nel tempo libero quando appunto la preparazione degli episodi non mi prende troppo tempo.Avrete sentito il mio gatto miagolare? Abbiate pazienza non posso spegnerlo non esiste un telecomando per disattivarlo.Pazienza.Vi dicevo spero che questo episodio vi sia piaciuto.Vi ho raccontato un po' come funziona il flow di pubblicazione il sito e il motore di transcription di github.it io spero, ripeto, vi possa essere utile e nulla non faccio altro che ringraziarvi e ricordarvi i contatti.Intanto se l'episodio vi è piaciuto e vi interessa seguire gli altri episodi quando escono beh non dovete fare che aprire il vostro cliente di podcast preferito sia Apple Podcast, Google Podcast, Spreaker, Spotify insomma quello che preferite io uso Castamatic per esempio cercare Gitbar e iscrivervi al podcast settimanalmente quindi riceverete tutti gli aggiornamenti.Altra cosa importante per entrare in contatto con me e farci una chiacchierata, contribuire alla realizzazione degli episodi, potete tranquillamente iscrivermi a info@gitbar.it o a @brainrepo su twitter.Io spero di avervi fatto compagnia per qualche minuto anche oggi.Questa puntata è un po' atipica perché non va ad ad aprire e esplorare un mondo specifico ma insomma vi racconta un processo che abbiamo messo in piedi e ho messo in piedi per il Potex quindi è una puntata abbastanza pratica un po' diversa dalle classiche puntate di Gitbar fatemi sapere insomma se vi è piaciuto.Detto questo io non posso far altro che salutarvi qua da lione è tutto un saluto alla prossima settimana ciao git bar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con brain repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e degli strumenti immancabili nella cassetta delle attrezzi dei full stack
