Way back in the MPW days, I used to rely heavily on an extension for the IDE that put powerful pasteboard manipulation tools in the window header. Essentially these tools let you treat your pasteboard like a stack, so you could easily accumulate multiple copies and then paste them all out at once.

For some dumb reason, I’ve been living without such conveniences for several years now. I know there are many 3rd party products that add an epic amount of functionality to the standard copy and paste of the system, but I’m not really interested in running a separate application for this purpose.

It occurred to me that this would be a perfect use of Xcode’s Menu Scripts. Xcode not only supports the addition of custom scripts to the menu bar, but supports a unique format by which the scripts can advertise keyboard shortcuts, and integrate seamlessly with Xcode’s text editor. For instance, you can use a script to process the selected text in Xcode and spit back out something else in its place.

Append To Pasteboard is a simple python script that takes advantage of the “pbcopy” and “pbpaste” commands to tack whatever you’ve selected in Xcode on to the end of the existing pasteboard. You stick this within your (horribly located) user scripts folder, where you must name the folders and files with numeric prefixes to inform Xcode where they belong. For example, the script lives in my home directory:

/Users/daniel/Library/Application Support/
	Apple/Developer Tools/Scripts/
	10-User Scripts/1-DCJ/

Unfortunately Xcode doesn’t handle the situation where some scripts come from your home directory, and some come from the /Library installation directory. So I put everything in my home directory. The “10-User Scripts” is how I tell it to name the menu bar item “User Scripts.” The “1-DCJ” folder is the folder with all my custom scripts in it, and since it is “1,” it comes before all of Apple’s standard scripts that I copied in (10-Open, 20-Search, etc). The process of providing scripts to Xcode is ugly but when you finally get it all put together, this is what you end up with:

Now it’s a snap to cruise through a .m and accumulate method declarations, for pasting into a corresponding .h. Note that the script always appends a newline to the existing pasteboard, which could be annoying depending on what you want to use it for. Since I envision myself almost always double-clicking a function or method declaration and appending it to a list, I find this behavior to be most convenient.

Thanks to Jon Wight for helping with Python.

Update: Any productivity gained by using this macro was certainly lost as I tried desperately to debug Xcode’s latest propensity to “beachball” on launch. Finally, I attached with gdb and found a telling backtrace. Hmm? Yep, when I “zipped” the script for upload to the blog, I left a zipped copy in the scripts folder. Next time I launched Xcode, it choked big time on trying to treat that zip file as a script.

There has been some speculation among my programmer buddies that Omni has lost a developer. Given the recent job listing for a Senior Cocoa Coder, many figured they must be restocking the talent. I figured they were just growing (and they may well be), but it turns out they did lose a developer, and quite a veteran at that.

Len Case is Omni CEO Ken Case’s brother, and apparently left the company in November, after 13 years of service, to become the lead developer at STX. He tells an interesting personal story about the decision, explaining that he thought about leaving in past years, but hesitated because of how his brother might take the news. The entry also includes some great context surrounding Omni’s formation way back when.

The Omni bio page still lists Len as a developer for the company, but perhaps this is a sort of “emeritus” honor (or they’re just slow in updating). What did Len do at Omni? The bio is purposely vague, but it looks like OmniDiskSweeper may suffer for his departure. By peering into the past, I gathered clues that indicate maybe his contributions were mostly in the consulting services that Omni provides to other companies. By the way, peering into the past is fun. And embarrassing. Don’t look me up. Please.

These details were all discovered after following Rentzsch’s incredibly vague del.icio.us entry pointing to Len’s blog.

TUAW points us to a a choice Newton video, from 1993. In spite of some dated production qualities, this video could serve as a template for marketing the greatest features of the iPhone. Syncing, address books, To Dos, “instant messages.” Lots of features ripe for comparison with the iPhone and other modern devices. It even “squirts” (beams) like a Zune!.

The best part of the video? In the midst of all this enlightened modern living, the video shows a man scribbling away on his Newton while talking on the phone. A pay phone! If only they could somehow combine those two devices! I also like the knowing look and raised eyebrows one worker gives to another just before she “beams” him a message. A subtle suggestion that Newton might actually get you laid.

I never used a Newton much, although I occasionally had my hands on one at work for some debugging purpose. Some of the design considerations really pop out, like the fact that the Newton was almost entirely “soft button” based, much like its nascent offspring. The soft QWERTY keyboard is even reminiscent of the iPhone’s, except that with the Newton it was only intended to be used when the handwriting recognition made a mistake.

Which it did. A lot. Many people consider the failure of adequate recognition on the Newton, and the basically functional compromise of Palm’s “Grafitti” to have been the death blow for the gadget. Amid all the happy music and smiling people, you can tell the issue was weighing heavy on Apple’s mind, too. Halfway through the video the topic changes to “handwriting tips” and more or less stays on the subject for the rest of the promo.

