Wegbringen: Gastgeber Eric Kavanagh diskutierte mit Dr. Robin Bloor, Dez Blanchfield und IDERAs Bert Scalzo ü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, am Mittwoch ist es 4 Uhr Ost, und das heißt natürlich.
Robin Bloor: Ich 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. Es ist die Art von Dingen, die Sie sicherstellen möchten, dass sie im Hintergrund in Ihrem Unternehmen stattfinden, es sei denn, Sie sind die Person, die es tut. In diesem Fall möchten Sie sicherstellen, dass Sie es richtig machen. Da wurde über das Debuggen geredet. Niemand mag Fehler, niemand mag es, wenn die Software nicht mehr funktioniert - die Leute sind aufgebracht, die Benutzer unfreundlich. Das ist nicht gut. Wir sprachen also über "Schnelle Reaktion: Datenbank-Debugging und Profilerstellung zur Rettung".
Es gibt wirklich einen Punkt, der sich mit Ihnen befasst, 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?
Gut, hören Sie von Dr. Robin Bloor, dann unserem eigenen Dez Blanchfield aus Down Under und natürlich 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 mache nur eine Hintergrunddiskussion, damit wir ein umfassendes Bild davon bekommen, was los ist. Ich habe das lange gemacht, und ich war früher ein Programmierer, und ich war fast versucht mit dieser Präsentation zu beginnen, über die Idee von Open Source lyrisch zu werden, aber ich dachte, ich überlasse das jemand anderem.
Hier ist eine Liste berühmter Bugs, und die meisten davon landen auf der Top-Liste von anybodys, im Grunde genommen kosteten alle außer den letzten beiden 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 nicht sicher, ob es 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 Schäden in Höhe von 100 Millionen Dollar verursachte. 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. Das 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. Der - unser längster Ausfall im Jahr 1990 - ist unter dem Gesichtspunkt der Kosten für so etwas einfach nur interessant - AT & T war ungefähr neun Stunden außer Betrieb und kostete bei Ferngesprächen etwa 60 Millionen US-Dollar.
Und 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 das 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 nicht wirklich gut zugeordnet werden können. Und deswegen bekommt man das, was man Impedanzfehlanpassung nennt, und irgendjemand muss sich auf die eine oder andere Weise damit auseinandersetzen. Aber was passiert eigentlich, weil ein Modell, das Codierermodell und die Datenbank eines anderen Modells nicht besonders aufeinander abgestimmt sind. Es gibt Fehler, die einfach nicht passieren würden, wenn die Branche Dinge entwickelt hätte, die zusammenarbeiten, was ich sehr lustig finde. Wenn Sie also Hierarchien erhalten, kann es sich auf der Codiererseite um Typen, Ergebnismengen, eine schlechte API-Fähigkeit und eine Menge Dinge handeln, die lediglich 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 zu einem Programm hin und her 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 plötzlich darum gekümmert, dass Sie Funktionen in eine Datenbank einfügen, was natürlich bedeutete, dass die Funktionen für ein Die 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 vorgenommen haben, dass ich mich mit relationalen Datenbanken befasst habe. Es gibt wirklich eine Menge Code, der in gespeicherten Prozeduren gespeichert ist, die getrennt von dem Code behandelt werden sitzt in den anwendungen. 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 oder im Netzwerk und zu Leistungsproblemen aufgrund von Sperren kommen. Die Idee wäre, dass der Codierer sich nicht wirklich Gedanken über die Leistung machen müsste und die Datenbank tatsächlich eine einigermaßen gute Leistung erbringen würde. Es soll so gestaltet sein, dass der Codierer 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. Wie auch immer, das ist 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 jemals erlebt habe 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 gehe dran vorbei, halte durch.
Automatisierte Stimme: 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 in diesem Punkt 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 umfassendes Thema, dass ich mich auf zwei Schlüsselbereiche konzentrieren werde, insbesondere auf das Konzept dessen, was wir für einen Bug halten, aber für ein Programmierproblem. 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 das Erstellen von Profilen und das Schreiben von Code, 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 ist also, dass gegen den 9. Septemberth1945 hat ein Team an der Harvard University eine Maschine auseinander genommen, sie stießen auf etwas, das sie "Relais siebzig" nannten. Damals wurde die Programmierung im physischen Sinne durchgeführt, man wickelte Code um eine Platine, und so programmierte man effektiv die Maschine - und sie fanden, dass dieses Relais mit der Nummer siebzig etwas nicht stimmte, und es stellte sich heraus, dass der eigentliche Begriff „Käfer“ entstand, weil es sich buchstäblich um eine Motte handelte - angeblich war eine Motte zwischen einem Stück Kupferdraht eingeklemmt von einem Ort zum nächsten. 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 haben wir diese Terminologie verwendet, um mit Problemen umzugehen, entweder nicht so sehr als Codierungsprobleme in einem Programm, das nicht kompiliert wird, sondern als ein Programm, das nicht gut läuft. Und speziell wurde nicht profiliert, nur Dinge wie endlose Schleifen zu finden, die einfach nirgendwo hingehen.
Wir haben aber auch ein Szenario, und ich dachte, ich würde ein paar lustige Folien einbauen, bevor ich näher darauf eingehen würde. Hier ist der klassische Cartoon namens XKCD im Web, und der Cartoonist hat einige ziemlich lustige Ansichten über die Welt. Und diese über ein Kind namens "Little Bobby Tables", und angeblich nannten seine Eltern diesen kleinen Jungen (Robert); TROPFENTABELLE Schüler - und es heißt und heißt sozusagen "Hallo, das ist die Schule deiner Söhne, die Computerprobleme hat", und die Eltern antworten: "Oh je, hat er etwas kaputt gemacht?" Und der Lehrer sagt: "Nun, In gewisser Weise ", fragt der Lehrer," haben Sie Ihren Sohn Robert wirklich genannt? " DROP TABLE Students; -? “Und die Eltern sagen:„ Oh ja, kleine Bobby Tables, die wir ihn nennen. “Wie auch immer, sie sagen, sie haben jetzt die Aufzeichnungen der Studenten verloren, ich hoffe, Sie sind glücklich. Und die Antwort lautet: "Nun, Sie sollten Ihre Datenbankeingaben bereinigen und bereinigen." Und ich benutze dies oft, um über einige der Probleme zu sprechen, die wir beim Auffinden von Dingen im Code haben .
Eine andere lustige, ich weiß nicht, ob dies 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 das ist meiner Erfahrung nach meine erste - und das wird mich schrecklich altern, da bin ich mir sicher. Robin, Sie sind herzlich eingeladen, sich über mich lustig zu machen - aber ich komme aus der Vergangenheit, als ich 14 Jahre alt war, als ich am Ende der Stadt herumwanderte und in Neuseeland an die Tür eines Rechenzentrums namens „Data Com“ klopfte und fragte, ob In der Schule konnte ich Taschengeld verdienen, indem ich den späten Bus nach Hause brachte, ungefähr 25 km pro Tag pendelte, Papier und Bänder in Bandlaufwerke steckte und nur ein Generaladministrator war. 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 der Ausführung von Skripten und Batch-Jobs, die am Ende des Tages 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.
Tatsächlich war meine allererste Erfahrung auf einem Teletyp-Terminal, das tatsächlich physisch 132 Spalten hatte. Stellen Sie sich im Wesentlichen eine sehr alte Schreibmaschine vor, in der Papier gescrollt ist, da sie keine CRT-Röhre hatte. 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 der Einzeileneditor, der zu einer bestimmten Zeile und dann zur Zeile wechselt und sie dann wieder eingibt. 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 von der 3270-Terminalerfahrung in meiner Welt zu Digital Equipment VT220, wo man die Dinge auf dem Bildschirm sehen konnte, und wieder machten Sie genau das, was Sie getan haben Auf dem Papierband gab es ein Ed-Format, das nur auf einer CRT angezeigt wurde, aber Sie konnten es einfacher 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 ich keinen Buggy einführte Code.
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 verzerrt, um das zu werden. Und das bringt eine ganze Reihe von Problemen mit sich, wenn wir an zwei Aspekte denken: an die Codierung und an die DBA. Es ist sehr einfach, Fehler in Sachen schlechte Programmiertechniken, faulen Versuch, Code zu schreiben, mangelnde Erfahrung, das klassische Tiergefühl, 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ürzten sich alle darauf, was wir das Rennen als Null bezeichnen: Versuchen Sie, alles so billig und so schnell zu erledigen, dass wir ein Szenario haben, in dem wir keine schlecht bezahlten Mitarbeiter beschäftigen. Und ich meine das nicht auf unaufrichtige Weise, sondern stellte 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 viele Leute, die sich mit Entwicklung, Design und Datenbank befassen und nicht über jahrelange Erfahrung verfügen und nicht unbedingt die gleiche Ausbildung oder Unterstützung hatten. 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 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 einzustellen, warten Sie, bis Sie ein paar Amateure einstellen, die ein Problem verursachen, und Sie müssen Bereinigen Sie es. “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, um die Daten zu manipulieren. 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 ist 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 befindet sich eine Wiedergabe des Mandelbrot-Sets, mit dem ich sicher alle vertraut war. 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 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 und schlecht bezahlte Mitarbeiter, die dies versuchen hochbezahlte Mitarbeiter, 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, ich liebe es, das auszufü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, die Farben sind vertauscht, es soll ein schwarzer Hintergrund und Grün ein grüner Bildschirm sein, aber das kann man 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: Wenn Sie nicht über die richtigen Tools verfügen, wenn Sie nicht über die richtigen Plattformen und Umgebungen verfügen, um diese Dinge erfassen zu können, und wenn sie in Produktion gehen, haben Sie 100.000 Mitarbeiter, die alle auf ein System zugreifen Tag, oder Stunde oder Minute, sehr bald erleben Sie Tschernobyl, wo das große Eisen zu schmelzen beginnt und sich im Kern des Planeten vergräbt, weil dieses Stück Code niemals in Produktion gehen 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 Sie sagen: "Schauen Sie, das ist wirklich hübscher Code, aber lassen Sie sich von einem DBA helfen, diese strukturierte Abfrage richtig zu erstellen, denn ehrlich gesagt ist das nur böse." 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 die Werkzeuge haben, um die Datenbank zu überwachen, versuchen Sie einfach, innerhalb von drei bis fünf Minuten zu schmelzen, und rufen Sie zurück, was eine Zeile von ist.
Zusammenfassend hat mich mein gesamter Hintergrund in der Codierung gelehrt, dass man Menschen eine Waffe geben kann und wenn sie nicht aufpassen, werden sie sich in den Fuß schießen. Der Trick besteht darin, 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 abgeschlossen haben, Ihren Code überprüfen. Sie können Probleme durch Profiling des Codes finden. Sie können effektiv unbeabsichtigte Fehler finden, die Leistungsprobleme sind, und wie bereits erwähnt Es war einmal, Sie konnten es tun, indem Sie auf einen grünen Bildschirm blickten. 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 vor allem die Demo, die ich denke, die bald erhalten würde. Eric, ich komme wieder vorbei.
Eric Kavanagh: Okay, Bert, nimm es weg.
Bert Scalzo: OK 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 gehen, ist es eine Größenordnung lästiger und nicht trivial war ein wichtiges Zitat.
OKAY. Ich wollte mit der Programmierung des Verlaufs beginnen, weil ich oft Leute sehe, die nicht debuggen, die keinen Debugger verwenden, nur mit der Sprache programmieren, die sie verwenden, und oft sagen sie zu mir: 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 und die Art, in der wir uns befanden 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, denn das ist der einzige Weg, den Sie bekommen würden weg mit dieser Behauptung.
Das andere, was an dieser Grafik lustig ist, ist, dass Dez gerade einen Kommentar über Grace Hopper gemacht hat. Ich kannte Grace, 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." , und ich habe in allen Sprachen hier programmiert, einschließlich SNOBOL, von dem noch niemand zuvor gehört hat, es war eine CDC, Control Data Corporation, also denke ich, dass ich für diese Branche ein bisschen zu alt werde.
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 beschäftige mich also mit dem Debuggen und den verschiedenen 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, es zu tun, aber es zählt. Aber wir haben auch die berühmte Aussage: Sie schauen zu und die Leute geben tatsächlich Aussagen 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 benutzt, drücken Sie einen Knopf und es bleibt hängen Anweisungen in Ihrem Code für Sie und wenn Sie fertig sind, drücken Sie einen anderen Knopf und es entfernt sie. Denn so viele Leute debuggen.
Und wir debuggen aus zwei Gründen: Zunächst müssen wir Dinge finden, die unseren Code ineffektiv machen. Mit anderen Worten, in der Regel bedeutet dies, 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, ist es aus Effizienzgründen und das 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. Nun, ich mache darauf aufmerksam, weil ein Profiler wahrscheinlich besser für dieses zweite Szenario geeignet ist und sowohl über Debugger als auch über Profiler sprechen würde. Darüber hinaus gibt es dieses Konzept des Remote-Debuggens. Dies ist wichtig, da Sie häufig, 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, das tun, was als Remote-Debugging bezeichnet wird. Sie können es nicht realisieren, aber das ist, was passiert. Und dann ist es bei diesen Debuggern sehr üblich, Unterbrechungspunkte, Überwachungspunkte, schrittweise Übergänge und einige andere übliche Dinge zu haben, die ich gleich auf einem Bildschirm-Schnappschuss 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 ist besser, wenn ich Proben genommen habe. Theres kein Grund, jede einzelne Aussage zu fangen, weil einige Aussagen gerade so schnell laufen können, dass Sie sich nicht interessieren, was Sie wirklich versuchen zu sehen, ist, gut, die sind diejenigen, die immer und immer wieder auftauchen, weil sie zu lang laufen . 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 ist es unabhängig 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 und 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 vorher gesprochen haben, haben 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, sein Transact-SQL, sein SQL-99, sein SQL / PSM - für, glaube ich, sein 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 Sachen, die SQL fremd sind, sind jetzt Teil von SQL in diesen Sprachen. 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 T- tue. SQL oder PL / SQL - und Im-Speicherung von Objekten in der Datenbank, wahrscheinlich eine gespeicherte Prozedur oder gespeicherte Funktion. Es gibt aber auch Auslöser: Ein Auslöser ä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, aber es ist 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, also wie eine Bibliothek. 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-manuelle Debugging-Methode.
Und der Grund, warum ich dies anspreche, ist, dass Sie, wenn Sie dies von Hand versuchen, tatsächlich mehr Debugging-Code eingeben, um all diese Anweisungen einzufügen, als Sie es mit dem Code tun. Obwohl dies möglicherweise funktioniert und besser als gar nichts ist, ist dies eine sehr schwierige Methode zum Debuggen, insbesondere, da es 10 Stunden gedauert hat, bis dieses Ding ausgeführt wurde und sich in Zeile drei ein Problem befindet. 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 Anweisungen enthält, und versuchen, die Nadel im Heuhaufen zu finden. Auch dies ist besser als nichts, aber es wäre nicht der beste Weg, um 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 hat gerade eine Reihe von Anweisungen in dieser Ablaufverfolgungsdatei erhalten, und ich bin möglicherweise nicht in der Lage, dies zu durchsuchen und herauszufinden, was ich finden muss. Ich bin mir also 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 - nur nicht daran gedacht, sie hier mit 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 ist es nur zu sehen, ob ich mehrere Zeilen in der Tabelle mit dem gleichen 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 einige Ausgaben. Und was hier wichtig 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 zu diesem Zeitpunkt in dieser Variablen enthalten ist, 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 nachsehen, was passiert ist. Lass mich nachsehen, was passiert ist Ich mache das 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, also dort, wo sich mein Cursor gerade befindet - mit anderen Worten, ich bin gegangen und dort, wo ich gerade bin. Also, wenn ich sage, "Schritt nochmal", gehe ich zur nächsten Zeile. Jetzt sehen Sie direkt darunter den roten Punkt. Nun, das ist ein Haltepunkt, der besagt: „Hey, ich möchte nicht über diese Linien treten.“ Wenn ich nur über alles springen und zu dem roten Punkt gelangen möchte, kann ich den Run-Button drücken und von hier aus laufen Das Ende oder ein Haltepunkt, wenn Haltepunkte gesetzt sind. Dann wird es angehalten und ich kann das Steppen wiederholen. Und der Grund, warum dies alles wichtig und mächtig ist, ist, dass wenn ich das alles tue, sich das, was in der Mitte und sogar im unteren Bereich geschieht - aber am wichtigsten ist, in der Mitte - ändern wird und ich die Werte aus meinen Variablen sehen kann Wenn Sie meinen Call-Stack-Trace sehen, werden alle diese Informationen dort angezeigt, während ich durch den Code gehe, sodass ich tatsächlich sehen und fühlen und ein Verständnis dafür bekommen kann, was los ist und wie der Code zur Ausführungszeit tatsächlich funktioniert . Und normalerweise kann ich ein Problem finden, wenn es eines gibt oder wenn ich gut genug bin, um es zu fassen.
OK, jetzt werde ich über einen Profiler sprechen, und in diesem Fall ist dies ein Profiler, den ich durch einen Debugger sehen kann. Erinnern Sie sich, dass ich sagte, dass sie manchmal getrennt sind und manchmal zusammen sein können? In diesem Fall, und wieder, bin ich in Rapid SQL, und ich 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 also 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 Debugging vermischt sind. Was nun schön ist, 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 ausführt, und nachdem die Ausführung abgeschlossen ist, werden Diagramme angezeigt, die mir die Dinge erklären, damit ich sehe, dass ich eine Aussage habe, die so aussieht, als würde sie den größten Teil des Kuchens ausmachen Diagramm und wenn ich schaue, sehe ich in diesem Raster nach unten, Zeile 23, wieder die FOR-Schleife: Er nimmt die meiste Zeit in Anspruch, er ist tatsächlich das dunkelrote Kauen des gesamten Kreisdiagramms. Dies ist also eine andere Möglichkeit zum Erstellen von Profilen. Wir nennen das in unserem Tool "Code Analyst". Aber es ist im Grunde nur ein Profiler, der von einem Debugger getrennt ist. 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 weltbesten Code schreiben und eine Gehaltserhöhung erhalten wollen - das könnte unser Grund sein, aber das ist nicht der eigentliche Grund, warum Sie es tun - Sie haben dem Unternehmen versprochen, dass Sie etwas richtig machen würden, damit Ihr Programm effektiv wird. Dafür werden Sie den Debugger verwenden. Darüber hinaus Geschäftsendbenutzer; Sie sind nicht sehr geduldig: Sie wollen Ergebnisse, noch bevor sie die Taste drücken. Wir sollten ihre Gedanken lesen und alles sofort tun. Mit anderen Worten, es muss effizient sein. Dafür 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 einen solchen gesehen." sieht es aus, wenn es in Bewegung ist? Also, hier auf meinem Bildschirm starte ich 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, das ein Schritt nach innen ist, wird der Pfeil gerade bewegt, und wenn ich weiter drücke, wird der Pfeil weiterbewegt. 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 auf die gleiche Taste wie der Debugger abgebildet, das ist, was die Verwirrung verursacht. 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 in der Lage, diese Schleife auszuführen. Ich kann sehen, auf was alle meine Variablen eingestellt sind. Dies ist keine Überraschung, da ich sie alle auf initialisiert habe Null. Und jetzt kann ich in diese Schleife eintreten und nachsehen, was in dieser Schleife vor sich geht.
Also, jetzt wird es eine Auswahl aus meinen Anmietungen machen und ich kann mit der Maus über diesen 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 "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 in einem Debugger ausgeführt hätte.
Und damit werde ich die Demo aussetzen und zurückgehen, 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 klar, das finde ich natürlich 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? Betrachten sie - ich nehme an - Leistungsprobleme, 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. Nehmen wir an, ich arbeite in Visual Basic, und ich rufe in meinem 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 folgendermaßen vor und sagen Sie: "OK, von den 100 Aussagen, die sich hier befinden, 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 haben diesen Code viel zu oft aufgerufen. 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 nur 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 tat ich nichts - ich war noch nie an der Erstellung von Anwendungen beteiligt, in denen wir Prozeduren gespeichert hatten, also bin ich wohl nie auf Probleme gestoßen, die mich in den Wahnsinn getrieben haben Datenbank und ein Programm. Aber machen Sie es trotzdem - ich gehe davon aus, dass die Antworten ja lauten werden, aber dies ist Teil einer Aktivität des Entwicklungsteams, wenn Sie auf die eine oder andere Weise versuchen, einen Defekt zu beheben oder vielleicht eine neue Anwendung zusammenzubringen. 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 dessen 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: "Logge mich ein und gib mir ein paar Daten, die ich sehen soll", und wann der Bildschirm tatsächlich auftaucht ein Leistungsproblem. Und sie wussten, dass das Problem weder in Java noch an einem dieser anderen Orte 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: Beeindruckend.
Bert Scalzo: Aber irgendjemand sagte einmal zu mir: "Nun, wie können sie einen kartesischen Mitstreiter haben und es nicht wissen?" Und das klingt wirklich schrecklich. Manchmal macht ein Programmierer, der mit SQL nicht sehr vertraut ist, so etwas wie einen kartesischen Join, gibt mir aber nur den ersten Datensatz zurück, sodass ich weiß, dass ich etwas habe und nur den ersten brauche. Und so merken sie nicht, dass sie gerade eine Milliarde Platten zurückgebracht haben oder sie sehen sich eine Milliarde Platten an, weil sie die haben, an der sie interessiert sind.
Robin Bloor: Wow, ich weiß, das nennt man - nun, das ist es, worum es Dez ging, 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 genau das Gleiche, was auch immer Sie auf der Codierungsseite verwenden?
Bert Scalzo: Absolut, Sie können 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 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 nie an Sets gedacht hat, aufzuhören, sich von der rekordverarbeitenden Arbeit zu lösen und mit Sets zu arbeiten.
Robin Bloor: Ja, ich bin dabei. Ich verstehe, das ist ein Bildungsproblem. Ich denke, das ist völlig ein Bildungsproblem, ich denke, dass es für Programmierer selbstverständlich ist, prozedural zu denken. Und SQL ist nicht prozedural, sondern deklarativ. Sie sagen eigentlich nur: "Dies ist, was ich will und es ist mir egal, wie Sie es tun", wissen Sie? Während bei Programmiersprachen oft die Ärmel hoch und runter gerollt werden, um die Zählungen selbst zu verwalten, während Sie eine Schleife ausführen. Kranke Hand an -
Bert Scalzo: OK, mach weiter.
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. Er tut den gleichen Effekt wie ein Join, aber er tut ihn selbst, und ein Profil würde dies auffangen, da 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. Prügel sind immer schlimm.
Wie auch immer, ich gehe weiter zu Dez; Ich bin sicher, er hat einige interessante Fragen.
Dez Blanchfield: Danke, ja, das tue ich. Ich werde mich Ihnen in den nicht werfenden Programmierern unter dem Bus anschließen. Ich habe zu viele Jahre in meinem Leben damit verbracht, selbst ein Programmierer zu sein, auf jeder Ebene, wissen Sie, ob es, wie Sie sagten, auf der Kommandozeile der Unix-Maschine saß, und in einigen Fällen war ich sogar an einem beteiligt paar verschiedene Ports von Unix von einer Hardware-Plattform zur anderen. Und Sie können sich vorstellen, welche Herausforderungen wir dort hatten. In Wirklichkeit handelt es sich jedoch um die Ausstiegskarte für jeden Codierer und Scripter auf der Welt. 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 an einem Teil des Codes arbeiten und dann bei einem Kaffee zu einem Code-Review-Chat auftauchen und herausfinden, dass sie genau denselben Teil des Codes in genau demselben Programm geschrieben haben in 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 gelassen 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, weil Sie wissen, dass heutzutage immer zu den niedrigsten Kosten gearbeitet wurde.
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. Also, dieser Punkt, denke ich, eine der Fragen, die Sie wirklich lieben, um uns einen Einblick zu geben, ist die Breite und Reichweite der Leute, die Sie derzeit sehen, und die diese Art von Tools einsetzen, um einen Code zu profilieren und zu schauen für Leistungsprobleme? 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? Bekamen wir jetzt weniger, wie Robin sagte, akademischen Ansatz, und jetzt ist es autodidaktischer oder Code zum Ausschneiden und Einfügen, oder lassen Sie einfach Dinge bauen? 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 jetzt passiert, ist, dass das gemacht wird später, manchmal während des Integrationstests oder des Stresstests, wenn man Glück hat. Aber die meiste Zeit war es Teil einer Eskalation, in der irgendetwas in Produktion ging, es lief eine Weile, vielleicht sogar Jahre lang, und jetzt läuft es nicht gut und jetzt sieht man es gut. 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 gesamten Bloor-Gruppe. Und wann immer wir etwas bauten, schauten wir es uns an, ich schaute es an und schaute immer unter dem Gesichtspunkt an, was es mich kosten würde, das jetzt zu reparieren, im Gegensatz dazu, ob ich es einfach in die Dose bekommen kann und Holen Sie es da raus und beobachten Sie dann, ob diese Dinge brechen werden. 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, um sicherzustellen, dass es schön, sauber und sicher ist. Aber es wird nur die Abfrage ausgeführt, die ich ausführen muss, da ich weiß, dass diese Funktion zum Arbeiten und zum Erreichen des größeren Puzzles erforderlich ist. das ist, wo mein wirklicher Schmerz ist. 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. Es ist der Ort, an dem die technischen Schulden anfallen. 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, bis es ausgeführt wird. Und das ist wahrscheinlich eines meiner Lieblingssachen. Ich habe tatsächlich Profilerstellungstools erstellt - wir haben Tools in Sed und Lex und Orc erstellt, um unseren Code auszuführen und zu sehen, wo sich die Schleifen befanden, bevor Tools wie dieses verfügbar waren - und wann Sie Code erstellt haben, um Ihren eigenen Code zu überprüfen Sie werden sehr gut darin, Ihren eigenen Code nicht überprüfen zu müssen. 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. 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?" Wir alle wissen, dass wir englische Fehler machen können, und deshalb verwendet jeder die Rechtschreibprüfung. Und ich sagte: „Nun, wie kommt es, dass Sie, wenn Sie in Ihrer IDE wie Visual Basic schreiben, den Debugger nicht verwenden? 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 nett ist, es im Voraus zu erfassen. Aber ja, das ist eine großartige Analogie zum Einfügen 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 mehr von einem Aufwärtstrend, ich denke, ich meine, die letzte Frage von mir, bevor ich vielleicht zu unseren Fragen und Antworten für unsere Teilnehmer werfe. Wenn Sie eine Art Empfehlung zu diesem Ansatz geben würden - ich nehme an, dies ist rhetorisch -, ist es der Fall, dass Sie früh einsteigen und dies implementieren, während Sie sich entwickeln, 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 Ihre Codes im Voraus sauber sind. Oder ist es ein Fall, dass sie diesen Teil ihres Post-Deployments in Betracht ziehen sollten?
Bert Scalzo: Im Idealfall tun sie dies im Voraus, 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 durch Hinzufügen von mehr CPUs und Speicher lösen können 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 egal, oder?
Bert Scalzo: Genau, ja, Sie können dies in der Cloud ausführen.
Dez Blanchfield: Hervorragend, denn ich denke, das ist eine Richtung, in die sich unsere neue mutige Welt bewegt. Also Eric. Ich werde jetzt zu Ihnen zurückwerfen und sehen, dass wir hier ein paar Fragen haben, und ich möchte, dass unsere Teilnehmer immer noch bei uns bleiben, obwohl wir die Stunde überschritten haben.
Eric Kavanagh: Ja, es gibt ein paar Leute da draußen, ich mache nur einen kurzen Kommentar: 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, denn es ist eine gute Möglichkeit, den Überblick darüber zu behalten, was Sie tun, wie wertvoll es ist und wie es sich wirklich als bewährte Methode für die Verwendung eines Debuggers in einem Blog erweisen sollte regelmäßig, oder? Ich wette, du bekommst ein paar Köpfe zum Nicken, wenn du den rauswirfst, oder?
Bert Scalzo: Ich sage ihnen auf jeden Fall: „Warum führe ich eine Rechtschreibprüfung für meine Dokumente durch? Ich möchte nicht durch dumme Rechtschreibfehler in Verlegenheit gebracht werden. “Nun, sie möchten nicht durch dumme Codierungsfehler in Verlegenheit gebracht werden!
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. Fügen Sie dies also hier zu dieser Liste hinzu.
Und damit würden wir uns von Ihnen verabschieden, Leute. Nochmals tolle Arbeit, Bert, danke an unsere Freunde von IDERA. Also, bis zum nächsten Mal, bis zur nächsten Woche. Sich kümmern! Tschüss.