Grails on Rails

Gleisanzeiger an der Haltestelle Berliner Tor in Hamburg

Das war mal etwas anderes: Vorgestern habe ich zusammen mit meinem it-agile-Kollegen Stefan Roock (Blog, Twitter, Xing) beim ObjectForum Nord in Hamburg einen Vortrag über Grails gehalten - in der Historischen S-Bahn Hamburg.

Grails auf Rails war das, und zwar wortwörtlich. Der Inhalt der Veranstaltung handelte von it-agiles Erfahrungen mit Grails und sollte dem Publikum aufzeigen, für welche Arten von Webanwendungen sich Grails gut eignet und wo es Fallstricke erwarten kann.

In einer S-Bahn vortragen, das war für uns neu. Während der Fahrt funktioniert kein Vortrag, da es einfach durch die Fahrtgeräusche zu laut ist. Wir haben die Zuhörer an der Haltestelle Berliner Tor in Hamburg abgeholt, nach Blankenese auf ein für uns reserviertes Gleis gebracht, dort in Ruhe den Vortrag gehalten und sie dann wieder zurück zum Berliner Tor gefahren. Die ganze Aktion dauerte etwa zweieinhalb Stunden bei einer Stunde Vortrag.

(Böse Zungen munkeln, dass das eine Butterfahrt war. Das stimmt aber nicht, denn wir haben nicht eine einzige Heizdecke an die Teilnehmer ausgegeben. Ehrenwort!)

Der Vortrag selbst war auch nicht so einfach: Durch die Sitzgruppen im durch eine dünne Trennwand zweigeteilten Abteil konnten wir Kraft eigener Stimme nicht jeden Zuhörer erreichen. Die eingebaute Lautsprecheranlage war dagegen ziemlich verrauscht, so wie es das Klischee der unverständlichen Lautsprecherdurchsagen vom Schaffner passend beschreibt. Eine eigene Boxenanlage musste her - akkubetrieben, da es keinen 240-Volt-Stromanschluss in einer historischen S-Bahn gibt.

Und dann die Sache mit den Folien und dem Beamer. Kein Strom, kein Beamer. Und selbst, wenn wir Strom gehabt hätten, wohin hätten wir die Folien projizieren können? Wir haben uns dann mit Riesen-Post-Its beholfen, die sechs it-agile-Kollegen auf Stefan und mein Zurufen hin umgeblättert haben. Und trotz aller Unkenrufe - Was da nicht alles hätte schief gehen können! -  verlief die Aktion reibungslos.

Die Resonanz: Sowohl Inhalt des Vortrags wie auch die Location kamen gut an. Uns hat es sehr viel Spaß gemacht.

Ein paar Fotos haben wir auch geschossen:

• Folien zum Download (das, was an den Fenstern hing)
  
• Handouts zum Download (die, die wir nach dem Vortrag verteilt haben)
• Infos zu Grails bei it-agile (die, die wir auch teilweise in den Vortrag gestreut haben)
  

[JFS 2008] Grails-Vortrag

Vorhin habe ich auf dem Java Forum Stuttgart einen Vortrag über Grails gehalten. Ich habe die Folien online zur Verfügung gestellt:

| View | Upload your own

Grails-Buch-Kapitel über Beziehungen zwischen Objekten

Stefan und ich haben ein neues Kapitel über die Beziehungen zwischen Objekten für unser Grails-Buch fertiggestellt und es auf die deutschsprachige Grails-Mailingliste zwecks Review hochgeladen (siehe Datei-Bereich der Mailingliste). Wie immer ist Feedback sehr willkommen!

Vielen Dank an dieser Stelle an die Feedbackgebenden der vorherigen Kapitel. Wir werden gewissenhaft jedem Hinweis zur Ergreifung von mangelnden Informationen und Fehlern im Buch nachgehen. Das Buch wird immer besser, und das verdanken wir zu einem Großteil Eurem Feedback!

[JAX 2008] JAX Innovation Award 2008 2. Gewinner: Grails (Bericht & Fotos)

Am Abend des 23.04.2008 wurden auf der JAX in Wiesbaden die Vertreter der nominierten Projekte für den JAX Innovation Award auf die Bühne von Saal 1 gebeten. Darunter befand sich auch Guillaume Laforge, Project Lead von Groovy. Groovy gewann im letzten Jahr den JAX Innovation Award - ein Umstand, der die Chancen für Grails in diesem Jahr leider negativ beeinflusste, so munkelte man zumindest vor der Verleihung. Dennoch: Grails war dieses Jahr unter den Top Ten und alleine dieser Fakt ist schon super!

Guillaume machte eine tolle Figur, als er Grails dem Publikum vorstellte - und überraschte damit, dass er seine ersten Sätze in doch recht brauchbarem Deutsch formulierte. Weiter so, Guillaume, dann brauchst Du Dir diesen Blog bald nicht mehr übersetzen zu lassen ;-)

Die Verleihung der Preise fing bei Platz 5 an. Platz 2 und damit EUR 5000 gingen an Grails. Ein tolles Ergebnis! Herzlichen Glückwunsch an dieser Stelle an Graeme Rocher, Project Lead von Grails, und allen Grails-Comittern, -Patchern, -Doku- und Plugin-Schreibern, sowie G2One, der Firma hinter Groovy und Grails! Platz 1 ging übrigens, nach Spring im Jahre 2006 und Groovy im Jahre 2007, an dynaTrace. dyna-was? Ja, genau, haben wir uns im Publikum auch gefragt ;-)

Der Publikums-Award wurde durch Handzeichen vom Publikum noch am gleichen Abend ermittelt, unmittelbar nach der Verleihung des JAX-Innovation-Awards. Das war relativ spaßig: Außer für Grails gab's nur noch Handzeichen für GreenFire, der Open-Source-Heizungssteuerung (!) von Adam Bien. Und im Gegensatz zur Jury-Verleihung des Hauptpreises konnte ich die Abstimmung des Publikums gut nachvollziehen: Adam Bien hat wirklich eine gelungene Vorstellung von GreenFire gegeben und das Publikum in seinen Bann gezogen. Kommt noch erschwerend hinzu, dass GreenFire auf der Ökowelle reitet, Adam Bien seit Jahren Publikums-Magnet auf der JAX ist (und damit hohes Ansehen beim JAX-Publikum genießt) und GreenFires letztes Feature eine Schnittstelle zum iPhone ist. Damit schlug GreenFire problemlos Grails mit einem Verhältnis von etwa 80 zu 20 Handzeichen. Herzlichen Glückwunsch an Adam Bien und seinem GreenFire! Grails wird's verkraften, immerhin 2. Platz, sowohl beim Jury-, als auch beim Publikums-Awards. Und GreenFire nutzt massiv Groovy - ergo bleibt's in der Familie :-)

