Casinos invest a lot of energy selling the dream. One way to do this is by showing off people winning big in your casino. Everyone has seen those corny pictures of people holding human-sized cheques right? It’s a solid tactic, since empirical evidence shows that after a store has sold a large-prize winning lottery ticket, the ticket sales increase from 12 to 38% over the following weeks. If we look at slot machine play, what exactly defines a big win? The first stab we took at this was quite sloppy. We took an arbitrary number and said wins bigger than 500 euro are impressive. This was quick and easy to implement, but when we observed the results we noticed that when you have players playing at high stakes, a win of 500 euro really isn’t that impressive, and we would see the exceptional high roller often dominate the results. ...

Early Summer, I had to set up an integration with an external partner. They required of us to daily provide them with a relational dataset stored in SQL Server. Most, if not all of the data was temporal, append-only by nature; think logins, financial transactions.. Since the data required largely lived in an eventstore on our end, I needed fast bulk projections. Having experimented with a few approaches, I eventually settled on projections in F# taking advantage of type providers. ...

Earlier today I was writing a migration script in F# where I had to calculate the aspect ratio based on the given screen dimensions. This is one of those problems where I don’t even mind breaking my head over, but directly head over to Stackoverflow to find an accepted answer which I can just copy paste. Since I didn’t find an F# snippet I could use, I ported some JavaScript, and embedded the result below for future snippet hunters. ...

In a previous series of posts, I went over the models used by casinos to spin a wheel (spinning, manipulating the odds, clustering and near misses). I did not yet expand on the basic mathematical models that ensure a casino makes money. Let’s pretend we are spinning the wheel again. The wheel has 5 pockets, and just one of those is the winning one. Given we will be using an unmodified wheel, you win 1 out of 5 spins. Each bet costs you 1 euro. Looking at the true odds (1/5), the casino should pay out 4 euro for you to break even. ...

This is the third post in my series on porting a node.js application to an F# application. So far, I’ve looked at parsing command line arguments, handling commands and storing events. Today, I want to project those events into something useful that can be formatted and printed to the console. In the original application, I only had a single query. The result of this query lists all items consumed grouped by category, sorted chronologically. ...

As I wrote earlier, I’ve been working on porting a node.js web application to an F# console application. It’s an application I wrote to learn node.js but still use today to keep track of all the things I consume. The application is able to consume an item, to remove a consumed item and to query all consumed items. In the previous post, I parsed command line arguments into typed commands and queries. Today, I’ll look at handling the two commands. ...

Coming from C#, I’m used to the compiler warning me about unused variables. Relying on the compiler to help me with checked exceptions in F#, I noticed that unused values (and functions) would go unnoticed. Having accidentally read earlier that Haskell has a compiler flag to check for unused bindings, I looked for the F# equivalent but failed to find it, until Scott Wlaschin pointed me in the right direction. By using the –warnon:1182 flag, the compiler will warn you about unused bindings. ...

Last year, I set out to write my first node.js application; a small web application for keeping lists of everything I consume. I had something working pretty quickly, deployed it to Heroku and still find myself using it today. Since there’s very little use for having it running on a server, and because I wanted something to toy with getting better at F#, I decided to port it to an F# console application. ...

In the land of C#, exceptions are king. By definition exceptions help us deal with “unexpected or exceptional situations that arise while a program is running”. In that regard, we’re often optimistic, overoptimistic. Most code bases treat errors as exceptional while they’re often commonplace. We are so confident about the likelyhood of things going wrong, we don’t even feel the need to communicate to consumers what might go wrong. If a consumer of a method wants to know what exceptions might be thrown, he needs to resort to reading the documentation (or source) and hope it’s up-to-date. ...

In our system a backoffice user can issue a promotion code for users to redeem. Redeeming a promotion code, a user receives a discount on his next purchase or a free gift. A promotion code is only active for a limited amount of time, can only be redeemed a limited amount of times and can only be redeemed once per user. public bool TryRedeem(UserId userId) { if (HasAlreadyBeenRedeemedByUser(userId)) return false; if (NoLongerActive()) return false; if (Depleted()) return false; Apply(new PromotionCodeRedeemed(userId.Value)); return true; } In code these requirements translated into a promotion code aggregate which would guard three invariants. ...