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).
]]>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).
]]>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.
]]>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.
]]>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.
]]>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).
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 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?
]]>Usage example:
xml.instruct! :xml, :encoding => "UTF-8"
xml.feed :xmlns => 'http://www.w3.org/2005/Atom', 'xml:base' => base_uri, 'xml:lang' => 'en-us' do
xml.link :rel => 'self', :type => 'application/atom+xml', :href => request.url
xml.link :rel => 'alternate', :type => 'text/html', :href => orders_url
will_paginate(@orders, :xml => true, :builder => xml)
xml.id orders_url
xml.title 'Feed for OM order updates'
xml.updated Order.maximum(:updated_at).iso8601
for order in @orders do
... # render entries
end
end
This will render something like this:
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-us" xml:base="http://om.example.com/">
<link type="application/atom+xml" rel="self" href="http://om.example.com/orders.atom?page=2"/>
<link type="text/html" rel="alternate" href="http://om.example.com/orders"/>
<link rel="next" href="/orders.atom?page=3"/>
<link rel="prev" href="/orders.atom?page=1"/>
<id>http://om.example.com/orders</id>
<title>Feed for OM order updates</title>
<updated>2009-04-07T07:44:56Z</updated>
In other words, use will_paginate as you would use it in HTML (the controller code can stay unchanged), and add the :xml => true option. This will make will_paginate return an XML string representation containing appropriate elements. Alternatively, you can pass in an XML builder and it will use that instead.
Works with Rails 2.3.2.
Note that my experience with git and GitHub is limited, I’m happy about suggestions on how to make this more useful. I’m also entirely satisfied if there’s a better solution and someone points me to it.
]]>