i use nogo instead of golangci-lint for Go linting in Bazel. nogo is a rules_go feature that compiles Go analyzers into the build. Lint errors become build errors. Bazel caches results per package, so incremental builds only re-lint what changed. golangci-lint has its own cache, but it doesn’t share between CI and local, so you duplicate work.

You enable nogo in MODULE.bazel by pointing go_sdk.nogo at a nogo() target:

go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")
go_sdk.from_file(go_mod = "//:go.mod")
go_sdk.nogo(nogo = "//:nogo")

go_sdk.from_file reads the Go version from your go.mod, so you don’t duplicate it. You can also use go_sdk.download(version = "1.24.5") if you want to pin it explicitly. Read more

I’ve been a Linux user for about 15 years, and I owe a lot of that journey to my first job at Capgemini Deutschland GmbH. It was a classic corporate setup-developers used Windows, but all the servers ran on Linux. That’s where I finally got to learn the essentials: Bash scripting, maintaining on-premise servers for testing environments, and all that fun in-house stuff.

I was working there part-time while studying computer science, so it wasn’t long before I started using Linux for personal projects, too. I kept my gaming PC on Windows, though, because back in 2012, gaming on Linux was basically impossible. Read more

Buf is the best tool to manage protobufs. One of the biggest pain points of protobuf is the management of protoc plugins. You need to manage them, and make them available to other engineers working on the same repository/project. Versions need to be centrally managed, code generation must produce the same result, no matter if it happens on an engineer A or B’s machine, or in CI.

This becomes even more challenging, as protoc plugins are written in different programming languages. Go protoc plugins are written in Go, and are therefore compiling to a single binary without dependencies. Easy. However, other plugins are more difficult to manage. Typescript plugins like protoc-gen-es are written in Typescript, and therefore do not compile to a single binary. Read more

By default, Azure AD Access Tokens have a lifetime of 1hour. Especially for single page apps, it’s very inconvenient. Users have to re-login every hour. Ideally, it’s just one redirect to the login of Azure AD, and there they still are within their session, and AD redirects them back to your app. However this can still be very painful, e.g. if the user does something within your app, and gets pretty much logged out because all API calls fail due to an expired token. My experience is, that 1 hour is too short. It has security benefits of course, but the complexity in the app increases significantly if you start dealing with expired tokens, saving state to local storage, and transmitting data after a successful re-login for example. Read more

Google Cloud DNS is a convenient way to manage DNS Zones. With Terraform, it’s possible to manage these Zones as code, usually by committing the terraform files to version control. However, setting up sub-zones has always been a bit tricky. I’ll use this blog post to document how to manage zones and sub-zones with CloudDNS and terraform.

To manage a zone, the resource google_dns_managed_zone can be used:

To add a sub-zone: Read more