My current employer has a corporate subscription with Books24x7 and purely out of curiosity I subscribed to their announcement mailing list some time ago. Most of the emails go directly to trash but some of them I actually read.

The business model of Books24x7 is to collect a fixed yearly subscription fee from companies (or individuals) and give a 24x7 online access to a vast number of professional literature in exchange. Perhaps not surprisingly, the titles available are typically not the ones you'd like to have but those which the publishers are willing to sell "cheap" plus a few gems to give the offering at least a hint of attractiveness.

This time, I found one of those gems. Witness The Assembly Programming Master Book. Definitely a must-read for everyone working for a global IT consultancy... (Not to mention the endless stream of game programming titles from Charles River Media!)

While I can't see why would the modern J2EE/.NET developer benefit from having 24x7 access to such a contemporary title, I can't help but drool after it. I mean, the marketing blob says "Aiming to prove that writing programs for Windows in the Assembly language is no more difficult than writing the same programs using C/C++". Yeah, right.

Patrick Cauldwell blogs about how they're using labels to facilitate their edit-merge-commit process (as opposed to checkout-edit-checkin). I find the approach intriguing, although obviously nothing new.

Personally, I've seen no real problems with mandating the HEAD to be "pristine" at all times. The potential issue with that approach, as Scott also mentions, is that it can "keep people from checking things in when they should" but I haven't seen this risk realize itself too much. In fact, I'm pretty sure I've seen a positive trend in people actually checking in more often and in smaller steps specifically because it's easier to keep HEAD clean that way.

How are you treating your HEAD?

Spotted from the comments in K. Scott Allen's blog:

Heh. A fellow consultant just pointed me to a couple of Application Development Trends articles that have quoted me:

Agile Breaks on Through to the Other Side (3/1/2005)
It's Alive! The Frankenapp Runs Amok! (4/1/2005)

And, according to age-old tradition, they got my name wrong in one of them :)

Browsing some of the feeds I've been neglecting for a whole week, almost, I found Brian Button mentioning an agile way of speaking. Agilists have done this for ages (ever since the Snowbird meeting, probably) so it's certainly nothing new. What I wanted to bring up is something that many of us observed on the Scrum course last week.

Too much "agility" can easily lead to lack of structure.

You could call it trashing, you could call it tunnel vision. Whatever you decide to call it, it's something we need to deal with. My suggestion would be to deal with lack of structure with extra visibility. For a talk, you really should consider what Brian did: plotting out how much time you've got left, which topics have been covered, which topics are next to be covered, and so forth.

Do not rely on your audience to know where you're going.
Their crystal ball ain't any less dim than yours.

I just registered for XP2005. If you're you're going there from Helsinki, Finland, let me know (lasse {dot} koskela {at} gmail {dot} com) -- I'd love to have someone to talk to while traveling...

Is it just me or is David exaggerating a bit by claiming that people are dying to hire [Rails programmers]...? To me, three vacancies is not a lot. Especially if the ad mentions the word "inexpensive".

Well, at least the MyTechSupport job would be cool because the project manager's (last)name is Matz ;)

(And so that this wouldn't be quite as worthless an entry as it has been so far, here's something interesting I picked up from the blogstream just now: require 'forwardable')

I just noticed that they've added a bunch of new logos at testdriven.com. Some of them are quite nice. For example, I wouldn't mind having this on a t-shirt:

Who would've guessed...

Michael, the mysterious Braidy Tester at Microsoft (oh, I should've said "SetUp" instead of "setUp" in the title...) is worried about people not taking enough care to craft their setup sections for automated tests.

I have to say I don't see it that way.

It's about focus. Surely you're not writing all your unit tests against the one and same layer of your code base, are you? When you create a fixture that contains an instance of wamboozle so that you can instantiate a fizwobble and test that, you don't really care whether all the execution paths you can traverse in order to create that wamboozle are actually executed. You care about the fizwobble under test. You focus on the wamboozle in a separate set of tests.

Obviously there are cracks and little things can fall into them, but I really don't see it as such a big problem as I interpreted Michael's blog entry to describe it.

What do you think?

Did you get mixed up with which was fizwobble and which was wamboozle? I did.

ADD stands for Attempt-Driven Development. Don't ask :)

[Spotted at testdriven.com] Max Kington is worried about who's telling the security user stories. My answer to the question? You are.

When talking about non-functional requirements for a system that are also invisible to users, such as security, we're not talking about user stories. In fact, we're not talking about requirements as such. We're talking about constraints. Constraints must be handled differently from requirements. You can't prioritize constraints into iterations. You monitor and enforce constraints. How different is a constraint labeled "write secure code" from a constraint labeled "write thread-safe code"? I'd say the difference is pretty small from a process perspective.

Have a toast.

Phew. I just uploaded chapter 1 for the first internal review. I'm certain there will be plenty of editing and revising to do but it's still a milestone for me. I'll celebrate by eating some... Uh... Well, whatever I can find in the fridge. :)