bad.robot

good robots do what they're told

Dealing with Exceptions as Monads

In some previous posts, I wrote about treating exceptions as a system wide concern. In this post, I extend that idea and talk about distinguishing between exceptional behaviour and just code that didn’t return what you wanted.

Pure functional languages often discourage the use of exceptions because when they are used to control execution flow, they introduce side-affects and violate purity of function. By using the type system to capture exceptional behaviour and dealing with exceptions monadically, it’s much easier to provide that system wide consistently I’ve been talking about.

Classes vs. Functions

You can use lambdas in Java 8 anywhere you would have previously used a single method interface so it may just look like syntactic sugar but it’s not. Let’s have a look at how they differ; it’s anonymous classes vs. lambdas or simply put, classes vs. functions.

Functional Interfaces in Java 8

Java 8 treats lambdas as an instance of an interface type. It formalises this into something it calls “functional interfaces”. A functional interface is just an interface with a single method. Java calls the method a “functional method” but the name “single abstract method” or SAM is often used. All the existing single method interfaces like Runnable and Callable in the JDK are now functional interfaces and lambdas can be used anywhere a single abstract method interface is used.

Let’s run through the basic syntax.

Method References in Java 8

Java 8 brings with it method references; shortcuts that you can use anywhere you would use a lambda. The Oracle docs describe four types of method reference but do such a poor job of describing them that I felt compelled to describe them myself.

Yet Another TeamCity Build Monitor

My build monitor is a little different from the rest; it aggregates the status of all the builds on TeamCity to a single visual pass or fail. When build radiators show the status of individual builds on a single page, people can be tempted to ignore specific builds. They learn to ignore that flaky build or disregard the one that they haven’t been working on.

Radiate takes a zero tolerance approach. Every build is as important as the next (else why have separate builds at all?) so Radiate hides which build is actually failing. Red or green, that’s all you get. It’s up to you to investigate the cause.

Currying Functions in Java & Scala

Currying is the technique of transforming a function with multiple arguments into a function with just one argument. The single argument is the value of the first argument from the original function and the function returns another single argument function. This in turn would take the second original argument and itself return another single argument function. This chaining continues over the number of arguments of the original. The last in the chain will have access to all of the arguments and so can do whatever it needs to do.

You can turn any function with multiple arguments into it’s curried equivalent. Let’s have a look at this in action.

Calculate the Optimum Number of Threads

Working out the theoretical optimal number of threads you should use for your application is fairly straightforward. You do, however, need to understand your applications runtime characteristics. Is it mostly occupied with CPU intensive work or is it mostly waiting for IO?

In this post, we look at how to work out a good thread pool size for your CPU and IO based tasks.