Hämtmat: Värd Eric Kavanagh diskuterade felsökning och profilering av databaser med Dr. Robin Bloor, Dez Blanchfield och IDERA: s 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 östra 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 på rätt sätt. För talade 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å skulle vi prata om "Rapid Response: Database Debugging and Profiling to the Rescue."
Det är en plats om din, verkligen, slå mig upp, @eric_kavanagh naturligtvis.
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 får 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 sakerna 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?
Hör väl 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 ska faktiskt 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 borde få en helt rund bild av vad som händer. Jag gjorde det här länge, och jag brukade vara en kodare, så det är så, 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 överlåta det till någon annan.
Här är en lista över kända buggar, och de flesta av dessa kommer in på anybodys 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 kodningsexperiment, som plötsligt blev en våldsam mask som gick runt alla saker - det orsakade uppenbarligen skador på 100 miljoner dollar; det är en uppskattning förstås. 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-programmet ä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 var bara intressant med tanke på kostnaden för något liknande - AT&T var ute i cirka 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, det är det. Jag trodde att jag pratade om impedansmatchning och SQL utfärdade. Det är intressant att relationsdatabaser lagrar data i tabeller och kodare tenderar att manipulera data i objektstrukturer som verkligen inte kartlägger mycket bra till tabeller. Och därför får du vad 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, kodningsmodellen och databasen en annan modell, inte är 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å kodersidan, 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 kastar ut saker 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å, databas killarna byggde lagrade procedurer för att leva i databasen och anledningen till de lagrade procedurerna som bodde där var att du verkligen 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 kaskaderande borttagningar och liknande saker, databasen tog hand om all den plötsliga du placerar funktionalitet i en databas, vilket naturligtvis innebar att funktionaliteten för en applikationen 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 den ena sidan av databasspelet, för det betyder att du har fått en hel del implementationer till exempel, att jag har varit inblandad i relationella databaser. Det är verkligen en hemsk massa kod som sitter i lagrade procedurer som hanteras separat från kod som sitter i applikationerna. Och det verkar som en väldigt konstig sak att ha fått, det är tänkt att vara ganska smart att göra olika saker.
Jag trodde att Id också pratade 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. Den ska utformas 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 full, saknar de ner. 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 felsökning av databaser bara kan vara så besvärande och icke-triviala - och jag säger det eftersom jag har gjort mycket av det - och du kommer ofta att upptäcka det 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 är allt du tittar på korrupta data och tänker: "Hur i helvete hände det?"
Hur som helst, jag ska vidarebefordra till Dez, som förmodligen 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 dämpades.
Eric Kavanagh: Okej, häng på 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, en livslång 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 är det mer ett fall av profileringskod 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 en förment programvaruproblem kom med.
Så den urbana myten är den runt den 9 septemberth, 1945, tog ett team vid Harvard University en maskin, de stötte på något som de kallade "relä sjuttio" - i dessa dagar programmering gjordes i fysisk mening, du lindade kod runt ett bräde, och det var så du programmerade effektivt maskin - och de hittade detta relä nummer sjuttio att det var något fel med det, och det visar sig att själva termen "bug" kom till eftersom det ganska bokstavligen var en mal - förmodligen fanns det en mull fastkopplad mellan en bit koppartråd som går 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 sammanställer, men som ett program som inte fungerar bra. Och specifikt har inte profilerats bara hitta saker som oändliga slingor som bara går ingenstans.
Men vi har också ett scenario, och jag trodde att Id satte in ett par roliga bilder innan jag fick lite mer detaljer. Här är den klassiska tecknade filmen, kallad XKCD på webben, och tecknad filmisten har några ganska roliga vyer över världen. Och det här om ett barn som heter "Little Bobby Tables" och förmodligen hans föräldrar heter den här unga pojken Robert); DROPTA TABELL Studenter; - och det heter, och sorts "Hej, det här är dina sönskolor som har några 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,” har du verkligen namngivit din son Robert); DROPTA 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 studentstudentjournalen, jag hoppas att ni är lyckliga. Och svaret är, "Tja, du bör rengöra och sanera dina databasingångar." Och jag använder det många gånger för att prata om några av de problem vi har när vi hittar 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 ett falskt problem - men igen, det berör också mitt roliga ben. Någon byter licensskylt 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 alla programmerare som förutsåg en hit och körning av deras kod av ett verkligt motorfordon, men aldrig underskattar den - 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 är väldigt mycket av den uppfattningen att den tiden har gått, och anekdotiskt i min erfarenhet, min första - och detta kommer att åldras mig fruktansvärt, 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 vandrat i slutet av staden och knackat på dörren till ett datacenter som heter "Data Com" i Nya Zeeland och frågar om Jag kunde tjäna fickpengar på skolan genom att hämta den sena bussen hem, cirka 25 km pendel varje dag, genom att lägga papper i ers, och band i banddiskar 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 fysisk 132-kolumn. I grund och botten, tänk på som en mycket gammal skrivmaskin med papper som rullade igenom den, för att de inte hade ett CRT-rör. Och felsökningskod på det var en mycket icke-trivial fråga, så du tenderade att skriva all din kod 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 raden och sedan skriva in den igen. Men en gång i tiden var det så vi skrev kod och det var så vi debugged, 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 var 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 som du gjorde på papperstejpen typ av ed-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 är, 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 introducerade buggy koda.
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 utformades 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, orsak när vi tänker på från två synvinklar: ur kodningssynpunkt och från DBA-synvinkel. Det är väldigt lätt att följa 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 letar efter något och hittar 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 fått andra utmaningar, till exempel, i dessa dagar rusade alla mot detta, vad 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 anställda lågbetalda personal. Och jag menar inte det på ett otänkbart sätt, men anlitade 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.
Dessa dagar, det finns en hel del människor att komma in i utveckling och design och databas som inte har haft många års erfarenhet, hade inte nödvändigtvis samma utbildning eller stöd. 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 tror 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 mycket, mycket lätt att lära sig, det är mycket 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 varhelst.
Nu, det är 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 mycket. Jag är ett stort fan av matematik, jag älskar kaosteori, jag älskar Mandelbrot-uppsättningarna. På höger sida finns en återgivning av Mandelbrot-uppsättningen, som jag säkert var bekant 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 beskrev där, och det är ja, du kan faktiskt programmera nästan vad som helst i SQL; det är ett mycket starkt 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 förfaranden, 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ågbetalda personal som försöker vara högt betalda personal, människor som låtsas att de vet, 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, är den typen av söt och du tänker, "Wow, vad en bra grafik, Id älskar att köra det." Men tänk dig att det kör på någon 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 är tänkt att vara en svart bakgrund och grönt för att vara 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 så har du 100 000 människor som slår 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 webbadresserna där kan du gå och titta - det kallas den den mest komplexa SQL-frågan du någonsin skrev. För tro mig, det faktiskt kompilerar, det går. 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 rad med.
Så för att sammanfatta, med det i åtanke, har hela min bakgrund i kodning lärt mig att du kan ge människor en pistol och om de inte är försiktiga kommer de att skjuta sig 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 jag sa tidigare om , en gång kunde du göra det genom att titta på en grön skärm. Du kan inte längre; det finns hundratusentals kodrader, det finns tiotusentals appar som används, det finns miljoner databaser i vissa fall, och till och med supermän kan 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 speciellt den demon som jag tror var på väg att få. Eric, jag kommer tillbaka igen.
Eric Kavanagh: OK, Bert, ta bort det.
Bert Scalzo: Okej, 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 riktigt ä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 säger de 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, medelåldern, vilken typ av säger var vi var i termer för 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 felsökare, orsakar det är en av de nya sakerna", då måste du ha börjat programmera, du vet, redan på 1950-talet, orsakar det är det enda sättet du skulle få bort med det påståendet.
Det andra som är roligt med det här diagrammet är att Dez bara gjorde en kommentar om Grace Hopper, jag kände faktiskt Grace, så det är roligt. Och sedan det andra jag skrattade åt är att han pratade om teletyper och jag satt där och gick, ”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 en 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, du har åldrat oss oerhört där.
Bert Scalzo: Ja, jag säger att jag känner mig 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 sätter påståenden i din kod och kanske du producerar 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 fått det berömda uttalandet: du tittar på och folk lägger faktiskt in uttalanden 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 trycker du på en knapp och det kommer att hålla fast uttalanden 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 debugging, det är för effektivitet och det kan vara ett logiskt misstag, men vad det är, är jag gjorde rätt sak, det kommer bara inte tillbaka tillräckligt snabbt. Nu gör jag den punkten eftersom en profilare förmodligen bättre för det andra scenariot och skulle prata om både felsökare och profilers. Dessutom finns det här konceptet med fjärrfelsökning; detta är viktigt eftersom många gånger om du sitter på din persondator och du använder en felsökare, som träffar en databas där koden faktiskt körs i databasen, gör du faktiskt vad 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, som 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 dess 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, eftersom de kör 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 skiljer sig 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, för profilering kan verkligen göra en enorm skillnad. Nu har databasspråk, som vi har pratat om tidigare, SQL - och vi har tvingat den runda pinnen i det fyrkantiga hålet här och tvingat det att bli ett programmeringsspråk - och Oracle.Det är PL / SQL - det är procedurspråket SQL - och SQL Server, dess Transact-SQL, dess SQL-99, dess SQL / PSM - för, tror jag, dess lagrade procedurmodul. 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, med 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 utlöser också: en trigger är på samma sätt som en lagrad procedur, men den avfyrar på någon slags händelse. Nu kommer vissa människor 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 trigger som 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 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 av koden, ja, det är den icke-manuella felsökningsmetoden.
Och anledningen till att jag tar upp detta är, om du försöker göra detta för hand, kommer du faktiskt att skriva mer felsökningskod för att lägga in alla dessa uttalanden ä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, vad händer om det har tagit 10 timmar för den här saken att köra, och där det har ett problem är i rad tre? Om jag genomförde en interaktiv felsökningssession, skulle jag ha känt till rad tre - fem minuter in i det - hej, det är ett problem här, jag kan sluta. Men med detta måste Ive vänta på att den ska köras, hela vägen till slutförande och sedan måste jag titta på någon spårfil som antagligen har alla dessa uttalanden i sig och försöka hitta nålen i höstacken. Å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 precis fått ett gäng uttalanden i den här spårfilen och jag kanske eller 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 debuggers - och om du har använt något som Visual Studio för att skriva program eller Eclipse, har du haft debuggers och du använde 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 grund och botten 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 på höger sida, på den översta tredjedelen, jag har fått min källkod i mitten, jag har vad som kallas mina klockvariabler och mina samtalstackfack, och sedan längst ner har jag några output s. Och vad som är viktigt här är, om du tittar över den första röda pilen, om jag musen ö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 i taget genom koden, jag behöver inte säga exekvera, 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 den 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 just nu. Så om jag säger: "Steg igen" ska jag 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 pricken, kan jag slå körknappen och det 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 allt viktigt och kraftfullt är att när jag gör allt detta, vad som händer i mitten och till och med i botten - men viktigast av allt i mitten - kommer att förändras och jag kan se värdena från mina variabler, jag kan se min call stack-spår, du vet, så all information 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 fungerar vid körning . 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. Kom ihåg att jag sa ibland att de är separata och ibland kan de vara tillsammans? I det här fallet, och igen, är jag i snabb SQL, och jag kan se en marginal på vänster sida bredvid radnumren. Och vad det är, är att det är antalet sekunder eller mikrosekunder som det tog att utföra varje kodrad, och jag kan se det tydligt, all min tid spenderas i den här FOR-slingan där jag väljer allt från en tabell. Och så är de som är intresserade av FOR-slingan 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 på 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 profilerande blandade med min felsökning. Vad är bra med 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 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 fått ett uttalande som ser ut som att det tar upp det mesta av kakan och om jag tittar, ser jag på det rutnätet mot botten, rad 23, finns FOR-slingan igen: han tar upp mest tid, han är faktiskt 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 grund och botten bara en profiler 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ökaren för. Dessutom, företagets slutanvändare; de är inte så tålmodiga: de vill ha resultat redan innan de trycker på tangenten. Skulle läsa deras sinne och göra allt direkt. Med andra ord, det måste vara effektivt. Och så, det är det vi skulle använda profilen för. Utan dessa verktyg tror jag verkligen att du är den här killen i affärsdräkten 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 förut." Och det ser snyggt ut på skärmens snapsida, men vad 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å, inte fastna 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å här är min pil, det är där uppe, efter rad en, det är där jag är 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 flyttats, och om jag fortsätter att trycka på den så ser du den fortsätter att röra sig. Om jag ville gå hela vägen ner till denna FOR-slinga, eftersom jag vet att där är problemet, kan jag ställa in en brytpunkt. Jag trodde att jag ställde in det. Åh skjut, jag fick 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 förflyttade mig hela vägen ner till där brytpunkten är, så jag är nu i svårigheten att köra den här slingan, jag kan se vad alla mina variabler är inställda på, vilket inte är en överraskning, för jag initialiserade 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 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, orsaken till att det jag vill att du ska se är att en felsökare inte ändrar beteendet hos programmet: När det är klart bör jag få exakt samma resultat om jag hade kört det inte i en debugger.
Och med det kommer jag att stänga av demot och gå tillbaka eftersom vi vill se till att vi har tid för 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 jobbat 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 liknande, tittar de på - eftersom 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, inuti min Visual Basic, kommer jag att ringa en Transact-SQL eller en PL / SQL. Låt mig göra PL / SQL, eftersom Oracle inte spelar bra alltid 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å medan koden kan vara mycket effektiv, kanske du tittar och säger: "Ooh, ringde 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 effektiva 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, återigen, gjorde jag inte ett - Jag har faktiskt aldrig varit involverad i att bygga 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 skulle dela upp koden mellan en databas och ett program. Men så, gör allt - Jag antar att svaren 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öra samman en ny applikation. 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 mycket 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 information att se" och när skärmen verkligen dyker upp, och nu är dess ett prestandaproblem. Och de visste att problemet inte var på någon av deras Java eller någon av dessa andra platser. 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å och inte veta det?" Och det här 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, eftersom de fick den de var intresserade av.
Robin Bloor: Wow, jag vet, det är vad som heter - ja, det är vad Dez pågick, när det gäller människor som inte är så duktiga som de kanske borde vara, vet du. Om du är programmerare bör du veta vad konsekvenserna av att utfärda ett kommando är. Jag menar verkligen, 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 du använder på kodningssidan?
Bert Scalzo: Absolut kan du 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ärde du rekord-i-tid-tänkande. 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 det är ibland mycket svårt för en person som aldrig tänkte i termer av uppsättningar, att sluta, släppa rekord-i-tid-behandling och arbeta med uppsättningar.
Robin Bloor: Ja, jag är med 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 programmeringsspråk har du ofta fått ärmarna rullas upp och du kommer ner i detaljerna om du även hanterar räkningarna, medan du gör en slinga. Ill hand 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. Tja, låt oss säga att han gör två FOR-slingor och i princip gör en sammanfogning, 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. Trasningar är alltid dåliga.
Hur som helst, jag ska vidarebefordra till Dez; Jag är säker på att han fick 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 som en kodare själv, på alla nivåer, du vet, huruvida det är som du sa, sitter på kommandoraden på Unix-maskinen, och i vissa fall var jag till och med involverad i en 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 som får-out-of-fängelset kort för alla 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 med någon kodkod och sedan vänder sig till en kodgranskningschatt över ett kaffe och ta reda på att de skrev exakt samma kodkod, i exakt samma program, i exakt på 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 på en dag, 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 kunde sticka det på ett skalskript och hitta några problem, för du vet, i dagens dag och ålder arbetade 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 har fått folk som betalas $ 400 000 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 frågorna som Id verkligen älskar dig att bara 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 titta för prestationsfrågor? 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 det nu fick en mindre, som Robin sa, akademisk inställning, och nu dess självlärda, eller klipp-och-klistra kod, eller bara få saker att bygga? Och stämmer det med den typ av människor som tar produkten på nu?
Bert Scalzo: Ja, precis. Och jag ger dig ett mycket specifikt exempel, vi vill bara få jobbet gjort, för affärsfolk vill inte ha perfektion. Det är 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, 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 att jag inte ser det som ett slöseri med tid - vad som händer är nu att det görs senare, ibland, under integrationstest eller stresstestning, om de hade tur. Men de flesta gånger dess del av en upptrappning, där något gick i produktion, den sprang ett tag, kanske till och med sprang i flera år, och nu fungerar det inte bra, och nu profilerar det väl. 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 fått våra egna projekt som Media Lens och andra, där vi har fått kodning som sker dagligen, och olika saker över hela Bloor Group. Och när vi byggde något så tittar vi på det, jag tittar på det och tittar alltid på vad som kommer att kosta mig att fixa det här just mot, kan jag bara få det i burk och ta det där ute, och se sedan om dessa saker kommer att gå sönder. Och ärva den tekniska skulden som jag vet att jag måste gå tillbaka senare och fixa.
Och jag menar, jag har gjort det under 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å att det är trevligt och rent och säkert, men det blir bara frågan 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 brukade bygga 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å igenom din egen kod , blir du 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: Oh yeah, Ive got - Jag kommer att rita en analogi åt dig och visa dig att icke-programmerare gör det hela tiden. Orsak om jag någonsin undervisar en debugger och profilering klass eller session, jag frågar människor, "OK, hur många människor här inne går i Microsoft Word och medvetet använder aldrig stavekontrollen?" Och ingen räcker upp, för för att skriva dokument, vi vet alla att vi kan göra engelska misstag, och så använder alla stavkontrollen. Och jag sa: ”Tja, hur kommer det att när du skriver i din IDE som Visual Basic, du inte använder felsökaren? Det är samma sak, det är som en stavningskontroll. "
Dez Blanchfield: Ja, det är en fantastisk analogi. Jag tänkte verkligen inte, 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 sätta in en ordbehandlare, orsaka att det är ett intressant väckning som bara inser att du har gjort några skrivfel eller till och med ett grammatikfel, eller hur?
Bert Scalzo: Exakt.
Dez Blanchfield: Så, ser du mer av en uptick nu från jag antar, jag menar, 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 utvecklas innan du utvecklas? 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 dina koder rensas i förväg. Eller är det så att de borde överväga den här delen av sin post-distribution?
Bert Scalzo: Idealt skulle de göra det på förhand, men eftersom alla är i den livliga, livliga världen där de bara fick göra saker, tenderar de att göra det förrän de stöter på ett prestandaproblem som de inte kan lösa genom att 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 verkligen inte, gör det?
Bert Scalzo: Exakt, ja, du kan köra detta i molnet.
Dez Blanchfield: Utmärkt, för jag tror att det är så vart 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 stanna hos oss, även om vi har gått förbi timmen.
Eric Kavanagh: Ja, det finns några folk där ute, jag ska bara kommentera: Bert, jag tror att metaforen, den analogi du ger till stavningskontroll är uppriktigt lysande. Det är värt en blogg eller två, helt uppriktigt, eftersom det är ett bra sätt att rama in vad det är som du gör, och hur värdefullt det är, och hur det verkligen borde vara en bra praxis att använda en felsökare på en regelbunden basis, 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, 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: Höger. Ja verkligen. Tja, folk, vi har brunnit 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å lägg till detta till denna lista här.
Och med det, skulle jag hälsa farväl, folkens. Återigen, bra jobb, Bert, tack till våra vänner från IDERA. Tala med dig nästa gång, ja, prata med dig nästa vecka. Ta hand om dig! Hejdå.