Byjean

Scala, Javascript vs Craftsmanship

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)

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} {
  @Test
  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 http://github.com/devlyon/mixter.

  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.

Refactorer Future[Option[T]] : la composition par un type ad hoc

Dans les précedents articles, nous avons étudié comment améliorer la lisibilité de code manipulant le type Future[Option[T]] en appliquant le principe de séparation des responsabilité et en utilisant des exceptions métier.

Ces deux approches, relativement simples ont toutes deux montré des limites: la première mélange le traitement de cas d’erreurs avec le traitement de cas normaux, la seconde perd de l’information au niveau du système de type et nécessite une connaissance de précise de l’implémentation ou une documentation détaillée pour pouvoir être correctement manipulée.

Dans cet article je vous propose d’explorer une piste proposée par la programmation fonctionnelle: la composition du type Future et du type Option dans un type ad hoc.

Refactorer Future[Option[T]] : Les exceptions business

Dans le précedent article, nous avons vu comment mitiger les effets des signatures de type Future[Option[T]] sur la lisibilité du code. L’extraction d’un ResultMapper et l’utilisation du pattern matching ont permis de séparer les différentes problématiques du code initial.

En conclusion je faisait remarquer que la répartition des traitements succès/erreur dans le mapper était suspecte. Elle devient problématique lorsque vous voulez coordonner plusieurs appels à des services ayant ce type de signature, le happy path est alors pollué par l’extraction des valeurs dans les couches successives de type conteneurs.

Je vais maintenant montrer que l’utilisation d’exceptions métier est une façon de regrouper les cas d’erreurs dans le même bloc et de conserver un happy path simple.