Fetch makes it easy to edit server files (using any application you like), but sometimes you don't want to open the file, you just want to take a peek at it.

Apple responded to a similar need in the Finder by introducing the Quick Look feature in Mac OS X 10.5 Leopard. Tapping the space bar displays a preview of the selected file (or files), and tapping it again dismisses that preview. Quick Look can preview text, images, videos, audio, and many other documents, including those created by Microsoft Word and Excel. And the Quick Look system is extensible: as developers release Quick Look plugins, more and more file types are supported.

We've had Quick Look support in Fetch since releasing 5.5 last June. Just as in the Finder, tapping the space bar (or clicking the Quick Look button, or choosing the RemoteQuick Look menu command) shows a Quick Look preview of the selected file on the server. Of course Fetch has to download the file contents before they can be previewed, but that happens automatically (and Fetch remembers the file so that it doesn't have to be re-downloaded if you preview the file again). Double-clicking in the Quick Look window opens the file in the appropriate application.

Thanks to new support in Mac OS X 10.6 Snow Leopard, we were able to improve Fetch's Quick Look behavior as of Fetch 5.5.2. Now, on Snow Leopard, you can switch back and forth between viewing a bunch of files as thumbnails or as a slideshow, and you can add previewed images to iPhoto.

One weakness we found with Quick Look in Fetch 5.5 has to do with its handling of text files. Quick Look does not support selecting text, so there is no way to copy a bunch of text out of the Quick Look preview in order to paste it in another application. To address this we added a View as Text command to Fetch 5.5.3. View as Text opens text files in separate windows, with support for selecting text.

Together, Quick Look and View as Text make previewing your files in Fetch easier than ever.

In How Reliable Is Reliable Enough? I wrote about the steps we took to make Fetch 5.5 more reliable, in particular its support for automatically resuming failed or stalled uploads. In the time since we released Fetch 5.5 we’ve heard from numerous users who’ve been helped by this feature. It is especially useful when transferring a large collection of files in many folders, for example a large web software package (e.g. WordPress or SugarCRM). In a big transfer there are hundreds of opportunities for one small part of the operation to stall or fail due to a server hiccup or network glitch. In versions of Fetch before 5.5, that would bring the entire transfer to a halt. Then you would be stuck figuring out what you still had left to transfer, or you might toss what you'd done and start over, just to be safe.

Fetch 5.5’s automatic resume feature fixed that problem for most uploads, but we heard about a few cases where it could do better. We also heard from users facing similar problems with large downloads. So in Fetch 5.6 we improved the performance for uploads, and extended the automatic resume feature to cover downloads as well. It also covers mirror transfers in either direction, and folder delete commands. We think we've eliminated nearly all of the common situations where a temporary glitch can cause a large operation to fail.

Please give Fetch 5.6 a try with your most challenging transfers, and let us know how it goes!

Etna, NH — Reliability is the watchword for Fetch 5.6, the latest version of the original Macintosh file transfer program, released today.

Transient errors or stalls can all too often cause a website update or large download to grind to a halt, wasting time and requiring tedious and error-prone manual intervention. Fetch 5.6 automatically resumes uploads, downloads, and mirror operations, to ensure that network glitches and server hiccups do not stand in the way of successful FTP or SFTP transfers.

Fetch 5.6 is a Universal binary, compatible with Mac OS X 10.4 or later, including Mac OS X 10.5 Leopard and Mac OS X 10.6 Snow Leopard, and can be downloaded from http://fetchsoftworks.com.

Fetch 5.6 is free to try for 15 days, and a single-user license is $29. Upgrades are free for Fetch 5.5 users and customers who purchased Fetch after January 28, 2009; otherwise, upgrades are $10. Free licenses and upgrades are available for educational and charitable use.

My son Dylan is away at college, and on January 27 — the day of the iPad announcement — I was on my way to visit him when I noticed that I was walking by the campus bookstore. I flashed back to January 24, 1984, when I was a freshman at the same college, and had eagerly hurried into that same bookstore to witness the unveiling of Apple's new Macintosh computer. On both days it felt as if the world of computers was being made anew.

