Eric Pierce

Job Title: 

I'm a software tester, developer, and graphic designer living in Colorado Springs with my wife and son. I have five years of experience with automated testing, ten years of software engineering and development, and fifteen years in illustration and 3D graphics.

In my spare time, I enjoy programming in Python and learning new languages such as Haskell. I'm a strong proponent of open source and open content. I created Kelp, Cukable, Grinder Webtest, CSVSee, tovid, PySci and other software, and have contributed to several open-source projects. I've also added many illustrations and articles to Wikipedia.

I think any IT professional should have a large repertoire of skills and be open to learning new technologies; nevertheless, I do have some clear favorites:

My web presences:


My Blog

Thu, 03/08/2012 - 19:10

A lot of people are complaining about the price of gasoline these days. It's not hard to find someone who is outraged at paying nearly 4 bucks a gallon to fill up their tank, and the issue has become so politicized and polarizing that we hear a lot of arguments about whether or not we should be doing more drilling, implementing stricter standards on automobile efficiency, or investing in alternative energy sources. Some people believe there are vast petroleum resources that still need to be tapped, while others believe we've long since passed peak oil.

I must say, though, I'm a little puzzled by all the fuss. I have never been bothered much by the price of gas. Part of the reason is that I drive a fairly fuel-efficient vehicle, but the main reason is that I make a conscious effort to drive smarter. I realized many years ago that I can save a lot of money on gasoline just by changing the way I drive. Regardless of what kind of vehicle you have, and regardless of what gasoline costs, you can cut 20 or 30 percent off the cost with minimal effort.

You may have heard of hypermiling. It's a simple concept whereby you improve your gas mileage by applying some fundamental laws about the conservation of energy and momentum. For instance, you may be aware of the fact that automobiles are rather heavy. It takes a lot of energy (gasoline) to get them moving, and it takes more energy to get them moving faster. You burn more gas going from 0-60 in 5 seconds than you would burn by going 0-60 in 10 seconds. Once you're up to 60, it uses relatively little gas to stay at that speed. You know, inertia (which is why cars usually get better mileage on the highway).

This principle is especially important in city driving, where you're likely to be accelerating and braking frequently. I always find it a little funny that people will so often speed ahead to a red light, as if the first person to stop is the winner. Stopping wastes a lot of gas too, because you're throwing away all your inertia, and must burn more gas to get going again.

So we should never stop at red lights, right? No, that would be insanely stupid. What I mean is, try not to be at the light while it's still red. If you're still moving, you still have some inertia; if you cruise up slowly and get there just in time for it to turn green, you may not need to stop at all.

Tailgating is another potential source of gas wastage. The more closely you follow another vehicle, the more quickly you may have to suddenly brake (losing inertia). When the car in front of you begins slowing down to make a turn, you'll have to slow down too, whereas if you were further behind them, their deceleration would have little or no effect on you, and you could keep your inertia. (Plus tailgating can also be incredibly dangerous).

I can hear you wondering at this point whether it's worth all the trouble. I can tell you from direct personal experience that it is. My car is rated at anywhere from 19 to 23 miles per gallon (city), depending on which statistics you look at. Let's call it 21 mpg. That's not too bad for a 22-year-old vehicle. But with the way I drive, I consistently get between 30 and 34 miles per gallon in the city.

How much money am I saving? A little math can tell us. Let's say I drive 300 miles, then fill up the tank at $3.75/gallon. At my average of 32 miles per gallon, this is $3.75 * (300 / 32) = $35.16. If I were not making any effort to drive smart, we can assume I'd be getting the rated 21 mpg, which works out to $3.75 * (300 / 21) = $53.57. So I saved $18.41 on this tank of gas, or about 35% off what I would have paid if I were a "normal" driver. Since I started keeping track of my gas mileage 4 years ago, I figure I've saved about $1200 (and I don't drive very often).

I am not alone either; there's a whole community of people who are saving money just by driving smarter. You don't need to buy anything, just make some small changes in your attitudes and perceptions while driving.

Hypermiling techniques range from basic to advanced, but I would summarize them like this:

  • Stay at or just a little under the speed limit.
  • Don't tailgate. In fact, do the opposite. Leave 2 or 3 car lengths per 10mph of speed. Yes, there will be a huge empty space in front of you, but this gives you plenty of time to react and slow down if needed.
  • Accelerate gradually. Unless of course you're drag racing.
  • Decelerate gradually. If there's a red light ahead, get your foot off the gas pedal. The only prize for getting to the red light first is a longer wait.

