I have just finished migrating a suite of Elixir projects from distillery to mix release. A key part of that change is that all environment variables need to be called from the runtime.exs rather than the various env.exs files.

This is part of a project to move to build once, deploy many times approach.

While working on this I found a few cases where the staging envitonment files inhereted from production. This is a big problem as you may turn things on in production later and not realise that the staging system (which can have a larger number of possible users) will also be using production.

I untangled the config into distinct files (keeping everything as it was) and only when it was reviewed it revealed certain production settings we don’t want in staging.

This relates to the talk Simple Made Easy.

No matter how many ptogramming languages you know there is always another that you need.

Currently I am learning Elm with the next stop being Rust.

The Elm ecosystem is slightly broken on M1 Macs (including via Docker). My plan to reduce the pain is to use Storybook.

I have been migrating some tests to use github actions from Drone.
Locally we use docker-compose to run the app and tests.

There is one annoying difference. The networking setup is different for services. In docker-compose if you have a postgres service it has the network name of postgres. In gha services are all found at localhost.

This makes working across them a choice of either having a host of environment variables that you need to set in each case or having an entire config environment. Having fought with some environment variables for a while I found the distinct configs to be much cleaner. Env variables don’t propagate well through nested processes.

I have finish working through chapter 3 of Elm In Action

https://github.com/chriseyre2000/PhotoGroove

I now can see the appeal of Elm to the Elixir developer.
There are a lot of language similarities.

It is opinionated, and which I may not agree with all the decisions I do understand them.

It would help if it were actively maintained as the mac dev tools seem to be lacking in certain areas.

Not having explored beyond the basics yet.

This is the second time that I have attempted to learn Elm.
The first time I was reading Seven More Languages
That time the chapter dedicated to Elm was highlighting a feature that have been removed from the language by the time I got to the chapter.

I am now working through Elm In Action.

Elm was the inspiration for some of the javascript libraries (redux) but seems to have a better theoretical basis.

However it does have it’s rough edges. It has strong opinions on use of commas, spacing (if I wanted to fight whitespace I’d be using python).

The language has also not been released much recently and the maintainer does not seem to both with mac support. This means that tools like elm format are broken.

On the positive side the error message do include suggestions on how to fix the current error. They don’t always solve the problem in one step, but can help to find the problem. Oddly the language talks to you in the first person!

I can see that the Elm Architecture could help simplify certain types of development.
The plumbing required to add it to a page does resemble Angular 1

This kind of thing should be easy right?

I have a SatNav and a computer.

The first problem requires a spotters guide to USB

Types of USB Connectors

While USB is the Universal Serial Bus there are lots of combinations out there.

Type A is the usual one used by plugs. Type B used to be used by some printers. Mini is used as the power supply for some devices. Micro A was used for older android phone and kindle devices. Type C is the modern EU approved standard version that is used by all modern phones.

The fun part is that the Garmin has a cable with type A at one end and Mini on the other (this is the end the goes into the Sat Nav). Mac currently only support USB-C. This is fine as I have an adapter.

The first A – Mini cable that I used (because it was in the house) did not work.
The Garmin Express helpfully suggested not using a hub and directly connecting to the computer!

The second A – Mini cable that I tried was in my car (and was the official cable). This one works.

Lesson learned: Mac port adapters do work with Garmin!

It is also weak at estimating download times. What started at 2 hours is going to only take 15 mins.

https://storybook.js.org/addons/storybook-css-modules

I have found storybook to be very beneficial in working on a large react application. This allows taking a component and rendering it independently of the application.

This allows getting the component into all of the possible states without needing to fake the rest of the world.

An error form can display all possible errors, which makes checking things far easier.

The last problem I need to solve is to ensure that the component is styled in tje same manner. Hence the above link. I hope to use this to ensure that Storybook has a high fidelity match to the app, as currently I am missing the exact fonts used.

I need to start this by saying that TDD is a very powerful technique that helps.

This is a discussion of the areas not to test.

Don’t fully test a library. Do have a test that the library does what you need.

Don’t build integration tests when you are unsure about the specific implementation ( especially if the setup becomes excessive). Add the tests on the second feature.

When integrating with 3rd party APIs you may get more value instrumenting well and seeing hoe it behaves in production. This is the source of the “don’t mock what you don’t control” rule. Vendors rarely provide an accurate test environment. REPLs are the best way to experiment with them.

If you have complex logic (more than one if statement or a trivial reduce) then write tests for that. They will be easy to write now and will be valuable as things become more complicated.

https://storybook.js.org/docs/6.5/react/get-started/why-storybook/

This is a tool that allows you to isolate UI components. The practical benefit is that you can list all of the expected states of a component without having to build the world around it.

I am currently working on displaying data that has no simple way of recreating accurately in environments below production. By using Storybook I can demonstrate what it would look like.

Another benefit is that you can test the component in isolation on a range of devices/browsers. That makes checking a new component much easier.