Heute bin ich über diese Redewendung gestolpert. Ich schrieb so vor mich, wollte betonen, dass eine Änderung im Ansatz eine tradierte Vorgehensweise nicht ausschließen würde, und erwischte mich dabei, wie ich “soll mit diesem Ansatz auf keinen Fall der Garaus gemacht werden” tippte. Das ging ganz flüssig. Aber als die Formulierung so dastand kam sie mir merkwürdig vor. War das so richtig?

Die Rechtsschreib-Prüfung meckerte nicht, also standen die Chancen gut. “Gar aus” beanstandete sie aber auch nicht. Was heißt das eigentlich? Fertig machen, umbringen, töten, kommt mir so in den Sinn. Ich glaube aber nicht, dass ich die Formulierung häufiger nutze, jetzt wo sie mir so fremdartig vorkommt. Lesen tut man sie manchmal. Besser mal nachschauen!

Duden verweist nüchtern auf töten. Das Deutsche Wörterbuch ist da schon unterhaltsamer, da gibt es zwei Lesarten:

GARAUS, m. n. völliges ende, untergang u. ä., …

Die Ellipse steht für eine lange Folge von Nachweisstellen. Scheint schon immer populär gewesen zu sein, die Formulierung. Dann gibt es da aber auch noch einen Plural:

GARAUS, pl. bei Fischart unter unheimlichen wesen: von wehrwölfen, pilosen, geiszmänlin, dusen, trutten, garausz und bitebawen (s. d.).Garg. 119b, garousz Sch. 214. es ist das frz. garou,jetzt loup-garou, Werwolf.

Eigentlich schien mir die zweite Lesart plausibler, also Garaus im Sinne von Grausen. Butzemänner und Werwölfe sind doch sehr plastisch, jemandem den Werwolf machen auch. Da bliebe doch auch nicht viel übrig, oder? Lykaner vor.

Aber die wahre Herkunft der Redewendung hält sich nicht an mein, sicherlich durch zuviel Hollywood geprägtes, Skript. Die Lesart 1 des DWB wird von der Wikipedia aufgenommen, wo es völlig unplastisch heißt:

Der Ausdruck Garaus entstand aus dem Ruf „gar aus!“ (vollständig aus!), der im 15. Jahrhundert in Süddeutschland die Polizeistunde ankündigte. Später erhielt der Begriff allgemein die Bedeutung Ende. Heute wird er nur noch in der Wendung „jemandem/etwas den Garaus machen“ (jemanden töten oder vernichten, einer Sache ein Ende bereiten) verwendet.

Nun gut, genug prokrastiniert.

Malen und zeichnen auf Papier finde ich ja meist ganz entspannend, und oft auch einfacher als die elektronische Variante. Geht schneller und ist unmittelbarer, auch wenn ich als Zeichner eher weniger begabt bin. Was macht man dann aber nach Fertigstellung mit dem Papier? Einscannen wohl, und dann irgendwie weiter verarbeiten. Als Papierartefakt hat es heute keine große Funktion mehr, es sei denn man ist an sogenannten Originalen interessiert. (Die Probleme dieses Begriffs wurden zwar schon frühzeitig im letzten Jahrhundert erläutert, wie man am jüngsten Skandal des Kunsthandels aber sehen konnte, lassen sich immer noch genügend zahlungsbereite Menschen finden, die fest an die Aura des Originals — oder doch eher dessen Wertsteigerung? — glauben. Kleiner Abschweif, pardon.)

Also das Papierartefakt, das passive, um das soll es gehen. Im Zeitalter der schlauer werdenden Objekte ist das kein Zustand, der lange währen kann. Die britische Firma Bare Conductive bietet daher Farben an, mit denen Malereien aller Art etwas reaktiver gemacht werden können. Der Clou an den Farben ist, dass die Malerei gleichzeitig als Stromleiter dienen kann. Wir erzeugen also nicht nur ein Abbild, sondern können es auch zum Leben erwecken, wenn wir es möchten und Spannung anlegen. Derzeit gibt es eine normale Farbe und eine für die Haut. Die Auswahl der verfügbaren Farbtöne orientiert sich im Augenblick noch an dem seligen Henry Ford: es gibt nur Schwarz.

