Alan Gardner

In Part 11, we looked at how to fetch our initial seat data via Phoenix channels. Our application, when it loads, opens a web socket to the server and then gets the initial seat data over this connection. Now we want to take a look at how to send and receive data over that channel in response to user interaction with the site.

Since the last post we have seen updates to both Elixir and Phoenix. Furthermore, as of Phoenix version 1.1.2, the version of Brunch that is used has been upgrade to ^2.1.1. This means that we will end up upgrading Brunch to version 2.1.3 or later, which affects the elm-brunch package that we use to build our Elm project.

We took a look, in Part 9, at how to fetch our initial seat data via an HTTP request. However, one of the most compelling reasons to use Phoenix is because of it's first class support for Channels.

Upgrading to Elm 0.16.0. OK, so I know that I promised that I'd be looking at Phoenix Channels in this post, and don't worry, that post is coming soon. However a shiny new version of Elm was just released, and so we should upgrade for all of the goodness that it brings.

This part of the tutorial is actually going to be a bit of a detour. We're going to fetch the initial data for our Elm application over HTTP from a data API that we'll create in our Phoenix application.

Currently our application only allows us to model a given state and perform actions that result in changes to that state. We create an initial state for our application with the init function and thereafter are only able to change that state via the update function.

Let's take a moment to talk about what is happening behind the scenes in our Elm application.

We mentioned in part 3 that Elm has a Model - Update - View architecture. We've looked at the View and the Model, so let's turn our attention now to the Update. The best way to get a handle on what the update function will need to do is by taking a look at its type annotation.

So far Elm has been happily inferring the types that we are using in our application, and it will continue to do so. However let's take a moment to look at how we can make it more obvious to others who might read our code what types we are expecting.

Adding a Model and enhancing the View.

Adding a simple View to the Elm application.

Getting Phoenix and Elm to play together.

Installing prerequisites and generating a base Phoenix project

A style guide or style manual is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization or field. The implementation of a style guide provides uniformity in style and formatting within a document and across multiple documents.

I was tidying up my study last week and stumbled across my copy of the Lean UX book. It's a pretty quick read, so I thought I'd go through it again. I'm glad I did, because something struck me that I missed the first time round.

I recently started learning Elixir and decided for my first "real" project to implement a basic genetic algorithm. I like to do this to kick the tyres on a new language because it's a non-trivial problem that gives you a good idea of what it's like to work with that language.