PragPub 2010-04: Issue #10

Table of Contents

Features

- Embedding a Movie on iPad
by Eric T Freeman, Daniel H Steinberg
The iPad comes with a bunch of new programming APIs, designed to support its revolutionary new interface. Here’s a look at just one—the ability to embed movies into your application.

- The Red Dirt Interview
interviewed by Michael Swaine
Far out in the remote red dirt country of Oklahoma—well, actually it’s in Oklahoma City—it’s the Red Dirt Ruby Conference, a unique experience in professional education and networking.

- When Did That Happen?
by Dan Wohlbruck
Dan’s got printer’s ink in his blood. This April he tells the story of printing that began in April, 1863.

- A Troubleshooter’s Tale
by Mike Hostetler
Sometimes fixing the problem is the last thing you should do.

- Medicine Making Music
by Brian Tarbox
In “And Your Bugs Can Sing” in September’s PragPub, Brian wrote about turning your log files into music. But what if the bugs you’re looking for are the kind that make you sick?

- Tangled Up in Tools
by Mike Taylor
Surely “Just learn these 57 classes” is not the re-use we were promised?

Departments

- Up Front
by Michael Swaine
iPad programming, career advice, troubleshooting tips, and more.

- Choice Bits
We thought you might like to know...

- The Working Geek
by Andy Lester
Andy spends a day helping people who want to get or keep a job, shares what he taught and what he learned.

- Swaine’s World
by Michael Swaine
Mike chats with Thom Hogan about developing Tycho TableMaker and how it was back in the day.

- The Quiz
by Michael Swaine
A monthly diversion at least peripherally related to programming.

- Calendar
Author sightings, partner events, and other notable happenings.

- Shady Illuminations
by John Shade
In which John contemplates the asymptote of the austere aesthetics of Steve Jobs.

Except where otherwise indicated, entire contents copyright © 2010 The Pragmatic Programmers.

Feel free to distribute this magazine (in whole, and for free) to anyone you want. However, you may not sell this magazine or its content, nor extract and use more than a paragraph of content in some other publication without our permission.

Published monthly in PDF, mobi, and epub formats by The Pragmatic Programmers, LLC, Dallas, TX, and Raleigh, NC. E-Mail support@pragprog.com, phone +1-800-699-7764. The editor is Michael Swaine (mailto:michael@pragprog.com). Visit us at http://pragprog.com

ISSN: 1948-3562

Up Front

iPad Programming, Career Advice, Troubleshooting Tips, and More
by Michael Swaine
You say you want to develop some serious software for Apple’s new iPad? Well, you can start right here. In this issue, Eric Freeman and Daniel Steinberg, authors of the forthcoming Pragmatic Bookshelf book iPad Programming: a Quick-Start Guide for iPhone Developers, walk you through the process of embedding a video in an iPad app.

Apple sold 300,000 iPads on day one (including pre-orders), so there’s already a sizeable market for your app, but what may be even more intriguing is the challenge this device offers. The iPad is a radically new platform, a new way of thinking about what computing devices do for us, and a new way of slicing up the market. Those who really get what the iPad is all about have a chance to dazzle consumers and have a lot of fun doing it.

You say you get a lot out of small, focused developer conferences, and it has crossed your mind that you could put on a conference yourself? James Edward Gray II has some advice for you. He and some friends did exactly that, and he shares what they learned in this issue’s interview.

You say there are certain things that drive you up the wall? Like other people’s software that you are struggling to maintain in the face of their abysmal coding and documentation? Or like an ever-increasing collection of libraries that you sense are pulling you farther and farther from a true, fingers-in-the-bits mastery of what’s going on in your own code? Or like figuring out what should go in your résumé? Then this issue of PragPub has something for you.

You say you want to know more? Well, we have an article on libraries by Mike Taylor, a dinosaur expert who wrote the first MUD to run over the Internet and who today runs a popular blog called The Reinvigorated Programmer. We have an article on troubleshooting by Mike Hostetler, who got his first computer at age 11. We have tech history and career articles by our resident tech historian, Dan Wohlbruck, and tech career expert Andy Lester; and we have an unusual article about music in the ER by frequent contributor Brian Tarbox.

And for the same low, low price, we’re going to throw in another John Shade essay, a state-of-the-art Events Calendar, and a challenging Quiz with all the extras. What do you say to that?

Choice Bits

We Thought You Might Like to Know...

What’s Hot

Top-Ten lists are passé—ours goes to 11. These are the top titles that folks are interested in currently, along with their rank from last month. This is based solely on direct sales from our online store.

1^

NEW

Seven Languages in Seven Weeks

2^

3

Hello, Android

3v

2

The RSpec Book

4

4

Agile Web Development with Rails, Third Edition

5^

10

Beginning Mac Programming

6^

NEW

Code in the Cloud

7v

1

Metaprogramming Ruby

8v

5

iPhone SDK Development

9v

7

SQL Antipatterns

10^

NEW

ExpressionEngine 2

11v

6

Programming Ruby 1.9

Nibbles from the News Desk

If you haven’t noticed yet, PragPub is now readable online in HTML format, as well as in the PDF, .epub, and .mobi formats we’ve always published in. This means that you can now link to individual articles, look something up in an article from a different machine without having to re-download the entire PDF, and so forth. You may, of course, be reading this article in HTML, in which case you probably have noticed that fact.

We’ve also tweaked our awesome publishing engine to take good advantage of the screen on the Apple iPad. As of this issue’s press date, your editor had not yet taken delivery on his iPad and, gadget freak and magazine junkie that he is, he was champing at the bit to see how PragPub will look on that device.

Metaprogramming Ruby has been getting a lot of attention lately. Author Paolo Perrotta admitted to enjoying the spotlight when the book was slashdotted. As Steve Peter points out, the discussion is classic.

Paolo’s related article in the March issue of PragPub (“Much Ado About Nothing”) stirred some discussion, too, which you can read in our Forum.

Speaking of Steve Peter, he’s had some nice feedback on his recent articles Our Daily Beer and Our Daily Bread. Seems like there are some dedicated homebrewers and home bakers in our family of readers.

And Jason Huggins points out that his PragPub article JavaScript: It’s Not Just for Browsers Any More generated a top post (“for this fleeting moment,” he wryly notes) at hacker news.

The hottest topic in the Forum right now is PragPub subscriptions. Kindle subscription, maybe, and/or an RSS feed for each article? A lot of you would like to see the magazine appear on your bookshelf every month. We’re looking into that, and here’s a tip adapted from the Forum:

In Stanza, navigate to Get Books/Shared/Book Sources, press “Add Book Source,” give it a name, and use this URL as catalog URL:

http://pragprog.com/magazines.opds

The complete catalog of PragPub magazine issues can now be browsed and downloaded from within Stanza.

You can follow us on twitter here.

The Working Geek

Thoughts from Milwaukee JobCamp
by Andy Lester
Andy spends a day helping people who want to get or keep a job, shares what he taught and what he learned.

In late February, I attended and spoke at the third Milwaukee JobCamp. JobCamp is a day-long event filled with speakers, workshops and lots of personal networking. Although the name JobCamp sounds like it might be a sort of BarCamp or Unconference, there’s a schedule of speakers and activities planned well in advance. Attendees come from all job categories, all ages and all industries, not just technology.

As always, it was well worth the day off I took from work to go, mostly as a learning experience for me. Even if I were not speaking, I’d have gone. Here are some thoughts from the event.

Get Business Cards

I handed out about 50 business cards to people I met. I suggest that before you next go to a conference or a user group meeting, you get some business cards of your own. Doesn’t matter if you have a job or not, you should have a way of representing yourself with a physical reminder. Even if you have business cards from your employer, get some for yourself. Carry a few in your wallet or purse at all times so you can give them out at a moment’s notice.

Business cards are dirt cheap. For about $20 you can get 500 cards professionally printed on heavy stock that will stand up to the recipient’s pocket, purse or laptop bag. That’s great bang for the buck. Don’t go cheap and try to print them yourself on microperf laser printer card stock. People can tell.

Have your cards designed professionally. If you’re like most geeks, you probably know a graphic designer or two that you can sweet talk into throwing something together. In my case, it took my bribing my freelance friend Kristen with lunch for her to throw together some designs in PDFs.

Your business cards should have the following bits of information on them:

- Your name

- What you do

- Your email address

- Your phone number

In my case, it could be as simple as:

- Andy Lester

- Programmer, manager, author, speaker

- andy@theworkinggeek.com

- 815-245-1738

Do include your phone number, even if the phone is not your preferred method of contact. To many, especially non-geeks, it may be their preferred form. You never know where your next awesome job is going to come from, so don’t prematurely optimize away the potential for someone to reach you that way.

Remember that your card may not go to someone geeky. Don’t put anything on it that is going to be misunderstood by someone not in our subculture. Your geek buddies might be amused at your card saying “Bob Smith: Hacker and raconteur,” but the non-geek recipients of the card probably wouldn’t, and would pick up on “hacker” as meaning “computer criminal.” It’s a good thing for your card to get passed down to other people, so keep it appropriate for an audience of everyone.

If you have any sort of image on the card, make sure it’s clear what the image is, and why it’s significant. In my case, I have the cover of my book on my card, but many people have been confused. Although Kristen’s design is attractive, I never realized that it’s not clear the big heart that dominates the card is the book’s cover. I wanted people to remember that I have a book, but for many I think they just see a big heart.

Once you have your cards, don’t be stingy with them. Hand them out to anyone who might be interested. If you give out 100 business cards over a three-day conference, you’ve spent four or five bucks.

Consider What You Want to Be Remembered for

When I give a talk on job hunting, or write a column here or at theworkinggeek.com, I try to think about how I’m going to be remembered after the listener or reader is gone. My goal is to have one or two key points that stick in the mind of my audience, things that are new ideas. I want her to say, for example, “I was reading this article by Andy Lester, and he was talking about business cards, and I’d never thought about how cheap they are compared to the impression they make.”

This sort of thinking should be at the front of your mind as you work through the job hunt. I see posts on forums like Reddit like “Do I have to take out my nose stud for the job interview?” It’s not a matter of “have to” as much as “Do you want to be remembered as a great programmer with serious chops, or the guy with the thing in his nose?” You don’t want to let something negative, or even neutral but meaningless, overshadow your qualities.

What brings this to mind is the speaker at JobCamp who gave a talk about the importance of interpersonal networking when searching for a job. About halfway through a fine talk, he brought up his personal relationship with Jesus Christ.

I thought this was a bit foolish. Religion is one of those personal topics that has no place in business (see the chapter “Too Much Information” in Land The Tech Job You Love). But then he spent the rest of the talk comparing his walk with Christ to the personal networking of job hunting. I’m sure that 90% of the audience, regardless of their faith, remembers him as the guy who wanted to talk about Jesus.

Think Hard about Your Résumé

One of the most popular parts of JobCamp is the Résumé Doctor. A room of a dozen tables is set aside for one-on-one discussions between a job seeker and an “expert” on résumés. I put “expert” because there’s no certification for “résumé expert,” other than the assertion “I know what I’m talking about.” Naturally, as an “expert” I critiqued résumés for a few hours in the Résumé Doctor room.

The problems that I saw most in the résumés were:

- Lack of understanding of the reader

- Insufficient use of specifics and details

- Too much focus on absolute rules

In all my critiques, I talked about how the reader would perceive it, what he would take away from the document. I explained how the addition of details to achievement bullets make the stories come alive in the mind of the reader.

One of my résumé patients that most surprised me in this way was from a man who’d been a car salesman for twenty years and was looking at moving into customer service because of the weak automotive market. His résumé was all fluff and soft words. He said that he was a driven salesman, always working to close the sale and make the customer happy, but there was no evidence. I asked him if he was a good salesman, and he beamed, “Oh yes, I was top salesman in three of the last seven years at the dealership.” I asked, “Then why the hell isn’t that on your résumé? It’s like you’re saying the car gets great mileage, but not telling me what the mileage is.” A light bulb came on over his head, and he realized that his résumé was all about sales, something that he excelled at. He’d never considered it in that way before.

In technical résumés I see from day to day, it’s the same thing. The writer asserts she’s worked on “large software projects,” but there are no specifics to back it up. How many lines of code? How many people on the team? How long was the project? Someone might claim to be a strong team player, but without giving examples. Examples and details back up your claims, and make you more memorable.

There’s No Right Answer and There Are No Rules

When I was asked, “Is it true I can’t have a résumé longer than two pages?” (and every person asked me) I referred to Roger Ebert’s rule about how long movies should be: “No good movie is too long; no bad movie can end soon enough.” In résumé terms, that means that if you have more than two pages of solid information about your background, then that’s OK. Go ahead and list it. If you have a two-page résumé that’s filled with 50% fluff, then it should be one page.

A Perl axiom is “TMTOWTDI,” pronounced “Tim Toady,” and it stands for “There’s more than one way to do it.” Nowhere is that more true than in job hunting.

More than a few résumé patients told me, “But this other guy told me that I should ....” Sometimes it was said with a note of confusion, but usually with frustration, even anger. One of my résumé patients started crying in frustration in the middle of a discussion about the pros and cons of using one approach or another on her résumé.

If there was only one Right Answer to how to find jobs or how to land them, there wouldn’t be so many books out there. We’d just buy a single book that told us all the answers, some sort of job hunting Bible, and that we’d just have to do what that book said. Of course, it’s not so simple. Every job and hiring manager is different. Every job seekers and job hunt is different. We have to adapt every step of the way.

Lifetime Employment Is Dead. Your Career Is Not.

I steal this section name from item #18 in Tom Peters’ excellent new book The Big Little Things: 163 Ways To Pursue Excellence because it so beautifully sums up what I saw in the thousands of faces that came through that space. People from all areas of industry in every sort of job were out there looking to improve their situation because the rug had been pulled out from under them.

I put my seat belt on every time I get in a car, because I expect that I’m going to get in a crash. By the same token, I expect that I am going to get fired some day. It’s happened before, and it can happen again.

That you’ve spent your time reading this article shows that you understand the value of keeping yourself hirable. Keep it up.

Finally, if you get the chance to go to a gathering like Milwaukee JobCamp, go. Even better, if you can volunteer, do it. To handle the 2,000 attendees, organizers Todd Nilson and Angela Harris had 160 volunteers handling speaking, directing people, taking registrations and so on. I know that if I ever need help in my job hunt, Angela and Todd will remember me and help out however they can. In times like these, there’s little more valuable than that.

Andy Lester has developed software for more than twenty years in the business world and on the Web in the open source community. Years of sifting through résumés, interviewing unprepared candidates, and even some unwise career choices of his own spurred him to write his nontraditional book on the new guidelines for tech job hunting. Andy is an active member of the open source community, and lives in the Chicago area. He blogs at theworkinggeek.com, and can be reached by email at andy@theworkinggeek.com. Send the author your feedback or discuss the article in the magazine forum.

Swaine’s World

Programming Back in the Day
by Michael Swaine
When we were young(er), we used whatever tools we had for solving our programming problems. Mike reflects on the early days of Macintosh programming, naive entrepreneurship, and tables with Thom Hogan.

In the earliest days of Macintosh programming, I was part of a garage startup called Macreations. The company eventually produced a product and made money, no thanks to me. Here’s how I remember that experience.

Time After Time

When Apple introduced the Macintosh back in 1984, two friends and I started brainstorming about how we could develop software for it. Thom Hogan, Roger Chapman, and I sat in Thom’s garage/office and sketched out plans for a game we called Time After Time. I’m really hazy on the details, but I seem to recall that it was story-based and that you could go back in time and change history. Something like that. It was going to be rich in historical detail and built on a nifty artificial intelligence engine that we would create.

Thom and Roger took a copy of Apple’s ring-bound developer manual, Inside Macintosh, with them for a weekend in Tahoe. The plan was to spend three solid days getting up to speed on Mac programming, and then come back and jump right into development. They returned bleary-eyed with a “Hello World” application that they seemed inordinately proud of.

But they had reason to be proud, because the learning curve for Mac programming back then was modeled after the face of Half Dome in Yosemite. It was widely repeated that the prerequisite for reading Inside Macintosh was a thorough understanding of Inside Macintosh, and this wasn’t so much a witticism or a zen koan as a straightforward description of the Mac developer experience. Although it may also be a zen koan.

I didn’t need to get up to speed on Mac programming because I was going to be responsible for the supernifty AI engine, which I would develop in whatever language I deemed appropriate. Roger would do the real hardcore programming and Thom would do some of everything, including concept, story development, and running the company.

But then I got a real job, Roger got busy with other things, and there was no time for Time After Time. Thom later teamed with hotshot Mac developer Kurt Matthies, to whom he eventually handed over management of Macreations, and along the way they produced a product called Tycho Table Maker.

Which is what I want to tell you about.

Money on the Table

“Tycho was a result of my doing the PC Programmer’s Sourcebook,” Thom told me recently. That book was nothing but tables, and it was a bear to produce. Thom sought in vain for software to help him create the tables, eventually settling for doing them all in Excel, which “caused all kinds of problems.”

After he finished the book Thom “sat down and designed the product I would have wanted to do that book, hooked up with a Mac programmer,” and created Tycho Table Maker.

“From the beginning Tycho was really a one-shot for me,” Thom said. “It seemed logical to me to complete the product, make some money off it, then sell it. We did a few deals along the way, including a bundling arrangement with Ashton Tate (FullWrite) that actually allowed us to pay back investors and make some money. Right after that deal expired Aldus attempted to buy us. The deal on the table was US$1.5M, and since we had paid off the investors, it was going to be pretty much the three primaries (me and two programmers) who benefited.”

But the Aldus deal fell through, and that’s really what I want to tell you about, because of how it relates to programming today.

Just Not Your Type

Thom called Tycho “middleware.” I don’t know if he coined the term, but what he meant by it was this: “the goal was to suck data out of a database, format it as a table, and stick that table into page layout or word processing.” Because Tycho occupied this middle ground, it wasn’t primarily a product to be sold to end users, but one designed to get bundled with a page layout or word processing application. Thus the deal with Ashton-Tate for FullWrite, the later deal with Nisus, and the failed sale to Aldus.

“[W]e were deep in due diligence and [Aldus President Paul] Brainerd wanted the deal done,” Thom said. It was technical problems that scuttled the deal. “[T]hey didn’t have a library for typesetting. [T]here was no way to exactly duplicate the typesetting. We couldn’t call their typesetting, since it was hard-coded and not isolated and no one even knew how it worked! Thus, we couldn’t guarantee that a table within Tycho paged within a PageMaker document would typeset the same way as the main document.” Unlike PageMaker, Tycho was designed to call a typesetting module; it wasn’t hard-coded to any given typesetting method.

As reviewers pointed out at the time, Tycho wasn’t really integrated with FullWrite, it was just bundled with it. Later, when Nisus bought the product, it did get integrated with NisusWriter and is the table component of that product today. But none of these deals, successful or not, went smoothly.

As problematic as it was working together with big companies back then, Thom sees it as even harder today. “Microsoft and Adobe are more unreachable than before. Ditto for the computer companies." Thom works with camera companies these days, and finds them just as unapproachable. “I’m in Japan at the moment,” he emailed me, “and just met with several luminaries at Nikon, but that took an enormous amount of string pulling.”

While Thom is probably right about the difficulties independent developers have in getting attention from the big companies, it seems to me that the kind of problem he faced with Tycho would be approached differently today. The big companies may be unapproachable, but their software isn’t necessarily so. The big companies participate in standards groups and expose their software’s functionality through APIs and generally recognize the value of third-party add-ons.

The world of software development, as Mike Taylor points out in his essay on libraries, is more collaborative than it was in the days when Thom and Kurt developed Tycho. “[T]hat’s both a good and a bad thing,” Thom thinks. “The good is that we have better building blocks to work from now. In the old days we had to build our own blocks,” (feel free to picture here a group of cavemen sitting around a fire, baking bricks with words like “TYPESETTING” and “STYLESHEET” carved in them) “which meant a lot of needless duplication for simple things. The bad is that the building blocks are often too center-of-the-road or limiting.”

Thom’s focus these days is on photography. He defends his opinion on the downside of generic components with an example from photography. “I don’t know of any imaging component that uses precise enough math. Even Adobe’s own modules get them into trouble occasionally (try plugging in a white balance setting of 1 for red, green, and blue for a file and see what happens: the Adobe software doesn’t know what to do with aninteger!) We all had to stop using a true UniWB (1,1,1) and use a nearUniWB (1.0004, 1.0001, 0.9998 for instance).”

Thom admits to missing the days of assembly-language programming and total control of your product. “If the program ran too slow, produced inaccurate results, or wandered off into memory it shouldn’t, at least it was my own fault. Libraries have this habit of doing all those things for you ;~).”

Having made his mark in publishing (InfoWorld editor, dozens of technical books), software development, film and television production, and music, Thom Hogan now spends much of his time photographing the wilds and teaching photography workshops in some of America's most interesting outdoor locales. He also writes books about Nikon cameras. His work can be found here. Send the author your feedback or discuss the article in the magazine forum.

Embedding a Movie on iPad

It’s Not Just an iPhone with an Ego
by Eric T Freeman, Daniel H Steinberg
The iPad comes with a bunch of new programming APIs, designed to support its revolutionary new interface. Here’s a look at just one—the ability to embed movies into your application.

Anyone who has held an iPad in their hands knows that it’s so much more than a big iPod touch. The additional real estate comes with support for custom gestures, enhanced input, sophisticated text processing, and so much more. And yet, at its core, the iPad is designed for media consumption—the large, in-hand screen is perfect for graphic display, especially video. With an iPhone, you can only display video in a full-screen viewer, while the iPad’s SDK allows you to build video right into your applications and fully customize the user experience around it. The SDK also exposes the state of the player, so you can directly control the video and coordinate its playback with the rest of your application.

In this article, we’re going to scratch the surface of the movie player’s capabilities by embedding it in an application. On the real device you can overlay other views on top of it, create navigational thumbnails, and stream content. If you’ve used video player frameworks in the past, you’ve probably found them to be difficult to work with, but using Apple’s new framework, we’ll have a sophisticated player up and running in no time. Note: this article is adapted from our new book, iPad Programming: a Quick-Start Guide for iPhone Developers. Both the book and this article assume you’re already comfortable with developing for the iPhone.

Before we start, let’s save us all some time. We already have the basic iPad project code written for you, so just download the code from the book and navigate to the movieplayer/MoviePlayer1 folder.

Set Up a View for the Movie

Go ahead and open the project in the downloaded folder, and you’ll find that we’ve added a video to the Resources directory called Movie.mp4. We’ve also added the MediaPlayer.framework to your frameworks folder.

First, let’s focus on getting a MPMoviePlayerController instantiated—this class manages all the details of playback and gives you a view that you can add to your own view hierarchy to display video. The MPMoviePlayerController can also display our video content full-screen.

Let’s start this process by opening the MoviePlayerViewController.xib Nib file in Interface Builder and adding a view that can be used to hold the MPMoviePlayerController’s video. (Just to make sure we have this straight: the MoviePlayerViewController is the main view controller for our application; the MPMoviePlayerController is the iPhone OS 3.2 controller for managing video playback.) Begin by selecting the MoviePlayerViewController’s main view and resetting its background color to solid black. Then drag a UIView object from the Interface Builder Library into the view. You’ll want to use the Size tab of the Inspector to configure your new UIView. Make sure to copy the size and autosizing constraints in your version.

Now we need to create an outlet to this new view in our MoviePlayerViewController header file, like this:

@interface MoviePlayerViewController : UIViewController {

UIView *viewForMovie;

»    MPMoviePlayerController *player;

}

@end

Here we’ve defined a UIView named viewForMovie and also declared it as a property that is an IBOutlet. Don’t forget to also add the synthesize directive to the MoviePlayer1ViewController.m file:

@synthesize player;

Now let’s wire things up by going back to the MoviePlayerViewController.xib Nib file in Interface Builder. Connect the viewForMovie IBOutlet we just declared to the UIView. To do that, control-click the Nib file’s File’s Owner object and drag to the new view. When the connection popup appears, choose viewForMovie.

Meet the MPMoviePlayerController

With the Interface Builder work out of the way, let’s focus on code. We’re going to add an instance of the MPMoviePlayerController class by declaring it in the MoviePlayerViewController.h header file. First, we need to import the movie player’s MPMoviePlayerController.h file, and then add a declaration for the player; we’ll also go ahead and declare the player as a property. While we’re here, let’s also add a declaration for a method named movieURL (we’ll come back to this shortly).

#import <UIKit/UIKit.h>

»  #import <MediaPlayer/MPMoviePlayerController.h>

@interface MoviePlayerViewController : UIViewController {

UIView *viewForMovie;

»          MPMoviePlayerController *player;

}

@property (nonatomic, retain) IBOutlet UIView *viewForMovie;

»  @property (nonatomic, retain) MPMoviePlayerController *player;

»  -(NSURL *)movieURL;

@end

Let’s take a look at the MoviePlayerViewController.m implementation file. We’re going to start in the viewDidLoad method and instantiate the MPMoviePlayerController there. Let’s add the code and then walk through it:

- (void)viewDidLoad {

[super viewDidLoad];

self.player = [[MPMoviePlayerController alloc] init];

self.player.contentURL = [self movieURL];

}

Here, we’ve first alloc’d and init’d the movie controller and assigned it to our player property. Next we assigned a content URL to the player—this is the location of the video content we sent the player to play back, which can be a local file in the bundle or a network-based URL. For now, we’re going to use a local file for our video content. Let’s take a quick detour to look at the movieURL method that constructs a file-based URL to the video content in the bundle:

-(NSURL *)movieURL

{

NSBundle *bundle = [NSBundle mainBundle];

NSString *moviePath =

[bundle

pathForResource:@"Century3min"

ofType:@"mov"];

if (moviePath) {

return [NSURL fileURLWithPath:moviePath];

} else {

return nil;

}

}

If you’ve ever constructed a URL to an image or other resource in the bundle, this code should look familiar: here we obtain a reference to the bundle, then construct a URL to our movie, wrap it in an NSURL object, and return it. In the book we’ll return to this code and construct some network-based URLs to stream content to the iPad.

But now, back from our detour, we’re going to look at one of the most important concepts in this article: the use of the MPMoviePlayerController’s video property. As we mentioned earlier, the player controller maintains a special view that can be added as a subview to any of your views to display video content. Treat this view with kid gloves—although there are some interesting reasons to add our own subviews to the player’s view, this is in general an opaque object under the control of the player, and should be treated that way.

- (void)viewDidLoad {

[super viewDidLoad];

self.player = [[MPMoviePlayerController alloc] init];

self.player.contentURL = [self movieURL];

»      self.player.view.frame = self.viewForMovie.bounds;

»      self.player.view.autoresizingMask =

»             UIViewAutoresizingFlexibleWidth |

»             UIViewAutoresizingFlexibleHeight;

»

»      [self.viewForMovie addSubview:player.view];

»      [self.player play];

}

Getting access to the MPMoviePlayerController’s video view is easy; we just access the player’s view property like any other property, and that’s what we’re doing in this code. After we have a reference to the view, we’re first setting two properties: the view’s frame and a couple of masks that control how the view can be resized. The frame, like the frame of any view, controls its onscreen size. Here, we’re getting the frame from the movieForView object and mirroring that. For the masks, we’re setting the view so that if necessary, it can be resized by width or height.

