A number of people at work have asked me why in a previous post I stated that I have concluded that MSFT isn't the kind of place I see myself working at in 5 years. The main reason for this is that I don't think the Microsoft culture and the direction from its executive leadership lends itself to building great consumer-centric software.

A good example of this is taking a look at Windows from the consumer perspective. The decisions that Microsoft has made over the past couple of years from abandoning feature work in Internet Explorer until Firefox became popular to a lot of the original intentions around the 3 pillars of Longhorn (Avalon, WinFS & Indigo) are the actions of a company that is more interested in protecting its market share than one that is trying to improve the lives of its customers by building great software.  Of course, it's not only customers that get the short end of the stick. Employees also have the consequences of this kind of thinking to deal with as well. The primary way this manifests itself is integrated innovation, a buzzword that translates to more dependencies among shipping products, less control of one's product destiny and longer ship cycles. A lot of the frustration you see in the comments in places like the Mini-Microsoft blog are a direct consequence of this focus by our executive leadership.

For now, MSN doesn't suffer from the same kind of culture that I have described but I can see signs that this is just temporary while we face off against competitors like Google [and Yahoo! to a lesser extent]. Since I don't see any reason why the corporate culture will change since the members of our executive leadership who are pushing this kind of thinking are well entrenched, it's just a matter of time before we start thinking that way at MSN as well. 

I give it 5 years, tops. In the meantime, I get to work with really cool people building really cool software that is changing people's lives. I can't ask for much more than that.


 

Categories: Life in the B0rg Cube

September 1, 2005
@ 07:49 PM

In his post The saga of RSS (dis)continuity Jon Udell writes

It's been almost three years since I first wrote about the problem of RSS feed redirection. From time to time I'm reminded that it's still a problem, and today I noticed that two of the blogs I read were affected by it. I was subscribed to John Ludwig at www.theludwigs.com/index.rdf, and today's entry says "Feed moved -- pls check out www.theludwigs.com/index.xml." In fact he's got an index.xml and an atom.xml, and the latter seems to correspond to what's actually published on the blog, but either way the issue is that we've still yet to agree on a standard way for newsreaders to follow relocated feeds.

Jon Udell is incorrect. There is a standard way to redirect feeds that is supported by a large number of RSS readers and it is called "just use HTTP". Many RSS readers including RSS Bandit support the various status codes for indicating that the location of a resource has changed temporarily or permanently as well as when the resource is no longer available.

Instead of constantly reinventing the wheel and looking for solutions to problems that have already been solved, a better use of our energy should be evangelizing how to properly use the existing technology.

Jon Udell does point out

So far as I know, that's where things stand today. If you control your server, you can of course do an HTTP-level redirect. But your blog is hosted, you probably can't, in which case you need to use the feed itself to signal the redirect.

This part just boggles my mind. If the user's blog is hosted (e.g. they are a LiveJournal, MSN Spaces or BlogSpot user) then not only can't they control the HTTP headers emitted by the server but they don't control their web feed either. So what exactly is the alternate solution that works in that case? If anything, this points to the fact that blog hosting services should give users the ability to redirect their RSS feed when they leave the service. This is a feature request for the various blog hosting services not an indication that a new technical solution is needed.

 


 

September 1, 2005
@ 06:34 PM

I have a LazyWeb request. I plan to write an article about my Seattle Movie Finder hack which is built on the MSN Virtual Earth APIs next week. Currently the application works in Internet Explorer but not in Firefox. This isn't due to any issues with VE but has to do with the fact that I don't know what the Firefox alternatives to innerHTML and some other properties of the DOM in IE actually are nor do I have time to brush up on writing Firefox-specific Javascript.

If any kind soul can do a view source on the Seattle Movie Finder and modify it to also work in Firefox, I'd appreciate it. Thanks in advance.

Update:  Julien Couvreur just swung by my office and fixed the page so it works in Firefox & IE. The new version of the site should be up in a few hours.


 

Categories: Web Development

September 1, 2005
@ 05:37 PM

It looks like http://www.start.com is now an actual site as opposed to a 'coming soon' graphic. However the disclaimer at the bottom still states, this site is not an officially supported site. it is an incubation experiment and doesn't represent any particular strategy or policy.

Curioser and curioser.


 

Categories: MSN

I've known about this for a couple of days but was planning to wait until it was mentioned on the MSN Search blog. However since they've been scooped it looks like the cat is out of the bag. So here goes

Searching for Web (RSS, Atom) Feeds

Need to find an RSS or Atom feed? No problem.  Use the feed: operator to do so.  This searches for all documents that are RSS or atom feeds

http://search.msn.com/results.aspx?q=feed%3A+robert+scoble&FORM=QBHP

Searching for documents that contain Web (RSS, Atom) Feeds

Need to find a document that contains an RSS or Atom feed?  Use the hasfeed: operator.

http://search.msn.com/results.aspx?q=hasfeed%3A+C%23&FORM=QBRE

Folder Level Site Search

You can now use site search (site: operator) to restrict your search to a particular folder hierarchy in the URL up to two levels deep.  For example,

