From the blog post Virtual Earth Team Launches Street-Side Drive-by we learn

The Virtual Earth team is pleased to launch a preview of a new feature we have been working on – interactive Street-side browsing. You can try it out at http://preview.local.live.com Street-side imagery allows you to drive around a city looking at the world around you as if you were in a car. But unlike the real world, you can stop your car anywhere you like and rotate your view around 360degrees. Currently we have street-side imagery for San Francisco and Seattle online, and we are planning to have many more cities added soon.

One of the most interesting features is to put yourself in ‘Street’ view map style. In this mode, all of the street-side images are pasted flat on the map to give you a very unique overview of an area. It takes some getting used to, but once you adjust to it you’ll find it provides a very compelling companion view for our Hybrid maps. Street view helps you orient yourself quickly in an area, while the street side views then show more detail presented as you would see it in the real-world.

This technology preview is just that – a means for us to get a feature we are working on in your hands to play with and provide feedback on, before it is ready for prime time integration into the Windows Live Local site.

Sweet.

The Window Live Messenger team has a blog post about the newest version of the Windows Live beta. My favorite new feature is described below

Live Contacts are Live! Click the button on the back of your contact card to enter in all your information (phone number, address, job, spouse , etc).

With your permission, friends can see your entered info on your contact card. Anytime you update it (new phone? new job? new wife? ) they'll see it.

Similarly, subscribe to get your friends' Live Contact information by clicking the backs of their contact cards.

Live Contacts is a rather cool feature that our team has been working on for a while. It will be integrated across a number of Windows Live properties and is already available in MSN Spaces.

PS: I have a dozen invites for the Windows Live Messenger beta. Send me an email at my work address if you want one.

Recently I've been thinking about digital representations of self. Back in the day, when I thought about digitally representing people, I'd think about the MetaVerse which was described in the novel SnowCrash. Below is an excerpt of the novel

As Hiro approaches the Street, he sees two young couples, probably using their parents' computers for a double date in the in the Metaverse, climbing down out of Port Zero, which is the local port of entry and monorail stop.

He is not seeing real people, of course. This is all a part of the moving illustration drawn by his computer according to specifications coming down the fiber-optic cable. The people are pieces of software called avatars. They are the audiovisual bodies that people use to communicate with each other in the Metaverse. Hiro's avatar is now on the Street, too, and if the couples coming off the monorail look over in his direction, they can see him, just as he's seeing them. They could strike up a conversation: Hiro in the U-Stor-It in L.A. and the four teenagers probably on a couch in a suburb of Chicago, each with their own laptop. But they probably won't talk to each other, any more than they would in Reality. These are nice kids, and they don't want to talk to a solitary crossbreed with a slick custom avatar who's packing a couple of swords.

You can look any way you want it to, up to the limitations of your equipment. If you're ugly, you can make your avatar beautiful. If you've just gotten out of bed, your avatar can be wearing beautiful clothes and professionally applied makeup. You can look like a gorilla or a dragon or a giant talking penis in the Metaverse. Spend five minutes walking down the Street and you will see all of these.

The one problem with the MetaVerse is that it primarily focuses on recreating the world with all of its limitiations when it comes to self expression. appearance. The only way people get to tell more about themselves is by how they look or by being spoken to. This isn't much different from the real world. That sucks.

I've come to realize that a new generation of social networking applications are fixing this problem with online representations of our personalities. I went clubbing this weekend and couldn't help but notice that everyone from the DJ at the techno club (DJ Niros) to rappers pimping their next album at the hip hop club (E 40) had a MySpace profile. I was watching TV and discovered that even movies and TV shows have MySpace profiles. I have a member of my household who obsessively hangs out on MySpace while online chatting with her friends.

Things get even more interesting when you factor in how modern social networking tools have changed dating rituals among young adults.  First of all,  there's the eternal wisdon of Jamie Zawinski who in his article Groupware Bad wrote

So I said, narrow the focus. Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?

That got me a look like I had just sprouted a third head, but bear with me, because I think that it's not only crude but insightful. "How will this software get my users laid" should be on the minds of anyone writing social software (and these days, almost all software is social software).

"Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

Some may laugh but I've met more than one college student who's said that she looks up potential dates in Facebook before going out with them. Or how about this comment from Jim Gilliam where he wrote

All this talk about MySpace lately. As someone who was part of the Los Angeles indie music scene that is now credited with making MySpace cool, I can tell you it was all about hooking up. It started at Friendster, but we broke it cause everyone started using it. So off to MySpace.

That girl you saw at the club? You could probably find her on MySpace even if you didn't know her name.. just by going through your friends and their friends. Then you either started flirting, stalked her, saw she was underage, or hated her musical tastes so much you got over it.

