Today I tossed the idea of a developer book club out to the rest of my team.  They all seemed to be on board with varying degrees of enthusiasm.  I know that we won't be the first to try this and so I'm hoping some of you out there can share some stories/ideas of what worked for your team.

The goals are three-fold:

• Team/community building
• Common knowledge
• Knowledge building/sharing

Specifically I'm looking for three things:

• What books would be on your short list?  Which book should we start with?
• What works well to keep people excited/enthusiastic?
• What are the things we should absolutely stay away from, whether they be specific books or implementation details?

So let me have it, what advice can you share?  What can we do to make our book club a success?

Shhh...don't tell anyone but we don't unit test all of our code.  We're striving to get all developers and managers on board with unit testing but we're not there yet.  Despite our delinquency in writing tests one thing we do try our very best to do is keep mistakes from happening again.  If we find a bug in the system, before fixing it, we go and write a unit test for that problem.  We verify the test fails, the go and write the code that fixes it.  This recognizes that bugs will appear in the system, but once fixed we'll insulate ourselves from that bug happening again.

We had one such case last week.  We were getting a yellow-screen error after a bunch of commits by developers.  The error stemmed from a component in Windsor that did not have all of it's dependencies met.  In other words, we registered a component which relied on another component which was not registered.  We already had written a test to compile and test our Windsor configuration, however that test was not mature enough and needed some tweaking. 

In our application we leverage the new ASP.Net MVC.  We also take advantage of the ability to leverage an IoC container, Windsor, to create controller instances when a web request comes in.  When the application starts, we register all of the controllers in the application into Windsor using reflection.  Therefore our Windsor configuration at runtime is made up of two things, the XML configuration and the controllers which are registered on startup.  The "bug" here was that one of our controllers had a dependency on it that was not registered in Windsor.  When you ran the test by itself, the test would pass, since it was only loading up the components from the Windsor configuration.

Wanting to protect us in the future, we acknowledged there was something missing from our test and set out to find it.  To create the failing test was relatively simple.  All that we needed to do replicate in our test what we were doing at runtime.  Therefore we needed to register all implementers of IController, just like we do on application startup.  Below I've

