I build systems that save real money.

I built an event-driven forex bot on a practice OANDA account, then spent most of the project doing the unglamorous part: pulling eight years of candles down from the broker, pickling them, and testing whether the strategy actually made money. It mostly didn’t. Scroll the pipeline below — collect, store, compute, backtest, report, tune — and you’ll watch the thing that matters get built: not a money printer, but an instrument that tells me the truth about a strategy. Most strategies aren’t true. This one taught me to check.

Showing the bands the bot watches. Candles are procedurally generated; the formulas are the bot’s real ones.

1. 01Collect

   The broker hands you 3,000 candles per request, so you walk the window forward in time steps until you reach the end date. Three retries per window, because the API drops requests and an eight-year gap in your data is a bug you find months later.

   • Window: 2016-01-07 → 2023-12-31
   • Per request: 3,000 candles
   • Retries: 3

   CANDLE_COUNT = 3000
   INCREMENTS = { 'M5': 5 * CANDLE_COUNT,
                  'H1': 60 * CANDLE_COUNT,
                  'H4': 240 * CANDLE_COUNT }
   
   while to_date < end_date:
       to_date = from_date + dt.timedelta(minutes=time_step)
       candles = fetch_candles(pair, granularity, from_date, to_date, api)

2. 02Store

   Paginated fetches overlap at the seams, so the same candle arrives twice. Drop duplicates on time, sort, reset the index, freeze it to disk. Pickles rather than CSVs — the dtypes survive, and reload is instant when you are about to read the same frame four hundred times.

   • Pickles: 65 files
   • Instruments: 23
   • Timeframes: M5 · H1 · H4

   final_df.drop_duplicates(subset=['time'], inplace=True)
   final_df.sort_values(by='time', inplace=True)
   final_df.reset_index(drop=True, inplace=True)
   final_df.to_pickle(f"{file_prefix}{pair}_{granularity}.pkl")

3. 03Compute

   Every indicator is a rolling window over the typical price — no loops, no state. Bollinger bands are a moving average plus and minus a scaled standard deviation. The band is not a prediction; it is a statement about how unusual this price is relative to the last twelve.

   • Indicators: Bollinger · ATR · Keltner · RSI · MACD
   • Signal: close crosses band, open inside
   • Gates: spread ≤ max · gain ≥ min

   typical_p = (df.mid_c + df.mid_h + df.mid_l) / 3
   stddev = typical_p.rolling(window=n).std()
   df['BB_MA'] = typical_p.rolling(window=n).mean()
   df['BB_UP'] = df['BB_MA'] + (stddev * s)
   df['BB_LW'] = df['BB_MA'] - (stddev * s)

4. 04Backtest

   This is where the project actually happened. I swept the parameter grid and watched almost all of it lose money. The first backtester was too slow to iterate on, so I vectorized it; when that was still too slow I ran the pairs across processes. Speed is not vanity here — it is how many hypotheses you get to kill per evening.

   • Combos swept: 32
   • Profitable: 3
   • Breakeven win rate: 41.7% @ RR 1.4

   # guru_tester.py  →  guru_tester_fast.py  →  ema_macd_mp.py
   def is_trade(row):
       if row.DELTA >= 0 and row.DELTA_PREV < 0:
           return BUY
       elif row.DELTA < 0 and row.DELTA_PREV >= 0:
           return SELL
       return NONE

5. 05Report

   Results go to Excel, one sheet per pair with an embedded line chart, because a notebook cell is where you compute a result and a spreadsheet is where you sit and stare at it until you believe it. The file ma_sim_H1.xlsx is still in the repo. It is 419 KB of me being wrong.

   • Output: ma_sim_H1.xlsx · 419 KB
   • Per pair: trades · total · mean · min · max gain
   • Notebooks: 16 in exploration/

   chart = book.add_chart({'type': 'line'})
   chart.add_series({
       'categories': [sheetname, start_row, labels_col, end_row, labels_col],
       'values':     [sheetname, start_row, data_col,   end_row, data_col],
   })
   chart.set_title({'name': title})

