[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 Direct Web Remoting (Joe Walker)

Nachdem die netten Mitarbeiter hier extra für mich eine Kabeltrommer angeschleppt haben, kann ich weiterbloggen. Ich höre gerade Joe Walker reden über DWR.

Also mal ganz ehrlich: keine Ahnung, warum ich hier bin. Joe erzählt über DWR - und nur über DRW. DRW wird eingesetzt, um umfangreiche Ajaxaufrufe aus Webseiten heraus zu machen. Das scheint mit ziemlich viel Aufwand verbunden, was der Entwickler dafür tun muss: beispielsweise muss (aus Sicherheitsgründen) jede aufrufbare Funktion freigegeben werden.

Was hat das nun mit Grails zu tun? Mir ist bekannt, dass es ein DWR-Plugin für Grails gibt - aber warum? Es gibt Prototype, es gibt Dojo, es gibt Yahoo UI. Damit kann ich alles zu Ajax abdecken. Warum sollte ich DWR benutzen? Muss mal nachfragen...

Joe erzählte mir dann, dass man mit YUI, Dojo, Prototype kein Reverse-Ajax machen kann, also mit dem Server die Webseiten steuern (Stichwort: Streaming). Außerdem hat man sehr viele Vorteile in statischen Umgebungen (wie Java), wenn man DWR benutzt. Natürlich könne man letzteren Vorteil nicht in Grails geltend machen.

Naja, nicht so meine Welt. Muss da mal drüber nachdenken. Enttäuschend an dem Vortrag fan ich, dass er so gar nicht Grails mit ins Spiel gebracht hat und die Vorteile aus der Grailssicht geschildert hat. Und da ich überhaupt nicht vorbelastet war mit DWR in Grails, konnte ich auch nicht viel Wissenstransfer betreiben.

[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.

[Grails eXchange] Panel Discussion (Grame Rocher, Guillaume Laforge, Dierk König, Scott Davis)

Das sollte jetzt mal eine interaktive Session werden - und hochkarätig, haben sich doch da vorne große Namen niedergelassen: Graeme Rocher, Project Lead des Grails-Projektes; Guillaume Laforge, Project Lead des Groovy-Projektes; Dierk König, Groovy- und Grails-Comitter und Autor von GinA; Scott Davis, Entwickler von aboutgroovy.org.

Inwiefern sei Grails mehr als ein Webframework? Graeme hatte soetwas bei der gestrigen Keynote gesagt. Graeme erklärt, dass Grails viele Dinge beinhaltet, die man auch außerhalb von Grails sehr gut einsetzen kann, beispielsweise GORM oder SpringBuilder.

Wie bringt man Javaentwickler das Arbeiten mit Groovy bei? Einerseits kann man (fast) jedes Javaprogramm auch in Groovy ausführen und dann Stück für Stück groovyfizieren. Die Lernkurve ist zudem sehr günstig. In Grails läßt sich viel arbeiten, ohne allzu tief in Groovy einzutauchen. Man muß nicht alles wissen, was hinter den Kulissen passiert, z.B. bei den Buildern. Groovy ist zudem Java und hat daher auch den gleichen Mindshare. DSLs sind ein weiteres Mittel, um die Benutzbarkeit von Grails einfach zu halten. Dierk weißt darauf hin, dass Javaentwickler meist Probleme mit der Magic haben. Dem kann ich zustimmen.

Noch zu den DSLs: Graeme ist stolz drauf, dass bislang Grails' DSLs immer noch ohne Annotations auskommen :-)

Reloading von Grails wird angesprochen und gelobt. Graeme meint, dass war eines der hartesten Implementierungen innerhalb von Grails, weil es extrem schwierig sei. Eine JVM lädt normalerweise eine Klasse - und gibt sie nicht mehr frei. Das im Hinterkopf habend erklärt, warum Reloading innerhalb eines Webcontainers nicht so einfach ist, was aber nichts desto trotz gemanaged wurde von Grails.

Warum sollte man Groovy nehmen, wenn man auch Javascript hätte nehmen können? Kurz: Weil Groovy die bessere Syntax hat, demnach ausdrucksfähiger ist. Als Beispiel werden Closures ausgeführt, die bei Javascript viel umfangreicher ausgedrückt werden müssen als in Groovy. Allerdings wird auch darauf hingewiesen, dass immer auch der Kontext der Anwendung und der Entwickler in Betracht gezogen werden muss. Grame meint, dass Javascript ganz nett sei, jedoch nicht so mit Liebe auf den ersten Blick bei den Entwicklern daherkomt. Es sei etwas, an das man sich langsam gewöhnt und zu schätzen lernt. Dierk wirft ein, dass man aus Sicherheitsgründen doch eher eine Sandbox haben möchte - die Javascript so nicht bieten kann. Scott spricht sich gegen Javascript aus, weil es außer den ersten vier Buchstaben nicht viel gemein hat mit Java.


G2One ist gegründet worden. Inwiefern wird das die Groov-&-Grails-Welt beeinflussen? Die Community wird davon profitieren, sei es im besseren Marketing, in der besseren Dokumentation, der beschleunigten Entwicklung. Es werden vergleiche angestellt zwischen G2One und Interface12 (Spring) oder RedHat, Suse, Novell (Linux). G2One wird weiterhin die Community brauchen und wird diese auf keinen Fall ersetzen.

Die Rolle von Sun bei Groovy wird besprochen. Nichts Neues: Einerseits ist Sun interessiert in Groovy (wie in dynamische Sprachen generell), andererseits investiert Sun auch viel Ruby. Es scheint weiterhin ein spannendes Thema zu sein.

Und natürlich viel Kleinkram, den ich nicht mitschreibe(n möchte).

Nett, nichts dolles.

[Grails eXchange] Nach dem ersten Drittel

Da ich gerade nur noch das Ende der Keynote von Scott Davis, Macher von und hinter aboutgroovy.org, gesehen habe (blöde Zeitzonenumstellung :-( ), gebe ich mal kurz einen Zwischenbericht ab:

Das erste Drittel ist geschafft und es macht sehr viel Spaß hier. Es ist immer wieder schön, auf solchen Konferenzen alte Bekannte wiederzutreffen und neue Bekanntschaften zu schließen. Die Umgebung hier ist auch super: das Barbican Center ist ein großes Entertainment-Ding (Theater, Kino, Konferenzen) in einer riesige Wohnanlage. Die Räume der Konferenz sind zwar weit verteilt, aber sowohl von der Einrichtung als auch von der Akustik super. Sehr nett: man sitzt in den Pausen bei Kaffee und Kuchen in einem tropischen Garten mitten in dem Barbican Center und kann die Kois im Teich streicheln :-)

Ansonsten ist das Publikum kleiner, als erwartet (ich schätze mal so an die 150 Leute), aber hat viel Ahnun und ist sehr euphorisch. Es sind auch relativ viele Leute mit Jetlag aus den USA hier; Jeff Brown hat bei seinem Vortrag bei so ziemlich jeder Gelegenheit seine 36-Stunden-Wachphase als Erklärung für Mißgeschicke und Versprecher hingehalten. Glen Smith, Macher von groovyblogs.org, hat 33 Stunden Anreise aus Down Under auf sich genommen - und ist fit wie ein Turnschuh.

So, gleich geht die nächste Veranstaltung los und ich will mir noch einen Kaffee besorgen. Viele Grüße aus London!

[Grails eXchange] Session Test Driven Development with Groovy & Grails (Jeff Brown)

Jeff Brown, einer der sieben Groovy Grails Core Comitter, fängt an mit den Herausforderungen und den Benefits des Testens dynamischer Sprachen: Kein Compiler, wenig Tool-Support und unbekannte Dinge zur Compile-Zeit bzw. sehr testbare dynamische Sprachen, einfaches Testen dynamischer Sprachen und dem Zwang, dass man das macht, was man eh tun sollte. Starke Worte, dann mal los.

In Groovy soll man schnell reinkomen, wenn man Groovy testet. Groovy unterstützt Testen unter anderem dadurch, dass es einen GroovyTestCase anbietet und einige zusätzliche Assertions bereitstellt. Dieses Unit-Tests sind ähnlich wie Java-Unit-Tests vielfältig ausführbar.

Code Coverage Tools ist das nächste Thema: Cobertura, EMMA und Clover werden genannt, wobei Cobertura auch für Groovy funktioniert.

Expandos werden gezeigt als Alles-Testbar-Machen-Wunderwaffe in Zusammenspiel mit Duck-Typing. So wird isoliertes Testen möglich. Mocks und Stubs werden in Groovy bereitgestellt und vereinfachen ebenfalls das isolierte Testen (oder ermöglichen es in vielen Fällen sogar erst).

Enttäuschend: Es geht nur ums Testen, nicht ums Design oder gar ums Treiben des Designs.

Der Unterschied zwischen Unit- und Integrationstests wird diskutiert. Grails unterscheidet ebenfalls zwischen diesen beiden. Jeff zeigt, wie er eine Domain-Klasse in Grails integrativ tested. Endlich: Er erläutert den TDD-Zyklus und kommt auch auf Refactoring zu sprechen - für etwa 20 Sekunden :-(

Und wir sind bei den Functional Tests, also den Akzeptanztests. Hier bringt Jeff Selenium und Canoo WebTest ins Spiel. WebtTest rocks! Insbesondere mit der tollen DSL, die Grails da noch drüberstülpt.

Naja, nich' so pralle. Es ging um Tools und ums Testen - nicht so das, was ich hören wollte. Aber ich bin wahrscheinlich schon zu betriebsblind mit meinen TDD-Augen. Es kam aber ganz sicher nicht das Agile Feeling rüber, dass ich erwarten würde in einer TDD-Session.

[Grails eXchange] Session Domain Specific Languages in Groovy (Venkat Subramaniam)

Venkat Subramaniam ein weiteres Mal für heute. Diesmal: DSLs.

Venkat geht auf den Unterschied von internal und external DSLs ein. Groovy ermöglicht internal DSLs. Venkat betont die Wichtigkeite der Kontextsinsitivität ("Two Venti Latte with two Shot Expresso" means Coffee at Starbucks aka the Starbucks DSL).

Fluent Interface beschreibt Venkat etwas anders, als ich es bislang gehört habe und selbst beschreiben würde. Für ihn sind alle DSLs, auch die Builder in Grails, Fluent Interfaces.

Eine Pizzabestellung wird flüssig gemacht, indem alle Setter das Objekt selbst zurückgeben. Venkat entwickelt das Beispiel weiter: ein Setter gibt nicht sich selbst zurück, sondern die Zeit, die die Bestellung bis zur Auslieferung benötigen wird. Hier benutzt Venkat auf clevere Weise Closures.

Jetzt kommen die Builder ins Spiel. Venkat demonstriert die Power des MarkupBuilders, um XML zu erzeugen. Er spielt ein wenig mit MOP rum, und kommt dabei durcheinander mit Ruby (er erzeugt zum Beispiel eine Klasse test.rb) - interessanter Marketingeffekt, muss ich mir merken :-)

Venkat demonstiert noch ein weiteres Beispiel:

players 'Scott', 'Venkat', 'Neal'

Scott 7
Venkat 5
Neal 8

printScores

Das ist Groovy-Code! Wie macht er das? So:

printScores = [:]

def players(Object[] player) {
  player.each{ printScores."$it" = 0 }
}

def invokeMethod(String name, args) {
  printScores[name] = args[0]
}

Sehr schön!

Dann gibt's ein größeres Beispiel, mit dem er folgende Syntax als DSL etablieren kann:

2.days.ago.at(4:30)

Zuerst zeigt er das Ganze mit Categories, danach mit der ExpandoMetaClass.

Auf IntelliJs MPS sollte man ein Auge halten, meint Venkat.

Tolle Session!

[Grails eXchange] Session The Grails Plug-in Architecture (Graeme Rocher)

Graeme, Project-Lead des Grails-Projektes, spricht über das Plugin-System von Grails. Es gibt bereits viele Grails-Plugins - und das, obwohl Grails noch nicht 1.0 final ist! Das wird noch richtig abgehen, wenn Grails ausgewachsen ist.

Graeme erzählt von der Historie des Plugin-Systems. Es gab mal eine Zeit, da hatte es ziemlich eklige Stellen in Grails, die dummerweise sehr wichtig waren, wie z.B. das Buildsystem, ein Ant-File mit über 1000 Zeilen. Das war dann irgendwann sehr anfällig für Störungen bei Änderungen und auch schwer zu warten. Was tun? Aufdröseln, auch genannt Modularisierung. So sind dann die Plugins entstanden.

Die Archtiktur von Grails wird umrissen (Plugins, GrailsApplication, ApplicationContext). Ziele der Plugins: DRY und Simplicity. Ein Plugin ist erstmal ein Grails-Project, welches zusätzlich noch einen Descriptor hat, *GrailsPlugin.groovy (das Sternchen steht dann für den Namen des Plugins), welches per grails create-plugin erzeugt werden kann. Mit einem Plugin kann man Methoden, Konstruktoren, etc. dynamisch hinzufügen zu jeder beliebigen Klasse (MOP), Spring-Konfigurationskram, web.xml modifizieren, neue Tag-Libs, Controllertypen, etc. hinzufügen, usw.

Mister Grails erstellt jetzt ein Plugin und zeigt, was man da so alles machen kann. Ich glaub ihm jetzt mal, dass man da sehr viel einstellen kann :-) Man kann ein Plugin laufen lassen wie jedes normale Grails-Projekt auch. Graeme wechselt zu den Folien und zeigt, wie man einem Logging-Plugin relativ einfach beibringen kann (per Meta-Object Programming; schon genial, wie die neue Metaklasse arbeitet - Graeme hat's erfunden!), in jeder Klasse ein log-Attribut zu haben, ohne jedesmal Logger.getLogger(NameOfClass.class) tippen zu müssen.

Das GrailsApplication-Object ist mächtig: man kann überall application.get*Classes() aufrufen, um mit application.getControllerClasses() alle Controllerklassen zu bekommen. Ähnlich einfach kann man eigene Klassen Grails in einem Plugin beibringen.

Artefakte sind Dinge, die eine Konvention erfüllen in Grails, etwa Controllers oder Services o.ä. Artefakte sind alle vom Typ GrailsClass, und haben damit viele nützliche Methoden und Attribute, die bei der Pluginentwicklung helfen.

Plugins zu verteilen ist trivial: grails package-plugin. Dann bekommt man ein zip-File, welches per grails install-plugin path/to/zip in einem anderen Grails-Projekt eingebaut werden kann. Statt dem Pfad kann man auch eine URL angeben: so einfach kann Verteilung übers Netz gehen!

Graeme zeigt kurz, wie man eine TagLib erstellt und per Plugin verteilt. Und jetzt geht Graeme ab: ich komme nicht mehr mit beim Schreiben, so viele Beispiele feuert er gerade ab, ziemlich advanced und alles mit seinen ExpandoMetaClasses. Sieht sehr gut aus!

Jetzt kommen die Reload Events. Danach geht's weiter mit der Kommandozeile, also alles nach dem grails-Kommando. Dafür stellt er nochmal kurz Gant vor. Jedes Kommanodzeilenskript in Grails ist ein Gant-Skript. Ein Skript ist einfach angelegt und kann danach sofort ausgeführt werden. Gewohnt straight forward.

Wie bereits geschrieben, es gibt bereits ein paar Plugins, auf die Graeme jetzt ein wenig eingeht: XFire, Searchable, Remoting, GWT, Acegi/Security, JMS, Wicket/JSF/Tapestry, Dbmigrate, Static Resources, Jasper Reports. Für 1.0 RC 1 sind auch einige Plugins aus dem Core entfernt worden und eigentständige Plugins: Canoo WebTest und Dojo z.B.

"Puh, geschafft", möchte ich fast sagen. Aber nein, es war super, allerdings ist Graeme ein sehr fokussierter Sprecher und geht ab wie ein Maschinengewehr, sowohl was Infos als auch Sprache angeht - schwer für einen Nicht-Native-Speaker. Ich bin begeistert, was Pluginsystem zu leisten vermag und erschüttert, in was ich mich noch einarbeiten muss fürs Buch. Obwohl, über dieses Pluginsystem kann bestimmt noch ein eigenes Buch schreiben.

[Grails eXchange] Session A Groovy Build System with Gant (Russel Winder)

Russel Winder zeichnet verantwortlich für Gant, das Pendant zu Ant und/oder Maven in Groovy. Grails macht reichlich Gebrauch von Gant: Alle Skripte wie etwa create-domain-class sind in Gant geschrieben.

Russel vergleicht Gant mit Rant/Rake, Ant, Maven, Scont und anderen Build-Sprachen. Seine Meinung ist, dass Gant, Rant (Ruby) und Scont (Python) werden die Gewinner sein in der Evolution der Build-Sprachen. Beispielsweise sind Sie internal DSLs, während Ant und Maven lediglich external sind, was Gant/Rant/Scont entsprechende Vorteile gibt.

Probleme mit Ant: Russel präsentiert eine Folie, auf der "Low level", Too declarative" und "No programmable target generation steht", und diese Punkte sind verteilt unter sechs Punkten, die da "XML" heißen. Man gewinnt den Eindruck, Russel mag kein XML. Laut Russel ist XML gut, um Daten zu repräsentieren, aber Ant und Maven repräsentieren eben nicht nur Daten, sondern eine komplette Build-Spezifikation. Allerdings wird Maven gelobt für seine Projektstruktur, welche als Standard daherkommt für alle Mavenprojekte.

Gant wird vorgestellt an einem Beispiel. Es geht um eine Javaprogramm: Hello World. Es ist wirklich nur eine Klasse mit einer Main-Methode, die den bekannten String ausgibt. Jetzt zeigt Russel die Build-Spezifikation in Ant auf einer Folie, allerdings schon arg gequetscht, so viele Klammern sind da drin. Es sind nur drei Targets: compile, test und clean. Dann komen vier Seiten Maven: Wahnsinn, was Maven so alles haben möchte (unter anderem jede Menge Zeugs über denjenigen, der für das Build-Skript verantwortlich ist, einschließlich der E-Mail-Adresse! "Just to blame somebody if the stuff not builds!"). Es scheint da wenig Default-Einstellungen zu geben; vieles muss explizit gemacht werden. So muss der Compilelevel (1.6) angegeben werden. Nee, sieht nicht gut aus, Michael ;-) Dann kommt Gant: auch eine Seite, allerdings ist die Schrift doppelt so groß wie bei Ant.

Das nächste Beispiel ist ziemlich cool: Das Gant-Skript stellt auf eindrucksvolle Weise dynamisch (!) Targets her. Alle LaTeX-Files aus einem bestimmten Verzeichnis können nach PDF übersetzt werden, da jeweils ein Target für ein File bereit gestellt werden. Das kann man nicht mit Ant schaffen. Auch nett: durch GStrings kann man einfach aussagekräftige Beschreibungen von Targets erstellen. Schonmal versucht, in einer Ant-Description eines Targets eine Variable auszuwerten, damit's sprechender wird? Viel Spaß damit...

He, Stefan, das will ich mir mal genauer anschauen für unser Buch. Ich wußte bislang nicht, dass Gant auch mit LaTeX kann, sogar ein eigenes Package dafür besitzt. Will Russel mal nach der Session drauf ansprechen.

Russel operiert da vorne gerade auf einem Uralt-PC mit Linux, weil sein Nagelneu-PC nicht mit dem Uralt-Beamer hier im Raum spricht. Es ist alles improvisiert, aber Russel macht eine gute Figur: Emacs-Hacker, wie er im Buche steht :-)

