Reg Developer: Interview with Jim Gray

Reg Developer have an iinterview with Jim Gray on their site, well known for his work on database theory in the 1970s, and currently working with Microsoft as manager of Microsoft Research’s eSciences group at the Bay Area Research Center (BARC) in San Francisco.

The interview covers transactions, using parallel processors such as GPUs for intensive processing, and why developers have a hard time adapting to thinking of problems in terms of parallel processing.

Continuing adventures with Grails – now we’re getting Groovy

I had a few hours this weekend to continue investigating the possibility of using of using Grails and Groovy to implement a solution for a client, and I’ve learnt enough at this point so say for this project I am committed to using Grails.

I was already liking what I was seeing, but was uncertain early on if this could realy do the job, but now I am sold. It really is Groovy; it is awesome. The productivity gain from using the ‘coding by convention’ approach made popular by Ruby on Rails really is awesome. It is amazing. In comparision with working with multi-layered architectures where as a developer I have to code each indiviidual slice in the application from end to end and then spend just as much time on the configuration to wire them all together – this is amazing. Groovy and Grails are so concise and gets the job done with minimal effort and coding, and yes – minimal if any configuration.

Ok, I learnt a few lessons at the weekend, and came across a couple of issues that I logged with Grails JIRA: – Comparing EJB2 to JPA – Why? I’ll tell you why. have a question posted on their site this morning asking ‘Comparing EJB2 and JPA – why?’.

Ok so the technologies are now radically different and improved, and of course once you have seen the JPA api, there is obviously no turning back, providing you have a platform available that supports it.

These are two of the main reasons why it is important to make the comparison – the main reason – to educate developers and get them up to speed with the new EJB3.0 spec.

But surely this is such an awesome development and step forward for Enterprise Application development that any developer worth their salt will already be intimately familiar with the spec? Yes, of course it is awesome, and is how the EJB spec should have looked from day 1. The main problem I am seeing from working within my own Java developer community is that developers who will most likely be using EJB3.0 tomorrow are already entrenched in EJB2.x projects today – they are so busy working on current implementations that they have not had time yet to surface and see what is going on in the world. Yes they have heard of EJB3.0, have probably not heard of it referred to as JPA, and yes they would love to have time to read the spec and have time to prototype some apps, but they’re too busy right now.

It’s ‘the curse of the long running project’ – projects that were scoped and designed as long as 2 or even 3 years ago are still knee-deep in development implementing functionality on top of whatever technologies were chosen during the project’s inception. For 2-3 year old projects coming to a close, this is likely to be J2EE 1.3 and yes they are still using EJB2.x. If you’re lucky a long-running project may have in it’s contract the allowance to upgrade to latest API and technology releases along the way, but in most cases this is unlikely since this most likely does not buy the customer any inprovement in functionality, although may be desirable for long time maintenance.