Av Techopedia Staff, 15 mars 2017
Takeaway: Värd Eric Kavanagh diskuterade felsökning och profilering av databaser med Dr. Robin Bloor, Dez Blanchfield och IDERAs Bert Scalzo.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar, det är 4:00 östlig tid på en onsdag, och det betyder naturligtvis.
Robin Bloor: Kan inte höra dig, Eric.
Eric Kavanagh: Jag var där för några dagar sedan, så du är inte ensam. Men så är ämnet idag riktigt intressant. Det är den typen som du vill se till att händer i bakgrunden hos ditt företag, såvida du inte är personen som gör det, i vilket fall du vill se till att du gör det ordentligt. För vi pratar om felsökning. Ingen gillar buggar, ingen gillar när programvaran slutar fungera - människor blir upprörda, användare blir ovänliga. Det är inte bra. Så vi ska prata om "Snabbt svar: felsökning av databaser och profilering till räddningen."
Det finns en plats om din verkligen, slå mig upp på Twitter, naturligtvis @eric_kavanagh.
Det här året är varmt. Och felsökning kommer att bli het, oavsett vad. Det kommer verkligen att vara ett av dessa problem som aldrig kommer att försvinna, oavsett hur bra vi har på det här, det kommer alltid att vara problem, så nyckeln är hur kommer du dit du kan lösa dessa problem snabbt? Helst har du fantastiska programmerare, fantastiska miljöer, där inte alltför mycket går fel, men som det gamla ordstävet säger: "Olyckor inträffar i bästa familjer." Och detsamma gäller för organisationer. Så det här händer, det kommer att hända, frågan är vad som kommer att vara din lösning för att hantera det och lösa dessa problem?
Vi kommer att höra från Dr. Robin Bloor, sedan vår egen Dez Blanchfield underifrån, och naturligtvis vår goda vän, Bert Scalzo, från IDERA. Och jag kommer faktiskt att dela ut nycklarna till Robin Bloor, ta bort den. Golvet är ditt.
Robin Bloor: OK. Detta är ett intressant ämne. Jag tänkte eftersom Dez förmodligen kommer att fortsätta med de faktiska teknikerna och krigsberättelserna om felsökning, jag tänkte att jag bara skulle göra en bakgrundsdiskussion så att vi skulle få en helt rund bild av vad som händer. Jag gjorde detta länge och brukade vara en kodare, så det är som, och jag blev nästan frestad av denna presentation att börja växa lyriskt om idén om öppen källkod, men jag trodde att jag skulle lämna det till någon annan.
Här är en lista över berömda buggar, och de flesta av dessa kommer in på någons topplista, i princip alla utom de två sista kostar minst 100 miljoner dollar. Den första var Mars Climate Orbiter, gick vilse i rymden och det var på grund av ett kodningsproblem, där människor förvirrade metriska enheter med (skratt) fötter och tum. Ariane Five Flight 501 var ett missförhållande mellan en motor som sattes på och datorerna som skulle driva raketen när den startades. Flera datorfel, exploderande raket, rubriknyheter. Sovjetiska gasledningar 1982, sägs vara den största explosionen i planetens historia; Jag är inte säker på om det är det. Ryssarna stal lite automatiserad kontrollprogramvara, och CIA insåg att de skulle göra det och lägga buggar i det, och sovjeterna implementerade det utan att testa. Så, blåste en pipeline upp, tyckte det var underhållande.
Morris-masken var ett kodningsförsök, som plötsligt blev en våldsam mask som gick runt alla - det uppenbarligen orsakade skador på 100 miljoner dollar; det är naturligtvis en uppskattning. Intel gjorde ett berömt fel med ett matematikchip - en matematisk instruktion på Pentium-chipet 1993 - som skulle ha kostat över 100 miljoner dollar. Apples Maps-program är kanske den värsta och mest katastrofala lanseringen av allt som Apple någonsin har gjort. Människor som försökte använda det var, menar jag, någon körde längs 101 och upptäckte att Apple Map sa att de befann sig mitt i San Francisco Bay. Så folk började hänvisa till Apple Maps-appen som iLost. Det - vårt längsta strömavbrott 1990 - det är bara intressant ur en synvinkel på kostnaden för något liknande - AT&T var ute i nio timmar och det kostade cirka 60 miljoner dollar i långdistanssamtal.
Och jag var på ett brittiskt försäkringsbolag, och databasen, de implementerade en ny version av databasen och det började rensa data. Och jag kommer ihåg det extremt väl, för jag kallades in efteråt för att delta i ett slags databasval på grund av det. Och det var mycket intressant att de hade tagit en ny version av databasen, och de hade ett batteri av tester som de gjorde för nya versioner av databasen att den klarat alla tester. Det hittade ett riktigt otydligt sätt att rensa data.
Så i alla fall är det det. Jag trodde att jag skulle prata om impedansmatchningen och SQL som utfärdats. Det är intressant att relationsdatabaser lagrar data i tabeller och kodare tenderar att manipulera data i objektstrukturer som verkligen inte kartlägger särskilt bra till tabeller. Och på grund av det får du det som kallas impedansmatchning, och någon måste hantera det på något eller annat sätt. Men vad som faktiskt händer, eftersom en modell, kodarens modell och databasen en annan modell, är inte särskilt anpassade. Du får buggar som bara inte skulle hända om branschen hade byggt saker som fungerar tillsammans, vilket jag tycker är lustigt. Så i princip, på kodarens sida, när du får hierarkier kan det vara typer, det kan resultera i uppsättningar, det kan vara dålig API-kapacitet, det kan vara en hel del saker som bara slänger ut i termer interaktion med databasen. Men det som är mest för mig, riktigt intressant; förvånade mig alltid att du hade denna SQL-barriär som också är en slags impedans på ett sätt som kodarna och databasen fungerar med varandra. Så SQL har dataigenkänning, vilket är bra och det har DML för att välja, projicera och gå med, vilket är bra. Du kan kasta mycket kapacitet när det gäller att få data ur databasen med det. Men det har väldigt lite matematiskt språk för att göra saker. Det har lite av det här och det, och det har väldigt lite tidsbaserat grejer. Och på grund av detta är SQL ett omöjligt, om du vill, ett sätt att hämta data. Så databasgubbarna byggde lagrade procedurer för att leva i databasen och orsaken till de lagrade procedurerna som bodde där var att du egentligen inte ville kasta data fram och tillbaka till ett program.
För en del av funktionaliteten var extremt dataspecifik, så det var inte bara referensintegritet och raderade kaskader och liknande saker, databasen tog hand om helt plötsligt du lägger till funktionalitet i en databas, vilket naturligtvis betydde att funktionaliteten för en applikation kan delas mellan kodaren och själva databasen. Och det gjorde jobbet med att implementera vissa typer av funktioner verkligen ganska svårt och därför mer benägna att göra fel. Så det är en sida av databasspelet, eftersom det betyder att du har fått många implementationer till exempel, att jag har varit inblandad i relationsdatabaser finns det verkligen en hemsk massa kod som finns i lagrade procedurer som hanteras separat från koden som finns i applikationerna. Och det verkar som en väldigt konstig sak att ha fått, det ska vara ganska smart att göra olika saker.
Jag trodde att jag också skulle prata om databasprestanda eftersom prestandafel ofta betraktas som buggar, men i princip kan du ha en flaskhals på CPU, i minnet, på disken, i nätverket och du kan ha prestandaproblem på grund av låsning . Tanken skulle vara att kodaren egentligen inte behövde vara bekymrad över prestanda och databasen skulle faktiskt fungera rimligt bra. Det ska vara utformat så att kodaren inte behöver veta. Men du får dålig databasdesign, får dålig programdesign, du får samtidighet i arbetsbördsblandning, vilket också kan leda till prestandaproblem. Du får lastbalansering, du får kapacitetsplanering, datatillväxt - vilket kan göra att en databas bara stannar eller saknar ner. Det är en intressant sak, när databaser blir nästan fulla saknar de. Och du kan ha problem med dataskikt när det gäller replikering och behovet av att kopiera och behovet av att göra säkerhetskopiering och återställning. Hur som helst, det är en allmän översikt.
Det enda som jag skulle vilja säga är att databasfelsökning bara kan vara så besvärlig och icke-trivial - och jag säger det för att jag har gjort mycket av det - och du kommer ofta att upptäcka att det är som alla situationer i felsökning som jag någonsin upplevt är, är det första du någonsin ser är en röra. Och du måste försöka gå från röra till att räkna ut hur röran kom till. Och ofta när du tittar på en databasfråga, allt du tittar på är korrupta data och du tänker: "Hur i helvete hände det?"
Hur som helst, jag ska vidarebefordra till Dez, som antagligen kommer att säga fler visdomsord än jag kom ut med. Jag vet inte hur jag skickar bollen, Dez.
Eric Kavanagh: Jag ska passera det, stå vid, hålla i.
Automatiserad röst: Deltagarraderna tystas.
Eric Kavanagh: Okej, vänta en sekund, låt mig ge Dez bollen.
Dez Blanchfield: Tack, Eric. Ja, Dr. Robin Bloor, du har verkligen mest korrekta: detta är ett ämne, ett livslångt bugbear om du kommer att förlåta ordspillet, ledsen att jag inte kunde hjälpa mig själv med det. Förhoppningsvis kan du se min första skärm där, min ursäkt för problemet med fontstorlek längst upp. Ämnet med buggar är en dagslång föreläsning, i många fall enligt min erfarenhet. Det är ett så brett och brett ämne, så jag kommer att lägga fokus på två viktiga områden, särskilt begreppet vad vi anser som mycket ett fel, men en programmeringsfråga. Jag tror att idag att införa ett bugg i sig generellt plockas upp av de integrerade utvecklingsmiljöerna, även om de kan vara långvariga buggar. Men ofta handlar det mer om att profilera kod och det är möjligt att skriva kod som fungerar, det borde vara ett fel. Så min titel glider här, jag hade faktiskt en kopia av detta i mycket högupplöst A3, men tyvärr förstördes det i en flyttning. Men det här är en handskriven anteckning på ett programmeringsblad från cirka 1945, där förmodligen en del folk vid Harvard University i USA, deras andra byggnad av en maskin som heter Mark II. De felsöker en fråga, på vanligt språk, men de försökte hitta ett fel, och det visar sig att något något annorlunda än vad som var en hårdvara och ett förment programvaruproblem kom med.
Så den urbana myten är att omkring den 9 september 1945 samlade ett team vid Harvard University en maskin, de stötte på något som de kallade ”relä sjuttio” - i dessa dagar programmerades det i fysisk mening, du sår kod runt ett bräde, och det var så du programmerade maskinen effektivt - och de tyckte att det här relänumret sjuttio var det något fel med, och det visar sig att själva termen "bug" kom till eftersom det bokstavligen var en mal - förmodligen där var en mull kilad in mellan en bit koppartråd som gick från en plats till en annan. Och berättelsen berättar att den legendariska Grace Hopper som den här bildtexten, för min titelruta, "första faktiska fallet om en bugg hittades" citat unote.
Men som Robin påpekade tidigare i sin första bild, går konceptet med ett fel så långt tillbaka som vi kan föreställa oss att människor gör beräkningar, begrepp som en lapp. Uttrycket "patch" kom från en verklig tejp som tejpades över ett hål på ett stanskort. Men hela poängen med detta är att termen "felsökning" kom ut ur detta koncept att hitta ett fel i en fysisk maskin. Och sedan dess har vi använt den terminologin kring att försöka hantera problem, antingen inte så mycket som kodningsproblem i ett program som inte kompilerar, men som ett program som inte fungerar bra. Och specifikt har inte profilerats bara hitta saker som oändliga öglor som bara går ingenstans.
Men vi har också ett scenario, och jag trodde att jag skulle lägga in ett par roliga bilder innan jag fick lite mer detalj. Här är den klassiska tecknade filmen, kallad XKCD på webben, och tecknad filmisten har några ganska roliga syn på världen. Och den här handlar om ett barn som heter "Little Bobby Tables" och förmodligen hans föräldrar heter den här unga pojken Robert '); DROP TABELL Studenter; - och det heter, och sorts "Hej, det här är din sons skola som har vissa datorproblem, " och föräldern svarar, "Åh, kära, bröt han något?" Och läraren säger: "Tja, på ett sätt ”, och läraren frågar, ” namngav du verkligen din son Robert ”); DROP TABELL Studenter; -? ”Och föräldern säger:” Åh ja, lilla Bobby-bord vi kallar honom. ”Hur som helst, de fortsätter med att säga att de nu har tappat årets studentrekord, jag hoppas att du är lycklig. Och svaret är: "Tja, du bör rengöra och desinficera dina databasingångar." Och jag använder det många gånger för att prata om några av de problem vi har för att hitta saker i kod, att koden ofta inte tittar på uppgifterna också.
En annan rolig, jag vet inte om detta är verkligt eller inte - jag misstänker att det är en falsk - men återigen, det berör också mitt roliga ben. Någon byter registreringsskylt på framsidan av sin bil, till ett liknande uttalande som får databaser att släppa in hastighetskameror och så vidare som fångar bilarnas registreringsskyltar. Och jag hänvisar alltid till det som att jag tvivlar på att någon programmerare förutsåg en hit och körning av deras kod av ett verkligt motorfordon, men aldrig underskattar den - kraften hos en arg nörd.
(Skratt)
Men detta leder till mig till min nyckelpunkt, antar jag, och det är att vi en gång i tiden kunde felsöka och profilera kod som bara dödliga. Men jag tycker mycket om att den tiden har gått, och anekdotiskt i min erfarenhet, min första - och detta kommer att åldras mig väldigt, jag är säker; Robin, du är välkommen att tänka på mig för detta - men historiskt sett har jag kommit från en bakgrund vid 14 års ålder och vandrade i slutet av staden och knackat på dörren till ett datacenter som heter "Data Com" i Nytt Zeeland och fråga om jag kunde tjäna fickpengar på skolan genom att få den sena bussen hem, cirka 25 km pendel varje dag, genom att lägga papper i skrivare och band i banddrev och bara vara en allmän administratör. Och märkligt nog gav de mig ett jobb. Men med tiden lyckades jag komma in i bemanningen och hitta programmerarna och insåg att jag älskade kodning och gick igenom processen med att köra skript och batchjobb, som i slutet av dagen fortfarande är kod. Du måste skriva skript och batchjobb som ser ut som miniprogram och sedan gå igenom hela processen med att sitta på en 3270 terminal skriva kod för hand.
I själva verket var min allra första erfarenhet på en teletypterminal, som faktiskt var 132-kolonnens fysiska skrivare. Tänk på som en mycket gammal skrivmaskin med papper som bläddrade igenom det, för de hade inte ett CRT-rör. Och felsökningskod i det var en mycket icke-trivial fråga, så du brukade skriva alla dina koder för hand och sedan agera som en typist, gör ditt bästa för att inte få fel att smyga in, eftersom det är extremt frustrerande att behöva berätta den enradiga redigeraren för att gå till en viss rad och sedan skriva ut raden och sedan skriva in den igen. Men en gång i tiden var det så vi skrev kod och det är så vi felsökte, och vi blev väldigt, väldigt bra på det. Och i själva verket tvingade det oss att ha mycket bra programmeringstekniker, eftersom det var ett riktigt besvär att fixa det. Men resan gick sedan igen - och vi är alla bekanta med detta - det gick från 3270 terminalupplevelse i min värld, till Digital Equipment VT220 där du kunde se saker på skärmen, men igen, du gjorde bara samma sak du gjorde på pappersbandet typ av tryckt format bara på en CRT, men du kunde ta bort lättare och du hade inte det "dit dit dit dit" -ljudet.
Och då vet du, Wyse-terminalerna - som Wyse 150, förmodligen mitt favoritgränssnitt till en dator någonsin - och sedan PC och sedan Mac, och sedan idag moderna GUI och ID som är webbaserade. Och en rad program genom det, programmering i ett och assembler och PILOT och Logo och Lisp och och Fortran och Pascal och språk som kan få människor att krypa. Men det här är språk som tvingade dig att skriva bra kod; de släppte dig inte bort med dålig praxis. C, C ++, Java, Ruby, Python - och vi kommer längre upp i det programmeringsstadiet, vi blir mer skriptliknande, vi kommer närmare och närmare strukturerade frågespråk och språk som PHP som faktiskt används för att åberopa SQL. Poängen med att berätta att det var, från min bakgrund, jag var självlärd på många sätt och de som hjälpte mig att lära mig, lärde mig väldigt bra programmeringspraxis och mycket bra metoder kring design och processer för att se till att jag inte gjorde det introducera buggy-kod.
Programmeringsmetoder i dag, saker som till exempel Structured Query Language, SQL, det är ett mycket kraftfullt, enkelt frågespråk. Men vi har förvandlat det till ett programmeringsspråk och jag tror inte riktigt att SQL någonsin har utformats för att vara ett modernt programmeringsspråk, men vi har skev det för att bli det. Och det introducerar en hel massa frågor, för när vi tänker på från två synvinklar: ur kodningssynpunkt och från DBA-synvinkel. Det är väldigt lätt att komma med och introducera buggar för saker som bara dålig programmeringsteknik, lata ansträngningar för att skriva kod, brist på erfarenhet, den klassiska husdjurskalan som jag har till exempel med SQL-människor som hoppar på Google och söker efter något och hitta en webbplats som är fick ett exempel och göra en kopia och klistra in existerande kod. Och sedan kopiera en dålig kodning, felbehandling och sätta den i produktion, eftersom det bara råkar ge dem de resultat de vill ha. Du har andra utmaningar, till exempel i dessa dagar rusar vi alla mot detta, det vi kallar loppet till noll: försöker göra allt så billigt och så snabbt, att vi har ett scenario där vi inte använder lägre -betald personal. Och jag menar inte det på ett otänkbart sätt, men vi anställer inte experter för alla möjliga jobb. En gång i tiden var allt med datorer att göra med raketvetenskap; det var involverat i saker som gick hårt och var väldigt högt, eller gick ut i rymden eller ingenjörer var mycket kvalificerade män och kvinnor som hade gjort examen och haft rigorösa utbildningar som hindrade dem från att göra galna saker.
Idag är det mycket folk som kommer in i utveckling och design och databas som inte har haft många års erfarenhet, inte nödvändigtvis har haft samma utbildning eller support. Och så slutar du med ett scenario med bara den traditionella amatör kontra experten. Och det finns en berömd linje, jag kan faktiskt inte komma ihåg vem som skapade offerten, linjen går, "Om du tycker att det är dyrt att anställa en expert för att göra ett jobb, vänta tills du anställer ett par amatörer som skapar ett problem och du måste städa upp det. ”Och så har SQL den frågan, och det är väldigt, väldigt lätt att lära sig, det är väldigt lätt att använda. Men det är enligt min mening inte ett perfekt programmeringsspråk. Det är väldigt lätt att göra saker som att göra en utvald stjärna var som helst och dra allt det till ett programmeringsspråk som du är mer bekväm med som PHP och Ruby eller Python, och använda det programmeringsspråk som du är bekant med för att göra datamanipulationen, snarare än att göra en mer komplex fråga i SQL. Och vi ser detta mycket, och då undrar folk varför databasen går långsamt; Det beror på att en miljon människor försöker köpa en biljett från ett online-biljetteringssystem, där det gör en utvald stjärna var som helst.
Nu är det ett riktigt extremt exempel, men du får poängen med allt detta. Så, för att verkligen slå den punkten hem, här är ett exempel som jag bär på mycket. Jag är ett stort fan av matematik, jag älskar kaosteori, jag älskar Mandelbrot-uppsättningarna. På höger sida finns det en version av Mandelbrot-uppsättningen, som jag är säker på att vi alla är bekanta med. Och till vänster finns det en bit SQL som faktiskt gör det. Nu, varje gång jag lägger detta på en skärm någonstans, hör jag detta “Åh herregud, någon gjorde Mandelbrot-serien med SQL, är du seriös? Det är galen! ”Tja, hela poängen med det är att illustrera vad jag just skisserade där, och det är ja, du kan faktiskt programmera nästan vad som helst i SQL; det är ett mycket kraftigt utvecklat, kraftfullt, modernt programmeringsspråk. När det ursprungligen var ett frågespråk, utformades det för att bara få upp data. Så nu har vi väldigt komplexa konstruktioner och vi har lagrade procedurer, vi har programmeringsmetodik som används på ett språk och så det är väldigt lätt för dålig programmeringspraxis, brist på erfarenhet, klipp och klistra in kod, lågbetald personal som försöker vara högt betald personal, människor som låtsas att de känner, men de måste lära sig på jobbet.
En hel rad saker där kodprofilering och vad vi kallar felsökning, som inte är så mycket att hitta buggar som hindrar program från att fungera, men buggar som bara skadar systemet och dåligt strukturerad kod. När du tittar på den här skärmen nu, och du tänker, det är bara det, det är lite söt och du tänker, "Wow, vilken bra grafik, jag skulle gärna vilja köra det." Men föreställ dig att det kör på en viss affärslogik . Det ser ganska snyggt ut, men det talar en matematisk grafiskt framförd kaosteori, men när du tänker på vad den potentiellt kan användas för i någon affärslogik får du bilden mycket snabbt. Och för att verkligen illustrera det - och jag är ledsen att färgerna är omvända, det ska vara en svart bakgrund och grön text som en grön skärm, men du kan fortfarande läsa det.
Jag gick och tittade snabbt på ett exempel på vad du potentiellt kan göra om du verkligen var galen och inte hade någon erfarenhet överhuvudtaget och kom från en annan programmeringsbakgrund och använde liknande C ++ på SQL för att verkligen illustrera min poäng, innan Jag överlämnar till vår lärda gäst från IDERA. Detta är en strukturerad fråga som är skriven som C ++, men den är kodad i SQL. Och det verkar verkligen, men det körs under en period på tre till fem minuter. Och det drar till synes en rad med data ur flera databaser, flera sammanfogningar.
Återigen, hela poängen med detta är att om du inte har rätt verktyg, om du inte har rätt plattformar och miljöer för att kunna fånga dessa saker, och de kommer i produktion, och då har du 100 000 människor träffar ett system varje dag, timme eller minut, mycket snart hamnar du med en Tjernobyl-upplevelse där det stora järnet börjar smälta ner och begrava sig själv till planetens kärna, för den kodkoden borde aldrig komma i produktion. Dina system och dina verktyg, ursäkta mig, borde plocka upp det innan det går någonstans nära - till och med genom testprocessen, även genom UAT och systemintegration, ska den kodkoden plockas upp och markeras och någon ska tas åt sidan och säger, "Titta, det är verkligen ganska kod, men låt oss få en DBA som hjälper dig att bygga den strukturerade frågan ordentligt, för ärligt talat, det är bara otäckt." Och webbadressen är där, du kan gå och titta - det kallas den den mest komplexa SQL-frågan du någonsin skrev. För tro mig, det faktiskt kompilerar, det körs. Och om du klipper och klistrar in det och bara håna upp databasen, är det ganska något att titta på; Om du har verktygen för att titta på databasen, försök bara smälta ner under en period på tre till fem minuter, för att ringa tillbaka vad som är en textrad.
Så för att sammanfatta, med det i åtanke, har hela min bakgrund inom kodning lärt mig att du kan ge människor en pistol och om de inte är försiktiga kommer de att skjuta sig själva i foten; tricket är att visa dem var säkerhetsmekanismen är. Med rätt verktyg och rätt programvara till hands, efter att du har gjort kodningen kan du granska din kod, du kan hitta problem genom att profilera koden, du kan hitta effektiva oavsiktliga buggar som är prestandaproblem, och som sagt tidigare, en gång i tiden, kan du göra det med att titta på en grön skärm. Du kan inte längre; det finns hundratusentals rader med kod, det finns tiotusentals appar som används, det finns miljoner databaser i vissa fall, och till och med supermänskor kan faktiskt inte göra det för hand längre. Du behöver bokstavligen rätt programvara och rätt verktyg till hands och du behöver att teamet ska använda dessa verktyg, så att du kan hitta dessa problem och hantera dem mycket, mycket snabbt innan du kommer till saken, medan Dr. Robin Bloor framhävde, saker blir antingen katastrofala och saker sprängs, eller mer vanligt, de börjar bara kosta dig en hel del dollar och mycket tid och ansträngning och förstöra moral och grejer, när de inte kan räkna ut varför saker tar en lång tid att springa.
Och med det i åtanke ska jag överlämna till vår gäst och jag ser fram emot att höra hur de har löst det här problemet. Och särskilt den demon som jag tror att vi håller på att få. Eric, jag ska gå tillbaka igen.
Eric Kavanagh: OK, Bert, ta bort det.
Bert Scalzo: OK, tack. Bert Scalzo här från IDERA, jag är produktansvarig för våra databasverktyg. Och jag ska prata om felsökning. Jag tror att en av de viktigaste sakerna som Robin sa tidigare - och det är mycket sant är att felsökning är besvärlig och icke-trivial, och när du går till databasfelsökning är det en storleksordning ännu mer besvärlig och icke-trivial - så, att var ett viktigt citat.
OK. Jag ville börja med programmeringshistorik, för många gånger ser jag människor som inte felsöker, de använder inte en felsökare, de programmerar bara med vilket språk de använder och många gånger kommer de säga till mig, "Tja, de felaktiga sakerna är nya, och vi har inte börjat använda dem ännu." Och så vad jag gör är att jag visar dem detta tidslinjediagram, slags förhistoria, ålderdom, medeltiden, det är snäll att säga var var vi när det gäller programmeringsspråk. Och vi hade väldigt gamla språk från 1951 med monteringskod och Lisp och FACT och COBOL. Sedan kommer vi in i nästa grupp, Pascals och Cs och sedan nästa grupp, C ++, och titta var det frågetecknet är - det frågetecknet är ungefär ungefär 1978 till kanske 1980. Någonstans i det intervallet hade vi debuggers tillgängliga för oss, och så att säga, "Hej, jag använder inte en debugger, för det är en av de nya sakerna", då måste du ha börjat programmera, du vet redan från 1950-talet, för det är det enda sättet du skulle komma undan med påståendet.
Det andra som är roligt med det här diagrammet är Dez som bara kommenterade Grace Hopper, jag kände faktiskt Grace, så det är ganska roligt. Och sedan det andra jag skrattade åt är att han pratade om teletyper och jag sitter där och går, ”Man, det var det största språnget vi någonsin har haft i produktiviteten, när vi gick från kort till teletyper, det var det största hoppet någonsin. ”Så, och jag har programmerat på alla språk här, inklusive SNOBOL, som ingen någonsin har hört talas om förut, det var ett CDC, Control Data Corporation, så jag antar att jag blir lite för gammal för den här branschen .
Dez Blanchfield: Jag tänkte säga att du har åldrats oss hemskt där.
Bert Scalzo: Ja, jag säger det, jag känner som morfar Simpson. Så jag tittar på felsökning och det finns olika sätt att göra felsökning. Du kan prata om vad vi alla tycker om som traditionella att komma in i en felsökare och gå igenom koden. Men också människor kommer att instrumentera sin kod; det är där du fäster uttalanden i din kod och kanske producerar du en utdatafil, en spårningsfil eller något, så att du instrumenterar din kod. Jag skulle räkna det som felsökning, det är lite svårare, ett sätt att göra det, men det räknas. Men också, vi har det berömda uttalandet: du tittar på och människor lägger faktiskt ut påståenden och jag har faktiskt sett ett verktyg där - och det är ett databasverktyg - där om du inte vet hur man använder en felsökare, du trycker på en knapp så kommer det att trycka utskrifter i hela koden för dig och sedan när du är klar trycker du på en annan knapp och den raderar dem ut. För det är så många människor felsöker.
Och anledningen till att vi felsöker är tvåfaldiga: för det första måste vi hitta saker som gör vår kod ineffektiv. Med andra ord betyder det vanligtvis att det finns ett logiskt misstag eller att vi missade ett affärskrav, men vad det är är koden inte är effektiv. det gör inte vad vi förväntade oss att göra. Den andra gången vi går och vi debuggar, det är för effektivitet och det kan vara ett logiskt misstag, men vad det är, är jag gjorde rätt, det kommer bara inte tillbaka tillräckligt snabbt. Nu gör jag den punkten eftersom en profiler förmodligen är bättre för det andra scenariot och vi kommer att prata om både felsökare och profilers. Dessutom finns det här konceptet med felsökning; detta är viktigt eftersom många gånger om du sitter på din dator och använder en felsökare som träffar en databas där koden faktiskt körs i databasen gör du det som kallas fjärrfelsökning. Du kanske inte inser det, men det är vad som händer. Och sedan är det mycket vanligt med dessa debuggers att ha brytpunkter, titta på poäng, kliva in och gå över och några andra vanliga saker, att jag kommer att visa dem på en skärmbild på ett ögonblick.
Nu, profilering: du kan göra profilering på ett par olika sätt. Vissa människor kommer att säga att arbetsbelastning fångar och spelar upp igen där det fångar allt, det som räknas som profilering. Min erfarenhet har varit mer, det är bättre om det är gjort provtagning. Det finns ingen anledning att fånga varje enskilt uttalande, för vissa uttalanden kan bara köra så snabbt att du inte bryr dig, vad du verkligen försöker se är, ja, det är de som fortsätter att dyka upp om och om igen, för de springer för länge. Så, ibland kan profilering innebära sampling snarare än att köra hela saken. Och vanligtvis kommer du att få någon form av output som du kan använda, nu som kan vara visuellt inuti en IDE-utvecklingsmiljö, där det kan ge dig som ett histogram av prestandan för de olika kodraderna, men det kan också fortfarande vara att den producerar en spårfil.
Profilers dök upp först 1979. Så de har funnits länge också. Perfekt för att hitta resursförbrukning eller prestandaproblem, med andra ord den effektivitetssaken. Generellt sett är det separat och distinkt från felsökaren, även om jag har arbetat med felsökare som gör båda samtidigt. Och medan profilers jag tror är de mer intressanta av de två verktygen, om jag känner att inte tillräckligt många debuggar, så definitivt inte tillräckligt många människor profil, eftersom en av tio debuggers kommer att profilera, verkar det. Och det är synd, eftersom profilering verkligen kan göra en stor skillnad. Nu har databasspråk, som vi har talat om tidigare, SQL - och vi har tvingat den runda pinnen i det fyrkantiga hålet här och tvingat den att bli ett programmeringsspråk - och Oracle. Det är PL / SQL - det är procedurspråket SQL - och SQL Server, det är Transact-SQL, det är SQL-99, det är SQL / PSM - för, tror jag, det är Procedure Stored Module. Postgres ger det ett annat namn, DB2 ännu ett namn, Informix, men poängen är att alla har tvingat 3GL-konstruktioner; med andra ord, FOR slingor, vid variabla deklarationer och alla andra saker som är främmande för SQL är nu en del av SQL på dessa språk. Och så måste du kunna felsöka en PL / SQL eller en Transact-SQL precis som du skulle göra ett Visual Basic-program.
Nu, databasobjekt, är detta viktigt eftersom människor kommer att säga: "Tja, vilka saker måste jag felsöka i en databas?" Och svaret är, ja, vad du än kan lagra i databasen som kod - om jag gör T-SQL, eller PL / SQL - och jag lagrar objekt i databasen, det är förmodligen en lagrad procedur eller lagrad funktion. Men det finns också triggers: en trigger är på samma sätt som en lagrad procedur, men den avfyrar på någon form av händelse. Nu kommer vissa personer i deras triggers att sätta en kodrad och ringa en lagrad procedur så att de behåller alla sina lagrade kod och procedurer, men det är samma koncept: det är fortfarande utlösaren kan vara det som initierar hela saken. Och sedan som Oracle, har de något som kallas ett paket, som liknar ett bibliotek om du vill. Du lägger 50 eller 100 lagrade procedurer i en gruppering, så kallad ett paket, så det är på samma sätt som ett bibliotek. Så här är felsökaren på gammalt sätt; detta är faktiskt ett verktyg som faktiskt kommer att gå in och fästa alla dessa felsökningar i din kod åt dig. Så överallt där du ser felsökningsblock, ta inte bort, auto-felsökning startar och spårar, de var alla fastnat i något verktyg. Och raderna utanför det, som är minoritet i koden, det är den icke-manuella felsökningsmetoden.
Och anledningen till att jag tar upp detta är, om du försöker göra det för hand, kommer du faktiskt att skriva mer felsökningskod för att lägga in alla dessa utskriftsuttalanden än du är med koden. Så även om detta kan fungera, och även om det är bättre än ingenting, är detta ett mycket svårt sätt att felsöka, särskilt eftersom, om det tar 10 timmar för den här saken att köra, och där det har ett problem är i rad tre? Om jag gjorde en interaktiv felsökningssession, skulle jag ha känt till rad tre - fem minuter in i det - hej, det finns ett problem här, jag kan sluta. Men med det här måste jag vänta på att den körs, hela vägen till färdigställande och sedan måste jag titta på en spårfil som antagligen har alla dessa tryckta uttalanden i sig, och försöka hitta nålen i höstack. Återigen är detta bättre än ingenting, men det skulle inte vara det bästa sättet att arbeta på. Det här är hur den filen skulle se ut som kom från föregående bild. med andra ord, jag körde programmet, och det har bara en massa tryckta uttalanden i den här spårfilen och jag kanske kanske inte kan sippra igenom detta och hitta vad det är jag behöver hitta. Så igen, jag är inte så säker på att det är så du vill arbeta.
Nu, interaktiva felsökare - och om du har använt något som Visual Studio för att skriva program, eller Eclipse, har du haft felsökare och du använt dem med dina andra språk - tänkte bara inte att använda dem här med din databas. Och det finns verktyg där ute, som vår DB Artisan och vår Rapid SQL, detta är Rapid SQL här, som har en felsökare, och du kan se på vänster sida, jag har en lagrad procedur som kallas "kontrollera duplikat." I princip kommer det bara att gå och titta och se om jag har flera rader i tabellen med samma filmtitel. Så, databasen är för filmer. Och du kunde se till höger, på den översta tredjedelen, jag har min källkod i mitten, jag har vad som kallas mina klockvariabler och mina samtalstackfack, och sedan längst ner jag " Vi har fått några outputmeddelanden. Och det som är viktigt här är, om du tittar över den första röda pilen, om jag musar över en variabel, kan jag faktiskt se vilket värde som finns i den variabeln i det ögonblicket i tiden, när jag går igenom koden. Och det är verkligen användbart, och sedan kan jag gå en rad åt gången genom koden, jag behöver inte säga köra, jag kan säga steg en rad, låt mig titta vad som hände, steg en annan rad, låt mig se vad som hände, och jag gör detta i databasen. Och även om jag sitter på Rapid SQL på min PC och min databas är uppe i molnet, kan jag fortfarande göra den fjärrfelsökningen och se den och kontrollera den härifrån och göra felsökning precis som jag skulle göra med något annat språk.
Nu, nästa pil där - du kan se den lilla pilen som pekar åt höger, mot DBMS-utgången, det är där min markör är för tillfället - så med andra ord, jag har gått och det är där jag är på ögonblicket. Så om jag säger: "Steg igen", kommer jag att gå till nästa rad. Nu precis nedanför ser du den röda pricken. Tja, det är en brytpunkt, som säger "Hej, jag vill inte gå över dessa linjer." Om jag bara vill hoppa över allt och komma dit där den röda punkten, kan jag trycka på körknappen och den kommer att köras härifrån antingen till slutet eller till en brytpunkt, om det finns några brytpunkter, och då kommer det att stoppa och låta mig göra steget igen. Och anledningen till att detta är viktigt och kraftfullt är att när jag gör allt detta kommer det som händer i mitten och till och med i botten - men viktigast av allt i mitten - att förändras och jag kan se värdena från mina variabler, Jag kan se mitt samtalstackspår, du vet, och all den informationen visas där när jag går igenom koden, så jag faktiskt kan se och känna och få en förståelse för vad som händer och hur koden faktiskt är arbetar vid utförandet. Och vanligtvis kan jag hitta ett problem, om det finns ett, eller om jag är tillräckligt bra för att fånga det.
OK, nu ska jag prata om en profiler, och i det här fallet är det en profil som jag kan se genom en felsökare. Kommer du ihåg att jag ibland sa att de är separata och ibland kan de vara tillsammans? I det här fallet, och återigen, är jag i Rapid SQL, och jag kan se att det finns en marginal på vänster sida bredvid radnumren. Och vad det är, är det antalet sekunder eller mikrosekunder som det tog att utföra varje kodrad, och jag kan se det tydligt att all min tid tillbringas i denna FOR-slinga där jag väljer allt från ett bord . Och så, allt som händer inne i den FOR-slingan är förmodligen något jag behöver titta på, och om jag kan göra det bättre kommer det att betala utdelning. Jag kommer inte att få några förbättringar genom att arbeta med de linjer som har 0, 90 eller 0, 86; det finns inte mycket tid där. Nu, i det här fallet, och igen, jag är i snabb SQL, ser du hur jag kan göra profilering blandad med min felsökning. Vad som är fint är Rapid SQL kan du också göra det på andra sätt. Snabb SQL låter dig säga, "Vet du vad? Jag vill inte vara med i felsökaren, jag vill bara köra detta och sedan vill jag titta på samma typ av information grafiskt eller visuellt. ”
Och du kan se att jag inte längre är med i felsökaren och det kör programmet och efter att exekveringen är klar, ger det mig diagram att berätta saker så jag kan se att jag har ett uttalande som ser ut som att det tar upp det mesta av cirkeldiagrammet och om jag tittar ser jag på det rutnätet mot botten, rad 23, det finns FOR-slingan igen: han tar upp mest tid, han är i själva verket att mörkröd tuggar upp hela cirkeldiagrammet. Och så är detta ett annat sätt att göra profilering. Vi kallar det "kodanalytiker" i vårt verktyg. Men det är i princip bara en profiler som är separerad från en felsökare. Vissa människor gillar att göra det första sättet, andra tycker om att göra det på andra sättet.
Varför gör vi felsökning och profilering? Det är inte för att vi vill skriva världens största kod och få en löneförhöjning - det kan vara vår anledning, men det är egentligen inte anledningen till att du gör det - du lovade företaget att du skulle göra något korrekt, att ditt program kommer att vara effektivt. Det är vad du använder felsökningen för. Dessutom, företagets slutanvändare; de är inte så tålmodiga: de vill ha resultat redan innan de trycker på knappen. Vi ska läsa deras sinne och göra allt direkt. Med andra ord, det måste vara effektivt. Och så, det är vad vi skulle använda profilen för. Utan dessa verktyg tror jag verkligen att du är den här killen i kostym med pil och båge och du skjuter mot målet och du är ögonbindel. För hur ska du hitta hur ett program körs genom att bara titta på statisk kod och hur ska du ta reda på vilken rad som är där det verkligen skulle spendera mest tid i körning, igen, bara genom att titta på statisk kod? En kodgranskning kanske eller kanske inte dyker upp några av dessa saker, men det finns ingen garanti för att en kodgranskning skulle hitta dem alla. Med hjälp av en felsökare och profiler bör du kunna hitta alla dessa buggar.
OK, jag ska bara göra en riktig snabb demo här. Det är inte min avsikt att driva produkt, jag vill bara visa dig hur en felsökare ser ut eftersom många gånger folk kommer att säga, "Jag har aldrig sett en av dessa tidigare." Och det ser snyggt ut på skärmens snapsida., men hur ser det ut när det är i rörelse? Så här på min skärm kör jag vår DB Artisan-produkt; vi har en debugger där också. DB Artisan är avsett mer för DBA, Rapid SQL är mer för utvecklarna, men jag har sett utvecklare som använder DB Artisan, och jag har sett DBA som använder Rapid. Så bli inte med på produkten. Och här har jag valet att göra en felsökning, men innan jag startar felsökningen kommer jag att extrahera den här koden så att du kan se hur koden ser ut innan jag börjar köra den. Så här är exakt samma kod som fanns i skärmbilden, det här är min kontroll för duplikat. Och jag vill felsöka detta, så jag trycker på felsökning. Och nu tar det ett ögonblick och du säger: "Tja, varför tar det ett ögonblick?" Kom ihåg fjärrfelsökning: felsökningen sker faktiskt på min databaseserver, inte på min PC. Så det var tvungen att gå över och skapa en session där borta, skapa en fjärrfelsökningssaken, ansluta min session till den fjärrfelsökningssessionen och ställa in en kommunikationskanal.
Så nu, här är min pil, det är där uppe, efter rad en, det är där jag befinner mig i koden. Och om jag trycker på den tredje ikonen där, som är ett steg in, kommer du att se den pilen som just har flyttats, och om jag fortsätter att trycka på den, kommer du att se den fortsätta flytta. Om jag ville gå ner till denna FOR-slinga, eftersom jag vet att det är där problemet är, kan jag ställa in en brytpunkt. Jag trodde att jag ställde in det. Åh skjut, jag hade en av mina skärmtagningsnycklar mappade till samma nyckel som felsökaren, det är vad som orsakar förvirring. OK, så jag ställer bara en brytpunkt manuellt där, så nu istället för att göra ett steg, steg, steg, steg tills jag kommer dit, kan jag faktiskt bara säga: "Gå vidare och kör den här saken, " och det kommer att stoppa. Lägg märke till att det rörde mig hela vägen ner till där brytpunkten är, så jag är nu i samband med att köra denna slinga, jag kan se vad alla mina variabler är inställda på, vilket inte är en överraskning, för jag initierade dem alla till noll. Och nu kan jag gå in i den här slingan och börja titta på vad som händer inne i den här slingan.
Så nu kommer det att göra ett urval av mina hyror och jag kan musa över den killen och titta, han är två, två är större än en, så det kommer förmodligen att göra nästa bit av den här koden. Med andra ord, den hittade något. Jag ska bara gå vidare och låta det springa. Jag vill inte gå igenom allt här; Det jag vill visa er när en felsökare är klar, den avslutas precis som ett normalt program. Jag har ställt in brytpunkten, så när jag sa kör, gick det bara tillbaka till nästa brytpunkt. Jag låter det köras till slutet, för det jag vill att du ska se är att en felsökare inte förändrar programmets beteende: När det är klart ska jag få exakt samma resultat om jag hade kört det inte inuti en felsökare.
Och med det kommer jag att stänga av demot och gå tillbaka eftersom vi vill se till att vi har tid till frågor och svar. Och så kommer jag att öppna det för frågor och svar.
Eric Kavanagh: Okej, Robin, kanske en fråga från dig och sedan ett par från Dez?
Robin Bloor: Ja, visst, jag tycker det här fascinerande, naturligtvis. Jag har arbetat med saker som det här, men jag har aldrig arbetat med något liknande i databasen. Kan du ge mig en uppfattning om vad folk använder profilen för? Eftersom det är som, tittar de på - för jag antar att de är - de tittar på prestandafrågor, kommer det att hjälpa dig att skilja mellan när en databas tar tid och när en kod tar tid?
Bert Scalzo: Du vet, det är en fantastisk fråga. Låt oss säga att jag arbetar i Visual Basic, och jag, inom mitt Visual Basic, kommer jag att ringa en Transact-SQL eller en PL / SQL. Låt mig göra PL / SQL, eftersom Oracle inte alltid spelar bra med Microsoft-verktygen. Jag kanske profilerar min Visual Basic-kod, och profilen där kan säga: "Hej, jag kallade den lagrade proceduren och det tog för lång tid." Men då kan jag gå in i den lagrade proceduren och jag kan göra en databasprofil på den lagrade procedur och säga, "OK, av de 100 uttalanden som finns här, här är de fem som orsakade problemet." Och så kanske du måste göra ett tagg-team, där du måste använda flera profiler.
Tanken är om du någonsin får höra att prestandaproblemet finns i din databas, en databasprofil kan hjälpa dig att hitta nålen i höstacken på vilka uttalanden faktiskt är de där du har problem. Jag säger er en annan sak som visade sig att profilering: om du har en kodkod som kallas en miljon gånger, men det tar bara ett mikrosekund var och en av miljon gånger, men det kallas en miljon gånger, vad profilen skulle visa, den saken gick under så många tidsenheter. Och så att koden kan vara mycket effektiv, kanske du kan titta och säga, "Ooh, vi ringer det här samtalet för alltför ofta. Kanske borde vi bara kalla det så ofta, snarare än varje gång vi bearbetar en post, eller något. Och så kan du faktiskt hitta var det finns effektiv kod som bara kallas för ofta, och det är faktiskt ett prestandaproblem.
Robin Bloor: Ja, det är underbart. Jag har aldrig gjort det här. Du förstår naturligtvis att när jag hade databasproblem så var det som om jag på ett eller annat sätt skulle ha att göra med databas eller att hantera kod; Jag kunde aldrig ta itu med båda på samma gång. Men där igen gjorde jag inte ett - jag har aldrig varit med och byggit applikationer där vi hade lagrat förfaranden, så jag antar att jag faktiskt aldrig har stött på problem som brukade driva mig vild, idén att du delade upp koden mellan en databas och ett program. Men så, gör allt - jag antar att svaret kommer att bli ja, men detta är en del av en utvecklingsteamaktivitet, när du på ett eller annat sätt försöker fixa något som är trasigt, eller kanske försöker få en ny ansökan tillsammans. Men skräddarsyr allt detta med alla de andra komponenter som jag förväntar mig i miljön? Kan jag förvänta mig att jag kunde klippa detta tillsammans med alla mina testpaket och alla andra saker som jag skulle göra och med mina projektledningssaker, är det så allt detta klipp ihop?
Bert Scalzo: Ja, det kan bli en del av alla strukturerade processer för att göra dina programmerings- eller utvecklingsinsatser. Och det är roligt, förra veckan hade jag en kund som byggde en webbapplikation, och deras databas hade historiskt varit liten och så att det faktum att de inte var så bra programmerare skadade dem aldrig. Tja, deras databas har vuxit med åren, och nu tar det 20 sekunder på en webbsida, mellan när du säger: "Logga in mig och ge mig lite data att se" och när skärmen verkligen dyker upp, och så nu är det ett prestandaproblem. Och de visste att problemet inte var på någon av deras Java eller någon av de andra platserna. Men de hade tusentals lagrade förfaranden och så de var tvungna att börja profilera de lagrade procedurerna för att ta reda på varför tar det denna webbsida 20 sekunder att komma upp? Och vi fann faktiskt att de hade en kartesisk medlem i ett av sina utvalda uttalanden och inte visste det.
Robin Bloor: Wow.
Bert Scalzo: Men någon sa till mig en gång, "Tja hur kunde de få en kartesisk medlem att gå med och inte veta det?" Och det låter riktigt hemskt; ibland kommer en programmerare som inte är särskilt bekväm med SQL att göra något som att ge mig en kartesisk medlem, men sedan bara ge mig tillbaka den första posten, så jag vet att jag fick något, och jag behöver bara den första. Och så, de inser inte att de bara tog tillbaka en miljard poster eller de tittar igenom en miljard poster, för de fick den de var intresserade av.
Robin Bloor: Wow, jag vet, det är det som heter - ja, det är vad Dez pågick kring, när det gäller människor som inte är så duktiga som de kanske borde vara, du vet. Om du är programmerare bör du veta vad konsekvenserna av att utfärda ett kommando är. Jag menar, det finns ingen ursäkt för den nivån av dumhet. Jag antar också att du på ett eller annat sätt bara är språkagnostiker när det gäller detta, för det här fokuserar allt på databasesidan. Har jag rätt i det? Är det precis samma sak, vad du använder på kodningssidan?
Bert Scalzo: Absolut, du kan göra detta i Fortran eller C eller C ++. På vissa Unix kan du till och med göra det för deras skriptspråk; de ger faktiskt samma verktyg. Och sedan vill jag gå tillbaka en sekund för det du sa utan ursäkt. Jag kommer att ge programmerarna en paus, för jag gillar inte att kasta programmerare under bussen. Men problemet är verkligen den akademiska miljön eftersom när du går för att lära dig att vara programmerare, lärs du upp inspelning i taget. Du lär dig inte upp tänkande i set, och det är vad Structured Query Language, eller SQL fungerar med uppsättningar; det är därför vi har facket, korsningen och minusoperatören. Och ibland är det mycket svårt för en person som aldrig har tänkt i termer av uppsättningar, att sluta, släppa rekord i taget och bearbeta med uppsättningar.
Robin Bloor: Ja, jag är med dig på det. Jag menar, jag får nu, det är en utbildningsfråga; Jag tror att det är helt en utbildningsfråga, jag tror att det är naturligt för programmerare att tänka procedurellt. Och SQL är inte processuellt, det är deklarativt. Du säger faktiskt bara: "Det här är vad jag vill och jag bryr mig inte om hur du gör det, " vet du? Medan du har programmeringsspråk har du ofta fått ermarna rullas upp och du är nere i minutierna att till och med hantera räkningarna, medan du gör en slinga. Jag ska överlämna till-
Bert Scalzo: Nej. OK, fortsätt.
Ja, jag tänkte säga att du tog upp ett annat exempel på att en profiler skulle vara bra att fånga den typ av fortsätter med den här rekord-i-tid-bearbetningen. Ibland kan en programmerare som är bra på en rekord-i-tid-logik inte ta reda på hur man gör SQL-program. Låt oss säga att han gör två FOR-slingor och i princip gör en sammankoppling, men han gör det på klientsidan. Så han gör samma effekt som en koppling, men han gör det själv, och en profil skulle fånga det, eftersom du förmodligen skulle sluta spendera mer tid på att göra anslutningen manuellt än att låta databasservern göra det åt dig.
Robin Bloor: Ja, det skulle vara en katastrof. Jag menar, du skulle bara trilla runt. Thrashing är alltid dåligt.
Hur som helst, jag ska vidarebefordra till Dez; Jag är säker på att han har några intressanta frågor.
Dez Blanchfield: Tack, ja, det gör jag. Jag ska gå med dig i att inte kasta programmerare under bussen. Jag menar, jag har tillbringat för många år i mitt liv att vara en kodare själv, på alla nivåer, du vet, om det är som du sa, sitter på kommandoraden på Unix-maskinen, och i vissa fall var jag till och med involverad i ett par olika portar på Unix från en hårdvaruplattform till en annan. Och du kan föreställa dig de utmaningar vi hade där. Men verkligheten är här att få-out-of-fängelsekortet för varje kodare och manus i världen. Det är en raketvetenskap, bokstavligen, att skriva riktigt hårt varje gång, hela tiden, är en raketvetenskap. Och berömda berättelser om människor som Dennis Ritchie och Brian Kernahan som självständigt arbetar på en kodkod och sedan vänder sig till en kodgranskningschatt över ett kaffe och fick reda på att de hade skrivit exakt samma kodkod, i exakt samma program, på exakt samma sätt. Och de gjorde det i C. Men den puristiska nivån på programmering finns mycket sällan.
Faktum är att dagligen finns det bara 24 timmar om dagen, sju dagar i veckan, och vi måste bara göra saker. Och så, när det gäller inte bara traditionella programmerare, DBA: er, och kodare, och skriptare, och sysadmin, och nätverksadministratörer och säkerhetspersonal, och allt hela vägen till medborgarens datasida i dessa dagar; vi hör, alla försöker bara göra sitt jobb. Och så jag tror att den stora takeaway från hela denna sak är att jag älskade din demo och jag älskade takeaway som du lämnade oss där, bara för ett ögonblick sedan och pratade med Robin om det faktum att det här har en speciell - kanske inte så mycket en nisch - men ett brett utrymme som det gäller för såväl som fixkod och SQL och databaser. Men jag var verkligen upphetsad över att höra dig säga att du kan göra det på ett skalskript och hitta några problem, för du vet, i dagens dag och ålder arbetar vi alltid till lägsta kostnad på allt.
Anledningen till att du kan köpa en $ 6-skjorta någonstans är att någon byggde ett system tillräckligt billigt för att faktiskt tillverka och leverera och logistiskt leverera och sälja och detaljhandel och ta online-betalningar för att få den $ 6-tröjan. Och det händer inte om du får människor som betalas 400 000 dollar per år för att skriva kod på det perfekta sättet; det är bara hela utvecklingen. Så den punkten antar jag att en av de frågor jag verkligen älskar dig bara för att ge oss lite mer inblick, är vad bredden och räckvidden för den typ av människor du ser för närvarande som använder sådana verktyg för att profilera en kod och leta efter prestationsproblem? Ursprungligen historiskt, var kommer de ifrån? Har de varit de stora verkstaden? Och framöver, är det så, har jag rätt i att tänka att fler och fler företag implementerar detta verktyg, eller dessa verktyg, för att försöka hjälpa kodare, som de vet som bara gör saker och ting för att få jobbet gjort och få den ut genom dörren? Och ibland behöver vi ett get-out-of-fängelsekort? Har jag rätt i att tro att vi historiskt sett hade ett mer tekniskt fokus och utveckling? Att vi nu får en mindre, som Robin sa, akademisk inställning, och nu är det självlärda, eller klipp ut och klistra in kod, eller bara bygga saker? Och stämmer det med den typ av människor som tar produkten på nu?
Bert Scalzo: Ja, exakt. Och jag ger dig ett mycket specifikt exempel, vi vill bara göra jobbet, för affärsfolk vill inte perfektion. Det är på samma sätt som ett datoriserat schackspel: schackspelet letar inte efter det perfekta svaret; det letar efter ett svar som är tillräckligt bra på rimlig tid, så det är så vi programmerar. Men vad jag hittar nu är att de flesta människor istället för att säga att de vill ha en profiler som en del av deras enhetstestning - vilket är hur jag skulle göra det, för jag ser inte det som ett slöseri med tid - vad som händer är nu när det görs senare, ibland under integreringstest eller stresstestning, om vi har tur. Men de flesta gånger är det en del av en upptrappning, där något har gått i produktion, det sprang ett tag, kanske till och med sprang i flera år, och nu går det inte bra, och nu kommer vi att profilera det. Och det verkar vara det vanligaste scenariot nu.
Dez Blanchfield: Ja, och jag tror att termen "teknisk skuld" förmodligen är en du är mer än bekant med; Jag vet Robin och det är jag verkligen. Jag tror att idag, särskilt i smidiga tillvägagångssätt för utveckling och systembyggnad, för mig är begreppet teknisk skuld nu en väldigt riktig sak, och vi redogör faktiskt för det i projekt. Jag vet, jag menar, vi har våra egna projekt som Media Lens och andra, där vi har kodning som sker dagligen, och olika saker i hela Bloor Group. Och när vi bygger något så tittar vi på det, jag tittar på det och tittar alltid på vad det kommer att kosta mig att fixa just nu, kan jag bara få det i kan och ta det ut där, och sedan se och se om den här saken kommer att gå sönder. Och ärva den tekniska skulden som jag vet att jag måste komma tillbaka senare och fixa.
Och jag menar, jag har gjort det de senaste sju dagarna: Jag har skrivit ett par verktyg och skript, jag har skrivit ett par bitar av Python-språket, och jag har distribuerat det till Mongo back end säker på att det är trevligt och rent och säkert, men det blir bara den fråga jag behöver göra, att veta att jag behöver den funktionen för att fungera, för att komma till det större pusslet; det är där min verkliga smärta är. Och så du bär på denna tekniska skuld, och jag tror att det här inte bara är en tillfällig sak, jag tror att detta är en del av DNA: s utveckling. Människor accepterar bara - inte obetydligt - att den tekniska skulden är en normal typ av operativ typ av problem, och de måste bara ådra sig det. Det är där du har teknisk skuld. Och jag tror att det fantastiska med det du visade oss i demonstrationen var att du bokstavligen kan profilera och titta på hur lång tid något tar att köra. Och det är förmodligen en av mina favorit saker. Jag menar, jag har faktiskt byggt profileringsverktyg - vi byggde verktyg i Sed och Lex och Orc för att köra vår kod och se var slingorna var innan verktyg som detta fanns tillgängliga - och när du har byggt kod för att gå och granska din egen kod, du blir väldigt bra på att du inte behöver granska din egen kod. Men det är inte fallet nu. Med det i åtanke, finns det ett särskilt marknadssegment som tar upp detta mer än något annat? Ser som en massa-
Bert Scalzo: Åh ja, jag har det - jag kommer att rita en analogi åt dig och visa dig att icke-programmerare gör det hela tiden. För om jag någonsin undervisar en debugger och profilerar klass eller session kommer jag att fråga människor, "OK, hur många människor här inne går i Microsoft Word och medvetet använder aldrig stavkontrollen?" Och ingen räcker upp, för för att skriva dokument vet vi alla att vi kan göra engelska misstag, och så använder alla stavkontrollen. Och jag sa: "Tja, hur är det när du skriver text i din IDE som Visual Basic, du inte använder felsökaren? Det är samma sak, det är som en stavningskontroll. "
Dez Blanchfield: Ja, faktiskt, det är en fantastisk analogi. Jag hade inte riktigt tänkt på, jag måste erkänna att jag faktiskt gör något liknande med ett par verktyg jag använder. I själva verket är en, ODF, min favorit med Eclipse bara klippa och klistra in kod där inne och leta efter saker som bara markerar omedelbart och insåg att jag gjorde en skrivfel i ett klasssamtal. Och men det är intressant nu med det här verktyget kan du göra det i realtid i motsats till att komma tillbaka och titta på det senare, vilket är ganska trevligt att fånga det i förväg. Men ja, det är en fantastisk analogi att bara lägga in text i en ordbehandlare, för det är ett intressant väckning som bara förstår att du har gjort några typfel eller till och med ett grammatikfel, eller hur?
Bert Scalzo: Exakt.
Dez Blanchfield: Så, ser du mer av en uptick nu, antar jag, den sista frågan från mig, innan jag kasta till vår fråga och svar kanske, för våra deltagare. Om du skulle ge någon form av rekommendation kring tillvägagångssättet att göra detta - jag antar att detta är retoriskt - är det så att du kommer in tidigt och får detta implementerat när du utvecklar dig innan du utvecklar? Eller är det så att du huvudsakligen får bygga, flytta, bygga något och komma in och profilera det senare? Jag misstänker att det är fallet att komma in tidigt och se till att din kod är ren i förväg. Eller är det så att de borde överväga den här delen av sin post-distribution?
Bert Scalzo: Helst skulle de göra det i förväg, men eftersom alla är i den livliga och livliga världen där de bara fick göra saker, tenderar de att inte göra det förrän de stöter på ett prestandaproblem som de inte kan lösa av lägga till fler CPU och minne till en virtuell maskin.
Dez Blanchfield: Ja. Så nämnde du faktiskt något intressant om jag snabbt kan? Du nämnde tidigare att detta kan köras var som helst och kan prata med databasen i slutändan. Så detta är bekvämt med den typ av bimodala koncept som vi pratar om nu, av molnet på plats / utanför premisset, av saker och ting, i slutet av dagen, om det kan prata med baksidan och se koden, det bryr sig inte riktigt, eller hur?
Bert Scalzo: Exakt, ja, du kan köra detta i molnet.
Dez Blanchfield: Utmärkt, för jag tror att det är den typ där vår nya modiga värld håller på att gå. Så Eric. Jag kommer att kasta tillbaka till dig nu och se att vi har några frågor här och jag vill att våra deltagare fortfarande ska vara hos oss, även om vi har gått förbi timmen.
Eric Kavanagh: Ja, det finns några folk där ute, jag kommer bara att kommentera: Bert, jag tror att metaforen, den analogi du ger med stavningskontroll är uppriktigt lysande. Det är värt en blogg eller två, helt uppriktigt, eftersom det är ett bra sätt att inrama sammanhanget för vad det är som du gör, och hur värdefullt det är, och hur det egentligen borde vara en bra praxis att använda en felsökare regelbundet, eller hur? Jag slår vad om att du får några huvuden som nickar när du slänger ut den, eller hur?
Bert Scalzo: Absolut, för det jag säger till dem är: "Varför kör jag en stavningskontroll på mina dokument? Jag vill inte bli generad av dumma stavfel. ”Tja, de vill inte bli generade av dumma kodfel!
Eric Kavanagh: Rätt. Ja verkligen. Tja, folkens, vi har bränt igenom en timme och fem minuter här, så stort tack till er alla ute för er tid och uppmärksamhet. Vi arkiverar alla dessa webbchattar, kommer gärna tillbaka när som helst och kolla in dem. Det bästa stället att hitta dessa länkar är förmodligen techopedia.com, så vi lägger till detta till den här listan här.
Och med det kommer vi att hälsa dig, folkens. Återigen, bra jobb, Bert, tack till våra vänner från IDERA. Vi pratar med dig nästa gång, vi pratar faktiskt med dig nästa vecka. Ta hand om dig! Hejdå.
