Wir, die Unterzeichner, haben keine Lust mehr, zu hören, wie viel von unserem Geld für fehlgeschlagene IT-Projekte der Regierung verpulvert wird.

Wir glauben, dass dies im Wesentlichen an der Art und Weise liegt, mit der diese Projekte ausgeschrieben und geliefert werden – nämlich, alle Anforderungen eines enormen Projektes im Vorhinein zu verlangen und sich darauf zu verpflichten. Das verurteilt Projekte dazu, fehlzuschlagen noch ehe sie begonnen haben.

Im privaten Sektor hat man sich bereits weitgehend von diesem falschen Modell zu einem inkrementellen Ansatz bewegt, der Änderungen im Verständnis und den Anforderungen erlaubt und die Wahrscheinlichkeit für einen Misserfolg enorm reduziert. Es ist an der Zeit, dass unsere Regierung das auch tut.

Wir bitten den Premierminister, den aktuellen Ansatz auf den Prüfstand zu stellen und für IT-Projekte der Regierung einen mehr inkrementellen und agilen Ansatz in Betracht zu ziehen.

Wow, das sollte hier in Deutschland auch gelten! Wo kann man hier eine ebensolche Petition abgeben? Ich wäre sofort dabei!

Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden “immer” oder “oft” benutzt, fast zwei Drittel hingegen “selten” oder “nie”. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Diese Situation stellt neue “Anforderungen an die Anforderungen”. Der Artikel zeigt, wie Anforderungen heute aussehen können, damit man mit ihnen sehr schlanke Projektverträge gestalten kann. “Money for nothing, changes for free” sind hier die zunächst unglaublich klingenden Stichworte. Auftrag geber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden.

Der rund eine Minute lange Film zeigt anschaulich, wodurch der Unterschied für den Kunden zu Stande kommt. Mehr über Flow gibt es hier.

Ist das in der Software-Entwicklung genauso? Die OOP hat sich ja in diesem Jahr auch so ein Motto auf die Fahne geschrieben: people, process, technology. Prüfen wir doch mal: people = mano e mente, process = macinatura, technology = macchina – nanu, wo bleibt miscela, die Mischung, der Rohstoff, aus dem die Software entstehen kann?

Alistair Cockburn hat diese Frage 2006 in einem Artikel beantwortet: “Software engineering … is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory.” Die Mischung besteht also aus den bisher unvalidierten Entscheidungen, die in der Mühle und der Maschine immer weiter verarbeitet werden, bis der Benutzer seine neue Software in Händen hält.

Beispiele für solche unvalidierten Entscheidungen sind:

• Jede Anforderung ist eine Entscheidung, die auf einem bestimmten Geschäftsklima basiert. Wenn sich das Klima ändert, könnte die Entscheidung falsch werden.
• Eine Architektur ist eine Entscheidung, die auf Technologie und Business basiert. Wenn sich die Technologie verändert bevor die Software genügend Wert für das Business eingespielt hat, ist die Entscheidung verschwendet.
• Jede Zeile Code ist eine Entscheidung, basierend auf Anforderungen, Technologie und Ästhetik. Sollte eines davon obsolet werden bevor die Software genügend Geld für die Firma verdient hat, dann war auch das Verschwendung.

Halten wir also am besten die Zyklen kurz und schlank und erzeugen nur so wenig unvalidierte Entscheidungen wie möglich. Über Anforderungen rasch entscheiden, Entwurf und Programmierung zeitnah durchführen, dem Benutzer lauffähige Systeme in die Hand geben, die er sofort validieren kann. So bleibt der Kaffee frisch, weil die Bohnen nicht lange liegen.

Ich lade Sie ein, mit mir auf der OOP einen Kaffee zu trinken!

Ausgangssituation: Priorität gemeinsam festlegen

Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:

• Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
• Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
• Was meinen die anderen Stakeholder dazu?
• Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?

Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)

Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.

Spielregeln

Die Spielregeln für “Buy a feature” sind sehr einfach und wirkungsvoll:

• Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
• Jedes Feature hat einen “Preis”, der durch den Entwicklungsaufwand bestimmt wird.
• Stakeholder “kaufen” nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
• Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.

Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.

Die Randbedingungen hatte ich wie folgt gesetzt:

• Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
• Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
• Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste “Launch” des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.

Der Ablauf des Spiels

Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.

Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.

Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.

Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: “Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.” Wer hätte das für möglich gehalten?

Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.

Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: “Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?”. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.

Feedback vor und nach dem Spiel

Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: “Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.” Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.

Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:

• “Die Visualisierung der Entscheidungen ist sehr gut.”
• “Man kommt sehr schnell zu einer Einigung.”
• “Es lockert diese Meetings auf und macht Spaß.”

Tja, da bleibt mir nur ein “Danke” an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!

Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”

Allgemeines Gelächter in der Gruppe.

Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.

Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.

Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?

Lesenswert!

These 1: Menschen leisten am meisten, wenn sie motiviert sind. Zumindest, wenn das Rennen über eine längere Strecke gehen wird. Kurze Strecken hoher Leistung sind auch rein aus Anstrengung machbar, bei längeren Strecken kommt die Energie am besten aus der Begeisterung. Softwareentwicklung gehört zu den längeren Rennen.

These 2: Softwareentwicklung ist ein Spezialfall von Arbeit mit Wissen, und zwar mit einem Wissen, das nicht von Anfang an komplett vorhanden ist, sondern eines, das wie ein stetiger Strom während der gesamten Projektlaufzeit ins Team fließt.

These 3: Wissensarbeit ist wie ein kooperatives Spiel – es gibt dabei keinen, der vernünftigerweise allein bestimmen könnte, was als Nächstes der beste Spielzug ist. Das gilt insbesondere sogar für den Projektleiter – er muss die Entscheidung über den besten nächsten Zug seinen Mitarbeitern überlassen.

Formen der Führung

Je nach der Komplexität der Arbeit, die die Teams leisten, muss der Führungsstil angepasst werden, damit die Sache ein Erfolg wird. Sehr einfache Arbeit kann man mittels Kommando und Kontrolle managen. Für etwas komplexere Aufgaben sind Zielvorgaben und Belohnung bei Zielerreichung das Richtige. Noch komplexere managt man durch charismatische Führung. Für höchst komplexe Tätigkeiten wie die Softwareentwicklung erreicht man die besten Ergebnisse, wenn man Selbstorganisation zum Prinzip macht. Niemand anderes als das Team weiß am besten, was in der aktuellen Situation zu tun ist. Als Manager nutzt man dieses Wissen und stellt dem Team lediglich eine Dienstleistung namens Führung zur Verfügung.

Robert K. Greenleaf hat vor einigen Jahrzehnten schon Essays dazu verfasst, das gemeinsame Thema hieß Servant Leadership, im Prinzip “Führung als Dienstleistung”. James A. Autry hat Greenleafs Erkenntnisse weiter konkretisiert, in seinem Buch von 2001: The Servant Leader: How to Build a Creative Team, Develop Great Morale, and Improve Bottom-Line Performance. Darin finden sich einige interessante Kernaussagen:

1. Bei Führung geht es nicht um das Steuern von Leuten; es geht darum, für Leute zu sorgen und eine nützliche Ressource für die Leute zu sein.
2. Führung bedeutet nicht, der Boss zu sein; es geht darum, für Leute präsent zu sein und eine Gemeinschaft am Arbeitsplatz aufzubauen.
3. Bei Führung geht es nicht um die Verteidigung von Territorium; es geht darum, Ihr Ego loszulassen, Ihren Geist mit zur Arbeit zu bringen und Ihr bestes und möglichst authentisches Selbst zu sein.
4. Führung befasst sich nicht so sehr damit, Anfeuerungsreden zu halten, sondern damit, wie man einen Platz schafft, an dem Leute gute Arbeit machen können, darin einen Sinn finden und ihren Geist zur Arbeit mitbringen.
5. Führung ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.
6. Führung erfordert Liebe.

Motivation und Produktivität

Wenn ich die obigen Kernaussagen von Autry lese, denke ich “Wow, so möchte ich als Teammitglied geführt werden!” Ein Manager ist in der Lage, eine Umgebung für Motivation und gute Arbeit zu schaffen, wenn er diese Sätze tief verinnerlicht und danach handelt. Nebenbei: Dann wird ihm sein Job auch richtig Spaß machen, weil er mit dem, was sein Team braucht, in Resonanz kommt.

Produktivität stellt sich dann durch Selbstorganisation des Teams ein, bei der der Manager lediglich Unterstützung leistet. Soziale Systeme entwickeln Verhalten, sie organisieren sich selbt aufgrund von Regeln, Feedback und Diskurs. Es beginnt mit einfachen Regeln, z.B. “Wir wollen nur Code einchecken, der den Build übersteht und fehlerfrei durch alle Unit-Tests geht.” Wenn jemand eine solche, gemeinsam anerkannte Regel verletzt, indem er schlechten Code eincheckt, bekommt er von den Teamkollegen (und vom CI-Server) Feedback. Er wird sich vermutlich wundern, mit seinen Kollegen ins Gespräch kommen. Zuletzt wird er die Ursache herausfinden und beheben, indem er vor dem Einchecken zunächst seine Arbeitsumgebung aktualisiert, alle Unit-Tests laufenlässt und Fehler lokal behebt, bevor er nochmals eincheckt. Das ist eine Verhaltensveränderung, Selbstorganisation durch Feedback und Diskurs. Die Produktivität des Teams wird ansteigen, weil wieder einer weniger “im Weg steht”.

Der Manager als Mentor

Als Manager oder Coach kann ich diesen Prozess der Selbstorganisation fördern, indem ich genug Quellen für Feedback schaffe, Menschen ermutige, Feedback zu geben und in den Diskurs zu gehen. Ich kann das Team fragen, welche anerkannten Regeln für das gemeinsame Handeln gelten müssen und die Verabschiedung dieser Regeln fördern. Ich kann Regeln auch hinterfragen (lassen), wenn mehrfach gegen sie verstoßen wird oder wenn das Team so reif wird, dass sie weniger Regeln brauchen.

Das alles ist, wie das Leben, größtenteils eine Frage der Aufmerksamkeit.

In allen agilen Methoden versucht das Entwicklungsteam, dem Kunden ein gewünschtes Feature möglichst schnell zur Verfügung zu stellen. Das ist ein wichtiger Bestandteil des Entwicklungsprozesses: zeitnahe Lieferung löst zeitnahes Feedback aus und hilft, das Projekt auf der Spur zu halten.

Die agilen Methoden können dabei von den jahrzehntelangen Erfahrungen aus der Lean Production profitieren. Kanban tut das explizit, XP und Scrum tun das implizit. Die Frage ist nur : Was heißt eigentlich “schnell” oder “zeitnah”? Über welche Zeit reden wir da eigentlich?

Lead time

Die für den Kunden interessante Zeit ist eigentlich diese: “Wenn ich heute ein Feature in die Entwicklung gebe, wann kann ich es in der lauffähigen Software erkennen und testen?”. Diese Zeit nennt man in der Lean-Welt lead time. Ihre Einheit ist tatsächliche, abgelaufene Zeit (elapsed time). Sie enthält sowohl die Zeit für den Fertigungs-Workflow (also Analyse, Design, Unit-Test, Implementierung, Integration, etc.) als auch eventuelle Wartezeiten vor der Fertigung, weil das Team gerade noch andere Features zu entwickeln hatte.

Cycle time