The MetaVerse from SnowCrash could not have enabled this level of insight into people's personalities with the limitations of just focusing on customizing ones appearance. With an online space I can share my thoughts, my music, my friends, my interests and my life with friends, family and strangers. This is a better MetaVerse than what existed in science fiction novels.

The reason I love my day job is that this is the kind of software I get to build. Every day is a holiday.

Last week I saw links to Jason Calcanis's post YouTube is not a real business which I didn't read at the time because I wasn't that familiar with YouTube. However, over the past few days I've been watching a ton of videos on the site including the MySpace movie. I have to say I totally agree with what Jason Calcanis wrote below

4. YouTube is not a real business (or an innovative business). This is my main point. Let's not look at YouTube's page views and claim they are some amazing business. Napster and Kazaa had a ton of traffic too--it just wasn't web-based. If you could do an Alexa graph of Kazaa, BitTorrent, Usenet, and the old Napster they would be number one through four on Alexa!

Watching DIGG, Engadget, and MySpace climb in the rankings? Those are real businesses. If those sites added the ability to distribute stolen video in two clicks they would shoot up to the top 10 sites!

Let me break it down: YouTube and other video hosting sites have made it easy to pirate stuff on the web (which is where piracy started), but they shouldn't be positioned as some revolutionary business.

Like the original Napster, YouTube seems to be primarily about making money off of copyright infringement. A lot of the most popular videos don't seem to be have been uploaded by copyright holders unlike other video services like MSN Video or Google Video.

What I wonder is whether copyright infringement lawsuits will eventually shut them down or they'll end up getting both by a major player before that happens. They definitely have become a good brand and they do have some skills when it comes to scaling a popular service [although the server seems to be giving me HTTP 500 errors this morning]. It would be a shame for them to end up like Napster did.

One of the interesting side effects of blogs is that it tells you more about people than you can ever learn from reading a resume or giving an interview. This is both good and bad. It's good because in a professional context it informs you about the kind of people you may or should want to end up working with. It's bad, for the same reasons.

Blogs Make Me Sad
I find all the "Web 2.0" hype pretty disgusting. Everytime I read a discussion about what makes a company "Web 2.0" or not, I feel like I've lost half a dozen IQ points. Everytime I see someone lay on the "Web 2.0" hype I mentally adjust my estimation of their intelligence downward. The only folks this doesn't apply to are probably Tim O'Reilly and John Battelle because I can see the business reasons why they started this hype storm in the first place. Everyone else comes of as a bunch of sheep or just plain idiots.

Some folks are worse than others. These are the self proclaimed "Web 2.0" pundits like Dion Hinchcliffe who's blessed us with massively vacuous missives like Thinking in Web 2.0: Sixteen Ways and Web 2.0 and the Five Walls of Confusion. Everytime I accidentally stumble on one of his posts by following links from other's posts I feel like I've become dumber by having to read the empty hype-mongering. Russell Beattie's WTF 2.0 shows that I'm not the only person who is disgusted by this crap.

I was recently invited to Microsoft's SPARK workshop and was looking forward to the experience until I found out Dion Hinchcliffe would be attending. Since the event aims to be audience driven, I cringe when I think about being stuck in some conference hall with no way to escape listening to vacuous  "Web 2.0" hype till my ears bleed. If I had any sense I'd just not attend the conference, but who turns down a weekend trip to Vegas?

If not for blogs, I wouldn't know about Dion Hinchcliffe and could attend this workshop with great expectations instead of feelings of mild dread.

Blogs make me sad.

Blogs Make Me Happy
One of the things I loved about working on the XML team at Microsoft was all the smart people I got to shoot the breeze with about geeky topics every day. There were people like Michael Brundage, Derek Denny-Brown, Joshua Allen, and Erik Meijer who I felt made me smarter everytime I left their presence.

With blogs I get this feeling from reading the writings of others without having to even be in their presence. For example, there are so many lessons in Shelley Powers's recent post Babble that a summary doesn't do it justice. Just go and read it. It made me smile.

Blogs make me happy.

Yahoo! announced some cool stuff last week. In his blog post Yahoo! UI JavaScript treats Simon Willison writes

The Yahoo! Developer Network was updated yesterday with a veritable gold-mine of Exciting New Stuff, coinciding with the launch of the brand new Yahoo! User Interface Blog. #

Here are some of the highlights: #

• Mature, extensively tested cross-browser JavaScript libraries for animation, event handling, DOM wrangling, XMLHttpRequestDrag and Drop. # and

