Here are some of the most interesting rides done in this state so far.
Steven's Pass: On May 31, 79 miles, 4972 ft climb. From Startup to the Steven's Pass and back, along Highway 2.
Blewett Pass: On June 8, 54 miles, 2879 ft climb. From Cle Elum to the pass and back.
Cayuse Pass and Chinook Pass Pass: On July 4, 64 miles, 4343 climb. From near Federation Park to the Chinook Pass and back, along route 410.
Flying Wheels Summer Century 2008: On June 14, 101 miles, 4164 ft climb
Issaquah to Monroe: On May 25, 66 miles, 2186 ft climb, mostly along route 203.
Mt Adams Country Bicycle Tour: On June 28, 58 miles, 5300 ft climb, near Trout Lake.
So far, I like the quality of cycling here. There are a lots of hills, in fact, I can't get pure flat rides near where I live. There are few long climbs like the above. Rain does bother sometimes and I may need to invest in another rugged bike to ride on wet roads. On the plus side, I don't need to worry about too much heat.
]]>Here is the ride profile from Cyclogz.
I started this ride about a mile before the Federation State Park along route 410. This is approximately 13 miles after leaving Enumclaw, WA. When I started riding, there was a slight drizzle, but it faded away in a few miles. From here I rode along 410 all the way up to the intersection of routes 123 and 410. Cayuse Pass is at this intersection, at approximately 4700ft. I then took a left and continued along 410 till the Chinook Pass, at approximately 5400ft.
From the Federation State Park till about mile 21, the climb was very gradual - mostly under 4%. After crossing the Mt Rainier National Park, the climb got a bit steeper - ranging from 6-8%. Along the way, the views of Mt Rainer were fantastic.
The weather patterns along the route were very interesting. Up until 27 miles, it was cloudy to partially sunny. From then onwards it became very very foggy with poor visibility. I could barely see 50-100 ft ahead of me, and my green vest kept me visible. From there, the fog continued all the way to the Chinook Pass, with a couple of Sun breaks in the middle. For the last 3 miles, the fog was so intense that I did not have a sense of direction or the switchbacks that I did climb. The slow levels along the road also increased. There was enough snow to put on snowshoes on the side trails.
The decent was great, and I could manage a modest 35mph for the first few miles. The descent tapered off after about mile 42. From there I had to start pedaling again. For about 10 miles during the descent, I got caught up in rain again, this time it was more intense.
Route 410 has wide-enough shoulder for biking. As far as water/food stops are concerned, Green River was the last place to buy things. There was a grocery store and a few coffee places in Green River. After that there were no stores along the way. There were a couple of resorts, which may have stores to buy water and energy food.
]]>No offense to the commenter, but I received such a comment when I blogged that I had performance issues with DreamHost. I did not buy the comment that Rails is slow then, and I don't buy it now. There are other things that influence scalability and these vary from case to case.
Here is another example. In response to FaceStat scales!, the first commenter asks "Why on earth didn't you use something like Grails that actually DOES scale?". I doubt if this commenter fully understands the architecture of FaceStat. To me, that is an automatic reaction, and so, I would be suspicious of that "obvious" choice that Grails or some other alternative would magically fix the scalability problems.
Say, for instance, if a PHP or a rails app is slow, an "obvious" choice is to throw memcache. But no amount of caching would rescue a poorly architected app. In fact, MySQL query caching may be sufficient for typical caching needs.
After writing the initial prototype of Cyclogz, I wanted to check if there are similar sites, and if so, how they are approaching the problem. The problem was simple - retrieve a large amount of data from a GPS, and then extract lots of info from it for both presentation and analysis purposes. I came across two sites (one of which is MotionBased, owned by Garmin). Both these sites did what seemed like an "obvious choice". Both sites upload all the data (in megabytes) to a server, store it in the database, and then kick off a background process to analyze and extract the data. This approach requires more hardware on the server side, more code to manage the background work, and more importantly, takes away instant gratification from the user. I won't describe alternatives here in detail, but better and more scalable design choices do exist. It was also fun thinking about the alternatives, and implementing those.
In the REST community, there is a similar pattern. Every now and then someone comes along with a need to do batch processing asserting that making "n" connections is slower than POSTing all requests in a single batch. When told of the problems with this approach, that person would immediately conclude that REST and/or HTTP is broken and that he/she "needs" to do batch processing.
So, if a choice seems too obvious to be incorrect, and is given by a smart but opinionated person, I say, take a step back, question and ponder. The obvious is not necessarily the best choice. The fun in writing software is figuring out those non-obvious choices. Repeating obvious choices is not fun.
]]>Yes, avoiding versioning!
Versioning is a hack and is a clever disguise to hide the fact the interface has broken its contract with its clients, and needs clients to start all over again (i.e. upgrade to a newer version of the contract).
So, please please avoid versioning. I don't care how pretty one versioning solution is over another versioning solution, if it requires clients to change their code. If it does not require clients to change their code, the changes to the interface are, after all, compatible, and hence do not require a change in the version.
]]>Oh my! What!
Someone else clarifies that:
Okay - this sounds familiar. This is REST using HTTP as the uniform interface. Let the pundits worry about labeling old wine, and I bet they are going to confuse masses yet again.
]]>That's one side of the story. The other side is repeating the same ideas with better and more flexible technology.
]]>Mike's questions are, for REST-ful applications that use JSON for representing resources, (a) "where is the hypermedia (links and forms)" and (b) "what standardized clients understand how to render these elements propertly?"
]]> As far as machine clients are concerned, (X)HTML has the advantage of a set of universal clients, a browser being the most common one, that can fully take advantage of hypermedia. In addition, browsers can render representations as well as controls to search and modify resources. But that does not mean that the goal of REST's hypermedia constraint is to allow building such automated applications.Assisted by the Atom Publishing Protocol, Atom Syndication Format has the advantage of a (smaller) set of generic clients that can deal with the hypermedia, but mostly in the blogging space. But when it comes to other applications of Atom and Atom Publishing Protocol, there are not any (at least to my knowledge) clients that can consume the hypermedia in a generic manner.
Take for example, OpenSocial, GData or Astoria where Atom feed/entry format is used to represent arbitrary resources like contacts, friends etc. In these cases, the purpose of the hypermedia is to take some guesswork out of client applications, and help client applications know how to fetch, create, modify or delete resources. For instance, client applications do not need to guess where to PUT to update a resource, or where to POST to create new resource. URIs for GET, POST, PUT and DELETE are expressed within representations of resources and collections of resources. This is hypermedia, as far as I understand it.
Now, similar information can be embedded in other media types as well, including application/json, if so desired. As far as the Atom Publishing Protocol is concerned, isn't it just "a" profile of HTTP 1.1 using RFC 4287 for expressing representations of resources?
> GET /statuses/friends.json HTTP/1.1 > Host: twitter.com > Accept: application/xml > < HTTP/1.1 200 OK < Date: Fri, 25 Apr 2008 17:06:39 GMT < Status: 200 OK < Content-Type: application/json; charset=utf-8 < Content-Length: 2 < Connection: close < * Closing connection #0 [...]
The response I get back is always of type application/json no matter what Accept header I send. What determines the response content type is the string that follows the dot in the last path segment of the request URI. That is, Twitter's representations are not negotiable in the HTTP 1.1 sense. The client needs to rely on Twitter's documentation to know that .xml at the end of the URI implies that client is asking for application/xml and not, let's say, application/atom+xml or application/json. This style of URI-based negotiation will break automated client applications that understand HTTP 1.1. Another problem with this approach is that, it forces the API to come up with new extensions for URIs for new media types, like .text, .svg and so on.
To be clear, content-negotiation in HTTP 1.1 is not complete. For instance, there is no way for a server to indicate what kind of media types it can represent a given resource in. That is, by purely relying on HTTP 1.1, a client can not discover the media types. HTML and Atom fix this via the link tag.
Most of the frustration with content negotiation is rooted in HTML. While you can indicate that alternative representations are available via the link tag for machine consumption (e.g. a blog reader to discover an Atom feed representation of my blog), you can not encode this information into a tags. That is, the following is not possible.
<a href="URI to a resource" rel="alternate" types="application/atom+xml,application/json,text/html"/>
This forces multiple representations to be explicitly encoded into HTML each with a distinct URI.
<a href="/foo.html">HTML</a> <a href="/foo.atom">Atom feed</a> <a href="/foo.atom">JSON</a>
See On Linking Alternative Representations To Enable Discovery And Publishing for more relevant discussion. As Dare Obasanjo once argued, "content negotiation has failed to take hold on the web". But that does not justify the Twitter example above. APIs like that of Twitter are mainly for machine consumption, and should implement content negotiation. A post by Frank Sommers at Artima tries to justify separate URIs for each media type so as to keep the server-side code simple, but I would argue that simplicity in server-side code can still be achieved. It just takes a little more design and discipline.
]]>application/hypermedia+json. Putting together such a new media type is not hard, but in my view, the real issue is defining a JSON format that can express data/media as well as hypermedia. One possibility is to take the "payload" formats defined by Atom and Atom Publishing Protocol, and translate that into JSON using some simple rules. Here is one, based on example from RFC 5023.
]]>
{
"entry" : {
"title" : Atom-Powered Robots Run Amok",
"id" : "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a",
"updated" : "2003-12-13T18:30:02Z",
"author" : {
"name" : "John Doe"
},
"content": "Some text.",
"link" : {
"rel" : "edit",
"href" : "http://example.org/edit/first-post.atom"
}
}
]]>
And, here are some pictures I took along the way.
A slide show will appear here shortly.
http://www.subbu.org/vide/1234 that can be updated via a PUT, ServiceReg will turn that into a GET:
http://servicereg.com/put/subbu.org/video/1234?title=Hello
This is bizarre. Why proxy POST, PUT and DELETE via a GET? As Stefan pointed out, this violates the purpose of RESTful design. But there is more to it. It masquerades all write operations as read operations, and that could lead to unintended consequences.
The motivation of ServiceReg may be to let GETs be used to replace other verbs so that URLs can be bookmarked. But still - it does not make sense.
]]>No. It should be possible to guess or interpret the nature of the resource by looking at a URI. That is, URIs are opaque to a machine dealing with the web service (unless otherwise described through a specification of the URI), but transparent to the user, like the following:
http://www.cnn.com/2008/POLITICS/04/09/clinton.iraq/index.html
An old W3C note on The use of metadata in URIs, describes the principles very well.
A related issue is resources carrying references to other resources. Consider, for example, my profile on a social networking site referring to pool of pictures uploaded by me? One common pattern is the following:
<photos page="2" pages="89" perpage="10" total="881">
<photo id="2636" owner="47058503995@N01"
secret="a123456" server="2" title="test_04"
ispublic="1" isfriend="0" isfamily="0" />
<photo id="2635" owner="47058503995@N01"
secret="b123456" server="2" title="test_03"
ispublic="0" isfriend="1" isfamily="1" />
<photo id="2633" owner="47058503995@N01"
secret="c123456" server="2" title="test_01"
ispublic="1" isfriend="0" isfamily="0" />
<photo id="2610" owner="12037949754@N01"
secret="d123456" server="2" title="00_tall"
ispublic="1" isfriend="0" isfamily="0" />
</photos>
This is used by Flickr's photos.getRecent API. In this model, the photos element is a collection of photo elements each referred to by two IDs, viz, an ID for the owner, and another ID for the photo.
To GET each of photo from this collection, the client will have to refer to another part of Flickr API documentation to learn how to construct a URI.
This is an exception to the opacity rule. Here the web service specified how to construct URIs, and so a machine client could construct URIs programmatically.
Still, this is no match for the following:
<photos page="2" pages="89" perpage="10" total="881">
<photo uri="http://farm2.static.flickr.com/2/2636_a123456.jpg"
owner="http://www.flickr.com/photos/name1"
title="test_04" ispublic="1" isfriend="0" isfamily="0" />
<photo uri="http://farm2.static.flickr.com/2/2635_b123456.jpg"
owner="http://www.flickr.com/photos/name1"
title="test_03" ispublic="0" isfriend="1" isfamily="0" />
<photo uri="http://farm2.static.flickr.com/2/2636_c123456.jpg"
owner="http://www.flickr.com/photos/name1"
title="test_01" ispublic="1" isfriend="0" isfamily="0" />
<photo uri="http://farm2.static.flickr.com/2/2636_d123456.jpg"
owner="http://www.flickr.com/photos/name1"
title="00_tall" ispublic="1" isfriend="0" isfamily="0" />
</photos>
where the URI is explicitly provided as part of the representation so that a machine client would immediately know to fetch the resource without manufacturing URIs. If a web service is providing IDs to resources only to let the client be able to construct a URI, it is better to provide the URI in stead of IDs.
How about URI Templates? URI templates serve a useful purpose by letting opaque URIs be programmable. But they should not be used to avoid serving URIs, as above.
]]>