Fehlersuche.

Hallo und herzlich willkommen zu einer neuen Folge von unserem Webcafé.

Und heute nehmen wir ein bisschen später auf als sonst, weil Kay noch in Reviews festhing. Aber Kay, ich freue mich sehr, dass du auch heute wieder dabei bist. Ja, hallo, ich freue mich auch. Es hat zwei Vorteile und einen Nachteil, aber darüber können wir gleich sprechen.

Kay, wir haben das erste Mal Feedback für einen Podcast bekommen, und zwar von Leuten, die wir nicht kennen. Eine E-Mail-Zuschrift. Und das hat mich natürlich sehr gefreut. Und Inhalt der ganzen Geschichte war, dass der Person das ganz gut gefiel. Will ich jetzt gar nicht näher darauf eingehen, aber er hat unter anderem auch geschrieben, dass ihm die Regelmäßigkeit so ein bisschen fehlt. Und wir sagen ja immer, das ist unser wöchentlicher Podcast. So habe ich es sonst immer eingeleitet. Heute habe ich es extra nicht gemacht. Ja, wir sind nicht so richtig wöchentlich. Das ist meiner Meinung nach so ein bisschen dem geschuldet, dass wir das ja in unseren Arbeitsalltag integrieren müssen.

Ja, und dass dann manchmal mehr oder weniger gut passt. Und jetzt müssen wir mal gucken, ob wir vielleicht eine gewisse Regelmäßigkeit reinkriegen. Also wir haben es jetzt auf jeden Fall nochmal bei uns beiden höher priorisiert. Aber wie du es schon sagst, allein die Vorbereitungen irgendwie in den Arbeitsalltag reinquetschen und dann die Aufnahme und sowas, das ist nicht ganz so einfach. Da geht dann doch pro Woche relativ viel Zeit für drauf. Der eine oder andere hat sich auch schon Sorgen gemacht, dass wir den Podcast nicht weitermachen. Aber da müsst ihr nicht besorgt sein. Wir haben noch viele Themen in der Pipeline und wollen die auch gerne abarbeiten.

Und vielleicht als Mini-Entschuldigung, unser Mensch, der unseren Podcast cuttet, der war jetzt längere Zeit nicht da.

Und das hat das Ganze auch nochmal so ein bisschen verzögert. Aber da sind wir wieder mit einer neuen Folge. Und Kay, nicht nur fremde Leute, die uns geschrieben haben, haben wir den Podcast gehört, sondern auch fremde Leute, die sich bei uns beworben haben. Wir haben nämlich tatsächlich den ersten Bewerber gehabt, der sich vorher auch unseren Podcast mit dem Thema der Bewerbung angehört hat. Und ich kann auch sagen, man hat es auch so ein bisschen gehört im Bewerbungsgespräch. Also jetzt gar nicht negativ gemeint, aber ja, das war schon ganz gut. Und auch ein cooler Anstiegspunkt, darüber zu sprechen.

Ende vom Lied. Wir haben denjenigen dann jetzt auch als Praktikant erstmal eingestellt und freuen uns sehr auf die Zusammenarbeit. Also ich meine, das ist ja letzten Endes das, was wir gehofft haben, was passiert, dass die Leute sich das auch anhören. Und dann müssen wir jetzt auch mit den Konsequenzen leben. Und dann kommt vielleicht auch bald der erste Kunde und sagt, ja hier, Ihre Qualität, was ist denn damit? Oder so. Aber ich freue mich auf jeden Fall auch. Das heißt ja, dass wir das nicht nur für uns beide hier im stillen Kämmerlein machen. Genau. Ja, das ist ein Wahnsinnsgefühl, wenn man das erste Mal von jemandem hört, den man vorher nicht kannte

und dann merkt, oh, es kommt wirklich irgendwo an und man bläst es nicht so ins schwarze Nichts einfach raus. Nicht zuletzt deswegen wollen wir das jetzt auch wieder regelmäßigerer machen und haben es in unserem Projekt-Tool mit einem kleinen, roten, dringend Fähnchen markiert. Ja, mich hat es auch mehr motiviert, als ich gedacht hätte. Ja, wunderbar. Kein, bevor es losgeht, muss ich aber erst mal wissen, ob du überhaupt getränketechnisch ausgestattet bist. Ja, so, pass auf. Gerade habe ich das angedeutet mit der späten Uhrzeit. Ein Nachteil ist, ich bin jetzt vielleicht schon ein bisschen müde.

Das kann man heute im Verlauf der Podcast-Folge sehen, ob es Konsequenzen hat oder nicht. Die zwei Vorteile sind A, ich bin schon warm geredet und B, vor allem, ich habe einen guten Grund, Kaffee zu trinken. Und jetzt habe ich hier einen Cappuccino stehen, habe ich mir gerade frisch gezapft und jetzt habe ich es mal extra rausgesucht mit der Keiler Espresso-Bohne von der Kaffeemanufaktur aus Bad Wildbad.

Und die wird hier beschrieben mit einem Bouquet, das ist Karamell, Nuss und Bittermandel und einem Körper, der ist vollmundig, samt, weicht und tolle Crema. Boah, Kay, ich werde sowas für neidisch. Ja, das Ganze getoppt mit einem wunderschönen Kaffeeschaum, der jetzt so steht. Ich lese ihn mal kurz für dich und für euch, so im Sinne von Teeblättern. Und ich würde dir eine Zukunft vorhersagen. Es ist ein Schmetterling, würde ich sagen, oder eine Tulpe vielleicht. Der steht für einen rosigen Podcast heute. Also so viel zu mir. Ich hoffe jetzt, kann ich mal mithalten mit deinen tollen Präsentationen.