Um das mal zu testen, habe ich mir zwei Töpfchen der Farbe besorgt. Nur die normale Variante (Bare Paint), die hautverträgliche (Bare Skin) ist erst seit kurzem erhältlich. Zu den Farben gibt es derzeit kein Datenblatt, das sei in Arbeit. Man weiß also nicht, was alles drin ist. Allerdings soll die Farbe ungiftig und wasserlöslich sein, schließlich zielt man damit vor allem auf Bildungsinstitutionen. Nehmen wir die Farbe daher mal in Augenschein.

Bare Conductive Paint

Was man von Bare Conductive bekommt sind kleine Kunststoffpötte mit jeweils 50ml Inhalt. Die Farbe soll sich circa 6 Monate halten. Öffnet man das Pöttchen sieht man eine schwarze Masse, die ein wenig nach Teer aussieht, allerdings nicht so riecht, sie ist eher geruchlos. Ganz im Gegensatz zu Teer ist sie auch leicht mit Wasser abzuwaschen, wie ich gleich ausprobieren konnte.

Farbe als Leiter zwischen Stromquelle und LED

Um die Farbe auszuprobieren habe ich eine kleine Versuchsanordnung aufgebaut, ähnlich einem der Tutorials auf der Webseite. Dort wird eine LED mit einer zwei AA-Batterien verwendet. Da gerade keine passenden Batterien zur Hand waren habe ich einen Arduino (Duemilanove) als Stromquelle genutzt. Die Anordnung besteht aus einem Blatt Papier auf das ich zwei ziemlich dicke Striche mit der Farbe gezogen habe. Wie dick der Farbauftrag wirklich sein muss, das muss ich erst noch herausfinden, hier habe ich wohl eher zuviel genommen, denn das Trocknen dauerte.

Nachdem die Farbe endlich getrocknet war, habe ich einfach die Spannungs-Pins des Arduino Duemilanove (GND und 3V3) per Drahtbrücke mit den Farbstrichen verbunden. Auf der anderen Seite führen ebenfalls Drahtbrücken zu einem kleinen Steckbrett mit der LED. Sobald Spannung angelegt wurde, leuchtete die LED. Funktioniert!

Die Verluste waren bei dieser kurzen Strecke (5cm Strichlänge) kaum messbar. Da muss ich noch etwas testen, um Grenzwerte zu finden. Bisher erscheint die Farbe aber als eine einfache Alternative zu herkömmlichen Schaltkreisen. Und man muss nicht bei Papier beiben. Solange die Farbe haftet kann man wohl alle möglichen Dinge damit versehen, und entweder Energie oder Information (Signale) übertragen.

Schreibziele und -fortschritt sind nicht nur für die Schreiberlinge ein Thema, sondern im Zeitalter der Betaversionen für Bücher auch für deren Kunden, die Leser. Als technologisch aufgeschlossener Mensch habe ich einige dieser Betabücher gekauft, die im IT-Bereich besonders populär zu sein scheinen. Macht ja auch Sinn, denn die in solchen Titel abgehandelte Software ist ja vielfach auch noch im Beta-Stadium, oder dem gerade erst entwachsen.

Pragmatic Programmers: Schreibfortschritt für Beta-Titel

Die Vorgehensweise beim Betabuch ist immer dieselbe. Man kauft den Titel, der zunächst nur aus einigen, wenigen Kapiteln besteht, erhält Einblick in das mehr oder weniger rohe Manuskript und wird periodisch vom Verlag über neue Fassungen auf dem Laufenden gehalten. Praktisch heißt das, dass man ab und zu eine Mail mit dem Download-Verweis bekommt, versetzt mit Hinweisen auf die mögliche, weitere Entwicklung.

