During my late teens and early twenties, I lived in a series of houses with Andrew Niland. We went to the same bars, had the same friends, and were into the same things (computers, body modification, “banned” films, industrial music).
In fact, I ended up going out with and eventually marrying his ex-girlfriend, Bronwyn, after living in the same house as the two of them for more than two years.
After learning enough from him and experimenting enough that he was confident in his abilities (it didn’t take long; Andy was always brilliant, and very quick at learning what he was interested in), Andy left Ireland and went to Canada, where he ended up working for the Sacred Art tattoo parlour in North Bay, Ontario.
By that time, we’d lost touch with each other over after an argument where we all ended up moving house (we drank a lot, were young, and seriously, don’t go out with your best friend’s ex-girlfriend while living in the same house as him because that’s a recipe for disaster).
Andy had been in court in Ontario over a really stupid law which claims that some body modification is ok, but others should be regarded as “aggravated assault”, even though it’s all done consensually.
A few weeks ago, he vanished. On August 4th, he was last seen at 6.30pm. When he was missing for a while, his apartment was searched and it was found that he’d left his wallet there. A lot of fuss was made over this online, but this was not unusual for Andy.
Yesterday, Andy was found. The police won’t confirm it’s him, but how you could not identify a guy who has distinctive piercings and huge stars tattooed on his forehead, is beyond me. Besides, people close to him have confirmed it’s him.
An autopsy is to be held on Monday. At the best, this was a camping accident. At the worst, it was murder. We’ll have to wait and see.
Update (Sep 2): Police in North Bay have said that “there is no foul play suspected“. As usual with police, they have not offered any of the other pieces of information which people would really like to know, like “what actually happened?”.
I was just looking at scales and trying to memorise how many sharps and flats each key has.
In short: count the sharps. multiply by 7. divide by 12. add the remainder in semi-tones to C. that’s the key. For flats, subtract the remainder from C.
The usual way to do this is to use the “circle of fifths” diagram:
In that, you count clockwise from C to find keys with sharps in them, and anti-clockwise for flats.
This key has 3 sharps, so you count three keys to the right of C, and that makes it A major.
If you want the minor key, then do the same, but then subtract 3 semi-tones from it, and you get F#m.
Now, what if you’ve a crap memory like me? There’s no bloody way I could remember a complex diagram like that.
Simple – let’s look at another variant of the diagram:
In this diagram, in order to figure out the key, you follow the lines; anti-clockwise for sharps, and clockwise for flats. For a key with 3 sharps, you start on C, then follow the lines 3 times, through G and D to A.
Yes, it’s another diagram, but look at the lines – they’re perfectly regular, which means that a formula can be built from it.
The formula is simply this: sharps * 7 % 12. Then add the result in semi-tones to C and you get the answer.
1 sharp: 1*7=7. 7%12=7. 7 is G
2 sharps: 2*7=14. 14%12=2. 2 is D
3 sharps: 3*7=21. 21%12=9. 9 is A
For flats, subtract the result from 12 to get the answer:
I debugged a problem for a friend of mine over the last day. He had installed bbPress on a server which also had WordPress on it, and his WordPress site just suddenly stopped serving comments and pages, and started killing the database server instead.
In the end (after a day of considering this and that and a lot of head-scratching), it turns out that the bbPress installation had been done using the same table prefix as the WordPress one.
See, when a web app is installed, it usually installs a load of database tables. The way to avoid these tables overwriting each other is to “namespace” them. The most common method is to simply place a unique prefix in front of the table names.
For example, WordPress and bbPress both have tables for posts. The default installation is to name them wp_posts and bb_posts, respectively, using wp_ and bb_ as prefixes. KFM does that as well, using kfm_ by default.
In the current case, what happened is that the bbPress installation was done using wp_ as the prefix, and some of the WordPress tables were then changed to match what bbPress expected.
In the case of wp_posts, the field post_status was changed from a varchar holding values such as “publish” or “draft”, to a smallint holding just ‘1’ or ‘0’. This had the immediate effect of unpublishing over 6000 articles on the blog. (aside: oi, WordPress – why are you not using enums?)
A few hours, spread over a day or so, were spent figuring that out then fixing that.
So, what actually happened? Why was wp_ used as the prefix?
Let’s look at the WordPress installation.
When you install a copy of WordPress, the first thing you do is fill in the database details. This is the field for the prefix:
Notice the name, “prefix”. A lot of browsers these days include auto-fill, which is sometimes useful. When encountering a form, the browser would fill in the details that it already knows, such as email address, etc.
The problem, though, is that sometimes, autofill might fill in details that really should be left blank or at their default states. An example of this is in phpBB, the popular forum software – whenever an admin goes to edit a user’s details, autofill in Firefox tends to fill in the “password” field in the user form, but it really shouldn’t do that, and can potentially break a user’s account.
This is actually quite easy to fix, though, in the installer – the installation program just needs to change to use a different name for its input box:
Now the value should only be autofilled by values recorded from other WordPress installations, and should not affect future installations of other software.
The thing is, this is not what broke the system I was fixing.
Let’s look at the bbPress installation.
When writing bbPress, more thought appears to have gone into the installation. The only fields visible here are database name, user, and password. These are the most commonly changed details, so are shown prominently.
There is an “advanced” checkbox. When clicked, this shows fields that should only be changed if you are sure of what they do:
The fields shown here rarely need to be changed. They include database host, collation, character set and table prefix.
The default character set is UTF8, and I can’t imagine why anyone would need anything other than that (that also covers collation). My own opinion is that these ones shouldn’t even be in advanced – they should be hard-coded.
There are not many reasons why the table prefix would ever need to be changed, but in the case I was troubleshooting, the database host was held on a separate server to the site itself.
So, because the database host needed to be changed, that explains why the admin opened the Advanced section in the first place.
If the prefix input box was named “prefix”, this would be the end of the story – I might have assumed that the problem was autofill (as I did for a while), and suggest the above solution to them.
But, the authors of bbPress have obviously come across the autofill problem themselves, because they named their prefix button “bb_table_prefix”, exactly as I suggest every installer should do (now do it with WordPress, guys!):
In this case, I believe it’s human error. What follows is my own guess at what happened, in hind-sight and without the benefit of watching the proceedings in person.
I think what happened is that our admin’s techie had left some notes about the settings used for the WordPress installation, including database username, password, etc. Then the admin had gone to install bbPress, in the correct assumption that installation should be straightforward and compatible with WordPress.
However, I believe the problem is that the techie had left a note about table prefix, but had not explained to the admin that all the other settings must be as written but the prefix must not.
The admin had simply filled in what was written, and bbPress did what it does, and changed WordPress’s database tables.
So, who’s at fault?
I believe the problem here was a misunderstanding – to all of us who have done a million installations of a thousand different software applications, it’s very obvious what the table prefix is, and what it does. However, I don’t believe I’ve ever seen it written down, or the dangers of using an existing value.
Let’s look at the bbPress installation again, this time with the ‘?’ expanded:
It says “If you are running multiple bbPress sites in a single database, you will probably want to change this.” While literally correct, this actually doesn’t explain what the prefix is or why it should be changed. And most importantly, it does not say “This value must be unique in your database, or it may overwrite your existing database tables.” The help text in bbPress’s case does not actually explain the danger of using existing values for the prefix.
The techie is also at fault. If leaving notes for someone, always make sure to explain anything which needs explaining. In this case, it should be something like “If installing new software, use these database access details, but make sure that you do not use these database table prefixes.” In fact, the table prefix should not have been in the notes at all – if the value is a default, then don’t write it down.
The admin is also at fault, for following the notes to the letter and filling in the prefix where the default value was actually perfect. I won’t fault him for installing software when the techie wasn’t at hand to point out mistakes, as there really shouldn’t have been any – the prefix error was actually quite easy to make; it just happened to have devastating effects.
However, these are all minor faults. They’re all easy mistakes to make, and it was the combination of all three that caused the error.
Having said all that, I realise that I have someinstallers to check now to make sure I follow my own advice!
Based on some work I did for chapter 3 of jQuery 1.3 with PHP, I’ve created a plugin to encapsulate the remote selectbox trick.
The idea of this is that in a lot of cases, there may be huge select boxes in your forms, but the selected value might not ever need to change. For example, if you have a country list, and you’re pretty sure that the user is in Ireland, then it might be pointless to have a full list of countries in there if it’s unlikely to be changed.
Notice that when you click the select box, it’s populated with countries. However, the source of the page does not include those countries in the HTML. So how does it do it?
How it does it is to add a focus event to the selectbox, which populates it only when it’s actually about to be changed. In this case, the missing options are in a file named countries.html which is 9k in size. So, by using this trick, we’ve saved 9k in bandwidth. Multiply that by the amount of large selectboxes in your forms, and it could be considerable.
All that’s needed is to include a single option in there to indicate the default, then run .remoteselectoptions() on the selectbox, telling it what url it should grab the options from.
In case you need to do some checking on the server-side based on the current selected item, the script calls the option source with a selected GET parameter set to the current selected option’s value. You might set the url to a PHP script for example, which would build up the option list based on that selected item.