Cross-platform UIs with F# and Fable

If you are small vendor and your primary focus hasn’t been in designing UIs, entering the field today presents you with too many choices. However, if you’d like to use existing expertise and develop new ones in way that would accommodate broad range of platforms: Web, Mobile, Windows and, ideally, OSX and linux – the choices shrink dramatically.

We have some WPF expertise in house, but due to premature demise of Silverlight it has become a non-transferrable skill. Xamarin seemed like a way forward, but it would fragment our investment into Mobile/Desktop and despite Xamarin’s accomplishments (and they are impressive) it remains a fragile niche and having tried it we decided to keep looking.

React (and its Native derivative) with “learn once, write anywhere” approach seems like a promising direction but it has one (big) problem – JavaScript. Having built statically-verifiable code the weak and dynamic nature of JS leaves the language entirely unattractive. On the other hand JavaScript as ecosystem is like a lab full of petri dishes, rapidly blossoming and quickly killing off an infinite stream of ideas. It’s great of course that it’s happening, but trying to figure out the minimal viable combination of tools and libs… the fatigue sets in rather quickly.

Over the past couple of years we at Prolucid have been building up our F# skills developing backend systems and looking at Elm with its beautiful implementation of “model view update” architecture and Fable with its amazing capabilities I realized we may have our way forward.

Building hardware and low-level device software I expect we’ll be dropping into native quite a bit, but doing native in the tools that were designed for it seems like an excellent idea anyway. At the same time we’ll be able to reuse tools, core logic and models across platforms and tiers.

What was lacking is F# implementation of Elm’s dispatch loop, similar to what Redux does, but w/o all the overhead seemingly designed to overcome the language shortcomings. There’s an implementation in fable-virtualdom from Tomas Jansson, but it’s tied at the moment with virtual dom management.

To that end an early build of Elmish is now available on npm. Elmish is a small library that has been designed following Elm’s concepts and terminology and it should work with React, ReactNative, virtualdom and any other DOM/rendering framework.

There are samples for React (CounterTodoMVC) and React Native.

With exception of F# syntax and explicit dispatch function being passed around one could follow Elm’s documentation when studying this approach to writing a UI, but hopefully I’ll get some time to write some docs in the next few weeks.

Many thanks to Fable contributors for the help with the ecosystem and for making F# a competitive language to write cross-platform UIs in!

Cross-platform UIs with F# and Fable

Real-time analytics with Apache Storm – now in F#

Over the past several month I’ve been prototyping various aspects of  an IoT platform – or more specifically, exploring the concerns of “soft” real-time handling of communications with potentially hundreds of thousands of devices.

Up to this point, being in .NET ecosystem I’ve been building distributed solutions with a most excellent lightweight ESB – MassTransit, but for IoT we wanted to be a little closer to the wire. Starting with the clean slate and having discovered Apache Storm and Nathan’s presentation I realized that it addresses exactly the challenges we have.

It appears to be the ultimate reactive microservices platform for lambda architecture: it is fairly simple, fault tolerant overall, yet embracing fire-n-forget and “let it fail” on the component level.

While Storm favours JDK for development, has extensive component support for Java developers and heavily optimizes for JRE components execution, it also supports “shell” components via its multilang protocol. Which is what, unlike Spark makes it interesting for a .NET developer.

Looking for a .NET library to implement Storm components there’s the Microsoft’s implementation – unfortunately components in C# end up looking rather verbose and it happens to work exclusively with HDInsight/Azure, which is a deal breaker for us, as we want our customers to be able to run it anywhere. Fortunately though, further search revealed recently open-sourced FsStorm announced on Faisal’s blog and I liked it at first sight: concise F# syntax for components and the DSL for defining topologies makes authoring with it a simple and enjoyable process.

The FsStorm components could be just a couple of lines of F#, mostly statically verified, have clear lifecycle and easy to grasp concurrency story. And with F# enjoying 1st class support on Mono, we are able to run Storm components effectively on both dev Windows boxes and distributed Linux clusters while capitalizing on productivity and the wealth of .NET ecosystem.