Or even more succinctly:

  • Don't drive like a jerk.

Driving smarter is the easiest, most cost-effective way to begin saving money on gasoline right now. No purchase necessary, enter as often as you like. Your wallet will thank you.

Tue, 01/31/2012 - 18:00
  • Bart: I better go check out this Mongo character.
  • [Bart reaches for his gun]
  • Jim: Oh no, don't do that, don't do that. If you shoot him, you'll just make him mad.

So I've got this Rails application that uses a MongoDB database. There have been occasional problems in the past, and a few times I've gotten frustrated with Mongo's general bone-headedness, but never anything serious. Then today, I had a face-off that firmly cemented my negative opinions of MongoDB.

It all started when something went wrong with the application. Suddenly, Passenger reports that Rails is unable to connect to Mongo. If it were any other Unix service, a simple service mongod start might do the trick. So we start there:

# service mongod start
Starting mongod: all output going to: /var/log/mongo/mongod.log
forked process: 19583
        [  OK  ]

Peachy, right? Well, when mongod says "OK", what it really means is "I may have started fine, or I may have exploded. I'm not saying." When you check, you might be surprised:

# service mongod status
mongod dead but subsys locked

That's no good. It seems to be in some kind of limbo-state, not started, but not really stopped either. So before doing further debugging, let's stop the service:

# service mongod stop
Stopping mongod:      [FAILED]

What? It failed to stop too? Now what? So tell us Mongo, what's your status now that you've pretented to successfully start, then failed to successfully stop?

# service mongod status
mongod is stopped

At this point, it's hardly a surprise. Well OK, so we check the log file and it's complaining that it needs to be repaired or something. So let's try this:

# mongod --repair
MongoDB starting : pid=4507 port=27017 dbpath=/data/db/ 64-bit
exception in initAndListen std::exception: dbpath (/data/db/) does not exist, terminating

That doesn't seem right. It's looking for databases where they don't belong. My databases are in /var/lib/mongo, not in /data/db:

# ls -l /var/lib/mongo
drwxr-xr-x 2 mongod mongod      4096 Jan 31 15:50 db_development
-rw------- 1 mongod mongod  67108864 Jan 31 15:50 db_development.0
-rw------- 1 mongod mongod 134217728 Jan 31 15:50 db_development.1
-rw------- 1 mongod mongod  16777216 Jan 31 15:50 db_development.ns

And I'm pretty sure that's already configured:

# grep dbpath /etc/mongod.conf

Yup. Fine, so I guess mongod doesn't know where to find its own configuration file. Let's tell it, shall we?

# mongod --config /etc/mongod.conf --repair
all output going to: /var/log/mongo/mongod.log

Alrighty, so everything should be fine now, right?

# service mongod start
Starting mongod: all output going to: /var/log/mongo/mongod.log
forked process: 27310
        [  OK  ]

But we know better than to trust this particular "OK" by now, right? Sure enough:

# service mongod status
mongod dead but subsys locked

What now? Oh yeah, the log says:

couldn't open /var/lib/mongo/db_development.ns errno:13 Permission denied

This makes no sense. The file was owned by mongod, right? A simple --repair shouldn't change that, right? I mean, if --repair instead broke things that were already working, it should probably be called --break, right?

# ls -l /var/lib/mongo
drwxr-xr-x 2 mongod mongod       4096 Jan 31 15:50 db_development
-rw------- 1 root   root     67108864 Jan 31 15:50 db_development.0
-rw------- 1 root   root    134217728 Jan 31 15:50 db_development.1
-rw------- 1 root   root     16777216 Jan 31 15:50 db_development.ns

Sigh. So I gotta manually fix the stuff that --repair broke:

# chown -R mongod:mongod /var/lib/mongo

And then stop, start, and once again verify the status of mongod, to discover that it's finally working properly now.

What's wrong with this picture? The mongod service flagrantly violates several of the unspoken (and some of the spoken) rules about software, not least of which is the fact that errors should not pass silently. Sure, they go to the log file, but if your service failed to start, then it shouldn't be saying "OK" when you go to start it. Similarly, it shouldn't mislead you by saying "FAILED" when in fact there was some measure of success. What about not being able to find your own configuration file? The mongod service itself seems happy to look in /etc/mongod.conf, but when you run mongod from the command-line, somehow it forgets where to find it. The fact that the --repair command can silently muck up your permissions is fairly disturbing as well; there's no good reason that these files should have their ownership changed.

