LA Code Camp Materials - They're Here!

Okay, the Code Camp site is back up and I've been able to upload my code and slides.  If you need a hand with any of it let me know.  Here are direct links to each session's page.

Dependency Injection - Why Bother?

Fun with Dependency Injection Containers

In addition to the materials, there is a feedback button.  I'd really appreciate it if you'd give it a click and fill it out - it won't take more than a minute.

Thanks again.

LA Code Camp Materials Part II

You're probably thinking that this is the post where I say I've finally posted the sample code and slides.  From the Code Camp last weekend.  And maybe ask you to complete the evaluations online? 

I thought it was too, until I discovered that the Code Camp site was down.

So maybe Tuesday isn't in the cards.  Wednesday perhaps?

If anyone is desperate for the materials (which would be surprisingly nice) leave a comment and we'll figure something out. 

But don't leave an email address unless you have a really good spam filter.

I'll try again later today.  Thanks for your attendance and your patience.

LA Code Camp Materials

Thanks again to all of you who attended my sessions at the Code Camp over the weekend.  I had fun giving it - and the discussion was great.

I'll be posting slides and sample code on the Code Camp web site sometime on Tuesday - sorry about the delay.

Thanks again.

TDD Guidelines

Heard a nice short podcast from NetObjectives on impediments to TDD this morning.  I had to register to get to it, but it doesn't cost anything.

They considered the problems associated with TDD adoption.  One which struck me in particular is the problem of many tests breaking when a minor change has been made.  This tends to push developers to 'temporarily' ignore tests so they can get their work done.  Which often becomes more than temporary.  I know I've built up a test maintenance burden this way.

They addressed this by defining a "good" unit test as follows:

1. A unit test should fail always for a well understood reason.
2. A unit test should never ever fail for any other reason.
3. No other unit test should fail for that reason.

Well, I'm guilty. 

Sometimes I get going on writing unit tests without being mindful of my 'well understood reason' just for the sake of hacking out tests.  This is a nice formulation for me to keep in mind.

xUnit Test Patterns has a lot to say about this kind of thing too.

Dependency Injection Resources

Here are the promised resources:

The Single Responsibility Principle by Robert C. Martin (Uncle Bob) is one of the design principles that makes Dependency Injection useful.  Also recommend are his articles Open/Closed Principle; Dependency Inversion Principle; and Liskov Substitution Principle.  All of these articles are more or less excerpts from his book Agile Principles, Patterns, and Practices in C#, so if you are interested in his book (which is great) these articles would be a good place to start before you make the investment.  Remember there is a Java version of the book too (Agile Software Development, Principles, Patterns, and Practices).

Unfortunately due to the structure of my talk I gave these principles short-shrift, so I want to make myself clear while I have the chance:  I consider them to be more important than the tool (the container).  In fact, I suspect that if you aren't following SRP, OCP and DIP, a Dependency Injection container would be useless anyway.

While I'm on books, Refactoring: Improving the Design of Existing Code is a must have title.  This is the book I mentioned in the talk that I bought years after having it recommended.  It was too bad I waited, because the book was a revelation.  Just the chapter on Code Smells alone is worth the price of admission.

The Castle Project's home page is a link worth having.  There are some tutorials worth looking at here if you want to go deeper.  Note that the Castle Project is a lot bigger than just the MicroKernel and Windsor Container - it also boasts the Monorail project (a .NET MVC web framework) and a really cool Dynamic Proxy.   Great stuff.

Using Castle Project is a collection of Castle Windsor specific resources. 

I'm not actively using StructureMap right now, but they just had a new release that is probably worth looking at.  They also have a NAnt task for testing configuration, which is a really cool addition.

High-Level Concepts is a part of the StructureMap web site which gives some great summaries of concepts surrounding good design in general, and Dependency Injection in particular.  These are important regardless of which container you use.  It was written by Jeremy Miller, who's blog is a great resource no matter what he's talking about.

