Intraday Stock Tracker

Design Decisions:

• At a high-level, the intraday-tracker project is broken down into the following components:
  • Tracking service interface
  • Tracking service in-memory implementation
  • Simple intraday security implementation
  • Intraday tracking command-line client
• The separation of the interface from the implementation allows:
  • Clearly documented interface contract details.
  • Unit tests to be written in a straight-forward manner.
  • Facilitates the addition of new implementations in the future.
  • Allows the client to inject the dependent service implementation of choice.
• The intraday security implementation stores the symbol, low price, high price, list of prices and sum of all prices from which the average price is calculated. Since this is a financial calculation, the rounding mode is exposed to the client to guarantee required behavior.
• In order to avoid gold-plating, all classes implement the minimum required methods including hashCode(), equals() and toString() where appropriate.
• Critical inputs are validated and runtime exceptions are thrown (if necessary). Otherwise, reasonable defaults are used.
• All exceptions are documented as part of the standard java doc.
• Test coverage includes both the intraday security and tracking service implementations.
• Note: Includes addition of trade date from February 13, 2019 coding review session.

Getting Started

These instructions will get you a copy of this project up and running on your local machine. Please make sure your JAVA_HOME environment variable is set to a valid JDK installation (JRE will not work).

1. Clone this Git repository:

git clone https://github.com/peter-sattler/intraday-tracker

2. Switch to the application directory:

cd intraday-tracker

3. Run the program:

./mvnw compile exec:java

Assessment Criteria

• Correct - Does your program work correct and meet the specification?
• Understandable - We spend much more time reading code than writing it. Is your submission easy for us to understand? Are assumptions and design decisions documented?
• Maintainable - Does your program lend itself to future enhancement. Does it have test coverage to protect against regressions.
• Pragmatic - We don't spend time on features that aren't needed today. Over-engineering and "gold-plating" are red flags for us.

The Problem

You will be building a command-line tool which tracks intraday data for an arbitrary set of securities. The tool receives security price updates in a specific format via STDIN. Every time a new line of input is received the tool will output updated intraday data, in the form of High, Low and Average. High and Low are the highest and lowest values seen for a given security, and Average is the mean of all prices seen so far for a given security.

Input is a space-delimited line of the form {TRADE DATE} {SYMBOL} {PRICE}, where {TRADE DATE} is the date on which the security was traded in YYYY-MM-DD format, {SYMBOL} is the symbol for a security and price is the current price for that security.

Output is set of space-delimited lines, one per security, of the form {TRADE DATE} {SYMBOL} {HIGH} {LOW} {AVERAGE}.

Here is an example sequence of updates from the command-line tool:

> 2019-02-12 APPL 178.44
< 2019-02-12 APPL 178.44 178.44 178.44

> 2019-02-11 GOOG 1149.49
< 2019-02-12 APPL 178.44 178.44 178.44
< 2019-02-11 GOOG 1149.49 1149.49 1149.49

> 2019-02-12 APPL 178.50
< 2019-02-12 APPL 178.50 178.44 178.47
< 2019-02-11 GOOG 1149.49 1149.49 1149.49

> 2019-02-11 GOOG 1148.10
< 2019-02-12 APPL 178.50 178.44 178.47
< 2019-02-11 GOOG 1149.49 1148.10 1148.80

> 2019-02-12 APPL 178.45
< 2019-02-12 APPL 178.50 178.44 178.46
< 2019-02-11 GOOG 1149.49 1148.10 1148.80

> 2019-02-12 FB 184.19
< 2019-02-12 APPL 178.50 178.44 178.46
< 2019-02-12 FB 184.19 184.19 184.19
< 2019-02-11 GOOG 1149.49 1148.10 1148.80

Pete Sattler
12 February 2019
peter@sattler22.net