• CSS-skinnable UI controls built on those libraries: Calendar, Slider and TreeView. #

• A library of documented design patterns for modern web applications. #

• A description of Yahoo!'s Graded Browser Support policy, which should be of great interest to anyone who cares about Web Standards, semantic HTML, accessibility, progressive enhancement and unobtrusive JavaScript. #

The code is all under a BSD Open Source license, which means you can use it freely in your own projects, including for commercial development. #

This is a fantastic contribution to the Web developer community by Yahoo!. It's taken me a week to blog about it because I wanted to try it out first. Unfortunately  I still haven't gotten around to trying out the code but I decided to give it a shout out anyway. This is basically what I expected Microsoft to provide developers with Atlas but not only has Yahoo! done it first, it has done so in a way that is completely free (as in speech and as in beer). Wow. 

The folks at Yahoo! are definitely understand what it means to build a developer platform and a developer community on the Web. Kudos to everyone involved in getting this out. 

In his post More SOAP vs. REST arguments Stefan Tilkov askes

I just noticed an interesting thing in the most recent iteration of the SOAP-vs.-REST debate: this time, nobody seems to have mentioned the benefit — if you believe that’s what it is — of protocol independence. Why is that?

For the record, I personally believe it’s one of the weakest arguments.

When I was on the XML team, we used to talk about XML infosets and data format independence to imply that it made sense if people could use transfer formats that were optimized for their use cases but still get the benefit of the XML machinary such as XML APIs (DOM, SAX, etc), XPath querying, XSLT transformations, etc. This philosophy is what has underpined the arguments for protocol independence at the SOAP level.

Now that I'm actually a customer of web services toolkits as opposed to a builder of the framework that they depend on, my perspective has changed. Protocol independence isn't really that important at the SOAP level. Protocol independence is important at the programming model/toolkit level. I should be able to write some business logic once and then simply be able to choose to expose it as SOAP, XML-RPC, RSS, or a proprietary binary protocol without rewriting a bunch of code. That's what is important to my business needs.  

It took a while but I eventually convinced some of the key Indigo folks that this was the right direction to go with in the Windows Communication Foundation. I damn near clapped when Doug demoed a WS-Transfer RSS service exposing a HTTP/POX endpoint, a HTTP/SOAP endpoint, and a TCP/Binary SOAP endpoint at an internal summit a couple of months ago.

Bottom Line: Protocol independence is important to providers of Web services. However it isn't required at the SOAP level.

From Matt Cutt's blog post about the Google Page Creator we learn

Oh, and by the way, it looks like Google has released a tool to make mini-websites. The Google Page Creator at http://pages.google.com/ lets you throw up a quick set of pages without a ton of hassle. Looks like a bunch of different look ‘n’ feel choices:

I feel like I'm in a time warp. Did Google just ship their own version of GeoCities? Isn't this space dead? End users have graduated from personal home pages to blogs and social networking tools which is why sites like MySpace, MSN Spaces and Xanga have tens of millions of users. Business users are likely to want an entire package like Office Live instead of just a web page creation tool.

Who exactly is the target audience for this offering?

Update: I just noticed that username@gmail.com is equal to username.googlepages.com. How do you ship a product with such an obvious privacy bug? I guess if you are creating a 20% project you don't need to have privacy reviews. Doh!

When you build web applications that have to scale up to millions of users, you sometimes end up questioning almost every aspect of your design as you hit scalability problems. One thing I hadn't expected was to notice that a number of people in our shoes had begun to point out the limitations of SQL databases when it comes to building modern Web applications. Below are a sampling of such comments primarily gathered together so I have easy access to them next time I want an example of what I mean by limitations of SQL databases when building large scale Web applications.