The IoC mind set: Validation is a pretty powerful article by Oren Eini on how to use a Dependency Injection Container (Castle in this case) to manage a multiplicity of validation rules.  It addresses a point I had hoped to make with my final example but which got lost in the lack of time and the broken code.  The container permits some *very* interesting efficiencies, that you just wouldn't come up with if you didn't have a container.  It is what Oren calls the Inversion of Control Mind Set in this entry.

I'd recommend subscribing his blog if you really want to stretch your mind in this direction.

ALT.NET Portal is a good place to start for exposure to all of the ALT.NET stuff, not just Dependency Injection.  The discussion groups on Yahoo are pretty rich.

Inversion of Control Containers and the Dependency Injection pattern is Martin Fowler's article on the topic.  It is usually the first citation when someone covers this topic.  It examines an alternative pattern as well - Service Locator.

Again, if any of you want further assistance with this stuff, call or email me and I'll be glad to help.  Thanks again for attending!

Dependency Injection Containers Talk at SoCal Rock and Roll Code Camp

Thanks again to all of you who attended.  And to all of you who completed the evaluation forms.  I had a lot of fun doing the talk, and look forward to delivering improved versions of it in the future.

I've printed out my slides to a PDF and put it on the session's page on the code camp web site.  The sample code is also there now.  I've only included the first two samples, but they should be enough to get you started playing around with the Windsor Container if you're interested.

I didn't include the third code sample.  As I mentioned it had some dependencies that I couldn't provide - on code developed in my workplace. 

But I hope to put something together to illustrate the points associated with that third, ill-fated, sample.  Expect to see something here on the blog. If you're interested and don't see anything, please feel free to nag.

There are a few other resources I'd like to post - references to books and/or articles I mentioned in the talk.  Look for that by Tuesday morning.

If you want to pursue this topic further and are running into roadblocks and need a hand, please feel free to call or email me.  Or even post a comment on the blog.  I'll do what I can to help out.

Thanks again for attending the session.  I had a lot of fun.

Professionalism, Programming, and Punditry and Success as a Metric

Scott Hanselman had a nice post in response to Jeff Atwood's post in response to Alastair Rankine's post "Blogging Horror". I don't feel the need to comment on Coding Horror beyond saying that I occasionally find some real jewels there. Good stuff for free.

But Scott's post struck a nerve. Here's some context.

I've been contemplating presenting at the local code camp for years now, but have never gotten around to actually doing it. I'd always figured that I should pick a topic on which I could speak with some authority. Makes sense I thought, but I was never able to pick one that moved me.

Localization is a nice, well circumscribed topic that I have engaged pretty thoroughly over the years. I have some hard earned experience, useful code and guidance borne of long hours. But I really find it difficult to care enough to put it all together into something that wouldn't risk being a waste of someone's time. So I've never done it.

The list of sessions for the code camp was posted a few weeks ago, and I'd been thinking that it would have been nice to see more and new sessions that addressed issues like SRP and OCP and Dependency Injection and other principles of good design. Maybe you've seen this coming, but I realized could do that session I wanted. Certainly then it would be on something that I actually cared about.

Of course the thing that's kept me from even considering it before is that I'm still learning, and still have a lot to learn. But I figured there's no reason that I can't do it based on my own struggles to make my code better.

I finally decided a week ago that I was actually going to do it. This past week's free time has been spent on reviewing literature, searching for good examples, and trying to make sure I've covered all the bases. I woke up at 4:30AM this morning and finally had the scenario for a good example. It was such a nice scenario that I couldn't get back to sleep.

So after I'd finished documenting my example this morning, it was really nice to see Scott's post about Jeff''s post about Alastair Rankine's post. Here's the best bit:

We're all just learning together. I started blogging so I could Google myself later, that's all. I taught as an adjunct professor so I could know the topics better as there is no better way to learn a thing deeply than to teach it. I worked on a few books so I could really dig deep, but I'm the first guy to say "dude, I have no idea." My brain bit-rots as yours does.

That is a nice bit of encouragement, isn't it?

Counting down four more weeks until the code camp and I don't even know if it is still open for submissions (hope so), but I'm going to do the work regardless of whether I can get in under the deadline. If I do it, you'll read about it here. But if I don't (and probably even if I do) it will all eventually find its way here.

We'll see what I can do . . .