Augenblicklich versuche ich meine privaten Softwareprojekte zu sortieren, zu organisieren und zu priorisieren. Springerjagd ist mir gerade vermutlich das wichtigste, auch wenn sich vermutlich sonst niemand dafür interessiert. Mir egal.

Darum konzentriere ich jetzt meine Programmierfreizeit auf dieses Projekt. Als ersten Schritt habe ich mal die Webseiten-Titelseite überarbeitet: springerjagd.net

Bald mehr …

Es wird mal wieder Zeit für ein kleines Software-Tool das die Welt nicht braucht (ich aber schon). Die Idee ist ganz einfach: Serien von Dateien, z.B. Musikdateien eines Hörbuchs oder Videodateien einer Serie, in einem Verzeichnis. Immer wieder schaut/hört man eine Datei an und fragt sich dann beim nächsten Mal wieder, wo war ich eigentlich. Mein kleines Tool registriert sich im Kontextmenu des Windows Explorers und erlaubt so ganz einfach in einem Verzeichnis ein Lesezeichen zu setzen. Das Lesezeichen ist schlicht eine leere Datei mit dem gleichen Namen wie die markierte Datei (zusätzlich der extra Dateinamenerweiterung). Das ganze ist keine Shell-Extension, sondern nur eine ganz normal DotNet-Anwendung die sich an den richtigen Stellen in die Registry einträgt. Einfach, sicherlich nicht sonderlich elegant, erfüllt aber seinen Zweck.

FileBookmark.zipFileBookmark.zip File Bookmark Utility
[91.2 KB; MD5: bd58a615775c9897ae82536bb678b05b; Mehr Info]

Und, weil ich es kann, gibt es außerdem auch den dazugehörigen Quellcode:

FileBookmark_src.zipFileBookmark_src.zip File Bookmark Utility Source Code
[60.2 KB; MD5: 84071f778ccb81b0c39101577a3fa204; Mehr Info]

Ok, ok, ich weiß, das Jahr ist noch nicht ganz vorüber, aber es ist jetzt der letzte Sonntag 2013 und daher Zeit für einen Post zum Ende des Jahres.

Jahresrückblicke sind etwas furchtbares, vor allem wenn das Jahr gar nicht so richtig gut war. Naja. Wirklich schlecht war es auch nicht, aber es hätte schon noch deutlich viel besser sein können. Immerhin gab es kurz vor Weihnachten noch eine angenehme Überraschung (mehr dazu werde ich aber wohl erst im neuen Jahr schreiben).

Nun wird es Zeit den Blick in die Zukunft zu richten. Für 2014 Pläne zu schmieden und deren Verwirklichung anzugehen. Beruflich kommt jetzt einiges ins Rollen und ich bin gespannt was davon auch erfolgreich sein wird. Dazu will ich aber auch noch nicht mehr schreiben. Nur so viel, ich habe Ideen für unterschiedliche Publikationen und Förderanträge. Wenn genug davon auch wirklich klappt, dann bleibt die Wissenschaft für mich interessant.

Was meine privaten Programmier-Projekte betrifft, so ist bisher nicht sehr viel passiert; und das ist noch übertrieben. Mal sehen wie es an der Front weitergehen wird.

Nun wünsche ich allen aber zunächst einmal einen guten Rutsch ins neue Jahr!

So, es passiert nicht viel für meine Webseite. Überraschend wie jedes Jahr auf’s neue kommt Weihnachten um die Ecke.

Daher wünsche ich euch einfach schon einmal: Frohe Weihnachten!

(P.S.: Ja, ich bin bekennender LEGO-Fan)

Die deutsche Forschungslandschaft ist in vielerlei Hinsicht problematisch. Diese Woche hatte ich eine schöne Diskussion mit einem Kollegen, dass Forschung, so wie sie augenblicklich betrieben wird, keine Probleme lösen kann. Jeder Forscher ist nur auf der Jagd nach Geld, bzw., die ambitionierten sind auf der Jagd nach einer Festanstellung. Dabei werden so schnell wie möglich so viele Paper wie möglich produziert um die eigene wissenschaftliche Exzellenz zu zeigen. Als Ergebnis dieser Arbeitsweise wird kein einziges der angegangenen Probleme wirklich vollständig gelöst. Immer klammert man alle Sonderfälle aus und zeigt in den Arbeiten sowieso nur die Daten die am besten funktioniert haben; weder repräsentativ noch vollständig. Aber es wird publiziert. Damit sieht die Forschungsgemeinschaft das entsprechende Problem als gelöst an. Gekniffen sind die Doktoranden und Forscher, die diese „Lösung“ einsetzen wollen und dann auf die ganzen Probleme stoßen. Will man „nur“ weiterforschen, so ist das egal. Man ignoriert einfach wieder alle Sonderfälle und Probleme. Will man damit aber arbeiten, so hat man halt Pech. Die viele Arbeite die man investieren muss, damit das ganze wirklich tut, dankt einem niemand. Da die Forschungsgemeinschaft das Problem ja als gelöst ansieht, kann man eine funktionstüchtige Lösung nicht publizieren. Damit ist man als Wissenschaftler gezwungen immer mit unfertigen 1/4s-Lösungen zu arbeiten.

Und was ist mit der Industrie? Die könnte doch die Implementierungen fixen. … Warum sollte sie? Die Industrie baut ihre einen Lösungen, genau auf ihre Probleme zugeschnitten. An allgemeinen oder übertragbaren Ergebnissen, die einer breiten Gemeinschaft zur Verfügung stehen sollten hat die Industrie, völlig zurecht, kein Interesse.

Diese Sicht bezieht sich natürlich ausschließlich auf die Forschungsarbeit die ich um mich herum sehe, also in der Informatik. Ich hoffe, dass andere Disziplinen besser arbeiten.

Wie geht es dann weiter? … Naja, so wie bisher eben auch. Es gibt keine Lösungen, sondern es wird nur unendlich lange Geld verbraucht.

Dieses Wintersemster besuche ich eine Vorlesung von Dr. Frank Furrer zum Thema Future Proof Software Systems. Sehr interessantes Thema und eine tolle Vorlesung. Neben der eigentlichen Vorlesung nutze ich die Gelegenheit auch im mit Dr. Furrer Themen zu diskutieren die in meinem persönlichen Forschungsfeld liegen. Dabei kommen schöne Weisheiten vervor. Beispielsweise die Entwicklungsstadien eines Software-Architekten:

  1. Der Software-Architekt wird ignoriert.
    Tatsächlich bin ich noch immer in dieser Stufe.
  2. Man nimmt dem Software-Architekten seinen Schlüssel weg und ändert die Passwörter seiner Zugangsdaten.
    Soweit bin ich noch nicht.
  3. Der Software-Architekt wird in einer dunklen Gasse erschossen.
    . . .

*seufz*

(Artikelbild-Quelle)

Letzte Woche hab ich schon über Legacy-Code geschrieben. Das Thema ist beständig.

Eigentlich gibt es zwei Sichtweise auf Legacy-Code:

  1. Die Einen halten Legacy-Code für einen Schrotthaufen den man unbedingt los werden muss.
  2. Die Anderen halten Legacy-Code für eine Goldgrube die man unbedingt nutzbar machen muss.

Die Wahrheit ist nicht, wie so oft, irgendwo dazwischen, sondern schlicht und ergereifend: beides ist wahr! Legacy-Code ist ein Schrotthaufen voller Gold! Das Gold muss man nutzbar machen und den Schrott muss man los werden. Das ist natürlich aufwändig und so darf man nicht gierig werden. Mit jedem Projekt sollte man ein kleines bisschen Schrott los werden und ein kleines bisschen Gold freilegen. So wird mit der Zeit alles gut.

Für die TheLib haben wir dieses Problem natürlich auch! Um die „kleinen Schritte“ durchzuführen, von denen ich grad geschrieben habe, haben wir das Projekt the.vislib.legacy gestartet.

Immer wenn man an einer Software arbeitet die nicht trivial oder klein ist, dann arbeitet man unweigerlich auch mit Legacy-Code. Damit meine ich Quelltexte die alt sind. Entweder will man sie ersetzen oder auch nicht, aber sie mit dem neu entstehenden Code zu verheiraten ist nie einfach. Im Besonderen, wenn man Interfaces nach außen hat, z.B. zu anderer Software, welche zumindest Teile der eigenen Software benutzt. Bei solchen Aufgaben zeigt sich, ob man sein Handwerk versteht. Damit meine ich nicht programmieren. Das ist einfach und kann praktisch jeder lernen. Ich meine Software-Entwicklung, Design und Architektur.

Ich arbeite zusammen mit Freunden an dem Aufbau der THElib, als Nachfolger und Ersatz der VISlib. Vor allem wollen wir einige Design-Fehler beheben die in der VISlib drin sind und wir auch nicht mehr raus kriegen, eben wegen zu starken Abhängigkeiten zu weiterer Software. Natürlich schreiben wir die THElib nicht komplett neu. Sie basiert zu sehr großen Teilen auf dem Code der VISlib, lediglich entschlackt und korrigiert. Aber hier sehen wir uns einer sehr großen Basis von Legacy-Code gegenüber die wir behandeln müssen. Es ist einfach nicht einfach.