Founding Engineer at Anchorage Digital
I love feedback! Email me your ideas.
Founding Engineer at Anchorage Digital
I love feedback! Email me your ideas.
Tempts is my temporal Go SDK wrapper that enables safer usage of Temporal when writing workflows in Go. I’ve been using Tempts successfully for new code, but I found it difficult to migrate existing code that uses positional arguments rather than a single input object. The new version of Tempts makes this migration easy and provides an easy way to move away from positional arguments after migrating to Tempts. The problem with positional arguments Positional arguments are when your workflow or activity’s function signature looks like func(ctx context....
When writing Go code, you have a lot of freedom in how you organize things, but there are some common pitfalls to avoid. One of them is what I’m calling the crab pattern. I’ve made this mistake plenty of times and always regretted it. The crab pattern happens when your code structure creates unnecessary dependencies. One side of the crab represents the importers of a central package and the other side represents the dependencies of a central package....
Introduction Let’s talk about global state in programming. We’ve all made excuses for using it, but there are better ways. Here, we’ll address some common excuses and show why avoiding global state is a game-changer. Common Excuses for Using Global State “I’ll use this code only in this specific way.” Code often outgrows its initial purpose, leading to unexpected issues. “It’s just the logger, though!” Even a logger can introduce hidden dependencies and headaches....
Are you using Temporal and writing workflows in Go using their Go SDK? If so, I have something for you. Otherwise feel free to skip this blog post. I created a type-safe wrapper around the Temporal Go SDK called tempts. It helps you avoid many common mistakes when working with Temporal workflows. The native SDK is powerful and flexible. Although this wrapper sacrifices some power and flexibility, it offers safety through its opinionated design....
There are three other packages already that implement data loaders in go, but after using them for a while, I wasn’t happy and decided to write my own. But why? Let’s start with “what’s a data loader?” It’s a pattern popularized by facebook in their dataloader javascript package. A data loader synchronizes multiple calls to fetch the same type of data (let’s say a user) by different keys (user IDs) and blocks the callers until “enough” of them have made a request....
I recently taught myself HTMX, and I’m excited to see its growth because it revives an old idea that the world has forgotten: hypermedia.. Hypermedia was behind the original growth of the internet and, through HTMX it might be able to bring a new level of efficiency and productivity to a world tired of JavaScript single page applications and 10MB web pages. It’s promoted as a way to make back-end developers more productive by learning a little bit of front-end....
I just published a blog post on the Anchorage Digital Engineering blog on the somewhat controversial topic of using code vs infrastructure to solve problems. You can learn where I stand by reading the original article here!
While attempting to extend the slog package in many different ways, I kept coming back to this idea that, at some point, I have to write a slog.Handler. I don’t have a need for high performance, and I just need an easy way to extend my logger to do additional things at the same time as logging. That’s why I created slogevent. This Go package makes extending slog as simple as writing a function that handles log entries....
In my previous blog post on the Anchorage Digital blog, I wrote about logging features I’d love to see built around the new slog package coming in Go 1.21. I heard from several people that they want to learn more about how exactly to do this. To answer these questions, I built out 6 examples of how to extend slog, showing 4 different strategies. I used some of the use-cases from the last blog post....
Go 1.21 will be released with many improvements that I appreciate, but the one that stands out to me the most is the addition of the log/slog package. It serves as a great foundation for a logging system, but there’s a lot more to logging than what it offers out of the box. I published a blog post on the Anchorage Digital Blog that points out some logging features that can and should be added around this package....