This helper is installable via SPM via the GitHub repo

I’ve been using the Swift Testing framework more. Despite my previous grumble I do like the arguments: feature of the @Test macro and how much it can clean up tests:

@Test(arguments: [
	(true, "bob", 38),
	(false, "sue", 45)
])
func testUserPermissions(isBasketEmpty: Bool, username: String, age: Int) {
    #expect( ... )
}

The ability to supply a list of parameter variants to test is very useful. I think it tends to result in more exhaustive tests because of ease of use.

But being able to do easily whack in a list of argument variants soon reveals a slight annoyance. It’s not unusual to end up with a test like this:

The orth concept in 2D geometry and graphics is where, given some vector, we find a vector (line) that is at right angles to the original. We have a tiny bit of choice about how to do it – we can pick a vector to the left, or to the right – but it’s very simple (more here).

The equivalent function in 3D is one of those odd little problems where you are given some freedom with the answer, and you don’t really care about that freedom – just pick something please! – but you’re made to care about it anyway and do what feels like too much thinking. Bah!¹

I’ve exhibited at Colony of Artists several times, a vibrant art festival at Abbeyhill Colonies in Edinburgh.

One of the things I was showing and selling was my tesselation pieces: designs inspired by MC Escher’s work, particularly matamorphosing tesselations.

Some of these pieces play with negative space and the transition from 3D to 2D:

Sometimes I do some GLSL or similar: much graphics and geometry. I usually scribble down some back-of-envelope variant of the usual geometry equations, but I’ve never consistently decided what to call things or how to write them down.

Here I’m setting down the notation I’m going to use, and capturing the definitions. Reference pseudo-implementations are given too (Swift).

The equations and source given here have been unit tested; full source to come after tidying.

I took the new Swift Testing framework out for a spin and used it seriously on a small project.

Conclusion: to me, Swift Testing isn’t ready for serious production use, because either it’s buggy in some important ways, or Apple’s documentation is not specific enough about Testing’s design philosophy and how you should (or should not) use certain features.

My time ratio for “writing tests” to “work out why Testing is crashing” is 1:2 (or worse) at this point.

Testing tools should be well understood and well presented; we trust them with a lot. I think if issues are found with a new framework like Testing, this should be mentioned in the framework documentation.¹

In recent years there seems to have been a shift in interviews: less pairing exercises and more home coding tasks / projects.

After recent experience of home coding projects pre-interview, I’ve set a policy for my engagement in these tasks. I’m detailing it below, partly to avoid repeating myself to recruiters. Further down I give some reasons and discussion.

Currying. It’s one of the stalwarts of functional programming.

Is Currying something you need to know about to be a developer?

Nope.

Is it handy to know about?

Yes. Think of it as a pattern for your toolbox. It can allow some elegant solutions and less code.

Is it weird and esoteric?

No; there’s a certain ‘shape’ to currying code but once you recognise it, there’s no mystery.

Here’s something a lot of devs would like to hear:

I’d say that anyone at senior level (and definitely above¹) should have some justified² thoughts on the greenfield question: