Die expeso GmbH hat das zweite Java-Trendbarometer veröffentlicht. Die Ergebnisse lassen sich nach einer Registrierung in Gänze einsehen. In Auszügen sind die Ergebnisse auch auf heise online verfügbar:

So empfinden 75 Prozent der Teilnehmer die Bedeutung der Qualitätssicherung in ihren Projekten als “zu gering”.

In Kommentaren zum verwendeten Prozess fielen Äußerungen wie “brain driven”, “chaos driven”, “code & fix” und “pseudoagil”. Die Qualität leide unter der häufig sehr stark termingetriebenen Entwicklung.

Agilität bei codecentric

Wie wichtig automatisierte Tests und ein partnerschaftlicher, agiler Prozess mit dem Kunden ist, hat codecentric schon lange verstanden und dementsprechend als Kernpunkte der Unternehmensstrategie festgesetzt. Dies schlägt sich unter anderem in den erfolgreichen Kundenprojekten nieder, siehe dazu auch unsere veröffentlichen Success Stories, die bald noch erweitert werden. Desweiteren unterstreicht die Vielzahl der zertifizierten Scrum Master, dass die Strategie auch vom Unternehmen ideal unterstützt wird.

Aber, allein die Erkenntnis, dass dies der richtige Weg ist reicht nicht, und so wird es vermutlich auch den 82 Teilnehmern an der Umfrage zum Trendbarometer gehen. Viele der Teilnehmer (78%) sind in externen Kundenprojekten tätig, das heißt sie sind dort eventuell auch wider besseren Wissens und ihrer Erfahrung zu den Prozessen genötigt, die der Kunde für ideal befindet.

Continuous Integration

Wie schwierig nach der Erkenntnis die tägliche Umsetzung agiler Softwareentwicklung ist, erfahren wir alle jeden Tag auf’s neue. Das unbequeme an effizienten Prozessen ist, dass alles, was den Prozess ineffizient macht, sofort auffällt. Im Laufe der Zeit entwickelt sich das Team und das gesamte Unternehmen aber weiter (wichtig: Reflection Sessions!), allerdings ist es kein Prozess, der von einem Tag auf den anderen stattfinden kann, da sowohl kulturelle als auch Aspekte der IT-Infrastruktur dem Änderungsprozess unterliegen.

Äußerst hilfreicher Teil der IT-Infrastruktur ist eine Umgebung, welche die Software laufend kompiliert, baut, “unit-testet”, installiert und auch automatisch “integration-testet”. Nur die Kompilierung, der Unit-Test und Zusammenbau der installierbaren Artefakte, also eine “Continuous Integration”-Umgebung, also eine stetige Integration aller Komponenten, jeweils auf dem neuesten Stand, geradezu notwendig. Selbst dies wird aber nur (laut Studie) bei ca. 45% der Befragten “häufig” eingesetzt (ca. 22% “nie”; ca. 33% “teilweise”). Da aber mehr als 60% der Teilnehmer angegeben haben agil zu entwickeln, verwundert es nicht, dass die Qualität leidet, wenn die unterstützende IT-Infrastruktur fehlt. Immerhin wird dies als Mängel erkannt: fast jeder zweite befragte Java-Experte empfindet die in Projekten vorhandenen Integrationsmechanismen als nicht ausreichend.

Anforderungsanalyse

Noch interessanter ist aber der folgende Punkt (Zitat aus der Studie):

60% der Java-Experten sagen, dass der Anforderungsanalyse zu wenig Bedeutung zugemessen wird. Diese Zahl ist schockierend, zumal die Anforderungsanalyse die Basis der gesamten Entwicklung darstellt und die Notwendigkeit einer optimalen Anforderungsanalyse bekannt ist.

