Nelle puntate precedenti.

Sinceramente in Italia, tra l'altro, per il mood nazionale che c'è, se tu appena ti dicono non lo fare, non lo fai.

Non fai praticamente niente.

Perché lo scoraggiamento è lo sport nazionale.

È anche vero che le reti neurali si sono mostrate più capaci di rinviazzare le professioni intellettuali che quelle fisiche.

Tutti, 40 anni fa, pensavamo che la prima cosa che succederà con l'urbano-robotico e l'intelligenza artificiale è che il lavoro primario sarà surclassato.

Quindi il momento degli sviluppatori è ora.

Stanno vivendo l'età del loro.

E quindi, come si dice, mai un giorno senza una linea.

Ora è il momento di creare grandi cose.

Bene e benvenuti su BitBar, nuova settimana e nuovo episodio qua nel bar degli sviluppatori.

Ahimè, devo chiedere scusa per la qualità dell'audio che oggi ci caratterizza, ma essendo in vacanza ci troviamo in una situazione un po' estrema dove, sapete no, quando si preparano le valigie qualcosa la si dimentica sempre.

Io ho dimenticato il capo della scheda audio, rendendo praticamente inutile quel mega valigione di microfoni, cuffie e cose varie che ho portato con me.

Però prometto che per il prossimo episodio mi organizzo per avere una qualità migliore.

Con me ho anche Luca.

Ciao Luca.

Tu ferie? Io ho già dato, no, ma non è vero.

Ritornerò in ferie tra un paio di settimane, due, tre settimane.

Non lo so in che mese siamo oggi.

Cos'è? Luglio? No, siamo a fine luglio.

Ok, vabbè, comunque, sì sì.

Me ne vado al fresco però, andrò in montagna.

L'ultimo che mi ha detto me ne vado al fresco è stato dentro per dieci anni, quindi forse è una cosa più rischia.

No, però non così fresco.

Non così a lungo, talvolta.

Un saluto a tutti gli amici che ci ascoltano dal carcere.

Ecco qua, si è già svelato.

Il nostro ospite, con un saluto ai nostri amici Galeotti, secondo me ci possono essere, secondo lui ha senso fare dei corsi di programmazione per Galeotti? Secondo me sarebbe abbastanza, io vabbè, subito partiamo con la buona opinione, io credo fortemente nel carcere come forma di recupero delle persone, quindi una cosa del genere secondo me non è affatto una cattiva idea, bisognerebbe pensarci davvero.

Mi hai dato uno spunto, già iniziamo così, quindi sì, secondo me sarebbe una figata per le persone che sono interessate potersi inserire così in società con una figura abbastanza ricercata.

Hanno il tempo di studiare.

Esatto, quello non manca.

Condivido, ma mi sembra esista anche, adesso non mi ricordo, ho letto qualcosa ma non mi ricordo se era in Italia o in America, comunque qualcuno ci ha già pensato, è proprio corsi di programmazione o informatica in generale.

Però condivido assolutamente l'idea di Davide.

Io intanto presento l'ospite che è entrata a gamba attesa, quando si parla di frontender non si può non parlare con Davide Di Punto, è già stato nostro ospite, è l'uomo del frontender, il maestro frontender come dicemmo la precedente puntata.

Ciao Davide.

Ciao, un piacere di essere qui, non mi ricordo assolutamente cosa avevo detto l'altra volta perché come molta gente, come tutte le persone famose non riascolto i miei lavori perché poi non mi piace più che ho detto, ovviamente per chi non mi conosce mi sto autoperculando, ho la sindrome dell'impostore come tutti, quindi adesso sono un po' in barazzo.

Davide è quella persona che è pronta a rispondere quando qualcunque ha un dubbio sul frontender, quindi sei la persona giusta al momento giusto.

La prima domanda Davide che voglio farti è oggi luglio 2022 qual è lo stato di salute del frontender, del mercato del frontender? Già mi sconvolge, si vede che sono in ferie perché è il 2022, ho controllato la data soccorra, anzi è il 2022, è ancora peggio di Luca, non mi ricordo nemmeno l'anno.

Qual è lo stato di salute? Devo dire che siamo abbastanza in un bel periodo, perché partiamo dalle cose che mi stanno piacendo molto, prima di tutto il mese scorso è Mort Explorer, definitivamente, quindi questa roba qua ragazzi ci manda già nel futuro, è una cosa, io faccio il frontender da 15 anni e mi lavoravo da 14, quindi è arrivato quel giorno, quindi sicuramente è un buon mese per amare il frontender, il primo senza supporto da parte di Microsoft Explorer, quindi diciamo che il supporto si può dire e abbandonare praticamente ovunque, questa è una buonissima notizia.

Ci sono buonissime notizie per quel che riguarda, come ho mostrato, il mia mole CSS, perché stanno arrivando discrete figate, Safari, strano di dire, so che molti lo odiano, ma Safari ha spinto sull'acceleratore, la release di settembre è stabile, porta con sé un sacco di cose, quindi supporto a parent selector, il 2.as per dire che permetterà per la prima volta nella vita di scorrere il DOM al contrario, che è una cosa che non si poteva fare fino ad oggi, ovviamente stanno seguendo a ruota gli altri Chromium e Mozilla, quindi già questa cosa qua rende lo sviluppo una figata.

Dal punto di vista della JavaScript fatigue c'è sempre, vi vede che quest'anno è caratterizzato parecchio da una lotta a cercare di trovare il nuovo React, di un casino la community che sta cercando in tutti in maniera di schiodare questa libreria che inizia a far sentire i suoi anni, questa cosa è evidente, la DX sta sempre, non che stia peggiorando, ma i nuovi avversari stanno tirando fuori discrete figate e quindi questo rende il tutto più frizzante.

Devo ammettere che rispetto alle altre volte in cui la JavaScript fatica era molto più alta, per impararti ogni volta il nuovo pattern, nuovi linguaggi, nuove cose, la standardizzazione, abbiamo capito finalmente come community, come ci piace fare le cose a componenti con qualcosa di JSX-like purtroppo, non sono un grande fan in realtà, però la cosa sta piacendo parecchio e quindi poter saltare da una libreria all'altra viene un po' facile, ma ci sono grandi cose in servo nel futuro.

Tra l'altro, questo sembra quasi una cosa da chi è un lettore di fumetti Marvel di vecchia epoca, è un buon numero zero da coiniziare, ogni tanto dicevano i bollini sui fumetti Marvel in cui si diceva perfect starting point, questo sarebbe un buon momento per iniziare.

Non riuscivo a sbattere, non so cosa è successo, ho legato sul pulsante e non funzionava.

Ero pronto con una telecronaca per descrivere quello che io stavo vedendo dalla tua webcam.

No, dicevo, oggi il mondo front-end è in fermento, quanto questo fermento diventa carico cognitivo insostenibile per chi invece è un full stack developer, che ha un'altra parte di contenuto che va a pesare sulla knowledge complessiva, sulla quantità di studio da fare.

Al massimo la tagli se è troppo brutale per il montaggio.

Io non credo molto nella figura del full stack, proprio perché il carico cognitivo ad oggi del front-end è così grande che diventa difficile anche solo essere un front-ender ad oggi.

Anche solo riuscire a fare un front-end da inizio a fine, facendolo con tutti i crezi nintendo, non sto parlando di roba fatta male.

Test end to end, test unitari, logica di business, caching e validazione dei dati, security, parte visuale, parte semantica, è veramente tanta tanta roba.

Io me ne rendo conto soprattutto perché nell'ultima esperienza lavorativa ho avuto il piacere di formare una persona che ha praticamente diventato front-ender in un anno.

È uno di quelli che ha fatto i famosi corsi di facciamo diventare sviluppatore in sei mesi, queste robe qui.

Grazie al cielo, anche il motivo per cui l'ho assunto, ha scoperto che quei sei mesi non bastavano e così ha preso sei mesi ancora per studiare i perfetti suoi e cercare di diventare un front-ender.

