Jean-Christophe Gay

Migration de Pelican vers Hugo

Sun, 20 Oct 2019 11:35:00 +0200

Retour sur la migration d’un blog construit avec Pelican pour un site statique généré avec Hugo.

Ça fait un moment que je n’ai pas posté ici. Pour le dépoussierage je reviens sur la migration du générateur de ce site.

J’utilisais Pelican depuis plusieurs années. Récemment j’ai réinstallé ma machine, j’avais bien entendu sauvegardé l’environnement virtuel qui me servait à générér mon site mais au moment de le restaurer je me suis dit que c’était le bon moment pour changer.

J’ai souvent eu des problèmes avec la gestion de mon environnement Python (pour tout dire ce n’est vraiment pas ma zone de confort, et je n’en touche que très rarement…), que ce soit à cause des chemins vers mes installations de Python ou bien à cause des mises à jour de Pelican et de ses dépendances. Du coup je surveille ce qui se passe un peu dans l’univers des générateurs de site et je suis resté bloqué sur Hugo et Gatsby.

Les deux semblent assez populaires et assez similaires en terme de fonctionalités. Comme je suis bien plus à l’aise avec Go qu’avec l’écosystème React le choix a été assez facile 😇.

Ce qui m’a encouragé à migrer est que pour utiliser Hugo il suffit d’utiliser un binaire tout en un. Pas besoin de gérer x dépendances 🚀. C’est donc plus simple de reproduire la génération de son site dans le temps.

Installation
#

Il a suffit de suivre le guide d’installation soit sur macOS un simple :

brew install hugo

Puis de générer la structure du site (dans le dossier existant) avec :

hugo new site jeanchristophegay.com

Theme
#

J’ai choisi Beautiful Hugo pour le moment.
L’installation a été rapide en suivant les simples étapes de la documentation.

Migrer les articles
#

Les articles sont déplacés dans le dossier content/posts pour respecter la structure d’Hugo.
Les images sont maintenant dans static/images pour ne pas devoir réécrire les URL.

Les articles sont déjà rédigés en Markdown, il faut donc s’occuper de convertir les métadonnés et les quelques balises spécifiques à Pelican.

Les métadonnées de Pelican ressemblaient à :

Title: De la couleur dans les logs
Date: 2013-05-04 18:22
Category: java
Tags: ansi console, grep console, jansi, log, log4j, log4j 2, logback
-Slug: de-la-couleur-dans-les-logs
-Author: Jean-Christophe Gay
-lang: fr
disqus_identifier: 213 http://jeanchristophegay.com/?p=213

Pour Hugo, il faut les transformer en :

---
title: "De la couleur dans les logs"
date: 2013-05-04T18:22:00+02:00
aliases:
 - /de-la-couleur-dans-les-logs/
slug: de-la-couleur-dans-les-logs
categories:
 - java
tags:
 - ansi console
 - grep console
 - jansi
 - log
 - log4j
 - log4j 2
 - logback
disqus_identifier: "213 http://jeanchristophegay.com/?p=213"
---

Toutes les options possibles sont listées dans la documentation.

L’attribut aliases est bien pratique pour conserver les anciennes URL générées par Pelican.

Pelican : https://jeanchristophegay.com/de-la-couleur-dans-les-logs/ Hugo : https://jeanchristophegay.com/posts/de-la-couleur-dans-les-logs/

La balises  qui permettait de délimiter le résumé d’un article est remplacé par .

Pour le moment j’ai perdu la table des matières, apparemment certains thèmes permettent d’en générer une mais je n’ai pas encore essayé.

Pour les articles disponibles en plusieurs langues, pas besoin de metadonnées, le suffixe dans le nom de fichier est suffisant.

Configuration
#

Site
#

La configuration se déroule dans un fichier config.toml à la place de pelicanconf.py et publishconf.py. On y retrouve un peu le même genre d’options que dans Pelican.

Pour exemple voici à quoi ressemble le mien à ce jour :

baseURL = "https://jeanchristophegay.com/"
languageCode = "fr-FR"

title = "Jean-Christophe Gay"
theme = "beautifulhugo"
disqusShortname = ""
googleAnalytics = ""

enableEmoji = true
enableGitInfo = true
enableRobotsTXT = true

DefaultContentLanguage = "fr"
[languages]
 [languages.fr]
 weight = 1
 [languages.en]
 weight = 2

[[menu.main]]
 name = "Home"
 url = "/"
 weight = 1

[[menu.main]]
 name = "Tags"
 url = "tags"
 weight = 3

[Params]
 subtitle = "Développeur"
 mainSections = ["post","posts"]
 logo = "https://www.gravatar.com/avatar/5cee6a7b8d17e4a0f367a5f0e237c694?s=200"
 dateFormat = "2 Jan 2006"
 rss = true
 comments = true
 readingTime = true
 wordCount = false
 socialShare = true
 delayDisqus = false
 showRelatedPosts = true
 
[Author]
 name = "Jean-Christophe Gay"
 website = "jeanchristophegay.com"
 email = "contact@jeanchristophegay.com"
 github = "jcgay"
 gitlab = "jcgay"
 twitter = "jchristophegay"
 linkedin = "jcgay"

Coloration syntaxique
#

Elle s’active dans la configuration :

pygmentsCodeFences = true
pygmentsUseClasses = true

Et il faut ensuite générer le style avec la commande :

hugo gen chromastyles --style=trac > static/css/syntax.css

J’ai activé le rendu côté serveur mais on peut aussi utilisé une version déportée dans le navigateur avec ce thème.

C’est un point qu’il faut que je creuse encore un peu parce qu’en l’état le rendu n’est pas optimal, quand un bloc de code est un peu trop large on ne peut pas scrollé horizontalement… 😅

Commentaires
#

Les commentaires du blog étant hébergés sur Disqus, la migration s’est bien déroulée.
Il a suffit d’utiliser les bons disqus_identifier pour chaque article. Par contre au départ j’avais utilisé l’option delayDisqus = true pour ne pas charger les commentaires par défaut (ça alourdi pas mal les pages de charger Disqus) mais cette option ne respecte pas par la suite les disqus_identifier définis… Ce qui rendait la récupération des anciens commentaires impossibles.

Un de ces jours je jetterai un oeil aux alternatives disponibles 😇.

Redirections
#

La possibilité de définir des alias pour chaque article a été suffisant pour gérer la migration des URL des articles, les ressources statiques n’ont pas bougées. J’ai ajouté de nouvelles règles uniquement pour les flux RSS :

RewriteRule feed/?$ index.xml [R=301,L]
RewriteRule feeds/? index.xml [R=301,L]

Prévisualisation
#

Pour voir le rendu de ce qu’on est en train d’écrire :

hugo serve

Le contenu se recharche bien entendu à chaud.

Génération du site final
#

Le site prêt à déployer est disponible dans le dossier public après avoir lancé :

hugo

Conclusion
#

En 3 ou 4 heures j’ai réussi à avoir un rendu de mon blog à peu près équivalent au précédent.
Je ne pensais pas que la migration se passerait aussi facilement 😎.
Il reste 2 ou 3 réglages à faire mais je suis bien content de ne plus avoir à me compliquer la vie pour avoir un environnement stable Python pour générer ce site 🎇.

Utiliser une propriété unique comme version Maven

Fri, 02 Sep 2016 20:49:00 +0200

Quand je travaille sur un projet Maven multi-modules (plusieurs dizaines) sur plusieurs branches en même temps, je me retrouve souvent avec des conflits à résoudre pour chaque merge sur les versions définies un peu partout dans les pom.xml… Et c’est tout sauf marrant.
Tour d’horizon des solutions pour réduire le nombre de <version> déclarées dans tous ces pom.xml.

Notre projet exemple de départ est donc constitué de deux modules :

.
├── pom.xml
├── submodule-1
│   └── pom.xml
└── submodule-2
    └── pom.xml

Le pom.xml du projet parent ressemble à :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>1.0-SNAPSHOT</version>
 <packaging>pom</packaging>

 <modules>
 <module>submodule-1</module>
 <module>submodule-2</module>
 </modules>
 
</project>

et ceux des modules :

<project>
 <parent>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>1.0-SNAPSHOT</version>
 </parent>

 <artifactId>submodule-1</artifactId>

</project>

La version du projet est répétée dans chaque pom.xml des modules, pour les changer ce n’est pas bien compliqué avec le plugin Versions. Par contre les merges entre branches sont vite pénibles, les conflits sont fréquents et généralement on ne peut pas se contenter de ne garder les changements que d’une des deux branches 😓.

Définir la version dans une propriété
#

Première tentative, extraire la version dans une propriété Maven. Le pom parent devient donc :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>${my-version}</version>
 <packaging>pom</packaging>

 <properties>
 <my-version>1.0-SNAPSHOT</my-version>
 </properties>

 <modules>
 <module>submodule-1</module>
 <module>submodule-2</module>
 </modules>

</project>

et un module utilise également la propriété ${my-version} pour référencer son parent :

<project>
 <parent>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>parent-pom</artifactId>
 <version>${my-version}</version>
 </parent>

 <artifactId>submodule-2</artifactId>

</project>

Etonnement ça fonctionne 😲
La seule arnaque provient des messages d’avertissements affichés par Maven.

Some problems were encountered while building the effective model for com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

Some problems were encountered while building the effective model for com.github.jcgay.example.version:submodule-2:jar:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

Some problems were encountered while building the effective model for com.github.jcgay.example.version:parent-pom:pom:1.0-SNAPSHOT
'version' contains an expression but should be a constant. @ com.github.jcgay.example.version:parent-pom:${my-version}, /Users/jcgay/dev/toolbox-examples/unique-maven-version/pom.xml, line 7, column 14

It is highly recommended to fix these problems because they threaten the stability of your build.

For this reason, future Maven versions might no longer support building such malformed projects.

En l’état ce n’est pas vraiment sérieux, et puis il y a un autre problème avec cette solution mais on va la détailler dans la seconde.

Continuous delivery friendly version
#

Depuis Maven 3.2.1 il est possible d’utiliser des propriétés réservées pour éviter les messages d’avertissements précédents.

Si on remplace notre propriété my-version de la solution précédente par une autre nommée revision, plus de messages qui font peur 🎆.

Seulement utiliser des propriétés plutôt que des versions stables pose réellement un problème. Quand Maven installe dans le repository local ou déploie dans un repository distant nos artifacts, les pom.xml sont copiés en l’état. Si on a donc un projet qui dépend d’un de nos modules (comprendre qui n’est pas construit dans ce même projet multi-modules), la résolution des dépendances échouera car la propriété ${revision} n’existera pas dans ce projet extérieur.

Exemple avec ce projet tout simple qui n’est pas un module de notre parent-pom :

<project>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>independant-project</artifactId>
 <version>1.0-SNAPSHOT</version>
 
 <dependencies>
 <dependency>
 <groupId>com.github.jcgay.example.version</groupId>
 <artifactId>submodule-1</artifactId>
 <version>1.0-SNAPSHOT</version>
 </dependency>
 </dependencies>

</project>

Quand on lance un build :

$> mvn test

Scanning for projects...

Using the MultiThreadedBuilder implementation with a thread count of 4

