Database triggers are useful, and I am not going to bush it completely. In some cases, like the one I run into, triggers are more of a distraction and source of issues, rather than help and ease of headache-free maintenance. In order to understand the case, players must be introduced first.

• An application that collects information from user inputs to be stored in database at a very specific table that is uniquely assigned for the purpose of persisting user selections.
• An external service that is asked from time to time to perform a job based on the inputs user has provided from the application.
• Results of the job are stored in database, and for optimization purposes, some metadata stored as well, in a table of its own. What kind of metadata? Well, lets keep it simple and say that a certain job was executed or not. So the next time job (pretend that it’s scheduled) has to be run, it will first validate that it wasn’t executed before.

Some business process rules around the user inputs are defined as well

JP called me out, so here I am, trying to travel back in time to recall how the heck I ended up coding.

How old were you when you first started in programming?

I was 16 years old when I touched computer for the first time with intension of more than just playing a video game. Not that I was a big gamer before that - I was not. I got my 1st computer when I was 16.

Going through the PDF document Karl Seguin was kind enough to share with all of us, could not not to agree with the written - quoting:

The real reason we’re spending a whole chapter on decoupling (which layering is a high-level implementation of) is because it’s a key ingredient in writing testable code. It wasn’t until I started unit testing that I realized how tangled and fragile my code was. I quickly became frustrated because method X relied on a functional class Y which needed a database up and running. In order to avoid the headaches I went through, we’ll first cover coupling and then look at unit testing in the next chapter.

[Purely Personal]

“Never give up, never surrender” was my favourite part from the Space Odyssey. Today it proved to be true again. How do you lift the skills of the team? By lifting the overall skills, by raising the bar for the whole team. This was the GCD is lifted, forcing the less strong developers to invest more, rather than doing an opposite, forcing the strong developers to play dummy.

Today I had a friend of mine, Mr. Mo, visiting us for a dinner and then having a little code jam (with a cup of tea and some crackers). A few things I would like to comment on:

• Thank you Mo for discovering the great taste of Oren’s triple A stake. Rhino Mocks 3.5 is awesome. Not only it is more natural to read, but also blends the differences between state based and interaction based testing into more cohesive testing. I loved it.

Update: Mark Capaldi has revealed a great VS.NET shortcut that does the work (Shift-ESC).

Visual Studio floating windows are not playing nicely with keyboard shortcuts. If you only using a keyboard, and want to be able to navigate around without constantly getting destructed by a mice, it’s ok. But floating windows are impossible to close without touching a mouse. At least I am not familiar with a way to do it. Imagine you could do something like this - press ALT-Space on floating window and… close!

Albert Weinert has release an update to his plugin to allow execution of R# 4.0 from within Visual Studio .NET 2005 / 2008. The only Unit Testing framework supported by R# 4.0 out of box is NUnit, so this is a useful plugin for those who prefer MbUnit to NUnit.

I recall that one of the final features for R# 4.0 was planned to provide out-of-box plugins and support for several Unit Testing frameworks. Wonder what happened to that plan.

It’s Canada Day today. And it’s opening of The ALT.NET Open Spaces conference in Calgary, taking place August 15-17, 2008 (at the University of Calgary).

Hurry to register as places are limited.

This is going to be sweet!

The leading bargeman

A few months ago I blogged about Domain Objects vs. Primitive Types. Back then it felt right to me to transform a primitive type, like a Guid that represented an organization ID, to an Organization domain object. Unfortunately at that time I was not educated enough to know that this is a common idiom among many object designers. Apparently it is. Craig Larman writes it nicely in his book (in my case Organization is what Craig references to as a Customer):