The Queen has died, which is sad, but not unexpected. A 96 year old dying is not an unlikely event.

What is happening now is that various institutions are going to use the event to claim relevance in the modern world.
This includes:

– The Church of England
– The Commonwealth
– The BBC
– The British Government

All of these are going to exaggerate their own worth.

We are going to have 10 days of official mourning.

The day that Diana died the BBC cancelled all normal broadcasting. This included the Shipping Forecast, which is essential for nautical travel. We need to watch that this time thing are handled better.

Just because a test fails it does not mean that the code is wrong.

I found a javascript ui test that was failing for changes that could not be caused by user input. The test api could introduce data in a manner that the ui does not permit. In this case the test was wrong.

In general a failing test can reveal:

– The code is wrong

– The test is wrong

– They are both wrong

I have now released kino_wardley version 0.4.1 to Hex.pm.

This is a small milestone as now all of the features that have been implemented now align to onlinewardleymaps.

This is limited to the following component types:

• evolution
• anchor
• component
• evolve

These can each have offsets. Evolve has four possible input formats:

component Kettle [0.5, 0.5]
evolve Kettle 0.79
evolve Kettle [0.7, 0.9]
evolve Kettle 0.79 label [10, 0]
evolve Kettle [0.7, 0.9] label [11, 12]

Note that you can only have one evolution per component and it needs to be defined after the component that it evolves.

Source for the above map

KinoWardley.Output.new("""
height 400
xevolution Experiment->Tested->Staging->Production

anchor User [0.95, 0.8]
component Livebook [0.8, 0.45] label [-80, 0]
User->Livebook
component Liveview [0.7, 0.7] label [0, -15]
evolve Livebook 0.55 label [20, 0]
Livebook->Liveview
component Phoenix [0.6, 0.8] label [5, -5]
Phoenix->Liveview
component Cowboy [0.5, 0.9]
Phoenix->Cowboy
""")

Given that yesterday Liz Truss became our new Prime Minister we need to remember why Boris Johnson had to resign.

It came down to his inability to tell the truth. This lead to a record breaking 50 ministerial resignations and one sacking.

On 6 June 2022, Boris Johnson faced a confidence vote, which he won by 211 votes to 148 (59% to 41%).

No conservative leader has survived such a poor result, even if they technically won.

This followed the partygate allegations and his varying “not aware of” defence to events he had attended.
There had also been two bye-elections that had not gone

It was the varying stories of how much was known about Christopher Pincher, who Boris Appointed as a whip that finally finished him. It came to the point that 50 resignations were required to bring down “Big Dog”

Despite what will be said later it was not a “coup” or a “change in the rules”.

Ministers are expected to be honourable gentlemen who resign should their honour be questioned.

I have been seeing some discussions about overuse of type safety and suggestions that you should make wrong states unrepresentable in the code that you write. This sounds like a good idea on the surface.

However in the real world data needs to travel across a network and between systems. The perfect type system stops at a network boundary. Recently I have been dealing with data validation and the reporting of the detected errors. If you don’t represent the error states then you can’t accurately report problems. You have to handle errors at the edge at least. This will create another translation boundary (which is another edge).

This gets especially difficult when you need an always on system that needs to cope with being deployed to without downtime. You need to cater for version N and N – 1 of a system. All those tight constraints can’t apply without causing an outage.

This project https://github.com/chriseyre2000/kino_wardley is an example of how to integrate a javascript based conponent into Livebook.

I had found myself writing an increasing amount of embedded javascript code in this project, which became harder to maintain. By extracting the javascript as an asset it becomes independently testable.

This does mean that I have an Elixir based tool that has more Javascript than Elixir.

This technique allows a livebook component to be implemented only requiring the following elixir code:

defmodule KinoWardley.Output do
  use Kino.JS, assets_path: "lib/assets/js"

# docs here...

def new(spec) do
    Kino.JS.new(__MODULE__, spec)
  end
end

It also requires the following package function (called as part of project in mix.exs)

defp package do
    [
      name: "kino_wardley",
      description: "A livebook smartcell that includes a Wardley Map.",
      files: ~w(lib lib/assets/js .formatter.exs mix.exs README* LICENSE* CHANGELOG.md),
      licenses: ["MIT"],
      links: %{"GitHub" => "https://github.com/chriseyre2000/kino_wardley"}
    ]
  end

This is all it takes to wrap the javascript component.

It does require a main.js file in the lib/assets/js folder. Here is the minimal version:

export function init(ctx, spec) {

// Use ctx to do something interesting with the spec
// ctx.root.innerHTML = spec
// console.log(spec)
}

The spec is the same value as passed to the new.

Hopefully this will make implementing Javascript components in liveview easier. Please keep to minimal dependencies to make your life easier.

Over the last few days I have been focussing on the how to render a Wardley Map. This post is going to cover the Why.

Wardley Maps are about value chains and their evolution against a axis. They can be used to discuss strategy without getting into stories. Its easier to challenge a map than a story.

The main benefit of having a map is that it allows you to clearly show how your current activities tie to the need that you are trying to resolve. In consultants terms this allows you to clearly state What Problem Are We Trying to Solve.

More accurately for a Wardley Map is how do we make changes that are related to a need. All Wardley maps start with an anchor in a user need.

Odd thought could I combine Impact Maps with Wardley Maps.

Impact Maps use the following chain:

Goal ->Actor -> Impact -> Deliverable

It makes sense to limit the number of goals in progress at a given time. If all work has to clearly tie back to a goal then there should be less waste on vanity items that don’t link to the goal. It also helps on prioritising things given this clarity.

Impact maps have a useful feature: when a goal is reached alternative routes can be stopped. This is something that other techniques don’t have.

I am planning on improving the Wardley Map Livebook component. If this becomes fully featured I would like to see if the Wardley Mapping community would be interested in using livebook as a storage and sharing format. This could allow the formation of a catalog of Wardley Maps.

Livebook is great for this in being highly suitable to version control and the files can easily be shared. You can put multiple wardley maps in one file with commentry.

José Valim has suggested that I split the smartcell from the component. This is going to happen soon.

Yesterday I started refactoring the oversized javascript function. It may be possible to extract them into a distinct file to aid testing and future development.

Other future items to work on include:

– fixing the evolve syntax to match onlinewardleymaps.com

– allowing alternative x-axis labels

– handle the offsets for labels

– handle annotations.