Je nach Autor und Werk unterscheiden sich dabei die Perioden. Manchmal scheint hinter den Kulissen eine große Pause eingetreten zu sein, denn man hört eine Zeit lang nichts mehr von einem Titel, bis dann irgendwann eine Durchhalte-Mail vom Verlag kommt. Da man, bis auf etwaige Foren zum Buch, keinen Einblick in die Entwicklung hat, bleibt einem dann nur übrig aus der Distanz auf weitere Echos zu warten.

Die Pragmatic Programmers haben sich nun etwas überlegt, verschaffen dem Leser etwas mehr Einblick in die Entwicklung des Titels. Wie ich beim Blättern in deren Webseiten feststellte, gibt es da nun eine Fortschrittsanzeige pro Titel (“Track our progress” klicken). Die Entwicklung der Wortzahlen wird dort pro Woche und Kapitel visualisiert. Keine schlechte Idee, denn so weiß man als Leser eher, ob man demnächst mit einem Kapitel rechnen kann, das gerade interessant ist.

Auch für die noch Unentschlossenen mag diese Visualisierung ein Kaufanreiz sein. Normalerweise bekommt man nämlich nur zu sehen, ob dieses oder jenes Kapitel schon verfügbar ist. Bei der PragProg-Visualisierung kann man immerhin schon mal anhand der Wortzahlen abschätzen, ob sich die Investition in das Buch überhaupt oder zur Zeit lohnt.

Auf der Seite zum Kindle Format 8 gibt Amazon eine Vorschau auf die Eigenschaften des neuen Formats für Kindle-Bücher. Kindle Format 8 soll das derzeit verwendete MOBI-Format ersetzen. MOBI hat seine Wurzeln auf den Palm-Rechnern vergangener Zeiten, und ist somit nicht für komplexere Formatierungen und moderne Tablets mit Multimedia-Fähigkeiten gedacht gewesen.

Die Ankündigung von Amazon zeigt eigentlich nur, dass man die andernorts schon vorgemachten Erweiterungen für digitale Bücher nachvollzieht. Und natürlich, dass man beim eigenen Format bleibt, statt zu EPUB zu wechseln, wie erwartet worden ist.

Mit KF8 kann man dann auch für den Kindle Bücher mit fixem Layout erstellen, auch an Comics wurde gedacht. Die sind derzeit auf dem Kindle kein Vergnügen. Amazons Format bietet dann ebenfalls eine Untermenge von HTML5 und CSS3 an. Derzeit allerdings ohne Video- und Audio-Tags. Der Script-Tag zur Einbindung von Javascript fehlt auch (die EPUB3-Spezifikation geht dagegen auf eingebettete Skripte ein).

Die derzeitige Vorschau verheißt also eine Evolution im Format: digitale Bücher können besser gestaltet werden, was bei den Kindle-Büchern auch bitter nötig ist. Aber sie bleiben dem gewohnten Buch ähnlich, nämlich passiv. Es sei denn, Amazon hat noch etwas in der Hinterhand.

Jo, nach docbook_status hat nun auch docbook_files die Versionsnummer 0.5 erreicht. Ich dachte ja, das kleine Hilfsprogramm wäre schnell abgetan, aber es findet sich doch immer ein Grund, es noch zu erweitern. Neben Administrativem (weniger Abhängigkeiten, Berücksichtigung von Windows) war der wichtigste Punkt dieser Version, das Netz der Abhängigkeiten zwischen den verschiedenen Dateien eines DocBook-Projekts genauer zu erfassen.

Das Projekt, anlässlich dessen ich docbook_files endlich mal in Angriff nahm, war in Bezug auf die Abhängigkeiten relativ einfach strukturiert. Das soll heißen jede Datei wurde nur einmal inkludiert oder referenziert. Bei den meisten Artikeln ist das so. Deswegen gab es in früheren Versionen immer nur ein Elternteil (parent) pro Datei. so konnte man für jede Datei sagen: “von dieser einen Datei wurde ich referenziert oder inkludiert”.