Ich glaube, so blumig kann ich mein Getränk heute gar nicht unbedingt erklären. Ich war jetzt eine Woche in Italien, unten in Apulien, was mir sehr gut gefallen hat. Und da muss man schon aufpassen, dass man nicht zum Kaffeetrinker umschwenkt vom Tee. Damit das nicht passiert, habe ich heute aber einen Tee mitgebracht, den ich vor zwei oder drei Folgen schon angeteasert habe. Da hatte ich nämlich einen Grey das erste Mal dabei. Und zwar war das ein Grey mit einem künstlichen Aroma. Das hat mich irgendwie nicht losgelassen, dass ich nochmal einen Earl Grey mit echtem Bergamottoöl kaufe. Und das ist dann tatsächlich auch passiert.

Und da habe ich so einen Bio-Ell Grey genommen von einem bekannten Teehaus. Und ich muss sagen, der gefällt mir nochmal eine ganze Ecke besser. Hätte ich gar nicht gedacht. Das künstliche Aroma, das ist so sehr, sehr intensiv und prägnant, sehr zitronig. Und dieses echte Bergamottoöl, was jetzt hier drin ist, das ist so sehr dezent. Also es ist so ein sehr runder Schwarztee, wo nur so ganz leicht im Hintergrund eigentlich diese Bergamotto zu schmecken ist. Finde ich ganz fantastisch. Kann ich nur weiterempfehlen. Den gibt es heute bei mir. Ich sehe schon, der Trick, damit du jetzt jedes Mal was Neues erzählen kannst, ist immer Earl Grey mit Geschmack XY zu trinken.

Und irgendwann sind wir dann eben bei Geschmack Currywurst angekommen oder so. Ja, ich glaube, Earl Grey gibt es ja nur im Bergamotto. Aber Schwarztees aromatisiert werden wir nicht ausgehen. Fantastisch. Kay, wir haben ja über unsere Tools gesprochen in einer der letzten Folgen. Und da haben wir auch ClickUp als unser Projektmanagement-Tool erwähnt. Und jetzt bist du ClickUp-Power-User. Kay, wie stolz bist du auf dich? Und was heißt das? Es ist fantastisch. Ich habe keine Ahnung. Ich habe irgendwann eines Morgens die E-Mail im Postfach gehabt, dass ich zu den Top, weiß ich nicht mehr, x Prozent der ClickUp-Nutzer gehöre.

Was, glaube ich, auch nicht verwunderlich ist, wenn man Projektmanager in zwei mindestens mal ClickUp-Instanzen ist. Und ich habe mir richtig was drauf eingebildet. Also sonst ist ja Autorität immer schwer zu fassen. Aber durch so einen blauen Haken, da fühle ich mich jetzt, wie als hätte ich so einen Twitter-Haken. Bei Twitch gibt es auch so einen verifiziert-Haken. Ja, genau. Und jetzt also, als hätte es nicht mehr gebraucht, um meine Autorität zu untermauern. Aber kannst du dadurch mehr machen als vorher? Ich glaube, ich habe es ehrlicherweise schon wieder vergessen. Ich wollte nur dieses Badge haben.

Aber ich glaube, ich kann jetzt auch an irgendwie so Workshops teilnehmen oder an so Meetups, wenn ich wollte. Okay, ist ja wild. Ja, aber es sind ja wirklich nur ein sehr kleiner Teil der ClickUp-User. Also ich glaube, Top 1, 2, 3 Prozent oder sowas, die da reinrutschen. Genug, um hier mächtig was drauf einzubilden, auf jeden Fall. Gut, wir wollen uns eigentlich mit Reviews beschäftigen und da ganz im Speziellen mit Fehlersuche, Fehlerbehebung, wie wir Fehlern auf die Schliche kommen.

Und soweit du mir das im Vorspräch gesagt hast, hast du ein Praxisbeispiel mitgebracht aus einem Merge Request. Nicht aus einem Merge Request, sondern einfach einen Bug, der von einem Kunde an uns herangetragen wurde. Und nachdem ich den dann so gelöst hatte, ist mir aufgefallen, ach, das ist doch eigentlich ein ganz gutes Beispiel, um mal im Rahmen von so einer Folge zu erklären, wie ich konkret an so einen Bug-Report dran gehe.

Oder wie ich mich dann auf Fehlersuche in den Code begebe. Das wird jetzt heute eine kleine Herausforderung, das möglichst plastisch zu beschreiben. Ich fuchtel hier schon ganz wild in der Gegend herum. Aber genau, ich möchte anhand von so einem konkreten Beispiel mal durchgehen, wie die einzelnen Schritte sind, den Bug zu finden und den Bug zu lösen,

um dann daraus vielleicht allgemeingültige Tipps abzuleiten, wie man selber vorgehen kann, wenn man so ein Problem hat.

Sehr cool. Ich habe ja heute schon sehr viel geredet und halte mich jetzt ein bisschen zurück. Ich habe nämlich eigentlich keine Notizen hier auf meinem Blog, außer, dass ich mir so ein paar Sachen aufgeschrieben habe, die ich bei der Fehlersuche so ganz hilfreich finde, also so Mini-Tweaks und Ideen, wie man im Browser noch schneller Fehler finden kann.

Mal gucken, ob das passt. Dann schmeiße ich dir eine. Aber ansonsten überlasse ich dir erstmal die Bühne. Okay. Also ich versuche kurz, das Problem zu beschreiben. Wir haben so eine Frontend-Anwendung, in der wir eine Karte zeichnen im Browser. Wir benutzen dafür Open Layers. Das ist ein kostenloses Tool. Man kann es ein bisschen vergleichen wie so eine Google Maps Karte oder Apple Maps Karte. Und dann zeichnen wir auf dieser Karte in verschiedenen Layern verschiedene Dinge, also Marker auf der Karte ein. Also hier sind Ampeln oder hier sind Schilder oder sowas. Und jetzt hatten wir den Bug, dass wenn man diese Karte geöffnet hat, initial, dass nichts auf der Karte eingezeichnet wurde.

Also man sah den Hintergrund, aber eben die Ampeln und die kleinen Icons für Schilder und sonst irgendwas waren nicht zu sehen initial.

Man musste die Karte erst einmal bewegen oder irgendwie damit interagieren. Dann wurden sie geladen. Grundsätzlich bei Fehlern ist es so, klingt jetzt trivial, aber so ist es. Fehler sind eine Verkettung von ungünstigen Zuständen. Oder besser gesagt, bei einem Fehler hat man üblicherweise eine Art von Input, von dem man weiß, dass es stimmt. Dann passieren magische Dinge im Code und am Ende kommt nicht das Ergebnis, was man gerne haben möchte.

Und das, was man bei der Fehlersuche eigentlich macht, ist eben dieser Kette entlang zu gehen, um den Fehler tatsächlich zu finden.

Üblicherweise weiß man vom Ausgang, wie er funktionieren soll. Und an irgendeiner Stelle weiß man auch vom Ursprung, wie es sein soll. In unserem Fall, anhand dieses Beispiels, hatten wir eben das Ergebnis, dass der Browser nicht funktioniert hat. Das war das eine Ende der Kette. Und das andere Ende der Kette ist, wir haben hier irgendwo im Quellcode eine Stelle, an der diese Karte konstruiert wird.

Und der einfache Trick, wenn ich das mal so sagen darf, bei der Fehlersuche, ist diese beiden Punkte zu erkennen und die einzelnen Kettenstränge, die von A nach B führen. Das sind dann Funktionen, die aufgerufen werden, Variablen, die erstellt werden, irgendwelche Zusammenhänge, externe Pakete oder sowas. Aber im Wesentlichen ist es eine relativ lineare Kette, die von einem Input oder von einem Zustand, von dem ich weiß, dass er korrekt ist,

zu einem Ergebnis führt, von dem ich weiß, dass es nicht korrekt ist. Zusammenfassend für diese Folge, der Trick ist einfach, Schritt für Schritt für Schritt diese Kette entlang zu gehen und zu schauen, ist hier der Zustand noch so, wie es haben soll oder ist es hier schon nicht mehr so. Und wenn es nicht mehr so ist, dann gehe ich ein Kettenglied wieder zurück und schaue, ob es da so ist. Und wenn es dann immer noch so ist, dann wieder ein Kettenglied zurück. Und wenn ich jetzt mal eine wilde Vermutung anstellen dürfte und in meine Vergangenheit zurückgucke, da war das ja immer so, dass man zum Beispiel im PHP dann ganz viele Echos reingebracht hat

oder meistens waren es eher Dice mit irgendeiner Ausgabe oder einem Echo mit einem Exit. Also, dass man den Code irgendwo abgebrochen hat und dann geguckt hat, ist der Zustand jetzt hier noch korrekt an der Stelle. Dann musste man das Ganze wieder auf den Server hochladen. Dann hat das nicht das gewünschte Ergebnis gebracht. Dann hat man das wieder verändert und nochmal hochgeladen. Und am Ende hat man dann vielleicht mal rausgefunden, wo der Fehler war. Und im JavaScript kann man sich ja durch diesen Debugger so ein bisschen hangeln im Browser oder eben auch mit Console-Logs arbeiten. Und ich vermute, dass du uns heute noch ein paar Tipps an der Hand geben wirst,

wie man sich da eben nicht so kleinschrittig durchhangeln muss, sondern ein bisschen effizienter ist. Ja, es kommt ein bisschen darauf an. Also, am wichtigsten ist erstmal zu erkennen, dass eben ein Bug genau diese Verkettung ist und dass es sehr, sehr wichtig ist, bei diesen Ketten auf jedes einzelne Glied zu achten. Selbst wenn da irgendeine Funktion ist, von der man eigentlich total sicher ist, ja, die habe ich gestern erst geschrieben, die hat nur drei Zeilen, die ist total fehlerfrei, da gucke ich gar nicht erst rein. Genau das sind solche Stellen, wo sich so Bugs gerne verstecken. Also, meine wichtigste Empfehlung ist, wirklich Schritt für Schritt diese Kette durchgehen.

Und so eine Kette hat zwei Seiten. Das heißt, einen Anfangszustand, von dem ich weiß, dass er richtig ist, und einen Endzustand, von dem ich weiß, dass er falsch ist. Und das Vorgehen ist jetzt, an einer der beiden Seiten zu starten, ist mehr oder weniger egal wo, und dann Glied für Glied die Kette zurückzugehen, wenn man sich das mal so bildlich vorstellt. Auf der einen Seite ist der Startpunkt, auf der anderen Seite der Endpunkt. Wirklich Glied für Glied, entweder von links nach rechts oder von rechts nach links. Es bringt nichts, wenn ich mir erst rechts was angucke und dann links oder wieder rechts,

und springe ich so auf der Kette hin und her, dann geht mir schnell was verloren. Und an irgendeiner Stelle stelle ich dann fest, ah, hier ist genau dieser Spalt zwischen das erwarte ich und das passiert aber in der Realität und ist dann nicht erwünscht. Und das ist gerade schon gesagt, diese Kettenglieder durchgehen, da gibt es mehrere Strategien für. Der klassischste Weg ist einfach so eine Debug-Ausgabe zu nehmen, die jede Programmiensprache mit eingebastelt hat. Also in JavaScript jetzt zum Beispiel mal so ein Console-Log überall reinstreuen und dann kann man sich schön in der Konsolen-Ausgabe anschauen.

Aha, hier hatte die Variable noch diesen Wert und hier diesen Wert und hier diesen Wert und dann hat sie auf einmal einen anderen Wert. So kommt man dann aus der Richtung da ran. Darf ich da schon mal zwei Tipps einwerfen? Ja, gerne. Was nämlich ganz viele nicht wissen, ist, dass es nicht nur Console-Log gibt, also Console.Log, sondern es gibt auch andere Dinge wie zum Beispiel Console.Error. Die markieren dir das jetzt nur anders farbig, sodass man sieht, dass da ein Fehler passiert ist. Aber was zum Beispiel spannender ist, ist sowas wie Console.Table, der dir aus einem Objekt, wenn das eine gewisse Struktur hat, direkt eine Tabelle ausgeben kann,

