Eric Pierce's blog

Hypermiling: Or, How I Learned To Stop Worrying And Love U.S. Gas Prices

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.

Candy-gram for Mongo

  • 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.

CentOS: The freshmaker

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.)

Testing Weasel Words

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to cut away. -- Antoine de Saint-Exupéry

Manual and automated software tests often include redundant and unnecessary words which can distract the tester from the real purpose of the test. We're so accustomed to seeing them that they often pass unnoticed.

Consider the following generic test description:

Declare or Impair

A topic that crops up often on the Cucumber mailing list is whether it's best to write BDD tests in imperative or declarative style.

The Perils of Trying to be Clever

  • Narrator: Tyler, you are by far the most interesting single-serving friend I've ever met... see I have this thing: everything on a plane is single-serving...
  • Tyler: Oh I get it, it's very clever.
  • Narrator: Thank you.
  • Tyler: How's that working out for you?
  • Narrator: What?
  • Tyler: Being clever.
  • Narrator: Great.

While working on Vittles today, I had a facepalm moment, preceded by an hour of desperate confusion.

The Zens of Python and Ruby

I've had this idea kicking around in my head for a while that someone ought to rewrite The Zen of Python from a Ruby perspective. Despite their many similarities (very high-level, multi-paradigm, interpreted and dynamic), Python and Ruby have nearly opposite design principles in many areas. Similarly, programmers of the two languages seem (to me anyway) to have different attitudes about readability and documentation, and what constitutes "cleverness" in programming (and whether cleverness is good or bad).

To Selenium or Not To Selenium?

I've been using Capybara with the Selenium driver for automated testing of a Rails project via Cucumber. Certain scenarios involve dealing with client-side Javascript (such as confirming a popup message before deleting a record), which is the reason I started using the Selenium driver. But I soon discovered that Selenium is slow, taking three or four times as long as the standard Rack-test driver.

Racking my brains

I'm using Cucumber and Capybara for integration testing on a web application that depends heavily on the use of subdomains. Since some features rely on client-side Javascript, some scenarios use the Selenium 2 (WebDriver) driver, while other scenarios use the regular rack-test driver.

Why centralize when you can decentralize?

Like most experienced software developers, I've accumulated quite a few years of experience with revision control systems. We use revision control for many reasons--to collaborate, to track changes, and to have a contingency plan in case something breaks--but maybe the biggest reason is simply to keep ourselves from going insane from the frenzied cat-herding that is software engineering.

Syndicate content