Fraser Speirs Cocoa and Photos

Dual Systems and Cameras as Computers

James Duncan Davidson writes:

Not having a single answer isn’t all that surprising. In fact, having an easy answer for a period of time when it comes to digital SLRs may have been a fluke of history. … The design decisions made by the camera makers are producing really good results in some areas with compromises in others. This means that sometimes Canon is going to be the right tool, other times Nikon.

The problem I have is that my own photography takes me into situations where I want the best of both worlds. I’d really like Canon to provide solutions that cover the full range of what I do, and many of my posts of late have reflected that point of view. I could wait another year or two, or even three for Canon to produce the camera I’d like them to make, but I have more immediate needs.

Could we all just agree on this? Think of the time and effort we would save by dropping the endless and unresolvable Canon vs. Nikon debate.

I’ll be interested to see how Duncan gets on. More than any megapixel count or other technical factor, it will be interesting to see how a dual-system shooter copes with avoiding mode errors: Canon’s button is here, but Nikon puts a totally different button in the same place. How easy is it to flip the brain into Canon Mode or Nikon Mode?

Canon EOS 30D, Canon EF-S 10-22mm @ 13mm
1/1250 @ f/8, ISO 200

For my photography, the Canon EOS 30D has been an absolutely stellar performer. I’ve lost the precise count, but I think it now has around 70,000 shutter actuations on the clock. It has almost never let me down. I don’t have a pressing need to go to another manufacturer.

Sure, I would love to pick up Duncan’s used 1D MkII, but I keep coming back to my Cameras-as-Computers question: “is it better to update your prosumer model every time it’s upgraded, or to buy a high end model and keep it for years?”. I’m almost at the point where I can justify upgrading my 30D to the newly-released 50D, but I’m in no hurry. In any case, the release of the iPhone SDK this year destroyed any spare time I had over the summer to do photography.

FNDA is now “Former” NDA

Feels great to have a second thing to thank Apple for in the same week. Yesterday, Apple lifted the Non-Disclosure Agreement on publicly-available iPhone software.

Pre-release Mac OS X Development has always been under NDA, but once an OS was on sale, we were free to talk about it. I can’t blog about Snow Leopard, but I can post all the Leopard code I want. Until yesterday, that wasn’t the case with the iPhone.

If you want an example of how important this is, I haven’t been to my Mac since the announcement and I already learned something I didn’t know via Twitter. I can’t wait to learn a lot more.

I’m now convinced that the remaining big problem - the lack of pre-approval for apps - will be resolved in time. I came up with another way to make progress on this issue:

Pre-approval only matters when you’re going to invest significant resources in creating an application. If your app is going to take you a week to make, you won’t lose much if it’s rejected. If you’re going to spend months or hire people to build an iPhone app, you stand to lose a lot if you can’t sell it.

What if Apple provided four “App Store Approval Incidents” with each ADC Premier account, and ADC Select members could buy one for, say, $350? As I see it, the costs of either represent little more than a trivial due-diligence fee on the investment you are about to make in iPhone development.

Anyway, thanks to Apple for the moves on the NDA. I’m looking to the future of iPhone development with immeasurably more optimism now.

Git: Branching and Fast-forward Merging

I made these videos late last night, mostly on a whim and to see if people found them useful. I’ve been digging deeply into Git over the past couple of weeks and, if I do anything well, I think one thing I make a decent job of is to go deep on a subject and then blog about it.

I learn in a very top-down way - I’m not initially detail-oriented. First I want to know the big picture, the overarching ideas and the big levers that you pull with all your might. I prefer to understand the screws and springs after I’ve grasped the big things. These are the result of my screws-and-springs research.

Disclaimer: I’m still a relative git newbie, although I have been using it for serious work since March, so you should verify what I say before going to town on your repositories. Also, I am doing my best to ‘umm’ and ‘aah’ less on these
Branching

This video explains the interaction between commits, branches and branch heads.

Fast-forward Merging

