This article is written for the intermediate F# audience who has a basic familiarity of stock trading and technical analysis, and is intended to show the basics of implementing a backtesting system in F#.
If you’re an F# beginner it may not take too long for you to get up to speed on the concepts if you check out a few resources. In particular:
The backtesting strategy which you will implement is a simple SMA crossover where the fast line is 10 bars and the slow one 25. When the fast line crosses above the slow line, a buy signal will be triggered, and when the fast line cross below the slow line, a sell signal will be triggered. Only one long position will exist at any time, so the system will not trigger another buy order until after the long position is sold.
When you are maintaining multiple web apps across environments it can be difficult to keep track of which scripts need to be run to upgrade the database when it comes time to deploy. If you’re maintaining different versions of web apps across environments when the versions can sometimes be significantly out of sync, the difficulty of determining which update scripts need to be run on deployment can explode.
While there are a ton of approaches to keeping your database under version control, if you want something simple and effective that you can implement with minimal time and effort, consider a DatabaseVersionHistory table in your database.
A database version history table will allow you to see at a glance the state the database is in and by comparing it with the update scripts in source control, you will quickly be able to determine which update scripts need to be run.
When should a small team be using an issue tracker such as JIRA?
A young startup may initially get away just fine by working informally and by email, and early in the project you’ll want to have as little administrative burden as possible, however as a project and team matures, there will come a time when having a searchable, persistent audit history of business decisions, fixes (and why they were done) and completed tasks will become invaluable.
Why would I want to use Mercurial or any other DVCS client with a Subversion repository?
It lets us keep SVN as our central repository
Some team members prefer not to use a DVCS for whatever reason so it lets them carry on using SVN without interruption.
It allows me to work and commit changes (but not push!), search history and switch between branches completely disconnected. I can continue to work during network outages or while traveling when I don’t have connectivity.
You get full, fast history search.
Switching between branches is easy and fast.
Any automated processes which use SVN (i.e. automated builds and deployments) can continue to operate while everyone moves to DVCS.
It’s much easier to perform merges than regular SVN (via export/import patch queues – which I detail later)