But unlike last time around¹, OmniFocus 2 isn’t ready to take over my life yet, so for the moment I’m still usually working in OmniFocus 1. Every couple days I fire up OmniFocus 2 to kick the tires a little more and sometimes provide some (hopefully useful) feedback to the good folks at the Omni Group. (And yes, they’re listening.)

Unfortunately, switching fluidly between the two versions becomes problematic when you bring third party tools into the mix. Case in point: AppleScripts that tell application "OmniFocus" expect that they’re working with an application called OmniFocus. So if OmniFocus 1 is called “OmniFocus 1″ and OmniFocus 2 is called “OmniFocus”, your scripts will always invoke OmniFocus 2 until you rename the applications – even if you’re currently working in OmniFocus 1. That’s hardly ideal if you’re switching version with any regularity. And it was keeping me from using OmniFocus 2.

The solution? A script, of course! Here’s a script that automates the process of switching between primary versions of OmniFocus. This is what it does:

1. Checks your applications folder for items matching the name OmniFocus* and asks you which version you’d like to bless² [See the end for a version that skips this]
2. Renames the blessed version to “OmniFocus.app”, and the other versions to “OmniFocus [version].app”
3. Launches the blessed version

Here it is in action:

Bless OmniFocus demo

For those who enjoy reading detailed notes:

• If you choose the version that’s already blessed, that version will be activated and no renaming will occur.
• If OmniFocus (or many OmniFoci) is running when a the script is ready to rename, the script will handle quitting and relaunching for you.
• If you happen to have multiple copies that would have the same target name, only one will be renamed (i.e., files shouldn’t be randomly overwritten).
• While I built this workflow for the purpose of OmniFocus testing, it could work just as easily with any other application: just change the application name at the beginning of the script. You can also change the applications folder.
• If the script encounters an application without a version number in its metadata, it will be renamed according to its creation date.
• If you use the tell application "System Events" to choose from list line, the dialog will appear at the front (rather than possibly being buried behind windows). However, in my experience, System Events can hang, so I endure the less convenient version in order to keep things running quickly.
• …and of course, your user account needs to have the proper permissions to rename the files.

I’ve been using this for about a month without issue, but of course use at your own risk and please let me know if you have any issues.

Grab the script here:

p.s…

Michael Schechter wondered about a version that blesses a specific version, rather than prompting for user input. This could be useful if you want to…

• Set up a Hazel rule or timed Keyboard Maestro action to automatically switch versions
• Keep two versions of the script for each version of the app to trigger by a launcher

So if you’d prefer a “headless” version, try this one.

1. OmniFocus 1 replaced Ethan Schoonover’s exceptionally clever but ultimately hackish OmniOutliner scripts, Kinkless GTD, so it wasn’t long before OmniFocus quickly surpassed kGTD’s utility. But OmniFocus 1 is now a very mature product, so it may be some time before OmniFocus 2 can fill its shoes.↩
2. Blimey, why the blessing? The name comes from a system command to choose which operating system to run on startup. The OS that’s set to run is “blessed”, and you select it by running the bless command.↩

So I’ve been using Ryan’s tip with one minor change: it uses the world’s simplest AppleScript to introduce a time limit for how long distracting apps can remain open (or active). Just create a Keyboard Maestro macro like the following (or download this example):

As you can see, this macro waits one minute (60 seconds) before hiding my Twitter client. Works like a charm: hiding the app doesn’t force me to leave Twitter; but reactivating the app becomes a conscious act of will that forces me to answer That Question.

(I use a similar macro to quit my RSS reader after a more generous 10 minutes.)

Scientific American I think it was did a study in the early 70′s on the efficiency of locomotion. What they did was for all different species of things on the planet – birds and cats dogs and fish and man and goats and stuff – they measured how much energy does it take for a goat to get from here to there… and they ranked them and published the list, and the condor won, it took the least amount of energy to get from here to there, and man didn’t do so well, came out with a rather unimpressive showing about a third of the way down the list.

But fortunately, someone at Scientific American was insightful enough to test man with a bicycle, and man with a bicycle won—twice as good as the condor, all the way off the list. And what it showed was that man is a toolmaker, has the ability to make a tool to amplify the amount of inherent ability that he has.

And that’s exactly what we’re doing here. We’re not making bicycles to be ridden between Palo Alto and San Francisco… but in general we’re making tools that amplify the human ability.

(video on computerhistory.org)

This is why I love technology.

You can grab them individually on the Github repo or my download page. Or, just download them all in one go.

10/31/11: Updated to work with Growl 1.3 (MAS version).

