My favorite dependency injector, Ninject, has ascended to v2! I like this framework because it's small and doesn't have a bunch of external dependencies. It does take a little extra work to get it rolling with ASP.NET MVC 2, however.

There is an extension project for MVC, and you can get that here. The core of this project, which is only a few classes, is a derivative of HttpApplication and the DefaultControllerFactory. The rub here is that the latter has a breaking change from the first version of MVC. You'll have to modify the GetControllerInstance() method of NinjectControllerFactory, because the base class from the framework now requires a RequestContext object in that method (I'm pretty sure that's to facilitate areas). The new method looks like this:

protected override IController GetControllerInstance(RequestContext requestContext, 
    Type controllerType)
{
    var controller = Kernel.TryGet(controllerType) as IController;

    if (controller == null)
        return base.GetControllerInstance(requestContext, controllerType);

    var standardController = controller as Controller;

    if (standardController != null)
        standardController.ActionInvoker = CreateActionInvoker();

    return controller;
}

Rebuild the project, you're ready to rock!

EDIT (3/2/10): Nate forked the code a bit, so the project now has an MVC2 version: http://github.com/enkari/ninject.web.mvc

If you're like me and you were trying to update your ASP.NET MVC 2 RC2 project with the latest and greatest, and couldn't figure out where the new scripts are, they're here:

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\CSharp\Web\1033\EmptyMvcWebApplicationProjectTemplatev2.0.cs.zip\Scripts

That's where you'll find the jquery-1.4.1.min-vsdoc.js file (among others). I'm sure I wasn't the only one scratching my head.

There are times where I've decided that I didn't want to get too deep into a mess of markup in my views, which drives me to writing a simple HtmlHelper extension method. It's a convenient and quick way to introduce slightly more robust display logic into the view.

But first off, if I may get up on my soapbox, I'd like to address the criticism around MVC views in general. I keep reading over and over again how some feel this is a step backward. That's nonsense. What we're doing in a view is not spaghetti code. We're not jumping around from place to place with data access and business rules mixed into the mess, like ASP.old. It just ain't the same thing. It's also not any worse/messy than using WebForms controls. Those are full of templates a bazillion properties to set, and you might still not get the HTML rendered that you'd really like.

In any case, let's say that I'm building a table of images. I can't just do a simple foreach loop because there are new rows to start. I could work in similar logic to what I'm about to show you in the view itself, but it won't be reusable, and will look a little messy (though really not that bad). The logic, then, is that we want to build a table, and split the series every so often to start a new row. Ignoring for a moment the markup components of a table and its rows and cells, we fundamentally only need to repeat the individual cells and end/start rows. This is my first stab at just such a helper:

public static void SeriesSplitter<T>(this System.Web.Mvc.HtmlHelper htmlHelper, IEnumerable<T> 
   items, int itemsBeforeSplit, Action<T> template, Action seriesSplitter)
{
    if (items == null)
        return;
    var i = 0;
    foreach (var item in items)
    {
        if (i != 0 && i % itemsBeforeSplit == 0)
            seriesSplitter();
        template(item);
        i++;
    }
}

As you can see, there isn't much to it. The first parameter extends the HtmlHelper class (the Html property of a ViewPage), the second takes the enumerable series you want to split up, the third says how many items to display before doing the split, and finally we take some Action objects to render. We're still doing a foreach, but if we get to a number of items that's divisible by the parameter you supplied, we pop in the splitter markup as well. In the view, your markup ends up looking something like this:

<table>
    <tr>
    <% Html.SeriesSplitter(Model.Photos, 4, photo => { %>
         <td><img src="<%=ResolveUrl("~/Thumbnail.ashx?id=" + photo.ID)%>" 
                     alt="<%=Html.Encode(photo.Title)%>" /></td>
    <%}, () => { %></tr><tr><% }); %>
    </tr>
</table> 

What's particularly fun is that even the HTML validates right in Visual Studio (I take the small wins. :)). Here you can see we're making a table that does four cells at a time, and if it has to start a new row, it drops in those tr elements. Piece of cake, and still pretty clear to read.

Every once in awhile, I feel like I've changed enough stuff around the technology that I'm using to take a sort of inventory. Mostly I just want to be able to refer back to it the next time I feel compelled to do so.

In terms of hardware, the last year or so has been full of upgrades. Last March I replaced my laptop with a 17" MacBook Pro, because I desperately wanted more screen resolution. It's not the size that's special, it's the resolution. The 15" model I had for three years at that point was also restricted to 2 gigs of RAM, which was less than ideal.

On the desktop, I just replaced my three-year-old Mac Pro after three years. It's not that it was inadequate in any way at all. In fact, it was still pretty ridiculous in terms of its computing power. I replaced it because I wanted a bigger screen at a higher resolution (see the pattern forming here?), and the new 27" iMacs were the ticket. I was able to sell the old computer and buy the new one for about $400 difference. So for that amount, I gained a giant and bright, high resolution LED-lit screen, a computer newer by three years and only "lost" two CPU cores. On top of that, I still have the old 20" Dell monitor, and it sites next to it. I've got nearly 6 million pixels to spread out multiple instance of Visual Studio, Photoshop, browsers, chat, etc. It's also the best video editing setup I've ever had.

