Rob Conery's Blog

Be A Good Jedi Part 2: It’s Alive

Back in August I wrote a post about building your own blog as a way of sharpening your skills and it was interesting, to say the least, to read the feedback. Well I’m happy to say that what you’re reading is the result of that post. I’m off of WordPress, doing my own thang and I couldn’t be happier.

I Recorded All of It Too

Have to say this was really fun – I recorded all of the development (including screw ups and bad starts) for Tekpub. I did it in a “day in the life” style which added some interesting edit points for me (had to decide if swearing was OK).

If you’d like to watch it – you can see a preview here.

I’m Not Even Close To Being Finished

Yes, you’ve probably crashed it by now – and that’s OK. This was an “emergency push” on my part as WordPress was ramping out FastCGI for some reason. Not too sure why – but my comments were breaking and it was an overall bad experience.

Anyway – I’ll be tweaking this thing as time goes on so please – break it for me.

Pass Number 1: ActiveRecordEngine for ASP.NET

I have a SubSonic prototype that’s been sitting on my hard drive for a while – something I’ve been meaning to spruce up for a bit and release. As of right now I’m happy I didn’t – the code would be considered SubSonic’s and I’d rather it get pulled into a larger effort (wink wink, nudge nudge… bat over the head).

I massaged the interfaces I’ve been using and in this post I thought I’d lay it out for comment.

Functional Background

The idea is that you “plug in” the ActiveRecord “stuff” to your web app and use it as you see fit – with perhaps a default being offered from Phil and team (using one of the ORMs their baking up there… :):):). So imagine that, out of the box, in the Global.asax is a line like this:

Controller.SetActiveRecordEngine(new EFActiveRecordEngine());

Yes yes I know. Settle down.

First Pass

To get all of this to work properly we need to define two interfaces – one that works the database, the other that describes the object. I’ve been sort of thinking a lot about this for a long time… can you tell?

Here’s a starter interface for IActiveRecord, with the goal of keeping it lean and simple:

    public interface IActiveRecord {

        object Add();
        int Update();
        void Save();

        void Delete();
        void Destroy();

        string KeyName();
        string KeyValue();
        string DescriptorName();
        string DescriptorValue();

    }

Aside from the typical CRUD stuff, there are 4 methods that allow you to do some groovy UI work here (Key/Descriptor stuff). With these specified we can hijack the HTMLHelpers to do our bidding – things like DropDowns and simpler tables. Heck we could even do Editor<T> if we wanted.

The next part is the engine – the thing that would do the query stuff:

    public interface IActiveRecordEngine {

        T Get<T>(object key) where T : new();
        T Get<T>(Func<T, bool> expression) where T : new();


        IQueryable<T> All<T>() where T : new();

        T Add<T>(T item) where T : new();
        void AddMany<T>(IEnumerable<T> items) where T : new();

        void Update<T>(T item) where T : new();
        void UpdateMany<T>(IEnumerable<T> items) where T : new();

        int Delete<T>(Func<T, bool> expression) where T : new();
        int Destroy<T>(Func<T, bool> expression) where T : new();

    }

The power of Linq means that we don’t need to define much beyond “All()” – aside from the CRUD stuff. This is our answer to “method missing” with Rails’ ActiveRecord. Well at least sort of.

Putting the Pieces Together

Under the hood the vendor who implements these interfaces would be responsible for allowing the developer to harness their particular ActiveRecordEngine to IActiveRecord – meaning that when object “Post” which implements “LinqToSqlActiveRecord” calls “Add()” then the underlying “LinqToSqlActiveRecordEngine” does the heavy lifting.

Your Thoughts Please – and Your Voice

Data access is a pain in the ass and something that we should really move beyond. If this interests you – heckle some people. Twitter it, blog it. Make yourselves heard. Phil is very much into this (it was our convo that sparked this whole thing) and let’s resolve this API so we can (if we so choose) all speak the same data access language when using ASP.NET.

Talk to me! If you want something like this – you need to speak up.

It’s Time for This: ActiveRecordEngine for ASP.NET MVC

I had dreams of this when I joined Microsoft a few years back – that SubSonic would be the database juice in the ASP.NET MVC story. Or if not the juice then the ActiveCherryOnTop.

The pieces didn’t quite fall into place, though I tried many a time. The issues that I faced were pretty simple – everything I tried didn’t quite fit. No one wants to take a dependency on a specific data access library (which is precisely the thing that Rails does most of the time – and it’s quite freeing to not think about it) – so working SubSonic into MVC didn’t quite fire on all cylinders.

It’s understandable – but I have a better idea now and I want to see if others are willing to engage with me on it. “Others” being the troupe of ORM-dudes out there: NHibernate, LLBL, and the for-pay guys…

Background

I’ve been talking to Phil of late (actually I’ve been mercilessly teasing him) about his work with the EF team on an ActiveRecord story for ASP.NET MVC. I understand the technical aspects of it, but the last thing I can get my head around is using EF to pump ActiveRecord magic into MVC. Sort of like having to ask the US Congress where the restrooms are…

Anyway I told Phil I’ve had a demo sitting here that I’ve been trying to spruce up a bit – a “SubSonic Starter” site for MVC if you will. I followed some patterns that I thought we could reuse for any ORM/DataEngine out there – and so I hit him up with the idea that I really like…

Elevator Pitch

Long story short – we geeked out for a few hours the other night and it was really fun. Here’s what we came up with:

An “IActiveRecordEngine” API for MVC that would allow you to “plug in” your AR implementation in the same way you might swap out the ControllerFactory or ViewEngine. In the Global.asax you would just “SetActiveRecordEngine(new SubSonicActiveRecordEngine())” and off you go.
Define an IActiveRecord interface for your objects to implement (stuff like Add, Update, Delete, etc)
Create an opinionated Controller<T> that would use this so you don’t have to think about persistence ANYMORE. The idea would be you would use a RESTful approach (like Rails does) with your objects and have a Controller<Post> for example. This controller would already have the “magic 7” actions defined (or magic 5 – depending on how literal you want to be) for CRUD operations and you can add/override as you like.

In addition to that, the IActiveRecord interface would define some “sugary” methods such as “GetKeyName, GetKeyValue, GetDescriptorName, GetDescriptorValue” that would allow you to spin up UI elements with the HtmlHelpers. Something like “Html.ControlFor<Post>(x=>x.Title)”.

There’s so much we can do with this – all without caring about which persistence mechanism we use (EF, SubSonic, L2S, NHib – whatever) as long as they implemented the API. Yes – some would do the API better than others, and if that’s the case then your data story is solved isn’t it?

Doing It In Public

It’s tempting to “come up with a proto” and push it out there – and believe it or not I have one – but I’d like to see if I can take the lead on this and come up with an API that works for the most common scenarios. I understand that “opinionated” approaches to problems generally don’t work well with a committee – all the same I don’t want to do this in the dark.

Before I do anything (as I’m already stretched pretty thin) – I wanted to see what people thought of this idea. So – lemme have it! Good? Bad? Things you’d like to see?

I’ll tweak my prototype based on what you suggest here, and see what I can do with it next!

Tekpub Production Calendar

A lot of people have asked about our scheduling and what we’re up to – so I thought I’d clean up and share a calendar I’ve been keeping using Google Calendar. Please note – we’re at the inception of our business here, so we’re fluid and freaky shifty. But we’ll really try to hit these dates as much as we possibly can.

Use What Works

