Starlite

I remember a few years ago watching a demo of Starlite on Tomorrow's World. I always wondered what happened to Starlite and was reading today that it continues to be stalled and yet apparently passes a host of tests to prove that there really is something behind it! What a shame. It has immense potential.

The future of Java middleware

I'm speaking at QCon London again this year and it's on a topic I've been working on for a number of years: where is (Java) middleware going? I'm not going to spoil things too much here, but suffice it to say that anyone who has heard me talk about middleware over the years, probably won't be surprised. I'll blog more about it after the event.

My presentation may be on Java, but what I've got to say transcends any particular language implementation. If Java hadn't come along and we were all still happily working on C++, then I'd be saying similar things. The middleware component of the larger software industry is at an inflexion point and no, Cloud didn't cause it: we've been heading towards this event at full speed for several years. We can either keep heading blindly down the route of inventing bespoke wheels that are often just as round as their cousins elsewhere, or we can start to think and work more efficiently.

I obviously can't speak on behalf of other vendors, but I can say that JBoss will be heading in the right direction! Of course this does not mean we are ditching Java Enterprise Edition, or any of the other investments we've made! But we have been expanding over the years from just JBossAS to other things like Hibernate, ESB, portal, etc. I see what we need to do over the next few years as just another evolution of what we've been doing. And if you look around at the plethora of projects we've got on JBoss.org then you'll be able to see that we've been heading in the direction I'm hinting at for some time.

The next few years are going to be exciting for JBoss. I'm also hoping that we can energise the open source communities as a whole around some of these ideas so that a wider audience can participate and benefit. Like I said ... exciting!

Another era draws to a close

For those of us who grew up huddled behind the sofa or simply asking the question "How do Daleks get up stairs?", this is a sad day.

DEC founder dies

It's likely that many of the current generation of developers will never have heard of DEC, but they had a profound impact on the way our industry developers. So it's sad to hear that Ken Olsen has died. The PDP-11 will always have a place in my heart!

What do developers want in the Cloud?

OK, so the title is a loaded question, because I'm getting hit from all sides with conflicting information. Plus as a developer myself, it's often hard for me to be objective. For instance, not everyone loves emacs the way I do! This could also be a very wide ranging discussion on aspects from repositories through to runtime management. Maybe I'll revisit some of those in later entries, but for now I feel compelled to focus on the editor/IDE component of the development experience.

Over the years I've used a range of different editors and IDEs. I'm not going to list them all here, but the fact that I still use emacs and the command line shows that perhaps I'm not easily pleased. However, whether it's emacs, Eclipse or (shudder) vi, I always have my development code on my laptop or desktop. Yes it may get pulled down from a remote repository, but it's edited locally before being committed back. This is a fairly standard way of doing things and probably the only thing to change over the past 20+ years is the repository aspect. Before cvs, svn and git there were ad hoc solutions, but the result was essentially the same: remote backup/sharing mechanism but local development.

Does cloud change this? Well I hadn't really put too much thought into this because I really didn't (don't) think it does. As a developer I still need a repository (OK, that could be hosted in the Cloud - I don't care as long as it is available when I check out and check in code). And I still need a local development environment with an IDE or editor, right? Well there's the problem. I think I do and I know quite a lot of people who think similarly. These folks are long time developers across a range of industries and academia, who expect to be able to code locally and deploy remotely into the (public or private) Cloud.

However, it seems that there is an alternative option, where everything is remote, including the code on which you develop. In this scenario the code is maintained in the Cloud (it may still be checked out of some repository, but maybe not). You edit it through a browser (Web 2.0 meets the Cloud) and the environment within the browser is (hopefully) as feature rich as your non-Cloud IDE. And typically this is all based around a 4GL offering.

Now don't get me wrong: I can see how this can all work. From a technical perspective it's pretty straightforward. Plus I don't have a problem with 4GL as far as they go. My problem with this approach is centred around the remote development aspect. As a developer I want to be able to code when I want and where I want, without having to worry about network connectivity issues. I need that off-line aspect. It's actually one of the reasons I'm still not entirely happy with using maven, but I'm getting over that now and am in rehab!

So is this really the kind of development environment/working pattern that Cloud developers want and need? Isn't Eclipse, or even emacs, sufficient and perhaps even preferable? As I said before, it's hard for me to separate what I'd want and expect as a developer from what others might want and expect.