Tag: best practices

pre-commit – a framework for managingmulti-language git pre-commit hooks

From the pre-commit homepage:

Git hook scripts are useful for identifying simple issues before submission to code review. We run our hooks on every commit to automatically point out issues in code such as missing semicolons, trailing whitespace, and debug statements. By pointing these issues out before code review, this allows a code reviewer to focus on the architecture of a change while not wasting time with trivial style nitpicks.

As we created more libraries and projects we recognized that sharing our pre-commit hooks across projects is painful. We copied and pasted unwieldy bash scripts from project to project and had to manually change the hooks to work for different project structures.

[…]

We built pre-commit to solve our hook issues. It is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit is specifically designed to not require root access.

Have a look at the list of all supported hooks. There’s plenty!

Passwords Evolved: Authentication Guidance for the Modern Era

“Passwords Evolved: Authentication Guidance for the Modern Era” is a good collection of guidelines and concerns for password management in the modern day.

Here’s the bigger picture of what all this guidance from governments and tech companies alike is recognising: security is increasingly about a composition of controls which when combined, improve the overall security posture of a service. What you’ll see across this post is a collection of recommendations which all help contribute to a more robust solution by virtue of complimenting one and other. That may mean that individual recommendations such as dropping complexity requirements look odd, but when you consider the way humans tended to deal with that (they’d just choose bad passwords with a combination of character types) alongside guidance such as blocking previously breached passwords, things start to make a lot more sense.

Now there’s just one more thing: as good as all this guidance is, practically implementing it can be somewhat trickier.

The Minimally-nice Open Source Software Maintainer

Brian Anderson shares a few thoughts on how to appear as a minimally-nice Open Source Software maintainer.  Maintaining Open Source Software projects is a demanding job.  And the more popular the project is, the more demanding it is.  Brian shares the following practices that minimize the effort while you still maintaining a positive atmosphere for the project’s contributors:

In summary, do these things if you want to appear to be nice, and also if you want to actually be an effective open source software maintainer:

By consistently exhibiting a few simple behaviors, one can at least look like a kind and decent person. Maybe someday we all actually will be.

Using non-breakable spaces in test method names

Using non-breakable spaces in test method names is a great example of how something can start as a joke and quickly turn into something very practical and useful.

if we decide to not follow PSR-2 naming for test methods because of readability, we might as well use non-breakable spaces since it’s even more readable…