Porta via: Il conduttore Eric Kavanagh ha discusso del debug e della profilazione del database con il Dr. Robin Bloor, Dez Blanchfield e gli IDERA Bert Scalzo.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Eric Kavanagh: Va bene, signore e signori, sono le 4:00 ora orientale di mercoledì, e ovviamente questo significa.
Robin Bloor: Non ti sento, Eric.
Eric Kavanagh: Ci sono stato giorni fa, quindi non sei solo. Ma oggi l'argomento è roba davvero interessante. È il tipo di cosa che vuoi assicurarti che accada in background nella tua azienda, a meno che tu non sia la persona che lo fa, nel qual caso vuoi assicurarti di farlo correttamente. Perché parlavano di debug. A nessuno piacciono i bug, a nessuno piace quando il software smette di funzionare - le persone si arrabbiano, gli utenti diventano ostili. Questo non è buono. Quindi, stavamo per parlare di "Risposta rapida: debug del database e creazione di profili per il salvataggio".
C'è davvero un punto sul tuo, colpiscimi su, @eric_kavanagh ovviamente.
Quest'anno è caldo. E il debug sarà caldo, non importa quale. Sarà davvero uno di questi problemi che non se ne andrà mai, non importa quanto siamo bravi a fare queste cose, ci saranno sempre dei problemi, quindi la chiave è come arrivare a dove puoi risolverli rapidamente? Idealmente, hai grandi programmatori, grandi ambienti, dove non troppo va storto, ma come dice il vecchio proverbio, "Gli incidenti accadono nella migliore delle famiglie". E lo stesso vale per le organizzazioni. Quindi, questa roba succede, sta per succedere, la domanda è: quale sarà la tua soluzione per affrontarla e risolvere quei problemi?
Bene, ascoltiamo il dottor Robin Bloor, poi il nostro Dez Blanchfield da sotto, e, naturalmente, il nostro buon amico, Bert Scalzo, di IDERA. E infatti, consegnerò le chiavi a Robin Bloor, lo porterò via. Il pavimento è tuo.
Robin Bloor: OK. Questo è un argomento interessante. Ho pensato che, poiché Dez probabilmente continuerà a parlare delle tecniche e delle storie di guerra sul debug, ho pensato di fare una discussione di base in modo da poter avere un quadro completo di ciò che sta accadendo. L'ho fatto per molto tempo, ed ero un programmatore, quindi mi piace, e sono stato quasi tentato da questa presentazione di iniziare a diffondere lirica sull'idea dell'open source, ma ho pensato che avrei lasciato questo a qualcun altro.
Ecco un elenco di bug famosi, e molti di questi entrano nella top list di anybodys, fondamentalmente, tutti tranne gli ultimi due costano almeno $ 100 milioni. Il primo era il Mars Climate Orbiter, si perse nello spazio ed era a causa di un problema di codifica, in cui le persone confondevano le unità metriche con (ride) piedi e pollici. Nell'Ariane Five Flight 501 c'era una discrepanza tra un motore acceso e i computer che avrebbero dovuto far funzionare il missile al momento del lancio. Più guasti al computer, esplosione di un razzo, notizie principali. Gasdotto sovietico nel 1982, si dice che sia la più grande esplosione nella storia del pianeta; Non sono sicuro che lo sia. I russi rubarono alcuni software di controllo automatizzato e la CIA si rese conto che lo avrebbero fatto e vi avrebbe messo dei bug, ei sovietici lo implementarono senza test. Quindi, ha fatto saltare in aria una pipeline, ha pensato che fosse divertente.
Il verme di Morris fu un esperimento di codifica, che divenne improvvisamente un verme rapace che girò su tutti gli altri - apparentemente causò danni per 100 milioni di dollari; questa è una stima ovviamente. Intel ha commesso un famoso errore con un chip matematico - un'istruzione matematica sul chip Pentium nel 1993 - che avrebbe dovuto costare oltre $ 100 milioni. Il programma Apples Maps è probabilmente il lancio peggiore e più disastroso di qualsiasi cosa Apple abbia mai fatto. Le persone che hanno provato a usarlo, erano, direi, qualcuno stava guidando lungo la 101, e hanno scoperto che la mappa di Apple diceva che si trovavano nel mezzo della baia di San Francisco. Quindi, le persone hanno iniziato a riferirsi all'app di Apple Maps come iLost. La nostra interruzione più lunga del 1990 è interessante dal punto di vista del costo di qualcosa del genere: AT&T è uscito per circa nove ore ed è costato circa $ 60 milioni per le chiamate interurbane.
Ed ero in una compagnia di assicurazioni del Regno Unito, e il database, hanno implementato una nuova versione del database e ha iniziato a cancellare i dati. E me lo ricordo molto bene, perché in seguito sono stato chiamato per prendere parte a una sorta di selezione del database a causa di ciò. Ed è stato molto interessante il fatto che avessero preso una nuova versione del database e che avessero una serie di test che hanno fatto per le nuove versioni del database che ha superato tutti i test. Ha trovato un modo davvero oscuro di cancellare i dati.
Quindi, questo è quello. Pensavo che parlassi della mancata corrispondenza dell'impedenza e dell'SQL emesso. È interessante notare che i database relazionali archiviano i dati in tabelle e programmatori tendono a manipolare i dati in strutture di oggetti che non si associano molto bene alle tabelle. E per questo motivo, ottieni quello che viene chiamato disadattamento dell'impedenza e qualcuno deve affrontarlo in un modo o nell'altro. Ma ciò che accade realmente, perché un modello, il modello dei programmatori e il database un altro modello, non sono particolarmente allineati. Si ottengono bug che non accaderebbero se l'industria avesse costruito cose che funzionano insieme, il che penso sia divertente. Quindi, fondamentalmente, per quanto riguarda i programmatori, quando si ottengono gerarchie possono essere tipi, può insiemi di risultati, può essere scarsa capacità API, può essere un sacco di cose che gettano le cose in termini di interazione con il database. Ma la cosa più importante per me è davvero interessante; mi ha sempre stupito che tu avessi questa barriera SQL che è anche una sorta di impedenza in un modo in cui i programmatori e il database lavorano l'uno con l'altro. Quindi, SQL ha il riconoscimento dei dati, che va bene e ha DML per selezionare, proiettare e unire, che va bene. È possibile sfruttare molte funzionalità in termini di estrazione dei dati dal database. Ma ha pochissimo linguaggio matematico per fare le cose. Ha un po 'di questo e quello e ha pochissime cose basate sul tempo. E per questo motivo, SQL è un mezzo imperfetto, se vuoi, per ottenere i dati. Quindi, i ragazzi del database hanno creato procedure memorizzate per vivere nel database e il motivo delle procedure memorizzate che vivevano lì era che non volevi davvero lanciare dati avanti e indietro in un programma.
Poiché alcune delle funzionalità erano estremamente specifiche per i dati, quindi non si trattava solo di integrità referenziale e eliminazioni a cascata e cose del genere, il database si occupava di tutto l'improvviso che stai inserendo funzionalità in un database, il che significa ovviamente che la funzionalità per un l'applicazione potrebbe essere suddivisa tra il codificatore e il database stesso. E ciò ha reso il lavoro di implementazione di alcuni tipi di funzioni davvero piuttosto difficile e quindi più soggetto a errori. Quindi, questo è un lato del gioco del database, perché significa che hai avuto molte implementazioni per esempio, che sono stato coinvolto in database relazionali c'è davvero un sacco di codice che si trova in procedure memorizzate gestite separatamente dal codice che si trova nelle applicazioni. E sembra una cosa molto strana, deve essere abbastanza intelligente nel fare varie cose.
Ho pensato che parlassi anche delle prestazioni del database perché gli errori di prestazione sono spesso considerati bug, ma in pratica puoi avere un collo di bottiglia nella CPU, nella memoria, sul disco, sulla rete e puoi avere problemi di prestazioni a causa del blocco. L'idea sarebbe che il programmatore non aveva davvero bisogno di preoccuparsi delle prestazioni e il database in realtà avrebbe funzionato abbastanza bene. Dovrebbe essere progettato in modo tale che il programmatore non abbia bisogno di saperlo. Tuttavia, si ottiene una cattiva progettazione del database, si ottiene una cattiva progettazione del programma, si ottiene la concorrenza nella miscelazione del carico di lavoro, che può anche portare a problemi di prestazioni. Ottieni il bilanciamento del carico, la pianificazione della capacità, la crescita dei dati, che può causare l'arresto o il rallentamento di un database. È una cosa interessante, quando i database diventano quasi pieni, rallentano. E puoi avere problemi con i livelli di dati in termini di replica e necessità di replicare e necessità di eseguire backup e ripristino. Comunque, questa è una panoramica generale.
L'unica cosa che vorrei dire è che il debug del database può essere solo oneroso e non banale - e lo dico perché l'ho fatto molto - e spesso scoprirai che è come tutte le situazioni di debug che io abbia mai sperimentato è, è la prima cosa che vedi mai è un casino. E devi provare ad andare dal caos a capire come è nato il caos. E spesso quando guardi un problema di database tutto ciò che stai guardando sono dati corrotti e stai pensando: "Come diavolo è successo?"
In ogni caso, passerò a Dez, che probabilmente dirà più parole di saggezza di quante ne venissi fuori. Non so come passarti la palla, Dez.
Eric Kavanagh: Lo passerò, aspetta, resisti.
Voce automatizzata: Linee partecipanti disattivate.
Eric Kavanagh: Va bene, aspetta un secondo, lasciami dare la palla a Dez.
Dez Blanchfield: Grazie Eric. Sì, dottor Robin Bloor, hai davvero ragione: questo è un argomento, un bugbear che dura tutta la vita se perdonerai il gioco di parole, mi dispiace non potermi aiutare su quello. Spero che tu possa vedere la mia prima schermata lì, le mie scuse per il problema della dimensione del carattere in alto. L'argomento dei bug è una lezione che dura tutto il giorno, in molti casi nella mia esperienza. È un argomento così ampio e ampio, quindi focalizzerò l'attenzione su due aree chiave, in particolare il concetto di ciò che consideriamo un bug, ma un problema di programmazione. Penso che in questi giorni l'introduzione di un bug di per sé venga generalmente rilevata dagli ambienti di sviluppo integrati, sebbene possano essere bug di lunga durata. Ma spesso è più un caso di codice di profilazione ed è possibile scrivere codice che funzioni, che dovrebbe essere un bug. Quindi, la diapositiva del mio titolo qui, in realtà ne avevo una copia in altissima risoluzione A3, ma sfortunatamente è stata distrutta in un trasloco. Ma questa è una nota scritta a mano su un foglio di programmazione del 1945 circa, dove presumibilmente alcune persone all'Università di Harvard negli Stati Uniti, la loro seconda costruzione di una macchina chiamata Mark II. Stavano eseguendo il debug di alcuni problemi, in un linguaggio comune, ma stavano cercando di trovare un errore, e si è scoperto che qualcosa di leggermente diverso da quello che era un hardware e un presunto problema software è arrivato.
Quindi, il mito urbano è quello intorno al 9 settembreesimoNel 1945 un team dell'Università di Harvard stava facendo a pezzi una macchina, si imbatterono in qualcosa che chiamavano "relè settanta" - a quei tempi la programmazione era fatta in senso fisico, si avvolgeva il codice su una tavola, ed era così che si programmava efficacemente il macchina - e hanno trovato questo numero di relè settanta c'era qualcosa che non andava, e si scopre che il vero termine "insetto" è nato perché era letteralmente una falena - presumibilmente c'era una falena incastrata tra un pezzo di filo di rame da un posto all'altro. E la storia narra che la leggendaria Grace Hopper come questa didascalia, per la mia diapositiva del titolo, "il primo caso reale di un bug trovato" cita una citazione.
Ma come Robin ha evidenziato in precedenza nella sua prima diapositiva, il concetto di un bug risale a quanto possiamo immaginare gli umani che fanno il calcolo, concetti come una patch. Il termine "patch" deriva da un pezzo di nastro che viene attaccato su un foro su una scheda perforata. Ma il punto è che il termine "debugging" è venuto fuori da questo concetto di ricerca di un bug in una macchina fisica.E da allora, abbiamo usato quella terminologia per cercare di affrontare i problemi, non tanto quanto i problemi di codifica in un programma che non viene compilato, ma come un programma che non funziona bene. E in particolare non è stato profilato solo trovare cose come loop infiniti che non vanno da nessuna parte.
Ma abbiamo anche uno scenario, e ho pensato di mettere un paio di diapositive divertenti prima di entrare nei dettagli. Ecco il classico cartone animato, chiamato XKCD sul web, e il fumettista ha alcune viste piuttosto divertenti sul mondo. E quelli di un bambino chiamato "Tavolini Bobby" e presumibilmente i suoi genitori hanno chiamato questo giovane ragazzo Robert); DROP TABLE Studenti; - e il suo nome, e una specie di “Ciao, questa è la scuola dei tuoi figli che ha qualche problema con il computer”, e il genitore risponde: “Oh caro, ha rotto qualcosa?” E l'insegnante dice: “Bene, in un certo senso ", e l'insegnante chiede," hai davvero chiamato tuo figlio Robert); DROP TABLE Studenti; -? ”E il genitore dice:“ Oh sì, piccoli tavoli Bobby che lo chiamiamo. ”Comunque, continuano dicendo che ora hanno perso il record degli studenti, spero che tu sia felice. E la risposta è: "Bene, dovresti pulire e disinfettare gli input del tuo database". E lo uso molte volte per parlare di alcuni dei problemi che abbiamo nel trovare cose nel codice, che spesso il codice non guarda anche i dati .
Un altro divertente, non so se questo è reale o no - sospetto che sia una parodia - ma, di nuovo, tocca anche il mio osso divertente. Qualcuno cambia la targa sulla parte anteriore della propria auto, con una dichiarazione simile che fa cadere i database negli autovelox e così via che cattura le targhe delle auto. E mi riferisco sempre ad esso come se dubitassi che un programmatore avesse anticipato un colpo al codice da un vero veicolo a motore, ma non lo sottovalutavo mai - il potere di un fanatico arrabbiato.
(Risata)
Ma questo mi porta al mio punto chiave, immagino, e cioè che una volta potevamo eseguire il debug e profilare il codice come semplici mortali. Ma sono molto dell'idea che quel tempo sia passato, e aneddoticamente nella mia esperienza, la mia prima - e questo mi invecchierà terribilmente, ne sono certo; Robin sei il benvenuto a prendermi in giro per questo, ma storicamente sono venuto da un background all'età di 14 anni vagando per la fine della città e bussando alla porta di un data center chiamato "Data Com" in Nuova Zelanda e chiedendo se Potevo guadagnare un po 'di soldi a scuola riportando l'autobus in ritardo a casa, ogni giorno circa 25 km di pendolarismo, inserendo carta e nastri e unità a nastro, ed essendo solo un amministratore generale. E curiosamente mi hanno dato un lavoro. Ma nel tempo, sono riuscito a mettermi nello staff e trovare i programmatori e ho capito che adoravo la programmazione e ho seguito il processo di esecuzione di script e lavori batch, che alla fine è ancora codice. Devi scrivere script e lavori batch che assomigliano a mini programmi e poi passare l'intero processo di seduta su un terminale 3270 scrivendo a mano il codice.
In effetti, la mia prima esperienza è stata su un terminale di teletipo, che in realtà era un er fisico a 132 colonne. In sostanza, pensa a una macchina da scrivere molto vecchia con carta che la scorreva, perché non avevano un tubo CRT. E il debugging del codice su questo era un problema molto banale, quindi tendevi a scrivere tutto il tuo codice a mano, e poi agisci come un dattilografo, facendo del tuo meglio per non ottenere errori da intrufolarsi, perché è estremamente frustrante doverlo dire l'editor di una riga per passare a una determinata riga e quindi alla riga e quindi a digitare nuovamente. Ma una volta era questo il modo in cui abbiamo scritto il codice ed è così che abbiamo eseguito il debug e siamo diventati molto, molto bravi. E in effetti, ci ha costretti ad avere ottime tecniche di programmazione, perché era una vera seccatura risolverlo. Ma poi il viaggio è andato avanti - e ne eravamo tutti a conoscenza - è passato dall'esperienza del terminale 3270 nel mio mondo, a Digital Equipment VT220 dove puoi vedere le cose sullo schermo, ma di nuovo, stavi solo facendo la stessa cosa che hai fatto sul nastro di carta una sorta di formato ed solo su un CRT, ma sei stato in grado di eliminare più facilmente e non hai avuto quel suono "dit dit dit dit".
E poi sai, i terminali Wyse - come il Wyse 150, probabilmente la mia interfaccia preferita per un computer di sempre - e quindi il PC e poi il Mac, e quindi oggigiorno GUI e ID moderni basati sul web. E una serie di programmi attraverso questo, programmazione in uno e assemblatore e PILOT e Logo e Lisp e e Fortran e Pascal e linguaggi che potrebbero far rabbrividire le persone. Ma queste sono lingue che ti hanno costretto a scrivere un buon codice; non ti hanno permesso di cavartela con le cattive pratiche. C, C ++, Java, Ruby, Python - e andiamo più avanti in quella fase di programmazione, otteniamo più script-like, ci avviciniamo sempre più al linguaggio di query strutturata e ai linguaggi come PHP che vengono effettivamente utilizzati per invocare SQL. Il punto di dirti che, dal mio background, sono stato autodidatta in molti modi e quelli che mi hanno aiutato a imparare, mi hanno insegnato ottime pratiche di programmazione e ottime pratiche in materia di progettazione e processi per assicurarmi di non presentare buggy codice.
Al giorno d'oggi metodi di programmazione, cose come, ad esempio, Structured Query Language, SQL, è un linguaggio di query molto potente e semplice. Ma l'abbiamo trasformato in un linguaggio di programmazione e non credo davvero che SQL sia mai stato progettato per essere un linguaggio di programmazione moderno, ma l'abbiamo inclinato per diventare quello. E questo introduce tutta una serie di problemi, a causa di quando pensiamo da due punti di vista: dal punto di vista della codifica e dal punto di vista DBA. È molto facile venire e introdurre bug per cose come solo tecniche di programmazione scadenti, sforzi pigri nella scrittura di codice, mancanza di esperienza, la classica pipì che ho per esempio con persone SQL che saltano su Google e cercano qualcosa e trovano un sito Web ottenuto un esempio e fare una copia e incolla del codice esistente. E quindi replicare una cattiva codifica, cattiva pratica e metterlo in produzione, perché capita solo che dia loro i risultati che vogliono. Hai avuto altre sfide, per esempio, in questi giorni tutti si precipitavano verso questo, ciò che chiamiamo la gara a zero: cercare di fare tutto così a buon mercato e così in fretta, che abbiamo uno scenario in cui non impiegavamo personale a basso costo. E non intendo questo in modo disonesto, ma non assumevo esperti per ogni possibile lavoro. C'era una volta qualcosa a che fare con i computer era la scienza missilistica; era coinvolto in cose che andavano male e che erano molto rumorose, o andavano nello spazio o gli ingegneri erano uomini e donne altamente qualificati che avevano conseguito la laurea e avevano una rigorosa educazione che impediva loro di fare cose folli.
In questi giorni, ci sono molte persone che si dedicano allo sviluppo, alla progettazione e al database che non hanno avuto anni di esperienza, che non hanno necessariamente avuto la stessa formazione o supporto. E così finisci con uno scenario del tradizionale dilettante contro esperto. E c'è una linea famosa, non riesco davvero a ricordare chi ha creato la citazione, la linea dice: “Se pensi che sia costoso assumere un esperto per fare un lavoro, aspetta di assumere un paio di dilettanti che creano un problema e devi ripulirlo. ”Quindi SQL ha quel problema, ed è molto, molto facile da imparare, è molto facile da usare. Ma non è, a mio avviso, un linguaggio di programmazione perfetto. È molto facile fare cose come fare una stella selezionata da qualsiasi luogo e trascinare tutto ciò in un linguaggio di programmazione che ti fa sentire più a tuo agio con PHP e Ruby o Python, e usare il linguaggio di programmazione che conosci nativamente per fare la manipolazione dei dati, piuttosto che eseguire una query più complessa in SQL. E lo vediamo molto, e poi la gente si chiede perché il database funzioni lentamente; è perché un milione di persone stanno cercando di acquistare un biglietto da un sistema di biglietteria online, dove fa una stella selezionata da qualsiasi luogo.
Questo è un esempio davvero estremo, ma ottieni il punto da tutto ciò. Quindi, per dare davvero un pugno a quel punto a casa, ecco un esempio che porto molto in giro. Sono un grande fan della matematica, adoro la teoria del caos, adoro i set di Mandelbrot. Sul lato destro c'è una rappresentazione del set di Mandelbrot, che sicuramente conoscevo tutti. E sulla sinistra c'è un pezzo di SQL che lo rende effettivamente. Ora, ogni volta che lo metto su uno schermo da qualche parte, sento questo “Oh mio Dio, qualcuno ha reso la serie Mandelbrot con SQL, sei serio? È folle! ”Bene, il punto è quello di illustrare quello che stavo solo delineando lì, e questo è sì, infatti ora puoi programmare quasi tutto in SQL; è un linguaggio di programmazione molto sviluppato, potente e moderno. Quando in origine era un linguaggio di query, era progettato per ottenere dati. Quindi, ora abbiamo costrutti molto complessi e abbiamo procedure memorizzate, abbiamo applicato la metodologia di programmazione a un linguaggio ed è quindi molto facile per cattive pratiche di programmazione, mancanza di esperienza, codice taglia e incolla, personale a basso costo che cerca di essere un personale ben pagato, le persone che fingono di sapere, ma devono imparare sul posto di lavoro.
Un'intera gamma di cose in cui la profilazione del codice e ciò che chiamiamo debug, che non è tanto trovare bug che impediscono il funzionamento dei programmi, ma bug che danneggiano il sistema e un codice mal strutturato. Quando guardi questo schermo ora e pensi che sia proprio così, è carino e pensi: "Caspita, che bella grafica, mi piacerebbe farcela." Ma immagina di correre su un pezzo di logica aziendale. Sembra piuttosto pulito, ma parla di una teoria del caos resa graficamente graficamente, ma quando pensi a cosa potrebbe essere potenzialmente utilizzato in alcune logiche aziendali, ottieni l'immagine molto rapidamente. E per illustrarlo davvero - e mi dispiace che i colori siano invertiti, dovrebbe essere uno sfondo nero e il verde uno schermo verde, ma puoi ancora leggerlo.
Sono andato e ho dato una rapida occhiata a un esempio di cosa potresti potenzialmente fare se fossi davvero pazzo e non avessi alcuna esperienza e venissi da un diverso background di programmazione e abbia applicato applicazioni come C ++ a SQL, per illustrare davvero il mio punto, prima Consegnerò al nostro dotto ospite di IDERA. Questa è una query strutturata scritta come C ++, ma codificata in SQL. E in realtà viene eseguito, ma viene eseguito per un periodo da tre a cinque minuti. E ritira apparentemente una riga di dati da più database, più join.
Ancora una volta, il punto è che se non si hanno gli strumenti corretti, se non si hanno le piattaforme e gli ambienti corretti per essere in grado di catturare queste cose, e entrano in produzione, e quindi si hanno 100.000 persone che colpiscono un sistema ogni giorno, o ora o minuto, molto presto si finisce con un'esperienza di Chernobyl in cui il grande ferro inizia a sciogliersi e seppellirsi nel nucleo del pianeta, perché quel pezzo di codice non dovrebbe mai entrare in produzione. I tuoi sistemi e i tuoi strumenti, mi scusi, dovrebbero raccoglierlo prima che vada ovunque vicino al - anche attraverso il processo di test, anche attraverso UAT e l'integrazione di sistemi, quel pezzo di codice dovrebbe essere raccolto ed evidenziato e qualcuno dovrebbe essere messo da parte e dicendo: "Guarda, questo è davvero un bel codice, ma consente di ottenere un DBA che ti aiuti a costruire correttamente quella query strutturata, perché francamente, è semplicemente brutto." E gli URL lì, puoi andare a dare un'occhiata - è indicato come il la query SQL più complessa che tu abbia mai scritto. Perché credimi, che in realtà si compila, funziona. E se lo tagli e incolli e deridi il database, è qualcosa da guardare; se hai gli strumenti per guardare il database, prova a scioglierti per un periodo da tre a cinque minuti, per richiamare quella che è una riga.
Quindi, per riassumere, con questo in mente, tutto il mio background in programmazione mi ha insegnato che puoi dare alla gente una pistola e se non stanno attenti si spareranno al piede; il trucco è mostrare loro dove si trova il meccanismo di sicurezza. Con gli strumenti giusti e il software giusto a portata di mano, dopo aver eseguito la codifica, puoi rivedere il tuo codice, puoi trovare problemi profilando il codice, puoi trovare efficacemente bug non intenzionali che sono problemi di prestazioni, e come ho detto prima , una volta, potevi farlo guardando uno schermo verde. Non puoi più; ci sono centinaia di migliaia di righe di codice, ci sono decine di migliaia di app distribuite, ci sono milioni di database in alcuni casi e persino i super umani non possono più farlo a mano. Hai letteralmente bisogno del software giusto e degli strumenti giusti a portata di mano e hai bisogno che il team utilizzi tali strumenti, in modo da poter trovare questi problemi e risolverli molto, molto rapidamente, prima di arrivare al punto, mentre il Dr. Robin Bloor ha sottolineato, le cose diventano o disastrose e le cose esplodono, o più comunemente, iniziano solo a costarti un sacco di dollari e un sacco di tempo e fatica e distruggere il morale e le cose, quando non riescono a capire perché le cose prendono molto tempo per correre.
E con questo in mente, sto per consegnare al nostro ospite e non vedo l'ora di sapere come hanno risolto questo problema. E in particolare la demo penso che stavo per ricevere. Eric, passerò di nuovo.
Eric Kavanagh: OK, Bert, portalo via.
Bert Scalzo: Ok grazie. Bert Scalzo qui da IDERA, sono il product manager dei nostri strumenti di database. E parlerò del debug. Penso che una delle cose più importanti che Robin abbia detto in precedenza - ed è proprio vero che il debug è oneroso e non banale, e quando vai al database il debug è un ordine di grandezza ancora più oneroso e non banale - quindi, quello era una citazione importante.
OK. Volevo iniziare con la cronologia di programmazione, perché molte volte vedo persone che non eseguono il debug, non usano un debugger, programmano semplicemente con qualsiasi linguaggio stiano usando e molte volte mi dicono: "Bene, quelle cose debugger sono nuove, e non abbiamo ancora iniziato a usarle. ”E quindi quello che faccio è mostrare loro questo diagramma temporale, una specie di preistoria, la vecchiaia, il medioevo, il suo tipo di dire dove eravamo termini dei linguaggi di programmazione. E avevamo lingue molto vecchie a partire dal 1951 con codice assembly, e Lisp, FACT e COBOL. Quindi entriamo nel prossimo gruppo, Pascals e Cs e poi nel prossimo gruppo, i C ++, e guardiamo dove si trova quel punto interrogativo - quel punto interrogativo è approssimativamente proprio intorno al 1978 fino forse al 1980. Da qualche parte in quell'intervallo che avevamo debugger a nostra disposizione, e quindi per dire: "Ehi, non sto usando un debugger, perché questa è una di quelle cose nuove", quindi devi aver iniziato a programmare, sai, negli anni '50, perché è l'unico modo in cui potresti ottenere via con quella richiesta.
L'altra cosa divertente di questo grafico è che Dez ha appena fatto un commento su Grace Hopper, in realtà conoscevo Grace, quindi è un po 'divertente. E poi l'altra cosa di cui ho riso è che ha parlato di teletipi e sono seduto lì dicendo "Amico, quello è stato il più grande salto che abbiamo mai fatto in termini di produttività, quando siamo passati dalle carte ai teletipi, è stato il più grande salto di sempre". e ho programmato in tutte le lingue qui, incluso SNOBOL, di cui nessuno aveva mai sentito parlare prima, era un CDC, Control Data Corporation, quindi immagino che sto diventando un po 'troppo vecchio per questo settore.
Dez Blanchfield: Stavo per dire che ci hai invecchiato terribilmente lì.
Bert Scalzo: Sì, te lo dico, mi sento come nonno Simpson. Quindi guardo al debug e ci sono diversi modi di fare il debug. Potresti parlare di ciò che tutti noi consideriamo come tradizionale entrare in un debugger e passare attraverso il codice. Ma anche le persone strumenteranno il loro codice; è qui che inserisci le istruzioni nel tuo codice e forse produci un file di output, un file di traccia o qualcosa del genere, e quindi strumenti il tuo codice. Direi che il debug è un po 'più difficile, un modo per farlo, ma conta. Ma abbiamo anche la famosa dichiarazione: guardi e le persone inseriscono effettivamente delle dichiarazioni e ho visto uno strumento in cui - ed è uno strumento di database - dove se non sai come usare un debugger, premi un pulsante e si attaccherà dichiarazioni in tutto il codice per te e poi quando hai finito premi un altro pulsante e le rimuove. Perché è così che molte persone eseguono il debug.
E il motivo per cui eseguiamo il debug è duplice: prima di tutto, dobbiamo trovare cose che rendono inefficace il nostro codice. In altre parole, in genere ciò significa che c'è un errore logico o abbiamo perso un requisito aziendale, ma ciò che è, è che il codice non è efficace; non fa quello che ci aspettavamo. L'altra volta che andiamo e facciamo il debug, è per efficienza e potrebbe essere un errore logico, ma quello che è, è che ho fatto la cosa giusta, non torna abbastanza velocemente. Ora, sottolineo questo punto perché un profiler probabilmente sarebbe meglio per quel secondo scenario e parleremo sia di debugger che di profiler. Inoltre, esiste questo concetto di debug remoto; questo è importante perché molte volte se sei seduto sul tuo personal computer e stai usando un debugger, che colpisce un database in cui il codice viene effettivamente eseguito sul database, stai effettivamente facendo quello che viene chiamato debug remoto. Potresti non rendertene conto, ma è quello che sta succedendo. E poi, è molto comune con questi debugger avere punti di interruzione, guardare punti, entrare e scavalcare e alcune altre cose comuni, che mostrerò quelle su un'istantanea dello schermo in un momento.
Ora, profilazione: puoi fare la profilazione in un paio di modi diversi. Alcuni diranno che il carico di lavoro acquisisce e riproduce dove cattura tutto, ciò che conta come profilazione. La mia esperienza è stata migliore se ha fatto il campionamento. Non c'è motivo di cogliere ogni singola affermazione, perché alcune affermazioni potrebbero essere eseguite così rapidamente che non ti interessa, quello che stai davvero cercando di vedere è, beh, quelle che continuano a comparire più e più volte, perché durano troppo a lungo . Quindi, a volte la profilazione può significare campionare piuttosto che eseguire l'intera cosa. E in genere, otterrai un tipo di output che puoi utilizzare, ora che potrebbe essere visivo all'interno di un ambiente di sviluppo IDE, dove potrebbe darti come un istogramma delle prestazioni delle varie righe di codice, ma potrebbe anche sia che produca un file di traccia.
I profiler sono apparsi per la prima volta nel 1979. Quindi, anche quelli sono in circolazione da molto tempo. Ottimo per trovare il consumo di risorse o problemi di prestazioni, in altre parole quell'efficienza. In generale, è separato e distinto dal debugger, anche se ho lavorato con i debugger che fanno entrambi allo stesso tempo. E mentre i profiler penso che siano i più interessanti dei due strumenti, se sento che non abbastanza persone eseguono il debug, quindi sicuramente non abbastanza profilo delle persone, perché un debugger su dieci ne apparirà, a quanto pare. E questo è un peccato, perché la profilazione può davvero fare una grande differenza. Ora, i linguaggi del database, come abbiamo già detto in precedenza, hai SQL - e abbiamo in qualche modo forzato il piolo circolare nel foro quadrato qui e costretto a diventare un linguaggio di programmazione - e Oracle.Questo è PL / SQL - questo è il linguaggio procedurale SQL - e SQL Server, il suo Transact-SQL, il suo SQL-99, il suo SQL / PSM - per, credo, il suo modulo stored procedure. Postgres gli dà un altro nome, DB2 ancora un altro nome, Informix, ma il punto è che tutti hanno costretto costrutti di tipo 3GL; in altre parole, i cicli FOR, alle dichiarazioni variabili e tutte le altre cose estranee a SQL fanno ora parte di SQL in quelle lingue. Quindi, devi essere in grado di eseguire il debug di un PL / SQL o Transact-SQL proprio come faresti con un programma Visual Basic.
Ora, oggetti di database, questo è importante perché la gente dirà: "Bene, quali cose devo fare il debug in un database?" E la risposta è, beh, qualunque cosa tu possa archiviare nel database come codice - se sto facendo T- SQL, o PL / SQL - e sto memorizzando oggetti nel database, probabilmente è una procedura memorizzata o una funzione memorizzata. Ma c'è anche un trigger: un trigger è un po 'come una procedura memorizzata, ma si attiva in qualche tipo di evento. Ora, alcune persone nei loro trigger inseriranno una riga di codice e chiameranno una procedura memorizzata in modo che mantengano tutto il loro codice e procedure memorizzati, ma è lo stesso concetto: è ancora il trigger che potrebbe essere ciò che avvia il tutto. E poi come Oracle, hanno qualcosa chiamato un pacchetto, che è una specie di libreria se vuoi. Metti 50 o 100 stored procedure in un raggruppamento, chiamato pacchetto, quindi è un po 'come una libreria. Quindi, ecco il debugger alla vecchia maniera; questo è in realtà uno strumento che andrà effettivamente a inserire tutte queste istruzioni di debug nel tuo codice per te. Quindi, ovunque vedi blocco di debug, non rimuovere, il debugger automatico si avvia e traccia, quelli erano tutti bloccati da qualche strumento. E le righe al di fuori di ciò, che è la minoranza del codice, è il metodo di debug non manuale.
E il motivo per cui lo sollevo è, se stai cercando di farlo a mano, in realtà stai andando a digitare più codice di debug per inserire tutte queste dichiarazioni di quelle che hai con il codice. Quindi, mentre questo può funzionare, e anche se è meglio di niente, questo è un modo molto difficile per eseguire il debug, specialmente da allora, cosa succede se ci vogliono 10 ore per far funzionare questa cosa, e dove ha un problema è nella riga tre? Se avessi fatto una sessione di debug interattivo, avrei saputo alla riga tre - cinque minuti - ehi, c'è un problema qui, potrei smettere. Ma con questo, devo aspettare che venga eseguito, fino al completamento e poi devo guardare qualche file di traccia che probabilmente contiene tutte queste affermazioni e provare a trovare l'ago nel pagliaio. Ancora una volta, questo è meglio di niente, ma non sarebbe il modo migliore di lavorare. Ora, questo è l'aspetto di quel file proveniente dalla diapositiva precedente; in altre parole, ho eseguito il programma e ha appena ricevuto un sacco di istruzioni in questo file di traccia e potrei o meno essere in grado di sifonare questo e trovare quello che devo trovare. Quindi, ancora una volta, non sono così sicuro che questo sia il modo in cui vorresti lavorare.
Ora, i debugger interattivi - e se hai usato qualcosa come Visual Studio per scrivere programmi o Eclipse, hai avuto dei debugger e li hai usati con le altre lingue - non hai pensato di usarli qui con il tuo database. E ci sono strumenti là fuori, come il nostro DB Artisan e il nostro Rapid SQL, questo è Rapid SQL qui, che ha un debugger, e puoi vedere sul lato sinistro, ho una procedura memorizzata chiamata "controlla i duplicati". Fondamentalmente, sta per andare a vedere se ho più righe nella tabella con lo stesso titolo del film. Quindi, il database è per i film. E puoi vedere sul lato destro, sul terzo superiore, ho il mio codice sorgente nel mezzo, ho ottenuto quelle che sono chiamate le mie variabili watch e i miei vassoi dello stack di chiamate, e poi in fondo ho alcuni output s. E ciò che è importante qui è, se guardi sopra quella prima freccia rossa, se passo il mouse su una variabile, in realtà posso vedere quale valore ha quella variabile in quel momento, mentre passo il codice. E questo è davvero utile, e quindi posso passare una riga alla volta attraverso il codice, non devo dire esegui, potrei dire passare una riga, fammi vedere cosa è successo, passare un'altra riga, fammi vedere cosa è successo, e Lo sto facendo nel database. E anche se sono seduto su Rapid SQL sul mio PC e il mio database è nel cloud, posso ancora fare quel debug remoto e vederlo e controllarlo da qui, e fare il debug come farei con qualsiasi altra lingua.
Ora, la freccia successiva lì - puoi vedere la piccola freccia che punta a destra, verso quell'uscita DBMS, ecco dove si trova il mio cursore in quel momento - quindi in altre parole, Ive ha fatto un passo e questo è dove sono al momento. Quindi, se dico "Passo di nuovo", vado alla riga successiva. Ora appena sotto quello vedrai il punto rosso. Bene, questo è un punto di interruzione, che dice "Ehi, non voglio scavalcare queste linee". Se voglio solo saltare su tutto e arrivare a quel punto rosso, posso premere il pulsante Esegui e correrà da qui a alla fine, o ad un punto di interruzione, se sono stati impostati punti di interruzione, quindi si fermerà e mi consentirà di fare nuovamente il passo. E la ragione per cui tutto ciò è importante e potente è, perché quando sto facendo tutto questo, quello che sta succedendo nel mezzo e anche nel fondo - ma soprattutto nel mezzo - cambierà e posso vedere i valori dalle mie variabili, posso vedi la mia traccia dello stack di chiamate, sai, e quindi tutte quelle informazioni vengono visualizzate lì mentre passo attraverso il codice, quindi posso davvero vedere e sentire e capire cosa sta succedendo e come funziona effettivamente il codice al momento dell'esecuzione . E in genere riesco a trovare un problema, se ce n'è uno, o se sono abbastanza bravo da prenderlo.
OK, ora parlerò di un profiler, e in questo caso, questo è un profiler che posso vedere attraverso un debugger. Ricordi che a volte ho detto che sono separati e a volte possono stare insieme? In questo caso, e ancora, sono in Rapid SQL, e vedo che c'è un margine, sul lato sinistro, accanto ai numeri di riga. E quello che è, è il numero di secondi o microsecondi impiegato per eseguire ogni riga di codice, e posso vedere chiaramente che tutto il mio tempo è trascorso in questo ciclo FOR dove sto selezionando tutto da una tabella. E così, i w accadendo che accadono all'interno di quel ciclo FOR probabilmente è qualcosa che devo guardare, e se posso renderlo migliore, pagherà i dividendi. Non otterrò alcun miglioramento lavorando su quelle linee che hanno come 0,90 o 0,86; non c'è molto tempo trascorso lì. Ora, in questo caso, e ancora, sono in Rapid SQL, stai vedendo come posso fare il profiling mescolato con il mio debug. Ora, ciò che è bello è Rapid SQL che ti permette anche di farlo nell'altro modo. Rapid SQL ti consente di dire: "Sai cosa? Non voglio essere nel debugger, voglio solo eseguire questo e poi voglio guardare graficamente o visivamente lo stesso tipo di informazioni. "
E puoi vedere che non sono più nel debugger e che esegue il programma e dopo che l'esecuzione è stata eseguita, mi dà dei grafici per dirmi le cose così posso vedere che ho un'istruzione che sembra occupare la maggior parte della torta grafico e se guardo, vedo su quella griglia verso il basso, linea 23, c'è di nuovo il ciclo FOR: sta occupando la maggior parte del tempo, è in realtà quel rosso scuro che mastica tutto il grafico a torta. E così, questo è un altro modo di fare profiling. Ci capita di chiamare questo "analista di codice" nel nostro strumento. Ma in pratica è solo un profiler separato da un debugger. Ad alcune persone piace farlo nel primo modo, ad altre piace farlo nel secondo modo.
Perché eseguiamo il debug e la profilazione? Non è perché vogliamo scrivere il codice più grande del mondo e ottenere un aumento di stipendio - questa potrebbe essere la nostra ragione, ma non è proprio la ragione per cui lo fai - hai promesso all'azienda che avresti fatto qualcosa di corretto, che il tuo programma sarebbe stato efficace. Questo è ciò per cui userete il debugger. Inoltre, utenti finali aziendali; non sono molto pazienti: vogliono risultati anche prima di premere il tasto. Dovevano leggere la loro mente e fare tutto istantaneamente. In altre parole, deve essere efficiente. E così, questo è ciò per cui utilizzeremmo il profiler. Ora, senza questi strumenti, credo davvero che tu sia questo ragazzo in giacca e cravatta con l'arco e la freccia e stai sparando al bersaglio e sei bendato. Perché come scoprirai come viene eseguito un programma guardando solo il codice statico e come stai andando a capire quale linea è dove passerebbe davvero più tempo in esecuzione, di nuovo, semplicemente guardando il codice statico? Una revisione del codice può rivelare o meno alcune di queste cose, ma non esiste alcuna garanzia che una revisione del codice le trovi tutte. Usando un debugger e un profiler dovresti essere in grado di trovare tutti quei bug.
OK, sto per fare una demo veloce qui. Non è mia intenzione spingere il prodotto, voglio solo mostrarti come appare un debugger perché molte volte la gente dirà: "Non ne ho mai visto uno prima." E sembra carino nelle diapositive delle schermate dello schermo, ma cosa sembra quando è in movimento? Quindi, qui sul mio schermo sto eseguendo il nostro prodotto DB Artisan; abbiamo anche un debugger. DB Artisan è pensato soprattutto per i DBA, Rapid SQL è più per gli sviluppatori, ma ho visto sviluppatori che usano DB Artisan e Ive ha visto DBA che usano Rapid. Quindi, non lasciarti coinvolgere dal prodotto. E qui, ho la scelta di fare un debug, ma prima di lanciare il debug, ho intenzione di estrarre questo codice in modo da poter vedere come appare il codice prima di iniziare a eseguirlo. Quindi, ecco lo stesso identico codice presente nell'istantanea dello schermo, questo è il mio controllo per i duplicati. E voglio eseguire il debug di questo, quindi premo debug. E ora, ci vuole un momento e tu dici: "Beh, perché ci vuole un momento?" Ricorda il debug remoto: il debug si sta effettivamente verificando sul mio server di database, non sul mio PC. Quindi, ha dovuto andare oltre e creare una sessione laggiù, creare una cosa di debug remoto, collegare la mia sessione a quella sessione di debug remoto e impostare un canale di comunicazione.
Quindi, ora, ecco la mia freccia, è lassù in alto, per linea uno, ecco dove sono nel codice. E se premo la terza icona lì, che è un passo in avanti, vedrai quella freccia appena mossa, e se continuo a premerla, la vedrai continuare a muoversi. Ora, se volevo andare fino in fondo a questo ciclo FOR, perché so dove si trova il problema, posso impostare un breakpoint. Pensavo di averlo impostato. Oh spara, ho avuto uno dei miei tasti di cattura dello schermo mappati sullo stesso tasto del debugger, questo è ciò che causa la confusione. OK, quindi ho appena impostato manualmente un punto di interruzione lì, quindi ora invece di fare un passo, un passo, un passo, un passo fino a quando non ci arrivo, in realtà posso solo dire: "Vai avanti e esegui questa cosa", e si fermerà. Notate che mi ha spostato fino al punto in cui si trova il punto di interruzione, quindi ora sono nel truffatore dell'esecuzione di questo ciclo, posso vedere su cosa sono impostate tutte le mie variabili, il che non è una sorpresa, perché le ho inizializzate tutte su zero. E ora, posso entrare in questo ciclo e iniziare a guardare cosa sta succedendo all'interno di questo ciclo.
Quindi, ora farà un conteggio selezionato dai miei noleggi e posso passare il mouse su quel ragazzo e guardare, è due, due è maggiore di uno, quindi probabilmente farà il prossimo pezzo di questo codice. In altre parole, ha trovato qualcosa. Ho intenzione di andare avanti e lasciar correre. Non voglio passare attraverso tutto qui; quello che voglio mostrarti è quando un debugger è finito, finisce proprio come un normale programma. Ho impostato il punto di interruzione, quindi quando ho detto di correre, è tornato al punto di interruzione successivo. Lo sto lasciando correre fino alla fine, perché quello che voglio che tu veda è che un debugger non cambia il comportamento del programma: una volta eseguito, dovrei ottenere gli stessi esatti risultati se non lo avessi eseguito all'interno di un debugger.
E con ciò, ho intenzione di sospendere la demo e tornare indietro perché vogliamo assicurarci di avere tempo per domande e risposte. E così, lo aprirò per domande e risposte.
Eric Kavanagh: Va bene, Robin, forse una tua domanda e poi una coppia di Dez?
Robin Bloor: Sì, certo, lo trovo affascinante, ovviamente. Ho lavorato con cose come questa, ma non ho mai lavorato con nulla di simile nel database. Puoi darmi un'idea di ciò per cui le persone usano il profiler? Perché è come, stanno guardando - perché presumo che lo siano - stanno esaminando i problemi di prestazioni, ti aiuterà a distinguere tra quando un database richiede tempo e quando un codice richiede tempo?
Bert Scalzo: Sai, questa è una domanda fantastica. Diciamo che sto lavorando in Visual Basic e io, all'interno del mio Visual Basic, chiamerò un Transact-SQL o un PL / SQL. Lasciami fare il PL / SQL, dato che Oracle non gioca sempre bene con gli strumenti Microsoft. Potrei creare il profilo del mio codice Visual Basic, e il profilo lì potrebbe dire: "Ehi, ho chiamato questa procedura memorizzata e ci è voluto troppo tempo". Ma poi posso andare nella procedura memorizzata e posso fare un profilo di database sul memorizzato procedura e dire: "OK, tra le 100 affermazioni che si trovano qui, ecco le cinque che stavano causando il problema." E quindi, potrebbe essere necessario creare un team di tag, in cui è necessario utilizzare più profiler.
L'idea è che se ti viene mai detto che il problema di prestazioni è nel tuo database, un profilo del database può aiutarti a trovare l'ago nel pagliaio su cui le dichiarazioni sono effettivamente quelle in cui hai un problema. Ti dico un'altra cosa che è emersa con la profilazione: se hai un pezzo di codice che viene chiamato un milione di volte, ma ci vuole solo un microsecondo ogni milione di volte, ma viene chiamato un milione di volte, cosa mostrerebbe il profiler , quella cosa è andata avanti per così tante unità di tempo. E così, sebbene il codice possa essere altamente efficiente, potresti guardare e dire: "Ooh, facevano troppo spesso questa chiamata a questo pezzo di codice. Forse dovremmo chiamarlo solo ogni tanto, piuttosto che ogni volta che elaboriamo un disco ”o qualcosa del genere. E così puoi effettivamente trovare dove c'è un codice efficiente che viene chiamato troppo spesso e che in realtà è un problema di prestazioni.
Robin Bloor: Sì, è meraviglioso. Non l'ho mai fatto. Vedete, ovviamente, quando ho avuto problemi con il database era come se in un modo o nell'altro avessi a che fare con il database o con il codice; Non potrei mai occuparmi di entrambi allo stesso tempo. Ma, di nuovo, non ho fatto nulla: non sono mai stato effettivamente coinvolto nella creazione di applicazioni in cui erano state memorizzate procedure, quindi immagino di non aver mai incontrato problemi che mi facevano impazzire, l'idea che avresti diviso il codice tra un database e un programma. Ma così, fa tutto: presumo che le risposte saranno sì, ma questo fa parte dell'attività del team di sviluppo, quando in un modo o nell'altro stai cercando di riparare qualcosa che è rotto, o forse stai cercando di mettere insieme una nuova applicazione. Ma tutto ciò si adatta a tutti gli altri componenti che mi aspetterei nell'ambiente? Posso aspettarmi di poter agganciare questo insieme a tutti i miei pacchetti di test e tutte le altre cose che vorrei fare e con le mie cose di gestione del progetto, è così che tutte queste clip insieme?
Bert Scalzo: Sì, può diventare parte di qualsiasi processo strutturato per fare i tuoi sforzi di programmazione o sviluppo. Ed è divertente, la scorsa settimana ho avuto un cliente che stava costruendo un'applicazione Web, e il loro database era stato piccolo, storicamente, e quindi il fatto che fossero programmatori molto bravi non li ha mai feriti. Bene, il loro database è cresciuto nel corso degli anni, e ora ci vogliono 20 secondi in una pagina web, tra quando dici "Accedi e dammi alcuni dati per vedere" e quando lo schermo si apre, e così ora è un problema di prestazioni. E sapevano che il problema non era in nessuna delle loro Java o in nessuno di quegli altri posti. Ma avevano migliaia di procedure memorizzate e quindi hanno dovuto iniziare a profilare le procedure memorizzate per scoprire perché questa pagina Web impiega 20 secondi a venire? E in realtà abbiamo scoperto che avevano un join cartesiano in una delle loro dichiarazioni selezionate e non lo sapevano.
Robin Bloor: Wow.
Bert Scalzo: Ma qualcuno una volta mi ha detto: "Beh, come hanno potuto unirsi a Cartesian e non saperlo?" E questo suona davvero orribile; a volte un programmatore che non è molto a suo agio con SQL farà qualcosa come darmi un join cartesiano, ma poi restituirmi solo il primo record, quindi so di aver ottenuto qualcosa e ho solo bisogno del primo. E così, non si rendono conto di aver appena riportato un miliardo di dischi o di guardare attraverso un miliardo di dischi, perché hanno ottenuto quello a cui erano interessati.
Robin Bloor: Wow, lo so, come si chiama ... beh, ecco cosa stava succedendo Dez, in termini di persone non esattamente abili come forse dovrebbero essere, lo sai. Se sei un programmatore, dovresti sapere quali sono le implicazioni dell'emissione di qualsiasi comando. Voglio dire, davvero, non ci sono scuse per quel livello di stupidità. Immagino anche che tu, in un modo o nell'altro, sia solo un linguaggio agnostico al riguardo, perché tutto si concentra sul lato del database. Ho ragione in questo? È lo stesso, qualunque cosa tu stia usando dal lato della codifica?
Bert Scalzo: Assolutamente, puoi farlo in Fortran o C o C ++. In effetti, su alcuni Unix puoi persino farlo per i loro linguaggi di scripting; in realtà forniscono gli stessi strumenti. E poi voglio tornare indietro di un secondo per quello che hai detto senza scuse. Darò una pausa ai programmatori, perché non mi piace buttare i programmatori sotto il bus. Ma il problema è proprio l'ambiente accademico perché quando vai a imparare a fare il programmatore, ti viene insegnato il pensiero record per volta. Non ti viene insegnato il pensiero del set, ed è quello che Structured Query Language o SQL funziona con i set; ecco perché abbiamo l'unione, l'intersezione e l'operatore meno. Ed è molto difficile a volte per una persona che non ha mai pensato in termini di set, smettere, lasciarsi andare all'elaborazione record alla volta e lavorare con i set.
Robin Bloor: Sì, sono con te su questo. Voglio dire, capisco ora, questo è un problema di educazione; Penso che sia completamente una questione educativa, penso che sia naturale per i programmatori pensare in modo procedurale. E SQL non è procedurale, è dichiarativo. In realtà stai solo dicendo: "Questo è quello che voglio e non mi interessa come lo fai", sai? Considerando che con i linguaggi di programmazione ti capita spesso di rimboccarti le maniche e di cadere nelle minuzie della gestione uniforme dei conteggi, mentre fai un ciclo. Mano malata a—
Bert Scalzo: No. OK, continua.
Sì, stavo per dire che hai citato un altro esempio che un profiler sarebbe bravo a cogliere il tipo di cose che vanno avanti con questa elaborazione record alla volta. A volte, un programmatore che è bravo in una logica record per volta, non riesce a capire come eseguire il programma SQL. Bene, diciamo che fa due cicli FOR e fondamentalmente fa un join, ma lo fa sul lato client. Quindi, sta facendo lo stesso effetto di un join, ma lo sta facendo lui stesso, e un profilo lo catturerebbe, perché probabilmente finiresti per passare più tempo a fare il join manualmente piuttosto che lasciare che il server del database lo faccia per te.
Robin Bloor: Sì, sarebbe un disastro. Voglio dire, ti staresti solo agitando. Thrashings sempre male.
Comunque, passerò a Dez; Sono sicuro che abbia alcune domande interessanti.
Dez Blanchfield: Grazie sì. Ho intenzione di unirti a te nei programmatori che non gettano sotto il bus. Voglio dire, ho passato troppi anni nella mia vita a essere un programmatore me stesso, ad ogni livello, sai, sia come hai detto, seduto sulla riga di comando della macchina Unix, e in alcuni casi, sono stato anche coinvolto in un coppia di porte diverse di Unix da una piattaforma hardware all'altra. E puoi immaginare le sfide che abbiamo avuto lì. Ma la realtà è quella che esce dalla prigione per ogni programmatore e programmatore del mondo. È una scienza missilistica, letteralmente, scrivere molto attentamente ogni volta, sempre, è una scienza missilistica. E storie famose di persone come Dennis Ritchie e Brian Kernahan che lavorano su un pezzo di codice in modo indipendente e poi passano a una chat di revisione del codice davanti a un caffè e scoprono di aver scritto esattamente lo stesso pezzo di codice, esattamente nello stesso programma, esattamente allo stesso modo. E lo hanno fatto in C. Ma quel livello purista di programmazione esiste molto raramente.
Il fatto è che su base giornaliera, ci sono solo 24 ore al giorno, sette giorni alla settimana, e dobbiamo solo fare le cose. E così, quando si tratta non solo di programmatori tradizionali, DBA e programmatori, scripter, amministratori di sistema, amministratori di rete, personale di sicurezza e tutto ciò che arriva fino al lato dati dei cittadini in questi giorni; sentiamo, tutti cercano solo di fare il loro lavoro. E quindi penso che la cosa più interessante di tutto questo sia che ho adorato la tua demo e ho adorato la cosa che ci hai lasciato lì, solo un momento fa, parlando con Robin del fatto che questo ha un particolare - forse non così tanto una nicchia, ma un ampio spazio a cui si applica, per quanto riguarda la correzione di codice, SQL e database. Ma sono stato davvero entusiasta di sentirti dire che potresti ficcarlo in uno script di shell e trovare alcuni problemi, perché sai, ai giorni nostri oggi lavoravamo sempre al minor costo su tutto.
Il motivo per cui puoi comprare una maglietta da $ 6 da qualche parte, è perché qualcuno ha costruito un sistema abbastanza economico da produrre e spedire e consegnare e vendere logisticamente e al dettaglio e prendere pagamenti online per ottenere quella maglietta da $ 6. E questo non succederebbe se le persone venissero pagate $ 400.000 all'anno per scrivere il codice nel modo perfetto; è solo l'intero sviluppo. Quindi, quel punto, immagino che una delle domande ti amo davvero per darci solo qualche informazione in più, qual è l'ampiezza e la portata del tipo di persone che stai vedendo attualmente che stanno implementando questo tipo di strumenti per profilare un codice e guardare per problemi di prestazioni? Inizialmente, storicamente, da dove vengono? Sono state le grandi case di ingegneria? E poi, in futuro, ho ragione nel pensare che sempre più aziende stanno implementando questo strumento, o questi strumenti, per cercare di aiutare i programmatori, che sanno che stanno solo facendo le cose per finire il lavoro e tirarlo fuori dalla porta? E a volte abbiamo bisogno di una carta per uscire di prigione? Ho ragione nel pensare che storicamente abbiamo avuto un focus più ingegneristico e di sviluppo? Che ora, stavano diventando meno, come diceva Robin, l'approccio accademico, e ora il suo codice autodidatta, o taglia e incolla, o semplicemente costruiva le cose? E questo corrisponde al tipo di persone che stanno assumendo il prodotto ora?
Bert Scalzo: Si Esattamente. E ti darò un esempio molto specifico, vogliamo solo fare il lavoro, perché gli uomini d'affari non vogliono la perfezione. È un po 'come una partita a scacchi computerizzata: la partita a scacchi non cerca la risposta perfetta; cerca una risposta che sia abbastanza buona in un ragionevole lasso di tempo, quindi è così che programmiamo. Ma quello che sto scoprendo ora è che la maggior parte delle persone invece di dire che vogliono un profiler come parte del loro test unitario - ed è così che lo farei, perché non lo vedo come una perdita di tempo - quello che sta succedendo è ora che è stato fatto successivamente, a volte, durante i test di integrazione o stress test, se fossero fortunati. Ma la maggior parte delle volte fa parte di un'escalation, in cui qualcosa è andato in produzione, ha funzionato per un po ', forse ha funzionato anche per anni, e ora non funziona bene, e ora ben profilato. E quello sembra essere lo scenario più comune ora.
Dez Blanchfield: Sì, e penso che il termine "debito tecnico" sia probabilmente uno di quelli con cui hai più familiarità; Conosco Robin e certamente lo siamo. Penso che oggigiorno, in particolare con approcci agili allo sviluppo e alla costruzione di sistemi, per me il concetto di debito tecnico ora sia una cosa molto reale, e in realtà lo spieghiamo nei progetti. So, intendo, che abbiamo i nostri progetti come Media Lens e altri, in cui abbiamo programmato la programmazione su base giornaliera e varie cose in tutto il Bloor Group. E ogni volta che stavamo costruendo qualcosa, guardiamo, la guardo e guardiamo sempre dal punto di vista di ciò che mi costerà aggiustare questo adesso, contro posso semplicemente metterlo nella lattina e portalo fuori, e poi guarda e vedi se queste cose si romperanno. E ereditare questo debito tecnico che so che dovrò tornare indietro e risolvere.
E intendo, l'ho fatto negli ultimi sette giorni: ho scritto un paio di strumenti e script, ho scritto un paio di pezzi di linguaggio Python e l'ho distribuito nel back-end Mongo, assicurandomi che fosse bello, pulito e sicuro, ma ottiene solo la domanda di cui ho bisogno, sapendo che ho bisogno di quella funzione per funzionare, per arrivare al puzzle più grande; ecco dove è il mio vero dolore. E quindi incorri in questo debito tecnico, e penso che questo non sia solo una cosa occasionale, penso che questo faccia parte del DNA dello sviluppo adesso. Le persone semplicemente - non disingenuamente - accettano semplicemente che il debito tecnico sia un normale tipo di problema modus operandi e devono solo affrontarlo. È lì che incorri nel debito tecnico. E penso che la cosa grandiosa di ciò che ci hai mostrato nella demo è che puoi letteralmente profilare e guardare quanto tempo impiega a correre qualcosa. E questa è probabilmente una delle mie cose preferite. Voglio dire, ho effettivamente creato strumenti di profilazione - abbiamo usato strumenti in Sed e Lex e Orc per eseguire il nostro codice e vedere dove erano i loop, prima che fossero disponibili strumenti come questo - e quando hai creato codice per andare a rivedere il tuo codice , sei molto bravo a non dover rivedere il tuo codice. Ma non è così adesso. Con questo in mente, esiste un particolare segmento di mercato che lo prende più di ogni altro? Vedendo come una massa—
Bert Scalzo: Oh sì, ho ... Ho intenzione di disegnare un'analogia per te, e mostrarti che i non programmatori lo fanno sempre. Perché se insegno mai a un debugger e profiling a lezione o sessione, Ill chiederò alla gente: "OK, quante persone qui entrano in Microsoft Word e non usano mai intenzionalmente il controllo ortografico?" E nessuno alza la mano, perché per scrivere documenti, sappiamo tutti che possiamo commettere errori in inglese, quindi tutti usano il correttore ortografico. E ho detto: “Bene, come mai quando scrivi nel tuo IDE come Visual Basic, non stai usando il debugger? È la stessa cosa, è come un correttore ortografico. "
Dez Blanchfield: Sì, in realtà, questa è una grande analogia. Non ci avevo davvero pensato, devo ammettere che in realtà faccio qualcosa di simile con un paio di strumenti che uso. In effetti, uno, ODF, il mio preferito con Eclipse è semplicemente tagliare e incollare il codice lì dentro e andare alla ricerca di cose che evidenziano immediatamente e realizzando che ho fatto un refuso in una chiamata di classe. E, ma è interessante ora con lo strumento come questo puoi farlo in tempo reale invece di tornare indietro e guardarlo più tardi, il che è un po 'bello prenderlo in anticipo. Ma sì, questa è una grande analogia del solo mettere in un elaboratore di testi, perché è una sveglia interessante che, ti rendi conto che hai fatto degli errori di battitura o addirittura un errore grammaticale, giusto?
Bert Scalzo: Esattamente.
Dez Blanchfield: Quindi, stai vedendo più di un miglioramento ora, suppongo, intendo, l'ultima domanda da parte mia, prima di lanciare forse alle nostre domande e risposte, per i nostri partecipanti. Se avessi intenzione di dare una sorta di raccomandazione sull'approccio per fare questo - Immagino che sia retorico - è il caso che arrivi presto e lo realizzi mentre stai sviluppando, prima di svilupparlo? O è il caso in cui prevalentemente costruisci, ti muovi, costruisci qualcosa e poi entra e profila in un secondo momento? Ho il sospetto che sia il caso di arrivare presto e assicurarsi che i tuoi codici siano puliti in anticipo. O è un caso che dovrebbero prendere in considerazione questa parte del loro post-schieramento?
Bert Scalzo: Idealmente, lo farebbero in anticipo, ma poiché tutti sono nel mondo frenetico in cui hanno appena finito di fare cose, tendono a non farlo fino a quando non si imbattono in un problema di prestazioni che non possono risolvere aggiungendo più CPU e memoria a una macchina virtuale.
Dez Blanchfield: Si. Quindi, in realtà hai menzionato qualcosa di interessante, se posso velocemente? Prima hai detto che questo può essere eseguito da qualsiasi luogo e può parlare al database sul back-end. Quindi questo è a suo agio con il tipo di concetto bimodale di cui parliamo ora, di nuvola on-premise / off-premise, anche dall'aspetto delle cose, alla fine della giornata, se può parlare con il back-end e vedere il codice, non gliene importa davvero, vero?
Bert Scalzo: Esatto, sì, puoi eseguirlo nel cloud.
Dez Blanchfield: Eccellente, perché penso che sia il posto in cui sta andando il nostro nuovo mondo coraggioso. Quindi Eric. Ora ti rispondo e vedo che abbiamo qualche domanda qui e voglio che i nostri partecipanti rimangano ancora con noi, anche se siamo passati oltre l'ora.
Eric Kavanagh: Sì, ci sono alcune persone là fuori, Ill solo fare un breve commento: Bert, penso che la metafora, l'analogia che dai all'utilizzo del controllo ortografico sia francamente geniale. Questo è degno di uno o due blog, francamente, perché è un buon modo per inquadrare la truffa di quello che stai facendo, di quanto sia prezioso e di come dovrebbe essere una buona pratica usare un debugger su un base regolare, giusto? Scommetto che ottieni delle teste che annuiscono quando le butti fuori, giusto?
Bert Scalzo: Assolutamente, perché ciò che dico loro è: “Perché eseguo un controllo ortografico sui miei documenti? Non voglio essere imbarazzato da stupidi errori di ortografia. ”Beh, non vogliono essere imbarazzati da stupidi errori di codifica!
Eric Kavanagh: Giusto. Si Certamente. Bene, gente, abbiamo bruciato un'ora e cinque minuti qui, grazie mille a tutti voi per il vostro tempo e la vostra attenzione. Archiviamo tutte queste chat Web, non esitate a tornare in qualsiasi momento e verificarle. Il posto migliore per trovare quei collegamenti è probabilmente techopedia.com, quindi aggiungilo a questo elenco qui.
E con quello, ti avrei detto addio, gente. Ancora una volta, ottimo lavoro, Bert, grazie ai nostri amici di IDERA. Beh, ci sentiamo la prossima volta, ci sentiamo, la prossima settimana, in effetti. Stai attento! Ciao ciao.