Mein vielleicht wichtigstes Programmierprojekt für meine privaten Projekte und für meine Arbeit ist thelib_icon16 TheLib. Die Idee ist einfach in dieser Lib Klassen zu sammeln die wir (zwei Freunde und ich) geschreiben haben und immer und immer wieder in unterschiedlichen Projekten benutzen. Diese Klassen sind üblicherweise Wrapper um API-Aufrufe oder andere Libraries (z.B.: STL, Boost, und alle anderen) für einfachere Bedienung oder bessere Kompatibilität untereinander. Aus dieser Idee kommt auch der Name unserer Lib: TheLib – Totally Helpful Extensions (Total Hilfreiche Erweiterungen). Außerdem ist es einfach cool #include "the/exception.h" zu schreiben.

Was ich mir aber immer wieder anhören muss: „Warum schreibst Du eine Lib? Es gibt doch schon jede Menge Libs für alle Aufgaben.“

Nun, wenn das wahr wäre, dann würde keiner von uns mehr Programme schreiben, sondern wir würden alle nur noch Programme aus fertigen Libs komponieren. Das machen wir aber (noch) nicht. Zumindest, ich mache das nicht. D.h. TheLib ist tatsächlich hilfreich. Sie ist kein Ersatz für die ganzen anderen Libs, sondern nur eine Ergänzung, eine Erweiterung.

Ein Beispiel: Strings!

Die String-Funktionen in TheLib sind nicht annäherend so mächtig wie sie sein müssten um einen Texteditor zu schreiben. Sollen sie auch nicht sein. Wir haben diese Funktionen geschrieben und etwas über die Basisfunktionen hinaus zu gehen. Die Idee ist es über einfache Funktionen Anwendungen die Möglichkeiten zu geben einfach zu bedienende Benutzungsschnittstellen zu implementieren.

Vor allem unter Linux (aber auch unter Windows) gibt es im Prinzip drei unterschiedliche Typen von Strings:

  1. char * und std::string speichert ASCII oder ANSI Strings die von der lokalen Spracheinstellung des System abhängen,
  2. char * und std::string speichern Multi-Byte-Strings, z.B. im UTF-8-Format, und
  3. wchar_t * und std::wstring speichern Unicode Strings.

Je nach entsprechendem Stringtyp sind unterschiedlichen API-Aufrufe notwendig, z.B. um die Länge des Strings zu ermitteln::

  1. strlen
  2. mehrere Aufrufe von mbrlen
  3. wcslen

Ein Problem ergibt sich nun bei den Fällen 1. und 2., da moderne Linuxe oft eine Spracheinstellung benutzen welche UTF-8-Strings in den Standard-Strings ablegen. Solange strings nur geschrieben, gespeichert und dargestellt werden ist das eine tolle Möglichkeit Abwärtskompatibilität zu erhalten und einen vollen Unicode Zeichensatz zu unterstützen. Allerdings, sobald etwas komplexere Aktionen durchgeführt werden sollen (sowas wie einen Teilstring auswählen) verhalten sich Implementierungen auf diesem Ansatz fehlerhaft, da sie die UTF8-Multi-Byte-Zeichen als mehrere einzelne Zeichen interpretieren.

Beispiel:

  • Der Benutzer ist ein Geek und gibt „あlptraum“ als Eingabe ein.
  • Das System benutzt utf8-en als lokale Spracheinstellung und speichert den String in einem std::string.
  • Deine Anwendung will nur das erste Zeichen haben, z.B. um es als typographische Initialie darzustellen.
  • Der normale Ansatz ist nun char* first_char = s[0]; und std::string remaining = s.substr(1);
  • Da das japanische  „あ“ aber zwei Bytes benutzt ist das Ergebnis: „0“ + „Blptraum“

Das Problem gilt nicht nur für japanische Zeichen, sondern logischerweise potentiell für alle Zeichen die nicht im 7-Bit ASCII abgedeckt sind. Schlimmer noch: das Problem existiert für alle Operationen die zeichenweise arbeiten, z.B. auch Vergleiche ohne Berücksichtigung von Groß-Klein-Schreibung.

Beispiel wie ein String zu Kleinbuchstaben konvertiert wird:

// Zuerst machen wir es wie die STL es vorschlägt
// http://notfaq.wordpress.com/2007/08/04/cc-convert-string-to-upperlower-case/

std::string data;
// Der Inhalt von 'data' wird nun auf "あlptraum" gesetzt und das System benutzt utf8-en als Spracheinstellung

std::transform(data.begin(), data.end(), data.begin(), ::tolower);
// Und nun ist der Inhalt von 'data': "0blptraum"
// ...

Um das Problem zu vermeiden initialisiert TheLib die System-Spracheinstellung für die Anwendung und erkennt ob eine UTF-8-Einstellung benutzt wird. Ist das der Fall, dann benutzt TheLib für alle API-Aufrufe die Varianten für Multi-Byte-Strings und die Ergebnisse entsprechen der Erwartung. Zusätzlich bietet TheLib explizite Funktionen zur Konvertierung nach und von UTF-8-Strings (z.B. für Dateizugriffe).

