AnyWare

Today I released version 1.4 (we skipped 1.3) of the Grails feeds plugin for producing RSS and Atom feeds trivially from Grails applications.

This version fixes several annoying bugs that results in seemingly irrelevant error messages, and adds support for RSS enclosures, as well as iTunes music store specific podcast tags.

This version is in production serving up a podcast in the iTunes Music Store.

To install type: grails install-plugin grails-feeds

Documentation updated to include enclosures and iTunes tags is here

You’ve hopefully heard about the problems with the prices of rice and other grain staples. This is serious stuff, probably more important than oil price and oil scarcity. Nothing makes people as hungry for change as being physically hungry.

Check out this excellent article detailing the thankfully widening appreciation that meat consumption at the levels we see in the West is simply not sustainable, especially on a global scale. China is entering the global food import market and the relative affluence developing there and in other countries is going to make it impossible for meat consumption to continue as it is.

You simply cannot feed millions of tons of grain to animals in order to eat them and ignore the fact that this food goes a lot further when fed directly to humans. It is deeply ironic that China, with a diet typically very low in dairy and meat produce, may well be the deciding factor as to whether people in Western countries do or don’t have meat on their plate most days of the week in 5 years time.

One thing’s for sure - its going to become a lot more expensive, which is as it should be. The gap between non-organic and organic prices is likely to narrow as the bottom-of-the-barrel produced meat prices increase due to scarcity. This is probably a good thing in the long term, as people will have notchoice but to eat less but better reared meat and dairy products. It might even in time turn around the prospects of our respective nations’ health - but possibly not so for the Chinese.

Hmm oh dear.

I’m working on some trivial Javascript code for a new site to add a little dynamic behaviour, using the "trusty" Prototype JS library that we have loved before. Only, property/array access on Hash objects is not working any more. I waste a lot of time on this.

Then I find this blog post on the prototype website.

Yes that’s right, in version 1.6 they made a completely breaking change to the behaviour of Hash - array indexing is no longer possible, you must call Hash.get(key). This makes me rather worried as it seems the developers are not aware of the concept of minor revisions not changing the public interface of a library.

Bizarre. I can only wonder what other functionality will be broken in other pre-2.0 releases. This has shaken my confidence in Prototype I must say.

So this Monday we had to launch a new website with Grails 1.0.2 to a site with an existing Gails 0.5.6 application running inside a single Tomcat instance.

We had the box’s ram upgraded from 1GB to 2GB to cover the anticipated extra drain - the existing app had seemingly needed 1GB for itself.

So the RAM or the extra CPU load was making the box croak and was showing up a Linux kernel 2.6.9 bug related to unlock_kernel() calls and we were getting up times of circa 50 minutes before the thing locked and needed a reboot. Also possible the RAM was faulty and the hosting company swapped it out for us pronto.

Anyway… when it was working many pages would come back blank. Logs showed OutOfMemory errors and we played with Tomcat heap settings as the problems were native thread allocation. Then the alarm bell in my head rang and reminded me that Java gives this OOM error not just for memory exhaustion but also not being able to allocate a new native thread.

Our sys admin looked into it and found that ulimit was 100 processes, a leftover from when I hacked the box to be secure with Bastille. The limit was removed - after all we need hundreds of threads in the Java VM for any level of traffic with 2 apps running.

Bingo - server runs beautifully with both apps withing 1GB Java heap. It runs better than it ever did with the single app and the hosed ulimit. Duh.

It is not surprising that Sun is making such a fuss about trying to get Java onto the iPhone / iPod Touch platform. They must be thinking "Holy crap, if iPhone and iPod touch replicate the success of iPod’s 72% mp3 player market share (excludes mp3 player phones), Java will be dead in the water on mobile". Too damn right.

The mobile handset market is completely different to the mp3 player market, where figures typically exclude the market made up of mp3 playing phones, but Apple might just pull it off.

I am a former J2ME developer of games, and now I’m a Mac user and iPhone owner. Java on iPhone/iPod Touch is a crap idea. People who think iPhone needs Java are failing to understand the Apple approach. The fact is that Sun/J2ME almost definitely needs iPhone to survive once Apple roll out cheaper mass-market handsets.

J2ME produces, much like J2SE, crappy applications on every platform. The Apple experience is about polish, about remaining uncomplicated, reliable and confidence inspiring. J2ME is about trying to average out all phones and at least get our app out there in some form no matter what compromises we have to make. This is exactly what happens in the J2ME space: "We spent $$$$$ developing our J2ME reference build, now we need to cash in by porting to as many devices as possible. Who cares what the thing ends up looking / running like, if we’re not on phone X we might miss out on 10% of the market because it’s so popular."

Now, take a look at Skype’s new Java mobile client. it looks like they haven’t done a bad job on the UI but it definitely isn’t great. The point is the UI will not fit in well with the existing phone UI and it will look different to every other J2ME app on the phone, and it therefore requires different understanding to use it. It will also probably chew your battery like there’s no tomorrow. It will also not have access to any recently invented (probably circa 2 years lag) features the phone might have - as without standard J2ME APIs which take years to approve and roll out among handsets, developers have to rely on proprietary APIs and that means yet more R+D, yet more individual ports and yet more QA.

Then you have people like Innaworks who say they can automatically port J2ME apps to iPhone. Dream on guys! You might get something running but it is going to look like crap on the device, won’t use natural UI paradigms, and will likely require certain coding conventions in the J2ME app. The problem is that executives with no clue look at offerings like this and tell their coders/porters "Hey don’t worry we can just get it all automatically converted by these guys, no need to learn Objective C!". I’ve been there in the past with "automatic" porting tools between J2ME handsets. If these things are good, and they have been on the market for years, why do all the mobile companies still have huge numbers of staff dedicated to porting and QA? How do their converters magically scale images to look good on new higher resolution displays. How do they make text align properly on the screen according to the layouts you’ve used in your reference build?

These poor quality automated ports are for people who don’t care about quality of the ported product, and that is EXACTLY the kind of application you don’t want on an iPhone.

Java - I love you on the server. On the desktop you suck a bit. On mobile… you facilitated a games industry. On iPhone… you will just let in a bunch of crappy apps and games that look crap and perform like crap, and use up loads of iPhone battery running non-native code.

Game developers in the J2ME market will not have any major difficulty getting one or two coders to do ports from scratch to iPhone with Objective C. It just means that some of the companies will need to actually use some braincells to get some decent infrastructure in their development environments, which means smart build systems, decent data structures that scale to different devices etc.

Hopefully everyone will see come June that native apps will beat J2ME apps into the ground on iPhone and iPod Touch.