It appears that the redis in memory database is causing a memory leak due to jobs not being deleted after they finish running in the queue. Will need to update the code sometime soon to resolve this issue, though it is not a big priority.

Zipline uses IEX API to fetch benchmark data for SP 500. Unfortunately since June 15 this API was deprecated. Thus running any algorithm, including the simple validation algorithm will fail without recovery.

Possible fixes include caching a version of the benchmark data locally instead of performing API call. Else, modify the code to get benchmark data from another source, like yahoo.

Either way would require modifying Zipline API source code which is not the best solution.

• There needs to be a way to validate whether we have certain stock ticker symbols in the database.
• Currently if a symbol is not found, the API will throw an error.
• There should be a dedicated endpoint to validate if an entered ticker is in our database or not.

• doesn't seem to be an issue when running locally
• random forest regression seems to run fine.
• on heroku, choosing to run regimes while selecting the random forest classifier for periods around 6 months or more seems to cause the job to fail sometimes. The confusing part is that sometimes it works and sometimes it doesn't, even when the simulation params remains the same.
• this suggests its possibly a redis issue?
• will investigate further, and if I can figure out what the heck is going on I'll document it here.

When deploying to heroku, the backend breaks because all of the APIs require matplotlib, which by default uses tkinter. However, the linux ver of python does not include this package.

My name is Luis, I'm a big-data machine-learning developer, I'm a fan of your work, and I usually check your updates.

I was afraid that my savings would be eaten by inflation. I have created a powerful tool that based on past technical patterns (volatility, moving averages, statistics, trends, candlesticks, support and resistance, stock index indicators).
All the ones you know (RSI, MACD, STOCH, Bolinger Bands, SMA, DEMARK, Japanese candlesticks, ichimoku, fibonacci, williansR, balance of power, murrey math, etc) and more than 200 others.

The tool creates prediction models of correct trading points (buy signal and sell signal, every stock is good traded in time and direction).
For this I have used big data tools like pandas python, stock market libraries like: tablib, TAcharts ,pandas_ta... For data collection and calculation.
And powerful machine-learning libraries such as: Sklearn.RandomForest , Sklearn.GradientBoosting, XGBoost, Google TensorFlow and Google TensorFlow LSTM.

With the models trained with the selection of the best technical indicators, the tool is able to predict trading points (where to buy, where to sell) and send real-time alerts to Telegram or Mail. The points are calculated based on the learning of the correct trading points of the last 2 years (including the change to bear market after the rate hike).

I think it could be useful to you, to improve, I would like to share it with you, and if you are interested in improving and collaborating I am also willing, and if not file it in the box.

In RSI, the line

throws a ValueError exception because the price may not be well defined. This is also one of the reasons why the API fails in between 2017-2018 because some prices may not be defined by the Quandl WIKI dataset.

It's become clear that with the newest introduction of the RSI Divergence Strategy in #33 that the current synchronous implementation of the logging tends to use too much resources.

The proposed solution is to rewrite the server to be async. Also, the number of repetitive logs for RSI could be cleaned up as well.

The API reponses currently return the date as a MATLAB serialized date, for example, 730990.

It is needed for graphing that the date be in UTC, so that it is easier to create the JavaScript Date object.

When an API is called it appears that the result is saved into the pyplot object as a figure, but when the API is called again, the new figure becomes appended to the old figure. The expected behaviour should be that a completely new set of plots and figures are generated, with the old ones being deleted once the API finishes responding.

Many of the APIs require longer than 30s to complete. However, heroku will kill the connection after 30s (even though the websocket continues to be pushed). Thus it will be necessary to learn how to fix this issue either through websockets or through some type of background queuing system.