Researching the topic – Part 2

Previously I wrote about some basic assumptions and first use cases that could be distinguished in my project for the DSP2017. Today I will dive deeper into the topic and cover the quotation sheet for company-level information as well as types of commissions along with additional conditions that might come in handy to the investors. As a reminder, I’m using a book called “Giełda – podstawy inwestowania” by Adam Zaremba as a source. Let’s continue with the research.

To compliment the commission sheet, the user should have access to a quotation sheet which will store information about a company present on the stock market. This sheet should contain data such as:

  • Company name
  • Opening reference rate
  • Opening rate
  • A partial commission sheet
  • Current rate
  • Volume of the last transaction
  • Stock value change (percentage)
  • Time of the last transaction
  • Volume of the traded stocks
  • Value of the traded stocks

Apart from being a list of use cases, this is a great indication of what the model of a company within the simulator will look like. Some of these points require additional description. Opening reference rate is the price at which the last trade was made during the last day, it may also be called the closing rate”. The opening rate is the price set before a session begins. This might be confusing – “if the closing rate is price of the last trade, then when was this opening rate set?” – the issue is connected to the quotation system itself and what happens between the sessions. We will discuss this a little later. The partial commission sheet is pretty straightforward, to keep things simple it will keep information about the top row from the main sheet. The current rate is the price of the last trade that has completed. Based on that the stock value change is calculated. We also have data such as the time and volume (number of stocks traded) that the last transaction completed. The last two elements hold information about the overall volume and value of every trade completed during current session.

This is something that we can start working with! We have all the elements that should be modeled in the simulator, to achieve a believable representation of a company. But there is no market without some actual trading. This is how we come to the commission types.

There are two basic categories that the commissions fall into: with and without price limit. If the user would wish to order the first type of commission, he would need to set the specific price, for which he wishes to sell, or buy shares. The trade is completed only if there is a corresponding offer for this very price. It is pretty intuitive and should be the basic commission type implemented in the simulator. There are two additional rules when comes to this method. First one is the priority of price, which means that an offer more advantegous to the other party will be realized earlier. The second rule is the priority of time. Simply put, between two offers that are equal in price, the one that was made earlier, will also be chosen earlier.

Commission without price limit can be distinguished into three sub-types: for any price, for the current rate and for the opening rate. The first one is a brutal buy/sell commission that disregards the prices, it goes through the commission sheet from the top and executes every offer until it satisfies the amount that was specified by the user. That means there might be more than one rate for such a commission, which happens if the first order on the sheet has a volume that doesn’t meet the requirement. Commission for the current rate limits this. It will complete only the first item on the sheet and it will create a new order, at this very price, to compliment the difference in volume. The last type which is based on the opening rate is more complex, as it branches out even further. Therefore I will postpone it’s implementation.

The user now has three different ways to acquire and sell stocks. But, to add some flavour and extend the possible strategies, I need to consider the additional conditions. Following the golden rule, of making it realistically simple, I will limit myself to a single one: activation limit.

Activation limit introduces a new concept, the commissions can be inactive, which means they can be issued by the user, but they’re not automatically part of the commission sheet. When user sets the activation limit, he should pass two variables: the activation value and the price. The first one corresponds to the current rate, if it achieves this level, the commission activates and is transfered to the sheet with the price determined by the second variable. This is called a stop limit” variant. There is also a “stop loss” variant which activates when the current rate drops to match the limit. This causes a sell for any price commission to fire and is a quick bail-out mechanic.

Now it’s finally coming together. With this much data I think it’s possible to finally start the implementation, at least to a certain degree. So please stay tuned for the second technical-oriented post. As always, thank You for reading and until next time!

Advertisements

Researching the topic – Part 1

Last time I posted about a purely technical task of setting up the server. The task itself is pretty generic and can be done independently of the project’s topic. Before I progress any further a proper research has to be done, especially considering the nature of the project. To get a somewhat accurate simulation of the stock market, It’s necessary to understand how the real one works. What I knew beforehand, is that it’s a vast concept, that people study and practice for years, until they feel comfortable with it. So the task is to choose a small part of it and simplify it further, while still remaining true to the core idea. Based on that, I will describe the use cases of my project, as well as design assumptions. Also, it will help to get a better understanding on what, and how, I’m supposed to model. So, let’s dive in.

