Răspuns rapid: depanare a bazelor de date și profilare la salvare

La pachet: Gazda Eric Kavanagh a discutat despre depanarea și profilarea bazelor de date cu Dr. Robin Bloor, Dez Blanchfield și IDERAs Bert Scalzo.

În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.

Eric Kavanagh: Bine, doamnelor și domnilor, este ora 4:00 la est într-o zi de miercuri și, desigur, asta înseamnă.

Robin Bloor: Nu te aud, Eric.

Eric Kavanagh: Am fost acolo zile în urmă, deci nu ești singur. Dar așa subiectul de astăzi este chestii cu adevărat interesante. Este genul de lucru pe care doriți să îl asigurați că se întâmplă în fundal la compania dvs., dacă nu sunteți persoana care o face, caz în care doriți să vă asigurați că o faceți corect. Pentru că vorbeau despre depanare. Nimănui nu-i plac bug-urile, nimănui nu-i place când software-ul nu mai funcționează - oamenii se supără, utilizatorii devin neprieteni. Asta nu e bine. Deci, aveam de gând să vorbim despre „Răspuns rapid: depanare a bazelor de date și profilare la salvare”.

Există un spot despre al tău cu adevărat, lovește-mă pe, @eric_kavanagh, desigur.

Anul acesta este cald. Iar depanarea va fi fierbinte, indiferent de situație. Va fi într-adevăr una dintre aceste probleme care nu va dispărea niciodată, oricât de bine vom ajunge la aceste lucruri, acestea vor fi întotdeauna probleme, așa că cheia este cum ajungeți unde puteți rezolva rapid aceste probleme? În mod ideal, aveți programatori grozavi, medii grozave, în care nu prea mult nu merge bine, dar așa cum spune vechea afirmație, „Accidentele se întâmplă în cele mai bune familii”. Și același lucru este valabil și pentru organizații. Deci, se întâmplă aceste lucruri, se va întâmpla, întrebarea care va fi soluția dvs. pentru rezolvarea problemelor și rezolvarea acestor probleme?

Ei bine, auziți de dr. Robin Bloor, apoi de propriul nostru Dez Blanchfield de jos și, desigur, de bunul nostru prieten, Bert Scalzo, de la IDERA. Și, de fapt, o să-i predau cheile lui Robin Bloor, să o iau. Etajul este al tău.

Robin Bloor: O.K. Acesta este un subiect interesant. M-am gândit pentru că, probabil, Dez va continua despre tehnicile reale și poveștile de război despre depanare, m-am gândit că doar voi face o discuție de fond, astfel încât să avem o imagine complet rotundă a ceea ce se întâmplă. Am făcut acest lucru mult timp și am fost un coder, așa că este similar, și am fost aproape tentat de această prezentare să încep să fiu liric despre ideea de open source, dar am crezut că voi lăsa asta cuiva altcineva.

Iată o listă de bug-uri celebre, iar cele mai multe dintre acestea intră pe lista de top a oricărui client, practic, toate, cu excepția ultimelor două costă cel puțin 100 de milioane de dolari. Primul a fost Mars Climate Orbiter, s-a pierdut în spațiu și a fost din cauza unei probleme de codare, unde oamenii confundau unitățile metrice cu (râde) picioare și inci. Ariane Five Flight 501 a existat o nepotrivire între un motor care a fost pus și computerele care trebuiau să funcționeze rachetă atunci când a fost lansată. Mai multe eșecuri ale computerului, rachetă care explodează, știri din titlu. Conducta de gaze sovietice din 1982, a spus a fi cea mai mare explozie din istoria planetei; Nu sunt sigur dacă este. Rușii au furat niște software de control automat, iar CIA și-a dat seama că urma să facă asta și să pună bug-uri, iar sovieticii l-au pus în aplicare fără testare. Așa că, a explodat o conductă, a crezut că a fost amuzant.

Viermele Morris a fost un experiment de codificare, care a devenit dintr-o dată un vierme răpitor care a dat peste tot - aparent a provocat pagube în valoare de 100 de milioane de dolari; asta este o estimare desigur. Intel a făcut o eroare faimoasă cu un cip matematic - o instrucțiune de matematică pe cipul Pentium în 1993 - care trebuia să coste peste 100 de milioane de dolari. Programul Hărți cu Mere este, probabil, cea mai gravă și dezastruoasă lansare de orice a făcut Apple vreodată. Oamenii care au încercat să o folosească au fost, vreau să spun, cineva a condus de-a lungul 101 și a descoperit că Apple Map a spus că se află în mijlocul golfului San Francisco. Astfel, oamenii au început să se refere la aplicația Apple Maps ca iLost. Cea mai lungă întrerupere a noastră din 1990 - este tocmai interesantă din punct de vedere al costurilor cu ceva de genul - AT&T au rămas aproximativ nouă ore și a costat aproximativ 60 de milioane de dolari la apelurile la distanță.

Și am fost la o companie de asigurări din U.K., iar baza de date, au implementat o nouă versiune a bazei de date și a început să șteargă datele. Și îmi amintesc asta extrem de bine, deoarece am fost chemat ulterior să iau parte la un fel de selecție de baze de date din cauza asta. Și a fost foarte interesant faptul că au luat o nouă versiune a bazei de date și au avut o baterie de teste pe care au făcut-o pentru versiuni noi ale bazei de date, care a trecut toate testele. S-a găsit un mod foarte obscur de ștergere a datelor.

Deci, oricum, asta este. M-am gândit că vorbesc despre nepotrivirea impedanței și SQL emis. Interesant este că bazele de date relaționale stochează date în tabele și codificatorii tind să manipuleze datele în structuri de obiecte care nu se potrivesc foarte bine cu tabelele. Și din această cauză, obțineți ceea ce se numește nepotrivirea impedanței și cineva trebuie să se descurce într-un fel sau altul. Dar ceea ce se întâmplă de fapt, deoarece un model, modelul codificatorilor și baza de date un alt model, nu sunt aliniate în mod special. Veți primi erori care s-ar întâmpla doar dacă industria ar fi construit lucruri care funcționează împreună, ceea ce cred că este hilar. Deci, practic, pe partea de codificare, atunci când obțineți ierarhii, poate fi tipuri, poate rezulta seturi, poate fi o capacitate API slabă, poate fi o mulțime de lucruri care aruncă lucrurile în termeni de interacțiune cu baza de date. Dar lucrul care este cel mai mult pentru mine, este foarte interesant; întotdeauna m-a uimit că aveți această barieră SQL care este, de asemenea, un fel de impedanță într-un mod în care codificatorii și baza de date funcționează între ei. Deci, SQL are recunoaștere a datelor, care este bine și are DML pentru selectare, proiectare și alăturare, ceea ce este bine. Puteți arunca o mulțime de capacități în ceea ce privește extragerea de date din baza de date cu asta. Dar are foarte puțin limbaj matematic pentru a face lucruri. Are un pic din asta și asta și are foarte puține lucruri bazate pe timp. Și din această cauză, SQL este un mijloc imperfect, dacă doriți, de a obține datele. Deci, tipii de baze de date au construit proceduri stocate pentru a trăi în baza de date, iar motivul pentru procedurile stocate acolo a fost că nu vreți să aruncați date înainte și înapoi către un program.

Pentru o parte din funcționalitate era extrem de specifică datelor, așa că nu era doar integritate referențială și ștergeri în cascadă și lucruri de genul acesta, baza de date avea grijă de toate punerea bruscă a funcționalității într-o bază de date, ceea ce însemna desigur că funcționalitatea pentru un aplicația ar putea fi divizată între codificator și baza de date în sine. Și asta a făcut treaba de a implementa anumite tipuri de funcții într-adevăr destul de dificile și, prin urmare, mai predispuse la erori. Deci, asta este o parte a jocului bazei de date, pentru că înseamnă că ai primit o mulțime de implementări, de exemplu, că am fost implicat în baze de date relaționale, într-adevăr, o mulțime grozavă de cod care se află în proceduri stocate care este tratată separat de codul care se află în aplicații. Și pare un lucru foarte ciudat la care ar fi trebuit să fie, ar trebui să fie destul de inteligent în a face diverse lucruri.