This video graphically explains what the git “fast-forward merge” feature does. This is a special-case operation in which you branch off a commit, work only on the new branch and then merge back. Compare this video to the one above in which NewFeature was branched and work continued in parallel on both master and NewFeature.

This video contains a slight error around the 2:00 mark that is noted in the Viddler timeline.

I would appreciate feedback on whether you find these useful.

App Store Reviews: credit where it’s due

Great move by Apple today. One thing that has always bugged me about reviews of higher-priced applications such as the love of my life, OmniFocus, (and to a lesser extent, Exposure Premium) has been that some people tend to abuse the App Store’s review system to protest the price.

For any software of any appreciable complexity, the sine qua non of a review of that software is that the reviewer has at least been in possession of a copy of the software. Simply complaining that you won’t pay the price of an application is fine, but in no sense whatsoever is that a review of the software. If you have purchased the app, and still don’t think it represents value then, by all means, say that in a review. Don’t hijack the purpose of a review to push your ideas about software pricing.

The App Store has always had enough data to enforce this requirement, since it knows which accounts have downloaded each title. Until now, that hasn’t been enforced. I and other developers have requested that it should be, in order to keep the review system as a venue for actual reviews that are worthy of the name.

Thank you, Apple.

Git committing workflow with BBEdit

Now that I’m committed to using Git, I’m trying to streamline (and improve) my workflow a bit. Here’s what I’m doing in a git commit right now.

I use the following script to open up individual diffs of each changed file in BBEdit:

#!/bin/sh

# Open each diff in a separate BBEdit buffer, inside one window
for f in `/usr/local/bin/git ls-files \
	-d -m -o --exclude-per-directory=.gitignore`; do

	/usr/local/bin/git diff $f | /usr/bin/bbedit --front-window

done

# Open the list of changed files in BBEdit
/usr/local/bin/git ls-files -d -m -o -t --exclude-per-directory=.gitignore \
	| /usr/bin/bbedit

This gets me two BBEdit windows. One window contains several buffers, each with a diff of a file that changed. The second window contains a Subversion-style list of changed file paths:

C ExposureTouch/Classes/EXLocalController.m
C ExposureTouch/Classes/ExposureAppDelegate.m

I then apply a BBEdit Text Factory to this window, which converts these lines into:

== CHANGED: ExposureTouch/Classes/EXLocalController.m ==

Comment: <# Change Comment #>

== CHANGED: ExposureTouch/Classes/ExposureAppDelegate.m ==

Comment: <# Change Comment #>

The <# Change Comment #> things are BBEdit placeholders. Incidentally, the manual is a little vague on how you create your own placeholders in BBEdit. The format is <##> and you can insert them by any text manipulation (from the manual, I had initially thought that you could only add them by inserting a clipping).

Having done this, I can tab through the placeholders (thanks, BBEdit 9!) and write a comment about each changed file while looking at the individual diffs in a second window.

At the top of the file, I write a single line that summarises the changes in the commit. I try to write this in the style of a user-visible release note, which I later extract in another script to produce the release notes (for example).

Usually, I then do git commit -a and paste my completed change form into the top of the commit message editor and I’m done.

The release note generator is a simple script around git log:

#!/bin/sh
/usr/local/bin/git log --pretty=format:"- %s (%h, %ci)" $1..

I invoke this by naming the last release tag: gitnotes Exposure-1.0.3. This gives me the first line of every commit message since the tag Exposure-1.0.3 was created.

It’s not perfect (particularly when you cherry-pick) but it generally does the job on a single branch. Usually the notes need some massaging to make total sense to users, but I much prefer doing it this way to maintaining a separate file of changes. I’m also working on ways to tag commits as user-visible or internal, so that I could mark internal changes as “not for release” and exclude them in the gitnotes script.

App Store: I’m out.

I will never write another iPhone application for the App Store as currently constituted*.

Writing software is a serious investment of time and energy. It also carries the opportunity cost of the other things you could have built. We live in a capitalist economy. Under capitalism, profit is the reward for economic risk. Without a reasonable expectation of profit, the sensible business-person will not invest. Without investment and risk-taking, there is no innovation.

