njr 3.0

I wrote a simple drag-and-drop SCP script. You'll need Bill Bumgarner's excellent SSHPassKey and Satimage.osax (included with Smile).

Mainly useful for me to leave on the desktop so I can quickly upload screenshots for others to look at—especially now Mac OS X is able to generate them directly in PNG format.

It was with some hesitation that I bought Script Debugger a few weeks ago. I now recommend it unconditionally: it's a great tool, well worth the price. Makes writing AppleScript almost enjoyable.

11:31 PM | Radio
No Comments

Today's Brent's birthday, and Josh Lucas's birthday, and my birthday as well. I'm 23.

12:42 PM | Radio
No Comments

I couldn't resist - tonight is our first real snowfall I've seen this winter in Illinois - I was away last time. Big difference from the freezing rain/sleet that pelted everything in sight last night (and it hurt!) It's so beautiful looking out the window, I don't want to sleep, but I must.

3:42 AM | Radio
No Comments

I'm too far behind with non-Net stuff - house, car, music, family, etc. Nothing catastrophic is wrong, but I fear it will happen if I don't start paying more attention to the world outside my computer. Until I'm caught up I'm reducing my online presence - including this weblog.

5:50 PM | Radio
No Comments

Steve Zellers: “The big loser in Mac OS X is the file system fragility problem.”

Yup. Cocoa makes things easy for the programmer, at the cost of fragility and poor error reporting: I still can't believe there is no result code or structured exception handling in Cocoa at all. Zip, zero. This is a huge failing: if the framework can't return specific errors to the programmer, then how can the programmer present intelligible error messages to the user? These are simple things like distinguishing 'file not found' from 'permission denied' from 'disk full', which Cocoa completely hides as a single boolean success/failure value despite their presence in the underlying BSD APIs.

The old Mac philosophy was to make things easy for the user, at the potential cost of pain and suffering for the programmer. I don't mind the pain and suffering all that much—I just spent the last five hours trying to fix some threading/corruption issues that I still haven't isolated with a (Cocoa) application, but I'd do it a hundred times over if it meant giving users an application that behaved stably and made sense.

As a programmer, I'd prefer the best of both worlds: an API that's easy to use, but robust and predictable for the user.

1:47 AM | Radio
No Comments