Bei etwas längeren oder komplizierter aufgebauten Projekten kommt es aber manchmal vor, dass ein Stück Code oder eine Abbildung mehrfach verwendet wird. In Handbüchern soll es sogar vorkommen, dass ganze Textteile mehrfach verwendet werden. docbook_files 0.5 kann nun auch damit besser umgehen. Das kann man leicht nachvollziehen, indem man sich die Liste der Datei-Details (–details) ansieht. Da gibt es nun die neuen Punkte:

• includes — Dateien, die von dieser Datei inkludiert werden
• included by — die Umkehrbeziehung, alle Dateien, die diese Datei inkludieren
• references — Dateien, die diese Datei referenziert
• referenced by — die Umkehrbeziehung, alle Dateien, die diese Datei referenzieren

Das sollte nun einen vollständigen Einblick in das Netz der Abhängigkeiten innerhalb des Textes geben. Das macht es etwas leichter, den Aufwand zu überprüfen, wenn man Dateien ändern oder löschen möchte.

Ganz nebenbei: nicht erstaunt sein, wenn diese Punkte nicht alle beim Selbstversuch erscheinen. Solche Angaben tauchen nur auf, wenn es die jeweiligen Abhängigkeiten auch tatsächlich gibt.

Für die neueste Version von docbook_status (0.5) habe ich einmal das getan, was ich schon ewig nicht mehr getan habe: eine Anwendung für Windows angepasst. Früher wäre dies wohl das erste gewesen, was man ob der Klagen getan hätte. Die Zeiten haben sich geändert, jetzt passiert das so im Nachhinein. Aber immerhin, es wurde getan.

Ein Windows-Problem war die farbliche Ausgabe, die über ANSI-Sequenzen gesteuert wird. Im XP-Terminal wurden die Sequenzen mit ausgegeben, statt sie in Farbe umzuwandeln. Um dem abzuhelfen, versucht docbook_status nun beim Start unter Windows “win32console” zu laden. Ist win32console nicht vorhanden, wird auf reine Textausgabe umgeschaltet. Wer also die Fortschrittsverfolgung von docbook_status unter Windows nutzt und es farbig mag: bitte win32console installieren! (Gibt es das Problem eigentlich auch mit Windows 7? Konnte leider nur mit einer XP-VM testen, daher die Neugier.)

Ein anderes Problem betraf nicht nur Windows, sondern auch Linux. Die Option –demon, die das Programm am Laufen hielt und bei Dateiänderungen die Analyse der DocBook-Dateien automatisch neu starten sollte, funktionierte nur unter OSX. Die eingesetzte Bibliothek war da leider nicht über die Plattformen hinweg kompatibel.

Bei der Suche nach Ersatz fand ich Guard. Das unterstützt alle drei Desktop-Plattformen, man muss nur der Anleitung für sein Betriebssystem folgen. Da der Test gut verlief, habe ich mich also dazu entschlossen, Guard zu nutzen. Guard verfügt mittlerweile über viele Zusatzmodule, die es vielseitig einsetzbar machen. Innerhalb eines Schreibprojektes kann man es zu mehr einsetzen, als nur docbook_status zu starten. Aus diesem Grund habe ich kurzerhand die Dämon-Funktionalität aus docbook_status entfernt, und ein eigenes Zusatzmodul für Guard verfasst: guard-docbook-status. Wer die Dämon-Funktionalität von docbook_status gern weiter nutzen möchte, der sollte sich das installieren.

Die Nutzung ist einfach:
[shell]
guard init docbbok-status
[/shell]
Damit erstellt Guard eine Datei namens Guardfile im Verzeichnis. In unserem Fall ist die einfach strukturiert:
[ruby]
guard ‘docbook-status’, :cli => ‘–remarks myproject.xml’ do
watch(/.+\.xml$/i)
end
[/ruby]

