F# and SignalR Stock Ticker: Part 2

Following up on my prior post found here about using F# to write the Stock Ticker example found on SignalR’s website, I went to implement the heart of the application – the stock ticker class.

The original C# class suffers from a violation of command/query separation and also does a couple of things.  Breaking out the code functionality, the class creates a list of random stocks in the constructor. 

Then there is a timer that loops and periodically updates the current stock price. 

Finally, it broadcasts the new stock price to any connected clients.

Because the class depends on the clients for its creation and lifetime, it implements the singleton pattern – you access the class via its Instance property.  This is a very common pattern:

Attacking the class from a F# point of view, I first addressed the singleton pattern.  I checked out the Singleton pattern in Liu’s F# for C# Developers. The sentience that caught my eye was “An F# value is immutable by default, and this guarantees there is only on instance.” (p149)  Liu then goes and builds an example using a private class and shows how to reference it via a Instance method.  My take-away from the example is that you don’t need a Singleton pattern in F# – because everything is Singleton by default.  Another way to look at it is that a Singleton pattern is a well-accepted workaround the limitations that mutability brings when using C#.

I then jumped over to the updating stock prices – after all, how can you send out a list of new stock prices if you can’t mutate the list or the individual stocks within the list?  Quite easily, in fact.

The first thing I did was to create a StockTicker class that takes in a SignalR HubContext and a list of stocks.

I then added the logic to update the list and stocks.

Looking at the code, the word “update” in the prior sentence is wrong.  I am not updating anything.  I am replacing the list and the stocks with the new price (if determined).  Who needs a singleton?  F# doesn’t.

I then attempted to notify the clients like so:

 

But I got a red squiggly line of approbation (RSLA) on the updateStockPrice method.  The compiler is complaining that

Error    1    The field, constructor or member ‘updateStockPrice’ is not defined   

And reading the SignalR explanation here:

The updateStockPrice method that you are calling in BroadcastStockPrice doesn’t exist yet; you’ll add it later when you write code that runs on the client. You can refer to updateStockPrice here because Clients.All is dynamic, which means the expression will be evaluated at runtime

So how does F# accommodate the dynamic nature of Clients.All?  I don’t know so off to StackOverflow I go….

In any event, I can then wire up a method that broadcasts the new stock prices like so:

And then write a method that calls this broadcast method every quarter second:

Note that I tried to figure out the Timer class and subsequent Event for the timer, but I couldn’t.  I stumbled upon this post to ditch the timer in favor of the code above and since it works, I am all for it.  Figuring out events in F# is a battle for another day…

 

 

 

F# and SignalR Stock Ticker Example

I was looking at the server broadcast SignalR tutorial found here for a current project when I got to the StockTicker class.  In this class, the interesting code surrounds making a singleton instance because SignalR hubs are transient.  Here is the full text:

You’ll use the SignalR Hub API to handle server-to-client interaction. A StockTickerHub class that derives from the SignalR Hub class will handle receiving connections and method calls from clients. You also need to maintain stock data and run a Timer object to periodically trigger price updates, independently of client connections. You can’t put these functions in a Hub class, because Hub instances are transient. A Hub class instance is created for each operation on the hub, such as connections and calls from the client to the server. So the mechanism that keeps stock data, updates prices, and broadcasts the price updates has to run in a separate class, which you’ll name StockTicker.

So then it hit me – we need an immutable class that can handle multiple requests.  This sounds like a job for Captain F#!  Unfortunately, Captain F# is on vacation, so I went with Private 1st class F#.  So this is what I did.

I created an empty solution.  I then added in a C# Empty Web Application just to have a point of comparison to the FSharp project.  Then I added in a new F# MVC4 project from on the on-line template that Daniel Mohl created:

The problem is that the C# is the web app and the F# is just the controller.  Since I want a full-on double rainbow F# only MVC application, I tossed the template and just created a bare-bones F# project.  I then opened the .fsproj file and added a web ProjectType GUID (basically parroting what was in the .cs project file):

I posted this to stack overflow here.  So I am back to using C# as the Web application and F# as the plug in code.  I re-started with a couple of skeleton projects like so:

I then added a class for Stock like so:

 

I then added some unit tests to verify that I could create the Stock class and that I could assign the Symbol property:

 

And sure enough, they run green:

Just then, Captain F# swooped in from vacation and exclaimed “What are you doing?  The tenants of functional programming is immutability.  What happens if you change the Symbol after the object is created – does it really represent the same thing?  In fact, allowing the Symbol to be changed after it is created will lead to bugs and potentially unexpected behaviors in your system!”  With that, he left for a 10-day tour of the eastern Mediterranean.

I then changed the Stock class to be immutable like so:

 

and then updated my unit tests like so:

And then I ran my tests and got red

Ugh, I reversed the parameters – I intended to have the stock go up $.25.  Instead, the constructor expects the Price to come before the DayOpen.  This is not intuitive – you have implicit temporal coupleing in these parameters and since DayOpen occurs sooner in the space-time continuum, I reversed the parameters and the tests ran green:

 

With that done, I looked at the last PercentChange  calculation.  The only thing remarkable about it is that the code in the on-line tutorial is incorrect.  The tutorial uses Price as the denominator, but my unit tests shows that it wrong:

 

If a stock goes from $10.00 to $11.00, it increases $1.00 and $1.00 divided by $10.00 is 10% – the stock increased 10%.

So I went back and changed the implementation to get the test to run green.

 

 

So looking at this class, why is F# better than C#?

1) Less noise.  Compare the code between C# and F#

All of the code in the Price setter is irrelevant.  In the F# implementation, you don’t need to worry about assigning DayOpen for the 1st time. 

 

2) Fewer Bugs: 

What happens if you are looking at Pets.com (IPET) on November 6, 2000 when it opened at $.16 and then went to $0.00 at noon when they finalized their liquidation?  You need to change your code b/c the C# implementation is wrong – the price was $0.00 and it was not the open price.

Also, what prevents me from changing the Symbol?  I could create a ticker class for APPL at $519 and then change the ticker to MSFT – volia MSFT’s price goes from $37.57 to $519.00!  And all of the unit tests for the Stock still run green.

3) More readable. 

Less noise – more signal (SignalR in fact)…

 

This blog post is getting a bit long so I will continue this project on another post.

Thanks to the RHCP, I listened to this 2-3 times when doing this blog post…