Glücklicherweise unterstützt mich meine Frau Helena bei dem Vorhaben im Bezug auf die Inhalte auf der Seite und den dazugehörigen Social Media Seiten.

Neben dem Nutzen der Seite zur Freizeitgestaltung mit unseren Kids, ist die Seite für mich vor allem spannend,

• um zu sehen wie viele Leute sich für solch eine Seite über welche Wege motivieren lassen.
• wie viele Personen die Seite aktiv durch Feedback und eigene Vorschläge mit entwickeln.
• wie die Seite für Suchmaschinen optimiert werden kann.
• wie viel Traffic über Soziale Netzwerke auf welche Art auf die Seite gelenkt werden kann.
• und natürlich ob bzw. wie heute so eine Nischen-Online-Community überhaupt aufgebaut werden kann.

Ich bin wirklich sehr gespannt, was aus der Seite wird. Über eure Unterstützung würde ich mich daher natürlich sehr freuen.

Der Beitrag Wollt ihr mit euren Kids etwas unternehmen? erschien zuerst auf Holger Rüprich.

Im Online Marketing wird seit einigen Jahren eine Technologie genutzt, die einen weiteren Schritt in dieser Entwicklung darstellt: Targeting.

Auf Wikipedia wird zwischen den folgenden Formen des Targetings unterschieden:

• Content-Targeting
• Semantisches Targeting
• Behavioral-Targeting
• Predictive-Behavioral-Targeting
• Retargeting
• Social-Media-Targeting

Zusammenfassend geht es darum, aus vorhandenen Informationen möglichst genaue Nutzerprofile zu erstellen und Inhalte nach Relevanz für diese Profile auszusteuern.

Die Website von Amazon ist hierfür ein beispielhaftes Vorbild. Kaum eine andere Firma versteht es so gut wie Amazon, Besuchern genau die Inhalte zu präsentieren, nach denen diese auf der Suche sind. Doch auch die Online Werbung von Zalando zeigt was möglich ist. Wurde der Online Shop einmal besucht, wird man beim Surfen regelrecht von Zalandos Retargeting-Maßnahmen mit den zuletzt angesehen Schuhen verfolgt.

Zur Erkennung einzelner Benutzer wird in der Regel auf Cookies gesetzt. Anbieter wie nugg.ad, Persuasion Engines, oder United Internet Media bieten bereits fertige Targeting Lösungen. Damit einher gehen allerdings teilweise sehr hohe Kosten sowie der Umstand, dass etliche Daten an externe Firmen übertragen werden. Eine In-House-Lösung bietet dagegen die Möglichkeit gesammelte Informationen weiter anzureichern und mit Offline-Kanälen wie Mailings oder Telefonaten zu verbinden.

Ob die personalisierte Ansprache von allen Nutzern positiv oder eher als unheimlich empfunden wird, ist eine ganz andere Frage.

Eine Sache steht allerdings fest – mit steigender Anzahl an Inhalten im Web, wird es immer schwieriger den Überblick zu behalten und relevante Inhalte aufzufinden. Nicht ohne Grund versucht selbst Google bereits seit einiger Zeit Suchmaschinen-Ergebnisse zu personalisieren.

Der Beitrag Targeting – Die Personalisierung des Web erschien zuerst auf Holger Rüprich.

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 :)

Der Beitrag Eine riesen Sauerei – Quiek.de erschien zuerst auf Holger Rüprich.

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.

Der Beitrag Mobile Web Apps: Wie, Warum, Womit? erschien zuerst auf Holger Rüprich.

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.

Der Beitrag Package Chaos erschien zuerst auf Holger Rüprich.

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.

Der Beitrag Expression Language 2.2 mit Maven und Tomcat erschien zuerst auf Holger Rüprich.

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.

Der Beitrag Clean Code Dojo erschien zuerst auf Holger Rüprich.

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.

Der Beitrag JSF 2.0 mit Maven und Tomcat erschien zuerst auf Holger Rüprich.

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.

Der Beitrag // Kommentare im Code erschien zuerst auf Holger Rüprich.

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)

Der Beitrag Clean Code mit Hilfe der Pfadfinder-Regel erschien zuerst auf Holger Rüprich.