die man viel besser dann natürlich erkennen kann, was der Inhalt davon ist. Oder es gibt auch so Sachen wie Console.Time und Console.TimeEnd. Und damit kann man sich Zeiten angucken. Das ist ganz oft, wenn irgendwo ein Performance-Problem ist. Dann kann man damit gut arbeiten, dass man wirklich rausfinden kann, an welchen Stellen viel Zeit ins Land geht. Und was ich persönlich ein Highlight finde, ist, dass man nicht nur diese Konsolenbefehle nutzen kann, sondern du kannst auch Debugger schreiben. Also du kannst einfach in deinem Code wirklich Debugger, Doppel oder Semikolon, schreiben. Und dann startet an der Stelle, wo der Code ausgeführt wird.

Du kannst es auch in eine Condition packen, also in eine Bedingung. Jedenfalls, wenn der Code dann dahin kommt, dann startet sich automatisch die Entwickler-Konsole und macht einen Breakpoint an der Stelle. Und dann kannst du genau da einsteigen zu Debuggen. Das finde ich richtig cool. Console.group hast du noch rausgelassen? Ja, da gibt es ganz viele, da müsst ihr mal nachlesen, was da noch so gibt. Es gibt auch Console.info, Console.warn, also naja. Das ist natürlich die primitivste Strategie, einfach diese Dinge überall zu verteilen. Aber ehrlicherweise ist es auch meistens die effektivste.

Eben kurz so ein paar Ausgaben da reinstreuen, dann findet man häufig schon sehr gut, was der Anhaltspunkt ist. Ja, und nicht jeder Fehler ist ja auch wahnsinnig riesig, sondern es gibt ja auch einfach kleine Fehler. Und die sind mit einem kurzen Konsolen-Output oft ja schnell zu erkennen. Genau. Die fanzigere Variante davon, du hast es gerade schon angesprochen, mit so Breakpoints und Debugger, ist eben so integrierte Debugger-Mechanismen zu benutzen, die dann schon die IDE bereitstellt oder wie du es jetzt gesagt hast, der Browser. Das ist dann im Prinzip das gleiche Konzept, nämlich man verteilt im Code Breakpoints, also so kleine Markierungen.

Und wenn dann der Code da durchläuft, dann stoppt der an den Stellen und gibt dir eine Ausgabe und du kannst den an diesen Stellen weiter navigieren und Schritt für Schritt die Programmführung weiterlaufen und sowas. Das ist ein super mächtiges Tool, wenn man weiß, damit umzugehen und wenn man es erstmal aufgesetzt hat. Und das ist dann eben die fanzige Variante von überall so Konsolenteile reinstreuen. Da kann man wirklich jeden einzigen Zustand der kompletten Anwendung pausieren, sich ausgeben, was an der Stelle vorkommt und dann vielleicht sogar Variablen setzen und überprüfen und sowas. Vielleicht noch ganz konkret in Chrome und wahrscheinlich heißt es in Firefox genauso.

In Chrome muss man auf diesen, also erstmal die Entwicklertools überhaupt aufmachen. Das ist dann, ich will jetzt nichts Falsches sagen, aber unter Windows glaube ich F12. Ich gehe immer mit rechten Maustaste untersuchen, dann auf die, oder inspect auf Englisch, auf die Elemente drauf und dann öffnet sich eben diese Entwicklerkonsole und im Sources Panel hat man dann zum Beispiel die JavaScript Codes, wo man dann links neben der Zeilennummer dann auch Breakpoints setzen kann und mit dem Mouse Over auf Variablen dann Werte von Variablen sehen kann und so weiter. Genau. Also mit dieser Grundlagenforschung, die ich jetzt mal so aufgestellt habe,

möchte ich das jetzt mal versuchen anzuwenden auf dieses konkrete Problem, was wir da haben. Also nochmal zur Wiederholung. Eine Karte wird geöffnet, aber da werden keine Dinge drauf eingezeichnet. Und jetzt waren wir im Frontend unterwegs, das heißt es war eine React-Anwendung und der erste Schritt, den ich dann natürlich mache als Entwickler, wenn nicht eh schon, du hast gerade gesagt, mache ich die Entwicklerkonsole auf. Es ist das mächtigste Tool, was man, glaube ich, als Entwickler an der Hand haben kann, als Webentwickler logischerweise, weil da steht alles drin. Alles, was auf der Anwendung abgeht, im Browser abgeht,

ist in dieser Entwicklerkonsole zu sehen. Also falls ihr die noch nie benutzt habt und Webentwickler seid, dann jetzt erstmal pausieren und ein Tutorial über die Entwicklerkonsole anschauen. Darf ich mal ganz frech sagen, wer die Entwicklertools noch nicht aufgemacht hat, ist kein Webentwickler. Ja, vielleicht. Und da steht eben auch eine Konsolenausgabe und da kann man schon sehr gut sehen, wenn es irgendwelche Fehler gibt. In diesem Fall allerdings stand da gar nichts. Das hat mich erstmal überrascht. Das heißt, die Anwendung ist gestartet und die Konsole hat erstmal gesagt, ja, alles wunderbar,

alles hat funktioniert, es gibt keine Probleme und trotzdem wurden die Dinge nicht auf der Karte eingezeichnet. So. Das heißt, ich weiß jetzt die Stelle, wo diese ganze Karte zusammengebaut wird. Ich habe da die Stelle im Code gefunden, wo das zusammengewerkelt wird und dann habe ich da gesehen, dieses Zusammenbauen besteht aus mehreren Teilen, nämlich zuerst wird diese Grundkarte geladen, also man kann sich das vorstellen, das Hintergrundbild und so die Dimensionen der Karte und sowas. Und dann im zweiten Schritt wurden die verschiedenen Layer geladen, die darauf eingezeichnet werden. Da gab es dann einen Ampel-Layer, sag ich mal,