Maybe it's just an old version (this is CentOS, after all); maybe these problems are fixed in newer versions of MongoDB. I'm not holding my breath, though. Sorry Mongo--I don't want you in my town anymore. Consider this to be your exploding candy-gram.

Tue, 10/11/2011 - 18:00

Are you bored with your slick Windows 7 or OSX GUI? Have Ubuntu's cutting-edge package updates got you down? Do you like installing archaic Enterprise editions of Linux just for fun? CentOS might be right up your alley. This is a brief tutorial on how to install CentOS within VirtualBox. You'll need a few hours to kill, and a working VirtualBox installation. (I won't go into the details of how to install VBox; it's pretty easy, and besides, if you're thinking of installing CentOS for fun, you probably already have it.)

So, you have a choice of installation media. Option A: Download 5 GBs worth of .iso images. Option B: Download a 10 MB "net install" image, then install just what you need over the network. This is pretty much a no-brainer. Grab the netinstall iso for i386 (32-bit) or x86_64 (64-bit) depending on what kind of engine you got in that there racecar. Fire up VBox and do:

  • New machine (Ctrl+N)
  • Name: CentOS
  • Operating system: Linux
  • Version: Red Hat
  • Base memory: As much as you can spare
  • Create new hard disk
  • Dynamically expanding storage
  • Size: As much as you can spare (at least 8 GB)

Select the new machine and press Start. When the First Run Wizard prompts for installation media, click the folder icon. You should see a tab of CD/DVD images, probably including some .iso files if you've installed other OSes in VBox. Click "Add", browse to where you saved the netinstall.iso file, select it and press Open. Back in the CD/DVD tab, select the netinstall.iso and press Select. Click Next, then Finish. The virtual machine should start up with a boot: prompt. Press Enter to start the installation.

Shortly, you'll get a text-based installer that prompts for some basic options such as Language and Keyboard type. When you get to the "Installation Method" prompt, choose "HTTP" and hit OK. Next you'll be asked for TCP/IP configuration options--just leave these at the default, arrow down to OK and press Enter. On the HTTP Setup page, you'll be asked for a server name and directory. These are where the net installer will fetch packages for installation. You can use any of the available mirrors that provide packages for the version you're installing, or just go with the main CentOS vault:

  • Web site name:
  • CentOS directory: /5.5/os/i386 (or /5.5/os/x86_64)

Enter those and hit OK. Eventually, you'll be taken to a GUI screen with the CentOS logo and a "Next" button. Hit Next, and you'll be prompted to initialize your new virtual disk. Unless something looks wonky, go ahead and click Yes. After this completes, you'll be informed that your hard drive needs to be partitioned. Unless you're an expert knob twiddler when it comes to partitions, just leave the defaults and click Next. On subsequent screens you can specify network settings, declare what time zone you're in, and set a root password.

The next choice you'll have to make is what kind of environment you want to have. You can pick Gnome or KDE GUIs, and extra stuff like Virtualization and Clustering. Make any changes you want here, or just leave it alone and click Next. From here on out, it should be pretty self-explanatory. Be prepared to wait a couple of hours, especially if your internet connection is anything short of magnificent.

Once it's installed, it's time to reboot. Go up to the "Devices / CD/DVD Devices" menu in VBox and unmount the installation .iso (otherwise it'll just try to install again when you reboot). Once you get logged in, it may tell you about some upgrades--you can go ahead and do those, but be prepared to wait another couple of hours.

There's one last wrinkle; if you've used VBox before, you've probably become quite enamored of the VBox guest additions. This is what allows your virtual OS to do cool things like automatically fill up the VBox window, have seamless mouse integration, and share network devices with your host OS. Installing them requires a couple extra steps, however. Here's how to make it happen:

  • Go to the VBox "Devices" menu, and click on "Install Guest Additions"
  • In the CentOS desktop, open a terminal window (Applications / Accessories / Terminal)
  • Become root: su - root
  • Install some things you'll need in order to build kernel modules: yum install gcc kernel-devel
  • Change to the guest additions folder: cd /media/VBOXADDITIONS_3.2.whatever
  • Run the guest installer: ./ or ./

When this is done, reboot CentOS. When you login the next time, your mouse should be integrated seamlessly, and the CentOS desktop will fill up your VBox window. What will you do with this newfound power? That's entirely up to you, and I take no responsibility for it. Enjoy!