This is, first and foremost, a post about two new open-source projects I’m excited to share with the world - though there is a short postscript that’s about having open-source projects at all.
Both of these projects are in Go and intended, primarily, for use by Gophers:
1. stave
If you are using a Makefile to test, lint, build, and/or release your Go app, then you have what is in effect a mixed-language project: your code is in Go, but your build system is in sh or bash (*).
Nate Finch recognized this years ago, and created the wonderful Mage tool, a build system where you write runnable build targets directly in Go.
Now, James Ainslie and I are taking this a step further: introducing Stave, a fork of Mage with numerous enhancements. Including:
-
Watch-mode (automatically re-run build targets if any file matched by specified glob-patterns changes)
-
Dry-run mode (tell me what command-lines you would have run, but don’t run them)
-
Modern CLI, incl. integrated completions (out-of-the-box, if you install stave via Homebrew)
-
Native management of git-hooks (buh bye, Husky!), enabling you to specify your Go-based build targets as git hooks directly
-
Support for enforcing Keep A Changelog conventions (if you choose to)
-
… and much more!
Stave is a work in progress, and we’re not quite ready to open it up for community contributions yet; but, like Mage, it is open-sourced under the Apache License 2.0, so you’re of course free to have a look, use it (or not), and generally poke around as you see fit!
Check it out at: https://github.com/yaklabco/stave
(*) - Not that there’s anything wrong with sh or bash! I have half-seriously said, in the past, that anyone who doesn’t know their way around a POSIX shell probably shouldn’t get to call themselves a software engineer, and I half-stand behind that! 😉 But mixed-language projects should only be undertaken if there is no alternative. (Think of when you would resort to using CGO.) And just wanting to use a modern build system should not be an instance of that.
2. goctx
tl;dr -
“I’m in a function 10 calls deep from the closest context.Context object, and I suddenly find myself in need of a context; I know that calling context.Background() deep in my call stack is a no-no, and context.TODO() just kicks the can down the road. Is there a tool out there that can just automagically add all the necessary context.Context function/method parameter plumbing for me?”
Now there is: https://github.com/preminger/goctx
It also handles existing unused context parameters (_ context.Context) intelligently by just renaming them instead of adding a new parameter, and also reuses existing context.Context parameters that are not named ctx, if present.
Postscript
When I had just moved from academia back into software engineering, and was looking for my first post-academia job, I was asked more than once, “Can you show me any open-source things you’ve written?”
And my answer at the time was “No,” because I didn’t have any. It’s not that I wasn’t writing code - I was, which is why I was able to move back into the industry with relative ease - but all of what I was writing was strictly for my own use & consumption.
This wasn’t because I didn’t WANT to share what I was doing; it was because, when you are not immersed in the open-source community the way - arguably - only an active software engineer can be, you don’t have a real sense for 1. what might be potentially useful for others; 2. what is likely to already exist; and, perhaps most importantly, 3. what goes into maintaining an open-source project.
It is yet another way in which job-hunting on the one hand, and the screening of job-candidates on the other, is borked. (The over-reliance on leetcode being another one.) Now that I don’t really have a need to prove my prowess to anyone (at the moment at least), I have a couple of open-source projects to share 🙃