Aki's Vibes

[Bogus Curry]

Das mit webrtc hat manni mal vor monaten hier gepostet

[Akira]

Das mit webrtc hat manni mal vor monaten hier gepostet

Ich weiss, aber damals war es noch nicht auf meinem Radar.

[Akira]

Mein Vault hat ein Gehirn bekommen – KI-Skills in Obsidian und was sie für die Softwareentwicklung bedeuten
Ein Erfahrungsbericht aus drei Tagen experimentieren, schrauben und staunen.

Was ist Obsidian überhaupt?

Bevor ich anfange: Falls du Obsidian noch nicht kennst, hier die Kurzfassung.

Obsidian ist eine Note-Taking-App, die auf einem simplen Prinzip basiert: Deine Notizen sind ganz normale Markdown-Dateien auf deiner Festplatte. Keine Cloud, kein proprietäres Format, keine Vendor-Lock-in. Du besitzt deine Daten wirklich.

Das Besondere ist die Art, wie Obsidian Notizen miteinander verknüpft. Mit sogenannten Wikilinks ([[Notizname]]) verlinkst du Gedanken miteinander – ähnlich wie Wikipedia, nur für deinen eigenen Kopf. Das Ergebnis ist ein sogenanntes zweites Gehirn: Eine persönliche Wissensdatenbank, die mit dir wächst und sich an deine Art zu denken anpasst.

Ich nutze Obsidian als zentrale Schaltstelle für alles: Projekte, Ressourcen, Daily Notes, Reisenotizen, Musikrecherche für meine Radio-Sendung, Fotografie-Know-how, Literatur über KI-Entwicklung und natürlich technische Dokumentation für meine Open-Source-Projekte. Ein Vault, der echte Breite hat.

Das Problem mit grossen Vaults: Sie können schnell unübersichtlich werden. Karten ohne Verbindungen, veraltete Strukturen, verwaiste Verzeichnisse, halbfertige Gedanken. Das ist der Punkt wo KI ins Spiel kommt.


Claude Code als Vault-Assistent

Claude Code ist ein KI-Coding-Assistent von Anthropic, der direkt im Terminal läuft. Anders als ein reiner Chat-Bot hat er Zugriff auf Dateien, kann Verzeichnisse lesen, Dateien erstellen, bearbeiten und umbenennen – und das alles im Dialog mit dir. Denk an einen Assistenten, der nicht nur antwortet, sondern wirklich zupackt.

Was Claude Code besonders macht: Er kann mit deinem Obsidian-Vault als Arbeitsverzeichnis laufen. Das bedeutet, er liest und schreibt direkt deine Markdown-Notizen. Keine Umwege, kein Copy-Paste zwischen Tools.

In den letzten drei Tagen habe ich genau das getan – Claude Code in meinen Vault gesetzt und ihn systematisch verbessert. Aber der eigentlich interessante Teil ist ein Ökosystem, das ich dabei entdeckt habe: npx skills.


Das Skills-Ökosystem: Modulare KI-Superkräfte

Code:

npx skills

ist ein Paketmanager für KI-Agenten. Die Idee ist bestechend einfach: Ein Skill ist eine Markdown-Datei (SKILL.md) mit Anweisungen darin. Claude Code liest diese Datei beim Start und weiss dann plötzlich, wie er eine bestimmte Aufgabe erledigen soll – Schritt für Schritt, nach einem definierten Workflow.

Skills installierst du mit einem einzigen Befehl:

Code:

npx skills add vercel-labs/agent-skills@grill-me -g -y

Sie landen in

Code:

~/.agents/skills/

/grill-me
/write-a-prd
/prd-to-issues
/tdd

per Slash (/) command direkt im Terminal aufrufbar, kein Plugin, keine Konfiguration.

Das Verzeichnis ~/.agents habe ich als Symlink auf meinen Vault gelegt. Dadurch sind alle Skills direkt im Vault bearbeitbar, per pCloud auf alle Geräte synchronisiert, und ich kann sie anpassen – genau wie jede andere Notiz. Das Gleiche gilt für ~/.claude, das ebenfalls auf den Vault zeigt. Settings, Hooks, eigene Skills: alles versionierbar, alles überall verfügbar.

Was sich im Vault verändert hat

Ich hatte klassische Altlasten: MOC-Dateien (Maps of Content) die halb gefüllt waren, Karten ohne Verknüpfungen, Verzeichnisse ohne Home-Card, doppelte Einträge für denselben Inhalt. Mit Claude Code als Partner haben wir in systematischer Arbeit:

• Alle Bereiche bekommen saubere Home-Karten mit vollständigen Verlinkungen
  
• Analoge Fotografie als neues Unterverzeichnis aufgebaut
  
• Software-Verzeichnis für Fotografie-Tools angelegt (Digikam, Luminar Neo, Affinity Photo, ON1, Nikon Capture)
  
• Kunst als neuen Bereich erstellt – 39 Künstlerinnen und Künstler aus Museumsbesuchen in Málaga dokumentiert
  
• Blender von einer MOC-Datei in eine echte Home-Card umgewandelt
  
• Alle Ressourcen-Verzeichnisse vollständig mit allen enthaltenen Karten verlinkt
  

Das Endergebnis: Von der globalen Home.md aus ist jetzt wirklich alles erreichbar. Keine Sackgassen mehr.

Obsidian-spezifische Skills:

• obsidian-markdown – kennt Obsidian Flavored Markdown: Callouts, Wikilinks, Frontmatter, Embeds. Claude erstellt damit valide Dateien die Obsidian korrekt rendert.
  
• obsidian-cli – erlaubt es, den Vault via CLI zu steuern: Notizen öffnen, suchen, Tags setzen.
  
• obsidian-bases – für die neue Bases-Funktion in Obsidian (Datenbankansichten).
  
• json-canvas – für Canvas-Dateien, Obsidians visuelles Board-Format.
  
• defuddle – extrahiert sauberes Markdown aus Webseiten. Statt einer Website manuell abzutippen, sagst du Claude «lies diese URL» und bekommst direkt aufbereitetes Markdown zurück.
  

Der Software-Entwicklungs-Workflow: Vom Gedanken zum Code

Ich entwickle mehrere Open-Source-Projekte auf Codeberg – hauptsächlich akisim (OpenSim Region Server in .NET) und akigrid (OpenSim Grid Server in Go). Bisher: Idee im Kopf, irgendwie anfangen, Issues nach Gefühl erstellen.

Jetzt gibt es einen durchgehenden Workflow, der nichts dem Zufall überlässt.

Schritt 1: grill-me – Den Plan stress-testen

Bevor eine einzige Zeile Code geschrieben wird, kommt

Code:

/grill-me

zum Einsatz.

Du beschreibst deinen Plan und sagst: «Grill me on this plan.»

Was dann passiert ist verblüffend: Claude stellt eine Frage. Eine einzige. Wartet auf deine Antwort. Gibt eine Empfehlung. Fragt dann weiter. Immer eine Frage nach der anderen, immer mit einer eigenen Einschätzung. Er arbeitet sich durch jeden Ast des Entscheidungsbaums: Architektur, Abhängigkeiten, Schnittstellen, Testbarkeit, Edge Cases.

Die meisten Bugs entstehen nicht beim Coden – sie entstehen beim Planen. Unklare Anforderungen, übersehene Abhängigkeiten, Annahmen die niemand hinterfragt hat. grill-me macht diese Fehler sichtbar bevor sie teuer werden.

Schritt 2: write-a-prd – Das PRD erstellen

Ein PRD (Product Requirements Document) ist das Pflichtenheft der modernen Softwareentwicklung.

Code:

/write-a-prd

führt ein strukturiertes Interview, schaut sich die bestehende Codebase an und erstellt dann ein PRD nach einem bewährten Template:

• Problem Statement – Was ist das Problem aus Nutzerperspektive?
  
• Solution – Was ist die Lösung, konkret und verständlich?
  
• User Stories – Exhaustive Liste aller Szenarien
  
• Implementation Decisions – Architektur, Module, Interfaces
  
• Testing Decisions – Was wird getestet, wie, warum?
  
• Out of Scope – Was explizit nicht gemacht wird
  

Das Ergebnis wird direkt als Codeberg Issue angelegt. Kein Copy-Paste, kein manuelles Formatieren.

Schritt 3: prd-to-issues – Zerlegen in vertikale Slices

Code:

/prd-to-issues

übersetzt das grosse PRD in handhabbare Arbeitspakete.

Das Konzept dahinter heisst tracer bullet: Statt horizontale Schichten zu bauen (erst alle Datenbank-Änderungen, dann alle API-Änderungen, dann alle Tests), baut man dünne vertikale Scheiben, die durch alle Schichten gehen. Jeder Slice ist demobar, jeder Slice ist ein abgeschlossener Wert.

Der Skill schlägt die Zerlegung vor, du gibst Feedback, er iteriert. Dann erstellt er alle Issues in Dependency-Reihenfolge auf Codeberg – mit korrekten Blocker-Referenzen, mit den User Stories die jeder Slice abdeckt, mit klarer Acceptance Criteria.