In other more peripheral categories, I have an Iomega 1.5 TB USB drive where I'm storing video, the Time Machine drive on the router is still the 1 TB no-name I got from NewEgg, I still use the gross (thank God it's black) Microsoft ergonomic keyboard that has been out for years (same one at work, used by nearly everyone). Since I couldn't wait to spend money in the company store, I also scored an Explorer Mouse to replace the even more disgusting one I had for five years. It glows blue when you wake it up. :)

The Web server at The Planet, tucked away somewhere in Dallas, is the same one I've had now for over six years. It's a P4 2.4 GHz with a pair of 40 gig hard drives and a gig of RAM. I can't believe it's still running. As traffic has picked up, it has shown some cracks here and there, in part because of my own poor coding, and partly because it's just so ancient. I would like to replace it, but I'm waiting for CoasterDynamix to pick up and move to their new site. I've been toying with the idea of going to SoftLayer, but haven't researched them thoroughly. I haven't had any real issues with The Planet, except for one recently, but I guess I just feel like a change.

Software has changed dramatically over the years. Chief among those changes is that I don't use a physical PC at home. I'm using Parallels 5 to host instances of Windows 7. Dedicating 4 gigs of memory to it has been awesome, and Parallels has gotten to the point where it even supports all of the eye candy and what not within Windows. As much as I hated Vista, 7 is such an enormous improvement. They really spent time thinking about little usability things, like snapping windows to the side to do split screens, for example. I started to toy with it going back as far as to before my interview, but once it came installed on the new box at work, I became a fan.

I'm still using Visual Studio 2008 at this point, not 2010. Even though I could get super new builds, I'm not sure I'd want to commit until ReSharper is updated to support it. I'm just too reliant on ReSharper now to go without.

For Web development, I'm mostly building on top of ASP.NET MVC, and will probably upgrade to the new version once it's released. MouseZoom will be MVC, except of course the forum since I'm certainly not going to rewrite that. I use NUnit for unit testing and Moq for mocking (neither of which I'm doing much of on MouseZoom since it's almost entirely composed of existing components). At work we use xUnit and Moq. For data, we've been experimenting with NHibernate, but for my home projects I've been sticking to LINQ to SQL. On the client side, the big story is still jQuery and its various plug-ins.

For Web browsers, I'm pretty sold on Google Chrome now. After using Firefox for years, it just seems to have become a dog, and I'm not sure why. Maybe it's the history that needs to be cleared out? I dunno, since Chrome is hooked right into Google search, I love that I can start typing something and pretty much get to where I want to go. I still use Firefox for Firebug though, as Google's tool isn't quite as slick. The Mac version still has some quirks (like a bookmark manager that only half-works), but it'll get there.

Adium is my chat client at home. It just works and is updated frequently. At work, when I use something at all, I use the Gmail chat with AIM enabled. Other than checking in with Diana, I don't interact that often with people while at work.

On the video front, I upgraded to the latest version of Final Cut Studio last fall, and I dig it. The latest version of Compressor in particular is impressive, and still super fast even with the dual-core CPU. The ProRes codec is what I've been using to edit with, transcoding the H.264 stuff recorded by my camera. Works exceptionally well in terms of performance and holding on to as many bits as possible.

I've talked plenty about the cameras, so I'll skip that, except to say that I may endeavor to buy a shoulder rig so I can properly shoot video before the baby is born.

When I stop and look at what we have available today, I'm really astounded at how far things have come these days. Cultural implications aside (i.e., real life social behavior), I'm amazed at what an iPhone can do. It's a computer, plain and simple, that can do far more than even a top of the line PC from ten years ago. That's crazy.

Wow, so I keep talking about how I want to write more, particularly now that I'm an "insider" working in Redmond, and yet it has been a month since my last post. But hey, I've been here two months and I just finally spent some time in downtown Seattle for the first time last weekend, so get off my case. :)

Anyway, as is typical in the professional world of software development, I've seen a great deal of debate about whether or not ASP.NET MVC is the second coming or a step backward. There are also peripheral discussions about what Microsoft sees as the future, but given the outright declaration of that guy with the red shirt and the fact that we've got new versions of Webforms and MVC on the way this year, I think it's pretty clear that you use whatever the best tool for the job is. Isn't it funny how that comes up with every religious debate about development tools?

In any case, there are a few themes to the online chatter around MVC that don't give it proper credit. I'm not suggesting that these are stupid people, but rather people who don't have the whole picture for one reason or another. This isn't an exhaustive list I'm sure, but it is noise that may prevent you from investigating the framework further, or inspire you to spread misinformation. There's a positive theme that builds up here, as you'll see.

ASP.NET MVC is too primitive.

Generally I think this statement is made in the context of MVC's lack of server controls. Some people don't like generating markup, particularly those who've enjoyed the drag-and-drop RAD nature of ASP.NET. Let's face it, when we first saw demos of ASP.NET v1 prior to its release, it looked a lot like VB6, solving problems around the stateless nature of HTTP and letting us build stuff quickly. Behold the editable DataGrid, right?

