I found that continuously updating my CV over time was a pain, so I simplified it and automated it. These days I use a simple CI workflow in a GitHub repository that generates a new .pdf CV based on a Markdown source file. If you like the sound of this, I’ve created a GitHub template for this pattern, should you wish to follow my example. The template contains placeholders to fit the structure I personally use these days, and is littered with tips and advice for how to write a good CV (I say this as someone who’s screened a lot of low-quality CVs).

Keeping your code’s dependencies up to date is hard, so luckily there are free tools like Dependabot around, that can create PRs against your repository whenever any of your dependencies have a more recent version updated. Depending on the size of your codebase, this can turn into quite a chore as you have to verify that the dependencies don’t break your code. A common solution is to establish a thorough test suite and other CI checks that you trust to let you know if your code is broken and combine that with automatically merging Dependabot PRs.

When error messages contain “useful information” e.g. application-specific IDs or other variables then the error messages lose their “grepability”. In other words, you cannot quickly search a codebase for an error without removing anything you believe could be variable. You might not think this is a big issue, and I might even agree with you there, but you might as well make it a practice to make error messages boring – I.

I recently rewrote my Neovim configuration in Lua in order to take advantage of a more intuitive programming language for configuration, Lua-only plugins, and powerful Neovim-only features such as: The built in LSP: Language Server Protocol, IDE features like “show docs”, “find references”, “rename”, and “go to definition” for basically any language. Treesitter: Powerful parsing of any programming language, which means plugins and syntax highlighting can make powerful and accurate transformations.

Have you ever wondered how iota works in Go? Basically, iota is the index of the constant inside a multi-constant (const (...)) declaration. So the value of iota for the first constant is 0, the second constant is 1, and so on. This only works for constants, not vars. This is probably best explained with an example. package main import "fmt" type day int const ( // Start counting days from 1, so ignore 0.

You might know that prefixing a file or a directory with . makes it ‘hidden’ in unix-based systems – i.e. they won’t show up when you run ls and they won’t show up in your file browser (e.g. Finder). However, did you know that MacOS lets you hide any directory in Finder – even if it’s not .hidden – using chflags? $ chflags hidden dir1 dir2 dir3 I use the above to hide directories in my home directory, that I can’t remove (MacOS regenerates them automatically):

This article will cover how to get visibility of your test coverage in Go. If you’re not comfortable with the basics of testing in Go, please checkout my earlier article aimed at beginners. Test coverage Test coverage gives you a high-level overview you how much of your production code was invoked in your tests (e.g. as a percentage), but it can also give you a lower-level view of exactly which lines are invoked or missed.

A while ago, I saw a question in a Go developer Slack channel that went something like this (translated): When would you want to define a function type like type MyFunc func(msg string) error? Do you have any examples? I replied with a http.HandlerFunc example (more on that below), but there were many developers smarter than me in that Slack channel, and I ended up learning a lot from the other answers to this question.

This past week I’ve had the privilege of having a Hack Week where I work, where we can work on whatever we wanted. I ended up building Mokku – a mocking framework for Go that gets out of your way. Key features Invisible: No hard (import) or soft (//go:generate) dependencies to add to your codebase. Unintrusive: Can be included in any developer’s workflow. Doesn’t dictate or enforce how you use it after it’s written.

Let’s have a go at writing tests in Go. Puns aside, testing in Go is baked into the language. Assuming you’re comfortable with the Go basics, let’s get started with writing tests. First of all, the way you run all tests in the current package is: $ go test However, unless you’ve got tests in your project nothing is going to execute. Go tests have to follow these three rules: