Pair-programming with another one of my wonderful team colleagues last week, we came across a tricky little bug caused by a (correctly behaving) feature of Java Calendar.
We tried to replicate the bug (to do with matching something within a date range) by running the application as described in the bug report. The application worked just fine.
We eventually tracked down the problem - setting the system time to the afternoon we replicated the bug. If we'd started on this bug after lunch, instead of first thing, we'd have found it straight away. I'm sure there's a moral there somewhere!
The HOUR of a Calendar is based on a 12 hour clock - we found some code that was setting the HOUR (to 0) when it should have been setting the HOUR_OF_DAY. The effect of setting the HOUR to 0 is that before 12pm, the hour part of the date is set to 0, and after 12pm the hour is set to 12 - this lead to the bug we had to fix.
OK - so it's not very interesting - but hopefully at least if you managed to stay awake during the whole of this article you'll remember it next time you come across something using Calendar.HOUR and the alarm bells will ring.
We were lucky that someone spotted this bug - it could have easily been missed. How do you find something like this where the bug only appears in the afternoon?
Also - it feels to me like the feature of being able to set the HOUR rather than the HOUR_OF_DAY is a bit superfluous and almost invites bugs like the one we fixed. How much time is saved by the existence of this feature compared to the time wasted by it? What does the time wasted by this feature tell us about how to write APIs? The experience has reminded me of a talk at a company conference run by one of my previous employers; "Features - just say no!".
Pair-programming with one of my wonderful team colleagues last week, we needed to automate an SSH thing.
SSH doesn't allow the password to be specified on the command line. Usually you'd set up SSH so you don't need to type your passwords). Due to one thing and another, we couldn't do this.
We found Pexpect (a pure Python version of expect). Pexpect makes it easy to automate things that require user interaction (like typing in a password when prompted). As Python was available on the relevant machine, we tried it out - the example using ssh worked first time (here included under the appropriate license):
#!/usr/bin/env python
'''This runs "ls -l" on a remote host using SSH.
At the prompts enter hostname, user, and password.
'''
import pexpect
import getpass
host = raw_input('Hostname: ')
user = raw_input('User: ')
password = getpass.getpass('Password: ')
child = pexpect.spawn("ssh -l %s %s /bin/ls -l"%(user, host))
child.expect('password:')
child.sendline(password)
child.expect(pexpect.EOF)
print child.before
Cool! Another useful addition to the post-modern toolbox.