Getting ready to fly
Everything is now is the last minute bug fix stage. We’ve been testing the software, the help documentation and the e-commerce as thoroughly as we can. I’ve been in this situation many times in the past: the release date or go-live date is set in stone, you’ve committed to it and come hell-or-high water, the thing has to be ready.
But every time I’ve been in this situation, I’ve thought "why didn’t I put another 4-6 weeks into the schedule?" But of course, what ever you do, you’ll always need another few weeks to ‘finish off the finer details; fix a few more bugs’. Even the D-Day landings could have done with a bit more spit-and-polish, I suspect. The point is, if you don’t set a date, the job will never get done. It’s a psychological necessity to have a ’do by’ date and it seems that only by setting such a date, the job gets done. Of course, the trick is to set a doable do-by date!
So we’re in the position of finding some bugs and the question is what to do about them. Well, my attitude was formed a long time ago by working for one of the hardest, meanest (and best) project managers I’ve ever had the misfortune to meet. To give you an example, one morning I came into work about a week after I’d left his team for another one and found him physically dismantling the machine I was working on (he ‘owned’ it – and computers were scarce). I naturally remonstrated about this state of affairs. His response was (he was Scottish and smoked the most evil smelling cheroots) “Laddie, ye’ll find that possession is nine tenths o’ development. Now just **** off”.
But that wasn’t what I learnt from him. On an occasion a few weeks earlier, a programmer on the team had proudly fixed a bug in the software. The problem was that the fix came in at 3:15pm: the project manager had declared the cut-off for the release to be 3:00pm. The programmer was loudly and publicly told where to put his bug fix and in which direction to travel before he was propelled in the said direction by overwhelming force. The printable part of the project manager’s words were something like: “Laddie, I prefer t’ ken y’ bugs and nay ken y’ fixes”. Which translated into the Queen’s English ran: “I’d rather have known bugs than unknown fixes, old chap”.
The thing is, the project manager was absolutely right. There’s always a chance that, by fixing a bug at a late stage, you’ll screw up something important – and you don’t have the time to re-test everything.
So, unlike previous bug hunts, we’re now just largely adding to the ‘to-be-fixed’ list: very frustrating!
Anyway, the last feature that went in (I decided that I couldn’t live without it) was getting Rails IntelliSense to recognise user-added code rather than just pre-existing Rails methods and classes. As I’ve pointed out before, Rails is a pig where IntelliSense is concerned. But I’ve added code that automatically recognises Rails models from the controllers section. Here’s an example:
This is a ‘post’ model from a blog application. The corresponding controller is PostsController and here’s a screen shot of the resulting IntelliSense.
So it does work. But here’s an illustration of the limits of my current IntelliSense parser. Look at this screen shot:
Here the @post instance variable is NilClass according to IntelliSense. But it isn’t: clearly NilClass doesn’t have a method find. The resolution of this problem comes when you do a Goto Definition on find
It’s just a stub – the IntelliSense parse didn’t figure out what find actually returns. That’s a problem I hope to address in the next iteration of IntelliSense. I’ll be saying more about that, improvements to the debugger and the Visual Rails Developer over the coming months.