Author Archives: shane

String Calculator for Scala

This is a slight repurposing of the String Calculator kata on Roy Osherove’s website. I’ve updated it for my own impression of TDD, and for Scala notation and types, but many of the words are still arranged in Roy’s order. read more »

Keep controllers clean with custom action builders

When writing controllers, there are often elements that are needed over and over again. Maybe you always seem to be getting the same objects from a repository, or you want to do authentication. Repeating simple operations like these leave controller actions bloated, and hard to read. Play Framework offers a simple and powerful way to abstract these repeated elements.

read more »

Play DI: compile time versus runtime

Scala’s Play Framework provides a runtime dependency injection mechanism by default, courtesy of Google Guice. The framework is built with flexibility in mind however, and so allows developers to replace the default application loader with a custom one that allows dependencies to be resolved at compile time. More details on this technique can be found here.

For the last couple of weeks, basically since reading Loïc’s blog post, I’d been working under the impression that compile time DI is a safer, and therefore better, approach. Having just spent a rather unhappy day trying to functionally test non-trivial implementations, I’m no longer convinced. In this post, I’m going to put forward my arguments for both cases in the hope that it will help me make up my mind.

read more »

Sorry, I can’t do that, I’m not agile

Inviqa’s dev days are always excellent events with a high level of content quality. One particular talk stood out for me at today’s event, which was Stephen McNairn talking about his take on the agile manifesto and how he’s seen Inviqa’s approach to agile develop over the years that he’s been with the company. One particular point really struck a chord with me, and that was that we might not always be as agile as we would like to think. What follows is my take on what Stephen said, and the majority of the text is only my interpretation of his original point.

read more »

Getting mad and sad

When I’ve attended retrospectives where activities such as Mad/Sad/Glad or Liked/Learned/Lacked/Longed for are used I’ve noticed that attendees often express confusion about what seems like two negative states. Mad and sad both suggest a negative influence has occurred, as do lacked and longed for.

When I planned my recent retrospective I deliberately avoided this confusion by making my emotive states liked, loathed and learned. While this did work, and the team seemed very comfortable with the differences between states, I’m starting to think that there is an argument in favour of a bit of confusion. read more »

Don’t be afraid to have fun

Sometimes an idea just pops into my head, and it’s so absurd that I immediately dismiss it. Sometimes I’ve had a couple of beers, and so I don’t dismiss it quite as quickly…and that’s a very good thing. read more »

Add value to legacy code using agile tools

Working with legacy code need not be the nightmare it is often portrayed as. Tools that are considered best practice for greenfield development can and should be used to support legacy codebases, and prepare them for new development to begin.

read more »

phpspec keeps your privates hidden

For the last few days I’ve been using phpspec to build an application. Inevitably comparisons will be drawn between phpspec and PHPUnit, but I think that one clear distinction is found by considering how phpspec prevents the direct testing of a private method. read more »

Considering what to test with phpspec

I have recently started using phpspec in place of PHPUnit as a PHP development tool. So far for me, the transition from TDD to specBDD is a fairly trivial one. The vocabulary used in the specs is slightly different to xUnit tools, and this seems to make me think more carefully about what I really want to test, or better, what behaviour I want my object to exhibit. read more »

Integrating Behat and Mink with JenkinsCI

Continuing on the theme of my previous two posts, I’ve finally got around to getting some test results from Behat into Jenkins. The tests I’ll implement in this post are pretty simplistic acceptance tests against a pre-populated server, testing against a server populated by the Jenkins job will have to wait for another time. read more »