Eine andere Zeit, die weniger für den Kunden und mehr für die Entwickler und deren Manager interessant ist, nennt man in der Lean-Welt cycle time. Ihre Einheit ist nicht tatsächlich abgelaufene Zeit (elapsed time), sondern der Rhythmus (engl. cadence), wie oft der Entwicklungsprozess ein Feature fertigstellt. Um den Unterschied zu verstehen, ein Beispiel: Ein GUI-Designer wird beauftragt, eine größere Anzahl bereits fertig entwickelter HTML-Seiten (z.B. 100 Stück) graphisch schön aufzubereiten. Sagen wir, er liefert jede Woche (5 Arbeitstage) 20 Stück, dann beträgt die cycle time pro HTML-Seite 2 Stunden (5 Tage mal 8 Stunden = 40 Stunden, dividiert durch 20 Stück, also 2 Stunden pro Stück).

Littles Gesetz und Work in Process

Wie stehen nun diese beiden Zeiten in Beziehung? Das fand John D.C. Little schon 1961 heraus. Damals formulierte er es so: In einem stabilen Wartesystem (Beispiel: Supermarkt) ist die durchschnittliche Anzahl von Kunden gleich dem Produkt aus Ankunftsrate und der durchschnittlichen Verweildauer im System.

Was heißt das, übertragen auf lead time und cycle time? Nun, die Ankunftsrate ist der Kehrwert der cycle time, die Verweildauer ist gleich der lead time und die durchschnittliche Kundenanzahl entspricht der Anzahl der Features, an denen das Team im Durchschnitt gleichzeitig arbeitet. In der Lean-Welt nennt man das work in process.

Also können wir Littles Gesetz so umstellen: lead time = work in process * cycle time.

Wenn der oben erwähnte GUI-Designer zu viele Aufträge hat, weil er für zu viele Kunden gleichzeitig arbeitet, ist seine work in process sehr hoch, z.B. befinden sich 100 HTML-Seiten bei ihm in Arbeit. Wenn ein Kunde nun eine neue Seite zum “Schönmachen” beauftragt, bekommt er sie erst nach einer lead time von durchschnittlich 5 Wochen zurück (100 Seiten x 2 Stunden/Seite, geteilt durch 40 Stunden pro Woche). Der Kunde wird unzufrieden sein, und der GUI-Designer sollte sich überlegen, ob er nicht mehr Aufträge ablehnen oder seinen Kollegen weitergeben sollte.

Handlungempfehlung

Was lernen wir daraus, wenn wir zu einem Software-Entwicklungsteam gehören oder ein solches managen? Um den Kunden zufrieden zu machen, sollte das Team die lead time optimieren. Das Einfachste ist, die work in process zu reduzieren, also einfach nicht an so vielen Sachen gleichzeitig zu arbeiten. Das Schwierigere ist, die cycle time zu reduzieren, also effizienter zu arbeiten. Dazu braucht es Methode. Wenn Sie Lust haben, zeige ich Ihnen , wie auch das geht. Rufen Sie mich an.

Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.

Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!

Hey, Uncle Bob is back at OOP,! For me this is very special because it was him who brought me to object oriented design/programming and to my first OOP conference, ever. And this was back in 1992 when I was a enthusiastic software developer, coding in C. Java did not exist in those days, design patterns were not published, there was no TDD – well, it was just the old days of poorly maintainable code!

Bob, when I came into your workshop about object oriented design at OOP, you started with a very simple example in C++ (at least, I thought it was): a car with an engine. You said something like this:

Bob: “OK, guys, lets define an accelerate() method on the car – what would be inside the body of this method?”. And my head started thinking. Somebody else: “The car should tell the carburator to increase the fuel to air ratio. And it should also tell the automatic transmission to shift one gear up!”

Bob: “OK, so Car::accelerate() calls Carburator::increaseFuelToAirRatio(), followed by Transmission::shiftUp(). Question to all of you: Is this a good design or a bad design?”

And poor me, inexperienced in OOD, could say neither yes nor no: “In fact, I don’t know!”.

Bob, you suddenly shouted “Of course, it is a BAD design, very bad design!”

Me: “Oh, why this?”

Bob: “What if you have a Diesel engine, without carburator? And: What if your car has an electric engine, without transmission?”

Me: “Hmmm… well, I guess, I would have to change the design significantly. Something like Thyristor::increaseElectricCurrent().”

