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.

Larger organisations try to adopt a Domain Driven approach where various parts try to act independently.
This is a good plan.

However independence does not mean ignoring other parts of the business that are consumers of what you produce.

Domain Driven Organisations need clear defined boundaries between the various domains. If the boundaries (contracts between systems) are weakly defined then changes in one place can have an impact in an ideally unrelated system.

Last weekend I bought a Rocket Book.

This is a reusable notebook with an app that allows uploading details to various locations.

Since then I added a set of index cards.

I have also bought the whiteboard tags.

The following is a sample file scanned.

Of late I have been having problems with a number of service providers. I try to give feedback to allow them to improve.

Barclays have a problem with their online banking – they sometimes drop people from your payee list. This is only meant to happen after 14 months. They dropped my credit card provider from the list and that gets paid every month. Another entry does not seem to be correct having the wrong reference. This dropping payees is listed as a known issue and I was told it may happen again. The online banking site is a bit of a mess – you can’t delete payees yourself.

Direct Line send out generic letters on payment failures and the staff blame it on an “automated system”. This is not acceptable. If you have generic letters make the effort to have suitable generic messages. Post is slow and the problem may have been resolved by the time the letter reaches you.

After cancelling my policy Direct Line sent me a letter offering me the chance to stop the cancel. The date on the letter was one day before the policy was due to stop and it arrived 5 days after I would have been able to do anything. This is pure waste.

I am also concerned about Amazon. I have a parcel that was due to be delivered yesterday that failed to arrive. According to the form it was out for delivery but failed to arrive and is now delayed by a week.