[JAX 2008] JAX Innovation Award 2008 2. Gewinner: Grails

Der 2. Platz des diesjährigen JAX Innovation Awards 2008 geht an Grails! Herzlichen Glückwunsch! (Fotos folgen)

Auf der JAX mit Grails und Agile Lego Hour

Vom 21. bis 25. April 2008 findet die JAX statt. Zusammen mit meinem it-agile-Kollegen Stefan Roock werde ich zwei Sessions halten:

• Dienstag, 22.04., 11:30 h: Grails - Der Gral der Webanwendungen
  Ein einstündiger Überblick über Grails in Theorie und Praxis (ja, wir coden!). Wer Grails noch nicht kennt und gerne kennen lernen möchte, der ist hier gut aufgehoben.
  
• Mittwoch, 23.04., 16:00 h: Agile Lego Hour
  Eine einstündige Übung (zusammen mit Daniel Lübke und Thomas Flohr), in der wir die Teilnehmer ein Produkt aus Lego mit einem agilen Prozess entwerfen lassen. Spaß ist hier garantiert! Und so viel haben sie noch nie in einer Stunde über Agile Softwareentwicklung gelernt - garantiert nicht! Diese Session haben wir bereits auf der W-JAX 2007 gehalten, und sie ist dort sehr gut bei den Teilnehmern angekommen.
  

Grails-Buch-Kapitel über Validierung von Eingaben

Stefan und ich haben ein neues Kapitel über die Validierung von Eingaben für unser Grails-Buch fertiggestellt und es auf die deutschsprachige Grails-Mailingliste zwecks Review hochgeladen. Über Feedback würden wir uns sehr freuen!

Update 06.04.2008: Der direkte Link auf das Kapitel ist kaputt, weil dynamisch (nicht REST). Das Kapitel steht aber immer noch im Datei-Bereich der Mailingliste zum Download zur Verfügung.

werkannwann.de

Endlich ist es soweit! Voller Stolz darf ich eine Grails-Anwendung verkünden, an der ich maßgeblich mitarbeiten durfte und die jetzt auch tatsächlich online gegangen ist: werkannwann.de.

werkannwann.de ist eine Webanwendung zur Online-Abstimmung von Terminen. Ich erklär's an einem Beispiel: In meiner Firma sind wir zum Arbeiten über die ganze Bundesrepublik verstreut. Damit wir uns auch trotz der Verteilung noch in Zukunft alle liebhaben, sehen wir uns öfter mal im Jahr alle zusammen, um uns abzusprechen. Aber es ist nie so einfach gewesen, dieses Treffen zu koordinieren. Ziel ist es, einen Termin mit allen abzustimmen, an dem die meisten teilnehmen können.

Henning, mein Chef, mailte dazu früher uns alle an: "He, wir müssen uns mal wieder alle zusammensetzen und Klönschnack halten. Wann habt Ihr Zeit? Ich schlage vor: ...", und dann folgten ein bis zwei Dutzend Datumsangaben. Und dann kamen die Antworten: "Ich kann dann und dann, aber da und da nicht, und da und da nicht so gerne." - "Mir passt's immer, außer [Liste von Datumsangaben]." - "Vielleicht könnte ich es da und da einrichten, aber sicher bin ich mir noch nicht. Da kann ich überhaupt nicht und hier bin ich mit meiner Familie im Urlaub, wo wir [lange Geschichte, die nett ist, aber irrelevant für die Terminabsprache]."

Jetzt hatte Henning viel Arbeit: Er musste aus den Antwort-E-Mails quasi alle Angaben herausfiltern, wann seine Mitarbeiter konnte, wann sie nicht konnte, und wann sie konnten, aber nur mit Bauchschmerzen. Das war viel Arbeit, langweilig und stupide. Und genau das übernimmt jetzt werkannwann.de!

Wenn Henning mit uns Mitarbeitern jetzt einen Termin abstimmen möchte, dann ruft er http://www.werkannwann.de auf:


Dort legt er dann eine neue Abstimmung an, gibt den Titel und eine Beschreibung ein und macht Datumsangaben, die seiner Meinung nach passen könnten. Er möchte das nächste Meeting irgendwann im Mai stattfinden lassen, Montags oder Freitags (aber nicht am 2. Mai, da sind vielleicht noch nicht alle wieder nüchtern haben einige vielleicht einen Brückentag geplant):


Auf der zweiten Seite gibt er noch die Namen und E-Mail-Adressen von sich und allen potentiellen Teilnehmern ein (ich hab die Darstellung mal etwas fürs Beispiel gekürzt; und die E-Mail-Adressen sind auch alles dieselbe, nämlich meine, sonst mache ich die ganze Firma kirre mit so einer Beispiel-Abstimmung). Er kreuzt an, dass auch er selbst an der Abstimmung teilnehmen möchte. Er nimmt noch schnell die AGB zur Kenntnis - und schon ist die Abstimmung angelegt:


Jetzt bekommt Henning eine E-Mail mit zwei Links: Mit dem ersten bestätigt er seine E-Mail-Adresse und veranlasst das Verschicken der Einladungs-E-Mails an die Teilnehmer. Mit dem zweiten kann er sich das Ergebnis anschauen. Dazu aber später mehr.

Jetzt bekommen die Teilnehmer also Einladungen via E-Mail. Dort ist ein Link drin enthalten, mit dem sie zur Abstimmung auf werkannwann.de gelangen. Dort wählen sie zwischen drei Optionen: ich kann (grün), ich könnte es möglich machen (gelb) oder ich kann nicht (rot). Ich lasse hier mal gerade meinen Kollegen Martin abstimmen:


