Software feature shout-out

As a software developer, I’m keenly aware that the tools we create both empower and frustrate those that use them. I guess after what feels to be four or five internet lifetimes by now, I’ve gotten used to adapting to the features – and the quirks – of whatever software packages I use myself.

My development, both at work, personal, and contract deals with MySQL. And for a long time, I’d run a local instance of phpMyAdmin so that I could get at the DB. And I’m grateful for phpMyAdmin – but most of the time I just need something that will help create db’s and users, and give me a nice interface and history for queries.

And that’s when I started using Querious for the Macintosh. If it all it did was give me a native application to do the routine stuff, and a query window, I’d be fine with it, and it would be worth the $30.

One feature in particular though that stands out, and that has come in amazingly handy is their CSV import. To assist some friends and colleagues of mine in a simulated baseball draft league, I wrote a web app that manages the baseball draft – and allows custom rankings of players for individual league owners. Importing that data though involves trying to get an excel spreadsheet of stats into the database – and for anyone that’s done this, you know it can be a major pain to line up stat columns and types with the db columns.

Not so with Querious. The app has what might be one of my favorite features in a software program ever – a drag and drop association of import columns to db columns:

I don’t have to do this a lot, but man when I did, this came in extremely handy.

The application also has the built in ability to create ssh tunnels for connecting to remote systems, which is also an extremely handy feature.

It’s a great feature, and a great app, and one of the most useful tools I own. A big thanks to Araelium for developing it.

A Story of a Bug

It started, as it should, with the belief that it was my own bug.

I’ve been working for the last few days to generate daily summaries of the activity flowing through our tools. It’s nothing earth shattering, but it’s been a stepping stone to understand a little bit more about the Rails framework – and gave me the chance to begin experimenting with the Google Visualization API. Toward the latter part of the week, there was something a little odd with the “total valid” numbers with the daily account creations – I had made data changes to make sure I had some idea when accounts were vouched for and when they had been retired – so I naturally assumed it was something I did. I even went back and modified the model to make it more consitent with it’s peer models. And kept running the script that produced the daily stats in the Einstein-esque insanity of the doing the same thing twice and expecting different results. After about a dozen combinations of DATE(date_column) comparisons – I went to google, because I knew by then I was either going crazy or this was a legitimate “it’s not my problem” bug.

Which led me to this mysql bug. Reported July 19, 2007. Apparently introduced in MySQL 5.0.42 (May 2007) when the DATE comparison changed from strings to ints. Fixed within two days as part of 5.0.48 (Released August 2007).

But guess which mysql package Red Hat EL 5 (well, RHEL5 update 2) provides? – right, in between. It’s MySQL 5.0.45. And the forthcoming RHEL5 update 3 release doesn’t update MySQL either.

Development and System Administration is a weird, weird world. I use RHEL, not for support (I’m not even sure we have support with the University contract), but to have some degree of patch level stability that’s slightly longer than the fedora releases (and at the time I went to RHEL, Fedora was still dealing with it’s Red Hat transition) – but that stability comes with the price of things like this. I already use my own Ruby to get beyond the base install, but configure, make, make install for one piece of core software is a little different than dealing with it (or MySQL-supplied RPMs) for other software.

I’m glad the open source world gives me that choice, but open source + my labor + thousands of moving parts does give provide the reality that even when a bug is fixed two days later, in the open, patchable by everyone – that sometimes you can find yourself over a year later modifying your own DATE queries so that they don’t include nulls.

So that’s the overall summary of the post I guess – part of it to go into google that if you are getting odd MySQL DATE function results on MySQL 5.0.45 on Red Hat Enterprise Linux (RHEL 5) – it’s a bug. And it’s fixed. But not included in RHEL 5. And if you aren’t getting odd results with DATE comparisons – you probably don’t know that you are.

And maybe one part as a lament to that inevitable ongoing intersection of thousands of moving parts in every environment, not the least of which ours. And you trade off replacing mysql on multiple servers and just turn nulls into zeros (which then breaks your signup form that desparately needs an overhaul) – well, because it seemed to make sense at the time.

And people say you don’t use probability after college.