Il y a quelques temps, j’ai eu pour mission de stabiliser et de « mavenizer » une application legacy, dont le build était devenu ingérable (dépendances dans divers répertoires, mélanges de scripts shell, Ant,  etc.).

Au sujet de la mavenization elle-même, je vous recommande cet article, donnant une méthode fiable permettant de retrouver la version exacte des dépendances lorsqu’elles ne sont pas connues. Je passe cependant rapidement sur cette étape qui n’est pas le sujet ici. Nous arrivons donc directement au moment où nous avons un fichier « pom.xml » convenable, dont nous voulons vérifier le bon fonctionnement pour assurer le packaging de l’application. Et c’est là que les choses commencent à se compliquer.

Car ce que j’ai oublier de préciser, c’est que cette mission est effectuée pour « Gros client », chez qui les règles de sécurité sont strictes : l’accès internet se fait uniquement au travers d’un proxy. Et plus particulièrement le modèle PALC avec toutes les options : identification individuelle obligatoire sur ledit proxy, mot de passe à modifier tous les 3 mois, verrouillage du compte après 5 tentatives ratées, etc. Pour Maven qui aime bien « télécharger l’univers », c’est problématique.

Petite digression sur une mauvaise surprise découverte lors de cette mission… Ubuntu 11.10 n’est pas du tout adapté au travail dans un environnement utilisant un proxy : il souffre en effet d’une régression empêchant le paramétrage d’exceptions (pour les serveurs du réseau local).

Paramétrer le proxy pour Maven

Maven fournit un guide pour paramétrer un proxy. L’opération consiste à renseigner les paramètres du proxy dans le « settings.xml » :

1
2
3
4
5
6
7
8
9
10
11

<proxies>
  <proxy>
    <active>true</active>
    <protocol>http</protocol>
    <host>palc.grosclient.com</host>
    <port>8080</port>
    <username>user</username>
    <password>password</password>
    <nonProxyHosts></nonProxyHosts>
  </proxy>
</proxies>

Une fois ce paramétrage effectué, les dépôts sont bien résolus et les dépendances téléchargées. Mais il reste un soucis : certains dépôts irréductibles résistent encore… Par exemple le dépôt JBoss, ou encore Sonatype OSS. La cause est vite identifiée : ces dépôts utilisent le protocole « https » et non « http ».

Qu’à cela ne tienne : on duplique le bloc « proxy » en modifiant le protocole. A ceci près que ça ne marche pas… Maven ne sait utiliser qu’un seul proxy à la fois. Si on utilise le proxy « https », on pert le « http », et inversement. Peut-être une idée de correction à implémenter pour le hackergarten de mercredi prochain…

La seule solution que j’ai pu trouver à ce jour est de paramétrer les proxys au niveau de la ligne de commande :

1
2
3
4
5
6
7
8
9
10

mvn
  -Dhttp.proxyHost=palc.grosclient.com
  -Dhttp.proxyPort=8080
  -Dhttp.proxyUser=user
  -Dhttp.proxyPassword=password
  -Dhttps.proxyHost=palc.grosclient.com
  -Dhttps.proxyPort=8080
  -Dhttps.proxyUser=user
  -Dhttps.proxyPassword=password
  install

Il est possible de paramétrer un proxy dans le « settings.xml » et le deuxième en ligne de commande mais ce n’est pas très intuitif. J’aime autant que tous les paramètres soient au même endroit.

Une fois les paramètres correctement configurés, on peut les pérenniser en les enregistrant dans la variable d’environnement MAVEN_OPTS.

Utiliser un dépôt Maven interne

Suite au paramétrage correct des proxys (http et https), Maven peut à nouveau télécharger tout internet… et le build peut fonctionner. Nous pouvons donc aller plus loin et installer un dépôt Maven chez « Gros client », afin d’y publier les artefacts produits.

Cependant, ce serveur peut également servir à régler autrement notre problème de proxy. Pour cela, il y a un pré-requis : le serveur doit être accessible directement depuis le réseau de développement, et avoir accès à internet (si possible sans proxy). Dans notre cas, c’est Nexus qui fait office de dépôt Maven (mais la même technique doit fonctionner avec Artifactory ou autre…). Ensuite :

• On configure différents dépôts de type « proxy » vers chacun des dépôts externes dont on a besoin.
• On ajoute tous ces dépôts au dépôt groupe « public ».

Enfin, nous devons expliquer à Maven qu’il doit systématiquement utiliser notre serveur interne au lieu de tenter d’accéder directement aux dépôts externes (Maven central, etc.). Pour cela, retour dans « settings.xml », mais cette fois dans le bloc mirrors.  Il suffit d’expliquer à Maven que tous les dépôts dont ont a besoin ont pour miroir notre serveur interne :

1
2
3
4
5
6
7
8

<mirrors>
  <mirror>
    <id>nexus.grosclient.com</id>
    <name>Serveur Nexus de Gros client</name>
    <url>http://nexus.grosclient.com/content/groups/public</url>
    <mirrorOf>*</mirrorOf>
  </mirror>
</mirrors>

Avec cette configuration, le paramétrage des proxys fait précédemment doit être supprimé (ou une exception doit être ajoutée pour le dépôt interne).

Cette dernière configuration présente plusieurs avantages :

• L’ensemble des dépôts susceptibles d’être utilisés dans les différents projets de l’entreprise sont configurés de manière centrale, au niveau du dépôt. Cela permet à l’équipe agile au chef de projet (rappel : nous sommes chez Gros client) de contrôler les dépôts/librairies utilisées sur le projet.
• Le premier développeur qui demande une librairie au serveur Nexus va déclencher son téléchargement depuis son dépôt initial. Mais celle-ci sera ensuite mise en cache sur le serveur. Ainsi, les appels suivants (par les autres développeurs) se contenteront d’effectuer un téléchargement sur le réseau local, avec un gain de temps (voire de bande passante) non négligeable.

• accès (en lecture et en écriture) à de nouvelles propriétés des fichiers : propriétaire, permissions, gestion des liens symboliques et des fichiers cachés, etc.
• surveillance native des évènements (création/modification/suppression d’un fichier)
• plus grande simplicité et meilleures performances lors de l’accès et du parcours des fichiers avec Files
• etc.

Configurer Talend Open Studio

Lancer Talend Open Studio avec Java 7

1
2

-vm
/usr/lib/jvm/java-7-jdk/bin/java

Enregistrer le JDK 7 dans le studio

Configuration Java dans Talend Open Studio

Utiliser du Java 7 dans Talend Open Studio

L’ensemble des préparatifs étant terminé, il est maintenant possible d’utiliser les classes de Java 7 dans Talend Open Studio :

• dans les différents composants permettant d’écrire du code directement (tJava, tJavaRow, tJavaFlex, etc.).
• en créant soit-même de nouveaux composants.

Exécution du composant bcFileProperties

1
2
3

git init
git add mondocument
git commit -m 'Première sauvegarde de mon document'

Diff entre deux versions

En commitant régulièrement son document, on en constitue un historique. Et avec les branches, on peut même le décliner en plusieurs versions. Je n’ai par contre pas réussi à créer de « feature branch » documentaire, la fusion automatique de documents binaires avec git se passant bizarrement assez mal.

L’autre problème avec des documents binaires, c’est qu’ils passent assez mal dans le « diff », ce qui fait perdre à la gestion de configuration une partie de son intérêt. Mais pour ce problème là, il existe une solution. Il suffit d’avoir un outil permettant d’afficher un document un mode texte. Dans le cas du format OpenDocument, on peut par exemple utiliser odt2txt.

Il faut ajouter dans .gitconfig le bloc suivant, pour déclarer le convertisseur associé au format odf :

1
2

[diff "odf"]
    textconv=odt2txt

Enfin, dans le répertoire du dépôt du projet, il faut associé ce convertisseur avec les extensions des fichiers OpenOffice. Ca se passe dans le fichier info/attributes :

1
2
3

*.odt diff=odf
*.ott diff=odf
# idem pour les formats ods, ots, odp et otp

Cette modification effectuée, on récupère la possibilité de calculer le différentiel entre deux commits, et toutes les fonctionnalités associées.

Le seul inconvénient, c’est qu’il faut répéter cette opération pour chaque dépôt de documents. Je n’ai pas trouvé le moyen de définir ces comportements dans la configuration globale de git. Si quelqu’un a une solution, je suis preneur !

Automatisation de la sauvegarde

Afin d’améliorer un peu le processus, il suffit d’un petit script shell qui automatise l’enregistrement du document à intervalles réguliers :

1
2
3
4
5
6
7
8
9

#!/bin/sh
# Intervalle entre deux enregistrements
SAVE_PERIOD_IN_SECONDS=120
while :
do
    echo "Autosave : $(date)"
    git commit -a -m "Autosave $(date)"
    sleep $SAVE_PERIOD_IN_SECONDS
done

Ce script utilise une des particularités intéressantes de git : si le fichier n’a pas évolué pendant l’intervalle, le commit n’est pas effectué. Ainsi, l’historique des versions du document pourra sauter des enregistrements (si on a oublié d’enregistrer le document entretemps par exemple).

Pour finir, voici donc le script en action :

Sauvegarde automatique de document avec git

Dans la nuit qui a suivi, Olivier et Nicolas ont respectivement publié des excellents comptes-rendus de cette soirée. Merci et félicitations à eux donc :

• Paris JUG « Cloud »
• Patrick Chanezon au Paris JUG, Didier Girard, SFEIR, Création de valeur et compétitivité avec le Cloud, et CloudFoundry présenté par Guillaume Laforge, Soirée Patrick Chanezon

Voici donc, modestement, un petit compte-rendu de tests que j’ai eu l’occasion de faire sur deux des plate-formes dont il était question à cette soirée.

Cloud Foundry

J’ai déjà eu l’occasion de parler de mes tests de déploiement d’une application Play Framework sur cette plate-forme, ici et là. C’est un projet que j’apprécie beaucoup, pour plusieurs raisons :

• il est Open Source, ce qui permet de monter une plate-forme de cloud privée (voire un « micro-cloud »)
• il permet de faire tourner des applications de plusieurs types (Java, Ruby, NodeJS…), avec des frameworks associés, et le nombre de technologies supportées sera prochainement élargi (par exemple, la gestion native des applications Play est dans les tuyaux)
• il est multi-services (MySQL, MongoDB, …)
• il n’y a pas d’API spécifique à Cloud Foundry, ce qui évite de se lier avec la plate-forme au point de ne plus pouvoir en sortir facilement
• il n’est pas dépendant d’une infrastructure particulière : on peut installer le système sur la couche de virtualisation que l’on souhaite : VMWare, VirtualBox, …

CloudBees

Inscription

La procédure d’inscription est un poil plus compliquée que celle de Cloud Foundry (mais en même temps, on peut difficilement faire plus simple que le bouton unique de ce dernier). Rien de bien dramatique cependant : en moins d’une dizaine de minutes tout compris, on a un compte prêt à l’emploi. Voici donc mes premières impressions, en essayant de les comparer à ce que j’ai pu voir sur Cloud Foundry.

Dev@Cloud

Avec une application Play Framework, je n’ai pas vraiment pu tester cette partie. Cependant, j’espère avoir l’occasion de le faire prochainement : l’approche est intéressante ! Elle consiste à pouvoir construire son application et la valider dans les nuages. Le principe est d’empiler à la demande les services dont on peut avoir besoin autour de l’intégration continue Jenkins : dépôts Maven (Archiva), tests fonctionnels avec Selenium, analyse de qualité avec Sonar… CloudBees propose même de mettre sa gestion de configuration dans les nuages avec des dépôts Git (ou autres dont on ne doit pas prononcer le nom). Et la gestion de ces différents services dispose d’une interface très conviviale :

RUN@Cloud

Passons maintenant à la partie déploiement. Depuis une application Play, la procédure pour monter une application dans le Cloud est très proche de celle de Cloud Foundry : il suffit de configurer et d’utiliser le module dédié, Au moment du déploiement, comme pour Cloud Foundry, l’application est convertie en archive WAR, puis est chargée sur le Cloud via l’API du service.

30 minutes après le premier échange de tweets avec Nicolas, la même application était en ligne sur CloudBees (avec l’aide de François pour la correction de quelques bugs de la première version). Entre les versions Cloud Foundry et CloudBees, aucune ligne de code n’a été modifiée pour permettre le déploiement. Le déploiement est donc aussi simple sur les deux environnements. Et dans les deux cas, on n’est pas lié par des API propriétaires. Le coût de sortie est donc faible.

Un petit avantage va cependant à Cloud Foundry : il gère une liste complète des fichiers déjà déployés (quel que soit l’utilisateur les ayant mis en ligne), et permet de ne charger que ce qui n’est pas déjà connu en ligne (soit quelques Ko). Sur CloudBees, il n’y a pas cette liste globale : le premier chargement nécessite donc le transfert complet des 50 Mo de l’application. Les déploiement suivants se font par contre bien de façon incrémentale (ouf !).

Monitoring

Sur ce point, CloudBees gagne sans aucune discussion possible. Sa console d’administration est graphiquement très agréable, et permet un monitoring complet de l’application : requêtes, mémoire, temps de réponse, etc.

Console de monitoring CloudBees

Au niveau de Cloud Foundry, il n’y a pour le moment quasiment aucune possibilité de monitoring, et uniquement via l’outil « vmc ». Il est ensuite possible de palier à ce manque avec des produits tierces : Hyperic, NewRelic, etc.

Mais n’oublions pas que Cloud Foundry est encore en phase de béta. On ne sait pas encore quel sera le mode de pricing de la version finale, ni quels seront les services associés mais cela m’étonnerait grandement qu’aucune solution de monitoring ne soit intégrée à l’offre commerciale.

Extensibilité

Une des choses qui m’a beaucoup séduit dans Cloud Foundry, c’est son extensibilité avec la possibilité d’utiliser les services que l’on souhaite (type de base de données, etc.). Sur ce point, CloudBees devrait proposer une approche similaire, en proposant des services partenaires. A l’heure actuelle, ce système de services est en place pour la partie DEV@Cloud, mais je ne sais pas ce qui pourra être rendu disponible sur la partie RUN. L’avantage est donc à Cloud Foundry pour la partie « services PaaS disponibles ».

Performances

Ma petite application de test n’utilise pas de base de données. Je m’attendais donc à ce qu’elle tourne de manière identique sur les deux environnements, d’autant plus qu’ils utilisent tous les deux des serveurs Tomcat pour l’exécution des applications Java. Or, les tests de monitoring que j’ai pu effectuer montrent que ce n’est pas le cas :

• Sur Cloud Foundry, l’application ne descend pas sous la barre des 200 Mo de RAM consommés
• Sur CloudBees, elle reste aux alentours des 60 Mo de RAM consommés

Conclusion

Sur la partie DEV@Cloud, CloudBees n’a pas de concurrent chez Cloud Foundry (je ne sais d’ailleurs pas s’il a un concurrent tout court…).

Une des particularité de cette journée était de ne pas tourner qu’autour de Java, mais aussi d’autres langages (Python, Ruby, .NET). Autre particularité (par rapport à la What’s Next notamment), les thèmes de cette journée étaient moins orienté Cloud, et plus NoSQL.

Voici un petit résumé des conférences qui m’ont le plus intéressé :

La keynote

La journée a commencé très fort, avec une keynote de Sébastien Douche sur les communautés. Après un rapide historique des communautés internet (Newsgroups, IRC, mailing-list, etc.), il nous explique l’intérêt des communautés :

• Trouver de l’information fiable rapidement, en s’adressant directement à « ceux qui savent, qui font, qui réfléchissent »
• Progresser plus rapidement que tout seul
• Elargir sa vision des choses, et devenir plus créatif, en échangeant avec des personnes qui font différemment
• Se constituer des réseaux d’amis, où l’on devient reconnu par son implication

Parmi les outils de « réseautage », Twitter est particulièrement intéressant. Contrairement à la plupart des autres réseaux sociaux, il permet d’avoir deux communautés distinctes : les personnes que l’on suit et les personnes qui nous suivent.

Faire les choses en communauté, c’est plus efficace, mais surtout, c’est plaisant. Alors comment importer ce modèle en entreprise, pour avoir plaisir à travailler 8 heures par jour (au moins) ? Plusieurs pistes, mais difficiles à appliquer par chez nous car opposées au modèle hiérarchique français :

• Tout d’abord, permettre l’accès aux communautés externes (ah… nos chers PALC d’entreprise)
• Valoriser l’initiative, la créativité, la prise de risque
• Avoir un modèle de collaboration ouvert, sans mettre de frontières entre les services, et former des équipes multi-disciplinaires communiquant beaucoup (tiens, ça rappelle le DevOps ça…)

Conclusion de cette keynote : adhérez aux communautés !

Je partage complètement les principes exposés par Sébastien dans cette keynote : en commençant à participer au Paris JUG il y a maintenant plus d’un an, j’ai effectivement pu constater tous ces bienfaits !

Les présentations

Après cette keynote, 7 conférences se sont enchaînées dans la journée, entrecoupées de discussions et d’un déjeuner galette/crêpe. Voici la liste des présentations auxquelles j’ai participé qui m’ont le plus intéressé :

Le déploiement continu

Claude Falguière nous a présenté deux retours d’expérience sur la mise en place du déploiement continu.

Cette présentation m’a particulièrement plu, car elle présente bien les étapes d’amélioration du processus de développement/déploiement, et explique bien l’intérêt de la mise en place des bonnes pratiques (qu’on a parfois du mal à défendre auprès de certaines directions) :

• Les tests (unitaires, d’intégration, etc.)
• Le « fast-fail », lié au tests, permettant de découvrir les problèmes au plus tôt et ainsi de limiter leurs impacts
• l’intérêt d’avoir un retour au plus tôt des utilisateurs
• etc.

Le langage Python

Après la keynote, Sébastien Douche nous a présenté le langage Python, ou plus exactement pourquoi il aimait ce langage.

Un langage est un univers : il est accompagné de paradigmes, d’une philosophie, qui incite à coder d’une manière ou d’une autre. C’est cet ensemble qui fait qu’on aime ou non un langage.

Les avantages du langage Python :

• concis, mais tout en restant lisible (certains langages ont des syntaxes parfois tellement concises et « magiques » qu’elles en deviennent illisibles)
• homogène : le langage pousse les développeurs à faire les choses d’une certaines façon. On peut essayer de faire autrement, mais on développe alors de façon « non pythonique » (en ne respectant pas l’esprit du langage)
• explicite et simple : quand on lit du code Python, on comprend directement ce qu’il fait (31 mots clés seulement, pour un manuel de référence de 100 pages)
• extensible

Sans être un langage purement fonctionnel, le Python est un langage first class : les méthodes peuvent être passée en paramètres ou être retournées (ce qui manque cruellement au Java, et que j’apprécie donc particulièrement en Scala soit dit en passant).

La présentation se poursuit par une présentation du duck typing, possible en Python. J’avoue ne pas être particulièrement par cette possibilité : je préfère un typage plus fort, certes plus contraignant, mais donnant un code plus facilement compréhensible.

Cette présentation n’a pas été sans quelques trolls, mais il est vrai que les discussions avec Sébastien sur les différents langages étaient particulièrement intéressantes. Il a en particulier pointé plusieurs travers du monde Java, qui sont assez vrais :

• ce monde est tellement vaste qu’on a tendance à ne pas trop avoir tendance à regarder ce qui se fait à côté, même si c’est en train de changer ces derniers temps
• les développeurs Java ont tendance à plus se focaliser sur la technique et la « tuyauterie » des programmes que sur l’aspect fonctionnel sur lequel ils travaillent

Les bases de données

Au cours de cette journée, j’ai assisté à 3 conférences sur le stockage de données : deux présentations sur l’écosystème Hadoop et sur Cassandra, ainsi que la présentation de Julien Dubois sur le choix d’une solution de stockage. En particulier, j’ai beaucoup apprécié cette dernière conférence, très didactique autour d’une présentation des différentes façons de répondre à la problématique suivante, lorsqu’on commence à avoir de nombreux utilisateurs en même temps :

• un ensemble d’évènements
• des personnes participant aux évènements, et ayant entre eux des relations d’amitiés

L’application doit afficher pour chaque évènement auquel l’utilisateur participe, la liste de ses amis participant à ce même évènement.

L’approche naïve en SQL, c’est une requête composée de deux jointures. Là où ça se corse, c’est quand la volumétrie et le nombre d’accès concurrents augmentent…

Julien nous a donc passé en revue un certain nombre de solution (à choisir en fonction du contexte et de ses contraintes : ACID ou non) :