The thing is, I would observe that as time went on, people weren't using these features out in the wild, particularly with big, sprawling, public facing apps. (I'd like to see the DataTable class stricken from the .NET Framework.) Personally, I almost always used Repeater controls, or variations on them I wrote myself, so I'd have more control over how the markup was rendered. And I almost never used in-place editing either, partly because I wasn't building Excel on the Web, and partly because getting your head around the event model was sometimes a pain.

So MVC goes minimal on the UI end of things by rendering simple HTML via the HtmlHelpers, and there's a remarkably simple state bag to hold on to your goodies when your server side validation says something isn't right. That you can simply wire up objects to those helpers without all of the "MyTextBox.Text = myObject.Foo" and the reverse nonsense in event handlers is a huge time saver. Give it a try!

MVC is a step backward to ASP.OLD and spaghetti code.

This is a pretty huge perception problem. I have to admit though, the first time I saw it demo'd, I thought the same thing. I remember the horror of ASP and trying to debug it, and this looked the same. That was because I didn't truly appreciate what Model-View-Controller really meant. After reading through a Ruby On Rails tutorial and reading various articles about the MVC pattern, something clicked in my head and I investigated further. Then I drank the Kool-Aid® at various Mix conferences and I was hooked.

But back to the Italian food, the biggest thing that colors your perception is that there are a lot of really bad examples of what a view should look like. That doesn't mean that it's conceptually broken. Remember that the MVC pattern facilitates the famous separation of concerns, meaning a view should not participate in any logic except perhaps some very basic display logic (most often, looping through some enumerable set of data). If you see some example on the Internets of a view that is calculating salaries, or worse, hitting a database, politely post on that site: "MVC: ur doin it wroung."

It's a lot of work deciding how to split everything up.

Again, I think that's only true if you aren't doing it right. Admittedly, it takes some practice to decide where things go, but after awhile it becomes pretty obvious. If you're dealing with a view, ask yourself if it's doing anything more than displaying stuff. If you're dealing with a controller, ask yourself if it's doing anything more than coordinating what to show the user, and shuttling data between the views and the models. If you're dealing with models (which is a pretty nebulous umbrella term in a lot of texts), ask yourself if it's doing any decision making about what to display or how to display it.

Don't be intimidated over the many related subjects around this concern soup. Dependency injection isn't that hard to get down, and like anything it takes practice to fully grasp why you'd want to soak up its awesomeness (see: Loose coupling).

In fact, the "ah ha" moments really may not come until you've forced yourself to sit down and do an end-to-end science project. While I understand that test driven development is a huge leap that's hard to make, unit testing can make your life easier even if it's slightly after the fact. In order to unit test, you have to figure out how to decouple your bits. That subject is too enormous here to cover, so you'll have to take it on faith until you try it.

Ugh, but it takes so long to do everything "right."

Think about how much time you may spend debugging a code-behind or a custom server control. If we share any experience, it's probably around those hours we'll never get back. Now imagine that you have some tight model that just does what it does, probably interacting with a database (or rather an interface that in production happens to be a database). Imagine you have a controller that takes the request, feeds its data to the model, then sends the model's data to a view to be rendered. Each phase of that can be looked at in total isolation. The points of failure are much easier to narrow down. And because it can be looked at in isolation, each part can also be tested in isolation. The speed at which you can debug this arrangement is far greater than what you do in Webforms.

The bottom line is that MVC is just... different. I happen to be a strong advocate of it because it gets back to the basics of what HTTP truly is, without a huge mess of abstraction on top of it to hide the way it works. That's important these days, because we trust the browser to do more work than ever now. The framework also gets us thinking about (but doesn't force us) how to do things in a way that is testable, more maintainable, and ultimately, more simple.

If you don't think you like MVC, but haven't really looked into it, go check out the learning page on ASP.NET/mvc. Read the tutorials, view the video (that Hanselman guy is a trip).

I'm closing in on a month now at Microsoft. OK, not really, because with the holidays and a week out for a pre-hired trip, I'm obviously still in a bit of a ramp up mode. Although I checked in some code last week, which is very exciting.

In any case, I've taken my share of cheap shots about the Borg, evil empire, M$ and the other predictable nonsense. Now I just find it sad that people spend that much time and energy on hating a company. I get it, some folks think the company is evil. Whatever.

The thing that I've noticed about Microsoft, from an internal view, is that it's an enormous company. I find diversity in teams, groups, divisions, top to bottom. In orientation and training, this diversity is reinforced in every aspect, from the way people develop product to the way they interact with each other.

Externally, you may also notice diversity. There are epic success stories, like the Xbox edging out the established players or Silverlight quickly iterating and gaining market share. On the other hand, you have things like Vista (which might have been more of a critical failure than financial, in my non-expert opinion) and Windows Mobile, which fails to make any traction.

Do you see what I'm getting at? You can't make generalizations about the culture of Microsoft. When I tell friends that I work in an agile team, in a room together, delivering value regularly, don't get bogged down in e-mail or specs that people never read, they think I'm lying. Are there "old school" teams around the company? I'm sure there are. Maybe there are even business reasons for it. But to suggest that Microsoft on the whole is incapable of doing amazing things in a very forward and progressive way is to suggest that a huge company operates in exactly the same way, from end to end. That's just silly.

