Software Engineering Blog

Was Gutes gibt es selten für 'n Appel und 'n Ei. Aber manchmal doch. Atlassian bietet jetzt bis zum Freitag, den 24. April, sein Issue-Tracking-System JIRA und das Wiki Confluence in der Enterpriseversion beschränkt auf fünf Benutzer für sage-und-schreibe fünf Dollar an. Die Lizenz kann für jeweils fünf Dollar maximal drei Jahre verlängert werden.

Gerade für kleine Firmen oder Gruppen ist das ein unschlagbares Einstiegsangebot. Natürlich spekuliert Atlassian darauf, so durch die größere Nutzerbasis auch füher oder später mehr große Lizenzen zu verkaufen. Doch gerade für den Einstieg mit JIRA und Confluence ist das ein unschlagbares Angebot.

Übrigens, das Geld wandert nicht in die Taschen von Atlassian, sondern alle Einnahmen aus dieser Aktion gehen an das Projekt Room to Read.

Vor einiger Zeit habe ich mir vorgenommen in einer kleinen Reihe von Artikeln meine bevorzugten Extensions für Mozilla Thunderbird vorzustellen.

Zum einen weil ich Thunderbird trotz seiner Schwächen einfach für den für mich am besten geeignetsten Mailclient halte, zum anderen weil einige der Erweiterungen gute Ideen beinhalten, die sich auf andere Anwendungen übertragen lassen. Und wenn ich mich auf eine Erweiterung beschränken müßte, dann würde meine Wahl immer wieder auf
Nostalgy von Alain Frisch fallen.

Obwohl sich Thunderbird schon von Hause aus leicht über Tastatur steuern läßt, sind nicht alle Funktionen schnell und leicht über die Tastatur erreichbar. Daher rüstet Nostalgy für oft genutzte Funktionen Shortcuts nach. Nostalgy ist eine Reminiszenz an die Zeiten in denen Programme nur über die Tastatur gesteuert wurden.

Navigation zwischen Ordnern

Der Schwerpunkt in den von Nostalgy installierten Tastaturkürzeln liegt in der Navigation zwischen den Ordnern aller Mailkonten. Muß bis zur Installation von Nostalgy ein Ordnerwechsel zur Maus gegriffen werden um den Ordner zu wechseln oder eine Mail in einen anderen Ordner zu verschieben, läßt sich dies jetzt schnell und effektiv über einen einzelnen Tastendruck erledigen.

Natürlich gibt es noch weitere Tastaturkürzel, die ebenso wie die in der Tabelle genannten alle individuell konfiguriert werden können.

Wird eines dieser Tastaturkürzel ausgelöst, erscheint unten im Thunderbird-Hauptfenster ein Eingabefeld zur Eingabe des gewünschten Ordners, wobei der Ordnername aufgrund der existierenden Ordner bei der Eingabe vervollständigt wird. Werden die Ordnernamen so gewählt, daß der gemeinsame Präfix aller Ordnernamen sehr klein ist, kann eine Mail zwischen Konten mit zwei, drei oder vier Tastendrücken bewegt werden. Besser geht es nicht.

Adressieren von Mails

Ein anderes Feld in dem Nostalgy seine Stärken ausspielt ist die Adressierung von Mails, genauer gesagt, bei der Angabe ob eine Mail direkt an einen Empfänger gehen soll (to:), als Kopie (cc:) oder als Blindkopie (bcc:). Ist das Standardverhalten von Thunderbird so, daß jeder neuhinzugefügte Empfänger die Adressart von der sich darüber befinden Adresse übernimmt, kann mit Nostalgy vor der Eingabe der Mailadresse einfach die Adressierungsart eingegeben werden, die dann sofort von Nostalgy für diese Adresse übernommen wird. In der untenstehenden Tabelle sind die Abkürzungen zum Umschalten zwischen den Adressierungsarten aufgeführt.

Natürlich kann Nostalgy noch mehr. Mittels der Taste l kann die Ordnerleiste ausgeblendet werden. Das ist konsequent, da diese für die Navigation durch Nostalgy nicht mehr notwendig ist. Über weitere Funktionen von Nostalgy kann man sich in der Dokumentation informieren.

Und wo bleibt jetzt das Software Engineering?

Die benutzerfreundliche Gestaltung von Oberflächen ist wohl eine der größten Herausforderungen für Software-Entwickler, da es hier nicht nur um die Entwicklung von Algorithmen und technischen Lösungen geht, sondern um solche weichen Bereiche wie Ästhetik, Benutzerfreunlichkeit und Effizienz. Nostalgy fällt in die letzte der genannten Kategorien und demonstriert wie eine kleine Erweiterung für bestehenden Lösungen die Benutzerfreundlichkeit und als auch die Ergonomie wesentlich steigern können. Und wenn man Software-Engineering auch als Disziplin auffaßt, deren Ziel es ist, uns dabei zu unterstützen unseren Benutzern genau solche Werkzeuge zur Verfügung zu stellen, dann ist Nostalgy unter diesem Aspekt ein gutes Beispiel für erfolgreiches Software-Engineering.

Die Bildung verliert gegenüber der Ausbildung. Das ist wohl das einzige Ergebnis, welches uns Master und Bachelor bringen. Hierzu paßt gut der Artikel Die Gelehrten von St. John's auf spiegel.de.

Fähigkeit und Können ist immer ein Querschnitt aus unserem Wissen. Unser Wissen stellt uns die Bausteine für unsere Ideen zur Verfügung. Eine leider einseitig gewordene Ausbildung birgt die Gefahr uns nur auf spezielle Gebiete zu beschränken und beschränkt zu bleiben, weil uns der Blick über den Tellerrand fehlt.

Außerdem ist es doch auch sehr angenehm und interessant Kollegen zu haben, mit denen sich einmal über etwas anderes als IT unterhalten kann.

Wie in der Ankündigung und beim Vortrag versprochen, sind hier die Folien zu meinem Vortrag zu TestNG im Format PDF.

TestNG - Unit-Test 2.5, Vortrag vor der JUG Berlin-Brandenburg, PDF

Wie der Heise-Newsticker meldet, wechselt das Gnome-Projekt das Versionskontrollsystem und löst damit Subversion durch GIT ab.

Das an sich ist mir noch keinen Eintrag wert, aber darüber bin ich auch einen Vortrag von Linus Thorvalds zu GIT aufmerksam geworden, der sehr interessant (und auch unterhaltsam) ist. Thorvalds spricht darin über eine Ansichten zur Versionskontrollsystemen und den Vorteil von verteilten Systemen gegenüber einem zentralisierten Ansatz wie er früher von CVS und jetzt auch von Subversion verfolgt wird. Insgesamt auf jeden Fall empfehlenswert, darum hier das Video zum Vortrag:

Mit vielen seiner Ansichten legt Thorvalds den Finger auf wunde Punkte in Versionskontrollsystemen und zeigt Alternativen auf. Auch seine Ansichten dazu, was ein Branch ist, sind richtig. Nach ihm entsteht defacto schon ein Branch dadurch das man die Working Copy verändert und damit eine neue Codelinie defacto eröffnet. Denkt man das konsequent zu Ende, ist eine in einer IDE geänderte Datei auch schon ein neuer Branch.

Nach meiner Meinung weist Thorvalds aber auch auf einen richtigen Punkt hin: Verteile Entwicklung in Open Source-Projekten erfordert sicherlich einen anderen Umgang mit Versionkontrollsystemen als ein räumlich zentralisiertes Projektteam. Bei zentralisiert arbeitenden Teams, die auf eine schnelle Integration von Änderungen auf einen zentralen Branch angewiesen sind, scheint mir Subversion und Co. im Vorteil zu sein.

Aber es ist wohl wie immer: Die Wahl des richtigen Tools hängt immer von der konkreten Situation ab.

Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!

Leider mußte ich aus persönlichen Gründen den TestNG-Vortrag vom 10. März auf den 23. März 2009 verschieben. Danke an Ralph Bergmann von der JUG Berlin-Brandenburg für die Flexibilität.

Jetzt steht der Termin endgültig fest und die Einladung ist via XING auch raus.

Also am 10. März 2009 um 18:30 Uhr werde ich vor der JUG Berlin-Brandenburg in einem Vortrag TestNG als Alternative zu JUnit vorstellen.

Die Folien oder besser gesagt das PDF zum Vortrag werde ich nach dem Vortrag hier veröffentlichen.

Nach "Der Termin" erschien von Tom DeMarco 2001 "Spielräume", in dem sich DeMarco mit der Notwendigkeit auseinandersetzt auch unter hoher Belastung genügend Freiräume zu schaffen um auch langfristige Ziele verfolgen zu können. "Adrenalien Junkies und Formular-Zombies" ist die aktuelle Veröffentlichung von Tom DeMarco mit seinen der Atlantic Systems Guild-Partnern. In diesem Buch setzen sich Tom DeMarco und seine Partner mit aus ihrer Sicht typischen Verhaltensmustern im Projektgeschäft auseinander. Hierfür stellten sie 86 in Projekten beobachtete Verhaltensweisen zusammen, bei denen es sich sowohl um empfehlenswerte Muster als auch um Anti-Muster handelt. Die Muster beschreiben Verhaltensweisen, die zum Erfolg der beobachteten Projekte oder zum Gesamterfolg der sie praktizierenden Firmen beigetragen haben. Entsprechend beschreiben die Anti-Muster projektgefährdende Verhaltensweisen. Wer "Der Termin" kennt, wird viele Muster als auch Anti-Muster wiedererkennen können. Das Muster "Der Bleistiftstummel" ist beispielsweise die Entsprechung dazu, daß sie Webster Tompkins um eine gute Ausstattung seiner Projektteams kümmert, um deren Produktivität sicherzustellen. Auch die Rolle von Aristoteles Kenoros, dem Leiter des moravischen Software Engineering Institutes, findet sich indirekt in "Alte Hüpfer und junge Hasen" wieder. Dieser sich häufig einstellende Wiedererkennungseffekt und die leichte Schreibweise machen "Adrenalien-Junkies und Formular-Zombies" zu einer angenehmen und leichten Lektüre, wodurch die Schwächen den Buches kaschiert werden. Den das Buch leidet zum einen unter einer mangelnden Struktur. So sind die Muster weder nach einem ersichtlichen Schema strukturiert, noch als Muster oder Anti-Muster gekennzeichnet. Zum anderen divergieren die Musterbeschreibungen sowohl in Hinsicht auf Qualität und Umfang. Teilweise werden Muster umfangreich auf vier Seiten beschrieben, andere Muster bringen es auf nicht mehr als eine Seite. Das dem Leser keine Hilfestellungen für sein Handeln in bestimmten Situationen an die Hand gegeben werden und die mangelnde Untermauerung mit Fakten sind aber die Hauptmängel des Buches. Hier bieten andere neuere Erscheinungen wie "Softkills für Software-Entwickler" mehr Rüstzeug für den Projektalltag, auch wenn sie sich nicht so leicht lesen wie "Adrenalien Junkies und Formular Zombies". Auch bot hier Projekttagebuch von Webster Tompkins, welches am Ende jedes Kapitels geführt wurde, mehr und bessere Ansätze.

Wie auch schon bei "Der Termin" besteht der Charme des Buches darin, daß viele Verhaltensweisen mit eigenem Erlebten übereinstimmen. Der Wert von "Adrenalien Junkies und Formular Zombies" liegt darin, einen auf diese Punkte aufmerksamzumachen und einem die Möglichkeit zu verschaffen, eigene oder beobachtete Verhaltensweisen zu reflektieren, die aufgrund des Shifting-Baseline-Effekts selbst nicht mehr wahrgenommen werden. Trotz dieser überwiegend positiven Aspekte weist das Buch also schwere Mängel auf und zählt nicht zu den publizistischen Höhepunkten im Schaffen von Tom DeMarco, ist aber auf jeden Fall, auch wenn nur zur Reflektion, eine Anschaffung wert, denn alle von ihm beobachteten Punkte sind wahr.

Als Fazit bleibt festzuhalten, daß der Wert von DeMarcos Büchern in seiner Fähigkeit liegt, die in Projekten und Firmen herrschende Realität zu beobachten und uns auf bisher publizistisch-hohem und unterhaltsammen Niveau mitzuteilen. Seine Popularität begründet sich darin, dies wahrheitsgemäß zu tun und das seine Beobachtungen mit den Wahrnehmungen seiner Leser übereinstimmen. Gleichzeitig sollte uns die Notwendigkeit solcher Menschen wie Tom DeMarco auch Anlaß sein darüber nachzudenken, wie und von wem Projekte geleitet werden.

Liebe ich Java? Ja, das tue ich. Sicher, Java muß aufpassen nicht den Anschluß an die Entwicklung "moderner" Sprachkonzepte zu verpassen, aber etwas moderater Konservatismus kann nicht schaden. An vorderster Front zu stehen kann auch gefährlich sein und tödlich. Außerdem geziemt es sich nicht für eine "Business-Language" sich in jedes Getümmel zu stürzen.

Es gibt aber auch Dinge in Java oder der API, die haben mich in den letzten acht Jahren immer wieder wahnsinnig werden lassen. Beispielsweise der Umgang mit Zeitangaben. Allein, daß sich Calendar im Package java.util befindet, drückt doch schon eine gewisse Geringschätzung aus...

Wer Businessanwendungen schreibt hat es täglich mit Zeitangaben in seinen Anwendungen zu tun wie: jeden Tag um acht Uhr, sieben Stunden lang oder vom ersten bis zum zehnten jeden Monats. Für all das bietet das JDK nur Date und Calendar als Ausdrucksmittel. Beide Klassen beziehen sich vereinfacht gesagt immer auf einen konkreten Zeitpunkt unter Angabe von Tag und Uhrzeit. Beides stellt also einen festen Punkt auf einer Zeitachse dar.

Damit lassen sich aber die oben genannten Beispiele nicht ausdrücken. "Vom ersten bis zum zehnten" bezieht sich auf zwei Punkte auf der Zeitachse. Sollen Fragen wie "Liegt folgendes Datum im Zeitraum oder davor oder sogar danach?" zwingt uns die API immer mit zwei Datumsangaben zu hantieren. Sollen zwei Datumsangaben mit Calendar noch schnell mit Tages oder Monatsgenauigkeit überprüft werden, läßt sich das auch nicht in einer Zeile bewerkstelligen, da Calendar-Instanzen immer auch Zeitangaben enthalten.

Eine neue API für den Umgang mit Zeit ist also mehr als überfällig und Rettung naht auch schon in Form des JSR 310 Date and Time API der unter der Leitung von Stephen Colebourne und Michael Santos entwickelt wird.

Colebourne ist übrigens auch verantwortlich für das JodaTima-Projekt, welches heute schon eine alternative API für Zeitberechungen bereitstellt und von http://joda-time.sourceforge.net/ heruntergeladen werden kann.

Die Grundkonzepte von JodeTime sind die folgenden Datentypen:

• Instant für einen Punkt auf der Zeitachse mit Nanosekundenauflösung
• Interval für einen Zeitraum zwischen zwei Punkten auf der Zeitachse
• Duration für eine Zeitdauer in Milisekunden wie zum Beispiel 3 Tage
• Period für Zeitdauerangaben unter der Verwendung von Jahren, Monaten etc. vergleichbar mit xs:duration

Um diese Datentypen bauen Colebourne und Santos nun auch die API für den JSR 310 auf die eventuell schon in der 7er Version von Java unter javax.time enthalten sein wird. Dazu kommen die notwendigen Klassen zur Verarbeitung von Datumsangaben. Insgesamt hinterläßt die API einen sehr mächtigen Eindruck. Zur Zeit ist sie leider noch sehr instabil, wer aber die Mailingliste zum JSR 310 verfolgt, merkt das aktiv an der Spezifikation und Implementierung gearbeitet wird. Einen guten Überblick über die verfolgten Ziele liefert auch die Präsentation von Colebourne auf der 2008er JavaOne.

Wer bis zu Version 7 nicht warten will, kann jetzt schon bei JodaTime Hilfe finden.