Interesting comparison on HFT server optimizations, chipset, RAM etc. Old, but probably still relevant: http://www.enterprisetech.com/2013/12/05/supermicro-revs-low-latency-hft-servers/
Potentially a good replacement for Sqlite LiteDB - A .NET NoSQL Document Store in a single data file http://www.codeproject.com/Articles/869219/LiteDB-A-NET-NoSQL-Document-Store-in-a-single-data Soon, I will be unforgiving for other peoples' assemblies and even windows programs that are not dotNet Core compliant. My own stuff is not, but I am making a huge effort to refactor to it. Native is also critical, but that is going to be slower going. https://dotnet.github.io/ Anything that allows me to run my stuff on Linux is a huge win. I straddle the institutional and retail world, and much of the retail world (e.g., API) is Windows only.
Ernie Chan reiterated in his blog and his book what he thought was a very wise saying: "You're not going to backtest your way into being a trader". While I could not begin to countenance Mr. Chan's Algo chops, it seems to be one of those sayings that holds up over time.
That's probably accurate, but I have to think about it if it would always be true. My guess is that an extremely sophisticated scientist could. For example, RenTech people almost certainly did what Chan is suggesting is not possible. For 99,999 out of 100,000 "traders" though, Chan statement is probably true. It is certainly not true for me. I wager that [one of] my system(s) is probably the only one like it in the world. However,I would not be surprised if ideas from it are in RenTech systems. I did not backtest into it though. So I don't know what my classification is.
To any quant, understanding Q-Q plots and their use in relation to CDFs are very important. http://onlinestatbook.com/2/advanced_graphs/q-q_plots.html
C# 7 will have Pattern Matching and Immutable objects. Worth reading if you program in C#: https://news.ycombinator.com/item?id=11961683
Ponderous to get started, still worth watching. The problem with these people is they start from the languge and proceed to the problem. This is upside-down. Start from the problem and show how FP solves the problems. If you are really clever, you can do it incrementally and weave in and out of language/problem. There is no question in my mind, zero, that while for many parts of the trading infrastructure OO is the right paradigm, it is definitely the wrong paradigm for the trading algorithm itself. Functional (Reactive) Programming is the correct way there. My ideal environment would be C++/17 with "Pure Functional C++/17" in an environment where mixed programming in both was super easy. C# and F# sort of get there, but they are MSIL languages. I want native.