fornax.net

Okay, last post on service for a while, I promise

This sign is on a pub near the Ealing Broadway tube station.

I can't sleep, so I figured I'd wade into the inline documentation debate.

Travis states that programming languages are declarative, so code, along with associated unit tests are enough to define what the code does, as well as provide examples of how to use the code.

Well, I agree with that.

However, that doesn't mean that inline documentation is therefore a "bad thing". Tobias has pointed out a couple of reasons why that's the case. I can think of a couple more, too.

Cathy and I went to Brugge over the Easter long weekend. No complaints

Photos are up in the gallery.

Speaking of customer service, I returned some faulty headphones at Micro Anvika last week.

Normally, I'd do everything I could to not shop there - I can't stand the stores, due to their appalling sales service. No one in the store is interested in helping you, and they certainly don't know their products. (They are, however, better than Currys.)

However, I got some vouchers as a gift about almost a year ago, and so had used them to buy some headphones. The right headphone wasn't working, however, so I took them back.

I have to say, I was really impressed. Sure, it took 20 minutes for them to locate a new set, but they swapped them over without a word of complaint (or the usual expected accusations that I wouldn't know if the thing was broken or not), and they issued me with a receipt for another 12 month warranty.

Now, that's how it should be.

I said recently that we were never rude to our customers back when I was working at Adelaide Uni.

However, I must confess that I did once lose my temper, and while I didn't exactly shout, I did raise my voice and speak in a somewhat unkind way.

I think, however, it was justified. The person in question came in, and asked to use a computer. About five minutes later, they asked for some help, because their files had "disappeared" from their disk.

So, I went over, and took a look. The first thing I did was to check in the file manager that the disk really was empty - I saw plenty of cases where an "empty" disk was simply a symptom of the customer not knowing how to display the contents of the disk. That's fair enough - not everyone knew how to do that on a computer that wasn't set up the same way as the one they would normally use.

However, when I did this, the floppy disk drive made an odd noise. Not the kind of noise you expect when reading a disk, and not that kind of "chunking" noise it makes when a disk's FAT is corrupted. It was a different noise. Kind of, well, slow sounding. I ejected the disk. It was sticky.

It turns out that they'd had their disk in their bag along with an icecream, which had melted. I suggested that perhaps they should have given more thought to how appropriate it might be to put a wet, sticky, icecream covered disk into an expensive computer.

Only, perhaps not as kindly as that.

I spent something like seven years at university, and for most of them, I worked for the Adelaide University Union's Computer Resource Centre.

At the time, the University of Adelaide didn't provide any kind of centralised, standardised computing facilities - it was up to each faculty to provide computers (as, and if, required) for their students. As a result, the Resource Centre was the one place where students who struggled with technology could turn to for help, and for specialist services like document binding, cheap photocopying onto overhead transparencies, and helping PhD students recover their one and only copy of their dissertation -- due next week -- that they have saved on a $1 floppy disk that's now gone bad.

Apart from the satisfaction of helping other students, and the fact the job paid my rent, the best thing about working there was the camaraderie with the other staff. We had these little rituals that we'd all follow - like using certain phrases to relieve the stress of dealing with some of our more challenging clients (without ever being rude, of course!). One of these rituals was to always correct people who came with a stack of printed sheets, and would ask "Ummm, can I get this binded?" We would always reply "No, but you can get it bound."

As a result, seeing this in the Metro recently made me a little nostalgic...

I was extending the Openads database abstraction layer last night, to ensure that creation of databases works correctly. I'm no PostgreSQL expert, but it seems that it won't let you issue DDL/DML commands unless you have connected to a database first - so if you want to create a database, you have to connect to a different, already existing database first.

Luckily, the PEAR::MDB2 library will connect you to the "default" database for a database server if you specify no database name in the DSN. (For PostgreSQL, this is the "template1" database.)

This was all well and good, until I tried to then connect to my newly created database, and all I'd get back was the previous connection to "template1". It turns out that the MDB2::singleton() method compared the DSN array of the database you want to connect to with any DSN arrays of previous connections it has made by using the array_diff() function.

Alas, when creating a connection with no database name results in the DSN having the boolean false for the database name field - and because other items in the new DSN array were also false in my case (for example, the "mode" of the connection" was false), the array_diff() function returned no differences. Oops!

Changing to the array_diff_assoc() function solved the problem.

It's been all systems go at Openads central this year. One of the big jobs we've been taking on is dealing with our database schema. Managing database schemata is actually a tough job, if you want to do it in a agile way. (No one actaully designs their database schema up front any more, right?) There are several great books on the subject, though, and based on those ideas, we've produced a white paper outlining a system we're writing for managing database schemata for PHP, in the same vein as Rail's Migrations.

As part of this project, we've decided to use PEAR::MDB2 and PEAR::MDB2_Schema to manage the jobs of reading in our existing database schemata from existing databases, to then be stored in XML files, The same two PEAR packages will then be used to prepare the SQL DDL/DML commands required to create new databases when installing Openads, or to modify an existing Openads database when upgrading. Of course, the DDL/DML created will all be based on XML schemata files.

If you've ever used PEAR::MDB2, you may be aware that it works by storing database schemata information in an "internal" MDB2 datatype. This datatype needs to be converted into database-specific commands when talking to a database, obviously. But if you're reverse engineering a schema from an existing database, you also need to be able to convert an existing database "nativetype" into the appropriate MDB2 datatype.

However, this is where we've run into a few issues.