I might drink some of the Kool-Aid®, but I'm not naive enough to believe that Microsoft doesn't deserve much of the criticism it gets. That said, the press and the average fashion hater are not credible when they paint the company with one broad brush. You don't need to work there to see that the different parts of the company roll in different ways. There are thousands of very different, and very real, people in this organization.

Calacanis wrote a rant about Facebook that causes me to question his credibility. Seriously, is he a lucky entrepreneur or just full of it half of the time? Like many "pundits" in the tech field, he tends to jump into the fray with whatever fashionable rant is the rage. These days it appears to be Facebook, probably because it's a big target. (I work for Microsoft, and I have a growing appreciation for being a big target.)

The long in-depth "articles" written by the haters and the EFF, among others, allege some ridiculous things, and Calacanis takes it one step further by implying naughty intent. It's that last part that really annoys the piss out of me. Ad hominem anecdotes about Zuckerberg hardly prove any ill intentions.

What did Facebook really do? Most importantly, they killed networks. Because people didn't understand what they were, and wanted to belong, they joined a network and by default showed all of the nonsense they posted to everyone else in that network. That's why teachers get fired for having photos of them with drinks on a cruise ship or whatever. While that in itself is pretty ridiculous, it was probably the right thing to do, since I doubt many people use Facebook for meeting new people.

The second thing they did is change the UI around setting these permissions. When I got the prompt to set them, I didn't change anything, and since I wasn't in a network, nothing changed.

Again, what really annoys me is the suggestion that Zuckerberg and his minions sit around planning how they're going to dupe people into giving up their privacy, thinking no one would be the wiser. Come on, really? Whatever you may think about the boy CEO, he's certainly not stupid. And the predictions about Facebook's ultimate demise are pretty hilarious too, because if Calacanis et al would get out of their tech bubble just for a moment, they'd see that even my 83-year-old grandfather is on there, along with the rest of my family, because that's how we track each other.

The take away is that sometimes people in our line of work get so close to technology that we fail to see the bigger picture. Don't be a pundit zombie.

I had my first "real" day at Microsoft today (the first day is mostly an HR thing). There's still a great deal of stuff to do to really get settled, as anyone who has ever started a developer job knows, but it felt like I actually worked there today.

I'll be working on the forums team in Server & Tools Online, which owns the forums on the MSDN site, among others. Since I'm only at a point where I'm trying to find the restrooms, I'm not sure yet what kinds of things I'll be able to blog about, but given the fairly non-proprietary nature of what we do in that group, I hope to be able to blog more. Over the last few years I've not posted a lot here outside of stuff relevant to CoasterBuzz, one of my own personal sites, but the more interesting stuff that I couldn't blog about had to do with previous employers. The really off-the-wall non-technical junk (complete with the occasional naughty word) will appear on my personal blog.

A quick shout out goes to the relocation folks at Microsoft, for making the move from Cleveland (relatively) painless. In another week or so, the move should be history overall, not counting the sale of my houses back in Cleveland. I think things have gone as non-stressful as could be expected.

The last refresh of Google Maps messed up my street. I live two houses down from an intersection, where on one side the street has one name, and a different name on the other (two subdivisions started years apart). In the last refresh, they had the name from the other street extending half way down my street. I noticed a "report problem" link on the map, so I did. Here's what I got...

Hi Jeff,

Your Google Maps problem report has been reviewed, and you were right! We'll update the map within a month and email you when you can see the change.

Report history
Problem ID: A4EE-24E3-19D7-40FE

Your report: Beaumont Dr. actually extends to N. Carpenter. It's Red Clover to the east, Beaumont to the west.

Thanks for your help,
The Google Maps team

Trying to wrap your head around leaving an area you've been around for 36 years for a destination and job 2,400 miles away is one of the single most bizarre things that I've encountered in my life. The time between my arrival in Seattle to interview at Microsoft (I was in town for just 27 hours) to my start date is going to be about six and a half weeks, or a month and a half. I'm not sure if that's making good time or not, and I'd love to hear stories from other current Microfolk who have relocated. The only unknown variable left is the move scheduling.

We're downsizing a bit, because we simply can't buy a house. The housing market here around Cleveland has been a brutal disaster, and between my wife's unsold house of 18 months, which we'll take a bath on eventually, and my own which may sell quickly but erase most of the equity, this move is very much like starting over. We're not angry or bitter about it, but it isn't the most cheery subject. Lots of nice apartments and townhouses around the Seattle metro, and we look forward to waking up to much better scenery every day.

It's weird how you can end up in a particular place for much longer than you expected. A great many life changes have affected me the last five years or so, which led me to one of the big "I'm a grown up" discoveries: That I can move if I want. Between visiting my new family out in Snoqualmie and frequent trips to Orlando to support my theme park habit, I was done with Midwest winters. Then I lost my job, twice in the span of a year, and I started to realize how awful the job market here was. Duh, good time to move.

I've only had a few other "I'm a grown up" moments. The earliest one was that I could buy a season pass to Cedar Point and go as much as I wanted to. It makes me a little sad to break the streak of 11 straight seasons of passholderness. Another moment was they day I realized I could buy a house to live in. The most recent one was about two years ago, when I had a lot of bonus cash in hand and decided I could buy a completely non-essential expensive item: a hot tub.

