Scripting for Lawyers > Ruby

When we last discussed the Finder, we looked at the different elements that make up the Finder’s object model: disks, folders, and files. As you recall, each element may contain zero or more other elements and those elements have properties that we can access. For example, a disk element contains zero or more folders and those folders have a name property that we can access. We can also make new elements. Here’s a quick example:

tell application "Finder"
    make new folder with properties {name: "My Folder"}
end tell

Open Script Editor, type in this code, and press the “Run” button. You should see a new folder named “My Folder” on your desktop. You might use this code to generate a new folder when you open a new matter. Let’s take a closer look at the code.First, we include our tell statement to tell AppleScript that we want to boss around the Finder. Then we send the Finder a message, “Hey, Finder, make a new folder and name the folder ‘My Folder’”. To let the Finder know about our properties, we send the Finder a record of properties. A record is an unordered collection of labeled properties. Here, we set the labeled property, “name”, to “My Folder”. We could have set other properties, too. To discover what properties we can set, we need to look at the Finder’s Dictionary. Here’s the Dictionary entry for the folder element:

Whoa! There’s no properties listed! But the dictionary does list the elements—in the inheritance chain. Click on the word “container” to see the properties of containers:

OK, so we see a few properties, but several are not available and the others are designated as “r/o”. This means that the properties are “read-only” which means we only read the value of the property, can’t set it when we make something new. Let’s look further up the inheritance chain. Click on the word “item” in the first line of the dictionary entry:

Ah, here we go. Look at the first property listed. It’s our “name” property that we set when we told the Finder to create our new folder. If you wanted to set more properties, you would add the labeled properties to your record that you send to the Finder:

make new folder with properties {name: "My Folder", label index: 1}

In the next post, we’ll look at files.
(more…)

In my last post, I promised an example of a script that uses rb-appscript instead of AppleScript. Well, remember that screencast that showed how to add events to Timeline? I wrote that script in rb-appscript.  Click here for the script.

I chose Ruby for this script instead of AppleScript because Ruby processes text much more efficiently than AppleScript. In this example, I ask the user to choose a data file, then I use a third-party library (FasterCSV) to parse the data file line-by-line. For each line, I add an event to my timeline.

I also chose Ruby because the syntax is much more concise. To process text in AppleScript, you typically have to write several more lines of code than with Ruby or another language. This can lead to considerable time savings while developing a script.I note that this script is not complete. I need to add better error handling and I’d also like to check each line for data consistency. But for demonstration purposes, this script works.

I’d like to hear your comments about moving forward with Ruby or sticking with AppleScript as our scripting language of choice. I’ve heard from a few people and the vote is split. One advantage of sticking with AppleScript is the large amount of existing scripts floating out there for you to examine and learn from. Because rb-appscript is relatively new (but very mature as it’s built on top of Apple Events), the number of existing scripts is small compared to AppleScript. Just another thing to think about before we move forward. 

Before we continue with scripting the Finder, let’s step back and take a look at our code from our last example.

tell application "Finder"
     get name of disk 1
end tell

Apple describes AppleScript as a programming language with an English-like syntax. Most people forget the “-like” part, though, and forget that AppleScript code must adhere to strict rules or the code will not work. For example, if you write:

tell "Finder" to tell me the name of the first disk

AppleScript will raise an error. The syntax is close to valid, but not quite, and this can be the source of considerable frustration. What if, instead, we had a syntax like this?

app("Finder").disks.name.get

The syntax in this example is more concise, which means less typing and less room for errors, and it still makes sense: we tell the Finder to get the name of our disks. “But that’s not AppleScript!” I hear you cry. Well, yes and no. Let’s take a closer look at what goes on when we run our AppleScript code.

### Apple Events

When you click the Run button in Script Editor or press Command+R on your keyboard, your Mac takes your AppleScript code and translates the code into Apple Events which get sent to the target application. The target application then executes the Apple Events sent to it and, if asked, returns a result by sending back an Apple Event. In our example, we sent Apple Events to the Finder that asked for the name of the first disk and the Finder sent back an Apple Event to us that contained the name of the first disk. Your Mac keeps track of all of these Apple Events with the aptly-named Apple Events Manager. Apple Events are a subset of a larger framework called the Open Scripting Architecture.

### Open Scripting Architecture

Underneath the covers of AppleScript and Apple Events lies the Open Scripting Architecture, a framework that provides for interapplication communication. The Open Scripting Architecture defines standards for scripting components to facilitate this interapplication communication. Scripting components can be written for any programming language, of which AppleScript is one. You can see this component in /System/Library/Components. Thus, you do not need AppleScript to boss around your applications. You can use any language for which there is a component. There are few components available, but we’re not going to investigate them. Instead, we’re going to build a bridge.

#### Scripting Bridges

As we learned above, your Mac takes your AppleScript code and translates it to Apple Events before sending it to the target application. We also learned that AppleScript is simply a component of the Open Scripting Architecture and is not required to boss around our applications. If we wanted to use another programming language, we would need something like a component that would translate our code into Apple Events before sending it to the target application. We would need a scripting bridge and several exist. The code above is Ruby code and it works with a Ruby-to-Apple Event Manager bridge called rb-appscript.

### Ruby and rb-appscript

Ruby is an open source, object-oriented programming language created with a focus on simplicity and productivity. rb-appscript takes that simplicity and productivity and applies it to scripting your applications. By using rb-appscript, we get all of the advantages of Ruby combined with the ability to boss around our applications with Apple Events. Ruby has several advantages over AppleScript including, most importantly, a module for unit testing. And, as we saw earlier, Ruby syntax is more concise, which means less typing and less room for errors. Ruby also provides more third-party libraries of code, including the Web application framework named Rails, and Ruby has much better text processing capabilities than AppleScript. Books on Ruby are plenty and the documentation is much better than you will find for AppleScript. If you want to try it out in your browser, click here.

