Kevin William Pang

March 23, 2012 will be my last day at MeridianLink, the company I’ve worked for since 2006. I’ve learned a lot working here and made many great friends, but it’s time for a new challenge. I’ve accepted a position at Google and on April 9, 2012, I will officially become a Noogler!

By now, everyone has heard all about Google’s amazing work environment and awesome employee benefits, so I’ll avoid droning on about them here. Suffice it to say that I’m extremely excited and eager to start. It’s a dream come true and I look forward to helping Google build a better web and change the world.

To my subscribers,

This effectively marks the end of my days as a .NET developer. From here on out, the technical posts on this blog will probably center around Java, JavaScript, C++, and Python, depending on which project I end up on. Expect some Google-related posts as well, especially in the near future as I go through Noogler orientation.

To my friends at MeridianLink,

It’s been a pleasure and I wish you all the best of luck in your future endeavors. The Google Irvine office is only a few minutes down the street. Please, don’t be strangers.

On a yet-to-be-released side project of mine, I decided to use Fluent NHibernate, StructureMap, and ASP.NET MVC. It took me awhile to get everything to play together nicely, so I documented the steps I took in case anyone out there was interested in using in a similar setup.

Step 1: Set up StructureMap

First, I created the StructureMapControllerFactory class (taken from the MvcContrib project):

I then added the following line to the Application_Start() function in Global.asax.cs so that StructureMap would inject dependencies whenever an ASP.NET MVC controller was instantiated:

Step 2: Set up Fluent NHibernate

Next, I created a static function for creating an ISessionFactory (this code may look very different depending on your database and project setup):

Step 3: Hook up Fluent NHibernate with StructureMap

Then, I updated my Application_Start() function in Global.asax.cs so that StructureMap would be aware of how to instantiate an NHibernate ISessionFactory and ISession:

Now, whenever StructureMap needs to create an ISessionFactory, it calls the CreateSessionFactory() method defined in Step 2. Since ISessionFactory is expensive to create, I have configured StructureMap to create it as a Singleton so that it will only be created once per application.

Similarly, whenever StructureMap needs to create an ISession, it will create/retrieve an ISessionFactory instance and call its OpenSession() method. This is scoped at the HttpContext level, which means that at most, one ISession will be created by StructureMap per web request.

Step 4: Clean up

Finally, in order to ensure that we aren’t leaking ISessions on every web request, I added the following line to my Application_EndRequest function to properly dispose of the ISession StructureMap may have created during that web request:

The setup described above works on my machine with the following versions:

• ASP.NET MVC 2
• StructureMap 2.6.1
• Fluent NHibernate 1.0.0.594

The Vague Email

Feature XYZ isn’t working. Please fix.

Provides next to no information other than at some point, a feature — possibly XYZ — did not work the way a specific user expected it to. Issue could be anything ranging from a catastrophic system failure to a simple misunderstanding on the part of the user. Usually requires a series of follow-up emails, phone calls, and conferences in order to clarify the problem at hand.

The End of the World Email

URGENT!!! System is down! NONE of our users can do XYZ! Please advise!!!11!

Usually flagged as important in Outlook and CC’ed to everyone in the user’s contact list. Grossly overstates the magnitude of the problem either to guarantee an expedited fix or simply because the user would rather yell at someone rather than bother checking. Rarely turns out to be as terrible as originally advertised. Unfortunately, that still won’t save you from having to put out all the fires the email started.

The Red Herring Email

Can you check if XYZ is working?

Actual problem winds up being completely unrelated to XYZ. Unfortunately, you won’t find that out until after you’ve spent several hours poring over code trying to envision the perfect storm of events that would have triggered a failure in XYZ.

The Ideal Email

When I do XYZ, ABC happens. I expected DEF to happen instead. Here are some screenshots showing what happened.

