Jonathan Oliver

I spent the better part of a day trying to get Gallio's runner to execute NCover and run our unit and integration tests as part of our build process. Our build server and all of our developer workstations run some variant of 64-bit Windows, e.g. Vista, 2008, 7, 2008 R2, etc. At the command line, I would type the following: Gallio.Echo.exe /runner:NCover PathToTestAssemblyMyApp.UnitTests.dll Everything worked great except for NCover. NCover.Console.exe would stall and timeout after 60 seconds and then die saying " »

You gotta love NHibernate. But sometimes there are little quirks the drive you nuts—at least until you understand how NHibernate handles things. We ran into one such "hiccup" the other day. Our objective was to have a parent object contain a list of child objects. Simple enough. Problem is, we didn't want the child to know about or have a reference back to the parent. But all of the simple example code that we found for NHibernate and Fluent NHibernate kept showing the bidirectional reference. »

We've been using Git for a little while now in a Windows environment and we have been quite pleased with it and the capabilities it affords us as part with its decentralized workflow. We have a number of shared projects or "common libraries" that we use between projects. Because of this, we are using Git's submodules feature. One small issue that we hit was when we would make changes to the code to the project in a submodule (for example, some scripting code in a submodule), we would want to commit and push those changes. »

I try to avoid the debugger at all costs, but it does come in handy sometimes. You'll even catch Uncle Bob in the debugger on occasion. When using a compiled language, you basically "lose" the source code once compiled. Of course bytecode languages can be decompiled, but that's beside the point. We have a number of common library projects that we share between our applications. Usually these common projects are very low-level infrastructure concerns, etc. »

Mark Needham posted on his blog a link to this article which I hadn't read before. It's a really good read about the logic behind write-only storage: http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx »

I've been involved in a few projects recently that didn't get into DDD much, so I've been out of the loop for a few months. As I was getting back into things, I had a question regarding what was stored in the "event store" for a bounded context—events, commands, or both? The reason for this is critical, because replaying of events vs. commands has some broad implications related to side effects, recalculation of values, keeping the context of the original operation, etc. »

In a previous post, I detailed all of the reasons why processing messages one by one with an aggregate root was a good thing. I am now going to contradict some of the main points in that post. While certain aspects still hold true, there is a much larger matter involved. First, the points that I still consider to be valid: Don't have threading logic in your aggregate roots. Don't do things with locks, monitors, mutexes, etc. »

I watched the battle from the sidelines where Jimmy Bogard talked about how not to do "poor man's dependency injection". Then Tim Barcz gave his input. Then Chad Myers got into the mix. Considering this blog is called Inversion of Control Freak, I should probably add my $.02 now that things have settled down. I've gone back and forth on this issue where I really want to allow flexible wire-up of my components using the IoC container of choice, but at the same time, I'd like to have the ability to just skip the wire-up and have a default, ready-to-go implementation. »

As I look back at applications and systems that I have been involved with over the years, what strikes me is how data-centric those applications were. In fact, the driving force behind most of those applications was the data. The behavior of an application was looked at as merely if statements and for loops. It was inconsequential. The other thing that strikes me about all of these applications is that, because they were all about the data, they were incredibly dumb. »

While fixing a few bugs in some legacy code that had no tests didn't follow DDD principles, I had an epiphany. Well, maybe I shouldn't say it that way. I had a few concepts reinforced in my mind regarding the importance of state-based testing, specifically using Behavior-Driven Design techniques. The problems I had were related to business concepts, such as renewing a customer's subscription. Other than the bugs that I fixed, the main problem with the code was that it didn't follow DDD principles. »