The announcement of the iPad, and the recognition by some (e.g. Steven Frank, Frasier Spiers and Dan Moren) that this represents a new era of computing, gives me a powerful sensation of déjà vu. Like the iPad, the Macintosh that Apple unveiled in 1984 was intended to radically simplify computing. Jef Raskin, who started the Macintosh project at Apple, believed that personal computers should be more like appliances: simple, rather than complicated, focused on specific tasks, rather than general-purpose. Raskin left Apple in 1982, but the idea of computer-as-appliance lived on in the Macintosh. If you wanted to write, you put in your MacWrite floppy disk and it became a word processing machine. If you wanted to draw, you put in your MacPaint disk and it became a digital sketchpad. Every application took over the entire screen, and turned the machine into a specialized device. In that way it was not so different from the iPhone of today (or the iPad of this coming April).

Raskin went on to create an even more appliance-like computer, the Canon Cat, which was a commercial failure. And the Macintosh itself only barely escaped an early demise. While Apple had planned to sell millions, the first year’s sales did not reach 100,000, and it was only the fortuitous emergence of desktop publishing that saved the Mac from cancellation. Over time the Mac acquired new features and capabilities, and new complexity, such that today we can look at it as an example of “Old World” computing that we hope to move beyond.

For the iPad to truly usher in a new age of user-centric computing it needs to succeed commercially, and it needs to avoid the creeping complexity that turned the 128k Mac into the MacBook Pro of today. There are reasons for optimism on both scores. Past efforts — the Mac, the Cat, and the Newton — tried to build a new world from scratch, offering no compatibility with existing platforms. As John Gruber has persuasively argued, it was that incompatibility more than anything else that doomed the Mac to its small market share. It is simply too difficult to sell a computer that forces consumers to throw away everything they have learned and done before. The iPad does not have this weakness: it builds on the iPhone, which in turn built on the iPod and iLife and Safari and Mac OS X, which in turn built on the classic Mac OS and NeXTSTEP. The Mac started with three applications (MacWrite, MacPaint, and Multiplan); the iPad will start with over 100,000. The iPad, like the iPhone, also starts with the web, the most critical and adaptable “application” of all.

The iPad will therefore not succumb to the usual new platform Catch-22 of having neither enough market share to attract software, nor enough software to build market share. But will Apple resist the temptation to add new features until an iPad requires as much training and expertise as a general-purpose personal computer? It’s much too early to tell, but the design decisions Apple has made to date suggest an encouraging restraint. They are helped by the fact that the iPhone and iPad can be huge successes without trying to be all things to all users. Customers who need a more flexible and complicated device can buy one, but most will be perfectly happy with an iPad. As new uses and technologies become mainstream Apple can incorporate them, while ensuring that the simplicity and usability of the platform is protected.

As a developer I have mixed feelings about this incipient new age. I remember when the U.S. telecommunications system was run by a benevolent monopoly, with awesome reliability and ease of use, and equally awesome resistance to change. Ma Bell imposed a narrow bottleneck for technological progress, a bottleneck that was ultimately smashed by the anarchic personal computer market. It was the wide-open personal computer that let hobbyist developers write and sell BBS systems, PPP drivers, and ultimately web browsers — without having to first ask permission. It is not difficult to imagine some great new idea dying because it can’t get through the App Store, or because the developer decides it is not even worth trying.

That said, I fervently hope that the iPad does represent a new world for computers. We developers build things to help people, but it is all too easy to focus on the things rather than the people. Today’s computers are wonderful, but they aren’t good enough for people. The iPad is another chance to do better.

I read a lot of articles online, and sometimes the ads and navigation links make it difficult to concentrate on the text of article, much less on the ideas that the text is trying to communicate. The folks at arc90 have come to the rescue with Readability, a JavaScript bookmarklet that reformats the current web page as a clean page of text:

→

Readability works great in Safari, but I do most of my web reading in NetNewsWire, the RSS reader by Brent Simmons of Newsgator. And NetNewsWire does not have a bookmarks bar where I could put the Readability bookmarklet.

Fortunately, NetNewsWire does have a Scriptmenu, and support for the do JavaScript AppleScript command. That makes it possible to add Readability support to NetNewsWire by following these steps:

1. Run Script Editor and create an AppleScript like the following:

   set theJS to "bookmarklet link"
   set jsScheme to "javascript:"
   if (offset of jsScheme in theJS) is 1 then
   	set theJS to (characters from (1 + (length of jsScheme)) to -1 of theJS) as string
   end if
   tell application "NetNewsWire"
   	do JavaScript theJS
   end tell
   

2. Go to the Readability web page to create a bookmarklet with your preferred settings
3. Right-click (or Control-click) the bookmark and choose Copy Link
4. Back in Script Editor, paste the link you just copied in place of the text bookmarklet link; it will start with "javascript:" and will be quite long
5. Save your script (e.g. to the Desktop)
6. Choose Open Scripts Folder from the Scriptmenu in NetNewsWire
7. Copy your saved script to the NetNewsWire Scripts folder

Once you’ve followed these steps your script will be listed in NetNewsWire’s Scriptmenu, and you can choose it to invoke Readability for the currently displayed web page.

I am a fan of the writer Tracy Kidder (The Soul of a New Machine, House) and a few years ago I picked up his then-latest book, Mountains Beyond Mountains. It tells the story of a doctor, Paul Farmer, who (along with friends Ophelia Dahl and Jim Yong Kim) created an organization called Partners In Health. PIH was founded to deliver high quality health care to the people of Haiti’s Central Plateau. Working with the people of Haiti, PIH’s efforts there have grown from a single clinic in 1985 to a system of hospitals, clinics, and community health workers that provided 2.6 million patient visits in 2009, all of them free of charge. It is a moving and inspiring story that convinced me to become a financial supporter of PIH’s work.

In the aftermath of the earthquake that struck Port-au-Prince on January 12, 2010, Partners In Health is perhaps the largest functioning medical provider left in Haiti. Their own facilities are far enough from the epicenter to have escaped serious damage, and their trained medical teams have been working around the clock to treat survivors. If they can afford to purchase the supplies they need, they will be able to save thousands of lives, not only from earthquake injuries, but also from the infections and other public health threats that will emerge in the weeks and months ahead.

To help make that happen, Fetch Softworks is one of nearly 150 independent Mac and iPhone developers participating in Indie+Relief, a group fundraiser for Haiti. If you purchase a Fetch 5.5 license on Wednesday, January 20, 2010, 100% of the proceeds will be donated to Partners In Health. If you already have a Fetch license, please take a look at the other applications that are for sale: you can pick up a great app and help Haiti at the same time. And if you do not need any software, please visit the PIH website, learn more about their work, make a donation, and spread the word.

Many thanks to Justin Williams of Second Gear Software for organizing Indie+Relief.

UPDATE: Thank you to everyone who purchased Fetch 5.5 yesterday — you raised $3,742 for Partners In Health!

Hello from Italy!

While my Fetch colleagues are toiling away at their posts, I am taking a break from Fetch to have an adventure. I am one of ten developers from around the world gathered together in Venice, Italy by Command Guru to develop an iPhone app from scratch in seven days. If that were not enough, the entire experience is being streamed live at commandguru.com.

So if you ever wondered what goes on behind the scenes to produce the apps you use, you can tune in to watch us sketch, discuss, argue, and type our way to actual software. We have been at it for three days now, and it’s been great fun to work with this terrific group of developers, and to get instant feedback from viewers around the globe. Not to mention all the fantastic Italian food!

In honor of this unlikely event we’re offering an equally improbable promotion: a Fetch half-off sale. Today and tomorrow, December 10 and 11, 2009, you can get a 50% discount on Fetch by entering the coupon code COMMANDGURU.