Das was man anpassen kann, sind die Kommndozeile für docbook_status (:cli) und eventuell der Ausdruck zur Überwachung der Verzeichnisse und Dateien (watch). Voreingestellt ist, dass alle XML-Dateien im Arbeitsverzeichnis und darunter als Auslöser für docbook_status dienen sollen — in der Annahme, dass dies alles DocBook-Dateien sind.

Startet man das Ganze mit
[shell]
guard start
[/shell]
hat man die Funktionalität der –demon Option wieder hergestellt.

Die alten Versionen von docbook_files waren etwas schwach in der Präsentation, zugegeben. Sie konnten zwar ein DocBook-Projekt auseinander nehmen, nur an der Kommunikation mit dem Benutzer haperte es etwas. Nach etwas Manöverkritik wurde die Bedienung nun vereinfacht, und die Ausgabe etwas präsentabler.

docbook_files: DocBook-Projekt in der Übersicht

Es gibt nun zwei Abschnitte, die Datei-Hierarchie und die Details. Ruft man docbook_files ohne Optionen auf, bekommt man nur die Hierarchie angezeigt, mit Option –details werden eben die Details zu den beteiligten Dateien angehängt.

Die Hierarchieanzeige wurde vereinfacht. Gezeigt werden nur noch

• die Dateien: mit Ebene und Einrückung,
• die Art der Einbindung: main: Hauptdatein, inc: inkludierte DocBook-Datei, ref: referenzierte (Medien-) Datei,
• die Dateigröße.

Erst bei den Details folgen dann Zusatzangaben wie Zeitstempel und Prüfsumme (SHA1). Können Dateien nicht gefunden werden, werden sie hervorgehoben angezeigt:

docbook_files: Anzeige fehlender Dateien

Administratives:

• Installation: sudo gem install docbook_files
• Download: rubygems.org
• Quellcode: GitHub

docbook_files: Ausgabe mit MIME Type und Größe

docbook_files 0.2.0 wurde soeben veröffentlicht (Quellcode auf GitHub). docbook_files durchforstet ein DocBook-Projekt nach inkludierten und referenzierten Dateien, und gibt das Ergebnis als Dateihierarchie mit Informationen zu den beteiligten Dateien zurück.

So ein DocBook-Projekt besteht ja normalerweise aus mehreren DocBook XML-Dateien, die zum Beispiel die einzelnen Kapitel enthalten, und der Hauptdatei, in der die Kapitel inkludiert werden. Dazu kommen noch Referenzen auf externe Dateien, beispielsweise für Medien (mediaobjects), womit Video, Audio und Bilder in das Dokument integriert werden können. Wird das Dokument etwas größer und mehren sich die Dateien, wird die Angelegenheit schnell unübersichtlich.

An dieser Stelle setzt docbook_files an.  Ausgehend von der Hauptdatei kann man sich damit den gesamten Baum der inkludierten (nur XInclude) und referenzierten Dateien ausgeben lassen. Es ist dann schnell ersichtlich, wo welche Datei benutzt wird. Über Optionen kann man sich neben dem Dateinamen auch verschiedene Eigenschaften der Dateien anzeigen lassen (Größe, Änderungsdatum, MIME, XML Namensraum usw.)

Wird eine Datei zwar referenziert, aber nicht gefunden, so wird sie in Rot dargestellt. Entweder hat man die, im Eifer des Gefechts, vergessen zu produzieren, oder einfach den Pfad falsch eingetragen.

docbook_files: Datei nicht gefunden

Okay, wieder ein Version von docbook_status. Aber damit sollte die Sache nun auch erledigt sein. Größere Änderungen gab es nicht mehr (siehe History.txt).

Wen der Quellcode interessieren sollte, der ist nun bei GitHub zu finden.