I know a lot people are going to scratch their heads at the use of Google Calendar. The deal is that it works really well for what we do. I’ve kind of carved my position at Tekpub as “Chief of Content” and to that end I’m trying to get organized as to who’s doing what, when. There are lots of different things I can use but as I’ve mentioned before, most of the time Lo-fi wins.

This calendar is like most people’s – fluid. There are many reasons for things to get pushed (like Oren being gone most of this month) and we need to be flexible – so please keep that in mind.

If you’re a Google Calendar person – this calendar is public so just search for “tekpub” and you can add it to your calendar if you like. I’ve popped the calendar below with the links.

Regularity

One thing I’m trying to do is to resolve some patterns to what we produce – things like “Concept Tuesdays”, “Coder Fridays”, and “NHibernate Mondays” (that just seems to fit for some reason :p). Doing something like this allows people to anticipate content – and also holds our feet to the fire a bit. I’m still waiting to see what shakes out, however, but this kind of regularity is my goal.

Branching Out

So far my voice is the only one you’re hearing and I think some people are .. noticing it. For those who are tiring of my stuttering along – James is finally coming out from under his pile of “ramping this bit** up” stuff and will start laying down the footage for an awesome jQuery series. We also have a list of folks we’ve reached out to who will be producing goodness for us.

We’ve received a ton of requests – please keep it coming!

Production Calendar

Or just have a look:

Hello Tekpub

James Avery and I have just launched a new site, Tekpub.com, that is focused on helping developers kick ass in their jobs. There have been a lot of questions about this after our “soft” launch yesterday, so I thought I would address them here.

What is it you do again?

Screencasts – or more precisely “Video Productions” – and that encapsulates our idea pretty clearly. Screencasts are OK for training and communicating ideas in summary form, but most of the time they’re not terribly detailed, perhaps a bit boring, and overall might leave you a bit short of a full picture.

Our focus is a bit different. We don’t want to just leave you with a vague summary of understanding – we want you to feel like you’ve just watched a book – a book by someone who’s trusted and knowledgeable on the subject. Really the only way we can do this is to make it our full-time focus, giving each episode the level of care that you might find in a television production (well, that’s our goal at least).

Yes, we’re charging for our deep, long-running titles, but we’re also offering free Productions of stuff that developers “should just know”. So far we have 2 free series:

Coder to Developer – a new look at Mike Gunderloy’s classic redone in video form and
Concepts – single episodes of various concepts used in programming.

I’ll be adding more (probably based on feedback) but our goal with these is to give people a place to come to raise their skill level for free.

What “Experts” are we talking about here?

So far we only have one – Ayende – and that’s because there is a need for this kind of thing for NHibernate. I’ve reached out to several other people so far and I’m hoping to get commitments from them in the near future to talk about what they’re doing.

Specifically:

Dave Laribee (Kanban/Lean Programming)
Nate Kohari (Kanban with AgileZen)
Miguel deIcaza (Mono and MonoDevelop)
Tim Heuer (Silverlight)

There are others whom I’ve contacted as well and am waiting to hear back from. The goal is to pick their brains and resolve everything into a meticulously crafted production, leaving nothing out, that conveys what they know in a concise, easy-to-follow format.

Isn’t this kind of stuff free? Why should I pay for it?

Yes, it’s free. In fact the information contained in just about every technical book out there is available on a blog, a forum, or Wikipedia. What you’re paying for is time and delivery. I’ll do the scraping part for you, I’ll get *the* experts to talk about the tools they know best rather than someone who just likes to write a book (and who may, or may not, be right).

I won’t settle for mediocrity. I’ll push to make sure it rocks – that’s what you’re paying for and hopefully it will show. If not, I will refund your money immediately.

Productions, Screencasts, Episodes – What’s Up Here?

Everything we do is in the scope of a “Production”. Each Production, just like television, has episodes to it. Using this concept we can keep a subject alive over time and if it changes, we just add an episode. This is a win for you because if you’ve bought the Git series, for example, and Git hits 2.0 and decides to copy Mercurial’s functionality, we’ll capture that.

In addition if users tell us we missed a feature, or request something explicit, we can add it to a Production. This helps us stay fluid and flexible and deliver stuff you want to watch.

There’s another reason we chose to go the Production model and that is because I liken what I do to producing a TV show. I honestly try to get their technically – so it keeps my mind in a good place.

How do subscriptions work. Can I just buy an Episode?

You have two choices with Tekpub – you can buy per Production (usually around $12-25, depending on the planned episode count) or you can buy a subscription. If you buy a single Production you get access to it and all of its episodes forever – download and streaming.

If you buy a subscription (monthly or yearly) you get access to our stuff, all of it, for as long as you subscribe. If you go yearly you can stream and download. If you go monthly you can only stream.

How often will you be producing new stuff?

My goal is to get new stuff out once a week or so. This depends on author’s scheduling (such as right now, Ayende is traveling so it’s hard to get time together to do another episode. He’s also 12 hours ahead of me (timezones) – the only thing that works is to carve out time on a Sunday – tomorrow. We have an RSS feed for episodes so you can subscribe and know when new stuff hits.

James and I are committed to regular drops and updates, but we absolutely will *not* bend on the quality of it – and that makes us bottlenecks. Good bottlenecks though :). Hopefully we’ll have the ability to involve others in the future – we’ll see how it goes.

Aren’t you just “NPeepCode”?

Peepcode is an inspiration, yes. I’ve watched a number of their videos and their level of commitment to quality is amazing. The one thing that differs us is our format – they more or less do one-off videos and try to fit concepts into 1 hour. Our focus is more about depth, so we’ll slice things up into digestible 20 to 50 minute episodes dealing with a particular subject. This allows us to get super-deep on a subject – to the book level.

Is this a Microsoft-only thing then?

No way. Our focus is on Microsoft techology right now because it’s what we know most, but we plan on covering anything and everything.

Is this why you quit Microsoft?

No. After my last day I was building a site for my brother using Rails and I wanted to sharpen up some stuff I had forgotten so I headed over to Peepcode to watch a screencast. Coincidentally I was also trying to figure out a way that I could afford to keep doing what I love to do – MVC-Storefront style learning/screencasting – and when I started watching the Peepcode thing it hit me.

I want to do this full time.

I started looking around for help and the first person I thought of was James. It turns out he was trying to do the exact same thing I was thinking about – and so we put it together.

How about a look at a Production schedule so we know what’s going on?

Yep – I’m putting this together right now. I just need to think about the best way to deliver it. I also need to be sure Tekpub.com is stable (more about that in a later post. A pretty entertaining story involving sheer panic and Rob shouting at people).

Summary

In short form: we’re not out to make a zillion dollars here. This is what I love to do and if I can do this and not lose my house (while feeding my kids) than I’m a happy, happy person. There is a void in our industry – which is the need for non-biased (platform, corporate, opinionated) material presented in a clear way. We want to fill that void and hopefully illuminate biases/prejudice out there through education.

Or as my local friends would say:

“Akamai! Den go home already an poun’em wen pau”.

Thinking About Hawaii? I Got Some Tips For Ya

This post is way off-topic and if you aren’t planning to come to Hawaii, or if you don’t even care about this place and want to see some code – well move along. This post is for people who are thinking or are planning on coming out to the Aloha State – my practical tips and ideas for having an awesome vacation. If you aren’t or don’t care, this post isn’t for you :).

OK – let’s get to it: Yes I live in Hawaii – no I’m not crowing about it – I promise. I’ve been asked soooooo many times, however:

“Hey what’s fun and cool to do over there? Where should we go? Any local tips?”

And yes – I have plenty! I used to have an email that I wrote for a friend long, long ago that I would copy/paste every time someone pinged me. I’ve been told countless times to “put it on the blog” so here it is – a useful and practical guide to the best possible Hawaiian vacation you could have (IMHO).

Planning

Hopefully I’ve caught you before you started to “plan”. It’s what people like to do – especially those with kids (as I suspect you probably have some). It’s good to plan, but I’ll tell you right now that unless you’ve been here every year for the last 5 years – you’re overplanning. This place is just about as low-maintenance as you can get and people freak themselves out about “what’s to do?”. The answer: nothing – it’s perfect.

More on planning in general below – but know this: if you don’t plan anything, you’ll have a better trip. This idea pervades this post so I want to start with it up front so I don’t surprise you. The reasons why are simple:

The “touristy stuff” types know you planners are out there, so they’ve blitzed the SEO to get you to commit to their packages before you arrive. Likely you’ve investigated the place and you have plan – do me a favor and toss it. There’s a 90% chance you’ve been sucked into a tourist trap.
Hawaii moves on its own pace. Fight it and you’re swimming up stream – best to let the trades take you where they do. The term “Hawaiian Time” is very real here – you absolutely cannot be in a hurry or you in for a world of pain.
There are savvy people here who want your money. They aren’t crooks, but often you’ll sign up for something like “authentic Hawaiian Luau” only to find on the last day of your trip that you really would have been much happier with a bottle of wine and your spouse/family on the beach at sunset.

I really need your trust here. I have a 99% batting record and if you follow at least the basics here (don’t plan anything) then you’ll have the time of your life… just give up the plans right here and now and let’s rock this.

Which Island?

Many times this decision is made for you – Uncle Dan’s timeshare or maybe you have a favorite. If you’re flexible, here’s an incredibly condensed list in no order:

Oahu (Honolulu): This is the #1 destination and home to Waikiki. If you like Cruise Ships and Times Square – this is your island. It’s spectacle and crazy town, but there is a LOT to do. Keep in mind Honolulu is the 11th largest city in the United States – don’t expect Lilo and Stitch but there is a lot of island-style nightlife, art museums and so on.

Maui: Party Island and part time home of Rick Strahl. The southwest shore is home to (probably) the most amazing stretch of resorts in the entire chain – it’s basically a prison for tourists. This is OK if all you want is a pool and a beach. In fact it’s more than OK – it’s perfect. Lahaina is my 2nd favorite town on all of the islands. I don’t know why – I’m a sucker for its history and brain-blowing sunsets. Maui, however, is 2 shades from Cruise Ship.

Big Island – Hawaii. Kona-side is dry and moon-scape-y with resorts carved out of fields of lava. The diving here is the best in all of the islands. If you’re a diver or love resorts – go here. The Big Island is great as long as you don’t want to go anywhere (there’s nowhere to go). Volcano Park is … interesting but smells :) and it’s a long (3 hour) drive from everywhere. Hilo is nice too.

Kauai – My Home. This is the oldest island and yes I’m biased, but I moved here for a reason. This is frontier Hawaii and probably the closest you’ll come to touching something of “real Hawaii”. I’ll have a lot more to say about resorts and Hawaii – but if you want to go home with your mind blown, Kauai is the place. Yes there are resorts and no, there’s not too much to do. If you watch those Corona commercials and salivate – this is your island. The North Shore (where I live) is magic – the rest is nice and fine, but tropical old jungle Hawaii is here, on the North Shore of Kauai.

Where To Stay?

If you’re planning a trip I’m going to guess you’ve been online and have tracked down hotels and resorts (this applies to those with children and without). Stop. Please.

Forget the hotels. They’re great and I’m sure you’ve got a great deal – that’s how they get you in. The hotels don’t make their money on the rooms – they make them on everything else (dinners, drinks, etc). You will double your bill – I promise you – in dinners and other things.

The average room fee over here is $250/night at a reasonably nice hotel. I know you’re going to scroll straight to the comments and tell me “dude no way I scored $90/night from Travelocity”! Yes – and you’ll get what you pay for. Many people don’t come back because of the nasty place they end up staying in…

OK fine - let’s lower it to $200/night and for a week that’s $1400 or so. Not so bad eh? But while you’re here you’ll need to eat each entree at that neat hotel is around $28 - $30 PER PERSON. Beers are $8 and drinks are $12. No, I’m not kidding – as I said this is where they make their money. You will double your daily room cost easily on food and “stuff” – so what to do?

Rent a condo or home. You won’t believe what you can get over here, 2 blocks from the beach. Let’s cover the costs:

3 bedroom home 2 blocks from the beach for $1400 per week. You go to Costco (every island has one) and blow another $300 on your food – with another $200 for incidental food and guess what? You’re ahead by $900 EASY. And you have more room and you can eat when the food you like on your own time.

If you have kids – this is an absolute MUST. If you have a baby (8 months or less) what you should really do is pop for a bit more and get a house on the beach – on whatever island! Check it out:

This is the Nalu Beach Cottage right on the sand in Hanalei. Yes you can find cheaper – but this place rocks. The price tag is a mind-blower at $4000 but if you travel with another couple (preferably with children) it comes in at $2000 apiece. Yes, I know that’s still crazy but the house is within baby monitor distance from the beach – and as new parents you’re not going to do anything else anyway and nap duty on vacation while your spouse is at the beach SUCKS.

Tip: If you have a baby you can have them sleep in a dresser drawer on the floor – leave the baby prison at home :).

Finally – you can always find awesome radical deals on VRBO – Vacation Rental By Owner. Friends have had great success with this. Also – Craigslist is great for finding local people who might have a condo for rent here. This is mostly for people on the West Coast of the US – San Francisco, Portland, Seattle (especially), and Los Angeles/San Diego.

Music

You gotta have tunes when you’re here and you can get them online before you come. Load your iPod and rotate these guys:

Hapa. This album has won so many awards it’s ridiculous. You can use this as a lullaby for your kids when you get home as well…

Brudda Iz (Isreal Kamakawiw’ole) - “The Big Man” and probably the most recognized artist from Hawaii. You can’t go wrong with any of his stuff, but this one is my favorite.

Paula Fuga. She’s a new one and has an absolutely mind-blowing voice. Kind of Billy Holiday goes to Hawaii. “Lilikoi” is her best song :).

Slack Key. Gotta have some of that!

Most of the places you rent these days have some kind of iPod player – but if in doubt bring your own if it’s small enough. If you want to be sure – email the person you’re renting from, they’ll tell you.

What To Do When You’re Here

OK so you’ve picked an island, you’ve got your tunes… now what to do? You won’t want to do this – and you’re going to fight me on it. I live here so you have to trust me :):):).

Nothing. Let it happen.

This is utterly impossible, I know. You’ll probably want to know “what’s to see” and “things to do” but ultimately Hawaii isn’t about “seeing stuff”. This place is incredibly serene and, well, dull. The best days of all of the vacations I’ve had here (and friends who’ve come over) are the days where they get a towel, a book, and a drink of choice and pick a beach and just soak it in.

This will sound weird, and I don’t blame you for telling me I’ve lost it – but Hawaii is a very wild place. Nature busts out of every single corner possible and you can feel what the Hawaiians call “Mana” (muh-nah) – or “magical power” if your mind is still and you’re receptive. I’ve (literally) watched people cry just watching a sunset.

