Jobs / Career

Return of a Jedi

Wed, 13 Feb 2008 20:55:51 GMT

It was a long, long time ago… It was a time of a great civil war between the Outlook/Office and the Exchange teams… It was a time of great browser wars and much uncertainty... It was an era in which ancient languages such as C++ ruled the galaxy and web browsers weren't considered application development platforms.

It was during this time, I had the opportunity to work on a product that would help redefine web based e-mail and more importantly define what web applications were capable of. I was one of the first developers on the Outlook Web Access team (or as it was known back then, the Exchange Web Client). During 1996-1998, I worked with Bob Gering (R.I.P.) and Jim Van Eaton, where I created the original appointment / meeting request form, the contact form, and the Java date picker. Needless to say, it was the highlight of my professional career at Microsoft.

Unfortunately, during this great civil war, my career ended up following a different path, than that of my good friends, and I joined "the confederacy". During this period, I ended up working on random Office apps in native code, as I meandered around aimlessly from group to group, either working on products I wasn't passionate about or working for managers who were mediocre. After a few years of my career going nowhere, I left Microsoft.

During this time, my friend Qui-Gon Jim (Van Eaton) became the Jedi Master of the Outlook Web Access team, and under his stewardship OWA became the first web application to use the XMLHTTP technology, which is today referred to as AJAX and continued to grow its proud legacy into the great application you know and love today. Unless of course, you use a browser that doesn't suck, in which case you'll never know how good OWA really is, which brings us to the present day.

You see, Microsoft fumbled the ball during the dot com bust. After building a huge market share & mind share lead in the browser wars, Microsoft disbanded the IE team and essentially walked away from improving its client side internet technologies (fortunately, they invented .net during this time, and improved it's server side software, but IE was essentially trapped in a time capsule from 2001-2005). I suppose at the time it seemed like a smart move since AOL purchased Netscape, and neither AOL, Netscape nor the Mozilla foundation were going anywhere. Furthermore, Steve Jobs second coming at Apple was still in its early stages and Google was merely a good search engine and not yet a verb.

Except, at some point during that era, we hit a strategic inflection point. Firefox got invented, kept improving and kept innovating. All while the majority of the former IE team was trapped in the Vista tar pit. In a few short years, IE 6 went from first to worst in mind share, due to the Firefox team playing the tortoise to Microsoft's hare. Even worse, Google took advantage of Microsoft's internet client myopia and made a web e-mail client that worked great on IE and Firefox (and gave away gigabytes of storage space to sweeten the deal). Shortly afterward Apple released Safari, Google released Google Maps, Microsoft released Virtual earth, and the Web was re-born.

Anyway, the OWA team kept innovating during this era of uncertainty, and ended up with a great AJAX client that only worked on IE because when it was designed 1) there were no other browsers that supported AJAX / DHTML except IE and 2) there were no standards to follow because there were no other browsers that had implemented them yet. I suppose myopia played a role as well, but by the time the other browsers gained mind share, the OWA's development plans were already set in Carbonite.

When I was on the OWA team, we supported IE & Netscape equally well (perhaps equally poorly is a better choice of words, because web browsers and web applications were so much simpler & less complex back then). However, during the past 10 years, we've witnessed the rise and fall of Internet Explorer (and possible redemption) and the World Wide Web is once again a chaotic and exciting area of uncertainty and innovation.

So, with that back story, I am now announcing that this epic tale, is taking a new, if small, unexpected twist. Qui-Gon Jim has asked this former Jedi Knight to return to the Rebel Alliance, where we both hope we can defeat Darth Page and Darth Brin of the Google Empire. For the past few years, I've been peacefully living on Tatooine, but Qui-Gon Jim's call to battle was too compelling to resist.

With a lot of hard work, and a little luck, perhaps I shall become a Jedi Master and re-join the Jedi Council. If nothing else, perhaps I'll merely play Han Solo for a few months and pay off Jabba the Hutt.

One thing is for certain, the light saber fights with the Sith are going to be fun to watch and I'm looking forward to seeing something other than IE 6 bugs for next several months. Wish me luck in my old / new job on Microsoft's Outlook Web Access team!

Best ASP.net Interview Question Ever (Part 2)

