Aki's Vibes

[Dorena Verne]

Liest sich wie ein spannender Krimi.

[LyAvain]

Jupp... Am genialesten finde ich den Vergleich mit dem alten Hotel... Keiner weiss, warum die Klingel aus Zimmer 47 die Lobby Beleuchtung einschaltet...
Mich hats echt zerrisssen vor Lachen.

[Akira]

Aufräumen im Werkzeugschuppen, ohne die Bauarbeiten zu stoppen

Oder: was passiert, wenn man drei Werkzeugkästen aus drei Jahrzehnten in einem einzigen Hotel zusammenstellt

Im letzten Beitrag habe ich erzählt, wie ich akisim als Hotel mit vier sauberen Stockwerken neu aufsetze, statt das alte OpenSim-Hotel weiter anzubauen. Heute geht's um den Werkzeugschuppen. Den Raum, wo die Hammer, Wasserwaagen und Schraubenzieher liegen, mit denen die Handwerker durchs Hotel laufen.

Im Erbe-Hotel sieht der so aus: drei Generationen Handwerker haben drei Werkzeugkästen reingestellt. Aus den 2000ern, aus den 2010ern, aus den 2020ern. In jeder Etage liegt ein anderer. Manche Werkzeuge gehen nur in bestimmten Ländern. Manche sind so alt, dass selbst der Hersteller sie nicht mehr ersetzt. Und niemand weiß mehr, welches Notizbuch denn jetzt das richtige ist.

Ich habe in den letzten Tagen drei davon angefasst. Hier die Geschichten.

Werkzeug Nr. 1: das mit der Länderbeschränkung

In OpenSim wird ständig mit Bildern gerechnet. Karten werden gerendert, Texturen werden zugeschnitten, Avatare bekommen Bake-Layers überlagert. Das ganze Hotel hängt am Bildverarbeitungs-Werkzeug.

Das alte Werkzeug heißt System.Drawing. Wer mit Windows aufgewachsen ist, kennt es – Microsoft hat es in den späten 90ern gebaut, und es hat zwanzig Jahre lang funktioniert. Das Problem: Microsoft hat irgendwann gesagt "das gehört nur noch zu Windows". Auf Linux funktioniert es nicht. Auf Mac auch nicht. Wer es auf Linux verwenden will, braucht eine alte Hilfsbibliothek aus dem Mono-Projekt, die seit Jahren kaum noch gewartet wird.

akisim soll aber überall laufen – Mac, Linux, Windows. Das Hotel kann nicht „nur deutsche Schraubendreher dabei haben". Also: das Werkzeug muss raus.

Ersatz: SkiaSharp. Eine Bildverarbeitungs-Bibliothek, die Google für Chrome entwickelt hat (Skia heißt der Renderer dahinter), und die mittlerweile auf jeder Plattform läuft, die einen modernen Browser ausführen kann. Also überall.

Die Migration ist mitten drin. Der Werkzeugschuppen hat ein zentrales Regal bekommen – ein kleines Wrapper-Projekt namens „OpenSim.Framework.SkiaSharp" – wo die wiederkehrenden Helfer liegen. Vierzehn Teilprojekte sind schon umgestellt und greifen nur noch auf das neue Regal. Drei Hybrid-Projekte stehen noch auf der Liste – die haben das alte Werkzeug parallel rumliegen, weil ich beim Migrieren auf was anderes gestoßen bin und unterbrochen habe. Plus etwa dreißig einzelne Code-Stellen, die noch direkt das alte Werkzeug nehmen statt aus dem Wrapper-Regal.

Die harte Regel dazu: Kein neues Projekt darf das alte Werkzeug noch dazustellen. Auch nicht „nur kurz, als Brücke". Sobald man die erste Ausnahme zulässt, ist die Regel weich. Lieber Null als Null-Komma-irgendwas.

Werkzeuge altern. Der Beton, auf dem das Hotel steht, nicht.

Werkzeug Nr. 2: drei Notizbücher, von denen niemand weiß, welches gilt

Wenn ein Hotel wissen will, welcher Concierge wo arbeitet, welche Bar bis wann offen hat, oder welches Schloss welchen Schlüssel braucht, schaut man im Hausmeister-Notizbuch nach. Eigentlich.

Im akisim-Hotel gab es bis vor zwei Tagen drei Notizbücher. Die Standorte würden Sie nicht glauben:

• Eines im Empfang. Heißt „OpenSim.ini", ist von 2007, und steht da, wo die alten Region-Einstellungen drin liegen.
  
• Eines im selben Empfang, im selben Notizbuch, nur ein paar Seiten weiter – aber für die Telemetrie-Einstellungen. Anderes Format, andere Konvention.
  
• Eines gar nicht im Hotel, sondern im Briefkasten neben dem Eingang – Umgebungsvariablen, die das Betriebssystem bereitstellt. Da steht der Endpoint für die Telemetrie drin, und das Passwort dafür.
  

Was passiert, wenn ein neuer Mitarbeiter morgens kommt? Er guckt im ersten Notizbuch nach seinem Service-Namen, findet „akisim.hotel". Schaut im zweiten Notizbuch, findet „akisim". Schaut im Briefkasten, findet eine dritte Variante – oder gar nichts, wenn der Postbote noch nicht da war. Drei verschiedene Wahrheiten zur selben Frage.

Symptom: das Telemetrie-System schickt Daten unter zwei verschiedenen Namen ein. Wer das Hotel überwacht, sieht zwei Hotels – aber es ist eins. Plus: der allererste Eintrag morgens fehlt manchmal komplett, weil das Notizbuch im Briefkasten beim Start noch nicht angekommen ist.

Lösung: ein einziges Notizbuch. Heißt jetzt „akisim.yaml", liegt direkt neben dem Hauptprogramm, und ist die einzige Wahrheit für alle akisim-Belange.

Format ist YAML – die selbe Sprache, die auch andere moderne Werkzeuge im Hotel verwenden. Passwörter und Tokens stehen nicht direkt drin (sonst könnte ich das Notizbuch nicht offen rumliegen lassen), sondern werden über kleine Platzhalter wie ${env:GRAFANA_TOKEN} reingelesen. Das echte Token kommt aus dem Briefkasten. Wer das Notizbuch in die Hand nimmt, sieht dass dort ein Token verwendet wird, aber nicht welches.

Das alte „OpenSim.ini"-Notizbuch im Empfang? Bleibt liegen, ungeöffnet. Es gehört zum Altbau-Teil des Hotels, und der ist eingefroren. Wenn der Altbau irgendwann komplett abgerissen wird, geht das Notizbuch mit raus. Bis dahin: zwei Notizbücher physisch im Hotel, aber nur eines wird gelesen.

Eine Wahrheit ist mehr wert als drei Halbwahrheiten – auch wenn die drei Halbwahrheiten alle stimmen.

Werkzeug Nr. 3: die alte Tagebuch-App

Jeder Hotelbetrieb braucht ein Tagebuch. Wer hat eingecheckt, wer hat den Aufzug repariert, wo gab's einen Wasserschaden. Im Software-Sprech heißt das Logging, und im OpenSim-Erbe lief das mit einer Bibliothek namens log4net.

log4net ist nicht schlecht. Es ist nur alt. Aus Java übersetzt, dann auf .NET portiert, in den frühen 2000ern entstanden. In jedem alten Modul findet man dieselbe drei-Zeilen-Beschwörungsformel oben drin – „besorg mir den Logger für diese Klasse hier" – und dann wird in den Dateinamen geschrieben.

Vor zwei Wochen hatte ich entschieden: für akisim wird das durch das Microsoft-Standard-Logging ersetzt. War der naheliegende Weg. Microsoft schreibt seit Jahren, das sei die richtige Wahl, alle .NET-Tutorials machen es so.

