David Owen’s blog

As a musician, I began to watch the different ways that people practice music. I noticed a pattern there, and started seeing the same pattern whenever people practice.

Our psychology makes it very easy to slip into practice ineffectively. On the other hand, simply understanding what and why makes it easy for you to have really effective practice.

It's the difference between mastering something versus just wasting your time. And you can boil it down to just one simple rule.

Continue reading "Effective practice"

A fun thing about refactoring code is that after one refactor is finished, the next candidate is easier to see.

In An abstraction gone wrong, we refactored the state variable of a simple tokenizer from an integer into an object. Now that that's done, another problem is staring at us in the face. It's in this code:

if (state == INITIAL) {
    // ...
} else if (state == IN_NUMBER) {
    // ...
} else if (state == IN_STRING) {
    // ...
} else if (state == AFTER_STRING) {
    // ...
} else if (state == ESCAPING) {
    // ...
}

Continue reading "Fixing dispatch"

A given abstraction can be helpful in one situation and harmful in another. Often, we use abstractions out of habit without thinking critically about their benefit. Sometimes, an abstraction is harmful because it distances us from other features of the language, as I wrote in Abstractions.

Here, I give an example of such an abstraction, which happens to be very common in the domain of parsing, but which comes up in many other places. I also begin refactoring the code to use a more helpful abstraction.

Continue reading "An abstraction gone wrong"

Abstraction allows us to wrap up complication into a simpler form. We can take a set of things, with all of their nuances and details of combination, wrap it all up and call it new thing.

But, abstractions can sometimes get in our way. If they're not designed properly, they may not go together in convenient ways, or they may distance us from other useful parts of the language.

Continue reading "Abstractions"

Recently, I needed to document firewall rules for a cluster of machines. The document needed to spell out rules by machine, but that meant that connections between machines were described in two places: the machine requesting the connection, and the one servicing it.

Context-based programming gave me an easy to describe a connection in a single place, but generate a document that connection in two places.

I can also use the same source file to generate the firewall rules themselves.

Continue reading "Context-based programming is DRY"