zAlternator is an app that allows the Zune to sync with other software clients like Windows Media Player (WMP), MediaMonkey and even Winamp!  From their site:

Finally, a release candidate of zAlternator is here! Yay! zAlternator is a program that will allow the Zune to be picked up and synced with programs other than the Zune program. It has been fully tested and proven to allow the Zune to be picked up and synced with the Zune program (duh), Windows Media Player 11, Winamp, and MediaMonkey. I have been unable to fully test the iTunes side of the program, but hopefully it should work.

While I love the Zune v2 software, the current lack of support for dynamic playlists and editing ID3 tag information is enough to turn me to WMP11.  I’ll jump right back to the Zune software when the Zune team adds these 2 features.

I spent quite a few hours today customizing my portfolio that I have hosted on Smugmug.  It’s such a pain in the butt to customize anything through SmugMug since I have to override everything with their rudimentary customization UI using javascript and CSS hacks. 

I’m pretty happy with it now and have to work on getting the “search” page to work so there’s an easy way for visitors to find photos based on keywords or dates. 

Drop by and let me know what you think of the new layout and customizations.

After I upgraded my last wordpress installation on my blog and on Green Is Sexy, strange characters were appearing in our content throughout the site. There seemed to have been encoding problems with apostrophes (’), quotation marks (”) and hyphens (-). They’d be displayed as question marks or ’.

Turns out that the fix is really simple. By default, the Wordpress config files now set your character encoding to UTF-8. The solution is to open up wp-config.php file and located these lines:

define(’DB_CHARSET’, ‘utf8′);
define(’DB_COLLATE’, ”);

and either remove the “utf8″ string so the first line becomes:

define(’DB_CHARSET’,'');
define(’DB_COLLATE’, ”);

or you can just comment the lines out completely by prefixing each line with “//”:

//define(’DB_CHARSET’, ‘utf8′);
//define(’DB_COLLATE’, ”);

Problem solved!

FASTER! FASTER! FASTER!

This is war cry we all know too well these days with the advent of “Web 2.0″. How quickly a service can be brought to market can either make or break a startup. The benefits of first-mover advantage can’t be discounted especially when buzz and eyeballs are so important these days to build a brand and grow a userbase.

However, with the desire to move to shorter development cycles and get to the “production” environment more quickly, companies are finding ways to take shortcuts as compared to traditional methodologies. Most services at Microsoft have at least 2 staging environments prior to deploying to the “live site”.

As our development team reaches code complete, we deploy our bits to the test cluster where our QA team goes through a test pass. After meeting our test pass exit criteria, we roll the bits into an intermediary staging environment, “Pre-production”. This staging environment matches our production hardware as close as possible and we use it to do final acceptance testing. This model, while seemingly heavy-weight, helps ensure the highest quality release when we finally deploy to our live site (aka “Production”). In particular, it’s important when your product integrates with several services that you don’t own — in our case, an example would be Windows Marketplace’s integration with Windows Live ID.

I myself have often been frustrated at times when I want to go to production faster with a feature that is seemingly “small”, but I have to remind myself that the rigor in staging our releases is worth it if we’re ensuring a higher quality product at the expense of slower time to market.

However, I do think there many teams (my current one included) can work on a model that is better at identifying the lower risk features and perhaps roll that directly to live site in a throttled manner. For example, roll out a feature so 5% of our users see if, and if it breaks, roll it back. Otherwise, increase the rollout slowly over a period of time until 100% of the users are using the new feature. The entire time make sure we monitor the snot out of things.

Facebook has been given accolades for how quick they get to market with their new features. When I first started using it last year, I was impressed with how much functionality they rolled out in a given week. From Facebook’s job site:

Our development cycle is extremely fast, and we’ve built tools to keep it that way. It’s common to write code and have it running on the live site a few days later. This comes as a pleasant surprise to engineers who have worked at other companies where code takes months or years to see the light of day. If you work for us, you will be able to make an immediate impact.

In speaking with several people that know engineers at Facebook, they apparently don’t have the same QA process as Microsoft and instead often go straight production and use throttling to control a feature’s exposure. Sounds great!

However, based on my experiences over the past 6 weeks with Facebook, the pitfalls of going “Faster! Faster! Faster!” are showing in a string of very visible problems. Some juicy examples:

No profile anyone?

I’m signed in, but am invisible and profile-less.

No news feed items?

My biggest beef is there are too many news items that I can’t even begin to sift through them. But this is ridiculous

Site maintenance in the middle of the day anyone?

Seems like an odd time to have a planned outage, given Facebook is in the same timezone as I am (PST) and it’s smack dab in the middle of the day (11:35am).

30 mins later, same maintenance message, but surprise! Looks like they’ve authenticated me and can tell me how many messages I have in my inbox. Something is astray.

Awkward error messages

I got this juicy one earlier today when I tried to confirm a new friend request. Some debugging message that it getting piped through to the FE users?

I’m definitely not saying that Facebook’s process is bad and Microsoft’s is better. Just that there has to be a happy medium in doing the appropriately amount of testing and monitoring to ensure we’re striking the right balance between quality and time-to-market. In our quest to ship more features faster, we shouldn’t lose sight that we can’t screw our end users, otherwise there is no reason to ship our products at all.

At any given time, I have at least 2 blog posts in draft form that I’m waiting to put the finishing touches on before publishing. I wasn’t originally a fan of using a rich blog client since I always wanted to roam the drafts and work on them from whatever computer I happen to be at. When Windows Live Writer (WLW) was first released, like a good Microsoft cog, I jumped on it to give it a try. Truthfully, I already had a huge bias against it due to my love for the roaming drafts.

However, to my surprise, I really, really liked Windows Live Writer. It made many of the tasks I struggle with regularly in authoring my posts, like embedding images that aren’t already remotely hosted. Windows Live Writer allowed me to author my posts very intuitively by enabling me to insert local images while I’m writing, and uploading them after I elect to publish the post. The post is then modified to have the image reference the new remote location.

Ever since falling in love with WLW, I was hoping they would release an update to fix some bugs I noticed as well as add new features. My wish came true on May 30th when The WLW team announced v2 was available for immediate download.

After eagerly downloading and installing it, I ran into a huge problem — I couldn’t even connect to my blog. I kept getting an obscure errror message that claimed I was getting a 403 Forbidden HTTP status code from the XML-RPC interface. I was able to hit the file directly without any trouble and verified that the file permissions were indeed correct. I was stumped. I did a web search and surprisingly I couldn’t find any information on it.

I emailed the Program Manager who works on the WLW team (perks of working at Microsoft I guess), and after a few emails, I was told to check if I had the Bad Behavior plugin installed (I do). It seems there is a bug in WLW v2 that makes it incompatible with that plugin.

The problem is documented by James McKay, who has a very simple fix. You just have to change the msie.inc.php file for the Bad Behavior plugin from this:

if (!array_key_exists('Accept', $package['headers_mixed'])) {
   return "17566707";
} 

to this:

if (strpos($package['headers_mixed']['User-Agent'], "Windows Live Writer")

    === FALSE && !array_key_exists('Accept', $package['headers_mixed'])) {

return "17566707";

}

After making this quick and painless change, WLW works now with my blog once again. Yipee!