Posts Tagged ‘Grails’

GInstruments – a new Grails plugin… soon!

Saturday, May 23rd, 2009

As a developer I’m very often on the hunt for every last bit of performance – trying to optimize every single function of my program.

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 draf of GInstruments 0.1

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.

Grails – ImageTools-Plugin

Friday, May 8th, 2009

There have already been some posts about the Grails Framework on my blog, so here’s one about the ImageTools plugin. This plugin leverages some functionality of the Java Advanced Imaging API (JAI) to make handling images a lot easier for Grails developers. However, some people seem to be complaining about poor image quality – I guess they’re about the poor resizing-results when using the thumbnail functionality.

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.

SpringSource übernimmt Hyperic

Tuesday, May 5th, 2009

nach G2One (die Firma hinter Groovy & Grails) hat SpringSource jetzt auch Hyperic übernommen.

Klingt interessant, schließlich ist SIGAR ein durchaus interessantes Projekt. Eigentlich wollte ich auch mal damit etwas schreiben – vielleicht eine Web-App die die Auslastung des Servers anzeigt – gibts sicherlich auch so schon… aber das Thema interessiert mich.

Bewertungsplattform

Monday, May 4th, 2009

Die letzten beiden Semester arbeitete ich mit meinen Kommilitonen Jan Laermann, Norman Schemel und Lino Strümann an einem Projekt im Rahmen der Vorlesung Projektmanagement. Unser Kunde war der Studiengangsleiter Herr Mester. Sein Ziel war es, eine generische Bewertungsplattform anzulegen. Es sollten mit minimalem Aufwand Bewertungsportale zu beliebigen Themen aufgestellt werden können.

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!

Enterprise-Vorlesung

Thursday, April 30th, 2009

In der Enterprise-Vorlesung lernten wir dieses Semester verschiedene Technologien kennen, die für die Entwicklung und den Einsatz von Unternehmens-Anwendungen wichtig sind.

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)