Useful stuff I don’t trust myself to remember

Lindsay (eldest son) and I went Orienteering at Oakview, which is a property about 20km west of Armidale on the Bundarra road. We did a 3.5km “Short Red” course.

The GPS was carried to track our path. I think this is becoming a common enough sight at Orienteering events these days that people no long immediately assume you’re cheating.

Back at home the GPS is plugged into the (Ubuntu) PC via its own serial cable and a USB-RS/232 converter. To upload the track data:

gpsbabel -t -i garmin -f /dev/ttyUSB0 -o kml -F FILE.kml

There are usually some breaks in the path due to the device losing contact with the satellites. Currently a text editor is used to rudimentarily merge them into a single path. The resulting file can be imported into Google Earth to (re)view the path.

Heavy overnight rain swelled the creek on our property and we went for a walk with the digital camera to take photos. Three videos of the flow were also taken.

Son #1 seemed a bit bored so he was set the task of finding a program (for Ubuntu) to stitch the three videos together into one – along with some static text between each one. He found Kdenlive and it, and he, did a brilliant job:

The interface has to watch system A and send transactions to system B. Normally, in the Oracle universe, there would be 2 ways to do this:

Use database triggers on System A’s tables to trigger transactions

Keep a separate record of the state of System A’s tables and compare it to the actual state – looking for differences which trigger transactions

The drawback with the first method is the performance hit of the database triggers on System A, as well as the possibility they might introduce errors into its processing.

The drawback with the second method is that replicating parts of the watched system is, well, just plain yucky.

Fortunately, in the case of this particular interface, System A uses a column called UPDATE_ON in its major tables. This column is updated whenever there is a change in the row. This means the interface just has to look for rows where UPDATE_ON is greater than when it last looked. It’s a much lighter touch than the other methods.

I encourage Data Architects everywhere to include an UPDATE_ON on their major tables in their designs – even if it’s usefulness isn’t immediately apparent.

In my (copious – I wish) spare time I contribute in minor and probably annoying ways to a project called INX which stands for “Is Not X” (and is pronounced ‘inks’). It’s a Linux distribution designed to teach the command-line and some of its tools in an easy and fun way.