### Objections

Many people object to using Ruby (or any other programming language) for fear of using the Terminal application. Like most programming languages, you write your Ruby scripts in a text editor, then run the script from the command-line in the Terminal. What those people miss is that Script Editor acts as a terminal application, only it’s used specifically as a terminal for AppleScript. The fear of Terminal.app is misplaced. You can safely use it for your rb-appscripts just as you use Script Editor for AppleScript. By the way, you can write AppleScript scripts in a text editor, then run the script from the command-line in the Terminal using the “osascript” command. Or you can execute AppleScript code directly from the command-line using the same command. Try it out. Open Terminal and type: osascript -e 'say "Hello from AppleScript"'. Sound familiar?

### Conclusion

Because of the availability of other language syntaxes to boss around our applications, I thought now would be the time to introduce an alternative to the wordy, English-like AppleScript syntax. As an alternative, I chose Ruby because Ruby syntax is more concise and can be just as easy to read. Moreover, Ruby includes unit testing and access to a large variety of third-party libraries. I like Ruby and rb-appscript so much that I decided to convert all of my existing AppleScripts to rb-appscripts.

I’d like your feedback on whether or not we should continue to learn and write with AppleScript syntax or whether we should continue down our path with Ruby and rb-appscript. But before you decide, let me show you an example…in my next post.

Scripting for Lawyers is a weblog that will explore all facets of scripting. From learning about the various scripting languages to writing our own scripts to digging into the guts of the operating system, together we will attempt to understand the ways that our computers can make you more efficient, more productive, and more profitable.

As the name of this weblog suggests, I’ll focus on how lawyers, especially those lawyers who use Macs, can use scripts to boss around their applications and data. Although scripts often operate on their own, many scripts can be used in connection with databases, text editors, word processors, calendars, and e-mail applications. As such, we’ll also look at setting up a database and using scripts to push that data into the other applications. We’ll also explore how to access Web services to grab data to put into your application.

#### Why focus on lawyers?

Well, I’m a lawyer and I want to help other lawyers who are interested in scripting. Many lawyers are interested in scripting, but they either don’t have the time to learn scripting or they are intimidated by the geekspeak that they find when exploring this technology. Other lawyers simply don’t understand the power of learning a scripting language and want some examples of how they can incorporate scripting into their workflow.

#### What is scripting, exactly?

Scripting is the process of writing short computer programs that tell your computer to complete a task. In short, you write scripts to boss around your apps. In AppleScript, for example, you “tell” an application process text or save a file or schedule an event. You use scripts to create and enhance your workflows with your current applications. You do not need to code an entirely new application to meet your needs.

#### What do you know about scripting anyway?

I began using Macs in 1998. My first Mac was a green Rev. B iMac. One of my graphic design friends was working on a large [Photoshop](http://www.adobe.com/products/photoshop/index.html “Adobe Photoshop”) file and, while I looked on, dropped the file on to a folder. Suddenly, an application opened, resized and transformed the file, and closed the file. Another application then opened and transmitted the image to a remote database. I stood in amazement. When I asked how they did that, the reply mentioned [AppleScript](http://www.apple.com/applescript/ “Apple’s scripting language”), Apple’s built-in scripting language. Well, I had to try that out. So I went home and started scripting. In 1999, I began working in an all-Mac law firm. The law firm used [FileMaker Pro](http://www.filemaker.com “Apple subsidiary of database software”) to keep track of everything. After learning the workflow and toying with the databases, I began writing AppleScripts to integrate Filemaker Pro with other applications. I have been scripting ever since, only now I’ve learned several more languages and how to use those languages with more databases and applications.

#### So which scripting languages might we see?

The majority of scripts that I plan to show will feature AppleScript. I also plan to introduce you to [Ruby](http://www.ruby-lang.org/en/ “Ruby”), [F-Script](http://www.f-script.org “Smalltalk-like scripting language”), and [JavaScript](http://www.ecma-international.org/publications/standards/Ecma-262.htm “Used on the Web and Adobe Acrobat”). We may also dabble in [Python](http://www.python.org “Python”), [Perl](http://www.perl.org/ “Perl”), and [Smalltalk](http://www.smalltalk.org “Smalltalk”).

#### Wow. That’s quite a bit. What about databases?

I’ve found that most Mac-using lawyers use FileMaker Pro to store information about their cases, which is great because FileMaker has an excellent AppleScript implementation. As such, most of the posts will cover FileMaker Pro. However, I also plan to feature databases such as [OpenBase](http://www.openbase.com) and [SQLite](http://www.sqlite.org).

#### And applications?

Deadlines are very important to lawyers, so learning to script a calendar application will be shown. In this case, we’ll look at iCal. Of course, lawyers write lots of letters, so we’ll look at text editors like TextEdit and word processors like Microsoft Word. We’ll also learn how to script Mail and Safari. Finally, we’ll look at how to script specialty applications like [Bee Docs' Timeline](http://www.beedocs.com “Software for creating timelines”).

#### What if I need help?

That’s what this weblog is for! I want to make this weblog into a conversation where we learn from each other. If you need help that is specific to your situation, [I'm available for consultation](http://scriptingforlawyers.com/?page_id=7 “Find out about my services”).

Now let’s get scripting!