My posterous blog is synesso.posterous.com

Posted via email from Mawson’s Hut

Posted via email from Beavious Grodily Harm

Posted via email from Beavious Grodily Harm

Posted via email from Beavious Grodily Harm

With the PostGIS extension, PostgreSQL has excellent support for calculating the distance between locations, so our calculations were delegated to the SQL queries. Essentially the query joined each location with every other location and excluded those which exceeded our distance threshold (for example, 25,000 metres).

The task was implemented in Rake. The execution time was in the order of 8 hours. It was assumed that the majority of time was needed for Postgres to perform the GIS calculations. Not so.

I reimplemented the task in Scala using Scweery. The Scala version differs from the rake task in several ways. It is strongly typed (as necessitated by the language) and, apart from IO operations, purely functional (my personal preference). It also used JDBC instead of ActiveRecord. Apart from these differences the algorithm is identical to its Ruby counterpart.

So did the Scweery/Scala version outperform Rake? Yes, without a doubt. /usr/bin/time reports that the Scala version was completed in 8m, 55s. That’s at least 50 times quicker. Importantly, it turns what was an overnight task into what is now a coffee break task.

pawn canMove Straight towards Black

Some alternative examples are :

pawn canMove Straight by 2 towards Black

pawn canMove Diagonally towards (Black, King)

With this syntax it is possible to construct executable specifications using Specs that read:

"a pawn that has already been moved and is not blocked" should {
    "be able to move one square towards opposite colour" in {
      pawn canMove Straight towards Black must beTrue
    }
}

Operator notation is what enables the building of this kind of syntax. It is the ability to omit the dot and parentheses on any function call with exactly one parameter. It is not possible to achieve this when there is 2 or more parameters (both dot and parentheses are required) or when there are zero (the parentheses are optional, but the dot is required).

Without operator notation, the initial example above would be written as:

  pawn.canMove(Straight).towards(Black)

Straight-line movement

In order to facilitate this structure, Piece.canMove(m: Movement) implies an instance of CanMove (a case class). CanMove.towards(o: Orientation) decides whether the move can proceed. Both Straight and Black are case objects.

class Piece(val colour: Colour, val role: Role, val position: Position) {
  def canMove[M >: Movement](m: M): CanMove[M] = CanMove(m, this)
}

case class CanMove[M >: Movement](m: M, p: Piece) {
  var dist = 1
  def towards(o: Orientation): Boolean = {
    m match {
      case Straight => p.role match {
        case Pawn => dist == 1 && o.equals(opposite of p.colour)
        case _ => false
      }
      case _ => false
    }
  }
}

At this stage, only the behaviour for “a pawn that has already been moved and is not blocked” has been specified. As such it is a simple case statement. If the movement is Straight and the piece is a Pawn, check that it is trying to move 1 space and that it is moving toward the opposite coloured side.

Diagonal Movement

Queries regarding diagonal movement require additional thought, as the direction is a composite of both Colour (Black or White) and Role with Orientation (Queen or King). In this case, a towards function is provided that takes a Tuple2 of these two parameters.

def towards(o: Tuple2[Colour, Role with Orientation]): Boolean = false

The function currently returns false, because there is no specification written yet that would require it to be true. Following BDD means the simplest possible implementation that would work is in place.

Using a Tuple2 instead of two input parameters permits operator notation to be used. That is, it is a single parameter comprised of two values. Although denoting the tuple does require the use of parentheses and a comma, but I think the effect is still readable.

"a pawn that has already been moved and is not blocked" should {
  "not be able to move diagonally towards black queen" in {
    pawn canMove Diagonally towards (Black, Queen) must beFalse
  }
}

Movement greater than 1 square

In order to support movement in a direction over multiple squares, the CanMove class is provided a by(distance: Int) function that sets the distance on the instance, and returns the instance again for a chained function call.

def by(distance: Int) = {
  dist = distance
  this
}

This permits the interspersing of ‘by n‘ as an optional term. On the downside, it also permits the illogical interspersing of multiple calls to ‘by n‘. Such as:

pawn canMove Straight by 1 by 9 by 4 towards Black

The pawn movement specification for this function utilises ScalaCheck to test a range of conditions of n from 2 upwards. This testing tool executes the specification with 100 arbitrary values of n that are 2 or greater.

"a pawn that has already been moved and is not blocked" should {
  "not be able to move more than one square towards opposite colour" in {
    forAll { n: Int => n >= 2 ==>
            (pawn canMove Straight by n towards Black equals false)
    } must pass
  }
}

