About one year ago, I just finished looking at what was new in the world of mouses. I wondered whether there could be something new in the world of Keyboards.

​Only one product appeared very different, which was the Beeraider Keyboard. But the product did not exist yet, it was crowdfunded via a pre-order process. The design was singing in my mind though, so I pre-ordered in September 2015, accepting all the risks this step could involve.

Once per month I received a status update email from “Ray”, whose surname is yet to be discovered, but those mails kept a certain feeling of progress being made. One year later, the product is finally send to its funders. I’ve worked about one week on the keyboard, and it is time to tell a story.

Novelty and hardships

The wireless Beeraider keyboard is shipped with a wireless mouse. Apparently there have been a few confusions, but the antenna can be found in the battery compartment. I also received the batteries for both keyboard and mouse. There is an instruction manual which you really need to read through, or you won’t get it. The package also includes a CD-rom with drivers, install those and then get the latest version from the web.​After you installed, you need to re-learn how to type. Beeraider comes in two keyboard layouts, the qwerty layout, and the optimized layout. I chose to go all the way, with the optimized layout.

Beeraider provided an excellent training video how to get started. And then you start typing, and typing, and typing. Stop a little, try to remember the keyboard layout by heart, try to see if your fingers can find all keys without looking. Focus on accuracy, and after a few days you gain a little speed. Won’t be anything you are used to tough.

I used the keyboard for software development, and to write a few articles. In the current state I’d say that the keyboard is more suitable for writing text, than writing code.

The Good

Every one in professional data entry has heard about the right way to sit behind your keyboard. However, the good old rectangle “qwerty” keyboard allows you to bend the rules a bit. Beeraider does not negotiate. It hurts to bend the rules. I needed to revise my sitting posture again. Chair up, place the keyboard under my fingertips, while the position of my elbows are leading. I’ve found a position which is a bit more comfortable, but I’m still experimenting. A new posture is activating though, which is a good thing.

Even though I’m not fully up to speed yet, I do notice progress in my typing speed. It is just a matter of seeing it through. Don’t learn this in your bosses’ time, you’ll be one week less productive.

Many keys at the top of the keyboard have some extra function, ie spelling correction, save file, and these work nicely. Note that the center button is a space-key, not an “Fn” button, even though they share the same color. I even programmed one of the macro buttons, which was quite easy.

The bad

I’ve already send the following observations to Beeraider, via their support form. Probably very busy with deliveries at this moment, but they’re currently not very responsive. Most crowdfunded projects have a blog or forum, to share experiences, and to send signals of activity. Now the product is leaving the factory, it would be a good moment to scale up.

The keyboard has a switch at the back, which I mistakenly took for an on/off switch. It actually switches between “qwerty” and “optimized” mode. I did not expect this switch on the optimized version. There is an on/off switch on the mouse, so it was my own Pavlov to even touch it. But then I searched for a few hours for language-settings, until I discovered why all letters came out wrong.

The product still has a few child diseases. When I plugged the USB antenna at the back of my notebook, I had a bad connection and a non-responsive mouse in some areas. Plugging it in at the side improved performance drastically, with nothing in between the antenna and the equipment. Both setups had less than one meter between antenna and keyboard/mouse. My old wireless Logitec mouse does not have this problem.

After a few hours of working, things sometimes go crazy, ie typing my name, would result in: “frnkkkkkkkk”. Correcting this and adding the letter “a” is simply refused, while some keys keep being repeated (driver v1.0.5). It sometimes helps to remove the antenna and re-insert it again.

Speaking of software development, I’m not convinced that the current “user experience” is very suitable for software development. The issue is that all special characters are accessible via ‘sticky keys’. So you press the blue key, and then the key with the special character. On a classic keyboard you hold Shift and press 9 to get a parenthesis. On the optimized radial keyboard, you press blue and then you press ‘T’. You don’t -hold- the blue button, so every special character always involves two key presses. I don’t expect this to sell very well in software sector, where such special characters are very common. I actually did some development in FSharp with BeeRaider, and found this feature quite reluctant.​One issue that software can’t solve. The mouse has a very comfortable coating, but it wears of in hours, making your long awaited and brand new mouse look old and compromised. Where your hand is resting on the mouse, it is stained, in my case the left mouse button, a the right half of my hand-palm.

Conclusion

​Even though my criticism, I do love this keyboard. Its creator has started this project in the nineties’ or something. During the last year, it did become clear that BeeRaider is very committed to make this into a perfect product. I have version 1.0, and the adventure has just begun.

I was asked to give a presentation at work about Akka.Net. Even though my audience is 100% C# loving, I will give a demonstration with F# code. I was already working on a project to rewrite “Three is a Crowd” to the Actor model in F#, and this presentation was a driver to finish this project. Let’s share my experiences with Akka.Net here.

