 non vi annoierò troppo, state tranquilli, ti metto la giornata. Prima di cominciare, una velocissima probleme di introduzione, questo sono io. Quello è il mio handle di tweet. Lavorato l'ino per Huilaica. Alcuni dei nostri progetti per WordPress li trovate. WordMove, WordPress, eccetera. Magari qualcuno avrebbe sentito sul sito www.uptools.it. Bene, velocissima. Parliamo di debugging. Molto spesso, appunto, introducendo l'ergomento, si parla di istinto di debugging. Capita ogni tanto di ritrovarsi di fronte a un bagno spalentisissimo. Non si sa come affrontarlo. E solitamente interviene, in sua risoluzione, quello che chissà per quel motivo sa dove mettere le mani. A questo punto, istinto. Arrivo ai super-eroi che ci salva, magari anche a cavallo di un animale intologico. Solitamente sono visti così, quelli che hanno gli istinto per il debugging. Ecco, poi dipende da chi è. Ci vedete voi, ma solitamente questa immagina che si dipinge di chi riesce a risolvere al volo è il problema. Invece, quello che voglio dirvi è che non serve alcun istinto, sono imito, come ai unicorni, mentre questi super-eroi non sono. Passerono semplicemente degli strumenti. Essendo bug, io ho voluto usare la metafora dell'intomologia. E quindi, come un qualsiasi intomologo bisogna avere gli strumenti per analizzare, classificare, osservare i nostri bug. Quindi, in realtà non ci serve un istinto per il debugging. Non è necessario sviluppare un istinto, ma semplicemente saper individuare i giusti strumenti e avere un certo esperienza. Quindi, dimentichiamoci i super-eroi unicorni e altre figure inesistenti. Non serve istinto, ma solo esperienza e strumenti. E come... Comunque, sono programatori di me... Io, prima di cominciare, ho provato ad immaginare come impostare questo discorso. La prima parte è su un pattern. Quale flow, quale... In che modo arrivare dall'indidibuzione alla diluzione dell'indidibuzione. Una delle primissime disigenze che abbiamo è molto spesso di... prima di tutto di riuscire a contenere un banco. In alcuni casi piuttosto che arrivare subito alla soluzione cioè non viene a trovare gli strumenti per riuscire a contenermi. L'altra cosa che dovremmo fare, prima di tutto, è lavorare esclusivamente con i fatti. Questo può sembrare un po' troppo teoricro, però vedremo poi, nella risultazione di alcuni bar di specifici, che i fatti sono la nostra base per la diluzione. E poi, quello da cui si partila sempre, e osservarli da distribuere. Questa, appunto, io ho usato una metafora dell'entomologia, che sono bug. Come farebbe un entomologo parte prima di tutto dall'osservazione a delle ali, a delle antenne, quanti zampia, attributi riconoscibili, perché in base alla tipologia di bug ci sono strategie differenti. Quindi l'altro passo che faremo è, appunto, isolarlo, per un iduruto, riuscire a ricordarlo, e poi ovviamente. Quindi il pattern che utilizzeremo sarà proprio questo. Osservare, scegliere gli strumenti, le strategie dopo averlo classificato per affrontarlo, e riuscire a sistemare. E lo sentriamo nel vivo. Io, appunto, sfruttando questo pattern, ho individuato un'atasonomia vero e propria, una classificazione di bug. Sicuramente, molti di voi lo sanno e esiste davvero l'atasonomia, hanno dei nomi specifici e utilizzeremo proprio quel pattern. Il primo bug è, forse, quello più comune, e ha queste caratteristiche principali che diciamo di osservare. Voi sapete che questo, il bug, se ho osservato un bug che vi sembra limitato in una parte specifica e tendenzialmente riuscita a ricordarlo. Da sviluppatori, magari, abbiamo, anziché sicuramente abbiamo, degli ambienti distinti, un bag che si presenta in produzione, lo provo in sviluppo e in sviluppatori. E riesco di individuare, subito, quale è l'area colvita da quel bag. Ecco, se vi capita questo, questo è un bore bug. Il bore bug è il riferimento al modello otomico di bore, tutti questi bug hanno un nome che deriva dal conto della fisica. È il modello otomico di bore, in particolare perché ha queste caratteristiche deterministiche. In determinate condizioni, questo bug si fa esempio ed è facilmente ricroducibile. Dove vive questo bag? Questo bag vive in un'altra codice, vive e si produce all'interno del codice. Soprattutto, magari, in funzione completa complesse, ovviamente non è diventato un typo, un codice. Ho dimenticato un punto di virgolo, una parentesi, non è tanto quello che avrebbe disintassito. Questo è uno di quei bag che non appare subito, ma diciamo a capire subito dove si trova. Di solito si rascone in funzione un po' complesse. Poi immaginate, magari, in una catena complessa di condizioni di if, if, if, if, if, if. Non so, accade quella cosa che lo fa finire chissà dove, in questa catena, che sfugge uno secondo un problema. Quei strumenti utilizziamo per affrontare questo bag appunto perché abbiamo un bisogno di producibilità, effettori, c'è qualcosa che si è in grado di crearci oggetti, set di dati determinati caratteristiche, delle fixtus, cioè anche qui parliamo di dati, ma soprattutto di condizioni della nostra applicazione e poi test, test in locale, prima di tutto. Non l'ho famigliere di sviluppo. Non sono ancora arrivato a dirvi di scrivere le test automatici, ma facciamo un slide da usare l'anticipazione. Questi sono gli strumenti perché mettiamo il campo questi per affrontare il bag l'abbiamo individuato. A questo punto dobbiamo riprodurlo, rigolpano, come facciamo tentiamo di replicare con le fixturi, effettori, le stesse condizioni locale in modo da costruire i nostri test automatici con quelle condizioni. Quindi non so voi cosa utilizzate, ma immagino che tutti scrivano le test che sia i unit o chissà cos'altro. Scrivere la soluzione più semplice e possibile, più veloce possibile per risolvere, abbiamo poi le test che verifichano che sia risolto e poi un altro consiglio che mi sento di fare è successivamente farlo rifattere perché non è solo la buona passi in generale di TvD ma in questo caso è proprio il motivo per cui si è presentato il buon bag perché il codice quel punto era troppo scontoto e quindi lì abbiamo fatto rinascere il nostro bag quindi risolviamo la soluzione abbiamo scriviti test abbiamo la condizione in cui questo bag si gela e quindi possiamo benissimo per metterci di fare le refattini per renderlo più leggibile ma non tenibile. Questo è il primo che possiamo dire di aver si esternato. In questa sequenza di bag viene rinascito in secondo un criterio quello del via via sempre più sponentoso a un certo punto quel curvo ricorderà momenti peggiori i momenti peggiori della sua vita d'altro quindi se volete che mi fermi secondo bag ha tributi osservati però e quando c'è qualcosa che ci fa capire un pezzo che ha sempre funzionato adesso non funziona più non funziona più ma ha mai funzionato eppure sembra funzionare quando vi trovate queste soluzioni questa cosa ha mai funzionato quando ho smesso di funzionare ma come funziona in questo caso c'è Shrelly Bag l'insetto in questo caso è un'insettofogna perché è proprio uno di quei bag che non si avvate bene non riuscite a capire che non è un pezzo della pianta ma è un foglio dicevi un insetto, non è un foglio e i Shrelly Bag sono proprio questo un qualcosa che dovrebbe funzionare ma non sappiamo esattamente se stia funzionando bene diciamo che i Shrelly Bag sono pezzi di codice che pretendono di essere codici funzionate che riusciamo ad individuare come bag, proprio come questo insetto sono quando gli osserviamo direttamente altrimenti sono un pezzo del nostro codice che funziona perfettamente e ce ne sono dei due tipi quando ce ne andiamo conto si possono distinguere i due tipi uno che si manifesta così un bag su codice che non ha mai funzionato e un altro invece un bag su codice che funziona in modo diverso da come ci aspettiamo vi faccio un esempio immaginate di avere il vostro frontend con un form che è una mobilizzazione a la salvation anche via JavaScript voi fate i vostri test del poveruomo vedete che le validazioni passano scrivete un'immagine sbagliata esce scritto non è valida cliccate su ok messaggio sformigliato con successo perfetto funziona a questo punto vedete che su database non c'è niente perché il codice è apparentemente funzionato però non vi siete mai preoccupati nella scrittura del codice per come ve lo distrito sembra una roba funzionante e quando leggete il codice è funzionante descrivendo questo flusso però nessuno verifica mai il form l'altro è in modo diverso da quello che vi aspettate immaginiamo sempre una classica submission in form che però ha bisogno di una univocità da l'altra parte e voi cliccate dicendo una registrazione che ha univoco il vostro nome che abbiamo decidete voi ogni volta che cliccate dice utente già registrato anche qui perché magari da qualche parte ogni volta che cliccate su quel bottone il formo viene mandato 4, 5, 10 volte c'è qualcosa che innesca un loop certo la prima risposta era valida e le altre non ok questi sono gli strumenti che possiamo utilizzare per gli individuali e quindi poi successivamente per una lana risalda e prima di tutto il loop il loop delle archifizioni per sapere davvero cosa sta succedendo da un'altra parte sia nel primo che nel secondo caso noi ci aspettiamo con un altro server a riceva post noi ci aspettiamo che il formato che ha creato proviamo 10 chiamati potrei l'altro strumento utile per noi che utilizziamo sicuramente ad esempio il bisette di git non scritto git bisette perché immagino che gli altri strumenti abbiano questo conoscetto che non gli conosco che ci aiuta non so se l'avete mai utilizzato ci aiuta ad individuare il punto in cui l'abbiamo introdotto magari una volta oltre xera ok come affrontarlo questo bag adesso che sappiamo che c'è sappiamo le convinzioni in cui si manifesta non c'è alcuna chiamata il server potere ci sono tante proviamo a rincrodurre localmente i test quelle condizioni questo bag è ricroducibile come un ball bag la sua caratteristica è piena così facilmente ricroducibile per questo mi ha dovuto mettere in mezzo altri strumenti non riusciamo a fare questa cosa aggiungiamo log che ci aiutano tentiamo di individuare davvero il nostro codice dove si rompe che cosa prende una direzione inaspettata cerchiamo appunto di citare il bisetto dove l'abbiamo introdotto questo bag e poi inestimiamo i test direi che a questo punto anche io lo scelgo il bag dal paradosso di il mio si può considerare esatto ma adesso cominciamo a parlare un po' più doloroso il prossimo bag ha una caratteristica strana sembra che non sia causato da determinati condizioni sembra addirittura che ogni volta che lo si tenta di isolare esparisca a qualcuno è mai capitato a non consigliere qualcuno la nuoische e sorride vuol dire che l'hai superato facciamo gli tutti la plaza per forza grazie ecco questo è forse uno dei più famosi è uno dei più famosi bag estremamente problematici leisenberg leisenberg fa di tenimento a leisenberg e al paradosso di heisenberg il paradosso in fisica quantistica diceva che osservare un fenomeno ma altera il fenomeno in questo caso c'è una farfalla molte farfalle tendono a hanno sviluppato strumenti per limitizzarsi non sono riuscito a trovare una farfalla che vesse occhi in modo da fingere di essere la faccia però è quella appunto, dicendo leisenberg sembra non deterministico e spagnisce quando lo sosteniamo oppure si comporta magari un modo diverso si manifesta in punti diversi dove vive? nel codice e il motivo per cui non riusciamo ad archiapparlo è che molto spesso gli strumenti che usiamo per fare debagging tutti gli strumenti che usiamo per fare debagging in qualche modo influiscono sull'esecuzione del codice anche solo variamente sul timing l'altro punto in cui può vivere però non è solo il codice ma è nei dati e dei motivi per cui magari la nostra produzione funziona è portata in produzione e si rompe anche quando proviamo la nostra applicazione in sviluppo comunque abbiamo sempre dei dati ridotti comunque costruiti apposta per provare la nostra applicazione nel modo più veloce possibile in sviluppo questo è che è difficile a individuare quali strumenti possiamo utilizzare? qua bisogna appunto perché ci sembra che non si manifesti mai nel nostro punto bisogna sapere ancora di più di livello in base al tipo di asembag ci possono solo vivere magari gli strumenti che facciano per fare il livello c'è qualcosa che ci dica quali sono le condizioni della nostra applicazione e le momenti in cui si è rotta i processi e la quantità di memoria utilizzata oppure un'altra cosa che secondo me perfetto, 10 minuti un'altra cosa che secondo me è infinissima soprattutto il profining serve soprattutto quando il bug è in i dati quando invece il bug è nel 12 qualcosa utilissima è magari un frame graph non so se lo avete mai visto è questa roba che individua costruendo questo grafico che sembra un delle fiamme il tempo di esecuzione di un piccolo verso di codice se voi costruite un frame graph in sviluppo avrete una certa forma magari in produzione nel momento in cui si manifesta il bug troverete che in questo punto questa barrettina un po' più piccola è magari diventata gigantesca e quindi ha occupato tutte le risorse delle macchine e quindi a un certo punto e si spacchia si spacchia tant'integrazione però non siamo riusciti a scendere da qua da qua questo caso è come l'orientato il suo grafico a salire però nel codice siamo riusciti a scendere fino alla singola funzione quindi per per risolverlo come facciamo impiditumiamo i punti in cui c'è uno storzamento un esempio è magari davvero una cosa che mi è successa immaginate di dover gestire migliaia di pagamenti tutti nel giro di poco tempo nella vostra applicazione quando scrivete in test abondate magari ne fate 50, 100 tanto avete l'effetto non arrivate mai però al volume della produzione e a un certo punto questi pagamenti devono consolidarsi produrre una fattura e lì ti rende conto che c'è un problema nel vuole di data che la il tuo codice a un certo punto non riesce a gestire e ha di tutto il pezzo perché anche stai infilando il memoria troppo a roba contemporaneamente anche ci sono problemi di concorrenza chi lo sa poi ha ogni uno internazio specifici quindi profaimi per trovarlo usiamo quando capita dei dati più reali possibili magari prendendo un pezzo di qual tipo di produzione quindi a questo punto sono uscite più da dove riproduciamo la condizione per riuscire a farlo fallire e possiamo trattarlo da questo punto in poi con un bug abbiamo le condizioni così si manifesta possiamo ritornare ad esempio un sistemaggio per fare questo passaggio poi c'è un vicino a uno mesi che lo sa ok l'ultimo c'è già la faccia l'ultimo internazio l'ultimo è terribile sono convinto che si è capitato a tutti ed è il barb in cui l'attributo osservabile è questo tutto è rotto, non funziona niente ma proprio niente non solo il sito andate a guardare provate a conmettermi ad una tabese vi dico che non potete conmettermi ad una tabese alla macchina, magari la fatica e guardate i log, il log si è completamente buoti non sta più scrivendo niente tutto, tutto si è rotto vedete come è possibile che lo abbia sentito quella riga di codici che ha spaccato tutto e pure sono cose che capitano sono davvero convinti se non viene mai capitato vi i capitano questo si chiama Mandelberg da Mandelbrot scrivesse questa funzione quella che genera che poi tradotta più tecnologica generale disegno le infruttaglie quindi una piccola funzione è in grado di generare l'immagine infinita e appunto sembra assolutamente casuale perché non è possibile che abbia scritto una riga di codici che ha spaccato tutto dal sito alla macchina e che si riproduca con una velocità infinita io ho spaccato la mia vista sul sito e mamma non è possibile che questo piccolo bag abbia rotto tutto quanto e questo punto era con questa funzione di Mandelbrot si genera in frontale dove vive? vive nel sistema non vive nel nostro codice state tranquilli non è possibile che spaccate tutto il vostro codice al massimo spacca il processo in cui è in esecuzione attenzialmente soprattutto perché lavoriamo in tecnologia web è proprio ecco magari se si è rotto qualcosa grazie alla vostra pagina web non è grazie al vostro bag questo piccolo è riuscito a passare la vita per arrivare alla macchina strumenti tutti gli strumenti che possono servire per monitorare visto che vive nel serve per monitorare il serve e poi per questo dico succederà a tutti ho messo un strumento molto specifico perché è quello che succede nel 99% di casi quando si manifesta questo bag è che il disco è pieno il disco è pieno non si può più far nulla non può più scrivere in nessuna parte del sistema neanche in benza di gavidog e questo uccide tutto non c'è più nessun processo che riesce a prendersi un pezzettino in più è pieno lo strumento è se riuscite ancora a entrare nel serve per entrare dietro le roacche spazio occupato 100% spazio libero 0% è l'urica ed è la cosa più comune anche per questo per risolvere questo bag non si può far nulla anticintamente per un lavoro di monitorare in questo caso dobbiamo davvero stare attenti a capire come sta andando in situazione dobbiamo accelerare il server e puoi fare cose che si mettono in campo solitamente per prevenire o per risolvere usate, non stiesce il troppo riavviare uccide i processi oppure fare un local date per esempio che è la prima cosa che si fa per prevenire questo tipo di problemi benissimo due minuti ci siamo anche il bag per concludere un piccolo recap ci sono tanti di bag ho scelto quelli che secondo me sono più più comuni scoprendo appunto che esiste una bella classificazione ma di tutto questo per affrontarli e condensifare partiamo dall'asservazione, classifichiamoli quando abbiamo capito quale tipo di bag è proviamo a ricrodurli isolarli sentiamo che riportare la manifestazione del bag che normalmente è deterministico scriviamo test e si stendiamo debajo scriviamo test scrivere test non testare e poi soprattutto ognuno si costruisca in base alla cosa su cui stai lavorando il proprio kit di strumenti perché tanto nessuno al mondo ha l'instituto del debugging ma si possono avere semplicemente gli strumenti giusti delle esperienze