Python, ZMQ pub/sub sockets, C++ ZMQ brokers, InfluxDB, and Discord for alerting.
Started as a threaded monolith and re-wrote it as small single-threaded/tasked services.
Network latency dominates language speed, so Python is fine. ZMQ brokers are in C++ for speed.
Discord is convenient and reliable.
Not attached to any tech (opposite of attached to Python).
My research environment:
R, PyCharm. Data pulled from db or directly from R (REST query, CSV, RData).
Considered adopting a reporting/notebook tool like Jupyter, but haven't had strong need yet.
It's necessary to keep a research environment clean in the same way and for the same reasons a software project should be. Analysis can easily become a mess, given multiple data sources, avenues of exploration, ideas, distractions, simultaneous projects, crowded folders, etc.
Maintain version control, quality organization and code, high cohesiveness, and low coupling.
Try to do everything right the first time.
Do analysis in reproducible steps.
Don't write off-the-cuff code or neglect processes; it will cost you time in the long run.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It's tempting to use common models using price and volume (including technical analysis) on highly analyzed and very liquid markets, like the S&P. But, why would you expect to consistently make money with MA crossovers on E-Minis?
👇
You need something more than a simple system, given that these assets are highly watched and very accessible.
You can invest in more data and complicated models, but now you have to deal with: overfitting, competition with smarter more resourceful people, wasted time and money.
The good news is you don't have to solve these problems — you can find your edges in less frequently analyzed and relatively illiquid (but liquid enough for you) markets.