Choices and Motivation
There were two goals of rewriting the game to Akka.Net. First of all, I wanted to try out a few design patterns. Secondly, if you run a multi-player game and your server needs to bring different players into the same context, you will run into big technical challenges if you store state in a file or database.

The previous version of the game stores state in a file, and uses file-locking to synchronize/sequence the threads for multi-player access. This choice was made due to past bad experiences with a cheap hosting-party in India, whose load-balancers took away any form of pan-threaded resource sharing, except the filesystem. Even if I chose a DB to store state, then the technical solution would still be quite hard, because then you end up migrainial row-locking feasts, with the risk of time-wasting deadlocks.

Akka.Net seemed to be the ultimate solution to the problem of different players working together in the same state-full context. That could of course not run on the cheap Indian hosting provider with their faulty Plesk interface. But it could certainly run as a service under different operating systems.

Because from work-side, we were investigating Akka.Net as a solution to some project, I was extra interested in Akka.Remote. So this project was separated in a Game Engine part and a Presentation part, instead of having the GameEngine embedded in the Web-Server.

The Presentation part was written with Websharper, because I wanted to (easily) use the HTML5 Websocket as a bidirectional communication channel between client and Game Engine. The previous version of the game had a polling mechanism to determine for each client whether it was his turn, or whether one of the other players had made a move and changed the board.

The Presentation part communicates with the Game Engine via Akka.Remote. One issue popped up quite quickly, Akka.Remote did not like my Discriminated Unions. Well, the issue was not really in Akka.Remote, but in the underlying serialization library from Newtonsoft. There have been numerous fixes over the years but none satisfactory, so I was adviced to use “Wire” for serialization. Instead of configuring this myself, I chose to use an experimental side-project, Akkling, which uses “Wire” by default and provides extra F# features such as static typing. With Akkling, you need to know what you’re doing. But when you get the hang of it, it works nicely. Wire processes Discriminated Unions flawlessly, so it certainly solves the issue.

If you compare working in C# or F# in respect to creating actors with Akka.Net, then the difference is that F# code is about 70% smaller than the C# version. In C#-land people are already making ML’s and/or DSL’s to speed up the work. Akkling reduced the work even more than Akka.Net’s standard F# support, with more features and extra static typing, which greatly reduced the error-risk. I really hope that this library will see a serious future.

Application Architecture
The basic application architecture is as follows:

To start at the left, the client has a bit of logic how to build the screen from data. At initialization it tries to register with the Game Server. Akka.Remote only allows actor systems to communicate with other actor systems. So the “Player Client” is an actor (in a local actor-system) through which this communication takes place. The Websocket-server bridges messages between the Websocket-client (in the browser) and the Player-Client actor system, in both directions. Finally, the “Player Client” connects with the “Player Server” in the Game Engine, through which the whole game is played.

Design Patterns
At the Game Engine side, I wanted to create a system with a waiting room. The first thing a new Player-Server actor does, is connect with a Waiting-Room actor. The Waiting-Room waits until enough players have entered, 3 players in this game. When enough players have entered, the Waiting-Room actor starts a Game-Room actor, and tells the players in the waiting room that they can connect to the Game-Room. The Game-Room determines who starts the game, who has which color, what the game-board looks like, and after this the game begins. During the game, the Game-Room informs all players about whether it is their turn, what choice other players made, what the game-board looks like after a player made a move. To support NPC AI’s, whenever a human-player enters the Waiting room, two AI’s are started, who wait 20 seconds before entering the Waiting-Room themselves. If their seat is taken (by another human player), then their attendance is ignored. Otherwise the AI is treated as a regular player.

The specific design pattern I wanted to try out in this game, was to find a way to move a player from the Waiting-Room to the Game-Room. The problem is though that there are limitations in how far an actor may be a container of other actors.

I thought of the “supervision” capability, where both Waiting-Room and Game-Room have Supervision on player-actors hang under them. The player actors could then communicate with their context (one of the rooms) via the “Parent” property. But I found two problems in this approach, -1- I did not find clear documentation how to create hierarchy in actors with F#, and I did not have much confidence in my own experiment-results. -2- I did not find any documentation on how to rehang an actor from one supervisor, to the other supervisor. I also did not want to re-create the player-actors under their new supervisor (the Game-Room), because this would at some point interrupt the communication, somewhere in the pipe between Browser and GameEngine.

One could also think of a construction in which both Waiting-Room and Game-Room have an array/list with player-actors. But then you still need to tell the player-actors about their context, ie. tell them in which room they are in. This implies that you manually program something into the player actor, that looks like the “Parent” property I mentioned above. Telling the player-actors about their context would make the whole array-structure obsolete anyway.