Zuletzt geht Russel auf die Einsatzmöglichkeiten von Gant ein: Ant zu ersetzen, dafür ist Gant gemacht worden, und Ant mit Gant zu ersetzen sei ein No-Brainer. Maven mit Gant zu ersetzen ist schon etwas schwieriger, aber möglich. Er geht da gerade näher drauf ein, aber ich verstehe nichts von Maven und damit auch nicht, wie das mit Gant gehen soll. Was ich mitbekomme habe ist, dass Gant eigene Maven-Targets mitbringt und so die Migration relativ einfach sein soll.

Netter Vortrag. Brachte mich auf Ideen. Gant, auf jeden Fall einen tiefergehenden Blick wert, auch für Java-Projekte!

[Grails eXchange] Session Agile Web Development with Grails (Venkat Subramaniam)

Etwa 25 Leute wollen Grails in agiler Aktion erleben. Was Venkat dann im Prinzip macht: Er erklärt Grails von Anfang an, immer wieder deutlich machend, wie agil Grails aufgebaut ist. Er macht das alles ohne Folien (die obligatorischen Startfolien mal ausgenommen), sondern live an seinem Mac.

Sein Beispiel umfasst bislang eine Domain-Klasse State, die einen zweistelligen Code aufnehmen soll (TX z.B. für Texas). Er schreibt zwei Integrationstests (Code soll zweistellig sein, Code soll nicht leer sein). Er schreibt die Tests in der Form

