Random Stuff Stefan Tilkov’s Weblog

I have to admit I wasn't aware of HTTP status code 418, "I'm a teapot".

I continue to like Ruby because of nice little gems like this:

class Object
  ##
  #   @person ? @person.name : nil
  # vs
  #   @person.try(:name)
  def try(method)
    send method if respond_to? method
  end
end

You never know: maybe one of my (German) readers is looking for a challenging Java-related (permanent) job in Stuttgart, where one of our customers has failed to find someone appropriate until now. If you want to help build up a team that creates a company-wide SOA, using Java, Spring, Web services, open source tools, and integrates the whole thing with an SAP ERP installation, drop me an email.

An excellent paper (PDF? Why?) by Michael Kay about the performance of his Saxon XQuery processor [via James Clark]. Favorite excerpt:

• Investigate every user-supplied performance problem in depth. There is no better raw material for under- standing how the code behaves, and without such understanding there can be no improvement.
• Optimize the code that typical users write, whether it is well-written code or not. Try to educate users on how to write code that works well on your product, but recognize that you will only reach a small minority.
• Never make performance improvements to the code without measuring the impact. If you cannot measure a positive impact, revert the change (easily said, but psychologically very difficult when you’ve put a lot of effort in). Keep records of what you learnt in the process.
• Avoid performance improvements that rely on user-controlled switches. Most users (including people who publish comparative benchmarks) will never discover the switch exists; of the remainder, a good number will set the switch sub-optimally.
• Remember that every optimization you make to your code is likely to require a substantial investment in new test material, and even then, is likely to result in several new bugs escaping into the field. Do not do it unless the gain is worth it.
• Maintain a set of performance regression tests to ensure that performance gains made in one release are not lost in the next.
• Separately, maintain tests to show that query optimizations are taking place as intended. In Saxon this is done by outputting an XML representation of the query execution plan for test queries, and checking assertions about these plans expressed as auxiliary queries.

Zen and the Art of Ruby Programming:

DB2 Express-C for Mac OS X Leopard will finally be shipping out (before Christmas), in all likelihood it could be as soon as early next week.

Smart move – I don't expect anyone will actually run DB2 on a Mac for production, but it's obvious that the chance of developers using it increases significantly. I don't have any numbers, but I would assume that most Mac developers run their production systems on some flavor of Linux.

Patrick Logan points to an article containing this example:

function quoteWords()
{
     return array_map('quoteWordsHelper',
            function ($string) {
                return preg_replace('/(\w)/','"$1"',$string);
            });
}

There's little doubt lambda functions and closures have become mainstream if they're in PHP :-)

One of the claims often made against REST is that there's a lot of disagreement around it – that nobody can define whether something is RESTful or not.

I was reminded of this in a recent discussion, and I claim it's bullshit. The REST community actually very easily agrees on whether or not something is RESTful or not when it's put up for judgement. And the nice thing is that you can easily get very close to answering this yourself by looking at a Web API that claims to be "RESTful", and see if it really is using a few simple questions:

• Do the URIs actually identify resources, or do they encode operations?
• Are the HTTP verbs – GET, PUT, POST, DELETE – used according to their defined meaning? Or is e.g. a GET used for operations that have side effects a client would not want when following a link?
• Is hypermedia used, i.e. are there links in the representations that a client can follow?
• Are MIME types used to differentiate data types (in Accept and Content-type) headers?
• Are caching and conditional GET supported, i.e. are there appropriate cache control headers and ETags?

I claim that if you answer "yes" less than four times, your API is not RESTful. If you answer yes five times, you may still not have everything 100% correct – but you've built something that's very good compared to the average, and can have meaningful discussions about how to improve it even more.

(Check out these articles for more background: intro, rest anti-patterns.)

Duncan Cragg has put up part 7 of his REST dialogues – excellent stuff.

Twitter’s Nick Kallen:

Cache Money is a plugin for ActiveRecord that transparently provides write-through and read-through caching functionality using Memcached. With Cache Money, queries are automatically cached for you; and similarly, cache expiry happens automatically as after_save and after_destroy events.

This doesn’t just apply to trivial queries. Very complex, sophisticated queries are handled effortlessly; the vast majority of ActiveRecord usage is transparently materialized, indexed, and kept fresh in Memcached.

I’m slightly skeptical towards magic like this, but it definitely sounds interesting.

Antonio Cangiano has updated his Great Ruby Shootout because of an interesting finding (emphasis mine):

The really big, flashing warning though is what happens when you install Ruby through apt-get. Compiling from source gives you double the speed, according to these tests. I expected a 10/20% increase, not 100%. The gist of it is that prepackaged Ruby is compiled using the option –enable-pthreads and there is the whole issue of shared vs static libraries. But whatever the reason, this is a significant difference. For production use, in light of these results, I feel that it would be foolish to use the slower version of Ruby provided by apt-get/aptitude.