Tag væk: Værten Eric Kavanagh diskuterede debugging og profilering af databaser med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bert Scalzo.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer, det er 4:00 østlig tid på en onsdag, og det betyder selvfølgelig.
Robin Bloor: Kan ikke høre dig, Eric.
Eric Kavanagh: Jeg var der for dage siden, så du er ikke alene. Men så emnet i dag er virkelig interessante ting. Det er den slags ting, du vil sikre dig, der sker i baggrunden hos din virksomhed, medmindre du er den person, der gør det, i hvilket tilfælde du vil sikre dig, at du gør det ordentligt. Fordi talte om fejlfinding. Ingen kan lide bugs, ingen kan lide, når softwaren holder op med at fungere - folk bliver urolige, brugere bliver uvenlige. Det er ikke godt. Så skulle vi tale om "Hurtig respons: Debugging af databaser og profilering til redning."
Der er et sted om dit, virkelig, slå mig op, @eric_kavanagh selvfølgelig.
Dette år er varmt. Og debugging bliver varmt, uanset hvad. Det vil virkelig være et af disse problemer, det vil aldrig gå væk, uanset hvor godt vi får til dette, det er altid problemer, så nøglen er, hvordan kommer du til, hvor du hurtigt kan løse disse problemer? Ideelt set har du gode programmerere, store miljøer, hvor ikke for meget går galt, men som det gamle ordsprog siger: ”Ulykker sker i de bedste familier.” Og det samme gælder for organisationer. Så dette sker, det vil ske, spørgsmålet er, hvad der vil være din løsning til at håndtere det og løse disse problemer?
Hør godt fra Dr. Robin Bloor, så vores egen Dez Blanchfield fra nedenunder, og selvfølgelig vores gode ven, Bert Scalzo, fra IDERA. Og faktisk vil jeg aflevere nøglerne til Robin Bloor, tage det væk. Gulvet er dit.
Robin Bloor: OKAY. Dette er et interessant emne. Jeg tænkte, fordi Dez sandsynligvis vil fortsætte med de faktiske teknikker og krigshistorier om fejlsøgning, jeg tænkte, at Id bare laver en baggrundsdiskussion, så vi skulle få et fuldt afrundet billede af, hvad der sker. Jeg gjorde dette længe, og jeg plejede at være en kodning, så det kunne lide, og jeg var næsten fristet med denne præsentation til at begynde at vokse lyrisk om ideen om open source, men jeg troede, jeg overlader det til nogen anden.
Her er en liste over berømte bugs, og de fleste af disse kommer på anybodys øverste liste, dybest set, undtagen de sidste to koster mindst $ 100 millioner. Den første var Mars Climate Orbiter, mistede sig i rummet, og det var på grund af et kodningsproblem, hvor folk forvekslede metriske enheder med (griner) fødder og tommer. Ariane Five Flight 501 var der et misforhold mellem en motor, der blev sat på, og de computere, der skulle køre raketten, da den blev lanceret. Flere computerfejl, eksploderende raket, overskriftnyheder. Sovjetisk gasledning i 1982, siges at være den største eksplosion i planetens historie; Jeg er ikke sikker på, om det er. Russerne stjal noget automatiseret kontrolsoftware, og CIA indså, at de ville gøre det og lægge fejl i det, og sovjeterne implementerede det uden test. Så, sprængte en pipeline op, syntes det var morsomt.
Morris-ormen var et kodningseksperiment, der pludselig blev en voldsom orm, der gik rundt om alle ting - det tilsyneladende forårsagede skade på 100 millioner dollars; det er et skøn selvfølgelig. Intel begik en berømt fejl med en matematikchip - en matematikinstruktion på Pentium-chippen i 1993 - der skulle have kostet over $ 100 millioner. Apples Maps-program er muligvis den værste og mest katastrofale lancering af alt, hvad Apple nogensinde har gjort. Mennesker, der prøvede at bruge det, var, mener jeg, nogen kørte langs 101 og opdagede, at Apple Map sagde, at de var midt i San Francisco-bugten. Så folk begyndte at referere til Apple Maps-appen som iLost. Den - vores længste strømafbrydelse i 1990 - det var bare interessant set ud fra omkostningerne ved noget lignende - AT&T var ude i cirka ni timer, og det kostede omkring 60 millioner dollars i langdistanceopkald.
Og jeg var hos et britisk forsikringsselskab, og databasen, de implementerede en ny version af databasen, og det begyndte at udslette data. Og det husker jeg ekstremt godt, fordi jeg bagefter blev opfordret til at deltage i en slags databasevalg på grund af det. Og det var meget interessant, at de havde taget en ny version af databasen, og de havde et batteri af test, som de gjorde for nye versioner af databasen, at den bestod alle test. Det fandt en virkelig uklar måde at slette data på.
Så det er alligevel det. Jeg troede, at Id talte om impedansmatchet og den udstedte SQL. Det er interessant, at relationelle databaser gemmer data i tabeller og kodere har en tendens til at manipulere data i objektstrukturer, der virkelig ikke kortlægger meget godt til tabeller. Og på grund af det får du det, der kaldes impedansforhold, og nogen er nødt til at håndtere det på en eller anden måde. Men hvad der faktisk sker, fordi en model, kodermodellen og databasen en anden model, ikke er særlig tilpasset. Du får fejl, der bare ikke ville ske, hvis branchen havde bygget ting, der fungerer sammen, hvilket jeg synes er sjove. Så dybest set på kodersiden, når du får hierarkier, kan det være typer, det kan resultere sæt, det kan være dårlig API-kapacitet, det kan være en masse ting, der bare kaster ting ud i form af interaktion med databasen. Men det, der er mest for mig, virkelig interessant; forbløffet mig altid over, at du havde denne SQL-barriere, der også er en slags impedans på en måde, som koderne og databasen fungerer sammen. Så SQL har datagenkendelse, hvilket er fint, og det har DML til at vælge, projektere og deltage, hvilket er fint. Du kan smide en masse kapacitet med hensyn til at få data ud af databasen med det. Men det har meget lidt matematisk sprog til at gøre ting. Det har lidt af dette og det, og det har meget lidt tidsbaserede ting. Og på grund af dette er SQL et ufuldstændigt, hvis du vil, middel til at hente dataene. Så databasegjengen byggede lagrede procedurer for at leve i databasen, og årsagen til de lagrede procedurer, der var der, var, at du ikke rigtig ville have at kaste data frem og tilbage til et program.
For nogle af funktionaliteterne var ekstremt dataspecifikke, så det var ikke bare referencemæssig integritet og kaskaderende sletninger og lignende ting, databasen tog sig af alle de pludselige du lægger funktionalitet i en database, hvilket naturligvis betød, at funktionaliteten til en applikationen kunne opdeles mellem koderen og selve databasen. Og det gjorde jobbet med at implementere nogle former for funktioner virkelig ret vanskeligt og derfor mere tilbøjelige til fejl. Så det er den ene side af databasespelet, fordi det betyder, at du har fået en masse implementeringer for eksempel, at jeg har været involveret i relationelle databaser, der er virkelig en frygtelig masse kode, der sidder i lagrede procedurer, der håndteres separat fra kode, der sidder i applikationerne. Og det ser ud til at være en meget mærkelig ting at være nødt til, det skulle være ret smart til at gøre forskellige ting.
Jeg troede, at Id også talte om databasepræstation, fordi ydelsesfejl ofte betragtes som fejl, men dybest set kan du have en flaskehals på CPU'en, i hukommelsen, på disken, på netværket, og du kan have problemer med ydeevnen på grund af låsning. Tanken ville være, at koderen ikke behøver at være bekymret for ydeevne, og databasen faktisk ville fungere rimeligt godt. Det skal designes, så koderen ikke behøver at vide det. Dog får du dårligt databasedesign, får du dårligt programdesign, får du samtidighed i blanding af arbejdsmængde, hvilket også kan føre til ydelsesproblemer. Du får belastningsbalancering, du får kapacitetsplanlægning, datavækst - det kan forårsage, at en database bare stopper eller bremser. Det er en interessant ting, når databaser bliver næsten fulde, går de langsommere. Og du kan have problemer med datalag med hensyn til replikation og behovet for at replikere og behovet for at lave sikkerhedskopiering og gendannelse. Alligevel er det en generel oversigt.
Det eneste, jeg gerne vil sige, er, at database debugging kun kan være så besværlig og ikke-triviel - og det siger jeg, fordi jeg har gjort en masse af det - og du vil ofte opdage det som alle situationer i debugging, som jeg nogensinde har oplevet er, er den første ting, du nogensinde ser, er et rod. Og du skal prøve at gå fra rodet til at finde ud af, hvordan rodet blev til. Og ofte, når du ser på et databaseproblem, er alt, hvad du ser på, korrupte data, og du tænker: "Hvordan fanden skete det?"
Jeg vil alligevel videregive til Dez, som sandsynligvis vil sige flere visdomsord, end jeg kom ud med. Jeg ved ikke, hvordan jeg giver dig bolden, Dez.
Eric Kavanagh: Jeg passerer det, står ved, hold på.
Automatisk stemme: Deltagerlinier er slået fra.
Eric Kavanagh: Okay, hold et sekund på, lad mig give Dez bolden.
Dez Blanchfield: Tak, Eric. Ja, Dr. Robin Bloor, du er faktisk mest korrekt: dette er et emne, en livslang bugbear, hvis du undskylder ordspillet, undskyld at jeg ikke kunne hjælpe mig med det. Forhåbentlig kan du se min første skærm der, mine undskyldninger for skriftstørrelsesproblemet øverst. Emnet bugs er et dagligt foredrag, i mange tilfælde efter min oplevelse. Det er et så bredt og bredt emne, så jeg vil lægge fokus på to centrale områder, nærmere bestemt begrebet, hvad vi betragter som en fejl, men et programmeringsspørgsmål. Jeg tror, at i disse dage introduktion af en bug i sig selv generelt bliver afhentet af de integrerede udviklingsmiljøer, selvom det kan være langvarige fejl. Men ofte er det mere tilfældet med profilering af kode og det er muligt at skrive kode, der fungerer, det skulle være en fejl. Så min titel glider her, jeg havde faktisk en kopi af dette i meget høj opløsning A3, men desværre blev det ødelagt i et flytning af hus. Men dette er en håndskrevet note på et programmeringsark fra omkring 1945, hvor angiveligt nogle folk ved Harvard University i USA, deres anden bygning af en maskine kaldet Mark II. De fejlsøgte et eller andet problem på fælles sprog, men de forsøgte at finde en fejl, og det viser sig, at noget lidt anderledes end hvad der var en hardware og et angiveligt softwareproblem fulgte med.
Så den urbane myte er den runde omkring 9. septemberth, 1945, trak et team ved Harvard University en maskine fra hinanden, de stødte på noget, de kaldte "stafet sytti" - i disse dage blev programmeringen udført i en fysisk forstand, du sår kode omkring et bræt, og det var sådan, du effektivt programmerede maskine - og de fandt, at dette relæ nummer sytti, der var noget galt med det, og det viser sig, at selve udtrykket “bug” blev til, fordi det ganske bogstaveligt talt var en møll - angiveligt var der en møl, der var fastklemt mellem et stykke kobbertråd fra et sted til et andet. Og historien fortæller, at den legendariske Grace Hopper som denne billedtekst, til mit titeldia, "første faktiske tilfælde af, at der er fundet en fejl," citerer unote.
Men som Robin fremhævede tidligere i sin første dias, går begrebet en bug så langt tilbage, som vi kan forestille os, at mennesker laver beregninger, begreber som en patch. Udtrykket “patch” kom fra et faktisk stykke bånd, der blev tapet over et hul på et stempelkort. Men hele pointen med dette er, at udtrykket "debugging" kom ud af dette koncept om at finde en fejl i en fysisk maskine.Og lige siden har vi brugt den terminologi omkring at prøve at håndtere problemer, enten ikke så meget som kodningsproblemer i et program, der ikke kompilerer, men som et program, der ikke kører godt. Og specifikt har ikke været profileret, bare finde ting som uendelige sløjfer, der bare går intet sted.
Men vi har også et scenarie, og jeg troede, at Id satte et par sjove lysbilleder ind, før jeg begyndte lidt mere detaljeret. Her er den klassiske tegneserie, kaldet XKCD på nettet, og tegneserieskaberen har nogle ret sjove synspunkter på verden. Og det her om et barn kaldet “Lille Bobby-borde” og angiveligt navngivet hans forældre denne unge dreng Robert); DROP TABEL Studenter; - og det kaldes, og slags "Hej, dette er dine sønner skole, der har nogle problemer med computeren," og forælderen svarer, "Åh kære, har han ødelagt noget?" Og læreren siger, "Nå, på en måde ”, og læreren spørger,” har du virkelig navngivet din søn Robert); DROP TABEL Studerende; -? ”Og forælderen siger:” Åh ja, lille Bobby-borde, vi kalder ham. ”Uanset hvad fortsætter de med at sige, at de nu har mistet årene studerendes poster, jeg håber, du er glad. Og svaret er, "Nå, du skal rense og desinficere dine databaseindgange." Og jeg bruger det mange gange til at tale om nogle af de problemer, vi har med at finde ting i kode, at koden ofte ikke ser på dataene så godt .
En anden morsom, jeg ved ikke, om dette er ægte eller ikke - jeg formoder, at det er en falsk - men igen, det berører også min sjove knogle. Nogen skifter nummerplade foran på deres bil, til en lignende erklæring, der får databaser til at falde i hastighedskameraer og så videre, der fanger bilers nummerplader. Og jeg refererer altid til det som at jeg tvivler på, at enhver programmør forventede et hit og run af deres kode af et faktisk motorkøretøj, men aldrig undervurderer det - magten fra en vred nørd.
(Latter)
Men dette fører til mig til mit nøglepunkt, antager jeg, og det er, at vi engang kunne fejlsøge og profilere kode som blot dødelige. Men jeg er meget af den opfattelse, at den tid er gået, og anekdotisk i min oplevelse, min første - og dette bliver mig aldeles frygtelig, jeg er sikker på; Robin du er velkommen til at pirre mig sjovt for dette - men historisk set er jeg fra en baggrund i en alder af 14 år og vandrer ned ad slutningen af byen og banker på døren til et datacenter kaldet “Data Com” i New Zealand og spørger om Jeg kunne tjene lommepenge på skolen ved at få den sene bus hjem, omkring 25 km pendler hver dag, ved at lægge papir i ers, bånd i båndstationer og bare være en generel administrator. Og underligt nok gav de mig et job. Men over tid lykkedes det mig at komme mig ind i bemandingen og finde programmører og indså, at jeg elskede kodning og gik gennem processen med at køre scripts og batchjob, som i slutningen af dagen stadig er kode. Du skal skrive scripts og batchjob, der ligner miniprogrammer og derefter gennemgå hele processen med at sidde på en 3270 terminal skrive kode for hånd.
Faktisk var min allerførste oplevelse på en teletypeterminal, der faktisk var fysisk 132-søjler. I det væsentlige skal du tænke på en meget gammel skrivemaskine med papir, der rullede igennem det, fordi de ikke havde et CRT-rør. Og fejlsøgningskode om det var et meget ikke-trivielt spørgsmål, så du havde en tendens til at skrive al din kode for hånd og derefter fungere som en maskinskriver, så du gjorde dit bedste for ikke at få fejl til at snige sig ind, fordi det er ekstremt frustrerende at skulle fortælle den ene linjereditor for at gå til en bestemt linje og derefter linjen og derefter skrive den ind igen. Men engang var det sådan, vi skrev kode, og det var sådan, vi debugged, og vi blev meget, meget gode til det. Og faktisk tvang det os til at have meget gode programmeringsteknikker, fordi det var et rigtig besvær at løse det. Men rejsen gik derefter igennem - og var alle bekendt med dette - den gik fra 3270 terminaloplevelsen i min verden, til Digital Equipment VT220, hvor du kunne se ting på skærmen, men igen, du gjorde bare det samme, som du gjorde på papirbånd slags redigeret format bare på en CRT, men du var i stand til lettere at slette, og du havde ikke denne "dit dit dit dit" lyd.
Og så ved du, Wyse-terminalerne - ligesom Wyse 150, sandsynligvis min yndlingsgrænseflade til en computer nogensinde - og derefter pc'en og derefter Mac'en, og derefter i dag moderne GUI'er og ID'er, der er webbaserede. Og en række programmer igennem det, programmering i en og samler og PILOT og Logo og Lisp og og Fortran og Pascal og sprog, der muligvis får folk til at krybe. Men dette er sprog, der tvang dig til at skrive en god kode; de lod dig ikke slippe af med dårlig praksis. C, C ++, Java, Ruby, Python - og vi kommer længere op i den programmeringsfase, vi får mere script-lignende, vi kommer tættere og tættere på Structure Query Language og sprog som PHP, der faktisk bruges til at påkalde SQL. Pointen med at fortælle dig, det vil sige, at jeg kom fra min baggrund, og jeg blev selvlært på mange måder, og de, der hjalp mig med at lære, lærte mig meget god programmeringspraksis og meget god praksis omkring design og processer for at sikre, at jeg ikke introducerede buggy kode.
Programmeringsmetoder i disse dage, ting som for eksempel struktureret forespørgsel sprog, SQL, det er et meget stærkt, enkelt forespørgsel sprog. Men vi har forvandlet det til et programmeringssprog, og jeg tror virkelig ikke, at SQL nogensinde var designet til at være et moderne programmeringssprog, men vi har skævt det til at blive det. Og det introducerer en hel række spørgsmål, årsag, når vi tænker over fra to synsvinkler: fra kodningssynspunktet og fra DBA-synspunktet. Det er meget nemt at komme med og introducere bugs til ting som bare dårlige programmeringsteknikker, doven indsats med at skrive kode, mangel på erfaring, den klassiske kæledyrsop, jeg har for eksempel med SQL-folk, der hopper på Google og søger efter noget og finder et websted, der er fik et eksempel og laver en kopi og indsæt af eksisterende kode. Og så gentages en dårlig kodning, malpractice og sætter den i produktion, fordi det bare sker for at give dem de resultater, de ønsker. Du har fået andre udfordringer, for eksempel stormede i disse dage alle hen imod dette, hvad vi kalder løbet til nul: at prøve at gøre alt så billigt og så hurtigt, at vi har et scenarie, hvor vi ikke beskæftigede lavere betalte personale. Og det mener jeg ikke på en urimelig måde, men ansat ikke eksperter til ethvert muligt job. Det var engang noget at gøre med computere raketvidenskab; det var involveret i ting, der gik hårdt og var meget højt, eller gik ud i rummet, eller ingeniører var stærkt kvalificerede mænd og kvinder, der havde gjort grader og havde en streng uddannelse, der forhindrede dem i at gøre gale ting.
I disse dage er der en masse folk, der kommer ind i udvikling og design og database, som ikke havde mange års erfaring, men ikke nødvendigvis havde den samme træning eller support. Og så slutter du med et scenarie med bare den traditionelle amatør kontra ekspert. Og der er en berømt linje, jeg kan faktisk ikke huske, hvem der oprettede tilbudet, linjen går, ”Hvis du synes, at det er dyrt at ansætte en ekspert til at gøre et job, skal du vente, indtil du ansætter et par amatører, der skaber et problem, og du er nødt til at ryd det op. ”Og så har SQL det spørgsmål, og det er meget, meget let at lære, det er meget let at bruge. Men det er efter min mening ikke et perfekt programmeringssprog. Det er meget nemt at gøre ting som at gøre en udvalgt stjerne fra hvor som helst og trække alt det ind i et programmeringssprog, som du er mere komfortabel med som PHP og Ruby eller Python, og brug det programmeringssprog, som du kender til, til at udføre datamanipulationen, snarere end at udføre en mere kompleks forespørgsel i SQL. Og vi ser dette meget, og så spekulerer folk på, hvorfor databasen kører langsomt; det er fordi en million mennesker forsøger at købe en billet fra et online billetsystem, hvor det gør en udvalgt stjerne hvor som helst.
Nu, det er et rigtig ekstremt eksempel, men du får pointen ud af alt dette. Så for bare virkelig at slå dette punkt hjem, er her et eksempel, som jeg bærer meget rundt. Jeg er en stor fan af matematik, jeg elsker kaosteori, jeg elsker Mandelbrotsættene. På højre side er der en gengivelse af Mandelbrotsættet, som jeg helt sikkert var bekendt med. Og til venstre er der et stykke SQL, der faktisk gør det. Nu, hver gang jeg lægger dette på en skærm et eller andet sted, hører jeg dette “Åh herregud, nogen gengav Mandelbrot-serien med SQL, er du seriøs? Det er sindssygt! ”Nå, hele poenget med det er at illustrere, hvad jeg lige skitserede der, og det er ja, faktisk kan du nu programmere næsten alt i SQL; det er et meget stærkt udviklet, kraftfuldt, moderne programmeringssprog. Når det oprindeligt var et forespørgselssprog, var det designet til bare at få data op. Så nu har vi meget komplekse konstruktioner og vi har lagrede procedurer, vi har fået programmeringsmetodik anvendt på et sprog, og så det er meget let for dårlig programmeringspraksis, manglende erfaring, klip-og-indsæt kode, lavtlønede medarbejdere forsøger at være højtlønnet personale, folk som foregiver at de kender, men de skal lære på jobbet.
En hel række ting, hvor kodeprofilering og hvad vi omtaler som fejlsøgning, som ikke så meget er at finde bugs, der forhindrer programmer i at fungere, men bugs, der bare skader systemet og dårligt struktureret kode. Når du ser på denne skærm nu, og du tror, det er netop, dets slags søde, og du tænker, “Wow, hvad en fantastisk grafik, Id elsker at køre det.” Men forestil dig at køre på et stykke forretningslogik. Det ser temmelig pænt ud, men det taler en matematisk grafisk gengivet kaosteori, men når du tænker over, hvad den potentielt kan bruges til i en vis forretningslogik, får du billedet meget hurtigt. Og for virkelig at illustrere det - og jeg er ked af, at farverne vendes, det antages at være en sort baggrund og grønt til at være en grøn skærm, men du kan stadig læse det.
Jeg gik og kiggede hurtigt på et eksempel på, hvad du potentielt kunne gøre, hvis du virkelig var skør og ikke havde nogen som helst erfaring og kom fra en anden baggrund af programmering og anvendte lignende af C ++ på SQL, for virkelig at illustrere mit pointe, før Jeg overleverer til vores lærte gæst fra IDERA. Dette er en struktureret forespørgsel, der er skrevet som C ++, men den er kodet i SQL. Og det kører faktisk, men det udføres over en periode på tre til fem minutter. Og det trækker tilsyneladende en linje med data ud af flere databaser, flere sammenføjninger.
Igen, hele poenget med dette er, at hvis du ikke har de rigtige værktøjer, hvis du ikke har de rigtige platforme og miljøer for at være i stand til at fange disse ting, og de kommer i produktion, og så har du 100.000 mennesker, der rammer et system hver dag, time eller minut, meget snart ender du med en Tjernobyl-oplevelse, hvor det store jern begynder at smelte ned og begrave sig til planetens kerne, fordi det stykke kode aldrig skulle komme i produktion. Dine systemer og dine værktøjer, undskyld mig, skulle samle det op, før det går overalt i nærheden af - selv gennem testprocessen, selv gennem UAT og systemintegration, skal det stykke kode samles og fremhæves, og nogen skal bringes til side og der siger: ”Se, det er virkelig smuk kode, men lad os få en DBA til at hjælpe dig med at opbygge den strukturerede forespørgsel ordentligt, fordi helt ærligt, det er bare grimt.” Og webadresserne der, kan du gå og kigge - det kaldes den mest komplekse SQL-forespørgsel, du nogensinde har skrevet. Årsag tro mig, der faktisk samles, den kører. Og hvis du klipper og indsætter det og bare håner databasen, er det noget at se på; Hvis du har værktøjer til at se databasen, skal du bare prøve at smelte ned over en periode på tre til fem minutter for at ringe tilbage, hvad er en linje af.
Så for at opsummere med det i tankerne, har hele min baggrund inden for kodning lært mig, at du kan give folk en pistol, og hvis de ikke er forsigtige, skyder de sig selv i foden; tricket er at vise dem, hvor sikkerhedsmekanismen er. Med de rigtige værktøjer og den rigtige software lige ved hånden, efter at du har udført kodningen, kan du gennemgå din kode, du kan finde problemer ved at profilere koden, du kan finde effektive utilsigtede fejl, der er ydeevneproblemer, og som jeg sagde tidligere om , engang kunne du gøre det ved at se på en grøn skærm. Du kan ikke længere; der er hundretusinder af kodelinjer, der er titusinder af apps, der er indsat, der er millioner af databaser i nogle tilfælde, og endda supermænd kan faktisk ikke gøre dette for hånden. Du har bogstaveligt talt brug for den rigtige software og de rigtige værktøjer ved hånden, og du har brug for, at teamet bruger disse værktøjer, så du kan finde disse problemer og adressere dem meget, meget hurtigt, inden du kommer til punktet, hvorimod Dr. Robin Bloor fremhævede, ting bliver enten katastrofale, og ting sprænger, eller mere almindeligt, de begynder bare at koste dig en masse dollars og en masse tid og kræfter og ødelægge moral og sånt, når de ikke kan finde ud af, hvorfor ting tager lang tid at løbe.
Og med det i tankerne overdrager jeg vores gæst, og jeg ser frem til at høre, hvordan de har løst dette problem. Og især den demo, som jeg tror, var ved at modtage. Eric, jeg passerer tilbage.
Eric Kavanagh: OK, Bert, tag den væk.
Bert Scalzo: Ok tak. Bert Scalzo her fra IDERA, Jeg er produktadministrator for vores databaseværktøjer. Og jeg vil tale om fejlfinding. Jeg tror, en af de vigtigste ting, som Robin sagde tidligere - og det er rigtigt, at fejlsøgning er besværlig og ikke-triviel, og når du går til databasesøgning er dens en størrelsesorden endnu mere besværlig og ikke-triviel - så det var et vigtigt tilbud.
OKAY. Jeg ville starte med programmeringshistorien, fordi jeg mange gange ser folk, der ikke debugger, de bruger ikke en debugger, de programmerer bare med det sprog, de bruger, og mange gange siger de til mig, ”Nå, disse debugger-ting er nye, og vi er ikke begyndt at bruge dem endnu. ”Og så, hvad jeg gør er, at jeg viser dem dette tidslinjediagram, slags forhistorie, alderdom, middelalder, dens slags sige hvor var vi i betingelser for programmeringssprog. Og vi havde meget gamle sprog, der startede tilbage i 1951 med samlingskode, og Lisp og FACT og COBOL. Så kommer vi ind i den næste gruppe, Pascals og Cs og derefter den næste gruppe, C ++ s, og ser hvor det spørgsmålstegn er - det spørgsmålstegn er omtrent lige omkring 1978 til måske 1980. Et eller andet sted i det område havde vi debuggers, der er tilgængelige for os, og så at sige, “Hej, jeg bruger ikke en debugger, forårsager det er en af disse nye ting,” så skal du være begyndt at programmere, ved du, tilbage i 1950'erne, fordi det er den eneste måde du vil få væk med den påstand.
Nu er den anden ting, der er sjovt ved dette diagram, Dez har lige skrevet en kommentar om Grace Hopper, jeg kendte faktisk Grace, så det er sjove. Og så er den anden ting, jeg lo af, at han talte om teletyper og jeg sad der og sagde: ”Mand, det var det største spring, vi nogensinde har haft i produktiviteten, da vi gik fra kort til teletyper, det var det største spring nogensinde.” Så , og jeg har programmeret på alle sprog her, inklusive SNOBOL, som ingen nogensinde har hørt om før, det var en CDC, Control Data Corporation, så jeg gætte på at jeg bliver lidt for gammel til denne branche.
Dez Blanchfield: Jeg ville sige, du har alderen os frygteligt der.
Bert Scalzo: Ja, jeg siger dig, jeg har lyst til bedstefar Simpson. Så jeg ser på debugging og der er forskellige måder at udføre debugging på. Du kunne tale om, hvad vi alle synes om, som traditionelt at komme ind i en debugger og gennemgå kode. Men også folk vil instrumentere deres kode; det er, hvor du sætter udsagn i din kode, og måske producerer du en outputfil, en sporingsfil eller noget, og så instrumenterer du din kode. Jeg vil regne det som fejlfinding, det er lidt sværere, en måde at gøre det på, men det tæller. Men også, vi har den berømte erklæring: du ser, og folk faktisk sætter udsagn i, og jeg har faktisk set et værktøj, hvor - og det er et databaseværktøj - hvor hvis du ikke ved, hvordan man bruger en debugger, skal du trykke på en knap, og den vil holde fast udsagn i hele din kode for dig, og når du er færdig, skal du trykke på en anden knap, og den fjerner dem. Fordi det er sådan, at mange mennesker debug.
Og grunden til, at vi debuger er todelt: Først og fremmest, vi var nødt til at finde ting, der gør vores kode ineffektiv. Med andre ord betyder det typisk, at der er en logisk fejl, eller vi har gået glip af et forretningskrav, men hvad det er, er koden ikke effektiv; det gør ikke, hvad vi forventede, at det skulle gøre. Den anden gang vi går, og vi foretager fejlsøgning, for effektivitet, og det kan være en logisk fejl, men hvad det er, er, at jeg gjorde den rigtige ting, det kommer bare ikke hurtigt nok tilbage. Nu gør jeg dette punkt, fordi en profilere sandsynligvis bedre til det andet scenarie og ville tale om både debuggers og profilers. Derudover er der dette koncept med fjernfejlretning; dette er vigtigt, fordi mange gange, hvis du sidder på din personlige computer, og du bruger en debugger, der rammer en database, hvor koden faktisk udføres i databasen, gør du faktisk det, der kaldes fjernfejlfinding. Du er måske ikke klar over det, men det er der, der sker. Og så er det meget almindeligt med disse debuggers at have break-point, se point, træde ind og gå over og nogle andre almindelige ting, som jeg vil vise dem på et skærmbillede i et øjeblik.
Nu, profilering: du kan gøre profilering på et par forskellige måder. Nogle mennesker vil sige, at arbejdsbyrde er fanget og gentaget, hvor det fanger alt, det, der tæller som profilering. Min oplevelse har været mere dens bedre, hvis det er udført prøveudtagning. Der er ingen grund til at fange hver eneste udsagn, for nogle udsagn kører bare så hurtigt, at du ikke er ligeglad, hvad du virkelig prøver at se er, ja, det er dem, der fortsat dukker op igen og igen, fordi de løber for længe . Så nogle gange kan profilering betyde prøveudtagning snarere end at køre det hele. Og typisk vil du få en form for output, som du kan bruge, nu som kunne være visuel inde i et IDE-udviklingsmiljø, hvor det kan give dig en histogram af ydeevnen for de forskellige kodelinjer, men det kan også stadig være, at det producerer en sporingsfil.
Profilere optrådte først i 1979. Så disse har været i lang tid også. Fantastisk til at finde ressourceforbrug eller præstationsproblemer, med andre ord den effektivitets ting. Generelt er det adskilt og adskilt fra debuggeren, selvom jeg har arbejdet med debuggers, der gør begge dele på samme tid. Og selvom profilere synes jeg er de mere interessante af de to værktøjer, hvis jeg føler, at der ikke er nok folk debug, så bestemt ikke nok folk profil, fordi en ud af ti debuggers vil profilere, ser det ud til. Og det er en skam, fordi profilering virkelig kan gøre en enorm forskel. Nu har databasesprog, som vi har talt om tidligere, fået SQL - og vi har slags tvunget den runde pind ind i det firkantede hul her og tvunget det til at blive et programmeringssprog - og Oracle.Det er PL / SQL - det er proceduremæssigt sprog SQL - og SQL Server, dets Transact-SQL, dets SQL-99, dets SQL / PSM - for, tror jeg, dets procedurer gemte modul. Postgres giver det et andet navn, DB2 endnu et navn, Informix, men pointen er, at alle har tvunget 3GL-konstruktioner; med andre ord, FOR sløjfer, ved variable erklæringer og alle de andre ting, der er fremmed for SQL, er nu en del af SQL på disse sprog. Og så skal du være i stand til at debugge en PL / SQL eller en Transact-SQL, ligesom du ville have et Visual Basic-program.
Nu, databaseobjekter, er dette vigtigt, fordi folk vil sige, ”Nå, hvilke ting skal jeg fejle i en database?” Og svaret er, ja, hvad du end kan gemme i databasen som kode - hvis jeg laver T- SQL eller PL / SQL - og jeg gemmer objekter i databasen, det er sandsynligvis en gemt procedure eller gemt funktion. Men der er også triggere: en trigger ligner en lagret procedure, men den skyder på en eller anden form for begivenhed. Nu vil nogle mennesker i deres triggere sætte en linje med kode og kalde en gemt procedure, så de opbevarer alle deres lagrede kode og procedurer, men det er det samme koncept: det er stadig den trigger, der kan være det, der initierer det hele. Og så som Oracle, har de noget, der kaldes en pakke, som ligner et bibliotek, hvis du vil. Du lægger 50 eller 100 lagrede procedurer i en gruppering, kaldet en pakke, så det er som et bibliotek. Så her er debuggeren på den gamle måde; dette er faktisk et værktøj, der rent faktisk vil gå ind og sætte alle disse fejlforklaringer i din kode til dig. Så overalt, hvor du ser fejlfindingsblok, må du ikke fjerne, automatisk debugger-start og -sporing, disse blev alle sat fast i et eller andet værktøj. Og linjerne uden for det, der er mindretallet af koden, ja, det er den ikke-manuelle fejlsøgningsmetode.
Og grunden til at jeg bringer dette op er, hvis du prøver at gøre dette for hånd, vil du faktisk skrive mere debugging-kode for at indsætte alle disse udsagn, end du er med koden. Så selvom dette muligvis fungerer, og selvom det er bedre end intet, er dette en meget vanskelig måde at fejlsøge, især da hvad så, hvis det har taget 10 timer for denne ting at køre, og hvor det har et problem, er i linje tre? Hvis jeg lavede en interaktiv fejlsession, ville jeg have kendt på linje tre - fem minutter ind i det - hej, der er et problem her, jeg kan afslutte. Men med dette var Ive nødt til at vente på, at den kørte, helt til færdiggørelse, og så fik Ive at se på en sporingsfil, der sandsynligvis har alle disse udsagn i sig, og prøve at finde nålen i høstakken. Igen, dette er bedre end intet, men det ville ikke være den bedste måde at arbejde på. Dette er, hvordan denne fil ville se ud, der kom fra det forrige dias; med andre ord, jeg kørte programmet, og det har lige fået en masse udsagn i denne sporfil, og jeg er måske eller måske ikke i stand til at sifere igennem dette og finde, hvad det er, jeg har brug for at finde. Så igen, jeg er ikke så sikker på, at det er sådan, du gerne vil arbejde.
Nu, interaktive debuggers - og hvis du har brugt noget som Visual Studio til at skrive programmer eller Eclipse, har du haft debuggers og du brugte dem med dine andre sprog - tænkte bare ikke at bruge dem herovre med din database. Og der er værktøjer derude, ligesom vores DB Artisan og vores Rapid SQL, dette er Rapid SQL her, som har en debugger, og du kan se til venstre, jeg har en gemt procedure kaldet "check for duplikater." Grundlæggende vil det bare gå og se og se, om jeg har flere rækker i tabellen med den samme filmtitel. Så databasen er til film. Og du kunne se i højre side, på den øverste tredjedel, jeg har fået min kildekode i midten, jeg har hvad der kaldes mine urvariabler og mine opkaldsstakke, og så i bunden har jeg nogle output s. Og hvad der er vigtigt her er, hvis du ser på den første røde pil, hvis jeg holder musen over en variabel, kan jeg faktisk se, hvilken værdi der er i den variabel på det tidspunkt, da jeg trækker gennem koden. Og det er virkelig nyttigt, og så kan jeg gå en linje ad gangen gennem koden, jeg behøver ikke at sige udføre, jeg kunne sige trin en linje, lad mig se hvad der skete, trin en anden linje, lad mig se hvad der skete, og Jeg gør dette i databasen. Og selvom jeg sidder på Rapid SQL på min pc, og min database er oppe i skyen, kan jeg stadig gøre den eksterne debugging og se den og kontrollere den herfra og foretage fejlsøgning, ligesom jeg ville gøre med ethvert andet sprog.
Nu, den næste pil der - du kan se den lille lignende pil, der peger til højre mod DBMS-output, det er, hvor min markør er i øjeblikket - så med andre ord, jeg har trådt, og det er, hvor jeg er i øjeblikket. Så hvis jeg siger, “Gå igen,” vil jeg gå til den næste linje. Nu lige under, vil du se den røde prik. Det er et gennembrud, der siger ”Hej, jeg vil ikke trække over disse linjer.” Hvis jeg bare vil hoppe over alt og komme til det sted, hvor den røde prik, kan jeg trykke på køreknappen, og den løber herfra enten til slutningen eller til et breakpoint, hvis der er indstillet nogen breakpoints, og så vil det stoppe og lade mig gøre det igen. Og grunden til at alt dette er vigtigt og kraftfuldt er, er fordi når jeg gør alt dette, hvad der sker i midten og endda i bunden - men vigtigst af alt i midten - vil ændre sig, og jeg kan se værdierne fra mine variabler, kan jeg se min opkaldssporingsspor, du ved, og så vises alle disse oplysninger der, når jeg går gennem koden, så jeg faktisk kan se og føle og få en forståelse af, hvad der foregår, og hvordan koden faktisk fungerer på udførelsestidspunktet . Og typisk kan jeg finde et problem, hvis der er et, eller hvis jeg er god nok til at fange det.
OK, nu skal jeg tale om en profiler, og i dette tilfælde er dette en profiler, som jeg kan se gennem en debugger. Kan du huske, at jeg nogle gange sagde, at de er separate, og nogle gange kan de være sammen? I dette tilfælde, og igen, er jeg i hurtig SQL, og jeg kan se, at der er en margin på venstre side ved siden af linjenumrene. Og hvad det er, er, det er antallet af sekunder eller mikrosekunder, det tog at udføre hver kodelinie, og det kan jeg se tydeligt, at al min tid tilbringes i denne FOR-loop, hvor jeg vælger alt fra en tabel. Og så er de, der sker inden i denne FOR-loop, sandsynligvis noget, jeg er nødt til at se på, og hvis jeg kan gøre det bedre, betaler det udbytte. Jeg vil ikke få nogen forbedringer ved at arbejde på de linjer, der har som 0,90 eller 0,86; der er ikke meget tid tilbragt der. Nu, i dette tilfælde og igen, I i hurtig SQL, ser du, hvordan jeg kan gøre profilering blandet med min fejlfinding. Nu, hvad der er rart er Rapid SQL giver dig også mulighed for at gøre det på den anden måde. Hurtig SQL giver dig mulighed for at sige: ”Ved du hvad? Jeg vil ikke være i debugger, jeg vil bare køre dette, og så vil jeg se grafisk eller visuelt på den samme type information. ”
Og du kan se, at jeg ikke længere er i fejlsøgningen, og det kører programmet, og efter at eksekveringen er afsluttet, giver det mig diagrammer til at fortælle mig ting, så jeg kan se, at jeg har fået en erklæring, der ser ud som om den tager det meste af kagen op og hvis jeg kigger, ser jeg på dette gitter mod bunden, linje 23, der er FOR-loop igen: han tager mest tid, han er faktisk den, at mørkerød tygger op hele cirkeldiagrammet. Og så er dette en anden måde at udføre profilering på. Vi kalder tilfældigvis denne "Code Analyst" i vores værktøj. Men det er dybest set bare en profiler, der er adskilt fra en debugger. Nogle mennesker kan lide at gøre det på den første måde, nogle mennesker kan lide at gøre det på anden måde.
Hvorfor foretager vi fejlsøgning og profilering? Det er ikke fordi vi ønsker at skrive verdens største kode og få en lønforhøjelse - det kan være vores grund, men det er ikke rigtig grunden til at du gør det - du lovede virksomheden, at du ville gøre noget korrekt, at dit program vil være effektivt. Det er hvad du bruger fejlsøgningen til. Derudover er forretningsbrugere; de er ikke meget tålmodige: De vil have resultater, selv før de trykker på tasten. Skulle læse deres sind og gøre alt øjeblikkeligt. Med andre ord, det skal være effektivt. Og det er det, vi ville bruge profilen til. Uden disse værktøjer tror jeg virkelig, du er denne fyr i dragt med pil og bue, og du skyder mod målet, og du er bind for øjnene. For hvordan skal du finde ud af, hvordan et program kører ved bare at se på statisk kode, og hvordan skal du finde ud af, hvilken linje der er, hvor det virkelig ville bruge mest tid i udførelse, igen, bare ved at se på statisk kode? En kodegennemgang kan muligvis ikke dukke op for nogle af disse ting, men der er ingen garanti for, at en kodevurdering finder dem alle. Ved hjælp af en debugger og profiler skal du være i stand til at finde alle disse fejl.
OK, jeg skal bare lave en rigtig hurtig demo her. Det er ikke min hensigt at skubbe produkt, jeg vil bare vise dig, hvordan en debugger ser ud, fordi mange gange folk vil sige, "Jeg har aldrig set en af disse før." Og det ser pænt ud på skærmens snap-slides, men hvad ser det ud, når det er i bevægelse? Så her på min skærm kører jeg vores DB Artisan-produkt; vi har også en debugger derinde. DB Artisan er beregnet mere til DBA'er, Rapid SQL er mere for udviklerne, men jeg har set udviklere, der bruger DB Artisan, og jeg har set DBA'er, der bruger Rapid. Så ikke blive fanget af produktet. Og her har jeg valget mellem at udføre en debug, men inden jeg starter debug, vil jeg udpakke denne kode, så du kan se, hvordan koden ser ud, før jeg begynder at køre den. Så her er den nøjagtige samme kode, der var i skærmbilledet, dette er min kontrol for dubletter. Og jeg vil fejlsøge dette, så jeg trykker på debug. Og nu tager det et øjeblik, og du siger, ”Nå, hvorfor tager det et øjeblik?” Husk ekstern fejlfinding: fejlsøgningen sker faktisk på min databaseserver, ikke på min pc. Så det måtte gå over og oprette en session derovre, oprette en fjernfejlfinding, koble min session til den eksterne debugging session og oprette en kommunikationskanal.
Så nu er min pil, det er der oppe øverst, efter linje en, det er, hvor jeg er i koden. Og hvis jeg trykker på det tredje ikon der, som er et trin ind, ser du pilen lige flyttet, og hvis jeg fortsætter med at trykke på den, vil du se den fortsætte med at bevæge sig. Hvis jeg nu ville gå helt ned til denne FOR-loop, fordi jeg ved, at det er, hvor problemet er, kan jeg indstille et brudpunkt. Jeg troede, jeg satte det. Åh skyde, jeg havde en af mine skærmfangsttaster kortlagt til den samme nøgle som fejlfinding, det er hvad der forårsager forvirringen. OK, så jeg bare manuelt indstiller et brudspunkt der, så nu i stedet for at gøre et skridt, trin, trin, trin, indtil jeg kommer dertil, kan jeg faktisk bare sige: ”Gå videre og kør denne ting,” og det vil stoppe. Bemærk, at det flyttede mig helt ned til hvor brudspunktet er, så jeg er nu i gang med at køre denne løkke, jeg kan se, hvad alle mine variabler er indstillet til, hvilket ikke er en overraskelse, fordi jeg initialiserede dem alle til nul. Og nu kan jeg gå ind i denne løkke og begynde at se på, hvad der sker inden i denne løkke.
Så nu kommer det til at foretage et udvalgt antal fra mine huslejer, og jeg kan slå musen over den fyr og se, han er to, to er større end en, så det vil sandsynligvis gøre det næste stykke af denne kode. Med andre ord fandt det noget. Jeg vil bare gå videre og lade det køre. Jeg vil ikke gennemgå alt her; hvad jeg vil vise dig er, når en debugger er færdig, den afsluttes lige som et normalt program. Ive fik indstillet breakpoint, så da jeg sagde løb, gik det bare tilbage til det næste breakpoint. Jeg lader det køre til slutningen, fordi det, jeg vil have dig til at se, er, at en debugger ikke ændrer programmets opførsel: Når det er færdigt, skal jeg få nøjagtigt de samme resultater, hvis jeg havde kørt det ikke inden for en debugger.
Og med det vil jeg stoppe demoen og gå tilbage, fordi vi vil sikre os, at vi har tid til spørgsmål og svar. Og så åbner jeg det for spørgsmål og svar.
Eric Kavanagh: Okay, Robin, måske et spørgsmål fra dig og derefter et par fra Dez?
Robin Bloor: Ja, bestemt, jeg finder det naturligvis fascinerende. Jeg har arbejdet med ting som dette, men jeg har aldrig arbejdet med noget lignende i databasen. Kan du give mig en idé om, hvad folk bruger profilen til? Fordi det er lignende, ser de på - fordi jeg formoder, at de er - de ser på præstationsproblemer, vil det hjælpe dig med at skelne mellem, hvornår en database tager tid, og når en kode tager tid?
Bert Scalzo: Du ved, det er et fantastisk spørgsmål. Lad os sige, at jeg arbejder i Visual Basic, og jeg, indeni min Visual Basic, skal kalde en Transact-SQL eller en PL / SQL. Lad mig gøre PL / SQL, da Oracle ikke altid spiller godt med Microsoft-værktøjer. Jeg profilerer muligvis min Visual Basic-kode, og profilen der kan sige, “Hej, jeg kaldte denne lagrede procedure, og det tog for lang tid.” Men så kan jeg gå ind på den lagrede procedure, og jeg kan udføre en databaseprofil på den gemte procedure og sige, "OK, ud af de 100 udsagn, der er her, her er de fem, der forårsagede problemet." Og så skal du muligvis udføre et tag-team, hvor du skal bruge flere profiler.
Ideen er, hvis du nogensinde får at vide, at ydelsesproblemet er i din database, en databaseprofil kan hjælpe dig med at finde nålen i høstakken, som udsagn faktisk er dem, hvor du har et problem. Jeg siger jer en anden ting, der dukkede op med profilering: Hvis du har et stykke kode, der bliver kaldt en million gange, men det kun tager et mikrosekund hver af de millioner gange, men det bliver kaldt en million gange, hvad profilen ville vise , den ting løb i så mange tidsenheder. Og selvom koden muligvis er meget effektiv, kan du muligvis se og sige, “Ooh, kaldte alt for ofte dette opkald til dette stykke kode. Måske skulle vi kun kalde det så ofte, snarere end hver gang vi behandler en post, ”eller noget. Og så kan du faktisk finde, hvor der er effektive kode, der lige kaldes for ofte, og det er faktisk et ydelsesproblem.
Robin Bloor: Ja, det er vidunderligt. Jeg har aldrig gjort dette. Du ser selvfølgelig, når jeg havde databaseproblemer, var det som om jeg på en eller anden måde enten skulle beskæftige sig med databasen eller beskæftige sig med kode; Jeg kunne aldrig håndtere dem begge på samme tid. Men der gjorde jeg igen ikke det - jeg har faktisk aldrig været involveret i opbygning af applikationer, hvor vi havde gemt procedurer, så jeg antager, at jeg faktisk aldrig har fundet problemer, der plejede at køre mig vild, ideen om, at du ville dele koden op mellem en database og et program. Men så gør alt - Jeg formoder, at svarene bliver ja, men dette er en del af et udviklingsholdsaktivitet, når du på en eller anden måde prøver at løse noget, der er ødelagt, eller måske forsøger at bringe en ny applikation sammen. Men skræddersyr det hele med alle de andre komponenter, jeg ville forvente i miljøet? Kan jeg forvente, at jeg kunne klippe dette sammen med alle mine testpakker og alt det andet, jeg ville lave, og med mine projektstyringsspørgsmål, er det sådan, alt dette klip sammen?
Bert Scalzo: Ja, det kan blive en del af enhver struktureret proces at gøre din programmerings- eller udviklingsindsats. Og det er sjovt, i sidste uge havde jeg en kunde, der byggede en webapplikation, og deres database historisk havde været lille, og så det faktum, at de ikke var meget gode programmerere, skadede dem aldrig. Nå, deres database er vokset i årenes løb, og nu tager det 20 sekunder på en webside, mellem når du siger, ”Log mig ind og giv mig nogle data at se”, og når skærmen faktisk kommer op, og så nu er det et ydelsesproblem. Og de vidste, at problemet ikke var på nogen af deres Java eller andre steder. Men de havde tusinder af lagrede procedurer, og så de var nødt til at begynde at profilere de lagrede procedurer for at finde ud af, hvorfor tager denne webside 20 sekunder at komme op? Og vi fandt faktisk, at de havde en kartesisk deltagelse i en af deres udvalgte udsagn og ikke vidste det.
Robin Bloor: Wow.
Bert Scalzo: Men nogen sagde en gang til mig: ”Nå, hvordan kunne de få et kartesisk medlem til og ikke kende det?” Og dette lyder virkelig forfærdeligt; nogle gange vil en programmør, der ikke er meget tilpas med SQL, gøre noget som at give mig en kartesisk deltagelse, men så kun give mig tilbage den første post, så jeg ved, at jeg har noget, og jeg har kun brug for den første. Og så ved de ikke, at de lige har bragt en milliard poster tilbage, eller de ser gennem en milliard poster, fordi de fik den, de var interesseret i.
Robin Bloor: Wow, jeg ved, det er hvad der hedder - ja, det var, hvad Dez foregik omkring, hvad angår folk, der ikke er lige så dygtige som måske de burde være, ved du. Hvis du er en programmør, skal du vide, hvad konsekvenserne af at udstede en kommando er. Jeg mener, der er ingen undskyldning for dette niveau af dumhed. Jeg formoder også, at du på en eller anden måde bare er sprogagnostisk med hensyn til dette, fordi det hele fokuserer på databasesiden. Har jeg ret i det? Er det lige det samme, hvad du bruger på kodningssiden?
Bert Scalzo: Absolut, du kan gøre dette i Fortran eller C eller C ++. Faktisk kan du på nogle Unixes endda gøre det for deres script-sprog; de leverer faktisk de samme værktøjer. Og så vil jeg gå et øjeblik tilbage efter det, du sagde uden undskyldning. Jeg vil give programmererne en pause, fordi jeg ikke kan lide at kaste programmerere under bussen. Men problemet er virkelig det akademiske miljø, for når du går i gang for at lære at være programmerer, underviste du i rekord-på-en-gang-tænkning. Du undervises ikke i sæt tænkning, og det er det, Structured Query Language, eller SQL fungerer med sæt; Derfor har vi fagforeningen, krydset og minus-operatøren. Og det er meget svært undertiden for en person, som aldrig har tænkt i form af sæt, at stoppe, give slip på rekord-til-en-gang-behandling og arbejde med sæt.
Robin Bloor: Ja, jeg er med dig om det. Jeg mener, jeg får nu, det er et uddannelsesspørgsmål; Jeg tror, det er helt et uddannelsesspørgsmål, jeg synes, det er naturligt for programmører at tænke procedurelt. Og SQL er ikke proceduremæssigt, dets erklærende. Du siger faktisk bare, "Dette er hvad jeg vil have, og jeg er ligeglad med, hvordan du gør det," ved du? Mens du med programmeringssprog ofte har dine ærmer rullet op og du er nede i detaljerne for endda at styre tællingerne, mens du laver en løkke. Ill hånd på—
Bert Scalzo: Nej. OK, fortsæt.
Ja, jeg ville sige, at du bragte op et andet eksempel på, at en profiler ville være god til at fange den, slags fortsætter med denne record-at-a-time-behandling. Nogle gange kan en programmør, der er god til en registrering-til-tid-logik, ikke finde ud af, hvordan man gør SQL-program. Lad os sige, at han laver to FOR-sløjfer og dybest set gør en sammenføjning, men han gør det på klientsiden. Så gør han den samme effekt som en sammenføjning, men han gør det selv, og en profil kan fange det, fordi du sandsynligvis ville ende med at bruge mere tid på at gøre en sammenkobling manuelt end at lade databaseserveren gøre det for dig.
Robin Bloor: Ja, det ville være en katastrofe. Jeg mener, du ville bare smadre rundt. Thrashings altid dårligt.
Alligevel går jeg videre til Dez; Jeg er sikker på, at han fik nogle interessante spørgsmål.
Dez Blanchfield: Tak, ja, det gør jeg. Jeg kommer med dig i de ikke kaster programmerere under bussen. Jeg mener, jeg har brugt for mange år i mit liv på at være en kode selv, på alle niveauer, ved du, om det er som du sagde, siddende på kommandolinjen på Unix-maskinen, og i nogle tilfælde var jeg endda involveret i en et par forskellige Unix-porte fra en hardwareplatform til en anden. Og du kan forestille dig de udfordringer, vi havde der. Men virkeligheden er heres, der får-out-of-fængsel-kortet for enhver coder og scripter i verden. Det er en raketvidenskab, bogstaveligt talt, at skrive virkelig stramt hver gang, hele tiden, er en raketvidenskab. Og berømte historier om mennesker som Dennis Ritchie og Brian Kernahan, der uafhængigt arbejder på et stykke kode og derefter dukker op til en kodevurderingschat over en kaffe og finder ud af, at de skrev nøjagtigt det samme stykke kode, i nøjagtigt det samme program, i nøjagtigt den samme måde. Og de gjorde det i C. Men det puristiske programmeringsniveau findes meget sjældent.
Faktum er, at der hver dag kun er 24 timer i døgnet, syv dage i ugen, og vi er bare nødt til at få ting gjort. Og så, når det kommer til ikke kun traditionelle programmerere, DBA’erne og kodere og scriptere og sysadmin og netværksadministratorer og sikkerhedspersonale og alt hele vejen igennem til borgerdatasiden i disse dage; vi hører, alle prøver bare at gøre deres job. Og så jeg tror, at den store takeaway fra hele denne ting er, at jeg elskede din demo, og jeg elskede afhentningen, som du forlod os med der, for lige et øjeblik siden, hvor jeg talte med Robin om det faktum, at dette har en bestemt - måske ikke så meget en niche - men et bredt rum, som det gælder for så vidt angår fastsættelse af kode og SQL og databaser. Men jeg var virkelig spændt over at høre dig sige, at du kunne stikke det på et shell-script og finde nogle problemer, fordi du ved, i dagens dag og alder arbejdede det altid til den laveste pris på alt.
Årsagen til at du kan købe en $ 6-skjorte et eller andet sted, er fordi nogen har bygget et system billigt nok til rent faktisk at fremstille og sende og logistisk levere og sælge og sælge og sælge og betale onlinebetalinger for at få den $ 6-shirt. Og det sker ikke, hvis du har fået folk til at blive betalt $ 400.000 om året for at skrive kode på den perfekte måde; det er bare hele udviklingen. Så det punkt antager jeg, at et af de spørgsmål, som jeg virkelig elsker dig for bare at give os lidt mere indsigt, er bredden og rækkevidden af den type mennesker, du ser i øjeblikket, der implementerer disse slags værktøjer til at profilere en kode og se til præstationsproblemer? Oprindeligt, historisk, hvor kommer de fra? Har de været de store ingeniørhuse? Og så er det tilfældet fremover, har jeg ret i at tænke på, at flere og flere virksomheder implementerer dette værktøj, eller disse værktøjer, til at prøve at hjælpe kodere, som de ved, hvem der bare gør tingene gjort for at få jobbet færdigt og få den ud af døren? Og nogle gange har vi brug for et get-out-of-prison-kort? Har jeg ret i at tænke på, at vi historisk set havde et mere teknisk fokus og udvikling? At der nu blev en mindre, som Robin sagde, akademisk tilgang, og nu dens selvlærte eller klip-og-indsæt kode, eller bare få tingene bygget? Og stemmer det overens med den slags mennesker, der tager produktet på nu?
Bert Scalzo: Ja, nøjagtigt. Og jeg giver dig et meget specifikt eksempel, vi vil bare få gjort jobbet, fordi forretningsfolkene ikke ønsker perfektion. Det er som et edb-skakspil: skakspelet ser ikke efter det perfekte svar; det ser efter et svar, der er godt nok på en rimelig tid, så det er, hvordan vi programmerer. Men hvad jeg finder nu, er, at de fleste mennesker i stedet for at sige, at de vil have en profiler, som en del af deres enhedsprøvning - hvilket er, hvordan jeg ville gøre det, fordi jeg ikke ser det som spild af tid - hvad der sker, er nu det, der bliver gjort senere, undertiden under integrationstest eller stresstest, hvis de var heldige. Men de fleste af de gange, det var en del af en eskalering, hvor der var gået i produktion, løb den et stykke tid, måske endda løb i årevis, og nu kører den ikke godt, og nu profilerer den godt. Og det ser ud til at være det mere almindelige scenario nu.
Dez Blanchfield: Ja, og jeg tror, at udtrykket "teknisk gæld" sandsynligvis er en, du er mere end bekendt med; Jeg kender Robin, og det er jeg bestemt. Jeg tror, i disse dage, især i agile tilgange til udvikling og systemopbygning, for mig er begrebet teknisk gæld nu en meget rigtig ting, og vi redegør faktisk for det i projekter. Jeg ved, jeg mener, vi har fået vores egne projekter som medieobjektivet og andre, hvor vi har fået kodning sker dagligt, og forskellige ting i hele Bloor-gruppen. Og når vi bygger noget, så kigger vi på det, jeg ser på det og ser altid på det synspunkt, hvad det koster mig at rette op lige nu, mod kan jeg bare få det i dåsen og få det derude, og se derefter og se, om disse ting går i stykker. Og arve denne tekniske gæld, som jeg ved, at jeg er nødt til at cirkulere tilbage senere og ordne det.
Og jeg mener, jeg har gjort det i de sidste syv dage: Jeg har skrevet et par værktøjer og manuskripter, jeg har skrevet et par stykker af Python-sprog, og jeg har brugt det til Mongo bagenden, og sørget for, at det er pænt og rent og sikkert, men det bliver bare den forespørgsel, jeg har brug for, vel vidende, at jeg har brug for denne funktion til at arbejde, for at komme til det større puslespil; det er, hvor min rigtige smerte er. Og så pådrager du dig denne tekniske gæld, og jeg tror, at dette ikke kun er en lejlighedsvis ting, jeg tror, at dette er en del af DNA'et ved at udvikle sig nu. Folk bare - ikke uanstændigt - de accepterer bare, at den tekniske gæld er en normal modus operandi-type emission, og de er bare nødt til at pådrage sig den. Det er, hvor du pådrager dig den tekniske gæld. Og jeg synes, det gode ved det, du viste os i demoen, var, at du bogstaveligt talt kan profilere og se, hvor lang tid noget tager at køre. Og det er sandsynligvis en af mine yndlings ting. Jeg mener, jeg har faktisk bygget profileringsværktøjer - vi byggede værktøjer i Sed og Lex og Orc til at køre vores kode og se, hvor løkkerne var, før værktøjer som dette var tilgængelige - og når du har bygget kode til at gå og gennemgå din egen kode , bliver du meget god til ikke at skulle gennemgå din egen kode. Men det er ikke tilfældet nu. Med det i tankerne, er der et bestemt markedssegment, der tager dette op mere end noget andet? Ser ud som en masse -
Bert Scalzo: Åh ja, jeg har - Jeg vil tegne en analogi for dig og vise dig, at ikke-programmerere gør det hele tiden. Årsag, hvis jeg nogensinde underviser i en debugger og profilering klasse eller session, jeg spørger folk, "OK, hvor mange mennesker herinde går ind i Microsoft Word og med vilje aldrig bruger stavekontrollen?" Og ingen lægger deres hånd op, for til at skrive dokumenter, vi ved alle, at vi kan lave engelske fejl, og derfor bruger alle stavekontrollen. Og jeg sagde: ”Nå, hvordan er det, når du skriver i din IDE som Visual Basic, du ikke bruger debugger? Det er den samme ting, det er som en stavekontrol. ”
Dez Blanchfield: Ja, faktisk er det en fantastisk analogi. Jeg havde virkelig ikke tænkt over, jeg må indrømme, at jeg faktisk gør noget lignende med et par værktøjer, jeg bruger. Faktisk, en, ODF, min favorit med Eclipse er bare at klippe og indsætte kode derinde og gå på udkig efter ting, der bare fremhæver med det samme og indse, at jeg lavede en skrivefejl i et eller andet klassekald. Og men det er interessant nu med værktøjet som dette, kan du gøre det i realtid i modsætning til at vende tilbage og se på det senere, hvilket er slags rart at fange det på forhånd. Men ja, det er en fantastisk analogi at bare sætte en tekstbehandler i, forårsage det er et interessant wake-up call, bare indse, at du har lavet nogle skrivefejl eller endda en grammatisk fejl, ikke?
Bert Scalzo: Nemlig.
Dez Blanchfield: Så ser du mere af en uptick nu fra jeg antager, det sidste spørgsmål fra mig, før jeg måske kaster til vores spørgsmål og svar for vores deltagere. Hvis du skulle give en slags anbefaling omkring fremgangsmåden til at gøre dette - Jeg antager, at dette er retorisk - er det således, at du kommer ind tidligt og får dette implementeret som du udvikler dig, før du udvikler dig? Eller er det tilfældet, at du overvejende får bygning, kommer i bevægelse, bygger noget og kommer ind og profilerer det senere? Jeg formoder, at det er tilfældet med at komme tidligt ind, og sørg for, at dine koder ryddes på forhånd. Eller er det sådan, at de skal overveje denne del af deres post-implementering?
Bert Scalzo: Ideelt set ville de gøre det på forhånd, men fordi alle er i den travle, travle verden, hvor de bare skulle få gjort ting, har de en tendens til ikke at gøre det, før de løber ind i et ydelsesproblem, som de ikke kan løse ved at tilføje flere CPU'er og hukommelse til en virtuel maskine.
Dez Blanchfield: Ja. Så faktisk nævnte du noget interessant, hvis jeg hurtigt kan? Du nævnte før, at dette kan køres hvor som helst og kan tale med databasen i bagenden. Så dette er komfortabelt med den slags bimodale koncept, vi taler om nu, af skyen på stedet / off-premise, ved tingene også, i slutningen af dagen, hvis det kan tale med bagenden og se koden, er det virkelig ligeglad, gør det det?
Bert Scalzo: Præcis, ja, du kan køre dette i skyen.
Dez Blanchfield: Fremragende, for jeg tror det er sådan, hvor vores nye modige verden bevæger sig. Så Eric. Jeg vil kaste tilbage til dig nu og se, at vi har fået et par spørgsmål her, og jeg vil have, at vores deltagere stadig skal være hos os, selvom vi er gået forbi timen.
Eric Kavanagh: Ja, der er et par folk derude, jeg skal bare komme med en hurtig kommentar: Bert, jeg synes, at metaforen, den analogi, du giver ved brug af stavekontrol, er helt ærligt strålende. Det er en blog eller to værd, helt ærligt, fordi det er en god måde at ramme indholdet af, hvad det er, du laver, og hvor værdifuldt det er, og hvordan det virkelig skal være den bedste praksis at bruge en debugger på en regelmæssigt, ikke? Jeg ved, at du får nogle hoveder, der nikker, når du kaster den ud, ikke?
Bert Scalzo: Absolut, fordi det, jeg siger dem, er: ”Hvorfor kører jeg en stavekontrol på mine dokumenter? Jeg vil ikke være flov over dumme stavefejl. ”Nå, de vil ikke være flov over dumme kodningsfejl!
Eric Kavanagh: Ret. Ja bestemt. Nå, folkens, vi har brændt en times tid og fem minutter her, så stor tak til alle jer derude for jeres tid og opmærksomhed. Vi arkiverer alle disse webchats, er du velkommen til at komme tilbage når som helst og tjekke dem ud. Det bedste sted at finde disse links er sandsynligvis techopedia.com, så tilføj dette til denne liste lige her.
Og med det ville jeg tage farvel, folkens. Endnu en gang, fantastisk job, Bert, tak til vores venner fra IDERA. Godt at tale med dig næste gang, snak med dig næste uge, faktisk. Pas på! Hej hej.