AppsScriptPulse

Deploying an Apps Script Library Part 4: Essential Developer Tooling

 

 

In this series about deploying Google Apps Script libraries, Part 2 dove deep into Test-Driven Development (TDD) and highlighted jest as my go-to tool for outstanding outcomes. Now, let’s broaden our toolkit with additional essentials that not only elevate our development standards but also make our codebase more welcoming to collaborators.

First up, we’ve got ESLint. Linting, for those unfamiliar, is the process of running a program that will check your code for potential errors.

Next, we introduce Prettier, which takes our code and formats it into a structured style that you define. Think of Prettier as the stylist of your codebase, making sure everything looks ‘pretty’ and readable by cleaning up those messy or inconsistent styles left behind.

We also employ Husky, a tool for managing git hooks. Git hooks are scripts you can set to run before or after events like commits, push, and receive. Husky ensures that tools like ESLint, Prettier and Jest run every time you commit changes, helping catch issues before they hit production.

These tools are indispensable not just for solo developers but also for teams looking to contribute to the library. By maintaining consistent, pre-defined high standards of code hygiene, we ensure that our library remains robust, clean, and maintainable.

Prerequisites: You should be familiar with git, an essential skill for any developer. If you’re not, I recommend checking out the beginner’s guide at FreeCodeCamp. Additionally, being able to code locally and understanding clasp is crucial. If you need a refresher on this, visit my earlier post on setting up your local environment. Once you’re set, we can dive into making our development process even smoother and more efficient!

Here are the links to the repo and the NPM page again.

Source: Deploying an Apps Script Library Part 4: Essential Developer Tooling

Deploying an Apps Script Library Part 3: JSDoc vs TypeScript

About a year ago, a notable shift occurred in the developer community when SvelteKit made the decision to transition from TypeScript to JSDoc, specifically stating that TypeScript was not the ideal choice for developing libraries. This move definitely raised some eyebrows and stirred the pot among developers. Initially, I was skeptical, perceiving it as a regression rather than progress. TypeScript was even featured in one of my previous blog posts as a recommended tool. However, this decision began to resonate with me over time, leading me to adopt a similar approach in Google Apps Script. The reasons for this shift are manifold, with some being universally applicable and others specific to the peculiarities of Apps Script.

Here are the links to the repo and the NPM page again.

Let’s dive into why TypeScript was chosen in the first place and what has changed to endorse JSDoc over it.

Source: Deploying an Apps Script Library Part 3: JSDoc vs TypeScript

Deploying an Apps Script Library Part 2: Source Code and Project Structure

 

Following up from last week, we get into how I built the table() method in our ConsolAS class, using test-driven development (TDD). This is a cool way to make sure everything works perfectly by testing each part before we fully build it. We’re aiming to make it work just like the console.table() function in Google Chrome, which is pretty handy.

Source: Deploying an Apps Script Library Part 2: Source Code and Project Structure

Ever felt like you’re bringing a knife to a gunfight? That’s me coding without `console.table()` in Google Apps Script. Here’s what I did about it.

Here’s the scoop: While tinkering with a project, I needed a way to pinpoint the last row of data in various sheets — essentially to catch any “orphan” values lurking there. Typically, something like console.table() would be the hero of the day, allowing me to effortlessly display data like so:

| Sheet Name | Last Row |
| ---------- | -------- |
| Sheet1     | 513      |
| Sheet2     | 27       |
| Sheet3     | 50       |

But as fate would have it, Google Apps Script doesn’t include a console.table() function, or even a Logger.table()

Source: Ever felt like you’re bringing a knife to a gunfight? That’s me coding without console.table() in Google Apps Script. Here’s what I did about it.

I challenged Gemini to a game of battleship in Google Sheets. Here’s what happened 🚢

 

I tried to see if an AI that’s good at writing could also make smart moves in a game. I chose Battleship and set it up in Google Sheets to play against Gemini, the AI. The result was mixed. On one hand, yes, Gemini could play the game. It followed the basic rules and even managed to sink some of my ships. This was a big deal, especially since it took me a ridiculous number of days of coding to get there, and I nearly gave up at one point.

Dmitry Kostyuk has shared a blog post detailing his experiment pitting the Gemini API  against himself in a game of Battleship. As explained by Dmitry  while Gemini could follow the rules and even sink some ships, it needed help to avoid basic mistakes, revealing that AI still has room to grow in the realm of strategic games.

Dmitry built the game in Google Sheets and the source code is linked from the post. To guide Gemini, Kostyuk crafted detailed prompts outlining the game’s mechanics and decision-making logic. However, he encountered challenges due to Gemini’s limitations in providing strategic responses. Despite these hurdles, the project yielded valuable insights into prompting techniques for AI decision-making.

Source: I Challenged Gemini to a Game of Battleship. Here’s What Happened.

How to Write to a JDBC Database with Google Apps Script: My Adventure with a Pesky Character Limit

I recently faced a frustrating issue when writing data to a CloudSQL database with the JDBC class in Apps Script. I kept getting the following error:

Exception: Argument too large: SQL

I also observed that it only happened when my SQL query reached a certain length. I considered breaking it down into multiple queries, but I was still puzzled 🤔 because I was only sending a few dozen kilobytes of data.

Now, the thing is, the official documentation could be more helpful; even though the solution is there, it needs to be better explained. So, I turned to StackOverflow. There was a discussion on this exact topic, but to my surprise, I was still waiting for an answer. Until, well, I wrote it 😉

Source: How to Write to a JDBC Database with Google Apps Script: My Adventure with a Pesky Character Limit

Master Google Apps Script UIs — Part 5: Unit Testing Your Front-End With Jest 🚀

Introduction 📝

Well, well, well! Look who’s back for another session of “Weaving Magic with Code”! 😄 Today, we’re diving head-first into the magical world of unit testing. You might be wondering: “Why the fuss about unit testing?” 🤔

Unit testing, my friends, is the silent hero of software development. Picture it as a mini-pit stop where your code gets a once-over before it hits the road. The automated tests ensure that our code does exactly what we expect it to. The benefits?

  • Makes us ponder deeply about our app’s architecture, like a philosopher musing about the meaning of life 🧐
  • Forces us to clarify our expectations from functions and classes.
  • Ensures that as we revamp and update our code, we aren’t unknowingly playing host to bugs, much like a surprise party you didn’t want 🐛

Source: Master Google Apps Script UIs — Part 5: Unit Testing Your Front-End With Jest 🚀

Master Google Apps Script UIs — Part 4: Spice Up Your Project with Dev Dependencies! 🔧

Introduction

Welcome back, code wranglers! Today, we’re diving into the world of developer dependencies that make developing projects more efficient than a coffee-fueled coder on a deadline. 🚀 You can find the complete source code in the part-04 branch of the Github repository. Also, feel free to mess around with this demo spreadsheet and play with Emojibar. I’ll be updating it with every new blog post!

What Are Dev Dependencies?

Dev dependencies are like your car’s GPS: they’re not necessary for the car to run, but they sure make getting to your destination a lot easier! 🗺️ They’re modules necessary for the development and testing processes of a project, but not for its production runtime environment. They’re not bundled with the source code and help automate tasks that would otherwise make you pull your hair out.

Source: Master Google Apps Script UIs — Part 4: Spice Up Your Project with Dev Dependencies! 🔧

Building the Ultimate Google Apps Script Front Ends. Part 3: Styling with Tailwind CSS 😎

Let’s take our UI to the next level with Tailwind CSS!

Introduction

In the previous article, we learned how to bundle NPM modules with Vite. Today, we’re going to add some style with Tailwind CSS. If you’ve been following my series, you’ll breeze through this like a true professional. 🚀

Check out the part-03 branch in the Github repository for the full source code.

 

What Is Tailwind CSS

Tailwind CSS is a utility-first CSS framework that makes styling a breeze. Think of it like a wardrobe filled with every piece of clothing that you’ll ever need, with everything neatly organized and ready to go. 💃🕺

Source: Building the Ultimate Google Apps Script Front Ends. Part 3: Styling with Tailwind CSS 😎