Category: Development

Actions, Objects, and Context

Nouns

image00

Nouns describe things: objects.

  • The noun itself carries some description of the thing: “rabbit”
  • That description can be extended through adjectives: “dark rabbit”

Nouns have a limited context. They give you a concept of a thing at a particular snapshot in time. Without more context, they are limited.

Think of full sentences:

  • car
    • What does this mean? It doesn’t convey much information without more context.
    • If you Google “car”, you get a lot of very broad results – but does it help you solve your problem?
  • move car
    • Full context, assuming a car can move. Grammatically limited, but gives a broader idea.
    • You can Google “move car” and it gives very specific, contextually useful results.

Continue reading

When Worlds Collide: How Writing Fiction Intersects with Writing Code

I’ve recently become a big fan of author Trevor Schmidt’s science fiction novels. They’re pacing is perfect and the characters are wonderfully engaging. Despite his latest book being set in a truly alien environment, his writing is so immersive that you don’t even notice it. Trevor recently posted a guide to world-building for authors. As I read through his recommendations, I found a lot of his suggestions also apply to programming.

Continue reading

Haskell logo

Intro to Haskell’s conduit library (Conduit 101)

Haskell’s conduit library provides some deep capabilities for building transformative workflows, while providing many useful guarantees (such as constant memory usage – something that often bites Haskell developers). In this post, I’ll walk you through some simple examples of using conduit to transform text, but also demonstrate some useful variations on input and output.

Continue reading

Building APIs, Part 1: Halting-Driven Development

Far too often, we developers go to solve a problem and find ourselves in the mindless drudgery of writing boilerplate. Often, this boilerplate can distract us from the bigger picture of what we’re trying to accomplish.

This is a blog-ized version of a talk I gave recently. The talk was an interactive experience which doesn’t translate directly to text, but I’ll attempt to convey the same concepts.

If I fail, just remember: It’s December! Go play in the snow!

Continue reading

Fear Not the Refactor

One of my coworkers had a fantastic comment: “If you’re afraid to refactor a code base because you’re afraid of instability, your code is probably already full of bugs.”

I often speak with developers who fear to modify their code beyond the immediate feature or bug fix. Many say, “If it’s not broken, don’t touch it.”

I find that to be short-sighted thinking. Uncle Bob believes in the Boy Scout rule: Always leave the code behind in a better state than you found it. Martin Fowler believes in Opportunistic Refactoring.

It’s not as difficult as you might think. And as Martin Fowler says, “The whole point of refactoring is that it makes the code base easier to work with, thus allowing the team to add value more quickly.”

Continue reading

Range Testing

Off-by-one errors are the bane of the programmer. They’re right up there alongside the null reference exception that Tony Hoare infamously calls his “billion dollar mistake“. They’re responsible for everything from data loss to program crashes to security failures.

A wise programmer will know how to avoid off-by-one situations through the judicious use of techniques like using no raw loops. This won’t always rescue bad code, however. Proper range testing is an integral part of quality code assurance.

Continue reading