Now starting week 4 of getting to know our 2 newly adopted cats.
One of the cats is happy to play string anywhere. The other works to strict zones. There are parts of the room that are for play and others for food/hiding. String will be played in a play zone, and ignored in others.
Understanding the cat zones makes communication easier
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.
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.
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.
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
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.
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.