Av Techopedia Staff, 15. mars 2017
Takeaway: Vert Eric Kavanagh diskuterte feilsøking og profilering av databaser med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bert Scalzo.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, mine damer og herrer, det er 4:00 østlig tid på en onsdag, og det betyr selvfølgelig.
Robin Bloor: Kan ikke høre deg, Eric.
Eric Kavanagh: Jeg var der for dager siden, så du er ikke alene. Men så temaet i dag er virkelig interessante ting. Det er den slags ting du vil være sikker på at skjer i bakgrunnen hos selskapet ditt, med mindre du er personen som gjør det, i så fall vil du forsikre deg om at du gjør det ordentlig. Fordi vi snakker om feilsøking. Ingen liker feil, ingen liker når programvaren slutter å fungere - folk blir urolige, brukere blir uvennlige. Det er ikke bra. Så vi kommer til å snakke om "Rapid Response: Database Debugging and Profiling to the Rescue."
Det er et sted om ditt virkelig, slo meg opp på Twitter, @eric_kavanagh selvfølgelig.
Dette året er varmt. Og feilsøking kommer til å bli het, uansett hva. Det vil virkelig være et av disse problemene som aldri kommer til å forsvinne, uansett hvor gode vi får til dette, vil det alltid være problemer, så nøkkelen er hvordan kommer du til der du kan løse disse problemene raskt? Ideelt sett har du gode programmerere, flotte miljøer, der ikke for mye går galt, men som det gamle ordtaket sier: “Ulykker skjer i det beste for familiene.” Og det samme gjelder for organisasjoner. Så dette skjer, det kommer til å skje, spørsmålet er hva som vil være din løsning for å takle det og løse disse problemene?
Vi får høre fra Dr. Robin Bloor, deretter vår egen Dez Blanchfield fra under og selvfølgelig vår gode venn, Bert Scalzo, fra IDERA. Og faktisk skal jeg dele ut nøklene til Robin Bloor, ta den bort. Gulvet er ditt.
Robin Bloor: OK. Dette er et interessant tema. Jeg trodde fordi Dez sannsynligvis kommer til å fortsette med de faktiske teknikkene og krigshistoriene om feilsøking, jeg tenkte at jeg bare ville gjøre en bakgrunnsdiskusjon slik at vi skulle få et fullstendig avrundet bilde av hva som skjer. Jeg gjorde dette lenge, og pleide å være en koder, så det er som, og jeg ble nesten fristet med denne presentasjonen til å begynne å vokse lyrisk om ideen om åpen kildekode, men jeg trodde jeg overlater det til noen andre.
Her er en liste over berømte feil, og de fleste av disse kommer inn på noens toppliste, i utgangspunktet, alt bortsett fra de to siste koster minst 100 millioner dollar. Den første var Mars Climate Orbiter, gikk seg vill i rommet og det var på grunn av et kodingsproblem, der folk forvekslet metriske enheter med (ler) føtter og tommer. Ariane Five Flight 501 var det et misforhold mellom en motor som ble satt på og datamaskinene som skulle kjøre raketten da den ble lansert. Flere datamaskinfeil, eksploderende rakett, overskriftnyheter. Sovjetisk gassledning i 1982, sies å være den største eksplosjonen i planetenes historie; Jeg er ikke sikker på om det er det. Russerne stjal litt automatisert kontrollprogramvare, og CIA innså at de kom til å gjøre det og la feil i det, og sovjeterne implementerte det uten å teste. Så, sprengte en rørledning, syntes det var morsomt.
Morris-ormen var et kodningseksperiment, som plutselig ble en voldsom orm som gikk rundt alles - det tilsynelatende forårsaket skade på 100 millioner dollar; det er et anslag selvfølgelig. Intel gjorde en kjent feil med en matematikkbrikke - en matematikkinstruksjon på Pentium-brikken i 1993 - som visstnok skulle ha kostet over 100 millioner dollar. Apples Maps-program er muligens den verste og mest katastrofale lanseringen av alt Apple noensinne har gjort. Folk som prøvde å bruke det, var, mener jeg, noen kjørte langs 101 og oppdaget at Apple Map sa at de var midt i San Francisco Bay. Så folk begynte å referere til Apple Maps-appen som iLost. Det - vårt lengste driftsstans i 1990 - det er bare interessant med tanke på kostnadene for noe sånt - AT&T var ute i rundt ni timer, og det kostet rundt 60 millioner dollar i langdistansesamtaler.
Og jeg var hos et britisk forsikringsselskap, og databasen, de implementerte en ny versjon av databasen, og det begynte å slette data. Og det husker jeg ekstremt godt, fordi jeg ble kalt inn etterpå for å ta del i et slags databasevalg på grunn av det. Og det var veldig interessant at de hadde tatt en ny versjon av databasen, og de hadde et batteri med tester som de gjorde for nye versjoner av databasen at den besto alle testene. Det fant en virkelig uklar måte å slette data.
Så uansett, det er det. Jeg trodde jeg skulle snakke om impedansmatch og SQL utstedt. Det er interessant at relasjonsdatabaser lagrer data i tabeller og kodere har en tendens til å manipulere data i objektsstrukturer som virkelig ikke kartlegger så bra til tabeller. Og på grunn av det får du det som kalles impedansmatch, og noen må takle det på en eller annen måte. Men hva som faktisk skjer, fordi en modell, kodermodellen og databasen en annen modell, ikke er spesielt på linje. Du får feil som bare ikke ville skjedd hvis bransjen hadde bygget ting som fungerer sammen, noe jeg synes er morsomt. Så i utgangspunktet, på kodersiden, når du får hierarkier kan det være typer, det kan resultere sett, det kan være dårlig API-evne, det kan være mange ting som bare kaster ting ut i form av interaksjon med databasen. Men det som er mest for meg, virkelig interessant; overrasket meg alltid at du hadde denne SQL-barrieren som også er en slags impedans på en måte som koderne og databasen fungerer med hverandre. Så SQL har datagjenkjenning, som er bra, og den har DML for å velge, prosjekt og bli med, noe som er greit. Du kan kaste mye kapasitet når det gjelder å få data ut av databasen med det. Men det har veldig lite matematisk språk for å gjøre ting. Det har litt av dette og det, og det har veldig lite tidsbaserte ting. Og på grunn av det er SQL et ufullkommen, hvis du vil, middel til å skaffe dataene. Så databasegutta bygde lagrede prosedyrer for å leve i databasen, og grunnen til de lagrede prosedyrene som bodde der, var at du egentlig ikke ønsket å kaste data frem og tilbake til et program.
For noe av funksjonaliteten var ekstremt dataspesifikk, så det var ikke bare referanseintegritet og kaskaderende slettinger og sånt, databasen tok seg av det plutselig at du legger funksjonalitet i en database, noe som selvfølgelig betydde at funksjonaliteten for et program kan deles mellom koderen og selve databasen. Og det gjorde jobben med å implementere noen slags funksjoner egentlig ganske vanskelig og derfor mer utsatt for feil. Så det er den ene siden av databasespillet, fordi det betyr at du har fått mange implementeringer for eksempel, at jeg har vært involvert i relasjonsdatabaser, det er virkelig en veldig masse kode som ligger i lagrede prosedyrer som håndteres separat fra kode som sitter i applikasjonene. Og det virker som en veldig merkelig ting å ha fått til, det er ment å være ganske smart til å gjøre forskjellige ting.
Jeg trodde jeg også ville snakke om databaseprestasjoner fordi ytelsesfeil ofte blir sett på som feil, men i utgangspunktet kan du ha en flaskehals på CPU, i minnet, på disken, i nettverket, og du kan ha problemer med ytelsen på grunn av låsing . Tanken ville være at koderen ikke egentlig trenger å være bekymret for ytelse, og databasen faktisk ville fungere rimelig bra. Det er ment å være designet slik at koderen ikke trenger å vite det. Imidlertid får du dårlig databasedesign, du får dårlig programdesign, du får samtidighet i arbeidsmengdemiksing, noe som også kan føre til ytelsesproblemer. Du får belastningsbalansering, du får kapasitetsplanlegging, datavekst - som kan føre til at en database bare stopper eller går tregere. Det er en interessant ting, når databaser blir nesten fulle, går de tregere. Og du kan ha problemer med datalag når det gjelder replikering og behov for å kopiere og behovet for å gjøre sikkerhetskopiering og gjenoppretting. Uansett, det er en generell oversikt.
Det eneste jeg vil si er at feilsøking av databaser bare kan være så tunge og ikke-trivielle - og det sier jeg fordi jeg har gjort mye av det - og du vil ofte oppdage at det er som alle situasjoner i avlusing som jeg noensinne opplevd er, er den første tingen du noensinne ser er et rot. Og du må prøve å gå fra rotet til å finne ut hvordan rotet ble til. Og ofte når du ser på et databaseproblem, er alt du ser på korrupte data, og du tenker: "Hvordan i helvete skjedde det?"
Uansett skal jeg gi videre til Dez, som sannsynligvis kommer til å si flere visdomsord enn jeg kom ut med. Jeg vet ikke hvordan jeg skal gi deg ballen, Dez.
Eric Kavanagh: Jeg skal passere det, stå ved, holde på.
Automatisert stemme: Deltakerlinjene er dempet.
Eric Kavanagh: OK, vent på ett sekund, la meg gi Dez ballen.
Dez Blanchfield: Takk, Eric. Ja, Dr. Robin Bloor, du er faktisk mest korrekt: dette er et tema, en livslang bugbear hvis du vil benåde ordspillet, beklager at jeg ikke kunne hjelpe meg med det. Forhåpentligvis kan du se min første skjerm der, unnskyldninger for skriftstørrelsesproblemet øverst. Temaet bugs er et dagsforedrag, i mange tilfeller etter min erfaring. Det er et så bredt og bredt tema, så jeg kommer til å legge fokus på to viktige områder, nærmere bestemt begrepet det vi anser som mye en feil, men et programmeringsspørsmål. Jeg tror i disse dager å introdusere en bug per se generelt blir plukket opp av de integrerte utviklingsmiljøene, selv om de kan være langvarige feil. Men ofte er det mer snakk om profilering av kode, og det er mulig å skrive kode som fungerer, det skal være en feil. Så, tittelen min gled her, jeg hadde faktisk en kopi av dette i veldig høy oppløsning A3, men dessverre ble det ødelagt i en flytting av hus. Men dette er en håndskrevet lapp på et programmeringsark fra cirka 1945, der visstnok noen folk ved Harvard University i USA, deres andre bygging av en maskin som heter Mark II. De feilsøkte noe problem, på vanlig språk, men de prøvde å finne en feil, og det viser seg at noe litt annerledes enn hva som var en maskinvare og et angivelig programvareproblem fulgte med.
Så den urbane myten er at rundt 9. september 1945 et team ved Harvard University trakk fra hverandre en maskin, de kom over noe de kalte “stafett sytti” - i disse dager ble programmering gjort i fysisk forstand, du sår kode rundt et brett, og det var slik du effektivt programmerte maskinen - og de fant at dette stafett nummer sytti, det var noe galt med det, og det viser seg at selve begrepet “bug” ble til fordi det bokstavelig talt var en møll - visstnok der var en møll kilt inn mellom et stykke kobbertråd som gikk fra et sted til et annet. Og historien går ut på at den legendariske Grace Hopper som dette bildeteksten, for tittelen min, "første faktiske tilfelle av en feil som ble funnet" sitat unote.
Men som Robin fremhevet tidligere i sitt første lysbilde, går begrepet en bug så langt tilbake som vi kan forestille oss at mennesker gjør regnestykker, begreper som en lapp. Begrepet "patch" kom fra et faktisk stykke tape som ble tapet over et hull på et hullkort. Men hele poenget med dette er at begrepet "feilsøking" kom ut av dette konseptet med å finne en feil i en fysisk maskin. Og siden den gang har vi brukt den terminologien rundt å prøve å håndtere problemer, enten ikke så mye som kodingsproblemer i et program som ikke samles, men som et program som ikke kjører bra. Og spesifikt har ikke blitt profilert, bare finn ting som uendelige løkker som bare går ingensteds.
Men vi har også et scenario, og jeg trodde jeg skulle legge inn et par morsomme lysbilder før jeg gikk litt nærmere inn på. Her er den klassiske tegneserien, kalt XKCD på nettet, og tegneserieskaper har noen ganske morsomme synspunkter på verden. Og denne handler om et barn som heter "Little Bobby Tables" og antok at foreldrene hans kalte denne unge gutten Robert '); DROP TABELL Studenter; - og det heter, og slags "Hei, dette er din sønns skole som har litt dataproblemer, " og forelderen svarer: "Å kjære, brøt han noe?" Og læreren sier: "Vel, på en måte, og læreren spør, "har du virkelig navngitt sønnen din Robert '); DROP TABEL Studenter; -? ”Og foreldrene sier:“ Å ja, små Bobby-bord vi kaller ham. ”Uansett fortsetter de å si at de nå har mistet årets studentrekorder, jeg håper du er lykkelig. Og svaret er: "Vel, du bør rense og desinfisere databasene dine." Og jeg bruker det mange ganger til å snakke om noen av problemene vi har med å finne ting i kode, at koden ofte ikke ser på dataene. også.
En annen morsom, jeg vet ikke om dette er ekte eller ikke - jeg mistenker at det er en forfalskning - men igjen, det berører også det morsomme beinet mitt. Noen som skifter lisensplate foran på bilen sin, til en lignende uttalelse som får databaser til å slippe inn hurtigkameraer og så videre som fanger bilers lisensplater. Og jeg refererer alltid til det som at jeg tviler på at enhver programmerer forventet et treff og kjøring av koden deres av et faktisk motorkjøretøy, men aldri undervurderer den - kraften til en sint nørd.
(Latter)
Men dette fører til meg til mitt sentrale punkt, antar jeg, og det er at vi en gang i tiden kunne feilsøke og profilere koden som bare dødelige. Men jeg er veldig mye av den oppfatningen at den tiden har gått, og anekdotisk etter min erfaring, den første - og dette blir veldig forferdelig; Robin, du er velkommen til å pirke på meg for dette - men historisk sett har jeg kommet fra en bakgrunn i en alder av 14 år og vandret nedover enden av byen og banket på døren til et datasenter kalt “Data Com” i New Zealand og spør om jeg kunne tjene lommepenger på skolen ved å ta den sene bussen hjem, rundt 25 km pendler hver dag, ved å legge papir i skrivere og tape i båndstasjoner, og bare være en generell administrator. Og nysgjerrig nok ga de meg en jobb. Men over tid klarte jeg å sette meg inn i bemanningen og finne programmererne og skjønte at jeg elsket koding og gikk gjennom prosessen med å kjøre skript og batchjobber, som på slutten av dagen fremdeles er kode. Du må skrive skript og batchjobber som ser ut som miniprogrammer og deretter gå gjennom hele prosessen med å sitte på en 3270 terminal skriverkode for hånd.
Faktisk var min aller første opplevelse på en teletypeterminal, som faktisk var 132-kolonne fysisk skriver. Tenk på som en veldig gammel skrivemaskin med papir som rullet gjennom den, for de hadde ikke et CRT-rør. Og feilsøkingskode på det var et veldig ikke-trivielt spørsmål, så du hadde en tendens til å skrive all koden for hånd, og deretter oppføre deg som en maskinskriver, og gjøre ditt beste for ikke å få feil å snike deg inn, fordi det er ekstremt frustrerende å måtte fortelle den ene linjeditoren for å gå til en bestemt linje og deretter skrive ut linjen og deretter skrive den inn igjen. Men en gang i tiden var det slik vi skrev kode, og det er hvordan vi feilsøkte, og vi ble veldig, veldig flinke til det. Og faktisk tvang det oss til å ha veldig gode programmeringsteknikker, fordi det var en virkelig problemfri å fikse det. Men reisen da gikk - og vi er alle kjent med dette - den gikk fra 3270 terminalopplevelsen i min verden, til Digital Equipment VT220 hvor du kunne se ting på skjermen, men igjen, du gjorde bare det samme du gjorde på papirbåndet slags trykt format bare på en CRT, men du var i stand til å slette lettere, og du hadde ikke den "dit dit dit dit" lyden.
Og så vet du, Wyse-terminalene - som Wyse 150, sannsynligvis mitt favorittgrensesnitt til en datamaskin noensinne - og så PCen og deretter Mac-en, og i disse dager moderne GUI-er og ID-er som er nettbaserte. Og en rekke programmer gjennom det, programmering i en og assembler og PILOT og Logo og Lisp og og Fortran og Pascal og språk som kan få folk til å krype. Men dette er språk som tvang deg til å skrive god kode; de lot deg ikke slippe unna med dårlig praksis. C, C ++, Java, Ruby, Python - og vi kommer lenger opp i programmeringsstadiet, vi blir mer skriptlignende, vi kommer nærmere og nærmere Strukturerte Query-språk og språk som PHP som faktisk brukes til å påkalle SQL. Poenget med å fortelle deg at det kom fra min bakgrunn, jeg var selvlært på mange måter, og de som hjalp meg med å lære, lærte meg veldig god programmeringspraksis og veldig god praksis rundt design og prosesser for å sikre at jeg ikke gjorde det introduser buggy code.
Programmeringsmetoder i disse dager, ting som for eksempel Structured Query Language, SQL, det er et veldig kraftig, enkelt spørrespråk. Men vi har gjort det om til et programmeringsspråk, og jeg tror ikke egentlig at SQL noen gang var designet for å være et moderne programmeringsspråk, men vi har skvist det for å bli det. Og det introduserer en hel haug problemer, for når vi tenker på fra to synspunkt: fra kodingssynspunktet og fra DBA-synspunktet. Det er veldig enkelt å få med seg og introdusere feil for ting som bare dårlige programmeringsteknikker, lat innsats med å skrive kode, mangel på erfaring, den klassiske kjæledyrknappen jeg har for eksempel med SQL-folk som hopper på Google og søker etter noe og finner et nettsted som er fikk et eksempel og lage en kopi og lim inn eksisterende kode. Og deretter kopiere en dårlig koding, malpractice og sette den i produksjon, fordi det bare skjer for å gi dem de resultatene de ønsker. Du har andre utfordringer, for eksempel i disse dager løper vi alle mot dette, det vi kaller løpet til null: prøver å gjøre alt så billig og så raskt, at vi har et scenario der vi ikke bruker lavere -betalt personale. Og det mener jeg ikke på en disingenuous måte, men vi ansetter ikke eksperter for alle mulige jobber. En gang i tiden var noe med datamaskiner å gjøre med rakettvitenskap; det var involvert i ting som gikk bra og var veldig høyt, eller gikk ut i verdensrommet eller ingeniører var tungt kvalifiserte menn og kvinner som hadde gjort grader og hadde strenge utdannelser som hindret dem i å gjøre gale ting.
I disse dager er det mye folk som kommer inn i utvikling og design og database som ikke har hatt mange års erfaring, ikke nødvendigvis har hatt den samme opplæringen eller støtten. Og slik slutter du med et scenario med bare den tradisjonelle amatør kontra eksperten. Og det er en kjent linje, jeg kan faktisk ikke huske hvem som opprettet sitatet, linjen går: “Hvis du synes det er dyrt å ansette en ekspert til å gjøre en jobb, vent til du ansetter et par amatører som skaper et problem og må rydde opp. ”Og så har SQL det problemet, og det er veldig, veldig enkelt å lære, det er veldig enkelt å bruke. Men det er ikke etter mitt syn et perfekt programmeringsspråk. Det er veldig enkelt å gjøre ting som å gjøre en utvalgt stjerne hvor som helst og trekke alt det til et programmeringsspråk som du er mer komfortabel med som PHP og Ruby eller Python, og bruke programmeringsspråket du er opprinnelig kjent med, til å gjøre datamanipulasjonen, i stedet for å gjøre et mer komplekst spørsmål i SQL. Og vi ser dette mye, og da lurer folk på hvorfor databasen kjører sakte; Det er fordi en million mennesker prøver å kjøpe en billett fra et online billettsystem, der det gjør en valgt stjerne hvor som helst.
Nå, det er et ekstremt eksempel, men du får poenget med alt dette. Så for å virkelig slå det punktet hjem, her er et eksempel som jeg bærer rundt mye. Jeg er en stor fan av matematikk, jeg elsker kaosteori, jeg elsker Mandelbrot-settene. På høyre side er det en gjengivelse av Mandelbrot-settet, som jeg er sikker på at vi alle er kjent med. Og til venstre er det et stykke SQL som faktisk gjengir det. Nå, hver gang jeg legger dette på en skjerm et sted, hører jeg dette “Herregud, noen gjengitt Mandelbrot-serien med SQL, er du seriøs? Det er sinnssykt! ”Vel, hele poenget med det er å illustrere hva jeg nettopp skisserte der, og det er ja, faktisk kan du nå programmere nesten hva som helst i SQL; det er et veldig sterkt utviklet, kraftig, moderne programmeringsspråk. Når det opprinnelig var et spørrespråk, var det designet for å bare få dataene opp. Så nå har vi veldig komplekse konstruksjoner og vi har lagrede prosedyrer, vi har programmeringsmetodikk som brukes på et språk, og det er veldig enkelt for dårlig programmeringspraksis, mangel på erfaring, klipp ut og lim inn kode, lavtlønte ansatte som prøver å være høyt betalte ansatte, folk som later som de kjenner, men de må lære på jobben.
En hel rekke ting der kodeprofilering og det vi omtaler som feilsøking, som ikke er så mye å finne feil som hindrer programmer i å fungere, men feil som bare skader systemet og dårlig strukturert kode. Når du ser på denne skjermen nå, og du tenker, det er bare det, det er litt søtt, og du tenker: “Wow, for en fantastisk grafikk, jeg vil gjerne kjøre det.” Men tenk at det kjører på et stykke forretningslogikk . Det ser ganske pent ut, men det snakker en matematisk grafisk gjengitt kaosteori, men når du tenker over hva den potensielt kan brukes til i en viss virksomhetslogikk, får du bildet veldig raskt. Og for virkelig å illustrere det - og jeg beklager at fargene er omvendt, det er ment å være en svart bakgrunn og grønn tekst for å være en grønn skjerm, men du kan fortsatt lese det.
Jeg gikk og tittet raskt på et eksempel på hva du potensielt kan gjøre hvis du virkelig var gal og ikke hadde noen som helst erfaring og kom fra en annen bakgrunn av programmering og anvendte slike som C ++ på SQL, for å virkelig illustrere poenget mitt, før Jeg overleverer til den lærde gjesten fra IDERA. Dette er et strukturert søk som er skrevet som C ++, men det er kodet i SQL. Og den kjøres faktisk, men den kjøres over en periode på tre til fem minutter. Og det trekker tilsynelatende tilbake en linje med data ut fra flere databaser, flere sammenføyninger.
Igjen, hele poenget med dette er at hvis du ikke har de riktige verktøyene, hvis du ikke har de riktige plattformene og miljøene for å kunne fange disse tingene, og de kommer i produksjon, og så har du 100 000 mennesker når du treffer et system hver dag, hver time eller minutt, veldig snart ender du opp med en Tsjernobyl-opplevelse der det store jernet begynner å smelte sammen og begrave seg til kjernen av planeten, fordi det koden ikke skulle komme i produksjon. Dine systemer og verktøyene dine, unnskyld meg, bør plukke det opp før det går hvor som helst i nærheten av - til og med gjennom testprosessen, til og med gjennom UAT og systemintegrasjon, skal det kodestykket plukkes opp og fremheves og noen bør føres til side og og sa: "Se, det er egentlig ganske kode, men la oss få en DBA som hjelper deg å bygge den strukturerte spørringen ordentlig, for ærlig talt, det er bare stygt." Og nettadressen er der, du kan gå og ta en titt - det blir referert til som det mest komplekse SQL-spørringen du noen gang har skrevet. For tro meg, det samles faktisk, det løper. Og hvis du klipper ut og limer det og bare håner opp databasen, er det ganske noe å se på; Hvis du har verktøy for å se databasen, bare prøv å smelte ned over en periode på tre til fem minutter, for å ringe tilbake hva som er en tekstlinje.
Så for å oppsummere, med det i tankene, har hele bakgrunnen for koding lært meg at du kan gi folk en pistol, og hvis de ikke er forsiktige, skyter de seg selv i foten; trikset er å vise dem hvor sikkerhetsmekanismen er. Med de riktige verktøyene og riktig programvare ved fingertuppene, etter at du har gjort kodingen, kan du gå gjennom koden din, du kan finne problemer ved å profilere koden, du kan finne effektive utilsiktede feil som er ytelsesproblemer, og som sagt tidligere, en gang i tiden, kan du gjøre det med å se på en grønn skjerm. Du kan ikke lenger; det er hundretusener av kodelinjer, det er titusenvis av apper som er distribuert, det er millioner av databaser i noen tilfeller, og selv supermennesker kan faktisk ikke gjøre dette for hånd lenger. Du trenger bokstavelig talt den rette programvaren og de riktige verktøyene til fingerspissene, og du trenger at teamet skal bruke disse verktøyene, slik at du kan finne disse problemene og adressere dem veldig, veldig raskt før du kommer til poenget, mens Dr. Robin Bloor fremhevet, ting blir enten katastrofale, og ting blåser opp, eller mer ofte, de begynner bare å koste deg mye dollar og mye tid og krefter og ødelegge moral og sånt når de ikke kan ordne hvorfor ting tar lang tid å løpe.
Og med det i tankene, vil jeg overlate til vår gjest, og jeg ser frem til å høre hvordan de har løst dette problemet. Og spesielt demoen tror jeg at vi er i ferd med å motta. Eric, jeg kommer tilbake.
Eric Kavanagh: OK, Bert, ta den bort.
Bert Scalzo: OK, takk. Bert Scalzo her fra IDERA, jeg er produktsjef for databaseverktøyene våre. Og jeg skal snakke om feilsøking. Jeg tror en av de viktigste tingene som Robin sa tidligere - og det er veldig sant, er at feilsøking er tung og ikke-triviell, og når du går til database feilsøking er det en størrelsesorden enda mer tyngende og ikke-triviell - så, det var et viktig sitat.
OK. Jeg ønsket å starte med programmeringshistorikk, fordi mange ganger ser jeg folk som ikke feilsøker, de bruker ikke en debugger, de programmerer bare med hvilket språk de bruker, og mange ganger vil de si til meg, "Vel, de feilsøkings tingene er nye, og vi har ikke begynt å bruke det ennå." Og så det jeg gjør er at jeg viser dem dette tidslinjediagrammet, slags forhistorie, alderdom, middelalder, det er snilt å si hvor var vi når det gjaldt programmeringsspråk. Og vi hadde veldig gamle språk fra 1951 med monteringskode, og Lisp og FACT og COBOL. Så kommer vi inn i den neste gruppen, Pascals og Cs og deretter den neste gruppen, C ++ s, og ser hvor det spørsmålsmerket er - det spørsmålstegnet er tilnærmet rundt 1978 til kanskje 1980. Et sted i det området vi hadde debuggers tilgjengelig for oss, og for å si: "Hei, jeg bruker ikke en debugger, for det er en av de nye tingene, " så du må ha begynt å programmere, vet du, allerede på 1950-tallet, fordi det er den eneste måten du slipper unna med påstanden.
Nå er det andre som er morsomt med dette diagrammet, Dez har bare skrevet en kommentar om Grace Hopper, jeg kjente faktisk Grace, så det er litt morsomt. Og så den andre tingen jeg lo av, er at han snakket om teletyper, og jeg satt der og gikk, “Mann, det var det største spranget vi noensinne har hatt i produktiviteten, da vi gikk fra kort til teletyper, det var det største hoppet noensinne. ”Så, og jeg har programmert på alle språkene her, inkludert SNOBOL, som ingen noen gang har hørt om før, det var en CDC, Control Data Corporation, så jeg antar at jeg blir litt for gammel for denne bransjen .
Dez Blanchfield: Jeg hadde tenkt å si at du har aldret oss veldig der.
Bert Scalzo: Ja, det sier jeg deg, jeg føler meg som bestefar Simpson. Så jeg ser på feilsøking, og det er forskjellige måter å gjøre feilsøking på. Du kan snakke om det vi alle tenker på som tradisjonelle å komme inn i en debugger og gå gjennom kode. Men også folk vil instrumentere koden sin; det er der du stikker utsagn i koden din, og kanskje produserer du en utdatafil, en sporingsfil eller noe, og så instrumenterer du koden. Jeg vil regne at det som avlusing er litt vanskeligere, en måte å gjøre det på, men det teller. Men også, vi har den berømte utskriftserklæringen: du ser på og folk legger faktisk utskriftsuttalelser i, og jeg har faktisk sett et verktøy der - og det er et databaseverktøy - hvor hvis du ikke vet hvordan du bruker en debugger, du trykker på en knapp, og den vil trykke uttalelser gjennom koden for deg, og når du er ferdig, trykker du på en annen knapp, og den fjerner dem. For det er slik mange mennesker feiler.
Og grunnen til at vi feilsøker er todelt: Først av alt, vi måtte finne ting som gjør koden vår ineffektiv. Med andre ord betyr det vanligvis at det er en logisk feil, eller at vi savnet et forretningskrav, men hva det er, er koden ikke er effektiv. den gjør ikke det vi forventet. Den andre gangen vi går og vi feilsøker, er det for effektivitet og det kan være en logisk feil, men hva det er, er at jeg gjorde det rette, det kommer ikke raskt nok tilbake. Nå gjør jeg poenget fordi en profiler sannsynligvis er bedre for det andre scenariet, og vi kommer til å snakke om både feilsøkere og profilere. I tillegg er det dette konseptet med fjernfeilsøking; Dette er viktig fordi mange ganger hvis du sitter på din personlige datamaskin, og bruker en feilsøking, som treffer en database der koden faktisk kjøres i databasen, gjør du det som kalles ekstern feilsøking. Du skjønner kanskje ikke det, men det er det som skjer. Og så er det veldig vanlig at disse avluserne har pausepoeng, ser på poeng, går inn og går over og noen andre vanlige ting, at jeg skal vise øyeblikksbildet på skjermen.
Nå, profilering: du kan gjøre profilering på et par forskjellige måter. Noen mennesker vil si at arbeidsmengde fanger og spiller på nytt der det fanger opp alt, som teller som profilering. Min erfaring har vært mer, det er bedre hvis det er gjort prøvetaking. Det er ingen grunn til å fange hver eneste uttalelse, fordi noen uttalelser kan løpe så raskt at du ikke bryr deg. Det du virkelig prøver å se er vel, det er de som fortsetter å vises igjen og igjen, fordi de løper for lenge. Noen ganger kan profilering bety prøvetaking i stedet for å kjøre hele saken. Og typisk vil du få en slags utdata som du kan bruke, nå som kan være visuell i et IDE-utviklingsmiljø, der det kan gi deg et histogram av ytelsen til de forskjellige kodelinjene, men det kan også fortsatt være at den produserer en sporingsfil.
Profilers dukket opp først i 1979. Så de har eksistert i lang tid også. Flott for å finne ressursforbruk, eller ytelsesproblemer, med andre ord den effektiviteten tingen. Generelt sett er det atskilt og forskjellig fra debuggeren, selv om jeg har jobbet med debuggers som gjør begge deler samtidig. Og selv om profilere synes jeg er de mer interessante av de to verktøyene, hvis jeg føler at ikke nok folk avluser, så definitivt ikke er det nok mennesker som profilerer, fordi en av ti avlusere vil profilere, ser det ut til. Og det er synd, fordi profilering virkelig kan utgjøre en enorm forskjell. Nå, databasespråk, som vi har snakket om tidligere, har du SQL - og vi har på en måte tvunget den runde pinnen inn i det firkantede hullet her og tvunget den til å bli et programmeringsspråk - og Oracle. Det er PL / SQL - det er prosedyrespråket SQL - og SQL Server, det er Transact-SQL, det er SQL-99, det er SQL / PSM - for, tror jeg, det er prosedyre lagret modul. Postgres gir det et annet navn, DB2 enda et navn, Informix, men poenget er at alle har tvunget 3GL-konstruksjoner; med andre ord, FOR looper, med variabel deklarasjoner og alle andre ting som er fremmed for SQL, er nå en del av SQL på disse språkene. Og så må du være i stand til å feilsøke en PL / SQL eller en Transact-SQL akkurat som du ville gjort et Visual Basic-program.
Nå, databaseobjekter, er dette viktig fordi folk vil si: "Vel, hvilke ting har jeg å feilsøke i en database?" Og svaret er, vel, hva du kan lagre i databasen som kode - hvis jeg gjør T-SQL, eller PL / SQL - og jeg lagrer objekter i databasen, det er sannsynligvis en lagret prosedyre eller lagret funksjon. Men det er også utløsere: en trigger er på samme måte som en lagret prosedyre, men den skyter på en slags hendelse. Nå vil noen mennesker i triggerne deres sette en kodelinje og ringe en lagret prosedyre slik at de beholder alle lagrede koder og prosedyrer, men det er det samme konseptet: det er fremdeles utløseren som kan være det som initierer hele greia. Og så som Oracle, har de noe som heter en pakke, som likner på et bibliotek om du vil. Du legger 50 eller 100 lagrede prosedyrer i en gruppering, kalt en pakke, så det er liksom et bibliotek. Så her er feilsøkeren på den gamle måten; dette er faktisk et verktøy som faktisk vil gå inn og feste alle disse avlusningsuttalelsene i koden din for deg. Så overalt hvor du ser feilsøkingsblokkering, ikke fjern, automatisk feilsøking starter og spores, de ble alle satt fast i et verktøy. Og linjene utenfor dette, som er mindretallet i koden, vel, det er den ikke-manuelle feilsøkingsmetoden.
Og grunnen til at jeg tar opp dette, er at hvis du prøver å gjøre dette for hånd, faktisk kommer du til å skrive inn mer feilsøkingskode for å legge inn alle disse utskriftsuttalelsene enn du er med koden. Så selv om dette kan fungere, og selv om det er bedre enn ingenting, er dette en veldig vanskelig måte å feilsøke, spesielt siden, hva om det tar 10 timer for denne tingen å løpe, og hvor det har et problem, er i linje tre? Hvis jeg holdt på med en interaktiv feilsøkingsøkt, ville jeg visst på linje tre - fem minutter inn i det - hei, det er et problem her, jeg kan slutte. Men med dette må jeg vente på at den kjøres, helt til ferdigstillelse, og så må jeg se på en sporingsfil som sannsynligvis har alle disse uttalelsene i seg, og prøve å finne nålen i høystakk. Igjen, dette er bedre enn ingenting, men det ville ikke være den beste måten å jobbe på. Nå, dette er hvordan filen vil se ut som kom fra forrige lysbilde; med andre ord, jeg kjørte programmet, og det har nettopp en haug med utskriftsuttalelser i denne sporingsfilen, og det kan hende at jeg ikke kan sifle gjennom dette og finne det jeg trenger å finne. Så igjen, jeg er ikke så sikker på at dette er slik du ønsker å jobbe.
Nå har interaktive feilsøkere - og hvis du har brukt noe som Visual Studio til å skrive programmer, eller Eclipse, har du hatt feilsøkere og brukt dem med de andre språkene dine - tenkte bare ikke å bruke dem her med databasen. Og det er verktøy der ute, som DB Artisan og vår Rapid SQL, dette er Rapid SQL her, som har en debugger, og du kan se på venstre side, jeg har en lagret prosedyre som heter "sjekk for duplikater." I utgangspunktet er det bare å gå og se og se om jeg har flere rader i tabellen med samme filmtittel. Så databasen er for filmer. Og du kunne se på høyre side, på den øverste tredjedelen, jeg har kildekoden min i midten, jeg har det som kalles klokkevariablene mine og mine call stack-skuffer, og så i bunnen jeg ' Vi har fått noen utdatameldinger. Og det som er viktig her er, hvis du ser over den første røde pilen, hvis jeg holder musen over en variabel, kan jeg faktisk se hvilken verdi som er i den variabelen i det øyeblikket, mens jeg går gjennom koden. Og det er veldig nyttig, og så kan jeg gå en linje av gangen gjennom koden, jeg trenger ikke å si utføre, jeg kan si trinn på en linje, la meg se hva som skjedde, trinn en annen linje, la meg se hva som skjedde, og jeg gjør dette i databasen. Og selv om jeg sitter på Rapid SQL på min PC og databasen min er oppe i skyen, kan jeg fremdeles gjøre den eksterne feilsøkingen og se den og kontrollere den herfra, og gjøre feilsøking akkurat som jeg ville gjort med andre språk.
Nå, den neste pilen der - du kan se den lille pilen som peker til høyre, mot DBMS-utgangen, det er der markøren er for øyeblikket - så med andre ord, jeg har tråkket til og det er der jeg er på øyeblikket. Så hvis jeg sier: "Gå igjen", vil jeg gå til den neste linjen. Nå like nedenfor ser du den røde prikken. Vel, det er et knekkpunkt, som sier "Hei, jeg vil ikke trå over disse linjene." Hvis jeg bare vil hoppe over alt og komme dit den røde prikken, kan jeg trykke på kjør-knappen og den vil løpe herfra til slutt, eller til et knekkpunkt, hvis det er angitt noen punkter, og så vil det stoppe og la meg gjøre steget igjen. Og grunnen til at dette er viktig og kraftig er, er fordi når jeg gjør alt dette, vil det som skjer i midten og til og med bunnen - men viktigst av alt - midten forandre seg, og jeg kan se verdiene fra variablene mine, Jeg kan se sporingsanropene mine, du vet, og så vises all den informasjonen der mens jeg går gjennom koden, slik at jeg faktisk kan se og føle og få en forståelse for hva som skjer og hvordan koden faktisk er arbeider på utførelsestid. Og typisk kan jeg finne et problem, hvis det er noe, eller hvis jeg er god nok til å fange det.
OK, nå skal jeg snakke om en profiler, og i dette tilfellet er dette en profiler som jeg kan se gjennom en debugger. Husker jeg at jeg sa at noen ganger er de separate og noen ganger kan de være sammen? I dette tilfellet, og igjen, er jeg i Rapid SQL, og jeg kan se at det er en margin på venstre side ved siden av linjenumrene. Og hva det er, er at det er antall sekunder eller mikrosekunder som det tok å utføre hver kodelinje, og jeg kan se at tydelig, all min tid blir brukt i denne FOR-loopen hvor jeg velger alt fra en tabell . Og det som uansett skjer inne i FOR-løkken er nok noe jeg trenger å se på, og hvis jeg kan gjøre det bedre, vil det betale utbytte. Jeg har ikke tenkt å få noen forbedringer ved å jobbe med de linjene som har som 0, 90 eller 0, 86; det er ikke mye tid brukt der. Nå, i dette tilfellet, og igjen, jeg er i Rapid SQL, ser du hvordan jeg kan gjøre profilering blandet med feilsøkingen min. Det som er fint er Rapid SQL, som også lar deg gjøre det andre veien. Rapid SQL lar deg si: “Vet du hva? Jeg vil ikke være med i feilsøkeren, jeg vil bare kjøre dette, og så vil jeg se på grafisk eller visuelt den samme typen informasjon. ”
Og du kan se at jeg ikke lenger er i feilsøkingsprogrammet og det kjører programmet, og etter at utførelsen er fullført, gir det meg diagrammer for å fortelle meg ting, så jeg kan se at jeg har fått en uttalelse som ser ut som om den tar opp det meste av kakediagrammet, og hvis jeg ser, ser jeg på det rutenettet mot bunnen, linje 23, så er det FOR-løkken igjen: han tar opp mest tid, han er faktisk så mørk rød som tygger opp alt kakediagrammet. Og slik er dette en annen måte å gjøre profiler på. Vi kaller tilfeldigvis “Code Analyst” i verktøyet vårt. Men det er i utgangspunktet bare en profiler atskilt fra en debugger. Noen mennesker liker å gjøre det på den første måten, andre liker å gjøre det andre veien.
Hvorfor gjør vi feilsøking og profilering? Det er ikke fordi vi vil skrive verdens største kode og få en lønnsøkning - det kan være vår grunn, men det er egentlig ikke grunnen til at du gjør det - du lovet virksomheten at du ville gjøre noe riktig, at programmet ditt vil være effektivt. Det er det du vil bruke avluseren til. I tillegg er forretningsbrukere; de er ikke veldig tålmodige: de vil ha resultater allerede før de trykker på tasten. Vi skal lese tankene og gjøre alt øyeblikkelig. Det må med andre ord være effektivt. Og det, det er det vi vil bruke profilen til. Uten disse verktøyene tror jeg virkelig at du er denne fyren i forretningsdrakten med pil og bue, og du skyter mot målet, og du er bind for øynene. For hvordan skal du finne ut hvordan et program kjøres ved bare å se på statisk kode, og hvordan skal du finne ut hvilken linje som er der det virkelig vil bruke mest tid på utførelse, igjen, bare ved å se på statisk kode? En kodegjennomgang viser kanskje ikke noen av disse tingene, men det er ingen garanti for at en kodegjennomgang vil finne dem alle. Ved hjelp av en debugger og profiler skal du kunne finne alle disse feilene.
OK, jeg skal bare gjøre en skikkelig demo her. Det er ikke min intensjon å presse produkt, jeg vil bare vise deg hvordan en feilsøking ser ut fordi mange ganger folk vil si: "Jeg har aldri sett en av disse før." Og det ser pent ut på skjermbildet, men hvordan ser det ut når det er i bevegelse? Så her på skjermen kjører jeg DB Artisan-produktet; vi har en debugger der også. DB Artisan er ment mer for DBA-er, Rapid SQL er mer for utviklerne, men jeg har sett utviklere som bruker DB Artisan, og jeg har sett DBA-er som bruker Rapid. Så ikke bli opptatt av produktet. Og her har jeg valget mellom å gjøre en feilsøking, men før jeg starter feilsøkingen, skal jeg trekke ut denne koden slik at du kan se hvordan koden ser ut før jeg begynner å kjøre den. Så her er nøyaktig den samme koden som var i skjermbildet, dette er min sjekk for duplikater. Og jeg vil feilsøke dette, så jeg trykker på feilsøking. Og nå tar det et øyeblikk, og du sier: "Vel, hvorfor tar det et øyeblikk?" Husk ekstern feilsøking: feilsøkingen skjer faktisk på databaseserveren min, ikke på min PC. Så det måtte gå over og lage en økt der borte, lage en ekstern avlusing ting, koble økten til den eksterne avlusingsøkten og sette opp en kommunikasjonskanal.
Så nå, her er pilen min, den er der oppe, etter linje en, det er der jeg er i koden. Og hvis jeg trykker på det tredje ikonet der, som er et skritt inn, vil du se at pilen nettopp flyttet, og hvis jeg fortsetter å trykke på den, vil du se den fortsette å bevege seg. Hvis jeg ville gå helt ned til denne FOR-sløyfen, fordi jeg vet at det er der problemet er, kan jeg sette et knekkpunkt. Jeg trodde jeg satte det. Å skyte, jeg hadde en av skjermtastene mine tilordnet den samme tasten som avluseren, det er det som forårsaker forvirring. OK, så jeg bare angir et bryterpunkt manuelt der, så nå i stedet for å gjøre et skritt, skritt, skritt, skritt til jeg kommer dit, kan jeg faktisk bare si: "Gå videre og kjør denne tingen, " og det vil stoppe. Legg merke til at det beveget meg helt ned til hvor bruddpunktet er, så jeg er nå inne i sammenhengen med å kjøre denne løkken, jeg kan se hva alle variablene mine er satt til, noe som ikke er en overraskelse, fordi jeg initialiserte dem alle til null. Og nå kan jeg gå inn i denne løkken og begynne å se på hva som skjer inne i denne løkken.
Så nå kommer det til å gjøre en valgt uttelling fra utleiene mine, og jeg kan muse over den fyren og se på, han er to, to er større enn en, så det kommer nok til å gjøre neste del av denne koden. Med andre ord fant den noe. Jeg skal bare fortsette og la det løpe. Jeg vil ikke gå gjennom alt her; Det jeg vil vise deg er når en feilsøking er ferdig, den fullføres akkurat som et normalt program. Jeg har satt pausepunktet, så når jeg sa løp, gikk det bare tilbake til neste pekepunkt. Jeg lar det løpe til slutt, fordi det jeg vil at du skal se, er at en feilsøking ikke endrer atferden til programmet: når det er kjørt, burde jeg oppnå nøyaktig de samme resultatene hvis jeg ikke hadde kjørt det inne i en debugger.
Og med det kommer jeg til å stanse demoen og gå tilbake fordi vi vil sørge for at vi har tid til spørsmål og svar. Og så vil jeg åpne det for spørsmål og svar.
Eric Kavanagh: OK, Robin, kanskje et spørsmål fra deg og deretter et par fra Dez?
Robin Bloor: Ja, selvfølgelig, jeg synes dette er fascinerende. Jeg har jobbet med ting som dette, men jeg har aldri jobbet med noe lignende i databasen. Kan du gi meg en ide om hva folk bruker profilen til? Fordi det er som, ser de på - fordi jeg antar at de er - de ser på ytelsesproblemer, vil det hjelpe deg å skille mellom når en database tar tid og når en kode tar tid?
Bert Scalzo: Du vet, det er et fantastisk spørsmål. La oss si at jeg jobber i Visual Basic, og jeg, inne i Visual Basic, skal jeg kalle en Transact-SQL eller en PL / SQL. La meg gjøre PL / SQL, siden Oracle ikke spiller bra alltid med Microsoft-verktøyene. Jeg kan profilere Visual Basic-koden min, og profilen der kan si: "Hei, jeg kalte denne lagrede prosedyren, og det tok for lang tid." Men så kan jeg gå inn på den lagrede prosedyren, og jeg kan gjøre en databaseprofil på den lagrede prosedyre og si, "OK, av de 100 uttalelsene som er her, her er de fem som forårsaket problemet." Og så kan det hende du må gjøre et tag-team, der du må bruke flere profiler.
Tanken er at hvis du noen gang får beskjed om at ytelsesproblemet er i databasen, kan en databaseprofil hjelpe deg med å finne nålen i høystakken som uttalelser som faktisk er de der du har et problem. Jeg forteller deg en annen ting som dukket opp med profilering: hvis du har et stykke kode som blir kalt en million ganger, men det bare tar et mikrosekund hver million ganger, men det blir kalt en million ganger, hva profilen ville vist, den tingen løp i så mange tidsenheter. Og så mens koden kan være svært effektiv, kan du se og si: “Ooh, vi ringer dette kallet til altfor ofte. Kanskje vi bare må kalle det så ofte, i stedet for hver gang vi behandler en plate, eller noe. Og slik at du faktisk kan finne hvor det er effektiv kode som bare heter for ofte, og som faktisk er et ytelsesproblem.
Robin Bloor: Ja, det er fantastisk. Jeg har aldri gjort dette. Du skjønner selvfølgelig at når jeg hadde databaseproblemer, var det som om jeg på en eller annen måte enten skulle ha å gjøre med database eller ha å gjøre med kode; Jeg kunne aldri takle begge deler på samme tid. Men der, igjen, gjorde jeg ikke det - jeg har aldri vært involvert i å bygge applikasjoner der vi hadde lagret prosedyrer, så jeg antar at jeg aldri har opplevd problemer som pleide å gjøre meg vill, ideen om at du ville dele koden opp mellom en database og et program. Men så, gjør alt - jeg antar at svaret blir ja, men dette er en del av en utviklingsteamaktivitet, når du på en eller annen måte prøver å fikse noe som er ødelagt, eller kanskje prøver å få en ny søknad sammen. Men skreddersyr dette alt sammen med alle de andre komponentene jeg forventer i miljøet? Kan jeg forvente at jeg kunne klippe dette sammen med alle testpakkene mine og alle de andre tingene som jeg ville gjort og med prosjektledelsen min, er det slik at alt dette klippes sammen?
Bert Scalzo: Ja, det kan bli en del av enhver strukturert prosess å gjøre programmerings- eller utviklingsarbeidet. Og det er morsomt, forrige uke hadde jeg en kunde som bygde en nettapplikasjon, og databasen deres hadde historisk vært liten, og så det faktum at de ikke var veldig gode programmerere, skadet dem aldri. Vel, databasen deres har vokst med årene, og nå tar det 20 sekunder på en webside, mellom når du sier: "Logg meg på og gi meg noen data å se" og når skjermen faktisk kommer opp, og nå et ytelsesproblem. Og de visste at problemet ikke var på noe av deres Java eller noen av de andre stedene. Men de hadde tusenvis av lagrede prosedyrer, og derfor måtte de begynne å profilere de lagrede prosedyrene for å finne ut hvorfor det tar 20 sekunder å komme på denne websiden? Og vi fant faktisk ut at de hadde en kartesisk med på en av sine utvalgte uttalelser og ikke visste det.
Robin Bloor: Wow.
Bert Scalzo: Men noen sa til meg en gang: "Vel, hvordan kunne de få en kartesisk med og ikke vite det?" Og dette vil høres veldig forferdelig ut; noen ganger vil en programmerer som ikke er veldig komfortabel med SQL, gjøre noe som å gi meg et kartesisk medlem, men bare gi meg den første posten tilbake, så jeg vet at jeg fikk noe, og jeg trenger bare den første. Og de skjønner ikke at de bare hentet tilbake en milliard poster, eller at de ser gjennom en milliard poster, fordi de fikk den de var interessert i.
Robin Bloor: Wow, jeg vet, det er det som heter - vel, det var det Dez foregikk om, med tanke på at folk ikke er så dyktige som de burde være, vet du. Hvis du er en programmerer, bør du vite hva konsekvensene av å utstede noen kommando er. Jeg mener egentlig, det er ingen unnskyldning det nivået av dumhet. Jeg antar også at du på en eller annen måte bare er språkagnostisk når det gjelder dette, fordi dette hele fokuserer på databasesiden. Har jeg rett i det? Er det akkurat det samme, uansett hva du bruker på kodingsiden?
Bert Scalzo: Absolutt, du kan gjøre dette i Fortran eller C eller C ++. På noen Unixer kan du faktisk gjøre det for skriptspråkene deres. de gir faktisk de samme verktøyene. Og så vil jeg gå et sekund tilbake for det du sa uten unnskyldning. Jeg kommer til å gi programmererne en pause, for jeg liker ikke å kaste programmerere under bussen. Men problemet er egentlig det akademiske miljøet, fordi når du går for å lære å være programmerer, blir du lært opptak om gangen. Du læres ikke settetenkning, og det er det Structured Query Language, eller SQL fungerer med sett; Derfor har vi fagforeningen, krysset og minusoperatøren. Og det er veldig vanskelig noen ganger for en person som aldri har tenkt i form av sett, å slutte, slippe rekord-til-en-gang-behandling og jobbe med sett.
Robin Bloor: Ja, jeg er med deg på det. Jeg mener, jeg får nå, det er et utdanningsspørsmål; Jeg tror det er helt et utdanningsspørsmål, jeg tror at det er naturlig at programmerere tenker prosessuelt. Og SQL er ikke prosessuell, den er erklærende. Du sier faktisk bare, "Dette er hva jeg vil, og jeg bryr meg ikke hvordan du gjør det, " vet du? Mens du har programmeringsspråk ofte har ermene rullet sammen, og du er nede i detaljene for selv å administrere tellingene, mens du gjør en løkke. Jeg skal gi videre til-
Bert Scalzo: Nei. OK, fortsett.
Ja, jeg hadde tenkt å si at du tok opp et annet eksempel på at en profiler ville være bra med å fange den, slags fortsetter med denne rekord-til-gangen-behandlingen. Noen ganger kan ikke en programmerer som er god på en logg-oppdatert logikk, finne ut hvordan du gjør SQL-program. La oss si at han lager to FOR-løkker og i utgangspunktet gjør en sammenføyning, men han gjør det på klientsiden. Så han har samme effekt som en sammenføyning, men han gjør det selv, og en profil vil fange det, fordi du sannsynligvis vil ende opp med å bruke mer tid på å bli med manuelt enn å la databaseserveren gjøre det for deg.
Robin Bloor: Ja, det ville være en katastrofe. Jeg mener, du ville bare slå deg rundt. Spennende er alltid dårlig.
Jeg vil uansett gi videre til Dez; Jeg er sikker på at han har noen interessante spørsmål.
Dez Blanchfield: Takk, ja, det gjør jeg. Jeg skal bli med deg i å ikke kaste programmerere under bussen. Jeg mener, jeg har brukt for mange år i livet mitt på å være en koder selv, på alle nivåer, vet du, om det er som du sa, sitter på kommandolinjen til Unix-maskinen, og i noen tilfeller var jeg til og med involvert i et par forskjellige porter på Unix fra en maskinvareplattform til en annen. Og du kan forestille deg utfordringene vi hadde der. Men virkeligheten er her det få-out-of-fengsel kortet for alle kodere og manus i verden. Det er en rakettvitenskap, bokstavelig talt, å skrive skikkelig tett hver gang, hele tiden, er en rakettvitenskap. Og berømte historier om mennesker som Dennis Ritchie og Brian Kernahan som arbeider på et eller annet stykke kode uavhengig av hverandre, for deretter å slå til en kodevurderingsprat over en kaffe og finne ut at de hadde skrevet nøyaktig det samme kodestykket, i nøyaktig samme program, på nøyaktig samme måte. Og de gjorde det i C. Men det puristiske programmeringsnivået eksisterer veldig sjelden.
Faktum er at det hver dag bare er 24 timer i døgnet, syv dager i uken, og vi må bare gjøre ting. Og så, når det gjelder ikke bare tradisjonelle programmerere, DBA-er, og kodere, og manusforfattere, og sysadmin, og nettverksadministratorer, og sikkerhetspersonell, og alt helt gjennom til innbyggerens dataside i disse dager; vi hører, alle prøver bare å gjøre jobben sin. Og så jeg tror den store takeawayen fra hele denne saken er at jeg elsket demoen din, og jeg elsket takeawayen som du forlot oss der, bare for et øyeblikk siden, og snakket med Robin om det faktum at dette har en spesiell - kanskje ikke så mye en nisje - men et bredt rom som det gjelder, så langt som å fikse kode og SQL og databaser. Men jeg var veldig spent på å høre deg si at du kunne pirke det på et shell-script og finne noen problemer, fordi du vet, i dagens tidsalder jobber vi alltid til lavest mulig pris på alt.
Grunnen til at du kan kjøpe en $ 6 skjorte et sted, er fordi noen bygde et system billig nok til å faktisk produsere og sende og logistisk levere og selge og detaljhandel og ta online betalinger for å få den $ 6 skjorten. Og det skjer ikke hvis du har fått folk som blir betalt 400 000 dollar i året for å skrive kode på den perfekte måten; det er bare hele utviklingen. Så det poenget, antar jeg at ett av spørsmålene jeg virkelig vil elske at du bare gir oss litt mer innsikt, er hvor bredden og rekkevidden til den typen mennesker du ser for øyeblikket som bruker slike verktøy for å profilere en kode og se etter ytelsesproblemer? Opprinnelig, historisk sett, hvor kommer de fra? Har de vært de store ingeniørhusene? Og fremover, er det tilfelle, har jeg rett i å tenke at flere og flere selskaper implementerer dette verktøyet, eller disse verktøyene, for å prøve å hjelpe kodere, som de vet hvem som bare gjør ting gjort for å få jobben ferdig og få den ut døra? Og noen ganger trenger vi et get-out-of-fengsel-kort? Har jeg rett i å tenke at vi historisk sett hadde et mer teknisk fokus og utvikling? At vi nå får en mindre, som Robin sa, akademisk tilnærming, og nå er det selvlært, eller klipp ut og lim inn kode, eller bare få ting bygget? Og stemmer det med den typen mennesker som tar produktet på nå?
Bert Scalzo: Ja, akkurat. Og jeg vil gi deg et veldig spesifikt eksempel, vi vil bare gjøre jobben gjort, fordi forretningsfolkene ikke ønsker perfeksjon. Det er på samme måte som et datastyrt sjakkspill: sjakkspillet ser ikke etter det perfekte svaret; det ser etter et svar som er godt nok på rimelig tid, så det er slik vi programmerer. Men det jeg finner nå, er at de fleste i stedet for å si at de vil ha en profiler som en del av enhetstestingene sine - og det er slik jeg ville gjort det, fordi jeg ikke ser det som bortkastet tid - det som skjer er nå som det gjøres senere, noen ganger under integrasjonstesting eller stresstesting, hvis vi er heldige. Men de fleste gangene er det en del av en opptrapping, der noe har gått i produksjon, det løp en stund, kanskje til og med løp i årevis, og nå går det ikke bra, og nå skal vi profilere det. Og det ser ut til å være det mer vanlige scenariet nå.
Dez Blanchfield: Ja, og jeg tror at begrepet "teknisk gjeld" sannsynligvis er en du er mer enn kjent med; Jeg kjenner Robin og det er jeg absolutt. Jeg tror i disse dager, spesielt i smidige tilnærminger til utvikling og systembygging, for meg at begrepet teknisk gjeld nå er en veldig ekte ting, og vi står faktisk for det i prosjekter. Jeg vet, jeg mener, vi har egne prosjekter som medieobjektivet og andre, der vi har koding som skjer daglig, og forskjellige ting i hele Bloor Group. Og når vi bygger noe, så ser vi på det, jeg ser på det, og ser alltid på fra hva det vil koste meg å fikse dette akkurat nå, kan jeg bare få det i kan og få det ut der, og så se og se om denne tingen kommer til å gå i stykker. Og arve denne tekniske gjelden som jeg vet at jeg må komme tilbake senere og fikse.
Og jeg mener, jeg har gjort det de siste syv dagene: Jeg har skrevet et par verktøy og skript, jeg har skrevet et par stykker av Python-språket, og jeg har distribuert det til Mongo back end sikker på at det er fint og rent og sikkert, men det blir bare spørsmålet jeg trenger, å vite at jeg trenger den funksjonen for å fungere, for å komme til det større puslespillet; det er der de virkelige smertene mine er. Og så påfører du deg denne tekniske gjelden, og jeg tror dette ikke bare er en og annen ting, jeg tror dette er en del av DNA-en for å utvikle seg nå. Folk bare - ikke uanstendig - de bare aksepterer at den tekniske gjelden er en normal modus operandi type problemstilling, og de må bare pådra seg den. Det er der du påfører deg den tekniske gjelden. Og jeg synes det fantastiske med det du viste oss i demoen, var at du bokstavelig talt kan profilere og se hvor lang tid noe tar å løpe. Og det er nok en av favoritt tingene mine. Jeg mener, jeg har faktisk bygd profilverktøy - vi bygde verktøy i Sed og Lex og Orc for å kjøre koden vår og se hvor løkkene var, før verktøy som dette var tilgjengelig - og når du har bygget kode for å gå og gjennomgå din egen kode, du blir veldig flink til å slippe å gjennomgå din egen kode. Men det er ikke tilfelle nå. Med det i bakhodet, er det et bestemt markedssegment som tar dette opp mer enn noen annen? Ser ut som en masse -
Bert Scalzo: Å ja, jeg har det - jeg skal tegne en analogi for deg, og vise deg at ikke-programmerere gjør det hele tiden. For hvis jeg noen gang underviser i en debugger og profilerer klasse eller økt, vil jeg spørre folk: "OK, hvor mange mennesker her inne går inn i Microsoft Word og målbevisst bruker aldri stavekontrollen?" Og ingen legger hånden opp, fordi for å skrive dokumenter, vet vi alle at vi kan gjøre engelske feil, og slik at alle bruker stavekontrollen. Og jeg sa: "Vel, hvordan kommer du til å bruke feilsøking når du skriver tekst i IDE-en som Visual Basic? Det er det samme, det er som en stavekontroll. ”
Dez Blanchfield: Ja, faktisk, det er en flott analogi. Jeg hadde egentlig ikke tenkt på, jeg må innrømme at jeg faktisk gjør noe lignende med et par verktøy jeg bruker. Faktisk, en, ODF, min favoritt med Eclipse er bare å klippe ut og lime inn kode der inne og gå og lete etter ting som bare fremheve umiddelbart og innse at jeg har laget en skrivefeil i en klassesamtale. Og, men det er interessant nå med verktøyet som dette kan du gjøre det i sanntid i motsetning til å komme tilbake og se på det senere, noe som er ganske fint å fange det på forhånd. Men ja, det er en flott analogi å bare sette tekst i en tekstbehandler, for det er en interessant vekker som bare er klar over at du har laget noen skrivefeil eller til og med en grammatikkfeil, ikke sant?
Bert Scalzo: Akkurat.
Dez Blanchfield: Så, ser du mer av en uptick nå, antar jeg det endelige spørsmålet fra meg, før jeg kaster til spørsmål og svar for våre deltagere. Hvis du skulle gi en slags anbefaling rundt tilnærmingen til å gjøre dette - jeg antar at dette er retorisk - er det slik at du kommer inn tidlig og får dette implementert mens du utvikler deg, før du utvikler deg? Eller er det slik at du overveiende får bygning, får flytte, bygge noe for så å komme inn og profilere det senere? Jeg mistenker at det er tilfelle å komme inn tidlig og sørge for at koden din er ren på forhånd. Eller er det slik at de bør vurdere denne delen av postdistribusjonen?
Bert Scalzo: Helst ville de gjøre det på forhånd, men fordi alle er i den travle verden hvor de bare fikk gjort ting, pleier de ikke å gjøre det før de får et ytelsesproblem som de ikke kan løse med legge til flere CPUer og minne til en virtuell maskin.
Dez Blanchfield: Ja. Så, faktisk nevnte du noe interessant, hvis jeg raskt kan? Du nevnte før at dette kan kjøres hvor som helst, og kan snakke med databasen på baksiden. Så dette er komfortabelt med den typen bimodale konsept vi snakker om nå, av skyen på stedet / utenfor lokalet, ved tingenes utseende også, på slutten av dagen, hvis den kan snakke med baksiden og se koden, det bryr seg ikke egentlig, gjør det ikke?
Bert Scalzo: Akkurat, ja, du kan kjøre dette i skyen.
Dez Blanchfield: Utmerket, for jeg tror det er slags hvor vår nye modige verden går. Altså Eric. Jeg kommer til å kaste deg tilbake til deg nå og se at vi har noen få spørsmål her, og jeg vil at de fremmøtte fortsatt skal være hos oss, selv om vi har gått forbi timen.
Eric Kavanagh: Ja, det er noen få folk der ute, jeg vil bare komme med en rask kommentar: Bert, jeg synes at metaforen, analogien du gir til å bruke stavekontroll, er helt ærlig. Det er en blogg eller to verdig, helt ærlig, fordi det er en god måte å ramme opp sammenhengen til hva det er du gjør, og hvor verdifull det er, og hvordan det virkelig skal være en god praksis å bruke en debugger med jevne mellomrom, ikke sant? Jeg vedder på at du får noen hoder som nikker når du kaster den ut, ikke sant?
Bert Scalzo: Absolutt, for det jeg sier til dem er: "Hvorfor kjører jeg stavekontroll på dokumentene mine? Jeg vil ikke bli flau over dumme stavefeil. ”De vil ikke være flau av dumme kodefeil!
Eric Kavanagh: Rett. Ja absolutt. Vel, folkens, vi har brent gjennom en time og fem minutter her, så stor takk til dere alle der ute for deres tid og oppmerksomhet. Vi arkiverer alle disse nettpratene, kom gjerne tilbake når som helst og sjekk dem ut. Det beste stedet å finne disse koblingene er sannsynligvis techopedia.com, så vi vil legge dette til denne listen her.
Og med det skal vi ta farvel, folkens. Nok en gang, god jobb, Bert, takk til vennene våre fra IDERA. Vi snakker med deg neste gang, vi snakker med deg neste uke, faktisk. Ha det fint! Ha det.