But the moving on to a new place and new job bit is the best moment of all for me. I've been a fan (and critic) of Microsoft for a very long time. I got caught up in the excitement of product development when I was writing my book, privy to early builds and roadmaps under NDA, and wondered what it might be like on the inside. Then the Mix conferences (I've been to three of the four) gave me warm fuzzies about how the Server & Tools division as a whole was coming along. Now I get to work with smart people who are very rapidly changing the way the customers of those products are interacting with the company. Very exciting times, indeed.

I saw this post from Ken Cox about his displeasure with the preview of the new VB developer site, specifically the animated box at the bottom. You've seen these before on a million different sites, where a number of featured content items are previewed.

Putting aside for a moment that this one is particularly non-useful (no single frame hangs out long enough to read it), what do these really accomplish? We can assume that the goal is to get a number of different things in front of the viewer. News sites in particular seem to love using these. I've certainly not conducted a human factors study on the subject, but my gut feeling is that this is completely ineffective.

The first flaw is that it's easier to scan a handful of headlines that are all there. My armchair designer mind says that people are drawn to pictures and retained longer by them, but I'm sure not I buy it. ABC News used to have an annoying headline rotator, but they recently switched to something that shows the picture as well as allows for the quick scan of headlines.

ESPN went a step further, realizing that their strength is the mountains of video they have. They abandoned the rotator entirely for video right there, immediately available.

It's funny how the traditional media is doing it better, while new and trendy get it wrong. Revision3 has the classic interpretation of this, and it's a failure. First off, they're using a busy image with text over it that's hard to read. Then they have the goofy "highlighted square" navigation in the top right that you almost miss. I shouldn't even call it navigation, because it doesn't tell you anything other than the number of frames, which is nearly useless information. There's no incentive to hang out and see what's next. It also continues to animate whether you like it or not.

But in my quick survey of things, no one gets it quite as wrong as MTV. They have the good old fashioned mystery meat keyframes at right, and many of the text descriptions are too long to read before the next frame.

Ultimately, I think some of these attempts come from stakeholders who all get in a room and believe that their content is most important. That's a nightmare you'll frequently run into if you do client work in particular. Other attempts at this I think are simply imitation of a trend.

So what would I consider the critical thinking points around these things if I were in charge? In no particular order...

• Is it critical that everything sits above the fold? If not, then why are you trying to cram it all into the first 400 pixels? We live in a Google Analytics world. You can see how often people are clicking down the page.
• Is everything you want to show really that important? If it is, are you sure there aren't other means of discovery? If you're a marketing department and everyone in your company thinks their stuff is most important, rank it yourself or get someone senior to the various departments involved.
  
• What is your audience looking for? This seems like such an obvious question, and I don't think designers ask it enough. If they're looking for headlines, give them headlines. If you want to pair with images, make sure they don't come at the expense of headlines. If the reverse is true, again, keep in mind that too much compromise may not effectively give your audience what they're looking for.
• If you're convinced you have to show more than one thing in a given space, don't rely on conventions you've seen elsewhere. Mystery meat navigation sucks and it pisses off users. As it is, they're probably not going to hang out for more than a few seconds.
• Animate only if you have to. You're falling into a trap where you have to predict the future in terms of how fast your readers can read, how long the content will be as long as you're using the animation, and you're living on the assumption that the dwell time on the page is long enough to see it all. If the average user sees 1.5 of your frames, you've already failed in getting the rest of that "important" stuff in front of the user.

If you haven't seen it (or don't otherwise subscribe to his blog), do check out Hanselman's peek at the new MSDN.

My impression is that I'll be working in some subset of this new stuff when I get there next month, so I now have a vested interest. :)

As I mentioned previously, I interviewed in Redmond for a position with Microsoft in the Server & Tools Online group, specifically Community Applications & Services (Codeplex, MSDN forums and other stuff in that area). I got the word Friday that I had an offer, today I verbally accepted it, and pending a background check and move, I should be starting some time in early November! I posted a few words about the interview experience on my personal blog.

From a personal and professional standpoint, there are a million reasons why this is the right thing at the right time, and I really look forward to getting started. Those who have followed me on blogs over the years know that online communities have been a passion for me for as long as the Web has been around, and that's a perfect match to my enthusiasm for much of what Microsoft is doing. I look forward to being a part of the stuff in between the products and the people using them. Very exciting times!

In the process of networking around Microsoft, I've also talked to quite a few people there outside of the group I'll be working in, and it feels good to have a greater awareness of what's going on. By the time I left Seattle last week, I was more convinced than ever that for the most part, the Server and Tools division of Microsoft is headed in the right direction. After living in a market (Cleveland) where nothing outside of medicine is doing anything with forward motion, it's a relief to see myself as a part of something good.

So for the next few weeks, I'll be spending time selling non-essential stuff, making minor house repairs, closing out the season at Cedar Point, throwing a party to end all parties for our friends, and figure out how to get the cats to Seattle without causing them major trauma. My wife is stoked too, since her brother and his family lives out there.

What a year... marriage, honeymoon, unemployment, sell a house, move 2,400 miles, start a new job and prepare for a little bundle. Heck of a year!

I'm coming out this week to Redmond again to visit Microsoft and interview, this time for a developer gig.

