Wissen bleibt exportierbar
WikiKit exportiert einen Space deterministisch als lesbaren Markdown-Baum oder als OKF-Bundle. Claims, Belege, Beziehungen, Quellen und Entscheidungen bleiben portabel.
Ausgewählte Blog-Beiträge von Mike Bild als Hörfassung – Softwarearchitektur, Engineering und Methodik.
Per RSS abonnierenIn Apple Podcasts öffnenIn Overcast öffnenIn Pocket Casts öffnen
WikiKit exportiert einen Space deterministisch als lesbaren Markdown-Baum oder als OKF-Bundle. Claims, Belege, Beziehungen, Quellen und Entscheidungen bleiben portabel.
Unabhängige Produkte lassen sich gemeinsam erweitern, wenn Verträge, lokale Prüfungen, echte Release-Artefakte, Produktionsprüfungen und eine zeitversetzte Beobachtung klar getrennte Beweise liefern.
WikiKit behandelt Entscheidungen als eigene, reviewte Wissensobjekte mit Kontext, Entscheidung, Begründung und Alternativen. Claims sagen, was gilt; Entscheidungen erklären warum.
Persönliche Leser, Gruppen, genaue und präfixbasierte Pfadregeln schützen Dokumentation samt Suche, Navigation, Medien und maschinenlesbaren Ausgaben als Teil des Releases.
WikiKit trennt Suche, vollständiges Lesen, Herkunft und optionale Q&A. Treffer bleiben rohe Belege; ohne Treffer entsteht keine erfundene Antwort.
Site-Presets, feste Seitenlayouts, Design-Tokens und begrenztes CSS erlauben unterschiedliche Websites, ohne hochgeladenen Template-Code in den Release-Pfad zu holen.
Finanzreports können denselben technischen Ablauf verwenden, ohne Daten, Rechte, Speicher oder Wissen mit allgemeinen Produktreports zu vermischen. Die Trennung folgt der Fachlichkeit.
Ein WatchKit-Befund ist ein revisionsgebundener Beleg, kein dauerhaftes Wissen. Wird er als unveränderte Quelle an WikiKit übergeben, kann daraus über ein ChangeProposal und nach menschlicher Freigabe eine wiederverwendbare Aussage entstehen.
Unveränderliche Revisionen, manifestgebundene Vorschauen und eine exakte Promotion halten schnelle Agentenarbeit vom öffentlichen Stand getrennt – aktiviert wird der geprüfte Kandidat, nicht eine Neuberechnung.
ContentKit ordnet semantische Inhalte für den tatsächlichen Container, die Lesedichte und das Ausgabemedium neu an.
WikiKit hält geprüftes Wissen, SubKit führt den versionierten Ablauf aus und ContentKit bindet Vorschau und Veröffentlichung an unveränderliche Revisionen und menschliche Entscheidungen.
MCP, HTTP mit OpenAPI, Webhooks und A2A verbinden Systeme auf unterschiedlichen Ebenen. Entscheidend ist, welche Verantwortung an der jeweiligen Grenze liegt.
MCP, REST, Webhooks und A2A lösen unterschiedliche Integrationsprobleme. Eine Entscheidungshilfe zeigt, wann direkter Agentenzugriff genügt und wann SubKit den Ablauf übernehmen sollte.
Das Mission Cockpit verbindet SubKit, ContentKit und WikiKit über ihre gewöhnlichen Verträge und trennt maschinenlesbare Fakten, geschützte Reports und kuratiertes Wissen.
Monate nach dem Gespräch, mit dem alles begann, ist es Zeit für eine ehrliche Bilanz: welche Erwartungen des Auftakts eingetreten sind, welche nicht, was offen bleibt – und warum die spannendste Frage nicht mehr lautet, was die Modelle können, sondern was Organisationen daraus machen.
Claude Code und Codex bereiten belegte Markdown-Revisionen und vollständige Vorschauen vor. Die Preview-Promotion bindet den geprüften Stand an ein exaktes Manifest und eine menschliche Entscheidung.
Sechs eigenständige Produkte statt einer gekoppelten Suite: ContentKit veröffentlicht, WikiKit kuratiert Wissen, SubKit führt reproduzierbare Abläufe aus, WatchKit belegt Verhalten, WorkKit delegiert Ziele und CodeKit kontrolliert Coding-Agenten.
ContentKit trennt Bedeutung, Erzählung, visuelle Komposition, Layout und Rendering, damit aus Markdown verständliche und überprüfbare Darstellungen entstehen.
Contentkit rendert helle und dunkle Diagramme reproduzierbar auf dem Server, veröffentlicht statische SVGs und behält Markdown-Tabellen als zugängliche Quelldaten.
WikiKit prüft den sichtbaren Wissensbestand ohne LLM auf Widersprüche, fehlende Belege, beschädigte Beziehungen, veraltete Claims und verwaiste Konzepte.
Contentkit erzeugt aus begrenzten Report-Direktiven und gewöhnlichen Zahlentabellen Kennzahlen, Entscheidungen, zugängliche Charts und typisierte Datenmuster.
Contentkit veröffentlicht prüfbare Markdown-Reports als zugängliche Websites und ordnet Zustand, Entscheidung und Evidenz durch eine explizite Narrative.
WikiKit bietet Suche, Lesen, Quellen, Historie, Ingest und Review als scope-gesteuerte MCP-Werkzeuge an. Agenten sehen nur Fähigkeiten, für die ihr Token berechtigt ist.
Markdown-Zwillinge, llms.txt, llms-full.txt und die geschützte Read API geben Agenten denselben freigegebenen Inhaltsstand in passenden Detailstufen.
Ein WikiKit-Space ist eine fachliche und sicherheitstechnische Grenze: Er hält Konzepte, Quellen, Vorschläge, Schlüssel, Sprache und Charter zusammen. Cockpit, HTTP und MCP müssen dieselbe Isolation durchsetzen – ohne Deployment-Umgebungen mit Wissensdomänen zu verwechseln.
Eine Wissensbasis, die belegte Konflikte sichtbar hält, verhindert, dass ein neuer Wert einen bestehenden Widerspruch verdeckt. Funktionale Prädikate, disputed Claims und die Beziehung contradicts machen die offene Frage prüfbar – die fachliche Auflösung bleibt einer geprüften Revision vorbehalten.
Headless beschreibt in ContentKit die Trennung von Inhaltsmodell und Ausgabekanal, nicht den Verzicht auf eine Oberfläche. Die geschützte Read API liefert den Veröffentlichungsstand als JSON mit ETags und Suche, während das Cockpit Menschen über dasselbe Inhaltsmodell Zugriff auf dessen veröffentlichte Sicht gibt.
Agent Card, Message, Task und Artifact verständlich erklärt: wie A2A 1.0 eigenständige Agentensysteme verbindet, was das Protokoll von MCP unterscheidet und wie WorkKit und CodeKit begrenzte Aufträge heute konkret annehmen.
WikiKit hält jede Wissensänderung als dauerhaften ChangeProposal fest. Der Stale-Base-Schutz und die atomare Freigabe trennen Agentenvorschlag und menschliche Entscheidung – im Cockpit, über HTTP und über MCP.
Private Reports bleiben nachvollziehbar, wenn Quelldaten, Analyse, Manifest und redaktionelle Aussage getrennte Artefakte bleiben – und Zugriffsregeln gemeinsam mit dem Release für geschützte Seiten, Medien und maschinenlesbare Ausgaben wirksam werden.
Ein abgeschlossener Stundenreport beantwortet andere Fragen als laufende Betriebsbeobachtung – und wird einfacher, sobald Zeitfenster, Verspätung und Messlücken ausdrücklich modelliert sind.
Mit begrenzten Zusatzfeldern, expliziten Beziehungen und dokumentbezogenen Metadaten übergibt ein Agent neben dem Text auch nachvollziehbare Struktur an ContentKit.
Claims zerlegen Wiki-Seiten in einzelne Aussagen mit Subjekt, Prädikat, Objekt, Confidence, Status und wörtlichem Beleg. Dadurch werden Zustimmung und Widerspruch präzise.
Produktstatistiken bleiben verständlich, wenn jedes System seine Daten selbst verdichtet und über einen kleinen, zeitlich einheitlichen HTTP-Vertrag anbietet.
WikiKit bewahrt eingereichte Dokumente unverändert und dedupliziert sie per Hash. Verlässliches Wissen entsteht daraus erst durch überprüfbare Aussagen und Freigabe.
ContentKit ist nicht die führende Wissensbasis, sondern macht freigegebene Wissensstände als Dokumentation, Wiki oder Hilfeportal für Menschen und Maschinen sichtbar.
Eine Aussage wird zu nachvollziehbar geprüftem Wissen, wenn Originalquelle, wörtlicher Beleg, Änderungsvorschlag, Status und menschliche Freigabe zusammen erhalten bleiben.
KI macht den Weg vom Kundenproblem bis zur Wirkung durchgängiger.
ContentKit verbindet ein eingebettetes Web-Cockpit mit portablen Markdown-Quellen, unveränderlichen Revisionen, prüfbaren Vorschauen und atomaren Releases. Cockpit, REST und MCP sind Zugänge für Menschen, Dienste und Agenten zu derselben Veröffentlichungsdomäne.
Einen Agenten für die eigene Fachdomäne kann man nicht installieren – den Weg dorthin aber sehr wohl lernen. Welche Konzepte tragen, welche Methoden den Anfang klein halten und welche Prozesse verhindern, dass Regeln veralten.
Kontext für Modelle, nicht fürs Ranking: warum llms.txt und llms-full.txt Coding-Agenten helfen – und was ein MCP-Server daraus macht.
Ein Tool prüft den einzelnen Aufruf – verbindliche Regeln gelten aber für den ganzen Vorgang. Warum Durchsetzung, Freigaben und Nachweis in einen eigenen, an die Fachdomäne gebundenen Agenten gehören.
Das Modell ist gemietet, der Agent kann unter eigener Kontrolle stehen – entscheidend ist, ob die Fachdomäne als Prosa im Prompt liegt oder als geprüfte Schnittstelle im Agenten.
MCP macht Softwarefähigkeiten für Agenten adressierbar. Gute Oberflächen bleiben wichtig, aber Arbeit bekommt eine zweite Schnittstelle.
Session-Wissen verdampft, wenn niemand es kuratiert – warum Teams ihr KI-Arbeitswissen wie Code behandeln sollten und dabei nicht das Modell schlauer wird, sondern die Organisation lernt.
Mein Arbeitsmodell für Grounding unterscheidet Konventionen, Dokumente und Schnittstellenbeschreibungen. Was im knappen Kontext bleibt, priorisiere ich nach Aufgabe und Wiederbeschaffungskosten.
KI verkürzt Recherche, Entwurf und Implementierung. Bleiben Übergaben, Ticket-Hierarchien und Freigaben unverändert, verlagert sich der Engpass – Großunternehmen müssen deshalb Arbeitsfluss und Governance gemeinsam neu ordnen.
Warum Sprachmodelle plausible Dinge erfinden, weshalb mehr Training das Problem nicht zuverlässig beseitigt und was Grounding damit zu tun hat.
Ein halbes Jahr lang habe ich versucht, Teamregeln über CLAUDE.md, AGENTS.md und Skills durchzusetzen – die Chronik einer Ernüchterung und die Einsicht, dass Instruktionsdateien Empfehlungen an ein probabilistisches System sind, keine Regeln.
Ein Kollege übernimmt mein KI-Setup und bekommt andere Ergebnisse. Werkzeuge, Tests und Konventionen sind übertragbar; Aufgabenzuschnitt, Prüfblick und der einzelne Sessionverlauf sind es nur begrenzt.
Vier Beobachtungen und eine offene Hypothese nach intensiven Monaten mit KI – vom möglichen Kompetenzverlust bis zur Sorge vor gleichförmigeren Lösungen und meinen praktischen Gegenmaßnahmen.
Wie Tools, Kontextverwaltung und ausführbare Prüfungen aus einer Aufgabe einen reviewbaren Branch machen können – und warum die Abnahme trotzdem beim Menschen bleibt.
Bei den Alltagsaufgaben, die ich selbst mit KI bearbeite, ist die Modellwahl selten der erste Engpass. Aufgabenzuschnitt, Kontext und Prüfung wirken meist stärker.
Wie ein Gespräch in Berlin mich nach über dreißig Jahren Softwarehandwerk zum täglichen Arbeiten mit Claude, ChatGPT und Claude Code gebracht hat – und warum ich meiner Begeisterung trotzdem erst einmal misstraue.
Ein kompletter Durchgang durch React, wie ich es heute unterrichte – vom deklarativen Rendern über die Frage, wem ein Zustand gehört, bis zur Architektur einer wachsenden Anwendung. Die Details zu einzelnen Stationen kommen später als eigene Beiträge.
React 19 macht das Formular zur eigentlichen Schnittstelle: eine Funktion als form action, dazu drei Hooks für Ergebnis, Pending-Zustand und sofortiges UI-Feedback. Dieser Beitrag zeigt das Zusammenspiel – und wo optimistisches Rendern ohne sauberen Fehlerpfad kippt.
Server Components laufen außerhalb des Client-Bundles und liefern ihr Ergebnis statt ihres Codes an den Browser. Server Functions holen Schreibvorgänge auf den Server – umgesetzt wird beides durch ein passendes Framework oder einen Bundler.
Der Data Router von React Router macht die URL zum Koordinationspunkt – eine Route lädt ihre Daten per loader vor dem Rendern und schreibt über action, sodass Ladelogik aus dem Komponenten-Body verschwindet.
useTransition markiert Updates als nicht dringend und hält React während teurer oder suspendierender Renderings responsiv. Dazu useDeferredValue als Werkzeug für nachgelagerte Renderings.
Tests auf sichtbares Nutzerverhalten koppeln weniger an DOM-Struktur, Komponentengrenzen und internen State. Dadurch überstehen sie bestimmte Refactorings ohne Anpassung.
Statt in jeder Komponente einen Ladezustand zu verwalten, beschreibt man mit Suspense an einer einzigen Stelle im Baum, was während des Wartens erscheint – und der use-Hook lässt die Komponente darunter rendern, als wären die Daten längst da.
Serverdaten sind Zustand, aber nicht client-eigener Zustand. Warum diese Unterscheidung wichtig ist, wann useEffect zum schlechten Cache wird und was eine Server-State-Bibliothek übernimmt.
Injizierbare Zeit macht zeitabhängige Regeln schnell und deterministisch testbar. Daten, Isolation und externe Systeme bleiben davon unberührt.
Ein Durchgang durch GraphQL – vom typisierten Schema über Abfragen und Resolver bis zu Echtzeit, Betrieb und föderierter Architektur, eingeordnet am Stand von Oktober 2024.
Wie HTTP/2 viele Streams über eine Verbindung multiplext und warum Server-Sent Events oft die einfachere Antwort auf Live-Daten sind als WebSocket – mit einem lauffähigen SSE-Endpunkt in Node und den üblichen Fallstricken.
Warum ein diffbarer Markdown Report für Nachvollziehbarkeit, Review und Betrieb oft mehr leistet als ein Dashboard – und wie ich das architektonisch aufziehe.
Wenn ein Team ein Monolith-Schema nicht mehr allein tragen kann, teilt Federation den Graphen in Subgraphs auf, die ein Router zu einem Supergraph komponiert. Dieser Artikel zeigt an einem User- und Orders-Beispiel, wie @key und __resolveReference Entitäten über Subgraph-Grenzen hinweg zusammenhalten.
Ein Fuzzy-Match ist eine Behauptung mit Konfidenz, kein Fakt – nützlich wird er erst durch versionierte Schwellwerte, drei Entscheidungszonen und einen diffbaren Report der Grauzone.
Event Sourcing serverless umgesetzt: DynamoDB als append-only Event-Store, DynamoDB Streams als Change-Feed und Lambda als idempotenter Projektor in CQRS-Read-Models.
Marble-Diagramme machen den zeitlichen Ablauf asynchroner Streams sichtbar. Mit TestScheduler.run und virtueller Zeit testest du RxJS-Operatoren deterministisch: kein echtes Warten, keine Flakiness.
Warum ein Rechnungsimport kein CSV-Job ist, sondern eine Fachdomäne mit eigenen Begriffen, Invarianten und Zeitregeln – und wie explizite Typen und ein Ablehnungs-Report aus stillen Datenfehlern erklärbare Daten machen.
Wie sich eine Node.js-Testsuite sinnvoll auf verschiedene Testebenen verteilt und wie Mocha, node:assert, sinon und supertest dabei zusammenspielen.
Determinismus ist eine Architekturentscheidung: gleiche Eingaben, gleicher Report, reviewbar per Diff. Er lohnt sich dort, wo ein Artefakt wiederholt geprüft wird.
Logs, Traces und Metriken mit OpenTelemetry einheitlich instrumentieren, über Trace-IDs verbinden und per OTLP an geeignete Backends ausgeben.
Apollo Link lässt jede GraphQL-Operation durch eine Kette von Middleware laufen: authLink setzt Header, errorLink behandelt Fehler zentral, split routet Subscriptions. Dazu Fragments als wiederverwendbare Feldmengen und warum Interfaces possibleTypes brauchen.
Warum sich eine OCR-Pipeline für Belegdaten erst dann zuverlässig anfühlt, wenn man jeden erkannten Wert mit Hash-Cache, Confidence-Gate und Plausibilitätsregeln absichert statt ihm zu glauben.
Subject, BehaviorSubject, ReplaySubject und AsyncSubject unterscheiden sich darin, was späte Subscriber sehen und wie Abschluss oder Fehler ihr gespeichertes Verhalten beenden.
HTTP-Caching ist auch mit GraphQL möglich, aber für Client-Zustand oft weniger direkt. Apollo normalisiert deshalb Objekte und unterstützt optimistische Updates in der UI.
Ein einziger GraphQL-Endpunkt nimmt beliebig verschachtelte Queries an – das ist bequem und zugleich ein Missbrauchsrisiko. Ich zeige, wie ich mit Depth-Limit, Complexity-Budget, Pagination-Caps und Rate-Limiting eine mehrschichtige Verteidigung gegen teure Queries baue.
TypeScript in einem Node-Projekt aufsetzen: tsconfig-Essentials verstehen, async und Handler typisieren und die Tests laufen lassen, Schritt für Schritt aus der Projektpraxis.
Wie aus Props und State überprüfbare Verträge werden – und der Editor Fehler meldet, bevor der Nutzer sie sieht. Von interface/type über useState-Generics und Event-Typen bis zu useRef und Utility-Types.
Warum Resilienz kein Zufall ist: Timeout, Retry mit Backoff und Jitter, Circuit Breaker und Idempotenz als bewusst entworfene Muster gegen die Ausfallmodi verteilter Systeme.
Subscriptions brauchen keinen WebSocket. Server-Sent Events genügen für den einseitigen Server-zu-Client-Kanal, während Query und Mutation normales HTTP bleiben, und das Schema entscheidet, was überhaupt ein Domänen-Event ist.
Consumer-Driven Contracts prüfen Schnittstellen an der Grenze zwischen Services statt in einer teuren, flaky End-to-End-Suite. Das Ergebnis: ein schnelleres, deterministisches Deploy-Gate und Teams, die unabhängig releasen.
Fehlerbehandlung in Node.js ist keine try/catch-Kosmetik, sondern eine Entscheidung über Ebenen, Eskalation und geordnetes Beenden. Wer die vier Fehler-Ebenen kennt und Graceful Shutdown ernst nimmt, baut Dienste, die kontrolliert sterben statt korrupt weiterzulaufen.
Lead Time, Deploy-Frequenz, Change-Fail-Rate und Recovery-Zeit sind Diagnosewerte statt Vanity-Velocity. Sie zeigen, wo der Zyklus klemmt – und warum Tempo und Stabilität kein Gegensatz sein müssen.
Node.js läuft auf einem einzigen Event Loop – CPU-Arbeit blockiert alles. Dieser Beitrag zeigt, wann fork, cluster und worker_threads wirklich helfen und wann sie nur Overhead sind.
Was ein Cold Start bei AWS Lambda wirklich ist, welche Hebel du steuern kannst – von Bundle-Size über Init-Code und Memory bis Provisioned Concurrency – und wie du das Ganze sauber misst.
RxJS in Node.js: Wie fromEvent einen EventEmitter in ein Observable verwandelt, Operatoren serverseitige Ströme deklarativ transformieren und warum RxJS keine echte Backpressure hat.
Architektur ist kein Endzustand, den man einmal festzurrt. Kleine Änderungen und passende Fitness Functions machen ausgewählte Risiken früher sichtbar, garantieren aber weder Tempo noch Qualität.
Wie teile ich Logik zwischen Komponenten ohne Copy-Paste? Custom Hooks vermeiden dafür meist verschachtelte Wrapper; HOCs und Render Props behalten einzelne Kompositionsaufgaben.
Wie man request-bezogenen Kontext wie Request-ID, User und Trace durch tiefe asynchrone Aufrufketten trägt, ohne ihn durch jede Funktionssignatur zu fädeln – mit AsyncLocalStorage, dem darunterliegenden async_hooks und diagnostics_channel für entkoppeltes Tracing.
Der GraphQL-Context transportiert die Identität eines Requests. Ob diese Identität eine Operation ausführen darf, entscheidet eine zentrale Policy in der Fachlogik.
Vom console.log-Reflex zum eingebauten Inspector: node --inspect, das debug-Modul, nodemon sowie erste CPU- und Speicherprofile für die lokale Diagnose.
Kurze Feedbackschleifen bei verlässlicher Qualität sind mein Denkmodell für Developer Productivity. Wo tatsächlich gewartet wird, muss die eigene Durchlaufzeit zeigen.
Drei Kompositions-Werkzeuge in Svelte 3: Slots reichen Inhalt von außen hinein, die Context-API vermeidet Prop-Drilling, und Custom Elements machen eine Komponente framework-neutral wiederverwendbar.
Der Rendering-Zeitpunkt wird pro Route entschieden. Statische, dynamische und inkrementelle Modelle lassen sich nach Datenfrist, Kosten und Fehlerverhalten kombinieren.
Node.js-Streams transportieren nicht nur Bytes: Mit objectMode:true werden sie zu komponierbaren Datenpipelines aus parsen, filtern und aggregieren – inklusive der Brücke zu Async-Iteratoren.
Flakiness weist auf unkontrollierte Eingaben oder Abhängigkeiten hin. Wer Zeit, Daten und Isolation sichtbar macht, kann die Ursache eingrenzen und das Merge-Gate wieder belastbar machen.
Was ein Framework-Adapter wirklich leistet: der Vertrag über den Build-Output, die Übersetzung von Request und Response und die stillen Umgebungsannahmen an der Grenze zwischen SvelteKit und AWS.
RxJS glänzt in React nicht überall, sondern genau dort, wo asynchrone Ereignisse koordiniert werden müssen – entprellte Eingaben, abgebrochene Autocomplete-Requests, kontinuierliche Ströme. Der Beitrag zeigt die wenigen Stellen, an denen sich Observables wirklich lohnen, und wo useState völlig genügt.
Wie Svelte Bewegung deklarativ und ohne Extra-Bibliothek mitbringt: transition-Direktiven fürs Ein- und Ausblenden, svelte/motion für sanft interpolierte Werte und animate:flip fürs Umsortieren von Listen.
Warum JS-Strings für rohe Bytes nicht taugen und Buffer Nodes Werkzeug dafür ist: alloc gegen allocUnsafe, Encodings sauber lesen und schreiben, und die Speicherfalle hinter slice und subarray.
Svelte Stores sind ein minimales Modell für Zustand, der nicht in eine einzelne Komponente passt: writable, readable, derived – plus die $-Kurzschreibweise, die abonniert und beim Unmount aufräumt.
Warum ein schneller Producer einen langsamen Consumer nicht überrennen darf – und wie pipe, pipeline, der Rückgabewert von write() und das drain-Event die Flusskontrolle in Node.js regeln.
Fitness Functions machen ausgewählte Eigenschaften wie Kopplung, Abhängigkeiten und Latenz kontinuierlich prüfbar. Fachliche Qualität und Architekturabwägungen ersetzen sie nicht.
Svelte kompiliert Komponenten zur Build-Zeit in gezielten DOM-Code, statt zur Laufzeit einen Virtual DOM zu diffen. Ich zeige das mentale Modell, die reaktive Zuweisung mit $: und die klassische push-Falle, die mir in Projekten immer wieder begegnet.
EventEmitter ist der gemeinsame Nenner unter Streams, HTTP-Server und Prozessen: Ich zeige on/once/off/emit, das Sonderverhalten von 'error' und wie man Listener-Lecks vermeidet.
Warum offset/limit bei bewegten Listen Duplikate und Lücken produziert und wie cursor-basierte Paginierung mit dem Connections-Muster stabil bleibt – inklusive Schema, Resolver-Skizze und den Fallstricken aus der Projektpraxis.
Warum ich einen eigenen SvelteKit-Adapter für AWS gebaut habe und was die Übersetzung zwischen Framework-Build und Lambda, S3 und CloudFront über beide Seiten verrät.
Ephemere Umgebungen pro Pull Request verkürzen das Feedback und machen Reviews konkret: Man klickt die Änderung, statt sie sich aus dem Diff vorzustellen.
Jamstack beschreibt einen Architekturstil mit vorgerendertem Frontend und entkoppelten Diensten. Der Beitrag ordnet die ursprünglichen Bausteine JavaScript, APIs und Markup im Stand von 2021 ein.
Wie SES zum ereignisgetriebenen E-Mail-Baustein wird: ausgehende Bestätigungsmails aus einer Lambda-Funktion und eingehende Receipt Rules, die aus einer Mail einen Handler auslösen.
Wenn ein Zustand wirklich app-weit ist, stellt sich die Werkzeugfrage – Redux Toolkit, ein leichter Store wie Zustand oder Jotai, oder das reaktive Modell von MobX. Warum diese Wahl aber erst nach der Gegenprobe kommt und meistens kleiner ausfällt als gedacht.
DynamoDB belohnt ein anderes Denken als eine relationale Datenbank: nicht vom Datenmodell her, sondern von den Zugriffsmustern. Single-Table-Design fasst mehrere Entitätstypen über zusammengesetzte Keys in einer Tabelle zusammen.
Warum ein eigenes CDK-Construct für statische Websites mehr ist als gesparte Zeilen: eine Schnittstelle mit Meinung über S3, CloudFront, Zertifikate und DNS.
Erledigte Tickets sind Output, aber noch kein Beleg für Wirkung. Warum Velocity im Management-Reporting in die Irre führt und wie man Teams stattdessen an Outcomes ausrichtet.
Von Rohdaten zur Erkenntnis: Wie NumPy, pandas und Matplotlib zusammenspielen – vektorisiertes Rechnen, groupby-Aggregation und ein schneller Plot in einer kleinen Pipeline.
Für die meisten Systeme reicht CRUD. CQRS und Event Sourcing lohnen sich nur unter klaren Bedingungen – dieser Beitrag liefert einen ehrlichen Entscheidungsleitfaden statt Muster als Selbstzweck.
Die Ideen hinter GraphQL, die bleiben, egal welcher Server gerade modern ist – das Schema als typisierter Vertrag, die Query als Form, das Resolver-Modell und die Reihenfolge der Ausführung. Eine konzeptuelle Vertiefung mit Diagrammen.
AWS AppSync verschiebt den GraphQL-Server aus der eigenen Betriebsverantwortung in einen managed Dienst. Ich zeige am DynamoDB-Backend, wann diese Build-vs-Buy-Entscheidung trägt und wann managed zur Sackgasse wird, inklusive der VTL-Mapping-Templates, die 2021 der Preis dafür sind.
Context löst das Verteilen von Daten durch den Baum – aber nicht die Frage, wem der Zustand gehört. Wer beides verwechselt, baut einen globalen Store durch die Hintertür ein und erzeugt bei unbedacht wechselnden Provider-Werten unnötige Renderläufe.
Ein Werkzeugkasten für jede Datenquelle: Wann die Standardbibliothek reicht, wann pandas lohnt, und wie man Encoding, Speicher und SQL-Injection nicht zum Verhängnis werden lässt.
Warum wir uns damals für PostgreSQL und gegen den Message-Bus entschieden haben? ADRs machen das Warum als versioniertes Markdown-Artefakt haltbar – statt es im Flurfunk versickern zu lassen.
Wie man ein GraphQL-Schema additiv weiterentwickelt, statt es zu versionieren – sichere Änderungen, echte Breaking Changes, @deprecated als Werkzeug und eine Feld-Migration Schritt für Schritt.
Step Functions machen aus verschachtelten Lambda-Handlern eine deklarative State Machine: sichtbarer Ablauf, explizite Retry- und Catch-Pfade, Standard oder Express.
Event Sourcing speichert nicht den aktuellen Zustand, sondern die Folge der Events als Wahrheitsquelle: der Event-Store als Logbuch, der Zustand als Faltungsergebnis. Nutzen, ehrliche Kosten und die Abgrenzung zu CQRS.
Wie ich Flask-Endpunkte teste: mit app.test_client() ohne laufenden Server, pytest-Fixtures und geprüften JSON-Antworten.
React speichert Zustand nicht in der Komponente, sondern an ihrer Position im Render-Baum – wer das versteht, steuert Erhalt und Reset absichtlich statt zufällig.
Cognito User Pools als managed Identity-Backend: Sign-up, Confirm und Sign-in ohne eigenen Auth-Server, die drei Tokens richtig verstanden und ein API-Gateway-Endpunkt, den ein Cognito-Authorizer absichert.
Kurze Integrationszyklen mit Feature Flags schlagen langlebige Branches: tägliche Integration ohne Merge-Hölle und ein Release, das zur Entscheidung wird statt zum Deploy-Ereignis.
Vom JSX-Element zum sichtbaren Pixel – was zwischen einer Zustandsänderung und dem neu gezeichneten Bildschirm genau passiert. Render und Commit als getrennte Phasen, der Abgleich zweier Bäume und warum React fast immer nur einen winzigen Teil des DOM anfasst.
Warum ich ausgewählte, wiederkehrende Prüfungen als Workflows ausführe – und woran sich zeigt, ob die Automatisierung das Team tatsächlich entlastet.
Von Hello World zur JSON-API: wie Routing, Request-Verarbeitung und jsonify in Flask 1.1 zusammenspielen – und warum SSR und API dieselbe Mechanik sind.
Ein aus Events aufgebautes Read Model ist eine bewusst gepflegte Projektion für konkrete Abfragen. Herkunft und Rebuild unterscheiden es von einem zufällig gewachsenen Cache, auch wenn die technische Sicht cacheähnlich wirken kann.
Warum zentrale Freigabeprozesse in der Cloud Schatten-Infrastruktur züchten und wie technisch durchgesetzte Leitplanken – SCPs, Permission Boundaries, Config Rules, Budgets – Teams Bewegungsfreiheit zurückgeben.
Wer ein CDK Construct veröffentlicht, verschickt keine Hilfsfunktion, sondern Betriebsentscheidungen – über Defaults, Upgrade-Pfade und das, was beim Konsumenten im CloudFormation-Template landet.
Bevor ich Services schneide, kläre ich fachliche Grenzen. Ein Bounded Context ist eine Sprachgrenze und ein möglicher, aber nicht zwingender Serviceschnitt.
Comprehensions, functools und itertools im Zusammenspiel: Wie ich in Projekten zeige, wann eine Comprehension die bessere Wahl ist als map/filter, wo lru_cache und groupby glänzen und welche Fallstricke lauern.
Ein präziser Blick auf JSX – was der Compiler daraus macht, warum in geschweiften Klammern Ausdrücke statt Anweisungen stehen, wie Attribute, Kinder, Bedingungen und Listen funktionieren und an welchen Stellen Anfänger stolpern.
Deployment Pipelines sind Architektur, weil sie bestimmen, wie häufig, sicher und reversibel ein System verändert wird.
Drei Bausteine, die pythonischen Code ausmachen: Decorators umschließen Funktionen, Magic Methods binden eigene Objekte an Pythons Protokolle, Generatoren erzeugen lazy Sequenzen.
Policy as Code macht einen prüfbaren Teil der Architekturregeln ausführbar und versionierbar.
Ein Aggregat ist keine ORM-Entity und keine Tabelle, sondern eine Konsistenz- und Transaktionsgrenze: ein Verbund von Objekten, den eine Aggregate Root als Einheit schützt. Warum eine Transaktion genau ein Aggregat ändert und andere Aggregate nur per ID referenziert werden.
Eine kleine CLI über AWS SSM zeigt, wie Konfiguration aus einer benannten, zugriffskontrollierten Quelle in lokale Prozesse und CI gelangt – einschließlich Versions- und Ausfallfragen.
GitHub Actions und AWS CDK verbinden Codeänderung, Infrastruktur und Deployment zu einer reviewbaren Pipeline – und machen die Architekturentscheidung im Pull Request sichtbar.
Wer offline Schreibzugriffe erlaubt, wechselt von Request/Response zur Replikation – und der Revisionsbaum von PouchDB und CouchDB macht Konflikte zur Aufgabe des Fachmodells.
Command, Event und Query sind drei Nachrichtenarten mit klarer Semantik: ein Wunsch, der abgelehnt werden kann, eine geschehene Tatsache und eine seiteneffektfreie Abfrage. Wer sie sauber benennt und trennt, gewinnt Klarheit im Modell – ganz ohne großes CQRS-Setup.
Sobald Infrastruktur Code ist, entscheidet ein kleiner Diff über Sicherheit, Kosten und Ausfallrisiko – deshalb gehört sie in denselben Review-Prozess wie Anwendungscode.
Secrets im Build sind ein Vertrauensproblem: Wer darf was wann sehen, speichern und deployen?
Discovery senkt das Risiko, effizient das Falsche zu bauen. Ich zeige eine kontinuierliche Spur, die Annahmen prüft, bevor sie teure Delivery bindet – nicht eine Phase vor der Entwicklung.
CQRS trennt das Modell zum Schreiben vom Modell zum Lesen – eine fachliche Entscheidung, kein installierbares Framework. Wann sich die Grenze lohnt, wie man klein anfängt und welche Verwechslungen teuer werden.
Node.js lässt sich nicht am Framework erklären, sondern am Event Loop, an Streams und an der Frage, welche Architekturentscheidung ein Team morgen noch versteht – genau das übe ich mit Teilnehmern im Repo introduction-nodejs.
Mit dem CDK rückt Infrastruktur in dieselbe Werkzeugkette wie Anwendungscode, wodurch Tests, Reviews und logische Identitäten plötzlich über den Bestand von Produktionsdaten entscheiden.
Parameter Store im Build macht Konfiguration explizit, wirft aber harte Fragen zu Secrets und Reproduzierbarkeit auf.
Wie ich in Projekten eine private Docker Registry mit registry:2 aufsetze: Images taggen, pushen und pullen, und danach mit htpasswd und TLS absichern.
Unter dem Druck eines echten Deployments sortieren sich die Kubernetes-Konzepte von selbst nach Wichtigkeit – vom Pod über Deployment und Service bis zum Ingress.
Container-Logs verstreuen sich über viele Container und sind flüchtig. Dieser Artikel zeigt, wie ein ELK-Stack aus Elasticsearch, Logstash und Kibana im Compose-Setup Logs zentralisiert, indiziert und durchsuchbar macht.
Warum die eigentliche Arbeit bei Micro-Frontends nicht in der Integrationstechnik steckt, sondern im Teamschnitt – gezeigt an einer lauffähigen Beispiel-Landschaft aus Gateway, vier Anwendungen und einer Komponenten-Bibliothek.
Warum Props, URLs, Events, CSS-Klassen und localStorage dieselbe Versionierungs-Disziplin verdienen wie ein REST-Endpunkt – spätestens, wenn mehrere Teams im selben Browser arbeiten.
Wie ich in Projekten eine Zwei-Container-App aus Node.js und Redis mit Docker Compose beschreibe: eine YAML für den ganzen Stack, Service Discovery über den Servicenamen, Persistenz per Volume – und warum depends_on nicht auf Betriebsbereitschaft wartet.
Warum „läuft im Container“ weder Isolation noch Reproduzierbarkeit noch geregelten Betrieb bedeutet – und welche Handgriffe die drei Lücken tatsächlich schließen.
Ich benutze MVP für ein Experiment, das eine riskante Annahme ehrlich testet. Diese Arbeitsdefinition verhindert, dass ein bloß reduziertes Feature-Set schon als Lernen gilt.
Ein GraphQL-Schema ist der beste Ort, den es je für die ubiquitäre Fachsprache gab – und wenn die Domäne deutsch ist, darf sie dort auch deutsch bleiben.
Ob ein Framework-Wechsel zum Umzug oder zum Neubau wird, entscheidet sich daran, wie billig zwei Welten monatelang nebeneinander laufen können.
class in ES2015 ist im Kern Syntax-Zucker über Prototypen: Wer die [[Prototype]]-Kette, Object.create und den new-Ablauf versteht, debuggt this-Fehler und geteilte Methoden souveräner.
Der Store ist der langweiligste Teil von Redux – wertvoll ist das Nachrichtenprotokoll aus benannten, serialisierbaren Actions, das UI-Änderungen nachvollziehbar, testbar und diskutierbar macht.
Drei JavaScript-Muster haben jeden Framework-Wechsel überlebt: das Module-Pattern für saubere Kapselung, Higher-Order Functions für Funktionen als Werte und Currying für spezialisierte Varianten. Warum sie das Fundament moderner Utility-Libraries bilden.
Warum Server-Sent Events für die meisten Echtzeit-Anforderungen die einfachere Wahl sind und wann sich der Preis einer echten WebSocket-Verbindung tatsächlich lohnt.
Wie KnockoutJS Reaktivität löst: Observables als get/set-Funktionen, Computed mit automatischem Dependency-Tracking und gezielte DOM-Updates statt globalem Baum-Vergleich.
Eine kleine Wetter-App als Progressive Web App zeigt, warum Offline-Verhalten eine Produktentscheidung ist und wie ehrlich eine Oberfläche mit veralteten Daten umgehen sollte.
Ein unschlagbarer Tic-Tac-Toe-Gegner in React zeigt, warum Spiellogik als reine Funktion nichts vom Rendering wissen darf – und warum unveränderliche Züge zu Reacts Modell passen.
In vielen Projekten kompensiert Prozess-Overhead einen zu großen oder spekulativen Entwurf. Kleiner zu schneiden kann Koordination sparen; externe Vorgaben und echte Abhängigkeiten bleiben.
Im Frühjahr 2017 tragen CSS Grid, Flexbox, fetch und natives ES2015 so weit, dass die erste Architekturfrage im Frontend neu gestellt gehört: Wie weit komme ich ohne Framework?
Wer Producer und Consumer benennt, erkennt sofort, ob Daten gezogen oder geschoben werden, und wählt zwischen Funktion, Iterator, Promise und Observable ohne Raten.
Die Rechnung „ein Thread mal 200 Verbindungen“ zeigt, welche Systeme zu Node.js passen und welche Arbeit besser in eigene Prozesse gehört.
Babel übersetzt Syntax, kein Ausführungsmodell – wer das trennt, weiß, warum babel-node in die Entwicklungsschleife gehört und nicht in den Betrieb.
Wer Operationen, Daten und Fehlerfälle vor der Framework-Wahl festlegt, kann das Frontend später fast beliebig tauschen – umgekehrt bekommt man eine API, die ein Framework nachbildet.
Ein Nachbau der Elm-Architektur mit RxJS und React – Actions als Strom, scan() faltet das Model, Nebenwirkungen bleiben am Rand – und was dieser Proof of Concept über gut alternde UI-Architektur verrät.
Ein Open-Source-Experiment aus dem Sommer 2016: eine GraphQL-Laufzeitumgebung, die aus einer Schema-Kurznotation eine komplette CRUD-API über PouchDB erzeugt – inklusive Synchronisation über das CouchDB-Replikationsprotokoll.
Der automatisierbare Kern einer Definition of Done gehört in ein grünes Gate aus Lint, Build und Test. Fachliche Abnahme und andere Urteile bleiben gemeinsame Qualitätsarbeit.
Warum Props der öffentliche Vertrag einer React-Komponente sind – und was sich ändert, wenn man sie wie eine API entwirft statt wie eine Parameterliste.
Ein halbes Jahr nach der Spezifikation sortiert dieser Beitrag, was an GraphQL wirklich neu ist – und welche Fragen Anfang 2016 noch niemand beantwortet hat.
Build-Skripte verdienen die Sorgfalt von Produktcode, weil sie bestimmen, wie reproduzierbar ein System tatsächlich ist.
Ein Memory-Spiel in frischem ES2015, ohne Framework gebaut, macht sichtbar, welche Zustände eine UI wirklich hat, wo sie liegen sollten und wer sie ändern darf.
Wer eingehende Nachrichten hinter einem Observable versteckt, macht den Transport zwischen Browser und Server austauschbar – und merkt dabei, wie weit gewöhnliches HTTP trägt.
Warum funktionaler Stil im Team-Alltag 2015 nicht Haskell bedeutet, sondern die Disziplin, reine Funktionen von I/O zu trennen – und wie ES2015 das endlich bequem macht.
Docker macht Systemgrenzen sichtbar und transportabel – gezogen werden müssen sie weiterhin von Hand, und ein Monolith bleibt auch im Container ein Monolith.
Dieselbe kleine Aufgabe in Dutzenden Programmierstilen gelöst ist der kompakteste Architekturvergleich, den ich kenne – weil jeder Stil eine bewusst gewählte Constraint-Menge ist.
Eine kleine Nancy-API unter Mono in einen Docker-Container zu packen war im Frühjahr 2015 ein Umweg über Linux – und hat mir mehr über .NET-Deployment beigebracht als jedes IIS-Handbuch.
Frühe Tests helfen, ein Problem zu begreifen, auch wenn der Code später komplett ersetzt wird.
Ein Brett aus Zahlen, ein Zug als reine Funktion und ein Greedy-Löser zeigen im Kleinen, was in großen Systemen verschwimmt: die Trennung von Kernlogik, Strategie und Darstellung.
Ein Rückblick auf ein eigenes Parser-Demo von 2010 zeigt, warum ein handgeschriebener Ausdrucks-Parser auf wenigen Zeilen mehr über Schichten, Struktur und die Grenze zwischen Syntax und Semantik lehrt als manches große Projekt.
Wer Zustand als Faltung über einen Strom von Ereignissen berechnet statt ihn direkt zu ändern, bekommt Undo, Replay und Nachvollziehbarkeit fast geschenkt.
Was der Heroku HTTP API Design Guide taugt, wenn man ihn an eigenen APIs spiegelt – und warum wenige Ressourcen, ein Versionsversprechen und selbsterklärende Fehler mehr bewirken als jedes Framework.
Nicht die Syntax hat mich zu Elixir gebracht, sondern das Ausführungsmodell der Erlang-VM – Prozesse, Nachrichten und Supervisors, betrachtet mit JavaScript- und C#-Augen.
Ein Blick auf die winzige Bibliothek cflow zeigt, wie Node-Entwickler asynchrone Schritte von Hand zu einer Kette verdrahteten und warum der fehlende Fehlerkanal die eigentliche Lektion ist.
Eine Kata ist ein Architektur-Labor im Kleinen – weil die Aufgabe konstant bleibt, wird sichtbar, was sonst nur der Entwurf weiß.