09.03.2026, 23:00
Das mit webrtc hat manni mal vor monaten hier gepostet
|
Aki's Vibes
|
10.03.2026, 07:10
(09.03.2026, 23:00)Bogus Curry schrieb: Das mit webrtc hat manni mal vor monaten hier gepostet Ich weiss, aber damals war es noch nicht auf meinem Radar. ![[Bild: footert5jul.jpg]](https://i.postimg.cc/mgksQryk/footert5jul.jpg)
06.04.2026, 00:33
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 skillsSkills installierst du mit einem einzigen Befehl: Code: npx skills add vercel-labs/agent-skills@grill-me -g -ySie landen in Code: ~/.agents/skills/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:
Das Endergebnis: Von der globalen Home.md aus ist jetzt wirklich alles erreichbar. Keine Sackgassen mehr. Obsidian-spezifische Skills:
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-meDu 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
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-issuesDas 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
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 connectionDas grosse Bild: Code: IdeeDieser 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: # DeaktivierenClaude Code liest nur exakt Code: SKILL.mdWas 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
19.04.2026, 20:33
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:
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
![[-]](https://www.gridtalk.de/images/collapse.png)
The following 5 users say Thank You to Akira for this post:• Bogus Curry, Dorena Verne, LyAvain, Mareta Dagostino, Pius Noel 
19.04.2026, 20:42
Seeeehr spannend, Aki.
19.04.2026, 21:24
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
19.04.2026, 21:51
(19.04.2026, 21:24)Bogus Curry schrieb: 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:
Macht riesig Spass!
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:
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:
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:
Die beiden Stücke reden ständig miteinander. Und genau da setze ich an:
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.
The following 6 users say Thank You to Akira for this post:• Anachron, Bogus Curry, Dorena Verne, LyAvain, Mareta Dagostino, Pius Noel
27.04.2026, 15:17
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
28.04.2026, 22:26
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.
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:
Ob ich es schaffe, weiß ich noch nicht. Schätzung: drei bis sechs Monate für die heißen Phasen. Ich poste, was passiert.
The following 6 users say Thank You to Akira for this post:• Dorena Verne, Ezry Aldrin, Jupiter Rowland, LyAvain, Mareta Dagostino, Pius Noel |
|
|
Benutzer, die gerade dieses Thema anschauen: Akira, 1 Gast/Gäste