wo alle Ampeln eingezeichnet wurden auf der Karte und einen Straßenschilder-Layer, kann man sich jetzt mal so vorstellen. Und was ich dann gemacht habe im ersten Schritt, ist das Setup zu vereinfachen. Das heißt, ich bin dann erstmal ganz stumpf hingegangen und habe alle Layer rausgeworfen und die Karte an sich gestartet und erstmal geguckt, okay, funktioniert immer noch. Hat vorher auch funktioniert. Aber jetzt funktioniert es auch noch. Ich habe also das Setup vereinfacht und die möglichen Konflikte gelöst. Und dann bin ich ganz stumpf hingegangen und habe die einzelnen Layer wieder aktiviert.

Und dann habe ich einen aktiviert und dann kam er auf einmal auf der Karte und dann wurden die Ampeln wieder angezeigt. Und da dachte ich, ah, okay, ist ja cool. Habe ich einen zweiten Layer aktiviert und dann hat es auch geklappt. Und dann habe ich einen dritten Layer aktiviert und dann hat es nicht geklappt. Und so habe ich mir quasi dann Schritt für Schritt, indem ich die Komplexität erhöht habe, angeschaut, okay, mit dem Bauteil funktioniert es noch, mit diesem dann nicht mehr. Und so habe ich das Ganze schon mal etwas näher eingegrenzt. Ich habe dann damit so ein bisschen herumgespielt und festgestellt, dass es tatsächlich eine Gruppe von Layern gab,

die nicht geklappt hat. Und wir hatten so ganz viele verschiedene Layer und die haben ihre Informationen aus verschiedenen Quellen bezogen. Und alle Layer, die aus derselben Quelle bezogen haben,

wenn eine davon aktiviert ist, ging die ganze Karte nicht mehr. So habe ich das schon mal eingegrenzt durch verschiedene Layer ein-, ausbauen und versucht, Gemeinsamkeiten zu finden. Und mit diesem Layer habe ich dann geschaut, okay, was sind denn hier die Gemeinsamkeiten zwischen diesen Layern, die da nicht funktionieren. Das konnte ich dann nur machen, weil ich vorher eben genau gefiltert habe, nicht nur diese ganze Karte ist das Problem, sondern ich habe auf einmal die Fehlerursache reduziert auf so drei von sieben Layern, die da irgendwie nicht funktioniert haben. Und als ich mir die angeschaut habe,

habe ich festgestellt, dass sie die gleiche Funktion benutzt haben, um ihre Informationen zu beziehen. Man kann sich da vorstellen, in dem Layer jeweils ist so ein API-Aufruf, der bezieht aus irgendeiner URL so ein JSON-Objekt und daraus baut es dann den Layer zusammen und generiert die Marker und solche Sachen. Und bei dieser Funktion haben wir uns sehr nah an dem orientiert, was tatsächlich Open Layer vorgibt. Die haben da so Beispiele und so Best Practices und haben gesagt, hier, wenn ihr Informationen irgendwo herbeziehen sollt, das ist hier jetzt der Beispielcode, den ihr benutzen könnt. Das heißt, wir haben das nicht selber implementiert an der Stelle,

sondern wir haben uns an dem orientiert, was Open Layer vorschlägt. Und da das ein offizieller Vorschlag von denen war, ist dann das nächste, was ich gemacht habe. Hast du einen Tipp? Nein. Ich habe nicht gegoogelt, darauf wollte ich hinaus, sondern was ich gemacht habe, ist direkt die Dokumentation beziehungsweise, ja doch, die Dokumentation zu konsultieren. Das heißt, ich habe Open Layers aufgemacht, habe mir die Stelle nochmal angeschaut, wie sie das machen, wie rufen die im Beispiel von Open Layers solche Daten ab, habe das mit dem verglichen, wie wir das gemacht haben und festgestellt, jo, wir haben das genauso.

Das heißt, ich habe jetzt schon das eingegrenzt in, der Fehler liegt irgendwie bei Open Layers und statt bei uns, dass wir irgendwo im Code eine Zeile falsch hatten oder sowas. Das ist natürlich immer der Worst Case. Deswegen habe ich gerade auch so ein bisschen gestockt, weil, also eigentlich sind ja 99,9% der Fehler immer bei einem selbst zu suchen und ich kann mich an so viele Situationen erinnern, wo ich gedacht habe, so, ich weiß, dass der Computer einen Fehler macht und man weiß natürlich eigentlich, der Computer macht keine Fehler und irgendwann findet man einen Fehler dann doch und meistens ist er dann umso dämlicher,

je sicherer man sich war, dass man selbst die Fehler nicht gemacht hat. Ja, und wenn man dann aber rausfindet, dass in irgendeiner externen Komponente oder vielleicht in so einem offiziellen und großen Projekt wie Open Layers ein Problem ist, da ist natürlich dann immer ein Problem, das sich oft nicht so leicht beheben lässt und das eigentlich ziemlicher Mist ist. Ja, also das habe ich vielleicht falsch erklärt, aber es war nicht der Fehler in irgendeiner Bibliothek, die Open Layers zur Verfügung steht, sondern der Code, den wir geschrieben haben, orientiert sich sehr stark an Beispielen, die Open Layers auch präsentiert.

Also die haben Beispiele gezeigt, wo sie sagen, hier so und so könnt ihr das machen und daran haben wir uns orientiert. Das ist die entscheidende Information an der Stelle. Das heißt, ich konnte jetzt schon meine Suche eingrenzen in nicht, wir haben zufällig in dieser JavaScript-Funktion einen ganz trivialen Programmierfehler gemacht und einen Nullcheck vergessen oder sowas, sondern irgendwas hat es schon mit Open Layers zu tun, anhand von wie Open Layers funktioniert, wie sie mit Layern umgehen und solche Sachen. Jetzt machst du mich schon ein bisschen heiß auf die Lösung. Ich weiß ja tatsächlich nicht, wie du es gelöst hast.