M-am gândit că Id vorbesc și despre performanța bazei de date, deoarece erorile de performanță sunt adesea considerate bug-uri, dar practic puteți avea un blocaj la procesor, la memorie, la disc, la rețea și puteți avea probleme de performanță din cauza blocării. Ideea ar fi că codificatorul nu trebuie să fie îngrijorat de performanță și baza de date să funcționeze destul de bine. Se presupune că este conceput astfel încât codificatorul nu trebuie să știe. Totuși, obțineți o proastă concepție a bazelor de date, obțineți un design prost al programului, obțineți concordanță în amestecarea volumului de muncă, ceea ce poate duce și la probleme de performanță. Vei obține echilibrarea sarcinii, obții planificarea capacității, creșterea datelor - ceea ce poate determina oprirea sau încetinirea unei baze de date. Este un lucru interesant, atunci când bazele de date sunt aproape pline, acestea încetinesc. Și puteți avea probleme de straturi de date în ceea ce privește replicarea, nevoia de replicare și nevoia de a face backup și recuperare. În orice caz, este o imagine de ansamblu.

Singurul lucru pe care mi-ar plăcea să-l spun este că depanarea bazelor de date poate fi doar la fel de oneroasă și non-banală - și spun asta pentru că am făcut multe lucruri - și vei descoperi adesea ca toate situațiile de depanare pe care le-am experimentat vreodată. este, este primul lucru pe care îl vezi vreodată că este o mizerie. Și trebuie să încercați să treceți de la încurcătură pentru a afla cum a apărut mizeria. Și de multe ori când te uiți la o problemă a bazei de date, tot ce privești sunt date corupte și te gândești: „Cum naiba s-a întâmplat asta?”

Oricum, voi transmite lui Dez, care probabil va spune mai multe cuvinte de înțelepciune decât am ieșit. Nu știu cum să-ți trec mingea, Dez.

Eric Kavanagh: O să-l trec, stai în picioare, ține-te.

Voce automată: Liniile de participanți au murit.

Eric Kavanagh: În regulă, agățați o secundă, permiteți-mi să dau lui Dez mingea.

Dez Blanchfield: Mulțumesc, Eric. Da, dr. Robin Bloor, sunteți într-adevăr cel mai corect: acesta este un subiect, o problemă de viață pe tot parcursul vieții, dacă veți ierta acuzația, îmi pare rău că nu m-aș putea ajuta pe mine. Sper să puteți vedea primul meu ecran acolo, scuzele mele pentru problema dimensiunii fontului în partea de sus. Subiectul bug-urilor este o prelegere de o zi, în multe cazuri din experiența mea. Este un subiect atât de larg și de larg, așa că voi pune accentul pe două domenii cheie, în special conceptul a ceea ce considerăm ca fiind un bug, dar o problemă de programare. Cred că în zilele noastre introducerea unui bug în sine este în general preluată de mediile de dezvoltare integrate, deși pot fi erori de lungă durată. Dar de multe ori este mai mult un caz de profilare a codului și posibilitatea de a scrie cod care funcționează, acesta ar trebui să fie un bug. Așa că, diapozitivul meu aici, am avut o copie a acestui text în rezoluție foarte înaltă A3, dar, din păcate, a fost distrus într-o mutare a casei. Dar aceasta este o notă scrisă de mână pe o foaie de programare din 1945, unde se presupune că unii oameni de la Universitatea Harvard din SUA, a doua lor construcție a unei mașini numite Mark II. Deprimau o problemă, în limbaj comun, dar încercau să găsească o defecțiune și se dovedește că a apărut ceva ușor diferit de ceea ce era un hardware și o problemă presupus software.

Așadar, mitul urban este cel din 9 septembrie^leaÎn 1945, o echipă de la Universitatea Harvard trăgea o mașină, au dat peste ceva ce au numit „ștafetă șaptezeci” - în acele zile, programarea se făcea în sens fizic, încercați codul în jurul unui tablou și așa ați programat eficient mașină - și au găsit acest ștafet numărul șaptezeci, era ceva în neregulă și se dovedește că termenul real „bug” a apărut, deoarece literalmente era o molie - se presupune că exista o molie înfășurată între o bucată de sârmă de cupru care se ducea. dintr-un loc în altul. Și povestea spune că legendarul Grace Hopper ca acest titlu, pentru diapozitivul meu, „primul caz real al unui bug care a fost găsit” citează unquote.

Dar cum a subliniat Robin mai devreme în prima sa diapozitivă, conceptul de eroare se întoarce atât de departe, încât ne putem imagina oamenii făcând calcul, concepte precum un plasture. Termenul de „plasture” provenea de la o bucată de bandă reală care a fost tapetată pe un orificiu de pe o carte de pumn. Însă, întregul aspect este că termenul „depanare” a ieșit din acest concept de a găsi o eroare într-o mașină fizică.Și de atunci, am folosit acea terminologie în jurul încercării de a aborda probleme, nu atât ca probleme de codare într-un program care nu compilează, ci ca un program care nu funcționează bine. Și în mod special nu a fost profilat, găsiți lucruri precum bucle care nu se încheie niciodată, care nu merg nicăieri.

Dar avem și un scenariu și m-am gândit că am introdus câteva diapozitive amuzante înainte de a intra într-un pic mai detaliat. Iată desenatul clasic, numit XKCD pe web, iar caricaturistul are niște vizionări destul de amuzante despre lume. Și asta despre un copil numit „Little Bobby Tables” și, probabil, părinții lui l-au numit pe acest tânăr Robert); TABLA DE DROP Studenți; - și așa se numește, și un fel de „Bună, aceasta este școala de fii ai tăi cu probleme la computer”, iar părintele răspunde: „O, dragă, a rupt ceva?” Și profesorul spune: „Ei bine, într-un fel, și profesorul îl întreabă, „l-ai numit cu adevărat pe fiul tău Robert); TABLA DE DROP Studenți; -? ”Și părintele spune:„ O, da, micuțe tabele Bobby pe care le numim. ”Oricum, ei continuă să spună că au pierdut acum înregistrările studenților, sper că sunteți fericiți. Iar răspunsul este: „Ei bine, ar trebui să curățați și să vă igienizați intrările bazei de date.” Și eu îl folosesc de multe ori pentru a vorbi despre unele dintre problemele pe care le avem în găsirea lucrurilor în cod, că de multe ori codul nu privește și datele .

Un alt amuzant, nu știu dacă acest lucru este real sau nu - bănuiesc că este o spoof - dar, din nou, îmi atinge și oasele amuzante. Cineva care schimbă plăcuța de înmatriculare din partea din față a mașinii lor, într-o declarație similară care face ca bazele de date să scadă în camerele de viteză și așa mai departe, care să capteze plăcuțele de înmatriculare ale mașinilor. Și mă refer mereu la aceasta, întrucât mă îndoiesc că orice programator a anticipat o lovitură și o derulare a codului lor de către un autovehicul real, dar niciodată nu o subestimăm - puterea unui furios furios.

(Râsete)

Dar asta mă duce la punctul meu cheie, cred, și asta este că, odată odată, puteam depana și coda de profil ca niște muritori. Dar consider foarte mult că timpul a trecut, și anecdotic în experiența mea, prima mea - și asta mă îmbătrânește teribil, sunt sigur; Robin ești binevenit să mă distrezi pentru asta - dar istoric am venit dintr-un fundal la vârsta de 14 ani rătăcind în capătul orașului și bătând la ușa unui centru de date numit „Data Com” din Noua Zeelandă și întrebând dacă Aș putea câștiga bani de buzunar la școală, ajungând cu autobuzul târziu acasă, cu aproximativ 25 de km de navetă în fiecare zi, prin introducerea hârtiei în casă, și casete în unități de bandă și doar fiind un administrator general. Și destul de curios mi-au dat o slujbă. Însă, în timp, am reușit să mă implic în personal și să găsesc programatorii și mi-am dat seama că îmi place mult codarea și am trecut prin procesul de a rula scripturi și joburi de lot, care la sfârșitul zilei este încă cod. Trebuie să scrieți scripturi și joburi de lot, care arată ca mini-programe și apoi parcurgeți întregul proces de ședere pe un terminal de scriere 3270 de mână.

