ANNOUNCING MOCKFN

me.pmatiello/mockfn is a library supporting mockist test-driven-development in Clojure. It is meant to be used alongside a regular testing framework such as clojure.test.

It provides two macros to be used in tests. The first, providing, replaces a function with a configured mock.

(testing "providing"
  (providing [(one-fn) :result]
    (is (= :result (one-fn)))))

The second macro, verifying, works similarly, but also defines an expectation for the number of times a call should be performed during the test.

INJECTING AKKA ROUTERS AS DEPENDENCIES IN A PLAY APPLICATION

Sometimes, an actor can’t keep up with the amount of messages it receives. When work is produced at a faster rate than it can be consumed, the system is in trouble. A bounded mailbox will drop messages that were intended to the actor while an unbounded one will grow until it consumes all the available memory and crashes the application.

If the task being performed isn’t CPU-bound or if there are enough cores available in the machine, a simple solution might be just have enough instances of this stressed actor working in parallel. Akka helps us to implement this by providing routers: actors that proxy, supervise and delegate messages to the child actors it manages. That is, when a mensage is sent the the router, it will be forwarded to one of the managed actors so that it can be properly handled. For the producer originating the messages, nothing changes: it just needs an ActorRef to the router and it can be completely ignorant about the size of the pool of consumers and whether it is pushing work directly to the consumer or through an intermediate.

REQUEST-SCOPED DEPENDENCY-INJECTION IN PLAY FRAMEWORK WITH MACWIRE

Update (09 Jul 2015): This post was written for Play 2.3.x. Since version 2.4.0, dependency injection is supported out of the box in Play through Guice. Also, changes in routing at this version of the framework break the approach described here.

Controllers in Play Framework are usually defined as singleton objects. In fact, Play’s documentation defines a controller as a singleton object that generates Action values and provides an example like the one below:

object Application extends Controller {
  def index = Action {
    Ok("It works!")
  }
}

This kind of design is not without problems. Any dependencies of these controllers must be constructed inside the controller, tightening the coupling between them as the controller must now concern itself with one more aspect of its dependencies, namely, their construction.

DATABASE ISOLATION FOR TESTS IN PLAY FRAMEWORK

Play Framework provides decent support for unit and functional tests. Tests using the WithApplication, WithServer or the WithBrowser abstract classes will bootstrap your application so that configurations are loaded and databases connections are available. Yet, nothing is provided out of the box to ensure that database changes made during the execution of a test will not leak into other tests or into the development environment.

About Play, Slick and specs2

Here, we’ll be using Slick for persistence and specs2 as testing framework, but the general idea should apply to different libraries without any major changes. The use of these libraries with Play is outside the scope of this post, but these links should do a good job at introducing the subject:

USING A DIFFERENT CONFIGURATION FILE WHEN RUNNING TESTS IN A PLAY PROJECT

Play Framework, as of version 2.3.x, typically loads the configuration for your application from conf/application.conf. Although it works as expected, it doesn’t allow for different configurations to be used in different environments unless the file is replaced. This is specially inconvenient when running tests directly from Activator since these tests will be executed against the same database used for running the application in development mode.

Luckily, Typesafe Config and SBT provide all that is necessary to work around this issue cleanly.

FUTURES IN SCALA

Scala 2.10 introduced futures as a convenient abstraction for concurrent programming. Using futures, one can perform a number of computations in parallel for which the result is expected to be available, at some point, in these Future objects.

A result in a Future can be easily retrieved without blocking the execution flow by setting a callback to be invoked once it’s ready:

val fut = future { slowComputation }

fut.onSuccess {
	case result => useSuccess(result)
}

This callback is guaranteed to be executed after the future completes successfully. It’s also possible request a callback to be executed if the future fails with an exception:

A KIND OF INFORMAL INTRODUCTION TO Π-CALCULUS

The π-Calculus is one of many approaches to concurrent computation by the means of formal modeling. Its purpose is to enable us to reason about concurrent processes in a disciplined fashion by manipulating expressions through formally defined algebraic rules.

Any exposition of the calculus will eventually introduce you to the primitive notions:

• Agents, which can be understood and even referred as processes.
• Actions, which are anything that can be done by an agent.
• Channels, which are links connecting agents, alowing them to communicate.
• Names, which are exchanged through channels.

The general idea is that we have a set of agents connected to each other through channels in some sort of network. These agents then use these channels communicate to each other by exchanging names.

IMPLEMENTING INTERFACE CONTRACTS IN PYTHON WITH CLASS DECORATORS

Python decorators are quite useful and interesting. I’ve already written about function decorators in a previous post and class decorators are a worthy followup.

I order to illustrate this feature, we’ll implement support for interface contracts for Python classes. In a language like Java, for instance, a contract can be declared this way:

DEPENDENCY INJECTION IN RUBY AS INSPIRED BY SCALA

A recent discussion in the GOOS’ group has lead me to consider different ways to compose objects in Ruby. Specifically, as module inclusion seems to be the favored approach for adding stuff to classes in Ruby, I’ve became interested in finding a more flexible idiom for this.

The objective, therefore, is to define an instance variable in a module and be able to have it injected in instances of some class. Since I’m not that familiar with Ruby yet, I’m forced to turn to other languages for inspiration. A possible solution in Scala, presented below, is kind of intuitive.

IN WHICH I GIVE MY OWN HALF-BAKED WORKAROUND TO THE LACK OF TAIL CALL OPTIMIZATION IN PYTHON

A tail call is a function call such that it is the last action performed by a procedure. Therefore, the value returned by the caller procedure is the value returned by the called procedure. Many compilers and interpreters take advantage of this situation by using the caller’s stack space to execute the called procedure, instead of allocating more space for it. Because no extra space is consumed by these calls, recursive tail calls can be nested at will without risk of overflowing the stack.