TL;DR: If you want to use Growl notifications in your AppleScripts without causing problems for people who don’t have it installed, feel free to use this code.

For anyone who writes AppleScripts that use Growl notifications, the problem is familiar: if a user doesn’t have Growl installed, the script throws a fit when they try to run it. Specifically, at load time, the AppleScript interpreter looks for all the applications listed in the script to retrieve their scripting dictionaries, and if it can’t find any of the listed applications, it asks the user where to find it:

This can be frustrating for users who don’t have Growl installed: either they don’t know what Growl is (and therefore have no idea what to do in this situation), or they actively prefer not to have Growl on their system. In neither case do you want to force users to install Growl.

Although others have written about this issue—including a couple solutions that work—I still spent a lot of time and frustration trying to work through the issue and thought it might be helpful to post a survey of different methods that don’t work—and why.

Method one (bad): Growl, straight-up

Pros: Elegant, simple, as Growl intended. Cons: Script chokes on Growl-free systems.

The simplest solution is to call Growl using the intended syntax, ignoring users who don’t have Growl installed. The code is straightforward and easy to understand:

But if the point of your script is to simplify a task, it’s not very helpful to publish something that won’t run for those who don’t happen to share your idea of a pleasant notification experience.

And you probably don’t want to maintain two versions of the same script.

Interlude: Detecting Growl

To support both Growl-enabled and Growl-free systems, you need to detect whether Growl is installed before deciding what to do. For that, best practice¹ seems to be to first check whether Growl is running:

Then, if Growl isn’t running, check if it’s installed, try to launch it if so², and run the alternative notification if not:

Method two (bad): string encapsulation

Pros: Used to work; doesn’t choke on Growl-free systems. Cons: No longer works with Growl.

For a long while I used a very simple method that encapsulated Growl statements in a string variable, which prevents the interpreter from choking on systems that don’t have Growl installed:

Unfortunately this method no longer works when Growl is installed:

So that’s out.

Method three (bad): growlnotify

Pros: Elegant, doesn’t choke on Growl-free systems. Cons: Doesn’t work unless growlnotify is installed.

Another method is to use the growlnotify utility that ships with Growl Extras, and call it via a shell script:

But growlnotify isn’t part of the base Growl installation, so for Growl users who don’t have the tool installed, it won’t be obvious why the notification doesn’t work.

Method four (good): osaScript

Pros: Works for Growl users, doesn’t choke on Growl-free systems, uses standard AppleScript syntax. Cons: Verbose and unsightly.

The first method I found that actually works in 2011, described by elasticthreads, is to encapsulate the entire Growl-facing script as its own (perfectly quoted) string, and run that using the shell tool osascript:

I didn’t want to hardcode the notification parameters, and with all the quoted stringiness, extracting them required writing a method for converting an AppleScript dictionary to string form. Here’s my complete version of this method:

This method doesn’t choke on Growl-free systems, uses standard (though obscured) AppleScript syntax, and works for the Growly. It’s quite a lot of code, though, and isn’t very pretty.

Method five (good): AppleScript literal syntax

Finally—hats off to Dave Nanian for this method—AppleScript has an obscure literal syntax that can be used instead of standard syntax. In brief, literal syntax is a way of describing statements in guillemet-enclosed events and classes. This is what the above code looks like in literal syntax…

N.B. While literal syntax doesn’t require encapsulating the app name in a string variable, you should do this for two reasons. First, if the application name is used, the interpreter will try to find GrowlHelperApp, thus choking on Growl-free systems. Also, Script Editor will try to convert the code to normal syntax, which you don’t want if you’ve gone to the trouble of crafting this version. Note also Nanian’s warning to use tell my application, not tell application.

This method won’t choke Growl-free systems as long as you don’t run the code; make sure you include a check to see if Growl is installed before running this code.

All tedious things must come to an end

Giving Apple the benefit of the doubt, I’ll make two assumptions:

1. It’s generally important to have access to the scripting dictionaries of applications referenced in your script.

2. Growl is an edge case in that it’s simultaneously useful to include in a script but superfluous to the script’s execution.

But it’s a problem that people spend so much time coming up with workarounds for such a seemingly straightforward problem. If you have any other methods for dealing with the “Growl not installed” scenario, I’d love to hear them.

You can download a paste-and-go version of the code (which includes both functioning methods) here, or click here to open it in your script editor of choice³.

1. Much of this is gleaned from discussion and examples posted at the OmniGroup and DEVONtechnologies forums. I think the current version is most similar to one from Rob Trew.↩

2. In theory, you should be able to proceed without explicitly seeing if Growl is running/trying to launch if not, because calling tell application "x" will cause it to launch if it’s not already running. However, there was a time that Growl would crash frequently (I once measured one Growl crash every 7-8 activations), so checking for a successful launch was one way to ensure consistent behavior. Growl has gotten very stable, so this shouldn’t be a problem, but it’s cheap and fast to run the check so I keep it in.↩

3. Hat tip to Don Southard’s handy AppleScript-encoding service, which created the “open” link. ↩

property volume_multiplier : 0.8

tell application "Airfoil"
    set all_speakers to (get every speaker)
    repeat with this_speaker in all_speakers
        set curr_volume to get volume of this_speaker
        set (volume of this_speaker) to (curr_volume * volume_multiplier)
        if (volume of this_speaker) is 0 then set (volume of this_speaker) to 0.1
    end repeat
end tell

I keep two copies of this script (“Airfoil Volume Down” and “Airfoil Volume Up”) bound to ⇧F10 and ⇧F11, respectively, to match the volume keys on my keyboard.

If I ever update them, I’ll do so over on Github.

Download: Airfoil Volume Down and Airfoil Volume Up

This behavior makes sense, on one level level: just sort everything by Due date and you can see when things are planned. But every time a date isn’t met, it has to be pushed back, creating the need for most of my date-related scripts.

Worse, indiscriminate use of Due dates dilutes their value and undermines any task-planning system.

Need to pay a credit card bill today? It’s lost in the mess of other things that are artificially “due” today, and that red Due badge is no longer a respected indication that something needs to happen today.¹

But there’s a better way.² Just use Start Dates to plan what you think you should do, and reserve Due Dates for things that actually have to get done. (To keep this straight, I use a “Due” perspective to show what’s actually due, and a “Do” perspective to show what I’m planning to do.³)

The benefits of this approach are enormous. Things that actually need to happen don’t get lost in the shuffle, and (using time estimates) you can work with more realistic expectations of what can/should happen in a a day.

But switching to this workflow also required re-tooling my scripts, many of which focused on Due dates.

So, as of today, all my OmniFocus scripts default to a Start-based workflow. Here are some of the major changes:

• Today, Tomorrow, and This Weekend all set the Start date of selected tasks by default.

• In addition to pushing back due dates of tasks, Defer now has the option to act on un-timed tasks by pushing their start date back by the given number of days. (This option is on by default.)

• All scripts now work when launched from the OmniFocus toolbar.

• Scripts no longer fail when an OmniFocus grouping header is selected.

• All scripts reorganized for performance and clarity.

You can continue these scripts with a Due-based workflow, of course: this is a matter of changing a single setting in each script.⁴ But if you’re successful with a Due-based workflow, you have much more discipline than me.

Download the lot of them here. (And as always, let me know if you have any problems with them.)

1. Lest anyone complain of the cost of OmniFocus: I’m sure I’ve paid more money to my credit card company in day-of-due-date payment penalties than I have to the OmniGroup. ↩

2. Thanks to David Sparks and Benjamin Brooks for the insights that led to this realization. I mentioned this in a little more detail here. ↩

3. Here are the settings for my Do perspective:
   
   
   … and here are the settings for my “Due” perspective:
   
   
   Both live in my toolbar for easy access.↩

4. For example, in the Defer script, there is a line: “property snoozeUnscheduledItems : true. Simply open the script in AppleScript Editor and change “true” to “false” to switch this setting. If you have any problems, feel free to email me. ↩

Confession: I usually fail to accomplish what I plan for a day. When the morning begins, big plans are in place… but at the end of the day, a pile of undone tasks lingers in my OmniFocus “Do” perspective.¹ More often than not, they just get snoozed for the next day’s action list.

And the process repeats.

It’s demoralizing to watch the Pile of Do grow, and I often feel out of control when looking at what seems like a reasonable list of things to accomplish in a day’s time. Clearly, good intentions need to be tempered by reasonable expectations.

Enter time estimates. Over the years I’ve been using OmniFocus, I’ve never really used its ability to assign a time estimate to projects and tasks. It seemed like a lot of effort for very little benefit: all OmniFocus really does with time estimates is sort/filter.²

But time is a critical dimension of doing: without time, there is no action. It should follow that time estimates are just as important.

So here is my new morning routine:

1. Collect all actions I want to do today by assigning them a Start Date of today.

2. In “Do” perspective, assign time estimates to each item.

3. Check the total time of the day’s planned items; remove lowest priority items until my list is doable. (Use the Total time and Snooze scripts to make this step easier.)

This routine has several immediate benefits:

1. Assigning estimates forces you to clarify next actions. In cases where it was difficult to assign a time estimate, I realized I hadn’t clarified the next action well enough. Poorly defined next action → inaction.

2. Using estimates helps clarify what is feasible for the day. This morning, my first pass included almost 14 hours’ worth of work. Without time estimates, I wouldn’t have known how feasible this plan was.

3. You can start right now. No need to assign estimates to everything in your OmniFocus database; just estimate what you’re looking at for today.

Having seen how simple this process is, I’m shocked I didn’t do this years ago.

1. I keep two perspectives side-by-side in my toolbar: “Due” and “Do”. Due shows tasks sorted by due date; these are items that really truly have to get done by the given date. Do shows tasks sorted by start date; these are the items that I plan to do on a given day. This gives me the benefit of some planning flexibility without the problems that come from recklessly using due dates. For more on this method, see this David Sparks post, which inspired me to use it. ↩

2. While OmniFocus doesn’t do much with estimates out of the box, there are some scripts that can do things like starting timers to keep you on task. See this discussion thread for more info. ↩

Here’s a script to sum the total time of selected items in OmniFocus. Just select some items, fire it off and see how overcommitted you are.

Download it here.

1. A pre-novice saxophonist assaulting commuters’ ears with noise
2. A highly skilled saxophonist assaulting commuters’ ears with extended techniques
3. Whale-song

None of these guesses was correct, as it turns out. As I pulled out my phone to record the scene, it occurred to me that what sounded like the pained vocalizations of a large animal or aspiring musician might be neither.

It was the greasing-song of the downward escalator. Put another way: the escalator was groaning in need of maintenance.

After my train arrived, I inspected the recording to see if it followed any pattern. As the following image shows, it was distinctly periodic—and I had been able to catch almost three full cycles before my train arrived:

What’s more, the cycles are almost exactly 88.5 seconds long. D.C. locals will recognize this as the broadcast frequency of WAMU, American University’s radio station. Which leaves open the question: does the greasing-song represent a breakdown in maintenance, or is it a planned student art installation?

Listen here:

Greasing-song by dbyler

Aug 2011 Lion update: the script works but is quite slow in Lion (it’s zippy in Snow Leopard). I’m looking for a workaround, but this appears to be a Mail.app bug.

TL;DR version: Archive Mail messages with a single keystroke:

1. Download this script and Fastscripts (free for up to 10 hotkeys)
2. Move the script to ~/Library/Scripts/Applications/Mail/
3. Set your hotkey in Fastscripts (Using a letter key is possible but not recommended. Try another character like `\/=- or an F-Key.)

The script will then move selected message(s) to a folder named “Archive”.

More information:

Existing shortcuts to file messages in Mail.app get you down to two or three keystrokes, but that just isn’t good enough for someone who has tasted the sweet, sweet bliss of single-keystroke archiving in Postbox or Gmail.

In my original reply to this superuser thread, I suggested using an AppleScript to move selected messages to an archive, and triggering the script using a single-key shortcut using Fastscripts. That script is simple and straightforward, but it has a major shortcoming: it leaves you hanging with no next message selected, so you have to manually select your next message. Not ideal.

My new script archives messages with a bit more smarts. Here’s what it does:

• If a mailbox is in the foreground, the script moves selected messages to the folder named “Archive” and selects the next available message. Boom.

• But you don’t want to accidentally archive messages whenever you hit your archive key. If the frontmost window isn’t a mailbox, the script will ignore the archiving functions and (optionally) type some text wherever you are. This is useful if you use a single key to trigger the script; without this function, you would never be able to type that key into a mail message because it’s intercepted by FastScripts before getting to the Compose window.

For interested scripters, here were some challenges:

• Select next message: The solutions I found online select the next message by sequential Message ID, which usually means that it only works if your mailbox is sorted by Date Received. Using visible messages gets messages in the order in which they’re displayed. Watch out, though: if message threading is turned on, the top-level thread item is not selectable. See my workaround in the script.

• Enter the keystroke that was captured: Merely telling System Events type the character that triggered the script will trigger the script again, resulting in a virtual infinite loop. I used a paste routine to work around this.

That’s it… happy archiving!

22 Mar 2011 update: fixed bug that caused selection to be lost when only the topmost message in a mailbox is selected.

Learning Materials

I researched several learning resources that had been recommended on Quora, including Big Nerd Ranch’s iPhone Programming and Craig Hockenberry’s iPhone App Development: The Missing Manual.

In the end, I decided to “take” the Stanford iPhone Application Development course, which is available in its entirety on iTunes U. (Note that iTunes U has both the 2009 and 2010 courses. I chose the 2010 version because a) it’s geared for a newer iOS SDK, and b) all the supporting materials are still (as of Spring 2011) available on Stanford’s course website.

iTunes handles the lecture downloads, but I watch them with QuickTime Player for two reasons: it uses less screen real estate, and you can speed up playback by option-clicking the fast-forward button. A text editor is ideal for notes (particularly one that handles Obj-C syntax highlighting), and it’s always handy to keep the lecture slides open as well. Here’s my typical “class time” screen:

Helpful shortcuts:

• Setting up the screen like this is a snap with Divvy. I set up shortcuts to move windows to each half or quadrant of the screen, so they can fly to any position with a keyboard shortcut. Priceless.
• A series of quick-and-dirty AppleScripts—which can be quickly invoked with FastScripts—makes it easy to work the lecture files. Scripts I use (available on Github) include:
  • launch the current iTunes file in QuickTime Player (or vice-versa), retaining the current playback spot
  • jump to an arbitrary playback position in QuickTime Player (especially helpful if I’ve been watching a video on my iPhone)
  • jump backwards or forwards in QuickTime Player

Notekeeping

Right now I keep two types of notes: course notes and error notes.

Course notes—general notes from the lectures or books—go in a single text file that’s easily searchable. I type or copy most of the lecture slides into this document because it’s easier to have it all in one place.

Error notes, which detail all the build errors I get in Xcode, live in Notational Velocity (tagged with “ObjC” and “Error”). Each error note contains the following sections:

• Error message
• Context (anything that might help)
• My code (specific code throwing the error, and which file)
• Problem explanation (interpretation of what went wrong)
• Solution (fixed code)

These error notes are a personal history of the mistakes I’ve made. My expectation is that this practice will have value both now and in the future, but as the good folks at Field Notes say, “I’m not writing it down to remember it later, I’m writing it down to remember it now.” The more I can internalize beginner’s mistakes, the less likely I’ll be to repeat them.

My only complaint w/r/t using Notational Velocity for this purpose is that it doesn’t have syntax highlighting. A relatively minor inconvenience, but I’m hopeful that a future NValt build might include this.

Helpful shortcut: I use a TextExpander shortcut to pre-fill each error note before I start adding data. It simply adds each section’s header—something that might not seem that important, but it saves a little time and helps me be consistent in this practice.

Troubleshooting

Stack Overflow is an indispensable Web site for programming questions/answers. I should probably get better at perusing Xcode documentation, but often it’s faster to search Stack Overflow. (I’ve noticed that most of my problems are answered in Stack Overflow questions with no upvotes, meaning that they’re beginner errors. I’ll know I’ve arrived when I graduate to more popular questions!)

Helpful shortcut: Searching Stack Overflow is nearly instantaneous using a LaunchBar search template set to search StackOverflow with the [Objective C] tag pre-filled. Once it’s set up, ⌘[space] → “so” → [query] gets it done pronto.

With thanks to the author, Timothy Beatty, here’s the original bundle:

For those wanting a little extra functionality, George MacKerron described a method to add tab-completion for Stata variables. I’ve added his code to this version of the Stata bundle. (N.B. If your Stata application is not named “Stata”, you’ll need to make one small change. Open TextMate’s Bundle Editor; then, in the Stata bundle’s Complete Variable command, change the “appname” variable in line 6 to reflect your app’s true name, e.g. “StataMP”.)

Update: I’ve learned that two forward slashes can also be used in Stata for comments, including inline comments. To properly highlight this in Textmate, open the Bundle Editor > Stata > Stata. At the end of this file is the ‘comment.line.star.stata’. Change the match line to this:

(N.B. As Sean points out below, make sure the single-quotes are straight, not curly, when you paste this line. Otherwise TextMate will throw an error.)

That day is today.

Happy Billion Day, everyone!

(One could discount this event by pointing out it’s only the coincidence of a) Julius Caesar’s arbitrary selection of the calendar’s start date, as well as b) the arbitrary—though now standardized—mapping of Latin letters to the 10-digit keypad. I suppose we could also cite the rise of the decimal numeral system in this celebration as well; who knows what billion would map to on a hexadecimal phone keypad, or if we’d even care since 1,000,000,000 is much less elegant as 3B9ACA00 in hex. Then again, many of our declared holidays aren’t much less arbitrary.)