anchor.diff:  basic-auction-client  basic-auction-cluster  logs  node0  node1  node2  script-common
   ----
   
  -Lets look briefly how the script launches the code.
  +Let's look briefly how the script launches the code.
   
   [source, Bash, indent=0, options="nowrap"]
   ----
  
positive.code: - Timestamps
  - Random Numbers
  - Reading from configuration files.
  - Iterating over some types of collections, eg. HashMaps.
  ====
  
  Timestamps are provide by Aeron Cluster (will be shown later). Random numbers are best avoided or use a seed fixed in
  the initial state or via a message. Configuration changes should be pushed into the application logic via messages.
  Iterating over collections should happen in a known order, with a collection that preserves ordering (e.g. TreeMap,
  LinkedHashMap) through sorting the values from the collection before sending them as messages. Alternatively, the
  Agrona collections can be used with their consistent iteration order and low allocation characteristics.
  
  As it may be impractical to replay all data from the "beginning of time" the system should take snapshots periodically,
  e.g. daily or hourly. The frequency of snapshots should be determined by the volume of data into the
  
negative.code: 
  == Implementing a Clustered Service
  
  The first step to setting up a cluster is to implement the application logic. For this tutorial we are going to
  implement simple auction service. It will have one auction and will track the best price, and an id for the customer
  who bid that price. To properly demonstrate the state management and recovery features of cluster it is important to
  have some functionality that is stateful, rather than something that is stateless like an echo service.
  
  NOTE: In order to understandably show the various features of Cluster, we've kept the various aspects of the code
  (data serialisation, application logic, Cluster integration) very close together. It is unlikely you would do this in a
  