Bene e benvenuti su Gitbar.Altra settimana ed ecco un nuovo episodio.Mattia ti prego non ridere perché sennò io non posso fare a farcela.Non ce la faccio, è più forte di me.Quindi come già avete sentito non sono solo in compagnia, sono in compagnia di Mattia e Carmine.Ciao ragazzi! Ciao a tutti! E non siamo soli perché oggi nel Gitbar ci è venuta a trovare un super guest Ma ve lo svelo non prima di avervi ricordato i nostri contatti Info@gitbar.it via email o @brainrepo su Twitter E poi...Sarebbe stato il gruppo Telegram forse? Davvero? Non lo so, non sono dimenticato.Non lo so, anch'io non ho mai sentito parlare, però adesso che me lo dici in effetti, in dubbio, in via, forse c'è un gruppo Telegram.Occhio a cercare che non è Gitbar Italia, che potrebbe venire come sfizio, ma in realtà è solamente Gitbar e lo puoi riconoscere perché c'è il logo del podcast, come avatar.Ebbene sì, c'è il gruppo Telegram, 345 membri a oggi.oggi iniziamo a essere un bel po dove trattiamo un gozziliardo di argomenti interessanti e proprio adesso sotto gli occhi vedo citare Vim ma Vim non è l'argomento della puntata vedo che anche il nostro ospite apprezza l'argomento della puntata è Graf Quell è quasi e lo andiamo ad affrontare subito dopo la sigla.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 usiamo.Con noi per parlare di questo argomento e specialmente per parlare di Asura, una tecnologia, una piattaforma, chiamiamola così, non tanto conosciuta o perlomeno io non la conoscevo, almeno prima di avere l'esigenza di tirare su tirare su rapidamente delle API GraphQL, ma vi dicevo per parlare di Azure abbiamo con noi Pamela Gotti, Tech Lead in Credimi e CTO di SheTech.Ciao Pamela! Ciao a tutti! Ah che bello riuscire a sostenere, a portare un po' di quota e rosa nel nostro podcast, ne ha bisogno, ma dicci un po', cosa possiamo fare, dove possiamo lavorare per migliorarci dal tuo punto di vista? Guarda, è un tema molto caldo ovviamente, stavo guardando nei giorni scorsi anche un po' di report che sono stati fatti da varie associazioni, proprio anche per arrivare con dei numeri concreti in cui parlare con voi.C'è stato un report che è stato fatto nel 2020 da Women Who Tech, che è una delle associazioni no profit che si occupano un po' del tema delle donne nel tech.Alcuni dei numeri interessanti che mi sono saltati all'occhio è che, se non ricordo male, il 48% delle donne nel mondo tech sostiene di aver subito una certa forma di harassment sul luogo di lavoro.Il 18% sostiene di aver ricevuto delle proposte di fare sesso in cambio di una promozione.Questo è il mondo tech.Vai a parlare del mondo dell'imprenditoria, il 40% delle donne founders hanno avuto la proposta di fare sesso in cambio di investimenti.Quindi insomma, sono numeri abbastanza importanti, che comunque vanno avanti per motivi culturali, di tempo, forse di bias e di abitudini che devono essere un po' sradicate.Da questi numeri importanti ci si deve un po' muovere per portare una diversa cultura in tutte le aziende.Cosa che secondo me deve essere fatta un po' più anche da prima da arrivare sul posto di lavoro e qua parlo delle scuole, a casa, in famiglia, con i bambini, perché alla fine poi come l'impatto che si ha sui bambini si riflette anche sulla percentuale di donne che poi vanno a finire nel mondo della tecnologia, no? Che siamo comunque una minoranza ancora e se pensate solo che nelle università per esempio mi sembra che l'ingegneria fosse le facoltà con la meno presenza femminile, intorno al 20% di tutte le donne iscritte.E comunque, su tutti gli iscritti in università, se non ricordo male, c'è il 37% delle donne iscritte in università vanno in direzioni STEM.Quindi, insomma, è un percorso lungo che viene un po' attaccato da diversi fronti e noi con SheTech stiamo un po' cercando di aiutare le donne ad avvicinarsi nel mondo della tecnologia.Non ci occupiamo solo di quello, ci occupiamo anche di fare empowerment delle donne nella tecnologia, nel digitale e nell'imprenditoria.E lo facciamo facendo banalmente corsi che aiutino le donne un po' ad avvicinarsi al tema.Quindi, per esempio, per quanto riguarda la parte tech, che è la parte che gestisco più, io organizziamo magari dei bootcamp per imparare a programmare con JavaScript.L'abbiamo fatto quest'anno.In passato avevamo fatto Bootcamp per imparare ad utilizzare Python per approcciare il machine learning.Poi organizziamo eventi di networking, cerchiamo di aiutare anche sia le aziende a trovare dei profili femminili che i profili femminili a trovare il lavoro nella giusta azienda, mettendo un po' in contatto i due mondi.Quindi questo è un po' quello che facciamo.È bello perché abbiamo iniziato qualche anno fa, nel 2019, avevamo 200 iscritti e poi con la pandemia adesso siamo arrivati ad averne più o meno 500.E stiamo crescendo.La cosa bella è che comunque abbiamo una community che è molto varia e poi lo sapete anche voi meglio di me cosa vuol dire stare in una community.Poi comunque c'è questo fenomeno che ci si aiuta vicenda, c'è proprio questo fenomeno di empowerment che è molto interessante.abbiamo anche 7% di presenza maschile che ci dà una gran mano sull'organizzazione degli eventi e su tutta la gestione della community.Ti faccio una domanda.Cosa pensi, oltre all'atto meramente culturale, sia l'elemento stativo all'ingresso nel mondo tech delle donne? Secondo me ci sono due temi.Il primo è, come ti dicevo un po' prima, un po' il contesto da cui arriviamo.Farei un esempio banalissimo, prendendo di fremento me.Quando andavo all'elementari, mamma e papà mi hanno messo in mano di tutto.Io avevo la Barbie, ma avevo il computer.Quindi sono cresciuta con il Lego, con i microscopi, con videogiochi da una parte, le bambole, le cucine dall'altra.Quindi ho avuto modo di sperimentare qualsiasi cosa e poi sono arrivata alle medie che non ho avuto tanta indecisione su come proseguire la mia carriera scolastica.Io ho studiato informatica praticamente dalle medie, poi ho proseguito, ho fatto l'ITIS, ho fatto ingegneria, bla bla, e poi sono andata avanti anche nel mondo del lavoro.Non tutti hanno avuto la fortuna, come me, di poter lavorare a tutto tondo su quelle che erano le loro skills.quindi spesso le materie STEM vengono anche percepite già dalle bambine come qualcosa di difficile, qualcosa per cui non sono portate.Quindi quello è un tema.L'altro tema che spaventa è anche il discorso di andare a finire a lavorare in un mondo che è vero ti offre tantissime possibilità, ma che è a prevalenza maschile e l'impatto che si ha può anche un po' condizionare la scelta di una persona se rimanerci o meno nel mondo del tech.Questo perché? Perché anche tutto quello che dicevo prima, esempi di arrivi in un'azienda, ti saltano fuori dei temi di sexual harassment con quello che potrebbe essere il tuo capo, magari ci pensi due volte se non ti senti anche protetta per poter fare escalation ad HR, no? Esempio banale.Quindi secondo me sono questi due temi, che sono tutti e due culturali.Io sono davvero ottimista sul fatto che poi andando avanti nel tempo, ovviamente si vede, stanno cambiando anche un po' la mentalità di tutti sul tema della diversity, quindi sicuramente ci vorrà ancora un po' di tempo.Nell'ultimo report che avevo letto ieri, c'era la stima, mi sembra che erano sui 200 anni prima di raggiungere la parità di genere in generale, che sono tanti, però dei piccoli passi avanti ci sono.Insomma, sono tematiche a cui tutti sono attenti, quindi spero che la situazione migliorerà sempre di più.Ti faccio una domanda che faccio spesso quando si parla di diversity.È una domanda dal mio canto un po' spinosa e io non sono riuscito a darmi una risposta, quindi ti chiedo se tu hai più chiara la situazione.Spesso succede con l'handicap, no? L'ho già detto quando qua da noi c'era Sara.Il fatto di dire a una persona in sede a carrozzelle con problemi di ambulatori "poverino" credi che ci sia il rischio di fare la stessa cosa col genere femminile? Quindi dire "hai queste opportunità solo perché...o comunque questo vantaggio perché sei donna in questa situazione" e se sì, come evitare questo problema? A me è stato detto, più volte.Cioè, nel senso, mi è stato chiesto letteralmente con chi fosse andata a letto per essere riuscita a farmi assumere da Google.Questa è una cosa successa, così come tante cose del "cambia lavoro spesso", probabilmente perché c'è qualcuno che le dà la spintarella.Quindi, cose purtroppo che si sentono, e The Gain è sempre una cosa culturale.come fare a non arrivare lì, secondo me il tema è di, anche una cosa che stiamo cercando di fare con Shitech, buttiamo fuori il più possibile profili tecnici donne per vedere che esistiamo e siamo dove siamo perché ce lo meritiamo e non perché c'è stato qualcuno che ci ha dato una mano.Esatto, no ma al di là del qualcuno che ci ha dato la mano la mia perplessità è anche sempre, sai, è donna, dobbiamo garantire la diversity e spesso passa in secondo piano magari la competenza che invece deve essere uno degli elementi della valutazione, la competenza, la capacità di adattarsi al team sono tanti i parametri nel paniere e quindi mi chiedo sai quando si parla di diversity a tutti i costi spesso c'è questa situazione che ci può fare uno sgambetto e può danneggiare tutto il lavoro invece in direzione di garantire la diversity che stiamo facendo.Hai parlato di Google? Ho parlato di Google.Che tra l'altro ho visto anche qualche altro sorriso, forse memorie di esperienze.Memorie di un passato piacevole, sì.La mia domanda è a Google rivestivi il ruolo di anti-abuse engineer.Avrò violentato anche qua l'inglese ma come mio solito ormai voi lo sapete quindi ci passate tranquillamente sopra.Cosa fa un anti-abuse engineer? Qual è il suo ruolo? In cosa si distingue dagli altri ruoli ingegneristici che ci possono essere una grande corporation come Google? Ti dico che io ero antipiose ingegnere in Google, ma era il lontano 2012, un'era fa, quindi non so neanche più se esista quel ruolo in realtà all'interno di Google.Io lavoravo nel team che faceva un lavoro bellissimo, ovvero cercava di tenere tutti i prodotti free di Google tranne search, per la loro antima parte, cercava di tenerli free dallo spam.Io ho iniziato con Google Maps, prendendomi cura di Google Maps, poi è arrivato anche Google Plus, siamo passati su Gmail.E come lo facevamo, avevamo due team.Uno che era il team di data analyst, se vuoi, che erano quelli che proprio andavano a prendersi i dati, cercavano di trovare i pattern e cercavano di automatizzare delle regole per evitare che questi spammer andassero sul prodotto.tipo in Italia, quello che succedeva per la Maggiore, prendevi un punto di interesse e ci trovavi il Bed and Breakfast sopra, tipo il Bed and Breakfast in mezzo al Lago Maggiore, il Bed and Breakfast sul Duomo di Milano, cose del genere che non erano compliant con le policy di Maps.Quindi c'era da fare un po' di pulizia, però forse l'esempio migliore, in Italia non ce l'avevamo, però negli Stati Uniti, i tassisti e i fabbri, tipo andavi su New York, cercavi Locksmith New York, si colorava la mappa di rosso, perché con la logica del tu sei chiuso fuori casa, chiami il fabbro che ti è più vicino casa.Quindi loro cosa facevano? Riempivano la mappa di puntini, no? Era anche molto interessante andare a cercare delle correlazioni tra tutti questi finti listing che c'erano su Maps, poi andavi a vedere, non so, l'IP da cui erano stati generati, oppure i numeri di telefono in comune.Ecco, insomma, quindi c'era il team che cercava il pattern dei dati e poi c'era il team che sviluppava i tool che venivano utilizzati dagli analisti.Io ero parte del team che sviluppava i tool.Quindi diciamo che la challenge maggiore lì era di tirar su un'interfaccia che consentisse al team di trovare pattern in modo semplice e immediato.Che poi, il più delle volte, che serviva semplicemente una tabella che consentisse di ordinare i dati e di fare delle ricerche nei database in determinati modi.Non era tecnologia per andare sulla luna, assolutamente.La cosa più interessante era che stavamo seduti tutto il giorno con tutto il team, eravamo in 12 persone, se non ricordo male, con l'obiettivo di tenere i prodotti Google Free libri dallo spam.Questo faceva un anti-abuse engineer.divertente io stavo nel team di Dublino, dico l'ultimo bit, il team di Dublino adesso non esiste più perché tutto l'automatizzabile è stato automatizzato e quindi diciamo che hanno...Questa è una di quelle frasi incisive nel senso che quando si dice la tecnologia ruberà il lavoro, no, il lavoro si evolve ma se anche lo dovesse rubare lo ruba anche agli ingegneri quindi non siamo liberi da qualunque tipo di rischio automatizzazione anzi a maggior ragione naturalmente sto dicendo una fesseria perché il nostro lavoro è talmente mutevole in modo talmente rapido che se siamo in grado di trovare un altro un altro ambito di business un'altra applicazione siamo già pronti a lavorare su un'altra cosa Tra l'altro è fighissimo quello che dicevi, ho per un attimo immaginato una versione tecnologica degli acchiappafantasmi, quindi mi immaginavo con Slimer pronti a cercare...quello che in realtà è figo, il ragionamento che fanno gli utenti per andare a fare, a raggiungere l'obiettivo saltellando qua e là nello user journey che chi ha sviluppato il prodotto disegnato per loro.A me è capitato tantissime volte di vedere come l'utente in un modo completamente creativo raggiungeva i suoi obiettivi, schippando completamente tutto il processo che noi avevamo pensato per quell'utente.Ti è mai capitato di avere la stessa esperienza, quindi in altri prodotti, di vedere che l'utente faceva dei pattern completamente diversi da da quelli che immaginavate? Ah, ma spesso.Allora, devo dire, quando stavo in Google, non tantissimo, perché io avevo a che fare più che altro con i ragazzi del team.Quindi il mio utente era loro, se c'era qualcosa che non era chiaro, ci si parlava subito, non aveva neanche bisogno di inventarsi pattern strani.Sì, c'è capitato più che altro in Credimi.Ogni tanto ci si immaginava un determinato flusso per l'utente, qualcosa che poi per te magari è chiaro e poi l'utente non si vede quel bottone "aggiungi la fattura" che è in alto a destra, che magari tu lo vedi subito e l'utente invece lo cercava in giro per tutta l'interfaccia, per dirne una.Comunque sì, sempre.È difficilissimo anche penso mettersi nei panni dell'utente dal punto di vista di qualcuno che ha una certa idea del prodotto.Bellissimo.E tra l'altro, scusami Mauro, aggiungo anche che è una cosa super difficile da misurare, nel senso che nel momento in cui tu hai un utente che non vede lo user journey che hai disegnato per lui, capire perché non lo vede è complicatissimo da misurare.Io ricordo che tempo fa lavoravo su uno sito di annunci e la metrica di quanti utenti rispondono agli annunci per email versus quanti per telefono ce l'hai sul sito perché sono due tasti e sai quando un utente schiaccia un tasto e quando un utente schiaccia l'altro, però perché, cioè come fai a dire perché un utente schiaccia un tasto anziché l'altro e come fai a dire quale metrica preferisci e quale metrica vuoi influenzare? La parte difficile secondo me è quella, è capire non solo cosa misurare ma anche cosa c'è dietro a quello che stai misurando perché le metriche che stai misurando sono fatte così, è un bel casino, quello è super divertente.Anzi, e aggiungo anche che magari se vuoi fare un'intervista ad un subset di un pent, una specie di focus group posteriori, a me è capitato ed è anche difficile effettivamente interpretare quello che ti dico.No, ma io ho cliccato quel pulsante lì, boh, c'era.Quindi nel senso, anche lì, riuscire a colmare quel brigio tra il tecnico ovvio e l'utente a cui magari non è ovvio, è effettivamente difficile anche a livello di comunicazione, almeno per me lo è molto molto difficile.Direi… Dai, fammi la scelta.È anche interessante che il fatto che comunque noi abbiamo anche un certo, ognuno di noi e ha una certa idea di come usare i prodotti digitali, immagino.Adesso mi avete fatto venire in mente che stavo parlando con un'amica che lei è una UX engineer, sta facendo un esercizio in cui deve tirare su quest'app per un corso e deve praticamente fare un'app per le prenotazioni.Adesso per farvi un esempio, lei mente con queste app nuove che vanno per lo swipe a destra e a sinistra, Abbiamo il nostro gruppo, ci ha messo l'esempio di quest'app.Noi tutti, early millennials, tutti ci aspettavamo i bottoni, non riuscivamo a capire come funzionava quest'app.No, invece lei, ma no, basta far swipe.Insomma, cambia anche tanto in base anche all'età banalmente dell'utente.Io mi aspetto bottoni dappertutto, ovviamente adesso non me li mettono più.Quindi, mi immagino, non lo so, un cinquantenne, un ottantenne usare la stessa interfaccia rispetto a come la userei io, come la userebbero un ventenne, insomma, sono stemi molto interessanti di cui non so nulla, mi ci sto approcciando adesso ogni tanto, però.Sì, no, io volevo giusto aggiungere una cosa che ha detto Mattia sul cercare di capire come l'utente possa stravolgere lo user journey usando le metriche con la consapevolezza che nel momento in cui definiamo un sistema di metriche noi stiamo introducendo il nostro bias legato allo user journey che abbiamo progettato quindi in realtà sono pienamente d'accordo con quello che dice Mattia anzi ancora di più vero è che se da una parte dobbiamo confrontarci con un mondo fatto di interfacce esiste anche un'altra parte del mondo dove le interfacce sono diverse e parliamo di API.Ad oggi, parlando di API design, perché scegliere GraphQL su, come diceva Davide in principio, fu il verbo "il buon rest"? Io ti posso dire perché abbiamo deciso di adottarlo in Credimi.E penso che sia stata una scelta vincente.Noi siamo partiti ovviamente utilizzando REST.Adesso faccio tutta la storia dall'alba dei tempi.Però siamo partiti utilizzando REST in un mondo in cui le specifiche ti cambiamo dalla mattina al pomeriggio.Quindi tu immagini che ti arriva la specifica dal PM, metti lì, ti disegni la tua REST API, la implementi, va bene tutto.il giorno dopo, ah no, ma in realtà questo campo che tu hai detto di far vedere al cliente non glielo dobbiamo far vedere perché in realtà è troppo sensibile, però dobbiamo aggiungere questi altri 7-8 campi che per prenderli deve interagire con altri mille microservizi, no? E allora cambi di nuovo e poi dopo due giorni si ripete la stessa cosa.Quindi a una certa, ci siamo trovati e abbiamo detto ma perché non cerchiamo di sfruttare GraphQL perché così da una parte siamo forzati a pensare per bene tutte le entità che sono coinvolte nel nostro modello.A capire qual è il grafo che collega queste entità e da lì ci veniva fuori lo schema, no? Lo schema GraphQL, lì con l'idea che il team di back-end avrebbe esposto tutti i dati possibili e inimmaginabili.Il team di front-end si sarebbe preso solo quello che gli serviva.E poi la challenge che abbiamo avuto dopo era un po' la challenge anche quella dell'autorizzazione.che l'abbiamo...perché ovviamente REST, penso quando facevamo factoring, noi avevamo queste API con le fatture che erano questi blobboni di 60 campi, no? Se devi mettere l'autorizzazione sul singolo campo, e lì con REST c'è da diventare un po' creativi, no? Non è banale come avere un endpoint che ti ritorna una risorsa bella fatta e finita.E quindi utilizzando GraphQL abbiamo anche un po'...Siamo anche riusciti ad andare a tunare le autorizzazioni proprio a livello del singolo campo.L'abbiamo fatto utilizzando questo tool che si chiama Asura, che ci ha permesso di esporre un server GraphQL in cinque minuti, penso.Ho provato a scriverlo utilizzando Sangria in scala, perché nello stack abbiamo scala, diciamo che è stato abbandonato l'approccio, perché è stato molto più veloce ed immediato utilizzare Asura.Quindi, ricapitolando, Asura è un tool.Ci puoi dire qualcosa in più? Allora, Asura è un tool open source di questa startup californiana.Come funziona? è un'immagine docker di un server scritto in Haskell che si attacca ad un database Postgres e che ti espone il database, così come lo vedi.Quindi con le tabelle, le relazioni che tu hai definito sulle varie tabelle.Ti espone le tabelle, ti espone le viste, ti dà la possibilità, appunto, come dicevo, di andare a definire autorizzazioni a livello di singola colonna, ti dà la possibilità di fare remote stitching, di arricchire lo schema con quelle che si chiamano actions, quindi andare a scrivere del codice custom.Adesso sono arrivati anche con la versione cloud, che si connette a diversi tipi di database, anche può andare su AWS, su Azure, mi sembra.e può connettere anche diversi database.Mi può parere che una stitching tra database diversi mentre nella versione iniziale ce n'era una sola.E appunto quello che ci è piaciuto di Azure, ovviamente c'erano altri competitor che avevamo valutato all'epoca, ad esempio Prisma.Abbiamo deciso di andare verso Azure perché era open source, perché ci è piaciuta tantissimo la community.Mi ho piacevolmente scoperto che hanno un canale Discord, dove ci sono anche i fondatori che interagiscono molto, insomma, spesso e volentieri sono molto reattivi.Ci hanno dato una grandissima mano nei primi giorni, anche se problemi veri non ne abbiamo avuti tantissimi.Perché? Perché hanno un ciclo di sviluppo molto veloce, rilasciano un sacco di feature, quindi tu avevi un problema, magari dopo due o tre settimane era già risolto.Quindi per questo motivo abbiamo deciso di utilizzarle.Poi, ripeto, quando abbiamo provato a fare una sorta di POC, ho preso l'immagine Docker, scaricata, messa su la mia namespace, su Kubernetes, attaccata al Postgres ed era su.Domanda.Ho una domanda anch'io.Vai tu, Mattia, allora.La mia domanda è facilissima.Ero curioso, giusto, di sapere se usavate già Postgres e quindi questa cosa ha guidato la scelta di Azure oppure avete succetto Postgres per usare Azure? Noi usavamo già Postgres.In realtà siamo partiti utilizzando MySQL.Poi abbiamo deciso di migrare su Postgres più per sfruttare anche un po' tutta una serie di funzionalità di Postgres all'epoca.ma in realtà penso che l'abbiamo implementata nell'ultima versione, non sono sicura, ad esempio poter utilizzare JSON nelle colonne quando abbiamo iniziato ad usare Postgres, la versione che usavamo di MySQL non ce l'aveva.Ormai non è nemmeno più tanto recente, cioè Postgres lo fa da quell'inizio, vero? Sì, esatto.Quindi avevamo deciso di migrare a Postgres per sfruttare tutta una serie di funzionalità che Postgres aveva e che MySQL non aveva, e lo stavamo proprio utilizzando per andare a consolidare tutti i dati che stavano nei vari database, nei microservizi, in quello che chiamiamo Read Side, che è un po' il contenitore di tutti i dati che arrivano appunto da varie sorgenti e che appunto è il Read Side della nostra applicazione.Utilizziamo un approccio Secure S, quindi abbiamo il Write Side che mi va a scrivere su tutti i vari microservizi, però poi quando il frontend deve leggere, si prende tutto dal read side.Quindi il Postgres è diventato un po' questo aggregatore di dati su cui abbiamo messo GraphQL.Ecco, diciamo che quando abbiamo iniziato, ecco, non abbiamo scelto Azura per via di Postgres.Ok, era esattamente quella la mia domanda.La mia domanda invece è super super simile.Ho sentito prima che è un dato Kubernetes, insomma.In produzione avete usato Postgres, diciamo, qualche soluzione più, diciamo, cloud oriented, che può essere, so, Amazon, Google Cloud, eccetera, eccetera, o avete fatto qualcosa, diciamo, in casa.Sto semplicemente rapportando alla mia esperienza, dove in azienda utilizziamo Postgres, su Kubernetes, e utilizziamo il Postgres operator di Zalando, che utilizza patroni sotto, per fare questi clustering, con le varie repliche, insomma.Ero curioso, perché effettivamente quando ne parlo con alcuni colleghi, "Ah, sì, potrebbe essere Cloud, quindi non ci sbattiamo nemmeno".Te lo dico anche io, Cloud, non ci sbattiamo nemmeno.Lontano dagli occhi, lontano dal cuore, no? Sapete che sono uno dei pochi invece invece c'è questa sofferenza continua tra le repi che si allineano.È bello.No, ma sai, dipende anche un po' dalle skill che uno ha all'interno del team, no? Per noi era abbastanza un no-brainer andare su una soluzione cloud, soprattutto per il database, perché non avevamo esperti in materia che potessero appunto gestire la cosa.Altro tema, Kubernetes per esempio, non ce l'abbiamo gestito, ma perché avevamo le skills per gestirlo noi.quindi quello è un altro tema, lì dipende sempre da come è composto il team e da cosa ti conviene tenere in casa e cosa mettere sul cloud.Hai detto che Asura è scritto in Haskell.Yes.Haskell per me è il famoso miraggio che più il tempo passa più si allontana e provare a rincorrere nei miei sogni.Prima o poi ci arriverò.Però la domanda che volevo farti è...introdurre...sai, quando si abbraccia una soluzione anche open in qualche modo si ha la curiosità, la necessità di avere almeno la sensazione di essere in grado di poterci mettere le mani.Io adesso non so se nel team voi avete competenze di Haskell, in quel caso forse la mia domanda è stupida e fuori luogo, però come si supera proprio questo limite cioè il dire ok adotto una soluzione che scritti in un linguaggio che ha il luogo comune di essere uno di quelli più difficili da apprendere? Ma alla fine questo scoglio penso che c'è un po' con tutte le tecnologie che utilizziamo, no? Perché noi abbiamo lo stack su RDS, scusami, su AWS, qualsiasi cosa che usiamo di AWS non ha più palidere di come sia scritto.Quindi esiste un po' in tutti i campi.Per quanto riguarda Azure, in particolare Haskell, io penso che allora, skills di Haskell nel team, le abbiamo, nel senso che abbiamo una persona che ha scritto Haskell in passato, quindi lo capisce.Abbiamo qualche persona, a me compresa, che semplicemente letta un libro e che non può assolutamente dire di essere competente di Haskell, però almeno ci ho provato.Diciamo che però, di solito, chi scrive Haskell tende ad avere del codice ben scritto.ma non so come...è difficile che trovi qualcuno che ti scriva l'ASCEL e che possa scrivere delle cavolate pure, no? Mi sto immaginando...faccio l'esempio, faccio sempre questo esempio qua di Python, no? Ci sono anche i corsi che ti dicono "ah, diventa un programmatore Python in sette giorni".Uno che ti fa un corso di Python in sette giorni, poi ti può scrivere delle cose che non si possono vedere, no? ASCEL la vedo un po' dura, perché se...Carmi ne è triggeratissimo da questa cosa.E quindi niente, tendo a, alla fine tendi a fidarti, abbiamo anche visto appunto ripeto la community che ci sembrava molto attiva, quindi, insomma, tra quello.Poi hanno iniziato a fare anche le conferenze, hanno iniziato a diventare anche un po' più widespread, quindi, non è stato un problema, ecco.Io avevo una domanda più che altro su Asura, non ho ancora capito, ok Asura, in questa conversazione ognuno lo sta pronunciando in un modo diverso.Carmine, guarda, quello che sbaglia al modo sono io.Va bene, Asura.Diciamo, una delle perplessità che ho spesso quando vedo queste soluzioni, e parlo comunque dal presupposto che ho avuto un'esperienza simile con GraphQL, non con Asura, ma con un post file, si può chiamare così, che diciamo è l'alternativa che però va solo su Postgres con delle cose diverse, c'è tutto l'RBAC fatto in Postgres, un macello terribile.Ma una cosa che mi fa sempre, diciamo, che mi lascia un po' perplesso, almeno questo per il mio caso d'uso, è il fatto che vada bene per il crude, insomma, che sia, diciamo, data centrico e che quindi leghi sostanzialmente ciò che stai esponendo a filo doppio con quello che è il tuo schema, insomma.Diciamo, è una cosa che spesso, diciamo, ho trovato più come un compromesso che una vera e propria feature, insomma, su cui volere andare.Però, insomma, ammetto che è comunque un mio bias, insomma.Sono sempre più contento se riesco a disaccoppiare a creare dei layer sostanzialmente siamo molto più indipendenti di loro.Secondo te è una preoccupazione utile, inutile o è semplicemente il caso d'uso che ha proprio Asura? Insomma, fare crude e farlo in un certo modo e poterlo gestire anche più semplicemente.Ti potrei rispondere, come non dipende da cosa ci vuoi fare con Asura, no? Nel senso che nel nostro caso noi dovevamo solamente esporre quello che era il read side.Quindi avevamo già dati abbastanza puliti su questo database da esporre e scrivendo un servizio apposito non avremmo fatto nient'altro che prendi i dati e falli vedere.Posto che avevamo già fatto un ottimo lavoro di appunto modellizzazione degli oggetti e quindi il database era già messo in una buona situazione, Nel nostro caso, ovviamente, metterci sopra un layer che ti espone il database è il risultato vincente.Ovvio che poi, se devi anche fare una considerazione del tipo, metto su Azure perché devo esporre due tabelle, ma per le altre 70 tabelle mi devo scrivere dei resolver custom, forse non è esattamente lo scenario più migliore, insomma, per utilizzare Azure.L'abbiamo utilizzato anche per fare prototipazione di un altro prodotto e lì l'abbiamo usato sia in lettura che in scrittura e ci ha consentito di andare straveloce.Quindi immaginati letteralmente devi lanciare un nuovo prodotto, cosa fai? Inizi a farti tutti i vari layering della situazione o ti prendi un database e ci scrivi dentro cose per un MVP e poi eventualmente lo rifai? No, no, certo.Abbiamo deciso di andare per quella strada, quindi sì, dipende.Poi, ovviamente, come dicevo prima, Asura comunque ti permette un certo tipo di versatilità, quindi ti permette, non lo so, di fare schema stitching con magari un altro server che hai scritto, quindi se devi fare arricchimento dello schema lo puoi fare.Hai bisogno di una business logic specifica, puoi scrivere queste, si chiamano actions, che si connettono ad API remote, lo puoi fare, ovvio.Dipende sempre da quanta customizzazione hai, ripeto.No, ok, no, era semplicemente una domanda, sì, anche a me è capitato di utilizzare alcuni tool simili, più sulla parte, insomma, REST che sulla parte GraphQL, però è qualcosa di interessante che voglio sicuramente provare, insomma.Anche perché comunque visto che, diciamo, ora io ho dato un'occhiata veloce prima della nostra puntata, diciamo, anche sostanzialmente il controllo più a basso livello dello schema con le mie creazioni, puoi farlo un po' con quello che vuoi.Insomma, quindi magari se sei abituato a farlo in plain SQL oppure con Rails, oppure con SQLite o qualunque cosa, puoi comunque farlo, che è una cosa che con altri tool simili non hai e spesso ti ritrovi bevendo all'occaso a 360°.Quindi questa è una cosa che mi piace.Ma Azure, se non ricordo male, ha aggiunto anche il supporto alle migrazioni.Noi le facciamo in modo esterno, non le facciamo con Azure, ma abbiamo proprio una pipeline che ci tira sulle migrazioni utilizzando Flyway, che è una pipeline a parte, che appunto ci consente di migrare solo il database e abbiamo tutto il 2GC ACDE anche un po' impostato in modo da avere sempre Asura aggiornata con la versione del database, sottostante con le migrazioni.Abbiamo proprio voluto metterle fuori da Asura proprio per avere un po' più di controllo sul tool.Infatti, la mia domanda verteva proprio su questo argomento.Come si configura una pipeline di CI/CD con un tool come Asura? Faccio una domanda stupida, no? Io faccio la mia bella configurazione del mio POC in locale.Funziona tutto bello.Da qui ad andare in produzione, come si va? Guarda, per Azure, noi stiamo usando la versione open source, non usiamo quella cloud, quindi posso parlare di quella.Abbiamo la pipeline che cosa fa? Immaginati che il primo step ti fa le migrazioni sul database, il secondo step ti tira su l'immagine docker di Asura con i metadati che hai configurato, poi magari vi spiego bene cosa sono, e poi come ultima fase abbiamo scritto dei test in Python che vanno a testare anche le autorizzazioni che funzionano nella maniera in cui ci aspettiamo.Quindi alla fine per Asura si tratta semplicemente di tirar su un'immagine docker in cui vengono occupati dentro i metadati.Ed è letteralmente una...andando a vedere il docker file, sono due righe, cioè sinceramente il from, Asura e il nome dell'immagine, e poi la coppia dei metadati.Questi metadati cosa sono? Sono la configurazione di tutte le tabelle, tutte le autorizzazioni, tutte le funzioni, le action, remote schemas, che sono definite in Asura.Una delle cose che ci era piaciuta molto è che la UI è molto intuitiva.E quindi qualsiasi cosa che si deve cambiare a livello di voglio esporre una tabella, voglio esporre una colonna, lo posso fare io, ma lo può fare una persona che è appena arrivata nel team che non conosce bene tutto lo stack.A differenza di se avessi tirato su il server utilizzando Sangria in scala, insomma, magari c'era da smanettarci su un attimino di più.Quindi, nel momento in cui tu stai sviluppando, hai la tua immagine di Azura che è in running, sul tuo ambiente di sviluppo.Ci fai tutte le modifiche del caso, da UI se vuoi, altrimenti utilizzando una clida terminale, esporto di metadati, versionati, in modo che anche poi riesci a capire bene cos'è cambiato da una release all'altra.That's it.Non ho la più pallida idea di come si integri Azure a Cloud con in realtà, con questo tema, insomma.Perché ovviamente poi non è più gestito da noi, non so come funzioni proprio la gestione dei metadati.Interessante.E comunque è tutto facilmente configurabile da una UI senza dover fare i conf a mano.Hai mai sentito questo come un limite? Sai, quando lavoriamo con dei conf abbiamo la sensazione di avere più controllo della cosa.Forse, ripeto, è un bias, forse è giusta una sensazione.Però la mia domanda è, hai sentito il limite di dover lavorare da UI o solo tanta bella roba? Ti dirò che tu parlavi di Vim a inizio puntata, quindi io edito i file di configurazione con Vim se devo fare delle modifiche su Asura.- Perché sono più avversario.- Quindi tu sai uscire da Vim? Io so assolutamente uscire da Vim e non vi dirò mai come si fa.No, esatto.Non si può dirlo.No, comunque, diciamo che hai la versatilità della cosa, no? Se vuoi ti puoi editare i file di configurazione, se vuoi puoi scrivere un comando utilizzando la CLI, se vuoi e non hai voglia di impararti la sintassi della CLI, non hai voglia di capire come funziona il file, vai sulla UI e te lo fai lì.Insomma, secondo me è un vantaggio anche perché proprio volendo avremmo potuto dare Azure in mano al nostro PM e ci avrebbe modificato lui le autorizzazioni, per esempio, sarebbe completamente stato in grado di farlo grazie alla UI.Autorizzazioni, autorizzazioni, bella cosa.In realtà, ripeto, io ho fatto un mezzo test per lanciare uno dei miei tanti POC che finiranno su un cassetto della credenza insieme a qualche raspberry pi e a qualche tastiera che mi sono stancato di usare.Però ho visto un interessantissimo un interessantissima area di autorizzazione e la cosa che mi ha incuriosito è che non ho visto la presenza invece di un sistema di autenticazione.Secondo te perché, in realtà un po' ho capito il motivo, però secondo te perché e soprattutto come funziona il sistema di autorizzazione di Asura? Questa volta l'ho detto bene anch'io.Grande.Non so perché non abbiano deciso di implementare un sistema di autenticazione ma deduco che il loro obiettivo fosse un altro, no? Non per non concentrarsi tanto su temi di autenticazione che sono anche un po' critici, no? Quindi meglio lasciare il lavoro a chi lo sa fare.Asura non fornisce appunto l'autenticazione ma fornisce dei webhook che si possono agganciare a un servizio esterno che poi può appunto riportare indietro dei token di autorizzazione dove sono settati dei ruoli che poi Azura utilizza appunto per capire che dati può, quali dati può avere accesso l'utente.Se non ricordo male, ci sono questi ruoli che possono essere passati direttamente nell'header della richiesta, esatto, anche sì nei token JOT, quindi sono letteralmente delle stringhe che si settano lì, e in base a quello appunto Azura poi ti va a validare il token, ti va a verificare la signature, poi se il token è valido, quello che fa è solo la layer di autorizzazione.Ti ho risposto più o meno? Sì, no, tra l'altro ci sono dei tutorial semplicissimi, io ho fatto per il mio POC l'autorizzazione con Auth0 ed è stato veramente 5 minuti di roba, due configurazioni ed è presto fatto.Però è interessante invece il fatto che abbia già out of the box un sistema dove e puoi gestire l'autorizzazione con una granularità anche importante, no? Sì, puoi andare alla singola colonna, puoi dare autorizzazione di livello anche di riga delle varie tabelle e poi tutte le entità che ci metti sopra, quindi se decidi di implementare una funzione, se decidi di implementare una vista, tutto si porta dietro il sistema di autorizzazione, quindi si può andare davvero granulari quanto si vuole.Ed è solo una questione di appunto configurazione.O da UI, dove è letteralmente l'interfaccia con la lista delle tabelle, le checkbox delle colonne che clicchi, sulle colonne che vuoi esporre al ruolo.Poi per quanto riguarda le righe invece, c'è la possibilità di definire dei match.Quindi per esempio se la WhatCode mi...La WhatCode, scusa, adesso mi dà sempre in mente, credimi, se la partita IVA dell'azienda mi equivale a quella dell'utente, esempio vi faccio vedere solo le sue le righe della sua azienda.Diciamo che toglie tanta carne al fuoco dovendoselo implementare con Apollo, un pochino più impegnativo, Apollo per citarne uno, tu hai citato Sangria, ma la mia domanda è ci sono dei casi d'uso dove sconsiglieresti di assolutamente utilizzare un tool come Asura.Come dicevamo prima, Asura va diretta sul database sottostante.Quindi se c'è qualsiasi motivo per cui avrebbe senso avere dei layer intermedi, probabilmente andrei con una soluzione custom.Sto pensando se c'è qualche esempio specifico.però magari anche pensando alla scrittura, nel nostro caso, come vi dicevo, abbiamo la scrittura nei microservizi, perché comunque c'è tutta la business logic che deve rannare dietro.Quella da fare in Azure, l'avremo tutta a fare, sì, però andavi probabilmente a customizzare troppo il tool e ci saremmo un po' persi la bellezza di usare qualcosa che lo tiri su e lì, e lo devi toccare il meno possibile.Sì, prima hai parlato dei webbook, no? Per Credimi li avete usati e se sì hai trovato dei limiti a quell'approccio? Le action so che il team ci ha sperimentato un po' su per una nuova feature che stanno rilasciando in questi giorni.Che dire, allora le action per esempio avevano un problema se non ricordo male di schema, nel senso che, ad esempio, facciamo una action che ti ritorna delle informazioni su una fattura, ok? Sono giusto sempre per stare in tema, credimi, che sono un po' monotematica.Ti ritorna una fattura con dei dati di un'azienda, tu puoi scrivere lo schema per cui dai dati della fattura della action riesci a tirar fuori informazioni in estate dell'azienda.Il viceversa non lo puoi fare.Quindi non puoi avere il grafo che ti parte dall'azienda e chiamare la action internamente.Quindi quello è un limite.Le action le ho viste un po' di più come un "devo fare una chiamata API" specifico, utilizzo GraphQL perché mi consente una certa flessibilità nell'esporre lo schema, insomma.Tutto qua.Però a parte quello, se ci pensi è come fare letteralmente una chiamata API un altro servizio che poi te lo implementi come vuoi tu.Quindi si tratta solo di una questione di prendere dati di cada proxy da una parte all'altra.Chiaro.Chiarissimo.Io invece volevo fare una riflessione anche diciamo più ad alto livello, no? Su quando magari scegliamo REST e quando magari possiamo scegliere GraphQL.Oltre diciamo al tipo di modellazione all'entità, tutto il DSL, come tipi che c'è dietro.Ad esempio, a noi è stato comodo GraphQL, anche perché diciamo si fetchava meno per fetchare meglio, perché nel senso, se il talent ti chiede x, y, z, io chiedo al database solamente x, y, z.Poi a noi è stato un po' un patema, perché noi lo facciamo in Go, quindi puoi immaginarti, non c'è proprio, diciamo, un tool come Asura, e quindi fare il resolver al mano che ti compone la query a mano - Ah, ia! - del builder, e fai select solo del campo che ti chiedono di mandare.Insomma, è stata abbastanza, insomma, un po' così.Però, effettivamente, quella cosa lì ci ha dato un boost incredibile, perché spesso il client chiedeva delle cose via REST, ma magari utilizzava solamente tre, quattro campi il più delle volte.Mi sto immaginando, diciamo, in un contesto grande come può essere con l'ipostore, magari ho queste fatture enormi, ho queste cose qui, il poter solo chiedere x, y, z e poter prendere solo quello, immagino che vi abbia anche dato un boost di performance, oltre anche magari la semplicità per il client.Sì, un'altra cosa che avevamo considerato quando avevamo pensato di passare a GraphQL, Dicevo che avevamo questa risorsa gigante che era la fattura dove c'era dentro di tutto e doveva andare a prendersi i dati da un sacco di tabelle, fare left join, vai ad integrare con dati che arrivavano da altri microservizi.Ovviamente le API erano lente, il tutto, perché poi magari dovevi far vedere nella tabella all'utente il numero della fattura, la montata e la data di pagamento.Quindi mi ritrovo assolutamente con quello che dici.Siamo con quello che è anche l'endless one problem, Quindi magari se hai l'approccio REST, devi appunto anche seguire il path di dire ok, prendo prima l'informazione della fattura, poi prendo l'informazione di tutte le rate e poi invece con GraphQL lanci una query e ti ridà indirettamente tutti i dati di cui hai bisogno.Ok, adesso qui invece è una domanda per tutti perché ne stavo parlando con alcuni miei colleghi un po' di tempo fa.La pagina azione con GraphQL, con il cursore che a me piace, o una cosa diciamo un po' più tradizionale con le pagine per prendere così.Nonostante quella con il cursore, se non usi la data su città, sia abbastanza un patema.Adesso non so come fa, insomma, Asura, se astrai questa cosa.Allora, gli oggetti che abbiamo utilizzato fino adesso non ci hanno richiesto di utilizzare la paginazione.Ok.Per quanto riguarda le fatture, tutta la parte delle fatture era sullo stack vecchio, non l'abbiamo migrato a GraphQL.Su GraphQL abbiamo un po' la parte di prestiti, comunque ha oggetti differenti e tendenzialmente ci sta tutta la informazione in una pagina.Adesso mi cogli in preparata su questo.Non ricordo, Asura, avevassi un modo per poter fare la paginazione classica con il limite di oggetti e il numero di pagina, però sono completamente impreparato in quel punto.No, vabbè, era giusto una domanda che anche un po' per tutto sì, per parlarne, diciamo, ci sono state diverse riunioni, "eh, ma a me piace con il limite offset", no? "Lo facciamo con il cursore", no? "No, aspetta, Postgres", quindi, anzi, considerando che comunque non utilizziamo norma, il fatto di doverlo comporre a mano e fare quella con il cursore per farla proprio efficiente per Postgres è stato un bel pezzo proprio di procedurale brutto, insomma.È giusto che lo si pensi.Comunque io ho fatto quello che riguarda la documentazione live al momento.Lo stavo facendo anche io.a sia la paginazione alla Postgres con limite offset che quella fatta con i cursori, quindi le supporto tutte e due.In effetti la mia risposta alla tua domanda per tutti era fondamentalmente che dipendo, come sapete tutti è la mia parola preferita del mondo, e dipendere da quello che devi fare la te la ti fruttendo, di fatto come pagine immediate.cioè alla fine è la stessa cosa che abbiamo fatto noi, con l'infit scrolling si va con il cursore perché è oggettivamente più comodo, se magari una radiazione classica è ovvio.Poi qui si entrano in delle cose male performance, l'indice, le cose, si va in tutta altra cosa che non vengono discusse su Gitbar ma su altre community che finiscono Italia.Verrà un giorno in cui Carmine non nomina altre community che finiscono con Italia, ma non è oggi quel giorno.No, però devo dire che ho avuto un'esperienza proprio con la paginazione, ho avuto esperienza con Strapi perché mi serviva la paginazione a cursore e in Strapi non era supportata.Infatti quel POC che aveva come base Strapi è stato allegramente immigrato su Asura.È ancora un POC ma...o Asura.È arrivato il momento golessecche, quindi ci prendiamo giusto un attimo per berci una birra.birre invitate oggi da Pazo e da Cimasim89 birre che, dopo una chiacchierata così lunga, fanno sempre comodo quindi noi, prima di berle, alziamo in aria i calici e brindiamo a Pazo e a Cimasim Cimasim che ci dice "Git commit -m" "Conoscere GitBar è avere un posto dove poter condividere la passione dello sviluppo" naturalmente non verifai quindi prendiamo questo commit e lo pushiamo direttamente su gitbar e Paso invece scrive a luglio inizio a lavorare in una nuova azienda a colpa del podcast che ha riacceso la sacra fiamma del dev festeggiamo tra l'altro Paso ti devo ringraziare per la mail che che ci hai iscritto, dove ci raccontavi un po' questa nuova esperienza del lavoro e sappi che ci hai fatto emozionare quindi ricapitolando grazie a Paso e grazie a Cimasin perché grazie alle loro birre in questa puntata le nostre gole non erano e non sono poi così secche *musica* domanda mmm sempre riguardo a Graf Quell QL questo perché è un argomento che mi ha toccato da molto vicino questa settimana visto che sto lavorando su Apollo ed è la gestione degli errori cioè come il server ci risponde errore.Una cosa che ho visto è che un po spacca gli utilizzatori di GraphQL è quella di modellare le risposte con l'errore quindi l'errore è una possibile risposta quindi te lo vai a modellare oppure come fa Apollo restituire o un area data dove ci sono i modelli dove diciamo è aderente hai un risultato aderente allo schema e poi errors dove ci puscia in modo schemaless o comunque schema light nel senso che lo schema degli errori è sempre quello più i metadata e poco altro Come gestisce Asura la risposta all'errore? Come risponde all'errore? Se non ricordo male, ha la versione Apollo Style.Non sono sicura al 100% di questa cosa, però sono sicura che andando a vedere la documentazione lo troviamo subito.Sì, perché in realtà spesso si trascura la questione della risposta all'errore, però avendo indossato anche il cappello del frontender il dubbio mi viene.Tra l'altro il tema di errori è una cosa che turba tantissimo di GraphQL in generale che risponde sempre con un 200.Non sono mai riuscita a farmene una ragione, questo mi urta tantissimo, più che la forma della risposta.ma in questo periodo bisogna essere pur positivi.Non è comunque un buon motivo per ritornare a 200.Io ci ho provato, in realtà era impossibile difendere quell'app.In realtà stiamo dando un'altra scusa a quegli applicativi che sono molto legacy, magari che utilizziamo ogni giorno e diciamo "ho comprato il biglietto" e vabbè, 200 errore.Quindi sono loro che erano avanti con i tempi evidentemente.Mi sa che è veramente triggerante, perché di recente ho avuto a che fare con un API che ha delle richieste GET con il body, quindi sono molto sensibile sul tema di come si fa bene HTTP, quindi mi state veramente facendo del male.C'è delle richieste GET con il body? C'è delle richieste GET che però vuole il body, quindi ho scelto il body.Sergio fa una cosa molto molto simile effettivamente.Ho scritto ai tizi di questi Twitch "ragazzi guardate che HTTP è fatto in un altro modo" e hanno detto "ok, la cambiamo e facciamo la post, grazie".Ho una domandina invece per quanto riguarda schema, tipi e questo Cioè, fino a qualche anno fa scappavamo dai tipi come un'eminenza grigia che ci rincorreva e oggi invece...Potrei dirti molto male, tra l'altro.Come vedi questo ritorno all'utilizzo dei tipi, degli schema abbastanza rigidi? Allora, stai chiedendo ad una che scrive Scala? Io sono solo contenta.Io ho un background comunque da Scala e Python e una cosa che mi è sempre mancata in Python erano i tipi.Quindi io non posso essere che contenta perché comunque tolgono, soprattutto quando poi di metterti lì a fare magari un po' di refactoring ti tolgono tanto di quel mal di testa che sono una gran mano, poi sei sicuro di avere il dato che ti serve, quindi io sono assolutamente pro a questa cosa.Oggi non sono in minoranza, io di solito sono quello dei type systems stretti e sono quello che li difende, ma almeno oggi non sono in minoranza.Poi in realtà la risposta giusta sarebbe sempre "dipende da cosa devi fare".Certo, quella è la risposta a tutte le domande del mondo.Esatto.No, però adesso a questo punto la domanda viene automatica.Siccome mia moglie si trova più o meno nella stessa situazione, cioè per metà Python, metà scala, ma come fate a far convivere queste due anime senza bisticciare con voi stessi? Perché sono due approcci completamente diversi allo sviluppo, no? Eh, lo si fa, lo si fa.Ogni tanto ti capita di scrivere un Val a= in Python, ogni tanto ti capita di scrivere del Python in scala, però...Sì, sono approcci molto diversi, ho fatto tanta difficoltà quando sono passata su scala proprio a cambiare, passare dal paradigma funzionale, ci ho messo un bel po' perché è completamente un altro modo di pensare.Poi, oh, sì, ti capita di scrivere in un linguaggio, in realtà stai pensando all'altro e fai il mix, è inevitabile.No, perché quello che...Però alla fine penso che riesci a prendere il meglio di tutte e due, sai, perché anche per esempio in Python ci sono modi di scrivere in Python in maniera un pelo più funzionale.Io per esempio prima di usare Scala avevo questo vizio di considerare, prendere gli oggetti, te li passavi tra funzioni, mutavano tra una funzione e l'altra, poi alla fine non si capiva.Cose che adesso mi fa orrore perché c'erano ovviamente gli oggetti mutabili, quella è una cosa che mi sono portata dietro la Scala in Python, per ottenere una.a fine cerchi.Secondo me poi si riesce a fare un mix in cui si prende il meglio di tutti i mondi.C'è anche da dire che mi è capitato di vedere tanto Scala scritto in Java, nel senso che in realtà ci sono tantissimi, Carmine ride, ma ci sono tantissimi sviluppatori.Io per esempio ho discusso a lungo con mia moglie proprio dopo aver visto del codice fatto dai colleghi e lei ha ha provato a fare una battaglia all'interno dell'azienda contro questo Java style Scala che però è presente in ambito, uso un'altra parola che ama molto Carmine Enterprise.Io per convincere un mio ex capo ad utilizzare Scala gli ho scritto una cosa con Java utilizzando Wavr come libri e mi ha detto mi stai stendendo per il culo e a questo punto fai Scala e non Ma ci prendiamo un giro, quindi nel senso...Sì, sì.Mi è fatto in mente anche quello che è successo ieri sera, in realtà, di quando si programma in un linguaggio, ma si pensa ad un altro linguaggio.Quello che è successo ieri sera, mi ha detto "ma perché queste struct in TypeScript hai il campo con la maiuscola?" Perché avevo finito di fare Go poco tempo prima e in Go l'unico modo per esportare un campo da una struct è metterlo appunto con la lettera maiuscola.quindi sì, è una cosa che mi capita spesso.Però sì, anzi.Ecco, vedete, il vantaggio grosso che ho io ultimamente che faccio Kotlin è che se tu lavori in un linguaggio scritto da gente che di mestiere fa gli IDE è che se tu scrivi Java in Kotlin IntelliJ te lo dice e ti dice "guarda che la forma idiomatica Kotlin di questa roba è quest'altra e ha molti autocompletamenti di questo tipo".Guarda che migliori da ora, Coll! È verissimo che si può scrivere...Tendenzialmente io credo che una grossa parte di noi scriva il primo linguaggio che ha imparato in tutti gli altri linguaggi che impara poi.È una cosa che richiede un grosso sforzo cognitivo imparare un altro paradigma di...e la mentalità e la forma idiomatica di un altro linguaggio.C'è un libro molto bello su questo tema che si chiama "Seven languages in seven weeks" e ti spiega proprio che se tu impari sette linguaggi in sette settimane ovviamente non diventi proficiente in nessuno di questi, ma solo per il fatto che sei esposto a sette diverse forme idiomatiche di fare la stessa cosa, perché poi gli esempi che fa sono sempre gli stessi, ma fatti nel modo idiomatico di ciascuno di questi sette linguaggi, apprendi anche una forma lentis diversa.è molto interessante sia così che anche con 7 databases in 7 weeks che fa praticamente la stessa cosa con i database bellissimo ci condividi i link assolutamente sì sai che 7 linguaggi in 7 settimane l'avevi già proposto con me ballocco non io non tu? mi spiace ma non ero io no però KalaJS Scala JS, perché ora io voglio sapere l'opinione di ognuno di voi e se l'avete mai utilizzato.L'ho utilizzato per un po' che è stata un'esperienza di sofferenza, perché stavo scrivendo una cosa, però in realtà ne dovevo scrivere un'altra, è stato veramente stranissimo.Io non l'ho mai usato.E hai fatto un uso.Non mi pronuncio.Io ho visto Kotlin.js delle volte, l'ho guardato e ho fatto "ehh" e sono scappato malamente.È un'idea romantica ma no.Quanto lontana da Elm? Io non parlo.il suo nome helm è proprio brutto, proprio brutto, ma brutto proprio, dici, cioè brutto, cioè a questo punto lo faccio in Reason o in Redscript, se vogliamo dirlo come si chiama ora e lo posso fare anche con React, piuttosto utilizzare helm come sostituto di React, non è una sintassi che non mi piace, la trovo veramente, veramente ostica, però io sono un umile bracciante di questo mestiere, quindi probabilmente è un problema mio, insomma, ci sono persone invece che lo apprezzo tanto, come anche Flutter, a me non piace, però ad esempio so che è un grandissimo fan di Dart, Mattia, invece a me non piace.Dart come lingua non mi piace, Flutter in sé è differente.Raga con questa uscita su Flutter abbiamo perso il 20% della community.Allora facciamo sì questa parte la possiamo tagliare dove dico che Flutter Web è un vadin che ce l'ha fatta adesso è più così però ora sto zitto.È un vadin coi soldi di Google.Se volete vi parlo di Jetpack Compose che è il coso per fare le interfacce in Kotlin che è una roba che a me fa lo stesso effetto di JSX che è tutto mischiato dentro e poi però è una roba che spunta Android, HTML e applicazioni native desktop con tutto mischiato Presentation, Business Logical e poi tutto l'altro ed è una roba che secondo me ci puoi fare del dolore proprio fisico.però va un sacco di moda, i potlinisti piacciono un sacco.Sì, che alla fine che tu si ritorni lì, vuoi usare lo stesso martello per chiodi diversi insomma alla fine, alla fine chiedo se è anche un po' quella cosa lì, almeno io penso così insomma, piuttosto che magari utilizzare diversi strumenti, ricicli il know-how in una cosa che magari non è proprio ideale.Arriviamo al momento tipico e topico del nostro episodio.Parliamo del Paese dei Balocchi.Il momento in cui i nostri ospiti davanti a una birra ci consigliano un libro, una libreria, un video...qualcosa che ha catturato la loro attenzione e magari è anche stato utile nel loro percorso professionale.voglio chiedere, qual è l'elemento che vuoi condividere con noi? Vi conduco nel paese dei balocchi.Ah, il paese dei balocchi.Io vi condivido un libro che ho letto qualche mese fa, che mi è piaciuto tantissimo, che si chiama "Range.Why generalists triumph in a specialized world?" di David Epstein, ed è un libro in cui parla di generalisti.Viviamo in un mondo in cui spesso si pensa che uno deve prendere una skill e andarci in deep dive, specializzarsi su una cosa, invece questo libro parla un po' di alcuni personaggi famosi, a 360 gradi, non è un libro neanche stato sulla programmazione, e parla un po' di questa tendenza di gente di successo che si è specializzata a tardi, hanno trovato il loro percorso tardi, però hanno avuto modo di giocare con tante tematiche diverse finché non hanno trovato quella su cui focalizzarsi.E questo di solito porta ad essere più creativi e anche ad integrare in quello che è il proprio lavoro anche magari degli spunti da mondi diversi che non sono letteralmente quello che si fa ogni giorno.e quindi ve lo consiglio perché dà un sacco di spunti.Bello, mi piace, no? È il famoso imparare a collegare i puntini, no? Sì, sì, sì, sì.Bello.Mattia, hai qualcosa per noi? Sì, ho un libro nuovo che in realtà, come tutte le persone brave che consigliano le cose sull'internet, non ho ancora letto, però mi sembra davvero interessante.È di un tizio che ha una newsletter molto figa che si chiama "Link molto belli", pubblica ogni weekend e ha una serie di link molto interessanti.Il libro si intitola "Come annoiarsi meglio".Il tema è che tutta la tematica della produttività estrema e dell'essere super efficienti ci ha un po' privati dei momenti in cui ci annoiamo.Spesso capita, quando uno si annoia, che ha quei momenti di serendipity in cui magari scopre cose nuove o approfitta dei momenti di noia per avere intuizioni o cose, come a me è capito spesso sotto la doccia di avere intuizioni di bug che ho sbattuto la testa tutto il giorno e poi sotto la doccia finalmente o quando esco a correre mi rendo conto del motivo per cui mi funziona una cosa.Quindi sono super curioso di leggere appunto questo saggio su come fare a gestire, a trovarsi dei momenti di noia e a come gestirli nella maniera migliore.Interessante.Anche questo, mi sa che l'acquisto e quei 15 giorni di vacanza sarà uno dei 30 libri che avrò da finire.Carmine? Allora, come balocco, in realtà è un talk che si chiama "The Clusterfuck Hidden in the Kubernetes Codebase".È un talk del FOSDEM del 2019, a cui ho avuto la fortuna di assistere come spettatore, sperando che ci si possa riandare l'anno prossimo, e praticamente parla dei mostri, insomma, che c'erano nella codebase di Kubernetes.E una cosa che non tutti sanno è che inizialmente era scritto in Java, ok? E quindi praticamente quando poi hanno fatto la transizione alla codebase Go, hanno dovuto avere a che fare con tantissimo, diciamo, code smell, perché, diciamo, la transizione dall'object orientere Java è stata fatta, diciamo, una transizione più o meno 1 a 1 a quello che è il Go.Quindi c'erano degli anti-pattern, delle cose che non erano affatto come dovevano essere e in questo talk sostanzialmente si racconta di come hanno fatto il refactoring di quella parte lì e come, diciamo, scrivere del Go ideomatico a partire da una code base che non era affatto ideomatica.secondo me può essere utile anche a chi non ha mai sviluppato Go, perché è una bella storia insomma, anche come la si racconta è qualcosa che ti appassiona e che ti fa capire come tutto non nasca già bello e già pronto, è già insomma flagship.Fantastico, anche questo link lo mettiamo nelle note dell'episodio.Il mio balocco, mio balocco è un balocco in progress.Da un'idea pazza della community di Gitbar nascerà a brevissimo una newsletter partecipata che parte dal gruppo Telegram e si autocomporrà e settimanalmente la riceverete proprio nelle vostre caselle email.Ci stiamo lavorando, ci sono pochissimi commit ancora ma contiamo di essere online.Carmine quando? Dipende da quando stanno sentendo questi video qui, per stare proprio larghi direi tra un po'.Io appunto avevo a dire quando è pronto.Quando è pronto, assolutamente.È pronto quando è pronto.Avevo il terrore che dessi una data consapevole del fatto che mia figlia che ha tre mesi ha un buco nero di tempo.No, però ci stiamo lavorando.Se volete buttare un occhio.Pensavo di ciascuno.Mia figlia che ha tre mesi sa che non bisogna dare le date.Sì, lei fa parte del gruppo No Estimate, no? Esatto.Al massimo ti dice SMLXM, tua figlia, quando le chiedi l'estime.No, ci stiamo lavorando lentamente ma ci lavoreremo e prima o poi avremo questa newsletter di Gitbar quindi se volete buttare un occhio ma soprattutto se volete darci una mano, la mano è ben accetta.Sulle note dell'episodio troverete il link di tutto.Pamela, grazie di essere venuta a trovarci.Grazie a voi, è stato un piacere.È stato anche per noi un super piacere bere una birra con te, una birra virtuale in questo caso.Penso che anche Mattia e Carmine siano d'accordo, no? Assolutamente sì, mi fa il piacere.Quando un ospite viene a trovarci nel nostro bar, sa che può tornare quando vuole, perché il GIT Bar diventa un po' anche casa sua.Quindi quando hai qualcosa di interessante da condividere con noi, o qualunque tipo di cosa riguardi il mondo dello sviluppo e dello sviluppatore/sviluppatrice la nostra porta è sempre aperta.Grazie tornerò volentieri.Spero che questo episodio vi sia piaciuto.È stato super piacevole farci questa chiacchierata con Pamela e soprattutto vedere un tool che in realtà è super interessante.Grazie anche a Mattia e a Carmine che da buoni bevitori sono venuti a farci compagnia, anzi in realtà loro hanno le chiavi quindi...Io non mi tiro mai indietro quando c'è da bere.Assolutamente no.Dobbiamo dotarci di biliardo e freccette.E ping pong.per il prossimo episodio.Il ping pong fa assolutamente enterprise.Fa enterprise, però un enterprise misto con la startup, quella via.Grande benefit aziendale, ping pong è frutta.Frutta, senza frutta non sei veramente una startup.Ragazzi, l'estrattore dove lo mettiamo? L'estrattore alla Silicon Valley.L'estrattore lo mettiamo vicino al machinakiki.Abbiamo l'interior designer stasera.Grazie davvero ragazzi per tutto.Noi ci diamo appuntamento alla prossima settimana sempre qua su Gitbar.Se l'episodio vi è piaciuto, naturalmente per merito di Pamela, Mattia e Carmine, beh potete aprire github direttamente dalla vostra app di iTunes o Apple podcast e lasciare una recensione.qualora foste su android va bene lo stesso che se vi scrivete e ogni settimana verrete notificati automaticamente dei nuovi episodi.io sono stanchissimo infatti sto dicendo parole a caso quindi capisco bene che è arrivato il momento di ricordarvi contatti info@gitbar.it @brainrepo su twitter oppure il nostro gruppo telegram se non l'avete ancora fatto iscrivetevi e nulla allora alla prossima settimana ciao Gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