Al che ha iniziato a lavorare con me e ovviamente ce n'era ancora, ha fatto quattro mesi in azienda in cui penso che, purretto, gli ho fatto solo scrivere componenti che non abbiamo mai usato, solo esclusivamente per fargli sbattere la faccia sulla realtà dei fatti, e la mole di informazioni da avere solo per fare quella roba lì è grande.

Uno degli aspetti che vedo molta gente sorvolare dal punto di vista del front-ender sono accessibilità, che molti front-ender manco sanno dove sta di casa, tipo area, attributes, tab index.

Hai mai provato a navigare il front-ender che hai fatto con la tastiera? È una domanda da colloquio 101 che ogni tanto faccio.

O con lo screen link.

Sì, sì.

Tra l'altro non mi ricordo più di avere pagamento del Mac, sembra che era Common Dalt 5, una roba del genere per fare partire lo screen reader su Chrome, ed è super divertente, una cosa che consiglio a tutti da fare.

Non mi ricordo la shortcut a memoria perché io sono una delle brutte persone che ha la touch bar del Mac e c'è il tastino per accendere e spegnere.

Però sì, con questa roba qui, già quello è un carico cognitivo devastante, io sono soltanto agli accessibility day.

Tu lo attivi ma non sai come uscire.

Esatto, si, si.

E quindi sì, questa è una roba che per me ha un carico cognitivo abbissa, nel senso che è veramente devastante.

L'altra parte che vedo sempre presa un po' sotto gamba, perché ci facciamo aiutare fin troppo dai framework, è la parte di security.

Banalmente, vedere se abbiamo scritto una content security policy per le nostre cose, se tutte le nostre richieste passano tramite HTTPS, sembra scemenze.

Io, nell'ultima esperienza lavorativa, ho lavorato per una banca, abbiamo subito un collaboratore che ci hanno provato ad attaccare il front e ovviamente lì ci sono alcune piccole cosettine che anche un frontender dovrebbe sapere, anche quello è carico cognitivo, soprattutto sulla security tecnicamente dovresti essere sempre aggiornato.

Quindi ce n'è tanta solo per iniziare, per dire esatto, parte di test end to end, cosa che ultimamente sta diventando veramente figo, Playwright, è un tool per fare test end to end per chi lo conoscesse, io ci ho avuto più fomo per l'uscita di Playwright, per vedere se era meglio di Cypress rispetto all'uscita di Blu-ray app 18, il nuovo Solid, GDS, queste cose qui.

Quindi secondo me il carico cognitivo è agghiacciantemente enorme e per dire, anche una persona come me che ha avuto la fortuna, io mi ripeto fortunatissimo perché 15 anni fa ancora non ne esisteva la figura, ma io volevo fare il frontender, questa idea qua ce l'ho da quando ero piccolino, subito dopo aver capito che non volevo più fare il veritista.

Ci sono interi settori del frontender che non conosco, come dicevo prima offline, adesso mi volevo fare un corso di 3JS, faccio tutta la pasta di 3D nel browser che ho avuto anni e anni e l'ultima volta che l'ho fatta penso di averlo usato con un plugin JQuery e la modellazione per 3D, questo mi fa capire quanto tempo potesse essere.

Domanda, quanto avere solo JavaScript come linguaggio di scripting del frontend ha in qualche modo attutito la frontend fatigue o quanto l'ha limitato? A questa ci attacco subito un'altra domanda che è WebAssembly, come lo vedi nel contesto frontend generale? Questa è una bellissima domanda perché è una di quelle cose che mi chiedo anch'io, non dico quotidianamente ma spesso, nell'ultimo paio d'anni io ho scritto solo programmazione funzionale in JavaScript, in TypeScript, con una libreria tutta italiana, per chi non la conosce, grande cuore, Giulio Campi che ha scritto FPTS con tutto quello che ne consegue.

Ovviamente una delle cose brutte di FPTS è che dietro c'è TypeScript a cui dietro c'è JavaScript che ovviamente non ha la più pallida idea di come dovrebbe funzionare davvero la programmazione funzionale.

Giulio è stato un mostro, ci ha messo dietro un sacco di modellazioni che io non so nemmeno come abbia fatto, quando vado a leggere i film che ha scritto, soprattutto quelli ricorsi in vero, solo applausi.

Certo che poi il giorno dopo leggi due righe di Haskell e proprio Haskell dove funzionale, fill citizen, capisci che stai usando un linguaggio ovviamente limitato, non è così così bello.

Quindi delle volte mi chiedo ma quanto sarebbe più bello poter usare il tool giusto per fare la cosa giusta? Quindi questo sicuramente è una buona...

non ho davvero una risposta perché in realtà con che se ne dica io sono un grande fan di JavaScript, con tutti i suoi limiti, con tutte le sue schifezze, con gli arrotondamenti, Mentool Academy e tutto quanto.

Perché alla fine è un linguaggio che a parte fa una cosa mostruosa, nel senso è compatibile con se stesso da quanto? 30 anni? Una cosa del genere, con Brad Deneck l'aveva fatto nel 94, 96 non mi ricordo più.

Però sì, è fenomenale questa cosa qua, non è una cosa da poco.

Poter scrivere JavaScript come lo facevi dieci anni fa, tu dipoi prendere un periodo sabbatico e poter fare ancora un sito, sta roba qui sulla JavaScript fatica in realtà dovrebbe influire molto.

Io ho amici che programmano Java e per anni per motivi lavorativi si sono fermati a Java 8 e adesso non lo so, prangono in lingue che io non comprendo.

Dall'altro, l'ultima volta che abbiamo provato a infilare roba non JavaScript dentro il browser non è andata benissimo.

Ci ricordiamo tutti quanti Flash, Silverlight, ActiveX, tutte quelle mostruosità che quando ci pensi ti fanno dire che il JavaScript non fa così schifo.

Abbiamo avuto roba che ti bucava la macchina, bruciava le batterie per davvero e cose di questo genere.

Per me ha sicuramente rallentato parecchio lo sviluppo e le cose belle che si potevano fare sul web, ma ne ha anche aumentato particolarmente la resilienza.

Secondo me una delle cose che ha reso il web vincente rispetto alla lotta con altri prodotti è proprio la resilienza.

Io nel passato quando ho un paio di app per Android 2, iOS 8, le avevo scritte.

Ovviamente oggi non funzionano più.

Ho ancora dei siti soli, penso che il sito del mio diploma in quinta superiore, da qualche parte, sia ancora lì che giri.

Quindi questo è ovviamente una figata.

Quando si parla di WebAssembly, quindi io sono da un lato galvanizzato, perché finalmente potremmo fare veramente qualcosa di più per quel che riguarda lo sviluppo più profondo.

L'altra domanda che mi faccio è, questo dal mio lato designer, all'utente, gli ne frega veramente di questa roba qui? Cioè che valore aggiunto ci porta questa roba qui? Perché JavaScript nella sua non essere bellissimo, nel suo essere super resiliente, nel essere sempre compatibile con se stesso e nell'avere dei limiti ha portato un grande valore aggiunto agli utenti.

Ovvero che una cosa che hanno usato l'hanno portata e la standard la possono usare all'infinito.

Con WebAssembly questa cosa dovrebbe rimanere, mi auguro sarà così, ma tutta questa potenza in più che avremo, cosa porterà poi all'utente come valore aggiunto? Io vengo da una generazione che, per fare un esempio, all'università mi hanno fatto studiare Second Life, che doveva essere, adesso faccio una battuta, ma non troppo il nuovo metaverso.

Mi pare Prada, però potrebbe essere un'altra casa di moda, che aveva fatto l'atelier tutto quanto su Second Life, tu potevi comprare come su Second Life.

Domanda, a parte la campagna marketing, avrà venduto una roba? Non lo so.

