Either when looking for work or looking to recruit, I’ve been doing pair tests in one form or another since 2008. I’ve only recently come to the conclusion that they just don’t work. At least not reliably.

I’m left wondering why we still use “pair tests” for recruitment. Is it to see how candidates problem solve? How they’d be to work with? The only way to assess these things is actually to do them. Pair tests are a poor simulation. If you want to see how someone works, work with them. Don’t pretend to work with them.

I have several versions of Java installed on my Mac. Trouble is, I can never remember where any of them are. So switching Java versions using the JAVA_HOME environment variable was always a pain. Then I discovered the handy java_home command.

/usr/libexec/java_home -V

It shows the Java versions are available and where there are. For example, on my machine, the output looks like this.

In the previous post, we looked at implicit parameters; parameters that will be automatically passed values annotated as implicit. In this post, we’ll take a look at implicit functions and how they can be useful to convert things of one type to things of another.

Scala “implicits” allow you to omit calling methods or referencing variables directly but instead rely on the compiler to make the connections for you. For example, you could write a function to convert from and Int to a String and rather than call that function explicitly, you can ask the compiler to do it for you, implicitly.

In the next few posts, we’ll look at the different types of implicit bindings Scala offers and show some examples of when they can be useful.

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.