Source code

The complete code (as a work in progress) lives on github. I welcome any advice on how to improve the approach I’ve taken.

import sbt._
class SpecsProject(info: ProjectInfo) extends DefaultProject(info) {
  val specsRepo = "Specs Repository" at "http://specs.googlecode.com/svn/maven2/"

  val specs = "org.scala-tools.testing" % "specs" % "1.4.4"
  val scalacheck = "org.scala-tools.testing" % "scalacheck" % "1.5"
  val mockito = "org.mockito" % "mockito-core" % "1.7"
  val junit = "junit" % "junit" % "4.4"
}

I love how Scala lets me code without being force-fed XML everywhere I turn.

I’ve heard good things about two Scala based testing frameworks: ScalaTest and Specs. After some investigation into both I’ve decided to run with Specs. I intend to test in a behavioural manner and so don’t need the flexibility of other testing styles that ScalaTest provides. In my opinion Specs facilitates a cleaner testing style and has really wonderful integration with my preferred mocking library, Mockito. In the end it’s really just a matter of personal preference.

The static call

My first challenge to overcome is the static method call to the Google App Engine’s UserServiceFactory:

UserServiceFactory.getUserService

As it stands, the LoginSnippet object is untestable without including a mocking framework that supports the mocking of static method calls. Whilst Mockito provides simple and elegant mocking, it does not support the mocking of static method calls.

A quick introspection into the UserServiceFactory shows that (as of v1.2.0) the factory method is simply:

return new UserServiceImpl();

But it would be a bad idea to replace the current call to the factory with this instantiation because:

1. it may not be backwards compatible as the GAE SDK is updated;
2. it may not be the same implementation once deployed to the service; and
3. it simply doesn’t work (UserServiceImpl is package private).

At this stage I’m forced to modify my class to facilitate my test. The primary constructor is modified to take an injected UserService. (It makes me cringe a bit to do this, but can it be done without using AOP or a different mocking library? Please fill me in on the secret if you know how).

 1: class LoginSnippet(userService: UserService) {
 2:     def this() = this (UserServiceFactory.getUserService)
 3:     def render(request: _root_.javax.servlet.http.HttpServletRequest) = {
            ... function continues as per my previous post ...
14:     }
15: }