Natürlich braucht man TheLib nicht und das Problem zu lösen. Es gibt andere Libs (vermutlich. Ich kenne nur die IBM-Unicode-Lib, aber die scheint mir ein riesiges Ding zu sein) oder man kann sich selber Workarounds schreiben oder man ignoriert das Problem, weil es bei „den eigenen Anwendungsfällen nicht auftreten wird“. Wie dem auch sei, die TheLib das einfach machen zu lassen ist einfach praktisch. Mehr ist da nicht dahinter.

Software sollte dazu dienen Probleme zu lösen. Manchmal ist das auch so.

Ich hatte ein Problem:

Ich habe ein etwas älteres Convertible Laptop, ein ASUS Aspire 1820PT. Seinerzeit ein gutes, günstiges Convertible mit Touch-Screen-Unterstützung für zwei Finger und einer akzeptablen Rechenleistung. Inzwischen hab ich das gute Stück mit einer SSD verfeinert und betreibe es mit Windows 8. Soweit so gut. Das Problem, jedoch, ist, dass der Lagesensor von Windows 8 nicht mehr unterstützt wird. :-(

Also musste eine Lösung her: Treiber-Hacking oder am Ende noch einen Treiber selber schreiben ist nicht meins. Ich bin Anwendungsprogrammierer. Wenn etwas automatisch nicht (mehr) funktioniert, dann muss man eben die manuelle Bedienung so komfortable wie möglich machen. Daher habe ich mir ein kleines Tool geschrieben: den DisplayRotator.

DisplayRotatorScreenDie Idee ist ganz einfach: Das Tool wird in der TaskBar angeheftet und zeigt sobald es gestartet wird ein Fenster mit den vier möglichen Displayausrichtungen an. Drück man auf den entsprechenden Button, so wird das Display entsprechend eingestellt. Damit kann ich den Desktop auf meinem Convertible mit zwei Clicks, bzw. besser mit zweimaligem Finger-Tippen wieder so hin drehen wie ich es brauche.

DisplayRotator.zipDisplayRotator.zip Display Rotation Tool
[152 KB; MD5: 07c3efddd05a98bf4d02db595b87f2fe; Mehr Info]

Und, weil ich es kann ist auch der Quelltext des Tools offen. Es ist in C# geschrieben und benutzt logischerweise die Windows API zum Ändern der Displayeinstellungen. Eigentlich alles ganz einfach. Auf der gleichen Code-Basis lassen sich auch Bildschrimauflösungen und Wiederholfrequenzen einstellen, und es ist sogar möglich Monitore vom Desktop zu trennen, bzw. zu verbinden. Ok, der Code für die ganzen Funktionen ist nicht drin, aber die API-Aufrufe sind die gleichen.

Vielleicht kann das Tool ja auch noch für jemand außer mir nützlich sein.

Ich arbeite sehr gerne an einer Universität. Ich löse gerne Probleme die noch keine Lösung haben. Ich verbessere gerne bestehende Lösungen. Ich arbeite gerne in meine eigenen Richtungen. Ich arbeite gerne mit Studenten. Ich betreue gerne Studenten bei ihren Arbeiten. Ich halte sogar gerne Lehrveranstaltungen ab.

Was ich aber, zumindest augenblicklich, überhaupt gar nicht gerne mache, ist meine wissenschaftlichen Ergebnisse zu publizieren, was natürlich die Hauptsache bei der Verfolgung einer wissenschaftlichen Karriere ist. Dieser Prozess ist augenblicklich furchtbar, ermüdent und frustrierend.

Ich habe dieses Jahr sechs Artikel geschrieben, jedes mal mit viel Arbeit in der Vorbereitung und für die Präsentation, und ich werde dieses Jahr *keinen einzigen* davon mehr publiziert kriegen. Nicht einen. Ein so schlechtes Jahr wie 2013 hatte ich noch nie. Für eine wissenschaftliche Karriere ist das in meinem Alter realistisch gesehen ein Todesstoß.

Das ist natürlich nicht schön, aber was mich vor allem frustriert sind die Reviews mit denen meine Arbeiten abgelehnt wurden. Bei den nummerischen Bewertungen (1 = schlechteste, 5 = beste Note) hat eines meiner Paper z.B.: 4 + 4 + 3 + 3. Auch die Reviewer Kommentare sind leider sehr oft unprofessionell, nutzlos und polemisch. Ein anderes Paper wurde von 2 von 4 Reviewer in höchsten Tönen gelobt. Ein dritter fand es ok, wollte aber einige Überarbeitungen. Jedoch hat dann der Haupt-Reviewer etwas geschrieben was ich nur als „Ich mag es nicht.“ interpretieren kann, und was auch etwa diesen Inhaltswert hat. Ergebnis: abgelehnt.

Ich hatte mich schon früher mit mehreren Professoren über das Problem einer überkritischen Review-Community unterhalten. Alle waren sich einig, dass es dieses Problem gibt und dass das immer mal wieder in den wissenschaftlichen Communities aufkommt. Leider habe ich das Gefühl, dass es sich in den sieben Jahren die ich jetzt wissenschaftlich arbeite und publiziere (außer dieses Jahr) immer weiter verschlimmert. Ganz ehrlich, ich weiß nicht was werden wird …

Punkte sind nicht gleich Punkte. Immer wieder gibt es fundamentale Missverständnisse über die Art der Daten mit denen ich in meiner Visualisierungsforschung arbeite.

Ich arbeite mit Partikeldaten. Üblicherweise werden diese von Simulationen erzeugt, z.B. nach der Methode der Molekulardynamik oder der Diskreten-Element-Methode. Die einzelnen Partikel stellen eigenständige Elemente dar, z.B. Atome oder Massepartikel, die untereinander zunächst keinerlei Beziehung haben, weder Verbindungen noch Beeinflussungen. Natürlich, beeinflussen sich die Partikel gegenseitig in der Simulation, aber die reinen Daten die mir für die Visualisierung vorliegen haben keinerlei topologische Strukturinformation in dieser Hinsicht. Die Literatur hat noch weitere Namen für diese Art von Daten: point-based data, mesh-less data oder, vielleicht noch am ehesten passend, scattered data. Technisch gesprochen sind diese Daten eine beliebig sortierte Liste von Elementen, welches jeweils eine Position und weitere Attribute besitzt. Die zusätzlichen Attribute geben dann z.B. noch einen Kugelradius oder eine Farbe an. Aber, das ist dann alles. Es gibt nicht mehr Informationen und man kann keine weiteren Annahmen treffen.

bunnyPSP-OSSNun zu einem sehr häufigen Missverständnis: Es gibt auch den Datentype der point clouds oder point-set surfaces. Diese bezeichnen ebenfalls Daten die eine Liste von zunächst unkorrellierten Punkten abspeichern. Dies stammen üblicherweise aus Punkt-basierter Modellierung in der 3D Computer Graphik oder hauptsächlich aber als Scans realer Objekte, beispielsweise durch Laserscanner, aber auch Structured-Light-Scanner wie die Kinect. Die Tatsache, dass es sich auch um eine einfache Liste von Punkten handelt, technisch praktisch identisch zu den Partikeldaten, führt dazu, dass immer wieder Leute der Meinung sind, dass die beiden Datentypen identisch wären. Das sind sie nicht.

Point Clouds sind diskrete Abtastungen einer kontinuierlichen Funktionen, nämlich der darunterliegenden Fläche des modellierten oder realen Objekts. Sprich die Positionen der Punkte liegen innerhalb kleiner Fehlerschranken auf eben dieser 2D Fläche eingebettet im 3D Raum. Dieser Aspekt ist fundamental anders als bei Partikeldaten, welche sich völlig frei im 3D Raum positionieren. Praktisch alle Algorithmen die mit Point Clouds arbeiten ziehen ihre Motivation aus diesem Aspekt der darunterliegenden Fläche. Aus genau diesem Grund ist es nicht möglich diese Algorithmen direkt auf Partikeldaten anzuwenden.

Tja. Offensichtlich habe ich immer noch nicht genug publiziert um diesen Unterschied bei meinen Fachkollegen klar zu machen. Dann will ich mal …

Kleine Tools schreibe ich seit mehreren Jahren sehr gerne in C#. Die Sprache ist schön und das Framework ist mächtig. Plattformunabhängigkeit ist mir in diesem Zusammenhang egal. Mono auch. Ich bin auch großer Fan von Windows Forms. Es ist ein sehr schönes und mächtiges GUI Toolkit, nahe an der klassischen C++-Welt aber mit guten Abstraktionen an den richtigen Stellen. Und dann gibt es natürlich noch WPF.

Mir ist nicht klar, was ich von WPF halten soll.

Einerseits, sagt Microsoft WPF ist die Zukunft. Viele neue Funktionen kommen (zuerst) in WPF und teilweise nie in Windows Forms. Windows 8 Apps und Windows Phone Apps benutzen ausschließlich WPF für die GUI Toolkits. Das Data-Binding ist sehr schön und sauber integriert, im Vergleich zu Windows Forms.

Andererseits ist WPF halt auch keine perfekte Lösung. Die Performance ist bei umfangreichen GUIs oder bei komplexen Selbstbauten nicht gerade gut. Der Editor im Visual Studio ist auch nur semi-cool. (Ok, es gibt Expression Blend, aber irgendwie finde ich es nicht gut ein Projekt in zwei Editoren gleichzeitig zu bearbeiten.)

Was mich allerdings wirklich in’s Grübel bringt, ist das Microsoft selbst ja auch keine klare Linie hier verfolgt. Visual Studio 2012 ist in WPF geschrieben worden und für Apps ist die API Pflicht. Allerdings ist das neue Office, obwohl optisch dem neuen Metro-Design folgend, nicht in WPF geschrieben, sondern mit klassischen GUI Toolkits. Insgesamt, weiß ich wirklich nicht, auf welches Pferd ich setzen soll. Vermutlich ist es einfach egal, aber trotzdem bin ich mit der Situation nicht zufrieden.