Did you know? You might have Phantom Code!

Did you know? When a Google Apps Script project containing multiple ‘files’ is run, the entire script is ‘loaded’ and run. That might include what I call Phantom Code: script content that you don’t intend to execute. This situation is more likely when you are using the recommended practice of separating your code into different gs files, each focused on a different concern.

Problems might show up as unexpected behaviours, or it might be benign but contribute to your script execution limits and slow your scripts.

PositionedImage Support introduced in Google Apps Script

Issue 1529, programmatic support of “Fixed Images”, has been fixed. As of December 2015, Google Apps Script can manipulate PositionedImage objects in Google Docs. Previously, we only had control over InlineImages via our scripts, so this is good news.

There are some hiccups with the introduction of this new feature, though, so this article aims to help programmers get quickly acquainted with it.

Note: This post is information I have concurrently posted on Stack Overflow.

Debugging external host communication with UrlFetchApp

There is a large and growing number of Web APIs available out there, many of which can extend our ability to obtain information or automate workflows from our Google Apps Scripts. Using the URL Fetch Service is a little more challenging than the majority of the services provided by Google, and when things don’t work it can be significantly more difficult to figure out than those services.

We’re going to look at debugging techniques unique to the UrlFetchApp today. For people unfamiliar with HTTP’s arcane messages and responses, we’ll get an overview that should help unlock this powerful capability.

Did you know? (It’s worthwhile including attribution for code snippets!)

I believe that everyone who writes software of any size will reuse code written by someone else at some time. I’m talking about referring to a library or API, but to copy & paste reuse; fully adopting someone else’s source code. Further, I believe that there are lots of great reasons to do so. Developers are quite used to performing internet searches or using dedicated code repositories to locate candidate code snippets that they will import into their projects in whole or part, and possibly modify to their own purpose.

Much of the code you’ll find this way is freely available (it will cost you no money), but may have additional licensing requirements that you should be aware of and conform to. One of the most common requirements is attribution.

attribution (noun) The act of attributing, especially the act of establishing a particular person as the creator of a work of art.^ref

In today’s entry, I’m going to make a case for including proper attribution for all the third-party code we reuse, and suggest a consistent way to do so. My examples will focus on Google Apps Script, but this can apply to any programming language.

Did you know? (You can log to a spreadsheet from client JavaScript!)

Google Apps Script has a Logger class, intended to help debug by enabling you to log the operation of your code, and examine run-time data. Viewing those logs is supported through the View > Logs menu option in the Google Apps Script editor.

Unfortunately, the built-in Logger doesn’t work in every situation. A requirement is that you must be running your script with an attached editor / debugger session, so that precludes logging trigger functions (when reacting to actual events), and many asynchronous operations such as UI interactions. If you want to compare results between sessions, you’ll be frustrated to find the output of the Logger is transient – the next time your script is executed, all previous logs are lost.

Today’s post is a quick tip for generating persistent logs from your whole application, including client-side JavaScript running in a user’s browser, such as an add-on sidebar or dialog, menu-driven functions, and autonomous functions such as triggers. Custom functions are not permitted to modify spreadsheet contents directly, so they are the one exception for this technique.

Converting from UiApp + Chart Service to Html Service + Google Visualization API

In July 2012 Roee Eilat and Eric Koleda, respectively members of the Google Charts and Apps Script Teams, published a popular tutorial: “Building a Charts Dashboard”. Later, in December 2014, Google deprecated the UI Service that supports Charts – while strangely not deprecating the Charts Service itself. That’s left some confusion for developers.

For users of Google Apps Script, there are two alternatives for visualizing data:

1. Continue using Charts + UiApp. While deprecated and not supported for auto-completion in the editor, UiApp still works. There has been no announcement that it will actually be shut down… yet.
2. Follow Google’s recommendation, and use HtmlService instead. A feature request to have Charts supported by the HtmlService has been declined. So this seemingly-simple recommendation entails the additional requirement that you use Google’s other Charts offering, also known as the Google Visualization API, or GViz.

In today’s post, I will show you how to convert the old dashboard example from from UiApp + Chart Service to HtmlService + Google Visualization API. For those willing to geek out with me, there’s even an introduction to System Architecture.

Did you know? (Custom Functions in Google Apps Script)

In Google Apps Script, Custom Functions are special. They have limitations that other script functions don’t, but to compensate, they have been given awesome powers! Ok, that’s a bit strong – let’s say they have unique capabilities that aren’t immediately obvious.

You can learn most of what you need to know to write your own Custom Functions by reading Google’s documentation. But did you know…

• You can craft effective auto-completion help with comments in your Custom Functions?
• Your Custom Functions can present customized error messages for users?
• Custom Functions can support an arbitrary number of parameters?

Today’s blog might have some surprises for you, if you thought you knew everything about writing Custom Functions.

StackOverflow Lost & Found, part 2

In part 1, we introduced the idea of strong and weak tags on StackOverflow, and offered some advice for posting questions that get attention from the experts you’re looking for.

Lost Questions

And that brings us to Lost Questions. StackOverflow experts typically focus their efforts on a narrow set of tags, expecting that people looking for their help will categorize them appropriately. Questions on a strong topic that are not tagged with that topic’s primary tag are “Lost”.

StackOverflow Lost & Found, part 1

I love answering questions about Google Apps Script on StackOverflow.com! As of this morning, I’ve made 792 posts on the google-apps-script tag, by far my most active tag. A large number of the questions I’ve answered came through what I call a “Lost & Found” activity – and so have many more that I’ve edited and left for others in the community to answer.

Read on to learn what causes a question to be Lost in the first place, what you can do to Find them, and how that can benefit you in terms of SO reputation gain and food for your soul or Karma.