Joep Schuurkes (Posts about programming)

How adding a flex-wrap almost spiraled out of control

Joep Schuurkes — Sat, 23 Aug 2025 22:00:00 GMT

How does a project get to be a year late?
...One day at a time.
- The Mythical Man-Month (anniversary edition), Frederick P. Brooks Jr., p. 153

Last week I found a minor bug in the application my team is building. For every election committee, we have a page showing all sessions of that committee. These sessions are shown as a row of cards. Playing around with the number of sessions, I discovered that the row keeps on growing, resulting in a horizontal scroll bar:

Benchmarking counterstring implementations in TypeScript

Joep Schuurkes — Sat, 22 Feb 2025 23:00:00 GMT

Earlier this year I posted about how I implemented a counterstring function using "fake it till you make it". I also posted about different ways to implement counterstrings. In this post, I want to share how those different implementations compare performance-wise.

To do this, I used both Tinybench and vitest bench (which uses Tinybench). The results are basically the same, but their default output is slightly different.

The nine implementations

Before I present the results, I should describe the different implementations and how they differ from each other. The actual code of each implementation is available on Codeberg. Here I'll only mention what makes each implementation interesting compared to the others:

Comparing counterstring implementations in TypeScript

Joep Schuurkes — Sat, 18 Jan 2025 23:00:00 GMT

In my previous post "Using 'fake it till you make it' to implement counterstring" I mentioned the implementation I included there, wasn't my initial implementation:

I did something less performant with reversing an array, because I had looked at PerlClips's source code. How that came about and what I learned from it, is for another blog post.

This is that blog post.

As a matter of fact, I currently have 9 different implementations of counterstring in TypeScript. Including two that are not mine: one is from PerClip but translated to TypeScript by me, the other is EvilTester's implementation. There are some interesting lessons to take, both from comparing the code of the different implementations, as from comparing the differences in performance. The performance-part of the comparison will have to wait for my next post, though.

Using "fake it till you make it" to implement counterstring

Joep Schuurkes — Sat, 04 Jan 2025 23:00:00 GMT

Last week I implemented PerlClip's counterstring in TypeScript. A counterstring is a string that tells you how long it is. For example a counterstring with length 9 looks like this: *3*5*7*9*. Each number tells you the position of the asterisk following the number. My main goal with this project is to learn more about front-end development.

Before I could start doing any front-end stuff, however, I needed to write a function that correctly generates counterstrings. Since I approached it in a way that I really enjoyed, inspired by Llewellyn Falco "Fake it till you make it", I figured it would make a good first post about this project.

The idea behind "fake it till you make it" is simple. Start with an implementation covering a single case ("fake it") and then pull it apart little-by-little until it becomes an actual program ("make it"). As Llewellyn explains in the video, the value of this technique is that it's a lot easier to start from a working example and proceed from there than it is to get complete requirements.

I did approach counterstring from the opposite direction, though, as Llewellyn did with Fizzbuzz in the video. Llewellyn starts with FizzBuzz length 20, so a case covering all the logic. Then he refactors it using different techniques, such as separation and encapsulation. While I started with counterstring length 0, the most simple case, and then worked my way up to larger lengths.

Your default response should be a safe one

Joep Schuurkes — Sat, 28 Dec 2024 23:00:00 GMT

In his training DVD "Ukemi from the Ground Up", Ellis Amdur explains how your default response should be a safe one. In the context of the video it's about what your action should be in response to an Aikido technique like kote gaeshi: Do you jump and do a breakfall? Or do you roll? The breakfall is the safe option. The roll is the comfortable one, except for the times you should have done the breakfall. Then you break your wrist...

Unfortunately, the choice between breakfall and roll is not up to you. Kote gaeshi is a throw executed through a wrist lock¹ and it's up to the person applying the technique what kind of throw it will be. Either they gently apply the wrist lock, guide you to the ground, and you can roll. Or they apply the technique more dynamically and there's no time to roll. In that case you have to jump and turn over your arm to fall safely on your side/back. That's what's called a breakfall.

