I spent the weekend in San Diego and I'm now writing this down on the return flight. I've been meaning to check that city out for a while now, and finally this weekend flights were offered at the right times, for the right price.

I was stuck in a phone screen late Friday afternoon (I asked the candidate if she had any questions for me, and yes, yes she did) but I had no problem making my 7:15 flight without resorting to a $30 taxi. While boarding the plane, the crew announced that due to possible fog in San Diego we may actually end up landing somewhere else like LAX or Palm Springs. Initially, I thought it was just the discount-airline crew joking around, but the announcement continued: If our flight did end up at some other southern California airport, meals/rooms/ground transportation to our actual destination would *not* be provided. So, if you couldn't cope with this contingency, you should get off the plane now! In the end nobody got off, and it was a foggy landing, but evidently not too foggy ... Still, what a policy, ALASKA AIRLINES!

Upon arrival, I decided to pass on the rental car that was included in my weekend package. My experience is that the car always ends up sitting in a lot the whole weekend even while you pay $40 a day in insurance and parking. Instead I took a cab to Ocean Beach and the Ocean Beach International Hostel where I paid $32 for two nights.

OBIH is located on Ocean Beach's 'strip' called Newport. Surf shops, greasy diners, bars, Mexican cantinas, T-shirt and tourist crap stores are all conveniently in the neighbourhood. At the end of the strip is a place where a lot of people who live in their cars park, and the beach! The beach is actually very nice and home to "California's Longest Pier" and "America's First Off-leash Dog Beach."

I only witnessed one real instance of hostel-drama. Details are sketchy but apparantly a large, loud, and angry hostel resident and self-described mental patient flipped out because ... well, as I said details are sketchy. There was some yelling and allegedly a chess piece from the board on front porch was thrown at a passer by. The cops were called and *six* of them arrived to ensure his ejection from the hostel went smoothly. Having the police show up really completed the socal experience as I know it from watching "COPS" -- it all seemed very authentic. ... 15 minutes after it was all over, the stoner-types emerged onto the porch to inquire "Dude, are the cops still here?"

There were really two highlights of the trip. First, sun. SD's reliably sunny weather a nice change from Seattle, but down there the sun provides not only lightbut heat! It was really nice to *feel* the sun in January.

Although Ocean beach was nice, the second real highlight were the 'cliffs' south of the beach, past the pier. The cliffs were not real cliffs, but the constantly eroding hard sandstone shore. The stone was strong enough to walk on but you could easily break off a ledge with your weight or make a mark in it with a rock. The fine was $250 for carving your name or anything else into the cliffs but that didn't seem to deter anybody. On Sunday morning, my counter-mate at the breakfast diner warned me that the cliffs were the den of the homeless and their drug dealers but ... they all seemed nice. The erosion was really cool. It produced mini-beaches surrounded on all sides by rock, and caves that the water had carved through the cliffs.

Final unrelated thought: Amazon has a funny looking hardware VPN device that "conveniently" velcros to the screen-back of the corporate-issue black HP laptop. Even when the VPN device is not in use, the vecro attachments remain. This makes fellow Amazonians easy to spot in airports and on planes. When this happens, like right now with this guy a few rows up from me, I think it's fun to just say "Amazon!" in their general direction and see what happens. Let's try ...

Today my friend Nick and I went snowshoeing near Paradise in Mount Rainier National Park. No photos to post, unfortunately, but they wouldn't have been that interesting anyway because we were basically hiking around inside a cloud. Visibility was near zero, a white-out if you will. If you threw a snowball, it would disappear into the whiteness before you saw it hit the ground. I'm actually a little surprised we didn't get lost up there ...

Wow. Two articles published on xml.com today about Amazon's Simple Queue Service. I'm a developer on this project so it's really exciting to see people writing about it.

In short, SQS is a message queue, designed for scalability and reliability, hosted in Amazon's datacenters, and accessed using web services.

Fun With Amazon's Simple Queue Service is a friendly introduction to the API and includes a sample chat application written in javascript.

How RESTful is Amazon's Simple Queue Service? is an article critical of our REST API. REST stands for REpresentational State Transfer, and is "an architectural style for large-scale software design". The author's answer to his rhetorical title is of course "not very." Point well taken. I (personally) agree that we shouldn't refer to our "HTTP GET with parameters in URL" version of the API as "REST". However, I also don't think we should change it to be more RESTful according to this author's suggestions. Keeping the service simple and accessible to new developers is one big reason. Everyone knows how to use a browser and even the most novice developer can construct a URL to make an ad-hoc call to try out any AWS API. His or her browser will then nicely render the response XML, or he or she could apply a server-side stylesheet and transform it into anything at all. However, far fewer people understand the various HTTP methods or could issue an ad-hoc query as quickly and easily against a "true" REST API. (A previous xml.com article suggests using telnet ...)

Levitt, in the first article linked to above, illustrates my point perfectly:

Using Amazon's REST interface, I could demonstrate the entire API without using a programming language at all. That's because Amazon chose to implement SQS using only HTTP GET requests (no PUTs, DELETEs, or POSTs). I could simply construct the appropriate URLs and put them into my favorite web browser to execute them. While some might disagree with this design about Amazon's non-RESTy choice to use only HTTP GETs for SQS, the fact is that it makes life very simple for developers.

Despite all this, I found Joe's proposed 'more RESTful reformulation' of SQS very interesting. I feel more enlightened about the REST philosophy after reading his article, but I'd like to point out a problem with his proposal. One of the article's main critcisms of SQS's REST API is the use of HTTP GET for all operations:

The Amazon Queue Service does everything through GET, and no, that's not a good thing ... There are some operations that should use GET. ListMyQueues and Read are both perfectly good GET candidates as they only return information. The problem with the other five operations is that GET is supposed to be both “safe” and “idempotent.” The terms “safe” and “idempotent” have particular meanings for HTTP. “Safe” means that GET does not have the significance of taking an action other than retrieval. “Idempotence” means that the side-effects of N identical requests are the same as for a single request.

Actually, every operation in every AWS service including SQS can be accessed by both GET and POST. We accept them both so go ahead and use whichever one makes you happiest! But more importantly, this author is mistaken about the semantics of Read.

SQS is designed to support many processes concurrently consuming messages from a single logical queue. If Read always returned the message at the top of the queue, as the article assumes, concurrent readers would duplicate the processing of most messages. Instead, what concurrent readers usually want is to divide up the queue traffic among them. This way you can scale up your message processing capacity simply by adding more readers. To permit this, a Read from the queue actually locks the message read for a limited time while the consumer processes it. By 'lock' I mean that a subsequent Read against the same queue within this limited time period will retrieve (and similarly lock) the next entry in the queue, even though the first entry appears first and hasn't yet been dequeued.

So while SQS's Read is exactly what concurrent queue consumers want, it is neither "safe" nor "idempotent" and therefore according to Gregorio should not be a GET. Since none of the other HTTP methods (HEAD, POST, PUT, DELETE) capture the sematics of SQS's locking Read, no API that Amazon could design would satisfy the REST zealots. If we had to choose one method for READ, GET would probably be the most appropriate, but my point is that not every useful operation can be expressed in the REST/HTTP world. Rather than being limited by the methods that HTTP offers, we simply use HTTP as the transport and build whatever operations we care to dream up on top of it.

P.S. Gregorio is not the first to propose a more RESTful queue API. A design and implementation in python was published here just a few days after our initial launch.

Some house-shares entail just a little too much "sharing" for my taste:

Seattle Craigslist Rooms & Shares: $520+ Includes Rent, Util, and Food: Co-Op on Captol Hill

One room available ... in a beautiful 1908 mansion with 15 bedrooms, lots of common space ... Our dues are: A base amount of $375.00 + $140.00 for food + a 'tax' (which is a form of income sharing) of 7% of income minus base dues, food, healthcare premiums and retirement deposits. Dues pay for just about all of your needs: vegetarian food, utilities, household supplies (including cleaning supplies and most basic personal needs), internet, phone, and subscriptions ...

Just when you're about to slit your wrists ...

... A clear sunny blue-skied day like today comes along and cheers you up.

In order to take advantage, I picked up a book covering 'winter' hikes near Seattle (describing trails that aren't closed for the season or made un-hikable by snow) and drove up with Matt to a place called Blue Mountain.

The book says that it's possible to drive a regular car right up the steep gravel road to the summit, and the Neon was ready to prove that fact except the road got really icy so after a certain point we just stopped moving forward and started sliding backwards. We parked at the edge of where the ice started and a short but slippery walk later we were at the top enjoying clear views in almost every direction. We could even just barely see the tallest of Seattle's buildings 100 kilometers away.

Really the best of this hike was there at the summit only a few minutes walk from the car, but not knowing this, Matt and I blew the next few hours trudging through the snow following a trail walled by trees on both sides that led pretty much nowhere (and then back again).

One funny thing that we noticed is that people out there in backwoods Washington really like to play with their guns. I say this because it didn't seem like there was a lot of hunting going on (our only encounter with wildlife was a hidden drain pipe whose irregular flow sounded like an animal splashing in a stream) but we saw so many groups parked on the side of the road just, like, shooting at stuff. We gawked at them from the car and they gave us back the kind of look that you give to people in Neons with Manitoba plates when you're holding your rifle and leaning up against your truck. On the trail, shotgun shells and beer cans were littered everywhere and there was a constant echo of semi-automatic gunfire from the valley below. The metal gate guarding the fireroad we walked down had a bullet hole through every square inch of it's surface.

We headed home after dark, coasting down the slipery road in neutral, back towards civilization.

• Go for breakfast at Broadway Grill, 2 units
• Walk around Frink park near Lake Washington, 3 units
• Get dinner at Red Line, 1 unit
• Talk with Jen on the phone, 2 units
• Watch an episode of The Sopranos, 2 units