If Apple presents iPhone along with a promotional video that is half devoted to teaching users how to workaround the device’s bugs, then we’ll know it’s doomed.

Today I decided to take a real Sunday. That is, to turn the computer off and do some massive chore-handling that I’ve been putting off for too long. I decided to clean and reorganize my office. Or at least get started. At around 1:30PM EST, I shut off my computer determined not to turn it on again until around 7:00PM.

Everything went great. That is, I got a lot done. I took my entire desk “apart” and put it back together, in a new location. Rerouted a bunch of clumsy wires. Mopped the floor. Went through files, etc. Hours later, I hooked everything up and turned the computer back on, to make sure it all still worked.

I so picked the wrong day to do this. Upon returning to my Mail inbox, I was greeted by news of a comment on my blog, regarding FlexTime 1.2: “So how come when I go to download it via MacUpdate I get a ‘file not found’ error.” Nightmare scenarios immediately passed before my eyes. I put the wrong URL into MacUpdate? I forgot to upload the file to the server? Surely if something that wrong had happened, I’d have heard by now?

I decided to take a browse to MacUpdate and then to my server. Sure enough, the file was not found. What the heck? I typed “www.red-sweater.com” into the URL field and decided to browse my way to the problem. Here’s where Groundhog Day Syndrome set in: I’m staring at a several-months old version of my site. Old design. Old software releases. What on earth? How could this possibly have happened?

A couple days ago I decided to perform some good housekeeping of a different nature. Although my site has been hosted on Pair for several months, and was hosted on DreamHost before that since April of last year, my domain name registration has been maintained on a pretty user-unfriendly Tucows-based registrar called OpenSRS.net. Since I’ve registered some new names since then on DreamHost, I decided it was time to bite the bullet and consolidate everything into one place. DreamHost has been good for this type of administrative stuff, so why not?

Apparently everything finally kicked in some time this afternoon, as I was knee-deep in cleaning supplies and for once every computer in my office was unplugged and stacked in corner. No problem, right? They just took over the registration of the domain. Yeah, no problem, if you overlook the minor problem that they changed the root nameservers to their own! Ugh! So the reason I’m looking at a months-old version of my site is because I just so happen to have the account with them that red-sweater used to be hosted on, and that old stale directory is still there, unchanged.

I immediately try to rectify the situation by changing the root nameserver values back to their correct, Pair.com based values. In response to this I’m greeted with a lovely internal error from the bowels of DreamHost:

Can't call method "request" on an undefined value at

/usr/local/lib/site_perl/Ndn/Registrar/Registry/NewEPP.pm
line 2137.

Oh, that’s just great. I also notice in looking at my DNS configuration on DreamHost that I actually have a custom A record entry pointing red-sweater.com to my Pair site. Unfortunately, they insist on keeping their own A record pointing at themselves. So if you ask DreamHost for my domain’s lookup, they’ll give you a schizophrenic response pointing both to Pair and to DreamHost.

So I decide the only thing to do is get in touch with DreamHost support. For the first time, I feel sufficiently screwed by the situation that I choose for the severity of the problem the typically cheeky:

“OMG! EXTREME CRITICAL EMERGENCY!! EVERYTHING’S BROKEN! People are DYING!”

The only part that’s not literally true is the part about people dying. But I decided to choose it anyway. An hour later, people are still not dying, but everything is still OMG broken.

I took matters into my own hands. I could either stand by and watch while my customers are treated to a version of my site fit for a museum, or go into damage-control mode. Since I keep my web site’s files in a Subversion repository, it wasn’t too hard to go back to the DreamHost version of reality and “svn update” everything to match the modern-day Pair site. Of course I’m a bit lazy about adding and committing every thing as I do it, so I had to go back into Pair and do some heavy committing. Then do some heavy updating on DreamHost.

But aside from the fact that the speed of the site is back to the lackluster DreamHost level, everything appears to be more-or-less back to normal. I’ll wait patiently now for DreamHost to fix my registration to point back to Pair. But in the mean time, I guess nobody is going to die.

One thing I almost overlooked is the PayPal “IPN” payment notification, which is configured to bounce back to my site and let me know when somebody has paid for one of my products. I have this implemented on my Pair account in a way that relies on some full paths and such to log files on Pair. I really didn’t want to hack this together on DreamHost just to survive the unfortunate retransition. Then I remembered that thanks to Pair’s “one IP per domain” approach to shared hosting, I can point PayPal (temporarily) at the raw IP address version of my site. I’ll breathe a sigh of relief and assume that PayPal purchases will be fulfilled as usual. If anybody wants to buy something just to check, that’ll be fine by me :)