[Musica] Bene e benvenuti su Geekbar Nuova settimana e nuovo episodio qua sul bar degli sviluppatori Lo so, so benissimo quello che state pensando Vorreste sgridarci e ne avete tutti i diritti per farlo In realtà due settimane che non usciamo con un episodio E quindi in qualche modo volevamo, insomma, ripartire alla grande In realtà è una ripartenza un po' a singhiozzo perché ci sono le vacanze di Natale Quindi usciamo con questo episodio, avremo uno speciale natalizio a sorpresa Che poi è una sorpresa che vi ho appena svelato, quindi vabbè, lasciamo stare Avremo uno speciale natalizio e poi noi ci sentiamo dopo l'epifania Cosa manca da dire? Beh, l'episodio di oggi è un pochino diverso è una raccolta di pensieri liberi, non abbiamo messo un tema ma siamo andati un po' a braccio e quindi diciamo prendetelo un po' come un viaggio dentro quello che pensiamo spero vi piaccia come nuovo format, in realtà è un esperimento, uno dei tanti esperimenti che facciamo qua nei microfoni di Gitbar prima di però iniziare effettivamente con il nostro episodio è il momento di ricordarvi rapidamente i nostri contatti info@gitbar.it @brainrepo su twitter e se non l'avete fatto ancora e so che non l'avete fatto in molti iscrivetevi al gruppo telegram e inoltre se non l'avete fatto buttate un occhio su iTunes se riusciste a lasciarci una recensione vi prego, tanti di voi hanno l'iPhone potete farlo quindi noi investiamo il nostro tempo per far gli episodi di Gitbar, voi vi prego investite 5 minuti, entrate su iTunes cercate il nostro podcast e lasciateci una recensione, bella o brutta non importa ma lasciateci una recensione diteci quello che pensate soprattutto se è bella ci aiuta a salire su sulle classifiche questo non per dirci quanto siamo belli e fighi che lo siamo pure ce lo diciamo noi quindi poco poco importa ma è importante perché vogliamo crescere vogliamo raggiungere nuove orecchie questo è un modo interessante per farlo se poi avete qualche altro modo per farlo beh suggeritecelo e fatelo detto questo io direi che possiamo iniziare benvenuti su GITBAR il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo conclusione.Devo dire che questo è pur essendo quello meno strutturato ma è l'episodio da registrare più difficile del mondo.Io ho il mio studio in camera di mia figlia Durante la sigla è entrata mia moglie per cambiare la bambina e ha dimenticato il pannolino qua io quindi sto registrando con una situazione di di criticità olfatica decisamente alta ma bando alle cienze se non svengo prima di 5 minuti vuol dire che insomma riesco a resistere anche a olezzi ai quanto forti.Detta questa cazzata in realtà come vi anticipavo l'episodio di oggi vuole essere una raccolta di pensieri liberi senza tema proprio perché per Natale ci piacerebbe che entraste nei nostri pensieri ci piacerebbe farvi entrare in quello che pensiamo, esplorare i nostri dubbi in un modo un po' diverso per augurarvi buone feste Ognuno di noi ha preparato qualche minuto di riflessione più o meno profonda, non è quello che importa e anche io ho preparato una mia.Per la prima volta dopo tanti anni inizio io e voglio parlarvi di testing.Non ho mai fatto il testing ben fatto, mea culpa.in realtà ho imparato a utilizzare il testing con Grano Salis non so se si dica così, non ho mai studiato latino quindi prendetelo per quello che viene ma ho imparato a utilizzarlo in modo molto pragmatico perché? perché ho visto sempre il testing come quella rete che mi permetteva di non spaccare tutto quando andavo a fare una modifica e per me è sempre stato solo questo il test in realtà come scoprirete poi nella puntata speciale di Natale il test poi col tempo ho imparato a vederlo anche come uno strumento di comunicazione ma per tanti anni davvero per me è sempre stato solo il modo per non distruggere tutto ogni modifica detto questo però mi sono chiesto se esisteva un modo per fare test diverso da come lo facevo io io facevo, utilizzavo il classico approccio, test unitari, test di integrazione, al massimo test end to end e finiva tutto là tra l'altro se non mi sbaglio tra i primi episodi di gitbar trovate anche una bella puntata sulla piramide del testing e poi abbiamo fatto se non mi sbaglio anche un bell'episodio con Mattia Detto questo, in realtà ho perso un po' di tempo provando a ragionarci e provando a vedere quelli che erano i processi che si attivavano in me quando facevo il testing.Io partivo sempre da una specifica, mi concentravo sul far funzionare le cose, quindi facevo un test per quella feature, quella funzionalità, scrivevo il codice, quindi test driven design, al test poi il codice va bene la feature è finita e va bene ma in realtà quando io scrivo il test in mente ho la feature in mente o come far funzionare le cose ma questo è un bias e sì in realtà ho capito poi correggetemi se sbaglio mi piacerebbe che si attivasse anche una bella discussione all'interno del nostro gruppo Telegram, ho capito che in realtà è il bias dello sviluppatore nello scrivere il test, cioè il fatto di fare dei feature driven test, dei code driven test.E questa cosa funziona, funziona se voglio mettermi un minimo di rete di salvataggio sotto le chiappe, ma esiste un altro approccio che poi ho scoperto più legato all'approccio dei test engineers.Se io sono concentrato sul far funzionare le cose, in realtà il test engineer, l'approccio alla test engineer è concentrato, focused, sul esplorare gli edge case, pensare rispetto agli scenari.Molti di voi mi diranno "sì vabbè ma anche noi quando scriviamo i test pensiamo ai vari scenari".Beh io no, nel senso una serie di scenari li prendo in considerazione ok? I scenari worst case scenario alcuni il più possibile li prendo in considerazione ma la differenza sta nell'effort che si mette nell'esplorazione di questi scenario.Se noi da sviluppatore proviamo ad indossare anche il cappello del test engineer, quindi facciamo un cambio di cappello, ci rendiamo conto che esiste un momento dove dobbiamo per forza mettere un paletto nel dire ok ma io ho anche altri feature da fare devo per forza bloccarmi qua nell'esplorazione degli scenario ma se io sono un test engineer e ho come target l'esplorazione degli scenario l'approccio a questo limite è completamente diverso l'approccio a questa sticella il definire il punto oltre il quale ho ho time boxato quella azione è completamente diverso.Nell'episodio speciale parleremo di Sweller e di Miller che sono due scienziati che si occupano di carico cognitivo ma voglio portare già in questo episodio un ragionamento che ha fatto Sweller.Sweller dice che in realtà le capacità cognitive utilizzate per il problem solving non si sposano, non permettono di attivare nel contempo attività di apprendimento, di esplorazione e quindi nel nostro caso di analisi degli scenario, perché alcuni elementi, alcuni sforzi diciamo si sovrappongono per cui non avremo abbastanza energie per farlo, tanto che insomma Sweller argomenta dicendo che appunto l'attività di problem solving e di learning non possono convivere e ci sono tutta una serie di studi buttateci un occhio se volete insomma approfondirlo, però questo riportato al nostro approccio fa sì che in realtà noi sì possiamo impegnarci nell'indossare il cappello del test engineer, ma quanta della nostra capacità cognitiva è realmente, effettivamente in modo proficuo impegnata nell'analisi degli scenario.E certo, questo ci evidenzia una cosa importante, che se noi, per esempio, siamo impegnati a scrivere un test come developer, Quando la nostra code base si sviluppa e diventa complessa, spesso, io parlo per me, poi credo che molti di voi si riconosceranno in questo, ci siamo tentati di testare comportamenti, quindi concentrarci sul test dei comportamenti.In realtà un test scenario è fatto da due parti principali, le procedure e i dati.Quello che noi facciamo spesso quando facciamo testing da sviluppatori è concentrarci sulle procedure, ma la definizione dei dataset per il testing, la definizione dei mock e dei risultati dei mock per i testing è determinante perché figlia di analisi dei vari scenario, possibilmente dei vari scenari negativi e noi o perlomeno io da sviluppatore spesso non prendo in considerazione questi scenario.Un altro ragionamento interessante da fare è che se lo sviluppatore ragiona in termini di test come strumento del suo processo di creazione di lavoro, probabilmente avere un approccio più strategico al testing può essere in qualche modo più proficuo, specie se la codebase si complica, se i team sono grandi, i worst case scenario sono tanti e quindi abbiamo bisogno di fare questo tipo di approccio.Quindi se io mi scrivo i test come rete di salvezza per non schiantarmi a terra un po' come nei circo, come vi dicevo prima, il circo dove ci sono i trapezisti che si lanciano da una parte all'altra, il mio testing è la rete che gli permette di non spiaccicarsi al centro dell'arena.Ma un altro modo di fare test è un modo strategico per farlo.questo vuol dire contemplare tutto il processo di vita del testing il prima, il durante e il dopo.Il prima possiamo vederlo come la scrittura di un piano di test, un test plan che partendo dai requirements prova a capire come ci si deve muovere strategicamente nei test e qua sfido qualunque sviluppatore di qualunque progetto se ha mai fatto un test plan.Io da sviluppatore non mi ci sono mai posto il problema e questa roba è stata come tipo aprire un vaso di Pandora.La seconda parte che poi è quella del durante che è fatta appunto anche in parte dallo sviluppatore quindi questo è il ruolo del test engineer e dello sviluppatore in qualche modo overlappano alcune parte e la scrittura dei test e l'analisi degli scenario.In questo caso per esempio è super interessante un tool, vi lascio il link nelle note dell'episodio, che è la Traceability Matrix, che ci permette di capire in realtà di tracciare cosa stiamo coprendo e dove stiamo coprendo.e lo sviluppo di una Traceability Matrix è uno strumento molto più importante, cioè molto più completo dal mio punto di vista rispetto alla Code Coverage che è lo strumento che utilizziamo di solito per misurare, per capire in fase di scrittura dei test cosa stiamo lasciando fuori.per noi, ma noi ragioniamo in righe di codice, ma il vero valore delle righe di codice a livello di business, come lo analizziamo, che copertura stiamo facendo, dove sono i difetti, quali sono i difetti di feature, quali sono i difetti di codice, tutto questo mondo tutto questo dubbio è fuori dal contesto che noi da sviluppatori consideriamo e però ci ci permette di avere una visione completa della nostra applicazione soprattutto un approccio quality driven.A questo punto abbiamo anche un dopo.Il dopo sono le metriche.Prima vi dicevo noi utilizziamo il test coverage ma è sufficiente come metrica? Perché testiamo? Se i nostri test sono solo una rete di sicurezza il test coverage è sufficiente.Se i nostri test servono per non permettere il bubble up di bug e soprattutto per la definizione di nuove strategie che migliorino la limitazione di questi bubble up di errori verso l'utente, a quel punto dobbiamo attivare una strategia proficua che valuta i test come degli risultati che devono triggerare e attivare delle azioni correttive.A questo punto dobbiamo realizzare insomma, dobbiamo prendere in considerazione delle nuove metriche oltre alla test coverage, dobbiamo prendere in considerazione il costo del testing per esempio, il tempo di running del testing, la qualità dei test, dobbiamo che ne so calcolare la distribuzione dei difetti che trova il testing quindi in quali aree di codice e poi ci sono un gozziliardo di API che mi hanno completamente sconvolto la vita, dei KPI scusatemi, che in realtà mi fanno capire che il testing ha un impatto molto più ampio di come l'avevo visto finora.Vi faccio un esempio c'è una KPI che si chiama la Defect Density dove si prendono in considerazione il numero dei difetti paragonato con la loro dimensione in un modulo software cioè quanti difetti i nostri test riescono a individuare in funzione della dimensione del difetto stesso o della dimensione del modulo che è meglio oppure quanti test superano quanti difetti superano le nostre test suite e vanno a schiantarsi con l'user acceptance testing, quindi diciamo il feature test fatto dal PO che va a provare la nostra applicazione o vanno a finire dentro l'utente.Noi le stiamo tracciando queste KPI, abbiamo attivato dei processi per migliorarci da questo punto di vista, oppure l'efficienza nella rimozione del difetto, entro quanto tempo noi fissiamo un difetto trovato da un test o un'altra cosa fighissima che ho trovato, un'altra KPI fighissima che ho trovato è la defect category, io sto runnando la mia test suite e capire quali difetti la mia test suite trova in funzione di alcuni elementi percettivi dell'utente quindi che ne so utilità, performance, credibilità ok guarda questo bug trovato dal test pinco pallo avrebbe inficiato in credibilità quindi il rischio è alto per cui dobbiamo impegnare risorse e tempo in questo modo Vi ho citato alcune delle KPI, in realtà c'è un bellissimo blog post dove se ne parla in modo intensivo, ma a chiudere questo ragionamento voglio semplicemente dirvi una cosa.Fare il test per quanto noi ci mettiamo di buona lena talvolta è una rotola di balle e se noi lo adoriamo, come per noi è importante e quindi lo facciamo, spesso per il management non è importante.E allora come si fa a percepire importante il test? Lo si fa utilizzando un approccio di tipo strategico, lo si fa coinvolgendo il business, coinvolgendo tutti gli stakeholder che vogliono creare un prodotto e dando gli strumenti che parlino la loro lingua.Per cui è necessaria la definizione di un approccio strategico e non tattico al test perché la tattica è lo strumentino, il trecchino che io uso per raggiungere rapidamente il mio obiettivo, la strategia è un qualcosa di più ampio, più olistico che abbraccia diverse parti.Quindi se noi da sviluppatori spingiamo verso un approccio strategico al testing, se noi costruiamo dei ponti verso gli stakeholder coinvolgendoli attraverso per esempio le KPI, KPI che arrivano a toccare, che ne so, i punti che interessano all'utente, la credibilità, la performance, l'utilità e l'individuazione di difetti prima che arrivino all'utente in questo scopo, in questo contesto, sotto questo frame noi riusciamo, utilizzando questo approccio, a avere budget e tempo per il testing quindi trovare il modo abbastanza semplice o quantomeno effettivo, funzionale per parlare col business e far capire che il test è importante.E allora di chi è la colpa se il business ti dice "il test non è importante"? Probabilmente in parte anche nostra, perché trattiamo il test solo come una rete di sicurezza.Ciao a tutti, in questo intervento volevo parlare un po' del mondo del lavoro quindi quello che dico probabilmente sarà più utile ai giovani o chi sta iniziando o ha iniziato da poco la carriera in questo mondo.Io ho avuto la fortuna, o comunque l'occasione, di lavorare con diverse realtà praticamente guardando il mio LinkedIn più o meno ogni due anni ho cambiato lavoro o ho cambiato azienda e ho alternato fasi in cui lavoravo su prodotti oppure lavoravo per agenzia o in consulenza e trovo che ci possono essere vantaggi e svantaggi in entrambi questi mondi.Lavorare su un prodotto è un po' come crescere un bambino, posto che io non avendo figli non so esattamente cosa cosa significhi, però lavorare diciamo sulla stessa codebase in un team, si ha la sensazione di rimare tutti dalla stessa parte, si percepisce il progresso, l'evoluzione del prodotto che stiamo facendo e si copre tutto il ciclo di vita di un software, quindi dalla progettazione, l'architettura, lo sviluppo, il testing, manutenzione, refactoring, documentazione, magari gestione anche della community, quindi diciamo che si ha un ampio spettro delle skill che servono per fare questo lavoro e di contro c'è che uno potrebbe annoiarsi a lavorare sempre sulla stessa codebase, a seconda delle dimensioni del prodotto si percepisce l'intervento di diverse persone, quindi diversi stili all'interno del codice e questa cosa può anche essere frustrante a un certo punto, passato l'entusiasmo ci sta che lavorare sempre sulla stessa cosa porti a un po' di noia un po' di poca voglia di fare.Lavorare invece in agenzia o in consulenza ci porta in tutto un altro mondo.Sull'agenzia, almeno per quello che è la mia esperienza, si ha la possibilità di lavorare su più progetti contemporaneamente.Il che, rispetto a lavorare su un singolo prodotto, può portare comunque a un lavoro più dinamico, perché magari si cambia ogni giorno, all'interno della stessa giornata, il progetto su cui si lavora.chiaramente ci possono essere progetti che piacciono di più e che piacciono di meno non li possiamo scegliere noi perché di solito arrivano da il reparto marketing o quello vendito o quello che è e soprattutto nell'agenzia diciamo che si tende magari a non badare troppo la qualità del software perché la consegna la consegna quindi bisogna rispettare i tempi, quindi non sempre si ha quella qualità che uno potrebbe auspicare.Nella consulenza diciamo che spesso quello che può succedere è di lavorare, per esempio nella mia esperienza io ho in Irform iniziato come sviluppatore, poi sono passato a fare il DevOps perché era un ambito che mi interessava sviluppare e all'interno l'azienda c'erano progetti in cui anche un DevOps junior poteva intervenire, quindi anche qui si possono sviluppare determinate skill.È vero che si ha sempre a che fare con un cliente esterno che spesso se chiede la consulenza non è, diciamo, non è pratico di questo mondo quindi bisogna interfacciarsi in una certa maniera.Il problema è che, almeno quello che ho percepito io, è che è come fare una gravidanza, prendo sempre questi esempi, partorire un bambino e poi lasciarlo a qualcun altro perché il prodotto poi viene consegnato e magari non ci si mette più in mano.E questo a lungo andare può può portare un po' a una specie di stress perché tutto il lavoro che si fa poi a un certo punto viene dato in mano a qualcun altro che magari ci mette le mani sopra e non è una bella sensazione anche se poi si passa a un altro progetto magari con l'affezione che si è provato questa cosa appunto può essere stressante.Per quanto riguarda l'avanzamento di carriera o di posizione o di seniority, io ho trovato queste due strade.All'inizio, quando mi sono affacciato dopo l'università del mondo del lavoro, la mia idea era quella di essere sviluppatore e dopo un po' salire di carriera per cominciare magari a gestire un team a livello tecnico e poi magari avere delle posizioni più manageriali dove per forza ti stacchi dal codice e ti occupi più di gestione progetti o prodotti, appunto persone eccetera.Ho notato però che personalmente io queste skill non le ho o non le ho mai ricercate troppo e poi mi sono chiesto "ma allora uno cosa fa? Sviluppa per tutta la vita?" può darsi.Un altro, andando nella direzione opposta, uno si può verticalizzare su una tecnologia, quindi diventare un ottimo sviluppatore su PHP, JS o quello che è, conoscere internals, magari partecipare alla scrittura proprio del core, del codice, diventare molto esperto e anche in quel caso aumentare il proprio capitale umano, detto in soldoni, farsi pagare di più perché sei in quella nicchia, in quel 0,1% delle persone nel mondo che conoscono quella tecnologia in maniera così approfondita.Quindi non per forza bisogna essere su...salire i piani, immaginando un grattacielo, andare ai piani alti a gestire, ma si può rimanere nel basement a programmare però con una conoscenza molto fine della tecnologia di cui siamo esperti.Anche le dimensioni dell'azienda possono contribuire ad avere un miglior rapporto con il proprio lavoro, anche qui dipende dai gusti.Lavorando in un'azienda molto grande abbiamo meno rapporti umani con i piani alti, è tutto molto più strutturato, ci sono procedure da seguire per qualsiasi cosa, sia in stradati molto perché ovviamente per gestire un'azienda grande senza questo tipo di sovrastrutture non sarebbe ingestibile per i manager.In un'azienda piccola si ha sicuramente un rapporto più umano sia con i peers ma anche con i manager, c'è sicuramente più elasticità, magari è più difficile creare, essere in una realtà importante perché poi una realtà quando diventa importante per forza di cose vuole crescere il suo business e cresce e cresce lei stessa.E sicuramente anche in un'azienda piccola, in un team piccolo diciamo, si deve fare tutto, non per forza bisogna essere legati alle nostre skill, ma magari c'è da ordinare le magliette per Natale e anche un programmatore si deve mettere lì a farlo, non essendoci un dipartimento specifico per questo task.Attualmente io lavoro per Platformatic, che è una startup fondata da Matteo Collinea e Luca Maraschi e ho trovato probabilmente la quadra per il momento storico in cui mi trovo, perché il team è piccolo.Ho un rapporto molto personale con Matteo che è il mio capo, ma anche il mio mentore e quindi mi trovo molto bene, non ho diciamo problemi a parlare con il mio boss.Si porta avanti un prodotto, quindi ora sono nella fase di prodotto e mi piace molto l'ambiente startup perché è tutto molto elastico e malleabile ma stiamo andando tutti nella stessa direzione.Ci conosciamo tutti quasi di persona anche se siamo un po' sparsi per il mondo quindi c'è anche una contaminazione culturale da parte degli altri membri del team e soprattutto visto che io forse non ho le skill per fare l'imprenditore, per fare una startup per me stesso, fondata da me e portarla avanti.Però ho la fortuna di avere incrociato Matteo che ha fatto questo passaggio, nonostante sia una persona molto tecnica, è diventato imprenditore e mi piacerebbe continuare a lavorare con lui, non per forza su quello che stiamo facendo oggi, perché magari tra cinque anni potremmo essere a lavorare da un'altra parte, ma questa fiducia che c'è tra il lavoratore, l'operativo che sono io e il capo porta per me a specializzarmi di più sulla parte tecnica di No JS e delle tecnologie che ci girano intorno senza dover pensare di dover per forza diventare un manager o gestire le persone.Ho già la persona che lo fa per me e diciamo questa questa situazione in questo momento è l'ideale.Lavoriamo da remoto, abbiamo pochissimi meeting, sono molto felice della situazione in cui mi trovo e spero che queste queste digressioni possono aiutare appunto chi si avvicina a capire un po' come può essere il mondo del lavoro anche se raccontato da una persona qualunque quale sono io.Il consiglio che vi do è provate, cambiate ancora questa industry è abbastanza drogata per cui ci si può permettere di lasciare il lavoro e aspettare un paio di settimane per trovare un altro.Non legatevi troppo a una situazione dove non vi sentite a vostro agio ma cercate la vostra condizione ideale sapendo che questa può cambiare.Io ve l'ho detto ogni due anni ho cambiato lavoro e sono passato da prodotto a consulenza eccetera senza senza troppi rimorsi perché è bene seguire quello che uno sente e farsi anche un'idea del mondo del lavoro.Eccoci qua tema libero, tema libero io oggi voglio parlare di usabilità perché voglio a parlare di usabilità, ma in realtà perché di recente, qualche settimana fa, a me è capitato, scrollando su TikTok tra un balletto e l'altro, un tizio, un TikToker abbastanza famoso in Italia, cioè abbastanza famoso, insomma, ha i suoi followers, si chiama Antonio Parlato tra l'altro, vi consiglio di vederlo perché fa delle cose sull'inglese, insegna alcuni trick sull'inglese, però in realtà non è quello il tema del video, in realtà lui stava vedendo, era un video leggero, non aveva niente a che fare con l'inglese, aveva visto il video di un altro tizio che usava il deodorante Breeze, avete presente il deodorante Breeze? È quel deodorante dove con una forma un po' bombata tu devi schiacciare per far uscire uno spruzzo di deodorante.Ecco, a quanto pare né lui né una moltitudine di dei suoi followers che poi hanno commentato erano mai riusciti ad arrivare a dover schiacciare questo deodorante.Loro lo usavano come quasi come si usa il dopobarba, quindi si capovolgeva, si metteva il profumo sulle mani e poi ti mettevi le mani sotto le ascelle che proprio non è la cosa proprio bellissima.La cosa che mi ha colpito è che lui, come tutte le altre persone che hanno commentato nei commenti dicendo che avevano avuto la stessa esperienza, dicendo che anche loro non avevano capito come si utilizzasse il deterente, si sentiva stupido.si sono sentiti stupidi perché non erano arrivati al fatto di di dover schiacciare questo deodorante e quindi si autoaccusavano, si autoaccusavano anche se erano centinaia, forse migliaia di persone che dicevano che non l'avevano nemmeno capito, che l'avevano comprato, quindi lo volevano utilizzare magari lo reputavano anche buono però non erano riusciti a a capire come funzionasse si autocusavano e dicevano "ah ma che scemi che siamo, ma quanto siamo stupidi" altri utenti invece "eh ma c'è scritto dietro, c'era la documentazione c'era la documentazione dietro su come si usa il deodorante" io ce l'ho il brisa a casa, sono andato a vederlo sinceramente Non è che fosse proprio così chiara la documentazione comunque diciamo che si poteva ci si poteva arrivare però da lì io mi son chiesto ma alla fine l'azienda quanti soldi ha perso perché c'erano sotto c'erano davvero ragazzi centinaia di commenti che dicevano "ah l'ho preso una volta, mi piaceva, ma non non mi piaceva come come veniva usata".Ma tanti! Ma quanti soldi avrà perso l'azienda? Ma sul serio allora è colpa degli utenti tutto questo? Cioè è colpa degli utenti se non capiscono come utilizzare un prodotto dell'azienda? O è l'azienda? O è chi ha disegnato il deodorante che doveva porsi quantomeno il dubbio, la domanda perché non stiamo vendendo questo deodorante qui magari anche investire in pubblicità e farlo vedere se proprio se proprio questo problema in realtà io poi ho scritto un commento dicendo "sì ragazzi ma è vero tutto siamo polli e non leggiamo le istruzioni, però l'azienda alla fine è l'azienda quella che ci perde, non ci perdiamo mica noi perché noi comunque qualche altro deodorante tanto tanto migliore o più o meno della stessa qualità lo troviamo e andiamo su quello quindi c'è davvero il designer di questo della breeze si è lavato la coscienza dicendo "e se gli utenti non leggono le istruzioni che abbiamo messo dietro, non è colpa mia No secondo me assolutamente no, è proprio colpa tua ed è tua responsabilità poi è vero la gente non legge la documentazione anche anche noi programmatori, noi programmatori leggiamo sempre tutto leggiamo leggiamo la documentazione del codice della libreria o andiamo direttamente a quello che ci è più intuitivo certo i più fighi tra di voi diranno "ah io leggo tutta la documentazione dalla prima all'ultima riga prima di scrivere un pezzo di codice" bravissimi siete delle perle rare in realtà la maggior parte delle scimmie presente la maggior parte delle scimmie non fa così e se non fa così chi è che ci perde? i programmatori ci perdono? no no i programmatori il compitino lo portano a casa in un modo o nell'altro con qualche bug di qua e di là perché non hanno letto bene, però alla fine chi ci perde? Ci perdono gli utenti.E di chi è la responsabilità? Sì, oddio, qui la responsabilità forse è del programmatore, ma è davvero di tut...nella totalità, la totale responsabilità è del programmatore? qui avrei un po' di dubbi, un po' di domande perché poi alla fine tu sei un'azienda che fa una libreria che viene usata da programmatori che fanno app, fai parte di una catena, fai parte del risultato del prodotto finale ed è il tuo lavoro, il tuo compito fare le cose ...fare le cose in modo semplice, in modo che i programmatori non dico che non possano sbagliare ma che lo possano fare in modo meno probabile, abbiano meno probabilità di sbagliare e poi quante volte, anche quando noi leggiamo la documentazione, quante volte ci imbattiamo in documentazione che poi alla fine non è vera o è scaduta, è datata o è addirittura imprecisa proprio alla radice.Quante volte? E qua anche qua c'è un'altra bellissima esperienza.Io ero a MediaWorld qua a Bolzano e c'erano le casse che in realtà sono due file di quelle che sembrano casse mentre in realtà una fila è il centro informazioni con delle specie di casse davanti che sembrano casse ma che non sono casse e un'altra fila ci sono le casse vere e proprie dove vai a pagare e un sacco di gente ovviamente si mette in fila nel centro informazioni che è anche la prima cosa che tu vedi convinta di essere in fila per la cassa e mi è capitato appunto una volta che l'impiegata che stava lì nel centro informazioni è esasperata perché la gente non leggeva il il cartello sopra con su scritto centro informazioni detto sì, a parte che siamo in un centro commerciale e di cartelli che ci imbadono ne siamo pieni quindi anche lì andare lì a pretendere che la gente legga quando la gente che fa vede una cassa o quello che crede essere una cassa e va C'è poco da da opinare però la cosa bella è stata quando poi questa signora si lamentava con me, io in realtà ero lì proprio per chiedere informazioni quindi ero nella fila giusta e si lamentava del fatto che la gente non leggesse.Io però guardo in alto e lei stava in una cassa che non era cassa con sopra scritto "chiuso" allora io che dovevo fare? ho alzato lo sguardo e ho detto "ma io posso stare qui perché qua sopra leggo chiuso" e lei "no no no siamo aperti" "sì ma è chiusa questa cassa" no no no mi dica mi dica ok allora dobbiamo leggere ma non dobbiamo leggere però a volte dobbiamo leggere e dobbiamo interpretare com'è che funziona.La cosa ragazzi si risolve secondo me alla radice si risolve facendo le cose in modo che non si possa sbagliare magari non metti il centro informazione vicino alle casse con delle casse che non sono casse ma che sembrano casse le metti da un'altra parte le fai di un colore diverso ti ingegni a fare qualcosa ma in realtà non ti devi lavare la coscienza mettendo un un commento sopra e dire questo questa è una cassa o questo è un centro informazioni e la cosa funziona esattamente anche secondo me con il codice si ci sono i programmatori che prima di scrivere due righe di codice si studiano tutto dalla la Z, la documentazione, ma poi quale documentazione? La documentazione del linguaggio perché c'è linguaggio, la documentazione del framework perché c'è il framework, la documentazione della libreria perché c'è la libreria, in ogni singolo dettaglio per fare una cosa accurata e magari anche di ricerca sì ma a volte magari anche l'esigenza e magari la compagnia, l'azienda non richiede tutta questa estrema cura nel fare qualcosa perché magari serve che funzioni e basta non serve che sia iper ottimizzata al massimo perché magari le ottimizzazioni quelle vere sono da fare da un'altra parte però se lì mi metti nelle condizioni di scrivere un codice che però magari può nascondere un bug da qualche parte che tu nella documentazione a pagina 17 in una nota mi hai detto stai attento a questo comportamento perché potrebbe essere inatteso no secondo me non funziona ed ovviamente vale con il codice e vale nella nell'accezione più più più primitiva dell'usabilità quindi nella nel nostro campo l'usabilità delle applicazioni ragazzi in questo in questi giorni sto vedendo delle gestionali e delle applicazioni che si vede che sono state fatte assolutamente fregandosene di quello che può essere qualsiasi tipo di pensiero dell'utente e sto vedendo gestionali senza alcuna cura per l'armonia per la facilità d'uso bottoni 10.000 bottoni tutti dello stesso colore, che fanno tutte cose diverse, bottoni troppo vicini, si vedeva proprio che era un qualcosa.Abbiamo questa funzionalità, mettiamola là, un bottone, scriviamo nella documentazione quello che il bottone che ti serve per fare questa cosa, sta lì e via.Certo, però la documentazione, alla fine l'applicazione, essendo anche molto complessa e molto complicata, la documentazione sono di 900 pagine con screenshot che ovviamente non sono eventualmente non sono nemmeno attuali perché magari nel frattempo si sono aggiunti altri campi altri bottoni per cui anche lì la documentazione è opinabile e basta ci si lava le mani così dicendo tanto c'è la documentazione adesso le cose le applicazioni determinate anche applicazioni, è vero, a volte sono troppo complesse, a volte dobbiamo accettare il fatto che per guidare un aereo dobbiamo avere nella cabina di pilotaggio una caterva di pulsanti e quant'altro, è vero, ma un minimo minimo minimo minimo di cura e di amore verso chi alla fine dovrà utilizzare questa applicazione che poi magari, come nel caso dell'aereo, servirà per portare a salvo delle persone da un punto all'altro del mondo, ma può servire in generale per qualsiasi cosa.Dobbiamo sforzarci, quello che ho imparato io, dobbiamo sforzarci di rendere le cose semplici.Questo è un lavoro, porta un sacco di lavoro, ma un un sacco, un sacco, perché ho avuto esperienza di programmare qualcosa sotto la supervisione di una persona che era maniacale dell'usabilità è una rottura di scatole però però però i risultati alla lunga si vedono e quando vediamo perché questa applicazione ha più successo di un altro, perché un linguaggio ha più successo di un altro e vediamo che alla fine il motivo è sempre quello la facilità di utilizzo la documentazione che serve, dove serve, quando serve esempi, tanti esempi, perché poi alla fine il 99% delle scimmie presente fa quello, copia e incolla copia e incolla dalla stack overflow, dalla documentazione e poi adatta almeno per quello facciamo le cose in modo che minimizziamo il rischio di errore.Questo è quanto.Ciao a tutti! è il momento di ringraziare chi ci sostiene e fa sì che insomma riusciamo raggiungerci vi e riusciamo a pagare le bollette [Musica] momento di ringraziare davvero chi fa sì che noi possiamo pagare le bollette possiamo acquistare le licenze gli abbonamenti dei software che ci servono e quindi possiamo raggiungere le vostre orecchie.Abbiamo una serie di donazioni quindi da salutare da ringraziare anche perché con due settimane che non siamo usciti probabilmente si sono un po' accumulate quindi iniziamo a partire da un donatore misterioso che ha nascosto la sua identità e dice grazie mille per tutto quello che condividete ascoltarvi è sempre un piacere grazie donatore misterioso c'è scritto tenetelo per voi ma noi volevamo comunque ringraziarti in modo pubblico ma misterioso appunto e se la UI di PayPal non mi ammazza, nel senso che scrollare è impossibile visto che c'è un header che sparisce mentre sto scrollando.Abbiamo anche da ringraziare Roberto Izzo perché ci ha donato una birra, quindi grazie Roberto.Abbiamo da ringraziare inoltre, vediamo se non perdo nessuno Giovanni Italiano che anche lui ci ha donato una birra dovremmo esserci? sì dobbiamo dovremmo esserci a posto a posto ok allora io direi di alzare i calici a no no no no no no mi stavo dimenticando Vanni Miarelli e ahimè, scusami Vanni, scusami davvero, anche Vanni ci ha invitato 5 birre, diciamo che ecco, una sbornia natalizia su Gitbar ci sta spero di non essermi dimenticato nessuno, se mi son dimenticato qualcuno recupererò al prossimo episodio, io vi ringrazio di cuore perché grazie anche al vostro supporto che ogni settimana riusciamo ad arrivare, quasi ogni settimana ad arrivare alle vostre orecchie quindi vi dico grazie di cuore e cin cin carissimi amici, compari, sodali, videoterminalisti, metalmeccanici è stato un anno complicato, è stato un anno lungo almeno per me È stato però un anno emozionante, io spero che sia stato un anno molto lungo anche per voi, lo sia stato per gli stessi motivi per cui lo è stato per me.Io, da parte mia e chiaramente da parte di tutti quelli che mi stanno accanto dello staff di Hitbar, vi auguro e vi auguriamo quindi un buonissimo Natale, delle buonissime feste, come è buonissimo il pandoro che sicuramente ve mangerete è un inizio di un nuovo anno, diciamo un "year 2.2.new" al meglio chiaramente E' già passato un minuto, io non mi resta altro che alzarmi dalla sedia e tornare, chiudere i terminali e tornare a mangiare perché finalmente è quel periodo dell'anno in cui i Pandori e i Panettoni invadono le nostre tavole e abbiamo quella scusa, quel piccolo, quella virgola di tempo in più, quello scampolo di giornata libero da dedicare ai nostri side project oppure semplicemente alla nostra famiglia perché male non fa tra l'altro prima che la mia ragazza mi manda a quel paese forse sarebbe ora appunto di spegnere il computer.Ecco ancora un ottimo buon nadale, buon anno, buon tutto, ma soprattutto buon hacking, carissimi.Concludendo, volevo fare un augurio a tutti gli ascoltatori di Gitbar di passare queste feste in serenità, possibilmente in ferie se vi è concesso, e approfittate di questi momenti magari un pochino più rilassati a cavallo dell'ultimo dell'anno per dare un'occhiata al mondo open source, per cominciare a contribuire al software open source, perché è un ottimo passatempo che aumenta le vostre skill, Aumenta anche la vostra visibilità e appetibilità da parte di chi vuole offrire un lavoro ed è un gesto per rendere alla community tutto ciò che la community open source ha sicuramente dato per voi perché se lavorate in questo mondo quasi sicuramente lavorate con prodotti o tecnologie che sono open source Quindi di nuovo buon Natale, buone feste e ci sentiamo la prossima volta, probabilmente il prossimo anno, 2023, per chi sta ascoltando questo podcast in ritardo.Grazie ancora per il supporto e per tutti i feedback che ci date.Auguri! Auguri, auguri e ancora auguri! Buon Natale a tutti voi ascoltatori ma soprattutto amici di Gitbar.in questo anno dove abbiamo parlato di felicità, di etica, di domotica, di front-end e romanzi, di intelligenza artificiale, database, ma soprattutto abbiamo parlato del nostro amato PHP.In questo anno dicevo abbiamo imparato a conoscerci, abbiamo discusso, parlato, ci siamo confrontati, in una parola siamo cresciuti o come mi piace dire siamo persone migliori, siamo diventati persone migliori.E oggi che è Natale siamo anche addirittura più buoni, buoni come il Pandoro.Il panettone no perché i canditi piacciono solo ai criminali e non negate.E se vi sembra questo messaggio forse troppo natalizio è perché vi manca lo spirito del Natale e lo so perché vi manca lo spirito del Natale perché già vi vedete a dover spiegare il vostro lavoro ai parenti a tavola durante il cena o il pranzo di Natale, a quello zio che vi estorcerà una promessa di sistemare il suo computer, di dover spiegare che no, anche se la lavatrice ha un touchscreen e voi non avete nessuna idea di come aggiustarla, e se la prozia ancora vi dice che dovreste smetterla di giocare al computer e trovarvi un lavoro vero, beh fate un respiro profondo e pensate che potete sempre trovare una birra fresca quando volete e quante volte volete qui nel nostro github e nei suoi canali come per esempio il gruppo telegram chissà se gli altri amici baristi l'hanno nominato.Siamo aperti a Natale e durante le feste sfogatevi con noi e beviamo insieme.Auguri! Spero che questo nuovo format vi sia piaciuto in realtà vi svelo un segreto io ho una nave tra poco e non ho più voce veramente non ho minimamente nessuna voce perché ho registrato anche lo speciale di Natale che spero vi piaccia e spero che vi piaccia anche la puntata di oggi insomma questa raccolta di pensieri di pensieri liberi se vi piace scriveteci nel gruppo telegram così che magari possiamo organizzarne qualcuna qualcuna più e perché no magari fare un episodio con i vostri pensieri liberi perché non iniziate a mandarci qualche vocale sui temi di cui chiacchieriamo nel nostro gruppo Telegram? Perché no, se porta valore potremo anche condividerlo, strutturarci per condividerlo in contatto.Detto questo io vi ricordo rapidamente i nostri contanti @fochiosameditware.it e @etbrenrepo su Twitter sul nostro fantastichissimo gruppo Telegram.Vi anticipo che per il nuovo anno ci saranno tante e tante e tante novità.Non ultimo lo store con le magliette che ho quasi finito e poi insomma abbiamo un po' di roba che polla in pentola che però vi sveleremo a tempo debito.Detto questo Io vi ringrazio nuovamente e grazie per averci fatto compagnia in tutto quest'anno, grazie per essere la comune di più bella del mondo, e tanti auguri di buon Natale, di buone feste, e con l'augurio di essere più elfo birbante e meno Grinch.Detto questo io vi do appuntamento tra qualche giorno, ma non vi dirò di più.Un abbraccio, alla prossima.Ciao! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.Ciao!
