Business
Is good, and busy, as always. After much negotiation I've managed to bring another software engineer on-board to help out with our workload. I'm very excited about this, even though the business will only have her on a part-time basis. I've also found a few suitable people who I can outsource to, so I'm hoping that things will quieten down as the wedding approaches, even though Perl Training Australia's throughput is increasing.

Training
In negotiation with some other organisations to provide extensive training over the coming financial year and beyond. Very exciting stuff.

Trees
A wattle tree in the front yard fell over. Just walked out to get the mail, and there it was, lying on its side. It missed the house, missed the vege-patch, and missed the fence. Very considerate of it. Now we just have to remove it and tidy it up.

On the 5th August I set up a phpwiki for a role-playing game that I was running with nine friends. The wiki was to form a general resource for the gaming group. I imagined it would get some use, with people writing for it here and there.

Since its inception, the wiki has been serving almost 800 pages/day, peaking at over 2000 pages/day only four days after creation, serving 25Mb/day of pages. The wiki size has grown from about a dozen pages up to 161 over the course of a week. Wow, and all this to just ten people. I've been asked to make the wiki public in a read-only format, since many of the players want to share the love.

I've also set up a wiki for business use, being a great place to jot notes, write proceedures, and pass and store information around. I may also end up doing a similar thing for my clients, many of which I'm sure would find such a tool very useful.

Payroll::AU::PAYG
Determine the tax of yourself or your employees in one easy step, using Payroll::AU::PAYG. I'll be talking on this during tomorrow night's Perl Mongers meeting. The entire module was written during my lunchbreak today, although I expect that the talk will take much longer to prepare.

Identity Theft
Lots of identity theft has been going on, and it looks like I'm not the only one who's concerned about it. My bank rang today as a courtesy call to see if I was happy with their service. Oddly enough, they didn't seem at all surprised when I asked for confirmation as to who they where when I was requested for my name, date of birth, and full address. The telephone operator immediately provided name, employee number, office building, manager, team leader, and contact phone number.

Of course, one cannot use the contact number provided by a potential scammer to verify their identity. A call to the bank's customer service department revealed that they could confirm that the call really was them, but only after doing some paperwork of their own to verify it.

A good challenge-response protocol for telephone calls would be great here, to allow both parties to verify the identity of the other. In fact, a good challenge-response system based on sound, cryptographic principals would help remove a lot of identity-theft and identity-confusion. Rather than needing personally identifiable information (name, date-of-birth, address, ABN/TFN/SSN) and static secrets (passwords), being able to provide a cryptographic challenge and response means identity could be confirmed using once-off session information.

Of course, you'd need a way to stop a scammer from presenting you with a challenge that they've received in pretending to be you, but I'm sure there's a way to get around that as well.

That which does not kill me, improves my disaster recovery plan
Had a somewhat exhausting experience the other day. After rebuilding a RAID I needed to restore the contents, and discovered a DLT tape which seemed to encounter problems half-way through. It's not very good when your backup that spans three tapes has a problem on tape number two.

Luckily for me, I had a second set of backups which worked fine, and a path of incrementals which means that we would have lost a few hours worth of changes from a non-business period. However, the last incremental tape also encountered problems. Not good at all.

Both problematic tapes were written fairly recently, so it may be that the drive itself is going bad, or it could just be a pair of bad tapes. The tapes also seemed to feel better after 40 hours, so as it happens no data was lost.

The whole ordeal has improved our current disaster recovery plan. More scheduling for testing (although all these tapes tested fine the day before!), and most importantly tagging of unimportant data. The really important data now fits uncompressed into a 15Gb DLT. This will greatly speed restores, improve the chances of data recovery from tape (if it ever comes to that), and allow us to keep more copies of important data to allow restore.