GWT and GXT

Recently I've been doing a lot of development in GWT. I have to say that, despite being a big fan of pure JavaScript RIA, I'm liking GWT a lot. It has been a couple of years since I touched GWT and it has come a long way. I particularly like the Activities and Places API, although there's a bit of a learning curve there.

One thing I don't particularly like though is Sencha's EXT-GWT, or GXT as it is known. For those that don't know, GXT provides an abundance of widgets including a fully featured Grid. This is of course highly enticing, but what I've found is that GXT appears to be an all-or-nothing proposition. GXT is more akin to a framework than a toolkit because it effects how you lay out your code. What isn't clear to me is why it has its own layout architecture and its own event architecture. That's just confusing!

I'm starting to think that GXT plugged a few gaps in GWT 1.x and is becoming increasing less relevant. GWT 2.x deprecates a lot of GXT; even GWT 1.6 introduced a new event model.

Don't even get me started on GXT's Grid separation of concerns; its one of those widgets that likes to influence how the data transfer objects look. Plain wrong. The whole loader concept is terribly confusing as well.

I feel that if GWT's TableCell was as fully featured as GXT's Grid then no one would probably use GXT.

Perhaps I'm being a little harsh though. GXT widgets present nicely. It is just that they don't just "slot in"; you've got to buy into all of GXT to use a little of it.

I have a new job

I now have a job with VMware starting January 24th and I'm excited! My role is as a vFabric consulting software engineer within the professional services division .

Over the past 12 years I've been an independent contracting developer/architecture/designer and launched quite a few of my own products. I suppose one of the initial drivers to go contracting for me back then was that it was lucrative to do so. I now feel that the gap in remuneration between going permanent and contracting has diminished.

Another incredibly important factor was my family. Contracting can be great but the cash flow can be stressful. With 4 kids I needed more stability.

Finally, I wanted to work with more like-minded people. During my contracting years I've met some truly inspirational people along the way; but I want to meet more! This can be difficult as a contractor as you tend not to stay around long enough to work on the strategic projects and with an organisation's best people.

So, back in May last year I decided to look around for some permanent work. I choose some companies with SpringSource being one of them. I thought, if I go for a permanent job then who would I really want to work for? It is important to "tow the corporate line" of course and so I needed to ensure that this would be a no-brainer. I'm not very good at lying!

I've been using the Spring framework for quite some time and became very interested in the work of some of the SpringSource people; namely Rod Johnson and Ben Alex. Towing the line for SpringSource would not be a difficult proposition... I contacted SpringSource and ended up meeting with Guy Baldwin and the ball then started to roll. I instantly liked Guy and his technical knowledge along with his amiable personality makes him a great face of VMware/SpringSource.

'better had just get one thing straight: VMware acquired SpringSource in 2009 and so SpringSource is now a division of VMware. I'll refer to SpringSource as VMware for the rest of this blog ('hope that is politically correct!).

vFabric is the name given to VMware's Cloud Application Platform, meaning the whole stack of technologies that enable applications to live in a cloud environment. Technically speaking the cloud may not be the actual cloud as in the internet, but live behind the corporate firewall; it doesn't really matter though. What the platform is really about is enabling applications to be scaled in order to meet unanticipated demand.

My specific role is a first here in Asia/Pac. VMware have a vFabric consulting presence in the US and I'm their first consultant for them here in our region. It is exciting.

I'll continue to post my own views on software development here but needless to say, they'll be my views and not necessarily VMware's!

The Low Cloud

I was chatting with a CIO mate today about the future of cloud computing and how his company are looking to build their own Cloud Enabled Application Platform (CEAP). I feel that many companies are sensitive to putting their data in the cloud itself and my friend definitely echoed that sentiment. There are some things his enterprise could put in to the cloud for economic reasons, but most things will reside behind their firewall.

Interestingly my friend's main driver for a CEAP was to achieve horizontal scalability. He has some performance issues that lend themselves well to being addressed in a highly parallel manner.

During this conversation I used the term "low cloud" to describe CEAP hosted behind the enterprise firewall. So, you heard the term, "low cloud" here first. :-)

Timezones, timezones and a new time zone library

I've had a bit of a thing about time zones and daylights savings rules for quite some time i.e. they interest me. This was first apparent in an application I wrote for the Palm OS originally named Time Traveler (which became Titan Class). Its time zone database was inspired by zoneinfo, but was no where near as sophisticated. The Palm OS was without time zone support in its first few incarnations. Eventually time zone support was incorporated but IMHO it was weak. I digress a little... the point is I've really liked the zoneinfo database that underpins most Unix based platforms for quite some time.

Java supports zoneinfo in its implementation by use of the ICU library. There is also a JSR that's about 3 years old which aims to provide greater support for zoneinfo.

