Meine /projects-Seite macht drei Sorten Aussagen: „104 öffentliche Repos.” „Kopier diesen Befehl und führe ihn aus.” „17 von 18 kuratierten Repos in den letzten 30 Tagen gepusht.” Alle drei verrotten. Stars altern, Install-Befehle brechen, und ich merke es nicht, weil ich nicht in der Gewohnheit bin, meine eigene Website neu zu lesen. Die Seite speichert deswegen keine dieser Zahlen. Sie berechnet sie.
So geht das.
Was ich schreibe vs. was GitHub sagt
Alles, was ich selbst getippt habe — Beschreibungen, Topics, Install-Befehle — liegt in einer Datendatei und wird wie Code reviewt. Alles, was GitHub besitzt — Stars, Forks, Push-Daten — wird nirgendwo von Hand eingetragen. Zur Build-Zeit wird jedes Projekt aufgelöst: Live-API-Cache, wenn frisch, committeter Snapshot, wenn nicht. Fehlt ein kuratiertes Repo in beiden, failt der Build. Keine Null, keine Warnung. Failt. Einen roten Build fixe ich lieber, als jemandem eine Null zu erklären, die er vor mir gesehen hat.
Der committete Snapshot ist selbst generiert. pnpm run snapshot:refresh ruft die API einmal auf und generiert das Snapshot-Modul samt Voll-Archiv, und snapshot:check difft beide gegen die Live-API — Drift landet also in meinem Terminal und nicht in einem Screenshot, den jemand anderes von meiner Seite macht.
Jeder Install-Befehl wird ausgeführt
Das Kernversprechen der Seite lautet: „Kopier das und führe es aus.” Das ist nur ein Versprechen, wenn ich es vorher selbst ausgeführt habe. Also lief jede Install-Zeile in einer Sandbox mit leerem GOCACHE und GOMODCACHE — keine warmen Caches, genau der Zustand deines Laptops, wenn du einfügst.
Zwei sind gescheitert.
-
go install github.com/larsartmann/dynamic-markdown-site/cmd/dynamic-markdown-site@latest: Das Repo lieferttemplates/layout.templohne die generierte Go-Datei, dastemplates-Package existiert also nicht — weder im Tag noch auf dem Default-Branch. Die Install-Zeile ist von der Seite geflogen. Sie kommt zurück, wenn ein Release sich wirklich installieren lässt. -
gogenfilterwirkte wochenlang nicht installierbar, weil sein Modulpfadgithub.com/LarsArtmann/gogenfilter/v3lautet — mit Großbuchstaben. Der Module-Proxy löst case-insensitiv auf, deshalb sah alles gut aus, bisgo getauf exaktem Case bestand. Wochenlang „warum installiert das nicht” wegen Buchstaben, die sich nur in der Größe unterscheiden. Der funktionierende Befehl steht jetzt auf der Seite, Großbuchstaben inklusive.
Beide Bugs sind meine. Genau deswegen wollte ich eine Maschine, die sowas findet.
Fünfzehn Befehle haben bestanden. Jeder trägt den exakten Modulpfad aus dem go.mod des Repos, inklusive der /v2-artigen Suffixe, an denen kopierte Pfade lautlos zerbrechen.
Das Archiv: jedes Repo, Forks inklusive
Unter den achtzehn kuratierten Karten liegt eine eingeklappte Tabelle mit jedem öffentlichen Repository — Forks als Forks markiert, Push-Daten sichtbar, nichts rauskuratiert. Dieselbe Tabelle, dieselbe Reihenfolge wie die API-Antwort. Tests pinnen sie: eine Zeile pro öffentlichem Repo, eindeutige Namen, jedes kuratierte Repo vorhanden.
Wenn dir meine Kuratierung nach Rosinenpicken aussieht: scroll runter und prüf nach. Die Forks stehen alle drin.
Screenshots erkennen kein Overflow
Der fieseste Bug dieser Seite war in jedem Screenshot unsichtbar, den ich gemacht habe: Ein breiter Install-Befehl drückte seine Max-Content-Breite durch ein CSS-Subgrid und blähte das Kartengrid auf 1477px in einem 1440px-Viewport auf. body { overflow-x: clip } hatte den Scrollbalken schon gefressen — die Seite sah also perfekt aus, während ein Drittel vom Schirm hing. Gemerkt habe ich es durch Messen, nicht durch Anschauen.
Deswegen wird die Seite jetzt gemessen. Ein Gate lädt jede gebaute Route bei 390, 768 und 1440 Pixeln und failt, wenn document.scrollWidth den Viewport schlägt. Ein weiteres klickt in headless Chromium jeden Copy-Button, EN und DE, und prüft, dass exakt der richtige Befehl in der Zwischenablage landet. Ein drittes läuft nur mit Tab-Tastendrücken durch die Seite. Was lautlos kaputtgehen kann, bricht jetzt meinen Build.
Was das bringt
Die Zahlen können nicht lautlos veralten — ein veralteter Snapshot fällt durch ein Frische-Gate. Die Befehle können nicht lautlos brechen — die Sandbox erwischt es. Und nichts steht auf der Seite, weil es gut klingt. Derselbe Standard wie bei Kundensystemen: Wenn es zählt, prüft es der Build; wenn der Build es nicht prüfen kann, shipped es nicht.
Die Projekte-Seite ist das kleinste System, das ich komplett selbst besitze — damit auch der billigste Ort, um den Standard durchzuhalten.
Kopier dir einen Install-Befehl von der Seite und führe ihn aus. Genau dafür ist der ganze Aufwand da.