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

A better way to document
Wed, 09/01/2010 - 22:30

Okay, I admit it; I'm not ashamed. I love to write documentation. Most of the time, I would rather write docs than code. That's one of the reasons I was thrilled to discover Read the Docs, a new website that makes it easy for developers to build and publish documentation. You can create quick one-off docs, or link up to existing docs you may have in a public Git, Mercurial, Subversion, or Bazaar repository.

This is one of those rare projects that I instantly liked; the same day I discovered it, I got involved in its development. A small team of very talented guys built most of it in a 48-hour sprint, which is an inspiring example of what can be accomplished in a short time with the right kind of focus, and with the right tools. Documents are marked up in reStructuredText format, and built using Sphinx, both held in high regard among the Python community, as well as being my personal favorites for creating documentation. Django, a powerful and elegant Python web framework, is another favorite of mine and an excellent choice for a site like this.

The docs for our CSVSee and Grinder Webtest projects are now being hosted there, saving us from having to manually build and publish them whenever they are modified. Read the Docs pulls the updates from our public repository on Launchpad, builds the docs, and posts them online with minimal intervention. Automation FTW!

How to learn a new language
Mon, 08/16/2010 - 19:05

Throughout my software development career, I've tried to be open to the prospect of learning new programming languages--not just to accomplish a job or pad my resume, but for my own edification and consciousness-expansion. While I haven't learned as many as I would like, I have picked up a few; most recently, I've been endeavouring to learn Haskell.

For the uninitiated, Haskell is a pure functional language with lazy evaluation. These two key features of Haskell make it almost completely unlike any imperative language I've used. In C++, Java, Python, PHP or Ruby, you typically build a program with sequential statements that change the values of variables; when the program executes, the state of these variables mutate until you eventually get the output or result you're looking for. Haskell doesn't work like this at all--its variables don't vary, and sequential execution of statements is almost unheard-of. There are no loops, and no side-effects. The alien nature of Haskell is one of the reasons I was drawn to it, and I have found that learning it (even just a little bit of it) has extended and deepened my understanding of programming in general.

But how does one go about learning a new language? In this case, I started with some of the many tutorials, drawing as much knowledge and experience as I could from each one. Nearly any semi-popular language is bound to have many different online resources, varying in length and detail from the short introduction to the full-blown textbook. With a little searching, you can probably find more reading material than you know what to do with, on just about any language you might be interested in learning.

Reading books and following their exercises can only go so far, though. I found that I didn't really begin internalizing Haskell until I set myself loose on some programming exercises. You can't get better at any skill unless you practice it, and this is especially true of programming. I suppose it's possible to make up my own practice exercises, but I found it more effective to attempt some well-established exercises designed by others. 10 Puzzle Websites has some good references; one of the most famous, and also one of my favorites, is Project Euler, which has hundreds of mathematical and logic problems. Most of them require some programming to solve, and beginning with the simplest problems is a great way to begin truly applying the language you're learning. Another good site is Programming Praxis, though the problems there are typically more complex; you may want to wait until after tackling a few of the Project Euler problems before moving on to those.

Ultimately, I think the only way to fully absorb a language is to write real software using it; to build a tool from scratch, then use and maintain that tool over a period of time, or to participate in development of an existing program in that language. I haven't quite gotten there yet with Haskell; the closest I've come is occasionally modifying the configuration of my favorite window manager XMonad (written and configured entirely in Haskell), so I am still looking for a project where I might make better use of what I've learned. I know that when I was first learning Python, I didn't feel very competent until I was building actual, useful software with it.

I hope to learn more programming languages some day. I've dipped my toes into Lisp and some of its dialects such as Scheme, but I would love to learn more. It would also be nice to get some C# exposure, and I've heard some good things about Erlang. On the other hand, I don't want to spread myself too thin; I know from my experiences years ago with C++ and Perl that if I don't stick with a language and use it frequently, it's likely to slip into the dark corners of my mind, where I can no longer say with any confidence that I still "know" it.

In the end, I believe practice is everything. A runner who doesn't run is no longer a runner, and a Haskell programmer who never programs in Haskell is not really a Haskell programmer. If I want to become a Haskell programmer, I need to keep practicing.

Automating procedures using Sikuli
Sat, 08/14/2010 - 16:49

A few days ago, I came across an interesting open-source GUI testing application called Sikuli. This tool promises to automate just about any procedure involving graphical elements displayed on the screen, using a vision engine to intelligently match regions of your GUI display to widgets where you might click, drag, or type things. Sikuli is distributed under the permissive MIT License.

Unlike other automation tools I've used such as WinRunner, QuickTest Pro, SilkTest, and LoadRunner, Sikuli does not depend on API-level access to the technology used in the target application, and instead works purely based on the pixels displayed on the screen. This could allow automation of tasks in graphical environments whose API is unsupported by these other tools.

The demos are quite impressive; Sikuli scripts can be written in Jython, giving full access to the power of the high-level, general purpose Python language. This also sets it apart from the proprietary tools mentioned above, which have extremely limited scripting languages. The Sikuli IDE looks much like a regular text editor, except that screenshot regions can be inserted directly into the code. This makes for some very intuitive scripts.

However, once I tried Sikuli, I became less hopeful. I tried to automate a few basic tasks, including:

  • Run Notepad, type "Hello world", then select the text and make it boldface
  • Run Firefox, load Google Maps, and zoom into Colorado Springs
  • Run Internet Explorer, browse to a VPN login page, fill in my username and password, and login

I had some measure of success with each of these, but I continually ran into problems with screen elements not being found, and typed text failing to be entered. After starting up an application, it seems necessary to wait for a particular graphical element in the application to show up. I tried several variations on this, including the menubar, titlebar icon, or URL entry field, with varying and inconsistent results.

Once the applications started up, I had other difficulties. I got "Hello world" to be entered in Notepad with no problem, but then couldn't get it to be selected or boldfaced. I also had problems with automatically entering URLs into Internet Explorer and Firefox. I did finally manage to get Google Maps to load, and the graphical map interface worked pretty well; however, the seemingly-simpler task of logging into VPN failed when, after getting the page to load, the username and password fields wouldn't fill in. Sikuli didn't even realize anything was wrong, but just proceeded with trying to login without a username and password.

Finally, and perhaps the most troubling of all, in a few cases I ran the exact same script twice in a row, and got two different results. The first time, the URL wouldn't be entered; the next time it would. Or, the first time the "File" menu would correctly be opened, and the next time it wouldn't. This is something you never want to see in automation, but unfortunately I have seen it many times (and yes, I've seen it happen quite often in the commercial automation tools).

Overall, I must say I'm not sure Sikuli is ready for prime-time automation, particularly in domains such as web applications where a more specialized tool like Selenium would be more reliable. But it does look very promising--it's possible that I just didn't play with it long enough to learn its subtleties, and I expect with a little patience it could turn out to be very useful.