I just had a very quick trip to Rome.

It was a team building so a one night stay.

Lots to see, food is great. Attended a pasta making training session.

Rome is said to be on seven hills. The hills are not very big. It’s more that the city is not as flat as say Milan.

Hotel rooms in Rome have kettles – something that the Milan equivalent lacks.

The international airport is a 35 min Train ride from the main Rome station.
The arrivals board is more prominent then the departures board.
Getting onto the train is more complex than necessary due to some repair work. You need to leave the platform and rejoin (or walk through the building work).

The travelator at the station moves at less than walking pace!

The playwright e2e tests are significantly easier to work with than cypress.

While developing the tests using the playwright test --ui option makes developing the test really easy.
You get to see what is happening at each step and can simply copy the final url to allow experimentation.

The only drawback is that on CI you can’t always see the server logs. This can be alleviated by adding small healthcheck endpoints.

Recently I have been working with some e2e tests. These run inside the ci build and all external services are mocked and dockerised.

Given the frontend is typescript and has an Elixir backend this is the only point we can test the integration of the two.

The existing system uses Cypress. This has been slow and unreliable. We sometimes get errors that we cannot manually recreate.

I have been working on moving to Playwright. We lose the gherkin format but gain faster more reliable tests.

I have just found https://github.com/HamedStack/HamedStack.Playwright.Screenplay which provides some abstractions to help the testing.

Last weekend was the start of British Summer Time, which is described as daylight saving.
This was implemented during WWII and is best charcterised as a politicians sigilism.

We must do something.

This is something.

We must do this.

The net effect of moving all the clocks an hour earlier is to inflict jet lag on an entire country for 2 weeks. During that time the sun will be rising earlier anyway so it will be as light when you wake up as if the system had not been imposed.

The argument that it helps farmers is demonstrably crazy. Pet owners know how confused they are at randomly changing meal times. Can you imagine how confused a milking cow herd would be!

I have started looking at dependabot again.

With the loss of the Heroku free tiers the old solution I used no longer works.

The first problem to solve is to detect PRs in need of merging.

declare -a arr=(“name1” “name2” “name3” )

for i in “${arr[@]}”
do
gh pr list -R owner/$i
done

The above is a bash script which requires you to have the gh cli tool installed and configured to access your repos.

This will help give you a report of the pending PRs to merge. It may need adapting if you have too many.

The next step is to start merging them.

Dependabot text commands are useful here. You can use `@dependabot merge` to assist with this.

The step beyond that is detecting the number of merged PRs to deploy. You don’t want a huge deploy in case it needs to be reverted.

You will never be clear of the upgrade treadmill. The best solution is to fully automate it.

To use that you need several things:

– a fast reliable deploy/rollback process

– a sufficient test suite

The best option is to automate the merging of dependabot PRs that pass all the tests. Beware false positives that other integrations can give (snyk).

You will also need an automated deploy process. Deploying the latest build every day at a fixed time would help this (this also ensures that you could at least deploy yesterday).

It is possible to rate limit dependabot to only having 10 open PRs at a time. This could help but could be problematic if you are in a fast moving environment like javascript.

I will be giving a talk at work about how to use mermaid diagrams.

Here is a set of examples that make great starting points.

https://mermaid.js.org/syntax/examples.html

I have a confession: I can’t draw well,

However I can create useful diagrams,

Important Formula:

Cost To Create + Cost to Maintain > Value of diagrams

Mermaid allows cheap creation and maintenance allowing the ability to achieve value in cases where other techniques will be prohibitive.

The perfect is the enemy of good enough.

No Diagram is perfect.

It’s easier to offer suggestions to improve a diagram than a large text document.

It’s amazing how much you learn building a diagram.

Diagrams need to have a key. (Although with some diagram types the key can be shared)

Each symbol you use needs to have the same meaning everywhere.

Map vs Diagram – a map is a special kind of diagram where space has meaning.

Documenting Software Architectures: Views and Beyond.

Build them by copying and editing.

The friends:

These can be a bit more complex. Typically they require a command line tool to transform a file into an image

Graphviz (https://graphviz.org/gallery/)
Plantuml (https://plantuml.com/)

For interactive diagrams there is the excellent
d3js. (https://d3js.org/)

I am starting to study Rust as it is used at work on some projects. So far it has been ok, but not overwhelming.

Rust is a semicolon language, which must be a more important split than the static/dynamic or compiled/interpreted split.

This is coming as a shock after Groovy, Typescript and Elixir.

The Rust compiler messages seem less helpful than I’d expect.

xcode-select --install

This reinstalls the command-line tools.

These frequently vanish after a mac os upgrade.

Once upon a time I was working on a system that was deployed on customers sites. That meant we had no regular access to the logs for the system which made getting feedback difficult.

One of the developers on the team added an exception logging table which would capture every exception raised by the system along with the full stack trace.

In order to debug a certain error the customer provided us with a full backup of their DB. In addition to fixing the specific issue I managed to get 2 days to look at the exceptions.

By looking at the frequencies I was able to put in place measures to handle 99% of these errors. Now most of them were transitory problems that the customer had never reported.

When the fixed version of the product was returned to the customer they were happy with it, but could not explain why.
In facts they were so happy that it took 2. years to convince them to take a new version (we had a 6 month release cycle at this time).