Now for the interesting part: we’re taking the player controller’s view and adding it as a subview to the viewForMovie view that we created earlier in Interface Builder. With that done, we send the player the play message to start the show. At this point, just build and run your project and you should see video playing in your UIView, just like the picture in the margin. Touching the view should expose some controls, including a fullscreen control, and rotating the device should give you reasonable resizing behavior. (The movie we're showing is copyright the Blender Foundation).

The Big Picture, or What Just Happened?

Let’s think about what just happened—it can get a bit confusing the first time through. While this may seem a bit complex, once you get past all the views and controllers involved, it is actually fairly simple.

What we’ve done is create a MPMoviePlayerController object that acts as the controller for displaying video content. We can use this controller to manage all the aspects of video playback, including stop, start, pause, and other actions. This controller also exposes a built-in property called view that we can obtain a reference to and then add to our own views in order to display video. And that’s exactly what we did. We first created an UIView in Interface Builder to act as a landing place for the video view, then, after creating the MPMoviePlayerController, we took its internal view and added it as a subview to our UIView.

The result? Video playback right in our iPad application.

Daniel H Steinberg wrote Cocoa Programming: A Quick Start guide for Developers, the Pragmatic Programmers’ best-selling book on developing Cocoa applications for Snow Leopard. A long-time Mac developer, Daniel also teaches courses on Mac OS X, iPhone, and iPad development for the Pragmatic Studios. Eric T Freeman is a media company executive and co-author of two best-selling books: Head First Design Patterns and Head First HTML with CSS & XHTML. A computer scientist with a passion for media and software architectures, Eric has been an Apple programmer since the days of the Newton. Eric holds a Ph.D. from Yale University. Send the authors your feedback or discuss the article in the magazine forum.

The Red Dirt Interview

Chatting with James and Dana Gray about the Red Dirt Ruby Conference
interviewed by Michael Swaine
Far out in the remote red dirt country of Oklahoma—well, actually it’s in Oklahoma City—it’s the Red Dirt Ruby Conference, a unique experience in professional education and networking.

Regional programming conferences are an increasingly important part of the working programmer’s ongoing education. You’ve doubtless attended your share, and it’s possible that the idea of putting on your own conference has crossed your mind. James Edward Gray II and a few of his friends had that idea, and they ran with it. The result, the Red Dirt Ruby Conference, starts next month in Oklahoma City. I thought it would be enlightening to chat with James about what it took to put on a conference, and what he’s learned in the process.

Dave Thomas of Pragmatic Programmers and Jim Weirich of EdgeCase will deliver the keynotes at the conference. The organizers hope to make it a uniquely focused and productive experience, partly by limiting attendance. The conference is organized around four themes:

1. Ruby: The Ruby language still has the power to surprise us. This theme is focused on Ruby syntax, gems, and good development practices.

2. Rails 3: Ruby on Rails is crossing a huge milestone. This theme is centered on topics such as routing, metal, the new response system, and advanced queries.

3. NoSQL: Database choice affects application performance and scalability. This theme will focus on databases such as MongoDB, Riak, Redis, and Tokyo Cabinet.

4. Servers: Ruby is well suited for web based applications. This theme will focus on tools such as Rack, Unicorn, EventMachine, Resque, and AWS.

Here’s what James—and Dana Gray, who joined in the conversation—had to say:

ms: Whatever possessed you to take this on?

jg: That’s a good question. We may need to plead Temporary Insanity.

I have wanted to do a Ruby conference in Oklahoma for some time now, mainly for selfish reasons. The official conference hosted by RubyCentral seems to bounce from coast to coast now and driving my wheelchair van all that way for a weekend event just isn’t much fun. There are quite a few regional conferences for Ruby, but again they tend to be towards the coasts. The closest, before we put this event together, was the Lone Star Ruby Conference in Austin, TX. I have attended that each year and it is terrific, but they give me a lot of flak for my Okie accent in Texas.

ms: What about the location? Oklahoma is not everyone’s first thought when they think of attending a conference.

jg: Travel distance aside, I’ve always felt Oklahoma could support a real tech conference. You may not have heard of us yet, but our little town is starting to make some waves. We are very startup friendly and we will be hosting the U.S. Conference of Mayors this June, just so they can observe how well our economy is still doing.

ms: I imagine doing a big conference like the Red Dirt Ruby Conference is a lot of work.

jg: Of course. A couple of the organizers had looked into doing it separately, but the size of the task scared us off. It wasn’t until we came together with a like-minded vision that we had the resources to do it.

ms: It seems that with so much information online, and technology changing so quickly, smaller, regional conferences like yours are getting more important, and the reasons to go to big conferences (unless your employer will pay for the international travel) are disappearing.

jg: Having been to both types, I agree that the regional conferences are becoming more important.

I feel that’s because of the people. Regional conferences have fewer people. That makes the key interactions more accessible to everyone. You can track down a speaker and have a quick chat with them about their topic. If you arrange extra-curricular events, like the Hackfest we have planned for the Red Dirt RubyConf, a significant portion of the speakers and industry experts will be there with us mere mortals. Those experiences really make an event.

ms: So what are the benefits of a regional conference?

jg: I think the primary benefit is the scale. We just don’t have the resources to think on the scale of a multitrack event that seats thousands. If you embrace that constraint, it comes down to the question of how you can pack the best content and experience into the time and space you have.

That means you have to make the tough choices like, how do I get these 50 speeches down to the 16 I can use. Those cuts are painful, but it also means we are really trying to maximize every aspect of the conference we control. I believe that will be noticed by those who attend.

ms: What are you trying to do with this conference that’s different, and why?

jg: First, we aren’t trying to be different just to be different. As avid conference attendees ourselves, we have seen a lot of things we like. We want to stand on the shoulders of those giants. Two of our biggest inspirations have been the Lone Star Ruby Conference, which taught us to favor their “cruise ship experience” and introduced the topical trainings, and the MountainWest RubyConf, which showed us that a single track conference with time restrictions can really build a killer program.

ms: So you’ve emulated those conferences?

jg: We kept those ideas. In a lot of ways we just tried to do even more of what we feel is working well. For example, our program has even tighter time restrictions than MountainWest RubyConf, limiting the majority of our speakers to just 15 minutes. We didn’t make that choice lightly and we have thought a lot about how we are going to make that work. We’ve divided the speakers into four themes of discussion. Each of those themes will have a 30 minute introductory speech to set the stage. Then we can followup with three 15 minute talks that are tightly focused. We feel that will allow us to get into multiple aspects of each theme even though we are just a one-day event. We close each theme with a panel Q&A from all four speakers. This relieves speakers from needing to allow time for this, which is important in making their limited time really count. As a bonus, attendees will get multiple perspectives on the questions they ask. Everybody wins.

Then we follow the conference up with trainings provided by experts on the same themes covered the day before. That allows attendees to get hands-on mentoring. We’ve got Envy Labs giving the same training they will be doing at RailsConf this year, Squeejee sharing their deployment expertise, Glenn Vanderburg helping me teach how to clean up Ruby code, and Basho teaching their Riak NoSQL database. It’s a full package we have created.

ms: Dana, you wanted to add something?

dg: Yes. Building on the cruise ship experience idea, we wanted to have a conference that kept everything together in one place. We felt by having the conference location next door to the hotel allowed participants to spend less time traveling from place to place and more time socializing and networking. Because the hotel provides service to and from the airport, we made it easy to get to the venue and then set it up so you don’t have to leave if you don’t want to.

Another part of the cruise ship experience we are trying to replicate is the food. We will provide breakfast and lunch on both the conference day and the training day and we will provide dinner on the night of the conference. Since the keynote is after dinner, we didn’t want anyone to feel rushed to eat so they wouldn’t miss such a great speaker. Not only are we providing food, our hope is that people will find it first-class fare. We’ve worked hard to build menus that cater to a variety of appetites, from vegetarian to the carb-conscious without sacrificing quality or selection.

ms: Is there anything apart from the content of the sessions that’s particularly Ruby-ish about this conference? I mean, would it make sense for someone to copy the model for a Java conference, or would that be a bad fit culturally or in some other way?

jg: I don’t think the ideas we are trying are inherently tied to Ruby, no.

It is interesting that regional conferences have have exploded in the Ruby community, though, and our culture encourages this kind of experimentation. I wonder if we would have been as tempted to try and build such an event if we were immersed in the Java world instead.

ms: What are you learning in the process of doing this?

jg: That organizing conferences is scary hard.

I always think, “Alright, I’ve finished that task up.” Then two weeks later I think, “Am I still doing this?” Yikes!

You have to have passion to do this. Luckily, Ruby is my second favorite thing and the first one, my wife Dana, is helping me organize the event.

I have planned a three week nap for myself as well, starting May 8th.

ms: What has the process been? What have you had to do to make it happen?

jg: This is roughly the order we did things in:

- Secure respected keynote speakers, so people would take us seriously

- Get great training content so we had something to offer

- Make an open call for proposals to fill out the program

- Find a location that could support our needs

- Sort out the extras like food, so we knew what we had to charge

- Line up sponsors to get that number down for attendees

- Open registration

- Do an interview in PragPub so people will know how cool we are and want to come join us

Short little bullet points make those seem so small to me now, but they sure felt big as we struggled to make them happen. I’m sure we will have quite a few other challenges as the event approaches.

It’s also worth noting that promoting the event is something we do just about every day in some form or other. You have to get the word out.

ms: How easy is it to line up speakers for a conference with no track record?

jg: I am very lucky to know some wonderful people in the community. I asked several of them to come and most of them took me up on the offer.

I started with my programming heros: Dave Thomas, Jim Weirich, and Glenn Vanderburg. We are super lucky to have them all and that’s exactly why they are my heros!

That said, there were still plenty of surprises for us organizers. A lot of people wanted to be a part of this event. We have some real heavy hitters from the industry: Twitter, Google, Engine Yard, 10gen, ThoughtWorks, Hashrocket, and more. They are coming to show how they use Ruby, which is so valuable to the attendees.

There was a little bit of pushback on the tight schedule, but I hope it goes over as well as we have planned—and it will be less in doubt in future years. We received at least as much praise for trying it, so we are not the only people who believe we are on the right track.

ms: How about attendees?

jg: We’re in that process right now, so I’ll let you know.

My hope is that people will see the program we have lined up and feel they would be crazy to miss it. That’s sure how I feel.

ms: What led you to the particular model of conference; e.g., strictly limited attendance?

jg: Early in our conversations one of the organizers told me, “Build the conference you have always wanted to attend.” That’s exactly what I did. And they have actually trusted me to do it, crazy ideas and all. Of course, if this year flops, I suspect they will go hunting for a new Idea Man next year.

I think the fact that it’s my ideal conference is really reflected in the program. One of the speakers commented that Red Dirt RubyConf is really shaping up to be a “down in the (developer) dirt” event. That makes sense. I’m a developer through and through. I want to see what other developers are using and trying so I know what I need to be keeping an eye on.

Of course, I’m not perfect. A couple of people have pointed out that I didn’t build in much room to discuss the business side of our business. That’s a valid complaint. It isn’t on my radar enough. It is now though and I’ll make it up to them next year.

ms: One last question: who should come to the Red Dirt Ruby Conference?

jg: While we originally planned an event for the central Ruby communities, the conference is much bigger than that. We had speech proposals from three non-U.S. countries. We would love to see our attendance be as varied.

I feel our program is strong enough to rival the national Ruby events. If you want to see how Google and Twitter scale or really get into this NoSQL movement everyone has been talking about, Red Dirt RubyConf is the right place for that. You can get information, trainings, and plenty of face time with like-minded developers and experts.

That said, we know everyone can’t make every conference and we don’t want to leave anyone out. We have been working hard to ensure we will have the resources to stream the presentations live for those who cannot attend. We are also making high-definition videos of the content available at a small expense. Anyone who wants to will be able to catch the Red Dirt RubyConf.

ms: OK, well thank you both for your time and insight.

jg: Thank you for taking the time to talk to us about our fun new hobby.

- May 6-7, Oklahoma City, OK
Red Dirt Ruby Conference

James Edward Gray II is a Ruby and Rails programmer by day. However, he often spends hobby hours helping to maintain TextMate’s Ruby integration. This gives him an ongoing excuse to play with his two favorite toys pretty much all the time. He is the author of TextMate: Power Editing for the Mac and Best of Ruby Quiz. Send the author your feedback or discuss the article in the magazine forum.

When Did That Happen?

The Printing Press and the Printer
by Dan Wohlbruck
Dan’s got printer’s ink in his blood. This April he tells the story of printing that began in April, 1863.

The idea that would ultimately lead to the computer printer actually started with shingles. The kind you put on a roof, not the kind whose symptoms include a painful rash.

Bullock’s Rotary Press

Sometime in the mid-1830s, an enterprising young foundry man and machinist by the name of William Bullock invented a machine to cut shingles. It was a real labor-saving device. Overcome by the smells of success and money, Bullock moved to Savannah, Georgia, and started a shingle-cutting factory. He went broke.

Undaunted, Bullock kept inventing things. He made artificial limbs, seed planters, a grain drill. During the late 1850s, Bullock moved to Pittsburgh and entered the newspaper business. By 1861, he had designed and built a printing press for the Cincinnati Times. Then, on April 14, 1863, he was granted a patent for the continuous-roll printing press. This invention would change history, and have a role in recording it.

By 1865, the world’s first continuous-roll rotary printing press was in operation. The Bullock press, as it came to be known, could finish up to 10,000 pages per hour as it printed on both sides of the paper. Bullock’s press could cut the continuous roll of paper into individual sheets as if they were shingles, cutting either before or after printing. The Bullock press is said to have enabled the creation of mass-circulation newspaper publishing. Without it, neither Hearst nor Pulitzer would have had an audience.

Sadly, Bullock’s story has a tragic ending. In 1867, just two years after his first press went into operation, he fell into a press as it was being constructed. Dare I say it? He was a man consumed by his work.

I have a personal interest in the rotary press. When my father returned from World War II, he used his GI benefits to become a pressman. In 1950, he moved our family from Altoona, Pennsylvania, to Harrisburg, where he went to work for a specialty printing house. The MacFarland Printing Company occupied an entire city block in Harrisburg. I still remember the time that he took me to see the press room. Everything about it was big. Huge rolls of paper fit on one end of the press and somehow, magically, full-color catalogs came out the other end. I was entranced.

IBM’s High-Speed Computer Printer

It was at about the same time, the 1950s, that computer manufacturers realized that the mainframe computer was going to need a new output device that could print all manner of documents. As well as continuous form computer paper, what we always called green bar because of its alternating rows of light green and dark green, mainframe users wanted to print insurance policies, telephone bills, paychecks, and everything in between.

In 1959, IBM came up with the answer. The IBM archive describes the 1403 printer this way: “The IBM 1403 Printer is a completely new development providing maximum thru-put of forms and documents in printing data from punched cards and magnetic tape. The printer incorporates a swiftly moving horizontal chain (similar in appearance to a bicycle chain) of engraved type faces, operated by 132 electronically-timed hammers spaced along the printing line. The impact of a hammer presses the paper and ink ribbon against a type character, causing it to print. The chain principle achieves perfect alignment of the printed line.” IBM bragged that the 1403 printer was four times faster than any competitor. The IBM web site maintains that the 1403 “launched the era of high-speed and high volume printing, and was not surpassed for print quality until the advent of laser printing technology in the 1970s.”

Both Sides? No

For all of IBM’s claims that the IBM 1403 printer was an entirely new development, it was truly a descendant of Bullock’s invention, a mini rotary press. Although it couldn’t print on both sides of the paper at once, it was fed by boxes of continuous-form paper, perforated at each page boundary, and it produced high-quality printed documents. Like the rotary press, the 1403 gave birth to an array of companies to support it. Moore Business Forms designed and prepared the custom forms, like bills and paychecks, that were needed for the mainframe’s new applications. Unlike the Bullock press, the 1403 didn’t cut the paper, so a number of manufacturers built decollators to remove carbon paper and bursters to separate each sheet from its perforation.

In the wake of the invention of the 1403, the mainframe computer room resembled nothing so much as my dad’s press room—with tape drives thrown in for good measure.

Although IBM discontinued the 1403 in 1971, it remained the printer of choice throughout the decade.

But all good things must end, and the Xerox laser printer, with its cut sheets of paper and its ability to print its own forms, brought an end to the era of large continuous-form printers. From Bullock’s press to computer mainframe printing took about one hundred years. It all started in April 1863—and that’s when it happened.

Dan Wohlbruck has over 30 years of experience with computers, with over 25 years of business and project management experience in the life and health insurance industry. He has written articles for a variety of trade magazines and websites. Send the author your feedback or discuss the article in the magazine forum.

A Troubleshooter’s Tale

Three Principles and a Big Ball of Mud
by Mike Hostetler
Sometimes fixing the problem is the last thing you should do.

Once I was put in charge of a big behemoth of an application. There were no unit tests, no actual design and, really, no sign of any sort of craftsmanship. Just quick fix upon quick fix upon quick fix. It was nothing but a Big Ball of Mud.

I was told that there was one particular recurring error that the users complained about occasionally. It was a data-quality issue, and the previous developer gave me instructions on how to fix it manually. Sure enough, I soon got a phone call from a user who said the problem had happened again. Before hanging up, the user said off-handedly, “I don’t know why our software never works!”

Me: “What do you mean? I thought this only happens once in a while.”

User: “No! This happens all the time!”

So I apologized profusely and did the quick fix for his specific problem. Then I cleared my schedule and dedicated at least the rest of my day on this issue.

Reproducing it was easy. That only took a few minutes. And then I dug into the code to figure out what was going on.

Getting through the muck inside this application was difficult to say the least, but I finally found what was causing it. Oddly enough, there was a large comment in that section of code, discussing the exact problem I was looking at. They had a fix, but the comment said that there had to be a better way and that “we will fix it soon.” The date on that comment was four years ago.

So I put a log statement in that code, ran what I needed to in order to reproduce the problem, but nothing—no log message! I studied the code a bit more and found, in another section, the same code (sans comment) that was copied and pasted in. I put my log message in there and—bingo! We have a hit! The bug was still there, but at least I knew where it was coming from.

I then extracted the well-commented code into its own method, removed the copied part and had it call the new method. Another test showed that my new method was being called.

Now that the problem was isolated, I could finally look at the code. The cause was unbelievably simple, now that I could see it. Instead of making a copy of the object and then changing its state, it was changing the state first, and then copying it. The user was right, of course—this never, ever worked! I made the change and, presto! Things were now working.

The user was happy to hear when I told him that I had just fixed the problem, once and for all.

The story above is one of many adventures debugging or troubleshooting applications or systems of applications. The big, strange problems almost always end up being something silly that someone (usually me) forgot to do or simply overlooked. These experiences have led me to develop a simple process that helps get the problem fixed once and for all. And generally in a timely matter.

It’s a three-step process:

1. Be able to easily reproduce the problem,

2. find the cause,

3. fix the problem.

It seems easy, doesn’t it? Yet the steps aren’t always easy to follow.

Easily Reproduce The Problem

If you can’t reproduce the problem easily, how can you ever be sure that the problem is fixed? And then how can you be guaranteed that your fix worked? Would you bet your job that you fixed a problem that you were not able to reproduce? Probably not.

And note that I said “easily.” If it takes you a day or even an hour to set up your application to the state where the bug occurs, then that isn’t “easy.” Sure, it can take you a day or two to do your first reproduction, but after that it shouldn’t take more than 5-10 minutes to do it again. This is important, because you will be doing this over and over again when you finally get to fixing the problem.

Sometimes disciplining yourself to start by reproducing the problem is difficult. And yes, when you are called at home at 2:30 in the morning, maybe a Band-Aid is what is needed. But when you get to the office, after getting your cup of caffeine you should try to reproduce the problem with the pre-Band-Aided code. That way you see if your Band-Aid is a permanent fix, or (hopefully) you will see something better to do.

Note that in my story above, that’s the first thing that I did. Before opening the code base, I went to see if I could reproduce the problem.

Find The Cause

People often think they know immediately what the problem is, but a lot of the time the cause is not as simple as you think. Usually you only get to see the big side-effect, not what might be the simple underlying cause. In my situation, the previous developers decided they had fixed the problem, but never went back to see if it worked. Or they just thought that it was an anomaly, never willing to dig into it. Heck, no one even seemed to ask a user if the problem was fixed!

So when I took on the task to dig into it, I spent most of my time trying to isolate the exact place where the bug was. Note that I also reproduced the problem even when I put log messages in—just so I knew what was executing.

Fix The Problem

Finally, you can fix the problem. It’s amazing how many developers jump straight to this step, yet it’s really the last thing you do. You make an attempt at a fix, and then you try to reproduce the problem again. If it’s fixed, great. If not, start figuring out why and make more changes, then try it again. It’s an iterative process—keep reproducing the problem and changing code until it goes away.

When you finally have it fixed, you should then start testing other parts of your code to see if you broke anything else. Unit tests are wonderful for this—just run your suite again.

I said that it’s common to jump right into fixing the problem, but some developers really don’t want to fix the problem—they like to blame the complier, the application server, the OS, some library they are using. This is a cop-out. There are plenty of people using the same tools you are and they manage somehow. And, while these tools may have bugs in them, that’s not something you can control—you only have control of your application. So yes, you may have to work around some flaky library or some weirdness with the application server. That’s part of your job.

One more note on fixing the problem: it may not involve changing any code. Sometimes it’s a configuration issue, or some application you depend on has a problem that the maintainers don’t know about.

To the user yelling for a problem to be fixed, it may seem that it ought to be easy to dig to the bottom of these application issues, but we all know that it isn’t. But if you use the iterative process of reproduce, find, and fix, you will find it much easier to solve the problem and satisfy the user.

Mike got his first computer at the age of 11 and hasn’t looked back since. After many years in the trenches of technical support and QA testing, he has found himself working as a software developer for a Fortune 500 company in Omaha, NE. When not at his day job, Mike does freelance work specializing in open source solutions for small business. He can be contacted by email at mike@squarepegsystems.com. Send the author your feedback or discuss the article in the magazine forum.

Medicine Making Music

Further Explorations of Sound as a Diagnostic Tool
by Brian Tarbox
In “And Your Bugs Can Sing” in September’s PragPub, Brian wrote about turning your log files into music. But what if the bugs you’re looking for are the kind that make you sick?

Recently on NPR I heard a report about doctors using music to monitor a patient’s condition. The idea is that there are many medical instruments in an ER, each reporting on a patient’s real-time condition. So many instruments, in fact, that it can be hard to notice changes in the values. It’s as though a bunch of musicians are jamming, but each is playing her own tune.

To make it easier to follow what’s going on, these doctors are playing an orchestral piece of music and associating each medical instrument in the ER with a different musical instrument in the piece. When the medical instrument’s output is in a safe or normal range, the musical instrument plays normally. If the medical instrument’s output is not in the safe range, the musical instrument’s track is tweaked so that it sounds wrong (by raising or lowering the pitch, for example).

Hey, That’s a Lot Like Log4jfugue!

This caught my attention because it’s very similar to my Log4jfugue project, which converts computer program log files into a music stream. Both projects use music as a way to deal with an overwhelming volume of data. I like how the doctors in this project are harnessing the human ability to process music. An orchestra creates a huge volume of acoustic data in performing an orchestral piece, yet it all comes together in such a way that the human brain can process it in real time and can isolate subtle variations.

Although this project is similar to Log4jfugue, there are a number of interesting differences between our approaches.

The medical music system seems to be optimized to detect deltas from a norm, whereas Log4jfugue is optimized to detect deltas in rates. This leads us in different directions. In the medical scheme, any change from the norm needs to be converted into a bending of the music stream of a particular instrument. So if the heartbeat gets too high, the violin track might be bent, while if the O2 saturation gets too low, the flute track might be bent.

This approach seems as though it would work best for detecting a single instrument going out of range. If many medical instruments reported bad values at the same time, the result would seem to be a literal cacophony.

Log4JFugue, on the other hand, is optimized for detecting rate differences without judging any value as normal or abnormal. So if the computer program’s output shows an increase or decrease in the rate of some log message that is being measured, Log4JFugue will increase or decrease the tempo of the associated percussion instrument. So if the system being measured speeds up, Log4JFugue will increase the tempo of all of the percussion instruments, which will still sound OK but will be noticeably faster.

The medical system solves a problem that Log4JFugue never solved, which is how to use non-percussion instruments. Both systems get a single rate variable for each item being measured. That works fine for achromatic instruments, but most instruments require both a pitch and a rate. The medical system takes the fascinating approach of starting with an orchestra score which provides constantly changing pitch and rate for each instrument. It then overlays that with the single rate value from the medical instrument. Each out-of-norm value perturbs the delicate balance of the orchestra, which is something easily noticeable to people.

The NPR article did not discuss the mechanism for altering the music stream but it implied that it could be done in real time to any music stream.

The Unharnessed Power of Sonification

Bubbling up a level, it is intriguing to see continuing interest in Sonification as opposed to Visualization.

Humans are primarily visual creatures: in fact one’s “attention” is generally equated with the location where your gaze is oriented. The flip side of this is that vision is optimized for focusing on a single target at a time. Hearing, on the other hand, is a much less directional sense and is optimized for more overall processing. There are lots of signals in our world that require our complete and focused attention, and these signals generally require visual input. Lot of other signals, though, can be attended to in a less focused manner and are good candidates for acoustic signals.

This leads to question of how we can improve our computer interfaces by making more intelligent use of non-visual signals. I see many articles these days discussing how to use the vast new expanse of the iPad’s screen. I don’t, however, hear people talking about ways to use sound to enhance the hopefully wonderful iPad experience.

Yes, I know what you’re thinking. But before you remind me that silence is golden, let me wholeheartedly agree. Extra sound for the sake of sound would be just as bad as the flashing screen icons that defaced many early web pages.

On the other hand, there are relatively non-intrusive ways to add acoustic feedback to signals. For a truly geeky example, it used to be fun to watch Star Trek TNG using a sound system with a great subwoofer—the low rumbling sound of the engines made an impressive background roar. Most of us run a CPU monitoring tool on our development boxes; imagine that its output was a modulated low bass rumble rather than a widget on the tray.

I think this medical musical data reduction project is an interesting example of sonification, and I’m keeping my ears open for other examples.

Brian Tarbox is a Principal Staff Engineer at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com. Send the author your feedback or discuss the article in the magazine forum.

Tangled Up in Tools

What’s Wrong with Libraries, and What to Do about It
by Mike Taylor
Surely “Just learn these 57 classes” is not the re-use we were promised?

Whatever Happened?

A few weeks ago on my blog, The Reinvigorated Programmer, I wrote an entry entitled “Whatever happened to programming?” that resonated deeply with a lot of people, judging by the many comments. Rather than respond individually to the initial batch of comments, I wrote a followup article, which in turn generated a lot more comments—on Hacker News, Reddit and Slashdot, as well as on the blog itself. Those comments have thrown up many more issues, and it’s taking time for me to digest them all. I think I am groping towards some kind of conclusion, though. In this article, I’ll briefly review the substance of those two entries, and speculate on possible ways forward.

The original article was born out of frustration at the way modern programming work seems to be going—the trend away from actually making things and towards just duct-taping together things that other people have already made. I’ve been feeling this in a vague way for some time, but the feeling was crystalized by Don Knuth’s observations in a long interview for Peter Siebel’s book Coders at Work. Knuth said:

The way a lot of programming goes today isn’t any fun because it’s just plugging in magic incantations—combine somebody else’s software and start it up. It doesn’t have much creativity. I’m worried that it’s becoming too boring because you don’t have a chance to do anything much new. Your kick comes out of seeing fun results coming out of the machine, but not the kind of kick that I always got by creating something new. The kick now is after you’ve done your boring work then all of a sudden you get a great image. But the work didn’t used to be boring. (page 594)

It’s evident that a lot of people feel the same way. It’s not that we want to have to write out own sort and search routines every time we need to do that stuff—everyone recognizes that that would be a waste of time better spent on solving higher-level problems. But when I’m working on a modern web application, I want to bring the same kind of creativity to bear that I used to need back in the day when we wrote out own quicksorts, schedulers, little-language parsers, and so on. I don’t want my job to be just plugging together components that other people have already written (especially when the plugging process is as lumpen and error-prone as it often is). I want to make something.

Scientists vs. Engineers

Responses to the “Whatever happened?” articles seemed to be split roughly 50–50 between scientists and engineers. Scientists said, “Yes, yes, I know exactly what you mean!”; engineers said “This is the re-use we’ve all been trying to achieve for the last forty years.” Part of me knows that the engineers are right, or at least partly right; but part of me feels that surely this can’t be the shiny digital future we were all looking forward to. Does re-use really have to be so, well, icky? Surely “Just learn these 57 classes” is not the re-use we were promised?

But the truth is that, like most of us, I wear both scientist and engineer hats at different times. What I want with one hat on might not be what I want with the other hat on. The are plenty of things that both hats agree on—the desirability of simplicity, clarity and generality, for example, the three Magic Words on the cover of Kernighan and Pike’s book The Practice of Programming. But the hats have different ideas on how to get there. The science hat cares deeply about understanding. No, it’s more than that: it cares about deeply understanding. The engineering hat cares about getting stuff done. What I am still trying to figure out is this: is it quicker just to Get Stuff Done without bothering to understand, or is time invested in understanding worthwhile even when measured in a purely utilitarian way? I honestly don’t know.

That Was Then, This Is Now

It didn’t used to be this way. I’ve been programming computers since 1980: Commodore BASIC, then C, then Perl, and most recently Ruby. Along the way I’ve used a lot of other languages, but those have been the four that, at some time or another, have been my favorite—my language of choice. For a few years back in the mists of time, all my thoughts had line numbers. In the 1990s, any time I wanted to write a program, my fingers would automatically type int main(int argc, char *argv[]) as soon as my hindbrain detected a fresh emacs buffer. I spent a decade of my life believing that the distinction between scalar and list context made sense, and that wantarray() was the kind of thing that a rational language might include. I’m better now, but it sometimes seems odd to me that physical objects in meatspace don’t know how to respond to an each message with a closure attached.

In the last 30 years, I’ve seen a lot of changes in how programming is done, but perhaps the key one is the rise of engineering. On a Commodore 64 you had to be scientist to get anything done. You had to know the machine deeply, you had to grok its inmost core, to become one with its operational parameters, to resonate with the subtle frequencies of its most profound depths—or, at least, know what location to POKE to turn the border purple.

Much the same was true when programming in C on Unix: you still needed to know the machine, even if now it was a slightly more abstract machine. But there was an important change—in retrospect, even more important than the change from unstructured spaghetti code to block-structured, or from interpreted to compiled: there was a library. Yes, a library—just one. (Well, roughly one; I am simplifying a bit, because there was also curses, termcap and a few other little ones.) The library provided simple ways to do complex things like sorting and formatted output, as well as system-level operations like setting up pipes and forking processes. It need hardly be said that everyone agreed the library was A Good Thing—a huge time-saver. So we all learned the library: good C programmers knew the whole thing, including stuff like the difference in the order of arguments between write() and fwrite(), the signature of a sort() comparison-function, and when to use strcpy() vs. memcpy(). It gave as a whole new palette to paint with.

And then, wow, Perl. Perl doesn’t offer a library. Perl has what is probably the biggest catalogue of libraries of any language in the world: CPAN (the Comprehensive Perl Archive Network. At the time of writing, CPAN offers 19941 distributions for download, of which 500 pertain to XML alone. It’s overwhelming. In the last dozen years, at least three biographies have been written with the title The Last Man Who Knew Everything (about Athanasius Kircher, Thomas Young, and Joseph Leidy). It’s exhilarating to think of a time when it was possible for a single individual to master all the accumulated knowledge of mankind; now it’s not possible to master all the open-source libraries for Perl. There’s just so darned much of everything.

Library Blindness

So what is a boy to do? Choose libraries carefully, learn only a few, and hope that you picked the right ones. For historical reasons, I do my XML handling in Perl using the clumsily named XML::LibXML library, and I have no real idea whether it’s the best one for the job. It’s the easiest one for me to use, because all I have to do is find some code where I used it before, cut and paste the instantiation/invocation, and tweak to fit the current case. But while my engineer hat is happy enough with that, my scientist hat is deeply unhappy that I don’t understand what I am doing. Not really.

Of course the XML-in-Perl problem would not be that hard to solve—I’d just need to take some time to surf around a bit, see which XML libraries other people are using and what they say about them, figure out how “alive” the code is (are there recent releases, and how frequent are they?), download and install them, try them out, and see which I like best. If XML were the only area where Library Blindness were an issue, I would probably just shut up whining and do it. But the same applies in a hundred other areas, and I am too busy chopping down trees to stop and sharpen my axe.

Am I saying that there shouldn’t be any libraries for Perl? Heck, no—I don’t want to do my own XML parsing! What then? That there should be One True Library, like there was for C in the 1980s, and someone trustworthy should decide what’s in and what’s out? No, that could never work. I am, in truth, not sure what I am saying: I don’t know the solution. I can’t even propose one, beyond the obvious observation that better reputation management mechanisms would make it less daunting to choose one library from among many that compete in the same space. We need libraries, and lots of them, for the simple reason that we are expected to do much more now than we were back when we had Commodore 64s (or, heaven help us, VIC-20s). The small, self-contained programs that we wrote then didn’t need libraries because they didn’t make REST calls to web services, or map objects onto relational databases, or transform XML documents. (Perhaps we could have used graphics libraries; but since the hardware didn’t really support arbitrary plotting, most graphics was done with user-defined characters and, if you were lucky, sprites.)

So libraries are necessary. Are they a necessary evil? Only if you think that the evilness is a necessity. I don’t think it is; but experimental evidence is against me.

The Library Lie

A commenter called Silversmith in the Reddit discussion of my original article had an idealized view of libraries: “You have problem X, consisting of sub-problems X1, X2, X3. There are readily available solutions for X1 and X3. If you don’t feel like being a bricklayer, code X. I choose to code X2, plug in solutions X1 and X3, and spend the rest of the day investigating and possibly solving problem Y.” That is what I call the library lie, and I think that Silversmith has swallowed it. The unspoken assumption is that “plug in solutions X1 and X3” is trivial—that it takes little effort and close to no time, and that the result is a nice, clean, integrated X. But we know from experience that this isn’t true. The XML that X1 produces is supposedly in the same format as X3 requires, but it’s mysteriously rejected when you feed it to X3 (and there is of course no useful error message—just “XML error”). You provide two hook functions for X3 to call back, but one never gets called and the other seems to be called twice... sometimes, under conditions that aren’t clear. And so it goes, and so you find yourself writing not just X2 but also wrapper layers X1’ and X3’ that are supposed to make X1 and X3 look like you want them to. And even when you’re done you’re not really clear in your mind why the aggregate works for the cases you’ve tested; and you have no confidence that something won’t go mysteriously wrong when you start using it in other cases.

I’m not saying that building X1’ and X3’ and dealing with all the pain isn’t still quicker overall than writing your own X1 and X3. But I am saying that we need at least to be honest with ourselves about how long “just plug in solutions X1 and X3” is going to take; and we need to recognize that the end result might not be as tractable or reliable as if we’d built the whole solution.

Libraries are a win. But they are not as big a win as they want you to think, and sometimes they are the kind of win that make you wish you’d lost.

I’ll See Your Library Blindness and Raise You Framework Fever

If there is one thing more frightening that mapping your way through a maze of twisty little libraries, all different, it’s getting mired in the framework swamp. “Framework” is a word that’s leaped to prominence in the last few years—you rarely heard it before the turn of the millennium, outside Java circles at least, but now they’re the hot game to be playing. Sometimes the word seems to be merely a fashionable synonym for library, but the framework proper is a bigger and hairier beast.

A framework can be defined as a set of libraries that say “Don’t call us, we’ll call you.” When you invoke a traditional library, you are still in control: you make the library calls that you want to make, and deal with the consequences. A framework inverts the flow of control: you hand over to it, and wait for it to invoke the various callback functions that you provide. You put your program’s life in its hands. That has consequences: one of the most important ones is that, while your program can use as many libraries as it likes, it can only use—or, rather, be used by—one framework. Frameworks are jealous. They don’t share.

Is it worth ceding control to a framework? Well, sometimes. My experience has been that so long as you do things the framework’s way, and don’t need to go beyond what the author imagined, you’ll do fine—things will work quickly and simply and the sun will shine and birds will sing until suddenly—uh-oh!—you need to do something just a tiny bit differently and wham! everything falls apart. Subtle dependencies that were hidden from you when it was all going right suddenly leap out of the bushes and yell at you. The monsters that were chained in the basement all get loose at once, and suddenly you add this line to your callback and it makes that seemingly unrelated thing go wrong. And so you patch for that and something completely separate goes wrong at the other end of your application, and the log-file doesn’t tell you anything useful. So you try to look up the problem area in the documentation, but when you find the entry for the function newRecordAddedHook, it just says “This hook is called when a new record is added.”

There’s a scary example of framework failure right in the Rails book, Agile Web Development with Rails (Third Edition). The tutorial has been going swimmingly for 187 pages, teaching you how to do things like add has_many :line_items to the Product model class: minimal code, all self-explanatory. Then suddenly, out of nowhere, the Internationalization chapter tells you to simply add a form to the store layout:

<% form_tag '', method => 'GET', :class => 'locale' do &>

<%= select_tag 'locale', options_for_select(LANGUAGES, I18n_locale),

:onchange => 'this.form.submit()' %>

<%= submit_tag 'submit' %>

<%= javascript_tag “$$('.locale input').each(Element.hide)” %>

I mean to say, what?

The form tag, select tag and submit tag make sense in light of what has gone before, but that hunk of JavaScript appears in the text fully formed, direct from the mind of Zeus. It’s great that it appears right there in the tutorial, but there is no way I would ever have arrived at that for myself.

When I run into this kind of thing, I feel like I am playing 1980s Adventure games all over again. You remember: OPEN DOOR / The door is locked / UNLOCK DOOR / Unlock the door with what? / UNLOCK DOOR WITH KEY / Do you mean the iron key or the brass key? / UNLOCK DOOR WITH BRASS KEY / The brass key does not fit. It’s guesswork. Worse than that, it’s guessing uninteresting details like vocabulary rather than guessing about the actual problem. When I played Lurking Horror, I had terrible trouble with a puzzle near the very end, when it was obvious that something was in a pool of water and I had to get it out. I couldn’t ENTER POOL or SWIM IN POOL, and attempts to PUT HAND IN POOL or FEEL POOL or FEEL IN POOL were all fruitless. In the end I hit on the answer, REACH INTO POOL. This sort of guess-what-the-author-had-in-mind game is dispiriting enough when you’re trying to defeat a gothic horror from outside of time and save the world from the evil dominion of cultic beasts; but it’s just plain dumb when all you’re trying to do is display a dropdown.

You Are Now the Underclass

My blood ran cold yesterday when I read these comments in an interview with the Gang Of Four on the subject of Design Patterns 15 Years Later:

Richard Helm: I think there has been an evolution in level of sophistication. Reusable software has migrated to the underlying system/language as toolkits or frameworks—and mostly should be left to the experts.
Ralph Johnson: Most programmers are not hired to write reusable software [...] Perhaps it would be better now to aim the book at people using patterns chosen by others rather than aim it at people trying to figure out which pattern to use.

There it is, folks, in black and white: according to the experts, all us working Joes should just be using frameworks... which will be written by: the experts.

You know what? I don’t trust them to get it right. I mean, why would they start now?

The Problem Is Not Libraries. The Problem Is Bad Libraries

I’ve painted a black picture. I recognize the need these days to write programs that do much more than they did back in the 1980s; I’ve admitted that we can’t do that without libraries; I may not have come right out and said that frameworks are necessary, too, but deep in the black recesses of my heart I know it’s true (otherwise why would I be bothering to read the Rails book?) It’s funny to remember my lecturers, back when I was doing my maths-and-CS degree in the late 1980s, talking about the “software crisis” – they really had no idea how bad it was going to get. Dijkstra’s words from The Humble Programmer seem prescient: “as long as there were no machines, programming was no problem at all [...] now we have gigantic computers, programming has become an equally gigantic problem.” It’s hard to believe that was written in 1972.

So I seem to be whining quite a lot. Do I have any constructive suggestions?

Why, yes! Yes, I do. I have a two-prong manifesto.

Prong 1: Simpler, Clearer, Shorter Documentation

The simplest thing that we can do right now is to rethink how we document libraries. Automatic documentation tools like Javadoc and Rdoc are good for producing thick stacks of paper, but not so hot at actually telling library users the things they need to know. They are the source of most of the world’s “newRecordAddedHook is called when a new record is added” documentation. They can be useful, but they are no substitute for actually writing about the library: single-page summaries that answer the three key questions: what the library does, why you should use it, and how to do so. For bonus points, the one-page summary should avoid using the word “enterprise” (unless it’s a library of Star Trek ships) and “innovative.”

Here’s an example of the kind of thing we need to get away from: I quote verbatim from the first paragraph of content on the front page of the primary web site about JavaServer Faces:

Developed through the Java Community Process under JSR - 314, JavaServer Faces technology establishes the standard for building server-side user interfaces. With the contributions of the expert group, the JavaServer Faces APIs are being designed so that they can be leveraged by tools that will make web application development even easier. Several respected tools vendors were members of the JSR-314 expert group, which developed the JavaServer Faces 1.0 specification. These vendors are committed to supporting the JavaServer Faces technology in their tools, thus promoting the adoption of the JavaServer Faces technology standard.

This is a model of obfuscation; a thing of beauty, in its own way. In nearly a hundred words, it says almost nothing. It contrives to use the name “JavaServer Faces” no fewer than five times, without once giving more than the vaguest hint of what it actually is—something to do with user interfaces, apparently, though whether on the Web or the desktop or elsewhere I couldn’t say. It does tell you a whole bunch of stuff that you might just become interested in after a year or two of actually working with a technology, but which no rational being approaching it for the first time could possibly care about. That several respected tools vendors were members of the JSR-314 expert group was not top of my Things To Find Out About JSF list.

(Let me say that my point here is not to pick on JSF particularly. It is merely one of hundreds of equally dense examples I could have picked—and that, really, is precisely my point.)

I suggest that any library whose key features can’t be summarized in one page of A4 (or US Letter, if you insist) is too complex and needs to be redesigned. By “too complex” here, I don’t mean merely that it does too much, but that the stuff it does do is not focused enough. In fact you ought to be able to briefly summarize what a library does in a single sentence. And if the sentence begins “It’s a framework for constructing abstractions that can be used to derive models that ...”, then you lose.

Prong 2: Minimize the Radius of Comprehension

“Radius of comprehension” is a new term that I am introducing here, because it describes an important concept that I don’t think there is a name for. It is a property of a codebase defined as follows: if you are looking at a given fragment of code, how far away from that bit of the code do you need to have in your mind at that time in order to understand the fragment at hand? It is a sort of a measurement of how good encapsulation is across the whole codebase, although when I say “encapsulation” here, I am using that term in a broad sense that means more than just technical issues such as what proportion of data members are marked private. I’m talking about a human issue here (and therefore, sadly, an all but impossible one to measure, though we know it when we see it).

So for example: when I am reading a codebase that I’m not already familiar with, if I come across an object whose class is called Employee or HashTable or CharacterEncoding, I can be reasonably sure that I understand what that class is meant to be doing, and I can take a good guess at the meanings of methods invoked on it—the radius of comprehension is pleasantly low. If I come across objects of class EmployeeFactory, I can probably take a good guess and likely be about right. If I find a CharacterEncodingMediatorFrobnicationDecorator, there is no way I am going to have a clear idea what that’s about unless I go and read the code for myself, so the radius of comprehension grows. Class naming is only one of many factors that contribute to the radius of comprehension: others include immutability of objects, functions that are guaranteed free of side-effects and—the hardest to quantify—the conceptual unity of the various modules.

The significance of the radius is obvious: when it is low, we need load only a little of the code into our minds at once in order to understand the part we’re trying to read, debug or enhance. When the radius is high, valuable mindspace has to be given over to matters that are not directly relevant to the problem we’re trying to solve; and the more things we have to think about at once, the less attention we can give to the core issue.

The radius of comprehension is all about how much you have to hold in your head before you can start being productive. Joel Spolsky has written about the problem of interruptions—how they knock programmers out of “the zone” so that we have to reload all our mental state again before we can get back to useful work (see point 8, “Do programmers have quiet working conditions?”) This being so, we need to build our software in such a way that programmers have a minimum amount to reload after each interruption. And this is particularly important for designers of libraries and (where possible) frameworks.

How can we reduce the radius? In general terms, it’s just Occam’s razor: do not multiply entities without necessity. Each library should provide the smallest possible number of API classes, and each should support the minimum number of methods. This much is obvious. But can we go beyond these generalities to propose some tentative guidelines for reducing the radius? We might try the following, with appropriate humility, in the hope that criticism of them will lead to better rules:

- Each kind of thing should have only one representation. This seems so obvious as scarcely to need stating, but Java’s misguided distinction between Array and ArrayList makes it a point worth stating.

- So far as possible, objects should represent actual things. Sometimes design patterns introduce classes to represent abstractions like iterations, strategies and decorators: that may be a necessary evil, but it’s an evil nevertheless. Every such class increases the radius.

- Immutable objects are easier to think about than mutable. If an object is guaranteed immutable, then the likelihood that I will need to read its source-code to understand it is greatly reduced.

- Similarly, functions without side-effects are easier to think about than those that change the state of one or more objects.

When languages have syntax that allows us to mark objects as immutable or functions as free of side-effects, we should use them: such notation is documentation that the compiler can check for us. The absence of such facilities from extremely dynamic languages such as Ruby is a weakness.

Finally, as Bjarne Stroustrup noted in The C++ Programming Language (2nd edition), “Design and programming are human activities; forget that and all is lost... There are no ‘cookbook’ methods that can replace intelligence, experience and good taste.” I think that the radius of comprehension is a useful concept, but that it will serve us best if we just have it mind when designing APIs, rather than blindly following rules that are intended to reduce it.

Earlier in my career, I spent ten years working on a proprietary text-and-objects database, written entirely in C, that had to build its object orientation out of spare parts. By all standard expectations, it should have been nightmarish. But in fact the code had a very low radius of comprehension, simply because it was designed with care, attention and taste by a very talented and diligent architect. To work on that very large system, I had to have only a very small part of it in my mind at a time. I can only hope that in ten years’ time, people who’ve worked with me are able to say the same about my code.

Mike Taylor started programming on a PET 2001 in 1980, and sold his first commercial programs, for the VIC-20 two years later, at the age of 14. At Warwick University in 1988, he wrote MUNDI, the first MUD to run over the Internet. He works for Index Data, the world’s smallest multinational, for whom his free software releases include query parsers, an OpenURL resolver, and toolkits for interrogating remote IR servers. In his spare time, he is a dinosaur paleontologist: he described and named the sauropod Xenoposeidon in 2007 and revised Brachiosaurus in 2009. His new programming blog, The Reinvigorated Programmer, joins the perennial favorite Sauropod Vertebra Picture of the Week, or SV-POW! for short. Mike’s written a lot of Perl software, but has recently got better and now writes mostly Ruby. One day, he really, really will learn Lisp. Send the author your feedback or discuss the article in the magazine forum. Mike loves sushi. All sushi images licensed with Creative Commons By-2.0 and downloaded and modified from: Rectangular plate with diagonal nigiri from above (TedsBlog), Salmon nigiri (adactio), Round plate (mdid), Single inside-out roll segment lying down (besighyawn), Square plate in oblique view (Geoff Peters 604), and Four salmon inside-out rolls (Jorge-11).

The Quiz

The Mystery of the Five Programmers
by Michael Swaine
You probably didn’t know that a certain famous programmer had a metal plate in his head of his own design.

There is some such odd factoid about every person just waiting to be discovered if you dig deep enough. Or sometimes if you just look them up on Wikipedia. This logic puzzle involves five famous programmers, identified here just by their first names, plus the college each graduated from, his year of graduation, and an odd factoid about each programmer. Your task is to associate each programmer with the correct college, graduation year, and factoid, based on the sketchy data provided.

A hint: expert solvers of logic puzzles find that it’s helpful to create a grid to record the connections as you make or eliminate them. But with this puzzle you have an additional way of making headway. The five individuals are real programmers and the information about them is all true. So if, for example, one of the programmers here was named Linus, you might guess that he’s the one who graduated from a university in Finland. So naturally none of them is named Linus, because that would be too easy. They all have fairly common names. But you get the idea.

Oh, and since the programmers are all real people, there’s one extra challenge. Once you’ve connected each programmer with his school, graduation date, and factoid, you should also figure out his last name. By that point, that should be easy.

So here’s all you need to know about the five programmers:

The five people are the Yale graduate, the UC Berkeley grad, the 1978 grad, the one who has no email address, and John. Now, John graduated before the person with no email address, and the UC Berkeley grad was never a radio disk jockey, although one of the five was. So that ought to be a big help. Also, the Porsche driver graduated after Mitch, who graduated after the person with a metal plate in his head, and Charles, who didn’t graduate in 1971, either has no email address or was a space tourist. Got that? And of the one with no email address and Tim, one graduated in 1960 and the other graduated from the University of Washington. Somebody, I forget who, graduated in 1972, and somebody, possibly a different person but not necessarily, went to Case Institute of Technology. Let’s see, what else can I tell you? Don graduated in 1960, and the group includes a 1949 Columbia graduate.

There, that should be enough information for you to match each programmer with his alma mater, year of graduation, and little-known factoid. Good luck!

OK, one more little puzzle: the title of this month’s quiz is stolen from a different puzzle published in a computer magazine some years ago. What was the magazine and who was the author?

Solutions to Last Month’s Quiz

How many times per day will a digital clock in 12-hour mode display three identical consecutive digits?

34.

How many times per day do all three hands of an analog clock coincide?

Twice.

You wake up. The first light of dawn is coming in the window. You glance at the clock. 5:45. You close your eyes and count off what you think is 15 seconds. You’re pretty good at this; in 15 seconds you’re not going to be off by an appreciable amount. You open your eyes and glance at the clock again. Still 5:45.

What is your best guess for the current time, to a tenth of a second?

5:45:37.5.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

- April 7, online
“Don't Play Schedule Games: Recognizing and Ending the Schedule Games We Play”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- April 8, Agile Central Europe conference, Krakow, Poland
“Retrospectives”Rachel Davies, the author of Agile Coaching

- Apr 8, New England Java Users Group
“An Experiential Introduction to Agile”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- Apr 8-9, Philly Emerging Technology
I think I finally understand mocksBrian Marick, the author of Programming Cocoa with Ruby: Create Compelling Mac Apps Using RubyCocoa and Everyday Scripting with Ruby: for Teams, Testers, and You

- Apr 8-9, Philadelphia Emergent Conference
Building DSLs with GroovyVenkat Subramaniam, the author of Practices of an Agile Developer, Programming Groovy, and Programming Scala

- Apr 10, Twin Cities Code Camp, Minneapolis, MN
“HTML5 and CSS3 Today”Brian Hogan, the author of Web Design for Developers

- April 11-14, 360iDev, San Jose, CA
TBDMarcus Zarra, the author of Core Data

- Apr 11-14, 360iDev, San Jose, CA
“Core Audio: Don't Be Afraid To Play It LOUD!”Chris Adamson, the author of iPhone SDK Development

- Apr 12-15, MySQL Conference & Expo, Santa Clara
“SQL Injection Myths and Fallacies”Bill Karwin, the author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

- Apr 14-16, Reston, VA
“Pragmatic Studio: Cocoa Programming for Snow Leopard”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- April 14-17, First Lego League World Robotics Championship, Atlanta, GA
Technical Judge—Robot DesignKrishna Sankar, the author of Building Clouds with Amazon Web Services

- Apr 15-17, Palmetto Open Source Conference, Columbia, SC
TBDAndy Lester, the author of Land the Tech Job You Love

- April 16, ACCU conference, Oxford, UK
Workshop: “Understanding User Stories”Rachel Davies, the author of Agile Coaching

- April 16, GR8 , Minneapolis, Minnesota
“Grails Quick-Start”Dave Klein, the author of Grails: A Quick-Start Guide

- Apr 16, Minneapolis
On topics around Groovy, and giving a kickoff talk at GR8 ConferenceVenkat Subramaniam, the author of Practices of an Agile Developer, Programming Groovy, and Programming Scala

- Apr 16-17, Citicon: Continuous Integration and Testing Conference, RTP, NC
TBDJared Richardson, the author of Ship It!: A Practical Guide to Successful Software Projects

- Apr 20-23, Bangalore
On topics around Java and Scala, and giving a keynote at Great Indian Developer SummitVenkat Subramaniam, the author of Practices of an Agile Developer, Programming Groovy, and Programming Scala

- Apr 22, Manchester Geek Night, Thoughtworks UK
“Naked Objects”Dan Haywood, the author of Domain-Driven Design Using Naked Objects

- April 24-25, Voices That Matter: iPhone Developers Conference, Seattle, WA
“Core Location and Map Kit: Bringing Your Own Maps” and “In-App Purchase: Best/Worst Thing Ever”Chris Adamson, the author of iPhone SDK Development

- Apr 26, London
“DevDay for iPhone”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- April 26-27, University of Washington
TBDMarcus Zarra, the author of Core Data

- Apr 27-30, Reston, VA
Mastering Ruby and Rails StudiosDave Thomas and Chad Fowler, the author of The Passionate Programmer: Creating a Remarkable Career in Software Development

- Apr 28, Geneva
“DevDay for iPhone”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- May 2-7, ???
teaching PSL with Esther Derby and Jerry WeinbergJohanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- May 10-11, Agila Sverige 2010, Stockholm, Sweden
“Timboxed Thinking”Staffan Nöteberg, the author of Pomodoro Technique Illustrated

- May 11-14, Chicago, IL
“Pragmatic Studio iPhone Programming”Daniel Steinberg, the author of Cocoa Programming: A Quick-Start Guide for Developers, and co-author of iPad Programming: A Quick-Start Guide for iPhone Developers

- May 11-14, Reston, VA
Mastering Ruby and Rails StudiosDave Thomas and Chad Fowler, the author of The Passionate Programmer: Creating a Remarkable Career in Software Development

- May 11-14, Obtiva's Ruby on Rails TDD Boot Camp, Chicago, IL
TeachingNoel Rappin, the author of Rails Test Prescriptions

- May 12-14, GeeCON 2010, Poznan, Poland
“Pomodoro Technique”Staffan Nöteberg, the author of Pomodoro Technique Illustrated

- May 12-14, Reston, VA
Clojure Programming StudioStuart Halloway, the author of Programming Clojure and Rails for Java Developers

- May 14-15, Open Agile conference, Bucharest, Romania
TBDRachel Davies, the author of Agile Coaching

- May 16~19, Software Practice Advancement 2010, London
“Customizable UIs with Naked Objects”Dan Haywood, the author of Domain-Driven Design Using Naked Objects

- May 17-20, Agile Oresund, Malmo, Sweden
“Agile Management: The Essence of Leadership”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- May 18, Software Practice Advancement 2010, London
“Retrospectives Refactored”Rachel Davies, the author of Agile Coaching

- May 18-21, TEK-X PHP Conference, Chicago
“SQL Injection Myths and Fallacies” and “Models for Hierarchical Data with SQL and PHP”Bill Karwin, the author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

- May 23, Gateway Software Symposium, St. Louis, Missouri
“Grails Deep Dive” and “Grails Takes Care of the REST”Dave Klein, the author of Grails: A Quick-Start Guide

- June 1-2, DevSum 2010, Stockholm, Sweden
“Pomodoro Technique”Staffan Nöteberg, the author of Pomodoro Technique Illustrated

- June 1-4, XP2010, Trondheim, Norway
Workshop: “Trust and Culture”Rachel Davies, the author of Agile Coaching

- June 6-11, Better Software Conference/Agile Development Practices, Las Vegas, NV
“It’s the People, It’s Always the People”Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- June 8, Embedded Systems Conference, Chicago, IL
“Testing Embedded User Interfaces”Ian Dees, the author of Scripted GUI Testing With Ruby

- June 8, Sacramento Java User Group
“Grails Integration Strategies”Dave Klein, the author of Grails: A Quick-Start Guide

- June 14-17, UberConf , Denver, CO
Continuous Testing, TDD, and Iterationless DevelopmentBen Rady

USENIX Events

- Apr 27, San Jose, CA
LEET ’10: 3rd USENIX Workshop on Large-Scale Exploits and Emergent Threats

- Apr 27, San Jose, CA
INM/WREN ’10: 2010 Internet Network Management Workshop/ Workshop on Research on Enterprise Networking

- Apr 27, San Jose, CA
IPTPS ’10: 9th International Workshop on Peer-to-Peer Systems

- Apr 28-30, San Jose, CA
NSDI ’10: 7th USENIX Symposium on Networked Systems Design and Implementation

O’Reilly Events

- Apr 12-15, Santa Clara, CA
MySQL Conference & Expo: “The largest gathering of MySQL developers, users, and DBAs worldwide.”

- May 25-27, Washington Convention Center, Washington, DC
Gov 2.0 Expo: “Gov 2.0 Expo will showcase the real-world application of Web 2.0 technologies in government and municipal sectors, featuring a practical program that will teach government employees and contractors how to apply technology best practices to foster greater transparency, effi ciency, and collaboration.”

Other Happenings

- Apr 14
Matz is 45.

- Apr 30
The World Wide Web is 17.

- May 6-7, Oklahoma City, OK
Red Dirt Ruby Conference

- May 17
Alan Kay is 70.

- May 19
James Gosling is 55.

- May 26
Ward Cunningham is 61.

- June 8
Tim Berners-Lee is 55.

- June 23
Vint Cerf is 67.

- June 30
Lynne Jolitz is 49.

Shady Illuminations

The CEO of No
by John Shade
In which John contemplates the asymptote of the austere aesthetics of Steve Jobs.

Subjugation to tyranny is never obligatory, although it can be extremely convenient. Even comforting.

Apple counts on this.

Apple sells convenience and comfort. That this is sometimes the comfort of a walled garden is something that Apple’s customers generally accept with equanimity. So I guess it works for them. OK, I admit it: for us.

But now and then Apple comes down on the side of the rebel. Apple’s iPhone OS has not really overthrown what Ted Nelson called the Tyranny of the File, but it has made it easier to flout it.

Ted might be pleased, though I somehow doubt it. Similarly, Jef Raskin, who invented the Macintosh only to see Steve Jobs turn it into something drastically different, who left Apple to design a machine that more or less did everything you needed it to do using only one file, would have seen the irony.

Apple didn’t hide the iPhone OS file system for Ted’s reasons. Ted deplored the single vision of file systems that force you to think of all your stuff in this and only this way, and to view the universe through a false hierarchy.

Keep It Simple, ’Cause We’re Stupid

Apple was dealing with complexity.

Beyond a certain threshold of complexity, structure becomes indistinguishable from randomness. From there on, you either accept that some of the structure has moved outside the cone of accessibility, or you search. For the average user, that threshold lies between three and four files, according to serious research.

So Apple hid the hierarchical file system. Clarity through obfuscation. Sort of like the portlessness of the iPad: the device isn’t ignorant of USB, it just doesn’t want to talk about it.

This what Steve Jobs does. He finds things to say no to. Some CEOs are takeover masters; Jobs is a takeaway master. The CEO of No.

The tyranny of files is just one case of the reification of metaphors. We mistake concepts for things. The stench of reification permeates our field: you can’t go for a stroll without stepping in a patch of it. Object-oriented thinking took too well, leaving malodorous deposits in places it was never meant to range. We swim in a sea of abstractions, and we ought to learn how to deal with them directly, rather than trying to recreate physical bookshelves on an iPad. The machinery of our culture has traded moving parts for altered states, and we should embrace the abstraction.

Which brings me back to Apple’s CEO, who dropped acid, made a pilgrimage to India, and once lived in a mansion with no furniture. Some say.

John’s Dream

I have a dream.

My dream is that Steve Jobs has not yet fully embraced his inner Buddhist. Deep down, I suspect that he wants to move beyond the colorful eye candy and give the customers a stark Zen garden experience, centered on the message of negative space. He wants us to realize the beauty of minimalism, the joy of No. He just hasn’t figured out yet how to convince us that we want it.

But when he decides to go for it, I have the perfect language for Apple’s developers to code it in.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He has still not forgiven LA electro-pop band Fol Chen for promising him a fortune but never delivering. Send the author your feedback or discuss the article in the magazine forum.