Here is my take it. I’m putting it here so I can find easily find it again. Basically it’s the same, but I’m using a lambda to create my anonymous delegate:

[Test]
public void UnitTestNodeChanged()
{
 var receivedEvents = new List<XmlNodeChangedEventArgs>();
 var document = new XmlDocument();

 document.NodeChanged += ((sender, e) => receivedEvents.Add(e));
 document.Load("C:\file.xml");

 Assert.That(receivedEvents.Count, Is.EqualTo(1));
}

Nice and short, and to the point. We can test the fact that the event was raised (or not); how many times the event was raised; and, we can test the event arguments.

I like it. Some people may not, but it suits my purposes.

Obviously I’ve had to test this out immediately.

That was about 18 months ago, I’ve learned a lot since then and I think that it is high time to take a look back at the code and see if I can spot if there is any room for improvement.

The current project

Current structure

Let’s have a look at how I structured the project when I set it up. The first thing that you will notice, is that I messed up the package names. It should be “uk.co”, and not “co.uk”, according to the Java language specification. A minor point, and not really a big deal, we can easily sort it out.

Something else I did, was lump everything together into the same project and package – the runner program, the utils (e.g. helper classes that you write as you progress through problems), resources and the problems themselves.

I don’t think that this was necessarily a bad idea at the time, I don’t think that it is inherintly a bad idea now, it’s logical for everything to share the same package. Or should I say, it was logical for everything to share the same package.

I am going to put the code for the problem runner onto Github, but I don’t want to share the answers to the problems. To answer your question, I think that it goes against the point of Project Euler, that of having a set of problems that the inquisitive person can solve with some math and programming. I have also found that the problems also help in getting comfortable with the syntax of a new programming language – after all the solutions to the problems remain the same, however the implementation is subtley different depending on the language being used.

Re-Design

Examining the current code and design, we can immediately identify some changes which we are going to make  I’m going to seperate the uk.co.temporalcohesion.euler package into three packages, which are more distinct from each other, but still keep them all in the same project. Why? Well, it is obvious that there are three tasks which we have to manage:

1. Running problems.
2. Provide an API to run the problems.
3. Store the problems somewhere

To shed some light on my thinking here, lets examine these in more detail. This will also identify areas of possible improvement in the design.

1. I want someway of consistenly running a problem (or group of problems) to test the solution(s) to (a) Project Euler problem(s). This is basically our console runner application, which doesn’t have to know exactly how this happens, it recieves input, and returns output – how that output is generated is irrelevant to it.

2. I want an easy to use API which I can leverage to easily implement the solution to a Project Euler problem, so that I don’t have to worry about re-writing all the input/output code over and over again. I also want to be able to share this API, without sharing the answers to the problems themselves.

3. I need to have somewhere I can put the answers to the problems, and associated helper classes (Prime number generators, etc) which I can easly backup, and easily run the problems from.

These are sounding a bit like user stories, and I suppose they are. They can be formalised as so:

As a Problem Solver, I want to run the solution, or group of solutions, to a Project Euler problem.

As a problem solver, I want to concentrate implementing the solution to a euler problem, not on implementing input/output for the problem.

As a problem solver, I want a place to develop and store the problems, from which I can run the problems to test the solution.

Fairly concise and simple requirements, which we will revisit later. We still have to examine the code in a little more detail so that we can identify exactly what it is we are going to refactor.

Code review

The main class to examine is Euler, in Euler.java.  The first to say without even looking at the code, is that the name is fairly awful. Then when we examine the code in more detail, we can see the name is even worse. The class has the main entry point for the program, as well as all the code to actually run the problems. This class is doing everything, there is definately no Seperation of Concerns. It is responsible for accepting user input, loading and running the problems and displaying the output. Wow.

The class is designed around the Command Pattern, and it has worked quite well. Looking at it now, a further two patterns could be used, namely Strategy and Template method.I’m still in two minds about refactoring the design pattern in use, but that discussion can be put off for the time being, as I have other things to concern me.

There are 144 SLoC, not a massive amount, but when you consider the above and what the class should be doing, then it is clearly a bit weighty. There are 7 functions in total, not counting the constructor, not a massive count, but as the SLoC count indicates, some of those functions are a bit long. The worst offender is the following method.

