Door Techopedia Staff, 15 maart 2017
Takeaway: Host Eric Kavanagh besprak database debugging en profilering met Dr. Robin Bloor, Dez Blanchfield en IDERA's 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 u zeker wilt zijn dat dit op de achtergrond in uw bedrijf gebeurt, tenzij u de persoon bent die het doet, in welk geval u ervoor wilt zorgen dat u het goed doet. Omdat we het hebben 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 we gaan het hebben over "Snelle respons: database debuggen en profileren voor de redding".
Er is echt een plekje in de jouwe, sla me op Twitter, @eric_kavanagh natuurlijk.
Dit jaar is heet. En foutopsporing wordt hot, wat er ook gebeurt. Het wordt echt een van deze problemen die nooit zal verdwijnen, ongeacht hoe goed we hierin 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?
We horen het 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 komen op iemands toplijst, 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 realiseerde zich dat ze dat gingen doen en er bugs in plaatsten, 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 rondging - 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. Het Maps-programma van Apple 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 het 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 zou hebben over de impedantie-mismatch en de uitgegeven SQL. Het is interessant dat relationele databases gegevens opslaan in tabellen en coders de neiging hebben gegevens te manipuleren in objectstructuren die echt niet zo goed in tabellen passen. En daarom krijg je wat de impedantiemismatch 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 slechte API-mogelijkheden 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 trapsgewijze verwijderingen en dat soort dingen, de database zorgde voor het plotselinge plaatsen van functionaliteit in een database, 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 een kant van het database-spel, omdat het betekent dat je bijvoorbeeld veel implementaties hebt gedaan, dat ik betrokken ben geweest bij relationele databases, er is echt heel veel code die in opgeslagen procedures zit die wordt afgehandeld los van code die in de applicaties zit. 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 ik het ook zou hebben over databaseprestaties 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 je kunt 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 moet zo 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 een interessant ding, 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 dat het net als alle situaties in debuggen dat ik ooit ervaren is, is het eerste wat je ooit ziet is een puinhoop. En je moet proberen om van de puinhoop te gaan om erachter te komen hoe de puinhoop is ontstaan. En vaak als 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 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 meest gelijk: dit is een onderwerp, een levenslange kever als u de woordspeling gratie wilt verlenen, sorry dat ik mezelf daar niets aan kon doen. 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 aandacht richten op twee belangrijke gebieden, in het bijzonder het concept van wat wij 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 is het 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 een zogenaamd softwareprobleem.
Dus, de stedelijke mythe is dat rond 9 september 1945 een team van Harvard University een machine uit elkaar trok, ze iets tegenkwamen dat ze "estafette zeventig" noemden - in die dagen werd programmeren in fysieke zin gedaan, je verwondde code rond een bord, en dat was hoe je de machine effectief programmeerde - en ze vonden dit relais nummer zeventig er was iets mis mee, en het blijkt dat de eigenlijke term "bug" tot stand kwam omdat het letterlijk een mot was - vermoedelijk daar was een mot ingeklemd tussen een stuk koperdraad dat van de ene plaats naar de andere ging. En het verhaal gaat dat de legendarische Grace Hopper als dit bijschrift, voor mijn titeldia, "eerste echte 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 rekenen, concepten als een patch. De term 'patch' kwam van een stuk tape 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 ik een paar grappige dia's erin zou stoppen voordat ik wat meer in detail ging. Hier is de klassieke cartoon, XKCD genoemd op internet, en de cartoonist heeft een aantal vrij grappige kijk op de wereld. En deze gaat over een kind genaamd 'Little Bobby Tables' en vermoedelijk noemden zijn ouders deze jongen Robert '); DROP TAFEL Studenten; - en het heet, 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 het studentenrecord van het jaar kwijt zijn, 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 naar de gegevens kijkt ook.
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 vergelijkbare verklaring die ervoor zorgt dat databases in snelheidscamera's vallen 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, weet ik zeker; Robin, je bent van harte welkom om me hier voor de gek te houden - maar historisch gezien kom ik op een leeftijd van 14 jaar door het einde van de stad en klop ik op de deur van een datacenter genaamd "Data Com" in New Zeeland en vragen of ik zakgeld kon verdienen op school door de late bus naar huis te nemen, elke dag zo'n 25 km woon-werkverkeer, papier in printers en tapes in tapedrives, en gewoon een algemeen beheerder te zijn. 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 in feite op een teletype-terminal, die eigenlijk een fysieke printer met 132 kolommen was. Denk in wezen aan een heel oude typemachine met papier dat erdoorheen rolde, 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 af te drukken en vervolgens weer in te typen. Maar eens, dat was de manier waarop we code schreven en dat is hoe we fouten opspoorden, en we zijn er heel, heel goed in geworden. 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 we zijn er 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 je deed het op de papieren band soort afgedrukt formaat alleen op een CRT, maar je kon gemakkelijker 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 bad practices. 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 ik, vanuit mijn achtergrond, op veel manieren autodidact was en degenen die me hebben geholpen bij het leren, hebben me heel goede programmeermethoden en zeer goede methoden rond ontwerp en processen geleerd om ervoor te zorgen dat ik niet introduceer buggy 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 als slechte programmeertechnieken, luie inspanningen om code te schrijven, gebrek aan ervaring, de klassieke huisdieren 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. Tegenwoordig haasten we ons allemaal hier naartoe, wat we de race naar nul noemen: proberen alles zo goedkoop en zo snel te doen, dat we een scenario hebben waarin we niet lager werken - betaald personeel. En dat bedoel ik niet op een oneerlijke manier, maar we huren 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 strikte opleiding hadden gevolgd die hen ervan weerhield gekke dingen te doen.
Tegenwoordig komen er veel mensen in ontwikkeling en ontwerp en database die geen jarenlange ervaring hebben gehad, niet noodzakelijk dezelfde training of ondersteuning hebben gehad. En zo eindig je met een scenario van alleen de traditionele amateur versus expert. En er is een beroemde regel, ik kan me niet echt 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 jij moeten opruimen. ”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 je ook bent en dat alles 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 te doen de gegevensmanipulatie, 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 geselecteerde ster van overal maakt.
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, waarvan ik zeker weet dat we er allemaal bekend mee zijn. 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 opgeslagen procedures, we hebben programmeermethodieken toegepast op een taal en dus is het heel gemakkelijk voor slechte programmeerpraktijken, gebrek aan ervaring, knip-en-plak code, laagbetaalde medewerkers proberen hoogbetaalde medewerkers te 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 denkt, dat is gewoon, het is een beetje schattig en je denkt: "Wauw, wat een geweldige afbeelding, ik zou dat graag willen uitvoeren." Maar stel je voor dat dat op een stukje bedrijfslogica draait . 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 hoort een zwarte achtergrond en groene tekst te zijn 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 die 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 als je elke dag, of elk uur of elke minuut een systeem raakt, eindig je al 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 goed op te bouwen, eerlijk gezegd, dat is gewoon vies." En de URL is 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 u over de tools beschikt om de database te bekijken, probeer het dan binnen een periode van drie tot vijf minuten te laten smelten om terug te bellen wat een regel tekst 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 al zei vroeger, ooit, kon je het doen door naar een groen scherm te kijken. Je kunt niet meer; er zijn honderdduizenden coderegels, er worden tienduizenden apps geïmplementeerd, er zijn in sommige gevallen miljoenen databases en zelfs supermensen kunnen dit niet meer handmatig 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 met name 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 als je naar database debugging gaat, is het een orde van grootte nog zwaarder en niet-triviaal - dus dat was een belangrijk citaat.
OK. Ik wilde beginnen met de programmageschiedenis, 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 mij, "Nou, 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 vriendelijk van zeg waar waren we in termen 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 begonnen zijn met programmeren, weet je, in de jaren 1950, want dat is de enige manier om met die claim weg te komen.
Het andere leuke aan deze kaart is dat Dez zojuist een opmerking maakte over Grace Hopper, ik kende Grace eigenlijk, dus het is best grappig. En het andere waar ik om lachte, was dat hij over teletypes sprak en ik zat daar te gaan: "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. "Dus, en ik heb hier in alle talen geprogrammeerd, inclusief SNOBOL, waar nog nooit iemand van gehoord heeft, 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 ouder 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 maakt 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 we hebben ook de beroemde print-statement: je kijkt en mensen zetten eigenlijk print-statements 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 drukt op een knop en het zal printinstructies in je code voor je plakken en wanneer je klaar bent, druk je op een andere knop en het verwijdert ze. Omdat zo 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 een profiler waarschijnlijk beter is voor dat tweede scenario en we gaan het hebben over zowel debuggers als profilers. Bovendien is er dit concept van foutopsporing op afstand; dit is belangrijk omdat je vaak op je pc zit en een debugger gebruikt die een database raakt waar de code daadwerkelijk op de database wordt uitgevoerd, eigenlijk doe je wat op afstand debuggen 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, uitkijkpunten, stap in en stap over en enkele andere veel voorkomende dingen, die ik ga laten zien op een momentopname op het scherm.
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 meer dat het beter is als het klaar is met bemonsteren. Er is geen reden om elke afzonderlijke verklaring te vangen, omdat sommige verklaringen zo snel kunnen lopen dat het je niets kan schelen, wat je echt probeert te zien is, nou ja, die zijn die steeds weer verschijnen, omdat ze lopen te lang. 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 ding van efficiëntie. Over het algemeen is het gescheiden en verschillend van de debugger, hoewel ik heb gewerkt met debuggers 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 hier in het vierkante gat gedwongen en gedwongen om een programmeertaal te worden - en Oracle. Dat is PL / SQL - dat is procedurele taal SQL - en SQL Server, het is Transact-SQL, het is SQL-99, het is SQL / PSM - voor, denk ik, het is 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 dat doe T-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 beetje als een 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 debug-methode.
En de reden dat ik dit ter sprake breng, is dat als je dit handmatig probeert te doen, je eigenlijk meer foutopsporingscode typt om al deze gedrukte verklaringen in te voeren 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 10 uur heeft geduurd voordat dit ding wordt uitgevoerd en waar het een probleem heeft in regel drie? Als ik een interactieve debug-sessie zou doen, zou ik het op regel drie - vijf minuten weten - hey, er is hier een probleem, ik kan stoppen. Maar hiermee moet ik wachten tot het helemaal is voltooid en dan moet ik naar een traceringsbestand kijken dat waarschijnlijk al deze afdrukafschriften bevat, en probeer de naald in de hooiberg. Nogmaals, dit is beter dan niets, maar het zou niet de beste manier van werken zijn. 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 gewoon een heleboel gedrukte 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, je had debuggers en je gebruikte ze met je andere talen - dacht er gewoon niet aan om ze hier met je database te 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 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, ik heb mijn broncode in het midden, ik heb wat mijn watch-variabelen en mijn call-stack-trays worden genoemd, en dan onderaan ik ' heb enkele uitvoerberichten. En wat hier belangrijk is, is dat als je over die eerste rode pijl kijkt, als ik over een variabele beweeg, 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, daar is mijn cursor op dit moment - dus met andere woorden, ik ben gestapt en dat is waar ik ben het moment. 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 het zal lopen van hier tot 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 mijn oproepstapeltracering zien, weet je, en dus wordt al die informatie daar weergegeven terwijl ik door de code stap, zodat ik daadwerkelijk kan zien en voelen en inzicht kan krijgen in wat er aan de hand is en hoe de code eigenlijk is werken tijdens 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 dat er een marge is aan de linkerkant, naast de regelnummers. En wat dat is, is dat het aantal seconden of microseconden was dat nodig was om elke regel code uit te voeren, en ik zie dat duidelijk, al mijn tijd wordt doorgebracht in deze FOR-lus waar ik alles uit een tabel selecteer . En dus is alles wat er binnen die FOR-lus gebeurt waarschijnlijk iets waar ik naar moet kijken, en als ik het beter kan maken, zal het dividenden betalen. Ik ga geen verbeteringen krijgen door te werken aan lijnen die ongeveer 0.90 of 0.86 hebben; er wordt 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 als het grootste deel van het cirkeldiagram en als ik kijk, zie ik op dat rooster onderaan, lijn 23, is er weer de FOR-lus: hij neemt de meeste tijd op, hij is eigenlijk dat donkerrood het hele cirkeldiagram aan het kauwen is. 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 u het doet - u hebt de onderneming beloofd dat u iets correct zou doen, dat uw programma effectief zal zijn. Daar zul je de debugger voor gebruiken. Daarnaast zakelijke eindgebruikers; ze zijn niet erg geduldig: ze willen al resultaten voordat ze op de toets drukken. We worden 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 met de pijl en boog bent en 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 code review kan sommige van deze dingen wel of niet opdagen, maar er is geen garantie dat een code review 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 gezien." En het ziet er mooi uit in de schermdia's, maar hoe 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 u 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, die staat 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 gewoon bewegen, en als ik erop blijf drukken, zie je hem blijven bewegen. Als ik nu helemaal naar deze FOR-lus wilde gaan, omdat ik weet dat dit 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, dus ik ben nu in de context van 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 tot 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 huurcontracten doen en ik kan over die man heen gaan en kijken, hij is 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 had uitgevoerd in een debugger.
En daarmee ga ik de demo opschorten en teruggaan, omdat we er zeker van willen zijn 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 dit soort dingen 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 werk en dat ik binnen mijn Visual Basic 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, hoewel de code zeer efficiënt kan zijn, zou je kunnen kijken en zeggen: "Ooh, we doen deze oproep aan dit stuk code veel te vaak. 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 nog 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 zou de code opsplitsen tussen een database en een programma. Maar dus, doe alles - ik neem aan dat het antwoord ja zal zijn, maar dit maakt deel uit van een activiteit van een ontwikkelteam, wanneer je op een of andere manier iets probeert te repareren dat kapot is, of misschien een nieuw probeert te brengen toepassing samen. 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 deel uitmaken 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 geen 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 deelname hadden in een van hun selecte verklaringen en wisten het niet.
Robin Bloor: Wauw.
Bert Scalzo: Maar op een keer zei iemand tegen mij: "Wel, hoe kunnen ze een Cartesiaanse deelnemer krijgen 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: Wow, ik weet het, zo heet het - nou, dat was het 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 dat niveau van domheid. Ik neem ook aan dat je, op de een of andere manier, gewoon taal-agnostisch bent wat dit betreft, omdat dit allemaal gericht is op de database. Heb ik daar gelijk in? Is het precies hetzelfde, wat u ook aan de codeerzijde gebruikt?
Bert Scalzo: Absoluut, je 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, want ik hou er niet van programmeurs onder de bus te gooien. Maar het probleem is echt de academische omgeving, want als je gaat leren hoe je een programmeur moet worden, wordt je geleerd om record voor een te 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 het mee eens. Ik bedoel, ik begrijp het nu, dat is een kwestie van educatie; Ik denk dat dit een volledig educatieve kwestie is, ik denk dat het voor programmeurs vanzelfsprekend is om procedureel te denken. En SQL is niet procedureel, het is 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 bij programmeertalen je mouwen vaak oprolt en je tot in de puntjes bezig bent om zelfs de tellingen te beheren, terwijl je een lus uitvoert. Ik zal doorgeven aan -
Bert Scalzo: Nee. Oké, doorgaan.
Ja, ik wou zeggen dat je nog een ander voorbeeld ter sprake bracht dat een profiler goed zou zijn in het vangen van, soort gaat door met deze record-at-a-time verwerking. 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 dat de databaseserver het voor je zou doen.
Robin Bloor: Ja, dat zou een ramp zijn. Ik bedoel, je zou gewoon rondslingeren. Thrashing is altijd slecht.
Hoe dan ook, ik zal doorgeven aan Dez; Ik weet zeker dat hij enkele interessante vragen heeft.
Dez Blanchfield: Bedankt, ja, dat doe ik. 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 in 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 hier dat je uit de gevangenis-kaart 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 precies hetzelfde programma, op precies dezelfde manier. En ze deden het in C. Maar dat puristische niveau van programmeren bestaat zeer zelden.
Het is een feit dat er dagelijks 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; we horen, 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 steken en een aantal problemen kon vinden, omdat je weet dat we vandaag de dag altijd aan de laagste kosten werken 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 mensen $ 400.000 per jaar krijgen om op de perfecte manier code te schrijven; het is gewoon hele ontwikkeling. Dus op dat punt denk ik dat een van de vragen die ik heel graag zou willen om ons gewoon wat meer inzicht te geven, is wat de breedte en het bereik is van het soort mensen dat je momenteel ziet en dat dit soort hulpmiddelen inzet om te profileren een code en op zoek naar 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 we nu een minder academische benadering krijgen, zoals Robin zei, en nu is het autodidact, of knip-en-plak code, of gewoon dingen laten 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, omdat de zakenmensen geen perfectie willen. 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 zie, 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, omdat ik het niet als een verspilling van tijd zie - wat er gebeurt is nu dat later wordt gedaan, soms, tijdens integratietests of stresstests, als we geluk hebben. Maar meestal maakt het deel uit van een escalatie, waar iets in productie is gegaan, het heeft een tijdje geduurd, misschien zelfs jaren, en nu loopt het niet goed, en nu zullen we het 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 je kent; 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 en verschillende dingen in de Bloor Group. En wanneer we iets bouwen, 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 krijgen in de kan en haal het daar, en kijk dan of dit ding gaat breken. En erven deze technische schuld waarvan ik weet dat ik ze later terug moet omcirkelen en oplossen.
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 geïmplementeerd in Mongo back-end, waardoor zeker dat het mooi en schoon en veilig is, maar het krijgt alleen de vraag die ik moet doen, 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 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 te gaan en bekijk je eigen code, je wordt 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. Omdat als ik ooit een debugger en een profileercursus of -les geef, ik mensen zal vragen: "OK, hoeveel mensen hier gaan naar Microsoft Word en gebruiken doelbewust nooit de spellingcontrole?" En niemand steekt zijn hand op, omdat we voor het schrijven van documenten allemaal weten dat we Engelse fouten kunnen maken, en daarom gebruikt iedereen de spellingcontrole. En ik zei: "Wel, hoe komt het dat wanneer u tekst 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 plaats van terug te komen en het later te bekijken, wat best leuk is om het van te voren te vangen. Maar ja, dat is een goede analogie van het gewoon in een tekstverwerker plaatsen van tekst, 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, je ziet nu meer een opleving 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 neem aan dat dit retorisch is - is het dan zo dat je vroeg begint en dit geïmplementeerd krijgt terwijl je ontwikkelt, voordat je je ontwikkelt? Of is het het geval dat je voornamelijk bouwt, beweegt, iets bouwt, dan binnenkomt en het later profileert? Ik vermoed dat dit het geval is om vroeg in te stappen en ervoor te zorgen dat je code van tevoren schoon is. 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 in de drukte is waar ze dingen moeten doen, doen ze het meestal pas als ze een prestatieprobleem tegenkomen dat ze niet kunnen oplossen door meer CPU's en geheugen toevoegen aan 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, omdat 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, ik zal even een korte opmerking maken: Bert, ik denk dat die metafoor, de analogie die je geeft met het gebruik van de spellingcontrole, eerlijk gezegd briljant is. Dat is eerlijk gezegd een blog of twee waardig, omdat het een goede manier is om de context te kaderen van wat je doet, en hoe waardevol het is, en hoe het echt een best practice zou moeten zijn om een debugger te gebruiken op een regelmatige 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. ”Wel, ze willen zich niet schamen voor domme codeerfouten!
Eric Kavanagh: Juist. 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 we zullen dit hier aan deze lijst toevoegen.
En daarmee gaan we u vaarwel zeggen, mensen. Nogmaals geweldig werk, Bert, dankzij onze vrienden van IDERA. We spreken je de volgende keer, we spreken je volgende week zelfs. Wees voorzichtig! Tot ziens.