De fapt, prima mea experiență a fost pe un terminal de tip teletip, care era de fapt o eroare fizică de 132 coloane. În esență, gândiți-vă la o mașină de scris foarte veche cu hârtie care a defilat prin ea, pentru că nu au un tub CRT. Și depanarea codului la asta a fost o problemă foarte netrebnică, așa că ați avut tendința să vă scrieți tot codul de mână și apoi să acționați ca un dactilograf, făcând tot posibilul să nu obțineți erori pentru a se strecura, deoarece este extrem de frustrant să trebuie să spuneți. redactorul de linie pentru a merge la o anumită linie, apoi a liniei și apoi a tasta-o din nou. Dar odată a fost, așa am scris codul și așa am fost depanat și ne-am descurcat foarte bine. Și, de fapt, ne-a obligat să avem tehnici de programare foarte bune, pentru că a fost o adevărată dificultate de a o repara. Dar călătoria a trecut apoi - și toți erau familiarizați cu acest lucru - a plecat de la experiența terminalului 3270 din lumea mea, la Digital Equipment VT220 unde puteți vedea lucrurile pe ecran, dar, din nou, făceați același lucru pe care l-ați făcut pe bandă de hârtie un fel de format ed doar pe un CRT, dar ai reușit să ștergi mai ușor și nu aveai acel sunet „dit dit dit”.

Și atunci știți, terminalele Wyse - cum ar fi Wyse 150, probabil interfața mea preferată pentru un computer vreodată - și apoi PC-ul și apoi Mac-ul, iar în aceste zile GUI-uri și ID-uri moderne care sunt bazate pe web. Și o serie de programe prin aceasta, programarea într-un singur ansamblu și PILOT și Logo și Lisp și Fortran și Pascal și limbaje care ar putea face oamenii să crească. Dar acestea sunt limbi care v-au obligat să scrieți un cod bun; nu te-au lăsat să te îndepărtezi de practicile proaste. C, C ++, Java, Ruby, Python - și ajungem mai departe în acea etapă de programare, obținem mai multe scripturi, ne apropiem tot mai mult de limbajul de interogare structurat și de limbaje precum PHP care sunt de fapt folosite pentru invocarea SQL. Ideea de a vă spune că, provenind din fondul meu, am fost autodidact în multe feluri, iar cei care m-au ajutat să învăț, mi-au învățat practici de programare foarte bune și practici foarte bune în jurul proiectării și proceselor pentru a mă asigura că nu am introdus buggy cod.

Metodele de programare în aceste zile, cum ar fi, de exemplu, Structured Query Language, SQL, este un limbaj de interogare foarte puternic și simplu. Dar am transformat-o într-un limbaj de programare și nu cred cu adevărat că SQL a fost vreodată conceput pentru a fi un limbaj de programare modern, dar l-am prefăcut pentru a deveni asta. Și asta introduce o mulțime de probleme, cauzate când ne gândim din două puncte de vedere: din punct de vedere al codării și din punctul de vedere al DBA. Este foarte ușor să vină și să introducă bug-uri pentru lucruri precum tehnici de programare slabe, eforturi leneșe la scrierea codului, lipsa de experiență, clasicul clasic de animale de companie pe care îl am, de exemplu, cu oamenii SQL sărind pe Google și să caute ceva și să găsească un site web. am primit un exemplu și făcând o copie și lipire a codului existent. Și apoi replicarea unei codări proaste, a malpraxisului și punerea ei în producție, pentru că se întâmplă doar să le dea rezultatele pe care le doresc. Aveți alte provocări, de exemplu, zilele acestea s-au grăbit toate acestea, ceea ce numim cursa la zero: încercând să facem totul atât de ieftin și atât de rapid, încât avem un scenariu în care nu angajăm personal cu salarii mai mici. Și nu vreau să spun asta într-un mod neplăcut, dar nu angajam experți pentru fiecare loc de muncă posibil. Din când în când, orice lucru legat de calculatoare era știința rachetelor; s-a implicat în lucruri care mergeau tare și erau foarte puternice sau mergeau în spațiu sau inginerii erau bărbați și femei puternic calificate, care făcuseră studii și aveau educații riguroase, care îi împiedicau să facă lucruri nebunești.

În aceste zile, există o mulțime de oameni care se dezvoltă și proiectează și baza de date care nu au avut ani de experiență, nu au avut neapărat aceeași pregătire sau sprijin. Și, astfel, încheieți cu un scenariu al amatorului tradițional versus expert. Și există o linie celebră, nu pot să-mi amintesc de fapt cine a creat citatul, rândul merge: „Dacă credeți că costisitorul său angajează un expert pentru a face o muncă, așteptați până când angajați câțiva amatori care creează o problemă și trebuie să curățați-l. ”Și SQL are această problemă și este foarte ușor de învățat, foarte ușor de utilizat. În opinia mea, nu este un limbaj de programare perfect. Este foarte ușor să faci lucruri precum faceți o stea selectă de oriunde și trageți toate acestea într-un limbaj de programare cu care sunteți mai confortabil cu PHP, Ruby sau Python și utilizați limbajul de programare cu care sunteți familiarizat, pentru a face manipularea datelor, în loc să efectueze o interogare mai complexă în SQL. Și vedem asta mult, apoi oamenii se întreabă de ce baza de date rulează lent; pentru că un milion de oameni încearcă să cumpere un bilet formează un sistem de ticketing online, unde face o stea selectă de oriunde.

Acum, acesta este un exemplu extrem de extrem, dar veți obține punctul de vedere din toate acestea. Așadar, pentru a înțelege cu adevărat acel punct acasă, este un exemplu pe care îl port în jurul multor. Sunt un mare fan al matematicii, iubesc teoria haosului, îmi plac seturile Mandelbrot. În partea dreaptă există o redare a setului Mandelbrot, cu care sunt sigur că toate erau familiare. Și pe partea stângă există o bucată de SQL care redă de fapt asta. Acum, de fiecare dată când așez acest lucru pe un ecran undeva, aud acest lucru: „Dumnezeule, cineva a redat seria Mandelbrot cu SQL, sunteți serios? Asta e nebun! ”Ei bine, tot ce înseamnă asta este să ilustrez ceea ce tocmai am subliniat acolo și asta este da, de fapt acum puteți programa aproape orice în SQL; este un limbaj de programare foarte puternic dezvoltat, puternic, modern. Când inițial era un limbaj de interogare, a fost conceput pentru a obține doar date. Deci, acum am obținut construcții foarte complexe și am obținut proceduri stocate, am aplicat metodologia de programare la un limbaj și, prin urmare, este foarte ușor pentru practici proaste de programare, lipsă de experiență, cod tăiat și lipit, personal cu salarii reduse care încearcă să să fie personal cu salarii mari, oameni care se prefac că știu, dar trebuie să învețe la locul de muncă.

O serie întreagă de lucruri în care profilarea codurilor și ceea ce ne referim la depanare, care nu este atât găsirea de erori care opresc programele să funcționeze, ci bug-uri care afectează doar sistemul și codul slab structurat. Când te uiți la acest ecran acum și te gândești, doar așa, este genul de drăguț și te gândești: „Uau, ce grafică minunată, îmi place să rulez asta”. Dar imaginați-vă că rulează pe o bucată de logică de afaceri. Arată destul de îngrijit, dar vorbește despre o teorie a haosului matematic redat grafic, dar când te gândești la ce ar putea fi folosit în anumite logici de afaceri, obții foarte repede imaginea. Și pentru a ilustra cu adevărat asta - și îmi pare rău că culorile sunt inversate, se presupune că este un fundal negru și verde pentru a fi un ecran verde, dar puteți citi în continuare acest lucru.

M-am dus și am aruncat o privire rapidă la un exemplu despre ceea ce puteți face dacă puteți fi într-adevăr nebun și nu aveți experiență și provin dintr-un fundal diferit de programare și am aplicat aprecierile C ++ la SQL, pentru a ilustra cu adevărat punctul meu, înainte Predau invitatul nostru învățat de la IDERA. Aceasta este o interogare structurată scrisă ca C ++, dar codată în SQL. Și de fapt se execută, dar se execută pe o perioadă de aproximativ trei-cinci minute. Și scoate în mod evident o linie de date din mai multe baze de date, mai multe uniri.

Din nou, întregul lucru este că dacă nu aveți instrumentele corecte, dacă nu aveți platforme și medii corecte pentru a putea prinde aceste lucruri, acestea ajung în producție, iar atunci aveți 100.000 de oameni care lovesc un sistem la fiecare zi, oră sau minut, foarte curând ajungeți cu o experiență din Cernobîl în care fierul mare începe să se topească și să se îngroape în miezul planetei, pentru că acea bucată de cod nu ar trebui să intre niciodată în producție. Sistemele și instrumentele tale, scuză-mă, ar trebui să ridice asta înainte de a merge oriunde în apropierea ... chiar și prin procesul de testare, chiar și prin integrarea UAT și a sistemelor, codul respectiv trebuie ridicat și evidențiat și cineva ar trebui adus deoparte și spunând: „Uite, acesta este codul foarte drăguț, dar permite să obținem un DBA care să te ajute să creezi acea interogare structurată în mod corespunzător, deoarece sincer, asta este doar urât.” Și adresele URL de acolo, poți merge și arunca o privire - este denumit cea mai complexă interogare SQL pe care ai scris-o vreodată. Pentru că credeți-mă, că de fapt compilează, rulează. Și dacă tăiați și lipiți asta și pur și simplu mocați baza de date, este destul de urmărit ceva; dacă aveți instrumente pentru a urmări baza de date, încercați doar să vă topiți pe o perioadă de trei până la cinci minute, pentru a reveni la ce este o linie.

