Try to keep the logs quiet. If something is happening we need to know. Logs can tell you that things are happening or have gone wrong. A request for intervention should be made once, pteferably by opening an alert on OpsGenie
Try to keep error messages clean. If possible treat warnings as errors. Noisy compile messages will hide real errors.
This was an inspired and truely British thing to do to form a queue to pay tribute to the late Queen. Currently it is a 10 mile queue that can take upto 24 hours to complete.
Queues as entertainment are not new as Legoland has been selling this for years (one visit had 7 rides each preceded by a one hour queue). This is however the first time we have had a televised queue with its own TV feed and incinsistently run twitter feed. At one point the queue was closed on twitter, but failed on two counts: they did not tell the people at the start of the queue, and when they did is it resulted in the formation of a second unofficial queue.
Self organising queue management is something inherent in the British character. Americans are amazed that post office queues work without anyone policing them. This is a single queue with several servers handling it. These form in many stores and self manage.
In most CI setups a build process is triggered on push to a PR (or a given pattern for the name of the branch).
To avoid having to fetch everything anew it it common to cache succesful runs of the main branch and use that at the start of each CI run.
This works fine as long as the PR is ahead of main. However in active teams (or in a monorepo with many teams) it is easy to get behind. This can cause odd effects. Typically this presents as errors that exist on CI that don’t exist locally and vanish when the branch is updated.
One solution would to cache per branch but initialise the cache to the main.
Another posibility is to datestamp the main cache and only use the most recent one older than the current branch.
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.