• 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/world

    I 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?

  • Why I'm not working on vCard validators

    The vCard 3.0 validator is ten years old. The standard has moved on, Python has moved on, and I'd like to think I've learned a thing or two as a developer. But I'm not working on any vCard validators, and probably won't be for the foreseeable future.

  • Mitre10 web site dark patterns

    Dear Mitre10

  • If you can't support your users, tell them!

    Most free and open source projects these days have plenty of documentation for producing a good bug report. This is really helpful, and we should continue improving our reporting tools and documentation. There's a special warm feeling following the submission of a bug report with exact version numbers (of course the most recent stable), idiot-proof steps to reproduce, anything relevant from /etc, /proc and env and maybe even a core dump. Many projects will answer these quickly and either repair the defect or explain where you went wrong in assuming how the program should work. FOSS at its finest, and respect all round.