Clear, concise, and doesn’t make any assumptions about the issue at hand. Gives enough information for a programmer to at least approach the problem and is oftentimes sufficient without any additional follow-up. These are rare and far between, yet the amount of effort to type them up isn’t much more than any of the three other types of emails. Wouldn’t life be a lot simpler if all emails came in this format?

Just a play off of the recent “How Fanboys See Operating Systems” post that’s been circulating the web.

Entity Framework	NHibernate	Subsonic	ADO.NET Datasets	as seen by…
				Entity Framework
				NHibernate
				Subsonic
				ADO.NET Datasets

What is dependency injection?

In a nutshell, dependency injection is a design pattern where external dependencies are “injected” into components rather than baked in.

If that made your eyes glaze over, think about it like this: imagine your friend asked you to drive him to the supermarket:

You would probably just hop in your car and take him:

But what if your friend asked you to drive him and his 5 friends to the supermarket, but your car only seats 4?

You would need a bigger car, right? Well, the good news is that since most cars implement the same interface (steering wheel, accelerator, brakes, etc.), you’re not only capable of driving your own car but many other cars as well. So if you had access to say, your mom’s minivan, you could complete the trip:

At the root of it, that’s what dependency injection is all about. Instead of you being stuck having to always use your car for your trips, you will be given the correct car to use based on the circumstances.

Bringing this back into software terminology, in the analogy above you (the driver) are a class and the car is your dependency. You depend on the car to drive your friend(s) to the supermarket. It doesn’t matter which car you use, so long as it’s familiar to you. Without dependency injection, the You class might look something like this:

Notice how you’ll always be using that particular instance of Car to complete the trip. With dependency injection however, the You class would look something like this:

Notice how now you don’t know (or care) what car you’ll be getting to complete your trip. The car is given to you by an outside entity via the constructor.

Ok great, so why should I care?

One reason is the one alluded to above. Dependency injection helps you create “loosely coupled” classes. What this means is that your classes will have less knowledge about their dependencies. This is a good thing. First, because it allows you to only expose functionality in your dependencies that your classes need (e.g. you don’t care what make or model or engine the car has, only that it drives and you’re capable of driving it). Second, because it lets you quickly and easily substitute out your dependencies (e.g. replacing the car with a minivan), which makes your code more flexible and also lets you swap out implementation without having to modify or recompile your dependent class.

Another reason is for unit testing. Dependency injection allows for something called “mocking”. What this means is that in your unit tests, you don’t actually have to inject concrete dependencies. Instead, you can inject “mock objects”, which are easy to create (via mocking frameworks) and define behavior for. This lets you test the behavior of your dependent class without having to worry about whether the dependencies are working as expected (you can test the dependencies in another unit test). This means your unit tests will be more in line with what unit tests are supposed to be: tests on individual units of an application (as opposed to tests on a unit and its dependencies and its dependencies dependencies, etc.).

Where can I learn more?

There’s been a lot written about dependency injection, but I think the wiki article covers it pretty well.

Once you’ve got that down, the next thing you’ll probably be interested in is Inversion of Control Containers. These containers make dependency injection a breeze by allowing you to configure default implementations to inject into your classes. Martin Fowler’s article on dependency injection covers this well.

Note: Yes, I did draw all the pictures using Paint and a laptop trackpad. No, I do not plan on selling my artwork anytime soon.

About a month ago, Joel Spolsky had the software developer community up in arms over his article, “The Duct Tape Programmer“.  Everyone with a blog felt compelled to throw in their knee-jerk response, faithfully declaring their allegiance to either Joel and the duct tape crowd or the do-it-right crowd.  And as so frequently happens on the internet, the whole argument degenerated into an enormous straw man fight.  Duct tape programmers complained about how endlessly debating best practices and writing unit tests doesn’t get anything done, while do-it-right programmers argued that poor design leads to maintenance nightmares down the line.  Both assertions are correct of course, but they miss out on one key point: there’s no such thing as a duct tape programmer.

