Some years ago I built a rules engine system for my employer. This is the theoretical underpinning.

There are various types of rules that a rule engine can have. The most basic is the default. This will apply a value to an initialised but not updated field.

The next is a calculation. This will set a value typically based upon data in one or more locations. This will recalculate whenever either value changes.

Another is the non-limiting constraint. This will warn that a value is somehow incorrect but will not change values.

This contrasts with the limiting constraint that will prevent a value from violating it’s rules, enforcing a limit should the constraint be broken.

If you are using relay to make your graphql development easier (it generates typescript types from your graphql schemas). This can make working with VSCode difficult as the IDE sometimes has a different view of the world to the latest generated version.


I have found the following extension for VSCode: Relay for VSCode I plan to try this tomorrow to see if it helps.

This may also help testing the components that use relay: https://relay.dev/docs/guides/testing-relay-components/

pic.twitter.com/qEwDPaGCP2

— Dan (@G_I_T_C) June 28, 2022

If you are exposing an endpoint to your front end on the public internet then it can be called at any time. There is no way to ensure that the call came from a browser. The only sane approach is to assume that any endpoint that you are exposing to the browser is a public API and should be treated as such (with the exception of ensuring backwards compatibility – private API’s are still subject to change/retirement without notice).

This also means that any javascript that you embed in the page and download to the browser will include a map of your exposed backend services and examples of how to authenticate and use it. Obfuscation will only go so far – the urls struct that you send out will be included in the messages.

Chrome has a wonderful security feature that makes local development harder.

They are trying to force https and having approved certificates. This does not help developers.

To bypass you need to type: thisisunsafe

I started brushing up on my DDD skills by re-reading Evans.(2004).
The main inspiration was to determine how to document a domain model.

Various searches led me to this article: https://medium.com/nexa-digital/my-journey-into-cqrs-and-event-sourcing-4bd7d0c1c670

It’s the start of a series of articles on Event Sourcing/CQRS in Elixir. The sample application is about consent for medical records, but looks to be ideal for consent for GDPR!

This is a great introduction to CQRS with a functional approach.

The underlying git repository is here: https://github.com/rodrigobotti/cqrs_es_consent

Typically you would want to advertise exciting features when advertising a book. This time I want to prome boring releases.

This book includes a chapter on how we managed to take the drama out of releasing software. The software we released was exciting, but the actual releases were calm and measured. In one case we had a project manager prepare 30 scenarios, 27 bad and 3 good. In the end it went so well that none of the good scenarios applied. This was the digital release of the Cursed Child Script book.

Here is the book including a chapter on how we made the magic:

https://leanpub.com/development2019

Here is the guidance from the ICO

https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-by-design-and-default/#:~:text=The%20UK%20GDPR%20requires%20you,by%20design%20and%20by%20default’.

The idea is that any system that is being worked on requires data protection by design and default.

This includes:

Asking permission from the user to use their personal information. If they need to opt in this needs to be explicit rather than assumed. (There are some circustances where permission is not required, but you need to make the owner of the data aware).

You should also record the version of the privacy notice that they accepted. If the terms change to include additional usage then permission needs to be requested again before the data is used. Permission may also be withdrawn.

The use, storage and processes must be clear. Breaches of these need to be reported to the authorities and affected users.

Fully doing this is not simple. There are benefits. This will typically require personal data to be held in a single place which can simplify processes (less duplication and inconsistency). The need to understand your internal processes will also help. It forces good communication practices.

This looks interesting (https://eventmodeling.org/posts/what-is-event-modeling/)

If you want to report a bug to a (typically an open source) project. Follow these steps:

Check if the bug is already in the tracker. If so see if you could add a new test case to demonstrste the issue.

If it is not in the tracker create a simple test case that demonstrates the problem. Being able to recreate the issue makes it far easier to work on, making it far more likely to be picked to work on.

If you know how to fix the problem check that they accept Pull Requests and supply one. Allow the maintainer to edit it. Its likely that you are going to have missed some internal rules of the project.

Contributions to documentation are really appreciated by maintainers.