Sobald der Teilnehmer gewählt hat, bekommt er eine anonymisierte Übersicht präsentiert, das bisherige Zwischenergebnis sozusagen (Martin war hier der erste, der abgestimmt hat):


Wenn dann irgendwann alle Teilnehmer abgestimmt haben, dann klickt Henning, der die Abstimmung gestartet hatte, sich über seinen zweiten Link auf eine andere Übersicht, in der er auch noch sieht, wer wie abgestimmt hat. Das ist hier wichtig, damit er evtl. nochmal nachfragen kann, falls nur ein einziger an einem bestimmten Termin nicht kann, alle anderen aber doch. In der Übersicht sieht Henning auch sofort, an welchem Termin die meisten können.


Schließlich kann Henning einen Gewinnertermin festlegen. Dann kann er alle Teilnehmer darüber informieren, welcher Termin das Rennen gemacht hat. Ihm wird da schon ein Text vorgeschlagen, den er nach seinen Wünschen abändern kann.


Wenn er den Text jetzt abschickt, dann bekommt jeder Teilnehmer Hennings Nachricht, und die Abstimmung ist beendet.

werkannwann.de ist nun erstmal in einer geschlossenen Alphaversion online. Das machen wir, um zu schauen, ob die Anwendung überhaupt "echte" User verträgt, und um nicht gleich alle zu enttäuschen, falls sie das noch nicht tut oder sich nicht so galant verhält (das böse Stacktrace-Monster, ihr wisst schon).

Abstimmungen anlegen darf also nur der, der die geheime Login-Passwort-Kombination kennt. Die verrate ich allerdings jedem, der's wissen möchte: eine E-Mail an info@werkannwann.de reicht da völlig. Wenn Ihr dann werkannwann.de ausprobiert, dann wäre Feedback natürlich echt super! Aber auch so freuen wir uns über jeden Besucher :-)

P.S.: An alle, die nerven, wann das Grails-Buch endlich kommt: Es kommt, wann es kommt. Wir sind noch dabei, aber werkannwann.de hat erstmal Vorrang. Alle dort gesammelten Erfahrungen fließen schließlich auch wieder ins Buch ein. Das Buch ist für Praktiker gedacht, ergo brauchen wir Praxis. Und mal ehrlich: So eine Webanwendung zu bauen ist doch viel spannender als darüber zu schreiben, oder? Also nicht verzagen, das Buch kommt!

Team-Radar

Meine Kollegen Stefan (Hompage) und Sebastian (Hompage) haben vor einigen Tagen ihre erste selbstgebaute Grails-Anwendung online gestellt: Team-Radar. Gehostet wird das ganze von meinem Brötchengeber it-agile. Ich selbst habe da einen Tag ganz am Anfang mitgemacht, beratend, quasi als Starthilfe.

Mit Team-Radar kann man online Umfragen zum Softwareentwicklungsprozess eines Teams starten. Der Umfrager legt so eine Umfrage an und bekommt dann zwei Links. Den einen verschickt er an alle Teammitglieder, den anderen behält er für sich. Die Teammitglieder finden dann hinter ihrem Link Fragen zum Prozess, die sie nacheinander beantworten sollen. Dabei geben sie pro Frage auf einer Skala von 1 bis 10 jeweils den Ist- und den Soll-Zustand an.

Haben das dann alle Teammitglieder gemacht, dann kann der Umfrager schließlich mit seinem Link eine Auswertung bekommen:


Der rote Bereich zeigt den Ist-Wert, der blaue den Soll-Wert. Eine Tabelle mit einer Auflistung der einzelnen Werte gibt's auch noch dazu.

Die Anwendung ist ganz nett, um eine (anonyme) Bewertung seines Softwareentwicklungs-Prozesses von allen Team-Mitgliedern zu erhalten. Natürlich kann man das auch ohne Tool machen, z.B. während einer Retrospektive. Wäre aber bestimmt nicht so schön aufbereitet von den Ergebnissen her. Und vielleich sind ja auch gerade nicht alle Teammitglieder greifbar, wenn man solch eine Auswertung starten möchte (Urlaub, Krankheit, projektexterne Aufgaben etc.). Oder das Team ist verteilt. Oder man möchte die Umfrage gerade anonym haben. Und genau in diesen Fällen, genau dann würde ich den Team-Radar einschalten.

Update 01.08.2008: Team-Radar heißt jetzt TeamSpider. Rider, Twix, ihr kennt das ja ;-)

[Grails eXchange] Nachtrag: Folien und Videos

Nun haben mich schon mehrere Leser angesprochen und -geschrieben, wo sie denn der Folien der Konferenz habhaft werden können. Euch werd' ich helfen: Die Folien werden in der nächsten Zeit nach und nach online gestellt. Ihr findet sie auf den Seiten der jeweiligen Speaker; Guillaumes Folien zu Keynote und DSL-Session stehen schon online zur Verfügung.

Aber nicht nur das: Jede Veranstaltung wurde auf Video aufgezeichnet. Die werden online gestellt, sobald das Rohmaterial geschnitten wurde. Schaut einfach mal öfter auf den Speakerseiten vorbei.

Und wer's gar nicht abwarten kann: Jeder Teilnehmer hat eine CD mit den Folien aller Sessions bekommen. Die sind allerdings nicht auf dem letzten Stand; es gab da ein paar Mutige, die die Nächte vor ihren Sessions noch kräftig an den Folien gewerkelt haben. Falls also jemand diese Folien haben möchte, der möge mir eine E-Mail an bernd(dot)schiffer(at)gmail(dot)com schicken und ich sende sie Euch dann zu.

[Grails eXchange] Live-Blog: Exit

Das waren drei schöne Tage in London bei der Grails eXchange 2007. Es war sehr anstrengend, nicht zuletzt das Aufpassen bei den Sessions, während man bloggt. Aber es hat Spaß gemacht, und wie! Viele tolle Leute waren da und ich habe den Austausch mit ihnen sehr genossen. Eine Menge Ideen sind mir während des Aufenthalts dort gekommen - bin schon gespannt auf deren Umsetzung.

