Die Geschichte dahinter

Manche Arbeitstage beginnen so, als hätten sich alle Probleme für denselben Morgen verabredet. Heute war wieder so ein Tag. Während einer Inbetriebnahme liefen mehrere Themen gleichzeitig: Hier musste noch etwas verkabelt werden, dort gab es Rückfragen, an einer anderen Stelle sollte etwas angepasst werden, und zwischendurch wartete schon das nächste Problem darauf, angeschaut zu werden.

Zusätzlich sollte ich per Fernwartung noch ein anderes Problem untersuchen. Die Verbindung lief dabei über das iPhone und war so langsam und träge, dass vernünftiges Debugging praktisch nicht möglich war. Normalerweise macht man eine Änderung, startet einen Test und sieht relativ schnell, was passiert. In diesem Fall bedeutete jeder einzelne Schritt: Ändern, warten, testen, wieder warten. Irgendwann war klar: So wird das heute nichts.

Also habe ich die Fehlersuche dort relativ schnell beendet und beschlossen, das Ganze später im Büro unter normalen Bedingungen sauber aufzubauen. Manchmal ist es sinnvoller, ein Problem für den Moment liegenzulassen, statt unter schlechten Bedingungen immer mehr Zeit darin zu versenken.

Während der Inbetriebnahme war mir aber noch ein anderes Verhalten aufgefallen, und genau diesem Problem widmete ich mich danach. Dabei stiess ich zuerst auf ein interessantes Architekturthema im Webproxy.

Im normalen Betrieb verwenden wir für verschiedene Controller getrennte Dienste. Jeder Dienst läuft damit in seinem eigenen Programmkontext und verbindet sich mit genau dem Controller, für den er vorgesehen ist. Deshalb war ein bestimmtes Verhalten bisher nie wirklich aufgefallen.

In meiner aktuellen Testkonstellation liefen jedoch mehrere Verbindungen innerhalb desselben Prozesses. Plötzlich zeigte sich, dass ein gemeinsam verwendeter Singleton-Zustand für diese Situation nicht ideal war. Was bei einem einzelnen Controller problemlos funktioniert, wird interessant, sobald mehrere Verbindungen denselben Dienst benutzen.

Die entscheidende Frage war plötzlich: Wem gehört dieser Zustand eigentlich? Controller A, Controller B oder einfach dem ersten, der zufällig da war?

Damit war klar, dass die Verbindungskontexte sauberer voneinander getrennt werden mussten. Kein spektakulärer Absturz und kein Weltuntergang, aber ein schöner Fund, weil genau diese spezielle Konstellation das Problem überhaupt erst sichtbar gemacht hatte.

Und dann kam noch der zweite Fehler. Der war deutlich kleiner und im Nachhinein wesentlich lustiger.

Das Problem sah zunächst so aus, als würde mit dem Pfad beziehungsweise mit der Webanwendung etwas nicht stimmen. Also suchte ich bei PathBase, MVC-Routing, Routing-Patterns und der Frage, ob beim Aufbau der URL oder bei der Pfadauflösung etwas falsch interpretiert wird. Alles durchaus plausible Kandidaten.

Nur war keiner davon schuld.

Vor dem Wert von BaseDirectory befand sich ein unsichtbarer Tabulator. Ein einziges Zeichen reichte aus, damit das angegebene Verzeichnis schlicht nicht gefunden wurde.

Ich hatte also über Routing, Pfade und Framework-Verhalten nachgedacht, während sich ganz vorne in der Zeichenkette ein kleiner unsichtbarer Tab versteckte. Die Lösung war entsprechend unspektakulär:

Trim()

Und plötzlich war das vermeintlich komplizierte Problem verschwunden.

Genau solche Fehler sind im Nachhinein immer die besten. Man sucht gedanklich schon tief im Framework, überlegt sich komplizierte Zusammenhänge und fragt sich, welches Verhalten man übersehen hat. Und am Ende sagt einem der Computer praktisch nur:

Da war ein Tab.

Am späteren Abend zeigte sich bereits noch ein weiteres Thema mit einem dynamisch erzeugten Device und der Nummer 65535. Das Problem war erkannt und grundsätzlich nachvollziehbar, aber nichts, was noch am selben Abend gelöst werden musste.

Das ist ein Problem für morgen.

Nach einem ziemlich chaotischen Start waren damit zwei interessante Probleme geklärt, ein weiteres für den nächsten Tag identifiziert und nebenbei noch etwas über die eigene Software gelernt worden.

Eigentlich ein ziemlich guter Tag.

Fazit

Nicht jeder erfolgreiche Arbeitstag fühlt sich von Anfang an erfolgreich an. Manchmal beginnt er mit mehreren Baustellen gleichzeitig, einer Fernwartung in Zeitlupe und dem Gefühl, dass heute alles etwas komplizierter sein muss als nötig.

Dann findet man einen Architekturfehler, der bisher nie sichtbar war, sucht anschliessend einen komplizierten Routingfehler und entdeckt stattdessen einen unsichtbaren Tabulator.

Und irgendwann sitzt man im Buvette Südpol und stellt fest:

Zwei Probleme gelöst, eines für morgen gefunden und trotzdem noch rechtzeitig Feierabend gemacht.

Kann man so lassen. 😄