Instead of one actor being container of other actors, I decided for a different pattern. The Player Actor would have a flexible communication-line to his current Room. So a Player-Server actor should first talk to the Waiting-Room actor, and then change its connection to the Game-Room actor.

The player actor has max only one connection to a room, and this is the room he is in. This finally became the pattern. Thanks to Akkling I was able to use static typing and many Discriminated Unions to enable this quite complex mechanism.
Also the AI’s got a slightly different design pattern. In the previous TIC version, the AI’s had access to the centralized game-board state. That was possible because everything was happening in the same thread. In this version, everything is split it into different actors, and sharing game-board became less obvious. Now the AI-player actor keeps track of the game-board state locally. This also caused many more message to be send through the system, to keep the data consistent.

How to Run
The complete code can be downloaded from Github. The two most important projects are “GameEngine.Service” and “GameUI.Owin”, which should both be started when running this code in Visual Studio 2015.
​
The “GameEngine.Service” project can also be run stand-alone, and with this Fsharp script you can run it step-by-step.

It was one of those wow-moments when I learned that Fsharp is suitable for making a DSL, that actually appears readable. It looks better than one of those fluent interfaces with method chaining. I was really interested in making a DSL, just as a learning exercise, and perhaps to contribute a dime to the Fsharp community.

I stayed close to home, I already was in a System Integration project for my paid job, where we used Apache Camel. I was quite content with its elegance and simplicity.

However, it is in Java and I don’t know of any similar product in the .Net world. So I thought it might be an interesting experiment to create something similar, and I’ll keep/change things to my likings.

FsIntegrator
FsIntegrator is a DSL in FSharp that provides a framework to implement Enterprise Integration Patterns (EIP). What you actually create is middleware, which implements a workflow between different enterprise systems.

For example, if you are creating a service-order backend application, you may want to connect the inbox to an incoming order channel (ie. the backend of an E-Commerce website), send a message to a billing system to start billing process and send a service-call to your business-platform to activate the service you are selling. One system may work with a Soap interface, another system is connected via queueing software and the third system only processes plain CSV text files. This is what EIP is about.

Such a system-to-system flow can be defined by routes, which start with a listener on an endpoint, after which the processing is defined. If you listen to a queue, you can process the incoming XML message. If you are listening on a filesystem folder, you can process the content of incoming files. A route somewhat follows the actor model, where one route implements a static actor. So a route is just the machine, processing incoming data on the endpoints. A route is isolated, so only one message is processed, before the next message is accepted.

FsIntegrator is still immature. It currently only supports endpoints for: filesystem folder, FTP folder, ActiveMQ and Subroute (shared internal). There are a few logical functions to support the Content Based Router pattern. And there is some error-handling, where exceptions can be diverted to a different route, or equipped with custom logic before terminating the process. So this blog is not about a fancy end-product, but about interesting learning points while developing this.

Modular Setup, seamless integration
In these days people really like to include what they want, and leave what they don’t need. Keeping it small so to say. So I created a module for ActiveMQ. If not needed, it should not be included. If needed, you can include it, and from then on it should not be hard to find. I rely on IntelliSense to achieve these goals.

The namespace “FsIntegrator.Producers” has the “From” type, under which all endpoint listeners are available. If the FsIntergrator-ActiveMQ dll is not referenced, the IntelliSense shows the following:

And if the FsIntegrator-ActiveMQ dll is referenced, IntelliSense shows the following:

Both Core and ActiveMQ dll’s implement the FsIntegrator.Producers namespace, and define/extend the type “From”. The same trick has been used for the “FsIntegrator.Consumers” namespace and the type “To”.

Hiding Implementation Details
I have already written a blog aboutImplementation Hiding in F#. The goal of implementation hiding is to increase user experience for our DSL, keeping them distant of boring details.

Hiding comes in this case with a little challenge. The FsIntegrator Core dll has a Route Engine. Routes are added to this engine, and this engine does some management, start/stop routes, validate collisions such that no two routes are listening to the same endpoint, etc.

Now if the ActiveMQ module is built in a different dll, it does not know (much) about the route-engine, which is in the Core. But it should provide “hooks” to which the external RouteEngine can connect. These hooks are typically details that I want to hide.

The FsIntegrator ActiveMQ listener obscurely implements an interface, via which the hooks are provided. The obscurity lies in this. The implementation of the ActiveMQ listener class implements the interface defining the hooks. But in the corresponding signature file, this interface is not mentioned. An outsider who only looks at the surface will never know about the hooks.

You get compiler warnings for this, which you can suppress, and runtime you can still dynamic-cast the type to the hook-interface it implements.

