Looks like it might be time for that scheduled service.

Our first assignment for this subject required us to use Perl to build an online job agency (the original specification in Word format is available).  I had an absolute ball working on this, and the appreciation that I developed for Perl is why I sought employment at realestate.com.au for my internship—which was ultimately life-changing.

After this assignment was finished I left it online, and eventually it got spidered by Google.  Some time later I received a cease-and-desist order from the owner of the (now defunct) JobSurge.com service.  Evidently he was concerned about me being a professional contender or something.  I didn’t know whether to be extraordinarily flattered or question the guy’s sanity.

Online demo

Bash the demo around as much as you like.  You are more than welcome to create accounts, but some username/password pairs already exist if you’re lazy:

• centrelink/alexpeters (company)
• zikaiq/123456 (company)
• apeters/alexpeters (job seeker)
• sipsas/123456 (job seeker)

Source code

Download a ZIP of the source code if you’re interested, but heed the following warnings:

• This is not how I would do it now. I wrote this code in 2005 as a first-year uni student.  I’ve been a full-time Perl programmer since the end of 2006.  I post the code here for nostalgia and not as a demonstration of my professional abilities.
• This is not how you should do it now. Most Perl web applications born before 2006 probably look like this (which might be why Perl got dumped for PHP in future incarnations of this subject).  These days frameworks like Catalyst, Template Toolkit and DBIx::Class exist to make things a lot more manageable.  My code will teach you Perl syntax, but that’s about it.  Good Perl programmers don’t mix HTML and application logic, write data to flat files or directly manipulate cookies!

I’m actually half-tempted to re-write this as a Catalyst application just to observe the difference.  I’d be much less averse to that being used as a learning example.

So what’s my biggest gripe with software-based address books as we know them?  Redundancy.  With paper-based address books this is an inadequacy inherent to the medium; we just work around it because we have no choice, and we’re okay with that.

Software-based address books, however, mimic paper-based ones so closely that they too have those now-avoidable drawbacks.  Perhaps this is because people are more likely to adopt something with which they’re already familiar, or perhaps it’s because the programmers of these things just lack the interest in improving on the idea that’s already there.  In any case I’m somewhat dissatisfied.

An address book consists of a number of contact entries.  Typically, a contact has a name, an address and a phone number associated with it.  Sometimes the address book caters for people with multiple phone numbers; this might be done by labelling them as home, work, fax and mobile for instance.

Most address books only offer one address per contact entry.  After all, people don’t live in two separate locations; that’s just silly.  Or is it?  Perhaps.  I know someone who spends equal time living with his divorced parents in two separate houses, but admittedly this is a rare scenario.  People don’t frequently have two home addresses.  People do however frequently have secondary locations: work addresses.

With address books as we know them (and assuming space for one address per entry), what’s the best way to handle storage of work addresses?  We can’t store them as part of a person’s contact entry, because we probably use that for their home address.  Unless we know we’ll never care about their home address, we simply have to create a whole new “contact” for this information.

But what do we call it?  We could put “Jim’s work” as the name, but then Jim’s details are spread across multiple records; we don’t know by looking at Jim’s entry whether we need to look at others to find out more about him.  We could put the business name as the name, but then we have no link between Jim and where he works at all.  If each contact entry can have free-form notes then we can use that to our advantage, but then we’d be using a free-form field for information that isn’t arbitrary, and should be deemed a proper part of the record itself.

If that seems too far-fetched, consider how we currently deal with home addresses.  If you want to store complete information in your address book for a family of five, you need to create five separate entries.  This in itself is reasonable, but because each entry has its own address and home phone information, you are repeating a large amount of common data across all five entries.

What happens when, for one reason or another, their home phone number changes?  That’s five records out of date; five records needing correction.  If you then fail to correct all five, you introduce inconsistencies.

You could avoid this by regarding one of the five people as the “head” of the house, and using only their record to hold all of the home address details.  Then, you could leave the address details for the other four blank and attempt to keep in mind that these people live with the “head” when you need their addresses.  Or you could list their addresses as literally, “see Bob’s entry.”

But then not only do your records depend partially on information residing solely in your brain (somewhat defeating the purpose of an out-of-mind “copy” in the first place), but now they also inaccurately suggest that you don’t know the addresses of these four people.  Or you’re placing usage instructions in your data, which is inelegant.

What happens when you know people with multiple personal mobile numbers?  I’ve never seen a paper-based address book that caters for this ever more common occurrence.  Perhaps on paper you would jam all of the numbers into the one space, or cross out “pager” and write “other mobile” in its place.  After all, assuming that everyone has a pager in this day and age is probably overkill.  With most software-based address books though, we don’t have the facility to overwrite labels on a per-record basis.

