Our customer - Bermuda is building a new automotive manufacturing plant to make cars and are looking for a simple dashboard to monitor and simulate costs. The dashboard has a series of sliders that allows them to simulate the costs for running the plant. In previous challenges we've developed the UI prototype using jquery, requirejs, d3js and is deployed at heroku.
The dashboard is very simple - user sets the values for the sliders in the main body and that updates the graphs, gauges and tables in the top. The user can than save the scenario or load an existing one. The compare view has the same features as the main dashboard view except that two scenarios are displayed side by side.
When one of the parameters is changed, the data for the graphs/gauges and tables will be recalculated in backend (by running a provided executable) and returned to frontend for display.
In this challenge we'll cover all the frontend features except for saving the report as pdf and sharing the results.
Backend and frontend should be 2 separate projects where backend will provide an API and frontend will serve public/static resources. Backend will be implemented using NodeJs&Express and frontend will integrate the current requirejs/jquery/d3js prototype with the backend (no need to convert it to React/Angular).
The list of parameters (operational tactical, strategic) and their ranges should be configurable in a config file in backend. The number of parameters will always be the same, but the labels and ranges might change, so you can encode them as parameter0 - parameter21 and have just labels and ranges configurable.
In the tactical parameters section, the four percentage parameters should always sum up to 100. If the user changes one of them, the remaining three should rebalance to get the sum back to 100.
The user can enter Sensitivity analysis mode by clicking the small graph icon next to the parameter labels. The x axis in the graph will be the percentage of slider value and the Y value will be value of the 'Total Cost' column in the output when varying that parameter from 0-100% with all other parameters being fixed. So for each of the active sensitivity analysis parameters we need to run the calculations with a few values of the slider (let's make it 10 as default), with other parameters being fixed. Each time the user changes one of the parameters, the process should be repeated. This can be a performance bottleneck, so trigger the updates of other parameters after user releases the slider (or the slider box handle in the graph), or a small 100ms delay when typing into the text box.
Each time a slider value changes, calculations should be triggered in backend. There are two executables that should be called: 'BermudaAutomate_No_v1.1' and 'BermudaAutomate_Yes_v1.1'. Which one to call is decided by the value of the 'Automate' parameter in the Operational group. If it's set to No, call the former one, otherwise call the latter one.
Each executable can be called in 2 modes:
- With no arguments. This will produce tab separated output to standard out using default values.
- With arguments - e.g. ./BermudaAutomate_Yes 0:200
- This will invoke the executable but ask it to use 200 for the value of the 0th indexed variable, for its run. Other variables will be at their defaults.
- Multiple variables can be passed in the command line e.g. ./BermudaAutomate_Yes 0:200 5:2.0
Input variables from the Bermuda Automotive interface are indexed as shown below
- 0 Profit per car
- 1 Install Cost for Lights
- 2 Cost per back seat install
- 3 Cost per tire
- 4 Engine Install Cost
- 5 QC Cost
- 6 Cost per spark plug
- 7 Painting Screwups
- 8 Wheel Assembly Success Rate
- 9 Induction Rate
- 10 Percent Supply Chain Failure
- 11 Brake Lining Success Rate
- 12 Tests per plug
- 13 Fuel Ignition Success Rate
- 14 Sedan
- 15 Luxury Sedan
- 16 SUV
- 17 Luxury SUV
- 18 Target Annual Car Production
- 19 Detroit Percent
- 20 Detroit Plant Production Rate
- 21 Mexico City Plant Production Rate
In all modes the output is printed to stdout and is tab separated of the following form:
Columns are named A through V. These column names translate to the following names in the Automotive interface:
Column | Name for Bermuda Dashboard | Value type
- A Chassis in transit Amounts (not costs)
- B Brake Installs Amounts (not costs)
- C Paint Jobs Amounts (not costs)
- D Annual Lights Installed Amounts (not costs)
- E Engine Installs Amounts (not costs)
- F Annual Cars Produced Amounts (not costs)
- G Sedans Amounts (not costs)
- H SUVs Amounts (not costs)
- I Luxury SUVs Amounts (not costs)
- J Luxury Sedans Amounts (not costs)
- K Total Costs Costs
- L Endowments Costs
- M Wiring & Linings Costs
- N Generators Costs
- O Painting Costs
- P QC Costs
- Q Interior Detailing Costs
- R Engine Installs Costs
- S Sedan % Percentage
- T Luxury Sedan % Percentage
- U SUV % Percentage
- V Luxury SUV% Percentage
In the backend, provide 3 'endpoints' for listing/saving/loading scenarios that will just return sample data for testing. These will be wired to database in a future challenge. Frontend actions should call these endpoints to get the data for display. 'RESTORE TODAY DEFAULTS' should also call the backend to get the default parameter values and you can return sample data for now.
Base code (UI prototype) is available in the forums.
Create a Docker image for both backend and frontend projects. Both images should have just the minimal environments and should start only the app process (so don't make the entrypoint be a bash shell). Application code should be embeded into the image, and not mapped as a volume. Applications should produce daily logs with all requests/responses/errors persisted to log files mapped to the host directory. Also, create a docker-compose script that will manage both containers.