Published June 17, 2016 ·
4 Minute Read ·
∞ Permalink
It’s easy to get stuck decoding JSON. First of all you have to understand how to
write a Decoder, and then… well, then you get to andThen. The docs have
a terse explanation (“Helpful when one field will determine the shape of a bunch
of other fields.“) and give the following example:
typeShape
= RectangleFloatFloat
| CircleFloatshape : DecoderShapeshape =
("tag" := string) `andThen` shapeInfo
shapeInfo : String -> DecoderShapeshapeInfo tag =
case tag of"rectangle" ->
object2 Rectangle
("width" := float)
("height" := float)
"circle" ->
object1 Circle
("radius" := float)
_ ->
fail (tag ++ " is not a recognized tag for shapes")
This is frustrating the first time you look at it. What’s important and
unimportant in the example? What shape of JSON do I even pass in here? But
there’s hope! Once you know where to look, it’s pretty simple. Let’s break it
down.
Published June 9, 2016 ·
2 Minute Read ·
∞ Permalink
I recently presented a talk on migrating from Elm 0.16.0 to Elm 0.17.0 at the
Elm remote meetup. I also gave the talk at the St. Louis Elm meetup, so if you
weren’t able to make it, here’s your chance to see the presentation:
Published April 22, 2016 ·
7 Minute Read ·
∞ Permalink
Earlier this year I published a “State of Elm” survey. 644 people answered. This
post details the results of that survey.
First of all, let me supply a big fancy warning: I am not a data scientist or
statistician. As I said about myself in the talk on this topic to the Chicago
Elm User Group: “I don’t even play one on TV!” Still, this was an interesting
project, but take my conclusions with a grain of salt. If you are a real data
scientist, please let me know. It’d be great for someone with that kind of
background to look at these data.
Some background: 644 people answered this survey. It ran between January 26,
2016 and February 8, 2016. Most of these questions took multiple responses, so
the totals add up higher than 644. Most of the questions also had an “Other”
field to fill in, so there’s a long tail on those questions. Without further
delay, let’s take a look at the responses:
Published March 11, 2016 ·
2 Minute Read ·
∞ Permalink
When it comes to cluster managers, Kubernetes is currently winning among developers. Like a lot of tooling, this comes down to Kubernetes having a great API. Why “great”?
Published June 4, 2015 ·
3 Minute Read ·
∞ Permalink
TL;DR: we’ve released
terraform.py, an Ansible dynamic
inventory for working with hosts that Terraform provisions. Read on for why:
Say you’re working on an Ansible-based project (like
I am.) You’ve got
everything running smoothly in Vagrant, and now you want to add support for a
cloud provider or two. Terraform is a great solution
to that problem, as
we’ve documented,
but then you have to find and support dynamic inventory providers for each of
those clouds, which means supporting more vendored scripts. Not only that, but
you have to be aware of the fact that most people trying your software won’t be
trying it in a brand new environment, but will add servers in an account they
already control. Most of the current inventory providers assume that they’re
controlling all the servers they can see, so this becomes a problem pretty
quickly. On top of that, all the dynamic inventory providers have to have your
cloud credentials and make remote calls so they tend to be, we’ll say, “slow”.
They also require additional software, requiring your users to have a specific
software stack.