rentzsch.tumblr.com

My Mother Tries an iPhone

Sun, 17 Mar 2013 15:53:29 -0500

My mother tried an iPhone for the first time. Here’s my Hallway Usability Testing report.

Slide to Unlock

Easy Start. Knew to take her finger, touch the “slider” and move it to the right all the way. The instructional text and appearance of a groove that affords sliding the slider along it win the day.

Problem occurred during release. She’s being very deliberate with her actions, which caused an issue here and later. She’s thinking about what she’s seeing and her next action, which causes a delay: she didn’t just quickly lift her finger from the screen to complete the unlock.

Instead, she unintentionally let her finger slide to the left a bit while waiting for the iPhone to do something (she’s used to computers also taking a while to do something, so it may not just be her being tentative but also her waiting to see if the machine needs to “catch up” to her actions” (a sadly common occurrence)).

When nothing happened, she lifted her finger from the screen only to watch the slider spring back to its original virtual resting position.

She tried again, only more slowly since the machine wasn’t operating as expected, so perhaps she has to do things even more slowly. Same result.

I hinted at her to try lifting her finger faster, and then she was able to succeed.

Suggestion: Slide to Unlock would benefit by taking into account time spent with the finger down on the unlock position and/or additional slop as to what’s considered a valid unlock request.

Initial Screen

Seemed fine enough. No problem thinking of icons as touchable buttons. No expressed puzzlement of the two tiers of icons on the top and another set of icons along the bottom (the dock).

I took the liberty of moving all the apps I knew she wouldn’t use to the second page and even the Utility apps (Voice Memos, Calculator, etc) out of their confusing group and onto the normal page.

She mentioned the Clock is wrong. She thought it odd since the other, textual clocks were correct (the first on the Slide to Unlock screen and the uppermost status bar clock). The Calendar app’s date is correct, so she has no reason to believe that the Clock’s icon just happens to be static. I never noticed this inconsistency myself.

Suggestion: while I’d probably be annoyed at it (especially with the second hand), the Clock app’s icon should be live and accurate.

In the same vein, she noted the Weather app must be showing the inside temperature (72°) since it’s currently in the mid-30°s outside when she was looking at it.

Suggestion: the Weather app should display the current location’s weather/temperature or a new, different static icon that’s clear isn’t trying to represent current conditions.

I told her to press the Mail icon. Again she got snagged by her deliberate movements, and accidentally triggered wiggle (icon rearrangement) mode. Apps wouldn’t launch and she didn’t know how to fix it.

Suggestion: wiggle mode is such a bad idea. Better to have a dedicated app to arrange Springboard pages/groups.

Safari

Like many (most?) people, she doesn’t understand URLs, so I typed in Google from her and then puzzled how to navigate to Google News (google.com now hides it under their burger button). She used Google News on her Mac, so I wanted to show her the same information is available on the iPhone. I wanted her to see something that offered the safety of familiarity.

She was immediately thwarted when tapping a headline link opened the page in a new tab. Her Google News page was pushed away and the Los Angeles Times’ page came frontmost. Because it was a new page, the back button wasn’t enabled. She was at a loss at how to go back, not noticing the nondescript tabs button that held the key to her return.

Suggestion: Safari should initially operate in a simpler single-page-at-a-time mode, which is how nonadvanced users use the web or do a better job of visually indicating and managing multiple tabs. Granted, this is a hard design problem.

Miscellaneous

When she opened the Weather app, she wondered whether it was showing the upcoming weather or historical weather.

I showed her Google Maps and had her type in a old address. She informed me that her fingers were too large to possibly hit the little keyboard. I assured her to try anyway, and after wrestling with finger placement to compensate for her nails (see below) she was able to input an address and switch back to the alphabetic keyboard without prompting (I prompted her on how to switch to the numeric keyboard).

I sent her a link via iMessage to look at a page on Amazon. The link was long, and wrapped extensively. For some reason tapping anywhere on the link except the first line didn’t work to open the page. This bug reduced her confidence that blue underlined text is universally tappable on iPhones.