L'altra cosa che mi fa molto paura di WebAssembly invece è l'accessibilità.

Ho paura che si torni, tra virgolette, a roba tipo skip intro, i tastini di The City Flash.

Anche perché una cosa riguardo WebAssembly, quando ne parla, ci si pensa, c'è tutta la parte di giochi, di gaming che si può portare, esperienze di quel genere.

Solo oggi alcuni giochi, diciamo di quelli importanti, un esempio nobile è The Last of Us 2, pensano a poter fare un gioco accessibile.

Non so quanto la spinta tecnica di poter fare nuove esperienze con WebAssembly ci potrà dare una mano a supportare tutto il web.

Una domanda perché voglio fare ancora un passo indietro.

Hai detto che l'ecosistema front-end è diventato abnorme e quindi c'è un carico cognitivo enorme per un nuovo front-endista, il front-endista del 2022.

Hai spiegato in parte le ragioni, alcune ragioni magari le posso trovare anche forse in una diversa scala, come la sicurezza.

La sicurezza era un problema anche vent'anni fa, ma ti chiedo, secondo te è andato storto qualcosa? Perché quello che vent'anni fa, o forse 15 anni fa, lo riusciva a fare un full stack, adesso c'è bisogno di una persona, comunque un team dedicato al front-end ed è giusto.

Però mi chiedo se si poteva fare altrimenti di questo.

Hai voglia che andasse storto qualcosa? Ne sono andate storte migliaia di fila.

Non è per me un problema tech, non è un problema solo della sfida del tech.

Qua potremmo entrare sul lato del proprio metafisico del consumismo sprenato, del capitalismo che cerca una velocità di andare online sempre più veloce, una ricerca di riuscire a, mi viene solo in inglese, a move fast, quick things e cose di questo genere, ad alzare sempre di più l'asticella di quello che viene proposto e quindi ad aumentarne la complessità.

Questo lo abbiamo in ogni settore.

Un esempio che posso fare è mio suocero, in cui sono ospite a un momento, che ha 81 anni, una volta costruiva le automobili, proprio si faceva le auto lui, da zero, cioè era meccanico per passione, perché di lavoro lui lo faceva il tipografo, quindi questo fa capire.

Oggi, quando apre il cofano della macchina, posso dire brutte parole in bresciano, perché la complessità che ha raggiunto un'automobile è ovviamente molto più complessa delle jippine che si costruiva lui, che andavano a 75 all'ora, probabilmente inquinando come un getto.

Quindi questa tipologia di cosa si è vista ovunque, non penso che abbiamo sbagliato noi tech, da quel punto di vista lì, è semplicemente che si cerca sempre di ottimizzare i processi, aumentare il livello da stazione.

Aumenti il livello da stazione e la cosa diventa più difficile, ma basta pensare che io una volta, appunto, come dici tu, anzi io non sono della prima ondata del web, appunto lo faccio come lavoro da 15 anni, 20 anni fa, quando ho iniziato a fare le mie prime cose c'era il webmaster, il sistemista, il security manager, il design, tutto.

Io vengo dalla seconda generazione, quella dove c'era il web designer, che faceva il design, l'html, il css, i plugin vgpoi di dentro, i caroselli, già lì ha iniziato a separarsi un po' la figura e poi più vai avanti e più questa cosa si specializza.

Così come oggi per rifare il concetto con le auto, c'hai il gommista, c'è quello che ti fa solo esclusivamente il bollo e via andate.

Un altro esempio che mi viene sempre in mente io quando ci penso perché la mia dolce metà era architetto, una volta il muratore ti faceva la casa.

Adesso c'hai l'elettricista, c'hai l'idraulico, c'hai l'ingegnere, l'ingegnerette, il muratore, il capo campiere, l'architetto, l'interior designer e se devi mettere sulla casa bisogna anche del notario e di un paio di loschi figure in comune, cioè è parecchio cambiato questa situazione qua.

Abbiamo sbagliato qualcosa? Sì, ma forse come società non abbiamo complicato le cose parecchio, un po' per dare da mangiare a tutti, tra virgolette.

Quando ingegnerizzi qualcosa, quando passi da qualcosa di rudimentale a cercare di farne un progetto ingegnerizzato, aumenti la strazione più una cosa è astratta e più ci vuole uno specialista.

Sì, secondo me infatti questa evoluzione viene proprio dalla trasformazione, dal passaggio da un approccio di tipo artigianale a un approccio di tipo industriale e per compensare e per permettere delle realizzazioni di tipo artigianale sono apparsi nel mercato una serie di tool che introducono ulteriore astrazione ma che in qualche modo hanno come obiettivo quello di semplificare alcune parti.

Uno di questi che adoro è Tailwind e io qua so che con David abbiamo due visioni opposte ma mi piace parlare con lui proprio di questo per questo motivo, perché so che le argomentazioni su questo sono opinionate ma molto ponderate e avendo stima in Davide ho stima anche nelle sue argomentazioni.

Quindi ti dico, io so che tu hai una sorta di repulsione verso Tailwind e questo tipo di strumenti, da che cosa è guidata questa repulsione? Allora, sempre per parlare storicamente io, una delle persone che apprezzo di più nel web è la persona che ci ha allontanato proprio come sviluppatori da fare i layout con le tabelle che era famoso sul web, Zeldman, e lui aveva scritto un bellissimo articolo quando ancora non esisteva Tailwind, penso che si parlasse di Atomic CSS in generale, che era Kiss My Class Name, che era appunto un modo di dire che la classe deve avere un significato semantico che deve spiegare a un'altra persona quello che fa quel nodo del DOM rappresentato in HTML, nel momento in cui ci metti qualcosa di estetico, che ti dice tra l'altro in maniera anche molto poco leggibile, a meno che non ti studi tutto quello che è il CSS, tutto quello che è Tailwind dietro, non stai postando valore aggiunto al tuo al tuo codice.

Detto questo, quindi il mio astio non è tanto per Tailwind, ma per tutti gli approcci in cui all'interno del componente ci sono scritte classiche che non hanno un valore semantico, per dire io in CodeReview dei miei colleghi se mi scrivono blue su una classe perché è il bottone blu, io non l'accetto, ma io non l'accetto manco dai designer, cioè se tu mi fai un figma, perché i designer da me usavano figma, dove hai le varianti, una variante blu, rosso, giallo, verde, per me quello è sbagliato, perché quello è il risultato di un ragionamento, ma tu mi devi far capire il ragionamento dietro quella cosa lì, quindi da quel punto di vista lì, per me qualsiasi cosa scritta nel DOM che non abbia un significato è sbagliato, cioè per farlo ancora più, per fare una bella catchphrase, scambiare il significato con il significante è proprio errato quando si comunica con un'altra persona.

Quindi questa è la prima questione, cioè io quando vedo una roba fatta in quella maniera lì, può essere veloce quando vuoi tu, può essere figa, puoi capirla, per me è un po' uno stupro di quello che dovrebbe essere il web, perché invece di facilitarmi la vita me la stai complicando.

Ci sono esempi di ovviamente classi, talvolta un gigantesco attaccato a un componente che leggerlo ovviamente non aiuta l'elegibilità del codice, e tutto quanto.

Poi ovviamente una delle cose che mi si può dire tranquillamente su Tilewind, infatti in quel caso ho poco da dire, è quando viene usato l'apply, cioè quando Tilewind viene usato con un preprocessore, quindi tu prendi tutte queste classi, le metti insieme e a quel punto lì hai una classe unica, bella lì, a posto.

Il problema mio maggiore col Tilewind è superato, cioè una volta tolto lo scoglio della semantica all'interno del markup, già questo me lo fa digerire di più.

