Don’t try and test everything in a single test. Each test should have a single reason to fail. If you are using infrastructure in your integration tests it is worth having some simple tests that check that it is present. These are simple to write and quick to run and will make the rest of the test suit far more stable.
Assertions about infrastructure is about is that S3 bucket present. Have I created that database. Is the database at least this version. These are assertions that would be far too unstable to have in a distributed manner. In fact these should explain how to setup or configure the resource when they fail. Having a test framework with multiline strings can give you a way to tell future people (including you) how to fix something.
Yesterday I attended the local Royal Proclamation. This is a public event that repeats the official statement made in Westminister the day before.
This is a tradition that predates modern communication methods, but does seem a little antiquated. Having a Town Crier introduce the local Mayor (flanked by his mace wielder – more of a golden hammer).
The pronouncement was also dated. It presumed that the entire crowd was Christian (which is now not true for the majority of the population). Having public collective worship is something I have not seen since school (outside of Weddings and Funerals).
They expected the crowd to sing the first verse of the national anthem (there was deliberate enouciation of King) shout God Save The King and recite the Lords Prayer. Most did.
Moving to CD should not be hard, but it is a change in mindset.
You will accidentally release something you shouldn’t. You need a fast rollback/forward process. Long lived caches can be an enemy here.
You need to think small changes. Deploy that then work on the next part.
Avoid excessive git merges as this can hide what you are deploying. Having a small unit test that fails if your code has been lost in a merge is a good safety net.
Feature Flags are your friend. Keep them positive, clearly named and not nested. Prune them aggressively. If you are using AB tests write your code so one side or other can be easily deleted after a test.
I have found that ex_docs has some very useful documentation options. This has allowed me to fully document the specification used by the kino_wardley_map component: https://hexdocs.pm/kino_wardley/syntax.html
Here is a wardley map rendered with the latest version:
Sample Wardley Map
I have started to diverge from the onlinewardleymaps.com conventions.
The new group option allows highlighting of parts of the map. The following. is the code required to render the map.
KinoWardley.Output.new("""
id myid7
height 800
width 800
title Tea Shop
anchor Business [0.95, 0.63]
anchor Public [0.95, 0.78]
component Cup of Tea [0.79, 0.61] label [19, -4]
component Cup [0.73, 0.78]
component Tea [0.63, 0.81]
component Hot Water [0.52, 0.80]
component Water [0.38, 0.82]
component Kettle [0.43, 0.35] label [-57, 4]
evolve Kettle 0.62 label [16, 7]
component Power [0.1, 0.7] label [-27, 20]
evolve Power 0.89 label [-12, 21]
Business->Cup of Tea
Public->Cup of Tea
Cup of Tea->Cup
Cup of Tea->Tea
Cup of Tea->Hot Water
Hot Water->Water
Hot Water->Kettle
Kettle->Power
annotation 1 [[0.43,0.49],[0.08,0.79]] Standardising power allows Kettles to evolve faster
annotation 2 [0.48, 0.85] Hot water is obvious and well known
annotations [0.60, 0.02]
note +a generic note appeared [0.23, 0.33]
style wardley
group Problem [0.43, 0.35, 20, 70] yellow red
""")
The next obvious addition is an indication of how to display inertia. I don’t like the onlinewardleymaps.com implementation so may have to think about this.
I have released version 0.5.0 of kino_wardley . This now includes notes, titles and annotations.
Sample wardley map
This comes from the following code:
KinoWardley.Output.new("""
height 800
title Tea Shop
anchor Business [0.95, 0.63]
anchor Public [0.95, 0.78]
component Cup of Tea [0.79, 0.61] label [19, -4]
component Cup [0.73, 0.78]
component Tea [0.63, 0.81]
component Hot Water [0.52, 0.80]
component Water [0.38, 0.82]
component Kettle [0.43, 0.35] label [-57, 4]
evolve Kettle 0.62 label [16, 7]
component Power [0.1, 0.7] label [-27, 20]
evolve Power 0.89 label [-12, 21]
Business->Cup of Tea
Public->Cup of Tea
Cup of Tea->Cup
Cup of Tea->Tea
Cup of Tea->Hot Water
Hot Water->Water
Hot Water->Kettle
Kettle->Power
annotation 1 [[0.43,0.49],[0.08,0.79]] Standardising power allows Kettles to evolve faster
annotation 2 [0.48, 0.85] Hot water is obvious and well known
annotations [0.60, 0.02]
note +a generic note appeared [0.23, 0.33]
style wardley
""")
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.