Așadar, pentru a rezuma, ținând cont de asta, întregul meu fundal în codificare m-a învățat că puteți oferi oamenilor o armă și dacă nu sunt atenți se vor împușca în picior; trucul este să le arătați unde se află mecanismul de siguranță. Cu instrumentele potrivite și software-ul potrivit la îndemână, după ce ați terminat codificarea, puteți să vă revizuiți codul, puteți găsi probleme prin profilarea codului, puteți găsi erori efective neintenționate care sunt probleme de performanță și, așa cum am spus mai devreme , odată, puteți face acest lucru privind un ecran verde. Nu mai poți; există sute de mii de linii de cod, există zeci de mii de aplicații implementate, există milioane de baze de date în unele cazuri și chiar super oameni nu mai pot face acest lucru de mână. Aveți nevoie literalmente de software-ul potrivit și de instrumentele potrivite la îndemână și aveți nevoie ca echipa să folosească aceste instrumente, astfel încât să puteți găsi aceste probleme și să le abordați foarte rapid, înainte de a ajunge la acest punct, în timp ce Dr. A subliniat Robin Bloor, lucrurile devin dezastruoase și lucrurile izbucnesc sau, mai frecvent, încep doar să te coste mulți dolari și mult timp și efort și distrug moralul și lucrurile, atunci când nu pot rezolva de ce lucrurile iau mult timp pentru a alerga.

Și ținând cont de asta, voi înmâna oaspetelui nostru și aștept cu nerăbdare să aflu cum au rezolvat această problemă. Și în special demo-ul, cred că urma să primească. Eric, trec înapoi.

Eric Kavanagh: OK, Bert, ia-o.

Bert Scalzo: Bine, mulțumesc. Bert Scalzo aici de la IDERA, sunt managerul de produse pentru instrumentele noastre de baze de date. Și voi vorbi despre depanare. Cred că unul dintre cele mai importante lucruri pe care le-a spus Robin mai devreme - și este foarte adevărat este faptul că depanarea este oneroasă și non-banală, iar atunci când mergeți la baza de date, dezactivați o ordine de magnitudine și mai gravă și non-banală - deci, că a fost un citat important.

O.K. Am vrut să încep cu istoricul programării, deoarece de multe ori văd oameni care nu se depanează, nu folosesc un depanator, doar programează cu orice limbă folosesc și de multe ori îmi vor spune: „Ei bine, acele lucruri de depanare sunt noi și încă nu le-am început să le folosim. ”Și, așadar, ceea ce fac este să le arăt acest grafic de timp, un fel de pre-istorie, bătrânețe, vârsta mijlocie, felul în care spunem unde ne aflam termenii limbajelor de programare. Și am avut limbi foarte vechi începând din 1951 cu cod de asamblare, și Lisp, FACT și COBOL. Apoi intrăm în grupul următor, Pascals și Cs și apoi grupul următor, C ++ s, și ne uităm unde se află semnul respectiv - semnul de întrebare este aproximativ exact în jurul anului 1978 - poate 1980. Undeva în acel interval am avut depanatoare disponibile pentru noi, și să spunem așa: „Hei, nu folosesc un depanator, pentru că este unul dintre acele lucruri noi”, atunci trebuie să fi început programarea, știi, încă din anii 1950, pentru că asta este singurul mod în care ai obține departe de această afirmație.

Acum, celălalt lucru care este amuzant în acest grafic este Dez a făcut doar un comentariu despre Grace Hopper, de fapt știam Grace, așa că este amuzant. Și atunci celălalt lucru de care am râs este că a vorbit despre teletipuri și stau acolo mergând: „Omule, acesta a fost cel mai mare salt pe care l-am avut vreodată în productivitate, când am trecut de la cărți la teletipuri, acesta a fost cel mai mare salt din toate timpurile”. și am programat în toate limbile de aici, inclusiv SNOBOL, despre care nu a mai auzit nimeni până acum, a fost un CDC, Control Data Corporation, așa că cred că devin un pic prea vechi pentru această industrie.

Dez Blanchfield: Aveam să spun, ne-ai îmbătrânit grozav acolo.

Bert Scalzo: Da, îți spun, mă simt ca bunicul Simpson. Așa că mă uit la depanare și există diferite moduri de a face depanare. Ați putea vorbi despre ceea ce credem cu toții ca fiind tradițional să intrăm într-un depanator și să parcurgem codul. Dar, de asemenea, oamenii își vor instrumenta codul; asta în cazul în care introduceți declarații în codul dvs. și poate produceți un fișier de ieșire, un fișier de urmărire sau ceva, și astfel vă instrumentați codul. Aș număra asta ca o depanare, este puțin mai grea, un mod de a face, dar contează. Dar, de asemenea, am primit faimoasa afirmație: vă uitați și oamenii au pus de fapt declarații și am văzut de fapt un instrument unde - și instrumentul său de bază de date - unde dacă nu știți să folosiți un depanator, apăsați un buton și se va lipi declarații pe tot codul dvs. pentru dvs., iar atunci când ați terminat, apăsați un alt buton și le desface. Pentru că așa se debarcă multă lume.

Iar motivul pentru care debugăm este dublu: în primul rând, trebuie să găsim lucruri care să ne facă ineficient codul. Cu alte cuvinte, de obicei, asta înseamnă o greșeală logică sau am ratat o cerință de afaceri, dar ceea ce este, este că codul nu este eficient; nu face ceea ce ne așteptam să facă. Cealaltă dată mergem și facem depanare, pentru eficiență și asta ar putea fi o greșeală de logică, dar ceea ce este, este că am făcut lucrurile corecte, nu se întoarce destul de repede. Acum, mă refer la acest aspect, deoarece probabil că un profilers este mai bun pentru acel al doilea scenariu și aveau să vorbească atât despre debugger, cât și despre profilatori. În plus, există acest concept de depanare la distanță; acest lucru este important, deoarece de multe ori stai pe computerul personal și folosești un depanator, care lovește o bază de date în care codul este de fapt executat în baza de date, efectiv faci ceea ce se numește depanare la distanță. Poate că nu îți dai seama, dar asta se întâmplă. Și apoi, este foarte comun cu acești depanatori să aibă puncte de pauză, să privească, să pășească și să treacă peste și alte lucruri comune, că le voi arăta pe instantaneu pe cele de pe ecran.

Acum, profilare: puteți face profilare în câteva moduri diferite. Unii oameni vor spune că captura și redarea volumului de muncă acolo unde surprinde totul, ceea ce contează ca profilare. Experiența mea a fost mult mai bună dacă eșantionarea finalizată. Nu există niciun motiv să surprindeți fiecare declarație, deoarece unele afirmații pot fi difuzate atât de repede încât nu vă pasă, ceea ce încercați cu adevărat să vedeți este, bine, care sunt cele care continuă să apară de mai multe ori, deoarece acestea rulează prea mult timp . Așadar, uneori, profilarea poate însemna eșantionare, mai degrabă decât executarea întregii lucruri. Și, în mod obișnuit, veți obține un fel de ieșire pe care o puteți utiliza, acum, care ar putea fi vizuală în interiorul unui mediu de dezvoltare IDE, unde vă poate oferi o histogramă a performanței diferitelor linii de cod, dar ar putea totuși fie că produce un fișier de urmă.

