Quick letter about electronic voting

Electronic voting has been thoroughly shown to be unreliable and manipulatable. As a professional software developer, I can attest to the difficulty of creating systems that cannot be tampered with. I can also add that many reports I have read of defects in voting machines have suggested a lack of competence in a task that would be difficult for the very best developers.

On the other hand, voting techniques that leave a paper trail give us a backup plan when machines fail us. It is long past time to add laws that encourage and aid officials in implementing paper trails for our elections. Inaction makes our elections look illegitimate, even if there is indeed no manipulation at all.

Managing to capacity

Jason Yip says managing to capacity is a prerequisite to other work on process:

When going down the path of Agile/Lean, there are two main topics:

1. Learning to manage to capacity
2. Learning how to improve process capability

If you can't accept the first point, the second point won't make any difference.... in fact, because of overburdening, you'll make the second point harder.

assert_efficient_sql

The ever-brilliant Phlip Plumlee with a way to lint SQL "pessimizations":

assert_efficient_sql - O'Reilly Ruby

To ensure your test cases call efficient MySQL…

def test_my_case
 assert_efficient_sql do

   # just wrap them in this block!

 end
end

The assertion intercepts and copies out your MySQL SELECT statements, then calls EXPLAIN on each one, and inspects the results for common problems.

The goal is test cases that resist database pessimization, even as you change your data relations, to add new features. If you run your tests after every few changes, you can easily detect which change broke your database’s indices and relations.

This article is a reference for this assertion’s options.

Phlip is soliciting help with implementing this feature across more database engines.

Four busted laptops, one measly task

Good friends of ours from out of state are staying with us tonight. They're fellow geeks, and he's a fellow developer.

Our task: copy 1.5 MB from a CD to his wife's MacBook.

Our challenge: his wife's MacBook does not currently read optical disks.

Tools available to solve the problem: a PC laptop with a failing hard drive, my work MacBook Pro that also has issues with optical disks, our family iBook that works but has no screen backlighting at present, and the destination MacBook, which, again, isn't reading optical disks.

Solution: I fortunately had SSH enabled on the iBook before its backlight went out. I logged into that, and inserted the CD into the iBook. Checking in /Volumes, I found that the CD wouldn't mount until I logged in to the GUI. I'm sure there are dozens of ways I could have done that from the command line, but it went along with the silly mood of the whole thing, so I went ahead and logged in blind.

Sure enough, during the GUI login process the CD appears in /Volumes. We make a tar file and my friend copies it down.

Easy peasy.

PS: Oh, and the eject key on the iBook didn't cause ejection. Turns out a quick drutil eject does fine.

Track down warnings in Ruby test runs

Got warning or other spew in your Ruby test runs? To track down the source you can have a setup method output the test name:

p name

This makes it very easy to track down the source of the unwanted output.

This works because each test run is its own instance of your TestCase subclass.