Grails and Eclipse: Not So Groovy

In fact I struggled to get the Groovy-Eclipse-Plugin installed those days, and after finally having done that I found out that developing Grails applications in Eclipse was really painful for me.

But now with the first pre-M1 release of the next version of the Groovy-Eclipse plugin many things are better than ever. I finally got around using Grails and Eclipse for some of my projects at work but on the Mac at home I still prefer the combination of TextMate and Console.app. I’m looking forward to the final release which should improve UI performance in Eclipse, especially when using Code Assist.

Instruments now sports a core Java library which takes care of caching the states of system usage for the last time. This is included in an all new “InstrumentsService” which will provide the necessary methods to controllers.

At the moment this is all trimmed for using flot. There are no other “export options” for now.

I decided to make this publicly available in my Subversion repository. You can checkout the source tree of the Grails application here:

http://creatified.com/svn/creatified/Instruments/

The trunk includes the latest development version. Don’t forget the “grails upgrade”-command after checking out the source tree.

When you run the app, all you’ll find there for the moment is the following site which will be located unter http://localhost:8080/instruments/

You will then be able to see something like this:

for the CPU usage and this:

for the Memory usage

This will be all for now, be sure to check out your own version – I’ll also be testing this on the Google AppEngine soon.

But one aspect that’s often annoying me is the Eclipse integration. Like many other guys I’d like to use Eclipse because for me TextMate is no full-blown IDE. But the default integration into Eclipse is “incomplete” at best.

Here are some things I encountered with some possible solutions:

Unfortunately the generated Eclipse project files do not include a source link to the plugins directory of your project. Since Grails 1.1 this will be in your home-directory (at least on Unix-based systems) like ~/.grails/{GRAILS_VERSION}/projects/{PROJECT}/plugins, you will have to link this as a source folder when you’re using any plugins (which will often be the case)

The other thing is: if you’re including jars in the “lib” directory under your Grails project you will either add these jars manually to your build path or once again add this folder as a linked source folder.

I hope these issues will be addressed in a future release of Grails, hopefully as soon as 1.1.2 since these should not be too complicated to fix.

First things first: Fortunately Hyperic had placed an exception-statement into its GPL-licensed SIGAR – which allows to include the SIGAR binaries in – for example – Apache-licensed works. For me that’s really good news, because this means GInstruments could also be used in productive environments which I think often would not be GPL-compliant.

Second: One of the basic things I always wanted to have seems really close now. At the moment GInstruments only displays your current system usage – not too useful, because most times you’d be interested in the usage over time, say for the past 30 seconds or so. So that’s one of the core features I’ll be implementing before releasing anything to the public – sorry for the delay, I’m very busy in other projects right now, too.

For the next few weeks I’ll also be testing on various kinds of systems (Windows, Linux, …) and of course testing on Google AppEngine whether they support all the necessary features.

And for a great user experience I’ll also be working very hard on a prototype of the UI.

Some things that will probably make it into the first public release include:

• logging system usage and events to a set of CSV-files (configurable in later versions)
• usage graphs on the client-side using flot
• more? yeah, sure!

In the past weeks I’ve been thinking of, designing and developing on a new plugin for the growing framework Grails. It will be called GInstruments and it aims to provide some useful clues for Grails developers who want to know how their application is performing.

The plugin uses Hyperic’s (now SpringSource) SIGAR (System Information Gatherer And Reporter) to report vital system information such as CPU usage or memory comsumption overall or for the current process.

The first release (0.1) is only going to be a snapshot of my first ideas, hence I’ll not release it to the official Grails plugin repositories. It will show you some information about your system like name, version, vendor or architecture, the current CPU and memory consumption. Especially for your current process (which will be the relevant information to know). Take a look at this:

First draft of GInstruments 0.1

All these features are subject to change (I first wanted to know whether there could be a future for this). Possible features for the future may include