Schritt 4: tdd – Red Green Refactor

Pro Issue:

Code:

/tdd

aufrufen, Issue-Nummer angeben, loslegen.

1. Red: Schreib einen Test der das gewünschte Verhalten beschreibt – und der fehlschlägt, weil der Code noch nicht existiert.
   
2. Green: Schreib den minimalen Code um den Test grün zu machen. Nicht mehr, nicht weniger.
   
3. Refactor: Jetzt den Code aufräumen. Tests dürfen nicht brechen.
   

Was der Skill dabei besonders gut macht: Er testet Verhalten durch öffentliche Interfaces, nicht Implementierungsdetails. Ein guter Test bricht nicht wenn du eine Funktion intern umbenennst – er bricht nur wenn sich das sichtbare Verhalten ändert.

Nach grünen Unit Tests kommen Acceptance Tests mit Godog – Cucumbers Go-Implementation. Gherkin-Syntax, lesbar wie Prosa:

Code:

Feature: Voice connection
  Scenario: Client connects via WebRTC
    Given a running grid server
    When a client initiates a WebRTC handshake
    Then the connection is established

Das grosse Bild:

Code:

Idee
  ↓
grill-me       → Plan durchdenken, Fehler finden bevor sie entstehen
  ↓
write-a-prd    → PRD erstellen → Codeberg Issue
  ↓
prd-to-issues  → In vertikale Slices zerlegen → Issues erstellen
  ↓
tdd            → Issue für Issue implementieren (Red → Green → Refactor)
  ↓
Godog          → Acceptance Tests fürs Feature
  ↓
Commit + Close → Nächster Slice

Dieser Workflow klingt aufwändig. Er ist es nicht – er ist schneller als das Chaos, das er ersetzt. Claude übernimmt die strukturellen Schritte, du triffst die inhaltlichen Entscheidungen.


Ein Wort zu Token-Effizienz

Skills sind mächtig, aber sie haben einen Preis: Jede SKILL.md wird bei jeder Claude-Anfrage in den Kontext geladen. Fünf grosse Skills gleichzeitig aktiv? Das sind Tausende von Tokens Overhead, bevor du überhaupt eine Frage gestellt hast.

Die Lösung ist simpel – Skills umbenennen:

Code:

# Deaktivieren
mv SKILL.md disabled_SKILL.md

# Reaktivieren  
mv disabled_SKILL.md SKILL.md

Claude Code liest nur exakt

Code:

SKILL.md

. Alles andere ignoriert es. Ich halte aktuell nur git-guardrails und tdd permanent aktiv. Die grossen Skills aktiviere ich nur wenn ich sie wirklich brauche.


Was sich wirklich verändert hat

Drei Tage, zwei Dimensionen:

Im Vault: Was vorher ein wachsendes Chaos war, ist jetzt eine navigierbare Struktur. Jedes Verzeichnis hat eine Home-Karte. Jede Home-Karte verlinkt alle Inhalte. Die globale Home.md ist wirklich ein Einstiegspunkt, kein dekorativer Index.

In der Entwicklung: Was vorher vom Bauchgefühl abhing, hat jetzt einen Prozess. Nicht als Bürokratie, sondern als Sicherheitsnetz. Der Plan wird hinterfragt bevor er umgesetzt wird. Issues sind klein genug um abgeschlossen zu werden. Tests beschreiben Verhalten, nicht Implementierung.

Das Beste daran: Alles ist portabel. Die Skills, die Vault-Struktur, die Settings, die Hooks – alles liegt in Markdown-Dateien, versioniert, synchronisiert, auf jedem Gerät sofort verfügbar.

Ein zweites Gehirn mit KI-Muskelkraft dahinter. Das fühlt sich gut an.

– Aki, OpenSim-Betreiber / Radio-DJ / Vault-Archäologe

[Akira]

akigrid – Wochenend-Update (18./19. April 2026)

Dieses Wochenende war richtig produktiv. Ich arbeite gerade an akigrid – einem selbst geschriebenen Ersatz für den Server-Kern, der hinter einer OpenSimulator-Grid-Instanz läuft (vergleichbar mit dem, was Robust.exe bei klassischen OpenSim-Setups macht). Das Ziel: moderner, stabiler, besser wartbar – und speziell auf meine eigene Grid-Infrastruktur zugeschnitten.

Samstag

