Netz - Rettung - Recht (Artikel mit Tag ruby)

t - Twittern auf der Kommandozeile

nospam@example.com (Thomas Hochstein) — Wed, 09 Jan 2019 08:50:00 +0000

Clients für Twitter gibt es viele, und logischerweise sind diese in der Regel GUI-Applikationen, also Programme mit einer grafischen Benutzeroberfläche. Gerade dann, wenn man Zugriffe auf Twitter automatisieren will, kann aber ein Kommandozeilenprogramm sehr praktisch sein. t (Twitter CLI) ist ein solcher Twitter-Client für die Kommandozeile, oder, mit den Worten des Entwicklers A command-line power tool for Twitter.

Installation

Für die Installation benötigt man zunächst einmal Ruby, denn das ist die Sprache, in der t geschrieben ist. Unter Debian sollte apt install ruby ruby-dev rubygems weiterhelfen.

Die eigentliche Installation erfolgt dann über den Ruby-Paketmanager vermittels gem install t; notwendige Dependencies (Abhängigkeiten) werden mitinstalliert.

Bedauerlicherweise wird der Start des Tools (seit 2017!) die Fehlermeldung uninitialized constant Twitter::REST nach sich ziehen. Das ist als Issue 878 seit langem berichtet, aber wohl noch nicht behoben. Dabei ist die Lösung - oder jedenfalls ein Workaround - einfach: es muss nur in der Datei lib/t/cli.rb innerhalb des Gem-Verzeichnisses (dessen Pfad u.a. von der Ruby-Version und der Version von t abhängt) die Einbindung einer Konstante angepasst werden …

Konfiguration / Anmeldung

Die Konfiguration ist hingegen aufwendiger geworden, weil dazu eine Applikation bei Twitter registriert werden muss, und die Hürden dafür hat Twitter erhöht.

Als erstes wird ein Developer Account benötigt, der an einen bestehenden Twitter-Account gekoppelt ist.

Ein solcher Account wird online beantragt und setzt eine Anmeldung bei Twitter mit einem Account voraus, für den eine gültige Mailadresse und eine gültige Mobiltelefonnummer hinterlegt sind (!).
Man muss sich entscheiden, ob man den Zugang für sich selbst oder seine Organisation benötigt. Außerdem ist ein Name für den Entwickler-Account zu vergeben und das Land auszuwählen, von dem aus man in erster Linie tätig ist.

Einrichtung eines Developer-Accounts.

Danach wird abgefragt, in welchen Bereichen man tätig sein will. Zudem muss man sein Projekt anhand von Leitfragen in Freitext beschreiben und sich dazu äußern, ob das Projekt Daten von Twittern für die öffentliche Verwaltung zugänglich macht.
Nach Bestätigung der Benutzungsbedingungen wird der Antrag geprüft und in der Regel zeitnah positiv beschieden.

Danach kann man in seinem brandneuen Developer Account eine Applikation registrieren.

Das geschieht über in der App-Übersicht über den Button “Create an app”.
Auch hier ist wieder ein Name für die App zu vergeben, der dann auch - in Clients, die das noch tun - als Name des Clients angezeigt wird, mit dem gepostetet wurde. Auch eine Beschreibung der App muss sein, die URL einer Webseite für die App, viele andere Einstellungen - und verpflichtend ist am Ende erneut eine Beschreibung der Verwendungszwecke dieser konkreten App, auf deren Basis Twitter die App dann freigibt.

Anmeldung einer App.

Ist das geschehen, sollte man sich die Details der App noch einmal ansehen; sie benötigt jedenfalls die Rechte “Read” und “Write”.

Dieser App muss man nunmehr noch den Zugriff auf das eigene Twitter-Konto erlauben.

Mit t authorize wird der Anmeldeprozess gestartet.
Es wird eine URL angezeigt, die man aufrufen muss, um sich dort dann bei Twitter anzumelden - mit dem Account, auf den t dann später zugreifen soll.
Nunmehr erhält man eine PIN, die auf der Shell (wo t authorize läuft) eingegeben muss.

