So I got in touch with two of the most respected Clojure folks in Europe, Christophe Grand and Lau B. Jensen, and asked them whether they'd be interested in doing one of their conj-labs trainings in Germany. And they agreed in exchange for my promise to help them a little with regards to marketing it around here. Which I've gladly agreed to do :-)

So, mark the date: From 26 to 28 October, Frankfurt will be the place to learn about one of the coolest programming languages on the planet. What are you waiting for? Find out more, register now, and please help spread the word.

(Next up: A bunch of good reasons in German to use to help convincing your boss, if you happen to have one – stay tuned.)

• Does the framework respect that an HTTP message does not only consist of a URI? I.e., is dispatch done at least based on the HTTP verb, the URI, the Content-type and Accept headers?
• Can I easily use the same business logic while returning different content types in the response?
• Is there support for checking for conditional requests?
• Are ETags calculated automatically if none are set by the backend logic?
• Can I (as a framework user) easily read all HTTP request headers?
• Can I easily set all HTTP response headers?
• Can I use custom HTTP verbs?
• Is it obvious and easy how to return correct status codes with responses, and does the framework use them correctly (if it does so at all)?

Update: Two aspects added due to feedback by Erik Mogensen and Mike Amundsen:

• Is there an easy way to produce links that "point back" resources identified by whatever means the framework exposes (such as some form of routing)?
• Are resources identified and requests dispatched to code by the full URI, or is there an artificial distinction between the path and query parameters?

Along the same lines, here are some questions where a "Yes" indicates that a framework doesn't do things the way they're supposed to be done:

• Are GET, POST and other requests to the same URI dispatched to the same business logic by default?
• Am I required to use "extensions" (e.g. ".xml", ".json") to get different representations of the same resource? (Supporting this optionally is OK.)
• Are there method names in the URI?

Finally, I wonder whether there's any justification for a web framework to support "REST services" as an addition instead of the default, but I'm reluctant to put this into the second list.

Suggestions for extending the list are welcome.

He also provided an explanation of the terminology used; I've expanded it a little for the big-O-challenged (such as me):

• constant means O(1) complexity, in other words, the time required for the operation is constant and independent of the number of elements contained in the collection. If you think of s simple linked list, you can imagine that adding something to its front always involves the same number of steps, regardless of the number of elements. This is the fastest you can hope for.
• linear is the slowest that can happen (in the Clojure libs, that is): This is O(n) complexity, meaning that the time required for applying this function on a list with 1000 elements will take a 100 times as long as applying it to a list of 10. In other words: this is slow.
• logarithmic means that the time required requires log n hops, which is pretty fast (e.g. doing this operation on a list of 1,000,000 items takes 6 times as long as doing it on a list with 10)
• near-constant performance characteristics refer to the places where the underlying tree structure for most (all?) of Clojure's collections shows its benefits: The number of hops required (as Rich puts it) is log32 n. (Update: I've erased the naïve explanation I had here, will follow up with a better one soon.)
• Some operations are, of course not supported on some structures.

On a related note, the Clojure IRC channel is simply great.

Dilbert was probably in second place for the most stolen item of the past 20 years, at least by businesses. (Money was in first place.) And who could blame anyone for using Dilbert without permission? I would have done the same thing. Humans have some sort of hardwired sense of rightness, and stealing something that's too much of a hassle to purchase legally feels okay to most people. I feel exactly the same way.

I object to the use of the word "stealing", but he's right anyway.

I fear that Java will have to be abandoned to the "Enterprise Development" world. It will be relegated to the hands of cut-rate business coders bashing out their gray business applications for $30 / hour. We've passed the tipping point on this one. We used to joke that Java would be the next COBOL, but that doesn't seem as funny now that it's true. Java will continue to exist. Millions of lines of it will be written each year. It won't be the driver of innovation, though. As individual programmers, I'd recommend that you learn another language immediately and differentiate yourself from the hordes of low-skill, low-rent outsource coders that will service the mainstream Java consumer.

I don't see things quite as drastic as this, but I totally agree that knowing Java as your only language is no longer enough. (Be sure to check out the whole piece, full of interesting predictions).

UDDI is dead. As in, you know, not pinin', passed on, is no more, ceased to be, expired and gone to meet 'is maker.

It started out as a global directory; visions of global e-commerce driven by dynamically emerging business relations, where a small producer of some fancy local specialty becomes listed on a large retailers Web site simply by publishing its services to the global yellow pages, which are operated for the greater good of the world by some of the most important e-commerce companies (IBM, Microsoft, SAP and Ariba, IIRC).

Yeah, right.

In what can only be termed an absolutely stunning example of 'spin', the operators of this global directory, which only ever contained hello world examples and other crap left there by people playing around with it before quickly finding better ways to spend their time, shut it down after it had failed too hard to ignore this fact, and then declared it a success! It was only an experiment to prove how well UDDI works, which was of course always intended for company-internal use only.

