Implizite Informationen

Neue Konzepte ausprobieren macht Spaß. Fossil ist eine interessante Mischung aus verteiltem Versionskontrollsystem, Wiki und Issue-Tracking-System. Für Eingeweihte: ein Trac verschmolzen mit Mercurial. Der große Vorteil: es wird kein zentraler Server benötigt. Der kleine Vorteil: Fossil besteht aus einer einzigen Datei, die Repositories ebenfalls.

Leider unterstützt Fossil nicht den Import von Mercurial-Repositories, noch Mercurial den Export in Fossil-Repositories. Was tun? Den Umweg über Git nehmen. Zwei Seiten helfen weiter:

• Converting from Mercurial to Git
• Fossil: Import And Export

Im ersten Schritt ist das Tool fast-export zu installieren:

cd /path/for/scripts
git clone git://repo.or.cz/fast-export.git

(Ich setze einmal voraus, dass auf dem System Git installiert ist ...)

Nun steht dem Konvertierungsvorgang nichts im Wege:

git init /tmp/git-repo
pushd /tmp/git-repo
/path/for/scripts/fast-export/hg-fast-export.sh -r /path/to/mercurial-repo
git fast-export --all | fossil import --git /path/to/fossil-repo
popd
rm -rf /tmp/git-repo

Hmm, das wäre ja ein Kandidat für ein eigenes Shell-Skript ;-).

Übrigens, erste Experimente zeigen, dass Fossil die Daten am besten komprimiert. Danach kommt Git und zum Schluss Mercurial. Aber alles innerhalb von ca. 20%, also nichts weltbewegendes.

Ich hasse Word. Das tut nie das, was man will.

Dieser Ausspruch läßt sich auf viele anderen Programme übertragen: Word, Excel, Powerpoint, die ganze OpenOffice Suite, Keynote, Numbers, Page, Graphikprogramme, und so weiter. Ganz spannend wird es, wenn eine Keynote-Präsentation in das Format von Powerpoint umgewandelt werden soll. Oder, noch schlimmer, Word nach OpenOffice Writer. Dann bleibt einem meistens nur noch übrig, den reinen Text von dem einen in das andere Programm zu kopieren und die Formatierung anschließend wieder nachzuvollziehen.

Einer der Gründe ist die Verwendung von sehr eigenwilligen Datenformaten. Heutzutage sind die meisten Office-Dateien nichts anderes als eine Sammlung von XML-Dateien, die in eine ZIP-Datei gepackt wurden. Manchmal hilfreich, meistens irrelevant. Selbst wenn diese Datenformate "normiert" sind, jedes Programm interpretiert die Norm auf eine eigene Art und Weise. Im Ergebnis läßt sich jede Datei nur von einem Programm lesen und verarbeiten. Der Anwender ist dem Programm auf Gedeih und Verderb ausgeliefert. Ein falsches Bit und der Anwender kann die Datei nicht mehr öffnen.

In vielen Fällen geht es auch anders. Es gibt ein Datenformat, dass in so gut wie auf jeder Plattform verfügbar ist: ganz normaler Text. Jedes Betriebssystem liefert mindestens eine Anwendung zum Erstellen von Textdateien mit. Unter Windows ist es Notepad, unter OSX ist es TextEdit, unter Linux gibt es vi, Emacs, gEdit und wie sie alle heißen.

Erstaunlich viele Daten lassen sich als normale Textdateien ablegen. Die meisten Texte lassen sich so schreiben. Für besondere Bestandteile können sogenannte Auszeichnungssprachen genutzt werden. Das müssen nicht gleich komplizierte Sprachen, wie XML, HTML oder LaTeX sein. Meistens reichen einfache Muster, wie Sie jede(r) bei normalen Text verwenden würde. Zum Beispiel wird eine Textpassage kursiv gestellt, indem diese mit dem Zeichen '*' eingerahmt wird. Übrigens, die meisten Inhalte von Wikipedia sind auf diese Art und Weise erstellt worden. Ein offeneres Format gibt es nicht.

Werden Dateien im Textformat erstellt, so eröffnet sich dem interessierten Anwender ein ganzes Biotop von Anwendungen:

• ein paar hundert Programme der diversen (Unix-) Shells
  • grep, sort, diff, cut, ...
• zig Programme der (Windows-) Eingabeaufforderung
• jede Programmiersprache erlaubt das Lesen und Verarbeiten von Textdateien
• Versionskontrollsysteme, um die Änderungen zu protokollieren, alte Stände wiederherzustellen oder gleichzeitige Zugriffe zu koordinieren
  • (Probieren Sie das einmal mit Word, Writer oder Pages)
• Graphiken können zum Beispiel mit graphviz erstellt werden

All diese Programme arbeiten zusammen.

Zur Textformatierung gibt es wunderbare Werkzeuge:

• reStructuredText interpretiert den eingegebenen Text sehr anwendernah und erzeugt daraus u.a. HTML-, XML, ODP- und LaTeX-Dokumente, sowie mit Hilfe von S5 ansehnliche Präsentationen.
• Markdown, Multimarkdown und Textile erstellen mit einfachen Angaben strukturierte HTML-Dokumente.

Nebenbei, fast alle Seiten dieses Blogs sind mit Markdown formatiert, einige andere mit reStructuredText.

Aber auch etwas komplexere Formate, wie LaTeX, haben große Vorteile gegenüber den proprietären Formaten. Ich kann mir den Text von anderen Programmen zusammenstellen lassen. So brauche ich Vorlesungsinhalte, die für mehrere Veranstaltungen relevant sind, nur einmal ablegen. Ändern sich diese Bestandteile, sind alle Präsentationen auf einen Schlag angepasst. Machen Sie das einmal mit Powerpoint, Impress oder Keynote. Von der Möglichkeit, an zentraler Stelle Layoutänderungen vorzunehmen ganz zu schweigen.

Mit ganz normalem Text ist jeder Anwender Herr seiner Daten. Archivierungsprobleme gibt es nicht. Sicherheitsprobleme auch nicht. Es ist schon recht schwierig einen Schädling in einer Textdatei so unterzubringen, dass er unerkannt bleibt. Selbst wenn dieser in der schieren Masse von Text verborgen wird, es gibt immer genügend Werkzeuge, die nicht von dem Schädling betroffen ist.

Wenn das keine Gründe sind. Wann steigen Sie um?

Update 4.1.2011: als kleine Bestätigung flattert mir heute morgen noch die folgende Seite hinein: Ad Hoc Data Analysis From The Unix Command Line.

In der c’t-Ausgabe 23/2009 gibt es einen Artikel mit Namen Elefantengedächnis, der beschreibt, wie man die Twitter-Timeline nebst Links und Bilder archivieren kann. Zwei Gedanken gingen mir nacheinander durch den Kopf. Erstens: "Hätte ich doch etwas gewartet, da hätte mir dann jemand Arbeit abgenommen". Zweitens: "Zum Glück habe ich vorher angefangen und meine eigenen Erfahrungen gesammelt".

Im Unterschied zu Twacbak ist Twitterbak mit Hilfe von Perl und PHP implementiert. Der Perl-Code dient dazu Twitter regelmäßig per API abzufragen und die Ergebnisse abzuspeichern. Mit PHP wird ein web-basierter Dienst implementiert, um die Ergebnisse anzuzeigen und zu durchsuchen. Schwerpunkt von Twitterbak ist das Archivieren der eigenen Tweets.

Ist Twitterbak eine Konkurrenz zu Twacbak?

Auf jeden Fall. Eine gute dazu.

Das Profil von Twitterbak ist klar: Datensicherung. Wohin die Reise mit Twacbak hingehen wird, ist mir dagegen noch nicht klar.

Was gibt es an Ähnlichkeiten? Beide wollen die Ergebnisse von Twitter-Aktivitäten längerfristig sichern, beide nutzen dazu SQLite als interne Datenbank. Beide sichern die eigenen Tweets, die direkten Nachrichten und die sog. Mentions, d.h. Tweets, in denen der eigene Account erwähnt wird. Beide sollen periodisch im Hintergrund, z.B. als Cron-Job, ablaufen.

Was kann Twacbak darüber hinaus? Twacbak kann auch die gesamte Timeline sichern, d.h. alle Tweets aller Account, denen man selbst folgt. Es werden die Favoriten gesichert und, ganz wichtig, alle Friends und Follower. Ich weiß, wovon ich spreche. Die Liste derjenigen denen man folgt ist ein fast so wertvolles Asset, wie die eigenen Tweets. Nebenher speichert Twacbak die Friend/Follow-Historie, denn es gibt immer wieder welche, die einem abwechselnd folgen und wieder nicht folgen. Damit ist Twacbak nicht nur ein Werkzeug zum Sichern der Twitter-Aktivitäten, sondern unterstützt diese auch. Mit Twacbak können sebst auch Tweets gesendet werden, Re-Tweets auf Basis von Schlüsselworten werden unterstützt, auch das Folgen per Kommandozeile geht.

Viele der anderen Unterschiede sind Geschmackssache. Ob ich nun das Ganze über eine Konfigurationsdatei steuere oder ob die Daten in der Datenbank selbst abgelegt werden: jeder wird für beides Vor- und Nachteile finden. Ditto für Änderungen am Quellcode selbst und einige Befehlsoptionen mehr gegenüber der Wahl für eine kleine Skriptsprache. Letztens Endes Firlefanz für einen Vergleich.

Natürlich kann das eine oder andere auch schnell von Twitterbak implementiert werden. Auch die größere Fehlertoleranz, wenn Twitter mal wieder nicht verfügbar ist. Darauf freue ich mich.

Ich habe für Twacbak die Anregung aufgenommen, die kurzen URL zu ermitteln, die sich hinter den Twitter-typischen Short-URL’s (z.B. via bit.ly) verbergen. Das gleiche gilt für Bilder. Nebenbei, dank der Python-Bibliotheken ("Batteries included") geht das Ganze leichter und weniger fehleranfällig von der Hand. (Die Spitze musste sein, ich nehm das aber nicht zu ernst ;-) )

Über den Artikel habe ich mich sehr gefreut. Bestätigt er doch, wie sinnvoll es ist, selbst für die Sicherung der eigenen Daten zu sorgen und sich nicht immer nur irgendwelchen obskuren Web-Diensten anzuvertrauen. Ich werde die Entwicklung von Twacbak im Rahmen meines Zeitbudgets vorantreiben und immer mal nach nebenan zur Konkurrenz schielen.

Die belebt nämlich auch den eigenen Geist.

Lange habe ich mich schon um die Anforderungen zu Twacbak herumgedrückt. Im Kopf waren Sie schon, aber nicht zu Papier. Und, als weitere Ausrede, musste ich erst einmal ausprobieren, was die Twitter-API so alles hergibt. Damit bin ich nun soweit fertig, einen ersten Prototyp habe ich auch schon.

Also, was sind (meine) Anforderungen?

Funktionalität

• Sichern aller grundlegenden Daten eines Twitter-Accounts, wie:
  • Benutzerdaten (Name, Location, eigene URL, Bio, … so wie sie im Profile / Setting angegeben werden),
  • alle eigene Tweets,
  • Favorites,
  • gesendete Nachrichten,
  • empfangene Nachrichten,
  • Liste der Friends, d.h. der Accounts, denen man folgt,
  • Liste der Follower, d.h. die Account, die einem folgen.
• Sichern von nützlichen Zusatzinformationen:
  • Wann ist mir wer gefolgt, wann hat er mich aus seiner Liste gelöscht?
  • Wann bin ich jemanden gefolgt, wann habe ich das Verfolgen aufgegeben?
  • Was haben meine Friends so getwittert?
  • Wenn jemanden eine Antwort getwittert hat, auf welchen Tweet welchen Benutzers bezog sich diese Antwort?
