Vor etwas mehr als 10 Jahren habe ich meine Webseite von Wordpress auf Jekyll umgestellt. Während dieser Zeit hatte ich fast gar keine Arbeit mit der Webseite — wo nix ist, kann auch nix kaputt gehen. Ich habe mir keine Gedanken um Sicherheitsupdates gemacht, und alles in allem war Jekyll eine schicke Geschichte. Bis auf ein Detail…
Die Schwächen von Jekyll
Als einer der ersten Generatoren von statischen Webseiten ist Jekyll natürlich in den letzten 10 Jahren technisch ziemlich gereift. Dinge wie eine Tag-Cloud waren am Anfang noch Handarbeit, über die Jahre sind diese Funktionen aber dazu gekommen. Mein Problem dabei: Ich hatte diese Features schon händisch implementiert. Und wie es nun einmal so ist: Was man selbst entwickelt muss man auch selber pflegen und warten.
Meine Jekyll-Installation funktionierte daher nur mit einem uralten Ruby-Interpreter. Die richtige Kombination aus Gems (Ruby-Bibliotheken) musste es sein, ansonsten war Jekyll einfach nicht glücklich. Alles machbar, aber nach vielleicht sechs Jahren hat man der Lösung einfach angemerkt, das sie in die Jahre kommt. Da war mein Handlungsdruck allerdings einfach noch nicht groß genug, und so hats weitere fünf Jahre gedauert, bis ich nun meine Webseite mit Hugo erzeuge. Wenn das damals mal nicht ein gutes Investment war weiß ich auch nicht, mit Wordpress wäre ich vermutlich wahnsinnig geworden…
Hugo
Technisch erfüllt Hugo die gleiche Funktion wie zuvor Jekyll: Es verwandelt einen Stapel Layoutvorlagen und Markdown-Dateien in diese Webseite. Wirklich viel hat sich dabei nicht geändert — sogar die Markdown-Dateien, die ich für Jekyll geschrieben hatte, funktionieren einfach weiter.
Hugo ist mir mittlererweile durch die Arbeit an ladefragen.de ans Herz gewachsen. Statt Ruby werkelt nun Go im Hintergrund. Hugo kommt als einfaches Binary ohne jegliche Abhängigkeiten. Ich muss also nicht mehr eine separate, uralte Ruby-Runtime vorhalten, um meine Webseite aktualisieren zu können. Die Features sind alle etwas moderner, das Templating ist mächtiger geworden. Und da ich für ladefragen.de sowieso schon ein Makefile und diverse Werkzeuge geschrieben habe kann ich diese einfach auch hier benutzen.
Ebenso habe ich das Layout von ladefragen.de
einfach weitergenutzt. Nicht, weil es besonders hübsch ist – aber es
ist funktional und gut lesbar, das reicht. Neu hinzugekommen im
Vergleich zur Jekyll-Variante ist das Optimieren aller Bilder, damit
diese möglichst kompakt sind. Das passiert automatisch während einem
make deploy, und ausserdem wird auch der HTML-Code mit allem drum
und dran kompaktiert.
Optimaler Aufwand
Das Paretoprinzip, benannt nach Vilfredo Pareto (1848–1923), auch Pareto-Effekt oder 80-zu-20-Regel genannt, besagt, dass 80 % der Ergebnisse mit 20 % des Gesamtaufwandes erreicht werden. Die verbleibenden 20 % der Ergebnisse erfordern mit 80 % des Gesamtaufwandes die quantitativ meiste Arbeit.
Beim Umzug hab ich mich am Paretoprinzip orientiert und die Startseite einfach neu entworfen. Der Umzug der Markdown-Dateien war dank eines in Hugo eingebauten Konverters ziemlich unspektakulär. Und damit die alten Links erhalten bleiben habe ich einfach im Front Matter der einzelnen Beiträge die alte URL als Alias hinterlegt:
---
aliases:
- /blog/2017/10/26/schwarzladen/
---
Das sorgt dafür, das für diese URL eine leere Seite mit einem Redirect auf die aktuelle URL angelegt wird. Es gehen also keine Links kaputt.
Noch sind nicht alle Dinge genau so, wie ich sie gerne hätte. Aber: Die Webseite funktioniert, die Links sind immer noch die gleichen und ich habe wieder Ruhe. Und ich bin guter Dinge, das ich erst in 10 Jahren wieder die Technik hinter der Webseite anpacken muss.