Aufräumen & Grundlagen
Bevor man ein Haus baut, muss das Fundament stimmen. Ich bin dabei ein paar alte Überbleibsel aus früheren Projekt-Experimenten bereinigt und die Projektbeschreibungen für akigrid und seinen Schwesterserver akisim (der den Regions-Server ersetzt) massiv umzubauen – klarer, ehrlicher, mit realistischen Zielen.

Datenbank-Struktur angelegt
Der Server muss irgendwo seine Daten speichern – Grid-Einstellungen, Benutzerinfos, Regionen usw. Ich habe damit angefangen, die nötige Datenbankstruktur aufzubauen. Der erste Schritt war eine Tabelle für grundlegende Grid-Parameter. Klingt unspektakulär, ist aber die Basis für alles andere. Das Ganze wurde mit automatisierten Tests abgesichert, die beim Start des Servers prüfen ob alles korrekt angelegt wurde.

Architekturentscheidung: Lesen und Schreiben sauber trennen
Eine wichtige Design-Entscheidung für den Code: Abfragen (z.B. "was steht in der Datenbank?") und Änderungen (z.B. "schreib das in die Datenbank") werden im Code klar voneinander getrennt. Das macht den Server langfristig einfacher zu warten und zu testen – und ist eine bewusste Verbesserung gegenüber dem bisherigen PHP-System, das beides munter durcheinander mischt.

Sonntag

Grid-Info-Endpunkt fertiggestellt
Wenn ein Viewer (z.B. Firestorm) sich mit einem Grid verbindet, fragt er als erstes: "Wer bist du eigentlich? Wie heißt das Grid, wie lautet deine Adresse, welche Funktionen bietest du?" – Das ist der sogenannte Grid-Info-Endpunkt. Der ist jetzt vollständig implementiert, getestet und läuft. Ein wichtiger erster Meilenstein: akigrid kann sich gegenüber Viewern korrekt vorstellen.

Automatische Bereitstellung (CI/CD)
Bisher musste ich nach jeder Änderung den Server manuell auf dem Hetzner-Server aktualisieren. Das ist jetzt automatisiert: Sobald ich neuen Code hochlade, wird automatisch ein fertiges Server-Paket gebaut und bereitgestellt. Ich musste dabei ein kleines Netzwerkproblem auf dem Server lösen (ein Systemdienst hatte sich selbst in einen inkonsistenten Zustand manövriert), aber danach lief alles reibungslos durch.

Übergangsphase: Alter und neuer Server laufen parallel
Das bisherige Grid läuft noch auf dem alten PHP-basierten Server. Damit ich nicht von heute auf morgen alles umstellen muss, habe ich eine Brücke gebaut: Der alte Server leitet bestimmte Anfragen transparent an akigrid weiter. Für Viewer und Nutzer ändert sich nichts – im Hintergrund übernimmt akigrid aber schon einen Teil der Arbeit.

Eingebaute Überwachung
Ein Server, der im Stillen vor sich hin läuft und niemanden informiert wenn etwas nicht stimmt, ist schwer zu betreiben. Ich habe deshalb Schritt für Schritt ein vollständiges Überwachungssystem eingebaut:

• Tracing: Jede Anfrage hinterlässt eine Spur durch den Server – wie ein Röntgenbild das zeigt wo Zeit verbraucht wird und wo Fehler auftreten. Das hilft enorm bei der Fehlersuche.
  
• Metriken: Zahlen die kontinuierlich gesammelt werden – wie viele Anfragen pro Minute kommen rein, wie lange braucht die Datenbank im Schnitt, gibt es Ausreißer? Diese Daten können in einem Dashboard visualisiert werden.
  
• Automatische Tests für die Überwachung selbst: Auch das Überwachungssystem hat Tests – es wird geprüft ob die Metriken und Spuren tatsächlich ankommen und die richtigen Informationen enthalten.
  

Das alles klingt nach viel Overhead – aber ein Server ohne Überwachung ist wie ein Auto ohne Armaturenbrett. Man merkt erst dass etwas nicht stimmt wenn es zu spät ist.

Wo stehen wir jetzt?

akigrid kann sich gegenüber Viewern korrekt vorstellen, läuft in einem Docker-Container, wird automatisch gebaut und deployed, hat eine Datenbankanbindung mit sauberer Migrationshistorie, und ist mit einem vollständigen Überwachungsstack ausgestattet. Das Fundament steht.

Als nächstes geht es an die eigentlichen Grid-Dienste: Zuerst mal einen Dienst den wir noch nicht haben XBakes

Codeberg: codeberg.org/AkiraSonoda/akigrid

[Dorena Verne]

Seeeehr spannend, Aki.

