Alle paar Monate stehe ich daher vor der Frage, was aus diesen Domains werden soll. Vergangenen Dienstag war es wieder soweit. Voller Eifer und Tatendrang, fest entschlossen einige alte Domains zu kündigen, machte ich mich ans Werk. Die erste Domain auf meiner Liste war quiek.de. Die Domain ist ja schon sehr kurz und prägnant – eigentlich viel zu schade zum Kündigen. Aber sollte die Domain deswegen weitere vier bis fünf Jahre Staub ansetzten? Nein. Somit blieben zwei Optionen: Kündigen oder mit Leben füllen.

Wenige Augenblicke später stand glücklicherweise die rettende Idee: quiek.de wird die neue Plattform für Sauerei im deutschsprachigen Netz.

Seid ihr von etwas genervt? Oder wollt ihr einfach mal Dampf ablassen? Quiek.de machts möglich (Twitter Account vorausgesetzt). Twittert dazu einfach über eine Sauerei eurer Wahl. Quiek.de findet alle Tweets die “Sauerei” enthalten und gibt diesen eine Plattform.

Wenn das mal keine Anwendung ist, auf die die Welt gewartet hat?!

Zur Technik

Im ersten Schritt habe ich versucht eine rein Client-seitige JavaScript Anwendung zu schreiben. Die einzelnen Tweets werden per AJAX und JSONP über die Twitter Search API geladen. Grafiken habe ich keine eingesetzt, sondern greife auf CSS Features wie text-shadow, box-shadow und RGBA zu.

Durch die folgenden zwei META-Elemente kann die Website gleichzeitig als Mobile Web App verwendet werden:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />
<meta name="apple-mobile-web-app-capable" content="yes" />

Ergänzend wird mit Hilfe von CSS Media Queries die Schriftgröße und der Seitenrand für die Darstellung auf kleinen Bildschirmen optimiert.

Damit die Seite einen kleinen Mehrwert zur Sauerei auf Twitter hat, können Nutzer einzelne Sauereien “liken” und so die Top Ten der quiek.de Sauereien bestimmen. Die Top Ten sollten allerdings für alle Nutzer gelten, daher musste ich mein Plan, eine rein Client-seitige JavaScript Anwendung zu schreiben, verwerfen und überlasse die Verwaltung der “gelikten” Tweets einem kleinen PHP Script.

Mal sehen, wie es mit der Seite und meiner Domain weitergeht. Fürs Erste ist die Domain gerettet und mein Gewissen besänftigt :)

Einen ersten “Testlauf” konnte ich mit dem Vortrag schon im Rahmen unserer Whiteboard Fridays auf der Arbeit absolvieren. Ich bin gespannt auf das Feedback aus Hamburg. Die Folien folgen kurz darauf bei Slideshare.

Update: Die Folien sind inzwischen auf Slideshare verfügbar.

Als Ursachen sehe ich vor allem:

• Neue Namen (Firmenname, Abteilungsname, Teamname, …) führen zu neuen Packages während alte bestehen bleiben.
• Ohne klare Struktur ist es schwierig, neue Klassen einzuordnen. Da die vorhandenen Packages oft nicht passen, kommen fortlaufend neue hinzu.
• Nicht alle Entwickler haben den gleichen Hintergrund oder das gleiche Wissen über ein Thema und strukturieren Klassen unterschiedlich.

Das größte Problem an diesem Chaos ist, dass Anforderungen mehrfach und unterschiedlich gelöst werden. Klassen mit gleichen fachlichen Themen sind auf unterschiedlichste Packages verteilt. Betroffene Stellen sind bei Änderungen schwer zu finden und werden leicht übersehen.

Raus aus dem Durcheinander

Ich bin kein großer Freund von langen Regelwerken und Forschriften, wie zu entwickeln ist. Im Gegensatz bin ich davon überzeugt, dass sich eine klare Package Struktur eigenständig durchsetzt, sobald sie vorhanden und nachvollziehbar ist. Doch der Weg aus diesem Gewirr an Packages ist müsig. Etliche Stellen im Code müssen angepasst werden. Unsere Applikationen erstecken sich über mehrere Module hinweg, womit jede Änderung mehrere Releases mit sich zieht. Konfigurationsdateien könnten übersehen werden und Bugs im “Worst-Case” erst live festgestellt werden. Getoppt wird dies durch Suberversion Baumkonflikte beim Mergen von bereits laufenden Projekten.

