This blog post is the written form of my presentation about how simplicity enables an evolutionary software architecture.
Simplicity enables an evolutionary software architecture
S
Our journey to F#: libraries we use
O
When I started with F#, I had some problems to find good libraries for the stuff we need in our software. Sometimes the problem was to find a library at all, sometimes several libraries provide similar functionality. So here is a list of the libraries I like to use (what we use and why).
Our journey to F#: CompilationRepresentationAttribute
O
We have a solution containing C# and F# code. In this post, I’ll show you how the CompilationRepresentationAttribute helps to use F# code from C# by preventing naming conflicts on types and modules.
C# vs. F#
C
I dared to ask two questions on twitter:
What makes your daily developer life easier in F# compared to C#?What is better in C# than F#?
This post summarizes the answers and my own opinion on where C# and F# shine.
Our journey to F#: persistency
O
Prepare for a long post about how we persist data with F# using Dapper into (Azure) SQL Server. I will also show, how we can run our tests either with an in-memory database simulation or a real database. As always, if you spot something that can be improved, please let me know. We are still learning…
Our journey to F#: bye-bye fluent syntax Version 2
O
In the previous blog post “bye-bye fluent syntax”, I wrote about a way how to implement an equivalent to a fluent syntax in F#, without classes and interfaces, using discriminated unions.
Steve Gilham pointed me to a much simpler solution (many thanks again!). And it looks like this:
Our journey to F#: Equality for free
O
We had one kind of defects in our C# that was very annoying: hidden usage of equality and missing equality members on involved classes.
We invested a lot of time to get rid of these in our C# code. Luckily, in F#, this problem does not exist because of the compiler.
But, let’s start at the beginning…
Our journey to F#: happy path coding
O
The application we are developing – it’s TimeRocket, just in case you forgot 😉 – has quite a lot of code that looks something like this (pseudo-code): given is an identifierload the data represented by the identifier if it existsif the data could be loaded, validate if the desired action can be executedif it can then continuereport back success or what failed In C#, we often resort to exceptions because otherwise, we get a pyramid of doom. So it’s time for one of the...
Our journey to F#: Relearning using the IDE
O
After a month of programming F#, I realized that I changed my usage of my IDE (JetBrains Rider). Here is how and why:
Our journey to F#: bye-bye fluent syntax
O
In C#, our preferred way to define a builder is using a fluent syntax. Whether it is setting up the system under test in our specifications by defining how we want external calls to be faked, setting up complex test data or defining the steps to be executed in an operation with automatic compensation in case of an exception. In F#, this works, but feels weird, because a fluent syntax typically uses classes and/or extension methods and there are a lot of . involved. So we experimented with a...