Physicality

I told her a few times to press the home button. She was confused as to which button it was. I considered calling it the Rounded Rectangle Button, but that seemed excessively wordy. I wish Apple would have used a house icon (something like ⌂) instead of the current quite-rounded rectangle. The downside is a house icon suggests an orientation, and could be annoying if your primary use is in a different orientation.

She tried to use her fingernails to touch things, which are long enough that they do a good job of keeping her fingertips away from being detected by the capacitive touch screen. Here a resistive touch screen actually has an edge (not that I’d ever go back).

Semantic Version Branches for Submodules

Sat, 16 Mar 2013 22:03:23 -0500

When you create a new git repo, you get a master branch for free. That’s fine in many cases.

Lately I’ve been using a different branching system for code that’s meant to be used as a library (perchance a git submodule or a subtree).

Here’s how it works:

Name the branch based on the code’s Semantic Version. Examples:
- Brand-new code base that’s still being written: name the branch semver-0.x.
  
  The x in the branch name denotes a variable, so this branch could house v0.0, v0.1, v0.1.42 and so forth.
  
  You probably could get away with a simple v0.x or even 0.x, but I think the explicitness is helpful indicator for humans and paves the way for machine recognition of semantic branch names.
- First version of the code base with a stable public API: semver-1.x.
- Upcoming not-yet-stable second version of code base: semver-2.x-beta
  
  Initially I went with semver-2.x-unstable, but I found myself confused when I came back to the project later. Does that mean the code is unstable and crashy? Or just the API is subject to change? Both?
  
  Whereas with beta it was instantly clear to me this branch holds the work-in-progress for version 2.
- Second version of the code base with a stable public API: semver-2.x.
There’s no master branch.

“master” is too generic a concept and it’s an attractive nuisance for submodules. Too often I look at a project, see lots of branches and no way to immediately tell what’s going on, so I reach for the familiar: the master branch.

Learning from my own behavior, I see it’s important to take away that crutch and force perspective library consumers to understand the project’s current state and semver branch structure. Fortunately GitHub makes it easy to select a non-master default branch, so it should be mostly transparent to your users.

Even better, switching the default branch gives the library’s author the ability to easy start migrating new users to newer versions of your library (while retaining backwards compatibility with your existing users). For example, update your default branch from semver-1.x to semver-2.x.

It’s best if you start off immediately using semver branching, but it’s straightforward to migrate to them even after you publicly release your library using the old fuddy-duddy master branch model. In that case you’ll have to weigh the conceptual clarity and usability advantages of deleting the master branch against breaking the assumed-master branch of your clients.

NS: Poor Man's Namespacing for Objective-C

Thu, 17 Jan 2013 19:43:17 -0600

Objective-C unfortunately lacks namespaces. This leads to both compile-time woes and runtime woes. You may have been witness to this runtime warning:

Class SUUpdater is implemented in both MyApp.app/Contents/Frameworks/Sparke and MyAppPlugin. One of the two will be used. Which one is undefined.

While Kyle Sluder has been leading the charge towards getting the feature as a first-class citizen in Objective-C, I’ve been successfully using a nine-line preprocessor hack for a few years now that effectively works-around the problem. I call it NS:

#ifndef NS
    #ifdef NS_NAMESPACE
        #define JRNS_CONCAT_TOKENS(a,b) a##_##b
        #define JRNS_EVALUATE(a,b) JRNS_CONCAT_TOKENS(a,b)
        #define NS(original_name) JRNS_EVALUATE(NS_NAMESPACE, original_name)
    #else
        #define NS(original_name) original_name
    #endif
#endif

Instead of writing your classes like so:

@interface Person : NSObject
@property(strong) NSString *name;
@end

Write it like so:

@interface NS(Person) : NSObject
@property(strong) NSString *name;
@end
#define Person NS(Person)

Then use the class like you normally would:

Person *p = [Person new];

Now your code supports compile-time prefix insertion. If you don’t do anything else, your classes will remain unprefixed.

However, you can now prefix all participating classes with one easy flick of a preprocessor definition:

-D NS_NAMESPACE=MyFramework

That turns the code above into:

MyFramework_Person *p = [MyFramework_Person new];

With judicious targeting of your -D NS_NAMESPACE= use, this should enable you to work-around class collisions at both compile-time and runtime.

P. S. I recognize it’s probably a bad idea for me to squat on something as Apple-generic as NS, but I don’t care.

Update: Uli Kusterer points out this hack doesn’t cover XIBs, since they reference classes by name and avoid the preprocessor’s reach.

I’ve only used this technique with pure code libraries, so that limitation hasn’t bitten me.

Nginx Homebrew Support

Mon, 07 Jan 2013 12:09:16 -0600

If you run nginx on OS X via Homebrew, you’ll probably be interested in my nginx-homebrew-support.

enum => NSString

Sat, 08 Dec 2012 18:05:56 -0600

I wish it were possible in C to access an enum’s name in string form given a type and its integer value. It’s great for logging/debugging.

Until that day arrives, here’s a small Ruby script which automates the process of vending an NSString given typed enum value:

def NSStringFromEnum(input)
  inputArray = input.lines.collect
  typeNameLine = inputArray[-1]
  typeName = typeNameLine.match(/(\w+);/)[1]

  output = "NSString* NSStringFrom#{typeName}(#{typeName} value) {\n    switch (value) {\n";

  constantLines = inputArray[1..-2]
  constantLines.each {|constantLine|
    constantName = constantLine.match(/(\w+)/)[1]
    output += "        case #{constantName}:\n";
    output += "            return @\"#{constantName}\";\n";
    output += "            break;\n";
  }
  output += "        default:\n";
  output += "            return [NSString stringWithFormat:@\"<unknown #{typeName}: %d>\", value];\n";

  output + "    }\n}"
end

Example input:

typedef enum {
    JRStream_Disconnected,
    JRStream_Connecting,
    JRStream_Connected,
    JRStream_Disconnecting
}   JRStreamState;

Example output:

NSString* NSStringFromJRStreamState(JRStreamState value) {
    switch (value) {
        case JRStream_Disconnected:
            return @"JRStream_Disconnected";
            break;
        case JRStream_Connecting:
            return @"JRStream_Connecting";
            break;
        case JRStream_Connected:
            return @"JRStream_Connected";
            break;
        case JRStream_Disconnecting:
            return @"JRStream_Disconnecting";
            break;
        default:
            return [NSString stringWithFormat:@"<unknown JRStreamState: %d>", value];
    }
}

Update: Guess I should mention how I use it. I put this script into an Automator Service. Apparently you can also use TextExpander and probably Typinator as well. Finally, Benedict Cohen wrote a C macro version that looks promising.

Update: I extended Benedict Cohen’s excellent work and I’m pleased to offer JREnum.

Xcode Comment Alignment

Wed, 28 Nov 2012 16:31:35 -0600

I finally put my finger on something that’s been bugging me about Xcode’s comment indentation since forever.

For short comments, I typically use //:

// This is a
// short comment.

That’s fine unless comments grow long:

// Lengthy essay
// about the high-level
// overview of the code
// perhaps with parameter-level
// machine-readable API documentation.

Having to prefix each of my lines with an // gets on my nerves, so I switch to classic C comment style:

/*
Lengthy essay
about the high-level
overview of the code
perhaps with parameter-level
machine-readable API documentation.
*/

However, Xcode wants to format it like this:

/*
 Lengthy essay
 about the high-level
 overview of the code
 perhaps with parameter-level
 machine-readable API documentation.
 */

Note each line after the initial comment opening is prefixed by one space.

I think this is because Xcode wants to help you line up the asterisks, like so:

/*
 * Lengthy essay
 * about the high-level
 * overview of the code
 * perhaps with parameter-level
 * machine-readable API documentation.
 */

