Sign on the Dotted Line

I use Emacs for all my Django/YUI server work, and all that work is stored in Bazaar repositories. Emacs has a great, modular mode for interacting with a variety of version control systems, called VC.

VC can handle pretty much the full range of dealing with files and directories under version control: finding out which files have changed (bzr st), what changed in those files (bzr diff), and committing those changes to the repository (bzr ci). However, for some of our projects, we sign our commit messages with GnuPG. To date, this required running from the command line for these particular projects. I wanted to remain in the flow inside Emacs, but it seemed unable to accommodate this added step.

So, I did some investigating. At first, I thought all I’d need would be gnupg-agent.

    $ sudo apt-get install gnupg-agent

In my ~/.gnupg/gpg.conf, I added (well, uncommented):

    use-agent

In my ~/.gnupg/gpg-agent.conf, I added:

    pinentry-program /usr/bin/pinentry-gtk-2
    default-cache-ttl 86400
    max-cache-ttl 86400

And I start up gpg-agent with every login by adding this line to my ~/.xsession file:

    eval $(gpg-agent --daemon)

However, this alone wasn’t enough to get VC to recognize that it should defer to a running agent for signing the commits. And I could find no way to specify additional command line arguments for the gpg_signing_command in my ~/.bazaar/bazaar.conf file, like so:

    [DEFAULT]
    launchpad_username = urbanape
    email = {my work email}
    gpg_signing_command = /home/zbir/bin/vc-bzr-gpg

So instead, I wrote a script at ~/bin/vc-bzr-gpg that would internalize those additional arguments:

    #!/bin/sh

    /usr/bin/gpg --verbose --use-agent --no-tty $@

Made it executable, and voilà! Commits made in VC mode are signed by the agent (and I’m prompted for my passphrase if the agent isn’t running or hasn’t been authorized within the cache-ttl in my gpg-agent.conf).

Now, if there was only a way to push to Launchpad and submit branches for review from within Emacs…

When Can I Cut the Cord on iOS App Development?

At Çingleton, Craig Hockenberry spoke about where he saw the future of mobile computing. One gaping void in his talk was a topic of incredible interest to those present: development. iOS is still utterly dependent^[1] on a Mac OS X counterpart for full lifecycle app development. I was reminded of both the Newton and the early Macintosh systems.

The early Macintosh couldn’t self-host a development environment. You developed Macintosh applications on a Lisa and installed them via a serial cable. It wasn’t until late 1984 or early 1985 that proper developer tools were made available for Macintosh computers.

The Newton, with the exception of NewtonScript (made spectacularly manifest with NewtDevEnv), was never fully untethered in terms of development.

Now, with apps like Keynote, Pages, Numbers, and Garage Band^[2] pushing the limits of what the iPad and iPhone can do locally, coupled with a (mostly) transparent networked storage layer and binary diff delivery, I think I can see a future where self-hosted iOS development is possible:

Taking a cue from Xcode 4, we’d have a singularly focused interaction model with the emphasis on building the UI elements from palettes and inspectors. A robust and richly appointed code editor handles all the tedious typey-typey, while all of the project’s files are hosted on and fetched from an Apple-branded site on top of iCloud, backed, naturally, by the distributed version control system du jour. Compilation, presumably the gating factor on an iOS device, is done remotely in Apple’s data centers, and incremental binary diffs are sent back down to the device, removing unnecessary network overhead. Codesigning and team testing deployment are handled in a model not unlike TestFlight or HockeyApp, tied into iTunes Connect and the Provisioning Portal.

Some people are finding interesting ways^[3] of using an iPad for their sole machine. I’d like to share in that future with iOS development.