Diese Website zeigt an vielen Stellen Messwerte: Commit-Verläufe, Projektstände, Ereignisse aus laufenden Sitzungen. Auf dieser Seite erkläre ich, wie diese Daten entstehen und warum ich sie von Anfang an gesammelt habe.
Meine Ausbildung liegt in der Messtechnik. Wer misst, lernt früh: Eine konsistent erhobene und vergleichbare Reihe kann Entwicklungen zeigen, die in einem Einzelwert unsichtbar bleiben. Bloße Menge ersetzt weder Messqualität noch die sichtbare Einordnung von Abdeckung und Unsicherheit. Deshalb habe ich beim Aufbau der Werkstatt mitgeschrieben, sobald es technisch möglich war oder mir die Idee dazu kam.
Zuletzt aktualisiert: · ein Projekt von Dominic Meiser
Die Werkstattchronik zählt Commits pro Projekt und Monat. Grundlage ist ein datierter Auszug aus der Git-Historie aller Projekt-Repositories; der Stichtag steht direkt an der Chronik. Die Zahlen werden nicht von Hand gepflegt, sondern aus der Historie erzeugt und gegen sie geprüft.
(kleine Programme, die an definierten Stellen einer Agenten-Sitzung anspringen) melden jeden Werkzeugaufruf als Ereignis. Aus diesen Ereignissen entstehen die Live-Ansicht und das Replay der Kontrollschicht. Die Demo auf dieser Website läuft mit synthetischen Beispieldaten; die echten Ereignisse bleiben auf meinem Rechner.
Was die Arbeit mit den Agenten verbraucht, rechne ich täglich aus den Sitzungsprotokollen beider Rechner zusammen (ccusage, ein Kommandozeilenwerkzeug für -Verbrauchsdaten). Dabei habe ich gelernt, dass sich die hinterlegten Preistabellen über Nacht ändern können; seitdem halte ich die Version fest, damit die Messreihe vergleichbar bleibt. Konkrete Beträge veröffentliche ich hier nicht.
Ein täglicher Scan kartiert die Projektlandschaft für die . Die Kennzahlen des übernimmt die Website aus einer Betriebsdatei, die ich vor jeder Übernahme prüfe; schlägt die Prüfung fehl, bleibt der letzte gute Stand stehen.
Der Build führt mehrere klar abgegrenzte Schritte verpflichtend aus. Er prüft die öffentliche Atlas-Projektion auf Schema, Hash und Sicherheitsregeln und führt eine Typprüfung der Functions aus. Generatoren aktualisieren Posts, Repository-Sichtbarkeit und Routenstände; danach entstehen Client, Server und statische Seiten. Die „Zuletzt aktualisiert"-Stempel und die Sitemap-Daten kommen aus der Git-Historie der jeweiligen Seite. Die Repository-Sichtbarkeit wird bei erreichbarem GitHub dort abgefragt; fällt die Abfrage aus, bleibt der letzte versionierte Stand bestehen. Andere öffentliche Zahlen werden dadurch nicht automatisch gegen ihre Quelle geprüft.
Quellen
Git-Historie · Hook-Ereignisse · Scans
Generator-Skripte
erzeugen Posts, Sichtbarkeit und Routenstände
Feste Prüfungen
prüfen Atlas-Projektion und Functions-Typen
Statische Seiten
entstehen aus Client, Server und Prerender
Drei Grenzen gehören dazu. Snapshots veralten zwischen den Stichtagen: Eine Zahl auf der Chronik ist so aktuell wie ihr Stichtag. Die Replay-Demo der Kontrollschicht zeigt synthetische Beispieldaten, die echten Abläufen nachempfunden sind, weil die echten Sitzungsprotokolle privat bleiben. Und private Repositories lassen sich hier nur beschreiben, nicht öffnen; auf Anfrage zeige ich sie im Gespräch.