As my literature entry-point I’m using a book “Giełda – Podstawy inwestowania” by Adam Zaremba. Unfortunately, to my knowledge, there is no english version of it. It’s a quick introduction to the world of stock exchange and other elements that come with it. It’s also written from a practical point of view, designed for people that want to learn how to invest their money. This is especially interesting for me, as my project is aimed at exactly the same group of people.

The book starts with describing the broker’s role in the investment process. At the very beginning, broker’s job was to execute transactions commisioned by the client. Nowadays, it provides additional insight based on professional analysis of the market supported by advanced tools. To make it simple from project’s structure point of view, yet educational, the simulator should be able to take in the transaction orders directly from the user (use case), without the need of an artificial broker office. We’ve got our first use case right here, each next use-case or assumption,  will also be highlighted in the same way. Furthermore, at this point, no supporting, analytical tools are to be provided (assumption), however the architecture should allow for an easy introduction of such in the future. This is dictated strictly by the resources and time I have for this project (which is just me, working on it after office hours).

Further analysis of the stock market indicates, that there are more instruments that are being traded, than just the stocks themselves. For instance we have bonds and so called “derivative instruments”. To keep the project simpler, the simulated stock market will allow only for the stock trading (assumption).

Now, how will the process of commissioning the orders look like? I will follow the most popular way (as stated in the literature I’m using). Firstly, the user should be able to decide the company, number of shares he wants to buy/sell and the price, for which he wishes to achieve that (use case). Once the user commissions the order it gets transferred to a commission sheet. It’s structure looks like this:

# of buyers | # of shares to buy| Purch. price | Sell. price | # of shares to sell | # of sellers

So a model of this sheet in the simulator will have to hold information, such as:

  • Purchase price, for which the user wants to buy certain shares,
  • Number of other buyers, which also offer the same amount of money for the share,
  • Combined number of shares that those users want to buy,
  • Selling price, for which the current holders want to sell the shares,
  • Number of sellers that offer such price,
  • Combined number of shares that are meant to be sold.

Additionaly the list should be sorted by the difference of the purchase and selling price (use case). Offers that are closest to being executed (difference is the smallest) should be on top.

I think that’s about it for the first part of the research. The project is starting to clarify, but it’s just the tip of an iceberg. Thank You for Your time and until next time!

Starting up with the server

Kicking off a project can be pretty tedious, especially when it’s a technology You’ve never used before. Getting to know the project’s foundations and the tools You will be working with in detail is fundamental. If you don’t feel comfortable with the fresh configuration it’s easy to get lost when the project increases in volume. So let’s start with the basics.

First, the text editor. My choice is the open-source Atom editor. It’s not focused on any specific technology, rather, through a vast selection of plugins You can set it up to improve Your workflow. For this project I’ve chosen Ensime, which provides Scala support, as well as atom-typescript respectively for the TypeScript language.

When it comes to the server application it was necessary to download and install the sbt which is a build tool for Scala. For the record, Scala operates on the JVM (Java Virtual Machine), so if You want to play around with it, You will need the JDK (Java Development Kit) for it to work. There also exists a more extensive build tool called Lightbend Activator provides a set of project templates to help You kick off. However for the education’s sake I decided to start from scratch.

As I’m building a web application pure Scala language won’t be enough for the job. To build my web API I will use the Play framework. However, to include it in my project I don’t have to download it manually. Instead we will start writing some configuration for our project.

In the main directory I created a build.sbt file, which will contain configuration for the sbt.


lazy val root = (project in file("."))
 .enablePlugins(PlayScala)
 .settings(
 name := "invest-sim",
 scalaVersion := "2.11.7"
 )

 

This is how a project root is defined. Sbt is told that this project resides in current directory of the build.sbt. After that Play framework is registered and additional settings are declared. Sbt also expects that a directory project is to be present in the project’s directory. Inside it I created two files: build.properties and plugins.sbt. The first one is rather minimalistic at this moment, it only contains the definition of the version of sbt that I am going to use:

sbt.version=0.13.13

plugins.sbt on the other hand has information that are necessary if Play framework is to be included in the project.


//Typesafe repo
 resolvers += "Typesafe repository" at "https://repo.typesafe.com/typesafe/maven-releases/"
 // The Play plugin
 addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.5.12")

// web plugins

addSbtPlugin("com.typesafe.sbt" % "sbt-coffeescript" % "1.0.0")

addSbtPlugin("com.typesafe.sbt" % "sbt-less" % "1.1.0")

addSbtPlugin("com.typesafe.sbt" % "sbt-jshint" % "1.0.4")

addSbtPlugin("com.typesafe.sbt" % "sbt-rjs" % "1.0.8")

addSbtPlugin("com.typesafe.sbt" % "sbt-digest" % "1.1.1")

addSbtPlugin("com.typesafe.sbt" % "sbt-mocha" % "1.1.0")

addSbtPlugin("org.irundaia.sbt" % "sbt-sassify" % "1.4.6")

It’s time to setup the server itself. Firstly, I need to create a directory conf in the project’s main directory. Inside it I will put two files: application.conf and routes. The first one contains configuration required by Play, but it can remain empty for now (It has to be created though, Play will throw an exception if it can’t find it). Routes will be where we will define our REST API. The first route to be implemented into the app should be the main one.

GET                 /               controllers.Application.index

In Play every route is configured by three elements in a line. First one is the HTTP method of the request that will be processed. Second part is the URI  and the last part indicates which function will be used to process the request. Now I need to declare it. I created a new directory called app which will contain all the *.scala files used by the server. Then a subdirectory called controllers contains the first Scala file in the project: MainController.scala:

package controllers

import play.api.mvc._

class Application extends Controller {
 def index = Action{
 Ok("Get Noticed!")
   } 
 }

As You can see it’s not much, but hey, Rome wasn’t built in a day. So firstly, to keep things tidy, I declare a package named controllers. The play API has to be imported and I declare a class Application. It must inherit from the Controller class provided by Play. Finally I define the function index. Functions that are supposed to be available from the API level need to return an Action object. This is the simplest way to construct such an object, where I declare only the expression needed for the Action. I don’t need to pass any information about the incoming request in this example. Based on all this, we can see how the last part of the API route has been constructed. We have the package part (controllers), class (Application) and the function identifier (index).

Having implemented all of this, I can finally start my server.

sbt

As You can see the server is up and running on port 9000. Let’s try accessing the main route.

first-run

And there we have it. I constructed my first Scala web app. I hope this proves to be at least a little educational to anyone reading. Thank You very much for Your time and until next time.

Get Noticed!

dsp2017-3@2xHello Everyone!

I am very pleased to say this “hello” as it is quite special for me. That’s because writing a blog post is a brand new experience. Also the reason for doing that is filled with things to discover and learn (at least from my point of view).

The origin of this blog is directly connected to a programming contest “Get Noticed!” (Yup, just like in the title). Main goal is to publish my progress in a project that I enlisted with, however, I hope I will expand it even further beyond that and into an interesting point on the map of IT community.

As for the project itself. The idea is to create an investing simulator (Git repo here) based on a virtual stock market. I always had this curiosity for economy and business topics in the back of my head, but I never got around to actually pursue them more in-depth. So now I am glad to do so, as it will be necessary to create a proper simulation model of a live stock market.

The technologies I’ve chosen to implement the project will be a challenge for me as well. Even though I’ve a little over a year of professional experience in web development as a full stack developer I decided to step outside my comfort zone when it comes to languages and frameworks (mostly!). Recently, I’ve picked up interested in functional programming, but didn’t really code anything substantial. So I said to myself – Why not? – and chose Scala for the server application. What about the Frontend? Here’s the “mostly” part coming in. Professionaly I work in Angular 1.x and for this project I stayed with Google and chose Angular 2. Additionaly, instead of the classic JavaScript I will be using the TypeScript superset.

So a lot of new things, which means quite a big challenge. I will probably flop along the road numerous times, but hey – maybe I will learn something. Please keep Your fingers crossed for me and until next time!