I have returned to this book now that the book is out of beta.

I also started using a different repo: https://github.com/chriseyre2000/property_testing

The only difference between my code and the samples is that I am using the pipe syntax where possible. My Execism.IO background in Elixir is also forcing me to make style changes to keep the code in Elixir format.

Part 1 chapter 4 does use the erlang queue library. It would be good to be able to get Elixir documentation on erlang packages.

The part 2 sample code is broken but I am working on fixing in my repo.

It turned out to be easier to download the code from the pragprog site.

These are my notes as I am working my way through this book from PragProg. I am reading a beta version of the book so things may change. I’ll be posting this to my github repo: (https://github.com/chriseyre2000/designing_elixir)

The introduction starts by building a simple counter application as the domain and wraps it in a send/receive process with an API.

The code samples here are clean and clearly ordered. The only note that I have found so far is that I needed to delete the autogenerated Count.ex file to avoid a warning.

Takeaway from the intro: Supervisors are about lifecycles.

Takeaway from type introductions: Send the functions to the data!

Chapter 3 typo: response.ex is misspelt (reported).

excoveralls looks to be a better code coverage tool.

I spent some of today trying to work out why a Docker image that I was using did not work correctly.

This is the most useful command for debugging a docker image:

docker run -it ubuntu /bin/bash

This is based upon the ubuntu image but feel free to replace it with whatever you are trying to debug.

You can do the same with a docker-compose

docker-compose run --entrypoint /bin/bash

I am now looking at how to run a gradle build inside a docker container and then extract the log files. It will be especially useful to be able to view the log files. It may be possible to add a web server to view them.

It’s now also possible to stand up a Jenkins server on your dev machine to test Jenkinsfiles before deploying them to the build server.

docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts

Chapter 4

I am still working my way through this book.

The main difficulty that I am finding with chapter 4 is the scattered nature of the example code. It’s all small snippets, some of which references code in the previous chapter.

This is in addition to the Erlang => Elixir translations:

• atom => :atom
• VariableName => variable_name
• moduleName => ModuleName

Some of the Elixir functions are reordered for consistency.

#Erlang
1> gen_server:start_link({local, timeout}, timeout, [], []).

#Elixir
1> c "Timeout.ex"
2> GenServer.start_link(Timeout, [], name: :timeout)
3> GenServer.call(:timeout, {:sleep, 100})
4> GenServer.call(:timeout, {:sleep, 5001})

The GenServer will by default timeout if a message takes more than 5 seconds to respond.

Samples for Chapter 4 have been pushed to

https://github.com:chriseyre2000/scalability_ex with hash: cc8dd44

Chapter 5

The Erlang sys module can be reference from iex using :sys

The the log commands require atoms.

:sys.log(Frequency, :print)

:sys.log(Frequency, :get)

Now at hash: 830c1ea

Chapter 6

This is an odd chapter for Elixir as the Finite State Machine was considered defective and was not adapted as a wrapper. I am going to skip this chapter

Chapter 7

GenEvent has also been Deprecated

This is another of my book walk through series. This time I am working on Designing for Scalability with Erlang/OTP.

This is the book that goes into detail about OTP in general.

Chapter 2 : Introducing Erlang

https://github.com/chriseyre2000/scalability_ex (edc0862)

The above is a repo with commit hash of where I have currently got to.

So far we have some basic recursion and some manual send/receive logic.

We have now seen the first use of ets – Erlang Term Storage a simple persistence layer.

You build it you support it (even if not first line). It’s the other side of continuous delivery. You also need the right to fix anything that could wake you up. It focuses the developers minds to proper testing, logging, auditing and error handling. There is no wall.

Management frequently believes that the value of the advice is proportional to the cost. Also, knowledge gained outside an organisation is more valuable than that gained within.