NuclearDonkey.net

So, I've been doing a lot of Bash scripting lately -- cranking out an upgrade utility so we can more quickly migrate mail servers on our new data replication software, Fenbu, being chief among recent tasks. There have been several smaller projects too -- tasks that are just more simply and quickly accomplished via direct Linux commands. I had never had issues with variable scope in Bash before, but I discovered something interesting/annoying today. I was trying to increment a counter variable from within a do/while loop, fed via a pipe from a search for IMAP processes. Initially, I had:

COUNTER=0
ps -Af | grep "imap \[$1 " | grep -v grep | awk '{print $2}' |
while IFS='\n' read PID
do
# Don't do anything with $PID yet for the sake of testing
	COUNTER=`$(($COUNTER + 1))`
	echo "$COUNTER"
done
echo "Found $COUNTER IMAP Processes"

The above will end up echoing something like:

1
2
3
Found 0 IMAP Processes

It turns out that this is because pipes cause Bash to perform operations within sub-shells, and variables are specific to whatever sub-shell they're called in. So, once we leave the do/while loop, $COUNTER will again evaluate to 0. Lame!

A little bit of tinkering later, and I found a work-around:

COUNTER=0
PIDS=`ps -Af | grep "imap \[$1 " | grep -v grep | awk '{print $2}'`
for PID in $PIDS
do
# Don't do anything with $PID yet for the sake of testing
        COUNTER=$(($COUNTER + 1))
done
echo "Found $COUNTER IMAP Processes"

There are no pipes going to the loop itself, so there are no sub-shells to worry about. Problem solved! Though it took a bit longer than I would have liked to figure that one out.

I read God's Debris by Scott Adams as one of my personal goals for last quarter and tonight finished up its sequel, The Religion War.

Adams is best known as the creator of the Dilbert comic strip and all the various books that it has spawned. It's interesting to see him out of his usual element and authoring two novels dealing with philosophy, religion, and the relationship between them.

God's Debris is the story of an average Joe deliveryman who, on a routine package drop-off, encounters the smartest man on Earth (known only as the Avatar) and is imparted with a new philosophy of the universe. It reads much like a Socratic dialog, as a lengthy question-and-answer session, but far less annoying. Where Socrates would always respond to someone with a smart-assed, "I don't know what the correct answer is, but I know yours is wrong," the character in Adams' work does offer what he sees as the correct answers, according to his understanding of the universe.

The Religion War then applies this philosophy in a not-too-distant future where the world is split in two -- half of it controlled by Christian extremists and the other half by Muslim extremists, both so convinced of their own religion's superiority that the planet stands on the doorstep of a World War III. The Avatar takes it upon himself to bring about a truce between both sides, and thus his new story begins.

Neither book is especially long, and each presents its own interesting journey (one more a mental journey than the other) that I found fun to follow along. As one who enjoys philosophy in general but is disenchanted with all the "great" thinkers of history who won't just write what they mean, I'm glad that I picked up both of these.

I finished this one last night, after two weeks of more-or-less adhering to my one-hour-of-reading-per-day regimen. It was definitely a valuable read. Author Thomas Limoncelli has substantial experience in the sysadmin field so is able to speak directly to the particular difficulties that sysadmins face when it comes to managing their time: having several different projects, some long-term and some short-term, at once; assorted and frequent interruptions on a daily basis that can quickly sap the concentration that's being applied to said projects; etc.

However, it seems like he's also been embittered by his years of service to larger companies. He speaks of enthusiasm for his work, but doesn't ever express it to the degree that most folks I know at Webmail would.

Either way, there are several valuable lessons I see here. To paraphrase some particularly important points:

• Never trust your brain! If you need to remember a person, place, or event, write it down in your planner. For every piece of information you get out of your brain and onto paper or into a PDA, there's that much more brainpower to devote to solving complex system issues. The bit that I'm missing here still, is where all notes are taken down in one centralized location. I just need to spend more time getting to know the new PDA phone so I can finally ditch all the various notepads I scribble down to-do items on throughout the day.
• Make your calendar and daily schedule as specifically-timed as possible. If there are five projects that need to be worked on in a day, plan out what will be worked on when. If all five projects can't be completed in that day, move the remaining ones to the top of the next day's schedule. If support tickets need to be checked throughout the day, allocate specific times to spend on that. Basically, do everything possible to be able to concentrate intently on one task at any given time. Personally, I usually have at least 10 different shell windows open, plus my email account and our support ticketing system. It's hard to resist the inherent urge to try to multitask by tackling everything at once, but that just isn't efficient.
• For the larger, long-term projects, break them down into several sub-projects, each one with its own goal for completion.
• Apply fundamental programming concepts to your average workday. Come up with daily routines to run (check the calendar and come up with a daily schedule first thing in the morning, for example). Take the most repetitive and time-wasting tasks and automate them. Eventually, the now-well-automated process can be delegated to somebody else.
• Find ways to cut down on the inescapable daily interruptions. Create an internal wiki to cover most commonly-asked questions. If there are multiple sysadmins, schedule “mutual interruption shields” where one sysadmin handles all interruptions for an x-hour period so the other can focus on a long-term project. Then rotate.

And, a couple of my favorite direct quotes:

• ”For a system administrator, the ultimate time waster is any task that could be eliminated if only we had time to build the infrastructure to make such busywork go away. In other words, the ultimate time management technique for a system administrator is a good IT infrastructure... The problem is that we get so caught up with tactical tasks that we never feel that we have time for the strategic work. We're so busy mopping the floor that we don't have time to fix the leaking faucet,” (p. 143).
• ”The term 'routine' has a bad reputation. How many times have you seen advertisements for products that promise to 'get you out of the old routine' or refer to a 'boring routine?' Boring is bad, right? No! As a system administrator I crave boredom. I want an entire week when things happen on schedule, projects get done on time, software installs without trouble, and documentation gives me the right answer. 'Give me just one boring day!' I shout when a big server crashes or a customer comes to me with an impossible but urgent request,” (p. 32).
• ”I once shared a bus ride with a professional chef who told me she hated to cook on her days off. 'Postmen don't like to take long walks when they come home from work' is how she put it. Most of the sysadmins I know have never heard of this idea. You'll find them (and me, as my spouse would be quick to point out) curled up at home in front of a laptop 'mucking about' virtually all the time. The notion of 'play' and 'work' are best described as a quantum superposition blur for a sysadmin. This is great because it means we enjoy what we do, but it's horrible because we can't (or won't) stop doing it. It is hard to manage your time if it is so nebulous,” (p. xi).

I was surprised by the number of recommendations Limoncelli gives that I had already started on the path towards. For example, schedule 6:30-7:30pm in my calendar each day as reading time. And no, the humor in my having to manage time to read a book on time management did not escape me.

There are ideas in this book, though, that I could never follow through with. Limoncelli's main goal, it seems, is to get a person to where they are working the standard 40 hours-per-week. He rants on about how companies today shouldn't expect one to work more than 40 hours and it's absolutely a bad idea to do more. I wholeheartedly disagree here. For somebody who claims to love his work so much, Limoncelli sure is eager to go home at the end of the day. Of course, he does have a family to attend to and that does make all the difference, but I would never say it's inherently bad to work 50, 60, etc. hours per week. If you love your job, why put such strict limits on how much time you spend doing something productive that you love?