30 min watch
How to bootstrap a Go project on GitHub Actions
I outline bootstrapping steps for a new Go project with GitHub Actions to run tests, lint code, and ensure secure project setup.
10 min watch
Use error decorators to simplify your error handling code
Learn to use a custom error type as a decorator to simplify error handling.
6 min read
JSON Tricks: The Self-Referencing Marshaler
For more content like this, buy my in-progress eBook, Data Serialization in Go, and get updates immediately as they are added! The content in this post is included in my in-progress eBook, Data Serialization in Go, available on LeanPub. I’ve done a lot of JSON handling in Go. In the process, I’ve learned a number of tricks to solve specific problems. But one pattern in particular I find myself repeating ad infinitum.
5 min read
JSON Tricks: Extending an Embedded Marshaler
How can you embed a struct with a custom MarshalJSON() method?
Subscribe to Boldly Go: Daily
Every day I'll send you advice to improve your understanding of Go. Don't miss out! I will respect your inbox, and honor my privacy policy.
Unsure? Browse the archive.
6 min read
JSON Tricks: JSON Arrays as Go Structs
How can you marshal and unmarshal JSON array as though it were a struct in Go?
5 min read
JSON Tricks: "Slightly" Custom Marshaling
For more content like this, buy my in-progress eBook, Data Serialization in Go, and get updates immediately as they are added! Have you ever found yourself writing a custom JSON marshaler in Go, because you needed something only slightly different than what the standard JSON marshaler provides? Maybe the consumer of your JSON payload expects an array where you have a single item. Or maybe you need to nest your object one level deeper in your JSON than is used in your application.
10 min read
Simple Go Mocks
Go’s interfaces and “duck typing” makes it very easy to create simple mock or stub implementations of a dependency for testing. This has not dissuaded a number of people from writing generalized mocking libraries such as gomock and testify/mock, among others. Here I want to describe a simple alternative pattern I frequently use when writing tests for an interface, that I think is generally applicable to many use cases. No Silver Bullet Of course neither this approach, nor any other, is a one-size-fits-all solution.