Sat, 12 Jan 2008 17:59:39 GMT

Last time, I whined about ASP.net byte bloat. As long as I'm bitching about Microsoft's internet platform, I might as well hold nothing back.

Microsoft doesn't care enough about Internet Explorer. It is the red headed step child of Microsoft's internet platform. MS seriously lost a lot of client side credibility and goodwill by disbanding the Windows IE team for 3+ years after Windows XP / IE 6 shipped and letting the Mozilla / Firefox team catch up and surpass it.

I'm sure killing Mac IE & killing Unix IE didn't help matters either (not that anybody ever used them). Shipping a mediocre IE 7 along with a disappointing Vista last year, has further hindered Microsoft's ability to convince people that it does have a great server side web platform and annoyed its supporters. I'm also annoyed that after IE 7 shipped, the IE blog has been less informative during the IE 8 dev cycle than it was during IE 7's. I'm optimistic that after the recent IE 8 Acid Test post, the group is just being quiet instead of dead.

However, barring a Seahawk like comeback by the IE 8 team, my money is on Firefox 3 being the champ in the 2008 browser bowl. Ever since Coach Dave Massy left the IE team, I think they've taken a step backwards. Maybe they need to give IE to Coach Scott Guthrie (GM for all things IIS, ASP.net, Silverlight, and all other MS web technologies that don't suck) or perhaps the GM Windows Live team (Did you know Firefox development is almost completely funded by Google ad revenue?) All I know is that IE is too important to be left in the Windows group. Microsoft needs to show more forward progress and give the season ticket holders reason to be hopeful. Otherwise, IE will be like Shaun Alexander, a browser/back that has a great history and a disappointing present.

OK, I got the big 2 gripes off my chest. Here are some minor ones.

Why does ASP.net AJAX download so many Javascript files? I think there's a new ScriptManager on CodePlex that combines several embedded scripts on a single download. Still, it would've been nice if it was this way by default.

Why is HTTP compression the best kept secret of IIS? Seriously, it seems the vast majority ASP.net programmers don't know about HTTP compression on IIS. Maybe all of my friends read Dilbert instead of Jeff Atwood during their lunch break? OK, it is a pain to configure and providing some UI, like what Port 80 Software's ZipEnable does, would be welcome. People get nervous when I say edit the IIS metabase around them.

Why did I have to wait so long for a real FTP server? Oh well, at least things are better in IIS 7.

As I said, in my first post, on the whole, I'm pretty happy with Microsoft's internet platform. The ASP.net team is adding cool features at a good clip, Silverlight seems like a promising addition to the web developer's tool chest, and IIS 6 has been simple to use & rock solid in deployment. It seems like half of the ASP.net engineering team blogs, so getting that level of transparency is awesome. Visual Studio 2008 & SQL Server 2008 both seem like worthwhile upgrades.

And yet, despite all this coolness, I still have to code work-a-rounds for IE 6 bugs in my day to day life! To be fair to Microsoft, IE 6 was a great browser in 2001. Unfortunately, it's 2008 now and Microsoft fumbled away the web browsing technology dominance it once had. We're all stuck writing apps for a 7 year old web browser, that doesn't compare well to today's best players. Oh well, here's hoping that both IE & 37 will return to All-Pro form next season.

Best ASP.net Interview Question Ever (Part 1)

Sat, 12 Jan 2008 07:56:42 GMT

I recently I had a job interview w/ Costco Wholesale in the e-Commerce group. I thought the most interesting question they asked was "If you could change one thing about ASP.net, what would it be". It was a hard question, because on the whole, I'm pretty happy with it. Furthermore, on the whole, I'm pretty happy with the direction that Microsoft is going. However, it got me thinking about what I don't like about Microsoft's internet platform and I figured it would make a great blog post (or two), so here I go.

Viewstate + ClientID = HTML Bloat + Slow. I don't think the ASP.net forms model is bad; it just makes it much more difficult than necessary to produce small HTML markup in the typical case. For example, let's say I have ASP.net code something like this

<form runat="server">
<asp:Repeater ID="rptCards" runat="Server">
<ItemTemplate>
<asp:Image ID="CardFace" runat="server" /><br />
<asp:Label ID="CardName" runat="server" /><br />
</ItemTemplate>
</asp:Repeater>
</form>