6. 06Tune

   What survives the backtest becomes configuration. The live bot loads it at boot, polls for newly closed candles, and sizes every position so a stop-out costs exactly $20 — whatever the pair, the pip location, or the distance to the stop. And it refuses to open a second position on a pair it is already in, because it once stacked entries all the way down.

   • Risk per trade: $20, always
   • Poll: M1 · newly closed candles
   • Guard: trade_is_open()

   { "trade_risk": 20,
     "pairs": { "EUR_USD": { "n_ma": 12, "n_std": 2.5,
                             "maxspread": 0.0004,
                             "mingain": 0.0014,
                             "riskreward": 1.4 } } }
   
   # trade_manager.py — refuse a second position on the same pair
   ot = trade_is_open(trade_decision.pair, api)
   if ot is not None: return None

• Collect → pickle → pandas → backtest → tune
• 8 years of candles · 23 instruments · 3 timeframes
• Bollinger mean-reversion · risk-sized positions
• Backtested 32 parameter combos — 3 made money
• Python · pandas · MongoDB · Flask · React

This runs on an OANDA practice account — no real money has ever been at risk, and I show no P&L because there is none worth showing. The candles in the simulation are procedurally generated; the thresholds, formulas, risk math, and signal logic are the bot’s real ones, ported line-for-line. The backtest result is the honest one: at a 1.4 risk-reward ratio you must win 41.7% of trades to break even, the strategy wins about exactly that, and then the spread takes it negative. That finding is the project.

Orbo looks like a music visualizer. Build one properly and you find out what it actually is: a real-time data system — a lossless 48 kHz feed off the OS mixer, a windowed feature pipeline, a lock-free hand-off between two clocks, a renderer on a 16.7-millisecond budget, and a CI rig that diffs the output pixels. This section is the engineering story in five acts: what’s being built, the challenges in the data path, the calls made under constraint, why the foundation holds, and where it’s headed. The music is just the workload.

/// Push mono samples; returns one `AudioFeatures` per completed hop.
pub fn push(&mut self, mono: &[f32]) -> Vec<AudioFeatures> {
    self.buffer.extend_from_slice(mono);
    let mut out = Vec::new();
    while self.buffer.len() >= FFT_SIZE {
        let (bands, energy, beat, surge, spectrum) =
            self.fft.process(&self.buffer[..FFT_SIZE]);
        // …
        self.buffer.drain(..HOP_SIZE);
    }
    out
}
// audio thread: features.store(Arc::new(f))
// render thread: features.load() — lock-free, no allocation

// ACES filmic tone mapping
fn aces_tonemap(x: vec3<f32>) -> vec3<f32> {
    let a = 2.51;
    let b = 0.03;
    let c = 2.43;
    let d = 0.59;
    let e = 0.14;
    return clamp((x * (a * x + b)) / (x * (c * x + d) + e),
                 vec3<f32>(0.0), vec3<f32>(1.0));
}

/// `--check-fresh`: recompute shader hashes and diff against the
/// manifest. No GPU — safe on headless CI runners; red when a
/// shader changed without regenerated snapshots.
pub fn check_fresh() -> Result<()> {
    let manifest = read_manifest(Path::new("scenes/images/manifest.txt"));
    let mut stale: Vec<&str> = Vec::new();
    for (_, key) in SCENES {
        match manifest.get(key) {
            Some(recorded)
                if *recorded != hash_str(&scene_shader_concat(key)) =>
                    stale.push(key),
            // …

• Capture → FFT → ArcSwap → render → post → CI
• 4096-pt FFT · Hann · 6 bands · beat + AGC
• 6 GPU scenes behind one Visualizer trait
• Dual-Kawase bloom → ACES · HDR pipeline
• Golden-image CI — headless, no GPU needed
• Rust · wgpu · WGSL · rustfft · cpal

The engine is a native Rust/wgpu desktop app — what you see on this page is not the engine. It is a TypeScript re-implementation of the engine’s real math: the band edges, the beat rule, and the gain-control constants are ported line-for-line and run over a procedurally generated signal. The repo is private while it’s in active development, so the numbers here come from a source-verified audit of the code rather than a public link. The 4K claim in the project’s own README is aspirational; the measured budget is 720p at 60 fps, and I’d rather tell you that than round up.