Scala, Javascript vs Craftsmanship

Git changelog

For a couple days I have needed to tell the team the changs contained in the last release of the backend code. Since each of our releases are tagged automatically thanks to our [painless-sbt-build] this is fairly straightforward. Today I automated a little bit more with 3 aliases added to my ~/.gitconfig :

  • git currrent-tag looks up the latest tag in the repository
  • git previous-tag looks up the tag immediately before the latest tag in the repository
  • git changelog displays only the changes between these two tags

The code for the aliases:

current-tag= describe --abbrev=0 --tags
previous-tag= "!sh -c 'git describe --abbrev=0 --tags $(git current-tag)^'"
changelog = "!sh -c 'git --no-pager lg --first-parent $(git previous-tag)..$(git current-tag)'"

Painless release with SBT

As a developer, the only version which really matters is the SHA-1 of the commit from which a deployed artifact was built. It lets me quickly get the source code for this artifact back if a patch is needed. However as a project stakeholder, I need human understandable versions to provide to users. by human understandable I mean strictly increasing and possibly semantically versioned.

In this article I am going to detail an SBT combo allowing for SHA-1 based continuous delivery to an integration environment. The combo then allows to easily promote from this integration environment to QA, PreProd and Production platforms, creating a human understandable version in the process.

  • edit – Added missing bumper function for release version
  • edit – Bump sbt-git version, drop corresponding obsolete code (as it fixes #89 and #67)
  • edit – mention ExtraReleaseCommands.initialVcsChecksCommand based on a suggestion from the comment section

Improve your 'Test-First' experience with Intellij IDEA

I recently helped friends create a koans-based exercise to introduce people to CQRS and event sourcing1. I was tasked with creating the Java version of the exercise. Since the whole exercise was going to depend on the quality of the tests, we applied a test first approach.

I found it quite painful as I didn’t see an obvious way to actually create a test without already having the corresponding class. I was able to create an empty class but it would force me to write a lot of boiler plate manually (all the test annotations and all the static imports manually).

I happened to discuss this with Yann Cebron from Jetbrains at Devoxx France who showed me a neat trick using file templates2.

If you go to the project tool window, select a package in the test folder and try to create a new file with the default configuration, you should see something like this : a screen capture of the new file menu in Intellij

That’s a lot of templates and there is nothing to create a Junit4 test, lets create one.

Select edit file templates... and you will reach a window with a green + sign click that, name it Junit4 and paste the following code (or your own variation thereof) :

#if (${PACKAGE_NAME} && ${PACKAGE_NAME} != "")package ${PACKAGE_NAME};#end

import org.junit.Test;
import static org.junit.Assert.*;

public class ${NAME} {
  public void test_${NAME}() throws Exception {


Now save this and go back to the project tool window, select a package in the test folder and try to create a new file again. This time you should see the Junit4 template.

This is nice and nifty but it can still be improved : there is an Intellij action called from template (you can find it with find action... which is cmd+shift+a on mac)

Using this action only custom templates applicable will be displated, in a test directory for a mixed scala/java project it will show a much smaller menu making it even easier to create your test first.

a screen capture of the `from template` menu in Intellij

  1. You can find the exercise at 

  2. This feature has been broken in a few Intellij builds and the user templates wouldn’t show up in the menu, see the corresponding issue on youtrack

Refactorer Future[Option[T]] : OptionT de Scalaz

Dans les précédents articles, nous avons étudié 3 refactorings permettant d’améliorer la lisibilité de code manipulant le type Future[Option[T]].

L’application du principe de séparation des responsabilité a permis une première amélioration, l’utilisation d’exceptions métier est une solution dans certains cas mais sacrifie une partie de l’information de typage.

Finalement l’utilisation d’un type ad hoc composant les propriétés d’une Future et d’une Option s’est avéré être un parfait complément à la séparation initiale.

Le seul défaut de cette dernière approche est le besoin de maintenir ce type et de construire un nouveau type pour chaque nouvelle composition: FutureO (Future et Option), FutureL (Future et List), etc. Ces types ne sont pas spécifiques à un projet et idéalement devraient être extraits dans une bibliothèque. Il s’avère qu’une telle bibliothèque existe déjà.

Dans cet article, le dernier de cette série, je vous propose un refactoring utilisant les MonadTransformer de Scalaz 7.x.