Friction on new projects

As the last post mentioned, I have been involved in a new project at work so it has been a good opportunity to introduce the team to some new concepts and investigate a few things my self.

Firstly the good:

• The last post mentioned that I have cleaned up the way we do stuff in terms of "code on the page". Its always good to be able to clean up coding standards
• introduction of IoC using Structure Map. I choose SM as I felt it was one of the most user friendly for those un familiar to IoC. I have used the Castle a fair bit however, what is good for me is not necessarily best for the team.
• Introduction of Rhino Mocks. Even though at work we are still .Net 3.0 Rhino Mocks we felt was a good choice over NMock2 as it has more fwd compatibility and the strong type of the delegates is well received (I hate strings)
• A much more refined user friendly architecture and overall structure

The Bad

The Friction on TFS, MSTest and MSBuild has been, to be honest, amazing. If the same project was using SVN, Nant and (N/Mb/x)Unit the CI would have been trivial, 30mins if all went well and maybe a couple of hours if things got a bit hairy. Not so with this nasty little threesome. TFS in itself is pretty good at combining check-ins with bugs/tasks and it has a nice interface. However the price tags and the pain in the ass it becomes when anything else needs to be done is just silly. MSTest, well does any one like it? As for MSBuild, well I don't mind it, I just prefer Nant as my main build script

So if you are going to go Greenfield be sure to check out what you need to do to get the whole system up and running. Unfortunately the powers that be a petrified of any OSS entering the realm of their MS world... I should probably keep quiet that the ORM, IoC, AOP, Logger and who knows what else all fall in to the banished category...

So this week I guess I will have the fun of putting my fingers in to all of this mess. I am not really sure where to start.. CI Factory? Until then we just have a continuous compiler

Cleaning up bad NHibernate/DDD practices

I have of late managed to be involved in a new green-fields project at work. I am sure everyone can relate to the elation you get when you have the opportunity to work on something new an "do it properly this time". I have had the privilege of being able to set everything up how I wanted. Not being a complete ass I have tried to get the team involved as much as possible and explain why/how I am doing things along the way. I think the thing I have found most enjoyable is setting up the means to creating a decent domain.

For the first time we have

• A clear delineation between value types and entities
• real value types
• generic repositories that only allow entities*
• protected empty constructors on all entities forcing you to construct the entity with the more public greedy constructor that actually puts the entity in a valid state
• Corrected sub classing of entities when behaviour is different for different types
• Non insertable type field on subclasses (that match the discriminator column) so the guys can still query "the old way"**
• Protected setters by default
• DBC that matches our DB & business constraints, down to the setter level
• A serious drive to push DOMAIN logic in to the DOMAIN objects
• Specifications

This is all pretty basic but these key aspect were not in our last big project. It may sound like having one repository per aggregate root would be a hard thing, but to be honest its a good thing and the headaches it could have saved my on the last project; NHibernate issues (transient state/dif object same id etc) and more importantly undetected business rule errors in the code.

What I am really hoping is that now the the hard work has been done that the team can more clearly see why we do things in the way we do them.

*I need buy in from the team on the whole Entity/Value type thing before dropping the Aggregate Root bomb shell

**Again this is perhaps not the best way to do it, but I feel for the moment its the best way for the team, while moving in the right direction

Ruby continues its war path

Ruby is now supported in VS thanks to the guys at SapphireSteel Software

More info:
http://www.infoq.com/news/2008/10/rubyinsteel-personal

So now i can have Python and Ruby from VS.... nice.

MSTest == Fail

I know i have already blogged about my dislike of MSTest, but this POC is really getting to me. The amount of hoops you have to jump thru to get it working in anything other than VS is just beyond me. I am seriously thinking of pulling my team over to MbUnit because this is getting out of hand.

• Its slow
• Requires Visual Studio. This makes it pretty dirty when setting up build servers. So now our build server has an instance of VS on it... well done M$, you just got an extra license becuase you suck.
  
• Poor integration with MS build; M$ own build script language. Why the hell does this not have native MSTest tasks? Hel go one step futher and make a pluggable interface so any test framework can be directly integrated.
  
• Using config settings just doesnt work. MS in all there wisdom decide to exclude files from the build dir that you have explicitly said to include. Well done morons. No i have to put dirty hacks in my tests to pick up 3rd party config settings.
  

Compare this with MbUnit. Um... there are no issues, well none that i have come across. Its fast, it integrates well, it has no wired application requirements...I just dont understand how one of the biggest software munfacturers in the world can balls this up so bad. The fact that the software is for developers just means any mistake will be amplified, you think they would make it better than anything under the sun... jeez they even had JUnit, NUnit, MbUnit (and many more) to copy from. You would think a product that you are paying for would at least be as good as the free alternatives.
My disappointment continues.

Book, Book And Books

I have decided to throw up a list of books I have read over the last year on my website. Up until .Net 3.0 I never really read a lot of tech books, the Google machine answered most of my questions. On the pending release of .Net 3.0 I realised that the web was not going to offer me the answers i wanted and the head start i needed, so i got closer to the source. I grabbed a few of the books and realised the benefit of actually reading up on info BEFORE you needed it.