To expand on Joel’s analogy, you won’t find a carpenter who only uses duct tape to fix things.  Similarly, you also won’t find a carpenter who doesn’t know how to use duct tape or refuses to use it under any circumstances.  All carpenters have duct tape in their toolbox. What differentiates a good carpenter from a bad one isn’t whether they use duct tape, it’s how well they use it and when they choose to use it.

Bringing this back into software terminology, there are situations where delivering code quickly is more important than delivering it correctly.  Yes, even if it means there are bugs.  Yes, even if it means maintenance will be a nightmare.  For instance, when your team is in a race against other competitors to be the first one out the door (e.g. iPhone development, Facebook app development) or when deadlines absolutely, positively must be met (e.g. your company will be sued if it doesn’t meet some compliance issue by a certain date or you’ll lose a potential client if a certain feature isn’t implemented by their go-live date).  In situations like these, getting things done trumps anything else and if it has to come at the cost of good coding practices, then so be it.

But — and this is a big but — , these situations are the exception, not the rule.  The difference between a good developer and a bad developer isn’t whether they use duct tape, it’s how well they can recognize whether a situation calls for it.  Bad developers use duct tape far too often, either because they’re too lazy to implement something correctly or because they simply don’t know of any other way to do it.  Good developers keep their duct tape handy for when they need it, but are usually smart enough to come up with better solutions instead.

Twitter's latest blog post titled Small Settings Update states the following:

We've updated the Notices section of Settings to better reflect how folks are using Twitter regarding replies. Based on usage patterns and feedback, we've learned most people want to see when someone they follow replies to another person they follow—it's a good way to stay in the loop. However, receiving one-sided fragments via replies sent to folks you don't follow in your timeline is undesirable. Today's update removes this undesirable and confusing option.

In other words, before this change you simply saw all tweets posted by the people you followed.  Twitter has decided that that was too complicated.  So instead, now you will only see tweets posted by people you follow if they are not replies to people you don't follow…unless the tweet doesn't begin with "@userwhoyoudontfollow", in which case you will still see the tweet since it's not really a "reply", but a "mention".  There, much better!  Thanks for clearing that up Twitter!

I honestly don't understand the motivation behind this change.  From my perspective, the less tweets I see, the less valuable Twitter is to me as a conversation and communication service.  I'm not sure what problem they were trying to address here, but judging from the initial response on Twitter there's obviously a disconnect between how Twitter thinks its users use it and how they actually use it.

Luckily there is a workaround.  

Later in the Twitter blog post, they reveal that "discovery" is still possible:

Spotting new folks in tweets is an interesting way to check out new profiles and find new people to follow. Despite this update, you'll still see mentions or references linking to people you don't follow. For example, you'll continue to see, "Ev meeting with @biz about work stuff" even if you don't follow @biz. We'll be introducing better ways to discover and follow interesting accounts as we release more features in this space.

In other words, while replies to people you don't follow are now hidden from you, tweets that only "mention" people you don't follow are still visible.

Let's say I am following user A but not user B.  Twitter's latest change makes it so that I won't see user A's tweet "@userB Let's go to the park!".  However, if user A only "mentions" user B in their tweet: "I'm going to the park with @userB", then I can still see it.   

So, if you want to make sure your replies are visible to all of your followers, just make sure your replies are actually "mentions" by prefixing them with a character. Expanding on the user A / user B example above, if user A changed their tweet to read "! @userB Let's go to the park!", I'd be able to see it again since it didn't start with "@userB".  It's a silly hack, but then again it's a silly feature too so I don't feel too bad using it.

I'm hoping that this was just a temporary brain fart on Twitter's part and that it will soon be fixed or that there is some hidden benefit to this feature that I'm missing.  What do you think about Twitter's "Small Settings Update"? 

Edit 5/13/2009:

Due to user feedback, Twitter has decided to change how replies work again.  Now, you should be able to see @user replies again, regardless of where the @user is placed…unless the reply was generated by clicking on the "reply" link, in which case it's still invisible.  It's really amazing how many different, but equally infuriating, ways Twitter can come up with to solve this problem.  They have also went against their original claim that this was changed for simplicity sake and now admit that the change was done because of architectural limitations.

