Recently I have been working on upgrading some libraries.
This has involved some complex grep scripts.

The ripgrep tool has proved to be very effective with multi-line queries.
In fact it was fast multiline than the standard grep scripts that we had been using.

JavaScript is currently the default for interaction on web pages. Just because the page loads JavaScript it does not limit you to using JavaScript to write it.

The simple option is just to write JavaScript. This works an is the common approach.

The next step is to use Babel to transpile various extensions into JavaScript. This allows the use of language features that the browsers don’t yet support. Hopefully the near future loss of support of Internet Explorer 11 will allow this process to become easier. This is the typical option for React. This allows non-javascript components to be translated.

The next option is to move to Typescript. This is a backwards compatible language that adds some structure to JavaScript. This makes refactoring easier and adds some type information. This only exists at compile time. This is the technique used by most Angular applications.

There is a further option to move to other languages that compile to JavaScript. Here I am going to consider Elm, but other options exist (PureScript, Gleam). Elm is specifically designed for frontend applications. It’s a strongly typed functional language that makes strong claims about eliminating runtime errors. It has its own model based UI tools. It won’t eliminate logic errors but will work hard to give you it’s famously useful error messages.

Elm uses expressions rather than statements. This means that you always need an else if when you use if. Expressions always return something. It is a compile error to omit this. The language also has strong opinions on tab Vs spaces, as a tab in code whitespace will give a compile error. Lists need to be of a uniform type. Tuples can only have 2 or 3 elements (this constraint will greatly simplify APIs).

I have recently been helping with a series of discovery workshops. The aim was to make recommendations on the future architecture of the system.

Several of these involved using concepts from DDD. In particular the workshops identified the bounded contexts and built a context map between them. Occasionally we described the entities within them, but these were mostly used to clarify the boundaries between systems.

For strategic analysis the ideas in second half of Evans DDD was of more interest than the first tactical part. Here we didn’t have a greenfield environment, but were trying to find a way to improve a certain part of the process.

The concept of separating the problem space from the solution space helps here. To design a logical architecture requires that the system be described in terms of the problem rather than the (possibly) existing solution. This means there can be no reference to databases, proxies or internal system names.

I am again working through this great book now that it has been published.

The first chapter is a great intro to Tasks.
It’s not changed much since the previous version I reviewed but is much clearer than the initial version.

Sample code is here:

https://github.com/chriseyre2000/sender

The following code works in Node 16:

`await Promise.resolve(console.log('🎉'))

It would fail in Node 14

We can finally use top level awaits in the console.

Node 16 comes into LTS on 2021-10-26

https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/

Chapter 1 was about Tasks

Now working on Chapter 2

This implements a Job Control system (with retries) using a GenServer.

This builds a more complex setup for supervisor trees.

This introduces a DynamicSupervisor and then adds transitory supervisors that watch their own jobs (which can then terminate cleanly.

Here is the sample from chapter 2: https://github.com/chriseyre2000/jobber

The important detail here is the use of a Registry, which exposes the underlying ETS (Erlang Term Storage) system used.

I have started to add custom aliases to my bash setup to reduce typing time:

alias ism="iex -S mix"

This is great for turning code into an interactive session

alias mtp="mix test --include pending"

This allows quick testing of Elixir Exercism exercises.

A given software system is a series of components that need each other to work. To test it you can either test all of it or you can treat it like a chain and test each link.

The current system I work on has a database, a Java backend, JSP views and uses AngularJS in the front-end

In order to comprehensivly test it you need a range of components. Featupent re flags can be tested by asserting that the page has certain elements present or absent. You can test for the presence of a given angular tag.

The angular components can be tested in a unit test framework in isolation.

Protractor is useful for checking that the components hang together without errors. There are so many places that JavaScript can live that only by looking for errors on the logs or ensuring that the page still has interactivity can you be sure you have s functioning page.

I spent some of last year looking for these assertiobs in React only to find them in an angular library.