It’s not just the scenery – it’s not the smell of the flowers nor the people you’re with. It’s yourself at rest, being opened to raw, powerful Mana – the magic of the land. This usually doesn’t set in until day 5 or 6 of the vacation – but when it happens to you it will be what you remember, I promise. What you really want to do is decrease the time from 5-6 days to 2-3; and you do that by not distracting yourself with busy stuff.

You might want to do a luau (Hawaiian feast) – just know that these are tourist traps – all of them. The food is good and it’s neat spectacle, but luau’s are feasts that are meant in the same way as our [Big Holiday] dinners – it’s like having Thanksgiving every weekend for people that come to visit the US. It’s kind of weird.

If you want to see Hula (which you should, it’s stunningly beautiful) take a look in the local paper’s or entertainment rags. Usually a “halau” (‘huh-lao’: hula school) is putting on a performance or benefit. This is the real stuff and make the effort to go. They tell stories and the meaning behind each dance. If you can, find the Halau that does “Mele” (Mel-ay) hula – this is the real hula and not full of grass skirts and coconut shells.

Other than that – seriously – plant yourself and challenge yourself to let the veneer of everyday life/work/whatever melt from you. Open yourself to the Mana of this place – it will touch you and blow your mind if you let it.

What Not To Do

Well you have to have this list don’t you :). Here’s some things to remember when you get here…

This is a foreign country. Hawaii was only made a state in 1959 and the people were flushed out of the jungles at the turn of the century. The culture is made up of natives and immigrants from all over the world – it’s a melting pot of massive proportions.
Things move slowly – including traffic and service just about everywhere. It’s the way it is and getting upset about it makes it worse.
Drive the speed limit. You will get a ticket (or worse). It’s pretty common to see people speeding out of the airport here – used to the “speed limit +10” rule. Not here – the roads aren’t terribly safe.
Pay attention to the water. The ocean is 75 degrees (plus or minus) and is great to swim in. If there are waves make it a habit to ask lifeguards if there’s something to worry about. We’re in the middle of the Pacific and the waves are, literally, freight trains that aren’t slowed by anything at all until they hit our shores. I’ve pulled 4 people out of the water – one of them was dead. It’s not an unsafe place – it just requires attention on your part :).

Be safe and courteous… (I sound like Mom).

Food.

Hopefully you’ve elected to stay in a rental – you might be wondering “what can I eat?”. You can survive (happily I might add) on this, every night if you wish:

1 block of Ahi sashimi from the grocery store ($7)
One cup of rice (20 cents)
one scoop of Poi (50 cents)
and a salad of your choice.

The salad can be made from local greens – fairly cheap – or you can get the seaweed salad from the store. This meal serves 2 for $10 or so and it’s perfect – add soy and wasabi (which your house likely has) and you’re in heaven. The Ahi (red tuna) in our stores is plentiful, awesome, and cheap – just wash it and cut! Broke da mouf!

A Note About Poi

Here’s the thing about Poi – people don’t eat it right and then complain that it sucks. If you did you’d love it. First, some history:

Poi is made from Taro (Kalo) – a big tuber that grows in rain-flooded valleys. Taro farmers harvest the taro by pulling it when it’s ready, chopping off the root (to make Poi), and then replanting the left-over cap. This means the same plant can be regrown endlessly – and indeed it has.

Much of the poi that you see in the stores comes from my neck of the woods- Hanalei Poi (the picture here). The taro in this valley is incredibly old and is referred to as “the ancestors” as it literally has fed the Hawaiians for hundreds of years. It’s ancient and awesome and you’re eating history…

OK – so history might not taste so good for some folks. Here’s what to do with poi:

Don’t ever eat it straight. You’ll get laughed at.
Add water to it. You want it the consistency of pancake batter.
Dip your meat in it. Sushi is good – but cooked meats like chicken or steak is unreal.
A dash of soy sauce makes all the difference.

When you eat it, close your eyes and hear the breeze outside – smell the Awapuhi and ginger that lights up the night air and twang of the slack key. You can taste the wild earth and sea breeze in the poi – it’s incredibly good for you and if you let your mind go, you can feel the Mana from the ancient taro creep into your bones…

What To Pack

You might think this should have come first – but I had to preface a lot of stuff! If you’re coming for a week then you should bring…

3 bathing suits/board shorts. You can get these at Costco if you don’t have any – they’re $20 apiece.

a pair of flip-flops. You can find these anywhere on the mainland, but Costco has them as well. Don’t bother with shoes or Tevas or whatever “outdoorsy” shoe thing you have. Red dirt ruins all – just get some flip flops as you’re not allowed in any house with your shoes on. Flippies come off easy and cost about $20.

4 T-shirts/Simple Cotton Tops. You don’t need long sleeves here unless you come in Dec/Jan/Feb – then you might want to bring a pullover (1) as well.

NO SOCKS.

Cotton Briefs (for men). Boxers will be painful after a while, and you’ll want to put your undies on after swimming TRUST ME – keep the boys dry!

That’s just about it. Most of the time the locals wear their board shorts (surf shorts) and when it rains they take their shirt off, tuck it in their shorts, and keep on truckin…

A Note About The Rain

The Resorts have made a killing by putting themselves on the South and Southwestern (“Kona”) sides of the islands. This is because tourists don’t like rain out of habit.

Embrace the rain – it’s warm and the Hawaiians consider it a blessing and usually (when we’re not having a storm) the rain is gone within 15 minutes and it will be sunny again. This is because our cloud deck is at about 700 feet versus that of the mainland, where storm clouds are up at 5-6000 feet. Our clouds move in fast and furious, dump a lot of fresh, warm rain and are gone just as quick.

The Best Time Is With Those You Love

If you’re not coming alone it helps to think about what it is you’re about to do: a vacation with the most important people of your life to a place that is all about “Aloha”. Distracting yourself with silly trips/hikes/helicopter rides is fine if you’re super bored, but there will be a time when you’re watching the sunset and it hits you – the Mana – and you say “this place is just bitchen”.

It’s not the place – it’s you and who you’re with, sharing a wonderfully quiet and exciting moment. Embrace that – know it’s you creating the moment and do what you can to have more moments like that.

This happens readily when you “hit the Hawaiian Groove” – when the Mainland pace wears off and you feel yourself get lighter and the smiles come more often. Hugs (especially for your kids) make this happen faster – long walks on the beach too.

If You Come To Kauai Let Me Know…

Every Saturday (barring weather) my family and our “calabash” families (good friends) get together at a beach on the North Shore of Kauai called “Black Pot” – it’s at the very end of Hanalei Bay by the pier. If you come to Kauai – this is an invite to join us. I’ve had a few friends come by and it’s been great fun – and I never get a chance to geek out!

So if you’re coming our way – there’s always a place for you at our fire!

Summary

There’s so much more I can write – but this pretty much covers the main thrust: your vacation is about you, not giving your money to silly tourist traps. You can have 10 times the vacation for less money if you let things roll and let the Mana of Hawaii pull you in.

200 Page Manual on Inversion of Control, Part 2

I’ve received a ton of email with questions about my IoC post the other day, so I thought I’d take a minute (or 60) and write up a followup. In this post I’ll try to put some pieces together and explain a bit more as to *why* you might want to use DI/IoC and how it won’t turn your application into the Mars Rover.

Quick Review

In the last 2 posts I’ve covered 4 “Cool Kid” patterns and tools:

