I’ve been dabbling a bit with the mdgriffith/elm-style-animation package for Elm 0.18 and so far it looks like quite a capable library. I did encounter some headwinds with layering multiple effects on the same HTML element at different times, so I scratched out a basic framework for extending animations. I’ll walk you through the basic extensions I’ve layered on top of the standard Elm Architecture.
What’s the goal of all this? Being able to define easily reusable animations, just like CSS classes! And being able to manage the complexity that comes along with creating many different animations.
Read on for details, or just grab the code from this Github repo and run with it.
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).
Right now, my basic environment looks like this:
- Running on OS X Sierra
- Elm 0.18
- Visual Studio Code
- Sascha Brink’s Elm Language Support extension for VS Code
That’s all I’m using to get a nice rapid development environment up and running.
I ran into a compilation bug when following the “Task Tutorial” in Elm’s Reactivity documentation.
This is the output I got when compiling (where Main.elm is the exact copy/paste from the “HTTP Tasks” section of the docs):
> elm-make Main.elm --output=index.html Success! Compiled 1 modules. elm-make: index.html: commitAndReleaseBuffer: invalid argument (invalid character)
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!
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?
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!