People Behind Perl: brian d foy

Apr 28, 2005 by chromatic

brian d foy is a longtime leader in the Perl community. Besides founding the Perl Mongers and being a trainer for Stonehenge Consulting Services, he founded and edits The Perl Review, a quarterly magazine for Perl users. If that weren’t enough, he writes and contributes to several CPAN modules. Recently, Perl.com interviewed brian on his work and plans.

Can you give us a brief professional biography?

brian d foy: I started out studying nuclear physics, and I started using Perl to extract simulation results out of huge text reports produced by legacy systems. The researchers were doing it with highlighter pens before I wrote them some programs to turn a three week task into a 15 minute one. Around that time, the dot.com bubble was rapidly expanding, and I got sucked in to that. I worked for a couple of ventures in New York that never really went anywhere. Around 1998, Randal Schwartz hooked me into working with Stonehenge Consulting Services as a Perl trainer, which I’ve been doing ever since. Along the way I’ve done a lot of work in the Perl community, with technical and non-technical contributions.

Had you known Perl previously, or did you learn it for this?

bdf: I picked up Perl sometime around the beginning of graduate school. I wasn’t a programmer, and had only gotten my first computer about a year before that (previously using school computers for anything I needed). At the start I just wanted to understand these weird characters that people were using in messages on a BBS I read. It turned out that they were Perl regular expressions. I bought Programming Perl, then Learning Perl in the same week. (I still have the receipts, oddly: Learning Perl receipt and Programming Perl receipt.) And I was on my way.

Stonehenge has its headquarters in Portland, Oregon, and you live in Chicago. Do they send you out to East Coast gigs? How does that work?

bdf: When I started with Stonehenge, I was living in New York, and we actually had a lot of business in New York. We also had a lot of business in the usual places like Silicon Valley, Research Triangle, and other tech centers. Teaching assignments are handed out more on availability than location, although each of the Stonehenge instructors has a favorite part of the country to visit, so we sometimes trade assignments to make it work out. Lately I’ve been taking the New England area assignments.

How’d you come up with the idea for “The Perl Review”?

bdf: It really had nothing to do with Perl. I had just left a dot.com company, and I was dating an opera singer. We moved to Chicago because she had a long-term engagement in Chicago. I went on several interviews, and being the dummy that I am, I was honest about my chances of staying in the Chicago area. I found Chicago much more hostile to job mobility than New York, and I wasn’t going to get a job unless I committed the rest of my working life to it. I couldn’t do that and follow my wife around the world as she pursued her career. I figured, she has to actually be where she wants to sing, whereas I could live in a virtual office from anywhere that had an internet connection. It’s especially nice now that a lot of hotels have wireless connectivity.

I needed something I could do from a hotel room, literally. I published most of the first print issue of “The Perl Review” from a hotel during a month-long production of The Pirates of Penzance.

Can we expect to see small discounts for orphans then? (Just kidding.)

bdf: Yes, but only until their 21st birthday.

I looked around to see what was missing from the Perl community. “The Perl Journal” had disappeared almost completely, and “Perl Month”, an online Perl magazine, had stopped publishing new stuff. No one seemed to be publishing much good stuff about Perl. A lot of magazines that had had some Perl content had disappeared in the dot.com shakeout too. I also realized that many of the people still writing about Perl had been writing about Perl for a while, and the community didn’t have too many ways to develop new writing talent.

When I asked around to gauge the interest, no one spoke any words of doom or misery, so I just kept going with the idea.

Is that the key to success in Perl, or do you think it worked out only in your particular situation?

bdf: Well, I had made a lot of friends through my work with Perl Mongers, so I was able to talk to a lot of people and get their support because they knew me. I also had a track record in the Perl community, so I think my personal reputation gave the project a bit of a boost. If no one knew who I was, I think things would have been a lot tougher.

What’s “Extreme Publishing” and how is that working out for you?

bdf: I started calling the process we used for “The Perl Review” Extreme Publishing as a bit of a joke on Extreme Programming. I had this idea that we’d be able to publish in short iterations with fast turn-around, and build a set of tools to automate the process.

On the technical side, that worked nicely. I could take a text file (usually in POD) from an author, run it through a converter to get LaTeX, then typeset the whole thing and turn it into a PDF file. If I changed some text, I only had to type a few characters to get a new PDF file. Everything was text-based and in source control, just how a good Perl programmer likes it.

On the aesthetic side, it wasn’t so great. I had put the technical details before the creative ones, and no one had said anything about it because everyone working on it was a techie, and those were the bits that we liked to play with. Those weren’t the hard parts of the process, and they weren’t the parts that needed the most time. The process I had set up really restricted the aesthetic side. Publishing is not programming.

The real process in creating something better than an author can do on his own (for instance, putting something on his website with no help from us) doesn’t involve many technical considerations: the value of a magazine or book is editorial help that develops and matures the content. All of that happens before we get to the point where we want to create the final output, and it’s the part of the process that takes the longest. By paying attention only to the last part of the process like we were, and then only the technical details of it, we had fallen into the trap of premature optimization.

After we printed our first issue, I switched from LaTeX to Adobe InDesign because we could produce better output faster. LaTeX is very difficult to wrangle if you want to precisely control the placement of a lot of things: you don’t want the last line of a paragraph at the top of a column or on the next page all by itself, or several hyphenated lines in a row. You can control all that in LaTeX, but you have to edit the input files, process them, and see what you get. You have to do that every time you want to make a change. We don’t have that problem with InDesign. Not only that, a much larger work pool becomes available. A good designer will probably know how to really use InDesign or Quark but know nothing of LaTeX, while the situation is reversed for a good technical person.

Although we still prefer POD from our authors, I’ve backed off of that requirement too. The more restrictive we are with submissions, the less motivated the authors are to do the work. Now we let them submit their articles in any format they want; they were doing that anyway. We’re here to publish good content, so the content should be first and the technical details later. If we have to do a couple extra minutes worth of work to convert a Microsoft Word document into another format, that isn’t going to kill us.

What do you look for from your authors editorially? Do you put together a theme for an issue and look for contributions there, or do you try to find a mix of solicited and unsolicited articles?

bdf: The themes come from what we get. I tried to come up with themes, but it just never worked out. I go after new authors rather than the same ones people see in every other magazine. My friend Randal Schwartz writes a column for just about any magazine that has Perl in it, and he’d be a popular author for “The Perl Review”, but I’d like to develop new talent too.

Most of the articles we publish now are solicited. One of the editors will see something cool, like a usenet post, new module registration, or blog entry, and we’ll get the author to expand that into a story.

How do you motivate authors to hit deadlines? Seriously, I’d like to know.

bdf: Deadlines are tough for part-time (or one time) authors. I tell the authors not to worry about the time. Whoever gets their articles in first gets into the next issue. If we want a particular article, we’ll just keep asking for it, or asking for rough drafts, or even outlines.

We have a big stack of articles waiting for space in the magazine, though. At first, when we were only a PDF file, every article could make it into the magazine because we didn’t have to commit to a page count. That also meant we started from scratch for the next one. Now that we have to commit to a certain number of pages to coordinate the designers, printers, and everyone else, we have articles left over after each cycle. Some are longer than the space we have and we don’t want to cut them, and some we want to give a more prominent position.

I don’t know if I’ve discovered any special secret, or really been any more successful than anyone else regarding deadlines. If you see a short article by me in the magazine, that probably means something that was supposed to take up that space didn’t get done in time.

How do you keep track of the dozens of little details? Sticky notes? Database? Notepads?

bdf: My personal to-do list is mostly a mail folder. Anything in that folder needs attention. Other than that, I have a several whiteboards in my office. Around production time, every page in the next issue turns into a Post-it note, and those notes go onto my big corkboard. As things change, like an article going from 6 to 8 pages perhaps, I move around all the Post-its.

For long-term article tracking, I have a mysql database and web application that tracks each submission. I know when I received it, what stage it’s in, and who’s worked on it. When it comes time to pick the articles we want to focus on, I look at those that have gone through most of the steps (such as technical reviews, re-writes, and peer review). We then concentrate on those articles.

I don’t think I’ve found the best way to do that, though (and I’ve been meaning to ask you about Jellybean). In the end, I don’t think it’s a technical problem. I think the real solution is going to be something that an editor uses to collect and view information. It’s not going to be something that automatically collects things because the value of the process is in the editor and what that person knows. I’ve found that that sort of information is not self-organizing, and that we really need one person who takes the article from start to finish. If we try to cut the human out of that process by automating things, we’re going to lose out on the creativity and writing side. Whatever the right answer is, I think it’s going to be something that helps rather than enforces.

I’ve noticed that you’re now shipping paper copies to Europe. How has the process of collecting addresses, billing, printing, and mailing worked out?

bdf: I’m continuing to learn a lot, and the main thing I’m learning is that a lot of the service industries are still protecting their knowledge so they can get me to pay thousands of dollars for them to handle all that for me. It’s not at all like the open source world.

Billing is pretty easy, although international credit cards fall into a higher risk category in the bank’s calculus of fraud. Sometimes the bank flags a transaction as suspicious because the bank on the other side doesn’t give it the right secret handshake. It’s better to be cautious, though.

We haven’t started printing in Europe yet, but that’s a big part of the plan. Some people have asked about printing on A4 paper, but that would be a new layout. Whatever we do, it will be the same size wherever we print as long as we’re using the same content in each edition.

Mailing is most of the excitement. Every country has their own format and includes different things in the address. I’m used to dealing with ASCII, but other languages (hence country, city, and street names) use lots of other characters. I’m learning about all the stuff I’ve been avoiding. People want to see everything in the right place and spelled correctly (and with the right characters) on the address labels. I’m still learning a lot, and plenty of people are being sufficiently patient with me to help. The information to make it all work is often closely guarded by service bureaus, but I’ve been learning to use the post office websites from all over the world.

What’s one question no interviewer has ever asked you that you think someone should?

bdf: As for “The Perl Review”, no one has asked me “Are you a masochist?” It’s a big undertaking that takes a lot of work and I started with no experience in the publishing business. It’s a business where the costs are high, the margins low, and there is an ongoing customer service commitment. I’m not in this to make money, though, so I think I’m safe.

What’s next for “The Perl Review”?

bdf: The big goal for the first year is to just keep going. So far, we’ve paid all of our bills on time, and we’ve been getting a lot of subscribers. At the end of the first year, I hope enough people think we’ve done a good enough job that they want to renew.