Connect with us

Entwicklung & Code

Events und Zeitstempel: Wann ist etwas wirklich passiert?


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Wer mit Events arbeitet, stößt früher oder später auf eine vermeintlich simple Frage: Wann ist etwas eigentlich passiert? Und die Antwort scheint naheliegend, denn jedes Event bringt schließlich einen Zeitstempel mit. Bei CloudEvents ist das etwa das time-Feld, das viele Systeme automatisch setzen, wenn ein Event gespeichert wird. Es liegt nahe, diesen Zeitstempel für Geschäftslogik zu verwenden, er ist ja schließlich da. Doch genau das führt zu subtilen Fehlern und falschen Annahmen.

Weiterlesen nach der Anzeige


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Das Problem: Wann wurde das Buch ausgeliehen?

Nehmen wir ein klassisches Bibliotheksbeispiel. Ein Leser leiht ein Buch aus, und das System erzeugt folgendes Event:


{
"source": "
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedUntil": "2026-02-12"
}
}


Fällt Ihnen etwas auf? Das Event enthält borrowedUntil (das Rückgabedatum), aber kein borrowedAt. Wer wissen will, wann das Buch tatsächlich ausgeliehen wurde, müsste auf den technischen Zeitstempel des Events zurückgreifen.

Aber hier liegt das Problem: Was, wenn der Leser das Buch bereits um 14:00 Uhr ausgeliehen hat, das System das Event aber erst um 14:02 Uhr geschrieben hat? Oder wenn der Bibliothekar die gestrigen Ausleihen erst heute Morgen eingetragen hat? Der technische Zeitstempel sagt uns, wann das Event gespeichert wurde, und nicht, wann die Ausleihe tatsächlich stattgefunden hat.

Warum technische Zeitstempel keine Geschäfts-Zeitstempel sind

Weiterlesen nach der Anzeige

Es gibt mehrere Gründe, warum der technische Zeitstempel für Geschäftslogik problematisch ist. Ein technischer Zeitstempel beschreibt, wann das System etwas getan hat. Ein Geschäfts-Zeitstempel beschreibt, wann etwas in der realen Welt passiert ist. Das sind zwei grundlegend verschiedene Konzepte und sie zu vermischen, kann zu subtilen Fehlern führen.

Das time-Feld eines Events beantwortet die Frage:

„Wann wurde dieses Event aufgezeichnet?“

Die fachliche Anforderung lautet aber oft:

„Wann ist das wirklich passiert?“

Das ist nicht dieselbe Frage. Und wichtig: Es geht hier nicht um Präzision oder Latenz, es geht vielmehr um Semantik.

Hinzu kommt: Ob ein Zeitstempelfeld überhaupt existiert, hängt vom Event-Format ab. CloudEvents enthält ein time-Feld, andere Formate aber möglicherweise nicht. Wer Events jemals in ein anderes Format konvertieren muss (etwa für Archivierung, Export oder Integration in andere Systeme), riskiert, dass der technische Zeitstempel verloren geht. Wenn Geschäftslogik von einem Feld abhängt, das bei einer Migration verschwinden könnte, baut man auf instabilem Grund.

Und das vielleicht stärkste Argument: Events werden häufig erst nach dem eigentlichen Ereignis aufgezeichnet. Ein paar Beispiele:

  • Ein Bibliothekar stellt fest, dass jemand die gestrige Ausleihe mit dem falschen Datum eingetragen hat. Das Korrektur-Event schreibt er heute, obwohl es sich aber auf etwas bezieht, das gestern passiert ist.
  • Eine mobile Bibliotheks-App erfasst eine Ausleihe, während das Gerät offline ist. Wenn es sich Stunden später synchronisiert, wird das Event erst dann persistiert, aber die eigentliche Ausleihe fand viel früher statt.
  • Die Datenmigration aus einem Legacy-System importiert Jahre historischer Events. Die technischen Zeitstempel würden alle das heutige Datum zeigen und historische Analysen wertlos machen.
  • Wenn das Zielsystem vorübergehend nicht erreichbar war, werden Events möglicherweise zwischengespeichert und später geschrieben. Der technische Zeitstempel zeigt den Schreibzeitpunkt, nicht das ursprüngliche Ereignis.

In all diesen Fällen liefert der technische Zeitstempel falsche Antworten für die Geschäftslogik.

Die Lösung: Zeit explizit machen

Das heißt: Wenn Zeit für das Geschäft relevant ist, gehört sie in die Event-Daten. Hier die verbesserte Version des Ausleihe-Events:


{
"source": "
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedAt": "2026-01-12T14:00:00.000Z",
"borrowedUntil": "2026-02-12"
}
}


Jetzt ist die Semantik klar:

  • borrowedAt: Wann das Buch tatsächlich ausgeliehen wurde (Geschäftszeit)
  • borrowedUntil: Wann das Buch zurückgegeben werden muss (Geschäftszeit (das war schon korrekt))
  • Event-Zeitstempel: Wann das System dieses Event aufgezeichnet hat (technische Zeit)

Interessant ist, dass borrowedUntil bereits ein Geschäftszeit-Feld war. Es fehlte nur das Gegenstück borrowedAt. Diese Inkonsistenz ist typisch: Entwickler denken oft daran, zukünftige Zeitpunkte aufzunehmen (Fristen, Fälligkeiten, Ablaufdaten …), vergessen aber gerne die vergangenen Zeitpunkte, also wann etwas tatsächlich geschehen ist.

Weitere Beispiele

Das Muster lässt sich auf andere Events übertragen:

  • book-borrowed mit borrowedAt: Wann das Buch ausgeliehen wurde
  • book-returned mit returnedAt: Wann das Buch zurückgegeben wurde
  • reader-registered mit registeredAt: Wann sich der Leser angemeldet hat
  • late-fee-charged mit chargedFor: Welchen Zeitraum die Gebühr abdeckt

Jedes dieser Felder beschreibt, wann etwas in der realen Welt passiert ist, unabhängig davon, wann das System es aufgezeichnet hat.

Wann der technische Zeitstempel akzeptabel ist

Heißt das, man sollte den technischen Zeitstempel komplett ignorieren? Nein. Es gibt legitime Verwendungszwecke: Debugging, um die Reihenfolge der Event-Persistierung nachzuvollziehen. Monitoring, um Systemlatenz und Durchsatz zu messen. Audit-Trails, um zu dokumentieren, wann Datensätze ins System gelangt sind.

Aber das sind alles technische Belange, keine fachlichen.

Und was ist mit dem technischen Zeitstempel als Fallback, wenn man vergessen hat, ein Geschäftszeit-Feld hinzuzufügen? Das ist ein Workaround, keine Lösung. Wer sich in dieser Situation wiederfindet, sollte erwägen, eine neue Version des Event-Typs einzuführen, die das explizite Zeitfeld enthält. Ja, dann muss man beide Versionen verarbeiten können, aber man gewinnt Klarheit und Korrektheit für die Zukunft.

Man sollte auch nicht versuchen, das Ganze mit

„die Latenz ist klein genug“

oder

„wir brauchen keine hohe Präzision“

zu beschönigen. Diese Argumente verfehlen den Punkt. Es geht nicht um Latenz oder Präzision, sondern es geht um semantische Klarheit. Ein technischer Zeitstempel und ein Geschäfts-Zeitstempel beantworten unterschiedliche Fragen, unabhängig davon, wie nah ihre Werte beieinander liegen mögen.

Zeit wirkt einfach, bis man genauer hinschaut. Bei der Arbeit mit Events ist die Unterscheidung zwischen „wann etwas passiert ist“ und „wann das System es aufgezeichnet hat“ fundamental. Wer diese Grenze verwischt, riskiert subtile Bugs, fehlerhafte Reports und Systeme, die die Realität nicht korrekt abbilden.

Die Lösung ist einfach: Wenn Zeit für das Geschäft relevant ist, gehört sie explizit in die Event-Daten. Das zukünftige Ich (und alle, die diese Events später analysieren müssen) werden es danken.


(who)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Eclipse Theia 1.68: KI-Agenten lernen Skills und erledigen To-do-Listen


EclipseSource hat die Veröffentlichung von Eclipse Theia 1.68 bekanntgegeben, einer quelloffenen Entwicklungsplattform für Web- und Cloud-basierte Tools. Das aktuelle Release erlaubt das Verwenden von GitHub Copilot out-of-the-box und lässt KI-Agenten – noch als Alpha-Feature – Skills verwenden. Neben zahlreichen KI-bezogenen Updates gibt es auch weitere Neuerungen, unter anderem zur Verbesserung der Accessibility.

Weiterlesen nach der Anzeige

Aufgabenplanung zum Mitverfolgen

KI-Agenten können in Eclipse Theia durch das neue Tool todo_write den Fortschritt mehrstufiger Aufgaben visuell darstellen: Sie können To-do-Listen erzeugen, die im Chatfenster angezeigt und aktualisiert werden. Die Aufgaben erhalten, ihrem Status entsprechend, Icons für „noch nicht erledigt“, „in Arbeit“ oder „erledigt“. Um das Feature nutzen zu können, muss der neue Agenten-Modus „Agent Mode (Next)“ aktiviert sein. Dieser soll sich dadurch auszeichnen, dass er Coding-Aufgaben effektiver, zuverlässiger und autonomer durchführt.

Das Entwicklungsteam zeigt ein Beispiel: Ein Prompt fordert den KI-Agenten auf, eine To-do-Liste für das Kochen einer Mahlzeit zu erstellen und so zu tun, als würde er die dafür nötigen Schritte ausführen.


Der KI-Agent arbeitet eine virtuelle To-do-Liste ab.

Der KI-Agent arbeitet eine virtuelle To-do-Liste ab.

Der KI-Agent arbeitet eine virtuelle To-do-Liste ab.

(Bild: EclipseSource)

GitHub Copilot in Eclipse Theia 1.68

Entwicklerinnen und Entwickler mit aktivem GitHub-Copilot-Abo können dieses nun direkt innerhalb der Theia IDE sowie in mit Theia AI erstellten Tools verwenden. Sie benötigen dafür weder zusätzliche API-Keys noch Abos. Dahinter steht technisch das neue Package @theia/ai-copilot, das GitHub Copilot als Language-Model-Anbieter in Eclipse Theias KI-Framework integriert, mitsamt Authentifizierung per OAuth.

Weiterlesen nach der Anzeige

Wie der Authentifizierungsvorgang aussieht, demonstriert das EclipseSource-Team:


GitHub Copilot lässt sich direkt aus Eclipse Theia 1.68 heraus nutzen.

GitHub Copilot lässt sich direkt aus Eclipse Theia 1.68 heraus nutzen.

GitHub Copilot lässt sich direkt aus Eclipse Theia 1.68 heraus nutzen.

(Bild: EclipseSource)

Skills für KI-Agenten

Als Alpha-Feature können KI-Agenten in Eclipse Theia nun Agent Skills nutzen. Diese bestehen aus wiederverwendbaren Anweisungen und Domänenwissen, die Agenten aus SKILL.md-Dateien beziehen. Unter anderem können Agenten im Verzeichnis ~/.theia/skills/ vorhandene Skills automatisch entdecken, spezifische Skills per Entwickleranweisung mithilfe des Befehls /skillName nutzen oder Skills nach Bedarf laden. Für Letzteres dient die Variable {{skills}}, die Entwicklerinnen und Entwickler in Agenten-Prompts einfügen können.

Das Erstellen von Skills mithilfe des CreateSkill-Agenten befindet sich ebenfalls im Alpha-Status. Um projektspezifische Skills festzulegen, dient das KI-Chat-Interface. Dort können Developer den gewünschten Skill beschreiben, und der Agent wird eine korrekt strukturierte SKILL.md-Datei mitsamt entsprechendem YAML-Frontmatter und Markdown-Inhalt erstellen.

Updates für Accessibility und VS-Code-Kompatibilität

Für eine verbesserte Barrierefreiheit sind im Chat nun Fokusnavigationsbefehle verwendbar, um per Tastatur zwischen Input und Antworten zu navigieren (Strg/Cmd+oben/unten). Auch sind alle Chat-Buttons jetzt per Tastatur zugänglich, und für Screenreader stehen umfassende ARIA-Attribute bereit.

Daneben wurde die Kompatibilität mit Erweiterungen für Visual Studio Code auf die API-Version 1.108.0 erhöht und das Theia-Team hat einige Bugs behoben, wie der Blogeintrag zur Ankündigung aufführt.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Codex-Spark: Schnelles Coding-Modell von OpenAI


Ein erstes Modell fürs Coden in Echtzeit, so beschreibt OpenAI das neu herausgebrachte GPT-5.3-Codex-Spark. Es ist eine Research-Preview und setzt erstmals auf einem Cerebras-Chip auf.

Weiterlesen nach der Anzeige

Codex-Spark soll besonders schnell sein – konkret 1000 Tokens in der Sekunde liefern können. Doch auch OpenAI schreibt in einem Blogbeitrag, dass das auf Kosten der Qualität gehen kann – das zeigt zumindest der Terminal-Bench 2.0, der auf die Genauigkeit abzielt. Dennoch soll dank der Schnelligkeit eine neue, andere interaktive Arbeit mit dem Modell möglich sein. Codex-Spark lässt sich beispielsweise auch in Echtzeit unterbrechen oder umlenken, heißt es. Es gibt aber etwa keine automatische Vorschau. Verarbeitet wird grundsätzlich nur Text, das Modell hat ein 128K-Kontextfenster.

Im Januar hatte OpenAI die Partnerschaft mit dem kalifornischen Chipdesigner Cerebras bekannt gegeben. Die haben seither verstärkt an einem Chip gearbeitet, der auf Inferenz ausgelegt ist, also besonders schnell KI-Algorithmen auszuführen. Bisher hatte OpenAI auf KI-Beschleuniger von Nvidia gesetzt. So richtig ausgereift klingt Codex-Spark allerdings noch nicht. Im Blogbeitrag steht, man wolle das Modell für frühe Experimente freigeben, während man unter anderem noch an der Endnutzer-Erfahrung arbeite. Zunächst gibt es auch spezielle Rate-Limits, dazu gehört, dass die Nutzung bei vielen Zugriffen auch grundlegend eingeschränkt werden kann. Zugriff haben ChatGPT-Pro-Nutzer mit Codex-App, der CLI und der VS-Code-Erweiterung.

