Gelegentlich verirrte Post ist dabei nur ein Teil des Problems. Hier führte es nun zu einem Wochenende ohne Internet, weil am Freitag bei jemand ganz anderem ein Telephontechniker im Haus war und nebenbei anscheinend unseren Anschluss „korrigiert“ hat.

Und das am letzten Wochenende vor den Feiertagen, an dem es noch Hundert Dinge zu erledigen gab :-/

Grundsätzlich lassen sich viele der Diagramme auch mit Dia oder Visio erzeugen, aber mir ist eine reine LaTeX-Lösung lieber. Ich mag es nicht mit vielen externen Dateien zu hantieren, die ggf. alle nochmal mehrere Arbeitsschritte erfordern, und lege Wert darauf dass die Schriften überall einheitlich sind. Das fängt schon mit Schriftart und -größe an, aber darüber hinaus habe ich im Dokument zum Beispiel ein Makro ip{} – wenn die Diagramme Teil des LaTeX-Verarbeitung sind so ist die Textauszeichnung in Text und Diagramm immer einheitlich und ich muss mir keine Gedanken mehr darüber machen.

TikZ ist für mich auf dem richtigen Abstraktionslevel, auf dem einfache Knoten & Kanten mit einfachen Befehlen erzeugt werden können, aber darüberhinaus mit entsprechend mehr Befehlen auch kompliziertere Konstrukte möglich sind.

Das PGF/TikZ-Manual ist sehr umfangreich, enthält aber weit mehr als nur die Befehlsreferenz. Ebenso wichtig sind fünf Tutorials, die Schritt-für-Schritt die Konstruktion bestimmter Graphiken/Diagramme (Trigonometrie, Petrinetz, Geometrie, Syntaxdiagramm und Baum) erklären und schon viele Fragen beantworten. Für den ersten Einstieg gibt es zudem eine “Very minimal introduction” und es gibt viele Vorlagen in der Beispielegalerie unter TeXample.net.

In meiner Arbeit benutze ich TikZ dann konkret für einfache Funktionaufrufdiagramme und Zeit-Sequenz-Diagramme wie in den Beispielen auf dieser Seite.

Leider sind die Diagramme nicht exportierbar; das „Speichern“ erfolgt als ASCII-Diagramm im Textformat. Für meine Zwecke wäre ein direkter PDF-Export allerdings auch nicht hilfreich, denn das Tool trennt alle Nachrichtensender/-empfänger nur nach IP- (oder MAC?-) Adressen. Wenn nun Multicast-Nachrichten dazukommen (wie im Screenshot), dann werden aus zwei Rechnern leicht 10 Endpunkte. Für ein sinnvolles Nachrichten-Sequenzdiagramm bräuchte man also auch die Möglichkeit mehrere Adressen zu einem Sender/Empfänger zusammenzufassen.

Ein Python-Programm, das PyX zur Ausgabe benutzt, ist das Netzwerkpaket-Manipulationstool Scapy. Mit den Methoden psdump bzw. pdfdump lässt sich eine detaillierte Beschreibung eines Pakets ausgeben.

Die Graphik-Funktionen in Python sind dabei m. E. auf einem guten Abstraktionslevel, um einerseits generisch genug aber andererseits auch noch nachvollziehbar und editierbar zu sein. Das Beispiel rechts habe ich so mit weniger schwarzen Pfeilen zwischen Beschreibung und Rohdaten für den s/w-Druck optimiert (Doku mit Beispiel für Originalfarben).

Both techniques give the OS more control over processes and the ability to kill running applications. At first sight this looks scary and a loss of control over your computer. But it is viable for the OS to provide better resource management. Think of it as Swapping 2.0 — only instead of moving virtual memory pages to disk and back, the application is simply killed to free its memory pages.

It might get even more interesting if developers accept this new model and design their application accordingly. Then there could be quite an incentive to reduce startup times (maybe also to reduce the overall size of a process’s state and use transaction safe I/O). Finally: Recovery-Oriented Computing on the desktop :-)

Erkenntnis des ganzen: geht garnicht. Da jedes Element mit Koordinaten zu platzieren fühlt sich quasi so an als würde man Diagramme mit Pixeleditor zeichnen… Falls ich alle Bilder auf Millimeterpapier fertig vorbereitet hätte und auch sicher nichts mehr dran ändern müsste, dann wäre {picture} das geeignete Tool um sie 1:1 zu übertragen; aber sonst bitte nicht.

Geradezu lehrreich ist TeXCAD als GUI: es zeigt den Unterschied zwischen Visualisierung und Abstraktion. Ersteres ist natürlich ein nettes Gimmick (und spart mit LaTeX einige Edit-Compile-View Zyklen), bringt einen aber nicht wesentlich weiter. Eigentlich möchte ich nämlich Abstraktion, also Anweisungen wie „verbinde die Boxen mit diesem Pfeil“ und „beschrifte den Pfeil mit diesem Text“. TpX ist da weiter, denn es erlaubt das Gruppieren von Objekten (und damit gemeinsames Verschieben und Skalieren). Aber ich werde auch weiterhin einen Bogen um {picture}s machen.

Größter Vorteil: Die Eingabe erfolgt im Textformat. Allein dadurch entfällt schonmal viel Graphik-Frickelei der Sorte „die Textbox muss größer“ und „das ist aber schief“. Selbst wenn einem die Syntax nicht klar ist, sind die 2-3 plausiblen Alternativen schnell ausprobiert und die korrekte gefunden. Ein Beispiel wie das im Quelltext und Ergebnis so aussieht findet sich auf der sdedit-Projektseite.

Die GUI besteht dementsprechend nur aus einer Texteingabe und einem Vorschau des Diagramms:

Einzige Merkwürdigkeit: Es gibt mehrere PDF-Export-Funktionen. Der Button “Print or export the diagram in multi-page PDF format” funktioniert bei mir nicht gut, weil im erzeugten PDF die Schriftart nicht passt (Beschriftungen werden breiter als die dafür vorgesehenen Rahmen). Die allgemeine “Export diagram as bitmap or vector graphics”-Funktion erlaubt dann auch einen PDF-Export, aber mit 2-3 zusätzlichen Einstellungen. Mit Option “Draw text as shapes” stimmt dann auch die Schrift a) in die Rahmen und b) mit der Vorschau überein.

Once upon a time I had to extract some application data using the antiqe DDE API and send it to a webservice. Once I found the Win32::DDE::Client it was quite easy to write 200 lines of Perl for the task. Because the script should not require a Perl installation on every machine it is used on, I used the Cava Packager to put everything into an .exe file. (Now I have to extend that old script and find that Cava is no longer free, but requires a subscription for commercial use.)

In order to know my alternatives I tried the Python Win32 extensions and py2exe and these seem to be just as good (or in case of the undocumented DDE module: just as bad) as their Perl counterparts. (Py2exe is not as easy to use as Cava; but not too difficult either.)

Das Projekt rechtfertigt nicht nur digitales Messie-tum („lieber nochmal speichern“ ;-), sondern zeigt auch warum Creative-Commons-Lizenzen sinnvoll sind. Denn diese erlauben es den eigenen Fans solche Kopien und Archive legal anzulegen, während die Verlage und Verwertungsgesellschaften das ‘eigene’ kulturelle Erbe verrotten lassen und öffentlich-rechtliche Konkurrenz zum Löschen der Bestände zwingen …