It is now available under FsStorm umbrella as a NuGet package, with CI, a gitter chatroom and a bit of documentation.

While still in its early days, with significant changes on the horizon – something I want to tackle soon is static schema definitions for streams and pluggable serialization with Protobuf by default, I believe it is ready for production, so go forth and “fork me on GitHub”!

Real-time analytics with Apache Storm – now in F#

void is a bug

Having studied Haskell and F# and done a lot of C# coding in functional style I realize that “void” declaration in C-family of languages is a bug in the type system.

It appears where a type should be, but is in fact an instruction to forget everything you know and hold dear and treat the calls to this function differently.

Enter Action vs Func<Unit> distinction. What it comes down to is that you have to duplicate all the code that works for Func<> to get its functionality for methods that don’t have a value to return.

.ForEach() doesn’t have to exist and yet, there’s gazillion implementations floating around for something that could have been implemented (once) as something like a fold().

.NET 3.5 should have included and promoted Unit type.


void is a bug

My best code ever

Yesterday I wrote the best piece of code I’ve ever written… I was so full of myself 🙂

Incidently it’s all thanks to Functional Programming and the insights gained from reading on Lisp, Ruby and LINQ.
It would have been shorter and probably prettier in Ruby or Lisp or even C# 3.0, but it works beautifuly nevertheless.

I’m stuck with Sharepoint as the database and had to build layers and UI around it.
If you ever wrote rich business model with data access layer around web-services you know exactly how it felt.

Comes along… a New Requirement.
We need to provide access to some of application data via web-serices.
No problem, I know Contract-First, I can do stuff like that with my eyes closed.
My boss has an idea to cache the results returned from Sharepoint to avoid the extra web-service call.
No problem – cache it is, with background update and a query interface.
Here’s where the good part comes in – I implement the interface as taking a Predicate<T>.
Of course it wasn’t ground-breaking in any way if you know .NET 2.0 –
lots of collections implement .FindAll(Predicate<T>), but it was bold and new
(and I have a mental chuckle imagining an Average Developer looking at it later on).
It also uses worker pool for parrallel-processing the search request (another chukle).

Comes along… a Refined New Requirement.
My web-service has to support search functionality and handle a Complex Criteria,
somethig like “gimme all A where A.Name or A.Alias are like “xxx” and A.Status is not in (Z,Y)”.
The only time I’ve seen a web-service supporting a query like that was Sharepoint itself.
I’m not keen on introducing an expression tree into web-services,
especially that I’m implementing both ends of it, but a requirement is a requirement.

Enter Templates Collection…
The other good idea was to use templates as the way to supply search criteria.
The idea of templates comes from Hibernate, where criteria can be expressed using an instance of the resulting class.
Collection of templates allows one to express almost everything an expression tree could do.
The criteria above becomes a collection: { new A(Name=”xxx”,Status=X), new A(Name=”xxx”,Status=W)}

The keen may notice that I’m cheating on 2 accounts – 1st I’m reversing “not in” to “in”
and 2nd – I’m using Name attribute to comapre Alias as well.
I find the trade-offs acceptable considering I was done with implementation and unit testing
within a few hours of getting the requirement.

And that’s where Functional Programming shines and the decision to use Predicate<T>
as the only parameter to query pays off spectacularly.
I’m processing my templates and turn them into predicates and chain the predicates together to pass to the search function.

It may not sound like much, but boy is it short, concise and to the point! The whole conversion from templates to a predicate takes about half a page of code.
I declare it my best code ever.

I’ll see if I can turn my code into a meaningful example to post here later.

My best code ever

Introducing functional programming to C#

I’ve been digging into functional programming and came a cross a need to have something like ‘self’ in my anonymous delegate.
The post here describes this and other tricks (available to trully functional languages out of the box) implemented in C# (unfortunately 3.0)
Introducing functional programming to C#