Watch where you put the ejector seat button

Jeff Attwood explains, as only he can, Fitts Law.

What I like about this post is that he uses Google's Gmail and Wordpress.com's post editor as examples. The former as bad and the latter as good. Both of these I use regularly.

While what Jeff says about these interfaces is correct according to Fitts Law, I would ask him - why so clumsy with the mouse? Click what you mean to click... I kid of course.

In defense of gmail, the buttons are all large and clearly marked. Though I can see where having Archive as a button and Report spam as a smaller less easy to click text link would make miss clicks harder. Wordpress.com's counter example of the Publish button vs. Move to trash illustrates this point beautifully.

Having said all that, I'm sure I'll miss click for weeks on end now.

17.99 a month for the WSJ on the iPAD - really?

I don't know, 17.99 a month for Wall Street Journal on the iPAD seems like a lot to me. Of course, what do I know, I pay 12 for CABLE TV.

199 out of 200 programmers can't program?

Can it be that 199 out of 200 programmers can't program?

"Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever."

Maybe so. What if you could screen them by watching them type a program over the web? Now you can with See[Mike]Code (not this Mike). Use this while you talk to the candidate over the phone... Nice.

Jeff Atwood explains how this works. The recommendation is to keep it short - the program you ask for should be about 10 lines long. You'll be amazed how many are stumped.

finding aging disk hogs in a linux environment

Here's a common problem - I'm working along running tests and bam, disk is full - all running tests fail when the simulator can no longer write to disk. I won't get into the cost benefit analysis of simply adding more disks to the project - that's not my thing. I'm going to talk about how to find old directories so that the owners of those directories can be prompted to delete stuff they don't need.

In this case, I've decided to find directories in two categories:

• directories older than 60 days
• directories older than 30 but less than 60 days.

Looking through the interwebs I found that there are many examples of how to do some of this but no full example. Here is what I came up with:

find <start path> -mtime +60 -type d -maxdepth 1
  | grep <directory of interest> | xargs du -bs |
  sort -rn"

The above uses find to look for directories under "start path" whose age is 60 days or more (technically counting from yesterday). Note that mtime is "modified time", which for directories is loosely the time it was created. This is especially true when that directory is at the top of a large tree. The find result is piped through grep to narrow it down to directories I know contain lots of data. This in turn is piped to du to count how much data and finally to sort to reverse order the list.

To find data between 30 and 60 days, simply replace the -mtime 60 with:
 -mtime +30 -mtime -60

In projects that take many months, like ones I work on, there are many people who, for whatever reason, some legitimate some less so, keep data around for what seems like long after it is useful. These commands, which stand on other find examples I came across, help me determine who owns the oldest and largest data.

Now if only this was actually my job!