def state = new State(code:'Texas')
assertFalse state.validate()

Find ich nicht so gut: Man sollte nicht mit Negativ-Tests starten, sondern mit Positiv-Tests, also soetwas wie

def state = new State(code:'TX')
assertTrue state.validate()

Außerdem ist die Zusicherung, dass der Code nicht leer sein soll, schon enthalten in der Zusicherung, dass er zwei Zeichen lang sein soll, und damit redundant. Naja, will jetzt nicht kleinlich werden... :-)

Die Session richtet sich eindeutig an nicht agil Vorbelastete, denn Venkat erklärt alles sehr ausführlich und von Grund auf (Simplicity, Refactoring, Feedback, Unittest, Integrationstests, ...). Nichts Neues hier. Aber natürlich ist es schon beeindruckend, wie gut Grails für die agile Entwicklung genutzt werden kann.

Nach den Unittests scaffolded Venkat die Controller und Views für State und erstellt einen WebTest, auf den er kurz eingeht, indem er ihn ein wenig verändert.

Hm, bislang bin ich etwas enttäuscht über den Inhalt dieser Veranstaltung, werden doch hauptsächlich die Features von Grails erklärt und dann die Relation zur Agilität dargestellt. Ich hatte eigentlich erwartet, dass mehr auf den agilen Prozess beim Umgang mit Grails eingegangen wird. Naja, vielleicht kommt das ja später noch in der Session TDD mit Groovy und Grailsy.