That last time, I was interviewing for a PM gig that I didn't entirely understand, and the vetting process before coming out was not particularly rich. I was an awful fit for that job, I think, and in retrospect, I'm not even sure how they came across me because I had never applied for it. But it was still a good experience, because it gave me a peek into the culture that I would never have had otherwise.

When I lost my job in April, the day after my honeymoon no less, my game plan became pretty obvious after a few days. I had to broaden the search and think more nationally in terms of the kinds of places I wanted to work. I also wanted to use the time I wasn't working (which has been a lot longer than I expected) to try new things, learn new things and develop my side business (mostly CoasterBuzz) into something that could sustain me for the duration. I feel like I did most of that.

Locally, in Northeast Ohio, the work potential is the worst it has been since 2001. The smaller short-term contract stuff kept leading me to the "over-qualified" response (seriously, for three months, doesn't that make me a low-risk bargain?), and the three really solid gigs I encountered after long interview processes ended up in two "we can't spend that money right now" endings and one that went to one of my mentors from two jobs ago, who also got let go and was clearly the better candidate, by a long shot.

We're not at all tied down here in any way other than real estate (another dismal market), so I've been targeting a number of well-known companies and watching their job postings, mostly in the Pacific Northwest and Central Florida. Good choices, too, as Forbes recently named Seattle as the best place for tech jobs, and Orlando was third place. I never forgot the trip to Microsoft, and going to conferences and what not just made me want to be a part of what goes on there even more. It's a far cry from the start-ups I've been working at, but internally, there are a lot of people taking initiative to better their product areas. Who wouldn't want to be a part of that? I've been watching the boards for start-ups and small companies as well, but the number that are hiring in these regions seems to be nearly zero.

This trip feels much different already. I had two brutal phone screens that were far more intense than most face-to-face interviews. The vetting process was solid and I go in feeling like I understand the gig, they understand me and flying me out there is a good decision for everyone. I'm really psyched for the trip. Plus there are bonus points because I'll have a short window to visit family out there.

I'll share more about the process after I get back, and hopefully have good news to share as well!

I've been thinking a lot about all of the frameworks we have now to use with our, uh, frameworks. There's a framework to solve every problem. Dependency injection frameworks are of particular interest to a lot of people because they make unit testing ridiculously easy. They're also well suited to something like ASP.NET MVC, where you're trying to make as few dependencies as possible between the various concerns.

But I was chatting with someone the other day about all of the frameworks for DI, and he expressed concern that he wasn't comfortable depending on a lot of external libraries for some things. His view (pun intended) was that you start to junk up a relatively simple framework like MVC by putting all kinds of other stuff into it to support another framework, and that introduces different kinds of risks. For example...

• You're decorating everything with attributes.
• There are all kinds of configuration files or classes to do the hookup.
• You'll replace the standard controller factories, perhaps giving new devs one more thing to learn about for your project.
• Global.asax becomes even more of a dumping ground (more because of the placement of routing there plus DI framework init).
• It just feels dirty to some to be using another library you don't own.

I think these are all valid concerns, though the scope of them depends a lot on your specific scenario. The funny thing about using frameworks that are named after design patterns is that everything becomes an academic debate about where and how you do this and that. And if you're a junior developer wanting to impress your peers, or a senior developer not wanting to set a precedent for the "wrong" thing, you want to get it "right."

Many of the examples published on the Web and in books suggest simply using different constructors on MVC controllers to handle DI in a rational way that doesn't require an additional framework. That allows you to keep the default controller factory and let your unit tests instantiate them with your mock objects. I read a lengthy discussion forum thread that suggested this wasn't proper either because you aren't testing the way that the objects are created in the real production environment. I thought that was a pretty thin argument, but I do see the point.

I got to thinking about how the provider model introduced in ASP.NET 2.0 worked pretty well for a lot of things, and it was used effectively before that in wiring up swappable data access layers on various apps. Creating a lightweight container to do that wire-up would be pretty straight forward, even if it did reinvent some wheels.

I don't really have a point that I'm after here. I guess these are things I'd like to hear people talk more about. What are you doing in the real world to keep things testable and maintainable?

There was a solid post on the Mix blog about just letting go of all the stuff going on in the online social world and getting back to work. It's a subject that I've thought a great deal about lately for a lot of reasons. With a baby on the way, balancing life is important to me. I see friends who can't got five minutes without checking Twitter. Sometimes I worry about whether or not I'm learning the right things. The presence of information itself causes worry.

The thing that I keep coming back to is that there are a number of means to limit what you're exposed to, and they're not always electronic tools. Some people make it their job to find stuff and filter out the unimportant stuff (heck, I'm applying for just such a job). I find that in areas of expertise or interest, your overload is reduced when you find these human filters. The method of transmission is unimportant. I've been filtering out amusement industry news for almost ten years on CoasterBuzz, with a Web site. Remember Web sites? Pages, hypertext, pictures? It doesn't matter if it's a blog, Twitter, Facebook or a newsletter printed on dead trees. Fundamentally, there are still sources that act as information aggregators for things you care about. In the .NET world we have these folks, and they're authors, Microsofties, code project owners, etc.

The bottom line is that I don't think you need to be on 100% of the time trying to follow it all yourself. The trickle down filters work pretty well for most people.

If it's your job to have a higher awareness, then yes, engage at an appropriate level. But at the same time, make sure you're monitoring your peers, and if people report to you, listen to what they have to say. The tools and conduits are only a discovery mechanism, and most of them don't even offer a lot of depth or context. Engaging with people is still necessary.

Don't be lured into the real-time trap to the extent that you feel you have to see every last thing. If it's important, it'll keep coming up, and you'll see it tomorrow. The only exception I can think of is if you're a thought leader, but in those cases, shouldn't you be the originator of the important brain snacks in the first place?

I was one of the nerds that went to church, er, the Apple Store, yesterday to pick up Snow Leopard, the OS X update. For $29, I think it's a pretty reasonable upgrade price (are you listening, Windows 7 pricing people?), considering it's an evolutionary upgrade and not feature heavy.

The first win was getting back 10 gigs of space from my hard drive. I thought it was supposed to be only 7, but I'll take what I can get. My Mac Pro's system drive is also where I put my iTunes library, and it's getting crowded.

Booting and shut down is faster, as they said it would be. Time Machine backups are crazy fast now, where it used to be that the icon would swirl for ages without anything new to even backup. Everything in Finder seems snappier, though it's hard to quantify it. The slider in Finder windows for icon size is a welcome addition. Spotlight seems faster. Stack navigation out of the dock is far, far better now that it scrolls.

I wonder if they haven't tweaked memory management. Parallels seems to be more responsive when I've also got Photoshop and/or Aperture open. Perhaps it's the CPU core management. It's all that under the hood stuff that's hard to measure.

Lots of little tweaks that I've read about, but not encountered, are intriguing. That it can figure out what time zone I'm in and adjust the clock is really cool. Definitely a worthy and inexpensive upgrade. And did I mention there are no install keys or other such nonsense?

More than two years ago, I made a post on here about how I didn't get Twitter. It's one of the most popular posts I've ever made for some reason, which perhaps I'm not proud of. I been meaning to follow up on that for, well, at least a year, because obviously things have changed a great deal.

My view was skewed in some respects because I never looked at it much outside of the context of technology circles. In its earlier days, Twitter was dominated by attention whoring tech pundits, and that seemed boring to me. These days, it enjoys more widespread use, but there are still some critical points that measure how effective it is as a communications medium, and furthermore, it serves different people different ways.

That 80% of people never post anything and have few followers indicates to me that a lot of people are tending a flock, and that's OK. In reality, this is a lot like any other Internet media we have, whether it be blogs or Web sites as a whole. It's a minority that publishes content while the vast majority are consumers only. This has been true for a long time. In fact, the forums on my sites over the years have always been a 95% read-only affair. Many view, few post.

The development community has a much more robust two-way audience. Its effectiveness is rooted in using the right tools, like TweetDeck, to follow not individuals, but hash tags and search terms that matter to you. You get and give help pretty quickly. There's a lot of re-tweet noise, unfortunately.

The bigger story is that it has finally achieved a more critical mass, making it useful by volume. So these days, yes, I'll admit that Twitter is useful if you cast out the attention whoring. Yesterday, I got RT'd by @scottgu, and within an hour, added 15 new followers. Can't argue with that as a means to get your words out. (Wonderfalls reference!)

Coming from the Webforms world, the thing you might miss most when using ASP.NET MVC is the ability to create rich Web controls that generate all kinds of markup and do nifty things. HTML helpers do similar work, even if their plumbing is different, and because we can see the full source code of the MVC framework, we can explore their innards. Keep in mind that this isn't a straight analog, since there are no events to worry about. The helpers have one responsibility, and that's to display the right data as HTML. The truth is that you don't need to know any of this, as the existing helpers probably meet your needs 95% of the time. But in the event you want to build your own helpers for the purpose of encapsulating some kind of common, reusable markup (or keep your views cleaner), you'll benefit from understanding what goes on inside the black box.

By the way, if you've never looked, I'd strongly encourage you to download and poke around the MVC source code. I know that you're probably expecting a big mess of overly abstract pieces that you can't follow, but it's one of the cleanest and easiest to understand projects I've ever seen. They did a really great job with this, and the whole thing weighs in at only 10,000 lines of code, and 500 of that is just resource stuff.

HTML helpers generally do the dumb work of creating markup. They save you the hassle of making input tags or links or whatever. But the other thing they do, the magic, if you will, is process model state. Controller has a property called ModelState, which is an instance of the ModelStateDictionary class. This is passed along to the view in a context object. Your views inherit from ViewPage, which has an instance of HtmlHelper (the Html property). Got all that? I'm first trying to illustrate how data gets from the controller to the view, where the helpers do their thing. The controller is where you process input via model binding and validate, and this is what gets the model state involved. It's a different topic from what we're discussing here, but hopefully you've had exposure to it and understand the goodness that makes working with input and models so easy. (Read up on the tutorials on the official site, specifically the stuff about model binders and validation.)

The HtmlHelper class by itself doesn't do much to generate markup. It does have the anti-forgery token code in it, as well as some static methods to create route links (I'm not sure I understand the decision to put them there), but otherwise, the creation of markup lies in several other classes filled with extension methods to HtmlHelper, found in the System.Web.Mvc.Html namespace. They're grouped into classes for input, forms, links, selection controls, validation, etc. Since they're all extension methods, they have access to the data in the HtmlHelper instance (the Html property of the view), so that means they can work with the model state and virtually anything else available in the view. As extension methods, you can hopefully see that you can build your own to generate most any HTML you can think of.

Let's start with the simplest example: text boxes. Found in the InputExtensions class, there are several overloads:

The MVC team is obviously thinking of your well being in allowing you to provide as much, or little, as you need to make that text box. The real meat comes in the last overload, which calls another extension method in the class named InputHelper. This is where we finally start to make some HTML.

Before we get into that method, consider what the typical code looks like in your view to make a text box. It may look something like this in a strongly typed view that has a "Name" property on the Model:

This says, "Create a text box on the 'Name' property, don't give it a value, and while you're at it, add a class attribute with the value 'textField'." This corresponds to the third overload of the available extension methods. In essence, we're calling:

InputHelper(Html /* instance of HtmlHelper on the view */, InputType.Text, "Name", null, (null == null) /* useViewData */, false /* isChecked */, true /* setId */, true /* isExplicitValue */, new { @class = "textField" });

Pretty well-factored code! This works with the extension methods for check boxes, hidden fields, passwords and radio buttons. Note the fifth parameter, the Boolean useViewData parameter. What this says in English is, "If the value given is null, then use the view data."

Here's the InputHelper code, with some of the non-relevant parts taken out for the purpose of this example.

Now we can dig in. To get things started, the method creates a TagBuilder object, which is used across most (maybe all) of the helper extension methods. Check out the source if you get a chance. It encapsulates the process of creating the tag and its attributes, and does all of the boring string formatting work. It creates an ID, checks for duplicate attributes, sets the innards of a non-self-closing tag, etc. The one important thing to note is that it also concatenates CSS classes (important for the validation part, as we'll see in a minute).

The switch block trickles down to the default, where it uses the GetModelStateValue method of the HtmlHelper to see if there is a value to drop into the text box. That method returns the value from the model if it's there and matches the type String (since we're using text here), otherwise it returns null. The next line calls up the TagBuilder to add a value attribute to our tag. What it puts there depends on what's available. You may recall from the documentation or books that the first thing it tries to do is use the value stored in ViewData.ModelState, if that's available, and that's what the EvalString method of HtmlHelper does. If that's not available, it goes with the value we passed in from the markup in the view. Since we specified null, it won't show anything, even if there was no value in model state. Again, read up on how model state is used to work with validation to repopulate a view with the values entered before posting the form to the controller.

After creating an id attribute for the tag, the method finally gets to the validation piece. Recall that fields that don't validate have their helpers render the CSS class "input-validation-error" in addition to any style classes you've specified. That happens here by checking to see if there are any errors associated with the model state of this field.

Finally, the method uses TagBuilder to build out the string of HTML to drop into the view. If you look around at the other helper methods, you'll find that they all work similarly to this.

To summarize, the helpers do this work:

• Use TagBuilder to create the HTML tag
• Pass in the attributes
• Figure out what the value of the HTML control will be
• Give the tag an id
• If there are validation errors, apply the predetermined CSS class in addition to others specified
• Output the string of HTML into the view

It's no secret that I'm all about Mac hardware and living in OS X when I'm not developing .NET stuff. It's also no secret that I thought Vista was too much of a dog to use, and have been sticking to Windows XP because of that. And in all fairness, I suppose some of that bias is rooted in the fact that Vista was a nightmare on my wife's old laptop, but I did experiment a little with it in a Parallels VM, and it just felt clunky. The outright bizarre dialogs with a chapter of text for everything also threw me for a loop.

People seemed pretty enthusiastic about Windows 7 though, so I thought I'd give it a go using Parallels 4, which lists 7 support as "experimental." Well, it's a pretty solid experiment so far!

Install went perfectly, and pretty quickly, without the silly self-serving ads describing how great Windows is. Once the install was done, the first win is the boot time, which is frankly awesome. This is after installing Visual Studio, SQL and such. Visual Studio seems to start faster as well, but I'm still convinced that this is caused by some kind of "cache rot" with ReSharper, since turning it off seems to yield faster start up times.

I prefer coherence mode in Parallels, since I typically run Adium, Firefox for e-mail and CoasterBuzz Feed in the background while working. It generally seems to work pretty well, and dock icons are much nicer than they were in XP when a high-res version is available. Trying to drag a window around at high speed is still not a pretty affair, but generally I don't do that in real life anyway. Drag-and-drop between an Explorer window and the OS X desktop works fine too.

So my early impression is that at the very least, it's a substantial improvement over Vista in terms of general perceived performance. I'll have to experiment some more and see how it affects battery life, which is something largely left to the folks at Parallels, I suspect. The question becomes, "What do I get that I don't get in XP?" I'm sure that's what IT departments everywhere also ask. I don't have a good answer for that other than I want the pretty, and I want to feel like everything is a bit zippier.

Poking around control panels and properties dialogs and such, it does appear that the Windows team has made great strides in getting away from the ridiculous verbosity of Vista, thank God. Stuff feels like it was built by user interface designers and not engineers who "know" what people want. I'm really happy to see this corner turned.