Using Livebook as a Model

I have been having a quick experiment with livebook.

This is an interactive website that can be used to easily share Elixir code.
Think of it as Juypter Notebooks but with the backing system being Elixir rather than Python.

It has a very neat docker image:

docker run -p 8080:8080 livebook/livebook

This will stand up a local website running livebook. The console will give you a link (including a token) to allow you to access it.

You can create notebooks and add sections in Markdown or Elixir.
The great thing is that these can be interactively edited by multiple concurrent users.
You can also export a notebook as a file, publish the details and import it into another livebook.

I have been thinking about using this to recreate an old mac simulation tool. This tool allowed you to build a model with data flowing through it and you could use it to see bottlenecks.

I have three code blocks:

The first is the initialisation block

Agent.start_link(fn -> 0 end, name: :complete)
Agent.start_link(fn -> 0 end, name: :iteration)
Agent.start_link(fn -> 0 end, name: :qa_backlog)

The second is the update block

Agent.update(:iteration, fn x -> x + 1 end)
Agent.update(:complete, fn x -> x + min(10, Agent.get(:qa_backlog, & &1)) end)
Agent.update(:qa_backlog, fn value -> max(value - 10, 0) end )
Agent.update(:qa_backlog, fn value -> value + 20 end)

The third is the output block

:ok = IO.puts "Iteration #{Agent.get(:iteration, & &1)} Backlog #{Agent.get(:qa_backlog, & &1)} Complete #{Agent.get(:complete, & &1)}"

If you put the three blocks into livebook then you have the start of a model.

This is a very simplistic model. It attempts to show that the QA team will never be able to keep up with the two dev teams feeding it work. This could become far more sophisticated (with a random percentage of QA items failing and being returned to the teams). The idea here is to show how you can use an Agent in livebook.

I am going to see if you can add visualisations.

Programming Phoenix LiveView – Part 1

I have now started work on the Phoenix LiveView Book.

Still early days on this book.

However this will make creating a phoenix app much easier:
docker run -d -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres:11

That makes a default password postgres image.
I would not recommend default passwords for anything other than local demo databases.
This makes setup much less painful.

Here is the repo that I am working on:

Patching AngularJS

2021 is a very unusual time to be returning to use AngularJS. This is the version of Angular that is going out of support at the end of this year! However I have a client that has a very large codebase that needs to be moved to the latest stable version before they start the move to a more modern Angular version.

A key feature of AngularJS is that it is built using a dependency injection framework. This means that it is possible to replace parts of the supplied libraries with alternative versions. For this codebase this can mean an older version of one of the system components. For example the $http component changed it’s call interface between 1.5.6 and 1.6.0. It would be great to move the entire codebase to the more standards compliant promise library, but this is just not feasible for the size of the codebase. There are thousands of uses of the old syntax.

This does allow us to take advantage of working on a library that has been abandoned – we know all of the changes that the later versions have made and also know what the replacement looks like. This gives us a chance to look at the direction we need to take the code before we migrate. This is not going to be quick.