Heute haben wir, eigentlich unfreiwillig, einen Performance-Vergleich zwischen Vista und Linux gemacht.

Aber von Anfang an: Ich habe unsere Refactoring-Tests umgeschrieben um externe Sourcen per Resource-Bundle zu laden. Ganz nett dabei ist, dass man automatisch Verzeichnisse nach gewissen Pattern durchsuchen lassen kann (leider keine RegExps, nur mit * als Wildcard). Auch rekursiv in die Unterverzeichnisse. Da wir in einem Durchlauf aber mehrere tausen Dateien laden und pro Ladevorgang zuerst alle Verzeichnisse durchsuchten, ist die Performance natürlich ziemlich eingebrochen… bei mir unter Linux ging es noch relativ gut (90 Sekunden für alle Tests) aber bei Thomas unter Vista dauerte das ganze 500 Sekunden! Und das bei gleicher Hardware, gleichem Eclipse und gleicher Java VM (1.6). Das Dateisystem war natürlich unterschiedlich, ReiserFS bei mir, NTFS auf der anderen Seite. Hätte ich echt nicht erwartet

Und ja, natürlich haben wir das ganze gefixt, einmal beim Start eine HashMap über die Resourcen erstellen und das ganze läuft auf beiden Plattformen in unter 3 Sekunden durch, unter Vista sogar wieder etwas schneller.

Nachdem vor ein paar Tagen (auch wenns im Manor schon seit mehreren Wochen verfügbar ist) das “neue” Coke Zero auf den Markt gekommen ist, haben wir Assistenten vom IFS einen Geschmacksvergleich gemacht und sind zum Schluss gekommen, dass das Coke Zero sicher nicht “wie das Original nur ohne Zucker” schmeckt, sondern eigentlich genau gleich wie Cola Light!

Nach einem Tag und mit weniger Kohlensäure habe ich dann nochmals getestet und hatte das Gefühl, dass das Zero weniger stark im Geschmack ist. Aber man lässt Cola ja auch nicht einen Tag offen herumstehen…

Eine Interessantere Entdeckung hatten wir (oder ich zumindest) aber beim Geruch gemacht: Light riecht irgendwie mehr nach Zitrone..

h3. Fazit

Ziemlich lächerlich das ganze, ich bleibe beim normalen Coca Cola! Auch wenn das Zero eine chicere (gibts das?) Dose hat.

Neben 24 und Alias habe ich soeben auch in Heroes KDE entdeckt:

Juhui

Eigentlich bin ich ja kein Manager, weshalb es vielleicht etwas komisch war, das Buch Behind Closed Doors — _Secrets of Great Management_ zu lesen. Da es aber recht schmal ist und von den Pragmatic Programmern, habe ich es trotzdem mal angeschaut:

_(Ja das Buch hat wirklich ein komisches Format, das liegt nicht am Bild)_

Der Inhalt handelt vom Manager Sam, der neu in eine Firma kommt und dort ein Team in der Softwareentwicklung leitet. Anhand vieler Beispiele und teilweise auch mehr als Roman geschrieben werden verschiedenste Alltagssituationen erläutert und Tipps gegeben, was man in der Situation am besten tut.

Zum Schluss werden dann noch diverse Techniken und kurze Checklisten erklärt, die man als Manager immer mal wieder braucht.

Wer weiss, vielleicht bin ich mal in der Lage, ein Team zu leiten, dann werde ich mich hoffentlich an dieses Buch erinnern, nochmals lesen und mich auch daran halten.

Als nächstes steht Everyday Scripting with Ruby auf dem Plan, wenn Amazon bald mal liefern würde…

Endlich ist es soweit, unsere Refactoring Plug-ins habens ins RDT geschafft und stehen somit im Nightly-Build zur Verfügung! Warum es so lange gedauert hat lässt sich relativ einfach sagen: JRuby ist schuld! Nein, in der Zeit der Diplomarbeit wurden einige Änderungen am abstract syntax tree vorgenommen und da wir sehr eng damit gekoppelt sind mussten wir einiges umschreiben und anpassen. Dank der ziemlich guten Testsuite ging das recht gut. Auch unsere Patches für JRuby wurden alle akzeptiert und commit Rechte fürs RDT haben wir ja schon seit längerem.

Also, installieren und Bugs bitte hier melden.

Wie gehts weiter? Wir haben noch einige Bugs zu fixen und auch neue Features sind vorstellbar — zum Beispiel Rails Integration.

In einem IEEE Magazin habe ich eine Anzeige für Diomidis Spinellis’ Buch *Code Quality* gesehen und habe es dann auf Weihnachten geschenkt bekommen. Spinellis ist IEEE-Software Autor und übrigens auch der Entwickler von UMLGraph, welches wir in unserer Studien- und Diplomarbeit für das Generieren der Diagramme verwendet haben.

Er schreibt über die verschiedenen Aspekte von Qualität, die man beim schreiben von Programmcode beachten kann, muss oder auch sollte. Es geht dabei um nicht funktionale Anforderungen wie Verlässlichkeit, Sicherheit, Portabilität, Wartbarkeit und Stabilität (also alle sogenannten “ilities”).

Aussergewöhnlich an seinem Ansatz ist, dass er all diese Probleme anhand von Code erklärt. Und nicht selbstgeschriebenen Dummy-Code sondern Code aus verschiedensten Open Source Projekten. Ich finde das wirklich ziemlich beeindruckend, ich möchte nicht wissen wie viel Zeit er dafür aufwenden musste.

Viele dieser Probleme sind stark von der Hardware oder dem Betriebssystem abhängig, man sollte also gerne C-Code lesen und auch nicht vor Themen wie Memory Management fürchten, sonst kann man dem Buch wahrscheinlich nicht allzu viel abgewinnen. Insofern sind gewisse Teile des Buches für reine Java-Programmierer eher uninteressant, müssen sie sich doch nicht um verschiedenste Hardware und Compiler kümmern. Aber Themen wie Security (keine eigenen Algorithmen “erfinden“!) und der Umgang mit Daten (Inputvalidierung beispielsweise) sind allgemein gültig. Im zweitletzten, ziemlich grossen Kapitel geht es noch um Maintainability und es werden verschiedenste Punkte die man beim schreiben von Code beachten sollte berücksichtigt.

Interessant war auch die letzte Seite im Buch, wo die verwendeten Tools erklärt werden. Das ganze Buch wurde nämlich mit vim/nvi und Latex geschrieben und mit make und diversen Perl-Scripts erstellt.

Ein recht gutes Buch, auch wenn nicht alle Teile gleich interessant sind, dafür aber immer mit echten Beispielen und keine Äpfeln und Birnen. Also definitiv lesenswert!