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:
- 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.
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.
We’ll walk through some real-world problems, then introduce a little-known data structure that helps us solve all of them. This concept is often utilized in Haskell and Clojure, but don’t worry if you don’t know these languages. You won’t see any Haskell here.
This is a set of slides I put together for a training session at work. This is largely informed by aspects of development on my weather app. I’ll try to blog up some of the finer points in more detail in the future.
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.
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!
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.”
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.