Ich habe zu 17 Sessions, Paneldiscussions und Keynotes gepostet und zusätzlich zwei Berichte nach einem bzw. drei Tagen geschrieben. Ihr könnt alle [Grails eXchange]-Beiträge hier lesen. Aber jetzt seit Ihr dran: Haben Euch die Beiträge gefallen? Soll ich auf der nächsten (Grails eXchange-)Konferenz erneut berichten? Was war gut, was weniger? Nutzt die Kommentierfunktion am Ende dieses Postings oder schreibt mir eine E-Mail: bernd.schiffer(at)gmail.com. Freue mich über jedes Feedback!

Schamlose Werbung: Die nächsten Schulungen mit Stefan und/oder mir in Hamburg für Groovy und für Grails stehen bereit. Termine und Inhalte gibt's hier für Groovy und hier für Grails.

[Grails eXchange] Nach drei Dritteln

Ich sitze gerade auf meinem Hotelzimmer und lasse die letzten drei Tage vor meinem inneren Auge Revue passieren. Das hat Spass gemacht, obwohl es sehr anstrengend war. Einige sind heute schon vor Schlafmangel eingenickt bei den Sessions des dritten Tages - es war also eine erfolgreiche Konferenz ;-)

Gestern abend nach den Sessions fand ein gemeinsames Treffen der User Groups Java und Groovy & Grails London statt. Ich habe mir keine weiteren Notizen mehr gemacht, da es auch kein Bestandteil der Konferenz war, aber es war doch recht interessant. Jemand von der Java User Group stellte vor, wie man Teile von Grails auch in Javaprojekten nutzen kann. Jemand von irgendeiner komischen Architektengruppe zettelte eine Diskussion über die Erfahrungen mit Groovy in Projekten an (Groovy ist dabei sehr gut weggekommen, wen wundert's?) und schließlich hat Guillaume Laforge die Ergebnisse der vierten GroovyDevCon vorgestellt, also einen Ausblick auf Groovy 1.2 und 2.0 gegeben - und da ärgere ich mich jetzt schon ein wenig, denn es ist kaum was hängen geblieben davon bei mir und das wäre doch richtig interessant jetzt hier zu lesen, oder?! Naja, sollen erstmal 1.1 fertig machen, der Rest kommt dann noch. Und fertig priorisiert haben die Groovyentwickler auch noch nichts, also kann sich an der geplanten Roadmap noch einiges ändern. Somit lasse ich die Hunde jetzt einfach mal schlafen...

Gestern abend gab's noch eine kleine Party, an der aber auch nicht mehr so viele teilgenommen haben. Nach der letzten Session heute fand noch ein Quiz statt. 17 Bücher erhielten so einen neuen Besitzer, je eines pro richtig beantworteter Frage. Nettes Gimmick, obwohl die Fragen doch wirklich etwas schwieriger hätten sein können. Ich bedanke mich trotzdem recht herzlich für mein Buch an dieser Stelle!

Nach dem Quiz fand noch so eine Art Frage-und-Ich-code-Dir-die-Antwort-Session statt: Das Publikum wollte wissen, wie man dies und das macht und Guillaume und Graeme haben das dann in die Tat umgesetzt, live und am Beamer. Die letzte Frage verlangte nach einem Beispiel in IntelliJIDEA, um die Leistungsfähigkeit dieser IDE zu demonstrieren - und einmal mehr bekomme ich den Eindruck, dass kein Weg beim professionellen Entwickeln von Groovy und Grails an IDEA mehr vorbeiführt. Es ist einfach u-n-g-l-a-u-b-l-i-c-h, was die JetBrain-Jungs da aus dem Tool herausgeholt haben. Man stelle sich mal vor: Ein Attribut einer Javaklasse wird aus einem Grails-Controller heraus referenziert und bei einem Refactoring innerhalb der Javaklasse, bei dem das Attribut umbenannt wird, wird auch die Referenz korrekt umbenannt! Oder: An einer Instanz einer Groovyklasse wird eine Methode aufgerufen, die zur Compilezeit nicht existiert (kein Fehler, weil könnte ja durch MOP so gewollt sein, etwas in einem Builder). Wird die gleiche Methode dann nochmal gebraucht, wird on-the-fly dafür Codecompletion zur Verfügung gestellt. IDEA lernt! Das ist ziemlich abgefahren und vor allem nützlich, bedenkt man mal, was das z.B. bei einem Builder bedeutet, wenn man z.B. XML erstellen will. Total genial. Oder die Codecompletion der Taglibs in den Views - selbst für eigene Tags!

Wenn man mal bedenkt, dass das die erste Version des JetGroovy-Plugins in IDEA ist... Graeme meinte, die Pläne von IDEA sehen vor, dass IDEA für Groovy ebenso leistungsfähig wird wie für Java. Wenn das stimmt, dann wird eine große Hürde vor Groovy für viele Skeptiker genommen sein, die bislang Groovy gescheut haben, weil es keine IDE-Unterstützung gab. Ach, was schreibe ich da, die Hürde ist doch eigentlich jetzt schon mit IDEA 7.0 genommen!

Fazit: Absolut gelungene Konferenz in einer tollen Atmosphäre. Sehr empfehlenswert! Ich hoffe, nächstes Jahr wieder dabei sein zu können, und freue mich da jetzt schon drauf.

[Grails eXchange] Session Ajax Development with Grails & Dojo

Sven arbeitet bei Yahoo und erzählt heute über Dojo. Hä? Nope, richtig gelesen. Obwohl Svens ehemalige Firma ist von Yahoo aufgekauft worden. Daher arbeitet er bei Yahoo. Vor dem Kauf hat er schon seinen Vortrag eingereicht bei der Grails eXchange, und daher macht er heute Dojo.

Mit Grails kommt noch die alte Version von Dojo, 0.4.3 daher. Will man Dojo 0.9 benutzen, muss man das momentan noch selbst installieren. Grails hat spezielle Tags, die Ajax ermöglichen, und unter der Haube wird dann dort auch Dojo benutzt, oder Yahoo! UI oder Prototype, je nach dem, was man haben möchte.

Ajax meint meistens Ajax plus Widgets, und Dojo ist reich an Widgets. Für diese gibt es allerdings keine Tags; Dojo-Widgets muss man selbst coden in JavaScript.

Sven zeigt live eine Grails-WebApp. Dann zeigt er die Tags in Grails, die das Ajaxzeug machen. remoteLink: Damit kann man einen Link anlegen, der eine Action aufruft, deren Antwort dann in ein DIV-Tag geladen wird. formRemote: Ein Formular, nicht-ajaxifiziert als form-Tag realisiert, wird asynchron abgeschickt. submitToRemote: ähnlich wie formRemote, allerdings stellt dieses Tag einen Button innerhalb eines normalen Formulars dar, mit dem man den Formularinhalt asynchron abschicken kann. remoteField: ein Feld innerhalb schickt sich selbst ab, wenn es geändert wird. Alle Tags können mit Event-Handlern versehen werden.

Sven priorisiert JSON vor XML (wer tut das nicht :-) ) und zeigt u.a. den JSON-Builder, eine DSL, mit der man JSON bauen kann. Mit JSON zeigt er dann auch ein paar Anwendungsbeispiele, beispielsweise eine Drop-Down-Liste, die Vorschläge automatisch beim Eintippen anbietet, indem die Vorschläge asynchron vom Server geholt werden. Sven endet mit ein paar Folien zu Resourcen.