Apple’s current practice of rejecting certain applications at the final hurdle - submission to the App Store - is disastrous for investor confidence. Developers are investing time and resources in the App Store marketplace and, if developers aren’t confident, they won’t invest in it. If developers - and serious developers at that - don’t invest, what’s the point?

You have to wonder if Apple wants the App Store to be a museum of poorly-designed nibware written by dilettante Mac OS X/iPhone OS switcher-developers and hobbyist students. That’s what will happen if companies who intend to invest serious resources in bringing an original idea to the App Store are denied a reasonable level of confidence in their expectation of profit.

Some people might have given Apple a pass when they rejected the e-flatulence applications iFartz and Pull My Finger. Personally, I didn’t. Half of my reasoning is that selecting for taste is the first step to censoring for business advantage. The other half of it is that, well, who can’t think of a million uses for a TCP/IP-enabled whoopee cushion?

That said, Apple is now selecting for anti-competitive reasons. It came to light today that an app that will deliver a capability I really, really want was rejected by Apple because it replaces a feature in Apple’s own software. The app is called Podcaster and it would allow one to update podcasts directly on the device over wifi. I sync my iPhone to my Mac Pro - should I have to go home to put a new episode on my iPhone? I’d buy that app in a heartbeat.

Do you want a store in which every app in the “Productivity” category is a to-do list manager? That’s exactly what you’re going to get because, without some a priori assurance that your idea will be accepted, the only way to know what Apple likes and dislikes is to look at what’s already on the store. Clearly Apple can’t get themselves enough of those ticky boxes, so why not do “your take” on a list of text cells and checkmarks? Much safer bet than inventing something new.

I said that I wouldn’t write another iPhone app for the App Store as currently constituted. What would make me change my mind? Here are a few ideas:

1. Publish clear and unambiguous rules for what will be accepted and what will not. I don’t even care if this is a long and detailed document, but it needs to be The Rulebook from which both sides play.
2. Defend those rules against external pressure from carriers (NetShare) or the media (Slasher).
3. Design a process by which developers can be given official pre-approval of their idea. Possibly a general nod, possibly conditional on certain criteria. If developers are going to go and borrow money to hire talent or build out services, they need more confidence than “call us when you’re done”.
4. Loudly and conspicuously hire an App Store Evangelist. Preferably someone with an already high profile who does not already work for Apple. In fact, it might even be best if this person was not paid by Apple but an independent developer to whom Apple would give deep access to work with the App Store team. This is an investor trust issue.
5. When controversies arise, let the Evangelist get into the conversation and lay out a clear rationale for Apple’s actions.
6. Send the App Store Evangelist to every corner of the earth where iPhone developers gather. Unshackle them from the usual Apple constraints on public speaking. Get them on podcasts. For better or for worse, Apple has to start talking to the iPhone developer community.

[* Update: Quick clarification. "I'm out" doesn't mean I'm pulling Exposure from the store. All it means is I'm not going to invest time and money into new ideas for the iPhone until this mess is resolved. Sorry for any confusion.]

C4[2] Brain-dump

Writing this at a table in Heathrow Terminal 5, halfway home to Scotland after spending the weekend at C4[2]. I’ll try and pull out my highlights.

The crowd is a feature at C4. I don’t want to insult those not in Chicago by saying that “everyone who is anyone was there”, but everyone who was there was someone well worth talking to. I had a number of incredible conversations which variously inspired me, gave me new insight into problems and just outright made me glad to know these people. I won’t embarrass anyone, but there was a time when certain people were heroes to me and to have those same people complimenting me on my work is a source of great satisfaction.

I thought C4 was incredibly reflective. If you imagine it as a smaller WWDC, it’s really nothing like that. The amount of code shown on-screen is really quite small, and the conversation is really about the art, craft, business, science and lifestyle of Mac development.

C4 paid for itself on the first night with Richard Hipp’s talk on SQLite. Besides being one of the nicest people I’ve ever met, Richard blew through all my concerns, questions and confusions with the SQLite C API in the course of his talk. The talk was so clear that instead of bugging him with questions over Sunday brunch, we had an amusing discussion about Cold War-era operations on Scottish fishing vessels between here and the Baltic sea.

I really appreciated Rich Siegel’s talk on taking the long view of the business of Mac development. Two words from his talk continue to stick in my mind: engineering discipline. It’s so easy not to have this when you’re a one-man shop, but I will continue to look for ways to increase the level of discipline I bring to my coding. I got burned early in my career with the Xjournal project by putting too much in. I’m vastly more conservative with features than I have ever been, and I’ll probably get worse with age.

Another topic, not on the schedule this year, but should be next year is QA and support. I had a great conversation with Rich and Liz Marley (Omni’s QA Queen) about the subject. It’s another thing that’s easy not to do as a one-man operation, but we need methodologies that scale down.

There was talk, as ever, about marketing and pricing. I feel, though, that the indie community is starting to come to a rough consensus on this: don’t underprice; don’t listen to the whiners but, if you don’t have whiners, you’re leaving money on the table. I’m paraphrasing the theme, of course!

Rich commented to me that the discussion is changing as people’s businesses and products mature. Many of us are on version 2 or 3 of our products and, of course, are moving to a new platform with iPhone. It’s no longer so much about how to start and a lot more about how to start to scale the business up from one person. A huge part of that conversation is about how to handle support.

From my own perspective, I’ve found that people are no longer asking me the “how do I get started?” questions quite so often. The most common question I get asked is “how do you find the time to do it?”. That might make a good title for a talk…..

OmniFocus: My Approach

I teach Computing to children and in education there are many Computing terms that we rarely use outside the classroom. For example, we say IT in the real world but ICT (Information and Communications Technology) in school. One term that I think is useful but little used outside of the classroom is General Purpose Package. A GPP is any application which is of little use or interest until you input your own information, such as Pages or Numbers. The classic counterexample is a game, to which you provide very little data and are generally strongly constrained in your usage patterns.

I think there’s an intimidating middle ground, though, between a truly general purpose application like Keynote or Excel and a purely specific purpose app like Photobooth, Google Earth or Skype. These applications today look a lot like structured databases. There are many exmaples - iTunes, iPhoto, Aperture, Lightroom, Delicious Library, Evernote, Mail - and I think there is a lot of anxiety amongst users about how to approach these applications.

Some of the applications I mentioned are easier to approach than others, due to the greater amount of direction (or reduced flexibility) they give to the user’s actions. I suggest to you that iPhoto provides more direction to the user than Aperture and is therefore easier for most people to approach.

These structured-database applications also come with a relatively high cost if you get your approach wrong early on. If you’ve been shooting heavily for two years in Aperture and then realise that it would have been much better to use time-based organisation, rather than project based, the cost to change is almost too high to contemplate. I still get grateful emails about my article from January “Organising Projects and Folders in Aperture”.

People need real-world walkthroughs of these applications to provide them some assurance that they’re not (a) crazy, (b) going in totally the wrong direction or (c) missing some game-changing insight into the way the app works.

Get Focused

And so to OmniFocus. I’ve always felt slightly proprietorial towards OmniFocus, with only the very slightest fragment of justification. Many moons ago, I wrote some AppleScripts to mess OmniOutliner around with GTD-like structures. This partly inspired Ethan Schoonover to create the legendary Kinkless GTD system of scripts, and Kinkless GTD led directly to OmniFocus.

I’ve been using OmniFocus on and off since it first came out as an alpha-test version some time last year but, in the past few months, I’ve really come to depend on it.

I’ve always appreciated the clean design of the application, but I do think that it’s necessary to understand some of the GTD methodology in order to appreciate why OmniFocus is so designed. Andy Ihnatko, in particular, has made some strong criticisms of the application over time and I think he generally makes a fair point. I would link, but Andy’s in the midst of server transition right now. Google it up, or read his review of OmniFocus/iPhone in the App Store (why can’t you select and copy the text of App Store reviews?).

That said, I look at OmniFocus not as a “to-do application” but as a “GTD application”. If you don’t have any grounding in GTD, I agree that OmniFocus will appear complex and somewhat strange. If you do know GTD, however, and you want to apply it in an orthodox fashion, I don’t see many applications that match OmniFocus for quality and polish.

My Approach

Uploaded with plasq’s Skitch!

I emphasise that this is just one of many possible ways to use OmniFocus and I wouldn’t suggest that those who use it differently are in any way wrong. It’s what works for you.

Beyond the standard GTD structures of Projects, Actions and Contexts, there are two features in OmniFocus that are critical to the way I use it: Perspectives and Start Dates.

Grand Perspective

I use five perspectives: Review, Strategic, Tactical, Urgent and Flagged. I’ll just list their exact settings and then explain them:

Review: I use this for weekly review. It shows everything except completed and dropped projects, grouped by their next review date. More on this later, but it’s important to note that this is where the not-yet-due projects will appear.

Strategic: I find this useful in mini-reviews that I might do every day or so. It’s like Review, except that the main filter is “Active” instead of “Remaining” so it only shows things that are current.

Tactical: This is the workday perspective: showing actions in contexts, sorted by due date. I don’t use due dates for everything, but I find it helpful in crunch times.

Urgent: This filters everything out except those actions which have due dates and are due soon. Useful near the end of the week, to make sure I’ve nailed everything that needs to be nailed before I head out the door.

Flagged: I use flags as an ad-hoc project or context, and this perspective pulls those out to the front and centre.

Timing Is Everything

The other feature in OmniFocus that I totally depend on is the Start Date field. I set it on projects that I don’t want to deal with immediately and, when the time is just right, those projects will become active and I’ll see them.

Here’s an example: I’m leaving tomorrow for C4. After I booked the hotel and flight back in July, I added some more items to the C4 project: “change currency”, “pack bags”, “check in online” and so on. Next, I set the project to have a Start Date of 9am, September 1st, since I knew I didn’t need to pack my bag until a day or two ahead. For the whole of August, I didn’t need to see any C4 actions at all.

You could achieve the same thing by putting the project on hold, but that has the disadvantage that you have to remember to un-pause the project again when the time is right. With Start Dates, it’s done for you. More than once, I’ve put a project on hold, forgotten it was even in OmniFocus (since it was usually hidden by my perspectives) and created a duplicate.

Take It With You

The killer feature of OmniFocus is OmniFocus for iPhone. I’ve found the syncing to be robust, if a little slower than I would like (although this script has helped a lot). OmniFocus for iPhone doesn’t support custom Perspectives, and I miss that. It does have a couple of built-in views for “Due Soon” and “Flagged”, which are a decent replacement for my “Urgent” and “Flagged” perspectives.

What I love about OmniFocus syncing, and one of the reasons I prefer it over Things, is that you can sync many clients to one database. With Things on the desktop and phone, it’s more of a pairing arrangement where you have the master database on your Mac and sync to your phone. I have a laptop, a desktop (with two boot partitions) and an iPhone. OmniFocus keeps all four in sync perfectly and I’m willing to wait a few more seconds for that.

Hear my MacVoice

I recently recorded an episode of MacVoice with Chuck Joiner in which we talked about Exposure and general iPhone design/development.

If you were wondering about the story behind why Exposure can’t upload and my current thinking on that, you’ll want to grab this episode.

Here’s the link Fraser Speirs of Connected Flow on Exposure for the iPhone, Uploading and the future of the App Store.

Where The Numbers Come From

A few people emailed to ask how I knew how many users Exposure has. The numbers come from Flickr.

When you use Flickr’s API, your app is assigned an API key and every request has to include that key. Flickr provides certain stats to developers about the activity that’s happening for each key and one of these stats is the number of accounts that have authorised that particular API Key to access their account.

I don’t know what the breakdown of free vs. paid versions of Exposure is, since both versions use the same API Key.