This post was supposed to discuss Ansible as the next primer series. However, I found Jeff’s posts and YouTube videos much better than what I would achive via a plain post. So definitely checkout Ansible 101 by Jeff Geerling. I also recommend purchase the eBook for further reading and as a reference manual for common tasks. Thank you.
Bazel is an open-source build/test framework similar to Maven, Make, and Gradle.
It features:
This post is a reading notes about the official documentation on Bazel version 3.4.0. You can skip these intros and jump directly to the sample repo to get started.
https://www.bazel.build ↩
WireGuard 1 is a simple, fast, and modern VPN that utilizes cryptography.
It encapsulates IP packets over UDP. The general workflow can be summarized as:
wlan0/eth0 but named wg0/wg1…)It’s similar to the ssh model. Both parties have each other’s public keys and they communicate by exchanging packets encrypted by the public keys through the WireGuard interface.
https://www.wireguard.com/ ↩
Last time I talked about gtest in the gtest primer, and in this post we discuss the usage of “value-paramterized” tests. In general, when you write a simple test case and verified it is working, what is the next step? Maybe you want to add more test cases! But how? Adding them by “hard-coding” the logics in the source files? It’s not a good idea since cases may evolve and we may later add new corner cases, maybe months later. At that time, you may already forgot how to write a test case using gtest.
Value-parameterized tests are a good way to organize your test cases and group them in a logical manner e.g. test cases for a particular API. I use value-parameterized tests and a YAML configuration file to dynamically add/reduce my test cases, so that adding or removing a test case is as simple as updating the YAML file.
Git commit messages can help you understand why something happened months or years ago for your collaborators or yourselves. It affects a project’s maintainability, and hence plays a critical role in a project’s long-term success.
This section we summarize some common techniques to write a healthy commit message. Of course there are variations on the styles and conventions adopted by different projects/orgs, you should pick one and stick to it as much as possible to reduce chaos and inconsistency.