------------------------------------------------------------------------
Building independant-project 1.0-SNAPSHOT
------------------------------------------------------------------------
Downloading: https://repo.maven.apache.org/maven2/com/github/jcgay/example/version/parent-pom/$%7Brevision%7D/parent-pom-$%7Brevision%7D.pom
------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Total time: 0.882 s (Wall Clock)
Finished at: 2016-08-09T15:26:09+02:00
Final Memory: 12M/193M
------------------------------------------------------------------------
Failed to execute goal on project independant-project: Could not resolve dependencies for project com.github.jcgay.example.version:independant-project:jar:1.0-SNAPSHOT: Failed to collect dependencies at com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT: Failed to read artifact descriptor for com.github.jcgay.example.version:submodule-1:jar:1.0-SNAPSHOT: Could not find artifact com.github.jcgay.example.version:parent-pom:pom:${revision} in central (https://repo.maven.apache.org/maven2) -> [Help 1]

Et en effet le pom.xml présent dans mon repository local défini toujours ${revision} en tant que <version> du pom-parent.

Filtrer les pom à l’installation/déploiement
#

Ce problème de propriétés non remplacées m’a rappelé un vieil article dans lequel l’auteur s’était amusé à filtrer (dans le sens maven-resources-plugin filtering) ses fichiers pom.xml et les installer à la place des originaux.
J’ai donc recherché s’il était possible de faire de même mais avec une extension Maven (la dose de XML nécessaire et le côté gros hack de la solution décrite m’a découragé…). Et c’est effectivement faisable avec Aether (utilisé dans Maven depuis la version 3) via un org.eclipse.aether.impl.MetadataGenerator. On peut donc écrire un gros hack dans son langage préféré à la place 🤔.

Le code est disponible sur GitHub. Il prend la forme d’une extension Maven qui se charge de transformer les artifacts de type pom à l’installation et au déploiement. Toutes les occurrences de ${revision} sont remplacées par l’actuelle version de l’artifact traité (c’est à dire la valeur résolue de ${revision}). Le problème de résolution de dépendance est dans ce cas résolu !

On peut l’utiliser via le mécanisme d’extensions de Maven en créant (modifiant) le fichier ${maven.multiModuleProjectDirectory}/.mvn/extensions.xml :

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
 <extension>
 <groupId>fr.jcgay.maven.extension</groupId>
 <artifactId>unique-revision-maven-filtering</artifactId>
 <version>[latest-version]</version>
 </extension>
</extensions>

ou bien en copiant directement le jar dans %M2_HOME%/lib/ext.

Conclusion
#

On a donc vu comment utiliser une propriété unique pour définir la version de tous les modules d’un projet. Clairement la fonctionnalité proposée par Maven (continuous delivery friendly version) ne semble pas prévue pour l’usage décrit ici, mais au moins je ne m’embête plus avec mes merge ! J’ai peut-être complètement raté une solution plus simple ? (dans ce cas je la veux bien 😉).

Contextualiser ses événements Sentry

Fri, 15 Jul 2016 14:04:00 +0200

Sentry est un service qui permet la sauvegarde, analyse des erreurs qui surviennent dans vos applications.

Quand vous ne pouvez pas analyser vos logs applicatifs facilement (application mobile ou installée directement sur les postes de vos utilisateurs) il est important de récupérer les erreurs qui se produisent pour les corriger. Pour cela on peut utiliser un service en ligne comme Sentry.

Le service propose des intégrations pour toute sorte de langage, plate-forme. On suivra ici l’intégration au sein d’une JVM avec Logback.

Installation
#

Tout repose sur un client Java nommé raven pour envoyer des erreurs vers Sentry. Il suffit donc d’ajouter une dépendance à votre projet (par exemple avec Maven) :

<dependency>
 <groupId>com.getsentry.raven</groupId>
 <artifactId>raven-logback</artifactId>
 <version>7.3.0</version>
</dependency>

Configuration
#

Il faut ajouter un nouvel appender à sa configuration Logback :

<appender name="Sentry" class="com.getsentry.raven.logback.SentryAppender">
 <dsn>https://<key>:<secret>@app.getsentry.com/<project>?options</dsn>
</appender>
<root level="warn">
 <appender-ref ref="Sentry"/>
</root>

Avec cet exemple, tous les messages loggés via Logback de niveau WARN ou ERROR seront envoyés à Sentry.

C’est très bien on a maintenant nos erreurs qui sont enregistrées mais les informations remontées se limitent en gros aux messages loggés et stracktraces (si présente) associées.
On peut faire mieux en identifiant les utilisateurs victimes d’erreurs.

Identification
#

Les messages Sentry peuvent être enrichis à l’aide de SentryInterface. Une des interface fournie par défaut permet d’associer un utilisateur à chaque message : UserInterface.
Pour définir ces interfaces il faut pimper l’initialisation du client Raven à l’aide d’une factory personnalisée.

package fr.jcgay.github.sentry

import java.net.InetAddress.getLocalHost
import java.util.UUID

import com.getsentry.raven.dsn.Dsn
import com.getsentry.raven.event.EventBuilder
import com.getsentry.raven.event.helper.EventBuilderHelper
import com.getsentry.raven.event.interfaces.UserInterface
import com.getsentry.raven.{DefaultRavenFactory, Raven}

case class MyAppRavenFactory() extends DefaultRavenFactory {

 lazy val uuid: String = UUID.randomUUID.toString

 override def createRavenInstance(dsn: Dsn): Raven = {
 val raven = super.createRavenInstance(dsn)
 raven.addBuilderHelper(AddUser("jcgay", "contact@jeanchristophegay.com", uuid))
 raven
 }
}

case class AddUser(id: String, email: String, uuid: String) extends EventBuilderHelper {
 override def helpBuildingEvent(eventBuilder: EventBuilder): Unit =
 eventBuilder
 .withSentryInterface(new UserInterface(id, getLocalHost.getHostName, null, email))
 .withTag("session-uuid", uuid)
}

On crée donc un utilisateur avec :

new UserInterface(id, getLocalHost.getHostName, null, email)

Le 3ième argument est l’adresse IP de l’utilisateur. Utiliser null pour l’absence de valeur.

On peut aussi ajouter des informations taggées au sein d’un message. Ces données seront indexées par Sentry. On pourra donc les utiliser dans des recherches, etc.
Ici par exemple on génère un identifiant de session qui sera associé aux actions de l’utilisateur pour toute la durée de sa session.

L’EventBuilder que l’on enrichi sera exécuté à chaque construction de message, attention donc à ce que l’on y met 😛.

En terme de configuration il faut enregistrer notre factory et la référencer dans le SentryAppender.

Exécuter quelque-part pendant l’initialisation de l’application :

RavenFactory.registerFactory(MyAppRavenFactory())

Et dans le logback.xml :

<appender name="Sentry" class="com.getsentry.raven.logback.SentryAppender">
 <dsn>https://<key>:<secret>@app.getsentry.com/<project>?options</dsn>
 <ravenFactory>fr.jcgay.github.sentry.MyAppRavenFactory</ravenFactory>
</appender>
<root level="warn">
 <appender-ref ref="Sentry"/>
</root>

Version de l’application
#

Une information importante comprise et utilisée par Sentry est la version de l’application. Elle est renseignable avec la balise <release> au niveau de la configuration du SentryAppender :

<appender name="Sentry" class="com.getsentry.raven.logback.SentryAppender">
 <dsn>https://<key>:<secret>@app.getsentry.com/<project>?options</dsn>
 <ravenFactory>fr.jcgay.github.sentry.MyAppRavenFactory</ravenFactory>
 <release>${project.version}</release>
</appender>
<root level="warn">
 <appender-ref ref="Sentry"/>
</root>

On peut par exemple utiliser la fonctionnalité de Filtering avec Maven pour injecter la version de l’application au moment du build.

Le MDC
#

Le dernier moyen pour contextualiser ses messages est d’utiliser le MDC.

Par défaut toutes les valeurs comprises dans le MDC sont envoyées à Sentry. Par contre elles ne sont pas indexées par défaut. Pour activer l’indexation sur une clef particulière il faut la déclarer en tant que tag :

MDC.put("Environment", "Development");

<appender name="Sentry" class="com.getsentry.raven.logback.SentryAppender">
 <dsn>https://<key>:<secret>@app.getsentry.com/<project>?options</dsn>
 <ravenFactory>fr.jcgay.github.sentry.MyAppRavenFactory</ravenFactory>
 <release>${project.version}</release>
 <extraTag>Environment</extraTag>
</appender>
<root level="warn">
 <appender-ref ref="Sentry"/>
</root>

Conclusion
#

Une fois correctement configuré les messages récupérés dans Sentry permettent de surveiller les erreurs qui interviennent dans vos applications déployées un peu partout dans la nature.
On atteint assez vite les quotas (à la minute) dans le premier plan payant, il existe pas mal d’alternatives mais je n’en ai pas essayé 😱.

Le code utilisé dans les exemples est disponible ici.

Fusion de dépôts Git

Sun, 07 Feb 2016 13:37:00 +0200

Comment fusionner de multiples dépôts Git en un seul ?

What ?!
#

Récemment j’ai eu besoin de fusionner tout un tas de dépôts Git en un seul. Une collection d’applications et de socles métier répartis sur 6 dépôts. Bien sûr des dépendances binaires entre tout ce petit monde et toujours sur la dernière version en cours de développement. Observant que le cycle de vie des projets étaient toujours le même on a voulu simplifier nos processus (branches, gestion de dépendances, build, release, etc.) sans aller jusqu’à la pratique du mono dépôt (comme chez Google par exemple).

Mise en place
#

On veut bien entendu garder l’historique de tous nos projets, il n’est pas question de repartir de zéro 😅.

Il existe un projet, git-merge-repos qui permet de faire le travail en essayant de préserver les branches et les tags.

Le résultat attendu est un dépôt unique contenant tous les projets désirés :

new-repo
├── project-1
├── project-2
├── project-3
└── project-4

On peut utiliser deux stratégies pour faire ce merge :

Réaliser un merge (avec n parents) et déplacer chaque projet dans son sous-dossier dans le commit de merge
Réécrire l’histoire de chaque dépôt pour déplacer chaque contenu de commit dans un sous-dossier et réaliser le merge à la fin.

J’ai d’abord testé avec la première option, le problème est qu’on ne voit plus l’historique d’une ressource après le commit de merge global.

Par exemple :

> git log -- project-1

ne retourne qu’une seule entrée, le commit de merge.

La solution 2 est donc vendue !

Par contre comme on doit réécrire l’historique de chaque dépôt, il faut trouver un moment où une seule branche est en cours de développement (dans mon cas master).

Pour chaque dépôt :

 > git clone --mirror git@example.com:project-1.git
 > cd project-1
 > git filter-branch --index-filter \
 'tab=$(printf "\t") && git ls-files -s --error-unmatch . >/dev/null 2>&1; [ $? != 0 ] || (git ls-files -s | sed "s-$tab\"*-&project1/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE")' \
 --tag-name-filter cat \
 -- --all

où project1 doit être remplacé par le sous-dossier dans lequel on veut transférer le projet.

J’en ai profité aussi pour renommer les tags, git-merge-repos s’occupe aussi de recréer les tags dans le dépôt final sur la base de leurs noms. Dans mon cas je ne le voulais pas vraiment, des tags sur différents dépôts portaient le même nom mais n’étaient pas forcément équivalents.

> git tag | xargs -I '{}' sh -c 'git tag project-1-{} {} && git tag -d {}'

L’opération finale est le lancement la fusion :

> git clone git@github.com:robinst/git-merge-repos.git
> cd git-merge-repos
> ./run.sh /absolute/path/to/project-1:. /absolute/path/to/project-2:.

Le résultat se trouve dans un dossier merged à la racine de git-merge-repos.

Avantages
#

L’intendance est plus facile (création de branches, merge, etc)
On a aujourd’hui de vrais commits atomiques pour la réalisation d’une fonctionnalité. Avant on se retrouvait tout le temps avec des commits sur différents dépôts et ce n’était pas toujours facile à tracer ou pour investiguer sur des régressions
La gestion des dépendances est plus simple, tout le code est dans le même dépôt
Maintenant qu’on est capable de builder nos projets sans dépendances binaires sur des SNAPSHOT, on a mis en place le build de nos Pull Request avec GH Pull Request Builder pour Jenkins

Dans la case inconvénient on peut noter :

Allongement du temps de build, même si ce n’est pas totalement vrai, mais avant avec les dépôts séparés on ne reconstruisait pas forcément tous les projets pour valider nos changements
On utilise Maven pour construire nos projets, notre projet multi-modules géant demande un peu plus de gymnastique intellectuelle pour lancer un build. Une fois qu’on a assimilé l’utilisation des options -pl et -am(d) c’est tout de même faisable 😇

Migrer de boot2docker vers docker-machine

Sun, 31 Jan 2016 16:13:00 +0200

Ça fait un moment qu’à chaque utilisation de la commande boot2docker j’ai un joli message d’avertissement :

 WARNING: The 'boot2docker' command line interface (not to be confused with
 'boot2docker' the operating system) is officially deprecated.

 Please switch to Docker Machine (https://docs.docker.com/machine/) ASAP.

 Docker Toolbox (https://docker.com/toolbox) is the recommended install method.

Je me suis dit qu’il était temps de finalement faire la migration et de tester quelques goodies !

Désinstallation boot2docker
#

C’est la partie simple,

> boot2docker delete
> brew uninstall boot2docker

Installation de docker-machine
#

Là encore brew nous sauve la vie,

> brew install docker-machine

docker-machine va nous permettre de provisionner docker dans des machines virtuelles (qu’elles soient locales ou dans le cloud) et il se charge de configurer le client docker pour parler avec ces machines.

Pour reproduire l’utilisation de boot2docker il faut créer un environnement en utilisant le driver virtualbox :

> docker-machine create --driver virtualbox dev

L’argument dev est le nom que de la machine, on peut y mettre ce qu’on veut.

Creating CA: /Users/jcgay/.docker/machine/certs/ca.pem
Creating client certificate: /Users/jcgay/.docker/machine/certs/cert.pem
Running pre-create checks...
(dev) Image cache directory does not exist, creating it at /Users/jcgay/.docker/machine/cache...
(dev) No default Boot2Docker ISO found locally, downloading the latest release...
(dev) Latest release for github.com/boot2docker/boot2docker is v1.9.1
(dev)
(dev) Boot2Docker v1.9.1 has a known issue with AUFS.
(dev) See here for more details: https://github.com/docker/docker/issues/18180
(dev) Consider specifying another storage driver (e.g. 'overlay') using '--engine-storage-driver' instead.
(dev)
(dev) Downloading /Users/jcgay/.docker/machine/cache/boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v1.9.1/boot2docker.iso...
(dev) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100%
Creating machine...
(dev) Copying /Users/jcgay/.docker/machine/cache/boot2docker.iso to /Users/jcgay/.docker/machine/machines/dev/boot2docker.iso...
(dev) Creating VirtualBox VM...
(dev) Creating SSH key...
(dev) Starting the VM...
(dev) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env dev

On peut bien entendu configurer un certains nombre d’options (CPU, mémoire, etc). La liste complète est disponible dans la documentation du driver VirtualBox.

On voit que docker-machine se charge de télécharger un ISO boot2docker, il nous indique aussi la commande à exécuter pour configurer le client docker.

> docker-machine env dev

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/jcgay/.docker/machine/machines/dev"
export DOCKER_MACHINE_NAME="dev"
# Run this command to configure your shell:
# eval $(docker-machine env dev)

Allez on finit donc par un :

> eval $(docker-machine env dev)

Et voilà docker fonctionne comme avant !

> docker-machine stop dev

Les volumes
#

Je dois certainement mal m’y prendre mais c’est vraiment la fonctionnalité qui me pose tout le temps problème, à chaque fois que j’essaie de démarrer un conteneur en mappant un volume sur ma machine, j’ai des problèmes de droit 🤔

Par exemple avec mongo:

> docker run -v /Users/jcgay/data/mongo:/data/db mongo

[initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=968af53e81ec
[initandlisten] db version v3.2.1
[initandlisten] git version: a14d55980c2cdc565d4704a7e3ad37e4e535c1b2
[initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
[initandlisten] allocator: tcmalloc
[initandlisten] modules: none
[initandlisten] build environment:
[initandlisten] distmod: debian71
[initandlisten] distarch: x86_64
[initandlisten] target_arch: x86_64
[initandlisten] options: {}
[initandlisten] exception in initAndListen: 98 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating

ou encore mysql:

 > docker run -v /Users/jcgay/tmp/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=plop mysql 

Initializing database
[Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
[ERROR] InnoDB: Operating system error number 13 in a file operation.
[ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
[ERROR] InnoDB: Operating system error number 13 in a file operation.
[ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
[ERROR] InnoDB: Cannot open datafile './ibdata1'
[ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
[ERROR] InnoDB: InnoDB Database creation was aborted with error Cannot open a file. You may need to delete the ibdata1 file before trying to start up again.
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Failed to initialize plugins.
[ERROR] Aborting

Apparemment le partage de volume ne fonctionne que si le partage de stockage avec VirtualBox se fait avec l’utilisateur root. Il y a un long thread ouvert chez boot2docker.

Activer NFS pour le mapping de volumes
#

Le projet docker-machine-nfs permet de remplacer le partage VirtualBox par du NFS. En bonus, les performances de lecture/écriture devraient être meilleures.

Après installation, il faut activer NFS sur la machine désirée :

> docker-machine-nfs dev

[INFO] Configuration:

	- Machine Name: dev
	- Shared Folder: /Users
	- Force: false

[INFO] machine presence ... 			OK
[INFO] machine running ... 			 OK
[INFO] Lookup mandatory properties ... OK

	- Machine IP: 192.168.99.100
	- Network ID: vboxnet4
	- NFSHost IP: 192.168.99.1

[INFO] Configure NFS ...

 !!! Sudo will be necessary for editing /etc/exports !!!
						
[INFO] Configure Docker Machine ... 	OK
[INFO] Restart Docker Machine ... 		OK
[INFO] Verify NFS mount ... 			OK

--------------------------------------------

 The docker-machine 'dev'
 is now mounted with NFS!

 ENJOY high speed mounts :D

--------------------------------------------

Bon et en fait chez moi, ce n’est toujours pas mieux 😱

 > docker run -v /Users/jcgay/tmp/mongo:/data/db mongo 
 chown: changing ownership of `/data/db': Operation not permitted

 > docker run -v /Users/jcgay/tmp/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=plop mysql 
 chown: changing ownership of '/var/lib/mysql/': Operation not permitted

On peut modifier la configuration du mapping pour changer les droits, voir le ticket #17)

> docker-machine-nfs dev --force --nfs-config="-alldirs -maproot=0"

Et enfin ça fonctionne ! 🎆🚀

Docker survitaminé
#

Maintenant que docker-machine s’occupe de tout, on peut tenter d’utiliser d’autres drivers. On peut essayer xhyve un hyperviseur natif pour OS X et ainsi se passer de VirtualBox.

> brew install xhyve docker-machine-driver-xhyve

Oui il faut être root…

> sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
> sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

On crée la machine :

> docker-machine create xhyve --driver xhyve --xhyve-experimental-nfs-share

Toutes les options sont documentées sur la page officielle du driver.

Je ne me suis pas amusé à comparer les performances des deux solutions mais pour le moment je n’ai pas rencontré de soucis avec cette dernière.

Déployer ses SNAPSHOT avec Travis CI

Wed, 29 Jul 2015 21:23:00 +0200

Mini guide pour déployer des binaires SNAPSHOT sur le repository OSS sonatype avec Travis CI.

Configuration de Maven
#

Il faut configurer Maven pour utiliser votre compte pour uploader des artifacts sur OSSRH.
Créer un fichier etc/deploy-settings.xml et utiliser des variables pour référencer vos identifiants :

<settings>
 <servers>
 <server>
 <id>ossrh</id>
 <username>${env.OSSRH_USER}</username>
 <password>${env.OSSRH_PASS}</password>
 </server>
 </servers>
</settings>

Ce fichier sera par la suite utilisé par mvn grâce à l’option --settings.

Identification
#

On a deux solutions pour stocker ses identifiants et les utiliser avec Travis CI.

Stockage dans les paramètres du repository
#

Dans les options de Travis CI https://travis-ci.org/user/repository/settings, on peut définir les variables d’environnements OSSRH_USER et OSSRH_PASS. Par défaut celles-ci seront masquées dans les logs.

Chiffrer ses identifiants
#

Il semble évident qu’on ne va pas sauvegarder ses identifiants en clair, Travis CI permet de chiffrer des données sensibles.

gem install travis

Et là on doit faire face à Ruby… Si vous ne développez pas dans cet eco-système, il y a des chances que celà se passe mal à partir de maintenant :( (en tout cas avec OS X)
Dans mon cas j’ai eu le droit à l’erreur suivante :

> gem install travis 
Fetching: multipart-post-2.0.0.gem (100%)
ERROR: While executing gem ... (Gem::FilePermissionError)
 You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

Le problème vient de la version installée par Apple, les utilisateurs de ruby utiliseront surement rvm, rbenv ou je ne sais quelle autre joyeuseté. Pour le commun des mortels qui ne veulent pas y passer une demi heure et qui n’ont pas envie de tout casser :

brew install ruby

Relancer un shell et l’installation du gem travis devrait mieux se passer…

On peut maintenant envoyer nos données importantes à travis :

travis encrypt --add -r jcgay/send-notification "OSSRH_USER='toto'"
travis encrypt --add -r jcgay/send-notification "OSSRH_PASS='s3cret&'"

Si les commandes sont lancées depuis le dossier qui contient le projet l’option -r n’est pas nécessaire et l’option --add ajoutera automatiquement les clefs cryptées dans le fichier .travis.yml.
jcgay/send-notification correspond bien entendu au projet pour lequel ont veut chiffrer des données.

Configuration de Travis CI
#

On veut déployer les SNAPSHOT sauf si Travis est en train de builder une pull-request. On peut pour cela utiliser la variable ${TRAVIS_PULL_REQUEST}.
La variable ${TRAVIS_TAG} permet de ne pas non plus déployer les releases (qui ne sont pas faites avec Travis dans mon cas).

On se retrouve donc avec les variables d’environnement cryptées au sein de .travis.yml :

env:
 global:
 - secure: GT8Hi5kgx2cLAGzh2ggZNTgiLm8J5fd64SYG3bkhgwZGbV/HRD8r8a1SYv1iQ72JqrDhlHQ7q8h17nDBFLjy99h/XKN4MacBu9CZhnPO7lXpuRefD3W/db6zWSk17a5DAKAt+1UOeyfohEkzx+JHcTfbvMg6hy+3DEPaVMUtV04=
 - secure: fQ4bSOcHWEURfsDQVhWA152GCiezQfh9YC45a2zae8oOk+6bIrHmrkJSyVYpUCLGdqO3Df+JTy6bfoqyJEsX7PkzGPZ10odSHw5qDqfTIolt7UympKtUvUNi6h5G6virGhBWjjs5REGjrgWdTlqKjNT2Ax/VlzNRskqaVAhEhl0=

et une étape de plus dans la section after_success:

after_success:
 - "[[ ${TRAVIS_PULL_REQUEST} == 'false' ]] && [[ ${TRAVIS_TAG} == '' ]] && mvn deploy -DskipTests --settings etc/deploy-settings.xml"

Et voilà tout roule !

Tester son code Java avec Groovy et Spock

Thu, 04 Jun 2015 22:18:00 +0200

Spock est un framework de tests écrit sous la forme de spécifications pour des applications Java ou Groovy. Il offre une alternative tout en un au trio JUnit (TestNG), Mockito et AssertJ.

Mise en place
#

Maven
#

Il s’agit de dépendances à ajouter et d’un peu de configuration supplémentaire :

<dependency>
 <groupId>org.codehaus.groovy</groupId>
 <artifactId>groovy</artifactId>
 <version>2.4.3</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.spockframework</groupId>
 <artifactId>spock-core</artifactId>
 <version>1.0-groovy-2.4</version>
 <scope>test</scope>
</dependency>
<!-- (Optionnel) Nécessaire pour mocker des classes concrètes -->
<dependency>
 <groupId>cglib</groupId>
 <artifactId>cglib-nodep</artifactId>
 <version>3.1</version>
 <scope>test</scope>
</dependency>

<build>
 <plugins>
 <plugin>
 <groupId>org.codehaus.gmavenplus</groupId>
 <artifactId>gmavenplus-plugin</artifactId>
 <version>1.5</version>
 <executions>
 <execution>
 <goals>
 <goal>testCompile</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 <plugin>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <includes>
 <include>**/*Spec.java</include>
 </includes>
 </configuration>
 </plugin>
 </plugins>
</build>

Et voilà on peut écrire des spécifications de type *Spec.groovy dans src/test/groovy.

Gradle
#

apply plugin: 'java'
apply plugin: 'groovy'

repositories {
 mavenCentral()
}

dependencies {
 testCompile group: 'org.codehaus.groovy', name: 'groovy', version: '2.4.3'
 testCompile group: 'org.spockframework', name:'spock-core', version: '1.0-groovy-2.4'
 testRuntime group: 'cglib', name: 'cglib-nodep', version: '3.1'
}

Et voilà on peut écrire des spécifications de type *Spec.groovy dans src/test/groovy.

Spécification
#

Squelette
#

Une spécification est une classe qui étends spock.lang.Specification. Elle est composée de champs, de méthodes de configuration (fixture) et enfin de méthodes pour décrire des fonctionnalités (feature).

class MyFirstSpec extends Specification {

 ClassUnderSpecification underTest = new ClassUnderSpecification()
 
 @Shared
 VeryExpensiveResource resource = new VeryExpensiveResource()
 
 def setup() {}
 def cleanup() {}
 def setupSpec() {}
 def cleanupSpec() {}
 
 def "pushing an element on the stack"() {}
}

Les champs ne sont pas partagés entre les méthodes de feature.
Pour partager un objet (par exemple un peu long à initialiser), il faut annoter le champ avec @Shared.

Equivalence fixture avec les annotations JUnit :

Méthode	JUnit
setup	@Before
cleanup	@After
setupSpec	@BeforeClass
cleanupSpec	@AfterClass

On peut de toute façon aussi utiliser les annotations JUnit directement.
Une fonctionnalité est équivalente à une méthode annotée avec @Test dans JUnit.

Blocs
#

Une fonctionnalité est structurée autour de blocs. Il en existe six : setup, when, then, expect, cleanup, et where. Il fait au minimum un bloc pour qu’une méthode soit considérée comme une fonctionnalité (et donc exécutée).
Chaque bloc joue un rôle dans l’expression d’un test et sa bonne utilisation est validée par la librairie quand c’est possible (ordre de déclaration, autorisation du contenu, etc).

setup, given
#

Il permet l’initialisation du test, given est un alias de setup.

when, then
#

when contient le stimulus du test tandis que then permet d’écrire les assertions.
when peut contenir n’importe quel type d’instructions contrairement au bloc then qui lui est limité aux : conditions, vérification des exceptions, interactions (avec les mocks), et définition de variables.

expect
#

Permet d’exprimer les bloc when et then en un seul. Dans la documentation officielle il est conseillé d’utiliser la forme when / then pour tester les méthodes avec des effets de bord et de garder la forme expect pour les fonctions pures.

cleanup
#

Le bloc pour nettoyer les ressources utilisées lors d’un test. Son contenu est tout le temps exécuté même si une exception est levée dans une autre partie de la fonctionnalité.

where
#

Toujours défini en dernier, on peut y écrire la génération des données pour exécuter des tests paramétrés.

Assertions (conditions)
#

Les assertions avec Spock peuvent être remplacées par de simples expressions booléennes.

given:
def list = []

when:
list.add(1)

then:
!list.isEmpty
list.size() == 10

Si un test échoue, on a un affichage complet de l’état du test.

Condition not satisfied:

list.size() == 10
| | |
[1] 1 false

C’est plutôt pratique et lisible dans la majorité des cas. Quand ce ne l’est pas, on peut très bien continuer d’utiliser sa librairie d’assertions préférées.

Vérification des exceptions
#

Il existe divers solutions pour tester des exceptions dans les tests unitaires.
Avec Spock on peut utiliser les conditions thrown(), notThrown et noExceptionThrown().

def "should not throw exception"() {
 when:
 [1].get(0)

 then:
 noExceptionThrown()
}

def "should not throw IndexOutOfBoundsException"() {
 when:
 [1].get(0)

 then:
 notThrown(IndexOutOfBoundsException)
}

def "should throw exception"() {
 when:
 [1].get(1)

 then:
 thrown(IndexOutOfBoundsException)
}

def "should throw exception with message"() {
 when:
 [1].get(1)

 then:
 IndexOutOfBoundsException e = thrown()
 e.message == 'Index: 1, Size: 1'
}

Mock
#

Spock utilise sa propre librairie de mock qui se sert des possibilités du langage Groovy pour définir les interactions.
Comme avec Mockito les mocks sont permissifs par défaut (une interaction non définie ne fera pas échouer un test), par contre les interactions non définies ne retournent que les valeurs par défaut (0, null ou false).

Prenons l’exemple d’une classe écoutant l’état d’un build qui chercherait à envoyer des notifications à la fin de celui-ci.

public class BuildListener {

 private final Notifier notification;

 public BuildListener(Notifier notification) {
 if (notification.checkCompatibility(System.getProperty("os.name"))) {
 throw new IllegalArgumentException("Notifier not compatible with current os");
 }
 this.notification = notification;
 }

 public void onSuccess(BuildResult result) {
 if (notification.isReady()) {
 notification.send("Build success !");
 }
 }
}

Création
#

La définition d’un mock passe par l’utilisation de l’api Mock().

def notifier = Mock(Notifier)

Notifier notifier = Mock()

interaction
#

La spécification du comportement du mock se fait directement dans le bloc then.

class MockSpec extends Specification {

 Notifier notifier = Mock()

 BuildListener listener = new BuildListener(notifier)

 def "should send notification when build ends and notifier is ready"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 1 * notifier.send("Build success !")
 }
}

Cela peut paraitre peu naturel au début de définir les interactions dans le bloc then. Mais c’est parce que l’api ne se limite pas à la définition du comportement, on a en plus la vérification que le mock a bien été appelé (l’équivalent d’un Mockito.verify()) !

Si l’interaction avec le mock ne s’est pas passée comme prévu on a un message d’erreur :

Too few invocations for:

1 * notifier.send("Build success !") (0 invocations)

Unmatched invocations (ordered by similarity):

1 * notifier.isReady()

On peut aussi ne pas vérifier les interactions (dans ce cas l’usage d’un Stub() est préférable). Le test précédent peut s’écrire :

def "should send notification when build ends"() {
 given:
 notifier.isReady() >> true

 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.send("Build success !")
}

On peut déclarer le nombre d’appel attendu :

1 * notifier.send("Build success !") // un appel
0 * notifier.send("Build success !") // pas d'appel
(2..5) * notifier.send("Build success !") // entre deux et cinq appels
(1.._) * notifier.send("Build success !") // au moins un appel
(_..2) * notifier.send("Build success !") // deux appels au plus

La vérification du/des arguments d’une méthode est lui aussi assez riche :

* notifier.send("a") // argument vaut "a"
* notifier.send(!"a") // argument différent de "a"
* notifier.send(_) // n'importe quel argument (dont null)
* notifier.send(!null) // argument non null
* notifier.send(_ as String) // argument de type String
* notifier.send({ it.startsWith 'a' }) // argument commençant par "a"

L’utilisation d’une closure dans le matching d’argument (comme le dernier exemple ci-dessus) peut permettre dans certains cas limites de reproduire le comportement d’un ArgumentCaptor de Mockito :

def "should send notification when build ends"() {
 def captured

 given:
 notifier.isReady() >> true

 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.send(_) >> { arguments -> captured = arguments[0] }

 captured == "Build success !"
}

Pour retrouver l’équivalent du @InjectMocks de Mockito il existe une extension Spock (Spock Subjects-Collaborators Extension) qui permet d’injecter automatiquement des mocks dans l’objet que l’on souhaite tester.
Les mocks doivent être annotés avec @Collaborator et le sujet du test avec @Subject.

class MockWithSubjectSpec extends Specification {

 @Collaborator
 Notifier notifier = Mock()

 @Subject
 BuildListener listener

 def "should send notification when build succeed"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 1 * notifier.send("Build success !")
 }
}

Par défaut Spock ne vérifie pas l’ordre dans lequel les interactions sont invoquées. Si vraiment on en a besoin on peut définir les interactions dans des blocs then différents. Dans ce cas les mocks devront être appelés dans l’ordre dans lequel ils ont été déclarés.

def "should send notification when build ends"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 
 then:
 1 * notifier.send("Build success !")
}

Définition retour des méthodes
#

Pour retourner une valeur dans la définition d’une interaction on utilise l’opérateur >>.

notifier.isReady() >> true

L’opérateur >>> permet de définir des valeurs de retours différentes pour des appels successifs.

notifier.isReady() >>> [true, false, false, true]

On peut également retourner une valeur après un calcul dépendant d’un argument.

notifier.checkCompatibility(_) >> { String os -> !os.startsWith("win") }

Et enfin pour lever une exception :

notifier.isReady() >> { throw new NullPointerException() }

Stub, Spy, Partial mock
#

Spock gère aussi tous ces autres type de mocks.

Un stub peut-être créé avec l’api Stub(). La grande différence avec un Mock() est qu’on ne peut pas vérifié le comportement du stub (d’ailleurs une erreur se produira si l’on essaie). L’initialisation par défaut est aussi plus “intelligente” que celle des Mock().
Si une interaction n’est pas définie et qu’un appel a lieu, la valeur retournée tentera de s’adapter au type de retour défini (une collection vide sera retournée par exemple).

Les autres s’utilisent avec l’api Spy(). Tout est décrit dans la documentation

Tests paramétrés
#

Parfois on a besoin d’exécuter plusieurs fois le même test avec des données différentes.
Avec JUnit on a le choix entre :

Généralement j’utilise junit-dataprovider qui mime le comportement des DataProvider de TestNG mais avec Spock on va avoir accès à des solutions bien plus élégantes.

Data Tables
#

La déclaration des données se fait dans un bloc expect.

def "should return maximum of two numbers"() {
 expect:
 Math.max(a, b) == c

 where:
 a | b || c
 1 | 2 || 2
 2 | 1 || 2
 1 | 0 || 1
 0 | 0 || 0
}

Le test sera exécuté pour chaque ligne du tableau, chaque colonne définissant une variable du test.
Le double séparateur de colonne est optionnel, c’est du sucre syntaxique pour séparer les valeurs d’entrée et le résultat attendu.

Par défaut le test est vu comme un seul, ce qui fait que ce n’est pas toujours facile de retrouver quelle ligne du tableau entraine un échec.
Pour améliorer la lisibilité du rapport de test, on peut utiliser l’annotation @Unroll. Elle permet de créer un rapport par ligne du tableau et d’injecter les valeurs du test dans le nom de la méthode.

On peut donc remplacer le nom du test précédent en utilisant #variable comme placeholder :

@Unroll
def "maximum of #a and #b should be #c"()

et le rapport de l’exécution des tests ressemblera à :

maximum of 1 and 2 should be 2
maximum of 2 and 1 should be 2
maximum of 1 and 0 should be 1
maximum of 0 and 0 should be 0

Data Pipes
#

Les data pipes sont la seconde forme de data provider disponible.

def "even numbers"() {
 expect:
 a % 2 == 0

 where:
 a << [0, 2, 4, 6]
}

Le test sera exécuté quatre fois avec les valeurs 0, 2, 4, 6. Tout objet connu comme étant iterable par Groovy peut être utilisé dans un data pipe.

Test génératifs
#

Spock-Genesis est une collection de générateurs pour écrire des tests génératifs.

@Unroll
def "should reverse #string"() {
 when:
 String reversed = string.reverse()

 then: 'It maintains length'
 reversed.size() == string.size()

 and: 'It is not destructive'
 reversed.reverse() == string

 where:
 string << Gen.these('', 'aba', 'aa').then(Gen.string).take(10000)
}

Tout se passe à partir de spock.genesis.Gen, il y a des générateurs pour les String, int, long, double, Date, etc.
La documentation est succincte mais il y a des exemples d’utilisation ici.

Pour améliorer l’analyse statique dans l’IDE il est possible d’ajouter en paramètre de la méthode de test les types des variables nécessaires.
Dans l’exemple précédent, IntelliJ Idea se plaint de ne pas trouver les méthodes reverse et size pour la variable string (reconnu comme étant de type Object). Si on déclare un paramètre pour la méthode, plus de problème.

@Unroll
def 'should reverse #string'(String string)

Extensions
#

Spock possède un mécanisme permettant d’enrichir son cycle de vie. Les extensions disponibles par défaut sont listées dans la documentation.

Parmi les plus sympa, il y a :

@IgnoreIf permet d’ignorer un test quand une condition n’est pas respectée,
@Timeout pour faire échouer un test s’il ne s’est pas exécuté en un certain temps,
@AutoCleanup appelle automatiquement une méthode sur un champ annoté pour libérer des resources à la fin de son cycle de vie,
@RestoreSystemProperties rétabli les valeurs des propriétés systèmes quand elles ont été modifiées au cours d’un test.

Et il en existe d’autres développés par la communauté :

Spock Reports pour générer un rapport HTML des spécifications,
@TempDirectory crée des dossiers temporaires,
Spock Subjects-Collaborators Extension pour injecter des mocks dans la classe que l’on teste,
Et bien d’autres…

Et finalement Spock est aussi compatible avec les @Rule de JUnit !!

Documentation
#

Spock met en avant le fait que les tests sont des spécifications qui peuvent-être documentées comme telles.
Les blocs sont en fait des labels, on peut donc y associer une description :

when: "a build notifies a listener when ending"
listener.onSuccess(new BuildResult())

then: "the listener asks a notifier if it is ready"
1 * notifier.isReady() >> true
 
then: "the listener asks the notifier to send a notification"
1 * notifier.send("Build success !")

Un bloc peut être découpé en plusieurs étapes avec le label and:

given: "something"
// code

and: "something else"
// code

when:
then:

Il existe aussi des extensions à fin documentaire :

@Title, @Narrative définissent une spécification,
@Issue indique qu’une fonctionnalité ou une spécification sont liées à un ticket,
@Subject pour identifier la classe que l’on spécifie.

Conclusion
#

Les tests écrits avec Spock sont globalement plus concis et lisibles. Les noms de méthodes sont de vrais phrases, les spécifications sont structurées autour de blocs bien définis (given, when, then) et le langage Groovy permet d’écrire moins de code.

Spock vient avec son propre framework de mocks et ses assertions pensés pour l’outil. Ça évitera de se retrouver avec des tests écrits avec des librairies différentes et de devoir retenir plusieurs API. Rien n’empêche d’ailleurs d’utiliser Mockito (ou un autre) par exemple à la place des mocks livrés avec Spock.

Spock est compatible avec de nombreux outils puisqu’il est accompagné d’un runner JUnit. Pas de soucis pour exécuter les spécifications depuis son IDE ou son outil de build préféré. Cela le rend aussi compatible avec les Rule JUnit !

Groovy a une courbe d’apprentissage rapide pour un développeur Java. Le langage en est très proche et on peut se permettre d’en apprendre les spécificités et les concepts au fur et à mesure. Utiliser Groovy pour ses tests a encore plus de sens quand on maintient du code Java dans des versions un peu ancienne.

Même si les exemples se sont concentrés sur du code Java, Spock fonctionne aussi très bien pour tester du Groovy 😇

Encore ?
#

Le guide d’utilisation de Spock mérite une lecture attentive, ses mécanismes y sont très bien expliqués.
La présentation Smarter testing Java code with Spock Framework propose tout une série d’astuces pour encore améliorer son utilisation de Spock !
Et pour finir les auteurs de l’outil maintiennent un projet d’exemple dans lequel on peut aller piocher de bonnes idées.

Notifications de bureau pour Gradle

Wed, 13 May 2015 17:35:00 +0200

Comme (trop ?) souvent avec les builds, le temps parait long… Souvent lancé un peu en tâche de fond, j’aime bien avoir une notification quand ceux ci se terminent.
Gradle propose un plugin par défaut pour enrichir son build de notifications mais on verra comment avoir accès à une panoplie de nouveaux types de notifications !

Gradle Build Announcements
#

C’est le plugin disponible par défaut dans la distribution de Gradle. Il est lui même basé sur le plugin Announce qui permet d’envoyer des notifications personnalisées pendant un build.
Il supporte 4 types de notifications :

twitter
notify-send
Snarl
Growl

Pour l’activer, c’est très simple il suffit de le déclarer dans build.gradle :

apply plugin: 'build-announcements'

ou de le déclarer directement dans $HOME/.gradle/init.gradle pour que le plugin soit actif pour tous les projets :

rootProject {
 apply plugin: 'build-announcements'
}

C’est vraiment très sympa d’avoir cette fonctionnalité disponible directement sans rien installer… Par contre le choix d’applications est assez limité et les notifications ne sont pas très visuelles (l’icône est toujours la même quelque soit l’état du build par exemple).

Gradle notifier
#

Comme j’avais déjà mes notifications pour Maven avec maven-notifier, j’en ai profité pour les porter vers Gradle avec gradle-notifier !

Il supporte l’envoi de notifications vers :

Notifier	Screenshot
Growl, pour Windows et OS X.
Snarl, pour Windows
terminal-notifier, OS X
notification center OS X (depuis Mavericks)
notify-send pour Linux
SystemTray depuis Java 6
Pushbullet
Kdialog pour KDE
notifu for Windows
AnyBar pour OS X et Linux
Toaster pour Windows 8
Notify since Java 6
BurntToast for Windows 10
Slack

Installation
#

Le plugin peut être ajouté dans la phase d’initialisation ou directement au sein d’un projet.

Script d’initialisation
#

Pa exemple, créer (ou modifier) le fichier $HOME/.gradle/init.gradle :

initscript {
 repositories {
 mavenCentral()
 }

 dependencies {
 classpath group: 'fr.jcgay', name: 'gradle-notifier', version: '1.1.0'
 }
}

rootProject {
 apply plugin: fr.jcgay.gradle.notifier.GradleNotifierPlugin
}

Script du projet
#

Dans le script build.gradle, ajouter :

buildscript {
 repositories {
 mavenCentral()
 }
 
 dependencies {
 classpath group: 'fr.jcgay', name: 'gradle-notifier', version: '1.1.0'
 }
}

apply plugin: 'fr.jcgay.gradle-notifier'

ou en utilisant le mécanisme de plugin introduit depuis Gradle 2.1:

plugins {
 id "fr.jcgay.gradle-notifier" version "1.1.0"
}

Configuration
#

Reposant sur send-notification, la configuration des applications et le choix de celle utilisée pour recevoir les notifications peut se faire dans le fichier $HOME/.send-notification (Voir les paramètres disponibles dans la documentation).

Ou bien l’outil est configurable directement au sein d’un script Gradle :

notifier {
 implementation = 'notificationcenter'
 threshold {
 time = 10
 unit = java.util.concurrent.TimeUnit.SECONDS
 }
 growl {
 port = 23053
 host = 'localhost'
 password = 'azerty123'
 }

Et voilà plus moyen d’oublier son build au fin fond d’une console !

Mesurer son temps de build Maven

Sun, 01 Feb 2015 20:07:00 +0200

Des outils pour mesurer en détail le temps de build de chaque exécution d’un build Maven.

Par défaut Maven ne mesure que le temps par module et total du build sans donner de temps intermédiaire.
Il existe heuresement des solutions pour obtenir les temps d’éxécutions de chaque étape de son build.

maven-profiler
#

Un outil que j’ai écris à l’époque car je n’en avais pas trouvé. Je m’en sers pour trouver quels étapes d’un build optimiser pour réduire son temps d’exécution.

Il génère un rapport (HTML ou JSON) archivé dans le dossier .profiler au sein du projet.

Pour l’installer il suffit de suivre les instructions disponibles sur github.

Le rapport est généré quand on lance un build avec la propriété système profile :

mvn install -Dprofile

Par défaut le rapport HTML est utilisé, pour avoir le modèle JSON :

mvn install -Dprofile -DprofileFormat=JSON

Exemple de rapport :

{
	"name": "maven-profiler",
 "goals": "clean install",
 "date": "2015/01/17 15:28:49",
	"parameters": "{profile=true, profileFormat=JSON}",
 "projects": [{
	 "project": "maven-profiler",
		"time": "6.793 s",
 	"mojos": [{
	 	"mojo": "org.apache.maven.plugins:maven-surefire-plugin:2.18:test {execution: default-test}",
		 "time": "2.512 s"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-shade-plugin:2.3:shade {execution: default}",
	 	"time": "1.458 s"
		}, {
 		"mojo": "org.codehaus.gmavenplus:gmavenplus-plugin:1.2:testCompile {execution: default}",
	 	"time": "818.3 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-compiler-plugin:3.2:compile {execution: default-compile}",
	 	"time": "538.7 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-source-plugin:2.4:jar-no-fork {execution: attach-sources}",
	 	"time": "248.5 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-jar-plugin:2.5:jar {execution: default-jar}",
	 	"time": "238.2 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-resources-plugin:2.7:resources {execution: default-resources}",
	 	"time": "171.7 ms"
 		}, {
 		"mojo": "org.codehaus.plexus:plexus-component-metadata:1.6:generate-metadata {execution: default}",
	 	"time": "170.5 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-enforcer-plugin:1.2:enforce {execution: enforce-maven}",
	 	"time": "126.0 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-clean-plugin:2.6.1:clean {execution: default-clean}",
	 	"time": "76.11 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-install-plugin:2.5.2:install {execution: default-install}",
	 	"time": "53.95 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-compiler-plugin:3.2:testCompile {execution: default-testCompile}",
	 	"time": "2.850 ms"
		}, {
 		"mojo": "org.apache.maven.plugins:maven-resources-plugin:2.7:testResources {execution: default-testResources}",
	 	"time": "2.518 ms"
	 }]
	}]
}

maven-timeline
#

Ce plugin présente les temps de construction de chaque phase au sein d’un build sous la forme d’un timeline. Initialement développé par David Gageot, il en existe un fork maintenu par l’équipe de takari.

Pour l’utiliser il fait ajouter une extension dans le fichier pom.xml :

<extension>
 <groupId>io.takari.maven</groupId>
 <artifactId>maven-timeline</artifactId>
 <version>1.6</version>
</extension>

Deux rapports sont générés, un en HTML et un en JSON.

{
 "start": "2015-02-01T19:18:18.738Z",
 "end": "2015-02-01T19:18:21.770Z",
 "dateTimeFormat": "iso8601",
 "events": [
 {
 "start": "2015-02-01T19:18:20.940Z",
 "end": "2015-02-01T19:18:21.095Z",
 "duration": 2380,
 "description": "com.github.jcgay.maven.color:maven-color-logback:package:jar:default-jar (2380 ms)",
 "trackNum": 1,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.136Z",
 "end": "2015-02-01T19:18:19.545Z",
 "duration": 830,
 "description": "com.github.jcgay.maven.color:maven-color-core:compile:compile:default-compile (830 ms)",
 "trackNum": 2,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.562Z",
 "end": "2015-02-01T19:18:19.564Z",
 "duration": 849,
 "description": "com.github.jcgay.maven.color:maven-color-agent:test-compile:testCompile:default-testCompile (849 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 },
 {
 "start": "2015-02-01T19:18:19.677Z",
 "end": "2015-02-01T19:18:19.818Z",
 "duration": 1103,
 "description": "com.github.jcgay.maven.color:maven-color-agent:package:jar:default-jar (1103 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 },
 
 ...
 
 {
 "start": "2015-02-01T19:18:20.801Z",
 "end": "2015-02-01T19:18:21.549Z",
 "duration": 2834,
 "description": "com.github.jcgay.maven.color:maven-color-log4j2:package:single:make-assembly (2834 ms)",
 "trackNum": 3,
 "color": "blue",
 "durationEvent": true
 }
 ]
}

tesla-profiler
#

Un autre profiler qui affiche les temps de build dans la console.

Le rapport est généré quand on lance un build avec la propriété système maven.profile :

mvn install -Dmaven.profile

Un exemple de résultat :

com.github.jcgay.maven:maven-profiler:2.2-SNAPSHOT

 clean 81ms
 org.apache.maven.plugins:maven-clean-plugin:2.6.1 (default-clean) 80ms

 validate 145ms
 org.apache.maven.plugins:maven-enforcer-plugin:1.2 (enforce-maven) 145ms

 process-resources 198ms
 org.apache.maven.plugins:maven-resources-plugin:2.7 (default-resources) 198ms

 compile 588ms
 org.apache.maven.plugins:maven-compiler-plugin:3.2 (default-compile) 588ms

 process-classes 209ms
 org.codehaus.plexus:plexus-component-metadata:1.6 (default) 209ms

 process-test-resources 3ms
 org.apache.maven.plugins:maven-resources-plugin:2.7 (default-testResources) 3ms

 test-compile 1s 2ms
 org.apache.maven.plugins:maven-compiler-plugin:3.2 (default-testCompile) 3ms
 org.codehaus.gmavenplus:gmavenplus-plugin:1.2 (default) 998ms

 test 2s 670ms
 org.apache.maven.plugins:maven-surefire-plugin:2.18 (default-test) 2s 669ms

 package 2s 778ms
 org.apache.maven.plugins:maven-jar-plugin:2.5 (default-jar) 250ms
 org.apache.maven.plugins:maven-source-plugin:2.4 (attach-sources) 270ms
 org.apache.maven.plugins:maven-shade-plugin:2.3 (default) 2s 258ms

Bon profiling !

Ecrire une migration Liquibase en Java

Sun, 01 Feb 2015 13:37:00 +0200

Liquibase est un outil très utile pour versionner sa base de données. La succession de refactoring à appliquer à une base peut-être décrite dans plusieurs formats de données (XML, YAML, JSON et SQL). Seulement il arrive qu’une migration soit “trop” complexe pour être décrite à partir des refactoring standards (ou alors tout simplement que l’on ne soit pas très à l’aise avec PL/SQL).
Dans ce cas on peut écrire un changement particulier en Java.

Implémenter un CustomChange
#

Liquibase propose deux interfaces pour créer son refactoring personnel, CustomTaskChange et CustomSqlChange. La première permet d’appliquer des changements qui ne génèrent pas de SQL contrairement à la seconde.
Cette dernière est à privilégier quand c’est possible puisque cela permet de sauvegarder le SQL généré dans un fichier (via un dryRun par exemple).

public class MyCustomChangeThatGenerateSql implements CustomSqlChange {

 @Override
 public SqlStatement[] generateStatements(final Database database) throws CustomChangeException {

 List<SqlStatement> statements = new ArrayList<>();
 
 JdbcConnection connection = (JdbcConnection) database.getConnection();
 try {
 ResultSet persons = connection.createStatement().executeQuery("select nom, prenom from person");
 while (persons.next()) {
 // Write your complex logic in here !
 // and generate SqlStatement(s)
 }
 } catch (DatabaseException | SQLException e) {
 throw new CustomChangeException(e);
 }
 
 SqlStatement insert = new InsertStatement(database.getDefaultCatalogName(), database.getDefaultSchemaName(), "person")
 .addColumnValue("nom", "Gay")
 .addColumnValue("prenom", "Jean-Christophe");
 
 SqlStatement update = new UpdateStatement(database.getDefaultCatalogName(), database.getDefaultSchemaName(), "person")
 .addNewColumnValue("prenom", "Jc")
 .setWhereClause(String.format("nom='%s'", Gay))
 
 statements.add(insert);
 statements.add(update);
 
 return statements.toArray(new SqlStatement[statements.size()]);
 }
 
 @Override
 public String getConfirmationMessage() {
 return null;
 }

 @Override
 public void setUp() throws SetupException {}

 @Override
 public void setFileOpener(ResourceAccessor resourceAccessor) {}

 @Override
 public ValidationErrors validate(Database database) {
 return null;
 }
}

La principale logique se passe dans la méthode generateStatements. L’API de Liquibase nous donne accès à la connexion Jdbc et il suffit de générer des SqlStatement pour décrire son refactoring.
Le reste des méthodes à implémenter permet de valider la configuration, accéder à des fichiers, etc. La Javadoc explique tout ça.

Configurer son changeset
#

L’élément customChange permet de déclarer la classe implémentant le refactoring.

<changeSet id="20140606-super-complex-change" author="jc.gay">
 <customChange class="fr.jcgay.MyCustomChangeThatGenerateSql" />
</changeSet>

Et voilà on peut décrire des changements complexes dans son langage préféré !

Réparation environnement Python après un brew cleanup

Sun, 26 Oct 2014 18:31:00 +0200

J’ai récemment exécuté un brew cleanup pour nettoyer toutes les anciennes versions des paquets non utilisés. Depuis virtualenv ne fonctionne plus… voilà comment j’ai pu m’en sortir.

Arrrghhhh
#

Après activation d’un environnement :

. ~/virtualenvs/pelican/bin/activate

En lançant par exemple la génération de mon blog avec Pelican :

dyld: Library not loaded: @executable_path/../.Python
 Referenced from: /Users/jcgay/virtualenvs/pelican/bin/python
 Reason: image not found

Mais pourquoi tout est cassé ?
#

Quand on crée un environnement avec virtualenv celui-ci crée des liens vers votre installation de Python. Par exemple à la racine d’un environnement isolé on a :

.Python -> /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/Python

En effectuant un brew cleanup les anciennes versions de Python sont supprimées. Les environnements utilisant ces versions deviennent inopérants.

Réparation de l’environnement
#

On installe un find GNU :

brew install findutils

On supprime tous les liens symboliques erronés :

gfind ~/virtualenvs/pelican/ -type l -xtype l -delete

On recrée l’environnement :

virtualenv ~/virtualenvs/pelican

Et là nouvelle erreur…

zsh: /usr/local/bin/virtualenv: bad interpreter: /usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Ver: no such file or directory

On réinstalle virtualenv :

pip uninstall virtualenv
pip install virtualenv

On recrée l’environnement :

virtualenv ~/virtualenvs/pelican

Et voilà tout fonctionne à nouveau !

Sources
#

How to fix your virtualenv after an upgrade of Python with Homebrew
Broken references in Virtualenvs
Trouble using mkvirtualenv after installing OS X Mavericks

A la découverte de Java 8

Sun, 04 May 2014 17:58:00 +0200

Java 8 est maintenant disponible depuis plusieurs semaines, voici un “petit” résumé des fonctionalités de Java 8 que j’ai testé à travers tous les articles sur lesquels je suis tombé.

Default methods sur les Interfaces
#

Java 8 utilise le mot clef default pour définir une implémentation par défaut au sein d’une interface.
C’est utile pour les développeurs d’API, c’était même indispensable pour la plupart des nouveautés du langage sinon comment enrichir les interfaces comme java.util.Collection sans briser toutes les implémentations existantes ?

public interface A {
 default void printSomething() {
 System.out.println("something");
 }
}

public class Implementation implements A {}

La classe Implementation n’a pas besoin de définir la méthode printSomething.

public class Examples {
 public static void main(String[] args) {
 new Implementation().printSomething();
 }
}

Que ce passe t-il si deux interfaces implémentent la même méthode par défaut et qu’une classe implémente ces deux interfaces ?

public interface B {
 default void printSomething() {
 System.out.println("something else");
 }
}

public class DoesNotCompile implements A,B {}

Et bien le code précédent ne compile pas:

class DoesNotCompile inherits unrelated defaults for printSomething() from types A and B

On est obligé de surcharger la méthode dans l’implémentation pour résoudre le conflit,

public class ItCompiles implements A,B {

 @Override
 public void printSomething() {
 System.out.printf("I can print what I want !");
 }
}

Pour faire référence à une des méthodes par défaut :

public class ItCompilesToo implements A,B {

 @Override
 public void printSomething() {
 B.super.printSomething();
 }
}

Je pense que cette fonctionalité va être très utile pour les développeurs de librairies, on va pouvoir oublier les fameuses classes abstraites dont il fallait hériter pour ne pas risquer de tout casser lors de mises à jour d’interfaces.

Expressions Lambda
#

Surement une des évolutions les plus attendues, une expression lambda est une sorte de méthode “anonyme”. Jusqu’à aujourd’hui en Java pour simuler ce comportement on utilisait une classe anonyme qui implémentait une interface avec une seule méthode abstraite (SAM).

List<Integer> numbers = asList(10, 1, 1000, 100);

Collections.sort(numbers, new Comparator<Integer>() {
 @Override
 public int compare(Integer a, Integer b) {
 return a.compareTo(b);
 }
});

peut-etre remplacé par :

Collections.sort(numbers, (a, b) -> a.compareTo(b));

Le compilateur est capable de trouver les types des paramètres, pas besoin de les préciser et la méthode tenant sur une ligne, on peut également omettre les {} et le return.

Accès variable locale
#

Contrairement à une classe anonyme, une expression lambda peut accéder aux variables locales même si celles ci ne sont pas déclarées comme étant final.

Integer n = 4;
Function<Integer, Integer> modulo = (Integer a) -> a % n;

assert modulo.apply(8) == 0;

mais en fait il faut qu’elles le soient, le code suivant ne compile pas :

Integer n = 4;
Function<Integer, Integer> modulo = (Integer a) -> a % n;
n = 8;

avec comme erreur :

local variables referenced from a lambda expression must be final or effectively final

Membre et variable static
#

Contrairement aux variables locales, les membres de classe sont accessibles en écriture.

public class Lambda {

 private static int staticNumber;
 private int number;

 public void write() {
 Function<Integer, Integer> function = (Integer a) -> staticNumber = a;
 Function<Integer, Integer> function2 = (Integer a) -> number = a;
 }
}

Functional Interfaces
#

Les expressions lambda ne sont en fait pas si “anonymes” que ça. Elles correspondent en fait à des types spécifiés par des interfaces avec exactement une méthode abstraite. C’est pour ça que les classes anonymes implémentant une interface de type SAM peuvent être remplacées par des expressions lambda.
Java 8 propose l’annotation @FunctionalInterface pour s’assurer qu’une interface ne déclare qu’une seule méthode abstraite.

@FunctionalInterface
public interface Function<T, R> {

 R apply(T t);
}

Si une deuxième méthode abstraite est ajoutée la compilation échoue :

Function is not a functional interface, multiple non-overriding abstract methods found in interface

Lambda
#

On peut ajouter des méthodes par defaut sur une @FunctionalInterface.

@FunctionalInterface
public interface A {

 default void printSomething() {
 System.out.println("something");
 }

 void print();
}

mais on ne peut pas accéder à ces méthodes depuis une lambda.

A doesNotCompile = () -> printSomething();

Function, Predicate, etc
#

De nombreuses @FunctionalInterface sont disponibles par défaut. D’anciennes interfaces de l’API ont été migrées, Comparable et Runnable par exemple. Si vous connaissez déjà Guava vous ne serez pas complètement perdu.

Function
#

Une Function prend un argument et retourne un résultat.

Function<Integer, String> toString = n -> String.valueOf(n);
Function<String, Integer> toInteger = s -> Integer.valueOf(s);

assert "4".equals(toString.apply(4));
assert toInteger.apply("4") == 4;

assert "4".equals(toString.compose(toInteger).apply("4"));
assert toString.andThen(toInteger).apply(4) == 4;

La méthode compose applique la fonction toInteger puis la fonction toString alors que la méthode andThen applique toString puis toInteger.

BiFunction
#

C’est un spécialisation d’une Function qui prend deux arguments et retourne un résultat.

BiFunction<Integer, String, String> concat = (Integer i, String s) -> s + ": " + i;

assert "un: 1".equals(concat.apply(1, "un"));

UnaryOperator
#

C’est une Function qui prend un argument et retourne un résultat du même type. Par exemple la fonction identity retourne toujours la valeur passée en argument.

assert UnaryOperator.identity().apply("un").equals("un");

BinaryOperator
#

Un BinaryOperator est une spécialisation d’une BiFunction dont les paramètres et le résultat partagent le même type.

BinaryOperator<String> concatString = (s1, s2) -> s1.concat(": ").concat(s2);

assert "un: 1".equals(concatString.apply("un", "1"));

Predicate
#

Un Predicate prend un argument et retourne un booléen.

Predicate<String> isEmpty = s -> s == null || s.isEmpty();
Predicate<String> isTrimmed = s -> s.equals(s.trim());
 
assert isEmpty.test(null) == true;
assert isEmpty.test("") == true;
assert isEmpty.test("not empty") == false;

assert isEmpty.negate().and(isTrimmed).test("not empty") == true;
assert isEmpty.negate().and(isTrimmed).test(" not empty ") == false;

assert isEmpty.or(isTrimmed).test("") == true;
assert isEmpty.or(isTrimmed).test("not empty") == true;

assert Predicate.isEqual("hello").test("hello") == true;

negate inverse un prédicat,
and et or permettent de chaîner des prédicats selon l’opérateur logique,
La méthode statique isEqual teste l’égalité de deux objets selon Object#equals

BiPredicate
#

Un BiPredicate prend deux arguments et retourne un booléen.

Supplier
#

Un Supplier ne prend pas d’argument et produit un résultat.

Supplier<String> emptyString = () -> "";

assert "".equals(emptyString.get());

Consumer
#

Un Consumer prend un argument mais ne retourne pas de résultat.

Consumer<String> print = s -> System.out.println(s);
Consumer<String> hello = s -> System.out.printf("Hello %s !", s);

print.accept("something"); // something
print.andThen(hello).accept("JC"); // JC Hello JC !

La méthode andThen permet de chaîner les consommateurs.

Comparator
#

Les Comparator sont devenus des FunctionalInterface.

Comparator<Integer> ascending = (a, b) -> a.compareTo(b);

assert ascending.compare(10, 1) > 0;
assert ascending.reversed().compare(10, 1) < 0;

Sans grande surprise reversed inverse la comparaison.
Il existe des méthodes par défaut pour appliquer une Function avant le Comparator dans les différents thenComparating.

A retenir
#

Ça fait beaucoup d’interfaces fonctionnelles (et je n’ai même pas lister les versions spécifiques pour les types primitifs), ce qu’il faut retenir :

s’il n’y a pas de retour, on utilise un Consumer,
s’il faut retourner un booléen, on utilise un Predicate,
s’il faut produire un numérique primitif (int, double, long), on utilise un (Type)ToIntFunction, (Type)ToDoubleFunction, (Type)ToLongFunction,
s’il faut retourner une valeur sans prendre d’argument, c’est un Supplier,
si le seul argument de la fonction est un int, double, long on utilise un Int(something), Double(something), Long(Something),
si la fonction prend deux arguments, c’est une Bi(something),
si la fonction prend deux arguments de même type, c’est un BinaryOperator,
si une fonction retourne une valeur de même type que son unique argument, c’est un UnaryOperator,
si une fonction prend en argument un type primitif et un autre type sans retourner de valeur, c’est un Obj(Int|Double|Long)Consumer,
sinon c’est une Function.

Surcharge de méthode
#

On peut surcharger une méthode utilisant une FunctionalInterface en paramètre par une autre plus spécifique (la manière classique d’overloading).

Par exemple, un BinaryOperator est une spécialisation d’une BiFunction,

public class A {

 public void is(BiFunction<Boolean, Boolean, Boolean> function) {
 System.out.println("bifunction");
 }

 public void is(BinaryOperator<Boolean> function) {
 System.out.println("binaryoperator");
 }
}

le code suivant affichera "binaryoperator"

new A().is((a, b) -> true);

Par contre le compilateur ne peut pas toujours trouvé “un type le plus spécifique”. Dans le cas où les types en questions n’ont pas de relation, seul le nombre d’arguments de la FunctionalInterface permet de différencier les méthodes surchargées.

@FunctionalInterface
public interface StringPredicate {
 boolean test(String string);
}

public class A {

 public void anotherMethod(Predicate<String> predicate) {
 System.out.println("predicate");
 }

 public void anotherMethod(StringPredicate predicate) {
 System.out.println("string predicate");
 }
}

Le code suivant ne compile pas

new A().anotherMethod(input -> true);

reference to anotherMethod is ambiguous
both method anotherMethod(java.util.function.Predicate<java.lang.String>) in fr.jcgay.example.java.overload.A and method anotherMethod(fr.jcgay.example.java.overload.StringPredicate) in fr.jcgay.example.java.overload.A match

Même si c’est techniquement possible, je ne suis pas sûr que ce soit une super idée de surcharger de telles méthodes, dans le premier cas par exemple la résolution est bien moins claire lors de la manipulation de l’expression lambda que lors de cas classiques de surcharge où l’on manipule directement des types.

Références de méthodes
#

Java 8 introduit le mot clef :: pour extraire des références de méthodes. C’est utile pour remplacer des expressions lambda qui se contentent de faire appel à une méthode qui existe déjà.

On peut remplacer :

Function<Integer, String> toString = n -> String.valueOf(n);

par :

Function<Integer, String> toString = String::valueOf;

On peut faire référence à des méthodes statiques mais aussi directement depuis une instance,

String hello = new String("hello");
Predicate<String> startsWith = hello::startsWith;

assert startsWith.test("he") == true;

et aux constructeurs,

Supplier<String> newString = String::new;

et aussi aux méthodes d’instance sans référence d’objet en particulier :

List<String> names = Arrays.asList("Barbara", "James", "Mary", "John");
Collections.sort(names, String::compareToIgnoreCase);

Fonctionnement
#

C’est bien magique mais comment on détermine qu’une méthode existante est compatible avec une FunctionalInterface ?

statique
#

La plus simple à se représenter, il suffit que la dite méthode ait bien la même signature que la méthode unique de l’interface désirée.

Par exemple, on peut écrire notre Function toString précédente,

Function<Integer, String> toString = new Function<Integer, String>() {
 @Override
 public String apply(Integer integer) {
 return String.valueOf(integer);
 }
};

String#valueOf(Integer) est bien utilisable pour implémenter Function<Integer, String>#apply(Integer), et remplacer une expression lambda par une référence de méthode statique.

instance
#

Ce type de référence permet de capturer une instance qui sera utilisée lors de l’évaluation de l’expression lambda.

Ainsi notre exemple du début revient à écrire :

String hello = new String("hello");
Predicate<String> startsWith = new Predicate<String>() {
 @Override
 public boolean test(String s) {
 return hello.startsWith(s);
 }
};

instance arbitraire
#

Ce sont les plus difficiles à se représenter au début. Ces références permettent de pointer des méthodes sur des instances qui seront découvertes à l’exécution. En fait celà veut dire que l’instance en question sera le premier argument de l’expression lambda et le reste des paramètres seront ceux passés à la méthode en référence.

Reprenons l’exemple de la comparaison de chaînes de caractères,

BiFunction<String, String, Integer> concat = new BiFunction<String, String, Integer>() {
 @Override
 public Integer apply(String self, String argument) {
 return self.compareToIgnoreCase(argument);
 }
};

Optional
#

C’est un conteneur pour une valeur qui peut être null. Ce conteneur possède deux états, contenant une valeur ou ne contenant rien.
Retourner un Optional à la place d’un null permet d’obliger le traitement du cas “pas de valeur de retour”.

Optional<String> hello = Optional.of("hello");

assert hello.isPresent() == true;
assert "hello".equals(hello.get());

Si la valeur contenu est null,

Optional<Object> absent = Optional.ofNullable(null);

assert absent.isPresent() == false;
absent.get() // throws java.util.NoSuchElementException: No value present

La classe Optional regorge de méthodes utilitaires pour transformer/filtrer la valeur qu’il contient, pour retourner une valeur par défaut et également un orElseThrow qui pour le coup n’existe pas dans Guava.

Stream
#

Un Stream est une séquence d’éléments sur laquelle on peut effectuer des opérations. Un Stream se compose d’une source (un tableau, une collection, etc), de zéro ou plusieurs opérations intermédiaires (transformation du Stream en un autre via filter par exemple) et d’une opération terminale (qui produit le résultat).
Les calculs ne sont effectués qu’à l’initialisation de l’opération finale et la source est consommée que si c’est nécessaire.

On peut créer un Stream à partir d’une collection en utilisant la méthode stream(),

List<Person> persons = asList(
 new Person("John", "Doe", 30),
 new Person("Jane", "Doe", 20),
 new Person("Jim", "Smith", 15)
 );

assert persons.stream().count() == 3;

En utilisant IntStream, DoubleStream, LongStream pour créer des Stream numériques,

assert IntStream.range(0, 10).sum() == 45;

Ou encore avec différentes méthodes utilitaires sur la classe Stream,

Stream.of("a", "b", "c").forEach(System.out::println);

Stream.builder().add("a").add("b").add("c")
 .build()
 .forEach(System.out::println);

Un Stream peut-être infini, dans ce cas il faut avoir une opération stoppante,

Random random = new Random();
Stream.generate(() -> random.nextInt())
 .limit(10)
 .forEach(System.out::println);

new Random().ints()
 .limit(10)
 .forEach(System.out::println);

En gros il y a des Stream un peu partout :)

forEach
#

Effectue une opération sur chacun des éléments en utilisant un Consumer. C’est une opération terminale qui consomme le Stream. On ne peut pas appeler d’autres opérations après un forEach.

persons.stream()
 .forEach(p -> System.out.println(p.getLastName() + " " + p.getFirstName()));

// Doe John
// Doe Jane
// Smith Jim

filter
#

Accepte un Predicate pour filtrer les éléments. C’est une opération intermédiaire qui nous permet donc de chaîner d’autres opérations à sa suite.

persons.stream()
 .filter(p -> p.getLastName().startsWith("D"))
 .forEach(System.out::println);

// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

sorted
#

Une opération intermédiaire qui permet de trier les éléments à l’aide d’un Comparable.

persons.stream()
 .sorted((p1, p2) -> p1.getFirstName().compareTo(p2.getFirstName()))
 .forEach(System.out::println);

// Person{firstName='Jane', lastName='Doe', age=20}
// Person{firstName='Jim', lastName='Smith', age=15}
// Person{firstName='John', lastName='Doe', age=30}

map
#

Applique une Function sur les éléments, c’est également une opération intermédiaire.

persons.stream()
 .map(Person::getAge)
 .sorted()
 .forEach(System.out::println);
 
// 15
// 20
// 30

allMatch, anyMatch, noneMatch
#

Plusieurs méthodes permettant de vérifier que zéro/un/des éléments vérifient un Predicate. Toutes ces opérations sont terminales.

assert persons.stream()
 .allMatch(p -> p.getFirstName().startsWith("J"))
 == true;

assert persons.stream()
 .noneMatch(p -> p.getAge() == 35)
 == true;
 
assert persons.stream()
 .anyMatch(p -> "Doe".equals(p.getLastName()))
 == true;

count
#

Une opération terminale qui retourne le nombre d’élément dans un Stream.

assert persons.stream()
 .filter(p -> p.getAge() >= 20)
 .count()
 == 2;

sum
#

Retourne la somme de tous les éléments.

assert IntStream.rangeClosed(1, 10).sum() == 55;

reduce
#

C’est une opération terminale qui réduit les éléments du Stream avec un BinaryOperator.
On obtient au final le résultat sous la forme d’un Optional,

On va créer un monstre en fusionnant nos personnes,

persons.stream()
 .reduce((p1, p2) -> new Person(p1.getFirstName(), p2.getLastName(), p1.getAge() + p2.getAge()))
 .ifPresent(System.out::println);

// Person{firstName='John', lastName='Smith', age=65}

On peut additionner les âges de nos personnes,

assert persons.stream()
 .map(Person::getAge)
 .reduce(0, Integer::sum)
 == 65;

L’argument idendity est l’élément identité de la réduction, il ne doit avoir aucun effet sur la fonction d’accumulation (accumulator dans la signature de reduce). C’est le cas ici puisque x + 0 = x.

Et on peut encore écrire le reduce sous la forme

assert persons.stream()
 .reduce(0,
 (result, person) -> result + person.getAge(),
 (a, b) -> a + b
 )
 == 65;

L’accumulator définit l’opération effectué sur chacun des éléments et retient ce résultat tandis que le combiner décrit l’opération effectuée pour combiner deux résultats de la fonction accumulator.
Cette fois ci identity ne doit pas avoir d’effet sur le combiner.
La fonction combiner doit être associative pour assurer la cohérence du résultat lors du traitement du Stream en parallèle.

collect
#

Permet de réunir tous les éléments en utilisant un Collector. C’est bien entendu une opération terminale.

persons.stream()
 .map(Person::getLastName)
 .collect(Collectors.toList());

// [Doe, Doe, Smith]

La classe Collectors regorge d’implémentations de Collector pour faciliter l’opération.
On peut en avoir un très bon aperçu dans la présentation de José Paumard : Java 8 Streams & Collectors : patterns, performances, parallélisation

concat
#

On peut concaténer des Stream.

IntStream.concat(
 IntStream.range(0, 4),
 IntStream.range(4, 6)
).forEach(System.out::print);

// 012345

findFirst, findAny
#

Des opérations terminales qui permettent de retourner le premier élément du Stream s’il existe en tant qu’Optional,

persons.stream()
 .findFirst()
 .ifPresent(System.out::print);

// Person{firstName='John', lastName='Doe', age=30}

ou encore n’importe quel élément,

persons.stream()
 .parallel()
 .findAny()
 .ifPresent(System.out::print);

Le résultat de findAny n’est pas constant, le résultat peut varier.

flatMap
#

C’est une opération intermédiraire qui permet de mettre à plat un Stream.
On peut par exemple transformer un Stream<List<Person>> en Stream<Person> via une Function<List<Person>, Stream<Person>> :

Stream.<List<Person>>builder()
 .add(asList(new Person("John", "Doe", 30), new Person("Jane", "Doe", 20)))
 .add(asList(new Person("Jim", "Smith", 15)))
 .build()
 .flatMap(persons -> persons.stream())
 .filter(person -> "Doe".equals(person.getLastName()))
 .forEach(System.out::println);
 
// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

limit, skip
#

Permet de se déplacer ou de bloquer le nombre d’éléments d’un Stream. Ce sont des opérations intermédiaires.

persons.stream()
 .limit(2)
 .skip(1)
 .findFirst()
 .ifPresent(System.out::print);

// 	Person{firstName='Jane', lastName='Doe', age=20}

min, max
#

Des opérations terminales pour trouver le minimum ou le maximum (en tant qu’Optional) d’un Stream s’ils existent à l’aide d’un Comparator.

assert IntStream.rangeClosed(1, 10)
 .min()
 .getAsInt()
 == 1;

assert IntStream.rangeClosed(1, 10)
 .max()
 .getAsInt()
 == 10;

peek
#

Une méthode utile pour débugger entre les opérations efféctuées sur un Stream. C’est une opération intermédiaire qui exécute un Consumer sur chacun des éléments.

persons.stream()
 .filter(p -> "Doe".equals(p.getLastName()))
 .peek(System.out::println)
 .filter(p -> p.getAge() < 25)
 .peek(System.out::println)
 .collect(Collectors.toSet());

// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

// Person{firstName='Jane', lastName='Doe', age=20}

Parallel Stream
#

Par défaut les opérations effectuées sur un Stream sont séquentielles. Pour paralléliser les processus il suffit d’utiliser la méthode parallel.
On peut changer l’état d’un Stream au cours de son utilisation en utilisant sequential et parallel.
Bien ententu il ne s’agit pas d’utiliser parallel sur chaque Stream en espèrant un temps de traitement moins long (ça peut même être le contraire). Il conviendra donc de s’assurer de la pertinence de son utilisation.

Map
#

Les Map ne sont pas compatibles avec les Stream. Elles ont quand même le droit à leur lot de nouvelles fonctionalités.

putIfAbsent
#

Associe une valeur avec une clef seulement si la clef n’existe pas encore ou si la valeur associée à la clef vaut null.

Map<String, String> map = new HashMap<>();

assert map.putIfAbsent("key", null) == null;
assert map.get("key") == null;

assert map.putIfAbsent("key", "value") == null;
assert map.get("key").equals("value");

assert map.putIfAbsent("key", "new-value").equals("value");
assert map.get("key").equals("value");

forEach
#

Utilise un BiConsumer pour consommer tous les couples d’une Map.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);
map.put("trois", 3);

map.forEach((key, value) -> System.out.printf("%s(%d) ", key, value));

// trois(3) un(1) deux(2)

computeIf
#

Permet d’appliquer une BiFunction sur les valeurs de la map.

compute
#

Si la Function retourne null, le couple est supprimé de la map.

assert map.compute("un", (key, value) -> null) == null;
assert map.compute("deux", (key, value) -> value == null ? null : value + 2) == 4;

// trois(3) deux(4) 

computeIfAbsent
#

Tente la création d’une valeur pour une clef si celle-ci n’est associée à aucune valeur (ou si elle est null) en utilisant une Function.

assert map.computeIfAbsent("un", key -> null) == 1;
assert map.computeIfAbsent("quatre", key -> 4) == 4;

// trois(3) quatre(4) un(1) deux(2)

computeIfPresent
#

Tente de mettre à jour la valeur associée à une clef si la valeur en question est non-null avec une BiFunction. Si la Function retourne null, le couple est supprimé de la Map.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);
map.put("trois", 3);
map.put("quatre", null);

assert map.computeIfPresent("trois", (key, value) -> value + 5) == 8;
assert map.computeIfPresent("un", (key, value) -> null) == null;
assert map.computeIfPresent("quatre", (key, value) -> value + 5) == null;

// trois(8) quatre(null) deux(2)

remove
#

Supprime l’Entry pour la clef en argument si et seulement si la valeur associée à cette clef est égale à celle en argument.

assert map.remove("un", 1) == true;
assert map.remove("deux", 3) == false;

// trois(3) deux(2) 

getOrDefault
#

Retourne une valeur par défaut si aucune valeur n’est associée à la clef en argument.

assert map.getOrDefault("un", -1) == 1;
assert map.getOrDefault("six", -1) == -1;

merge
#

Associe la valeur non-null en argument à une clef si cette clef n’est pas déjà associée à une valeur (ou si la valeur est null), sinon applique la BiFunction sur la valeur existante.

Map<Integer, String> map = new HashMap<>();
map.put(1, "un");
map.put(2, "deux");

assert map.merge(1, " exemple", String::concat).equals("un exemple");
assert map.merge(2, "exemples", (key, value) -> null) == null;

// 1(un exemple) 

replace, replaceAll
#

Remplace une valeur associée à une clef si cette valeur est égale à celle en argument.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);

assert map.replace("un", 1, 5) == true;
assert map.replace("deux", 3, 5) == false;

// un(5) deux(2)

Remplace toutes les valeurs en appliquant la BiFunction en paramètre

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);

map.replaceAll((key, value) -> "un".equals(key) ? value + 1 : value + 2);

assert map.get("un") == 2;
assert map.get("deux") == 4;

Date
#

Une toute nouvelle API pour les dates est disponible dans le package java.time. Elle s’inspire de Joda-Time et toutes les classes de cette API sont enfin immuables et threadsafe !

LocalTime
#

Cette classe représente une heure au sein d’une journée sans information de timezone, c’est l’heure qu’on affiche sur une horloge.

LocalTime time1 = LocalTime.of(13, 37, 26);
LocalTime time2 = LocalTime.of(15, 47, 54);

assert time1.isBefore(time2) == true;

LocalTime time3 = time1.plusMinutes(5);

assert ChronoUnit.HOURS.between(time1, time2) == 2;
assert ChronoUnit.MINUTES.between(time1, time3) == 5;

time1.format(DateTimeFormatter.ISO_LOCAL_TIME); // 13:37:26
time3.format(DateTimeFormatter.ofPattern("Ha")); // 13PM

DateTimeFormatter formatter = DateTimeFormatter
 .ofLocalizedTime(FormatStyle.SHORT)
 .withLocale(Locale.FRANCE);
LocalTime time4 = LocalTime.parse("17:17", formatter);

assert time4.getHour() == 17;
assert time4.getMinute() == 17;

LocalDate
#

Représente une date sans information d’heures, c’est ce qu’on utilise pour une date de naissance.

LocalDate today = LocalDate.now();
LocalDate tomorrow = today.plus(1, ChronoUnit.DAYS);
LocalDate yesterday = today.minusDays(1);

LocalDate birthday = LocalDate.of(2014, Month.DECEMBER, 18);
assert birthday.getDayOfWeek() == DayOfWeek.THURSDAY;

DateTimeFormatter formatter = DateTimeFormatter
 .ofLocalizedDate(FormatStyle.LONG)
 .withLocale(Locale.FRANCE);
LocalDate date = LocalDate.parse("14 juillet 2014", formatter);

assert date.getDayOfMonth() == 14;
assert date.getMonth() == Month.JULY;
assert date.getYear() == 2014;

LocalDateTime
#

Et voilà une date avec des heures mais toujours sans timezone. L’API reste toujours très similaire aux Local* précédents.

LocalDateTime time = LocalDateTime.of(2014, Month.DECEMBER, 25, 12, 10);
assert time.get(ChronoField.YEAR) == 2014;

time.format(DateTimeFormatter.ofPattern("dd/MM/yyyy HH:mm")); // 25/12/2014 12:10

ZonedDateTime
#

La version ultime avec une timezone en plus.

ZonedDateTime today = ZonedDateTime.now(ZoneId.of("Europe/Paris"));
System.out.println(today.format(DateTimeFormatter.ISO_ZONED_DATE_TIME)); 

// 2014-04-21T20:26:53.275+02:00[Europe/Paris]

ZoneId
#

Cette classe représente les timezone manipulables dans l’API.

ZoneId.getAvailableZoneIds();
// [Asia/Aden, America/Cuiaba, Etc/GMT+9, Etc/GMT+8, Africa/Nairobi, America/Marigot...

ZoneId paris = ZoneId.of("Europe/Paris");
paris.getDisplayName(TextStyle.FULL, Locale.FRENCH); // Heure d'Europe centrale
paris.getDisplayName(TextStyle.SHORT, Locale.FRENCH); // CET

Instant
#

Représente un instant au cours du temps.

Instant.parse("2007-12-03T10:15:30.00Z");

On peut récupérer cet objet un peu partout depuis l’API, par exemple

Instant now = LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant();
// 2014-04-21T19:27:26.759Z

Et il permet de créer un bon vieux java.util.Date pour la compatibilité.

Date.from(now)

Clock
#

Permet l’accès à l’Instant courant.

Instant now = Clock.system(ZoneId.of("Europe/Paris")).instant();
// 2014-04-21T19:36:37.786Z

long millis = Clock.systemDefaultZone().millis();
// 1398109144935

Duration
#

Représente une quantité de temps comme 42 secondes.

Duration twentySeconds = Duration.parse("PT20S");
assert twentySeconds.getSeconds() == 20;

Duration oneMinuteTwentySeconds = Duration.ofMinutes(1).plus(twentySeconds);
assert oneMinuteTwentySeconds.getSeconds() == 80;

LocalTime time1 = LocalTime.of(21, 30, 17);
LocalTime time2 = LocalTime.of(22, 40, 37);
Duration duration = Duration.between(time1, time2); // PT1H10M20S
assert duration.get(ChronoUnit.SECONDS) == 3600 + 600 + 20; 

Du sucre
#

StringJoiner
#

On peut enfin concaténer des String séparées par un délimiteur sans utiliser de librairies.

String join = new StringJoiner(",")
 .add("a")
 .add("b")
 .add("c")
 .toString();
assert join.equals("a,b,c");

String join = String.join(",", asList("a", "b", "c"));
assert join.equals("a,b,c");

Calendar.Builder
#

La mise en place du pattern Builder pour la classe Calendar.
Des exemples sont disponibles dans l’article http://marxsoftware.blogspot.fr/2013/05/jdk-8-calendar-builder.html.

Base64
#

Plus besoin non plus d’utiliser une librairie pour encoder des données en Base64.

Base64.getEncoder().encode("JC".getBytes()); //SkM=

Annotations
#

Les annotations peuvent être déclarées sur les utilisations des types.

Instantiation d’une classe :

new @Interned MyObject();

Cast :

myString = (@NonNull String) str;

Implémentation d’une interface :

class UnmodifiableList<T> implements
 @Readonly List<@Readonly T> { ... }

Déclaration des Exceptions:

void monitorTemperature() throws
 @Critical TemperatureException { ... }

Java 8 introduit la possibilité de rendre une annotation @Repeatable.

Vous avez déjà certainement vu le schéma d’utilisation suivant :

une annotation d’un certain type, au hasard @JoinColumn,
une seconde prenant comme paramètre un tableau d’éléments du premier type, @JoinColumns.

Et on écrivait ensuite

@JoinColumns({
 @JoinColumn(name="ADDR_ID", referencedColumnName="ID"),
 @JoinColumn(name="ADDR_ZIP", referencedColumnName="ZIP")
})
public Address getAddress() { return address; }

On peut maintenant se contenter de

@JoinColumn(name="ADDR_ID", referencedColumnName="ID"),
@JoinColumn(name="ADDR_ZIP", referencedColumnName="ZIP")
public Address getAddress() { return address; }


si l'annotation `@JoinColumn` est annotée avec `@Repeatable(JoinColumns.class)`.

Création
#

Il faut continuer de créer deux types.

public @interface Descriptions {
 Description[] value();
}

@Repeatable(Descriptions.class)
public @interface Description {
 String value();
}

@Description pourra être répétée dans utiliser @Descriptions.

@Description("toto")
@Description("tata")
public class Repeat {}

En fait c’est le compilateur qui utilisera @Descriptions de manière transparente pour l’utilisateur.

Lecture
#

Description[] byType = Repeat.class.getAnnotationsByType(Description.class);
assert byType.length == 2;

Description withoutType = Repeat.class.getAnnotation(Description.class);
assert withoutType == null;

Descriptions byContainer = Repeat.class.getAnnotation(Descriptions.class);
assert byContainer != null;
assert byContainer.value().length == 2;

On voit qu’il faut utiliser Class#getAnnotationsByType pour lire une annotation @Repeatable et que le compilateur a bien ajouté une annotation @Descriptions pour englober les @Description.

Nashorn
#

C’est un moteur Javascript executé au sein de la JVM ! Jusque là était disponible Rhino mais Nashorn est une nouvelle implémentation basée sur invokedynamic.

Il est possible d’interpréter du js en ligne de commande avec l’utilitaire jjs disponible dans le jdk.

jjs 
jjs> print("hello");
hello

Mais on peut surtout embarquer le moteur dans ses programmes Java.

ScriptEngineManager engineManager = new ScriptEngineManager();
ScriptEngine engine = engineManager.getEngineByName("nashorn");
engine.eval("function sum(a, b) { return a + b; }");

assert (int) engine.eval("sum(1, 2);") == 3;

Il existe de nombreuses possibilités d’intéraction entre votre code Java et le js évalué. L’article Oracle Nashorn: A next-generation JavaScript engine for the JVM présente toutes ces fonctionalités.

jdeps
#

Un analyseur de dépendances fait son apparition dans les outils du JDK.

jdeps -v Examples.class 
Examples.class -> /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar
 fr.jcgay.example.java.Strings.Examples -> java.lang.AssertionError
 fr.jcgay.example.java.Strings.Examples -> java.lang.CharSequence
 fr.jcgay.example.java.Strings.Examples -> java.lang.Class
 fr.jcgay.example.java.Strings.Examples -> java.lang.Iterable
 fr.jcgay.example.java.Strings.Examples -> java.lang.Object
 fr.jcgay.example.java.Strings.Examples -> java.lang.String
 fr.jcgay.example.java.Strings.Examples -> java.util.Arrays
 fr.jcgay.example.java.Strings.Examples -> java.util.List
 fr.jcgay.example.java.Strings.Examples -> java.util.StringJoiner

Direction l’article http://marxsoftware.blogspot.fr/2014/03/jdeps.html pour en savoir plus.

Profils
#

Des sous-ensembles de l’API ont été définis et permettent de réduire la taille de la JVM : guide.

Javadoc
#

La section “Method Summary” a évoluée légèrement en regroupant maintenant les méthodes par type (Exemple).

Javadoc method summary

Un outil de validation a fait son apparition, doclint, malheureusement activé par défaut. Il y a peu de chance que votre documentation soit valide… Tout est très bien expliqué ici

Metaspace
#

La suppression de la Permanent Generation (PermGen) laisse place au Metaspace.
Java 8 from PermGen to Metaspace
Metaspace in Java 8

Sources, pour aller plus loin
#

Understanding Method References
Java 8 tutorial
10 features in Java 8 you haven’t heard of
Annotations Basics
50 nouvelles choses que l’on peut faire avec Java 8
Java time
Java 8 features

Le cycle de vie de son build Maven

Sat, 22 Mar 2014 19:24:00 +0200

Avec Maven, je me suis souvent retrouvé un peu seul devant un POM en me demandant ce que pouvait bien exécuter mon build sans devoir aller lister toutes les exécutions déclarées. Depuis Maven 3 il est possible de prévoir ce qu’un build va exécuter au sein de son cycle de vie. Etrangement il n’y a rien qui permet d’afficher facilement ce plan de build calculé. Voici le buildplan-maven-plugin.

Configuration
#

Pour utiliser le plugin facilement, déclarer son groupId au sein de la configuration de Maven (ie settings.xml) :

<pluginGroups>
 <pluginGroup>fr.jcgay.maven.plugins</pluginGroup>
</pluginGroups>

Afficher le plan du build
#

Il est possible de lister toutes les exécutions de goals qui font parties du build. La simulation se déroule jusqu’à la phase deploy.

> mvn buildplan:list

[INFO] --- buildplan-maven-plugin:1.0:list (default-cli) @ buildplan-maven-plugin ---
[INFO] --------------------------------------------------------------------------------------------------------------------
[INFO] PLUGIN | PHASE | ID | GOAL
[INFO] --------------------------------------------------------------------------------------------------------------------
[INFO] maven-plugin-plugin | generate-sources | help-goal | helpmojo
[INFO] maven-plugin-plugin | process-classes | default-descriptor | descriptor
[INFO] maven-resources-plugin | process-resources | default-resources | resources
[INFO] maven-compiler-plugin | compile | default-compile | compile
[INFO] maven-plugin-plugin | process-classes | mojo-descriptor | descriptor
[INFO] maven-resources-plugin | process-test-resources | default-testResources | testResources
[INFO] maven-compiler-plugin | test-compile | default-testCompile | testCompile
[INFO] maven-surefire-plugin | test | default-test | test
[INFO] animal-sniffer-maven-plugin | process-classes | check-signature | check
[INFO] maven-jar-plugin | package | default-jar | jar
[INFO] maven-plugin-plugin | package | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] maven-source-plugin | package | attach-sources | jar-no-fork
[INFO] license-maven-plugin | verify | default | check
[INFO] maven-install-plugin | install | default-install | install
[INFO] maven-deploy-plugin | deploy | default-deploy | deploy

Lister les phases du plan
#

Une vue par phase au sein du build est disponible. On peut ainsi voir rapidement quels plugins seront exécutés au sein d’une phase.

> mvn buildplan:list-phase

[INFO] --- buildplan-maven-plugin:1.0:list-phase (default-cli) @ buildplan-maven-plugin ---
[INFO] install ------------------------------------------------------------------------------------------
[INFO] + maven-install-plugin | default-install | install
[INFO] generate-sources ---------------------------------------------------------------------------------
[INFO] + maven-plugin-plugin | help-goal | helpmojo
[INFO] process-resources --------------------------------------------------------------------------------
[INFO] + maven-resources-plugin | default-resources | resources
[INFO] test ---------------------------------------------------------------------------------------------
[INFO] + maven-surefire-plugin | default-test | test
[INFO] test-compile -------------------------------------------------------------------------------------
[INFO] + maven-compiler-plugin | default-testCompile | testCompile
[INFO] process-test-resources ---------------------------------------------------------------------------
[INFO] + maven-resources-plugin | default-testResources | testResources
[INFO] verify -------------------------------------------------------------------------------------------
[INFO] + license-maven-plugin | default | check
[INFO] process-classes ----------------------------------------------------------------------------------
[INFO] + maven-plugin-plugin | default-descriptor | descriptor
[INFO] + maven-plugin-plugin | mojo-descriptor | descriptor
[INFO] + animal-sniffer-maven-plugin | check-signature | check
[INFO] compile ------------------------------------------------------------------------------------------
[INFO] + maven-compiler-plugin | default-compile | compile
[INFO] package ------------------------------------------------------------------------------------------
[INFO] + maven-jar-plugin | default-jar | jar
[INFO] + maven-plugin-plugin | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] + maven-source-plugin | attach-sources | jar-no-fork
[INFO] deploy -------------------------------------------------------------------------------------------
[INFO] + maven-deploy-plugin | default-deploy | deploy

Pour filtrer la description d’une seule phase, utiliser le paramètre buildplan.phase :

mvn buildplan:list-phase -Dbuildplan.phase=test

Lister les plugins
#

On peut grouper les exécutions par plugin.

> mvn buildplan:list-plugin

[INFO] --- buildplan-maven-plugin:1.0:list-plugin (default-cli) @ buildplan-maven-plugin ---
[INFO] maven-deploy-plugin -------------------------------------------------------------------------
[INFO] + deploy | default-deploy | deploy
[INFO] maven-source-plugin -------------------------------------------------------------------------
[INFO] + package | attach-sources | jar-no-fork
[INFO] license-maven-plugin ------------------------------------------------------------------------
[INFO] + verify | default | check
[INFO] maven-resources-plugin ----------------------------------------------------------------------
[INFO] + process-resources | default-resources | resources
[INFO] + process-test-resources | default-testResources | testResources
[INFO] maven-plugin-plugin -------------------------------------------------------------------------
[INFO] + generate-sources | help-goal | helpmojo
[INFO] + process-classes | default-descriptor | descriptor
[INFO] + process-classes | mojo-descriptor | descriptor
[INFO] + package | default-addPluginArtifactMetadata | addPluginArtifactMetadata
[INFO] maven-jar-plugin ----------------------------------------------------------------------------
[INFO] + package | default-jar | jar
[INFO] animal-sniffer-maven-plugin -----------------------------------------------------------------
[INFO] + process-classes | check-signature | check
[INFO] maven-surefire-plugin -----------------------------------------------------------------------
[INFO] + test | default-test | test
[INFO] maven-compiler-plugin -----------------------------------------------------------------------
[INFO] + compile | default-compile | compile
[INFO] + test-compile | default-testCompile | testCompile
[INFO] maven-install-plugin ------------------------------------------------------------------------
[INFO] + install | default-install | install

Le paramètre buildplan.plugin permet de filtrer un plugin en particulier :

mvn buildplan:list-plugin -Dbuildplan.plugin=maven-compiler-plugin

Et voilà comment on peut explorer ce que va exécuter Maven pendant un build !

Migration de WordPress vers Pelican

Mon, 17 Mar 2014 20:31:00 +0200

Retour sur la migration d’un blog construit avec WordPress pour un site statique généré avec Pelican.

Mais pourquoi ?
#

Tout simplement pour avoir quelque chose de plus léger… J’avais volontairement gardé mon installation de WordPress minimaliste mais l’outil prends du poids par nature (en tout cas pour des fonctionalités que je n’utilisais pas). Peu de plugins étaient installés mais les temps de chargement ne me convenaient pas (hébergement mutualisé pour du PHP).

Comme j’écrivais déjà mes textes en Markdown pour les convertir en HTML et les coller dans l’éditeur de WordPress, j’ai sauté le pas pour un générateur de contenu statique.

Pelican
#

Pelican est un générateur de site statique écrit en Python. Il supporte Markdown, AsciiDoc et reStructuredText.
Il en existe une pléthore, les plus connus étant certainement Jekyll et Octopress.
J’ai choisi Pelican car il propose une fonctionalité multilangue, ce qu’il est possible de faire avec les autres mais pas de manière native.

Installation
#

Pour l’utiliser avec OS X :

brew install python
pip install virtualenv

## Install Pelican
mkdir -p ~/virtualenvs/pelican
virtualenv ~/virtualenvs/pelican
cd ~/virtualenvs/pelican
. bin/activate
pip install pelican
pip install Markdown
pip install beautifulsoup4
pip install typogrify
pip install webassets
pip install cssmin

Sinon l’installation est détaillée ici.

Activer l’environnement Pelican
#

. ~/virtualenvs/pelican/bin/activate

Quitter l’environnement Pelican
#

deactivate

Créer un site
#

Il suffit de lancer pelican-quickstart et de suivre les instructions.

Welcome to pelican-quickstart v3.3.0.

This script will help you create a new Pelican-based website.

Please answer the following questions so this script can generate the files
needed by Pelican.


> Where do you want to create your new web site? [.] blog
> What will be the title of this web site? Jean-Christophe Gay
> Who will be the author of this web site? Jean-Christophe Gay
> What will be the default language of this web site? [en] fr
> Do you want to specify a URL prefix? e.g., http://example.com (Y/n) Y
> What is your URL prefix? (see above example; no trailing slash) http://jeanchristophegay.com
> Do you want to enable article pagination? (Y/n) Y
> How many articles per page do you want? [10]
> Do you want to generate a Fabfile/Makefile to automate generation and publishing? (Y/n) Y
> Do you want an auto-reload & simpleHTTP script to assist with theme and site development? (Y/n) Y
> Do you want to upload your website using FTP? (y/N) N
> Do you want to upload your website using SSH? (y/N) N
> Do you want to upload your website using Dropbox? (y/N) N
> Do you want to upload your website using S3? (y/N) N
> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
Done. Your new project is available at /Users/jcgay/blog

Les source générées:

blog
├── Makefile
├── content
│   ├── (pages)
├── develop_server.sh
├── fabfile.py
├── output
├── pelicanconf.py
└── publishconf.py

2 directories, 5 files

Ajouter du contenu
#

Les articles doivent être ajoutés dans le dosser content. Il est possible d’extraire le contenu de WordPress pour l’importer dans Pelican : http://docs.getpelican.com/en/3.3.0/importer.html#import

Je ne l’ai pas testé car j’avais déjà des versions Markdown de mes articles. Je me suis contenté d’ajouter les métadonnées nécessaires à Pelican dans mes fichiers .md.

Pour qu’un article soit indexé comme tel par Pelican, il faut ajouter les métadonnées:

Title: git-p4 au secours de Perforce
Date: 2012-03-18 18:10
Category: Scm
Tags: git, git-p4, perforce, p4
Slug: git-p4-au-secours-de-perforce
Author: Jean-Christophe Gay
lang: fr

La propriété slug permettra de conserver les mêmes URLs que celles utilisées par WordPress.

Choisir un thème
#

Les thèmes sont disponibles dans le repository https://github.com/getpelican/pelican-themes.

Pour le moment j’ai choisi le thème elegant.

Cloner le répository des thèmes Pelican pour pouvoir les utiliser par la suite.

Les plugins
#

Pelican est extensible par l’intermédiaire de plugins. Ils sont répertoriés dans le repository https://github.com/getpelican/pelican-plugins. Comme pour les thèmes il suffit de cloner le repository dans l’emplacement de son choix.

La liste des plugins que j’ai activé:

sitemap : génère un fichier sitemap.xml pour l’indexation.
tipue_search : moteur de recherche au sein du site sans utiliser un service tiers.
extract_toc : extait une table des matières du contenu d’un article.
optimize_images : compresse les images jpeg et png.
related_posts : affiche une liste d’article en relation avec l’article lu.
summary : défini un résumé de l’article en utilisant le tag  dans les articles.
assets : permet de minifier/compiler les resources statiques.

Configuration
#

La configuration est séparée en deux fichiers: pelicanconf.py et publishconf.py. Le second surcharge le premier avec les paramètres utilisés lors de la génération du site de production.

Tous les paramètres sont documentés ici.

Je n’ai pas rencontré de difficultés particulières, deux petites astuces quand même.

Pour générer des URLs identiques à celles que j’avais avec WordPress :
```
 ARTICLE_URL = '{slug}'
 ARTICLE_SAVE_AS = '{slug}/index.html'
```

Pour chaque article, un dossier est créé avec la valeur de la métadonnée slug contenant un fichier index.html.

Il est possible de copier des fichiers avec la propriété EXTRA_PATH_METADATA :

 EXTRA_PATH_METADATA = {
 'extra/humans.txt': {'path': 'humans.txt'},
 'extra/robots.txt': {'path': 'robots.txt'},
 'extra/.htaccess': {'path': '.htaccess'},
 }

Les commentaires
#

Si vous utilisez le système de commentaires de WordPress, il faut les migrer vers un service externe, par exemple Disqus. C’est déjà ce que j’utilisais mais sinon il suffit d’installer le plugin WordPress.

Pour chacun des articles, ajouter l’identifiant de chaque fil de discussion :

disqus_identifier: 7 http://jeanchristophegay.com/?p=7

C’est supporté par le thème elegant.

Règles de redirection
#

Il faut réécrire les URLs qui vont disparaitre pour ne pas perdre toutes vos URLs qui se baladent dans la nature.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule feed/?$ feeds/rss.xml [R=301,L]
RewriteRule wp-content/uploads/2013/03/Capture-d’écran-2013-03-09-à-11.24.20-300x182.png images/p4merge-mini.png [R=301,L]
RewriteRule wp-content/uploads/2013/03/Capture-d’écran-2013-03-09-à-11.24.20.png images/p4merge.png [R=301,L]
# Redirect wp-content/uploads/2012/03/git-p4.png to images/git-p4.png
RewriteRule wp-content/uploads/[0-2][0-9][0-9][0-9]/[0-1][0-9]/([^/]+) images/$1 [R=301,L]
# Redirect 2012/04 to archives.html#2012
RewriteRule ([0-2][0-9][0-9][0-9])/[0-1][0-9]/? archives.html#$1 [R=301,NE,L]
# Redirect category/slug/ to categories.html#slug-ref
RewriteRule category/([^/]+)/? categories.html#$1-ref [R=301,NE,L]
# Redirect tag/slug/ to tags.html#slug-ref
RewriteRule tag/([^/]+)/? tags.html#$1-ref [R=301,NE,L]
# Redirect author/jcgay/ to /
RewriteRule author/jcgay/? / [R=301,L]
</IfModule> 

Tester/Publier son site
#

Pour générer le site, lancer make html && make serve.
Le contenu est généré dans le dossier output et accessible via http://localhost:8000.

Le contenu final est disponible en utilisant make publish. Il ne reste qu’à uploader le contenu en ligne.

Conclusion
#

Je suis plutôt satisfait du résultat, tout le site est généré à partir d’un simple repository git, celà permet de versionner correctement le contenu du site et j’ai les fonctionalités nécessaires à la publication de quelques articles de temps en temps. Mission Accomplie !

Configurer Idea pour développer en Scala sous OS X

Sun, 13 Oct 2013 10:59:00 +0200

Mini guide pour démarrer son environnement de développement Scala pour IntelliJ Idea sous OS X.

Installation SBT et Scala
#

Avec le gestionnaire de paquet Homebrew :

brew install scala --with-docs 
brew install sbt 

Pour passer des options supplémentaires à la JVM lors de l’utilisation de SBT, celà se passe via $SBT_OPTS ou dans le fichier ~/.sbtconfig. Utiliser les paramètres "-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256M" pour commencer.

Configuration IntelliJ Idea
#

Direction la gestion des plugins et installer le plugin Scala disponible dans les plugins maintenus par JetBrains.
Le reste de la configuration se déroulera lors de la première création d’un projet.

Création d’un projet (à la main)
#

Dans Idea, Create New Project puis choisir Scala Module :

Choisir un nom de projet
Utiliser /usr/local/opt/scala/idea en tant que Scala Home
Cocher Make global libraries

Le projet est prêt !

Les avertissements ne sont pas activés par défaut à la compilation, l’IDE vous prévient quand même qu’il faut activer certaines options pour avoir le détail des avertissements avec des messages de type : scala: there were 1 feature warning(s); re-run with -feature for details
Il suffit d’aller les options du projet, Open module settings > Facets > Scala et de cocher les avertissements désirés ou de spécifier l’option voulu dans le champ Additional compiler options.

Création d’un projet (SBT)
#

Structure du build
#

La structure d’un projet est assez classique pour un langage de la JVM : mkdir -p src/{main,test}/{scala,java,resources}
L’outil de build majeur dans l’univers scala est SBT, le descripteur du projet prend la forme d’un fichier build.sbt:

scalaVersion := "2.10.3"

name := "mon-projet-scala"

version := "1.0"

scalacOptions ++= Seq("-unchecked", "-deprecation", "-feature")

Les options ajoutées à scalac permettent d’afficher les avertissements les plus courants lors de la compilation.
Les lignes vides ne sont pas une blague, c’est vraiment nécessaire à SBT pour détecter la fin d’une propriété de configuration…

Génération des fichiers projets IntelliJ Idea
#

Dans sa version actuelle (12.1.6), Idea n’intègre pas encore SBT, on ne peut donc pas importer un projet à partir de son descripteur de build comme il est possible de le faire avec Maven ou Gradle.
Il faut donc générer la configuration du projet à l’aide du plugin sbt-idea.
Créer le fichier ~/.sbt/0.13/plugins/build.sbt pour déclarer le plugin de manière globale. Le plugin sera utilisable sur tous les projets sans devoir le déclarer dans chaque build.sbt. 0.13 correspondant à la version de SBT utilisée, ajouter :

addSbtPlugin("com.github.mpeltonen" % "sbt-idea" % "1.5.1")

A la racine du projet exécuter sbt gen-idea pour générer toute la configuration.

Le projet peut maintenant est ouvert dans IntelliJ Idea.

Il se peut que le compilateur scala soit configuré un peu n’importe comment, dans ce cas il faut aller dans les options du projet pour sélectionner un compiler library correct (celui créer en tant que global library par exemple) et supprimer ceux qui sont incorrects.

Mais, ça ne fonctionne pas les scripts ?!
#

Tous les exemples présentés pour apprendre le langage sont souvent des scripts.
Si vos scripts sont écrits dans des fichiers .scala, Idea essaie de les compiler et échoue :

expected class or object definition
println("hello world")
^

La solution consiste à renommer le script avec l’extension .sc, ce qui le transforme en scala worksheet (source).

Et voilà !

Publier son site Maven sur GitHub Pages

Sat, 17 Aug 2013 18:10:00 +0200

Tout fier de son projet hébergé sur GitHub, il existe un mécanisme de publication de site statique, les GitHub Pages. Petit tour de piste pour configurer le déploiement de site Maven sur cet espace.

The Maven way
#

Le maven-site-plugin permet de déployer les sites via différents protocoles configurables avec des providers wagon. Coup de chance il existe une section pour l’utilisation des gh-pages: Deploying your Maven site to GitHub’s gh-pages.
Malheureusement je n’ai pas réussi à le faire fonctionner… Je suis tombé sur ce ticket qui donne des pistes (enfin pas sûr que ça fonctionne au final) mais qui indique surtout qu’il faut utiliser Maven SCM Publish Plugin.
Par contre ce n’est pas intégré à la fonctionalité de reporting de Maven, pas de mvn site-deploy out of the box.
Je ne l’ai pas testé, je me suis plutôt rabattu sur le plugin maven développé par GitHub qui avait l’air de répondre à mes attentes.

Plugin GitHub
#

Dans le repository officiel de GitHub est disponible le Site Plugin.
Un petit peu de configuration :

<plugin>
 <artifactId>maven-site-plugin</artifactId>
 <version>3.3</version>
 <configuration>
	 <skipDeploy>true</skipDeploy>
 </configuration>
</plugin>
<plugin>
 <groupId>com.github.github</groupId>
 <artifactId>site-maven-plugin</artifactId>
 <version>0.8</version>
 <configuration>
	 <message>Creating site for ${project.version}</message>
	 <repositoryOwner>_</repositoryOwner>
 <repositoryName>_</repositoryName>
 <server>github</server>
 </configuration>
 <executions>
	 <execution>
 	 <phase>site-deploy</phase>
 <goals>
 	 <goal>site</goal>
 </goals>
 </execution>
 </executions>
</plugin>

avec
repositoryOwner: nom d’utilisateur,
repositoryName: nom du repository,
server: identifiant du serveur dans settings.xml

<servers>
 <server>
 <id>github</id>
 <username>GitHubLogin</username>
 <password>GitHubPassw0rd</password>
 </server>
</servers>

Et voilà mvn site-deploy génère et publie le site sur vos gh-pages (peut prendre une dizaine de minutes avant qu’il ne soit disponible).

Si vous ne l’avez pas encore fait, pensez à utiliser le skin maven-fluido-skin qui modernise le rendu de votre site !

Les exceptions dans les tests unitaires

Tue, 18 Jun 2013 19:30:00 +0200

Il existe différentes solutions pour écrire des assertions sur les exceptions. Le choix de l’une ou l’autre se fait généralement selon les tests que l’on souhaite écrire… tour d’horizon des différents choix possibles.

@Test(expected) avec JUnit
#

@Test(expected = IndexOutOfBoundsException.class)
public void should_throw_exception() throws Exception {
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected exception: java.lang.IndexOutOfBoundsException

C’est la méthode la plus simple, le code est compact et le but du test est clair. On ne peut pas effectuer d’autres assertions au sein du test (celui-ci s’arrête dès que l’exception attendue est levée), c’est un bien mais aussi un mal… Le message de l’exception n’est pas testable, ce qui est pourtant bien pratique.

@Rule ExpectedException avec JUnit
#

@Rule
public ExpectedException thrownException = ExpectedException.none();

@Test
public void should_throw_exception() throws Exception {
 thrownException.expect(IndexOutOfBoundsException.class);
 thrownException.expectMessage(containsString("2"));
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected test to throw an instance of java.lang.IndexOutOfBoundsException

JUnit possède de nombreuses règles (@Rule) utilisables dans les tests. Celle-ci est dédiée aux exceptions. Cette solution permet, contrairement à la première, de réaliser des assertions plus précises sur l’exception levée. On peut vérifier le message, la présence ou non de cause, etc. En utilisant des matchers Hamcrest le message est testable de manière fine.

Je trouve dommage de devoir écrire ses assertions avant l’appel au code testé, l’ordre de lecture se retrouve inversé mais on s’en accommode assez bien.

@Test(expectedExceptions) avec TestNG
#

@Test(expectedExceptions = IndexOutOfBoundsException.class, expectedExceptionsMessageRegExp = "2")
public void should_throw_exception() throws Exception {
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

Method TestNGExpectedTest.should_fail_because_no_exception_is_thrown()[...] should have thrown an exception of class java.lang.IndexOutOfBoundsException

Quand le message ne correspond pas :

org.testng.TestException: The exception was thrown with the wrong message: expected "2" but got "3"

Cette méthode avec TestNG ressemble beaucoup à celle de JUnit sauf que l’on peut tester le message ! Pratique et suffisant dans la majorité des cas. On utilise une expression régulière pour valider le message.

Etrangement expectedExceptions permet de renseigner un tableau d’Exception attendues, pas sûr que celà serve la lecture et la robustesse du test…

try / fail / catch
#

@Test
public void should_trow_exception() throws Exception {
 try {
 asList(0, 1).get(2);
 failBecauseExceptionWasNotThrown(IndexOutOfBoundsException.class);
 } catch (IndexOutOfBoundsException e) {
 assertThat(e).hasNoCause()
 .hasMessage("2");
 }
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected IndexOutOfBoundsException to be thrown

Quand les autres solutions ne suffisent pas, par exemple pour tester un type personnalisé avec des données spécifiques ou pour vérifier la cause d’une exception, on peut toujours se reposer sur cette solution. Le test produit est assez verbeux mais le plus gros problème à mon sens est l’oubli du fail(). Si les tests sont écrits après le code de production, il est malheureusement assez facile de l’oublier au sein du bloc try.

catch-exception
#

@Test
public void should_throw_exception() throws Exception {

 catchException(asList(0, 1)).get(2);

 assertThat(caughtException())
 .isInstanceOf(IndexOutOfBoundsException.class)
 .hasMessage("2")
 .hasNoCause();
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expecting actual not to be null

catch-exception permet également de tester l’exception levée de manière très précise mais possède l’avantage de ne pas devoir écrire ses assertions dans le bloc catch. Plus de soucis d’oubli du fail() (caughtException() retourne null si aucune exception n’est levée). Le code est également moins verbeux que le try / catch / fail.

L’outil possède d’autres variantes d’écriture documentées sur son site. La forme présentée ici est celle que je préfère, puisque malheureusement la version BDD repose sur l’utilisation de FEST-assert 1.4.

Conclusion
#

Avec TestNG, j’utilise expectedExceptions quand le type de l’exception et son message sont suffisants pour mon test. Sinon avec JUnit ou pour des tests plus précis, j’utilise catch-exception avec AssertJ.

De la couleur dans les logs

Sat, 04 May 2013 18:22:00 +0200

Dans la quête de couleur, je me suis intéressé aux logs des applications Java. En fait il est très simple de configurer les différents frameworks de logs pour éclairer son quotidien.

Logback
#

L’implémentation ConsoleAppender expose une propriété withJansi qui permet d’activer la coloration des logs. Il suffit ensuite d’utiliser un des pattern disponibles dans PatternLayout (celui configuré par défaut) pour customiser ses logs :

%red, %boldRed, etc
%highlight

Ces mots clefs sont censés encapsuler d’autres expressions. La couleur sera appliquée sur l’expression contenue entre parenthèses.

[%thread] %highlight(%-5level) %cyan(%logger{15}) - %msg %n

%highlight est une conversion qui permet de séparer les différents niveaux de logs. Une erreur sera affichée en rouge et en gras, un warn en rouge et un info en bleu.

<configuration>
 <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
 <withJansi>true</withJansi>
 <encoder>
 <pattern>%d{HH:mm:ss.SSS} [%thread] %highlight(%-5level) %logger{36} - %msg%n</pattern>
 </encoder>
 </appender>

 <root level="trace">
 <appender-ref ref="STDOUT" />
 </root>
</configuration>

Sous Windows il est nécessaire d’ajouter la librairie Jansi à l’exécution de l’application.

<dependency>
 <groupId>org.fusesource.jansi</groupId>
 <artifactId>jansi</artifactId>
 <version>1.10</version>
 <scope>runtime</scope>
</dependency>

Documentation officielle : http://logback.qos.ch/manual/layouts.html#coloring

Log4j 2.0
#

Dans la nouvelle version de Log4j, le pattern %highlight est également disponible dans l’implémentation PatternLayout. Les couleurs par défaut sont différentes de celles de Logback mais il est possible de les surcharger :

%highlight{%d [%t] %-5level: %msg%n%throwable}{FATAL=white, ERROR=red, WARN=blue, INFO=black, DEBUG=green, TRACE=blue}

voir même d’utiliser les mêmes codes couleurs que Logback :

%highlight{%d [%t] %-5level: %msg%n%throwable}{STYLE=Logback}

Le deuxième pattern disponible est %style{pattern}{ANSI style}. Il permet de choisir une couleur pour une portion de texte. La liste complète des couleurs est disponible dans la documentation de Log4j 2.

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="OFF">
 <appenders>
 <Console name="Console" target="SYSTEM_OUT">
 <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %highlight{%-5level} %logger{36} - %msg%n"/>
 </Console>
 </appenders>
 <loggers>
 <root level="trace">
 <appender-ref ref="Console"/>
 </root>
 </loggers>
</configuration>

Sous Windows il est nécessaire d’ajouter la librairie Jansi à l’exécution de l’application.

<dependency>
 <groupId>org.fusesource.jansi</groupId>
 <artifactId>jansi</artifactId>
 <version>1.10</version>
 <scope>runtime</scope>
</dependency>

Log4j
#

Pas de solution officielle disponible pour le bon vieux Log4j… J’ai écrit un Appender et un Layout (logj4-color) qui permettent d’utiliser le pattern #highlight pour coloriser les logs. Les couleurs utilisées sont :

FATAL, rouge
ERROR, rouge
WARN, jaune
INFO, gras

L’appender AnsiConsoleAppender doit être utilisé sous Windows. Sinon le ConsoleAppender suffit.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
 <appender name="console" class="com.github.jcgay.log4j.color.appender.AnsiConsoleAppender">
 <param name="Target" value="System.out"/>
 <layout class="com.github.jcgay.log4j.color.layout.ColorEnhancedPatternLayout">
 <param name="ConversionPattern" value="#highlight(%-5p) %c{1} - %m%n"/>
 </layout>
 </appender>

 <root>
 <priority value ="trace" />
 <appender-ref ref="console" />
 </root>

</log4j:configuration>

Il suffit d’ajouter la librairie log4j-color à l’exécution de l’application.

<project>
 ...
 <repositories>
 <repository>
 <id>jcgay-releases</id>
 <url>https://repository-jcgay.forge.cloudbees.com/release/</url>
 </repository>
 </repositories>
 ...
 <dependencies>
 <dependency>
 <groupId>com.github.jcgay.log4j</groupId>
 <artifactId>log4j-color</artifactId>
 <version>0.1</version>
 <scope>runtime</scope>
 </dependency>
 </dependencies>
 ...
</project>

Plugins pour les IDE
#

Pour profiter de toutes ces couleurs dans son IDE préféré, il faudra utiliser des plugins pour améliorer les consoles disponibles : IntelliJ Idea : Grep Console Eclipse : Ansi Console

Maven: complétion, couleurs et notifications de bureau

Sun, 14 Apr 2013 14:02:00 +0200

Maven, out of the box n’est pas l’outil le plus sexy du monde… Utilisé dans un IDE, il saura se faire oublié mais il mérite mieux lors de son usage en ligne de commande.

Complétion
#

Il existe des scripts de complétion automatique des commandes Maven.

Les utilisateurs de bash pourront compter sur :

maven-bash-completion, une représentation statique de plugins/goals/options. Celà fonctionne très bien, malheureusement il faut que chaque plugin soit décrit pour pouvoir être reconnu.
Un second script maintenu dans le paquet ubuntu de maven. Il fonctionne sur la même base que le précédent.

Si vous utilisez zsh, deux solutions sont disponibles :

le plugin mvn au sein du framework oh-my-zsh s’occupe de la complétion. En cadeau on a également tout une collection d’alias très pratique.
dans zsh-completions, un script permet de découvrir les goals de manière automatique à la première utilisation d’un plugin (mvn plugin:<TAB>). La première exécution est un peu plus longue mais après la complétion est instantanée (Merci à Thomas Queste qui en a parlé dans les commentaires).

Notifications de bureau
#

Avoir un build rapide c’est bien… seulement il arrive que ce ne soit pas du tout le cas. Rester devant sa console pour un build qui dure plusieurs minutes n’a pas vraiment d’intérêt… Pouvoir être notifié du résultat à la fin de son build devient alors indispensable.

maven-notifier
#

J’ai développé une extension Maven qui permet d’envoyer une notification à la fin d’un build : maven-notifier. Il fonctionne avec tous les systèmes d’exploitation.
Par défaut, l’extension tentera de trouver un notifier disponible sur la machine depuis cette liste d’outils.
Il est possible de configurer le système de notification utilisé et bien d’autres choses (format des messages, etc) en créant un fichier maven-notifier.properties.

Notifier	Capture d’écran
Growl, disponible pour Windows et OS X.	maven-notifier-growl
Snarl, disponible pour Windows	maven-notifier-snarl
terminal-notifier, OS X
notification center OS X (depuis Mavericks)
notify-send pour Linux
SystemTray depuis Java 6
Pushbullet	maven-notifier-pushbullet
Kdialog utilisable avec KDE	maven-notifier-kdialog
notifu disponible pour Windows	maven-notifier-notifu
AnyBar pour OS X et Linux	maven-notifier-anybar
Toaster pour Windows 8
Notify since Java 6
BurntToast for Windows 10
Slack

Les scripts
#

On peut aussi se contenter de wrapper la commande mvn pour récupérer son statut et envoyer une notification.

Growl via growlnotify : Intégration de Growl avec Maven, maven-growl
notification center via terminal-notifier : maven-notification-center
notify-send : Intégration de notify-send avec Maven.

Couleurs
#

La sortie console de Maven est toute terne. Il n’est pas toujours facile d’y retrouver les messages d’erreurs et c’est encore pire pour les messages d’avertissement…

maven-color
#

maven-color ajoute de la couleur dans les logs de Maven.

Les dernières versions de Maven (depuis la version 3.1.x) utilisent SLF4J en interne, cela veut dire que l’on peut choisir l’implémentation de log que l’on veut !
Cet article très complet explique comment avoir une console en couleur avec Log4j 2 ou Logback. C’est la technique utilisée par maven-color

Pour les versions plus anciennes (entre la 3.0.x et la 3.1.0), j’ai utilisé Jansi et remplacé les loggers utilisés en interne par Maven avec un agent. Cela fonctionne avec les goals interactifs, par contre c’est beaucoup moins facile à mettre en place et bien moins résistant aux changements d’implémentation au sein de Maven et du plugin Surefire… maven-color.

Les scripts
#

On peut ajouter un peu de couleur pour y voir plus clair :

Ces scripts sont très biens et faciles à mettre en place, malheureusement ils ne fonctionnent pas avec les goals interactifs. N’espérez pas utiliser maven-release-plugin ou maven-archetype-plugin en mode interactif, les messages de demande de saisis n’apparaitront pas.

Tout en un (pour OS X)
#

Comme c’était dommage de réinstaller toutes ces extensions à la main pour chaque version de Maven, j’ai créé une formule pour brew.

brew tap jcgay/jcgay
brew install maven-deluxe

Celà installera la dernière version de Maven, maven-notifier, maven-color et maven-profiler.

Conclusion
#

Xzibit

Thanks Xzibit for pimping my Maven !

Git mergetool avec P4Merge sous MacOS

Sat, 09 Mar 2013 12:40:00 +0200

Quelque soit le gestionnaire de sources que l’on utilise, vient toujours le moment où des conflits apparaissent lors des merge. Dans ces cas là, chacun sa technique, personnellement, que ce soit pour l’affichage d’un diff ou un merge, je préfère les outils graphiques. J’ai longtemps utilisé les outils de tortoise sous Windows, mais à force de papillonner entre différents OS, j’ai cherché un outil disponible sur toutes les plateformes. Et je me suis finalement arrêté sur P4Merge…

Malgré un rendez-vous manqué avec Perforce (git-p4), l’outil de merge disponible au sein de la distribution de Perforce est plutôt réussi (une fois que l’on a compris le mécanisme de sélection à l’aide des trois coquillages).

Installation
#

Télécharger une distribution Perforce : http://www.perforce.com/downloads/complete_list
Copier p4merge dans /Applications

Direction /usr/local/bin, créer un script nommé p4merge avec le contenu :

#!/bin/sh

/Applications/p4merge.app/Contents/Resources/launchp4merge "$@"

Rendre le script exécutable : chmod +x p4merge

Configuration de git
#

[merge]
 conflictStyle = diff3
	tool = p4merge
[mergetool]
	keepBackup = false
	keepTemporaries = false
	prompt = false

Utilisation
#

Et voilà, git difftool et git mergetool utiliseront maintenant P4Merge !

JRebel, le redéploiement c'est à chaud !

Sat, 02 Feb 2013 16:12:00 +0200

Quand on développe des applications web Java EE, on passe généralement son temps à redéployer son application et redémarrer son conteneur… Heureusement on peut compter depuis un moment sur JRebel pour grandement augmenter sa productivité lors des développements en permettant le rechargement à chaud des modifications de façon plus poussé que le Hot Swap intégré à la JVM.

Fonctionnement
#

JRebel est un agent java qui va surveiller les modifications de notre application et les appliquées au sein de la JVM à chaud. Pour celà, l’agent va scanner le classpath à la recherche de fichiers rebel.xml décrivant les ressources à surveiller.

Installation
#

La documentation de JRebel met l’accent sur l’intégration avec les IDE (Eclipse, IntelliJ Idea, Netbeans, MyEclipse) et est très bien faite : JRebel IDE Plugins Personnellement j’utilise rarement les fonctionnalités de déploiement intégrés dans les IDE (peut-être à cause de wtp dans Eclipse…) et préfère utilisé un serveur embedded (dans un plugin Maven par exemple) ou même directement le serveur d’application installé sur mon poste.

On a donc besoin de télécharger une archive de JRebel, disponible ici : Télécharger JRebel

Une fois dezippé, il faut exécuter la configuration de JRebel via bin/jrebel-config.{cmd|sh} et suivre les instructions de l’assistant. Pour ajouter l’agent JRebel à la JVM : -noverify -javaagent:$JREBEL_HOME/jrebel.jar

Configuration de votre application
#

Il faut maintenant s’intéresser à la génération des fichiers de configuration rebel.xml. Il existe un plugin Maven pour faire le travail à notre place : http://zeroturnaround.com/software/jrebel/maven/

<plugin>
 <groupId>org.zeroturnaround</groupId>
 <artifactId>jrebel-maven-plugin</artifactId>
 <version>1.1.3</version>
 <configuration>
 <classpath>
 <resources>
 <resource>
 <includes>
 <include>com/github/jcgay/**</include>
 </includes>
 </resource>
 <resource>
 <directory>src/main/resources</directory>
 </resource>
 </resources>
 </classpath>
 </configuration>
 <executions>
 <execution>
 <id>generate-rebel-xml</id>
 <phase>generate-resources</phase>
 <goals>
 <goal>generate</goal>
 </goals>
 </execution>
 </executions>
</plugin>

Le plugin se base sur le type de votre module pour générer la configuration par défaut (pour par exemple intégrer src/main/webapp aux ressources surveillées). Ce comportement peut-être surchargé si par exemple votre webapp utilise le type maven jar en utilisant war au sein de la configuration du plugin. Le plugin fonctionne très bien au sein des projets multi-module. On peut filtrer avec des include/exclude les ressources à intégrer dans le rechargement de JRebel.

Les chemins générés au sein de la configuration sont absolus par défaut (donc spécifique à votre environnement), il est possible de variabiliser les chemins générés pour les rendre relatifs. Je n’ai jamais utilisé la fonctionalité (je ne package pas la configuration JRebel dans mes artifacts finaux) mais c’est toujours bon à savoir.

Toutes les possibilités de configuration du rebel.xml sont décrites ici : documentation rebel.xml

Vérification du fonctionnement
#

Si l’agent est correctement configuré, on obtient au lancement de la JVM :

[2013-01-25 16:16:04] #############################################################
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] JRebel 5.1.1 (201211271929)
[2013-01-25 16:16:04] (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] Over the last 30 days JRebel prevented 
[2013-01-25 16:16:04] at least 95 redeploys/restarts saving you about 3.9 hours.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] This product is licensed to ******
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] The following plugins are disabled at the moment: 
[2013-01-25 16:16:04] * Click plugin (set -Drebel.click_plugin=true to enable)
[2013-01-25 16:16:04] * JRuby Plugin (set -Drebel.jruby_plugin=true to enable)
[2013-01-25 16:16:04] * Jersey plugin (set -Drebel.jersey_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Core plugin (set -Drebel.adf_core_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Faces plugin (set -Drebel.adf_faces_plugin=true to enable)
[2013-01-25 16:16:04] * RESTlet plugin (set -Drebel.restlet_plugin=true to enable)
[2013-01-25 16:16:04] * Seam-Wicket plugin (set -Drebel.seam_wicket_plugin=true to enable)
[2013-01-25 16:16:04] * Spring Data Plugin (set -Drebel.spring_data_plugin=true to enable)
[2013-01-25 16:16:04] * WebObjects plugin (set -Drebel.webobjects_plugin=true to enable)
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] #############################################################

Puis les ressources qui sont surveillées :

[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/target/classes' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/webapp' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/resources will be monitored for changes.

Les classes seront maintenant rechargées dès qu’elles sont compilées depuis l’IDE (pour peu que celui ci soit bien configuré pour compiler les classes au même endroit que Maven).

Les ressources sont rechargées après un hit sur le serveur d’application. Pour chaque ressource rechargée, une entrée est loggée :

[2012-12-20 11:33:56] JRebel: Reloading class 'com.github.jcgay.app.Person'.

Notes
#

La génération de la configuration via le plugin Maven est liée à la phase “generate-resources”. Il est possible que le reste du build écrase cette configuration (par exemple de l’overlay de war, ou du tissage d’aspect à partir du build d’un war dans ses modules). Génaralement dans ce cas je change la phase d’exécution du plugin Maven pour une phase postérieure à celle qui pose problème…
Attention à bien cocher “I use Maven to build my application” dans l’assistant de configuration de JRebel, sinon vous verrez surement le monitoring de plugin JRebel correctement s’activé mais pas celui des ressources de l’application.
Dans IntelliJ Idea, pour que la compilation se fasse bien dans le même répertoire que Maven, il faut cocher “Use Maven output directories”.
Toujours dans Idea, si l’on utilise le debugger, celui si se retrouvera désynchronisé dès la prise en compte d’un rechargement à chaud. Dans ce cas il faut installer le plugin JRebel, et ajouter la propriété -Drebel.debugger_integration=true au lancement de la JVM.

Jenkins dans son IDE favoris

Sun, 15 Jul 2012 20:25:00 +0200

Se tenir informer de l’état de son (ses) build(s) est primordial dès lors que l’on utilise un environnement d’intégration continue. Quand on a de la chance on a un buildwall dans son espace de travail au milieu des développeurs… sinon c’est un peu du chacun pour sa peau.

Ma solution préférée (différente des mails et autre moyen de notifications) consiste à monitorer Jenkins depuis son IDE.

Eclipse
#

Il existe un connecteur mylyn pour Jenkins (et aussi Hudson). Celui-ci permet de suivre le statut des jobs que l’on choisit et bien plus encore.

Installation
#

Pré requis : Le plugin Mylyn doit être installé. Pour la dernière version d’Eclipse (Juno), le connecteur est disponible dans le répository mylyn. Direction Help > Install new software... > Mylyn for Eclipse Juno > Mylyn Integrations > Mylyn Build Connector: Hudson/Jenkins pour dérouler le processus d’installation et redémarrage d’Eclipse.

Configuration
#

Une nouvelle entrée est disponible dans les préférences d’Eclipse : Eclipse > Preferences > Mylyn > Builds

On peut :

Rafraichir le statut des builds toutes les X minutes ou seulement lorsque la vue "Build" est active.
Changer le type de notification disponible, par défaut un changement de statut du build ouvrira une popup dans dans la fenêtre d’Eclipse.

Il suffit ensuite d’ajouter une instance Jenkins :

Afficher la vue Mylyn > Builds, on obtient l’écran suivant :
On clique sur create a build server, sélectionner Hudson (support Jenkins),
Renseigner les informations nécessaires, puis cliquer sur Validate pour vérifier que la connection s’effectue correctement,
Sélectionner les jobs à surveiller :
Les jobs sélectionnés sont maintenant disponible dans la vue Builds.

Utilisation
#

Exemple de notification pour être prévenu de l’état du build :

En double cliquant sur un job dans la vue Builds, on obtient une fiche Mylyn :

Parmis les fonctionalités sympa, on peut :

Lancer un build,
Obtenir le contenu de la console Jenkins dans la vue console d’Eclipse,
Charger les résultats des tests dans la vue JUnit. C’est très pratique quand des tests ont échoués, ceux-ci se retrouvent directement liés aux sources dans le workspace,
et plein d’autres choses dont je me sert moins souvent…

Ces actions sont aussi disponibles directement dans la vue Builds, quand on sélectionne un job !

Malheureusement pour le moment, le plugin n’est plus compatible avec les dernières versions de Jenkins… Le bug est ouvert ici.

IntelliJ Idea
#

Installation
#

Télécharger le plugin "Jenkins Control Plugin" depuis le répository des plugins.

Configuration
#

Après redémarrage d’Idea, une nouvelle entrée "Jenkins Control Plugin" est disponible dans les settings.

Utilisation
#

On a accès dans la vue Jenkins Browser à tous les jobs de l’instance, les fonctionalités sont plus réduites que celles du plugin eclipse, on peut :

Voir l’état des builds,
Lancer un build,
Ouvrir la page du job Jenkins dans votre navigateur.

Voilà, plus d’excuses possibles pour ne pas avoir vu que son commit a planté le build :)

Spring et les profils

Wed, 09 May 2012 19:55:00 +0200

Une des fonctionnalités apportées par la version 3.1 de Spring est la gestion des profils.

Récemment, pour une application web, j’ai eu besoin de définir des comportements spécifiques dans mon environnement de développement pour ne pas interroger des services externes, inaccessible depuis mon poste.

Le besoin est donc simple, charger des implémentations de service différentes selon l’environnement d’exécution de l’application. Et c’est là qu’entre en jeux les profils ! Ceux ci permettent de charger des beans différents dans le contexte Spring selon le(s) profil(s) configurés.

Configuration XML
#

Un fichier par profil
#

Il est possible de spécifier un profil dès la balise racine, celà implique que tout le contenu du fichier ne sera chargé que si le profil correspondant est activé.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd"
 profile="a">

 <bean class="com.github.jcgay.example.spring.BeanA" />

</beans>

Le bean n’est chargé que si le profile “a” est actif. Les beans définis en dehors de ce fichier de configuration seront accessibles dans tous les cas.

Blocs au sein d’un même fichier
#

On peut également définir des blocs de profils au sein d’un même fichier de configuration.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

 <bean class="com.github.jcgay.example.spring.BeanA" />

 <beans profile="b">
 <bean class="com.github.jcgay.example.spring.BeanB" />
 </beans>

</beans>

Le bean A est chargé dans tous les cas, le B seulement quand le profil “b” est actif.

Mutualisation de configuration pour plusieurs profils
#

Pour ne pas répéter la configuration de beans dans plusieurs profils, on peut déclarer des blocs valides pour ces différents profils.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

 <beans profile="a,b">
 <bean class="com.github.jcgay.example.spring.BeanA" />
 <bean class="com.github.jcgay.example.spring.BeanB" />
 </beans>

 <beans profile="a">
 <bean class="com.github.jcgay.example.spring.BeanC" />
 </beans>

 <beans profile="b">
 <bean class="com.github.jcgay.example.spring.BeanD" />
 </beans>

</beans>

Le profil “a” contient les beans A,B et C tandis que le profil “b” comprends les beans A,B et D. La déclaration de A et B est mutualisée.

Configuration par annotation
#

On peut également définir des profils via les annotations Spring. L’annotation @Profile peut être utilisé sur les différents stéréotypes disponibles (@Service, @Component, @Configuration, etc).

Au niveau @Configuration
#

@Configuration
@Profile("a")
public class ProfileA {

 @Bean
 public BeanA beanA() {
 return new BeanA();
 }
}

Tous les beans définis dans cette classe sont accessibles quand le profil “a” correspondant est actif.

Comme avec le modèle XML, il est possible de mutualiser la définition des profils.

@Configuration
@Profile({"a", "b"})
public class MultipleProfiles {

 @Bean
 public BeanA beanA() {
 return new BeanA();
 }

 @Bean
 public BeanB beanB() {
 return new BeanB();
 }
}

On peut annoter directement un composant Spring sans passer par des @Configuration.

@Component
@Profile("e")
public class BeanE {
}

Et enfin on peut utiliser @Profile comme meta-annotation et donc créer ses propres annotations au lieu de répeter le nom du profil un peu partout.

@Profile("a")
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface CustomProfile {
}

Et voilà on peut utiliser @CustomProfile pour construire le profil “a”.

Activation d’un profil
#

L’option -Dspring.profiles.active=a en ligne de commande active le profil “a”. Pour activer plusieurs profils il faut les séparer par des virgules.

Ou alors, en variable d’environnement : export spring.profiles.active=a

Dans le cadre d’une application web, le choix du profil peut être passé en paramètre de la servlet :

<servlet>
 <servlet-name>dispatcher</servlet-name>
 <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 <init-param>
 <param-name>spring.profiles.active</param-name>
 <param-value>a</param-value>
 </init-param>
</servlet>

ou en paramètre du listener :

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/applicationContext*.xml</param-value>
</context-param>
<context-param>
	<param-name>spring.profiles.active</param-name>
	<param-value>a</param-value>
</context-param>

<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Définir un profil par défaut
#

La clef spring.profiles.default permet de choisir un profil qui sera activé automatiquement si aucun autre n’a été défini. Pratique si par exemple on veut que l’application charge une configuration type “production” si aucun profil n’est spécifié.

Pour finir, pour les utilisateurs IntelliJ IDEA, il y a une fonctionnalité plutôt sympa qui permet de filtrer la configuration Spring selon le profil actif : http://blogs.jetbrains.com/idea/2011/04/new-in-105-spring-31-bean-definition-profiles/

git-p4 au secours de Perforce

Sun, 18 Mar 2012 18:10:00 +0200

A la manière d’un git-svn, il est possible d’utiliser git pour se synchroniser avec un dépôt Perforce (ouf). On peut profiter de la souplesse de git en local et continuer de travailler avec ses collègues sur le dépot central Perforce.

Principe de fonctionnement
#

Git-p4 permet de cloner un dépot Perforce dans un repository git.

Le script va parcourir chaque révision des fichiers et peupler un répository git via la commande p4 print. On peut importer la totalité de l’historique, enfin si on a le temps surtout, le premier import peut-être assez long en fonction de la taille du dépot Perforce.

La phase un peu plus compliquée est le report des changements dans Perforce (à cause des spécificités de ce SCM). Il faut pour celà passer par un workspace Perforce différent de l’emplacement du répository git.

Les commits git sont alors reportés par le script dans le workspace Perforce via des git diff/format-patch… | git apply puis p4 submit s’occupe de transférer les changements dans Perforce.

Git-p4 utilise git-notes sur chaque commit pour repérer ceux déjà synchroniser avec Perforce.

Installation
#

git
#

Après l’installation classique des binaires, on ajoute quelques propriétés spécifiques à git-p4 dans le fichier de configuration .gitconfig :

[git-p4]
detectRename=true
detectCopy=true

Celà permettra à git-p4 de détecter les fichiers déplacés lors du submit dans Perforce (le copy ne semble pas utilisé…).

perforce
#

Après l’installation des binaires, exposer la variable d’environnement P4CONFIG.

Par la suite j’utilise un fichier .p4config pour configurer les accès Perforce.

python 2.x
#

git-p4 est écrit en python, installation.

git-p4
#

Télécharger le script Pour windows, créer le fichier git-p4.bat avec le contenu suivant:

@python "%~d0%~p0git-p4" %*

Copier ces deux fichiers dans le répertoire d’installation de git /libexec/git-core/

Vérification de l’installation
#

git --version
p4 help
python --version
git p4 help

Utilisation
#

Structure d’un projet
#

Le dossier git contiendra le repository git, et p4 le workspace Perforce.

Contenu du fichier .p4config :

P4USER=nom d’utilisateur
P4PASSWD=mot de passe
P4CHARSET=encoding du serveur
P4COMMANDLINE=encoding du CLI
P4CLIENT=nom du workspace

Création du client Perforce
#

Dans le dossier p4, utiliser la commande p4 client pour créer un nouveau workspace. Les données du fichier .p4config sont automatiquement utilisées, il suffit donc seulement de renseigner le mapping vers le projet.

Penser à créer l’arborescence complète du mapping côté client avant de tenter votre premier commit.

Import initial du projet
#

Dans le dossier git, utiliser la commande git p4 clone //depot/chemin/projet . (attention au point à la fin de la commande).

Par défaut seule la dernière révision sera importée, pour importer l’historique complet il suffit de suffixer le chemin du dépôt par @all.

Voilà on peut maintenant travailler dans le répository git !

Mise à jour incrémentale
#

Une fois le premier import effectué, git p4 rebase permet de récupérer les dernières changelist depuis Perforce.

Pour ceux qui préfèrent voir les changements distants avant de les intégrer dans les commit locaux git p4 sync puis git rebase p4/master

Report des changements locaux dans Perforce
#

Penser à toujours faire un git p4 rebase avant de soumettre les changements locaux dans Perforce sinon les possibles conflits devront être résolus depuis le workspace Perforce, et c’est quand même plus simple de les gérer dans git. En oubliant l’update avant le submit il est également possible de se retrouver avec des changelists Perforce non importées dans git (pas cool).

git p4 submit permet de reporter les changements sur le serveur Perforce.

Utiliser l’option --auto pour que Perforce ne demande pas de modifier le commentaire des commits. Il utilisera automatiquement ceux de git.

Précautions
#

Comme lorsque l’on travaille uniquement avec git, ne pas réécrire l’historique de changements déjà synchroniser avec Perforce,
Penser à toujours rebaser les modifications Perforce sur les changements locaux de git avant de tenter un submit,
Éviter les merge entre branches locales, de toute façon il faudra rebaser les modifications au final. Celà pourrait amener à régler les mêmes conflits plusieurs fois.

Workflow
#

git p4 clone
Modifier des fichiers
git commit
Modifier des fichiers
git commit
git p4 rebase
git p4 submit

Pour aller plus loin
#

Utiliser le même répository git pour gérer plusieurs branches du dépot Perforce (Pour le moment j’utilise un repository git par branche),
Repasser sur le script maintenu sur le repository git officiel, j’ai eu des problèmes sous windows avec ce dernier il y a quelques mois quand j’ai commencé à utiliser git-p4.

Jean-Christophe Gay

Migration de Pelican vers Hugo

Installation #

Theme #

Migrer les articles #

Configuration #

Site #

Coloration syntaxique #

Commentaires #

Redirections #

Prévisualisation #

Génération du site final #

Conclusion #

Utiliser une propriété unique comme version Maven

Définir la version dans une propriété #

Continuous delivery friendly version #

Filtrer les pom à l’installation/déploiement #

Conclusion #

Contextualiser ses événements Sentry

Installation #

Configuration #

Identification #

Version de l’application #

Le MDC #

Conclusion #

Fusion de dépôts Git

What ?! #

Mise en place #

Avantages #

Migrer de boot2docker vers docker-machine

Désinstallation boot2docker #

Installation de docker-machine #

Les volumes #

Activer NFS pour le mapping de volumes #

Docker survitaminé #

Déployer ses SNAPSHOT avec Travis CI

Configuration de Maven #

Identification #

Stockage dans les paramètres du repository #

Chiffrer ses identifiants #

Configuration de Travis CI #

Tester son code Java avec Groovy et Spock

Mise en place #

Maven #

Gradle #

Spécification #

Squelette #

Blocs #

setup, given #

when, then #

expect #

cleanup #

where #

Assertions (conditions) #

Vérification des exceptions #

Mock #

Création #

interaction #

Définition retour des méthodes #

Stub, Spy, Partial mock #

Tests paramétrés #

Data Tables #

Data Pipes #

Test génératifs #

Extensions #

Documentation #

Conclusion #

Encore ? #

Notifications de bureau pour Gradle

Gradle Build Announcements #

Gradle notifier #

Installation #

Script d’initialisation #

Script du projet #

Configuration #

Mesurer son temps de build Maven

maven-profiler #

maven-timeline #

tesla-profiler #

Ecrire une migration Liquibase en Java

Installation
#

Theme
#

Migrer les articles
#

Configuration
#

Site
#

Coloration syntaxique
#

Commentaires
#

Redirections
#

Prévisualisation
#

Génération du site final
#

Conclusion
#

Définir la version dans une propriété
#

Continuous delivery friendly version
#

Filtrer les pom à l’installation/déploiement
#

Conclusion
#

Installation
#

Configuration
#

Identification
#

Version de l’application
#

Le MDC
#

Conclusion
#

What ?!
#

Mise en place
#

Avantages
#

Désinstallation boot2docker
#

Installation de docker-machine
#

Les volumes
#

Activer NFS pour le mapping de volumes
#

Docker survitaminé
#

Configuration de Maven
#

Identification
#

Stockage dans les paramètres du repository
#

Chiffrer ses identifiants
#

Configuration de Travis CI
#

Mise en place
#

Maven
#

Gradle
#

Spécification
#

Squelette
#

Blocs
#

setup, given
#

when, then
#

expect
#

cleanup
#

where
#

Assertions (conditions)
#

Vérification des exceptions
#

Mock
#

Création
#

interaction
#

Définition retour des méthodes
#

Stub, Spy, Partial mock
#

Tests paramétrés
#

Data Tables
#

Data Pipes
#

Test génératifs
#

Extensions
#

Documentation
#

Conclusion
#

Encore ?
#

Gradle Build Announcements
#

Gradle notifier
#

Installation
#

Script d’initialisation
#

Script du projet
#

Configuration
#

maven-profiler
#

maven-timeline
#

tesla-profiler
#

Implémenter un CustomChange
#

Configurer son changeset
#

Arrrghhhh
#

Mais pourquoi tout est cassé ?
#

Réparation de l’environnement
#

Sources
#

Default methods sur les Interfaces
#

Expressions Lambda
#

Accès variable locale
#

Membre et variable static
#

Functional Interfaces
#