Dependency Injection: wiring a class to take its dependencies via constructor
The Repository Pattern: formalizing your data access into a class with explicit methods (IPostRepository)
Inversion of Control: using a special container to instantiate your objects for you, rather than explicitly declaring them yourself.
Mocking: a groovy testing tool/trick to orchestrate your tests at a higher level.

These concepts are a lot of fun to read, but many people say “yah so what” – and that’s the focus of this post: to tie the strings together.

Our App So Far

I’ve been using my blog project (building my own blog) as the basis for my examples, and I’ll keep doing that for this post. Here’s what we have so far (I’m using ASP.NET MVC):

IPostRepository repo;

public PostController(IPostRepository postRepository){
   repo=postRepository;
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

and I’ve wired up IoC using StructureMap to inject my IPostRepository for me:

public class BlogRegistry : Registry {
        protected override void configure() {

            ForRequestedType<IPostRepository>()
                .TheDefaultIsConcreteType<SQLPostRepository>();

        }
    }

Many people have asked me: “I don’t see how you’re using IoC here – you’re not calling for the Container anywhere” – and that’s true. I left that part out as I didn’t want to derail the point on the innards of ASP.NET MVC. But I will address it here.

Wiring IoC to MVC

What you’re about to see is why so many people like ASP.NET MVC: it’s modular and clean in terms of its parts. Yes you can do this with Web Forms – most likely by using inheritance with System.Web.Page – but there are issues with doing it this way since inheritance is another form of coupling (tying your classes to an architecture or implementation). What would be much better is to “shiv” something in – use some Code Fu to work in this change without a lot of pain. And you can do just this with a thing called a ControllerFactory – which is a core piece of ASP.NET MVC. They have a single responsibility which is to find and create the Controller that your route is asking for. If a user comes to my app and requests “http://myblog/post/index” – routing will dissect this and see that I want to use the PostController and execute the Index action – all good. It’s all magic and “just works” – but the good news is that Phil and team have left back doors in the framework just about everywhere, so we can shimmy-shake it as we need to (another reason why ASP.NET MVC is fun). What I really need to do is to intercept the process – right where the Controller is created – and have my IoC create the Controller instead of the core bits. Doing this will allow me to set all kinds of fun injection rules and have at my Controllers as I feel. To do this, I need to create my own ControllerFactory – the thing that creates the Controllers to service the request – and design the process myself:

public class HanaControllerFactory:DefaultControllerFactory {
    protected override IController GetControllerInstance(Type controllerType) {
        IController result = null;
        if (controllerType != null) {
            result = StructureMap.ObjectFactory.GetInstance(controllerType)
                as Controller;
        }
        return result;
    }
}

That’s all there is to it :). You might have been expecting a lot more here – but as I mention above: Phil and team gave the ControllerFactory a Single Reponsibility (following some principle that I can’t recall the name of) – making it easy to implement/override (love you Phil!). Now that I have my ControllerFactory created, I crack open the Global.asax and wire it up:

protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);
    StructureMapConfiguration.AddRegistry(new BlogRegistry());
    ControllerBuilder.Current.
        SetControllerFactory(new HanaControllerFactory());
}

That’s all there is to it. Now all of my Controllers are “wired” with Inversion of Control, and I can use it from this point on.

Greasing The Wheels With IoC

In the first part of my IoC post I had a comment from Dan A:

In this simplified example above you switched from 3 lines of easily understandable code to something that requires code in the global.asax, another couple classes, and an interface. The end result contains an extra line or two of code, but now the whole thing is “reusable” and can be unit tested. I happen to agree with Joel’s quote which you openly mocked… it *is* more convoluted. It *is* harder to read and grok. And this was an overly simple example… I’m sure it gets more convoluted with large projects.

Fair enough – reading the StructureMap stuff isn’t so easy – but please consider that as far as my application goes, I’ve added 1 dll and about 18 lines of code. What has it bought me? Check it out… Let’s focus on a very real scenario – growth of the application via shifting business needs. Let’s say that I’m building this blog app for my work and so far it’s working as intended – it adds posts, displays posts, etc. My boss comes in and tells me that they want to move to a more CMS-type of system with version control and some rules around publishing. They also want to have the notion of pages as well as posts. Normally you might throw up your hands and say “REWRITE!” – buy you don’t need to. Breaking the requests down, what’s needed is a more formalized way of working with the data – a business layer if you will. In there we’ll do all kinds of fun things like version our posts and so on:

public class CMSService(IPostRepository repo): ICMSService{
    public IList<Post> GetPosts(){
    //...
    }
    public void SavePost(Post post){
    //..
    }

    //other stuff
}

(You’ll have to use your imagination a bit here for more “CMS-y” stuff… and yes I recognize that you’d probably have a few more classes than this. Work with me here people…) Since I want to test my CMSService class I’ve used the Dependency Injection Pattern once again (passing IPostRepository in the constructor), and I’ve also created an interface called ICMSService so I can mock this thing as required. Now I need to refactor my PostController to use the CMSService:

ICMSService _service;

public PostController(ICMSService service){
  _service=service;
}

public ActionResult Index(){
   var posts=_service.GetPosts();
   return View(posts);
}

… and I have to deal with the Container stuff. You might think “aha! THIS is where Conery eats his hat – this is going to be FUGLY”! Keep in mind that all I’ve done to this point is a bit of refactoring to my application – I haven’t touched the IoC stuff at all. Hold on to your hats…

   public class BlogRegistry : Registry {
        protected override void configure() {

            ForRequestedType<IPostRepository>()
                .TheDefaultIsConcreteType<SQLPostRepository>();

             ForRequestedType<ICMSService>()
                .TheDefaultIsConcreteType<CMSService>();

        }
    }

Yes – that would be one line (well, one line broken in half to keep my page from getting too wide). And that one line does 2 things:

It tells StructureMap “whenever you see ICMSService in a constructor – use CMSService” and
It deals with injecting CMSService with IPostRepository *and* injecting the PostController with ICMSService.

That is why IoC is Good Time Fun – as your app grows, shuffling, refactoring, and tweaking your application is an order of magnitude easier.

More Examples

As the application grows I’ll doubtless have to add many things to it – Logging, ValidationEngine, EmailServices, AuthenticationServices – etc. Being a good Cool Kid, I make sure to interface each of them so I don’t take on coupling, and I add them to my IoC registry:

   public class BlogRegistry : Registry {
        protected override void configure() {

            ForRequestedType<IPostRepository>()
                .TheDefaultIsConcreteType<SQLPostRepository>();

             ForRequestedType<ICMSService>()
                .TheDefaultIsConcreteType<CMSService>();

             ForRequestedType<IILogger>()
                .TheDefaultIsConcreteType<NLogLogger>();

             ForRequestedType<IEmailService>()
                .TheDefaultIsConcreteType<SynchroEmailService>();

             ForRequestedType<IAuthenticationService>()
                .TheDefaultIsConcreteType<MSMembershipService>();

             ForRequestedType<IValidationEngine>()
                .TheDefaultIsConcreteType<XMLValidator>();
        }
    }

Now when I need any one of these things – I just ask for them where I need them - even in my Controller:

ICMSService _service;
ILogger _logger;
public PostController(ICMSService service, ILogger logger){
  _service=service;
  _logger=logger
}

public ActionResult Index(){
   var posts=_service.GetPosts();
   //log the posts
   _logger.Info("IoC Rocks...");

   return View(posts);
}

