Netz - Rettung - Recht

In den letzten drei Monaten des Jahres 2018 habe ich wieder ein wenig - sehr wenig! - Zeit gefunden, mich mit dem einen oder anderen Projekt rund um freie Software (FLOSS) oder das Netz zu beschäftigen. Dabei habe ich folgendes beigetragen:

Serendipity (s9y)

Das Blogsystem Serendipity werkelt auch hinter diesem Blog.

• Bei dem s9y-Plugin serendipity_event_markdown habe ich die damit ausgelieferten Bibliotheken Markdown und SmartyPants aktualisiert.
  Upgrade Markdown Lib and SmartyPants Lib.

Nanoc

U.a. meine Webseiten generiere ich mit Nanoc, einem Generator für statische Seiten.

• Die im blogging helper enthaltene Funktion atom_feed() zur Generierung, nun ja, eines Atom-Feeds habe ich um die Möglichkeit ergänzt, die Titel der automatisch erzeugten Einträge anzupassen, wie dies auch schon für den Inhalt bzw. das Exzerpt der einzelnen Einträge möglich war.
  Add title_proc parameter to blogging helper.

Zwei Beiträge in drei Monaten ist … nicht viel. Vielleicht finde ich 2019 wieder mehr Zeit.

Vorherige Aktivitäten-Übersicht: 09/2018

Die Verwaltung von Dateien in einem Versionskontrollsystem (VCS) wie git hat einen Nachteil: der Zeitstempel im Dateisystem gibt nicht mehr den Zeitpunkt der letzten Änderung an dieser Datei wieder, sondern den Zeitpunkt, zu dem sie zuletzt (ggf. mit vielen anderen Dateien) ausgecheckt wurde.

Für Webseiten bedeutet das, dass man für die Ausgabe des Datums der letzten Änderung nicht mehr auf den Zeitstempel der entsprechenden Datei zurückgreifen kann. Das macht mir nichts aus, denn zum einen verwende ich mittlerweile weitgehend statische Webseiten, bei denen das ohnehin nicht ohne weiteres möglich wäre, und zum anderen bringt dieser Ansatz zwar den Vorteil der Automatisierung mit sich, aber zugleich den - aus meiner Sicht überwiegenden - Nachteil, dass jeder verbesserte Tippfehler, jede unsichtbare Änderung am Seitengerüst als “Update” vermerkt wird, obwohl der Inhalt möglicherweise weiterhin völlig veraltet ist. Ich ziehe es daher vor, selbst zu entscheiden, was als “Änderung” gilt, und dann das Datum der letzten Änderung selbst zu setzen.

So weit, so gut - aber wie sieht das mit Downloaddateien aus?

Nanoc nutze ich schon mehr als drei Jahre zur Erzeugung verschiedener Websites; aber wie das so ist bei verschiedenen und zudem historisch gewachsenen Installationen, je mehr und je komplexer man ein Werkzeug einsetzt, desto größer ist der Angang bei notwendigen Änderungen. Und so habe ich das Upgrade auf Nanoc 4 - über dessen Beta ich damals bereits berichtete - dann auch gut zwei Jahre vor mir hergeschoben.

Nunmehr werden aber endlich alle meine Präsenzen mit Nanoc 4 erzeugt.

Mein Nanoc-Filter für die juristische Vernetzungsfunktion von dejure.org steht nun in der Version 1.2 zur Verfügung und ist damit - endlich - auch mit der aktuellen Nanoc-Version 4.x kompatibel.

Bereits vor gut zwei Jahren hatte ich berichtet, wie man nanoc mit einer (MySQL-)Datenbank als Datenquelle betreiben kann, und auf die entsprechende Dokumentation verwiesen. Schon damals hatte ich angemerkt, dass sich in dem dort gezeigten Weg möglicherweise ein Zwischenschritt einsparen lässt. Dies habe ich dann mittlerweile auch erfolgreich getestet.

