More README improvements

use-case-2/ARCHITECTURE.md

@@ -1,16 +1,16 @@
 ##Architecture
 
-This document is in place to give the developer a high level understanding of how this app's structural design. In this document you will find information about request/response handling, smart contract interaction, smart contract and transaction fee estimation, relational database schema layout. 
+This document is in place to give the developer a high level understanding of how this app's structural design. In this document you will find information about request/response handling, smart contract interaction, smart contract and transaction fee estimation, relational database schema layout.
 
 ### Request Handlers
 
-Requests that have the intention of communicating with the smart contracts are made on the frontend and sent to the backend of the application where an HTTP request is sent to Plutus Application Backend(PAB) that simulates communication with a deployed smart contract. A list of API requests can be found within `common/src/Common/Api.hs`. Note: Some familiarity on how to read Haskell function headers will immediately provide you with an idea of the input and output to these application APIs. 
+Requests that have the intention of communicating with the smart contracts are made on the frontend and sent to the backend of the application where an HTTP request is sent to Plutus Application Backend(PAB) that simulates communication with a deployed smart contract. A list of API requests can be found within `common/src/Common/Api.hs`. Note: Some familiarity on how to read Haskell function headers will immediately provide you with an idea of the input and output to these application APIs.
 
 ### Request Responses
 
-Responses to requests that have been made are not returned from the http request made on the backend of the application. Instead, the responses for the request can be discovered in two ways. 
+Responses to requests that have been made are not returned from the http request made on the backend of the application. Instead, the responses for the request can be discovered in two ways.
 
-One way is to submit an empty request to the `http://localhost:8080/api/new/contract/instances` endpoint and parse it's response for the `observableState` JSON key. Within these `observableState` JSON objects, there will be another key called `tag` provide the subject matter of the state being observed. For example, if awaiting the results of a Swap requests the value of `tag` will be `Swapped`.
+One way is to submit an empty request to the `http://localhost:8080/api/new/contract/instances` endpoint and parse its response for the `observableState` JSON key. Within these `observableState` JSON objects, there will be another key called `tag` provide the subject matter of the state being observed. For example, if awaiting the results of a Swap requests the value of `tag` will be `Swapped`.
 
 The second way is to listen for incoming smart contract `observableState` via websocket. Connection with the PAB websocket is established in this case using `ws://localhost:8080/ws/[contract-instance-id]`. In the frontend, Reflex-FRP's websocket libraries are used to detect changes in websocket data to generate events to provoke updates within the DOM. This is how it is possible to know when a swap was successful, when to update the wallet balances, fetch, and perform other calculations based on incoming response data.
 
@@ -25,4 +25,4 @@ Transaction fees are derived using regression analytical algorithms on a history
 There are 3 tables persisting information in this application.
 1. db_contract - The contract id of available wallets that can interact with the Uniswap smart contract. This table is used to display the available wallets a user can perform smart contract actions with on the landing page of the application.
 2. db_pooledTokens - The available tokens with supportive pools that enable them to be swappable. This table is used to display tokens that can be swapped in dropdown menus.
-3. db_txFeeDataSet - The history of smart contract transactions. This table is used to assemble a data set of uniswap transactions that is later referenced during transaction regression estimation. 
+3. db_txFeeDataSet - The history of smart contract transactions. This table is used to assemble a data set of uniswap transactions that is later referenced during transaction regression estimation.

use-case-2/README.md

@@ -15,15 +15,15 @@ By the end of this README you will be able to run the POKE-DEX on your machine l
 
 ## Running the App
 
-1. [Install Obelisk](https://github.com/obsidiansystems/obelisk#installing-obelisk).
+1. **Install Obelisk** by following the instructions [here](https://github.com/obsidiansystems/obelisk#installing-obelisk).
 
-2. Make sure you don't have anything running using port 8080.  You can check by running `netstat -nltp | grep ':8080'`; if you see something like `tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1234/some-server-process`, that means the port is in use by `some-server-process`, and you will need to stop that process.
+2. **Make sure you don't have anything running using port 8080**.  You can check by running `netstat -nltp | grep ':8080'`; if you see something like `tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      1234/some-server-process`, that means the port is in use by `some-server-process`, and you will need to stop that process.
 
-3. [Run PAB] In one terminal window, run `./scripts/run-pab.sh` to launch the PAB.  Once it has started running, it will output something like `[INFO] Starting PAB backend server on port: 8080`, followed by many additional lines starting with `[INFO]`.  You will need to leave the PAB running for as long as you are using the app; if the PAB shuts down for any reason, all chain data will be lost, and you will need to `rm -rf db` to clear the app state and then restart from this step.
+3. **Run PAB** in its own terminal window by `cd`ing to this directory and runing `./scripts/run-pab.sh`.  Once it has started running, it will output something like `[INFO] Starting PAB backend server on port: 8080`, followed by many additional lines starting with `[INFO]`.  You will need to leave the PAB running for as long as you are using the app; if the PAB shuts down for any reason, all chain data will be lost, and you will need to `rm -rf db` to clear the app state and then restart from this step.
 
-4. In a separate terminal window, run `ob run`.  After a while, it will output lines starting with `"Pool tokens persisted:`, at which point the app is fully functional.
+4. **Run this App** in a separate terminal window by `cd`ing to this directory and running `ob run`.  After a while, it will output lines starting with `"Pool tokens persisted:`, at which point the app is fully functional.
 
-5. In a Chrome or Chromium window (**not** Firefox, see [below](#development-mode-supported-browsers)), navigate to [http://localhost:8000](http://localhost:8000).
+5. **Open the App** in a Chrome or Chromium window (**not** Firefox, see [below](#development-mode-supported-browsers)), navigate to [http://localhost:8000](http://localhost:8000).
 
 ##  Development Mode Supported Browsers
 `ob run` uses a lot of tricks to make development fast.  Currently, it is only tested with Chrome-based browsers, such as Google Chrome and Chromium.  Firefox does **not** work - typically the app will load, but then hang.