These are deficiencies that can’t be avoided on paper, but can on screen.  How, though?

Recognise that people and locations are separate things, and treat them separately.

Give Jim a “person” entry containing his name and his personal mobile number.  Give his house a “location” entry, and give his work a location entry.  Then, create links between Jim and the two location entries.  The links themselves could also hold information telling you what the link signifies; one link is for “home address” and the other is for “work address.”  This information goes into the link rather than the location entry itself, because one person’s work address might indeed be another person’s home address—what if Jim is a butler?

Create five separate “person” entries for the family of five, each containing personal mobile numbers as appropriate.  Then, create a “location” entry for the address at which the five people live.  Then, create links from each of the five people to the location as a “home address.”

Where does the home phone number go?  It doesn’t belong to any one of the five people; as a fixed phone line it belongs to the location itself.  Therefore, it goes into the location entry and not the individual people entries.  Looking at the people entries and following their links to the location entry, it’s easily inferred that those people can be contacted via that number.  Because that number is stored once, when it changes it only needs to be changed once.

How about email addresses?  Many people have many email addresses for different purposes (often just for something completely unrelated to email, like MSN).  I just tried an online contact manager that allows you to store only two emails per person: a “home email” and an “office email.”  Terrible!

How is the problem of multiple mobile numbers (and emails) per person solved?  So far, it isn’t.  These would go into the people entries, but perhaps both the people and location entries would be designed such that they can accept as many numbers (and emails) as one wishes to store, and the user could assign any label they like to each one (“primary mobile,” “secondary mobile,” “line 2,” “MSN address,” “uni email address,” “fax line,” “garage door opener,” etc.).

Yes—garage door opener.  My place of employment is setting up a spare phone number to accept incoming calls from employees as a trigger to open and close the garage door to the car park, saving people from carrying around a remote control (or not being able to open the door at all when there aren’t enough clickers to go around).  Pretty neat.  How would one go about storing this in an existing address book?

So at this point, we’ve gone from a set of “contact” entries containing as much information as possible relating to one contact, to a set of “people” entries, a set of “location” entries and a set of links between them.  The people and location entries hold phone numbers specific to that person or location, with a label specific to each number.  Software that implements an address book in this way would, I think, leave me happy.

But in thinking about how I would go about implementing this, I then realise: is there any major difference between “people” and “locations?”  They both have an identifier (such as “Jim” or “107 Lygon Street”), they both have phone numbers hanging off them and they both link to other things.  So really, they’re just information holders linking bidirectionally to other information holders.

If you reason that no information is lost by turning phone numbers into separate entities and linking to them, all we’re left with is a graph (not to be confused with chart) of tidbits of information, made meaningful via the relationships between them.

And at this point, we’re no longer limited to storing just contact information.  By being able to link anything off a “person” entry we can now store dates of birth, favourite colours, shoe sizes, car registrations…the list is endless.  And of course by being able to link anything to anything, we can even link people together.  What started out as an address book can now also function as a family tree, among other things.  Anything that can somehow be linked back to a person can make an appearance.

So now, we’ve gone from sets of “people”, “locations” and relationships to just “nodes” (small bubbles with tidbits of information, like a name or an address) and “edges” (the relationships between those tidbits of information).

Given any arbitrary node (perhaps retrieved by name), we can follow its edges to other nodes.  In this way we could eventually traverse the entire knowledge base.  What if we just want to see a list of people though?  We’ve generalised away the concept of “people,” so all nodes are now equal in status.

Simple: create a node called “person” or “people,” and link all nodes representing people to this newly created node.  Do similar for “locations,” “phone numbers” and “dates” perhaps.  If you then wanted a concise reference to all the categories that you’ve defined, you could then link all of these to a new node named “categories.”

A graphical user interface could probably incorporate this in a nicer fashion: it could make “category” appear as an adjustable attribute for each node.  Perhaps the interface could then colour different nodes appropriately, according to their category.  It can be seen however that the data structure itself can hold all of this information, and it would; the user interface would simply choose to interpret it in a special way.

It can be seen that because edges (relationships) provide the meaning to the data, there will be many of them—possibly even hundreds—for some nodes.  Perhaps a user interface would want to offer the ability to somehow limit or filter the display of relationships.

For instance, perhaps I could have a view (a predefined set of filtering rules) that tells the user interface to start by showing me only “people” nodes, and when I open them, to only show me links to “location,” “phone number” and “email address” nodes.  I could call this my “address book” view.

What other views could one build?  It depends on what would be useful for the data stored.  A “family tree” view might start with display of just people nodes and limit viewing of relationships to other people nodes.  A “password manager” view might only list website URLs with links to “password” nodes.

