I am now onto chapters 7 – 9 which deal with OTP. This is the really interesting part of the book. I am unsure that my sample code is accurate as there are very few tests and the supplied sample code has diverged from that which you enter if you are following along. I can’t tell if I have made a mistake or if the supplied code is wrong (my suspicion is a little of both). This has taught me a lot about debugging Elixir applications which will be useful. What looked like a cryptic error message was actually precise and detailed where the genserver received a Map when it was expecting an atom. Adding guard clauses is a great way to flush out these problems.
The book is written as a long exercise where you add code snippets to your application to update. Given that I am using an epub format I can’t simply cut and paste the code, so I am typing it in. This is interesting since epub adds a trailing
- when wrapping lines which takes a while to get used to. This has a certain error rate so I frequently use `iex -S mix` to check for typos. This works well for sections where the required pieces are defined first. These later chapters were written outside-in (a technique that I like, but normally back with tests) so this does not help.
One of the downsides of these long exercises is that it can be hard to find a mistake in a snippet that has been updated several times.
The database additions have slowed me down as I don’t currently have a local working postgres version. The samples for the database completely miss out the credentials required, but this information is available elsewhere.
Here is the docker-compose.yml that I got to work (note that the port is marked host:container):
In practice we would use a better username and password. I can have a portable database setup by using:
docker-compose up -d db
Here is the config that I used to get the database setup:
config :mastery_persistence, MasteryPersistence.Repo,
The use of OTP fails to mention the default 5 second timeout behaviour built into OTP requests. It does cover using timeouts to handle late responses and has a good explination of the use of via.
Poncho projects are an interesting concept. You just create a full mix application in a subdirectory (or a parallel directory). This allows it to be moved into a distinct repository later on should it be needed, but is less overhead than an umbrella project.
Now on to integrating the mastery_persistence into mastery. This part looks a bit rushed. They are asking us to change files that have not yet been created (config/config.exs).
I have worked through the examples and pushed the finished details to:
I am currently at: 6963329
All that remains is the testing chapter and going back and making sure everything works.