Random Stuff Stefan Tilkov’s Weblog

It's no secret that I've become I big fan of Clojure in the last year or so. I've done three talks, collaborated on a series of print articles (part 1, 2 and 3) and an online article to promote it as much as I can, and I think I made up with enthusiasm for my lack of practical experience. But I'm definitely not experienced enough with the language to do a multi-day workshop that would stand up to some tough questions. On the contrary, in fact I'd love to attend an advanced workshop done by some really smart folks who have more than introductory-level knowledge.

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.)

InfoQ has put up a video of my QCon London presentation. Too bad the animations in the slides aren't included -- spoils some of the fun.

I recently thought about what to expect in a web framework that claims to have "REST support", and came up with a list of questions that one should ask to see whether such a claim is justified:

• 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.

Together with Mathias Meyer and Markus Völter I recently recorded a SoftwareArchitekTOUR podcast on NoSQL data stores; heise.de has put it online now. It was great to have Mathias on the show, not only did he clearly know three times more about the topic than Markus and I combined, he also added a nice additional dialect to our portfolio …

At QCon London, Sadek Dobri interviewed me on REST – this was a nice chance for me to voice my current thinking about most, if not all things RESTful. InfoQ has put the video up online.

I've uploaded the slides from today's Clojure talk. As usual, comments are welcome.

Jarkko Oranen a.k.a. Chousuke posted an excellent table summarizing the performance characteristics of functions operating on different Clojure data structures:

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.

Scott Adams phrases the only reason I occasionally download stuff illegally:

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.

Michael Nygard:

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).

It does no longer come as a surprise to anyone when I criticize the SOAP/WSDL/WS-* variant of Web services, but in the last couple of weeks I've been in a few discussions where one particular piece of technology came up for discussion: UDDI, Universal Description, Dicovery and Integration, an official OASIS standard, at version 3.0.2 since February 2005. In the course of these discussions, I still saw a few eyebrows raised when I explained what I consider to be the obvious:

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.