Ciao!

The default behavior of Subversion when tunneled over SSH works well for simple cases. I encountered some more complex situations which required digging into advanced SSH features, and built some simple tools that make our Subversion life easier.

Specifying a username for SSH repositories

By default, when you connect to a Subversion repository over SSH, Subversion will assume that the remote username is the same as the local username. When this is not true, you can force a different username to be used. When you check out the repository, use:

svn checkout svn+ssh://svn-username@svn-hostname/svn-path

Subversion will parse the username out of the URL, and pass it through to SSH, which will then prompt you for the password for the correct account.

Avoiding multiple password prompts

If you have a simple SSH repository, you will be asked for your password once at the beginning of a Subversion command. However, if your repository contains externals, you will be asked for your password again for each external that requires it. If you have multiple externals on the same server, you get to enter the same password multiple times.

To work around this you can use SSH session sharing. Session sharing lets multiple SSH connections to the same server share a single network connection. That also causes multiple SSH connections to the same server to share credentials, and therefore you don’t have to reenter your passwords during a single Subversion command.

To set up SSH session sharing, you need to add this to your ~/.ssh/config:

ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

To verify that it works, open an SSH connection in Terminal, then open a new Terminal window and open another SSH connection to the same account as the first one. The second will not ask for your password.

The configuration above enables SSH connection sharing for all SSH connections. If, instead, you want to only enable connection sharing for your Subversion server, put the following at the bottom of your ~/.ssh/config:

Host svn-hostname
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

Avoiding multiple password prompts — the pair.com users’ version

On pair.com — I imagine this may also be true of some other hosting providers — the above recipe with SSH session sharing works great as long as your repository has fewer than ten externals. Once you get to ten externals, you see a “channel 10: open failed” message and your Subversion command dies.

This is because pair.com limits SSH session sharing to ten simultaneous connections to a given server. Unfortunately, Subversion keeps every SSH connection open until it’s done with all of them. If you have ten externals on the same server, you wind up with eleven simultaneous SSH connections (ten for the externals and one for the root of the repository), and so your SSH and Subversion error out.

The good news is that SSH already has a mechanism to delegate its password prompting to another tool (this is what programs like Fetch use to give a graphical user interface for entering your SFTP password). If you had a tool that handled SSH password prompting, but was also capable of remembering the passwords you gave it and not asking you to reenter them, you would only get asked for your password once.

An SSH password prompter is relaunched for every prompt, so it needs a place to stash passwords during a single Subversion command. An easy way to handle this is to write a tool which creates a password store and then launches Subversion. Using that tool instead of Subversion will provide the password prompter with the password repository it needs to work correctly.

This is what the Subversion replacement looks like:

#!/usr/local/bin/python

from __future__ import with_statement
from subprocess import call
from tempfile import mkdtemp
from os import mkfifo, environ
from os.path import join, expanduser
from sys import argv
from threading import Thread
from pickle import load, dump
from getpass import getpass

request_pipe_path = join(mkdtemp(), "svn-askpass-requests")
response_pipe_path = join(mkdtemp(), "svn-askpass-responses")

mkfifo(request_pipe_path)
mkfifo(response_pipe_path)

args = argv[1:]

def prompt_loop():
    cache = {}

    while True:
        with open(request_pipe_path, "r") as request_pipe:
            hidden, request = load(request_pipe)

        if not request in cache:
            if hidden:
                cache[request] = getpass(request)
            else:
                cache[request] = raw_input(request)
            
        with open(response_pipe_path, "w") as response_pipe:
            dump(cache[request], response_pipe)
            
prompter = Thread(target=prompt_loop)
prompter.daemon = True

environ["SSH_ASKPASS"] = expanduser("~/.subversion/svn-ssh-askpass")
environ["SSH_ASKPASS_REQUEST_PIPE"] = request_pipe_path
environ["SSH_ASKPASS_RESPONSE_PIPE"] = response_pipe_path

prompter.start()

exit(call(["/usr/local/bin/svn"] + args))

There isn’t much to it — it creates two pipes, on one of which it reads prompts and on the other of which it provides user responses. Before starting Subversion, it spawns a background thread, from which it listens for prompts. If it receives a prompt that it has already seen, it returns the same answer as before; if it receives a prompt it hasn’t already seen, it presents it to the user and stores the answer for later.

If you weren’t familiar with them before, you may find these interesting:

• tempfile.mkdtemp: securely creates a temporary directory readable only by its owner
• getpass.getpass: securely prompts for a password
• threading.Thread.daemon: if set on a thread, then the thread is automatically killed off when all other threads are done
• os.path.expanduser: expands ∼ to user’s home path
• os.environ["SSH_ASKPASS"]: the way to tell SSH to delegate password prompting

This Subversion wrapper sets up SSH to use ~/.subversion/svn-ssh-askpass for password prompting. However, SSH doesn't use the value of SSH_ASKPASS unless a few specific conditions are met, and those conditions are not met when Subversion command line invokes SSH. Therefore, we also need to create a wrapper for SSH, which will set things up so that password prompting is delegated to the prompter, and then we need to tell Subversion to invoke that SSH wrapper instead of SSH.

This is what the wrapper looks like:

#!/usr/local/bin/python
from os import setsid, environ
from subprocess import call
from sys import argv

# We have to invoke SSH from a process with no controlling terminal
# in order to get SSH_ASKPASS to work
setsid()
environ["DISPLAY"] = "0"

exit(call(["/usr/bin/ssh"] + argv[1:]))

If you don’t really get all the details of this, that’s OK. I don’t either; it’s Soviet-era UNIX programming, I just Googled until I pieced it together.

Save that at ~/.subversion/svn-ssh-detach and tell Subversion to use this SSH wrapper by adding this to your ~/.subversion/config:

[tunnels]
ssh = /Users/ben/.subversion/svn-ssh-detach

Sadly, Subversion doesn’t expand ~ in tunnel configuration, so you have to put the full path to your home there.

OK, now we have a Subversion wrapper that can cache passwords, and we have an SSH wrapper that can delegate its password prompting to a custom prompter. All we need to do to close the loop is write a custom prompter that talks to the Subversion wrapper instead of directly prompting you:

#!/usr/local/bin/python

from __future__ import with_statement
from sys import argv
from os import environ
from pickle import load, dump

prompt = argv[1]
secret = False

if "password:" in prompt:
	secret = True

with open(environ["SSH_ASKPASS_REQUEST_PIPE"], "w") as request_pipe:
	dump((secret, prompt), request_pipe)

with open(environ["SSH_ASKPASS_RESPONSE_PIPE"], "r") as response_pipe:
	print load(response_pipe)

And there you have it. To recap:

• Subversion wrapper: put it anywhere you like, make sure it’s executable
• Subversion configuration changes: put them in ~/.subversion/config
• SSH wrapper: put it in ~/.subversion/svn-ssh-detach, make sure it’s executable
• SSH prompter: put it in ~/.subversion/svn-ssh-askpass, make sure it’s executable

From there on, invoke your Subversion wrapper instead of svn (or create an alias that runs the wrapper when you type svn).

Fetch 5.5.3, a bug-fix update to Fetch 5.5, is now available. This release fixes a number of problems reported by our users.

The changes in Fetch 5.5.3 include:

• Fixed Mac OS -8905 errors when opening Fetch or saving shortcuts on Mac OS X 10.6 Snow Leopard
• Fixed rare freezes when quitting
• Fixed a problem where Fetch displayed the copy cursor when moving a file
• Fixed problem displaying file lists with Norwegian month names from vsFTPd servers
• Fixed a problem where items moved to a parent folder would sometimes not appear in the parent folder's file list
• Improved compatibility with certain versions of the VanDyke VShell server that send non-standard TYPE replies

For a complete list of changes, see the Fetch 5.5.3 Release Notes.

