Torna a tutti gli episodi
Ep.33 - Programmazione e blockchain GitPointerBar. Gemellaggio podcastico.

Episodio 33

Ep.33 - Programmazione e blockchain GitPointerBar. Gemellaggio podcastico.

Il podcasting è un impegno ma anche una grande passione e quando incontri qualcuno con cui condividi questi pensieri ne può solo venir fuori una gatta de festa. In questo episodio ho chiacchierato con Eugenio Luca e Alessandro di podcasting, blockchain, Smart contract sempre con un punto di vista co...

6 agosto 202001:32:54
AIMusic
33

In Riproduzione

Ep.33 - Programmazione e blockchain GitPointerBar. Gemellaggio podcastico.

0:000:00

Note dell'Episodio

Il podcasting è un impegno ma anche una grande passione e quando incontri qualcuno con cui condividi questi pensieri ne può solo venir fuori una gatta de festa. In questo episodio ho chiacchierato con Eugenio Luca e Alessandro di podcasting, blockchain, Smart contract sempre con un punto di vista condiviso, quello del programmatore 🤟.Abbiamo parlato di pointer podcast, Tocket, solidity e... beh il resto lo trovate nell’oretta. Mezzo di chiacchierata.## Links- https://pointerpodcast.it/- https://www.tocket.it/- https://courscryptomonnaies.com/actualite/vitalik-buterin-ladoption-massive-est-plus-importante-que-les-etfs- https://www.facebook.com/pg/thesamephotoofvitalik/posts/- https://cryptopotato.com/top-10-legendary-photos-of-vitalik-buterin-ethereums-co-founder/- https://web3js.readthedocs.io/en/v1.2.11/- https://securify.chainsecurity.com/- https://superblocks.com/- https://www.npmjs.com/package/serverless-python-requirements## Contatti@brainrepo su twitter o via mail a info@gitbar.it## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

Descrizione

In questa puntata ospitiamo Luca, Alessandro e Eugenio del Pointer Podcast per un'immersione nel mondo blockchain. Parliamo di puntatori crittografici che ti sgamano se manometti i blocchi, di mining come "indovina la parola magica", di come Ethereum sia un computer distribuito che ti fa pagare per ogni operazione, e del loro progetto Toket che vuole sconfiggere il bagarinaggio. E scopriamo che educare l'utente alla blockchain è praticamente impossibile, buona fortuna.

Takeaway

  • Blockchain è un ledger di transazioni distribuito e tamper-proof: Ogni blocco punta al precedente con un puntatore crittografico. Se modifichi un blocco vecchio, il puntatore si rompe e tutta la rete se ne accorge. La modifica viene respinta.
  • Il mining risolve il problema dei generali bizantini: Gli algoritmi di consenso (Proof of Work, Proof of Stake, Proof of Authority) permettono di discretizzare il tempo e decidere chi può aggiungere il prossimo blocco. Bitcoin usa Proof of Work: chi risolve l'indovinello per primo vince.
  • La decentralizzazione è teorica, la concentrazione dei miner è reale: La potenza di calcolo è accentrata su poche mining farm. Se si mettono d'accordo, possono fare un attacco del 51%. Ma non lo fanno perché rovinerebbe il valore dei loro Bitcoin. I soldi sono la vera sicurezza.
  • Ethereum è programmabile, Bitcoin no: Bitcoin è solo transazioni. Ethereum ha gli smart contract scritti in Solidity/Vyper, che girano su tutti i nodi della rete. Ogni operazione costa gas (frazione di Ether) per evitare loop infiniti che consumano risorse.
  • Il problema delle blockchain pubbliche è la scalabilità: Bitcoin mina un blocco ogni 10 minuti, Ethereum ogni 15 secondi. Non scala come un database tradizionale. Ethereum 2.0 promette di risolvere questo problema.

Bold Opinion

  • Le blockchain private sono deboli senza reward: Senza una ricompensa economica in gioco, cosa impedisce a un dipendente incazzato di perpetrare un attacco? Le blockchain private perdono la loro forza principale: l'incentivo economico.
  • Educare l'utente alla blockchain è impossibile: Chiedere all'utente di installare Metamask, capire cosa sono i wallet, gestire chiavi private... è troppo. La tecnologia deve diventare completamente agnostica e trasparente per avere successo.
  • Gli smart contract vanno ottimizzati maniacalmente: Ogni byte costa. Usare stringhe invece di bytes32, allocare int256 invece di int8, fare loop su array dinamici... tutto questo brucia gas e soldi. L'ottimizzazione non è opzionale, è obbligatoria.
  • I tempi di conferma sono un problema UX reale: Aspettare 15 secondi (Ethereum) o 2 minuti (7 conferme) per vedere il biglietto acquistato è inaccettabile per l'utente medio. Servono soluzioni asincrone: email, notifiche push, video di gattini mentre aspetti.

