Posts

How does Json.Decode's andThen work?


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:

type Shape
    = Rectangle Float Float
    | Circle Float

shape : Decoder Shape
shape =
  ("tag" := string) `andThen` shapeInfo

shapeInfo : String -> Decoder Shape
shapeInfo 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.

Read on

ch-ch-ch-ch-changes in Elm 0.17.0


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:

Read on

State of Elm 2016 Results


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:

Read on

It All Comes Down to APIs


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”?

Read on

Introducing terraform.py


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.

Read on