Venkat zeigt, mit wie wenig Änderungen am Code Dinge in Grails erledigt werden können, für die man zig Zeilen Java und XML benötigt in herkömmlichen Webframeworks. Klar das dies sehr agil ist: Embrace Change!

Venkat geht viel auf DRY ein, und zeigt z.B. mit dem Templatesystem von Grails eindrucksvoll, wie man so ziemlich jede Redundanz in den Views eliminieren kann. Wer schon einmal mit Includes in JSP gearbeitet hat, wird weinen vor Freude, wenn er sieht, wie einfach und flexibel das mit Grails realisiert wird.

Venkat will zum Schluss noch ein wenig zu Ajax sagen. Hierzu führt er ein Grails-externes Tool vor, dass bestimmt schon viele von Euch kennen werden: FireBug. Ich benutze das selbst sehr gerne bei der Entwicklung von CSS und JavaScript und kann das nur wärmstens empfehlen. Venkat zeigt, wie man mit FireBug z.B. den Request und den Response untersuchen kann.

Venkat demonstriert, wie einfach man ein Formular ajaxifizieren kann und einen asynchronen Aufruf (remote) absetzt, der bei seiner Rückkehr mit der Antwort einen Bereich auf der Webseite updatet. Das Updaten macht er noch pulsierend, und den Effekt entwickelt er in der JavaScript Shell. Dieses Tool kannte ich noch nicht, sieht aber recht spannend aus. Mal ausprobieren.

So, das war's. Wie ich bereits vermutet hatte, soll auf den Prozess mehr in der TDD-Session eingegangen werden. Naja, für diejenigen, die Agile Development nicht kannten, war's bestimmt gut. Venkat ist ein guter Speaker und mir sehr symphatisch. Man merkt, dass er in seiner Sache aufgeht.

[Grails eXchange] Keynote Graeme Rocher

Graeme ist der Project Lead des Grails-Projektes und löst gerade Guillaume ab, der bis gerade seine Keynote gehalten hat.

Graeme erzählt wie er zu Grails kam: In den späten 1990ern entwickelte er für eine Firma Webanwendungen, die auf EJB basierten. Das System, an dem er arbeitete, umfasste etwa 1 Mio. LOC, Java und XML. Er schätzt, dass das gleiche System heutzutage mit Grails etwa 50.000 bis 100.000 LOC hätte - Groovy, kein XML :-)

Seine Kernaussage ist, dass es einfach zu schwierig ist, wenn man in Java professionell Webanwendungen entwickeln möchte: Struts plus Spring pus Hibernate plus Sitemesh, und man ist bei einem halben Dutzend Config-Files. Man weiss gar nicht mehr, wo man anfangen soll! Grails sollte genau diesen Missstand beheben - laut Graeme hat es das natürlich.

Grails 1.0 RC 1 ist für diese Konferenz released worden. Mitte November soll es RC 2 geben, Ende November dann die final. Grails wird immer populärer: Mailinglisten- und Blogtraffic, Downloadrate, das alles steigert sich von Monat zu Monat.

Auch Graeme stellt G2One vor, nicht ohne darauf hinzuweisen, dass G2 nicht für Guillaume und Graeme steht, sondern für Groovy und Grails.

Graeme erzählt darüber, wie wichtig ihm Instant feedback und Test driven development ist: Agility eben, und dafür gibt's auch vier Sessions auf der Grails eXchange. Weiter geht's mit Dynamic in Groovy und wie toll das alles ist. Zwei Sessions, von Groovy und Guillaume, werden hierzu angeboten (macht IMHO auch deutlich, wie advanced diese Technik ist, dass sich hier nicht mehr Speaker etabliert haben). Graeme tangiert kurz Plugins. Grails ist manigfaltig erweiterbar mit dieser Technik und drei Sessions sollen erklären, wie's geht. Ajax ist einfach mit Grails, sind doch Dojo, YUI und Prototype nicht mehr wegzudenken aus diesem Webframework. Drei Sessions für Ajax. GORM ist eines der Aushängeschilder von Grails (drei Sessions dafür).