My usual reason for reading articles, blogs etc was because I had a problem and need to get around it. To be honest that's a pretty bad way to approach your profession. A doctor doesn't go and read a heart surgery blog when he has accidentally torn the bicuspid... well i hope not.

Another push toward my now ever growing library was Alt.Net Seattle earlier this year. Sometime you just don't know how much you don't know. Meeting guys like Martin Fowler, Brad Abrams, Udi Dahan, Greg Young, Ayende etc and talking with them face to face, you soon get a reality check. Luckily I was not the only on there that felt this way.

A few of us (and i don't want to drag these guys down to my level) started interrogating the Big Guns on what we need to do to get to the next level. Now we are not schmuck devs, but we realised the way to get up to the next level is some structured learning. The likes of Dru Sellars, Greg Young, Ian Cooper, Udi Dahan and Jarrod Ferguson were incredibly helpful in passing on there recommendations.

Since then I have stepped up my reading of about 1-2 books a year to almost 20 since late April, that's just shy of a book a week! I feel like a sponge, sucking up everything I can get my hands on.
The improvement is the quality of code has improved, my ability to acknowledge that MY code may need to be refactored is now apparent. My TDD skills are far superior to the start of the year. DDD is something I actually understand and can implement (whether i do it well is up for debate). Because of my improve domains Service Orientated Architectures are easier to create and evolve. My awareness that as a senior/lead Dev coding is only one of the small areas of my job. The ability to release good quality, testable, stable applications and do it fast are all thing we must manage.
The only problem is what the hell do I do with all these books? Being the travelling man I am, I now have dozens of kilos of books that i can not (cost effectively) take with me back to Australia. Damn, because many of these are books you want to keep around the office or at least easily accessible at home.
Anyway the page is not up yet but it should be under http://www.fullstack.co.uk/articles/library.aspx soon. Check it out. I am only going to put up books i think are worthwhile reading, so if its on there go buy the book.

.Net and cloud computing

Looks like Windows (and therfore .Net sans Mono) and MS-SQL will be availiable soon on the amazon cloud:
http://www.infoq.com/news/2008/10/EC2-Windows

Loose coupling: The Illusion

I must say I totally agree with the sentiment Jeremy has here. Loose coupling is an illusion to most of the projects have worked on. The project I current work on has the client UI in a distributed system knowing that we use NHibernate as our ORM. Unbelievable. Needless to saying Unit testing this solution is VERY hard! To me, this is the first place where loose couping rears its head. If you can not unit test a class due to concrete dependencies rearing their ugly head, then its either

• Deal with the fact that you are not, in fact, loosely coupled or
  
• Fix it.

As mention in Jeremy's post having separate assemblies is not loose coupling. At best this forces a direction of flow of control, at worst it hides circular references or creates the illusion of loose coupling. Jeremy doesn't break his solution down to quite the project granularity I do and nor do others (JP Boodhoo for example is know to have very few projects in a solution). The notion is that you are not trying to hide behind the perception of more assemblies == less coupling. You can also separate the single project into multiple assemblies in your build scripts if required. It then becomes a gentleman's agreement amongst the team that coupling rules will be adhered too. Now this is much easier to police with a tool like NDepend.

Currently I am without NDepend so I still break up my solution to multiple projects, for a couple of reasons. I like to be able to visually see what is going on quickly and I like the default name spacing that is then applied (Sure this can be done with folders too). Probably the aspect I like most however is that i can see what reference what at any given time by checking the references (again, we don't have NDepend on this project). By opening the UI project I can now see that Data Access references are made, or there are WCF references in a Data access project. Without NDepend this is my last resort to policing the silly things that go on in the current (and no doubt futures) project.

With NDepend I would certainly be moving toward smaller projects. *Thinking out loud* I think a common assembly for server side (with my default and abstract data access/repository stuff) a server side assembly and a client side assembly. It kinda makes sense. If none of that server side stuff will ever be accessed by an other application or assembly then why break it up? Hmmm...

Anyway, on the path to loose(r) coupling consider a couple of things:

• Are you using a Test first approach. Although it is not necessary it tends to flush out dependencies early on
• Are you using a means of Dependency injection? If you are new'ing up dependencies in line then you have just tightly coupled yourself to an implementations. Check out this for a start on DI including poor mans DI, which is still infinitely better than no DI, IMO
• Code to interfaces not implementations. I always thought this was a pretty obvious statement, but apparently not. Your DEPENDENCIES should be interfaces. Anything you interact with in terms of Actions (ie methods or delegates/events) should ideally be via the interface. I very rarely see a point of having DTO's implement an interface...
• Stream line code that interacts with the unmockable (file system, DB, WCF/Windows services etc) ; it should be as thin as possible. Try to get your working code out of these classes. This is more of a testing issue, but will also lead to better design.
• Get NDepend. It is a kick ass tool that i wish my boss would get for me :(
• Code reviews. Get out of trouble at the first sign, its very hard to "loosen up" an app once the tight coupling has set in.

Loose coupling is a design goal we should strive for but I believe it deserves a bit more than just lip service. Get the team on board an explain the benefits. The earlier this begins in the project timeline, obviously, the better