This is an article on running elixir tests without a project.

The problem I am trying to solve is to have a true isolated unit test that does not require the entire project to be built. Given a suitably large codebase the tests can take 30+ seconds to start due to rebuilding the world. This is painful if you are only working on something that is isolated from the rest of the system.

The main trick is to use the elixir cli tool to run just what you need without requiring all the heavy details from the project.

This is a project that shows off using this technique.

Even on a trivial project you get some speed ups locally ./first-test.sh was twice as fast as mix test

Competitive Engineering (Gilb 2005) is a dense book that describes an agile process for project management that is different to that typically used by the typical agile manifesto.

This is an older process that tries to replace what would have been described as waterfall development with something practical. The book has a lot of great ideas but is not an easy read. It is especially challenging as most of the book uses a semi-formal language called planguage to define itself. It does not limit itself to software projects.

Lets break the big ideas down in reverse order.

10. Evolutionary Project Management.

The idea here is that you can break any large project down into a series of small steps that each deliver some value. Typically each step should only cost no more ghan 2% of the total budget.

9. Impact Estimation

A technique for comparing design ideas numerically against a fixed set of requirements.

8. Specification Quality Control.

A technique of inspection of documents against defined rules.

7. Design Ideas and Design Engineering

How to find an specify design ideas

6. Resources Budgets and Costs

Resource requirements

5. Scales of measure

A great technique for making everything measurable.

4. Performance

How to turn performance attributes into numbers.

3. Functions

This is what the system must do.

2. Requirement Specification

Outline of targets and constraints.

1 Planguage and process control

Intro to Planguage.

This book was written at a time when you actually had a mantained specification document alongside a system. I have only ever seen this in use once on a large project near the start of my career.

I have used some of these techniques to help choose between design alternatives. The whole process is too big to use for “small” tasks.

Lean processing was initially developed by Toyota. The innovation was to work in terms of flow rather than focussing on speed of production. This has been covered in many books:

• The Goal
• The Machine That Changed The World
• The Phoenix Project and it’s equal The Unicorn Project

The one that I am reading now is Freedom From Command and Control

This is an attempt to translate the Toyota process for service organisations, and in particular customer service.

The overall idea is to find and eliminate waste. Those best placed to detect the waste are those doing the work.
A starting point would be categorising calls into value vs failure management. Failure management results in finding things that should not happen. If these can be prevented then the volume of wasted repeat calls will decrease.

This is the basic Plan Do Study Act loop that is used at multiple levels in an agile project.

At the lowest level it is the Red-Green-Refactor cycle of TDD

At the task level it’s the do we know enough to know what to do, report what is finished and update the next steps.

At the initiative level it’s the breaking down items into discrete tasks and ensuring that each incrementally adds value.

At the team level it’s the retro and the resulting actions to drive improvements.

ets is the bare bones no persistence storage mechanism that has lived inside Erlang for decades.
It’s not pretty but does its job well.

Today I found etso a bare-bones Ecto wrapper for ets.
This does allow possibilities for rapid prototyping of systems.
You can see if the database structure makes sense without actually having to create the database.

Possibilities here get interesting. For example you could point a generator at openapi and have a system that implements the spec without ever touching a disk.

vimtutor -c 2

This was news to me. I had done most of the the first chapter many times.

I have been working in a company that has a large monolith. The developers have been split into domains and largely been focussed on their own area.

Over time each of the domains has atrophied their understanding of the other domains.

We recentlty had some larger cross domain projects started. These also cross into some of the systems that surround the monolith.

The pure DDD ideal of having a service belonging only to one team is now causing new bottlenecks. If a service needs to be used by all the surrounding systems this will happen.

The easiest solution would be to start accepting PRs from outside of the supporting team. The downside is that the bottleneck now becomes reviewing the changes.

We really need to have a big picture view of the system somewhere. Currently we have many competing (and contradictory) views.

Designers would benefit from this. We recently we given a piece of UI work that requires a new API from the constrained team.

We would have benefited from a user needs mapping session to make it clear which team owns the various capabilities.

I have found tmux to be very useful in my development work.
I typically have one session with multiple windows, some of which are split into many tabs.
Most of the time I am zoomed into the console but the other useful panes are just a PREFIX z away.

The thing that makes it so powerful is that I can have the same terminals in both a window inside my IDE and in ghosttty outside the ide. This means that I can go full screen when I need to or simple have the results where I want them.

The next step is working out how to quickly set up the windows in the format that I want them.

The following creates a new named window

tmux new-window -n foo

The following splits a window as follows

tmux new-window \; split-window -v \; last-pane \; split-window -h

|----------------|
|   1    |  3    |
|        |       |
------------------
|   2            |
|                |
------------------

The original idea for a microservice was something small and independent that could be replaced in a couple of days.

These days we end up with distributed monoliths that are called a set of microservices.

Independent means that it could be deployed in multiple places.

Lets use a practical example. We have some images that we need thumbnails for. Images are stored in an S3 bucket. An ideal microservice would watch for images being created then create the thumbnails.

This could be configured via a pulumi script. By giving a base prefix all the parts could be configured as a set of serverless functions.

For a sufficiently large company could probably mine a number of these utilities from systems that already exist.

This varies depending upon what type of project you are working on.

If you have a website this can be reduced to: how do I know this is working in production.

If you are shipping products for other people to deploy then a test deploy should be enough.