Lars Rasmussen posted on the Google Wave Developer Blog that Wave will inform Internet Explorer users to install Chrome Frame for a better user experience. Reason being that Internet Explorer is just too slow at interpreting JavaScript and DOM Manipulations – features Wave heavily relies on. IE’s support of modern web standards such as HTML5 is pretty poor, too.

I’ve been experiencing the same issues with IE over and over for myself – yet in a smaller dimension: Every hour (and it have been many hours) a developer spends on the specific quirks on IE (which of course are different per each version) and to fix them for their application is not spent on adding cool new features or bug fixes which affect general issues.

Since this has been a problem for so a long time I hope this finally helps to fix this issue.

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

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

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.

So what’s this about? In a few words: The PMT is a tool which will allow us to keep track of many quality-relevant metrics our company-website “produces” every day.

Problem

The sites we use for selling products are changed very often due to marketing campaigns. Not only do we have to change some images for that instead these are huge changes to the affected frontends. This of course results in the fact that many parts of our codebase are from older versions which may not be needed anymore.

At the moment we’re in the uncomfortable situation that we often don’t know how our pages really perform e.g. how many of the resources we deliver or keep are really necessary. We don’t know how many kilobytes (or even megabytes?) the average page weighs nor do we know where we could optimize easily.

Possible solution: the PMT

The PMT is designed as flexible as we think it can be. All it basically does is receive data from all different kinds of sources by offering a defined interface (a webservice). This will include information from

• the Jasmin servlet as mentioned by my colleague Nico Steiner (both in German)
• our Pustefix framework which renders the sites
• some other emerging projects we will use to make our websites even faster

In the end we will have information not only like “how many of the CSS selectors we deliver are really used by our pages?” but also “how does this change over time”. So we will be able to track quality with our predefined metrics and check back every week or so whether we have improved in those fields.

Architecture

I chose Grails to build this application – which I’m already pretty familiar with – but we’re also using some core Java libraries to add some features specific to the frameworks and technologies we use. Grails seemed like an ideal candidate for me because it already ships with the really powerful GORM abstraction layer. There are also plugins for other enterprise applications like the Quartz enterprise job scheduler. Grails makes it very easy to run all this stuff so I got done with the first steps pretty soon.

Frontend

At the moment I’m also drawing the first drafts of how the user interface of the PMT will look like. It will probably use Flot which I also mentioned several times.

Conclusion

For me this is a really great project. Not only in its size – it’s definitely the biggest project I’ve been working on until today. But its also a project in which I spend all my effort and time of work this time. I think it will help a lot to improve the overall technical quality of our web frontends.

I’ll keep you updated with all major changes and milestones to the PMT. So what do you think of our idea?