War ganz nett; auf jeden Fall sind die Folien einen Blick wert, wenn man erste Gehversuche in Grails + Dojo unternehmen möchte, denn da stehen ein paar gute Beispiele drin, wie die ajaxifizierten GSP mit den entsprechend JSON zurückgebenden Action in den Controllern zusammenarbeiten.

[Grails eXchange] Session GORM-ORM with Hibernate Demystified (Graeme Rocher)

Graeme, Project Lead von Grails, zeigt den Object-Relational Mapper in Grails (GORM, wobei G für Groovy steht). Dieses Tool ist auch separat von Grails einsetzbar. In Grails ist es einer der Hauptstützfeiler der Architektur.

Hibernate steckt unter der Haube von GORM. Anders als bei Ruby on Rails (RoR) nutzt Grails kein ActiveRecord-Pattern, um die Persistenzgeschichte zu erledigen. Grails leitet via GORM die Informationen direkt aus den Domainklassen ab. Da stecken gut durchdachte Defaulteinstellungen dahinter. Tatsächlich gibt es, sofern man nichts tweaken muss, keinen Bedarf an Mapping-Files, wie man sie in Hibernate normalerweise nutzt.

Graeme führt gerade die Vorteile von Hibernate aus und begründet damit den Einsatz in Grails. Ich spare mir das mal hier: Hibernat ist gut und daher in Grails enthalten.

Interessant ist, wie GORM das Mapping aus den Domainklassen zieht. Groovy ist dynamisch und statisch typisierbar. In Domainklassen nutzt man das statische Typisieren, um Informationen zu bekommen für den Typ der Tabellenspalte in der Datenbank.

Mit statischen Maps wie hasMany oder belongsTo steuert man die Abbildung der Assoziationen zwischen Domainklassen, zumindest was die Aggregationen angeht. Es können Sets und SortedSets benutzt werden, ebenso wie Maps und Lists.

Früher konnte man Legacy Datenbanken anbinden, indem man in Grails Mapping-Dateien einbindet, um die Domainklassen mit den Alttabellen zu verbinden. Jetzt gibt es die neue Mapping-DSL, mit der man das in der Domainklasse selbst machen kann, und zwar eben genau so viel, wie man braucht. Dort, wo man nichts angibt, fällt man zurück auf das Default-GORM-Verhalten.

GROM bietet dynamisch Methoden an den Domainklassen zur Verfügung, etwa save(). Hat man eine Aggregation etwa zwischen Author und Book, dann kann man sagen

autor.addToBooks(book)
autor.removeFromBooks(book)

Constraints, wie man sie früher entkoppelt vom Domänenmodell in der Datenbank pflegen musste, werden nun abgeleitet aus einer Deklaration im Domänenmodell. Ist das DRY oder was?! In jeder Domänenklasse kann man, naürlich via einer ausgeklügelten DSL, Constraints definieren.

Graeme zeigt Teile der oben beschriebenen Features nun live. Interessant dabei: Die Constraints beeinflussen auch die Validierung von an der Oberfläche eingegebenen Werten. Die Fehlermeldungen werden dabei aus einer message.property (normales I18n-Verhalten aus Java) angezeigt, die man zur Laufzeit ändern kann. Die zur Verfügung stehenden Validierungsmöglichkeiten sind vielfältig. Die Validierungen werden automatisch beim Speichern eines Domänenobjektes validiert. Kann man alles sehr schön schnell live erleben, wenn man sich mal eine kleine Beispielapplikation scaffolded.

Wieder zurück in den Folien zeigt Graeme die dynamichen Finder-Methoden. Hat ein Book ein en Title, dann kann man schreiben

Book.findByTitle("Harry Potter and the Goblet of Fire")

Nett: Graeme bemüht die GroovyConsole, die in Grails eingebettet ist. Damit kann man auf so ziemlich Alles, insbesondere hier auf die Domainklassen, zugreifen, und mal eben schnell etwas ausprobieren. Wird aufgerufen über grails console Wie bei Hibernate auch, kann man etwas suchen, wenn man ein Beispielobjekt zur Verfügung stellt. Und schließlich kann man auch via Hibernate-Kriterien suchen - mit dem HibernateCriteriaBuilder, der eine gute DSL dafür zur Verfügung stellt.

Alle Aktionen sind transaktional, wenn man möchte. Das wird durch Spring zur Verfügung gestellt. Das transaktionale Verhalten kann wiederum via Grails beeinflusst werden. Optimistisches Locking ist Default, kann aber via lock()-Methode umgestellt werden aufs Pessimistische Locking.

(Fast) Nichts Neues für mich; guter Vortrag. Empfehlenswert.

[Grails eXchange] Session: Canoo Web Test & Grails (Dierk König)

Dierk ist (einer der) der Entwickler von Canoo WebTest, Autor von GinA und Comitter von Groovy und Grails. WebTest wird für die Entwicklung funktionaler Tests verwendet (aka Akzeptanztests). Es ist Opensource, obwohl der Name (Canoo) da vielleicht fehlleitet.

