Marc Palmer

At JavaOne there was a session that is now online comparing Rails, Grails and J2EE. They say some good stuff about all three, but one can’t help but feel – unsurprisingly perhaps – that J2EE comes out smelling of roses rather unfairly.

I hope that the presenters, Damien Cooke and Tom Daly of Sun Microsystems, Inc. can get in touch with the Grails team to confirm how they ran these tests that supposedly show Grails using a huge amount of CPU compared to Rails and J2EE.

After all, we have run benchmarks that seem to be fair against Rails, and Grails throughput is much better in almost all cases. So at a basic level this cannot support the high Grails CPU usage vs Rails.

This makes me think they ran grails with "grails run-app" which runs grails in Jetty with loads of extra code to support dynamic reloading and compilation in development mode. If they did this, they should have executed "grails war" (which they know about, says it elsewhere) and run it in Tomcat/Glassfish to compare with J2EE.

There are so many typos in the document you can’t help but wonder about the quality of work involved. They call Groovy a "JavaScript" programming language. They show Grails with source code examples inline making things look complicated, and then show 4 simple bullet points for creating a CRUD J2EE application (in what universe is this?).

They say that one of the "problems" with Grails is that its made up of lots of other bits of tech – Hibernate, Spring, SiteMesh etc. Of course they would say this, but they are in denial that these are actually the best of breed APIs out there as opposed to the awful EJB, JSP, JSF gumph. They also say you have to configure all this stuff. Hmm, I think they haven’t tried convention over configuration at all.

Then there are things like "Not clear how to regenerate if you have made changes to the controller/views". There’s nothing to do! Reload!

Pah, oh well. Damien and Tom, if you want to get in touch and give us precise details of how you did your Grails testing we’d like to help check it was a fair comparison

Ziltoid the Omniscient is the latest musical creation of Devin Townsend and sits somewhere between his previous solo efforts and Strapping Young Lad.

It is seriously rocking B-movie prog metal that once again showcases Devin’s distinctive sound and production. The guy is a genius and knows exactly how to press all the right "metal" buttons.

All the drums on the album are apparently programmed using some sample setup from Meshuggah. The drum patterns are insane in places, I shudder to think about the hours that must have been spent slaving over "grid edit" in his sequencer.

I was sad to read that he no longer plans to tour or record with Strapping Young Lad or the Devin Townsend Band… but family life always seemed to me rather incompatible with ROCK (that’s rock in captials man).

The highlight track for me is "Ziltoidia Attaxx!" which has to be the most bouncy and pounding not-taking-itself-seriously metal track ever. Other tracks are on the Ziltoid myspace.

Also for a few minutes of fun you can check out the Ziltoid transmissions on YouTube.

Most stupid rock lyric from a puppet in a metal song ever? "Aha! Surprise!"

It always frustrates me when I find bugs. Not because the bug is there, but because I am sure that in many cases I am not the first person to have hit the problem. All too many people I know hit a problem, and then just work around it and that’s that.

It’s so incredibly vital, especially with volunteer open source projects, to report and document as well as possible any issues that you find.

To expect the developers of all the great open source software out there to not only create new features and fix bugs found but also to find all the bugs is wanting to have your cake and eat it!

So it is for this reason, that I as a self-confessed Jira fanboy, always always always create a jira issue for every problem I hit. Sometimes even before I can find any sign of a root cause. A forgotten bug report is lost time for everyone – for you as a user, who may hit it again and find it is still not fixed, but also for us as developers as we want to get rid of as many bugs as possible in every release.

So please if you hit a Grails bug, JIRA our asses! If you don’t have a JIRA account already, create one, it only takes a few seconds.

Bug reports are like code coverage reports. They show gaps in our unit testing and improve the quality of the product as a whole. You can never have too many bug reports – but quality is important too!

The WWDC revelation that custom applications will be standard web applications is possibly, in the long term, a masterstroke. It is not without its problems though, but could have far reaching effects on the mobile software industry.

The demo at WWDC revealed/implied:

• Your applications run within Safari, in fact it is launched as a bookmark (not from an icon in the main UI) as can be seen at 01:17:49 into the keynote
• You can access on-phone services like make a call, address book, send email, maps etc. This must be either via custom JS objects (as per Dashboard widgets) or an httpd on localhost supporting ajax requests.
• You can make the applications look the same as the native applications.
• You can build applications today and to paraphrase "be ready to launch after final testing on June 29"

However these revelations beg more questions than they answer.

First off, no J2ME or Java. This could be a major earthquake in the mobile content industry, especially for games. If iPhone sees huge take up eventually and has market share in mobile similar to iPod does for mp3 players. Web apps on a standardised mobile platform (i.e. few target device types) would have seriously lower development costs than the perpetual hell that is J2ME development and porting.

However, it is not clear how this will generate revenue for network operators or content providers. Its also not clear whether or not you can even run applications (such as games) offline. The two are linked, as if you are to run a local cached version and some form of online billing is involved, things will get complicated. You could still resort to network operator portal browsing, pay by clicking a link, and it sends you a unique code by SMS that you must enter to unlock the web application I suppose.

It gets more problematic though. What about local data storage? J2ME has a concrete (but very ugly) model for this. If there is no such API or no way to access the data on the phone directly (without invoking native app UIs) then offline apps are going to be a no-no. Integration with data sync would be crucial for many apps. The J2ME RMS API while ugly and backward-looking, was copied in part from Palm OS which we all know licked the data sync problem long before anyone else. Data sync of custom application data is fundamental, even in a wireless world.

Take OmniFocus for example. I’m lucky enough to be beta testing this GTD application and having it running on your iPhone would be perfect – sync data from main mac to it etc. However this is not likely to be possible with the iPhone, at least initially. The implication from the WWDC demo is that you would require an online OmniFocus webservice that had access to all your data. Bad news. Maybe the .Mac "back to my mac" stuff will come into play here in future such that iphone webapps could access this data using an API, and have the iphone sync, but all this still requires network access.

Everyone likes wireless networking, but many people resent paying for mobile data services. A lot of people want to be able to use apps offline or where there is no reception.

Another concern I have is the purported ability to make web apps have the same look and feel as native apps. From what I could tell, they did this just by meticulously copying the style of the iPhone ui within their webapp. There was no statement that makes me believe there is an API for accessing common styles/graphics. After all they said there is "no SDK". This is a tragic error. It means apps will look out of place on future revisions of iPhone UI, and there is a lot of work to make the UI look like it fits in – you’re basically having to make websites that look just like iPhone apps.

While we’re on the lack of SDK – how does this gel with the "develop today and launch June 29"? Maybe for purely web-based services yes, but without an iPhone to copy the look and feel of the apps, or an SDK/documentation to explain how to invoke phone features like maps, you’re going to have a very busy Jun 28 while you try to reverse engineer iPhone apps.

You get the feeling that this is a last-minute solution hacked together. After all what did they really demo? A webservice that is entirely off-device, that just looks a bit like a local app and launches as a bookmark. i.e. they demo’d nothing at all relating to custom apps, surely? Isn’t this a classic case of smoke and mirrors?

On iPhone a custom application really needs to:

1. Have sandboxed access to user data on the device
2. Access to phone features via published APIs
3. Integrate trivially with standard phone UI
4. Sync data with main computer
5. Be a first-class application with an icon that you can launch – it needs visibility

I don’t think I saw any of those. Oh dear.

Addendum:

I forgot to mention the problems making any kind of smooth game using JS and HTML. This therefore puts iPhone into a mobile game cul-de-sac like some of the early J2ME handsets that performed so badly they were a write-off.

Of course the iPhone "is an iPod" we are told so they are possibly planning on having native "iPod games" run on the device, although how they achieve this will be interesting. This implies syncing games from iTunes and therefore implies Apple getting all the money, and the operators relegated to making money from bandwidth charges only. This could kill off the existing J2ME games industry.

I’ve committed some minor enhancements to Grails scripts in 0.5.5 HEAD.

They lay the groundwork for some platform-specific extensions to Grails that may come along in future. Graeme, Jeff, Jason and I, among other Grails developers, are OS X users and some people will know I have previously written a script to show Growl notifications based on script events.

Well we weren’t happy with the requirement to install growlnotify shell script from the Growl DMG so I went down a little path of using the Growl Java API. This necessitated some tweaks to grails scripts.

So what’s new in SVN is:

• startGrails shell script on OS X adds /Library/Java/Home to the classpath before booting up the Gant script engine. This is required for Cocoa APIs to be available to Gant scripts
• Tweaks to the classpath target of the Init script, which now always adds <home>/.grails/lib jars to the classpath before running scripts. This was required to allow Events.groovy to import the growl API. This mechanism will be useful for other platform specific jars. If you don’t mind looking up classes by name you probably don’t need this because of…
• A new SetClasspath event is triggered when setting up the classpath for running grails code/scripts and the classpath is now setup even if you run a target that doesn’t depend on the "classpath" task. It turned out this was no good for me as of the previous point, I didn’t fancy class.forName
• Grails now ships with a $GRAILS_HOME/media/icons directory with our new snazzy icons in there, and an OS X format multi-resolution icon file
• New CompileStart/CompileEnd events (requested by a user) and PluginInstalled is now implemented in 0.5.5 – documentation for events is here

All this adds up to Growl notifications for Grails 0.5.5 being a case of downloading the latest Grails snapshot an then downloading this zip file and then unzipping the contents of that into your ~/.grails directory. Note that using the default unzip UI on OS X you will get the folder GrowlGrails and need to copy the files from there into ~/.grails/lib and ~/.grails/scripts manually. Either that or open a shell and do unzip GrowlGrails.zip

Now just do something with grails 0.5.5 and watch the pretty notifications. By default only status updates and final status are growled, but you can now go to Growl Preferences and configure the notifications on a per-event basis. I expect more changes to the list of available events in future. I’m looking to see if we can hook into Gant task execution to provide automatic task X start/end events as the current scheme requires us to add event generating calls to every target, which is likely to be boring and error prone.