Starting A Java Project

I have been working on some Java coding kata’s lately.

One of the pain points was the getting the environment set up.

This is one thing that other environments get right:

C# – visual studio has templates for everything.

Elixir – “mix new projectname” does the trick

I have had a look at the Java equivalents:

If you have gradle installed:

gradle init –type java-library

or if you prefer groovy and spock:

gradle init –type groovy-application

If you have maven installed:

mvn archetype:generate DartifactId=myapp DarchetypeArtifactId=mavenarchetypequickstart DinteractiveMode=false

Personally I like the brevity of gradle, both of these should be run inside the directory that you have created.

Working through “Property Based Testing in PropEr with Erlang and Elixir” in Elixir – Part 1

Property testing looks to be an interesting subject.

This is a journal of my working through the book “Property Based Testing in PropEr with Erlang and Elixir”. Note that the book is on it’s third beta at the time I am writing this.

The book is mostly written in Erlang with the Elixir details following (and in an Appendix).

I have upgraded my version of proper to 1.1 rather than the suggested 1.0. This seems to fix the issue I was having experimenting with :proper_types.term()

The PropEr tests will warn you to run mix.propcheck.clean, however if proper is only installed in test mode you will need to use:

MIX_ENV=”test” mix propcheck.clean

The source for this can be found here:

This is at the end of chapter 2.

Property Testing is the practice of testing code with a range of test data that is generated. Typically a property can have 100 test runs with increasingly complex test data. Only the simplest failure will be reported. Properties are a set of invariants that are asserted about the subject under test with respect to the input data.

For example a sorting function can assert that the data set is the same size as before, all elements of each collection (before and after) reside in the other and that each of the sorted elements is <= the next element. Care must be taken not to repeat the implementation. It is possible to use an older system as a golden master.

Understanding Powershell

Powershell is a very powerful language yet a lot of developers get frustrated by some of it’s little quibbles.
Learning a few little details make working with powershell much easier.

Items to consider are:

  • Continue On Error
  • Strict Options
  • Comparison Operators
  • Type System
  • The Pipeline

Powershell commands are always formed Verb-Noun although they can have a more familiar alias.

The beauty of Powershell is how configurable and reflective it is.
If you don’t like the default behaviour then it can easily be adjusted.

For example to find the automatic variables you can use the simple command:

dir variable::*

This lists the variables defined in global scope, including the automatic variables.
Details of these can be found using:

get-help about_auto | more

For example you can change the continue on error by setting $ErrorActionPreference

If you don’t think that PowerShell is strict enough on checking the parameters and types you can use:

Set-StrictMode -Version Latest

This is the Implicit None from Fortran (or VB’s OPTION STRICT).
It means that you get warned if you try to use an uninitialised variable.

PowerShell uses the prefix [Type] to define a type.


$a = [int]16

is valid.

Virgin Airlines as a case study into development failure

While on holiday I found myself interacting with some of Virgin’s software and infrastructure.

To start with I tried registering for their app while waiting in the departure lounge.

It’s not normal to have a password with a 12 character max length that will one accept letters or numbers. That is a security fail.

On the night before our departure my wife received a text message telling us to check in.

Checking the website from a mobile phone told us to try again 2 hours later. This is inconsistent messaging.

Two hours later the website would let us start but insisted on us using an app. We downloaded the app, but found that it wanted us to enter our passport and address details – something we had clearly done before as we had already flown to the Caribbean. The app had an interesting user interface. It would tell you that something was wrong but give no clue as to how to fix it. This is a UX fail.

We attempted to use the hotel supplied tablet but was frustrated by it’s 1 min auto refresh – the website was unable to complete a simple transaction between the console refreshing.

Finally we managed to use my wife’s tablet to check in. This time it was fine.

Virgin really need to look at their systems. Forcing mobile users to use a broken app is not helpful. Prompting users to check in when the system is not ready is also not a good idea. Asking for information that has already been given with a UI that can alter the info without sane error handling is a bad idea.

Categories of Bugs

This assumes a mature XP process is underway (this is almost 20 years old, so should not be a surprise to anyone).

If you are actively developing software there are only a limited category of bugs:

  • The critical – stop development and fix
  • The important – to be picked up as the next highest priority item
  • Prioritised alongside other upcoming work items.
  • Do not fix – record as unimportant

These days there should be no reason to keep an extensive bug backlog.

A bug is effectively a missing test (unit, integration or end-to-end).

With a sufficient test suit the QA should be getting bored. Hopefully they are spending the time working on acceptance criteria and acceptance tests for upcoming work.

Software Reliability

One of my colleagues asked at a recent open spaces event whether the software industry was doing enough about Software Reliability. This was inspired by Bob Martins talk: This raised the fear of 10K deaths caused by software and a potential future restrictions.

To start with I mentioned the aircraft practice of having three independent teams write distinct solutions that need to have two of them agree for any set of input.

The next item is the Erlang/Elixir/OTP ecosystem with its supervisor trees. This is the Erlang principle of “let it crash”. Erlang was designed to allow the software to fail and expect the machine it runs on to fail. This is why the Erlang VM is designed to be distributed – it’s the only way to protect against failure. It even allows software to be upgraded while running. This the software system that runs: telephone switches, Heroku, Rabbit MQ and Whatsapp.

Then there are tools that can help reliability:

Saboteur ( is a tool that can inject network failures between parts of the system. This allows delays and blocks to be simulated. Systems can be tested for resilience – how they behave when the network fails and then recovers.

Gatling ( is a load test tool. This allows us to see how a system reacts under load. One place that I worked tested to either three times the peak load or to system failure. This involved having twelve instance of the application installed in aws vm’s around the world. Some or all of these could be pointed at a system with a suite of scenarios. This would have 300 users arriving per second (and then use the system) for 2 hours. A good test run would involve the system still being responsive throughout this load and then cleanly recovering afterwards.

Property Testing ( or These are tools that allow systems to be tested against generators that try to examine behaviour against the entire of the parameter space. Suites of random values are tested and upon a failure it attempts to find the simplest example that causes the same problem. This is documented here: . Note that that book is still in beta.

There are the resources out there, it is up to the software development community to use them to raise their game.