Adding Save PDF to iBooks Support to Your Application

As I wrote recently, the ability to create a PDF document from an application’s printed content is one of my favorite features that Apple added in iOS 9. This feature leverages the printing system so that if your application can print, a user will also be able to use the new “Save PDF to iBooks” feature. Well, almost.

The key is that your application needs to offer printing by using Apple’s “Share Sheet”, instead of using the older method of using a UIPrintInteractionController. And unfortunately, as of my writing this, all of Apple’s sample code demonstrating how to implement printing in an iOS application uses the UIPrintInteractionController method of presenting printing to the user.

I ran into this recently when I emailed the developers of one of my favorite iOS applications and suggested they add support for the “Save PDF to iBooks” to their app. After all, the app already supported the Share Sheet for a number of tasks other than printing but it supported printing using the old UIPrintInteractionController. The developer was kind enough to reply to my suggestion with interest, but the response I got was: “I’d like to but I don’t know how to do that.”

Poking around Apple’s developer site, I found the handy page AirPrint for Developers. It includes a link to the 2014 WWDC session on AirPrint (there was none in 2015) which is a great presentation with tons of info for app developers getting started with printing on iOS. And the AirPrint for Developers page has four links to sample code that implement printing in various ways. Unfortunately none of these samples implement the Share Sheet method of printing.

So I grabbed one of Apple’s samples and updated it. I started with one that I myself wrote (long ago) at Apple. It demonstrates how to print content from a WebView in both a basic way and also by using some fancier techniques to add more control to the layout of content on the printed pages. Updating it to use the Share Sheet is pretty straightforward.

The only substantive change needed to make the sample app use the share sheet is to take out the use of the UIPrintInteractionController from the sample and replaced it with the use of a UIActivityViewController. This controller takes an array of “Activity Items” as part of its initialization. When the controller is presented it determines what activities (or actions) can be taken on those activity items and allows the user to choose from those actions.

The UIActivityViewController determines that printing is a supported activity if the activity items array contains both an object of the UIPrintInfo class and also a source of print data. The source of print data can be a printing item or items (e.g. a photo or photos), a UIPrintFormatter object, or a UIPrintPageRenderer subclass. For the original sample code, the source of print data was a UIPrintPageRenderer subclass that the code created and assigned to the myRenderer local variable. For fun in the new code I also added an NSURL corresponding to the URL of the web page the user is visiting. This allows the Share Sheet to show more actions for the sample app than just those associated with printing. Once the UIActivityViewController is created, all that is needed is to present it and UIKit does the rest. I mostly stole the code to present the activity view controller from this sample.

Here’s the updated code snippet that replaces the old usage of the UIActivityViewController in the original sample: 

NSURL *url = [NSURL URLWithString:[self.urlField text]];
NSArray *activityItemsArray = 
  [NSArray arrayWithObjects: myRenderer, printInfo, url, nil];
UIActivityViewController *activityViewController =
  [[UIActivityViewController alloc]
    initWithActivityItems:activityItemsArray
    applicationActivities:nil];


if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
  //iPad, present the view controller inside a popover
  if(!self.activityPopover){
    self.activityPopover =
      [[UIPopoverController alloc]
        initWithContentViewController:activityViewController];
  }
  if (![self.activityPopover isPopoverVisible]) {
    [self.activityPopover
      presentPopoverFromBarButtonItem:self.printButton
      permittedArrowDirections:UIPopoverArrowDirectionAny
      animated:YES];
  }else{
    //Dismiss if the button is tapped while pop over is visible
    [self.activityPopover dismissPopoverAnimated:YES];
  }
}else{
 //iPhone, present activity view controller as is
 [self presentViewController:activityViewController animated:NO completion:nil];
}

Running the modified app on an iPad and touching the action icon brings up the Share Sheet instead of the Printing UI directly (as it would have if I’d not modified the original sample). From there you can see that both the Print icon as well as the “Save PDF to iBooks” icon appears on the Share Sheet. And both behave as expected! 

If you’ve already got printing working in your app, now’s the time to update to using the Share Sheet method instead of the older method. Without a lot of extra work on your part, users get a great new option to save your application’s content in a print ready format. And if you’ve not added printing to your application to date, the “Save PDF to iBooks” feature provides yet another reason to do so.

Save PDF to iBooks

New in iOS 9 is the ability to save web pages as a PDF document to iBooks. It is a feature that is near and dear to my heart, in part because it is the last major feature I worked on at Apple before I left in early 2013.

What users of iOS 9 may notice is that Safari offers a new item in the Share Sheet: “Save PDF to iBooks”. They may think of this as a Safari specific feature.

 

But the Photos app also allows this, as will every iOS app that presents printing using the iOS “Share Sheet” (in iOS programming parlance, using an ActivityViewController). If an app can print via the Share Sheet then “Save PDF to iBooks” automatically appears as well.

During my career at Apple I worked primarily on the printing subsystems of Mac OS X and iOS. Much of that work was on the software plumbing needed for users to print on paper. But a portion of that work was enabling the ability to produce a PDF file corresponding to what otherwise would have been printed output. Save as PDF from the print dialog was part of OS X since version 10.0 shipped in 2001.

When creating the printing system for iOS, allowing for the ability to create a PDF reproduction of the results of printing was a goal of the design from the beginning. To me it seemed almost more important to allow users to capture content to store on their device to take with them (or email or whatever) than it was to produce pieces of paper. The design of the printing system allowed for it but the user facing feature was left out. So in the summer of 2012 I worked on an early implementation of what is now shipping. And I’m thrilled that it’s now out.

Executives at Apple talk about the desire to “surprise and delight our users”. Well I experienced that firsthand when I got a notification from Apple’s “Tips” app on my iPhone soon after updating to iOS 9. For me the (ironic) surprise was that the tips app was telling me about a feature that I worked on. And I was delighted to see that it was finally shipping. 

Macintosh Then and Now (Updated)

I originally wrote this in January but thought I’d update it for the introduction of the first Retina iMac, especially since the original Mac and the Retina iMac are priced identically. It’s amazing to see how far the Macintosh hardware has come over the 30 1/2 years of its existence. 

Original Macintosh January 24, 1984

Single-core 8 MHz Processor, 16 bit Motorola 68000
128 KB RAM
9 inch, 1 bit per pixel, black and white CRT display, 512×342 pixels, 72 dpi
One 400 KB single-sided floppy drive
2 RS-422 ports
OS: Mac OS 1.0
Number of swaps to copy 1 floppy disk: 4
$2499 in 1984 dollars.

Retina iMac October 16, 2014

Quad-core 3500 MHz Processor, 64 bit Intel Core i5
AMD Radeon R9 M290X graphics processor with 2GB of GDDR5 memory
8,000,000 KB RAM
27 inch, 24 bits per pixel, color Retina LCD display, 5120×2880 pixels, approx 218 dpi
One 1,000,000,000 KB Hard Drive
4 USB 3 ports, 2 Thunderbolt 2 ports, 1 Gigabit Ethernet port, SDXC card slot, Bluetooth, Facetime HD camera
802.11ac Wi-Fi wireless networking; IEEE 802.11a/b/g/n compatible
OS: Mac OS X 10.10 Yosemite
Number of swaps to copy 1 floppy disk: huh?
$2,499 in 2014 dollars.

Not to mention how visually different the computers are today.

 

The Turkey Drumstick

That’s not a turkey drumstick! That’s the cover of my book!

I never thought I’d be thanking Apple product marketing for something related to my book on programming Quartz graphics. Without their “help”, the book Programming with Quartz that I wrote with Bunny Laden would have been published without our names as authors. Instead it would have listed “Apple” as the author. But thanks to a cranky person in Apple product marketing, our names are there instead.

From the very beginning of the book project there was no question: our names would never be on the book. Apple had a firm policy, instituted by Steve Jobs when he returned as iCEO, that no individual names would be on Apple products, including any Apple publications. The author of our book would be “Apple” and our names would not appear in any form. There would be author bios on the back of the book but they would omit our names.

I should mention that our publisher, Morgan Kaufmann, had already done a number of books with Apple. They hated the fact that these books were published with “Apple” as the author and that the true author names were not known. To them it was extremely valuable to have real people’s names on their publications. But they wanted to do business with Apple and those were the terms.

Writing this book was my crazy idea, I started it with this understanding, and I had absolutely no problem with not having my name on it. I was writing this book for software developers use, not for personal glory. I was (and still am) passionate about the fact that 3rd party developers need good introductory and reference documentation and I was determined to do what I could to help provide that.

While our names weren’t going to be on the book, late in the project I had an idea how we could have an easter egg in the book so that we weren’t totally anonymous. After all, this was a book about graphics! In the chapter “Image Masking” there was a code sample and accompanying graphic that showed how to draw color through 1-bit image masks using Quartz. We needed images for the graphic so I thought we might take the opportunity to sneak us in.  

By October 2005 we had finished the process of writing the book, dealing with copy- and proof-reading edits, processing the graphics, struggling with image rights issues, and handling a great many other details related to the book. The book was ready. The only thing remaining was to get final approval of the book’s cover from product marketing. Proposals for that artwork had been created by the publisher and the final selection had been made with the help of talented artists in Apple publications. This final approval seemed like a formality.

But then came the email message:

From: xxx <xxx@apple.com>
Date: October 12, 2005, 6:56:52 AM PDT
To: David Gelphman <gelphman@apple.com>
Cc: “<various@apple.com>”
Subject: Re: Need Approval for Front Cover of Morgan Kaufmann Book…

I can’t really tell what image is being used on the cover (blured drum stick?), but I don’t think this cover is really up to our standards. Is there someone in GD who can take a look and help out here?

No, that was not a “blured drum stick”, it was a crystal, a Quartz crystal. None of us could see the “blured drumstick”, even after drinking heavily (not really), taking massive quantities of drugs (not really), and more squinting than we thought possible (really). After we got this email everyone involved jokingly referred to the graphic on the cover as the “turkey drumstick”.

This helpful fellow high up in product marketing caused everything to come to a screeching halt. Of course we had been working with someone in GD (Graphic Design) and they were on board with the proposed cover. But this one person in product marketing was saying that this book had Apple’s name on it which made it an Apple product and in their opinion the cover reflected poorly on Apple.

At this point the publisher pushed back like crazy. They had a schedule for the book to be published and everything was ready. But now there was a huge roadblock that was holding things up. This was their design, so obviously they were happy with it. This was all an Apple problem. Should the design of the cover be done from scratch? How long was it going to take before “Apple” was happy with a new design? They had had plenty of previous experience with the lengthy process of getting things done with Apple.

Ultimately the proposed solution was to remove “Apple” as the author of the book and have the real author’s names appear. This would make product marketing happy since the book would no longer be an “Apple” product. The publisher was thrilled about this possible outcome. They definitely wanted our names on the book.

I don’t know for certain but I believe that Bertrand Serlet was the one to propose this solution to Steve Jobs. Amazingly Steve agreed to OK a one time exception to the Apple policy. (I would have loved to be a fly on the wall in that meeting!) The crisis was over and the book was published soon after.

Of course I was ecstatic about the result. It was totally unexpected and, as you can imagine, quite satisfying. I was extremely proud of the work I’d done on the book and was thrilled to have my name with Bunny’s on the cover. I still feel that way today, almost 9 years later.

And one more thing: Thanks again Rich.

 

Macworld

Today it was announced that the Macworld print magazine is being discontinued and virtually all of the editorial staff is being let go. Even though I don’t personally know any of the people being laid off, other than a tiny amount through Twitter, I’m quite sad for them and for the magazine. And there is something personal about it for me also.

When the Mac was introduced in 1984, my life veered from a life studying physics and went into a totally different direction. (I wrote about this previously in some detail in my post 30 Years of Macintosh.) For young people in todays world it is almost impossible to imagine how we learned about this radical new computer. There was no internet as we know it today. No World Wide Web, no Twitter, no online blogs, no RSS feeds of news stories.

The way most of us found out information about the Macintosh was through the monthly publication Macworld. I remember eagerly awaiting each new issue. It was filled with tons of information that wasn’t available anywhere else. In the early days I read every word of every issue the same day it arrived. Every word. And the Macworld conferences were must attend shows and continued to be for more than 20 years. (I still get excited thinking about that Levco 68020 board that you could put in a Mac.)

