Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori Lo so, lo so, è passato un po' di tempo dall'episodio del FosDEM in realtà l'avete sentito qualcosa tipo due settimane fa però da questo momento effettivo sono solo passate alcuni giorni e io mi sto ancora riprendendo devo dire che è stato un po' faticoso 1600 1700 km in totale tra andata e ritorno in macchina poi due giorni di conferenza a bella attesa quindi insomma adesso andiamo slow ma Geekbar non si ferma infatti oggi registriamo un nuovo episodio.Di cosa andiamo a parlare oggi? Oggi per un attimo ho avuto un flashback e sono tornato indietro una decina d'anni fa così a spanne più o meno sì una decina d'anni fa quando ancora lavoravo in PHP c'era Symfony, c'era Behat c'era il Gherkin e c'era Selenium.Io lo ricordo bene quel momento.Da allora ad oggi nel mio percorso professionale tante cose sono cambiate così come buona parte dell'ecosistema è cambiata però l'esigenza di fare dei test end to end rimane e forse è sempre più forte di ieri.Ma la puntata di oggi non è un mio monologo sul test end to end per quello trovate uno o due episodi dove sproloquio per qualche buona mezz'oretta sul testing ma abbiamo un super ospite un ospite che vi presento subito dopo avervi ricordato rapidamente i contati.Info@gitver.it e @brainrepo sono su twitter sono i modi canonici per contattarci.Esiste però il gruppo telegram che ormai buona parte di voi conoscono ma non tutti per cui se ci state ascoltando e non vi siete ancora iscritti al gruppo telegram sappiate che è là che succedono le cose è là che trovate tutti gli stimoli e le robe fighe e incontrate la nostra community di più di 1200 membri.Detto questo io direi che vi ricordo rapidamente due cosine.A) Gitbar ha completamente eliminato le pubblicità, è stata una scelta non troppo sofferta ma abbastanza determinata quindi da queste puntate in poi non sentirete almeno per ora nessun tipo di pubblicità.Questo ci è utile per le transcription in modo da avere dei punti fermi su cui appunto tarare e marcare ogni parola, visto che le pubblicità di Spreaker erano una roba, la roba meno reliable del mondo cioè facevano shiftare la lunghezza dell'episodio a fisarmonica in modo non predicibile.Quindi se insomma ci volete supportare avete un modo per farlo andate su iTunes, lasciateci un commento, una stellina o una stellina su Spotify oppure supportateci con una donazione.Non perdo troppo tempo per questo e andiamo subito al solo.Benvenuti su GITBAR, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.[Musica] eccoci qua eccoci qua l'ospite di oggi è Giovanni Rago, Head of Customer per Solutions per Checkli è un ambassador, uno dei pochi ambassador di Playwright e anche host del canale YouTube Automate Together.Ciao Giovanni! Ciao, piacere di essere qui! Il piacere è tutto nostro, finalmente riusciamo a registrarla questa puntata devo dire che con Giovanni avevamo pianificato questa registrazione da un po' di tempo no? sì è vero è vero qualche settimana ma per me sono volati a dire il vero periodo intenso anche per me devo dire levami una curiosità Head of Customer Solutions che è? eh lo so è difficile è difficile trovare il nome giusto per questo genere di posizioni è un po' ibride che trovi spesso nelle startup anche no? In generale allora se lo devo spiegare con cioè che cosa fa Customer Solutions & Checklist che è un team piccolino siamo io e altri due ragazzi e è un po' una fusione fra il Solutions Engineering che già come nome so per tanti che non come dire non non l'hanno mai sperimentato sembra la cosa più generica del mondo, Solutions engineering, anche conosciuto come sales engineering e con altri 30 nomi e customer solution, customer success management quindi al di là dei paroloni che cosa si fa? Si lavora coi coi clienti e coi futuri clienti lato tecnico, quindi ho una formazione da informatico però non lo so all'inizio della mia carriera sono devo aver fatto un passo falso sono finito più lato sales diciamo e no adesso scherzi a parte mi piace sempre molto lavorare con i clienti e vedere i business di diverso tipo come si interfacciano con le tecnologie e come ad esempio insomma quella che offre che offre che offre che offre che offre che offre che offre che offre che quindi io in sostanza faccio un ruolo in questo momento che è ibrido siamo appunto un team piccolino quindi non faccio management tutto il tempo e sono sono diciamo part time manager se vuoi e sono anche sempre molto front line sul solutions engineering e in generale provo diciamo a stare a fianco dei nostri dei nostri clienti e ad aiutarli ad ottenere il massimo nel campo specificatamente in questo caso del synthetic monitoring.Ecco ci racconti rapidamente perché è una cosa che mi ha incuriosito da subito no? Cosa ha fatto Incecly e cos'è il Synthetic Monitoring? Sì allora il Synthetic Monitoring è una possiamo dire una una branca del del monitoring no? Che ovviamente può voler dire tante cose nello specifico il Synthetic monitoring è quella parte di monitoring che crea traffico sintetico per andare a verificare lo status di un sistema, sistema che può essere un API può essere che ne so una web app no? Noi quindi che cosa andiamo a fare? L'esempio più noioso del mondo, se il cliente, il nostro cliente magari che ne so gestisce uno web shop di un qualche tipo no? Il cliente va ad identificare quelli che sono i, diciamo, quelli che chiamiamo Key User Flows, quindi i percorsi utente più importanti che appunto nel caso di uno webshop saranno, l'esempio classico è arrivi sulla pagina, inserisci un item nel carrello, poi fai la procedura di checkout.L'idea è che ovviamente, immagino tutte le persone che ascoltano questo podcast capiscono benissimo che dietro le quinte di una cosa che può sembrare così semplice è semplice, possono...come dire, ci sono un miliardo di cose che possono andare storte, quindi noi andando a creare...noi siamo un servizio SaaS, no? Andiamo a creare un browser headless in cloud che appunto, avendo sotto il cofano Playwright, va a ripercorrere questi step, a navigare sulla pagina, arrivare al checkout dopo aver inserito l'item nel carrello e verificare che questo flow funziona.Lo facciamo di continuo, no? L'idea, appunto, è quando qualcosa smette di funzionare, che sia a livello infrastrutturale, che sia un bug che va in produzione, noi, come dire, diamo questo feedback al nostro cliente in tempo reale, tramite alerting, tramite pager duty, tramite sms, messaggi su slack, qualsiasi cosa, tutto automatizzato, e diamo le informazioni che servono al malcapitato che deve rispondere all'incident per risolverlo il prima possibile.Insomma, questa è un po' l'idea del synthetic monitoring.Dall'altro lato, magari c'è il real user monitoring che è più, come si dice, è complementare, che invece va a guardare, come dire, quello che fanno gli utenti reali, in un qualche modo.Non incontrano errori, incontrano problemi.Noi invece quegli utenti li creiamo, appunto, in maniera sintetica.Io vengo da un ambiente, un mondo dove questo tipo di testing viene fatto in house, quindi quando sviluppi una soluzione fai questo tipo di copertura e quello che mi chiedo è ad oggi dal tuo punto di vista sono molte le società e le aziende che invece non lo sviluppano in questo tipo di azione, di strumento.Intendi proprio il sistema di monitoring o la parte proprio di scripting invece dei test? Sì la parte di scripting perché la vostra parte è scriptabile, è l'utente che praticamente va a costruire i suoi test.Esatto esatto.Ok.Sì, io ho visto entrambe le cose, devo dire in passato, guarda ti do giusto un po' di background così capisci quello che ho visto prima, insomma, io adesso sono a Czechia da tre anni praticamente da quando esiste, all'inizio eravamo 4/5, prima però ho lavorato per la mia carriera, quando mi sono trasferito in Germania, iniziata con una piccola startup TestObject, facevamo anche lì una soluzione in cloud ma per il testing, non monitoring, ma proprio testing su dispositivi reali.E' un'esperienza molto interessante e che poi è stata comprata da SOS Labs che fino a quando me ne sono andato insomma è stato uno dei leader di quel settore, è stata dietro a Selenium tantissimo, insomma è un pezzo grosso insomma del settore e devo dire interfacciandomi allora adesso a Cekri siamo ancora piccolini ma interfacciandomi con i grandi, con le grandi aziende ai tempi di Sauce Labs ho visto tante cose, ho visto ho visto aziende in cui si faceva tutto in house, ho visto dell'outsourcing anche bestiale in certi casi in cui insomma poi mi vengono in mente un paio di storie dell'orrore.Il team di Mechanical Tark o simile Mechanical Tark dall'altra parte del mondo che cercano di fare copertura di test in questo tipo immagino.Si guarda te ne racconto una perché è troppo spassosa non riesco a trattenerla.Per questa, insomma, capita ovviamente che quando ti intendi di test automation, magari c'è qualcuno all'alto sales proprio che si sta interfacciando con un cliente o un potenziale cliente, insomma, e sia in questa situazione in cui, come dire, il cliente o il tuo contatto principale non è quello che è stato dietro l'automazione ma ne è responsabile.L'automazione viene fatta magari offshore.Mi viene in mente appunto questa chiamata in cui io maldestramente stavo provando a indicare a un programmatore dall'altro lato che si occupava dell'automazione un determinato errore che avevo visto, eravamo in screen share, determinato errore che avevo intravisto nel codice e non so perché non mi è venuto in mente di dirgli la...insomma non stavo riuscendo a dare indicazioni precise sul punto esatto del codice no? quello che è successo è che il mio collega che era in chiamata con me dice sì sì sta dicendo lì di fianco a questo numero qua 27165 che ne so no? E io era anche mattina presto mi sa quindi andavo ancora preso il caffè evidentemente e dico che sta dicendo 27165 qui stiamo guardando dei degli script di Selenium e poi guardo capito e il fatto è che 27165 quella era era la riga era il numero di riga di codice quindi noi stavamo guardando ed eravamo a un terzo cioè il framework di automazione che era stato costruito appunto in outsourcing eravamo a un terzo di questo enorme file java che conteneva tutto che puoi immaginarti da variabili globali casini e e tutto e il file sarà stato 60-70 mila righe qualcosa del genere quindi ecco se volevano war story insomma e ho visto anche...LM: questo è peggio! In realtà questo mi porta a farti una domanda è una riflessione che ho fatto qualche qualche settimana fa nell'episodio natalizio.Tu hai a che fare prevalentemente con anzi hai a che fare con due figure potresti avere a che fare con due figure diverse potresti avere a che fare con i software engineer oppure con i test engineer che hanno due forme mentis leggermente diverse che differenza trovi tra queste due figure? Nella tua esperienza sai confrontandoti col cliente e anche col reparto tecnico poi del cliente essendo comunque un solution mi viene da dire un solution architect però più o meno il ruolo è quello se ho capito bene.Sì sì c'è molto overlap almeno e è un'ottima domanda e come dire se ne potrebbe parlare davvero a lungo Diciamo, in passato mi sono interfacciato di più con proprio QA puri, quindi tester-tester, diciamo, test automation engineer fino all'SDAT, in sostanza, e anche diversi sviluppatori puri.Queste erano un po' le figure.Oggigiorno continuo a interfacciarmi sempre un po' con QA, automation engineer, eccetera, però mi interfaccio decisamente di più con sviluppatori SRE, DevOps engineer, tipo di figure qui.La differenza grande, da dove cominciare? Allora innanzitutto guarda partiamo da qui, nella mia esperienza e adesso qui per dire qualcosa un po' dobbiamo generalizzare, quindi non me ne vorranno insomma gli ascoltatori quando magari non si riconoscono in quello che però almeno in passato diciamo, è una cosa che si nota ancora nel campo del testing puro, come dire c'è stata un come dire una fetta della popolazione che ha secondo me seguito un po' e ha ha capito fin dall'inizio magari o più avanti il senso della test automation e che cosa appunto la test automation fa e dove in un contesto di sviluppo agile si inserisce e c'è anche c'è anche una frangia come dire magari che ha un po' più uno skillset da puro testing manuale che spesso come dire non si trova diciamo in un contesto di alta automazione e poi c'è anche una frange oltransista che dice proprio test automation è un come si dice uno simero non si può non si può automatizzare il testing eccetera eccetera e quindi da quel lato lì si si trovano anche più mi manca la parola adesso però più più scontri ideologici quasi no nel senso gente che investe molto sull'automazione sia automazione no io notando ho notato invece lavorando più con sviluppatori e sarì eccetera c'è un approccio semplicemente pragmatico nel senso oggigiorno l'automazione, lato testing ti serve e non ti fai neanche troppe domande.È ovvio che non è un discorso semplice avere una strategia di testing, come fare l'automazione, eccetera, possiamo parlarne molto a lungo, però si con gli sviluppatori diciamo di solito non c'è quel sì c'è un filo meno di ideologia nel senso la cosa che ti faccio un esempio pratico questa è una cosa che ho notato e noto di continuo anche perché adesso come dire in passato come dire ho utilizzato molto selenium no poi è stato fuori cypress no poi oggigiorno mi mi occupo principalmente di playwright che è il framework in cui in cui credo credo di più come possibilità future eccetera e però ogni volta che uno esprime in un qualche forum pubblico si esprime a favore o contro in un qualche modo insomma di un di un un tool di automazione, c'è sempre una risposta molto infiammata, molto vigorosa.Cioè la gente che ha investito molto su Selenium, che ne so ad esempio, magari invece di aver provato un po' tutti i tool, di saltare dall'uno all'altro a seconda del progetto, del contesto in cui si trova del target di automazione eccetera si trova magari gente che che ne so è talmente investita su selenium che ti non ti può accettare che che ne so magari cypress effettivamente è un'esperienza una developer experience molto accattivante quindi la gente che lo usa a se c'è una ragione se lo usa e o che ne so magari anche gente che invece è molto molto intrippata con cypress magari non quando gli porti un argomento magari a sfavore come dire un po se la prendono c'è un attacco molto questa cosa che secondo me come dire da informatico mi sembra un po un po strana no però d'altra parte insomma ci sono le flame wars si trovano sempre no cioè se vogliamo.Infatti sta nell'ordine delle cose, la lotta continua e noi lo diciamo sempre che qua a Gitbar che crediamo che una parte di queste flame wars venga dalla gestione del caricocognitivo, nel senso io mi sono studiato Selenium, me lo difendo fino alla morte perché non ho un cazzo di voglia studiare cypress o playwright perché perché è un effort diciamoci la verità.Comprensibile anche è vero è vero.Secondo me e ne sono fortemente convinto questa cosa è il driver principale abbiamo parlato di sviluppatori abbiamo parlato di testing io vabbè sono un po opinionato perché per me l'end to end testing fa parte della fase di scrittura del codice quindi gli script d'automazione fanno parte della fase di scrittura del codice come il rompitorio umano così lo chiamo io quindi il QA che va a testare l'app fa parte dal mio punto di vista del prodotto design.Sono due ruoli completamente diversi per me rompitorio umano quindi quella persona che scassa l'applicazione inventandosi degli user flow impossibili ci deve sempre essere perché è il generatore di entropia fondamentalmente all'interno del processo cosa che magari in uno script d'automazione si va beh si può generare l'entropia ma non quanto una persona che sa che sa che sa veramente rompere l'applicazione.Io ne conosco un paio vi giuro sono state in grado di rompere le cose più robuste del mondo però ritornando alla parte dello sviluppatore esiste una linea sottile che separa i diversi tipi di test, test unitario, test di integrazione e test end to end specialmente tra la linea dei test di integrazione dei test end to end talvolta questo confine è un po' sfuocato no? Dal tuo punto di vista come possiamo capire se il test che stiamo facendo o la feature che vogliamo testare o l'elemento che vogliamo dal quale vogliamo proteggerci deve stare su un test end to end o su un test d'integrazione.Questa è un'ottima domanda.Anche un po' stronza a bipartenza.No no mi piacciono le domande stronze e io ti direi guarda sì qui siamo secondo me nel senso...Sì siamo un po' nel dominio delle opinioni esatto.Io ti potrei dire guarda se vogliamo farla semplice quando guardiamo proprio al all'end to end lo intendiamo se lo intendiamo nella come dire nell'accezione classica io lo vedo come davvero partire partire dal far partire dall'inizio o meglio far partire il test o lo script o il case insomma come vuoi dall'inizio dell'interazione utente alla sua fine no che anche lì ovviamente stiamo concettualizzando però io direi a quel punto tutto quello lo possiamo confortevolmente chiamare end to end testing poi il resto insomma quello è già un bel chunk, una bella fetta che tagliamo via poi non so che cosa aggiungerei ecco dipende anche da che cosa vogliamo che cosa vogliamo fare di preciso.No sono pienamente d'accordo con te su questa cosa anche perché quando si parla, anche questa opinione mia, di test end to end secondo me si deve ragionare con lo use case in testa e con l'utente, sono dei test user centrici ok invece i test di integrazione hanno come focus principale hanno come spotlight direttamente una luce che punta sulla feature sulla parte architetturale, sull'integrazione di diversi moduli, sull'integrazione con la platform, quindi cambia l'approccio.Se io sto testando da ingegnere probabilmente non farò un test end to end ben fatto a meno che il product designer viene da me e mi dice "guarda che gli user flow sono questi rompimi e qua abbiamo si apre un altro problema un altro mio dilemma a la quale secondo me non esiste risposta però io provo a farti questa domanda io non sono riuscito a dare la risposta quindi sentiti libero di dirmi che domanda del cazzo cioè no la domanda che mi pongo è anche perché ne parlavo con un collega proprio stamattina.Secondo te il mocare i servizi esterni ha senso nei test end to end ed è un rischio nei test end to end? Si collega un po' alla domanda di prima no? Test integrazione test end to end? Sì, ottima domanda anche questa.Guarda secondo me nel senso io sarei molto, quando parliamo proprio di test end to end come li abbiamo definiti prima, io sarei molto ovviamente e sono sicuro che ci saranno i casi specifici in cui questo non vale, però io sarei farei attenzione insomma al moccare servizi esterni nel senso adesso io ti parlo magari adesso il bias appunto del synthetic monitoring in cui tu vuoi effettivamente andare come dire sei in production no quindi che ne so se le cose si rompono a causa di una di un API ter party che ne so comunque comunque lato utente le cose non funzionano e quindi io ho talmente come dire ho quello in testa adesso e immagino che ci possono essere dei casi in cui comunque si vuole fare però lo vedo io personalmente lo vedo più preponderante lato integration test proprio che non full end end diciamo.Sì, sono d'accordo con te.Anche qua ti dico quella che era la mia posizione con la collega.C'è da fare una distinzione sui test end to end.Se sono dei test io li chiamo da pipeline o dei test on-prod quindi degli smoke test sono quei test per chi non lo sapesse che semplicemente ti devono dire in qualche modo "oh qua c'è il rischio di bruciato qualcosa sta andando a fuoco perché questo user journey è interrotto da qualche parte" quindi potrebbe esserci un problema più grande perché faccio un esempio proprio l'esempio della serva non più lontano di ieri non più lontano di ieri noi avevamo un test end to end che faceva aveva c'era un drop down stupidissimo un autocomplete col drop down stupidissimo che faceva delle API a google places per fare l'autocomplete dell'address.Peccato che zio google in modo del tutto intelligente ha dei rate particolari dallo stesso ip e spesso si incazza se tu fai troppe chiamate e in un certo lasso di tempo fondamentalmente noi avevamo una serie di una test suite di un po di test che andavano a toccare a insistere su quella feature e quindi andavano a fare queste chiamate e google iniziava a rispondere rendendo i test dei test flaky e questo è tipo il terrore più grande di chi fa dei test end to end, è la cosa, il dolore che capita spesso ed è sempre predictable.Allora di là che fai? Mocky.La Mocky però se in pipeline è poco male secondo me ecco il mocking nei test end to end non in ambienti di produzione ancora ancora ci sta ok anche se in realtà ti sta nascondendo dei potenziali rischi dei potenziali non funzionamenti perché l'end to end deve toccare ogni margine del tuo sistema però degli smoke test on prod a quel punto non ha senso farli per niente sono completamente d'accordo nel senso a quel punto rischi davvero di come dire accercarti volontariamente in qualche modo perché invece quel feedback lo vorresti avere e sì sì no sono sono d'accordo su questo abbiamo parlato tantissimo di testing ma allora andiamo ai giocattoli no? playwright arriva playwright e in modo anche abbastanza devo dire a livello di marketing abbastanza prepotente cioè si è fatto spazio nel panorama delle soluzioni per il testing in modo così forte.Perché cosa pensi abbia portato a Playwright la capacità appunto di aprire un varco così grande? Allora io innanzitutto penso che una cosa importante sia anche nella storia di Playwright in un qualche modo.Adesso è passato un po' di tempo ma spero di riportare i fatti in maniera accurata.Però in sostanza prima di Playwright c'era Puppeteer, c'era Puppeteer appunto Testing Library volendo.Sì e non solo per esempio diciamolo agli ascoltatori sanno che le copertine del podcast sotto il cofano hanno Puppeteer che fa il rendering di un'applicazione che si chiama React.Esatto quindi c'era Puppeteer per quello, per scraping, insomma per tanti tanti utilizzi e Puppeteer già di suo insomma era un tool interessante, io lo vedevo col cannocchiare dal campo di Selenium volendo e in sostanza come dire Puppeteer si è sviluppato fino a un certo punto, insomma sotto lo standard di Google comunque, dopodiché il team penso nella sua interezza in sostanza è stato poi assunto a Microsoft per costruire Playwright e secondo me questa è una chance io direi quasi più unica che rara, nel senso hai hai modo di costruire un tool, di fare tutti gli errori, arrivi qualche anno dopo che dici "ah, se l'architettura l'avessimo pensata in maniera leggermente diversa, se l'avessimo posizionato in maniera un po' diversa anche lì e tutto" e poi hai effettivamente la chance con la stessa gente, nel senso con le persone che conosci tutto con le dinamiche già già un po create di andare a rimediare a tutti magari tutte le cose che avresti avresti voluto cambiare voluto fare diversamente quindi playwright è uscito è uscito fortissimo insomma già dalla fabbrica.La versione è ben riuscita del piano di Ryan Dahl con Dino.Sì esatto esatto io fra l'altro nel senso è chiaro comunque che Microsoft ci ha messo anche un certo peso dietro a Playwright perché comunque anche solo guardando la velocità con cui si è sviluppato nel senso tutte le feature comunque release a cadenza mensile con nuove feature ogni volta roba grossa e comunque anche un po' di marketing ben pensato diciamo un'immagine curata da tool di testing per sviluppatori, bello accattivante in un qualche modo e documentazione ottima nel senso...Beh il know how che ha fatto Microsoft con Github, con Visual Studio Code, con tutto ci sta, è classico e c'è anche il sordo secondo me, come si suol dire, che fa la differenza.Domanda, quanto rimane di Puppeteer dentro Playwright? Perché il team hai detto che parte e lo stesso devono aver strappato i contratti di non competizione di un tempo, non so se te li ricordi dove facevano gli accordi io non assumo i tuoi tu non assumi i miei una roba del genere no però quanto rimane di puppeteer dentro playwright oggi? Oddio sotto il cofano è stata da quello che mi ricordo io è stata riscritta tantissima roba proprio e quello che rimane lo lo vedi un po' magari nella forma dell'API, no? Però anche lì, come dire...tutto il meccanismo, diciamo...è proprio l'impostazione completamente diversa, no? Cioè Playwright nasce cross-browser, no? Mentre Puppeteer lo era per finta, diciamo.E Playwright ha questo sistema di auto-weighting, no? built in con gli actionability check che è come dire, su cui hanno chiaramente investito molto perché ovviamente non può funzionare in tutti i casi quella è una cosa pressoché impossibile però funziona davvero bene, c'è da dire secondo me sono quelli che l'hanno azzeccato meglio di tutti probabilmente fino a questo punto quindi non rimane tantissimo però probabilmente rimangono le lezioni in un qualche modo quella era la cosa fondamentale L'altro grande che Playwright è riuscito in qualche modo a mettere in difficoltà è Cypress togli Selenium che comunque aveva il suo mondo e già insomma qualche schiaffo l'ha sentito da Cypress però Cypress era molto verticale nel mondo frontend, nel mondo javascript e Playwright da quello che ho visto, non sono un esperto correggimi se sbaglio, si pone in modo un pochino più orizzontale no? Per esempio è aperto a più linguaggi se ricordo bene.Sì guarda allora è anche interessante secondo me la storia di Playwright che secondo me molti utenti nuovi non non sanno ma come dire Playwright non è nato nella forma attuale, diciamo.Cioè all'inizio Playwright, 2020, gennaio 2020, penso la prima release, era sostanzialmente una libreria, cioè era molto più simile a Puppeteer, in qualche modo.Cioè era proprio un tool, se vogliamo dirla tutta, principalmente per sviluppatori web, per per developer proprio.Nonostante, come dire, si dicesse già "testing framework", in un qualche modo.Era ottimo per tutti gli scenari citati prima, cioè scraping, testing, synthetic monitoring, eccetera.Quello che ha fatto per appunto piazzarsi in maniera più orizzontale, mentre prima era molto verticale anche lui, è stato appunto la trasformazione quello che oggi si chiama anche semplicemente Playwright, ma fino a poco fa almeno si chiamava Playwright Test.Playwright sotto il sombrello ha due grossi componenti, se vogliamo semplificare.La Playwright Library, che era il vecchio Playwright, tutto il core, tutte le API, tutta la parte interna, e poi c'è la parte Test, che è il Test Runner, il runner, diciamo, e tutti i vari tool di debugging, test generation, il recorder, in sostanza, e l'aggiunta comunque di tutto questo runner, diciamo, che prende molto da Jest, no? Come ricorda molto, insomma, per tanti aspetti.E tutti questi altri tool, appunto, che ho menzionato prima, il trace viewer anche, tutte queste cose rendono, in qualche modo, lo rendono molto più accessibile.E con l'aggiunta di queste feature, secondo me, ha chiuso o sta chiudendo, insomma, molti magari dei gap che aveva specialmente con Cypress, ad esempio.Cioè, prettamente di developer experience.Penso al debugging, principalmente, no? Test generation, eccetera.Quindi c'è stata una grossa trasformazione lì.Se dovessimo paragonarlo a Cypress, secondo te quali sono i plus di Playwright? Quali sono diciamo quegli elementi che ci farebbero dire ok uso Playwright e non uso Cypress? Io qualcuno ce l'ho in mente ma mi piacerebbe sentirli da te.Sì allora innanzitutto voglio dire che i tool che abbiamo che abbiamo menzionato fino ad adesso sono tutti ottimi tool nel senso cypress secondo me una developer experience fantastica ad esempio, mi ricordo anche quando ero molto investito appunto nel mondo Selenium, utilizzavo Appium insomma ero abbastanza in ambiente web driver, provare anche le prime versioni di Cypress, ero lì cavolo insomma.Ci aveva una UI figa, per chi veniva da Selenium diceva questa UI è spettacolare.Insomma più che fare un raffronto magari fra tutti, ti dico anni fa feci, scrissi un articolo, penso che sia ancora una delle pagine più visitate del nostro blog di Cekri fra l'altro, in cui andavo a paragonare, facevo un benchmark abbastanza crudo volendo, però comunque volevo, come dire, avevo delle domande su cui volevo un paio di risposte.Questa domanda viene proprio da quell'articolo.Sì, avevo in sostanza fatto appunto un benchmark fra, adesso non mi ricordo quali avevamo incluso, comunque mi sa che c'erano Puppeteer, Selenium tramite Webdriver I/O se ricordo bene, cypress eccetera e ovviamente non ti dico la controversia cioè tutti me ne hanno volute insomma mi hanno mi hanno redarguito da tutti i lati proprio sul su quello che secondo loro non andava bene ma non c'era non c'era altro modo di farlo in sostanza e però si insomma quello poi informò anche quel benchmark alla nostra decisione di focalizzarci su Playwright.Devo dire, è sempre difficile fare raffronti fra i framework in questo modo, specialmente perché non sono tool che usi così come sono, vanno configurati in un certo modo, possono essere utilizzati in diversi modi, per diversi scenari, insomma, è complicato fare un raffronto importante.la cosa che ti posso dire in qualche modo posso rigirare la domanda e dirti il perché secondo me playwright è così interessante versus capito? Sì sì sì io non volevo ragionare in termini di performance volevo invece parlare in termini di feature no? Sì sì no no ma proprio quello anzi io guarda ti dicevo mettendo assieme tutto no la cosa secondo me come dire la cosa davvero che fa risaltare che mette in risalto playwright rispetto agli altri tool è che è un po forte da tutti i punti di vista no cioè nel senso la developer experience di playwright specialmente dopo questi ultimi questi ultimi sviluppi secondo me è praticamente best in class.La performance come tempo di esecuzione degli script è un tool estremamente veloce e la stabilità dico la stabilità per me venendo dal synthetic monitoring in cui come dire false failure c'è un test che fallisce quando non dovrebbe quando non c'è un problema col col sistema under test insomma col sistema che stai monitorando, quello vuol dire che magari qualcuno viene svegliato da pager duty alle 2 del mattino, quindi non come dire, devi davvero guardare con una certa serietà e la flessibilità comunque che ti permette, cioè il numero di, la profondità e l'agilità con cui puoi utilizzare i browser, no? Anche se non fosse come dire il numero uno in nessuno di questi campi e lì ne potremmo parlare.Il discorso è che è forte in tutti ed è questo secondo me che lo rende così appetibile un po' sia lato sviluppatore sempre di più anche lato test automation QA engineer.Sì c'è da dire che per esempio io ti porto sai in azienda abbiamo fatto dei POC abbiamo fatto un po' di discoveri perché buona parte dei test end to end li abbiamo fatti sempre con Cypress da quando esiste e quindi almeno per quanto mi riguarda io ho sempre usato subito dopo Selenium ho utilizzato Cypress e così sono andato.Un paio di cose che mi hanno catturato l'attenzione sono state in primis il supporto di più linguaggi anche se il web fondamentalmente è scritto in javascript aver la possibilità di scrivere le test suite in più linguaggi questo è un grosso vantaggio perché ci possono essere altri scenari che noi stiamo trascurando stiamo facendo girare python nei browser qualcosa vorrà dire nel senso qualcosa sta cambiando da quel punto di vista lo vedremo poi più avanti però già col concetto di WebAssembly tu stai portando delle skill differenti nel mondo del web, skill che potrebbero essere opinionati o spinte a utilizzare il loro linguaggio piuttosto che il javascript.Lo molto semplicemente facendo due passi indietro io ricordo me che utilizzavo o Gherkin o PHP per pilotare Selenium con Mingmong non mi ricordo come si chiamasse quella libreria insomma quindi quello è un plus.Un'altra cosa che ho notato è che ho invidiato supporto multitab? No il parallel testing.Il parallel ok? Perché Cypress è fatto in modo diverso lì ha proprio una filosofia differente no? Esatto e quella è una cosa che ho che ho invidiato di brutto.Un'altra cosa che ho invidiato di brutto non so come si chiami il nome specifico però sono la parte di "await" la scrittura dell'esperienza utente nell'utilizzo di questa funzionalità fa sì che l'esperienza utente nella scrittura del test sia molto più fluida al posto di fare dei giri come quelli che facevamo facevamo con Cypress talvolta.L'auto weight, altra cosa, io penso di aver pianto non più tardi di qualche ora fa mettendo Interceptor, facendo l'attesa sull'Interceptor, cioè raga volevo spararmi i piedi.Quello è un come dire il topic del waiting, dell'aspettare che qualcosa succeda in maniera...adesso mi vengono solo parole in inglese, devi perdonarmi ormai sono le 10 quindi l'italiano sta svanendo...quindi fare waiting, avere un modo facile da gestire che poi non vada a creare invece dei falsi positivi è un argomento inesauribile, ogni volta che facciamo, ogni volta che mi trovo a parlare con persone che scrivono script in questo o in quel framework è quasi sempre la cosa che mi viene chiesta di più e non importa quante conferenze vai, quanti workshop fai eccetera eccetera, trovi sempre tantissime persone che usano i slip in sostanza, cioè che mettono ok, qui mettiamo aspettiamo dieci secondi capito e speriamo che poi la cosa che deveva succedere sia successa.Esatto io porto la mia esperienza con Cypress metti un interceptor aspetti ascolti metti il weight sull'interceptor ok sono sei righe di roba cinque righe di roba che sa anche ricordarti la sintassi quindi fai un salto nella documentazione per vedere che non stai facendo cappellate perché anche per la leggibilità fra l'altro no? Esatto al test.Anche, anche esatto e poi cosa fai? Metti l'only sulla parte di test, te la run in visuale, speri che funzioni.Ragà è tempo quindi molti di noi cosa fanno? Sbagliando a palla.Mettono un bel wait 500 millisecondi e quello in un modo o nell'altro funziona ti porte a casa il test peccato che cambia il contesto gira in CI e quel test fallisce diventa un flicky test a volte fallisce a volte succede le bestemmie riranare la CI e me ne falliscono 7 10 15 questa cosa poi diventa esponenziale fuori controllo ti incazza prendi cancelli se ne è la possibilità prendi cancelli la test suite e dice vaffanculo me le prova a mano io queste scene le ho viste.scherzi ma poi il discorso è mi ricordo questi tempi tempi di selenium per me ma appunto tempi tempi di testing lavorare interfacciarmi con grandi aziende alcuni comunque avevano delle suite di test appunto che giravano capito su commit magari che giravano su sul deploy capito magari dovevano far girare una test suite immensa tantissime volte al giorno e comunque se se tu inizi ad aggiungere 10 secondi qua 10 secondi la sbagli la parallelizzazione eccetera a un certo punto devi diventa davvero come come all'epoca quando potevi andarti a prendere il caffè perché tanto non capito sei lì che aspetti che finisca tutto prima di poter andare Giovanni nel progetto dove sono 25 minuti ogni PR di cui 18 minuti 19 minuti stanno su cypress adesso ci sono tanti weight 500 e weight 1000 da rimuovere e piano piano si stanno rimuovendo però in realtà sono un indicatore perché comunque tu devi mettere il weight e nel mio caso devi anche mettere la regola per far star zitto l'Inter perché io da furbo quando ho fatto il setup del progetto ho detto ok facciamo una cosa mettiamo una bella regoletta dell'Inter in modo da creare attrito verso questa soluzione però nonostante la regoletta dell'Inter quella rimane ancora la soluzione più rapida per lo sviluppatore e questa cosa evidenzia il fatto che il problema sia un mero problema di "Deve Experience" l'auto weight in qualche modo nasconde, elimina quest'attrito dal mio punto di vista, rende tutto più smooth tutto più fluido ed evita questo tipo di loop e e soprattutto fa sì appunto che non si crei questo modo, che non si generi la causa di questa perdita di tempo.Facciamo un passo per un attimo sul parallelo invece.Quella sai perché secondo me è una roba molto figa? Perché una cosa che mi è capitata da poco in un progetto dove stavo dando consulenza è stata quella di avere dei test che erano in qualche modo dipendenti l'uno dall'altro.Ok adesso noi siamo tutti bravi tutti facciamo i test isolati ma non è vero no? Perché perché capita perché perché siamo esseri umani perché talvolta la merda la scriviamo a palate.Io sono il primo che lo fa.Rannare i test in parallelo può essere un modo per spottare questo tipo di problematica? Sì sicuramente, io qui tendo ad essere un po' nazi, rischierzo, esatto, però un po' estremista nel senso, poi ho lavorato in campo testing per aziende che come dire puntavano molto sul fatto che si sfruttasse la capacità di parallelizzazione di quelle che erano magari grid in cloud, no? In sostanza.Quindi questo era sempre un grosso topic.Ma in realtà al di là di al di là di quelli che potevano essere gli interessi aziendali ha proprio senso stare attenti a ste cose qui.Il discorso è sempre per ricollegarmi un attimo alla quello che dicevi prima sulla flakiness è ogni volta che c'è un un false positive no? Appunto un test fallisce quando non c'è una vera ragione, diciamo appunto, del sistema che sta venendo testato affinché questo debba fallire.Non è solo che, come dire, come si dice "da dove vengo io da Bologna ti scende la catena", ma c'è proprio il problema che piano piano, capito, è quella goccia.Il problema è che più succede, più, e questo è un problema molto sottovalutato secondo me, più il developer o chi per lui inizia a perdere un po la fiducia in questo sistema di automazione che è stato scritto no si guarda ho controllato per la ventesima volta c'ho mille cose da fare sono a ritardo sulla deadline mi è arrivata la notifica qui che questo test ha fallito per l'ennesima volta sai cosa la prossima volta semplicemente non controllo e basta quasi quasi perché appunto c'ho le mie cose da fare Comprensibilissimo, comprensibilissimo.Una delle tante ragioni per cui questa cosa può capitare è che appunto si vanno a creare magari dipendenze fra i test, appunto, che non sono più autonomi, ma magari interferiscono con lo state dell'altro, con i prerequisiti del test che deve venire dopo, capito? io ti creo io test 1 ti creo l'utente per te test 2 funziona quando siamo quando eseguiamo in maniera seriale quando andiamo a parallelizzare il test 2 parte per primo poi la cosa peggiore che magari non è che fallisce sempre no fallisce ogni tanto quando test 2 parte prima di test 1 in qualche modo quindi aggiunge capito un ennesimo grattacapo il test che fallisce sempre in un qualche modo magari capito ti fermi dice questo proprio non funziona lo metto in quarantena subito lo lo lo lo fixo adesso tutti quegli errori invece che diventano che non succedono continuamente adesso mi sfugge la parola sono intermittenti diciamo e quelli creano creano più casino in un qualche modo secondo me quindi bisogna sempre stare attenti la mia indicazione di base è test autonomi indipendenti e brevi cioè chiedersi sempre cosa devo testare qui qual è lo scope sto aggiungendo roba e poi ci sono comunque devo dire i tool di automazione offrono anche dei buoni metodi secondo me per andare a isolare il setup da quello che è il test effettivo e far girare quel setup quella fase di preparazione per il test nel momento giusto prima di ogni test prima di questi test prima di solo questo test qui insomma c'è modo di configurare le cose in modo giusto però bisogna pensarci bisogna investirci un po' di tempo perché altrimenti dopo partire male costa tanto insomma vero verissimo sai a cosa mi porta a pensare questa cosa? questa cosina che ho appena fatto ho appena evidenziato e che tu hai chiarito mi porta a fare un ragionamento magari mi sbaglio però tenetevi furti perché questa è una di quelle parentesi di Mauro e ne esce con cose che non c'entrano niente quindi abbiate pazienza sopportatevi.Penso che dipenda proprio il fatto di fare dei test accoppiati l'uno all'altro e far esplodere tutto una roba che poi ti dice no bo li tolgo viene un po' dal ragionamento dello sviluppatore dal modo in cui pensa lo sviluppatore dal modo in cui pensa il software engineer rispetto al modo in cui pensa il QA o il test engineer.Il software engineer pensa col behavior in mind col comportamento in mind step by step è indispensabile invece per il test engineer chiarire lo scenario prima di tutto.Lo scenario nell'ottica dello sviluppatore puro un po' si perde un po' si diluisce perché lo sviluppatore non tiene traccia in testa di tutti gli edge case possibili e immaginabili ma tiene prevalentemente traccia di quello che è il best case e cerca di tamponare se nel best case scenario trova dei luck ecco quindi una cosa che e lo dico mettendomi in prima persona quando scrivo dei test io difficilmente cioè faccio fatica a immaginarmi tutti gli scenari possibili immaginabili e invece la definizione chiara dello scenario quindi per capirci dello stato del database se vogliamo semplificare o fare un esempio dello stato del database a quel dato momento la chiarificazione di quel elemento mi porta necessariamente a dire ok io devo inizializzare questo questo test ha un certo stato, inizializzarlo a un certo stato ti costringe in qualche modo a disaccopiarlo da tutto il resto perché stai partendo da un T0.Ecco quindi probabilmente il fatto...perché tutto questo ragionamento? Per dire che probabilmente il fatto di avere dei test accoppiati tra di loro dipendono non necessariamente dallo strumento che si usa per fare i test ma quanto dalla formamentis che abbiamo nello scrivere i test e fare lo switch di cappello tra il test engineer e il software engineer è talvolta difficile no? cosa cosa ne pensi? mi trovi anche qui completamente d'accordo devo dire mi sembra un buon ragionamento come dire è anche una questione secondo me ha molto senso cioè è una questione un po di bias nel senso dati da quello che noi facciamo, no? Nel senso se tu, è chiaro che tu che lavori magari sul internamente alla soluzione, capito? Al prodotto, tu hai chiaramente un punto di vista completamente diverso, mentre se io sono là fuori da lato diciamo, io sono magari anche un QA engineer, test automation engineer, quello che vuoi, embedded in un team di sviluppatori, però comunque la mia prospettiva, come hai detto tu, è diversa.In un qualche modo, parlare, provare anche a scambiarsi appunto, come dici tu, il cappello, provare a vivere un giorno ogni tanto, diciamo, nelle scarpe, nei panni dell'altro, aiuta molto.Devo dire una delle cose di cui sono molto contento a Cekli, vedo che c'è questa...il bello forse della startup in un qualche modo, che tutti hanno questo senso di ownership in un qualche modo e quindi vanno, come dire, molto facile saltare fuori da quello che sarebbe appunto magari la propria posizione, proprio day today riesce molto facile questo tipo di esperimento questo tipo di comportamento magari quando dico ipoteticamente quando si cresce si diventa anche un po più rigidi un po tutta la struttura diventa un po più rigida quei bias diventano ancora un po più pericolosi sì sì sì sì esatto pensavo a un'altra feature perché ormai ci stiamo spostando all'interno all'interno delle delle feature una feature che tra l'altro potrebbe aprire un'altra di quelle parentesi enormi infinite no però gli exporter dei test result una cosa che ho trovato molto figa di Playwright, questo è un po' l'outcome della fase di discovery dei miei colleghi che hanno perso un po' di giorni cercando di smontare Playwright e capire se in realtà l'upskilling che ha un certo costo dal punto di vista aziendale verso un nuovo tool era motivato una cosa figa che ho trovato è che poi mi ha aperto una serie di ragionamenti è appunto l'exporting dei test results che è out of the box e in un po' di formati giusto? sì sì giusto e sì l'exporter in sostanza è built in una delle cose come dire lì poi adesso non non so quando è magari l'ultima volta che avete appunto fatto questa questa questa piccola investigation però, o più sì insomma, però il secondo me la cosa che sposta di più in quel senso lì è probabilmente il trace viewer, cioè non solo io ho come dire i test o il reporting che poi mi permetta di di addentrarmi anche in ogni singolo test, test result, ma per ogni singolo test risolto proprio la trace, cioè posso nel momento in cui quello fallisce posso davvero come dire spostare il mio cursore sulla timeline andare a vedere quali errori in console avevo quando abbiamo eseguito quel determinato comando no e nei casi impestati è una cosa una cosa fondamentale aiuta tantissimo devo dire e anche io quando quando sono lì che magari guardo un test che conosco poco è di un di un cliente che mi ha chiesto una mano è una delle cose che hanno spostato di più secondo me che ha aggiunto più valore fra tutti i vari sviluppi recenti perché ti permette davvero con precisione pressoché chirurgica di andare a vedere che cosa è andato storto in uno specifico caso.volevo chiederti una cosa che piace molto di cypress è il test visuale c'è qualcosa del genere per playwright? si nel senso c'è l'inspector diciamo che permette di ovviamente tu puoi metterti i vari breakpoint fai girare di default playwright fa girare il browser in modalità headless quindi non vedi nulla ovviamente però e tu puoi semplicemente semplicemente far partire tutto in modalità head full no e poi fare step through di ogni singola istruzione e anche quello è molto utile devo dire e ci sono tante cose che aiutano davvero tanto a capire effettivamente come stanno andando le cose c'è anche un'integrazione con via scode fra l'altro che anche quella appunto vedi Microsoft e anche quella comunque aiuta molto a dare una developer experience che sia, secondo me, veramente ottimizzata io da sviluppatore sono già su VS Code, ho il plugin, ho Playwright Test, tutto lì in codice che poi è una cosa che anche adesso a Checklist stiamo provando in un qualche modo a replicare avendo anche noi il nostro tool CLI che ti permette di far girare quei test sia in locale ma anche poi trasformarli in check o monitor insomma che girano di continuo sui checkli quindi secondo me adesso si qui mi sto un po' allontanando però secondo me il come dire quella è la direzione in cui andiamo no? tutto everything has code in un qualche modo no? si si si vero ritornando però agli exporter e poi alla fine all'output del test la buona parte dell'output dei test noi lo utilizziamo per andare a fissare bug andare a fare hot fixing andare a salvare la roba che va a fuoco.Però una roba ancora poco utilizzata in realtà dal mio punto di vista almeno in quello che mi è capitato di vedere in piccole, medie ed enormi aziende è un approccio un po più manageriale al testing cioè ad oggi esiste tutto il mondo del test management che non sta emergendo ancora ma che è super interessante specie nell'ottica collegata al fatto che abbiamo dei tool come playwright che attraverso l'exporter ci danno una serie di informazioni faccio un esempio pensiamo a adesso mettiamo i panni del product manager no? Pensiamo a come possiamo utilizzare i test.Ad oggi io sfido chiunque e lo chiedo anche a te quanti product manager conosci che danno un'occhiata alle test suite in development non al synthetic monitoring ma alle test suite in development? pochissimi.Pochissimi sì.Io mi dischieria un "nessuno".Quando in realtà dal punto di vista di management quello che emerge sono tutta una serie di informazioni utilissimi da misurare.Faccio una serie di esempi.Una che hai come la "defect density" che ti permette di stabilire per ogni modulo la densità di difetti che le test suite trovano e questo ti permette di stabilire il costo di sviluppo di ogni monitor di ogni modulo no? oppure il defect leakage cioè quanti difetti fanno bubble up dalla test suite e arrivano all'utente per un certo modulo o per tutta l'applicazione.Questa roba è super interessante, quello che secondo me manca in realtà è una semplice azione di comunicazione, cioè una cosa che trovo probabilmente sviluppata in modo superficiale non so se per scelta o semplicemente perché manca questo tipo di prospettiva di questi tool Cypress, Selenium e Playwright è l'idea di passare un messaggio verso l'utilizzo di queste KPI.Cioè faccio un esempio, lancio i miei test end to end, un test end to end insiste su alcune parti di Codebase.Io ho la possibilità per esempio, essendo un tool, mi verrebbe da dire vorrei avere la possibilità di evidenziarmi dove insiste il fallimento, in quali moduli del software insiste il fallimento.Su questo secondo me c'è ancora tantissimo da fare.Adesso non so come in modo specifico e in modo pratico ci sarebbe magari da ragionare sopra però si aprono tutta una serie di prospettive che finora non sono battute cioè quelle dei framework di test management.Sì sono sono d'accordo e guarda non penso di poterti dire tanto qui ma esattamente speravo Ho toccato qualche NDA! No, no, non per quello, non per quello.Però come dici tu, nel senso, di solito ci sono poi tool dedicati, no? Perché questo è come dire, già da come l'hai messa tu si intuisce che è un argomento piuttosto vasto, no? Quindi almeno fino ad adesso, come dire, queste cose di solito non sono built in nei tool di automazione, perché sono due mondi, no? non so se in futuro le cose li potranno cambiare però di solito ci sono sempre stati dei framework esterni per il test management e per il reporting di quel tipo poi che ti permette di andare a in teoria almeno a guardare alle metric di cui di cui hai parlato tu.Io nella mia limitata esperienza, mi è capitato molto raramente anche solo di sentire conversazioni utili di questo livello.Non sto dicendo che non siano conversazioni utili, dico solo che come magari dicevi già tu, è magari dove siamo più indietro in generale come industry, capito? Cioè non siamo...col fatto che c'è già tanta complessità proprio nei nell'automazione di per sé cioè a livello più basso andare a fare poi questo tipo di conversazione di livello più alto invece di in cui traduciamo tutto a livello di prodotto e magari di processo di sviluppo è difficile nel senso anche parlando anche con tante aziende grandi non c'era non c'era il focus non c'era magari la cultura lì è dove mi mi aspetterei, magari ottimisticamente, che nei prossimi anni ci sia qualche breakthrough.Di solito, anche quando sono andato a guardarmi, a fare un po' di ricerca su questi argomenti, ho sempre trovato tante risorse, come dire, almeno le risorse più disponibili, le cose che ti saltano addosso dalla home page di Google, mi sono sempre sembrate un po' superficiali, non ho trovato ancora cose illuminate su questo argomento diciamo secondo me perché siamo siamo un po' è presto semplicemente secondo me non c'è tanto know-how.Sì magari il know-how c'è anche però è un problema forse di silos che i due mondi non si parlano che i tool diversi non si parla in modo aperto che vuol dire nel sito di playwright tra gli exporter no magari c'è qualcosa di più pensato anche in questa direzione.Insomma sono degli scenario che io non vi nascondo che ho pensato anche una startup per qualcosa del genere ma siccome ho 70.000 side project non ho paura a dirlo.Si aprono degli scenari, si aprono dei mondi quello che però oggi con Giovanni e possiamo confermare, affermare è che semplificando la dev experience i nostri team sono sempre più portati a testare.Testare è bene se testato bene come si suol dire altrimenti diventa una grande una grande perdita di tempo e poco affidabile e che comunque Playwright è uno di quegli strumenti che in qualche modo proprio migliorando la dev experience ci porta a migliorare le nostre test suite fondamentalmente come sempre ragazzi io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare dei soldi ma non vedo perché vergognarsi a una cosa così bella parlare dei soldi perché i soldi sono veramente la cosa più bella del mondo quindi donate perché dobbiamo fare una cena da massimo bottura con i vostri soldi quindi è una cosa molto importante e siamo molto poveri quindi donate copiosamente veramente in tantissimi mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare ovvero metterli su delle cripto uscite da mezz'ora.28 gradi e mezzo all'ombra non si ave più da 20 giorni e non c'è un alito di vento tanto caldo quanto assente [musica] Ogni volta che sento questa musichetta mi viene da ballare, d'ansecchiare sul posto.È il momento di ringraziare chi ci sostiene visto che dal momento in cui abbiamo disattivato qualunque tipo di pubblicità in realtà le donazioni e gli acquisti referenziati su Amazon sono l'unico nostro modo di sostentamento.Dobbiamo ringraziare due amici che questa settimana ci sostengono e sono diciamo stati il motivo per cui siamo riusciti a uscire anche questa settimana il primo è Luigi Tacetta e il secondo è Giovanni Italiano che entrambi ci hanno donato una birra.Luigi e Giovanni noi vi ringraziamo tantissimo per il supporto perché grazie a queste piccole donazioni noi possiamo pagare tutti gli abbonamenti e riuscire a essere online anche la prossima settimana e via discorrendo.Se vi fa piacere, se in qualche modo GITBAR ha in qualche modo preso un posto nella vostra vita o vi ha apportato del valore vi prego supportateci questo farà sì che anche per altre persone potremo portare quel valore e continuare a portarlo anche per voi stessi.Detto questo io vi ringrazio infinitamente e vi ricordo che qualora non vi vada di fare una donazione o volete supportarci anche in altro modo potete andare in uno dei link delle note dell'episodio uno dei link di amazon cliccare si aprirà una sessione da lì potete comprare quello che volete possono essere cosa ne so uno spazzolino da denti o dei pannolini per la bimba e pochi centesimi del vostro acquisto andranno a supportare i GITBAR.Noi vi ringraziamo e nuovamente appunto tiriamo sui calici e brindiamo a Luigi e a Giovanni.Grazie.Io ho visto, ero un po' distratto adesso, ho visto un attimo l'orologio siamo già un'ora e un quarto e Giovanni mi ha detto che era distrutto ancora prima di registrare la puntata, io tipo sono un cadavere ambulante, quindi voliamo rapidamente al momento il paese dei balocchi, il momento in cui i nostri ascoltatori condividono qualcosa che ha catturato la loro attenzione e pensano che sia interessante condividere con noi.Quindi ti chiedo Giovanni hai qualcosa da condividere con la nostra community? "E conduco nel paese dei balocchi" "Ah il paese dei balocchi" Sì sì non è prettamente ambito testing o nemmeno synthetic monitoring è più un articolo che mi ha dato da pensare più ampiamente sul web e sul nostro modo di consumare informazioni è un articolo che si chiama "The Garden and the Stream" non so se lo conosci è abbastanza famoso ma...ma non devo essere perso...in sostanza adesso la faccio molto...come dire vi do il teaser magari mezzo teaser mezzo spoiler ma come dire ovviamente l'idea iniziale di web come ce l'avevamo magari negli anni 90 o inizio anni 2000, oggi quando navighiamo sul web abbiamo un'esperienza molto differente.C'è il concetto, come dire, il concetto magari più iniziale del web con, capito, ipertesti e collegamenti e, come dire, questa struttura che cresce e rimane, capito di contenuto che rimane e viene costruito con la cura magari anche di un contenuto che deve rimanere in un qualche modo sta lasciando posto secondo me più allo stream in un qualche modo questo sto già inserendo la mia opinione se guardiamo su youtube ad esempio nel senso il mio canale automateogather che è piccolissimo a pochi video e tutto sono la maggior parte sono video molto specifici che vengono da un'idea specifica e magari di uno di uno use case particolari playwright come che ne so l'automazione della two factor authentication su cose cose che come dire ho incontrato con magari clienti o che persone mi hanno chiesto sai cosa questa questo ci starebbe a fare un bel video proprio targeted su questa cosa lo mettiamo lì ma perché ho avuto l'idea però se seguite un qualsiasi content creator che è un giovane nome interessante su youtube o su una delle tante piattaforme non necessariamente video ma insomma piattaforme che fanno girare il web oggi il concetto è quello dello stream cioè il contenuto e la piattaforma ti favorisce anche se tu pompi fuori contenuto continuamente no deve avere questo stream deve avere engagement continuo che vuol dire produzione continua in un qualche modo e questo articolo parla un po' di questo di questo concetto qui e ve lo consiglio.Bello e si ricollega anche a quello che ho detto qualche episodio fa, i miei piani per l'anno nuovo che sto portando avanti davvero sono quelli di ridurre gli articoletti piccoli, eliminare completamente le stories di instagram o i tweet e andare a leggere o libri o paper o articoli cicciosi che magari ti portano via anche una buona mezz'ora 40 minuti per leggerli e rifletterci perché dobbiamo come come Giovanni ci hai appena ricordato dobbiamo in qualche modo anche rimpadronirci del nostro tempo del tempo di fare le cose, ne parlavamo anche al Fosdam con gli altri e l'ha detto Alessio in modo molto chiaro, dobbiamo anche ridare un valore alla fatica nel fare le cose e il dedicare il giusto tempo è uguale anche al dedicare un effort, un impegno, una certa fatica, quindi mai articolo fu così ben tarato come come quello che ci proponi oggi.Io invece qua sulla scrivania mi sono ritrovato, avevo in mente un altro balocco però mi sono ritrovato questi pochi foglietti che sono reduci da come ho suotato la borsa dei gadget, dei goodies del FOSDEM.Il primo è un piccolo foglietto che mi ha dato un certo Ken Follon che è colui che tiene l'Hacker Public Network che è un aggregatore di podcast del mondo hacking, sviluppo software e in genere.Il sito è freeculturepodcast.org e ha una lista di podcast tutti in creative common e l'idea è quella appunto di...e ce ne sono un sacco ce ne sono su Linux, ce ne sono sul kernel, ce ne sono sulla tecnologia in generale, sullo sviluppo, su...veramente ce n'è un gozziliardo buttateci un occhio questo è molto figo prima o poi anche Github andrà a finire là dentro e poi per le, ahimè, ancora poche donne all'ascolto AlphosDemo ha scoperto una cosa fighissima che esistono delle community femminili tematiche l'idea era appunto riuscire a individuare qualcosa di interessante che catturasse l'attenzione di mia moglie, voi sapete una date engineer e ho beccato una roba carina che si chiama Postgres Woman che è una community che ha come obiettivo insomma tutto tutto il ragionamento della diversity nel mondo Postgres.E' una cosa curiosa se c'è qualche qualche signora all'ascolto o o comunque qualcuno interessato al mondo post-gress con lo sprint di lavorare verso un mondo un po' più diverse di quello che abbiamo adesso specie nel nostro ecosistema ecco questa può essere una cosa interessante [Musica] Giovanni mi ha fatto superissimo piacere averti qua a fare questa nostra bellissima chiacchierata.Io ne approfitto per ricordare nuovamente il tuo canale youtube ci ho buttato un occhio ho visto un paio di video carino quello che hai fatto su amazon ha catturato la mia attenzione.Il canale automate together Ricordiamo insomma che là ti possono trovare, metteremo nelle note dell'episodio tutti i tuoi contatti e per il resto grazie di nuovo, grazie, grazie davvero.Grazie a te, è stato un piacere.Ringraziando nuovamente Giovanni, io vi ricordo rapidamente i nostri contatti, info@gitbar.it @brainrepo su Twitter.ricordiamo che nel sito web c'è un link per supportarci e ci sono diversi modi per supportarci o attraverso quel link dove potete fare una donazione e invitarci una birra oppure direttamente potete supportarci in modo indiretto direttamente in modo indiretto non si può sentire vabbè abbiate pazienza io ormai sono fuso ma il modo per farlo è mettendoci delle belle stelline sull'aggregatore Apple Podcast e se ci ascoltate con Spotify o con Audible vi ricordo che ci sono dei player molto migliori si trovate cercando "New Podcast Apps" su Google e trovate insomma dei dei player molto fighi ce ne sono davvero un gozziliardo quindi buttateci un occhio sono tanta roba detto questo io vi do appuntamento alla prossima settimana e la prossima ciao ciao GIT BAR il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e combrir repo, parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
