October 7, 2006
@ 04:55 PM

Jeremy Zawodny has a blog post entitled A List of Amazon S3 Backup Tools where he writes

In an effort to replace my home backup server with Amazon's S3, I've been collecting a list of Amazon S3 compatible backup tools to look at. Here's what I've discovered, followed by my requirements.

...

  • s3DAV isn't exactly a backup tool. It's provides a WebDAV front-end (or "virtual filesystem") to S3 storage, so you could use many other backup tools with S3. Recent versions of Windows and Mac OS have WebDAV support built-in. Java is required for s3DAV.
...

I was chatting with a coworker last week and one thing we couldn't figure out is why Amazon S3 doesn't use WebDAV as their REST protocol. Besides the fact that there are WebDAV clients widely deployed on major operating systems from Mac OS to Windows (including Windows Explorer and Microsoft Office), adopting WebDAV wouldn't even require that many changes to the Amazon S3 REST API. All you'd need to do is

  1. Replace the URLs for listing keys with supporting the PROPFIND method.

  2. Replace the usage of custom HTTP headers prefixed with "x-amz-meta-" for adding or retrieving user-defined metadata for objects with supporting PROPPATCH and PROPFIND methods for setting and getting the object's metadata.

  3. Support the COPY and MOVE methods by translating them to PUT and PUT + DELETE operations respectively

  4. Return an HTTP 501 error code when applications attempt to perform LOCK or UNLOCK operations since Amazon S3 doesn't support locking objects.

The last one is tricky because there are a number of WebDAV clients that don't fail gracefully if the server doesn't support LOCK and UNLOCK but in general I think supporting WebDAV would have made the reach of S3 even greater. I wonder if the folks at Amazon even considered that as an option or whether it was an explicit choice?


 

Categories: XML Web Services

October 7, 2006
@ 02:33 AM

Tim Bray has a blog post entitled On Comments where he writes

I’ve had comments running for a few days here now (I prefer to say “contributions”, but whatever). People are irritated at me because an ongoing fragment shows up as unread in their feed-reader whenever a new comment comes in. I’m not sure what the right thing to do is. This piece outlines a few options and asks the community for discussion.

This is one of the reasons I've given about disliking the atom:updated element in blog posts like Indicating Updated Items in RSS Bandit. It should be up to the user to decide what count as 'significant' updates that warrant marking the item as changed or new in the user interface, not the publisher. Tim thinks that new comments in a blog post should lead to the reader being notified by their aggregator, I think this should only be the case when the user has explicitly opted in for notifications on changed new comments. This doesn't extend to updates because the definition of what counts as a 'significant' update is going to vary from publisher to publisher and from user to user.

My advice to Tim is to  use the Atom threading extensions which provides explicit mechanisms for indicating changes to the number of comments and provides a way to link to comment feeds as opposed to hacks like changing the value of atom:updated or putting the comments into the atom:content of the entry. Those both sound like recipes for a negative user experience when reading his blog in many aggregators.

The title of this blog post is probably harsher than I intend. I think it is useful to have a last modified date in the form of atom:updated on items in a feed. What I disagree with is impacting the user experience based on changes to that element.


 

October 5, 2006
@ 05:03 PM

After my workout this morning, I was in the locker getting undressed to shower when I turned around after locking my locker and realized someone had taken my towel. So there I am in my birthday suit with no towel yet about to take a shower. So I have to make a decision do I

  1. Get dressed and go back to the front desk to get another towel?
  2. Hang around the locker room until an attendant shows up and ask him for a towel?
  3. Take a shower without a towel and "air dry"?
  4. Steal somebody else's towel?

Guess which one I picked? :)


 

Categories: Personal

Last year, in the comments to a blog post entitled Career Development at Microsoft: The internal interview process, there was the following exchange

# re: Career Development at Microsoft: The internal interview process

Monday, October 24, 2005 11:38 PM by hrbp
I have a question.
For internal candidates, is there a selection meeting including the job owner (manager), supervisors of the internal candiates, a representative from the talent management team, and the HR gen? If not, will the job owner talk with the candidate's current supervisor?
Thanks.

# re: Career Development at Microsoft: The internal interview process

Tuesday, October 25, 2005 4:22 PM by JobsBlog
Hrbp - The hiring manager (job owner) will look at the employee's previous reviews and speak with his/her manager AFTER the employee has notified his/her team of upcoming interviews. The current manager must also grant the employee "permission to interview."

gretchen

The concept of "Permission to Interview" is probably the worst idea that Microsoft's HR group has come up with and this is after considering other questionable practices like The Curve & getting rid of the towel service. What happens when you tell your manager you want permission to leave the team? First of all, your manager has veto power over this decision or at the minimum can delay it for months at a time. Secondly, you're automatically labelled as a "bad" employee which sucks if you don't make it through the interviews on the team you want to transfer to or your opportunity to move is delayed for so long the other team finds someone else. 

I've lost count of the amount of times I've heard someone say that they or someone they know is interviewing with Google or some other external company because they (i) don't want to risk asking for permission to interview or (ii) their management team has placed a temporary ban on permissions to interview. This means that the awesome thing about "permission to interview" is that it encourages people to leave the company once they've decided to leave a team because they are no longer a good fit or have a bad manager.

Why am I writing about this now? See the Mini-Microsoft post Microsoft Internal Transfers Just Got a Whole Lot Easier. Another Dilbert-style HR practice bites the dust. Lisa Brummel is slowly becoming my favorite Microsoft employee.


 

Categories: Life in the B0rg Cube

Dick Hardt has a blog post critical of Yahoo's recently announced BBAuth entitled Yahoo’s Identity Silo where he writes

Yahoo has joined Google’s silo building by releasing BBAuth, a mechanism for other sites to access services and data within the world of Yahoo.

Unlike Google’s Account Authentication, Yahoo is allowing their service to be used for SSO and registration.

BBAuth is clearly targeted at Web 2.0 site developers, encouraging them to build apps on the Yahoo platform so that they get access to all those Yahoo users.. While I understand how this helps Yahoo strengthen their relationship with their users, it would seem Yahoo did not learn what Microsoft learned with Passport, as Yahoo is deepening their identity silo, rather then participating in the emerging identity infrastructure.

Given that I've been crusading for Microsoft to build solutions similar to BBAuth and Google's Account Authentication for Windows Live I'm interested in whatever criticisms of these approaches exist. The first thing I should note is that I don't like the term "identity silo". On the one hand it could be considered accurate but on the other it automatically potrays the party being described in a negative light. It's like using the term "baby killer" to describe people who consider themselves pro-choice. Any website which authenticates its users (i.e. has a username/password requirement to utilize aspects of the site) is an "identity silo" because the identity I've created on that site is only usable on that site and cannot be utilized elsewhere.

Lots of really smart people from big companies (e.g. Kim Cameron of Microsoft) and startups (e.g. Dick Hardt of SXIP Identity) with products to sell have now told us that "identity silos are bad m...kay". Since I drink the company Kool Aid, I agree with this premise. From reading Kim Cameron's The Laws of Identity and Microsoft's Vision for an Identity Metasystem it seems the solution to the problem of identity silos is federated identity where I can use credentials from one site to sign-in to another site as long as the sites trust each other. This sounds cool, it's like the promise of Single Sign On without one company trying to be your Passport to using the Internet. :)

So let's say I'm a website that wants to allow users to access their data from other sources besides my wbesite thus liberating their data and enabling new applications, visualizations and mashups. I need some way to figure out whose data to give out to these mashups when they come calling...I know, I'll use the unique username to figure out whose data I'm to give out and I can verify that its really the user asking because I'll require their password. Except, according to Dick Hardt and Eric Norlin this is bad because I'm deepening my "identity silo". Since I'm a practical guy I have only two questions

  1. Are there shipping technologies today that allow me to do what I want in an "Identity 2.0" way?
  2. Are they as easy to implement as telling mashup developers to include a link to my website in their UI and then process the data they get back when the user is redirected back to their site after signing in?
From my reading, the answer to question #1 is No (but we're really close) and the answer to question #2 is Hell No. If you were Yahoo! or Google, would you wait a few years for a technology that is more difficult for the developers you are targeting to adopt than what you can roll on your own today to meet your needs? If the answer is no, does that make you a "baby killer"?

Let me know what you think.


 

I just got a comment to my previous blog post which pointed out that it's been a long time since the last release of RSS Bandit and asked whether development has stopped. Torsten and I are still hard at work on the project but development has been slow because this is a side project for both of us which we only get to work on when we have free time. Anyway here's a general status update for the next release which is currently codenamed Jubilee.

Completed Features

Features in progress

  • Podcasting support - Think of it as adding the most useful features of Doppler Radio or Juice Receiver to RSS Bandit.
  • Revamping the search feature - We're moving the implementation of feed search to Lucene.Net from our custom feed search implementation which should make it faster and provide richer search options
  • Remembering application state on restart - This will work similar to the Session Saver extension in Firefox in that open tabs and the tree view state will be remembered on restart

Major problems to fix

Postponed features

As far as dates go, the only thing I will commit to is that we will have a release this year. I expect that we will be ready to provide a beta release by the end of October or early November at the latest with a final release in time for the holiday season.
 

Categories: RSS Bandit

Via Jeremy Zawodny I noticed that Yahoo! has finally launched their Browser Based Authentication (BBAuth) system which they announced at ETech earlier this year. What does BBAuth do?

To use BBAuth, you'll need to do the following:

  1. Register your application

    First you need to register your application with Yahoo!. The process requires that you describe what your application does, provide contact information, set your application's endpoint URL, and select the Yahoo! services to which your application needs access. Some services may divide their API calls into subsets, or scopes. For example, a service might group its read-only methods into a single scope.

    When you complete registration, Yahoo! provides you with an application ID and shared secret for making authenticated service calls.

  2. Log in your users

    Your application cannot access a user's personal data until the user grants your application limited access to their data. To do this you must direct your users to a specialized Yahoo! login page. Once the user enters their Yahoo! user ID and password, Yahoo! displays a Terms of Service page and lists the data which your application may access. If the user grants your application access, Yahoo! redirects the user to your site. The redirect URL contains a token that you use to retrieve the user's credentials.

  3. Use the user's credentials to make web service calls

    Now that you have the user's token, you can use it to retrieve an auth cookie and a WSSID, which together represent the user's credentials. The user's credentials last for one hour, and you must supply them for each authenticated web service call.

This is very similar to Google Account Authentication Proxy for Web-Based Applications. However Yahoo! doesn't seem to have a good story for desktop applications that want to use their APIs on behalf of a user (e.g. a desktop photo management application that wants to upload photos to a users Yahoo! Photos account). On the other hand, Google's authentication system for developers actually does cover the desktop case with Account Authentication for Installed Applications which even goes as far as incorporating CAPTCHAs which the desktop app needs to show to the user as they log them in. The only problem is that unlike the Web case, the desktop application actually collects the username and password which I've already mentioned is a big no-no. However the alternatives have trade offs which I can't blame the Google folks for rejecting. I still can't come up with a solution to this problem that I am 100% comfortable with.

Props to the folks at Google and Yahoo! for opening up their systems in this way. One thing I definitely don't like is that both Google via Google Account Authentication and Yahoo! va BBAuth have shipping code that allows developers to authenticate users that use their services while at Microsoft we're still just talking about it. We need to up our game.


 

September 30, 2006
@ 05:18 AM

Adam Barr has a blog post entitled Trying to Grok Windows Live where he writes

