Dec 03 2011

Setting Up CoffeeScript in CodeRunner

The nifty Mac app CodeRunner lets you edit and run code written in a variety of programming languages in a window. It comes pre-installed with the most likely programming candidates – AppleScript, C, Perl, Ruby, etc – and allows you to add others fairly easily. Just pick your language, write your code, and run.

My pal John asked for a little help getting the app working with CoffeeScript ((Yes, when John August isn’t busy writing awesome movies and/or writing Broadway shows and/or podcasting and/or managing several on-going software products, he’s writing code in CoffeeScript. Math-y code, no less.)), and since this process doesn’t seem Google-able at the moment, I figured I’d give a little back to the Interwebs by detailing it here:

To set up CoffeeScript with CodeRunner you need to install Node.js, npm (node package manager), and the CoffeeScript command line tool on your machine, then add CoffeeScript to CodeRunner’s configuration.

1. Install Node.js and npm

You can install both Node.js and npm at the same time via the Mac installer available at At the time of this writing, the direct link to the latest Mac installer is here. Just download, run, and you’re good.

2. Install CoffeeScript

After you have installed npm open Terminal and run the command sudo npm install -g coffee-script. It will ask you for your password, and then install the command line CoffeeScript tool onto your system.

3. Configure CodeRunner

In CodeRunner, open the Preferences and add a new language to the list of available programming languages (you should probably name it CoffeeScript). Under Run Command write coffee $filename, set the Syntax Mode to JavaScript and the File Extension to coffee. For the visual learners out there, here is a screenshot of what that should all look like:

CodeRunner screenshot

That’s it. You should now be able to run CoffeeScript in CodeRunner. You can add other languages in a similar manner – install the command line version of the language processor and configure the app to use it.

Happy programming!

Oct 06 2011


I bought my first cell phone in 2003. It was a Samsung flip-phone, top of the line according to the sales woman, yet also somehow free with my T-Mobile contract1. The phone was a morass of features buried in menus and submenus. It would be easier to escape one of those death traps from the Saw movies than it was to send a text message. Worse yet, I was paying for features I didn’t understand and couldn’t use. After using that thing for a couple of months I finally built up the courage to call Samsung technical support, which, as expected, was a labrynith of menus, rife with confusing options and emotionally unsettling muzak. Twenty minutes later – approximately four jazz flute solos, if I remember the musak correctly – I got to talk with a delightfully inept Pakistani gentleman named “Christopher,” who repeatedly told me to refer to the manual that came with the phone. Eventually I gave up and decided to just settle for what I got.

If Steve Jobs settled for the way phones were back then, we’d never have the iPhone. The iPhone is brilliant because it solves a problem with nearly all cell phones since they started adding more than just talk to them – how do I use this damn thing? The iPhone presents everything you want to do, clearly marked, right on the home screen.

Obviously, the iPhone does more than just that, but the resistence to settling for a bad status quo is what I think defined Steve Jobs. Before his return to Apple he founded NeXT, which formed the technical foundation for what we know now as Apple. NeXT had a number of great innovations, but the one that strikes me the best is Interface Builder. IB allows developers to quickly and easily build user interfaces and connect the interface to code all in a GUI. Here’s a YouTube video of a young Steve Jobs demoing IB back in 1991. If you’ve ever had to build a user interface in code, you’ll recognize IB as a revelation. It’s something many of us Mac and iOS developers take for granted now, but IB is exactly what Steve Jobs has been all about: it gives people a better way of doing something easily that used to be terrible, but that we were all resigned to as ‘the way it is’.

In other words, Steve Jobs declared war on mediocrity.

It’s easy to recognize when something doesn’t work, but it’s harder to see when something works, but is sort of awful. These are the “unnoticed problems” of the world2. It’s not that we’re unable to see that something is wrong, it’s that most of the time we’re fine settling for what little works right. Maybe it’s optimism, or laziness, or simply a lack of will, but we let these unnoticed problems persist. We tolerate mediocrity because it’s easy.

Steve Jobs was great at solving those types of problems. The success of the iPod didn’t come simply from how nice the devices were, they were the first MP3 players that were integrated with really stellar music management software. Before the iPod we settled with poor music transfer software, and poorer music players. iTunes made everything easy. It made things better.

At the end of the day, that is Steve Jobs’s legacy – he made things better. He made owning a cell phone better. He made listening to music better. He made buying music better. He made making software better. He made selling software better. He made using a computer better. He made managing our data better.

I want to make things better. I don’t want to be the guy that grits his teeth and suffers through using a poorly designed phone. I don’t think I have to be that guy. I don’t think any of us have to be that guy. Steve Jobs sure as hell wasn’t that guy. So the next time I have to deal with something that’s not okay but not great – which will undoubtedly be tomorrow – I’m not just going to put up with it. I’m going to do something about it. In that way, even in death, Steve Jobs is going to make something better: me.

  1. I was sucked into getting a T-Mobile phone because of those Catherine Zeta Jones T-Mobile commercials. I’ve never forgiven her for that.

  2. A great example of this is how for millions of years the peoples of the Earth have been using measuring cups that you can’t read while you fill. Oxo and company finally solved this problem (via Gruber).

Aug 11 2011

Poor Patenting

In “Why Software Patents Are Not Fixable” Marco points out how completely broken the current U.S. patent regime is, and why it’s a giant mess for everybody. Smartly, he lays blame at the doorstep of the US Patent and Trademark Office. In that, we are in 100% agreement.

Like Marco, I’m not a lawyer, but at one point I thought I wanted to be one. I got into a pretty good law school, and prepared for the patent bar, which is required to file patents with the USPTO[^why I quit]. With that background, I think I can add some more to what Marco is saying.

Why the USPTO Sucks at Its Job

Marco explains the two big requirements for a patent: novelty and non-obviousness. You can check novelty by looking at prior art, and I’m not sure how big a problem that ends up being in practice. Non-obviousness is a different story; I think this is where the system is falling apart. How come?

Patents take a long time to get. In fact, Austan Goolsbee, Obama’s former head economics advisor, made the rounds on the TV last week touting acceleration of the patent granting process as a bi-partisan measure that would help the economy1. I don’t recall exactly what the average is for being granted a patent, but I know it’s measured in years. So it’s not like patent examiners are rushing through these things and shooting them out without looking at them. There’s a lot of work that goes into the examination process.

The next logical question you might ask, then, is who are these patent examiners? That’s great question. Here are the requirements to become a Patent Examiner for the USPTO:

  • Be a US Citizen or National.
  • Be willing to live/work in the D.C. area.
  • Have a 4-year degree in a science or math discipline.

That’s it. Work experience helps, but basically the USPTO is just looking for people with an educational background in the art the patents are based on. A bachelor’s degree is considered “ordinary skill” by the USPTO.

And that is the problem. The bar for “ordinary skill” is set far too low. In the sciences, we nearly universally agree that the people that know what’s going on are the one’s with Ph.D.s. Bachelor’s degrees simply don’t carry a lot of weight in the biological sciences standing next to Ph.D.s and M.D.s. Yet to the USPTO, a person with a B.S. is qualified to determine if a medical device an M.D./Ph.D. has invented is a non-obvious invention. Seriously.

I’m sorry, but that’s just not how it works. A B.S. degree is the beginning of one’s journey in mastering an field, not the end. Which is why there’s another degree called Master, and terminal degrees called Doctorate. Having a degree doesn’t even mean the person is a competent practitioner in the field, let alone skilled enough to judge patents2.

Now, it’s entirely possible that 100 years ago, when cutting edge technology literally involved a sharp blade and better levers, normal users of a tool might have had “ordinary skill” in the art, but today the fields of science and technology are so huge and so complex that it’s simply not credible to believe a non-Ph.D. could know what is really going on in the peripheries of the field.

What’s worse, the longer a person is a patent examiner, outside the field they’re supposed to be policing, the less they’ll know about what is new and exciting in their field. Counter-intuitively, a patent examiner is probably most qualified to judge non-obviousness the day they’re hired by the USPTO, and decline every day thereafter.

Why Software Patents Might Be Fixable

Understanding all that, I think there are some obvious solutions to the patent crisis. The USPTO needs more qualified examiners to determine the merits of a patent. My suggestion would be to look to the peer review model academia uses. Yes, yes, yes – that’s not a perfect system, but it’s miles better than what the USPTO is doing, and might even work better for patents than for journal articles.

Here’s what you do: make patent reviewing a requirement for all federal research grants, and give rewards to reviewers in terms of prestige and priority access to key talks and meetings. That would give you a huge pool of quality academics – experts in their fields – to review patents, and give incentives to people, particularly younger faculty, to step up and get involved. Have a three person committee review each patent based on non-obviousness, while the USPTO’s patent examiner does the logistical work (checking prior art, checking drawings, etc). This way we get to keep the current crop of examiners, but ensure we get a better review of a patent’s merits.

Moreover, the incentives for academics reviewing patents more closely aligns with society’s goals in granting exclusivity. That is, they want to prevent dangerous and over-broad patents from restricting innovation, but don’t want the patent process to grind to a halt, lest their own ability to get patents is compromised. Right now, patent examiners have zero skin in the game – they don’t work in the field anymore (assuming they ever did), so who cares if someone gets a patent that screws everyone else up? I trust the experts to set the bar where it needs to be – high enough to prevent riff-raff from getting patents that could destroy an industry, but low enough that real invention is still being protected.

There are still problems unique to software patents that might make them untenable. Marco might be right to say the system is broken beyond repair, but I’m not sure. I am sure, however, that there’s no way we’d get rid of the patent system, even if just for software. To keep advancing as a society, we’re going to need an innovative solution to the software patent problem.

  1. I’m pretty sure if Marco saw any of these interviews his head would have exploded.

  2. With no disrespect meant to Marco, he has himself admitted that while he is an excellent programmer, he’s a not very great computer scientist. That’s the kind of distinction that the USPTO should be taking into account, but doesn’t seem to be. Even people with excellent technical skills might lack the depth of understanding need to analyze novel inventions in that field.))

Jul 21 2011

Two For the Price of 1.1

FDX Reader iPhone screenshot

FDX Reader 1.1 is out today! In addition to bug fixes and a price change, we’ve turned our little iPad app into an iOS Universal app. That means if you’ve got a device running iOS 4.2 or better you’ll be able to run FDX Reader on it. That means you, iPhone and iPod Touch.

John made the announcement at, and explains some of the background behind the app. We decided pretty early on to bring FDX Reader to the iPhone, and that we wanted you to be able to buy once and get both the iPad and iPhone versions. I think most people would agree that it’s kind of a dick move to make someone pay twice for the same thing. But the thing is, the iPhone version of FDX Reader turned out to be a very different app from the iPad version.

The iPad version of the app uses a page flipping metaphor. We fill the screen with content, and you can flip forward and backward through the script, always looking at a single full screen of content. This is very natural for a screen the size of the iPad, and I think it works very well. But this doesn’t scale down to the iPhone’s smaller screen size. Trust me, as the guy responsible for writing this stuff, I desperately wanted to just load the iPad code-base onto the iPhone, rejigger some widths and heights, and call it a night. But just reformatting the same views for the iPhone would have meant flipping up to four times more on the iPhone than on the iPad, and we couldn’t do that to you.

Long story short, the FDX Reader for the iPhone uses a scrolling metaphor. The entire script is loaded, and you scroll through it as you read. This feels much more natural on the iPhone’s smaller screen, and we all think it works pretty well. Unfortunately, that meant rewriting all of the script display code, most of the code related to the page jump slider and the font size switcher, and some of the data model internals. This is why it took us a while to put the iPhone version of the app together, and why we’re treating it like a big deal.

Moving forward, we’re going to have to handle two separate code-bases, each with it’s own needs and potential bugs. I mean, don’t cry for me Argentina, but, yeah, it’s going to be kind of a pain. In light of this, I completely understand why some apps charge separately for iPad and iPhone versions. If you can’t just re-scale your interface, it’s potentially a lot more work to support the iPhone and the iPad version. I think going Universal still felt right for us, but I’m much more sensitive to apps that split the iPad and iPhone versions. It’s not always motivated by greed, but by the amount of work needed to support two very different user interfaces.

If you’ve already bought FDX Reader, download the update and try it out on your iPhone or iPod Touch. If you haven’t bought the app yet, now is as good a time as any.

May 25 2011

FDX Reader's First Bug

Congrats to Khan Tang for finding the first FDX Reader bug.

Here’s the issue: if your script ends in either a character cue or a scene header, the app will crash because it’s expecting something to follow it.

Why would a screenplay end with one of those tags, anyway? In most cases, it’s because the screenwriter typed “The End” and used one of those tags instead of an action line. It’s not wrong. It’s just not what we were expecting.

We’ve already found and fixed the bug in our code. We just have to do some internal double-checking, and we’ll submit an update to the App Store that addresses this bug in the next day or so.

Apple’s review process can take a week, so in the meantime if you find that a particular script crashes when you try to run it, please check to see if the last line of your script is a character cue or a scene heading. If it is, you can change it to an action element so that it will work in the app until the update comes out.

You shouldn’t have to modify your files to work with FDX Reader. This is just a short term workaround while we get the update out.

On the other hand, if the app is crashing and your script doesn’t end with one of those element types, please let us know as soon as possible via the official email: App crashing bugs are our highest priority (we take all bugs seriously, of course, but the app shouldn’t crash, ever). If you don’t mind sharing a sample file that is crashing in the app, that would be extremely helpful. Of course, please don’t send a super top-secret Star Trek 2 script, or something of the like.

We hope you’re enjoying FDX Reader and finding it useful. We’ve been getting great feedback (good and bad). If you’ve got something to say, let us know.