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!
In my last post, I showed how you can generate a simple mouse-chasing effect with Elm. That was an accidental side-effect for my true purpose: To demonstrate how to draw triangles in Elm. This post will continue along that journey, demonstrating how to generate rays from a fixed point out to the current mouse location using the standard Elm Architecture.
I won’t be introducing any new concepts here; I’ll simply be layering on a little bit more complexity on top of what we’ve learned in the previous posts.
Signals are a non-obvious concept to grasp at first glance. The Reactivity guide contains good in-depth instruction about how Signals work, but spending a little time playing with them can really help grasp how they work.
We’ll walk through a simple example to generate a snake-line line that follows the mouse. To see what we’re going to build, you can open up the demo here. (Note that this only works with a mouse, not with touch events. Exercise: Extend this example to support touch events using Elm’s Touch module.)
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.
(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.
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?
There are a lot of different thread lock mechanisms that .Net provides. Some are better than others. Some you really shouldn’t use at all. This post will walk you through some of the most common scenarios and provide suggested mechanisms for dealing with them.
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!
(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.
The Commercial Haskell SIG recently sent out a survey through Haskellers.com. They plan on releasing the survey results to the public, but I found the questions interesting enough that I wanted to post my own response to it. Whether you agree or disagree with my responses, I think a conversation around the questions is highly relevant both to those just building an interest in Haskell as well as for those who have been practicing since Before Time Began.
For the curious, read on!
[Slight editing of survey responses was done for better readability. These responses are also highly subjective, of course – they are the personal thoughts of the author of this blog. :)]
Caution! If you received the survey and haven’t yet responded to it, please don’t read this post until you do so! I’d hate to see my writing skew their results.