Recently, I’ve been diving into some foundational literature in the IT field. It’s a great way to get acquainted with influential figures and ideas that frequently come up in current developer discussions.

After tackling Patterns of Enterprise Application Architecture and Clean Code, I moved on to Test-Driven Development: By Example.

This book was by far the most enjoyable IT book I’ve read. I found myself laughing out loud and thoroughly engaged throughout. For instance, check out this paragraph about Kent Beck’s early days.

The book uses two main examples to explore various TDD disciplines. Kent Beck discusses patterns in TDD, including design patterns, testing patterns, and refactoring patterns.

Overall, the book focuses more on the mindset necessary for effective TDD rather than just the procedural steps, though those are covered as well.

I nearly finished the book in one sitting. Thank you, Mr. Beck, for such...

As I wrote earlier, I attended my first ever Alt.Net un-conference this weekend. It was a rewarding experience, and meeting fellow developers in such an informal setting was fantastic. The open spaces were particularly valuable.

One of the open spaces I participated in focused on Pair Programming. The discussion quickly evolved into how to persuade developers, management, and others that it’s a beneficial practice.

Here is a recap of some of the insightful points from that session:

Good Ideas

• Switch the keyboard often: One developer writes the test and another handles the implementation, or use a Pomodoro timer for ten-minute intervals.
• Switch partners frequently: For example, once a day.

Arguments for the Benefits of Pair Programming

• It’s fun! This alone is a strong argument. Enjoying your work is essential.
• Here is a list of benefits and some studies...

Two big things will (or are in the process of) happen this weekend.

The first is that I have gone over to the dark side. Yes, I know, I couldn’t resist anymore. The temptation was too great.

I have bought a MacBook Pro. And have just installed it – that process was so smooth. I want to do it again!

OK – the next thing is that I will speak at a conference for the first time ever. Actually, it’s an Un-conference for alt.net Sweden. And it’s a lightning talk, but that only makes it harder, I think. 10 minutes – it’s not much.

The subject is “Let Fluent NHibernate test your mappings.” And it relates to some of my recent findings.

I know that I have spoken some bad words about Apple, so I suspect some pretty harsh comments from...

I came across this post by Ayende which perfectly captures my goal for achieving persistence ignorance:

“After that, you are done. Just create an entity in the proper place, hit the /database/create and have a lot of fun.”

I particularly enjoy the “fun” part of this quote! My aim is to configure conventions and then simply code the model as I desire, allowing the framework (NHibernate in this case) to handle the storage details.

The Fluent NHibernate framework has been updated since Ayende’s post. I explored the documentation, including AutoMapping, Conventions, Available Conventions, and discovered some shortcuts. Additionally, this article explains how to transition from the old convention style to the new one.

I’ve put together an updated example inspired by Ayende’s post, including a feature for automatically setting cascades for OneToMany and ManyToMany relationships.

Here is the most...

If you’re looking for a simple way to share code snippets without the hassle of email or chat messages, Pastie is a great tool.

Just visit the site, paste your code, optionally select a programming language, and you’ll receive a URL to share your code snippet. It’s a handy way to quickly get feedback or collaborate with others on coding problems.

Lately, I’ve been working extensively with Fluent NHibernate and encountered a recurring issue.

When setting up a mapping test with PersistenceSpecification<T> to test a reference (using CheckReference, for instance), I often get the following exception:

System.ApplicationException: Expected ‘Marcusoft.Product' but got 'ProductProxy…' for Property 'Product'

This issue arises because NHibernate generates a proxy class, which causes problems when performing equality tests on that class. To address this, I found a base class that resolves this problem, provided by the Hibernating Rhinos (what a name!).

You can read more about this solution here or check out my code here.