• logging of metrics (cpu, memory, swap, network, …)
• tracking of Grails events (requests, …)
• visualization of these two and more components over time to detect points of interest

I’m open to all kinds feature requests but please bear in mind that I’m only doing this in my spare time, after work, school whatsoever ;-)

At last let me point you to a link (for the non-Apple-developers) to how Apple’s Instruments-app looks like. I think it has some other cool possibilities.

At the moment I’m also waiting for some response from the guys from Hyperic. I really want to license the plugin under the terms of the Apache License (the license Grails uses and many other plugins) – SIGAR is GPL-only at the moment.

Do you think this could be a useful plugin for the Grails infrastructure? What’s your opinion.

The default method for creating thumbnails is the following

def imageTool = new ImageTool()

imageTool.load("/path/to/image.jpg")

imageTool.thumbnail(640)

This will load the file, create a new ImageTool instance and make a thumbnail out of it, where the max width/height will be 640px. However the resizing quality is very bad because by default it uses nearest neighbor for interpolation. You will encounter this especially when you’re rendering small thumbnails out of large images.

A possible solution

Because there is no detailed documentation about the ImageTools plugin (actually I didn’t find any) one will have to inspect the source code to find something very cool: ImageTools also provides a method called “thumbnailSpecial” which can use other interpolation and rendering algorithms and you can use it instead of the basic “thumbail()”. It’s signature is as follows

thumbnailSpecial(float maxWidth,
                 float maxHeight,
                 int interPolationType,
                 int renderingType)

maxWidth and maxWidth are pretty self-explaining, just set them to the same values (for example 640) to achieve the same dimensions as above.

interPolationType is one of

1: “bilinear interpolation” – which is at least better than nearest
2: “bicubic interpolation” – which is even better and
3: “bicubic2 interpolation” – which may even better

these are JAI names for them, don’t ask me about the details

renderingType is one of
1: “scale” – the default function JAI uses
2: “SubsampleAverage” – which will provide better results

Please keep in mind that all the “better results” require a lot more rendering time and are likely to consume more memory – but the results will be way smoother then.

So that may help some people out there which have experienced poor quality at this end.

For me there are only two further caveats when using ImageTools/JAI.

First: performance is very bad when using pure Java mode (which will be the default unless you provide a “native accelerator” for JAI). On my Mac this is no problem – as far as I know Apple provides a native accelerator in its own JDK on Mac OS X (and I never got messages like detailed on the plugin page) – yeah, using CoreGraphics/CoreImage, whatever… correct me if I’m wrong ;-) but I never got it to run on my production system (Ubuntu Server).

Second: JAI seems to have some other strange problems with JPEGs on Linux (I tried both OpenJDK and Sun’s JDK, always JAI in pure Java mode): some JPEGs will have inverted colors in the resulting thumbnail – couldn’t find out any details but I think something about the JPEG implementation is broken. This also affects saving JPEGs for me. It got strange exceptions when saving images as JPEGs causing that to fail – so I fell back to using PNGs – which is everything but cool in many cases :-(

As said these two problems only occurred on Linux (Ubuntu 9.04) – not on Mac OS X (couldn’t test on Windows) – but since most web apps I’m writing will be running on Linux some day this is a very annoying problem – and unfortunately I don’t see any progress on the ImageTools plugin or JAI. Anybody else got this kind of problem?

So I’m very tended to give something like good old ImageMagick a try – maybe using im4java or JMagick – or something else.

Projektplanung

Im ersten der beiden Semester kümmerten wir uns maßgeblich um die Projektplanung, dies ergab am Ende ein Pflichtenheft, das vom Kunden unterzeichnet wurde und uns im Folgenden als Basis für unsere Entwicklung diente.

Projektumsetzung

Im zweiten (diesem) Semester des Projekts ging es dann an die konkrete Implementierung der Software, sowie den geplanten Rollout. Wir hatten uns aus diversen Gründen dafür entschieden, für die Entwicklung das Grails-Framework zu benutzen.

Zur weiteren Entwicklungsumgebung gehörten bei uns folgende Komponenten:

• ein Subversion-Repository zur Versionierung und Zusammenarbeit
• Trac als Task-Tracking-Tool um die einzelnen Aufgaben und auch Bugs zu koordinieren
• anfangs ein MediaWiki welches dann durch das Wiki von Trac abgelöst wurde
• eine lokale Testumgebung (von Grails bereitgestellt) und zum Ende auch ein serverseitiger Test mit Tomcat und MySQL

Da wir aus vergangenen Projekten leider nicht sehr gute Erfahrungen mit Lösungen aus der BA-Infrastruktur gemacht hatten (dass das SVN-Repository z.B. nicht von außerhalb der BA erreichbar war, oder häufig nicht funktionierte) wählten wir meinen eigenen Server um die Tools dort zu hosten. Eine meiner Grundaufgaben war deshalb die Verwaltung dieser Entwicklungsumgebung, damit das Team verlässlich damit arbeiten konnte.

Außerdem arbeitete ich danach als Java/Groovy-Entwickler an den Backend-Funktionen mit Grails um die Logik zu implementieren.

Abgabe

Unserem Kunden war es gegen Ende des Projektes leider nicht mehr möglich die entsprechende Live-Umgebung zur Verfügung zu stellen. Deshalb konnten wir die Bewertungsplattform nicht aus unserer Test-Umgebung auf das Live-System übertragen.

Aus dem geplanten Roll-Out wurde so die Abgabe aller Entwicklungsressourcen, inkl. SVN-Repository, Trac-Backups etc. so dass z.B. ein anderer Jahrgang dieses Projekt dann inklusive einer (ursprünglich geplanten) Werbekampagne online stellen kann.

Erfahrungen

Dies war für mich ein weiteres großes Software-Projekt innerhalb unseres Studiengangs. Man sieht, dass mich meist mehr die Technik reizt, als gestalterische oder statistische Arbeiten. Da wir den Prozess der Erstellung durch das Trac ebenfalls sehr einheitlich ablaufen lassen konnten, lief in diesem Projekt wieder einiges besser planbar als in früheren Projekten (jedes Mal kommen ein paar weitere Tools und Erfahrungen hinzu bei denen man sich fragt wie man das bisher nur ohne sie geschafft hat).

Die Arbeit mit Grails war im weitesten Sinne sehr angenehm. Das Grundgerüst der Anwendung war innerhalb von ein paar Stunden erstellt und einsatzbereit. Ein paar Bereiche sind noch naja… meines Erachtens nicht unbedingt produktiv einsetzbar – z.B. Web Flows hatten bei mir auch in anderen Projekten bisher noch einige Stabilitätsprobleme. Und die Doku reicht auch von supermegatoll bis mittelprächtig. Fragen wie “wie bekomme ich den info-Loglevel für Controller oder Services?” ließen sich nur durch langwierige Recherche im Internet beantworten. Aber es gibt auch Bereiche wie die Konfiguration mittels der jeweiligen “DSLs” (z.B. für die DataSources) oder die Groovy-Builder, mit denen die Arbeit eine reine Freude sein kann, sofern die Doku sie entsprechend erläutert.

Wir hatten sehr viel Zeit zur eigenen Einteilung zur Verfügung, so konnten auch die einzelnen Entwickler ihren eigenen Rhythmus leben (meine Commits kamen z.B. meist in der Zeit von 8-20 Uhr, andere zwischen 14-2Uhr ;-) ). Das wurde auch durch die strikte Trennung von Grails ermöglicht, weshalb z.B. die einen weiterhin an den Layouts arbeiten konnte, während andere die Logik implementierten.

Ausblick

