Here’s what turns out to be the most intractable problem I’ve encountered in my move to OSX as my primary work platform:

For years I used a programmers’ text editor tool in Windows called Ultraedit. It worked great and allowed me to record macros. The most indispensible one, which I used constantly, was for automating the creation of HTML links. I would store the link-to URL in a clipboard, select some link text and start the macro. The macro would magically surround the link text with the proper HTML code to link it to the URL in the clipboard.

I achieved this by
(a) copying the link text to a second clipboard;
(b) typing the <a href=”

(c) pasting in the URL from the first clipboard;
(d) closing the tag with “>
(e) pasting the link text from clipboard #2;
(f) ending the link with </a>

It sounds kinda complicated but it worked beautifully, and Ultraedit’s macro recorder simply “got it.” I created the macro years ago, and its keyboard shortcut became hardwired in my memory.

Now I’m using TextWrangler and, alas, AppleScript doesn’t seem to get it at all. The AppleScript recorder seems to grab the actions at too specific a level — i.e., it doesn’t capture “switch to next clipboard” but records the specific clipboard number; it doesn’t capture “current active document” but records the specific document name that I happen to be using while I’m recording the script.

I was gearing myself up to learn enough AppleScript to try to write the script (or edit a recorded script well enough to make it work). Then I discovered that, perhaps thanks to Snow Leopard upgrade, the entire AppleScript recorder in TextWrangler doesn’t seem to work at all. When I record a script and try to save it I get the following error message: (MacOS Error code: -4960). As far as I can tell, I can’t save any scripts at all, making any AppleScript solution to this problem seem hopeless.

I know, I know, if I had learned emacs years ago I wouldn’t have any of these problems. But I didn’t. I welcome any tips/suggestions! Is there a text-editor for Mac that will make my life easier? (I used to use the full version of BBEdit, and, back in those days, it wasn’t any easier to script than Textwrangler.) Is there some obvious solution I’m missing?

For years I organized my life with the wonderful, now-orphaned and somewhat antiquated Windows outliner Ecco Pro. For me Ecco was versatile enough to function effectively as both a todo-list manager and a repository for random information, scattered ideas and research. It really could do it all.

I’ve always used both Macs and PCs but this year I’ve migrated my main workspace over to OS X. There were many compelling reasons to do this, but I’ve had to struggle with finding an Ecco replacement. (Yes, I could run it on my Mac in a Windows virtual machine, but it’s a bit kludgy, and it’s time for me to move away from this program that, despite the efforts of many devotees, doesn’t look like it will ever be fully modernized.)

So far, it’s looking to me like there is no one Mac application that can serve in both roles (todo list and information organizer). OmniOutliner is a pretty good all purpose outliner, and it has a companion, “Getting Things Done”-based todo list program called OmniFocus. Though I’ve made my peace with OmniOutliner, I have not fallen in love with OmniFocus. It follows the David Allen GTD approach a little too rigidly for me, it has various features I don’t need and it’s missing some that I do want (as far as I’ve been able to tell, for instance, it lacks the ability to make some item vanish until a certain date when it reappears–what I call the “out of my face” tool).

So I’ve begun exploring various combinations of other tools. Right now, it’s Evernote for research/information and Things for todo management. I’m also going to look into Tinderbox, Yojimbo and some other applications that look promising. I know the Mac ecosystem is full of great products that sometimes have only small followings, so if there’s one you’re especially enamored of, do let me know.

I’ve also been playing around with Thinklinkr, a new Web-based outliner. It has one huge plus: It’s got an absolutely top-notch browser interface (it’s the only browser-based outlining tool I’ve found that is as responsive and fast as Ecco on the desktop — bravo for that!). At the moment, though, it’s a somewhat rudimentary tool; it lacks various features one might want, and it looks like it’s being aimed at the (important but different) market for collaborative outlining rather than personal information management. But it’s definitely worth a look if you’re into outlining.

