Snelle reactie: database debuggen en profileren voor de redding

Afhaal: Gastheer Eric Kavanagh besprak het debuggen en profileren van databases met Dr. Robin Bloor, Dez Blanchfield en IDERAs Bert Scalzo.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Eric Kavanagh: Oké, dames en heren, het is 4:00 Eastern Time op een woensdag, en dat betekent natuurlijk.

Robin Bloor: Ik kan je niet horen, Eric.

Eric Kavanagh: Ik was er dagen geleden, dus je bent niet alleen. Maar het onderwerp van vandaag is dus echt interessant. Het is het soort dingen waarvan je zeker wilt zijn dat dit op de achtergrond in je bedrijf gebeurt, tenzij je de persoon bent die het doet, in welk geval je er zeker van wilt zijn dat je het goed doet. Omdat we het hadden over debuggen. Niemand houdt van bugs, niemand houdt van wanneer de software stopt met werken - mensen raken overstuur, gebruikers worden onvriendelijk. Dat is niet goed. Dus gingen we het hebben over 'Snelle reactie: database debuggen en profileren naar de redding'.

Er is echt een plekje over dat van jou, sla me op, @eric_kavanagh natuurlijk.

Dit jaar is heet. En foutopsporing wordt hot, wat er ook gebeurt. Het gaat echt een van deze problemen zijn die nooit weg zullen gaan, hoe goed we ook in dit soort dingen worden, er zullen altijd problemen zijn, dus de sleutel is hoe kom je bij waar je die problemen snel kunt oplossen? In het ideale geval heb je geweldige programmeurs, geweldige omgevingen, waar niet teveel misgaat, maar zoals het oude gezegde luidt: "Ongelukken gebeuren in de beste families." En hetzelfde geldt voor organisaties. Dus dit soort dingen gebeurt, het gaat gebeuren, de vraag is wat jouw oplossing zal zijn om ermee om te gaan en die problemen op te lossen?

Goed gehoord van Dr. Robin Bloor, dan onze eigen Dez Blanchfield van beneden en natuurlijk onze goede vriend, Bert Scalzo, van IDERA. En in feite ga ik de sleutels overhandigen aan Robin Bloor, haal het weg. De vloer is van jou.

Robin Bloor: OK. Dit is een interessant onderwerp. Ik dacht omdat Dez waarschijnlijk verder gaat over de feitelijke technieken en oorlogsverhalen over debuggen. Ik dacht dat ik gewoon een achtergronddiscussie zou houden zodat we een volledig afgerond beeld zouden krijgen van wat er aan de hand is. Ik deed dit lang, en ik was een coder, dus het is zo, en ik was bijna verleid met deze presentatie om lyrisch te worden over het idee van open source, maar ik dacht dat ik dat aan iemand anders overliet.

Hier is een lijst met beroemde bugs, en de meeste hiervan komen op de toplijst van anybodys, eigenlijk, alles behalve de laatste twee kosten minstens $ 100 miljoen. De eerste was de Mars Climate Orbiter, verdwaalde in de ruimte en het was vanwege een coderingsprobleem, waarbij mensen metrische eenheden verward met (lacht) voeten en centimeters. Bij de Ariane Five Flight 501 was er een mismatch tussen een motor die werd aangezet en de computers die bij de lancering van de raket zouden moeten draaien. Meerdere computerstoringen, exploderende raket, nieuws. Sovjet-gasleiding in 1982, naar verluidt de grootste explosie in de geschiedenis van de planeet; Ik weet niet zeker of dat zo is. De Russen hebben wat geautomatiseerde besturingssoftware gestolen, en de CIA besefte dat ze dat gingen doen en er bugs in zouden stoppen, en de Sovjets implementeerden het zonder te testen. Dus blies een pijpleiding omhoog, dacht dat was grappig.

De Morris-worm was een coderingsexperiment, dat plotseling een roofzuchtige worm werd die iedereen om zich heen draaide - het veroorzaakte blijkbaar voor 100 miljoen dollar schade; dat is natuurlijk een schatting. Intel maakte een beroemde fout met een wiskundechip - een wiskunde-instructie op de Pentium-chip in 1993 - die naar verluidt meer dan $ 100 miljoen had gekost. Apples Maps-programma is mogelijk de slechtste en meest rampzalige lancering van alles wat Apple ooit heeft gedaan. Mensen die het probeerden te gebruiken, bedoel ik, iemand reed langs 101 en ontdekte dat de Apple Map zei dat ze zich in het midden van de Baai van San Francisco bevonden. Dus begonnen mensen naar de Apple Maps-app te verwijzen als iLost. De - onze langste storing in 1990 - het is gewoon interessant vanuit een oogpunt van de kosten van zoiets - AT&T waren ongeveer negen uur onderweg en kostte ongeveer $ 60 miljoen aan langeafstandsgesprekken.

En ik was bij een Britse verzekeringsmaatschappij en de database, ze implementeerden een nieuwe versie van de database en deze begon gegevens te wissen. En dat kan ik me nog goed herinneren, omdat ik daarna ben opgeroepen om deel te nemen aan een soort databaseselectie. En het was erg interessant dat ze een nieuwe versie van de database hadden genomen, en ze hadden een hele reeks tests die ze deden voor nieuwe versies van de database die alle tests doorstaan ​​hadden. Het vond een echt obscure manier om gegevens te wissen.

Dus dat is in elk geval dat. Ik dacht dat ik het had over de impedantie-mismatch en de uitgegeven SQL. Het is interessant dat relationele databases gegevens opslaan in tabellen en coders de neiging hebben om gegevens te manipuleren in objectstructuren die niet erg goed aan tabellen kunnen worden toegewezen. En daarom krijg je wat de impedantie-mismatch wordt genoemd, en iemand moet er op de een of andere manier mee omgaan. Maar wat er feitelijk gebeurt, omdat het ene model, het codeermodel en de database een ander model, niet bijzonder op elkaar zijn afgestemd. Je krijgt bugs die gewoon niet zouden gebeuren als de industrie dingen had gebouwd die samenwerken, wat volgens mij hilarisch is. Dus, in feite, aan de kant van de codeur, wanneer je hiërarchieën krijgt, kunnen dit typen zijn, kan dit sets opleveren, kan het een slechte API-capaciteit zijn, het kunnen veel dingen zijn die dingen gewoon weggooien in termen van interactie met de database. Maar het ding dat voor mij het meest interessant is; verbaasde me altijd dat je deze SQL-barrière had die ook een soort impedantie is op een manier dat de coders en de database met elkaar samenwerken. SQL heeft dus gegevensherkenning, wat prima is en het heeft DML voor selecteren, projecteren en samenvoegen, wat prima is. Je kunt daarmee heel wat mogelijkheden gooien om gegevens uit de database te halen. Maar het heeft heel weinig wiskundige taal om dingen te doen. Het heeft een beetje van dit en dat, en het heeft heel weinig tijdgebaseerde dingen. En daarom is SQL een imperfecte manier om de gegevens te verkrijgen. Dus de jongens van de database bouwden opgeslagen procedures om in de database te leven en de reden voor de opgeslagen procedures daar was dat je niet echt gegevens heen en weer naar een programma wilde gooien.

Want sommige functionaliteit was extreem dataspecifiek, dus het was niet alleen referentiële integriteit en cascading deletes en dat soort dingen, de database zorgde voor alle plotselinge functionaliteit die je in een database stopte, wat natuurlijk betekende dat de functionaliteit voor een applicatie kan worden verdeeld tussen de coder en de database zelf. En dat maakte het uitvoeren van sommige functies heel moeilijk en daarom meer foutgevoelig. Dus, dat is één kant van het database-spel, omdat het betekent dat je bijvoorbeeld veel implementaties hebt gekregen, dat ik betrokken ben geweest bij relationele databases, er is echt heel veel code die in opgeslagen procedures zit die apart van de code wordt behandeld zit in de applicaties. En het lijkt een heel vreemd ding om te hebben, het wordt verondersteld redelijk slim te zijn in het doen van verschillende dingen.

Ik dacht dat Id ook over databaseprestaties sprak omdat prestatiefouten vaak als bugs worden beschouwd, maar in principe kun je een bottleneck hebben bij de CPU, bij het geheugen, op de schijf, op het netwerk en kun je prestatieproblemen hebben vanwege vergrendeling. Het idee zou zijn dat de codeur zich niet echt zorgen hoeft te maken over de prestaties en dat de database in feite redelijk goed presteert. Het hoort zo te zijn ontworpen dat de codeur dit niet hoeft te weten. Je krijgt echter een slecht database-ontwerp, je krijgt een slecht programma-ontwerp, je krijgt gelijktijdigheid in het mixen van workloads, wat ook kan leiden tot prestatieproblemen. U krijgt load balancing, u krijgt capaciteitsplanning, datagroei - waardoor een database gewoon stopt of vertraagt. Het is interessant, wanneer databases bijna vol raken, vertragen ze. En u kunt problemen hebben met gegevenslagen in termen van replicatie en de noodzaak om te repliceren en de noodzaak om back-up en herstel te doen. Hoe dan ook, dat is een algemeen overzicht.