Grails 1.0 RC 1 bringt eine Menge neue Sachen mit sich, die Graeme nun kurz vorstellt: die neue GROM-DSL, die es stark vereinfacht, Legacy Databases an Grails anzukoppeln; Filter mit einer eigenen DSL; Verbesserungen an den Tag-Libs, wie z.B. Namespaces; verbesserte URL-Mappings (natürlich per DSL).

Bestandsaufnahme und Schulterklopfen Teil II geht seinem Ende entgegen und das Publikum ist eager to know more about it now. Nichts Neues für mich soweit.

[Grails eXchange] Keynote Guillaume Laforge

Es sind etwa 150 Leute hier im Kino des Barbican-Centers in London und hören zu, wie Guillaume, Project Lead des Groovy-Projektes, eine Zeitleiste zeigt, die die Entwicklung von Groovy darstellt ("Wie alles begann"). Er erzählt, wie er die Leitung übernommen hat im Groovy-Projekt, als das Projekt 2004 fast tot war. Stimmt, erst Anfang 2007 ist Groovy in der Version 1.0 herausgekommen - Groovy ist noch so jung! Weiter geht's mit der Auflistung der einzelnen Entwicklerkonferenzen (DevCon#1 bis #4).

Die Zeitleiste endet mit dieser Konferenz - und mit der Gründung der ersten Firma, die sich alleine um die Belange von Grooy und Grails kümmern wird: G2One. Graeme Rocher, Project Lead des Grails-Projektes. und Guillaume sind die Gründer. Guillaume hat das Logo gemacht. Die Firma berät, trainiert und schult an Groovy und Grails interessierte und entwickelt die Sprache, das Framework und spezielle Erweiterungen für Drittfirmen. Mal schauen, wie sich das entwickelt. Interessant: die arbeiten alle von zu Hause aus.