There are a lot of ASP.NET web forms developers out there who admit that they simply don't "get it" when it comes to all the hubbub surrounding ASP.NET MVC.  In some ways, I can sympathize with them.  The vocal minority that raves about ASP.NET MVC gush about it with such zeal that they make it sound like you'd have to be a fool not to switch over.  In actuality, the decision isn't nearly as black and white. 

ASP.NET web forms aren't going anywhere.  As much as I love ASP.NET MVC, it is not the end-all-be-all one-size-fits-all solution to web development.  Both of these approaches have their rightful place in a web developer's toolbox and it's important to recognize their strengths and weaknesses.  In general, the ASP.NET MVC framework tends to sacrafice ease-of-use (e.g. viewstate, validation, etc.) in order give developers tighter control over the reins.  This can be a great thing, but only if you take advantage of it.  Otherwise it can just as easily be a hindrance.

With that in mind, I have developed a quick metric to determine if ASP.NET MVC is right for you.  The way I see it, there are three primary reasons a developer should choose the ASP.NET MVC framework over ASP.NET web forms.  If none of these reasons are compelling to you, then you should stick with ASP.NET web forms:

To Unit Test

This, in my opinion, is the most compelling reason to use ASP.NET MVC.  When it comes to unit testing, ASP.NET MVC simply blows ASP.NET web forms out of the water.  It's not even close.  Whereas ASP.NET web forms requires you to jump through all sorts of hoops to test around the page event lifecycle, the ASP.NET MVC framework practically begs to be tested.  There are interfaces everywhere screaming "mock me!". 

There's a reason why the biggest ASP.NET MVC supporters also tend to be TDD proponents; it's because ASP.NET MVC actually allows for TDD.  Personally, I think this is where all the zeal comes from.  Simply put: it's really, really hard to do TDD with ASP.NET web forms and really, really easy to do it in ASP.NET MVC.

To Gain Control and Extensibility

As pointed out in the comments, ASP.NET MVC gives you more control and extensibility options than ASP.NET web forms.  You get complete control over the page request lifecycle and the ability to substitute out several key pieces of the framework (e.g. view engine, routing, etc.), none of which is possible with ASP.NET web forms. 

In addition to this, you also gain full control over the rendered HTML.  In general, the rendered HTML from ASP.NET web forms applications is atrocious.  The web controls it utilizes generate garbage ids and hidden fields galore that not only hamper the performance of a site, but also make CSS styling and Javascript development a pain.  ASP.NET MVC forces you to be more in tune with your HTML.  There aren't any repeaters or datagrids that magically generate markup for you.  There aren't any hidden fields to persist state for you.  It's just you, the HTML, and a few extension methods (which you don't even have to use).

To Learn Something New

In other words, "because you feel like it".  This was actually why I started using ASP.NET MVC.  It never hurts to look at how you're approaching development from another angle. 

I should also point out that learning ASP.NET MVC is incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process.  I think a large part of the appeal of ASP.NET MVC is that the community's input is not only being taken into consideration, it is actively being sought after.  The framework has sparked so many discussions and debates over best practices that simply following along introduces you to concepts you might previously have been unaware of.  I would actually recommend learning the ASP.NET MVC framework for this reason alone.  The threads on TDD, BDD, ORM, AJAX, etc. you stumble across during the learning process are worth it.

So there you have it.  Aside from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC.  Maybe this is why the adoption rate isn't nearly as high as we think it should be.  The incentive for using the framework essentially boils down to unit testing, control/extensibility, and boredom/curiosity.  Good reasons, to be sure, but hardly game breakers for the vast majority of developers out there.

What do you think?  I'm interested in seeing if anyone can come up with another reason(s) that I may have missed here.  Why do you use ASP.NET MVC?

Edit 3/29/2009 7:23 PM:

It appears that Delimitdesign has finally caught wind of this thread and has altered their post to look less like a blatant rip off of mine.  They also modified the post date from 3/28/2009 to 5/28/2008.  Right.  Too bad Google cache clearly shows their original post in its full copy & paste glory with the actual date they had posted it on:

You can view the full screenshot here.  I took it just in case the Google cache page updated.

Original post:

I’ve grown somewhat accustomed to seeing my articles regurgitated on some random blogger’s site and passed off as their own.  Usually I just send the content-stealing jerk (CSJ for future reference) an e-mail asking that they provide some sort of link back to my original article and leave it at that.  Sometimes they comply, oftentimes they don’t.  In the end, life goes on.  After all, it’s not like I’m going to press charges over it.

It’s a problem that’s existed ever since the advent of blogging.  In general, I think bloggers have pretty much become desensitized to it.  Every few months you’ll hear someone cry foul, but that’s about all we can do.  Personally, I’m not a big fan of smear campaigns, especially since they tend to give the CSJs more traffic than they would have gotten otherwise.  However, it seems that the CSJs are finally evolving from no-name bloggers with 5 readers to large, professional-looking CMS-type deals.

Thanks to some heads-up readers e-mails today, I found out that a site called Delimitdesign was featuring an article on their home page that was copied word-for-word from my blog.

My post	Delimitdesign’s carbon copy

I promptly sent them an e-mail which thus far has gone unanswered.  I also left a couple replies to the post which were not approved (surprise, surprise).  I even @replied to them on Twitter without any luck.  What’s worse, it appears that I’m not the only one they’ve ripped off.  Out of curiosity, I took a look at another one of their articles featured on their home page:

http://delimitdesign.com/inspirational/101-ways-to-know-your-software-project-management-is-doomed/

A quick Google search revealed that it was a carbon copy of an article written by someone else:

http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

After some more digging around, it became quite clear that several of their posts were turning up a separate, but identical, blog post written by someone else.  In other words, the site appears to be digging up old, popular posts and regurgitating them as their own.

This is nothing new of course.  I think most bloggers have put up with it so long simply because thus far the CSJs have been relatively harmless.  But what do we do when the CSJs become more established?

Honestly, I’m not entirely sure how to react.  My only recourses, thus far, have been to politely ask them to stop and to notify the public of their behavior.

It’s not just the blogging CSJs we have to worry about either.  As Jeff Atwood noticed today, someone seems to have ripped off the entire StackOverflow site:

StackOverflow	CNProg’s carbon copy

What do we do in this case?  It’s not like Jeff has a copyright on his CSS, javascript, or design (edit: as pointed out by several commenters both here and on Reddit, he very well may, but whether or not he can enforce it is still questionable and dependent on where the infringers live and possibly how much is copied).  It seems his only retort — as well as mine — is to cry foul and throw a little mud (exactly what I’m doing here).  I think Jeff, and anyone else who has had their content ripped off, would agree that mud slinging isn’t all that satisfying.

The only solution that I have devised to curtail this is to take away the CSJs incentive for ripping off other people’s content (e.g. their visitors and thus, their advertising revenue).  I propose a new site: ContentStealingJerks.com, which would let people flag articles they recognize as blatant ripoffs of someone else’s original content.  It could come with a firefox plugin that would redirect users to the original article when they visit a flagged page.  What do you think?  Good idea?  Bad idea?  Or already implemented and I just haven’t realized it?

Edit 3/29/2009 3:58 AM:

Thanks to the comments readers have left here and on Reddit and Hacker News, I’ve learned that there are indeed things I can do.  I have now reported Delimitdesign through Google Adsense’s complaint feature (which should eliminate any monetary gains they’ve gained from their content ripping) as well as through Google Webmaster Tools (which should remove them from Google’s search index).  Tomorrow, I plan on filing a DMCA complaint as well.