Besides Ecco, Quicken is really the last app that I still need Windows for. (Quicken for the Mac is way inferior.) So I thought I’d finally figure out which of the Mac personal-finance contenders would best suit my needs: simple budget and expense tracking on several checking accounts and a credit card or two. All evidence pointed to iBank. I downloaded the program on free trial and checked it out. The register worked nicely, the interface was smooth, and it seemed like importing my 12 years’ worth of Quicken data could be accomplished. So I plunked down the not inconsiderable charge for the program, spent an hour or two figuring out how to avoid having transfers appear twice after the import, and thought I’d solved my problem.

Then I tried to create a report. And the program that had until that moment seemed well-built and -designed turned to sand between my fingers. Report? iBank basically says. What’s that? Oh, you have to create a chart and then you can generate a report? That seems silly — I don’t need a pie chart, it doesn’t tell me what I need to know, but if I have to pay the pie chart tax before I can get to my report, OK! I’ll make some pies! So finally I click the button to make a report and wait for the program to ask me some questions about, you know, which categories and dates and accounts I want to include in the report. But there is no dialogue box. The program grinds through its data and a minute later it spits out a clumsily formatted PDF. Wait a minute; I can customize the chart, and that should then change the report, right? But no, that would be too logical. Whatever I do to the chart, the report is still the same useless, largely unreadable junk.

This is a problem, because, really, the only point to the tedium of entering all these transactions is that at the end of the labor you can click a few buttons and actually gain some insight into where and how you are spending your money. iBank is like a financial-software roach motel: you can get your data in easily enough, but just try getting useful information out the other side!

My guess is that coding up a useful report generator must’ve fallen off the developers’ feature list somewhere along the way and keeps dropping off the upgrades list. Obviously I’m hugely disappointed, particularly since the trial version of iBank doesn’t let you enter more than a handful of transactions, so you never really have the chance to test out the report quality.

I think the next step is to give up on this category altogether and experiment with the online/cloud-based alternatives. Of the available choices, Wesabe, which I’ve begun playing with, and Mint appear to be the likeliest contenders. I’ll let you know how it goes, and welcome any tips and experiences you may have.

Late last night — because late night is the time to tinker with software! — I decided to test drive Dave Winer’s recent crib sheet on setting up an Amazon Web Services cloud-based server. Dave called it “EC2 for Poets” (EC2 is the name of Amazon’s service), and I’ve always been a fan of “Physics for Poets”-style course offerings, so — though I do not write poetry — he lured me in.

For the uninitiated, Amazon has set up a relatively simple way for anyone to purchase and operate a “virtual server” — a software-based computer system running in their datacenter that you access across the Net. It’s like your own Windows or Linux box except there’s no box, just code running at Amazon. If you’ve ever run one of those arcade video-game emulators on your home computer, you get the idea: it’s a machine-within-a-machine, like that, only it’s running somewhere else across the ether.

Dave provided crystal clear step-by-step instructions for setting up and running one of these virtual servers. (Writing instructions for nonprogrammers is, as they say in software-land, non-trivial. So a little applause here.) The how-to worked hitch-free; the whole thing took about a half-hour, and by far the longest part was waiting for Amazon to launch the server, which took a few minutes.

But what should one do with such a thing? Dave’s sample installation runs a version of his OPML editor, an outlining tool. That gave me an idea.

Regular readers here know of my dependence on and infatuation with an ancient application called Ecco Pro. It’s the outliner I have used to run my life and write my books for years now. It has been an orphaned program since 1997 but it still runs beautifully on any Win-32 platform; it’s bulletproof and it’s fast. My one problem is that it doesn’t share or synchronize well across the Net (you need to do Windows networking to share it between machines, and I just don’t do that, it’s never made sense to me, as a one-man shop with no IT crew).

But what if I were running Ecco on an Amazon-based server? Then I could access the same Ecco document from any desktop anywhere — Macs too. So I downloaded the Ecco installer (using a browser running on the Amazon-server desktop, which you access via the standard Windows Remote Desktop Connection tool), ran it, and — poof! — there it was, a 12-year-old software dinosaur rearing its ancient head into the new Web clouds:

What you see here in the innermost window is Ecco itself (displaying some of the sample data it installs with). Around that is the window framing the remote desktop — everything in there represents Windows running in the cloud. The outermost frame is just my own Windows desktop.

This remains very much in Rube-Goldberg-land at this point. Accessing this remote server still requires a few more steps than you’d want to go through for frequent everyday use. (To me it felt like it was about at the level that setting up your own website was in 1994 when I followed similar cribsheets to accomplish that task.) And the current cost of running the Amazon server — which seems to be about 12.5 cents per hour, or $3 a day, or over $1000 a year — makes it prohibitive to actually keep this thing running all the time for everyday needs.

On the other hand, you have to figure that the cost will keep dropping, and the complexity will get ironed out. And then we can see one of many possible future uses for this sort of technology: this is where we’ll be able to run all sorts of outdated and legacy programs when we need to access data in different old formats. Yesterday’s machines will virtualize themselves into cloud-borne phantoms, helping us keep our digital memories intact.

When I first began reporting on Chandler for Dreaming in Code at the very start of 2003, there was talk of shipping a 1.0 version within a year. Then, in following years, the project got so bogged down that at times it was hard to imagine it ever arriving at such a milestone.

Well, on Friday, the OSAF team released a 1.0 version of Chandler. At the moment I am too deep in the swamps of blog history circa 2001 to do full justice to this news, but must take note nonetheless.

Chandler, of course, is the personal-information-management application whose story sat at the center of my first book. I last checked in on the project at the start of this year, when OSAF and Kapor parted ways.

It’s been close to six years since Mitch Kapor first announced plans for Chandler, and the application today is quite different from what was envisioned then. But it does fulfill at least a portion of the ambitious agenda Kapor set: It’s fully cross-platform, and, from the user side, it takes a very flexible approach to data. The program was once positioned as a calendar with email and task capabilities, and it’s still got those features, but it’s now presented as a notebook program — it’s “The Note-To-Self Organizer.” You store information free-form and then can organize it according to now/later/done triaging, turn items into tasks and schedule them on the calendar, group data in multiple collections, and share it across the web via the Hub server. I’m looking forward to experimenting more with it.

The OSAF blog post announcement includes some more detail. And James Fallows has a good post up at the Atlantic.

We have become dependent on Google as a part of our Web infrastructure (too dependent, some say), in part because Google’s reliability record is so superb. All of which makes the receipt of any sort of error message from any dimension of the Googleverse worthy of note.

Today I tried to access my Google Calendar. Instead I saw this:

A minute later, my calendar returned. But for an instant, I got to thinking about life without Google.

Today’s Journal features a Portals column by Vauhini Vara that represents yet another attempt to gauge how far Web apps have come by attempting to “live on the Web,” forsaking all desktop-based software. (Others — like James Fallows in 2006 in Technology Review, whose effort I wrote about back then — have done this before.)

The trouble with this approach is that it’s a total straw man. No one would ever do this except to provide column fodder. The shifts in our software habits are incremental; we don’t “change state” 100 percent, we just drift in one direction. And the drift today is overwhelmingly towards the Web.

Of course Vara finds the trouble spots exactly where you’d expect: If you’re tied in to a corporate email system, giving up Outlook for a Web interface is still painful. Spreadsheets and PDFs are harder to work with. Web-based writing tools are pretty good but so far they haven’t provided a good replacement for Word’s clumsy but essential “track changes” feature.

OK. In the meantime, those of us who aren’t locked in to Outlook long ago went with Gmail or some other Web-based email system. We keep and share our calendars on the Web, and increasingly we use Web-based tools to coordinate small work groups. No one is holding a gun to our heads, so we happily mix Web apps and desktop apps. Why not?

If you’re starting a small business today, are you going to invest in Outlook or are you just going to piggyback on some Web service? When the business begins to grow, are you going to pay the big Outlook tax or stick with what’s working? As developers devise new useful tools for communication and coordination, are they introduced on the desktop or on the Web — or in both places?

These are the trends that matter. “All or nothing” is beside the point.