Het enige dat ik zou willen zeggen, is dat het debuggen van databases alleen zo belastend en niet-triviaal kan zijn - en ik zeg dat omdat ik er veel van heb gedaan - en je zult vaak ontdekken zoals alle situaties in debuggen die ik ooit heb meegemaakt is, is het eerste wat je ooit ziet een puinhoop. En je moet proberen om van de puinhoop te gaan om erachter te komen hoe de puinhoop is ontstaan. En vaak wanneer u naar een databaseprobleem kijkt, kijkt u alleen naar corrupte gegevens en denkt u: "Hoe is dat in godsnaam gebeurd?"

Hoe dan ook, ik zal het doorgeven aan Dez, die waarschijnlijk meer woorden van wijsheid gaat zeggen dan waar ik mee kwam. Ik weet niet hoe ik je de bal moet geven, Dez.

Eric Kavanagh: Ik zal het passeren, stand-by, wacht even.

Geautomatiseerde stem: Deelnemerslijnen gedempt.

Eric Kavanagh: Oké, wacht even, laat me Dez de bal geven.

Dez Blanchfield: Bedankt, Eric. Ja, Dr. Robin Bloor, u hebt inderdaad het meeste gelijk: dit is een onderwerp, een levenslange bugbear als u de woordspeling gratie verleent, sorry dat ik mezelf daar niet aan kon helpen. Hopelijk kun je mijn eerste scherm daar zien, mijn excuses voor het probleem met de lettergrootte bovenaan. Het onderwerp van bugs is een daglange lezing, in veel gevallen mijn ervaring. Het is zo'n breed en breed onderwerp, dus ik ga de focus leggen op twee belangrijke gebieden, met name het concept van wat we als een bug beschouwen, maar een programmeerprobleem. Ik denk dat tegenwoordig het introduceren van een bug op zichzelf meestal wordt opgepikt door de geïntegreerde ontwikkelomgevingen, hoewel het mogelijk langdurige bugs zijn. Maar vaak is het meer een geval van profilering van code en het is mogelijk om code te schrijven die werkt, dat zou een bug moeten zijn. Dus, mijn titeldia hier, had ik eigenlijk een kopie hiervan in een zeer hoge resolutie A3, maar helaas werd het vernietigd in een verhuizing. Maar dit is een handgeschreven notitie op een programmeerblad uit circa 1945, waar zogenaamd wat mensen aan de Harvard University in de VS, hun tweede build van een machine genaamd Mark II. Ze debugden in een probleem, in de gewone taal, maar ze probeerden een fout te vinden en het bleek dat er iets anders was dan een hardware- en zogenaamd softwareprobleem.

De stedelijke mythe is dus die rond 9 september^th, 1945, een team van Harvard University trok een machine uit elkaar, ze kwamen iets tegen dat ze "estafette zeventig" noemden - in die dagen werd programmeren in fysieke zin gedaan, je wikkelde code rond een bord, en dat was hoe je effectief de machine - en ze vonden dit relais nummer zeventig er was iets mis mee, en het bleek dat de werkelijke term "bug" ontstond omdat het letterlijk een mot was - vermoedelijk zat er een mot vast tussen een stuk koperdraad van de ene plaats naar de andere. En het verhaal gaat dat de legendarische Grace Hopper als dit bijschrift, voor mijn titeldia, "eerste werkelijke geval van een gevonden bug" citaat citeert.

Maar zoals Robin eerder in zijn eerste dia benadrukte, gaat het concept van een bug zo ver terug als we ons kunnen voorstellen dat mensen berekenen, concepten als een patch. De term "patch" kwam van een stuk plakband dat over een gat op een ponskaart werd geplakt. Maar het hele punt hiervan is dat de term "debuggen" voortkwam uit dit concept van het vinden van een bug in een fysieke machine.En sindsdien hebben we die terminologie gebruikt om problemen aan te pakken, niet zozeer als coderingsproblemen in een programma dat niet compileert, maar als een programma dat niet goed loopt. En specifiek is niet geprofileerd, zoek dingen zoals eindeloze lussen die nergens heen gaan.

Maar we hebben ook een scenario, en ik dacht dat Id een paar grappige dia's had geplaatst voordat ik wat meer in detail ging. Hier is de klassieke cartoon, XKCD genoemd op het web, en de cartoonist heeft een aantal vrij grappige kijk op de wereld. En deze gaan over een kind genaamd "Little Bobby Tables" en vermoedelijk noemden zijn ouders deze jonge jongen Robert); DROP TAFEL Studenten; - en het wordt genoemd, en soort van: "Hallo, dit is de school van je zoon die wat computerproblemen heeft," en de ouder antwoordt: "Oh schat, heeft hij iets gebroken?" En de leraar zegt: "Wel, in zekere zin, 'en de leraar vraagt,' heb je je zoon echt Robert genoemd); DROP TABLE Studenten; -? ”En de ouder zegt:“ Oh ja, kleine Bobby Tables noemen we hem. ”Hoe dan ook, ze zeggen verder dat ze nu de jarenlange studentenrecords hebben verloren, ik hoop dat je gelukkig bent. En het antwoord is: "Wel, u moet uw database-invoer opschonen en opschonen." En ik gebruik dat vaak om te praten over enkele van de problemen die we hebben bij het vinden van dingen in code, dat de code vaak niet ook naar de gegevens kijkt .

Nog een grappige, ik weet niet of dit echt is of niet - ik vermoed dat het een spoof is - maar nogmaals, het raakt ook mijn grappige bot. Iemand verandert de kentekenplaat aan de voorkant van hun auto, in een soortgelijke verklaring die ervoor zorgt dat databases flitsen in flitsers enzovoort die de nummerplaten van auto's vastleggen. En ik verwijs er altijd naar dat ik betwijfel of een programmeur een hit en run van zijn code verwachtte door een echt motorvoertuig, maar onderschat dat nooit - de kracht van een boze nerd.

(Gelach)

Maar dit leidt naar mijn kernpunt, denk ik, en dat is dat we ooit code konden debuggen en profileren als louter stervelingen. Maar ik ben heel erg van mening dat die tijd is verstreken, en anekdotisch in mijn ervaring, mijn eerste - en dit zal me vreselijk verouderen, ik weet het zeker; Robin, je bent van harte welkom om me hiervoor uit te lachen - maar historisch kom ik op een leeftijd van 14 op de leeftijd aan het eind van de stad, kloppend op de deur van een datacenter genaamd "Data Com" in Nieuw-Zeeland en vraag of Ik kon zakgeld verdienen op de school door de late bus naar huis te nemen, elke dag zo'n 25 km woon-werkverkeer, papier in dozen en tapes in tapedrives en gewoon een algemene admin. En merkwaardig genoeg gaven ze me een baan. Maar in de loop van de tijd slaagde ik erin mezelf in de staf te krijgen en de programmeurs te vinden en realiseerde ik me dat ik van coderen hield en het proces van het uitvoeren van scripts en batchtaken doorging, wat aan het einde van de dag nog steeds code is. Je moet scripts en batchtaken schrijven die eruit zien als miniprogramma's en dan het hele proces doorlopen om met de hand op een 3270 terminal te schrijven.

Mijn allereerste ervaring was zelfs op een teletype-terminal, die eigenlijk 132-koloms fysiek was. Denk in wezen aan een heel oude typemachine met papier dat erdoorheen scrolde, omdat ze geen CRT-buis hadden. En het debuggen van code daarover was een heel niet-triviaal probleem, dus je hebt de neiging om al je code met de hand te schrijven en je vervolgens als een typist te gedragen, je best doen om geen fouten te laten binnensluipen, omdat het buitengewoon frustrerend is om te moeten vertellen de eenregelige editor om naar een bepaalde regel te gaan en vervolgens de regel en deze vervolgens weer in te typen. Maar eens, dat was de manier waarop we code schreven en dat is hoe we debugden, en we werden er heel, heel goed in. En in feite dwong het ons om zeer goede programmeertechnieken te hebben, omdat het een heel gedoe was om het te repareren. Maar de reis ging toen door - en was hier allemaal bekend mee - het ging van de 3270 terminalervaring in mijn wereld, naar Digital Equipment VT220 waar je dingen op het scherm kon zien, maar nogmaals, je deed gewoon hetzelfde als wat je deed op de papieren band soort ed-formaat alleen op een CRT, maar je was in staat om gemakkelijker te verwijderen en je had dat "dit dit dit dit" geluid niet.