So maybe this is the role for UDDI -- support SOA governance within an organization, offering a standardized way to catalog one's metadata, including ways categorize it in multiple dimensions, using a simply, yet extensible data model that is universally accepted, leading to excellent interoperability between vendors ...?

No.

Never mind that UDDI is the most horrible spec ever written - 420 pages stuffed with entirely useless new terminology, describing what should be a very, very simple CRUD API in as complex a way as possible. Never mind that one could have done the same thing using a simple REST API, and Paul Prescod showed how to do that in 2002 (sadly I'm unable to dig up a link). Ignore the fact that as soon as you use UDDI for something useful, you have to customize it in a non-interoperable way, making the standards argument mute.

More importantly, there is no vendor left who cares about it. The standard isn't being extended, there is no working group, there are no new initiatives, and even if you are a strong believer in SOA governance and associated tools, you'll find out that most of them no longer use UDDI (except as a checkbox feature).

The very simple fact is: You don't have to be a RESTafarian to come to the conclusion that UDDI is, indeed, dead.

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

That's pretty great news, even though it will probably take some time before you can actually gain much of a benefit from it. Until now, there were two options of dealing with resource creation (and update, for that matter):

• Use a POST to create a new resource when you want the server to determine the URI of the new resource
• Use a PUT to do a full update of a resource (or create if it's not there already)

Sometimes, though, what you're looking for is a partial update. You have a bunch of different choices: You can design overlapping resources so that one of them reflects the part you're interested in, and do a PUT on that; or you can use POST, which is so unrestricted it can essentially mean anything.

With PATCH, you have a standardized protocol-level verb that expresses the intent of a partial update. That's nice, but its success depends on two factors:

• The availability of standardized patch formats that can be re-used independently of the application
• The support for the verb in terms of infrastructure, specifically intermediaries and programming toolkits

In any case, I will definitely start advocating its use for the purpose it's been intended to support, even if this means going with home-grown patch formats for some time: It's still better than POST, and using some sort of x-http-method-override-style workaround should work nicely if needed.

Kudos to James Snell for investing the time and energy to take this up.

But how would the fundamental experience of the device suffer if Apple shipped a dev environment with the iPad, just like one used to be part of every home computer (incl. the Apple II)? Is that really an inconceivable proposition? Or heck, it could be a $20 download on the App Store for all I care. That’s no hurdle for a teenager, not even a big one for a preteen. Why must the iPad require a dev licence and a Mac to write code for? (Obviously: because that makes Apple a lot of money.)

Anybody can build a development environment for the iPad/iPhone, this seems to be just a matter of enough commercial interest or enough open source enthusiasts to combine their forces. The real problem is the fact that the only way to get software onto an iPad is through the AppStore. I don't even believe it should be Apple who address the development environment aspect; I'm pretty sure that there'd be a great option for somebody else to build an awesome environment, perhaps based on a modern dynamic language, and this could be hosted on any platform to produce applications for the iPad. But you wouldn't be able to install the development environment itself to the iPad, as the AppStore approval policy explicitly forbids installation of any sort of interpreter, nor could you install applications built with it unless they go through the AppStore.

Apple's reasons for insisting on the AppStore as the only delivery method are understandable from a commercial point of view, at least for now. But ultimately, they'll harm both the users and Apple itself – which makes me pretty sure this will change – who knows, maybe even the first generation of the iPad OS will allow the user to install applications via some other means than the AppStore. My guess is that Apple will wait until they have a very firm position, similar to the way the dropped DRM from iTunes music once they no longer had to rely on it.

Until then, at least there's the set of interpreters built into Mobile Safari …

One line of reasoning that I don't really buy into, though, is the one related to "tinkering". As Alex Payne writes:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

I have some sympathy for these feelings because I have similar personal experience. But the whole things smells a little like complaining about not being able to tinker with your car anymore. The level of detailed fiddling you can do with any sort of device that becomes mainstream has been going down steadily – while my grandfather probably could have repaired a mild engine damage without too many problems, I'm pretty sure not too many people do this anymore today. I believe it's fine to be able to tinker on a totally different level, even if it's in the form of Web apps that run locally. The hypothetical development environment on the iPad – can you imagine what kind of Scratch one could build? – would be more than enough of a compensation from my point of view.

The feeling I understand not at all, though, is the one expressed by Tim Bray:

It’s probably a pretty sweet tool for consuming media, even given the unfortunate 4:3 aspect ratio. And consuming media is obviously a big deal for a whole lot of people.

For creative people, this device is nothing.

Given the fact that I expect there to be millions of people who'll use an iPad to write, and paint, and sketch, using a multitude of applications built for the purpose, I beg to disagree.