yk.camelcase.work

Aktuelle Arbeiten

Aktuelle Produkte, von Anfang bis Ende gebaut. Jeder Eintrag nennt die technische Entscheidung, die ihn geprägt hat - nicht die Liste der Features.

Jedes der folgenden Projekte begann mit einem echten Problem. Ab da ist die Rolle immer dieselbe: Produktkonzept, Systemarchitektur, Implementierung, Infrastruktur, Deployment und Continuous Delivery - jedes Produkt entwickelt sich lange über sein erstes Release hinaus weiter.

Mixtrace - Iterative Mix-Diagnose und -Verifikation

Mixtrace misst einen gerenderten Musikmix, erklärt, was nicht stimmt - in Begriffen, mit denen ein Mix-Engineer in der DAW direkt arbeiten kann - und prüft beim nächsten Upload, ob die Korrektur tatsächlich gewirkt hat. Ich habe es um eine Schleife herum gebaut - rendern, messen, diagnostizieren, verifizieren -, in der jeder Befund einen Timecode, eine Mittenfrequenz und eine maschinenlesbare Erfolgsbedingung trägt. Jede Bewertung ist deterministisch und regelbasiert: Derselbe Mix erhält immer dieselbe Diagnose.

Problem

Ein Mix durchläuft Dutzende Renderings, und spätestens beim sechsten urteilen die Ohren des Engineers nicht mehr zuverlässig - im direkten Vergleich gewinnt fast immer die lautere Version. Messgeräte liefern Zahlen, aber nicht, was falsch ist, wo im Track oder was in der DAW zu ändern ist. Eine Woche später weiß niemand mehr, ob v7 tatsächlich behoben hat, was in v5 schieflief.

Signal analysisPython, NumPy, SciPyRule enginedeclarative versioned definitionsFix verificationper-diagnosis contractsCross-version alignmentdynamic time warpingMeasurement storagePostgreSQL, JSONB

Architektur

  • Messung und Bewertung getrennt. Ich normalisiere Rohwerte zu lokalisierten, zielunabhängigen Beobachtungen und lasse dann Regeln das Problem benennen. Weil die Beobachtungen gespeichert bleiben, leitet ein Wechsel von Genre oder Zielformat jede Diagnose aus dem Speicher neu ab - nur ein Engine-Upgrade erzwingt eine erneute Messung des Audios.
  • Jeder Befund trägt einen Vertrag. Jede Diagnose legt fest, welche Metrik sich bewegen muss, in welche Richtung und wie viel des gemeldeten Überschusses verschwinden muss, damit sie als behoben gilt - dazu Schutzbedingungen gegen Nebenwirkungen. Die nächste Version wird automatisch daran gemessen.
  • Regeln sind Daten, kein Code. Diagnosedefinitionen sind versionierte deklarative Dateien, die beim Start geladen werden, sodass sich Schwellenwerte und Abhilfen ohne Release ändern lassen. Ein Linter lehnt jede Regel ab, deren Abhilfe vage ist oder deren Verifikationsmetrik im Messkatalog fehlt.
  • Versionen werden unter gleichen Bedingungen verglichen. Nach Gehör gewinnt fast immer die lautere Version, daher wird jeder Vergleich zuerst lautheitsangeglichen. Anschließend werden die Versionen automatisch ausgerichtet - per Versatz, abschnittsweise oder per Dynamic Time Warping, wenn ein Takt hinzukam -, sodass ein Befund bei 1:42 in v5 an derselben musikalischen Stelle in v7 geprüft wird.
  • Echte Abweichungen werden unterdrückt. Unterschiede unterhalb der Hörschwelle und alles innerhalb der gemessenen Genre-Varianz werden als neutrale Beobachtungen gemeldet, nicht als Mängel. Schlagen viele Regeln gleichzeitig an, gebe ich einen einzigen Hinweis auf ein abweichendes Profil aus - ein Tool, das Geschmack zum Mangel erklärt, wird schnell aufgegeben.

Editron

Ein API-first-Dienst zur Texttransformation. Der eigene Web-Editor ist ein First-Party-Client derselben öffentlichen API und darf sie nicht umgehen - genau das hält die Integrationsschnittstelle ehrlich; die Verarbeitungs-Engine ist hinter einem internen Vertrag austauschbar, Mandantenfähigkeit, API-Keys, Kontingente und Nutzungsabrechnung sind von Anfang an mitgedacht, dazu kommt ein veröffentlichtes TypeScript-SDK.

Lernklang

Eine zugangsgeschützte Hörplattform zum Sprachenlernen mit einem Analyse-Dashboard für Schulen. Ein Image, drei Rollen: Geplante Aufgaben laufen in einem eigenen Container, sodass ein Neustart oder Skalieren der Web-App nie einen Job überspringt oder doppelt ausführt - und die Konfiguration wird beim Start validiert: Bei einer ungültigen Variable startet der Prozess gar nicht erst, statt in der Produktion still zu scheitern.

Herald

Themengesteuertes Sammeln, Verarbeiten und Ausliefern von Nachrichten. Die Deduplizierung greift bei der Auslieferung, pro Kanal über einen Content-Hash mit der URL als Fallback innerhalb eines gleitenden Zeitfensters, sodass syndizierte und live aktualisierte Artikel nie zweimal verschickt werden; jeder Artikel ergibt drei unabhängig erzeugte Formate, jedes mit der exakten Pipeline-Version versehen, die es erstellt hat - für Reproduzierbarkeit und Kostenabrechnung.

Kleinere Produkte und gezielte Experimente gehören zur selben Praxis: Mit ihnen lässt sich eine Idee, ein Interaktionsmuster oder ein neuer Workflow schnell validieren, bevor man sich auf ein größeres System festlegt.