En dan weet je, de Wyse-terminals - zoals de Wyse 150, waarschijnlijk mijn favoriete interface voor een computer ooit - en dan de pc en vervolgens de Mac, en tegenwoordig moderne GUI's en ID's die webgebaseerd zijn. En een reeks programma's daardoor, programmering in één en assembler en PILOT en Logo en Lisp en en Fortran en Pascal en talen die mensen ineenkrimpen. Maar dit zijn talen die je dwongen om goede code te schrijven; ze lieten je niet wegkomen met slechte praktijken. C, C ++, Java, Ruby, Python - en we komen verder in dat programmeerstadium, we krijgen meer script-achtig, we komen steeds dichter bij Structured Query Language en talen zoals PHP die eigenlijk worden gebruikt om SQL op te roepen. Het punt om je te vertellen dat, vanuit mijn achtergrond, ik op veel manieren autodidact was en degenen die me hebben geholpen leren, hebben me heel goede programmeermethoden en zeer goede methoden rond ontwerp en processen geleerd om ervoor te zorgen dat ik geen buggy introduceerde code.

Tegenwoordig programmeermethoden, dingen zoals bijvoorbeeld Structured Query Language, SQL, het is een zeer krachtige, eenvoudige querytaal. Maar we hebben er een programmeertaal van gemaakt en ik geloof niet echt dat SQL ooit is ontworpen als een moderne programmeertaal, maar we hebben het scheef getrokken om dat te worden. En dat brengt een hele reeks problemen met zich mee, omdat we vanuit twee invalshoeken denken: vanuit coderingsoogpunt en vanuit het oogpunt van DBA. Het is heel gemakkelijk om mee te gaan en bugs te introduceren voor dingen zoals slechte programmeertechnieken, luie inspanningen om code te schrijven, gebrek aan ervaring, de klassieke pet peeve die ik bijvoorbeeld heb met SQL-mensen die op Google springen en naar iets zoeken en een website vinden die kreeg een voorbeeld en deed een kopie en plak van bestaande code. En vervolgens een slechte codering, wanpraktijken repliceren en in productie nemen, omdat het hen toevallig de resultaten geeft die ze willen. Je hebt andere uitdagingen, bijvoorbeeld, deze dagen renden hier allemaal naartoe, wat we de race naar nul noemen: proberen alles zo goedkoop en zo snel te doen, dat we een scenario hebben waarbij we geen lagerbetaalde medewerkers in dienst hebben. En dat bedoel ik niet op een oneerlijke manier, maar ik huurde geen experts in voor elke mogelijke baan. Er was eens alles wat met computers te maken had, raketwetenschap; het was betrokken bij dingen die knalden en heel luid waren, of de ruimte ingingen of ingenieurs waren zwaar gekwalificeerde mannen en vrouwen die een diploma hadden behaald en een rigoureuze opleiding hadden gevolgd die hen ervan weerhield gekke dingen te doen.

Tegenwoordig zijn er veel mensen die zich bezig houden met ontwikkeling en ontwerp en database die geen jarenlange ervaring hebben, havent had noodzakelijkerwijs dezelfde training of ondersteuning. En zo eindig je met een scenario van alleen de traditionele amateur versus expert. En er is een beroemde regel, ik kan me eigenlijk niet herinneren wie de quote heeft gemaakt, de regel luidt: "Als je denkt dat het duur is om een ​​expert in te huren om een ​​klus te klaren, wacht dan tot je een paar amateurs inhuurt die een probleem veroorzaken en je moet ruim het op. ”En dus heeft SQL dat probleem, en het is heel, heel gemakkelijk te leren, het is heel gemakkelijk te gebruiken. Maar het is naar mijn mening geen perfecte programmeertaal. Het is heel gemakkelijk om dingen te doen zoals een select star doen waar dan ook en dat allemaal in een programmeertaal brengen waar je je comfortabeler bij voelt, zoals PHP en Ruby of Python, en de programmeertaal gebruiken die je van nature kent, om de gegevensmanipulatie uit te voeren, in plaats van een complexere query in SQL uit te voeren. En we zien dit vaak, en dan vragen mensen zich af waarom de database traag is; het is omdat een miljoen mensen proberen een ticket te kopen van een online ticketingsysteem, waar het een select star van waar dan ook doet.

Dat is echt een extreem voorbeeld, maar daar krijg je het punt van. Dus, om dat punt echt naar huis te halen, hier is een voorbeeld dat ik vaak ronddraag. Ik ben een grote fan van wiskunde, ik hou van chaostheorie, ik hou van de Mandelbrot-sets. Aan de rechterkant is er een weergave van de Mandelbrot-set, die ik zeker allemaal kende. En aan de linkerkant is er een stukje SQL dat dat eigenlijk weergeeft. Nu, elke keer als ik dit ergens op een scherm plaats, hoor ik dit: "Oh mijn god, iemand heeft de Mandelbrot-serie met SQL weergegeven, meen je dat? Dat is krankzinnig! ”Welnu, het hele punt is om te illustreren wat ik daar net heb geschetst, en dat is ja, in feite kun je nu bijna alles programmeren in SQL; het is een zeer sterk ontwikkelde, krachtige, moderne programmeertaal. Toen het oorspronkelijk een query-taal was, was het ontworpen om alleen gegevens te verzamelen. Dus nu hebben we zeer complexe constructies en hebben we opgeslagen procedures, we hebben programmeermethodes toegepast op een taal en dus is het heel gemakkelijk voor slechte programmeerpraktijken, gebrek aan ervaring, knip-en-plak code, laagbetaalde medewerkers die proberen hoogbetaalde medewerkers zijn, mensen die doen alsof ze het weten, maar ze moeten leren tijdens het werk.

Een hele reeks dingen waar codeprofilering en wat we 'debuggen' noemen, is niet zozeer het vinden van bugs die programma's niet meer laten werken, maar bugs die alleen het systeem beschadigen en slecht gestructureerde code. Als je nu naar dit scherm kijkt, en je denkt dat het gewoon schattig is, en je denkt: "Wauw, wat een geweldige afbeelding, ik vind het geweldig om dat uit te voeren." Maar stel je eens voor dat je dat op een stukje bedrijfslogica uitvoert. Het ziet er vrij netjes uit, maar het spreekt een wiskundig grafisch weergegeven chaostheorie, maar als je nadenkt over waarvoor het in sommige bedrijfslogica zou kunnen worden gebruikt, krijg je het beeld heel snel. En om dat echt te illustreren - en het spijt me dat de kleuren zijn omgekeerd, het wordt verondersteld een zwarte achtergrond te zijn en groen als een groen scherm, maar dat kun je nog steeds lezen.

Ik ging en bekeek snel een voorbeeld van wat je mogelijk zou kunnen doen als je echt gek was en geen enkele ervaring had en vanuit een andere programmeerachtergrond kwam en het soort C ++ op SQL toepaste, om mijn punt echt te illustreren, voordat Ik draag het over aan onze geleerde gast van IDERA. Dit is een gestructureerde query die is geschreven als C ++, maar is gecodeerd in SQL. En het wordt daadwerkelijk uitgevoerd, maar het duurt ongeveer drie tot vijf minuten. En het trekt ogenschijnlijk één dataregel uit meerdere databases, meerdere joins.

Nogmaals, het hele punt hiervan is dat als je niet de juiste tools hebt, als je niet de juiste platforms en omgevingen hebt om deze dingen te kunnen vangen, en ze in productie gaan, en dan heb je 100.000 mensen die elk een systeem raken dag, of uur, of minuut, je eindigt heel snel met een Tsjernobyl-ervaring waar het grote ijzer begint te smelten en zich begraaft tot de kern van de planeet, omdat dat stukje code nooit in productie mag komen. Uw systemen en uw tools, neem me niet kwalijk, zouden dat moeten oppakken voordat het ergens in de buurt van komt - zelfs door het testproces, zelfs door UAT en systeemintegratie, dat stuk code moet worden opgepakt en gemarkeerd en iemand moet terzijde worden geschoven en zeggend: "Kijk, dat is echt mooie code, maar laten we een DBA krijgen om je te helpen die gestructureerde query correct op te bouwen, want eerlijk gezegd, dat is gewoon vies." En de URL's daar, je kunt gaan kijken - het wordt de meest complexe SQL-query die u ooit hebt geschreven. Want geloof me, dat compileert echt, het loopt wel. En als je dat knipt en plakt en de database gewoon opmaakt, is het heel wat om naar te kijken; als je de tools hebt om de database te bekijken, probeer het dan gewoon over een periode van drie tot vijf minuten te laten smelten, om terug te bellen wat één regel is.

