I just uploaded a few gadgets to Windows Live Gallery and thought I should share something cool I learned from Jay Fluegel, the PM for gadgets in Windows Live Spaces. If you see a cool gadget on someone's space that you'd like to add to your space or portal page, all you need to do is click the '+' in the top-right corner of the gadget as shown in the screenshot below and viola

That's pretty hot and brain-dead simple too. Definitely beats having to trawl Windows Live Gallery everytime you see a cool gadget that you'd like to add to your space or personalized home page.


Categories: Windows Live

Caterina Fake of Flickr has a blog post entitled BizDev 2.0 where she writes

Several companies -- probably more than a dozen -- have approached us to provide printing services for Flickr users, and while we were unable to respond to most of them, given the number of similar requests and other things eating up our time, one company, QOOP, just went ahead and applied for a Commercial API key, which was approved almost immediately, and built a fully-fleshed out service. Then after the fact, business development on our side got in touch, worked out a deal -- and the site was built and taking orders while their competitors were still waiting for us to return their emails. QOOP even patrols the discussions on the Flickr boards about their product, and responds and makes adjustments based on what they read there. Now that's customer service, and BizDev 2.0.

Traditional business development meant spending a lot of money on dry cleaning, animating your powerpoint, drinking stale coffee in windowless conference rooms and scouring the thesaurus looking for synonyms for "synergy". Not to mention trying to get hopelessly overbooked people to return your email. And then after the deal was done, squabbling over who dealt with the customer service. Much, much better this way!

I know exactly where Catrina is coming from. Given that I work on the platform that powers Windows Live Spaces which has over 100 million users and 5.2 billion photos with over 6 million being uploaded daily, I've been on the receiving end of similar conversations about business partnerships revolving around integrating with the blogs, photo albums, lists and user profiles in our service. All of these partnerships have sounded obsolete to me in the age of open APIs. It seems to me to be much better to support de-facto industry standards like the MetaWeblog API that enables any tool or website to integrate with our service than have proprietary APIs that can only be accessed by people who we've made exclusive business deals with us. That seems better for our service and better for our users to me.

This definitely changes the game with regards to how our business development folks approach certain types of business partnerships. I probably wouldn't have called it BizDev 2.0 though. ;) 


August 16, 2006
@ 12:56 PM

In the post entitled Something went wrong at the W3C? Anne van Kesteren has a collection of links to rants about the W3C from Web-standards geeks that is sober reading. The post is excerpted below

Something went wrong at the W3C? Lets see:

  1. To Hell with WCAG 2
  2. Leaving W3C QA Dev.
  3. An angry fix
  4. SVG12: brief clarification on formal objections
  5. SVG Tiny 1.2 in Candidate Wreckommendation stage
  6. What's Wrong With The SVG Working Group
  7. Angry Indeed

Reading some of these rants takes me back to days I used to work on the XML team at Microsoft and how I grew to loathe the W3C and standards bodies in general. All of the above links are recommended reading for anyone who is interested in Web standards. An observation that stood out for me was taken from Joe Clark's rant, To Hell with WCAG 2 where he wrote

And now a word about process, which you have have to appreciate in order to understand the result. The Web Content Accessibility Guidelines Working Group is the worst committee, group, company, or organization I’ve ever worked with. Several of my friends and I were variously ignored; threatened with ejection from the group or actually ejected; and actively harassed. The process is stacked in favour of multinationals with expense accounts who can afford to talk on the phone for two hours a week and jet to world capitals for meetings.

The WCAG development process is inaccessible to anyone who doesn’t speak English. More importantly, it’s inaccessible to some people with disabilities, notably anyone with a reading disability (who must wade through ill-written standards documents and e-mails—there’s already been a complaint) and anyone who’s deaf (who must listen to conference calls). Almost nobody with a learning disability or hearing impairment contributes to the process—because, in practical terms, they can’t.

This sounds like an apt description of the W3C working groups I used to track, namely the XML Schema working group and the XML Query working group. Both of which [in my opinion] have done more harm than good for the Web and XML by simply existing and retarding progress with the technologies they have failed to produced.

The question I sometimes ponder is what's the alternative? De-facto standards based on proprietary technologies seem to be one option as evidenced by the success of RSS and IXMLHttpRequest. There is also something to be said about the approach taken by Microformats community. Either approach seems preferable to the current mess we have with the W3C's approach to standards development. 


Categories: Web Development

August 16, 2006
@ 11:01 AM

Robert Scoble has a blog post entitled Blogs and Digg, not geeky enough? where he writes

I notice a general trend looking through blogs, TechMeme, and Digg. There aren’t many coders anymore.

Five years ago the discussions were far more technical and geeky. Even insiderish. When compared to the hype and news of today.

It makes me pine for ye old RSS vs. Atom geek flamefests.

Anyone else notice this trend?

Sites like TechMeme and Digg hone in on what is popular to the general audience even if it is the general audience interested in software. There are more people interested in the impact of software-powered companies like Google, Yahoo!, Microsoft, MySpace, Youtube, and so on than there are people interested in the technology that powers these companies. There are going to be more people speculating about Google's next new service than those interested in a dissection of how the AJAX on one of Google's sites works. There are more people talking about Google Maps mashups than there are people talking about how to build them. There are more people interested in the next "Web 2.0" startup that Yahoo! is going to buy than are interested in technical language wars about whether Flash or AJAX is the way to go in building such sites. That's why you won't see Raymond Chen, Simon Willison or Jon Udell on TechMeme and Digg as often as you'll see the Michael Arringtons, Robert Scobles and  Om Maliks of the world.

This doesn't mean "there aren't many coders anymore" as Robert Scoble suggests. It just means that there are more people interested in the 'industry' part of the "software industry" than in the 'software' part. What else is new?


Categories: Technology

August 16, 2006
@ 03:45 AM

Today I learned about developers.facebook.com which proclaims

Welcome to Facebook Developers (beta), where you can create your own projects using our application programming interface (API).

In case you've been living under a rock for the past couple of months, The Facebook is like MySpace but for college kids. It seems to have made the transformation from a cool application of the moment (a.k.a. a fad) to an actual must-have utility among the college students I've talked to about it. I've heard college girls say they look guys up on The Facebook as part of pre-date screening and these were sorority girls not geeks. The fact that they are providing an API is a very interesting turn of events especially when you consider their dominant position in their market. 

I'm particularly interested in the Facebook API because I've been thinking about what we should do to expose the Windows Live friends list via an API. The problem with exposing APIs for social networks and contact lists is that the worst case scenario is that your API gets a lot of usage from your competitors (e.g. Zooomr vs. Flickr). I've been thinking about this problem on-and-off for the past couple of months and was interested to see how Facebook API handled this problem or whether, like me, they'd come to the conclusion that if the main use of your API is people trying to leave your service then you've got other problems than just the API. I checked out the definition of the facebook.friends.get method and left with more questions than answers. The API states


Returns the identifiers of the current user's Facebook friends. The current user is determined from the session_key. The values returned from this call are not storable.


The friend ids returned are those friends visible to the calling application. If no friends are found, the method will return an empty result element.

The parts highlighted in red are interesting to say the least. I wonder what exactly is meant by "values returned from this call are not storable". Is this legal wording? Are the values encrypted in some way? What exactly does that mean? It looks like I may need to do some sleuthing around the forums except I don't have a Facebook account. Hmmm...

I was also interested in the authentication model used by the Facebook API. From reading the documentation, their authentication scheme reminds me of Yahoo's Browser Based Authentication Scheme (scheme) in that it requires users to always log-in from a browser and then either be redirected back to the calling page (much like Microsoft's Passport Windows Live ID) or for the target application to re-use the URL it got after the browser was closed if it is a desktop application. Surely, there must be a better way to authenticate desktop applications against online services than habing them launch a Web browser and having a separate, dissonant sign-in process.

PS: If the Facebook API sounds interesting to you and you'd like to do similar things with the Windows Live friends list I'd love to hear what your scenarios are. Holla at me. 


I've been spending some time over the past couple of months thinking about Web services and Web APIs. Questions like when a web site should decide to expose an API, what form the API should take and what technologies/protocols should be used are topics I've rehashed quite a lot in my head. Recently I came to the conclusion that if one was going to provide a Web service that is intended to be consumed by as many applications as possible, then one should consider exposing the API using multiple protocols. I felt that at least two protocols should be chosen SOAP over HTTP (for the J2EE/.NET crowd) and Plain Old XML (POX) over HTTP (for the Web developer crowd).

However, I've recently started spending a bunch of time writing Javascript code for various Windows Live gadgets and I've begun to appreciate the simplicity of using JSON over parsing XML by hand in my gadgets. I've heard similar comments echoed by co-workers such as Matt who's been spending a bunch of time writing Javascript code for Live Clipboard and Yaron Goland who's one of the minds working on the Windows Live developer platform. JSON has similar goals to XML-RPC and W3C XML schema in that it provides a platform agnostic way to transfer data which is encoded as structured types consisting of name<->value pairs and collections of name<->value pairs. It differs from XML-RPC by not getting involved with defining a mechanism for remote procedure calls and from W3C XML schema by being small, simple and focused.

