Recently I moved an API integration to use Oban (https://hex.pm/packages/oban).

Previously we had been making API calls to a third party that we need to notify of changes. Our old implementation simple made the call and logged errors. This meant we had to spend time checking logs for possible problems.

After the move to Oban (we use the paid for add-on Oban Web) items needing attention now have a UI.

I have not yet worked out how best to model “wait for an email then retry”.

This is the magic incantation you need:

kubectl exec -it $(kubectl get pods | grep PROJECT_DEPLOYED_NAME | head -1 | awk '{print $1}') -- bash -c "/app/bin/PROJECT_NAME remote"

Elixir uses macros to generate some of the infrastructure that you need to use. This can result in modules that consist of a simple use macro and maybe one function. These modules are far more useful if you add some documentation about how it is to be used. Don’t just copy the generic parts, but mention the concrete use cases that you have.

I have been working on how to correct an identifier sent to a third party.
Their API does not have a rename option so I have to cancel the old version and create a new entry.

This is made more difficult because we had calculated the old identifier and not stored what we sent. In addition our system uses k8s so there could be multiple versions of the same application running at the same time. This also adds the wrinkle that a failed deploy would be rolled back.

The solution that I used was a fixed cutover date in the near future. This meant that before that date the old approach was used. After that date on the first change an upgrade was applied and for new and upgraded it would use the new correct identifier.

This does involve having code that can be removed at various points.
The pre code can be removed as soon as we know we are not rolling back.

The upgrade code will have to live for a year (the lifetime of the value in the third party service).

This gives an interesting option when structuring the code: plan for deletion. It is worth living with slightly more duplication than is normal so that the deletion can become much cleaner.

Now onto chapter 4.

This is where the book is using leex templates where as the latest generator is creating heex templates.

There are now a number of elixir template formats:

eex – this was the basic template version

leex – this was the first liveview template version

heex – this is adds support for syntax aware html

It appears that the modal dialog components of liveview have been significantly rewritten so that the chapter is a bit out of date.

We now have a `

heex – this is adds support for syntax aware html

It appears that the modal dialog components of liveview have been significantly rewritten so that the chapter is a bit out of date.

We now have a `

heex – this is adds support for syntax aware html

It appears that the modal dialog components of liveview have been significantly rewritten so that the chapter is a bit out of date.

It appears that live_modal has been replaced by live_component and live_modal/3 by modal/1

live_modal/3 means a function called live_modal with three parameters.

The 3 is called the arity of the function

Note to readers

`The heex templates are slightly different to the supplied leex template, but the basic logic remains.

phx-<SOMETHING> is mapped to a handle_event(“<SOMETHING>”, params, socket) function.

I have tried seeing if an updated version of the book is out (I am currently reading version B3).

Just found that B8 is the latest version so may need to go back and redo the start of the book again (or at least reread).

`

There are a number of property testing frameworks available for the Elixir ecosystem.

PropEr is the obvious one from the book.

StreamData is the custom build Elixir version that was almost added to ex_unit.

Of late I have found StreamData to be very useful. Add some property tests and your bugs become very easy to find.

I have even started to experiment with minimal property tests.
Call the function with all possible inputs and assert that the output is valid.
This is what Typecheck is trying to do, but that requires you to add annotations to all of your types, which does not yet work well with some other libraries.

Now onto chapter 2.

This is where having a moving library makes books like this difficult to keep upto date.
phx_gen_auth is now part of phoenix as of 1.6.

However it is a bit harder to work that out from the docs.
Adding the dependency leads to a mix resolution conflict.

​:phx_gen_auth is listed as 0.4 in the book, The latest version available is 0.7.0
However that only works with phoenix 1.5.2, where as the latest version is 1.6.15

phx_gen_auth has now vanished from hex.pm, and the github project is archived.

Here is the project currently at the end of chapter 2

https://github.com/chriseyre2000/pento

Still working on getting started.

I am using phx.new version 1.6.15 which is slightly different to the book.
The mix phx.new command no longer has the –live flag so some of the expected templates are not there.
This means that page_live needed to be created manually and the route added.

This is my current version of that module. It’s probably not what. is expected but it is good enough.

defmodule PentoWeb.PageLive do
  use PentoWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, query: "123", results: %{})}
  end

  def render(assigns) do
    ~H"""
    <%= @query %>
    """
  end
end

I have also found that you get some exotic errors if you make a typo in an ~L template.

If you type phn-click instead of phx-click you get asked about some missing methods.

I have started working through Programming Phoenix Liveview

These are my notes.

Currently working on the setup. Given that I had already got phoenix installed it is useful to add the following:

mix archive.install hex phx_new

docker run -d -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres:11

These bring the generator upto date and gets a minimal version of postgres running locally.
Don’t use these settings in production, but it will make making quick examples easier.

Expoloring the liveview socket.

iex> Phoenix.LiveView.Socket.__struct__ |> Map.keys
[:__struct__, :assigns, :endpoint, :fingerprints, :host_uri, :id, :parent_pid,
 :private, :redirected, :root_pid, :router, :transport_pid, :view]