On the topic of storing passwords in a structure like this: if you don’t use a different password for every single thing in your life requiring one, this data structure could give you interesting insights.  Relationships between nodes can be traversed in either direction, so you could discover exactly which services use a particular one of your passwords.  In a situation where this password is compromised, you would have a concise list of services that require you to go and change it to something else.

This inverse observation of things obviously applies to anything in the data structure, so you could learn all sorts of new things from information that you already know, simply because you’ve never had the inverse relationships pointed out to you.

So here’s the question: is there any software or online service already in existence that offers anything remotely like what I’ve described above?

The closest graphical equivalent I’m aware of is FreeMind.  Primarily, however, FreeMind “maps” function as trees; hierarchy is enforced whereas in the structure I’ve described above, any hierarchy is merely incidental.  Links can be made between two arbitrary nodes of a FreeMind map, but I don’t know much more about it.  And as software, your data is only accessible from your own computer; you can’t just log into an online service to retrieve something if you’re out and about.

In terms of actual functionality (though not necessarily usability), wikis might come close depending on how they are set up and used.  For instance, a wiki page would serve as both a node and its links; the page’s name/title would serve as the node’s name, and the page’s body would document its relationships with other pages.  Links would be strictly unidirectional unless the wiki software offers “backlink” functionality (a list of wiki pages that link to the currently displayed one), and depending on the quality of that functionality, one might have to visit the other page to understand its relationship.  Creation and maintenance of such small wiki pages would be tedious since wiki pages are designed for much more content.

And so for now, I remain tempted to implement my own solution to this.  I’m always hesitant to act because I don’t want to start and then discover that someone else has already done it, but then I don’t think anything would function quite the way I would like it to.

Should I embark on this development adventure, these will be my considerations:

• Web-based. If it’s accessible from a web browser, your data can be accessed from any computer with an internet connection.
• Simple mobile interface support. I would want to be able to use it from my phone, which has limited screen space and limited processing power.

The system would start out predominantly text-based, even though in my mind I visualise it as bubbles or boxes with lines to other ones.  Further down the line it might be possible to dynamically generate still shots of parts of the data using Graphviz.  Even further down the line, with continued lessons of wisdom from a good friend it might be possible to offer an AJAX-like Flash interface complete with traversal animation.  I would most probably write my code in Perl using the Catalyst web framework, and I’d probably use MySQL as the data store since that’s what my web host provides.

In the meantime however, I guess I’ll just continue keeping all of my tidbits of information disjointedly on sticky notes and hope that I find some other information management solution that works for me.

Finding photos is simple; you just work out what tags are relevant and then form a search query out of them: get me all photos taken within Balwyn featuring my two sisters, myself and a wheel of Brie—but no possums.  If you’ve been prudent with your tagging when you add photos, this works perfectly every time.

I wish the same could be done for music.

So MP3s have ID3 tags, and any decent music software will recognise these.  But they’re not totally arbitrary; you get to store an artist, an album, a title, a genre and some other crap.  If you want to associate something else to an MP3, like “this was a favourite of mine in 2008″ or “this song features Ethiopian lyrics,” ID3 tags won’t help you.

But playlists might.

Let’s say you had a bunch of playlists set up to signify such things, like 2008 Favourites, Ethiopian Lyrics and Never Play These Automatically.  You could then easily inspect these lists to see what songs fall under these criteria, and you could double-click a playlist to listen to them.

Playlists are more of a one-way relationship though.  A playlist points to songs within it.  Existing software, to my knowledge, doesn’t look at a song and tell you the playlists to which it belongs.  Therefore, you couldn’t pick up a song in your collection and automatically be told that you stole it from Dan, it hails from Mongolia and it should always automatically be copied to your car’s music player.  Which means that when you identify a song as satisfying a certain criterion, you can’t easily know whether the appropriate playlist already reflects this.  So you unconditionally add it anyway, and because they’re lists and not sets, your playlists then contain repeated entries.

Authors of some software recognise that most people want this in a more limited sense: ratings.  They then all go about their own way in storing some number of stars alongside each song in one’s collection (it certainly doesn’t seem to go into the ID3 tag).

To me though, such a rating system is pretty useless.  Sure, I could default all my tracks to 3 stars and assign one star to anything I never want to hear but don’t have the heart to delete.  But would I do anything else?  If I started assigning four or five stars to songs I really like at this point in time, what happens when my tastes inevitably change?  The ratings aren’t going to be constant.  I’ll just be twiddling with ratings all the time.

And when I’m looking for songs in Amharic, besides searching for a few obvious artists, ratings certainly won’t help.

I wonder if I’m the only person who thinks this way—that tags could be applied to so much more than just photos—and if not, how long it will be before they can be used elsewhere.