At the Company Meeting last week, Ray Ozzie stood up and gave a very nice, very inspiring speech about how we have to shift the company to Live (Windows Live, Office Live, etc). He spoke without slides or notes and it's obviously something he cares a lot about and has thought a lot about. I'm entirely convinced that he has a great vision of the future in his mind.

The only problem is, I really don't know what he is talking about.

I'm fully prepared to believe it's because I'm too dense to understand. But when he talks about "betting the company on Windows Live", what does that mean? How does Windows become a service? I understand that there are things we need to do in order to make the Internet a platform; back in 2000 I wrote that I thought that's what .Net was. But I don't see how this involves changing Windows in some fundamental way.

This isn't the first time I've heard someone from Microsoft say they don't understand what Ray Ozzie is talking about when he talks about "Live" software. I feel such a disconnect when I hear this because when I read Ray's "Internet Services Disruption Memo, I was like "Duh" so it is difficult to understand the perspective of people who don't appreciate the power of the Web.

From my perspective, Ray Ozzie's memo and his various speeches have one simple message

  1. The Web has fundamentally changed the face of computing.
  2. The Web is here to stay.
  3. The world's largest software company has to adapt to this reality
A good analogy for understanding what it means for software to embrace the Web is to compare an application like WinAmp 3.0 which plays music on your hard drive or from CD to iTunes 7.0 which plays music on your hard drive or from CD and can be used to purchase music from an online store and can be used to subscribe to podcasts on the Web. One doesn't have to resort to "creating an AJAX version of WinAmp" or whatever other straw man argument usually comes up in this context to turn a desktop MP3 player into "Live" software. iTunes shows that.

What Microsoft needs to do is repeat that lesson across all of its products and think about how they can embrace the Web instead of simply reacting to it or barely acknowledging its existence.


 

September 30, 2006
@ 12:16 AM

Lately I find that the stories I have been writing turn out not to be suitable for publication. It makes me kind of sad, because I've written a few things recently that I think are actually really good, but I haven't published them here, because if I did, there would be people who would never speak to me again. Either people who are too close to the stories to think they're funny, or people who are too far away from them to think they're funny.

I think maybe the problem is that I really didn't write them well enough at all: if I'd done my job, then everyone reading them would understand why they were funny. If it only makes sense to people who think like me, then I haven't done my job, right?

Jamie Zawinski

A few days ago I wrote a blog post entitled Leaving MSFT in Five Years: Year One which was meant to be a follow up to a blog post I wrote a year ago entitled On Moving On From Microsoft in 5 Years. After writing it, I realized I didn't have the stomach to deal with whatever comments or emails I got about the post whether they were good or bad. Just writing the blog post was cathartic even though I never published it and probably never will.

However this afternoon, I saw a blog post Rebuilding Microsoft in Wired Magazine on the Mini-Microsoft blog which talks about the winds of change at Microsoft. I felt drawn to comment even if my comment is just that I like the changes that have been occuring at Microsoft over the past year and I like having leadership like Ray Ozzie, Steven Sinofsky and Chris Jones running Windows Live.

Have a good weekend. See you at Chuck-E-Cheese's. :)

 

Categories: Life in the B0rg Cube

September 28, 2006
@ 06:05 PM
Steve Yegge, who works at Google, has a blog post entitled Good Agile, Bad Agile which has a lot of really interesting bits. The first is his take on the origin of Extreme Programming where he writes
So some of the consultants began to think: "Hey, if these companies insist on acting like infants, then we should treat them like infants!" And so they did. When a company said "we want features A through Z", the consultants would get these big index cards and write "A" on the first one, "B" on the second one, etc., along with time estimates, and then post them on their wall. Then when the customer wanted to add something, the consultant could point at the wall and say: "OK, boy. Which one of these cards do you want to replace, BOY?"

Is it any wonder Chrysler canceled the project?

So the consultants, now having lost their primary customer, were at a bar one day, and one of them (named L. Ron Hubbard) said: "This nickel-a-line-of-code gig is lame. You know where the real money is at? You start your own religion." And that's how both Extreme Programming and Scientology were born.

