subbu.org

BTC 2009

2009-06-29T00:50:14Z

I just came back from the 2009 Bicycle Tour of Colorado. This was a 515 mile long (excluding an optional segment to the Colorado National Monument) loop ride from Glenwood Springs, Colorado with over 1700 other riders from all around US and a few other countries. We started the ride on June 21 from Glenwood Springs, and went through Hotchkiss, Grand Junction, Montrose, Crested Butte and Buena Vista/Leadville. Overall, I climbed over 27000 ft, and three passes – McClure Pass, Cottonwood Pass, and Independence Pass. Another massive climb was to the Grand Mesa near Grand Junction, which is the largest mesa in the world. Here are the logs and pictures.

Day 1: Glenwood Springs to Hotchkiss, 84 miles, 3700 ft climb
Day 2: Hotchkiss to Grand Junction, 94 miles, 6600 ft climb
Day 3: Grand Junction to Montrose, 69 miles, 2500 ft climb
Day 4: Montrose to Crested Butte, 96 miles, 6200 ft climb
Day 5 – rest day in Crested Butte
Day 6: Crested Butte to Buena Vista, 77 miles, 5000 ft climb
Day 7: Leadville to Glenwood Springs, 97 miles, 3700 ft climb

I took most of the pictures while riding, which explains why most shots show backs of riders ahead of me.

Caching Chapter

2009-05-25T15:54:55Z

Here is a post on our thoughts on the chapter on caching for our RESTful Web Services Cookbook.

Let us know if you have any comments.

Orca Hurt

2009-05-25T15:51:27Z

My bike, hurt but still standing after yesterday’s crash.

The right shifter looks bad. Both the levers are damaged. The front break assembly is bent. The fork and the front wheel seem alright, as I was able to ride for 15 more miles with the front break assembly disengaged. It is going to the shop today.

Atom Is Not SOAP

2009-04-30T16:45:14Z

After reading Stefan’s agreement and Mike’s observation that Atom is "too widespread" in some cases, I can't help but add that, Atom isn't SOAP.

In order to build interoperable distributed systems over HTTP, there is no need for a general purpose envelope format other than what HTTP provides. HTTP gives us a format with representation metadata (i.e. headers) and a message body. That is as general purpose as we can get.

Atom as a General Purpose Format

2009-04-30T06:44:55Z

A format is just what it is – a format. Dare Obasanjo recently commented that "the Atom syndication format has been as successful or perhaps even more successful than originally intended because it’s original scenarios are still fairly relevant on today’s Web". True. This format is relevant for what it was designed for. However, there has been a slow trend to use Atom as a general purpose payload format for RESTful applications. One of the arguments that gets used is that, standardizing on such a format makes all services consistent and easy to use. This approach, IMO, is suboptimal, and the benefits of doing so are, in some cases, pedantic.

A case in point is Google’s Code Search Data API that I looked at recently. This API uses the Atom Syndication Format. A GET request to a URI such as http://www.google.com/codesearch/feeds/search?q=atom returns an Atom feed document. Each entry in this entry is a code search result, which looks like the following.

