Apps Script Crash Course – Script Editor


CARRIE ROWE: Camera
adds 10 pounds. ARUN NAGARAJAN: Camera
does add 10 pounds. KALYAN REDDY: Perspective. You are closer. ARUN NAGARAJAN: That too. We’ll let you do another
one where you can have your own shot. [MUSIC PLAYING] ARUN NAGARAJAN: Welcome to
“Developers Live.” My name is Arun Nagarajan, and we’re
here live from the New York studios. Today’s topic is “Apps Script
Crash Course and the Script Editor.” We’re going to focus
a lot on the Script Editor. But before I get started, I
want to introduce other presenters. KALYAN REDDY: Hey, everyone. My name is Kalyan Reddy. I usually do the Apps Unscripted
series, but today, I’m going to give you some neat
tips and tricks on using the Script Editor and maximizing
productivity there. And as you might know, most of
us on the apps script team work out of the New
York office here. But today, we have a special
guest on our team from the Mountain View office. I’ll let her introduce
herself. CARRIE ROWE: Thanks, Kalyan. I’m Carrie Rowe. I’m a program manager on the
apps dev rel team, and I work with these guys. I’m really excited to sit out
here with them and hear more about what they do. And my job is to help make
developers successful, so implementing programs to help
reach out to you guys and communicate to you about
our products and get your feedback. So if you guys have any ideas
about how we can better interact with you, please post
on the community page or reach out to me on Google+. I’d love to hear
your feedback. ARUN NAGARAJAN: That’s right. That’s really important
feedback. “Google Developers Live” itself
is a program, so– CARRIE ROWE: Yes. ARUN NAGARAJAN: –that’s why
she’s on it, promoting it. So let’s get started. So the Apps Crash Course series
is all about taking one aspect of writing Apps Script
apps and just going really deep into it. So even if you’re a programmer
that’s been working with Apps Script for a couple of years
now, we hope that you’ll have something that you can take
away from this series, but it’s more focused around just
from the ground up explain a lot of the capabilities of
a particular feature. And today, it’s all about
the Script Editor. Should we get started? All right. So the very first thing that
we’ll talk about is how do you get to the Script Editor. So obviously, I think the
easiest to remember URL in the world is script.google.com, real
easy to remember, real easy to type. It brings you the Script
Editor directly. So when I say Script Editor,
just so everybody is on the same page, it’s the IDE, the
Integrated Development Environment where you’ll write
and run your scripts from. So that’s one of the
easiest ways to get to the Script Editor. We also have the ability to
inject the Create Script option within Google Drive. So this actually is a pretty
nice thing that you can do. So right now, if you click on
the Create menu, you have the native Google Apps formats
available and then any third-party apps you
can install. We have Google Apps Script
available as an app which you can install as well. So what you can do is say
Connect Apps to Drive and search for Apps Script,
and search for that. And that should– hopefully, the
Wi-Fi catches up here, and that should bring back an Apps
Script app that I can hit Connect on. And that will install a new
option under your Create menu for Script. So I like to use this, because
it’s actually a really nice way to put a script in
a particular folder. So if you’re within a folder
already where you keep your scripts, and you create a script
within that, it’ll be managed properly. So let’s go with this route, and
that, again, brought us to the Script Editor. And in fact, you can see in the
URL that the folder ID is specified, so you know
it’s working. That’s great. So let me talk a little
bit about the Script Editor itself. So the very first thing that you
see when the Script Editor comes up is the Welcome
screen. I know a lot of you probably
turn this off, but I do find this useful in some scenarios
where if I have a recent project that I want to
immediately open up, or if I like to use a template. So on the left-hand side, is the
set of templates that we have to help you get started. So this doesn’t change the type
of script or create any property changes about
the code itself. All it does is it seeds your
Script Editor with a bunch of useful snippets that we think
will help you get started. So if I, for instance, select
the Calendar template, all that’s doing is it’s going to
create the project that we already have and populate it
with a bunch of code that we think will be useful for you. KALYAN REDDY: Right. Like every script isn’t like
this is a Calendar script. This is a Drive script. It’s not like that. You could have permissions
granted based on what services you’re using on a script basis,
but this just seeds the code into the Script Editor. ARUN NAGARAJAN: That’s right. Yeah. So as you probably know, most of
the impressive scripts that are out there oftentimes
use Calendar along with spreadsheet data, along with a
file in Drive or something along those lines. So in this case, we’re just
giving you a bunch of code that if you’re not interested in
reading the documentation, you can start looking at some
samples and get going. Excuse me. So let me show one last thing,
and then I’ll talk to you about the next set of
things we’ll show. So in Drive itself, one of
things you can do is once you’ve created a script, you can
go into the Settings, go to Manage Apps, and you’re able
to actually filter all your scripts by going to Google
Apps Script from the Manage App option and then say,
view all the files this app created. This allows you to see all the
scripts very quickly, so it’s a really nice way to kind of
filter and look at all your scripts in a simple search. And then I’ll also do a quick
walk through of all the different options within
the Script Editor. So we’ve actually done a really
nice job, I think, to make the Script Editor feel
familiar to other editors you may have worked in. Obviously, it’s still running
in a browser, so it’s very portable, and it’s meant to be
lightweight and quick, but we’re still trying to make
it very familiar. So you have your standard File,
Edit menu where you can kind of do basic things around
the file in the project You have the list of
files on the left. You cannot have more than one
file with the same name, so we take care of that kind
of validation here. And then you can actually have
multiple tabs open which is great when you’re writing a
fairly sophisticated program. And then these are your standard
Formatting, and Deployment, and Debugging
options, so being able to indent, unindent,
save the file. This is a deployment option
to the web as a web app. These are triggers. We’ll get to that in a second. And then these are the debugging
and the running icons, so you’ll end up
using that a lot. And this is the list of
functions that we have parsed out from your code that
you can execute. So that’s sort of the
very quick overview of the Script Editor. Now, I think Kalyan is going
to take over and talk about one of his favorite features. KALYAN REDDY: Yeah. So if you’re anything like me,
you hate taking your hands away from a keyword, because it
just wastes so much time. CARRIE ROWE: Spoken like
a true engineer. KALYAN REDDY: Yeah. Exactly. It wastes so much time– grabbing the mouse and trying to
use the UI to do something that you know is there, and you
just want to get to it. So I have a couple of handy
shortcuts that I use on a day-to-day basis when
I’m writing scripts. So maybe if you don’t know, you
might find these useful. The first thing is actually Auto
Complete, which is the most handy shortcut, I think,
anyone likes here. So basically, you can
see it in here. It’s Content Assist, but in
action you can see it. Let’s say we have Calendar app,
Get Calendar by ID here. If you want to do something else
with Calendar app, you can actually just get to it
by doing that shortcut combination, Control-Space, and
then you have all of these choices, which are our top-level
services that you can interact with using
App Script. ARUN NAGARAJAN: This is a great
way to just keep up with what are our available
services. KALYAN REDDY: Right. I haven’t typed anything yet,
but you already get this list. So then let’s go type C for
Calendar right there, and then you can complete that when you
press the dot, you get a sub menu drilling into that
top-level service. And you can say– let’s say I want to create a
calendar, and then you can give it some name. So very easily without doing
anything, without remembering, without going to our
developer pages and looking at the function. ARUN NAGARAJAN: Even though our
developer pages are great I think this is– KALYAN REDDY: Oh, yeah. Right. ARUN NAGARAJAN: –I think
this is a really nice way to write code. KALYAN REDDY: Exactly. Let’s see. After that, let’s get into some
keyboard shortcuts that you might not know. So one shortcut is– let’s name it something. I love calling things
test script. ARUN NAGARAJAN: You just
defined those, right? KALYAN REDDY: I have a billion
test scripts in my drive right now, and I have no idea what
any of the old ones do. OK. So let’s see, what are
some of my favorites? The one thing that I love
is, I write some code. I save it. I just want to see
what it does. It’s the run. All right? ARUN NAGARAJAN: There’s another
one here with some code that you can run quickly. KALYAN REDDY: There we go. So this is good code
that we can show. Let’s say we want to run a
Processinbox function. I select it. I make some edits here,
whatever, save it. So if you’re using a Mac, it’s
Command-R. If you’re for using anything else, it’s Control-R.
So that does not reload the page like the behavior is in
just a regular web browser for other websites, but it actually
runs the function that’s currently selected within
this function box here. And as you can see, the yellow
bar came up saying the function was run. In conjunction with this,
another useful chain command is Command-Enter or
Control-Enter, if you use other IDEs. And this brings up the
logging output. So what I usually do is I do
Control-R, Control-Enter and then quickly see what’s
there to log. So actually, if you want to
chain that even more, Command-S to save it. As you know, this is the
same for other things. ARUN NAGARAJAN: So you’re
saying, you’ll write code. You’ll use Auto Complete
to write your code. KALYAN REDDY: Exactly. ARUN NAGARAJAN: Command-S.
Command-R. Command-Enter. KALYAN REDDY: Command-Enter. CARRIE ROWE: All of this is part
of the quest to become an App Script Jedi master. KALYAN REDDY: Exactly. ARUN NAGARAJAN: Well, just
in general doing more– CARRIE ROWE: Slash impress
your friends. ARUN NAGARAJAN: Yes. KALYAN REDDY: Yes. I talk about this at parties. So anyway, you see this
logging output here. We’ll get into explicit details
of logging later. But this is generally
how you can get to the log very quickly. OK. Another feature that we have,
you might have noticed this, but Arun mentioned it
briefly just before. It’s the Auto Indent feature. So if you have it turned on,
then you might notice that you can’t press the Tab key to
indent things like normal, because it’s handling
this for you. And if you add something else,
it’ll automatically indent it starting at the same spot. If you turn that
off, you can– well, let me show some
other behavior here. Well, let’s try some
real code here. Var x equals 2, let’s say. If you want to fix that quickly,
you just make a selection and press Tab. And then it’ll make
your code pretty. ARUN NAGARAJAN: And I find that
when I’m copy/pasting samples or code from another
place, I end up needing that a lot. KALYAN REDDY: It’s all messed
up, so you do Command-A or Control-A, Select All, and then
just do Tab to fix that. Now, if you don’t use this Auto
Indent, if you have that turned off, the behavior
is slightly different. So when you do have something
like this that you want to fix, you have to do Shift-Tab
to fix it. So instead of just Tab, you have
to do Shift-Tab, because otherwise, you can use Tab just
to do regular indents. ARUN NAGARAJAN: So
what do you have? Do you have– KALYAN REDDY: I don’t use
the Auto Indenter. ARUN NAGARAJAN: You don’t? KALYAN REDDY: No. ARUN NAGARAJAN: Wow. KALYAN REDDY: I just like, if
I need to indent something, Control-A, Shift-Tab. It’s quick enough. The next thing is for variables
that you’ve defined earlier in your code. A useful way to complete this
here, here we have Logger.log, thread.count. Let’s say we want to do that
easily, we went and defined thread count earlier on. You can do thread and then– So Alt forward slash is a
shortcut to do completions from your code. So as I keep clicking it, it
keeps iterating through everything you’ve defined. You’ve defined thread
ID earlier. You’ve defined thread
count, threads. Its iterating though all of
these that you’ve designed, so you can quickly do it. ARUN NAGARAJAN: So you no longer
need to decide between short names that
are easier type versus descriptive names– KALYAN REDDY: Exactly. ARUN NAGARAJAN: –that
are easy to read. KALYAN REDDY: So it’s actually
good programming practice to not name everything XYZ. You can actually give them
descriptive names. And so even if your name has
like four words camel cased together, you can quickly just
get to that and have people who are sharing the script with
you and managing it in the future, have them
understand it. ARUN NAGARAJAN: And what
was the shortcut again? It was Alt? KALYAN REDDY: So Alt
forward slash. ARUN NAGARAJAN: Alt
forward slash. And is this one of the ones
we list in the menu? KALYAN REDDY: This is. So if you go to the Edit menu,
if you ever forget– ARUN NAGARAJAN: This is– KALYAN REDDY: Word completion. ARUN NAGARAJAN: Word
completion. KALYAN REDDY: Is what
it is here. ARUN NAGARAJAN: All right. And Content assist is our
content, our APIs. KALYAN REDDY: Exactly. And another really, really handy
one is let’s say you want to quickly comment a line
of code, you can do Control forward slash, and then you can
automatically toggle the comments on and off. And this is also listed
in the Edit menu here in Toggle comment. ARUN NAGARAJAN: And where does
your cursor have to be, anywhere in that line? KALYAN REDDY: Anywhere
on the line is fine. And if you have a multiple line,
selection like I have three lines here, you can do
the same comment all of the lines are– ARUN NAGARAJAN: That’s
a good trick. KALYAN REDDY: –done. Yeah. ARUN NAGARAJAN: That’s even
faster than using the multi-line comments, I think. Because you have to
move your mouse. KALYAN REDDY: Yeah. Exactly. You have to create new line up
there, down there slash star. ARUN NAGARAJAN: No wonder
you’re always typing faster than me. KALYAN REDDY: Exactly. You’ve got to know all
these things, man. Let’s see, another feature
that’s very common to other IDEs is the undo/redo
functionality. So if you do Command-Z on
the Mac, you can undo. Command-Y is redo. Control-Z, Control-Y
I believe– ARUN NAGARAJAN: All of this
works on a Chromebook. KALYAN REDDY: Yeah. It works on everything. The actual shortcut,
the modifier key might be different. It’s Command on a Mac, but if
you go to the Edit menu, you can see what– ARUN NAGARAJAN: Will show
the correct one. KALYAN REDDY: –the actual
modifier is. Right. So it’ll be adjusted
for your system. And also, this, like Arun
said, is meant to be lightweight so we can
write some great scripts really quickly. But we do want to add some
functionality that’s missing from other IDEs, like Eclipse,
that you might use, or even more older ones like Vim. I don’t want to get there. I love using Vim. So you know, if there’s some
functionality that you want us to add like some new keyboard
shortcuts, then please put a feature request on our issue
tracker, and we’ll enter that in the system. And if enough people like
it, we’ll definitely be introducing that into
the Script Editor. ARUN NAGARAJAN: Great. Thank you very much for that. So now, what we’ve done so far
is given you tips, tricks to allow you to write your
code really fast. Now, the time has come to run
the script and find out what you’ve screwed up, right? So that’s where this feature
called the debugger comes in. So debugger is a concept that
a lot of you that have programmed on other platforms
would be very familiar with. It’s where you could run your
code and pause the execution, and then inspect the state
and variables, and then potentially run it a little bit
more, pause it again, and compare things. So the debugger gives you this
deep insight into the execution of the program. And even though Google Apps
Script is a cloud-based, scripting language, we’ve
given you the debugger capability that runs
within the browser. So that’s actually pretty
incredible to see. So let’s see a quick
demo of this. So I’ll use the same function
here called the Processinbox, which is on a test inbox. It’s just going to iterate
through all my inbox threads and log the messages, the
first message subject. So let’s say what if I want
to ensure that this– let’s say something is breaking
at about the 10th thread or something
along those lines. What I can do instead of hitting
the Run command, which Kalyan was using Command-R, I
could hit this little bug symbol, the universal
symbol for bug. I’m sure like in the next 10
years, this is going to get archaic, but we’re still using
floppy disks and bugs for important metaphors,
so that’s great. So I’ll hit the Debug button. And what happens now is, instead
of the function just running in the regular mode, it
runs it in a special mode, which is the Debug mode. So what happened here, and you
can see that the line that I clicked on was highlighted,
and it pauses execution. I forgot to show you. You can just hit the gutter on
the left-hand panel, and it turns on a red dot next to the
line you want to break on. That’s the word, break point. And there we have it. So what it essentially did
here is, it paused the execution of the code you
wrote on the Google data centers and returned back the
state your application is in. So you can see that the
variables that you have here are threads, and msg, and i,
which is the incrementer for the loop itself. So let’s just take a look. I’m going to hit the
Step Over function, which is the continue. When I hit that, it’s going to
go back and start running the loop again, because we are
now in the second item. So you can actually kind of walk
through and you watch the line of code being
highlighted. This is actually pretty
impressive when you think about what kind of capability
this gives you. So you’re able to essentially
run the code interactively from the Script Editor itself. And it’s really nice to be
able to say, OK now, i is incrementing appropriately, and
for a complex app, that may have multiple call stack
items on the left. This becomes really powerful
to observe and inspect. KALYAN REDDY: Now, I don’t know
if you all caught that at home, but you can see here in
the fourth line here that i is of type number and then value
is in the third column. It was 0 in the first iteration
of the loop, because you started it at 0, and then it
became 1 when Arun went to the next generation
of the loop. ARUN NAGARAJAN: That’s right. And if you don’t want to walk
through every line, you could just hit Continue Debugging, and
that will go to the next time the break point get hit. So it will come back and now you
can see that my message is now it says, Add a
profile photo. So that’s the message
it’s picking up. And you could also look
at a collection. In this case an array has Gmail
thread objects in it. You can see that’s not very
useful in that hover we have here, but those are the things
that you’re able to really see pretty easily. And I end up using this quite
frequently because I think this is a lot more powerful
than just logging things. This can allow you to take a
look at all the different objects in it as well. So if you have a string value
that you can really inspect that pretty quickly. Cool. So that’s the basics
of the debugger. I definitely urge you guys to
take a look at these options to stop, and you can actually
dive into a function as well. So if you’re just making a
function call that you’ve written, you can use this option
which is Step In, to go into your custom function. And there are some ways to do
the inheritance and all the expanded objects in the
collection as well. The stopping and pausing,
stopping really just stops execution, so now we’re done. So we just iterated through
two items, and we decided to stop. So it’s a nice way to– you can figure it out. If you know where the issue
is, you don’t need to wait till the app finishes for you
to start fixing the bug. You can just stop it and
write it right there. KALYAN REDDY: Right. And sometimes later on
you, might be like gmailapp.sendmail. If you don’t want to run
all of those, you can just exit early. ARUN NAGARAJAN: Yeah. Absolutely. And so it’s kind of a powerful
tool that we end up using quite a bit to troubleshoot
our own code. So we hope to have
you guys use it. CARRIE ROWE: You guys
don’t write code perfectly the first time? ARUN NAGARAJAN: Unfortunately,
not. KALYAN REDDY: I do. I don’t know about everyone. ARUN NAGARAJAN: It’s all the
keyboard shortcuts, I assume. Now, this is great when, in
fact, you’ve written an app that you are launching and
running for the Script Editor. However, there are several
cases where your code is invoked asynchronously,
either from an event or from a web app. So in those scenarios, for the
time being, you can’t attach to that process and break a
particular line at this point. So what you end up needing to
do is you create a little wrapper function where you
essentially mock the invocation. So these mock objects allow you
to control the debugging experience like you
would normally. So let’s take a look at
why you’d want that. So for instance, let’s say I
have published this web app. Go to Manage Versions. I already have one, I guess. And then I’m going
to say, Deploy. Wi-Fi is being a little
slow here. We’re going to deploy
this version. And as you can imagine, there’s
a doGet function that’s just returning a very
simple output that’s the message for the given index. So let’s open up a new tab
here, and go there. It’s probably going to throw
an error of Undefined. So I’ll say, ?Index
equal to 2. KALYAN REDDY: So this is
you passing parameters. ARUN NAGARAJAN: Yeah. So think of this as a very
simple web app, and I’m passing in a parameter. And now let’s say that, for
instance, something breaks when index is 10 again. Something is not working
correctly, and we want to debug it. So in order to debug this when
you come back to the Script Editor, the way you were able to
debug doGet function is you have to sort of write a wrapper
function from which you’re launching doGet with the
parameters packaged up as an object yourself. So it’s a bit of a hand-held
process to create that object, but it’s something that I think
will really help you when you understand that, OK,
so it’s the same object that comes in from the invocation and
the web app in a browser or another device. So this is what we’ll do
instead, and let’s say we want to debug this. I can put a break point now here
for message, and I will use testDoGet as
my invocation. And when I hit the
Debug sign– zoom out a little bit. Click on the bug again. Resize it appropriately. And you can see that now I have
my break point in doGet with the appropriate
parameter. So that’s one of the really nice
ways that you can debug even asynchronous invocations by
creating these test harness mock functions that allow you
to pretend as if your application is being invoked. Now, it’s not just web apps. There’s also tons of triggers
and events we expose, things like onOpen, onEdit,
even Google Forms. We launch a lot more
events now. KALYAN REDDY: OnFormSubmit. ARUN NAGARAJAN: OnFormSubmit. Yep. And you can see that this
list is quite large. So there’s a page in our
documentation for understanding events,
and you can see that under Events and Triggers. And you can see quite a number
of items that we’ve listed there, and we actually document
to you all the different object parameters
that will come to you. So you can see that if it’s a
clock event, you’ll get e dot x, y, and z, these different
properties. So with this knowledge, you
can actually mock your own objects just like
I’ve done here. For a web app, it’s all
parameters dot x, y, and z. For events, it’s a bit more
involved, because there’s a lot more objects of properties
that we give you. So that’s something
to keep in mind. It allows you to debug much
more effectively. I think there’s a couple of
other things that are interesting about
the debugger. So the way debuggers work,
essentially, is we paused the execution on our side, and we
send down the state of the application down
to you, right? So that’s pretty
powerful stuff. There’s certain things where
we’re unable to just pause execution and save state. There’s a couple of things
that we’ve documented. One of them is if you’re
asking for input. So if you have Browser.msgBox
or Browser dot– I forget the other– Inform or whatever the
equivalent is. I’ll use Auto Complete. Browser.msgBox and inputBox,
very useful. CARRIE ROWE: Very useful. ARUN NAGARAJAN: Yeah. Really saves a lot of
room in my head memorizing these things. So when you have these sort
of user, input-grabbing invocations, we’re unable to
serialized that state, because we can’t pick up where we
left off if the user is in middle of typing. So you will see a message
along the lines of continuation is not allowed. I forget the exact message. KALYAN REDDY: Unable to
serialize continuations. ARUN NAGARAJAN: And every now
and then there’s someone in the issue tracker bringing this
issue back up, but for JDBC connections, which are
these persistent database connections we make on behalf
of you and for browser UI interaction like msgBox and
inputBox, we do not allow debugging around those
functions. KALYAN REDDY: And in addition
to that, there are certain things that you should be able
to debug, and you might still be getting this error. And that’s a bug on our part,
so definitely report those kind of things. If it’s not around the two
that Arun mentioned but something different, and you’re
still getting that unable to serialize
continuation, that weird error, then report that to
us, and then we can fix that as they come. ARUN NAGARAJAN: Sounds good. So hopefully, you got a little
sense for what the debugger is all about. And now Kalyan is going to take
over and talk about some other features. KALYAN REDDY: All right. So logging. I briefly touched on this
before, but we’ll go into a little more detail here. So Logger.log is how you
can get to the log. And if you want to just try to
random string into your log, this is how you do it. So you get the string just by
doing– you’re iterating on the threads object here which
you get from GmailApp by doing inbox threads. And you’re extracting the first
message subject of this particular thread, and that
string you can easily log by just going Logger.log
and then message. Now, when I run this
Processinbox function here, you can see that the log has
a timestamp of when each particular entry was written to
the log in addition to the actual message. So these– more information about, blah,
blah, blah, all of this stuff, I think this is Arun’s
test account. Nothing awesome here, but these
are the subjects for all of the threads in Arun’s
inbox here. Very quick way when you’re
debugging your script. I mean, if you’re going to
have users running your script, they’re not
going to see this. No one in the public side
is going to see this, but this is for you. So if you’re developing your
script, you can quickly say, hey, what is this returning? Let me just log in
and find out. ARUN NAGARAJAN: So in a web
app, this is console.log. KALYAN REDDY: Yep. ARUN NAGARAJAN: And since this
is the server side, we have to expose our own logger, which is
what capital L Logger is. KALYAN REDDY: Right. So actually, it’s kind of
hidden, I guess, but you can actually log within the doGet
and doPost as well. If you’re the person that’s
executing the web app and you’re signed in, when you
execute those functions and you go back to your Script
Editor and you go into your Logger, you’ll see the logging
output from there as well. You won’t see it when other
users run your script, but you do when you’re developing it. It’s very handy for like
developing like web apps just without going through
all that pain. But there’s another way to
capture log output, which is once you have accumulated some
things within the log, within a script execution,
in the Logger, there’s another method. You can do getLog, which returns
to you a string of everything that you’ve
logged to Logger. ARUN NAGARAJAN: That’s
really cool. KALYAN REDDY: So basically, what
you can do is you can do GmailApp.sendmail, and you can
just send that as the body, the Logger.getLog. ARUN NAGARAJAN: So at the
end of an execution– KALYAN REDDY: Exactly. ARUN NAGARAJAN: Or maybe an
exception try catch all the logs so far and send it out? KALYAN REDDY: Exactly. So a lot of people do things
like open a document and then append logs to the
document instead. You know that kind of adds a
little bit more latency to your script than is
maybe necessary. This is a very lightweight way
to, if you’re running in the Script Editor, you can just
examine the Logger. If you’re not, then you can
go check your email. It gives you more
options there. ARUN NAGARAJAN: Cool. KALYAN REDDY: And so another
thing that you can do is you can do formatting. Instead of just having the
simple method where you do Logger.log and then pass in
one string, there’s an overloaded log method. And I have that as an
example down here. So I have three variables here
that I’ve poorly named. ARUN NAGARAJAN: All
right, man. KALYAN REDDY: So here we go. So one is just a number, and the
other one is a string, and the other one is an object,
which has first and second [? keys ?] and then
appropriately has values. So I want to log all of these. I don’t want to do the value
of a, close the quotes plus the object plus open quotes
and continue that. If you’re familiar with other
programming languages, you can do syntax like this where you
have one string that’s unbroken but where you want to
replace certain values of the string with variables, you can
do this %s syntax where it actually takes that variable’s
value and puts it into the string when it’s about
to write the string. So here we have the same
Logger.log as before, but we’ve defined this string, and
we’re giving the parameters of the string. So I have three %s’s here. And these correspond
sequentially to a, b, and c. You can provide a variable
number of arguments here, and you can likewise add in more
%s’s into your string. A %s means formatted
as a string. So it will convert
this object. ARUN NAGARAJAN: It’s
like printf in C++. KALYAN REDDY: I’ts like printf,
yeah, or sprintf or all the other variants. ARUN NAGARAJAN: In fact, we have
a utility style format string as well that we’ve
recently added– KALYAN REDDY: Right. ARUN NAGARAJAN: –which
has very similar– KALYAN REDDY: –which mirrors
the same syntax. ARUN NAGARAJAN: Very cool. KALYAN REDDY: So yeah. So let me just run this real
quick and show you an example of that as well. So saving code. ARUN NAGARAJAN: Can you use
your keyboard shortcuts? KALYAN REDDY: I should. So anyway, this is the
line that we logged. The value of a is 1, b is 2,
and then c, as you can see, was an object. But it turned that object into
a string and then enumerated all of its keys and
printed it nicely. ARUN NAGARAJAN: Very cool. KALYAN REDDY: All right. Oh, something I almost
forgot to mention. The execution transcript. So this is a feature that we
added relatively recently. But people have been asking
about how do I know how long a particular script takes because
I might be getting time out errors. I want to know how I can make
my code more efficient. Where are the problems? Where are the bottlenecks? So a great way to find that
out is to just look at the execution transcript. Before you would have to do
like, I don’t know, log a timestamp there, a timestamp
there, something more complex. But here let’s say we’re
running something like Processinbox. We’ve run the function, and
we want to know what’s taking a long time? What did my code actually do? You can go to View and Execution
Transcript here, and so this shows you exactly
all of the calls that your code did. And as you can see here, you do
getInboxThreads, and this is within the loop, right? So you iterate through the
first thread and call getFirstMessageSubject, and
then you log something. And then you get it for the
second thread, and then you log something else. And you can see that it actually
shows what would be actually logged instead
of saying Logger has been called again. ARUN NAGARAJAN: So you can see
that the most expensive call here was the very first call. KALYAN REDDY: Right. So just calling that
API and getting it back took one second. And then from that point on,
you have the object, and you’re not making any more
calls, so it’s nearly instantaneous. And you don’t have to
worry about it. And so this logging
took a fraction of a second, et cetera. But if you had more
function calls– I’m not sure if you have a good
example ready to go here. But if you did have more complex
calls, you can say like DriveApp.getAllFiles and
then enumerate through each file, might be more
expensive than– A good example is when you do
getInboxThreads, you get all the threads in your inbox. If you were to do
threadsi.getMessage dot and then do operations on that,
basically, getMessage per each thread, that takes much longer
than doing getInboxThreads, getMessagesForThreads. There’s another method that
takes an array of threads and returns a 2D array ARUN NAGARAJAN: Like
a batching option. KALYAN REDDY: Right. Exactly. ARUN NAGARAJAN: So it’s like
with spreadsheets, it’s something you should
look into. KALYAN REDDY: Right. So execution transcript is a
great way to analyze if a command is taking way too long,
and how to improve it. ARUN NAGARAJAN: Cool. KALYAN REDDY: Oh, one more thing
is Find and Replace. within your script. ARUN NAGARAJAN: Very
popular request. KALYAN REDDY: A very
popular request. Right. So now I already have
threads ready to go. There’s only one thread,
so let’s look for a var for some reason. So then you can quickly go
in and iterate through. ARUN NAGARAJAN: So it actually
moves around this focus. Very cool. KALYAN REDDY: And you can
actually drag this dialogue around just to see where
in your script it is. Find and Replace, obviously,
it’s very similar to other Find and Replace functionalities
in other IDEs. ARUN NAGARAJAN: And you have
multiple files, that actually lists those options
here as well. So you can see it makes
re-factoring and other cleanup options pretty straightforward. KALYAN REDDY: Right. ARUN NAGARAJAN: All right. So we’re running short
on time here. I’ll show you a couple of other
quick things that I think are really important
around libraries. I think libraries are a really
nice way to organize your code, share code across
different projects. In fact, just recently, our
colleague Eric Koleda, he released the library that
he put together based on Moment.js, which is an open
source date parsing library that is very popular with
JavaScript developers. And so let’s just take a look
at his Google+ post. Now, he talked about here’s a
library that he shared, and he gave us what’s called
the project key. So this is how libraries
are brought in. So you can find your own project
key by going to File, Project Properties. It’s tucked away here, but if
you want to bring in another project into your project as
a library, you can go to Resources, Manage Libraries. And let’s go copy this ID, and
paste this in here under Find a Library, and hit Select. And then it brought in Moment
as the title of the project, and then identifies what
we want it to auto complete off of. So that’s sort of the
name space for our particular project. And I’ll just pick the static
version for the time being, and I’ll hit Save. The Development mode, we’ll talk
about at a separate time. For now, we’ll just keep
it as a static version. I’ll hit Save. So now, I get a nice message
saying it’s been updated, and what I can do now is type in
moment dot and I get auto complete within the library that
Eric has provided for me, which is really nice to not just
be using auto complete from our APIs. You can actually get
auto complete on your own APIs as well. So libraries are a great way
to share and reuse code. A couple of other things that
I think are really important to point out are– you saw this very quickly when
I went into the project properties– is the concept of user
properties and project properties. So user properties are
essentially name value pairs that are sort of like cookies in
a web browser, if you will. You can leave that as an
API for it as well. There’s a UI for it. You can just say, favorite
color, and you could say something like blue. And the next time you come and
run the script for this user, you can say, what did
I say for you as your favorite color? And this gives you that
little storage space. And project properties are
stored and shared across all users essentially. It’s the project-level setting,
and user properties are shared across
all projects. So if you have multiple
projects, and they’re using the same user property key,
you’ll get the same value. So that’s pretty useful a lot
of times to write sort of personalized content,
so you remember what you did for the user. And here’s the APIs for it, user
properties dot, and you get the auto complete. So it’s pretty powerful
in that regard. So I think I covered everything
that I want to. Let me look at my cheat sheet
really quickly here, and we’re running out of time anyway. But hopefully, you’ve learned a
lot of really useful tricks. Carrie, did you learn
anything? CARRIE ROWE: I definitely
learned a ton. ARUN NAGARAJAN: You’re going
to go back to Mountain View and write your first
app script? CARRIE ROWE: This will be great
for all of my personal training on app scripts. ARUN NAGARAJAN: That’s right. CARRIE ROWE: And I love
keyboard shortcuts. KALYAN REDDY: Thanks. Exactly. ARUN NAGARAJAN: Yeah,
that’s for Kalyan. So we hope that you’ve learned
more tricks around how you can be more productive and use
some of the features that we’ve had in the product for
some that we released this year, some that’s been
around for a while. And we hope to keep improving
this experience. Let us know your feedback,
and thank you very much for joining. KALYAN REDDY: Thank you. CARRIE ROWE: Thanks,
everybody. Bye. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *