JavaScript has no real concept of keyword arguments, and at the same time is remarkably flexible about what you pass in to a function. As a result it is easy to get confused or tied in knots about what to pass to a function in what order. I have found that it’s better all round, for my own sanity, and for others who use my code, to always only pass a single argument called params to my functions, and embed everything in there.

Before I try to convince you this is a good idea, let’s take a look at how…

Back near the start of my career I worked for a large UK university library on a project to capture and publish PhD theses electronically. This was to increase the access and availability of previously hidden research.

Prior to that, PhD theses were submitted to the library in print (two bound copies) and held in Special Collections where readers could come and view them.

My colleague and I were tasked with understanding the traditional thesis submission workflow and their subsequent usage in research, and how that would translate into a digital environment.

One of the things we did was go…

Writing tests with good coverage and that work all dimensions of your code is time consuming, repetitive, tedious and subject to the law of diminishing returns.

When we start out as developers writing tests, we tend to take the approach of one test per case, and aggregate related tests into suites. For example, you might see a suite like this:

class TestMyCode(TestCase):

    def test_first_case(self):
        assert some_stuff()

    def test_second_case(self):
        assert some_other_stuff()

    def test_third_case(self):
        assert yet_more_stuff()

Each test case needs to carry out all its custom prep, execution and assertion stages. If these cases are closely related, this could result in a…

Do you ever write software by accident? It happens to me all the time. “Oh, I could just write a quick script to do X” / “hm, this would be better if I could pass it some arguments” / “this code is messy I’d better split it up into functions” / “urgh, I could really do with some model objects to make this easier” / “ah, damn, I’ve written some software”.

You know how it goes.

A while ago I wrote a couple of posts about managing the text of specifications in order to minimise the effort of maintaining consistency…

JavaScript is resolutely not a traditional Object Oriented language, no matter how much it may give that appearance. It belongs to a class called “Prototypical” languages, in which there are only Objects, no Classes, and a process called “delegation” stands in place of what OO programmers would understand as inheritance.

(As an aside, this class of languages includes the beautifully minimal Lua, which you may have encountered if you’ve done any games programming through the wonderful Love2D framework).

As a result, us oldies who come from traditional OO backgrounds sometimes struggle to think about the language correctly. When I first…

I hate truthy tests, and I don’t think you should use them, and I oppose them whenever they appear in a Pull Request.

Why? Because in my experience, more bugs arise from broken truthy tests than from any other class of error. And the bugs from broken truthy tests can also be the worst to track down.

If you don’t know what I mean by a truthy test, it’s this (in Python, but we’ll look at some other languages in a moment):

if some_variable:
    do_something()

This asks whether some_variable evaluates to true before carrying out some conditional action.

It’s that…

If your horizontal bar chart labels are too long for your left margin, by default in NVD3 the labels will simply overflow the space, and disappear off to the left, which is annoying and looks unprofessional. On these charts, space for the vertical axis labels is at a premium, so to do a good job it’s not enough to implement word-level wrapping, we need to incorporate hyphenated wrapping and label truncation.

One of the reasons that space can be limited for these labels is the temptation to make your horizontal bars around a single text line height. In that case…

I recently needed to check the links in a dataset to find out if they were active or how they were failing. Flippantly, I thought that this sounded pretty easy; after all you could just script a GET on each link and record the result, then you’d know, right. Right?

Wrong.

This is a story about what I learned in the surprisingly subtle and imprecise world of link checking.

First, it’s worth noting that I couldn’t immediately obviously sign up to a link checking service — the dataset was “offline” so it wasn’t like I could have a link checker…