This morning I signed up for an upgrade for my two Macs; a 5-user “family pack” for $49.00, which will cost me $25.00 per machine. There is one version for everybody, and two prices, $29.00 for a single copy and the $49.00 for the family pack.

On the Microsoft Windows 7 side it is a crapshoot. Decide between three different versions, plus full or upgrade versions, plus 32 or 64 bit versions, and pay at a minimum what appears to be $79.00 for a single copy for an upgrade. Considering the fiasco of Windows Vista, Microsoft should be paying their customers to install Windows 7, not the other way around.

Both upgrades Mac and Windows appear to offer very little in the way of enhanced functionality as David Coursey says in his blog, “Snow Leopard, More Snore Than Snarl“. PC World also has a comparison of the two upgrades.

Recommendation: Sit Tight. Wait till Christmas.

I’m dipping a toe into programming my Mac… and it looks as if one of the best entry-level ways to do it is to use the scripting tools provided with the OS. They are installed under the Applescript folder which is in the Applications folder.

The script editor is a simple text editor which checks the syntax and runs the script.

After I fiddled with this for awhile, I actually went out and bought a book (!), AppleScript 1-2-3 A self-paced guide to learning AppleScript by Sal Soghoian an Bill Cheeseman. Amazon link here. It is useful and interesting to read reviews of the book, and other Applescript books, because you can gain a certain amount of insight about the AppleScript language itself. Not all of it is rosy commentary. For example, here is an excerpt from another review of an O’Reilly Applescript book…the book actually sounds quite good, however, with a publication date of 2006 it is a couple revisions back:

Apple has long pushed AppleScript as an easy-to-learn, English-like way of automating repetitive tasks on a Mac. Alas, I and many, many others have discovered from painful experience that AppleScript is hugely difficult to approach — its learning curve never seems to flatten out. Even after writing thousands of lines of code in several programs that (eventually) worked, I still feel I’m groping in the dark every time I try something new. I’ve read other books on AppleScript, looking for one that would open the magic door and reveal the simple, friendly AppleScript that’s supposed to exist.
Matt Neuburg has given us the first AppleScript book that tells the deep truth: AppleScript is a quirky, inconsistent programming language that is not only hard to learn, but hard to learn for fundamental, structural reasons. Neuburg exposes the unavoidable difficulties that are built into AppleScript’s design, and then shows us practical techniques for accomodating to them and using them.

Ok. Nevertheless, I’ve plowed on roughly halfway through the book. One of the other features of the scripting tool is the “dictionary”… this is essentially an object browser which allows you to look at all of the objects, events and commands of an application. If the developer wants to create an API for the application, they can expose objects, events and commands of the app. Here is an example of the dictionary chooser…I’m going to take a look at the Mac Mail application.

When I select Mail, I get the object browser. Commands that are unique to the Mail application appear when you select the Mail “suite” of commands. Here you can clearly see that if you want to check for mail, you can use the command as shown in the window. This suggests the following script:

This simple script will launch the mail program if it isn’t already active, and check for new mail.

More AppleScript tools

One tool suggested in the AppleScript 1-2-3 book is an enhanced Applescript editor called Script Debugger 4.5. This includes a debugger, and a greatly enhanced dictionary explorer. Very nicely done. It sells for $199. (There is a time-limited demo available, as well as number of free tools on their website.) You can install it on both a laptop and a desktop, as long as only one license is in use at one time. This really seems to take the sting out Applescripting. I admit I haven’t gotten very far in my travels yet… I’ve got a maximum script length of about 40 lines so far. Still I’m not entirely sure what all the book reviewers were making such a fuss about.

Other than simple dialog boxes for a single variable, you can’t create much of an interface in AppleScript. For more complex interfaces, with the usual Apple buttons, windows, and menus, you can use the AppleScript Studio, which grafts AppleScript capability on to the standard “Cocoa” Apple interface using the Interface Builder and XCode tools. Thats a whole other can of worms.

The open source OpenOffice looks like an attractive alternative to Microsoft Office. But when you are collaborating with Microsoft Office users, can you keep up? According to this review, the answer is absolutely not.

I could go on quoting examples, but suffice to say that OpenOffice.org 3.1’s interoperability features were wholly inadequate. When the application thought it could successfully render an object, it often mangled it beyond recognition. When it became confused by, for example, an unfamiliar chart type or an unsupported configuration parameter, it simply discarded the extraneous data. It’s the kind of half-baked file format compatibility that keeps IT personnel awake at night.

Bottom line: OpenOffice.org 3.1 failed to deliver on its promise of better Microsoft Office interoperability. It severely mangled our Microsoft Word and Microsoft Excel test data files, and no amount of new features or targeted performance improvements could overcome this critical deficiency. Factor in OpenOffice’s other well-documented warts — buggy Java implementation, CPU-hogging auto-update system, quirky font rendering — and it’s easy to see why the vast majority of IT shops continue to reject this pretender to the Microsoft Office throne.