October 31, 2007

appscript’s get syntax

Filed under: General Information — Ryan Wilcox @ 11:26 am

I use appscript – a Python module letting me talk to scriptable applications on the Mac – everywhere I can. It means I can write less in the verbose, cranky, sometimes read-only AppleScript.

Appscript is nice, but in earlier versions seemed very… verbose. Where AppleScript did all kinds of magic behind the scenes, appscript made you do a lot of that stuff yourself.

Today I was working on getting an object’s reference’s value from appscript. In Applescript this is easy:


tell app "Microsoft Word" to get selection's selection start

(Maybe Word isn’t the best example of this, but it’s what I’m working in now…)

In appscript I’ve always struggled with how to get and set values in appscript. Not today, since I’ve discovered there are three ways of doing it (shown here from the Python Interpreter, one of the great tools for appscript: piece together things line by line interactively!)


>>> msw = app("Microsoft Word")
>>> msw.selection.selection_start.get()
48
>>> msw.selection.selection_start()
48
>>> msw.get( msw.selection.selection_start )
48

The first get() call is the one I’ve been using since early in appscript’s development. Entire reference (the subject), than the verb. It’s very OOP smelling, OBJECT then VERB. You see this everywhere, including Python.

The second get() call is one I didn’t know about until I read the appscript manual just today: once you have a reference, call it like a function and you’ll get its value. That’s a great shortcut, and feels somewhat OOP too.

The third get() call is one I just discovered, and probably the most familiar to AppleScript programmers. Much of Applescript works on VERB then OBJECT, because it could be considered not a class based object oriented programming language. So here we are: GET the selection object’s selection start).

It’ll be a toss-up for me whither I’ll use the second or the third form of the “get idiom”, but I’ve always found the first to be too literal, personally. I’m glad there are other forms.

Oh, and PS: appscript has had addressing by creator code, bundle identifier, path, as well as name and eppc URL since very early in its development. Thanks for catching up, Applescript. <nudge />

October 17, 2007

Betas and Testing

Filed under: General Information — Ryan Wilcox @ 1:45 pm

Steven Frank: Betas and Testing

Lots of truth in the article, from both ends (running a beta cycle, being in QA, and also giving some advice to people in a beta testing program. My advice for the latter group would be: test, let people know that you’re testing, even if you haven’t found any problems in the areas you’ve explored. Basically, let the people running the beta cycle that you’ve gone fishing in this part of the application and haven’t caught anything.)

But I have to point this out:

I’ve researched automated testing with products like Eggplant, with mixed results. I’m a big advocate of unit testing, but in practice, it always seems to get back-burnered, and is not easy enough to do with predominantly GUI-driven applications.

You can have all the unit tests in the world, but if the logic connecting your view component to everything else doesn’t work, the program doesn’t work. I know this point all too well. So testing (internal QA and beta testing) are very useful.

The beta testing being a check on internal QA: making sure the internal QA does its job well, and also going above internal QA, trying oddball stuff that internal QA wouldn’t think of. When you work with a product day in and day out it’s easy to test and use the app only the way that makes sense to you – or to the development group – but people may use the app differently in the real world. People will zig when you are expecting them to zag. Which is also why you need beta testers, even if you have automated tests.