One thing to note: the IoC container handles the instantiation completely, so when I alter the constructor as I’ve done here, I don’t need to change the calling code anywhere else (except for tests). I haven’t really even touched on the best parts yet :). Typically you’d want to have some level of logging in every part of your application – such as your AuthenticationService as well as your EmailService. Once again you don’t want to take dependencies in there (especially on a particular logging engine!) because you very well may reuse them later, or you may change your mind. I have an AuthenticationService and EmailService I use in just about every app I create – it’s what we do – we’re pack rats. Can you imagine what my PostController would look like if I had to inject the logger into it, as well as into my services (that are also passed to the same constructor)? I’d offer a code sample but it makes my brain hurt just thinking about it. This is “Constructors Gone Wild” and it’s really, really ugly. Instead – I’ve opted for IoC – which will inject “stuff” wherever it’s “injectable” – as long as it’s responsible for creating the object in the first place. Since I made my own ControllerFactory – everything else is buttah and IoC “knits” it all together.

Even More Examples

My project has been a success and my manager actually kissed me because I came in under budget and ahead of schedule (his beard is scratchy…). Now he throws me a curve ball and says “hey you know our site’s slowing down a bit – but only when people leave comments. I think we have an issue with sending out emails. With all of our users – that’s a lot of email all at once.” Taking a look at my EmailService I see that “DOH!” – it’s the SynchroEmailService and YES – it’s trying to send emails synchronously (inline) to n people when a page is submitted. Yikes! That should be asynchronous and put behind a “chron” – or a scheduled job. I spend 3 hours writing up/testing another mailer (“AsynchroEmailService”) – one that sends the email messages to a queue and logs them using my ILogger. And now I have to implement this – how would you do it? I get to do it in one line with IoC:

ForRequestedType<IEmailService>()
                .TheDefaultIsConcreteType<ASynchroEmailService>();

It just doesn’t get easier than that.

But Wait, There’s More!

My boss and the lead engineer are looking over the code I wrote for the AsynchroEmailService and they like it, but the Lead Engineer has been reading his pattern books again and says

Can we do something with a little less memory pressure here?

Memory Pressure? ORLY? I try to convey that the cost of instantiation here is incredibly minimal – almost at the atomic level – but he insists on doing it right and “Can I use a Singleton”. Rather than argue – I say sure (have you ever had this discussion by chance?). Have you ever tried to code a Singleton? It’s not very fun – in fact I’d say that most of us (me especially) are “doin it wrong”. Locks, threading, ick. Once again – IoC’s got my back:

ForRequestedType<IEmailService>()
                .TheDefaultIsConcreteType<ASynchroEmailService>()
                .CacheBy((InstanceScope.Singleton));

Not sure that could be any easier. I could also choose to cache by HttpContext, PerRequest, ThreadLocal, and “Hybrid” (which means, basically, the same as PerRequest but works better for testing). For now I choose “Singleton” to keep my Lead Engineer happy.

Summary

You can do most of these tricks with WebForms as well – but to be honest I’m not sure what the best way is. I’m fairly certain you could do it with inheriting a base class from your Page and then explicitly working with properties (read only):

public class MyPage:System.Web.Page{

   public ICMSService CMSservice{
      get{
        return StructureMap.ObjectFactory.GetInstance<ICMSService>();
      }
   }

}

It’s a lot more manual, as you can see, but this *should* work (warning: I’ve never tried it). I’m hoping that you’re beginning to see (if you haven’t already) that IoC *can be* a complicated thing, to be sure, but hey you work on computers and you’re already ahead of the curve :). If you think your application will grow (which most do), IoC can really become your best friend.

Using Dependency Injection and Mocking For Testability

My server got buried yesterday from my IoC post. I think that’s a good thing, but it also underscores the need to have more detailed, simple tutorials to share concepts. I wrote that post with a bit of a giggle since I was poking fun (again) at Joel – I won’t do that tonite since I think that aspect got in the way of some good stuff and many people thought I was attacking Joel again. I spose I was a bit “in his face” – but it’s OK to disagree with someone – it doesn’t mean I hate the guy.

Anyway got a Tweet from Rick Strahl right after I posted that post:

When I wrote the post I was thinking I should do just that – but IoC doesn’t have too much to do with testing (the Dependency Injection pattern is what makes it more testable) so I didn’t want to derail the post. But since Rick is only an island away he can come “wop my jaw” so, for you Rick – here’s some more stuff on DI and testing.

The Things We Do For Testing!

This is the major pain-point for most people when they’re confronted with a TDD discussion. All it takes is a look at the code you need to write to facilitate “good testing” and it tends to sour people immediately. Why all this extra code!?!?!

The answer is that, like scientists, you’re trying to control the testing environment. I used to work in a lab, and I used to wear a silly mask and yes I wore a white lab coat. I had to have my hair cut short and wear a cap and there were notebooks upon notebooks that recorded everything. It was craziness, but at its core it was the scientific method at work: remove the variables.

That’s what it’s all about: removing the variables that can negate the outcome of your test. We’re not scientists, to be sure, but at the same time we’re not plumbers. I’ll stop at this point – but I will leave you with the notion that it’s your responsibility to prove your stuff works. Testing is a good thing!

Last Time, On Rob’s Blog…

We used IoC to free up our Controller, but I never finished off the test. So now I have my Controller setup the way I want, and I have a lame test that needs to change:

IPostRepository repo;

