There was a recent discussion here: https://news.ycombinator.com/item?id=36345288

I mostly use DigitalOcean and their managed kubernetes service. My projects tend to be self-contained in a monorepo (where my k8s manifest also live) and I use Flux* to keep my cluster in sync. I'm quite happy with, took a bit of time to get it set up exactly how I wanted, but now it's no-effort to do releases.

* https://fluxcd.io/

I've been working on a platform to help teams deal with their deadletter queues. It's very much a scratch my own itch project as it's solving a problem that I've faced while at my day job.

This is the one I wanted to suggest too. It's a great book, don't be put off by the "enterprise" in the name.

I've been working on an event orchestration platform[1] with the initial use case being "surface your deadletter queue, and resolve problems" mostly to scratch an itch. In other words, what happens when you can't process an event and you want a human to investigate the why and perform some kind of action to resolve the issue.

[1] anketta.com

I think "based on" is more like implemented on top of, similar to timescaledb

it looks like the generated code of a protobuf enum

Great to see. I've definitely missed it coming from circleci where you have contexts where you can define secrets that you can share across multiple repos

Environment variables being exposed to the client is great assuming this means they can be configured at runtime and available on the client

You‘d have to assume that they are only read during SSG/SSR.

I was in the same boat until I tried VScode. It's a really great editor, configurable, and performant enough that I don't miss Sublime. Also the Go support is pretty great.

https://github.com/Microsoft/vscode-go

What's the big difference between VScode and Atom? Why would I move to a fork?

VScode is not an Atom fork. It's only built on the same tech (Electron)

Really? For some reason I really thought it was a fork of Atom. How does it compare then?