issues

Wall of Fire

One of the major problems with building a distributed system is that it's distributed. This means that the parts of the system need to talk to each other. Of course, these days, networks are viewed by most large network operators (e.g. universities) as hostile environments, where anything even remotely risky is split out, preferably into its own little subnet.

The piece of Codd which passeth understanding

I took a good deep look at one of the datasets I'm meant to be linking up today. Actually, it's four separate datasets, but all held within the same database. I poked around a bit, and found this:

Repository Issues: Real Soon Now™

When we started this project many moons ago, we started with 10 identified repositories that we wanted to work with. Of those, two were new systems, being planned or put in. And therein lies the rub… It's hard to write and test code against something that doesn't exist yet (or which is partly set-up and has little data in it). It's even harder to do when the configuration changes under you as they modify their testbed.

Repository issues: The Custom Application

After a project meeting today, it was suggested that I keep a note of all of the "interesting" issues that I encounter with the various data repositories I encounter on the project. So, here's the first of them.

At least two of our repositories consist of custom-built applications. One of them is a fairly large piece of PHP, backed by a MySQL database. The PHP for this repository is complex, and only understood by one person. The database schema is also fairly cryptic, and almost entirely undocumented. To make matters worse, the web user interface implemented by the PHP is actually a GUI, developed with (I think) Google Gears. The only way of querying this data store through an alternative interface is to access the database directly1.