Component Options via Intellisense
In FsIntegrator, I wanted to use IntelliSense as to present which options you can configure on an endpoint. So these are statically typed, and thanks to Discriminated Unions we can even provide complex option/configuration values. At the DSL level, an endpoint is configured with a list of options, which are specific for that endpoint.

The order of the list is unimportant. This format is convenient for developers, but terrible for FSharp code to deal with behind the scenes. So it is converted to an internal format, where each option always overrides a default value.

Monad Mini Language
For FsIntergrator I wrote my first monad. I implemented a few CustomOperations as mentioned in the cheatsheet, to provide a mini-language for FileSystem and FTP system operations. Nothing with quotations (yet).

Sometimes, after processing a file, you do not just want to move the file to some backup location and quit. Sometimes you want to delete a non-empty tree on the FileSystem, or in some cases even create such a tree at that moment. Or perhaps you receive a package of files which belong together, but your listener is only triggered by xml files, and when ready, the package needs some post-processing.

At this moment a mini-language is provided for the File-component and one for the FTP component, and very limited; no Fsharp code allowed.

Examples
I’ve created a few test scripts, to test FsIntegrator, manually. These scripts can also be considered as (hopefully) self-explanatory tutorials to use FsIntegrator. Well, this is the current status.

Future plans
A couple of things still on my todo-list are:
• File and FTP components currently only work with Xml files, it should also work with other content-types;
• All components should get more configure options, to improve route customization;
• Components which require network should get extra attention for security (logins, certificates);
• Create new components for Rabbit-MQ, Redis, etc….
• Automatic documentation generation should greatly improve;

The repository can be found on GitHub. I used Scaffold, FAKE and Paket, such that this can be build and run under Windows/VS2015 (tested) on Linux (tested) or perhaps OSx (not tested).

One of those things that I keep searching on the internet, for examples and Howto’s is, how do you hide stuff in Fsharp?

Hiding stuff can be very useful. When you create a library, or a DSL, or perhaps a framework, you want to provide a good user-experience by hiding implementation details. At the same time, you don’t want your code to add a magnitude of complexity, to fulfil this requirement. Fsharp is perfect for that, and the following may help.

Note that I will only handle cases which are harder to find on the internet, for basic syntax, please follow provided links.

Signature filesSignature files may be used to show or hide things at a file level. So if you have code file “mycode.fs”, you can have signature file “mycode.fsi”, which needs to come before the .fs file, in the file order of the project. So “mycode.fsi” specifies what can be seen in “mycode.fs”, by other files in the same project, and outside the project. What’s included in the .fsi will be accessible, what’s excluded will be hidden. You can automatically generate a signature file for the whole project, and use this as a start-point . I’ve seen issues with a generated signature file, so you still might need a bit of editing, but in most cases this is unnecessary.

Discriminated union
The cases of a discriminated union can either be fully hidden or fully public.
Example code:

From a different file, OpenDU.Case1 will be accessible, while ClosedDU.Op1 is not. So anything you want to do with ClosedDU.Op1 needs to be done in the .fs file.

Hiding in a record
A record may have record properties, but also static and instance members . A record may not inherit from another class (including an abstract class), but a record may implement an interface. So how do you show and hide all that?

Note that the first “type ClosedRecord” is to hide all record properties. The second line is to add the members to the type. Can’t you do that in one go? Good question, I did not find the answer. The “Create” member was added so that you can easily see that “this.Closed” is really hidden.

If a record implements an interface, you can hide it by excluding it from the signature file. You will get a warning that via reflection, one can still derive the interface. This is a design choice, if you hide to provide user experience, why care about someone digging with reflection?

Access Modifiers
Signature files are a nice way to hide and show large parts of your implementation. But sometimes you need it more fine grained.

If for example you have implemented an interface, or inherited from a baseclass (for classes), then you are required to include all interface or baseclass members in the signature file.

Sometimes that is more than you want to be public, because there can be technical reasons to choose for a baseclass/interface. For example, you want a set of types to implement a function member, while this function is only used internally. For user-experience, you don’t want to show that technical function to the outside world.
To hide such technical methods, you can use the “internal” access modifier on individual member functions, including “new “. You still need to mention all interface/inherited member functions in the signature.

Note that the “internal” modifier is applied on both the super- and the base-class. This way, member function “GetMyData” is hidden to the outside world, but accessible inside the project.
The outside world will see type “Base”, but that doesn’t have to be bad. You can also hide “Base”, but whether this is a good idea depends on your design.
​
You want to show a baseclass like “Base”, when you also implement types “StoreSomethingElse”, “StoreAnothingThing”, and you need to provide a combinator operator like this: