First Impressions of Clasp extension for VS Code to manage local development of Google Apps Scripts

The editor for google apps scripts is OK for simple (single file) macros or scripts. But it falls short when you are managing more complex scripts and multiple files. That is where google clasp comes in. Google clasp is an extension for VS code that allows google apps scripts to be updated locally, with changes easily pushed to your script.google.com. It does not replace git, as it does not do version control, but it does do basic syncing well. It has its own .claspignore file like git and uses similar commands – clasp push to send code to google.com and clasp pull to get code down. But it is rather crude – there are no controls and it overwrites everything on script.google.com with each push. I assume pulls would do the same, but I have not done them and would caution against them. A simple json files clasp.json – holds the scriptID of the remote target and a path to the local “repo”. I have a dev and prob remote target and swap our clasp.json files as needed. Pushing to multiple targets seems to be possible, but I have not implemented it.

I followed this basic guide to get up and running – thank you Learn Google Spreadsheets. As this guide is geared to Mac users and I am running on WSL2 on windows, I had to do a few particular things to get clasp installed.

One clear anomaly that clasp handles is the conversion the .gs file extensions on script.google.com to .js file extensions in your VS code. I also have a remote git repo connected. The remote git repo works pretty normally, but it does have .js extensions so it cannot be hooked up directly to script.google.com. I would need another repo that connects to the gashub extension for chrome to hold a repo of .gs files. Pretty convoluted, but it works.

I found that having VS Code really facilitates refactoring. I basically treat the script.google.com as the test server environment and use the watch command (clasp push -w) to make updates quite seamless. All in all a thumbs up.

UPDATE – for those interested – here is my full workflow.

Google Apps Script workflow – with Clasp and Gashub

First impressions of GitHub CoPilot

Finally had a chance to get a first hand taste of GitHub CoPilot – the AI-based automated code generation tool which is in restricted Beta. And I have to say I like it and would encourage you to get on the beta list. I had seen a few videos on it, but it really feels different with you have it running in the background of a live project of your own. It makes suggestions that are at times helpful other times not, but never annoying.

I found it most impressive and helpful when running inside a javascript code base that I are extending. A line of comments in context is often all it needs to generate a decent snippet of code. And while generating code it a new function, it picked up and integrated very particular structures in my code base – e.g. my object model, my callback structures, my naming scheme, etc.. It did not feel like it was grabbing code verbatim from GitHub as some have postulated. It was writing code in my style. It was a bit freaky to see how well it mimicked new lines of code that I could have written. At times it was like the Gmail autofill that guesses what you might want to write. But this is code and it was rarely wrong.

GitHub CoPilot integrates with Visual Studio Code and requires Node.js and NPM (you install it as a package). I ran it on a Windows Machine running WSL2 with Remote Development Tools so was in clean virtualized Linux environment.

Here is a live example of this: I typed the first 2 lines – a comment and the function definition. And CoPilot within a couple of seconds suggested the next 15+ lines comprising a complete function with callback and error capture in keeping with my object model and variable structures.

Github CoPilot generated all the lines in Gray. If you keep typing you the code disappears. If you tab – the code is captures and you can edit it further.

My love/hate of Cloud Based IDEs.

Having learned modern development late in life, I have relied on cloud-based IDEs for my much of my coding. I started off on c9.io which was great until Amazon bought it a few years ago. It was container-based so you could spin up new environments very quickly and access them from any machine. The new version of Cloud9 under AWS still works for me, but I no longer love it. My latest cloud-based IDE is one on ‘training wheels’ – the script editor for Google Apps Script (GAS – such a bad name and acronym).

With GAS, I love the extension of Javascript to the google apps world – the sheets, docs, gmail classes are incredibly robust. And the concept of bounded scripts greatly simplifies authorizations needed to move across apps. The integration with Google Compute Engine – just damn works. And the ability to execute scripts up to 6 minutes (for FREE) is very sweet. I never want to write another line of VB code.

The only real shortcoming is the script editor. While, I did not suffer through the first version, it baffles me why it still has no support of tabs or folders (something my c9 IDE had 5 years ago). Yes it might work for the business users relying mainly on macro-recording. But that is just one use case. With hand-crafted processes, you can create and execute code spread across multiple files, but during coding the UI is only aware of local (single file) references. WTF??? What other code editor only references a single file during coding? Notepad is not a good reference point.

The Script Editor seems to go out of the way to encourage worst practices – putting all of your code in one file with NO version control. Google sheets and docs are amazing at version control – what happened to the script editor? The fact that there is currently no support for local git is a big shortcoming.

I recently solved this lack of version control by integrating a sweet chrome extension – GasHub – that allows even a bounded Google App Script to push and pull to a remote repo – all without a local git. It is very basic – but does the job and simplifies moving code from dev to production. Now with this remote repo integration I want to see if I can move coding to my newly minted local environment (WSL2/Docker/VScode) and even see if GitHub Copilot can help with GAS coding. More to come….

Course 6 seems a lot more fun these days.

Started watching the Machine Learning series from the MIT Open Courseware offerings.  Incredible source of free coursework.  This is from last fall and is part of MIT infamous “course 6” Introduction to Computational Thinking and Data Science.  I avoided course 6 when I was at MIT Sloan School – too theoretical.  It is far more relevant today.

What is the role of TDD with Machine learning?

I have looked at a good 50 books on machine learning and see few that seriously deal with Testing Driven development and Machine learning.  Given the vary nature of machine learning, the lack of TDD seems to be a problem waiting to happen.  Having grown up in the world of credit risk modeling, I know the level of scrutiny we had at every level of model development deployment and monitoring.  More recently I dived into full-stack web development with a rather simple web app that is backed by 1400 tests in a continuous integration environment.  It is a challenge keeping the environment and test suite in sync at times, but the foundation principles of creating single responsibility classes and overtly spelling out acceptance criteria at the most basic level (unit tests) is a critical discipline.