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/.

I started blogging 20 years ago, in April 2003. My first blog engine was a PHP CMS, called Nucleus. I was hosting it on my ISP, at free.fr.

Then in 2011, I wrote my own blog engine, called Bloogaey, which was written in Groovy, using my little Gaelyk web framework, and running on App Engine.

As it became a bit painful to properly format my blog posts, and evolve my blog engine, I decided I should move to something that is more static, with a static site generator that eats Markdown files: I chose the Hugo static site generator that I used in some previous projects. And I’m now hosting the content of my blog in Github Pages, under the glaforge.dev custom domain name.

With the turmoil around Twitter, like many, I’ve decided to look into Mastodon. My friend Geert is running his own Mastodon server, and welcomed me on his instance at: uwyn.net/@glaforge.

With Twitter, you can access your analytics to know how your tweets are doing, how many views you’re getting. Working in developer relations, it’s always interesting to get some insights into those numbers to figure out if what you’re sharing is interesting for your community. But for various (actually good) reasons, Mastodon doesn’t offer such detailed analytics. However, I wanted to see what the Mastodon APIs offered.

This is a three-part series of posts, in which we summarize Workflows and service orchestration patterns. In this third and final post, we talk about managing workflow life cycles and the benefits of using Firestore with Workflows. 

Use subworkflows and Terraform to manage workflow definitions

If you’re not careful, the workflow definitions you create with YAML or JSON can get out of hand pretty quickly. While it is possible to use subworkflows to define snippets of a workflow that can be reused from multiple workflows, Workflows does not support importing these subworkflows. Thankfully, there are other tools, such as Terraform, that can help.

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.

This is part 2 of a three-part series of posts, in which we summarize Workflows and service orchestration patterns. You can apply these patterns to better take advantage of Workflows and service orchestration on Google Cloud.

In the first post, we introduced some general tips and tricks, as well as patterns for event-driven orchestrations, parallel steps, and connectors. This second post covers more advanced patterns.  

Let’s dive in!

Design for resiliency with retries and the saga pattern

It’s easy to put together a workflow that chains a series of services,  especially if you assume that those services will never fail. This is a common distributed systems fallacy, however, because of course a service will fail at some point. The workflow step calling that service will fail, and then the whole workflow will fail. This is not what you want to see in a resilient architecture. Thankfully, Workflows has building blocks to handle both transient and permanent service failures. 

For the last couple of years, we’ve been using Workflows, Google Cloud’s service orchestrator, to bring order to our serverless microservices architectures. As we used and gained more experience with Workflows and service orchestration, we shared what he had learned in conference talks, blog posts, samples, and tutorials. Along the way, some common patterns and best practices emerged. 

To help you take better advantage of Workflows and service orchestration on Google Cloud, we’ve summarized these proven patterns and best practices in a three-part series of blog posts.

When designing a web API, not only do you have to think about the happy path when everything is alright, but you also have to handle all the error cases: Is the payload received correct? Is there a typo in a field? Do you need more context about the problem that occured?

There’s only a limited set of status codes that can convey the kind of error you’re getting, but sometimes you need to explain more clearly what the error is about.

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.