Programming

Joel on Software

2009-12-22T11:49:00.000-08:00

Es ist schon erstaunlich, dass viele Entwickler ähnliche Probleme haben, zumindest die Guten :-D. Hier ein interessanter Blog: Joel on Software von Joel Spolsky. Joel Spolsky ist ein ehemaliger Fallschirmjäger und Microsoftentwickler. Ob es zwischen diesen Fähigkeiten einen Zusammenhang gibt? In dem Blog geht es um gutes und natürlich schlechtes Projektmanagement aber auch um Programmierdinge (z.B. Blähsoftware, Bytes oder der Joel-Test). Einige Beiträge von 2000 bis 2009 sind auch auf Deutsch verfügbar. Man kann auch bei der Übersetzung helfen. Spontan meine liebste Stelle:

...

Aber ich mache mir nicht über die Tage Sorgen, an denen ich "nur" zwei Stunden arbeite. Es sind die Tage, an denen ich gar nichts tue.

...

Interessant ist auch der Joel-Test, obwohl er schon fast 10 Jahre alt ist, erfüllen immer noch nicht alle Softwarefirmen den Test. Selbst wenn man den Test nicht kennt, so ist sein Inhalt doch für alle guten Programmierer keine Überraschung sondern sollte der Normalfall sein.

Die Forderung des Test eines One-Click-Build passt gut zu Maven und Ant und zu diesem Blog. Ja und ich habe einen zweiten Monitor.

Fehlende Einträge

2009-12-25T02:30:00.000-08:00

Hier meine unvollständige Liste noch fehlender Einträge. Ich nehme noch gerne Vorschläge für weitere Artikel entgegen.

Security, Rolls in Tomcat
Performancevergleich von Webservices im Vergleich zu reinem HTTP
Optimierter Code
DB Zugriffe
XSL

Noch so ein Programmierer-Blog

2009-07-10T12:52:00.000-07:00

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

CCD: clean code developer

2009-08-14T05:32:00.000-07:00

Viele Dinge in diesem Blog thematisieren die täglichen Probleme. Auch gibt es paar etwas grundlegendere Beiträge nur leider keine grundlegende Verarbeitung dieser Dinge. Ich hatte mir das alles auf einen späteren Zeitpunkt verschoben. Das ist dann wohl zu spät. Aber ich freue mich auf die folgende Webseite hinzuweisen: CCD: clean code developer bzw. auf das Interview.

Ich glaube alle Prinzipien dieser Seite kann ich gutes Gewissens empfehlen, weil ich sie aus meiner Erfahrung selbst anwende und meinen Studenten rate. Die dort beschriebenen Prinzipien lassen sich durch eine Reihe von Werkzeugen sinnvoll unterstützen. Dazu werde ich demnächst einen Beitrag schreiben.

Internationalisierung

2009-08-10T11:07:00.000-07:00

Oft stößt man bei Internationalisierung von Java-basierter Software auf das Problem das die Property-Dateien von Java mit einem festen Encoding (ISO-8859-1) eingelesen werden, das man auch nicht ändern kann. Diese Property-Datei dienen zur Aufnahme der lokalisierten Zeichenketten. Wenn es sich nur um gelegentliche Zeichen handelt, die nicht in diesem Encoding vorhanden sind kann man diese Zeichen in UTF-Schreibweise eingeben. Alternatif schreibt man sich eine eigene Klasse die Proppertie-Dateien mit unterschiedlichen Encodings einlesen kann. Dann muss man nur noch eine Methode schreiben mit denen man auf diese lokalisierten String zugreifen kann. Besonders elegant finde ich, folgende Methode String _(String Key) zu definieren und diese dann statisch zu importieren. Noch eleganter wird es wenn man den Key als Fallbackwert zurückgibt wenn der Key nicht vorhanden ist. Natürlich sollt man das in Fehlerlog dann eintragen. Ein wirkliche Alternative zu der Lokalisierung via Property-Dateien ist die Benutzung von XLIFF (XML Localization Interchange File Format).

Vereinheitlichung von GUIs komplexer Applikationen

2009-07-30T05:31:00.000-07:00

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.

Tomcat Buch

2009-07-09T12:34:00.000-07:00

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.

Buch zum Logging

2009-07-10T04:37:00.000-07:00

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

2009-07-10T00:16:00.001-07:00

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.

