I can tell this because the UI has changed slightly, and more importantly pretty much any time I try to request a page i.e. do anything with the site I get this glorious error message:

That or the variant: "org.omg.CORBA.NO_RESOURCES: vmcid: 0×0 minor code: 0 completed: No"

First, we try not to laugh that they are still using CORBA. Then we laugh at the genius of the package name "org.omg" as in OH MY GOD. Then we cry that after what must be 3 years or so now, Co-Op bank has still utterly failed to turn this into an appealing and reliable online banking product, when they do so well on the personal banking site and use COMPLETELY DIFFERENT code it seems on the business side. Anyone heard of D.R.Y. at Co-Op Bank?

Online banking is about the least funny place to have I.T. clowns working instead of actual experts. Co-Op have been suckered by their IT managers, internal or external, and seem to remain blinded by them. Even the call centre staff know how bad this is, and its been going on for years.

Check out the blog post and the many many negative user comments!

In a nutshell, the UI on Windows is changing to a full screen UI, with overcomplicated horrendous Windows design touches. It truly beggars belief that they can be so wrong about this and misjudge their user base so.

One comment on the blog that sums it up well is:

"An app like Skype should be really out of the way most of the time. For me it is a great communication tool, but I have to switch if this is Skype’s future."

It seems like Skype’s ego has taken over and forgotten that it is just  a phone on steroids. If your mobile phone suddently became the size of your laptop, you’d get rid of it for a better one. Skype will haemorrhage users if they don’t rethink this UI disaster.

I can only think that most of the developers/producers with a clue have left Skype and new people post Ebay takeover are completely ruining the company.

Who knows, our entire company might …. shudder… have to switch to iChat. At least it has multi-way video and app sharing. It doesn’t have SkypeIn or SkypeOut though of course, but we currently don’t use those and will not start if Skype’s UI goes this awful awful way.

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.

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.

Most people understand that psychologically a 1.0 release is important. It sets the baseline and foundation for what is to come in the future. Grails 1.0 is incredibly rich in terms of core features, and has a growing list of free plugins that add all manner of powerful functionality.

Grails 1.0 has a powerful ORM DSL now for tweaking what Hibernate does behind the scenes in an intuitive way, including index generation. We’ve also now got Hibernate’s second-level caching in there. Not to mention the frankly pretty twisted auto unmarshalling of JSON/xml request payloads into beans, and the withFormat content negotiation stuff.

We have also put together a framework for automatically running functional web tests on "specimen" applications held in SVN as part of the Grails continuous integration builds. There are some teething troubles with the server environment but the whole process is working locally, and we just need to fill SVN with some good test apps with, more importantly, some comprehensive webtest scripts.

This will effectively form a kind of "TCK" for Grails and will ensure stability against the 1.0 baseline functionality - in addition to the large number of unit tests that Grails undergoes constantly as part of the continuous integration build platform (the rather excellent Bamboo as it happens). Contributions of non-trivial applications with comprehensive unit and webtests would be appreciated.

This is in addition to the work Graeme did to tie together Groovy SVN HEAD and Grails SVN HEAD in continuous integration to ensure that we spot any changes to Groovy that break Grails as early as possible, as well as giving the Groovy team a great stock of code to run their changes against.

We’re looking forward to talking to all the new Grails users that this 1.0 release will bring!