Posts
-
Faux idempotency
Writing idempotent code is great. It should always result in the same final state, so it’s easy to test. And a failed run shouldn’t affect the next one, making it reliable and safe. But as you’ve noticed I used “should” in both places, because code which looks idempotent may not be.
-
Consistent fonts in Firefox
Are you sick of every single website using different fonts in the name of branding? You can easily force websites to use the browser default fonts:
-
Rarotonga tourist tips
The Cook Islands recently opened up to tourists from New Zealand. Since the COVID-19 situation meant we wouldn’t be able to meet our family and friends without something like four weeks of hotel quarantine, we decided instead to take this first chance at an overseas experience in over a year. A friend happened to have booked a vacation overlapping a couple days with ours, so after arriving we met up for a chat. We learned a bunch of things about practicalities on the island, and this is a collection of those I can remember plus a few more we found out afterwards.
-
Dependabot on GitLab
GitHub has made it as easy as six lines of YAML to get started with Dependabot, and I wanted to get as close to that as possible.
-
JetBrains IDEA repository sync
If you have a paid version of IDEA, you probably already know that you can automatically sync your settings to the currently active account. That doesn’t cover all use cases though:
-
echo 'I wrote a Bash book!' >> /dev/worldI wrote a book — The newline Guide to Bash Scripting! I’ll let the intro speak for itself:
-
We need programming mentors
tl;dr Mentoring is probably the best way to advance the art of programming, by keeping hard-earned lessons fresh.
-
August bug
Remembering a classic "time travel" bug reminded me of a fun time in Bash. How to reproduce in four handy steps:
-
Test naming tips
No naming scheme is going to guarantee good names, so here are a few intentionally vague test naming guidelines:
-
Start test names with “should”
The purpose of a test is not just to enforce some behaviour on the code under test. When the test fails it also should provide enough information to understand which behaviour failed, where it failed, and (at least superficially) why it failed. If the only output of a failing test is just a binary value like “FAIL”, that test is only giving one bit of information to the developer. A good test framework will also print the test name and a call stack. We can’t change the call stack much, at least not without changing the semantics of the test, and how to actually write the test itself is a whole other story, but what does a useful test name look like?