I also discovered that Delimitdesign didn’t bother to swap out the images when they copy/pasted my article, meaning their article is using images hosted on my server.  So I took the liberty of swapping them out.  Here’s the final result:

Yes, I know.  I missed a golden opportunity to use goatse or tubgirl or something along those lines.  Don’t think I wasn’t tempted.  In the end though, I’d rather just get the message out rather than gross out their (presumably) innocent visitors.

Simon Torkumine, a Ruby on Rails developer, recently blogged about how the ASP.NET MVC framework compares to Ruby on Rails. While there are some parts of his post that I don't necessarily agree with (e.g. the anemic community, C# being too verbose), one point he brought up rang true to me:

.NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling. As others have mentioned, there are other ORM tools out there, but bear in mind these are targeted at traditional ASP.NET development and are not integrated into the framework as in other MVC’s. This means that you’ll be writing your own validation and form handling code for starters.

I couldn't agree more. The biggest pain point in my development experience with the ASP.NET MVC framework has been its incredibly lax approach to the "M" in "MVC". Whereas the views and controllers are pretty much hashed out, developers are essentially thrown into the deep end when it comes to the model. That means that persistence and validation is completely up to us, which is great for experienced developers who have very opinionated views on what best to insert here but extremely terrifying when for developers approaching the framework for the very first time.

This may be a matter of opinion here, but for me web application frameworks are expected to come with all the necessities to get a basic site up and running. This is not so when it comes to the ASP.NET MVC framework. At first it appeared that Linq 2 Sql would be the clear-cut answer to the persistence question. After all, Linq 2 Sql was developed by Microsoft and was used in almost every single Microsoft blogger's posts on ASP.NET MVC. But then something happened. Microsoft announced that it would no longer be supporting Linq 2 Sql and ever since then the community has been a flock without a sheppard.

Microsoft's suggested replacement, the Entity Framework, is so actively despised by the community that there was a petition against it. To date, I have yet to see a single example of integrating the Entity Framework into an ASP.NET MVC application. NHibernate has a decent following, but it's not exactly user friendly or easy to set up. Subsonic, the obvious alternative to Linq 2 Sql doesn't appear to have garnered too much support.

Validation has also gone by the wayside because of this as it is tends to be tied in with the persistence layer. Scott Guthrie's initial post on validation in the ASP.NET MVC framework revolved around handling Linq 2 Sql's "OnValidate" event when saving off entities to the database. Now that Linq 2 Sql is essentially out of the picture, we're left with either writing our own or going with one of the many newly created OSS solutions like xVal.

There is a significant difference between being allowed to go outside the box and being forced to. The "rails way or the highway" approach that Ruby on Rails takes is great for beginners, but not so great when you want to go outside of the box. ASP.NET MVC's complete lack of guidance when it comes to models has the opposite problem in that beginners don't know what to do, but are free to explore whatever options they want. This may prove to be a big problem for the adoption rate of ASP.NET MVC now that it's advancing past the point of early adopters who are willing to put up with the growing pains.

To be clear here: I know that there are several valid solutions for how to handle validation and persistence in ASP.NET MVC, and it's great that each of them is available to us. The problem is that you have to actively hunt these solutions down instead of having one of them baked into the framework. It's great that ASP.NET MVC is so extensible that you can essentially plug in whatever you want, but at some point some basic guidance is called for. A blank slate is intimidating and not very user friendly. 

In the end, it seems like there should be a middle ground between the Ruby on Rails approach and the ASP.NET MVC approach. Perhaps the project template could ask the user if they wanted to link this application up to an existing database or create a new one?  If they did, it could generate the model (even if it were empty) using Linq 2 Sql and throw in Scott Guthrie's validation code in there as well?  That would provide users with a starting point at least that could be easily ignored or stripped out if so desired.

What are your thoughts? I want as much as anyone else to see ASP.NET MVC become successful — and in my opinion it could be — and it would be a shame to see if struggle in the wild because it didn't take a few extra steps to cater to the beginner audience.