Werbung für Groovy: zig Sessions auf zig Konferenzen, zig Downloads, zig Mailinglisttraffic etc. pp. Es gibt bereits dutzende von Büchern zu Groovy, und das populärste, GinA von Dierk König, ist bereits ins Deutsche übersetzt worden. Groovy gewann den JAX-Innovation-Award. Groovy wird in zig Firmen eingesetzt, prominentes Beispiel: 50 KiloLOC bei Mutual of Omaha (US Fortune 500), ein Versicherer, bei dem Groovy zur Risikoberechnung eingesetzt wird.

Man kann hier auch gerade Buzzwordbingo spielen: DSLs, Java, Groovy, Grails, Big Player, Scripting, ...

Es werden Firmen vorgestellt (Big Player), die Groovy nutzen: Oracle, IBM, Sun, JBoss, JetBrains. Weiter geht's mit dem Einsatz von Groovy im Enterprisebereich: Groovy verträgt sich gut mit Java, läßt sich einfach in Javaanwendungen integrieren.

Neuigkeiten in Groovy 1.1 werden vorgestellt: Annotations, Generics, Enums, Verbesserungen bei der Metaprogrammierung, Performancesteigerungen - und die alte for-Schleife :-) Groovy ist übrigens momentan die einzige dynamische Programmiersprache, die Java 5-Features unterstützt.

Hihi: Guillaume zeigt kurz das Eclipse-Plugin für Groovy ("Nice.") - und dann JetGroovy, das Plugin für IntelliJIDEA ("Great!!"). Was für ein Unterschied, wenn man nur jeweils einen Screenshot sieht!

Es war eine Bestandsaufnahme und ein verdientes Schulterklopfen.

[Grails eXchange] Live-Blog: Init

Ich sitze gerade vor Gate 1 am Flughafen Karlsruhe/Baden-Baden, fertig zum Takeoff nach London zur First International Grails eXchange 2007. Auf diese Konferenz habe ich mich schon das ganze Jahr über gefreut, seit ich damals davon erfahren habe. Dieser Post kennzeichnet den Beginn einer Reihe von Blogeinträgen, die ich in den nächsten Tagen schreiben werde, als Live-Blog.

Im Frühling war ich auf der QCon, auch in London, und ich habe damals schon live gebloggt, allerdings im internen Blog meines Arbeitgebers it-agile. Einerseits habe ich dafür sehr gutes Feedback von meinen Kollegen bekommen, andererseits hat mich ein Freund sogar noch während der QCon gebeten, dass ich ihm meine Einträge zukommen lasse - er konnte ja nicht in unseren abgeschotteten firmeninternen Blog schauen. Fazit: Diesmal schreibe ich gleich offen und dann können Alle etwas davon haben.

Seit fast zwei Jahren beschäftige ich mich schon mit Groovy und seit mehr als einem Jahr mit Grails. Ich sauge seither alles in mich hinein, was mit diesen Technologien zu tun hat. Daher freue ich mich sehr auf diese Konferenz, die sich auf eben diese Themengebiete spezialisiert hat. Es gibt auch wirklich kaum eine Session da, die mich nicht interessiert. Bin sehr gespannt, ob meine hohen Erwartungen erfüllt werden!

Mit dem Internet auf solchen Konferenzen ist das immer so eine Sache: Mal ist man drin, mal fliegt man gleich wieder raus. Der Akku meines Notebooks wird auch nicht den ganzen Tag durchhalten; Steckdosen sind meist belagert oder zumindest heiß umkämpft (und ich habe schon wieder vergessen, einen kleinen Steckdosenverteiler zu besorgen). Was ich schreiben will: Es wird so live geblogt, wie es die Umstände eben zulassen. Abends im Hotel hole ich auf jeden Fall nach, was ich am Tage nicht schaffe.

Für die Filterwütigen unter den RSS-Feed-Schlürfer: Ich tagge diese Einträge nicht mit einem nur für diese Konferenz relevanten Tag, sondern benutze das Präfix [Grails eXchange] im Titel.

Okay, auf geht's nach London: das Boarding hat gerade angefangen :-)