Bene e benvenuti su GIT BAR, 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 GIT BAR.

Prima di però iniziare effettivamente con il nostro episodio, è il momento di ricordarvi rapidamente i nostri contatti.

Info.gitbar.it, etbrenrepo 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 fare gli episodi di GIT BAR, 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 e soprattutto se è bella, ci aiuta a salire sulle classifiche.

Questo non per dirci quanto siamo belli e fighi, che lo siamo pure, ce lo diciamo noi, quindi poco importa, ma è importante perché vogliamo crescere, vogliamo raggiungere nuove orecchie e 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 GIT BAR, 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.

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, ha dimenticato il pannolino qua, io quindi sto registrando con una situazione di criticità olfatica decisamente alta, ma bando alle cienze, se non svengo prima dei cinque minuti, ecco, vuol dire che riesco a resistere anche a olezzi alquanto forti.

Detto 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, ecco, 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, voglio parlare di testing.

Non ho mai fatto il testing ben fatto, mea culpa, in realtà ho imparato a utilizzare il testing con Granosalis, 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 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 che 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, prima il 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 ho come far funzionare le cose.

Ma questo è un bias? Eh 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 tests, dei code driven tests.

E questa cosa funziona, funziona se voglio mettermi un minimo di rete di salvataggio sotto le chiappe, ma esiste un altro approccio che 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ì va bene, ma anche noi quando scriviamo i test pensiamo ai vari scenari, beh io no, nel senso una serie di scenari li prendo in considerazione, 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 scenari.

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 scenari, ma se io sono un test engineer e ho come target l'esplorazione degli scenari, l'approccio a questo limite è completamente diverso, l'approccio a questa sticella, il definire il punto oltre il quale 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 scenari, perché alcuni elementi, alcuni sforzi diciamo si sovrappongono per cui non avremo abbastanza energie per farlo, tanto che 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 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 scenari.

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 su il 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 data set per il testing, la definizione dei mock e dei risultati dei mock per i testing è determinante perché figlia di analisi dei vari scenari, possibilmente dei vari scenari negativi.

E noi, o perlomeno io da sviluppatore spesso non prendo in considerazione questi scenari.

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, vi dicevo prima no, 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, 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 in alcune parte, è 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.

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.

Però ci permette di avere una visione completa della nostra applicazione e 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, attivare delle azioni correttive.

A questo punto dobbiamo realizzare, 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 Defected 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, 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 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, 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 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 a 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, ho cambiato azienda.

E ho alternato fasi in cui lavoravo su prodotti oppure lavoravo per agenzie 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 significa.

Però lavorare diciamo sulla stessa code base 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.

Di contro c'è che uno potrebbe annoiarsi a lavorare sempre sulla stessa code base, 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, diciamo passato l'entusiasmo ci sta che lavorare sempre sulla stessa cosa porti a un po' di noia, a 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 dal reparto marketing o quello che è.

Soprattutto nell'agenzia si tende magari a non badare troppo alla qualità del software, perché la consegna e 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 dell'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 è 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, partorino 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ò portare 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 o magari con l'affezione che si è provato questa cosa 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à al 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, 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 l'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 salire ai 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, si è instradati molto perché ovviamente per gestire un'azienda grande senza questo tipo di sovrastrutture 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 lei stessa.

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 Colline 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 col 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 ho visto che io forse non ho le skill per fare l'imprenditore, per fare una startup per me stesso, cioè fondata da me 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 Node.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 situazione in questo momento è l'ideale.

Lavoriamo da remoto, abbiamo pochissimi meeting, per noi sono molto felice della situazione in cui mi trovo e spero che queste digressioni possano aiutare 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 industria è 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 senza troppi rimorsi perché è bene seguire quello che uno sente e farsi un'idea del mondo del lavoro.

Eccoci qua, tema libero.

Io oggi voglio parlare di usabilità.

Perché voglio parlare di usabilità? Perché qualche settimana fa mi è capitato, scrollando su TikTok tra un balletto e l'altro, un tizio, un tiktoker abbastanza famoso in Italia ha i suoi followers, si chiama Antonio Parlato, vi consiglio di vederlo perché 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 dei suoi followers che poi hanno commentato erano mai riusciti ad arrivare a schiacciare questo deodorante loro lo usavano come si usa il dopobarba, si capovolgeva, si metteva il profumo sulle mani e poi ti mettevi le mani sotto le ascelle che proprio non è la cosa 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 deodorante, si sentiva stupido perché non erano arrivati al fatto di dover schiacciare questo deodorante.