Letzte Woche habe ich diese Entscheidung wieder kassiert. Grund:

In den Tagen davor hatte ich beschlossen, möglichst wenig vom „Microsoft.Extensions"-Baukasten zu verwenden, weil der bei mir Reibung erzeugt – im konkreten Fall mit dem neuen Konfig-Notizbuch (siehe Werkzeug Nr. 2). Wenn ich den ganzen Microsoft-Baukasten draußen halten will, gehört das Microsoft-Logging mit dazu.

Ersatz: Serilog. Eine Logging-Bibliothek, die seit etwa zehn Jahren im .NET-Bereich richtig erwachsen ist und mit der ich gut arbeite. Wichtig daran: Serilog hat einen direkten Pfad zu meiner Telemetrie-Plattform (Grafana Cloud). Kein Umweg über Microsoft-Vermittler, keine zusätzliche Verkettung. Tagebuch-Eintrag wird geschrieben, geht raus, fertig.

Das alte log4net? Bleibt im Altbau unangetastet. Während der Übergangsphase läuft beides parallel: log4net schreibt in die alte Datei wie immer, Serilog schreibt direkt in die Cloud. Doppel-Output ist akzeptiert, weil sonst die Migration in einem Big Bang landen würde – und davon halte ich nichts (siehe letzten Beitrag).

Ein Tagebuch reicht. Es muss nur am richtigen Ort liegen.

Aside: der Bauleiter mit der Mappe

Eine Sache, die ich nebenher gemacht habe und die in den Werkzeugschuppen passt, weil sie auch alle Etagen betrifft:

In OpenSim haben Variablen den Präfix „m_". Das stammt aus den 90ern, aus einer Zeit, in der C++-Programmierer ihre Felder so markiert haben, weil ihre Editoren keine Farben konnten. Heute können Editoren Farben. Es ist überflüssig.

In akisim-Code gibt es jetzt eine Mappe im Bauleiter-Büro (eine Datei namens „.editorconfig"), in der steht: „m_-Präfix verboten, in akisim-Schichten gilt der moderne Software-Stil". Wer das ignoriert, kriegt vom Compiler einen Fehler ins Gesicht – nicht eine Warnung, einen Fehler. Der Code geht gar nicht erst durchs Tor.

Den Altbau lasse ich in Ruhe. Da darf „m_" stehen wie immer. Sobald aber ein Stück Code von Altbau in Neubau wandert, kommt der Stil mit. Compiler-getrieben, nicht mit Lint-Bots, die Pull-Requests öffnen.

Disziplin gehört in die Bauakte. Nicht ins Bauchgefühl.

Was ich daraus gelernt habe

Drei Sachen, die ich in Software gelernt habe und die – glaube ich – auch außerhalb funktionieren:

1. Werkzeuge altern, der Beton nicht. Wer ein Werkzeug fest im Tragwerk verbaut, hat ein Problem, sobald das Werkzeug ausstirbt. Werkzeuge gehören in einen Schuppen, mit Tür, die man öffnen und schließen kann. Nicht ins Mauerwerk.
   
2. Eine Wahrheit, ein Ort. Drei Notizbücher, die alle technisch korrekt sind, ergeben in der Praxis null Wahrheit. Wer eine Information sucht, weiß nicht wo. Wer sie ändert, vergisst zwei Stellen. Lieber ein Buch, das alle benutzen.
   
3. Disziplin lieber im Compiler als im Kopf. Eine Regel, die der Compiler durchsetzt, ist eine Regel, die ich nicht jeden Morgen neu beschließen muss. Eine Regel, die nur im Kopf existiert, hat in zwei Wochen ihren ersten Verstoß.
   

Es bleibt viel zu tun. Drei Hybrid-Projekte und dreißig Code-Stellen für Werkzeug Nr. 1, der vollständige log4net-Cutover für Werkzeug Nr. 3 ist Sache von „wenn der Altbau weg ist". Aber die Richtung steht. Ich poste, was passiert.