• Un serveur SQL traditionnel simple (Oracle)
• Un cluster de bases SQL (master-slave, façon MySQL)
• du Oracle RAC (monnayant quelques bras)
• une couche ORM (Hibernate par exemple), utilisant les bénéfices des caches de premier et second niveau (Ehcache, etc.)
• les solutions de cache distribués, qu’il soient gratuits (Memcached) ou propriétaires (Terracotta, GemFire, etc.)
• une solution NoSQL, avec la présentation de Cassandra (qui fait d’ailleurs partie de la solution avec laquelle Julien et son équipe sont parvenus en finale du challenge de l’Université du SI.

Epilogue

Cette journée s’est terminée par une mise en pratique fort sympathique de la keynote du matin, en communauté :

Quatrième (voire cinquième) mi-temps

Prochain grand rendez-vous le 16 septembre pour le JUG Summer Camp : et il reste des places !

Avant de me lancer dans la résolution des problèmes en question, et en application des bonnes pratiques du TDD, j’ai écrit les signatures des méthodes, et les tests associés à ces 22 problèmes. Si vous voulez vous lancer, je vous épargne cette première étape : vous pouvez télécharger directement ce squelette.

Vous pourrez vérifier que les 22 tests échouent. Ces tests sont cependant rudimentaires, et les faire passer au vert ne garantira pas que vous avez la bonne solution (même si c’est encourageant).

D’autres personnes se sont lancées avant moi dans la résolution de ces problèmes. Comme il est toujours intéressant de comparer les différentes approches, en voici quelques unes (en plus des solutions du site original) :

• http://99problemsinscala.wordpress.com/
• http://gabrielsw.blogspot.com/2009/04/my-take-on-99-problems-in-scala-first.html

Voici maintenant mes propositions pour chacun de ces problèmes, que vous pourrez tester, critiquer, optimiser. Par rapport à celles proposées sur le site officiel, elles sont sans doute moins optimisées, et plus complexes. Mais découvrant le langage, je n’ai pas eu le réflexe d’utiliser les méthodes natives de manipulation des listes avancées (flatMap, takeWhile, dropWhile, etc.), qui permettent souvent de s’en sortir d’une jolie manière.
P01 : trouver le dernier élément d’une liste

1
2
3
4
5
6

def last[E](ls: List[E]): E =
    ls match {
        case Nil => throw new NoSuchElementException
        case head :: Nil => head
        case _ :: tail => last(tail)
    }

P02 : trouver l’avant-dernier élément d’une liste

1
2
3
4
5
6

def penultimate[E](ls: List[E]): E =
    ls match {
        case head :: lastElement :: Nil => head
        case _ :: tail => penultimate(tail)
        case Nil => throw new NoSuchElementException
    }

P03 : trouver un élément donné d’une liste

1
2
3
4
5
6

def nth[E](n: Int, ls: List[E]): E =
    (n, ls) match {
        case (_, Nil) => throw new NoSuchElementException
        case (0, head :: _) => head
        case (m, _ :: tail) => nth(m - 1, tail)
    }

P04 : trouver la taille d’une liste

1
2
3
4
5

def length(ls: List[Any]): Int =
    ls match {
        case Nil => 0
        case _ :: tail => 1 + length(tail)
    }

P05 : inverser une liste

1
2
3
4
5
6
7
8

def reverse[E](ls: List[E]): List[E] =
    reverseRec(ls, Nil)
 
private def reverseRec[E](input: List[E], result: List[E]): List[E] =
    (input, result) match {
        case (Nil, res) => res
        case (head :: tail, res) => reverseRec(tail, head :: res)
    }

P06 : la liste est-elle un palindrome ?

1
2
3

def isPalindrome(ls: List[Any]): Boolean =
    // En Scala, '==' correspond à la méthode Java 'equals()'.
    (ls == reverse(ls))

P07 : « aplanir » une liste

1
2
3
4
5
6

def flatten(ls: List[Any]): List[Any] =
    ls match {
        case Nil => Nil
        case (head: List[_]) :: tail => flatten(head) ::: flatten(tail)
        case head :: tail => head :: flatten(tail)
    }

P08 éliminer les doublons successifs d’une liste

1
2
3
4
5
6

def compress[E](ls: List[E]): List[E] =
    ls match {
        case Nil => Nil
        case h1 :: h2 :: tail if (h1 == h2) => compress(h2 :: tail)
        case h1 :: tail => h1 :: compress(tail)
    }

P09 : « compacter » une liste

1
2
3
4
5
6
7
8
9
10
11

def pack[E](ls: List[E]): List[List[E]] =
    packRec(Nil, Nil, ls)
 
private def packRec[E](accu: List[E], result: List[List[E]], ls: List[E]): List[List[E]] =
    (accu, result, ls) match {
        case (Nil, res, Nil) => res
        case (acc, res, Nil) => res ::: List(acc)
        case (Nil, res, head :: tail) => packRec(List(head), res, tail)
        case (accHead :: accTail, res, lsHead :: lsTail) if (accHead == lsHead) => packRec(lsHead :: accHead :: accTail, res, lsTail)
        case (accHead :: accTail, res, lsHead :: lsTail) => packRec(List(lsHead), res ::: List(accHead :: accTail), lsTail)
    }

P10 : « encodage » d’une liste

1
2
3

def encode[E](ls: List[E]): List[(Int, E)] = {
    pack(ls) map ((l: List[E]) => (length(l), l.head))
}

P11 : encodage modifié d’une liste

1
2
3
4
5
6
7

def encodeModified(ls: List[Any]): List[Any] =
    pack(ls) map (
            (l: List[_]) => length(l) match {
                case 1 => l.head
                case n => (n, l.head)
            }
    )

P12 : « décodage » d’une liste

1
2
3
4
5
6
7
8
9
10
11

def decode[E](ls: List[(Int, E)]): List[E] =
    ls match {
        case Nil => Nil
        case (n, elem) :: tail => decodeRec(n, elem, Nil) ::: decode(tail)
    }
 
private def decodeRec[E](n: Int, elem: E, result: List[E]): List[E] =
    n match {
        case 0 => result
        case m => decodeRec(m - 1, elem, elem :: result)
    }

P13 : encodage direct d’une liste

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def encodeDirect[E](ls: List[E]): List[(Int, E)] =
    ls match {
        case Nil => List()
        case head :: tail => encodeDirectRec(1, head, List(), tail)
    }
 
private def encodeDirectRec[E](nb: Int, elem: E, result: List[(Int, E)], ls: List[E]): List[(Int, E)] =
    (nb, elem, result, ls) match {
        case (0, _, res, Nil) => res
        case (n, el, res, Nil) => res ::: List((n, el))
        case (0, _, res, head :: tail) => encodeDirectRec(1, head, res, tail)
        case (n, el, res, head :: tail) if (el == head) => encodeDirectRec(n+1, el, res, tail)
        case (n, el, res, head :: tail) => encodeDirectRec(1, head, res ::: List((n, el)), tail)
    }

P14 : dupliquer chaque élément d’une liste

1
2
3
4
5

def duplicate[E](ls: List[E]): List[E] =
    ls match {
        case Nil => Nil
        case head :: tail => head :: head :: duplicate(tail)
    }

P15 : dupliquer N fois chaque élément d’une liste

1
2
3
4
5
6
7
8
9
10
11
12

def duplicateN[E](n: Int, ls: List[E]): List[E] =
    duplicateNRec(n, n, ls)
 
private def duplicateNRec[E](n: Int, compt: Int, ls:List[E]): List[E] =
    (compt, ls) match {
        case (_, Nil) => Nil
        // Passage à l'élément suivant
        case (0, head :: tail) => duplicateNRec(n, n, tail)
        // Boucle sur l'élément 'head' tant qu'il doit être dupliqué
        case (cpt, head :: tail) => head :: duplicateNRec(n, cpt-1, head :: tail)
 
    }

P16 : supprimer un élément tous les N d’une liste

1
2
3
4
5
6
7
8
9

def drop[E](n: Int, ls: List[E]): List[E] =
    dropRec(n, 1, ls)
 
private def dropRec[E](n: Int, compt: Int, ls: List[E]): List[E] =
    (compt, ls) match {
        case (_, Nil) => Nil
        case (cpt, head :: tail) if (cpt == n) => dropRec(n, 1, tail)
        case (cpt, head :: tail) => head :: dropRec(n, cpt+1, tail)
    }

P17 : diviser une liste en deux sous-listes

1
2
3
4
5
6
7
8
9

def split[E](n: Int, ls: List[E]): (List[E], List[E]) =
    splitRec(n, Nil, ls)
 
private def splitRec[E](n: Int, left: List[E], right: List[E]): (List[E], List[E]) =
    (n, right) match {
        case (0, _) => (left, right)
        case (_, Nil) => throw new NoSuchElementException
        case (nb, head :: tail) => splitRec(nb-1, left ::: List(head), tail)
    }

P18 : extraire les éléments M à N d’une liste

1
2
3
4
5
6
7

def slice[E](start: Int, end: Int, ls: List[E]): List[E] =
    (start, end, ls) match {
        case (0, 0, _) => Nil
        case (_, _, Nil) => throw new NoSuchElementException
        case (0, n, head :: tail) => head :: slice(0, n-1, tail)
        case (m, n, head :: tail) => slice(m-1, n-1, tail)
    }

P19 : permuter les positions des éléments d’une liste à gauche

1
2
3
4
5
6
7

def rotate[E](n: Int, ls: List[E]): List[E] =
    (n, ls) match {
        case (_, Nil) => Nil
        case (0, lst) => lst
        case (_, head :: tail) if (n > 0) => rotate(n-1, tail ::: List(head))
        case (_, _) => rotate(length(ls) + n, ls)
    }

P20 : supprimer un élément d’une liste

1
2
3
4
5
6
7
8
9

def removeAt[E](n: Int, ls: List[E]): (List[E], E) =
    removeAtRec(n, Nil, ls)
 
private def removeAtRec[E](n: Int, start: List[E], end: List[E]): (List[E], E) =
    (n, end) match {
        case (_, Nil) => throw new NoSuchElementException
        case (0, head :: tail) => (start ::: tail, head)
        case (m, head :: tail) => removeAtRec(m-1, start ::: List(head), tail)
    }

P21 : insérer un élément dans une liste

1
2
3
4
5
6

def insertAt[E](elem: E, pos: Int, ls: List[E]): List[E] =
    (pos, ls) match {
        case (0, lst) => elem :: lst
        case (_, Nil) => throw new NoSuchElementException
        case (_, head :: tail) => head :: insertAt(elem, pos-1, tail)
    }

P22 : créer une liste contenant tous les entiers d’un intervalle donné

1
2
3
4
5
6

def range(start: Int, end: Int): List[Int] =
    (start, end) match {
        case (s, e) if (e < s) => Nil
        case (s, e) if (s == e) => List(s)
        case (_, _) => start :: range(start+1, end)
    }

Après avoir un peu pratiqué git, ce genre de workflow devient naturel, et est particulièrement appréciable :

• les fonctionnalités ont chacune leur branche dédiée : la lecture de son historique n’est donc pas gêné par le reste des développements
• les livraisons peuvent être préparées sans empêcher les personnes qui travaillent sur les futures fonctionnalités de partager leur travail
• etc.

Voila pour la théorie : sur le papier, ça laisse absolument rêveur ! Mais dans la pratique, tout ne fonctionne pas aussi bien, surtout au début. Et c’est là que commence mon retour d’expérience sur la mise en place de ce workflow.

Git est un outil complexe

Lorsque l’on met git en place avec une équipe qui avait l’habitude de travailler avec SVN, on ne peut pas s’attendre à ce qu’un tel workflow soit mis en place du jour au lendemain : il faut d’abord commencer par apprendre à l’équipe les bases de l’utilisation de git. Car si c’est un outil extrêmement puissant, il ne faut pas perdre de vue qu’il est aussi objectivement beaucoup plus complexe à utiliser. Il n’y a qu’à vérifier sur ce petit pense-bête des commandes pour s’en rendre compte :

• On passe d’une communication entre un workspace et dépôt à un système de quatre « zones » (et encore, je ne parle même pas du stash) : workspace, index, dépôt local, dépôt distant.
• L’équivalent d’un commit SVN, c’est commit + push. L’équivalent d’un checkout SVN, c’est fetch + checkout (ou pull). etc. Bref, plus de commandes à apprendre !

Il y a donc nécessairement un temps d’adaptation. L’idéal serait évidemment de pouvoir arrêter le développement le temps de véritablement former l’équipe à git, sur quelques jours à temps plein. Dans la pratique, ce n’est souvent pas possible, et on se retrouve à devoir apprendre petit à petit sur le tas.

C’est à ce stade que les formations ne sont vraiment pas un luxe. Personnellement, ce sont les formations sur une journée complète de Christophe Porteneuve qui m’ont permis de véritablement apprendre à maîtriser git. Pour ceux que cela intéresse, la prochaine formation, c’est samedi en huit à Paris. Et 100€ pour une journée de formation, déjeuner compris, c’est donné vu tout ce qu’on y apprend. Note : pour ceux qui se posent la question, je ne touche strictement rien pour les publicités que je lui fait. J’encourage ces ateliers parce que je les trouve excellents ! Et vu le prix des formations par rapport au temps qu’il y passe, je ne le soupçonne pas de faire ça pour l’argent non plus…

Les habitudes SVN…

Tous les manuels le disent : il ne faut pas penser comme en SVN, et ne surtout pas se dire « quel est l’équivalent de cette commande SVN en git ? ». C’est bien beau de le dire, mais dans la pratique, faute d’avoir le temps de commencer par une formation complète, ça commence souvent comme ça quand même !

On se retrouve donc avec deux habitudes que l’on reproduit :

• la trunkite : dans SVN, la gestion des branches est tellement catastrophique que souvent, on ne les utilise même pas. Quand on arrive dans git, on n’a donc pas le réflexe de créer des branches, et on développe dans master, qui devient le « git trunk ».
• la pushite : avec SVN, les commits intermédiaires d’une fonctionnalité sont généralement interdits car ils cassent le build. On développe donc toute la fonctionnalité, avec d’effectuer un unique gros commit, que l’on le partage immédiatement à l’équipe par un push.
• la pullite : il s’agit de la peur de ne pas être à jour par rapport à ce que font les camarades, et donc d’effectuer très régulièrement des pull, pour remettre à jour sa branche.

On utilise donc git comme si c’était un SVN. Et à plusieurs, il arrive souvent que les push soient refusés pour cause d’absence de mise à jour préalable. Qu’à cela ne tienne : « git pull + git push » résout le problème ! A ceci près que git conserve ces fusions dans son arbre. Quand il y a un merge, ça va… mais quand plusieurs développeurs commencent à faire la même chose en parallèle, on a vite un arbre qui ressemble à ça :

Workflow Subversion utilisé dans Git

Le problème, c’est que dans ce workflow, les micro-merges de chacun ne correspondent pas à de véritables fusions fonctionnelles. On se retrouve donc avec un graph dont la compréhension nécessite parfois quelques aspirines. Paradoxalement, on se retrouve dans une situation où la gestion de configuration est plus difficile à lire que l’équivalent SVN, ce qui est l’inverse du but recherché.

… dont on se soigne !

Heureusement, après quelques temps et un peu de formation, la maîtrise des commandes progresse, ainsi que la compréhension des avantages de git et la méthode de travail. En particulier, voilà quelques réflexes qu’on acquiert :

Commiter régulièrement

C’est un des premiers réflexes à acquérir. Les commit étant locaux, le commit d’un « morceau de fonctionnalité » ne gènera pas le reste de l’équipe et ne cassera pas le build tant qu’il ne sera pas partagé. Ca permet d’avoir plus de commits par fonctionnalité, avec de nombreux avantages :

• un suivi plus fin du développement, et une meilleure compréhension pour le reste de l’équipe de l’enchaînement des étapes de développement
• une identification plus facile du commit ayant entrainé une régression quand il y en a (recherche qui peut être automatisée avec le surpuissant git bisect)

Cette évolution de la méthode de développement va évidemment de pair avec l’arrêt de la pushite, puisqu’on risquerait là de partager une évolution incomplète cassant le build, et de se faire taper dessus par le {reste de l’équipe/chef de projet/scrum master} (rayer les mentions inutiles).

Créer des branches

Avant tout début de développement (fonctionnalité, refactoring, etc.), le réflexe à avoir est de créer une branche dédiée, avant même de commencer à réfléchir à ce que l’on va coder.

Petite astuce : avec quelques commandes git, si on a oublié de créer une branche, on peut le faire à postériori. Supposons que j’ai fait 3 commits dans master, que j’aurais du faire dans une branche dédiée feature :

1
2
3

git branch feature # Création de la branche manquante
git reset HEAD~3 # La branche master revient là où elle devrait être, ni vu ni connu…
git checkout feature # Retour sur la branche et poursuite des développements…

Une fois cette habitude prise, la pullite n’est plus un problème : rien n’empêche de mettre à jour master (aussi souvent qu’on le souhaite), en fast-forward, tout en continuant ses développements dans la branche feature.

On ne fusionne sa branche de développement dans master que lorsque l’évolution est terminée :

Git workflow

Résolution des conflits

Le workflow précédent est déjà nettement plus lisible dans l’historique git. Cependant, il présente un inconvénient : si l’évolution est complexe, on travaille « en aveugle » par rapport au reste des développements jusqu’à la fusion finale. Si différentes évolutions impactent les mêmes classes, la fusion finale peut être difficile.

D’où l’idée de résoudre les conflits par avance. Pour cela, il y a un moyen simple : réaliser régulièrement des fusions de la branche master vers sa branche de développement :

Git workflow avec fusions intermédiaires

Cela permet de résoudre les conflits au fur et à mesure qu’ils apparaissent, et ainsi de ne pas avoir à tout résoudre d’un seul coup à la fin.

En route vers git ReReRe

Ce chapitre est naturellement dédié à Nicolas, suite à une discussion que nous avons eu à la What’s Next la semaine dernière (juste avant qu’il ne s’enfuie pour mettre à jour une présentation…).

Certaines fusions de master vers la branche de développement sont justifiées, quand par exemple, il faut intégrer des correctifs qui impactent les développements en cours. Mais si ces fusions n’ont pour but que de résoudre par avance les conflits, elles sont un peu artificielles et « polluent » l’historique du projet.

Mise en place

Or, il existe un moyen d’avoir une résolution par avance, sans pour autant conserver ces fusions. Il s’agit de la fonctionnalité ReReRe de git (Reuse Recorded Resolution) : son principe est d’enregistrer par avance la résolution du conflit, afin que git l’utilise automatiquement lors de la fusion finale.

Pour activer cette fonctionnalité, il faut l’ajouter à la configuration de git (soit pour un projet, soit de manière globale). Ca ne coûte pas grand chose : c’est donc maintenant quelque chose qui fait partie de ma configuration .gitconfig de base (avec quelques alias et autres choses…). D’autant plus que cela se fait en une commande :

1

git config --global rerere.enabled true

Utilisation

Cette configuration en place, si on utilise la ligne de commandes, on remarque l’apparition de nouvelles lignes lors des fusions contenant des conflits à résoudre :

Recorded preimage for ‘fichier_en_conflit’

Et, une fois la résolution effectuée, au moment du commit :

Recorded resolution for ‘fichier_en_conflit’

Git a donc enregistré la manière dont on a géré le conflit, et sera capable de la rejouer manuellement. Vérifions cela immédiatement. Juste après ce commit, on exécute :

1
2

git reset --hard HEAD^ # Annulation de la fusion que l'on vient d'effectuer
git merge branche_en_conflit

Git indique alors :

Resolved ‘fichier_en_conflit’ using previous resolution.

Le commit n’est pas fait : mais si on regarde les différents fichiers en conflit, on s’aperçoit que la résolution précédente a été appliquée automatiquement. Après vérification de celle-ci, il suffit de valider à nouveau le commit.

Pour le cas qui nous intéresse…

Annuler une fusion pour la rejouer immédiatement après, l’intérêt est limité. Mais ces résolutions sont conservées dans le temps. Ainsi, on peut pré-enregistrer la résolution des conflits entre sa branche et master, annuler la fusion, et continuer à travailler.

La résolution qu’on a enregistrée ne sera appliquée qu’au moment de la fusion finale, quand la fonctionnalité sera entièrement développée.

Concrètement, voici la manière de procéder :

1
2
3
4
5
6
7
8
9
10

git merge master
# Résolution des conflits
git add fichier_en_conflit
git commit -m 'Pré-résolution des conflits avec master'
git reset --hard HEAD^ # Annulation du commit, mais en conservant la résolution
# Suite de l'évolution dans la branche feature…
# Nouvelle pré-résolution de conflit si l'évolution est longue (il n'y a pas de limite).
# Une fois l'évolution terminée, intégration dans la branche principale :
git checkout master
git merge feature # Utilisation des résolutions pré-enregistrées

Informations supplémentaires

Quelques informations complémentaires concernant « git rerere » :

• si on travaille à plusieurs sur la branche feature (en la partageant sur le dépôt central) : les enregistrements de résolution sont partagés entre les membres de l’équipe . Ainsi, même si j’annule le commit après le pré-enregistrement d’une résolution, les développeurs travaillant sur la même branche bénéficieront des résolutions automatiquement lorsqu’ils feront à leur tours des fusions avec la branche master.
• les résolutions enregistrées s’appliquent automatiquement dès que le conflit est à nouveau rencontré, et pas seulement pour les fusions. Ainsi, si par la suite je décide de faire un rebase sur la branche master de mon évolution plutôt d’une fusion, les conflits pour lesquels une résolution est connue seront automatiquement gérés.
• mise en garde pour les cas extrêmes de développements très longs : les pré-résolutions ne sont conservées qu’une durée limitée. Par défaut, cette durée est de 60 jours : c’est généralement suffisant, mais si ça ne l’était pas, il est bien sûr possible d’augmenter ce temps dans la configuration git.

Vu la puissance de cette fonction, il est dommage qu’elle soit assez méconnue. On peut cependant comprendre pourquoi elle n’est pas activée par défaut : il est préférable de bien en comprendre l’intérêt et le mode de fonctionnement du ReReRe avant de l’utiliser. Il n’est en effet pas naturel au début de fusionner et de commiter… pour annuler ce commit immédiatement après !

Comme toutes les commandes git, celle-ci dispose de toute une batterie d’options dans lesquelles on peut se plonger pour aller encore plus loin, avec le manuel officiel.

Conclusion

Voici donc comment on peut monter petit à petit un workflow d’utilisation de git sur un projet qui utilisait préalablement SVN. Pour ceux qui se poseraient la question, ce n’est pas que de la théorie : cet article est le fruit d’une discussion avec Nicolas à la What’s Next d’un véritable retour d’expérience sur un projet où nous avons « switché » de SVN à git (en particulier sur les habitudes SVN qu’il n’est pas évident de perdre).

La journée commence de manière très conviviale, autour d’un café avec Nicolas de Loof, qui nous quittera précipitamment pour aller tester git rerere et mettre à jour sa présentation de ce soir. J’en profite pour faire la publicité des ateliers git attitude qui m’ont appris l’existence et l’utilisation de cette commande !

Keynote de Neal Gafter

Neal Gafter est une des figures emblématiques du langage Java, ayant contribué à son commencement. Il commence par nous présente un historique complet du langage, et des évènements survenus lors de son développement (problème des TCK et du projet Harmony, etc.). Au passage, quelques tests tirés de son livre Java Puzzlers (sur lesquels je me suis fait avoir : j’ai encore quelques révisions à faire…).

Nous passons maintenant à une partie qui m’intéresse : le cloud (encore !), mais à la sauce Microsoft :  Azure. La plate-forme de cloud tourne en environnement Windows, mais se veut ouverte à tous les langages de développement.

Avec la plate-forme Azure, on ne s’occupe pas des machines virtuelles : la plate-forme le gère pour nous, et fournit les VMs clés-en-main, en appliquant automatiquement les patchs de sécurité, etc. Le but est de permettre aux développeurs de se concentrer sur les applications. De même, la plupart des briques techniques sont gérées automatiquement : le load-balancing, l’ajout d’une base de données, etc.

Sur ces points, la description de cette plate-forme me rappelle fortement ce que j’ai pu voir de Cloud Foundry.

Apparemment, Azure est Java Ready : SDK Java, support de JDBC4 (et donc des frameworks de persistence comme Hibernate). Il y a également un Starter Kit permettant de configurer un projet Java sur le cloud.

RabbitMQ par Rob Harrop

Pas de WIFI pendant cette présentation, j’écris le compte-rendu à postériori. Rob était absolument impressionnant (je le soupçonne d’être en fait Chuck Norris déguisé) : démonstration live sans aucun « effet démo » sur 4 langages différents (Java, Erlang, Ruby, Python) pour montrer l’inter-opérabilité de la plate-forme. Ca donne vraiment envie de l’essayer !

A suivi une phase de questions-réponses assez pointues sur la scalabilité, la résistance à la panne, les différences d’approche par rapport à d’autres technologies de messagerie, etc.

Pause déjeuner

Tirage au sort de l’iPad 2 : encore perdu… Je ne perds pas espoir d’en gagner un prochainement.

Comme hier, au Mc Donald’s d’en face, mais sans passer par la case sandwichs.

Le découplage de services par Theo Schlossnagle

Un contributeur à presque 20 projets OpenSource, ça force le respect…

Début de conférence sur les chapeaux de roue : on met les pieds dans le plat avec les raisons du choix d’une architecture NoSQL ou Cloud.

Très bonne démonstration du fait qu’on n’a pas besoin de milliers de machines pour scaler, mais de repenser son modèle dans la majorité des cas.

Le découplage d’une application en systèmes élémentaires indépendants donne de la flexibilité, mais est une opération très complexe. Elle nécessite des systèmes de files (ActiveMQ, RabbitMQ, etc.).

Pour bien concevoir un système, on doit faire la part des choses entre ce que l’on veut (un résultat instantané), et ce que l’on peut obtenir (calcul trop long pour permettre un résultat instantané). Dans ce cas, il faut découpler ce calcul dans un système asynchrone.

Conseils pour parvenir à ses fins :

• Programmation défensive (timeouts, points de vérification, etc.)
• Mise en place de monitoring (vitesse de traitement, taille des files d’attente, nombre de connexions concurrentes, etc.)

Si une application doit tomber en erreur, il faut qu’elle tombe en erreur rapidement (timeouts, etc.) !

Résumé final : excellente conférence pleine de très bons conseils d’architecture !

Tirage au sort des gagnants de places VIP pour Rolland Garros

Félicitations Alexandre !

Architecturer l’expérience utilisateur, par Michaël Chaize

Conférence en français (ça mérite d’être souligné).

L’architecture est impactée par l’expérience utilisateur qu’on veut donner à ses clients

Flex est devenu Open Source en 2007, et peut être codé en ActionScript 3 ou en MXML. Il génère ensuite un fichier Flash. Flex est utilisé à 90% pour des applications internes [Mode mauvaise langue]par honte de les exposer au public[/Mode mauvaise langue].

Depuis 2007, la fondation OpenScreen a permis de travailler avec les acteurs du marché mobile pour optimiser le player Flash sur les terminaux, à l’exception d’un acteur du marché qui a refusé. On se demande bien lequel…

Flex 4.5 semble effectivement assez adapté au développement mobile :

• prise en compte des différentes résolutions d’écran
• développement unique pour Android 2.2 et 2.3, Blackberry Playbook, et les tablettes Apple (moyennant une conversion de code)

Présentation intéressante, et qui donne envie. Mais malheureusement, je n’ai pas vraiment le temps en ce moment de faire du développement mobile (trop d’autres choses dans ma todo-list d’études).

Conférence Akka par Jonas Bonér (CTO de TypeSafe)

Il est difficile de construire des systèmes gérant correctement la concurrence et la scalabilité. Akka (et Scala) a été créé pour tenter de proposer des solutions à cette problématique.

Les trois briques principales de Akka :

• Tolérance à la panne (supervision)
• Scalabilité (système des Actors et clustering)
• Concurrence (Actors, STM, Agents, Dataflow)

Plus tout un ensemble de modules add-on (JPA, etc.)

Qu’est ce qu’un acteur ? un acteur ressemble à un objet : c’est un état, et un comportement. Un acteur est indépendant, isolé, et ne partage pas son état : il n’y a donc pas de mécanisme de lock à implémenter pour gérer la concurrence. Les acteurs communiquent par un système de messages. Les acteurs sont indépendants des threads (à ceci près qu’un acteur est MonoThread) : la seule limitation du nombre d’acteurs est la mémoire.

L’envoi d’un message à un acteur n’attend aucun retour. Le traitement du message est asynchrone. On peut cependant attendre un résultat futur (associé à un timeout) :

1
2
3
4
5

actor ! message
 
val future = actor !!! message
future.await
val result = future.result

Le comportement des acteurs est complètement déterministe.

Travailler avec des acteurs distribués sur plusieurs machines est presque transparent pour le code. Le runtime fournit un mécanisme de clustering (gérant le failover) pour les acteurs, avec plusieurs stratégies de choix du serveur d’exécution (CPU utilisé, mémoire utilisée, etc.).

Elastic Search, par Shay Banon

Présentation très originale, qui s’est déroulée sans aucun slide, mais juste avec une console, et l’outil cURL, qui servait à attaquer l’API REST d’Elastic Search. Pour résumer, Elastic Search est un outil construit autour de Lucene avec les grandes fonctionnalités suivantes :

• Fonctionnement en cluster (avec une gestion très simple de l’ajout d’un serveur au cluster)
• API d’accès entièrement construite en REST, avec des données JSON

L’ensemble de la présentation consistait à nous montrer des fonctionnalités de plus en plus complexes :

• utilisation d’un noeud, puis d’un cluster de noeuds
• création d’index simples, puis complexes (en imposant un format de mapping)
• recherches simples, puis complexes (filtrage, etc.)

Je n’ai encore jamais eu l’occasion de travailler sur une problématique d’indexation de documents (à l’exception d’une mise en place d’une GED Alfresco, mais où l’indexation est déjà gérée). Mais si ça devait arriver, l’API d’Elastic Search en fait un produit qui a l’air particulièrement intéressant.

L’avenir de l’intégration continue par Kohsuke Kawaguchi

La présentation commence par un bilan : la puissance des machines de développement augmente de manière exponentielle. Or, les compétences des développeurs ne suivent pas cette même évolution. Par rapport à la puissance des machines, le développeur est donc une denrée précieuse : il faut donc veiller à ce que l’outillage exploite eu mieux cette puissance machine pour permettre aux développeurs de gagner du temps.

Pour cela, plusieurs pistes :

• utiliser au mieux les gestionnaires de configuration distribués (git par exemple)
• faire exécuter les tests sur le serveur d’intégration continue au lieu de les exécuter sur les machines des développeurs
• etc.

Epilogue

Voilà deux journées très intéressantes, sans aucun bémol majeur : c’est donc une grande réussite pour Zenika (dont je remercie toute l’équipe au passage), qui nous a d’ors et déjà invités à revenir l’année prochaine.

La soirée s’est achevée pour moi par plus d’une heure de discussions techniques passionnées sur les quais du métro avec Alexandre (rencontré hier par l’intermédiaire d’Antoine).

Félicitation à Nicolas qui a le courage de rempiler pour la soirée Jenkins… J’aurai une pensée émue pour sa présentation de ce soir (et j’en suis quitte pour un prochain article sur git, sauf si Sébastien me devance).

[Mise à jour : quelques autres compte-rendus]

• http://hypedrivendev.wordpress.com/2011/05/28/whats-next/
• http://blog.loof.fr/2011/05/merci-zenika.html
• http://www.lemondeinformatique.fr/actualites/lire-what-s-next-le-monde-java-pense-a-l-avenir-sans-oracle-33817.html
• http://www.touilleur-express.fr/2011/05/31/whats-next-2eme-journee-neal-gafters-keynote/
• http://pro.01net.com/editorial/533707/what-s-next-les-retrouvailles-de-la-communaute-java/

[Et ça continue…]

• Chez Xebia, ici et là
• Chez Valtech, ici et là

Une logistique perfectible

Commençons par le sujet qui fâche… la logistique ! A la décharge de Zenika, c’est la première édition de la What’s Next. Et gérer la logistique pour une conférence de plus de 600 participants, ce n’est pas une mince affaire. Voici donc quelques points perfectibles :

• Le Grand Rex n’a visiblement pas l’habitude de recevoir en même temps 500 geeks, tous équipés de leur {smartphone/tablette/ ordinateur portable} (rayer les mentions inutiles). Les 3 réseaux WIFI disponibles ont rapidement été saturés, et n’attribuaient plus d’adresse IP. Heureusement qu’il restait la 3G d’urgence pour couvrir l’évènement via Twitter (le hashtag officiel wsnparis ayant bien servi).
• Un seul point de ravitaillement en café pour les mêmes 500 geeks, c’est l’embouteillage assuré à chaque pause (encore qu’il faille relativiser : la distribution restait suffisamment fluide, et que j’ai toujours pu avoir mon café).
• Le déjeuner a convaincu une bonne partie des participants de se retrouver au Mc Donald’s d’en face. Cependant, vu le rapport entre le prix d’entrée et la qualité des conférenciers présents, je ne regrette pas le déjeuner un peu léger. J’aime autant que la conférence reste à prix abordable, quitte à devoir sacrifier sur la nourriture.

Le choix du Grand Rex a pourtant un certains nombres d’avantages indéniables :

• bien placé, au centre de Paris
• des sièges bien plus confortables que dans la majorité des salles de conférences

Une ambiance géniale et des rencontres très sympatiques

Comme d’habitude, la journée a été très riche en rencontres. Outre les personnes déjà croisées au Paris JUG (ou autres évènements), j’ai pu faire la connaissance aujourd’hui de David Gageot, Nicolas de Loof, Arnaud Héritier, Florian Boulay, ainsi qu’un bon nombre d’autres personnes…

L’ambiance générale de l’évènement était très agréable : très détendue, très geek (sur l’ensemble des participants, on n’a pu dénombrer que quelques cravates). Sur ce sujet, la palme revient d’ailleurs certainement à Jevgeni Kabanov.

Enfin, la fin de journée sur une discussion autour d’une bière était une super-idée pour permettre un debriefing et des débats passionnés dans une bonne ambiance, même si j’ai dû m’absenter assez rapidement, étant attendu.

De très bonnes conférences

Les conférences étaient très bonnes. Parmi celles-ci, j’ai particulièrement apprécié :

• La keynote d’Adrian Colyer, où il était question surtout question de cloud, de cloud… et de cloud ! Cette conférence m’a donné envie de me repencher sur Cloud Foundry, après quelques premiers tests. Au passage, on notera l’apparition d’un nouveau buzzword qui devrait faire fureur dans les prochaines : le microcloud (j’aurai peut-être l’occasion de revenir sur ce concept dans un prochain article).
• La présentation du projet Eclipse Orion, par Boris Bokowski. Elle ne m’a pas convaincu d’abandonner IntelliJ IDEA, mais la démonstration des possibilités d’édition était impressionnante : on ne se croirait pas dans une application web ! Parmi mes appréhension, je me pose en particulier la question suivante : l’IDE web est-il résistant à la perte de la connexion réseau et permet-il de travailler offline ?
• La présentation de Clojure par Howard Lewis Ship était intéressante : elle rappelait bien les différents paradigmes de la programmation fonctionnelle. Cependant, le langage lui-même ne m’a pas du tout convaincu : les exemples de code étaient particulièrement difficiles à relire, et me rappelaient la syntaxe sur-parenthésée du LISP. Sur les langages fonctionnels, je vais donc certainement continuer de faire l’impasse sur Clojure, et poursuivre ma découverte de Scala.
• La présentation de Jevgeni Kabanov sur la gestion de la mémoire en Java était passionnante. En particulier, la modélisation du CPU et de la gestion mémoire par du code Java était impressionnante ! En résumé, un excellent cours de culture générale sur la gestion de la mémoire en Java. Pour revoir cette conférence (éventuellement au ralenti), c’est dans l’ordre ici, ici, et ici.
• Enfin, la présentation des Web Sockets parBrad Drysdale m’a là encore donné envie d’étudier cette API de plus près. Par chance, je me souviens avoir lu rapidement un article parlant des Web Sockets et de Play Framework.

Après cette conférence, je sens que je vais avoir un programme d’étude chargé ces prochains week-ends… Vivement demain pour la suite !

[Mise à jour] Pour un résumé beaucoup plus détaillé de cette première journée, conférence par conférence (et avec des photos), foncez chez Nicolas.

En attendant mon prochain passage par la FNAC pour trouver un bon livre sur la question, j’ai été glaner quelques informations pour débuter :

• La liste des billets de Nicolas sur la question
• Les 99 Scala Problems, que je suis en train de faire petit à petit
• Les différents liens de documentation du site officiel (il y a de quoi faire…)

J’ai eu la chance d’avoir des cours de Caml Light en prépa et de Lisp en école d’ingénieurs : la programmation fonctionnelle ne m’est donc pas inconnue, ce qui m’a grandement facilité l’entrée en matière (même si j’ai rapidement dû me mettre à niveau avec les Case Class et autres concepts que je n’avais encore jamais rencontré).

Les cours de prépa que j’ai pu avoir sur la question étaient excellents. Même s’ils concernent le langage Caml, ils fournissent des exemples originaux dans lesquels la programmation fonctionnelle permet de s’en sortir bien plus facilement qu’en programmation procédurale. Je propose donc aux curieux d’aller les consulter sur le site de notre enseignant.

Problématique

Après ces premiers pas dans le langage à suivre des tutoriels, j’ai trouvé quelques cas d’utilisation dans mes projets sur lesquels le Scala serait mieux adapté que le Java. Il est bien évidemment hors de question de réécrire toute l’application en Scala. Je me suis donc demandé s’il était possible de faire cohabiter facilement dans une même application du code Java et Scala.

Je vais donc partir d’un projet Java standard, et tenter d’y ajouter du Scala petit à petit. Voici donc la structure de mon projet :

• src/main/java : code source Java
• src/main/scala : code source Scala

Choix de l’IDE

Typesafe préconise l’utilisation de Scala-IDE, basé sur Eclipse. J’avoue ne même pas l’avoir essayé : je n’ai donc pas de point de comparaison. Je me suis directement tourné vers le plugin Scala d’IntelliJ IDEA, et il me convient parfaitement :

• coloration syntaxique
• autocomplétion (y compris lorsque le paramètre est une fonction)
• détection des erreurs de compilation à la volée
• possibilité d’utiliser du Scala et du Java dans un même projet, avec des appels croisés
• etc.

Bref… je retrouve dans le plugin Scala tous les petits plus que j’apprécie dans IntelliJ par rapport à Eclipse !

Appeler du code Scala depuis du Java

Après quelques tests, il semble qu’appeler du code Java depuis Scala ne pose apparemment aucun problème. Mais dans le cas qui m’intéresse d’une application Java pré-existante, c’est plus l’inverse dont je vais avoir besoin.

Prenons donc un code utilitaire en Scala :

1
2
3
4
5
6
7

object ListUtils {
    def length[A](ls: List[A]): Int =
        ls match {
            case Nil => 0
            case _ :: tail => 1 + length(tail)
        }
}

Premier test simpliste en Java :

1
2
3
4
5
6

public static void main(String[] args) {
    java.util.List<String> listeTest = new java.util.ArrayList<String>();
    listeTest.add("un");
    listeTest.add("deux");
    System.out.println("Taille : " + ListUtils.length(listeTest));
}

On tente de compiler, et les premiers soucis ne se font pas attendre :

<A>length(scala.collection.immutable.List<A>) in org.courtine.scala.ListUtils cannot be applied to <java.lang.String>(java.util.List<java.lang.String>)

L’erreur a le mérite d’être explicite. Il ne nous reste donc qu’à convertir notre java.util.List en scala.collection.immutable.List. Je n’ai pas encore réussi à faire cette conversion côté Java. En revanche, c’est une conversion assez simple côté Scala. Il suffit donc de créer dans notre classe utilitaire Scala une méthode supplémentaire :

1

def length[A](ls: java.util.List[A]): Int = length(ls.toArray.toList)

On recompile et on exécute l’ensemble : ça marche !

Après ce test utilitaire, un autre test concluant : une classe métier Scala peut être instanciée et utilisée directement dans le code Java, sans aménagement particulier (du moins une classe simple : je n’ai pas encore essayé de mettre en défaut cette compatibilité avec des cas tordus).

Automatiser le build

Ces premiers tests étant concluants, passons à l’étape du build : l’exécution des tests se passe bien dans IntelliJ, mais une fois sorti de l’IDE, peut-on assurer un build automatisé (tests, intégration continue, etc.).

Pour les projets sur lesquels je travaille, le build est assuré par Maven. Après une recherche rapide, on découvre qu’il existe un plugin Scala pour Maven. Voici donc le fichier pom de mon projet :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.courtine</groupId>
    <artifactId>scala-java-test</artifactId>
    <version>1.0</version>
    <packaging>jar</packaging>
    <name>scala-java-test</name>
    <repositories>
        <repository>
            <id>scala-tools.org</id>
            <name>Scala-tools Maven2 Repository</name>
            <url>http://scala-tools.org/repo-releases</url>
        </repository>
    </repositories>
    <pluginRepositories>
        <pluginRepository>
            <id>scala-tools.org</id>
            <name>Scala-tools Maven2 Repository</name>
            <url>http://scala-tools.org/repo-releases</url>
        </pluginRepository>
    </pluginRepositories>
    <build>
        <plugins>
            <plugin>
                <groupId>org.scala-tools</groupId>
                <artifactId>maven-scala-plugin</artifactId>
                <executions>
                    <execution>
                        <id>compile</id>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <phase>compile</phase>
                    </execution>
                    <execution>
                        <id>test-compile</id>
                        <goals>
                            <goal>testCompile</goal>
                        </goals>
                        <phase>test-compile</phase>
                    </execution>
                    <execution>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
    <dependencies>
        <dependency>
            <groupId>org.scala-lang</groupId>
            <artifactId>scala-library</artifactId>
            <version>2.9.0</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Ce fichier automatise convenablement le packaging de l’application par Maven.

Et maintenant

D’après ces premiers tests, il semble donc qu’on puisse créer une application mélangeant du code Scala et Java, avec un coût d’entrée faible (du point de vue des adaptations à effectuer : j’exclue ici le coût d’apprentissage du langage Scala lui-même, qui est loin d’être négligeable).

La prochaine étape sera d’essayer de vérifier si un tel mélange de codes n’est pas préjudiciable aux performances.

L’étape suivante sera certainement la plus compliquée : convaincre un client des avantages d’un tel mélange (code plus expressif sur les parties métier du projet), pour pouvoir le mettre en oeuvre sur un véritable projet.