Die Überschrift klingt etwas bombastischer, als der Inhalt es ist …

Seit etlichen Jahren nutze ich git zur Verwaltung sowohl meiner Software als auch für die von mir betreuten FAQs. Da lag es nahe, auch die Veröffentlichung neuer Fassungen derselben (“Releases”) nach Möglichkeit zu automatisieren. Für Software bedeutet das, die einzelnen Bestandteile in einen Tarball zu packen, vielleicht Readme-Dateien zu erstellen, usw.; für FAQs ist ggf. zur reinen Textfassung eine HTML-Fassung zu erstellen, was sich insbesondere anbietet, wenn die Textfassung bereits aus Markdown besteht.

Drei Wochen nach der ersten Fassung meines nanoc-Filters für die juristische Vernetzungsfunktion von dejure.org kann ich nun die Version 1.0 präsentieren.

Vergangene Woche schrieb ich über Aliase für Git - und heute möchte ich etwas ähnliches für nanoc vorstellen.

nanoc ermöglicht es nämlich, eigene Kommandos in Form von Ruby-Scripts zu definieren, die dann in commands/ gespeichert werden und - bspw. als commands/COMMAND.rb - mit nanoc COMMAND ausgeführt werden. Die Dokumentation hat unter der Überschrift “Writing commands” ein Beispiel dazu und verweist ansonsten auf die Dokumentation von Cri, dem dafür verwendeten Framework.

Ich stelle die von mir betriebenen Webseiten, die nicht auf interaktive Funktionen angewiesen sind, Stück für Stück auf statisch generierte Seiten um, zuletzt meine Homepage. Dabei setze ich auf einen Workflow, der nanoc als static site generator und git als Versionsverwaltungssystem umfasst und dafür sorgt, dass Änderungen der Seiten automatisch eingespielt werden.

Das - kostenlose - juristische Informationsportal dejure.org bietet nach eigenen Angaben 90% der am häufigsten zitierten deutschen (Bundes-)Gesetze, insgesamt rund 300 an der Zahl, und dazu vor allem eine umfassende Literaturdatenbank mit Urteilen, Anmerkungen und Querverweisen an. Ist ein Gesetz nicht verfügbar, wird der Nutzer auf den entsprechenden Eintrag in der umfassenden Sammlung des deutschen Bundesrechts bei buzer.de - einem weiteren kostenlosen juristischen Informationsdienst - weitergeleitet.

Unter anderem für den Relaunch meiner Homepage habe ich mich damit beschäftigt, wie ich das CSS-Framework Bootstrap am besten mit nanoc, meinem bevorzugten static site generator, zur Anwendung bringen kann.

Bereits mehrfach hatte ich über nanoc berichtet, dessen Entwicklung nunmehr wieder mit Elan fortschreitet.

Seit einigen Tagen gibt es die erste Beta-Version von nanoc 4.0 mit bereits teilweise angepasster Dokumentation - und obwohl dieses Release eigentlich keine neuen Features enthalten, sondern nur den Code für zukünftige Veränderungen vorbereiten soll, gibt es einige Neuigkeiten zu vermelden:

• In den Rules können nunmehr erweiterte Platzhalterzeichen (Globs) verwendet werden. Gab es bisher nur die Möglichkeit, * und + zu verwenden, bspw. in der Form /projects/*/, gibt es in nanoc 4.0 neue Möglichkeiten wie * contra ** oder Zeichensätze wie [abcdefg] oder auch Auswahllisten wie {foo,bar}. Vermutlich wird das der neue Default.

• Von manchem lange erwartet gibt es in der neuen Version zwei verschiedene Formate für Items, also einzelne Quelltextdateien: full format (neu) und stripped format.

Ein static site generator wie bspw. nanoc erzeugt, wie der Name schon sagt, im wesentlichen statische Seiten ohne - zumindest serverseitige - dynamische Elemente, oder schlicht: HTML-Dateien. Dennoch ist es möglich, solchen Webpräsenzen eine begrenze “Dynamik” zu verleihen, und dies nicht nur durch Einbindung von Drittanbieter-Diensten wie bspw. der Kommentar- und Diskussionsplattform Disqus - soll sich der Inhalt einer oder mehrerer Seiten ändern, müssen sie eben neu generiert werden.

Üblicherweise wird die Neugenerierung immer dann (manuell) veranlasst, wenn eine neue Seite oder ein neuer Beitrag (in einem statisch generierten Blog) verfasst oder ein bestehendes Quelldokument verändert worden ist. Jedoch kann eine Neugenerierung der Seiten auch angestoßen durch externe Ereignisse erfolgen. Man könnte bspw. immer dann, wenn ein neuer Beitrag eines bestimmten Accounts auf Twitter veröffentlicht wird, diesen Tweet in die Webseiten einbinden und dann die dadurch veränderten Seiten neu generieren - oder, bspw., einen RSS-Feed regelmäßig (täglich, stündlich, …) auslesen und bei einer Änderung die betreffenden Seiten der (eigentlich statischen) Webpräsenz neu generieren und auf diese Weise einen Newsticker einbinden, der allerdings nicht in Echtzeit “tickt”. Sehr häufig ist eine solche Echtzeit-Aktualisierung aber auch gar nicht nötig, weil sich Änderungen ohnehin nur in größeren Zeitabständen ergeben und es unschädlich ist, wenn sie mit einer gewissen Verzögerung angezeigt werden. So bindet bspw. der CCCS in seinen durch nanoc erzeugten Webseiten die Tweets des Accounts @cccs ebenso ein wie eine Übersicht der Blogbeiträge von Aktiven des Vereins. Die entsprechenden Daten werden in regelmäßigen Abständen ausgelesen, danach werden dann - wenn erforderlich - die betreffenden Webseiten neu erzeugt.

Die Dynamik lässt sich aber noch deutlich weiter treiben.

Nicht selten lassen sich die meisten Seiten einer Webpräsenz aus demselben Template erzeugen, wohingegen einige Ausnahmefälle einer Sonderbehandlung bedürfen - bspw. die Startseite oder landing page, die oft anders gestaltet ist als der Rest der Webseiten, und sei es nur, dass sie keine oder andere Navigations-Elemente aufweist oder mehrspaltig statt einspaltig (oder umgekehrt) dargestellt werden soll.

Mag es bei der Verwendung von nanoc für eine singuläre Ausnahme noch sinnvoll sein, sie explizit in die - bereits erläuterte - Rules-Datei aufzunehmen, gibt es für diese Aufgabenstellung eine sehr einfache Lösung: ein abweichendes Template kann nämlich im YAML-Metadatenblock jeder Seite angegeben werden.

Sollen nun die Webseiten einer Präsenz normalerweise das Template namens default verwenden, die Startseite aber das Template startpage, so erhält die Quellcode-Datei der Startseite einen entsprechenden Eintrag in ihre YAML-Metadaten, bspw. template: startpage, und die Rules-Datei erhält dann im compile-Block an der passenden Stelle - statt layout 'default' - die Anweisung layout item[:template] || 'default'.

Man kann auch - wie es der CCCS tut - die Variante “gar kein Template” direkt mit aufnehmen:

if item[:template]!='none'
  layout item[:template] || 'default'
end

Ich nutze mittlerweile für eine ganze Reihe (meist eher einfacher) Webpräsenzen den static site generator nanoc. nanoc, geschrieben in Ruby, erzeugt anhand vorgegebener Regeln aus einer Verzeichnisstruktur mit Quellcode-Dateien in verschiedenen denkbaren Formaten und Seiten-Templates unter Anwendung von Filtern und ggf. ergänzenden (in Ruby geschriebenen) Modulen eine (grundsätzlich) statische, d.h. aus einzelnen HTML-Dateien bestehende, Website. Man kann sich das beispielsweise an den Webseiten des CCCS ansehen.