Ich bin jetzt schon gespannt. Genau, aber was ich damit sagen möchte, ist, dass ich den Fehler eingeräumt habe von irgendwas mit JavaScript hat nicht funktioniert zu irgendwas in Kombination mit diesem Open Layers-Dingen hat nicht funktioniert. Und deswegen habe ich auch direkt tatsächlich GitLab konsultiert, weil meine Erfahrung nach, GitHub meine ich natürlich, Entschuldigung, wo das Open Layers gehostet ist, weil wenn man so konkrete Fehler weiß, also weiß, dass es irgendeinen Fehler in Zusammenhang mit dieser Bibliothek gibt, dann ist es meiner Erfahrung nach effizienter, direkt in GitHub danach zu suchen,

weil üblicherweise gibt es da schon Issues und Discussions und so weiter und man hat es schon klarer gescoped, als das irgendwie so in die Google-Maske einzutragen. Früher hat man gesagt, immer Probleme googeln, aber ich für mich habe gemerkt, in letzter Zeit insbesondere, das weicht sich so ein bisschen auf und das hat ein paar Gründe und einer der Gründe ist unter anderem, dass wenn man jetzt zum Beispiel nach sowas wie Open Layers googelt, die haben inzwischen Versionsnummer 9 und mitunter über die vielen Jahre, wo es schon existiert, relativ umfangreiche Änderungen vorgenommen, dass wenn man einfach so stumpf danach sucht,

man dann auf einmal Ergebnisse findet, die schon vielleicht fünf Jahre alt sind oder sowas. Nichtsdestotrotz müssen wir, glaube ich, jeden ermutigen, auch bei Fehlern bei Google zu gucken. Viele Fehler sind ja der erste Treffer bei Google und da findet man einen guten Anhaltspunkt, woran es liegen könnte. Ja, genau, das wollte ich nicht verteufeln und Stack Overflow ist natürlich auch immer gerne gesagt, nur ich für mich, ich sage das gerne nochmal, habe festgestellt, wenn ich das so relativ konkret einkreisen kann, nämlich irgendwas mit Open Layers und irgendwas mit einem konkreten Layer, dann ist es für mich häufig zielführender,

wenn ich das direkt bei GitHub mache. Und das habe ich dann auch gemacht. Ich bin also in das GitHub-Repository von Open Layer gegangen. Aber du gehst wirklich auf die GitHub-Seite, auf das Repo von denen und suchst da in dem Forum? Ja, genau. Ach, interessant. Das habe ich noch nie gemacht. Muss man sich jetzt natürlich ein bisschen mit den Tools aufkennen, aber ich habe meinen Mac so konfiguriert, dass ich quasi mit dem Spotlight, dass ich da direkt auch URLs eingeben kann oder Suchanfragen. Und dann ist das für mich halt eine Tastenkombination, wo ich direkt auf die GitHub-Seite von Open Layers komme.

Und dann haben die oben rechts so eine Suchfunktion direkt, da kann man das eintippen. Da habe ich dann eingeben, irgendwas mit Layer-Sync oder sowas. Also wirklich auch nur so wenig Stichpunkte wie möglich, damit man ein möglichst breites Spektrum an Ergebnissen bekommt, wie irgendwie diese Begriffe enthält. Und dann bekommt man schon eine Liste von Issues, in denen das erwähnt wird, vielleicht sogar Code-Stellen, wo das erwähnt wird. Fussionen sind ja jetzt auch relativ neu. Genau. Und als ich das dann gemacht habe, habe ich tatsächlich Issues gefunden, wo jemand anders gesagt hat, jo, meine Layer laden nicht.

Und hat dann da so Code-Beispiele gehabt und gesagt, ja, hier, schau mal, ich habe das so und so gemacht, aber es wird nichts angezeigt. Also ich habe so über GitHub die Fehlerbeschreibung quasi gefunden, die wir auch hatten. Dann habe ich mir das angeschaut und festgestellt, was dann die eigentliche Lösung unseres Problems war, ist, dass wir zwar per URL diese Remote-JSON-Sachen laden,

um daraus die Marker zu generieren, aber dass es in dem Layer von OpenLayer einen Callback gibt, den man aufrufen muss, wenn es einen Fehler gab. Und wir hatten in diesem Fall einen Fetch-Fehler, also, weiß ich nicht, einen Autorisierungsfehler oder einen 404-Fehler. Und der hat dann dazu geführt, dass da nichts geladen werden konnte. Aber bei OpenLayer anscheinend führt es nicht dazu, dass wenn innerhalb dieses Layers ein Fehler stattfindet, dass OpenLayers als übergeordneter Wrapper den als Fehler interpretiert, sondern der stoppt dann an der Stelle einfach die Ausführung. Und was man stattdessen machen soll,

ist diesem Layer zu sagen, hey, du hast nicht funktioniert. Da gibt es dann so einen kleinen Callback, ich will jetzt nicht so sehr ins Detail. Und wenn man den dann aufruft, dann geht OpenLayers die einzelnen Layer durch bei der Initialisierung. Und wenn dann da Fehler auftreten, dann registriert der den intern als fehlerhaft, aber macht weiter mit der Initialisierung des nächsten Layers, wo er vorher, wenn man nichts macht und dem quasi nichts sagt, dass er fertig ist, einfach stoppt an der Stelle und nicht weitermacht. Damit hätte ich jetzt nicht gerechnet. Ich hätte gedacht, dass der Fehler irgendwo dran liegt,

