September 2008 Entries
Reading Phil and ScottHa's 'Five things you didn't know about me' posts and started one of my own...but I only got to number two before I realized that the rest are either very illegal / potentially career ending so I stopped. Anyway I haven't posted here for a while and I wanted to give my reader an update on what's happenin' wit me...
Features...the name MS gives to 'stuff that's in the product', working away on some WebForms stuff. Some stuff has already made it to the world. I've worked on the ability to specify your own Ids for controls (client side) and currently looking at some Routing stuff, improving how our controls render their content as well as a hodge-podge of other stuff for ASP.NET 4.0. In general I 'own' WebForms so all of my work revolves around improving the experience using this stuff.
Releases...if there's one thing the ASP.NET team does really well it's generate 'stuff', one of my responsibilities is how / where / when we release this 'stuff'; as an example we just released work from the ASP.NET QA team as well as 'Dynamic Language Support' updates. Doing this takes a lot of work for everyone involved, from the teams actually doing the work to my little part at the end where I make sure we're good to release stuff (legal, honest, useful) / do the physical release.
Process...probably my least favorite bit of my job, but a necessary one. All sorts of not very interesting stuff around navigating the bullshit that comes with working in a big company right through to dealing with incoming bugs / making sure dev's fixing them, PMs are making judgement calls and QA is testing the fixes. No-one likes doing it but my job's to buffer the team from all of the crap which inevitably goes along with what we do.
Community...one of my favorite bits of my job, working with groups like the ASP Insiders, events and generally looking after how the product team interacts with this stuff (and making sure we don't forget it!). Sounds easy but my (*heavily filtered) inbox gets >300 mails a day, about 10% of which are bang (!) mails...one of the hardest skills as a PM in MS is just managing your mail / keeping up with all the threads going on at any particular moment.
Personal life...pretty much dead. I made the decision after breaking up with my last girlfriend in March to take a year off and get things straight...5 years of continuous dating with a mean relationship length of ~2 months wasn't healthy.
So that's me...I'm a bit 'behind the scenes' on the team at the moment (well, compared to superstars like Haacked) but hey, I'm happy getting things done. I'll start speaking at conferences in the next few months...especially as my features will start getting more attention.
I was trawling through new posts on the ASP.NET blog site and came across this one from Tess (who is someone I should probably know but don’t…). What I found interesting (as well as the post which is excellent) was the first comment:
“When will MS simply drop the Viewstate completely? This is a good example of a solution to a problem that shouldn't be a problem to begin with. “
This got me to thinking, ViewState has gotten a really bad rap over the years (with notable exceptions). Let’s look at what ViewState actually is and why it might not be the villan it’s often painted out to be…
What is ViewState…at it’s simplest it’s a hidden field which contains data about the controls currently on the page. Really, that’s it…now it does this pretty cleverly, serializing a whole bunch of stuff into a Base64 encoded string (which can also be encrypted, validated etc…).
For those of us who wrote web apps back in the dark ages i.e., before ASP.NET, we remember the days where we had a bunch of hidden fields used to track changes in a page, and it was frankly a pain in the ass…it was far more transparent but a lot of grunt work just to track if a field’s value had changed / store some additional data in the page for use in postback. ViewState solves that problem pretty nicely actually.
So, what’s the problem people have? Two things:
1. people misuse it; it’s partly our fault and partly theirs.
From ‘Truly Understanding Viewstate’:
CASES OF MISUSE
a. Forcing a Default
b. Persisting static data
c. Persisting cheap data
d. Initializing child controls programmatically
e. Initializing dynamically created controls programmatically
Now, as I said it’s not entirely their fault…ViewState is enabled by default…if you bind a bunch of data to a DataBound Control then you’ll get a huge amount of ViewState serialized to and from the browser each time, it’s not that easy to figure out what having no ViewState will break / just enable it for certain controls and not others (which is what ControlState lets you do…just not for existing controls).
At it’s core the problem ViewState really has is that it’s a Leaky Abstraction; it’s ALMOST there but doesn’t quite hit the sweet spot nowadays…
So, how do you use ViewState correctly…what can you do to avoid the pitfalls?
Stay tuned!
Kind of a ‘tools’ list but a great post on what John uses on his machine…a few new ones I hadn’t seen which is always nice!