Aki's Vibes

[akira]

Huhu zusammen,

Nein, hier geht es nicht um Musik, da wär ich wohl im falschen Forum ...

tl;dr Hier geht es um eine Beschreibung von Vibe Coding wie ich es sehe und was ich vor kurzem umgestellt habe, um den Region-Server zu optimieren. Observability, OpenTelemetry, Grafana Cloud sind Themen.


Vielleicht zuerst eine kleine Definition:

Vibe Coding ist ein relativ neuer Begriff in der Programmier-Community, der einen Programmierstil beschreibt, bei dem man sich mehr auf das "Gefühl" und den Flow verlässt als auf strenge Planung oder Best Practices.

Die Kernidee hinter Vibe Coding:

• Man schreibt Code intuitiv, ohne grosse Vorplanung oder Architektur-Überlegungen
• der Fokus liegt auf schnellem Experimentieren und "einfach mal machen"
• weniger Sorgen um perfekte Struktur, Dokumentation oder Tests
• Man lässt sich von der Stimmung und Kreativität des Moments leiten

Dann gibt es noch den Begriff Agentic Development auch hier:

Die Kernidee hinter Agentic Development:

• Fokus: KI-Agenten übernehmen ganze Entwicklungsaufgaben autonom
• Ansatz: "Ich delegiere komplexe Tasks an einen KI-Agenten"
• Kontrolle: Der Agent arbeitet selbstständiger - plant, implementiert, testet teilweise eigenständig
• Typisch: KI schreibt ganze Features, refactored Code, debuggt, nutzt Tools eigenständig
• Werkzeug: Spezialisierte KI-Agenten (wie Claude Code, Devin, Cursor mit Agent Mode)

Hauptunterschied:

Vibe Coding ist eine Arbeitsweise - ein lockerer, Flow-orientierter Stil, den man mit oder ohne KI praktizieren kann.

Agentic Development ist ein Delegationsmodell - man übergibt grössere Verantwortung an autonome KI-Systeme, die komplexere Aufgaben eigenständig lösen.

überschneidung

In der Praxis kombinieren viele Entwickler beides: Sie nutzen agentic tools (wie Claude Code), um sich auf den Vibe zu konzentrieren - also schnell Ideen umzusetzen, ohne sich in Details zu verlieren. Die KI übernimmt die "Denkarbeit" für Implementierungsdetails, während der Mensch im kreativen Flow bleibt.

Mein Vibe im OpenSim

Ich kenne die Architektur des Projekts mehr oder weniger. Ich weiss, was ich erzielen will (kleine Schritte). Dazu nutze ich eine Umgebung, welche mir viel Arbeit abnimmt.

Die beste Erfahrung habe ich mit Claude Code gemacht. Er will eine Änderung machen, zeigt mir dies an und ich entscheide, ob er loslegen soll. Nachteil von Claude Code. Kostet Geld. Aber ich kann den Pro-Plan von Claude nutzen. Kostet pro jahr etwa 160 Euro. Natürlich hab ich da nicht Tokens ohne Ende. Es ist mir schon oft passiert, dass ich eine Meldung kriege: Deine Token sind aufgebraucht, der Reset findet um 20:00 Uhr statt. Also Zwangspause bis 20:00 Uhr. Es existieren noch andere Modi die sind jedoch viiiiel teurer. Und Claude Code funktioniert nur mit Claude zusammen.

In letzter Zeit wird gerade OpenCode gehyped. Hat durchaus auch Vorteile. Es ist möglich beliebige Modelle zu nutzen auch kostenlose. OpenCode ist jedoch näher bei Agentic Development und ich werde da nicht warm damit, den Agent grössere Arbeiten machen zu lassen. Und um die Claude Modelle zu nutzen, brauch ich API Token. Mit OpenCode die Claude Pro Schnittstelle zu nutzen lief bis vor Kurzem, aber Anthropic hat dies nun unterbunden. Und API Token sind sehr teuer.

Vibe von Mistral existiert auch noch. Hat ebenfalls die Möglichkeit gratis Modelle zu nutzen. Ist vom Stil her näher an Claude Code. Und Mistral bietet einen gratis Zugang zu den eigenen Modellen. Begeisterung hält sich aber noch in Grenzen.

Let's do something

Eine Frage welche mich interessiert. Wann läuft ein OpenSim Region Server gut. Und wann nicht und wie sehe ich das. Observability ist das Zauberwort. Hier eine kleine Erklärung:

Observability ist die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Ausgaben zu verstehen und zu analysieren. Der Begriff stammt ursprünglich aus der Kontrolltheorie, hat sich aber vor allem in der Software-Entwicklung und IT-Operations etabliert.

Die drei Säulen der Observability:

Logs – Detaillierte Ereignisaufzeichnungen, die beschreiben, was zu einem bestimmten Zeitpunkt passiert ist
Metrics – Numerische Messwerte über Zeit (z.B. CPU-Auslastung, Response Times, Fehlerraten)
Traces – Verfolgung von Requests durch verteilte Systeme hinweg

Logs habe ich. Kein Thema. Metrics fehlen mir. Klar kann ich mit einem Profiler rein, ist aber für den Betrieb zu heftig. Aber auch dazu gibt es eine Lösung:

OpenTelemetry (oft abgekürzt als OTel) ist ein Open-Source-Framework für Observability, das zum Standard für das Sammeln von Telemetriedaten aus Anwendungen geworden ist.

Was macht OpenTelemetry?

Es bietet eine einheitliche, herstellerneutrale Methode zum Instrumentieren, Generieren, Sammeln und Exportieren von Telemetriedaten (Traces, Metrics, Logs). Statt für jedes Observability-Tool eine eigene Integration zu bauen, verwendest du OpenTelemetry einmal und kannst dann flexibel zwischen verschiedenen Backend-Anbietern wechseln.

Backend-Anbieter also Systeme, welche die OpenTelemetry Daten sammeln und grafisch auswerten, gibt es einige. Kann man sich selber installieren. Jaeger und Zipkin kommen mir da in den Sinn. Die beiden sind spezialisiert auf Traces. Will ich aber im Moment noch nicht. Vorerst brauch ich Logs und Metrics.

Grafana resp. Grafana Cloud war dann die Lösung. Bei Grafana Labs kriegt man eine Grafana Cloud Instanz für Lau mit grosszügig bemessenem Storage. Schnell subscribed und nach 10 Minuten war dies eingerichtet.

Ok was brauche ich nun für OpenTelemetry in meinem Region-Server? Hab ich dann Claude Code gesagt, er solle mir doch bitte OpenTelemetry für Logs und Traces einbauen. Unter anderem kamen da diese Libraries neu in den Region-Server mit rein:

Code: Alles auswählen

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol
dotnet add package OpenTelemetry.Instrumentation.Http

Im Monitoring und Logging Teil des Region-Servers mussten noch einige Anpassungen gemacht werden. Das war ein ziemliches Try-and-Error Spiel. Hatte dann zur Folge, dass noch wesentlich mehr Libraries notwendig wurden.

Einen Region-Server zu bauen ist per Standard runprebuild.sh und compile.sh. Die Abhängigkeiten der Packages werden im prebuild.xml beschrieben usw. Leider funktioniert nur OpenSim mit diesem Prebuild Gedöns. Der Rest der Welt nutzt den NuGet Package Manager. Dieser Prebuild Mechanismus war mir schon lange ein Dorn im Auge. Die Wahrheit liegt in den csproj files und nicht in einem Prebuild XML. Entwicklungsumgebungen sind auf NuGet optimiert und dort ist die Wahrheit halt in den *.csproj files ( wie in Java in den *.pom files ).