Anche Tilewind per me, come può essere anche Bulma, Bootstrap, tutte queste cose qua, per me sono, io li considero dei prestiti, dei loan, ovvero non ho pensato troppo alla parte diciamo di design visuale, prendo in prestito qualcuno che l'ha pensato per me, quindi ho quelli che vengono chiamati design tokens già presi e rappresentati, eccetera, li posso buttare in pagina e vado su.

Per alcuni progetti, tipo se oggi mi dicessero, vedete abbiamo una dashboard interna e la facciamo con Tilewind solo in apply, dico va bene, cioè nel senso la parte UI ha un valore aggiunto in quel caso molto basso, perché mi riguarda, deve essere una roba bella da vedere, usabile, ma di certo non devi metterci su la brand identity o qualcosa di parecchio significativo, non ho nulla in realtà in contrario per quelli utilizzati, anche comunque se è un progetto personale in cui voglio semplicemente raccogliere la lista dei miei podcast, ok, non è problematico.

Se stai facendo un prodotto già un pochettino diverso, perché a quel punto lì, è un prodotto di user facing, perché a quel punto lì appunto quel prestito andare a sovrascrivere quelle che sono appunto i design token, da un punto di vista del design, può avere un costo parecchio parecchio alto, quindi se l'accordo è usiamo Tilewind con Apply, con tutto quello che viene, useremo i design token configurati come cavolo vogliamo, allora bella, non ho nulla da eccepire.

Nel momento in cui usiamo Tilewind, però questa roba qui la cambiamo un pochettino, perché le griglie qui saranno 10, lì 12, lì invece il padding così, così, eccola, secondo me ci sono altri tool che funzionano meglio, per dirne uno, perché poi mi magari si fa la domanda, c'è Vanilla Extract con tutto il suo ecosistema che ti permette di scrivere le foglie di configurazione dei design token, farli e poi applicarli da zero, quindi hai la comodità di un Tilewind, ma i design token te le sei iscritti tu, ovviamente dipende come tutte le cose.

Una delle domande che ovviamente ci si può fare volentieri è, ma tu non è che ti iscrivi tu da zero, uso React, uso vari router, FTTS per dire sì, vero, ma qua torniamo sul discorso dell'astrazione, cioè nel senso, astrarre qualcosa di complesso va bene, per me l'astrazione su un design token va bene nel momento in cui sai, però cosa c'è sotto quel design token, quella è la cosa fondamentale, perché tu puoi astrarre quando sai quello che c'è sotto, sai fare la catena al contrario, quello che noto è che spesso chi usa Tilewind usa come scorciatoria per non sapere quello che c'è sotto, non parlo di CSS, parlo proprio di design.

Alcune cose che hai detto sposo al 100%, io però voglio provare a portare un'altra prospettiva a quello che hai detto.

Intanto per me è importante fare una grossa distinzione tra tool come poteva essere Bootstrap e Tilewind, perché? Perché Tilewind ha un approccio completamente diverso, ti mette a disposizione token e non componenti.

Quindi già quello in qualche modo a me per esempio è uno dei motivi per cui dall'inizio ho adorato Tilewind, era per questo motivo perché chi si ricorda quanto fosse doloroso accare i cacchio di componenti di Bootstrap, con punto esclamativo importante dappertutto e l'abbiamo fatto tutti, voi per i side project, voi per il tema di Italia.it, ma l'abbiamo fatto tutti.

Invece Tilewind ti dà questo approccio, queste classi che aggiungono una cosa che secondo me a CSS manca, che non saprei come dirla in italiano, però ti permette di descrivere la parte estetica in modo pseudo discorsivo, non saprei come dirlo.

Cioè è come che tu stia scrivendo una classe, invece il CSS classico lo sento quasi come il singhiozzo, i due punti e la capo, forse è una mia fissazione.

Qua a livello proprio di sensazione nello scrivere, trovo molto più fluido dove scrivere una lista di classi.

Altra cosa interessante che secondo me è la discriminante, sta nell'approccio.

Quello che ha detto Davide io l'avrei sottoscritto fino alla morte, fino a cinque anni fa, quando non utilizzavo un approccio a componenti.

Oggi ho la percezione che in realtà, e quindi cosa facevo, mi creavo i miei componenti nel CSS, ne gestivo la parte estetica, quindi una parte di valore semantico lo portavo nel CSS dove descrivevo i componenti con lo stile e a quel punto ero pronto davvero a difenderlo col sangue.

Oggi con i componenti che diventano un elemento comprensivo di logica del componente, DOM, quindi struttura HTML e stile, secondo me la separazione avviene a livello componente, non più a livello CSS, JavaScript, HTML.

Per cui non sento così forte quell'esigenza di separazione.

Altra cosa, e qui chiudo, il fatto di essere limitati a una serie di design token già prefabbricati può avere senso, cioè ha senso quando Davide dice Tailwind ti dà già i suoi token e tu te li usi.

Però in realtà per il mio approccio a Tailwind, i token di Tailwind li uso praticamente zero, perché se devo fare un progetto strutturato il mio Tailwind conf sarà veramente customizzato all'inesima potenza.

Però nel contempo utilizzo lo stesso strumento anche per fare il POC, il sito di Gitbar che ho fatto coi piedi, dove io non ho bisogno di pensare alla razza aurea per la dimensione del bottone, per l'equilibrio, perché non è mio, non sono un designer e per quel tipo di progetto non mi posso permettere un designer.

Avere Tailwind che ha già per esempio i token di spacing o di font size, disegni stabiliti e fatti con un criterio opinabile ma ha una logica, quello è tanta roba per me che sono una capra in quell'ottica.

Mi permette anche di avere un approccio artigianale dove altrimenti non potrei averlo.

Guarda, hai toccato tanti punti, non mi ricordo più il primo, parto dal secondo, che è quello lì di trovi più comodo a scriverlo in maniera tricolette discorsiva, si capisco, è il motivo per cui ti ho parlato di Vanilla Extract dove puoi farti questa roba qui esattamente nella stessa maniera, molto simile, ma con altri vantaggi tipo è fortemente tipizzato, scrivi alla fine CSS, non scrivi CSS, se sei più vicino a CSS rispetto a quello hai una serie di ottimizzazioni pare, quindi per me se ti piace quella roba lì, il problema di Vanilla Extract è che non c'è quello che dici tu che è il terzo tema, il prestito, il prestito da parte del design.

Cioè per dire, come dici tu, avere dei limiti, questa è una cosa che a me piace molto di Tilewind, quello che banalmente ha fatto capire alla gente che le spaziature sono delle variabili di tutto rispetto, cosa che invece spesso e volentieri i designer ogni tanto, qua 48 pixel, lì 52, qua fai tipo 3D da un componente all'altro, quindi da questo in realtà è molto figo, è quello che ti dicevo, funziona Tilewind, funziona molto bene, quando parlo appunto di design token, tipo anche se tu ti fai i tuoi design token con la configurazione, alla fine sei limitato a giustamente a quelli che sono quelli di Tilewind.

E ti dico, se il web fosse quello di cinque anni fa, sarei convinto anch'io.

La mia domanda è, quant'è che hai usato l'ultima volta CSS Grid, le erroneamente valutate, chiamate CSS variables, Clamp, Minmax e cose di questo genere qui? Io ti posso rispondere, CSS Grid stamattina con Tilewind, quindi in realtà sai cos'è da, hai ragione nell'ottica di avere awareness di quello che stai usando.

Se il problema sta nel fatto che essendo Tilewind, una strazione, una classina del cavolo, ti nasconde un livello di complessità e tu conosci solo quella classina del cavolo, grazie al piffero, certo che il problema c'è.

Se però tu sfrutti quell'awareness, io credo che in realtà ogni strumento è buono perché stai usando una zappa, sei consapevole del prestito che stai prendendo.

