Menu

F#

Today I was trying to create a quick integration with a bug tracking tool, as a little spike, unfortunately as is often the case, out of date documentation, vague errors, etc held up the task. None-the-less I got something working with cookie based authentication (I’ll be switching to OAuth based soon I’m sure that’ll go just as smooth). I’ll also submit a report about the problems with the documentation I discovered.

The rest of the documentation seems ok, but only time will tell as I get further with it, but from my experience it’s usually the initial steps that result in the most frustrations, as you get reminded not to trust the documentation…

What’s not clear in the documentation:

Even though you sign in with your email address, you really need to use your username (which is different), at least is for the `admin` account.

Error 1: there is a leading `/jira/` element in the auth API route, this may be old or may be specific to self hosting, it’s not part of the URI for on-demand, it should be `http://jira.example.com:8090/rest/auth/1/session`

Error 2: (the big one) what is returned is a different `session` object and it not only contains the required `JSESSIONID` but also another key,value pair you need to have in your cookie when you make a subsequent request: `studio.crowd.tokenkey`.

The core objective was to get specific events from 1 system to be reflected in new or existing locations in a second system. In this case the second system is JIRA the bug tracker.

Complete Solution

The break down will follow below.

Sorry this code is a bit awkward because RestSharp is written for fluent C# style usage, I’ll be looking for an F# focused rest client, and I only chose ReshSharp because I had used it ages ago.

Walk Through

Some types to send along, notice the casing, that’s because I don’t have any JSON serialization code wired up yet to do the case change from .NET uppercase convention to lowercase JSON style.

Using these records, against your on-demand account make the auth request, and inspect what you get back (see Error 2) and you’ll discover more cookie details come back than documented. As an extra note as to why it was even more frustrating if you capture and review the calls from the web UI those calls supply even more cookie details such as: `ondemand.autologin`, `xsrf.token` and others.

Why?

Because your model is structured this way, and you have realised you need this, otherwise this doesn’t apply to you.

Scenario

When you get used to using AutoMapper to help you everywhere, you begin to demand it helps you everywhere by default. In this scenario you have to configure it to help you map from an F# type that has option (Guid is just an example).

In our event sourcing setup, we have commands that now change to have an additional property (not option), but the event now needs to have option (as that data was not always present).

We end up using those types/classes (events) that have the optional value to map to C# classes that are used for persistence (in this case RavenDB), and they are reference type fields so a null value is acceptable for persistence.

Here’s the Source and Destination classes, hopefully seeing that makes this scenario clearer.

On the 5th of June* at work we decided to give F# a go and by ‘go’ I/we mean really use it in the most important parts of our application. Some of the team has had greater exposure to functional languages like Haskell and Scala, they are the ones being our champions and guiding the rest.

*I know the exact date because it is marked by a small commit of a blank F# project added to the solution I went back and checked.

This was not a snap or rushed decission but one with a fair few chats over code examples and a proof of concept.

If I have to boil down the decission to go ahead with F# at this early stage it is:

Record Types

Patern Matching

Immutability

These language features combined with team motivation to be working with something new and interesting “sold” the rest of us who haven’t didn’t have the exposure yet.

At this point I want to confess that it’s a strange feeling to be working with F# code and not having the same level of confidence to make changes and jump in and write like I would with my near decade of experience in C#. Many would argue that that’s actually quite a good thing, and I’m starting to agree – for one thing it means I’m thinking longer about the code.

It’s very easy to just write some procedural logic, call some methods, change variables, and just keep writing until it works and think about tidying it up after the fact, or worse leaving a “//TODO: clean this up” comment for a future self or peer to rage over.

Take the preceding paragraphs and the title of the blog post as my disclaimer that this is all new to me but here goes… My take on the concepts I understand and apprecaite about F# so far are simple and based on and how it’s helping me and the team so far to write code more easily.

Record Types

Concise / less code

In our CQRS style application we have lots of little commands (that’s what the C stands for), and lots of events so being able to very succinctly create these is a huge win.

Pattern Matching

Immutability

Concise

Of the 3 things I this is the most fundamental F# concept that I can appreciate so far, at a mimimum it’s about avoiding side effects in your code, and makes you think about transforming data as it flows through your application. In our CQRS world this is a great match, a command gets populated, it shouldn’t change. An event gets produced, that’s even more definate it happened – here’s what happend it doesn’t change.

Did you notice the trend for each of the 3 items I chose to cover, that’s right it’s about being concise. The immutabilty may not always be less code but you absoultely do get conciseness. If you take 1 thing away from this is that how could less code possibly be bad, less to write, less to mainting, win, win.

That’s it for now, we haven’t had to give up and re-write all this code in C#.