• Die gesammelten Daten sollen auf den Bildschirm / in eine Datei ausgegeben werden können.
• Darüber hinaus sollen folgende Berichte (Bildschirm / Datei) ausgegeben werden:
  • Liste der Accounts, die kürzlich das Verfolgen eingestellt haben
  • Detailinformationen zu Accounts, z.B. wann bin ich gefolgt, wann wurde meinem Account gefolgt, wann wurde das Verfolgen eingestellt und wieder aufgenommen, …
  • Durchsuchen der Tweets nach bestimmten Begriffen.
• Sobald von Friends Tweets mit einem definierten Hashtag erscheinen, sollen diese Retweetet werden.
• Eigene Tweets sollen auf einem anderen Account gespiegelt werden.
• Gespeicherte Informationen zu Accounts sollen regelmäßig aktualisiert werden, z.B. einmal pro Woche.

Technisches

• Die Daten sollen so abgespeichert, dass diese auch separat auswertbar sind.
• Twacbak soll regelmäßig ohne Benutzerinteraktion die Daten von Twitter einsammeln können.
• Es soll eine Lösung für einen Account erstellt werden. Twacbak soll nicht für beliebig viele Accounts Daten sammeln.
• Es sollen beliebige Microbloggingdienste unterstützt werden, welche die Twitter-API bereitstellen. Neben Twitter ist dies z.B. identi.ca.
• Twacbak soll im Normalfall einmal pro Stunde ablaufen und dabei max. 50 Aufrufe der API tätigen.
• Die Software soll so weit es geht platformunabhängig sein. Auf jeden Fall soll die Software unter Windows und unter Linux ablaufen.

Das wären die ersten Anforderungen. Wir alle wissen ja: der Appetit kommt beim Essen. Und wenn jemand Anregungen hat, ich nehme diese gerne entgegen ;-)

Jedes Kind muss einen Namen haben. Und für eine Heimat wäre es wohl auch dankbar. Zuerst der Name. Nicht zu lang, bin ja tippfaul. Eindeutig und aussagekräftig sollte er sein. Bisher hatte ich von "meinem Twitterbackupanalyseprogramm" gesprochen. @jbanach kam mit dem Vorschlag "Twaccback" (Twitter Account Backup). Ich habe noch zwei C's aufgehoben. Eines für das Glücksrad, das andere für die Sesamstraße.

Als Heimat kommen auch diese Seiten in Betracht. Dann könnte ich aber entweder "nur" das gesamte Paket zum Download anbieten oder ich müsste hier Software installieren. Aber es gibt ja Dienste, welche die Softwareentwicklung unterstützen. De facto gibt es die Wahl zwischen SourceForge.net oder Google Code. Ich habe mich für SourceForge.net entschieden, weil es da einige Dienste gibt, die ich immer schon mal ausprobieren wollte: Mercurial als verteiltes Versionskontrollsystem (kann Google Code auch) und Trac (kann Google Code m.E. nicht). Beide wären auch Kandidaten für meine Veranstaltung "Projektstudie Softwareentwicklung" ;-).

Somit ist die Heimat von Twacbak gefunden.

Bleibt noch die Frage der Lizenz. Open Source sollte sie sein, von abgeschlossenen Systemen halte ich nicht zu viel. Die GPL ist mir zu viral (und einschränkend), MIT & Co. zu offen. Als Lizenz habe ich (vorläufig) die Apache License, Version 2.0 definiert.

Ja, ich weiß. Langsam sollte ich die Anforderungen definieren. *g

Update 20.03.2011: Twacbak ist jetzt doch auf meinen Seiten verfügbar. Die Seiten bei SourceForge sind höchstens historisch zu sehen. Der Grund? Weil ich es kann. Ich habe einen Hoster gefunden, der (nicht nur) Mercurial und Trac erlaubt. Und noch viel mehr. Name? Uberspace.