Nun fehlt hier leider die Information wie viel Zeit denn absolut in die Anforderungsanalyse gesteckt wird, um beurteilen zu können wie viel noch als zu wenig angesehen wird. Ich denke aber, dass hier ein anderes Problem offenbar wird: Es ist einfach nicht möglich ein interaktives und komplexes System von A bis Z zu spezifizieren, und alle Rand-, Sonder- und Fehlerfälle zu berücksichtigen. Dies zu versuchen zeugt allein davon, dass der Prozess nicht agil sein kann. Und selbst wenn man es geschafft hat alle Anforderungen zu berücksichtigen, besteht immer noch das Risiko, dass die analysierten Features nicht umgesetzt werden, da 3 Monate nach der Anforderungsanalyse der Kontext ein ganz anderer ist (andere Anforderungen, andere Prioritäten, andere Laufzeitumgebung, andere Wirtschaftslage, etc.). Das ist genau die Krux und bei iterativem Vorgehen am schwierigsten umzusetzen: Zu akzeptieren, dass sich Anforderungen ändern, dass nicht alle Sonderfälle bekannt sind, und einen Prozess zu finden damit zurecht zu kommen.

Weiterbildung

Laut Studie bilden sich die Java-Experten hauptsächlich durch das Internet, Bücher und Zeitschriften weiter. Nur weniger als die Hälfte besuchen Seminare (teilweise auch durch die Firmenpolitik bedingt) und noch weniger lassen sich coachen oder nehmen andere Angebote in Anspruch.

Wie wertvoll die Diskussion mit Experten sein kann, steht so hoffe ich außer Zweifel. Deshalb möchte ich zum Abschluss noch kurz auf unser anstehendes Event “Meet the Experts” zum Thema Agilität aufmerksam machen, das schon am 4. September bei uns stattfinden wird. Es werden ausgewiesene Experten einem kleinem Kreis an Teilnehmern (limitiert auf 100) durch Vorträge und viele Diskussionen ihr Wissen weitergeben. Zudem bieten wir eine Zertifizierung zum Product Owner an, um die oben beschriebene Problematik der Anforderungsanalyse besser in den Griff zu bekommen.

Insgesamt eine gute Möglichkeit seine Kenntnisse im Bereich der Agilität auszubauen. Angelehnt an das agile Manifest gilt:

Das erste Meet the Experts – Performance im Juni war für alle Beteiligten ein erlebnisreicher Tag, an den man oft und gerne zurückdenken kann; wegen der dort geknüpften Kontakte, den neu erworbenen (Er-)kenntnissen oder den interessanten Gesprächen – vielleicht auch nur wegen des guten Essens (Präsentationen & Bilder sagen mehr als 1000 lobende Worte!)

Der Inhalt des zweiten Meet the Experts steht fest und ich freue mich, dass wir es auch zum nächsten Thema Agilität geschafft haben, die Experten im deutschsprachigen Raum versammelt zu haben:

• Simon Roberts ist freiberuflicher agile-Software Entwickler und Projekt-Manager, zertifizierter Scrum-Master und registrierter PRINCE2 Anwender. Seine Engagements bestehen oft darin, die ersten Schritte einer Organisation mit agiler Softwareentwicklung zu leiten. Das gemeinsame Thema, das seine gesamte Arbeit verbindet, ist seine Leidenschaft, Organisationen zu helfen, effektivere Wege für ihre Softwareprojekte zu finden.
• Boris Gloger war der erste Scrum- zertifizierte Trainer in Europa. Seit 2004 arbeitet er als freiberuflicher Scrum Consultant.
  Nachdem er für einige europäische Firmen als Projekt-Manager, Team-Leiter und Leiter der Software-Entwicklung (EDS, Broad Vision, ONE, Web.de) gearbeitet hat, entschloss er sich, sich nur noch auf Scrum zu fokussieren.
• Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (eXtreme Programming, Scrum, FDD) als Entwickler, Projektleiter und Berater. Darüber hinaus hat er zahlreiche Artikel und Tagungsbeiträge über agile Softwareentwicklung verfasst und ist Autor der Bücher “Software entwickeln mit eXtreme Programming” und “Agile Softwareentwicklung”. Henning Wolf hilft Unternehmen und Organisationen agile Methoden erfolgreich einzuführen.
• Dietmar Strasser ist Director of Quality Assurance in Borlands größtem Entwicklungslabor in Linz, Österreich. Er ist seit über 12 Jahren zentraler Bestandteil des Silk Entwicklungsteams. Als Qualitätsmanagement Coach ist er seit Anfang 2008 verantwortlich für die ständige Verbesserung der Software Qualitätsprozesse, unterstützt mit seinem Domänenwissen die Scrum Teams dabei, neue Funktionalität mit bestmöglicher Qualität in die Produkte einzubauen und ist für die Zusammenarbeit mit dem Enterprise Quality Center in Singapur verantwortlich.
• Andreas Ebbert-Karroum ist der Leiter des Competence Centers Agilität bei codecentric. Seit mehr als 3 Jahren ist er zertifizierter Scrum Master. Seitdem konnte er seine Kompetenzen in kleinen wie großen (> 300 Personen), internen wie externen und lokalen wie globalen Projekten als Entwickler, Scrum Master oder Product Owner einbringen. Sein Fokus bei codecentric ist die ständige Verbesserung des Entwicklungsprozesses in echten Projekten, wobei die technischen, organisatorischen und sozialen Möglichkeiten die spannenden externen Rahmenbedingungen schaffen.

Nachdem der Tenor des Performance-Events sehr technischer Natur war, viel Code und Diskussionen durch die Tiefen der JVM, wird es bei Agilität auf einer anderen Ebene interessant. Es wird darum gehen, wie man Projekte mit agilen Methoden erfolgreich durchführen kann, wie diese in kleinen und großen Unternehmen dauerhaft eingeführt werden können und wie sich das auf die Zusammenarbeit im Team auswirkt. Zudem bieten wir dem Meet the Experts vorgelagert eine offene Schulung zum “Certified Scrum Product Owner” an. Der Product Owner wird häufig als die am schwierigsten auszufüllende Rolle in Scrum bezeichnet, interessanterweise gibt es aber nur wenige Schulungen dazu. Umso mehr freuen wir uns, Simon Roberts als kompetenten Partner und Experten für die Schulung gewonnen zu haben. Konkret sieht die Agenda somit für das Meet the Experts zum Thema Agilität folgendermaßen aus:

Certified Scrum Product Owner | 02.09.- 03.09.2009

Simon Roberts wird im kleinen Kreis (limitiert auf 20 Teilnehmer!) erläutern, was einen guten Product Owner ausmacht, und wo die Tücken und Fallstricke liegen (und natürlich wie diese umgangen werden können). Inhaltlich werden wichtige Themen abgedeckt wie: Agile Grundlagen, Product Vision und Backlog, Agile Aufwandschätzungen, User Stories, Releaseplanung, Controlling und Reporting, Skalierung von Scrum und Retrospektiven. Details finden sich auf der Meet the Experts Homepage im Bereich Schulungen, wo man sich auch direkt anmelden kann.

Meet the Experts – Agilität | 04.09.2009

Das Meet the Experts wird in bewährter Weise durchgeführt, erstklassige Rahmenbedingungen, Vorträge und ein “Open Space” um auch Themen platzieren zu können, die den Teilnehmern am Herzen liegen, sich aber nicht in den Vorträgen wiederfinden. Die Vorträge unserer Experten sind:

1. Henning Wolf: Agile Methoden im Überblick: Scrum, XP, FDD, Kanban
2. Andreas Ebbert-Karroum: Scrum Best Practices
3. Boris Gloger: Going Large By Staying Small
4. Dietmar Strasser: Agile Transformation aus Sicht eines QS Managers
5. Simon Roberts: Making Scrum Stick: Sustainable Enterprise Transitions

Trotz teilweiser englischer Titel sind die Vorträge selbst natürlich alle auf Deutsch. Die Anmeldung zum Event ist freigeschaltet, und ich freue mich schon auf den Tag und unsere Gäste. Vielleicht sehen wir uns ja auch schon vorher auf der Agile 2009 in Chicago?

Hier einige interessante Statistiken zur coding night. Da die coding night ein “Projekt im Zeitraffer” war, sind die von Hudson bei den automatischen Builds erstellten Statistiken ganz interessant.

JUnit Test Ausführung

Das erste was auffällt ist, daß es erst ab Build #68 Testergebnisse gab. Der Build fand um 22:28:56 statt, was etwas mehr als 6 Stunden nach dem ersten commit (16:01:27) entspricht. Der Grund ist zum einen, daß erst Verzeichnisstrukturen in den ersten commits aufgesetzt wurden. Zum anderen ist TDD bei nicht vorhandener codebasis auch recht schwer, zumal die ersten Stunde wirklich eher unkoordiniert waren (das erste Scrum of Scrums zur Synchronisation fand um 20 Uhr statt). Allgemein positiv ist der konstante Aufwärtstrend. Die fehlgeschlagenen Tests sind hauptsächlich einem größeren Refactoring geschuldet. Zudem verhinderte zeitgleiches Grillen, daß diese Fehler schnell bemerkt und korrigiert wurden.

Testabdeckung

Der Graph ist auch sehr aufschlussreich, so erkennt man daß die Testabdeckung sehr breit ist, da etwa 90% aller Klassen und Packages abgedeckt wurden. Daß die “Conditionals” rapide fielen hatte den Grund, daß die Software in der Tat bis Build 83 keine If Verzweigung enthielt. Dies spricht für eine sehr geringe Komplexität, welches der Verwendung von Spring anzurechnen ist, da man selber keine Verzweigungen programmieren muss wenn man immer die richtigen Objekte vom Container übergeben bekommt. Zwar versuchte man dann auch später implementierte Verzweigungen abzudecken, war aber nicht wirklich erfolgreich. Dies liegt meiner Meinung nach daran daß die Verzweigungen durch Fehler/Exception Handling entstehen und nicht so schön testbar sind. Die steigende Methoden und Zeilenabdeckung ist gut, aber insgesamt viel zu niedrig. Die Ursachen dafür sind allerdings nachvollziehbar. So schlagen sich vorbereitete aber nicht genutzte Services (toter code) durch.  Auch die Modellklassen und unzählige Getter und Setter sind teilweise nicht extra getestet.
Zusammen zeigen die ersten beiden Statistiken ein positives Bild. Kontinuierliches Testen erfolgt auch in stressigen Projekten und bringt eine gewisse Sicherheit über die Qualität.

Code Wachstum

Abgebildet sind die Zeilen selbstgeschriebenen Codes über Zeit. Man sieht den schnellen Wachstum der Zeilenzahl. Es sieht also nach einem sehr produktivem Projekt auch. Die Verteilung des Codes auf die Entwickler ist interessant, man ist fast geneigt zu sagen: 20% der Entwickler haben 80% des Codes geschrieben. Allerdings relativiert sich dies etwas dadurch, daß die Anwesenheit an dem Wochenende stark schwankte. Die 4-6 stärksten Balken verteilen sich somit auch auf die Entwickler welche fast permanent anwesend waren. Eine Anmerkung am Rande: Letzendlich ist es doch erschreckend, wie viel Code für relativ wenig Funktionalität benötigt wurde. Diesen Kritikpunkt muss Java leider einstecken.

Code Typ

Das Tortendiagramm zeigt es deutlich. Wir haben hauptsächlich Java code geschrieben. JSPs wurden als Views genutzt. XML ist kaum vorhanden, da wir größtenteils Annotations verwendet haben anstelle von langen Spring Konfigurationen. Ausgeblendet aus dieser Ansicht sind Javascriptbibliotheken welche eingebunden wurden aber im src Verzeichnis liegen und damit von FishEye als unser Code gezählt wird. Auch zeigt die Verteilung, daß relativ wenig untestbarers entstanden ist. Ausser den Views, welche in egal welcher Form immer problematisch sind, ist fast der komplette Code mit Java Mitteln testbar.

Dieses Wochenende haben wir ein interessantes Experiment gestartet: Mit einem großen Team 48h gemeinsam programmieren. Der Grund? Spaß haben, neue Technologien ausprobieren und die Grundideen für unsere Agile Software Factory zu überprüfen. Die Agile Software Factory werden wir bald offiziell vorstellen. Dabei handelt es sich um eine Dienstleistung für die Erstellung von Individualsoftware auf Basis agiler Methoden (basierend auf Scrum und eXtreme Programming), etablierten Technologien und Architekturen sowie natürlich unserem Team von Experten, die mit der bei codecentric gelebten 4+1 Woche jeweils einen Tag pro Woche Zeit für Weiterbildung und Innovation haben.

Mit fast 28 Programmierern sind wir am Freitag um 14 Uhr gestartet eine Zeiterfassungssoftware zu schreiben, die automatisch Rechnungen für unserer Kunden erzeugt. Das Backlog wurde dafür von unsererm Product Owner Stephan erstellt und in einer ersten Präsentation allen Teilnehmern vorgestellt. Danach wurden insgesamt vier Teams mit je sieben codecentricern ausgelost und die Features auf die Teams verteilt. Gegen 15 Uhr haben wir dann mit dem Product Planning begonnen und die Entwicklunsgumgebungen aufgesetzt. Die Kommunikation zwischen den Teams wurde in so genannten Scrum of Scrums organisiert. In zwei Sprints von je 24h wollten wir das Produkt so weit wie möglich fertigstellen. Jedes Team Mitglied konnte natürlich jederzeit zum Schlafen nach Hause fahren (einige haben auch die Couches bei uns in den Büros genutzt) und zwischendurch haben wir mehrfach unseren Grill angeworfen.

Das Event hat sich für uns als wertvoller herausgestellt als urspünglich angenommen. Durch die kurzen Sprints von nur 24h wurde praktisch ein Großprojekt (immerhin 28 Entwickler in 4 Teams) im Zeitraffer durchgeführt. Probleme in der Methodik und Technologie wurden somit sehr schnell transparent und die Teams mussten adhoc Lösungen finden. Am Ende war tatsächlich auch ein Großteil des Product Backlogs umgesetzt. Fazit für uns:

• Die Kommunikation zwischen den Teams mit Scrum of Scrums hat gut funktioniert
• Die Architektur hat sich während der kurzen Sprints schnell entwickelt
• Gemeinsame Code Ownership ist wichtig – jeder kann den Code ändern, wenn er ein Problem hat
• Die eingesetzten Frameworks müssen verstanden werden und zusammen funktionieren, damit der “technische Overhead” minimiert wird
• Automatisierter Tests und Continuous Integration sind gerade bei kurzen Iterationen und großen Teams extrem wichtig und sparen Zeit

Wir werden die Ergebnisse der coding night für uns genauer analysieren und in die Competence Center bei uns geben, um die aufgedeckten Schwachstellen bei Vorgehen und Technologien noch abzustellen. Immerhin wollen wir mit der Agilen Software Factory die höchste Produktivtät auf dem Markt erzielen und müssen die Methodik deshalb kontinuierlich verbessern. Sicherlich wird das nicht das letzte Event dieser Art sein und wir überlegen es in Zukunft auch für Gäste und Kunden zu öffnen.

[Show as slideshow]

Am 26. Juni haben wir unser erstes meet the experts zum Thema Performance bei uns in Solingen durchgeführt. Die Ideen zu diesem Event wurden bereits in einem eigenen Blog Eintrag beschrieben. Für das erste Event hatten wir uns 30 Teilnehmer vorgenommen, wurden aber schnell von der großen Resonanz überrascht. Insgesamt 96 Teilnehmer konnten wir am Ende begrüßen. Ein riesiger Erfolg für uns und eine Motivation diese Event weiter auszubauen. Die Idee anerkannte Experten einzuladen und den Erfahrungsaustausch zu fördern scheint auch nach der Auswertung der Feedbackbögen sehr gut angekommen zu sein – fast alle Teilnehmer bewerteten den Gesamteindruck der Veranstaltung mit “sehr gut“. Die Votragsreihe habe ich mit dem Thema Performance Antipatterns begonnen – inhaltlich eine Zusammenfassung der gleichnamigen Java Magazin Kolumne, dessen Artikel auf unserer Webseite zu finden sind. Da 60 Minuten für das Thema sehr kurz sind, hatte ich mich auf Basis unserer Performance Studie auf die beiden Themen Remoting/Serialisierung und O/R Mapping konzentiert. Von den Teilnehmern der Studie wurden diese beiden Themen als besonders Performance kritisch eingestuft. In den eigenen Räumen vor 96 Java Performance Experten und Interessierten zu sprechen war für mich persönlich ein sehr schönes Gefühl und es hat mir unheimlich Freude bereitet in dieser lockeren und familiären Umgebung ein interessantes Thema zu präsentieren. Direkt nach mir hat Kirk Pepperdine einen Vortrag gehalten in dem er “live” gezeigt hat, wie man eine Anwendung mit Open Source und JVM internen Werkzeugen analysieren und optimieren kann. Kirk legt besonders viel Wert darauf, dass man die Performance Probleme mit den Werkzeugen zunächst eingegrenzt, um dann ganz gezielt im Code Optimierung vornehmen zu können. Hierfür teilt er eine Java Anwendung in mehrere logische Schichten ein, in denen sich Performance Probleme manifestieren können. Angefangen vom System, über die JVM bis hin zum Anwenungscode. In seinem Beispiel konnte man sehr schön nachvollziehen wie er bei einer Problemanalyse vorgeht und wie gezielt er mit einfachen Mitteln Probleme identifizieren kann. Zu den eingesetzten Tools zählten unter anderem jstack, jconsole, HPjmeter, der NetBeans Profiler und VisualVM. Insgesamt hat Kirk seine Zuhörer nicht enttäuscht: Eine sehr witzig und interessant vorgetragene Präsentation mit sehr viel Input für den Alltag. In der Mittagspause konnte wir die Gespräche in unserem neu renovierten Dachgeschoß bei einem leckeren Buffet vertiefen. Dr. Heinz Kabutz war zu dieser Zeit gerade in Düsseldorf gelandet und auf dem Weg zu uns. Sein Votrag nach dem Mittag war sicherlich eines der Highlights des Tages. Zunächste überrascht er viele Teilnehmer mit seinem fließend gesprochenen Deutsch, das er von seinen deutschstammigen Eltern erlernt hat. Er lebt heute aber auf der schönen Insel Kreta und hat uns seine Wahlheimat auch direkt mit netten Bildern vom Meer (direkt vor seiner Haustür) schmackhaf tgemacht. Tags zuvor hatte er noch mit einem Tintenfisch gekämpft, der Ihn zwar in den Finger gebissen hat, aber trotzdem auf dem Mittagstisch gelandet ist. Neben diesen immer wieder eingeworfenen Kreta-Anekdoten hat Heinz 10 Geheimnisse rund um Java Concurrency vorgestellt. Aus meiner Sicht ein sehr interessantes und wichtiges Thema, das er sehr anschaulich vermittelt hat. Freue mich schon Ihn auf seinem Java Specialist Master Course im September wieder bei uns begrüßen zu können – auch die Schulung wird er erstmalig auf deutsch halten. Den letzten Vortrag des Tages hatte Alois Reitbauer von dynaTrace zum Thema Continuous Performance Management. Alois stellte dabei eine Methodik vor, mit der man Performance Probleme bereits sehr früh in der Entwicklung feststellen kann. Dafür intergiert man Performance Analysen in ein Continuous Integration Build System und versucht Performance Antipatterns zu identifizieren. Alois erläuterte, dass dieses Vorgehen den klassischen Performance Tests nicht ersetzen kann, aber die in der Entwicklung gefundenen Performance und Skalierbarkeitsprobleme deutlich günstiger zu beheben sind. An Hand von Praxisbeispielen konnte er diese Thesen belegen und aus meiner Sicht ist es an der Zeit auch Performance Tests in unseren Entwickleralltag zu integrieren – ähnlich wie beispielsweise JUnit Tests oder auch Code Metriken mit PMD oder Checkstyle. Nach den vier Voträgen ging es mit einem netten Abendprogramm weiter. Durch die große Hitze hatten wir kurzfristig entschieden, das Buffet nach draußen zu legen und das Catering Unternehmen Hitzegrad musste in Rekordzeit das komplette Essen, die Getränke, sowie Tische und Stühle nach draußen in den schönen Innenhof unseres Alten Amtsgerichts bringen.Vielen Dank noch mal an das tolle Team! Ab diesem Zeitpunkt wurde das Event zu einer super Networking Veranstaltung. Andreas hatte zuvor die Regeln des Open Space erklärt und nach einer ersten Stärkung am Buffet starteten die Vorträge und Diskussionen in verschiedenen Räumen und mit unterschiedlichen Vortragenden. Unter anderem waren auch wieder Kirk, Heinz und Alois dabei, aber auch Jeroen Borgers von Xebia und andere Experten unter den Teilnehmern. In meinem Open Space zum Thema “Organisatorische Performance Antipatterns” ging es darum, wie man Fingerpointing in kritischen Situationen vermeidet und den Überblick behalten kann. Die ca. 20 Teilnehmer waren schnell in einer interessanten Diskussion vertieft und selten habe ich so viele konstruktive Ideen zu diesem Thema erhalten wie an diesem Abend. Auch in den Sessions die parallel gelaufen sind, konnten interessante Themen vertieft werden. Die Bildergalerie gibt hoffentlich einen Eindruck von der Veranstaltung, die erst gegen 1:00 Uhr morgen beendet war. Kirk hat an unserer Firmen Wii auch das Guitar Hero spielen schätzen gelernt

[Show as slideshow]

Während unserer coding night, zu der mit Sicherheit noch ein separater Blogeintrag folgt, setzen wir voll auf Spring Technologien. Dabei hat sich eine vermutlich simple Anforderung als ziemlich halsbrecherisch herausgestellt.

Wie kann man mit Spring MVC eine Select box darstellen, bei der man multiple Elemente auswählen kann, welche dann in eine Collection der Bean hinzugefügt werden?

Wir implementiere eine einfache Zeiterfassung. In dem Domänenmodell gibt es Projekte, denen Mitarbeiter zugeordnet sind. Zudem können Projekte Aufgaben haben, denen auch Mitarbeiter zugeordnet sein können. In der View zum erstellen der Aufgaben benötigen wir also eine Selectbox aus allen verfügbaren Mitarbeitern.

Modell

Hier das wichtigste der Aufgaben und Mitarbeiter:

Task

@Entity
public class Task implements Serializable {
	@Id
	@GeneratedValue
	private long id;
 
	@ManyToMany
	private Set<Staff> staffs = new HashSet<Staff>(0);
 
	//...
}

Staff

@NamedQuery(name = "staff.activeStaff", query = "select s from Staff s where s.disabled = false")
@Entity
@DiscriminatorValue("STAFF")
public class Staff extends Person {
 
	//...
}

Person

@NamedQuery(name = "person.findByUsername", query = "from Person p where p.login.username = :username")
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "type", discriminatorType = DiscriminatorType.STRING)
public abstract class Person implements Serializable {
 
	@Id
	@GeneratedValue
	private long id;
 
	//...
}

View

In der view, in der die Tasks erstellt werden sollen, brauchen wir also eine select box, welche alle verfügbaren Mitarbeiter anzeigt. Die ausgewählten Mitarbeiter sollen dann der Aufgabe hinzugefügt werden. Die View ist mit der Task hinterlegt, und fügt alle aktiven Mitarbeiter zu einem Attribut hinzu:

@Controller
@SessionAttributes("project")
public class ProjectController {
	@RequestMapping(method = RequestMethod.GET, value = "/project/createTask.action")
	public void createTaskView(@ModelAttribute Task task, Model model) {
		List<Staff> activeStaff = timetrackingService.getActiveStaff();
		model.addAttribute("activeStaff", activeStaff);
	}
 