1. From Google's Adam Bosworth we have the post Where Have all the Good databases Gone

   The products that the database vendors were building had less and less to do with what the customers wanted...Google itself (and I'd bet a lot Yahoo too) have similar needs to the ones Federal Express or Morgan Stanley or Ford or others described, quite eloquently to me. So, what is this growing disconnect?

   It is this. Users of databases tend to ask for three very simple things:

   1) Dynamic schema so that as the business model/description of goods or services changes and evolves, this evolution can be handled seamlessly in a system running 24 by 7, 365 days a year. This means that Amazon can track new things about new goods without changing the running system. It means that Federal Express can add Federal Express Ground seamlessly to their running tracking system and so on. In short, the database should handle unlimited change.

   2) Dynamic partitioning of data across large dynamic numbers of machines. A lot people people track a lot of data these days. It is common to talk to customers tracking 100,000,000 items a day and having to maintain the information online for at least 180 days with 4K or more a pop and that adds (or multiplies) up to a 100 TB or so. Customers tell me that this is best served up to the 1MM users who may want it at any time by partioning the data because, in general, most of this data is highly partionable by customer or product or something. The only issue is that it needs to be dynamic so that as items are added or get "busy" the system dynamically load balances their data across the machines. In short, the database should handle unlimited scale with very low latency. It can do this because the vast majority of queries will be local to a product or a customer or something over which you can partion...

   3) Modern indexing. Google has spoiled the world. Everyone has learned that just typing in a few words should show the relevant results in a couple of hundred milliseconds. Everyone (whether an Amazon user or a customer looking up a check they wrote a month ago or a customer service rep looking up the history for someone calling in to complain) expects this. This indexing, of course, often has to include indexing through the "blobs" stored in the items such as PDF's and Spreadsheets and Powerpoints. This is actually hard to do across all data, but much of the need is within a partioned data set (e.g. I want to and should only see my checks, not yours or my airbill status not yours) and then it should be trivial.
   ...
   Users of databases don't believe that they are getting any of these three. Salesforce, for example, has a lot of clever technology just to hack around the dynamic schema problem so that 13,000 customers can have 13,000 different views of what a prospect is.

   If the database vendors ARE solving these problems, then they aren't doing a good job of telling the rest of us.

2. Joshua Schachter of del.icio.us is quoted as saying the following in a recent talk

   Scaling: avoid early optimization. SQL doesn't map well to these problems - think about how to split up data over multiple machines. Understand indexing strategies, profile every SQL statement. Nagios or similar for monitoring.

   Tags don't map well to SQL. Sometimes you can prune based on usage - only index the first few pages for example. This keeps indexes small and fast.

3. Mark Fletcher of Bloglines wrote the following in his post Behind the Scenes of the Bloglines Datacenter Move (Part 2)

   The Bloglines back-end consists of a number of logical databases. There's a database for user information, including what each user is subscribed to, what their password is, etc. There's also a database for feed information, containing things like the name of each feed, the description for each feed, etc. There are also several databases which track link and guid information. And finally, there's the system that stores all the blog articles and related data. We have almost a trillion blog articles in the system, dating back to when we first went on-line in June, 2003. Even compressed, the blog articles consist of the largest chunk of data in the Bloglines system, by a large margin. By our calculations, if we could transfer the blog article data ahead of time, the other databases could be copied over in a reasonable amount of time, limiting our downtime to just a few hours.

   We don't use a traditional database to store blog articles. Instead we use a custom replication system based on flat files and smaller databases. It works well and scales using cheap hardware.
   
   

Interesting things happen when you question everything. 

Yesterday, Mark Baker asked Why all the WS Interop problems?.

If you'd have asked me six or seven years ago - when this whole Web services things was kicking off - how things were likely to go with them, I would have said - and indeed, have said many times since - that they would fail to see widespread use on the Internet, as their architecture is only suitable for use under a single adminstrator, i.e. behind a firewall. But if you'd asked me if I would have thought that there'd be this much trouble with basic interoperability of foundational specifications, I would have said, no, I wouldn't expect that. I mean, despite the architectural shortcomings, the job of developing interoperable specifications, while obviously difficult, wouldn't be any more difficult because of these shortcomings... would it?

In my opinion, the answer to his question is obvious. A few months ago I wrote in my post The Perils of Premature Standardization: Attention Data and OPML that

I used be the program manager responsible for a number of XML technologies in the .NET Framework while I was on the XML team at Microsoft. The technology I spent the most time working with was the XML Schema Definition Language (XSD). After working with XSD for about three years, I came to the conclusion that XSD has held back the proliferation and advancement of XML technologies by about two or three years. The lack of adoption of web services technologies like SOAP and WSDL on the world wide web is primarily due to the complexity of XSD.

If you read the three posts that Mark Baker links to about SOAP interop problems, you'll notice that two of them are about the issues with mapping xsi:nil and minOccurs="0" to concepts in traditional object oriented programming languages [specifically C#]. If a value is null does that map to xsi:nil or minOccurs="0"? How do I differentiate the two in a programming language that doesn't have these concepts? How do I represent xsi:nil in a programming  language where primitive types such as integers can't be null? 

The main problem with WS-* interop is that vendors decided to treat it as a distributed object programming technology but based it on a data typing language (i.e. XSD) which does not map at all well with traditional object oriented programming languages. On the other hand, if you look at other XML-Web-Services-as distributed-objects technology like XML-RPC, you don't see as many issues. This is because XML-RPC was meant to map cleanly to traditional object oriented programming languages.

Unfortunately I don't see the situation improving anytime soon unless something drastic is done.