2009-07-08T00:08:00.001-07:00

c2in7y8qwm

2009-07-09T05:16:00.000-07:00

c2in7y8qwm

Blog: Java ist auch nur eine Insel

2009-07-09T00:12:00.000-07:00

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

2009-07-08T05:36:00.000-07:00

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

2009-07-08T00:46:00.000-07:00

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

2009-07-03T03:11:00.001-07:00

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.

Fluent Interface - schlechter Stil hat einen Namen

2009-07-03T01:23:00.000-07:00

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.

Tomcat JDBC Realm

2009-07-03T02:33:00.000-07:00

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.

Texlipse

2009-04-21T00:26:00.000-07:00

Zur Zeit erstelle ich ein Liste meiner Programmierwerkzeuge. Heute ist der Abschnitt zu Texlipse fertig geworden. Teclipse ist ein Eclipse-Plugin zur Erstellung von Latex-Dokumenten. Weiters ist hier zu finden: http://sites.google.com/site/mirkoebert/Home/werkzeuge

Texte für LaTeX-Dokumente schreiben.

2009-07-03T00:59:00.000-07:00

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.

Wo sollen die JUnit-Tests ausgeführt werden?

2009-06-25T05:57:00.000-07:00

Wenn man ein Projekt mit Hilfe Mavens realisiert und steht man meist vor dem Problem wo man die JUnit-Tests ausführt. Natürlich in Maven, das funktioniert prima auf Grund der meist durch Maven definierten Projektstruktur (ich weiss, sie ist natürlich änderbar). Das Problem was ich dann habe, es dauert länger bis ich weiss wie das Ergebnis der Test ist, dazu kommt das die Integration der Testergebnisse und deren graphische Darstellung (lange List in der Console) im Vergleich zur JUnit-Komponnente aus Eclipse mau ist. Wenn ich versuche einzelne Tests oder alle Tests des Projekts via Run-Menü in Eclipse ausführen zu lassen schlägt dies fehl. Abhilfe schafft dort ein anderer Weg (siehe Bild), wähle im Package Explorer das Projekt aus, gehe dann auf den Menüpunkt Run As und dort weiter auf den Punkt 5 JUnit Test. Das wars, jetzt können alle Tests sowohl in Maven als auch in Eclipse ausgeführt werden.

Projektmanagementfehler

2009-05-21T11:21:00.000-07:00

Hier ein Sammlung meiner liebsten Projektmanagement-Fehler:

Es wird eine neue Software entwickelt die am Markt verfügbar ist, aber in schlechterer Qualität.
Projekte mit diversen Unterprojekten werden ohne Koordinator versucht.
Projekte mit diversen Unterprojekten werden ohne Integrationskonzept und ohne Personalaufwand für die Integration versucht.
Einheitliche Richtlinien für grosse Projekte werden nicht entwickelt oder nicht umgesetzt bzw. es wird die Umsetzung wird nicht überwacht.
Usability wird als Beiwerk in Projekten betrachtet.
Projektpläne werden nicht an veränderte Bedingungen angepasst.
Hippe Techniken werden ohne Rücksicht auf die Bedingungen im Projekt eingesetzt.
Erkannte Architekturfehler werden ignoriert.
Komplexe Projekte werden ohne Entwicklungsiterationen versucht.
Zeitverzug in Projekten wird ignoriert, es wird dann auf auf die Selbstheilungskräfte im Projekt gesetzt.
Man ignoriert elementare Anforderungen des Kunden um sich selbst zu verwirklichen.
Man lässt den Kunden alles Bestimmen (zu diesem Thema gibt es übrigen eine Simpsons-Folge in der Homer ein Auto entwirft).
Gute Projektidee werden durch mangelhafte Benutzeroberflächen sabotiert, weil bei der Planung niemanden Aufgefallen ist, dass die Software durch eine GUI bedient werden soll. Selbst nach dem erkennen dieses Problem werden keine Ressourcen in die GUI investiert unter dem Motto "Wir haben eine Software mit den versprochenen Funktionen umgesetzt.", dass Niemand sie bedienen kann ist nicht unser Problem.
Schwierigkeiten in Projekten werden nicht konsequent angegangen sondern es wird entweder versucht das Problem zu ignorieren (Probleme die ich nicht sehe sind auch nicht da.) oder es wird herum lamentiert und die sich Sachen schöngeredet und versucht es nicht wie einen Fehler aussehen zu lassen.

Spring

2009-05-20T04:43:00.000-07:00

Zur Zeit arbeiten wir an einem Projekt (Server, Fat-Client) in welchem Spring eingesetzt wird. Primär wird dort nur Dependency Injection (DI) verwand. Andere Dinge wie Aspekte, Lokalisierungsunterstützung oder Messageing kamen nicht zum Einsatz. Ein Probleme die dort auftrat waren:

Hohe Startup-Zeiten des Clients
Inkonsistentes Logging
Laufzeit-Spring-Fehler
Unzureichende Integration von Spring in Eclipse

Die hohen Startup-Zeiten in Kombination mit dem Problem das viele Spring-Fehlermeldungen erst zur Laufzeit auftraten haben aus meiner Sicht die ganze Entwicklung des Projektes behindert. Aus diesen Gründen wäre es besonders sinnvoll gewesen, wenn der Projektcode Test Driven entwickelt worden wäre. So hätte man viele Zeit-fressende Iterationen den Entwicklern erspart.

TDD Vorlesung - Einführung

2009-05-19T00:50:00.000-07:00

Bei iTunes gibt es den etwas weniger bekannten Bereich iTunes U. Dort können Universitäten Podcast oder Videopodcast veröffentlichen. Hier habe ich unter anderem eine Vorlesung von RWTH Aachen zu Thema Test Driven Development von Prof. Jan Borchers (Link) gefunden. Auch wenn dort Xcode als Entwicklungsumgebung verwandt wird, so ist es doch eine gute Einführung in das Thema für Leute die sich das erste Mal mit dem Thema beschäftigen wollen. Leider enthält diese Vorführung einen sehr entscheidenden Fehler. Es wird hier demonstriert wie man Test schreibt. Was fehlt ist, wie man den Code schreibt. Bei TDD ist das schreiben von Code nicht equivalent zum schreiben von herkömmlichen Code, das hängt mit den kurzen Round-Trip-Zeiten zusammen, d.h. zwischen schreiben eines Test und dem schreiben des dazugehörigen Codes vergeht sehr wenig Zeit, z.B. eine Minute auch wird dort nur beiläufig angerissen, wie Test zu schreiben sind. Dies hat aber aus meiner Erfahrung einen entscheidenden Einfluss auf den späteren Code. Aber solche Dinge könnte man ja schon als Vertiefung des TDD ansehen. Sauberer wäre es schon gewesen, die wichtigen Dinge des TDD gleich am Anfang zu erwähnen:

Test first
Kurze Round-Trip-Zeiten
Boundary Test
Testen mit falschen Parametern (Fehlerbehandlung)
Einbeziehung von Code-Überdeckung
Übergang vom Black-Box-Testen zum White-Box-Testen

Spassvögel bei Sun

2009-05-08T00:50:00.001-07:00

Warum heisst die grundlegende Klasse in Java eigentlich Object?

Test Driven Development (TDD)

2009-05-08T00:30:00.000-07:00

Letztens wurde ich gefragt, wie ich das Problem löse, schwer testbare Klassen zu testen. Eine Möglichkeit wären natürlich Mock-Objekte, also Objekte die fürs Testen gewisse Funktionen als Dummy bereitstellen ggf. auch Datenbanken mit Testdaten aufbauen. Dies ist zwar etwas aufwendiger als das schreiben reiner Tests aber sonst nicht weiter aufregend. Da diese Antwort scheinbar nicht ausreichte, war meine nächste Antwort, dass das Objektmodell dann wohl fehlerhaft wäre und man dort ansätzen müsste. Diese Antwort war wohl nichts für Verfechter der reinen Objekt-orientierten Analyse und Entwurfs. Es wurde daraufhin auch deutlich, dass das Gegenüber unter Extreme Programming (XP) und TDD wohl nur als eine Technik wie z.B. Hibernate verstanden. XP und TDD sind an dieser Stelle mehr, sie sind ein Wechsel bei der Art und Weise wie Software entwickelt wird. Das heisst natürlich nicht, dass sich XP, TDD und Objekt-orientierte Softwareentwicklung sich ausschliessen. XP und TDD sind die nächste Evolutionsstufe der Softwareentwicklung, der Objekt-orientierten Softwareentwicklung.