Sì, sì, ma quello mi sta bene, nel momento in cui tu lo sai, appunto sai questa roba, però per dire, per fare l'esempio, quando si parla di tipografia, ti faccio l'esempio stupidissimo, nell'ultimo sito che ho realizzato la tipografia è fluida, va da un minimo di una dimensione a un massimo di una dimensione, non ci sono breakpoint in nessuna maniera, quindi non c'è un ragionamento a questi, semplicemente a una dimensione minima, più di un momento lo schermo arriva a una dimensione massima e viene appunto fatto un clamp sull'inmax delle varie proprietà con determinate dimensioni.

A quel punto lì, anche la griglia, per dire, tutto il sistema, non c'è una griglia, perché si usa CSS grid con i vari auto e quello che spesso e volentieri viene fatto è un po' il contrario di quello che è questo, ovvero, ecco l'altra cosa che mi hai detto, concordo con te, la questione si è spostata verso i componenti, quindi non vedo più una separation of contents, come dicevamo prima HTML e CSS e JavaScript, se usi JSX quella roba lì non esiste già più, quindi mi sta bene metterci quello, a quel punto scrivi pure a stand in line, tanto purtroppo il JSX di base ammazza la separation of contents, su questo non posso essere smentito, perché HTML e JavaScript si sono scritti insieme e quindi la separation of contents non c'è.

A quel punto se ci butti pure dentro lo stile, per me non muore nessuno, la strada era già segnata.

La differenza è proprio questa, tu potresti avere un componente che gestisce la tua griglia, che decide come mettere le cose in pagina, puoi fare sovrascritture di custom properties, le custom properties di CSS bisognerebbe vederle come volendo, un livello di API sul componente, non passare i props, passare i classi eccetera, ma banalmente il tuo text code, cioè tu come sviluppatore dici ok questa roba qui è il padding che deve prendersi, a quel punto lì tu ad esempio in token padding 1, padding 2, padding 3 che scrivi in line o che c'è nell'apply, lo devi sovrascrivere, lo puoi sovrascrivere con Tilewind, non sto mettendo in dubbio perché a quel punto lì fai una custom properties, però come vedi il livello di astrazione per poter ottenere qualcosa che finalmente CSS ti dà abbastanza facilmente è molto alto, perché veramente una delle cose che ho notato sposando appieno diciamo banalmente l'ultimo lavoro che ho detto non me ne frega niente, supporto le ultime due persone dei browser, con la scusa che era una banca quindi andando lì bisogna avere la sicurezza alta, quel browser vecchio non ce l'abbiamo, io in realtà ho fatto sta roba qua per poter dire ultimi due vendor, major dei browser, explorer mostro, quindi sono due anni che lavoro in questa situazione qua, potendo sbizzarrirmi appunto con custom properties, media query all'interno di javascript perché ci sono i media observer, ho scritto un casino meno di CSS, pensa che una cosa assurda, uno dei lavori miei più apprezzati su internet tanti fa era un generatore di griglie sas, che ti permetteva di farti la griglia come volevi tu e usarla sia a tile window maniera, sia con i mixing di sas, ma nell'ultimo lavoro noi abbiamo lavorato senza griglie, non c'era spacing, non c'era nulla, perché banalmente tutto quanto da un punto di vista del design gli spacing era una variabile, in realtà tre variabili di spacing, anche quelle che si adattavano direttamente al dispositivo, non c'era nessuna griglia perché avevi il componente che decideva come mettere le griglie e comandava attraverso custom properties i figli che si andavano a mettere in giro, quindi questa roba qui mi ha permesso, io ho scritto pochissimo CSS, usando CSS moderno, in realtà è molto più complicato, perché se mai riuscirò nella vita per entrare nella committee di chi decida il CSS, perché i nomi delle proprietà del grid sono una delle cose più oscure che il signore abbia mai creato, ogni volta nonostante lo uso tutti i giorni il compo di aspetto era vertical, alline self, alline justify content, display era grid template columns o grid columnist template, tutte queste cose qua, però una volta che ci fai la mano, veramente per fare l'esempio stupido, ultimamente ho dovuto inserire all'interno di una griglia molto complessa, un elemento praticamente, facciamo un esempio, avevo un titolo con una roba a destra, una navigazione, ok, di primo livello, e una tabella gigantesca, nel punto in cui c'era la navigazione io sono dovuto andare, ho dovuto inserire dei filtri, quindi un secondo livello di navigazione affiancato, il tutto senza poter toccare i componenti che già c'erano, perché erano utilizzati da altre parti, una delle cose che avrei potuto fare, vado a fare un decorator, che ti prende questa roba qui, no banalmente con un filtering selector e con CSS grid, sono andato ad apprezzare un elemento che era sotto, ah c'è anche questo elemento, bon, ficcamolo qui con la CSS grid, scrivendo tre righe di codice, CSS normale, questa roba qui è abbastanza wow effect, quindi poi, come dici tu, è un tool, sai quello che stai facendo, ti fa andare veloce, per me puoi scrivere anche a quel pucere, questa è la cosa che per me è più importante di tutte le emozioni agile, le persone prima di tu, se tutte le persone nel tuo team quella roba lì, la capiscono, la comprendono e gli piace, e se la persona sei solo tu, bella lì, e nel momento in cui hai rispetto per il prossimo, per rispetto per il prossimo intendo la roba è accessibile, è comprensibile, se non è comprensibile, ben documentata, ci sono i test a coprire quella roba lì, allora puoi fare quello che vuoi, lo scrivi in brainfarm, va bene, non c'è nessun problema, questo vale ovviamente per tutto, dall'altro è quello che dici tu, se prendi un prestito devi sapere cosa stai pagando, una volta che lo sai, cioè se tu mi dici io scrivo molto più veloce, riesco a fare, io ti dico bella lì, l'unica cosa che ti dico è che se guardi un pochettino, poi se mi dici che le usi con grid misto a tile, window dentro tile, bella, mi chiedo come fai a scrivere una grid template area con le classi, quasi paura a chiederle questa cosa qui, però va bene, cioè non è problematico, la questione è quella che dici tu, è un pochettino quello che si dice sempre quando si vede nei corsi, si diventa sviluppatore in tre mesi, quindi ti fanno fare le hack senza sapere javascript, ti fanno vedere che ne so qualche lava, senza sapere PHP e MongoDB infila da caso dentro, manco teoria dei dati, fatto sì va bene, sono dei tool, però sotto devi sapere come, cioè una delle domande che faccio per viste colloqui è, ok, questo minore div slash chiuso div, in cosa viene compilato? Te lo sei mai chiesto? Perché sapere banalmente una cosa così banale aiuta a risolvere infinità di problemi in React, stessa cosa su CSS, se sai qual è il tuo prestito sai quello che faccio, per me va bene, l'unica cosa che ti dico appunto, io personalmente non ne ho mai sentito il bisogno perché, quando tu dici mi piace scrivere con la roba lì, ad oggi scrivo massimo due o tre lighe di CSS per elemento del DOM, due o tre lighe di CSS, quindi se dovessi scrivere tilewind, applicherei una o due classi ad elemento, mentre io non scrivo manco più le media query, perché solitamente uso flex o grid per fare per fare giochini vari, c'è un bel talk di Giacomo Zinetti su youtube, potete trovare che la mostra della media query o qualcosa del genere, dove appunto fa vedere un sacco di tecniche per non usare più le media query e avere una roba con il contenuto.

Domani che ci saranno, domani veramente, le element query, le container query, anche quello ci permetterà di fare delle figate assolute che ovviamente a strade con dei framework atomici inizierà a diventare un pochettino complicato secondo me.

Luca hai qualche domanda? Ce l'avevo fino a un secondo fa quando ha appena detto cosa gli mancava nel CSS oggi, quindi gli ha detto immagino di aver capito bene che sta aspettando i container queries, se c'è altro? Cosa vorrei domani? Si no, allora devo mettere container query e parent selector sono due miei...

non lo so, se avete presente il video del bambino che scarte il nintendo 64 a Natale? Quando ho visto che sono disponibili, tipo quella è stata la mia espressione, quindi dal punto di vista del CSS per ora mi sta bene.

