Right in the middle of a workshop I was delivering, as I was launching Google Cloud console’s Cloud Shell environment, I received the dreaded warning message: no space left on device.

And indeed, I didn’t have much space left, and Cloud Shell was reminding me it was high time I clean up the mess! Fortunately, the shell gives a nice hint, with a pointer to this documentation page with advice on how to reclaim space.

As cURL was celebrating its 25th birthday, I was reading Daniel Stenberg’s story behind the project, and discovered a neat little feature I hadn’t heard of before: the --json flag! Daniel even blogged about it when it landed in cURL 7.82.0 last year.

So what’s so cool about it? If you’re like me, you’re used to post some JSON data with the following verbose approach:

curl --data '{"msg": "hello"}' \
    --header "Content-Type: application/json" \
    --header "Accept: application/json" \
    https://example.com

You have to pass the data, and also pass headers to specify the content-type. You can make it slightly shorter with the one-letter flags:

For some scripting tasks, my favorite go-to tool is the Groovy Console, and writing code with Apache Groovy. Usually, you just spill some println calls all over the place to display some textual information. But there’s a little known secret. Not really secret though, as it’s properly documented. It’s possible to display images (like BufferedImage or its parent java.awt.Image) or all sorts of rich components (from the Swing UI toolkit, like JPanel, JLabel, etc.)

I regularly use both IntelliJ IDEA and Visual Studio Code as my environments for developing. But like all tools, we often need to personalise them to our liking, to feel at ease, or to be more productive. As we read code more than we write, there are certain settings in your favorite editor to improve your reading experience. Today, I’ll share of the tweaks I’ve made to my VS Code settings.

You can edit some of the settings by opening the UI of the settings dialog box, but you can also edit the JSON file in which those settings are saved. On a Mac, for example, the settings.json file is stored in ~/Library/Application Support/Code/User/.

Probably like most of you, my dear readers, I have too many browser windows open, with tons of tabs for each window. But there are always apps I come back to very often, like my email (professional & personal), my calendar, my chat app, or even social media sites like Mastodon or Twitter. You can switch from window to window with CTRL/CMD-Tab, but you also have to move between tabs potentially. But for the most common webapps or websites I’m using, I wanted to have a dedicated desktop application.

Here are some general tips and tricks that we found useful as we used Google Cloud Workflows:

Avoid hard-coding URLs

Since Workflows is all about calling APIs and service URLs, it’s important to have some clean way to handle those URLs. You can hard-code them in your workflow definition, but the problem is that your workflow can become harder to maintain. In particular, what happens when you work with multiple environments? You have to duplicate your YAML definitions and use different URLs for the prod vs staging vs dev environments. It is error-prone and quickly becomes painful to make modifications to essentially the same workflow in multiple files. To avoid hard-coding those URLs, there are a few approaches.

Requirements:

• an existing Google Cloud Platform account and project
• Cloud Functions should be enabled for that project

Compared to the previous tip when using Exress’ request path attribute, we can take advantage of Express routing.

So to support the following paths:

https://us-central1-myproject.cloudfunctions.net/api/customers
https://us-central1-myproject.cloudfunctions.net/api/customers/32
https://us-central1-myproject.cloudfunctions.net/api/customers/32/address

We can have our functions require Express by adding Express in package.json:

{
  "name": "mini-api-router",
  "version": "0.0.1",
  "dependencies": {
    "express": "^4.17.1"
  }
}

Then we can require that dependency in our new functions script:

Requirements:

• an existing Google Cloud Platform account and project
• Cloud Functions should be enabled for that project

We often use individual HTTP Cloud Functions as a single endpoint, and we pass data to the functions with either query parameters, or via a POST body payload. Although it’s a good practice to keep the scope of a function small, however, you can easily write mini Web APIs for a given function, with different paths for different needs, like with usual Web frameworks.

Requirements:

• an existing Google Cloud Platform account with a project
• you have enabled the Cloud Run service and already deployed a container image
• your local environment’s gcloud is already configured to point at your GCP project

By default, when you deploy a Cloud Run service, it is secured by default, unless you use the –allow-unauthenticated flag when using the gcloud command-line (or the appropriate checkbox on the Google Cloud Console).

But once deployed, if you want to call it locally from your development machine, for testing purpose, you’ll have to be authenticated.

Requirements:

• an existing Google Cloud Platform account
• you have enabled the Cloud Run service and deployed already a container image

One of the nice things with Cloud Run is that when you deploy your services, you get a URL like https://myservice-8oafjf26aq-ew.a.run.app/, with a certificate, on the run.app domain name, etc.

You see the name of the service: myservice, the region shortcut where it was deployed: ew (Europe West), and then .a.run.app. However, you can’t guess ahead of time what the final URL will be, as there is a randomly generated part in the URL (here: 8oafjf26aq). Let’s see how we can discover this whole URL.