The Fetch 5.5.3 update is free if you purchased your Fetch license after January 28, 2009; otherwise an upgrade is $10, and a new license is $29.

Please download Fetch 5.5.3 from the Fetch Download page, or by choosing Check for Update… from the Fetch menu in an earlier version, and let us know what you think of the new release.

Fetch 5.5.3 is a Universal binary, compatible with Mac OS X 10.3.9 or later, including Mac OS X 10.5 Leopard and Mac OS X 10.6 Snow Leopard.

Upgrading an application can be an annoying process. In the best case, you click an Upgrade button and go on with your work; in the worst case, you spend hours in frustration trying to make the new version work. For some applications — such as Fetch — the upgrade experience is made simpler by code signing, a Mac OS X 10.5 Leopard technology.

From the earliest days of Mac OS X, Apple made it easy to securely store passwords in the keychain. A password in the keychain no longer has to be remembered, making it easy for you to log into different accounts, websites, and servers.

An application can only see those passwords that you let it see. The first time an application tries to access a password saved by another application, you have to give it permission. For example, without your permission, Fetch can’t access your bank account password, and Safari can’t access your Fetch passwords.

Before Mac OS X 10.5, every time you upgraded an application, you had to re-approve it for password access. A new version of Fetch would need to get your permission to access your web host password, even though the old version of Fetch already had that permission.

This was because there was no way for Mac OS X to tell a new version from a fake. The fear was not that a new version of Fetch would steal your passwords, but that someone would fool you into installing a Fetch lookalike that emails all your passwords to a miscreant.

Requiring new versions to ask for permissions was a safe thing to do, but it made it rather tedious to upgrade some applications. After you installed a new version, the first time you tried to access a password-protected account, you would see something like this:

“Huh?” you’d say. Change All sounds ominous, given that you were probably just logging in and not yet trying to change anything, but good luck figuring out from that dialog if this was change you could believe in.

Of course, if you click Don’t Change, you’ll get the same question next time. Your computer is giving you a not-so-subtle hint: if you want to get on with your life, you might want to click Change All, whatever in the world that means.

To make matters worse, you wouldn’t always get the same dialog; depending on how you upgraded, you may see a completely different dialog. Even worse, sometimes you might see the dialog once for each password… every time you upgrade.

All in all, this made upgrading confusing and annoying. Nobody was happy about this state of affairs, and, starting with Mac OS X 10.5 Leopard — released in 2007 — Apple made it possible for developers to give the Change All mole one final whack. Using a technology called code signing, information about who created an application can be stored inside the application in a way that can’t be tampered with or falsified.

Once an application contains its author’s identity, Mac OS X can tell the difference between a new version of an application (which has the same author identity as the old version) and a fake (which would have someone else’s identity, or no identity at all). This way, Mac OS X can give new versions of Fetch access to all the passwords that older versions of Fetch had access to. At the end of the day, this is one less reason for having to sweet-talk your computer into letting you get work done.

This is so obviously good for our users that we ran off to sign Fetch two years ago, when we were working on Fetch 5.3, aiming to release it concurrently with Mac OS X 10.5. To gain some other benefits of code signing, we needed to obtain an official code-signing certificate™, issued by an official certificate authority™.

We applied for a certificate, and the issuer conscientiously asked for all sorts of information about the company. Nothing too complicated — company name, company address, a proof that we are a legitimate business, and so on.

This is when we somewhat unexpectedly found out that, while we were busy shipping software, our company ceased to be. Our corporate registration with the New Hampshire Secretary of State had lapsed; before we could proceed, we had to have our status as a legitimate business reinstated. Several months and layers of red tape later, we finally got our hands on a certificate, but by now it was much too late to sign Fetch 5.3 — as planned, we had released it shortly after Mac OS X 10.5 came out.

We signed the next version — Fetch 5.3.1, released in March 2009. Since then, we have been delivering you features and bug fixes without the pesky keychain approval alerts. Enjoy!