[Bogus Curry]

Hallo zusammen ;D

Hab hier ein Video über ein KI Konzept mit Claude Code, wo es drum geht der KI ein Art Datenbank zu erstellen. Worauf die KI sich beziehen kann, wenn man ein neuen Chat beginnen will oder muss. Dann wird diese Datenbank, de als Wiki da liegt, von der der KI zu rate bezogen und kann sich daraus die Infos holen.

Finde das Konzept sehr intressant, auch weil darin das Tool Obsidian benutzt wird, was kostenlos ist. Vielleicht ist es ja für den einen oder andere das intressant.;D

[Akira]

Hab hier ein Video über ein KI Konzept mit Claude Code, wo es drum geht der KI ein Art Datenbank zu erstellen. Worauf die KI sich beziehen kann, wenn man ein neuen Chat beginnen will oder muss.

Schon umgesetzt

Habe Skills für:

• Obsidian
  
• Software Entwicklung
  
• Musik Agent
  

Macht riesig Spass!

[Akira]

Clean Architecture, OpenSim und warum akisim/akigrid einen Neuanfang wagen

Ein Haus braucht ein Fundament – Software auch

Stell dir vor, du baust ein Haus. Du würdest nicht zuerst die Tapete aussuchen und dann
schauen, ob die Wände dazu passen. Du fängst beim Fundament an, ziehst die tragenden
Mauern hoch, packst dann Strom und Wasser rein und ganz am Ende kommen Möbel,
Anstrich und Vorhänge. Falls dir die Vorhänge nicht mehr gefallen – kein Problem,
du hängst neue auf. Das Haus steht weiter.

Genau das ist die Idee von Clean Architecture – einer Bauweise für Software, die
der Programmierer Robert C. Martin (Spitzname „Uncle Bob“) im Jahr 2012 populär
gemacht hat.

Was steckt dahinter?

Software ist innen drin in Schichten aufgebaut – wie eine Zwiebel. Ganz innen liegen
die Dinge, die sich kaum ändern: die Geschäftsregeln. Bei einer Bank zum Beispiel
„Ein Konto darf nicht ins Minus rutschen, ausser es hat einen Dispo“. Diese Regel ist
heute, morgen und in zehn Jahren dieselbe – egal ob du sie auf einem Webformular,
einer Smartphone-App oder am Bankschalter anwendest.

Weiter aussen liegen die austauschbaren Sachen: die Datenbank, das Web-Framework,
das hübsche Bedienfeld. Das sind die Vorhänge. Die kann man wechseln, ohne dass das
ganze Haus zusammenbricht.

Die goldene Regel dabei: Innere Schichten dürfen nichts von äusseren Schichten wissen.
Die Geschäftsregel „kein Minus ohne Dispo“ darf nicht wissen, dass es PostgreSQL,
ein iPhone oder einen Touchscreen gibt. Sie kümmert sich nur um Konten und Geld.

Klingt simpel, ist aber unfassbar mächtig. Denn dadurch kann man:

• Die Datenbank austauschen, ohne die Geschäftslogik anzufassen
  
• Die Bedienoberfläche neu bauen, ohne alles drumherum zu zerlegen
  
• Den Kern der Software in einer halben Sekunde durchtesten – ohne Datenbank, ohne Server, ohne nichts
  

Und wo steht OpenSimulator?

OpenSimulator (kurz OpenSim) ist eine Software, mit der
sich virtuelle 3D-Welten betreiben lassen – die Open-Source-Antwort auf Second Life. Eine
beeindruckende Codebasis, gewachsen seit 2007, mit unzähligen Features.

Aber: OpenSim ist nicht in dieser sauberen Schicht-Bauweise gemacht. Das war damals
auch keine Designentscheidung, denn das Projekt ist über fast zwei Jahrzehnte
organisch gewachsen. Geschäftslogik, Datenbankzugriffe, Netzwerkprotokolle und
Bedienoberflächen sind oft kreuz und quer miteinander verknüpft.

Bildlich gesprochen: Stell dir eine Werkstatt vor, in der Werkbank, Lager,
Verkaufstresen und Bürotisch alle in einem einzigen Raum stehen. Funktioniert –
aber wenn du den Verkaufstresen umstellen willst, fliegt dir auch die Werkbank
um die Ohren.

Konkret heisst das:

• Die Kommunikation zwischen Servern läuft über XML-RPC, ein Protokoll aus den späten 90ern. Funktioniert, ist aber heute ungefähr so modern wie ein Faxgerät neben einem Smartphone.
  
