I have a USB-stick which acts as my backup. As I program a lot compilation and unit testing produces a lot of trash (.pdb, Test Results, obj-files etc). I don’t want or need a backup of those.

Today I found a short script that removes those file. Since I have folders named “bin” I want to keep I tweaked it a bit into this:

FOR /F "tokens=*" %%G IN ('DIR /B /AD /S Debug') DO RMDIR /S /Q "%%G" FOR /F "tokens=*" %%G IN ('DIR /B /AD /S _Resharper*') DO RMDIR /S /Q "%%G" FOR /F "tokens=*" %%G IN ('DIR /B /AD /S TestResults') DO RMDIR /S /Q "%%G" FOR /F "tokens=*" %%G IN ('dir /b /A /S *.vsmdi') DO RMDIR /S /Q "%%G" 

I don’t know if you are like me and don’t know the first things of DOS....

After spending a few days working with Fluent NHibernate, I’m finding it to be a fantastic tool. One feature that stands out is the ability to test your mappings. This feature is especially useful as it allows you to switch to an in-memory database, such as SQLite, which speeds up your tests and eliminates the need for a complex database setup.

For a solid introduction to NHibernate and Fluent NHibernate, check out the articles by Gabriel Schenker from Hibernating Rhinos. These articles cover mapping testing and are available here (Part 1, 2, and 3).

And I love this quote: “If you continue to implement your own data access code, you are stealing (money) from your customer.”

After a brief experience with NHibernate, I quickly realized that managing XML files for mapping instructions can lead to several issues. XML files lack compile-time checking and can create discrepancies between code and configuration.

The solution? Fluent NHibernate. This library allows you to define mappings in code using a fluent interface, eliminating the need for XML configuration.

I recently explored their starter example and was impressed. The approach is intuitive and offers features that feel almost magical, such as auto-mapping. It aligns well with the idea of “letting the storage issues be a consequence of the domain model”.

I found this great article about events, delegates, and anonymous methods.

These topics can be quite confusing, especially with modern syntax like lambda expressions. It’s challenging to make sense of something like () => { } at first glance.

The article by S. Desmedt offers a clear explanation and includes many links for deeper exploration. If you’re struggling with these concepts, this resource is a great starting point.

The more I work with NHibernate, the more I question why I wrote so much SQL in the past. It feels… unnecessary. Who said “stupid”? Not me…

Jimmy Nilsson once said, “I just want the database and storage problems to be a consequence of my domain model. I don’t want to think about it.” This aligns with one of the goals of Domain-Driven Design (DDD), and NHibernate is a key tool in achieving this.

I’ve been experimenting with NHibernate recently, and I’m genuinely impressed. While the mapping files can be complex initially and there are many tricks and traps to navigate, NHibernate is truly powerful.

Here are some resources that have been particularly helpful in my journey:

• The NHibernate API Reference
• A great tutorial for getting started
• A series of articles on implementing the Unit of Work pattern with NHibernate: Part 1, Part 2,...

I recently conducted a small experiment with an object-oriented database, db4o, and I’m quite impressed.

Initially, the concept is a bit challenging to grasp since there are no tables, no SQL, and no mapping involved. Instead, you directly store your objects.

The real challenge lies in querying these objects, but the db4o team has made strides in this area. For example, the current release includes full support for LINQ, providing an excellent programming experience.

Although I’m still a newbie and have some unanswered questions about data and class definitions evolution, it looks promising—very promising.

Just imagine it: “No more SQL. No more mapping.” It’s appealing, isn’t it?

Here is a very funny duo from New Zealand. This song is a great introduction. Come on – take a 7.10 break.

Flight of the Concords

And then take 3 minutes more:

Flight of the Concords

I’ve been quite harsh on the Conchango Scrum template for Team Foundation Server in the past, and I didn’t enjoy using it the last time (about 8 months ago).

My main issue was the need to use the standard, heavy-weight forms in Visual Studio to edit Backlog Items and Actions. This made it impractical for daily scrums, so someone (usually me) had to take notes during the meeting and then update TFS afterward. In lean terms, this was pure WASTE added to our project. I hated that, so we stopped using it quickly.

But now, Conchango has created a tool that I think fills the gap—a Task Board application that mimics the physical task board you typically use during sprints, planning, and daily scrums.

You can read more about it here and check out these videos to learn how it works. I can’t...

I haven’t practiced TDD for a very long time, and I’m still waiting for my first BDD project in real life. Sometimes, I struggle to articulate the benefits of these methodologies.

However, Gregg Pollack has traversed this same path and has delivered a great presentation on the value of TDD and how to effectively use it. Unfortunately, the video is no longer available, which is a shame because it was an excellent presentation.

Gregg’s presentation highlights several key points about TDD and BDD, which he describes as the “pathway to developer enlightenment.” Here are the key points:

1. Testing breeds confidence
2. Writing tests before code results in better code
3. Well-written tests serve as effective documentation
4. TDD isn’t just about writing tests; it’s about defining behavior

Seeing these points articulated was like having my own thoughts validated. Thank you, Gregg.

Also, I might need to explore...

I’ve been diving deeper into BDD, and the more I explore it, the more I like it. Today, working from home, I’ve been frequently exclaiming “Yes!” or enthusiastically explaining the benefits of BDD to Elin, who’s starting to get a bit annoyed.

What stands out for me is that BDD provides a way to derive requirements iteratively and exploratively, using the experts’ language (the ubiquitous language).

I also appreciate the structured approach to stories and scenarios described by Dan North in this article. This structure offers clear guidance on what to tackle next in the system. Mike Cohn outlines other advantages of using the “As a user, I want…” user story template.

The strict and formal nature of BDD also makes it well-suited for automation, as demonstrated by these guys.