I still have two issues from the early magazine. These issues made a difference in my life. I’ve kept them for 30 years and I’ll keep them for 30 more. Macworld ceasing publication seems personal. My heart goes out to those who’ve lost their jobs. And for the Apple community that has lost an old friend.

30 Years of Macintosh

Without a doubt the introduction of the Macintosh changed my life.

In 1984 I was nearing the completion of my PhD in physics. I knew I wasn’t going to continue in physics and I had no idea what I would do instead. My interest in the personal computers of the day was non-existent. In January 1984 I was out of the country so I missed the introduction of the Mac. But a colleague had a friend who worked for Apple and that friend brought a Mac over to show us. It seemed like magic.

I was totally hooked. Stanford had some Macs that you could go and spend time with, playing with MacPaint and MacWrite. When Apple offered Macs through the university at $1000 (a huge discount from the $2500 list price) I scraped together money I didn’t have and bought one.

In the early days of Macintosh the internet was just a bit different than today. A couple of people at Stanford started the “Info Mac Digest” which was a daily mass mailing that went to thousands of people. It was an incredible information source and consisted entirely of postings from people who shared excitement about this sea change in computing. For a period of time I was moderator of info-mac and through that got to meet many people in the Macintosh community, many of which are colleagues and friends today. I have to take at least partial credit for organizing the “netters dinner” that took place annually around MacWorld. I still remember the year that about 70 of us gathered at MacWorld and walked from Moscone up to Chinatown and overtook the Hunan Restaurant. (See Netter’s Dinner.)

Stanford had a users group, SMUG, that met regularly. Gus Fernandez started a developers group associated with SMUG and he seemed to have every Apple superstar come and talk about Macintosh. I don’t remember everybody but I do remember Andy Hertzfeld, Larry Kenyon, Bruce Horn, Chris Crawford, and Bill Budge coming and blowing everybody away with stories, demos, and more. I still remember Andy saying that even though the LaserWriter had a 12 MHz processor (instead of the 8 MHz of the Mac), running PostScript brought the processor to its knees!

All this motivated me to go to the Stanford library where they had a loose leaf copy of a draft of Inside Macintosh and I started reading. Everything was totally new and exciting but completely foreign to me. I’d only done programming in Fortran previously and Pascal was literally a foreign language. It was nothing like the computing I’d done on mainframes! On July 13, 1985 I went to the “MacAfrica” one day class taught by Dave Wilson (see MacAfrica) and learned a ton.

When I finished grad school and started looking for jobs I had a couple of opportunities with high tech companies doing computing work that didn’t really excite me but they were good opportunities nonetheless. Then by chance I met Dave Gustavson at SLAC who was looking for a Mac programmer to do Mac programming using FORTH on a project to control a piece of hardware. I ended up working for him in the Computation Research Group at SLAC programming the Mac using the fantastic Mach1 programming environment created by Rick Miley and others at the Palo Alto Shipping Company.

One bonus of that job was that Dave got one of the first Apple LaserWriter printers. I got a serial cable and started to learn the PostScript programming language. Since it was syntactically similar to FORTH it was a breeze to get started. This was my real first experience with computer graphics and it was a really easy way to learn. This was helpful when a friend at SLAC, Kathy Dager, put me in touch with Dick Sweet at Adobe Systems.

At Adobe I got the opportunity to do a wide range of things, including teaching PostScript programming classes to a wide range of people, working with a number of high profile software developers, including Apple, Aldus, and Quark. While Adobe was in development of a second version of the PostScript programming language (PostScript Level 2) I got to be part of the design of the language.

When Adobe decided that they needed to write a new LaserWriter driver for the Macintosh, I met Rich Blanchard and he and I co-designed and (with a team of talented people) wrote a new PostScript printer driver for Macintosh. That project became a joint project with Apple and became Apple’s LaserWriter 8 printer driver.

This led to my direct involvement with Apple Computer. Over time I worked with Rich and others from the LaserWriter 8 team at RBI Software Systems where we did contract work for Apple, Adobe, Sun, IBM, and others. After 5 years of working with Apple as a contractor, Apple decided they wanted us to work exclusively for them and our team at RBI became Apple employees. I worked at Apple almost 13 years before leaving in January 2013 to take a break from working in the world of technology.

Without my involvement with Macintosh, I would not have met my wife of 25+ years nor most of the people who are my friends today. It has influenced my career, my personal life, and many of my interests that continue to this day.

So I mean it when I say the introduction of the Macintosh changed my life.

Moving the Crystal Ball

I never expected that my graduate school experience would include a ride in a C-5A military transport airplane, much less the opportunity to be in its cockpit during a mid-air refueling. But amazingly it did.

In April of 1982 I was part of a team that moved the Crystal Ball, a detector used for particle physics experiments, from Stanford Linear Accelerator Center (SLAC) in Menlo Park, California to Deutsches Elektronen-Synchrotron (DESY) in Hamburg, Germany. The Crystal Ball was unique among detectors used in particle physics in that it consisted almost completely of a spherical array of sodium iodide crystals and was an excellent tool for measuring the energy of gamma ray photons that can be produced in collisions of high energy particles. The success of the Crystal Ball at SPEAR resulted in an invitation from DESY to move it to the newly upgraded DORIS storage ring in Hamburg. (Some additional detail about the detector itself can be found in my PhD dissertation, starting on page 23 of the linked PDF file.)

Because the Crystal Ball was largely made up of sodium iodide, it needed to continually exist in a temperature and humidity controlled environment. Without this special handling, the crystals themselves would corrode and be worthless for experimental purposes. In addition there were concerns about it encountering excessive g-forces (i.e. sharp jolts) that might crack one or more crystals. Ultimately it was decided that instead of sending the most delicate portion via cargo ship, it would be transported by a C-5A military transport plane.

The heart of the detector was carefully packaged into special boxes constructed with a styrofoam cushion against shock and which allowed the flow of dry nitrogen to control the humidity. These boxes were loaded into a specially outfitted US shipping trailer and trucked to Travis Air Force Base northeast of San Francisco. The trailer itself was loaded into the C-5A and detached from the truck which stayed behind.

The cargo area of a C-5A is massive tube. Here’s a photo prior to the trailer being loaded.

Prior to the flight we got a tour of the cockpit and I got to take some photos. This was as close as I ever expected to get.

There were a couple of unusual aspects to flying in the passenger portion of the C-5A. For improved safety, the seat backs are in the direction of travel. At first this seemed odd but once you could no longer see out it really didn’t make any difference. And the windows themselves were either non-existent or were so high up that you couldn’t see out of them while seated. The biggest issue while flying was that it was LOUD. We all were given earplugs to wear during the flight but even with them it was loud. No doubt it was the most claustrophobic and uncomfortable flight I’ve every taken. But also the most incredible.

We took off and after a few hours there was going to be a mid-air refueling. I don’t know if that was strictly necessary or was done so that they could practice the process. Either way it was incredibly exciting because our team from SLAC was invited to the cockpit in groups so we could watch!

When I got to the cockpit, this was the scene I saw.

After a short while I got to locate myself just behind the pilot’s seat, to the left of his left shoulder. And what I saw startled me at first. Flying at our speed, just above and in front of us, was another airplane. The photo below was taken through the left side of the windshield in the cockpit and you can clearly see the boom that was already attached to our plane, providing fuel. I don’t know the distance between the two planes but it could have been as close as 20 feet and almost certainly wasn’t more than 50. Let’s just say it was close.

Below the boom is a window where the boom operator in the other plane can see our plane and properly guide the boom. I was able to take a photo where you can see the boom operator’s face through that window.

Once the refueling was complete, the boom was withdrawn and the other plane slowly flew away from us.

Once it got a sufficient distance away, the fins on the boom became visible.

What an amazing opportunity! It was an unforgettable experience to be in that cockpit. And I can’t believe that I got to take photos.

Once we’d taken off, the landing was the next risk point in the journey. Because large g-forces could be damaging to our cargo, we’d equipped the trailer with recording accelerometers so we could monitor the conditions. I’m not exaggerating when I say that it was the smoothest landing I’ve ever experienced while flying. We landed safely and encountered no problems with the detector.

Here’s a photo of the trailer being safely unloaded from the C-5A. That’s me with the red backpack on the right side of the photo.

They took a group photo of the flight crew plus our team. The civilian team was led by Dr. Ian Kirkbride from Stanford and Dr. Don Coyne from Princeton. Chad Edwards (now at JPL) was a Cal Tech graduate student at the time and is the redhead at the bottom-left in front. I’m at the back with my hair flying, sandwiched between two air force men. Other members of our team were Jim Nolan, John Hawley, Bob Parks, and Sal Fazzino. (Apologies to anyone I left out or whose name I got wrong. It was almost 32 years ago!)

Now all we had to do was drive from where we’d landed at Rhein-Main Air Force Base in Frankfurt to our final destination in Hamburg. But there was a surprise in store for us.

During the drive from Frankfurt to Hamburg we took turns traveling inside the trailer, riding with the crates holding the Crystal Ball hemispheres. The idea was to ensure that the environment was being maintained during the trip. At some point along the drive I was in the windowless trailer when the truck unexpectedly slowed down and stopped. The truck had blown out a gasket or thrown a rod and that was going to require a major overhaul. That didn’t seem like too big a deal until we found out that there was only one other truck in Germany that could pull our trailer. Apparently the coupling needed for pulling an American trailer was rarely available. It’s safe to say that there was a lot of confusion when the breakdown occurred. I think this photo captures that.

In truth, the remainder of the trip went smoothly. The replacement truck arrived the following day and we were able to transport the trailer containing the Crystal Ball safely to its new home at DESY. Here’s a photo of the trailer after the Crystal Ball was unloaded from it at DESY.

And the Crystal Ball was installed inside the radiation area where the beams collide.

It was all quite an adventure. And one of my fondest memories from graduate school.

On the Debug Podcast

Recently I made an appearance on the Debug podcast, hosted by Guy English and Rene Ritchie. It was terrific fun talking with them and we’ve gotten a lot of positive feedback from listeners. We had so much to talk about that they broke it up into two parts.

In Part 1 we talk about how I got into computing, working with FORTH at Stanford Linear Accelerator Center, my days at Adobe Systems in the late 1980s, working at General Magic, and then RBI Software Systems. Part 1 ends just as we are talking about RBI moving to Apple to work in the Graphics and Imaging Group in June, 2000.

Part 2 begins as I arrive at Apple and begin working on Printing and Graphics just as Mac OS X was ramping up for a beta release in the fall of 2000 and the 10.0 release in the Spring of 2001. It was a fantastic time to start at Apple and be a part of its evolution. And yes, we also talk about bagels.

If you haven’t already, I hope you listen in.

How I Became a Movie Producer

In my career I’ve been lucky to get to do a variety of things. At Stanford I worked as a graduate student doing research in high energy physics. My work at Adobe, RBI Software Systems, and Apple was primarily software development, but I also did 3rd party developer support, taught PostScript programming, wrote numerous technical documents, and even wrote a book. But I never imagined that I would be an associate producer of a movie.

It started on June 26, 2012, when a New York Times article caught my eye. Filmmakers Lindsay Blatt and Paul Taggart were making a short film, Herd in Iceland, documenting the historic herding of the Icelandic horse. The story they were filming was from another world, one so different than the one I live in, but one I have a connection to nonetheless. You see, I’ve been fortunate enough to be able to ride my beautiful Icelandic horse Katla for 7 years now. She takes me to places that connect me with nature in ways that I could not do without her.

Reading the article about Lindsay and Paul and watching the trailer to their film brought tears to my eyes. The Icelandic landscape is so beautiful and seeing the elegant Icelandic horses running freely in it was a deeply moving experience. When I read that they had started a Kickstarter project, I knew I had to participate. I wanted to see their film succeed.

I’d already been part of several Kickstarter projects and it had been quite gratifying. In each case the results exceeded my expectations, especially the project by my friend Basho Parks, who created a wonderful album with his partner Jenn Rawling.

For the Herd in Iceland project, the question was how much to contribute. I looked at the project and they were trying to raise $16,500. At that point they hadn’t raised anywhere near that much money. I saw that I could be listed as an associate producer on the project if I contributed $2000. But that was insane. Yes, I loved what I saw of their project, but I’d never sent that much money to someone I don’t know. I’ve rarely sent that much money to anyone I do know!

