Philipp Trommlers Blog

Mein neuer Blog

Endlich habe ich meinen neuen Blog zum Laufen gebracht. Es ist schon eine ganze Weile her, seit ich meinen letzten Beitrag geschrieben habe und ich habe die Gelegenheit genutzt, einige neue Ideen zu entwickeln, sowohl in technischer wie auch in inhaltlicher Hinsicht.

Veröffentlicht am Freitag, 09. August 2019 (zuletzt geändert am Sonntag, 11. August 2019) von Philipp Trommler. Dieser Beitrag wurde außerdem übersetzt nach: en.

Update 11.08.2019: Rechtschreibung korrigiert und Inhaltsverzeichnis hinzugefügt.

Ich habe meinen letzten Artikel in 2016 geschrieben, einen Test meines - damals - neuen Smartphones. Ich nutze es noch immer, obwohl sich mein Urteil über das Gerät doch sehr geändert hat. Aber das ist es nicht, worum es hier gehen soll, ich möchte mich lieber darauf fokussieren, worüber ich in Zukunft schreiben will, wie und warum.

Gründe neu anzufangen¶

Mein alter Blog hatte ein klares Ziel: an Anfänger gerichtete Beiträge über Vala und Gtk-Entwicklung auf Deutsch. 'Warum auf Deutsch?', könnte man fragen. Weil die Sprache ein großes Hindernis beim Erlernen neuer Dinge darstellen kann, insbesondere für Anfänger. Sich gleichzeitig auf das eigentliche Thema und die Fremdsprache konzentrieren zu müssen, kann sogar für relativ sichere Sprecher schwierig sein. Und da es bereits genug Blogs auf Englisch gab, dachte ich mir, ich könne Deutschsprachigen wie mir einen Gefallen tun und die Informationen in unserer Muttersprache aufbereiten.

Ich war schon immer an Embedded- und Low-Level-Entwicklung interessiert, aber ich habe mich nie ausreichend sicher gefühlt, auch darüber zu schreiben. Aber da ich beides seit nunmehr fast drei Jahren täglich beruflich mache, haben sich meine Gefühle dahingehend geändert. Natürlich bin ich noch lange kein "alter Hase", aber ich denke, dass ich ein Level erreicht habe, auf dem es sich lohnt, mein Wissen zu teilen. Von daher gibt es hier vorerst keine Informationen zu Vala oder Gtk-Entwicklung mehr (zumindest nicht in der Hauptsache).

Mit der inhaltlichen Verschiebung kommt auch eine Änderung der Sprache. Erstens, weil das neue Thema eine noch kleinere Nische besetzt als das alte und ein exklusiv deutscher Blog nur eine sehr kleine Leserschaft ansprechen würde. Zweitens, weil die Anzahl der internationalen (englischsprachigen) Blogs, die sich mit dem neuen Thema beschäftigen, deutlich geringer ist und dadurch mehr Raum für einen weiteren bleibt. Dennoch will ich auch weiterhin deutsche Übersetzungen meiner Beiträge bereitstellen, da die Gründe für die ursprüngliche Wahl von Deutsch als Veröffentlichungssprache immer noch valide sind.

All diese Änderungen sollen nicht den Eindruck erwecken, dass mir meine alten Beträge in irgendeiner Form peinlich wären. Du kannst meinen alten Blog noch immer unter seiner ursprünglichen Adresse erreichen. Da ich jedoch plane, die dort verwendete Subdomain wiederzuverwenden, habe ich die Wayback Machine darum gebeten, eine Kopie meiner Seite anzulegen. Glücklicherweise ist sie dieser Bitte nachgekommen. Du kannst meine deutschen Beiträge über Vala und Gtk also auch dann noch lesen, wenn ich dem alten Blog den Stecker ziehe.

Eine neue technische Grundlage¶

Eine inhaltliche Neuausrichtung nach einer langen Pause offeriert die Möglichkeit, die technische Grundlage eines Blogs anzupassen. Ich habe diese Chance wahrgenommen und die letzten zwei Wochen damit verbracht, meine persönliche Pelican-Seite zu erstellen.

