Friday, 28 January 2011

My First Presentation

Last Thursday[+] saw me popping my “presentation” cherry as I stood up in front of a small crowd of around 35 people and waffle on for 60 minutes about unit testing database code (SQL). The size of the audience and the number of questions at the end and in the pub afterwards makes me feel that it can probably be chalked up as a success. I certainly got a buzz out of it and more importantly I’m glad to get one under my belt before the ACCU Conference in April where I’ll be presenting “Using xUnit As a Swiss Army Testing Toolkit”.

It was pretty obvious from my twitter feed that I was more than a little bit nervous and even though I had a few calming replies from my fellow ACCU members I was still somewhat pensive. The ACCU is full of very smart people and the topic on which I was speaking was not what I would consider one of my core skills and so I was well aware that the room would contain people far more knowledgeable than me on the subject. The nightmare scenario was one of those people asking the kind of ‘obvious’ question that would invalidate the entire talk. The basis for this is some of the ‘heckles’ that I’ve seen at past conferences and talks. Fortunately they were unfounded… this time.

So what did I learn from the experience? Well, it’s kind of nice being the centre of attention for an hour or so :-) The biggest thing, and I’ve said this before about blogging, is that it makes you think even harder about your topic so you feel doubly sure you don’t say anything really stupid. When first asked by Allan Kelly to do a talk for ACCU London I reluctantly said ‘yes’ as I find originality a big stumbling block – I’m always assuming that I need to say something novel. Because of the ACCU’s heritage[*] I didn’t want to say anything C++ related, I don’t know anything about Java, the iPhone, Python etc and anyway those angles are already well covered by other prominent members so that pretty much left something C#/SQL based. I also didn’t want to do a shorter version of my upcoming conference talk so I looked back over my blog for inspiration and realised I had a few posts relating to database development that I could probably stitch together into a coherent piece And so the following blog posts were fused together to the form the meat of the session:-

xUnit Style Database Unit Testing
Simple Database Build & Deployment With SQLCMD

…with the following posts providing some additional minor content:-

Debug & Release Database Schemas
Implementing Constants & Enumerations in a Database

Naturally I had extravagant plans when planning it 3 months earlier. I was going to develop my own test runner and follow Paul Grenyer’s fine example by running actual tests with a live demo. I was also going to have a few vibrant slides and follow Martin Fowler’s lead by eschewing bullet point lists and unnecessary images. And then Xmas came and went and like any real student the deadline was looming and still I only had a rough outline.

My wife, who fortunately knows a thing or two about presenting[#], and more importantly knows a thing or two about her lazy husband, provided some sage advice to get me bootstrapped. It didn’t take long to realise I was never going to have time for the live demos (either beforehand or during the talk for that matter) and I also dropped the ‘clever’ slides in favour of creating what were essentially a giant bunch of queue cards. Once I had gone through the entire talk for real I decided I probably shouldn’t try and run before I can walk…

This may seem really obvious to everyone else but there is a world of difference between talking in your head and saying it out loud. I spent a number of train journeys on my commute planning the talk and then going through it in my head, i.e. actually talking in my head to practice what I was going to say – I didn’t think my fellow passengers would be that interested in the content and they might also find it a little repetitive :-). So when I came to practice it out loud I got to hear all the pauses and umm’s and errr’s and it was truly disheartening. I practiced it again over the next few evenings and although the talk become more fluent, I was still annoyed with myself for forgetting to say certain things. My wife stepped in once more with another ‘obvious’ piece of advice “The audience doesn’t have a script, so they won’t know what you did and didn’t mean to say”. She also said that if a point was truly important I wouldn’t forget it. Boy it annoys me how that women is always right! I still ditched one slide right at the last minute as I realised the content was effectively irrelevant, it also was hard to convey fluently and would help bring me back to nearer the 60 minute mark.

On the night it seemed to go pretty much according to plan, except for the technical problems getting my laptop and the projector to acknowledge each other’s presence. I only remember losing my train of thought once and I believe I got all the key points in just like my wife said I would :-). I felt the urge on a number of occasions to ad-lib as I thought of something new or different to say but I held fast and stuck to the content I’d been practicing. If I ever get to do the talk again I guess I can always ‘refactor’[^] it. It was also nice to be able to point out two members of the audience (Phil Nash & Steve Love) whilst acknowledging their ‘indirect’ contributions.

After I had finished rabbiting there were a number of questions ranging from the classic “how do you get your developers to write tests?” to one from fellow member Ed Sykes about whether it’s possible to get code coverage for SQL based tests? No, I don’t know. In the pub afterwards we got to chew the fat further and a few more ideas popped into my head. The question now is whether the alcohol killed off too many brain cells or whether I can still recall what they were for future blogging purposes…

All-in-all a wonderful experience and hopefully an excellent bit of practice in preparation for the main event - the ACCU conference in April.

FWIW Here is a link to the slides (PowerPoint).

[+] The photo was taken by fellow ACCU member Schalk Cronje.

[*] There are members who sit on the C++ panel! They know more than than just their onions…

[#] She’s a producer of live events and one of her many talents is to train and rehearse speakers.

[^] I guess that means “the message” stays the same but I say it in a different way.

Monday, 10 January 2011

Intriguing SCHTASKS Bug

To get our system up and running quickly we chose to use the built-in Windows task scheduler to invoke our nightly batch. During initial development we added a couple of tasks by hand using the Scheduled Tasks UI, but as we got closer to our release date we created a batch file to script creation of the scheduled tasks so that we had a formal (and version controlled) deployment process, e.g.


The script was written and tested on a Windows XP desktop machine, but when we came to test it on our Windows server the script failed with the following error:-

ERROR: The creation of the scheduled task failed.
Reason: The Task Name may not contain the characters: <, >, :, /, \,|.

This was most curious as the server was running Windows Server 2003 (which is the same family as XP) and the task names were all pretty simple using just a number, dash and short name, e.g. “01-EstablishValueDate” – there were no out-of-the-ordinary characters at all. Naturally I took the dash[*] out first – no luck. Then the numbers – nope. Finally I resorted to a binary search to try and pin down exactly which character(s) it was…

It turned out to be the letter ‘D’ at the start of the word “Date”! The first three tasks I tried all had the word “Date” in them somewhere and they all worked after just removing the letter ‘D’. To be more specific it was a capital letter D as a lower case ‘d’ worked! This became our temporarily workaround whilst I did a little Googling in the background as I just couldn’t entertain the idea that this was the real problem; I’ll always assume I’m doing something wrong until Occam's Razor tells me it’s not me :-). Fortunately I quickly discovered the following forum post “Error In Schtasks Command Line” where there author was having no joy in creating a scheduled task called “Defrag”. Sadly it doesn’t say they resorted to just calling their task “defrag” as a workaround. Anyway a short time later I managed to discover an MSDN article that appeared to confirm the behaviour. In the KB article it says the following:-

The Schtasks command verifies the task name by comparing the task name with an invalid character set. If the task name contains one or more characters from the invalid character set, the Schtasks command denies the task creation request.

However, in race conditions, the invalid character set may contain a valid character. Therefore, the Schtasks command cannot create some tasks even if the task names contain only valid characters.

My mind boggles at what the SCHTASKS code is doing to create such a race condition? And why just the letter D?

[*] A common source of error is pasting command lines out of Word documents or web pages into console windows; this often results in curious error messages from the application. The problem is the “clever” document editor converting a dash (en dash, minus sign, etc) into a proper hyphen (em dash) or equivalent Unicode character at a different code point from the ASCII one. It may look like a dash to you and me but the “computer says no”.