logspec: Testing your Scala Logging Output

When things go wrong with your application, the first thing you turn to are your logs. But, even if you use TDD, this is the one thing you are least likely to have tested. This increases the likelihood that your logs may not be anywhere near as useful as you might want them to be.

logspec is a a Scala library I just wrote that allows you to treat your logging as a first-class feature and unit test them.

Read this post

Writing DSLs using Scala. Part II - A simple matcher DSL

This is the second of a two-part series of blogposts that explain how Scala can be used to create powerful Domain Specific Languages (DSLs). Before you read this, please read the first part, where I describe the Scala features that allow us to build these DSLs.

In this post, I shall illustrate how to build a Scala DSL by building a simple matcher DSL that will allow users of the DSL to perform assertions — in essence, a simplified version of a testing DSL like Scalatest or Specs 2.

Read this post

Writing DSLs using Scala. Part 1 — Underlying Concepts

I've been using Scala in (not particularly torrid) anger for around two years now, and the Scala feature I've loved most during this time has been its ability to define concise Domain Specific Languages (DSLs). What got me into Scala in the first place was the fact that it was incredibly easy to write tests in Scala that looked for all intents and purposes like a Gherkin spec.

So in this series of blogposts, I am going to attempt to illustrate how you can write a simple matcher DSL. In the first part of the series, I'd like to illustrate some of the Scala features that allow us to build these powerful DSLs.

Read this post

Dr. Rajagopal: my person of the year, every year

In 2013, cancer served my father with a death sentence. My father was a stoic man, and he took his diagnosis with the same equanimity and calm that he'd lived his whole life with. He merely wanted to die with his dignity intact, just as he had lived.

The doctor at the private cancer institute we ended up in — purportedly one of the best in India and among the best in the world – assured him of a good quality of life. He was wrong, not that he cared.

He has come in my mind to represent the debauched, materialistic mentality that drives privatised healthcare.

But as the end approached, we met Dr. Rajagopal who told us about palliative care, and how people did not have to die in pain with tubes strapped to every orifice. India's healthcare system has no space for palliative care; it's far more profitable to extend people's lives out for as long as is possible.

Dr. Rajagopal refused to accept payment; he told me he prefered people to donate, as most of his patients could not afford to pay in any case. Dr. Rajagopal was always happy to pick up the phone and listen to my concerns. He was never rude or short, but he never gave me false hope.

Thanks to Dr. Rajagopal, my father's last days were spent in bed, at home. Thanks to Dr. Rajagopal, he suffered not the humiliation of tubes and ventillators strapped to him. Thanks to Dr. Rajagopal, he was allowed to die as he lived; with dignity.

Dr. Rajagopal has been nominated for the CNN-IBN Indian of the Year award. Please cast your vote for him here, and consider donating to Pallium India.

Read this post

Matching Functions as arguments and varags using Mockito and Scala

Having spent all morning fighting through the vagaries of mocking and verifying methods that take functions as arguments and variable arguments using Scala and Mockito, I thought I'd scribble this down (mostly for myself, as I'll probably hit this selfsame problem again at some point in the future).

The Problem

Let us assume you have a class FooService, which has a method, quite unimaginatively called getBar that takes a function (Int, Int) => Int and a variable number of additional arguments.

class FooService {
    def getBar(baz: (Int, Int) => Int, args: Any*): Int = {
        //...does stuff with baz and args

Let us also assume that we have a class Foo that calls FooService in one of its methods that we needed to test:

class Foo(fooService: FooService) {
    def doImportantThings(arg1: Int, arg2: Int) {
       vall bar = fooService.getBar(add, arg1, arg2)

    private def add(x: Int, y: Int): Int = {
        return x + y;

The problem is:
* We want to write a unit test of Foo that mocks FooService * We want to verify that FooService.getBar is called using the right arguments.

The Solution

I have outlined the solution in this Scalatest Snippet. To match the varags, we need to use a VarArg Matcher

import org.mockito.Mockito._
import org.mockito.Matchers._
import scala.collection.mutable

"The Foo class" should "do the things that the Foo class does" in {
    val mockFooService = mock[FooService]
    when(mockFooService.getBar(any[(Int, Int) => Int].apply,

    val underTest = new Foo(mockService)

    verify(mockFooService).getBar(any[(Int, Int)=> Int],
        argThat(new VarArgMatcher(Array(20,21))))

class VarArgMatcher(expected: Array[Int]
    extends ArgumentMatcher[Array[AnyRef]] {
       override def matches(argument: AnyRef): Boolean = 
        argument.asInstanceOf[mutable.WrappedArray[AnyRef]].forall {
            actual =>

I'm not going into the detail of what this code does, and hope it's self-explanatory.

Read this post

Customising Facebook share content on Ghost

In this post, I describe how to fix your Ghost posts so that the descriptions in your Facebook shares aren't irrelevant and unreadable.

Read this post