The most important and best decision I made was to use Java for the trading platform.
Another important decision was to drop the GUI. Command-line software only, unless there is a clear need for a GUI. A GUI is a time consuming, unnecessary complication in most cases when it comes to trading software. In my first year of trading system programming, I wasted a lot of time maintaining GUIs before I came to this realization.
Benefits realized from all of the above: I successfully have deployed trading applications to a Linode virtual server, without any problems, the very first day I tried. Furthermore, I was able to use the least-expensive package (512MB RAM) and I still have plenty of RAM available. The system has been up for 38 days straight.
I am also a certified C++ programmer. But I tell you what, I'm glad I didn't use C++ for the trading application. C++ gives you greater flexibility and speed, but it comes at a cost. Java is just right. If you are playing some sort of millisecond trading game, then I guess you are forced into C++.
As I look at the 3rd party Java libraries I'm using, there's not much. The most important is Mockito, for testing. There's also JodaTime for dates/times, Apache CLI to parse the command line, and JDOM, Jaxen to handle XML I/O.
Also, I think using XML for I/O was another fruitful decision. If you mention XML, some software developers (especially web developers) will jump and say "use JSON instead". I even talked to one who thought XML was only good for storing meta-data. The reason, I believe, is that most of them have only seen/used XML to send/receive messages. Well, of course JSON is better for THAT purpose.
If you want to know the real deal, read Rusty Herrold's books. XML is outstanding for data I/O to the trading program, especially when mated with Java. I also have a PostgreSQL database for storage, but I didn't want to require a trading program to have a database connection. It takes an XML input file, and it gives an XML output file. I can use a variety of readily available GUI editors to change the input, or just a text editor. Using DTDs, schema, schematron, et. al. the trading program is guaranteed to get a valid input file. Using XPath, I have other programs which get data from the XML output just like a database query.
On the research and analysis side, I tend to favor Python and Matplotlib. It's quick and easy to grab data from an XML file or database and plot up some multi-panel analysis. On the downside, packages and modules tend to be a little disorganized and troublesome compared to Java/Netbeans. I jump a lot between computers. When I clone a Python package onto another computer I tend to run into problems getting it to work at first. Namespace clashes, paths, and the like.
- Trading is a real-time, asynchronous task. Java has the built-in machinery to handle this kind of thing. I make heavy use of Executor services and concurrent memory objects such as ConcurrentLinkedQueue and ConcurrentHashMap.
- My build is automatic with the Netbeans IDE. I can tweak it when I need to.
- The same build runs an any computer, any OS.
- I can easily tweak the heap size from the command line.
- JConsole allows me to easily watch RAM and CPU usage in real-time.
Another important decision was to drop the GUI. Command-line software only, unless there is a clear need for a GUI. A GUI is a time consuming, unnecessary complication in most cases when it comes to trading software. In my first year of trading system programming, I wasted a lot of time maintaining GUIs before I came to this realization.
Benefits realized from all of the above: I successfully have deployed trading applications to a Linode virtual server, without any problems, the very first day I tried. Furthermore, I was able to use the least-expensive package (512MB RAM) and I still have plenty of RAM available. The system has been up for 38 days straight.
I am also a certified C++ programmer. But I tell you what, I'm glad I didn't use C++ for the trading application. C++ gives you greater flexibility and speed, but it comes at a cost. Java is just right. If you are playing some sort of millisecond trading game, then I guess you are forced into C++.
As I look at the 3rd party Java libraries I'm using, there's not much. The most important is Mockito, for testing. There's also JodaTime for dates/times, Apache CLI to parse the command line, and JDOM, Jaxen to handle XML I/O.
Also, I think using XML for I/O was another fruitful decision. If you mention XML, some software developers (especially web developers) will jump and say "use JSON instead". I even talked to one who thought XML was only good for storing meta-data. The reason, I believe, is that most of them have only seen/used XML to send/receive messages. Well, of course JSON is better for THAT purpose.
If you want to know the real deal, read Rusty Herrold's books. XML is outstanding for data I/O to the trading program, especially when mated with Java. I also have a PostgreSQL database for storage, but I didn't want to require a trading program to have a database connection. It takes an XML input file, and it gives an XML output file. I can use a variety of readily available GUI editors to change the input, or just a text editor. Using DTDs, schema, schematron, et. al. the trading program is guaranteed to get a valid input file. Using XPath, I have other programs which get data from the XML output just like a database query.
On the research and analysis side, I tend to favor Python and Matplotlib. It's quick and easy to grab data from an XML file or database and plot up some multi-panel analysis. On the downside, packages and modules tend to be a little disorganized and troublesome compared to Java/Netbeans. I jump a lot between computers. When I clone a Python package onto another computer I tend to run into problems getting it to work at first. Namespace clashes, paths, and the like.