public PostController(IPostRepository postRepository){
   repo=postRepository;
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

And my lame test that hits the database and proves nothing:

[Test]
public void Post_Should_Show_Posts(){
   var controller=new PostController();
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.IsGreaterThan(0,posts);
}

My goal, for this post, is to make this test meaningful and to also make it pass. For that I’ll need to reach into the Tester’s Bag Of Tricks and use the Swiss Army Knife of Environmental Control: A Mock Container.

Controlling The Test

If you look at my lame test above, you see that I’m not testing anything. In fact it’s not even going to work consistently because I’m hitting my database (see my last post about this).

I don’t want to hit the database – it’s a variable and it blows my control on my test. What I’d love to have is a way to bend the universe a bit and just say

Dammit just pretend there are 20 Posts in my database!

If I could do that, then a test I could write might be something like “Index_Returns_100_of_100_Posts_In_Repository” – which again is a lame test – but it’s lame because I wouldn’t want to throw 100 posts on my home page! But it’s a test that will lead me to write other tests, which tosses us in TDD territory and that’s a good thing – so let’s go there.

The fun part is that I can easily bend the universe to my will – at least in the code sense – using something known as “Mocking”. You’ve probably heard of this (or maybe you’ve used it) and you’ve also (most likely) heard people argue about it. Testers can be a cranky bunch – but you know what – it’s because they really like what they do. They’re like football fans that love their team (or soccer) – they think you’re an ass because of your team, not really because you’re you.

Anyway, my team is the Moq Lambdas – (because Moq uses Lambdas a lot…) but there are others (in the same way there are other IoC containers) and it comes down to what flavor mock bubble gum you like to chew. I like Lambdas so therefore I like Moq (and I’m afraid of Daniel Cazzulino – dunno why. I should be more afraid of Osherove).

Download Moq and drop it in your testing app’s references – it’s a single DLL which is lovely.

Some Details on Mocking

I’ve read countless blog posts about Mocking and usually they start with something like “Hey mocking is teh suck and it’s really easy – check it out: [crazy ass code that looks like finger paint] – isn’t that cool! The best part is Interceptor is written in Erlang and the guy who wrote it was born in an insane asylum and sleeps only 1 hour every night!”.

The thing is – a Mock container is like an IoC container (discussed last night) – except that it’s all FAKE. It’s just stuff that’s made up, and handed over when you tell it to hand it over.

Think of it this way – you’re in high school and you and your friends really want some PBR (Pabst Blue Ribbon) because you’re headed over to Steve Harman’s house and all he drinks is Red Bull and Pabst (yes, mixed). No one will buy for you, so you pop a wig and fake beard on your tallest friend and say “when that guy in there asks you if you’re 21 – you say ‘yes’ – you got it!”

That’s all it is – truly. And in this way you can lie to your application when it asks for certain things – like data.

Lying To Our PostController

I’ve referenced Moq in the application and now what I need to do is to build up a good lie to tell my PostController. It needs to think there are 100 Posts because I’ve rewritten my lame test to be a bit more concise:

[Test]
public void Index_Should_Return_100_of_100_Total_Posts(){
   var controller=new PostController();
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.AreEqual(100,posts.Count());
}

This test is much, much better since the title of it clearly states what we’re testing and what’s expected. It’s not vague – That’s important!

This test will of course fail because I don’t have 100 records in my database – until I lie to my Controller:

[Test]
public void Index_Should_Return_100_of_100_Total_Posts(){
   var posts=new List<Post>(0);
   for(int i=0;i<100;i++){
      posts.Add(new Post());
   }
   var mock=new Moq.Mock<IPostRepository>();
   mock.Setup(x=>x.GetPosts()).Returns(posts);
   
   var controller=new PostController(mock.Object);
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.AreEqual(100,posts.Count());
}

I’ve added a silly List<Product> and filled it with 100 Posts. There are other ways I can do this – but this is the easiest for right now. I then handed that List to Moq and said “see that PostController over there? When it asks you for posts – hand it this!”.

This is cheating at its best and yes – it’s that simple. The best part is that this test will never fail – until I change the Controller to add paging – which I should really do since returning 100 tests is really dumb from a usability perspective. This testing thing is making me think a lot…

Tests Breed More Tests

One of the fun things about learning tricks like Mocking is that you find testing to be fun – yes fun – because now you know that tests *simply can’t be ignored because of [whatever lame circumstantial reason]*. Moreover the tests you write start to make you think – is this what I really want to happen? Always?

In this case – no. What I really want to do is page my results – 100 Posts on my home page is pretty gnarly and bad for performance, reading, etc.

Adding this change in is pretty simple – and you start with the test. Let’s rewrite it:

[Test]
public void Index_Should_Return_20_of_100_Total_Posts(){
   var posts=new List<Post>(0);
   for(int i=0;i<100;i++){
      posts.Add(new Post());
   }
   var mock=new Moq.Mock<IPostRepository>();
   mock.Setup(x=>x.GetPosts()).Returns(posts);
   
   var controller=new PostController(mock.Object);
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.AreEqual(20,posts.Count());
}

Ahh – this test is nice. It’s still not perfect since we’re not addressing paging explicitly, (hey – see that, another test :) ) but I can’t make this post too long…

The test will now fail, which is what we want (to make sure our mocking and everything else is working as expected). Now we need to tweak our app code a bit (pretending our repository is returning IQueryable):

IPostRepository repo;

public PostController(IPostRepository postRepository){
   repo=postRepository;
}

public ActionResult Index(){
   var posts=repo.GetPosts().Take(20);
   return View(posts);
}

And with this I start to see the application take shape – my testing is pushing out the features of my app. How nice.

What This Buys Me

If you can set conditions for your application like this – using Mocking – you really don’t need to hit F5 to make sure your app works. You can mock up all the situations you can possibly think of (well – almost) and pretty much write your application completely from the Test Project.

Some people actually do this – I’ve seen it in action. They literally mock up all these diverse situations then pound out there code before the application is ever run, gleefully running around their office with test results and doing shots for every percent less than 100 of their code coverage (I miss Phil and Eilon…).

This is TDD – writing tests and doing shots.

Summary

Hopefully you’re starting to see that the Cool Kids don’t have a lock on Cool – and hopefully you’re starting to see “Cool” as the evolution of the industry. Things do indeed change and there are folks out there taking the risks and trying it out for you. Sometimes it works, sometimes not – the important thing is the trying and letting these guys try stuff without judgment.

200 Page Manual on Inversion of Control (plus or minus 199)

I’d like to preface this treatise with an appeal to those of lesser intellect – please close your browser now. The concepts you read below are quite high-minded and we have a secret handshake you don’t know. We are “The IoC Community” and we rock the concepts yo.

For those who haven’t read the 200 page manual on IoC – well here ya go. If your little brain can’t handle the complexities of this post might I suggest turning on Howard Stern and Spolsky at the same time, full volume, and holding your breath until you see patterns in the air. This usually helps when wondering WTF Joel is talking about.

Let’s take a walk on the Cool Kid side of the street and see what Inversion of Control is all about…

The Setup: My Blog

So I’m building my blog (more on that later) and it makes for a really good demo since most people understand blogs. So I’ll use it for this discussion. Let’s pretend I have a PostController (using MVC) and this thing shows Posts.

I have a single action called “Index” that grabs data from my database and sends it down to my view (let’s pretend I’m using Linq to SQL):

public ActionResult Index(){
   var db=new Model.DataContext();
   var posts=db.Posts.Where(x=>x.IsPublished);
   return View(posts);
}

Groovy. Now let’s get on with this…

Analysis

What I’ve done here is pretty typical, and what you would see in any demo given at a Microsoft conference. The person writing this code can easily invoke the “This is a demo/small app so shutup” rule when the Cool Kids cry foul – and that would hold most likely as it would be either Hanselman or Scott Gu giving the demo and those guys have swagger like that.

There’s no need for complexity at this point – which is true, however it should be noted that we’ve incurred what’s known as “Technical Debt” – which is akin to repairing a go-kart with duct tape. Like debt, you could live with it, but more than likely it will cause you problems as you build out your app.

The Next Step: Making Sure It Works

Typically what you might do, as a developer, is to hit F5 (Debug/Run) to see if data appears on your page. It’s still magic to me after all these years to see data from my DB hit the screen – I dig that rush and for a moment my little itch is scratched and I feel good about myself. I see data there – so it works.

But then I begin to think – do I really want to hit F5 every time I want to make sure this page runs right? I’ll appease the Cool Kids and add a test:

[Test]
public void Post_Should_Show_Posts(){
   var controller=new PostController();
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.IsGreaterThan(0,posts);
}

What’s this test telling you if you put your programmer’s hat on? The title is a bit misleading as we don’t know what the view will actually “Show” – moreover we’re just testing that we have posts.

This test will fail – immediately – and it will keep failing no matter how much code we write. Why? Because I have no data in my database and this test will fail until I add some. Being the impatient type I add a record to my DB and my test passes.

If your geek senses are tingling – that’s a good thing! This test is pointless to say the least – what “unit of functionality” is it testing? None. And if you look at this a bit longer you’ll start to realize that I’m not chanting or smoking a secret mix of techno-herb and sassy weed – I’m just using common sense and basic coding principles. What happens if I remove all records again? The test fails. Does that mean my Controller won’t show posts? Not at all – and this is one main reason the People Who Like Testing (Cool Kids) advocate against hitting the database.

Well what’s the point of testing Controllers then if it’s this hard!

It’s not hard – it simply requires you to look a bit further and use some tricks – that’s all.

Rewind and Refactor: Using an Interface