And then I data bind a playing card to my repeater in the code behind file, which ASP.net proceeds to render it as this…

<form name="ctl00" method="post" action="form.aspx" id="ctl00">
 <div>
 <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 					
 value="/wEPDwULLTEyODIyNzUwMDAPZBYCAgEPZBYCAgEPFgIeC18hSXRlbUNvdW50AgEWAmYPZBYEAgEPDxY
 CHghJbWFnZVVybAUTL2NhcmRzLmFzcHg/Y2FyZD00NmRkAgMPDxYCHgRUZXh0BQ9RdWVlbiBvZiBIZWFydHNkZ
 GQAQrEoOi46tPS8NZ9nekUDim2+Mg=="/> 
 </div>
 <img id="rptCards_ctl00_CardFace" src="/cards.aspx?card=46" style="border-width:0px;" /><br />
 <span id="rptCards_ctl00_CardName">Queen of Hearts</span><br />
</form>

What's with the <div> surrounding the __VIEWSTATE control? Where did that style="border-width:0px;" come from? Why is there so much damn view state? Why do my Image and Label controls render IDs on the client? And why is it named rptCards_ctl00_CardFace instead of something shorter, such as rptCards_0_CardFace?

Sometimes I have nested repeaters, sometimes I don't. Sometimes I use HTML controls instead of Web Controls, but the issue is the same. The elements in question aren't getting changed on the client and only get changed on the server during the initial HTTP GET during data binding. Normally, the __VIEWSTATE just grows & grows as I add more stuff to the page. OK, you can avoid this by a few well placed EnableViewState="false" or disabling it altogether in web.config. Unfortunately, I don't always know when you really need it, so often times I end up disabling it on a control by control basis in a trial and error fashion, until my app works and my markup is small. Unless you truly understand viewstate, you could end up meeting a fatal end with ViewState-ious of Borg. Fortunately, I understand that problem.

What bothers me more is ID bloat, especially when you nest Repeaters, so an innocent looking <asp:Hyperlink> control ends up with an ID like...

rptMerchants_ctl01_rptShippingMethods_ctl00_rptLineItems_ctl00_ProductName,

That's ugly, so I end up using shorter IDs for Repeaters. Unfortunately, that's not good enough at times, so I usually end up replacing many of my server controls with <asp:Literal> controls and controlling my markup directly. Unfortunately, doing that stops you from using the server control you really wanted to use, and makes complex page development a huge pain.

Ideally, what I'd like is a RenderClientIDs="false" attribute for all ASP.net server controls. After all, the ID isn't sent to the server on the postback (just name / value pairs from form controls). You really only need it on the client if you are doing client side DOM/DHTML manipulation. I know you need a Control ID as a parameter to __doPostBack, but I usually don't need it on the client side HTML markup. It also seems odd that ASP.net is missing a RenderClientIDs attribute since they did have the foresight to create an EnableViewState attribute on server controls.

Most of the time, a Hyperlink control is just an <a> HTML tag, a Label control is just a <span> HTML tag, and an Image control is just an <img> HTML tag, so the ID attribute is just byte bloat running up my bandwidth bill. Why is it so hard to just get this instead?

<img src="/cards.aspx?card=46"/><br />
<span>Queen of Hearts</span><br />

Is there a diet control library I don't know about or some magic web.config setting to stop unneeded ClientIDs from rendering? How does one fight ClientID bloat? Should I just wait for an MVC version of ASP.net? I'm kind of lukewarm on the whole MVC thing because of ignorance and the lingering bad taste of classic ASP. I don't mind paying the ASP.net tax, when it adds more value than byte bloat. It just annoys me, that I have resort to <asp:Literal> controls to avoid paying the ASP.net tax in some cases.

So what are the downsides of MVC ASP.net vs Classic ASP.net? Will my favorite 3rd party ASP.net web control product work on it? Do I just need to read Phil Haack's blog and Scott Hanselman's blog more often? Any idea when an MSDN event will cover MVC ASP.net? Oh well, it beats tracking down memory or COM interface leaks in an ISAPI application for a living.