A better Trader: Difference between revisions
No edit summary |
No edit summary |
||
Line 28: | Line 28: | ||
# Turn off CI loop to debug via IDE | # Turn off CI loop to debug via IDE | ||
# Stop prod, pull down production database, run LIVE mode in debugger to diagnose production problems | # Stop prod, pull down production database, run LIVE mode in debugger to diagnose production problems | ||
=== QAB charts === | |||
* historical data DISPLAY only needs to show action points and highs/lows | |||
* internal historical data ANALYSIS should use all points | |||
Historic Stock Data use cases... | |||
1) user wants to see live chart | |||
2) user wants to see historical chart with bracketing | |||
3) user wants analysis | |||
--- | |||
1 and 2 should be aggressively node-reduced to fit the requested screen size! | |||
given: number of pixels of width | |||
provide: all bracket quotes plus the lowest+highest quotes in each 2-pixel range (minimum - adjustable to more aggressive clipping if desired) | |||
3 should NOT be node reduced at all on read, but should be node reduced once-pre-and-once-during analysis | |||
=== ANALYZE PSEUDO (REFACTOR THREE) === | === ANALYZE PSEUDO (REFACTOR THREE) === |
Revision as of 12:07, 4 February 2017
CI
MASTER SCRIPT: atci
We will have a live site, a constantly running CI site, and multiple dev environments.
RUN LIVE at bitpost.com:
m@bitpost rs at m@bitpost # if that doesn't work, start a session: screen -S at m@bitpost cd ~/development/thedigitalage/AbetterTrader/server-prod m@bitpost atlive ======================================================== *** LIVE MODE *** ======================================================== CTRL-A CTRL-D
RUN CI at bitpost.com:
# Keep this running to ensure that changes are dynamically built as they are committed # It should run at a predictable publicly available url that can be checked regularly # It runs in TEST but should run in a test mode that has an account assigned to it so it is very much like LIVE # It runs release build in test mode CTRL-A CTRL-D
RUN DEV anywhere but bitpost:
# Dev has complete control; most common tasks: # Code fast with a local CI loop - as soon as a file is changed, CI should restart server in test mode, displaying server log and refreshing server page # kill server, build, run, refresh browser # Turn off CI loop to debug via IDE # Stop prod, pull down production database, run LIVE mode in debugger to diagnose production problems
QAB charts
- historical data DISPLAY only needs to show action points and highs/lows
- internal historical data ANALYSIS should use all points
Historic Stock Data use cases...
1) user wants to see live chart 2) user wants to see historical chart with bracketing 3) user wants analysis --- 1 and 2 should be aggressively node-reduced to fit the requested screen size! given: number of pixels of width provide: all bracket quotes plus the lowest+highest quotes in each 2-pixel range (minimum - adjustable to more aggressive clipping if desired) 3 should NOT be node reduced at all on read, but should be node reduced once-pre-and-once-during analysis
ANALYZE PSEUDO (REFACTOR THREE)
Single aggressiveness slider value selected:
- analysis page requests analysis via AJAX: user selects aggressiveness
- APIGetRunAnalysis::handle_call()
- p_user_->findBrokerAccount(account_id);
- ba.getSPAS(run_id,&spit,&asit)
- g_p_local->readRunHistory() (does rh QAB pB_ allocations)
- atc_.thread_analyzeHistory(aggressiveness, rh, *papsAnalysis)
- generateAPSFromAggressiveness(aggressiveness, apsAnalysis)
- create MemoryModel, AppUser, BrokerAccount
- pba->analyze(rh)
- save papsAnalysis
- atc_.thread_buildRunJSON(rh)
- deallocate(rh)
Auto-analysis selected (aggressiveness=0)
carefully select (0..n) APSs to test based on a range of aggressive levels then do a small monte carlo around the best result only apply to one stock at a time (unlike before where we ran all - revisit this)
TRADE PSEUDO
load from SQL tables into Major Objects (std::unordered_sets of PersistentIDObjects)
API PSEUDO
APIGetRunLive::handle_call() g_p_local->getRunLiveJSON() readRunQAB(s_str_db_name...) (SAME as readRunLive!!)
APIGetRunHistory::handle_call() g_p_local->getRunHistoryJSON() readRunHistory readRunQAB
DEBUG LIVE
NOTE that you WILL lose stock quote data during the debugging time, until we set up a second PROD environment.
- WRITE INITIAL DEBUG CODE in any DEV environment
- UPDATE DEBUGGER to run with [live] parameter instead of debug ones
- COPY DATABASE directly from PROD environment to DEV environment: atimport prod
- STOP PROD environment at_server
- DEBUG. quickly. ;-)
- PUSH any code fix (without debug code) back to PROD env
- RESTART PROD and see if the fix worked
- REVERT DEV environment: clean any debug code, redo an atimport and reset the debugger parameters
Qt Creator settings
- Make sure you have already run [atbuild] and [atbuild debug].
- Open CMakeLists.txt as a Qt Creator project.
- It will force you to do CMake - pick cmake-release folder and let it go.
- Rename the build config to debug.
- Clone it to release and change folder to release.
- Delete make step and replace it with custom build:
./build.sh (no args) %{buildDir}
- Create run setups:
you have to use hardcoded path to BASE working dir (or leave it blank maybe?): /home/m/development/thedigitalage/AbetterTrader/server [x] run in terminal I recommend using TEST args for both debug and release: localhost 8000 test reanalyze (matches attest) LIVE args may occasionally be needed for use with [atimport prod]: localhost 8080 live (matches atlive)
HTML SHARED HEADER/FOOTER
------------------------------------------------------------------------------- THREE PARTS THAT MUST BE IN EVERY HTML FILE: ------------------------------------------------------------------------------- 1) all code above <container>, including these replaceables: a) logout: <button type='button' id='logout' class='btn btn-margined btn-xs btn-primary pull-right'>Log out</button> b) breadcrumbs: <!--bread--><li><a href="/1">1</a></li><li class="active">2</li><!--crumbs--> 2) logout button handler $( document ).ready(function() { 3) footer and [Bootstrap core Javascript] what a maintenance nightmare - but it seems best to do all 10-12 files manually -------------------------------------------------------------------------------