A major theme of The Art of Unix Programming is to separate policy (what to do) from mechanism (how to do it). Policy is things like business rules that change rapidly in response to the real world; often policy for daemons like Nginx are entirely defined in config files. Mechanism on the other hand changes much slower, typically you write once and then only need minor bug fixes and other maintenance. Often this looks like library code such as a HTTP request parser. It’s good to write integration tests to verify policy code, and unit tests to verify mechanism.
The article is describing a specific way to encode a policy layer decision by renaming a mechanism layer function. If you enjoyed the post, I recommend reading the book! Probably the most worth-while programming advice book I’ve read.
Thanks for framing it in these terms. Trying not to stretch too far per post, but the posts after this in the series will pivot from functions–and it’ll be interesting to see if this framing survives the pivot or not.
I’m starting here mainly because I thought this bit would make a nice standalone post, and because function names are a familiar place to start dissecting something for my target audience. But I also hope that the connections I’ll try to make will make it easier to see if some practices and ways of thinking throw sparks when transferred around…
That simple script won’t reliably exit if preconditions fail, because the exit 2 is conditional upon the echo to stderr succeeding. So running with 2>&- to close stderr will cause the fail path to fail to successfully exit.
A major theme of The Art of Unix Programming is to separate policy (what to do) from mechanism (how to do it). Policy is things like business rules that change rapidly in response to the real world; often policy for daemons like Nginx are entirely defined in config files. Mechanism on the other hand changes much slower, typically you write once and then only need minor bug fixes and other maintenance. Often this looks like library code such as a HTTP request parser. It’s good to write integration tests to verify policy code, and unit tests to verify mechanism.
The article is describing a specific way to encode a policy layer decision by renaming a mechanism layer function. If you enjoyed the post, I recommend reading the book! Probably the most worth-while programming advice book I’ve read.
Thanks for framing it in these terms. Trying not to stretch too far per post, but the posts after this in the series will pivot from functions–and it’ll be interesting to see if this framing survives the pivot or not.
I’m starting here mainly because I thought this bit would make a nice standalone post, and because function names are a familiar place to start dissecting something for my target audience. But I also hope that the connections I’ll try to make will make it easier to see if some practices and ways of thinking throw sparks when transferred around…
Rule of thumb: Intention revealing names are generally preferable to behavior revealing ones.
That simple script won’t reliably exit if preconditions fail, because the
exit 2is conditional upon the echo to stderr succeeding. So running with2>&-to close stderr will cause the fail path to fail to successfully exit.Indeed. One of several simplifications (like excluding the variables) made to reduce line count. I wondered who’d call it out :)