To paraphrase Robert Kennedy, "we definitely live in interesting times", or at least you do if you're part of JBoss. What with the language work we're doing around Ceylon, some great work with JRuby over in TorqueBox-land, major improvements in transactions performance, world domination from the Infinispan team (well, most of our teams to be perfectly honest!), strong involvement in the EE7 standardisation process, yet more world domination and great work from the Drools team, and so many other things going, it has been impossible for me to write about them all. We've even seen several of our competitors start to copy our PaaS story in recent weeks (well, they do say that imitation is the sincerest form of flattery!)
I've been meaning to write about several of these items for a while. But what with JBossWorld/JUDCon, working on the long term vision for JBoss, various off site meetings, and a vacation to Orlando (which turned into a successful working holiday), I simply haven't had time. But once we get over conference season I hope to get a bit of breathing room and revisit one or two of them. At the very least I'll be writing more on what I'll be talking about during my keynote, though if you were at my presentation during QCon London then you might be able to make an intuitive leap before then!
In conclusion it's worth saying that in the 6 years that I've been a part of JBoss I can't recall a time when there was as much innovation and excitement within the projects and their communities. This is definitely a great time for us!
Wednesday, April 27, 2011
JBossWorld 2011
Not long now until JBossWorld and JUDCon. I'm presenting at both this year, but probably the most important aspect will be my keynote. Since taking over from Sacha 2 years ago, I've given a state of the union at each JBossWorld, but this time will be different: yes we'll cover what has happened over the past 12 months, but the real meat of the presentation will be unveiling where we are going in the next few years. So if you haven't registered yet for either event, do so now (I think JUDCon attendees get free access the my keynote!)
Sunday, March 20, 2011
True Grit
I remember vividly the first time I saw True Grit: I was 7 years old and on a family holiday and my father and I snuck off to watch it. I loved it then and I continue to love it whenever I watch it. So it was with some apprehension that I heard they were making another movie. I still haven't seen it but I probably will eventually.
However, it was while I was reading about the new movie that I realised I'd not actually read the book. I did some research about it and kept hearing how good it was. When I saw some reviewers likening it to one of my favourite books of all time (To Kill A Mockinbird), I knew I had to give it a go. Well I'm almost finished the book and I have to admit it is definitely up there as a classic. If the new movie is as good, then I think it'll be worth a viewing. Though it'll have to go some to displace the original movie in my heart!
However, it was while I was reading about the new movie that I realised I'd not actually read the book. I did some research about it and kept hearing how good it was. When I saw some reviewers likening it to one of my favourite books of all time (To Kill A Mockinbird), I knew I had to give it a go. Well I'm almost finished the book and I have to admit it is definitely up there as a classic. If the new movie is as good, then I think it'll be worth a viewing. Though it'll have to go some to displace the original movie in my heart!
Monday, March 14, 2011
HPTS 2011 Call For Papers
Call for Participation
14th International Workshop
on High Performance Transaction Systems (HPTS)
October 23-26, 2011
Asilomar Conference Grounds
Pacific Grove, CA
The ubiquity of the Internet and the proliferation of "smart" devices have led us to a world where large, scalable, data-intensive systems -- once the rarified domain of mainframe computers and financial institutions -- now permeate virtually every industry. Social networks, online ticketing systems, and massively multiplayer online games are just a few of the applications regularly used by hundreds of millions of users that depend daily on such systems. System architects and engineers face increasingly complex challenges: larger scale, lower power, more client heterogeneity, etc. In addition, the skies are rapidly "cloud"ing up -- and some of the world's largest systems are being built from parts or platforms that are "non-traditional" in nature. The "NoSQL movement" is upon us, data analytics are running on thousand-node clusters, and almost every one of our traditional assumptions is being questioned by a new generation of data system architects.
Every two years, HPTS brings together a lively and opinionated group of participants to discuss and debate the pressing topics that affect today's systems and their design and implementation. Past workshops have included topics such as emerging directions in systems infrastructure, new applications, and current developments in software and technology. The topics are limited only by the imagination of our participants. The workshop will include position paper presentations, panels, moderated discussions, and significant time for casual interaction. And of course beer.
We ask potential participants to submit a short (two paragraph) technical summary, a one-page position paper, or an abstract of their current work. Submissions can present a viewpoint on a controversial topic, a summary of lessons learned, experience with a large or unusual system, an innovative mechanism, an enormous problem looming on the horizon, or anything else that convinces the program committee that the participant has something interesting to say. The submission process is purposely lightweight, but we require each submission to have only a single author.
The workshop is by invitation only and is limited to approximately 75 participants. The submissions drive both the invitation process and the workshop agenda. Participants may be asked to be part of a presentation or discussion session at the workshop.
Send submissions, in plain text, to hpts2011@ics.uci.edu no later than 11:59 PM (EST) April 1, 2011.
14th International Workshop
on High Performance Transaction Systems (HPTS)
October 23-26, 2011
Asilomar Conference Grounds
Pacific Grove, CA
The ubiquity of the Internet and the proliferation of "smart" devices have led us to a world where large, scalable, data-intensive systems -- once the rarified domain of mainframe computers and financial institutions -- now permeate virtually every industry. Social networks, online ticketing systems, and massively multiplayer online games are just a few of the applications regularly used by hundreds of millions of users that depend daily on such systems. System architects and engineers face increasingly complex challenges: larger scale, lower power, more client heterogeneity, etc. In addition, the skies are rapidly "cloud"ing up -- and some of the world's largest systems are being built from parts or platforms that are "non-traditional" in nature. The "NoSQL movement" is upon us, data analytics are running on thousand-node clusters, and almost every one of our traditional assumptions is being questioned by a new generation of data system architects.
Every two years, HPTS brings together a lively and opinionated group of participants to discuss and debate the pressing topics that affect today's systems and their design and implementation. Past workshops have included topics such as emerging directions in systems infrastructure, new applications, and current developments in software and technology. The topics are limited only by the imagination of our participants. The workshop will include position paper presentations, panels, moderated discussions, and significant time for casual interaction. And of course beer.
We ask potential participants to submit a short (two paragraph) technical summary, a one-page position paper, or an abstract of their current work. Submissions can present a viewpoint on a controversial topic, a summary of lessons learned, experience with a large or unusual system, an innovative mechanism, an enormous problem looming on the horizon, or anything else that convinces the program committee that the participant has something interesting to say. The submission process is purposely lightweight, but we require each submission to have only a single author.
The workshop is by invitation only and is limited to approximately 75 participants. The submissions drive both the invitation process and the workshop agenda. Participants may be asked to be part of a presentation or discussion session at the workshop.
Send submissions, in plain text, to hpts2011@ics.uci.edu no later than 11:59 PM (EST) April 1, 2011.
Saturday, March 05, 2011
A note to Program Committees
Over the years I've written over 50 papers, many technical reports, quite a few magazine articles and several books, not to mention a PhD thesis. I've sat on enough program committees over the past 20+ years to know that it is a difficult job, particularly if you've got a lot of papers to review and very little time. That's why assembling the program committee is often one of the most challenging tasks for the conference/workshop chairs.
Throughout this time I think I've had a pretty good paper acceptance ratio, but I have had papers rejected by conferences and workshops. I think if you weren't disappointed about a rejection then you probably didn't put in enough effort to the paper writing in the first place, and that's definitely something I do for every paper. So it's true to say that when our WS-REST paper was rejected we were all disappointed.
I'm not going to go into whether or not I agree with the reviewers: that would be inappropriate. But at least one of them did frustrate me with something I've seen done once or twice elsewhere and each time I see it I get really annoyed. As a reviewer, whether for a conference/workshop, a journal or elsewhere, you often want to illustrate your points, both positive and negative, by drawing the attention of the authors to other papers or works. But if you're going to do this make sure that those papers or citations are publicly available or it really is pretty pointless: you may as well be saying "You are wrong; I know it but I refuse to tell you why and you just have to believe me because I am a reviewer!", which is obviously not what you expect from peer review! It also doesn't reflect well on the conference.
Over the past few decades some journals and conference/workshop publications have gone private, only being available to paying readers. This does make it hard, but not impossible, to achieve publicly available copies. I remember us doing this back in the 1980's, by publishing technical reports that covered roughly the same content and were primarily there for others to access when the original papers were unavailable. As a member of a program committee you could then refer to these. But one way or another, if you are on a program committee and you're going to want authors to learn from the experience of others and improve their papers based on your comments, either refer to papers that they can access, or don't bother!
Throughout this time I think I've had a pretty good paper acceptance ratio, but I have had papers rejected by conferences and workshops. I think if you weren't disappointed about a rejection then you probably didn't put in enough effort to the paper writing in the first place, and that's definitely something I do for every paper. So it's true to say that when our WS-REST paper was rejected we were all disappointed.
I'm not going to go into whether or not I agree with the reviewers: that would be inappropriate. But at least one of them did frustrate me with something I've seen done once or twice elsewhere and each time I see it I get really annoyed. As a reviewer, whether for a conference/workshop, a journal or elsewhere, you often want to illustrate your points, both positive and negative, by drawing the attention of the authors to other papers or works. But if you're going to do this make sure that those papers or citations are publicly available or it really is pretty pointless: you may as well be saying "You are wrong; I know it but I refuse to tell you why and you just have to believe me because I am a reviewer!", which is obviously not what you expect from peer review! It also doesn't reflect well on the conference.
Over the past few decades some journals and conference/workshop publications have gone private, only being available to paying readers. This does make it hard, but not impossible, to achieve publicly available copies. I remember us doing this back in the 1980's, by publishing technical reports that covered roughly the same content and were primarily there for others to access when the original papers were unavailable. As a member of a program committee you could then refer to these. But one way or another, if you are on a program committee and you're going to want authors to learn from the experience of others and improve their papers based on your comments, either refer to papers that they can access, or don't bother!
Friday, March 04, 2011
ZX81 is 30 years old?!
Now this brings back memories! I was never a ZX owner, nor did I own a Spectrum. But they did come out when I was at school and I did write programs for them, so I have fond memories (including using a milk bottle as a heat sink!) My personal computer ownership started with a Commodore Pet (still have it at home!) and then a BBC Model B, both of which were a step up from the punch-tape mainframes that we used in school prior to their arrival! Ah, those were the days!
Tuesday, March 01, 2011
I confess ...
I have to confess that I'm a Bob Hope and Bing Crosby fan. I grew up with their movies, with the Road To ... series as my favourites. But Pale Face is a classic Hope-only movie and that's where I came across Jane Russell. So it's very sad to hear that she has died.
Monday, February 28, 2011
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.
Sunday, February 27, 2011
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!
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!
Wednesday, February 23, 2011
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.
Tuesday, February 08, 2011
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!
Wednesday, February 02, 2011
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.
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.
Saturday, January 29, 2011
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!
Sunday, January 23, 2011
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.
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.
Thursday, January 13, 2011
Wednesday, January 12, 2011
Software Craftsman
I didn't even know there was a Software Craftsman Manifesto, but Dan North makes some good points.
Sunday, January 09, 2011
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.
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.
Tuesday, December 28, 2010
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.
And the thesis can be obtained from here.
Subscribe to:
Posts (Atom)