Sunday, April 12, 2009

Constructor injection FTW

I prefer using constructor injection with DI for a few simple reasons.
  1. It's self-documenting code. It's explicitly telling clients or maintainers of the component how it's put together.
  2. It keeps my components honest. In most cases, excessive constructor arguments is a code smell.
I also don't like setter injection for a few simple reasons.
  1. It adds noise to component's API. I wouldn't want to see public properties hanging off a component that serves's me no use as a client.
  2. It feels like it breaks encapsulation. How the component does its work internally shouldn't be part of its public API.
  3. It obfuscates how the component is put together.

Thursday, April 9, 2009

Finally; ubuntu problems!

This has been a WIP since years and years now. I install the latest version of Ubuntu two or three times a year mostly because I'm curious and partially because I'm a masochist. I generally want to get into using an open source OS and just be aware of how things work on the other side of the fence (being a Windows user and .NET developer). That's also why I chose Ubuntu; it's the entry-level linux distro.

Things usually work out this way; I install Ubuntu and there are issues. Wireless has never worked out-of-the-box. The graphics are 50-50. Sometimes they work and other times they don't. I've done the whole ndiswrapper thing and iwconfig and messed around on the command line more than any Windows user should ever have to feel comfortable with. Things never end up pretty and are generally unstable.

For instance, my last installation was Ubuntu 8.04. Wireless didn't work. Graphics were fine. I sacrificed the customary chicken and goat and eventually got the wireless to work. But then after I did a restart it stopped working again. Then it intermittently worked until finally it stopped working altogether. Completely random.

I tethered my laptop to the wired network and decided to updgrade Ubuntu to 8.10. After I did, the bootup had the funniest behavior. It would stop booting unless I pressed keys. Nothing in particular. Just pressing keys would make it advance. Once I booted into the desktop it said there were new drivers for the nVidia graphics card. I let the update take place (the drivers were recommended by Ubuntu). When I restarted, I couldn't get to the desktop anymore. One of the startup steps would fail and it would die. I'm not a linux ninja so it was as good as dead.

I burned down the now defunct Ubuntu 8.10 install. I downloaded and installed Kubuntu 8.10 out of sheer desperation. It too demonstrated the "press some goddam keys to boot" behavior so this wasn't an isolated incidence. Once I got to the desktop it didn't recognize I had wireless card at all and the graphics chip wasn't detected either. I was worse off than when I was just in Ubuntu 8.10. Fail.

That was last night. Today, I see that there's ubuntu 9.04 experimental. I installed it, it detected my wireless and it only took a minor spiritual channeling to get the graphics to work. Needless to say, I am happy that things just worked out-of-the-box. This blog post has come from my linux desktop. Joyous day!

Monday, April 6, 2009

Hot feature storm and digging into ASP.NET MVC

Hot feature - A feature that is released as a hotfix usually due to an overly complex or bloated release process that makes normal releases a burden on the entire organization. Those wishing to circumvent the release process will hide features in hotfixes and have them pushed out without any of the normal safety nets used for an official release.

Hi and welcome to my life for the last month. Hot features suck. As a developer, I've never felt so dirty or violated. The things I do for money...

The story; we built a releasable product but never got an official release for it due to lack of QA resources and the overall brutal release process we have now (4 days for the automated QA tests to run! Bullshit!). The solution that was worked out was that I had to tear apart the product and release each feature as a hotfix (henceforth, hot feature). Decomposing a product for its features in a non-chronological order was a nightmare in and of itself given how code evolves. This was only compounded by the fact that there was perfect storm of daily issues that would block or bump these hot features. There was one day where I had to tear apart the product 3 times, each time adding or removing a feature until ultimately, we didn't release anything at all. I will never partake in such a thing ever again.

Tomorrow we push out the last of the hot features and I'll officially be switching teams. My new role is much like my existing role. I'm generally involved with modeling the solution domain and implementing the application layer. One of the first things my team lead has indicated to me is that I'll be working on some new web pages and the platform of choice is going to be ASP.NET MVC. This is thrilling news for me as I've never cut my teeth on any MVC platform. I've been reading about it, I bought a Ruby book that just arrived today so that I could try out rails and I'm hearing stuff all the time from Mr. O'Hara about his MVP framework.

As the .NET web dev world knows, ASP.NET MVC 1.0 was RTM'ed a few weeks back. I've kept it on my radar but hadn't invested any time into it. Not because I don't care but that I've been involved with a brutal release schedule at work (as outlined above) and a newborn child. This last weekend I finally had a chance to download it and take it for a spin.

I've been developing with web forms since time out of mind and I haven't really known anything else. They've never felt quite right and given my gravitation towards TDD, it's become apparent, more than ever, that it's just not the right solution for me. I can't test the way I want to and I have to struggle against web forms to create logic that fits the web forms domain, not my product's domain. I've got the page lifecycle down pat and it was a great introductory solution for me to get acquainted with web app development but it just creates tightly coupled code by default.

My first impression of MVC; I'm smitten. It just flows the way my mental model of the application layer should be behaving. As far as ASP.NET MVC I'm glad I hopped on at 1.0 since they've improved it considerably since the betas. What it allows me to do is nearly forget the fact that I'm working on the web (outside of rendering the views). Controllers create the workflow of the app and they create truly meaningful names and actions that speaks directly to what you're modeling. It's liberating from my years of web forms oppression.

I really want to articulate for all 3 readers in my audience how this has liberated me and one example ran through my mind that captured it perfectly. Let's take the example of some portion of a simple banking application where we want to save a deposit. Use your imagination as to how it should behave.

In web forms, I load an account on Page_Load and I tie into the button click event of a web control to submit a deposit from a user.
public partial class AccountPage : System.Web.UI.Page
protected void Page_Load(object sender, EventArgs e)
//Load the account

protected void btnSaveDeposit_Click(object sender, EventArgs e)
//Save the deposit

In MVC, I speak to the AccountController and I tell it to load an account or save a deposit.
public class AccountController : Controller
public ActionResult LoadAccount(int accountId)
//Load an account and show it to the user.

public ActionResult Save(Deposit deposit)
//Save the deposit

Do you see the difference in the way you think about this code? Web forms have the unintentional side effect of obfuscating the workflow of your application. It's noise that doesn't speak to anything. What the hell is Page_Load and why do I care about intercepting events to a button? Why do I need event arguments that I'm not going to use? What does this all have to do with a bank account or saving a deposit?

Absolutely nothing. You get mired in the details of the page lifecycle and all the black magic you have to employ to do what should normally be simple activities. I can never forget lessons like "Don't forget to load dynamic controls at page init or else their viewstate is lost!" or "Always load your data on prerender as events are fired after page load and you may end up displaying stale data!". I just have a hard time caring for web forms, the page request life cycle, and all the bloat that comes with their attempt at creating a stateful application on a stateless medium.

With MVC, it makes perfect sense. My workflow is clearly illustrated, my purpose is outlined with meaningfully named actions and we can get strongly typed arguments. There is no ambiguity, this is no unexpected behavior and despite it's learning curve, I can show this to anyone and they will get an idea of how the application flows.

So, this is my first impression and what I've witnessed. As a 1.0 product it's no doubt rough around the edges and it seems like there's a lot of work to be done to ease the pain of creating the views as the web controls built for web forms can't (for the most part) be dropped into an MVC view. The tutorials on the main website are also light on details. They aren't tutorials so much as they are quickstarts. I had to munge around to find out how some things worked. Other than that, it looks to be a fun platform and I'll report back when I have more dirty details about my travels in ASP.NET MVC land.