anchor.diff:  }
   ----
   
  -This method retrieves the configuration, instantiate the verticles (5 verticles are deployed) and publish the
  +This method retrieves the configuration, instantiates the verticles (5 verticles are deployed), and publishes the
   services in the service discovery.
   
   First, notice the method signature. It receives a `Future` object indicating that the start is asynchronous. Indeed,
  -all the actions made in this methods are asynchronous. So, when the caller thread reach the end of the method, the
  -actions may have not completed. So we use this given `Future` to indicate when the process has completed (or failed).
  +all the actions made in this method are asynchronous. So, when the caller thread reaches the end of the method, the
  +actions may have not completed. We use this given `Future` to indicate when the process has completed (or failed).
   
   The `start` method:
   
   1. retrieves the configuration (giving the "fake" company settings)
  -2. deploys on verticle per defined companies
  +2. deploys one verticle per defined company
   3. deploys the `RestQuoteAPIVerticle`
   4. exposes the `market-data` message source
   5. notifies the given `Future` of the successful completion or failure
   
   To retrieve the configuration the verticle needs a `ConfigRetriever`. This object allows retrieving configuration
  -chunks from different stores (such as git, files, http...). Here we just loads the content of the `config.json` file
  -located in the `src/main/resources` directory. The configuration is a `JsonObject`. Vert.x heavily uses JSON, so you are
  +chunks from different stores (such as git, files, http, etc.). Here we just load the contents of the `config.json` file
  +located in the `src/main/resources` directory. The configuration is a `JsonObject`. Vert.x uses JSON heavily, so you are
    going to see a lot of JSON in this lab.
   
   Once we have the retriever, we can retrieve the configuration. This is an asynchronous method (`rxGetConfig`)
  -returning a `Single` (a stream containing one item). When the configuration is retrieved, we extract the `companies`
  -array from it and deploys one verticle per defined `company`. The deployment is also asynchronous and done with
  +returning a `Single` (a stream containing one item). After the configuration is retrieved, we extract the `companies`
  +array from it and deploy one verticle per defined `company`. The deployment is also asynchronous and done with
   `rxDeployVerticle`. These _company_ verticles simulate the value of the stocks. The quotes are sent on the event bus
   on the `market` address.
   
  -When the _company_ verticles are deployed, we deploy another verticle providing a HTTP API to access market data.
  +When the _company_ verticles are deployed, we deploy another verticle providing an HTTP API to access market data.
   The last part of the method is about the service discovery mentioned in the microservice section. This component
   generates quotes sent on the event bus. But to let other components discover where the messages are sent (_where_
  -means on which address), it registers it. `market-data` is the name of the service, `ADDRESS` is the event bus
  +means on which address), it registers it. `market-data` is the name of the service, `ADDRESS` (a static final variable defined as `market`) is the event bus
   address on which the messages are sent.
   
  -Finally when everything is done we report the status on the given `Future` object.
  +Finally, when everything is done, we report the status on the given `Future` object.
   
   
   Remember, Vert.x is promoting an asynchronous, non-blocking development model. Retrieving the configuration,
   deploying verticles, publishing a service may take time, as we cannot block the event loop, these methods are asynchronous.
  -This code use RX Java 2 and asynchronous method are prefixed with `rx`. Then returns a `Single` emitting the result
  +This code uses RX Java 2 and asynchronous methods are prefixed with `rx`. Upon completion the method returns a `Single` emitting the result
   or a failure.
   
   The failure management can be made at any stage, but generally, it's done in the `subscribe` method:
  
positive.code: 
  The first action is about observing the stream of _market_ messages. This is done using
  `vertx.eventBus().<JsonObject>consumer(GeneratorConfigVerticle.ADDRESS).toFlowable()`. We now have the stream of
  message, but we need to extract the JSON body and populate the `quotes` map. Implement the missing logic that extract the
   body of the message (with the `body()` method), and then put `name -> quote` in the `quotes` map.
  
  [.assignment]
  ****
  
negative.code: 2. Compile the java code and process resources (if any)
  3. Build a _fat-jar_
  
  A _fat-jar_ (also called _uber_ jar or _shaded_ jar) is a convenient way to package a Vert.x application. It creates an
  _über-jar_ containing your application and all its dependencies, including Vert.x. Then, to launch it, you just need
  to use `java -jar <jar name>` without having to handle the `CLASSPATH`. Wait, I told you that Vert.x does not dictate a
  type of packaging. It's true, fat jars are convenient, but they are not the only way. You can use plain (not fat) jars,
  OSGi bundles...
  
  The `pom.xml` file also contains a set of properties used to configure the application:
  