However the entire reason I use classic C comments is when I don’t want to have to bother with per-line prefixes.

For now I just manually delete the extraneous spaces, but I wish I could easily suppress this behavior.

Functional Cocoa Collections

Sun, 25 Nov 2012 21:30:33 -0600

Tony Arnold / @tonyarnold:

Alrighty guys: best map/reduce/filter categories for NSArray/NSSet/etc — what do you have/use? /cc @atnan @orj @rob_rix

I made a brief aside about this in the latest Edge Cases episode about blocks, so Tony’s question is topical. Here’s the ones I know about, roughly in order of my first-glace preference:

I haven’t used any of these in anger yet (but have been happy with Underscore.js).

mogenerator 1.27

Wed, 14 Nov 2012 12:13:56 -0600

What’s New:

[NEW] You can now pass .xcdatamodeld paths to mogenerator. mogenerator will look inside the directory, read its hidden .xccurrentversion file and use the “current” .xcdatamodel file. (Alexander Zats)
[NEW] Replaced mogenerator’s previous testing system (the test mule) with a new Rakefile-based system that eases building & testing from the current source tree and tests both MRC and ARC. (rentzsch)
[NEW] Property declarations generated from attributes can now be qualified as readonly by adding a mogenerator.readonly to an attribute’s userinfo. (crispinb)
[NEW] --configuration option that limits generation to the specified configuration. (Sixten Otto)
[NEW] --base-class-import option for fine-grained control of base class import statements. (David Aspinall)
[CHANGE] Optimized keyPathsForValuesAffectingValueForKey: generated code (returns after first match). (Sean M)
[CHANGE] Add default private class extension to human source template. (Jonas Schnelli)
[FIX] Align generated code’s pointer asterisks more consistently. (Tony Arnold)
[FIX] Missing import when using mogenerator.customBaseClass entity userinfo key. (Thomas Guthrie)
[FIX] Handle case in generated fetch request wrapper machine code when predicate variables are repeated. (Sergei Winitzki)
[FIX] Explicitly set mogenerator project’s deployment target to 10.6 to avoid segfaulting on 10.8 for some reason. issue 121 (reported by Sixten Otto, diagnosed by Florian Bürger)
[FIX] Cast to unsigned in machine source to avoid clang format string warning. (rentzsch)
[FIX] Don’t attempt to report errors through -[NSApp reportError:] in generated machine source unless targeting AppKit. (rentzsch)
[WORKAROUND] Recent versions of Xcode use an empty string to mark entities that do not have a custom subclass. (Matthias Bauch)
[CHANGE] make_installer.command: assume PackageMaker now lives in /Applications/Utilities. (rentzsch)

Simple Code

Tue, 13 Nov 2012 15:13:13 -0600

damien katz / @damienkatz:

Invented a design pattern I call “simple code”. When I need the code to do something new I “modify it”.

I’ve wasted too much brain power over the years over-engineering software, bracing my designs for scenarios that fail to ever materialize.

My suggestion, at least for the first cut: do the simplest thing that could possibly work.

If you’re like me, that engages your intellect towards simple solutions instead of over-engineering against invisible foes.

OS X 10.8 Apple Software RAID

Tue, 30 Oct 2012 17:24:24 -0500

After my poor experience with Software RAID on Mac OS X 10.7.3, I’m pleased to report that software RAID on OS X 10.8 seems improved over 10.7.

Enabling Software RAID does have some tradeoffs:

You lose OS X’s Recovery Partition. Internet Recovery should still work and you could always build your own Recovery Disk.
FileVault isn’t supported.

For my server purposes, I don’t care about either of these limitations, so I’m happy that OS X Software RAID is realistic option again (the “Repair Disk” button actually works).

Here’s how I set up my new 2x1TB Mac mini Server:

SuperDuper the Mini’s boot drive (“Server HD”) onto an external drive.
Boot from the external drive.
Repartition both drives into three slices each: 50GB Boot, 50GB Boot Backup and the rest Data.
Create three new RAID 1 (Mirroring) sets encompassing those slices, respectively.
SuperDuper the external drive back onto the Boot RAID volume and boot off it.

Here’s my set-up as it appears in Disk Utility:

This set-up enables me to perform system software updates with a bootable backup safety-net in place.

I’m backing up that Data partition offsite, so I’m not backing it up locally on the Mini itself (I’m just SuperDuper’ing the Boot volume to the Boot Backup volume nightly).

My Amazon Ebook Insurance Policy

Mon, 22 Oct 2012 15:53:57 -0500

When iTunes Music Store first came out I studied it and decided to buy music off it. Not because I trusted Apple, but because I had a spare Mac that I could use as a DRM lifeboat.

I copied my purchases as I made them to the old Mac. The Mac was also disconnected from the Internet after its initial authorization. Finally, I had software in place to extract the audio I purchased even if Apple pulled the DRM football from me just as I tried to kick it.

Fortunately Apple’s iTMS DRM dog never barked. But after today’s Amazon Ebook controversy I decided it’s time to share my similar Amazon Ebook Insurance Policy:

Have the Kindle’s network turned off most of the time. I do this to conserve battery on my Kindle 3, but it has the nice side-effect that Amazon can’t remotely delete content at its whim.
Buy Chronosync and set it up to copy purchased Ebooks to my Mac whenever I connect+charge my Kindle. That way I can recover even from an unexpected remote wipe from Amazon.
Use (and hopefully donate to) Calibre and then install plugins to strip Amazon’s DRM from your purchased Ebook files. Calibre can then export your .azw and .azw1 files to unencumbered .mobi and .epub formats.

Update: Zachary West offers specific steps on converting Amazon to ePub using Calibre.

Xcode 4 Splits

Fri, 19 Oct 2012 16:09:32 -0500

One of the features Apple took away in Xcode 4 was splits.

rentzsch / @rentzsch:

predicted headline feature of Xcode 5: splits

But it turns out you can clumsily emulate them with Xcode 4’s Assistant Editors:

kongtomorrow / @kongtomorrow:

@rentzsch like text splits? already there. View > Assistant Editor > Add Assistant Editor (and various shortcuts)

rentzsch / @rentzsch:

@kongtomorrow that only works when you have an assistant editor showing. Very rarely that I do. Need it for standard editor

Troy Gaul / @tgaul:

@rentzsch @kongtomorrow You can open the same file in the assistant editor and then stack the editors vertically in your window.

kongtomorrow / @kongtomorrow:

@tgaul @rentzsch ooh, thanks, thought that was there somewhere. View > Assistant Editor > All Editors Stacked Vertically

rentzsch / @rentzsch:

@kongtomorrow @tgaul ah that’s clumsy, but it will work when I’m desperate. Thanks!

Wherein I Write Apple's Technote About OpenSSL on OS X For Them

Tue, 16 Oct 2012 01:06:31 -0500

Technical Note TNNaN: OpenSSL on OS X

Long story short: we screwed up when we included OpenSSL (libcrypto) in OS X in the first place.

(We learned our lesson and didn’t repeat the mistake with iOS.)

Now there’s some transitionin’ to do.

Recommendations

New Code Should Use SecTransform. SecTransform is cool: it’s high-level, rather declarative, fast and even leverages GCD. It solves OpenSSL’s issues described below in the Backgrounder section.
Code That Uses OpenSSL Just for Hashing Should Switch to CommonCrypto. CommonCrypto provides a thin OpenSSL compatibility shim for common cryptographic message digests. It’s called COMMON_DIGEST_FOR_OPENSSL and lives in CommonDigest.h.
Apps That Need OpenSSL Should Include Their Own Copy. You should stop using the system’s supplied libcrypto.dylib, build your own and link it into your app.

We know that’s a pain, but this project should help you out.

Add -isystem "$(SRCROOT)/openssl-1.0.1c/include" to OTHER_C_FLAGS to pick up your project’s local OpenSSL headers instead of the system’s headers (which are outdated and throb with deprecation attributes).

Backgrounder

The crux of the problem is OpenSSL doesn’t offer API compatibility between versions.

We’d love to ship updated versions of OpenSSL, but there’s only two feasible routes, both of which are seriously problematic:

Apps link to /usr/lib/libcrypto.dylib symlink. In theory we should be able to always point that to the latest version of libcrypto.dylib and apps get free security + capability updates.

In practice we’d break shipping apps since the APIs are different. So it’s kinda stuck. (Notice we’re still shipping v0.9.8r when v1.0.1c is the latest.)
Apps link to a specific version of libcrypto. For example: /usr/lib/libcrypto.0.9.8.dylib.

Now your app doesn’t get security + capability updates for free. When there’s a security hole, it’s now our job to backport the fixes in the latest OpenSSL into the old-ass version your app is linked against.

Nobody wins in this case.

Ideally the OpenSSL project would do a better job at API compatibility, but it’s really not in their unixy source-code-oriented worldview. Sure we could get big into the project to try to improve it, but we’d rather put the resources into making OS X rock harder.

Both SecTransform and lowly CommonCrypto offer API compatibility, allowing us to add functionality and fix security problems even in shipping apps, which is awesome for users.

Working Around Apple's Deprecation of OpenSSL

Mon, 15 Oct 2012 19:52:27 -0500

Apple has started deprecating OpenSSL on Mac OS X 10.7 SDK and later. I guess they’d prefer you use SecTransform or something. Unfortunately SecTransform isn’t on iOS yet and even it were, some of us have codebases that aren’t Apple-platform exclusive. Feels kind of like a dick move to me.

Anyway, I continued to use OpenSSL in my code — I just stuck a big fat

#pragma clang diagnostic ignored "-Wdeprecated-declarations"

on the top of my OpenSSL-using source files.

Unfortunately that turns off deprecation warnings for the entire file. I tried downloading OpenSSL (/usr/include/openssl/opensslv.h’s OPENSSL_VERSION_TEXT indicates you want v0.9.8r) and using their header files directly but was stumped:

rentzsch / @rentzsch:

lazytwitter: how do I get Xcode to prefer my local openssl header dir to the SDK’s (that’s littered with with deprecation attributes)?

rentzsch / @rentzsch:

(setting ALWAYS_SEARCH_USER_PATHS, HEADER_SEARCH_PATHS & USER_HEADER_SEARCH_PATHS doesn’t seem to be enough or I’m doing it wrong)

Fortunately Christopher Lloyd answered my query:

Christopher Lloyd / @cjwl:

@rentzsch -isystem <myincludedir> added using other c flags should do it

I just tried it and it works. Thanks again, Christopher!

Update: I take back my “feels kind of like a dick move” statement. There are good reasons for Apple to deprecate OpenSSL, I just wish they wrote a Technote about it. So I wrote one for them as penance. Apologies, Apple peeps.

Lich: simple, general, human-sympathetic binary data format

Thu, 04 Oct 2012 15:46:41 -0500

Lich is my new mostly-human-readable binary data format. Check it out if you like bencode or need a space-efficient JSON.

Apple Maps and OpenStreetMaps

Tue, 02 Oct 2012 21:54:22 -0500

Buzz Andersen / @buzz:

Second vintage tactic I wish Apple used with Maps: align Apple resources (a la WebKit) with a promising open source effort (OpenStreetMaps).

I agree with Buzz here: feels like a missed opportunity for Apple and indeed humanity.

Apple uses OpenStreetMaps in iPhoto for iOS, so it’s not like they never heard of the project. I can only surmise somehow OpenStreetMaps wasn’t a fit (or Apple knew it was about to pour a billion dollars into a project and didn’t want to share the project’s fruits with competitors).

See also: llvm and Facebook’s Open Compute Project.

Edge Cases Podcast

Mon, 18 Jun 2012 12:11:47 -0500

I started a new Apple-developer-related podcast with my friend Andrew Pontious called Edge Cases.

To kick off the show we’re going to catch up with our backlog and post an episode each day this week.

Click here to subscribe to the show.

You can also follow the show on twitter: @edgecasesshow.

Special thanks to Victoria Wang for the website design and coding.

Mac App Store vs Buying Direct

Mon, 04 Jun 2012 14:58:36 -0500

Since the launch of the Mac App Store, a common question potential customers ask developers is “Should I buy your app directly or through the Mac App Store?”

Developers have been remarkably cagey, mostly replying with the non-answer “choose whichever is better for you”.

Fortunately Apple now only accepts sandboxed Mac apps, clarifying the situation: customers should buy Mac apps directly unless there’s a good reason not to.

Here are some reasons why it’s preferable to buy non-sandboxed apps directly from developers:

Better App User Experience: Non-sandboxed apps can auto-navigate the user to correct folders in Open/Save panels, run user-written AppleScripts, control iTunes* and install PDF Services automatically.
More features: Non-sandboxed BBEdit can directly edit files that require administrator privileges, non-sandboxed OmniFocus can automatically determine the selected document in the Finder when creating a clipping. There’s lots more.
Better Data Integrity: Document-based Core Data apps are incompatible with Sandboxing. One work-around is to disable disk-based journaling, increasing the risk of data corruption. It appears sandboxed Core Data Mac apps will need to switch to packages for a long-term solution, changing file formats for no good reason (and packages are less convenient for data sharing than flat files).
More and Faster Updates: Different developers follow different update schedules, but typically direct apps get updated more often and with less latency than Mac App Store apps. Some developers intentionally throttle down their direct update schedule to match Apple’s delays and avoid customer confusion, but that’s the developer’s decision.
Less Risk of Losing Your Software Investments: I bought Divvy via the Mac App Store. Unfortunately Divvy relies on Apple’s Accessibility APIs, which aren’t allowed for sandboxed apps. That means aside from minor bug fixes, I will no longer receive updates for the application I purchased.

Some developers are going out of their way to allow seamless cross-grading from Mac App Store versions of their apps to direct apps, which is commendable and helps alleviate somewhat the situation Apple has created.

Sandboxing is just the latest App Store rule change, I’m sure there’s more to come. All things being equal, it’s safer to buy directly instead of being cut off from your own software based on an arbitrary Apple policy change.
More Money Goes to the Developer: For a $10 application, only $7 goes to the developer when you buy it through the Mac App Store. For a direct purchase, it’s more on the order of $9.

The fact more developers weren’t encouraging customers to buy directly is a testament to how much Mac developers care about User Experience — they’re willing to forego the extra profit of selling direct to make things easier for their customers.

However, as alluded to above, there are downsides to buying directly. Buying through the Mac App Store offers these benefits:

Better Purchasing Experience: Apple probably already has the customer’s credit card on file. No .zip to unpackage and drag into the right place. It Just Works.
Better Maintenance Experience: Buy a new Mac, launch App Store.app and enter your Apple credentials. Ta-da, a list of the apps you purchased ready to reinstall. No trying to remember what apps you previously had installed, who wrote them, what the developer’s website is or what your license key was.
iCloud Access: Apple has decided only Mac App Store apps (and thus now sandboxed apps) can access iCloud. Fortunately this isn’t much of an issue since the smart folks at SmileOnMyMac have already demonstrated a work-around of having a “bridge” Mac App Store application which allows its directly-sold PDFPen to access iCloud as well.
Vetted By Apple: I don’t hold this benefit in very high regard, but it does add a safety net versus downloading and running arbitrary software off the web. For example, I’m looking forward to 10.8’s Gatekeeper as a way of limiting the software my mother downloads and attempts to run on her Mac (though this is apparently possible since 10.6).

The bottom line is that sandboxing has effectively collapsed the ambiguity and customers should now purchase their apps directly instead of through the Mac App Store.

