Skip to main content.
Features: Calendar | Interviews | || Login

Interview with Ian Langworth

Ian Langworth is the co-author of Perl Testing: A Developer's Notebook and the creator of the Perl Testing Quick Reference Card which appeared on the back cover of The Perl Review 1.0 (Summer 2004). He's a student at Northeastern University and a member of

The Perl Review: What's your background in Perl? How did you start using it? How did you get hooked in with the Perl community?

Ian Langworth: I grew up in the middle of New Hampshire where, at the time, my only resources were a few old-world Macs and a dialup modem. I never had large programming suites like MPW or CodeWarrior, but I did spend countless hours with FutureBASIC and the thick reference guides that came with it. Around 1996 a friend of mine mentioned a language called Perl, so I downloaded MacPerl and started to play around. I devoted countless summer nights to staying up late and reading Perl man pages with Shuck, the Mac OS Classic POD viewer. MacPerl, MOO programming, beta versions of REALbasic and lighting fireworks were my early teen-aged past-times.

At some point in high school I realized that if I was going to drive a car and go on lots of dates (*cough*), I needed money. As I was about to start hunting for a cash-register or burger-flipping job, a friend asked me if I wrote CGIs since dad was interested in what a web site could do for his business. After that day, my high school afternoons were spent writing said webapp and improving the business of a local promotional marketing company. I immediately discovered that Perl could improve a business and pay the bills. My first purchase while working there was a radar detector, so you could even say that Perl prevented me from getting speeding tickets.

Fast-forward to college. In addition to classes, Northeastern University students participate in "co-ops," or six-month, full-time, paid internships. Two of my three co-ops were spent working for the College of Computer and Information Science's (CCIS) Systems Group led by David N. Blank-Edelman, author of Perl for Systems Administration. Working with the fine folks at Systems, as well as participating in their volunteer student group, resulting in writing a lot of Perl. A member of the volunteer group got me interested in AxKit, which got me interested in wikis, and eventually I stumbled upon Brian Ingerson and his Kwiki project. I started hanging around on IRC and delivered a Kwiki talk at YAPC::NA::2004. The community itself is what got me hooked; I realized what great people most of them all are, and I felt like I might be just nutty enough to fit in.

TPR: You recently finished writing Perl Testing: A Developer's Notebook (PTDN) with chromatic. What's your background in testing and how did you get the idea for the book?

Ian: While working for the Systems group I began to develop a large system for managing the CCIS network and all of its hosts. I had recently discovered FIT and Extreme Programming and I decided that I wanted writing tests before writing the system itself. Not knowing where to start, I scoured the CPAN and compiled a list of what I thought were the most interesting and useful Perl testing modules out there. Being a closet graphic designer, I scratched an itch by creating the Perl Testing Quick Reference Card: a printable sheet with synopses and examples of over a dozen modules. People liked it. Andy Lester linked to it on, and [brian d foy] asked me if he could feature it on the back cover a Perl magazine he was publishing. After receiving a lot of good feedback, that [he] asked me if I had considered writing a book. After the idea rolled around my head for a few seconds, I visited the web site for my favorite technical book publisher and began to read a page titled How to Write for O'Reilly. The idea stuck.

At Northeastern, all students are required to take an advanced writing course around their middler (3rd out of 5) year. At the beginning of this class I asked my teacher if I could write a book, showing her one of the O'Reilly pocket guides as an example. She replied "No, this isn't English"---a response that made Richard Rasala, the associate dean at CCIS, nearly burst an artery in disbelief. Prof. Rasala offered me a directed study to begin the book with him and, for the next three months, he mentored me on what evolved into the first three chapters of PTDN.

TPR: How did you do in that class? Did anyone else end up with a published book?

Ian: I got an A in both :)

For the advanced writing class, I turned in a report on the benefits of test-driven development, and all I remember is that it featured really neat 3D graph. It wouldn't surprise me if someone else in that class had their paper published, as a few of the kids really worked hard. I avoided the classroom faux pas of starting conversations with, "I'm writing a book. What are you doing?"

TPR: How much did the class help you in writing PTDN?

Ian: Prof. Rasala reviews piles upon piles of computer textbooks, so having him as an editor was a treat. The independent study with him was easily one of the most rewarding courses I've taken. We both had a good time watching the project develop and discussing Perl weirdisms.

TPR: Will we ever see a Perl Testing Pocket Guide?

Ian: Doubtful. I think the format of the Developer's Notebook series is a much better fit for the material than the Pocket Guides. The Guides are only annotated references whereas the Developer's Notebooks are recipes for accomplishing a task. PTDN doesn't just list the ingredients and cooking instructions; it takes you through a typical process, explains each step, and tries to answer any questions you might have afterward.

TPR: TPR published your Perl Testing Reference Card in its first issue. Will we see that as a nice laminate from O'Reilly?

Ian: That's a good suggestion---I'll look into that. Until then, I'd be happy to present the reference card in alternate formats, such as interpretive dance or macaroni glued to paper.

TPR: Who should buy PTDN? What's your target audience?

Ian: Everyone with a credit card! I'm kidding, of course, but I'm reminded of a National Public Radio interview years ago in the midst of the Windows 95 hype. A man was carrying around a box for Windows 95 in his trench coat. "I don't even have a computer," I remember him saying, "but when I get one, I'll be ready." (Hint, hint.)

Anyone who has written a Perl test file should find this book entertaining and blindingly useful. In fact, one of the reviewers just instant messaged me about how he's already using his review copy to test the database infrastructure at his workplace. He's actually just beginning to learn Perl and is even using the book as a style guide.

The book is for anyone who wants to test anything with Perl. It's not just limited to testing Perl code, either---there are sections on testing web sites, databases, and external programs as well.