Borrelay magari che ci fosse un po' più attenzione per quel che riguarda il web components e lo styling del web components usato con API con le custom properties, mi piacerebbe molto quella parte lì.

In javascript quello che mi manca visto che adesso sono due anni che lo utilizzo è avere qualcosa che lo renda l'approccio funzionale molto più facile da fare.

Ecco una delle cose che tipo ultimamente sono molto felice che è diventata una proposal di javascript è...

oddio...

sono i record le tuple, che sono delle proposal per chi non sapesse cosa cambia faccio...

semplifico per amore di chiarezza, non è proprio così, ma banalmente un record è un oggetto immutabile, quindi se faccio record a 2.1 uguale uguale uguale record a 2.1 finalmente javascript dice trucco, perché riesce a fare un confronto tra valori e non da referenza.

Questa roba qua, tu pensa a quante librerie di immutabilità, di memorizzazione butti nel cesso con una specifica sola che dovrebbe arrivare e passata, non mi ricordo a quale stipo, al terzo stadio, quindi tra un annetto o due si potrà fare questa roba qua, tu pensa banalmente per chi usa React, pensa quanto diventa più bello usare quei maledetti...

per gli effetti, per poter fare...

o tutta la parte di memorizzazione te la puoi scordare, perché puoi usare appunto record e tuple, potete immaginare più o meno la stessa cosa che ho detto prima per i record e per gli additi.

Questa roba qui è una delle cose che mi galvanizza di più.

Ecco una delle cose che aspetto anche con trepidazione in javascript, oltre alla pipe che sta arrivando, è il pattern matching.

Secondo me è una di quelle cose che...

ecco, tra librerie che tutti dovrebbero conoscere, se usate TypeScript andate subito a vedervi tspattern, che vi fa fare praticamente...

io ormai avvio un progetto, installo tspattern, lo userò il prima, se sto usando TypeScript per metti tspattern, dovrebbe essere già incluso, non so nemmeno come fare senza.

Vero, vero, vero.

Tieni presente che uno dei motivi per cui mia moglie mi percula sul fatto che io uso javascript sta sul pattern matching.

Domanda, voglio spostarmi in una delle materie preferite di Luca invece.

Comunicazione.

Tu hai fatto tantissimi anni il front end e continui a lavorare sul front end.

Come si costruisce una comunicazione sana con UI e UX designer? Se avessi un euro ogni volta che mi hanno fatto questa domanda adesso avrei più di quanto mi hanno fatto guadagnare il bitcoin.

Gioca parte.

Prima di tutto, per me quando si parla di full stack, quando si parla di front end, quando si parla di design, c'è un ovvio problema.

Il problema è che secondo me, nella mia opinione, potete poi insultarmi sul canale telegram o via messaggi privati su LinkedIn, un front end dovrebbe saperne un pochettino di design e viceversa un designer dovrebbe saperne un pochettino di quello che sta andando a progettare.

Per esempio, per fare un esempio di quale per personale, la mia ragazza è architetto di stato eppure, giustamente, quando devi fare l'architetto, parliamo di realizzare le billette, ti fanno fare analisi 1, analisi 2, fisica 1, fisica 2, c'è tutta roba di ingegneria tecnicamente, perché l'architetto giustamente non ti può costruire, non ti può progettare qualcosa senza avere almeno una base e quindi da quel punto di vista lì, secondo me, la progettazione ad oggi ha delle lacune molto forti.

Io sono fortunato, io sono lavorato in design, però negli esami obbligatori della mia università c'erano tre esami di sviluppo web, quindi proprio HTML, CSS, la parte di codice era invece in ActionScript 2, perché questo fa capire quanto tempo fa ho fatto l'università, però c'era programmazione, c'era un esame anche per vita, anche in modellazione 3D che avevo fatto e After Effects, c'era una parte di sviluppo.

Non sto parlando, io ho fatto anche informatica, sto parlando di esami di algoritmi o di esami di programmazione oggetti che si fa in informatica all'università, però comunque della roba che ti dà delle basi, cioè tu sai che è difficile.

Io quando sono uscito dall'università sapevo già che centrare un elemento verticalmente in pagina era un problema, quindi non mi sono mai sognato nella vita di andare da una parte che ci vuole centrarlo, perché avevo capito col sangue che quello era un problema.

Stiamo parlando del 2005, del 2006.

Quindi questa è la prima cosa, e dall'altra parte, avendo appunto fatto anche informatica, se parliamo di progettazione è abbastanza agghiacciante, a me è una delle cose che mi fa più fastidio, non c'è manco progettazione di un API, tra tale cosa che già aiuterebbe a far capire.

Quindi da un lato la prima cosa da fare, lo dico io in sé, ovviamente ho questo problema quando mi, avendo appunto io nella vita fatto sempre quasi solo front end, per quanto abbia scritto qualcosina che interagisce con MongoDB, Postgres, eccetera, dal punto di vista di database, sicurezza, faccio schifo al librezzo.

Ho fatto morire a mare un Postgres con 200 utenti al giorno, perché non mi ricordo cosa avevo dimenticato di fare dalle quelle che avevo scritto.

Quindi, da un lato c'è sempre cercare di parlare tutti la stessa lingua e di fidarsi di quello, di cercare di imparare da quello che ne sai più di te.

Se un front end, fatti spiegare il design, fatti dare questa roba qui, e viceversa, perché? Perché insegnarsi a vicenda queste cose qua è il primo passo per poter iniziare a parlare la stessa lingua e a poter quindi comunicare, perché alla base della comunicazione ci sta la lingua.

Per chi è appassionato di fibbia, c'è la bella storia della torre di Babel, che è una cosa divertente sull'argomento.

Quindi, se si inizia a poter comunicare insieme, questa cosa qui è fondamentale.

L'altra domanda, quindi l'altra cosa da fare è chiedere sempre perché.

Chiedere sempre perché una cosa.

Non capisci una roba? Yellow, White, ha fatto un tasto blu e un tasto rosso? Perché? Qual è la differenza? L'altra cosa, siate, lo dico a entrambi, non so se ci sono anche designer, che ci ha fatto, siate pigri.

Questa è una cosa abbastanza strana da dire.

Perché siate pigri? Perché, come dicevano prima, l'approccio a componenti è quello che ha vinto la battaglia di come si progettano i web oggi.

Vero? Quindi, se è un componente che fa una roba, perché ne devo fare uno che è quasi uguale ma leggermente diverso? Questo vale, sia quando si sviluppa, ma soprattutto quando si progetta.

Quindi se il vostro designer viene da voi con, guarda, questo è il bottone di prima, solo che in questo caso qui è due pixel più largo, senza ragione apparente, domanda perché? C'è una forte motivazione per questo motivo qua.

Cioè, ricordatevi che ogni cosa che viene fatta a un costo, è una delle cose che ti fa guadagnare i soldi e risparmiare sui costi inutili.

Quindi spesso e volentieri discutere insieme del perché di alcune scelte è istruttivo per ambele parti.

Perché magari con due pixel in più, il designer ci ha pensato a lui, c'è magari una ricerca utente che dice, però con due pixel in più fatturiamo il 40% in più, ragazzi, ma anche tre pixel, va bene.

Se invece, boh, perché così è allineato a questo punto qua, focale, a quel punto magari...

perché? Questa è la questione.

Però ripeto, la risposta è imparare a comunicare, cercare di parlare la stessa lingua, per chi usa componenti, banalmente dare il nome insieme al componente.

Ogni componente dovrebbe avere un nome, in maniera che in azienda, quando dico button bar, sanno tutti esattamente di cosa stiamo parlando.

Mapp, tutti.

Questa è per dire che è la prima questione.

Seconda questione, appunto, cercate di contaminarvi a vicenda, un po' di imparare il design.

