talideon.com

Platitudes and inanities

Entries for January 2007

January 1, 2007 at 3:35AM Nappy yew hear!

Ach! My stomach’s in knots! Hope ye all had fun!

January 18, 2007 at 2:18PM I’m not dead...

...I’ve just been living in Carlow. [smile]

While I haven’t been shouting it from the rooftops or anything, I haven’t been hiding the fact that I started working as the lead developer at Blacknight Internet Solutions about two months back. My quietness here is due to me not having got around to organising a broadband connection in my house, something I hope to be fixing pretty soon.

January 18, 2007 at 5:24PM On speaking in my personal capacity

In case anybody, and I’m not naming any names here, is confused, whenever I express something here or elsewhere, I’m expressing it in my personal capacity. Don’t assume that I speak for any organisation I’m affiliated with unless I make it completely clear that I am speaking in an official capacity. Capisce?

January 29, 2007 at 9:36AM No Pinnocchio Relations

Here’s something about relational database design I, and I don’t believe I’m alone in this, have a tendancy to forget: Pinnochio relations are bad.

But what’s a Pinnochio relation, you ask? You know when you have some data that you want to store in a table, but doesn’t appear at first glance to either fit into your existing schema or deserve to be treated as a proper relation, so you just serialise it into, say, JSON, XML or something and toss it into a column? That’s a Pinnochio relation: one that’s almost but not quite real, but with a bit of effort can be.

Here’s a simple example from something I’m working on at work, obfuscated, of course. The database as a relation called people, which, as you might guess, holds a list of people. Here’s what it looks like:

CREATE TABLE people (
    id      INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
    name    VARCHAR(64)      NOT NULL,
    email   VARCHAR(64)      NOT NULL,
    address TINYTEXT         NOT NULL,

    PRIMARY KEY  (id),
    INDEX ix_email (email(8))
);

What complicates this picture is that the system takes plug-ins that talk to other systems and these plug-ins need to store data about each person in the people relation. However, this data is somewhat ad-hoc, so what do you do?

There are a few obvious answers. Firstly, you could add a bunch of placeholder columns to the table and allow each of the plug-ins to take a range of them for their own use. But that’s not very smart. Secondly, you could store all the data as a serialised associative array, which is what I did initially as I never expected to have to do anything other than pull it out of the table occasionally. Thirdly, you could create a table with a primary key consisting of the person’s internal id and the name of the key, along with the associated value; essentially an associative array implemented in a table.

Of course, if you want to do anything more than store and retrieve this ad-hoc data, everything’s ok. But what if what you want to do something more interesting with the data, such as, say, doing a lookup on it, or performing some kind of analysis on it? You might be able to do it, but it’ll be hard and error-prone. You’re kind of screwed, really.

Though data like this doesn’t appear to be relational, it really is. One just has to get out of the habit of looking for all the relations, no just ones that map onto objects in your domain model.

In my case, I discovered that some housekeeping code I needed to write needed to be able to do lookups on the value of some one of those bits of ad-hoc data. The solution was to treat the data associated with a particular plug in and person as a relation of its own, which gave me a relation something like this:

CREATE TABLE randomplugin_people (
    id   INTEGER UNSIGNED NOT NULL,
    ref  CHAR(4)          NOT NULL,
    code INTEGER UNSIGNED NOT NULL,

    PRIMARY KEY  (id),
    UNIQUE INDEX ix_ref (ref)
);

Now I can do quick lookups on ref to retrieve the associated person, join it to get all the associated data, or whatever I want, and all because I recognised the data as a proper relation all of its own.

January 29, 2007 at 9:38AM Stupid ROX Hacks: Play in Background

Sometimes I want to play a tune in the background without having to open up a full-blown music player or media library, say, a promotional one I picked up on I Guess I’m Floating, Nialler 9, or some other music blog. After getting sick of having of having my playlist filled with junk I deleted long ago, I knocked out a short, if a little overly paranoid, shell script for doing just that. Here it is:

#!/bin/sh
#
# Play in Background
# by Keith Gaughan (http://talideon.com/)
#
# Starts a music player, killing the currently playing one if it exists.
#
# Copyright (c) Keith Gaughan, 2007.
# Freely redistributable under the BSD license.
#

# If /bin/sh isn't bash...
if [ "$UID " = " " ]; then
	UID=`id -ru`
fi

PID_FILE=/tmp/play_in_background.$UID.pid
# It's only safe to kill the process if it's us who logged the PID the
# last time.
if [ -O "$PID_FILE" ]; then
	LAST_PID=`cat $PID_FILE`
	kill $LAST_PID
fi

for PLAYER in mpg321 mpg123; do
	LOCATION=`which $PLAYER`
	if [ -x "$LOCATION" ]; then
		$LOCATION "$@" &
		break
	fi
done

# Save the PID of the player just spawned.
echo $! >$PID_FILE

To set this up in ROX, right-click on an audio file and select Customise Menu... from the file menu. A filer window should have popped up in which you can put simlinks to the script or drop the script itself into. Either way, drop it in there, give it a suitable name, and make sure it’s executable. It should now appear in your menu.

If you want it to run whenever you click on an audio file, again, right click on an audio file and select Set Run Action... from the file menu. Now drag the shell script from the filer and onto the dialogue box, and click Use Command. And now you’re set!

I give no guarantees that this’ll run on any other Unix or *nix clone besides FreeBSD, and if you use one of those other uncouth filers such as Nautilus or Konqueror, you’re on your own as far as setting it up goes... [smile]