Getting Started With Phoenix 1.4 (Part 3)

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.

https://github.com/chriseyre2000/rumbl_1_4

Getting Started With Phoenix 1.4 (Part 2)

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.

https://github.com/chriseyre2000/rumbl_1_4

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.

Singletons should be Humble

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.

Casing Conventions

These are the most common casing rules:

PascalCase

snake_case

camelCase

kebab-case

 

PascalCase is used in C# for classes and methods.

Java uses PascalCase for classes but camelCase for methods.

Elixir uses PascalCase for modules and snake_case for variables and functions.

CSS uses kebab-case.

Getting Started With Phoenix 1.4

These are the notes from working through the new version of the book.

Firstly Phoenix 1.4 has been released so the Phoenix install instructions are out of date so here is the update:

$ mix archive.uninstall phx_new
$ mix archive.install hex phx_new 1.4.0

(from: https://phoenixframework.org/blog/phoenix-1-4-0-released)

I also did not have postgres installed:

$ brew install postgres

initdb /usr/local/var/postgres

/usr/local/opt/postgres/bin/createuser -s postgres

(from https://stackoverflow.com/questions/15301826/psql-fatal-role-postgres-does-not-exist)

This will get you to the end of the hello app.

Railway Oriented Programming


https://medium.com/elixirlabs/railway-oriented-programming-in-elixir-with-pattern-matching-on-function-level-and-pipelining-e53972cede98

The common recommendation in Elixir is to let it crash (more accurately it is let a supervisor handle the error ). This is normally the case when you have small processes.

There is another pattern that can be used.

If all of your functions return {:ok, something} or {:error, reason} then technically the function is a Monad. This allows pipelines in which data and errors can be passed through cleanly.

Railway oriented programming takes this a stage further by having defined pipelines that have a good and an error route. It is possible for errors to be handled and returned to the good track.

https://zohaib.me/railway-programming-pattern-in-elixir/ 

Things worth studying in Elixir

It’s worth looking over the basics libraries of a language from time to time to see if you have missed anything useful.

For example Elixir has the very useful:

https://hexdocs.pm/elixir/Enum.html#map_join/3

This allows you to map some data then join it together as a single operation.

https://hexdocs.pm/elixir/Enum.html#min_max/2

This finds the smallest and largest items in an Enumerable by a given definition.

https://hexdocs.pm/elixir/String.html#split/3

This splits a string on a pattern and allows you to drop the empty elements. This is especially useful if there are patterns that you want to filter out as well. One iteration will split and remove the irrelevant items.

Expressing the Open Closed Principle in terms of Deletion

Most definitions of the Open Closed Principle talk in terms of extension. This makes it hard to check for because you need to imagine all possible extensions. There is a simpler equivalent test: How much would I need to change to remove this feature? Theoretically it could be as little as deleting one class that self registers (plus the tests). The advantage is that it’s easier to reason about removal.