Price Feed Success

Success! I have implemented a proper notification failure system as well as solved the disconnection issues I have been having with my price feed. It seems my request was a bit malformed, and overall everything is running much snappier now. I am retaining the idea of a backup fail-over feed "just in case" it is needed, and the coding is done on that as well. However, I did shy away from having automatic fail-over, so for now, this will be a manual thing if needed. I hope the days of endless disconnections are gone now.

Updating the trading framework

It's been some time since I spoke about the engine behind the robots and strategies I trade. I had a wonderful coding marathon last weekend the result of which is many new improvements in the trading framework I am using. Although I solved several issues and cleaned up many things, there remains a piece I haven't quite been able to clean up.

I have the dilemma of writing code that is clean and maintainable, while having client side strategies that are really one-off programs. The server side backend pieces are abstracted away and objectified nicely, but that doesn't help with the client side implementations. Simply stated, I have a template I wish to use for all new strategies. This is easy to do. The trouble comes when I update the template (fixing a bug, adding new cool stuff, etc), the strategies of course don't get this update without me manually merging it across. This is not scalable as the number of strategies grows. The trouble with creating a generic class and having each strategy extend it is that each strategy has unique pieces and I don't believe I can abstract anymore pieces away. This is of course despite the fact each has a common workflow. Creating a generic client class is the answer (unless a programmer out there can shed some light). Regardless this is a wall that is slowing progress on new trading ideas.

Of Backtesting

The joys of backtesting. In my last post I described the framework I am utilizing for autotrading. Once the strategy is coded inside the framework, I can choose to run it in live mode, or I can choose to run it thru previous price quotes in order to get a historical perspective on it's performance. This is helpful to reveal bugs more than anything else. People will often "tweak" there strategies in order to gain good backwards testing performance. Unfortunately, this is also how many are scammed with the inevitable forex bots, and pretty graphs showing beautiful equity curves. Suffice to say, tweaking for the past is an exercise in futility, and borders on dangerous. While it is enjoyable to see a strategy perform on an unknown dataset, I have successfully run robots that don't backtest well. The reason of course is that the past is different from the future; which is of course different from today. The only thing that matters is how the robot is performing now, in realtime.

That's not to say backtesting has no place. As I said, it helps to reveal bugs, and can identify or disprove your thesis on the core of the strategy. For example, if I code a trend following system, I would want to backtest it on a dataset containing trends. This will help me to see if my idea on how to idenitfy a trend is correct (and correctly coded). The performance of the robot on this dataset is a secondary indicator, but again is most useful for determining proper code. If a robot wipes the account of otherwise experiences severe drawdown my strategy doesn't call for, it usually means there is a bug somewhere. Typically you can no more always be wrong, than always be right. Either one is a cause for investigation. Or you found the grail. Heh. My money is on a bug!

Of Frameworks

When one considers how to approach trading there are alot of upfront choices to be made. Which market to trade? Shall I trade or have someone or something do it for me? What philosophy or strategy will I employ with trading -- aka what edge am I seeking to profit on? My goal is to use fundamental and technical analysis to determine where edges may lie and attempt to profit from them. Since I am human, I am delegating the grunt execution to a machine, and instead employing my time to analysis. This is otherwise known as autotrading.

While there are many packages of there to support such endeavors, I have written my own framework to accomplish this. In a nutshell, I have separated out the execution layer, data layer and logic layers of a trading program. The execution layer takes care of the communication and physical trade execution at my broker. The data layer is separated out to render feeds of price and other information for use by any particular strategy I am running. Finally the logic layer is separated out into individual strategies running within the framework.

It sounds much more complicated than it really is. But having this proper framework allows me to code strategies easily; and then run them thru backtesting or live mode. I suppose I would be remiss if I didn't also mention I did this all in PERL.

Of Systems

Creating a trading strategy isn't something to be taken lightly. It's important to remember we're running a business here. For practical purposes, I'm going to codify my thoughts on trading into trading robots. I have several in various stages of development. The concept behind having multiple robots is simply to target and profit from several different trading environments. Running them concurrently should in theory allow me to profit in any environment. Hehe. Any known environment ₁.

1. You don't know what you don't know -- hence I cannot trade the unknown. But, if Nassim Taleb has shown anything, I can profit from it.