Monthly Archives: July 2008

Tiefenanordnung von Linien in Matlab-Plots

Heute geht es mal um ein sehr spezielles Problem mit einer Lösung auf die ich gestern durch Probieren gekommen bin und sehr erstaunt war, dass das so funktioniert und offenbar sogar so vorgesehen ist. Zunächst ein paar Worte zum ursprünglichen Problem.

Ich arbeite im Institut mit Matlab 6.1, zwar schon etwas in die Jahre gekommen aber brauchbar. Für die Auswertung meiner Messdaten habe ich ein GUI programmiert wo ich zwei verschiedene Sachen gleichzeitig in einem axes-Objekt darstellen will. Normalerweise kann man hier mit den Funktionen hold und plot arbeiten, aber mir war das zu unflexibel und ich habe daher gleich die LowLevel-Funktionen benutzt. Ich habe in dem GUI das gewünschte axes-Objekt. Direkt darunter in der Objekthierarchie kommen bereits die line-Objekte, die auch plot erzeugt. Von Hand kann man sich die mit dem Befehl line erzeugen, die landen dann in dem aktuellen axes-Objekt, das man zuvor mit axes(axeshandle) festlegen sollte. Bei der Erzeugung der line-Objekte speichere ich das line-Handle um später direkt wieder drauf zugreifen und beispielsweise die zugrundeliegenden Daten ändern zu können.

Soweit so gut, nun ist es so, dass ich nicht bestimmen kann, wann der Benutzer die eine Sache zum Plotten anklickt und wann die andere. Oben erscheint aber immer die zuletzt gewählte. Genauso verhält sich der Befehl plot. Was zuerst geplottet wird, landet hinten, die nachfolgenden Sachen darüber. Das ist bei vielen Darstellungen egal, bei einigen aber nicht.

Der Trick um die Darstellungsreihenfolge – oder englisch z-Order – zu ändern klingt ein wenig wie »von hinten durch die Brust ins Auge«, funktioniert aber wunderbar. Um zu verstehen, was dort gemacht werden muss, schaut man sich am besten nochmal die Objekthierarchie an. Ein axes-Objekt beherbergt beliebig viele line-Objekte. Die Handles dieser Objekte kann man sich ausgeben lassen:

linehandles = get(gca, 'Children')

Die einzelnen Elemente des Vektors linehandles haben genau die Reihenfolge der Anordnung in z-Richtung wobei das erste Element das zu oberst angezeigte ist. Es spricht nichts dagegen, die Elemente umzuordnen und dem axes-Objekt wieder zuzuweisen, z.B. in umgekehrter Reihenfolge:

set(gca, 'Children', flipud(get(gca, 'Children')))

Ich war einigermaßen überrascht, dass das tatsächlich so funktioniert, da ich in der ausführlichen Matlab-Hilfe nie darüber gestolpert bin. Dass das wirklich so vorgesehen ist, sagt einem Matlab selbst, wenn man versucht der Eigenschaft Children etwas anderes als ein umgeordnetes selbst zuzuweisen:

??? Error using ==> set
Children may only be set to a permutation of itself.

Damit das ganze noch ein wenig anschaulicher wird, habe ich noch ein kleines Skript geschrieben, dass die Sache nochmal illustriert:

% test data
a = rand(5,1)
b = rand(5,1)
c = rand(5,1)
% line handles
hp = plot([a b c])                  % hp in order we plotted
ha = get(gca, 'Children')           % reverse order
% vectors of line handles equal?
all(hp==ha)                         % not equal
all(hp==flipud(ha))                 % should be equal, see above
all(sort(hp)==sort(ha))             % also equal
% thick lines
set(ha, 'LineWidth', 10)
title('original order')
legend('a','b','c')                 % order as in plot call
print(gcf, '-dpng', 'z-order-original.png')
% color of the most front line, should be c
get(ha(1), 'Color')                 % should be red aka [1 0 0]
% now flip lines, put c in the back
set(gca, 'Children', [ha(2) ha(3) ha(1)])
title('flipped order')
print(gcf, '-dpng', 'z-order-flipped.png')
% color of the most front line, should be b
ha = get(gca, 'Children')
get(ha(1), 'Color')                 % should be green aka [0 0.5 0]

Schaut man sich hier die erzeugten PNG-Bilder an, erkennt man, dass die Linie für die Datenreihe c zunächst ganz vorn und dann ganz hinten dargestellt wird:

Alte Revisionen wiederherstellen mit Subversion

Im täglichen Umgang mit Subversion passiert es, dass man Dateien eincheckt, die man dann doch eigentlich nicht commiten wollte. Zum Glück kann man alte Revisionen wiederherstellen, dafür hat man ja das Versionsverwaltungssystem, man muss nur wissen wie.

Die erste Idee: revert – das funktioniert nicht, weil revert nur Änderungen an der lokalen Working Copy rückgängig macht, nach dem Commit kann revert nichts mehr ausrichten.

Die zweite Idee: update auf die ursprüngliche Version. Dann hat man in der Working Copy zwar zunächst mal die alte Version liegen. Man kann sie aber nich direkt commiten, weil Subversion sie für aktuell hält. Das ist sie im Grunde auch, nur halt in einer vorherigen Revision. Lokale Änderungen gibt es in dem Sinne nicht an der Datei. Bei Binärdateien kommt man an dieser Stelle nicht weiter, wenn man nicht jedesmal wieder ein update auf die alte Revision machen will.

Die dritte Idee: ins Handbuch schauen. Das exzellente Subversion-Buch hat natürlich auch zu dieser Problematik die passenden Tipps parat: Undoing Changes. (Wir arbeiten hier noch mit Subversion 1.4, daher der Link ins »alte« Buch.) Was auf den ersten Blick überraschend klingt: merge ist die Lösung für das Problem. Der Trick ist, dass wir dieses Mal rückwärts mergen. Dadurch gelangt die ältere Revision wieder in die Working Copy und nachdem man kontrolliert hat, ob damit alles stimmt, kann man die erneut commiten.

Genug der Vorrede, ich zeige den Vorgang mit dem Kommandozeilen-Client und mit TortoiseSVN am Beispiel. Ich habe hier eine Binärdatei driftcompgui.fig, die ich zuletzt in Revision 297 korrekt eingecheckt habe. In Revision 300 habe ich versehentlich eine falsche Version der Datei eingecheckt und möchte jetzt wieder die Version aus Revision 297 haben. Auf der Kommandozeile sieht das recht einfach aus (mit anschließendem Screenshot der Ausgaben):

svn merge -c -300 driftcompgui.fig

Wie man sieht liegt die Datei nun geändert in der Working Copy und zwar in der gleichen Version wie in Revision 297. Jetzt kann man die so einchecken oder noch weiter damit arbeiten. Bei TortoiseSVN erschließt sich diese Funktion aus dem GUI eher überhaupt nicht. Ich zeige zunächst mal den entscheidenden Screenshot und erkläre dann nochmal:

Hier wählt man zunächst im Feld »From:« die gewünschte Datei aus und klickt »HEAD Revision« an. Das ist sozusagen der Startpunkt des Rückwärts mergens. Bei »To:« natürlich »Use “From:” URL« auswählen, da es um die selbe eine Datei geht. Als Ziel Revision gibt man hier die an, die man wiederherstellen will, in meinem Fall 297. Jetzt kann man ohne weiteres auf »Merge« klicken und dann die Datei in der Working Copy untersuchen. Sollte irgendetwas nicht stimmen, kommt man mit revert wieder zur HEAD Revision, da wie bei jedem anderen Merge kein automatischer Commit passiert sondern die Änderungen des merge nur in der Working Copy landen. Wenn alles ok ist, kann man commiten und hat danach wieder die alte Version der Datei im HEAD des Repository.

Keys für Upgrade auf WordPress 2.6

Gestern kam mal wieder ein neues Update für WordPress. Wir setzen hier die DE-Edition ein und da gibt es auch eine detaillierte Anleitung zum Upgrade. Dort wird einem verraten, dass es für WordPress 2.6 neue Variablen in der Datei wp-config.php gibt. Der entsprechende Abschnitt in der wp-config-sample.php sieht so aus:

// Ändere jeden SECRET_KEY in eine beliebiege, möglichst einzigartige Phrase. Du brauchst dich später
// nicht mehr daran erinnern, also mache sie am besten möglichst lang und kompliziert.
// Auf der Seite https://www.grc.com/passwords.htm kannst du dir einen Ausdruck generieren lassen.
// Bitte trage für jeden SECRET_KEY eine eigene Phrase ein.
define('AUTH_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.
define('SECURE_AUTH_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.
define('LOGGED_IN_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.

Jetzt ist da eine Seite angegeben, auf der man sich diese Keys erzeugen lassen kann. Das ist für den DAU ganz nett, aber schrieb nicht fefe gerade die Tage:

Man sollte denken, niemand könnte je so unglaublich dämlich sein, sich einen Krypto-Schlüssel von jemand anderem generieren zu lassen

Glücklicherweise gibt es ja noch mehr Möglichkeiten zufällige Zeichenketten zu erzeugen. Eine davon habe ich vor einigen Monaten im Beitrag Kleiner Passwortgenerator in Perl vorgestellt. Was der Beitrag verschweigt: Ich hatte wenige Tage später noch eine kleine Anpassung an dem Skript vorgenommen, die es erlaubt, beim Aufruf die Anzahl der zurückzugebenden Zeichen als Parameter zu übergeben. So war es ein leichtes die nötigen Keys für die Konfigurationsdatei von WordPress zu generieren:

perl genpasswd.pl 64

Das veränderte Skript ist jetzt übrigens auch über Penguineering Tools abrufbar.

CLI siegt

Spontane Erkenntnis: Ich nutze lieber den Kommandozeilenclient als die Shell-Extension im Kontextmenü – jedenfalls wenn es um Subversion geht. Gerade Routineaufgaben wir update und commit gehen damit einfach schneller.

Mögliche Erklärung: In der KDE kommt man aus dem Dateimanager per F4 in ein Konsolenfenster mit dem aktuellen Verzeichnis. Dort muss ich dann nur noch svn up eingeben, mit das Ergebnis anschauen und die Konsole mit Strg+D wieder schließen. Das geht wesentlich schneller, als mit der Maus im Kontextmenü die entsprechende Option zu suchen.

Die HCI-Community spricht hierbei von habit, also der Gewohnheit beziehungsweise Routine. Während man bei der Mausbedienung zuerst den Mauszeiger suchen muss, um ihn dann auf die richtige Position im Dateimanager und im Kontextmenü zu navigieren, ist die Position der Tasten fest, die Tastaturbedienung bedarf also wesentlich weniger Planung und fördert daher eher ein routiniertes Vorgehen. Letztendlich entlastet das das Gehirn und wird deshalb als energiesparende Maßnahme bevorzugt. Aber wer gern Shortcuts benutzt, kennt das ja … 8)

Nachtrag: Da war ich wohl etwas eilig und hab die Abkürzungen nicht erklärt…

CLI = Command Line Interface; eine Form von Kommandozeile, entweder auf der Konsole oder in ein Programm eingebettet.

HCI = Human-Computer-Interaction oder Human-Computer-Interface, also die Schnittstelle beziehungsweise Interaktion zwischen Mensch und Computer.

irssi-Hilight mit Jabber

Seit einigen Jahren läuft in meiner Screen-Session neben ICQ und anderen Tools auch ein irssi, um mich mit der Welt des IRC zu verbinden. In den meisten Channels bin ich einfach nur anwesend, gelegentlich spricht mich dann aber doch jemand an. Dank hilight im irssi wird man darüber ja eigentlich informiert. Nur leider schaue ich viel zu selten in das irssi-Fenster, um das dann letztendlich auch zu sehen. (Ja, screen informiert ueber Pings in anderen Fenstern, aber da guck ich doch erst Recht nicht hin …)

Da irssi eine schicke Perl-API hat, liegt es doch nahe, ein Perl-Script zu schreiben, mit dessen Hilfe ich mich anderweitig informieren lassen kann. Sehr nahe liegt da der Instant Messenger, der sowieso immer läuft, wenn ich am Rechner sitze – konkret Jabber.

Mit dem Perl-Modul Net::Jabber ist das alles kein Problem (abgesehen von den lückenhaften Dokumentationen, insbesondere in der irssi API) und so gibt es nun das Script irssi2jabber.pl, das als irssi-Script geladen werden kann und mir nun bei jedem Hilight oder jeder privaten Nachricht, die auftreten, während ich /away bin, eine Nachricht an meinen Jabber-Account schicken.

Das Script ist etwas kommentiert, die notwendigen Einstellungen stehen ganz am Anfang und müssen in die irssi-Config. Unter der GPLv3 darf es jeder weiterverwenden, natürlich nehme ich auch Patches an, die, wenn sie nützlich sind, eingepflegt werden.

Kalendertool gesucht

Ich vermisse es mal wieder: Mein Wunschkalendertool.

Folgende Eigenschaften soll es haben:

  • Frontend im Stil vom Google-Kalender. Erreichbar über jeden Browser.
  • Verfügbare Software, die ich auf meinem eigenen Server installieren kann und die mir alleinige Kontrolle über meine Daten gibt.
  • Das Backend kann Kalenderdaten in IMAP-Foldern verwalten. Das ist meine derzeitige Speicherform, die den Vorteil hat, dass ich kein zusätzliches LDAP- oder DAV-System installieren muss, sondern einfach mein E-Mail-Postfach verwenden kann.
  • Kostenlos und OpenSource.
  • Optional: Eine schicke API, mit der ich ggf. auch andere Tools wie z.B. einen Reminder anbinden kann. Das muss aber nicht sein, weil die Daten ja auch schon im IMAP-Folder gut lesbar vorliegen.

Sachdienliche Hinweise bitte in die Kommentare oder per Nachricht an mich.

Security by Obscurity

Im April hatte ich über die Sicherheitslücke in Chipkarten des Typs Mifare Classic geschrieben, die auch als Studentenausweis an der Uni Magdeburg dienen. Der Hersteller InterCard hatte Anfang April angekündigt sich zügig mit seinen Kunden in Verbindung zu setzen. Davon hat man hier an der Uni bisher nichts gemerkt.

Unabhängig davon ist heute bekannt geworden, dass NXP, der Hersteller der Chips, eine niederländische Universität verklagt hat, damit die keine Paper zu der Thematik veröffentlichen. Fefe schreibt dazu:

Das sagt mir persönlich ja immer alles, was ich über eine Firma wissen muß, wenn die ihre Sicherheitslücken nicht fixen und dazu stehen sondern den Boten unter Beschuß nehmen.

Ich frage mich, wie die sich das vorstellen. Die Niederländer sind ja lange nicht die einzigen, die Details zu der Sicherheitslücke veröffentlicht haben. Da gab’s einen Vortrag auf dem 24C3, die c’t hat lang und breit drüber berichtet und all diese Informationen sind seit über einem halben Jahr öffentlich, lange genug Zeit also für böse Buben sich da schlau zu machen und das Wissen zu speichern. Viel interessanter ist die Frage, wie sie die bestehenden Systeme absichern oder auf neue Systeme migrieren wollen. Wäre glatt mal interessant beim hiesigen Studentenwerk anzufragen, ob der Hersteller schon Kontakt aufgenommen hat und was da möglicherweise hinsichtlich neuer Karten o.ä. geplant ist.

Penguineering

Penguineering ist ein Kunstwort, das aus penguin und engineering zusammengesetzt ist. Die Idee stammt von einer Freundin, die mir dieses Wort freundlicherweise überlassen hat, sodass ich mir gleich mal die Domain penguineering.com reservieren konnte.

Seit gestern Abend ist unter http://tools.penguineering.com eine Sammlung von Tools zu finden, die in einzelner oder gemeinsamer Arbeit der Blog-Autoren entstanden sind und allgemein verfügbar sein sollen.

Die Seite sieht noch etwas mager aus, aber das wird sich im Lauf der Zeit ändern.

Windows Vista: Auf der Höhe der Zeit?

Bei unserem Zeitabgleich zwecks Mensabesuch fiel mir vorhin auf, dass die Systemuhr meines Vista-Systems (das ist unfreiwillig nutze) mal wieder einige Minuten nachgeht. Normalerweise merke ich so etwas nicht, die lokalen Dienste stören sich nicht daran, bei Terminen ist der Griff nach dem Handy gewohnter und direkt zeitkritische Dinge tu ich auf dem Rechner nicht.

Trotzdem stellte sich dann die Frage: Was tun, um diese Situation in Zukunft ohne Mehraufwand zu verhindern? Seit XP kann sich auch Windows mit öffentlich verfügbaren Zeitservern synchronisieren. Das scheitert im Netz der Uni Magdeburg aber daran, dass das Rechenzentrum sehr restriktiv bei der Freigabe von Ports ist und NTP schlichtweg nicht funktioniert. Vista bestätigt das mit der lapidaren Meldung, dass irgendwo ein Fehler aufgetreten sei. Eine Möglichkeit, auf unprivilegierte Ports auszuweichen, gibt es nicht.

Zum Glück gibt es an der FIN einen eigenen Zeitserver (herkules.cs.uni-magdeburg.de), der sich für solche Zwecke einspannen lässt; mit diesem läuft es dann jetzt. Sonst hätte ich auf das Feature wohl verzichten müssen. Eine spontane Google-Suche nach Tools zur Zeitsynchronisierung unter Vista hat mich jedenfalls nur auf Seiten geleitet, die die Lösung mit bordeigenen Mitteln beschreiben.

Indirekter SPAM

Das Antiblau-Blog war heute zeitweise nicht erreichbar, gemeinsam mit einigen anderen Diensten, die auf diesem Server laufen.

Grund ist eine indirekte SPAM-Attacke: Irgend jemand hat heute morgen eine meiner E-Mail-Adressen als Absender für eine größere Menge von SPAM-E-Mails missbraucht. Der Effekt war, dass der Server mit failure notice-Nachrichten bombardiert wurde – insgesamt ca. 8000 Stück.

Das fiese an so einer Attacke: Das findet wohl kein SPAM-Filter. Die Fehlerbenachrichtigungen sind korrekte und unverdächtige E-Mails, lediglich ihre Anzahl ist ungewöhnlich. Hier kann wohl nur eine konsequente Umsetzung diverser Anti-Spam-Maßnahmen wie z.B. Absenderverifikation helfen.

Aber bis es soweit ist, kann ich wohl nur versuchen, die Erkennungsmaßnahmen zu optimieren und einzelne Parameter so zu tunen, dass viele E-Mails den Server nicht mehr in die Knie zwingen.

Ideen sind an dieser Stelle oder direkt an mich natürlich immer willkommen!