http://search.msn.com/results.aspx?q=site%3Awww.microsoft.com%2Fwindows&FORM=QBHP (searching the Windows site on MS.com)

http://search.msn.com/results.aspx?q=site%3Aspaces.msn.com%2Fmembers%2Fmike&FORM=QBRE (searching a blog on MSN Spaces)

Note:  There is a known issue around this feature. You cannot include a / after the second directory. This will be fixed in the near future. 

So it looks like MSN Search is the first of the big three search engines to provide RSS search and the improvements to the site: operator are also quite cool. They definitely get mad props from me for getting these features out there. 


 

Categories: MSN

One of the biggest problems that faces designers of distributed application is making sure their applications are resistant to change (i.e. versioning). Making sure services are designed with forwards and backwards compatibility in mind is especially challenging when one has no control over the various parties that will be invoking the service. 

In traditional applications, enumerated types (aka enums) are particularly problematic when it comes to versioning. The problem case being when new values are added to an enumerated type in a later version. The .NET Framework Design Guidelines about adding new values to enumerated types shows how insidious this problem actually can be. The original guidelines stated that it was OK to add values to enumerated types but this was later surrounding with lots of warnings as to why this is a bad idea. The original guideline states

It is acceptable to add values to enums

If a caller receives an enum as an out or return value (or as a parameter to a virtual method), and switches over every valid value of the enum and throws unconditionally in the default case, then added values will cause the caller to perform the default case, and throw

If a caller receives an enum as an out or return value, and performs some default behavior in the default case, then added values will behave as if they were default values

If you receive compatibility data for your application which indicates returning the new values from the existing API will cause issues for callers, consider adding a new API which returns the new (and old) values, and deprecate the old API. This will ensure your existing code remains compatible.

The following addendum was later added

Adding a value to an enum has a very real possibility of breaking a client. Before the addition of the new enum value, a client who was throwing unconditionally in the default case presumably never actually threw the exception, and the corresponding catch path is likely untested. Now that the new enum value can pop up, the client will throw and likely fold.

The biggest concern with adding values to enums, is that you don't know whether clients perform an exhaustive switch over an enum or a progressive case analysis across wider-spread code. Even with the FxCop rules above in place and even when it is assumed that client apps pass FxCop without warnings, we still would not know about code that performs things like  if (myEnum == someValue) ...  in various places.

Clients may instead perform point-wise case analyses across their code, resulting in fragility under enum versioning. It is important to provide specific guidelines to developers of enum client code detailing what they need to do to survive the addition of new elements to enums they use. Developing with the suspected future versioning of an enum in mind is the required attitude.

There is an additional wrinkle when adding values to an enumerated type in XML Web Services especially if the calling application is built using the .NET Framework. Let's say we have the following enumerated type declaration in the schema for v1 of our service

<xsd:simpleType name="SyndicationFormat">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="RSS10"/> 
    <xsd:enumeration value="RSS20"/>     
    <xsd:enumeration value="CDF"/>
  </xsd:restriction>
</xsd:simpleType>

and in a later version modify it in the following way

<xsd:simpleType name="SyndicationFormat">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="RSS10"/> 
    <xsd:enumeration value="RSS20"/>        
    <xsd:enumeration value="CDF"/>
    <xsd:enumeration value="Atom"/> 
  </xsd:restriction>
</xsd:simpleType>

Of course, as mentioned in the amended discussion on adding values to enumerated types in the .NET Framework design guidelines, this is a forwards incompatible change because new messages will very likely not be properly processed by old clients. However when the consuming applications are built using the XML Web services capabilities of the .NET Framework we dont even get that far. Instead you will most likely get an exception that looks like the following

Unhandled Exception: System.InvalidOperationException: There is an error in XML document (1, 1022). ---> System.InvalidOperationException: 'Atom' is not a valid value for SyndicationFormat.
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderSyndicationService.Read4_SyndicationFormat(String s)

This is because the client code will have been generated from the v1 version of the WSDL for the service where "Atom" was not a valid value for the SyndicationFormat enumerated type. So adding a value to an enumerated type in an existing XML Web service end point is pretty much guaranteed to break client applications.

I love my day job. ;)

PS: This example is made up but the problem is real.


 

Categories: XML Web Services

From the Microsoft press release Microsoft Acquires Teleo, Innovative VoIP Technology Company we learn

REDMOND, Wash. — Aug. 30, 2005 — Microsoft Corp. today announced it has acquired Teleo Inc., a provider of voice over Internet protocol (VoIP) software and services that enable the placement of phone calls from PCs to traditional phones and that deliver this technology in unique ways through a variety of software and Web applications. Microsoft expects to combine the technology and expertise of Teleo with the existing VoIP investments of MSN to further develop products and services that connect consumers to the people and information that most matter to them. Financial details were not disclosed.

Founded in 2003 and headquartered in San Francisco, Teleo is a privately held company whose initial planned service offering, also called Teleo, was designed to allow customers to use their PC to make phone calls to cell phones, regular phones or other PCs. Through its integration with Microsoft® Outlook® and Microsoft Internet Explorer, the Teleo service was designed to facilitate click-to-call dialing of any telephone number that appears on-screen, for example through a Web site or via search results or e-mail.