Doch aller Anfang ist bekanntlich schwer und so hilft nur eins – ran ans Werk! Mit dem ersten Schritt bin ich gerade beschäftigt. Dabei werde ich alle alten Packages in neue überführen, um die offensichtlich veralteten Strukturen abzuschaffen. Danach werde ich die Anzahl der Top-Level Packages einschränken und diese nach fachlichen Themen strukturieren. Ich bin überzeugt, dass sich dieser Aufwand lohnt. Stück für Stück kristalisiert sich so die finale Struktur der Packages heraus und es wird leichter neue Klassen einzuordnen sowie bestehende Logik aufzufinden.

Die ersten Packages habe ich angepasst bzw. entfernt. Dabei sind die ersten redundaten und unbenuzten Klassen aufgefallen bzw. abgeschafft worden. Sobald die Struktur steht, werden wir darauf aufbauend die Frage der Abhängigkeit zwischen Packages angehen, also welches Package auf welches andere Zugriff haben sollte oder auch nicht. Also Augen zu und durch.

Dependencies
Zuerst muss die Expression Language API sowie die dazugehörige Implementierung aus dem Maven Repository von java.net in das Projekt eingebunden werden.

<dependency>
  <groupId>javax.el</groupId>
  <artifactId>el-api</artifactId>
  <version>2.2</version>
</dependency>

<dependency>
  <groupId>org.glassfish.web</groupId>
  <artifactId>el-impl</artifactId>
  <version>2.2</version>
</dependency>

<repository>
  <id>maven2-repository.dev.java.net</id>
  <name>Java.net Repository for Maven</name>
  <url>http://download.java.net/maven/2</url>
</repository>

Verwendung der neuen Expression Language
Um die neue Version der Expression Language zu verwenden, muss die ExpressionFactory anschließend in der web.xml registriert werden.

<context-param>
  <param-name>com.sun.faces.expressionFactory</param-name>
  <param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>

Und damit lassen sich nun auch Parameter an Methoden per Expression Language übergeben.

Entwickler üben in der Regel direkt bei der Arbeit und verursachen damit auch hier die meisten Fehler. Mit den Code Katas beschreibt Chad Fowler eine Möglichkeit dem entgegen zu wirken. Jedes Code Kata stellt eine Programmieraufgabe dar, die immer wiederholt werden kann, um Stück für Stück besser zu werden. Mit jeder Wiederholung können die Aufgaben z.B. in kürzerer Zeit, mit anderen Sprachen, in weniger Zeilen oder mit anderen Tools durchgeführt werden. Wichtig ist, dass man Spaß an der Aufgabe hat und etwas dabei lernen kann. Chad Fowler hat in seinem Blog seither 21 solcher Code Katas veröffentlicht.

Laurent Bossavit nahm diese Idee mit einigen weiteren Entwicklern auf und organisierte das erste bekannte Code Dojo. Also ein Treffen von Entwicklern, die gemeinsam versuchen ein bestimmtes Code Kata zu lösen. Mittlerweile gibt es solche Treffen immer öfter. In Deutschland organisiert z.B. die Münchner .Net-User-Group regelmäßige Code Dojos, in Finnland wird darüber berichtet oder bei der Universität von Houston.

Und was steckt hinter dem Clean Code Dojo?

Bei meiner Arbeit beschäftige ich mich sehr viel mit der Frage, wie wir unsere – über die Jahre gewachsene – Anwendung für die Zukunft wartbar halten können. Wie wir alten Code testbar machen und Stück für Stück aufräumen können. In einigen Diskussionen und Büchern bin ich dabei auf Code Reviews als Mittel gestoßen. Meine Befürchtung war allerdings, dass ein Review zu passiv verlaufen würde. Wenn eine Gruppe von 10 Leuten (um einen Beamer verteilt) über Code diskutiert, ist die Chance recht hoch, dass einige Diskussionen nur für wenige von Interesse sind und so mehr und mehr Leute abschalten und nur passiv “beisitzen”.

Unser Freelancer Florian brachte vor einer Weile das Thema wieder auf und fragte, warum wir nicht gemeinsam in kleineren Gruppen eine Aufgabe vornehmen und gemeinsam unseren Code testen, aufräumen und neu organisieren. Durch die kleineren Gruppen ist so jeder aktiver beim Thema und kann aus den einzelnen Diskussionen viel mehr für sich mitnehmen. Diese Idee fand ich spitze. Und mit meiner Vorliebe für das Buch Clean Code war der Name bald gefunden – Clean Code Dojo.

Als Zeitrahmen für unsere Treffen haben wir fürs erste drei Stunden gewählt. Auf einer Wiki-Seite werden mögliche Aufgaben gesammelt. Für jedes Treffen wollen wir uns genau eines dieser Ziele vornehmen. Die Entscheidung darüber fällt direkt zu Beginn eines Treffens. Letzten Donnerstag haben wir den ersten Versuch gestartet und damit begonnen sämtliche Coding Stylequide Violations zu beseitigen. Das Ziel war für den Anfang noch sehr einfach und passt nicht zu 100% in die Form eines Code Katas, doch es ergaben sich bereits hierbei einige interessante Diskussionen und viele Aufgaben für kommende Clean Code Dojos. Innerhalb der drei Stunden haben wir in ca. 300 Klassen 3000 Zeilen Code angepasst. Es wurde einiges gelernt und viel gelacht. Meiner Meinung nach ein Erfolg auf ganzer Linie.

Die kommenden Wochen werden zeigen, wie es weiter geht. Wir werden uns ab jetzt alle zwei Wochen treffen. Ich hoffe, dass die Motivation anhält, weiterhin viel gelernt wird und die Ergebnisse den Erfolg bestätigen.

Projekt anlegen

Um das Projekt initial anzulegen habe ich einen der Standard Maven Archetypes verwendet.

mvn archetype:generate
-> 18 maven-archetype-webapp (A simple Java web application)

Dependencies
Als Dependencies werden die JSF-API samt Implementierung, die Servlet API sowie JavaServer Pages Standard Tag Library (JSTL) verwendet.

<dependency>
  <groupId>com.sun.faces</groupId>
  <artifactId>jsf-api</artifactId>
  <version>2.0.2</version>
</dependency>

<dependency>
  <groupId>com.sun.faces</groupId>
  <artifactId>jsf-impl</artifactId>
  <version>2.0.2</version>
</dependency>

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>servlet-api</artifactId>
  <version>2.5</version>
  <scope>provided</scope>
</dependency>

<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>jstl</artifactId>
  <version>1.2</version>
</dependency>

Repository
Die JSF API sowie dazu gehörige Implementierung finden sich im Maven Repository von Java.net.

<repository>
  <id>maven2-repository.dev.java.net</id>
  <name>Java.net Repository for Maven</name>
  <url>http://download.java.net/maven/2</url>
</repository>

Plugins
Zu guter letzt wird der Tomcat wie folgt konfiguriert.

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>tomcat-maven-plugin</artifactId>
</plugin>

Eclipse konfigurieren

Zur Unterstützung der Code Completion für JSF Taglibs muss der Dateityp der JSF-Dateien (in meinem Fall .xhtml) dem Content Type JSP zugeordnet werden:

Window > Preferences > General > Content Types > Text > JSP > Add (xhtml)

Projekt mit Tomcat starten

Wird das Projekt über Maven mittels mvn tomcat:run gestartet, gibt es ein Problem: Sämtliche @ManagedBeans(s) werden nicht initialisiert und können somit nicht verwendet werden. JSF sucht an zwei Stellen nach annotierten Klassen – unter WEB-INF/classes sowie in den jar-Files im Classpath. Sowohl das Verzeichnis WEB-INF/classes als auch das Verzeichnis WEB-INF/lib existiert allerdings nur sofern das Projekt mittels Maven zum war-Archiv gepackt wurde. Um dieses Problem zu lösen, muss das Projekt mittels mvn tomcat:run-war gestartet werden.

Will man das Packen des Projekts mit jeder Änderung umgehen, gibt es eine weitere Möglichkeit:

<build>
  <outputDirectory>src/main/webapp/WEB-INF/classes</outputDirectory>
</build>

Der Nachteil an dieser Lösung ist allerdings, dass man die gesamten class-Files im src-Verzeichnis ablegt.

Software wird ständig erweitert und angepasst. Aufgrund mangelnder Disziplin und der Hektik im Projektalltag gilt dies in der Regel allerdings nicht gleichzeitig für Kommentare. Je älter ein Kommentar ist, desto höher ist die Wahrscheinlichkeit, dass es nicht mehr dem aktuellen Verhalten der Software entspricht.

Wann handelt es sich um ein schlechtes Kommentar?

Neben dem häufigen Grund, dass Kommentare veraltet sind, gibt es auch ein paar weitere Beispiele, die ich euch nicht vorenthalten möchte.

Positionsmarkierungen
Postitionsmarkierungen sind Kommentare, die größere Abschnitte im Code in einzelne kleinere Teile trennen. Anstatt Code durch Kommentare zu separieren, sollten die jeweiligen Abschnitte besser als eigenständige Methoden extrahiert werden.

// **** Form Upload ****
....
// **** Input Validation ****
....

Auskommentierter Code
Ein großer “Freund” bin ich vor allem von auskommentiertem Code. Nicht nur, dass die Aussagekraft von auskommentiertem Code gegen null geht. Schlimmer ist, dass jeder weitere Entwickler, der über diesen Code stößt, denken wird, dass dieser aus einem bestimmten Grund überlassen wurde. Mit der Zeit verändert sich der umliegende Code und das Kommentar verliert immer mehr an Bedeutung und führt einzig und allein zu Verwirrungen.

In der heutigen Zeit wird jeder Stand bei größeren Software-Projekten mit Hilfe von Versionsverwaltungssystemen wie Subversion, Git oder CVS gesichert. Wird eine bestimmte Funktionalität nicht mehr benötigt, sollte diese schlicht weg gelöscht werden. Mit einem aussagekräftigen Kommentar im Versionsverwaltungssystem, erklärt sich auch viel besser aus welchem Grund diese Funktionalität entfernt wurde.

Redundante Kommentare
Kommentare, die nichts weiter aussagen als der beschriebene Code selbst.

/**
 * Get the car
 */
public Car getCar() { return car; }

/** The name */
private String name;

Gibt es auch sinnvolle Kommentare?

Wie bereits geschrieben halte ich nicht alle Kommentare für unnötig und schlecht. Zum Ausgleich daher auch einige Beispiele für den sinnvollen Einsatz von Kommentaren.

@todo-Kommentare
Die meisten IDEs unterstützen Entwickler durch die Erkennung von @todo-Kommentaren im Code. Werden diese nicht nur als Ausrede verwendet, um unsauberen Code liegen zu lassen, ist der Einsatz solcher Kommentare auf jeden Fall in Ordnung.

Informative Kommentare
Sinnvoll finde ich auch Kommentare, die Informationen zum Kontext des Quelltext liefern. Wurde der Code beispielsweise durch einen Bugfix auf eine ungewöhnliche aber erforderliche Weise angepasst, ist es ratsam die entsprechende Stelle mit einem Kommentar zu versehen.

Kommentare in öffentlichen APIs
Eine gut dokumentierte öffentliche API ist für Entwickler ein Segen. Allerdings gilt diese Aussage nur, sofern die Dokumentation auf aktuellem Stand gehalten wird und dem Entwickler zusätzliche Informationen bietet. Kommentare für Setter und Getter halte ich auch in öffentlichen APIs für unnötig.

Nach unserem Vortrag “Die Kunst des Software Design” auf dem PHP World Kongress, diskutierten Stephan und ich noch eine Weile darüber, wie man eine bestehende Anwendung im laufenden Betrieb am besten aufräumt. Ist eine Anwendung lang genug in Betrieb und groß genug, kommt oft der Ruf nach einem groß angelegten Refactoring-Projekt. Ein Projekt, in dem Entwickler endlich einmal die Zeit haben Dinge, die schon seit langer Zeit im Argen liegen, aufzuräumen und die Anwendung wieder in Ordnung zu bringen. In den wenigsten Fällen werden solche Projekte allerdings genehmigt oder entsprechend priorisiert.

Robert C. Martin schreibt in seinem Buch Clean Code, dass Code über die gesamte Lebensdauer “sauber” gehalten werden muss und findet dafür eine treffende Regel der amerikanischen Pfadfinder: “Leave the campground cleaner than you found it”. Der einzelne Schritt beim Aufräumen muss dabei gar nicht groß sein. Ob eine lange Methode aufgebrochen, eine Duplikation eliminiert oder der Name einer Variable in einen ausdrucksvolleren Namen geändert wird, spielt dabei keine Rolle. Wenn der Code einer Anwendung mit jedem Commit ein kleines Stück sauberer wird, als er es zuvor war, wird die gesamte Anwendung nicht verrotten (siehe auch Broken-Window-Theorie).

Letztendlich sind wir zu dem Entschluss gekommen, dass in dem für gewöhnlich hektischen Alltag der Weg von Robert C. Martin genau der Richtige ist. Der Fokus bei der Entwicklung liegt allerdings eher auf einem konkreten TODO, anstatt auf dem Aufräumen der Codebasis. Probleme im Code werden zwar oft erkannt, aber nie korrigiert, da man gerade an etwas anderem dran ist. Aus diesem Grund wollten wir ein Poster gestalten, das einige kleine “Aufräum-Arbeiten” auflistet und dazu ermuntert in kleinen Schritten das große Ziel zu erreichen. Nachdem Stephan bereits die Punkte gesammelt hatte, habe ich heute das Poster fertig gestellt. Ich bin gespannt, wie es ankommt und zu welchem Ergebnis es führen wird.

Die Pfadfinder-Regel als A4 Poster als JPEG zum Download (ca. 1.1 MB)

Interessant war das Buch für mich in erster Linie wegen OSGi. Vor dem Lesen des Buches wusste ich zwar grob, um was es bei OSGi ging, der praktische Nutzen war mir allerdings nicht wirklich ersichtlich. Da die Version 1.0 des Open Source Frameworks Pustefix, auf dem die Bestellprozesse bei 1&1 basieren, nun auch auf OSGi setzt, wollte ich mehr über OSGi erfahren und im Idealfall auch direkt erste praktische Erfahrungen sammeln. Genau dies erfüllt Craig Walls auf gerade mal 200 sehr gut zu lesenden Seiten.

Das Buch ist in drei Teile untergliedert. Im ersten Teil “OSGI Fundamentals” werden die Grundlagen von OSGi kurz und knapp erklärt und die Entwicklung des Hello World Beispiels im OSGI Style beschrieben. Anschließend wird die Beispielanwendung “Dude, Where’s My JAR” eingeführt und der Umgang mit Bundles sowie die Entwicklung von OSGi Services genauer beschrieben. Im zweiten Teil “Spring Dynamic Modules and Web Bundles” erklärt Walls neben Spring Dynamic Modules und Web Bundles auch wie man OSGi Bundles erweitern kann. Den Abschluss bildet der Teil “Finishing Touches” in dem es um OSGi im Live Betrieb sowie die Konfiguration der Anwendung geht.

Interesse geweckt? Das Buch könnt ihr hier direkt bei Amazon bestellen.

Semantische Auszeichnung der Inhalte

Da ich für meine Website ein eigenes WordPress Theme erstellt habe, war die Erfüllung des ersten Punktes keine große Herausforderung. WordPress Themes bestehen aus einer Reihe von PHP-Dateien mit bestimmten Namen (beispielsweise header.php, footer.php oder home.php). Hat man eine fertige XHTML Vorlage seiner Website, kann man diese direkt in die von WordPress vorgesehenen Dateien aufteilen. Somit hatte ich bei der Auszeichnung der Inhalte in XHTML alle Freiheiten. Die Auszeichnung von Inhalten, die dynamisch hinzugefügt werden, können leicht angepasst werden. Und die Inhalte des Rich Text Editor werden ebenfalls korrekt formatiert.

In dem Artikel High Accessibility Is Effective Search Engine Optimization geht Andy Hagans bei A List Apart auf den Zusammenhang von Accessibility und Suchmaschinenoptimierung ein. Ein netter Nebeneffekt einer Website mit validem XHTML und reicher Semantik ist, dass sie auch sehr gut bei Suchmaschinen gelistet wird. Um die Qualität einer Website zu messen, empfehle ich die Firefox Extesion SenSEO von meinem Kollegen Nico Steiner.

