Here are the notes on how to write a smart cell:

https://www.strangeleaflet.com/lets-write-an-elixir-livebook-smart-cell

Before I build the smart cell I need to change the input format from a list of strings in javascript to a text block that uses the current syntax of onlinewardleymaps.

The current major deviation is the implementation of the evolve type which I am using two coordinates rather than one. Also there is no explicit offset mechanism, instead labels have a white underlay.

It is also missing title, alternative x-axis titles and annotations.

I had initially tried to implement this with VegaLite, but found that was more suitable for traditional charts. D3.js is a lower level library. You have to do slightly more work yourself, but gain complete control: everything in software development is a compromise.

This is a functional Livebook containing a Wardley Map

https://github.com/chriseyre2000/livebooks/blob/main/d3wardleymap.livemd

Livebooks are easy to share and version control.

This is the basic example Wardley Map.
It is a tea shop that had decided to build their own kettle with a specialist power supply.

The following is the evolved version purchasing a standard kettle and using the mains supply:

I am planning to create a Kino Library in hex to wrap this up.
It would also be useful to port this to Mermaid.

The input syntax is close to that used by https://onlinewardleymaps.com/

Here is the current state of the diagram:
https://github.com/chriseyre2000/livebooks/blob/main/d3wardleymap.livemd

This is a great summary of Wardley Maps and how to run a workshop:

https://pipdecks.com/blogs/workshops/how-to-run-a-wardley-map-workshop

These two concepts work together really well.

Recently I have been experimenting with Json Schema as a way to formally describe an API. It lists all possible inputs that are accepted in a single document. Equivalent schema documents exist for other contracts.

A property test is a way of stating invariants about a system. You write tests that make assertions about the system that are always true for a range of inputs. The testing tool generates an increasingly complex input an runs a series of assertions reporting the simplest case that fails.

If you have a formal input specification the simplest property test you have is I can accept this input without rejecting the message. The contract document gives you a source for the generators.

By creating a generator based upon a specification document allows the tests to keep up with all possible inputs. This is the closest that you can get to a formal proof for system correctness without requiring a single typesystem (which in a distributed system may be impossible).

Here is the starting point:

https://github.com/chriseyre2000/livebooks/blob/main/wardleymap.livemd

Here is an issue in mermaid to add wardley maps to Mermaid: https://github.com/mermaid-js/mermaid/issues/1661

I am going to have a look at seeing if it would be easier to use Kino to put online wardley maps into a livebook or to implement in mermaid.

This tool is great:

https://onlinewardleymaps.com/

However it is not very collaborative.

I am wondering if it would be possible to recreate it in an elixir livebook?

Let’s start to show the amazing power of livebooks without even touching custom code.

First install livebook from this site: https://livebook.dev/

This provides a host to run a livebook.

Start a new livebook

Paste in the following url then hit enter:

https://github.com/chriseyre2000/livebooks/blob/main/EventStorming.livemd

You now have a local copy of my mermaid starter for Event Storming.

Yes livebooks allow you to open sample pages that happen to be sitting on a website.

If you click on the edit button that gives you the ability to see the source used to create this.
How over the main image and hit +Block and you can add another diagram block and copy and edit the key that I created.

Theoretically these can be edited collaberatively.