Pelican vs. Jekyll¶

Meinen alten Blog habe ich mit Jekyll erstellt, so wie es viele andere auch tun. Es hat damals alle meine Anforderungen erfüllt und würde das wahrscheinlich heute auch noch tun, aber ich habe mich nie wirklich wohl bei seiner Benutzung gefühlt, eher beschränkt, besonders weil ich den Blog bei Github gehostet habe (zum Beispiel konnte man zu dieser Zeit keine eigenen Themes verwenden, wenn man die automatische Seitenerstellung genutzt hat). Ich bin ziemlich sicher, dass alles, das mir Jekyll verleidet hat, nicht dem Generator selbst sondern den Umständen geschuldet war (ich habe meine Seite schlussendlich lokal erstellt und dann das Generat bei Github eingecheckt 🤢...). Trotzdem wollte ich etwas Neues.

Auf der Suche nach diesem "Neuen" bin ich auf Pelican gestoßen. Markdown? Ja! In einer normalen Sprache geschrieben (Hugo *hüstel*)? Oh ja! Die Liste der Plugins? Lang! Und, am wichtigsten (aus oben genannten Gründen): Ein i18n Plugin! Ich begann sofort, ein minimalistisches und dennoch technisch modernes Template zu erstellen.

Das Ergebnis siehst du jetzt hier vor dir. Ich muss jedoch gestehen, dass ich etwas enttäuscht bin. Das Pelican-Ökosystem konnte seine Versprechen nicht halten. Pelican selbst ist zwar durchdacht, einfach zu benutzen und ausreichend schnell, pelican-quickstart ist großartig und die grundlegende Generatorfunktion arbeitet korrekt, aber sobald Pelicans Plugins und ein etwas komplexeres Setup ins Spiel kommen (wobei ich mein Setup eigentlich noch nicht als komplex bezeichnen würde), geht es steil bergab.

Hier ist eine (unvollständige) List der Dinge, die (noch) nicht (richtig/wie erwartet) funktionieren:

• Der Blog enthält bisher keine schema.org Mikrodaten. Es gibt zwar ein pelican-microdata Plugin, dieses wird jedoch seit 2017 nicht mehr weiterentwickelt, unterstützt nur RST-Dateien und hat natürlich keine Unterstützung für JSON-LD. Nun, Philipp, zurück zum Jinja2-Templates Schreiben!
• Die Erstellung und Verlinkung der RSS- und Atom-Feeds ist noch nicht an dem Punkt, an dem ich sie gern hätte. Das ist auch der Grund, warum es noch keine sichtbaren Links zu den Feeds gibt (sie sind jedoch im Code enthalten, dein Reader sollte sie finden).
• Ich kann derzeit das better_code_samples Plugin nicht nutzen, da es meine HTML-Struktur zerstört (es fügt überflüssige </body></html><body>-Tags ein). Entschuldigt, mobile Nutzer, Code-Beispiele sprengen bis auf Weiteres den Seitenrahmen für euch.
• Das image_process Plugin setzt mein HTML neu (keine/falsche Einrückung, Tag-Attribute in einer anderen Reihenfolge).
• Ich muss Inline-HTML in meinen Markdown-Dateien schreiben, wenn ich für meine Bilder mehr will als <p><img ...></p> (zum Beispiel <figure> und <figcaption>; Hallo, Semantik!).
• filetime_from_git generiert (zumindest lokal) Timestamps, die nicht W3C-konform sind (sie haben mehr als zwei Stellen im Subsekundenbereich).
• Das sitemap Plugin beachtet die i18n-Unterseiten nicht.
• Die Autoren-/Kategorien-/Tags-Seiten sind rudimentär, aber ich verstehe die Dokumentation des autopages Plugins nicht 🤷‍♂️...
• Das i18n Plugin funktioniert zwar an und für sich recht gut, es generiert jedoch eine Unterseite für die Hauptsprache. Das begreife ich nicht. Mal sehen, was die Suchmaschinen dazu sagen.
• Ich würde gern "Übersetzer"-Seiten analog zu den "Autor"-Seiten erstellen. Ich weiß aber nicht wie oder ob das überhaupt möglich ist, ohne Pelican zu patchen.
• Ich habe noch kein Favicon. Hat man so etwas noch? Welche Icon-Größen braucht man eigentlich für die "Neuer Tab"-Seite von Firefox?

Ehrlich gesagt bin ich ein bisschen überrascht vom Zustand des Pelican-Ökosystems, aber zugegebenermaßen erinnert er mich an meine Erfahrungen mit Jekyll und an das, was ich über andere SSGs gelesen habe: Kernfunktionen werden in Plugins ausgelagert, die ihrerseits nur mäßig gewartet werden (wenn überhaupt). Meine Probleme mögen zwar teilweise der uralten Version von Pelican, die ich verwende, geschuldet sein (3.7.1, aber bitte verurteile mich nicht, ich bin zur Zeit wegen Hardwareproblemen an Ubuntu LTS unter WSL gebunden 😩), aber das erklärt nicht die Probleme, die ich mit den Plugins hatte.

Sourcehut vs. Github¶

Um wirklich von vorne anzufangen, habe ich nicht nur das Thema und den Generator gewechselt, sondern auch meinen Git-Hoster. Ich war schon länger unglücklich mit Github, weil es ein böses Großunternehmen im Besitz von Microsoft ist. Zum Glück hat Drew DeVault vor kurzem mal wieder gezaubert und Sourcehut veröffentlicht. Dabei handelt es sich um eine ernstzunehmende, JavaScript-freie und e-Mail-basierte Alternative zu Github und es ist großartig. Ich hoste dort einerseits meine Pelican-Dateien und nutze andererseits den eingebauten Build-Service, um meine HTML-Dateien zu erstellen.

Das eigentliche Hosten des Blogs übernimmt Namecheap. Dafür gibt es keinen besonderen Grund, außer dass ich dort sowieso Kunde bin, da ich dort meine Domains hoste. Die Kombination von Sourcehut und Namecheap ergeben ein geteiltes Setup, das etwas widerstandsfähiger sein sollte, als alles unter einem Dach zu haben.

Fazit¶

Trotz meiner starken Gefühle gegenüber Pelican muss ich zugeben, dass ich mit meinem neuen Setup recht zufrieden bin. Das kommt vor allem durch die Automatisierung, die ich erreicht habe, aber auch das nutzererlebbare Ergebnis gefällt mir. Außerdem denke ich, dass sogar Pelican seinen Job erfüllen wird, wenn es erst einmal fertig konfiguriert ist. Ich hoffe, dass insbesondere die Automatisierung meine Blogging-Ambitionen aufrechterhalten wird.

Der Blog-Titel geht gar nicht!¶

Zugegeben, er ist nicht gerade erfinderisch. Aber da es in diesem Blog um mich geht, meine Interessen und die Dinge, die ich tue, und da ich hier außerdem nichts verkaufen will, ist der Name ziemlich auf den Punkt gebracht 🙄.

Wie geht es weiter?¶

Ich habe mir bereits einige Themen für die nächsten Beiträge zurechtgelegt, so möchte ich eine mehrteilige Einführung in ein noch recht unbekanntes Meta-Build-Tool namens "Bob" geben, meine Gedanken zum inzwischen vollständigen C++20-Standard äußern und ich habe außerdem Ideen für zwei oder drei wiederkehrende Kategorien. Hoffentlich bleibe ich diesmal lange genug am Ball, um zumindest diese Themen abarbeiten zu können. Ich lade dich ein, es mit mir gemeinsam herauszufinden!

Abgelegt unter Meta. Tags: namecheap, pelican, pelican-plugins, publishing, sourcehut.

Willst du diesen Beitrag kommentieren? Schreib mir an blog [at] philipp-trommler [dot] me!