<entry>
    <id>http://www.google.com/codesearch/p?hl=en#zhw7s4tDL7M/IssueDealerWeblog/atom.py<id>
    <updated>2009-04-29T19:34:24Z<updated>
    <author>
      <name>Code owned by external author.<name>
    <author>
    <title type="text">IssueDealerWeblog/atom.py<title>
    <link rel="alternate" type="text/html"
          href="http://www.google.com/codesearch/p?hl=en#zhw7s4tDL7M/IssueDealerWeblog/atom.py&q=atom"/>
    <gcs:package
        name="http://freshmeat.net/redir/issuedealer/38032/url_tgz/IssueDealer-0.9.120.tar.gz"
        uri="http://freshmeat.net/redir/issuedealer/38032/url_tgz/IssueDealer-0.9.120.tar.gz">lt;gcs:package>
    <gcs:file name="IssueDealerWeblog/atom.py">lt;gcs:file>
    <content type="text/html">lt;pre> 61: class <b>atom</b>(
      OFS.Folder.Folder,
      </pre><content>
    <gcs:match lineNumber="43" type="text/html">lt;pre>class <b>atom</b>_entry:
      </pre><gcs:match>
    <gcs:match lineNumber="61" type="text/html">lt;pre>class <b>atom</b>(
      </pre><gcs:match>
    <gcs:match lineNumber="119" type="text/html">lt;pre> arguments_ = REQUEST['PATH_INFO'][REQUEST['PATH_INFO'].rfind('/<b>atom</b>')+6:].split('/')
      </pre><gcs:match>
    <gcs:match lineNumber="148" type="text/html">lt;pre> """<?xml version="1.0"
      encoding="UTF-8"?><feed xmlns="http://purl.org/<b>atom</b>/ns#">"""
      + \
      </pre><gcs:match>
    <gcs:match lineNumber="149" type="text/html">lt;pre> """<link rel="service.post"
      href="%s" type="application/x.<b>atom</b>+xml" title="%s"
      />""" % (
      </pre><gcs:match>
    <gcs:match lineNumber="150" type="text/html">lt;pre> self.getParentNode().get_weblog_url() +
      '/<b>atom</b>', escape(self.getParentNode().get_title())) + \
      </pre><gcs:match>
    <gcs:match lineNumber="151" type="text/html">lt;pre> """<link rel="service.feed"
      href="%s" type="application/x.<b>atom</b>+xml" title="%s"
      />""" % (
      </pre><gcs:match>
    <gcs:match lineNumber="152" type="text/html">lt;pre> self.getParentNode().get_weblog_url() +
      '/<b>atom</b>.xml', escape(self.getParentNode().get_title()))
      </pre><gcs:match>
    <gcs:match lineNumber="153" type="text/html">lt;pre> self.REQUEST.RESPONSE.setHeader('content-type',
      'application/x.<b>atom</b>+xml')
      </pre><gcs:match>
    <rights>GPL<rights>
  <entry>

In this entry, almost everything that the client cares about is an extension, i.e. an element in the "http://schemas.google.com/codesearch/2006" namespace. A general purpose feed reader or feed API won’t be able to make much sense from this.

The fact that this representation had to rely on extensions so heavily makes me wonder of the benefits of using the Atom Syndication Format for this representation. Of course, it is entirely possible to argue that, any general purpose feed reader or Atom client can interpret the Atom-specific elements in this entry, and "value-added" clients can interpret the extensions to provide more features. It is true. But this argument is not strong enough.

I am not undermining Atom's built in extensibility to support arbitrary content (under atom:content), its emphasis on hyperlinks between representations and resources (via atom:link), and the abstraction of resource collections (as atom:feed). These are important characteristics for any representation format.

So, when would I consider the Atom Syndication Format? I would consider it when my resources are feeds or entries, or represent content. Even then, I would not blindly apply this format for all resources in my apps. I would reserve it for only those resources that share these characteristics. For others, I will use whatever format makes sense, including HTML, binary formats, CSV or even plain text.

Announcing RESTful Web Services Cookbook

2009-04-20T02:47:47Z

I am happy to announce that Mike Amundsen and I are writing a book titled RESTful Web Services Cookbook. This will be published by O’Reilly by the end of 2009.

See http://www.restful-webservices-cookbook.org/ for more details.

Daffodil Classic 2009

2009-04-19T22:15:45Z

Start time: Apr 19, 2009, 07:23 AM

Total distance: 63 miles

Total time: 4 hours 28 minutes

Average speed:14.0 mph

Total ascent: 2922 ft

Total descent: 2926 ft

Lots of rolling hills, farms, views of Mt Rainier, and nice weather.

That Was an AtomPub Test

2009-04-19T02:09:04Z

The previous post was meant to test AtomPub on WordPress. One of the riders at Cyclogz asked for this feature yesterday, and the previous post demonstrates that all is well.

Mt Constitution (Orcas Island)

2009-04-19T00:21:04Z

Start time: Apr 5, 2009, 09:55 AM

Total distance: 24 miles

Total time: 2 hours 43 minutes

Average speed:8.96 mph

Total ascent: 3454 ft

Total descent: 3147 ft

I started this ride at the ferry landing, and took the Orca Road up north. Then I turned right on to Main Street to Eastsound. The road up to this point is mostly rolling hills with a few short climbs. Per my GPS, the cumulative climb till here was approximately 1000 ft.

From the town, I continued east on Crescent Beach Dr, and then took a right at the Olga Road. From here till the Cascade Lake, the road climbs by approximately 400 ft. The lake is scenic, and is a great photo op.

The fun starts as you enter the Moran State Park. From here, for the next 4 miles, the climb averages 12-13% and it does not let up. It was time to shift to the granny gear. It felt a bit easier once the switchbacks get sharper at mile 16.

At about mile 19 (near the lake on the right in the map), the climb eases off finally. From here till the summit, for about 1.8 miles, the climb is gentle. This section of the road was a bit muddy with all the snow melting on the sides. The path to the observation deck was wet and snow-covered, but the views from the deck were panoramic.

The descent was quick. I ended my ride at the lake and jumped into the car as I was getting hungry.

Overall, it was great ride. I got my first respectable climb for 2009.

Supplies/Restrooms: The best place for supplies and rest rooms is the North Beach Road, off Main Street. There is also a bike shop on this road. The next place for rest rooms is the parking lot at the Cascade Lake. But these are currently “closed for winter”. Even the water fountain there is closed! At the summit there are rest rooms and a vending machine to buy colored chemical water and good old H2O.

Is “rev=canonical” a Good Idea?

2009-04-19T00:21:37Z

I agree that URL shorteners are bad for the web in the long run. Link shorteners defeat the centralized nature of the web as they introduce an external redirection service that is not in your control. When that service disappears, your resources become unreachable.

But is the rev="canonical" that is being floated now going to fix the problem? It can not.

As Ben Ramsey points out, the rev relation is ill-defined. More importantly, why not just use the short URI as the value of hrefs in the first place? I don’t get it.