I purchased Google Script: Enterprise Application Essentials By James Ferreira via O’Reilly’s excellent Deals of the Day scheme, whereby they offer an eBook each day at 50% off of their already very reasonable prices. I often find this an excellent opportunity to pick up books on topics that I’m interested in but might not have been willing to pay full price for. There were no reviews yet, but it seemed that for $12, even if all I got out of it was a few gmail and doc tricks, it would still be well worth it!
The book is divided into three parts: Understanding Google Script, Building Enterprise Applications and UI Element Examples (which is really just the Appendix). This review covers Part I, with a subsequent post to cover the remainder. In addition to reviewing the book itself, this is also partially a review of the Google Script platform. One of the most impressive facets of the system is the time required to set up a development environment. It’s as simple as selecting Script Editor from the Tools menu within a Google Spreadsheet! One click, and you have in front of you a cloud-based IDE with autocomplete*, keyboard shortcuts (e.g. Ctrl+’/’ to toggle comments for a selected block of code), and even a GUI Builder! No local install, no server setup, no uploading files – it’s ready to go with a single click! Built-in revision history too!
*in fairness, perhaps more a “sorta-complete” e.g. you only seem to get functions after typing an entire object’s name, and there is no attempt to predict existing variable names as you type etc.
The voice of the book is casual – perhaps almost too conversational[1] – I don’t really expect use of the first person in this type of book – and it wasn’t used frequently enough to become an expected quirk. Forgiving the occasional lapse into first person, I had to groan on page 30 when a discussion of child elements devolved into “Some of the buttons are aunts and there may be at least one second cousin. Is this way too confusing?” which just struck me as goofy and not worth the effort if an attempt to inject humor.
The lack of Errata is perhaps understandable, given that the book was released in January, but the number of issues I discovered was rather shocking of an O’Reilly book. [update: Errata appear to have been published as of mid-February] The instructions do not always match the actual steps required, which is understandable since google Apps may well have evolved since the time of writing (though the book only came out a few weeks ago) – e.g. there were often references to creating a new file and then saving at the end after code has been added etc. – whereas in my experience the file name was required up-front on creation. This I can of course forgive, but there were a fair number of further inaccuracies and downright mistakes that undermined my confidence in the book significantly. It started with minor things[2] – what really seemed unforgivable, though, was the use of the variable names application and app interchangeably throughout the examples, when clearly for the code to function, one or the other name must be selected. For example, on page 7, “var application” is used in the example code, while the subsequent page suggests “app.createLabel()” and “app.add()” be inserted into a previous placeholder – which of course will not work. This mistake is repeated on page 11, and on page 14 it even occurs within a single block of code:
var application = UiApp.createApplication();
app.add(app.loadComponent("MyGui")); // name of the saved Gui
return application;
Hilariously, page 24 comments ”In this book, the UI instance of UiApp will almost always be referred to as app.” – if only this were the case! The mistake was immediately clear to me as I typed, but the preface suggests “You don’t have to be a webmaster or programmer to grasp the concepts in this book.” – I fear that a novice with no JavaScript experience, blindly following this book as their only guide, might quickly run into problems here.
Regardless, the first part of the book provided some interesting exercises – for example, the notion of logging caught errors to a spreadsheet, and the simplicity with which it can be accomplished:
}catch(error){
var errorSheet = SpreadsheetApp.openById(‘<YourSpreadsheetIdGoesHere>’).getSheetByName(‘errors’);
var cell = errorSheet.getRange(‘A1′).offset(errorSheet.getLastRow(),0);
cell.setValue(“function doGet: ” + error);
}
made me smile (comparing this to e.g. accessing an Excel object via .NET and wrangling permissions on the server to the point where the file could be written etc. – not that this would be a particularly desirable scenario vs. just writing to a database, but…). The subsequent Contact form example with full UI, validation, and storage of the collected values in a spreadsheet was a good demonstration of what can be accomplished in Google Script with impressively few lines of code. Yet another sizable mistake could be found in this example: the info element in contactMe() function on page 35 needs to have .setVisible(true) added since it is .setVisible(false) in doGet() – this bug likely sneaked through due to the element being made visible by the validation function – but if there is no validation failure prior to a successful submission, info remains hidden with the code as written.
I am still excited by many of the topics in Part II: Building Enterprise Applications, but the sheer number of mistakes in the first part of this book have somewhat dampened my enthusiasm – and these are just the findings of a novice on the topic – I worry about the quality of subsequent code and the strength of suggested practices based on the faults I was able to find so far. Yet I will continue to push on, and will share the results in my subsequent post on this topic. Regardless of any issues with the book, Google Script is clearly a powerful and exciting platform, and I look forward to automating all sorts of tasks, as well as mashing Docs with all kinds of other services!
Notes
- ^ at points I found for example first person references like ”While I present these differences of the two UiApp styles as hurdles,” on page 10 and “but I think it is important for you to see how everything is written out” on p25 almost jarring
- ^ on page 8 for example the claim is made that ”you will see an empty UI window with the title ‘Hello World’ at the top” – yet this is inaccurate since the corresponding code says ‘Your Title’ - so whether you substituted your own text or went for the literal, it’s unlikely to match “Hello World” unless you somehow selected this as your own title based via some sort of premonition
