I have now finished the testing chapter (Chapter 8).
This was rather frustrating to work with since you have to enter a lot of code before you get to run the tests. This means that it is very easy to make a mistake and spend a lot of time tracking down the issue.
This chapter gives a lot of details on testing a Phoenix application at different levels.
Beware some of the later parts of the chapter – it has a trick problem that is intended to fail and explains on the next page. This can be frustrating if you had previously made a few typos and were running each test as you go.
Recently I have been working on a set of projects that use Docker extensively. I received an error message that appeared to be an out of disk space message. At first I thought it was the host machine that was out of space. On further investigation it was the docker volume that was out of space. It makes sense for containers to have limits it’s just odd to encounter them – when you shut down the containers the volumes remain until you clean them up.
Here are some useful clean up commands for Docker.
docker volume rm $(docker volume ls)
docker rm -f $(docker ps -a -q)
docker volume prune
docker rmi -f $(docker images -q)
I have finally updated the library after the feedback that I received at the joint user group. The code now handles all of the four sample Contentful spaces and empty spaces.
The library used the content type id as the name of the type in Neo4j. There is a mismatch in rules so I have prefixed it with “type_”. This avoids leading numbers.
Stops all of your docker services:
docker stop $(docker ps -aq)
Continuing the way through the book.
Now have reached the end of Chapter 6.
This adds video to use associations. It includes some of the clever techniques that Phoenix uses to allow the templates to be customised.
By adding an action method you can customise the parameters passed to the various utility methods:
def action(conn, _) do args = [conn, conn.params, conn.assigns.current_user] apply(__MODULE__, action_name(conn), args) end
This allows details from the conn to be decomposed and passed as a parameter.
I am still working through the book. Programming Phoenix >= 1.4
Now upto the end of Chapter 5.
Here is the current state of the Repo.
This is a long chapter that adds the user login and session management.
It can be painful fixing typos as there is a lot of code to type and the tests don’t arrive for a few chapters. This time it was only a few small issues. Mostly restarting the server gave the exact compilation error.
There have been a few small changes from the first version. Passwords and emails have been separated from main user table – which makes sense. This is trivial to implement.
The Singleton pattern is one of the simplest in the Gang of Four book. This does have it’s place in code. It introduces some complications for testing.
I have recently started working on some Groovy code that uses the @Singleton attribute. This is a Groovy construct that turns any class into a Singleton. Groovy has the ability to alter the Abstract Syntax Tree between parsing and compilation.
This makes the code hard to test as the annotated class now has two responsibilities, it’s function and being a Singleton.
The easy way to split this is to use the Humble object pattern. Move the responsibility into a distinct class and use the Singleton as a gatekeeper.
Singletons work best if supplied by architecture not directly in a component. They are fine if Stateless but not otherwise.