TPR: What's the main thing you want people to learn from PTDN?

Ian: To mangle a classic Perl aphorism, I'd say the book shows that testing simple things is easy and testing seemingly-impossible things is doable. I hope that readers will see techniques for things they've never considered testing. I can imagine people really digging the material and saying, "Gee, it never occurred to me that I could temporarily override Perl's built-in keywords."

TPR: How is the Developer's Notebook series different from the more familiar "Nutshell" series of O'Reilly books?

Ian: I'd say that the Developer's Notebooks are much more casual and relaxed. I'd guess that the Nutshell books are like a politics class and the Developer's Notebooks are like a rock-climbing class---you learn a whole lot in both, but one is way more hands-on and fun.

TPR: When you originally pitched this idea to O'Reilly as a first time author, did you think you had any chance of getting a "Yes"?

Ian: When hearing it, lots of Perlers agreed it was a good idea and became excited. When I was introduced to [O'Reilly editor] Allison Randal, she was excited and she immediately asked me for a proposal. David, however, wisely suggested that I not refer to the project as "an O'Reilly book" until it was officially accepted.

Even though I was a first-time author, I was moderately confident. When I wrote the proposal at the end of December I had already completed three chapters of an early version of the book. I spent a solid week writing and polishing the proposal, and I made sure to spell the name of the publisher correctly.

TPR: You co-authored the book with chromatic, had a mailing list during writing, and quite a cast of Perlers helping you out. How did that work out?

Ian: People gawk when I tell them that I wrote a book without ever meeting my co-author or editor face-to-face. The proposal was written in the Bahamas, and the book was written in Boston and various wireless-equipped New Hampshire ski lodges. (My girlfriend went snowboarding and I took the season off this year due to foot problems.) chromatic and Allison worked from Portland and the chapters were reviewed by terrific people from all sorts of places. I suppose this says something about the times we are a-livin' in.

The book was written in PseudoPOD, which made it easy to manage with Subversion. We had a cron job email chromatic, Allison and myself a diff when a commit was made to the repository. Emails on commit, descriptive commit messages and the mailing list made for extremely good communication.

TPR: Did the final product come out close to what you'd thought you would have at the beginning?

Ian: I had a Pocket Reference in mind until Allison convinced me that the Developer's Notebook style was a better fit. She certainly was right.

TPR: How did you feel while you wrote the book? Terrified, elated? How did the community support affect that?

Ian: Y'know how Keanu Reeves steps back in his movies and says, "Whoa?" Imagine that every day for four months. Mix in a few "Holy crap"s from The Family Guy and that busy-sounding music from classic cartoons.

Encouragement is completely necessary with a large writing project. I have some good friends both inside and outside the Perl community to thank for that---editor and co-author, inclusive.

TPR: How about at the end when you turned in everything?

Ian: An allegory: One time, in high school, we were excused early due to an imminent blizzard. I had to drop a friend off at his house, and by the time we were leaving from the parking lot there was already a foot of fresh powder blanketing the entire state. What normally would have been a twenty-minute trip was a dark, two-and-a-half hour long precarious rumble through what seemed like the worst of the Andes. When I got home I realized that, despite the drive being dangerous and a great deal of work, it had really been a lot of fun.

TPR: You actually finished the book a while ago. Now that some time has passed and you've had a chance to think about it, do you want to write another book?

Ian: I've got a few more projects I want to accomplish first. But even more importantly, I've got a girlfriend who's tired of hearing the phrase, "Just one more hour, I gotta finish this." After a month or so, the sky's the limit.

TPR: Which Test:: modules do you use the most?

Ian: My projects usually start by using Test::More, Test::Exception, and Test::Class. Test::Deep usually finds its way in there, too.

TPR: Did you (or anyone else) need to create new Test:: modules to support part of the book?

Ian: I'm pretty sure that chromatic was ferociously working on Module::Build::TestReporter. He completed it in time to write a nifty lab that demonstrates how to have the output of failed tests sent via email.

TPR: Or did you have to get authors to update and fix their Test:: modules as you wrote about them?

Ian: Not that I can remember. I really wish HTTP::Recorder was a little farther along, but I figured it would be useful to enough people, so it was included.

TPR: What's the future of Perl testing? What sort of things would you want to see in a second edition of the book, say, in four years?

Ian: I regret that we didn't have enough time to include everything we wanted to---we were really hoping to get the book out in time for OSCON. A few things were left out, such as the Test Anything Protocol libraries for C and PHP, testing with FIT, and Test::Inline. I also wish we had included Test::MockRandom, which I'll admit I didn't know about until I read about it in The Perl Review.

A big milestone was to have Ingy discover and succeedingly reinvent Perl testing. The Ingy Effect has occurred, and the result is his nifty Test::Base module. I'd like to see a "Write Tests Without Writing Code" lab in the book that's similar to the talk he gave at YAPC::NA this year.

Word has it that the core testing modules are being worked on. I'm a big fan of fruity colors, and I hope to see a Perl version of Tinderbox of some point. Y'know, DHTML unfolding boxes of failed tests, something cute and flashy.

I've been lusting over how the DrScheme IDE displays test coverage. You write a test and a function, run it, and the code that was not run by the test appears in red. Coverage is one of the first things they teach to students. This is something I'd love to see happen in a Perl editor. With the recent developments of PPI, I think it's feasible.

Finally, there are whisperings of a Big Perl Testing Book---a book that covers not only testing with Perl, but concepts and common practices of testing as well. I hope that PTDN will keep Perl folks full until that tasty meal is served.

A review of Perl Tester's Developers Notebook appears in the Fall 2005 issue of The Perl Review.