* Update: Originally I wrote here “send Growl notifications”. I was corrected by Growl Project CEO Chris Forsythe that the version of Growl in the Mac App Store appears to now listen on a machine-local network port, which works around sandbox-disallowed Mach messaging.

Apps I Love: git-subtree

Mon, 30 Apr 2012 04:07:59 -0500

My thinking was fuzzy in regards to what’s wrong with git submodules. So I finally opened up an editor window and started typing how I think an Ideal Submodule System should work. I wound up with this:

The subproject is copied into the super-project’s repo. At least a snapshot of it, if not the entire history. It’s a fact of life external resources have a habit of disappearing — this helps makes your project resilient.
git clone foo is enough. None of this git clone --recursive foo or git submodule init && git submodule update business.
Can easily pull subproject updates.
Can easily push subproject updates.
Can easily handle super-project branching.
Super-project’s commits don’t wind up in subproject’s history.
Subproject’s commits don’t wind up in super-project’s history.

Armed with clearer thinking, I reexamined my options and have settled on Avery Pennarun’s git-subtree.

Unfortunately its CLI UX is lacking (you have to specify the subproject’s entire remote repo URL each time you pull or push) and Avery hasn’t accepted pull requests or budged the project for a year. Fortunately Helmo forked Avery’s repo, added .gittrees support and push-all and pull-all subcommands, and generally seems to be keeping on top of pull requests and moving the project forward.

I just started using git-subtree, but so far it’s making my life better than before.

P.S. Here’s a short primer on using git-subtree.

Update: Hmm, I discovered and turned to Helmo’s fork after I got tired of reentering my remote repo URL each time I wanted to push or pull a subtree. Turns out Helmo’s fork is currently unstable — the tests don’t pass and there’s a definite bug in it when adding a repo as a subtree that doesn’t show up until you attempt push it back. So I recommend using Avery’s original repo until it’s fixed.

Update 2: I fixed the bug and tests are passing in my git-subtree fork. git subtree push-all away!

Backup Chrome tabs with JSTalk

Sun, 22 Apr 2012 13:29:43 -0500

Sometimes Chrome has trouble restoring its windows and tabs upon launch (the windows and tabs open, but their content never loads). The worst thing about this bug is that it tends to happen only when I have large number of windows and tabs to restore.

I’ve added the following JSTalk script to my nightly backup routine. It writes out the names and URLs of all open tabs to a text file:

var chrome = [SBApplication application:'Google Chrome'];
var windows = SBElementArrayToJSArray([chrome windows]);
var output = '';
windows.forEach(function(window){
    var windowName = [window name];
    if (windowName != 'New Tab') {
        var tabs = SBElementArrayToJSArray([window tabs]);

        output += windowName + '\n';
        tabs.forEach(function(tab){
            output += '\t' + [tab title] + '\n';
            output += '\t' + [tab URL] + '\n\n';
        });
    }
});

Date.prototype.getShortWeekdayName = function(){
    return ['Sun','Mon','Tue','Wed','Thu','Fri','Sat'][this.getDay()];
};
var tabsBackupFileName = 'tabs_' + (new Date()).getShortWeekdayName() + '.txt';
var tabsBackupFilePath = [@"~/Documents/backup/browser" stringByExpandingTildeInPath];
tabsBackupFilePath = [tabsBackupFilePath stringByAppendingPathComponent: tabsBackupFileName];

[[NSString stringWithString:output] writeToFile:tabsBackupFilePath atomically:NO encoding:NSUTF8StringEncoding error:nil];

function SBElementArrayToJSArray(sbArray) {
    var sbIdx = 0;
    var sbCount = [sbArray count];
    var result = [];
    for (; sbIdx < sbCount; sbIdx++) {
        result.push([sbArray objectAtIndex:sbIdx]);
    }
    return result;
}

It uses Cocoa’s Scripting Bridge to enable JSTalk to talk to Chrome via its AppleScript interface.