A better Trader: Difference between revisions

From Bitpost wiki
No edit summary
Line 16: Line 16:
   AppUser
   AppUser
     BrokerAccount
     BrokerAccount
       SP
       broker (not worthy of its own layer)
       AS
       StockRun
        StockPick+AutotradedStock


=== CI ===
=== CI ===

Revision as of 13:22, 25 February 2017

Dev Documentation

AtController
  ui_
  memory_model_
  timers

MemoryModel
  prefs
  sq_
  brokers
  aps_
  users_

TradingModel
  AppUser
    BrokerAccount
      broker (not worthy of its own layer)
      StockRun
        StockPick+AutotradedStock

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
    -------------------------------------------------------------------------------