Ku-DS Leistungsorientierte Software Lösungen,
Prozessautomatisierung und Dokumentation,
Digitale Problemlösungen (Beratung und Umsetzung),
Homepagedesign und Hosting

Warum ich Jai für meinen Stack gewählt habe?Alles begann mit einer Einladung, die ich vor über einem Jahr per Email beko...
17/04/2026

Warum ich Jai für meinen Stack gewählt habe?

Alles begann mit einer Einladung, die ich vor über einem Jahr per Email bekommen habe.

Ich wurde in die Closed Beta für Jai aufgenommen.

Mein erster Gedanke war, dass ich ein würdiges Projekt brauchte um die Sprache zu testen.
Ich entschied mich für den Port meines HTTPS-Server von C++.

Der Einstieg überraschte mich extrem.
Denn es war ein Kinderspiel.

Nicht weil die Sprache simpel ist.
Sondern weil alles -- Syntax, Compiler-Fehlermeldungen, Beispiele -- mit spitzen Kommentaren versehen ist.
Diese erklären nicht nur wie man sie einsetzt, sondern auch _warum_ bestimmte Entscheidungen getroffen wurden.
Keine Magie. Keine versteckten Annahmen.
Nur direkte, ehrliche Designentscheidungen, direkt im Code zu lesen und nachzuvollziehen.

Seit diesem Zeitpunkt war ich gefangen.

Nach über einem Jahr Anwendung und der Implementierung des kompletten Stacks, kann ich nun mit Sicherheit sagen, dass es die wohl bestdesignte Sprache ist die ich je benutzt habe.
Möglicherweise die beste, die existiert.

Und das Beste?
Ich hab noch nicht mal annähernd die volle Power ausgeschöpft.

Ich schreibe nach wie vor in C, C++, Python und Javascript.
Wenn ich jedoch wählen kann, würde ich mich immer für Jai entscheiden.

„KI schreibt jetzt unseren Code. Was bleibt da noch für uns Softwareentwickler übrig?"Diese Frage lese ich gerade überal...
15/04/2026

„KI schreibt jetzt unseren Code. Was bleibt da noch für uns Softwareentwickler übrig?"

Diese Frage lese ich gerade überall.

Die ehrliche Antwort:
Code _tippen_ war noch nie unser Job.
_Problemlösen_ war es.

Claude, Copilot und Co. generieren Syntax schneller als jeder Mensch.
Sie kennt jede API-Doku auswendig.
Wer jedoch glaubt, das sei Software Engineering, hat das Wesentliche nie verstanden.

Was wirklich bleibt und wichtiger wird:

System Design:
Eine KI schreibt dir auf Knopfdruck einen Algorithmus.
Ein System entwerfen, das tatsächlich zum Problem passt, ohne unnötige Komplexität?
Das erfordert Urteilsvermögen, das Modelle nicht haben.

Code lesen und debuggen:
Wir schreiben weniger von Grund auf neu.
Wir reviewen, bewerten und reparieren riesige Mengen an generiertem Code.
Wer fremden Code schnell durchschaut, wird wertvoller, nicht überflüssiger.

Domänenwissen:
Die KI kennt Python-Syntax.
Du kennst das Geschäftsproblem deines Kunden.
Je tiefer dieses Verständnis, desto weniger ersetzbar bist du.

Das Problem scharf definieren:
Ein Tool ist nur so gut wie die Frage, die du ihm stellst.
Wer ein Problem nicht klar benennen kann, bekommt Müll zurück, egal wie gut das Modell ist.

Der Mindset-Shift ist simpel:
Du bist nicht der Tippkünstler.
Du bist derjenige, der weiß was gebaut werden soll und warum.

Was hab ich vergessen?

I built a custom HTML → Jai transpiler from scratch.It takes a full HTML landing page, parses it into an element tree (A...
13/04/2026

I built a custom HTML → Jai transpiler from scratch.

It takes a full HTML landing page, parses it into an element tree (AST) and generates native Jai source code -- in ~2ms, without any optimizations at all.

Why?

Because I wanted to turn my quickly “vibecoded” landing page for nobbs.at into something:
- type-safe
- composable
- fully integrated into my backend

Instead of treating HTML as static files, I now generate it as code.

Pipeline:
- HTML parsing
- AST (element tree) construction
- Code generation → Jai HTML builder

Result:
A fast, deterministic transformation from markup → executable logic.

This opens the door to:
- variables, for/while loops, functions
- compile-time guarantees
- reusable UI structures
- tighter backend/frontend integration

Sometimes the best way to remove complexity… is to own the entire pipeline.

PS: nobbs.at is built in public and earlybirds can sign up for the mailing-list.
Rest is in progress and will update over time.

.at

Die Datenbank-Spalte, die zu viel wusste.  Nun steht das Stripe-Datenbank-Schema für NOBBS.Aber fast hätte ich mir dabei...
11/04/2026

Die Datenbank-Spalte, die zu viel wusste.

Nun steht das Stripe-Datenbank-Schema für NOBBS.

Aber fast hätte ich mir dabei die Architektur zerschossen.

Mein erster Plan:
Ich packe votes_granted direkt in die stripe_purchases-Tabelle.

Machte Sinn, denn jeder Kauf gibt Votes, also warum nicht?

Ganz einfach:
Weil dann plötzlich meine Payment-Schicht über das Gamification-System bescheid weiß.

Falls ich also das Voting-System komplett umbaue oder sogar abschaffe, müsste ich am Stripe-Schema herumschrauben.

Zwei unabhängige Domänen wären plötzlich miteinander verklebt.
Der klassische Geruch von too much knowledge in the wrong place.

Die Lösung?
Ein simples metadata TEXT Feld das als unschuldiger JSON-Blob dient.

Jetzt wissen die Tabellen nur noch das, was sie wirklich wissen müssen.
Die Bedeutung dieses Felds bestimmt der Application Layer.

Schöner Nebeneffekt:
Diese sind nun 100 % generisch und können als fertige Library in jedes zukünftige Projekt mitgenommen werden. ♻️

Und das Beste:
Das war keine geniale Vorab-Architektur-Entscheidung.
Sie entstand, weil ich mich beim Coden gefragt habe:

„Was muss diese Tabelle eigentlich wirklich wissen?“

Viel weniger, als man denkt.


NOBBS – die High-Performance-Plattform für spezialisierte Tools: schnell, pragmatisch und ohne Konzern-Bullsh*t. Gebaut von Machern für Macher.

Nächste Schritte: Webhook-Handler, Shadow Accounts und der erste zahlende Kunde.


PS: Für die _VERY_ earlybirds: nobbs.at

PPS: Mailinglist funktioniert, Rest ist in progress.

Wie beschleunigt man Code, auf den man keinen Einfluss hat?Im letzten Post ging es darum, langsame Stellen durch Timing ...
10/04/2026

Wie beschleunigt man Code, auf den man keinen Einfluss hat?

Im letzten Post ging es darum, langsame Stellen durch Timing aufzuspüren.

Aber was, wenn der Code seine Zeit aus gutem Grund braucht, weil er eine Blackbox ist, eine externe Bibliothek, ein API-Call?

Dann hilft oft nur eines:
Ergebnisse zwischenspeichern → also cachen.

Die Idee ist simpel:
Man generiert den Output (z.B. die Response als String) einmal, hasht den Input → also Path + Parameter + relevante Header und speichert das Ergebnis in einer Hashmap/Dict.

Beim nächsten Request schaut man zuerst nach:
Gibt's den Hash schon?
Wenn ja → Response direkt zurückgeben, fertig.
Wenn nein → neu generieren, ins Dict schreiben, zurückgeben.

Der zweite Request ist damit quasi gratis.

Worauf man achten sollte:
Der Cache muss invalidiert werden, sobald sich die zugrundeliegenden Daten ändern, sonst liefert man veraltete Responses aus.
Und man sollte sich überlegen, ob der Cache im Arbeitsspeicher lebt (schnell, aber flüchtig) oder persistiert wird.
Caching ist kein Allheilmittel, aber gezielt eingesetzt, einer der effektivsten Performance-Wins überhaupt und einsetzbar auf Dinge auf die du sonst keinen Einfluss hast.

Wer hat's schon mal bereut, weil die Cache-Invalidierung vergessen wurde? 😄

Code langsam, was tun?Eine der ersten Schritte, die man tun sollte, wenn man merkt, dass der Code langsam läuft, ist ihn...
08/04/2026

Code langsam, was tun?

Eine der ersten Schritte, die man tun sollte, wenn man merkt, dass der Code langsam läuft, ist ihn zu Timen.

Also man schreibt eine Funktion oder ähnliches, die man in Funktionen platziert die man messen möchte.

Bei einem Webserver wäre das z.B. die gesamte Dauer des Requests -- Request kommt rein, Response geht raus.
Danach noch Subfunktionen, bei dem man das Gefühl hat die könnten die Ursache sein.

Damit hat man dann schon einen sehr guten Ausgangspunkt und erkennt wo die Hotspots sind, also jene Funktionen, die am Längsten brauchen.

Nun kann man sich diese ansehen und eventuell mit einer LLM herausfinden, was diese Funktion so verlangsamt und versuchen zu beschleunigen z.B. eine neue Funktion zu schreiben oder sich über die Datenstrukturen gedanken machen.

Ein weiterer Punkt wäre Caching, also den Input (Path, Parameter und Header) zu hashen und den Output (z.B. String der Response) in der Hashmap/Dict zu speichern und beim nächsten Request direkt widerzugeben.

Mehr dazu in einem Folgepost.

Noch jemand im Team "ich time so früh als möglich"?

Der Login-Flow für NOBBS benutzt keine Passwörter.Nein, nicht weil's trendy ist…Sondern weil Passwörter bedeuten: Hashin...
06/04/2026

Der Login-Flow für NOBBS benutzt keine Passwörter.

Nein, nicht weil's trendy ist…

Sondern weil Passwörter bedeuten: Hashing, Salting, Reset-Flows, Breach-Responses.

Magic Links umgehen das alles.

Der Flow:
→ Email eingeben → Link kommt → klicken → fertig
→ Token wird vor dem Speichern SHA-256 gehasht
→ Einmaligkeit wird direkt im Query erzwungen
→ 30 Minuten Ablaufzeit
→ Cookie mit HttpOnly + Secure + SameSite=Strict

Bonus:
Erster Klick registriert den User automatisch.

Ein Flow für Registrierung UND Login.

Das Ganze steckt in einem einzigen Endpoint. Keine Auth-Library.

Im Code-Bild seht ihr übrigens auch die ursprüngliche Version mit separatem SELECT + UPDATE und warum das eine Race Condition erzeugt hätte.
Das atomare UPDATE...RETURNING ersetzt beides in einer einzigen Operation.

One Endpoint is all you need.

Das mit Abstand beste Anwendungsgebiet für AI, wenn es um Coden geht, ist…… Javascript zu produzieren. Denn sind wir mal...
03/04/2026

Das mit Abstand beste Anwendungsgebiet für AI, wenn es um Coden geht, ist…

… Javascript zu produzieren.
Denn sind wir mal ehrlich: Wer programmiert schon freiwillig in JS? 😅

Aber mal im Ernst:
Es hilft teilweise wirklich extrem.
Man sitzt grübelnd auf der Couch, überlegt wie man Problem X am besten löst, und quatscht einfach kurz mit einem LLM.

Das generiert den Code, und wenn man wieder am Schreibtisch sitzt, wird er nur noch kopiert und implementiert.
Das ist bei mir absolut kein Einzelfall.
Besonders bei Code, der nicht zu 100 % perfekt sein muss, wie z. B. ein vom Server retourniertes Javascript, das ohnehin nur 1x abläuft.

Solche Tasks schafft das LLM meist im One-Shot.
Das bedeutet: Ich kann den Code wirklich 1:1 kopieren, er funktioniert, und ich muss nicht debuggen.

Und ganz nebenbei minimiert es die Zeit, in der ich selbst JS schreiben muss.
Definitiv auch kein Fehler! 😁

P.S.: In diesem speziellen Fall war das Ergebnis allerdings eine Halluzination von Claude… 🙈

Ein bombensicheres Deploy-System: ohne DevOps, ohne GitHub Actions, ohne Docker und ohne dabei verrückt zu werden:Das Bu...
02/04/2026

Ein bombensicheres Deploy-System: ohne DevOps, ohne GitHub Actions, ohne Docker und ohne dabei verrückt zu werden:

Das Build-Programm wurde um 100-Zeilen erweitert → done.

Keine „Text file busy“-Fehler, keine versehentlich gelöschte Datenbanken.
Die "naive" Version wurde übersprungen und gleich mit der "Bullet-Proof" - Version begonnen.

Atomar, state-safe und lächerlich einfach.

# Das ganze System in 4 Schritten:

1. Code und State strikt trennen
- releases/commit_abc/ → immutable Code/Files + Binaries
- shared/ → liegt außerhalb von Releases (SQLite + Logs)
- current → Symlink, zeigt auf die aktive Version
- previous → Symlink, zeigt auf die vorige Version

2. Clone → Sync → Atomic Swap
"build.jai" macht das automatisch bei "--deploy":
- rsync die Binaries + Assets
- Ein einziger SSH-Befehl: Shared-Ordner verlinken + "current"-Symlink umstellen + "systemctl restart nobbs"

3. Praktisch Zero Downtime. Zero Datenrisiko. Sofortiges Rollback.
- Symlink zurück auf den vorherigen Release-Ordner zeigen lassen. Fertig.

4. Lokale Entwicklung bleibt 1:1 gleich
- Gleiche Ordnerstruktur, gleiche relative Pfade.
- Kein Docker Compose, keine extra Configs.

Kein Kubernetes. Kein Terraform. Kein YAML-Horror. Nur Code.

Ein einiziges build.jai, dass sowohl das Programm kompiliert als auch das Deployment übernimmt und das at compile time.

Ich baue *Nobbs* in Public:
- Eine Highperformance Webplattform auf der Module/Apps gehosted werden - alles in Jai, self-hosted auf einem günstigen VPS.

Next: Deployment steht und wird ab Tag 1 getestet indem die Landingpage live geht.

Einer der besten Wege, besser im Programmieren zu werden?Man liest Code, den andere geschrieben haben.Das Schwierige dar...
01/04/2026

Einer der besten Wege, besser im Programmieren zu werden?

Man liest Code, den andere geschrieben haben.
Das Schwierige daran ist jedoch herauszufinden, _wessen_ Code?

Für mich war es unter anderem Casey Muratori mit seiner legendären Twitch-Reihe „Handmade Hero“. Darin hat er live eine komplette Game Engine in C++ geschrieben, hauptsächlich in reinem C, nur mit einem sehr kleinen Subset von C++ und dabei jeden einzelnen Gedankenschritt laut erklärt.

Damals war ich noch relativ neu im Programmiergeschäft und kam aus der Python-Welt.

Es war ein _brutaler_ Umstieg.

Ich brauchte mehrere Anläufe, vor allem wegen der Absurdität von Compiler, Commandline, Toolchain und der berüchtigten Linker-Hell.
Dass ich mir das alles komplett selbst beigebracht habe, machte es nicht nicht gerade leichter.

Aber sobald die Anfangshürde überwunden war und ich mit bedachtem Einsatz externer Bibliotheken arbeitete, wurde eines kristallklar:

Die Dinge sind eigentlich verdammt einfach.

Man erkennt plötzlich, dass die vermeintliche Komplexität in vielen modernen Projekten oft nur durch unnötige Abstraktionen und Over-Engineering entsteht.
Statt blind auf Frameworks zu vertrauen, lernt man, von Grund auf zu denken.
Der Code wird robuster, performanter und vor allem verständlicher.

Handmade Hero hat mir nicht nur C beigebracht, sondern ein komplettes Mindset: Einfachheit zuerst.

Volle Transparenz. Echtes Verständnis statt Copy-Paste.
Thank you Casey!

Jemand ähnliche Erfahrungen gemacht?

NOBBS ist eine highperformance Web-Plattform, gebaut in Jai und in aktiver Entwicklung.Grunddaten wie folgt: # Das Ziel:...
30/03/2026

NOBBS ist eine highperformance Web-Plattform, gebaut in Jai und in aktiver Entwicklung.

Grunddaten wie folgt:

# Das Ziel:
zuerst eine spezialisierte Version shippen (meine eigenen Apps/Module), dann generalisieren, wenn's läuft.

# Aktueller Stand:
Läuft. HTTP-Server steht, Login mit Token-Flow ist fertig, Stripe-Integration kommt als Nächstes.

# Architektur:
• Nginx als Reverse Proxy/Load Balancer (interim — Security-Shield + TLS-Termination)
• Custom HTTP-Server in Jai (HTTP/1.1, HTTP/2 in Arbeit — ersetzt Nginx sobald fertig und gehärtet)
• Apps/Module kommunizieren via Shared Memory Ring-Buffers + Semaphoren — HTTP-Proxy-Semantik über IPC. Request landet im Ring-Buffer, Semaphor signalisiert die App, App baut die vollständige Response in einer zweiten Shared-Memory-Region, Server leitet weiter. App-Crash = isoliert, Server läuft weiter.
• Tailwind CLI zur Build-Zeit → statisches CSS, zur Laufzeit im RAM gecacht. HTMX liefert dynamischen Content - Caching geplant.*

# Dependencies:
Nginx*, OpenSSL, curl, SQLite, Stripe, Tailwind CLI (Build-Zeit), HTMX (statischer Asset) - *temporär

# Out of the Box:
Login/Account-System (serverseitige Sessions + Cookies), SMTP via curl, Stripe

# Mindset:
Kein Bloat, minimale Dependencies, Pragmatismus statt Over-Engineering, Security-First.
Routing, Modul-Generalisierung, Config - wird später entschieden. On the fly oder im Post-Launch-Cleanup.

# Go-to-market:
Closed Source, Built in Public (Code-Snippets). Open Source in Betracht, sobald gehärtet und erfolgreich. Offen für Sponsoren (bevorzugt) / Investoren (vielleicht).

Landingpage und mehr dazu nächste Woche.

Adresse

Kärntner Straße 43
Leoben
8700

Benachrichtigungen

Lassen Sie sich von uns eine E-Mail senden und seien Sie der erste der Neuigkeiten und Aktionen von Ku-DS erfährt. Ihre E-Mail-Adresse wird nicht für andere Zwecke verwendet und Sie können sich jederzeit abmelden.

Service Kontaktieren

Nachricht an Ku-DS senden:

Teilen

Kategorie