TheCodedWorld

I have taken a special interest in parallel and asynchronous data processing in F#. The absolute majority of the really hard to fix bugs that I have come across during the last years all have one thing in common, thread safety. Or rather, the lack of thereof. It is very easy to write a class in C#, Java, or C++ that is not thread safe. And if you try to make it thread safe it quickly can become quite complex and it is easy to forget to put a lock on a variable or make some subtle mistake that makes the lock useless (locking on a reference to an object that you later make a copy of, which makes locking the old reference useless, is a not so uncommon mistake that can be really hard to spot). Another thing about thread safety is that it is really hard to test for. All your tests might run perfectly fine, but then when you go into production, things starts crashing in really strange ways. F#, and other functional languages, addresses these problems and makes it easy to write code tha...

I have been wanting to learn functional programming for real for a while now. I must say, it has been tough. Being used to procedural and object oriented programming languages like C, C#, and Java, I am used to being able to grasp new programming languages quite fast. But functional languagues, that's a completely different story. In pure functional programming there are no variables, no states, none of the things you are used to in an object oriented language. It is like starting over from scratch. Let me give you an example, assume you want to calculate the sum of all even numbers between 0 and 100 squared. How would you go about implementing that? Well, I would define a variable, sum, that keeps track of the sum so far. Then I would create a for loop, for (int i = 2; i <= 100; i += 2), in which I add i * i to sum. In functional programming however, you should avoid mutable values and loops. So what to do? Well here is one example on how you can do it in F#: [0..100] ...

Today I wrote some tests with the goal to verify thread safety on a part of production code. Using TDD I wrote a test that started two new threads that both updated the same object, and while they were running I verified the object's data. By putting this in a loop I was able to get a unit test that failed on each run. By adding locks at the correct places I got the test to pass. But looking at the time it took to run the test I noticed that it was quite slow. I knew that the updates to the object's data were fast and started wondering if it was the start and join of the threads that were slowing it down. So, instead of using new Thread(task) I switched to using Task.Run(task) and task.Wait() instead of thread.Join() . The main difference here being task adding a job to a pool of worker threads while new Thread creates a completely new thread that is stopped and disposed after it has run to completion. By doing this small change the test time decreased by 25% (from 80...

For reasons at work I am currently looking into how storing and retrieving data from databases works. Was introduced to an abbrivation that I didn't know of earlier, ACID. ACID is a combination of Atomicity, Consistency, Isolation, and Durability. Atomicity - requires each transaction to be "all or nothing". A transaction may consist of several writes to the database, however, if any of these fail, or is interrupted, the entire transaction must be invalidated in order to have the database in a valid state. Consistency - requires that any transaction will bring the database from one valid state to another. No transactions may currupt the database. Isolation - ensures that concurrent transactions results in a system state that would be obtained if they were executed sequentially . Read that sentence again, it is a tricky one. Be able to perform concurrent transactions in a way that the result is like they have been done sequentially... Durability - ensures that a tra...

The observer pattern is a behavioral pattern that lets several objects, observers, subscribe to state changes at another object, the Subject. As with the Iterator, the .NET framework contains interfaces that are recommended when implementing the design pattern. These are named IObservable and IObserver. The subject should implement the IObservable interface while the observers implement IObserver. Of course, you do not absolutely need to use these interfaces in order to implement the observer pattern but it is good to know that they exist.

The iterator design pattern is an integrated part in many languages and frameworks. In C# you can implement the IEnumerable interface (defining the GetEnumerator method) to make a class iterable. Using the yield keyword makes the method return an iterator. This is so simple in the .NET framework that I did not bother to create a UML diagram this time. Check the code in my GitHub repository  for an example on how to implement IEnumerable.

No software design patterns overview can be complete without describing the Factory pattern. I would say this is one of the most commonly used patterns. Let's get right to the UML diagram. As can be seen an interface, Creator, is defined for creating a Product, but it is the ConcreteCreator that decides which subclass of Product to instantiate. From the client you instantiate the ConcreteCreator and use that to create the products. It is the resonsibility of the ConcreteCreator to see to it that the product is created correctly. This adds a nice level of abstraction since any changes to how the ConcreteProduct is created only needs to be reflected in the ConcreteCreator. The users of the product does not need to change their implementation.