.svg)
By
·
12 minute read
dynaWeek #8
Hackathon-Woche 2026
⎯
Grundidee
Jedes Jahr machen wir eine Woche lang interne Projekte zum Testen eigener Ideen und erforschen neue Technologien. Dabei steht der Spaß im Vordergrund und das wirtschaftliche muss dem Spieltrieb weichen. Fünf Tage lang machen wir einfach nur das was wir wollen. Hier ist eine kurze Zusammenstellung aus dem Jahr 2026.
VOCA
Eine Plattform für Real-Time Collaboration mit Voice-Chat, Multi-User-Screen-Sharing und Textnachrichten
Grundidee
Effektive Remote-Zusammenarbeit erfordert latenzfreie Kommunikation und ein Gefühl von „virtueller Anwesenheit“. Ein zentrales Element ist dabei die Möglichkeit, Bildschirme unkompliziert mit mehreren Kollegen gleichzeitig zu teilen. Zwar bietet Discord technisch genau diese Funktionen, ist jedoch nicht auf den Unternehmenseinsatz (Datenschutz, Integrationsfähigkeit) ausgelegt. Meine Motivation war daher, eine eigene Lösung mit Fokus auf professionelle Zusammenarbeit zu schaffen.
Konzept & Umsetzung
Ich habe mich bewusst für einen modernen und experimentellen Stack entschieden: Die Desktop-Anwendung basiert auf WailsJS (als Alternative zu Electron) in Kombination mit SolidJS, während Pocketbase als Backend dient. Mein technisches Hauptziel für die Dynaweek war ambitioniert: Die Implementierung eines Screencast-Video-Streams unter Arch Linux und Wayland. Das ist technisch anspruchsvoll, da Wayland eine strikte Isolation von Fenstern erzwingt. Ziel war es, diesen lokalen Stream abzugreifen und perspektivisch über WebRTC (LiveKit) an mehrere Nutzer zu verteilen.
Erkenntnisse & Ausblick
Die Hürden waren höher als vermutet: WailsJS bietet aktuell keine native Unterstützung für Video-Streaming, und die Sicherheitsprotokolle von Wayland blockieren herkömmliche Screen-Capturing-Methoden. Statt mich auf die Netzwerkübertragung zu konzentrieren, musste ich den Großteil der Zeit in "Low-Level"-Lösungen investieren (unterstützt durch KI-Debugging mit Gemini 3 Pro), um überhaupt an das Bildsignal zu kommen.
Das Ergebnis: Es ist mir gelungen, einen funktionierenden Proof-of-Concept zu bauen, der den Bildschirm unter diesen erschwerten Bedingungen erfolgreich abgreift und in der App darstellt – ein technischer Durchbruch für diesen Stack. Die Übertragung via LiveKit ist der logische nächste Schritt für Voca.
Technologien
Tätigkeiten
NODARIUM NODESYSTEM
Mit der Webapp Nodarium und dem NodeSystem Plantarium können User auf spielerische und visuelle Weise 3D Pflanzen generieren.
Grundidee
Mit drei Leute wurde in einer Woche an unterschiedlichen Ecken von dem Nodarium Nodesystem Projekt weitergearbeitet. Die erste Herausforderung bestand darin, ein über längere Zeit allein entwickeltes Projekt so aufzubereiten, dass es von mehreren Personen gemeinsam und mit Freude weiterentwickelt werden kann. Dafür wurde zum Beispiel der modernen Code-Formatter “dprint” eingesetzt. Außerdem wurde der Code an vielen Stellen aufgeräumt und auf einen modernen Stand gebracht.
Niklas und Max haben sich derweil mit den einzelnen Nodes auseinandergesetzt, eine optimierte Runtime zur Ausführung der einzelnen Nodes konzipiert und Niklas hat die erste prototypische Node in Zig geschrieben. Parallel dazu hat das Team die Benutzerinteraktion deutlich verbessert: Das neue Drop-Node-on-Connection Feature ermöglicht es, Nodes direkt auf einer Verbindung zu platzieren. Das Kontextmenü bleibt nun immer im sichtbaren Bereich, und die Kamera-Position wurde so optimiert, dass alle Nodes beim Start sichtbar sind.
Ein weiteres Highlight dieser Woche war die Umsetzung eines vollständigen Project Manager Systems, das Benutzern ermöglicht, ihre Projekte effizient zu organisieren und zu verwalten. Zusätzlich wurde die Docker-Infrastruktur finalisiert – mit eigenen Dockerfiles für App und Nodes sowie optimierten Deployment-Konfigurationen. Dies ermöglichte auch Feature-Branch Deployments über Coolify.
Die UI wurde umfassend modernisiert: Integer- und Float-Input-Komponenten wurden überarbeitet, bekamen Min/Max-Schalter und Tastatur-Integration (Esc/Enter), und ein neues Header-Element wurde hinzugefügt. Die Workspace-Struktur wurde von Links auf echte pnpm-Workspaces migriert, und die Development-Pipeline wurde optimiert.
Erkenntnisse & Ausblick
Weitere Verbesserungen im Detail: Keyboard-Shortcuts sind jetzt mit "?" erreichbar, das Graph-Kontextmenü bewegt sich nicht mehr bei Right-Click-Drag, und alle verfügbaren Knoten sind im Add-Menü sichtbar. Build-Flags wurden für WASM optimiert, Node Build-Scripts aufgeräumt und verschiedene Minor-Fixes implementiert – alles in allem über 45 Commits in fünf intensiven Tagen!
Technologien
Tätigkeiten
REINFORM
Tool zur einfachen PDF Generierung auf Basis von Typst Templates
Grundidee
Irgendwie ist es viel zu schwer eine einfache PDF zu erstellen. Typst/LaTeX sind zu kompliziert für den Otto Normalnutzer und andere Dokumentenprogramme (z.B. Word) sind mir zu schwergewichtig.
Konzept & Umsetzung
Man kann Typst-Templates hochladen. Templates bestehen aus einer Funktion namens “template”, wo man alle Parameter durch Annotations beschreibt und Metadaten anhängt. Aus den Templates werden automatisch Formulare generiert, um die Parameter an das Template zu übergeben. Daraus wird dann das endgültige PDF generiert. Ein großer Schwerpunkt ist hierbei die clientseitige Rendering-Logik. Sämtliche PDF-Generierung erfolgt im Browser. Der Server ist allein dazu da, die Templates zu verwalten. Alle Templates sind zudem öffentlich und man kann ohne Login sofort loslegen.
Erkenntnisse & Ausblick
Typst kann man von Haus aus schon zu WebAssembly kompilieren, was die Einbindung in eine Website erheblich vereinfacht hat. Schwierigkeiten gab es überwiegend in der Kombination aus Angular und WebAssembly. Die PDF-Preview hat dafür gesorgt, dass das PDF selbst “verbraucht” wurde und in einem späteren Schritt nicht mehr heruntergeladen werden konnte. Als Lösung habe ich die URL-Objekte gefunden, die nicht einfach “verbraucht” werden. Insgesamt musste ich die High-Level API von Angular mit der Low-Level API von WebAssembly kombinieren, was mich zu etwas ungewöhnlichen Workarounds gezwungen hat.
Aktuell kann im Formular nur normaler Text behandelt werden. Diese Datentypen auszuführen ist der nächste Schritt, damit das Tool sinnvoll und brauchbar wird. Dazu gehören beispielsweise ein Datum, Zahlen oder auch komplexere Strukturen wie Listen oder Objekte. Außerdem ist das Template Erstellen noch sehr undokumentiert und erlaubt auch falsche Eingaben. Hier muss die Dokumentation und Hilfestellung für den Nutzer erheblich verbessert werden.
Technologien
Tätigkeiten
Web AppSoftwareentwicklung
2DRacer
Das Projekt simuliert selbstfahrende Autos, die mit Hilfe genetischer Algorithmen und neuronaler Netze eigenständig lernen, eine Rennstrecke effizient und fehlerfrei zu befahren.
Grundidee
Die Grundidee des Projekts entstand aus dem Wunsch, die „ideale Linie“ auf einer Rennstrecke nicht manuell vorzugeben, sondern sie von den Fahrzeugen selbst erlernen zu lassen.
Eine erste Version des Projekts entstand bereits 2024, in der die Autos zwar über die Strecke fahren konnten, jedoch noch ohne eigenständiges Lernverhalten. In der aktuellen Weiterentwicklung wurde dieses ursprüngliche Ziel nun vollständig umgesetzt.
Durch den Einsatz selbstlernender Algorithmen treffen die Fahrzeuge eigenständig Entscheidungen, lernen aus Fehlern und verbessern ihre Fahrweise über mehrere Generationen hinweg. Die Motivation dafür liegt sowohl im Interesse an motorsportlichen Fragestellungen – insbesondere der Berechnung optimaler Rennlinien – als auch an der Begeisterung für Videospiele und simulationsbasierte Systeme.
Konzept & Umsetzung
Im Zentrum des Projekts steht eine Rennsimulation, in der autonome Fahrzeuge eine frei definierbare Rennstrecke selbstständig erlernen und befahren. Jedes Fahrzeug trifft seine Fahrentscheidungen – Beschleunigen, Bremsen sowie Links- und Rechtslenken – auf Basis von Sensordaten wie Abständen zur Strecke, Geschwindigkeit und Fahrtrichtung. Eine ideale Linie wird dabei nicht vorgegeben, sondern soll durch wiederholtes Fahren eigenständig gefunden werden.
Zur Umsetzung wurde ein genetischer Algorithmus eingesetzt. Eine Population von Fahrzeugen fährt die Strecke, wird anhand ihrer Leistung bewertet und dient anschließend als Grundlage für die nächste Generation. Durch gezielte Mutation und Kombination von Entscheidungsparametern entstehen über mehrere Generationen hinweg neue Fahrstrategien.
Die Strecke ist in einzelne Sektoren unterteilt, wodurch auch unvollständige Fahrten sinnvoll ausgewertet werden können. Zusätzlich werden Fahrdaten wie Sektor- und Rundenzeiten erfasst und visualisiert, um den Lernfortschritt der Fahrzeuge nachvollziehbar darzustellen
Erkenntnisse & Ausblick
Deutlich schwieriger als zunächst erwartet war die Definition einer geeigneten Fitness-Funktion. Kleine Änderungen an der Bewertung führten teilweise zu starkem oder unerwünschtem Verhalten, etwa zu vorsichtigem Fahren, frühem Abbremsen oder dem völligen Vermeiden von Kurven. Die richtige Balance zwischen Geschwindigkeit, Fortschritt und Stabilität zu finden, erforderte viel Experimentieren und Feinjustierung.
Eine bewusst getroffene Vereinfachung war die Verwendung nur eines Fahrzeugtyps. Alle Fahrzeuge hatten identische physikalische Eigenschaften wie Beschleunigung, Bremskraft und Höchstgeschwindigkeit. Dadurch konnte sich der Lernprozess vollständig auf das Fahrverhalten konzentrieren. Gleichzeitig stellt dies eine nicht umgesetzte Idee dar: Unterschiedliche Fahrzeugtypen mit eigenen Stärken und Schwächen hätten interessante zusätzliche Dynamiken ermöglicht.
Für die Zukunft wären mehrere Erweiterungen denkbar. Dazu zählen verschiedene Fahrzeugklassen, komplexere Sensorik, adaptivere Fitness-Funktionen oder auch das Lernen über mehrere Strecken hinweg. Ebenso wäre es möglich, das System stärker in Richtung realistischer Motorsport-Simulation weiterzuentwickeln oder die KI gezielt auf bestimmte Fahrstile zu optimieren.
Technologien
Tätigkeiten
Residual Surface
Browserbasierte, interaktive Web-App, die Live-Kamera-Input in dynamische visuelle Erfahrungen transformiert und dabei verschiedene generative Sketches nahtlos wechseln kann.
Grundidee
Die Idee entstand aus dem Wunsch, eine interaktive Web-App zu schaffen, die Live-Kamera-Input aufnimmt, transformiert und in verschiedene visuelle Darstellungen umwandelt – ohne dabei Identitäten zu erkennen oder zu klassifizieren.
Das System soll als autonome Oberfläche fungieren, die sich kontinuierlich entwickelt, auch ohne direkte Interaktion. Die Motivation war es, ein modulares System zu entwickeln, das verschiedene visuelle Ansätze ermöglicht und für den Einsatz im Browser optimiert ist.
Konzept & Umsetzung
Residual Surface wurde als vollständig browserbasierte Anwendung entwickelt, die mehrere unabhängige generative Sketches in einem einheitlichen System vereint. Jeder Sketch nutzt die Live-Kamera als Rohmaterial und transformiert diese Eingabe auf unterschiedliche Weise: Von physikbasierten Fragmenten mit Matter.js über organische Partikel-Flows mit Perlin-Noise bis hin zu abstrakten Malereien und ASCII-Kamera-Visualisierungen.
Die größte technische Herausforderung lag in der Entwicklung einer sauberen Plugin-Architektur, die es ermöglicht, Sketches nahtlos zu wechseln, ohne Memory Leaks zu verursachen. Insbesondere die korrekte Bereinigung von Matter.js Physics-Engines beim Sketch-Wechsel erforderte sorgfältiges Lifecycle-Management. Die Lösung war ein Registry-System mit klaren Setup-, Draw- und Cleanup-Phasen für jeden Sketch, kombiniert mit einem zentralen State-Management für geteilte Ressourcen wie die Kamera.
Eine weitere Herausforderung war die Performance-Optimierung für den kontinuierlichen Betrieb im Browser. Durch die Begrenzung der Fragment-Anzahl, Delta-Time-Capping für Physics-Simulationen und optimierte Canvas-Rendering-Strategien wurde eine stabile 60 FPS Performance erreicht. Die Anwendung wurde zudem für Graceful Degradation entwickelt – sie funktioniert auch ohne Kamera-Zugriff und erholt sich automatisch von Fehlern, ohne die Anwendung zu blockieren.
Das System unterstützt sowohl Bild- als auch Video-Capture (PNG/WebM) und bietet eine dynamische Toolbar, die sich automatisch an die Parameter des aktiven Sketches anpasst. Die Architektur ermöglicht es, neue Sketches einfach hinzuzufügen, indem man das Sketch-Interface implementiert und den Sketch im Registry registriert.
Erkenntnisse & Ausblick
Die Wahl einer Plugin-Architektur mit klarem Interface hat sich als sehr wertvoll erwiesen, da sie die Entwicklung neuer Sketches erheblich vereinfacht und die Wartbarkeit des Codes verbessert.
Die korrekte Bereinigung von Matter.js Physics-Engines beim Sketch-Wechsel war komplexer als erwartet und erforderte mehrere Iterationen, um alle Memory Leaks zu eliminieren.
Geplante Features / Nicht umgesetzte Ideen:
-
Präsenz-Erkennung via TensorFlow.js zur Modulation der Visualisierung basierend auf Bewegung
-
Netzwerk-Synchronisation für mehrere Instanzen, die Fragmente teilen
-
Zeitbasierte Sketches, die ihr Verhalten je nach Tageszeit ändern
Technologien
Tätigkeiten
N8N Workflow für Foto Leistenscheider
Ein N8N Workflow, welcher automatisiert einkommende Support-E-Mails sortiert, labelt und je nach Kategorie entweder eine Antwort verfasst oder die E-Mail an die entsprechende Abteilung weiter leitet. Zum Sortieren der E-Mails, Labeln und Verfassen der Antworten wurde Gemini 3 Modell verwendet.
Grundidee
Unsere Kunde hat aktuell Probleme mit Abarbeitung der Support Tickets und dynabase würde gern Kompetenzen im bereich N8N und generell Automatisierung aufbauen.
Konzept & Umsetzung
Umgesetzt wurde ein n8n-Workflow mit Gemini Agents zur automatisierten Analyse, Kategorisierung und Weiterleitung eingehender Support-E-Mails.
Erkenntnisse & Ausblick
Mit N8N kann man schnell einen Prototypen zusammenbauen, jedoch wird es schnell unübersichtlich, wenn man größere Workflows baut. Als Softwareentwickler habe ich natürlich ein Bias und tendiere und fühle mich besser, wenn ich Code schreibe, jedoch für jemanden, der kein Softwareentwickler ist, ist N8N ein gutes Werkzeug um seine Ideen umzusetzen.
Technologien
Tätigkeiten
Gophper
Gophper ist ein Language-Server für die Programmiersprache PHP. Er unterstützt Entwickler dabei zu programmieren, indem er relevante Vorschläge für Editoren bestimmt und diese über das Language-Server-Protokoll (LSP) übermittelt.
Grundidee
PHP ist eine weit verbreitete Sprache, für die es bisher keine freie und performante LSP-Implementation gibt. Bestehende Implementation sind entweder proprietär oder selbst in PHP geschrieben, was durch die fehlende Nebenläufigkeit deutlich langsamer ist als in anderen Sprachen. Unser Ziel war eine PHP-LSP-Implementation, die performanter ist als die bestehenden Lösungen und dabei offen ist.
Konzept & Umsetzung
Aufgrund der geringen Einstiegshürde und der recht einfachen Verwendbarkeit der Nebenläufigkeit, haben wir uns für Go als Grundlage entschieden. Für das Parsen haben wir zuerst auf eine PHP Lösung gesetzt, da diese in der Lage wäre, uns einen AST zu erzeugen, der viele Informationen bereits beinhaltet, die wir andernfalls selbst ermitteln müssten. Aufgrund einiger Limitierungen mussten wir dieses Vorhaben jedoch verwerfen. Letztlich haben wir uns für Tree-sitter entschieden. Tree-sitter ist etabliert, extrem performant und von der Community gepflegt.
Erkenntnisse & Ausblick
Ein Learning war, dass PHP an sich gar nicht langsam ist. Ein Testprojekt mit knapp 20.000 Dateien ließ sich mit PHP alleine innerhalb von 24 Sekunden parsen.
Aus Go heraus den PHP Prozess anzustoßen und jede Datei dabei einzeln parsen zu lassen war trotz Nebenläufigkeit mit knapp 60 Sekunden sogar langsamer, da wir hier den Overhead hatten, dass PHP immer wieder gestartet werden musste.
Außerdem haben wir einiges über das (fehlende) Scoping in PHP gelernt, im Bezug auf Variablen, Funktionen und Klassen.
Ebenso über die Namespaces in PHP. Darüber, dass es syntaktisch zwei verschiedene Arten von Namespaces gibt und auch darüber, dass man innerhalb einer Datei mehrere Namespaces definieren kann.
Technologien
Tätigkeiten
Kana
Kana ist ein Kartenspiel im Stile eines Memorys
Grundidee
Kana entstand aus einem ehemaligen Projekt einer vorhergehenden Dynaweek.
Konzept & Umsetzung
Es wurden über 200 Kartenartworks generiert um ein hochkomplexes Memoryspiel mit erweitertem Regelwerk zu bauen.
Erkenntnisse & Ausblick
Es wurde ein funktionierendes Memoryspiel mit komplexem Cardviewer gebaut. Es gibt eine Vielzahl von Features die noch umzusetzen sind
Technologien
Tätigkeiten
Obsidian CalDAV Task Sync Extension
Eine Obsidian-Extension, die Aufgaben anhand eines definierten Keywords mit einem CalDAV-Kalender synchronisiert und deren Status bidirektional abgleicht.
Grundidee
Obsidian bietet nativ die Möglichkeit, Aufgaben (Tasks) zu erfassen. Mithilfe der Tasks Extension lassen sich diese zusätzlich um Metadaten wie Fälligkeitsdatum (Due Date) oder Priorität erweitern.
Da Obsidian jedoch keine Push-Benachrichtigungen unterstützt und Aufgaben bzw. Erinnerungen nicht zwangsläufig ausschließlich in Obsidian gepflegt werden, entsteht schnell ein Medienbruch. Um dennoch eine konsistente und zentrale Übersicht zu gewährleisten, bietet sich eine Synchronisation der Tasks mit einer externen CalDAV-Taskliste an.
Konzept & Umsetzung
Im Rahmen des Projekts wurde ein funktionsfähiger Prototyp einer Obsidian-Extension entwickelt, der Tasks automatisch anhand eines definierten Keywords einem CalDAV-Kalender hinzufügt. Zusätzlich können bestehende Kalendereinträge sowie der Status bereits synchronisierter Tasks manuell vom CalDAV-Server abgerufen und mit Obsidian abgeglichen werden.
Die Extension unterstützt vollständig die Syntax der Obsidian Tasks Extension, sodass Fälligkeitsdaten direkt in Obsidian definiert und nahtlos synchronisiert werden können.
Zentrale technische Herausforderungen lagen insbesondere im sicheren Handling von Zugangsdaten. Diese konnten nicht abschließend gelöst werden, da CalDAV-Server in der Praxis häufig auf Basic Authentication setzen, was aus sicherheitstechnischer Sicht problematisch ist, da diese im Klartext in einer JSON auf einem Server gespeichert werden könnten.
Ein weiteres Hindernis stellen CORS-Restriktionen bei der Verwendung bestehender NPM-Packages dar. Diese wurden umgangen, indem unter anderem ein eigener CalDAV-Client implementiert wurde.
Erkenntnisse & Ausblick
Die konsequente Orientierung an der bestehenden Tasks-Syntax von Obsidian erwies sich als sehr gute Designentscheidung und erleichterte sowohl die Nutzung als auch die Erweiterbarkeit der Extension.
Unerwartet komplex gestaltete sich hingegen das sichere Credential-Management im Kontext von CalDAV.
Geplante Erweiterungen umfassen unter anderem: vollautomatische bidirektionale Synchronisation (2-Way Sync), Unterstützung von Kalendereinträgen und Unterstützung von Uhrzeiten bei Fälligkeitsdaten
Technologien
Tätigkeiten
S&box Colonizer
S&box Colonizer ist eine PC-Portierung des mobilen Weltraum-Echtzeitstrategiespiels (RTS) "Colonizer", die auf der Source 2 Engine basiert und um Online-PvP-Support erweitert wurde.
Grundidee
Das ursprüngliche Mobile Game leidet unter den typischen Limitierungen der Plattform: unpräzise Touch-Steuerung, schwache KI-Gegner und fehlende Multiplayer-Funktionalität. Gleichzeitig bot die Entwicklung der neuen Plattform S&box (basierend auf Valves Source 2 Engine) durch Facepunch die Gelegenheit, sich frühzeitig in diese Technologie einzuarbeiten. Das Ziel war es, zum geplanten Release von S&box in Q1 bereits ein performantes, fertiges Spiel vorweisen zu können, das die Schwächen des Originals durch Maussteuerung und echtes Networking behebt.
Konzept & Umsetzung
Entwickelt wurde ein Peer-to-Peer RTS-Spiel mit einem "Multiplayer-First"-Ansatz. Die größte technische Herausforderung lag in der Implementierung des eigenen Netzwercodes, um über hundert Raumeinheiten gleichzeitig und flüssig simulieren zu können. Um Einheiten (Game Objects) ohne Performance-Einbrüche (Lag-Spikes) spawnen zu können, wurde ein Game Object Pool implementiert. Dieser dient dazu, eine Menge an inaktiven Spielobjekten im Speicher vorzuhalten und bei Bedarf wiederzuverwenden, anstatt sie rechenintensiv neu zu erstellen und wieder zu zerstören (Garbage Collection). Der Netzwerk-Ansatz ist deterministisch: Der Host sendet einmalig Position und Rotation eines neuen Schiffes, woraufhin alle Clients die Bewegung über die nächsten Frames eigenständig und identisch (deterministisch) berechnen.
Erkenntnisse & Ausblick
Die Komplexität einer eigenen Netzwerk-Implementierung wurde unterschätzt. Es zeigte sich, dass die deterministische Synchronisation zwischen Clients deutlich aufwendiger ist als gedacht, da schon kleinste Abweichungen zu Desynchronisation führen. Ein positives Learning war die Effektivität des Object Poolings in der Source 2 Engine, welches das Spielgefühl massiv verbesserte. Für die Zukunft ist geplant, eine "Prediction"-Logik zu integrieren, damit der Host Asynchronitäten erkennen und korrigieren kann, bevor sie für die Spieler sichtbar werden.
Technologien
Tätigkeiten
Flip-Heaven
Flip 7, ein Kartenspiel, wurde als Web-Anwendung mit Online-Multiplayer nachgebaut.
Grundidee
Mit wenig Zeit ein einfaches Spiel nachzubauen, um in der Lage zu sein, besser verteilte System und Zusammenarbeit zwischen Client/Server zu verstehen.
Konzept & Umsetzung
Ich hatte während der Dynaweek versucht, in kurzer Zeit eine Web-Anwendung zu bauen, die es ermöglicht, mit anderen Leuten Flip 7 zu spielen. Sowohl das Regelwerk als auch die Darstellung waren hierbei eine technische Herausforderung. Wie vereint man Server State / Client State, während man alles ansprechend animieren muss? Wie sollte ein gutes Protokoll für so eine Anwendung aussehen?
Für den ersten Wurf habe ich dafür einen einfachen Automaten gebaut, der das Regelwerk von Flip 7 abbildet. Im zweiten habe ich einen Wrapper drumherum gebaut, damit man diesen Automaten durch eine WebSocket Anbindung bedienen und Änderungen im State kommunizieren kann. Im letzten Schritt wurde dann eine Angular Application aufgebaut, die diesen State visualisieren kann und es erlaubt, mit dem Automaten zu interagieren.
Erkenntnisse & Ausblick
Wo mir Standard-Entwicklungsaufgaben einfach fallen, fand ich, dass Feinschliff und gute UX mir deutlich schwieriger fielen. Deshalb würde es sich für mich als Entwickler lohnen, vor dem Code schreiben eine Skizze des Endergebnis festzuhalten.
Technologien
Tätigkeiten
dereview
Eine dezentrale Bewertungsplattform für Orte (wie Restaurants und Cafés), die auf dem AT-Protokoll basiert.
Grundidee
Die Motivation hinter Dereview ist es, Bewertungen von physischen Orten unabhängig von zentralen Plattformen (wie Google Maps oder Yelp) zu machen. Durch die Nutzung des AT-Protokolls behalten Nutzer die Hoheit über ihre eigenen Daten (Reviews), während die Plattform diese lediglich aggregiert und dezentral verfügbar macht.
Konzept & Umsetzung
Im Rahmen des Projekts wurde ein komplettes Ökosystem für dezentrale Reviews entwickelt. Dazu gehört:
-
Lexikon-Design: Definition des app.dereview.review Lexikons, um strukturierte Daten wie Sterne-Rating, Titel, Beschreibung und Location-IDs (basierend auf OSM Node IDs) im ATProto-Netzwerk zu speichern.
-
Ingester-Service: Ein spezialisierter Node.js-Dienst, der via Jetstream das gesamte AT-Netzwerk in Echtzeit nach Review-Events scannt und diese in eine PostgreSQL-Datenbank indiziert. Dabei werden auch Nutzerprofile (Handles, Avatare) automatisch vervollständigt.
-
Web-App (Next.js): Eine moderne Oberfläche, die Kartenintegration (Leaflet) nutzt, um Orte anzuzeigen und es Nutzern ermöglicht, eigene Reviews sicher via OAuth zu veröffentlichen.
Erkenntnisse & Ausblick
Eine sehr gute Entscheidung war die Architektur-Trennung zwischen Ingester und Web-App (Microservices), was die Lastverteilung optimiert. Für die Zukunft sind Bild-Uploads direkt in die ATProto-Blobs sowie ein "Upvote"-System für besonders hilfreiche Reviews geplant.
Technologien
Tätigkeiten
RESUME
Die DynaWeek #8 hat 2026 erneut gezeigt, wofür dynabase steht: Neugier, technischer Tiefgang und die Freiheit, Ideen ohne wirtschaftlichen Druck zu erforschen. Eine Woche lang entstanden Prototypen, Experimente und Systeme, die sich mit ganz unterschiedlichen Fragestellungen beschäftigten – von Real-Time Collaboration und Workflow-Automatisierung über generative Web-Erlebnisse bis hin zu selbstlernenden Rennsimulationen und neuen Ansätzen für PDF-Generierung.
Ob komplexe Low-Level-Experimente unter Wayland, der Ausbau einer modularen Node-Architektur, KI-gestützte Automatisierung oder browserbasierte Echtzeit-Visualisierung: Die Projekte zeigen, wie breit das technologische Spektrum bei dynabase ist – und wie viel Energie entsteht, wenn Teams Raum zum Ausprobieren bekommen.
Die DynaWeek bleibt damit das, was sie sein soll: ein Spielfeld für neue Ideen, ein Testfeld für Technologien und ein fester Bestandteil unserer Kultur, in der Lernen, Experimentieren und gemeinsames Weiterentwickeln im Mittelpunkt stehen.