use Perl

I used to know a couple of people who decided to go into COBOL development because they could see the way the salaries were trending back in the early nineties :-)

Last time I talked to one of them (around 2000 I think) she told me that she knew of two large orgs that had taken their compiler development in-house - because they couldn't take the risk of not being able to keep the code running on newer boxes as time went on... so folk maybe playing this sort of game already.

And you are a lovely lovely man who I will buy several beers the next time we meet :-)

I'm partially kidding :-)

I don't really buy your law though. It was tough for me to "get" roles for various reasons. It was tough for me to get declarative Prolog-ish languages when I first encountered them. I know a bunch of people who took a hell of a time to understand OO. I know a bunch of folk who don't really "get" TDD, XP or Scrum.

Yes - there are nice sound bites for all of them. But they don't really "explain". The concepts are often deep - even if they have a simple container.

... I'm still not totall clear about this roles nonsense :-) :-)

Yup. Since 1928 Australia has been a signatory to the Berne Convention - so hasn't needed it.

The only case after 1928 where it would have been an issue was before the US joined (if you wanted copyright protection there - but you would have had to pay for registration anyway). Not an issue now.

_"Seems problematic:"_

Nah - the problem is selecting all the parents of a child in order. The length of the path is guaranteed to increase.

Ah...

ORDER BY CHAR_LENGTH( path )

?

Too lazy to test it by would something like

ORDER BY FIELD( id, 5,7,1,48)

do the job?

If things like faeces are common - then I think you might need a flickr feed...

Damn :-(

I was going to post some useful references coz I spent a large chunk of time with my undergraduate project implementing a temporal reasoning system based around a constraint propagation mechanism, intending it to form the backbone of a multi-agent planner.

Then I realised that was eighteen years ago and I cannot remember anything about the bugger - beyond the fact that it was annoyingly NP-complete and ran far too slowly to do anything useful.

Sorry!

Yes. You're right. I was obviously feeling especially grumpy when I wrote that. The presence of the card is certainly a good sign that folk are paying attention to the code and know improvements need to be made. Yay :-)

That said - I've seen too many folk who get into this nasty cycle of hack-code-until-mud... oh bugger.... better write some refactoring cards.... spend time persuading product owner than they really, _really_ need to do the refactoring cards.... refactor.... hack-code-until-mud... repeat...

Refactoring should be continual. That's when you start getting real benefit. So I would see the card as a good sign - but also a sign that things could get better.

... that they feel the need to stick it up as a separate card rather than doing continual refactoring. I'd want to work with them on that :-)

Adrian

It was an excellent - and productive - three days.

(Also - I want to get Curtis to educate me about Role based design... but that's not QA related)

.. Another vote for nested TAP here for obvious reasons!

Me, I hope to fix some of the more broken bits of the T::C internals, make whatever changes Piers needs for T::C::Sugar, and knock a few of the things off the T::C to do list.

Along with anything else that seems useful :)

I'm also going to annoy Curtis with a long conversation about TDD. Especially if I get around to finishing up the blog post(s) that have been sitting on my desktop for the last week :-)