Bob: “Exactly! So, how about introducing a neutral abstraction above all this? How about Engine::increasePower()? And with an intelligent Engine class that knows how to increase the power purely by itself? With nobody telling it how to do that?”

Me: “Aha!”

And so 1992 was the year when I became enthusiastic about object oriented design. Thanks a lot, Bob – I am really looking forward to see you again at this OOP. I guess, you won’t remember me but this is not a problem.

The RDFa plug-in allows you to expose relevant parts of the structure of your application as RDFa annotations in your views. Both domain model (non-information resources) and controller actions (information resources) can be described.

The plugin is still in its early stages, check out its interesting features which are described on the plugin page.

Ein Beispiel des Portals Indeed.com:

SCRUM and project management, AGILE and project management, PMI and project management Job Trends

SCRUM and project management jobs – AGILE and project management jobs – PMI and project management jobs

Good news today: Grails has a plug-in for this purpose – it is called the taxonomy plug-in. The developers of this plug-in say that it allows you to apply arbitrary hierarchical categorisation (Taxons) to domain objects. Here is an example of the basic usage:

def book = Book.get(1)
// Add the book to the Non-fiction > Autobiography category
book.addToTaxonomy(['Non-fiction', 'Autobiography'])
 
def autobiographies = Book.findAllByTaxonomyFamily(
    ['Non-fiction', 'Autobiography']
)

There is support for arbitrary nesting of Taxons (categories) within unlimited taxonomies, and taxonomies are domain class independent.

So the category “Local” on Author can also be used on Book.

However, you can have different taxonomy graphs aside from the default one, so you might have a taxonomy graph “Location” storing the names of states and cities, and another taxonomy graph “Company type” – and objects having categories in both graphs.

Release 0.1 of the taxonomy plug-in is “alpha” grade. It does not support polymorphism. So querying objects by taxonomy requires you to query the specific class type. This will be resolved in the next release. Also, it does not do caching so it isn’t going to be blazingly fast. Developers say that this will come soon.

Have fun and visit the plug-in page on grails.org.

This plugin helps you to define a fixture, that is a defined set of data used for testing. The plugin defines a DSL in which you can express your need for data. Example:

fixture {
    guillaume(Author) {
        name = "Guillaume Laforge"
    }
    dierk(Author) {
        name = "Dierk Koenig"
    }
    gina(Book) {
        title = "Groovy In Action"
        authors = [guillaume, dierk]
    }
}

Or a little shorter:

fixture {
    guillaume(Author, name: "Guillaume Laforge")
    dierk(Author, name: "Dierk Koenig")
    gina(Book, title: "Groovy In Action", authors: [guillaume, dierk])
}

Then, in your test case, you will want to load that fixture, like this:

class GinaTests extends GroovyTestCase {
    def fixtureLoader
 
    void testFinderMethod() {
        fixtureLoader.load("gina")
        def gina = Book.findByTitle("Groovy In Action")
        assertNotNull(gina)
        assertEquals(2, gina.authors.size())
    }
}

Pretty simple, isn’t it? Find out more about how to install and use the Fixtures plugin on its plugin page at grails.org.

A grails implementation of MonsterID: a method to generate a unique monster image based upon a certain identifier (user id, email address, whatever). It can be used to automatically provide personal avatar images in blog comments or other community services.

You can find this plugin (as usual) on grails.org.

Out of the box it:

• renders a field using a UI element appropriate for the property type. Constraints are used to set maximum lengths etc.
• automatically renders tags for fields, from i18n message bundles
• renders “required” indicators if the field is nullable:false and/or blank:false
• renders errors adjacent to the field that had the error
• renders the current value as appropriate

This is all done by building on top of Grails existing tags, so all the regular tag attributes are supported where possible.

Here’s an example of how you can render all this for a bunch of bean properties:

<bean:withBean beanName="form">
    <bean:field property="firstName">
    <bean:field property="lastName">
    <bean:field property="company">
    <bean:field property="email">
</bean:withBean>

You can find more elaborate examples as well as instructions for use on the plugin page.

