Vereinheitlichung von GUIs komplexer Applikationen

In vielen komplexeren Projekten hat man das Problem das verschiedene Leute GUI-Teile implementieren. Das führt in vielen Fällen zu einer inkonsistenten GUIs. Dieses Problem kann man auf verschiedenen Wegen angehen. Der Weg 1 wäre einen eigenen Style Guide zu entwickeln und umzusetzen. Dieser Weg erzeugt sehr gute Resultate ist aber aufwendig. Bei der Umsetzung in Java hat man zusätzlich das Problem, dass einige Anforderungen des Style Guides in den Java-Klassen selbst umgesetzt werden müssen andere Dinge hingegen eine Anpassung des Look and Feels (L&F) erfordern.
Der 2. Weg ist pragmatischer und wesentlich einfacher und schneller umzusetzen, dafür sind die Resultate nicht ganz so gut, stellen aber in den meisten Fällen eine wesentlich Verbesserung gegenüber der Ausgangssituation dar. Folgende Regeln sind dafür umzusetzen:

• Verwendung möglichst wenigen Layout Manager z.B. BoxLayout, wenn komplizierter ist und sonst BorderLayout bzw. FlowLayout für Button-Reihen
• Einen Entwickler montiert bzw. überarbeitet der alle Oberflächen
• Convenience Methoden z.B. wenn man Textabschnitte bold setzt
• Minimale und sehr einfache Klassen die alle Entwickler nutzen z.B. für Fenster, dort sind dann Font, Rahmen und Layoutmanager werden schon richtig gesetzt
• Kreuzprüfung der GUI-Teile, d.h. die Entwickler testen die GUI-Teile die von anderen Entwicklern erstellt wurden

Diese Punkte garantieren kein einheitliches L&F der Oberflächen aber sie wirken Wunder und kosten fast nix. Ein weiterer wichtiger Punkt wenn es um das Interface zwischen Maschine und Mensch geht ist die Usability. Aus meiner Sicht ist es wichtig nicht nur in den Evaluationsphase Usability-Tests einzusetzen sondern schon in der Konzeptionsphase. Usability sollte den Entwicklungsprozess begleiten. Hier der Link zur bekanntesten Usability-Web-Seite. ES lohnt sich immer auf dieser Seite zu stöbern.

Noch so ein Programmierer-Blog

Scheinbar gibt es noch ähnlich angelegte Blogs, wie diesen Blog. Schaut mal rein.

Buch zum Logging

Logging ist wenig beachteter Teil von vielen Projekten. Oft wird wenig Zeit in das Logging investiert, weil es kein zentrales Feature der Software ist. Dem entsprechend gut funktioniert es auch. Zur Zeit werden primär drei verschiedene Logging-APIs eingesetzt, log4j, commons-logging und das Logging des JDK (Bestandteil seit dem JDK 1.4). Mein persönlicher Favoriet log4j war aus meiner Sicht lange Zeit nicht allzu gut dokumentiert, vor allem nicht die Möglichkeit der XML-Konfiguration. Aus diesem Grund habe ich mir auch folgendes Buch gekauft. In ihm wird nicht nur log4j erläutert sondern auch das Logging-API des JDK. Aus meiner Sicht könnte es noch weiter in die Tiefe gehen obwohl es schon ein paar Spezialitäten anreisst. Es bietet allgemein ein recht guten Einstieg ins Logging für Programmierer die nicht nur den Logging-Code aus einem alten Projekt kopieren.

Bücherregal

Ich werde hier in loser Folge einige Bücher empfehlen die ich für meine Arbeit nutze. Den Anfang machte gestern ein Buch zu Tomcat.

Tomcat Buch

Dieses Buch ist ein gutes Nachschlagewerk, wenn man mit der Entwicklung von Webapps vertraut ist und Spezialitäten des Apache Tomcat nutzen will. Vor allem für komplexere Web-Projekte jenseits von Spring ist es zu empfehlen als auch für Administratoren. Schon das Vorgängerbuch ist empfehlenswert.

c2in7y8qwm

c2in7y8qwm

Blog: Java ist auch nur eine Insel

Die meisten Programmierer werden das Buch "Java ist auch nur Insel" (Open Book) aus dem Galileo-Verlag kennen und als gutes, schnelles Nachschlagewerk schätzen. Der Autor des Buches, Christian Ullenboom , schreibt nicht nur Bücher, sondern auch noch einen interessanten Blog mit Tipps zum Thema Java.

Develop your developers

Tests ein mal anders. JavaBlackBelt ist ein Community-Website, die Test und Kurse zu vielen aktuellen Themen bietet. Diese stammen primär aus dem Bereich der Java-Programmierung. Je nach dem, wie viele Examen man erfolgreich absolviert hat bekommt man einen entsprechenden, farbigen Gürtel. Der schwarze Gürtel ist dann der höchste zu erreichende Gürtel. Natürlich stellt sich bei einigen Test die Frage, wie relevant sie in der Praxis sind und ob es sich bei dem Code nicht um gefährlichen Code (potentieller Bug) handelt. Trotzdem ist es aus meiner Sicht eine sehr gelungene Site.

Log4J Pattern Layout

Oft hat man beim Logging das Problem, dass ein Logmeldung länger ist als eine Zeil auf dem Bildschirm. Das führt dazu dass diese lange Zeile am Bildschirmrand umgebrochen wird. Für den Programmierer ist dies auf den ersten Blick nicht immer zu sehen, wo die Zeile weitergeht. Für mehr Übersichtlichkeit kann man durch folgendes Pattern sorgen:

< layout class="org.apache.log4j.PatternLayout">
        < param name="ConversionPattern" value="%d [%t] %-5p %c.%M%n: %m%n" />
</layout>

Das ergibt dann folgendes:

2009-07-08 06:59:06,470 [main] INFO  me.alif.App.
App starts up

Bei diesem Pattern wird der Inhalt der Logausgabe, also dass was der Programmierer in die Klammer des Log-Methodenaufruf schreibt, in einer neuen Zeile ausgegeben, die mit einem Doppelpunkt beginnt. Dies führ aus meiner Sicht zu einer höheren Lesbarkeit der Log-Ausgabe.

Tomcat JNDI Realm

Man man Tomcat nicht nur gegen Datenbanken authentifizieren lassen sondern auch gegen andere Naming and Directory Services. Hier ein Beispiel für die Authentifizierung gegen einen LDAP-Server:

<Realm

className="org.apache.catalina.realm.JNDIRealm"

connectionURL="ldap://ldap.rostock.xxx.de"

userPatter="|(cn={0},ou=XXX,o=XX1)(cn={0},ou=XX1,o=XXX)(cn={0},ou=XXX,ou=XY,o=XX1)(cn={0},ou=XX1,ou=XY,o=XY)"

userRoleName="SmartBluUserRole"

roleSearch="(uniqueMember={0})"/>

Jetzt muss man nur noch das formulieren des LDAP-Such-Pattern beherrschen.

Tomcat JDBC Realm

Mit Hilfe des JDBC Realms kann man in Tomcat sehr einfach und elegant eine Benutzerauthentifizierung und Zugriffsteuerung durchführen, bzw. von Tomcat durchführen lassen. Dafür muss man in der Datei context.xml der Webapp folgenden Abschnitt einfügen:

<Realm className="sb.realm.SmartBLURealm" debug="99"

driverName="com.mysql.jdbc.Driver"

connectionURL="jdbc:mysql://localhost:3306/test"

connectionName="smartblu"

connectionPassword=""

userTable="USER"

userNameCol="LoginName"

userCredCol="Password"

userRoleTable="user_roles"

roleNameCol="role_name"

digest="sha"/>

Tomcat versucht dann die Benutzer zu Authentifizieren gegen eine Datenbank jdbc:mysql://localhost:3306/test mit den entsprechenden Parametern. Der Datenbank-Table heisst hier USER. Die Passwörter der Benutzer sind mit SHA gehasht. SHA bedeutet in der Java-Welt meines Wissens nach SHA2.

In diesem Beispiel wir nicht der normale JDBC Realm verwandt sondern ein eigener Realm, der von JDBC Realm abgeleitet wurde aber gleichzeitig ein Migrationsfunktion (das Altsystem verwendete nicht SHA sondern Crypt) besitzt. Die Jar-Datei die die hier verwandte Klasse enthält muss für Tocat verfügbar sein, sie muss sich also im Verzeichnis tomcat/libs befinden. Alternativ kann in dieses Beispiel auch der JDBC Realm (org.apache.catalina.realm.JDBCRealm) eingetragen werden.

Der Realm ist aber nur ein Baustein bei der Authentifizierung mit Tomcat. Die weiterne Bausteine (Login-Config, Rollen und Security Constraints) sind in der Datei web.xml des Projektes enthalten.

Fluent Interface - schlechter Stil hat einen Namen

Gester oder war es Vorgestern bin ich gleich zweimal auf ein Problem gestossen, dass einige Programmierer in einer Codezeile lange, komplexe, häufig ineinander geschachtelte Anweisungen schreiben. In einigen Fällen sieht da sehr elegant aus und es spart Platz, d.h. man muss nicht so viel scrollen im Editor. Diese Art des Code Schreibens hat aus meiner Sicht zwei Mankos, auch wenn ich weniger scrollen muss sinkt die Verständlichkeit des Codes und wenn ein Fehler in dieser Zeile auftritt (Nullpointer in Zeile 137), muss diesen Ausdruck zerlegen um den Bug zu finden. Aus diesem Grund halte ich auch trinäre Ausdrücke für potentielle Fehler.

Daraufhin habe ich in der Newsgroup de.comp.lang.java den Verweis auf die Idee des Fluent Interface gefunden. Die oben beschrieben Art der Programmierung ist kein Fluent Interface. Fluent Interface ist eine elegante Art der Programmierung die vor allem Domain-spezifisch, sehr effizient sein kann. Der Vorteil der Natürlichsprachlichkeit dieser Ausdrücke halte ich nicht unbedingt für einen Vorteil, das mag vielleicht auch mit mit meinen mit Lingo (Macromedia Director, jetzt Adobe Director) gemachten Erfahrungen zusammenhängen. Die Natürlichsprachlichkeit war ja ein Kernfeature von Lingo.

Texte für LaTeX-Dokumente schreiben.

Die aktuellen Office-Pakete glänzen heute durch eine recht gute Rechtschreib- und Grammatikprüfung, ein Feature das vielen LaTeX-Editoren fehlt. Ein Möglichkeit dies zu kompensieren ist die Verwendung von Open Office mit der Erweiterung Writer2LaTeX. Mit ihr kann man Open Office Textdokumente als LaTeX-Dokumente exportieren.