Software must be configurable to be flexible. A configuration defines parameters and settings for software. Usually, the settings are stored in a configuration file that the software reads. But how do we ensure that a configuration is complete and valid? That all aspects that need to be configured are actually configured? That there are sensible defaults for values not explicitly configured? And that the values entered in the configuration are actually sensible values?

To avoid answering these questions anew for each project, we have developed a library for configurations for Clojure and ClojureScript that we have been using successfully for many years - and present in this article.

Read on...

This post is part of the series on functional software architecture in Kotlin. The first one covered functional validation, and this part is about monads. In Kotlin, these are particularly useful when describing domain workflows that should be separated from the technical logic for executing these workflows - specifically using small domain-specific languages (DSLs).

This episode is about how monads actually work. Kotlin has - like many functional languages - special syntax for this, even though you won‘t find it under the „M-word“ in the documentation. It‘s hidden behind the suspend keyword.

Read on...

Lenses are an important concept in functional programming with great practical utility. Several years ago, we already introduced functional lenses here on the blog. Since then, we have continuously expanded our use of lenses in our daily work. Today we want to show how we use lenses as bidirectional transformations and how they help us convert between data representations.

We implement the example for this article with our comprehensive and freely available Clojure library called Active Clojure, which we use in all our Clojure projects. This library includes implementations of lenses and Records, the latter of which is for representing compound data in Clojure. The combination of lenses and records is particularly helpful.

Read on...

This post is the beginning of a series about functional software architecture in Kotlin. Its material originally comes from a collaboration between Active Group and Blume2000, where we consulted them on the development of their web shop. I wrote this post together with Benedikt Stemmildt, who was CTO at Blume2000 at the time.

This post is about data validation. We want to ensure that objects in our program are „valid,“ meaning they satisfy arbitrary consistency criteria without which our software won‘t function.

My colleague Marco Schneider already presented abstractions for this in Haskell in an earlier post.

The same ideas can also be transferred to Kotlin — with some compromises. In this post, we‘ll tackle the topic anew, specifically how we can help an object-oriented perspective using functional techniques. So it‘s not necessary to read the Haskell post. (We still warmly recommend the post, as it particularly describes the concept of Applicative, which is impractical in Kotlin.) However, basic Kotlin knowledge is assumed.

Read on...

Riemann is a stream processing system that is excellent for collecting and processing events and logs from servers and systems. We successfully use Riemann in production in very large IT systems as a core component for log and metric processing and for monitoring.

We use Riemann to process events and forward them to long-term storage systems like Elasticsearch, where these events can be conveniently searched through user interfaces like Kibana. Additionally, we use Riemann to write metrics to time-series databases like InfluxDB; these time series can then be visualized through user interfaces like Grafana or can also be used to alert on errors and problems.

Today we‘ll show with an application example how to extract metrics from logs using Riemann.

Read on...