Before:

   1: IWindsorContainer container = new WindsorContainer("windsor.config.xml");

   2:  

   3: foreach (var handler in container.Kernel.GetAssignableHandlers(typeof(object)))

   4: {

   5:     Console.WriteLine("{0}\n\t- {1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);

   6:     container.Resolve(handler.ComponentModel.Service);

   7: }

After:

   1: IWindsorContainer container = new WindsorContainer("windsor.config.xml");

   2:  

   3: var assm = new HomeController(null).GetType().Assembly;

   4: //add all controllers

   5: foreach (Type type in assm.GetTypes())

   6: {

   7:     if (typeof(IController).IsAssignableFrom(type) && !type.IsAbstract)

   8:     {

   9:         container.AddComponent(type.Name.ToLower(), type);

  10:     }

  11: }

  12:  

  13: foreach (var handler in container.Kernel.GetAssignableHandlers(typeof(object)))

  14: {

  15:     Console.WriteLine("{0}\n\t- {1}", handler.ComponentModel.Service, handler.ComponentModel.Implementation);

  16:     container.Resolve(handler.ComponentModel.Service);

  17: }

Now that this test is in place, I am much more confident that we won't see the error we were seeing in product again, we've got a test which warns us if something isn't quite right.  Our initial test didn't quite get it all right.  Mistakes/bugs in code will happen, hopefully few and far between, but when a bug does show up, go write a test that verifies the bug before going off an fixing it.  Then make the test pass, which should fix the bug.

I don't typically link blog and I do my best to write substantive original material, but the following is too good to pass up.  It's how I feel and how I've approach work in the last year or so.  From Ayende's Reducing The Cost Of Change blog post this morning:

That mindset, at least for me, starts from the first line of code. I treat each piece of the project as utterly disposable. Since I don't really care how each individual piece works, I am able to roughly sketch a fair amount of the application very rapidly, and then focus on each of the items in isolation, and replace that with a much better implementation. I think that I stated before that I tend to rewrite most of my application core at least two or three times before I am happy with them.

When you have disposable pieces, it is no big deal if you mess up and need to start over, because the whole project is structured in a way that allows you to do so. Going back to using my current project as an example, the algorithm used for the core part of the system is crap. I thought it up while being on a coffee break, and it is enough to demonstrate what the software is supposed to be doing. I don't really care, because the moment that I do need the real algorithm, I can drop it in (need to change the implementation of a single method).

I can't improve on that, so I won't try.

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 understand floating point numbers can be somewhat imprecise but I'm a bit bothered today when I see the following evaluates to false:

   1: float f = .16f;

   2: double d = .16d;

   3:  

   4: Assert.That(f, Is.EqualTo(d))

Annoyingly I wanted to see what the two values are:

   1: Console.WriteLine((double)f)

   2: Console.WriteLine(d);

produces the following respectively:

.159999996423721

.16

What bothers me about this, and I'm hoping someone can eloquently explain this, the MSDN docs say this should be implicitly converted.  From the MSDN doc article on implicit numeric conversions:

• From float to double.

Float is 32-bit and double is 64-bit, so why can't the float fit nicely inside the address space for the double?

Hell, if you're not going to respect the integrity of the number what's the point of the implicit conversion?

This past weekend I attended the Continuous Improvement in Software Development Conference in Austin, Texas.  This conference brought together many brilliant minds in the .NET community for the expressed purpose of continuous improvement.  The conference was very good, but some of the best chances for learning happened outside the conference sessions at dinner or sitting around a table at the hotel bar.  One such discussion seemed to point out one problem we have in our community, minutiae.

I will preface the remainder of this post by saying I tend to be a purist at times and must always remind myself what the ultimate goal is.  Acknowledging my tunnel vision, sometimes purists, can miss the point if we're not careful.  One evening a few of us got on the discussion of test-driven development.  Someone at the table used the phrase test-first development in the conversation.  That person was quickly halted by others at the table because the terms, in their opinion are quite different and should not be used interchangeably.  If I were to ask you define both, could you adequately define the difference?  Should you be able to?  Does it really matter?

I would say that for the development community out there that the differences, if in fact they do exist, don't matter.  A quick and informal poll revealed that 8 of 10 developers I know aren't unit testing at all.  I readily admit that my sampling is probably an inaccurate representation of the total developer population.  I don't think though that my sample poll is off by an enormous amount.  Think of the developers you know; are they testing at all?  I'm not talking TDD, but plain old unit tests?  Chances are good that you know a few that aren't testing at all.  Are they served by the bantering back and forth about differences between TDD and TFD?  Absolutely not.

The important thing to remember is that fundamentally the TDD and the TFD practitioner believe the same thing, that is, you need to be testing your code. They may disagree about small things, but those small things should take a back seat to the fundamentals.  We don't have to look far to see another example of this type of behavior.  Think of two Christian denominations, both of which are trying to convert nonbelievers to Christianity, bickering among themselves about whether children should be baptized or not.  The debate becomes so ardent, that neither camp accomplishes their original goal or converting nonbelievers because they're too focused on each other.  I fear the same outcome will befall those of us preaching testing.  We get so religious about the non-essential aspects of testing that we miss the people we intended to target, the people who aren't testing their code at all.

I think we could all take a page from St. Augustine who had it right over 1600 years ago: "In essentials, unity; in non-essentials, liberty; in all things, charity."

Yesterday was the first day of the pre-conference workshops at the Kaizen Continuous Improvement Conference.  Day two was a bit more invigorating for me since I attended two topics (Opinionated MVC and Fluent API's with C#) which got my head spinning nearly immediately.  Both talks were very good and rather than writing my own thoughts on the subject I'll defer to Derik Whittaker and his thoughts on the day.

I'm in Austin, Texas for the Kaizen Continuous Improvement Conference this weekend.  One of the very cool things the organizers did for this event was offer two days of workshops before the conference.  While I'm excited for the conference itself, much of my excitement for the conference stemmed from these pre-conference workshops.  Yesterday I went to two workshops, both of which should be online at some point.

Advanced NHibernate - with Ayende Rahien

I was a little leery of this one given our seemingly trivial usage of NHibernate.  I was pleasantly surprised to see how much of this was perfectly timed for where we are at.  Oren went into great detail on various parts of the NHibernate and it's contributing projects.  He spoke a bit on caching and performance optimizations/pitfalls that you generally have to watch out for.  Quite possibly the coolest feature was getting to see NHibernate profiling application that Oren is working on.  This won't be a free tool but the price from what I've heard from Oren will be very reasonable (I am not saying the price since it may change).  With NHProfiler you can see all the queries that get executed from you application.  It even has alerts built in, such that if it detects a problem (ie. Select N+1) it will let you know.  Without hesitation, if you're using NHibernate, buy NHProfiler when it comes out, it is easily worth it.

The most important concept that I got from this session is how powerful NHibernate is.  People can fight ORM, roll their own solution, or write their own T-SQL but when you see what NHibernate has to offer it seems ridiculous to choose any of those options.  Two little known NHibernate features you may not have known about that I've found very cool:

• NHibernate Search : Leverages the open source Lucene.NET implementation and keeps allows you to do search which have performed poorly in the database against a very fast Lucene index.
• NHibernate Shards : Written by Google this allows you to scale across a number of databases. I won't delve into sharding here but you can read up on it on wikipedia.

DDD Chalk Talk - David Laribee

I was very interested in this chalk talk since the name seemed to indicate we'd get a chance to have an open discussion about DDD and how one would approach DDD in their domain.  This talk seemed to have peaks and valleys.  It was no fault of anyone in the talk, but DDD seems to be one of those topics where it becomes extremely tough to follow once you get outside of what you know.  The topic of aggregate roots and contexts were quite helpful.  I found it encouraging that ideas that I have interpreted from the book seem in line with what David Laribee demonstrated on the white board.  I'm only a few chapters into the book and am absorbing as much of the DDD concepts from those who are ahead of me on this path.  I'm encouraged to see where others have taken it, the value they have found in it, and what it could mean for our application(s) in the future.  Just have to keep reading and learning.

Quite a lot for only the first day of a multi-day conference.  For those of you who aren't here in Austin but wish you were, keep an eye out for videos of the many presentations that my pop up.  I will update this blog if/when I see them appear online.  There was a lot of good content coming out of these workshops and it'd be a shame to have the content limited only to those in attendance.

Last week I posted the first in a series on Mass Transit, an open source enterprise messaging system.  This series is my public exploration into messaging for our eCommerce application.  In this post I'm going to dig in to see an actual working example.  I like to see something work, then dig in to figure out how it's all put together.  We'll take a look at a simple publish subscribe example to see the messaging in action.  In later posts we'll dig in deeper into the guts of MassTransit.  That said, let's see some MassTransit in action!

Getting Started

I've downloaded the MassTransit source from the Google Code repository and am going to run one of the samples provided with the source.  We'll look at their "PublishSubscribe" sample.

Project Structure

Opening the solution reveals nine projects, a few more than what I would consider a simple sample, however don't let the solution scare you away.  It turns out that you can for the most part ignore five of the projects, the mass transit infrastructure projects.

There are four parts to this solution that are relevant and we'll focus on those:

• Client - The client represents the application that wishes to leverage messaging.  It plays the role of publisher in this example.  It is worth noting however that in this example, as we'll see, this project is also a subscriber.
• Security Messages - This is a pretty simple project as it should be.  This project encapsulates the strongly typed messages that will be passed throughout the system.  By having the messages in their own light-weight assembly we can keep our messages separate for their consumers.
• Server - This project acts as the subscriber.  In a normal scenario this server may be sending out emails or logging particularly interesting things as messages come through or whatever else you may have a need for.  Like the client project, we'll see that this project also plays dual roles, the subscriber as mentioned and also a publisher.
• SubMgr - The subscription manager, is quite a mystery to me.  It may not be obvious, but the subscription manager is needed to get everything to work.  As Dru explains it to me, it is the glue.  In my first go around with MassTransit, I created a client and server and was frustrated when nothing was working.  Talking with Dru, he quickly pointed out my error, I had no Subscription manager.  In the following posts I hope to clear up some of the mystery for myself around the subscription manager.  My understanding at this point of the subscription manager, which may be a bit simplistic, is that it pushes the messages to each of the queues which are interested in the message.  A publisher publishes a message, the subscription manager is the one that ensures that it ends up in the appropriate queue(s) for consumption by various subscribers.

Getting Setup

In order to get this sample going you first have to create the MSMQ queues that this sample expects:

• mt_client
• mt_pubsub
• mt_server

You can create these queues in the Message Queuing area of the Services and Applications snap-in in the computer management area on your computer.

Seeing Is Believing

Now that we've got the project set up let's fire it up and see what we get.  Since we need all three applications running at once, the client, server, and subscription manager we can take advantage of a cool feature in Visual Studio, multi-project startup.

With multi-project startup you start any number of projects in your solution.  From the properties dialog for the solution we can choose which projects we want to kick off.  (It is worth noting the order in which I have these projects launching.)

What's Going On

When you run this example, the client application will ask you to enter a new password.  When you type in a new password  you will get a nearly instantaneous response letting you know the password was updated.

The thing to bear in mind here is that at the point you hit the <enter> key submitting your new password, the client publishes a message and then it is done.  It appears instantaneous but you'll want to keep in mind that it is asynchronous.

The Flow Of It All

The diagram to the right illustrates what is going on once you hit the <enter> key.

1. The client publishes a RequestPasswordUpdate message (see the Security Messages project in the solution for this message object).
2. The server in this case consumes the RequestPasswordUpdate message.  When it is notified of the message, it logs the new password, then...
3. The Server publishes a new PasswordUpdateComplete message.
4. The client consumes the PasswordUpdateComplete message and in so doing writes to the console that the password update is complete.

It is worth noting here that the client knows nothing of the server and the server knows nothing of the client.  Our example could easily expand to have multiple clients (think for example a windows app or multiple web servers in a farm).  Likewise there could be multiple server instance, each consuming different messages.  In other words, we are very loosely coupled, which is a good thing.

Conclusion

I hope this introduction to the MassTransit was beneficial.  Now that we've seen the example working, in the next post I'll revisit the idea of durability.  We'll augment this example and simulate a breakdown in infrastructure and see what durability really means, which is really at the heart of this fantastic open source library.