Category: Development
Actions, Objects, and Context
Nouns
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.
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.
Haskell Library for Forecast.io
Two of the joys of working with Haskell is how quickly code can be prototyped and how quickly it can be (safely) refactored. What follows is a quick tale of how a library for the Forecast.io weather API came to be. I’ve also released it on Hackage and github.
Zippers: Not Just for Pants Anymore!
Real-World Problems
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.
Automating the Application Lifecycle
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.
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.
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!
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.”
Building APIs, Part 3: Controlling Code Complexity
This is a talk I gave for a developer training session recently. This is the third part of the series, but the first two parts are not (yet) posted. The prior two were more interactive sessions; as I adapt them for review, I will post them here.
Part 1 has now been posted.
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.
voyage in tech 
You must be logged in to post a comment.