Posts

This post is a response to a comment from one of my subscribers, who suggested the topic for the next post:

… how to set up Docker so the LB routes straight into the right containers

How do I see the task?

When developing locally, many people skip simulating https and run their services over http.

Here’s the task:

• Serve traffic locally over https with a valid certificate;
• Make it easy to reproduce — not just for you, but for everyone on your team.

Many of us, back in the day, did web development, and to develop and test the next project locally we’d add another entry to /etc/hosts along the lines of:

127.0.0.1       next-project.tld

“1024 lashes for anyone using http.DefaultClient in their code” — that’s the kind of “joke” you hear at our standups. The problem is that the defaults don’t set any timeouts. There’s a great article on the topic on the Cloudflare blog¹.

I use Uber’s fx¹ IoC container in my work. There are camps on both sides — fans and detractors of this kind of solution — but here we’ll focus specifically on using fx.

If you’re not familiar with the basics, I recommend going through the official Quick Start². It’ll help you get your bearings.

Given:

• GitLab, most likely deployed inside an internal network;
• “perfectionism” that demands everything be filed neatly into folders, or a directive from above;
• an internal Go package that needs to be installed as a dependency.

Given:

• You’re using Jetbrains Space¹.
• You write code in Go.
• You need to create a shared library and pull it in as a module across your internal projects.

For one reason or another, you’ve switched from Docker Desktop to lima or colima and you’re on an M1 MacBook.

By default, lima and colima use qemu under the hood. To get a 1.5–2× speedup ¹, you need to launch the VM with virtualization options that swap qemu for Virtualization.Framework².

Given:

• Two versions of the same application: A and B.
• Both versions expose a contract described in OpenAPI.
• The application has consumers that rely on the current contract.

The task:

• Determine whether the new version’s contract introduces any backwards-incompatible changes.
• Determine what additional changes the contract has undergone.

The standard Go tooling doesn’t print a summary of your tests. But on a large project, when you need to see the overall picture, that kind of summary is useful. Say you’re bringing your own fork up to date with upstream and you need to gauge the size of the problems caused by merging the changes.