Ich werde mich mit Sicherheit weiterhin mit Grails beschäftigen. Für die schnelle Erstellung von Web-Anwendungen eignet es sich hervorragend. Integriert sich auf Wunsch auch gut in bestehende Umgebungen (eigenes Mapping für Persistenz z.B.) bietet viele sinnvolle Features – und noch mehr durch die immer weiter wachsende Zahl von Plugins.

Ein Task-Tracking-System wie Trac ist ebenfalls sehr sinnvoll, allerdings fand ich es während dieses Projekts teilweise etwas umständlich zu bedienen – und es lief (Python, Apache, Ubuntu, VPS, wer auch immer dafür verantwortlich ist…) leider lange Zeit nicht unbedingt flink.

Auf eine Versionsverwaltung kann ich selbst bei Ein-Mann-Projekten nicht mehr verzichten!

Neben einem schriftlichen Test erarbeiteten wir in verschiedenen Gruppen unseres Kurses einzelne Module an einem “Downloadportal”. Dazu sollten wir unter Anderem den JBoss Portal Server einsetzen.

Aufgabe/Gruppe

Ich war gemeinsam mit meinen Kommilitonen Claudia Fröhlich, Katrin Plaumann und Lino Strümann, in der Gruppe “Persistenz”. Unsere Aufgabe war es, mittels des ORM-Frameworks Hibernate dafür zu sorgen, dass jegliche Objekte aus dem Downloadportal transparent in einer relationalen Datenbank abgespeichert und aus dieser auch wieder ausgelesen werden konnten. Hibernate ist ein sog. objekt-relationaler-Mapper (kann also objektorientierte Strukturen in relationale Strukturen mappen) und hat sich auf diesem Gebiet als Quasi-Standard etabliert.

Dazu entwickelten wir eine Hilfsklasse, welche den anderen Gruppen nicht nur eine Hibernate-Session bereitstellte, sondern auch Methoden um verschiedene Objekte in die Datenbank schreiben zu können. Ergänzt wurde dies durch einige “Finder”-Methoden die z.B. einen Benutzer anhand seines Nicknames finden konnte. Diese Klasse wurde allen anderen Gruppen zur Verfügung gestellt.

zur Entwicklungs-Umgebung

• Da wir keine Testumgebung innerhalb des Portal Servers hatten, sicherten wir unsere Ergebnisse allein durch eine umfangreiche Test-Abdeckung durch JUnit ab
• zur Versionskontrolle nutzten wir ein Subversion-Repository dass ich auf meinem privaten Server eingerichtet habe

Erfahrungen

Ich hatte bisher schon Erfahrungen mit Hibernate gemacht – vor allem durch verschiedene Arbeiten mit Grails das ebenfalls Hibernate einbindet. Allerdings war die “Low-Level-Arbeit” mit Hibernate eine andere Anforderung, ganz im Vergleich zu dem “Luxus” den Grails dabei anbietet. Dennoch kam ich damit sehr gut zurecht und konnte meinen Kommilitonen die bisher noch nicht damit gearbeitet hatten eine kurze Einführung in das Thema geben.

Mögliche Verbesserungen

aus diversen Gründen kamen wir erst in den letzten Wochen des Semesters dazu diese Anwendung zu entwickeln. Unser Teil wurde dabei relativ flott in weniger als einer knappen Woche fertig. Dabei wurde natürlich einiges weggelassen, damit wir so schnell fertig wurden. Optimieren können hätten wir zum Beispiel durch

• mehr Finder-Methoden für die Objekte anzubieten (wäre in Groovy dank Meta-Methoden sehr einfach, wie z.B. bei Grails)
• log4j (miteingebunden) weiter nutzen um detaillierte Logs auszugeben
• Aufbau des gesamten Projekts z.B. mit Maven, um Abhängigkeiten von Libraries transparent auflösen zu können (hätte leider wiederum eine Einführung benötigt, da Ant, Maven oder auch JUnit den meisten noch unbekannt waren)