Booking a table

This impressed me a lot, it's very slick:

GMail managed to look into this restaurant confirmation email and see that it referenced an event at a specific time, so it created a link to add to my Google Calendar!

Following the link to their website reveals, however, that reservations are done through some third-party widget that's not OpenTable.

It's a shame that restaurants in Ottawa are fracturing their reservation systems across several providers like this, just like online classifieds for the city are fractured across Kijiji, Craigslist and UsedOttawa, reducing their utility for everyone. Restaurant reservations are the sort of service where these third-party hosted reservation service providers can hugely benefit from network effects. Once one service reaches a tipping point (like it seems OpenTable is achieving in some US cities), it will enable the creation of location-aware mobile apps and a whole bunch of other useful services for finding restaurants around you.

It seems to me that as a restaurateur, you'd have see huge benefits from going with a large provider that's essentially advertising your restaurant for you by publicly listing availability of tables. You'd want to go for the dominant service that could offer this, which hasn't (yet?) happened with OpenTable in Ottawa...


That didn't take long


Wow, the Kanata Costco sells Manchego cheese now. In three years it went from unobtainable to completely mainstream.

Three years ago, you could buy some 6-month and 12-month manchego at La Bottega. If, you know, you got lucky. Very lucky. And wanted to pay about 60 bucks a kilo.

Now it's at Costco for 35$ a kilo.


Resource Acquisition over Broadcast Channels (Geek Factor: 9/10)

I've converted most of my workplace to my RABC protocol when requesting favours / equipment. Here it is:



This document provides a message-exchange pattern (MEP) for
requesting and attributing resources over a shared broadcast
channel (RABC), such as an electronic mailing list (see
RFC822, RFC2919).


This section describes the status of this document at the time
of its publication.

This document is the second public Working Draft of this spec-


The following nomenclature is defined:
Alice Requester
Bob Responder to Alice's request
Charlie Responder to Alice's request
Dave Responder to Alice's request
L Broadcast destination [email list or message board]
R Resource being requested

Note that R need not be a physical resource, it may also be a
service. Examples of common resource requests include a ride
to a place of business, a piece of networking equipment, a
driver to pick up a food order, etc.


A common anti-pattern this protocol addresses is the lack of
notification provided to non-selected responders informing
them of which offer was selected:

(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks!"

In the above example, before MESSAGE 5, Alice may or may not
have sent the private message:

(6) Alice -> Bob "Thanks, I'm using yours"

Charlie and Dave are now left wondering if the thanks was di-
rected to them, and if not, which offer was accepted. From
their point of view, MESSAGE 5 was ambiguous.


The only change required to the above pathological scenario is
for MESSAGE 5 to include an extra identifier. Requesters using
RABC to request a resource MUST include the identifier of the
party whose offer was accepted in their broadcast thanks mes-
sage. Any thanks expressed in this message is implicitly di-
rected at ALL offering responders, even if they are not named.

Sample exchange:

(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks BOB, received R"


In some situations, a responder may wish to offer a resource,
but not have that fact rebroadcast in the thanks message. A
typical case for this would be if the responder is concerned
that him offering a resource he's holding, albeit temporarily
(such as a piece of equipment), might publicly imply he didn't
really need that resource in the first place.

This is solved by including a unique anonymous key in the Of-
fer message. There are no format restrictions on this key, it
can be any string the responder reasonably believes will be
unique given the size of L:

(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R, ANON_12345)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks ANON_12345, received R"


It is allowable for a requester with an outstanding request to
repeat this request after a personally-defined timeout. When
repeating an unsatisfied request, a requester MUST reply to
his original request keeping intact its subject field. This
allows members of the broadcast channel L to use message
threading features in their mail clients to easily collapse
request retransmissions into the original request's thread.

The retransmitted request thus replaces the original. Members
of L consider MESSAGE 1, MESSAGE 2 and MESSAGE 3 a single re-

(1) Alice -> L Request(R)
(2) Alice -> L RE: Request(R)
(3) Alice -> L RE: Request(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks DAVE, received R"


v0.1 jpdaigle 2008-05-20
Initial revision

v0.2 jpdaigle 2008-06-05
Added STATUS section, implicit thanks to IMPLEMENTATION

v0.3 jpdaigle 2009-03-10
Added anonymous thanks

Can I get some quiet?

It was too loud in my cube so I moved to the lunchroom to finish some doc reviews (no coding today). Of course, since the universe tends toward maximum irony, a bunch of coworkers decided the lunchroom would be the perfect place to start chatting away. Nice, thanks a lot.


Spotlight Effectiveness

What happens when you hit ⌘+space, then type "digi"?
Spotlight Effectiveness by you.

And how effective is this "Top Hit"?

You'd think there would be some sort of frequency counter kicking in after the first hundred times I manually arrowed-down to the right result, to train whatever rule determines the Top Hit.