javablog.ch

[Novum heute: Der erste Blogeintrag zu Objective-C bzw. XCode.]
XCode ist Apple’s IDE für die Entwicklung von iPhone und Mac-Applikationen. Allerdings ist XCode bei weitem nicht so komfortabel und mächtig wie Eclipse. Dennoch gibt es ein paar Shortcuts, die jeder iPhone-Entwickler kennen sollte:

1. cmd-shift-d (Springt schnell zu einem File, ähnlich ctrl-shift-r in Eclipse )
2. cmd-alt-up (Wechselt von .h Datei zur passenden .m Datei und umgekehrt)
3. cmd-shift-j (Refactor von Klassen, Methoden und Variablen)
4. ctrl-shift-7 (Springt zum nächsten Platzhalter)
5. cmd-shift-7 (Kommentiert markierten Code)
6. ctrl-k (Löscht aktuelle Zeile)
7. cmd-shift-e (Schaltet den Editor in der Projektansicht ein und aus)

Vor kurzem habe ich für ein bereits aufgesetztes Blackberry-Projekt einen automatischen Build für Hudson konfiguriert. Wenn Maven im Einsatz ist, ist das normalerweise schnell gemacht, aber bei diesem Projekt war der Einsatz von Maven nicht möglich. Somit bleibt einem nichts anderes übrig, als selbst ein paar Ant-Skripte zu programmieren. Klar, kein Problem. Allerdings wollte ich nicht die ganzen Projektabhängigkeiten im Ant-Skript wiederholen (DRY und so…), sie wurden ja schon im Eclipse-Projekt konfiguriert.

Aber wie bekomme ich die Informationen aus der .classpath-Datei ?

Hier hilft ant4eclipse: Der “getJdtClassPath”-Task extrahiert den Classpath aus dem Eclipse-Projekt und stellt ihn für die weitere Verwendung in ant bereit. Das nachfolgende Beispiel-Skript nutzt den extrahierten Classpath und kompiliert damit die Java-Klassen:

Praktisch.

Wesentliche neue Features:

• Erklärungstext für jede Frage
• Verbesserte Listendarstellung in “MyList”
• Und ganz wichtig: Schickeres Applikationsicon

Hier gehts zum Download. Viel Spaß beim Lernen.

Eigentlich ist es ganz einfach. Aber es wird dennoch häufig vergessen. Die Rede ist vom “Expire” HTTP-Header. Er gibt dem Webbrowser zu erkennen, ab wann eine Resource “veraltet” ist. Typischerweise werden diese Header im Webserver konfiguriert (und nicht in der eigentlichen Applikation). Hier ein Beispiel aus einer Apache HTTP Konfiguration, die dafür sorgt, dass alle statische Komponenten nach einem Tag “veralten”.

        <LocationMatch “^/static(.*)”>
                ExpiresActive On
                ExpiresDefault “access plus 1 day”
        </LocationMatch>

Allerdings besteht die Gefahr, dass Codeänderungen aufgrund des clientseitigen Caches beim Kunden erst sich nach einem Tag manifestieren. Eine Lösung ist, den Resourcen einen Timestamp des Deployments zu geben, so dass sie quasi endlos gecached werden können. Bei einem neuen Deployment erhalten die Resourcen einen neuen Timestamp. Mehr zu Frontend Best Practises gibts hier oder auch hier.

Zur Qualitätssicherung eines Softwareprojekts gehören neben Unittests auch statische Codeanalysen. Tools wie Checkstyle, Findbugs oder PMD untersuchen Java-Klassen und bewerten den Code anhand verschiedener Metriken.

Zwar können diese Checks einen manuellen Codereview nicht ersetzen, aber Standardfehler und bekannte Anti-Patterns werden zuverlässig erkannt. Für jedes der genannten Tools gibt es ein Eclipse-Plugin, das die betreffenden Codestellen markiert. Die Anzeige der Fehler ist aber nicht ausreichend: Bei schwerwiegenden Verstössen soll auch der Build scheitern, ansonsten besteht die Gefahr, dass der Code nicht korrigiert wird. Aber wie kann man das umsetzen ?

Mit Maven 2 geht dies einfach mit einer Plugin-Konfiguration innerhalb des “build”-Elements.

Hier ein Projektbeispiel für die PMD Analyse:

Mit dieser einfachen Konfiguration wird sichergestellt, dass der Code keine PMD-Verstösse der Kategorie 1 und 2 enthält. Zudem ist garantiert, dass der Build bei Copy&Paste von 100 Wörtern (bzw. Tokens) scheitert. Praktisch !

Wenn Bibliotheken von Drittherstellern nicht vollständig dokumentiert sind, und dann auch noch der Quelltext fehlt, kann ein Decompiler Abhilfe schaffen. Leider wurde die Entwicklung des kostenlosen Decompilers “JAD” von Pavel Kouznetsov eingestellt.

Seit letztem Jahres steht eine Alternative namens “JD” ebenfalls kostenlos zur Verfügung. Das Projekt ist zu finden unter http://java.decompiler.free.fr/ und bietet neben einer schicken Standalone GUI-Version auch ein Eclipse-Plugin an. Obwohl es noch nicht ganz fertig ist, hinterlässt das Tool einen sehr guten Eindruck.

Apache Maven ist ein fantastisches Buildsystem, allerdings sind manche Plugins eher spartanisch dokumentiert. Für mehr Klarheit sorgt das maven-help-plugin mit seinem “describe“-goal, welches alle Goals eines Plugins inkl. der möglichen Parameter beschreibt. Beispielaufruf:

mvn help:describe -Dplugin=org.codehaus.mojo:findbugs-maven-plugin -Dfull

Ebenso hilfreich ist das “effective-pom“-goal, mit dem ein POM inkl. aller geerbten Eigenschaften ausgegeben wird. Vor allem bei grossen Projekten mit vielen Parents ist die generierte Übersicht hilfreich. Beispiel:

mvn help:effective-pom

In der letzten Zeit gabs weniger Posts im Blog. Dies hatte auch einen Grund: jPrep. Seit ein paar Monaten beschäftige ich mit der Entwicklung von iPhone / iPod touch Applikationen. Die erste habe ich nun auf den Appstore gestellt.

jPrep ist ein Vorbereitungstool für die SCJP 6 (Sun Certified Java Programmer) Zertifizierung. In Form eines Quiz mit 175 Fragen wird der Anwender auf die Prüfung vorbereitet. Eine übersichtliche Statistik zeigt Stärken und Schwächen in den einzelnen Themengebieten auf. Als zusätzlichen Feature können die Quizfragen zu einer eigenen Merkliste (”MyList”) hinzugefügt werden. Für die meisten Fragen habe ich einen direkten Link auf die Java Reference (API oder die Java Language Specification) eingepflegt, der über den (applikationsinternen) Browser geöffnet werden kann. Hier ein paar Screenshots:

Themenübersicht

Beispielfrage

Statistik

MyList

Umgesetzt wurde es komplett mit Objective-C. Als Java-Entwickler muss man sich zwar an manche Besonderheiten der Sprache und der IDE erst mal gewöhnen, aber wenn diese Hürde geschafft ist, macht iPhone-Entwicklung richtig Spass. Apropos Spass: Für die Pflege der Fragen habe ich eine eigene Webapplikation mit Ruby On Rails geschrieben. Ging definitiv schneller als mit Java

Im Gegensatz zu Mocktests beschränkt sich ein Integrationstest nicht auf die JVM, sondern involviert auch Fremdsysteme wie Datenbanken, LDAPs oder Webservices. Ein Integrationstest ist auf immer gleichbleibende Testdaten im Fremdsystem angewiesen, muss aber ggf. auch den schreibenden Zugriff testen. Hier bieten sich Transaktionen an: Jede Testmethode läuft in einer eigenen Transaktion, die unabhängig vom Testergebnis immer wieder zurückgerollt wird. Somit bleibt das Fremdsystem in einem definierten Zustand. Dennoch sollten Integrationstests nicht auf den späteren Liveinstanzen ausgeführt werden, sondern immer auf dedizierte Testinstanzen. Allerdings sollte sichergestellt sein, dass die Test- und Liveinstanzen sich gleich verhalten.

Integrationstests bieten sich insbesondere für Dao-Klassen an, da hier der Zugriffscode für Fremdsysteme gekapselt wird. Gute Unterstützung bietet hier das Spring Framework mit den Annotationen @RunWith, @Transactional und @TransactionalConfiguration.

Beispiel-Code:

Vorteile:

• Das konkrete Verhalten eines Fremdsystems (z.B. Active Directory, oder einer MSSQL) kann abgeprüft werden.
• Fremde Webservices können automatisiert auf ihre Konsistenz geprüft werden.

Mögliche Stolperfallen:

• Integrationstests laufen nicht offline. Bei Mavenprojekten sollten sie für die Offline-Entwicklung abgeschaltet werden, da sonst der Build scheitert. Dies kann durch ein eigenes “mobile”-Profil in Kombination mit dem maven-sunfire-plugin sichergestellt werden.
• Die Testausführung dauert bei Integrationstest im Vergleich zu “normalen” JUnit-Tests wesentlich länger. Bei steigender Anzahl von länger laufenden Tests ist ein kompletter Durchlauf der Tests auf den Entwicklungsmaschinen nicht mehr sinnvoll.

Fantastisch: Das “eStore”-Projekt, an dem ich letztes Jahr in allen Projektphasen mitarbeiten durfte, wurde nun für den “Master of Swiss Web Award 2009″ nominiert.

Der nominierte eStore setzt auf der java-basierten Hybris PIM (Product Information Management) Platform auf, in der die Produktdaten aus mehreren Systemen (SAP, iPFG, Celum) zusammengefasst werden. Das Frontend haben wir mit Spring MVC umgesetzt. Viel Arbeit steckte auch in der Entwicklung des Carts und dem anschliessenden Bestellprozess. Zum Projekt gehörte ebenfalls das Aufsetzen der Infrastruktur: Vom Microsoft ISA 2006 als Webproxy bis hin zum eigenen Active Directory für die Kundenlogins war alles dabei.

Sowohl aus technischer als auch aus fachlicher Sicht ein absolut spannendes Projekt. An der Stelle ein dickes Dankeschön an alle Beteiligten !

Ach ja: Wer für unser Projekt abstimmen möchte muss sich erst hier registrieren.

Update 05.04.2009: Leider hats nicht zum Master gereicht. Allerdings können wir uns über Silber in der Kategorie Technology Quality und Bronze in der Kategorie Usability freuen.