private void loadClasses() {
 InputStream fis = null;

 Properties p = new Properties();

 try {
 fis = ClassLoader
 .getSystemResourceAsStream("co/uk/temporalcohesion/euler/resources/problems.properties");
 p.load(fis);

 Enumeration<?> e = p.propertyNames();
 while (e.hasMoreElements()) {
 String key = (String) e.nextElement();
 String value = (String) p.getProperty(key);

 Object o = Class.forName(value).newInstance();
 if( ( o != null) && (o instanceof Problem)){
 Problem problem = (Problem)o;
 problems.put(Integer.parseInt(key), problem);
 }
 }
 }

 catch (FileNotFoundException e) {
 e.printStackTrace();
 } catch (IOException e) {
 e.printStackTrace();
 } catch (ClassNotFoundException e) {
 e.printStackTrace();
 } catch (InstantiationException e) {
 e.printStackTrace();
 } catch (IllegalAccessException e) {
 e.printStackTrace();
 } catch (ClassCastException e) {

 }
 finally {
 try {
 fis.close();
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
 }

Wow, that’s a lot of code for something which is relatively straightforward. It’s not exactly easy to read, and it violoates the Single Responsibility Principle: by loading in and enumerating over a properties file, instantiating new instances of problem classes, and handling all the exceptions which can be thrown. There will definately be some room for improvement there.

Getting back to the main Euler class as a whole, there is an even worse problem…

There are no unit tests!

This is a disastrous situation, because it means I cannot refactor the class with any confidence. The me of 18 months ago has a lot to answer for. I’ve got a bit of work to do. Check back next time to see how I’ve progressed things.

]]> http://temporalcohesion.co.uk/2010/03/23/revisting-the-project-euler-problem-runner/feed/ 0 http://temporalcohesion.co.uk/2010/03/23/revisting-the-project-euler-problem-runner/ http://feedproxy.google.com/~r/co/temporalcohesion/~3/svOUKDmv6os/ http://temporalcohesion.co.uk/2010/03/17/even-more-on-the-generic-plugin-manager/#comments Wed, 17 Mar 2010 13:24:40 +0000 stuart http://temporalcohesion.co.uk/?p=180 I’ve written previously about writing your own generic plugin manager/framework.

I believe that this is a worthwhile exercise for the beginning programmer, because it firstly teaches you a lot about reflection, and secondly teaches you the advantages that proper use of interfaces can bring to your code. Thirdly it can also teach you to think about how your API might be used by someone else when they write a plugin for your program. In short I think it’s a great exercise.

While writing and using my own plugin framework has been a great learning experience for me, I’ve found that I have outgrown it’s usefulness to me. What made me see this was when I started to think about and begin implementing a way for me to use the framework as a IoC/Dependency Injection tool. This led me off on some Googling and I found Funq, and the the associated screencasts by Cazzulino.

This got me to thinking about DRY. Don’t Repeat Yourself can just as easily mean Don’t Repeat Work Other People Have Already Done (If You Don’t Have To), but DRWOPHADIYDHT doesn’t sound/look nice as an acronym. Perhaps a better way to express that sentiment is “lazyDRY”, or “The re-use of prexisting libraries and code can save you a lot of time, and which effort you can put into your application at a higher level.”

Or in other words, it is foolish to ignore the work that other people have done, unless you have a compelling reason to do so. If you really want to write your own IoC/DI container, then great, knock yourself out. No one is going to stop you.

I’m lazy though. Nanos gigantium humeris insidentes.

Depending on the blogs in your feed reader, or who you follow on Twitter, or just in general googling, you will probably come across references to the same group of IoC/DI containers. Chiefly:

• StructureMap
• Castle Windsor
• AutoFac
• Ninject
• MEF
• Unity
• Spring.net

There are others, but it would seem hardly anyone uses them. Of those above, I have so far only used StructureMap and Ninject, and have really liked using both of them. I will try out the others at some point, but so far I’ve liked what I’ve seen in StructureMap and Ninject, I honestly don’t think that any of the others will have anything better to offer me. Besides which, StructureMap has a built in method of using it as a plugin framework. Win.

In Conclusion

What can I draw from all this? I don’t think that I wasted any of my time or effort in writing my own plugin framework. It was a worthwhile exercise which taught me a lot of things, and I urge you to do the same.

You will have seen, heard and read the buzz about the Apple iPad. What it is, what it does and why you should buy it. This post is not about all that – it’s covered in excruciating detail elsewhere on your favourite tech site. Ever since the iPad was just a rumour, and since it was officially announced, we have been arguing about it at work. Whose going to buy one? Who is an idiot for wanting to buy one? Who is an idiot for not wanting to buy one?

Note: I should mention that I do happen to own an iPhone (via an O2 two year(!) contract), and I think it is probably the best mobile phone I’ve ever owned, however, I will take some convincing to enter into another two year contract again. But I digress. I have a couple of old iPods, nothing else: I am not a fanboy.

The niche that the iPad and devices like it fill is undoubtedly there, or else these products would not be developed. The key thing here is “…and devices like it…”. There isn’t just the iPad to consider.  This is the fantastic thing about our society: we have a huge freedom of choice in our purchasing decisions. We are free to evaluate, consider and weigh all the pros and cons of a particular product before we make the commitment to purchase.

Unless you are an Apple fanboy

In which case, you have already sub-concisiously made the decision to purchase anything with an Apple logo on. Are you an Apple fan boy? You have a Mac of some discription. You bought (and probably still have) a first-gen iPod. You bought an iTouch the day it was release. You were the first in your office to get an iPhone. You were the first to upgrade to an iPhone 3G. You were the first to upgrade to an iPhone 3GS. You hammer F5 on your favourite liveblog of an Apple event. You wouldn’t even consider buying a laptop from Asus, Acer or Dell (or whoever) which as powerful and costs half the price of something which has a fucking Apple logo on it.

Fanboy. Acolyte. Get out. You have already made your choice. You cannot win an arguement with someone who fanatically believes they are right.

Open minded? Continue from here

For those who are prepared to broaden our horizons, there is a bewildering array of choice just around the corner. Rather than rehash other people’s hard work from around the interweb, and because I’m lazy, I refer you to this article on About.com: http://portables.about.com/od/otherdevices/tp/Slate_tablet_roundup.htm, which offers a succinct highlight of varous slate tablet computers. Engadget also has some details of Microsofts offering, the ‘Courier’, which looks promising.

In Conclusion

You do not have to kneel at the alter of the cult of Apple. You have a choice. Use it wisely.

However, there are problems with this approach. Consider that you’ve changed several files, but then you realise that the changes you have made are not good enough, or just don’t work. With svn, or vss (*vomit*), you can undo-checkout to get the previous version back, with dropbox you can roll back to the previous version – one file at a time. There is no branching, no merging, no tagging. Nothing like a traditional SCM tool should have.

Dropbox is after all, essentially just a folder that is backed up “to the cloud”. If we use the right tool, we can take advantage of this properly.

Enter Git

What is Git? Well, surely you must have at least heard of Git by now? If not, I refer you to the wikipedia page about Git. Ok? You’re back?

The key aspect of Git which we can take advantage of is essentially the very nature of Git itself. Every Git clone is a full-repository, containing the full commit history and full revision tracking capability for the project, and it does not rely on network access nor a central server.

Basically, the idea is that you initialise an empty, bare repository inside your dropbox folder, and then somewhere else on your filesystem, perhaps a development folder where you store all your projects, you clone the repo from dropbox, and do all your work on that clone. Then when you call ‘git push origin master’, your changes are pushed into the dropbox repo, ready to be synced up on other computers you use.

Note: This is not a substitue for having a proper hosted Git repository, such as a project on Github, or somewhere else. However, it useful if you are working on something you aren’t ready to put into the public domain, or you haven’t yet decided to purchase an account on a private repository provider.

Setup

Setting it up is fairly simple, but, I am going to assume that you have Dropbox and a dropbox account, Git and (if you are on Windows) GitExtensions, correctly installed already.

Note: I have only tested this on Windows 7, but I wouldn’t expect it to not work on any other system. As always YMMV.

First, create a folder in your dropbox folder to house your projects, e.g. C:\Users\Stuart\Documents\My Dropbox\projects or just store it in the root of your Dropbox, it’s upto you. Don’t forget to include quotes around any path that has a space in, or else it won’t work.

Stuart@LAPTOP ~/Documents/My Dropbox/projects
$ mkdir example

Stuart@LAPTOP ~/Documents/My Dropbox/projects
$ cd example

Stuart@LAPTOP ~/Documents/My Dropboxprojects/example
$ mkdir .git

Stuart@LAPTOP ~/Documents/My Dropbox/projects/example
$ cd .git/

Stuart@LAPTOP ~/Documents/My Dropbox/projects/example/example.git
$ git init --bare
Initialized empty Git repository in c:/Users/Stuart/Documents/My Dropbox/projects/example
/example.git/

Then, in your development folder clone that repo.

Stuart@LAPTOP /c/development/examples
$ git clone -v "C:/Users/Stuart/Documents/My Dropbox/projects/example/.git"
Initialized empty Git repository in c:/development/examples/example/.git/

Stuart@LAPTOP /c/development/examples
$ cd example/

Stuart@LAPTOP /c/development/examples/example (master)
$ touch example.txt

Stuart@STUART-LAPTOP /c/development/examples/example (master)
$ git add example.txt

Stuart@LAPTOP /c/development/examples/example (master)
$ git commit -m "Added example file to initial commit"
[master e9ac78d] Added example file to initial commit
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 example.txt

Stuart@LAPTOP /c/development/examples/example (master)
$ git push origin master
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 253 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
To C:/Users/Stuart/Documents/My Dropbox/projects/example/.git
 1e38d4e..e9ac78d  master -> master

Dropbox will sync the files into the cloud. On your other computer, the git repo will sync, then you can clone it, and find that you have all your history for your project as you would expect.

I’ve written some more about what I’ve learned whilst working on my plugin manager here: http://temporalcohesion.co.uk/2010/03/17/even-more-on-the-generic-plugin-manager/

A few months ago I wrote about writing a generic plugin loader/manager in C#, where I offered links to several articles and referenced a rather excellent book about C# which I had used to base my plugin loader on. I hadn’t really given it much thought since then, but according to Google Analytic’s, it’s one of the most hit posts on my blog. Recently I had a request to release the source code.

Now when I first wrote that post, I was hesitant to include any code, and I still am – not because I think there is something new and unique with what I’ve done – but, rather that what I have written is not terribly difficult to write. I do not mean to sound snobbish or arrogant at all, I’m just telling you how it is, all I’ve done is to do a bit of reflection on assemblies in a folder, and load instances of certain interfaces.

Anyway…

The scenario is that you want to provide a way for for 3rd parties to be able to add additional functionality to your application at run time. We need to provide a common way for 3rd parties to be able to register their new functionality into our application, in order that the user can take advantage of the exciting new feature being added to the application.

Straight away, you should be thinking to yourself: Interface!

public interface IPlugin
 {
 /// <summary>
 /// Does what ever It is.
 /// </summary>
 void Do(Action it);
 }

Anyone who now wants to create a plugin for our application must implement our IPlugin interface, as it defines the contract to which our application is bound to, in order to recognise and load plugins. Thus any assembly, that has a class which implements IPlugin is considered by our application to be a plugin which is capable of offering additional functionality.

We can now attempt to load our plugins. We need to have a class which can scan a folder for assemblies, scan those assemblies for types which implement IPlugin, and then create instances of them which our application can use. Loading the assemblies is easy:

public class PluginLoader<T>
{
 private IList<T> pluginsList = new List<T>();
 ...
}

...

public virtual IList<T> LoadPlugins()
 {
 foreach (string file in Directory.GetFiles(this.pluginFolderPath, "*.dll", SearchOption.AllDirectories))
 {
 Assembly assembly = Assembly.LoadFile(file);
 this.LoadObjects(assembly);
 }

 return this.pluginsList;
 }

We create a generic class, so we can use it with any type of plugin, and not just ones which implement IPlugin, then it’s just simple directory recursion to load all the files in the specified folder which have a file extension of .dll. The real magic happens in the LoadObjects() method.

var types = from t in assembly.GetTypes()
 where t.IsClass &&
 (t.GetInterface(typeof(T).Name) != null)
 select t;

 foreach (Type t in types)
 {
 T plugin = (T)assembly.CreateInstance(t.FullName, true);
 this.pluginsList.Add(plugin);
 }

Using LINQ, we extract all the types from the assembly which are classes, which implement the interface which is a typeof(T) – T being the type we specified when we instantiated the class. You could just as easily here specify the type should inherit from some other type, and you could also check to see if a class has some assembly level attribute.

Why would you want to do that? Well, we can use an assembly level attribute to decorate the plugin class with meta-data about the plugin, such as the author, a short description, the name of the plugin, and it’s version.

public virtual KeyValuePair<string, List<KeyValuePair<string, string>>> GetPluginInformation(Type type)
 {
 var attributeInfo = from pa in type.GetCustomAttributes(false)
 where (pa.GetType() == typeof(PluginAttribute))
 select pa;

 foreach (PluginAttribute p in attributeInfo)
 {
 data.Add(new KeyValuePair<string, string>("Author", p.Author));
 data.Add(new KeyValuePair<string, string>("Description", p.Description));
 data.Add(new KeyValuePair<string, string>("Name", p.Name));
 name = p.Name;
 data.Add(new KeyValuePair<string, string>("Type", p.Type.ToString()));
 data.Add(new KeyValuePair<string, string>("Version", p.Version));
 }

 this.attributeInformation = new KeyValuePair<string, List<KeyValuePair<string, string>>>(name, data);

 return this.attributeInformation;
 }

Or you could create a struct to use as a DTO for the plugin meta-data, it’s up to you.

I’ve removed all the comments and exception handling from the code I’ve posted purely just to save space, you’d really want to include that – especially the exception handling. But that’s really all there is to it, you might want to have a property to access the actual plugin list, or return it from a LoadPlugins method, it’s up to you.

You’ll notice I’ve made the methods virtual, you may want to use this class as a base class in another class. For instance I’ve got an additional class which inherits from my plugin loader class which does specific tasks for a particular type of plugin, and another which does different tasks for a different type of plugin.

If you have not heard of it, psake is a”…build automation tool written in PowerShell”, started by James Kovacs. With it, you can write build scripts, with which you can automate the build and deployment of your .NET project. Recently the version 1.00 and 2.0 0 version were released. Why two versions? Well, the 1.00 version is primarily for PowerShell 1.0, but psake 1.00 is being “retired”. This article assumes the reader is using psake 2.01 and PowerShell 2.0.

A quick note here, I should point out the primary example I based my first build script on is Ayende Rahien’s build script for Rhino Mocks.

Our first psake build script

First, I have to make two assumptions:

1. I have to assume that you have PowerShell installed, if you are running Vista/Windows 7 then it’s installed by default, if you are on XP, then it is a manual install.
2. You have installed the psake module into Powershell – see the release announcement linked to above for details on how to do this.

Example solution

With those assumptions out of the way, we are going to write a build script to automate the building of a simple C# solution, containing a Windows Forms application, and two class library assemblies.

Hopefully this should be simple enough to easily follow along with what is happening in the build script, but complex enough that you can see how sophisticated your build scripts can be.

You can see that I have already taken the liberty of adding an extra file to the solution, “build.ps1″, this is our build script, with which we can command psake to do great things for us.

With our solution setup, we can now write our first build script:

properties {
 $base_dir = Resolve-Path .
 $sln_file = "$base_dir\WindowsFormsApplication.sln"
}

Task default -depends Compile

Task Compile {
 msbuild "$sln_file"
}

Open a command prompt into the directory containing the .sln file, which is where your build.ps1 script
should be, and run this command: invoke-psake .\build.ps1 -taskList Compile

psake Compile task output

You should receive some output to the console window like the above.What the script does is to work out where on the file system the script is running, and gets the path to that folder, and builds the path to the specified solution file, and runs msbuild, passing the full path to the solution file as a parameter.

The script as it is has some drawbacks though. In it’s current form, msbuild will only build the default configuration of the solution. What if we want to build a Debug version, or a Release version, or some other configuration we’ve created? Additionally, it doesn’t let us specify a directory to put the built binaries, they just get put in the default locations as specified in the projects contained in the solution – what if we want to put them in a custom location?

If we modify our build script slightly, we can introduce this functionality. Firstly, we need to specify some additional properties:

properties {
 $base_dir = Resolve-Path .
 $build_dir = "$base_dir\build"
 $sln_file = "$base_dir\WindowsFormsApplication.sln"
 $debug_dir = "$build_dir\Debug\\"
 $release_dir = "$build_dir\Release\\";
}

Notice the double backslash, msbuild requires a trailing slash when paths are specified, and it seems to require the additional backslash as well, or else it doesn’t work. With those additional properties in place, we can introduce two new tasks to our build script:

Task Clean {
 remove-item -force -recurse $debug_dir -ErrorAction SilentlyContinue
 remove-item -force -recurse $release_dir -ErrorAction SilentlyContinue
}

Task Init -depends Clean {
 new-item $debug_dir -itemType directory
 new-item $release_dir -itemType directory
}

Powershell’s easy to read syntax should make it easy to follow with what is happening now. In the Clean task, we forcefully and recursively remove any files and the folder from the specified path, and if there are any errors then they are not displayed. Now that we know that those folders are going to be cleaned and created, we can create two further tasks, where we can create Debug and Release versions of our solution:

Task Debug -depends Init {
 msbuild $sln_file "/nologo" "/t:Rebuild" "/p:Configuration=Debug" "/p:OutDir=""$debug_dir"""
}

Task Release -depends Init {
 msbuild $sln_file "/nologo" "/t:Rebuild" "/p:Configuration=Release" "/p:OutDir=""$release_dir"""

Again, the syntax here is relatively straightforward to follow along with, we execute msbuild, passing it the solution file to build, specify not to show the logo (suppressing the output of “copyright microsoft msbuild etc), tell it to execute the rebuild target and to build the Debug configuration, copying the output to the specified debug directory. Notice that that there are no spaces in the paramters that we pass to msbuild. For example, if we passed the parameters like this: “/p:Configuration=Release /p:OutDir=”"$release_dir”"”, then it would fail and we would get a msbuild parse error saying it was invalid.

Build script output for Debug task

Summary

In a relatively short amount of code, less than 30 lines, we have accomplished quite a lot. We can now issue the command: invoke-psake .\build.ps1 -taskList Debug, and psake will automatically clean the output folders, do a full rebuild of the Debug configuration and copy the output to a custom location on our filesystem. What’s more, the build script we have written is small, compact, easy to read, easy to maintain and easy to build/extend upon in the future.

As this is getting a bit long already, I’m going to cut things short here, however, there are some additional things that you can do as part of the build script that are very nice, such as automatically versioning the assembly before you do the full build. If you take a look at Ayende Rahien’s example from Rhino Mocks, that is covered there.

Also in the new version of psake, there are pre and post conditions and actions that you can add onto your tasks, although I haven’t had the opportunity to use them yet. I’ll try to cover those in a future blog post though.

Code Complete 2nd Edition

Code Complete 2nd Edition, by Steve McConnel should be recommended reading on software engineering degrees at Universities the world over. It is a classic book about the software industry. McConnel makes the distinction between average programmers, who are happy to go through the motions of churning out (usually terrible) code and collecting their wages; and above average programmers, who continually seek to improve their base knowledge, actively improving their skills, who write solid, well designed and easily maintainable code. I think this was the book that really changed my mindset about being a programmer, about being proud of the work I do and the programs I write and maintain.

Working Effectively with Legacy Code

Working Effectively with Legacy Code, by Michael Feathers is another classic book, and another which I believe should be recommended reading on all University software engineering degrees. The reason I would recommended this book to any aspiring developer is that, more than likely they are going to be working with legacy code. I would say that 95% of the code I work with on a daily basis is legacy code, although that figure is slowly improving, thanks in a large part to the skills and knowledge I’ve gained from this book.  Feathers’ defines legacy code as that which does not have unit tests. I would also add that most legacy code is often poorly designed, with no comments and is usually incredibly difficult to maintain. The book is split into three parts, the first part being about how you can bring about change in your legacy code base (and legacy developers!); the second part is like an FAQ, which links techniques together in a way to address common problems; the third part is a reference of the different dependency breaking techniques that can be employed to get your legacy code under test and under control.

The Art of Unit Testing

The Art of Unit Testing, by Roy Osherove, is an excellent book, full of practical advice about unit testing. The book covers everything, from why you want to unit test your code, to how you can unit test code. Even if, as I had, you have written unit tests before, then you can still learn something from this book. Indeed there were several patterns on how to approach particular problems that I’d not even considered before. Also, I had never really gotten my head around using a mock object framework as part of my unit tests, but this book explains and demonstrates in a clear and concise manner, exactly how you can leverage your mock object framework of choice for your benefit. One minor criticism that I have though, is that I feel there is a certain element of bias toward Typemock Isolator – Osherove is a chief architect at Typemock.

Holub on Patterns

Holub on Patterns, by Allen Holub, is another excellent book, about software design.  Design patterns offer an excellent way of not re-inventing the wheel, and Holub offers an entertaining and insightful tour of the majority of the Gang of Four patterns, and offers real world scenarios in which you would use them. The book is very opinionated, but this is not a bad thing, indeed it is refreshing to read as Holub is obviously very passionate about the subject. It certainly opened my eyes into the world of design patterns, as I’m one of these who finds concrete, interesting examples an excellent tool for learning, and I’ve always found the Gang of Four book rather dry.

C# in Depth

C# In Depth, by Jon Skeet is an excellent book about the C# programming language. If you want to understand something about C#, and I mean really, truly understand why the language does what it does, then I suggest that you read this book. The book is clear and straightforward, with excellent examples. Honestly if most of the people posting C# questions on stackoverflow.com read this book, then I suspect the number of questions would stop increasing at the current rate.