Di Techopedia Staff, 15 marzo 2017
Takeaway: L' host Eric Kavanagh ha discusso del debug e della profilazione del database con il Dr. Robin Bloor, Dez Blanchfield e Bert Scalzo di IDERA.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Eric Kavanagh: Okay, 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é stiamo parlando 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, parleremo di "Risposta rapida: debug del database e creazione di profili per il salvataggio".
C'è davvero un punto nel tuo, fammi sapere su Twitter, ovviamente @eric_kavanagh.
Quest'anno è caldo. E il debug sarà caldo, non importa quale. Sarà davvero uno di questi problemi che non sparirà 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, succederà, la domanda è: quale sarà la tua soluzione per affrontarla e risolvere quei problemi?
Sentiremo 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 solo una discussione di base in modo da poter avere un quadro completo di ciò che sta succedendo. L'ho fatto per molto tempo, ed ero un programmatore, quindi è come, ed ero quasi tentato da questa presentazione di iniziare a diffondere lirica sull'idea dell'open source, ma ho pensato che lo avrei lasciato a qualcun altro.
Ecco un elenco di bug famosi, e la maggior parte di questi entra nella lista dei migliori di chiunque, in sostanza, 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 fece il giro di tutti - 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 Mappe di Apple è 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 è rimasto fuori per circa nove ore ed è costato circa 60 milioni di dollari 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, comunque, è quello. Ho pensato di parlare della mancata corrispondenza dell'impedenza e dell'SQL emesso. È interessante notare che i database relazionali archiviano i dati in tabelle e i programmatori tendono a manipolare i dati in strutture di oggetti che in realtà non si associano molto bene alle tabelle. E per questo motivo, ottieni ciò 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 del programmatore 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, dal punto di vista dei programmatori, quando si ottengono gerarchie possono essere tipi, può insiemi di risultati, può essere scarsa capacità API, può essere un sacco di cose che buttano fuori le cose in termini di interazione con il database. Ma la cosa più interessante 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 prendeva cura di tutto l'improvviso che stai inserendo funzionalità in un database, il che significava ovviamente che la funzionalità di un'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 nelle procedure memorizzate che vengono gestite separatamente dal codice che si trova nelle applicazioni. E sembra che debba essere una cosa molto strana, dovrebbe essere abbastanza intelligente nel fare varie cose.
Ho pensato di parlare 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 potresti avere problemi di prestazioni a causa del blocco . L'idea sarebbe che il programmatore non aveva davvero bisogno di preoccuparsi delle prestazioni e che il database avrebbe effettivamente funzionato abbastanza bene. Dovrebbe essere progettato in modo tale che il programmatore non debba 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 mai sperimentato è, è la prima cosa che tu abbia mai visto è 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 vedendo 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 sia venuta fuori. Non so come passarti la palla, Dez.
Eric Kavanagh: Lo passerò, aspetto, resisti.
Voce automatica: le linee dei partecipanti sono silenziate.
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 alcuni folk 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 è che intorno al 9 settembre 1945 un team dell'Università di Harvard stava facendo a pezzi una macchina, si sono imbattuti in qualcosa che chiamavano "relè settanta" - a quei tempi la programmazione era fatta in senso fisico, hai ferito il codice attorno a una scheda, ed è così che hai programmato efficacemente la macchina - e hanno scoperto che questo relè numero settanta c'era qualcosa di sbagliato in esso, e si scopre che il vero termine "bug" è nato perché era letteralmente una falena - presumibilmente lì era una falena incastrata tra un pezzo di filo di rame che andava 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 "debug" è emerso 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 nello specifico non è stato profilato solo trovare cose come loop infiniti che non vanno da nessuna parte.
Ma abbiamo anche uno scenario, e ho pensato di inserire un paio di diapositive divertenti prima di entrare nei dettagli. Ecco il classico cartone animato, chiamato XKCD sul web, e il fumettista ha delle visioni piuttosto divertenti sul mondo. E questo riguarda un bambino chiamato "Tavolini Bobby" e presumibilmente i suoi genitori hanno chiamato questo giovane ragazzo Robert '); DROP TABLE Studenti; - e si chiama, e in un certo senso "Ciao, questa è la scuola di tuo figlio 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 i registri degli studenti dell'anno, 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 i dati anche.
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 vengo da un ambiente di 14 anni che vaga per la fine della città e bussa alla porta di un data center chiamato "Data Com" in New La Zelanda e chiedendo se potevo guadagnare soldi in tasca a scuola, riportando a casa l'autobus in ritardo, circa 25 km di pendolarismo ogni giorno, inserendo carta nelle stampanti e nastri nelle 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 una stampante fisica 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 debug del codice su questo era un problema non banale, quindi tendevi a scrivere tutto il tuo codice a mano, e poi ti comporti come un dattilografo, facendo del tuo meglio per non sbagliare, perché è estremamente frustrante doverlo dire l'editor di una riga per andare su una determinata riga e quindi stampare la riga e quindi reinserirla. Ma una volta era così che 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 è finito - e tutti ne siamo 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 hai fatto sul nastro di carta una specie di formato stampato 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 no introdurre il codice buggy.
Metodi di programmazione in questi giorni, 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, perché quando pensiamo a 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ì per animali che ho ad esempio con persone SQL che saltano su Google e cercano qualcosa e trovano un sito web che è 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 altre sfide, ad esempio, in questi giorni ci stiamo precipitando verso questo, ciò che chiamiamo la corsa a zero: cercare di fare tutto ciò che è così economico e così veloce, che abbiamo uno scenario in cui non stiamo impiegando personale retribuito. E non intendo questo in modo disonesto, ma non stiamo assumendo 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, c'è molta gente che si occupa di sviluppo, progettazione e database che non hanno avuto anni di esperienza, 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 tu devo ripulirlo. ”E 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 con cui ti trovi più a tuo agio come PHP e Ruby o Python, e usare il linguaggio di programmazione che hai familiarità nativa, da 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.
Ora, questo è un esempio davvero estremo, ma ottieni il punto da tutto ciò. Quindi, per dare 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 sono sicuro che conosciamo tutti. E sulla sinistra c'è un pezzo di SQL che in realtà lo rende. 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 una metodologia di programmazione applicata a un linguaggio e quindi è molto facile per cattive pratiche di programmazione, mancanza di esperienza, codice taglia e incolla, personale a bassa retribuzione che cerca di essere personale ben retribuito, gente che finge di saperlo, ma deve 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 giusto, è un po 'carino e pensi: "Wow, che bella grafica, mi piacerebbe eseguirlo." Ma immagina che 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 un testo verde per essere 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 dispone degli strumenti corretti, se non si dispone delle piattaforme e degli ambienti corretti per essere in grado di catturare queste cose e queste entrano in produzione, quindi si hanno 100.000 persone colpire 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, è davvero un bel codice, ma prendiamo un DBA che ti aiuti a costruire correttamente quella query strutturata, perché francamente, è semplicemente brutto". E l'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 di testo.
Quindi, per riassumere, con questo in mente, il mio intero background nella 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, vado a consegnare al nostro ospite e non vedo l'ora di sapere come hanno risolto questo problema. E in particolare la demo penso che stiamo per ricevere. Eric, passo di nuovo.
Eric Kavanagh: OK, Bert, portalo via.
Bert Scalzo: OK, grazie. Bert Scalzo qui di 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 è vero che il debug è oneroso e non banale, e quando si passa al debug del database è 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 diranno "Bene, quelle cose debugger sono nuove, e non abbiamo ancora iniziato a usarle." E quindi quello che faccio è mostrare loro questo grafico temporale, una specie di preistoria, la vecchiaia, il medioevo, è gentile di dire dove eravamo in termini di 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é è una di quelle cose nuove", allora devi aver iniziato a programmare, sai, negli anni '50, perché è il l'unico modo per cavartela 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 è abbastanza divertente. E poi l'altra cosa di cui ho riso è che parlava 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. "Quindi, e ho programmato in tutte le lingue qui, incluso SNOBOL, di cui nessuno ha 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 sto dicendo, mi sento come nonno Simpson. Quindi guardo al debug e ci sono diversi modi per eseguire 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 di stampa: guardi e le persone inseriscono effettivamente le dichiarazioni di stampa e in realtà ho visto uno strumento in cui - ed è uno strumento di database - dove se non sai come usare un debugger, si preme un pulsante e si attaccheranno le istruzioni di stampa in tutto il codice per te e poi quando hai finito premi un altro pulsante e li 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 questo potrebbe essere un errore logico, ma quello che è, è che ho fatto la cosa giusta, semplicemente non torna abbastanza velocemente. Ora, sottolineo questo punto perché un profiler è probabilmente migliore 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, punti di controllo, passaggio e passaggio e alcune altre cose comuni, che mostrerò quelle su un'istantanea dello schermo tra 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 più è meglio se ha fatto il campionamento. Non c'è motivo di catturare 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é corrono 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 di database, di cui abbiamo parlato in precedenza, hai SQL - e abbiamo in qualche modo forzato il piolo circolare nel foro quadrato qui e lo abbiamo costretto a diventare un linguaggio di programmazione - e Oracle. Questo è PL / SQL - che è il linguaggio procedurale SQL - e SQL Server, è Transact-SQL, è SQL-99, è SQL / PSM - per, credo, è il modulo memorizzato nella procedura. 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, le 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 eseguire il debug in un database?" E la risposta è, beh, qualunque cosa tu possa archiviare nel database come codice - se lo sto facendo T-SQL o PL / SQL - e sto memorizzando oggetti nel database, è probabilmente una procedura memorizzata o una funzione memorizzata. Ma ci sono anche 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 da mantenere tutto il loro codice e le procedure memorizzate, ma è lo stesso concetto: è ancora il trigger 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 è che, se stai cercando di farlo a mano, in realtà digiterai più codice di debug per inserire tutte queste istruzioni di stampa rispetto a quelle 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, posso smettere. Ma con questo, devo aspettare che venga eseguito, fino al completamento, quindi devo guardare qualche file di traccia che probabilmente contiene tutte queste istruzioni di stampa 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 un mucchio di istruzioni di stampa 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, andrà 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 in alto, ho il mio codice sorgente nel mezzo, ho quelle che sono chiamate le mie variabili watch e i miei vassoi dello stack di chiamate, e poi in fondo io ' ho ricevuto alcuni messaggi di output. 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 nel tempo, mentre passo attraverso 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'output DBMS, ecco dove si trova il mio cursore al momento - quindi in altre parole, ho fatto un passo ed è lì che mi trovo il momento. Quindi, se dico "Passo di nuovo", vado alla riga successiva. Ora appena sotto 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 funzionerà da qui alla fine o fino a un punto di interruzione, se sono stati impostati punti di interruzione, quindi si fermerà e mi consentirà di fare di nuovo il passo. E la ragione per cui tutto ciò è importante e potente è, perché quando sto facendo tutto ciò, ciò che sta accadendo nel mezzo e persino nel fondo - ma soprattutto nel mezzo - cambierà e vedrò i valori dalle mie variabili, Posso vedere la mia traccia dello stack di chiamate, sai, e quindi tutte quelle informazioni vengono visualizzate lì mentre passo attraverso il codice, quindi in realtà posso vedere e sentire e capire cosa sta succedendo e come è effettivamente il codice lavorando in fase di esecuzione. E in genere riesco a trovare un problema, se ce n'è uno, o se sono abbastanza bravo da risolverlo.
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 è, è che è il numero di secondi o microsecondi necessari 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 quindi, qualunque cosa accada 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 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 prendere la maggior parte del grafico a torta 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 è fondamentalmente 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 utilizzerai il debugger. Inoltre, utenti finali aziendali; non sono molto pazienti: vogliono risultati anche prima di premere il tasto. Dovremmo leggere la loro mente e fare tutto istantaneamente. In altre parole, deve essere efficiente. E quindi, 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ò mostrare o meno alcune di queste cose, ma non c'è 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, ho intenzione di 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, ma che aspetto ha quando è in movimento? Quindi, qui sul mio schermo sto eseguendo il nostro prodotto DB Artisan; abbiamo anche un debugger. DB Artisan è pensato più per i DBA, Rapid SQL è più per gli sviluppatori, ma ho visto sviluppatori che usano DB Artisan e ho visto DBA che usano Rapid. Quindi, non lasciarti sorprendere 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 riga uno, ecco dove sono nel codice. E se premo la terza icona lì, che è un passo in avanti, vedrai quella freccia appena spostata e se continuo a premerla, la vedrai continuare a muoversi. Ora, se volessi andare fino in fondo a questo ciclo FOR, perché so che è qui il problema, posso impostare un punto di interruzione. 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 sta causando 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 contesto 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 a zero. E ora, posso entrare in questo loop e iniziare a guardare cosa sta succedendo all'interno di questo loop.
Quindi, ora farà un conteggio selezionato dai miei affitti e posso passare il mouse su quel ragazzo e guardare, lui è 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 lascio correre fino alla fine, perché quello che voglio che tu veda è che un debugger non cambia il comportamento del programma: quando ha finito l'esecuzione, dovrei ottenere gli stessi esatti risultati se non lo avessi eseguito all'interno di un debugger.
E con questo, 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 domanda da parte tua e poi una coppia da Dez?
Robin Bloor: Sì, certo, lo trovo affascinante, ovviamente. Ho lavorato con cose del genere, 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, è 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, poiché 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 causavano 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ì mentre il codice può essere altamente efficiente, potresti guardare e dire: “Ooh, stiamo facendo questa chiamata a questo pezzo di codice troppo spesso. 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 lì, ancora una volta, non ho fatto … Non sono mai stato coinvolto nella creazione di applicazioni in cui erano state memorizzate procedure, quindi credo di non aver mai incontrato problemi che mi facevano impazzire, l'idea che tu avrebbe diviso il codice tra un database e un programma. Ma così, fai tutto: presumo che la risposta sarà sì, ma 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 portare un nuovo applicazione insieme. 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 settimana scorsa ho avuto un cliente che stava costruendo un'applicazione Web, e il loro database era stato piccolo, storicamente, e quindi il fatto che non fossero dei bravi programmatori 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 quindi 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 suonerà davvero orribile; a volte un programmatore che non è molto a suo agio con SQL farà qualcosa come darmi un join cartesiano, ma poi mi restituirà 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, è quello che stava succedendo a 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à. Presumo 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 gettare i programmatori sotto il bus. Ma il problema è davvero l'ambiente accademico perché quando vai a imparare come essere un programmatore, ti viene insegnato il pensiero record alla 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, abbandonare, lasciarsi andare all'elaborazione record alla volta e lavorare con i set.
Robin Bloor: Sì, ci sono io. Voglio dire, capisco ora, questo è un problema educativo; Penso che sia completamente un problema educativo, 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 sei nella minuta persino di gestire i conteggi, mentre fai un ciclo. Passerò 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. Thrashing è sempre male.
Comunque, passerò a Dez; Sono sicuro che ha alcune domande interessanti.
Dez Blanchfield: Grazie, sì, lo faccio. Ti raggiungerò 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 paio di porte diverse di Unix da una piattaforma hardware all'altra. E puoi immaginare le sfide che abbiamo avuto lì. Ma la realtà è che ecco quella carta per uscire di 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 stanno solo cercando 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 nostri giorni lavoriamo 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 accade se hai persone pagate $ 400.000 all'anno per scrivere il codice in modo perfetto; è solo l'intero sviluppo. Quindi, quel punto, immagino che una delle domande che vorrei davvero che tu ci dessi 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 cercare 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 stiamo ottenendo un approccio accademico inferiore, come diceva Robin, e ora è un codice autodidatta, taglia e incolla, o semplicemente costruiamo le cose? E questo corrisponde al tipo di persone che stanno assumendo il prodotto ora?
Bert Scalzo: Sì, 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 trovando 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 - ciò che sta accadendo è ora che viene fatto in seguito, a volte, durante i test di integrazione o stress test, se siamo 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 lo profileremo. E quello sembra essere lo scenario più comune ora.
Dez Blanchfield: Sì, e penso che il termine "debito tecnico" sia probabilmente uno 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. Lo so, voglio dire, abbiamo i nostri progetti come Media Lens e altri, in cui la programmazione avviene quotidianamente e varie cose in tutto il Bloor Group. E ogni volta che stiamo costruendo qualcosa, guardiamo, la guardo e guardiamo sempre dal punto di vista di ciò che mi costerà aggiustare questo adesso, invece di farlo semplicemente nel possibile e portarlo là fuori, e poi guardare e vedere se questa cosa si romperà. E ereditare questo debito tecnico che so che dovrò tornare indietro più tardi 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, realizzando sicuramente è 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. È qui 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, in realtà ho 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 il codice per andare e rivedere il proprio codice, si diventa molto bravi a non dover rivedere il proprio codice. Ma non è così ora. 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 … Vado a disegnare un'analogia per te, e ti mostrerò che i non programmatori lo fanno sempre. Perché se insegno a un debugger e ad una lezione o sessione di profilazione, 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, e quindi tutti usano il correttore ortografico. E ho detto: “Bene, come mai quando scrivi un testo nel tuo IDE come Visual Basic, non stai usando il debugger? È la stessa cosa, è come un correttore ortografico. "
Dez Blanchfield: Sì, in realtà, è un'ottima 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ì, è una grande analogia nel mettere il testo in un elaboratore di testi, perché è un interessante campanello d'allarme che, ti rendi conto che hai fatto degli errori di battitura o addirittura un errore grammaticale, giusto?
Bert Scalzo: Esatto.
Dez Blanchfield: Quindi, stai vedendo più di un miglioramento ora, immagino, intendo, l'ultima domanda da parte mia, prima di passare alle nostre domande e risposte, forse, per i nostri partecipanti. Se avessi intenzione di dare una sorta di raccomandazione sull'approccio per fare questo - suppongo che sia retorico - è il caso che arrivi presto e lo realizzi mentre stai sviluppando, prima di svilupparlo? O è il caso in cui stai principalmente costruendo, muovendoti, costruendo qualcosa, poi entra e profilalo in un secondo momento? Ho il sospetto che sia il caso di arrivare presto e assicurarsi che il codice sia pulito 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 trambusto del mondo in cui hanno appena finito di fare cose, tendono a non farlo fino a quando non incontrano un problema di prestazioni che non possono risolvere aggiungendo più CPU e memoria a una macchina virtuale.
Dez Blanchfield: Sì. 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 gli interessa davvero, vero?
Bert Scalzo: Esatto, sì, puoi eseguirlo nel cloud.
Dez Blanchfield: Eccellente, perché penso che sia in un certo senso dove sta andando il nostro nuovo mondo coraggioso. Quindi Eric. Ora ti rispondo e vedo che abbiamo alcune domande qui e voglio che i nostri partecipanti rimangano ancora con noi, anche se siamo passati un'ora.
Eric Kavanagh: Sì, ci sono alcune persone là fuori, farò solo 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 il contesto di ciò che stai facendo, di quanto sia prezioso e di come dovrebbe essere una buona pratica usare un debugger su base regolare, giusto? Scommetto che ottieni delle teste che annuiscono quando le butti fuori, giusto?
Bert Scalzo: Assolutamente, perché quello che dico è: “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 lo aggiungeremo a questo elenco proprio qui.
E con questo, ti saluteremo, gente. Ancora una volta, ottimo lavoro, Bert, grazie ai nostri amici di IDERA. Ci sentiamo la prossima volta, ci sentiamo la prossima settimana, in effetti. Stai attento! Ciao ciao.
