This past weekend in West Des Moines, Iowa I attended the Iowa Code Camp.  This was the second such event this year and it amazes me how well these events have gone given they are in their infancy.  The leadership deserves a huge round of kudos for pulling off such a great event.

Recap:

This was a big day as I was leading four session, two by myself, and two fishbowl type sessions.  Below is my recounting of an awesome day!

Open Source Tools for the .NET Developer

This was my only open session where I was not helping or giving the talk.  So this was a good time to soak in some knowledge.  Javier Lozano did a great job introducing some of the open source tools that he considers a must.  I use everything he was saying, so I was hoping to catch a nugget here or there that I could take back to work with me.  In general I think this was a very good talk.  Covered a lot of ground in a short amount of time but attendees could see by the interaction from a few in the crowd that many of these tools are mature and being used quite heavily with a lot of confidence by other attendees.

Fishbowl Session(s)

Chris Sutton has had a vision of bringing open discussion to the Iowa Code Camp since the last go around in May.  He tapped Nick Parker and myself to facilitate.  We weren't sure how the idea of dynamic selection of topics for group discussion would go, but we were very surprised and pleased with the outcome.  We had two of these "sessions" during the day and both of the discussions were very good.

Easing Your Testing With Rhino Mocks

This was my talk.  I've given this talk before internally but I was a little skeptical of how the talk would go given that I didn't know who would attend, their familiarity with testing and/or mocking, and what they're knowledge level was in general.  I had struggled with where to take people.  In preparation my talk went from "way too much" to "too trivial" at times.  By Friday night I felt like I had the kinks worked out.  Overall though I think this talk went very well.  I first introduced code that does not lend itself to be easily tested.  I wanted to address testability as a design time idea.  After going through what made this code not easily testable we refactored the code to allow us to get in there are test what we wanted.  We created some stubs and mocks by hand to test both state and interactions.  After showing you could test by writing your own mocks I wanted to show that it's much easier to leverage a framework.  Given the amount and type of questions, I feel pretty good that the attendees understood why you would want to mock and how you would do so.  I'm confident attendees walked away with something they could take to their jobs on Monday morning.

TDD: A Workshop in Driving Your Design with Tests

This was my second, self-led session of the day.  I'm not a TDD expert by any means.  Quite frankly, like many out there, I too am learning what it means.  As I've learned and studied, I find that many people classify TDD wrongly.  I often hear something like, "We write unit tests and do TDD" or "We add tests to our code using TDD", which seem to blur the lines between TDD and unit-tests.  I wanted to clear the air and share what I knew.  Rather than doing a talk where I stood up in front of the group and they watched me do something, I wanted to get them involved.  TDD is hard, and I wanted to people to get a true sense of what TDD feels like and how it takes discipline to accomplish.  The idea for this was to have a workshop and as a group solve a problem using TDD.  I think the the knowledge transfer was good and people saw what TDD really is.  The downside was getting people to get out of their seats and code.  The idea was to have a person write a failing test, then someone else write the code to make it pass.  Out of a very good crowd of about 30, only about 7 were willing to interact which was somewhat disappointing.  I think the idea of an interactive workshop is still a good one, however, as someone suggested, I would structure it quite differently, possibly keeping someone at the computer for a few minutes at a time.

Conclusion

Overall the day was awesome and I look forward to the next.  If you have access to a code camp they really are a great way to learn.  Imagine trying to learn something new and having someone right there begging you to ask them a question.  I look forward to the next Iowa Code Camp, which will be next spring.  Leading four sessions was a lot but come May I will probably be pushing myself to present again as much, ever hoping to help someone be better than they were the day before.

I want to invite any of you who are within a few hours of Des Moines, Iowa to attend the second Iowa Code Camp on November 8th.  The first Iowa Code Camp back in May was a huge success. From Derik's write-up:

Yesterdays event was awesome.  They had about 125-150 people show up for the first ever Code Camp in Iowa.  The venue could not have been any nicer and setup any better.

I will be giving one presentation on using RhinoMocks and one workshop on TDD.  Below are the abstracts.  If you have the chance, take part, and register today.

TDD: A Workshop in Driving Your Design with Tests

If you've heard about Test Driven Development (TDD) and wondered what it was or how to do it, then this workshop is for you.  We'll take a practical, introductory approach to getting started with TDD.  We'll introduce fundamental object-oriented design principles including separation of concerns, dependency injection/inversion, and more.  This will be a hands on lab, so bring your laptops and a copy of Visual Studio 2008 and expect to learn.

Easing your Testing With RhinoMocks

When learning about testing you'll see trivial examples illustrating how to write tests. However most production code is non-trivial, making calls to configuration files or to a database which makes testing in isolation hard.  The use of mock objects allows you to isolate code you want to test by providing fake objects to your methods, allowing you to set up complex scenarios to test specific conditions.  In this session we'll first dig into some code that is not very testable and refactor it to make it more testable.  After the refactoring we'll use and explore RhinoMocks to see how we can test different scenarios in our code and verify our code is working as it should.