Io per dire, non ho mai usato film in vita, mi sono fermato a fare design con sketch, poi l'ho smesso, perché già imparare la programmazione funzionale è stato un delirio questi due anni.

Però il designer in azienda mi ha fatto vedere un sacco di figate, tipo che Figma utilizza praticamente flex, by default, quindi puoi fare proprio così in flex senza media query, un approccio a componenti molto React-like, dove passi non delle props, ma dei pulsantini che alla fine fanno le cosiddette varianti.

Quindi questa roba qui mi ha aiutato un casino, perché dal prossimo design, con cui parlerò, gli dirò, oh, usi Figma, perché non usiamo le varianti? Semplicemente perché ho perso del tempo per parlare con un altro essere umano.

So che se fate gli sviluppatori non volete parlare con gli esseri umani, è comprensibile questa cosa qua.

Ce l'ho Facebook pure io, li apro i commenti di Repubblica, lo so che è un mondo difficile, però se ascoltate un podcast evidentemente la voce umana non vi fa così l'ibrezzo, quindi parlare con qualcun altro potrebbe aiutarvi parecchio.

Sono d'accordo con te, Figma è stata la rivoluzione, anche per spingere un designer a lavorare in un modo un po' più simile a come lavoriamo noi.

È veramente una figata assoluta, in più tutta la parte di prototipazione ti permette anche di vedere le interazioni che il designer ha in testa e che prima dovevi solo immaginare o provare a immaginare.

Figma e Framer hanno veramente sviluppato il design.

Framer l'ho usato anche da designer, effettivamente sì, proprio rispetto a quello che c'era prima, che erano, io li chiamavo dribble shot, che era tipo mettere su dei pixel bellissimi che facevano cose lì, ti costringe a pensare web, che è una figata, non indifferente.

Chi prototipava prima, io ricordo c'era qualcuno che lo faceva in quattro, non so quanti di voi lo conoscono.

Voglio rimanere ancora sulla comunicazione, però spostarla dentro il team, perché è una domanda, come sempre le domande che pongo su BitBar vengono dalle mie segmentate serali.

So che comunque tu hai il tuo team, quindi ti sei anche occupato di formare giovani, gestire i sviluppatori.

Allora voglio chiederti, con questa ci accingiamo a chiudere questo episodio, challenging, esiste un modo per capire quando smettere di challengeare con un collega o con un designer? È una domanda che sicuramente ti è venuta da casi di vita reale, perché me la sono fatta anch'io, non per me, perché la risposta brutta è difficile da attuare e allenare con la che si può chiamare intelligenza emotiva.

Quindi questo non ha nulla a che fare con il tech, è un argomento di cui ci sono un po' di libri.

Se ne posso consigliare uno, possiamo dire l'Atlante delle emozioni, che è uscito da poco su argomenti che ti fa capire come gli esseri umani comunicano le proprie emozioni.

Quando vedi che gli stai fortemente facendo salire rabbia, tristezza, sentimenti negativi, a quel punto magari è il caso di smettere.

Magari hai ragione, però non stai portando la discussione in nessun punto costruttivo.

Da quel punto di vista, non mi è capitato spesso, economicicamente, formando persone, è molto più difficile avere due persone che stanno discutendo, capire entrambe le loro ragioni e riuscire a quietare gli animi e soprattutto non solo tanto a far ferma la rissa, perché è facile.

Anche cercare di far capire che avete ragione entrambi, nonostante adesso vi odiate e ognuno di voi voglia la morte dell'altro, dovete cercare di trovare una soluzione a questo problema insieme, perché avete entrambi ragione, ma dovete trovare il compromesso.

È una cosa stra difficile da fare con una persona che detesti profondamente, perché c'è appena magari sbroccato.

Quindi come puoi fare in questa roba qua? Prima di tutto c'è una cosa manageriale, qua dovrebbero essere i manager o comunque chi è sopra, deve essere sempre molto esplicito qual è l'obiettivo che bisogna raggiungere, perché questa roba qua è fondamentale per quietare qualsiasi discussione.

Se per dire, come dicevo prima, l'obiettivo di questo sprint, di questo task, di quello che voi, che vi interessa la metodologia, è quello di fare delivery il prima possibile di questa feature, a quel punto lì la discussione non è più me contro di te, ma la scelta che stiamo facendo ci porta vicino all'obiettivo.

Se la persona, e troppo può succedere, soprattutto lato design, ma anche lato sviluppo, quando sei quasi alla fine del tuo mestiere, cioè il design ha finito di disegnare la feature, tu sviluppatore hai pure scritto il test end to end su quella roba lì, poi c'è un cambio di lotta, per qualsiasi motivo uno tende a innamorarsi di quello che ha fatto.

Magari hai scritto il tuo test end to end più bello di sempre e poi ti dicono che lo devi cancellare perché non sei quella.

Ci sta che uno diventi difensivo.

Avere l'obiettivo ben saldo e ben chiaro, la stella polare lì, che bisogna raggiungere, questo aiuta veramente un casino, perché a quel punto lì tu puoi anche semplicemente osticipare la discussione, quando l'animo sarà più raffreddato.

Se quei due pixel lì in più non servono a nulla per raggiungere l'obiettivo e siamo stretti di tempi, non si fa.

A quel punto lì nella tua discussione tu stai facendo comunque una cosa costruttiva.

Anche se passerai per stronzo, ma c'hai ragione, perché come team ci siamo committati per arrivare lì.

Tu stai cercando di arrivare lì, se la persona ostacola, sta ostacolando il team.

Questo sposta a un genere di prospettive, dove si può discutere.

Poi lì entrano questioni caratteriali.

Mi è capitato anche persone che hanno detto che quello è l'obiettivo, facendo così lo raggiungiamo, siamo tutti felici.

Non mi ne frega niente, perché io le cose o le facciamo come mi piacciono a me, o se no cosa mi sveglio la mattina a fare e poi venire a lavorare.

Lì stiamo a raggiungere un livello ovviamente di...

L'evento stativo è a quel punto un elemento pericoloso nel team? A quel punto lì si scala, perché effettivamente è proprio dannoso per tutti quanti.

Perché a quel punto lì hanno...

Ok, io voglio solo scrivere in ASCEL, mi interessa niente che la vostra codebase sia in JavaScript, morite male, sti votati.

E se voi non vi imparate ASCEL, non mi fate le cose che io faccio.

Fatte i vostre.

Non è l'odio.

Quindi queste due cose qua.

Un po' di intelligenza emotiva.

Appunto si può allenare, ci sono testi, è quello che ho detto, per cercare di capire l'altra cosa.

La seconda è avere sempre in mente l'obiettivo, il goal.

Questo deve arrivare o dall'alto o dal timbro, non è vostro personaggio.

Può essere anche vostro personale.

Cioè, nel senso, faccio un esempio.

Uno dei goal di team che avevo nell'ultima esperienza era avere una code coverage dell'80%.

Code coverage dell'80%, quindi banalmente se in un task questa roba qui rallentava perché non riuscivo a scrivere i test per tutte le casistiche, bla bla bla.

A quel punto lì, quello non viene.

Però appunto è chiaro del team, diventa proprio una...

e a quel punto la comunicazione è molto più facile.

Però gli obiettivi di business, il business deve essere chiaro.

Diciamoci la verità, delle volte il business è volutamente un po' oscuro, perché così riesce a fare qualcosina di più, bella lì, cercano sempre di saturare al massimo la tua cosa.

Però poi il problema può scaturire nella comunicazione.

Un obiettivo chiaro solitamente porta a molto meno discussioni e a risolvere molto più facilmente.

Io sono d'accordo, mi permetto solo di aggiungere forse anche un piccolo dettaglio.

Magari è buona Prassi e può aiutare tantissimo sulle cose che hai giustamente detto.

Una preparazione preventiva prima della formazione del team, o durante la formazione del team, o in generale anche per gli esterni che entrano nel team come nuovi arrivati.