Bug description: When a user makes a payment, Paypal notifies the site with a so-called instant payment notification. The code in PaypalController.notify() was wrong so that an error code 404 was returned to Paypal. Paypal retried the notification several times and finally gave up. The plugin processed the notification properly, though.

I fixed this bug today and released the corrected Paypal plugin as version 0.5.

You can find more info about the plugin on the plugin page at grails.org.

This is an interesting phenomenon that I am trying to study and understand. Maybe, it is possible to generate something entirely new.

However, at least one plug-in developer for Grails seems to think differently. See for yourself:

This plugin provides an ‘automatic’ component-like rendering infrastructure to Grails. It combines the ease of use of scaffolding with the flexibility to change the resulting views via custom renderers. This also allows you to change what tags you use to render an object without having to worry about consistency across views. Write it once, and be done with it!

What do you think – is this plug-in worth a try?

It is quite easy to route messages. For example, write a Grails service like this:

class MyService {
    def myMethod(fooBarText) {
        log.info “Got text: ${ fooBarText }”
    }
}

Then, using Camel’s bean integration, you can deliver messages from an in-memory queue directly to that Grails service:

from(“seda:my.queue”).filter {
    it.in.body.contains(“FooBar”)
}.to(“bean:myService?methodName=myMethod”)

Cool, isn’t it? As usual, you can find more info on the plugin page on grails.org.

There are three ways to define security mappings – see Securing URLs for more details. This tutorial uses the Requestmap approach. To use Controller annotations, use this tutorial and to specify security mappings using the standard Spring Security approach use this tutorial.

Good Luck!

Kunde: “Wir verstehen unser Framework nicht mehr. Es ist total verstrickt!”

Berater: “Aber Ihr habt doch gesagt, es sei erst zwei Jahre jung.”

Kunde: “Ja, und?”

Berater: “Sowas passiert doch sonst nur mit viel älterer Software!”

Kunde: “Nein, hier waren viele Externe vom Dienstleister XY dabei, da altert das Framework schneller!”

Berater: “Oh!???”

<prettysize:display size="${someSize}" />

generates outputs like:

"one kilobyte", "2 megabytes", or "3 GB"

The second one, Pretty Time, does this:

<prettytime:display date="${someDate}" />

generates timestamps like:

"right now", "2 days ago", or "3 months from now"

For i18n, check the “message.properties” file from the plugin directory.

Thanks to the creative developers in the Grails community! Have fun!

The Wordpress plugin provides tags for pulling content from wordpress for display in grails. ehcache is used to cache wordpress content for a 5 minute period.

Configuration is a piece of cake:

wordpress.url='http://myblog.wordpress.org/xmlrpc.php'
wordpress.blogId=0
wordpress.username='myapp'
wordpress.password='grailsrocks'

Then, display a list of your Wordpress categories:

<wordpress:getCategories />

or display the latest posts by saying:

<wordpress:getRecentPosts count="5" />

And so on… Read the full story on the plugin page at grails.org.

Perf4J is to System.currentTimeMillis() as log4j is to System.out.println().

Using Perf4J, you will be able to stop the time for a Grails code block, like this:

withStopwatch("myCriticalCodeBlock") {
    // code to be profiled with tag "myCriticalCodeBlock"
}

You can also log the time for a service method, automatically, choose one or more of these alternatives:

static profiled = true
static profiled = ['testMethod1', 'testMethod3']
static profiled = {
    testMethod1()
    testMethod2(tag: "tm2")
    testMethod3(message: "only message")
    testMethod4(tag: "tm4", message: "this is testMethod4()")
}

Got the taste of it? Read the full story about the upcoming plugin and enjoy!

assert new File('foo.bar') == new File('example.txt')

will yield this output:

Caught: Assertion failed:
 
assert new File('foo.bar') == new File('example.txt')
       |                   |  |
       foo.bar             |  example.txt
                           false

Isn’t that cool?
Read more about the new Features in Groovy 1.7.

In Marcel Overdijks Blog gibt es dazu eine interessante Diskussion.