dass wir ein Event nicht feuern oder dass bei React, da gibt es ja manchmal Situationen, wo dann Sachen ausgeführt werden oder nicht ausgeführt werden, von denen man eigentlich ausgeht oder nicht ausgeht und dass das dann in so einem Loop irgendwo verschluckt wurde. Aber ja, das ist hier interessant an. Genau, das ist hier eigentlich tatsächlich passiert, dass der OpenLayers ein Event abfeuert, wenn er glaubt, dass alle Layer geladen wurden. Aber dafür müssen die Layer von sich aus mitteilen, ob sie geladen wurden oder nicht. Und es gibt quasi nicht von OpenLayer als Manager oben drüber die Überwachung der einzelnen Layer,

sondern jeder Layer sagt für sich, hör mal, ich bin jetzt fertig geladen oder ich konnte nicht laden wegen eines Fehlers. Und nur wenn sie eine dieser beiden Aussagen aktiv machen, dann geht der übergeordnete Rapper durch und feuert dann Events oder sowas. Also in unserem Bug-Beispiel war OpenLayers die ganze Zeit in einem Zustand von ich habe noch nicht fertig geladen, weil einzelne Layer nicht geantwortet haben. Und nachdem wir dann geantwortet haben, hey, es gab einen Fehler, dann konnte der durchgehen und alles Weitere ordentlich machen. Verstehe. Ja, das ist natürlich jetzt schon ein bisschen konkretes Problem,

was du jetzt beschrieben hast, was ich aber mega spannend finde. Also hat mir schon Spaß gemacht, dir dazu zu hören. Jetzt ist natürlich die Frage, was nehmen wir jetzt als allgemeine Takes da raus? Und wenn, ich weiß gar nicht, ob du schon fertig bist, aber wenn ich von vorne durchgehen würde, würde ich erstmal sagen, das Wichtigste ist natürlich erstmal das Problem einzugrenzen und sich mal zu überlegen, an welcher Stelle fange ich überhaupt an. Du hast jetzt gesagt, von vorne oder von hinten. Das finde ich genau richtig. Entweder guckt man sich die Ausgabe an oder man guckt sich die Quelldaten an

und sucht sich eine Stelle, wo es noch richtig ist oder wo es eben schon falsch ist und geht dann zurück oder vor. Ganz genau, das würde ich auch sagen. Also den Fehler als so eine Kette zu verstehen von einem Zustand, bei dem ich weiß, dass er stimmt und wenn es nur ein Quellcode ist, den ich vor mir aufhabe, den ich gerade frisch geschrieben habe, bis hin zu einem Zustand, von dem ich weiß, dass er nicht mehr stimmt, da diese Kette erkennen und dann jedes Kettenglied einzeln durchgehen, auch wenn man glaubt, da ist doch ganz bestimmt gar kein Fehler, dann ist er sehr wahrscheinlich genau da versteckt

und einzeln schauen, was sind hier die Zustände, was hat sich verändert. Und wenn ich das dann sehr genau eingegrenzt habe, an welcher Stelle ich mich befinde, dann ist der Fehler meistens ja entweder offensichtlich, also ich kann ihn dann direkt beheben oder ich habe eine Stelle, wo ich erstmal so nicht weiterkomme mit meinem Wissen und das kann ich dann sehr präzise googeln, Chat-GP-Teen oder eben, wie du gesagt hast, direkt bei GitHub dann nachforschen, woran es liegen könnte. Genau, da sind die beiden Tipps von mir, A, nach dem Datum des Ergebnisses schauen, weil insbesondere, also es wird tatsächlich ein zunehmendes Problem,

dass alle Packages ja immer älter werden und wenn ich mir Bugfix-Lösungen oder Tipps für React von vor sieben Jahren anschaue, dann kommen sie mir noch mit Klassenkomponenten um die Ecke. Das heißt, da immer so ein bisschen nachschauen, dass die Situation und die Antworten halbwegs aktuell sind und auch versuchen, stichpunktartig zu suchen, dass wenn ich jetzt nach Suche Open Layers, Layer Sync oder sowas, dass ich dann so Buzzwords nenne, die irgendwie mein Problem einkreisen. Und ansonsten eine sehr gute Methode ist natürlich auch mal, seine Kollegen nochmal zu fragen. Wenn man eine Stelle hat und sagt,

da muss irgendwo ein Fehler drin sein und da kommt man nicht weiter, dann kenne ich die Situation ganz oft, dass ich dann einen Kollegen, eine Kollegin anrufe und dann anfange, über das Problem zu sprechen und entweder merke ich schon während des Sprechens, oh, ah, da ist ja der Fehler und der andere hat noch gar nichts gesagt und ich habe den Fehler schon gefunden. Das ist uns schon so oft passiert und kenne ich auch von anderen. Oder die andere hat eben noch eine gute Idee dazu und kann da nochmal Input geben. Zu zweit sieht man so viel mehr als alleine. Ist natürlich jetzt nicht jedem vergönnt,

in einem Team zu arbeiten, aber wenn man den Luxus hat, dann sollte man das definitiv auch wahrnehmen. Was ich vielleicht als Fazit jetzt daraus ziehen würde, ist, Fehler nicht als Hindernis oder so als leidiges Thema zu interpretieren, sondern Fehler als Möglichkeiten. Weil selbst wenn man da stundenlang drin rumdoktort und sich total intensiv mit den Packages beschäftigt und dann vielleicht auch den Quellcode des Packages auf GitHub untersucht, weil man vielleicht jetzt zufällig kein Issue findet oder sowas, das ist alles nicht vertane Zeit, sondern das trägt alles dazu bei, dass man insgesamt ein besserer Entwickler wird.

Man lernt ja nur an Problemen, wenn man einfach so zeilenweise alles runterschreibt und es funktioniert, dann lernt man nichts. Und genau solche Fehler sind Möglichkeiten zu sagen, oh, geil, es funktioniert nicht. Lass uns herausfinden, woran es liegt. Da setzen wir uns die Sherlock-Kappe auf und nehmen einen Tee und dann gehen wir mal richtig hart rein, bis es wehtut. Ja, ich kann mich an wilde Debug-Sessions erinnern, wo man dann auch stundenlang mit zugebracht hat und das dann irgendwann auch einfach nur noch nervig war. Aber das Beste ist ja, wenn man dann einen Fehler wirklich gefunden hat