• Welt-Logik, Datenbankzugriff und Netzwerkkram leben in denselben Klassen. Wer eine Sache ändern will, muss aufpassen, dass nicht drei andere kaputt gehen.
  
• Die Software lässt sich nur schwer in Häppchen testen, weil alles voneinander abhängt.
  

Das ist kein Vorwurf an die OpenSim-Entwickler – im Gegenteil, das Projekt ist eine
gewaltige Leistung. Es ist einfach so, dass die Welt der Softwarearchitektur seit
2007 deutlich weitergezogen ist.

Was sind akisim und akigrid?

Hier kommen meine zwei Projekte ins Spiel: akisim und akigrid.

OpenSim besteht im Kern aus zwei Teilen:

• Region Server – die Maschine, auf der eine virtuelle Insel oder Welt läuft. Hier passiert die ganze 3D-Action: Avatare bewegen sich, Objekte werden angefasst, Skripte laufen.
  
• Grid Server (heisst bei OpenSim „Robust“) – die zentrale Verwaltung. Wer ist eingeloggt? Wo wohnt mein Avatar? Welche Inseln gibt es? Wo liegen meine Inventar-Objekte?
  

Die beiden Stücke reden ständig miteinander. Und genau da setze ich an:

• akisim ist ein Fork von OpenSim – also eine eigene Variante des Region Servers. Verschlankt, aufgeräumt, ohne den ganzen alten Standalone-Kram, der heute keiner mehr braucht. Geschrieben in C# auf .NET 8.
  
• akigrid ist der Grid Server komplett neu gebaut – in Go (einer modernen Programmiersprache von Google), mit sauberer Schicht-Architektur und modernen Schnittstellen (gRPC statt XML-RPC).
  

Die beiden sind als Paar gedacht und sollen gemeinsam den klassischen
OpenSim-Stack ersetzen.

Und wieso bringt das einen Vorteil?

1. Sauberes Fundament
akigrid/akisim wird von Anfang an nach Clean Architecture gebaut. Geschäftslogik
in der Mitte, Datenbank- und Netzwerkkram aussen rum. Wenn morgen jemand
sagt „Ich will MariaDB durch PostgreSQL ersetzen“ – kein Drama. Die Schicht
mit der Datenbank wird ausgetauscht, alles andere bleibt wie es ist.

2. Modernes Reden zwischen den Servern
Statt XML-RPC reden akisim und akigrid über moderne Schnittstellen
(REST/gRPC). Das ist schneller, robuster, besser zu beobachten und
einfacher zu erweitern. Wo OpenSim quasi noch Briefe per Postkutsche
verschickt, telefonieren akisim und akigrid via WhatsApp.

3. Testbar bis ins Detail
Weil die Schichten sauber getrennt sind, kann ich einzelne Stücke
isoliert testen. Funktioniert die Login-Logik? Test in einer Hundertstelsekunde
beantwortet, ohne dass irgendwo eine Datenbank oder ein Server hochfahren muss.
Das macht das Projekt langfristig pflegbar – ein riesiger Unterschied.

4. Beobachtbar im Betrieb
akigrid bringt von Tag eins moderne Werkzeuge zur Beobachtung mit:
OpenTelemetry, Prometheus-Metriken, verteilte Traces.
Wenn etwas langsam ist, sieht man genau wo. Bei OpenSim sucht man
oft im Nebel.

5. Klare Aufgabenteilung
akisim kümmert sich nur um die Welt selbst – das, worin es richtig
gut ist (Physik, Avatare, Objekte, Skripte). akigrid kümmert sich
nur um die Verwaltung. Jeder macht was er gut kann, statt dass eine
Software alles gleichzeitig versucht.

6. Viewer-Kompatibilität bleibt
Wichtig: Die Programme, mit denen Nutzer in die virtuelle Welt
einsteigen (Firestorm, Cool VL Viewer und Co.), funktionieren
weiterhin ohne Anpassung. Das Protokoll, das die Viewer sprechen,
wird respektiert. Niemand muss sich umgewöhnen.

Fazit

Clean Architecture ist im Grunde simpel: Bau dein Software-Haus mit einem
Fundament, tragenden Wänden und austauschbaren Vorhängen. Was sich nie ändert
gehört nach innen, was sich oft ändert gehört nach aussen.

OpenSim ist ein grossartiges Projekt – aber nach 18 Jahren organischen Wachstums
schwer zu pflegen. akisim und akigrid sind mein Versuch, den Stack mit der
Erfahrung von heute neu aufzustellen: schlank, modern, sauber geschichtet und
genau so kompatibel wo es muss (zu den Viewern), dass sich für die Nutzer am
Ende nichts ändert – ausser dass alles schneller, stabiler und langlebiger wird.

