In my previous post I mentioned that I am trying to write to Neo4j from node.

This is becoming difficult as each of the top two libraries seems to have serious dependency problems.

The Neo4j package does not handle error conditions well due to a missing stacktrace function.

The neo4j-driver package is also broken with a vague “Headers is not defined”.

This brings me to the main topic: when should you choose a library versus directly using an api?

Firstly does the library do the job? There are lot of node packages out there. Some of them are useful.

If the library adds some features then it’s a no-brainer. Especially if the library can maintain a stable contract despite the underlying api changing (The Delphi VCL was a great example of this. The VCL survived the underlying platform moving from 16 to 32 bit without any code changes required).

There is also the matter of the dependency chain that you will pick up with the library. It’s not uncommon for a npm package to have tens of dependencies. This can mean that a poorly maintained library can be broken by someone else’s change (this may be less of a problem with the introduction of package-lock). This can also be difficult with dependencies from multiple required libraries: these can clash and you may have to chose which bugs you can live with.

If the usage that you have of an api is simple and the api is stable it may be worth directly calling just the parts that you need.

I have been having fun recently working on a react app. Typically I use TDD.

This can be difficult when you have code that goes:

fetch.then(res => json)
.then(res => this.setState(res.aValue)
 )

Testing this gets awkward. Changing the signature is too invasive. You can easily mock the fetch but get a race condition reading the state.

This is the solution that I found works. By abusing the javascript sequencing a bit – do what you need to then check this:

setTimeout(() => { assert thing.state}, 0)

Here are eight influential books that relate to software development:

The classic:

Introducing techniques:

The skills around development:

How to unit test anything:

How to stretch your knowledge:

How to stretch your knowledge further:

How to explain your new ideas to other people:

Information about Quality, Gumption Traps and The Scientific Method:

Recently I have started using react redux. It’s amazing how complex React/Redux makes even the simplest task.

I needed to pass an environment value through to the client side rendered ui. This was to allow the component to vary by environment – something essential in a dev -> qa -> preprod -> live pipeline.

You need to pass this into the store and map it out into the state of your component. All of the documentation and examples seem to care about is state mutation. The trivial case is overlooked.

The app that I am working on has multiple reducers that are combined with CombineReducers. This has the interesting side effect of dropping any state that is not included in a reducer.

This is not accidental it actually warns you (cryptically) that it is doing it.

I solved this for now by creating an idempotentReducer that simply returns the state. This is not a good long term solution.

The documentation on CombineReducers does state that it is intended for simple cases. I can’t imagine why passing through static state is not the simplest case.

I have now completed the book (although not all of the bonus exercises).

https://github.com/chriseyre2000/storex

The remainder of the book demonstrated extensions to the application to create an administration mode. This shows how you extend an existing application.

Overall the book is a gentle introduction to Phoenix and avoids introducing some of the more complex features (there is no attempt to explain OTP or Channels).

The code struct has been easy to follow with the examples being split into the correct sized chunks. This is in comparison to Learn React Native who code samples were excessive given that you needed to type in several pages of code before anything could be checked.

I did find a few typos which the author says are due to be corrected soon (an early view of the contents of the database includes the admin flag, some brackets are missing on some of the redirects and the validate_max_price method breaks when the price is null).

This has been a very useful addition to my Elixir/Phoenix study library.

It is interesting to compare the changes in the Phoenix framework between the Learning Phoenix book and this one. The major difference is the movement of the model from within the Phoenix app itself (storex_web) into a library (storex).

The only variation I took from the book was to add Credo:

Terraform is a means of declaratively specifying infrastructure.

Terraform comes with built in graph visualization (requires Graphviz) :

terraform graph | dot -Tsvg > graph.svg

It is now possible to start Linux Development on an android device:

https://medium.freecodecamp.org/building-a-node-js-application-on-android-part-1-termux-vim-and-node-js-dfa90c28958f

The above article shows how to install enough onto your phone to allow basic development.

Here is some of the history from my first session

1 apt update && apt upgrade
2 apt install coreutils
8 which awk
9 which sed
10 which grep
11 which curl

# not found so installed via
12 pkg install curl
13 curl
19 apt install vim
21 apt install nodejs
22 which node
24 node -v
25 history

Given that I now have node, vim, curl, grep, awk and sed this looks to be a useful base platform.