In der Theorie lernt man sehr viele Dinge, die sich in der Praxis des Arbeitsalltags leider nur selten wieder finden. So sind Unittests in unserer alltäglichen Softwareentwicklung ein Fremdwort. Für mein aktuelles Projekt wollte ich diesen Umstand aus gegebenem Anlass ändern und habe angefangen, Tests nachzustricken.
Während des Entwerfens der Testfälle fragte ich mich, wie sich die Klasse, die ich gerade bearbeitete wohl unter Reset ihrer Daten verhält, und ob ihr Zustand danach wirklich definiert ist, da ich ursprünglich davon ausging, dass die Daten nur einmal pro Instanz gesetzt werden, was ich aber programmtechnisch nicht erzwungen hatte.
Ich hatte zwei Möglichkeiten: Im Source der Klasse nach lesen, was in diesem Fall wohl passiert, oder einfach einen Testfall dafür schreiben. Ich entschied mich für die zweite Lösung, was zu zwei Ereignissen führte: Ich entdeckte, dass sich die Klassenimplementation tatsächlich falsch verhielt und ich hatte das erste Mal in der realen Welt Kontakt mit test driven development (TDD).

Bei der ganzen Sache fiel mir ein Fakt auf:
Das Leben ist wie TDD beim refactoring und bug hunting von legacy code. Man hat einen Haufen Code, von dem eine ganze Menge irgendwie funktioniert, und man weiß nicht genau warum. Und dann gibt es Code, der nicht richtig funktioniert wie er soll, und auch hier weiß man nicht, warum er das tut. Also schreibt man sich ein paar Unittests, Blaupausen der eigenen Vorstellung, wie sich das Programm verhalten soll, und fängt an, das Programm langsam aber sicher umzustricken. Man nimmt sich einer Kante der Klasse nach der anderen an und bringt diese dazu, sich den eigenen Vorstellungen entsprechend anzupassen.
Nun hat man als Schöpfer des eigenen Lebenablaufes das gleiche Problem wie der Softwareentwickler: Wenn man es mit fremdem Code zu tun hat, ist man sofort versucht, alles als Müll abzutun und wegzuwerfen und das Rad von vorne zu erfinden, wenn es aber um eigenen alten Code handelt, kann es noch so ein Schrott sein, man wird meist an der alten Implementierung festhalten und nur ein wenig hier und da rumpfuschen, in der Hoffnung, dass es besser wird.
Ab wann sollte man sich von einer Implementierung trennen und eine neue beginnen? Warum gibt es kein Werkzeug, keine Codemetrik, die einem einen Anhaltspunkt liefert, wann man etwas neu machen sollte, und wann es sich lohnt, das alte zu reparieren?
Und wenn das Design der Klasse, das Interface schon fehlerhaft war? Wie soll man so eine Entscheidung treffen, wenn man noch gar keine Vorstellung davon hat, wie die neue Klasse eigentlich aussehen soll?
Also muss man auch noch die Architektur überarbeiten. Und vielleicht kommt dabei heraus, dass das Interface schlecht war… vielleicht, oder auch nicht.
Jedenfalls ist es besser, als immer wieder Instanzen von dem gleichen fehlerhaften Klassendesign zu machen.

Music for today The Corrs – At Your Side

In unserer hochtechnisierten und wissenschaftlich aufgeklärten Welt gibt es eine Frage, die sich eigentlich gar nicht mehr stellt: Gibt es Magie?

A Story About Magic

Ich finde die Geschichte großartig. Sie zeigt zum einen, dass es für (fast) alles eine logische Erklärung gibt, aber sie zeigt auch, wie man sich wundern, wie man staunen kann, wenn eine Erklärung nicht sofort ersichtlich ist.

Die Faszination des Lebens ist vielleicht gerade, nicht alles zu wissen. Ich glaube, ich werde mich in nächster Zukunft einfach mal überraschen lassen, häufiger einfach sehen, was auf mich zu kommt.
Mal schauen, ob ich auch irgendwo einen Schalter finde, den ich auf “mehr Magie” schalten kann.

roundtrip time: 369d 4h 39m 17675msec
host status: alive, but critical
packets transmitted 872348674, received 1, 99.9% packet loss

Wie gerade eben im letzten Beitrag schon angedeutet, scheint die Menge an Gizmos in meinem Leben momentan rapide anzusteigen. Vielleicht erscheint es aber auch nur so, weil fast alle meine Freunde und gute Bekannte von Frühlingsgefühlen gepackt in einigermaßen funktionierende Beziehungen schlittern, ich mir deshalb deutlich weniger Gejammer anhören muss und mir selbst damit auch deutlich weniger Gedanken über Frauen mache, was dazu führt, dass ich anderen (un)wichtigen Dingen mehr Aufmerksamkeit zukommen lassen kann. (Okay, der letzte Satz strotzt jetzt von Unwahrheiten und Übertreibungen, aber nehmen wir mal an, es wäre tatsächlich so.)
Die Welt wäre ohne Probleme so langweilig. Jeder kennt ja das vim-emacs Problem, aber ich gestehe, ich bin ein Weichei. Ich benutze statt vim lieber nano, und emacs ist ein cooles Betriebssystem, aber es fehlt ein guter Editor. Wenn es ums Programmieren geht werde ich sogar noch weicher. Ich stehe dazu, dass ich selbst für Kleinstprojekte (alles was größer als ein 100 Zeilen Perlskript ist) eine ausgewachsene Entwicklungsumgebung bevorzuge. Seit ein paar Jahren ist da Eclipse meine erste Wahl. Nun hat aber gerade das Plugin für die Entwicklung in C den Nachteil, dass das Source Code Parsing sich stark auf die Ausgabe einer funktionierenden Build-Umgebung stützt, so dass einige Informationen erst nach einem erfolgreichen Compilerlauf zur Verfügung stehen. Da stand ich natürlich etwas im Regen, als ich mit Eclipse unter Windows mit Cygwin versuchte, ein Tool für ein Embedded System auf Basis eines Freescale MPC5200 Prozessors zu basteln, für den ich keinen Cross Compiler hatte. Schon die Tatsache, dass ich im Endeffekt ein komplettes Unix mit Cygwin unter Windows nachbilde, ist ja eigentlich seltsam. Das mit coLinux praktisch seit ein paar Tagen auch noch ein virtualisiertes Linux auf meinem Arbeitsplatzrechner zuhause ist, wirft dann allerdings die Frage auf, warum die dämliche Kiste überhaupt noch unter Windows läuft. Unter FreeBSD ließe sich das Linux viel besser virtualisieren Ach, ich erinnere mich… MS Office und Alibre sind Schuld.
Jedenfalls stand ich vor dem Problem eine cross compile toolchain selbst zu kompilieren. Allerdings ist das ein Krampf, und die Aussage eines Kollegen, ich sollte dafür ruhig ein bis zwei Wochen an Bastelei einplanen, hob meine Motivation nicht gerade. Ich hatte schon mit Eclipse innerlich abgeschlossen und mich damit abgefunden, wieder per X-Umleitung mit einem emacs auf unserem Linux-Entwicklungsrechner zu programmieren und die dort vorhandene cross compile Umgebung zu nutzen, als mir mit einem Schlag klar wurde: Virtualisierung ist doch nicht nur Spielerei sondern hat eine Existenzberechtigung. Ich werde nach Ostern Eclipse und die cross compiler in ein Image schmeißen und unter coLinux auf meinem Rechner in der VM laufen lassen. Spart mir eine Menge Arbeit und ich kann doch so arbeiten wie ich das mag. Ha!
Geekism for the win.
Stori freute sich über das Wort geekism. Ich find es besser als geekdom, immerhin steckt ein kis(s) drin
Aber jetzt stehen für die nächsten Tage erst mal Strand und Sonne an. For life and fun.

Ich bin wohl doch ein Nerd. Ich habe meine komplette Freizeit heute tatsächlich mit Aufräumen und Wühlen durch Codezeilen verbracht. Und das, nachdem ich schon die letzten beiden Tage in der Firma schon fast ausschließlich bis zum Kinn in Sourcecode gebadet hab. Und das auch noch in einer Mischung aus hardwarenahem C und Assembler.

Die Gründer des Projektes, mit dem ich gerade zu tun habe, müssen aber auch einen gewissen Geekfaktor haben. Wer sonst würde einen universellen Bootloader Das U-Boot nennen. Wenn man sich dann durch hunderte Zeilen Code kämpft, um die Hardwareabstraktion der IDE-Treiber zu verstehen und dann in der README-Datei folgendes findet, wundert einen fast gar nichts mehr, auch wenn ich einige Sekunden gebraucht hab, um festzustellen, dass es sich nicht um C-Code handelt.


U-Boot Porting Guide:
----------------------

void no_more_time (int sig)
{
hire_a_guru();
}


Ich verstehe, wenn das jetzt nicht für jeden witzig ist. Ich gehe schon in die Ecke und schäme mich.

An dieser Stelle einen schönen Gruß an Wolfgang Denk, der vielleicht genial, auf jeden Fall aber ein Guru ist und mit dem U-Boot und dem ELDK sicherlich ein Stück Softwaregeschichte geschrieben hat. Beste Grüße auch von Reinhard.

Als ich im code gen_eth_addr.c dann folgenden Kommentar gefunden hab, dachte ich einfach nur: OMG, geeks.


/* (C) Copyright 2001
* Murray Jensen
*/

/*
* setting the 2nd LSB in the most significant byte of
* the address makes it a locally administered ethernet
* address
*/


Den Satz muss man tatsächlich einige Male laut aussprechen und auf der Zunge zergehen lassen. Einfach nur geil. Präzisise und kurz formuliert, aber beim ersten Lesen versteht es bestimmt keine Sau.

Als ich heute in meinem syslog dann folgende Fehlermeldung gefunden hab, war es total aus:


Mar 31 15:47:19 mike gconfd: Some clown returned undeclared exception 'IDL:ConfigException:1.0'


Da hatte einer Spaß beim Programmieren von Fehlermeldungen. Hätte auch von mir kommen können.

Okay, genug gelacht für heute. Morgen früh ruft eine Rollenspielkonvention.