Tagged: applied
Drawing Triangles in Elm (Beginner)
Hey, let’s draw some triangles! If you’ve been following my last two posts on mouse chasing and drawing rays using Elm, this post will be a simple extension. If you haven’t already read those posts, I encourage you to start from the beginning, because we’ll be making iterative updates to practice getting our hands dirty with Elm.
Once again, this is targeted at newcomers to Elm, so we won’t be covering any advanced topics. If you want to see a quick demo, follow this link and start clicking around!
Composing Styles in Elm (Beginners)
I’ve recently started learning Elm and I’ve been excited to find this to be a very powerful language. I thought I’d share some tips as I learn. This post will be about structuring Elm-defined CSS styles in a way that they can be easily composed together.
My target audience for this post is users new to Elm. If you’re already familiar with Elm or Haskell, this will be pretty trivial, but if you’re new to functional programming, the syntax may confuse you!
To see what we’re going to build, you can open up the demo here.
Testing: How Not to Fire Ze Missiles
(The following is an adaptation of a talk I did concerning how to focus your testing and how to better conceptualize what kinds of testing to focus on.)
A lot of companies and a lot of developers like to talk about what kinds of testing they’re doing. But here’s a dirty little secret that the software industry won’t tell you: It’s much more common that you’ll be working at a company where very little of the code is regularly tested outside of production. I’m talking single digits code coverage bad. Many developers neglect tests, but a big part of that is because they’re unsure how to properly approach testing.
End Goals
When approaching the concept of testing your code, you should ultimately be thinking about the end goals that you want your code to accomplish. I like to focus this into three areas:
- Your code should do what you think it does.
- Your code shouldn’t do what you don’t think it does.
- You shouldn’t allow your code to make the same mistakes twice.
While most software doesn’t act in a life-critical role, it’s easiest to break these down by considering:
“If I make a mistake, will my code ‘fire ze missiles’?”
That’s the software equivalent of nuclear war. We don’t like nuclear war! Let’s avoid that, shall we?
Open Source Extravaganza!
I’ve been quiet here lately. That’s what happens when a heavy workload blends into a long vacation.
To help myself get back in the swing of this blogging lark, I’m made today an “open source dump”. Basically, I went through all the stuff I hadn’t made publicly available before and added mirrors on github.
Most of this is incomplete, trivial, and most likely crap. Read on for links!
Snippet Sunday: Mapping Over Large Numbers of I/O Resources
(This is the first in what will hopefully be a series of useful code snippets to solve problems. For each snippet, I’ll try to provide a basic solution to the problem, then ask my readers to post alternatives in the comments.)
Haskell provides some greatly composable functions in its standard Prelude library (accessible by default) that make performing operations on large lists of data very easy.
However, when dealing with certain resources (especially I/O resources, like file handles and network connections), these simple abstractions can get you in to trouble by easily exhausting available system resources.
What follows is a (very) simple method for mapping over large numbers of resources. It’s really just intended as an example for newcomers to Haskell, that may have encountered this problem.
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.
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.
voyage in tech 
You must be logged in to post a comment.