Warum wir ein Journal schreiben
Elchi Studios hält fest, was es baut und entscheidet, und warum. Was hineinkommt, was draussen bleibt und wie das Journal für Menschen und Maschinen gebaut ist.
Nachtrag vom 9. Oktober 2026: Das Journal erscheint jetzt auf Deutsch, Englisch, Französisch und Italienisch, und ein Beitrag ist online, sobald er veröffentlicht wird. Zwei Absätze weiter unten beschreiben den früheren Stand. Das Journal in vier Sprachen erklärt, was sich geändert hat.
Hier schreibt Elchi Studios auf, was es baut und was es entscheidet, und warum. Das ist kein Newsfeed und keine Liste von Features. Wenn sich etwas ändert, das ein Kunde, eine Entwicklerin oder sonst jemand bemerken würde, der sich auf uns verlässt, steht es hier vollständig: was sich geändert hat, der Grund, was es kostet und was noch fehlt.
Warum überhaupt aufschreiben
Eine Website sagt Ihnen, was eine Firma verkauft. Wie die Firma arbeitet, sagt sie selten, und genau dem vertrauen Sie, wenn Sie uns Ihre Website, Ihr Login oder Ihre Mail übergeben. Ein Changelog kommt näher heran, aber ein Changelog sagt, was sich geändert hat, und fast nie, warum. Das Warum ist der nützliche Teil. Es ist auch der Teil, der zuerst vergessen geht, auch bei uns.
Deshalb kommt jede Entscheidung, die zählt, hierher, mit ihrer Begründung, solange die Begründung noch frisch ist. Wenn wir etwas falsch machen, bleibt der Beitrag, der den Fehler erklärt, neben dem Beitrag stehen, der die Korrektur erklärt.
Was hineinkommt und was nicht
Ein Beitrag beschreibt etwas, das Sie heute nutzen oder bemerken können. Pläne, „demnächst“ und Features, die nur auf einer Folie existieren, bekommen keinen Beitrag. Ist etwas erst halb fertig, sagt der Beitrag, welche Hälfte.
Jeder Beitrag ist von der Person gezeichnet, die ihn geschrieben hat, mit ihrer Funktion. Eine Aussage einer Firma ist nur etwas wert, wenn jemand dafür einsteht. Überprüfbare Behauptungen verlinken auf ihre Quelle: den RFC, die Dokumentation des Herstellers, die Messung. Wo es eine Zahl gibt, steht die Zahl statt des Adjektivs.
Das Journal ist auf Englisch. EAuth, unsere Entwicklerdokumentation und die meisten Leute, die darauf aufbauen, arbeiten auf Englisch, und mit einer Sprache erreicht jeder Beitrag alle gleichzeitig. Der Rest von elchi.dev bleibt zuerst deutsch, denn das ist die Sprache der Firmen in Zug, für die wir Websites bauen.
Ein Beitrag ändert sich nicht hinter Ihrem Rücken
Die Adresse eines veröffentlichten Beitrags und der Tag seines Erscheinens sind fest. Das ist kein Versprechen, sondern eine Regel in der Datenbank: Ein Versuch, eines davon zu ändern, wird abgewiesen, egal von wem. Muss ein Beitrag später korrigiert werden, geschieht das offen, und der Beitrag zeigt neben dem Erscheinungstag den Tag der Aktualisierung. Wir korrigieren lieber, als zu löschen.
Lesbar, ohne etwas auszuführen
Immer mehr Leute finden Dinge über Suchmaschinen und Sprachmodelle statt durch Stöbern, und beide lesen Seiten wie ein sehr geduldiger Mensch, der für JavaScript keine Geduld hat. Deshalb besteht das Journal aus einfachen Dateien:
- jeder Beitrag ist vollständiges HTML, und nichts wird nachgeladen, um den Text anzuzeigen;
- jeder Beitrag ist auch als Markdown unter seiner eigenen Adresse mit angehängtem
.mdabrufbar, mit Autor und Daten im Front Matter und den Quellen unter dem Text; - es gibt einen Atom-Feed für alle, die lieber einen Reader nutzen;
- strukturierte Daten sagen Suchmaschinen, wer einen Beitrag geschrieben hat, wann und was er zitiert;
- die
llms.txtder Website listet die zwanzig neusten Beiträge, jeden mit der Adresse seines Markdowns.
Bilder laufen durch dieselbe Pipeline wie auf jeder Website, die wir bauen: AVIF und WebP in sechs Breiten von 320 bis 2560 Pixel, ausgeliefert von unserem Asset-Host, jedes mit einer Beschreibung für Menschen, die es nicht sehen können. Ein Bild ohne Beschreibung wird abgewiesen.
Wie es entsteht
Beiträge entstehen im selben Dashboard, das wir für alles andere auf elchi.dev nutzen, oder gehen an die API des Dashboards, mit einem Schlüssel, der genau einem Autor gehört. Der Text ist Markdown und wird vor dem Speichern geprüft: ein Titel, kein rohes HTML, Bilder nur aus unserer eigenen Mediathek. Eine zweite Prüfung markiert Formulierungen, die einen Text nach Prospekt klingen lassen. Sie warnt und weist nicht ab, denn die Person, die schreibt, entscheidet. Eine Regel bleibt niemandes Urteil überlassen: Die Datenbank weist den Geviertstrich und den Halbgeviertstrich in Titel, Zusammenfassung und Text ab.
Veröffentlichen allein ändert die Website nicht. elchi.dev besteht aus einfachen Dateien, also erscheint ein Beitrag mit dem nächsten Build der Website. Dieser Build holt jeden veröffentlichten Text von der API, und wenn die API nicht antwortet, bricht er ab, statt eine Website ohne den neuen Beitrag auszuliefern. Der Preis ist ein Schritt zwischen Veröffentlichen und Online-Gehen. Der Gewinn: Jede Seite, die jemand liest, wurde als Ganzes gebaut und geprüft.
Die ersten Beiträge behandeln das Release vom 3. Oktober 2026: den Umzug von EAuth auf eine eigene Domain, die Limits bei jedem Login und eine Handvoll Fehlerbehebungen, aus denen wir jeweils etwas gelernt haben.
Quellen
- RFC 4287: The Atom Syndication Format, IETF, gelesen am
- The /llms.txt file, llmstxt.org, gelesen am
- BlogPosting, Schema.org, gelesen am
Geschrieben von Samuel Krauss, Founder. Abgelegt unter company, journal.
Übersetzt aus dem Englischen. Zum englischen Original