Profilii au apărut pentru prima dată în 1979. Așadar, cei din jur sunt de mult timp. Excelent pentru a găsi consumul de resurse sau probleme de performanță, cu alte cuvinte acel lucru de eficiență. În general, este separată și distinctă de depanator, deși am lucrat cu depanatoare care le fac pe ambele în același timp. Și în timp ce profilatorii cred că sunt mai interesanți dintre cele două instrumente, dacă simt că nu sunt suficient de mulți oameni, atunci cu siguranță nu sunt suficient de mulți oameni, pentru că unul din zece depanatori se va profila, se pare. Și este o rușine, deoarece profilarea poate face cu adevărat o diferență uriașă. Acum, limbajele bazei de date, așa cum am mai vorbit mai devreme, ai primit SQL - și noi am forțat clapeta rotundă în gaura pătrată aici și a forțat-o să devină un limbaj de programare - și Oracle.Thats PL / SQL - acel limbaj procedural SQL - și SQL Server, Transact-SQL, SQL-99, SQL / PSM - pentru, cred, modulul său de stocare a procedurilor. Postgres îi dă un alt nume, DB2 și încă un alt nume, Informix, dar ideea este că toată lumea a forțat construcții de tip 3GL; cu alte cuvinte, pentru bucle, la declarații variabile și toate celelalte chestii străine SQL sunt acum parte din SQL în aceste limbi. Și deci, trebuie să fiți capabil să debutați un PL / SQL sau un Transact-SQL la fel cum ați face un program Visual Basic.

Acum, obiectele bazei de date, acest lucru este important pentru că oamenii vor spune: „Ei, ce lucruri trebuie să debug într-o bază de date?” Și răspunsul este, bine, orice puteți stoca în baza de date sub formă de cod - dacă fac T- SQL, sau PL / SQL - și stochez obiecte în baza de date, este probabil o procedură sau o funcție stocată. Dar acolo se declanșează: un declanșator este ca o procedură stocată, dar se declanșează pe un fel de eveniment. Acum, unii oameni din declanșatorii lor vor pune o linie de cod și vor apela la o procedură stocată, astfel încât să păstreze tot codul și procedurile stocate, dar este același concept: totuși declanșatorul ar putea fi ceea ce inițiază totul. Și apoi, ca Oracle, au ceva numit pachet, care seamănă cu o bibliotecă, dacă vrei. Puneți 50 sau 100 de proceduri stocate într-un singur grup, numit pachet, deci genul de bibliotecă. Așadar, acesta este cel care depășește modul vechi; acesta este de fapt un instrument care va intra în realitate și va lipi toate aceste declarații de depanare în codul dvs. pentru dvs. Deci, oriunde vedeți blocul de depanare, nu înlăturați, debuggerul automat începe și urmă, toate au fost blocate de un instrument. Și liniile din afara acesteia, care este minoritatea codului, bine, asta este metoda de depanare non-manuală.

Iar motivul pentru care aduc acest lucru este că, dacă încercați să faceți acest lucru de mână, de fapt, veți tasta mai multe coduri de depanare pentru a pune în toate aceste declarații decât cu codul. Deci, în timp ce acest lucru poate funcționa și, în timp ce este mai bun decât nimic, acesta este un mod foarte dificil de a depana, mai ales că, dacă este nevoie de 10 ore pentru ca acest lucru să funcționeze și unde are o problemă este în linia a treia? Dacă aș face o sesiune interactivă de depanare, aș fi știut la linia trei - cinci minute până la ea - hei, există o problemă aici, pot renunța. Dar cu asta, trebuie să aștept să fie difuzat, până la finalizare și apoi trebuie să mă uit la vreun fișier de urmărire care are probabil toate aceste declarații în el, și să încerce să găsească acul în hastack. Din nou, aceasta este mai bună decât nimic, dar nu ar fi cel mai bun mod de a lucra. Acum, asta ar arăta acel fișier provenit din diapozitivul anterior; cu alte cuvinte, am rulat programul și tocmai am primit o mulțime de declarații în acest fișier de urmărire și pot să pot sau nu să pot sifona asta și să găsesc ce trebuie să găsesc. Deci, din nou, nu sunt atât de sigur că acesta este modul în care ai vrea să lucrezi.

Acum, depanatoarele interactive - și dacă ați folosit ceva precum Visual Studio pentru a scrie programe sau Eclipse, ați avut debuggers și le-ați folosit cu celelalte limbi - nu ați gândit să le utilizați aici cu baza de date. Și există instrumente acolo, cum ar fi DB Artisan și SQL Rapid nostru, aici este Rapid SQL, care are un depanator și puteți vedea pe partea stângă, am o procedură stocată numită „verificați duplicatele”. Practic, va merge să mă uit și să văd dacă am mai multe rânduri în tabel cu același titlu de film. Deci, baza de date este pentru filme. Și ați putut vedea în partea dreaptă, în partea a treia superioară, am primit codul sursă la mijloc, am primit ceea ce se numesc variabilele de ceas și tăvile de apeluri, iar în partea de jos am primit unele ieșiri. Și ceea ce este important aici este, dacă te uiți peste acea primă săgeată roșie, dacă dau mouse-ul peste o variabilă, pot vedea de fapt ce valoare are acea variabilă în acel moment în timp, în timp ce parcurg codul. Și asta este cu adevărat util și atunci pot să parcurg o linie simultan prin cod, nu trebuie să spun execută, aș putea spune pas cu o linie, să mă uit la ce s-a întâmplat, să trec o altă linie, să văd ce s-a întâmplat și Fac asta în baza de date. Și chiar dacă stau pe Rapid SQL pe computer și baza mea de date este sus în cloud, totuși pot face acea depanare de la distanță și o pot vedea și controla de aici și pot face depanare la fel cum aș face cu orice altă limbă.

Acum, următoarea săgeată de acolo - puteți vedea puțin ca săgeata îndreptată spre dreapta, spre ieșirea DBMS, acolo unde este cursorul meu în acest moment - deci, cu alte cuvinte, am pășit și asta unde sunt în acest moment. Deci, dacă spun: „Pasă din nou”, o să merg la următoarea linie. Acum chiar sub acest lucru veți vedea punctul roșu. Ei bine, acesta este un punct de pauză, care spune „Hei, nu vreau să pășesc peste aceste linii.” Dacă vreau doar să sar peste tot și să ajung acolo unde este punctul roșu, pot apăsa butonul de rulare și va rula de aici, fie spre sfârșitul sau până la un punct de întrerupere, dacă există puncte de întrerupere stabilite, atunci se va opri și mă va lăsa să fac din nou pasul. Iar motivul pentru care este atât de important și puternic este că, atunci când fac toate acestea, ceea ce se întâmplă la mijloc și chiar la partea de jos - dar cel mai important la mijloc - se vor schimba și pot vedea valorile din variabilele mele, pot Vedeți urmărirea stivei mele de apeluri, știți și astfel toate informațiile sunt afișate acolo, în timp ce pășesc codul, așa că de fapt pot să văd și să simt și să înțeleg ceea ce se întâmplă și cum funcționează efectiv codul la momentul executării. . Și, de obicei, pot găsi o problemă, dacă există una sau dacă sunt suficient de bună ca să o prind.

OK, acum voi vorbi despre un profiler, iar în acest caz, acesta este un profil pe care îl pot vedea printr-un depanator. Amintiți-vă că am spus că uneori sunt separate și alteori pot fi împreună? În acest caz, și din nou, sunt în Rapid SQL și pot vedea o marjă, pe partea stângă, lângă numerele de linie. Și ceea ce este, este acela care este numărul de secunde sau microsecunde necesare pentru a executa fiecare linie de cod și pot vedea clar, tot timpul meu este petrecut în această buclă FOR, unde selectez totul dintr-un tabel. Și deci, ceea ce se întâmplă în interiorul acelei bucle FOR este probabil ceea ce trebuie să privesc și, dacă pot îmbunătăți, va plăti dividende. Nu voi obține nicio îmbunătățire lucrând la liniile care au 0,90 sau 0,86; nu există mult timp petrecut acolo. Acum, în acest caz, și din nou, sunt în Rapid SQL, vedeți cum pot face profilarea amestecată cu depanarea mea. Acum, ce este frumos este Rapid SQL vă permite, de asemenea, să o faceți în alt mod. Rapid SQL vă permite să spuneți, „Știți ce? Nu vreau să fiu în debugger, vreau doar să rulez acest lucru și apoi vreau să mă uit grafic sau vizual la același tip de informații. "

Și puteți vedea că nu mai sunt în debugger și rulează programul și după ce execuția este făcută, îmi oferă diagrame care să-mi spună lucrurile, astfel încât să văd că am o declarație care pare că ocupă cea mai mare parte a plăcintei. diagrama și dacă mă uit, văd pe acea grilă spre partea de jos, linia 23, este din nou bucla FOR: ezită să ocupă cel mai mult timp, el este, de fapt, că roșu închis mestecă toată graficul. Și deci, acesta este un alt mod de a face profilări. Întâmplăm acest „Analist de Cod” în instrumentul nostru. Dar practic este doar un profiler separat de un depanator. Unora le place să o facă în primul rând, unora le place să o facă în al doilea mod.

