Cakes

Cote writes about requirements gathering and cakes.

If your powerful boss asks you for a cake, you can't easily find out the details of what he wants. You have to find out via secondary sources (e.g. the boss's calendar, asking the baker what sort of cakes the boss has ordered before). The calendar may not be up to date, and the baker may not remember accurately.

This takes longer and is more likely to go wrong. If there are more steps than necessary in finding out requirements, the solution is to understand what the difficulty is with asking him directly and work on reducing these difficulties.

Personal Search Filter

If you want to find out information about something, you will typically enter terms into a search engine.

The search engine will determine which results are most relevant (by using a complex algorithm based on how important it thinks the pages are). Everybody using this search engine will see the same results.

The things you want to see might not be the same as the things others want to see. However, you are more likely to want to see things that people "compatible with you" liked. If A likes B and B likes C, and B also likes D, then chances are that A will like D.

You could filter the results of your search (from the search engine) through a personal search filter. This would reorder your searches depending on

1) Things you have liked before
2) Things that people compatible with you have liked before.

When you visit a web page, you record whether you found it valuable. This updates your personal search filter and how compatible you are with other people. If you liked page A and B didn't like page A, you will not value the opinion that B liked page C. However if B liked A, you would be compatible with B and their opinion would affect your search filter.

This can be seen below:

Anti-tests

Charles Miller describes the concept of an "Anti-Test", which is a test that verifies a bug exists.

This can be written when the problem is discovered, even if it's not going to be fixed immediately.

It means that if the problem is inadvertently fixed as a result of something else, we know this has happened, have a look at why this is the case and update our records accordingly. The test can then be changed to a normal test to make sure it doesn't go wrong again.

When you're ready to fix an anti-test, you can change it to a normal test - it should now fail (and this change should be easy to make), fix the bug and make sure the test passes.

NAnt version

I've been trying to add version numbers to a NAnt build script using the <version> task, and come across a problem with the script in Marc Holmes' "Expert .NET delivery" book.

The task increments a property called "buildnumber.version", not "sys.version". Adding the following line to the script (as described here) seems to fix it.

<property name="sys.version" value="${buildnumber.version}" />