Sprechende URLs

URLs sehe ich als eine Art API der Website an. Eine URL sollte daher einerseits die Struktur der Website wiederspiegeln. Anderseits sollte sie aber vor allem einfach, benutzerfreundlich und beschreibend sein. In WordPress nennen sich sprechende URLs Permalinks. Das Format dieser Links kann relativ einfach über die Einstellungen des Blogs konfiguriert werden. Schön finde ich dabei, dass direkt beim Schreiben eines Artikels der Seitenname angezeigt wird und editiert werden kann.

Mit den Namen meiner URLs habe ich versucht einen Satz zu konstruieren. Artikel der Kategorie Clean Code können z.B. wie folgt aufgerufen werden:

rueprich.de/bloggt/ueber/clean-code

Und Projekte, an denen ich bisher gearbeitet habe können unter arbeitet-an/PROJEKT-NAME aufgerufen werden.

rueprich.de/arbeitet-an/fitness-beruf

Bei Blog-Einträgen habe ich eine Ausnahme gemacht, da es relativ schnell passieren kann, dass ein Titel mehr als einmal verwendet wird. Aus diesem Grund habe ich den Monat und das Jahr der Veröffentlichung in die URL mit aufgenommen:

rueprich.de/bloggt/2010/01/rueprichde-behind-the-scenes

Der Vorteil an diesen URLs ist, dass man so z.B. auch alle Einträge im Januar 2010 ansehen kann:

rueprich.de/bloggt/2010/01

Oder alle Artikel von 2009:

rueprich.de/bloggt/2009

In WordPress konnte ich die URLs über zwei Felder in den Blog-Einstellungen konfigurieren. Für Blog-Einträge verwende ich diese benutzerdefinierte Struktur:

/bloggt/%year%/%monthnum%/%postname%

Und als Basis für Kategorien verwende ich:

bloggt/ueber

Wenn ihr auch eine Vorliebe für sprechende URLs habt, kann ich euch den Artikel von Chris Shiflett URL Vanity empfehlen.

Performance

Um eine gute Performance für meine Website zu erreichen, habe ich versucht alle Inhalte so klein wie möglich zu halten. Aus diesem Grund habe ich versucht mit so wenig HTML-Elementen, CSS-Klassen und -Eigenschaften wie möglich auszukommen. Die Bilder habe ich in Photoshop direkt für das “Web” gespeichert, daher sind diese bereits sehr gut komprimiert. Hover-Effekte bei Bildern habe ich mit Hilfe von CSS Sprites umgesetzt, um die Anzahl der HTTP-Request zu verringern. Denn viele HTTP-Requests führen zu einer längeren Ladezeit. Ein weiterer Vorteil von CSS Sprites ist, dass die Bilder im Hover-Zustand bereits geladen sind und es so nicht zu einem kurzen Flackern beim ersten “hovern” kommt.

In dem Artikel “Speed Up: Optimierungstipps für Ihre Seiten” fasst Nelly Brekardin bei Dr. Web einge Tipps für die Optimierung von Websites zusammen. Für meine Website war vor allem der Punkt “Die richtigen HTTP-Header senden” hilfreich. Hier wird beschrieben, wie man mit Hilfe der .htaccess Konfiguration die HTTP-Header Expires und Cache-Control sendet und textuelle Inhalte per gzip komprimiert.

Ein guter Einstieg für die Performance-Optimierung einer Website ist die Firefox Extension YSlow. Diese misst unterschiedliche Kriterien auf der Seite und beurteilt diese in Noten von A – F. Zu jedem Punkt gibt es eine Erklärung und Tipps, wie man die entsprechende Note verbessern kann. Unter dem Reiter “Statistics” sieht man darüber hinaus, wieviel Speicher die Website beim ersten Laden und wieviel Speicher die Site im “gecachten” Zustand benötigt.

Wer sich für dieses Thema interessiert, dem sei auch der Artikel “Best Practices for Speeding Up Your Web Site” empfohlen.