My friend and former colleague Chad Dickerson has a great post about Facebook developers reliving the perennial platform-developer’s nightmare: if you build something really wonderful, sooner or later the platform owner incorporates what you invented into the core software.

This line should be savored:

As the old Santayana quote goes, “those who do not learn from history are doomed to repeat it,” but in Silicon Valley, those who rely on their command of history too much often find themselves getting crushed by a 23-year-old who skipped history class in favor of a CS degree.

The platform developer’s dilemma goes back a long way: among other things, to the early days of Dave Winer’s web writing (he’d experienced the phenomenon when he saw his own Macintosh scripting environment eclipsed by Apple’s less versatile in-house effort). But it goes even farther back than that — back before Windows. In the 80s, DOS dominated the world, but you couldn’t really run DOS without a zillion helper utilities. Over time and successive DOS releases many of these helper utilities were incorporated into the OS. Much of the time this was a Good Thing for users, and many of the utilities were freeware anyway, but if you’d tried to build a for-profit business around some essential extension to DOS, you were on shaky ground — and Microsoft was the beast causing the tremors.

Chad locates the difference in today’s software world in the speed of development:

Velocity changes everything. As the developers dance faster in this new environment, so too does the platform elephant. The faster the elephant dances, the more likely “the little people” underneath (as Ariana calls platform developers in the News.com story) could get unwittingly trampled in the process.

Very true. But in the end, I think, developers understandably flock toward any platform on which large numbers of users have pitched their tents — true for DOS decades ago, Facebook today, and who knows what tomorrow.

PS I’m reasonably sure the canonical version of the Santayana quotation is:

Those who cannot remember the past are condemned to repeat it.

But the Web is full of variations. And those who cannot remember their quotes are condemned to wander the Web’s copycat quote pages!

[This is a post describing a technique I've found useful for managing my blog. Feel free to skip the geek-out!]

For a long time I’ve wished for a better system to manage my blog post drafts. I know there are client side tools like MarsEdit and Ecto, but I use lots of different machines at home and on the road, and prefer to work with one set of drafts on a server.

Recent tweaks to Wordpress have allowed you to filter posts based on published/unpublished/draft status — that means you can have a standling link to a list of drafts. That simple capability got me most of where I wanted to be; when I get an idea for a post, I create a placeholder post with a quick note reminding me of the idea. A bookmark on my browser toolbar points to this list of drafts.

The other tool that has made this really useful is Postalicious — a wordpress plugin that creates blog posts based on Delicious tags. I was less happy with Postalicious the first time I used it because I had it set to automatically publish my links — but Delicious has a tight, Twitter-like limit on the number of characters you can use to annotate the links. And I like to gas on sometimes. I’d find myself going into the post after it was published and adding material — awkward at best.

Now I have Postalicious set to create the new posts as drafts. As I’m wandering the Web, when I see something I want to blog about, I tag it appropriately. Then the next time I have a chance to do some blogging, I’ve got a nice list of the links I want to write about waiting for me in my draft list. The URL is right there so if I want to quote at length I can just click right through to it and cut and paste the longer quote that wouldn’t have fit into Delicious.

Sometimes, it’s these simple things that please us users the most!

That Orwell quote earlier this week that began “Our civilization is founded on coal” had a “pace Chesterton” at the start that puzzled me. A number of you wrote in with suggestions, including a pointer to a fascinating debate between Chesterton and Bernard Shaw about whether to nationalize the coal mines, moderated by Hilaire Belloc.

But I believe Mark Bernstein found the ur-instance of the Chesterton reference:

This is the true and exact account of the Great Cigar Fraud, and the moral of it is this–that civilisation is founded upon abstractions. The idea of debt is one which cannot be conveyed by physical motions at all, because it is an abstract idea.

So, what Orwell was really saying was: sorry, G.K., our civilization is not founded upon abstractions, it’s founded on the hard reality of coal mining. And thus Stroustrup’s reformulation — “our civilization is built on software” — takes us full circle, back to the many layers of abstraction that constitute our program code.

It all connects!