Logs: Fix known issues or exclude them from the main view

When supporting a system you frequently need a view of the aggregated errors that the system is generating.
However there will sometimes be an error in the logs that you just can’t fix or it is not worth fixing yet.

Exclude these from the main view as they will mask out real problems further down the frequency table.

This is especially important if you are trying to fix the most frequent error each week, If the same error is always there no progress will be made.

Logging Errors: Read them regularly

A log message that is an error is a failure of a system to do something. Typically something can be done to improve matters (a retry, an alert). If you are going to log them look at the logs on a regular basis.

If a client side error was caused from a system outside your direct application it is fine to make another call to store that error,

Give your log messages a useful correlation id. Natural ones are best (the order id being processed) but artificial ones are also useful, if sent through the system.

Thoughts on Alexa Skills

My employer is having a Hackathon and the team I am on is investigating Alexa skills.

The plan was to use the email address of the Alexa account to match against the email address of the customer we already have. It took us all a little while to get a hello world Alexa app stood up. Alexa has been around long enough that there are now more wrong setup articles than good ones.

The Amazon documentation is lacking in actual code samples alongside the documentation.

It does have a full setup including it’s own github build pipeline and deployment tools. The downside is that this makes it more difficult to integrate with your own build tools. For example it wants you to push.to master on it’s repo, yet ours has that name restricted, so we need to branch again to push it to github.

The debugging experience is painful. The default logging system is very weak. A simple list of log events that is hard to search.

The simulator is missing key features. You can’t trigger permission requests and there is no way to bypass these. You need permissions to fetch a basic email address, and getting this involves an interesting dance with various other services.

Let’s see if this gets better on Day 2.

Why Loki does not break the Time Travel Rules of Endgame

Professor Hulk gave a long talk on the rules of time travel in Endgame. These were based upon his logical reasoning. It is possible that those limits were enforced by the method of Time Travel used: move to parallel universes and you are not going to have consequences on your own.

However Loki using TVA gateways did manage to move backwards on the single timeline and have a conversation that altered the future.

I suspect that The Hulk only had logical reasoning to define the rules, where as Loki found out by experience.

Classic Elixir Bug

Data in Elixir is immutable. This can lead to some subtle bugs.

Here is the example Ecto.Multi sample

defmodule PasswordManager do
  alias Ecto.Multi

  def reset(account, params) do
    Multi.new()
    |> Multi.update(:account, Account.password_reset_changeset(account, params))
    |> Multi.insert(:log, Log.password_reset_changeset(account, params))
    |> Multi.delete_all(:sessions, Ecto.assoc(account, :sessions))
  end
end

This could be rewritten as

defmodule PasswordManager do
  alias Ecto.Multi

  def reset(account, params) do
    multi = Multi.new()
    multi = Multi.update(multi, :account, Account.password_reset_changeset(account, params))
    multi = Multi.insert(multi, :log, Log.password_reset_changeset(account, params))
    multi = Multi.delete_all(:sessions, Ecto.assoc(account, :sessions))
  end
end

Forget to capture the multi at any step and you will lose the specific change from the batch.

This is insidious when moving from the first to the second to add a calculated value or when the function you are adapting only uses one multi

Wheel of Time season 2

After watching season 1 of wheel of time I started reading the books. Currently I am on book 13 of 14. This article is trying to be spolier free.

The TV adaption was always going to differ from the books. We are not going to get 14 seasons with all of the characters

Season 1 did a good job of introducing the world, and managed to introduce some characters earlier than we would otherwise have met them.

Starting the characters off a little older than the books returns to the authors intent, before being asked by his publisher to make them younger.

Critical numbers have been reduced and there are 8 Forsaken and it only takes 8 to still someone – these required 13 in the books.

There is a slight flaw in timing in the new episodes. Perrin is with a group tracking Pendan Fain from the end of the previous season yet the group in the White Tower seem to have been there longer. This could just be a syncronisation issue with his letter being written and received some time later.

Several of the characters are in different places to the book. Rand and Matt need to be with Perrin. Matt could join the girls on their trip to the coast later on. Not sure how Rand will make the journey.

An interesting note on the opening catchup – all characters that were focussed on will be important later on.

Security > Usabilty

Recently there have been a number of changes to systems in the name of Security.

Security is a good thing, but so is being able to use a system.
A system is perfectly secure if no-one can use it. However it scores zero on the usability scales.

Consider a useful balance.

For example some systems insist on emailing a code to confirm logins. This can be useful.
The login link expires after a finite time, also a good idea.

When the link expires before the email is delivered or is invalidated when the next is requested will lead to loops where it is not possible to access a system.