Dierk zeigt zuerst mal, wie der Nicht-Grails-Webtest aussieht: eine XML-Datei, in der man Schritt für Schritt angeben kann, wie man eine Webseite bedienen möchte: Klick hier, trage dort BlaBla ein und dann verifiziere, dass im Titel danach Foo steht. Diese XML-Datei ist ein valides Ant-Skript und so führt man es auch aus.

Das Ergebnis wird in einem Report dargestellt, in dem man im Browser surfen kann, da es sich um HTML-Seiten handelt. Der Report ist sehr aussagekräftig. Lustig: es gibt da eine Auflistung der Schritte, die man im Test bereits gemacht hat. Dierk meint, wenn jemand manuell testen möchte, dann hat man es hier super aufgeschrieben und kann einem dann das sog. Storyboard geben :-)

Dierk zeigt vier Pattern beim Testen: Capture/Replay, Modelbasiertes Testen, Dategetriebenes Testen und geskriptete Automatisierung, worauf Dierk kurz eingeht. Je weiter in der Liste, desto effizienter das Pattern. Dierk mag definitiv keine Capture/Replay-Tools ("the least cost-effective way of test automation"!).

Typische Projekte werden vorgestellt und die Strukturen hinter einem Webtest. Dierk erzählt davon, dass er am Ende eines Projektes, dass er mit WebTests versieht, bei 5000-7000 Tests landet! 5 bis 7 Kilo!

Zu den Zusicherungen meint Dierk, dass man sie so spezifisch wie nötig und so "loose" wie möglich definieren sollte. Wie wahr! Er favorisiert XPath für die Zusicherungen, um sich die zu untersuchenden Elemente herauszupicken. Dabei macht Dierk anhand eines Beispieles deutlich, wie man schlechte und gute Ausdrücke unterscheidet.

Auf der Webseite ist eine sehr gute Dokumentation zu sehen - kann ich bestätigen, die ist wirklich super!

Wie wird nun WebTest groovyfiziert? Erstmal zeigt Dierk, wie man Groovy per Ant-Task in einem Ant-File einbinden kann, um feine Veränderungen in z.B. der Konfiguration zu machen. Einfach scheint auch das Einfügen eines neu erstellten Schrittes (Step) zu sein. Dierk zeigt da gerade noch mehr interessanten Kram: Er erweitert XPath um eine neue Funktion mit Groovy. Abgefahren :-)

Nun aber kommt endlich die DSL, die man aus Grails auch kennt - keine spitzen Klammern mehr, willkommen in der Curly-Braces-World! Im Endeffekt ist das eine 1-zu-1-Abbildung von XML nach Groovy.

Dierk setzt hin sich zur Live-Demo. Übrigens der erste Speaker, der an einem PC arbeitet. Alle seine Vorgänger, die ich hier erlebt habe, brachten einen Mac mit. Egal, Details.

Juchu, Dierk macht TDD. Naja, so fast: er erzeugt die Domainklasse, ohne die Tests vorher rot laufen zu lassen (die ja noch nicht da sind). Aber das bekomme ich gleich aufs Brot geschmiert, indem er dem Publikum erläutert, dass ich das getan hätte. Puh, TDD-Ehre gerettet :-)

Dierk erstellt also eine Domain-Class, danach generiert er das Scaffolding und den Webtest hierzu und läßt das ganze Laufen per Grails. Es poppt eine Webseite mit dem Report auf. Der generierte Webtest beeinhaltet schon rudimentäre Tests für die CRUD-Methoden.

Cool: in dem Report kann man mitlerweile wie mit dem Daumenkino durch die Schritte blättern, die der Test durchlaufen ist. Tolles Feature, wenn man rote Tests hat!

Genial: Es gibt einen WebTest-Rekorder, den man in Firefox einbinden kann. Wow, das Tool rockt total! Schaut Euch das mal an! Und schaut Euch auch (und ganz besonders) die Warnung im roten Rahmen an. Darauf geht Dierk gerade in den weiteren Folien ein. Kann ich ganz dick unterstreichen, seine Ausführungen.

So schaut übrigens ein typischer Test aus:

invoke(description: "Get the page: Google", url: "http://www.google.de/")
invoke(url: "http://www.google.de/")
setInputField(name: "q", value: "Groovy")
clickButton(label: "Google-Suche")
verifyTitle(description: "Verify page's title", text: "Groovy - Google-Suche")

Toller Vortrag (bin noch nie enttäuscht worden, wenn ich zu einem Vortrag von Dierk gegangen bin). Sehr empfehlenswert.

[Grails eXchange] Session The Whole 9 Yards: Things you can do in 10 minutes that will make users love you (Glen Smith)

Glen Smith ist der Macher von groovyblogs.org und hat einen sehr empfehlenswerte Blog, der viele coole Sachen zu Groovy und Grails eingetragen hat.

Glen erzählt über seine Erfahrungen mit der Entwicklung von Webanwendungen mit Grails. PDF erstellt er direkt von HTML-Seiten mit iText. Thmbnails von Webseiten bekommt er einfach per AWT. Da dies aber XHTML-Strictness voraussetzt und nicht alle Webseiten dies bereitstellen, ist vielfach hierfür eine Aufbereitung erforderlich (hat er mit TagSoup gemacht). Allerdings: besser geht's mit einer SWT-Lösung, weil es dort eine Browser-Komponente gibt. Graphen erstellt Glen mit JFreeChart, Caching bekommt er mit EHCACHE hin. RSS erstellt und verdaut er mit ROME. Mit Textile und Grailscodecs realisiert er Wikimarkup, dass Benutzer in Textfeldern eingeben können.

Nette Effekte auf der Webseite erstellt Glen mit script.aculo.us (in Grails integriert); die Effekte sind aber auch wirklich gut und so einfach zu erstellen. Genial.

Fürs Layout schlägt Glen Yahoo! UI vor. Das kannte ich noch nicht: YUI bietet ein vorgegebenes Layout an, das sehr gute Proportionen bietet und wirklich gut aussieht. Es ist flexibel einstellbar und einfach zu handhaben. Glen stellt dann noch andere Kleinigkeiten der YUI-Bibliothek vor. Sieht alles sehr gut aus.

