sgillis

Highcharts.js is a JavaScript library to generate graphs inside the browser. It has a pretty simple API that allows you to create a wide range of different graphs. I stumbled upon this library when looking for a solution to create some graphs in an Elm web app that I’m working on.

Highcharts documentation gives an example to create a simple bar chart. In it, you are instructed to create a div element, load it using jQuery and call the highcharts function on the element. So something like this

<div id="container"></div>

<script>
$(function () { 
    $('#container').highcharts({ ... });
});
</script>

The argument to highcharts is just a dict that contains all data and configuration options for the chart as described in their API documentation. Easy enough.

But I want this to be integrated in an Elm web app, where I can’t just create a div element and load it injQuery. This is because the app uses elm-html, which uses the virtual-dom project behind the screens. This means that a virtual DOM will be created by the app, and rendered at runtime. So it’s not obvious when to call the highcharts function on the div that will contain the chart, since we don’t know when the HTML element will be present.

Since Elm compiles to JavaScript, every function you use in Elm should have a translation to a normal JavaScript function that will be executed in the browser. Those basic building blocks that make up Elm are defined in the Native modules of the elm-lang core.

While I was working on the Chrome app for the Mooltipass, I needed to change one of those native JavaScript functions on which Elm is based. We are using the dropDown function to create a dropdown HTML element, but the problem was that there was no way to say which element had been selected. So we needed to add an extra argument to the function that would be used to indicate the selected element.

Haskell is well known for its advanced type system and the safety and certainty it brings to your code. I’ve read the phrase “if it compiles, it works” from time to time. It is true that the type system catches a lot of mistakes early on and prevents you from creating certain types of bugs. However, it still pays of to write code tests in Haskell. That’s why there are a couple of great testing libraries like QuickCheck and HUnit.

Since both have a different approach to testing (HUnit uses the more traditional approach of xUnit architecture whereas QuickCheck does a type of testing often called property testing), I would like to use both. After some googling I found the test-framework library that enables you to do this easily. Another option is tasty, I didn’t try this but it should work as well.

Trying to set up the tests took me a little longer than I would have liked, so I’m documenting what I found here hoping that it will be of help to someone (maybe it will help myself in a few months).

Whenever you have a problem with some open source project, there’s often a good chance that someone else has already fixed the problem you’re facing on a forked repository. This is the great thing about open source software.

However, it might happen that you need fixes from multiple forks. Or maybe you need a fix from a fork, but the fork is horribly outdated and doesn’t have the latest fixes from the master repository. What to do in this case?

One of the reasons why I like Docker is that it makes development with external services much easier to do. If you are working with a microservices architecture it is a regular occurence that you want to work on service A, but you need access to service B somewhere in service A. Doing that with Docker, and more specifically docker-compose, is a cinch. I will not go into the details in this blog post, but essentialy you define your docker-compose.yml something like this

serviceb:
    image: username/serviceb

servicea:
    image: username/servicea
    links:
        - serviceb

When you execute docker-compose up servicea it will automatically start service B and make the IP of service B available in the service A container via an environment variable.

A small annoyance I had with this set-up was that whenever I wanted to connect to service B directly, I needed its IP not in a container but on the host machine. The default way to get access to its IP is by executing

docker inspect --format "{{ .NetworkSettings.IPAddress }}" <container_name>

The downside of this approach is that whenever I restart service B, it will get a new IP address, forcing me to look it up again. And I always forget the exact syntax for the format option, so I have to google it everytime.

Let’s fix that!

While working on a project with Elm, I needed to include some radio buttons in a Elm generated form. While there is a great example on how to create forms with text inputs in Elm, I couldn’t seem to find examples or documentation on how to handle radio buttons.