Less Wrong Than Yesterday

Tinkerable Software

This is a post I wrote for Software Testing and Quality Engineering magazine (now https://www.stickyminds.com) and subsequently published on a long-defunct site of mine. Laurent Bossavit asked that I recreate the web version. It was originally published in 2001.

Last night, I dreamt we'd just bought a new house, my ideal house: enough bedrooms, a nice lawn, fully furnished, the works.

The first thing I noticed was that some electrical outlets weren't in the right place. Not being handy with electrical work, I found an electrician in the phone book and called him in. He set to

Continue Reading...

On designing with sum and product types

I understand product types in statically-typed FP languages; they're records:

I understand sum (or union) types; they're cool:

As I learn Elm, I'm been having considerable trouble combining the two: should I model the problem as a sum type inside a record? as records in a sum type? For a good while in my Eecrit project, I bounced around alternatives like these:

The worst part was that I was developing iteratively, and new features kept breaking my model: I didn't find my design converging in the way that I'm used to from TDD and dynamic languages (be they OO like

Continue Reading...

Phoenix, Elm, and multiple single-page apps

In the running example used in Programming Phoenix, client-side apps are launched from the master app.js file. The Javascript that's loaded for every page checks to see whether this page has the id it's looking for. If so, the code to launch the app is run.

That's fine for the book, as it avoids irrelevant complexity, but I found it awkward as my overall app grew. Multiple clauses of this form:

const ivDiv = document.querySelector('#iv-target');  
if (ivDiv) {  

... are untidy. I'd rather have the "start the client-side" code exist only on the single page

Continue Reading...

Customizing `mix phoenix.gen.*` tasks

Because I am who I am, I've deviated from some default Phoenix file layouts. For example, rather than models having a single changeset function with two parameters you combine in different ways, I've tentatively decided I'd rather have variants like new_action_changeset, create_action_changeset, update_action_changeset, etc. That means a model should start out looking like this:

Similar changes are needed in the controller - and in model tests - and in controller tests. It would be tedious to run the default mix.phoenix.html task and then edit those files to support my quirkiness, so I

Continue Reading...

Thoughts on testing Phoenix views

TL;DR: I'm not a huge fan of extensive unit tests for rendered HTML. Despite that, I've put a fair amount of work into some test support code for Phoenix views. Mostly, that was because I thought it would be a good learning experience for me, a novice in Phoenix and Elixir. But I came up with some testing conventions and code that might be useful to others. They might also serve as a model for testing other complex data structures.

Why don't I like automated tests for views?

  1. Nowadays, it's usually very quick to visually check a change.

  2. You

Continue Reading...