OpenAI kündigt auch bereits an, dass Codex-Spark das erste Modell einer neuen „ultraschnellen Modell-Familie“ sein soll. Multimodalität und weitere Fähigkeiten sollen entsprechend folgen.

Erst vor wenigen Tagen hat OpenAI mit GPT-Codex-5.3 ein neues Modell mit Coding-Fähigkeiten veröffentlicht. Auch dieses soll vor allem schneller sein, als der Vorgänger. Hier geht es aber mitnichten um Echtzeit sondern um minutenlange Denkprozesse zur Aufgabenerfüllung. Zudem gibt es mit der Codex-App eine Kommandozentrale für KI-Workflows.

Sam Altman witzelt bei X, dass ihm das neue, schnelle Modell Freude bereiten würde. Dabei bezieht er sich mit dem englischen Satz „It sparks joy for me“ auf die 2010er Fernsehsendung, in der Marie Kondo Menschen beim Ausmisten geholfen hat. Die Aufräum- und Minimalismusexpertin fragte bei jedem Teil, ob es dem Besitzer Freude bereite – nur dann durfte man es behalten. Kondo allerdings ihren eigenen Spark-Stil längst über Bord geworfen und lässt eigenen Aussagen zufolge lieber ein bisschen Chaos zu.

Weiterlesen nach der Anzeige


(emw)



Source link

Weiterlesen

Entwicklung & Code

PHP-Framework: Tempest 3.0 bringt neuen Error-Handler


Tempest 3.0 ist erschienen. Das noch recht junge PHP-Framework bringt einen neuen Exception-Handler, Performance-Optimierungen, Unterstützung für PHP 8.5 sowie zahlreiche Detailänderungen. Auf GitHub verzeichnet das Projekt 2100 Sterne.

Weiterlesen nach der Anzeige

Das Tool richtet sich an Entwicklerinnen und Entwickler, die Webanwendungen mit einem integrierten Stack aus Routing, ORM, View-System, Konsole und OAuth-Anbindung umsetzen wollen. Es bündelt typische Infrastrukturaufgaben und setzt konsequent auf aktuelle PHP-Versionen. Hinter dem Projekt steht unter anderem Brent Roose, der die Community unter stitcher.io über Neuerungen rund um die Programmiersprache auf dem Laufenden hält.

Fokus auf PHP 8.5

Version 3.0 unterstützt ausschließlich PHP 8.5 oder neuer. Das Projekt bleibt damit bei seiner Linie, nur die jeweils aktuelle PHP-Version zu berücksichtigen. Das soll den Einsatz neuer Sprachfeatures erleichtern, setzt aber eine entsprechend moderne Laufzeitumgebung voraus.

Neuer Exception-Handler und ORM-Updates

Statt der PHP-Bibliothek Whoops nutzt Tempest ab sofort einen eigenen Exception-Handler, der sich offenbar enger in das Framework integrieren lässt und das Debugging verbessern soll.

Im Datenbankbereich wurde das ORM laut Entwicklerteam performanter. Neu ist zudem die Unterstützung von UUIDs (Universally Unique Identifier) als Primärschlüssel. Die Methode Query::toRawSql wurde überarbeitet, um komplexe Abfragen nachvollziehbarer zu machen.

Weiterlesen nach der Anzeige

CSRF, Views und OAuth

Beim Schutz vor Cyberangriffen wie Cross-Site Request Forgery (CSRF) ersetzt Tempest den klassischen Token-Ansatz durch die Header Sec-Fetch-Site und Sec-Fetch-Mode. Das bisherige x-csrf-Element entfällt.

Der View-Parser erhält Whitespace nun unverändert, was das Debugging erleichtern soll. Zusätzlich unterstützt Tempest Validierungsregeln mit Closures und erweitert die OAuth-Integration um Twitch.

Upgrade und Ausblick

Als Major-Release bringt Tempest 3.0 mehrere Breaking Changes, etwa beim Exception-Handling, Session-Management und bei Konfigurationsklassen. Ein Upgrader auf Basis von Rector soll die Migration bestehender Projekte teilweise automatisieren.

Für die 3.x-Reihe plant das Team unter anderem eine Debugging-KI, Unterstützung für den Worker-Modus von FrankenPHP sowie eine Überarbeitung von Event- und Command-Bus. Weitere Informationen zum Release finden sich im Ankündigungsbeitrag auf der offiziellen Website zum PHP-Framework.


(mdo)



Source link

Weiterlesen

Beliebt