As you can imagine, there's not always a lot of time to think and decide between roll and breakfall. And if there's no time to think, whatever your default response is, that's what your body will do. That's why your default response to kote gaeshi should be the breakfall, the response that's safe in both circumstances. The worst case scenario is that you take a breakfall you didn't need to. While the alternative, defaulting to the role even when you should have done the breakfall, comes with significantly worse consequences.

Tackling test automation in a new language

Joep Schuurkes — Sat, 10 Feb 2024 23:00:00 GMT

While there's value in learning all the ins-and-outs of one particular language, its ecosystem and its testing libraries, I think there's also a lot of value in having experience in several. Or at least, in two. If you only know one, you don't really know what's essential and what's incidental to the one set of tools you know. You don't know from experience in what ways things could be different.

Picking up a new language is not trivial though, especially if it's your second one. There will be a lot to learn. You will notice similarities between the new language and the one(s) you already know. Sometimes those similarities will help you, sometimes they will mislead you.

Also, it's more than picking up a new language. There are also the testing libraries you will use and the language's ecosystem (e.g. how to install those libraries¹ or how to set up a pre-commit hook with a linter). That's quite a package.

A lesson from every language I've used

Joep Schuurkes — Thu, 28 Dec 2023 23:00:00 GMT

Throughout the years I've used quite a few different languages - if you allow me to be somewhat generous with the word "use". One language I actually feel proficient in. Some languages I've only done coding exercises in. And one language I've only used for a total of maybe 10 minutes, but that did really help out a whole team.

I do believe we should be that generous, both towards ourselves and to others. For an industry that likes to talk about imposter syndrome, we seem to enjoy saying "You're not a real ... unless..." a bit too much.

Listing these languages for myself made me wonder what I had learned from them. Did I just learn how to write some code in each of them? Or did I also pick up some more general lessons? Turns out I did.

(clj 12) Core concepts of functional programming with Peg Thing

Joep Schuurkes — Sun, 06 Aug 2023 13:13:36 GMT

Chapter 5 of "Clojure for the Brave and True" explores two core concepts of functional programming: pure functions and immutable data structures. It wraps up with walking you through the code¹ of a game called "Peg Thing"², which uses "everything you've learned so far: immutable data structures, lazy sequences, pure functions, recursion - everything!"

So what is this Peg Thing?

For a full description and the code of Peg Thing, you can follow the links in the paragraph above. In this post I'll only share what's relevant to describe what I learned about functional programming through Peg Thing.

(clj 11) Moving on from some unsolved exercises

Joep Schuurkes — Thu, 29 Dec 2022 15:08:36 GMT

At the end of chapter 4 of "Clojure for the Brave and True" there are four exercises. This post is about me deciding to move on to chapter 5 after solving 1.5 of these exercises.

The challenge with these exercises

A good example to talk about the challenge with these exercises is the second one:

Write a function, append, which will append a new suspect to your list of suspects.

(clj 10) The mapify function of (clj 9) revisited

Joep Schuurkes — Wed, 13 Jul 2022 19:02:36 GMT

In my previous Clojure post I covered the code example at the end of Chapter 4 of "Clojure for the Brave and True". Or rather, I focused on a single function in the example, called mapify, and described how I figured out what it does. At the end of that post I shared my disappointment:

Having done all this work (and writing) I can't help but feel a bit disappointed. In the end, the function does not seem to do a lot.

And I shared a Python version of that same function, claiming that it basically does the same thing¹.

However, less than a week after publishing the post, I got a very kind email by someone named Martin. And "in defence of clojure and to maybe reduce your disappointment" Martin pointed out the two versions are not as equivalent as I claimed, because the Clojure version is more general than the Python version. So I looked at the two version again and the way they are different turned out to be quite interesting - interesting enough to write a follow-up post.