For Christmas 2007 my wife got me an Aqua Sphereing experience. The local centre is also only 5 miles from our house. Given that she was also the one who got me into SCUBA diving, I figured this would be fun. Unfortunately the weather in the UK this summer hasn't been that good, but eventually I managed to find the time and the weather held. Although the whole thing lasted only a minute or so, I had a fantastic time and now know what it feels like to be inside a giant washing machine. My friend Duane did something similar at JavaOne earlier this year, but I don't think there was water involved. If you get the chance, I'd definitely recommend the experience!
For our anniversary this year, my wife got me an EcoSphere (hmmm, there's definitely a spherical theme going on here!). It turned up the other day and it's fantastic. I love this sort of thing: mini-worlds, whether they're real or virtual, have always fascinated me. Maybe it's a god-complex or something, but I can spend hours just watching these worlds evolve.
Saturday, August 30, 2008
Friday, August 15, 2008
Erlang and Mac OS 10
Wednesday, June 25, 2008
WS-CDL literature surveys
I've been on the program committees for too many conferences and workshops to keep count. You almost always see the expected bell-curve of paper submissions (5% are really bad, 90% are ok, and 5% are extremely good). But irrespective of the quality and content of a paper, the one thing that always annoys me is bad citations and references. I think this goes back to when we were doing the initial work around Arjuna and looking at how to leverage object-oriented techniques for fault tolerance. These days it'd be very passe, but back then it was the start of OO and the work we did was cutting edge. We weren't the only ones doing work in that area: there was Camelot/Avalon (later went on to become Encina from Transarc) and Argus (ISIS wasn't really about exploiting OO approaches). Whenever we ran into papers by those teams it was very rare to see them reference us, whereas the inverse was almost never the case (timing permitting). Frustrating to say the least. So I always try to ensure that accepted papers have appropriate references. It benefits the author's work as well as the reader (there's nothing more infuriating than reading a paper, asking yourself "OK, but how does this compare with XYZ?" and then finding that the author's don't mention it.)
What has this to do with WS-CDL? Well I'm on another PC (I won't mention which, though I have posted the CFP on the blog already) and recently received a swathe of papers on orchestration and choreography. All of them mentioned BPMN. Several of them mentioned BPEL. A couple of them mentioned Pi-calculus. None of them mentioned WS-CDL (or its predecessors)! Of those that mentioned Pi-calculus, they all duplicated the effort that has gone into CDL. Plus every single paper mentioned the importance of being "standards compliant". It's not as if it's hard to find a mention of CDL via google (try googling for 'choreography web services'): in the "good 'ol days" we used to wonder if the lack of references to Arjuna was down to the complexity of tracking journal and conference papers - this was before the WWW and in the relative infancy of the internet (oh cr*p, doesn't that make me sound old?!)
Why is it that these papers didn't even mention CDL once? I think it's a combination of factors including: poor research on the part of the authors', excellent publicity on the part of major vendors that CDL is a dead standard, and confusion around the relationship of CDL to BPEL. This does a disservice to the people who have worked on CDL over the years: it's an excellent body of work and brings value to the choreography arena both from a static (development) perspective as well as dynamic (runtime). Of course it's in the vendor's best interests to ignore WS-CDL when they've adopted WS-BPEL heavily, but these things are complimentary (in fact CDL compliments any orchestration implementation, so don't get hung up over the WS part of the name.) But for a researcher, it's not acceptable.
So if you're doing research into choreography (and/or orchestration) and are thinking of writing a paper, you need to look at WS-CDL. Even if it's only to compare and contrast with what you're going to do, it's important. (A cogent argument against it in favour of your own work is fine, as long as the literature survey is complete.) Otherwise you could be disappointed when your paper is rejected.
What has this to do with WS-CDL? Well I'm on another PC (I won't mention which, though I have posted the CFP on the blog already) and recently received a swathe of papers on orchestration and choreography. All of them mentioned BPMN. Several of them mentioned BPEL. A couple of them mentioned Pi-calculus. None of them mentioned WS-CDL (or its predecessors)! Of those that mentioned Pi-calculus, they all duplicated the effort that has gone into CDL. Plus every single paper mentioned the importance of being "standards compliant". It's not as if it's hard to find a mention of CDL via google (try googling for 'choreography web services'): in the "good 'ol days" we used to wonder if the lack of references to Arjuna was down to the complexity of tracking journal and conference papers - this was before the WWW and in the relative infancy of the internet (oh cr*p, doesn't that make me sound old?!)
Why is it that these papers didn't even mention CDL once? I think it's a combination of factors including: poor research on the part of the authors', excellent publicity on the part of major vendors that CDL is a dead standard, and confusion around the relationship of CDL to BPEL. This does a disservice to the people who have worked on CDL over the years: it's an excellent body of work and brings value to the choreography arena both from a static (development) perspective as well as dynamic (runtime). Of course it's in the vendor's best interests to ignore WS-CDL when they've adopted WS-BPEL heavily, but these things are complimentary (in fact CDL compliments any orchestration implementation, so don't get hung up over the WS part of the name.) But for a researcher, it's not acceptable.
So if you're doing research into choreography (and/or orchestration) and are thinking of writing a paper, you need to look at WS-CDL. Even if it's only to compare and contrast with what you're going to do, it's important. (A cogent argument against it in favour of your own work is fine, as long as the literature survey is complete.) Otherwise you could be disappointed when your paper is rejected.
Sunday, June 15, 2008
What's the point?
I've had the pleasure of working with some very smart people over the years in the area of fault tolerant distributed systems. As a result I've performed research and development in a number of different techniques, including replication (for high availability) and transactions (for consistency). In all that time I've been conscious of the fact that a lot of time and effort has been spent proving that whatever was done worked in the case of failures (whatever the specific definition may be for the particular environment): after all, that's the point of the whole exercise. Yes I know that failures don't happen that often (try selling a transaction manager to people who haven't used one for years and explaining why they really really need to buy one!) But they do happen and that's why fault tolerance techniques (and testing they work in the presence of failures) are so important.
Now why do I bother mentioning this? Well it's come to my attention over the past few years that some purveyors of fault tolerance solutions either don't bother to test the "edge cases" (which are not really edge cases, but the reason for their product's existence) or don't care (and hence publicize) that their solutions won't work in the case of some (all?) possible failure modes. I'm not going to name-and-shame them (primarily because I haven't been able to confirm those reports myself), but if you are a user of something that purports to offer high availability or data consistency in the presence of failures, you really need to check that that vendor means and how they go about confirming that their product works as they say it should.
Now why do I bother mentioning this? Well it's come to my attention over the past few years that some purveyors of fault tolerance solutions either don't bother to test the "edge cases" (which are not really edge cases, but the reason for their product's existence) or don't care (and hence publicize) that their solutions won't work in the case of some (all?) possible failure modes. I'm not going to name-and-shame them (primarily because I haven't been able to confirm those reports myself), but if you are a user of something that purports to offer high availability or data consistency in the presence of failures, you really need to check that that vendor means and how they go about confirming that their product works as they say it should.
Monday, June 09, 2008
SOA 2.0 all over again?
Over two years ago I got frustrated at the announcement of SOA 2.0. Many others were likewise confused and irritated at an attempt to create another hype curve. I'm not going to attribute cause and effect because maybe it would have happened anyway, but SOA 2.0 pretty much bit the dirt subsequently. Well while writing up this article for InfoQ I had a serious case of deja vu.
WTF is WOA? Where did it spring from and more precisely where has it been hiding for the past ten years? At its best it seems to be the same as ROA, i.e., a concrete implementation of REST targeting the Web. (I'm not so keen on ROA either: I prefer REST/HTTP.) At its worst it's an excuse to start generating more terms ('Web-oriented SOA'?! You've got to be joking!) One of the original articles on Web Oriented Architecture (aka WOA) was posted by Dion on April 1st, so maybe that was a Freudian Slip on his part?
But if WOA is not the same as REST (or REST as applied to the Web) then it really needs a different acronym: REST is fundamentally the architecture on which the Web is based and everyone understands that now. Alright you do need to clarify how the concepts are implemented (HTTP, JMS etc.), but that's easy to do without coining a whole new terminology. Independently of Roy's thesis, the W3C has done a good job of defining the Web Architecture. Plus, people have been building RESTful good citizen applications for quite a while. Did they need to coin a new term to make it clear what was happening under the hood? I think not. But then again, maybe the intent is to try to outwit us with an attempt at the Chewbacca Defense? I think it's more a case of The Emperor's New Clothes syndrome and we should just say that WOA is naked and move on!
Look guys, we have REST as a well defined and accepted term. Why do we need yet another acronym to mean the same thing? The answer is that we don't, so let's stop polluting the atmosphere with meaningless or duplicate terms and get on with helping end users and developers figure out the best way in which to deliver business functions and data! I can say 'REST as applied to the Web' in less time than it takes to explain WOA and I can guarantee you that more people will understand what I mean with the first description than the second.
WTF is WOA? Where did it spring from and more precisely where has it been hiding for the past ten years? At its best it seems to be the same as ROA, i.e., a concrete implementation of REST targeting the Web. (I'm not so keen on ROA either: I prefer REST/HTTP.) At its worst it's an excuse to start generating more terms ('Web-oriented SOA'?! You've got to be joking!) One of the original articles on Web Oriented Architecture (aka WOA) was posted by Dion on April 1st, so maybe that was a Freudian Slip on his part?
But if WOA is not the same as REST (or REST as applied to the Web) then it really needs a different acronym: REST is fundamentally the architecture on which the Web is based and everyone understands that now. Alright you do need to clarify how the concepts are implemented (HTTP, JMS etc.), but that's easy to do without coining a whole new terminology. Independently of Roy's thesis, the W3C has done a good job of defining the Web Architecture. Plus, people have been building RESTful good citizen applications for quite a while. Did they need to coin a new term to make it clear what was happening under the hood? I think not. But then again, maybe the intent is to try to outwit us with an attempt at the Chewbacca Defense? I think it's more a case of The Emperor's New Clothes syndrome and we should just say that WOA is naked and move on!
Look guys, we have REST as a well defined and accepted term. Why do we need yet another acronym to mean the same thing? The answer is that we don't, so let's stop polluting the atmosphere with meaningless or duplicate terms and get on with helping end users and developers figure out the best way in which to deliver business functions and data! I can say 'REST as applied to the Web' in less time than it takes to explain WOA and I can guarantee you that more people will understand what I mean with the first description than the second.
Sunday, June 01, 2008
What's it mean to be an architect?
We live in a 19th century station master's house and it's time to either move or add another module (aka extension). We're looking at the latter for a number of reasons. Going this route means we need to have someone come in and draw up plans: the architect. Most people probably think of what an architect does based on the dictionary definition: "One who designs and supervises the construction of buildings or other large structures." But if you think about it more, this person is more than a designer or supervisor: they have to understand a lot about materials and how they fit together in order to assess structural integrity, stress points, resilience to adverse conditions and, of course, the final all-important look. So although they may not get their hands dirty with bricks and mortal (some do), they have to know about the construction as well as the people who will eventually do that work. That doesn't mean they are necessarily as skilled as some others in their team (e.g., I doubt the typical architect would have the skills of a carpenter), but they would need to understand wood, bricks, stone etc.
This requirement for an architect to know how things come together and, if necessary, be able to do some of that development should be common to uses of the term within other sectors and not just building. Whether it be biotechnology, cars or ships, the architect had better be skilled enough to understand how their plans will be affected by the implementation. How they do that may depend upon the industry and the individual (e.g., some building architects have been carpenters in the past).
The software architect needs to be the same. If you've got 'architect' in your title then you need to either be (or have been) a coder. (I think 'be' is better). Whether that means you've coded entire systems, or had to bring together existing modules as well, doesn't really matter as long as you have the understanding of what's possible, practical, reliable and maintainable as a developer. Writing a few XML configuration scripts doesn't cut-it in my opinion, because that does not bring the necessary appreciation for architecture. For instance, how can you understand what it means for a failure to happen in a distributed system if you've never had to implement one (or part of one)? So far I've been in the fortunate position to have only met software architects who fit my definition (I suppose a chicken-and-egg situation could be argued).
However, I know others who have met (suffered) exceptions to this rule. In some companies it appears to be endemic that architects are designers or team managers, with little or no coding experience behind them. Maybe they're just lucky and the development teams pick up the slack, ensuring success of the projects. Or maybe the blame for failed projects just manages to go elsewhere. But I know when we decide to go with an extension on our house I'll be looking for an architect who knows more than how to draw pretty pictures or make sure the work is done on time: I don't want the whole thing collapsing on us months or years later!
This requirement for an architect to know how things come together and, if necessary, be able to do some of that development should be common to uses of the term within other sectors and not just building. Whether it be biotechnology, cars or ships, the architect had better be skilled enough to understand how their plans will be affected by the implementation. How they do that may depend upon the industry and the individual (e.g., some building architects have been carpenters in the past).
The software architect needs to be the same. If you've got 'architect' in your title then you need to either be (or have been) a coder. (I think 'be' is better). Whether that means you've coded entire systems, or had to bring together existing modules as well, doesn't really matter as long as you have the understanding of what's possible, practical, reliable and maintainable as a developer. Writing a few XML configuration scripts doesn't cut-it in my opinion, because that does not bring the necessary appreciation for architecture. For instance, how can you understand what it means for a failure to happen in a distributed system if you've never had to implement one (or part of one)? So far I've been in the fortunate position to have only met software architects who fit my definition (I suppose a chicken-and-egg situation could be argued).
However, I know others who have met (suffered) exceptions to this rule. In some companies it appears to be endemic that architects are designers or team managers, with little or no coding experience behind them. Maybe they're just lucky and the development teams pick up the slack, ensuring success of the projects. Or maybe the blame for failed projects just manages to go elsewhere. But I know when we decide to go with an extension on our house I'll be looking for an architect who knows more than how to draw pretty pictures or make sure the work is done on time: I don't want the whole thing collapsing on us months or years later!
Saturday, May 31, 2008
WSWSA 2008 CFP
ESWSA: Workshop on empirical studies of Web service architectures
(the RESTñSOAP debate in numbers)
in conjunction with OOPSLA 2008
http://eswsa.cs.uiuc.edu
The recent rapid growth in size and capability of distributed computing
systems has heralded new types of software architectures, among them the
messaging paradigm championed by Web Services and the distributed hypermedia
model upheld by the Web. Currently these two competing styles ñ known as
SOAP and RESTful ñ are used, but little is known about the real-world
engineering characteristics of each style, though each has an active camp of
campaigners. The known comparisons focus on sometimes abstract architectural
principles, and there is little empirical information in the public domain
from specific system implementation experience.
Only one piece of empirical data regarding this debate is available to date.
It comes from Amazon. Jeff Barr, quoted by Tim O'Reilly, noted that 85% of
Web services requests at Amazon are HTTP-based, or RESTful. That was in April
2003.
The ongoing conflict between the two groups is often called the ìREST-SOAP
debate.î Yet actual debates, organized for example during conferences, have
not been conclusive, because they typically fail to convince the proponents of
the competing style. Rather than arguing over abstract concepts, this workshop
will address the merits of each style based on empirical experience how
systems work in practice.
GOALS OF THIS WORKSHOP
The workshop will present empirical work on RESTful and SOAP-based Web
Services. We are seeking papers that present empirical engineering evidence
regarding specific aspects of both kinds of services. This evidence will be
the starting point of the discussion during the workshop that aims to:
* Identify what is known empirically about building RESTful and SOAP services;
* Discuss the empirical results to see how widely they apply;
* Confirm or rebuke abstract claims with empirical evidence; and
* Identify questions for further study.
Workshop submissions should focus on one of the following types of empirical
studies.
Firstly, we are soliciting empirical studies or comparisons of SOAP and RESTful
Web services in the context of:
* Publicly accessible services
* Cross-Organization Integration (B2B), or inter-enterprise services
* Enterprise Application Integration (EAI), or intra-enterprise services
* Non-functional requirements of services (e.g. security, reliability, crash
recovery)
Second, studies of the REST architectural style, e.g.
* How closely does the Web follow the principles of REST?
* How many Web services claiming to be RESTful follow the principles of REST?
Good sources of arguments regarding the REST-SOAP debate are
* RESTwiki, http://rest.blueoxen.net
* Paul Prescod's paper, ìRoots of the REST-SOAP debate,î XML 2002.
* "RESTful Web services" book by Leonard Richardson and Sam Ruby
* Web services-related tracks at qCon conferences
SUBMISSIONS
We are seeking short papers (up to 6 pages, 9pt font, in ACM format). A
submission must pose an empirical question related to Web services, present
some data that addresses the question and interpret the results. Submissions
will be judged based on soundness of methods, quality of analysis, as well as
relevance of the empirical results to the REST-SOAP debate. They will be
reviewed by Program Committee members, who are industry and academic experts
in the area of Web services.
Submissions will be accepted through the EasyChair submission system available
from http://eswsa.cs.uiuc.edu.
Authors of accepted papers will be notified by September 2nd (in time to take
advantage of OOPSLA's early registration discount). Authors will have an
opportunity to update their submissions with the reviewers' feedback until
September 20th, 2008. The reviewed submissions will be featured in OOPSLA
Companion 2008 and in the ACM's Digital Library. Note that at least one author
of the submitted paper must be present at the workshop to present it.
IMPORTANT DATES
* ESWSA paper submission deadline: August 3, 2008
* Notification of acceptance/rejection: September 2, 2008
* OOPSLA's early registration deadline: September 11, 2008
* ESWSA Workshop: Oct 19th or 20th, 2008
WORKSHOP PROGRAM
The workshop will run over an entire dayís session at OOPSLA 2008.
Morning session: paper presentations (20 mins per paper + 10 mins for questions)
Afternoon session: more presentations plus a panel discussion of invited experts
WORKSHOP ORGANIZERS
Munawar Hafiz, University of Illinois
Paul Adamczyk, University of Illinois
Jim Webber, ThoughtWorks
PROGRAM COMMITTEE
Mark Baker, Coactus Consulting
Raj Balasubramanian, IBM
Chris Ferris, IBM
Ralph E Johnson, University of Illinois
Mark Little, Redhat
Steve Loughran, HP
Mark Nottingham, Yahoo
Savas Parastatidis, Microsoft
Ian Robinson, ThoughtWorks
Halvard Skogsrud, ThoughtWorks
Stefan Tilkov, innoQ
Paul Watson, Newcastle University
Sanjiva Weerawarana, WSO2
PABELISTS
Jim Webber, ThoughtWorks
Sanjiva Weerawarana, WSO2
Kyle Brown, IBM
Brian Foote, Industrial Logic
Paul Adamczyk, University of Illinois
For more information about the workshop please visit http://eswsa.cs.uiuc.edu
or contact the organizers.
(the RESTñSOAP debate in numbers)
in conjunction with OOPSLA 2008
http://eswsa.cs.uiuc.edu
The recent rapid growth in size and capability of distributed computing
systems has heralded new types of software architectures, among them the
messaging paradigm championed by Web Services and the distributed hypermedia
model upheld by the Web. Currently these two competing styles ñ known as
SOAP and RESTful ñ are used, but little is known about the real-world
engineering characteristics of each style, though each has an active camp of
campaigners. The known comparisons focus on sometimes abstract architectural
principles, and there is little empirical information in the public domain
from specific system implementation experience.
Only one piece of empirical data regarding this debate is available to date.
It comes from Amazon. Jeff Barr, quoted by Tim O'Reilly, noted that 85% of
Web services requests at Amazon are HTTP-based, or RESTful. That was in April
2003.
The ongoing conflict between the two groups is often called the ìREST-SOAP
debate.î Yet actual debates, organized for example during conferences, have
not been conclusive, because they typically fail to convince the proponents of
the competing style. Rather than arguing over abstract concepts, this workshop
will address the merits of each style based on empirical experience how
systems work in practice.
GOALS OF THIS WORKSHOP
The workshop will present empirical work on RESTful and SOAP-based Web
Services. We are seeking papers that present empirical engineering evidence
regarding specific aspects of both kinds of services. This evidence will be
the starting point of the discussion during the workshop that aims to:
* Identify what is known empirically about building RESTful and SOAP services;
* Discuss the empirical results to see how widely they apply;
* Confirm or rebuke abstract claims with empirical evidence; and
* Identify questions for further study.
Workshop submissions should focus on one of the following types of empirical
studies.
Firstly, we are soliciting empirical studies or comparisons of SOAP and RESTful
Web services in the context of:
* Publicly accessible services
* Cross-Organization Integration (B2B), or inter-enterprise services
* Enterprise Application Integration (EAI), or intra-enterprise services
* Non-functional requirements of services (e.g. security, reliability, crash
recovery)
Second, studies of the REST architectural style, e.g.
* How closely does the Web follow the principles of REST?
* How many Web services claiming to be RESTful follow the principles of REST?
Good sources of arguments regarding the REST-SOAP debate are
* RESTwiki, http://rest.blueoxen.net
* Paul Prescod's paper, ìRoots of the REST-SOAP debate,î XML 2002.
* "RESTful Web services" book by Leonard Richardson and Sam Ruby
* Web services-related tracks at qCon conferences
SUBMISSIONS
We are seeking short papers (up to 6 pages, 9pt font, in ACM format). A
submission must pose an empirical question related to Web services, present
some data that addresses the question and interpret the results. Submissions
will be judged based on soundness of methods, quality of analysis, as well as
relevance of the empirical results to the REST-SOAP debate. They will be
reviewed by Program Committee members, who are industry and academic experts
in the area of Web services.
Submissions will be accepted through the EasyChair submission system available
from http://eswsa.cs.uiuc.edu.
Authors of accepted papers will be notified by September 2nd (in time to take
advantage of OOPSLA's early registration discount). Authors will have an
opportunity to update their submissions with the reviewers' feedback until
September 20th, 2008. The reviewed submissions will be featured in OOPSLA
Companion 2008 and in the ACM's Digital Library. Note that at least one author
of the submitted paper must be present at the workshop to present it.
IMPORTANT DATES
* ESWSA paper submission deadline: August 3, 2008
* Notification of acceptance/rejection: September 2, 2008
* OOPSLA's early registration deadline: September 11, 2008
* ESWSA Workshop: Oct 19th or 20th, 2008
WORKSHOP PROGRAM
The workshop will run over an entire dayís session at OOPSLA 2008.
Morning session: paper presentations (20 mins per paper + 10 mins for questions)
Afternoon session: more presentations plus a panel discussion of invited experts
WORKSHOP ORGANIZERS
Munawar Hafiz, University of Illinois
Paul Adamczyk, University of Illinois
Jim Webber, ThoughtWorks
PROGRAM COMMITTEE
Mark Baker, Coactus Consulting
Raj Balasubramanian, IBM
Chris Ferris, IBM
Ralph E Johnson, University of Illinois
Mark Little, Redhat
Steve Loughran, HP
Mark Nottingham, Yahoo
Savas Parastatidis, Microsoft
Ian Robinson, ThoughtWorks
Halvard Skogsrud, ThoughtWorks
Stefan Tilkov, innoQ
Paul Watson, Newcastle University
Sanjiva Weerawarana, WSO2
PABELISTS
Jim Webber, ThoughtWorks
Sanjiva Weerawarana, WSO2
Kyle Brown, IBM
Brian Foote, Industrial Logic
Paul Adamczyk, University of Illinois
For more information about the workshop please visit http://eswsa.cs.uiuc.edu
or contact the organizers.
Wednesday, May 14, 2008
JavaOne bug
I'll post about JavaOne later, but if you attended you really should check out Duane's blog concerning health issues around the conference. Luckily I wasn't affected, but I know others were!
Tuesday, May 13, 2008
DOA 2008
OTM 2008 Federated Conferences - Call For Papers
Monterry (Mexico), November 9 - 14, 2008
http://www.cs.rmit.edu.au/fedconf/
BRIEF OVERVIEW
"OnTheMove (OTM) to Meaningful Internet Systems and Ubiquitous Computing"
co-locates five successful related and complementary conferences:
- International Symposium on Distributed Objects and Applications (DOA'08)
- International Conference on Ontologies, Databases and Applications of
Semantics (ODBASE'08)
- International Conference on Cooperative Information Systems (CoopIS'08)
- International Symposium on Grid computing, high-performAnce and Distributed
Applications (GADA'08)
- International Symposium on Information Security (IS'08)
Each conference covers multiple research vectors, viz. theory (e.g. underlying
formalisms), conceptual (e.g. technical designs and conceptual solutions) and
applications (e.g. case studies and industrial best practices). All five
conferences share the scientific study of the distributed, conceptual and
ubiquitous aspects of modern computing systems, and share the resulting
application-pull created by the WWW.
PAPER SUBMISSION SITE
http://www.cs.rmit.edu.au/fedconf/index.html?page=submit
IMPORTANT DEADLINES:
- Abstract submission: June 8, 2008
- Paper submission: June 15, 2008
- Acceptance notification: August 10, 2008
- Camera ready: August 25, 2008
- Registration: August 25, 2008
- OTM Conferences: November 9 - 14, 2008
PROGRAM COMMITTEE CHAIRS
CoopIS PC Co-Chairs (coopis2008@cs.rmit.edu.au)
* Johann Eder, University of Klagenfurt, Austria
* Masaru Kitsuregawa, University of Tokyo, Japan
* Ling Liu, Georgia Institute of Technology, USA
DOA PC Co-Chairs (doa2008@cs.rmit.edu.au)
* Mark Little, Red Hat, UK
* Alberto Montresor, University of Trento, Italy
* Greg Pavlik, Oracle, USA
ODBASE PC Co-Chairs (odbase2008@cs.rmit.edu.au)
* Malu Castellanos, HP, USA
* Fausto Giunchiglia, University of Trento, Italy
* Feng Ling, Tsinghua University, China
GADA PC Co-Chairs (gada2008@cs.rmit.edu.au)
* Dennis Gannon, Indiana University, USA
* Pilar Herrero, Universidad Politécnica de Madrid, Spain
* Daniel S. Katz, Louisiana State University, USA
* María S. Pérez, Universidad Politécnica de Madrid, Spain
IS PC Co-Chairs (is2008@cs.rmit.edu.au)
* Jong Hyuk Park, Kyungnam University, Korea
* Bart Preneel, Katholieke Universiteit Leuven, Belgium
* Ravi Sandhu, University of Texas, USA
* André Zúquete, University of Aveiro, Portugal
Monterry (Mexico), November 9 - 14, 2008
http://www.cs.rmit.edu.au/fedconf/
BRIEF OVERVIEW
"OnTheMove (OTM) to Meaningful Internet Systems and Ubiquitous Computing"
co-locates five successful related and complementary conferences:
- International Symposium on Distributed Objects and Applications (DOA'08)
- International Conference on Ontologies, Databases and Applications of
Semantics (ODBASE'08)
- International Conference on Cooperative Information Systems (CoopIS'08)
- International Symposium on Grid computing, high-performAnce and Distributed
Applications (GADA'08)
- International Symposium on Information Security (IS'08)
Each conference covers multiple research vectors, viz. theory (e.g. underlying
formalisms), conceptual (e.g. technical designs and conceptual solutions) and
applications (e.g. case studies and industrial best practices). All five
conferences share the scientific study of the distributed, conceptual and
ubiquitous aspects of modern computing systems, and share the resulting
application-pull created by the WWW.
PAPER SUBMISSION SITE
http://www.cs.rmit.edu.au/fedconf/index.html?page=submit
IMPORTANT DEADLINES:
- Abstract submission: June 8, 2008
- Paper submission: June 15, 2008
- Acceptance notification: August 10, 2008
- Camera ready: August 25, 2008
- Registration: August 25, 2008
- OTM Conferences: November 9 - 14, 2008
PROGRAM COMMITTEE CHAIRS
CoopIS PC Co-Chairs (coopis2008@cs.rmit.edu.au)
* Johann Eder, University of Klagenfurt, Austria
* Masaru Kitsuregawa, University of Tokyo, Japan
* Ling Liu, Georgia Institute of Technology, USA
DOA PC Co-Chairs (doa2008@cs.rmit.edu.au)
* Mark Little, Red Hat, UK
* Alberto Montresor, University of Trento, Italy
* Greg Pavlik, Oracle, USA
ODBASE PC Co-Chairs (odbase2008@cs.rmit.edu.au)
* Malu Castellanos, HP, USA
* Fausto Giunchiglia, University of Trento, Italy
* Feng Ling, Tsinghua University, China
GADA PC Co-Chairs (gada2008@cs.rmit.edu.au)
* Dennis Gannon, Indiana University, USA
* Pilar Herrero, Universidad Politécnica de Madrid, Spain
* Daniel S. Katz, Louisiana State University, USA
* María S. Pérez, Universidad Politécnica de Madrid, Spain
IS PC Co-Chairs (is2008@cs.rmit.edu.au)
* Jong Hyuk Park, Kyungnam University, Korea
* Bart Preneel, Katholieke Universiteit Leuven, Belgium
* Ravi Sandhu, University of Texas, USA
* André Zúquete, University of Aveiro, Portugal
WS-FM 2008
WS-FM 2008
5th International Workshop on Web Services and Formal Methods
September 4-5, 2008, Milan, Italy
http://www.informatik.uni-rostock.de/ws-fm2008/
Co-located with the 6th International Conference on
Business Process Management (BPM'08)
Important Dates
---------------
* Abstract submission deadline: May 19, 2008
* Paper submission deadline: May 26, 2008
* Author notification: June 23, 2008
* Camera-ready pre-proceedings: July 21, 2008
* Workshop dates September 4-5, 2008
Scope of the Workshop
---------------------
Web Service (WS) technology provides standard mechanisms and protocols
for describing, locating and invoking services available all over the
web. Existing infrastructures already enable providers to describe
services in terms of their interface, access policy and behavior, and
to combine simpler services into more structured and complex
ones. However, research is still needed to move WS technology
from skilled handcrafting to well-engineered practice, supporting
the management of interactions with stateful and long-running services,
large farms of services, quality of service delivery, inter alia.
Formal methods can play a fundamental role in the shaping of such
innovations. For instance, they can help us define
unambiguous semantics for the languages and protocols that underpin
existing WS infrastructures, and provide a basis for
checking the conformance and compliance of bundled services. They can
also empower dynamic discovery
and binding with compatibility checks against behavioural properties
and quality of service requirements. Formal analysis of security
properties and performance is also essential in application areas such as
e-commerce. These are just a few prominent aspects;
the scope for using formal methods in the area of Web Services is
much wider, and the challenges raised by this new area can
offer opportunities for extending the state of the art in formal techniques.
The aim of the workshop series is to bring together researchers
working on Web Services and Formal Methods in order to catalyze
fruitful collaboration. The scope of the workshop is not purely
limited to technological aspects. In fact, the WS-FM series has a strong
tradition of attracting submissions on formal approaches to
enterprise systems modeling in general, and business process modeling
in particular. Potentially, this could have a significant impact on
the on-going standardization efforts for Web Service technology.
List of Topics
--------------
This edition of the workshop will have a special focus on the
integration of different ways for conceiving Web Services, like
orchestration vs choreography, Petri nets and workflow models vs
process calculi ones, client-server interaction vs multiparty
conversation, secure but static service binding vs open dynamic
binding, etc.
Other topics of interest include, but are not limited to:
* Formal approaches to service-oriented analysis and design
* Formal approaches to enterprise modeling and business process modeling
* WS coordination and transactions frameworks
* Formal comparison of different models proposed for WS protocols and
standards
* Formal comparison of different approaches to WS choreography and
orchestration
* Types and logics for WS
* Goal-driven and semantics-based discovery and composition of WS
* Model-driven development, testing, and analysis of WS
* Security, performance and quality of services
* Semi-structured data management and XML technology
* WS ontologies and semantic description
* Innovative application scenarios for WS
We encourage also the submission of tool papers, describing tools
based on formal methods, to be exploited in the context of Web
Services applications.
Submissions
-----------
Submissions must be original and should neither be already published
somewhere else nor be under consideration for publication while being
evaluated for this workshop.
We are negotiating with Springer the publication of all accepted
papers in the workshop post-proceedings as a volume of Lecture Notes
in Computer Science (LNCS), to appear a few months after the workshop.
Papers are to be prepared in LNCS format and must not exceed 15 pages.
All papers must be submitted following the instructions at the
WS-FM'08 submission site, handled by EasyChair:
http://www.easychair.org/conferences/?conf=wsfm2008
History
-------
Information about previous editions of the workshop can be found at
WS-FM'07: http://bpm07.fit.qut.edu.au/ws-fm07/
WS-FM'06: http://www.cs.unibo.it/projects/ws-fm06/
WS-FM'05: http://www.cs.unibo.it/~lucchi/ws-fm05/
WS-FM'04: http://www.cs.unibo.it/~lucchi/ws-fm04/
Starting from 2007, the workshop has taken over the activities of the
online community formerly known as the "Petri and Pi" Group, which
allowed to bring closer the community of workflow oriented researchers
with that of process calculi oriented researchers. People interested
in the subject can still join the active mailing list on "Formal
Methods for Service Oriented Computing and Business Process
Management" (FMxSOCandBPM) available at
http://www.cs.unibo.it/cgi-bin/mailman/listinfo/fmxsocandbpm
Steering Committee
------------------
W. van der Aalst (Eindhoven University of Technology, The Netherlands)
M. Bravetti (University of Bologna, Italy)
M. Dumas (University of Tartu, Estonia)
J.L. Fiadeiro (University of Leicester, UK)
G. Zavattaro (University of Bologna, Italy)
Program Committee
-----------------
Co-chairs:
R. Bruni (University of Pisa, Italy)
K. Wolf (University of Rostock, Germany)
Other PC members:
F. Arbab (CWI, The Netherlands)
M. Baldoni (University of Torino, Italy)
A. Barros (SAP Research Brisbane, Australia)
B. Benatallah (University of New South Wales, Australia)
K. Bhargavan (Microsoft Research Cambridge, UK)
E. Bonelli (Universidad Nacional de Quilmes, Argentina)
M. Butler (University of Southhampton, UK)
P. Ciancarini (University of Bologna, Italy)
F. Curbera (IBM Hawthorne Heights, U.S.)
G. Decker (HPI Potsdam, Germany)
F. Duran (University of Malaga, Spain)
S. Dustdar (University of Vienna, Austria)
A. Friesen (SAP Research Karlsruhe, Germany)
S. Gilmore (University of Edinburgh, Scotland)
R. Heckel (University of Leicester, UK)
D. Hirsch (Intel Argentina, Argentina)
F. Leymann (University of Stuttgart, Germany)
M. Little (RedHat, UK)
N. Kavantzas (Oracle Inc., U.S.)
A. Knapp (LMU Munich, Germany)
F. Martinelli (CNR Pisa, Italy)
H. Melgratti (University of Buenos Aires, Argentina)
S. Nakajima (National Institute of Informatics, Japan)
M. Nunez (Complutense University of Madrid, Spain)
J. Padget (University of Bath, UK)
G. Pozzi (Politecnico Milano, Italy)
R. Pugliese (University of Florence, Italy)
A. Ravara (Technical University of Lisbon, Portugal)
S. Ross-Talbot (pi4tech)
N. Sidorova (Eindhoven University of Technology, The Netherlands)
C. Stahl (Humboldt-University Berlin, Germany)
E. Tuosto (University of Leicester, UK)
H. Voelzer (IBM Zurich, Switzerland)
D. Yankelevich (Pragma Consultores, Argentina)
P. Yendluri (Software AG, U.S.)
5th International Workshop on Web Services and Formal Methods
September 4-5, 2008, Milan, Italy
http://www.informatik.uni-rostock.de/ws-fm2008/
Co-located with the 6th International Conference on
Business Process Management (BPM'08)
Important Dates
---------------
* Abstract submission deadline: May 19, 2008
* Paper submission deadline: May 26, 2008
* Author notification: June 23, 2008
* Camera-ready pre-proceedings: July 21, 2008
* Workshop dates September 4-5, 2008
Scope of the Workshop
---------------------
Web Service (WS) technology provides standard mechanisms and protocols
for describing, locating and invoking services available all over the
web. Existing infrastructures already enable providers to describe
services in terms of their interface, access policy and behavior, and
to combine simpler services into more structured and complex
ones. However, research is still needed to move WS technology
from skilled handcrafting to well-engineered practice, supporting
the management of interactions with stateful and long-running services,
large farms of services, quality of service delivery, inter alia.
Formal methods can play a fundamental role in the shaping of such
innovations. For instance, they can help us define
unambiguous semantics for the languages and protocols that underpin
existing WS infrastructures, and provide a basis for
checking the conformance and compliance of bundled services. They can
also empower dynamic discovery
and binding with compatibility checks against behavioural properties
and quality of service requirements. Formal analysis of security
properties and performance is also essential in application areas such as
e-commerce. These are just a few prominent aspects;
the scope for using formal methods in the area of Web Services is
much wider, and the challenges raised by this new area can
offer opportunities for extending the state of the art in formal techniques.
The aim of the workshop series is to bring together researchers
working on Web Services and Formal Methods in order to catalyze
fruitful collaboration. The scope of the workshop is not purely
limited to technological aspects. In fact, the WS-FM series has a strong
tradition of attracting submissions on formal approaches to
enterprise systems modeling in general, and business process modeling
in particular. Potentially, this could have a significant impact on
the on-going standardization efforts for Web Service technology.
List of Topics
--------------
This edition of the workshop will have a special focus on the
integration of different ways for conceiving Web Services, like
orchestration vs choreography, Petri nets and workflow models vs
process calculi ones, client-server interaction vs multiparty
conversation, secure but static service binding vs open dynamic
binding, etc.
Other topics of interest include, but are not limited to:
* Formal approaches to service-oriented analysis and design
* Formal approaches to enterprise modeling and business process modeling
* WS coordination and transactions frameworks
* Formal comparison of different models proposed for WS protocols and
standards
* Formal comparison of different approaches to WS choreography and
orchestration
* Types and logics for WS
* Goal-driven and semantics-based discovery and composition of WS
* Model-driven development, testing, and analysis of WS
* Security, performance and quality of services
* Semi-structured data management and XML technology
* WS ontologies and semantic description
* Innovative application scenarios for WS
We encourage also the submission of tool papers, describing tools
based on formal methods, to be exploited in the context of Web
Services applications.
Submissions
-----------
Submissions must be original and should neither be already published
somewhere else nor be under consideration for publication while being
evaluated for this workshop.
We are negotiating with Springer the publication of all accepted
papers in the workshop post-proceedings as a volume of Lecture Notes
in Computer Science (LNCS), to appear a few months after the workshop.
Papers are to be prepared in LNCS format and must not exceed 15 pages.
All papers must be submitted following the instructions at the
WS-FM'08 submission site, handled by EasyChair:
http://www.easychair.org/conferences/?conf=wsfm2008
History
-------
Information about previous editions of the workshop can be found at
WS-FM'07: http://bpm07.fit.qut.edu.au/ws-fm07/
WS-FM'06: http://www.cs.unibo.it/projects/ws-fm06/
WS-FM'05: http://www.cs.unibo.it/~lucchi/ws-fm05/
WS-FM'04: http://www.cs.unibo.it/~lucchi/ws-fm04/
Starting from 2007, the workshop has taken over the activities of the
online community formerly known as the "Petri and Pi" Group, which
allowed to bring closer the community of workflow oriented researchers
with that of process calculi oriented researchers. People interested
in the subject can still join the active mailing list on "Formal
Methods for Service Oriented Computing and Business Process
Management" (FMxSOCandBPM) available at
http://www.cs.unibo.it/cgi-bin/mailman/listinfo/fmxsocandbpm
Steering Committee
------------------
W. van der Aalst (Eindhoven University of Technology, The Netherlands)
M. Bravetti (University of Bologna, Italy)
M. Dumas (University of Tartu, Estonia)
J.L. Fiadeiro (University of Leicester, UK)
G. Zavattaro (University of Bologna, Italy)
Program Committee
-----------------
Co-chairs:
R. Bruni (University of Pisa, Italy)
K. Wolf (University of Rostock, Germany)
Other PC members:
F. Arbab (CWI, The Netherlands)
M. Baldoni (University of Torino, Italy)
A. Barros (SAP Research Brisbane, Australia)
B. Benatallah (University of New South Wales, Australia)
K. Bhargavan (Microsoft Research Cambridge, UK)
E. Bonelli (Universidad Nacional de Quilmes, Argentina)
M. Butler (University of Southhampton, UK)
P. Ciancarini (University of Bologna, Italy)
F. Curbera (IBM Hawthorne Heights, U.S.)
G. Decker (HPI Potsdam, Germany)
F. Duran (University of Malaga, Spain)
S. Dustdar (University of Vienna, Austria)
A. Friesen (SAP Research Karlsruhe, Germany)
S. Gilmore (University of Edinburgh, Scotland)
R. Heckel (University of Leicester, UK)
D. Hirsch (Intel Argentina, Argentina)
F. Leymann (University of Stuttgart, Germany)
M. Little (RedHat, UK)
N. Kavantzas (Oracle Inc., U.S.)
A. Knapp (LMU Munich, Germany)
F. Martinelli (CNR Pisa, Italy)
H. Melgratti (University of Buenos Aires, Argentina)
S. Nakajima (National Institute of Informatics, Japan)
M. Nunez (Complutense University of Madrid, Spain)
J. Padget (University of Bath, UK)
G. Pozzi (Politecnico Milano, Italy)
R. Pugliese (University of Florence, Italy)
A. Ravara (Technical University of Lisbon, Portugal)
S. Ross-Talbot (pi4tech)
N. Sidorova (Eindhoven University of Technology, The Netherlands)
C. Stahl (Humboldt-University Berlin, Germany)
E. Tuosto (University of Leicester, UK)
H. Voelzer (IBM Zurich, Switzerland)
D. Yankelevich (Pragma Consultores, Argentina)
P. Yendluri (Software AG, U.S.)
Saturday, April 26, 2008
XTP
Have been doing some thinking and planning around what Extreme Transaction Processing should be. Now all I need do is fine time to do something about it!
Saturday, April 19, 2008
OPENflow deserves another chance
While we were dutifully working on Arjuna, Arjuna2, JavaArjuna, OTSArjuna and other things, Stuart and Santosh (amongst others) were also hard at work on OPENflow. As with many things we did back then it began life as an attempt to improve standards: this time workflow in collaboration with Nortel (and was better received by users than the competitor specification from the WfMC). Over the next few years it went much further than the original submission and became one of our product offerings. Although the research and development took a bit of a back-seat to the JTS development when we were acquired by Bluestone, it still managed to be cutting edge.
Unfortunately when we were acquired by HP they already had a workflow product (Process Manager Interactive). The decision was taken to stop OPENflow and that was essentially that. (It was also the point that HP Middleware, a predominately Java-based division, decided to mothball our C++ transaction service.) But even today OPENflow offers capabilities that modern equivalents could benefit from. Quite a few capabilities to be perfectly honest. I think it's time to revisit past decisions and re-learn forgotten techniques!
I haven't even begun to blog about B2B Objects yet, either.
Unfortunately when we were acquired by HP they already had a workflow product (Process Manager Interactive). The decision was taken to stop OPENflow and that was essentially that. (It was also the point that HP Middleware, a predominately Java-based division, decided to mothball our C++ transaction service.) But even today OPENflow offers capabilities that modern equivalents could benefit from. Quite a few capabilities to be perfectly honest. I think it's time to revisit past decisions and re-learn forgotten techniques!
I haven't even begun to blog about B2B Objects yet, either.
Degrees of coupling
Over the past few years we've seen the distributed system industry moving to embrace loose coupling as though it's a global panacea to all of the woes of the previous decades. I've said on many occasions that coupling (loose or close) is something that cannot be taken in isolation: as with most things there's a trade-off to be made and there are degrees of coupling (no innuendos intended). I made that point again with my first presentation of 2008 and as recently as QCon, also taking that opportunity to point out again that loose coupling isn't something discovered or invented by the distributed systems community. It's a general software engineering pattern that has been used since Noah used his ZX76BC.
Now what makes me write about this again, when it's old hat? Well Jim's written a nice piece on coupling and cohesion. It's worth a read, but what prompted me to add this entry wasn't the subject itself but the fact that it references Pete Lee. As with Jim, Pete was one of my undergraduate teachers and took me through two years of software engineering. And it was this course that first brought loose coupling and cohesion (and many other things) to my attention. When I was preparing my presentation for the winter school I wanted to pull some specific references from the software engineering book we used during that undergraduate course, but it's stuck up in the loft and I was too lazy to go and find it. It's been over 20 years since I last saw it, but I'm pretty sure it was the first edition of Ian Sommeville's excellent book. Maybe time to buy the latest edition!
Now what makes me write about this again, when it's old hat? Well Jim's written a nice piece on coupling and cohesion. It's worth a read, but what prompted me to add this entry wasn't the subject itself but the fact that it references Pete Lee. As with Jim, Pete was one of my undergraduate teachers and took me through two years of software engineering. And it was this course that first brought loose coupling and cohesion (and many other things) to my attention. When I was preparing my presentation for the winter school I wanted to pull some specific references from the software engineering book we used during that undergraduate course, but it's stuck up in the loft and I was too lazy to go and find it. It's been over 20 years since I last saw it, but I'm pretty sure it was the first edition of Ian Sommeville's excellent book. Maybe time to buy the latest edition!
Winter School presentation
Back in January I make a two day presentation on the evolution of distributed systems at CUSO Winter School. The audience was a mixture of students and professors with a variety of backgrounds (most not in distributed systems research). So I had a great opportunity to start with a blank slate and try to give an historical background as well as comparing and contrasting with different approaches. The feedback during the event was great, but also the act of just sitting down and having to create the presentation helped coalesce a lot of things that I've worked through over the past 20 years.
QCon London 2008
It's a bit late, but here's a quick summary of QCon London 2008. Although I've been an InfoQ editor for a couple of years, this was my first time at a QCon and I was impressed. The presentations I saw were all packed and technically very good: there was none of the "product placement" that you tend to see more and more at conferences. Even the vendor pavilion was less of a car salesroom and more another opportunity to share technical discussions. I was impressed.
I jumped across the tracks during the days I wasn't presenting. However, on the Thursday I stayed with my track. Given what I'd heard about the same track at the last QCon, I was expecting a lot of controversy. However, this time I think the community has moved on and accepted that one size doesn't fit all, which coincidentally was the subject of my presentation. The entire day of the track went well and I thought all of the presentations came together very cohesively.
I jumped across the tracks during the days I wasn't presenting. However, on the Thursday I stayed with my track. Given what I'd heard about the same track at the last QCon, I was expecting a lot of controversy. However, this time I think the community has moved on and accepted that one size doesn't fit all, which coincidentally was the subject of my presentation. The entire day of the track went well and I thought all of the presentations came together very cohesively.
Diving at long last
It's been really difficult to find the time and the weather to go diving. With the 6 month clock ticking, we finally bit the bullet and got wet. The weather wasn't great, so we opted for Ellerton again. Although my dive computer said it was 9C certain parts of my body registered much lower! Whereas others were diving in dry suits, we were roughing it in our 5mm wet suits. We managed to get nearly an hour dive time despite the temperature. And I'm sure my hands were blue when I started!
I love diving for a number of reasons. Not least of which is the silence and ability to think about things while I'm down there. I managed to resolve a few issues I haven't been able to get to during my normal working day and a couple of new blog entries will be coming as a direct result. Now it had better not be another 6 months before my next dive!
I love diving for a number of reasons. Not least of which is the silence and ability to think about things while I'm down there. I managed to resolve a few issues I haven't been able to get to during my normal working day and a couple of new blog entries will be coming as a direct result. Now it had better not be another 6 months before my next dive!
Friday, April 11, 2008
Another blast from the past
I was in Neuchatel this week for some meetings and one of our conversations moved on to failure detection/failure suspecting: the fact that you cannot reliably detect failures until (and unless) those failures are eventually recovered from. Typical "detection" uses timeouts and if you use the wrong value you can end up in a world of pain. That's where failure suspectors come in: the idea is that if you think something has failed then you make sure everyone else agrees with you so even if you are wrong you don't end up with split-brain syndrome. This reminded me of some work I did back in the 90's around quantum mechanics and failure detectors.
Sunday, March 23, 2008
A couple of not so obvious facts around REST/HTTP
While composing an entry on QCon I came across a couple of factoids around REST/HTTP that I had thought obvious but when I mentioned them at the event a few people found them surprising. So rather than bury them in that post (when it eventually appears), I thought I'd bring them up here:
Now the folks I met at QCon were all very bright. So their surprise at these "revelations" came as a bit of a surprise to me. But hey, maybe it wasn't a good statistical sample.
- I've been developing applications on the Web since it was first released: being at University at the time, I had a lot of freedom to play. I even wrote a browser in InterViews! (Anyone else remember gopher?) Anyway, I remember being glad when the first URN proposal came out because it looked to address some of the issues we mentioned at the time, through the definition of a specific set of name servers: no longer would you have to use URLs directly, but you'd use URNs and the infrastructure would look them up via the name server(s) for you. Sound familiar? Well fast forward 10 years and that never happened. Or did it? Well if you consider what a naming service (or trading service) does for you, WTF is Google or Yahoo?
- My friend and co-InfoQ colleague/editor Stefan has another nice article on REST. In it he addresses some of the common mis-conceptions around REST, and specifically the perceived lack of pub/sub. You what? As he and I mentioned separately, it seems pretty obvious that RSS and Atom are the right approach in RESTland. The feedback I got at QCon the other week put this approach high on my pet projects list for this vacation, so I've been working on that for our ESB as well as some other stealth projects of my own.
Now the folks I met at QCon were all very bright. So their surprise at these "revelations" came as a bit of a surprise to me. But hey, maybe it wasn't a good statistical sample.
Monday, March 17, 2008
Beautiful Code
Just back from QCon London and taking the day off (another one of those "use 'em or lose 'em" days). I'll say more about QCon in a separate entry, but I wanted to mention something that came up there but which has been playing on my mind for a while anyway: the art of beautiful code and refactoring. I heard a number of people saying that you shouldn't touch a programming language if you can't (easily) refactor applications written using it. I've heard similar arguments before, which comes back to the IDEs available. I'd always taken this as more of a personal preference than any kind of Fundamental Law, and maybe that (personal preference) is how many people mean it. However, listening to some at QCon it's starting to border on the latter, which really started me thinking.
Maybe it's just me, but I've never consciously factored in the question "Can I refactor my code?" when choosing a language for a particular problem. I think that's because when I started using computers you only had batch processing (OK, when I really started we were using punch card and paper-tape, but let's gloss over that one). Time between submitting and compiling was typically half an hour, not including the 6 floors you had to descend (and subsequently ascend). So you tried to get your programs correct as quickly as possible, or developed very good calf muscles! Refactoring wasn't possible back then, but even if it was I don't think most of us would have bothered because of the batch system implications.
I try (and fail sometimes) to get the structure of my programs right at the start, so even today I typically don't make use of refactoring in my IDE. (Hey, it's only recently that I stopped using emacs as my de-facto editor, just to shut up others!) But this is where I came in: it's a personal thing. Your mileage may vary and whatever you need to do to help you get by is fine, surely? Why should it be the subject of yet another fierce industry battle? Are we really so short of things to do that we have to create these sorts of opportunities?
Oh well, time to take the day off.
Maybe it's just me, but I've never consciously factored in the question "Can I refactor my code?" when choosing a language for a particular problem. I think that's because when I started using computers you only had batch processing (OK, when I really started we were using punch card and paper-tape, but let's gloss over that one). Time between submitting and compiling was typically half an hour, not including the 6 floors you had to descend (and subsequently ascend). So you tried to get your programs correct as quickly as possible, or developed very good calf muscles! Refactoring wasn't possible back then, but even if it was I don't think most of us would have bothered because of the batch system implications.
I try (and fail sometimes) to get the structure of my programs right at the start, so even today I typically don't make use of refactoring in my IDE. (Hey, it's only recently that I stopped using emacs as my de-facto editor, just to shut up others!) But this is where I came in: it's a personal thing. Your mileage may vary and whatever you need to do to help you get by is fine, surely? Why should it be the subject of yet another fierce industry battle? Are we really so short of things to do that we have to create these sorts of opportunities?
Oh well, time to take the day off.
Subscribe to:
Posts (Atom)