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…
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...
After a month of programming F#, I realized that I changed my usage of my IDE (JetBrains Rider). Here is how and why:
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...
I develop code with C# for 18 years and I’m a heavy ReSharper/Rider user. So I know a lot of shortcuts. Really a lot.Actually, my fingers know them. Whenever I get asked during pair programming how I did this, I almost certainly reply with: “ask my fingers, I don’t know.”
Programming in F#, I had to retrain my fingers to use some new shortcuts that I was not used to. And that’s why I share them here with you:
To start our experiment with F#, we first needed to learn to write code in F#. Read a little I knew about the site quite some time, but finally, I took the time to read some posts there until I thought I’m fit enough to code something real. Code a little Once upon a time, I wrote a report generator for xBehave.net in C#. The report generator generates a markdown report from the results of a test run of xBehave.net tests/specs. The code was old and lacked some features. So I started...
The past I’m a C# developer since .Net came into life in 2002. I’ve built many systems using C#, and I like(d) it. C# is an excellent object-oriented programming language. For the last five years, I’ve built only backend systems with C# – the clients were web clients. The backends we built were almost entirely stateless. Either the client holds the state or the state resides in a database. So we started to write stateless C# code. Today, we write lots of read-only data...
This is a cheat sheet for team decision making that I compiled from discussions in open spaces and conference workshops:
Team decision making
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Let’s look back at the workflow Max and his team used to build a solution to their problem. First, they invested in problem understanding so that they then could decompose the problem into almost independent subproblems. Finding solutions to the subproblems and composing these together into a solution for the whole problem were the next iterative steps. Once a consistent...
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Max and his team can now build software in steps, adapt to new business needs and technology changes, and evolve the software architecture accordingly. But like most teams after a while, they get the feeling that they lose speed. Development takes longer, features get completed less and less. It’s time to improve the code base and invest in innovation. But unfortunately...