Von Techopedia Staff, 15. März 2017
Imbiss: Gastgeber Eric Kavanagh diskutierte mit Dr. Robin Bloor, Dez Blanchfield und Bert Scalzo von IDERA über das Debuggen und Profilieren von Datenbanken.
Du bist derzeit nicht angemeldet. Bitte melde dich an oder registriere dich, um das Video zu sehen.
Eric Kavanagh: Okay, meine Damen und Herren, es ist 4:00 Eastern Time an einem Mittwoch, und das heißt natürlich.
Robin Bloor: Kann dich nicht hören, Eric.
Eric Kavanagh: Ich war vor Tagen dort, also bist du nicht allein. Aber so ist das Thema heute wirklich interessantes Zeug. Dies ist die Art von Dingen, die Sie sicherstellen möchten, dass sie in Ihrem Unternehmen im Hintergrund stattfinden, es sei denn, Sie sind die Person, die dies tut. In diesem Fall möchten Sie sicherstellen, dass Sie es richtig machen. Weil wir über das Debuggen sprechen. Niemand mag Fehler, niemand mag es, wenn die Software nicht mehr funktioniert - die Leute sind aufgebracht, die Benutzer unfreundlich. Das ist nicht gut. Wir werden also über "Rapid Response: Datenbank-Debugging und Profilerstellung zur Rettung" sprechen.
Es gibt einen Spot über deinen, der mich auf Twitter anspricht, natürlich @eric_kavanagh.
Dieses Jahr ist heiß. Und das Debuggen wird heiß, egal was passiert. Es wird wirklich eines dieser Probleme sein, das niemals verschwinden wird, egal wie gut wir mit diesen Dingen umgehen, es wird immer Probleme geben. Der Schlüssel ist also, wie kommt man dahin, wo man diese Probleme schnell lösen kann? Idealerweise haben Sie großartige Programmierer, großartige Umgebungen, in denen nicht zu viel schief geht, aber wie das alte Sprichwort sagt: „Unfälle passieren in den besten Familien.“ Das gilt auch für Unternehmen. Also, dieses Zeug passiert, es wird passieren, die Frage ist, was wird Ihre Lösung sein, um damit umzugehen und diese Probleme zu lösen?
Wir hören von Dr. Robin Bloor, dann von unserem eigenen Dez Blanchfield aus Down Under und natürlich von unserem guten Freund Bert Scalzo von IDERA. Tatsächlich werde ich Robin Bloor die Schlüssel geben und sie wegnehmen. Der Boden gehört dir.
Robin Bloor: Okay. Das ist ein interessantes Thema. Ich dachte, da Dez wahrscheinlich über die tatsächlichen Techniken und Kriegsgeschichten zum Debuggen sprechen wird, dachte ich, ich würde nur eine Hintergrunddiskussion führen, damit wir ein umfassendes Bild davon bekommen, was vor sich geht. Ich habe das lange gemacht, und ich war früher ein Programmierer, und ich war fast versucht, mich über die Idee von Open Source lustig zu machen, aber ich dachte, ich überlasse das jemand anderem.
Hier ist eine Liste berühmter Bugs, und die meisten davon landen auf der Top-Liste aller, mit Ausnahme der letzten beiden, kosten mindestens 100 Millionen US-Dollar. Der erste war der Mars Climate Orbiter, der sich im Weltraum verirrt hat und aufgrund eines Codierungsproblems, bei dem metrische Einheiten mit (lachenden) Fuß und Zoll verwechselt wurden. Beim Ariane Five Flight 501 gab es ein Missverhältnis zwischen einem Motor, der eingeschaltet war, und den Computern, auf denen die Rakete beim Start laufen sollte. Mehrere Computerausfälle, explodierende Raketen, Schlagzeilen. Die sowjetische Erdgasleitung von 1982 soll die größte Explosion in der Geschichte des Planeten gewesen sein. Ich bin mir nicht sicher, ob es so ist. Die Russen stahlen eine automatisierte Steuerungssoftware, und die CIA erkannte, dass sie das tun würden, und legte Fehler darin an, und die Sowjets implementierten es, ohne es zu testen. Also, eine Pipeline in die Luft gesprengt, fand das amüsant.
Der Morris-Wurm war ein Codierungsexperiment, das sich plötzlich in einen räuberischen Wurm verwandelte, der offenbar Schaden in Höhe von 100 Millionen Dollar anrichtete. das ist natürlich eine Schätzung. Intel machte einen berühmten Fehler mit einem Mathematik-Chip - eine Mathematik-Anweisung auf dem Pentium-Chip von 1993 - der über 100 Millionen Dollar gekostet haben sollte. Apples Maps-Programm ist möglicherweise der schlimmste und katastrophalste Start von allem, was Apple jemals gemacht hat. Die Leute, die es ausprobiert haben, waren, ich meine, jemand fuhr 101 entlang und stellten fest, dass sich die Apple Map mitten in der Bucht von San Francisco befand. Daher wurde die Apple Maps App als iLost bezeichnet. Das - unser längster Ausfall im Jahr 1990 - ist unter dem Gesichtspunkt der Kosten für so etwas einfach interessant. AT & T war ungefähr neun Stunden lang außer Betrieb und kostete bei Ferngesprächen etwa 60 Millionen US-Dollar.
Ich war bei einer britischen Versicherungsgesellschaft und die Datenbank implementierte eine neue Version der Datenbank und begann, Daten zu löschen. Und daran kann ich mich noch sehr gut erinnern, denn ich wurde später gerufen, um an einer Art Datenbankauswahl teilzunehmen. Und es war sehr interessant, dass sie eine neue Version der Datenbank aufgenommen hatten und eine Reihe von Tests hatten, die sie für neue Versionen der Datenbank durchgeführt hatten, die alle Tests bestanden hatten. Es hat einen wirklich undurchsichtigen Weg gefunden, Daten zu löschen.
So ist es jedenfalls. Ich dachte, ich würde über die Impedanzinkongruenz und die ausgegebene SQL sprechen. Es ist interessant, dass relationale Datenbanken Daten in Tabellen speichern und Codierer dazu neigen, Daten in Objektstrukturen zu manipulieren, die Tabellen wirklich nicht sehr gut zugeordnet sind. Und deswegen bekommt man das, was Impedanz-Mismatch genannt wird, und jemand muss sich auf die eine oder andere Weise damit auseinandersetzen. Aber was passiert eigentlich, weil ein Modell, das Modell des Codierers und die Datenbank eines anderen Modells nicht besonders aufeinander abgestimmt sind. Man bekommt Fehler, die einfach nicht passieren würden, wenn die Branche Dinge entwickelt hätte, die zusammenarbeiten, was ich lustig finde. Wenn Sie also Hierarchien erhalten, können es Typen, Ergebnismengen, eine schlechte API-Fähigkeit und viele Dinge sein, die die Interaktion mit der Datenbank beeinträchtigen. Aber das, was für mich am interessantesten ist, ist wirklich interessant. Ich habe mich immer gewundert, dass Sie diese SQL-Barriere hatten, die auch eine Art Impedanz ist, so dass die Codierer und die Datenbank miteinander arbeiten. SQL hat also eine Datenerkennung, die in Ordnung ist, und DML zum Auswählen, Projizieren und Verknüpfen, was in Ordnung ist. Damit können Sie eine Menge Möglichkeiten nutzen, um Daten aus der Datenbank zu holen. Aber es hat sehr wenig mathematische Sprache, um Dinge zu tun. Es hat ein bisschen von diesem und jenem und es hat sehr wenig zeitbasiertes Zeug. Und aus diesem Grund ist SQL ein unvollkommenes Mittel zum Abrufen der Daten. Also bauten die Datenbank-Leute gespeicherte Prozeduren auf, um in der Datenbank zu leben, und der Grund für die gespeicherten Prozeduren, die dort lebten, war, dass Sie nicht wirklich Daten in ein Programm werfen wollten.
Einige der Funktionen waren extrem datenspezifisch. Es handelte sich also nicht nur um referenzielle Integrität und kaskadierende Löschvorgänge. Die Datenbank hat sich auf einmal darum gekümmert, dass Sie Funktionen in eine Datenbank einfügen. Das bedeutete natürlich, dass dies der Fall war Die Funktionalität für eine Anwendung kann zwischen dem Codierer und der Datenbank selbst aufgeteilt werden. Und das machte die Implementierung einiger Funktionen sehr schwierig und daher fehleranfälliger. Das ist eine Seite des Datenbankspiels, weil es bedeutet, dass Sie eine Menge Implementierungen haben, zum Beispiel, dass ich an relationalen Datenbanken beteiligt war. Es gibt wirklich sehr viel Code, der in gespeicherten Prozeduren gespeichert ist, die behandelt werden getrennt von Code, der in den Anwendungen sitzt. Und es scheint eine sehr seltsame Sache zu sein, es soll ziemlich klug darin sein, verschiedene Dinge zu tun.
Ich dachte, ich würde auch über die Datenbankleistung sprechen, da Leistungsfehler oft als Fehler angesehen werden. Grundsätzlich kann es jedoch zu Engpässen bei der CPU, im Speicher, auf der Festplatte und im Netzwerk sowie zu Leistungsproblemen aufgrund von Sperren kommen . Die Idee wäre, dass der Codierer sich nicht wirklich um die Leistung sorgen muss und die Datenbank tatsächlich eine einigermaßen gute Leistung erbringt. Es soll so gestaltet sein, dass der Programmierer es nicht wissen muss. Sie bekommen jedoch ein schlechtes Datenbankdesign, Sie bekommen ein schlechtes Programmdesign, Sie bekommen Parallelität beim Workload-Mischen, was auch zu Leistungsproblemen führen kann. Sie erhalten einen Lastenausgleich, Kapazitätsplanung und Datenwachstum - dies kann dazu führen, dass eine Datenbank nur angehalten oder verlangsamt wird. Es ist eine interessante Sache, wenn Datenbanken fast voll werden, werden sie langsamer. Außerdem kann es zu Problemen mit Datenebenen hinsichtlich der Replikation und der Notwendigkeit der Replikation sowie der Durchführung von Sicherungen und Wiederherstellungen kommen. Jedenfalls ist das ein allgemeiner Überblick.
Das einzige, was ich sagen möchte, ist, dass das Debuggen von Datenbanken nur so lästig und nicht trivial sein kann - und ich sage das, weil ich viel getan habe - und Sie werden oft feststellen, dass es wie alle Situationen beim Debuggen ist, die ich habe jemals erlebt ist, ist das erste, was Sie jemals sehen, ist ein Chaos. Und Sie müssen versuchen, aus dem Chaos herauszukommen und herauszufinden, wie das Chaos entstanden ist. Und oft, wenn Sie sich ein Datenbankproblem ansehen, sehen Sie nur korrupte Daten und denken: "Wie zum Teufel ist das passiert?"
Wie auch immer, ich werde an Dez weitergeben, der wahrscheinlich mehr Worte der Weisheit sagen wird, als ich herausgebracht habe. Ich weiß nicht, wie ich dir den Ball geben soll, Dez.
Eric Kavanagh: Ich werde es weitergeben, zuschauen, durchhalten.
Automatisierte Sprachausgabe: Teilnehmerleitungen stumm geschaltet.
Eric Kavanagh: Okay, Moment mal, lass mich Dez den Ball geben.
Dez Blanchfield: Danke, Eric. Ja, Dr. Robin Bloor, Sie haben in der Tat höchstes Recht: Dies ist ein Thema, ein lebenslanger Bugbear, wenn Sie das Wortspiel verzeihen, tut mir leid, dass ich mir dabei nicht helfen konnte. Hoffentlich können Sie dort meinen ersten Bildschirm sehen, und ich entschuldige mich für das Problem mit der Schriftgröße oben. Das Thema Bugs ist meines Erachtens in vielen Fällen ein ganztägiger Vortrag. Es ist ein so breites und umfassendes Thema, dass ich mich auf zwei Schlüsselbereiche konzentrieren werde, insbesondere auf das Konzept dessen, was wir als Fehler, aber als Programmierproblem betrachten. Ich denke, dass die Einführung eines Fehlers per se heutzutage in der Regel von den integrierten Entwicklungsumgebungen aufgegriffen wird, auch wenn es sich möglicherweise um lang laufende Fehler handelt. Aber oft handelt es sich eher um Profiling-Code, und es ist möglich, Code zu schreiben, der funktioniert, das sollte ein Fehler sein. Also, meine Titelrutsche hier, ich hatte tatsächlich eine Kopie davon in sehr hoher Auflösung A3, aber leider wurde sie bei einem Umzug zerstört. Dies ist jedoch eine handschriftliche Notiz auf einem Programmierblatt aus dem Jahr 1945, in dem angeblich einige Leute an der Harvard University in den USA eine Maschine namens Mark II bauten. Sie haben ein Problem in der gemeinsamen Sprache behoben, aber sie haben versucht, einen Fehler zu finden, und es hat sich herausgestellt, dass etwas anderes als ein Hardware- und ein angebliches Softwareproblem aufgetreten ist.
Der urbane Mythos besagt also, dass ein Team der Harvard University gegen den 9. September 1945 eine Maschine auseinanderzog und auf etwas stieß, das sie "Relais siebzig" nannten Auf diese Weise haben Sie die Maschine effektiv programmiert - und sie fanden, dass bei dieser Relaisnummer 70 etwas nicht stimmte. Der eigentliche Begriff „Fehler“ ist entstanden, weil es sich buchstäblich um eine Motte handelte - angeblich dort Eine Motte war zwischen einem Stück Kupferdraht eingeklemmt, das von einem Ort zum anderen führte. Und die Geschichte besagt, dass der legendäre Grace Hopper als diese Überschrift für meine Titelfolie „der erste tatsächliche Fall, in dem ein Fehler gefunden wurde“ nicht zitiert wird.
Doch wie Robin bereits in seiner ersten Folie hervorgehoben hat, reicht das Konzept eines Fehlers so weit zurück, wie wir uns vorstellen können, dass Menschen rechnen, Konzepte wie ein Patch. Der Begriff „Patch“ stammt von einem Stück Klebeband, das über ein Loch auf einer Lochkarte geklebt wurde. Der springende Punkt dabei ist, dass der Begriff „Debugging“ aus diesem Konzept hervorgegangen ist, einen Fehler in einem physischen Computer zu finden. Und seitdem verwenden wir diese Terminologie, um Probleme zu lösen, und zwar nicht nur, um Probleme in einem Programm zu codieren, das nicht kompiliert werden kann, sondern auch, wenn es nicht gut läuft. Und speziell nicht profiliert wurde, sondern Dinge wie Endlosschleifen findet, die einfach nirgendwo hingehen.
Wir haben aber auch ein Szenario und ich dachte, ich würde ein paar lustige Folien reinstecken, bevor ich etwas näher darauf eingehen würde. Hier ist der klassische Cartoon mit dem Namen XKCD im Web, und der Cartoonist hat einige ziemlich lustige Ansichten über die Welt. Und hier geht es um ein Kind namens "Little Bobby Tables", und angeblich nannten seine Eltern diesen kleinen Jungen "Robert". TROPFEN-TABELLE Schüler - und es heißt und heißt sozusagen "Hallo, das ist die Schule deines Sohnes, in der es Computerprobleme gibt", und die Eltern antworten: "Oh, Liebes, hat er etwas kaputt gemacht?" Und der Lehrer sagt: "Nun, In gewisser Weise “, fragt der Lehrer, „ haben Sie Ihren Sohn Robert wirklich benannt? '); DROP TABLE Students; -? “Und die Eltern sagen:„ Oh ja, kleine Bobby Tables, die wir ihn nennen. “Wie auch immer, sie sagen weiter, sie haben jetzt die Schülerrekorde des Jahres verloren, ich hoffe, Sie sind glücklich. Und die Antwort lautet: "Nun, Sie sollten Ihre Datenbankeingaben bereinigen und bereinigen." Und ich spreche so oft über einige der Probleme, die wir beim Auffinden von Dingen im Code haben, dass der Code die Daten häufig nicht untersucht auch.
Ein weiterer lustiger, ich weiß nicht, ob das echt ist oder nicht - ich vermute, es ist eine Parodie - aber auch hier berührt es meinen lustigen Knochen. Jemand ändert das Nummernschild an der Vorderseite seines Autos in eine ähnliche Anweisung, die dazu führt, dass Datenbanken in Blitzer fallen und so weiter, die die Nummernschilder des Autos erfassen. Und ich beziehe mich immer darauf, dass ich bezweifle, dass ein Programmierer einen Hit und Run seines Codes durch ein tatsächliches Kraftfahrzeug erwartet hat, aber unterschätze das nie - die Macht eines verärgerten Geeks.
(Lachen)
Aber das führt mich zu meinem Kernpunkt, denke ich, und das ist, dass wir einst Code als Sterbliche debuggen und profilieren konnten. Aber ich bin sehr davon überzeugt, dass diese Zeit vergangen ist und meiner Erfahrung nach meine erste - und das wird mich schrecklich altern, da bin ich mir sicher; Robin, du kannst dich gerne über mich lustig machen - aber ich komme aus der Vergangenheit, als ich 14 Jahre alt war und am Ende der Stadt herumwanderte und in New an die Tür eines Rechenzentrums mit dem Namen „Data Com“ klopfte Zealand und die Frage, ob ich in der Schule Taschengeld verdienen könnte, indem ich den späten Bus nach Hause bringe, etwa 25 km täglich pendle, Papier in Drucker stecke und Bänder in Bandlaufwerke stecke und nur ein Generaladministrator bin. Und seltsamerweise gaben sie mir einen Job. Aber im Laufe der Zeit gelang es mir, mich in die Personalabteilung einzumischen und die Programmierer zu finden, und mir wurde klar, dass ich das Codieren liebte, und ich ging durch den Prozess des Ausführens von Skripten und Batch-Jobs, die am Ende immer noch Code sind. Sie müssen Skripte und Batch-Jobs schreiben, die wie Mini-Programme aussehen, und dann den gesamten Prozess des Schreibens von Code auf einem 3270-Terminal von Hand durchlaufen.
In der Tat war meine allererste Erfahrung mit einem Teletyp-Terminal, das tatsächlich ein physischer 132-Spalten-Drucker war. Stellen Sie sich im Wesentlichen eine sehr alte Schreibmaschine vor, in der sich Papier befand, weil sie keine Röhren besaßen. Und das Debuggen von Code in dieser Hinsicht war kein einfaches Problem. Daher haben Sie Ihren gesamten Code in der Regel von Hand geschrieben und sich dann wie ein Typist verhalten, der sein Möglichstes tut, um Fehler zu vermeiden, die sich einschleichen, da es äußerst frustrierend ist, sagen zu müssen der Einzeileneditor, der zu einer bestimmten Zeile wechselt und diese dann druckt und dann wieder eintippt. Aber es war einmal so, dass wir Code geschrieben und auf diese Weise debuggt haben, und wir haben es sehr, sehr gut gemacht. Tatsächlich zwang es uns, sehr gute Programmiertechniken zu haben, da es ein echtes Problem war, das Problem zu beheben. Aber dann ging die Reise - und wir sind alle damit vertraut - von der 3270-Terminalerfahrung in meiner Welt zu Digital Equipment VT220, wo man Dinge auf dem Bildschirm sehen konnte, aber auch hier haben Sie genau dasselbe getan Sie haben auf dem Papierband eine Art gedrucktes Format nur auf einer CRT erstellt, aber Sie waren in der Lage, einfacher zu löschen, und Sie hatten nicht den Sound "dit dit dit dit".
Und dann wissen Sie, die Wyse-Terminals - wie das Wyse 150, wahrscheinlich meine Lieblingsschnittstelle zu einem Computer - und dann der PC und dann der Mac und heutzutage moderne GUIs und IDs, die webbasiert sind. Und eine Reihe von Programmen, die in einem und Assembler und PILOT und Logo und Lisp und Fortran und Pascal programmiert wurden, und Sprachen, die Menschen erschrecken könnten. Aber diese Sprachen haben Sie gezwungen, guten Code zu schreiben. Sie ließen dich nicht mit schlechten Praktiken davonkommen. C, C ++, Java, Ruby, Python - und wir werden in dieser Programmierphase noch weiter fortgeschritten, wir werden skriptähnlicher, wir kommen der Structured Query Language und Sprachen wie PHP, die tatsächlich zum Aufrufen von SQL verwendet werden, immer näher. Ich möchte Ihnen sagen, dass ich von meinem Hintergrund her in vielerlei Hinsicht Autodidakt war und diejenigen, die mir beim Lernen geholfen haben, mir sehr gute Programmierpraktiken und sehr gute Praktiken in Bezug auf Design und Prozesse beigebracht haben, um sicherzustellen, dass dies nicht der Fall ist Buggy-Code einführen.
Heutzutage sind Programmiermethoden wie beispielsweise SQL (Structured Query Language) eine sehr leistungsfähige und einfache Abfragesprache. Aber wir haben es in eine Programmiersprache verwandelt und ich glaube nicht wirklich, dass SQL jemals als moderne Programmiersprache konzipiert wurde, aber wir haben es so verzerrt. Und das wirft eine ganze Reihe von Fragen auf, wenn wir an zwei Aspekte denken: an die Codierung und an die DBA. Es ist sehr einfach, Fehler in Sachen schlechter Programmiertechniken, fauler Versuche, Code zu schreiben, mangelnder Erfahrung, dem klassischen Ärgernis, das ich habe, einzuführen, zum Beispiel wenn SQL-Leute auf Google springen und nach etwas suchen und eine Website finden, die das ist habe ein Beispiel und mache ein Copy & Paste von existierendem Code. Und dann eine fehlerhafte Codierung, ein fehlerhaftes Vorgehen und die Produktion wieder aufnehmen, weil es ihnen zufällig die gewünschten Ergebnisse liefert. Sie haben andere Herausforderungen, zum Beispiel: In diesen Tagen stürzen wir uns alle darauf, was wir als Nullrennen bezeichnen: Wir versuchen, alles so billig und schnell zu machen, dass wir ein Szenario haben, in dem wir nicht weniger beschäftigen -bezahltes Personal. Und das meine ich nicht unaufrichtig, aber wir stellen nicht für jeden möglichen Job Experten ein. Früher war alles, was mit Computern zu tun hatte, Raketenwissenschaft. es war an Dingen beteiligt, die knallten und sehr laut waren oder in den Weltraum gingen, oder Ingenieure waren hochqualifizierte Männer und Frauen, die Abschlüsse gemacht hatten und strenge Ausbildungen hatten, die sie davon abhielten, verrückte Dinge zu tun.
Heutzutage gibt es eine Menge Leute, die sich mit Entwicklung, Design und Datenbank beschäftigen, die nicht über jahrelange Erfahrung verfügen und nicht unbedingt die gleiche Ausbildung oder Unterstützung haben. Und so endet man mit einem Szenario, in dem es nur um den traditionellen Amateur gegen den Experten geht. Und es gibt eine berühmte Zeile, an die ich mich eigentlich nicht erinnern kann, wer das Zitat erstellt hat. Die Zeile lautet: „Wenn Sie der Meinung sind, dass es teuer ist, einen Experten für einen Job zu engagieren, warten Sie, bis Sie ein paar Amateure einstellen, die ein Problem verursachen, und Sie Es muss aufgeräumt werden. “SQL hat also dieses Problem und es ist sehr, sehr einfach zu erlernen und sehr einfach zu bedienen. Aber meiner Meinung nach ist es keine perfekte Programmiersprache. Es ist sehr einfach, Dinge wie einen ausgewählten Stern von überall aus zu tun und alles in eine Programmiersprache zu ziehen, mit der Sie sich besser auskennen, wie PHP und Ruby oder Python, und die Programmiersprache zu verwenden, mit der Sie ursprünglich vertraut sind die Datenmanipulation, anstatt eine komplexere Abfrage in SQL durchzuführen. Und wir sehen das sehr oft, und dann fragen sich die Leute, warum die Datenbank langsam läuft. Das liegt daran, dass eine Million Menschen versuchen, ein Ticket über ein Online-Ticketsystem zu kaufen, bei dem ein ausgewählter Star von jedem beliebigen Ort aus auftritt.
Nun, das ist ein wirklich extremes Beispiel, aber Sie verstehen, worauf es ankommt. Um diesen Punkt wirklich zu verdeutlichen, hier ein Beispiel, das ich viel herumtrage. Ich bin ein großer Fan von Mathematik, ich liebe die Chaostheorie, ich liebe die Mandelbrot-Sets. Auf der rechten Seite ist eine Wiedergabe des Mandelbrot-Sets zu sehen, mit der wir sicher alle vertraut sind. Und auf der linken Seite gibt es ein Stück SQL, das das tatsächlich rendert. Jetzt höre ich jedes Mal, wenn ich das irgendwo auf einen Bildschirm lege, Folgendes: „Oh mein Gott, jemand hat die Mandelbrot-Reihe mit SQL gerendert, meinen Sie das ernst? Das ist verrückt! “Nun, der springende Punkt ist, zu veranschaulichen, was ich dort gerade skizziert habe, und das ist ja, in der Tat können Sie jetzt fast alles in SQL programmieren. Es ist eine sehr stark entwickelte, leistungsfähige, moderne Programmiersprache. Als es ursprünglich eine Abfragesprache war, war es so konzipiert, dass nur Daten abgerufen werden. Jetzt haben wir also sehr komplexe Konstrukte und gespeicherte Prozeduren, wir haben Programmiermethoden, die auf eine Sprache angewendet werden, und es ist daher sehr einfach für schlechte Programmierpraxis, mangelnde Erfahrung, Code ausschneiden und einfügen. Niedriglohnpersonal, das versucht, hochbezahltes Personal zu sein, Leute, die so tun, als wüssten sie es, aber sie müssen am Arbeitsplatz lernen.
Eine ganze Reihe von Dingen, in denen Code-Profiling und das, was wir als Debugging bezeichnen, nicht so sehr Fehler finden, die das Funktionieren von Programmen verhindern, sondern Fehler, die nur das System und den schlecht strukturierten Code schädigen. Wenn Sie jetzt auf diesen Bildschirm schauen und denken, das ist einfach süß und Sie denken: „Wow, was für eine großartige Grafik, das würde ich gerne ausführen.“ Aber stellen Sie sich vor, dass dies auf einer Geschäftslogik basiert . Es sieht ziemlich ordentlich aus, spricht aber eine mathematisch grafisch dargestellte Chaostheorie. Wenn Sie sich jedoch überlegen, wofür es möglicherweise in einer Geschäftslogik verwendet werden könnte, erhalten Sie sehr schnell ein Bild. Und um das wirklich zu veranschaulichen - und es tut mir leid, dass die Farben vertauscht sind, soll es ein schwarzer Hintergrund und grüner Text sein, um ein grüner Bildschirm zu sein, aber Sie können das immer noch lesen.
Ich habe mir ein Beispiel angesehen, was Sie möglicherweise tun können, wenn Sie wirklich verrückt sind und keinerlei Erfahrung haben. Ich bin von einem anderen Hintergrund der Programmierung ausgegangen und habe C ++ auf SQL angewendet, um meinen Standpunkt wirklich zu veranschaulichen Ich übergebe an unseren gelehrten Gast von IDERA. Dies ist eine strukturierte Abfrage, die wie C ++ geschrieben, aber in SQL codiert ist. Und es wird tatsächlich ausgeführt, aber es wird über einen Zeitraum von drei bis fünf Minuten ausgeführt. Und es zieht angeblich eine Datenzeile aus mehreren Datenbanken zurück, mehrere Verknüpfungen.
Der springende Punkt dabei ist wiederum, dass Sie 100.000 Mitarbeiter haben, wenn Sie nicht über die richtigen Tools verfügen, wenn Sie nicht über die richtigen Plattformen und Umgebungen verfügen, um diese Dinge zu erfassen, und wenn sie in Produktion gehen Wenn Sie jeden Tag, jede Stunde oder jede Minute auf ein System treffen, haben Sie sehr bald eine Erfahrung in Tschernobyl, in der das große Eisen zu schmelzen beginnt und sich im Kern des Planeten vergräbt, weil dieses Stück Code niemals in die Produktion gelangen sollte. Entschuldigen Sie, Ihre Systeme und Werkzeuge sollten das aufgreifen, bevor es irgendwo in der Nähe ist. Selbst während des Testprozesses, sogar durch UAT- und Systemintegration, sollte dieser Teil des Codes aufgegriffen und hervorgehoben und jemand beiseite gebracht werden Mit den Worten: „Sehen Sie, das ist wirklich hübscher Code, aber lassen Sie uns einen DBA besorgen, der Ihnen hilft, diese strukturierte Abfrage richtig zu erstellen, denn ehrlich gesagt ist das nur böse.“ Und die URL ist da, Sie können nachsehen - sie wird als die bezeichnet komplexeste SQL-Abfrage, die Sie jemals geschrieben haben. Denn glauben Sie mir, das kompiliert tatsächlich, es läuft. Und wenn Sie das ausschneiden und einfügen und die Datenbank nur verspotten, ist es ziemlich sehenswert; Wenn Sie über die Tools zum Anzeigen der Datenbank verfügen, versuchen Sie einfach, innerhalb von drei bis fünf Minuten die Daten zu verarbeiten, um eine einzelne Textzeile abzurufen.
Zusammenfassend hat mich mein gesamter Hintergrund im Codieren gelehrt, dass man Menschen eine Waffe geben kann und sie sich in den Fuß schießen, wenn sie nicht aufpassen. Der Trick ist, ihnen zu zeigen, wo sich der Sicherheitsmechanismus befindet. Mit den richtigen Tools und der richtigen Software an Ihren Fingerspitzen können Sie, nachdem Sie die Codierung durchgeführt haben, Ihren Code überprüfen, Probleme durch Profilerstellung des Codes finden, effektiv unbeabsichtigte Fehler finden, bei denen es sich um Leistungsprobleme handelt, und wie gesagt Früher war es einmal möglich, einen grünen Bildschirm zu betrachten. Sie können nicht mehr; Es gibt Hunderttausende von Codezeilen, es sind Zehntausende von Apps implementiert, es gibt Millionen von Datenbanken in einigen Fällen, und selbst Supermenschen können dies nicht mehr von Hand tun. Sie benötigen im wahrsten Sinne des Wortes die richtige Software und die richtigen Tools, und das Team muss diese Tools verwenden, damit Sie diese Probleme finden und sehr, sehr schnell beheben können, bevor Sie zur Sache kommen, wohingegen Dr. Robin Bloor hob hervor, dass die Dinge entweder katastrophal werden und in die Luft jagen, oder dass sie Sie einfach eine Menge Geld und viel Zeit und Mühe kosten und die Moral und das Zeug zerstören, wenn sie nicht herausfinden können, warum die Dinge dauern eine lange Zeit zu laufen.
Und in diesem Sinne werde ich an unseren Gast übergeben und ich freue mich zu hören, wie sie dieses Problem gelöst haben. Und besonders die Demo, von der ich denke, dass wir sie bald erhalten werden. Eric, ich gehe zurück.
Eric Kavanagh: Okay, Bert, nimm es weg.
Bert Scalzo: Okay, danke. Bert Scalzo hier von IDERA, ich bin der Produktmanager für unsere Datenbanktools. Und ich werde über das Debuggen sprechen. Ich denke, eines der wichtigsten Dinge, die Robin zuvor gesagt hat - und es ist sehr wahr, dass das Debuggen lästig und nicht trivial ist, und wenn Sie zum Debuggen von Datenbanken übergehen, ist es eine Größenordnung lästiger und nicht trivial war ein wichtiges Zitat.
IN ORDNUNG. Ich wollte mit dem Programmieren des Verlaufs beginnen, weil ich oft Leute sehe, die nicht debuggen, die keinen Debugger verwenden, sie programmieren nur mit der Sprache, die sie verwenden, und oft sagen sie es mir "Nun, diese Debugger-Dinge sind neu und wir haben noch nicht damit begonnen." Ich zeige ihnen also diese Zeittafel, eine Art Vorgeschichte, das Alter, das Mittelalter, es ist eine Art zu sagen, wo waren wir in Bezug auf Programmiersprachen. Und wir hatten sehr alte Sprachen, beginnend im Jahr 1951 mit Assembler-Code und Lisp und FACT und COBOL. Dann kommen wir in die nächste Gruppe, Pascals und Cs, und dann in die nächste Gruppe, die C ++ s, und schauen, wo sich dieses Fragezeichen befindet - dieses Fragezeichen liegt ungefähr zwischen 1978 und 1980. Irgendwo in diesem Bereich hatten wir Uns zur Verfügung stehende Debugger und sozusagen: "Hey, ich benutze keinen Debugger, weil das eines dieser neuen Dinge ist." Dann müssen Sie in den 1950er Jahren mit dem Programmieren begonnen haben Nur so würden Sie mit dieser Behauptung davonkommen.
Das andere lustige an dieser Grafik ist, dass Dez gerade einen Kommentar über Grace Hopper gemacht hat. Ich kannte Grace tatsächlich, also ist es irgendwie lustig. Und das andere, worüber ich gelacht habe, ist, dass er über Teletypen sprach, und ich sitze da und frage: „Mann, das war der größte Produktivitätssprung, den wir je hatten, als wir von Karten zu Teletypen wechselten, das war der größte Sprung, den es je gab. Also, und ich habe alle Sprachen hier programmiert, einschließlich SNOBOL, von denen noch niemand zuvor gehört hat, es war eine CDC, Control Data Corporation, also werde ich wohl ein bisschen zu alt für diese Branche .
Dez Blanchfield: Ich wollte sagen, Sie haben uns dort schrecklich gealtert.
Bert Scalzo: Ja, ich sage dir, ich fühle mich wie Opa Simpson. Ich schaue mir das Debuggen an und es gibt verschiedene Möglichkeiten, das Debuggen durchzuführen. Sie könnten über das sprechen, was wir alle als traditionellen Einstieg in einen Debugger und schrittweise durch den Code betrachten. Aber auch die Leute werden ihren Code instrumentieren; Hier fügen Sie Anweisungen in Ihren Code ein und erstellen möglicherweise eine Ausgabedatei, eine Ablaufverfolgungsdatei oder ähnliches. Auf diese Weise instrumentieren Sie Ihren Code. Ich würde das als Debugging bezeichnen, es ist ein bisschen schwieriger, wie man es macht, aber es zählt. Aber wir haben auch die berühmte print-Anweisung: Sie sehen und die Leute setzen tatsächlich print-Anweisungen ein und ich habe tatsächlich ein Tool gesehen, in dem - und es ist ein Datenbank-Tool - wenn Sie nicht wissen, wie man einen Debugger verwendet, Wenn Sie einen Knopf drücken, werden Druckanweisungen im gesamten Code für Sie festgehalten. Wenn Sie fertig sind, drücken Sie einen anderen Knopf und dieser entfernt sie. Denn so debuggen viele Leute.
Und wir debuggen aus zwei Gründen: Zunächst müssen wir Dinge finden, die unseren Code ineffektiv machen. Mit anderen Worten, dies bedeutet normalerweise, dass ein logischer Fehler vorliegt oder wir eine Geschäftsanforderung übersehen haben. Dies ist jedoch der Fall, dass der Code nicht effektiv ist. es tut nicht das, was wir erwartet hatten. Das andere Mal, wenn wir das Debuggen durchführen, dient dies der Effizienz und könnte ein logischer Fehler sein, aber was es ist, ist, dass ich das Richtige getan habe. Es kommt einfach nicht schnell genug zurück. Ich verstehe das, weil ein Profiler wahrscheinlich besser für dieses zweite Szenario geeignet ist und wir sowohl über Debugger als auch über Profiler sprechen werden. Darüber hinaus gibt es dieses Konzept des Remote-Debuggens. Dies ist wichtig, da Sie häufig das sogenannte Remote-Debugging durchführen, wenn Sie auf Ihrem PC sitzen und einen Debugger verwenden, der auf eine Datenbank zugreift, in der der Code tatsächlich in der Datenbank ausgeführt wird. Sie werden es vielleicht nicht bemerken, aber genau das passiert. Und dann ist es bei diesen Debuggern üblich, dass sie Unterbrechungspunkte haben, Punkte beobachten, einsteigen und übergehen und einige andere übliche Dinge, die ich gleich auf einem Bildschirmschnappschuss zeigen werde.
Jetzt Profilerstellung: Sie können das Profilerstellen auf verschiedene Arten durchführen. Einige Leute werden sagen, dass Workloads dort erfasst und wiedergegeben werden, wo sie alles erfassen, was als Profilerstellung zählt. Meine Erfahrung war eher so, dass es besser ist, Proben zu nehmen. Es gibt keinen Grund, jede einzelne Anweisung abzufangen, da einige Anweisungen möglicherweise so schnell ausgeführt werden, dass es Ihnen egal ist. Was Sie wirklich sehen möchten, ist, welche Anweisungen immer wieder auftauchen, weil Sie laufen zu lange. Daher kann Profiling manchmal auch Sampling bedeuten, anstatt das Ganze auszuführen. In der Regel erhalten Sie eine Art Ausgabe, die Sie verwenden können. Diese kann nun in einer IDE-Entwicklungsumgebung visuell dargestellt werden, wobei sie Ihnen möglicherweise ein Histogramm der Leistung der verschiedenen Codezeilen liefert, aber auch weiterhin angezeigt wird sei es, dass es eine Trace-Datei erzeugt.
Profiler tauchten erstmals 1979 auf. Diese gibt es also auch schon lange. Hervorragend geeignet, um Ressourcenverbrauch oder Leistungsprobleme zu finden, mit anderen Worten, diese Effizienzsache. Im Allgemeinen unterscheidet es sich vom Debugger, obwohl ich mit Debuggern zusammengearbeitet habe, die beides gleichzeitig tun. Und während Profiler meiner Meinung nach das interessantere der beiden Tools sind, scheint es, als ob nicht genug Leute debuggen, aber definitiv nicht genug Leute profilieren, weil jeder zehnte Debugger ein Profil erstellt. Und das ist eine Schande, denn die Profilerstellung kann wirklich einen großen Unterschied machen. Nun, Datenbanksprachen, über die wir bereits gesprochen haben, haben Sie SQL - und wir haben den runden Stift hier irgendwie in das quadratische Loch gezwungen und ihn dazu gezwungen, eine Programmiersprache zu werden - und Oracle. Das ist PL / SQL - das ist die prozedurale Sprache SQL - und SQL Server, es ist Transact-SQL, es ist SQL-99, es ist SQL / PSM - ich denke, es ist Procedure Stored Module. Postgres gibt ihm einen anderen Namen, DB2 noch einen anderen Namen, Informix, aber der Punkt ist, dass jeder Konstrukte vom Typ 3GL erzwungen hat. Mit anderen Worten, FOR-Schleifen, bei Variablendeklarationen und alle anderen SQL-fremden Dinge sind jetzt in diesen Sprachen Bestandteil von SQL. Daher müssen Sie in der Lage sein, ein PL / SQL- oder ein Transact-SQL-Programm genau wie ein Visual Basic-Programm zu debuggen.
Nun, Datenbankobjekte, das ist wichtig, weil die Leute sagen werden: "Nun, welche Dinge muss ich in einer Datenbank debuggen?" Und die Antwort ist, nun, was auch immer Sie als Code in der Datenbank speichern können - wenn ich das tue T-SQL oder PL / SQL - und ich speichere Objekte in der Datenbank, es ist wahrscheinlich eine gespeicherte Prozedur oder eine gespeicherte Funktion. Es gibt aber auch Trigger: Ein Trigger ähnelt einer gespeicherten Prozedur, wird jedoch bei einer Art Ereignis ausgelöst. Einige Leute in ihren Triggern fügen eine Codezeile ein und rufen eine gespeicherte Prozedur auf, damit sie ihren gesamten gespeicherten Code und ihre gespeicherten Prozeduren behalten. Es ist jedoch das gleiche Konzept: Es kann immer noch der Trigger sein, der das Ganze initiiert. Und dann haben sie als Oracle so etwas wie ein Paket, das, wenn man so will, einer Bibliothek ähnelt. Sie ordnen 50 oder 100 gespeicherte Prozeduren in eine Gruppierung ein, die als Paket bezeichnet wird, sodass sie einer Art Bibliothek ähnelt. Also, hier ist der Debugger der alte Weg; Dies ist eigentlich ein Tool, das alle diese Debug-Anweisungen für Sie in Ihren Code einfügt. Also, überall, wo Sie Debug-Block sehen, nicht entfernen, den Auto-Debugger starten und verfolgen, die alle von einem Tool stecken geblieben sind. Und die Zeilen außerhalb davon, die die Minderheit des Codes darstellen, sind die nicht-manuellen Debugging-Methoden.
Und der Grund, warum ich dies anspreche, ist, dass Sie, wenn Sie dies von Hand versuchen, tatsächlich mehr Debug-Code eingeben, um all diese print-Anweisungen einzufügen, als Sie es mit dem Code tun. Obwohl dies funktioniert und besser als gar nichts ist, ist dies eine sehr schwierige Methode zum Debuggen, vor allem, da es 10 Stunden gedauert hat, bis dieses Ding ausgeführt wurde und in Zeile drei ein Problem aufgetreten ist. Wenn ich eine interaktive Debugsitzung durchgeführt hätte, hätte ich es in Zeile drei - fünf Minuten gewusst - hey, hier gibt es ein Problem, das ich beenden kann. Aber damit muss ich warten, bis es läuft, bis es fertig ist, und dann muss ich mir eine Trace-Datei ansehen, die wahrscheinlich alle diese print-Anweisungen enthält, und versuchen, die Nadel in der zu finden Heuhaufen. Auch dies ist besser als nichts, aber es wäre nicht die beste Art zu arbeiten. Nun, so würde diese Datei aussehen, die von der vorherigen Folie stammt. Mit anderen Worten, ich habe das Programm ausgeführt und es enthält nur eine Reihe von print-Anweisungen in dieser Ablaufverfolgungsdatei. Vielleicht kann ich das durchgehen und herausfinden, was ich finden muss. Daher bin ich mir nicht sicher, ob Sie so arbeiten möchten.
Jetzt haben interaktive Debugger - und wenn Sie Visual Studio zum Schreiben von Programmen oder Eclipse verwendet haben, hatten Sie Debugger und Sie haben sie mit Ihren anderen Sprachen verwendet - einfach nicht daran gedacht, sie hier in Ihrer Datenbank zu verwenden. Es gibt auch Tools wie DB Artisan und Rapid SQL. Dies ist hier Rapid SQL mit einem Debugger. Auf der linken Seite sehen Sie, dass ich eine gespeicherte Prozedur mit dem Namen "Auf Duplikate prüfen" habe. Im Grunde geht es nur darum zu schauen, ob ich mehrere Zeilen in der Tabelle mit demselben Filmtitel habe. Die Datenbank ist also für Filme. Und Sie konnten auf der rechten Seite sehen, im oberen Drittel, ich habe meinen Quellcode in der Mitte, ich habe, was meine Watch-Variablen und meine Call-Stack-Trays genannt werden, und dann am unteren Rand habe ich Ich habe einige Ausgabenachrichten erhalten. Und was hier wichtig ist, ist, wenn Sie über den ersten roten Pfeil schauen, wenn Sie mit der Maus über eine Variable fahren, kann ich tatsächlich sehen, welcher Wert sich zu diesem Zeitpunkt in dieser Variablen befindet, während ich durch den Code gehe. Und das ist wirklich nützlich, und dann kann ich zeilenweise durch den Code gehen. Ich muss nicht "Ausführen" sagen. Ich kann "zeilenweise gehen" sagen. Lass mich schauen, was passiert ist. Lass mich sehen, was passiert ist Und das mache ich in der Datenbank. Und auch wenn ich auf meinem PC auf Rapid SQL sitze und meine Datenbank in der Cloud ist, kann ich das Remote-Debuggen durchführen und es von hier aus anzeigen und steuern sowie das Debuggen so durchführen, wie ich es mit jeder anderen Sprache tun würde.
Nun, der nächste Pfeil dort - Sie können den kleinen Pfeil sehen, der nach rechts in Richtung der DBMS-Ausgabe zeigt. Dort befindet sich momentan mein Cursor. Mit anderen Worten, ich bin gegangen und dort bin ich der Moment. Wenn ich also "Schritt nochmal" sage, gehe ich zur nächsten Zeile. Direkt darunter sehen Sie den roten Punkt. Nun, das ist ein Haltepunkt, an dem steht: "Hey, ich möchte nicht über diese Linien treten." Wenn ich nur über alles springen und zu diesem roten Punkt gelangen möchte, kann ich die Schaltfläche "Ausführen" drücken, und es wird ausgeführt Von hier aus entweder bis zum Ende oder bis zu einem Haltepunkt, wenn Haltepunkte festgelegt wurden. Dann stoppt der Vorgang und ich mache das Steppen erneut. Und der Grund, warum dies alles wichtig und mächtig ist, ist, dass sich, wenn ich das alles mache, das, was in der Mitte und sogar im unteren Bereich passiert - aber am wichtigsten ist, in der Mitte - ändern wird und ich die Werte aus meinen Variablen sehen kann, Ich kann meine Call-Stack-Ablaufverfolgung sehen, wissen Sie, und all diese Informationen werden dort angezeigt, wenn ich durch den Code gehe, damit ich tatsächlich sehen und fühlen und ein Verständnis dafür bekommen kann, was los ist und wie der Code tatsächlich ist zur Ausführungszeit arbeiten. Und normalerweise kann ich ein Problem finden, wenn es eines gibt oder wenn ich gut genug bin, um es zu erkennen.
OK, jetzt werde ich über einen Profiler sprechen, und in diesem Fall ist dies ein Profiler, den ich durch einen Debugger sehen kann. Erinnerst du dich, ich habe gesagt, manchmal sind sie getrennt und manchmal können sie zusammen sein? In diesem Fall bin ich wieder in Rapid SQL und sehe einen Rand auf der linken Seite neben den Zeilennummern. Und das ist die Anzahl der Sekunden oder Mikrosekunden, die für die Ausführung jeder Codezeile benötigt wurden, und ich sehe, dass meine gesamte Zeit in dieser FOR-Schleife verbracht wird, in der ich alles aus einer Tabelle auswähle . Was auch immer in dieser FOR-Schleife passiert, muss ich mir wahrscheinlich ansehen, und wenn ich es verbessern kann, zahlt es sich aus. Ich werde keine Verbesserungen erzielen, wenn ich an den Zeilen arbeite, die 0, 90 oder 0, 86 haben. es ist nicht viel Zeit dort verbracht. In diesem Fall und wieder in Rapid SQL sehen Sie, wie ich Profile erstellen kann, die mit meinem Debuggen vermischt sind. Das Schöne ist, dass Rapid SQL es Ihnen auch ermöglicht, es in die andere Richtung zu tun. Mit Rapid SQL können Sie sagen: „Weißt du was? Ich möchte nicht im Debugger sein, ich möchte dies nur ausführen und dann die gleichen Informationen grafisch oder visuell anzeigen. “
Und Sie können sehen, dass ich nicht mehr im Debugger bin und das Programm ausgeführt wird. Nachdem die Ausführung abgeschlossen ist, werden Diagramme angezeigt, in denen Sie mir Dinge mitteilen können, damit ich sehen kann, dass ich eine Aussage habe, die anscheinend aufgreift Der größte Teil des Kreisdiagramms und wenn ich hinschaue, sehe ich in diesem Raster ganz unten, Zeile 23, wieder die FOR-Schleife: Er nimmt die meiste Zeit in Anspruch, er ist in der Tat, dass Dunkelrot das gesamte Kreisdiagramm zerkaut. Dies ist also eine andere Möglichkeit zum Erstellen von Profilen. Wir nennen das in unserem Tool "Code Analyst". Im Grunde genommen handelt es sich jedoch nur um einen vom Debugger getrennten Profiler. Manche Leute mögen es auf die erste Art und Weise, manche mögen es auf die zweite Art und Weise.
Warum debuggen und profilieren wir? Es ist nicht so, dass wir den besten Code der Welt schreiben und eine Gehaltserhöhung erhalten wollen - das könnte unser Grund sein, aber das ist nicht wirklich der Grund, warum Sie es tun - Sie haben dem Unternehmen versprochen, dass Sie etwas richtig machen würden, damit Ihr Programm effektiv wird. Dafür verwenden Sie den Debugger. Darüber hinaus Geschäftsendbenutzer; Sie sind nicht sehr geduldig: Sie wollen Ergebnisse, noch bevor sie die Taste drücken. Wir sollen ihre Gedanken lesen und alles sofort tun. Mit anderen Worten, es muss effizient sein. Deshalb würden wir den Profiler verwenden. Ohne diese Werkzeuge glaube ich wirklich, dass Sie dieser Typ im Business-Anzug mit Pfeil und Bogen sind und auf das Ziel schießen und die Augen verbunden sind. Denn wie finden Sie heraus, wie ein Programm ausgeführt wird, indem Sie sich nur den statischen Code ansehen, und wie finden Sie heraus, in welcher Zeile tatsächlich die meiste Zeit für die Ausführung erforderlich ist, und zwar wiederum, indem Sie sich nur den statischen Code ansehen? Eine Codeüberprüfung kann einige dieser Dinge aufdecken oder nicht, aber es gibt keine Garantie, dass eine Codeüberprüfung sie alle finden würde. Mit einem Debugger und einem Profiler sollten Sie in der Lage sein, alle diese Fehler zu finden.
OK, ich werde hier nur eine kurze Demo machen. Es ist nicht meine Absicht, ein Produkt zu veröffentlichen, sondern ich möchte Ihnen nur zeigen, wie ein Debugger aussieht, da die Leute häufig sagen: "Ich habe noch nie zuvor eines davon gesehen.", aber wie sieht es aus, wenn es in Bewegung ist? Hier auf meinem Bildschirm starte ich also unser DB Artisan-Produkt. Wir haben dort auch einen Debugger. Der DB Artisan ist eher für DBAs gedacht, der Rapid SQL eher für Entwickler, aber ich habe Entwickler gesehen, die DB Artisan verwenden, und ich habe DBAs gesehen, die Rapid verwenden. Lassen Sie sich also nicht vom Produkt einfangen. Und hier habe ich die Wahl, ein Debug durchzuführen, aber bevor ich das Debug starte, extrahiere ich diesen Code, damit Sie sehen können, wie der Code aussieht, bevor ich ihn starte. Also, hier ist genau der gleiche Code wie im Screenshot, das ist meine Überprüfung auf Duplikate. Und ich möchte das debuggen, also drücke ich auf debuggen. Und jetzt dauert es einen Moment und Sie sagen: "Nun, warum dauert es einen Moment?" Erinnern Sie sich an das Remote-Debugging: Das Debugging findet tatsächlich auf meinem Datenbankserver statt, nicht auf meinem PC. Es musste also eine Sitzung erstellen, ein Remote-Debugging-Objekt erstellen, meine Sitzung mit dieser Remote-Debugging-Sitzung verknüpfen und einen Kommunikationskanal einrichten.
Also, hier ist mein Pfeil, er ist oben, in Zeile eins, dort bin ich im Code. Und wenn ich dort auf das dritte Symbol drücke, in das ein Schritt hinein geht, wird der Pfeil gerade bewegt, und wenn ich weiter drücke, wird der Pfeil weiter bewegt. Wenn ich jetzt bis zu dieser FOR-Schleife gehen möchte, kann ich einen Haltepunkt setzen, da ich weiß, dass dort das Problem liegt. Ich dachte, ich hätte das festgelegt. Oh, schieß, ich hatte eine meiner Bildschirmaufnahmetasten der gleichen Taste wie der Debugger zugeordnet, das ist der Grund für die Verwirrung. OK, ich setze dort einfach manuell einen Haltepunkt. Anstatt also Schritt für Schritt voranzukommen, kann ich jetzt einfach sagen: "Mach weiter und führe dieses Ding aus", und es stoppt. Beachten Sie, dass es mich ganz nach unten bewegt hat, wo sich der Haltepunkt befindet. Jetzt bin ich im Kontext der Ausführung dieser Schleife und kann sehen, auf was alle meine Variablen eingestellt sind. Dies ist keine Überraschung, da ich sie alle initialisiert habe bis Null. Und jetzt kann ich in diese Schleife eintreten und anfangen zu schauen, was in dieser Schleife vor sich geht.
Also, jetzt wird es eine Auswahl aus meinen Anmietungen machen und ich kann mit der Maus über den Kerl fahren und schauen, er ist zwei, zwei ist größer als eins, also wird es wahrscheinlich den nächsten Teil dieses Codes machen. Mit anderen Worten, es wurde etwas gefunden. Ich werde einfach weitermachen und das laufen lassen. Ich möchte hier nicht alles durchgehen; Was ich Ihnen zeigen möchte, ist, wenn ein Debugger fertig ist, endet er genau wie ein normales Programm. Ich habe den Haltepunkt gesetzt. Als ich also run sagte, ging es einfach zurück zum nächsten Haltepunkt. Ich lasse es bis zum Ende laufen, denn ich möchte, dass Sie sehen, dass ein Debugger das Verhalten des Programms nicht ändert: Wenn es fertig ist, sollte ich genau die gleichen Ergebnisse erzielen, wenn ich es nicht ausgeführt hätte in einem Debugger.
Und damit setze ich die Demo aus und gehe zurück, weil wir sicherstellen wollen, dass wir Zeit für Fragen und Antworten haben. Und so werde ich es für Fragen und Antworten öffnen.
Eric Kavanagh: Alles klar, Robin, vielleicht eine Frage von dir und dann ein paar von Dez?
Robin Bloor: Ja, natürlich finde ich das faszinierend. Ich habe mit so etwas gearbeitet, aber ich habe noch nie mit so etwas in der Datenbank gearbeitet. Können Sie mir eine Vorstellung davon geben, wofür die Benutzer den Profiler verwenden? Weil es so aussieht, als würden sie sich mit Leistungsproblemen befassen - weil ich vermute, dass sie es sind -, hilft es Ihnen zu unterscheiden, wann eine Datenbank Zeit braucht und wann ein Code Zeit braucht?
Bert Scalzo: Weißt du, das ist eine fantastische Frage. Angenommen, ich arbeite in Visual Basic und rufe in Visual Basic Transact-SQL oder PL / SQL auf. Lassen Sie mich PL / SQL ausführen, da Oracle mit den Microsoft-Tools nicht immer gut funktioniert. Möglicherweise erstelle ich ein Profil für meinen Visual Basic-Code, und das Profil dort lautet möglicherweise: „Hey, ich habe diese gespeicherte Prozedur aufgerufen und es hat zu lange gedauert.“ Dann kann ich die gespeicherte Prozedur aufrufen und ein Datenbankprofil für die gespeicherte Prozedur erstellen Gehen Sie wie folgt vor und sagen Sie: "OK, von den 100 Aussagen, die hier enthalten sind, sind hier die fünf, die das Problem verursacht haben." Daher müssen Sie möglicherweise ein Tag-Team erstellen, in dem Sie mehrere Profiler verwenden müssen.
Die Idee ist, dass ein Datenbankprofil Ihnen helfen kann, die Nadel im Heuhaufen zu finden, auf der tatsächlich die Anweisungen stehen, bei denen Sie ein Problem haben, wenn Ihnen jemals mitgeteilt wird, dass das Leistungsproblem in Ihrer Datenbank vorliegt. Ich sage Ihnen noch etwas, was beim Profiling aufgetaucht ist: Wenn Sie einen Code haben, der millionenfach aufgerufen wird, aber von den millionenfachen Aufrufen jeweils nur eine Mikrosekunde benötigt, wird das vom Profiler millionenfach aufgerufen, das Ding lief für so viele Zeiteinheiten. Der Code ist zwar sehr effizient, aber Sie könnten nachsehen und sagen: „Oh, wir rufen diesen Code viel zu oft auf. Vielleicht sollten wir es nur ab und zu aufrufen, anstatt jedes Mal, wenn wir eine Aufzeichnung bearbeiten. “Oder so. Und so können Sie tatsächlich feststellen, wo es effizienten Code gibt, der einfach zu oft aufgerufen wird, und das ist tatsächlich ein Leistungsproblem.
Robin Bloor: Ja, das ist wunderbar. Ich habe das noch nie gemacht. Sie sehen natürlich, als ich Datenbankprobleme hatte, war es so, als würde ich mich auf die eine oder andere Weise entweder mit Datenbank oder mit Code befassen; Ich könnte nie mit beiden gleichzeitig fertig werden. Aber auch hier habe ich nichts getan. Ich war noch nie an der Erstellung von Anwendungen beteiligt, in denen Prozeduren gespeichert waren. Ich glaube, ich habe nie Probleme bekommen, die mich in den Wahnsinn getrieben haben, die Idee, dass Sie würde den Code auf eine Datenbank und ein Programm aufteilen. Aber tun Sie alles - ich gehe davon aus, dass die Antwort ja lautet, aber dies ist Teil einer Aktivität des Entwicklungsteams, wenn Sie auf die eine oder andere Weise versuchen, etwas zu reparieren, das kaputt ist, oder vielleicht versuchen, etwas Neues zu bringen Anwendung zusammen. Aber passt das alles zu all den anderen Komponenten, die ich in der Umgebung erwarten würde? Kann ich damit rechnen, dass ich dies mit all meinen Testpaketen und all den anderen Dingen, die ich machen würde, und mit meinen Projektmanagement-Dingen zusammenschneiden kann?
Bert Scalzo: Ja, es kann Teil jedes strukturierten Prozesses werden, um Ihre Programmier- oder Entwicklungsbemühungen auszuführen. Und es ist lustig, letzte Woche hatte ich einen Kunden, der eine Webanwendung erstellte, und seine Datenbank war historisch gesehen klein, und die Tatsache, dass sie keine sehr guten Programmierer waren, hat sie nie verletzt. Nun, ihre Datenbank ist im Laufe der Jahre gewachsen, und jetzt dauert es auf einer Webseite 20 Sekunden, bis Sie sagen: „Melde dich an und gib mir Daten, die ich sehen möchte“, und wann der Bildschirm tatsächlich angezeigt wird ein Leistungsproblem. Und sie wussten, dass das Problem weder in Java noch an anderen Orten auftrat. Aber sie hatten Tausende von gespeicherten Prozeduren und mussten daher mit der Profilerstellung der gespeicherten Prozeduren beginnen, um herauszufinden, warum es 20 Sekunden dauert, bis diese Webseite angezeigt wird. Und wir fanden tatsächlich heraus, dass sie eine kartesische Beteiligung an einer ihrer ausgewählten Aussagen hatten und es nicht wussten.
Robin Bloor: Wow.
Bert Scalzo: Aber irgendjemand sagte einmal zu mir: "Nun, wie können sie eine kartesische Verbindung haben und es nicht wissen?" Und das wird wirklich schrecklich klingen. Manchmal gibt mir ein Programmierer, der mit SQL nicht sehr vertraut ist, so etwas wie einen kartesischen Join, aber dann gebe ich nur den ersten Datensatz zurück, damit ich weiß, dass ich etwas habe, und ich brauche nur den ersten. Und so merken sie nicht, dass sie gerade eine Milliarde Platten zurückgebracht oder eine Milliarde durchgesehen haben, weil sie die haben, an der sie interessiert waren.
Robin Bloor: Wow, ich weiß, so heißt das - na ja, so ging Dez vor, in Bezug auf Leute, die nicht so geschickt sind, wie sie vielleicht sein sollten, wissen Sie. Wenn Sie ein Programmierer sind, sollten Sie wissen, welche Auswirkungen die Ausgabe eines Befehls hat. Ich meine, es gibt wirklich keine Entschuldigung für diese Dummheit. Ich gehe auch davon aus, dass Sie auf die eine oder andere Weise nur sprachunabhängig sind, da sich alles auf die Datenbankseite konzentriert. Habe ich recht damit? Ist es genauso, was auch immer Sie auf der Codierungsseite verwenden?
Bert Scalzo: Natürlich können Sie dies in Fortran oder C oder C ++ tun. Tatsächlich können Sie dies bei einigen Unixen sogar für ihre Skriptsprachen tun. Sie bieten tatsächlich die gleichen Werkzeuge. Und dann möchte ich eine Sekunde zurückgehen für das, was Sie ohne Entschuldigung gesagt haben. Ich werde den Programmierern eine Pause geben, weil ich es nicht mag, Programmierer unter den Bus zu werfen. Das eigentliche Problem ist jedoch das akademische Umfeld, denn wenn Sie lernen, wie man ein Programmierer ist, lernen Sie, wie man nacheinander aufzeichnet. Ihnen wird nicht das Denken von Mengen beigebracht, und genau das funktioniert in Structured Query Language oder SQL mit Mengen. Deshalb haben wir die Vereinigung, die Überschneidung und den Minus-Operator. Und es ist manchmal sehr schwierig für jemanden, der noch nie an Sets gedacht hat, aufzuhören, die Verarbeitung von Aufzeichnungen auf einmal loszulassen und mit Sets zu arbeiten.
Robin Bloor: Ja, ich bin dabei. Ich verstehe, das ist ein Bildungsproblem. Ich denke, das ist eine rein erzieherische Angelegenheit. Ich denke, dass es für Programmierer selbstverständlich ist, prozedural zu denken. Und SQL ist nicht prozedural, sondern deklarativ. Sie sagen eigentlich nur: "Das ist, was ich will und es ist mir egal, wie Sie es tun", wissen Sie? Während bei Programmiersprachen häufig die Ärmel hochgekrempelt werden und Sie in die Minutien geraten, die Anzahl sogar zu verwalten, während Sie eine Schleife ausführen. Ich werde weitergeben an …
Bert Scalzo: Nein. OK, fahren Sie fort.
Ja, ich wollte sagen, dass Sie ein weiteres Beispiel angesprochen haben, dass ein Profiler gut geeignet ist, die einzelnen Verarbeitungsschritte zu erfassen. Manchmal kann ein Programmierer, der sich mit einer Satz-für-Satz-Logik auskennt, nicht herausfinden, wie man ein SQL-Programm ausführt. Nehmen wir an, er macht zwei FOR-Schleifen und führt im Grunde genommen einen Join durch, aber er tut dies auf der Clientseite. Also macht er den gleichen Effekt wie ein Join, aber er macht es selbst, und ein Profil würde das auffangen, weil Sie wahrscheinlich mehr Zeit für den manuellen Join aufwenden würden, als den Datenbankserver für Sie erledigen zu lassen.
Robin Bloor: Ja, das wäre eine Katastrophe. Ich meine, du würdest dich nur herumschlagen. Thrashing ist immer schlecht.
Wie auch immer, ich werde an Dez weitergeben; Ich bin sicher, er hat einige interessante Fragen.
Dez Blanchfield: Danke, ja, das tue ich. Ich werde mich mit Ihnen an den nicht werfenden Programmierern unter dem Bus beteiligen. Ich habe zu viele Jahre in meinem Leben damit verbracht, selbst ein Programmierer zu sein, auf jeder Ebene, wissen Sie, ob es so ist, wie Sie gesagt haben, auf der Kommandozeile der Unix-Maschine zu sitzen, und in einigen Fällen war ich sogar beteiligt in ein paar verschiedenen Ports von Unix von einer Hardware-Plattform zur anderen. Und Sie können sich vorstellen, welche Herausforderungen wir dort hatten. Die Realität ist jedoch, dass es für jeden Codierer und Scripter auf der Welt eine Ausstiegskarte gibt. Es ist eine Raketenwissenschaft, im wahrsten Sinne des Wortes, jedes Mal richtig genau zu schreiben, ist eine Raketenwissenschaft. Und berühmte Geschichten von Leuten wie Dennis Ritchie und Brian Kernahan, die unabhängig voneinander an einem Teil des Codes arbeiten und dann bei einem Kaffee zu einem Codeüberprüfungs-Chat auftauchen und herausfinden, dass sie genau denselben Teil des Codes in genau demselben Programm geschrieben haben. in genau der gleichen Weise. Und sie haben es in C getan. Aber dieses puristische Programmierniveau gibt es sehr selten.
Tatsache ist, dass es täglich nur 24 Stunden am Tag gibt, sieben Tage in der Woche, und wir müssen einfach alles erledigen. Wenn es also heutzutage nicht nur um traditionelle Programmierer, Datenbankadministratoren, Programmierer, Skripter, Systemadministratoren, Netzwerkadministratoren und Sicherheitspersonal geht, sondern um alles bis hin zur Seite der Bürgerdaten. Wir hören, jeder versucht nur, seinen Job zu machen. Und so denke ich, dass das Beste an dieser ganzen Sache ist, dass ich Ihre Demo geliebt habe, und ich habe das Mitnehmen geliebt, mit dem Sie uns vor einem Moment dort zurückgelassen haben, als Sie mit Robin darüber gesprochen haben, dass dies eine Besonderheit hat - vielleicht nicht so viel eine Nische - aber ein weiter Bereich, für den es gilt, was das Reparieren von Code, SQL und Datenbanken betrifft. Aber ich war wirklich aufgeregt zu hören, wie Sie sagten, Sie könnten ein Shell-Skript durchgehen und einige Probleme finden, denn Sie wissen, wir arbeiten heutzutage immer an den niedrigsten Kosten für alles.
Der Grund, warum Sie ein Hemd für 6 USD irgendwo kaufen können, ist, dass jemand ein System gebaut hat, das billig genug ist, um es tatsächlich herzustellen und zu versenden, logistisch zu liefern und zu verkaufen und im Einzelhandel zu verkaufen und Online-Zahlungen zu tätigen, um dieses Hemd für 6 USD zu erhalten. Und das passiert nicht, wenn die Leute 400.000 US-Dollar im Jahr verdienen, um Code auf perfekte Weise zu schreiben. Es ist nur die gesamte Entwicklung. Zu diesem Punkt möchte ich Sie bitten, uns einen tieferen Einblick zu gewähren. Er ist die Breite und Reichweite der Personen, die Sie derzeit sehen und die diese Art von Tools für die Profilerstellung einsetzen einen Code und suchen Sie nach Leistungsproblemen? Woher kommen sie ursprünglich historisch? Waren sie die großen Maschinenbauer? Und in Zukunft ist es richtig, dass immer mehr Unternehmen dieses Tool oder diese Tools implementieren, um Programmierern zu helfen, von denen sie wissen, wer gerade die Dinge erledigt, um die Arbeit zu erledigen und es aus der Tür holen? Und manchmal brauchen wir eine Ausstiegskarte? Habe ich Recht, wenn ich denke, dass wir uns historisch mehr auf Technik und Entwicklung konzentriert haben? Dass wir jetzt weniger, wie Robin sagte, akademischen Ansatz bekommen und es jetzt autodidaktisch ist, oder Code ausschneiden und einfügen oder einfach nur Dinge bauen lassen? Und passt das zu der Art von Leuten, die das Produkt jetzt auf den Markt bringen?
Bert Scalzo: Ja genau. Und ich gebe Ihnen ein ganz konkretes Beispiel: Wir wollen nur die Arbeit erledigen, weil die Geschäftsleute keine Perfektion wollen. Es ist wie bei einem computergestützten Schachspiel: Das Schachspiel sucht nicht nach der perfekten Antwort. Es wird nach einer Antwort gesucht, die in angemessener Zeit gut genug ist. So programmieren wir also. Aber was ich jetzt finde, ist, dass die meisten Leute anstatt zu sagen, sie wollen einen Profiler als Teil ihrer Unit-Tests - so würde ich es machen, weil ich es nicht als Zeitverschwendung betrachte - was passiert ist Jetzt, wo das später gemacht wird, manchmal während Integrationstests oder Stresstests, wenn wir Glück haben. Aber meistens ist es Teil einer Eskalation, in der etwas in Produktion gegangen ist, es lief eine Weile, vielleicht sogar jahrelang, und jetzt läuft es nicht gut, und jetzt werden wir es profilieren. Und das scheint jetzt das üblichere Szenario zu sein.
Dez Blanchfield: Ja, und ich denke, der Begriff „technische Schulden“ ist wahrscheinlich einer, mit dem Sie mehr als vertraut sind. Ich kenne Robin und bin es mit Sicherheit. Ich denke, in diesen Tagen ist das Konzept der technischen Verschuldung, insbesondere bei agilen Ansätzen zur Entwicklung und zum Systemaufbau, für mich eine sehr reale Sache, und wir berücksichtigen dies tatsächlich in Projekten. Ich weiß, ich meine, wir haben unsere eigenen Projekte wie das Media Lens und andere, in denen das Programmieren täglich stattfindet, und verschiedene Dinge in der Bloor-Gruppe. Und wenn wir etwas bauen, schauen wir uns das an, ich schaue es an und schaue immer unter dem Gesichtspunkt an, was es mich kosten wird, das jetzt zu reparieren kann und hol es da raus, und dann schau und schau, ob das Ding kaputt geht. Und erben Sie diese technische Schuld, von der ich weiß, dass ich sie später beheben muss.
Und ich meine, ich habe das in den letzten sieben Tagen getan: Ich habe ein paar Tools und Skripte geschrieben, ein paar Teile der Python-Sprache, und ich habe es im Mongo-Back-End implementiert und gemacht Sicher, es ist schön, sauber und sicher, aber es wird nur die Abfrage ausgeführt, die ich benötige. dort ist mein wahrer Schmerz. Und so entstehen Ihnen diese technischen Schulden, und ich denke, dies ist jetzt nicht nur eine gelegentliche Sache, ich denke, dies ist ein Teil der DNA der Entwicklung jetzt. Die Leute akzeptieren nur - nicht unaufrichtig - die technischen Schulden sind ein normaler Vorgang und sie müssen sie nur übernehmen. Hier entstehen Ihnen die technischen Schulden. Und ich denke, das Tolle an dem, was Sie uns in der Demo gezeigt haben, war, dass Sie buchstäblich ein Profil erstellen und beobachten können, wie lange etwas dauert, um zu laufen. Und das ist wahrscheinlich eines meiner Lieblingssachen. Ich habe tatsächlich Profilerstellungstools erstellt. Früher haben wir Tools in Sed, Lex und Orc erstellt, um unseren Code auszuführen und zu sehen, wo sich die Schleifen befanden, bevor Tools wie dieses verfügbar waren Wenn Sie Ihren eigenen Code überprüfen, können Sie gut damit umgehen, Ihren eigenen Code zu überprüfen. Aber das ist jetzt nicht der Fall. Gibt es in diesem Sinne ein bestimmtes Marktsegment, das dies mehr als jedes andere ausmacht? Wie eine Masse sehen -
Bert Scalzo: Oh ja, ich habe - ich werde eine Analogie für Sie zeichnen und Ihnen zeigen, dass Nicht-Programmierer das die ganze Zeit tun. Denn wenn ich jemals einen Debugger und eine Profilerstellungsklasse oder -sitzung unterrichte, frage ich die Leute: "OK, wie viele Leute hier gehen in Microsoft Word und verwenden absichtlich niemals die Rechtschreibprüfung?" Weil wir alle wissen, dass wir beim Schreiben von Dokumenten englische Fehler machen können, und daher jeder die Rechtschreibprüfung verwendet. Und ich sagte: „Wie kommt es, dass Sie den Debugger nicht verwenden, wenn Sie Text in Ihrer IDE wie Visual Basic schreiben? Es ist das Gleiche, es ist wie eine Rechtschreibprüfung. “
Dez Blanchfield: Ja, eigentlich ist das eine großartige Analogie. Ich hatte nicht wirklich darüber nachgedacht, ich muss zugeben, dass ich mit ein paar Werkzeugen, die ich benutze, tatsächlich etwas Ähnliches mache. Tatsächlich, ODF, ist mein Favorit bei Eclipse, einfach Code ausschneiden und einfügen und nach Dingen suchen, die sich sofort hervorheben, und feststellen, dass ich in einem Klassenanruf einen Tippfehler gemacht habe. Und, aber es ist jetzt interessant, mit dem Tool wie diesem können Sie es in Echtzeit machen, anstatt zurück zu kommen und es später anzusehen, was ein bisschen schön ist, es im Voraus zu erfassen. Aber ja, das ist eine großartige Analogie zum Einfügen von Text in ein Textverarbeitungsprogramm, denn es ist ein interessanter Weckruf, bei dem Sie nur feststellen, dass Sie Tippfehler oder sogar Grammatikfehler gemacht haben, oder?
Bert Scalzo: Genau.
Dez Blanchfield: Also, sehen Sie jetzt eher einen Aufwärtstrend? Ich meine, die letzte Frage von mir, bevor ich vielleicht zu unseren Fragen und Antworten für unsere Teilnehmer werfe. Wenn Sie eine Empfehlung zu diesem Ansatz abgeben würden - ich nehme an, dass dies rhetorisch ist -, ist es der Fall, dass Sie früh einsteigen und dies bereits während der Entwicklung implementieren, bevor Sie sich entwickeln? Oder ist es der Fall, dass Sie vorwiegend bauen, sich bewegen, etwas bauen, dann hereinkommen und es später profilieren? Ich vermute, es ist der Fall, dass Sie früh einsteigen und sicherstellen, dass Ihr Code im Voraus sauber ist. Oder ist es ein Fall, dass sie diesen Teil ihres Post-Deployments in Betracht ziehen sollten?
Bert Scalzo: Idealerweise würden sie das im Vorfeld tun, aber da sich jeder in der geschäftigen Welt befindet, in der er nur seine Aufgaben erledigen muss, tun sie dies in der Regel erst, wenn sie auf ein Leistungsproblem stoßen, das sie nicht lösen können Hinzufügen von mehr CPUs und Speicher zu einer virtuellen Maschine.
Dez Blanchfield: Ja. Also, eigentlich hast du etwas Interessantes erwähnt, wenn ich schnell kann? Sie haben bereits erwähnt, dass dies von überall ausgeführt werden kann und mit der Datenbank am Back-End gesprochen werden kann. Das passt also gut zu der Art von bimodalem Konzept, von dem wir jetzt sprechen, von On-Premise- / Off-Premise-Cloud, auch vom Aussehen der Dinge, am Ende des Tages, wenn es mit dem Back-End sprechen und sehen kann Dem Code ist das eigentlich egal, oder?
Bert Scalzo: Genau, Sie können dies in der Cloud ausführen.
Dez Blanchfield: Exzellent, denn ich denke, das ist der Weg in unsere neue mutige Welt. Also Eric. Ich werde mich jetzt wieder bei Ihnen melden und feststellen, dass wir hier ein paar Fragen haben. Ich möchte, dass unsere Teilnehmer immer noch bei uns bleiben, auch wenn wir die Stunde überschritten haben.
Eric Kavanagh: Ja, es gibt ein paar Leute da draußen, ich werde nur einen kurzen Kommentar machen: Bert, ich denke, dass die Metapher, die Sie zur Rechtschreibprüfung geben, ehrlich gesagt brillant ist. Das ist ehrlich gesagt ein oder zwei Blogs wert, da es eine gute Möglichkeit ist, den Kontext dessen zu bestimmen, was Sie tun, wie wertvoll es ist und wie es sich wirklich als Best Practice für die Verwendung eines Debuggers erweisen sollte regelmäßig, oder? Ich wette, du bekommst ein paar Köpfe zum Nicken, wenn du den rauswirfst, oder?
Bert Scalzo: Auf jeden Fall, weil ich ihnen sage: „Warum führe ich eine Rechtschreibprüfung für meine Dokumente durch? Ich möchte mich nicht für dumme Rechtschreibfehler schämen. “Nun, sie möchten sich nicht für dumme Codierungsfehler schämen!
Eric Kavanagh: Richtig. Ja in der Tat. Nun, Leute, wir haben hier eine Stunde und fünf Minuten durchgebrannt, ein großes Dankeschön an euch alle da draußen für eure Zeit und Aufmerksamkeit. Wir archivieren alle diese Web-Chats, Sie können jederzeit zurückkehren und sie überprüfen. Der beste Ort, um diese Links zu finden, ist wahrscheinlich techopedia.com. Deshalb werden wir dies hier zu dieser Liste hinzufügen.
Und damit verabschieden wir uns von Ihnen, Leute. Nochmals tolle Arbeit, Bert, danke an unsere Freunde von IDERA. Wir werden nächstes Mal mit dir reden, wir werden sogar nächste Woche mit dir reden. Sich kümmern! Tschüss.