Quello proprio della formazione, della condivisione dei valori, dei concetti, aver chiaro qual è l'apporto che noi dobbiamo dare all'azienda, al nostro sistema superiore.

E fatto questo lavoro, una volta che tutti i membri del team li conoscono e li approvano e sottoscrivono, in un certo modo è anche più facile disinnescare quei litigi, chiamiamoli così, che arrivano.

Perché se c'è un forte contrasto, dobbiamo individuare o saper individuare cos'è quel valore che manca, che è diverso.

Magari uno dei due ha un valore diverso che, o nel caso più facile, va in contrasto con quelli già approvati.

Allora lì è facile farsi rendere conto di, tra virgolette, che è ragione e che è torto.

Se invece è uno di quei valori che era una zona grigia, che non è stato deciso, non è stato approvato, è un buon momento per invece discuterne e trovare, se non un compromesso, magari proprio un consenso da parte di tutti i membri del team, nel caso anche a scalare verso l'azienda.

Il discorso sui valori alla fine rientra anche nella gestione dei sentimenti.

Quando si discute e cominciamo a provare dei sentimenti, questo vuol dire proprio che c'è qualcosa in ballo nei valori che noi abbiamo accettato.

La rabbia è il sentimento che indica di un valore violato, la paura di un valore in pericolo o la vergogna di un valore che noi stesso abbiamo violato.

Saper riconoscere anche queste piccole cose aiutano a discutere, disinnescare i vari litigi o le varie discussioni che sembrano non portare a nulla, si possono chiamare loop, che sembrano non portare a nulla e soprattutto a nulla di buono.

Questo è un altro capitolo, potremmo rimanere ore a parlarne.

Andiamo per un prossimo episodio, visto l'ora siamo già un'ora e un quarto, quindi è arrivato il momento Paese dei Balocchi.

Per cui io chiedo a Davide, hai qualcosa da condividere con la nostra community? Qualcosa che ti saluta in mente? L'ultima volta ci hai portato i lunari.

Ah giusto, che bello che è quel libro lì.

Riconducono il Paese dei Balocchi.

Ah il Paese dei Balocchi.

No appunto, in realtà un po' di cosettine che ho già letto, ripeto, T.S.

Pattern, il libro dovrebbe essere uscito in italiano, Atlante delle emozioni, lo sto scrivendo al momento su, no non è questo, vi mando poi il link.

Esatto, era tipo Atlantis, per le emozioni.

Non ho finito di leggerlo, devo essere onesto, però quello che ho letto finora mi era piaciuto.

L'altra cosa che appunto T.S.

Pattern ho letto, una per gli amanti della programmazione funzionale in TypeScript, suggerisco anche Remote Data, un'altra libreria per gli amanti di queste cose qui, anche qua vi mando il link, che permette di usare un approccio funzionale alla cosa più comune che facciamo a front end, prendere una chiamata e gestire i casi di loading, error e success, tutti in una maniera appunto più funzionale, più pipe oriented possibile.

Io ho un balocco che non mi sembra di aver mai portato, ed è un sito, visto che abbiamo parlato di CSS, di front end, però a volte bisogna proprio, abbiamo bisogno di immagini, abbiamo bisogno di, specialmente se magari abbiamo nella mente di fare il nostro bel gioco, abbiamo bisogno proprio di grafiche che non sappiamo proprio farci da soli.

In quel caso opengameart.org è un bellissimo sito dove mettono a disposizione, tutti gli autori se vogliono, possono mettere a disposizione le loro creazioni specifiche per il gioco, però va bene un po' per tutto, ci sono anche dei background, ci sono credo anche modelli tridimensionali.

Quindi Davide, avevi detto che stavi provando, che volevi provare qualcosa sul 3D, forse qui puoi anche trovare qualcosa di carino.

Questo l'avevo anche detto in anteprima, l'avevo consigliato sul canale Telegram, qualcuno l'aveva chiesto, quindi lo dico anche in puntata.

Quasi quasi mi fate venire voglia di riprendere in mano 3JS, mamma mia.

Io, come dicevo prima, sono una capra nel design dei layout, vorrei essere più bravo, però due cosine, alla fine dopo tanto tempo, le ho imparate.

Uno dei posti dove ho imparato di più è un libro, un ebook, che potete trovare sul sito refactoringui.com, è scritto da uno dei due tizi di Tailwind, che è quello che si occupa della parte di design, è prodotto da Tailwind Labs.

È un libro che aiuta a capire dove sbagliamo nel design delle interfacce e ci spiega come e perché facciamo degli errori.

A corredo ci sono una serie di video esplicativi e poi se prendete il pacchetto super fighi da persona che flexa, avete anche delle icone, dei fonti.

Io ho preso quello più economico e mi è stato più che sufficiente.

È un po' costoso perché il pacchetto economico mi ricordo di averlo pagato attorno ai 100 euro o dollari.

Ah, ok, vedo che 99 dollari più venditi di tasse, va bene, siamo là.

Però è davvero un libro che vale la pena avere se fai front end, almeno per non fare porcherie, troppo porcherie, in un set project dove non abbiamo la possibilità di pagarci un design.

È arrivato il momento di ringraziare i donatori, coloro che supportano e ci sostengono economicamente perché kitbar è gratuito ma non senza costi.

Ogni mese infatti abbiamo tutta una serie di bollette da pagare e i donatori ci aiutano appunto a sostenere questo tipo di spese.

Questa settimana dobbiamo ringraziare Salvatore Sanfilippo, fantastico, che oltre essere stato nostro ospite la settimana scorsa ci ha donato e offerto tre birre che noi alziamo al cielo i bicchieri e brindiamo alla salute di Antireds.

Grazie! Siamo arrivati alla fine dell'episodio anche questa settimana, grazie Davide per essere venuto con noi a condividere la tua esperienza, grazie di cuore, tu ormai sei di casa qua a kitbar.

Grazie a te, a quanti episodi sei arrivato? Questo sarà il 125esimo o 126esimo.

Ecco quindi il applauso va a te per la perseveranza, è veramente un sacco di risultato, quindi grazie non solo dello spazio ma di tutto lo sbatta che ti fai.

Io Davide rinnovo appunto il ringraziamento per aver condiviso con noi le tue conoscenze, le tue esperienze e ti aspetto per parlare di 3D sul web a questo livello.

Guarda, volentieri.

Anzi prima che me lo dimentico, visto che nel lavoro non penso così da molto, se vuoi facciamo un po' di discussione su FPTS e tutte le figate che ci stanno attorno.

Ah, volentierissimo, sfondi una porta aperta.

Però dobbiamo farlo prima di dicembre, secondo me dopo le sbronze di Natale, se non lo usa ancora, penso di dimenticarmelo.

Poi volentieri con il 3D adesso vi impago qualcosa, visto che ho fatto i primi 20 minuti del corso, di un corso al momento, quindi direi che non sono sicuramente ancora la persona con cui parlarne.

Io ho questo mega punto interrogativo sull'accessibilità e 3D sul web che è ancora così che flotta nella mia testa, a quale non sono ancora riuscito a dare una bella risposta, perché secondo me c'è un buco.

Lo so, infatti è una delle mie prime domande che mi sto già facendo.

Infatti, ancora non posso fare disclosure della mia prossima avventura lavorativa, ma è una delle domande che mi sta venendo in mente.

Quanto ad ho quelle cose di saranno per un effetto wow, banalmente ininfluente sulla parte funzionale, e quanto invece ci sarà da patire per quanto riguarda l'accessibilità.

Ma lo scopriremo l'estate prossima probabilmente.

Molto volentieri, grazie di nuovo, io vi do appuntamento la prossima settimana qua su Gitbar, alla prossima.

Ciao, grazie.

Ma non abbiamo detto del gruppo Telegram? Gitbar, il circolo dei fullstack developer.

Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev..