mein erstes Grails-Projekt

Eigentlich bin ich eher skeptisch, was neue Technologien angeht. Zu häufig wird viel zu viel versprochen und der Gesamtnutzen bleibt zweifelhaft. Viele Technologien lösen auch schlicht Probleme, die ich gar nicht habe.
Bei Groovy und Grails verhält es sich anders. Ich hatte jetzt das Glück, dass ich zum Jahresausklang ein kleines Grails-Projekt machen konnte. Ich hatte Grails bereits vorher ein wenig ausprobiert und hatte daher eine Idee, was mich erwartete. Und diese Erwartungen wurden noch übertroffen.
Wir haben in sehr kurzer Zeit eine kleine aber komplette Internetanwendung mit lächerlich wenig Code geschrieben. (Sobald die Anwendung Live ist, werde ich den Link hier mal posten.)
Besonders beeindruckt hat mich die Klarheit des Programmiermodells. Struts, JSF und Spring Web-MVC haben bei mir immer das Gefühl hinterlassen, dass intern Dinge passieren, die ich nicht ganz verstehe. Dieses Gefühl habe ich mit Grails nicht.
Weiterhin ist interessant, dass wir - obwohl es für alle das erste Grails-Projekt war - jedes Problem in weniger als 2 Stunden lösen konnten. Bei anderen Java-Technologien hatten wir immer wieder Fälle, wo wir uns Tage oder gar Wochen die Zähne ausgebissen haben; teilweise konnten wir die Probleme gar nicht lösen und mussten dann mit Work-Arounds arbeiten.

Post bewerten

neues Buch zu Scrum

Roman Pichler hat im dpunkt-Verlag ein deutschsprachiges Scrum-Buch veröffentlicht. Es ist angenehm dünn (gut 180 Seiten) und sehr pragmatisch und handlungsleitend. Es bietet insbesondere dem Einsteiger in agile Softwareentwicklung genau die Handreichungen, die benötigt werden. Der erfahrene Agilist kann dem Buch sicher noch die eine oder andere neue Idee oder Technik entnehmen und erhält einen guten Überblick über den aktuellen Stand von Scrum.

Post bewerten

Korrektur zur DAO-Aussage im Hibernate-Buch

In dem Hibernate-Buch von Arno, Robert, Sebastian und mir gibt es eine Falschaussage, die ich zu verantworten habe. In Abschnitt 8.2 steht, dass man mit Hibernate keine DAOs mehr braucht.

Das stimmt, wenn man DAOs nur zur Kapselung der DB bzw. von JDBC verwenden möchte. Denn das leistet Hibernate sehr gut. Dennoch sollte man seine Anwendung ohne Datenbank testen wollen, also Mocks einsetzen. Und dazu braucht man dann doch wieder sowas wie DAOs.
In unseren Projekten setzen wir da auf das Repository-Muster von Domain Driven Design (Eric Evans), was technisch den DAOs sehr ähnlich ist.

Sorry für die Falschaussage und Danke an Eberhard Wolff, dass er mich darauf aufmerksam gemacht hat.

Post bewerten

Screencast zum Vortrag "Einfachheit in Softwareprojekten"

Auf den XP-Days habe ich einen Vortrag mit dem Titel "Einfachheit in Softwareprojekten" gehalten. Den habe ich als Screencast aufgezeichnet und dabei leider das Mikro so übersteuert, dass der Ton unbrauchbar ist.
Glücklicherweise hat Jens Himmelreich den Ton separat aufgezeichnet und mir zur Verfügung gestellt. Nach ziemlich viel Arbeit habe ich es dann auch geschafft, Bild und Ton so zu mischen, dass sie synchron laufen.
Das Gesamtkunstwerk kann man sich hier ansehen (oder einfach nur den Ton oder die Folien als PDF runterladen).

Nochmal vielen vielen Dank an Jens Himmelreich. Ohne seine Ton-Aufnahme wäre das alles nichts geworden.

Post bewerten

die zweite Internet-Blase?

lustiges Video mit Musik dazu: http://valleywag.com/tech/online-video/here-comes-another-takedown-332666.php?autoplay=true

Post bewerten

Lohnt sich Dependency-Injection

Auf InfoQ ist gerade eine Zusammenfassung einer Diskussion erschienen, in der es um die Frage geht, ob sich Dependency-Injection auszahlt. Die einen sagen, dass DI nur dazu gut ist, damit man entkoppelt mit Mocks testen kann. Stattdessen könne man aber auch bessere Mock-Frameworks benutzen, die DI nicht erzwingen. Die anderen sagen, dass Testen DI erzwingt und dass daher DI automatisch gut ist.

Ich finde, die Diskussion geht etwas am eigentlichen Kern vorbei. DI ist erstmal nur eine Technik, genauso wie Mock-Testen. Keines von beiden ist generell gut oder schlecht. Genauso wie Entkopplung nicht automatisch gut ist. Man muss auch die richtigen Teile entkoppeln.

Meiner Meinung nach ist das Dependency-Inversion-Principle (DIP) das übergeordnete Konzept. DIP sagt, dass ein High-Level-Konzept nicht von Low-Level-Implementationen abhängen sollen. Demnach darf z.B. die Fachlogikschicht nicht von der Datenbankschicht abhängen. Begründung: Low-Level-Implementationen ändern sich häufiger als High-Level-Konzepte und die Änderungen finden nicht nur hinter dem API der Low-Level-Implementation statt, sondern schlagen häufig bis in die Klienten durch. Hängen die High-Level-Konzepte von den Low-Level-Implementationen ab, müssen sie unnötig häufig geändert werden.

Das bedeutet: DIP ist generell gut.

DI und Mocks erlauben mir, DIP umzusetzen. Daher sind DIP und Mocks mind. dann gut, wenn sie für DIP eingesetzt werden.


Interessanterweise korreliert DIP mit vielen Aspekten aus Quasar.

Post bewerten

Warum einfach, wenn es auch kompliziert geht?

Ich habe auf den XP-Days in Karlsruhe einen Vortrag über Einfachheit in Softwareprojekten gehalten, den ich hoffentlich bald als Screencast online stellen kann.
In dem Vortrag ich von einem Experiment berichtet, dass von Bavelas an der Stanford-Universität durchgeführt wurde. Man hat Propanden mit Bildern von Gewebezellen konfrontiert. Sie sollten ohne medizinische Vorkenntnisse diagnostizieren, ob die Zellen gesund oder krank sind. Sie bekamen als Feedback dann jeweils, ob sie richtig oder falsch gelegen haben. Aus dem Feedback entwickelten sie ein Modell darüber, woran man krankhafte Gewebezellen erkennt.
Allerdings hat man nur der einen Gruppe korrektes Feedback gegeben. Die andere Gruppe hat zufälliges Feedback erhalten.
Schließlich hat man Paare mit jeweils einem Vertreter jeder Gruppe gebildet, die dann gemeinsam Gewebezellen diagnostizieren sollten. Und dabei setzte sich meistens die Person durch, der man das zufällige Feedback gegeben hatte.
Begründung: Diese Person hat sich auf Basis des zufälligen Feedbacks ein sehr kompliziertes (aber falsches) Modell darüber gemacht, woran man krankhafte Zellen erkennt. Die Person mit dem korrekten und einfachen Modell war begeistert von der Detailtiefe des komplizierten Modells ("da habe ich selbst wohl etwas übersehen") und ist daher der meist falschen Einschätzung seines Partners gefolgt.
Und dieses Phänomen findet sich auch ständig in der Softwareprojekten. Es ist so verführerisch den komplizierten Architekturen, Technologien und Vorgehensmodellen zu folgen. Ich glaube jedoch, dass das meistens der falsche Weg ist: Komplizierte Lösungen sind auch dann falsch, wenn sie richtig sind.

Eine genauere Beschreibung des Experimentes findet sich in "Wie wirklich ist die Wirklichkeit?" von Paul Watzlawick im Kapitel ("Warum einfach, wenn es auch kompliziert geht?"). Der Text findet sich unter der gleichen Überschrift auch Online auf Seite 20ff.

Post bewerten