Things I Believe is on my periodic reading list – maybe it should be on yours?
So the following intrigued me:
Use the same language for the little tools and scripts in your system too. There are few good reasons to drop down into bash or Python scripts, and some considerable disadvantages.
A modern programming language is the most expressive tool we have for describing all aspects of a system.
This means: write configuration as code, unless it absolutely, definitely has to change at runtime.
Also, write the specification of the system as executable code.
And, use code to describe the infrastructure of your system, in the same language as the rest of the code. Write code that interprets the description of your system to provision actual physical infrastructure.
At the risk of repeating myself: everything is code.
Corollary: if you’re writing JSON or YAML by hand, you’re doing it wrong. These are formats for the machines, not for humans to produce and consume. (Don’t despair though: most people do this, I do too, so you’re not alone! Let’s just try to aim for something better).
And then I read Why you shouldn’t use
func main in Go.
And then I needed to set up a test harness where two gateway instances were needed to test rules that execute between gateways. In the past, I’ve been a big fan of
envsetup.sh for starting up my test instances. However, after reading the above, it become obvious – why not write a Go program that fires up two GW instances. Matt’s pattern makes it really easy to do this.
go run is a nice scripting environment …
If all parts of your system are abstracted as functions, it is very simple to stitch together a test harness that instantiates the entire system, runs tests, etc. And, since one program is watching all the instances, it is very easy to do something in one, and then look for a change in another.