My strategy has been slowly evolving, and now I have about 7000 lines of code running in Ninja. (Actual trading logic is probably only 1000-2000 lines... a lot of other performance tracking, logging stuff in the background.)
I like Ninja's data handling, and I like using Ninja for backtesting.
The one thing I really don't like, is being "stuck" to Ninja's order handling. It means I'm stuck to Ninja's small set of broker adapters. I'm also looking to implement options trading, which isn't supported within Ninja.
So, I've been looking into converting over into QuickFIX. The obvious solution would be to build a class which basically implements all of Ninja's order functions (EnterLong(), ExitLong()), and order events (OnOrderUpdate(), OnExecution())... using QuickFIX.
I just didn't want to duplicate anyone else's work, if it's already been done. Any previous experience out there?
Thanks in advance!
The following user says Thank You to heech for this post:
Stay tuned! I've had ups and downs, but am slowly making fundamental improvements (like selecting better instruments to focus on). Since June, I've had 4 consecutive up months (but did have some intra-month drawdown)... talk to me in 20 years, and I'll let you know how I did.
As far as autotrading, it's usually working very well. But to make this work I'm tracking all of my positions independent of Ninja... I have my own Order objects, track my own fills, etc, etc. Now, I basically leave Ninja with my strategy running 6 days a week, 24 hours a day. I shut it all down Friday night, reboot my machine, and then relaunch Sunday afternoon.
That said, there's at least one latent bug that I haven't been able to resolve... when I have two different strategies placing orders on the same instrument at almost exactly the same time (same bar), I believe there's a race condition in Ninja 6.5. The *quantity* of the orders may become wrong... I believe the quantity requested by the second order call some how overrides the quantity requested by my code in the first call. It's pretty hard to replicate, but I've seen the bug 3 times in the last month, so I'm pretty sure it's real. I'm just hoping Ninja 7 gets rid of it.
The "why" should be pretty obvious. I mean, it's strategy specific, so I won't get into it in too much detail... but I'll just say, it's profitable to have both.
The alternative way of implementing this (and it would save commissions) is putting another layer on top of the Ninja order code, and some how "sum up" the short/long orders to come up with some kind of a net position... and then place orders accordingly. That might work, but it really complicates the logic for what I'm doing in terms of tracking individual positions/fills. I prefer to think of these as independent positions, even though they're on top of the same instrument.
With a simple strategy (i.e. sell if some oscillator > 80, buy if < 20) there can be no disagreement between the long & short sides so you can easily put both in one strategy.
If things are more complex, and it's possible for both the long and short sides to want to be in a position at the same time, it can make more sense to separate the strategies for a couple of reasons.
1) It's simpler to code and test the long and short strategies separately. If both strategies want to have positions, logically it makes sense to be flat, and wait until only one strategy holds a position. This is exactly what you get if your platform allows you to be long and short at the same time, and it doesn't cost extra in commissions unless both strategies fire at the same time (i.e. closing positions at the end of the day). Total system performance is simply the sum of the long & short system performances.
2) The resulting system can be much more stable. If you put both long & short sides in a single strategy and let one "win" (i.e. whichever triggers first will block the other), then small variations in inputs can cause large variations in performance. In that case, total system performance is unpredictable and is certainly NOT the sum of the long & short system performances.