E quindi 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 capire come funzionasse e si autoaccusavano e dicevano che siamo scemi, che siamo stupidi.

Altri utenti invece, ma c'è scritto dietro, c'era la documentazione dietro su come si usa il deodorante.

Io ce l'ho il breeze a casa, sono andato a vederlo, sinceramente non è che fosse proprio così chiara la documentazione.

Dunque diciamo che ci si poteva arrivare.

Però da lì io mi sono chiesto, ma alla fine l'azienda quanti soldi ha perso? Perché sotto c'erano davvero centinaia di commenti che dicevano ah l'ho preso una volta, mi piaceva, ma non mi piaceva 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 era un problema.

In realtà io poi ho scritto un commento dicendo sì ragazzi ma è vero tutto, siamo polli e nolleggiamo le istruzioni però alla fine l'azienda è quella che ci perde, non ci perdiamo mica noi comunque qualche altro deodorante tanto migliore o più o meno della stessa qualità lo troviamo e andiamo su quello.

Quindi c'è davvero il designer della Breeze si è lavato la coscienza dicendo eh 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 noi programmatori leggiamo sempre tutto leggiamo la documentazione del codice della libreria o andiamo direttamente a quello che ci è più intuitivo.

Certo i più fighi tra di voi diranno 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 non fa così.

E se non fa così chi è che ci perde? I programmatori ci perdono? 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 tutti, 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 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 in 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ì al centro informazioni è esasperata perché la gente non leggeva il cartello sopra con su scritto centro informazioni.

Ho detto, sì, a parte che siamo in un centro commerciale e di cartelli che ci imbadono, ne siamo pieni, quindi anche 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.

Non c'è poco 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 avanzato 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.

Cioè 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 commento sopra e dire questo, questa è una cassa o questo è un centro informazioni.

E la cosa funziona esattamente anche, secondo me, con il codice.

Sì, ci sono i programmatori che prima di scrivere due righe di codice si studiano tutto, dalla A alla Z, la documentazione, ma poi quale documentazione? La documentazione del linguaggio perché c'è linguaggio, la documentazione del framework perché c'è 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, 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 nell'accezione più primitiva dell'usabilità, quindi nel nostro campo, l'usabilità delle applicazioni.

Ragazzi in questi giorni sto vedendo dei 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, diecimila 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, molto complicata, la documentazione sono di 900 pagine, con screenshot che ovviamente 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, dobbiamo avere 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 il 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 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, 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 a raggiungerci e riusciamo a pagare le bollette.

È il momento di ringraziare davvero chi fa sì che noi possiamo pagare le bollette, possiamo acquistare le licenze e gli abbonamenti dei software che ci servono e quindi possiamo raggiungere le vostre orecchie.

Allora, 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 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 e abbiamo da ringraziare inoltre, vediamo se non perdo nessuno, Giovanni Italiano che anche lui ci ha donato una birra.

Dovremmo esserci? Sì, dovremmo esserci a posto.

Ok, allora io direi di alzare i calici, ah no, no, no, no, no, no, mi stavo dimenticando Vanni Miarelli, ahimè, scusami Vanni, scusami davvero, anche Vanni ci ha invitato 5 birre, diciamo che una sbornia natalizia su Gitbar ci sta.

Spero di non essermi dimenticato nessuno, se mi sono 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 se 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 vi manierete, è un inizio di un nuovo anno, siamo un year 2.2.new, parentesi donde, al meglio chiaramente, è 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 Pandori e 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 Natale, 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 nato, 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 i 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 pro zia 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 Gitbar e nei suoi canali, come per esempio il gruppo Telegram, chissà se gli altri amici baristi li hanno nominati.

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 liberi.

Se vi piace, scriveteci nel gruppo Telegram così che magari possiamo organizzarne qualcuna in più.

E perché no, magari fare un episodio con i vostri pensieri liberi.

Perché non iniziare a mandarci qualche vocale sui temi di cui chiacchieriamo nel nostro gruppo Telegram.

Perché no, se porta valore potremo anche strutturarci per condividerlo in puntata.

Detto questo, io vi ricordo rapidamente i nostri contanti, info.cio.editor.it e TrenRepo su Twitter, sul nostro fantasticissimo 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.

Grazie per averci fatto compagnia tutto quest'anno.

Grazie per essere la community più bella del mondo.

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 a tra qualche giorno, ma non vi dirò di più.

Un abbraccio, alla prossima.

Ciao! Hai detto la parola magica? Piantala! Maledizione! Che stronzi questo programmatore! Telefona a quelli di Metri, a Cambridge..