Those of you young and technologically inclined may find this difficult to believe, but the average cell phone user cannot use many features you may find standard, such as call-waiting, call-forwarding, and conferencing.
OK Tog. I'm going to put my hand up here:
- I got my first computer for Christmas 1984, at the age of 9.
- I still remember that to change the background colour on that computer, you had to type POKE 53281,n where 'n' is the number (0-15) of the colour you wanted to switch to.
- The first distribution of Linux I installed had a kernel version number less than 1.0
- I'm a self-taught programmer, earning a living developing software that has to be compatible with dozens of versions of half a dozen different databases
- I have no idea how call-waiting works on my phone.
I'd be lucky if I got the opportunity to use call-waiting more than once a month. I don't get that many calls on my mobile to begin with, so the chance of getting two at the same time is quite slim.
When I hear the muffled beep that signals someone else coming in on the line, I experience a mild form of panic. I can pretty much work out from the display what button I need to press to put my current caller on hold, but I know from bitter experience that this is no guarantee I'll be able to get them back again later.
Given that I consider accidentally hanging up on someone to be far more rude than letting the second caller drop through to voice-mail, I just don't bother.
Except I have no voice-mail. I never could remember what number I needed to ring to retrieve them, so I eventually stopped ordering the service when I signed up for a new phone plan.
To top it all off, I'm one of those annoying people who feels the need to use entire sentences, complete with capital letters, punctuation and fully spelled-out words when I send a text message.
I think I'm getting old.
I spent all of Christmas telling everyone who raised the subject, including my brother who was on his way to report on Macworld SF, just why there wouldn't be an iPhone.
Boy do I look like an idiot now.
A grinning, "I want one of those! NOW! Yes, I know it's not going to be available in Australia forever, and half the features won't work when it finally gets here, I don't care!" idiot, mind you.
I spent a lot of today going through old Confluence bug reports: sifting through for all the forgotten bugs: the ones that we fixed but forgot to close, the ones that slipped through the QA cracks, the ones that are really all symptoms of some chunk of nasty, ugly code we need to drag out into a dark alleyway and bludgeon with baseball bats, but haven't had time to yet.
There was one interesting class of bugs though -- the ones that had spontaneously fixed themselves since we last looked at them. This could be:
- Because we fixed another, duplicate bug
- Because it was an issue with a dependency we later upgraded
- Because we performed the aforementioned bludgeoning-with-baseball bats on the piece of code that was causing that whole class of errors
Popular wisdom says that every defect needs a test, but popular wisdom says you write that test to check for the behaviour that you want to happen. So when that test goes green, you know you've fixed the bug.
Those tests are fine if you're going to fix the issue immediately, but often commercial reality says you're not. Then you're in trouble because (a) all our tools are predicated on tests that start green and stay green, and (b) you can't maintain such tests effectively. How do you tell that the test still works? It can't exactly go more red than it is now.
The solution, perhaps, is the anti-test. Write a test that verifies the bug. One that goes green when the application is misbehaving in the way that you expect it to misbehave. Make sure you annotate it with the issue that it's verifying. That way your continuous integration environment will let you know immediately if something's suddenly worse than it was before.
Or perhaps, when something is spontaneously better.
It's not often a developer gets to practice optimism.
For 90% of my transport needs, I rely on a very small stretch of railway: the track running over the Harbour Bridge between Milson's Point and Wynyard stations, a single stop. Exasperated last night by the fact that once again there were no trains running over the bridge and I was forced to catch a bus instead, I decided to find out what the schedule was for such outages in the near future.
This is what I found. The following dates are Cityrail's projection for when that one small piece of track will be unavailable over the next six months:
January 3-4, 13-14 (weekend), 16-18, 22-24, 29-1st February
February 12-15, 19-22, 26-1st March
April 2-4, 21-22 (weekend), 23, 26
May 7-10, 21-24
June 4-7, 9-11 (long weekend) 12-14, 18-21
July 2, 4-5, 9, 10, 12, 16-19, 21-22 (weekend)
(All dates denote days on which the line is unavailable after 10pm, except those marked weekend where the line is closed all day for the entire weekend)
You could argue that this is just an unlucky six months for me, and some big work is going on. And I'm sure that if I complained to Cityrail that's exactly what they'd do. But this is pretty typical of the regularity of outages I've experienced since moving to the North Shore, so whatever is going on, it's been going on for three years now.