Fertig!

Die Anmeldung bei weiteren Accounts kann dann in gleicher Weise erfolgen - man muss sich nur sinnvollerweise zwischendurch bei Twitter aus- und mit dem richtigen Account wieder einloggen.

Verwendung

t bietet vielfältige Möglichkeiten. Zwei einfache Beispiele:

t accounts zeigt an, auf welche Accounts man Zugriff hat, und erlaubt die Auswahl des aktiven Accounts, auf den die folgenden Befehle angewendet werden.
t update TEXT twittert “TEXT”.

So lassen sich bspw. Statusmeldungen automatisch twittern, Termine ankündigen u.v.m.

Viel Spaß!

Zeitstempel von Dateien unter Versionsverwaltung

nospam@example.com (Thomas Hochstein) — Mon, 15 Jan 2018 06:15:00 +0000

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?

Zeitstempel von Downloadangeboten passend setzen

Jedenfalls dann, wenn man Downloadangebote nicht nur verlinkt, sondern den Downloadbereich auch als Dateiübersicht zugänglich macht - wie ich es auf meinen Webseiten tue -, ist es für den Nutzer gelinde gesagt verwirrend, wenn der angezeigte Zeitstempel der Dateien nichts mit der letzten Änderung derselben zu tun hat.

Dafür gibt es natürlich verschiedene einfache Lösungen: Zum einen könnte ich darauf verzichten, einen Downloadbereich in diesem Sinne anzuzeigen, und die Dateien einfach nur verlinken. Tatsächlich sind die meisten Downloadangebote irgendwo auf meinen Seiten verlinkt, und ich speichere für sie auch Metadaten wie bspw. das Datum der letzten Änderung, das bei dem Link angezeigt wird, wie bspw. bei meinen Downloads aus dem Bereich des Rettungswesens. Ich schätze es aber gerade, dass man in den Downloadangeboten auch “einfach so” stöbern kann. - Zum anderen könnte ich darauf verzichten, Downloads unter Versionskontrolle zu stellen, und sie in einem gesonderten Archiv speichern. Gerade für Software-Releases - und auch meine FAQs - wäre das vernünftig; beide werden ohnehin in gesonderten git-Repositories versioniert, so dass es nicht erforderlich ist, einzelne Releases nochmal im Repository meiner Webseiten zu speichern. Andererseits gibt es aber Downloads, die nicht selbst unter Versionskontrolle stehen, und - mir viel wichtiger - eine getrennte Speicherung der Downloadangebote würde bedeuten, dass ich meine Webseiten nicht “aus einem Guss” aus dem git-Repository erzeugen bzw. wiederherstellen kann; ich müsste dann den Downloadbereich getrennt sichern und einspielen.

Trotz allem denke ich regelmäßig darüber nach, die Downloadangebote aus der Versionskontrolle herauszunehmen (das ist ja ein wenig auch eine Frage der Größe des Repositories). Bis dahin wollte ich aber eine andere Lösung für das Problem der “falschen” Zeitstempel im Directory-Listing - und eigentlich kann das so schwierig ja nicht sein: immerhin habe ich Metadaten, aus denen sich für jede einzelne Datei im Downloadbereich das Datum der letzten (inhaltlichen) Änderung ergibt. Wie schwer kann es sein, den Zeitstempel - also das Datum der letzten Änderung der Datei im Dateisystem, die sog. modification time oder kurz mtime - passend zu setzen?

Wie sich herausstellt: nicht sehr schwer. Es genügt, ein paar Zeilen als postprocess-Block in der Nanoc-Konfiguration hinzuzufügen:

postprocess do
# iterate over all items starting with /archives/ or /net/usenet/faqs/ with kind “file” or “faq” that have “updated_at” set
items.select { |item| %r<^/(archives|net/usenet/faqs)/> =~ item.identifier && [ ‘file’, ‘faq’ ].include?(item[:kind]) && !item[:updated_at].nil? }.each do |item|
# prefer the “text” representation, if available (for FAQs)
unless item.reps[:text].nil?
path = item.path(rep: :text)
else
path = item.path
end
# use the output files, not the source
path = @config[:output_dir] + path
# change the mtime to “updated_at”
# “updated_at” is part Date (when set to 2017-10-01), part String (when set to ‘2017-10-01’),
# so it has to be converted to strings and parsed (instead of using .to_time)
FileUtils.touch path, :mtime => Time.parse(item[:updated_at].to_s)
end
end

Gut, die Zeitstempel sind jetzt immer noch auffällig, weil ich natürlich nur das Datum der letzten Änderung mitführe, nicht die Uhrzeit, und die Dateien daher scheinbar alle um Mitternacht erzeugt werden, aber damit lässt sich leben. Einziger Nachteil: Die unerwartet “alten” Dateien im Downloadbereich bringen das Dependency-Tracking von Nanoc durcheinander und werden daher bei jedem Durchlauf neu erzeugt, weil die Ausgabedateien (mit einem Zeitstempel von vor einigen Monaten oder Jahren) scheinbar älter sind als die Quelldateien (die frisch aus der Versionskontrolle ausgecheckt wurden und daher einen aktuellen Zeitstempel haben), aber damit lässt sich leben.

Symlinks erzeugen

Außerdem konnte ich so ein weiteres Problem lösen:

Die Downloads meiner Scripts (und anderer Software) tragen die Versionsnummer im Dateinamen, bspw. checkmail-0-6-1.tar.gz für die Version 0.6.1 von checkmail. Ich möchte aber zugleich immer die aktuellste Version unter dem generischen Namen checkmail.tar.gz anbieten. Nichts einfacher als das: checkmail.tar.gz muss ein Symlink auf den jeweils neuesten “versionierten” Dateinamen sein. Das lässt sich so auch in das gir-Repository einchecken … nur bearbeite ich meine Webseiten unter Windows - und da ist das Konzept von symbolic links eher nicht so bekannt. Dieses Problem hatte ich vorübergehend “gelöst”, indem ich einfach zwei identische Dateien gespeichert habe - aber das ist natürlich ein nerviger Hack, der doppelt Platz braucht und einfach nicht elegant ist.

Nachdem ich jetzt ohnehin die Dateien im Downloadbereich nach ihrer Generierung nachbehandle, lassen sich dabei auch direkt die Symlinks erzeugen - zwar immer noch aus einer Platzhalterdatei, aber dafür genügt dann eine leere Datei, die nur den passenden Namen trägt. Mein Ansatz dafür ist folgender (eingefügt in den oben bereits gezeigten Block):

postprocess do
[…]
# use the output files, not the source
path = @config[:output_dir] + path
# generate symlinks
if item[:kind] == ‘file’ && item[:current]
# remove placeholder and symlink generic name (‘myprog.tar.gz’)
# to current file (‘myprog-1-2-17.tar.gz’)
FileUtils.rm path
FileUtils.ln_s item[:current], path
# mtime shall be changed for the current file
path = File.dirname(path) + ‘/’ + item[:current]
end
# change the mtime to “updated_at”
[…]
end

Insgesamt fühlt sich das immer noch wie ein Hack an, aber immerhin nicht mehr ganz so krude.

nanoc-dejure 1.2 released

nospam@example.com (Thomas Hochstein) — Mon, 21 Aug 2017 09:00:00 +0000

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.

Dazu gehören folgende Neuerungen:

Die automatische Verlinkung kann für Überschriften (die HTML-Elemente <h1> bis <hx>) deaktiviert werden¹.
Verlinkungen erfolgen mit HTTPS als Protokoll².
Kompatibilität mit Nanoc 4.

Beides ist implementiert, scheint aber bei Tests noch nicht richtig zu funktionieren. Ich hoffe, dafür noch eine Lösung finden zu können, bin bislang aber ratlos, nachdem im Wesentlichen dieselbe Implementation für das Serendipity-Plugin, das auch hier im Blog läuft, probemlos funktioniert. ↩︎
Siehe Fußnote 1. ↩︎

git-commit-notifier

nospam@example.com (Thomas Hochstein) — Fri, 18 Aug 2017 06:05:00 +0000

Es gibt zwar nicht sehr viele “eigene” git-Repositories, an denen außer mir noch andere mitentwickeln, aber einige doch schon, zumindest potentiell; und ungeachtet dessen bereitet es mir auch als bloße Spielerei Freude, wenn ich zumindest die Möglichkeit anbieten kann, per Mail über neue Commits zu informieren.

Bisher habe ich das mit dem “eingebauten” - quasi im Lieferumfang befindlichen - Script post-receive-email gelöst, das allerdings optisch altbacken daherkommt und v.a. kein Diff mitliefert. Oft habe ich nach Alternativen geschaut und bin dabei immer wieder über git-commit-notifier gestolpert, das aber irgendwie[tm] bei mir nicht recht laufen wollte. Der - schon mehrmals erwähnte - Serverumzug, den auch meine öffentlichen git-Repositories mitgemacht haben, bot nun die Gelegenheit für einen neuen Anlauf - und was soll ich sagen? Es funktioniert!

Wenn Ruby vorhanden ist (apt install ruby rubygems), genügt ein gem install git-commit-notifier, und dann bedarf es nur noch eines Hooks (post-receive im hooks-Verzeichnis, ausführbar!) mit dem folgenden Inhalt:

#!/bin/sh
git-commit-notifier /path/to/git-notifier-config.yaml

… und einer Konfiguration in /path/to/git-notifier-config.yaml nach dem vorhandenen Muster, und schon gibt es schön bunte Benachrichtigungen, deren Adressaten und Inhalt sehr weitgehend konfigurierbar sind.

Screenshot einer durch git commit notifier generierten Benachrichtigung.

Externe Datenquellen für nanoc

nospam@example.com (Thomas Hochstein) — Mon, 24 Jul 2017 05:30:00 +0000

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.

Das Beispiel aus der nanoc-Dokumentation

Das in der nanoc-Dokumentation gezeigte Beispiel generiert aus jedem Datensatz in der Datenbank ein Item (also im Prinzip ein Dokument), das keinen Inhalt hat, aber die einzelnen Datenbankfelder als Attribute enthält, und erzeugt diese “leeren” Seiten unter /external/hr/employees/. Das ergibt sich aus dem Zusammenwirken des Prefixes items_root: /external/hr in der nanoc.yaml einerseits und der Funktion zum Erzeugen von Items in der Definition der Datenquelle andererseits:

def items
@db[:employees].map do |employee|
new_item(
”,
employee,
“/employees/#{employee[:id]}”
)
end
end

Für jeden Datensatz wird ein Item /employees/ID/ (also für den Datensatz mit dem Feld id: 1 ein Item /employees/1/) erzeugt, dem der Pfad /external/hr vorangestellt wird (also im Beispiel /external/hr/employees/1/).

Alle diese Seiten dort sind leer, weshalb ihre Erzeugung im Beispiel auch unterdrückt wird. Von ihnen werden nur die Attribute (“Metadaten”) benötigt, um ein Verzeichnis mit allen Mitarbeitern zu erstellen.

Meine Anwendung für d-e-n.net

Diese Lösung hatte ich für die “Schreiberliste von de.etc.notfallrettung” übernommen.

Da ich dort aber nicht nur eine Liste der Nutzer, sondern für jeden auch eine Profilseite benötige, war ich zweischrittig vorgegangen: in einem ersten Schritt wurden - wie im Beispiel - die Daten eingelesen und leere Seiten (unter /_external/db/users/ID) erzeugt und in einem zweiten Schritt aus den Attributen dieser leeren Seiten entsprechende Profilseiten erstellt, indem im preprocess-Block der Rules eine entsprechende Funktion aufgerufen wurde.

Schon damals fand ich das recht ineffizient: einmal “leere” Seiten nur mit Attributen erstellen, deren Ausgabe unterdrücken und dann für jedes dieser “virtuellen” Items noch einmal eine Seite erzeugen, die dann ausgegeben wird? Warum nicht den ersten Schritt entfallen lassen und direkt die Profilseiten erstellen?

Gesagt, (zwei Jahre später) getan: es genügt, new_item() statt des “leeren” Inhalts den passenden Seiteninhalt zu übergeben (und ggf. die notwendigen Zusatzattribute hinzuzufügen):

def items
@db[:employees].map do |employee|
new_item(
“= render ‘profile’”,
{:updated_at => employee[:changedate], :title => employee[:name],
:description => “Profile of #{employee[:name]}”}.merge(employee),
“/employees/#{employee[:id]}”
)
end
end

Dann musste nur noch - neben einigen Anpassungsarbeiten im Code - in der nanoc.yaml entsprechend items_root: auf / gesetzt werden, damit die Daten auch unter /user/ID aufscheinen, und schon war der unnötige Zwischenschritt entfallen.

Der konkrete Code

Die Datenquelle wird dabei bei mir wie folgt in der nanoc.yaml eingebunden:

data_sources:
-
# The type is the identifier of the data source. By default, this will be
# <code>filesystem_unified</code>.
type: filesystem_unified
[…]
-
# Add mysql database (lib/data_sources/user_db)
type: userdb
items_root: /

Definiert wird die Datenquelle dann in lib/data_sources/user_db.rb:

# taken from http://nanoc.ws/docs/guides/using-external-sources/
require ‘sequel’
class UserDataSource < ::Nanoc::DataSource
identifier :userdb
def up
@db = Sequel.mysql2(:host=>’HOSTNAME’, :user=>’USER’, :password=>’PASS’, :database=>’DATABASE’)
end
def items
@db[:users].map do |user|
fullname = [user[:vorname],user[:name]].join ’ ’
# create profile page
Nanoc::Item.new(
“= render ‘profile’”,
{:author => fullname, :created_at => ‘2002-11-14’,
:updated_at => user[:changedate], :title => “Profil von #{fullname}”,
:short => “#{fullname}”, :template => ‘page-container’,
:description => “Profil des Autors #{fullname} in der Newsgroup de.etc.notfallrettung”}.merge(user),
“/user/#{user[:id]}/”
)
end
end
end

Ich arbeite derzeit noch mit dem alten nanoc 3.x, weshalb dort statt new_item() noch Nanoc::Item.new() verwendet wird.

Mit der dargestellten Funktion in der Definition der Datenquelle wird für jeden Datensatz eine Seite (ein Item) erzeugt, die (das) als einzigen Inhalt = render 'profile' enthält. Da in den Rules angegeben ist, dass die Seiten unterhalb von /user/ einen HAML-Filter durchlaufen, wird mithin der Inhalt der Datei profile im Verzeichnis /layouts/ eingefügt - das Template für alle Profilseiten. Mit dem ERB-Filter wäre entsprechend <%= render 'profile' %> einzufügen. Die erzeugte Seite bzw. das erzeugte Item erhält überdies alle Felder aus dem Datensatz als Attribute übergeben, verbunden mit weiteren, zusätzlichen Attributen wie :author oder :title. Am Schluss bekommt die Seite / das Item einen Identifier unter Nutzung des Datensatzfeldes id, für id: 1 also dementsprechend /user/1/.

Fertig!

nanoc-dejure 1.0 released

nospam@example.com (Thomas Hochstein) — Fri, 26 May 2017 05:10:00 +0000

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.

Neben einem Changelog und einer (englischsprachigen) Readme-Datei gibt es folgende Neuerungen:

Das Cache-Verzeichnis wird jetzt auch dann korrekt erzeugt, wenn das übergeordnete tmp-Verzeichnis noch fehlt.
Die Gültigkeitsdauer des Caches beträgt künftig standardmäßig sieben (und nicht nur vier) Tage. Sie ist außerdem konfigurierbar.
Dokumente ohne irgendwelche hinzuzufügenden Links werden platzsparender gecached.
Der Aufruf der API erfolgt nunmehr über HTTPS.
Einzelne Dokumente können durch Hinzufügen des Textes  irgendwo auf der Seite von der Bearbeitung durch den Filter ausgenommen werden.

nanoc commands

nospam@example.com (Thomas Hochstein) — Mon, 22 May 2017 04:05:00 +0000

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.

Die Anwendungsmöglichkeiten dafür sind vielfältig:

Der CCCS hat ein Script, mit dem sich aus einem Template Flyer für die Ankündigung von Vorträgen erzeugen lassen.
Teilweise gebe ich RSS-Feeds als Bestandteil meiner Webseiten aus. Diese Feeds müssen natürlich regelmäßig ausgelesen werden, gefolgt von einem Rebuild der Webseite. Das entsprechende, per Cronjob aufgerufene Script hat, als nanoc-Kommando implementiert, den Vorteil, jederzeit auch so aufgerufen werden zu können und im selben Repository zu stecken wie der Rest der Website.
Die meisten meiner Webseiten haben ein Kommando, mit dem sich die Quelldateien komplett durch einen frischen Checkout ersetzen lassen, wenn bspw. einige Dateien gelöscht worden sind (was sonst bei meinem Workflow dazu führt, dass die Dateien weiter vorhanden bleiben). Im Prinzip wird dabei das Quellverzeichnis komplett geleert, dann ein frischer Git-Checkout vorgenommen, nanoc prune entfernt überzählige compilierte Dateien aus dem Ausgabeverzeichnis, und ggf. werden vor dem Compilieren noch RSS-Feeds ausgelesen oder andere notwendige Operationen vorgenommen, damit alle erforderlichen Daten für den Aufbau der Website zur Verfügung stehen.

Andere Beispiele:

Creating screenshots with nanoc command
A create-post command

Verwendet ihr auch nanoc-Kommandos?

Vernetzungsfunktion von dejure.org als nanoc-Filter

nospam@example.com (Thomas Hochstein) — Wed, 10 May 2017 05:40:00 +0000

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.

Außerdem stellt dejure.org mit seiner juristischen Vernetzungsfunktion eine Möglichkeit zur “automatischen Verlinkung von Gesetzes- und Rechtsprechungszitaten über eine einfache Schnittstelle” zur Verfügung. Jeder Paragraph eines bei dejure.org (oder buzer.de) erfassten Gesetzes, jede Urteilsfundstelle wird auf Wunsch mit einem passenden Link auf dejure.org hinterlegt. Für eine Vielzahl von Webapplikationen (Blogs, CMS, Foren, Wikis), darunter Wordpress, Serendipity und Dokuwiki, sind Plugins verfügbar; außerdem wird eine Beispiel-Implementierung in PHP bereitgestellt, die sich als Vorlage für eigene Plugins verwenden lässt.

In diesem Blog verwende ich die Vernetzungsfunktion bereits seit vielen Jahren; gerne hätte ich eine solche Funktion auch für meine privaten Webseiten gehabt. Nach deren Relaunch war ich dann motiviert genug, mir diese Möglichkeit zu schaffen. Theoretisch sollte das nicht schwer sein: nanoc, mein static site generator, unterstützt das Konzept von Filtern, die (bspw.) aus Markdown HTML machen. In gleicher Weise lässt sich die Vernetzungsfunktion einbinden. Einziges Problem: die Beispiel-Implementierung ist in PHP gehalten, Varianten in Perl und ASP werden angeboten, aber ich bräuchte Ruby … und das “spreche” ich dazu noch kaum. Dennoch: einen Versuch erschien es mir wert.

Und zu meiner Überraschung war es dann gar nicht so schwierig, das PHP-Beispiel in Ruby als nanoc-Filter nachzubauen: erst nur die Grundfunktion, dann - aufgrund der stark ansteigenden Compile-Zeiten - auch den optionalen Cache. Und schon habe ich einen Prototypen in Betrieb, der auf meiner Homepage alle Gesetzes- und Rechtsprechungszitate mit dejure.org verlinkt!

Interessenten können sich den Filter auf meiner Homepage herunterladen.

Installation von nanoc unter Windwows 7

nospam@example.com (Thomas Hochstein) — Sun, 25 Jan 2015 17:00:00 +0000

Über nanoc, einen Generator für statische Webseiten, hatte ich hier im Blog bereits berichtet. Bislang nutze ich ihn auf verschiedenen Linux-Maschinen ohne Probleme, wollte ihn aber nunmehr auch auf meinem Laptop unter Windows 7 installieren, um auch ohne Netzanbindung das eine oder andere ausprobieren zu können.

Installationsanleitung

Ausgehend von einer über Google gefundenen Anleitung gestaltet sich die grundsätzliche Installation unter Windows überraschend einfach und problemlos:

Zunächst benötigt man Ruby - dankenswerterweise gibt es dafür einen Windows-Installer zum Download. Empfohlen wird derzeit Ruby 1.9.3.
- Bei der Installation sollten die Optionen Add Ruby executables to your PATH und Associate .rb and .rbw files with this Ruby installation ausgewählt werden. Ggf. wird ein Reboot erforderlich.
- Testen lässt sich die Installation bspw. durch den Aufruf des interaktiven Interpreters mit irb (verlassen wird er mit quit) und durch den Aufruf von gem --version, um zu testen, ob auch der Paketmanager RubyGems installiert und lauffähig ist.
nanoc selbst wird dann einfach vermittels gem install nanoc installiert. Das funktionierte bei mir erfreulicherweise ohne jedes Problem; auch der Aufruf war sofort möglich.
Die Installation von Win32::Console verbessert ggf. die Darstellung und kann ebenso einfach mit gem install win32console erfolgen.
Fehlt zum Abschluss noch ein integrierter Webserver, falls man einen solchen nicht bereits zur Verfügung hat: gem install adsf ermöglicht es, die generierte Webpräsenz mittels nanoc view unter http::/localhost:3000 anzuschauen.
Nutzt man weitere Filter und Funktionen wie kramdown oder ähnliches, sind die entsprechenden Gems nachzuinstallieren. Gebräuchlich mag bspw. gem install kramdown haml rubypants sein.

So weit, so gut. Endlich mal ein Fall, wo die Installation eher “unixoider” Software unter Windows ohne größere Probleme funktioniert, könnte man denken.

Und dann kam LESS.

LESS is less than helpul

Neben den bereits genannten Gems benötige ich für meine Bootstrap-basierten Webpräsenzen auch LESS; sowohl Bootstrap als auch LESS habe ich ja bereits beschrieben.

Auch LESS gibt es als Gem; dessen Installation unter Windows ist aufgrund der enthaltenen Abhängigkeiten allerdings schwierig und zeigte sich - für mich - als unmöglich. Ein beherztes gem install less zieht nämlich auch die Installation von therubyracer nach sich, das wiederum libv8, eine Javascript-Engine, benötigt. Und die ist sperrig.

Eine Recherche bei Google zeigt eine nahezu unüberschaubare Zahl von entsprechenden Threads, sei es in einem Ruby-Forum oder bei StackOverflow unter Überschriften wie “Installing Gem therubyracer on windows 7”, “therubyracer gem on windows” oder “Installing Less in Ruby - Windows”, oder auch “bundle install / update: libv8 (therubyracer) installation fails (with native extensions)” oder “rails gem install ERROR: Error installing libv8: ERROR: Failed to build gem native extension”. Zumeist wurde dann auf ein Git-Repository bei Github namens “therubyracer for windows” verwiesen, das mir allerdings auch nicht weitergeholfen hat.

Nach etlichen Stunden habe ich dann irgendwann frustriert aufgegeben.

Falls es einem meiner Leser gelungen sein sollte, Ruby, LESS und Windows miteinander zu versöhnen, oder falls jemand andere kluge Ideen hat: immer her damit!

Nachtrag vom 2015-02-22: Das erwähnte Repository “therubyracer for windows” ist nicht mehr verfügbar.

[Dieser Eintrag wurde nachträglich im Februar 2015 veröffentlicht.]