Trascrizione

Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti in questo nuovo episodio di Gitbar.Non sono solo, ma prima di svelarvi gli ospiti, prima vi ricordo i nostri contatti.scrivermi @brainrepo su Twitter oppure a info@gitbar.it ma bando alle ciance partiamo subito con le presentazioni, presentazioni che saranno rapidissime con noi abbiamo Luca, Alessandro e Eugenio ciao ciao ciao ciao ragazzi chi sono? allora posso dire che sono dei colleghi podcaster e probabilmente avete già sentito il loro podcast il pointer podcast che come payoff ha un nome bellissimo "Puntatori alla tecnologia" e con questi ragazzi l'idea è quella di fare una puntata gemellaggio dove il loro know-how molto grande in materia di blockchain e il mio microscopico know-how nella stessa materia si proveranno a unire per cercare di chiarire un po' di dubbi e di avere una visione generale.Prima di tutto iniziamo con le presentazioni.Ok, iniziamo da Alessandro e da Eugenio.Li presento insieme perché in realtà hanno buona parte del curriculum condiviso, quindi parlo per entrambi.Sono entrambi degli esperti di tecnologia e studenti dell'Università di Pisa, giusto? Entrambi si occupano di blockchain e e hanno all'attivo un'interessante tesi sulla...vediamo se riesco a dirlo senza fare strafalcioni...comunicazione dei dispositivi IoT in ambienti non centralizzati esattamente ok, in un'epoca dove alla parola "master slave" si è dato un'accezione un po' razzista questa tesi diciamo è abbastanza progressista *risate* e insieme a loro c'è Luca collega sempre in pointer podcast, un data scientist che tra l'altro ha fatto un'interessante tesi vi suggerisco di andarla a cercare sulla rete, trovate magari delle cosine interessanti sulla analisi delle transazioni nella blockchain di Ethereum, dico bene Luca? Sì esatto, esatto, era una tesi di ennale Entrambi condividono un'esperienza sia all'Università di Pisa dove hanno fatto gli studi, sia con il loro podcast, che è appunto Pointer Podcast, e sia in una start-up che ha un obiettivo molto interessante e ne parleremo durante l'episodio.Ma prima di iniziare vi faccio subito una domanda.La faccio tutte e tre.Il primo che inizia risponde."Pointer Podcast" perché lo fate? - È colpa di Luca, dico solo questo e lascio la parola a Eugenio.- Sì, confermo è colpa di Luca perché fondamentalmente noi ci conosciamo da prima del podcast e passavamo giornate a parlare tra di noi di tecnologia e Luca ha iniziato a proporre "ma perché non portiamo queste chiacchierate in un podcast e diciamo in questo modo è nato un po' poi inter podcast e magari adesso Luca spiega bene perché è venuta questa idea.Si c'è da dire che loro mi danno sempre retta, non mi hanno mai detto di no quando gli propongo, c'è voluto un po' per convincerli però dopo alla fine si sono convinti abbiamo iniziato a maggio del 2019 e abbiamo iniziato in realtà un po' per gioco forse perché all'inizio ci aveva preso molto il fatto che avevamo perso un po' di tempo a creare il sito, a pubblicare sulle varie piattaforme e pensavamo un po' probabilmente senza dirlo che una volta finita questa prima fase sarebbe finito pure il podcast, in realtà poi abbiamo continuato ormai abbiamo registrato varie puntate, non siamo proprio puntuali ogni settimana ma cerchiamo di fare del nostro meglio.Diciamo che l'idea originale era quella di sia portare le nostre reacherate dietro a un microfono, ma soprattutto andare a parlare non tanto di notizie che magari le persone possono andarsi a trovare su qualsiasi sito, non so, le novità del momento, ma andare a fare qualcosa di un po' più tecnico, non so, leggere magari qualcosa relativo a un paper e parlarne.e qualche volta abbiamo fatto, qualche volta di più, qualche volta di meno, però l'idea è questa e cerchiamo di portarla avanti.Molto molto interessante.Io devo dire che ho ascoltato alcune delle vostre puntate, il tempo non mi permette di ascoltarle tutte, ma credetemi, l'iscrizione del feed ce l'ho, quindi al primo volo in aereo cerco sempre di mettermi in regola, ed è un podcast veramente interessante.la mia domanda però è una.Da ex studente di ingegneria informatica io ricordo che i puntatori erano sempre un cosiddetto granchio, erano una cosa poco simpatica, in realtà non è così, però i primi esami di informatica quando si iniziano a usare i puntatori in qualche difficoltà la si trova.Perché pointer podcast? bella domanda questa questa è una domanda su cui dobbiamo riflettere perché io non mi ricordo veramente il momento in cui l'abbiamo scelto allora diciamo che secondo me in quel momento avevamo messo da parte l'odio verso i puntatori in c ma ci piaceva il concetto un po' di portare di essere dei puntatori alle notizie o alle informazioni che volevamo portare probabilmente era questo il nostro obiettivo, la nostra idea era questa quindi l'idea è quella di riqualificare il concetto dopo che questo stesso concetto è stato praticamente mistrattato da tutti gli studenti universitari credo, di ambiti informatici Ok, adesso parliamo invece di Toket.Ho letto qualcosa, in realtà non so tantissimo, so che è un progetto dove tutti e tre, chi più chi meno, è impegnato nel lavoro.Ci volete raccontare, a noi, alla community di Gitbar, di cosa si tratta, cosa vuole innovare e che tipo di tecnologie utilizza? io vai te? sì vai allora, Tocat è un progetto che è nato dall'incontro nostro, mio e di Alessandro con un altro ragazzo, Nicola che insomma è con noi all'interno del progetto e l'obiettivo principale era quello di andare a sconfiggere il bagarinaggio, se vogliamo, nel mondo del ticketing un sogno un po' troppo utopistico forse però l'idea è quella e questo è successo perché noi eravamo comunque tutti appassionati di musica, concerti, eventi dal vivo e bene o male era capitato quasi a tutti di trovarsi a comprare un biglietto dai bagarini o trovarsi un concerto sold out perché magari i bot prendevano tutti i biglietti e li rivendevano su piattaforme secondarie.Quindi l'idea è partita da qui, abbiamo detto ok cerchiamo di trovare una soluzione a questo dato che esistono varie leggi ma non sono riuscite a gestire questo fenomeno, volevamo trovare una soluzione noi.Questo abbiamo cercato di farlo con Tocat che è una piattaforma in cui un'applicazione in cui l'utente si va a registrare e acquista i vari biglietti.L'anti-bacarinaggio sta dietro, sta sulla tecnologia blockchain, infatti gestiamo tutti i biglietti non più come ticket cartacei, ma come un token su blockchain quindi scambiabile solo a determinate condizioni e quindi non rivendibile a prezzo più alto, non comprabile da più di n persone e così via che poi tra l'altro in queste settimane abbiamo fatto il nostro primo vero test, abbiamo rilasciato le applicazioni sul Play Store, App Store e anche sull'App Gallery di Huawei, perché ci dispiaceva lasciarlo da parte E' stata piacevole la sorpresa che, sostanzialmente noi, come funziona attualmente, siamo in questa fase di test dove mandiamo alle persone un QR code che identifica il token blockchain, facciamola semplicemente.E noi quindi ci troviamo davanti all'evento a scansionare questi QR.Con immensa gioia, su tutte le persone che sono entrate non c'è stato alcun bug.e questa per noi è stata una grandissima vittoria, perché eravamo lì col computer di "oh cavolo se succede qualcosa attaccati al server" e invece è andato tutto perfettamente, siamo molto soddisfatti Ma come funziona? Fatemi capire, adesso quello che potete dire naturalmente però quando io prenoto un ticket ricevo un qwercode che ha il token del mio riferimento sulla blockchain come esatto praticamente ogni applicazione all'interno un wallet di ethereum gli smart contract sono tutti su ethereum e tu se acquisti un biglietto riceverai all'interno del tuo wallet un token quel token rappresenta il tuo biglietto unico e non non duplicabile quindi nel momento in cui tu lo acquisti e fatti una transazione con carta di credito magari per l'acquisto sia a pagamento o gratuito quindi senza nulla viene precedentemente quando l'evento viene creato viene deployato uno smart contract che emette questi token quindi nel momento in cui tu acquisti fai una chiamata a questo smart contract lo smart contract emette il token che ti viene poi recapitato all'interno del wallet nell'applicazione e una volta che tu hai quel wallet viene generato il qr code all'interno dell'app e l'utente non si accorge nemmeno in di utilizzare la blockchain.Si presenta davanti, fa vedere un QR code, attualmente è un semplice QR code, entra all'evento e via.Il funzionamento è questo fondamentalmente.Poi c'è tutta la parte di rivendita che ancora, dato che siamo nelle prime fasi, non è implementata nell'app ma lato blockchain è già gestito, che viene gestito attraverso un altro smart contract che fa da escro, quindi prende il token, aspetta l'altro che vuole acquistarlo attraverso una sorta di altro token, una sorta di stablecoin e viene effettuato lo scambio in maniera atomica.Ok Eugenio sei riuscito a mandare già il mio cervello in pappa usando parole come stablecoin.Io mi perdo.No però un'idea l'abbiamo andata quindi avete introdotto quindi il concetto di blockchain ma che cos'è la blockchain? Allora che cos'è la blockchain? Anzitutto è una tecnologia peer-to-peer e più nel concreto è un ledger di transazioni condiviso, trusted, public, raggruppato in blocchi questa è la classica definizione che utilizziamo sempre quando dobbiamo perché secondo noi identifica tutti gli elementi necessari per poter comprendere la tecnologia stessa.Infatti subito leggere di transazioni.Già sappiamo che è un insieme di transazioni e la transazione è uno scambio di valore fra due o più entità.In particolare nell'ambito della blockchain queste entità vengono definite address ed è non è altro che, facciamola semplice, è una chiave pubblica.pubblica, non è esattamente la chiave pubblica ma facciamo finta che lo sia e se lo vogliamo trattelare questo concetto nel contesto di tutti i giorni in realtà è come fosse un Iban, quindi tutti lo possono vedere ed è quello che mi permette di sapere a chi sto mandando i soldi, quindi è per questo che magari su qualche sito troviamo "ok questo è il mio bitcoin address, gli mando i soldi perché non posso fare altro da esterno conoscendo soltanto quello".Quello che mi servirebbe a me esterno per poter rubare i soldi di qualcun altro è avere la chiave privata associata a quell'address, in quel modo potrei rubare i suoi bitcoin, quindi la chiave privata deve essere tenuta no segreta di più.Quindi abbiamo detto che ci sono queste transazioni e abbiamo detto anche che sono raggruppate in blocchi, la blockchain infatti come dice il nome è una catena di blocchi dove ciascun blocco ha la caratteristica particolare di essere concatenata all'indietro attraverso dei puntatori criptografici.Che cosa significa? In particolare, per ora è visto di scendere nel tecnico, la conseguenza di utilizzare i puntatori criptografici qual è? È che se io vado a un blocco vecchio all'interno della blockchain e vado a modificare una transazione contenuta in esso, ad esempio dico che quel giorno invece non ho speso quei di 10 bitcoin che ho speso e ci metto 0, allora questo puntatore crittografico fa emergere che c'è stata una manomissione all'interno di un blocco e quindi tutti gli utenti della rete si rendono conto che c'è stata una manomissione e non accettano quindi la modifica al cambiamento della blockchain.Prima ho detto nella definizione che è shared, è Spesso quando si pensa alla blockchain, o perlomeno io spesso commettevo l'errore di immaginarmela come un blocco unico da qualche parte, in realtà è una struttura dati che è contenuta in ciascun computer di ciascun utente e la magia della blockchain è che riesce attraverso i suoi algoritmi a far mantenere queste blockchain tutte coerenti tra di loro e in qualche modo queste poi figurano come un'identità ed è sempre coerente.Quindi sostanzialmente questa blockchain è di fatto tampering proof, per il motivo che abbiamo detto che se modifichi una cosa in realtà viene consultata la rete.E poi ricordiamoci che se io vado a modificare un elemento della blockchain, in realtà quello che sto facendo non la sto modificando in questo concetto astratto di blockchain unica, ma la sto modificando sulla mia personale del mio computer.Quello che dovrei fare è poi inviare queste modifiche a tutti i peer della rete e il problema è che quando arrivo lì, cosa succede? Loro dicono "Ehi, no no no, qui non ci siamo, hai modificato un blocco, io non accetto questo cambiamento e quindi te lo respingo" e quindi questo è il modo in cui la rete riesce a autogestirsi.In particolare, il vero punto di svolta o il punto più complicato sta sul modo in cui vengono aggiunti i blocchi all'interno della blockchain.Qualcuno esiste e si chiamano nodi miner, che sono dei minatori in qualche modo.La cosa particolare è che ciascun blocco della blockchain è chiaramente costituito da un legge di transazioni e da altri valori.Questi blocchi devono essere, perché ci sono delle persone interessate a inserire blocchi nella blockchain? Perché ogni volta che viene minato un blocco, il sistema blockchain rilascia una reward a questi minatori.In particolare nel caso di Bitcoin all'inizio, quando è uscita, per ogni blocco minato erano 50 Bitcoin.50 Bitcoin, pensate, oggi sono circa 11.000 dollari un Bitcoin, diciamo, fatto veramente di gola.Quindi questo meccanismo di reward permette in qualche modo a attrae persone a partecipare alla rete bitcoin, ma siccome ci sono tante persone che potenzialmente vogliono essere interessate a inserire un blocco, ci deve essere un meccanismo per il quale si riesce a scandire, a discretizzare i momenti in cui vengono inseriti i blocchi all'interno blockchain.Questo viene fatto attraverso degli algoritmi particolari, algoritmi di consenso.Sostanzialmente riescono alla soluzione al problema dei generali bizantini, che venne postulato nell'82 dall'Hanford, ovvero l'idea era come faccio a garantire che tutti si comportino bene assumendo, come faccio a garantire che il sistema si comporti bene assumendo che qualcuno dentro abbia un atteggiamento malevolo.Questo viene risolto con gli algoritmi di consenso della blockchain.Gli algoritmi di consenso sono moltissimi, ne escono ogni giorno.Diciamo che i principali sono due, mettiamo tre dai, Proof of Work, Proof of Stake e Proof of Authority.Questi sono quelli più, che mi vengono a mente al volo.In particolare la Proof of Work è quella utilizzata dalla blockchain di Bitcoin ed anche dalla blockchain d'Ethereum.La blockchain d'Ethereum sta subendo un aggiornamento che la porterà a proof of stake nei prossimi mesi.Ma cos'è la proof of work? In realtà mi piace molto questa perché fa forse capire bene come viene discretizzato il tempo.Sostanzialmente chi risolve questa proof è una sorta di indovinello, ha il diritto, come abbiamo detto, di inserire il blocco all'interno della blockchain.Ma questo indovinello è molto difficile e è come se dicessi "indovina" e l'altra persona si dice "ok, indovina cosa" e l'altro risponde "indovina".Devi cominciare, quindi non hai una bussola che ti orienta verso l'indovinello, ma devi cominciare a sperare soluzioni a caso, tipo ad esempio e dici terra, quadro, luna, tavolo, cartello e dici "ah ok cartello bravo allora inseriscila" e capisci che questa difficoltà viene settata in modo tale che ogni 10 minuti venga fornito un blocco e quindi venga inserita all'interno della blockchain.Questo è un po' il gioco di come funziona l'algoritmo di consenso, tra l'altro una volta che il blocco viene minato, al blocco viene assegnato un identificatore che in realtà è quello utilizzato dal puntatore crittografico del blocco successivo per sapere a chi deve puntare.In particolare quando esce un blocco avrà un identificatore, quando esce il successivo all'interno di quel blocco ci sarà un puntatore all'ID del blocco precedente.E qui era il discorso che avevamo detto prima del fatto che è difficilmente modificabile, se non impossibile.Ci piace dire impossibile anche se teoricamente è in qualche modo sbagliato.Se non ricordo male era il 50% più minore, dovrebbero riconoscerlo, una cosa impossibile anche per i governi.Allora, infatti volevo aprire questa parentesi che è un po' brutta, che ci piace dire che la blockchain è decentralizzata, di fatto però concretamente se guardiamo la distribuzione dei miner, in qualche modo i miner sono queste entità che inseriscono i blocchi, ma è possibile anche identificare quali sono, e si osserva che la potenza di calcolo della blockchain è concentrata in poche entità.Cosa significa la potenza di calcolo? La potenza di calcolo è quella che permette di risolvere un dovinello più velocemente degli altri.Quindi significa che se questa potenza di calcolo è accentrata su poche persone, in realtà se queste tre si mettono d'accordo, allora tanto la decentralizzata non è e quindi supereresti il 51% e potresti perpetrare chiaramente un attacco.Ora, nonostante questo che, diciamo, sia possibile, in un certo senso, non avviene perché sotto c'è la cosa più sacra del mondo, i soldi.Ovvero che se io ho messo, ho investito nella mia azienda di miner tantissimi soldi, considerate che se googleate una mining farm, vedete che sono dei capannoni con tanti sostanzialmente ASIC dentro che fanno computazione.Significherebbe che se io andassi a perpetrare un attacco del 51%, chiaramente appartengo quindi a una delle entità che ha maggior profitto da questa azione del mining, allora succederebbe che il giorno dopo si trovi nel giornale "la blockchain di Bitcoin ha subito un 51%, l'attacco del 51% è stato modificato dai dati senza che ci fosse diritto".Allora il miner quando quando vede questo articolo, guarda il suo address, il suo portafoglio, il suo wallet e vede che i suoi bitcoin che sono 100 in realtà oggi valgono 0 e quindi chiaramente sarebbe anti, andrebbe contro i propri interessi e questo gioco è il motivo proprio per cui alla fine tutto il sistema blockchain riesce a automantenersi.Proprio per il fatto che c'è questa reward, in realtà, e proprio perché c'è quindi dei soldi dietro, è difficile pensare che una blockchain privata, perché esistono quelle pubbliche e quelle private, quelle pubbliche sono dove tutti gli utenti, anche io, posso entrarci, quelle private soltanto un set di persone selezionato in base ad esempio a blockchain di aziendali, soltanto il dipendente potrà entrare a fare parte di quella blockchain interagire con essa.Proprio per questo le blockchain private che non forniscono una reward hanno chiaramente una debolezza.Cos'è che a me dipendente, che magari ce l'ho con la mia azienda, mi blocca da perpetuare un attacco? Niente, perché oggettivamente non ho una reward, voglio soltanto annientarti, ti anniento in qualche modo se ho le potenzialità.Questo è chiaramente detto in modo molto semplice.E diciamo, questo secondo me potrebbe, diciamo l'esplicazione fatta di ora della blockchain potrebbe racchiudere tutti i punti principali.Concludo con i pro e i contro, detti proprio brevemente.Ovvero, da una parte abbiamo che non è centralizzata, ok? Abbiamo detto ora in realtà il contrario per i miner, però facciamo finta di essere decentralizzata a tutti gli effetti.di effetti, quindi significa che non c'è un single point of failure e questo è molto interessante perché è chiaramente uno dei problemi principali che si hanno con le tecnologie centralizzate.L'altra cosa è che è tampering proof, quindi nessuno, nessuno mai andrà a modificare la blockchain, perché se modifichi la blockchain perdi soldi e quindi non lo fai.I cont della blockchain, soprattutto di quelle pubbliche, è che scalano male e questo è uno dei motivi per il quale si tende oggi ad avere difficoltà ad adottare la blockchain in propri business.Scusa, scalano male hai detto? Ho sentito bene? Scalano male, esatto.Ah ok, ecco.Ok, e quindi scalando male difficilmente l'adotti nel tuo business, ma soprattutto un barlone di speranza è dato dall'aggiornamento di Ethereum, con Ethereum 2.0, che a seconda di Vitalik Buterin, il CEO dell'inventore del blockchain Ethereum, potrebbe andare a rimuovere questo problema della scalabilità.Un'altra chicca che mi veniva a mente ieri sera mentre ripensavo alla...Sono gli abiti di Vitalik, no? No, scherzavo, perché quando lo seguo ho visto su Twitter delle cose, ho visto come si veste e ho detto più chicca.E' un grande però.E' un grande, ma che è del '94, questa è la cosa che mi disturba.Senti? Eh? Esatto, anche io sono del '94 e questa cosa mi crea dei problemi.Quindi la chicca che volevo dire è questa, che è lessi sul libro, che esiste l'infanticidio di blockchain ed è un concetto molto simpatico per il quale se sei abbastanza stronzo da fare una blockchain molto interessante e se sei ancora più stronzo perché utilizzi una proof of work magari o meglio una proof condivisa da anche altre blockchain che hanno un sacco di potenza, potrebbero i miner di quelle blockchain dato che hanno questi capannoni, questi blocchini capannoni, biasi, quindi molta potenza rispetto a te che sei il piccolo povero bimbino che non hai potenza, di dire "ok ragazzi, miners, convogliate tutta la potenza sulla loro blockchain", perfetto, loro convogliano la potenza sulla loro blockchain e incominciano a manomettere i blocchi e chiaramente quando vai a manomettere i blocchi vai a rimuovere la cosa più bella della blockchain, ovvero che è il tampering proof e in questo caso quindi la blockchain può dichiarare completamente morta ed è una cosa molto interessante su cui riflettere.Sì perché uno degli elementi della blockchain come stavi dicendo è la trustability, il fatto che noi possiamo metterci della fiducia nel momento in cui perdi quella fiducia alla fine l'utilità diventa se non marginale nulla.Quindi ricapitolando, riassumendo con la zappa come mi solito fare sono una serie di, immaginiamoli come, lo so che mi starete per picchiare, dei record di un database distribuito i quali hanno un riferimento ai record precedente che non può essere modificato quindi perché modificando il record precedente si perderebbe il collegamento al record successivo e tutto il resto degli anelli della della catena diciamo sarebbero in qualche modo corrotti.Però di blockchain ne vediamo diverse.Hai parlato Alessandro di Ethereum, di Bitcoin, ma quali sono le differenze tra queste due grosse blockchain senza entrare poi nello specifico di altre blockchain perché ce ne sono un gozziliardo e ogni settimana ne esce una.Quindi quali sono le differenze sostanziali tra queste due blockchain? Allora, diciamo tecnicamente il modello delle transazioni su cui si basano è completamente diverso.Da una parte viene definito quello di bitcoin, UTXO, ora diciamo che è molto potrebbe essere complicato spiegarlo a voce, diciamo che l'idea è questa.e non la capite ci sta perché non sono in grado, che se io ho un address e voglio dare dei soldi al tuo address, quello che succede è che in realtà quello che dico è "io non sto inviando i soldi a te ma sto dicendo che questi soldi potranno essere scossi esclusivamente dal detentore della chiave privata associata al tuo address.E queste sono le UTXO, quindi Unspent Transactions.In qualche modo quella di Bitcoin ha una sorta di frontiera di UTXO che definiscono lo stato della blockchain, ovvero si è interessata soltanto alle transazioni che ancora non sono non sarebbe spese, perché quelle vecchie fanno parte della storia dei blocchi precedenti.Mentre in quella di Ethereum, in realtà, il modello di transazioni è chiamato account based model ed è molto più simile a quello che viene utilizzato nelle banche.Io ho credito zero, mi mandi 10 euro, faccio un +10 sulla mia variabile relativa all'account.In Ethereum c'è proprio il concetto dell'account, cosa che non esiste su Bitcoin.Altro aspetto è il tempo di mining delle transazioni.Su Bitcoin ogni blocco viene minato in 10 minuti, su Ethereum ogni 15 secondi.Queste sono le sostanziali differenze tra le due e l'altra in più è che in Bitcoin non è programmabile, Ethereum è programmabilissima, perché offre un linguaggio che qualcuno dice "turing completo", in realtà Butering ha detto "no, non dite che è turing completo perché non va bene dirlo perché altrimenti si creerebbero problemi e bla bla bla" è "stateful richness", è una cosa del genere, ovvero che puoi fare un sacco di cose quasi come se fosse turing completo, facciamola abbastanza semplice.E quindi permette di fare gli smart contract.E quindi qui lascio la parola al buon Eugenio.E qua arriviamo appunto al concetto di smart contract.Abbiamo parlato di moneta, di scambio valore.C'è un bellissimo esempio quando si parla di coin su blockchain che mi piace e lo voglio condividere con voi e con la community che è proprio quello che è cambiato con l'introduzione di questa tecnologia e il concetto di trasferimento del valore.quindi è stata un'innovazione nel modo di comunicare il valore non so se condividete con me la visione naturalmente un altro lato è quello degli smart contract e adesso Eugenio ce li racconta ma cosa saranno mai questi smart contract? io quando sento contratto mi viene subito la pelle doppia e penso "ho il contratto d'affitto, ho al mutuo da pagare" queste cose No, questi sono più belli, sono decisamente più belli.Ma fondamentalmente è un programma che viene eseguito in maniera distribuita su tutti i nodi della rete, della blockchain su cui siamo.Quindi quello che viene fatto è che viene scritto lo smart contract, una volta che viene deploiato viene poi eseguito chiamando una funzione all'interno di questo smart contract e l'esecuzione viene fatta dai vari nodi della rete che poi si accordano sul risultato questo viene fatto in vari passaggi, c'è la scrittura dello smart contract che abbiamo in vari linguaggi due principali sono Solidity e Vypr.Abbiamo il deploy dello smart contract che può essere fatto attraverso vari tool, si può utilizzare un truffle ma anche cose più semplici che poi magari andremo un attimo ad elencare anche per chi si vuole approcciare e scrivere il suo primo smart contract.Abbiamo poi la scelta della rete perché ovviamente quando uno va a scrivere i i primi smart contract non vuole andare sulla rete di Ethereum principale perché costerebbe soldi, esistono quindi varie reti di test e quindi tutti questi passaggi portano poi allo sviluppo dello smart contract.Infine c'è anche poi l'interazione con un'interfaccia grafica che poi è un'altra parte fondamentale perché uno smart contract fino a se stesso sulla blockchain può essere utilizzato da uno smanettone, che conosce la blockchain ma quando uno vuole portare questa tecnologia nel mondo reale va poi integrata con un'interfaccia semplice da far utilizzare all'utente.Dicevo esistono due linguaggi principali sono Solidity e Vyper.Scusami un attimo Eugenio dimmi se ho capito bene giusto per fare una sintesi.Quindi uno smart contract è, anche questo lo spiego con la zappa, una sorta di script che permette la scrittura sulla blockchain a particolari condizioni che sono indicate praticamente nello script che stiamo scrivendo esattamente, l'hai spiegato praticamente meglio di me all'interno dello smart contract ci sono dei vincoli che uno può andare a inserire e devono essere rispettati nel momento in cui le funzioni all'interno dello smart contract devono essere chiamate l'interazione con lo smart contract avviene attraverso transazioni quanto siamo su blockchain quindi tutto quello che viene fatto all'interno avviene con transazioni quindi se io voglio chiamare una determinata funzione eseguirò una transazione che chiama quella funzione e mi restituisce un risultato che scriva all'interno della blockchain poi può essere scritto in modi diversi può essere scritto in maniera indelebile nella blockchain possono essere emessi dei log che costano meno non vengono scritti all'interno ma vengono scritti in un'altra area sono ragazzi perché sono molto interessato al risparmio quello è un ambito fondamentale perché poi un'altra base degli smart contract è che almeno per quanto riguarda Ethereum perché poi esistono tante blockchain hanno caratteristiche differenti è basata sul fatto che ogni operazione ha un costo e questo è fondamentale perché la visione di Ethereum è che questa blockchain è un grande computer condiviso essendo un computer condiviso ci sono delle risorse che possono essere accessibili a tutti gli utenti e se io mando in esecuzione uno smart contract che fa un loop infinito vado a consumare risorse che possono servire a qualcun altro quindi hanno introdotto la necessità di andare a pagare per per le operazioni che fai in modo tale da evitare questo in modo tale da evitare che qualcuno vada a consumare risorse senza motivo.Prima hai parlato di Solidity e hai anche parlato di un altro linguaggio, Viper giusto? Qual è il linguaggio più utilizzato per la scrittura degli smart contract e secondo te perché? Allora decisamente il più utilizzato è sicuramente Solidity.Il fatto è che c'è stata sicuramente una scelta.Adesso se uno entra nel mondo blockchain e vuole scegliere un linguaggio è portato se non per caratteristiche particolari di vai per utilizzare Solidity per la community che c'è dietro.Questo è un mondo che comincia a essere abbastanza conosciuto, ma quando ti trovi a scrivere qualcosa ci sono delle particolarità che è difficile trovare nonostante Stack Overflow, nonostante i mille mila articoli su Medium, ci sono delle cose che vanno cercate bene per essere risolte.quindi questo porta a utilizzare, come probabilmente nella programmazione in generale, il linguaggio che ha dietro la community più forte e questo secondo me è il motivo per cui anche noi utilizziamo Solidity, che è il linguaggio più utilizzato Viper è un linguaggio che ha la sintassi molto simile a Python, a differenza di Solidity che è proprio basato il creatore l'ha reso molto simile a ECMAScript con qualche differenza rispetto a quello ma hanno basato questi linguaggi uno su ECMAScript e l'altro su Python per rendere facile l'ingresso a questo alla programmazione di smart contract.Perdonami Eugenio, ECMAScript è diciamo la definizione tipica del linguaggio che utilizza anche JavaScript quindi un po' ricorda appunto anche il linguaggio JavaScript.in realtà una delle particolarità di Solidity è che è staticamente tipizzato.Esiste un motivo per cui c'è un uso di questo tipo dei tipi in questo linguaggio? Allora, questa è una bella domanda e magari ne parliamo insieme perché non so darti una risposta probabilmente giusta a questa domanda.sicuramente i tipi sugli smart contract sono fondamentali, nel senso che lo smart contract poi non è modificabile nel momento in cui uno smart contract viene deployato, se c'è un errore all'interno di quello c'è possibilità di perdere soldi e tutto quanto Solidity non è fortemente tipato come linguaggio, a differenza di Vyper che ha una tipizzazione molto più forte la necessità di averlo staticamente dipato non so rigiro la domanda, secondo voi in realtà io stavo leggendo una cosa ditemi se siete d'accordo, anzi se avete qualcosa a dire ditelo voi io faccio la chiusa magari allora l'unica cosa che viene a me è per una questione di risparmio non so se in qualche modo Ok, e quindi chiaramente se le tipi, praticamente tipato, ad esempio in Solidity puoi dichiarare un int 8, 16, quindi chiaramente lo metti già all'inizio e dici "guarda questo è un int 8", sai che non sarà mai un int 16 e quindi occupi meno memoria sulla blockchain risparmiando.Poi non so se ci sono altre motivazioni, ecco.Luca? penso che sia la motivazione che ha detto Alessandro per il risparmio sì anche io pensavo la stessa cosa vi dico la verità perché poi ripeto non conosco solitamente però mi viene in mente visto quello che avete detto prima del fatto che comunque essendo un computer distribuito che i calcoli avvengono, le registrazioni avvengono una ogni T di tempo quindi vuol dire che che non posso scalare orizzontalmente per cui l'efficientamento e l'ottimizzazione diventano quasi un pallino fisso per cui anche il lato di calcolo quando uno script deve provare intuire a capire che tipo contiene la variabile potrebbe essere magari più comodo impostarlo come dice Eugenio una cosa molto interessante è prevenire gli errori perché quando deploio non posso modificarlo quel contratto se non creandone uno nuovo a quel punto fare un'analisi a priori in cieca a priori sui tipi lo vediamo anche quando scriviamo in javascript è uno dei motivi per cui molti di noi utilizzano typescript proprio quello di predire prevenire gli errori quindi anche credo adesso correggetemi se se sto prendendo un abbaglio anche secondo me in funzione di un'ottimizzazione di spazio in memoria potrebbe essere secondo voi? assolutamente infatti anche questa è una cosa che viene bisogna essere molto attenti a selezionare il tipo giusto come diceva Alessandro già per gli interi ci sono dimensioni diverse è sconsigliato andare a salvare stringhe ma convertirle direttamente in byte 32 eccetera eccetera perché l'ottimizzazione dello spazio porta poi ad un'ottimizzazione del costo del deploy e dell'esecuzione di uno smart contract quindi è fondamentale questo quindi da sviluppatori prima approcciavamo a uno sviluppo specialmente i full stack dove le resource...oh a chi se ne frega tanto Amazon scala quasi gratis questa era la frase no? quante volte l'avete sentita e quante volte l'avete detta io quoti pienamente? si esatto! quando però si approccia a questo tipo di mondo le performance come ci ricordava Eugenio sono importanti però io sono un maledetto feticista e una cosa che mi diverte da paura è la guerra degli editor.Quando vedo gente che si scontra io uso visual studio code io uso php storm io uso vim la lavorazione di Stavo aspettando che lo dicessi perché non lo stavi elencando e mi stavo preoccupando C'è una guerra in atto eh! Vi svelo un segreto, io ho sempre rifiutato Vim finché non ho conosciuto mia moglie Alessandro adesso esce dalla chiamata No Alessandro tranquillo, finché non ho conosciuto mia moglie Io non sono sessista a prescindere, ma quando ti senti prendere in giro da tua moglie, perché lei usa Veeam e tu usi il tuo...io da ex sviluppatore PHP, affezionato PHP Storm, ti senti un po' così quindi magari provi a installare il plugin di Veeam dentro PHP Storm ma dopo dieci minuti e quindici madonne scese sulla terra decidi di disinstallarlo.Adesso però devo dirvi che ho acquistato un libro per l'introduzione di Vim, è ancora chiuso la sulla scrivania, però conto di iniziare la lettura durante le ferie estive.Però ritornando a noi, editor per scrivere codice in Solidity.Ho visto che esiste Remix, cos'è? Si può fare con altri editor? Infatti Solidity per la guerra degli editor è il male perché quando passiamo passiamo da Vim a proporre Remix per scrivere smart contract probabilmente qualcuno ci ucciderà però devo dire si può utilizzare Visual Studio Code diciamo il plugin per scrivere sono su tutti i principali editor quello che magari uno consiglia io consiglierei è quello di utilizzare magari almeno all'inizio Remix, perché ha tutto integrato all'interno.Quindi scrivi lo smart contract, te lo compila, te lo deploya su una blockchain locale, oppure si attacca a Metamask.Metamask è un'estensione che ti permette di gestire all'interno Wallet e permette di attaccarti alla blockchain che tu selezioni.Quindi se è una blockchain di test, la mainnet, quale blockchain di test perché ne esistono varie con algoritmi di consenso diversi quindi ricapitolando direi che Remix è una buona soluzione all'inizio perché offre tutto all'interno anche i test e tutto quanto e se invece uno vuole passare a Visual Studio Code scrive lo smart contract avrà il plugin che segnala gli errori poi dopo deve compilarlo con Truffle magari che che permette di andare a compilare e deploiare lo smart contract e poi dopo interagire o con la riga di comando oppure andare direttamente con l'interfaccia grafica e interagire altra cosa a favore di Remix è che una volta deploiato lo smart contract hai i bottoni lateralmente che ti permettono di chiamare direttamente le varie funzioni all'interno dello smart contract probabilmente ecco questo va in conflitto con tutte le varie qr vim vs code intelli j però a livello di comodità è veramente comodo perché ti permette di fare a meno degli altri 12 tool di cui avresti bisogno se utilizzassi vs code ad esempio o vim domanda una cosa che uso quotidianamente e che per me è fondamentale è git Usando Remix il versionamento si fa? Non si fa? Ha senso farlo? Si fa male.Ha senso farlo assolutamente e piccola cosa che nel tempo uno ha scoperto ovviamente cancellando la cache del browser se ne vanno anche gli smart contract che uno ha sul Remix quindi ha molto più senso anzi diciamo forse per le prime volte ecco Moto Remix poi a un certo punto uno passa a un editor diverso perché il versionamento è fondamentale se uno lavora in team ma anche se uno lavora da solo e perché poi diciamo almeno fino a quando uno è in test quello smart contract lo modificherà tantissime volte e quindi lo proverà lo vedrà un qualcosa che non gli torna lo modificherà lo rideployerà quindi il versionamento secondo me è fondamentale e con Remix non è così comodo però la facilità d'uso del deploy di Remix è un motivo non esistono dei tool semplici con interfaccia? avete parlato di Truffle, no? sì però io ci ho buttato un occhio Devo confidarvi, avevo preso un corso di Udemy ma sono ancora fermo alla terza lezione e ho visto che era particolarmente complesso l'approccio rispetto a un Remix però poi la domanda che mi facevo è "Bene, se io domani ci tiro su un business io non posso deployare un Remix" "Io ho bisogno di far operare più, più, più, più tecnici" ho bisogno di versionare il codice, magari fare le pull request sul contratto e quindi la soluzione comunque c'è domanda vai vai no volevi aggiungere qualcosa? no no vai niente adesso faccio un'altra domanda qualche tempo fa ho fatto una puntata sul pragmatic tdd parlando di cypress quando stavo parlando di javascript e invece sui nostri contratti solidity test driven development è un concetto che esiste non esiste si testano come si testano? si testano e anche qui tornando al fatto che lo smart contract non è modificabile il test assume ancora più più valore perché prima di andare a deployare uno smart contract considerando che poi quello smart contract potrà avere all'interno anche degli ether anche di persone diverse se è un qualcosa di distribuito come è stato il DAO all'epoca che poi ha causato la perdita di diversi ether quindi sì si testano esistono vari tool per testarli anche questi sono all'interno di Remix quindi volendo ecco un'altra cosa comoda all'interno di Remix è che permette anche qui il test degli smart contract senza dover aggiungere nulla se no esistono tantissimi tool che permettono il test.Noi abbiamo utilizzato ad esempio un Securify, un tool dell'ETH di Zurigo che permette di Securify.Dopo riesci a mandarmi il link che lo mettiamo nelle note dell'episodio.Certo, grazie.Permette di andare a trovare tantissime errori all'interno come errori di rientra ma anche potenziali loop che mandano out of gas la transazione e quindi ecco esistono questi tool a cui dai in passo lo smart contract e ti cercano le varie falle all'interno che sono quelle classiche.Esistono poi dopo possibilità di fare dei test direttamente le funzioni quindi per vedere i classici unit tests per vedere se la funzione funziona come come gli aspetti quindi quindi esistono test unitari anche l'itest di integrazione no naturalmente girano sulle test net immagino si diciamo vengono fatti nel con una io l'ho fatto con remix e l'ho fatto sulla blockchain di test di Remix, quella locale, nemmeno su Ropsten o Rinkeby che sono quelli ufficiali di Ethereum, quindi non saprei se anche lì girano ma sicuramente su quella locale sì.Perfetto, adesso un po' stanno tornando i tassi lì, lo so sto portando molto del mondo full stack in un ambiente che è un po' magari un po' diverso in termini anche di contesto d'approccio però questi sono i dubbi di quando un full stack developer vede per la prima volta quel tipo di codice.Un altro dubbio, anzi un'altra cosa che vi chiedo è un attimo fermarci sul concetto di costi.Nel nostro mondo tutto si paga e avendo a disposizione un computer distribuito dobbiamo in qualche modo contribuire affinché questo computer possa continuare a vivere.Computer distribuito è bruttissimo però è una metafora no? questa questa rete di potenza di calcolo deve pur sopravvivere e quindi vi chiedo che cos'è il concetto dal gas e come questo concetto entra all'interno appunto del concetto di smart contract.Che cos'è quando si parla di gas? Rispondo io oppure vuole rispondere Ale o Luca? ok sicuramente io preciso fondamentalmente il gas come come dicevamo prima etereum è come dice anche tu un computer distribuito per accedere per fare qualsiasi operazione che richiede un elaborazione o storage di qualcosa all'interno della blockchain è necessario un pagamento questo pagamento avviene con il gas.Il gas è una frazione piccola di un ether.Praticamente quello che viene fatto è nel momento in cui vado a deployare uno smart contract, chiamare una funzione, viene stimato il gas che viene utilizzato per per eseguirla o per deployare lo smart contract e viene richiesto il pagamento di questo.Il gas diciamo ha un costo che possiamo possiamo assegnarli noi.Che significa? Significa che ad esempio, se vogliamo, questo è un concetto particolare, i miner prendono le fee in base alle transazioni che includono nel blocco.Le fee vengono prese sia dal, diciamo, la quantità di ether che gli vengono riconosciuti nel momento in cui effettuano il mining di un blocco ma anche dalle fee che vengono inserite all'interno della transazione quindi tenderanno a inserire all'interno di questi blocchi transazioni con il prezzo del gas più alto perché loro guadagnano di più da questo quindi ogni transazione avrà un costo in gas definito come, non so, 100 gas siamo noi che diamo un prezzo a quel gas e lo paghiamo poi in Ether.Insomma la priorità dell'imbarco negli aeri quindi noi paghiamo di più e abbiamo in qualche modo una priorità implicita affinché questo nostro record possa essere memorizzato in questo ciclo piuttosto che negli altri giusto? Paolo ti butto lì una domanda, se io scrivessi uno smart contract con dentro un white true che fa poco e niente, quando è che si ferma questo smart contract? Eh, lo chiediamo a me! Quando finisce i soldi! Esatto, bravo! è proprio questo, esattamente, perché altrimenti rimane sempre il principio di non so quando finirà e questo è proprio uno degli aspetti principali per cui non si parla di touring completo ma stateful richness dal punto di vista del linguaggio della blockchain di Ethereum infatti i vari contratti hanno un limite di gas che possono spendere prima di terminare si esatto puoi impostarlo con viper ad esempio una cosa che permette in più rispetto a solidity è anche settare un upper bound di gas per ogni funzione in modo tale che ad esempio se una cosa che capita spesso è avere un array all'interno dello smart contract se andiamo a fare un for su quell'array che cresce dinamicamente ci troviamo dopo qualche tempo che magari ci costa qualcosa di esorbitante invece settando un upper bound a un certo punto si ferma e evita un altro attacco che è comune all'interno di Ethereum che è quello di andare a riempire i blocchi con una sola transazione Domanda E chi paga? L'utente Quindi se io scrivo uno smart contract chi chiama quello smart contract pagherà la fee giusto? sì funziona proprio così e questo è un po' anche uno scalino che noi abbiamo incontrato con Toket perché il discorso è se in che viene utilizzato da persone che sanno di utilizzare la blockchain quello che succede è che io vado su un exchange compro Ether, me li metto sul wallet wallet, chiamo una funzione e pago il gas che è necessario con il mio wallet.Se invece tu, utente, vuoi semplicemente interagire con un'applicazione, ti trovi a dover entrare su un exchange, registrarti, comprare ether, diventa un qualcosa di impressionante.Quindi esistono dei metodi alternativi, uno è gasstation di OpenZeppelin, OpenZeppelin diciamo un...non so come definirlo però ha tantissimi tool, un SDK, ha delle...tipo una libreria? non so se definirla come un'organizzazione open source, non so bene come definirla però diciamo mette a disposizione tool per il testing, per diciamo per deployare token, per andare a testare i vari smart contract e i e in mezzo a tutti questi tool c'è gas station che permette di andare a imputare a chi ha deploiato lo smart contract le fiche degli utenti quindi l'utente fa una transazione c'è di mezzo gas station che dice ok l'utente ha fatto una transazione il gas è x lo paga chi ha deploiato lo smart contract perfetto questo scarica l'utente da tutto e lo mette in carico di chi gestisce lo smart contract.Domanda.Esiste.Questa è una domanda che figlia di quello che avete appena detto.Ma se io sono l'entità che deploya quindi che rilascia questo contratto e a me saranno imputati tutti i costi e la transazione io ho un modo per dire solo questo set di indirizzi può chiamare questo contratto? perché essendo un contratto chiamabile da mondo a quel punto anche tu devi tutelare le tue risorse affinché non vengano completamente "mangiate" da questo smart contract pubblicamente accessibile Si, può essere definito, la cosa che mi viene in mente è può essere definito anche già subito uno smart contract.Puoi gestire una white list dentro, puoi gestire un access control ad esempio con ruoli o regole e quindi quello che fai è magari andare a vedere una lista di utenti che possono chiamare determinate funzioni e tutti gli altri li escludi e fai, quindi se provano ad effettuare transazione fai il reverto della transazione e non gli fai chiamare lo smart contract e queste informazioni dove stanno dentro lo smart contract o posso anche purgarle e mettere da un'altra parte? allora potenzialmente possono essere inserite probabilmente da qualche altra parte non so diciamo non so dirti se è possibile metterle da qualche altra parte ma sicuramente un modo c'è il fatto è che la blockchain non comunica con l'esterno quindi infatti voleva arrivare la mia domanda era proprio quella quello che si può fare si gestire su magari su ipfs o anche su un database semplicemente chi può accedere ma poi dopo qualcuno deve dare sempre l'autorizzazione alla blockchain quindi c'è un po' un qualcosa che non torna se invece viene gestito tutto all'interno della blockchain è la blockchain stessa che vede ok lui è autorizzato lui non è autorizzato e questo è garantito anche da tutte le proprietà che diciamo prima cioè che non è modificabile e tutto quanto quindi siamo più sicuri che chi esegue quella transazione ha il diritto di poterla eseguire.Si la mia perplessità era quella io mando in deploy un contratto ho il mio bel set di indirizzi un po di chiavi che distribuisco a destra e a manca domani le chiavi finiscono quindi la verifica che ho all'interno del contratto è limitata solo a quelle chiavi io per deployare devo fare un cioè per raggiungere quella nuova sette di chiavi devo fare un nuovo deploy e come faccio adesso la mia domanda è proprio questa no come lo risolvo può essere anche può essere anche dinamico nel senso che puoi sì inserirlo come variabile dello smart contract e quindi inserisco tre utenti, tre address degli utenti e quando dovrò inserire il quarto rideployo lo smart contract, questo è fattibile, ma è possibile farlo anche in maniera dinamica quindi ad esempio gestiamo un access control basato su ruoli, abbiamo che io che ho deployato lo smart contract sono l'utente root e darò autorizzazioni a tutti quelli che voglio far accedere.Quindi le autorizzazioni le scrivi sulla blockchain in modo che l'altro contratto possa accedervi giusto? esatto sì quindi quando farò una funzione che riconoscerà che solo io posso chiamarla e prenderà in input un'addressa il tuo address e ti aggiungerò agli utenti che hanno il diritto di chiamarlo e in questo modo non è necessario rideployare ogni volta esatto cosa succede in realtà se invece io devo cambiare parte della logica del contratto se avrà un altro contratto giusto? come dovrò poi, cioè la parte di convergenza dei vari dati dovrò farla poi lato front end giusto? immagino di avere una società ok? fino a oggi che ne so, emettevo biglietti, sto dicendo bagianate però seguite un po' il ragionamento, emettevo biglietti dove il codice del biglietto iniziava con A da domani il business perché sapete com'è volubile l'ambiente di business mi chiede che il codice dei biglietti deve iniziare con B una banalità che non stravolge a livello di processo quello che lo smart contract definisce ma solo diciamo il valore di una stringa io però non l'ho previsto il fatto che questa questa questa questa prima parte della stringa potesse variare quindi magari non ho fatto una variabile dove buttavo dentro quel valore.Per cui poi mi ritroverò due contratti con due set di record che poi dovrò andare a far convergere.Questa è la situazione.Sostanzialmente sì, diciamo che non è banale fare questo tipo di aggiornamenti, in realtà è complicato ma quando uno va a sviluppare uno smart contract già è seriamente importante crearlo il più modulare possibile, in modo tale che poi stacchi un pezzettino, lo reinserisci devi rispettare tutto per un'altra parte.E comunque devi far convergere tutto necessariamente in un secondo momento.O troviamo qualche hack, cioè qualche cosa intelligente per evitare, ma...dal punto di vista...Io direi di sì.Oggettivamente non vi vengono soluzioni molto intelligenti.Anche secondo me sì, magari puoi far agganciare il nuovo smart contract a quello vecchio e magari farlo comunicare però direi che...Si dovresti aver preveduto che siccome c'è la possibilità allora devo lasciare la possibilità allo smart contract iniziale di poter comunicare con altro però sai questa cosa lo dici dopo averle fatte queste cose e quindi è complicato poi prenderci male No sapete io immagino una situazione agile dove il rilascio viene fatto, interazioni quindi la mia forma mentis è molto legata a quel modo di vedere le cose e credetemi per me è uno sforzo che spaventa quasi il fatto di dovermi prendere tutte le responsabilità all'inizio quindi chapeau a chi lavora nell'ambito domanda chiunque voglia rispondermi mi risponda prima di passare in realtà alla parte front end mi viene in mente una domanda.Quando si parla di scrittura di smart contract da sviluppatore full stack penso al fatto che quando scrivo il mio codice utilizzo una buona, una significativa quantità di librerie di terze parti.Quando si sviluppa con solidity in ambito blockchain esistono librerie di terze parti esistono dei tool dei package manager che le gestiscono oppure se ne fa meno uso perché i casi d'uso lo prevedono ma in modo marginale Allora, chi vuole rispondere a qualcun altro? Vai, tranqui, vai.Se ne fa uso, ma probabilmente in maniera ridotta rispetto alla programmazione standard, nel senso che quando vai a sviluppare un smart contract in realtà è una logica già ben definita, nel senso hai dei vincoli che devi andare a...dei vincoli da far rispettare.Non...difficilmente si vanno a scrivere contratti così complessi da dover andare a inserire le librerie.Di solito, almeno per la mia esperienza, mi è capitato di inserire le librerie per andare a effettuare controlli sulla sicurezza, quindi magari sull'overflow, l'underflow, i vari attacchi conosciuti sugli smart contract.diciamo ci sono librerie sviluppate sempre, quelle che ho usato sempre da Open Zeppelin, testate, open source e quindi affidabili che vengono importate all'interno del codice, sono fondamentalmente altri contratti che includi e importi all'interno.Però ecco, nella mia esperienza non ho mai utilizzato librerie che mi permettessero di fare altro.viene fatto, è una cosa abbastanza comune, magari comunicazione tra contratti quindi se ho un contratto che fa l'emissione di biglietti, facciamo il caso nostro noi abbiamo un contratto che fa l'emissione dei biglietti, un altro contratto che permette la rivendita di quei biglietti sono due contratti che si integrano tra loro ok quindi comunque è possibile importare librerie di terze parti e utilizzarle e queste librerie ti danno la possibilità, ne espongono magari degli altri contratti che tu quindi quando deploy il tuo contratto deploy anche i contratti collegati adesso mi è più chiaro questo prima di passare al front end ultima domanda sono curiosissimo mi sto martellando di domande che neanche all'esame universitario più rompi male però credetemi sono tutti dei dubbi che sono dei sani dubbi da sviluppatore full stack che non conosce la tecnologia e quindi dice sì ma il mio mondo funziona così come funziona quell'altro mondo.Parliamo per un attimo di continuous deployment e continuous integration.Quindi rilascio continuo.Esiste qualcosa? Io stanotte credetemi ero alletto e pensavo a questa cosa, mio moglie mi guardava come uno scemo Però gli dicevo ma caspita una cosa che cambia così poco perché in realtà se tu rideploy stai creando un nuovo contratto Ha l'esigenza Insomma di avere sistemi per semplificare quella parte di processo sinceramente non so risponderti a questo perché non non mi è mai servita fondamentalmente quindi non l'ho nemmeno cercata più di tanto e quindi io personalmente non so risponderti non so se gli altri hanno visto qualcosa magari curiosando Allora nemmeno io sostanzialmente I set base in generale, quelli che sono i più noti per fare scritture di smart contract, quindi poi test, integrazioni, sono tutte relative un po' all'ambito truffle, con il quale ci integri Ganache, che è questa interfaccia, questa blockchain privata che viene creata soltanto sul tuo locale, sul tuo computer, sulla quale tu sostanzialmente testi velocissimamente.efficaci, test te le scrivi poi con javascript per fare i test però anche io non sono mai entrato troppo nella profondità in questa tematica relativa a blockchain e quindi...il mio ragionamento era serve davvero perché in un contesto dove deploy così poco perché fondamentalmente deploy così poco magari il continuous deployment lo togliamo e possiamo ragionare in termini di continuous integration.Io vi dico quello che ho trovato ieri sera, perché qui sono andata a guardare e ho trovato, se ho capito bene quello che il sito dice, perché erano ormai le due passate quindi potrei aver preso un abbaglio, ho trovato questo superblocks.com.Ci sono arrivato attraverso un articolo su Medium dove, se ho capito bene, loro propongono tra i loro servizi una sorta di continuous integration per blockchain, se ho capito bene.l'ho aperto adesso il sito però dicono che chiuderanno il 31 agosto ma per le ferie o falliscono? no no, permanentemente ah, ok quindi vuol dire non serve io l'ho provato ma non è arrivato ok, questo mi era sfuggito non ho avuto grande fortuna, un po' come me ne gli piace agli schinesi con le motivazioni ma non so perché, adesso va bene No, io ci sono arrivato attraverso un articolo su Medium e ho detto "prova a chiederlo ai ragazzi se ne sanno qualcosa" perché nel nostro mondo io, vi dico la verità, senza continuous integration e continuous deployment probabilmente non potrei vivere e starei in questo momento a terminare di deployare gli ultimi cinque progetti a mano su SSH.quindi in realtà la mia domanda nasceva da quello.Chiudiamo per un attimo il capitolo "Solidity e Smart Contract" e andiamo in un ambiente dove mi sento un pochino più a casa.Le nostre applicazioni non girano in Solidity.Noi siamo abituati a vedere le nostre applicazioni tramite interfacce grafiche sostanzialmente in html, un po' di css e del javascript a fare da colla quindi come ci possiamo interfacciare ai nostri smart contract, Luca? ci puoi aiutare a capire un pochino questa parte del processo? sì, diciamo che quando mi sono avvicinato io al mondo di questi smart contract è stato per un esame e l'esame prevedeva che si sviluppasse una distributed application quindi sia il contratto con Solidity sia un'interfaccia e io all'epoca siccome ero un po' curioso e volevo provare React.js ho utilizzato React.js per svilupparmi il front-end di questa distributed application però ci stanno anche...praticamente diciamo che quello che utilizziamo...React lo possiamo scegliere, ma possiamo scegliere anche qualsiasi altra soluzione.La cosa fondamentale che utilizziamo è una libreria che si chiama Web3 che permette di interagire con la blockchain.Alessandro e Eugenio, se dico qualche cosa sbagliato poi correggetemi.Permette di interagire con la blockchain e nel caso mio o anche nel caso in cui sviluppiamo un'applicazione web, è Web3.js ma questa libreria è stata sviluppata in vari linguaggi, per esempio c'è anche una versione per Dart che avevo guardato per integrarla in un'applicazione Flutter In pratica Web3 ci permette, nel momento in cui andiamo a sviluppare il frontend, di fare le chiamate allo smart contract.Quindi, per esempio, ho il pulsante per inviare un'offerta all'acquisto di un qualcosa.Premendo quel pulsante faccio la chiamata tramite Web3 allo smart contract.quindi la mia applicazione deve conoscere l'indirizzo dello smart contract e deve conoscere un altro dato che viene fornito al momento in cui faccio il deploy che è l'hubby del contratto in cui sono definite tutte le varie funzioni che sono disponibili all'interno del contratto e nel momento in cui ho questi due dati posso andarmi a fare queste chiamate con Web3 e per utilizzarlo poi, nel momento in cui ho completato lo sviluppo di questa applicazione, devo utilizzare un'estensione che è Metamask, che è un'estensione per il browser disponibile su Firefox e Chrome.Praticamente questa estensione ci permette di accedere al nostro wallet di Ethereum per fare in modo che quando faccio la chiamata il costo venga pagato tramite il mio wallet di Ethereum.Quando anche avevamo fatto un altro progetto insieme avevamo sempre usato React e in quel caso avevamo creato una chat che non era proprio l'esempio migliore però era abbastanza semplice e potremmo far vedere un po' tutte le varie funzionalità del contratto però per esempio tu e Genio l'anno scorso non avevi usato React, giusto? No, io mi era capitato di usare proprio JavaScript base per un sito e anche lì avevo utilizzato Web3.js e Metamask ma mi è capitato anche utilizzare Web3.py Che non permette l'integrazione con metamask e a quel punto va proprio inserita la chiave privata dentro per firmare le transazioni Si sta vedendo che in realtà C'è il porting quasi in tutti i linguaggi vedeva adesso il client per php Magari la cosa interessante di web3gs è il fatto che in realtà con l'integrazione di metamask semplifica tantissimo la parte di utilizzo della chiave in realtà però mi confermate che si può usare anche senza metamask web 3 sì si può usare anche diciamo fuori dalla dal front end L'avevo usato da terminale per andare a scaricare delle varie transazioni Diciamo che quello che usiamo per fare il front-end ognuno sceglie un po' quello che meglio crede, la cosa fondamentale è questo webtree perché ci permette di fare poi l'integrazione e andare a comunicare con il nostro contratto sono curioso in realtà se sapete qualcosa ditemelo anche se ho visto che praticamente tutti utilizzano webtree per interfaccia arm sì? se esistono delle alternative a webtree cioè delle librerie sì ce n'è in realtà ce n'è io ho provato etherjs se non sbaglio si chiama adesso lo riprendo al volo sì vedo che esatto il primo che mi dà è proprio etherjs e poi c'è truffle contracts e taejs quindi ci sono comunque delle alternative perché in realtà tutti i video che vedi tutorial, qualunque cosa sulla rete ho visto che 90% dei casi utilizzano web3 o anche visto che è abbastanza semplice da usare fondamentalmente tu gli dai l'indirizzo dello smart contract, gli dai l'habit che, correggetemi se ho capito bene, è una sorta di interfaccia per poter fare le chiamate dove vengono un po' raccontati metodi chiamabili virgolette e poi ho visto che in realtà tutto funziona attraverso rpc no? chiamate remote veramente veramente interessante questo ci permette di portare poi i nostri le nostre applicazioni blockchain con frontend oltre a fare le chiamate semplicemente al contratto a me è una cosa che mi era piaciuta è il fatto che tu ti puoi mettere in ascolto di eventi, quindi per esempio se un'altra persona chiama il tuo contratto e magari tu vuoi ricevere una notifica nel momento in cui un'altra persona chiama quel contratto, tu ti metti in ascolto di quell'evento e ricevi la notifica nel momento in cui stai utilizzando il frontend di questa applicazione.o anche banalmente se vuoi ricevere una carina notifica quando viene minato un nuovo blocco per esempio questo l'avevo usato per controllare quanti blocchi passavano tra l'altro un evento e un altro quindi ricevo una notifica se vedo che erano passati un toto di blocchi mi confermate che spesso questa cosa è data dalla natura sincrona della scrittura nella blockchain scrivere sulla blockchain ci mette del tempo io non ho una risposta immediata quindi potrei dover rimanere in ascolto affinché la mia transazione viene registrata veramente un mondo affascinante ragazzi quando uno si mette in ascolto dei log può definire, cioè magari chiaramente uno potrebbe essere sconnesso, no? Quindi è possibile definire "voglio l'ultimo log generato", "voglio gli ultimi 10 log generati" e quindi non deve essere necessariamente sempre pronto a prendere l'evento, non è che una volta lanciato scompare, anzi rimane.primale.Ecco qua.Domanda i problemi più grandi che avete avuto nello sviluppo nell'interfacciare uno smart contract con il front end? Le difficoltà più grandi dove stanno? Io personalmente l'integrazione questa qua della gestione degli event ci ho messo un po' inizialmente per farla funzionare e poi poi un errore che ripetevo spesso e vabbè quello è una cosa un po' stupida in realtà è il fatto che magari tu rideploy il contratto e perdi mezz'ora perché non cambi il lobby o non cambi l'indirizzo però quella è una cosa che ti fa perdere soltanto tempo poi quando ci ripensi e la risolvi facilmente Eugenio, Alessandro, voi? A me ne vengono in mente due.Una proprio recente, ci siamo affacciati su AWS e ho creato una lambda dove andavo utilizzando python, volevo integrarci Web3Pi pi e il problema è che web 3 pi non riusciva a integrarlo nel senso che deve essere per inter per inserire una libreria su lambda va fatto il pacchettino in zip inserito e dava un sacco di problemi non ho trovato soluzioni su internet e tuttora sono passato 3gs anzi che web 3 pi quindi ancora non sono riuscito a integrare web 3 pi su AWS.Guarda Eugenio se ti posso essere utile ho avuto un problema simile perché stavo provando a fare una cosina con mia moglie una lambda che utilizza lei per lavoro siccome io le lambda le uso quotidianamente ormai.Utilizzo un tool si chiama serverless framework non so se lo conosci.Si chiama serverless, ci ho fatto anche una puntata su questo e semplifica il deploy sulla lambda puoi deploy sulle lambda di amazon di AWS occhio che puoi comunque deployarle anche su google su diverse e su azur quindi puoi puoi fare deploy su contesti diversi comunque python è il problema delle delle librerie con python sulle lambda di AWS per questo framework esiste un plugin.Io cosa faccio quando scrivo script python? Mi creo il mio ambiente virtuale, mi faccio il mio file di requirements e lancio l'install con pip.Molto semplice però peccato che le dipendenze tu non te le trovi a stretto giro e soprattutto è difficile accedervi.Cosa succede? Per questo framework, per questo serverless, esiste una piccola estensione, mi sa che si chiami Python Lambda Depth qualcosa del genere poi se vuoi me lo guardo tu installi questa estensione che è un pacchettino npm perché serverless è scritto in javascript e semplicemente non fa altro che tirarti sullo stack di CloudFormation con il bucket dove metti il codice ci butta lui il codice poi ti crea la lambda ti attacca CloudWatch per vedere tutti gli eventi quindi fa tutto lui praticamente e cosa fa questo scriptino non fa altro che creare un container docker si ho capito bene con le tue dipendenze e deployarlo insieme alla lambda immagino come livelli come layer di lambda a quel punto tu dovresti avere a disposizione le dipendenze io ci ho provato e funziona.Quindi fantastico lo provo subito.Buttaci un occhio.Sì perché io ripeto python lo uso pochissimo, l'ho usato su lambda e senza dipendenza di terza parte però con il problema che ho avuto a questione di giorni, tre quattro giorni fa, con mia moglie questa è la soluzione che abbiamo adottato e funziona tutto alla perfetta.L'altro problema che volevi raccontarci L'altro problema è più da ragionare nel senso che che succede quando l'utente acquista qualcosa e vuole l'utente abituato a spingere il bottone per il pagamento e trovarsi la cosa nell'applicazione del sito web? Che succede se devo aspettare? Nel senso Ethereum impiega 15 secondi per mediamente validare una transazione che non è tanto.Però è buona norma aspettare quelle 7-8 conferme.Per un utente è tanto aspettare un minutino o due minuti per vedere la cosa nell'applicazione e quindi diciamo il dubbio che ho sempre è "ok lo faccio aspettare, devo trovare un meccanismo di backup per fargli trovare comunque quella cosa e poi sostituisco con l'informazione della blockchain".Ho sempre un po' questo dubbio quando...video di gattini, video di gattini li tieni insolati ai browser e questa è l'altra soluzione in effetti, un bel gatto no però vedi potresti creare una lambda che rimane in ascolto della transazione registrata io la parte di blockchain, sto dicendo quello che mi avete insegnato voi oggi, ma magari nell'altra parte vi posso essere un pochino più d'aiuto, però in quel caso potreste rimanere in ascolto, collegarvi a un servizio che può essere le notifiche push che stanno su firebase o così e utilizzare o le push notification o le web push in modo da ricacciare in modo asincrono l'utente e nel frattempo magari provare in modo creativo di raccontare la stampa del biglietto so a me l'idea stupida che mi viene in mente è quella di mettere una gif dove c'è la stampante che sta stampando il tuo biglietto "se sei stanco di..." le nostre stampanti sono ancora stampanti ad aghi "se sei stanco di aspettare tranquillo ti mandiamo una notifica push" la girate dal punto di vista...utilizzate l'operazione simpatia per catturare l'informazione vero è che comunque ragazzi i software complessi spesso sono asincroni.L'esempio più semplice che mi viene in mente è il software bancario.I movimenti non li vedete se tutta stante.Quindi in realtà oggi come oggi la soluzione che mi viene in mente è quella appunto di sviluppare magari più canali di asincronicità.quindi gli mandate l'email, gli mandate una notifica web push, gli mandate una notifica push e tra l'altro esistono dei sistemi che ti permettono, che vi permettono di farlo.Uno di questi che mi viene in mente così è OneSignal che è un servizio che dà la possibilità, probabilmente lo conoscete anche già, che dà la possibilità di mandare delle notifiche push e web push e websocket per aggiornare la pagina tutto con un unico tool che ha dei prezzi veramente super contenuti se non nulli E vi da una mano da questo punto di vista Io non lo conoscevo Alessandro tu invece parla anche tu dei tuoi problemi In realtà l'hanno detto hanno detto insieme Eugenio e Luca, nel senso che sicuramente uno dei più grossi problemi è gestire gli eventi asincroni quando si incomincia a utilizzare Web3, perché non capisci bene come funziona, c'è il concetto di "devo aspettare transazione ricevuta" o "quando è confermata", insomma ci sono un po' di meccanismi che devono essere approfonditi.Un problema in realtà che trovavo quando abbiamo sviluppato la pointer DAP, che è questa chat decentralizzata che sviluppammo tempo fa, era relativo al fatto del "ok, ma se io faccio entrare la persona su un sito che si basa su Web3 e quindi gli serve un wallet, come faccio ad addestrarla e dirgli "ok, apri Metamask" e quindi in realtà indagando è venuta fuori questo meccanismo interno a Web3js che ti permette proprio di far attivare automaticamente Metamask e se non ce l'hai ti dice "guarda, ti serve Metamask" ed è utile perché chiaramente se no l'utente trova una pagina bianca e dice "mo che devo fare?" almeno quello lo indirizza.Comunque quando guardi in prospettiva poi il problema front end blockchain è sempre relativo al fatto che ci sono dei ritardi, come faccio a visualizzare quella cosa in modo intelligente, perché come dici te trovi o soluzioni simpatiche o devi educare l'utente alla blockchain, ma educare l'utente alla blockchain è sostanzialmente impossibile, no? Buona fortuna! Esatto, esatto! Che poi lo state facendo, tra l'altro! Il mio buona fortuna era veramente sincero e dal profondo del mio cuore! Allora, senti, io chiaramente cominci poi a vivere in un contesto dove senti blockchain tutti i giorni, però non ti rendi conto le persone intorno a te quando ti muovi dal contesto che magari non ne sanno niente.Sostanzialmente mi sono trovato a parlare a una classe di ragazzi di prima superiore che non so perché, ma io ero convinto che i loro blockchain sapessero cosa fosse.Forse ero un po' troppo ambizioso in questa e loro mi hanno guardato tutti i torti "Bitcoin" e lì mi aspettavo che alzassi una mano su un pc e "3 o 4".Esatto tutti i sordi.E quindi niente, è difficilissimo educare il utente, non è per niente banale e la soluzione simpatica è sicuramente la migliore.Vero.Io ripeto rimango ancora perplesso sulla difficoltà d'accesso.Questa è una cosa che mi ha spesso anche limitato ad approfondire.Cioè il fatto che se non voglio fare delle cose particolarmente complesse devo chiedere al mio utente di installare MetaMask che è il punto d'accesso più semplice tra l'altro.Che però vuol dire che io a mia madre che ha 60 anni devo spiegare che cosa è un'estensione per un browser che pensando per quanto lei sia comunque non sia comunque l'ultima arrivata per lei il browser è qualcosa che usa per vedere internet quindi questa è la mia perplessità secondo me molto del lavoro che ancora si deve fare in questo ambiente è proprio l'eliminazione di questo tipo di frizioni Sì, deve essere completamente agnostico da questo punto di vista.Pensa che ci sono stati, incominciano a essere delle prove per integrare dei wallet di default all'interno dei cellulari.Questa chiaramente sarebbe un'ottima cosa, perché non ti rendi più conto che stai magari interagendo con la blockchain e allo stesso tempo puoi utilizzare roba offerta dalla blockchain.Il fatto che quando deve installare i plugin, già lì l'utente normale dice "Oh, io non mi fido perché chiedo a installare questo plugin, che cosa fa?" e chiude.Infatti sì, e penso che parte della complessità del vostro progetto Toccat fosse proprio quello di astrarre quel tipo di concetti, perché poi da quello che mi avete raccontato e dalle poche informazioni che sono riuscito a racimolare sulla rete, ho visto che comunque molto del vostro impegno era indirizzato in quella, anche perché è un'app generalista.e si propone di esserlo.Ragazzi io sono super felice di aver fatto questa oretta e mezzo di chiacchierata con voi, mi ha fatto immensissimamente piacere anche a me, anche a noi.Grazie per l'invito.Grazie per averci invitato.Grazie.Ciao ragazzi erano Eugenio, Luca e Alessandro che ci hanno aiutato a capire un po' di più di questo mondo che sembra da fuori così complesso e che parla in termini di blocchi, di crittografia e nulla.Detto questo noi ci aggiorniamo alla prossima settimana con altri contenuti.Prima di salutarvi vi ricordo rapidamente i contatti, potete trovare tutte le info degli episodi su www.gitbar.it, là trovate anche le transcription.Potete scrivermi a info@gitbar.it o a @gitbar su Twitter Se l'episodio vi è piaciuto, beh, aprite il vostro client di podcast e iscrivetevi al feed e se proprio vi è piaciuto davvero tanto, perché no, lasciate pure una recensione sull'applicazione podcast di Apple o sull'iTunes Store Niente, da Lione temporaneamente, prossima la partenza è tutto Ci sentiamo la prossima settimana Ciao! GitBar, il circolo dei fullstack 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 degli attrezzi dei fullstack dev.dare.[Musica]