Computer

"Emacs is a great operating system - it lacks a good editor, though." Seit vielen Jahren schon ist der Gnu Emacs mein Hauptwerkzeug am PC. Erfreulicherweise ist er relativ plattformunabhängig, so dass ich eine Vielzahl von Funktionen auf verschiedenen Rechnern ausführen kann.

Ende 2009 habe ich auf der immer mal wiederkommenden Suche nach Emacs-Werkzeugen für die Arbeitsorganisation (Aufgabensteuerung etc.) Org-Mode entdeckt. Das war ziemlich genau das, wonach ich eigentlich gesucht habe:

• Vernünftiger Gliederungsmodus
• Aufgaben einsteuern, überwachen, nachvollziehen
• Leicht zu erlernen, viele schnell zu bedienende Features
• Ausgabe leicht nach LaTeX bewerkstelligbar; incl. auf entsprechende Dokumentklassen zugeschnittenem Output
• Ausgabe leicht nach HTML bewerkstelligbar; damit habe ich auch diese Homepage zusammengestell
• Verwendet als Dateiformat reine Textdateien

Weitergehende Informationen zum Org-Mode habe ich auf einer eigenen Unterseite zusammengestellt.

Links hierzu:

• Wikipedia

  (en)

  http://en.wikipedia.org/wiki/Org-mode

  (de)

  http://de.wikipedia.org/wiki/org-mode

• Tutorials etc.: http://orgmode.org/worg/org-tutorials/index.php

LaTeX ist seit vielen Jahren mein Brot- und Buttertextsatzsystem. Für viele Einsatzbereiche (insb. mathematischer Formeldruck) ist es ungeschlagen, gut zu bedienen und sehr leistungsfähig.

Nervig ist die Integration von Grafiken (das ist einfach immer umständlich) und die Interaktion mit Produkten aus der Microsoft Office-Welt. Man wünscht sich doch manchmal eine leichtere Möglichkeit, sich mit Word-Benutzern schnell auszutauschen.

Für statistische Auswertungen habe ich R kennen und schätzen gelernt. Die Lernkurve ist zwar aufgrund der Kommandozeile als Standard-Interaktion etwas steil, aber es bietet nette Datenkonstrukte, viele schöne statistische Funktionen und gute grafische Ausgaben.

SCM- (oder Source Code Management) Tools gibt es mittlerweile viele. Nach den ersten Schmerzen mit CVS war ich recht glücklich, als mit Subversion eine erste Verbesserung eintrat. Nach einigen Jahren des Arbeitens mit Subversion habe ich im Jahr 2009 dann Git gefunden. Es bringt viele von mir gewünschte Features mit sich:

Dezentral

Man hat das gesamte Repository incl. Geschichte und alter Versionen immer bei sich. Es gibt keine Notwendigkeit, den eigenen Rechner mit einem Server-Dienst zu verbinden. Und wer nicht immer in der gleichen Büro-Umgebung arbeitet, wird dies zu schätzen wissen. Gerade im Zug, Flugzeug oder abseits eines Internetanschlusses kann man dennoch gut an seinen Projekten weiterarbeiten, hat den Zugriff auf die historischen Daten und kann neue Versionen erstellen.

Gute Gruppenunterstützung

Es sind verschiedene Arbeitsabläufe denkbar, um in einer Gruppe gut zusammenzuarbeiten. Dezentrale SCM-Systeme sind hinsichtlich des Zusammenführens von Teilergebnissen qua Konzept komplexer. Infolgedessen muss man in Bezug auf die Organisation der Zusammenarbeit einige Gedanken investieren und anschließend als Regeln für die Gruppe etablieren. Dann lassen sich aber auch ganz unterschiedliche Konzepte und Ideen gut realisieren.

Schnell, plattformübergreifend, sicher

Git ist wirklich schnell. Gerade aufwändige Operationen wie Merges werden bspw. im Vergleich zu Subversion rasend schnell ausgeführt.

Branches und Mergen

Wer einmal versucht hat unter CVS oder Subversion einen Zweig mit einem anderen zusammenzuführen, wird aufgrund des Ärgers und des Zeitaufwandes diese Mühen zukünftig versuchen zu vermeiden und Branches und Merges schlicht nicht nutzen. Git ist geradezu für das schnelle Erstellen und Zusammenführen von Zweigen gemacht, und es geht wirklich schnell und einfach.

Der einzige wirkliche Nachteil ist die doch recht steile Lernkurve. Mit den Standardbefehlen kommt man sehr schnell zurecht, aber sobald es mal um Patches versenden, Mergen verschiedener Zweige etc. geht, muss man doch das eine und andere mal nachlesen. Ebenso etwas nachteilig sind die zum Teil nicht so sonderlich instruktiven Hilfeseiten zu den Befehlen.¹

Schon zu Schulzeiten hat mich Lisp interessiert. Im Gegensatz zu vielen "Skeptikern" finde ich gerade die Lisp-Syntax mit den vielen Klammern ästhetisch. Heute "beherrsche" (im Sinne von "ich komme damit zurecht") zwei Lisp-Dialekte:

Common Lisp

Als Standardlösung für Anwendungen; hier setze ich auf Linux-Basis in der Regel SBCL ein.

Emacs Lisp

Zur Programmierung und Erweiterung des Gnu Emacs; Das Emacs Lisp ist etwas gewöhnungsbedürftig und hat auch die eine oder andere Eigenheit, aber ich komme halbwegs zurecht.

Bei der Verarbeitung von Daten in R habe ich neulich SQLite als feine kleine Datenbankanwendung schätzen gelernt. SQLite ist eine eingebettete Datenbank (ca. 300 KB C-Code), die ihre Daten in einer Datei auf dem Filesystem speichert, ohne Server und ohne große Voraussetzungen an vorhandene Bibliotheken. Trotzdem unterstützt sie den Großteil von SQL, führt Transaktionen ACID aus und benötigt praktisch keine Konfiguration. Klar, das ganze hat natürlich auch so seine Begrenzungen, aber für eine Vielzahl von Anwendungen ist dies eine feine und leicht zu implemtierende Variante. Da es zu ziemlich vielen Programmiersprachen Schnittstellen gibt, lässt es sich mit der dem Programmierer liebsten Sprache auch leicht und bequem ansteuern. Bekannte Einsatzgebiete von SQLite sind: Programme aus der Mozilla-Gemeinschaft wie der Firefox verwenden SQLite zum Speichern ihrer Applikationsdaten, Apple benutzt es für Apple Mail, Safari und andere ANwendungen, Adobe setzt es in Lightroom und ihrer AIR ein, SQLite ist integraler Bestandteil der Symbians Betriebsystems für Smartphones; weitere bekannter Nutzer kann man auf der Homepage von SQLite nachlesen.