So, dass waren dann die 10 Dinge, die man alle machen kann. Obwohl es größtenteils eine Toolshow war, habe ich einen guten Eindruck bekommen. Das mag daran liegen, dass diese Dinge alle recht einfach einzubinden und zu benutzen sind (jeweils in 10 Minuten, laut Glen).

Guter Vortag, hat mir sehr gefallen. Folien gibt's hier.

[Grails eXchange] Session Grails in the Real-World (Marc Palmer)

Marc Palmer, einer der aktivsten Grails-Comitter nach Graeme Mister Grails Rocher himself, teilt ein wenig seinen Erfahrungsschatz. Er hat schon einige Websites gestaltet, und seit Anfang des Jahres auch mit Grails.

Und es sind Websites, keine Webapps, wie er betont. Da sind z.B. solche Webseiten dabei wie Troicana. Dahinter steckt ein sehr großer Kunde: Pepsico.

Er ist zu Grails gekommen über einen Umweg. Zuerst hatte er sein eigenes Framework erstellt mit Groovy und Spring, bevor er dann von Grails hörte.


Seine Folien sind klasse: Sehr gute Fotos, die seine Worte unterstreichen. Einfach mal anschauen, sieht toll aus.

Marc erzählt über die Lektionen, die er gelernet hat während seiner Zeit mit Grails: Controller, Views, Codecs. Im Endeffekt stellt er Teile seiner Webseiten als Grafiken vor und zeigt dann, wie er's gemacht hat. Da ist eine Wettervorhersage dabei, ein Postkartenservice und ein Blog.


Während seiner Arbeit hat er sich das Leben erleichtert, indem er Plugins geschrieben hat: StaticResourcesPlugin (hat er auch gleich veröffentlicht), EmailConfirmationsPlugin (nicht veröffentlicht), MicroFormatPlugin (wird veröffentlicht).

Toller Vortrag und gutes Marketing für Grails: es funktioniert, auch wenn jemand hinschaut!

[Grails eXchange] Session Acegi on Grails, Security on Grails (Tusyoshi Yamamoto)

acegi ist für Authentifizierung und Authorisierung zuständig. Tusyoshi kommt aus Japan und hat's erfunden. Es gibt ein Acegi-Plugin für Grails. Bis Ende diesen Jahres heißt es noch Acegi, danach Security.

Die Technik dahinter ist schnell erklärt: ein Filter, der auf konfigurierbare URL-Patterns anspringt, leitet bei Bedarf den Request auf eine Login-Seite weiter. Es gibt Support für single sign on, LDAP, x509 uvm. Sehr umfangreich, erweiterbar, flexibel. Ab geht's zu Grails.

In Grails selbst hat mit dem Plugin eine Datei namens "AcegiConfig.groovy" zur Kontrolle des Verhaltens von Acegi. Soweit ich weiss gibt es dort die entsprechenden Defaulteinstellungen, die man ändern kann, wenn man möchte. Es gibt darüber hinaus bestimmte Domainklassen, Controller, Taglibs usw., die z.B. User repräsentieren o.ä. Man kann dann in der BootStrapklasse entsprechende Stammdaten wie Personen, Rechte und Mappings angeben.

Jetzt greift er in die Tasten und demonstriert live auf der grünen Wiese das Plugin im Einsatz. Er installiert das Plugin und legt die Domänen-Klassen an. Mir fällt auf, wie viel Wert er auf die Konfigurierbarkeit des Plugins legt. Per Default wird z.B. u.a. die Klasse Auhtority angelegt. Man kann das aber auch umbenennen in Role. Dies Konfigurations-Denke ist in Grails aus meiner Sicht fehl am Platz.

Wie auch immer: Als Tusyoshi dann die WebApp startet, sieht alles nett aus. Es gibt einen Login- und einen Logoutcontroller, der das Verhalten der Anwendung entsprechend steuert. Sieht einfach und gut aus.

Es gibt Taglibs für Grails, die Bereiche einer Webseite entsprechend aus- bzw. einblenden können je nach Rolle des Users. Darüber hinaus gibt's Tags um sich Infos über den gerade angemeldeten User anzuzeigen oder Infos darüber, ob überhaupt jemand angemeldet ist.

Hm, irgendwie komisch, wenn da ein Plugin Dinge in meine Domainklassen packt, die ich eigentlich gar nicht in meiner Domäne haben will.

Per URL Login und Logout zu managen ist vielfach ok, aber manchmal möchte man das auch auf Service- oder Controllerebene erledigen. Kann man: Das Grailsplugin bietet entsprechende Aufrufe in Controllern und Services an.

Das Grailsplugin unterstützt auch Ajax-Security. Dabei wird dann der Request beim Filtern nicht auf die Login-Seite weitergeleitet, sondern ein kleiner Rahmen wird aufgemacht, in dem man sich einloggen kann.

Per AOP kann man auch noch Services sichern - aber das passt einfach nicht mehr in den Rahmen dieser Veranstaltung, hat doch der Speaker bereits 10 Minuten überzogen.

Acegi scheint genau das zu tun, was man erwarten könnte. Gut so. Die Einbettung in Grails könnte noch besser sein, aber Tusyoshi meinte, dass er gerade an weiteren Features arbeitet. Bin gespannt, wohin das noch führt.

Der Vortrag selbst war übrigens ganz amüsant: Tusyoshi hatte eine Übersetzerin zur Hand, die er allerdings nur zweimal konsultieren musste. Dabei haben sie sich ziemlich lange über eine kurze Frage aus dem Publikum unterhalten :-) Insgesamt hat der Vortrag und der Vortragende einen guten Eindruck hinterlassen bei mir.

[Grails eXchange] Session Dynamic Groovy: Meta Magic (Graeme Rocher)

Graeme, Project Lead von Grails, gibt sein Bestes zum Thema MOP (Meta Object Protocoll). Er gibt eine kleine Einführung in Groovys dynamische und gleichzeitig auch statische Typisierung. Dann geht's gleich los mit einer Rundreise in der Groovy-MOP-API: MOP Hooks, Categories, ExpandoMetaClass.