Zusammen mit Claude Code war der Build Prozess recht rasch umgebaut. Die Schwierigkeit: Die Package-Verwaltung in OpenSim ist gelinde gesagt ein Desaster oder schlichtweg nicht existent. Da liegen *.dll herum in einer Version, welche gefühlt Jahrzehnte alt sind. Zu einigen DLL gibt es kein NuGet Package und woher sie kommen ist auch unklar. Deshalb haben liegen im Git des OpenSim auch noch dll rum, was eigentlich nicht die feine Art ist.

Egal damit lebe ich erst mal und nach einigen Iterationen war auch dieses Problem gelöst. Und dann Tadaaa:



Vielleicht fällt auf: otel_heartbeat_seconds ist bei 56 Jahren und tendenz steigend. Da hat Claude Code noch was falsch gemacht. Er sendet nur die Timestamps ab Epoch (1.1.1970) und nicht die Differenz von zwei Timestamps. Muss ich ihm noch austreiben.



Find ich voll Cool. Logs und Metrics an einem Ort, zentral.

Fazit:

• Build System modernisiert (NuGet)
• OpenTelemetry Logs und Metrics eingebaut
• Zeilen codiert: 0

Nächstes mal mehr zu weiteren Vibes
Liebe Grüsse
Akira

[akira]

Huhu zusammen,

tl;dr Beobachtungen bei unserer Party zum 11 Jährigen Bestehen des Grid und Ersatz einer Grafikbibliothek.

Diese Woche, welche in unserer Geburtstagsparty endete, hab ich einiges hingekriegt. Aber lasst mich mit der Geburtstagsparty beginnen. Ich habe ja Ko Suai und Dereos Plaza mit OpenTelemetry ausgerüstet. Ein Event wie eine Party ist spannend zu beobachten und anschliessend zu analysieren. Hier mal ein Screnshot der gesamten Party:



Ich werde jetzt nicht jedes Feld einzeln erklären. Wen's interessiert, darf gerne fragen. Ansonsten die KI eurer Wahl kann dies auch selbst gut erklären. Das Bild sieht etwa so aus wie ich es erwartet habe. Ab 19:30 Uhr, da sind Ly, Samira und ich auf der Sim aufgeknallt. Nun Beginnen die Kurven stark zu oszillieren. Das dauerte an bis etwas nach 22 Uhr als andauernd neue Gäste eintrafen. Danach lief die Party und irgendwann wurde es spät für einige und am Schluss waren wir noch zu fünft auf der Sim und haben dann gegen 01:00 Uhr Schluss gemacht.



Ein paar mal EINE Aufgabe, welche in dem Thread Pool zur Abarbeitung in der "Warteschlange" standen. Schon mal sehr gut! Das heisst, die Aufgaben wurden alle zügig erledigt. Dass einiges zu tun war, zeigt diese Grafik:



Viel zu tun und rasch erledigt. So soll es sein! Natürlich gab es auch viele Warnungen und Fehler:



Aber nichts Aussergewöhnliches. Sieht man auf jeder Party:



Was mir mehr zu denken gibt, sind diese Warnungen:



Diese CSJ2K Library, mit der hab ich viel Zeit verdödelt. Bin ja dabei, alten Ramsch aus dem Sim zu entfernen. Eine der Libraries, die mich stört, ist die System.Drawing.Common Library. Diese wurde für Linux bis zur Version .NET 6 noch unterstützt. Ab Version .Net 7 gab's dann Fehlermeldungen, dass sie nicht mehr unterstützt ist. Natürlich kann ich die noch lange verwenden, auch in .NET 8+ muss einfach sicher sein, dass ich die alte Version immer im Paket behalte und wenn ihr in euer bin-verzeichnis des OpenSims schaut, dann seht ihr, dass es da zwei Dateien gibt. System.Drawing.Common.dll.linux und System.Drawing.Common.dll.win und je nach System muss dann die richtige eingebunden werden. Also ein Abstellgeleise. Will ich nicht.