The link which explains that Chrysler cancelled the project where a lot of the Extreme Programming and Agile Methodology hype started is on Wikipedia so for all I know that clarification may be gone by the time you read this post. Unfortunately in trying to track down the details in more permanent location all I can find is a USENET thread and more wiki entries. That's pretty interesting, that XP and Agile resulted in a failed software project in the original project where it all started.

There is also some stuff about working at Google where he writes

From a high level, Google's process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:

- there are managers, sort of, but most of them code at least half-time, making them more like tech leads.

- developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

- Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.

- developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.

- there aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.

- it's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.

- there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.

- even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to.

For some reason this reminds me of Malcolm Gladwell's The Talent Myth which is excerpted below

This "talent mind-set" is the new orthodoxy of American management. It is the intellectual justification for why such a high premium is placed on degrees from first-tier business schools, and why the compensation packages for top executives have become so lavish. In the modern corporation, the system is considered only as strong as its stars, and, in the past few years, this message has been preached by consultants and management gurus all over the world. None, however, have spread the word quite so ardently as McKinsey, and, of all its clients, one firm took the talent mind-set closest to heart. It was a company where McKinsey conducted twenty separate projects, where McKinsey's billings topped ten million dollars a year, where a McKinsey director regularly attended board meetings, and where the C.E.O. himself was a former McKinsey partner. The company, of course, was Enron.
...
"We had these things called Super Saturdays," one former Enron manager recalls. "I'd interview some of these guys who were fresh out of Harvard, and these kids could blow me out of the water. They knew things I'd never heard of." Once at Enron, the top performers were rewarded inordinately, and promoted without regard for seniority or experience. Enron was a star system. "The only thing that differentiates Enron from our competitors is our people, our talent," Lay, Enron's former chairman and C.E.O., told the McKinsey consultants when they came to the company's headquarters, in Houston.
...
Among the most damning facts about Enron, in the end, was something its managers were proudest of. They had what, in McKinsey terminology, is called an "open market" for hiring. In the open-market system--McKinsey's assault on the very idea of a fixed organization--anyone could apply for any job that he or she wanted, and no manager was allowed to hold anyone back. Poaching was encouraged. When an Enron executive named Kevin Hannon started the company's global broadband unit, he launched what he called Project Quick Hire. A hundred top performers from around the company were invited to the Houston Hyatt to hear Hannon give his pitch. Recruiting booths were set up outside the meeting room. "Hannon had his fifty top performers for the broadband unit by the end of the week," Michaels, Handfield-Jones, and Axelrod write, "and his peers had fifty holes to fill." Nobody, not even the consultants who were paid to think about the Enron culture, seemed worried that those fifty holes might disrupt the functioning of the affected departments, that stability in a firm's existing businesses might be a good thing, that the self-fulfillment of Enron's star employees might possibly be in conflict with the best interests of the firm as a whole.

Interesting juxtaposition, huh? I've talked to people who've come to Microsoft from Google (e.g. Danny Thorpe) and it definitely is as chaotic as it sounds there. For some reason, the description of life at Google by Steve Yegge reminds me a bit of Microsoft where there were two huge money making projects (Office & Windows in the case of Microsoft and AdWords & AdSense in the case of Google) and then a bunch of good to mediocre projects full of smart people dicking around. Over the years I've seen a reduction of the 'smart people dicking around' type projects over here and more focus on shipping code. I suspect that it's just a matter of time before the same thing will happen at Google as investors seek a better return on their investments once they hit their growth limits in the online advertising space.

There's just one more thing that Steve Yegge wrote that I want to comment on, which is

The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude. You can't help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.

I remember interning at Microsoft five years ago and hearing someone say how grateful he was for "the things Microsoft has done for me" and thinking how creepy and cult-like that sounded. A company pays you at worst 'what they think they can get away with' and at best 'what they think you are worth', neither of these should inspire gratitude. Never forget that or else you'll be on the road to heartbreak.