Dieses Repository enthält sowohl den statischen Site-Generator als auch Inhalte für https://qubyte.codes.
Der Generator ist größtenteils in index.js enthalten. Der größte Teil der schweren Arbeit wird von einem benutzerdefinierten Diagrammerstellungssystem und Markierungen übernommen, das Markdown-Dateien aufnimmt und sie in HTML-Inhalte verarbeitet. Es ist jedoch nicht perfekt und es waren einige Nachbesserungen nötig. Das Modul lib/render.js führt diese Patches durch und fügt Syntaxhervorhebung und Formatierung mathematischer Formeln hinzu.
dienen.js ist ein Entwicklungsserver. Wenn sich Dateien ändern, werden Teile des Build-Diagramms erneut ausgeführt, um eine aktualisierte Ausgabe zu erhalten.
Quelldateien sind in den Verzeichnissen src und content enthalten. Beim Erstellen wird ein öffentliches Verzeichnis erstellt und einige dieser Quelldateien kopiert (solche, die keiner Kompilierung bedürfen, wie z. B. der Service Worker). Andere Dateien müssen generiert werden und werden beim Erstellen im öffentlichen Verzeichnis abgelegt.
netlify.toml ist eine Konfiguration für Netlify, das meinen Blog hostet (ich kann es nur wärmstens empfehlen). Zum Zeitpunkt des Schreibens enthält diese Datei nur die Konfiguration für Header. Diese sind für die Sicherheit und das Browser-Caching von CSS optimiert. Ursprünglich habe ich diesen Blog auf einem DigitalOcean-Droplet mit NGINX gehostet. Eine Konfiguration dafür ist immer noch Teil dieses Repos, nginx.conf.
Ich verwende Postcss, um CSS zu kompilieren. Grundsätzlich kann das CSS auch ohne verwendet werden. In den meisten Fällen wird Postcss verwendet, um das CSS zu verketten und zu minimieren. Das ausgegebene CSS wird gehasht und der Hash wird Teil des CSS-Dateinamens. Dabei handelt es sich um einen Cache-Bust, da CSS eine lange oder unbestimmte Cache-Zeit zugewiesen wird, um zu verhindern, dass das Laden von Seiten nach dem einmaligen Laden blockiert wird.
Mit Ausnahme der Syntaxhervorhebung vermeidet diese Website weitgehend die Verwendung von Klassen in HTML als Hooks für CSS und behauptet stattdessen, dass semantisches Markup ausreichend Kontext bietet, damit CSS daran festhalten kann.
Der Blog ist eine Progressive Web App (PWA) und verfügt entsprechend über Icons in verschiedenen Größen. Eines davon ist auch das Favicon.
Dieses Verzeichnis enthält die Markdown-Quellen veröffentlichter Beiträge. Jeder Beitrag verfügt über eine JSON-Präambel mit verschiedenen Metadaten:
Name | Beschreibung |
---|---|
Datum/Uhrzeit | Der Veröffentlichungszeitstempel des Beitrags. Wenn dies in der Zukunft liegt, wird der Beitrag nicht gerendert. |
Titel | Der Titel des Beitrags. |
Beschreibung | Die Beschreibung des Beitrags. Dies wird dem HTML-Kopf als Meta-Beschreibung und Meta-Twitter-Beschreibung hinzugefügt. Letzteres wird von Twitter verwendet, um Twitter-Karten zu füllen. |
Entwurf | Wenn „true“, wird der Beitrag nicht gerendert. |
Tags | Eine Liste von Tags. Diese werden oben in jedem Eintrag angezeigt und auch beim Teilen auf Twitter und Mastodon über die Links am Ende jedes Beitrags verwendet. |
Weberwähnungen | Eine Liste von Web-Erwähnungen aus anderen Blogs. |
Skripte | Eine Liste von Objekten mit einem href Feld. Diese werden als Modultyp-Skripte zum Kopf des Beitrags hinzugefügt. |
Ich verwende Lenkervorlagen, um Inhalte in Seiten darzustellen. Einige davon enthalten Seiten, andere sind gemeinsame Bestandteile von Seiten. Sie sind ziemlich altmodisch, machen aber einen guten Job.
Der Service Worker und das Manifest sind Dateien, die es diesem Blog ermöglichen, sich wie eine PWA zu verhalten. Dies ermöglicht größtenteils benutzerdefiniertes Caching. Es ermöglicht auch die „Installation“ dieses Blogs auf Android (obwohl ich an dieser Funktionalität nicht wirklich interessiert bin).