I recently had a need to ensure that my application had the latest time zone rules available. From a Java perspective, Sun or Apple (or whoever) provide a patch when time zone rules change. You then typically restart your application. I didn't want that. My goals were:

• to have the latest rules on a monthly basis; and
• to be able to dynamically update the time zones without having to restart my application.

JSR-310 could probably help me out here but I had another nagging concern; in fact a couple:

• the JSR is 3 years old and doesn't appear to have progressed; and
• I like the zoneinfo structure and wanted to use something that honoured its structure closely.

I might be a little unfair toward JSR-310 and if it becomes approved then it'll be difficult to avoid. I'm also strongly aware of the "Not Invented Here" syndrome... not my style though. Then, there's the JCP-is-dead thingy...

So, what I've done is created a new Java time zone library that takes zoneinfo files and produces a JDK compatible facade. The library uses ANTLR to parse the zoneinfo files thus actually providing a parser that can be used for many languages. I'll shortly be open-sourcing this library and probably at The Codehaus depending on how well it is received there. Meanwhile here is an overview of its structure:

The library is effectively done and has reasonable test coverage. I hope that you'll join me and help improve it. Meanwhile any thoughts and ideas are most welcome.

Memory grids

There's a great podcast on Software Engineering Radio with Nati Shalom. The podcast discusses memory grids and I certainly found it insightful. In essence memory grids are being looked upon as the next disk.

The clincher for me was the revelation that the durability of data is not related to it being persisted to disk; it is related to the number of geographically disbursed copies of that data at any one time. Taken to the extreme this could mean that you don't need disk at all, but practically the data gets persisted to disk in an asynchronous manner. This is called "write behind" and can be performed at n nodes, if not all of them.

I think memory grids are very interesting. My prediction is that memcached, a popular open source memory cache that can be distributed over many nodes, will become a memory grid offering write-behind persistence. Same goes for Ehcache/Terracotta i.e. these memory caches will evolve beyond being just that. There are of course commercial memory caches out there including vmware's Gemfire and Oracle's Coherence.

One reason in my mind as to why memory grids are topical is commodity hardware being able to address one heck of a lot of memory resident data. Since the introduction of 64 bit computing for the masses, we now have a situation where a cheap processor can generally access about 256TB data - more than enough for most databases! Of course, with 32 bit processors about 4GB could be addressed which is less than many databases.

I think something that can be overlooked with memory grids is persistence. As mentioned, write-behind appears typical, but what isn't focused on is what performs the write-behind. There's no reason why that write-behind can't be done with a conventional RDBMS and I understand that many memory grids support such a thing. Thus with memory grids, it appears that you can have the best of both worlds.

Bring on the memory grid (preferably open sourced!).

Mac OS X Virtualisation

This evening I read that Apple are retiring the Xserve. I guess that's a shame as I always wanted to see more of OS X in the server space. I think that this will relegate OS X to the SOHO market; unless... Apple permit virtualised instances of OS X.

Permitting virtualisation would be a very smart move by Apple. Let's face it, unless you can run on OS as a virtualised instance then you're never going to be a player in the enterprise and in the elastic cloud.

Time will tell if Apple see the merits of virtualisation.

JavaScript Dependency Management and JSLint Tools

I've been focusing on JavaScript Rich Internet Application development for some time now and have felt that while JavaScript is a capable language, it has sorely lacked tooling. This situation is changing of course and we're seeing more JavaScript tools come from the likes of Mozilla, Apple and Google quite frequently.

I feel that the lack of dependency management with good version control in any language is painful and JavaScript was no exception. I recently spent a good part of my day sorting out dependencies in a .NET environment; I sorely missed Apache Maven there. Given my JavaScript development activities I decided to provide the dependency management functionality of Maven to JavaScript via a Maven Plugin.

Imagine writing just the following in your JavaScript code when you want to ensure that jQuery or Prototype.js is present at runtime:

var $;

Alternatively when there are no global variables declared by a JavaScript dependency you can import it without being concerned about its file location and version:

/**
 * @import com.jqueryui:jquery-ui
 */

The com.jqueryui:jquery-ui artifact along with its version is declared in Maven's POM file.

This frictionless approach to declaring JavaScript dependency requirements is the motivation for the Maven JavaScript Import Plugin.

I'm pleased to announce the availability of my JavaScript Import Plugin at Codehaus where I have now also become a committer (a great honour!).

Along the way  I decided to create a plugin that provided efficient JSLint invocation during JavaScript development. This plug is also released at the Codehaus and is named the JSLint Plugin.

Please help the professional JavaScript developer community by downloading and building the projects from source and try out some development using the plugins.