Bene e benvenuti su Geekbar, altra settimana e altro episodio.Siamo al 74esimo episodio, corriamo verso l'episodio numero 100.In realtà abbiamo già sfondato anche, come vi dicevo la scorsa puntata, i 300 iscritti nel gruppo Telegram.Quindi è sempre una corsa verso numeri più grandi.E oggi questa corsa la faccio insieme a due ammutinati che continuano a presidiare il territorio di Gitbar.Parlo di Leonardo e di Andrea.Ciao ragazzi, com'è? Ciao a tutti, ciao a tutti.Come ci scrivono da qua? Come ci scrivono? Ciao, è sempre un piacere essere qua e passare un po' di tempo a fare altro rispetto a scrivere codici.codice.Assolutamente sì e devo dire ad Andrea che ho visto che siete più ancorati alla poltrona dei parlamentari e questo mi piace.In realtà dove ci si diverte è difficile andarsene.Esatto è proprio così e abbiamo già le birre belle fresche ma prima di iniziare il mio ruolo ormai noiosissimo è quello di ricordarvi i contatti info@gitbar.it via email o @brenrepo su twitter ma io so di dimenticare qualcosa...il gruppo telegram? esatto abbiamo anche un gruppo telegram per chi non lo sapesse @gitbar mi raccomando se non vi siete iscritti iscrivetevi.oggi abbiamo un ospite però e questo ospite vorrei farlo presentare da Andrea che è diciamo stato il padrino colui che ci ha permesso di avere...Benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente Con grande, grande piacere, quest'oggi avremo con noi il CEO di Impronto Advance, il Community Manager di RomaJS, è uno speaker, è uno sviluppatore full stack degno rispetto della scena nazionale e non di meno che mio carissimo amico, quindi a tutti popolo di Gitbar vi presento Matteo Manchi.Grazie, ciao a tutti.Ci portiamo dentro i nostri amici sempre qua a parlare, vogliamo allargare sì ma sempre rimanendo in una stretta cerchia.Ci si allarga ci si allarga sempre più.Si parla dagli amici più stretti, poi ovviamente i conoscenti, il cugino del cugino e poi si finisce a fare il sito il miocugino.dev Per l'insta! No, scherzi a parte.In realtà mi fa immensamente piacere avere qua Matteo perché da una parte rappresenta il mondo delle community essendo lui il community manager per Rome.js dall'altra mi interessa perché è esperto di un argomento che mi attira particolarmente quindi Matteo la prima domanda che ti voglio fare intanto è chi è Matteo e come è entrato nel tunnel dello sviluppo software.Grazie per l'invito e colgo l'occasione di ringraziare Andrea per la presentazione e nello stesso tempo bacchettarlo perché dopo un anno di podcast, quasi un anno e mezzo, sono venuto a sapere questa cosa molto tardi, sto recuperando adesso tutte le puntate, quindi invito anche a chiunque si stia ascoltando a condividere il podcast perché è una fonte veramente stupenda di formazione.Chi è Matteo Manchi? Matteo Manchi è un full stack developer, perché nasce da questa passione per lo sviluppo dell'informatica da quando sono bambino grazie a mio padre che era molto smanettone, nei anni 96-98.Ho avuto la fortuna di avere internet a casa, ho avuto la fortuna di navigare sui siti dei Pokémon a pochi anni, quindi andare a guardare un po' i database di Pokémon e cose del genere, informazioni da piccolo.La passione di mio padre per l'informatica mi ha trasmesso, mi ricorda questa cosa, che tramite VGET mi ero scaricato tutto il database delle immagini di Pokémon nella mia cartellina con il mio 56k all'epoca.Poi saltiamo, sono molto scostante, saltiamo verso le medie, andava di moda i giochi di ruolo via chat e all'epoca c'era questo progetto open source, GDRCD si chiamava, per svilupparsi il proprio e partì così scaricandomelo iniziai lì, era un progetto in PHP, MySQL, qualche aiuto da parte mio padre che poi non ha seguito la carriera dell'informatico come programmatore ma più sistemistico, quindi riesco a tirare su questa cosa e cominciò a lavorare in PHP in terza media e me lo porto come passione, quindi come hobby e oltre allo studio, al cercare di risolvere il problema, un po' quello che facciamo tutti quanti poi per lavoro, cercare di risolvere il problema di quel progetto, di quell'implementazione che uno voleva fare e così ho iniziato ad avvicinarmi più nel mondo dello sviluppo web.Qui in Toliceo mi unisco a una piccola agenzia di sviluppo web, che mi serviva uno sviluppatore tramite un compagno di classe mi presentano e inizia, come ho già sentito, il "perché posso fare ciò che mi piace e essere pagato, perché no?" e quindi da lì è iniziato poi il parallelo tra lo studio, la triennale all'università e lo sviluppo che poi è andato avanti fino alla formazione impronta, advance e l'agenda che ho formato insieme al gruppo impronta per la parte di sviluppo e da PHP poi mi sono spostato a JavaScript, community varie e poi ecco oggi seguo un po' da full stack tutta la filiera.Come tantissimi di noi da PHP hai fatto la diaspora verso JavaScript? No no no no no no no no no sono gente che ha ancora nel cuore tutt'oggi ci lavoriamo attivamente, quindi sono tanti cuori per PHP.Sono d'accordo, anche io non ho fatto la diaspora.Non è una cosa che va molto di moda dire "tanti cuori per PHP" nel gruppo di Gitbar, in realtà però ragazzi questo...Mattia mi sta per cacciare.Questo questo pattern però ritorna tantissimo cioè io credo che se non fosse per PHP molti di noi non farebbero questo questo mestiere e poi sei approdato al al javascript hai detto che hai fondato la società la tua società no? Impronta.Sì l'impronta advance specifico perché ho fatto il luogo sviluppatore freelance e quindi anche lì forse il full stack è nato un po' anche per quello, per l'epoca era lo sviluppo web che voleva dire sia la parte PHP che la parte di frontend, un po' di CSS, un po' di JavaScript, frontend, ho iniziato a collaborare con questa agenzia di comunicazione impronta all'epoca ADV e team interno di sviluppo poi è stata costituita una società di cui sono il CEO attualmente, dedicata solo allo sviluppo.Adesso fa parte del gruppo Impronta ma con una sua accezione di sviluppo a 360 gradi sulle tecnologie del web.Capito, non avevo capito niente prima ma come mio solito, è sempre così.Io però come stavo spulciando un po' di cosettine sui te, sono approdato a YouMain.Che cos'è? YouMain è un progetto, posso dire, ambizioso che è stato veramente nato da un'idea del mio socio e portato avanti durante la pandemia e nasce come sistema di videoconferenza, di comunicazione online dedicato agli store, ai negozianti, a tutte quelle figure che nell'arco della pandemia del lockdown e che crediamo che domani siano anche concezioni che rimarranno anche in un futuro, sono rimasti bloccati dal comunicare con i propri clienti, con le proprie persone, quindi nasce da un concetto di ritrovare, quella che poi nel claim è "humanity", la possibilità di contattare e di riprendere determinati lavori in versione digitale, quindi un set di strumenti, di un linguaggio per per utilizzare il browser, così come fa Google Meet in ambito business, per entrare in contatto con i propri clienti.È un progetto che sta per uscire a breve, sul sito si stanno già dando un po' di informazioni, ed è un progetto che tramite Wind 3 abbiamo pubblicato come progetto pilota, quindi adesso tutti gli store Wind 3 utilizzano questo servizio prendere appuntamento, i propri clienti di vari store possono prendere appuntamento e parlare col proprio consulente nello store direttamente nel browser senza passare per tool esterni e quindi torniamo al discorso che ci piace del utilizzare le tecnologie che conosciamo bene quelle del web per vari contesti.Come gli ascoltatori di Gitbar sanno, Gitbar ha sempre molto a cuore il mondo delle community, essendo Gitbar stessa una community che io amo definire orizzontale, nel senso che non va a posizionarsi sulle verticalità territoriali o tematiche, rimane un pochino più generalista.Insomma è il bar dove ci si incontra dopo i meetup a bere birra, ubriacarsi e a cantare a squarciagola.E allora la mia domanda è, in realtà non è mia, la rubo a qualcuno che me l'ha suggerita, è quando nasce Roma JS e a cosa serve? Allora, Roma JS nasce, mi sfugge il numero preciso però, a luglio 2014, nasce come costola del Pug di Roma, che è il PHP User Group, è ancora qui, tanti cuoricini al PHP, che è una storica community romana del PHP, potrei sbagliare, ha spessivamente più di dieci anni sul territorio, l'ho frequentata veramente per tanto tempo, e dà un'idea di Gilles Rupert, che era un partecipante di questa community, e all'epoca, come dicevo prima, il JavaScript era un po' di front-end, cominciava magari a nascere Node, alcune cose, ma prima era un po' di front-end nello sviluppo di PHP, era quella parte lì, si iniziavano a vedere i primi front-end in backbone e come PHP User Group Roma, il Pug, era il punto di incontro, la community legata al PHP e alle tecnologie del web, era nata l'idea di fare un secondo incontro dedicato al JavaScript.E Gilles fu il fondatore che iniziò questo incontro, questo mercoledì di luglio del 2014.All'inizio eravamo sei persone, pochi che avevamo aderito e due di questi, tra me e Luca, ancora partecipano attivamente.Gilz, fortunamente adesso è palo alto in Facebook, è passato in BBC, quindi era un precursore secondo me di quello che poi è stato poi la Community, quello che è stato poi il front end, portava le sue esperienze di backbone come un page della BBC e cose di questo tipo, molto per me all'epoca, per altri noi quasi futuristi, però si cominciava a ragionare sul front end come templating, come logica sul frontend.E quindi nasce questo appuntamento, diventa mensile, di cui poi ho ereditato lo Shetro un annetto e mezzo dopo.Roma.gs è questa community che una volta al mese, giorno fisso il terzo mercoledì al mese, si incontrava e si incontra digitalmente adesso, per scambiarsi conoscenza sulle tecnologie in javascript, usando il javascript come lingua franca.Quindi alla fine si parlava di front-end, di back-end, di web gl, di sviluppo giochi, di sviluppo mobile, come anche di metodologie o addirittura la famosa meetup che tutti ricordano su di Luca come hackerare una ciabatta, questa ciabatta in web socket e come in javascript era riuscito a manipolare, a controllarla e tutto il resto.E' molto ampio, si discute un po' di tutto e poi oltre alla parte puramente di talk, quindi di speaker che portano qualche la loro esperienza, qualche framework, qualche libre, qualche lettura, qualcosa da portare e il resto è networking.Quindi ad oggi sono, a luglio saranno sette anni di Roma.js ed è una community di sviluppatori appassionati in JavaScript che si confrontano poi quotidianamente anche sul canale Slack.È diventato un grande gruppo anche di amicizie.Andrea io lo conosco tramite il Pug, poi come Roma.gs, così Alessio Biancalana che ogni tanto so che viene a disturbarti.E questo è Roma.gs.Volevo chiedere, spero di non rubarti la domanda, ti volevo chiedere come è cambiata il modo in cui vi incontrate, diciamo nell'ultimo anno e mezzo, se è cambiata, cioè se avete ridotto o completamente abbandonato gli incontri live e com'è la sensazione eventualmente di persone che prima si incontravano di persona e trovarsi "costretti" a essere online e basta.Com'è cambiata questa percezione? Allora, è cambiata, sicuramente, è impossibile negarlo, soprattutto per una community come la nostra, che non nasce su web, non nasce da un gruppo Facebook, non nasce da una newsletter, ma nasce dal vedersi in faccia, fare le domande al presentatore che sta sul palco e, soprattutto, cosa di rito, veramente ci sembra la pizzata dopo, ma la cena dopo il meet up era un momento in cui se c'erano 50 partecipanti facevamo 30 persone a cena.Quindi comunque era un momento veramente importante che tutta la community viveva per fare networking, per chiacchierare, per confrontarsi oltre l'ora e venti, l'ora e mezza di metà.Quindi siamo una community molto legata al vedersi in faccia, a parlare direttamente.Com'è cambiata? È cambiata che ovviamente non abbiamo potuto fare più nulla perché comunque anche gli spazi che ci venivano concessi e qui ringrazio anche vivamente CodeMotion che sul territorio romano sponsorizza un sacco di umili e ci dà anche degli spazi per poterle organizzare.I punto bianco non si potevano più utilizzare quindi il primo mese abbiamo aspettato l'ultimo di PCM sperando che sbloccassero, parliamo proprio di marzo e non è stato così, e penso abbiamo soltato, non mi ricordo se un altro mese, abbiamo cominciato a fargli live in diretta, ovviamente con un pubblico anche più ampio, perché con i vari gruppi, i vari community più sparsi, una volta che metti una live organizzata su Facebook e su YouTube, può partecipare chiunque.Però l'appuntamento fisso è una delle nostre bandiere, quindi il terzo mercoledì del mese è è un qualcosa che la gente si abitua a mettere in calendario, quindi meno male l'appuntamento c'era, però la rivoluzione dell'abitudine quotidiana a casa, del non vedersi, del vedere il talk ma poi sono le otto ma non si può andare a cena insieme e vada a cucinare, cioè diciamo l'abbiamo vissuta.Infatti io la butto qua, così sul tavolo, ed è una proposta per tutti gli ascoltatori di Gitbar.Noi dovremmo fare un grande mukbang, spero si legga così, è quella cosa che fanno le web star coreane di mangiare live davanti a una camera.Noi dovremmo fare una grande call zoom dove siamo tutti a mangiare insieme davanti alla webcam.Che ne dite? Che è una delle poche cose che non abbiamo fatto davanti alla webcam in quest'anno e e mezzo, quindi perché non aggiungere un altro layer di virtualità? No, quello che volevo chiedere a Matteo, ora il fatto che anche io ricevo le mail di Code Emotion dove ci sono i vari meetup, quindi volendo, ora io non ho mai partecipato purtroppo, però quello che volevo chiedere, però non so quanto è quantificabile, se, presupponendo che in presenza ogni tanto ci siano delle persone nuove che poi, quindi la community si allarga.Se questa cosa avviene anche online, quindi volevo un po' circostanziare, se altre persone di Roma, venendo a conoscenza di questa community, si sono unite alle live e quindi poi magari si incontreranno anche di persona, oppure se questa virtualità è un po' limitata? A mio avviso è limitata tanto.Abbiamo un canale Slack come Roma.gs dove ci sono circa 300 persone, anche abbastanza attive, si chiacchierano, escono problemi, si dibattono, anche con persone che magari non hai mai letto, e ne vedi anche che sono nuove, o durante una live si iscrivono, perché poi sponsorizziamo i canali e si iscrivono.Se quelle persone sono di Roma io non lo so, perché a parte il benvenuto, due chiacchiere così magari non approfondisci o non ti viene in mente di chiederlo.Se guardano quella singola diretta e non seguono il canale, seguono la pagina Facebook eccetera, non si iscrivono sul canale Slack, sono dei bounce, perché comunque poi li devi ricontattare.Una volta che venivano al meetup e si trovavano bene, ma soprattutto non è soltanto il talk singolo, perché a volte può capitare anche l'argomento super noioso per qualcuno, o super banale, ovviamente gradi differenti, però sai che se viene e lo catturi poi sa che deve che ritorna lì.Eh su questa cosa digitale avere anche l'appuntamento comunque se non ehm ti ti ti abboni alla pagina off-site, arriva la notifica e ci sarà la live domani o quando sarà eh te lo va più facilmente.C'è meno commitment per partecipare quindi diciamo beh senti se ecco e vengo se non no.Anche perché siamo bombardati comunque di appuntamenti perché oggi veramente le community sia sul territorio che c'erano prima che adesso sono globali quindi la stessa persona di Milano che aveva altri quattro meetup prima adesso ha anche il nostro land da poter seguire mentre prima la live era un di cui ci stanno tante cose quindi eccolo lì che l'offerta è tanta e poi dipende se uno si pone come di voler fare a differenza o come community che cresce intanto così senza uno scopo di voler per forza incrementare perché c'è un ritorno o qualcosa.Certo, volevo portare su questo tema anche il mio feedback, cioè per quanto Roma.js e essendo anche co-organizer del Pug Roma è qualcosa su quale ho riflettuto tanto e ovviamente giustamente gli devo dire che manca il commitment, Esatto, manca proprio questo, ma quello che prima riusciva a fare il post meetup a cena, quindi è lì che tu conoscevi davvero la nuova persona, interagivi, ci facevi amicizia, si creava quell'engagement che lo portava anche a tornare dopo il mese prossimo, no? O addirittura nei casi più fortunati riuscivi a trovare una nuova persona che voleva buttarsi il mondo dello speaking e proporre lui stesso una tematica o lì facevi anche opera di convincimento per dire che ne so buttati provo anche tu a portare la tua esperienza o oggi invece con questo è proprio lo strumento che limita secondo me perché si partecipano persone dalla qualunque però anche se vai a cercare di creare un momento alla fine per cercare questa condivisione, questo momento di "conosciamoci meglio", c'è sempre quel fattore di timidezza, non accendo la webcam, sto muto, è difficile fargli uscire fuori e anche il discorso "ah ok, sei a casa, ovviamente già ti stai ritagliando quel momento per te, c'è i bambini, devo andare a cucinare, c'è la compagna che mi aspetta, il compagno eccetera eccetera e quindi viene meno.E' come il discorso di andare alle conferenze.Cioè non so pure voi, ora ti compri tutte queste belle conferenze online ma mentre tu stai dentro la conferenza ti suona il telefono, ti arriva una notifica, ti scrive su Slack, un'email e non la vivi appieno.Invece se vai in presenza lo vivi al 100%, perché ora stai facendo quella cosa.Meetup o conference che sia ci vedo molto un'assonanza in questo.Sì, infatti io che dovrei...cioè sono l'organizer del Pug di Firenze, che però ancora non è partito perché a me non piacerebbe iniziare con un evento virtuale perché ci potresti dare poco valore e allora sto aspettando...ho visto, ho notato nel gruppo Telegram di Gitbar, molte persone di Firenze, ora vedrò con le varie aperture di fare qualcosa in presenza, perché secondo me quello dà tantissimo valore per creare diciamo uno zoccolo duro che poi si potrebbe espandere.No, assolutamente.Noi abbiamo questo zoccolo duro di 20 persone buone che girano, costruito in anni, perché comunque ogni tanto ne perdi qualcuno, ogni tanto ne guadagni qualcun altro.Però comunque le nuove… veramente la cena che facevamo, veramente 30 persone l'abbiamo fatte tranquillamente a cena con noi abbiamo un roadhouse lì sotto quindi l'unico velocemente ci può consegnare la roba considerando anche i mezzi per rimuoversi da Roma e tornare era un'esperienza che valeva forse tre quarti del meetup in sé che adesso ti perdi perché alle 8 e 10 dicono giustamente la gente sta a casa non si può fare networking a questo ora ma vado a cucinare, è tardi per affrontare questi discorsi, è successo anche questo.Poi ognuno a casa è facile dire "vabbè oggi faccio il meetup" però se sei a casa e hai mille distrazioni, mille necessità diverse, non è il "oggi non torno a casa fino a mezzanotte".Chiarissimo.Infatti il mondo delle community è cambiato parecchio e secondo me deve ancora esprimere la vera metamorfosi.Abbiamo ancora bisogno di tempo per vedere come cambierà.Sicuramente si evidenzia la necessità del contatto umano come in qualunque cosa in questo mondo oggi.Cioè io ho bisogno di riabbracciare la gente, bermici una birra, al di là del mondo delle community e quindi di riflesso va a impattare anche quel mondo.Devo dire però che dobbiamo cambiare discorso.Qual è il main theme qua? Anche perché potremmo rimanere tutta la sera a parlare del mondo dei community e la butto qua.Un giorno mi piacerebbe fare un bel panel con una decina di persone dove si parla solo di community e magari farlo coinvolgendo anche gli ascoltatori di Gitbar potrebbe essere una cosa interessante però dobbiamo anche parlare di giocattoli sono quelle cose che usiamo tutti i giorni e infatti Matteo è qua in veste di giocatore di React Native.Eccoci cambio la maglia metto quella di giocatore di React Native.Allora, la mia domanda è una.Posto che mi cazziano sempre nel dire che React non è un framework, e hanno anche ragione, ma React Native è un framework? React Native è un framework.Mi prendo questa bold opinion, mi prendo le responsabilità di questa bold opinion.è un framework perché comporta a dietro tante incastri e tante diciamo pattern e come si dice standard che impone per fare certe cose quindi è molto più di una semplice libreria posto che anche qui il termine libreria sul react ormai è abbastanza diciamo nell'ecosistema non puoi vedere React come esempio di libreria, ma verrò con lo scudo la prossima volta che ti blast la libreria.React Native ormai è uno strumento troppo ampio per essere solo una libreria.Che cos'è React Native? È un framework sviluppato da Facebook per sviluppare applicazioni native utilizzando react e qui si apre un tema ampissimo su che vuol dire utilizzare react e vuol dire scriverla in javascript se sono applicazioni native e javascript spesso sono contrapposte e diciamo nell'immaginario delle persone sono due strade parallele che non dovrebbero toccarsi perché tutti noi, penso come Fullstack, abbiamo magari avuto la necessità di spostare un sito su un'applicazione o di cercare di sviluppare un'applicazione con le tecnologie sempre del web, di JavaScript e quant'altro, in particolare HTML e CSS, e quindi chiunque ci sia avvicinato a questa cosa abbia toccato almeno una volta PhoneGap Cordova, quindi progetti open per utilizzare quello che sono le tecnologia HTML, JavaScript e CSS all'interno di un'applicazione.Ecco queste sono delle webview, quindi dei mini browser, soprattutto come idea iniziale dell'epoca, erano dei mini browser dove girava dentro la nostra pagina HTML, JavaScript e CSS, quindi scrivevamo effettivamente un mini sito e poi veniva utilizzato all'interno e c'era una serie di binding nativo che venivano utilizzati per accedere a qualche API.Questo è il mio primo talk ufficiale al CodeMotion, di qualche anno fa a Milano, quindi ho un ottimo ricordo di questo.La mia storiella era proprio sul...chi si è avvicinato e poi ha messo un box shadow all'epoca per fare qualcosa di effetti su Cordova, soprattutto quando era il main topic, ha sofferto tantissimo perché le performance sulle web view all'epoca su mobile erano veramente pessime e se non ricordo male proprio sulla parte iOS le web view erano limitate rispetto a Safari.Apple ha sempre avuto questa cosa ancora oggi lo notiamo in tante cose molto particolare di chiusura per cui per disincentivare questo approccio le web view che dava nativamente erano meno potenti non ricordo se proprio l'accelerazione 3d o cose del genere rispetto al safari browser.Altre alternative sul javascript non so se qualcuno di voi l'ha mai provato, Titanium, il loro claim era "Write once, run everywhere".Chi l'ha provato non può scordare una schermata rossa della morte, perché era quella rossa con una scritta verde sopra con l'errore, e quello che faceva era cercare di convertire il codice in linguaggio nativo, quindi staccarsi dal concetto di WebView, è stato e usare un unico codice per più piattaforme e questo è stato sicuramente un progetto molto precursore diciamo dei tempi moderni ma purtroppo non possiamo dire non ce l'ha fatta."Write one, runs never" come? Esatto, "runs red screen".React Native, secondo me, poi lo porto come studio e utilizzo pratico, si è posto proprio diversamente a livello di struttura che era "learn once, write everywhere", cioè questo concetto di React, per chi si è approcciato a React, di componenti, di state, di props, di context, e tutto ciò che il mondo React ci riporta applicato al mondo nativo.E penso che una delle cose che poi quando faccio i corsi mi piace sottolineare di chi viene dall'imperativo è la parte dichiarativa di React, che è di una potenza secondo me inimmaginabile.Nello sviluppo mobile, cosa vuol dire? Vuol dire che il codice che scriviamo noi in JavaScript viene fatto un bundle, quindi viene fatto un unico file JavaScript e viene caricato a livello di file all'interno del nostro progetto e abbiamo una parte di librerie native del framework quindi sia iOS che Android che a runtime eseguono il codice JavaScript e segue il render dei componenti, il render dei componenti viene trasformato in una sorta di virtual DOM e viene passato al motore di render e gli dice "voglio la mia schermata fatta rettangolare così con un quadrato rosso al centro" queste istruzioni vengono prese dal framework di React Native e applicate a livello di UI da componenti nativi Quindi abbiamo una UI interamente nativa e della logica di sviluppo scritta con React, in questo caso come libreria.Ci tengo giusto a fare una nota a margine.Abbiamo parlato di Virtual DOM.Se volete approfondire l'argomento, ne abbiamo parlato forse nella puntata 2 o 3 del podcast quando parliamo di Svelte, quindi se volete approfondire un attimo l'argomento l'ha raccontato bene che cos'è il virtual DOM.Faccio una brevissima sintesi prendendomi anche la responsabilità di raccontarlo con la zappa come mio solito.React fondamentalmente non è strettamente legato al DOM del browser ma crea questo oggetto, chiamiamolo così, intermedio, questa rappresentazione intermedia.Questa rappresentazione intermedia può, da una parte, collegarsi alla struttura di renderizzazione del browser con la libreria ReactDOM che si occupa proprio di questo, ma questi oggetti che sono dei plain JavaScript object possono in qualche modo essere tradotti in qualunque altra cosa.Quindi la cosa figa di React è che tu stai definendo un qualcosa nella sua struttura con i suoi componenti e non nascondo che ho un amore spassionato per i componenti funzione di react che veramente hanno semplificato il life cycle a zero e vengono tradotti in qualunque altra cosa nel caso di react native vengono tradotti in istruzioni per andare a visualizzare, questo lo fa naturalmente la parte bassa del framework, quella parte scritta in c++ se non ricordo male, per andare a visualizzare i componenti nativi che nel caso di iOS saranno di un tipo, nel caso di Android saranno di un altro ma potrebbero essere potrebbero esserci dei componenti che noi andiamo a chiamare utilizzando la stessa API e poi il livello sottostante che si occupa di gestirli in un certo modo per Android e in un certo modo per iOS e questa cosa devo dire che è molto molto figa però ti voglio fare una domanda perché so che in realtà il mondo di React Native non è un lago di latte e miele, nel senso che quando tu provi a sviluppare in React Native, anche là tante schermate nere con le scritte rosse e rosse con le scritte nere ti appaiono, no? E alcuni casi sono queste problematiche che vengono proprio dal fatto che il il codice javascript, il famoso bundle di cui dicevi, va a girare su, nel caso di iOS, il runtime che Apple ha messo dentro i telefonini, dentro il sistema operativo.Nel caso di Android, una build che invece il framework fa.E il modo con cui si comportano questi due runtime, che sono oggettivamente diversi, un po' ci riporta indietro nella storia quando metterò un bip e i browser interpretavano javascript in modo cinofallico, ecco lo dico così.Quindi ti dico, sei mai incappato nel problema di avere qualcosa che funziona per iOS e non funziona per Android o viceversa? Torniamo al discorso di prima, anche di Safari, che tanto su iOS stiamo parlando di quello, il motore JavaScript che viene usato, che è questo JS Core di iOS, proprietario interno a Safari.E, nella parentesi, su Android adesso, hanno rilasciato da un qualche tempo Hermes come compilatore, come interprete JavaScript interno che si possono, si può attivare, che bypassa, diciamo, quello nativo.Nella mia esperienza non ho avuto problemi di questo tipo pesanti, pesanti intendo per crash o cose del genere su dispositivi, quanto invece più facilmente, una delle ultime mi ricordo, sulla gestione delle date del costruttore di New Date dentro Safari e questo ce lo abbiamo su web come ce l'abbiamo all'interno dell'interprete JavaScript che viene utilizzato dentro React Native il più dei problemi che possiamo evidenziare su React Native, io penso che React Native per noi parliamo di noi come full stack developer è un coltellino svizzero che ognuno dovrebbe avere nella propria tasca.Quello che dico sempre quando poi spiego questa tecnologia è che sto sviluppando un'applicazione nativa e ciò non mi preclude dal conoscere gli strumenti nativi, quindi è molto più facilmente la maggior parte degli errori che ci capitano come sviluppatori approcciando a questa tecnologia sono la build per iOS o la build per Android, capire cos'è...adesso c'è pod che è molto simile a npm prima non c'era quando è uscita la tecnologia parliamo comunque una tecnologia molto giovane è un progetto che nasce come hackathon nel 2013 e viene presentato a gennaio 2015 sulla versione us come beta come alfa ad oggi non c'è ancora una versione 1.0 quindi comunque sta evolvendo e si sta migliorando l'ecosistema quella che viene chiamata oggi la developer experience ci sono una serie di progetti paralleli che ci aiutano in questo però se io dovessi prendere a Knative così com'è a parte il sviluppo del componente della mia interfaccia ho comunque tutta la fase di build, di configurazione ad oggi anche gli store sono più restrittivi quindi devo configurare tutti i vari metadata per quello che faccio ed è è una cosa che faccio nativamente, quindi quello che ho è sì la mia applicazione è bellissima, funziona benissimo, adesso apro Xcode, apro Android Studio, configuro quello che mi serve e certe cose, come è successo a noi, abbiamo imparate sul campo, perché noi non veniamo dallo sviluppo nativo, non l'abbiamo in casa, non è il nostro, quindi veramente sono concetti che ci siamo visti un po' sul campo per quello che ci serviva.Anche la parte di debugging dentro, c'è una parte React, JavaScript, tutti gli strumenti, perché poi il bello del JavaScript è quello di utilizzare gli strumenti che già conosciamo.Nella puntata di Luciano con Node e JavaScript, lo stesso linguaggio da parte l'altra, stesso discorso, lo porto su mobile, mi porta un sacco di knowledge, di know-how su come fare determinate cose.Però arriva un punto e magari la RAM del dispositivo non è la gestione della RAM del browser.La user experience dentro un dispositivo mobile non è quella che è abituato un utente nel browser, sia da un pulsante alla navigazione a tante altre piccole cose.Quindi sì è una tecnologia che facilita, no non è così zero effort per chi viene dal web, perché il vantaggio di avere la UI nativa ci porta comunque a dover approcciare a molto più nativo di quanto facevamo con Cordova, che pure NPM era un build ma con n problemi annessi che poi non non sono nostri da sviluppatori web abituali.Beh in realtà si si rompe, si va quasi a uscire da quella sandbox web, quando si parla di sviluppo mobile, si parla di cordoba ionic, noi abbiamo lo sviluppo all'interno di una cassettina di sabbia con i confini ben delimitati, stiamo agendo in ambiente web al massimo, abbiamo dei binding che sono sempre meno utilizzati, basta guardare capacitor, sono sempre meno utilizzate perché le web api sono sempre più prestanti quindi questa sandbox diventa sempre più solida e sempre più chiusa per cui da sviluppatori web ci viene comodo.Quando poi, e parlo della mia esperienza, approcci per la prima volta su React Native dici "ah, forse qua devo capire un po' dove sta andando a girare il mio codice, devo capire il contesto".spesso quando poi ti trovi come dicevo prima e come tu mi confermi davanti a situazioni dove che ne so usi un tool local string e vedi che su ios funziona su android non funziona ma android se run il debugger allora funziona e se non capisci cosa succede quando avvii chrome developer tools per andare a ispezionare quello che accade nella tua app tu dici no ma Questa è pazzia.Molla tutto, si escapi a gambe all'aria o approcci ad altre soluzioni più semplificate che andremo a vedere tra un po'.Però mi chiedo, tutta questa roba crea una curva d'apprendimento molto ripida che in qualche modo può anche aver penalizzato l'adozione di React Native? No, sono fautore delle bold opinion di questo.No, perché innanzitutto non ha penalizzato, e dico questo perché nel 2015 è uscita la demo, e anche la demo, scusate, la 2015, sì, è uscita la presentazione nella React.js Conf, dove facevano vedere un modello 3D che girava scritto in React Native, con una select scritta in React Native e a marzo 2015, mi ricordo che dentro un talk del CodeMotion mi arriva la mail, viene pubblicato il progetto iOS per open source su GitHub e nel 2018 è il secondo progetto su GitHub per numero di contributors, non di stelline.Quindi non mi sento di dire che la con la l'adozione sia stata penalizzata.Sono dell'idea che, come giustamente dice Mauro, non è una tecnologia per portare un pezzo di applicazione web per uno sviluppatore web per dire faccio l'applicazione co zero effort.e la curva d'apprendimento non la trovo tanto più ripida di chi si approccia a uno sviluppo mobile da zero.Cioè è una tecnologia per sviluppare, a mio avviso, applicazioni mobile come alternativa possibile o affiancamento.Poi vediamo magari come ha sviluppo in nativi, in Swift, Objective C, Java, Kotlin, quello che sia.Sì, quello che volevo dirti è proprio quello, cioè quando tu approcci allo sviluppo mobile l'effort che metti è superiore da questo punto di vista rispetto a quello che utilizzi generalmente, mediamente.Lo so che sto facendo di tutto un erbo in fascio e me ne scuserete, però generalmente rispetto a quello che ci metti per girare su web.Perché? Perché non puoi far finta di non vedere i vincoli del sistema operativo che su mobile sono più stringenti.Immaginiamo la gestione della memoria cioè noi la memoria la trattiamo a calci quando sviluppiamo su web.sono pochissimi quelli di noi che guardano i Chrome Developer Tools per vedere quanta memoria stiamo allocando nella nostra pagina web penso di averlo fatto due volte in vita mia e quando le pagine laggavano e non andavano anche a calci forse è per quello, ma altrimenti non li guardi quando stai sviluppando generalmente invece nell'ambito mobile la complessità a cui approcci non è più alta ma diciamo che stai abbracciando anche altri livelli.Andrea volevi dire qualcosa? Sì, una curiosità che prima parlavi appunto della curva di apprendimento che uno si avvicina diciamo allo sviluppo con React Native oppure sul linguaggio nativo di iOS o Android del caso, però ipotizzo che, visto che non c'è questa stable, ma probabilmente non c'è perché non c'è nemmeno il modo per attaccarsi, non c'è il bridge per ogni singolo componente che sta all'interno delle nostre applicazioni nativi, ipotizzo, e quindi la mia curiosità era se ti era mai capitato di realizzare un tuo componente custom che facesse da bridge con qualcosa che la community ancora non ti avessi messo a disposizione e in quel caso, se ti è capitato, se hai delle buone pratiche da consigliare per fare tutto questo e risolvere questo problema.LM: Allora, mi è successo, noi abbiamo in azienda, abbiamo fatto questo passaggio, vi raccontavo prima, da Cordova a Titanium, ci siamo scottati esattamente, era un periodo dove facevamo un sacco di applicazioni interne per aziende, per eventi aziendali, quindi anche iPad, situazione controllata, distribuzione aziendale per fare quelle cose.E ci siamo scottati con Titanium.Quando è uscito React Native, era piaciuto, ho fatto un paio di scursi sul lato web invece, Angular, fino a provare React, innamorati di React e tutti quanti, esce React Native e ho detto "vabbè, proviamolo, tanto peggio di così non possiamo fare e proviamolo effettivamente così e all'epoca quando è uscito hanno rilasciato un tot di componenti per chi ci ascolta da casa per fissare bene il concetto è che quando io scrivo un componente dico qui ci voglio una view quindi un come un div in html metto una view ci deve essere la controparte nativa scritta in java quando è buildata su android o scritta in Objective-C o Swift, quello che sia, su iOS, che mi dice "in questo spazio mettimi una UI view su Swift, una view, non mi ricordo come si chiama, su Android e così via".Quindi c'è questa controparte che deve essere compilata all'interno dell'applicazione.E quando è uscito non c'erano ovviamente tante componenti, altre sono state aggiunte e ad oggi le stanno levando dal core per fare i pacchetti esterni, quindi comunque quando dico numero di contributi, comunque i pacchetti ad oggi soddisfano un grandissimo numero di moduli, sia di API che di view, di interfacce e mi capitò questa cosa di dover fare per una grande azienda un player video in full screen, quindi non solo il video ma dover mandare in full screen questo video e non c'era sostanzialmente il modulo come siamo abituati magari ad oggi, ah c'è React Native video, scarico questo, fa quasi tutto quello che mi serve...non c'era, però avevo la necessità di usare il player nativo di iOS e questa è una cosa che racconto con molto piacere, in una giornata di Objective-C mai visto in vita mia, con un po' di documentazione che stava lì, e Objective-C penso sia meno comprensibile dell'ISP, io sia riuscito a costruire quelle quattro API, roce, che servivano io ho il mio controller copiato, mezzo incollato, eccetera, per mandare quell'API nativa, cioè chiamare dal Javastip quell'API che nativamente mi avrebbe aperto il mio player video con il parametro del video da aprire.Quindi io nel giro di una giornata, potevano essere due se fossi stato più stanco col momento, o mezza se avessi conosciuto l'Objective, sì, sono riuscito comunque a implementarlo.E questo è, mi attacco anche per tornare un attimo al discorso di prima, la tecnologia è fatta, secondo me, principalmente, la vedo molto a supporto degli sviluppatori mobile, perché avendo questi bridge nativi e questo guscio nativo, ho conosciuto tante persone che hanno sviluppato nativamente buona parte dell'API e esposte sul JavaScript, quindi usato React Native solo per un discorso di dichiarazione dell'interfaccia e tutta la potenzialità del dichiarativo, oppure, viceversa, persone che hanno fatto applicazioni interamente React Native e quando avevano quel famoso modello 3D, che non troveremo mai un componente che fa quello che ci serve, o dei grafici molto complessi, nella documentazione è molto facile per chi sviluppa nativo, ritorniamo al discorso che c'è un minimo di competenza ci dovesse, Legge la documentazione e dire "ok, mi implemento la mia view nativa, che scrivo io in Java o in Objective-C perché sono capace, ho la mia libreria nativa, e dispongo delle pre-i da componenti semplicissime che utilizzerà magari il mio collega mentre costruisce la view".Quindi farò un componente graph con tre parametri, il mio collega li invoca, gli mette la withDate da React Native e sotto poi in realtà verrà visualizzata la view nativa.quindi c'è questa commissione tra sviluppo in-grid e sviluppo mobile.Hai detto una cosa molto intelligente, che è quella di dire che sviluppare in React Native non è portare lo sviluppo web, è sviluppare in nativo con lo state of mind dello sviluppare in react anche perché react ha portato a innovato il modo di sviluppare no? da quel punto di vista e devo dire che sia il mondo ios che il mondo android hanno degli approcci ben più prolissi ben più complessi e quindi mi chiedo Se ci fosse un approccio alla React per le due platform, avrebbe ancora senso React Native? Una cosa che non si ha detto in questo podcast e in questa puntata è il "dipende".[Musica] So che è un'altra parola fondamentale.In questo episodio perlomeno ancora non era stata fatta.Mi sembra il caso di utilizzarlo.E sì, Sonore Act ha influenzato tante cose, lo vediamo da ovunque nel web e lo vediamo nel...anche in Swift UI, che per quanto possa è stato influenzato dal modo dichiarativo di scrivere l'interfaccia di React.Quindi domani mi aspetto anche un Kotlin UI, giusto per spararne uno, che implementa un paradigma del genere.Il discorso è la semplificazione con cui io scrivo interfacce in react native e me le porto in due ambienti differenti con la possibilità di personalizzare poi singolarmente l'ambiente, riduce comunque la codebase e il team di sviluppo.Cioè quello con cui è portato facebook, uno dei primi articoli era facebook ads manager l'applicazione avevano l'85% di codice condiviso tra iOS e Android e non penso che Facebook abbia problemi ad avere due team specifici di una tecnologia o nell'altra, ma questo ha portato ad avere delle funzionalità comuni e come ci insegniamo tutti quanti meno bug perché c'era meno codice.Quindi il risultato è dipende anche dal tipo di applicazione.React Native è perfetta, mi avviso, per fare dei crude e sappiamo che facciamo tanti crude.È utile per fare Facebook in sé? Perché Facebook non la utilizza? Facebook nell'applicazione sua nativa la utilizza in parte, come dicevo prima, può essere embeddata in una parte e i gruppi di Facebook, se non ricordo male, e alcune altre sezioni sono state portate in React Native dal team interno, mentre tutto il resto dell'applicazione viene curato dal team Android, del team iOS.Quindi sì, l'approccio è giusto che viaggi e che venga portato poi in altre tecnologie, è l'evoluzione dell'informatica, perché anche i paradigmi di javascript che abbiamo adesso non è che si sono inventati da nulla, però è quel caso d'uso specifico del multiplattaforma non demonizzato come "lo scrivo una volta e deve funzionare per tutto e mi tengo la stessa cosa", ma un multiplattaforma inteso come una buona parte di codebase condivisa e poi, in maniera anche molto particolare, la specificità dell'interfaccia o delle cose sui pari piattaformi.Io infatti mi volevo unire proprio su questo discorso, che è una domanda non proprio legata per forza a React Native, ma a tutte le tecnologie che permettono di unificare, diciamo, lo sviluppo di un software e poi deploiarlo su differenti di piattaforme mobile.Il fatto è che l'interfaccia utente, l'interazione, la user experience di iOS e Android sono molto diverse tra loro.Per cui, mi leggo proprio all'ultima frase che hai detto, uno non deve dire "ok, facciamo la stessa esperienza per tutti", perché in Android hai i tasti, per esempio, i tasti in basso che possono fare delle azioni, invece su iOS l'interazione è in alto.Quindi a quel punto uno deve dividere lo sviluppo, dico ok se siamo su Android renderizza questo, se siamo su iOS renderizza quest'altro.Alla fine questo si deve fare per...cioè bisogna anche rispettare l'utente che si aspetta un certo tipo di UI.Aggiungo una cosa, ci sono dei controlli in tal senso, immagino da parte di Apple, nel senso di fornire un'esperienza a un utente, non lo so, metti la navigazione in basso, loro ti dicono no, deve stare in alto, oppure...Quindi questo è un po' un mix di domande.Non sono uno sviluppatore iOS accanito, quindi tutte le linee guida, parlo della mia esperienza, diciamo, di applicazioni portate in produzione, non è mai successo.Abbiamo fatto applicazioni che sono uguali sia per Android che per iOS, per una serie di motivi, che sia dal cliente che sia dall'UI, n motivi che non ci interessano in questo momento e non hanno mai avuto questo problema.Il principale problema che abbiamo avuto per esempio su iOS era un tasto regista che ti portava al sito e non poteva essere così.Quindi hanno molto più un'attenzione all'utente che non abbandona piuttosto che all'interfaccia.All'utente che abbandona, diciamo alla fuga dalla loro piattaforma.Esatto, a mantenere l'utente...Da un punto di vista di interfaccia No, non c'è stato.Lato Apple non ci sono state problematiche.Lato utente ci sono, e ne dipende anche qui, ci può essere l'interfaccia uguale per vari motivi, sia di budget che di MVP, sia di qualsiasi altra cosa.Sì, ha la necessità di avere due interfacce differenti.Il discorso di due interfacce differenti, ad esempio, non, a meno della mia esperienza, ho un Android da sempre, non conosco io, non ho evidenze di applicazioni Apple, però l'applicazione Facebook mi aspetto che il post sia abbastanza simile come cosa.Poi cambia la navigazione, siamo d'accordo.Rekner intensivamente ha un sistema basato su Webpack, sul suo bundler, molto comodo, per cui tu puoi dichiarare un componente button.android.ios e quando va a a fare il bundle per iOS, andrà a prendersi quella versione.E questo ti porta a poter fare un pulsante dedicato a Android, un pulsante dedicato a iOS, solo da un punto di vista di stile, ma a livello di funzionalità, quella schermata che ti farà vedere quelle informazioni e farà quella chiamata API è comune.E tu, la tua applicazione, vai a importarti un comune button e lui internamente andrà a importare il file corretto per la piattaforma che ti interessa.Quindi anche lì ti dà un controllo abbastanza granulare, quindi se vuoi fare un'interfaccia dedicata ai diversi piattaforme ti dà la possibilità di farlo e questo può anche riportarsi sul navigator, quindi fare un navigator Android e navigator iOS e caricare il bundle che mette sopra la navigazione o la mette con i tasti in basso.Devo rubare qualche istante per ringraziare i due amici che ci hanno offerto le birre in questo episodio.I amici sono Savezzo che ci ha offerto 3 birre e Federico Dainelli che ci ha offerto 3 birre.Vi ricordo che grazie a queste donazioni che Gitbar si sostiene e devo dire che tra un partirà una campagna di finanziamento per acquistare i microfoni agli ammuttinati, in modo che anche la qualità audio del nostro podcast complessiva possa guadagnarci.Detto questo io ringrazio Savezzo, ringrazio Federico e prendiamo alla loro salute.Cin cin! Io devo farmi ambasciatore di una domanda che Carmine ci ha lasciato, perché non è potuto essere qui, noi comunque lo salutiamo e lui ci chiede se utilizzi TypeScript con React Native e se sì, se ci sono dei pain points, se lo consigli o se lo sconsigli? Non esistono non pain points in typescript, in qualsiasi linguaggio, qualsiasi cosa front-end, a mio avviso.Bona opinione! Abbiamo il gingolo per questa roba, grande! Almeno nella mia esperienza, nella community, sono stato un portabandiera del JavaScript puro per la semplificazione, per la spontaneità nella scrittura e tutta una serie di cose.La mia community, se lo sa, ad oggi creiamo molti progetti in TypeScript.L'attivizzazione, soprattutto nell'ottica del team, la trovo molto utile.Nell'ottica di React Native, in generale con React funziona abbastanza bene tutto quanto, ormai è molto consolidato.Nell'ambito di React Native, come nell'ambito web, dipende poi da molti moduli che vai a installare.Diciamo la community se per sé ormai, leggevo l'estatissimo, il 60% dei pacchetti su npm supportano TypeScript e cose del genere, quindi è molto avanti con la struttura.Però sai, mentre nel core di React Native ci sono una serie di componenti, vai a prenderti magari quella libri o quelle piai non tipizzate e hai il solito point di turno del sapere cosa ti ritorna esattamente e dovertelo rimanere.Detto ciò, sia a livello di stile che quant'altro è abbastanza ad oggi supportato tranquillamente.Visto che abbiamo aperto la parentesi carbine, ha lasciato anche un'altra domandina interessante riguardo un po' al riutilizzo se eventualmente possibile farne e se siccome riguarda le API, librerie di tipo di user interface, quindi ipotizzo il cliente che ti chiede questo tipo di interfaccia sia nell'applicazione web device con un viewport bassissimo anche diciamo nell'applicazione nativa tipo la tipografia, lo storybook di turno, il design system, cioè riesci a condividere questi strumenti tra le due implementazioni? se sì cosa? non so.questa è un'ottima domanda che di un argomento non è ancora uscito che ci tengo tantissimo è il scrivo in react native su mobile perché non esco pure su web questa è una dei topic su react native la mia sembra un po ricorrente la cosa è un'altra bold opinion che si scontra un po anche con parte della community nella mia esperienza la nostra esperienza di team sviluppare un'applicazione mobile non è sviluppare un'applicazione web sia sia da un punto di vista di tecnologia sia da un punto di vista di esperienza utente non c'è il CSS, banalmente, non ci sono i media query, che devi fare diversamente, è uno sviluppo con altri paradigmi.Ci sono delle soluzioni per portarsi parte dei componenti e fare dei wrapper per componenti, ad esempio la view di prima, portarla in div sul web.Esistono, sono abbastanza stabili per determinate cose nelle demo vengono fatte funzionare tranquillamente.Ci sono delle API native che ovviamente non abbiamo sul dispositivo web e viceversa, quindi ci sono una serie di cose che dobbiamo valutare se vogliamo fare un approccio di tipo scrivo l'applicazione in nativo, React Native, per esportarla anche su web.Lato strumenti invece la connessione è abbastanza ampia, nel senso che tutto ciò che non riguarda il DOM e quindi l'API estrettamente del browser possono essere utilizzate dentro React Native.Lo stesso Storybook ha deciso di fare una sua versione per React Native e il costo di farlo è stato abbastanza semplice, perché poi è view renderizzata sull'applicazione.Tutto ciò che riguarda il testing dei componenti o librerie di API o ancora timers e tutto tutto diciamo l'ecosistema JavaScript me lo riporto tranquillamente abbiamo dei progetti dove abbiamo la stessa diciamo file per semplificare con tutte le chiamate API e tutti i metodi con Axios come libreria ed è lo stesso e manteniamo mappato gli stessi tipi tra l'applicazione web e l'applicazione nativa A livello di UI si può fare, ma non so quanto poi sia consigliato, in senso che comunque la tipografia...non ho il CSS, ho un altro modo di scriverlo e quindi mi porta delle differenze.Soprattutto non c'è il CSS nel senso del cascading, è molto dello stile in un sito, è fatto anche dall'eriterietà degli stili, del parent su mobile, questa cosa non c'è.Quindi una cosa che si vede bene su web non si potrebbe vedere bene su mobile e viceversa.Sì, beh, sono due ecosistemi anche diversi.React, diciamo, che diventa la lingua franca per comunicare, ma i significati e i contesti sono differenti.Noi all'inizio forse abbiamo spaventato parlando di complessità di React Native, però se siete arrivati fino a questo punto possiamo anche dirvelo esiste un modo per iniziare ad approcciare con questo mondo che se non è in dolore poco ci manca nel senso che è molto molto semplificato una rete di salvataggio per tutte le o buona parte delle schermatte rosse che comunque continuerete a vedere, ma che si chiama Expo.Io l'ho utilizzato, ci ho mandato in produzione anche dei progetti, ma mi piacerebbe che ne parlassi tu di Expo.Come si pone e che cos'è questo player, perché è un player, nell'ecosistema React Native? Expo è una di quelle che adesso sono diventate delle aziende basate sull'open source e sul concetto di React Native insieme ad altri come Infinity Red e sono stati un po' dei player come singoli giocatori, dei contributors vari di React Native come framework nella sua evoluzione.Per parlare di Expo faccio un piccola premessa per focalizzare bene il concetto del noi abbiamo questo file javascript con dentro tutte le istruzioni della nostra applicazione React che viene interpretato sulla nostra applicazione al runtime e questo è quello che esce da questo file, da questa interpretazione e viene bandato al bridge nativo che compila le interfacce.Se voi avete in mente questa suddivisione vi viene abbastanza facile pensare che se noi leviamo dall'applicazione build data nativamente, quindi con solo i libri iOS girando su iOS, leviamo il file javastick che c'è, ne mettiamo un altro a runtime, abbiamo una nuova applicazione che deciderà come visualizzare e cosa visualizzare all'utente l'interfaccia.Ecco, Expo si pone di base come un'applicazione, come un ecosistema, poi entriamo nei dettagli, ma per iniziare facilmente è un'applicazione con tutte le librerie native già buildate dentro, tutta una serie di librerie che loro supportano, già buildate dentro, dove noi ci occupiamo di scrivere soltanto la parte di JavaScript dei nostri componenti, delle nostre schermate.Queste vengono, in italiano è sempre orribile, bandelerizzate, compresse, non so, comunque viene fatto un unico file, viene caricato su questa applicazione a runtime e noi ci vediamo già l'applicazione attiva sul contesto nativo tramite questo Expo Go, che è la loro applicazione.In più, in generale, Expo è un framework, diciamo, è un set di strumenti per lo sviluppo di React Native che si occupa di permettere agli sviluppatori di sviluppare un'applicazione mobile in React Native senza avere tutta la parte di compilazione nativa, senza Xcode, senza altre cose.Quindi abbiamo l'applicazione mobile di Expo Go per, diciamo, assorbire il JavaScript che noi scriviamo e all'interno offre tutta una serie di librerie che parte sono prese dalla community e rimappate, già testate, già stabili, si pone come player di garanzia su queste librerie, che coprono la maggior parte dei casi di uso, dalla camera bluetooth di base a tante altre cose che possiamo utilizzare.È ancora più facile per iniziare senza avere Expo e l'ambiente web di React Native, diciamo, JavaScript si installa con npm, si fa npm start, si inquadra con il telefono e stiamo scrivendo la nostra applicazione, ma ancora più facile vi consiglio snack.expo.io dove è un piccolo editor online che fa...dove voi scrivete il vostro componente, tramite il qr code potete già legge e vedere l'applicazione attiva sul dispositivo senza dover avere neanche npm sul computer.- che metteremo nelle note dell'episodio ovviamente.- assolutamente, lasciamo tutti i riferimenti.Quindi questi sono i pro, quindi abbiamo una gestione completa dell'applicazione da punto di vista di questo Expo come ecosistema e da relativamente poco, con qualche paio di anni, ormai hanno un sistema di build integrato direttamente online dove io posso veramente non aver cognizione o quasi del mio ecosistema nativo, preparo la mia applicazione, la mando tramite il loro cloud a fare la build con i loro sistemi, gli do i miei accessi col mio chi c'è in Apple perché la possono firmare totalmente gratuita, in maniera totalmente open, e fatto il previo studio di build mi ritornano con l'IPA per iOS o la pick up per Android pronti per essere caricati sugli store.Pro e contro ovviamente di questa cosa è che da una parte abbiamo un sistema in cloud loro, quindi dipende dalle applicazioni che abbiamo.Non è detto che possiamo pushare il nostro codice javascript con tutti i nostri secrets verso un endpoint a caso per policy.Avendo la build nativa presso di loro non possiamo installare componenti o librerie puramente nostre, abbiamo un po' di difficoltà ad aggiungere quel modulo nativo scritto da noi, perché loro hanno quella shell nativa, pronta, testata e sanno che funziona, e noi sostanzialmente ci carica soltanto la parte javascript nostra e la parte di asset ovviamente.E a mio avviso alla lunga crea un...come tutte tante cose...un lock-in sulla piattaforma, perché vai ad utilizzare una serie di cose loro che funzionano, ma nel momento in cui hai la necessità di staccarti potrebbe non essere così facile.Devo però dire, scusa Matteo per complettezza, che il sistema di build che utilizza Expo è open, si chiama Turtle e noi possiamo installarlo all'interno della nostra macchina per agire, questo l'ho scoperto da poco perché stavo lavorando su un progetto di end-to-end testing di applicazioni expo quindi fondamentalmente se expo fa è un po lo ionic del react native ti dà la possibilità di sviluppare facile perché ci hanno già dei binding dei componenti loro ti dà la possibilità di buildare online togliendoti tutti i mal di testa e questa cosa devo dire che è molto figa noi ci abbiamo rilasciato diverse applicazioni così in tempo zero con una knowledge veramente minima quando però superi il limite diciamo che c'è la possibilità di buildare a casa loro però poi magari ti scontri con quello che dicevi tu devo mettere l'api caso personale di mapbox quelle con web gl e con con le gl e non posso metterle però da quello che leggevo non vorrei dire una bugia ma Expo rilascerà per i clienti enterprise un nuovo build system non so se l'ha già fatto che permette anche di utilizzare delle terze librerie non so come funzionerà ma so che si sta a prenda a quel mondo hai qualche info in più? Non in particolare sul sistema di build posso dire che è anche colgo l'occasione di ringraziare Expo perché è una di quelle aziende che nell'ecosistema React Native ha dato un contributo veramente enorme nel standardizzare i moduli che si possono installare.D'Expo, Unimodule, lascio poi semplicemente la buzzword, la potete cercare, ha dato una forte struttura come creare i moduli per poter essere utilizzati facilmente, avere una struttura comune per poter poi arrivare a una cosa in cui posso posso tranquillamente usare un modulo di terze parti sulla mia libreria senza spaccare tutto perché c'è il problema anche quando prendo la libreria nativa mentre noi siamo sviluppatoi JavaScript, sappiamo che a runtime esplode tutto una libreria nativa che deve essere compilata se non passa la fase di build e soprattutto se la build è in cloud posso litigarci per ore sul discorso dell'avere la Tartle in on-premise come progetto open source e loro lo fanno tutto open source È un po' un controsenso sull'usare Expo perché se ho le competenze per tirarmi su tutto il mio sistema di build locale di Turtle probabilmente sono andato su una build nativa e ho fatto prima.Quindi in realtà è giusto per evitare il lock-in finale però ecco io metto le mani avanti su questo.In realtà sì.Devo dire dal mio canto che Turtle è molto comodo se stai sviluppando su Expo e vuoi fare qualcosa con una CI.No, certo.Credimi, è veramente comodo.Dall'altro canto però ci tengo a ricordare che noi possiamo tranquillamente sviluppare un'applicazione React Native usando Expo che ci dà anche una certa semplicità, una certa tranquillità, se non dobbiamo fare grandi cose possiamo farle e poi arrivato a un certo punto quando abbiamo un'esigenza che va oltre il nostro MVP o la nostra Proof of Concept fare un bel Expo Eject, quindi non sto facendo altro che un po' come faccio con React sto togliendo le cinture di sicurezza e mi sto buttando di petto nel mondo della complessità però quella roba funziona e posso inserirci qualunque altra libreria.So che c'hai un ma? No no no aggiungo soltanto una cosa per chi ci ascolta poi come appunto nel momento molte librerie di Expo che fanno sicuramente sono battle tested con delle API consistenti ma molte librerie e anche specificando la documentazione prendono spunto da librerie esistenti.A me è capitato di fare un eject e se usate la Expo Camera in realtà è un wrapper fatto benissimo, non ce l'ho da togliere, su React Native Camera.Quindi anche nel momento in cui vi trovate a fare un eject non previsto e avete un tot di librerie, valutate le singole librerie perché probabilmente con il riadattamento delle props o delle cose riuscite comunque ad utilizzare quelle che poi sottoutilizza Expo.Il tempo sta volando quindi io direi che facciamo le ultime due domande che però potrebbero aprire delle voragini quindi lascio a te il senso della misura.La prima domanda è Flatter.La prima domanda è Flat, non è...Stai caricando, no.Lei provato, se l'hai provato, cosa ti è piaciuto e cosa non ti è piaciuto, se invece hai deciso di continuare a sviluppare React Native, cosa ti ha spinto a continuare a percorrere questa strada nonostante l'affascinante mondo di Flattor e delle sue tante stelline, più di quelle che ha React Native? volevo provocarti, penso di esserci riuscito.No, non sono un fanboy delle stelline, ricordo sempre il progetto di Apache che ne ha meno di tutte, quando è così.No, non l'ho provato, c'è tanto hype intorno, ho fatto giusto poche cose, non produzione, quindi cerco di avere del...le mie bold opinion sono sulla mia esperienza diretta, quindi su questo discorso pochi paragoni, quello che ci tiene tuttora su React Native è il suo payoff.Learn once, write everywhere.Cioè noi utilizziamo attivamente React sul frontend, abbiamo una verticalità di competenze su React notevole e tutto ciò che impariamo sull'utilizzo del frontend, e non tanto da un punto di vista di UI, ma da un punto di vista di gestione degli stati, globale, API, tutto, lo riportiamo come competenza su React Native.Quindi ad oggi il framework fortunatamente ha un'adozione incredibile, ci sono veramente aziende enormi dietro che contribuiscono, alcune se ne sono andate, altre sono rimaste, newsletter di 20 minuti fa, che non so quando ci ascolteranno, ma qualche giorno prima, Coinbase ha postato tutto in React Native, quindi è un'adozione comunque costante, è un framework, è una tecnologia che non ci sta abbandonando dopo cinque anni, e non so quant'è il commitment di Facebook ad oggi, che comunque la usa internamente come React, ma anche l'ecosistema intorno è tanto solido da unire le due cose.L'ecosistema solido, competenze che riutilizzo e quindi ad oggi noi abbiamo deciso di continuare a puntare su React Net.Volevo farti...Ah, Andrea volevi...Hai parlato appunto di, diciamo, aziende che sposano in maniera molto forte, diciamo, questo framework.Hai citato parallelamente qualcuna che se n'è andata, tipo ad esempio Airbnb, Shopify...Ti sei fatto un'idea del perché loro hanno preso un'altra strada? Non mi sono fatto un'idea.La cosa bella dell'ecosistema è che su questa cosa non c'è un'idea.Ci sono quattro articoli enormi di Airbnb dove descrivono il motivo, quindi rispondo provocatoriamente, non c'è bisogno di farci un'idea, basta leggerlo e e sicuramente, come tutte le tecnologie, c'è gente che le abdotta, c'è gente che le ama e gente che le odia.Nel caso di Airbnb stiamo parlando comunque di uno scisma del 2018, metà 2018.Vi ricordo che ottobre 2015 è uscita la prima versione per Android, quindi le prime cose.Nel giro di due anni e mezzo hanno puntato tanto su Airbnb, sia sul React, conosciamo tante librerie loro, sia su React Native, si sono accorti che per il loro modo di sviluppare, per il loro team, per le performance, n motivi, il loro caso d'uso, il debito tecnico accumulato rispetto agli aggiornamenti, perché stiamo parlando sempre di una tecnologia che ad oggi è la 0.60, non è la 1, quindi ci sta, fare l'upgrade di React Native all'epoca, specialmente da una versione all'altra, era veramente un bagno di sangue.Ad oggi è più stabile, fanno due release l'anno quasi, perché ormai è quasi stovere, stiamo aspettando la 1 per festeggiare, però comunque è molto cambiato e per loro era diventato più un costo di mantenimento dell'upgrade che la velocità con cui implementavano le cose quindi all'epoca hanno deciso di spostare.Parallelamente Facebook continua ad utilizzarle e continuano ad uscire, ma possiamo non rimanere senza diungare.Tesla, Wix fa tantissime cose, Skype ci ha dedicato tutto, Microsoft su React Native sta investendo un sacco su React Native, Windows e Mac OS, capiamoci, e Microsoft su come utilizzare quella Vue che usa, adesso utilizzo su Android come view e su iOS come UI view, su Windows come, non so come si chiami, nel linguaggio, nel suo UI kit, per fare la view nativa, quindi avere anche lo stesso tipo di paradigma applicato alle applicazioni desktop.Chi se ne è andato sono casi d'uso e esperienze dell'epoca che sicuramente non sono quelle di oggi.No, tra l'altro leggendo anche il set di articoli rilasciati da Airbnb io tutta questa aggressività verso React Native non la vedo tanto che dai sondaggi fatti negli stessi ingegneri risulta che React Native è comunque un approccio, un ecosistema vincente nonostante lo switch.Quello che loro evidenziano è il fatto che per loro dover tenere una terza knowledge, quindi oltre che a conoscere l'ecosistema android con kotlin o java del caso, l'ecosistema ios con swift, a quel punto è necessario conoscere anche react native con javascript.Ma questo perché? Perché le esigenze specifiche ti portano a scendere molto vicino alla piattaforma, a quel punto è naturale che fai questo tipo di scelta cioè fondamentalmente prima ho detto casi d'uso proprio per questo.Volevo farti l'ultima domanda che un po' mi viene da un'esperienza personale il testing che per quanto riguarda lo unit testing siamo in ambiente javascript per cui la risposta è abbastanza banale però sono curioso di sapere se esiste un modo per fare snapshot testing quindi per gesti utilizzare le snapshot dei vari componenti che ti vai a fare non so se ci hai mai provato io non non ho mai provato però è una cosa che mi viene in mente e poi se hai dovuto mai fare end to end testing e cosa utilizzi? mai dovuto? sì ci ho abbiamo provato e allora in ordine unit testing sono componenti React, 99% classico, suggerisco tutti i React Testing Library, su native c'ha i suoi binding, c'è una configurazione veramente minima e funziona sulla parte di TestRunner, siamo in casa Facebook, Jest, Jest Native e Jest Expo sono tutti dei preconf, delle configurazioni, dei preset, ecco facili da installare, tre righe di add e zero conf e partono per quanto riguarda snapshot testing inteso come output del componente come snapshot stiamo ancora nell'ecosistema React, non abbiamo alcuna differenza di sorta abbiamo una serie di sempre preset di mock da usare in eventuali API native ma anche il sistema di stile, di cui non abbiamo parlato, ma simile al CSS dal punto di vista di struttura, anche se va cascading come dicevamo prima, ci viene esportato come proprietà dell'oggetto, quindi noi possiamo prendere il nostro componente e fare lo snapshot tramite gest tranquillamente, con il classico to match snapshot, perché tramite il React test rendering, col testing library, quello che utilizziamo ci esce questo, ritorniamo, questo simil virtual DOM, quindi questo oggetto con dei dati che poi verranno passati al bridge nativo.Quindi faccio lo snapshot di quello e posso tranquillamente poi riparagonarlo dopo, compreso lo stile che viene applicato sui singoli componenti.In finale, end to end, penso sia a croce di dirizio di tutti gli sviluppatori mobile.Chi viene alla web è abituato, noi abbiamo questo grande vantaggio del browser, Ad oggi, con tante tecnologie dietro, da Puppeteer, lo stesso, come si chiama, Selenium, abbiamo mille modi di manipolare il browser.Sulla applicazione nativa è tutta un'altra storia.Con Expo è ancora un po' più complicato perché è un'applicazione separata, di cui non abbiamo controllo nativo.Sulla parte di sviluppo nativo in sé utilizziamo principalmente tutti gli strumenti che già ci sono sull'applicazione mobile, per questo torniamo a una curva di appendimento che non si limita solo all'ecosistema JavaScript, ma usa il JavaScript come semplificazione dell'ecosistema mobile, quindi il vario Appium di turno che mi viene in mente che ispeziona le varie view e le cose.Detox è un progetto Wix per l'end-to-end testing in React native che si collega al packager nativo e ricarica l'applicazione, fa una serie di asserzioni, di click direttamente, uno smoke test completo.L'abbiamo configurato su iOS con grande difficoltà, però l'abbiamo fatto girare, comodo anche per fare gli screenshot.Farlo girare su Android un po' più di difficoltà, farlo girare su Expo credo sia ad oggi possibile.Impossibile, ho provato per le nuove prima si poteva prima c'è stato un periodo c'è un detto un expo detox di helper ma con gli ultimi aggiornamenti e l'ecosistema di expo come si è voluto attualmente non c'è una soluzione per fare un quadro esatto infatti l'unico modo è quello di utilizzare a più però non abbiamo una semplificazione quindi dobbiamo chiamarci le robe le chiamate a più a mani in manella penso scrivere dei test così forse è un lavoro a parte rispetto a quello che facciamo su web.È un'altra competenza che specifica mobile come ad esempio chiudiamo sulla tutta la parte di di siai su di esempio molto famose su fastlane per la parte di iOS che viene utilizzato per fare siai su iOS per le bilder gli screenshot dell'app e tutta una serie di cose è compatibile con React Native, cioè con la documentazione ufficiale, ma semplicemente perché è una build nativa di iOS quindi utilizza tutti gli strumenti nativi del caso.Ma te li devi studiare.Quindi niente viene gratis, tutto presuppone un effort anche se in questo percorso possiamo avere una serie di soddisfazioni a breve periodo, date magari dall'adozione di tool come Expo, che anche con un minimo sforzo ci permette di fare la nostra applicazione, che però se si complica a quel punto alziamoci le mani, rimbocchiamoci le maniche e iniziamo a studiare.La documentazione è molto dettagliata e completa, quindi anche per chi non sviluppa nativo, stackoverflow e documentazione alla mano se ne esce per fare quasi tutto tranquillamente, poi sempre in diversi ambiti.Siamo andati lunghissimi, però io so che Andrea vuole chiederti una cosa e mi ha detto che non abbandonerà la stanza virtuale di questo bar prima di averte la chiesta, quindi lascio la palla a te Andrea.No vabbè prima abbiamo parlato di questa amicizia che abbiamo, quindi spesso dai tavoli di Rodaus si parla anche d'altro, della nostra vita.Matteo un giorno mi confessa il fatto di avere questa grande passione per Magic e che addirittura era arbitro, non so giudice, scusa l'ignoranza, di questi tornei nazionali.Questa cosa un po' mi ha affascinato e quindi oggi riportando la discussione sul tavolo dello sviluppo, mi viene in mente cosa hai portato la mentalità del sviluppatore nel gioco del Magic o se il gioco del Magic ha fatto cambiare qualcosa in te nel mondo dello sviluppo? Allora brevemente, sì, è una passione che ho da tanti anni poi bloccata nella parte delle medie cose ripresa da qualche anno come giocatore e poi mi sono approcciato a questa parte di arbitraggio del toreo.Per chi non conoscesse Magic è il più grande gioco di carte collezionabili al mondo per quanto riguarda numeri e diffusione, ha un sistema sistema di gioco organizzato eh a livello mondiale dei vari stati con diverse competizioni e diverse carriere professionali e professioniste ehm e da poco anche sulla parte esport con Magic Arena come applicativo ehm il Magic è un gioco di carte eh strategico quindi come giocatore io che faccio come noi facciamo un mentale per noi era andare a giocare con gli amici, farsi quella serata di gioco, in un gioco che comunque ti assorbe mentalmente e ti fa staccare da tutto.È ricorrente in questo podcast anche il discorso del non staccare o del continuare a pensare anche fuori dal singolo ambito lavoro e quello è stato uno sfogo che ti assorbe mentalmente.Ha aiutato nel tuo work-life Esattamente, esattamente.Per me il venerdì sera, dalle nove alle tre di notte, era tutto un non pensare a nient'altro che a quello perché non puoi fare nient'altro perché è un gioco mentale.Mi sono approcciato all'arbitraggio tramite un amico di un negozio dove giocavo che ha deciso di farlo per motivi suoi e da una parte capire, diciamo un po' la curiosità delle regole in realtà molto più approfondite rispetto al gioco in sé, che sono comunque un gioco molto complesso.Dall'altra parte anche l'organizzazione, l'arbitraggio è un'organizzazione abbastanza complessa nell'ambito di una gestione di un torneo, parliamo di tornei magari di 2000 persone dove c'è un grandissimo impatto di logistica, di risoluzione di problemi, tanto per cambiare perché ne facciamo pochi durante la settimana, e quindi la collaborazione di team, una gerarchia di ruoli abbastanza rigida, perché poi in realtà essendo come chi partecipa ai eventi lo sa, è sul momento, hai quel problema lo devi risolvere, non hai i giorni "Vabbè ci penso, trovo una soluzione".È molto vissuto in rapidità.Da una parte mi ha fatto uscire dalla comfort zone del nostro lavoro, del "ci posso pensare" e quindi avere un pensiero molto più veloce e quindi dover risolvere le problematiche più veloce.LM: "Non ne dice, pensiamo".Esatto, grande Alec Gicchi.E dall'altra parte invece una parte di organizzazione, di struttura, di logistica nel posizionare mille persone, di portare diciamo una mente razionale come la nostra quando lo sviluppiamo, nell'organizzazione di questi tornei che sono poi eventi dove gestisci tante persone e ti poni con quello che è customer service nel fargli vivere una buona giornata dove escono soddisfatti del lavoro.È un altro lavoro perché effettivamente è un altro lavoro, non vado lì a giocare e poi con la pandemia si è fermato tutto quanto.Però ecco questi erano gli spunti che ho apportato e che mi hanno dato dall'arbitraggio in maniera professionale.Fantastico, io so che tra le 300 e passa persone nel gruppo ci sono parecchi appassionati di Magic, quindi se vi piace Magic pingate pure Matteo che è presente anche lui nel nostro.L'ultima cosa perché non l'abbiamo detto, ricordatevi il gruppo Telegram di Gippar, Ah sì? No, ti possiamo sentire anche da là.Io so che tu stai fremendo per andare a cenare, anche io in realtà, visto che ho ancora un'ora di viaggio da fare per tornare all'altra casa, ma non ti lascio andare non prima di averti fatto una domanda, anzi di essere arrivati nel momento tipico e anche topico del nostro podcast, il momento del Paese dei Balocchi.Io sono un pessimo lettore quindi cambia dalle abitudini dei veri full stack di questo bar che portano un sacco di contributi utili in lettura.Porto un balocco fisico che ho trovato di un'utilità spaventosa, è un monitor esterno usb c senza alimentazione, alto 8 mm.Possiamo poi mettere link di questo del prodotto è uno schermo dell'Asus MB168 ed è fondamentale e l'ho comprato un sacco di tempo fa sotto suggerimento di un caro amico della magia e l'ho utilizzato come secondo schermo a casa perché comunque ho una casa abbastanza piccola quindi nel weekend lo usavo come schermo esterno senza avere una postazione e che ve lo dico a fare in pandemia è stato il mio secondo schermo per tanti mesi, perché penso che uno sviluppatore senza due schermi non possa lavorare, deve essere mandatoria la cosa, e anziché avere l'ingombro di uno schermo esterno questo poi si ripiega, è alto 8 mm e largo 15 pollici, e quindi lo metti vicino al computer nello zaino, me lo sono portato alle conferenze come secondo schermo con le slide, durante i corsi lo uso come appoggio come secondo schermo.Il secondo balocco, una porta di due, è un video di Code Emotion 2014, un sacco di tempo fa, di Bruce Lawson che lavorava in opera, un personaggio fantastico ed era "How to destroy the web".È un tema che mi è molto vicino, che se non ne sono esperto, parte di accessibilità e suggerisce come non ci meritiamo il web per tutta la serie di pattern che utilizziamo.Fa molto ridere e molto pensare.Si ricordo, l'ho visto in presenza.Esatto.Bellissimo.Ve le lasciamo nelle note dell'episodio.Certo.Andrea? Anche io al mio balocco.Oggi vi porto un gioco che si chiama "Ordinare Puzzle", è simpaticissimo puzzle game, è free, open source, senza advertising ed è realizzato interamente in React Native o anche in React, quindi c'è la versione sia diciamo web che quella realizzata con React Native e ovviamente il link al gioco sia per scaricare l'applicazione o giocarci via web lo troverete in un'ultimo episodio.Anche io avrei un balocco, il problema è che non mi è ancora arrivato, quindi non posso garantire sulla qualità.In realtà ho ordinato una nuova tastiera meccanica super fine, che è la Keikron K3 e poi vi dirò se è figa o meno, visto che ne abbiamo parlato a lungo di tastiere nel gioco.Ma capitura il gruppo a postare tastiere meccaniche.Aggiungo nel dire che Leo mi ha convinto, ho preso la trackball di Logitech e devo dire che è wow, semplicemente wow.In realtà però Matteo mi ha suggerito un balocco che avevo in giacenza da un po' perché anch'io a Lione non avevo il secondo monitor e prima di prendere un fantastico 28 pollici 4k che si vede da schifo ma è grande e ci sta tutto della Samsung volevo usare il mio vecchio iPad Pro da 13 pollici come secondo monitor essendo la prima versione dell'iPad Pro grande non era supportato l'utilizzo come secondo monitor e allora ho acquistato un'applicazione si chiama Duet Display che permette di utilizzare l'iPhone, l'iPad o qualunque tipo di iPad proprio come secondo monitor.È sviluppata da ex ingegneri di Apple quindi anche la qualità quando non si richiede una qualità retina usando la wifi è perfetta in realtà funziona sia wifi riducendo un po la risoluzione per non farlo laggare quindi non funziona con retina oppure col cavo di alimentazione il cavo lightning direttamente in modalità retina e devo dire che in alcuni corsi di formazione mi ha salvato perché l'alternativa era usare il televisore con gli ovvi limiti dei televisori che si vedono da schifo.Quindi anche questo lo metto nelle note dell'episodio.[Musica] Matteo, io non so come ringraziarti e devo anche ringraziare Andrea per aver ci presentato quindi per avervi portato qua.Grazie a voi, grazie Andrea.Adesso è ufficiale, fai parte della famiglia, puoi tornare quando vuoi.Grazie dell'invito.Esatto, GIT Bar da oggi è anche un po' casa tua, ho il tuo bar di fiducia.Sapi che qua non facciamo cappuccini ma solo le birre e nulla.Spero che questa puntata vi sia piaciuta, sono sicuro che vi è piaciuto per la presenza di Matteo che ormai fa parte della nostra community, è diventato uno di noi e io insieme ad Andrea ci teniamo a ricordarvi rapidamente i nostri contatti.info@gitbar.it via email o @brainrepo su Twitter e il gruppo Telegram che potete trovare digitando nella barra di ricerca Gitbar e uscirà la simpaticissima iconcina con il faccino del nostro Brain Repo e potete entrare a far parte anche voi di questa bellissima famiglia Io ringrazio Matteo.Ciao, grazie, grazie a voi.Ringrazio Andrea.Leo è dovuto scappare.Sempre un piacere.Alla prossima.Grazie anche da parte mia, Matteo.Grande mille.Alla prossima.Ciao.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 di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] [Musica] Sottotitoli e revisione a cura di QTSS
