I love being bored.

It's a stupendously easy problem to solve with quick hits. It's not entirely novel to this generation — magazines, books, comics, television, etc. have had a hand in staving off what can be an uncomfortable feeling.

But I savor it when I can. It makes room for one of my favorite hobbies: Daydreaming.

Not enough credit is given to daydreaming. It might be that there's not craft to it, perse. There aren't daydreaming contests, there's no coach I can hire for it. Maybe people see it as lazy. It certainly doesn't fit into a puritan work ethic.

And yet, paradoxically, it's essential, even in pragmatic efforts. Software problems are often solved while doing the dishes. Books are written while on walks. And music is composed in that twilight realm between wake and sleep.

But, I'd hate to justify it with a specific outcome. Much like music teaching advocates who would only speak of the increased SAT scores for music students, I feel that we'd be missing the point.

I will say, writing is a fun vehicle for it. A nice balance of structure and flexibility. A place to watch thoughts crawl through the page, turning here and there, until a piece comes together.

But, nothing quite beats having time to stare at the ceiling and see where the thoughts go. There's a magic to it, "between the click of the light and the start of the dream".

Another go at a different rif!

Thanks to Let's Talk About Math Rock for the tabs and curated licks.

It's been a while since I've shared something from the sketchbook!

Except if it were a slow jam.

Thanks to Let's Talk About Math Rock for the tabs and curated licks.

The night-time desk.

So good. 🤘

Thanks to Let's Talk About Math Rock for the tabs and curated licks.

Wahoo!

There's a piece I've been meaning to write about how Super Mario 64 was my medium for curiosity growing up. That running around in these worlds expanded my own, that taking to the sky in game made me curious as to what would happen if you flew into the skyboxes. What other discoveries could be made out there?

But, then again, maybe the painting says it all.

Greetings from Colorado! I'm releasing my first lil album since the move from Texas.

There's so much natural beauty out here. Mountains frame the sky and streams run in parallel with trails. I couldn't wait to capture some of that magic with sound!

Hope you enjoy, thanks as always for listening!

• Support the ablum on 🤘 Bandcamp.
• Listen on 📺 Youtube.
• Listen on 🙉 Spotify.

Never Meant — The Wonder Wall of Midwest Emo.

I've never felt so seen by a soundfont cover.

From cartoonist Zac Gorman:

In regards to process, I prefer to focus on figuring out what works best for me as opposed to what is or isn’t standard practice for contemporary comic artists. It has always been important to me to find a process that I’m comfortable with, that allows me to produce work quickly and that is the most fun possible, in order to stay engaged and productive.

I think a lot of what we understand as an artist’s “style” or “voice” is based around the development and maturation of their working process as this tends to produce a lot of variables, so what works for me may not work for you, but I think that fun, speed and comfort are the three factors I look for most in any process. Quality actually becomes a shockingly arbitrary value if you don’t first develop a process which helps you to finish work, enjoy the process of making work, and desire to make new work.

Play around with what works for you.

Another vote for Process > Product.

What's so appealing about an artist's visual style is how it communicates so much of their process. There's a great deal of humanity naturally baked in.

You would think this only applies to loose styles like Zac's, with their wobbly lines or flowing gestures. But even really polished, highly rendered pieces can expose how much an artist revels in the details.

Either way, fun has to be a major element.

(Even in software — I was speaking with a colleague about how the experience of working with a language can change the joy in the process and, of course, the end product.)

A scene from my walks with Lucy around our new neighborhood!

      /`·.¸
     /¸...¸`:·
¸.·´ ¸ `·.¸.·´)
: © ):´;      ¸  {
 `·.¸ `·  ¸.·´\`·¸)
`\\´´\¸.·´

A few years ago, I was torn up about leaving the teaching profession. I had this assumption that leaving the career meant that I was letting go of an identity: Someone that mentored. Someone that served. And someone doing creative work.

I was delightfully surprised as I stepped into the work of software. It turns out there's plenty of creativity, daily opportunities to be in service of others, and teaching/learning are requirements for the job.

It's noble to commit to a profession. However, the reality is that the humanity is in the effortless integration between roles and skills. A call with a friend is an opportunity to teach. So is playing with your dog. So is onboarding a new colleague. So is writing a blog post.

The same is true for many of the professions. Do you have to be a painter to be creative? Or are you creative when you come up with a solution to an interpersonal dispute? Are you only a leader if you manage others? Or can you lead by example from a position "lower" on the ladder? Are you only an entrepreneur when you run a company? Or do you find ways to innovate within your team?

The roles are merely robes to wear. Easily changed, we can step into them at any time. You may find yourself wearing certain pieces in unlikely places.

Unit tests, as a rule, are meant to be quick to run. Part of their benefit is the ability to cover the entire codebase and give you feedback on its working status in a few seconds.

Let's look at an exception: Code that is timing sensitive.

In my case, I have a function that imitates throttling behavior. Meaning: the first call will set a timeout, subsequent calls will be gathered, and after the timeout, a merged result will be returned.

How would I test that functionality?

An Aside

The way my function is gathering calls is trivial for today's topic. If you're curious: In my real-world case, I'm using an in-memory Redis server to store args passed to function calls. But I'll leave out the details. Let's get to the testing!

Considerations

As mentioned, we want to keep the benefit of a tight iteration loop. Test runners may even limit the time a test can run. Bun, our test runner of choice today, errors if a test takes longer than 5 seconds.

To handle this, if the function tested typically has a timeout set for 60 seconds, we'll truncate it to 1 second for testing.

export const getFunctionTimeout = () => {
    if (process.env.NODE_ENV === "test") return 1;
    const envValue = process.env.FUNCTION_TIMEOUT;
    if (envValue) return parseInt(envValue, 10);
};

Typically, we test multiple cases with multiple tests. A describe block will have separate it blocks, each test being decoupled from the others. If we are working with timeouts, however, writing multiple tests will dramatically increase the time it takes for our tests to complete if they run sequentially.

Writing the Test

To simulate delayed function calls, I'm going to write a method that returns a promise that resolves based on the position in a list of arguments:

const additionalMessageInterval = (getFunctionTimeout() * 1000) / 10;

const getStaggeredFunctionCalls = (argValues: ArgValues[]) =>
        argValues.map((args, i) => {
            return (async () => {
                if (i) await wait(i * additionalMessageInterval);
                // Call the function being tested.
                await myThrottleFunction(args, callback);
            })();
        });

Note the additionalMessageInterval. Instead of hard-coding a number and coupling my tests, I'm making the interval dynamic based on the value returned by getFunctionTimeout.

Now, I'll generate those function calls and pass them into a Promise.all call:

describe("myThrottleFunction", () => {
    it("should handle throttling args", async () => {
        const callback = mock((args: Args) => {});

        await Promise.all([
            ...getStaggeredFunctionCalls(firstSetOfArgs),
            ...getStaggeredFunctionCalls(secondSetOfArgs),
        ]);
    }

    // . . .
}

After this, I can ascertain the behavior of my function. Here, I'll do so by checking if my callback was called the expected number of times:

expect(callback).toHaveBeenCalledTimes(2);
expect(callback).toHaveBeenCalledWith(firstSetOfArgs);
expect(callback).toHaveBeenCalledWith(secondSetOfArgs);

Viola! By using a series of promises with timeouts, I've now simulated throttled behavior in my tests. From here, I can expand the test as needed to handle the unique behavior of my function.

Have a good time playing with this!