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.

[Jupiter Rowland]

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.

Kann man sich echt bildlich vorstellen.

Amateurhafter Pfusch am Bau verschiedentlichen Alters neben Resten professioneller Bausubstanz von Big Blue. Ein ganzer Flügel, den vor vielen Jahren Halcyon Hoch- & Tiefbau mit'm Schwertransporter angeliefert hat. Bauschaum, wo wirklich niemand damit rechnen würde und auch wirklich keiner hingehört. Inzwischen huschen nur noch fünf Gestalten auf dem Bau rum, von denen auch nur noch einer tatsächlich Bauwerkzeuge hat.

Und unweigerlich hat man xkcd 2347 im Hinterkopf.

[Akira]

Wie ein Kran ans Hotel kam

Oder: warum ich aufgehört habe, jedes neue Bauteil selbst nach oben zu schleppen

Bisher lief der Umbau am Hotel so: ich hatte eine Idee, schrieb den Code, baute lokal ein neues Bauteil, lud es auf einen USB-Stick, fuhr zum Hotel, ging in den Heizungskeller, tauschte das alte Teil gegen das neue. Eine Stunde Hin-und-Her für jede Änderung. Klingt umständlich? War es auch.

Letzte Woche habe ich einen Kran aufgestellt. Genauer: eine kleine Logistik-Kette, die für mich macht, was ich vorher zu Fuss erledigt habe. Heute geht's darum, wie der Kran funktioniert, was ich dabei kaputtgemacht habe und welche drei Schlüssel ich verwechselt habe.



Zwei Helfer, eine Übergabe

Der Kran besteht aus zwei Helfern, die sich nie persönlich sehen.

Der erste sitzt in einer auswärtigen Werkstatt. Wenn ich am Code etwas ändere und „Schick's los" sage, fängt er sofort an: nimmt meinen Code, baut daraus ein fertiges Bauteil, packt es in eine nummerierte Kiste (zum Beispiel „Kiste Nr. 28") und stellt sie ins Lager. Diese Werkstatt steht irgendwo im Internet, ich habe sie nie gesehen. Sie wird mir kostenlos vom Hoster meines Code-Repositories zur Verfügung gestellt, solange ich nicht übertreibe.

Der zweite Helfer steht direkt am Hotel auf dem Bauhof. Bei mir konkret: auf meinem Laptop, der mehr oder weniger dauerhaft mitläuft. Sein Job ist, gelegentlich rauszugehen und nachzuschauen, ob's eine neue Anweisung gibt. Wenn ja, holt er die passende Kiste aus dem Lager und stellt sie an die richtige Stelle im Hotel.

Das Schöne dabei: der Bauhof-Helfer braucht keine Türklingel. Niemand kann ihn von aussen anrufen. Er geht nur selbst raus und fragt. Genau richtig für einen Laptop, der hinter dem Hausanschluss steht und nicht aus dem Internet erreichbar ist. Klingelnde Tür wäre ein Sicherheitsrisiko, das ich nicht haben möchte.

Ein Helfer ohne Klingel ist ein Helfer ohne Einbruchsrisiko.

Das Lieferschein-Buch in der Mitte

Wie kommen die beiden Helfer zusammen, wenn sie sich nie sehen? Über ein Lieferschein-Buch.

Das Buch ist ein eigenes kleines Git-Repository namens „homelab". In dem Buch steht für jedes Hotel-Element eine Zeile: „Verwende aktuell Kiste Nr. 28". Mehr nicht. Die Werkstatt darf reinschreiben, der Bauhof darf lesen.

Wenn die Werkstatt eine neue Kiste fertig hat, macht sie zwei Dinge: sie stellt die Kiste ins Lager und sie streicht in dem Buch die alte Nummer durch und schreibt die neue rein. Punkt. Sie kümmert sich nicht ums Hotel selbst.

Der Bauhof-Helfer guckt regelmässig ins Buch. Steht dort eine andere Nummer als gestern, holt er die neue Kiste und tauscht sie aus. Etwa sieben Sekunden. Fertig.

Was ich daran mag: das Buch ist die Wahrheit. Wenn ich wissen will, was im Hotel gerade verbaut ist, schaue ich nicht ins Hotel. Ich schaue ins Buch. Wenn ich was rückgängig machen will, ändere ich nicht das Hotel — ich ändere das Buch. Der Bauhof zieht beim nächsten Blick automatisch nach.

Wenn das Buch und das Hotel auseinanderlaufen, hat das Buch recht. Immer.

Zwei Werks-Ausweise, nicht einer

Beide Helfer brauchen einen Ausweis, um ans Buch zu kommen. Hier habe ich am Anfang gespart und einen einzigen Ausweis für beide ausgestellt. Ist ja dasselbe Buch.

Schlechte Idee. Wenn der Bauhof-Helfer den Ausweis verliert (Laptop geklaut), könnte derjenige, der ihn findet, ins Buch schreiben. Was bedeutet: er könnte sagen „Verwende Kiste Nr. 9999 aus meinem privaten Lager". Und der Hotel-Bauhof würde gehorchen.

Also: zwei getrennte Ausweise. Einer für die Werkstatt, der nur Schreiben kann. Einer für den Bauhof, der nur Lesen kann. Wenn der Bauhof-Ausweis abhandenkommt, kann der Finder zwar mitlesen — aber nichts ändern.