De ce facem depanarea și profilarea? Nu pentru că vrem să scriem cel mai mare cod al lumii și să obținem o majorare a salariilor - acesta ar fi motivul nostru, dar acesta nu este motivul pentru care îl faci - i-ai promis afacerii că vei face ceva corect, că programul tău va fi eficient. Pentru asta veți folosi debuggerul. În plus, utilizatorii finali de afaceri; nu prea au răbdare: vor rezultate chiar înainte de a apăsa tasta. Trebuia să le citească mintea și să facă totul instantaneu. Cu alte cuvinte, trebuie să fie eficient. Și deci, pentru asta am folosi profilerul. Acum, fără aceste instrumente, cred cu adevărat că ești un tip în costumul de afaceri cu arcul și săgeata și te împuști la țintă și ești cu ochii închiși. Deoarece cum veți afla cum se execută un program doar uitându-vă la codul static și cum aveți de gând să vă dați seama ce linie este unde ar petrece cu adevărat cel mai mult timp în execuție, din nou, doar uitându-vă la codul static? O revizuire a codului poate sau nu să apară unele dintre aceste lucruri, dar nu există nicio garanție că o revizuire a codului le va găsi pe toate. Folosind un depanator și un profilator, ar trebui să puteți găsi toate aceste erori.

OK, o să fac o adevărată demo rapidă aici. Nu este intenția mea de a împinge produsul, vreau doar să-ți arăt cum arată un depanator pentru că de multe ori oamenii vor spune: „Nu am mai văzut niciodată unul dintre acestea.” Și arată destul de bine în ecranul de diapozitive. seamănă când este în mișcare? Așadar, aici pe ecranul meu execut produsul DB Artisan; avem și un depanator acolo. DB Artisan este menit mai mult pentru DBA, Rapid SQL este mai mult pentru dezvoltatori, dar am văzut dezvoltatori care folosesc DB Artisan și am văzut DBA-uri care folosesc Rapid. Deci, nu te prinde de produs. Și aici, am ales să fac o depanare, dar înainte de a lansa debugul, voi extrage acest cod, astfel încât să puteți vedea cum arată codul înainte de a începe să-l rulez. Deci, aici este exact același cod care a fost în instantanee ecran, aceasta este verificarea pentru duplicate. Și vreau să debug, așa că apăs debug. Și acum, durează un moment și spuneți: „Ei, de ce durează un moment?” Amintiți-vă de depanare la distanță: depanarea se întâmplă de fapt pe serverul de baze de date, nu pe computerul meu. Deci, a trebuit să treacă și să creeze o sesiune acolo, să creeze un lucru de depanare de la distanță, să-mi conectez sesiunea la acea sesiune de depanare la distanță și să stabilesc un canal de comunicare.

Așadar, acum, uite săgeata mea, este acolo sus în vârf, după linia unu, acolo este unde sunt în cod. Și dacă apăs pe cea de-a treia pictogramă acolo, care este un pas în interior, veți vedea că acea săgeată tocmai s-a mișcat, iar dacă continuu să o apăs, o veți vedea în continuare. Acum, dacă aș fi vrut să merg până la această buclă FOR, deoarece știu că acolo este problema, pot seta un punct de întrerupere. Am crezut că am setat asta. Oh, trage, am avut una dintre tastele de captare a ecranului mapate la aceeași cheie ca depanatorul, asta cauzând confuzia. OK, așa că am setat manual un punct de pauză acolo, așa că acum, în loc să fac un pas, pas, pas, pas până ajung acolo, de fapt, pot spune doar „mergeți mai departe și executați acest lucru” și se va opri. Observați că m-a deplasat până la locul de pauză, așa că acum sunt în con de a rula această buclă, pot vedea la ce sunt setate toate variabilele mele, ceea ce nu este o surpriză, pentru că le-am inițializat pe toate zero. Și acum, pot păși în această buclă și să încep să mă uit la ce se întâmplă în interiorul acestei bucle.

Deci, acum va face un număr select din închirierile mele și pot face mouse peste acel tip și uite, ez, două, două este mai mare decât unul, așa că probabil va face următoarea bucată din acest cod. Cu alte cuvinte, a găsit ceva. O să merg înainte și o să alerg. Nu vreau să parcurg totul aici; ceea ce vreau să vă arăt este atunci când un depanator este terminat, se termină exact ca un program normal. Am primit punctul de întrerupere, așa că atunci când am spus alergare, tocmai a revenit la următorul punct de întrerupere. Îl las să ruleze până la capăt, ceea ce vreau să vezi este că un depanator nu schimbă comportamentul programului: atunci când se execută, ar trebui să obțin aceleași rezultate dacă l-aș fi rulat nu în interiorul unui depanator.

Și cu asta, voi suspenda demo-ul și mă voi întoarce pentru că vrem să ne asigurăm că avem timp pentru întrebări și răspunsuri. Și așa, o voi deschide pentru întrebări și răspunsuri.

Eric Kavanagh: Bine, Robin, poate o întrebare de la tine și apoi un cuplu de la Dez?

Robin Bloor: Da, sigur, mi se pare acest lucru fascinant, desigur. Am lucrat cu chestii de genul acesta, dar nu am lucrat niciodată cu așa ceva în baza de date. Puteți să-mi dați o idee despre ce folosesc oamenii profilerul? Deoarece seamănă, se uită - pentru că presupun că sunt - se uită la probleme de performanță, vă va ajuta să faceți distincția între momentul în care o bază de date necesită timp și când un cod necesită timp?

Bert Scalzo: E o întrebare fantastică. Vreau să spun că lucrez în Visual Basic, iar eu, în interiorul meu Visual Basic, voi apela un Transact-SQL sau un PL / SQL. Permiteți-mi să fac PL / SQL, deoarece Oracle nu joacă bine întotdeauna cu instrumentele Microsoft. Aș putea să-mi profilez codul Visual Basic, iar profilul de acolo poate spune: „Hei, am apelat la această procedură stocată și a durat prea mult.” Dar atunci pot merge în procedura stocată și pot face un profil de bază de date pe stocat procedați și spuneți: „OK, din cele 100 de declarații aflate aici, aici sunt cele cinci care au cauzat problema.” Și, astfel, este necesar să faceți o echipă de etichete, unde trebuie să utilizați mai mulți profilatori.

Ideea este că, dacă vi se spune vreodată că problema de performanță se află în baza de date, un profil de bază de date vă poate ajuta să găsiți acul în fânul pe care afirmațiile sunt de fapt cele în care aveți o problemă. Vă spun un alt lucru care a apărut cu profilarea: dacă aveți o bucată de cod care se numește de un milion de ori, dar este nevoie doar de un microsecund fiecare din milionul de ori, dar se numește de un milion de ori, ceea ce ar arăta profilerul , lucrul ăsta a funcționat pentru multe unități de timp. Și, în timp ce codul poate fi extrem de eficient, s-ar putea să arătați și să spuneți: „Ooh, făceau acest apel prea repede către această bucată de cod. Poate că ar trebui să o sunăm doar de fiecare dată, mai degrabă decât de fiecare dată când procesăm o înregistrare ”sau ceva de genul acesta. Așadar, puteți găsi unde există coduri eficiente care sunt numite prea des și asta este de fapt o problemă de performanță.

Robin Bloor: Da, este minunat. Nu am făcut niciodată asta. Vedeți, desigur, când am avut probleme în baza de date, a fost ca și cum aș face într-un fel sau altul, fie să mă ocup de baza de date, fie să mă ocup de cod; Nu am putut niciodată să mă ocup cu ambii în același timp. Dar acolo, din nou, n-am făcut ... Nu am fost niciodată implicat în construirea de aplicații în care am avut stocate proceduri, așa că cred că nu am reușit niciodată să intru în probleme care m-au condus în sălbăticie, ideea că ai împărțit codul între baza de date și un program. Dar da, faceți totul - Presupun că răspunsurile vor fi da, dar aceasta face parte dintr-o activitate a echipei de dezvoltare, când încercați într-un fel sau altul să remediați ceva rupt sau poate încercați să reuniți o nouă aplicație. Dar toate acestea se adaptează cu toate celelalte componente pe care le-aș aștepta în mediu? Pot să mă aștept că aș putea să îmbine acest lucru împreună cu toate pachetele de teste și cu toate celelalte chestii pe care le-aș face și cu lucrurile mele de management de proiect, este cum stau toate aceste clipuri?

