Upgrading an Old Mac Mini

I am trying to upgrade an old Mac Mini that I have had sitting around for a while.
Apple upgrade are cumulative and slow, you need to finish one before the next will be allowed.

Just found a strange option. The upgraded mac required me to slow down the monitors refresh rate, otherwise it would not turn the screen on. Currently it has reach version 10, but I need to get it to 12.5

It’s a 2 hour reboot cycle, when it can find a screen.

Mix Test Output Part Two

`This is how I fixed the tests over an umbrella project problem:

  mix test | tee test-logs.log
  echo "=== Unit Test Summary ==="
  grep "==>\| failure\|are no tests" test-logs.log
  rm test-logs.log

This way the last thing in the log file on the build server is a summary of the above tests.
It may include some false positives if you are logging too much, but it does include what is needed.

Plantuml-Libs now has a single file version of all of the templates

https://github.com/tmorin/plantuml-libs

Now has single file includes for all of the templates.

https://raw.githubusercontent.com/tmorin/plantuml-libs/master/distribution/eventstorming/single.puml
@startuml

!include https://raw.githubusercontent.com/tmorin/plantuml-libs/master/distribution/eventstorming/single.puml

' display elements
FacadeCommand('FacadeCommand')
Command('Command')
Result('Result')
Event('Event')
DomainEvent('DomainEvent')
IntegrationEvent('IntegrationEvent')
Query('Query')
ReadModel('ReadModel')
UserInterface('UserInterface')
Aggregate('Aggregate')
Service('Service')
Policy('Policy')
Saga('Saga')
Process('Process')
Timer('Timer')
Person('Person')
System('System')
Comment('Comment')

@enduml

This now works for all of the templates, have a look.

This is kind of ironic as earlier today Simon Brown posted about how complex using plantuml for architecture diagrams becomes.

New Mix Archive gen_docker_db

I have been experimenting with creating custom mix tasks and publishing them as archives.
The project is here: https://github.com/chriseyre2000/gen_docker_db/

The first release is here: https://github.com/chriseyre2000/gen_docker_db/releases/tag/0.1.0

If you download the archive and use mix archive.install gen_docker_db-0.1.0.ez

This adds a new command to mix: gen_docker_db
This will echo the command you need to create a docker container for postgres,

It is entirely insecure and uses a default password, but it will allow you to quickly stand up a local docker image for phoenix.

Evolving a CQRS ES Model

Here is a video I found on the topic:

https://www.youtube.com/watch?v=04_esxp8C_o

The video covers some of the basics including how to version, reproject, handle “Errors” and mask invalid data.

Here is an article on Evolving Data Warehouses:

https://www.sqlshack.com/implementing-slowly-changing-dimensions-scds-in-data-warehouses/

I have a theory that the two topics are at least similar enough to consider using across the two domains.

Kubernetes and Elixir Part 2

It appears that the series that I linked to stopped at the first article.

Here is my plan for the weekend:

– build a generator to create the docker file for an elixir app.

– build a generator to build the skeleton for a Kubernetes/Helm setup

– deploy this to minikube

– establish how to network the nodes together within k8s

– establish and document how to connect to this from outside k8s usung both iex and livebook

– work out how to deploy to a pod running inside k8s

If possible experiment with the build server system from the link in the previous article. It would be good to use this to build something that could be used to test github actions locally or to recreate a heroku environment.

A recent Thinking Elixir podcast talked about per PR environments. This could be achieved with Kubernetes. A previous client had attempted something like this.

Kubernetes and Elixir

This is a series of articles that cover using Elixir in Kubernetes:

https://david-delassus.medium.com/elixir-and-kubernetes-a-love-story-721cc6a5c7d5

This uses the following github repo:

github.com/linkdd/elixir-k8s-love-story

The difference in this series from most others is that it covers building a Kubernetes setup assuning that you have a BEAM cluster rather than just a set of go applications that require elections.

The programming model for the BEAM is very different. The model is closer to an operating system than a single machine.

I have not yet worked through it, but will study it.

Here is another article on clustering on Kubernetes https://mbuffa.github.io/tips/20201022-elixir-clustering-on-kubernetes/

Elixir Test Output

Elixir has been designed taking inspiration from a number of other languages. This makes the developer experience to be one of the best available. This includes test runner support and the ever useful mix utility that hosts everything from project creation, dependency management, database migrations and repl support.

One feature that is slightly lagging is the test output support. Previously I had worked in Groovy using Gradle and Spock. The test output report was spectacular. You could generate a detailed report artifact, which was either a directory of html or a single zip file containg the same. This report would list all of the test suites with the ability to see the associated console output with the test. This becomes great to have in a CI setup as these can cheaply be stored in S3 which allows detailed investigation of historical failed test runs.

The following provides the hooks to improve the Elixir story. I have been considering writing one that produces a livebook as the output.

https://stackoverflow.com/q/41350135/662571

Here is a sample project that uses some of the above techniques:

https://github.com/chriseyre2000/my_custom_test_formatter

Currently the project will add the name of the current project before the summary line of tests passed and failed.
The idea being that an umbrella project could report which project it was. This can make life a bit easier when dealing with a build server that only shows a limited span around failures.

Warning this does not work in an umbrella project.

Thoughts on CQRS ES

The theory goes that an event sourced system has a perfect audit trail. However in practice this is only partially true.

It does have a complete history of all of the commands that have succeeded. It tells you nothing of the load on the read model and the failed commands. These require more detailed information that may reside in your observability system.