Dus, om dat samen te vatten, heeft mijn hele achtergrond in codering me geleerd dat je mensen een pistool kunt geven en als ze niet oppassen, schieten ze zichzelf in de voet; de kunst is om ze te laten zien waar het veiligheidsmechanisme is. Met de juiste tools en de juiste software binnen handbereik, nadat u de codering hebt gedaan, kunt u uw code bekijken, kunt u problemen vinden door de code te profileren, kunt u effectief onbedoelde bugs vinden die prestatieproblemen zijn, en zoals ik eerder zei op , ooit kon je het doen door naar een groen scherm te kijken. Je kunt niet meer; er zijn honderdduizenden regels code, er zijn tienduizenden apps geïmplementeerd, er zijn in sommige gevallen miljoenen databases en zelfs supermensen kunnen dit eigenlijk niet meer met de hand doen. Je hebt letterlijk de juiste software en de juiste tools binnen handbereik nodig en je hebt het team nodig om die tools te gebruiken, zodat je deze problemen kunt vinden en heel, heel snel kunt aanpakken voordat je ter zake komt, terwijl Dr. Robin Bloor benadrukt, dingen worden rampzalig, en dingen ontploffen, of vaker, ze beginnen je gewoon veel dollars en veel tijd en moeite te kosten en moraal en zo te vernietigen, als ze niet kunnen achterhalen waarom dingen duren een lange tijd om te rennen.

En met dat in gedachten, ga ik het overhandigen aan onze gast en ik kijk ernaar uit om te horen hoe zij dit probleem hebben opgelost. En vooral de demo die ik denk te ontvangen. Eric, ik zal teruggaan.

Eric Kavanagh: Oké, Bert, haal het weg.

Bert Scalzo: OK, bedankt. Bert Scalzo hier van IDERA, ik ben de productmanager voor onze database-tools. En ik ga het hebben over debuggen. Ik denk dat een van de belangrijkste dingen die Robin eerder zei - en het is heel waar dat debuggen lastig en niet-triviaal is, en wanneer je naar database gaat debuggen is het een orde van grootte nog zwaarder en niet-triviaal - dus dat was een belangrijk citaat.

OK. Ik wilde beginnen met programmeergeschiedenis, omdat ik vaak mensen zie die niet debuggen, ze gebruiken geen debugger, ze programmeren gewoon met welke taal ze ook gebruiken, en vaak zeggen ze tegen me: "Wel, die dingen voor het opsporen van fouten zijn nieuw, en die zijn we nog niet gaan gebruiken. ”En dus wat ik doe is dat ik ze deze tijdlijngrafiek laat zien, een soort voorgeschiedenis, de ouderdom, de middeleeuwen, het is een soort van waar we waren voorwaarden van programmeertalen. En we hadden hele oude talen vanaf 1951 met assemblagecode, en Lisp en FACT en COBOL. Dan komen we in de volgende groep, Pascals en Cs en dan de volgende groep, de C ++ s, en kijken waar dat vraagteken is - dat vraagteken is ongeveer rond 1978 tot misschien 1980. Ergens in dat bereik hadden we debuggers die voor ons beschikbaar zijn, en om te zeggen: "Hé, ik gebruik geen debugger, want dat is een van die nieuwe dingen," dan moet je in de jaren 1950 zijn begonnen met programmeren, want dat is de enige manier waarop je weg met die claim.

Het andere dat grappig is aan deze grafiek is dat Dez zojuist een opmerking heeft gemaakt over Grace Hopper, ik kende Grace eigenlijk, dus het is best grappig. En dan was het andere waar ik om lachte, dat hij het had over teletypes en ik zat daar te gaan zitten: "Man, dat was de grootste sprong die we ooit in productiviteit hadden, toen we van kaarten naar teletypes gingen, dat was de grootste sprong ooit." , en ik heb hier in alle talen geprogrammeerd, inclusief SNOBOL, waar nog nooit iemand van heeft gehoord, het was een CDC, Control Data Corporation, dus ik denk dat ik een beetje te oud word voor deze industrie.

Dez Blanchfield: Ik wilde zeggen dat je ons daar vreselijk oud hebt gemaakt.

Bert Scalzo: Ja, ik zeg het je, ik voel me opa Simpson. Dus ik kijk naar debuggen en er zijn verschillende manieren om debuggen te doen. Je zou kunnen praten over wat we allemaal beschouwen als traditioneel om in een debugger te stappen en door code te bladeren. Maar ook zullen mensen hun code instrumenteren; dat is waar u verklaringen in uw code steekt en misschien produceert u een uitvoerbestand, een tracebestand of zo, en dus instrumenteert u uw code. Ik zou dat als debuggen beschouwen, het is een beetje moeilijker, een manier om het te doen, maar het telt. Maar ook, we hebben de beroemde uitspraak: je kijkt en mensen zetten eigenlijk verklaringen in en ik heb eigenlijk een tool gezien waar - en het is een database-tool - waar als je niet weet hoe je een debugger moet gebruiken, je op een knop drukt en het blijft hangen uitspraken in uw code voor u en wanneer u klaar bent, drukt u op een andere knop en deze wordt eruit gehaald. Omdat dat is hoe veel mensen debuggen.

En de reden waarom we debuggen is tweeledig: allereerst moeten we dingen vinden die onze code niet effectief maken. Met andere woorden, meestal betekent dit dat er een logische fout is opgetreden of dat we een zakelijke vereiste hebben gemist, maar wat het is, is dat de code niet effectief is; het doet niet wat we hadden verwacht. De andere keer dat we gaan en we debuggen, is het voor efficiëntie en dat kan een logische fout zijn, maar wat het is, is dat ik het juiste heb gedaan, het komt gewoon niet snel genoeg terug. Nu maak ik dat punt omdat profilers waarschijnlijk beter waren voor dat tweede scenario en over zowel debuggers als profilers gingen praten. Bovendien is er dit concept van foutopsporing op afstand; dit is belangrijk omdat vaak als je op je pc zit en je een debugger gebruikt die een database raakt waar de code daadwerkelijk wordt uitgevoerd, je eigenlijk doet wat externe foutopsporing wordt genoemd. Je beseft het misschien niet, maar dat is wat er gebeurt. En dan is het heel gebruikelijk bij deze debuggers om breekpunten te hebben, kijkpunten, stap in en stap over en enkele andere veel voorkomende dingen, die ik die op een momentopname op een scherm ga tonen.

Profilering: u kunt op verschillende manieren profileren. Sommige mensen zullen zeggen dat het vastleggen en opnieuw afspelen van workloads alles vastlegt, dat geldt als profilering. Mijn ervaring is beter geweest als het klaar is met samplen. Er is geen reden om elke afzonderlijke verklaring te vangen, omdat sommige verklaringen zo snel kunnen lopen dat het je niet kan schelen, wat je echt probeert te zien is, nou ja, degenen die steeds weer verschijnen, omdat ze te lang duren . Dus soms kan profilering steekproeven betekenen in plaats van het hele ding te runnen. En meestal krijgt u een soort uitvoer die u kunt gebruiken, nu die visueel zou kunnen zijn in een IDE-ontwikkelomgeving, waar het u mogelijk een histogram geeft van de prestaties van de verschillende coderegels, maar het kan ook nog steeds zij het produceert een traceerbestand.

Profilers verscheen voor het eerst in 1979. Dus die bestaan ​​ook al heel lang. Geweldig voor het vinden van hulpbronnenverbruik, of prestatieproblemen, met andere woorden dat efficiency-ding. Over het algemeen is het apart en anders dan de debugger, hoewel ik met debuggers heb gewerkt die beide tegelijkertijd doen. En hoewel profilers volgens mij de meest interessante van de twee tools zijn, als ik vind dat niet genoeg mensen debuggen, dan zeker niet genoeg mensen profileren, omdat een op de tien debuggers zal profileren, lijkt het. En dat is jammer, want profilering kan echt een enorm verschil maken. Nu, databasetalen, waar we eerder over hebben gesproken, je hebt SQL - en we hebben de ronde pin een soort in het vierkante gat hier gedwongen en gedwongen om een ​​programmeertaal te worden - en Oracle.Dat is PL / SQL - dat is procedurele taal SQL - en SQL Server, zijn Transact-SQL, zijn SQL-99, zijn SQL / PSM - voor, denk ik, zijn Procedure Opgeslagen Module. Postgres geeft het een andere naam, DB2 en nog een andere naam, Informix, maar het punt is dat iedereen 3GL-achtige constructies heeft gedwongen; met andere woorden, FOR-lussen, bij variabele declaraties en alle andere dingen die vreemd zijn aan SQL, maken nu deel uit van SQL in die talen. En dus moet u een PL / SQL of een Transact-SQL kunnen debuggen, net zoals een Visual Basic-programma.

Nu, databaseobjecten, dit is belangrijk omdat mensen zullen zeggen: "Wel, welke dingen moet ik debuggen in een database?" En het antwoord is, nou ja, wat u als code in de database kunt opslaan - als ik T doe- SQL of PL / SQL - en ik bewaar objecten in de database, het is waarschijnlijk een opgeslagen procedure of opgeslagen functie. Maar er zijn ook triggers: een trigger is een beetje zoals een opgeslagen procedure, maar het vuurt op een soort gebeurtenis. Nu zullen sommige mensen in hun triggers één regel code plaatsen en een opgeslagen procedure aanroepen zodat ze al hun opgeslagen code en procedures behouden, maar het is hetzelfde concept: het is nog steeds de trigger die het hele ding kan initiëren. En dan als Oracle, hebben ze iets dat een pakket wordt genoemd, wat een soort van bibliotheek is als je wilt. U plaatst 50 of 100 opgeslagen procedures in één groep, een pakket genaamd, dus het is een soort bibliotheek. Dus, hier is de debugger op de oude manier; dit is eigenlijk een hulpmiddel dat daadwerkelijk zal ingaan en al deze foutopsporingsverklaringen voor u in uw code zal plaatsen. Dus, overal waar u debug-blokkering ziet, niet verwijderen, de automatische debugger start en trace, die zaten allemaal vast in een tool. En de regels daarbuiten, wat de minderheid van de code is, nou, dat is de niet-handmatige foutopsporingsmethode.

En de reden dat ik dit ter sprake breng is, als je dit met de hand probeert te doen, ga je eigenlijk meer foutopsporingscode typen om in al deze verklaringen te stoppen dan met de code. Dus, hoewel dit misschien werkt, en hoewel het beter is dan niets, is dit een heel moeilijke manier om te debuggen, vooral omdat, wat als het tien uur heeft geduurd voordat dit ding wordt uitgevoerd en waar het een probleem heeft in regel drie? Als ik bezig was met een interactieve debug-sessie, zou ik het op regel drie - vijf minuten geweten hebben - hé, hier is een probleem, ik kan stoppen. Maar hiermee moet ik wachten tot het is voltooid, helemaal tot voltooiing en dan moet ik naar een tracebestand kijken dat waarschijnlijk al deze verklaringen bevat, en proberen de naald in de hooiberg te vinden. Nogmaals, dit is beter dan niets, maar het zou niet de beste manier zijn om te werken. Nu, dit is hoe dat bestand eruit zou zien dat afkomstig was van de vorige dia; met andere woorden, ik heb het programma uitgevoerd en het heeft zojuist een aantal uitspraken in dit tracebestand en ik kan dit wel of niet doornemen en vinden wat ik moet vinden. Dus nogmaals, ik ben er niet zo zeker van dat dit de manier is waarop je zou willen werken.

Nu, interactieve debuggers - en als je zoiets als Visual Studio hebt gebruikt om programma's te schrijven, of Eclipse, had je debuggers en je gebruikte ze met je andere talen - dacht gewoon niet dat je ze hier met je database kon gebruiken. En er zijn tools die er zijn, zoals onze DB Artisan en onze Rapid SQL, dit is Rapid SQL hier, die een debugger hebben, en je kunt aan de linkerkant zien dat ik een opgeslagen procedure heb die 'controleren op duplicaten' wordt genoemd. Kortom, het gaat gewoon kijken en kijken of ik meerdere rijen in de tabel heb met dezelfde filmtitel. De database is dus bedoeld voor films. En je kon aan de rechterkant zien, op het bovenste derde deel, ik heb mijn broncode in het midden, ik heb wat mijn watch-variabelen en mijn call-stack-trays worden genoemd, en onderaan kreeg ik wat output s. En wat hier belangrijk is, is dat als je over die eerste rode pijl kijkt, als ik over een variabele ga, ik daadwerkelijk kan zien welke waarde op dat moment in die variabele zit, terwijl ik door de code stap. En dat is echt handig, en dan kan ik stap voor stap door de code stappen, ik hoef niet te zeggen uitvoeren, ik zou stap voor stap kunnen zeggen, laat me kijken wat er is gebeurd, stap nog een regel, laat me zien wat er is gebeurd, en Ik doe dit in de database. En ook al zit ik op Rapid SQL op mijn pc en mijn database bevindt zich in de cloud, ik kan nog steeds dat externe foutopsporing doen en het vanaf hier bekijken en beheren, en debuggen net zoals ik zou doen met elke andere taal.

Nu, de volgende pijl daar - je kunt de kleine pijl zien die naar rechts wijst, naar die DBMS-uitgang, dat is waar mijn cursor op dit moment is - dus met andere woorden, ik heb een stap gezet en dat is waar ik op dit moment ben. Dus als ik zeg: "Stap weer", ga ik naar die volgende regel. Nu net daaronder zie je de rode stip. Nou, dat is een breekpunt, dat zegt: "Hé, ik wil niet over deze lijnen stappen." Als ik gewoon over alles heen wil springen en naar die rode stip wil gaan, kan ik op de knop Run drukken en vanaf hier ook lopen het einde, of tot een breekpunt, als er breekpunten zijn ingesteld, en dan zal het stoppen en laat ik het stappen opnieuw doen. En de reden dat dit allemaal belangrijk en krachtig is, is omdat wanneer ik dit alles doe, wat er in het midden gebeurt en zelfs de onderkant - maar vooral het midden - zal veranderen en ik de waarden van mijn variabelen kan zien, ik kan zie mijn call stack trace, weet je, en dus wordt al die informatie daar weergegeven als Im door de code stap, dus ik kan eigenlijk zien en voelen en begrip krijgen voor wat er aan de hand is en hoe de code daadwerkelijk werkt tijdens de uitvoering . En meestal kan ik een probleem vinden, als er een is, of als ik goed genoeg ben om het op te lossen.

OK, nu ga ik het hebben over een profiler, en in dit geval is dit een profiler die ik door een debugger kan zien. Weet je nog dat ik zei dat ze soms gescheiden zijn en soms kunnen ze samen zijn? In dit geval, en nogmaals, ben ik in Rapid SQL, en ik zie aan de linkerkant een marge naast de regelnummers. En wat dat is, is dat het aantal seconden of microseconden dat nodig was om elke regel code uit te voeren, en ik zie dat duidelijk, al mijn tijd wordt doorgebracht in deze ene FOR-lus waar ik alles uit een tabel selecteer. En dus, wat er ook binnen die FOR-lus gebeurt, is waarschijnlijk iets waar ik naar moet kijken, en als ik het beter kan maken, zal het dividend opleveren. Ik ga geen verbeteringen krijgen door te werken aan lijnen die ongeveer 0.90 of 0.86 hebben; er is niet veel tijd doorgebracht. Nu, in dit geval, en nogmaals, ik ben in Rapid SQL, zie je hoe ik profilering kan doen, vermengd met mijn foutopsporing. Wat leuk is, is dat Rapid SQL je ook in staat stelt het andersom te doen. Met Rapid SQL kun je zeggen: 'Weet je wat? Ik wil niet in de debugger zijn, ik wil dit gewoon uitvoeren en dan wil ik grafisch of visueel hetzelfde type informatie bekijken. ”

En je kunt zien dat ik niet langer in de debugger zit en het programma uitvoert en nadat de uitvoering is voltooid, geeft het me grafieken om me dingen te vertellen, zodat ik kan zien dat ik een verklaring heb die eruitziet alsof hij het grootste deel van de taart in beslag neemt grafiek en als ik kijk, zie ik op dat rooster naar de onderkant, lijn 23, daar is de FOR-lus weer: hij neemt de meeste tijd in beslag, hij is eigenlijk dat donkerrood het hele cirkeldiagram aan het kauwen. En dus is dit een andere manier om te profileren. We noemen dat 'Code Analyst' in onze tool. Maar het is eigenlijk gewoon een profiler gescheiden van een debugger. Sommige mensen doen het graag op de eerste manier, sommige mensen doen het graag op de tweede manier.

Waarom doen we foutopsporing en profilering? Het is niet omdat we 's werelds beste code willen schrijven en een loonsverhoging willen krijgen - dat kan onze reden zijn, maar dat is niet echt de reden waarom je het doet - je hebt het bedrijf beloofd dat je iets correct zou doen, dat je programma effectief zal zijn. Dat is waar u de debugger voor zult gebruiken. Daarnaast zakelijke eindgebruikers; ze zijn niet erg geduldig: ze willen resultaten zelfs voordat ze op de toets drukken. Werden verondersteld hun gedachten te lezen en alles meteen te doen. Met andere woorden, het moet efficiënt zijn. En dat is waar we de profiler voor zouden gebruiken. Nu, zonder deze hulpmiddelen, geloof ik echt dat je deze kerel in het pak bent met de pijl en boog en dat je op het doel schiet en je bent geblinddoekt. Want hoe ga je ontdekken hoe een programma wordt uitgevoerd door alleen maar naar statische code te kijken en hoe kom je erachter welke regel het is waar het de meeste tijd aan uitvoering zou besteden, opnieuw, gewoon door te kijken naar statische code? Een codebeoordeling kan sommige van deze dingen al dan niet opdagen, maar er is geen garantie dat een codebeoordeling ze allemaal zou vinden. Met een debugger en profiler zou je al die bugs moeten kunnen vinden.

OK, ik ga hier gewoon een echte snelle demo doen. Het is niet mijn bedoeling om producten te pushen, ik wil je alleen laten zien hoe een debugger eruit ziet, omdat mensen vaak zullen zeggen: "Ik heb nog nooit een van deze eerder gezien." En het ziet er mooi uit in de schermdia's, maar wat ziet het eruit als het in beweging is? Dus hier op mijn scherm voer ik ons ​​DB Artisan-product uit; we hebben daar ook een debugger. De DB Artisan is meer bedoeld voor DBA's, de Rapid SQL is meer voor de ontwikkelaars, maar ik heb ontwikkelaars gezien die DB Artisan gebruiken en ik heb DBA's gezien die Rapid gebruiken. Dus raak niet verstrikt in het product. En hier heb ik de keuze om een ​​foutopsporing uit te voeren, maar voordat ik de foutopsporing start, ga ik deze code uitpakken zodat je kunt zien hoe de code eruitziet voordat ik hem start. Dus, hier is exact dezelfde code die in de schermopname stond, dit is mijn controle op duplicaten. En ik wil dit debuggen, dus ik druk op debug. En nu duurt het even en u zegt: "Wel, waarom duurt het even?" Onthoud externe foutopsporing: de foutopsporing gebeurt eigenlijk op mijn databaseserver, niet op mijn pc. Dus moest het daarheen gaan en daar een sessie maken, een externe foutopsporingsactie maken, mijn sessie koppelen aan die externe foutopsporingssessie en een communicatiekanaal opzetten.

Dus nu, hier is mijn pijl, het is daar bovenaan, bij regel één, daar ben ik in de code. En als ik daar op het derde pictogram druk, wat een stap is, zie je die pijl net bewegen, en als ik erop blijf drukken, zie je hem blijven bewegen. Nu, als ik helemaal naar deze FOR-lus wilde gaan, omdat ik weet dat dat het probleem is, kan ik een breekpunt instellen. Ik dacht dat ik dat had ingesteld. Oh schiet, ik had een van mijn schermvastlegtoetsen toegewezen aan dezelfde sleutel als de debugger, dat is wat de verwarring veroorzaakt. OK, dus ik stel daar gewoon handmatig een breekpunt in, dus in plaats van een stap, stap, stap, stap te doen totdat ik er ben, kan ik eigenlijk gewoon zeggen: "Ga je gang en voer dit ding uit", en het zal stoppen. Merk op dat het me helemaal naar waar het breekpunt is verplaatst, dus ik ben nu bezig met het uitvoeren van deze lus, ik kan zien waar al mijn variabelen op zijn ingesteld, wat geen verrassing is, want ik heb ze allemaal geïnitialiseerd om nul. En nu kan ik in deze lus stappen en beginnen te kijken naar wat er in deze lus gebeurt.

Dus nu gaat het een selecte telling van mijn huuraccommodaties doen en ik kan over die man heen gaan en kijken, hij twee, twee is groter dan één, dus het gaat waarschijnlijk het volgende stuk van deze code doen. Met andere woorden, het heeft iets gevonden. Ik ga gewoon door en laat dat lopen. Ik wil hier niet alles doornemen; wat ik je wil laten zien is wanneer een debugger klaar is, het eindigt net als een normaal programma. Ik heb het breekpunt ingesteld, dus toen ik zei rennen, ging het gewoon terug naar het volgende breekpunt. Ik laat het tot het einde lopen, want ik wil dat je ziet dat een debugger het gedrag van het programma niet verandert: als het klaar is met draaien, zou ik exact dezelfde resultaten moeten krijgen als ik het niet in een debugger had uitgevoerd.

En daarmee ga ik de demo opschorten en teruggaan want we willen ervoor zorgen dat we tijd hebben voor vragen en antwoorden. En dus zal ik het openstellen voor vragen en antwoorden.

Eric Kavanagh: Oké, Robin, misschien een vraag van jou en dan een stel van Dez?

Robin Bloor: Ja, natuurlijk, ik vind dit natuurlijk fascinerend. Ik heb met zoiets gewerkt, maar ik heb nog nooit met zoiets in de database gewerkt. Kun je me een idee geven waarvoor mensen de profiler gebruiken? Omdat het zo is, kijken ze - want ik neem aan dat ze zijn - kijken ze naar prestatieproblemen, zal het je helpen onderscheid te maken tussen wanneer een database tijd kost en wanneer een code tijd kost?

Bert Scalzo: Weet je, dat is een fantastische vraag. Laten we zeggen dat ik in Visual Basic aan het werk ben, en dat ik binnen mijn Visual Basic Im een ​​Transact-SQL of een PL / SQL ga aanroepen. Laat me de PL / SQL doen, omdat Oracle niet altijd goed speelt met de Microsoft-tools. Ik kan mijn Visual Basic-code profileren en het profiel daar kan zeggen: "Hé, ik heb deze opgeslagen procedure genoemd en het heeft te lang geduurd." Maar dan kan ik in de opgeslagen procedure gaan en kan ik een databaseprofiel op de opgeslagen en zeg: "OK, van de 100 verklaringen die hier staan, zijn hier de vijf die het probleem veroorzaakten." En dus moet u misschien een tagteam doen, waarbij u meerdere profilers moet gebruiken.

Het idee is dat als je ooit te horen krijgt dat het prestatieprobleem zich in je database bevindt, een databaseprofiel je kan helpen de naald in de hooiberg te vinden waarop de uitspraken eigenlijk degene zijn waar je een probleem hebt. Ik vertel je nog iets dat met profilering te maken kreeg: als je een stuk code hebt dat een miljoen keer wordt aangeroepen, maar het kost slechts een van de miljoenen keren, maar het wordt een miljoen keer genoemd, wat de profiler zou tonen , dat ding liep voor zoveel tijdseenheden. En dus terwijl de code zeer efficiënt kan zijn, zou je kunnen kijken en zeggen: "Ooh, we hebben dit stuk code veel te vaak gebeld. Misschien moeten we het maar af en toe noemen, in plaats van elke keer dat we een record verwerken ', of zoiets. En dus kunt u eigenlijk vinden waar er efficiënte code is die gewoon te vaak wordt genoemd, en dat is eigenlijk een prestatieprobleem.

Robin Bloor: Ja, dat is geweldig. Ik heb dit nooit gedaan. Zie je, natuurlijk, toen ik databaseproblemen had, was het alsof ik op de een of andere manier met database te maken had of met code te maken had; Ik zou ze nooit allebei tegelijkertijd kunnen behandelen. Maar nogmaals, ik deed het niet - Ik ben nooit echt betrokken geweest bij het bouwen van applicaties waar we procedures hadden opgeslagen, dus ik denk dat ik nooit problemen heb gehad die me vroeger gek maakten, het idee dat je de code had opgesplitst in een database en een programma. Maar dus, doe alles - Ik veronderstel dat de antwoorden ja zullen zijn, maar dit maakt deel uit van een activiteit van het ontwikkelingsteam, wanneer je op een of andere manier iets probeert te repareren dat stuk is, of misschien probeert een nieuwe applicatie samen te brengen. Maar sluit dit allemaal aan op alle andere componenten die ik in de omgeving zou verwachten? Kan ik verwachten dat ik dit samen met al mijn testpakketten en al die andere dingen die ik zou doen en met mijn projectmanagement-dingen zou kunnen knippen, is dat hoe al deze clips samen?