MOP Hooks sind invokeMethod, methodMissing, get/setProperty und propertyMissing. Diese Methoden sind jeweils an einer Klasse zu überschreiben, will man das Verhalten dieser Klasse auf der Metaebene beeinflussen. Graeme greift jetzt zur Tastatur und schreibt ein Beispiel.

class XmlBuilder {
 def invokeMethod(String name, args) {
   if(name == 'text') {
     println args[0]
   } else {
     println "<$name>"
     def callable = args[0]
     callable.delegate = this
     callable()
     println ""
   }
 }
}

html = new XmlBuilder()

html.html {
 head {
   title {
     text "This is a Test"
   }
 }
 body {
   ul {
     li {
       text "Groovy is great!"
     }
     li {
       text "Grails rocks!"
     }
   }
 }
}

So schnell kommt man zu einem kleinen HTML-File :-) Graeme fügt dann noch das Feature "Links" dem Skript hinzu, also das Zurechtkommen mit Attributen in den Tags.

Jetzt kommt die ExpandoMetaClass unters Mikroskop. Methoden und Properties können on-the-fly hinzugefügt werden. Statische Methoden und Konstruktoren sind auch kein Problem mehr. Also sehr einfach.

Graeme spricht über Meta Patterns. Strings können als Methodennamen benutzt und dynamisch aufgerufen werden. Caching ist ein weiteres Pattern: wenn eine neue Methode aufgerufen wird, die vorher nicht bekannt war, dann wird sie erzeugt, Inhalt hinzugefügt und dann ausgeführt. Das ist relativ teuer von der Performance her. Hier kann man einen Cache einführen, der die Methode nachschlägt und nur dann erzeugt, wenn sie noch nicht existiert hat (Hookmethode methodMissing wird hier benutzt). Davon wird in Grails Gebrauch gemacht, z.B. bei den Codecs. Ziemlich clever gemacht, schaut mal bei Erscheinen in die Folien für Codebeispiele. "Intercept, Synch, Cache, Invoke" ist das Pattern insgesamt, denn Groovy läuft auf der Multithreaded JVM, und da ExpandoMetaClass mutable ist, muss man eben entsprechend synchronisieren - und zwar in eben genau der Reihenfolge intercept, synch, cache, invoke.

Guter Code, nette Beispiele, Einsicht in Grails - was will man mehr :-) Empfehlenswert.

[Grails eXchange] Session Advanced Layouts with SiteMesh (Joe Walnes)

Mit SiteMesh regelt man alles rund ums Layout, nicht nur in Grails. Ich selbst bin erst mit Grails auf SiteMesh aufmerksam geworden, wie die meisten anderen der 10 weiteren Zuhörer hier auch. Mehr als das Grundprinzip habe ich nicht umgesetzt, daher bin ich an den Advances-Sachen interessiert.

Joe zeigt ersteinmal, warum jsp:include Dreck, mindestens aber nicht DRY ist. Dann präsentiert er SiteMesh außerhalb von Grails. Er macht das live. Zuerst erstellt er eine HTML-Seite, absolut rudimentär. Dann erzeugt er einen SiteMesh-Decorator, ein XML-File. Dieses enthält alle Informationen zum Layout, beispielsweise auch das CSS (kann auch eine CSS-Datei referenzieren). Über ein Config-File (wird bei Grails per Konvention vermieden) werden die beiden Dateien zusammengebracht.

Beeindruckend, wie einfach das schon ohne Grails funktioniert. Ich dachte immer, Grails macht noch viel mehr im Hintergrund. Tatsächlich sagt Joe, dass Grails SiteMesh aufgrund der Einfachheit nutzt.

Technisch bindet sich SiteMesh als Filter in eine WebApp ein und filtert den jeweiligen Request. SiteMesh selbst ist ein jar-File. Dann gibt es noch beschriebene Config-Datei. Und das war's auch schon.

Interessant, wie man in einem Decorator auf die Elemente der Content-HTML-Seite verweist:

So wird der Titel aus der Inhalts-HTML referenziert.

In Grails kann man ein Layout entweder per Konvention angeben, oder aber per Meta-Tag im Head einer HTML-Seite. Berechtigte Frage aus dem Publikum: Gibt's da nicht ein Problem, wenn man aus der HTML-Seite heraus das Layout referenziert? Jap, gibt es, daher sollte man lieber immer die Konvention benutzen.

Die Konvention ist, dass man die Decorator abhängig vom Controller und den Actions in Grails in entsprechende Verzeichnisse legt.

Jetzt wird's spannend: Joe schlägt vor DecoratorMapper zu benutzen, z.B. den PrintDecoratorMapper, der alle Requests mit print=true auf ein entsprechendes Layout umleitet. Es gibt noch weitere DecoratorMapper. Man kann Bereiche in Grails per Tag g:applyLayout mit unterschiedlichen Layouts versehen. Inhalte der HTML-Seite können in den Dekoratoren benutzt werden, wie etwas body, head, meta und spezielle Tags wie content und param.

Mir kommt gerade die Idee, Fittests damit für den Kunden ziemlich einfach attraktiv zu machen... :-)

SiteMesh ist schnell, weil der Parser "custom written" ist. Der Parser kommt mit wirklich sehr schrottigem HTML aus - naja, nicht unbedingt das, was für Disziplin im Team sorgt, aber bestimmt hilfreich, wenn man externe HTML-Seite, auf die man selbst keinen Einfluss hat, neu gestalten möchte (HTML aus MS Word mit Fittests vom Kunden vielleicht).

Joe stellt jetzt ein Pattern vor, das nichts mit Grails zu tun hat, aber sehr interessant ist aufgrund der Art, wie er damit umgeht. Es geht um ein CMS. Seine Definition von CMS ist: jemand, der keine Ahnung hat von HTML, möchte seine Webseite updaten. Er möchte mit einem Tool arbeiten, dass er kennt (MS Word). Damit speichert er Dateien in HTML ab. Diese werden mit SiteMesh dann aufbereitet. Das Design stammt von einem Webdesigner. SiteMesh selbst wird aufbereitet über ein wenig Programmierarbeit von einem Entwickler. Sehr pragmatisch und einfach - und bestimmt sehr viel besser handhabbar als Typo3!

Guter Vortrag, netter Vortragender, empfehlenswert.