A protocol for quant funds and researchers to work together without revealing their IP.

<aside> 👉 Just a few tips & examples to make life easier when it comes time to schedule the scripts that send your live features into Judge Research’s API.

</aside>

Introduction

Cron jobs are everywhere because they are super easy. Still, the Judge Research SDK comes with a function - live_fcs: live fetch, calculate, submit - that live-sends your feature three times:

1. A bit early: so you know you’ll never send your feature(s) in too late.
2. Just under the wire: the best balance between almost-never sending it too late, and incorporating all of the discrete time period’s data.
3. As close as possible: Optimal for data but so close it might sometimes miss.

It is simple enough but slightly idiosyncratic. More importantly, errors in handling your live submissions will likely be silent errors that introduce bias and/or noise into your live features. So, we thought it prudent to over-document this topic.

Even if you are not going to use live_fcs or our SDK in general, you might want to quickly review the below so you can don’t make any errors on the last step.

Starting Off

If you have to set up cron for the first time on a server:

sudo service crond start
crontab -e

• If you are not familiar with cron jobs, this short intro is pretty much all you need to know.
• If that is the case, you might find this VIM editor cheat sheet useful while editing your cron jobs.

Keep In Mind

• Once you have made the first submission of historical data, you cannot resubmit it
• Missing data will penalize your feature;
• Missing more than 5% after a couple weeks will remove your feature from consideration
• A submissions at the turn of a discrete time period is too late. For example, 11:59 59 is cool, 12am is not.