Once you start using JSON in your AJAX apps, it gets pretty addictive and it begins to seem like a hassle to parse XML even when it's just plain old XML such as RSS feeds not complex crud like SOAP packets. However being an XML geek, there are a couple of things I miss from XML that I'd like to see in JSON especially if it's usage will grow to become as widespread as XML is on the Web today. Yaron Goland feels the same way and has started a series of blog posts on the topic.

In his blog post entitled Adding Namespaces to JSON Yaron Goland writes

The Problem

If two groups both create a name "firstName" and each gives it a different syntax and semantics how is someone handed a JSON document supposed to know which group's syntax/semantics to apply? In some cases there might be enough context (e.g. the data was retrieved from one of the group's servers) to disambiguate the situation but it is increasingly common for distributed services to be created where the original source of some piece of information can trivially be lost somewhere down the processing chain. It therefore would be extremely useful for JSON documents to be 'self describing' in the sense that one can look at any name in a JSON document in isolation and have some reasonable hope of determining if that particular name represents the syntax and semantics one is expecting.

The Proposed Solution

It is proposed that JSON names be defined as having two parts, a namespace name and a local name. The two are combined as namespace name + "." + local name to form a fully qualified JSON name. Namespace names MAY contain the "." character. Local names MUST NOT contain the "." character. Namespace names MUST consist of the reverse listing of subdomains in a fully qualified DNS name. E.g. org.goland or com.example.bigfatorg.definition.

To enable space savings and to increase both the readability and write-ability of JSON a JSON name MAY omit its namespace name along with the "." character that concatenated it to its local name. In this case the namespace of the name is logically set to the namespace of the name's parent object. E.g.

{ "org.goland.schemas.projectFoo.specProposal" :
"title": "JSON Extensions",
"author": { "firstName": "Yaron",
"org.goland.schemas.projectFoo.lastName": "Goland",

In the previous example the name firstName, because it lacks a namespace takes on its parent object's namespace. That parent is author which also lacks a namespace so recursively author looks to its parent specProposal which does have a namespace, org.goland.schemas.projectFoo. middleName introduces a new namespace "com.example.schemas", if the value was an object then the names in that object would inherit the com.example.schemas namespace. Because the use of the compression mechanism is optional the lastName value can be fully qualified even though it shares the same namespace as its parent. com.example.taxonomy

My main problem with the above approach is echoed by the first comment in response to Yaron's blog post; the above defined namespace scheme isn't completely compatible with XML namespaces. This means that if I have a Web service that emits both XML and JSON, I'll have to use different namespace names for the same elements even though all that differs is the serialization format. Besides the disagreement on the syntax of the namespace names, I think this would be a worthwhile addition to JSON.

In another blog post entitled Adding Extensibility to JSON Data Formats Yaron Goland writes

The Problem

How does one process JSON messages so that they will support both backwards and forwards compatibility? That is, how does one add new content into an existing JSON message format such that those who do not understand the extended content will be able to safely ignore it?

The Proposed Solution

In the absence of additional information providing guidance on how to handle unrecognized members a JSON processor compliant with this proposal MUST ignore any members whose names are not recognized by the processor.

For example, if a processor was expecting to receive an object that contained a single member with the name "movieTitle" and instead it receives an object with multiple members including "movieTitle", "producer" and "director" then the JSON processor would, by default, act as if the "producer" and "director" members were not present.

An exception to this situation would be a member named "movie" whose value is an object where the semantics of the members of that object is "the local name of the members of this object are suitable for presenting as titles and their values as text under those titles". In that case regardless of the processor's direct knowledge of the semantics of the members of the object (e.g. the processor may actually know about movieTitle but not "producer" or "directory") the processor can still process the unrecognized members because it has additional information about how to process them.

This requirement does not apply to incorrect usage of recognized names. For example, if the definition of an object only allowed a single "movieTitle" member then having two "movieTitle" members is simply an error and the ignore rule does not apply.

This specification does not require that ignored members be removed from the JSON structure. It is quite possible that other processors who will deal with the message may recognized members the current processor does not. Therefore it would make sense to let unrecognized members remain in the JSON structure so that others who process the structure may benefit from the extended information.

Definition: Simple value - A value of a type other than array or object.

If a JSON processor encounters an array where it had expected to encounter a simple value the processor MUST retrieve the first simple value in the array and treat that as the value it was expecting and ignore the other elements in the array.

Again, it looks like I'm going to go ahead and parrot the same feedback as a commenter to the original blog post. Defining an extensibility model where simple types can be converted to arrays in a future version seems like overkill and unnecessary complexity. It's not like it's that hard to another field to the type. The other thing I wondered about this blog post is that it seemed to define a problem set that doesn't really exist. It's not like there are specialized JSON parsers that barf if they see a field that they don't understand in widespread use. Requiring that the fields of various types be defined up front or else barfing when encountering undefined fields over the wire is primarily a limitation of statically typed languages and isn't really a problem for dynamic languages like JavaScript. Or am I missing something?


Categories: XML Web Services

August 14, 2006
@ 07:24 PM

I've been late to blog about this because I was out on vacation but better late than never. J.J. Allaire (yes, that one) has a blog post entitled Introducing Windows Live Writer which announces Microsoft's desktop blogging tool called Windows Live Writer. He writes

Introducing Windows Live Writer

Welcome to the Windows Live Writer team blog! We are excited to announce that the Beta version of Windows Live Writer is available for download today.

Windows Live Writer is a desktop application that makes it easier to compose compelling blog posts using Windows Live Spaces or your current blog service. Blogging has turned the web into a two-way communications medium. Our goal in creating Writer is to help make blogging more powerful, intuitive, and fun for everyone. Writer has lots of features which we hope make for a better blogging experience. Some of the ones we are most excited about include:

WYSIWYG Authoring

 The first thing to notice about Writer is that it enables true WYSIWYG blog authoring. You can now author your post and know exactly what it will look like before you publish it. Writer knows the styles of your blog such as headings, fonts, colors, background images, paragraph spacing, margins and block quotes and enables you to edit your post using these styles. ...

Photo Publishing

Writer makes inserting, customizing, and uploading photos to your blog a snap. You can insert a photo into your post by browsing image thumbnails through the “Insert Picture” dialog or by copying and pasting from a web page...Photos can be either uploaded directly to your weblog provider (if they support the newMediaObject API) or to an FTP server.

Writer SDK

 Already thinking of other cool stuff you want to insert into your blog? Good!

The Windows Live Writer SDK allows developers to extend the capabilities of Writer to publish additional content types. Examples of content types that can be added include:

  1. Images from online photo publishing sites
  2. Embedded video or audio players
  3. Product thumbnails and/or links from e-commerce sites
  4. Tags from tagging services

This is one project I've been dying to blog about for months. Since I was responsible for the blogging and the upcoming photo publishing APIs for Windows Live Spaces, I've spent the last couple of weeks working with the team to make sure that the user experience when using Windows Live Writer and Windows Live Spaces is great. I'd like to hear if you think we've done a good job.

PS: The application is not only chuck full of features but is also very extensible. Tim Heuer has already written plugins to enable integration with Flickr and added tagging support. If you are a developer, you should also download the SDK and see what extensions you can hack into the app.


Categories: Windows Live

In my previous post, I talked about some of the issues I saw with the idea of doing away with operations teams and merging their responsibilities into the development team's tasks [as practised at companies like Amazon]. Justin Rudd, who is a developer at Amazon, posts his first-hand perspective of this practice in his blog post entitled Expanding on the Pain where he writes

Since I am a current employee of Amazon in the software development area, I probably shouldn’t be saying this, but…

First a few clarifications - there is no dedicated operations team for Amazon as a whole that is correct.  But each team is allowed to staff as they see fit.  There are teams within Amazon that have support teams that do handle quite a bit of the day to day load.  And their systems tend to be more “smooth” because this is what that team does - keep the system up and running and automate keeping the system up and running so they can sleep at night.

There are also teams dedicated to networking, box failures, etc.  So don’t think that developers have to figure out networking issues all the time (although there are sometimes where networking doesn’t see a problem but it is affecting a service).

Now for those teams that do not have a support team (and I am on one of them), at 3 in the morning you tend to do the quickest thing possible to get the problem rectified.  Do you get creative?  After being in bed for 3 hours (if you’re lucky) and having a VP yell at you on the phone that this issue is THE most important issue there is or having someone yell at you that they are going to send staff home, how creative do you think you can be?  Let me tell you, not that creative.  You’re going to solve the problem, make the VP happy (or get the factory staff back to work), and go back to bed with a little post it note to look for root cause of the problem in the AM.

Now 1 of 2 things happens.  If you have a support team, you let them know about what happened, you explain the symptoms that you saw, how you fixed it, etc.  They take your seed of an idea, plant it, nurture it, and grow it.

If you don’t have a support team and you are lucky, in the morning there won’t be another THE most important thing to work on and you can look at the problem with some sleep and some creativity.  But the reality is - a lot of teams don’t have that luxury.  So what happens?  You end up cronning your solution which may be to bounce your applications every 6 hours or run a perl script that updates a field at just the right place in the database, etc.

We all have every intention of fixing it, but remember that VP that was screaming about how this issue had to be fixed?  Well now that it isn’t an issue anymore and it’s off his radar screen, he has new features that he wants pushed into your code.  And those new features are much more important than you fixing the issue from the night before because the VP really doesn’t care if you get sleep or not at night.

Justin's account jibes with other accounts I've heard [second hand] from other ex-Amazon developers about what it means to live without an operations team. Although it sounds good on paper to have the developers responsible for writing the code also responsible when there are issues with the code on the live site, it leads to burning the candle at both ends. Remember, division of labor exists for a reason.

Categories: Web Development

A few weeks ago, I bookmarked a post from Sam Ruby entitled Collapsing the Stack where he wrote

Werner Vogels: Yep, the best way to completely automate operations is to have to developers be responsible for running the software they develop. It is painful at times, but also means considerable creativity gets applied to a very important aspect of the software stack. It also brings developers into direct contact with customers and a very effective feedback loop starts. There is no separate operations department at Amazon: you build it; you run it.

Sounds like a very good idea.

I don't see how this sounds like a good idea. This reminds me of a conversation I once had with someone at Microsoft who thought it would be a good idea to get rid of their test team and replace them all with developers once they moved to Test Driven Development. I used to be a tester when I first joined Microsoft and this seemed to me to be the kind of statement made by someone who assumed that the only thing testers do is write unit tests. Good test teams don't just write unit tests. They develop and maintain test tools. They perform system integration testing. They manage the team's test beds and test labs. They are the first line of defence when attempting to reproduce customer bug reports face before pulling in developers who may be working on your next release. All of this can be done by the development team but it means that your developers spend less time developing and more time testing. This cost will show up either as an increment in the amount of time it takes to get to market or a reduction in quality if schedules are not adjusted to account for this randomization of the development team. Eventually you'll end up recreating your test team so there are specific people responsible for test-related activities [which is why software companies have test teams in the first place].

The same reasoning applies to the argument for folding the responsibilities of your operations team into the development team's tasks. A good operations team isn't just responsible deployment/setup of applications on your servers and monitoring the health of the Web servers or SQL databases inyour web farm. A good operations team is involved in designing your hardware SKUs and understanding your service's peak capacity so as to optimize purchase decisions. A good operations team makes the decisions around your data centers from picking locations with the best power prices and ensuring that you're making optimal use of all the physical space in your data center to making build . A good operations team is the first line of defence when your service is being hit by a Denial of Service attack. A good operations team insulates the team from worrying about operating system, web server or database patches being made to the live site. A good operations team is involved in the configuration, purchase, deployment and [sometimes] development of load balancing, database partitioning and database replication tools. Again, you can have your development team do this but eventually it would seem to make sense that these tasks be owned by specific individuals instead of splitting them across the developers building one's core product.

PS: I've talked to a bunch of folks who know ex-Amazon developers and they tend to agree with my analysis above. I'd be interested in getting the perspective of ex-Amazon developers like Greg Linden on replacing your operations team with your core development staff.

PPS: Obviously this doesn't apply if you are a small 2 to 5 person startup. Everyone ends up doing everything anyway. :)


Categories: Web Development

August 8, 2006
@ 08:30 PM

This morning I got an IM from Niall Kennedy letting me know that he was Leaving Microsoft. He begins his blog post about leaving by writing

I am leaving Microsoft to start my own company. My last day at Microsoft is next Friday, August 18. It's uncertain whether Microsoft will continue the feed platform work I started, but it's some good stuff so I hope they do.

As the person who referred Niall to the company and gave him some advice when he was weighing whether to join Windows Live, I am sad to see him leave so soon. I sympathize with his reasons for leaving although some of what he wrote is inaccurate and based on speculation rather than the actual facts of the matter. That said, I found Niall to be quite knowledgeable, smart and passionate, so I expect him to do well in his endeavors.

Good luck, Niall.