I’ll be joining their solutions team, which means I’ll be helping with the design, development, and deployment of custom solutions built upon Day’s product line. The position isn’t unlike the consulting work I’d been doing much of the past six years, only more hands-on (yeah!), and of course, Day-specific.

It also means a lot more travel, so watch for me in your neck of the woods on Dopplr.

1. Manhattan Cocktail
2. Kopi Luwak (Weasle Coffee)
3. French / Swiss Absinthe
4. Rootbeer
5. Gin Martini
6. Sauternes
7. Whole Milk
8. Tequila (100% Agave)
9. XO Cognac
10. Espresso
11. Spring Water (directly from the spring)
12. Gin & Tonic
13. Mead
14. Westvleteren 12 (Yellow Cap) Trappist Ale
15. Chateau d’Yquem
16. Budweiser
17. Maraschino Liqueur
18. Mojito
19. Orgeat
20. Grand Marnier
21. Mai Tai (original)
22. Ice Wine (Canadian)
23. Red Bull
24. Fresh Squeezed Orange Juice
25. Bubble Tea
26. Tokaji
27. Chicory
28. Islay Scotch
29. Pusser’s Navy Rum
30. Fernet Branca
31. Fresh Pressed Apple Cider
32. Bourbon
33. Australian Shiraz
34. Buckley’s Cough Syrup
35. Orange Bitters
36. Margarita (classic recipe)
37. Molasses & Milk
38. Chimay Blue
39. Wine of Pines (Tepache)
40. Green Tea
41. Daiginjo Sake
42. Chai Tea
43. Vodka (chilled, straight)
44. Coca-Cola
45. Zombie (Beachcomber recipe)
46. Barley Wine
47. Brewed Chocolate (Xocolatl)
48. Pisco Sour
49. Lemonade
50. Speyside Single Malt
51. Jamaican Blue Mountain Coffee
52. Champagne (Vintage)
53. Rosé (French)
54. Bellini
55. Caipirinha
56. White Zinfandel (Blush)
57. Coconut Water
58. Cerveza
59. Cafe au Lait
60. Ice Tea
61. Pedro Ximenez Sherry
62. Vintage Port
63. Hot Chocolate
64. German Riesling
65. Pina Colada
66. El Dorado 15 Year Rum
67. Chartreuse
68. Greek Wine
69. Negroni
70. Jägermeister
71. Chicha
72. Guiness
73. Rhum Agricole
74. Palm Wine
75. Soju
76. Ceylon Tea (High Grown)
77. Belgian Lambic
78. Mongolian Airag
79. Doogh, Lassi or Ayran
80. Sugarcane Juice
81. Ramos Gin Fizz
82. Singapore Sling
83. Mint Julep
84. Old Fashioned
85. Perique
86. Jenever (Holland Gin)
87. Chocolate Milkshake
88. Traditional Italian Barolo
89. Pulque
90. Natural Sparkling Water
91. Cuban Rum
92. Asti Spumante
93. Irish Whiskey
94. Château Margaux
95. Two Buck Chuck
96. Screech
97. Akvavit
98. Rye Whisky
99. German Weissbier
100. Daiquiri (classic)

What it is about is that earlier this week, at the BBDC, RIM announced what is, AFAIK, its first on the topic of the Web; Web Signals;

BlackBerry Web Signals leverages RIM’s unique push technology to allow online content providers to automatically notify BlackBerry smartphone users when relevant content has been published and to allow streamlined, one-click access to the online information.

So I dug into the technical overview, and spotted this near the beginning;

To push content to users, content providers must first register their web signals with Research In Motion.

Bzzt!

As they don’t seem to realize, the Web is agreement; a large, complex distributed system made possible by parties who agreed to use its constituent protocols. Publishers agreed because it gave them a low cost path to distribute information directly to the users who had also made those same agreements (by using an agent which implemented the protocols). Imagine now, if you will, what would have happened to the Web, had publishers needed to register with, say, AOL to reach AOL users, or Comcast for Comcast users. What a huge burden! It could be worse, the burden could be on the users, but why bother with one at all? Remember PQA? My point exactly.

Always, always, always, try do what you need using existing agreement.

In this case – of notification of content changes – RIM had a couple obvious options. Most simply, they could have used email, though of course the user experience is suboptimal, not to mention the privacy concerns of handing out the user’s email address to every publisher. Alternately, there’s RSS/Atom, something publishers are already pretty comfortable with. It might even sound a little familiar, seeing as I described the architecture necessary to support it in that white paper I wrote for them.

If you’ve read ahead in that tech overview, you’ll also notice that they predefine their URI structure, and don’t even mention which HTTP method to use on those URIs to send a notification, which probably means that GET does the deed. Yuck.

Come on RIM, get your act together. Competition is heating up, and those guys in Cupertino (mostly) have their act together when it comes to the Web.

As I mentioned in a comment there, I’m no stranger to this kind of interface specification, as I’d guess that about 80% of the “APIs” I reviewed as a consultant suffered from at least one of the problems Roy listed. Fortunately, I found it wasn’t very difficult to get people to see the error of their ways. All I had to do was re-emphasize that REST requires that interfaces be uniform – the same – and therefore that pre-specifying anything specific about a resource, such as URI structure, response codes, media types, resource relationships, etc.. was antithetical to that requirement.

Then again, Web services nailed their requirements perfectly too.

I think the how of what Gears is doing is, frankly, misguided. There’s minimal reuse of existing Web technologies, and it’s overly imperative when it could be easily be far more declarative. Each of these issues raise the bar for the kinds of skills a Web developer needs. Not a good thing.

Interestingly, the Web services analogy doesn’t stop at the requirements. When I talk about “minimal reuse”, what I’m referring to is that the Web already has a mature and general API for accessing and manipulating local data-oriented services – the DOM – and no “gear” I’ve seen has yet to use it for data access. So instead of a Javascript GeoLocation object that might expose method calls such as getCurrentLocation() or getLockedSatellites(), why not make the object a DOM Node and treat the data contained within as a document? Something like;

<Location>
  <Current>45.234,-120.999</Current>
  <LockedSattelites>4</LockedSatellites>
</Location>

(or better yet perhaps, microformatted HTML – though there’s issues there)

Then you could use the DOM itself to get at those values, or perhaps even a CSS selector. Simple!. You even get events for free.

Why is it that the industry continues to overlook the value of reusing pervasively deployed generic abstractions, be they network oriented or local? It couldn’t be a case of NIH, because the DOM is unavoidable if you’re a Web dev. I guess it just didn’t occur to the them, though that doesn’t explain the push back.

Thanks, Roy. I owe you one.

Skip ahead to current day, and I find myself ex-co-founder of a mobile startup which wasn’t able to raise the money it needed, and a consultant who, frankly, got bored answering all the REST 101 questions that came my way. Don’t get me wrong, I love that the Web and REST are finally getting their due, and I was honoured to have folks from all over the world come to me to answer their questions, but unfortunately those questions were rarely a challenge. What I want – nay, what I need – is to work on product or projects for a while where I have the opportunity to be creative once again.

If you’re reading this, you probably know what I’m good it and what I like. For the record, that’s the Web, mobile, open source, and projects/products for the public good. If you know of any opportunities that fall somewhere in that space, please drop me a line. Thanks.

• Never Let Me Down Again, Smashing Pumpkins
• Policy of Truth, Dishwalla
• Everything Counts, Meat Beat Manifesto
• Master and Servant, Locust

Here’s the rest of my favourites, in no particular order;

• Hurt, Johnny Cash covering Nine Inch Nails
• Mad Mad World, Michael Andrews covering Tears for Fears
• End of the World, Great Big Sea covering R.E.M
• Helpless, KD Lang covering Neil Young
• Landslide, Smashing Pumpkins covering Fleetwood Mac
• There She Goes, Sixpence None the Richer covering The La’s
• American Woman, Lenny Kravitz covering The Guess Who

(wow, complete performances at Youtube or last.fm for all of them, that’s pretty cool)