Scala, come out and Play

Last week I started work on a Play 2.1 Scala project, which is a nice departure from Spring and Hibernate, so it’s a good time to share some first thoughts on the differences between the old traditional Java webapp, Grails, Rails and Play 2.1 with Scala.

First off, installing Play is easy as pie. Most modern frameworks can create a skeleton app quite easily, however the integration with sbt feels a bit awkward but is still much better than good ol’ Maven. Re-compiling scala files can seem to take awhile, but running tests are nice and quick in IntelliJ.

IntelliJ is a great choice for Scala/Play projects, as v12.1 has excellent auto-completion, syntax highlighting and click-through method links and good test integration. The contextual help is quite good at telling you what’s wrong – this seems to be a strength of the Scala compiler. However, for whatever reason we spent some time trying to get IntelliJ to register our Play app as such when importing the project. Possibly because the /app folder wasn’t off the root of the repository, (we have it in /play/app) but even after running play idea to generate the necessary project files, IntelliJ refused to import it as a Play app.

After upgrading the Play plugin, installing a Scala plugin and ensuring Scala, Play and Java were all in the path and had appropriate %_HOME directories set, it still wouldn’t give in. Creating a new Play app from IntelliJ seemed to bootstrap it with the necessary vision it needed, and after doing this, it imported our existing app no worries.

Be careful as lots of documentation on the web is disinformation, since Play 1.0 is different, and Play 2.1 have made some refinements from previous revisions. Also the fact that we are using Specs2 means you have to sanity check all blog posts and stackoverflows before assuming they are correct for you.

Testing in Scala is beautiful and clean, feels natural and all the crazy syntax of Mockito in Java seems to have been repaired. Specs2 reminds me more of RSpec or Jasmine Specs, which make it easier to read and group similiar tests.

Scala as a language feels quite wierd. Ruby and underscore.js already have nice functional methods like reduce, map, filter which are pretty straight-forward. Things I like are the Option class and the case matching aspects. Like any new framework (and language) you can get stumped and need a good reference on how to do things the idiomatic way.

Scala templates have been carefully designed with a set of opinions and good conventions (such as auto-escaping and immutable parameters, and the ability to create templates and helpers which have multiple closures as parameters changes the way you can call templates.

As an example:

To get all the goodness I am used to in other projects, I created a @toggle macro, which takes in a single String parameter, followed by 2 closures (one to render when enabled and, you guess it, the other to render when disabled).

Place the following in the directory views/helpers/toggle.scala.html as a helper template:

@(toggle: String)(enabledContent: Any)(disabledContent: Any)

@import play.api._

@defining(Play.current.configuration.getBoolean("toggles." + toggle)) { toggleValue =>

  @toggleValue match {
    case Some(toggleEnabled) => {

      @if(toggleEnabled) {
          @enabledContent
      } else {
         @disabledContent
      }

    }
    case None => {
      <h1> Error invalid toggle specified: @toggle</h1>
    }
  }
}

Then simply set a value in conf/application.conf ie.

toggles.search_box=true

Where you want to switch the behaviour (in a Scala template), do the following:

  @toggle("search_box") { 
    <label>Search:<input type="text" id="search"></label>
  } {
    <div>Search is currently disabled</div>
  }

Additionally, Play allows you to toggle the value in the application.conf file dynamically, no restart needed =)

Ruby and Groovy vs. Java

This is why I like modern languages… a good developer knows what he is doing and writes tests anyway, so we don’t need mountains of syntax to provide compile-time safety.

Imagine you are a development manager looking at this:

Ruby

def get_types
  words.collect{|word| word.word_type}
end

15 seconds to code.
3 seconds to read and understand.
Easy to read = self documenting.
Less LOC = better codebase and more agile team.

Java

public List get_types {

  List word_types = new ArrayList();

  for (Word word : words) {
    word_types.add(word.getWordType());
  }

 return word_types;
}

1:10 seconds to write.
8 seconds to read… harder to interpret.

Which is leaner and meaner?

Java – stop making me think for simple operations!

Why branches are bad

Ok i’m not going to beat around the bush with a long intro into source control, why we use it, etc. Branching, in source control systems, means to fork/split development concurrently in 2 branches of code, from a common root.

This is bad. Why? If you consider that you should commit your changes to source control often, which is a recommended practice, then you should

    fear

huge change merges, since they should be seldom. How does this relate to branching?

Branching is most commonly done for 2 reasons. a) because you want to push hotfixes/patches of the current production build out, at a moments notice and you may introduce incompatible changes into your main line of source control during an iteration of development. So you can do branch development (iterations on the branch, merged when you deploy to production at the end of an iteration), or do main line development where you create a branch for every production release (any hotfixes are released on the branch – merge changes at the same time).

The problem here is an iteration may be 1 week, 2, or 4, or 8 or 12 weeks! How can you assume you will be able to safely merge two versions of code modifies over 12 weeks? You can’t (or you wouldn’t want to!) Merging big change sets of code is a bad practice, is error prone, and is basically begging for something to break.

It is also a hassle for planning of releases, for developers and testers alike – “what version of code am I testing?” “which project/branch do I check into?” the list goes on. It also introduces more context-switching, which we know wastes time. For an analogy of context-switching, consider the ALT-TAB to switch processes in Windows, imagining it takes 15 minutes each time… ouch!

So what is my grande opinion? Don’t branch? Well no. That’s purist talk. But almost 🙂 Branch seldomly, and don’t branch for long (eg. 2-3 days until a week, preferably merging changes daily or whenever possible.)

But why branch at all? Ideally, you don’t need to maintain a branch, if you hide your new features perfectly with feature tagging and ensure continuous integration and continuous delivery then there is no need.

But sometimes, yes sometimes, there are fundamental changes (to a horizontal layer in the code) which cannot be controlled by feature tagging or configuration options, or in a case where old feature set cannot compatibly co-exist with new feature set as they conflict. Here you need a branch 😦

The only other time I can consider branching valid is if you are branching without the intention of merging back, but want to maintain a compatible root (eg. if you fork development to experiment in adding some features, prototyping etc).

Anyway, hope that’s shed some light on souce control branching in a realistic manner.