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.

Marc on Hudson/Jenkins

I haven't been tracking the Hudson/Jenkins issue in depth, but from what I do know I have to agree with Marc. Community is critical to the success of an open source project, and if your licence allows a fork of the code then it's also possible to fork the community too. Even if forking the code isn't possible, if you don't embrace, support and nurture your communities then they'll either go elsewhere or start a competitive effort themselves. This may sound strange, but this is one of the things that I love about working in open source: it's not just about having the best technology; you need to have the best communities too.

HPTS 2011

Anyone who knows me probably knows how much I love the High Performance Transaction Systems workshops that Jim created and mentored for years. I've been going to it for many years and have been on the program committee for the past few. Well I'm pleased to say that we've just announced the Call for Papers for the event this year. If the past workshops are anything to go by then it'll be a great workshop and I'm really looking forward to October!

Beanstalk and PaaS?

I didn't get a chance to write up everything I've got to say about the Amazon Beanstalk announcement, particularly as it applies to JBoss. I agree with some of what Sacha and the CloudBees team have to say: it's a good step for Java, but I also think it's pretty obvious that this would happen. I'm not sure if this is an "I told you so" moment.

However, once again I have to say that I agree with Paul on his assessment: it's not quite a PaaS ... yet. It seems that others agree, though not everyone is so sure. I'm sure we will see (have to see) further improvements to what is being offered, but as things stand, this doesn't fit my definition of PaaS. But this is a fast moving arena at the moment, so I wouldn't be surprised to see things change in the future, particularly as the competition starts to heat up.

Steve on public vs private Cloud

Steve Jones makes some very similar points to my earlier posting on data and its role in the public versus private cloud debate. Definitely worth checking out.

Edsac being rebuilt

Wonderful news. Guess I'll be making a trip once it's completed then!

Software Craftsman

I didn't even know there was a Software Craftsman Manifesto, but Dan North makes some good points.

IO, objects and messages

I mentioned that one of my Christmas projects involved playing around with the IO programming language. I took it a little further than I'd planned originally and started to look at integrating transactions with it (in the form of the C++ version of Arjuna). I got to know the language pretty well, despite the poor documentation which often caused more delays and hair pulling.

One of the things I realised about half way through was that I really like IO because it has a lot in common with Smalltalk: everything is an object and methods are invoked via the exchange of messages. In some ways it made me realise how much I miss programming with Smalltalk, though that's not to suggest that I preferred one language over the other; it's been a few years since I really used Smalltalk so I'd have to refresh that knowledge to make a qualified judgement.

IO also reminded me that while I love C++ and probably still like it above others, as an object-oriented language it has a number of quirks that don't make it, or similar languages, ideal for beginners learning the ins and outs of OO. One of the things I miss, which was part of the original Smalltalk implementation and Simula, though removed from Smalltalk-80, is the concept of message passing to interact with objects. I always found this concept more natural when thinking about object orientation.

It's probably one of the reasons I took to distributed systems: in the early days of Arjuna, when C++ was chosen as the implementation language over Concurrent Euclid and others, we (mainly Graham) spent a lot of time on making C++ (opaquely) distributed (trailblazing this at the time). Obviously what we ended up with was a system where C++ objects interacted via messages! Since the work Graham did also supported multiple inheritance as well as overloading, it went much further than simply distributing an object's implementation.

Looking back at that period now, I could imagine doing something with that work to move a non-distributed C++ language varient in the direction of message passing, but that would probably have been pointless. C++ is good for what it was aimed at. But I think it, and similar languages such as Java, may not necessarily be the right basis from which to learn initially about object orientation (I still long for multiple inheritance and operator overloading in Java!) I believe that programmers should always have a broad knowledge of languages under their belts and I'm glad I came at C++ through the likes of Simula, Smalltalk, Lisp, Fortran and Forth, to name just a few. Some of them have little to say about object orientation, but I'm sure that all of them have influenced the way in which I think about and approach problems, no matter what the implementation language.

So back to IO. It may have a small following compared to the mainstream languages and it may suffer from poorer documentation than most, but if you've used Smalltalk or thought about learning it, then I'd recommend looking at IO as well. It's not perfect (which language is?) but I'm sure you'll learn something, or perhaps it'll refresh your memories about other languages as it did for me. The result may well be that you chane the way in which you think about object orientation or at least the way you use your favourite language today.

Well done Cambridge

Very well done! A bonus Christmas present. Fix the security issue(s) rather than ignore them and attempt to silence those who might call attention to them. OK, the latter might be cheaper and easier in the short term, but as a user I'd much prefer the former was the avenue explored!

And the thesis can be obtained from here.

I must be a traditionalist?

Two of my favourite movies at any time of year, but particularly at Christmas, are Scrooge with Alastair Sim (the definitive version IMO, with only Scrooged coming close) and It's a Wonderful Life. Both in black and white as they were intended originally. So what happens this year? The TV is showing colourised versions of them! No, no, no, no, no! That is wrong on so many levels! Almost as bad as "dogs and cats living together".

Now it's entirely likely that if colour film had existed when both movies were made then the directors would have chosen it and those movies would likely look and feel different to their colourised cousins. But the fact is that it wasn't and the film director's, writers etc. used the black and white medium to great effect. It's part of the atmosphere of the movies and is so ingrained in the making of them that when you watch you don't notice it's not in colour. And when you see it in colour today it's just wrong. Almost like watching a program or film based on something that was intended originally for radio. The act of moving it from one medium to another alters it, but rarely do the people involved in that alteration seem to understand that or take it into account.

Colourising films is a great example of the adage that "just because you can do something doesn't mean you should"! So if you have a choice between seeing the above two movies in colour or black and white, I recommend sticking with the original. You won't be disappointed.

A late Christmas present?

It's probably too late to expect this for Christmas, but I think a reprint of Geoffrey Hoyle's book is definitely on the cards for the new year!

End of an era

It's a bit of a sad day today. For over 10 years I've been using an HP Jornada 720 for a lot more than it was originally intended. But since I got it in 2000 it has become harder and harder to interface it with any of my desktop or laptop machines. You tend not to find machines today with IR or RS232 ports! And getting up-to-date versions of Java for it, for example, have proven difficult, to say the least!

Ultimately over the last couple of years I've been using it as a glorified address book. But as I use my smartphone more, or the built-in equivalent applications on my laptop, resorting to the Jornada became more and more of a hassle. So despite the fact that it is the machine I've used the longest over the past 30 years, I've decided to retire it and it is now resting comfortably in the loft. Maybe, just maybe, I'll resurrect it if the need arises. Until then I'll have fond memories of one of the best and most versatile machines HP ever built!

JUDCon 2011 in Boston

I've been thinking about tracks for JUDCon next year and posted a preliminary Call for Presentations earlier today. Take a look if you're at all interested in JBoss as a developer or as a user.

IO

Recently I've been reading up on IO the language, not to be confused with IO the moon of Jupiter. It's a very interesting prototype language, based on very few concepts (everything's either an object or a message, objects have slots which are either attributes or methods). It reminds me a lot of Smalltalk. But what surprises me the most is that it is such an extremely simple language and yet it's possible to do some extremely complex things with it. Although this wasn't one of my original pet projects for Christmas, I think it will be now!

I'm not sure if I'll take it further than that, but it's sufficiently different to other languages I've been playing with recently that it may well get some quality time from me as I figure out exactly what it's good for and where its limitations reside. If you're looking for something different in the language arena then take a look too. It won't take long to get to grips with the basics and you might well be pleasantly surprised by what you find.

Data on the outside (of the public Cloud) versus data on the inside (of the public Cloud)

A few years back Pat Helland wrote a nice paper about the issues of data outside and inside the services boundary and how the locale impacts traditional transaction semantics. This was around the time that there was a lot of work and publicity around extended transaction models. Pat used an analogy to relativity to drive home his point, whereas I'd been using quantum mechanics analogies. But regardless of how it is explained, the idea is that data and where it is located, is ultimately the bottleneck to scalability if total consistency is required (in a finite period of time).

So what's this got to do with Cloud? Well I've been thinking a lot about Cloud for quite a while (depending on your definition of Cloud, it could stretch back decades!) There are many problem areas that need to be worked out for the Cloud to truly succeed, including security, fault tolerance, reliability and performance. Some of these are related directly to why I believe private Clouds will be the norm for most applications.

But probably the prime reason why I think public Clouds won't continue to hog the limelight for enterprise or mission critical applications is the data issue. Processor speeds continue to increase (well, maybe not individual processor speeds, but when stuck on the same chip the result is the same), memory speeds increase, even disk speeds are increasing when you factor in the growing use of solid state. Network speeds have always lagged behind and that continues to be the case. If you don't have much data/information, or most of it is volatile and generated as part of the computation, then moving to a public cloud may make sense (assuming the problems I mentioned before are resolved). But for those users and applications that have copious amounts of data, moving it into the public cloud is going in the wrong direction: moving the computation to the data makes far more sense.

Now don't get me wrong. I'm not suggesting that public clouds aren't useful and won't remain useful. It's how they are used that will change for certain types of application. Data has always been critical to businesses and individuals, whether you're the largest online advertiser trying to amass as much information as possible, or whether you're just looking to maintain your own financial data. Trusting who to share that information with is always going to be an issue because it is related directly to control: do you control your own information when you need it or do you rely on someone else to help (or get in the way)? I suspect that for the vast majority of people/companies, the answer will be that they want to retain control over their data. (Over the years that may change, in the same way that banks became more trusted versus keeping your money under the mattress; though perhaps the bank analogy and trust isn't such a good one these days!)

Therefore, I think where the data will reside will define the future of cloud and that really means private cloud. Public clouds will be useful for cloud bursting and number crunching for certain types of application, and of course there will be users who can commit entirely to the public cloud (assuming all of the above issues are resolved) because they don't have critical data stores in which they rely or because they don't have existing infrastructure that can be turned into a protected (private) cloud. So what I'm suggesting is that data on the outside of the public cloud, i.e., within the private cloud, will dominate over data on the inside of the public cloud. Of course only time will tell, but if I were a betting man ...

It's Christmas!

In the immortal words of the great Noddy Holder and Slade ... It's Christmas (or will be very soon!) I have a couple of weeks off due to not taking much vacation throughout 2010 (which is a pattern I seem to follow every year). So as is usual for any vacation (at least mine), I've written a list, checked it twice, ruled out those things that are naughty, leaving only those that are nice and come up with way more things that I can do in the time available. But hey, it's better to be over active than under!

So what's in the list? Well there's the usual smattering of work related efforts. But I've tried to make the majority of them "pet projects". Of course they'll probably have some impact on work eventually, but that's not the reason for them at this point. Top of my list is doing some refreshers on some languages I haven't had a chance to use much recently, including Ruby and Erlang. Then I've got a paper I want to write on REST and transactions with Bill and Mike (OK, so this is work related, but I do like writing papers, so it almost doesn't count). I want to do some work on JavaSim too and if there's time, get back to my STM effort.

Lots to do. Lots to look forward to. Oh and then there's Christmas too! I love this time of year.

Another CloudBees acquisition

This is *not* a CloudBees blog, but yet again I have to say congratulations to Sacha and the team for their latest announcement! Very impressive move.

Nearly two years as CTO

A cross post. A quick summary: thanks Sacha!

Cloud 2.0? Give me a break!

Over 4 years ago a group of analysts and vendors got together to try and rally around the term SOA 2.0. In an attempt to stop that in its tracks, I said a few things that maybe played a smaller part in helping to show the problems behind the term. I haven't seen or heard of SOA 2.0 much since, so maybe the community effort helped to bring a little sense to the world.

Unfortunately it seems that adding 2.0 to something is still a favourite pastime for those that either can't figure out a good name, or simply don't understand why it works for Web 2.0. With today's announcement that Salesforce have bought Heroku, it seems that we've entered the world of 'Cloud 2'! Oh come on! Let's inject some reality into this again, before it gets jumped on by other vendors or analysts that believe an increment to a term really makes a difference when the technology or architecture hasn't actually evolved.

Apparently Cloud 2 is oriented around social, mobile and real-time. So is this hard real-time, soft real-time, or some other form of real-time, given that when you're using applications in the Cloud today the response is happening in your frame of reference and within your lifetime!

I do believe that the current perception of Cloud is limited to servers and that does need to change, but that can be sorted out by having a true architectural definition of Cloud that is agreed by everyone. But there's no need to call it Cloud 2. In fact that just adds more confusion!

And social aspects of Cloud? Well I'm not a big fan of social networks; I think they're anti-social: go down the pub to see your friends, don't chat to them on IRC!

So let's get a grip on reality! Sticking 2 on the end in the hopes that it'll help will only do the opposite. And as I said for SOA 2.0, if this "social, real-time and mobile" Cloud really is different than what we're getting used to today, then coin a proper term for it, e.g., The Social Cloud.