Bert Scalzo: Da, poate deveni o parte a oricărui proces structurat pentru a face eforturile de programare sau dezvoltare. Și amuzant, săptămâna trecută am avut un client care construia o aplicație web, iar baza lor de date fusese mică, din punct de vedere istoric și, astfel, faptul că nu au fost niște programatori foarte buni niciodată. Ei bine, baza lor de date a crescut de-a lungul anilor, iar acum durează 20 de secunde într-o pagină web, între momentul în care spui: „Conectează-mă și dă-mi câteva date de văzut” și când ecranul apare de fapt, și acum acum o problemă de performanță. Știau că problema nu era în niciunul din Java sau în oricare din alte locuri. Au avut însă mii de proceduri stocate și astfel au fost nevoiți să înceapă să profileze procedurile stocate pentru a afla de ce este nevoie ca această pagină web să apară 20 de secunde? Și am descoperit că au o aderare carteziană la una dintre declarațiile lor selecte și nu o știau.

Robin Bloor: Wow.

Bert Scalzo: Dar cineva mi-a spus o singură dată: „Păi, cum ar putea să aibă o aderare carteziană și să nu o știe?” Și asta sună cu adevărat oribil; uneori, un programator care nu este foarte confortabil cu SQL va face ceva de genul să-mi ofere o aderare carteziană, dar apoi să-mi dea doar înapoi prima înregistrare, așa că știu că am ceva și am nevoie doar de prima. Și deci, nu își dau seama că au adus înapoi doar un miliard de înregistrări sau se uită printr-un miliard de înregistrări, pentru că l-au obținut pe cel de care erau interesați.

Robin Bloor: Uau, știu, asta se numește ... ei bine, asta este ceea ce se întâmplă Dez, în termeni de oameni care nu sunt la fel de pricepuți ca probabil ar trebui să fie, știți. Dacă sunteți un programator, ar trebui să știți care sunt implicațiile emiterii oricărei comenzi. Adică, într-adevăr, nu scuză acest nivel de prostie. Presupun, de asemenea, că, într-un fel sau altul, sunteți doar un limbaj agnostic în ceea ce privește acest lucru, deoarece acest lucru se concentrează pe partea bazei de date. Am dreptate în asta? Este la fel, orice folosiți pe partea de codare?

Bert Scalzo: Absolut, puteți face acest lucru în Fortran sau C sau C ++. De fapt, pe unele Unix, puteți face chiar și pentru limbajele lor de script; ele oferă de fapt aceleași instrumente. Și atunci vreau să mă întorc o secundă pentru ceea ce ai spus fără nicio scuză. Voi oferi programatorilor o pauză, pentru că nu-mi place să arunc programatori sub autobuz. Dar problema este într-adevăr mediul academic, deoarece atunci când te duci să înveți cum să fii programator, ai învățat gândirea înregistrată la un moment dat. Nu ești învățat gândirea setului și asta este limbajul de interogare structurat sau SQL funcționează cu seturi; de aceea avem uniunea, intersecția și operatorul de minus. Și este foarte greu, uneori, pentru o persoană care nu s-a gândit niciodată în ceea ce privește seturile, să renunțe, să dea drumul la procesarea înregistrată la un moment dat și să lucreze cu seturi.

Robin Bloor: Da, sunt cu tine la asta. Adică, acum am o problemă de educație; Cred că este complet o problemă de educație, cred că este normal ca programatorii să gândească procedural. Și SQL nu este procedural, declarativ. De fapt spui doar „asta vreau și nu-mi pasă cum o faci”, știi? În timp ce, cu ajutorul limbajelor de programare, de multe ori te-ai rostogolit mânecile și te-ai aruncat în minuțioanele de a gestiona chiar și conturile, în timp ce faci o buclă. Mă duc la ...

Bert Scalzo: Nu. OK, continuați.

Da, aveam să spun că ai adus un alt exemplu potrivit căruia un profiler ar fi bine să prindă acest fel, continuă cu această procesare înregistrată la un moment dat. Uneori, un programator care se pricepe la o logică înregistrată la un moment dat, nu își poate da seama cum să facă un program SQL. Ei bine, hai să spunem că face două bucle FOR și practic face o aderare, dar o face pe partea clientului. Așadar, nu face același efect ca și o aderare, dar nu face acest lucru singur, iar un profil ar capta asta, pentru că probabil vei ajunge să petreci mai mult timp făcând înscrierea manual decât să lași serverul bazei de date să o facă pentru tine.

Robin Bloor: Da, asta ar fi un dezastru. Vreau să spun, ai fi doar învârtit. Foarte rau mereu.

Oricum, imi trece lui Dez; Sunt sigur că nu a primit câteva întrebări interesante.

Dez Blanchfield: Mulțumesc, da, da. O să mă alătur în programatorii care nu aruncă sub autobuz. Vreau să spun că am petrecut prea mulți ani în viața mea fiind un codificator, la toate nivelurile, știi, dacă este așa cum ai spus, stând pe linia de comandă a mașinii Unix și, în unele cazuri, am fost chiar implicat într-un câteva porturi diferite ale Unix de la o platformă hardware la alta. Și vă puteți imagina provocările pe care le-am avut acolo. Însă realitatea este aceea că cardul de ieșire din închisoare pentru fiecare codificator și scriptor din lume. Este o știință a rachetelor, destul de literal, să scrii cu adevărat strâns de fiecare dată, tot timpul, este o știință a rachetelor. Și povești celebre despre oameni precum Dennis Ritchie și Brian Kernahan care lucrează la o bucată de cod independent și apoi apelează la o chat de revizuire a codului peste o cafea și află că au scris exact aceeași bucată de cod, exact în același program, exact în același program. în același mod. Și au făcut-o în C. Dar acel nivel purist de programare există foarte rar.

Cert este că, zilnic, există doar 24 de ore pe zi, șapte zile într-o săptămână și trebuie doar să terminăm lucrurile. Și uite, atunci când vine vorba de nu numai de programatori tradiționali, DBA-uri și codificatoare și scripturi, și sysadmin, și admin-uri de rețea și personal de securitate, și totul până la partea de date a cetățenilor în aceste zile; auzim, everyones încearcă doar să-și facă treaba. Și, așadar, cred că marea preluare din acest lucru este că mi-a plăcut demo-ul tău și mi-a plăcut transportul cu care ne-ai lăsat acolo, în urmă cu o clipă, vorbind cu Robin despre faptul că asta are un anumit lucru - poate nu atât de mult o nișă - dar un spațiu larg la care se aplică, în ceea ce privește remedierea codului și a SQL și a bazelor de date. Dar am fost foarte încântat să vă aud spunând că puteți să-l încercați pe un script de shell și să găsiți câteva probleme, pentru că știți, în zilele de azi și de vârstă lucrau întotdeauna la cel mai mic cost la tot.

Motivul pentru care puteți cumpăra o cămașă de 6 dolari undeva, este pentru că cineva a construit un sistem suficient de ieftin pentru a fabrica și expedia efectiv și livra și vinde logistic și vânzarea cu amănuntul și pentru a lua plăți online pentru a obține acea cămașă de 6 USD Și asta nu se întâmplă dacă ai primit plată oamenilor de 400.000 USD pe an pentru a scrie cod în mod perfect; doar întreaga sa dezvoltare. Deci, acel punct, cred că una dintre întrebările pe care chiar te iubesc este doar să ne oferiți mai multe informații, care este lățimea și atingerea tipului de persoane pe care le vedeți în prezent care utilizează aceste tipuri de instrumente pentru a profila un cod și a privi pentru probleme de performanță? Inițial, istoric, de unde provin? Au fost marile case de inginerie? Și apoi, mergând înainte, este cazul, am corect în gândul că din ce în ce mai multe companii implementează acest instrument sau aceste instrumente, pentru a încerca să ajute codificatorii, care știu care tocmai termină lucrurile pentru a termina munca. și scoate-l pe ușă? Și uneori avem nevoie de un card de ieșire din pușcărie? Am dreptate să cred că istoric am avut o concentrare și dezvoltare mai inginerească? Asta devenea o abordare academică mai mică, după cum a spus Robin, și acum codul său autodidact sau tăiat și lipit sau pur și simplu lucrurile s-au construit? Și asta se potrivește cu genul de oameni care iau produsul acum?