The class definition on line 1 provides a new primary constructor. It now takes a UserService parameter. On line 2 a zero-arg constructor is defined that delegates to the primary constructor. There’s nothing particular to Scala in this scenario. However, it is worth noting that the execution of UserServiceFactory.getUserService now occurs in the constructor. If I needed it to continue to be executed in the render function I could do the following:

 1: class LoginSnippet(getUserService: => UserService) {
 2:     def this() = this ({UserServiceFactory.getUserService})
 3:     def render(request: _root_.javax.servlet.http.HttpServletRequest) = {
 4:         val userService = getUserService

The distinction here is that the constructor now takes a parameter which implies (=>) a UserService. It may be a literal UserService instance (as our test-time mock would be), or it may be a code block that returns a UserService, as can be seen on line 2 (note the added curly braces). If a code block is passed, it will not be executed until invoked on line 4.

Running Specs with Mockito via Ant

As is stands, there is currently a small trick to getting Specs running via Ant. It is clearly documented on their site, but I sometimes have a blind spot when it comes to RTFM’ing. Here it is in a nutshell:

1: import org.specs.Specification
2: import org.specs.mock.Mockito
3: import org.specs.runner.JUnit4
4: class SnippetSpecs extends JUnit4(snippetSpec)
5: object snippetSpec extends Specification with Mockito { ... }

The Specifications must be defined in an object (line 5), but the JUnit Ant task will require a class instance (line 4). The class must be something that JUnit knows how to run and so must extend the Specs JUnit4 runner. Finally, the addition of the Mockito trait (line 5) provides syntactic sugar to sweeten the mocking experience.

In the Ant build.xml the specs are executed with the junit task. The batchtest fileset should include the classes (in my case *Specs) and not the objects (*Spec).

Testing the sign-in snippet with mocks and XML matchers

The sign-in snippet should be shown when we don’t have a currently logged-in user. This forms the basis of my first specification. The task seems simple – ensure the user is null and assert the correct XHTML is returned.

1:  "LoginSnippet with an unknown user" should {
2:      "Provide a login prompt" in {
3:          userService.getCurrentUser returns null
4:          request.getRequestURI returns "requestURI"
5:          userService.createLoginURL("requestURI") returns "loginURL"
6:          val xhtml = snippet render request
7:          xhtml must ==/(<p>Hello! <a href="loginURL">Sign in</a> just for kicks.</p>)
        }
    }

The specification is described on lines 1-2. The mock expectations are established on lines 3-5 (notice how clean the syntax is, thanks to the Specs’ Mockito trait?). The code under test is executed on line 6. The expectation is asserted on line 7.

The expectation makes use of one of Spec’s XML matchers. Matchers are powerful tools for asserting only the aspects of the comparisons that are relevant. In this case, the must ==/ matcher compares the equality of a node sequence whilst ignoring whitespace.

Testing the sign-out snippet – splitting hairs over Atoms

The sign-out snippet seems equally as straight-forward, but there is a catch. My first approach was:

1:  "LoginSnippet with a known user" should {
2:      "Provide a logout prompt" in {
3:          val user = new User("x", "y")
4:          userService.getCurrentUser returns user
5:          request.getRequestURI returns "requestURI"
6:          userService.createLogoutURL("requestURI") returns "logoutURL"
7:          val xhtml = snippet render request
8:          xhtml must ==/(<p>Hello, x! Now you can <a href="logoutURL">sign out</a> again.</p>)
        }
    }

This specification fails! The XML on line 8 seems to be what we are receiving, but the equality matcher failed. After inspecting the returned node sequence closely it seems that the string “Hello, x! Now you can ” is not a single text element, but a chain of text/atom/text. The Atom (the parent class of Text) corresponds to the inlined user name (“x”) and, I assume, indicates that the inlined characters may not be valid XML text, but instead PCDATA or Unparsed.

To make the specification pass, line 8 needed to be modified to:

8:          xhtml must ==/(<p>Hello, {"x"}! Now you can <a href="logoutURL">sign out</a> again.</p>)

Now that I have the behaviour-driven testing essentials under my belt, it’s all go to proceed on adding some features to my application.

I’ve just uploaded a hello world app that is written with a JSP delegating to Scala. (It’s not worth clicking through to, but it is here if you need proof). Here is what I needed to do, once I had signed up and downloaded the SDK.

First you need to create the right project structure. You can get it automagically if you are using the Eclipse plugin, but I find that particular IDE to be a choking hazard. Here’s the structure I created manually.

• project_root
  • src
  • web
    • WEB-INF
      • classes
      • lib

The one-and-only page is the JSP war/index.jsp. It delegates to the Scala class.

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="au.com.loftinspace.scalachess.LoginSnippet" %>
<html>
  <body>
    <h1>Just a test</h1>
    <%= LoginSnippet.render(request) %>
  </body>
</html>

The custom Scala object providing the XHTML snippet to display is defined in LoginSnippet.scala

package au.com.loftinspace.scalachess

object LoginSnippet {
    def render(request: _root_.javax.servlet.http.HttpServletRequest) = {
        import _root_.com.google.appengine.api.users._
        val userService = UserServiceFactory.getUserService
        val user = userService.getCurrentUser

        if (user == null) {
            <p>Hello! <a href={userService.createLoginURL
                (request.getRequestURI)}>Sign in</a>
                just for kicks.</p>
        } else {
            <p>Hello, {user.getNickname}! Now you can
                <a href={userService.createLogoutURL(
                request.getRequestURI)}>sign out</a> again.</p>
        }
    }
}

Scala classes need to be compiled to web/WEB-INF/classes (just as Java classes would). When compiling the class I required the following on the classpath:

• appengine-java-sdk/lib/shared/geronimo-servlet_2.5_spec-1.2.jar (for HttpServletRequest); and
• appengine-java-sdk/lib/user/appengine-api-1.0-sdk-1.2.0.jar (for the User functionality)

Some jars need to be deployed with your application. This simply means placing them in web/WEB-INF/lib. The jars I required were:

• scala-library.jar (for the scala -> java bridging objects you get when scala is compiled, and several classes from scala.xml._ which I have used implicitly by defining the inline XML in the render function).
• appengine-api-1.0-sdk-1.2.0.jar (which surprises me a little, as I thought GAE could provide this itself)

This is a reworked version of login as seen in the SDK’s demo application GuestBook. It is worth noting that the User functionality allows any username when running under the SDK’s development server, but integrates with Google account authentication once published to GAE.

Update: David Pollak – In case you missed it, Lift *does* run on the Google App Engine http://lift-example.appspot.com/index