Random Stuff Stefan Tilkov’s Weblog

The good folks at Parleys have published a video of my talk at Devoxx '08; watch it and be impressed by their super-slick viewer application. I put up the slides (12 MB PDF) a while ago.

Paul Downey's slides with explanations just rock.

I did an introductory session on REST at SEACON today – pretty much the stuff I've been talking about for quite some time now. There was a twist, though: The projector (or my laptop, or the connection between them) didn't work, so I fiddled around with it for a minute, and then decided to do the talk without slide support.

Interestingly, I think it went better than usual – I knew exactly what I wanted to say, and I didn't feel the need to get through any material. Feedback indicated that the audience liked it, too.

Maybe I should do this more often. Slides – even if they're not text-oriented bullet point catastrophes – may be overrated.

Update: Here are the slides in case you're interested (in fact, it's only the part that I think I covered).

Arnon Rotem-Gal-Oz has a nice blog entry on RETRO (the whole rest-discuss thread is also neatly summarized by Mark Little for InfoQ):

On the good side, I have to say, it is one of the best RESTful models I’ve seen thus far. The authors took special care to satisfy the different REST constraints, unlike many “RESTful” services (e.g. twitter that returns identifier and not URIs).

I agree, this is a very well-though out solution.

On the downside is I think a distributed transaction model is bad for REST or in other words I don’t see a reason for going through this effort and jumping through all these hoops.

I tend to agree — I'm not at all sure we need standardization here.

Since using hypermedia as the engine of state change means that the hypermedia actually describes the protocol, we clutter the business representations (the representations of real business entities like customer, order etc.) with transactional nitty-gritty.

Now this is something I don't agree with — if it's done, this is the way to do it; not hiding the details somewhere else.

It seems to me that RETRO is a good mental exercise to show transactions can be RESTful. I think, however that it is an overkill for RESTful implementations.

I agree again. In my opinion, transactions in REST should be a pattern, not an implementation (see this entry for some motivation for this).

At QCon London this year, I did an interview with Ian Robinson and Jim Webber. It was pretty hard for me to not step out of the interviewer role as of course everything they said was just plain wrong!

Seriously though, I think this was very interesting, and I do in fact agree with almost everything. One thing I have a different opinion about is that I think the REST community should be grateful for the REST posse (or "REST djihadists", as I believe Jim likes to call them) – IMO, they saved REST from suffering a Betamax fate.

Joe Gregorio:

Color me shocked, but IBM has just rolled out a cloud computing offering.

Be sure to check out Joe's description of the process for trying it out.

Martin Fowler:

ThoughtWorks started using Ruby for production projects in 2006, from then till the end of 2008 we had done 41 ruby projects. In preparation for a talk at QCon I surveyed these projects to examine what lessons we can draw from the experience. I describe our thoughts so far on common questions about Ruby's productivity, speed and maintainability. So far our conclusions are that Ruby is a viable platform that should be seriously considered for many forms of applications - in particular web applications using Ruby on Rails. I also go through some technical lessons, including some thoughts on testing with Active Record.

Just keeping this around for reference.

William Vambenepe:

I have given up, at least for now, on understanding what Microsoft wants Oslo (and more specifically the “M” part) to be. I used to pull my hair reading inconsistent articles and interviews about what M tries to be (graphical programming! DSL! IT models! generic parser! application components! workflow! SOA framework! generic data layer! SQL/T-SQL for dummies! JSON replacement! all of the above!). Douglas Purdy makes a valiant 4-part effort (1, 2, 3, 4) but it’s still not crisp enough for my small brain. Even David Chapell, explainer extraordinaire, seems to throw up his hands (“a modeling platform that can be applied in lots of different ways”, which BTW is the most exact, if vague, description I’ve heard).

James Clark:

The question at the back of my mind before I went was "Does M really have the potential in the long term to be an interesting and useful alternative to XML?". My tentative answer is yes.

I can't help wondering whether something that can replace both RDF and XML (and basically any kind of modeling language, too) might be just a little bit too generic.

By far the most RESTful (or maybe REST-compatible?) transaction proposal I’ve seen so far comes from Alexandros Marinos, Amir Razavi, Sotiris Moschoyiannis, and Paul Krause: RETRO: A RESTful Transaction Model (PDF). This is really cool work.

Alex Popescu, who is InfoQ.com's chief architect, makes a case for using a relational database without schemas:

By now the solution should become quite obvious: instead of persisting the object by storing it field by field, we would just serialize the whole object with all its properties. Basically, the table will need just 2 fields: an ID and a field that can store our serialized object.

I'm usually a big fan of Alex's work and agree with almost everything he writes – but this time I couldn't disagree more: Using an RDBMS in this way is an abuse IMO, and in fact one of the examples I use as an anti-pattern when I rent about HTTP abuse. I know it's in no way cool to say so, but I'm in fact a big fan of relational databases. As with any technology, they're not always a good match, but in very many cases they are. (You might think you need a fast reliable replicated high-performance clustered key-value storage engine, but you're probably wrong as long as your app doesn't have a few hundred thousand users. [Which I admit InfoQ.com has, but I'm not sure that was Alex's context here.])

Relational databases make sense when I can actually use them the way they were supposed to be used - namely, with the flexibility to select, filter, combine, update and delete available information in tabular form. If you can't do meaningful SELECTs anymore, why would you want to use a relational database?