Dealing with invalid Input

Recently I’ve been discussing about unit-tests and contracts, and the question arose if mechanism existed that would check at compile-time whether a value satisfied a certain condition or not.

This is a difficult question and no doubt a hot topic in computer-science research.

My intuitive answer would be: no. There can’t be such a mechanism, especially if those values are coming from sources we can not control. For example: user input, reading from a file, from a database, from a web-service, etc.

Since those values will be known at run-time, we are forced to deal with them at that stage. However, we can use our faithful assistance the compiler to remind us (even force us) to deal with these cases.

What do I mean? If we can model the situation where value is either valid or not with the type-system then we’ll have all the compiler assistance we want.


In Scala this is easily doable and in fact already part of the standard library. But nothing prevents it from being implemented in other languages as well (how easy or difficult this would be, is another question).

In this post I want to show you how to use Scala’s mechanisms to safely parse an Int, and how to guarantee at compile-time that it will be a positive Int.

Continue reading

Can Contracts replace Unit-Tests?


What are “contracts”? Contracts are the key element in the design-by-contract technique, natively supported by the Eiffel programming language.

They allow operate at many levels:

  1. methods: as pre- and post-conditions
  2. classes: as class invariants
  3. loops: as loop variants/invariants

In this article we shall only consider method pre- and post-conditions. That means, before method execution the pre-condition is checked and after the method is finished (upon completion) the post-condition is checked.

It’s an automatic runtime-enforced form of defensive programming. Recently I started debating with an Eiffel expert about unit-tests vs. contracts, his points being that contracts offer a superior mechanism over unit-tests. That discussion lead me to analyse his claims and write this article.


So the question is: can contracts replace unit-tests?

Continue reading

Integrating Cucumber and Play

In this post I want to show you how to integrate Cucumber into a Play (2.2.3) application.

It assumes some previous Play experience and that you know what Cucumber is about.

The example is minimal, but hopefully it is enough to get you started for bigger projects.

Setting up the SBT Plugin

Let’s start by setting up the SBT plugin. Add to “project/plugins.sbt” the following lines:

resolvers += "Templemore Repository" at ""

addSbtPlugin("templemore" % "sbt-cucumber-plugin" % "0.8.0")

This will make it possible for SBT to find and load the plugin. However, your project still lacks the corresponding settings (refer to the official page for a complete list). For this tutorial, we’ll be overriding some defaults. Add these lines to your “build.sbt”:


cucumberFeaturesLocation := "./test/features"

cucumberStepsBasePackage := "features.steps"

Continue reading

Scaladin chat demo in a Vaadin/Eclipse project

In this post I’m going to show you how to integrate a Scaladin project into an Eclipse-generated Vaadin setup. The demo I’ll be using is a small but impressive one: it uses Vaadin’s Atmosphere-poweredserver-push” and Akka-Actors (disclaimer: I don’t take credit, since I did not write the demo).

I like Scala, Vaadin, and find the idea of Scaladin excellent (to be able to code for Vaadin using idiomatic Scala). There is a SBT plugin for Scaladin, which integrates very well with this build tool. On the other side, the benefits of the Vaadin plugin and IDE integration are lost: like debugging in Eclipse, for example.

What I set up to do was modify the IDE-generated Vaadin project until:

  • Scala was supported
  • Scaladin was supported

As an excercise I “ported” (actually more like “copy-pasting”) the existing “Scaladin Chat demo” to the IDE-generated default setup.


Here’s what I did…

Continue reading

Scala Beginners: counting words and lines

A simple command-line tool

At work, I’m teaching one intern and one colleague how to program.

I gave them the following exercise:

Write an utility that takes 3 command-line parameters P1, P2 and P3. P3 is OPTIONAL (see below) P1 is always a file path/name. P2 can take the values:

  • “lines”
  • “words”
  • “find”

Only P2 is “find”, then P3 is relevant/needed, otherwise it is not.

So, the utility does the following:

  • If P2 is “rows” it says how many lines it has
  • If P2 is “words” it says how many words it has (the complete file)
  • If P2 is “find” it prints out the lines where P3 is present

Continue reading

P07 – Flatten a nested list structure

Peter not only offers you one but three solutions in Clojure.

Clojure recursive:

(defn flatten-recur
  "P07 (**) Flatten a nested list structure."
  ([xs] (flatten-recur [] xs))
  ([acc xs]
      (seq? xs) (conj acc xs)
      (if (empty? xs)
        (-> (flatten-recur acc (first xs))
            (flatten-recur (rest xs)))))))

Clojure de-structured:

Continue reading

P05 – Reverse a List

Clojure – recursive:

(defn my-reverse [xs]
  "P05 (*) Reverse a list"
  (loop [ret [] xs xs]
    (if (empty? xs)
      (recur (cons (first xs) ret) (next xs)))))

Clojure – with reduce:

(defn my-reverse-reduce [xs]
  "P05 (*) Reverse a list"
  (reduce #(cons %2 %1) '() xs))

Scala – recursive:

def reverse[T](list: List[T]): List[T] = {
  def helper(remaining: List[T], reversed: List[T]): List[T] =
    remaining match {
      case Nil => reversed
      case first :: rest => helper(rest, first :: reversed)
  helper(list, Nil)

Scala – with folding:

def reverseFolding[T](list: List[T]): List[T] =
  list.foldLeft(List.empty[T])((result, element) => element :: result)