Sprint EVDO Mobile Broadband on Ubuntu

So I just got a Sprint EVDO USB stick to allow connectivity when there's no WiFi around. I did some quick Google searches and it looks like it's supported. Little did I know how well :) I plugged in the device to a USB port and the kernel started loading appropriate modules and gave me the /dev/ttyUSB0 through /dev/ttyUSB3 ports. At this point I thought I'd pick it up at home.

I couldn't resist one last Google search, however, and it was worth it :) While the box for the device (a Sierra Wireless 598U) doesn't mention Linux by name, Sprint provides a full installation guide for Ubuntu (Fedora and others are there too). I was very pleasantly surprised. Everything just works!

Multi-Column Database Indices in Sqlite3 and Ruby on Rails

In my previous post about database indices in Sqlite3 and Ruby on Rails, I'd observed that Sqlite didn't seem to support multi-column indices properly. It turns out that while Sqlite does support them, I was using syntax in my Rails model which had the effect of ensuring that both the columns in my index were checked separately for uniqueness. Assuming you have the category_id and name fields in a table such that the combination of those two fields has to be unique, the correct way to do multi-column indices is as follows:
In your database migration,

add_index :contests, [:category_id, :name], :unique => true

In your data model,

validates_uniqueness_of :name, :scope => :category_id

That last line in the model is key. Syntax similar to the add_index line above won't work when using the validates_uniqueness_of validator.

The Magic SysRq Key - Commandline Edition

So earlier today I was stuck trying to bounce a remote host that had a Software RAID volume. It turns out for some reason (I still suspect a faulty volume in the RAID1 volume) nothing was able to write to the mounted RAID volume. All processes kept getting hung and drove the load up to 25. Responsiveness was still good since this load was actually due to I/O waiting processes that kept getting some CPU time and not CPU-intensive processes trying to share a couple of processors.

In any case, after manually failing the partition that was causing problems with the RAID volume I still wasn't able to bounce the box since the RAID volume won't stop or sync and actually halted the shutdown process. I thought about the magic SysRq but realized I was ssh'ed in and that won't work. For some reason I didn't think of searching for a way too invoke the magic SysRq processes from the commandline. I looked for a way to force a shutdown and found this blog. It worked like a charm!

Intriguingly enough, when the host came back up the RAID volume remounted and both partitions that formed the RAID volume were fine as reported by mdadm. What's more all seemed well with the mounted volume and I was able to read/write to it just fine. I'll be keeping an eye on that for a bit.

A Scientific View on Database Indices

I've been playing with Ruby on Rails by seeing how easy (or difficult) it would be for me to re-write an existing mod_perl2 application within RoR. While the original application uses PostgreSQL as its backend database (numerous reasons but the top few are: timestamptz, multiple columns in a table that can default to now(), support for transactions - even nested ones), I decided to use sqlite3 for the initial prototype of the application before it grew beyond 2-3 models.

It seems that either sqlite3 or RoR 2.0.5 doesn't support multi-column indices on a table. One of those two converts a single two-column index into 2 one-column indices - not quite the behavior I wanted. I'll try to switch to PostgreSQL to see if the behavior re-surfaces.

While I was scouring Google for sqlite3's limitations, however, I came across this interesting article that details the kind of scientific analysis that should be conducted on your data to determine the order of columns in a multi-column index. Very informative.