Bene e benvenuti su Gitbar, un'altra settimana, un altro episodio e un altro ospite qua nel nostro circolo bar degli sviluppatori.Ma prima di presentarlo come sapete ormai è consuetudine vi ricordo i nostri contatti info@gitbar.it e @brainrepo per scrivermi oppure iscrivetevi direttamente al gruppo telegram e fatelo mi raccomando se non l'avete già fatto lo trovate semplicemente cercando github ma a bando alle ciance ci prendiamo una piccola pausa e ritorniamo subito subito per presentarvi il guest developer di stasera benvenuti su github il podcast dedicato al mondo dei full stack developer i mezzo artigiani, mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Facciamo una cosa, ve lo presento così.Viene dal design ma partecipa alle discussioni su spazi e tab.Con noi infatti abbiamo Davide Di Pumpo.Ciao Davide! Ciao Mauro! Bella presentazione, mi è piaciuta particolarmente.Mi è piaciuta soprattutto perché non sei riuscito a inquadrarmi bene, perché vuol dire che non è solo un mio difetto, anche io questo problema onestamente quando mi presento quindi ti capisco benissimo.Sì ho avuto difficoltà ti dico la verità anche perché il tuo background è molto eterogeneo ma piuttosto raccontaci tu chi è Davide Di Pumpo? Madonna mia che domandona basta che poi non mi chiedi dove mi vedo tra cinque anni perché Allora, chi sono? Se dovessi dire che lavoro faccio, ti direi che faccio il web designer, che per i più vecchietti d'ascolto ricorderà gli anni 2000 e qualche vecchia canzone.Per chi è più giovincello il web designer era quello che ai tempi faceva il lavoro del UX, dello UI, del frontend developer più qualche cosina magari di back end un po' soft anche un po' di marketing di SEO perché il web era molto più piccolo e si faceva un po' di tutto quindi è nel tempo in cui c'avevi, se eri un'azienda grande c'avevi non solo il webmaster ma anche l'IT e il web designer appunto.Questo è come mi sento.Oggi è un po' più difficile di dire, il mio titolo attuale, copiato dai ragazzi di Google, è UX Engineer, ovvero l'ingegnere dell'esperienza utente, che un pochettino fa, anzi mi piace di più e quindi mi occupo più o meno di tutto quello che l'esperienza dell'utente quando approda su un applicativo.Per lo più, per dirla facile, per il 50% del mio tempo sviluppo front-end, tranquillamente, per l'altro restante un po' faccio coordinazione tra i team, metto d'accordo back-end e front-end, faccio un pochettino di progettazione e ricerche e sviluppo, per dire la mia giornata tipo.So, ho anche un po' il pallino, come dicevi prima, su anche Spawn sembra strano, sull'accessibilità, anche per quello la lotta spazi tab è abbastanza divertente poi magari raccontiamo appunto un aneddoto alla fine così dipendiamo ancorati fino alla fine non so se va bene.Esatto leggendo le cose che hai pubblicato adesso non ricordo se fosse un post o un talk da qualche parte dici che ti senti un po' mastro in quello che fai.Allora la mia domanda mi viene automatica, no? So che tu vieni da un percorso di formazione umanistico che poi ci racconterai, ma cosa ha portato questo percorso di formazione al Davide che poi si mette a scrivere il codice? Ok, sì, sì, diciamo che c'è una formazione abbastanza mista perché non ho mai capito cosa volessi fare o meglio io faccio esattamente il lavoro che avevo deciso di fare ai 16 anni, su quello c'ho visto lungo ed è quello che volevo fare.Devo ammettere che soprattutto in Italia cercare nel '98-'99 di capire come formare un front-end developer/UX engineer è impossibile.Quindi, tolto il liceo che è stato scelto dai miei genitori, ho dovuto fare il classico.All'inizio ho fatto informatica.Ho fatto due anni di informatica, dove però ho mollato quando mi sono accorto che non avrei mai passato l'analisi di fisica.La cosa per cui ho studiato di più nella mia vita e ne ho ricovato un 14.È stato abbastanza devastante anche perché avendo fatto il classico la mia preparazione matematica era assai scarsa, ma quello è il primo motivo.Il secondo motivo era perché ai tempi, per chi se lo ricorda, il lettore dell'Università di Milano aveva fatto questo bellissimo articolo su White che diceva "il web è morto", nel senso che secondo lui il web era una bolla, c'era stata qualche anno prima la famosa bolla di internet, e quindi l'Università di Informatica di Milano nel 2003-2004 non credeva assolutamente al web come possibile futuro.Era una cosa che sarebbe passata momentanea e quindi la maggior parte della formazione formava gente per fare applicativi pseudo bancari, cosa di una palla estrema.Io volevo vedere quello che stavo facendo.Mi ero iscritto anche a corsi facoltativi tipo grafica 3D eccetera, ma si usavano software non dico obsoleti.Una delle cose che mi ricordo sempre è che per chi pratica la grafica un pochettino sa cos'è una curva di Bézier, soprattutto per quelli che lavorano con il vettoriale, c'era anche in informatica ai tempi la curva di Bézier, ma non è che ti insegnavano a usarla o cose di questo genere o come manipolare un SVG.No, no, io sapevo ai tempi, e l'ho fatto, adesso grazie a cielo non la ricordo più, proprio calcolare la matrice che genere una curva di piedi.Era per carità un'università molto interessante se nel caso io fossi diventato programmatore per Adobe e quindi avrei dovuto prendere quel concetto matematico e farlo diventare un disegno, però diciamo che non era quello che mandava.Avevo proprio voglia di fare siti, io volevo fare i siti web, questa era la cosa.Quindi sono andato a fare l'Accademia di Belle Arti, in realtà la nuova Accademia, un'Accademia di Belle Arti privata, perché c'era proprio un corso di web design, chiamato "I Tempi", dove c'erano tra tutte le varie lezioni che potrebbero andare da storia della cultura visuale a storia del cinema, a storia dell'arte, quindi un'università accademica standard, in tutti gli opzionali che c'erano possibili, c'era sviluppo, c'era HTML, c'era CSS, ai tempi c'era Flash, io ho imparato a sviluppare davvero con Flash, c'era Java, quindi i corsi che per chi voleva fare il web design erano fighi perché studiare a livello universitario ActionScript 2, ActionScript 3 era una roba parecchio figa, soprattutto se la mischiavi ai tempi con concetti come modellazione 3D, che poi ho proprio un po' abbandonato ma che mi sono ancora molti utili e avevo anche parte di animazione.Quindi una persona che ai tempi come me sapeva sia sviluppare un pochettino in art, sia sapeva disegnare con le curve di Bézier, con Vettoriale eccetera, era l'epoca di Flash piena, ti divertivi un casino, potevi fare roba abbastanza abbastanza impressionante e abbastanza divertente e quindi ho cavalcato fortunatamente quell'onda e sono uscito da quell'università come mastro, cioè chi è laureato in un'accademia diventa un mastro, un mastro d'arte e quindi questa cosa qui mi è un pochettino rimasta e secondo me fa parte proprio, ma non solo della mia persona, io per questa caratteristica la vedo molte persone che fanno sviluppo.Siamo un pochettino degli artigiani spesso e volentieri, non tanto solo per il lavoro che facciamo, anche per i progetti alternativi che abbiamo.Pensiamo a quanti di noi gli piace spugnare con un Raspberry, quanti di noi stanno lì a fare le cosettine con l'Alex, il Google Home, l'automotica e tutte queste cose qua.Ci abbiamo abbiamo quell'indole astigiana, quell'indole da tours, da makers, che effettivamente è figa e che in Italia abbiamo un pochettino nel sangue.Tant'è che c'è un illustratore molto bello per chi conosce magari Sandman, o lo conosce, che si chiama Dave McKeen, che dice sempre, lui è inglese, sta a lavorare in America e tutto quanto, lui si definisce in italiano un progettista, che dice che non c'è nessuna lingua che lui conosce se non l'italiano che raffigura bene questa tipologia di persona, cioè una persona che non progetta ma allo stesso tempo fa qualcosa, tipo fa il modellino, progetta realmente un'esperienza, perché chi conosce il macchina lui fa solitamente delle illustrazioni mettendoci colate di plastica, plastica, bamboline, fa delle costruzioni veramente progettuali e questo termine è intraducibile nel mondo, nell'inglese, designer è un pochettino diverso, non è proprio...è un po' omnicomprensivo la parola designer...si, designer è generico, puoi fare...il designer può essere...se scrivete designer su una tastiera per emoji vi viene fuori il tizio con il cappello d'artista e il pennello, così come uno può essere un designer di API, c'è veramente un cappello enorme.Un progettista invece è qualcosa di più grande.Io mi rifaccio molto psicologicamente a Munari, che era un progettista di mobili per lo più, mi scusassero i polisti, era però per far capire, cioè faceva design industriale, che secondo me è la cosa più simile a quello che fanno i frontender oggi.Non siamo né artisti che prendono la tavolozza e a petto nudo sul chiaro di luna disegnano un'interfaccia, né siamo gli operai di bassa lega, super specializzati per carità, che però abitano un bullone.Noi progettiamo e realizziamo un'esperienza che fino a poco prima non c'era, esattamente come chi progetta una serie, che ha anche uno scopo ben definito, che può essere una serie di design, una segna di luce eccetera.Abbiamo ancora un controllo sull'oggetto finale abbastanza ampio da poter fare tutto il pezzo.Anche quando facciamo solo un footer, un header, una card, siamo come il progettista che progetta una sedia che poi verrà messa all'interno di un progetto di interior design di una casa.Così se siamo molto bravi potremo addirittura progettare e costruire tutta questa casa facendo sviluppo alla fine, utilizzando non carta penna, legno, eccetera, ma anche soprattutto il codice.Il designer ha un metodo per cui, di fronte a un problema che la comunità gli pone oppure lui stesso trova che esiste un problema da risolvere, questo problema viene analizzato nelle sue componenti fisiche psicologiche.Naturalmente la componente psicologica chiama una verifica culturale, storico e geografica e può anche modificare lo stesso problema.La componente fisica chiama una verifica tecnica ed economica e anche questa può modificare il problema.Da queste verifiche e da questi controlli nascono i limiti del problema stesso.A questo punto interviene la creatività che è una sintesi che tiene conto del codice del fruittore e da questa creatività nascono dei modelli i quali subiscono un collaudo per cui si arriva alla progettazione dei dettagli del prototipo.Si condivido con te anche l'esperienza iniziale.Ricordo i tempi quando io ho fatto ingegneria, no? Di mattina si studiava Fourier e la sera si giocava con Flash, con ActionScript, con le prime funzioni che implementavano le physics, quindi i movimenti e gli effetti fisici.poi facevamo i nostri siti flash e magari li deploiavamo hackando con un po' di html in action dentro myspace non so se ti ricordi quei bellissimi periodi.Ti dico la verità la parola mastro a me piace tantissimo infatti davvero quello che ti consiglio sarebbe fighissimo vedere nel linkedin mastro in front-end, no? Sarebbe, credimi, fantastico.Ma perché mi piace così tanto? Perché in realtà il compito di chi fa UX e sviluppo front-end nello stesso momento, quindi nella stessa persona, non nello stesso momento, è un po' come l'artigiano.Cioè, oggi si spinge all'informatica, si spinge l'informatica affinché diventi sempre di più un processo industriale con l'affidabilità del processo industriale e con i meccanismi del processo industriale.C'è però un lato dell'informatica che come dici tu è il lato UX, quello più vicino all'utente, dove quasi l'esperienza è più tailor made, più costruita su misura sull'utente.E quale è meglio di una figura che è un artigiano, una figura artigianale può fare questo tipo di lavoro ed ecco perché mi piace proprio la parola mastro che ho sentito dire da te in un talk pubblicamente e che mi ha fatto subito innamorare di questa figura.Io penso che non so, cioè è un termine che mi piacerebbe molto se la gente acquisisse, almeno non mi vergogneria a metterlo su LinkedIn a quel punto.Spoiler, una volta ho fatto un giochino e per una volta alla settimana ho cambiato la mia qualifica su Linkedin, giusto per l'idea, e l'ho messo ovviamente mastro in italiano come titolo.No ma dico, secondo me non è solo chi si occupa di UX front-end che è un mastro, secondo me anche chi fa, cioè chiunque faccia sviluppo oggi, siamo ancora così fortunati da fare sviluppo sempre per un'altra persona.Anche se sei il becchendaro più infognato che con l'utente finale pensi di non avere nulla a che fare, tu stai facendo progettazione di un API che qualcun altro utilizzerà.Come garantire la risposta al del tuo servizio? È una roba di progettazione di veramente alta actualità, io per renderlo un po' più tecnico, forse questo talk, se tu rispondi con l'oggetto che ti è venuto in pasto, se fai secure address, se fai GraphQL o se fai REST, sono tutte scelte tecniche che all'utente finale, volendo, non vanno a impattare in nessuna maniera, ma che per un'altra persona, per un altro essere umano che ti utilizzerà hanno un sacco di valore e quindi alla fine anche quello è il tipo di artigianalità che secondo me, come dici tu, è giusto.Le aziende stanno cercando di toglierti un pochettino questa artigianalità perché è imprevedibile, non si può mettere a budget, è difficile da tenere, ma noi secondo me come categoria di lavoro dovremmo tenerci stretta.Io sono fidanzato con un'architetta e quindi mi viene facile fare l'affronto.Nessuno si sognerebbe mai di andare da un architetto e spiegargli banalmente su che tipo di foglio di carta disegnare, capito? O che marco usare, o che programma utilizzare per far quella roba lì, perché vai ad un architetto, scegli eccetera.Invece vedo che spesso e volentieri, visto che la maggior parte degli sviluppatori sono anche difficili a relazionarsi con altre persone, anche perché voglio dire, se passi la metà della tua vita davanti a un computer, io passo più di metà della mia vita da lucido, da sveglio, a parte il sonno, davanti a un computer, probabilmente le persone non mi piacciono tantissimo.Se la maggior parte delle persone sono così, hanno questo rapporto un po' conflittuale con gli altri filomani, noi subiamo un pochettino tanto questa cosa che vengono da noi e ci dicono "no, no, ma fai questo in questa maniera qui, eccetera" e questo ci condiziona.Secondo me un po' di quell'artigianalità dovremmo sempre tenerla.Se non il progetto principale su cui lavorate io almeno adoro farlo nei side project.Cioè tutti i miei project devono essere proprio di alta artigianalità ma veramente...gli ultimi side project che ho fatto per dirne una sono state dei lavoretti di falegnameria in casa, che ho fatto tipo una porta scorrevole in legno.Me l'han detto, me l'han detto.Sei un provetto fa legnare.Mi sono messo a fare tutto l'impianto elettrico con Alexa in casa in maniera che possa accendere e spegnere luci in condizioni varie, stupide, che quando...per dire, il mio albero di Natale si accende quando tramonta il sole.Fantastico.Così di questo genere qua.Oppure come il sito che ho fatto per la mia futura bambina, ho fatto un piccolo così che è fatto tutto in svg animate a manina una a una per prendere quella parte lì.Secondo me quella non dobbiamo mai perderla e purtroppo il mercato spinge verso quella roba lì perché si vuole industrializzare un po' di più.Io faccio sempre anche un altro esempio con il mondo delle auto.Le auto oggi sono un pochettino tutte simili cioè non c'è più la varietà che c'era tante o tanto tempo fa.Cioè se vai fuori più o meno le forme sono tutte rotondate, sono tutte...che è giusto, è ovvio, c'è la sua motivazione, cioè la guida è diventata una cosa da tutti i giorni, l'auto non è più un bene di lusso, bla bla bla, eccetera.Però un pochettino mi dispiace, un po' mi dispiace che si perda la personalità e si perda la progettualità delle cose è un pochettino bello è un pochettino per fare di nuovo l'esempio con l'architettura di prima magari adesso con l'interior design è un po brutto vedere tutte le case Ikea se vogliamo dire ogni tanto quel tocco lì secondo me è il nostro dovere dovrebbe essere deontologico come sviluppatori tenerlo tenerlo un po dentro.Sì una visione più che condivisibile anche se io ti posso dire che per esempio l'approccio industriale dovrebbe servire per dare un pochino più stabilità a un ecosistema informatico che per il più è fatto in modo veramente artigianale nel senso peggiore del termine perdonami.Quindi sì la parte creativa hai pienamente ragione dal mio canto però per esempio la monotonia dell'immagine spesso è guidata da un driver che è quello della struttura di produzione nel senso che oggi le macchine devono avere queste caratteristiche perché il controllo industriale sulle macchine è stringente cioè raramente si può sbagliare se non sei volkswagen che hai una cei particolare però capito da questo punto di vista però per quello che dicevo l'approccio artigianale nel front end ha maggior ragione perché è quello più human centric no? occhio sulla cosa occhio a non confondere diciamo l'artigianalità di qualcosa che perché non la sai fare ok? cioè non stavo parlando di arrabbattarsi le mani perché non hai conoscenza che è quello che industrializzazione ti toglie.Se io alzo il livello di industrializzazione e di astrazione di alcuni concetti è più facile che tutti ci arrivano.Quello è sacrosanto.Quello che dico io è che una volta che si hanno delle solide fondamenta, cioè l'esempio appunto qua, vi cito ancora Munari, una volta che si conosce bene il turismo, una volta che la sedia sei riuscita a industrializzarla abbastanza bene per che ti regga la persona, cioè quindi a quel punto ci puoi mettere il guizzo, ci puoi mettere quella cosa lì che la renda particolare, che la renda magari anche più adatta.Poi sì, per carità, ovvio che l'esempio delle auto è molto differente perché lì c'è anche tutta una questione di sicurezza sulla strada, è ovviamente una metafora un pochettino particolare.Cosa che ha senso è che non vedo in realtà tanto fatto per il web.Esatto, infatti mi riferivo a quello.Però anche su quello escono ancora oggi appunto macchine con delle forte personalità.Faccio l'esempio, anche se non bellissimo, di Elon Musk che presenta la sua versione di un'auto comunque ha creato...quando si vede una Tesla si vede qualcosa di diverso, c'è un concetto dietro.Per quanto poi quel tipo di cosa lì mi piacerebbe che sia condivisa e che non sia solo qualcosa che ti può tirare fuori Elon Musk di turno.Cioè non voglio che...bisogna aspettare il genio della generazione per vedere un sito un pochettino più figo o un'idea differente o una non conformazione.Anche perché in questi giorni sto giocando come dicevo prima cyberpunk, c'era una citazione in mezzo molto bella, non è spoiler tranquilli, è una citazione che è totalmente decontestualizzata e non è spoiler di nulla, che dice "il chiodo che fuoriesce viene martellato".Ecco, quella situazione lì a me non piace, mi sta stretta.Mi piacerebbe invece qualcosa di più di più variegato.Tra l'altro devo dire che la Delorean 4x4 mi piace tantissimo.Sì, appunto, cioè quel tipo di cosa lì...se siamo tutti maschio non la perdiamo.Vero e secondo me riusciamo a essere mastro anche nel back end come dicevi tu quindi sì la mia voleva essere quasi un'evidenziazione alla necessità di creare processi più stabili ma il fatto di non perdere l'artigianalità pura, quella che poi sarà pure un luogo comune ma a me piace ricordare e fa parte del concetto di italianità no? Che in realtà si può adottare anche nel back end e nel codice.Cosa porta un esperto di UX quando va a scrivere il codice? In primis una delle cose che ti porta parecchio...Dirò una parola così la capite, perché è difficile comunque...Una macchina a stati.Nel senso che una persona che fa sviluppo e fa design di interfacce, alla fine riesci a capire che ogni cosa che stai progettando non è troppo diverso da una macchina a stati.E mi spiego un po' meglio adesso dopo aver detto questa bella buzzword per attivare il cervello di alcuni che stanno bofonchiando lì dietro.Per dire, una delle cose che insegno io, ai ragazzi, mi insegno anche in alcune scuole, che insegno ai ragazzi quando si parla di progettare qualcosa, è ogni componente del web per sua stessa natura ha sempre minimo tre stati.Uno stato di caricamento, uno stato di pronto e uno stato di errore, perché il web tutto è, quando si parla di connessione, che è resiliente e quindi è possibile che tu stiai caricando una pagina, quindi c'è per forza, devi avere almeno un minimo di caricamento, anche se c'è la linea più veloce del mondo, basta semplicemente "little time" di 200 millisecondi per prendere la connessione, c'hai del caricamento, il pacchetto si può perdere, c'è l'errore, solo a un certo punto hai qualcosa di pronto e quel tipo di, sono questo tipo di accortezze di persone che sanno veramente come funziona un browser, che per me possono portare veramente valore alla progettazione perché nel mio caso io non mi dimenticherò mai di pensare a uno stato di loading di un componente non mi verrà mai in mente di fare ogni tanto l'avete visti loading a tutto schermo di tutto quello che succede non mi dimenticherò mai che in un momento forse è meglio fare optimisti qi o meno perché questo tipo di concetti per chi fa web sono abbastanza sono abbastanza sensati, a differenza di un tipo di progettazione che purtroppo mi viene da dire purtroppo va per la maggiore, che è quello di aprire il file sketch figma ma anche carta e penna di turno ed è quello di progettare l'HPAT, diciamo così, è subito quello che mi piace definire una visione utopistica dell'interfaccia dell'utente, cioè qualcosa che non vedremo mai nell'interfaccia questo tipo di approccio secondo me è necessario per fare una progettazione sensata.L'altro approccio che di sicuro lo sviluppo porta al design e alla UX è riuscire a capire come avere un minimo minimo di base di dati, cioè riuscire a capire qual è il flusso dei dati di un'applicazione ti permette di sviluppare, poi di progettare, un'applicazione che sia la meno peggio possibile, diciamo, perché non l'eccellenza? Perché spesso e volentieri noi, giustamente, una corrente giustissima che c'è oggi è quella del human-centered design, cioè io progetto il miglior path possibile per l'utente.Questo è il sogno di ogni progettista.Per quanto che poi ti scontri con il mondo reale, dove si sta progettando, facciamo per esempio una sedia, magari farla in vetro non è proprio una brillante idea, per quanto per l'utente sarebbe magnifico poter guardare sotto di sé senza nulla, ti metti a fare una progettazione di un servizio, di una UX fantastica, ma la base di dati che hai sotto non è forse così fantastica perché magari quei dati lì ti arrivano in SOP, il JSON che ti arriva è scompattato in maniera devastante e a me mi è capitato in vita di beccarmi le API di servizi esterni che mi rispondevano con 15 megabyte di JSON, capisci che questo tipo di situazioni ti dicono ok io ho anche progettato la cosa più bella del mondo, ma se capisco come funziona la base dati dietro, riesco a progettare il giusto compromesso tra la migliore parte, la migliore esperienza utente e il miglior modo per sfruttare quello che ho a disposizione.Ricito, visto che ormai tanto lo sto citando e c'è il mio cervello in background, Munari ancora, che fare gli esempi col bambù.Quando tu progetti una struttura con del bambù, devi capire che il bambù non lo puoi tagliare dove vuoi tu, perché c'hai i nodi, il bambù non lo puoi tagliare trasversale, perché si sfida.Quindi un progettista non è Dio, non può fare quello che vuole.Quello che succede delle volte invece è che si apre uno sketch, si mettono bottoni, tabelle, cose in giro, cose di questo tipo qua, però stai stuprando quello che invece è la base dei dati, il contenuto, Per carità, magari stai progettando un processo per l'utente meraviglioso, ma è utopistico, non si potrà mai avere.E quindi è una buona parte dei problemi che ci sono spesso nello sviluppare un'applicazione e che si arriva quasi alla fine e si vede "ah cavolo, ma fare questa roba qui non va bene" oppure dei problemi di performance dovuti al fatto che si fanno delle richieste al back-end che sarebbero state meglio in verso opposto, per ottenere un dato dell'utente, soprattutto se pensiamo ad una REST API, ma anche a un GraphQL, prima devo aprire l'ID, poi devo andare a prendere questo dato e poi insomma, quindi alla fine ho fatto quattro chiamate quando magari quel dato esporlo subito non aveva senso e quindi di colpo alleggerito il launch della mia applicazione di quattro volte, semplicemente con un'accortezza di questo genere qua.Guarda Davide quello che dici lo condivido e lo sposo appieno e ti devo dire anche che io mi porto appresso una bellissima esperienza lavorativa proprio in questa direzione.Stavamo infatti lavorando in un'applicazione e da junior qual'ero, il primo attacco che ha avuto quasi in modalità compulsiva era quella di andarmi a scrivere subito la struttura delle tabelle una volta capito il dominio.Ricordo che il senior di allora, molto intelligente, guarda Mauro tu devi respirare un attimo perché adesso chiamiamo l'esperto di UX fa un'analisi su quella che deve essere l'esperienza utente e in funzione di quell'esperienza utente tu avrai le informazioni necessarie per progettare la struttura dei dati della nostra applicazione non prima perché tu puoi pensare di inserire tutti i campi che ti pare ma se non sono utili nel processo se non esiste un hook per farli inserire o per fruirli, quei dati saranno dei campi nel database vuoti o se pieni irraggiungibili.E' arrivato la rovina! L'altra cosa che ti dico ancora se si vuole vedere tutto il cerchio è che chi però ha fatto la UX deve essere conscio del dato su cui sta basando, cioè alla la fine è sempre il dato utente quello che ci deve interessare di più.Ti faccio l'esempio, se nella progettazione fatta dallo UX, tavola bianca, posso progettare quello che voglio, abbiamo fondi infiniti, tra virgolette, se io progetto qualcosa ma non ho un dato dietro che mi dica ok, questo è il miglior modo di fare la cosa, ti faccio un esempio banalissimo, Formi di registrazione o email e password.Alcuni adesso li sdoppiano.Ha email, ha email e password dopo.E tu pensi che visto che il pattern è comune, di implementarlo anche nella tua cosa.E quindi sviluppi tutto il processo in quella maniera lì.Poi ti accorgi che i tuoi utenti non riescono a registrarsi.Perché avevi sgarra...Cioè, perché magari quel pattern che funziona molto bene in America, in Italia non funziona bene, perché la tua base di utenti è differente, perché il tuo target è abituato a quest'altra app più famosa che non lo fa in quella maniera e quindi devi iterare, c'è il concetto di iterazione nella UX che secondo me è importante quindi quando iteri a quel punto prendi quel formulo, rimetti tutto in un formulo unico dopo averlo separato quindi magari il back end deve fare delle modifiche, il front end non si trova Quindi è vero quello che dici, è la soluzione a tutto questo dramma, secondo me, che è quello che ha detto giustissimamente il tuo senior, è che bisogna parlarsi, che bisogna banalmente che tutta la filiera, ad un certo punto, parli e capisca che sono tutti dei progettisti per poter progettare il miglior prodotto per qualcuno.e contemporaneamente tu sei un progettista per quelli che ti stanno a fianco, perché come backhandel devi progettare la cosa migliore per il fronthandel, per servire meglio lo UX, che servirà meglio il data scientist, che servirà meglio l'utente, che servirà meglio il marketing, quindi tutta questa cosa qui alla fine se si pensa un pochettino come come ognuno mastro del suo, per continuare da questa metafora, ognuno mastro del suo settore è abbastanza figo.Assolutamente sì, vero.Quindi anche la parte diciamo di più strutturale, più tecnica di back-end deve comunque mettere dei constraint o comunque potrebbe mettere dei constraint.Per me è fondamentale, soprattutto in fase di start-up, di progetto comunque, in vari meeting paralleli, che ci sia almeno un responsabile per ogni area allo stesso tavolo, perché giustamente nessuno può sapere tutto, ognuno si blocca da qualche parte.Io mi reputo una persona che sa, avendo avuto questo background particolare, riesco un pochettino a navigare bene dal marketing all'API, però sono una capra totale in qualsiasi cosa che sia, infrastruttura, macchine, gubernizze, cose di questo genere qua, non ne capisco un h, e quindi prendere delle decisioni finali senza qualcuno che ne capisca, che se ne occuperà, secondo me non ha senso così come il fare delle scelte tecniche addirittura senza coinvolgere un attimino lo UX o lo UI di turno potrebbe non essere proprio geniale ecco.Sì mi piace visto che hai parlato tanto di architettura anche io in famiglia ho degli architetti quindi conosco benissimo la situazione e come dire l'architetto che o veste dopo poi i panni dello strutturista oppure si affianca a un ingegnere che gli farà i calcoli e gli dirà ok tutto questo ti pare ma il palazzo deve reggere.Esattamente quello, l'esempio dell'architettura secondo me è fenomenale proprio per quello perché quando costruisci una casa c'è l'ingegnere, c'è l'architetto, c'è il geometra, l'elettricista, l'idraulico e tutte queste persone sono in in cantiere insieme o comunque per dire io adesso ho ristrutturato casa a un certo punto cliente finale, ingegnere, architetto, muratore, eutraulico erano tutti seduti per capire come spostare questa tubatura perché è ovvio che in caso di imprevisto soprattutto come in quel caso c'era una tubatura che non doveva essere dove doveva essere tutte le parti coinvolte doveva mandire la sua perché il cliente magari non vuole una colonna in mezzo al corridoio, il muratore deve capire come abbattere il muro, l'idraulico, l'ingegnere deve capire se poi questa roba regge o allaga i vicini e l'architetto deve fare una roba che non è un pugno nell'occhio da vedere.Tutta questa roba qui secondo me è una cosa che spesso vedo molto sottovalutata in molti ambiti, molti ambiti agile per dire non c'è lo UX o il data science all'interno della stessa struttura.Ci sono poi, poi li trovate su Google a manetta, fior fior di articoli per fare aziende, non stiamo dicendo nulla di diverso secondo me da com'è composta Spotify che c'ha i chapters, le tribe e quella roba lì per cercare anche in questo caso ingegnerizzare quel tipo di processo.Sai che quello che dici mi piace tantissimo perché è un concetto che sostengo da diverso tempo che è appunto il concetto anche se vogliamo estremizzarlo dei team cross funzionali questa cosa molto comune per chi sviluppa magari micro front end giusto per mettere un'altra buzz word nel calderone cioè il team dove c'è il frontender, hai lo UX, hai l'esperto di dati quindi il data scientist, il backender e fanno un piccolo slice che è un piccolo slice verticale di quello che è tutto l'ecosistema però affrontando il problema da testa a pieno ed è un approccio dal mio punto vista moderno è anche efficace in ambienti medio grandi no? Si si si, concordo 100%.Volevo farti un'altra domanda invece visto che abbiamo parlato tanto di progettazione.Oggi, dal tuo punto di vista, nel 2020 qual è il processo che porta dal design allo sviluppo di un prodotto web funzionante dalla tua esperienza? Anche questa è una bella domanda, dovresti farti scrittore per Marzullo.Allora, prima di tutto io ti direi che la cosa fondamentale e va ancora prima di iniziare a fare progettazione validare le idee, cioè validare che quello che si stia iniziando a fare è la cosa giusta e il modo giusto di farla.Su questo vorremmo fare 20.000, per esempio c'è l'intera scienza che adesso è quella appunto di l'insta-startup e tutte quelle cose lì per dirla.Quella parte lì deve essere fatta secondo me anche quando si parte da un app, non solo quando ti crea la tua startup, ma anche quando crei la nuova feature.Vedere, validare se quell'idea lì ha senso, perché non c'è niente di più brutto che rilasciare un prodotto e poi nessuno te lo guarda, non funziona e tu magari hai fatto una roba splendida e nessuno ti valida.È molto meglio buttare su qualcosa subito, immediatamente, il famoso "fail quickly", cioè fallisci rapidamente, che è mettersi lì a fare i brainstorming, le idee, fare rilasci monolitici, anche la questione di fare piccoli pezzettini è figa anche in fase di validazione.Quindi fatto quello, ottenuti dei dati, la parte migliore da fare, ho detto una bellissima frase, quella lì di prima, una parola che ma ci sono un po' di no, è quella di capire appunto il dominio.Capire appieno il dominio, sempre anche questo è un processo collettivo di team, e capire un attimino, non mi viene adesso la traduzione in italiano, ma è una maledizione che leggo solo testi in inglese sugli argomenti, che il behavior, il comportamento esatto, che ci aspettiamo, che l'utente voglia fare per risolvere la sua problematica, perché alla fine è quello che facciamo, risolviamo i problemi della gente.Siamo moderni Mr.Wolf oltre che morti.Tu sei Jimmy giusto? È casa tua? Sì, proprio così.Sono il signor Wolf, risolvo problemi.Bene, ne abbiamo uno.Me l'hanno detto, posso accomodarmi? Sì, la prego, entri.Quindi fatto questo si può iniziare a...Una volta che abbiamo questa roba qua, a me piace fare uno user flow, ok? Che è molto...quindi per dirvi la forma, all'inizio sono molto dei post-it di cose che devono avvenire perché tutto succede perfettamente.Questi post-it poi diventeranno dei wireframe di bassissimo livello.Per wireframe intendo proprio che tipo non c'è manco destra e sinistra, sono grossi come una card di zoom per interceppo, piccolissimi, dove se al massimo c'è scritto "l'input nome cognome il tastone", questo tipo di roba qua in maniera che si inizi a capire più o meno tutti quanti a concretizzare qualcosa.Alcuni lo sconsigliano eccetera perché è ancora troppo famoso, ma secondo me se a un certo punto non inizi a far visualizzare alle persone qualcosa, ci si perde, poi non si sa più di cosa si sta parlando e cose di questo genere qua.Da questa parte qui si va, che è molto orizzontale, immaginatevelo come un flusso, quindi orizzontale c'è una freccia che parte dalla sinistra del vostro foglio immaginario e va progressivamente verso la destra per noi che siamo in left to right come modalità di scrittura.Fatto questo in orizzontale, sull'asse verticale dall'alto verso il basso invece si può iniziare a pensare appunto a tutta la parte di modellazione del dato, di come può essere fatta la UI eccetera eccetera.Quando si ha tutto questo malloppone qui gigante a cui abbiamo collaborato più o meno tutti, si fa la cosa più bella e più brutta contemporaneamente, si va via con l'accetta, si tolgono tutte le features che nel frattempo sono state reputate inutili per ottenere l'obiettivo che ci si era professato all'inizio con i dati che si erano presi o anche se sono dei dati con le assumption che ci si era data all'inizio.A quel punto lì se la feature è abbastanza piccola si inizia a sviluppare quella feature si fanno le user story, se c'avete le gira si fanno i task, si finiscono le sprint, più o meno una deadline per ogni cosa, blablabla.Altrimenti c'è ancora un altro processo che è quello di spacchettarla in singole single feature, possibilmente scorrelate, con anche parti manuali, la registrazione si può fare a manella e un pezzettino lo puoi fare con la landing page, quell'altro flusso lì ti mandi il pdf, altri...cioè ci sta anche fare questa roba qui in maniera da capire subito quali siano le parti che non funzionano nel flusso, perché ripeto, l'iterazione secondo me è fondamentale.Nel mio lavoro, io lavoro alla fine in una società diciamo parabancaria, diciamo così, una start-up, scale-up, strafiga e tutto quanto, radioflessibile, tutte quelle cose californiane, diciamo così.Per carità però alla fine sono quattro anni che lavoro qui, ho scritto qualcosa come 20 volte il flusso di registrazione dell'utente.Perché i primi dieci erano sbagliati, posso dirselo che erano sbagliati secondo me, adesso siamo andati molto meglio, adesso invece andiamo sia da un certo punto di vista a migliorarlo sempre di più, ad aggiungere feature.Il primo form chiedevamo un sacco di dati, adesso abbiamo automatizzato un sacco, quindi quando tu inserisci un dato andiamo a chiamare le determinate banche dati per sapere qualcosa e non chiedertelo più, ti facciamo delle proposte, ci facciamo dei pezzi di controllo prima o dopo, ti facciamo già vedere l'input precompilato con il dato giusto, tu devi cliccare solo avanti se ti è piaciuto e tutte cose di questo genere qua.Quindi è un'interazione costante per migliorare quel processo, che nel mio caso è la richiesta di un finanziamento per una società, quindi un B2B, una roba abbastanza complicata, renderlo il più l'inne e più facile possibile che risolva nella maniera migliore questa problematica e che sia anche, tra le altre cose, conforme ai tempi.Un finanziamento oggi nel 2020 è diverso da quello del 2019, vista la pandemia e 3 o 4 ordinanze che ha fatto l'Unione Europea.Quindi questo tipo di cose qua, quando si itera costantemente le assorbi molto meglio.Diciamo che tra l'altro i vostri flussi sono anche diciamo in alcuni passaggi abbastanza complessi anche perché spesso non si richiede a chi offre quel a chi opererà il vostro software di essere un esperto tecnologo come invece in altri ambiti è possibile chiedere? Assolutamente, la cosa brutta è che poi hai sia il tecnologo sia quello che non ne capisce proprio niente e quindi per alcuni il tuo flusso è proprio boring, lungo, troppe parole, che palle, non c'ho voglia di leggere, è ovvio che sia così.Dagli altri invece c'hai della gente che proprio non ne sa nulla e gli devi proprio scrivere clicca qui se vuoi fare questa azione che ti sto dicendo da quattro pagine.Verissimo.Allora fino a una decina d'anni fa facevamo delle enormi pagine html da 500 righe poi un bel giorno è entrato nella nostra vita il framework backend che ci permetteva di dividere le pagine in blocchi e di riutilizzare i blocchi mi viene in mente il twig ma ce ne sono tantissimi di linguaggi di templating che ti permettevano di fare questo.E tutto ad un tratto nel mondo frontend si affacciano i componenti.Ad oggi cosa sono per Davide i componenti? Come li piega nel suo lavoro? E se usiamo un'altra buzzword visto che oggi stiamo andando...le stiamo distribuendo a man bassa è come vede Davide il concetto di Atomic Design nel suo lavoro di tutti i giorni? Ok, allora veniamo un attimo a noi.Diciamo che una delle cose che faccio sempre per dire che i componenti sono sempre stati tra noi in realtà, solo che non ce ne eravamo accorti, è pensare al tag immagine.il tag immagine HTML è una cosa fighissima, tu gli dai un url, quello fa la chiamata, trasforma quel blog in qualcosa che tu vedi, un altro componente che abbiamo sempre usato e non ci siamo mai accorti è la select che è un comportamento ben definito e alla fine è un componente che tu metti lì e addirittura in molti browser fuoriesce dal motore di render del browser e attiva quello di sistema, quindi la Select è un componente di quelli seri ragazzi, Serious Business.Non ce ne siamo mai accorti perché purtroppo noi ereditiamo il nostro mindset, ereditavamo come designer proprio, come progettisti, il nostro mindset dai libri.Io ho lavorato in Feltrinelli editore per cinque anni, ho fatto un casino di e-pub e posso dirvelo parecchio.Questo perché, lo sappiamo tutti, senza far tutta la storia, il web nasce per fare dei documenti per testuali di accademia, quindi abbiamo semplicemente riprodotto una biblioteca messa su una rete telefonica.Era anche il modo in cui si spiegava l'internet all'inizio ai più anziani.Cioè il web è un'enorme libreria di tutto lo scivile umano che viaggia sul telefono, per buona pace di quelli che vendevano le enciclopedia porta a porta.Quindi detto questo a un certo punto ci siamo accorti che no, esattamente come qualsiasi altro prodotto artigianale, per tornare alla metaforia prima, il web era composto da vari pezzi.Per quanto alla fine facciamo delle pagine web, queste sono composte da delle strutture componentizzate, ma anche se facciamo un semplice foglio di testo, l'H1, l'heading è un componente, così è una pagina, è un componente che le conti con un paragrafo sopra la pagina, sopra il sito, quindi questa ristrutturazione è comune a qualsiasi struttura umana, se vogliamo, la sedia, cioè i piedi, lo schienale, la seduta, la casa, cioè le porte, le tubature, i muri, bla bla bla.Quindi abbiamo semplicemente preso e ci siamo un attimino capito che ok, il web è abbastanza maturo per non copiare più una struttura che è quella di un libro, che è un oggetto abbastanza inerte, ma possiamo farci determinate figate.Lì sono nate tutti i vari concetti.Io direi che fino a qualche anno era un'idea comune, come tu ci hai citato, Atomic Design di Brad Frost, che ha avuto un impatto abbastanza devastante sul mondo di come concepivamo queste cose qua che ci ha fatto aprire un po' gli occhi e dire cavolo ma io è possibile che come frontender devo riscrivermi lo stesso pezzo 200 volte devo ancora concepire le pagine come dei template top down cioè noi prendevamo le pagine ci infilevamo dentro dei pezzi con twig, io ai tempi mi ricordo con tanto affetto Handelbars, e cose di questo genere qua.Poi aveva arrivato Angular e Angular nonostante ci avesse, di AngularJS per non confonderci, nonostante ci avesse delle buone intuizioni fenomenali sulla componentizzazione cercava ancora non aveva capito veramente il problema, stava cercando di dare un colpo al cerchio e uno la botte.AngularJS ha cercato di risolvere troppi problemi tutti troppo contemporaneamente e quindi è uscito fuori sia come risorse impiegate, sia come bellezza della scrittura, alla fine scrivevi...il mondo non era ancora pronto a qualcosa del genere.Qualche anno dopo è arrivato React che ci ha avuto anche lì un altro piccolo guizzo, secondo me, nella direzione giusta, che era quello appunto del "tutto è un componente".In React questa cosa qui era abbastanza disraptive, qualsiasi cosa è un componente e alla fine la gente ci si è trovata bene per un semplice motivo, secondo me, una cosa abbastanza fondamentale.Se tutto è un componente, tutto ha un nome.Se tutto ha un nome, per noi è più facile riuscire a parlare di quella cosa lì.Se riusciamo a parlare di qualcosa vuol dire che, visto che pensiamo parlando, riusciamo a pensarci parecchio.parecchio.Può sembrare una cosa stupida, però molte metodologie, una delle famose cose che si dicono sull'usuario, non mi ricordo di chi ha la citazione, ci sono solo due cose difficili nell'informatica, invalidare le cache e dare nome alle cose.In una struttura componenti tu sei costretto a dare nome alle cose e ti viene assolutamente più facile.Quindi è quella la cosa, un componente ti permette di astrarre concetti molto difficili dandogli semplicemente un nome.Io adesso se vi dico banalmente una card di prodotto, quindi product card, questo pezzo qui, io vi ho di colpo nel cervello acceso almeno un concetto di qualcosa e una product card in realtà non è un concetto così facile perché dentro potrebbe esserci il carrello, potrebbe esserci la foto, potrebbe esserci la descrizione, potrebbe esserci il titolo, potrebbe esserci la quantità, il prezzo, vedete, cioè è veramente difficile da descrivere una product card, però la chiamo product card e ho finito.questo paradigma di pensiero ancora prima, che in realtà nel web c'è sempre stato perché l'html alla fine quello è un "p" è un paragrafo, un "strong" è un elemento in line, questo che c'è stato secondo me ha proprio fatto quasi dire a tutti, me incluso, "ma che cosa stai...cavolo giusto?" e quindi abbiamo iniziato a progettare a costruire tutto molto component base adesso il front end tutto è un componente non solo se si usa React ma ci sono Web Components, Angular ha le sue cose, Vue ha le altre e via discorrendo Devo dire che in realtà come dici tu anche un'altra utilità è quella della riusabilità che insomma ci ha aiutato tantissimo E quando la riusabilità si sposa con contesti un po' più complessi dove non sei da solo a lavorare oppure devi lavorare col te stesso tra sei mesi hai bisogno di un sistema per accentrare custodire e spiegare il comportamento di questi tool.Uno di questi si chiama Storybooks io ti ho sentito parlarne però tu lo usi? Se sì, in cosa ha migliorato la tua esperienza, il tuo lavoro e soprattutto cos'è per te Storybook? Ok, come dicevo all'inizio della trasmissione ho fatto il classico e quindi c'è una parola che adesso chi ha fatto il classico ricorda che è "il rocci".Il rocci era un dizionario per tradurre le versioni abbastanza devastante.Perché esattamente come dici tu, quando si utilizza, quando un linguaggio si evolve, ad un certo punto abbiamo bisogno di dare sia la collezione di parole, diciamo, di raccogliere qualche pasta e Storybook per me in primis mi ha aiutato in questo.Ci sono varie cose.Io adoro Storybook proprio in maniera esponenziale, lo utilizzo tipo dalla versione 1, da quando l'ho visto.Ho sempre cercato un tool come Storybook, anche nella vecchia azienda in cui lavoravo non c'era Storybook, cercavamo di fare...noi lo chiamavamo Kitchen Sink, ok? Il lavandino della cucina dove c'è tutte cose per cucinare.Mi ricordo ExtJS o Sencha.Esatto, Sencha c'era anche Kitchen Sinka ad esempio, ma ce l'aveva pure penso GQ e UI, questo concetto foundation, li chiamavano proprio Kitchen Sinka ai tempi, come la tua cartuccera con tutti i...la tua batticintura, ecco, quella roba lì.E quindi La cosa in cui mi ha aiutato in primis Storybook è stato parlare un linguaggio comune con tutte le persone di cui dicevo prima.Perché io adesso, quando in azienda dico "Li ci metto una product card", c'è lo UX che sa di cosa sto parlando, c'è lo UI che sa di cosa sto parlando, il front-end sa perfettamente di cosa sta parlando, il back-end ha un'idea.Quando arriva uno nuovo, una persona nuova, può andare a vedere di cosa si sta parlando, quindi è veramente un dizionario comune che ti permette di evitare ogni volta di dover specificare come è composta una product card.Lo dici, detto fatto.Le altre cose, quindi tolta la parte di progettazione, di semantica, è ovviamente uno strumento figo perché ti permette di fare una cosa molto molto importante.La prima è quella di prendere uno dei concetti che più mi piace dell'informatica, ma che mi piace anche nella vita vera, è che il buon codice è il codice che puoi cancellare.Cioè, cosa ti permette di fare storybook, storybook ti permette di isolare perfettamente un componente capendo subito se questo ha delle dipendenze con altri componenti.Questa roba dell'ISP perché se io avendo tutte le dipendenze del progetto storybook correlate tra di loro se cancello un pezzettino non devo ristallare le dipendenze, non devo farci subito, vedo che c'è qualcosa che non va quindi riesco a capire qual è l'alberatura delle dipendenze di tutti i miei componenti ma avendo un componente totalmente lì isolato totalmente bello nella sua senza nessuna roba esterna posso fare dei componenti più resilienti perché non mi abitua ad avere quel tipo di dato perché lo sto già sviluppando in piattaforma e soprattutto cosa molto importante che è l'ultimo pezzo per quello dello storybook più testabile perché a quel punto senza dover buttare giù architetture, kubernetes e via deploy eccetera su veramente un html abbastanza scemo posso su una paginetta posso testare come il responsive e se passa l'accessibilità e se passa gli unit test e se passa regression test perché è un ambiente piccolo controllato ci puoi lanciare sopra un sacco di roba ed è abbastanza semplice e veloce.Infatti la mia domanda immediatamente successiva era esattamente sul testing, perché mi ci hai accompagnato.Ho detto sul testing io, qua dico una di quelle cose proprio che poi mi insultano ogni tanto mi succede, non sono un grandissimo fanatico sul front end degli unit test perché sono molto...per me i front-end dovrebbero essere il più resilienti possibile, dovrebbero avere poca logica e messa tutta in punti ben definiti.Mi piacciono gli unit tests quando hai della logica a front-end anche ben isolata, che però stanno un pochettino fuori, secondo me, queste cose da storybook.In storybook io avrò 100 componenti, 40 unit test, una roba del genere.Perché i componenti praticamente sono abbastanza appunto stupidi, sono delle cose che...La card, cosa devo testare? Che se ho messo l'immagine, l'immagine si veda? Si, non lo fai con l'unit test.Sulla parte di testing ci tengo a ricordarvi che un po' di tempo fa a giugno ho registrato una puntata dove parlavo di Cypress e su quella puntata in realtà c'è una piccola provocazione che dice appunto che sposa un po' il mio modo di vedere le cose, lato front end salvo alcune giunture, le immagino come il ginocchio, salvo alcune giunture che secondo me è necessario testare unitamente, quindi fare unit test, tutto il resto secondo me si può fare tranquillamente come test di integrazione in complesso e quindi è un po' un ribaltare quella famosa piramide del test ormai famosa che si legge dappertutto.Però da questo punto punto di vista mi sembra di capire che anche tu sposi questa...Io sposo appieno questo concetto qua, anche perché l'acconto, quando io ho iniziato, in realtà non sono un fan di Cypress perché uso TestCafe, però il concetto è esattamente lo stesso.Mi piacerebbe in realtà fare molti più test su TestCafe, comunque per un end, purtroppo hanno un costo abbastanza evidente ma quello possiamo fare in un altro di talk.Esatto.Lunghissimo.Uno dei bug più grossi che ho mai avuto in produzione era dovuto al fatto che appunto come dicevo prima un'immagine ok che era stata caricata avevamo usato noi avevamo questa pagina fatta già con CSS grid che aveva questa CSS grid con delle immagini sopra che venivano indimensionate in CSS grid bla bla bla e sotto c'era il tasto la CTA principale che dovevano cliccare gli utenti.A un certo punto non funziona più sta roba qua perché? Perché Chrome aveva cambiato come le immagini si comportavano all'interno delle CSS grid, erano proprio gli early days e quindi le immagini sforavano e andavano a sovrastare questo pulsante ok? da un giorno all'altro.Quindi gli utenti non potevano più cliccare su quel tasto perché sopra c'era un'immagine, proprio non si vedeva sto tastone e quindi poi gli autunno c'erano le suite di test che andavano, non capiamo perché si è ridotto, la gente non clicca più su sto cavolo di tasto, abbiamo sbagliato i test in produzione non ad lib e va a vedere quello.Alla fine è una roba che con un regression test, visto che Cypress, ma anche Test Café, non vanno a cliccare il nodo del DOM, come invece fanno gli unit test di React per dire, ma vanno proprio a muovere il mouse e a cliccarci sopra.L'anno di quando un test di quel genere ce ne saremmo accorti subito della regressione che ce l'ha stata.E quindi sì, per me molte cose per molte cose uno unit test cioè un test di end to end è molto molto più comodo.Io guarda condivido l'ho parlato ne ho parlato proprio in quell'episodio mi sa che se non ricordo male era l'episodio 25 comunque ve lo linko nelle note dell'episodio tra l'altro ho ho letto che molti in ambito front-end dicono che lo stesso valore del test, anzi forse anche di più, è dato dal raccogliere le metriche di quello che sta succedendo nel tuo front-end.Tu hai mai avuto esperienze da questo punto di vista? No purtroppo, nel senso a me, no, questa è la forse la giusta.Allora c'è una libreria che io ad occhio da un po' che voglio usare, scritto da una persona, da un italiano anche se sta all'estero, che voglio molto bene, che è Leonardo Di Zamia e si chiama Parfum JS, che ti misura quanto, puoi usarlo per misurare quanto tempo ci mette proprio a fare un'attività, il tuo front end, ma proprio l'utente, tu per dire, puoi capire quanto tempo ci mette il tizio dopo aver cliccato un tasto a vedere il tooltip.Facciamo un esempio, quel tipo di faccenderie mi intriga parecchio, non sono mai riuscito alla fine a metterci più di tanto tempo, ma ci sono alcuni settori in cui lo vorrei fare.Ho detto "ni" perché invece per altre parti tipo la suscitata la suscitata form di application per fare il finanziamento di qui sopra sono abbastanza maniaco per vedere i numeri ogni volta che c'è un rilascio quanto è migliorato quanto meno tempo ci mette proprio l'utente finale nemmeno il browser.Cose invece su cui sono abbastanza fissato quando si fanno i test di quel genere sono i budget test cioè capire se la pagina che stiamo mettendo su supera un determinato peso di computazione, di performance diciamo così.Ok, te lo chiedo perché anch'io non ho mai utilizzato strumenti di questo tipo salvo alcuni software che magari misuravano il click sulla giunta al carrello che magari era della logica che girava solo solo lato front end però molti parlano e dal mio punto di vista hanno ragione parlano appunto del concetto di observability del front end che è una cosa che mi piacerebbe veramente.Io voglio farlo da Dio però è una di quelle cose che richiedono sia tempo sia nel mio caso anche numeri.L'applicazione nostra ha numeri abbastanza bassi, parliamo di centinaia di utenti al giorno, quindi non è che riesce a fare delle oristiche veramente veramente fighe.Il gioco a un momento ancora non vale la candela, per 100 utenti faccio veramente prima chiamarne 10 al giorno che a mettere solo a struttura.Assolutamente sì, vedi questo è il tipo di pragmatismo che alle volte cerco di evidenziare nel gruppo Telegram perché spesso siamo talmente presi, siamo geek, siamo talmente presi dalle tecnologie, dai giocattoli, che rischiamo di dimenticarci questo tipo di pragmatismo dato dal contesto.Sì, sì, associo con questo.Guarda, con me sfondi una porta aperta.Tutti noi l'abbiamo fatto almeno una volta, è incluso almeno migliaia di volte che abbiamo sparato alla mosca col cosiddetto cannone.Quello è una delle cose.Saper usare lo strumento giusto al momento giusto con le aspettative giuste secondo me è una delle vere differenze tra un junior e un senior.Ti faccio una domanda adesso questa la faccio veramente giusto perché fa molto buzzword no? In una battaglia tra React, Angular o Vue, chi dal tuo punto di vista naturalmente quindi fortemente opinionato, chi sopravvive e perché? Allora risposta per me giusta è Web Components perché non si va mai via dagli standard.alla fine, per me, se devo fare la scommetta, nel futuro vinceranno.Se devo dirti una mia scelta personale, ad oggi io preferisco React ai tre perché ha sicuramente un approccio molto più modulare, che è una cosa che io preferisco.Io non sono un grande adoratore di approcci a framework, cosa che Angular è.Quindi per me Angular è già respingente perché ha il suo modo di fare, invece a me piace fare le mie scelte, vedere le mie cose, poter cambiare rapidamente, mi ha sempre portato bene in vita.Pensate anche semplicemente che come ho detto io ho iniziato come Flash Developer, il mio fallimento della tecnologia l'ho già vissuto ragazzi.Dopo Dopodiché mi sono buttato come AngularJS developer e anche lì posso dire che se domani mi muore React, React per me è semplicemente...per carità, devo fare un lavoro devastante, però soprattutto adesso con l'introduzione di Lux, per dirne una, tutta la logica è là, devo fare solo le...Le chiamate? Sì, ma nemmeno perché le chiamate le faccio con Apollo, con GraphQL, devo rifare solo la UI.Essendo GSX molto simile ad HTML, mi aspetto, tra l'altro essendo GSX ormai è diventato quasi un linguaggio a sè stante, mi aspetto non questo grosso dramma.Tant'è che noi usiamo molto, da me, si usa molto spinto JavaScript, gli UX infatti sono state una cosa che ci ha proprio cambiato la vita, perché quasi tutte funzioni infilate negli UX che fanno cose poi, e poi React mette solo la UI.Non mi dispiace in realtà nemmeno tanto Vue, e ammetto di averci pensato un pochettino, non l'ho mai prepreso troppo in considerazione, perché io poi devo assumere gente anche e già vi assicuro che è difficile trovare sviluppatori React in gamba se ci metti un framework, cioè una libreria che è usata anche un po' meno mi diventa un po' difficile o anche banalmente se c'è un problema, una delle cose che faccio io, vedo lo stesso problema delle volte quando faccio un framework quante risposte trovo su Stack Overflow perché quella è un'ottima...quando non è offline aggiungere...esatto! io sono un grandissimo grandissimo fan di un altro tool fatto da un italiano in realtà su cui secondo me si sono parecchio basati in google per l'html che è hyperhtml l'HTML è una libreria che fa alla fine componenti, ti permette di fare dei web components, ti permette di fare un sacco di cose fighe non è proprio come è detto HTML, però era per dargli più o meno un'idea nella stessa famiglia dove c'è Polymer, no? Sì, diciamo quella famiglia lì, esatto.È una figata, secondo me, è veramente scritto bene, fa tutto quello che deve fare.L'ho adottato in azienda, in un progetto e il problema grosso è stato che tutte le volte che ho avuto dei problemi ho dovuto chiedere al maintainer direttamente, perché non c'era nessun altro che lo conoscesse in maniera decente, richiedeva una conoscenza molto avanzata di javascript per essere usato, secondo me, e quindi i junior che mi arrivavano impazzivano brutalmente.Però, e quindi quando fai la scelta su un tool, devi anche un pochettino capire quello che è il mercato, cioè non la puoi fare solo in base ai tuoi gut feeling.se dovessi essere io a lavorare da solo nel mio collo eremita, probabilmente non toccherei un computer e fargli il falegname come mi hai detto prima.Se stavo lasciandoci sul frontend, sceglierei una roba come HyperHTML.Oggi React mi sembra il giusto compromesso tra facilità di ingresso, possibilità di motorizzazione, gente che lo conosce, tool a disposizione, eccetera.Quindi sì, per me lui è qui per restare fino alla prossima Next Big Thing o fino a trasformarsi.Alla fine, in realtà una delle cose che ho apprezzato di più di React è che si è trasformato parecchio.Io adesso sto in React da 4 anni, ho ancora in produzione roba che ho scritto 4 anni fa, la guardo, ci sono cose che oggi mi fanno...mi facevano già schifetto un po' prima, tipo, io non ero un fan, per chi le conosce, degli I/O del Components.mi facevano abbastanza pene il ribrezzo, però li scrivevi.Adesso tutto functional e UX è diventato un altro linguaggio.GSX praticamente si è evoluto così tanto da diventare quasi un linguaggio di templating a parte, lo puoi usare anche in Vue e lo puoi usare addirittura...quindi è un linguaggio che a differenza di molti altri che ho visto si è evoluto molto e ha saputo secondo me anche predire bene tutte le varie cose anche il fatto che adesso stia spostando gli eventi da questi fantomatici eventi sintetici agli eventi del DOM quindi si potranno usare in combutta con i web components è un'ottima...cioè il team dietro le HATS è il fatto suo non lo mette in dubbio e sta facendo quello che è buon gioco, quindi è qui per restare secondo me.Probabilmente poi, come dicevo prima, una delle frasi sempre più belle, una citazione di cui non ricordo però, è che sempre sulla faragnameria "Se il tuo unico tool è un martello, tutto di sempre è un chiodo" e quindi secondo me per ogni cosa ci stanno i suoi utilizzi.Io sono sempre un fan, per chi mi vede su Facebook sono anche sempre un po' un bastià in contrario, cioè per me c'è il tool giusto per ogni cosa e bisogna comunque cercare di valutare tutto quello che c'è in giro prima di poter dire qualcosa.Quindi per dire, anche solo su una delle domande che mi viene fatta più spesso sui state manager di react c'è il caso d'uso per redax spoiler sono pochissimi c'è il caso d'uso per le macchine a stati e c'è il caso con x8 c'è il caso d'uso per mobix c'è il caso d'uso per non usarli proprio c'è il caso d'uso in cui basta Apollo uSquare basta quello quindi è molto Una delle cose brutte, come si dice, è che è molto frammentato.Posso capire chi magari fa consulenza, abbia i suoi tour favoriti e spinga quelli, per carità.Se sei fortunato come me a lavorare in un'azienda di prodotto dove puoi fare le tue scelte, io prima di pagliare una nuova tecnologia mi prendo sempre uno sprint, quindi un paio di settimane, per vedere tutte quelle che possono andarmi bene.Quindi anche per quello che bazzico sempre al comune, se domani dovessi fare un'applicazione molto complessa, probabilmente potrei cambiare totalmente il scenario.Se il team ingrandisse di colpo e dovessi assumere 850 sviluppatori in tutto il mondo, probabilmente sceglierei a quel punto sì un framework, può essere Angular anche, semplicemente perché non ho voglia di stare lì a dire a tutti come mi piace che sia fatta una chiamata al backend e cose di questo genere.Quindi in realtà ogni tool e il suo utilizzo, l'unica cosa anche qua, cerco sempre, mi piace diffondere questa cosa qua, di cercare il tool giusto per la cosa giusta da fare, perché purtroppo non è così.Anche perché anche uno di...questa domanda è anche uno dei pochi modi per cui possa uscire il nuovo tool, cioè che è il bello per alcuni e il brutto per molti altri del frontend che c'è veramente una frammentazione, una roba che va, però la cosa figa è che tanto ad oggi facciamo tutti web, quindi siamo in tanti a lavorare, possiamo anche metterci ad avere 7/8 alternative.Ma adesso mi accompagna la domanda più difficile della serata.Io volevo chiederti in realtà a farti una domanda su bootstrap ma per la tua opinione su bootstrap rimando a un tuo talk dove sei stato abbastanza chiaro.Poi ti chiederò cosa ne pensi di te ma mi hai accompagnato per forza una domanda.Oggi il mondo è abbastanza frammentato.Noi per esempio ne abbiamo citato tre tra le framework libreria adesso non so quali sia framework non so quale sia libreria perché anche là la definizione è un po' evanescente no? E controversa però ci aggiungerei Svelte, ci aggiungerei AlpineJS, ci aggiungerei altri 70.Ma allora ha senso iniziarsi a chiedere se esiste un modo, questa domanda in realtà è stimolata un po' dalle posizioni che solitamente prende Luca all'interno del gruppo Telegram, ha senso chiedersi se esiste un modo per pensare a un approccio un pochino più resilient per il front end? Luca è Luca Mezzalì, no no no è uno sviluppatore, un ragazzo che fa parte del nostro nostro gruppo Telegram tra l'altro lo salutiamo è super super attivo nelle discussioni.Ciao Luca ti saluto da casa! Allora c'è un personaggio per chi non lo conosce molto, che a me piace molto, lo anche conosci di persona che è Jeremy Keith, scritto così almeno, che parla molto di resilienza, ovvero lui è un fanatico, in parte lo sono anch'io, del fatto che il tutto dovrebbe essere fatto con la tecnologia più resiliente possibile, in tutti i contesti.Se applichiamo questa cosa al mondo del frontend non c'è nulla di più residente dell'html sopra il css e sopra il javascript quindi lui dice addirittura evitare di scrivere qualsiasi cosa in javascript che in realtà uno potrebbe dire che cavolo vuol dire che ci scriviamo l'html a mano no la cosa che però si può prendere da questo cos'è che noi spesso volentieri facciamo delle app che potrebbe la prima schermata potrebbe tranquillamente funzionare come html alla fine è quello che l'utente potrebbe leggerla e metterle senza dover avviarlo nemmeno javascript quindi uscire in questa maniera qua.Secondo me quando si pensa a questo concetto di resilienza è anche una scelta sensata perché una roba resiliente funzionerà sempre cioè domani facciamo l'esempio il mondo finisce proprio tabula rasa del mondo Secondo voi, per il futuro dell'umanità, è più facile leggere un foglio HTML o del JavaScript minificato? Quale dei due? Vedrà decifrato prima.Su questa, ovviamente, questa qua è un'iperbole gigante, in realtà è così che funziona Internet.Nel senso che a me capita spesso, quando sono in viaggio sul treno, che la pagina non risponda perché è bianca, perché l'HTML mi è arrivato ma dentro non c'era niente.Come dicevo prima, può rompersi parecchia roba, magari il browser con cui lo stai visualizzando è quello di un televisore, Chrome non gira dappertutto, l'HTML alla fine ti presenta di far tutto.Il CSS gli dà un senso estetico e il JavaScript lo arricchisce.Ora, per tornare, quindi vi consiglio di cercare Jeremy Keitt, lui ha fatto anche una conferenza che si chiamava proprio solo sulla resilienza.Io non concordo con lui, mi sembra che nel 2020 possiamo ancora metterci a scrivere l'html a mano, però una cosa che sta succedendo e che secondo me dà ragione a Jeremy, che è un estremista, ma su questo secondo me ha un po' di ragione, è il proliferare di tool come Gatsby, Next.js, ovvero cercare di nuovo, come se fosse una spirale, la vita dello sviluppatore, di portare alcune parti dell'applicazione di nuovo sul server e servire all'utente semplicemente, ancora una volta, HTML e CSS, quindi è solo dopo tramite una fase che è next, per dire si chiama idratazione, metterci il JavaScript in mezzo.Questo tipo di architettura per me rende tutta l'esperienza più...che rende il tutto più resiliente.Sarebbe questa poi la domanda, non so se mi sì sì assolutamente sì la domanda è centrato proprio il focus.Oggi per me una delle cose che voglio fare, uno dei miei obiettivi per il 2021 è prendere questa applicazione su cui sto lavorando e spostarla magari appunto con next o devo vedere qualcosa il più possibile sul su un back end perché perché ci sono interi mi sono accorto che ci sono intere schermate ma proprio intere pagine, interi flussi in cui l'utente non è davvero un'applicazione, è una dashboard finanziaria.Il momento in cui clicca qualcosa sono veramente molto pochi e fargli scaricare poi tutto, non tanto fargli, fargli seguire sulla macchina tutto quell'ambradam di roba mi sembra forse un pochettino eccessivo per fare quello che deve fare ma soprattutto non mi sembra resiliente, cioè domani volendo potrei iniziare a cacciare alcune despo...quindi se la roba è resiliente e non è eseguita run time su una macchina di cui io non ho controllo perché il damma di tutti i frontender, spostarla su un back-end mi sembra una buona cosa.E' vero che ovviamente la community, soprattutto adesso con Next.js, con Gatsby, con lo Stack Jam, sta roba qua gli piace parecchio quindi non è un bisogno solo mio quel tipo di resilienza lì secondo me va ricercata e va trovata una va trovata la giusta misura tra la roba fatta totalmente lato client per renderizzare magari una product card che poteva essere servita staticamente e il concetto di JeremyKit di scriverci a mano HTML CSS e javascript che c'è da fare un po' i cerchiobottisti, un colpo al cerchio, uno alla botte, cercare la giusta misura perché secondo me quella è la via.Il mercato degli sviluppatori lo sta mostrando, le richieste degli utenti pure, basti pensare al successo di appunto non solo Gatsby, ma anche di Ample, in Google, di questo tipo di cose qua.Su quello che dicevi, qualche tempo fa, il 22 ottobre, ho fatto un episodio sul concetto di progressive enhancement e sul concetto di democraticità ed eticità dei prodotti che realizziamo proprio a livello tecnico dove parlavo proprio di questi concetti di accessibilità, di come si è evoluta l'accessibilità col passare del tempo, se javascript sì, javascript no, ancora senso e quindi niente volevo condividere anche questa questa questa puntata.Ti faccio giusto l'ultima domanda poi ti lascio andare perché siamo arrivati davvero alle nove e ti ho rubato tantissimo tempo.Che cos'è per Davide l'accessibilità? Un'altra domanda da rispondere in tre minuti e mezzo.Esatto, tu metti che io ci ho scritto la tesi sul web per i non venuti quindi se puoi passiamo è un po' datata e avevo rifatto, ho fatto vedere tutti i problemi a tempi del sito delle poste italiane e avevo anche fatto vedere come sviluppare ai tempi siti per il Nintendo Wii perché molti non ci pensano, c'è anche chi ha disabilità motorie e navigare il sito con il mouse era impossibile, mouse o tastiera, e molta gente ha iniziato a usare sensori di movimento tipo quello lì del Wii, il telecomando del Wii per chi conosce col puntatore eccetera è abbastanza nel 2000 cos'era nel 2008 per me era abbastanza una figata l'accessibilità che cose per me per me anche qui dico una frase un po stramba un dovere deontologico del dello sviluppatore cioè non è una cosa di cui possiamo fare a meno ed è una cosa che permette veramente di migliorare a tutti la vita e di permetterci di poter utilizzare il web in ogni momento.Perché dico "permetterci"? Perché una delle cose che le gente spesso si dimentica è che la maggior parte delle persone che sono al momento disabili non lo sono per tutta la vita.Nel senso, se vi rompete una gamba, siete momentaneamente disabili e vi accorgerete, vi assicuro, mi è successo, mi sono distrutto il sole facendo palestra, vi assicurerete che noterete quando una città come Milano sia accessibile veramente pochissimo perché le conchiglie sono fatte male, le scale mobili non funzionano e quando cammini sulle stampelle ogni volta che ti vibra la coscia, ti fa malissimo qualche parte del non poterne accorgi.Molta gente, tornando al web, magari ha problemi di vista, ha le cataratte.Probabilmente noi che passiamo tutto questo tempo davanti a un computer, quando arriveremo a 60 anni sarà molto divertente vederci davanti al monitor.A me è capitato di avere la congiuntivite e quindi di non riuscire ad accedere allo schermo.Sono problemi comuni che secondo me devono essere per forza risolti e servono anche ad un altro aspetto che è più umano che lavorativo che è quello di simulare l'empatia, nel senso riuscire anche nel proprio lavoro a cercare di capire come possano utilizzare il nostro prodotto altre persone è una cosa che sicuramente è migliore del vostro prodotto, perché farsi delle domande per fare qualcosa da chi è diverso da te porta ad avere un prodotto ancora una volta più resiliente, perché se il tuo prodotto funziona bene anche in situazioni critiche, in situazioni che non erano il caso di uso che riguardava la tua persona, sicuramente è migliore, è il motivo per cui si parla tanto tra virgolette di diversity.Se ci metti cervello diverso se ti metti nelle scarpe di qualcun altro sicuramente riesci a progettare a costruire un software più resiliente quindi migliore.Risposta devo dire che non posso aggiungere niente credimi mi hai bloccato naturalmente sulla accessibilità ci sarebbe da dire per settimane e magari noi rimandiamo l'appuntamento a un altro episodio dove magari ne parliamo in tanti di questa cosa.Quindi sei nuovamente invitato nel nostro bar a berti una birretta con noi.Prima di salutarti però è nostra tradizione avere un momento che si chiama il Paese dei Balocchi dove i nostri ospiti ci suggeriscono qualcosa, ci regalano un balocco che li ha particolarmente coinvolti nella loro attività professionale o anche nella loro vita che può essere un libro, un tool, un software, un servizio, qualunque cosa.A te cosa piacerebbe condividere in questo in quest'angolo? Riconduco nel paese dei balocchi.Ah, il paese dei balocchi.Allora, come libro io lo consiglio sempre a tutti e l'ho citato più volte oggi, "Arte come mestiere di Morari, è un libro di cui potete tra l'altro leggere la prima metà, che secondo me è un libro che parla di progettazione, come dicevo prima, abbastanza trattato, ma che per me è modernissimo, perché mi mette proprio nell'ottica di tutte le cose che ho detto magari all'inizio del talk.Come tool invece io vedo poco parlare di tool di logging degli errori dell'utente di mezziche quindi oltre al platform.js che ho già citato che vi consiglio c'è anche secondo me un tool che mi ha cambiato parecchio la vita davvero come sviluppatore che si chiama Sentry.Adoro.Che è un tool di monitoring di quello che sta succedendo online io ce l'ho attaccato a un canale slack al lavoro e notate che praticamente la maggior parte dei miei errori sono tutti, come dicevo prima, network error.Io ho quasi solo problemi dai cellulari che arrivano da noi, fanno le richieste, si interrompe la connessione, gli va giù il 3G.L'Italia non è proprio un posto bellissimo per le connessioni mobile, devo dire.E quindi Sentry veramente mi ha cambiato la vita perché dormo molto meglio la notte perché vedo tutti gli errori che hanno davvero in produzione i clienti e non c'è niente di più figo quando ti chiamano dall'assistenza, dal servizio tecnico, se dire l'utente ha questo problema e tu gli puoi rispondere "sì, digli da aggiornare, l'ho già sistemato".E' bellissimo, noi la parte di assistenza più core, più tecnica in azienda, aveva proprio un accesso a Sentry, quindi vedeva l'utente, vedeva l'errore dell'utente, ancora prima che l'utente chiamasse siccome era un'applicazione B2B era l'assistenza tecnica che chiamava l'utente e questa cosa è strabiliante perché si meravigliavano e il valore generato a livello aziendale aveva un moltiplicatore è arrivato la rotina Davide io non so come ringraziarti mi ha fatto super piacere averti qua con noi credimi e te lo dico col cuore è stata una chiacchierata super super super piacevole ti ringrazio guarda anche per me è stato bello di percorrere anche un un po' di vialli dei ricordi e tutte le cose che...parlare un po' genericamente, solitamente sono abituato a fare dei talk su cose specifiche, poter parlare genericamente è molto bello, quindi ti ringrazio.Hai fatto delle domande splendide, devo dire.Quindi bravo, posso solo dirti questo.questo lo taglio però, mi imbarazzano i complimenti.detto questo noi ci salutiamo ci diamo appuntamento alla prossima settimana ciao GIT BAR il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