Bert Scalzo: Ja, het kan onderdeel worden van elk gestructureerd proces om uw programmeer- of ontwikkelingsinspanningen te doen. En het is grappig, vorige week had ik een klant die een webapplicatie bouwde, en hun database was historisch klein, en dus het feit dat ze niet erg goede programmeurs waren, heeft hen nooit pijn gedaan. Nou, hun database is in de loop der jaren gegroeid, en nu duurt het 20 seconden op een webpagina, tussen wanneer je zegt: "Log me in en geef me wat gegevens om te zien" en wanneer het scherm daadwerkelijk verschijnt, en nu is het een prestatieprobleem. En ze wisten dat het probleem niet op hun Java of op die andere plaatsen lag. Maar ze hadden duizenden opgeslagen procedures en dus moesten ze beginnen met het profileren van de opgeslagen procedures om erachter te komen waarom deze webpagina er 20 seconden over doet om te verschijnen? En we ontdekten eigenlijk dat ze een Cartesiaanse deelnemer hadden in een van hun selecte verklaringen en dat niet wisten.

Robin Bloor: Wauw.

Bert Scalzo: Maar iemand zei ooit tegen mij: "Wel, hoe kunnen ze een Cartesiaan laten meedoen en het niet weten?" En dit klinkt echt verschrikkelijk; soms zal een programmeur die niet erg vertrouwd is met SQL zoiets doen als me een Cartesiaanse join geven, maar me dan alleen het eerste record teruggeven, dus ik weet dat ik iets heb, en ik heb alleen de eerste nodig. En dus realiseren ze zich niet dat ze zojuist een miljard records hebben teruggehaald of dat ze een miljard records hebben bekeken, omdat ze degene hebben waarin ze geïnteresseerd waren.

Robin Bloor: Wauw, ik weet het, zo heet - nou, dat was waar Dez mee bezig was, in termen van mensen die niet precies zo bekwaam zijn als ze misschien zouden moeten zijn, weet je. Als u een programmeur bent, moet u weten wat de implicaties zijn van het uitvoeren van een opdracht. Ik bedoel, echt, er is geen excuus voor dat niveau van domheid. Ik ga er ook vanuit dat je op de een of andere manier gewoon taalonafhankelijk bent wat dit betreft, omdat dit allemaal gericht is op de database. Heb ik daar gelijk in? Is het precies hetzelfde, wat je ook aan de codeerzijde gebruikt?

Bert Scalzo: Absoluut, u kunt dit doen in Fortran of C of C ++. Op sommige Unixes kun je het zelfs doen voor hun scripttalen; ze bieden eigenlijk dezelfde tools. En dan wil ik even teruggaan voor wat u zonder excuus zei. Ik ga de programmeurs een pauze gunnen, omdat ik het niet leuk vind om programmeurs onder de bus te gooien. Maar het probleem is echt de academische omgeving, want als je gaat leren programmeur te worden, leer je record-per-keer denken. U leert niet het setdenken, en dat is wat Structured Query Language of SQL met sets werkt; daarom hebben we de unie, de kruising en de min-operator. En het is soms heel moeilijk voor een persoon die nooit aan sets heeft gedacht, om te stoppen met het verwerken van records per keer en het werken met sets.

Robin Bloor: Ja, daar ben ik bij. Ik bedoel, ik begrijp het nu, dat is een kwestie van onderwijs; Ik denk dat dit een volledig educatief probleem is, ik denk dat het voor programmeurs vanzelfsprekend is om procedureel te denken. En SQL is niet procedureel, maar declaratief. Je zegt eigenlijk alleen maar: "Dit is wat ik wil en het kan me niet schelen hoe je het doet", weet je? Terwijl je met programmeertalen je mouwen vaak hebt opgestroopt en je bent zelfs in de details van het beheren van de tellingen, terwijl je een lus uitvoert. Zieke hand op -

Bert Scalzo: Nee. OK, doorgaan.

Ja, ik wou zeggen dat je nog een ander voorbeeld ter sprake bracht dat een profiler goed zou zijn om dit soort gegevens te verwerken. Soms kan een programmeur die goed is in een record-voor-een-logica niet weten hoe hij een SQL-programma moet uitvoeren. Laten we zeggen dat hij twee FOR-lussen maakt en in feite een join uitvoert, maar hij doet het aan de clientzijde. Dus, hij doet hetzelfde effect als een join, maar hij doet het zelf, en een profiel zou dat vangen, omdat je waarschijnlijk meer tijd zou moeten besteden aan het handmatig doen van de join dan de databaseserver het voor je zou laten doen.

Robin Bloor: Ja, dat zou een ramp zijn. Ik bedoel, je zou gewoon rondslingeren. Thrashings altijd slecht.

Hoe dan ook, ik ga door naar Dez; Ik weet zeker dat hij een aantal interessante vragen heeft.

Dez Blanchfield: Bedankt, ja. Ik ga met je mee in de niet-gooiende programmeurs onder de bus. Ik bedoel, ik heb zelf te veel jaren in mijn leven doorgebracht als coder, op elk niveau, weet je, of het zoals je zei, zittend op de commandoregel van de Unix-machine, en in sommige gevallen was ik zelfs betrokken bij een paar verschillende Unix-poorten van het ene hardwareplatform naar het andere. En u kunt zich de uitdagingen voorstellen die we daar hadden. Maar de realiteit is dat deze kaart uit de gevangenis komt voor elke coder en scripter ter wereld. Het is een raketwetenschap, heel letterlijk, elke keer heel strak te schrijven is altijd een raketwetenschap. En beroemde verhalen van mensen zoals Dennis Ritchie en Brian Kernahan die zelfstandig aan een stukje code werken en vervolgens naar een code review chat gaan bij een kopje koffie en ontdekken dat ze precies hetzelfde stukje code hebben geschreven, in exact hetzelfde programma, in exact dezelfde manier. En ze deden het in C. Maar dat puristische niveau van programmeren bestaat zeer zelden.

Het is een feit dat er dagelijks slechts 24 uur per dag, zeven dagen per week is, en dat we gewoon dingen moeten doen. En dus, als het gaat om niet alleen traditionele programmeurs, de DBA's en coders en scripters en sysadmin, en netwerkbeheerders en beveiligingspersoneel, en tegenwoordig alles tot aan de gegevenskant van de burger; horen we, iedereen probeert gewoon zijn werk te doen. En dus denk ik dat de geweldige afhaalmaaltijden van dit hele ding is dat ik van je demo hield en ik hield van de afhaalmaaltijden die je ons hier zojuist achterliet en met Robin sprak over het feit dat dit een bepaalde - misschien niet zo veel heeft een niche - maar een brede ruimte waarop het van toepassing is, voor zover het gaat om het repareren van code en SQL en databases. Maar ik was echt heel blij om je te horen zeggen dat je het in een shellscript kon porren en enkele problemen kon vinden, omdat je weet dat vandaag de dag altijd oud was aan de laagste kosten voor alles.

De reden dat je ergens een $ 6-shirt kunt kopen, is omdat iemand goedkoop genoeg een systeem heeft gebouwd om daadwerkelijk te produceren en te verzenden en logistiek te leveren en verkopen en verkopen en online betalingen te doen om dat $ 6-shirt te krijgen. En dat gebeurt niet als u mensen $ 400.000 per jaar krijgt om code op de perfecte manier te schrijven; het is gewoon hele ontwikkeling. Dus, dat punt, ik denk dat een van de vragen waar Id echt van houdt om ons gewoon wat meer inzicht te geven, is wat de breedte en het bereik is van het type mensen dat je momenteel ziet en dit soort tools inzet om een ​​code te profileren en te kijken voor prestatieproblemen? Aanvankelijk, historisch gezien, waar komen ze vandaan? Zijn zij de grote engineeringhuizen geweest? En dan, in de toekomst, is dat het geval, heb ik gelijk als ik denk dat steeds meer bedrijven deze tool, of deze tools, implementeren om te proberen coders te helpen, die ze weten die net dingen voor elkaar krijgen om de klus te klaren en het de deur uit krijgen? En hebben we soms een get-out-of-jail-kaart nodig? Heb ik gelijk als ik denk dat we historisch gezien een meer technische focus en ontwikkeling hadden? Dat nu, zoals Robin zei, een minder academische benadering kreeg, en nu zijn autodidactische, of knip-en-plak code, of gewoon dingen laat bouwen? En komt dat overeen met het soort mensen dat het product nu aanneemt?