und hinterher das gelöst hat, die Euphorie, die ist natürlich genial und das sehe ich so wie du. Die allerwichtigsten Lektionen lernt man, wenn man entweder selbst Fehler gemacht hat oder nach Fehlern sucht, weil man einfach so tief in den Code einsteigt, versucht, jeden Schritt zu verstehen, Sachen versteht, die man vorher nicht so verstanden hat. Und klar, dabei lernt man einfach wahnsinnig viel. Mein Bruder sagte mal, Probleme sind nur Hindernisse mit Dornen. Hat er sicher nicht erfunden, aber ich finde das ganz schmissig. Also Fehler als Chance. Kay, ich würde abschließend noch mal ein bisschen auf Debugging eingehen,

weil ich zwei Sachen noch habe, die ich ganz interessant fand. Die habe ich jetzt im Vorhinein gelesen in meiner Recherche. Nämlich das eine ist, dass man bei Firefox einen Request, der abgeschickt wurde. Da sind wir wieder in den Entwicklertools und da gibt es halt diesen Netzwerktab. Da kann man dann nach bestimmten Requests filtern, zum Beispiel nach diesen XR Requests. Und wenn man das in Firefox macht, dann kann man da einen Request editieren und neu abschicken. Wusstest du das? Heilige, willst du mich jetzt zu Firefox konvertieren? Nee, überhaupt nicht. Ich benutze es ja selbst. Nee, aber wusste ich tatsächlich nicht.

Aber das finde ich eigentlich cool und ich habe es in Chrome auch ausprobiert und da geht es nicht. Und das kann ich mir schon vorstellen, dass das in vielen Situationen nochmal praktisch ist. Wenn man dann ein JSON-Objekt, wie du es gerade gesagt hast, zum Beispiel von einem Layer bekommt und meint, da wäre vielleicht ein Fehler drin oder einfach nur ausprobieren will, wie sich das mit anderen Werten verhält, dann kann man das da einfach editieren und kann den neu abschicken. Und das finde ich eine richtig coole Funktion. Also das sei hier nochmal als Tipp mitgegeben. Und eine andere Sache, die ich aus meiner Praxis

sehr, sehr gerne benutze und wo ich immer wieder denke, das hilft Leuten sehr weiter, ist dieses Problem, jetzt sind wir vielleicht wieder im Chrome, dass wenn ich ein Problem bei einem Hover zum Beispiel habe, bei irgendeinem Mouse-Over, irgendeinem Maus-Interaktion, dann habe ich halt ein Problem, dass ich nicht einen Breakpoint reinschmeißen kann bei JavaScript, weil die Breakpoints ja meistens, also da klicke ich meistens save in die Zeile an und setze einen Breakpoint. Und dann bin ich manchmal bei so Hover-Geschichten und sowas bin ich zu spät. Und da finde ich richtig cool, dass man im Chrome

in dieser Code-Ansicht, in den Entwickler-Tools wieder, eine rechte Maustaste auf irgendein Element machen kann. Also ich nehme jetzt zum Beispiel ein Div und dann kannst du sagen break on und dann könntest du zum Beispiel break on attribute modification machen und dann breakt der automatisch, wenn sich ein Attribut ändert. Und das ist halt richtig cool, wenn du so mit CSS-Geschichten machst, also zum Beispiel eine Hover-Klasse auf irgendein Element draufpackst und in dem Moment, wo das passiert, kannst du da eben breaken. Und das finde ich oft sehr, sehr hilfreich, so eine Funktion zu verwenden,

anstatt irgendwo im Code einen Breakpoint zu machen, wo der vielleicht zu spät kommt. Also ich höre schon daraus, wir müssen nochmal eine explizite Debugging-Folge ausleiten, wo wir wirklich auch über solche Debugging-Tools und auch Debugging in der IDE sprechen. Da würde ich mich auch über Feedback für diese Folge freuen, ob das halbwegs verständlich ist, was wir so erzählt haben. Ich habe natürlich alles im Kopf und gestikuliere hier wild vor dem Mikrofon herum, aber das ist ja alles schon sehr konkret, ob das auch gut nachvollziehbar ist, wenn man einfach nur so zuhört, ob wir das gut beschrieben haben

und sowas. Feedback gerne. Und falls man das gut machen kann, dann wäre, glaube ich, so eine Debugging-Folge, wie du es jetzt schon angeteasert hast, auch nochmal ganz hilfreich. Ja, du hast gerade schon Debugging in der IDE gesagt und das würde mich noch ganz kurz für diese Folge interessieren. Vielleicht verlegen wir den längeren Teil dann auf eine andere. Benutzt du das Debugging in PHPStorm im Moment noch? Ich benutze es für Backend-Sachen, weil es da sehr viel praktischer ist. Und ich benutze es, wenn ich über JavaScript-Unit-Tests reingehe, weil man dann sehr gut den Debugger-Auslöser kontrollieren kann.

Wenn man das in Kombination mit dem Browser macht, dann ist es immer ein bisschen sperriger. Aber ja, ich benutze das tatsächlich aktiv für JavaScript, noch ein Grund mehr für Unit-Tests und PHP. Weil das benutze ich nämlich bisher noch gar nicht, habe es bei dir aber hin und wieder gesehen und du kriegst ja da manchmal schon sehr schnell sehr gute Ergebnisse mit. Ja, du jetzt auch, nachdem du diese Folge gehört hast. Okay, Kay, ich glaube für heute schließen wir das Thema. Ja, mein Kaffee ist auch alle. Und dann hören wir beide uns in der nächsten Woche und liebe Grüße gehen raus an alle da draußen.

Tschüssi!