Diego Ringleb’s Post

Do your backtests lie to you? I tested the same strategy using: - Revised data - Point-in-time data Same model. Same logic. Different results. The reason? Lookahead bias. Using revised data gives your model access to information that wasn’t available at the time, making performance look better than it really is. If you want backtests you can trust: 👉 Use point-in-time data 👉 Replicate the real information set Less impressive results — but far more reliable. Comment “Python” to receive the full script 👇 #quant #finance #backtesting #python #macrobond

Great job Karl Philip Nilsson! This is one of those things that looks small but isn’t. We see a lot of really slick Python workflows that fall apart once you strip out revised data. Being able to pull proper vintages through an API is what turns a nice backtest into something you can actually rely on.

Look ahead bias is a common issue for backtests. Maybe even more so for macro models. Point-in-time data is crucial for accurate modeling. This is why Karl Philip Nilsson built a backtesting model in python to showcase that the proof is in the pudding.

I’m checking this out. As we need to select the “best” platform for our genAI applications, the permutations become truly daunting. Adrian provides a framework and code to do so - scoring and promoting the highest rated candidates. Fascinating!

Spent some time recently improving test stability in a small Python project. What looked like “random failures” at first turned out to be a mix of: - leftover state between runs - timing issues - and assumptions that were true locally but not always in CI Nothing unusual — but a good reminder how fragile systems can become when small things accumulate. The interesting part wasn’t fixing individual tests, but understanding *why* the system behaved differently depending on the context. In the end, the most valuable changes were: - making state explicit instead of implicit - isolating test cases properly - and improving observability (logs > guesswork) Not a big project, but a good example of how reliability issues are often less about tools and more about system behavior. Curious how others approach this — do you treat flaky tests as isolated problems, or as signals of deeper issues?

Two months in, and FlameIQ is starting to find its place. FlameIQ is an open-source, CI-native performance regression engine for Python — built to make performance a first-class signal in your pipeline, not an afterthought. In that time, the focus has stayed simple: • Catch regressions before they reach production • Make performance checks enforceable in CI • Keep everything deterministic and reproducible FlameIQ also supports statistical significance testing (Mann-Whitney U) and generates self-contained HTML reports for easy inspection. If you're already treating correctness and tests as non-negotiable, performance should sit right alongside them. 📦 pip install flameiq-core 🔗 https://lnkd.in/d-2KcKFd 🔗 https://lnkd.in/d6e2D7mq 🔗 https://lnkd.in/d2VDWRQa Always open to feedback and contributions. #Python #OpenSource #Performance #DevTools #CI #SoftwareEngineering

Two months of FlameIQ in the wild 🔥 What we’re seeing is clear: teams don’t want more dashboards — they want performance checks that actually block regressions before code ships. That’s exactly where FlameIQ fits 👇 👇 ⚡ CI-native performance regression detection 📉 Catch latency issues before production 📊 Built-in statistical validation (Mann-Whitney U) 📄 Clean, self-contained HTML reports Performance isn’t something to “monitor later” — it belongs in your CI pipeline. FlameIQ is built for that shift.

I built a pricing scraper on n8n that hits 100+ regions and pushes everything into Notion. Ran it on Railway for months. Loved it. Then I looked at the bill. Turns out processing thousands of rows per run adds up fast on these platforms. So I rewrote the whole thing in Python. Now it runs on my machine for free. The funny part is that n8n is what taught me enough about APIs and data flows to eventually not need it. Which makes me wonder how many people are running automations that would be cheaper as a script they just haven't gotten around to writing yet...

#MorningReflections I revisited an old codebase and realized I had built a CLI I didn’t even remember. As part of my internal tooling process, argparse makes creating functional CLIs almost automagical—you set options, and it handles the heavy lifting. Don’t be a fool like me, always keep learning. 😂 #Python #InternalTools #CLIDevelopment

Backtesting is a safe dream. Live trading is a messy reality. Going live, the most challenging aspect of algo trading, involves crossing the “last mile.” I have compiled a guide on how you can deploy an algo using Python and Oanda without spending too much money. Your strategy should not be confined within a Jupyter Notebook anymore.