Interfaces are scary to many developers at first – they seem rather pointless until you actually use them. In this sense they work perfectly since I don’t want to talk to my database at all – what I really want in my Controller is the ability to get data from *somewhere* (not necessarily a SQL Database). That’s the important part – and yes it’s an abstraction – but that’s one step towards the idea of “Loose Coupling”.

When I wrote my initial Controller Action above (Index), I planted data access code right in it from Linq to Sql. In doing that I also made a decision that was explicit: whenever I use this controller, I also need to make sure I have my Linq to Sql classes set up and pointed to my Post database. This is called “coupling” and you can think of Linq To Sql and your PostController on a date, having babies if that helps.

Let’s pretend I made an interface (IPostRepository) with a single method called “GetPosts()” which returns an IEnumerable<Post>. Now I can use it instead of Linq:

IPostRepository repo;
public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

This is a good first step – but how does it help me? I can’t instantiate an interface can I? So how the heck to I make this work?

Next Step: Dependency Injection

Put in plain English: our PostController has a dependency on data from the IPostRepository – it needs it to function (which is a dependency sort of like your college roommate needed to wake-n-bake in order to get moving).

We could just implement our interface in a concrete class (let’s call it SQLPostRepository since we’re using SQL Server) somewhere and instantiate that:

IPostRepository repo;
public ActionResult Index(){
   repo=new SQLPostRepository();
   var posts=repo.GetPosts();
   return View(posts);
}

Now the code works, but we’ve traded one dependency for another (on SQLPostRepository) – what did we gain here? Well nothing actually – and the Cool Kids are getting pissed.

What we should do is to allow the calling code to specify this dependency when creating the class, defaulting to the SQLPostRepository if nothing was set:

IPostRepository repo;
//injectable constructor
public PostController(IPostRepository postRepository){
   repo=postRepository;
}

//default
public PostController(){
   repo=new SQLPostRepository();
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

This works, and now we can test this by sending in a fake repository (made up of in-memory lists) or we can use mocking, which basically “lies” about stuff. I’m going to sidestep the testing aspect here (easily will derail the post) as I want to stay on Dependency Injection and Inversion of Control.

Analysis.

On the face of it we’ve “loosened things up” which is always good as now we can plug in SubSonic instead of Linq to Sql if we wanted to, or next year we can use the [Groovy New ORM] that’s all the rage.

There is a problem, however, with “Naked Dependency Injection”, and that problem is that Controllers typically have more than one dependency. There might be logging involved, email, a comment repository, user repository, etc and you’d have to inject each of these (and update all the calling code when you change stuff).

It’s pretty easy to end up with “Constructors Gone Wild” by following this pattern, and on occasion you can end up with recursive construction – which is really ugly and a maintenance nightmare.

The Answer: Inversion of Control

It’s a strange name – Inversion of Control – it sounds like you’re turning your app inside out. Here’s what it means:

Normally, when your class needs to use another class to do something it will instantiate an instance of that class, use it, and then discard it at some point. In this case our PostController class is controlling the instance of the IPostRepository – determining when it gets created and how. All these decisions being made for our IPostRepository – isn’t that just a bit presumptuous!

Inversion of Control does the exact opposite. You have a thing called a “Container” that instantiates the classes and controls their lifetime (according to some rules you set) and it hands them out when asked for. In our blog app the control is removed entirely from the PostController and is “inverted” – handed completely to the container which tells your PostController “this is the object you’re going to get and you’re going to like it”.

The IoC container is essentially a big playground of objects just waiting to be used and reused. As you can imagine, there’s a lot of freedom when your objects are cut free like this – you can setup all kinds of rules for them and even control their lifetime. Want to make one a singleton (yuck)? You can do this easily with a half-line of code. Want to set an object’s lifetime to that of the request? Same thing.

I’ve used StructureMap a lot as it’s what I know – but Ninject or any other framework is pretty easy to pick up, no Big Brain required – so that’s what I’ll show you below.

The first thing you do is to tell StructureMap what type of class you want when a given interface is used in a constructor. You do this in a thing called a “Registry”:

    public class BlogRegistry : Registry {
        protected override void configure() {
            
            ForRequestedType<IPostRepository>()
                .TheDefaultIsConcreteType<SQLPostRepository>();
           
        }
    }

Then, in your Application_Start you call it:

protected void Application_Start()
{
    StructureMapConfiguration.AddRegistry(new BlogRegistry());
}

Now when you want to use it, you ask StructureMap for an instance of the object:

var repo=ObjectFactory.GetInstance<IPostRepository>();

On the face of it this might seem like a lot of code for nothing – and it’s a bit true. IoC is an investment in your application – not a direct deposit. What you gain is the ability to “unhinge” your classes from one another, reusing them in other applications as needed.

Most importantly, as you’ll see below, I’ve lost all of my “technical debt” and not many things are more fun than being debt-free.

In the case of my blog application, I can override my ControllerFactory and ask StructureMap to build my Controllers for me – this reduces my examples above to this:

IPostRepository repo;

public PostController(IPostRepository postRepository){
   repo=postRepository;
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

Now the Controller knows nothing of any implementation – which is awesome.

Summary

If you’d like to know more about DI/IoC (and some details on how to hook it up to an MVC App), I did a full hour’s video cast with Jeremy Miller (creator of Structure Map) and you can watch it here: http://www.asp.net/learn/mvc-videos/video-366.aspx. It’s about an hour long and I think the best of the entire MVC Storefront series.

It took me just over an hour to write this post – how long did it take you to read it? Does IoC make more sense to you? Regardless if you think it’s worth it (you might think it’s crap) – is it too high-minded? Too complex?

IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual. I personally am perplexed at how the IoC community took a beautiful, elegant article by Martin Fowler and turned it into a bunch of complex frameworks typically with 200-300 page manuals.

Am I a whole lot smarter than you?

I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren't as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It's the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don't understand it.

Is it harder to read my final PostController versus my “Naked DI” Controller above?

I believe that if you use IoC containers, your code becomes, frankly, a lot harder to read. The number of places you have to look at to figure out what the code is trying to do goes up by at least one. And somewhere in heaven an angel cries out.

I mentioned in my last post, in the comments, that I’m no stranger to disagreeing with Joel. It crosses the line, however, when he advocates idiocy – the notion that *you* are too dumb to figure this stuff out.

Are you?

Just Stop. Please.

I’ve tried to stay out of the whole “Spolsky Thing” of late as it seems like it’s spectacle for spectacle’s sake. That seems to be Spolsky’s thing and it’s one of those things you sort of ignore most of the time.

But he just keeps going – sort of like your parents revving your kids before bed while you watch, knowing there’s nothing you can do – he’s just going to do it anyway. It’s weird how that works – my family and my wife’s – they love to rev the kids up at bedtime for some reason and then I spend the next 2 hours trying to get them to go to sleep. It’s not fun, but to my dad, who’s upstairs reading a book (complaining about all the noise coming from downstairs) I just “worry too much – let them be kids!”

Sure. I’ll do that. And I’ll pay the price when they wake up tired the next morning and cry through breakfast while you remind me how discipline was handled when you were a boy.

Anyway - as I read through Joel’s latest train wreck, this clip of Jon Stewart on Crossfire popped right in my head…

Joel – it’s not funny any more. You’re hurting the industry, not helping. You’re acting like my dad did – revving up the industry and spewing old-time wisdom that does not apply anymore.

Here’s some tea – time for bed. Please stop.