The simple answer according to Debian bug #496497 is that Apache 1.3 has been removed.  Debian Etch appears to be the last distribution to support it.

To me, this is a surprise.  Surely Apache 1.3 is still used heavily in production around the world.  The possibility that it could be at this point of abandonment—the point of not even offering it in packages—didn’t even occur to me.  That’s why I wasted so much time trying to “un-break” my installation.

So in short, if your code base relies on Apache 1.3 and you upgrade from Etch, you’re out of luck.  You need to roll back, or possibly compile and install everything by hand, or start looking at migrating from Apache 1.3 to Apache 2.0.  Bug #482648 offers a temporary workaround which I’ve not yet tried.

I have mixed feelings about this.  In a way it’s probably good that the migration from 1.3 to 2.0 is being forced upon us.  In another way though, how does one propose this migration to higher business powers in a way that doesn’t sound like a complete waste of resources?

At worst, managers reject the migration and developers are stuck with Etch.  But then with the exception of backported packages, all future improvements to Debian are essentially immaterial.  Should a code base ever lock things down to that degree?

I like being able to use the newer versions of things like Eclipse and Ratpoison, but my Edgy experience has otherwise been quite average.  Here are the gripes that are fresh on my mind:

• My computer likes to freeze rock-solid at some point after the screen saver kicks in.  Sometimes I can SSH into it from another computer and restart GNOME; sometimes that doesn’t help and I have to request a reboot.  Sometimes I can’t even SSH in and I have to pull the power plug.
• The text-mode terminals no longer clear the screen on logout, but that’s the least of the text-mode terminal issues that I’ve faced.
• On my computer, the ‘text-mode’ terminals seem to have been changed so that they’re actually graphically based somehow—the font is really weird—and as a result if I try to drop into a text-mode terminal my computer will sometimes instead present me with a screen full of purple-ish and grey-ish noise.
• On the other computer, at random times if you ‘accidentally’ move the mouse to the top right-hand corner of the screen, you get the same purple-ish noise all over the screen as mentioned above.  If you then move the mouse around wildly for a little while everything seems to go back to normal.
• GNOME likes to present some random non-existent floppy drive in the Places menu due to a bogus entry in /etc/fstab, which now seems to take care of business using 128-bit UUIDs.  What the?
• GNOME doesn’t let me assign Ctrl+Alt+Del (or any keyboard combination for that matter) to the Log Out action.
• It no longer seems possible to disable rebooting and shutting down from the login screen without also disabling the XDMCP chooser (and I could swear I was able to do this before, but maybe not…).
• It seems necessary to hack around in GConf to disable suspension and hibernation.
• GNOME likes to open some random number of Home Folder windows when a user logs in.  Sometimes it’s none; sometimes it’s six—often it’s a number inbetween.
• There is no longer a Disks administration applet, apparently due to the fact that no one maintains it anymore.  Great, but no alternative is installed by default in its place.

All in all, Edgy has proven to be quite unusable for all of us here.  I was a total moron to rush off and overwrite a perfectly working system without testing it first.  I suppose I should have acknowledged beforehand that Edgy isn’t meant to meet the standards of Dapper as a distribution since Dapper is a long-term release and Edgy has gone through some substantial under-the-hood changes, but at the same time I feel that Edgy really shouldn’t have been released in this state—surely some of this stuff should have been picked up?

And now to go and re-install Dapper…  I hate sitting in front of computers installing and configuring software for any long period of time…

• Highly recommended reading on the JCF

—and if you love Perl’s arrays and hashes (or Python’s lists and dictionaries) as much as I do, you’ll surely fall hard for the JCF like I did.  One thing that I wish I realised earlier though: TreeSets can’t contain two items where item1.compareTo(item2) == 0, even if !item1.equals(item2).  So watch out there or you’ll be chasing your tail for hours like I was.

I’ve also discovered that I really like Java GUI programming.  Our Software Engineering 1B assignment requires us to code a decent batch of GUIs and custom controls:

Screen shot of one dialogue from our Software Engineering 1B assignment

It seems that GUIs can get much prettier and much more functional once you understand how to use GridBagLayouts; if you’re stuck doing Java GUIs then learning to use them is probably quite worth the effort.  More functional? Yes indeed—a fully resizable dialogue is much more functional than one with a hard-coded size, and GridBagLayout seems to support this quite nicely.

I also finally sat down and worked out how to use Java’s serialisation.  How I wish I took the time to do this earlier, especially before this semester started—coding your own data loading and saving routines is so mundane (and evidently completely unnecessary).  Oh well.

Anyway, I’m now convinced that when I get around to working on some of the extracurricular projects that I have in mind (if ever), Java will be the perfect weapon of choice.