I re-watched the trailer and teared up once again. I really loved what they were doing with their film and wanted them to be able to do it. It was right around my birthday so I decided I’d forgo anything else for my birthday and give myself the biggest birthday present ever. I signed up. It was crazy, but I was very excited.

The DVD for the movie arrived just before Christmas. Every year my wife Leslie and I pick a movie to watch on Christmas Eve and this time it was going to be Herd in Iceland. I put the disc in and as soon as the title sequence started I teared up. The sight of those horses in that country just does it to me.

And when the credits come up at the end, there I am as one of the associate producers.

Lindsay tells me that the Kickstarter money is, in part, enabling them to enter their film into film festivals this year. Most recently they attended the 2013 Black Hills Film Festival and were surprised and thrilled to win Best Documentary Short.

I’m looking forward to them coming to festivals in the San Francisco Bay Area and I’m crossing my fingers and hoping that they get into the Santa Cruz Film Festival. If so, my many friends in this area that have Icelandic horses will be able to come and support it. And still more people that have not seen the beauty of the Icelandic horse will be able to share in that experience.

Lindsay has a calendar of their film festival appearances, but you don’t have to find a film festival to see the film. The movie and a book of images from the movie are available for purchase.

Lindsay and Paul made a lovely film and I am proud to have been a small part of it.

AWK! That Can’t Be Right!?

Predicting when software will be ready to ship is hard. Especially when the software involved is:

• a complete rewrite from scratch of already existing software.
• being written by a completely different team (and company) than the one that wrote the original code.
• a system software component that interacts with virtually every 3rd party app on the platform.
• required to be fully compatible with the existing software, plus new software and hardware in development.

But that was exactly the scenario I was in, along with Rich Blanchard and the rest of the development team, when I was at Adobe Systems circa 1991 writing a replacement for Apple’s LaserWriter printer driver. And the software we were writing was a critical part of Adobe’s strategic plan for preserving its largest income source at the time, PostScript licensing revenue. No surprise that there was a lot of scrutiny about the project and when it was going to be completed.

Years later, the website MacJournals.com did a write up about the project, including quite a bit about what role the LaserWriter driver software played in the printing system on Mac OS at the time. I have my minor quibbles with some of the details of that write up but one thing was true: that software project really burned me to the ground and was a major factor in my deciding to leave Adobe for greener pastures in 1993.

The Definition of Bad Management

There are a lot of stories about the project I could tell that would raise the hair of every software engineer on the planet, but one clearly defines the term “bad management”.

Part way into the project, Adobe hired “Stoy Aho” to manage the project and the engineering team. As far as I could tell, Stoy had no experience managing a software project or software engineers and there was no evidence that he knew how to write software beyond simple UNIX shell scripts. And even that ability became suspect.

As the completion date for the software kept being pushed out (see the bulleted list above for why), upper level management at Adobe started having meetings every day at 8am to discuss the status of the project. Stoy went to these daily meetings to report how things were going. In order to satisfy his need for something new to report, each team member was required to write a status report each day.

But we were converging on completing the software and some of the tension the engineering team members were feeling began to dissipate; things were looking good. So it was a complete surprise when Stoy came to me and told me how worried Adobe management was about the project. It turned out that he was showing them information he had calculated from our bug tracking database. By using the rate we were fixing bugs and observing the rate that new bugs came in, he had potentially useful information about predicting when the software would be ready to ship.

And that is why he was alarmed. Despite our sense that things were going much better, his analysis of the data indicated that they were getting progressively worse. I asked how he computed the results that he obtained and Stoy said he’d written an AWK script to process the raw bug count data. I immediately demanded that he show me the script.

I didn’t know the AWK programming language but it didn’t take me long to find the problem. At a critical point in his computations, Stoy had inverted the numerator and denominator in one of the calculations, causing his script to produce results that were the exact inverse of the truth! His program showed that the faster we fixed bugs, the longer it would take to ship.

Repeat after me: Stoy’s AWK script showed that the faster we fixed bugs, the longer it would take for the software to be ready.

This occurred over 20 years ago so I don’t remember exactly what I said at the time, but I’m pretty sure my response at the time was something besides AWK.