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.

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.

Automaticaaly rebase your Git repository when you do a pull.

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.

There haven’t been many posts on the blog recently because I’ve been super-busy working on my book Essential Acceptance Testing. It’s published via Leanpub and talks about the typical acceptance testing strategy and how, more often than not, it’s driven by dogma rather than by a genuine testing need.

Acceptance testing in it’s generally accepted form, is so full of duplication and cruft that gaining software confidence can come at a high price. It doesn’t have to be this way. The book talks about how we can reclaim all the good parts of acceptance testing without suffering the long build times and specification overload.

It also talks about when not to bother; how gaining software confidence isn’t always about testing. Fast feedback and writing software that’s cheap to change can be an effective alternative to testing and help shorten the path from concept to cash.

• Show hidden files and folders in Finder
• Show hidden files and folders from an application’s Open dialog
• Remove Duplicate Entries in ‘Open With’ Menu
• Show your workings with Calculator

More as a reminder to myself than anything, here’s a bunch of Git commands I fund useful.

• Create a branch on a remote (pushing a branch to a remote)
• Delete a remote branch
• Switch from HTTP to git/ssh
• Set upstream branch
• Abbreviated status
• Useful Git aliases