Das ist nicht paranoid, das ist Hygiene. Eine Tür hat einen Schlüssel, der genau diese Tür öffnet. Nicht zehn Türen.

Wer einen Schlüssel macht, der alle Türen öffnet, baut ein Bündel Sollbruchstellen, kein Schlüsselbund.

Drei Stolpersteine, ehrlicherweise

Es lief nicht beim ersten Versuch. Drei Sachen, an denen ich hängengeblieben bin:

1. Zwei Sorten von Anmelde-Codes.
Als ich den Bauhof-Helfer einrichten wollte, fragte das System nach einem Code. Es gibt aber zwei Sorten: einen Anmelde-Code (gilt nur für die einmalige Erstanmeldung, danach Müll) und einen Dauer-Geheimnis (kommt nach erfolgreicher Anmeldung raus, und das benutzt der Helfer dann jeden Tag). Ich habe den Dauer-Geheimnis-Code in das Anmelde-Feld eingetragen. Funktionierte nicht. Halbe Stunde gesucht. Helfer einmal komplett neu aufgesetzt.

2. Das Etikett mit der falschen Nuance.
Ein Helfer kann auf zwei Arten arbeiten: entweder direkt am Hotel mit den dortigen Werkzeugen, oder in einem Container (eine Art transportabler Mini-Werkstatt, in der nichts vom Hotel sichtbar ist). Welche Variante er nimmt, entscheidet ein Etikett auf seinem Werkzeuggürtel — „omnibook" für direkt am Hotel, „omnibook:host" für ausdrücklich-direkt. Steht da nur „omnibook", nimmt er aus alter Gewohnheit die Container-Variante. Und in dem Container existiert das Hotel nicht. Der Helfer suchte vergeblich. Suffix nachgetragen, alles gut.

3. Der leere Lieferwagen.
Mein erster Live-Test endete damit, dass eine Kiste pünktlich am Hotel ankam, ich sie öffnete — und sie war leer. Genauer: die Werkstatt hatte ein Bauteil produziert, das aus einem leeren Gehäuse bestand. Hintergrund: ich hatte eine Woche vorher einen vermeintlich überflüssigen Verbindungsschlauch zwischen meinem Code und dem Bauteil entfernt. Stellte sich raus: durch den Schlauch floss in Wirklichkeit der ganze Inhalt. Werkstatt baute weiter, aber ohne Inhalt. Zwei Stunden Detektivarbeit, bis ich den Fehler gefunden hatte. Schlauch wieder dran, jetzt wandert der Inhalt fest mit ins Bauteil.

„Sah aus, als wäre's nicht wichtig" ist die Diagnose, mit der die meisten Schäden anfangen.

Was läuft jetzt automatisch

Stand heute, eine knappe Woche nach dem Aufbau:

• Code-Änderung am Web-Anteil des Hotels (heisst „phpgridserver") → Werkstatt baut → Lieferschein-Buch wird gestempelt → Bauhof-Helfer rollt in sieben Sekunden aus.
  
• Code-Änderung am Verwaltungs-Anteil (heisst „akigrid") → identische Kette. Erster grüner Lauf war Lieferung Nr. 28 — vom Push bis zum laufenden Container etwa zehn Minuten, davon waren neun Minuten Tests, die sicherstellen, dass das Bauteil wirklich tut, was es soll.
  

Was nicht automatisch geht: Veröffentlichungen mit fester Versionsnummer (sogenannte „Tags"). Die landen zwar im Lager, aber das Lieferschein-Buch wird absichtlich nicht aktualisiert. Releases gehören zur Schlüsselübergabe, nicht zur täglichen Auslieferung.

Automatisch ist nicht automatisch immer richtig. Ein Release will angekündigt werden, kein nächtlicher Geist.

Was ich daraus gelernt habe

Drei Sachen, die ich beim Kran-Aufbau gelernt habe — gelten für Bauarbeiten und vermutlich auch ausserhalb:

1. Schreiben und Lesen sind zwei Berechtigungen, nicht eine. Es ist verlockend, einen Universalschlüssel zu machen, weil's beim Aufbau bequem ist. In dem Moment, wo der Universalschlüssel verlorengeht, ist alles offen. Lieber zwei Türen mit zwei Schlüsseln als eine Tür mit einem Generalschlüssel.
   
2. Ein Buch zwischen den Stationen ist mehr wert als direkte Zurufe. Wenn die Werkstatt direkt im Hotel rumpfuschen würde („ich tausch dir das mal kurz aus"), wäre das schneller, aber nicht nachvollziehbar. So steht in dem Buch jede Änderung mit Datum und Unterschrift. Wer was wann geliefert hat, ist sichtbar.
   
3. Sieben Sekunden sind keine Magie, sie sind Disziplin. Der Kran ist nicht schneller als ich es zu Fuss könnte, wenn ich's denn würde. Aber er macht es bei jeder Änderung, ohne zu murren, ohne Schritte zu vergessen. Ein langweiliger, gehorsamer Helfer, der jeden Tag dasselbe macht, ist mehr wert als ein genialer Held, der's einmal richtig macht und beim zweiten Mal vergisst.
   

Nächste Baustelle: das eigentliche Hotel — der akisim-Anteil — hängt noch nicht am Kran. Da läuft die Übergabe vom Code zur laufenden Region noch zu Fuss. Aber jetzt, wo der Kran steht, ist's nur noch eine Frage des Anbaus. Ich poste, was passiert.