Free AWS Book Chapters

In my email this morning, from Amazon:

*Free AWS Book Chapters*
Download a free PDF copy of the first three chapters of AWS Evangelist Jeff Barr's book, Host Your Website in the Cloud at http://www.sitepoint.com/books/cloud1/samplechapters.php. Jeff's book covers principal AWS services including EC2, S3, SimpleDB, CloudWatch, and RDS. The book makes use of the AWS SDK for PHP and includes plenty of working examples. Find the book on Amazon.com: http://www.amazon.com/Host-Your-Web-Site-Cloud/dp/0980576830

If you went to BLUG's AWS-Installfest-in-the-Cloud event, this ties right in. Good book, too.

Sort of Balkan Dancers

Another forehead-smacking episode of "Why didn't I think of that?"

HT: Chuck Hipschman

23-and-me one-day sale

23-and-me gives you information about your own DNA. I just became a customer. They're running a sale.

Normally, it's $199, plus a $9 a month subscription to updates for a year (after which you can continue to subscribe or cancel).

Today only: you still have to subscribe, but the $199 is waived, so it's about $100 instead of about $300. I'll find out whether the subscriptions are worth it over the next year.

Note that Federal bureaucrats want to shut them down because they think your DNA is something that only an M.D. should explain to you. Even without that, though, I'd have still bought it.

Handling Failure

Here are two coding styles for handling failure. I read a lot of code that uses the first. I always use the second.

(1)

do-something;

if (success) {

do-this;

do-that;

...

[many lines of stuff]

do-some-other-thing;

}

else

{

print-error-message-and-exit;

}

(2)

do-something;

if (failure) {

print-error-message-and-exit;

}

do-this;

do-that;

...

[many lines of stuff]

do-some-other-thing;

I could go on at length to try to justify my strong preference, but I won't. In the end, it's just taste.

No, I take it back, I will rationalize a little. Here are some reasons I prefer #2.

• It's shorter overall.
• The short alternative comes first, so you don't overlook it in the noise.
• There's one fewer nesting level to puzzle through. This also occasionally permits longer lines without word-wrap.
• It feels more like exception handling, and saying what I mean: A problem? Let's bail.

In Perl, the solution is even more stereotyped and easy-to-read:

do-something OR die "it didn't work";

...

In bash, I use a shell function, die(), which I wrote to let me code in the same style:

do-something || die "It didn't work"

...

Process Whack-a-Mole: An Alternative Approach

Gosh. I haven't blogged in, like, forever. Inspired, as is so often the case, by Hal Pomeranz and friends, here's something.

Over at his Command-Line Kung Fu blog, Hal has posted a solution to the problem of writing a process-whack-a-mole command, that watches for any new process and kills it.

(Hal's self-imposed constraint is always that his solutions really be command lines -- they can't be full-blown scripts -- and that they not use Perl, or other languages that are powerful enough that their use would feel like cheating.)

Nothing wrong with his approach at all, but here's another. (I mailed it to Hal, who said, "Post it somewhere, Dude.")

$ ps -e o pid,ppid,cmd | grep -v $$ > baseline; while : ; do

> sleep 5

> ps -e o pid,ppid,cmd | grep -v $$ > now

> join -v 2 baseline now

done

This is, at least, a single command line. :-)

It shows off a couple of things:

1. join -v
2. the output of ps is pre-sorted by process-number

The didactic downside? It doesn't show off arrays or "[[" . (I spent a minute in philosophical reverie, contemplating the elevated virtue of using files to store data for shell scripts, but then realized this is engineering and snapped out of it.)

Oh, and I completely love Hal's "| grep -v $$", which I never would have thought of.

On reflection, the only thing the join would normally see is the ps itself, which is gone by the time of the join, so for the real deal, this can be pared down a titch.

# ps -e o pid,cmd > baseline; while : ; do

> sleep 5

> ps -e o pid,cmd > now

> kill -9 $(join -v2 -o2.1 baseline now)

done 2>/dev/null &

Just kill everything new and ignore the error message from not being able to kill the ps:

"Kill them all and let The Kernel sort them out."

Just in case

I just learned something new about shell syntax -- specifically, about the case statement.

The shell's big enough that I expect I'll be able to keep learning things about it for a long time, even though I've been writing shell scripts for ... lessee ... about 30 years.

Here's today's:

I'm used to writing this:

case $key in

whatever) do-something ;;

*) some-default-behavior ;;

esac

I just read a Fedora system script that looks like this, instead:

case $key in

(whatever) do-something ;;

(*) some-default-behavior ;;

esac

The leading paren is optional, but legal. And not just for bash, but for any POSIX shell. Amazing. Also, the last item doesn't have to have the semis, so it could even be this:

case $key in

(whatever) do-something ;;

(*) some-default-behavior

esac

Back Off Man, I'm a Scientist

"I have no faith in anything short of actual measurement & the Rule of Three"

-- Charles Darwin

In an interminable thread about recycling computer parts, on the Boulder Linux Users' Group mailing list, Davide Del Vento injects a completely unsubstantiated and largely dubious claim:

The point of the discussion is what we agree is ok to "kill" or "destroy", and what is not. Is it ok to kill a cow to feed my kids? Most people would say "yes". Is it ok to kill Jeffrey Haemer to feed my kids? Most people would say "no".

Doing science means collecting data. The polls in the left sidebar test his claim.

We shall see, eh?