Af Techopedia Staff, 15. marts, 2017
Takeaway: 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, at 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 vi taler om fejlsøgning. 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å vi taler om "Hurtig respons: Fejlsøgning af databaser og profilering til redning."
Der er virkelig et sted om dit, slå mig op på Twitter, @eric_kavanagh selvfølgelig.
Dette år er varmt. Og debugging bliver varmt, uanset hvad. Det vil virkelig være et af disse problemer, der aldrig vil forsvinde, uanset hvor gode vi får til dette, er der 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?
Vi hører fra Dr. Robin Bloor, derefter 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: OK. Dette er et interessant emne. Jeg tænkte, fordi Dez sandsynligvis vil gå videre med de faktiske teknikker og krigshistorier om fejlsøgning, jeg tænkte, at jeg bare ville tage en baggrundssamtale, så vi skulle få et fuldt afrundet billede af, hvad der foregår. Jeg gjorde dette længe, og jeg plejede at være en kodning, så det er som, og jeg var næsten fristet med denne præsentation til at begynde at vokse lyrisk om ideen om open source, men jeg troede, at jeg overlader det til nogen anden.
Her er en liste over berømte bugs, og de fleste af disse kommer ind på nogens top liste, dybest set alle 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 tilfældet. 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 alles - det tilsyneladende forårsagede skade på 100 millioner dollars; det er selvfølgelig et skøn. 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 er 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 det alligevel. Jeg troede, at jeg ville tale om impedansforholdet 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 særlig godt til tabeller. Og på grund af dette 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 kaste data frem og tilbage til et program.
For nogle af funktionaliteterne var ekstremt dataspecifikke, så det var ikke kun referencemæssig integritet og cascading sletninger og lignende ting, databasen tog sig af alt det pludselige, du lægger funktionalitet i en database, hvilket naturligvis betød at funktionaliteten til en applikation kan 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 databasespillet, fordi det betyder, at du f.eks. Har fået en masse implementeringer, 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 skal være ret smart til at gøre forskellige ting.
Jeg troede, at jeg også ville tale 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 ydelsen på grund af låsning . Ideen ville være, at koderen ikke behøver at være bekymret for ydeevne, og databasen faktisk ville fungere rimeligt godt. Det skal formes, at 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. Uanset hvad, det er 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, at det er som alle situationer i debugging, som jeg nogensinde 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 det, du ser på, korrupte data, og du tænker: "Hvordan fanden skete det?"
Under alle omstændigheder skal jeg 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å ved, hold på.
Automatisk stemme: Deltagerlinier er slået fra.
Eric Kavanagh: Okay, hold på et sekund, 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 vil tilgive ordspillet, undskyld at jeg ikke kunne hjælpe mig med den. 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 et tilfælde af 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, at omkring 9. september 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 maskinen - 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 bogstaveligt talt var en møll - angiveligt der var en møl, der var kilet ind mellem et stykke kobbertråd, der gik 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 en bug bliver fundet", ikke citerer.
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 forsøg på 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 er ikke blevet profileret, bare find ting som uendelige sløjfer, der bare går intet sted.
Men vi har også et scenarie, og jeg tænkte, at jeg ville sætte et par sjove lysbilleder i, inden jeg begyndte at gå nærmere ind. Her er den klassiske tegneserie, kaldet XKCD på nettet, og tegneserieskaberen har nogle ret sjove synspunkter på verden. Og denne handler om et barn kaldet “Lille Bobby Tables” og angiveligt navngivet hans forældre denne unge dreng Robert '); DROP TABEL Studenter; - og det hedder, og slags "Hej, dette er din søns skole, der har nogle problemer med computeren, " og forælderen svarer, "Åh kære, brød han 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 fortæller de, at de nu har mistet årets studenterrekorder, 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åvel.
En anden sjov, jeg ved ikke, om dette er ægte eller ej - jeg formoder, at det er en falsk - men igen, det rører også min sjove knogle. Nogen ændrer nummerpladen på fronten af 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 ældre for mig, jeg er sikker; Robin, du er velkommen til at stikke sjov på mig for dette - men historisk set er jeg kommet fra en baggrund i en alder af 14 år og vandrede ned ad slutningen af byen og bankede på døren til et datacenter kaldet “Data Com” i nyt Sjælland og spørge, 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 printere og 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 132-søjles fysisk printer. Tænk i bund og grund på som 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 og gør 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 udskrive linjen og derefter skrive den ind igen. Men engang var det sådan, vi skrev kode, og det er 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 vi er 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 lige det samme du gjorde på papirbåndet slags trykt format bare på en CRT, men du var i stand til lettere at slette, og du havde ikke den "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, at fra min baggrund var jeg 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 gjorde det introducer buggy-kode.
Programmeringsmetoder i disse dage, f.eks. Struktureret forespørgsel, SQL, det er et meget kraftfuldt, enkelt forespørgselssprog. Men vi har forvandlet det til et programmeringssprog, og jeg tror ikke rigtig, 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, fordi 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æledyrspis, jeg har for eksempel med SQL-folk, der springer 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 andre udfordringer, for eksempel i disse dage skynder vi os alle mod 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 bruger lavere -betalt personale. Og det mener jeg ikke på en urimelig måde, men vi ansætter 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 lavet 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 har haft mange års erfaring, ikke nødvendigvis har haft 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, 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 rydde op. ”Og så har SQL det problem, og det er meget, meget let at lære, det er meget nemt 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 bruge det programmeringssprog, du kender til, til at gøre datamanipulationen i stedet for 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 skyldes, at 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 virkelig ekstremt eksempel, men du får pointen ud af alt det. Så for bare virkelig at slå dette punkt hjem, her er et eksempel, som jeg bærer rundt på meget. 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 er sikker på, at vi alle kender. Og til venstre er der et stykke SQL, der faktisk gengiver 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 programmeringsmetodik, der anvendes på et sprog, og det er så meget let for dårlig programmeringspraksis, manglende erfaring, klip-og-indsæt kode, lavtlønnet personale, der prøver 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 bare, det er lidt sød, og du tænker, “Wow, hvad en fantastisk grafik, jeg ville meget gerne 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 er vendt, det skulle være en sort baggrund og grøn tekst for 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 til at være i stand til at fange disse ting, og de kommer i produktion, og så har du 100.000 mennesker ved at ramme 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 webadressen er der, du kan gå og kigge - det kaldes den den mest komplekse SQL-forespørgsel, du nogensinde har skrevet. For tro mig, det samles faktisk, det løber. 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 sammen over en periode på tre til fem minutter for at ringe tilbage, hvad er en tekstlinie.
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 ved hånden, når 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 sagt tidligere kunne du engang gøre det ved at se på en grøn skærm. Du kan ikke mere; der er hundredtusinder af kodelinjer, der er titusinder af apps, der er indsat, der er millioner af databaser i nogle tilfælde, og endda supermennesker kan faktisk ikke gøre dette i hånden mere. 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, jeg tror, at vi er ved at modtage. Eric, jeg vil vende tilbage.
Eric Kavanagh: OK, Bert, tag den væk.
Bert Scalzo: OK, tak. Bert Scalzo her fra IDERA, jeg er produktchef for vores databaseværktøjer. Og jeg vil tale om debugging. Jeg tror, en af de vigtigste ting, som Robin sagde tidligere - og det er meget sandt, er, at fejlsøgning er besværlig og ikke-triviel, og når du går til database-debugging er det en størrelsesorden endnu mere besværlig og ikke-triviel - så det var et vigtigt tilbud.
OKAY. Jeg ville starte med programmeringshistorien, fordi jeg ofte ser mennesker, der ikke debugger, de bruger ikke en debugger, de programmerer kun med det sprog, de bruger, og mange gange vil de sige til mig, ”Nå, disse fejlfindings 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 forhistorik, alderdom, middelalder, det er venligt at sige, hvor var vi med hensyn til 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å for at sige, "Hej, jeg bruger ikke en debugger, fordi det er en af de nye ting, " så skal du være begyndt at programmere, ved du, tilbage i 1950'erne, fordi det er den eneste måde du slipper af med påstanden.
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 lidt sjovt. Og så den anden ting, jeg lo af, var at han talte om teletyper, og jeg sad der og sagde: ”Mand, det var det største spring, vi nogensinde har haft inden for produktivitet, 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 et CDC, Control Data Corporation, så jeg antager, 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 her, 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 kunne regne, at det som en fejlfinding er en smule sværere, en måde at gøre det på, men det tæller. Men også vi har den berømte udskrivning: du ser, og folk lægger faktisk udskrivningsangivelser 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, du trykker på en knap, og den klæber udskriftsangivelser 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 debuger.
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 at vi har gået glip af et forretningskrav, men hvad det er, er koden ikke effektiv; det gør ikke, som vi forventede, at det skulle gøre. Den anden gang vi går, og vi foretager fejlsøgning, er det for effektivitet, og det kan være en logisk fejl, men hvad det er, er, at jeg gjorde det rigtige, det kommer bare ikke hurtigt nok tilbage. Nu gør jeg dette punkt, fordi en profiler sandsynligvis er bedre for det andet scenarie, og vi vil 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 fjernfejlsøgning. Du er måske ikke klar over det, men det er hvad der sker. Og så er det meget almindeligt med disse debuggers at have break-point, se point, træde ind og træde 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 arbejdsmængde er fanget og gentaget, hvor det fanger alt, det, der tæller som profilering. Min erfaring har været mere, det er bedre, hvis det er udført prøveudtagning. Der er ingen grund til at fange hver eneste udsagn, fordi nogle udsagn måske bare løber 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, 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 proceduresprog SQL - og SQL Server, det er Transact-SQL, det er SQL-99, det er SQL / PSM - for, tror jeg, det er Procedure Stored Module. 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 lagrer objekter i databasen, det er sandsynligvis en gemt procedure eller gemt funktion. Men der er også triggere: en trigger ligner en gemt procedure, men den skyder på en eller anden form for begivenhed. Nogle mennesker i deres triggere vil nu sætte en kodelinje 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 lidt 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, som er mindretallet af koden, ja, det er den ikke-manuelle fejlsøgningsmetode.
Og grunden til, at jeg bringer dette op, er, at hvis du prøver at gøre det manuelt, vil du faktisk indtaste mere fejlfindingskode for at indsætte alle disse udskrivningsangivelser, 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 nu hvis det tager 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 er jeg nødt til at vente på, at den kører, hele vejen til færdiggørelse, og så er jeg nødt til at se på en sporingsfil, der sandsynligvis har alle disse trykte udsagn i sig, og prøve at finde nålen i høstak. Igen er dette 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 et stykke udskrivningsangivelser i denne sporfil, og jeg er måske eller måske ikke i stand til at trække 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 har 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 min kildekode i midten, jeg har hvad der kaldes mine urvariabler og mine opkaldsstakke, og så i bunden jeg ' Vi har fået nogle outputmeddelelser. 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 denne variabel på det tidspunkt, da jeg går 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 det 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 der, hvor min markør er i øjeblikket - så med andre ord, jeg er trådt, og det er, hvor jeg er ved øjeblikket. Så hvis jeg siger, ”Gå igen, ” går jeg til den næste linje. Nu lige nedenfor ser du den røde prik. Det er et gennembrud, der siger ”Hej, jeg vil ikke gå 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 vil køre 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 magtfuldt er, er, at når jeg gør alt dette, sker det, der sker i midten og endda i bunden - men vigtigst af alt i midten, og jeg kan se værdierne fra mine variabler, Jeg kan se min opkaldssporingsspor, du ved, og så vises alle disse oplysninger der, mens 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 er arbejder på udførelsestid. 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. Husk jeg sagde, at nogle gange er de separate, og nogle gange kan de være sammen? I dette tilfælde, og igen, er jeg i Rapid SQL, og jeg kan se, at der er en margin i venstre side ved siden af linjenumrene. Og hvad det er, er, at det er antallet af sekunder eller mikrosekunder, det tog at udføre hver kodelinje, og det kan jeg se tydeligt, at al min tid tilbringes i denne FOR-loop, hvor jeg vælger alt fra en tabel . Og hvad der sker inden for denne FOR-loop er 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 der er brugt. Nu, i dette tilfælde, og igen, jeg er i Rapid SQL, ser du, hvordan jeg kan gøre profilering blandet med min fejlfinding. Hvad, der er rart, er, at Rapid SQL også giver dig 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 debuggeren, 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 debuggeren, og at den 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 en erklæring, der ser ud til, at den tager op det meste af cirkeldiagrammet, og hvis jeg ser, ser jeg på det gitter mod bunden, linje 23, der er FOR-loop igen: han tager mest tid op, han er faktisk den, at mørkerødt tygger op alt 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 profil, 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 vil 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. Vi skal læse deres sind og gøre alt med det samme. Med andre ord skal det være effektivt. Og så, det er hvad vi ville bruge profilen til. Uden disse værktøjer tror jeg virkelig, at 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 kodeanmeldelse kan muligvis ikke dukke op for nogle af disse ting, men der er ingen garanti for, at en kodegennemgang 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 hvordan 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å lad dig ikke få fat på produktet. Og her har jeg valget mellem at udføre en debug, men inden jeg starter debug, skal 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, her er min pil, den er der oppe øverst, efter linje en, det er her jeg befinder mig i koden. Og hvis jeg trykker på det tredje ikon der, som er et trin ind, ser du den pil, der lige er 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 debugger, det er hvad der skaber forvirring. 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 en sammenhæng med at køre denne loop, 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 foregår inde 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. Jeg har 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 med at køre, skulle jeg få nøjagtigt de samme resultater, hvis jeg havde kørt det ikke inde i en debugger.
Og med det vil jeg suspendere 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 selvfølgelig 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 som, 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 indeni min Visual Basic kalder jeg en Transact-SQL eller en PL / SQL. Lad mig gøre PL / SQL, da Oracle ikke altid spiller godt med Microsoft-værktøjerne. 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, vi kalder 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 effektiv 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 noget - 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 delte koden op mellem en database og et program. Men så gør alt - jeg formoder, at svaret 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 prøver at bringe en ny ansøgning 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 rigtig 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 i nogen af deres Java eller nogen af disse 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å en kartesisk tilslutning og ikke kende det?” Og dette vil lyde 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 fik noget, og jeg har kun brug for den første. Og så er de ikke klar over, 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 hedder det - ja, det var hvad Dez foregik omkring, hvad angår folk, der ikke er lige så dygtige som de måske skulle være, ved du. Hvis du er en programmør, skal du vide, hvad konsekvenserne af at udstede en kommando er. Jeg mener virkelig, 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 bare det samme, uanset 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, for jeg kan ikke lide at smide programmerere under bussen. Men problemet er virkelig det akademiske miljø, for når du lærer at være programmerer, undervises du i rekord-til-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 nogle gange er det meget svært for en person, der 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, det får jeg nu, det er et uddannelsesproblem; Jeg tror, det er fuldstændigt et uddannelsesspørgsmål, jeg synes, det er naturligt for programmerere at tænke procedurelt. Og SQL er ikke proceduremæssigt, det er erklærende. Du siger faktisk bare, "Det er dette, jeg vil, og jeg er ligeglad med, hvordan du gør det, " ved du? Mens du med programmeringssprog ofte har dine ærmer rullet sammen, og du er nede i det mindste om endda at styre tællingerne, mens du laver en løkke. Jeg vil give videre til-
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å han gør den samme effekt som en sammenføjning, men han gør det selv, og en profil vil fange det, fordi du sandsynligvis ville ende med at bruge mere tid på at gøre en sammenbinding 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. Thrashing er altid dårlig.
Jeg vil uanset videregive til Dez; Jeg er sikker på, at han har 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 koder 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 et par forskellige havne af Unix fra en hardwareplatform til en anden. Og du kan forestille dig de udfordringer, vi havde der. Men virkeligheden er her, at få-out-of-fængsel kortet for alle kodere 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 fandt ud af, at de havde skrevet nøjagtigt det samme stykke kode, i nøjagtigt det samme program, på nøjagtig 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 skal bare 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 begejstret over at høre dig sige, at du kunne stikke det i et shell-script og finde nogle problemer, fordi du ved, i dagens dag og alder arbejder vi 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 får 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, jeg virkelig vil elske, bare giver os lidt mere indsigt, er, hvad bredden og rækkevidden er for den type mennesker, du ser i øjeblikket, der implementerer disse slags værktøjer til profilering en kode og kigge efter ydelsesproblemer? 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 vi nu får en mindre, som Robin sagde, akademisk tilgang, og nu er det selvlært, 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 vil give dig et meget specifikt eksempel, vi vil bare få jobbet gjort, fordi forretningsfolk ikke ønsker perfektion. Det er på samme måde 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 sådan 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 når det sker senere, undertiden under integrationstest eller stresstest, hvis vi er heldige. Men de fleste af de gange er det en del af en eskalering, hvor noget er gået i produktion, det løb et stykke tid, måske endda løb i årevis, og nu løber det ikke godt, og nu skal vi profilere det. 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 et, du er mere end fortrolig 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 vores egne projekter som medieobjektivet og andre, hvor vi har kodning, der sker dagligt, og forskellige ting i hele Bloor-gruppen. Og hver gang vi bygger noget, ser vi slags på, jeg ser på det og ser altid ud fra synspunktet om, hvad det koster mig at løse dette lige nu, mod kan jeg bare få det i kan og få den derude, og så se og se, om denne ting vil gå i stykker. Og arve denne tekniske gæld, som jeg ved, at jeg bliver nødt til at cirkulere tilbage senere og ordne det.
Og det mener jeg, 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 Python-sprog, og jeg har brugt det til Mongo back end sikker på, 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 for at arbejde, for at komme til det større puslespil; det er her, 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 her du har 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 plejede at bygge 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, du bliver 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 til 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, vil jeg spørge folk, "OK, hvor mange mennesker herinde går ind i Microsoft Word og målrettet bruger aldrig stavekontrollen?" Og ingen lægger deres hånd op, for ved skrivning af dokumenter ved vi alle, at vi kan begå fejl i engelsk, og derfor bruger alle stavekontrollen. Og jeg sagde: ”Nå, hvordan er det, når du skriver tekst 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 ikke rigtig tænkt på, 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 tekst i en tekstbehandler, fordi det er et interessant wake-up call, bare indse, at du har lavet nogle skrivefejl eller endda en grammatisk fejl, ikke?
Bert Scalzo: Præcis.
Dez Blanchfield: Så ser du mere af en uptick nu, tror jeg, det sidste spørgsmål fra mig, inden jeg kaster til vores spørgsmål og svar måske 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, når 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 din kode er ren 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 skal få ting gjort, har de en tendens til ikke at gøre det, før de løber ud i et ydelsesproblem, som de ikke kan løse med tilføjelse af 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 ligeglad, gør det ikke?
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 et par spørgsmål her, og jeg vil have, at vores deltagere stadig skal være hos os, selvom vi er gået i timen.
Eric Kavanagh: Ja, der er et par folk derude, jeg vil 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 indramme konteksten af, hvad det er, du laver, og hvor værdifuldt det er, og hvordan det virkelig skal være en god praksis at bruge en debugger 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: Okay. Ja bestemt. Nå, folkens, vi har brændt gennem en time 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å vi tilføjer dette til denne liste lige her.
Og med det tager vi farvel, folkens. Endnu en gang, fantastisk job, Bert, tak til vores venner fra IDERA. Vi vil tale med dig næste gang, vi vil faktisk tale med dig næste uge. Pas på! Hej hej.