Bert Scalzo: Ja precies. En ik zal u een heel specifiek voorbeeld geven, we willen gewoon de klus klaren, want de zakenmensen willen geen perfectie. Het lijkt een beetje op een geautomatiseerd schaakspel: het schaakspel zoekt niet naar het perfecte antwoord; het zoekt naar een antwoord dat binnen een redelijke tijd goed genoeg is, dus dat is hoe we programmeren. Maar wat ik nu vind, is dat de meeste mensen in plaats van te zeggen dat ze een profiler willen als onderdeel van hun unit-testen - en dat is hoe ik het zou doen, want ik zie het niet als een verspilling van tijd - wat er gebeurt is nu dat wordt gedaan later, soms, tijdens integratietests of stresstests, als we geluk hadden. Maar meestal maakt het deel uit van een escalatie, waar iets in productie ging, het liep een tijdje, misschien zelfs jaren, en nu loopt het niet goed, en nu goed profileren. En dat lijkt nu het meest voorkomende scenario te zijn.

Dez Blanchfield: Ja, en ik denk dat de term 'technische schuld' er waarschijnlijk meer is dan u gewend bent; Ik ken Robin en dat ben ik zeker. Ik denk dat het concept van technische schuld tegenwoordig voor mij, met name in agile benaderingen van ontwikkeling en systeemopbouw, heel reëel is, en we houden er eigenlijk rekening mee in projecten. Ik weet het, ik bedoel, we hebben onze eigen projecten zoals de Media Lens en anderen, waar we dagelijks codering hebben gekregen, en verschillende dingen binnen de Bloor Group. En wanneer we iets aan het bouwen waren, kijken we er naar, ik kijk ernaar, en kijk altijd vanuit het oogpunt van wat het me gaat kosten om dit nu op te lossen, versus kan ik het gewoon in het blik krijgen en haal het daar en kijk en kijk of dit soort dingen zullen breken. En erven deze technische schuld waarvan ik weet dat ik ze later moet omcirkelen en repareren.

En ik bedoel, ik heb dat gedaan in de afgelopen zeven dagen: ik heb een paar tools en scripts geschreven, ik heb een paar stukken Python-taal geschreven, en ik heb het in Mongo-back-end geïmplementeerd, ervoor zorgend dat het mooi en schoon en veilig is, maar het krijgt gewoon de vraag die ik nodig heb, wetende dat ik die functie nodig heb om te werken, om de grotere puzzel te krijgen; dat is waar mijn echte pijn is. En dus sta je met deze technische schuld, en ik denk dat dit nu niet alleen af ​​en toe iets is, ik denk dat dit deel uitmaakt van het DNA van het ontwikkelen van nu. Mensen accepteren gewoon - niet zomaar - dat technische schuld een normaal type operandi-kwestie is, en ze moeten het gewoon oplopen. Het is waar u de technische schuld oploopt. En ik denk dat het mooie van wat je ons in de demo hebt laten zien, was dat je letterlijk kunt profileren en kijken hoe lang het duurt voordat iets wordt uitgevoerd. En dat is waarschijnlijk een van mijn favoriete dingen. Ik bedoel, ik heb eigenlijk profileringshulpmiddelen gebouwd - we bouwden altijd hulpmiddelen in Sed en Lex en Orc om onze code uit te voeren en te zien waar de lussen waren, voordat dergelijke hulpmiddelen beschikbaar waren - en wanneer je code hebt gebouwd om je eigen code te bekijken , word je er erg goed in dat je je eigen code niet hoeft te herzien. Maar dat is nu niet het geval. Is er met dat in gedachten een bepaald marktsegment dat dit meer oppakt dan enig ander? Zien als een massa—

Bert Scalzo: Oh ja, ik heb ... Ik ga een analogie voor je tekenen en je laten zien dat niet-programmeurs het altijd doen. Want als ik ooit een debugger en een profileercursus of -les leer, vraag ik mensen: "OK, hoeveel mensen hier gaan naar Microsoft Word en gebruiken nooit doelbewust de spellingcontrole?" En niemand steekt zijn hand op, want voor het schrijven van documenten, we weten allemaal dat we Engelse fouten kunnen maken, en daarom gebruikt iedereen de spellingcontrole. En ik zei: "Wel, hoe komt het dat wanneer u in uw IDE schrijft zoals Visual Basic, u de debugger niet gebruikt? Het is hetzelfde, het is als een spellingcontrole. '

Dez Blanchfield: Ja, eigenlijk is dat een goede analogie. Ik had er niet echt over nagedacht, ik moet toegeven dat ik eigenlijk iets soortgelijks doe met een paar tools die ik gebruik. Eén, ODF, mijn favoriet bij Eclipse, is gewoon code knippen en plakken daar en op zoek gaan naar dingen die gewoon meteen opvallen en beseffen dat ik een typefout heb gemaakt in een klasgesprek. En, maar het is nu interessant met dit hulpmiddel dat je het in realtime kunt doen, in tegenstelling tot later terug te komen en het later te bekijken, wat best leuk is om het van tevoren te vangen. Maar ja, dat is een goede analogie van het gewoon in een tekstverwerker stoppen, omdat het een interessante wake-up call is, realiseer je je gewoon dat je een typefout of zelfs een grammaticafout hebt gemaakt, toch?

Bert Scalzo: Precies.

Dez Blanchfield: Dus, zie je nu meer een verbetering van, denk ik, ik bedoel, de laatste vraag van mij, voordat ik misschien naar onze Q&A ga, voor onze aanwezigen. Als je een soort aanbeveling zou geven over de aanpak om dit te doen - ik ga ervan uit dat dit retorisch is - is het dan zo dat je vroeg begint en dit geïmplementeerd krijgt terwijl je je ontwikkelt, voordat je je ontwikkelt? Of is het het geval dat je voornamelijk bouwt, gaat bewegen, iets bouwt, dan binnenkomt en het later profileert? Ik vermoed dat het het geval is om vroeg in te stappen en ervoor te zorgen dat je codes van tevoren schoon zijn. Of moeten ze dit deel van hun post-deployment overwegen?

Bert Scalzo: In het ideale geval zouden ze het van tevoren doen, maar omdat iedereen zich in de drukte bevindt waar ze net dingen voor elkaar krijgen, doen ze het meestal niet totdat ze een prestatieprobleem tegenkomen dat ze niet kunnen oplossen door meer CPU's en geheugen toe te voegen naar een virtuele machine.

Dez Blanchfield: Ja. Dus, eigenlijk heb je iets interessants genoemd, als ik snel kan? U zei eerder dat dit overal kan worden uitgevoerd en aan de achterkant met de database kan praten. Dus dit is comfortabel met het soort bimodaal concept waar we het nu over hebben, van on-premise / off-premise cloud, door het uiterlijk van dingen ook, aan het einde van de dag, als het kan praten met de back-end en ziet de code, het maakt niet echt uit, of wel?

Bert Scalzo: Precies, ja, je kunt dit in de cloud uitvoeren.

Dez Blanchfield: Uitstekend, want ik denk dat dat is waar onze nieuwe dappere wereld naartoe gaat. Dus Eric. Ik ga nu naar je teruggooien en zien dat we hier een paar vragen hebben en ik wil dat onze aanwezigen nog steeds bij ons blijven, ook al zijn we het uur voorbij.

Eric Kavanagh: Ja, er zijn een paar mensen daar, ik zal even een kort commentaar geven: Bert, ik denk dat die metafoor, de analogie die je geeft met het gebruik van de spellingcontrole, eerlijk gezegd briljant is. Dat is een blog of twee, eerlijk gezegd, waardig, omdat het een goede manier is om de con in te schrijven van wat je doet, en hoe waardevol het is, en hoe het echt een best practice zou moeten zijn om een ​​debugger op een normale basis, toch? Ik wed dat je hoofden krijgt die knikken als je die weggooit, toch?

Bert Scalzo: Absoluut, want wat ik ze vertel is: “Waarom voer ik een spellingcontrole uit op mijn documenten? Ik wil me niet schamen voor domme spelfouten. ”Nou, ze willen zich niet schamen voor domme codeerfouten!

Eric Kavanagh: Rechtsaf. Ja inderdaad. Welnu, mensen, we hebben hier een uur en vijf minuten gebrand, heel erg bedankt voor jullie tijd en aandacht. We archiveren al deze webchats, kom gerust terug en bekijk ze. De beste plaats om die links te vinden is waarschijnlijk techopedia.com, dus voeg dit hier direct aan deze lijst toe.

En daarmee zouden we je vaarwel zeggen, mensen. Nogmaals geweldig werk, Bert, dankzij onze vrienden van IDERA. Ik spreek je de volgende keer goed, ik spreek je volgende week eigenlijk. Wees voorzichtig! Tot ziens.