Towards a local, testable, debuggable GAS scripting environment

Okay, so since Friday afternoon I’ve been playing with the very very interesting Google Apps Scripting (GAS), just because it was sitting there and I didn’t understand any of it, and I definitely saw its potential.

Then I went to a GAFE summit conference (I’m an ESL teacher by day) and saw what cool stuff cool people were doing, and I figured it was worth a bit of digging around. So I made a script. It was a pretty simple one, it took info out from an API and added rows in a sheet.

It took me three days to write. I blamed the development environment. I asked the author of the insanely great and probably insanely-difficult-to-maintain Docopus, if there was any legitimate options out there that allowed unit tests and proper debugging.

So I set out to figure out A Better Way. I hated that I had to click on a play button and not see immediate logs from my running program. I’m used to writing python code and seeing results immediately, no waiting around. Maybe it was because I am an amateur JS coder. Whatever. I hated it.

First of all, GAS scripting at the moment, as it is now, from within the browser feels a tick more mature than GUI scripting with AppleScript. Have you ever tried GUI Scripting with AppleScript? Just don’t. It’s a horrible environment, filled with traps and pitfalls. There’s like three guys in the world that do it all the time, and they know everything, and they dominate the help-focused mailing lists, okay so I’m exaggerating, but not all that much.

Okay so there’s no “second of all.” Anyway, so I sought out to figure out a way where I could code up things in JavaScript on my local machine, not on the browser, and when I was done could copy and paste the script. I’ll leave the problem of git-like push/pull for a later date.

Here it is:

You can install node.js and use its require() function in which you define dummy objects that have the same name as those that you use in the GAS API, such as Logger, and define methods that do the terminal equivalent. So that Logger object’s log method would just call console.log. So a Spreadsheets object whose getActiveSpreadsheet method returns a Sheets object which is just a fancy container for an array. That Sheets object’s appendRow() function just pushes to the contained array structure. Simple as.

This will also allow unit testing and other nice things, because making dummy data that just tests integrity of the logic and the assumptions relatively painless. And since you are on the local machine, typing is fast 🙂 Also, since you’re using node.js, you have full access to a completely functional command-driven debugger.

Fascinating, is that in “pure” javascript there’s no way to include files, because that’s usually done through the html layer. And if javascript was ever going to grow up and be a Modern Programming Language it would have to solve that hiccup. Nice to see that node.js has.

Now. Not sure how this will scale for scripts that use all sorts of GAS API objects. I reckon it wouldn’t be too much fun to have to make new ones for each project, but this has to be better than waiting around for a Google Doc to open just so I can click on Script Editor just so I can choose the play button and wait 10 seconds to launch, and wait for it to finish before I see any log items.

Also. It’s not strictly copy-n-paste because you still need some variable assignment boilerplate, but the define function removes the vast majority of the magical “on-the-local-machine-only” code away from that blasted browser.

Comments are closed.