First off, my apologies for the deep silence of late. I’m pretty deep in the trenches when my Master’s semesters are running and I simply had to take a personal break during my summer. I’m hoping this post can help me pick up my cadence again!
I recently dove back into Elm development, only to find that the community has evolved rapidly between versions 0.16 and 0.18 (current as of this writing). I thought I’d share my notes on how I have my new development environment set up, now that we have more options beyond simple text editors (or vim).
Apologies for the extreme silence on my blog lately. I’ve started a Master’s degree program through Georgia Tech’s OMSCS program and it’s proving to be a challenging and time-consuming course of study.
From browsing around, it looks like the issue might be that the Elm compiler needs to set a LANG property in the Haskell code that runs the compiler to better specify encodings. Whether it’s relevant or not to the default encoding that failed here, I’m based in the US.
While the bug is still open, read on for a work-around, if you encounter the same issue.
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. Continue reading →
Continuing upon my last post, I’ll be showing how basic Signal functionality can be used to update a data model in Elm.
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.