Um die möglicherweise abstrakten Integrationsszenarien von docbook_status konkret zu machen: im Folgenden ein kurzes Beispiel, um aus Textanmerkungen gleich Aufgaben zu machen. Aufgaben in einem Planer wie etwa Things von Cultured Code, das ich seit längerem nutze. Things sorgt bei mir für die Planung von einfachen Aufgaben und die Erinnerung an alle möglichen Erledigungs-Versprechungen, die ich oder andere gemacht haben. Daher dachte ich mir, es wäre doch gut, die Aufgaben, die ich in einem Schreibprojekt als Anmerkungen formuliere, gleich in Things als Aufgaben zu übernehmen.

Natürlich könnte ich das auch manuell erledigen. Die Erfahrung hat aber gezeigt, dass dabei oft einige Dinge liegen bleiben. Aufgaben, die gerade nicht im Fokus des Interesses liegen, aber erledigt werden müssen. Und an mehreren Stellen nach zu erledigenden Dingen Ausschau halten ist auch nicht schön, also lieber alles in Things hinein pumpen. Löschen kann ich die nervigeren Aufgaben da immer noch.

Mit der YAML-Ausgabe von docbook_status geht der Import der Anmerkungen glücklicherweise schnell:

[shell]
docbook_status –remarks –outputformat=yaml heft1.xml | rem2things
[/shell]

Ein Aufruf und schon erscheinen die Anmerkungen als Aufgaben in Things.

Textanmerkungen als Aufgaben in Things

Das Skript rem2things ist auch nur ein kleines Ruby-Skript, das Things über dessen AppleScript-Schnittstelle ansteuert. Wer also kein Ruby mag, kann das auch in AppleScript machen. Der Things AppleScript Guide (PDF) liefert ausführliche Beispiele um Things zu automatisieren.

Für mich selbst war AppleScript immer etwas kompliziert, daher in diesem Beispiel die Nutzung von rb-appscript, das einen Ruby-Zugang zu AppleScript-Schnittstellen von Mac-Anwendungen möglich macht. (Eine gute Einführung zur Handhabung gibt es übrigens hier.)

[ruby]
require ‘appscript’
require ‘yaml’

yaml_inp = YAML.load(STDIN)
rems = yaml_inp[:remarks]

things = Appscript.app.by_name(‘Things.app’)
unless rems.nil?
title = yaml_inp[:sections][0][:title]
rems.each do |rem|
props = {}
props[:name] = rem[:text]
props[:notes] = "#{title}, #{rem[:file]} #{rem[:line]}: #{rem[:text]}"
props[:tag_names] = "#{rem[:keyword]}"
things.make(:new => :to_do, :at => things.lists['Inbox'],
:with_properties => props)
end
end
[/ruby]

Kurz erklärt: Die YAML-Ausgabe von docbook_status wird eingelesen und in eine Struktur verwandelt. Danach wird die Things-Anwendung gesucht (Zeile 7), um mit ihr zu kommunizieren. Für jede Textanmerkung (remark) wird dann ein TODO in Things angelegt (Zeile 15).

In diesem Beispiel habe ich es mir einfach gemacht. Alle Anmerkungen werden hier in Things kopiert, ich könnte sie natürlich auch nach dem Schlüsselwort filtern, denn nicht alle Anmerkungen sind gleich wichtig. Außerdem füge ich die Aufgaben zunächst einfach in den Eingangskorb (Inbox) ein. Es wäre wohl besser ein Projekt anzulegen, und die Aufgaben dann diesem zuzuweisen.

Die Struktur der so transferierten Aufgaben ist einfach: der Anmerkungstext wird zum Aufgabentitel. Alle anderen Angaben werden im Notizen-Feld abgelegt. Als Schlagwort für die Ausgabe verwende ich derzeit einfach das Schlüsselwort der Textanmerkung. Das könnte man wohl auch verbessern.