Home / Team / Eric Pierce

Eric Pierce

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:

  • "Share

My Blog

Internet Explorer 31-stylesheet limit
Tue, 08/10/2010 - 15:10

After half an hour of editing ie6.css and wondering why the heck my customizations weren't actually showing up in MSIE, I came across a bit of CSS trivia that I'd forgotten, if I ever knew it at all: Internet Explorer can only load 31 stylesheets. Maybe this is due to the stylesheets being indexed by a 5-bit number? I can't imagine a logical reason for such an arbitrary limit. Anyhow, a quick glance at the page source revealed that ie6.css was number 33, which explained why my customizations weren't finding a foothold.

Drupal has a CSS optimization feature that supposedly can help with this, but it's kind of annoying to do style developments with that turned on. The real problem here is the tradition that many Drupal themes have of including a ton of different CSS files; one for layout, one for background images, one for blocks, one for forms, one for fields, and so on. My theme is based on Zen, which alone includes 17 different stylesheets. Add to that the various stylesheets that are builtin to the custom modules I've installed, and we quickly exceed that 5-bit limit.

The solution was simple--just edit my theme's .info file and comment out all the styleshets that are totally empty (views-styles.css, panels-styles.css), logically empty or very close to it (page-backgrounds.css, fields.css, blocks.css) or otherwise unused (wireframes.css). I'm not sure why these void stylesheets aren't commented out by default in the starterkit theme; I can't imagine many theme developers actually needing them, and if you know you need to define a custom style for #block-aggregator-category-1, you're probably smart enough to uncomment the relevant line in your .info file.

A couple of bugs have been opened for this, but it's good to have an easy workaround in the meantime.

Cover your nose
Tue, 09/14/2010 - 14:05

Python has some great features for testing. One of my favorites has always been doctest, which allows you to embed executable tests right in the documentation of your modules, classes, and functions. There are some practical limits to what you can do with doctests, and that's where unit testing comes in.

Until recently, I've used the builtin unittest module for unit testing, but I've always felt a little bit uncomfortable with it, though I couldn't have explained why until I read Ian Bicking's rant against unittest. I think one of the reasons I'm not crazy about unittest is that it doesn't feel very pythonic. Maybe this is because it was based on a Java framework, which in turn was based on a Smalltalk framework. Why should I have to write boilerplate class wrappers for all my tests, when all I want to do is call some functions? In fact, this characteristic is one of my least favorite things about Java--that "object oriented" really means "objects mandatory." Ironically, in Java, many primitive data types aren't actually objects, unlike in Python where everything really is an object, even though Python isn't considered "object oriented". But I digress...

There's a testing tool (I hesitate to call it a "framework") that I'd heard about called nose. I decided to give it a try, and I'm very glad I did--it makes unit testing about as painless as it can possibly be, with no boilerplate code, no configuration, and only a few simple rules about how your modules and functions should be named. Much in line with duck typing, if it looks like a test, it's a test.

Nose also comes with support for coverage, making it really easy to see at a glance what percentage of my code is covered by tests.

When I started using nose and coverage, there were only a handful of doctests and unit tests in CSVSee. Less than 24 hours later, I've reached 100% statement coverage of the core modules, and made many small improvements to the design as a result.

It's a long way from SQLite's legendary 650:1 tests-to-code ratio, but it's a darn good start.

Social code project resume networking with Ohloh
Fri, 09/17/2010 - 21:38

Ohloh is a site I've bumped into before, but never really explored it or created an account. Today I signed up and tried it out, and I'm very glad I did. Project tracking meets resume building meets social networking--I've originated or contributed to quite a few open source projects, and this site gives me an easy overview of the work I've done, what languages I've used, and who else is contributing to or using my software.

I think one of the coolest features is the automatic code analysis; if you tell Ohloh where to find your project's source code, it'll automatically fetch the code and spit out some nice charts showing the percentages of each language used, how many of those lines are comments, and how the code distribution has changed over time. For example, did you know that Firefox has more than 50% JavaScript, or that PHP includes only about 18% PHP? It's interesting, though may not be very reliable. One of my projects, tovid, is reported to have only 636 lines of shell script, when it's actually over 10,000 lines, so you should probably take their metrics with a salt lick.

The profile page is pretty sweet--I can see all my projects at a glance, or view all of a project's contributors. Projects can be tagged with keywords--the tagging interface is great, allowing quick and easy selection of additional tags from similarly-tagged projects. Another nifty though somewhat dubious feature is the "Project cost" box, which gives an estimate of how much it would cost to develop the project from scratch, using something called the COCOMO model. The things I've been working on lately total to about $42,000. Of course this model can't possibly be estimating code quality or utility, or indeed whether anyone would actually pay that kind of money, but it's a great little ego boost.

You can create "stacks" of software in your profile by selecting existing projects that you use. When you do this, you'll see a list of other users who have similar choices in their stacks; this also enables the familiar "people who use this also use ..." on each project's page, which could help you discover new software that you might like. Since most of my projects are relatively recent, there isn't much to see yet as far as who uses the software or whether they like it. I'm looking forward to seeing that info as it comes in. Overall, I've gotta say this is a well-designed and useful site, and it's definitely going to stay bookmarked for a while.