	//...

Die entsprechende JSP sieht folgendermaßen aus:

<td><label for="staffs">Chose Staff: </label></td>
<td><form:select path="staffs" multiple="true" items="${activeStaff}" itemLabel="fullName" itemValue="id"/></td>
<td><form:errors path="staffs" /></td>

Das Problem, sobald man die Form submitted, bekommt man eine ServletRequestBindingException, denn Spring weiß nicht wie man aus einem String (bzw. String[] wenn mehrere Personen markiert waren) ein Set erstellt.

org.springframework.web.bind.ServletRequestBindingException: Errors binding onto object 'task'; nested exception is org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object 'task' on field 'staffs': rejected value [3]; codes [typeMismatch.task.staffs,typeMismatch.staffs,typeMismatch.java.util.Set,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [task.staffs,staffs]; arguments []; default message [staffs]]; default message [Failed to convert property value of type [java.lang.String] to required type [java.util.Set] for property 'staffs'; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [java.lang.String] to required type [de.codecentric.timetracking.model.Staff] for property 'staffs[0]': no matching editors or conversion strategy found]

Zudem ist der generierte HTML-code lückenhaft, er enthält keine id für die einzelnen Mitarbeiter!

<select id="staffs" multiple="multiple" name="staffs">
<option value="">firstname lastname</option>
<option value="">aaaa aaaa</option>
<option value="">firstname lastName</option>
<option value="">firstname aaaa</option>
<option value="">firstname lastname</option>
</select>
<input type="hidden" value="1" name="_staffs"/>

Id als String

Um die ID des Mitarbeiters in das value-Attribut der option zu bekommen, kann man einen eigenen Getter auf der Person implementieren, und diesen dann in der JSP statt der ID verwenden:

public abstract class Person implements Serializable {
	//...
	public String getIdAsString() {
		return new Long(id).toString();
	}
}

<form:select path="staffs" itemValue="idAsString" multiple="true" items="${activeStaff}" itemLabel="fullName"/>

InitBinder

Die Lösung für das Binding-Problem ist, dass wir für das Attribut ’staffs’ einen eigenen PropertyEditor registrieren müssen. Spring bringt eine Reihe eigener PropertyEditoren mit, in diesem Falle können wir den CustomCollectionEditor wiederverwenden. Um von der String-ID wieder auf den Mitarbeiter mappen zu können, müssen wir uns auch noch eine Map initialisieren, die dieses Mapping vorhält.

public class ProjectController {
 
private Map<String, Staff> staffCache;
 
@RequestMapping(method = RequestMethod.GET, value = "/project/createTask.action")
public void createTaskView(@ModelAttribute Task task, Model model) {
	List<Staff> activeStaff = timetrackingService.getActiveStaff();
	staffCache = new HashMap<String, Staff>();
	for (Staff staff : activeStaff) {
		staffCache.put(staff.getIdAsString(), staff);
	}
	model.addAttribute("activeStaff", activeStaff);
}
 
@InitBinder
protected void initBinder(WebDataBinder binder) throws Exception {
	binder.registerCustomEditor(Set.class, "staffs", new CustomCollectionEditor(Set.class) {
		protected Object convertElement(Object element) {
			if (element instanceof Staff) {
				System.out.println("Converting from Staff to Staff: " + element);
				return element;
			}
			if (element instanceof String) {
				Staff staff = staffCache.get(element);
				System.out.println("Looking up staff for id " + element + ": " + staff);
				return staff;
			}
			System.out.println("Don't know what to do with: " + element);
			return null;
		}
	});
}

Der Code enthält noch etwas Debug-output nach System.out, der natürlich noch entfernt werden muss. Er zeigt aber sehr schön, dass der Code sehr (zu?) häufig aufgerufen wird. Außerdem wird erwartetn, dass die Property in beide Richtungen konvertiert werden kann!

Allein wenn die select box angezeit werden soll, steht folgendes im Log:

Looking up staff for id 1: Staff(firstname lastname)
Looking up staff for id 1: Staff(firstname lastname)
Converting from Staff to Staff: Staff(firstname lastname)
Looking up staff for id 2: Staff(aaaa aaaa)
Looking up staff for id 2: Staff(aaaa aaaa)
Converting from Staff to Staff: Staff(aaaa aaaa)
Looking up staff for id 3: Staff(firstname lastName)
Looking up staff for id 3: Staff(firstname lastName)
Converting from Staff to Staff: Staff(firstname lastName)
Looking up staff for id 4: Staff(firstname aaaa)
Looking up staff for id 4: Staff(firstname aaaa)
Converting from Staff to Staff: Staff(firstname aaaa)
Looking up staff for id 5: Staff(firstname lastname)
Looking up staff for id 5: Staff(firstname lastname)
Converting from Staff to Staff: Staff(firstname lastname)

Wenn man einen Mitarbeiter aus der Select-Box auswählt und die Form submitted, findet sich dann aber wie erwartet nur ein Eintrag im Log:

Looking up staff for id 3: Staff(firstname lastName)

Fazit

Angesichts der Masse an Webframeworks, die es gibt, finde ich es erschreckend Kompliziert so etwas einfaches wie eine multiple select Box mit Spring MVC zu implementieren. Da ich mir Spring MVC aber auch erst seit gestern genauer angesehen habe, verstehe ich es vielleicht noch nicht richtig, von daher bin ich sehr für Vorschläge zu haben, wie man das beschriebene Szenario mit Spring MVC-Mitteln eleganter und einfacher implementieren kann.