Microsoft gibt dazu einige Empfehlungen ab. ImageSharp und SkiaSharp Ich habe mich schlussendlich für SkiaSharp entschieden, ist zwar komplexer im Library Handling aber schlussendlich voll offen unter einer MIT-Lizenz, wogegen die ImageSharp Library von SixLabors lizenziert wird. Ich hatte null Probleme eine freie Lizenz von ihnen zu kriegen, weil die kostenpflichtigen Features von mir nicht genutzt werden. Also als Plan B noch offen halten.

Die umstellung verlief dann relativ harzig. Insbesondere beim Generieren der Maptiles haben wir uns einen Wolf ab-debugged. Bis wir dann die CSJ2K als Bösewicht eingekreist haben. Nachdem ich die aus der Konfiguration entfernt hatte wurden auch die Maptiles korrekt generiert. Die Frage ist nun offen. Was mach ich mit der CSJ2K. In einem Repository von OpenSim gibt es Sourcecode dazu. Auf Github gibt es dieses Repo: https://github.com/cureos/csj2k und diese lib findet man auch im NuGet Repository. Ich gehe aber davon aus, dass Ubit etwas selbst gebrautes verwendet, die arbeiten ja nicht mit NuGet. Ist aber auch fraglich ob ich die verwenden soll. Wir haben ja noch die OpenJpeg Library zusätzlich im Repo. Muss mir da noch einen Task machen.

Wenn alles mit der CSJ2K Library funktioniert, warum nicht wechseln ... wenn ich aber schaue der letzte Commit am 26. September 2018 die ist ja fast so alt wie unser Grid, dann ... na ja, weiterforschen. Ziel für letzte Woche ist erreicht, SkiaSharp eingebaut und angetestet. Nein, nein, auf der PartySim ist die noch nicht eingebaut, erst bei mir lokal im Test.

Nächste Woche: Rausschmiss des SmartThreadPool... der ist in der heutigen Zeit völlig überflüssig. DotNet hat eigene Thread Pools und die Leute vom OpenSim-Tranquility Projekt haben den auch schon entfernt.

[akira]

Huhu zusammen,

tl;dr In diesem Vibe geht es ums Aufräumen. Gedanken zu Plugins, Dependency Injection und Factories.

Diese Woche hab ich nicht viel am Simulator rumgevibed. War anderweitig engagiert. Deshalb erzähle ich nun etwas zu der Idee, warum ich am Sim oder genauer gesagt dem Region-Server rumwerkle. Was mich eigentlich schon längere Zeit stört, der Region-Server ist überladen! Eigentlich beginnt das schon beim Namen. Neben dem Region-Server, gibt es ja noch den Grid-Server, der "Robust" genannt wird. Ausser der Region Server wird im Standalone Modus betrieben, dann ist die Funktionalität im Region Server eingebaut, besser gesagt zusammengesteckt.

Dieses zusammenstecken ist im Prinzip eine spannende Sache, so können die Module im Region-Server für Standalone und im Robust Server wiederverwendet werden. Auch wird die Möglichkeit geboten, Plugins für den Simulator zu entwickeln. So weit, so gut. Ein Plugin System wird dann richtig lustig, wenn es dann irgendeinen Marketplace gäbe, in welchem Plugins geholt werden können, mit denen der Simulator mit Funktionalität erweitert werden könnte. Leider hat sich diesbezüglich ausser einigen Money Plugins nicht sehr viel entwickelt. Schön wäre es, wenn die Trennung zwischen dem Grundgerüst und den Plungins sauberer getrennt wären, sodass ich, falls ich gerne die Ubode Physik hätte, beispielsweise ein bereits geliefertes Physik Plugin austauschen könnte. Aktuell sind all diese Module oder Plugins mehr oder weniger wild im Code verteilt. Es existiert ein Folder addon-modules. Aber im OpenSim Code Folder existieren ebenfalls zwei Projekte OpenSim.Addon.Groups und OpenSim.Addon.OfflineIM. Und das ganze noch in mehreren Ausprägungen.

Für meinen Geschmack zu viel Durcheinander. Und wir Schweizer mögen Durcheinander nicht. Wir lieben es aufgeräumt. Wir räumen gerne alles auf:

https://www.youtube.com/watch?v=nhPcsvlNcVc

Also hab ich mir ein paar Gedanken gemacht, was ich eigentlich gerne möchte.

• Brauche ich Robust? Nö ich habe den Php-Gridserver
• Brauche ich die Standalone Möglichkeit? Nö ich betreibe Sims nur im Hypergrid Modus.
• Brauche ich 10 Physik-Engines? Nö, Ubode und Bullet reichen eigentlich. Bullet brauch ich nur wegen der 3D Meshes die ich importiert hab, weil bei Ubode müsste ich nochmals importierten.
• Scripting Engines. Hat sich inzwischen auf eine reduziert. Glücklicherweise.
• Weitere Modules die ohne Sinn und Zweck rumliegen entfernen.
• Mono.Addins als Plugin System loswerden wird nicht mehr weiterentwickelt. Brauch ich wirklich Plugins?

Auch wenn die Konzeption der Mono.Addins ziemlich cool ist, die Tatsache, dass es nicht mehr weiterentwickelt wird und auch das Plugin Konzept nicht so prickelnd umgesetzt ist, sagte ich mir: Raus damit!

Um mit Modulen umzugehen, existieren mehrere Muster:

• Plugins
• Dependency Injection
• Factories

Die drei Muster im Vergleich

Plugin-System (Mono.Addins, System.Composition)

• Findet automatisch Implementierungen in Assemblies
• "Zeig mir alle Klassen, die ICommand implementieren"
• Für unbekannte, dynamische Erweiterungen

Dependency Injection (DI Container)

• Verwaltet Objektlebensdauer und injiziert Abhängigkeiten
• "Gib mir die registrierte Implementierung von ILogger"
• Für lose Kopplung innerhalb bekannter Komponenten

Factory

• Kapselt Objekterstellung mit Logik
• "Erstell mir ein Objekt basierend auf diesen Runtime-Parametern"
• Für komplexe oder parameterabhängige Instanziierung

Aktuell hab ich mich für eine Factory-Lösung entschieden. Aber könnte mir vorstellen, dass wenn ich das Testing überarbeite, ich vermehrt auf Dependency Injection umsteigen werde. Schon seit einiger Zeit erledigt:

• Mono.Addins rausfakturiert und durch Factories ersetzt
• Module die nur für den Standalone Betrieb notwendig sind entfernt
• Uralte Module die nicht mehr notwendig sind entfernt

Hab den Sim schon mal angetestet, aber es traten noch einige Seiteneffekte auf also wieder zurück ins Labor. Und genau deshalb überleg ich mir auch den Smart Thread Pool zu entfernen, um noch mehr Standardkomponenten zu verwenden, mit dem finalen Ziel keine .dll mehr im Github Repository und alles mit NuGet managen. Bin mal gespannt, wozu ich nächste Woche komme.

Ob das ganze jemals die Qualität hat um im Grid eingesetzt zu werden, weiss ich noch nicht. Die Vibes sind Sachen an welchen ich im Moment herumexperimentiere, immer mit einem konkreten Ziel welches ich habe.

[akira]

Huhu zusammen,

So, ich habe die Changes vom OpenSim in meinen Sim gemerged. War einiges an Arbeit, aber schlussendlich habe ich es auch geschafft. Was spannend ist, im OpenSim haben sie WebRtc beigefügt. Das WebRtc ist der Ersatz für Vivox oder Freeswitch Voice. Spannende Geschichte.

Das WebRtc besteht aus drei Teilen, ein Modul für den Region-Server, eines für den Robust-Server und ein Drittes (Siehe Hierarchie-Abbildung unten). So weit, so gut. Was macht man nun, wenn man keinen Robust hat? Umschreiben nach PHP (unser Grid läuft ja auf dem PHP Grid Server)?

Nein PHP tue ich mir nicht an! Aber das WebRtc ist ja mehr oder weniger autonom, hat mit dem andern Gedöns des Grid eigentlich nichts zu tun. Das Teil auf dem Robust ist eigentlich nur eine Schnittstelle zum janus-gateway. Okay da braucht es noch einiges mehr. Die Kommunikation sieht wie folgt aus:

Code: Alles auswählen

Viewer (WebRTC)
     │  HTTP Caps (LLSD/XML)
     ▼
WebRtcVoiceRegionModule          ← Region-Server
  (ISharedRegionModule)
  Caps: ProvisionVoiceAccountRequest
        VoiceSignalingRequest
        ChatSessionRequest
     │  JSON-RPC über HTTP
     ▼
WebRtcVoiceServerConnector       ← Robust-Server
  (IServiceConnector)
  Endpunkte: provision_voice_account_request
             voice_signaling_request
     │  ServerUtils.LoadPlugin
     ▼
WebRtcVoiceServiceModule         ← Robust-Server (Service-Modul)
  (ISharedRegionModule + IWebRtcVoiceService)
  Verteilt auf spatial / non-spatial Voice-Service
     │  ServerUtils.LoadPlugin
     ▼
WebRtcJanusService               ← Janus-Implementierung
  (IWebRtcVoiceService)
  Kommuniziert mit Janus WebRTC Gateway
     │  WebSocket / HTTP
     ▼
Janus WebRTC Gateway

Okay, mal wieder die tyische OpenSim Struktur. Ein Region Modul, welches mit dem Grid Server kommuniziert. Ein Connector Modul, welches die die RPC Anfragen vom Region Server entgegen nimmt, dann ein Service Modul das sonstige Logik enthält und als drittes der WebRtcJanusService welcher mit dem Janus-WebRtc-Gateway quasselt. Der WebRtc-Gateway ist eine externe Software die auch noch bereitgestellt werden muss, gibt es aber glücklicherweise als Docker Container in den verschiedensten Ausprägungen. Also muss ich nur noch etwas mit dem Robust Gedöns anstellen.

Also eine Architektur Entscheidung treffen. Ich hab ja noch einiges vor mit dem Grid-Server. Und das was ich vor habe ist am besten unterstützt in der Sprache "Go". Diese Sprache wurde von Google entwickelt https://de.wikipedia.org/wiki/Go_(Programmiersprache). Die Sprache wurde zwar von Google entwickelt, ist aber OpenSource, den Source Code findet man hier: https://github.com/golang/go. Go ist eigentlich die Sprache für die Cloud. Viele Cloud Services sind in Go geschrieben. Also perfekt für einen Grid Server.

Ich habe dann Claude mal gebeten mir den csharp code nach Go zu übersetzen, was er auch ohne Meckern gemacht hat. Und siehe, das ganze kann man sogar schon fehlerfrei compilieren. Ob es etwas Sinnvolles tut hab ich noch nicht getestet. Aber der Ansatz ist schon mal spannend. Und schon hatte ich ein neues Repository.

Hmm... ein weiteres Repository auf einem amerikanischen Server. Irgendwie möchte ich das nicht mehr. Habe mich auf die Suche gemacht und "Codeberg" gefunden. Das schöne ist, Codeberg ist in Deutschland und es ist ein Community-Projekt mit offener Software entwickelt und bietet all das, was ich brauche. Was fehlt sind die Vulnerability Scanner und ein Renovate-System, welches automatisch Pull Requests generiert, wenn eine abhängige NuGet die Version wechselt. Aber das ist Deluxe und im Enterprise Umfeld durchaus sinnvoll und ich gehe davon aus, dass ich so was auch mit irgendwelchen externen Services erreiche. Also rasch die Url bei den Repos geändert und voilà Aki ist auf Codeberg: https://codeberg.org/AkiraSonoda

Nächste Schritte: Dieses WebRtc zum Laufen zu kriegen.

Liebe Grüsse
Akira