Bert Scalzo: Da, exact. Și îți ofer un exemplu foarte specific, vrem doar să terminăm treaba, pentru că oamenii de afaceri nu vor perfecțiune. Este ca un joc de sah computerizat: jocul de sah nu cauta raspunsul perfect; caută un răspuns suficient de bun într-o perioadă de timp rezonabilă, așa că programăm. Dar ceea ce găsesc acum, majoritatea oamenilor în loc să spună că vor un profiler ca parte a testării unității lor - așa cum aș face-o, pentru că nu o văd ca o pierdere de timp - ceea ce se întâmplă acum se face asta mai târziu, uneori, în timpul testării integrării sau testării stresului, dacă au avut noroc. Dar, de cele mai multe ori, o parte a unei escaladări, unde ceva a intrat în producție, a funcționat o perioadă, poate chiar a rulat ani de zile, iar acum nu merge bine, iar acum este bine profilat. Și acesta pare să fie scenariul mai comun acum.

Dez Blanchfield: Da, și cred că termenul „datorie tehnică” este probabil unul mai mult decât familiarizați cu voi; Îl cunosc pe Robin și cu siguranță sunt. Cred că în aceste zile, în special în abordări agile pentru dezvoltarea și construirea de sisteme, pentru mine, conceptul de datorie tehnică este acum un lucru foarte real, iar noi de fapt îi punem la socoteală în proiecte. Știu, vreau să spun, am obținut proiecte proprii, cum ar fi Media Lens și altele, în cadrul cărora ne-am întâmplat codificarea zilnic și diverse lucruri din grupul Bloor. Și ori de câte ori construiam ceva, ne uităm, îl privesc și mă uit mereu din punctul de vedere al ceea ce mă va costa să repar acest lucru chiar acum, față de ce pot să-l aduc în cutie și scoate-l acolo și apoi privește și vezi dacă aceste lucruri se vor rupe. Și moștenesc această datorie tehnică pe care știu că trebuie să o încercuiesc mai târziu și să o repar.

Și vreau să spun, am făcut asta în ultimele șapte zile: am scris câteva instrumente și scripturi, am scris câteva bucăți de limbaj Python și l-am dislocat la Mongo, asigurându-se că este frumos și curat și sigur, dar este doar întrebarea de care am nevoie, știind că am nevoie de funcția respectivă pentru a merge la un puzzle mai mare; Acolo este durerea mea reală. Așadar, suportați această datorie tehnică și cred că acum nu este doar un lucru ocazional, cred că aceasta face parte din ADN-ul dezvoltării acum. Oamenii pur și simplu - nu înșelători - acceptă doar datoria tehnică este un tip normal de emisiune modus operandi și trebuie doar să o suporte. Este locul în care suporti datoriile tehnice. Și cred că mare lucru despre ceea ce ne-ați arătat în demo a fost că puteți să profilați literalmente și să urmăriți cât timp durează ceva. Și asta este probabil unul dintre lucrurile mele preferate. Adică, am construit instrumente de profilare - am folosit pentru a construi instrumente în Sed și Lex și Orc pentru a rula codul nostru și a vedea unde sunt buclele, înainte ca instrumentele de acest fel să fie disponibile - și când ați creat codul pentru a merge și revizui propriul dvs. cod , te pricepi foarte bine să nu fii nevoit să îți revizuiești propriul cod. Dar nu este cazul acum. Având în vedere acest lucru, există un anumit segment de piață care preia acest lucru mai mult decât oricare altul? Văzând ca o masă ...

Bert Scalzo: Oh, da, am ... Voi atrage o analogie pentru tine și îți arăt faptul că non-programatorii o fac tot timpul. Deoarece, dacă învăț vreodată o cursă sau o sesiune de profanare, îi întreb pe oameni: „OK, câți oameni aici merg în Microsoft Word și nu folosesc în mod intenționat corectorul ortografic?” Și nimeni nu pune mâna sus, pentru că pentru a scrie documente, știm cu toții că putem face greșeli în limba engleză și astfel toată lumea folosește corectorul ortografic. Și am spus: „Păi, cum de când scrii în IDE-ul tău ca Visual Basic, nu folosești depanatorul? Este același lucru, este ca un verificator de ortografie. ”

Dez Blanchfield: Da, de fapt, este o mare analogie. Nu m-am gândit cu adevărat, trebuie să recunosc că fac de fapt ceva similar cu câteva instrumente pe care le folosesc. De fapt, unul, ODF, favoritul meu cu Eclipse este doar să tai și să lipiți codul acolo și să caut lucruri care să scoată în evidență imediat și să realizez că am făcut o dactilografie la un apel de clasă. Și, dar este interesant acum cu instrumentul de acest fel, îl poți face în timp real, spre deosebire de a te întoarce și de a-l privi mai târziu, ceea ce este cam drăguț să-l surprinzi. Dar da, aceasta este o mare analogie a introducerii într-un procesor de texte, determină un interesant apel de trezire care, doar să vă dați seama că ați făcut unele greșeli sau chiar o eroare gramaticală, nu?

Bert Scalzo: Exact.

Dez Blanchfield: Deci, acum vedeți mai multe aspecte de la Banuș, adică, întrebarea finală de la mine, înainte de a arunca întrebările noastre de întrebare și poate, pentru participanții noștri. Dacă ar trebui să oferiți un fel de recomandare în legătură cu abordarea pentru a face acest lucru - presupun că aceasta este retorică - este cazul să ajungeți din timp și să aplicați acest lucru pe măsură ce vă dezvoltați, înainte de a vă dezvolta? Sau este cazul că în principal obțineți o construcție, faceți mișcare, construiți ceva, apoi intrați și faceți profilul mai târziu? Banuiesc ca este cazul sa devii devreme si sa te asiguri ca codurile tale se curata in prealabil. Sau este cazul că ar trebui să ia în considerare această parte a post-implementării lor?

Bert Scalzo: În mod ideal, ar face-o în avans, dar pentru că toată lumea se află în lumea agitată, unde tocmai au ajuns să facă lucrurile, tind să nu o facă până când nu se confruntă cu o problemă de performanță pe care nu o pot rezolva adăugând mai multe procesoare și memorie. la o mașină virtuală.

Dez Blanchfield: Da. Deci, de fapt, ai menționat ceva interesant, dacă pot rapid? Ați menționat înainte că acest lucru poate fi rulat de oriunde și se poate vorbi cu baza de date în partea din spate. Deci, acest lucru este confortabil cu felul de concept bimodal despre care vorbim acum, de cloud on-premise / off-premise, de aspectul lucrurilor, de asemenea, la sfârșitul zilei, dacă se poate vorbi până la capăt și vezi. codul, chiar nu-i pasă, nu?

Bert Scalzo: Exact, da, poți rula asta în cloud.

Dez Blanchfield: Excelent, pentru că cred că este genul în care se îndreaptă noua noastră lume curajoasă. Deci, Eric. Voi reveni acum la tine și voi vedea că am primit câteva întrebări aici și vreau ca participanții noștri să rămână în continuare cu noi, chiar dacă am trecut peste oră.

Eric Kavanagh: Da, există câțiva oameni acolo, doar fac un comentariu rapid: Bert, cred că metafora, analogia pe care o oferiți folosirii verificării ortografice este sincer genială. Acest lucru este demn de un blog sau două, destul de sincer, pentru că este o modalitate bună de a încadra conținutul de ceea ce faci și cât de valoros este și cum ar trebui să fie cu adevărat o practică optimă să folosești un depanator pe un în mod regulat, nu? Pun pariu că îți dai niște capete încuviințând când îl arunci, nu?

Bert Scalzo: În mod absolut, ceea ce le spun este „De ce execut o verificare ortografică pe documentele mele? Nu vreau să fiu jenat de greșelile de ortografie stupide. ”Ei bine, ei nu vor să fie rușinați de greșeli stupide de codificare!

Eric Kavanagh: Dreapta. Da, întradevăr. Ei bine, oameni buni, ne-am ars o oră și cinci minute aici, atât de mare mulțumesc tuturor celor prezenți pentru timpul și atenția dvs. Arhivăm toate aceste chat-uri web, nu ne simțiți liber să reveniți oricând și să le consultați. Cel mai bun loc pentru a găsi aceste link-uri este probabil techopedia.com, deci adăugați acest lucru la această listă chiar aici.

Și cu asta, aveam de gând să-ți ia rămas bun, oameni buni. Încă o dată, mare treabă, Bert, mulțumesc prietenilor noștri de la IDERA. Ei bine, vorbesc cu tine data viitoare, bine vorbesc cu tine săptămâna viitoare, de fapt. Ai grijă! Pa! Pa.