First up: Simple often-used utility functions:

static boolean Boolean.parseBoolean(String s) missing

The lack of this method is really annoying once you have to cope with reading in configuration values. Many of them will be in boolean-like format but you will have no method to parse them into booleans.

A very simple re-write of this method could look like that:

public static boolean parseBoolean(String s) {
return s.equalsIgnoreCase(“true”) || s.equalsIgnoreCase(“yes”);
}

Since it could be so easy to write this function (and Integer.parseInt() still exists which seems more complex to me) I don’t understand why it has not been included.

String[] String.split() missing

Every now and then one will have to parse some input – and this is where split() comes in handy. Would have come. Luckily String.indexOf() exists which allows for the following re-implementation of String.split():

public static String[] split(String source, String separator) {
Vector nodes = new Vector();

int index = source.indexOf(separator);
while(index >= 0) {
nodes.addElement(source.substring(0, index));
source = source.substring(index + separator.length());
index = source.indexOf(separator);
}
nodes.addElement(source);

String[] result = new String[nodes.size()];
if(nodes.size() > 0) {
for(int i = 0; i < nodes.size(); i++) {
result[i] = (String)nodes.elementAt(i);
}
}

return result;
}

All in all this might not sound too bad since both “re-implementations” were pretty easy to write. But: Since Boolean and String are declared abstract you can’t subclass and by that extend those. So you will have to declare a “tool”-class for them – not the most elegant way in my opinion.

So these are methods I think many developers will use very regularly but J2ME/MIDP doesn’t provide them.

I’m still a software developer. But the kind of software I’m developing has changed and so have my experiences and learnings. Of course they did not change completely – but they changed focus. For the last year I’ve mostly been developing server side applications combined with HTML/CSS/JavaScript. Although I would not see them as very large they were certainly more complex and more demanding on hardware than what I’m developing now. That thing which I’m entirely new to is development for mobile. This basically means developing for devices like the iPhone, Blackberry or Android. For me, this is a great opportunity. It’s helping me a lot to fine-tune my programming skills. Here are some examples of things I had already expected and some things I just experienced:

• memory and processing power is so limited compared to desktop or even server environments (iPhone 3G: ~400MHz, 128MB of RAM, no swap! – Desktop: multi-core 1-2GHz, GB’s of RAM)
• (only for the iPhone) memory management can be a tricky if you’ve always been developing in a garbage collected environment like the Java platform
• SDKs like the iPhone SDK or Android SDK rely heavily on software design patterns. A developer using those SDks is at a loss if he’s does not only understand those but is also able to extend and re-use them

There are many things that come with this change for developers. First: one must be very careful with creating objects. Very careful! Even if you’re on platforms like Android or Blackberry which feature Java and by thus automatic Garbage Collection! Every object counts.

Those limitations and the way you deal with them really help developers get more experienced. By that it’s a great deal for both the company and me.

I’m looking forward to what comes next – and rest assured I will keep you updated about any further developments.

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.

My first performance tests show that this boosts overall performance when checking large amounts of CSS selectors on multiple HTML documents. The next big step will be trunk-integration of this feature.

In the meantime check the dev-branch at http://code.google.com/p/jacqueline/source/browse/#svn/branches/threaded

Of course I’ll post my experiences here…

Jacqueline is a library which will help you to find unused CSS Selectors in multiple HTML documents. This is a very important feature when you want to check a complete website: it will be almost certain that you have some CSS selectors used on page “A” but not on page “B” whereas “B” uses some CSS selectors which “A” doesn’t use.

Jacqueline is completely written in Java – this was necessary because we wanted to run it in our Java based infrastructure. This brings some other problems Jacqueline has to face: the DOM implementation in Java doesn’t feature the Selectors API. So I wrote a CSS-to-XPath engine – inspired by DOMAssistant. What this basically does is: it transforms CSS2.1 selectors into XPath queries which can then be used for node tests (since XPath support is included in the JDK) on the DOM tree of the HTML document.

Because our documents are still using HTML 4.0 (due to several problems when switching to XHTML 1.0) I had to use JTidy for building DOMs.

Jacqueline also uses Apache Batik to retrieve all the CSS rules and CSS selectors from a document – it was the only implementation of the SAC (Simple API for CSS) I got to run – and which had some special features. These include locator information of the found tokens for example.

At the moment Jacqueline only works single-threaded, but because this includes many cpu-intensive operations which could definitely be fastened by using the power of multiple cores I’m also dreaming of a multi-threaded version. Since most operations of Jacqueline could be executed in a parallel fashion this could bring a major speed-up.

The main thing of Jacqueline is that it’s one of the first pieces to the lately mentioned Project Mess Tool. We’ll be using the power of Jacqueline to detect unused CSS selectors in our web projects.

Finally, that stupid name: Jacqueline is named after Jacqueline Bouvier from my favorite TV show the Simpsons. See this poster in our office:

Jacqueline - Poster

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.

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)