Facebook hat den RSS-Feed für öffentliche Seiten am 28. Januar 2015 wie angekündigt eingestellt und ähnelt damit einer modernen, auf Sicherheitsgefühl getrimmten Siedlung: man baut einen großen Zaun ums komplette Areal und achtet peinlich genau darauf, daß man unter sich bleibt.

Das alles wäre kein Problem, wenn nicht - wie vor Jahren schonmal bei Myspace - einige Bands dazu übergehen würden, ihre Neuigkeiten nur noch im “sozialen Netzwerk” zu veröffentlichen und die Pflege einer eigenen Internetpräsenz weitestgehend einzustellen.

Möchte man weiter mitlesen, so ist als Nicht-Facebook-Nutzer Bastelarbeit angesagt:

Zum einen benötigt man einen Facebook-Account, der über die Facebook-Entwicker-Seite als Entwickler registriert werden muss - zwingende Voraussetzung für diese kostenlose Registrierung ist entweder die Angabe einer gültigen Mobiltelefon-Nummer oder einer gültigen Kreditkarte.

Als Entwickler legt man dann eine App an - Name, Sinn und Zweck sind beliebig, letztendlich benötigt man nur die App-ID sowie den App-Geheimcode, mit deren Hilfe man sich später automatisiert bei Facebook anmelden kann. Solange eine Seite öffentlich ist, reicht ein x-beliebiger Benutzer, um auf die öffentlichen Daten zugreifen zu können.

Das Zauberwort für den Zugriff lautet dann “Graph API”, für die Facebook neben dem kompletten SDK auch eine Online-Hilfe zur Verfügung stellt.

Glücklicherweise muss man das Rad allerdings nicht neu erfinden:

Nachdem die Lieblingssuchmaschine mit den richtigen Begriffen gefüttert wurde, landet man z.B. auf GitHub bei “facebook-json-to-rss”, einem kleinen Skript, das Login sowie die mühevolle Aufgabe der Konvertierung von JSON nach RSS bereits erledigt.

Nach dem Eintragen der App-Daten in die entsprechenden Stellen im Skript kann der Aufruf über das Anhängen des gewünschten Seitennamens

erfolgen und liefert die XML-Daten für den RSS-Feed zurück.

In der ursprünglichen Variante benötigt das nur 3.72 KB Skript noch das SDK, das zwar ebenfalls nicht allzu groß ist, aber lediglich zur Anmeldung verwendet wird.

Im Zugriffsschlüssel-Hilfsprogramm kann man sich das App Token der zuvor angelegten App anzeigen lassen und dieses direkt als “$access_token” im Skript verwenden. Nach Auskommentieren (oder löschen) des SDK-Includes sowie des Token-Abrufs funktioniert “facebook-json-to-rss” dann auch ohne SDK.

Funktioniert in der Kombination mit einer 32-bit Microsoft Office-2013-Version die Zeile

problemlos, so wird sie bei einem installierten 64-bit Office mit folgendem Fehler quittiert:

Eine längere Suche führte schließlich zum entscheidenen Hinweis: bei der 64-bit Installation wird der Schlüssel für die Typelib vom Office-Installer nur als “win64” gesetzt, Perl aber sucht nach einem “win32” Eintrag.

Ein Workaround ist somit recht einfach: unterhalb des Registrierungspfads

nach dem Eintrag für die “MSOUTL.OLB” suchen und passend zum “win64” Key händisch einen “win32” Key mit gleichem Inhalt erzeugen.

Aus unerfindlichen Gründen ignoriert der Installer für Ruby Gems die Umgebungsvariablen “http_proxy” bzw. “https_proxy”, stattdessen muß der Proxy in der Kommandozeile angegeben werden:

Versucht man auf einem 64bit System mit 32bit Software auf eine ODBC-Quelle zuzugreifen, so erhält man statt der erhofften Daten lediglich eine Fehlermeldung:

connection failed: [Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf. (SQL-IM014)

Auf den ersten, zweiten und dritten Blick bietet Windows auch keine Möglichkeit, die gewünschte Architektur der Datenquelle anzugeben. Der Trick liegt im expliziten Aufruf des ODBC-Datenquellen-Administrators “odbcad32.exe” im Pfad “C:\Windows\SysWOW64”, auf den standardmäßig kein Link im Startmenü gesetzt wird.

Da die Verwaltungsoberflächen für 32bit und 64bit nicht gekennzeichnet sind, hilft im Zweifelsfall ein Blick in die Prozessliste des Taskmanagers: hat die dort aufgefühte “odbcad32.exe” den Zusatz “*32”, so ist aktuell die Verwaltung für 32bit-Datenquellen gestartet. Fehlt dieser Zusatz, ist die Verwaltung für 64bit Datenquellen aus dem Verzeichnis “C:\Windows\System32” aktiv.

Im privaten- oder Hobbybereich nur selten eingesetzt, kann eine Versionsverwaltung auch hier helfen den Überblick zu behalten. Egal, ob der Umfang über eine Hand voll Dateien oder die Skriptlänge über eine Bildschirmseite wächst - irgendwann führen temporär umbenannte Dateien und ge-zip-pte Versionen mehr zur Verwirrung denn dazu, im Falle eines Falles nochmal die letzte funktionierende Version rekonstruieren zu können.

Ein Blick auf einen der Big Player wie Git macht allerdings wenig Lust darauf, ein Versionsmanagement einzusetzen: alleine die Installion und Konfiguration wird mit ein bißchen Pech leicht zu einem Unterfangen, das die Größe des eigentlich zu verwaltenden Projekts deutlich übersteigt.

Als schlanke und sowohl einfach zu installierende als auch zu konfigurierende Alternative entpuppt sich Fossil, dessen Installation aus dem Herunterladen einer gepackten Datei besteht mit der dann dach dem Entpacken in einen beliebigen Ordner sofort losgelegt werden kann. Wer es etwas komfortabler haben will, entpackt die Datei irgendwo innerhalb des Suchpfades oder erweitert diesen um das Verzeichnis, in dem die ausführbare Fossil-Datei liegt.
Ein weiterer Vorteil von Fossil liegt darin, daß ein Fossil-Repository lediglich aus einer SQLite-Datenbank besteht, somit also im Bedarfsfall problemlos auf einen USB-Stick, Cloudspeicher (oder sonstwohin) kopiert und an einem anderen Ort weiterverwendet werden kann.

Vollständigen Beitrag lesen