https://arran4.github.io/blog/categories/go-patterns/Recent content in go-patterns on Arrans Technical blogHugo -- gohugo.ioentechnicalblog123@arran4.com (Arran Ubels)technicalblog123@arran4.com (Arran Ubels)Arran Ubels. This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.Thu, 27 Aug 2026 13:38:30 +0000https://arran4.github.io/blog/post/2026/039-asset-hashing-in-go/Thu, 27 Aug 2026 13:38:30 +0000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/039-asset-hashing-in-go/When building web applications, a common goal is to serve static assets (CSS, JavaScript, images, WASM) as quickly as possible. The most effective way to achieve this is aggressive HTTP caching. However, aggressive caching introduces a challenge: when you update an asset and deploy the new version, you must ensure that users receive the updated file rather than a stale, cached copy, while avoiding unnecessary downloads for unchanged assets. The solution to this problem is asset fingerprinting (or content hashing).https://arran4.github.io/blog/post/2026/034-golden-test-update-convention/Fri, 14 Aug 2026 02:27:49 +0000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/034-golden-test-update-convention/go test ./... -update is a common golden-test update convention, but -update is not built into go test. The repository&rsquo;s test code defines that flag and uses it to decide whether to compare against or overwrite .golden files. A typical implementation looks like: 1var update = flag.Bool(&#34;update&#34;, false, &#34;update golden files&#34;) 2 3//go:embed testdata/example.golden 4var exampleGolden []byte 5 6func TestSomething(t *testing.T) { 7 got := generateOutput() 8 9 golden := &#34;testdata/example.https://arran4.github.io/blog/post/2026/033-testing-fs-with-mapfs-mockfs/Fri, 14 Aug 2026 00:00:58 +0000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/033-testing-fs-with-mapfs-mockfs/When building tools in Go that interact heavily with the file system, having a solid strategy for testing those interactions is critical. Direct coupling to os functions like os.MkdirAll or os.WriteFile makes testing cumbersome and slow. In this post, I want to detail how I approach this by designing minimal file system interfaces and using in-memory implementations like MapFS and MockFS for tests. Why This Matters in the Era of Agentic Coding Before diving into the code, it&rsquo;s worth highlighting why robust, abstract testing environments are becoming even more critical today.