Blog ·
Ein Datum in der Zukunft ist kein Plan
Vierundzwanzig veröffentlichte Beiträge behaupteten, noch nicht erschienen zu sein. Die Lösung war kein Planer, sondern ein Build, der solche Daten ablehnt.
Von Provibr
Jeder Beitrag auf dieser Seite trägt ein Veröffentlichungsdatum in seinem Kopfbereich. Es steht unter dem Titel, es geht in die strukturierten Daten ein, die eine Suchmaschine liest, und es ist das einzige Datum, das die Sitemap je ausgibt. Es soll eine Tatsache sein.
Eine Zeit lang waren vierundzwanzig davon keine. Sie trugen Daten, verteilt über die folgenden sechs Tage, weil wer sie schrieb einen Veröffentlichungsrhythmus im Sinn hatte und ihn in die Datei schrieb. Je neun Sprachen, also zweihundertsechzehn Dateien. Jede dieser Seiten war erreichbar, durchsuchbar und im Index, und jede erzählte einem Sammler in maschinenlesbarer Form, sie sei an einem Tag erschienen, den es noch nicht gegeben hatte.
Nichts stand auf rot. Der Build war grün, die Tests waren grün, die Seiten wurden ausgeliefert. Den Widerspruch sehen konnte nur eine Maschine, die die Seite las, und Maschinen melden keine Fehler.
Was die Historie sagte
Zuerst musste festgestellt werden, welches der beiden Daten wahr war. Das ist ein Befehl: fragen Sie git, wann jede Datei zuerst hinzugefügt wurde. Alle vierundzwanzig wurden am selben Tag hinzugefügt, in drei Übergaben, durch drei Runden derselben Nachtarbeit. Es gab keine Ausrollung über sechs Tage. Die Streuung war eine Absicht, die in ein Feld geschrieben worden war, das für Beobachtungen gedacht ist.
Diese Unterscheidung ist der ganze Beitrag. Ein Feld, das festhält, was geschehen ist, kann nicht zugleich ausdrücken, was Sie vorhaben, denn ein Leser kann beides nicht auseinanderhalten und ein Sammler ebenso wenig.
Warum wir den Planer nicht gebaut haben
Die naheliegende Reparatur ist, die Daten wahr zu machen, indem die Seite sie beachtet: verbirg einen Beitrag, bis sein Datum kommt. Das ist hier aus zwei unabhängigen Gründen die falsche Reparatur, und beide sind es wert, ausgeschrieben zu werden, weil der erste leicht zu übersehen ist.
Diese Seite wird statisch erzeugt. Seiten werden einmal gerendert, während des Builds, und als Datei ausgeliefert. Ein Tor auf dem Datum wird also zur Bauzeit bewertet und danach nie wieder. Um Mitternacht erscheint nichts; es erscheint, wenn jemand baut. Ein Datumstor ergibt somit keinen Veröffentlichungsplan, sondern eine Menge Seiten, die fehlen, bis zufällig eine unbeteiligte Auslieferung läuft.
Der zweite Grund ist schlimmer. Diese zweihundertsechzehn Adressen waren bereits gesammelt. Sie bis zu ihrem genannten Datum zu verbergen heißt, bis zu sechs Tage lang eine 404 auf Seiten auszuliefern, die eine Suchmaschine schon gesehen und aufgenommen hat. Eine 404 auf einer zuvor aufgenommenen Adresse ist kein „komm später wieder“, sondern ein Entfernungssignal, und die Erholung davon kostet weit mehr als die behobene Unwahrheit.
Die Daten wurden also auf den Tag korrigiert, an dem die Arbeit wirklich landete, wobei in jeder der zweihundertsechzehn Dateien nur diese Zeile berührt wurde, und stattdessen wurde die Möglichkeit entfernt, überhaupt ein zukünftiges Datum zu schreiben.
Das Tor steht an der Quelle und hat keine Hintertür
Der Inhaltsbuild lehnt nun jedes Datum im Kopfbereich ab, das nach dem Tag liegt, an dem er baut. Keine Warnung: ein fehlgeschlagener Build mit dem Dateinamen und beiden Daten in der Meldung.
Zwei kleine Entscheidungen darin verdienen einen Namen. Er vergleicht mit heute in der eigenen Zeitzone des Projekts und nicht mit UTC, denn ein Beitrag, der hier um halb eins nachts erscheint, trägt das hiesige Datum, und ein Vergleich mit UTC würde eine Datei an ihrem eigenen Erscheinungstag ablehnen. Und es gibt absichtlich keine Übersteuerung: keine Umgebungsvariable, kein Schalter. Eine Hintertür an einer solchen Regel wird einmal aus gutem Grund benutzt und danach dauerhaft, und ein Zeitplan gehört in eine Aufgabenliste und nicht in den Kopfbereich einer Datei, die bereits übergeben ist.
Weiter hinten steht ein zweites Tor, im Verzeichnis, das die veröffentlichten Beiträge zusammenstellt, und es lässt jeden Beitrag weg, dessen Veröffentlichungsdatum noch in der Zukunft liegt. Das ist ein Auffangnetz für die Wege, die nicht am Build vorbeikommen: eine von Hand bearbeitete Datei, eine Zusammenführung, die zwei Generationen vermischt, ein zurückgespieltes Backup. Es prüft nur das Veröffentlichungsdatum und nicht das Änderungsdatum, denn ein Tippfehler in einem Datumsfeld soll keine bereits aufgenommene Seite verschwinden lassen.
Und dieses zweite Tor wird einmal bewertet, beim Laden des Moduls während des Builds. Das steht in einem Kommentar daneben, denn ein Leser, der etwas anderes annimmt, schreibt am Ende genau den Planer, gegen den dieser Abschnitt argumentiert.
Ein Datum, das Sie nicht ableiten können, lassen Sie besser weg
Dieselbe Runde musste entscheiden, welches Datum, wenn überhaupt, zu den Dokumentationsseiten gehört, die gar keinen Kopfbereich haben. Drei Kandidaten boten sich an, und alle drei sind unwahr.
| Kandidat | Warum er falsch ist |
|---|---|
| Das Git-Datum der Seitendatei | Ändert sich bei einem geänderten Klassennamen und ändert sich nicht, wenn der Text in eine Übersetzungsdatei wandert |
| Das Git-Datum des Übersetzungskatalogs | Eine Datei trägt Tausende unabhängige Texte und ändert sich deshalb ständig aus Gründen, die mit dieser Seite nichts zu tun haben |
| Das Builddatum | Sagt jeden Tag, jede Seite sei heute geschrieben worden |
Die Dokumentationsseiten tragen in ihren strukturierten Daten also kein Veröffentlichungsdatum. Nichts ist besser als eine plausible Zahl, denn eine plausible Zahl ist die, die niemand nachprüft.
Dieselbe Überlegung galt bereits für die Sitemap. Feste Routen tragen überhaupt kein Änderungsdatum, und der Grund ist keine Faulheit: ihr Inhalt ist Quelltext und ihr Text wohnt in neun Übersetzungskatalogen, jedes Datum, das wir berechnen könnten, folgte also etwas anderem als dem, was der Leser sieht. Eine Suchmaschine, die eine „geänderte“ Seite dreimal holt und unverändert vorfindet, lernt, das Feld zu übergehen, und dann ist das Feld schlimmer als abwesend für die Seiten, auf denen es echt ist. Beiträge tragen sehr wohl eines, denn es steht im Kopfbereich neben dem Titel, wo wer den Text überarbeitet es auch wirklich sieht.
Nach dieser Arbeit hat sich die Abdeckung überhaupt nicht geändert: die Beitragsadressen tragen ein Änderungsdatum, alles andere keines, genau wie zuvor. Geändert hat sich, dass zweihundertsechzehn dieser Daten in der Zukunft lagen und nun keines mehr.
Noch ein Widerspruch, gelöst durch Identität
Beim Durchsehen der strukturierten Daten tauchte eine kleinere Fassung desselben Problems auf: auf einigen Seiten waren Verfasser und Herausgeber zwei getrennte Einheiten ohne erklärte Beziehung. Wörtlich gelesen behaupteten diese Seiten, der Beitrag sei von einem Unternehmen verfasst und von einem anderen herausgegeben worden. Beide zeigen nun auf dieselbe Kennung. Niemand hätte sich beschwert, und es war dennoch eine Behauptung von uns, die nicht stimmte.
Was wir aufschreiben würden
- Schreiben Sie nie eine Absicht in ein Feld, das eine Beobachtung festhält. Ein Leser kann beides nicht trennen, eine Maschine ebenso wenig.
- Prüfen Sie die Behauptung an der Historie. Ein Befehl über die Dateihistorie entschied, welches von zwei Daten das echte war, und er widersprach allen vierundzwanzig Dateien.
- Ein Datumstor auf einer statisch erzeugten Seite ist kein Zeitplan. Um Mitternacht erscheint nichts; es erscheint beim nächsten Build.
- Verbergen Sie keine Adressen, die schon im Index sind. Eine 404 auf einer gesammelten Seite ist ein Entfernungssignal, und die Heilung kostet mehr als das Leiden.
- Setzen Sie das Tor dorthin, wo der Fehler entsteht, lassen Sie den Build scheitern, und bauen Sie keine Übersteuerung ein. Setzen Sie ein zweites Tor weiter hinten für die Wege, die das erste auslassen.
- Lassen Sie ein Datum weg, das Sie nicht ehrlich ableiten können. Drei plausible Quellen, alle drei falsch, heißt: die ehrliche Ausgabe ist nichts.
Zur Klarheit darüber, was das ist: dies ist Hausarbeit an einer öffentlichen Website, keine Produktfunktion, und es hat kein Verhalten verändert, für das jemand zahlt. Ein Teil davon ist unbewiesen. Die strukturierten Daten wurden gegen ihr eigenes Schema geprüft und von Hand gelesen, nicht von einem echten Sammler oder einer echten Vorschaukarte. Nichts davon wurde gegen den Index einer Suchmaschine gemessen, denn diese Messung dauert Wochen, und niemand sollte darauf warten, bevor er eine Unwahrheit entfernt.
Aus der Seitenarbeit an Provibr. Was es kostet, sechzehntausend Texte in neun Sprachen richtig zu halten, steht in sechzehntausend Schlüssel, neun Sprachen, und wie eine Kollision von Feldnummern in einem Protokoll verborgen blieb, steht in zwei Runden, eine Feldnummer.