VoIP technology already is prominently featured in MSN® Messenger as well as other Microsoft products and services. Microsoft plans to incorporate and expand upon Teleo technologies, integrating them into the infrastructure that supports MSN and ultimately projects delivering new VoIP consumer applications in future releases of MSN services.

This is pretty good news for MSN Messenger users. Instant Messaging is more than just sending text from one computer to another. Voice and video conversations are also valid ways to communicate using our instant messaging client. Also the ability to communicate with people on other devices besides their computers is also one thing we think is important. In fact, while I was in Nigeria I made heavy use of MSN Messenger's SMS to IM conversation capabilities to send messages to my girl friend's phone while she was at work back here in Seattle.

It's all about communication and the addition of the Teleo folks to our fold will only increase and improve the communication capabilities of MSN Messenger. Excellent.


 

Categories: MSN

Torsten just posted the following announcement about the RSS Bandit support forums

Because of the amount of spam from fake user/member accounts we changed the rules related to how new members are approved to use/post to our forums.

Each new user will be approved by one of the forum administrators manually. You will have to provide a VALID e-mail address while registering. So if you don't get approved within 10 minutes, please don't try again with other/changed e-mail addresses.
We are humans and need to sleep some minutes every day

If you get access, you will receive a mail from forumadmin at rssbandit.org soon...

We were getting almost a dozen spam posts a day which made the forum RSS feed completely useless. We shut down accepting new members for a few days until Torsten figured out that we could add an approval process for new member requests.

Having to deal with approving new member requests is a hassle but a lot less than having to delete posts and member accounts created by spambots. Spammers suck. 


 

Categories: RSS Bandit

Since I've been in the process of adding support for synchronization between RSS Bandit and Newsgator Online, I've been trying to eat my own dogfood and use both applications. A ready opportunity presented itself when I travelled to Nigeria a few weeks ago and wanted to keep up with my RSS feeds. While I was in Nigeria, I was always on a dialup connection and used about four different PCs and 1 Mac. It seemed to make sense to favor a web-based RSS reader as opposed to trying to install RSS Bandit and most likely the .NET Framework on all these machines which in some cases I didn't have administrator access to anyways.

After unsuccesfully trying to use Newsgator Online I ended up settling with Bloglines instead for a number of reasons. The first being that Bloglines is a lot faster than Newsgator Online whose interface seems to move at a snail's pace over dial up. The second being that a basic feature like "Mark All Items As Read" seems to be missing from Newsgator Online. Trying to visit every feed individually to mark all its items as read became such an ordeal, I simply gave up.

I'd rather not think that I've wasted the time I've spent working on implementing synchronization between RSS Bandit and Newsgator Online since the current user experience of the latter service leaves much to be desired. I sincerely hope there are some changes in the works for the service.


 

Lots of folks I've talked to at work have had mixed feelings about the recently announced Google Talk. The feelings are usually relief and disapointment in equal portions. Relief because Google hasn't shipped yet another application that redraws the lines of what that class of application should look like (e.g. GMail and Google Maps) meaning we have to play catch up. Disappointment because we actually expect better from Google.

You can see some of these sentiments from various folks at MSN such as Mike Torres in his post Competition & Google Talk, Sanaz Ahari in her posts Google Talk review and Google Talk pt II, and Richard Chung in his post Google Talk Blows.

Of course, Microsoft employees aren't the only ones underwhelmed by Google Talk. Doing a quick search of the blogosphere for comments about Google Talk leads me to lots of bloggers expressing ambivalence about the application.

The most interesting reaction I noticed was from Robert X. Cringely who was inspired to ask Has Google Peaked? in his most recent column. In the article he not only asks whether Google's best products are already behind it but also points out that they have become experts at Fire and Motion. Below is the relevant excerpt from Robert X. Cringely's column

Google plays on its technical reputation even though, if you look closely, it isn't always deserved. Many Google products haven't been revved since they were introduced. And while some Google products are excellent, some aren't, too.

Google likes to play the Black Box game. What are they DOING in all those buildings with all those PhDs? I'm sure they are doing a lot that will change the world, but just as much that will never even be seen by the world. For the moment, though, it doesn't matter because Google can play the spoiler. They offered a gigabyte of e-mail storage, for example, at a time when they had perhaps one percent the number of e-mail users as a Hotmail or Yahoo. And by limiting the Gmail beta, they avoided the suffering of both those other companies when they, too, had to increase their storage allocations, but for tens of millions of real users.

Now Google will do something similar for chat and VoIP with Gtalk, pushing the others toward an interoperability that undermines the hold each company thinks it has on its users.

In my original post about Google Talk I mentioned that using Jabber/XMPP was an attempt at a disruptive move by Google. Of course, it is only disruptive if its competitors like AOL, MSN and Yahoo! react by breaking down the walls of the walled gardens they have created in their various IM products.

I find it interesting that instead of trying to push the envelope with regards to the user experience in instant messaging, Google chose to 'punk' its competitors instead. I guess we'll just have to see how MSN, Yahoo & AOL end up reacting. 


 

Categories: MSN