Oder kurz gesagt: gleiche virtuelle Welt, neues Fundament.

[Bogus Curry]

Hallo Akira ;D

Das klingt super, wenn du ein Tester brauchst, dann bin ich gerne zu stelle. Denke da bin ich bestimmt nicht der einzige ;D

[Akira]

Wie ich akisim umbaue, ohne die Gäste rauszuwerfen

Oder: Was ich gerade über Software-Architektur lerne, am Beispiel von akisim

Ich bastle gerade an einem ziemlich verrückten Projekt: einem Region-Server für virtuelle Welten. Das ist die Software, die im Hintergrund läuft, wenn du dich in OpenSim einloggst und mit deinem Avatar durch eine Region spazierst. Sie verwaltet die Bäume, die Häuser, die anderen Avatare, die Physik, das Chatten – alles.

Das Projekt heißt akisim. Es startet als Fork (Abzweigung) eines bestehenden Projekts namens OpenSim, das es seit fast zwanzig Jahren gibt. Und genau da fängt das Drama an.

Das Hotel-Problem

Stell dir OpenSim als ein altes, verwinkeltes Hotel vor, an dem zwanzig Jahre lang gebaut wurde. Jeder Eigentümer hat irgendwo einen Anbau drangepappt. Die Heizung läuft durchs Dachgeschoss, das Telefonkabel führt durch den Pool, und niemand weiß mehr, warum die Klingel von Zimmer 47 das Licht in der Lobby auslöst.

Es funktioniert. Irgendwie. Aber jeder Handwerker, der reinkommt, braucht drei Tage, bis er auch nur einen tropfenden Wasserhahn findet.

So sieht der Code von OpenSim aus. Knapp hundert Teilprojekte, davon siebzehn mit doppelten Namen (Erblast eines längst entsorgten Plugin-Systems). Die Datenbank-Schicht kennt die 3D-Welt-Schicht. Die HTTP-Schicht hat statische Hilfsfunktionen, die irgendwer in dreihundert anderen Stellen im Code aufruft. Wenn du etwas änderst, weißt du nie, was woanders kaputtgeht.

Ich will das Hotel renovieren. Im laufenden Betrieb. Mit Gästen drin.

Erste Entscheidung: vier saubere Stockwerke

Statt das Chaos zu erweitern, setze ich akisim aus vier sauberen Stockwerken auf. Jedes Stockwerk hat genau eine Aufgabe, und Stockwerke reden nur in eine Richtung miteinander – von außen nach innen.

• Erdgeschoss (Domain): das Tragwerk. Hier wohnen die Konzepte – was ist ein Avatar, was ist eine Region, was ist eine Berechtigung. Reine Idee, kein Schnickschnack.
  
• Erster Stock (Application): der Concierge. Nimmt Aufträge entgegen ("dieser Avatar will da rein") und orchestriert, was passieren muss.
  
• Zweiter Stock (Adapter): die Türen und Fenster. Übersetzt zwischen drinnen und draußen – die Sprache, mit der dein Viewer redet, ist eine andere als die Sprache des Concierges.
  
• Dachgeschoss (Infrastructure): Keller-Technik in Dachgeschoss-Verkleidung. Datenbank, HTTP, Telemetrie, der ganze technische Kram.
  

Plus ein kleines Hausmeister-Büro (im Code heißt es "Composition Root"), das alles zusammenstöpselt.

Das klingt nach mehr Aufwand. Ist es auch – kurzfristig. Aber wenn jemand morgen kommt und sagt "wir wechseln die Datenbank", muss ich nur das Dachgeschoss anfassen. Das Erdgeschoss merkt davon nichts.

Die radikalste Entscheidung: das Erdgeschoss bleibt nackt

Hier wird's interessant, und das ist die Entscheidung, an der ich mich gerade selbst zur Disziplin zwinge:

Das Erdgeschoss darf nichts mitbringen, was nicht aus dem Erdgeschoss selbst kommt. Keine fremden Werkzeuge. Keine Bibliotheken. Keine Frameworks. Nichts.

Das klingt erstmal albern. Programmierer lieben Werkzeuge. Es gibt für alles ein fertiges Paket – fürs Loggen, für die Datenbank, für HTTP, für Dependency Injection (frag nicht). Und in diesem einen Stockwerk darf ich davon gar nichts verwenden.

Warum? Drei Gründe, in einfach:

Erstens, weil Werkzeuge altern. Vor zehn Jahren war eine bestimmte Logging-Bibliothek der Standard. Heute ist sie veraltet. In OpenSim hängt dieses Ding aber überall drin – auch in der innersten Schicht. Sie auszutauschen ist ein Monatsprojekt. Wenn das Erdgeschoss frei von allem Werkzeug bleibt, kann ich oben drüber jedes Tool austauschen, ohne dass das Tragwerk wackelt.

Zweitens, weil Ausnahmen nie bei einer bleiben. Ich war in der Versuchung – versprochen. "Eine winzige Bibliothek nur, ist ja nicht wirklich ein Werkzeug, ist nur Klempner-Zeug." Sobald du die erste Ausnahme zulässt, kommt die zweite, dann die dritte. Nach drei Jahren hast du zwölf Ausnahmen, und niemand erinnert sich, warum die Regel mal existiert hat. Lieber Null als "Null-Komma-irgendwas".

Dritter Grund, der mich tatsächlich überzeugt hat: Die Tests werden absurd einfach. Wenn das Erdgeschoss von nichts abhängt, kann ich seine Logik testen, indem ich Werte reingebe und Werte rausbekomme. Keine Datenbank, keine Schein-Objekte, keine Setup-Akrobatik. Funktioniert, oder funktioniert nicht. Schwarz-Weiß.

Drei Sachen, die ich mir verboten habe

Ich habe ein paar weitere Regeln aufgestellt, die ich kurz übersetze:

"Das Wort Modul will ich nicht mehr sehen." OpenSim hat ein Plugin-System mit etwa fünfzig Modulen. Die kleben überall an der zentralen Welt-Klasse und fragen sich gegenseitig nach Funktionen – wie Mitarbeiter, die statt im Telefonbuch zu schauen jedes Mal durch alle Büros laufen und "Hat einer von euch zufällig…?" rufen. In akisim wird das durch normale Service-Aufrufe ersetzt. Das spart langfristig Hunderte von kleinen Verschachtelungen.

"Pro Aufgabe genau eine Lösung." OpenSim hat für viele Aufgaben drei bis fünf konkurrierende Implementierungen – historisch gewachsen, weil sich nie jemand getraut hat, die alten zu löschen. Ich lösche jetzt einfach. Der Endzustand ist klar: ein Weg, eine Implementierung. Wer eine Alternative will, kann forken – aber im Standard-akisim gibt's nur eine Tür pro Zimmer.

"Keine Plugins, keine Add-ons." Das alte System wollte erweiterbar sein wie Firefox. In der Praxis hat das eine Galerie aus halbgaren Halb-Projekten produziert, die alle drei Schichten kreuzen und keiner versteht. Wenn jemand was Neues bauen will, baut er's direkt in die Schichten – und schaltet es per Konfig an oder aus. Reicht.

Die Pointe: kein Big Bang

Das wichtigste Prinzip kommt zum Schluss, weil es alle anderen erst möglich macht:

Jeder Zwischenzustand muss laufen.

Ich darf nicht das alte Hotel sprengen, dann ein neues bauen, und hoffen, dass die Gäste so lange im Park warten. Die Renovierung läuft Zimmer für Zimmer. Wenn ich morgen aufhöre – egal in welchem Zustand – funktioniert das Hotel weiter.

Konkret heißt das: das alte OpenSim und das neue akisim laufen parallel im selben Programm. Ich verschiebe Funktionen Stück für Stück rüber. Beim Start sieht das alte System aus wie ein Hotel mit einem neuen Eingangs-Pavillon davor. Beim Ende sieht es aus wie ein neues Hotel mit einem stillgelegten Altbau, der irgendwann abgerissen werden kann – oder eben stehenbleibt, falls keiner ihn mehr betritt.

Niemand muss in einem Zelt schlafen. Das ist mir wichtig.

Was ich daraus gelernt habe

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

1. Eine harte Regel ist einfacher zu halten als eine weiche. "Null Werkzeuge im Erdgeschoss" ist leichter durchzusetzen als "nur die wirklich wichtigen Werkzeuge im Erdgeschoss".
   
2. Wenn etwas dreißig Mal kopiert ist, ist nicht das Kopieren das Problem. Das Problem ist, dass das Original an der falschen Stelle liegt.
   
3. Renovierung schlägt Abriss. Auch wenn der Abriss verlockender aussieht, wenn man morgens reinkommt und die alten Tapeten anschaut.
   

Ob ich es schaffe, weiß ich noch nicht. Schätzung: drei bis sechs Monate für die heißen Phasen. Ich poste, was passiert.