Milan Farkas (84CKD00R)

Redline Engine

Wed, 29 Apr 2026 00:00:00 GMT

Project Redline Building a Trading System From Scratch

What Is Project Redline?

Project Redline is my full algorithmic trading suite, built entirely from scratch, covering every step from idea to live execution.

Most traders who go the algorithmic route either rely on off-the-shelf platforms that lock you in, or they hack together a bunch of disconnected scripts that barely talk to each other. I wanted neither. I wanted something I fully understood, fully owned, and could change at any time without asking anyone's permission.

That obsession turned into Project Redline. A professional trading framework for futures markets, written by one person, for one person.

:::important This isn't a "trading bot" in the YouTube sense. There's no magic AI predicting the market. It's a system that tests ideas honestly, executes them precisely, and doesn't lie to you about the results. :::

How a Strategy Goes From Idea to Live Market

The easiest way to explain it is to just walk through how a strategy actually gets built.

Step 1 Research and Backtesting (HardEdge)

Before real money is involved, a strategy needs to be tested on historical data. That's what HardEdge does.

You describe a strategy in a config file, what indicators to use, when to enter, how to manage risk, and HardEdge replays years of market data bar by bar to see how it would have performed. It handles all the messy stuff: slippage, commissions, partial fills, session boundaries, multi-timeframe logic.

The results are honest. It doesn't curve-fit, it doesn't hide losing trades, and it doesn't let you fool yourself.

:::important Important is that i do not use the whole dataset to train the model, i only use a small portion of the data set to train the model and then i use the rest of the dataset to test the model and will never tweak and test the model again on the same data set, because the more you tweak and test the model the more it will overfit and the more it will not show any real edge. :::

:::note HardEdge also runs parameter optimisation sweeps, testing thousands of combinations in parallel and rendering the results as a 3D surface. The goal isn't finding the single "best" setting. It's finding settings that work across a wide range, not just at one lucky point. but usually because of overfitting i do step 2 and only after that will I optimise the parameters :::

Step 2 Does It Actually Have an Edge? (MCPT)

Backtests can lie. A strategy that looks profitable might just have gotten lucky on that specific sequence of bars. MCPT (Monte Carlo Permutation Testing) is how I catch that.

The idea is simple: run the same strategy on thousands of randomly shuffled versions of the price data. If it performs about the same on shuffled data as on real data, there's no edge. If the real result is clearly better than almost every random run, there's a genuine signal.

:::important Monte Carlo Permutation Test is a statistical test that is very complex for beginners and this explanition above is an overly simplified version of it, so i will not go into the details of the test, but now you understand the idea of Monte Carlo Permutation Testing. :::

I run 1000 statistical tests before I even consider a strategy worth developing further (that means i go back to optimise the parameters and run this test again). Most ideas fail here. That's the point.

:::important Passing MCPT doesn't mean a strategy will make money going forward. It just means the historical result is unlikely to be noise. That's a necessary condition, not a guarantee. :::

Step 3 Pattern Discovery (DataMining)

Sometimes the question isn't whether a strategy works, it's whether there are any patterns worth building a strategy around in the first place.

DataMining uses a genetic algorithm to evolve candlestick pattern hypotheses directly from price data. It starts with random guesses, tests them, keeps the better ones, mutates and combines them, and repeats for hundreds of generations. Same idea as biological evolution, just applied to finding market structure.

The best patterns get validated on data the algorithm never saw during evolution. If they survive that, they're worth looking at.

Step 4 Live Execution (Sentinel)

Once a strategy is validated, Sentinel takes it live. This is the piece that actually places orders in the real market.

Sentinel is written in Rust, chosen specifically because speed and reliability matter here more than anywhere else. It connects to either NinjaTrader 8 (over a c# bridge) or Interactive Brokers (with their api) depending on what you're running. The exact same config file used in backtesting gets loaded by the live engine, so what you tested is what gets traded. No translation, no drift.

:::important Important is that I need to code the indicators in both Python and Rust, and the Strategy loader too, only the config file is the same json file in both components, and I don't want to use some bride for that, This is the best solution to keep them seperate but still use the same config file. :::

:::note Sentinel runs a background health monitor, logs UTC timestamps on every trade signal, and handles order state with thread-safe logic. Live trading is where bugs become expensive, so there's no room for sloppy code here. :::

Step 5 Everything Else (RedlineEngine)

All the monitoring and review lives in RedlineEngine, a native Swift app for macOS and iOS. It has three tabs.

The first tab is performance analytics: equity curve, drawdown, win rate, expectancy. Everything I need to see whether a strategy is running clean or starting to fall apart. Both HardEdge and Sentinel will send the data to this tab.

The second tab is a visual strategy editor. Instead of writing JSON config files by hand, you build strategies through a UI. It generates the same file format HardEdge and Sentinel use, so there's no disconnect between what you designed and what actually runs.

The third tab is trade review. For those who are familiar with Funded Firms, this tab would be familiar to you, with the calendar view, the summary stats, and the actual individual trades.

:::important The reason it all lives in one native app instead of a bunch of browser tabs is the same reason I built everything else myself, I want one place that does exactly what I need, nothing more, nothing less. :::

How It All Connects

Every component feeding into a separate tool is a problem I've seen kill other people's setups. Results live in one place, the live engine is somewhere else, the review dashboard is a third thing that doesn't know about either. You end up copying numbers by hand and wondering why things don't add up.

I solved that with a central Supabase API. When HardEdge finishes a backtest, it uploads the results. When Sentinel executes a trade in live markets, it uploads that too with 3 diffrent type of logs (network, system, execution). RedlineEngine then reads from the same API on both macOS and iOS , so every tab is pulling live or backtest, real data from a single source of truth, not local files, not exports, not manual syncing.

:::note This means I can finish a backtest on my laptop, pick up my phone, and see the full results immediately. Or check how Sentinel is running from anywhere without being at my desk. That's the kind of workflow that actually matters when you're trading. :::

The Stack

Backtesting       Python, Polars, NumPy
Live Engine       Rust (Sentinel), C# (NinjaTrader bridge)
Pattern Mining    Python, Genetic Algorithms
Statistics        Monte Carlo Permutation Testing
API Layer         Supabase (self-hosted, shared between all components)
Native App        Swift (RedlineEngine , macOS and iOS)
Code Quality      Pre-commit hooks, CodeRabbit, CI/CD, SonarQube

How the Code Actually Gets Shipped

I treat this codebase like production software, not a personal project I can leave in a broken state.

Every commit runs through pre-commit hooks first , formatting, linting, type checking, security scanning, all of it. Nothing gets committed if the hooks don't pass. No exceptions, no --no-verify shortcuts.

After that, CodeRabbit reviews the diff automatically. It catches logic issues, spots things I missed, and flags anything that looks off before it ever touches the main branch.

Then CI/CD kicks in with four jobs running in parallel: lint, Rust build, docs build, and the full test suite. If any one of those fails, the branch doesn't merge.

Finally, SonarQube runs a static analysis pass , code quality, duplication, potential bugs, security hotspots. It gives a second opinion on things that are technically valid code but still wrong.

:::note Most personal projects skip all of this. I don't, because the moment a bug makes it into Sentinel and the live engine is running, it's not a debugging exercise anymore , it's a real problem with real consequences. :::

Why Build It Instead of Buy It?

Because the tools that exist either don't do what I need, or they're a black box I can't trust.

When I trade with a system, I need to understand every decision it makes. If Sentinel skips an entry, I need to know why. If HardEdge shows a drawdown, I need to know exactly which trades caused it and under what conditions.

Off-the-shelf platforms don't give you that. You get a result and you're expected to trust it. That's not how I work.

:::important Building your own tools also forces you to understand the domain at a level no course can give you. You can't write a position manager without understanding exactly how stops, targets, and partial exits interact. You can't write a regime filter without really thinking about what "market state" means in data terms.

The act of building is the education. :::

Current Status

The full pipeline is running , backtesting, statistical validation, live execution on both NinjaTrader and Interactive Brokers. The codebase has over 1,000 automated tests covering the core engine, the statistical modules, and the pattern discovery system.

Right now I'm focused on the Futures transition, dialling in execution and validating strategies under live conditions. The infrastructure is solid. Now it's about finding edges worth deploying.

:::tip If you're building your own trading system: separate your backtesting from your live execution cleanly from the start. The moment those two things share code in a messy way, your test results stop meaning anything. And please don't forget to add tests, MCPT, CI/CD, SonarQube, Pre-commit hooks these are the most important things to have in your system :::

Project Redline

Sat, 07 Feb 2026 00:00:00 GMT

Backtest

Config

Account Size      50_000$
Symbol            CME NQ
Contracts         5
Data              Databento
Datatype          2023:OHLC, 2024:OHLC, 2025:Tick
Evaluation Rules  MyFundedFutures
Trading Hours     Between 15:00-16:00

2022

============================================================
BACKTEST RESULTS
============================================================

=== Performance ===
Final Equity (MTM):       $163,320.77
Total PnL (MTM):          $113,320.77
  Realized PnL:           $123,523.17
  Unrealized PnL (end):   $-10,202.40

=== Risk ===
Max Drawdown:             -6.66%
Max DD Duration:          34.07 days (~196225 bars)
Annualized Return*:       674.09%
Annualized Vol*:          26.29%
Sharpe*:                  25.64
Sortino*:                 2.30
Calmar*:                  101.19
*Note: annualization on 15s bars is for relative comparisons.

=== Trades ===
Trades:                   436
Wins / Losses / BE:       376 / 60 / 0
Win Rate:                 86.24%
Profit Factor:            3.48
Avg Trade (Expectancy):   $283.31
Median Trade:             $120.33
Std Trade:                $875.45
Avg Win / Avg Loss:       $460.89 / $-829.56
Best / Worst Trade:       $4013.50 / $-1163.33
Max Consecutive W/L:      36 / 2

=== Exit Reasons ===
  SESSION_END        16  (3.7%)
  SL                349  (80.0%)
  TIME_STOP          58  (13.3%)
  TP2                13  (3.0%)

=== 2-Step Exit Stats ===
TP1 Hits:                 375
TP2 Hits:                 13
Break-even Saves:         292

=== Performance by Entry Timeframe ===
15s   | Trades:   19 | W/L:  14/  5 | Win%:  73.7% | Avg: $-130.25 | Total: $ -2474.67
30s   | Trades:  401 | W/L: 346/ 55 | Win%:  86.3% | Avg: $ 239.09 | Total: $ 95876.33
45s   | Trades:   16 | W/L:  16/  0 | Win%: 100.0% | Avg: $ 168.00 | Total: $  2688.00

=== Execution ===
Avg Trade Duration:       1.90 minutes
Avg Commission/RT:        $21.39
============================================================

======================================================================
PROP FIRM EVALUATION ANALYSIS
======================================================================

=== Evaluation Rules ===
Profit Target:        $3000.0 (PASS)
Loss Limit:           $-2000.0 from peak (FAIL)
Drawdown Type:        End-of-Day (EOD)
Starting Capital:     $50000

=== Results ===
Total Attempts:       238
Passed:               237 (99.6%)
Failed:               1 (0.4%)

Avg Days to Pass:     1.2 trading days
Avg Days to Fail:     1.0 trading days

=== Cost Analysis ===
Expected Attempts:    1.00
Expected Cost:        $107.45 per funded account
ROI (at $25k/year):   233x

2023

============================================================
BACKTEST RESULTS
============================================================

=== Performance ===
Final Equity (MTM):       $202,191.93
Total PnL (MTM):          $152,191.93
Realized PnL:           $167,542.33
Unrealized PnL (end):   $-15,350.40

=== Risk ===
Max Drawdown:             -5.17%
Max DD Duration:          11.99 days (~69066 bars)
Annualized Return*:       1079.20%
Annualized Vol*:          26.37%
Sharpe*:                  40.92
Sortino*:                 4.64
Calmar*:                  208.77
*Note: annualization on 15s bars is for relative comparisons.

=== Trades ===
Trades:                   656
Wins / Losses / BE:       566 / 90 / 0
Win Rate:                 86.28%
Profit Factor:            3.73
Avg Trade (Expectancy):   $255.40
Median Trade:             $109.17
Std Trade:                $698.99
Avg Win / Avg Loss:       $404.27 / $-680.81
Best / Worst Trade:       $3337.00 / $-1173.33
Max Consecutive W/L:      56 / 3

=== Exit Reasons ===
SESSION_END        22  (3.4%)
SL                514  (78.4%)
TIME_STOP         110  (16.8%)
TP2                10  (1.5%)

=== 2-Step Exit Stats ===
TP1 Hits:                 564
TP2 Hits:                 10
Break-even Saves:         425

=== Performance by Entry Timeframe ===
15s   | Trades:   11 | W/L:   8/  3 | Win%:  72.7% | Avg: $ 284.79 | Total: $  3132.67
30s   | Trades:  533 | W/L: 461/ 72 | Win%:  86.5% | Avg: $ 207.31 | Total: $110495.33
45s   | Trades:  112 | W/L:  97/ 15 | Win%:  86.6% | Avg: $ 170.42 | Total: $ 19087.00

=== Execution ===
Avg Trade Duration:       2.08 minutes
Avg Commission/RT:        $21.39
============================================================

======================================================================
PROP FIRM EVALUATION ANALYSIS
======================================================================

=== Evaluation Rules ===
Profit Target:        $3000.0 (PASS)
Loss Limit:           $-2000.0 from peak (FAIL)
Drawdown Type:        End-of-Day (EOD)
Starting Capital:     $50000

=== Results ===
Total Attempts:       273
Passed:               271 (99.3%)
Failed:               2 (0.7%)

Avg Days to Pass:     1.0 trading days
Avg Days to Fail:     1.0 trading days

=== Cost Analysis ===
Expected Attempts:    1.01
Expected Cost:        $107.79 per funded account
ROI (at $25k/year):   232x

2024

============================================================
BACKTEST RESULTS
============================================================

=== Performance ===
Final Equity (MTM):       $156,722.20
Total PnL (MTM):          $106,722.20
  Realized PnL:           $118,937.00
  Unrealized PnL (end):   $-12,214.80

=== Risk ===
Max Drawdown:             -6.90%
Max DD Duration:          26.97 days (~155340 bars)
Annualized Return*:       613.62%
Annualized Vol*:          29.06%
Sharpe*:                  21.12
Sortino*:                 2.09
Calmar*:                  88.98
*Note: annualization on 15s bars is for relative comparisons.

=== Trades ===
Trades:                   522
Wins / Losses / BE:       434 / 88 / 0
Win Rate:                 83.14%
Profit Factor:            2.79
Avg Trade (Expectancy):   $227.85
Median Trade:             $114.58
Std Trade:                $757.23
Avg Win / Avg Loss:       $426.80 / $-753.35
Best / Worst Trade:       $3835.83 / $-1178.33
Max Consecutive W/L:      24 / 3

=== Exit Reasons ===
  SESSION_END        21  (4.0%)
  SL                410  (78.5%)
  TIME_STOP          85  (16.3%)
  TP2                 6  (1.1%)

=== 2-Step Exit Stats ===
TP1 Hits:                 431
TP2 Hits:                 6
Break-even Saves:         324

=== Performance by Entry Timeframe ===
15s   | Trades:   20 | W/L:  14/  6 | Win%:  70.0% | Avg: $ -24.38 | Total: $  -487.67
30s   | Trades:  445 | W/L: 374/ 71 | Win%:  84.0% | Avg: $ 185.63 | Total: $ 82604.33
45s   | Trades:   57 | W/L:  46/ 11 | Win%:  80.7% | Avg: $ 127.15 | Total: $  7247.67

=== Execution ===
Avg Trade Duration:       2.18 minutes
Avg Commission/RT:        $21.47
============================================================

======================================================================
PROP FIRM EVALUATION ANALYSIS
======================================================================

=== Evaluation Rules ===
Profit Target:        $3000.0 (PASS)
Loss Limit:           $-2000.0 from peak (FAIL)
Drawdown Type:        End-of-Day (EOD)
Starting Capital:     $50000

=== Results ===
Total Attempts:       269
Passed:               269 (100.0%)
Failed:               0 (0.0%)

Avg Days to Pass:     1.1 trading days

=== Cost Analysis ===
Expected Attempts:    1.00
Expected Cost:        $107.00 per funded account
ROI (at $25k/year):   234x

2025

============================================================
BACKTEST RESULTS
============================================================

=== Performance ===
Final Equity (MTM):       $114,281.27
Total PnL (MTM):          $64,281.27
  Realized PnL:           $73,664.67
  Unrealized PnL (end):   $-9,383.40

=== Risk ===
Max Drawdown:             -6.55%
Max DD Duration:          44.69 days (~257403 bars)
Annualized Return*:       314.60%
Annualized Vol*:          24.70%
Sharpe*:                  12.74
Sortino*:                 1.10
Calmar*:                  48.02
*Note: annualization on 15s bars is for relative comparisons.

=== Trades ===
Trades:                   401
Wins / Losses / BE:       337 / 63 / 1
Win Rate:                 84.04%
Profit Factor:            2.59
Avg Trade (Expectancy):   $183.70
Median Trade:             $108.50
Std Trade:                $679.66
Avg Win / Avg Loss:       $355.64 / $-733.12
Best / Worst Trade:       $3654.33 / $-1076.67
Max Consecutive W/L:      40 / 3

=== Exit Reasons ===
  SESSION_END        15  (3.7%)
  SL                328  (81.8%)
  TIME_STOP          55  (13.7%)
  TP2                 3  (0.7%)

=== 2-Step Exit Stats ===
TP1 Hits:                 337
TP2 Hits:                 3
Break-even Saves:         269

=== Performance by Entry Timeframe ===
15s   | Trades:   10 | W/L:   9/  1 | Win%:  90.0% | Avg: $ 181.53 | Total: $  1815.33
30s   | Trades:  336 | W/L: 278/ 57 | Win%:  82.7% | Avg: $ 123.42 | Total: $ 41468.33
45s   | Trades:   55 | W/L:  50/  5 | Win%:  90.9% | Avg: $ 152.47 | Total: $  8385.67

=== Execution ===
Avg Trade Duration:       2.06 minutes
Avg Commission/RT:        $21.43
============================================================

======================================================================
PROP FIRM EVALUATION ANALYSIS
======================================================================

=== Evaluation Rules ===
Profit Target:        $3000.0 (PASS)
Loss Limit:           $-2000.0 from peak (FAIL)
Drawdown Type:        End-of-Day (EOD)
Starting Capital:     $50000

=== Results ===
Total Attempts:       261
Passed:               261 (100.0%)
Failed:               0 (0.0%)

Avg Days to Pass:     1.1 trading days

=== Cost Analysis ===
Expected Attempts:    1.00
Expected Cost:        $107.00 per funded account
ROI (at $25k/year):   234x

Live

Not enough Data yet...

How to Think in Code

Sun, 26 Oct 2025 00:00:00 GMT

How to Think Like a Programmer

The biggest problem people face with programming is that they watch too many tutorials. Don't get me wrong — tutorials aren't bad. But what happens is you copy and paste code, and at the end of the day you've learned nothing about how to structure or write something on your own.

I struggled with this myself. I learned GDScript from tutorials. I even learned how to make games in Godot. But when it was time to write code alone, I froze. I couldn't structure anything. I didn't understand why I needed multiple functions instead of one big block. I could write small fragments, but I didn't truly understand what was behind all of it.

If you struggle like I did — let me show you how I figured it out.

It turns out there are really only two pillars to programming mastery:

Thinking in Code — translating concepts into executable logic
Writing Clean Code — structuring code for clarity and maintainability

Learn these two things and you can build anything. So let's get into it.

Pillar 1: Thinking in Code

The Translation Problem

You understand "player damages enemy" as a concept. But how does that become code?

The trick is realizing that every programming language has more or less the same structure. The differences are mostly syntax. If you move from something like Python to C++, you get more features — but you can structure your code the same way with a few adjustments.

:::important First of all, you always — and I mean always — need to break code down to simple pseudocode. What does an if-statement actually do? What about a function? A for-loop? Here's how I think about them: :::

if (something is true) → then do this; else do that

function (input/settings)
{
    code that does something with your input
    and produces an output or changes some state
}

for (repeat until this condition is met)
{
    code that runs a fixed number of times
}

while (this statement is true)
{
    code that runs endlessly until the condition becomes false
}

:::caution Please do NOT make a while(true) loop unless you know what you're doing — it can easily crash your computer. :::

Logical Operators

and, or, and not are essential. Let me demonstrate:

if this AND that → both must be true for the whole condition to be true
if this OR that → only one needs to be true
if NOT this → reverses the statement. If it's false, it becomes true. Think of it as a flipper.

For example, if FireRateLimited is a boolean that's true when you can't shoot, you want to shoot when it's not limited:

while(!FireRateLimited)
{
    shoot()
}

You can stack conditions:

while(!FireRateLimited and !MagazineEmpty)
{
    shoot()
}

while(!FireRateLimited and !MagazineEmpty and Input.is_action_just_pressed("Shoot"))
{
    shoot()
}

And so on. Once you internalize this, you have enough to build almost anything.

The Mental Model

Thinking in code means breaking down real-world concepts into five elements:

Entities (nouns) — What objects exist? → Player, Enemy
Properties (adjectives) — What describes them? → health, damage_value, is_alive
Actions (verbs) — What can happen? → attack(), take_damage(), die()
State Changes — How does the system evolve? → Enemy.health -= damage
Conditions — When do things happen? → if enemy.health <= 0

For any concept you want to code, ask yourself:

What are the nouns? → Classes/Objects
What are the verbs? → Methods/Functions
What are the relationships? → How objects interact
What is the state? → What changes over time
What is the flow? → Order of operations

Example: "Player Damages Enemy"

Let's break it down:

Who are the actors? → Player, Enemy
What's the action? → Dealing damage
What changes? → Enemy's health
What follows? → Check if enemy dies

We need two files — one for the Hero, one for the Enemy.

Hero logic:

if (hero detects an enemy in range AND hero presses attack)
    then call Enemy.Damaged(10)

Enemy logic:

int Health = 100

function Damaged(int damage)
{
    Health -= damage
}

That's it. Now you just need to research how to apply this in your specific engine or language.

Here's how it looks in Godot:

Main Scene
├── Player
│   ├── Sprite2D
│   └── RayCast2D
└── Enemy
    ├── Sprite2D
    └── Collision2D

Player.gd

@onready var ray_cast_2d: RayCast2D = $RayCast2D

func _process(delta: float) -> void:
    if ray_cast_2d.is_colliding():
        var hit = ray_cast_2d.get_collider()
        hit.on_hit_by_raycast(10)

Enemy.gd

var health := 100

func on_hit_by_raycast(damage: int) -> void:
    health -= damage

Concept → pseudocode → real code. Every time.

More Examples

"Car Accelerates on a Highway"

Nouns: Car, Highway. Verbs: accelerate. Properties: speed, max_speed, position. Condition: can't exceed max_speed.

class Car:
    def __init__(self):
        self.speed = 0
        self.max_speed = 120

    def accelerate(self, amount):
        self.speed = min(self.speed + amount, self.max_speed)

"Trading Bot Buys When Price Drops Below Threshold"

Nouns: TradingBot, Order, Price. Verbs: monitor, execute. Condition: price < threshold AND not already in a position.

class TradingBot:
    def __init__(self, threshold):
        self.threshold = threshold
        self.in_position = False

    def on_price_update(self, current_price):
        if current_price < self.threshold and not self.in_position:
            self.execute_buy(current_price)

    def execute_buy(self, price):
        # execute order logic
        self.in_position = True

"Inventory Removes Item When Player Uses It"

Nouns: Inventory, Item, Player. Verbs: use, remove, apply_effect. Flow: use item → apply effect → remove from inventory.

class Inventory:
    def __init__(self):
        self.items = {}

    def use_item(self, item_name, player):
        if self.items.get(item_name, 0) <= 0:
            return False
        item = get_item_definition(item_name)
        item.apply_effect(player)
        self.items[item_name] -= 1
        if self.items[item_name] <= 0:
            del self.items[item_name]
        return True

Same pattern every time. Nouns, verbs, state, conditions, flow.

Pillar 2: Writing Clean Code

Thinking in code gets you working software. Writing clean code makes it maintainable software. Here's the core principle:

:::important Every function should do ONE thing, and its name should accurately describe that one thing. :::

The Problem: Hidden Responsibilities

# BAD — this function does TWO things
def check_password(password):
    if password == stored_password:
        initialize_session()  # surprise side effect!
        return True
    return False

The name says "check" but it also initializes a session. You can't reuse the check without triggering the session. You can't test them independently.

# GOOD — each function does ONE thing
def check_password(password):
    return password == stored_password

def initialize_session():
    # session logic here
    pass

# Usage
if check_password(user_input):
    initialize_session()

The 10 Principles of Clean Code

0. Naming Reveals Intent

Function names are verbs: calculate_damage(), validate_input(), spawn_enemy(). Variable names are descriptive: enemy_health not eh, player_position not pp. If a name requires a comment to explain, the name is wrong.

# BAD
def calc(a, b):
    return a * b * 0.75

# GOOD
def calculate_discounted_price(original_price, quantity):
    DISCOUNT_RATE = 0.75
    return original_price * quantity * DISCOUNT_RATE

1. Small Functions

If you can't see the entire function on your screen, it's probably too long. Aim for 10–20 lines max.

# BAD — god function doing everything
def process_game_turn():
    # 80 lines of player input, enemy AI, physics, rendering, scoring...

# GOOD — orchestrate focused functions
def process_game_turn():
    handle_player_input()
    update_enemy_ai()
    check_collisions()
    render_frame()
    update_score()

2. Functions Do One Thing

If you need the word "and" to describe what a function does, it does too much. "Check password and initialize session" → split it.

3. Consistent Levels of Abstraction

High-level functions call mid-level functions. Mid-level calls low-level. Don't mix raw database queries with business logic in the same function.

# BAD — mixed abstraction
def process_payment(order):
    total = order.total
    if order.user.credit_card[0:4] == "4532":
        charge_visa(total)
    db.execute("UPDATE orders SET status='paid' WHERE id=?", order.id)

# GOOD — each level reads clearly
def process_payment(order):
    validate_payment_method(order)
    charge_customer(order)
    mark_order_as_paid(order)

4. Avoid Repeated Switch Statements

If you're writing the same if/elif chain in multiple places, use polymorphism or data structures instead.

# BAD — duplicated logic
def calculate_damage(weapon_type, base_damage):
    if weapon_type == "sword": return base_damage * 1.2
    elif weapon_type == "bow": return base_damage * 0.8

def get_attack_speed(weapon_type):
    if weapon_type == "sword": return 1.0
    elif weapon_type == "bow": return 1.5

# GOOD — centralized
WEAPON_STATS = {
    "sword": {"damage_mult": 1.2, "speed": 1.0},
    "bow": {"damage_mult": 0.8, "speed": 1.5},
}

5. Minimize Function Arguments

Zero to two arguments is ideal. Three or more? You probably need an object.

# BAD
def create_character(name, health, mana, strength, dex, int, level, x, y, team):
    pass

# GOOD
def create_character(name, stats, position, team, level=1):
    pass

6. No Hidden Side Effects

A function called get_something() should never secretly modify state. If it changes things, make that obvious in the name.

# BAD — "check" but also modifies
def check_password(password):
    if password == stored_password:
        self.session = initialize_session()  # hidden!
        self.login_count += 1               # hidden!
        return True
    return False

# GOOD — explicit
def is_password_valid(password, stored_password):
    return password == stored_password

7. Command-Query Separation

Functions should either do something (command) or answer something (query). Not both.

# BAD — does both
def get_next_enemy():
    enemy = self.enemies.pop()  # changes state
    return enemy                # returns data

# GOOD
def has_next_enemy():       # query
    return len(self.enemies) > 0

def remove_next_enemy():    # command
    return self.enemies.pop()

8. Handle Errors Properly

Don't mix error handling with business logic. Use exceptions instead of error codes.

# GOOD
def process_player_move(direction):
    validate_direction(direction)
    new_pos = calculate_new_position(direction)
    check_collision(new_pos)
    player.position = new_pos

try:
    process_player_move(user_input)
except InvalidDirectionError:
    show_message("Invalid direction")
except CollisionError as e:
    handle_collision(e)

9. DRY — Don't Repeat Yourself

If you're copy-pasting code, extract it into a function.

# BAD — duplicated
def damage_player(amount):
    player.health -= amount
    if player.health <= 0:
        player.is_alive = False

def damage_enemy(enemy, amount):
    enemy.health -= amount
    if enemy.health <= 0:
        enemy.is_alive = False

# GOOD — shared logic
def apply_damage(entity, amount):
    entity.health -= amount
    if entity.health <= 0:
        entity.is_alive = False

10. The Refinement Loop

Writing clean code is rewriting. First draft: make it work. Second pass: make it right. Third pass: make it fast — only if needed.

# First draft — just works
def do_stuff(x, y):
    result = []
    for i in x:
        if i > 5:
            result.append(i * y)
    return result

# Refined — clear and intentional
def multiply_values_above_threshold(values, multiplier, threshold=5):
    return [v * multiplier for v in values if v > threshold]

Real-World Example: Game Enemy AI

Let's apply both pillars to a real scenario — an enemy AI system.

# BAD — god function that does everything
def update_enemy(enemy, player, delta_time):
    # movement, attack, animation, health regen
    # all crammed into 40+ lines...

# GOOD — each system separated

def get_movement_direction(enemy, player):
    if calculate_distance(enemy.position, player.position) < enemy.chase_range:
        return normalize(player.position - enemy.position)
    return enemy.patrol_direction

def move_enemy(enemy, direction, delta_time):
    enemy.position += direction * enemy.speed * delta_time

def can_attack(enemy, player):
    distance = calculate_distance(enemy.position, player.position)
    return distance < enemy.attack_range and enemy.attack_cooldown <= 0

def execute_attack(enemy, player):
    damage = calculate_damage(enemy.base_damage)
    apply_damage(player, damage)
    enemy.attack_cooldown = enemy.attack_delay

def update_animation(enemy):
    enemy.animation = "walk" if enemy.velocity.length() > 0 else "idle"

def regenerate_health(enemy, delta_time):
    if enemy.health < enemy.max_health:
        enemy.health = min(enemy.health + enemy.regen_rate * delta_time, enemy.max_health)

# Orchestrate — reads like a plan
def update_enemy(enemy, player, delta_time):
    direction = get_movement_direction(enemy, player)
    move_enemy(enemy, direction, delta_time)

    if can_attack(enemy, player):
        execute_attack(enemy, player)

    update_animation(enemy)
    regenerate_health(enemy, delta_time)

Each function is testable on its own. You can modify movement without touching combat. You can reuse apply_damage() for any entity. The orchestrating function reads like English.

Advanced Thinking Patterns

Once the fundamentals click, these patterns will level you up.

State Machine Thinking

When something has distinct modes — idle, walking, jumping, attacking — think in states and transitions. Each state knows its own behavior and when to hand off to the next.

class Player:
    def __init__(self):
        self.state = "idle"

    def handle_input(self, input):
        if self.state == "idle":
            if input.jump: self.transition_to("jumping")
            elif input.move: self.transition_to("walking")
            elif input.attack: self.transition_to("attacking")

Event-Driven Thinking

When one event should trigger many reactions — "enemy killed" updates score, plays sound, spawns loot — use an event bus. The publisher doesn't know or care who's listening.

events.subscribe("enemy_killed", score_system.add_points)
events.subscribe("enemy_killed", audio_system.play_death_sound)
events.subscribe("enemy_killed", loot_system.spawn_drops)

def kill_enemy(enemy):
    enemy.alive = False
    events.publish("enemy_killed", {"enemy": enemy, "position": enemy.position})

Pipeline Thinking

When data flows through transformations — parse, validate, convert, filter, calculate — each stage is independent and composable.

def process_trading_data(raw_data):
    parsed = parse_csv(raw_data)
    cleaned = clean_trade_data(parsed)
    enriched = add_technical_indicators(cleaned)
    save_trades(enriched)
    return enriched

Want to process without saving? Just drop the last step. Want to add a new indicator? Insert one function. The pipeline doesn't care.

Code Smells Cheat Sheet

Watch out for these red flags:

Function name uses "and" → validate_and_save() — split it
Generic names → do_stuff(), handle(), manager() — rename or rethink
Long functions → 30+ lines usually means multiple responsibilities
A "get" function that also modifies state → separate query from command
Boolean flag arguments → save(data, compress=True) — probably two functions
Copy-pasted blocks → extract into a shared function
Global variables in calculations → pass them as arguments instead
Can't test without a database/API/filesystem → extract dependencies

The Mastery Loop

1. Encounter a concept
       ↓
2. Think in code (break it down)
       ↓
3. Write working code
       ↓
4. Refactor for cleanliness
       ↓
5. Review: Does it read well? Does each piece do one thing?
       ↓
6. Learn from the pattern
       ↓
   (Return to 1 with better instincts)

Quick Reference

Thinking in Code — 5 Questions:

What are the nouns? → Objects/data
What are the verbs? → Actions/functions
What is the state? → What changes
What are the conditions? → When things happen
What is the flow? → Order of operations

Clean Code — 5 Rules:

One function = one job
Name reveals intent
No hidden side effects
No "and" in function descriptions
If you can't see it all on screen, it's too long

The Refactoring Workflow:

Does it work? → Make it work first
What does it do? → Name it clearly
Does it do one thing? → Split if not
Can I test it? → Extract dependencies
Is it readable? → Simplify

:::important When you're stuck or your code feels messy, ask yourself two questions:

Can I explain this concept without code? (Thinking)
Does each piece do ONE clear thing? (Cleanliness)

These two questions will guide you back to clarity every time. :::

"First, make it work. Then, make it right. Then, make it fast." — Kent Beck

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." — Martin Fowler

Private Account Management!

Mon, 20 Oct 2025 00:00:00 GMT

How to Manage your portfolio(Bank Accounts) before you even start to Invest your money?

source: https://www.finanzfluss.de/

This picture summaries pretty good how you should build up safety before you hop into the deep waters!

But this picture doesn't answer every question and its German so let me help you with that, there are a ton of account-models like this one but this one is in my opinion the best

First of all we need some translation

Gehalt: Income

Ausgaben: Expenses

Girokonto: In Europe this is a common basic bank account(normally without interest)

Tagesgeld: This is any given account with some interest(this is not important) where you put your "Emergency" money like 3x your salary when money is tight

Festgeld: This is an account with the most interest in your country this doesn't have to be your Main account

Depot: Like Robinhood, or in Europe TradeRepublic or Scalable this has to be where you can purchase Stocks or in my case ETFs

How should your money move?

First of all you get your paycheck on your First Girokonto 1 this is you Main account and the only account where you may spend your money But first you should always pay yourself! like when you get your paycheck you already need to have an automatic system(Most Banks support this!) to get some money onto your Girokonto 2, Festgeld and Depot. How much? that depends. You should always look these accounts like your short term wants(1-3 years), medium term wants(5-6 years) and long term savings(10-20 years)

:::important I say wants and savings because the most important account is your depot(investments) because with the power of compound interest you will gain the most money on this specific account the other two is for your "fun" in this process. Imagine if you save for 10-20 years, but you don't buy anything just save everything, after a while you won't even make past 3 years or less before you give up. You should always have some wiggle room where you can spend your money on things you don't really need but you just "want" them. To stay focused on the long term gains you should have a little fun, but not too much to not save anything :::

I haven't really talked about Tagesgeld or "Emergency" money, but it's the most important one, you build this one first before everything, this account is important if the stock or ETFs prices fall really hard because you can buy back cheap but actually the main purpose of this account is so you don't need to get your money out of the 3 other accounts before you even make some money if you really in the emergency

:::tip As you can see there are a lots of accounts you have to make but does that mean you really have to open 5 different account? the short answer is yes, but not always it really depends on how the laws work in your country, but it's better to diversify between 5 accounts. One bank won't give you the best in all 5 options you need in this case, and you won't need to search hours to find one with all 5 options just find 5 different but the best in their thing so you don't have to compromise
:::

Race Conditions!

Wed, 01 Oct 2025 00:00:00 GMT

Race Conditions

What are Race Conditions ?

Basically Race Conditions are Conditions where you webapp is out of the synchronization, so it if you would send a packet more then one time even 100s of times in a single second than you could exploit the website

Example

Websites where you can buy something always have a place to redeem your coupon codes of some kind. If the website doesn't apply rules to this feature we can exploit it and redeem a coupon code 100s of times in a single second and bypass the one time use feature so we can get something really cheap

:::caution This is off course highly illegal and I won't take responsibility, this is for education only and for websites that you allowed to test if they have this issue :::

Okay lets start this TryHackMe called Race Conditions

:::important You need to have premium to go through this box :::

The first 4 task should be self-explanatory so if you read them correctly you should answer them easy

Task 5

This is where it gets hard, you need to use either the attackbox for this task or your own machine with Burp Suite on it

First you need to open Burp Suite and go to the proxy tab there you can open the browser but don’t turn on intercept yet

go to the website and login into one of the accounts

You can turn now intercept on and send some money over the other account

now you should see a POST request in the proxy tab

you can know Ctrl+R or right click and send it to repeater but don’t turn intercept off

you can now make a group

and duplicate 20 times

if you are finished with that you can select send group (parallel) this is important! and send it

now you can turn intercept off and see the magic

you need to repeat the sending part (with intercept on) till you get 100$ in one account and log in to that account to get the flag

The flag :spoiler[THM{PHONE-RACE}]

we can now move on

Task 7

This task is the same as Task 5, but now you have 3 accounts but its basically identical

I put here the step-by-step guide with picture but first try it yourself and if you get stuck go through the pictures and see what you did wrong then try again alone

:::important Don’t forget to turn on intercept before you send the packets and only turn on intercept to get the POST packet first then turn it on again when you see the screen successful :::

The flag :spoiler[THM{BANK-RED-FLAG}]

How to Structure Code in Godot!

Tue, 30 Sep 2025 00:00:00 GMT

How to Structure Code in Godot?

Over the years I saw many tutorials how to build projects, like multiplayer projects, inventory systems, how to move your character 3D and 2D and so on...

After I started my first project in c++ it was easy to manage folders at first. Then because of time reasons + I am a single developer I moved to Godot because it still opensource, so I can later add or even remove or change things that I don't like or want to improve, but it was a disaster...

Everything was new. I was way faster than plain c++ with SDL2 but after a while I did find my self doing the same structure as in c++ and it didn't quiet worked the same, and I was using more and more coding than Nodes(Later you see what i mean by that) and even programmed things that Godot already had, so I clearly needed some structure in my code

But what could you done in that situation?

:::tip First note to yourself:
Always check if the engine is already providing a solution to your problem before you even start solving it!!! :::

What can you Structure?

In godot there are two main things you can structure the first one is Nodes, Nodes are the way Godot stores Objects with logic, and you can either use one or build one like your Player Node

The second thing which only comes up for medium size or bigger projects is your folder structure after I started my big 3D multiplayer shooter again in godot it got so messy that I couldn't find anything in my folders

I think they are two separate problems, so I solve them with two separate chapters

:::important I won't explain everything in detail because this should be self-explanatory this course is also meant to be for people who already familiar with Godot and Programming but cant really structure his/her code and because I didn't find anything online I made this for more advanced Godot Programmers but also not Professionals because they might know an even better solution :::

I will structure my explanation in notes so you can easily come back, and you don't need to read though 20 lines to find something specific

Solution to the Node Structure Problem

If you want to make trees like this

Game (Node)
└── World (Node3D)
    ├── Environment (WorldEnvironment)
    ├── Lighting (DirectionalLight3D)
    ├── GridMap (GridMap)
    └── Portals (Area3D)    # With this you can move between maps
|
└── Player (CharacterBody3D)
    ├── Mesh (MeshInstance3D)
    ├── Collision (CollisionShape3D)
    ├── Animations (AnimationPlayer)
    ├── CameraRig (Node3D)
    │   └── Camera3D
    ├── StateMachine (Node)
    │   └── States (Node)
    │       ├── Idle (Node)
    │       ├── Move (Node)
    │       └── Jump (Node)
    └── Inventory / Stats / etc. (Optional: Node/Node3D)
|
└── Enemies (Node3D)
    ├── Enemy_1 (CharacterBody3D)
    │   ├── Mesh (MeshInstance3D)
    │   ├── Collision (CollisionShape3D)
    │   ├── Animations (AnimationPlayer)
    │   └── StateMachine (Node)
    │       └── States (Node)
    │           ├── Attack (Node)
    │           ├── Search (Node)
    │           └── Idle (Node)
    ├── Enemy_2 (...)
    └── Spawner (Optional) (Node)
|
└── NPCs (Node)
    └── Villager_01 (CharacterBody3D or Node3D)
    ├── Dialogue (Node)
    └── InteractionArea (Area3D)
|
└── UI (CanvasLayer)
    ├── HUD (Control)
    ├── DialogueBox (Control)
    ├── InventoryUI (Control)
    ├── PauseMenu (Control)
    └── Quests (Control)
|
└── Audio (Node)
    ├── Music (AudioStreamPlayer)
    └── SFX (AudioStreamPlayer)

:::important A really important thing you see is that everything is a Node and that's a perfect practice which I can explain for hours, but you just need to think that everything you program could actually be a Node that you can put in your Game and use Godot signals to connect everything together which can help you to safely and easily manage your whole game! :::

:::note StateMachine: Where you define your Object into states like idle, move, jump

It's even better if you use multiple state machines for Movement, WeaponHandling or even one for interactions

CameraRig: It's better to put your Camera3D into a Node3D and apply code to that like shake, zoom, smooth movement and so on you can even put more cameras if you want to support third-person and first-person at the same time and switch between

It also helps when you want an AntiGunClipping to your Game where your weapon is a "picture" so in your view it won't go through walls! :::

For the Main Menu this is as simple as

MainMenu (Control)
├── Background (TextureRect)
├── TitleLabel (Label)
└── MenuContainer (VBoxContainer)
    ├── PlayButton (Button)
    ├── ContinueButton (Button)
    ├── SettingsButton (Button)
    └── QuitButton (Button)
|
└── SettingsMenu (Control)
    ├── Tabs (TabContainer)
    │   ├── AudioTab (Control)
    │   ├── VideoTab (Control)
    │   └── ControlsTab (Control)
    └── BackButton (Button)

here is no right or wrong you can customize it how you like, but the structure needs to remain readable and reasonable you can even add CreditsMenu or whatever you need to extend this

Solution to the folder Structure Problem

res://
├── MainMenu/
│   ├── MainMenu.tscn
│   ├── MainMenu.gd
│   ├── UI/
│   │   └── StartButton.tscn
│   └── Assets/
│       ├── Background.png
│       └── Music.ogg
├── Game/
│   ├── Game.tscn
│   ├── Game.gd
│   ├── World/
│   │   ├── World.tscn
│   │   ├── World.gd
│   │   ├── GridMap.tscn
│   │   └── Assets/
│   │       ├── TerrainTileset.tres
│   │       └── EnvironmentSky.tres
│   ├── Player/
│   │   ├── Player.tscn
│   │   ├── Player.gd
│   │   ├── States/
│   │   │   ├── Idle.gd
│   │   │   └── Move.gd
│   │   ├── Assets/
│   │   │   ├── PlayerMesh.glb
│   │   │   ├── PlayerTexture.png
│   │   │   ├── Run.anim
│   │   │   └── PlayerStats.tres
│   │   └── CameraRig.tscn
│   ├── Enemy/
│   │   ├── Enemy.tscn
│   │   ├── Enemy.gd
│   │   ├── States/
│   │   │   └── Attack.gd
│   │   └── Assets/
│   │       ├── EnemyMesh.glb
│   │       └── Sound_Attack.wav
│   ├── NPC/
│   │   ├── NPC.tscn
│   │   └── Dialogue.tres
│   └── UI/
│       ├── HUD.tscn
│       ├── HUD.gd
│       ├── InventoryUI.tscn
│       └── Assets/
│           └── Icons/
│               └── UITheme.tres
├── Common/
│   ├── UI/
│   │   ├── ButtonLarge.tscn
│   │   └── DialogBox.tscn
│   ├── Scripts/
│   │   ├── StateMachine.gd
│   │   ├── Health.gd
│   │   ├── SaveLoadSystem.gd
│   │   └── EventBus.gd
│   ├── Resources/
│   │   ├── GenericShader.tres
│   │   ├── Crosshair.png
│   │   └── BaseStats.tres
│   └── Extensions/
│       ├── VectorUtils.gd
│       └── MathHelpers.gd
├── Addons/
│   └── (Godot plugins)
└── Autoloads/
    ├── GameManager.gd
    ├── InputManager.gd
    └── Config.gd

:::note Autoloads: these are codes that are in the Globals menu in your Project settings(they can be accessed everywhere in you code)

Common: this is a folder where you put not Game specific things, these are mainly template codes that you can just import like Addons(plugins) to your next project later so you write it once and be there when you need them forever

Structure: the main structure is that you put everything related into one folder like your Player Scene(.tscn) and put logic and resources into subfolders for these scenes. If you have more than 1 script for your scene you could make a folder called scripts and put them in there :::

Full Futures Guide!

Mon, 29 Sep 2025 00:00:00 GMT

Futures Trading

Futures

Type

Mini
Micro (worth 1/10 of a Mini)
NQ 20 dollar per points
MNQ 2 dollar per points
:::note the M before MNQ means micro which is worth 1/10 of a Mini which is the normal one (NQ)! :::

Points

point value is the smallest whole number 1000->1001 move is 1 point move

Ticks

tick value is the smallest decimal number movement
NQ moves 0,25 decimal points minimum!
But ES moves 0,1 decimal points minimum!
1 NQ point is 4 NQ tick
1 ES point is 10 Es tick

:::caution you always need to know which one is in the current use when i place your stoploss and takeprofit, you make this mistake once and instead of 20 ticks stoploss you place a 20 points stoploss and bye bye mmy whole savings or funded account :::

Contracts

Contracts are multipliers to point or tick values, you can buy 3 * 20 dollar worth of "contracts"

Margin Requirements

Margin

intraday (market open)
overnight (market closed)

NinjaTrader

intraday 500 dollar per contract
overnight 2000 dollar per contract

:::warning every broker has a different intraday and overnight requirement, so always check that before you assume the above example :::

Requirement

if buying 3 contracts, you will need to set aside 1500 dollar with intraday margin on NinjaTrader, if you have 2000 dollar in the account you will have 500 dollar liquidity if you lose more than 500 dollar you will get a margin call, and you will be liquidated!

:::tip because of the information above I advise you to calculate how many points you can go down before a margin call sso remember the calculation below :::

Calculation

Calculate how many points you can lose before margin call
(Account Size - Contracts * Margin Each Contract) / (Contracts * Point Value)
(150.000-15×500)÷(15×20)=475Points

Positions

Position Worth

contract * point value or
contract * tick value
3 * 20 = 60 dollar for points in NQ
3 * 5 = 15 dollar for ticks in NQ

Win Calculation

contract * point value * point movement or
contract * tick value * tick movement
3 * 20 * 8 = 480 dollar for 8 point movement into profit on NQ
3 * 5 * 32 = 480 dollar for 32 tick movement into profit on NQ (8 point * 4 tick per point = 32 tick)

:::important I don't actually want you to calculate how much money can you make because then you could make unrealistic expectations to yourself and won't archive anything so this is just to remember but do not calculate everytime you win how much money could you made when... :::

:::note these notes are specific to MyFundedFutures, which is one of the best Futures trading firm what I know, but the first rules under "Funded Firms" are generally there on every Futures firms and only the last rule is MyFundedFutures specific which I marked as "MyFundedFutures Profitable Month Bonus" :::

Funded Firms

Consistency Rule

40% -> If a trader makes a total of 10.000 dollar in profit, no single profit can exceed 4,000 dollar (40% of $10,000)

Scaling

You can only scale by contracts, so if you scale, you are actually allowed to use more contracts to trade, but does not get more money

Subscription Model

You will need to pay a monthly fee for your funded account but only in the evaluation stage, once funded, you will not have to pay anymore

Reset after Fail

Once you have failed the account before renewal, then the account will automatically change your balance back to starting balance, sometimes you need to pay an additional fee for reset

Drawdown Modes

End of Day (EOD) drawdown refers to the maximum loss a trader can incur within a trading day, calculated at the end of the day based on the accounts balance.

Intraday drawdown Tracks the highest and lowest points of the account balance within the day, including unrealized gains and losses.

MyFundedFutures Profitable Month Bonus

If you close a month in profit and pay for the next month's subscription, you earn a valuable bonus—a free reset. This free reset can be used at any point in the future.

One Free Reset Limit: Account resets don't accumulate. You can have a maximum of one free reset available at any given time.