An abbreviated set of JMock examples with their Scalamock equivalents.

If you’ve just started to learn Scala and are wondering what to expect, it’s typical to experience a quick ramp up in skill followed by a slower adoption of the more sophisticated features. In this post, I talk about what I think of as a typical learning curve.

Taken from my Pluralsight course, the chart shows experience (or time) along the x axis and some measure of “learning” on the y.

Scala traits are interesting because they can be used for inclusion polymorphism and to mixin behaviour. I’ve found tension here though, as the former uses inheritance and the later is more about code re-use. So when a Scala class extends a trait with behaviour, it seems to go against the generally accepted view that using inheritance as a mechanism for code re-use is a bad idea.

It can be tricky not break the inheritance vs. composition principle when using traits with behaviour. Is it clear to you when you might be?

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.

I’ve just published my course on Java 8 over at Udemy.com, for a limited time only, get 10% off with coupon code BLOG10!

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.

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.

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.

Despite IntelliJ’s improvements to retina support, IDEA still looks shabby when running a retina display with the JDK 7 and 8. See for yourself below.

Running on JDK 6 Running on JDK 7

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.