Infotel partenaire d’ElasticSearch

Infotel est fier de vous annoncer son nouveau partenariat technologique avec ElasticSearch, effectif depuis le 12 mai 2014.




Logo Elasticsearch

Pourquoi ce partenariat ?

1.

Pour Infotel, il permet de développer son expertise reconnue dans la mise en œuvre de d’approches innovantes pour lesquelles ElasticSearch joue les premiers rôles.

2.

Pour ElasticSearch, il offre à ses clients la qualité de son support en l’accompagnant de l’expertise d’Infotel qui opère au cœur des systèmes d’informations complexes (Banque, Industrie Automobile, Assurance, Services…).


Infotel développe au cœur du métier de ses clients des solutions qui s’appuient sur les formidables capacités d’Elasticsearch à indexer et valoriser de très grandes quantités de données. Que ce soit de la donnée en texte libre (Documents, facture, Mails, tweets, forums..), des logs techniques, des logs applicatifs ou bien de la donnée statistique, la liberté offerte par ElasticSearch en fait un choix de premier ordre pour construire sa solution BigData.

Portail avec ElasticSearch

Exemple : Solution d'exploration documentaire motorisée par Elasticsearch




De plus, Infotel poursuit la montée en compétences de ses collaborateurs sur les technologies Big Data pour vous permettre d’accéder à un savoir-faire reconnu et en ligne avec votre stratégie IT. Vous pouvez désormais le compléter avec le support ElasticSearch dont vous avez besoin, lors de vos développements ou votre passage en production.


Vous voulez en savoir-plus ?
N’hésitez pas à nous contacter : ingenierie.technique@infotel.com



Université de la Performance -retour sur DevoxxFR 2014

Sebastien VAIRA, Senior Developper JEE / Grails revient sur une session Performance de DevoxxFR 2014

La performance, partie intégrante du travail de chacun d’entre nous, se doit d’être au cœur de nos développements ; nous ne devons pas négliger cet aspect et l’intégrer au plus vite dans nos cycles de développements. Car s’attaquer aux mesures (métriques) suite aux développements est rarement gage de réussite ; cela peut même induire une forte refonte du code, voire une remise en cause de l’architecture. Et c’est là que les plus grosses dérives se produisent…
Dans cet article, nous allons revenir sur les outils de référence et les pratiques qui ont été abordés lors du Devoxx 2014.

1. Préparer les jeux de données – Benerator


Il n’est pas toujours aisé de pouvoir disposer d’un jeu de données d’une volumétrie comparable à celle de PROD mais aussi d’une qualité semblable.
Certains d’entre nous, en particulier dans le domaine bancaire, ont également des contraintes d’anonymisation à respecter ; ce qui complexifie encore davantage la mise en place (l’acquisition) d’un jeu de données cohérent (vis-à-vis de la PROD).

Pour répondre à cette problématique, il existe l’outil : Benerator
http://databene.org/databene-benerator

Qui présente (entre autres) ces avantages :

  • Génère des données de TEST sans limite de taille
  • Rend anonymes les données sensibles
  • Insère des données en base si besoin / les ressort en fichiers sinon (CSV/XML/plat etc.)
  • Il embarque de base différents domaines (adresse, personne, web, finance etc.) pour faciliter la création de données
  • Il est multi-plateformes
  • Il supporte la majorité des BDD (Oracle, DB2, MySQL, PostgreSQL etc.)
  • Enfin, il est gratuit.

2. Exécuter une mesure unitaire – Chrome developer tools

La mesure unitaire réfère ici à un test de performance avec un utilisateur sur une base de données chargée.
Ceci peut facilement être réalisé avec Chrome DevTools qui nous fournit de nombreux composants pour :

  • tracer le temps réseau :
  • tracer la chronologie des événements (timeline) et ce qui prend du temps (chargement des ressources, parsing JS, calcul des styles etc.) :

  • tracer le temps d’exécution des scripts et l’utilisation mémoire :

3. Exécuter des tests de charge – Gatling

Cette fois par test de charge, on entend ici une cible de 100 utilisateurs par ex. et ce sur un volume BDD de PROD.
Simuler l’utilisation simultanée de votre serveur par X utilisateurs est généralement réalisé par l’écriture d’un script.
On connaissait jMeter, outil open-source d’Apache, qui réalise correctement ce travail mais qui est considéré, du moins au Devoxx, comme « ancestral ».
LoadRunner, logiciel HP payant ;
la tendance serait plutôt désormais à l’utilisation de l’outil Gatling :
http://gatling-tool.org/

Ce dernier offrant comme particularités :

  • Un vrai langage de développement pour les scripts : le Scala (il s’agit donc bien ici d’un développement à part entière dans le cadre d’un projet)
  • Un module ‘Recorder’ (sorte de proxy entre votre navigateur et votre application) vous aidant à écrire des scénarios ; pour ce faire, il suffit simplement de l’activer et de naviguer au sein de votre application Web…
  • La mise à disposition d’un plugin Maven gatling
  • La génération de rapports HTML avec graphiques très sympas (visuel + significatif) :

A noter, toujours dans la rubrique des tests de charge réalisables via Gatling, que bien souvent les tests suivants ne sont pas considérés/réalisés :
a) Test de rupture
Ayant pour objectif de déterminer les limites de votre application (en terme de nombre d’utilisateurs max ou de temps de réponse non acceptable)
b) Test de vieillissement (test d’endurance)
La capacité de votre application à fonctionner sur une période étendue (ex : 48h) avec une charge constante égale à la charge moyenne.
Il est évidemment conseillé de ne pas les négliger…

4. Industrialisation/automatisation des tests de charge – Jenkins, Capistrano, Chef

La question des performances est souvent traitée à la fin du projet ;
Ce qui implique que si elles ne sont pas acceptables, des dérives risquent d’être observées pour rectifier le tir ; l’architecture risque même d’être revue !
Ainsi donc, pour éviter ce type de faux pas, il faut intégrer les tests de performance au plus tôt dans le cycle de développement de nos projets et ce de préférence au sein d’une intégration continue.

Jenkins, outil open-source d’intégration continue, est un bon candidat pour ce faire.
http://jenkins-ci.org/

Au sein d’un job spécifique gatling, il permettrait par ex. de :

  • a) Créer un environnement
  • b) Réaliser un/des tirs de performance
  • c) Détruire ce contexte.

On pourrait ensuite visualiser les tableaux de bord Gatling résultants directement sous Jenkins.
Une des particularités intéressante en découlant serait de poser des limites sur les temps de réponse attendus pour votre application (ex : <=200 ms) ;
De sorte que si un des développeurs impacte l’aspect performance, le build Jenkins soit en conséquence cassé et le développeur notifié par mail…

A noter, dans l’optique de mise en place sous Jenkins d’un environnement adéquat pour réaliser les tirs de performance (ex : application déployée temporairement sur un espace virtuel), que ce dernier peut facilement être couplé aux outils suivants : ‘Chef’ et ‘Capistrano’.
Chef permettant de déployer facilement serveurs et applications sur un emplacement physique/virtuel/cloud :
http://www.getchef.com/chef/

Capistrano permettant d’exécuter des commandes SSH sur des serveurs distants :
http://capistranorb.com/

6. Problème de contention/identifier une fuite mémoire – VisualVM

Pour mesurer la consommation des ressources d’une application tournant sous la JVM, il est préconisé d’utiliser l’outil VisualVM, fourni dans les distributions Sun du JDK.
Egalement disponible en téléchargement ici :
http://visualvm.java.net/

Cet outil nous offre une petite interface graphique simple pour le suivi :

  • De l’utilisation CPU
  • De la consommation mémoire
  • Du volume de classes chargées par la VM
  • Des threads

Il permet aussi :

  • De réaliser le monitoring sur une application distante :
  • De réaliser un profilage CPU/mémoire :
  • Et enfin de diagnostiquer les fuites mémoires (par analyse des opérations qui consomment le plus)

Avec ce type d’outil, vous avez désormais de nombreuses possibilités pour analyser les problèmes de contention.

7. Identifier un problème d’index – jstack, explan plan

8. Mise en place du monitoring – collectd, Graphite et Metrics

  • Collectd : outil portable écrit en C et agissant tel un démon qui ‘monitore’ tout périodiquement et collecte des métriques relatives aux statistiques de performance du système
    http://collectd.org/

  • Graphite : outil écrit en Python proposant des interfaces graphiques avancées pour le suivi temps-réel des métriques de votre serveur
    http://graphite.wikidot.com/

  • Metrics : librairie Java intégrable dans votre projet via Maven et permettant de mesurer le comportement des composants critiques ; A noter qu’il se couple à Graphite pour la partie reporting.
    http://metrics.codahale.com/

  • metrics-spring : annotation Spring ‘@Timed ‘ sur les méthodes (sensibles) de votre serveur ;
    permettant d’obtenir ce type de sortie console/log:

9. Tuning système – Bonnie++

Les développeurs ne sont pas toujours à incriminer dans le cas de performances insatisfaisantes ;
N’oublions pas que les disques durs, CPU, cartes réseaux sont autant de composants qui peuvent influer sur les résultats d’une application ; et donc par conséquent l’aspect ‘Tuning d’infrastructure’ est alors à considérer.
A été abordé lors du Devoxx un petit outil de benchmark : « BONIE++ » pour réaliser une analyse système et vérifier si des optimisations sont possibles.
http://www.coker.com.au/bonnie++/

Conclusion

Cet article a plutôt vocation à être un recueil d’outils (en tout genre) pour réaliser des mesures unitaires/de charge, automatiser ces tests au sein d’une intégration continue, disposer de tableaux de bord modernes, être capable suite à l’obtention éventuelle de résultats négatifs de diagnostiquer un problème de contention/fuite mémoire/index et aller pourquoi pas jusqu’à du tuning système.
Chacun de ces outils a été abordé, ses facettes notables retranscrites ; je laisse néanmoins à chacun d’entre vous la possibilité de ‘creuser’ et de déterminer la réelle valeur ajoutée de l’outil au sein de vos projets.



Dépoussierez votre construction d’appli avec GRADLE

Les acteurs en place


GRADLE


Gradle est un moteur de production basé sur le langage Groovy fonctionnant sur une plateforme JAVA. Il permet d’automatiser les build, les tests, les publications, les déploiements, etc. pour une multitude de langages.

Apache Maven


Aujourd’hui Maven est utilisé par la majorité des développeurs pour automatiser le build et le deploy des applications.
Il se base sur un concept « Convention over configuration » qui impose le respect d’un certain nombre de règles :

  • Définition des règles de construction via des fichiers XML, les POM,
  • Nommage et structuration de répertoires projet (src/main/Java, src/main/resources, src/main/webapp, etc.).

A ce concept Maven accole un cycle de vie très stable basé sur des gaols prédéfinis (compile, test, package, install, deploy, etc.).
Les principaux reproches faits à Maven sont que

  • Maven est Monolithique, il laisse très peu de place pour les spécificités et la customisation,
  • Maven repose sur de la configuration XML qui devient rapidement peu lisible,
  • Maven propose un fichier de build par artefact,
  • Maven ne permet de Build d’un seul langage,
  • La résolution des problèmes de dépendances est difficile et fastidieuse.

Gradle avance ses atouts


Gradle reprend et agrège les points forts d’ANT, Maven, Ivy et Groove, apportant flexibilité et souplesse.
Il reprend les idées et concepts suivants :

  • Le concept « Convention over configuration » de maven
  • Le cycle de vie de Maven
  • La notion de repositorie de Maven
  • Le moteur de dépendances de Maven et Ivy
  • Le Scripting de ANT
  • Le langage de programmation de Groovy

Gradle repose sur un mécanisme de cycle de vie qui s’appuie sur un système de tâches. Ce cycle de vie est basé sur l’enchainement d’un certain nombre de tâches prédéfinies et customisable. Ce cycle de vie peut lui aussi être customisé via des taches personnalisées et dynamiques.
Définition d’une tache

task myCopy(type: Copy) {
    from 'resources'
    into 'target'
    include('**/*.txt', '**/*.xml', '**/*.properties')
 }

Cette liberté de création et modification de tâches offre à Gradle la décorrélation du build et du deploy ainsi que la gestion de plusieurs artéfacts au sien d’un même fichier build Groovy.

La définition des tâches et donc des règles de construction se fait à travers des fichiers écrit en Groovy. Un fichier de build Gradle (build.gradle) pour un projet Java tient en une ligne :

apply plugin:'java'

Gradle permet aussi une certaine souplesse dans la définition des repositories (adresse repository officiel, adresse repository local, adresse proxy, adresse serveur de partage, etc.) ainsi que dans la résolution des dépendances (remplacement de versions manuel, remplacement de dépendance manuel, etc.)
Définition de dépendance

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

Définition de repositories

repositories {
     mavenCentral()
 }

Un point fort supplémentaire de Gradle est sa notion de build incrémental qui lui permet, grâce à la définition de point d’entrées et de sorties lors de la construction des livrables, de déterminer si le build est UP-TO-DATE ou non.
La commande d’init d’un projet est :

gradle init

Enfin, pour simplifier la notion de version au sien de projet, Gradle, lors de l’initialisation du projet, génére un wrapper dédié au projet qui contient l’ensemble des informations de versions y compris la version de Gradle lui-même. Ainsi, le build du projet est portable sur n’importe quel environnement. Le wrapper contient la version de Gradle et un lien permettant de télécharger cette version. Ce lien étant paramétrable à souhait.

Par François Nassoy, Chef de Projet



Retour DevoxxFr #2: Adoptez-les stratégies gagnantes de Atlassian

Damien Ridereau, Senior Developper chez Infotel, présente les grands principes qui permettent de faciliter l’innovation dans les projets logiciels d’envergue.

Atlassian ou le développement logiciel Kick-Ass


Comme le souligne Tariq Krim dans son rapport à Fleur Pellerin, le logiciel vit actuellement sa révolution. Le développement passe de l’artisanat à l’ère industrielle. Les démarches de développement empiriques s’affinent et évoluent pour laisser place à des processus et méthodologies d’automatisation.

Cette transformation n’a cependant pas encore atteint la maturité et est toujours en phase d’évolution. Il est en effet fréquent de voir des projets fonctionnant de manière erratique et ne satisfont pas les attentes des utilisateurs. Dans sa conférence au DevoxxFR 2014, Samuel Le Berrigaud explique comment Atlassian a récemment revu en profondeur son organisation pour « kick-ass again » (déchirer de nouveau).

Mesurer à l’avance l’intérêt

Avant de commencer tout développement, il est important de savoir quel impact aura un produit ou une fonctionnalité. Un exemple marquant est le smartphone Kin développé par Microsoft et stoppé après seulement 48 jours de commercialisation car il ne correspondait pas aux attentes des utilisateurs.

D’autres sociétés comme IBM ont eu la bonne idée de simuler l’utilisation de leur produit avant de commencer tout développement. IBM prévoyait par exemple de créer un logiciel de commande vocale d’un ordinateur. Un utilisateur a été invité à tester le logiciel de simulation dont toutes les actions étaient réalisées par un humain. La conclusion de cette étude a montré que ce moyen d’interaction était fastidieux et fatiguant.

Souvent, une analyse préalable permet d’économiser beaucoup de temps et d’argent. Il est possible de réaliser de simples maquettes sur papier pour se projeter sur les fonctionnalités à développer.

Anticiper et intégrer le retour utilisateur

Un autre point important est la boucle de feedback utilisateur. Pour avoir un produit de qualité, le retour des utilisateurs est important;en conséquences, pour les inciter à donner leur avis, il est impératif de rendre l’interface de feedback facile à trouver, simple et rapide à soumettre. Le support doit être effectué par des développeurs pour leur permettre de mieux comprendre les utilisateurs et leurs besoins.



Dans les projets de grande envergure, les équipes de développement et de test sont compartimentées. Ainsi, quand une fonctionnalité est réalisée, celle-ci est transférée à l’équipe de test et est retournée aux développeurs si une anomalie est trouvée. Cette approche est partiellement contradictoire avec l’objectif de détecter le plus tôt possible un possible bug quoique souvent nécessaire. Pour remédier à cela, les développeurs doivent aussi réaliser une partie des tests. Une fois une fonctionnalité achevée, un autre programmeur va effectuer la revue de code et réaliser des tests sommaires. L’équipe de test prend ensuite le relais.
De même, les testeurs peuvent acquérir une connaissance de programmation pour mieux réaliser leurs tests. Cela peut passer par du « pair programing » avec un développeur. Il est aussi possible d’effectuer des blitz tests (tests éclairs) où toute l’organisation effectue en un temps court, le test de l’application ou d’une nouvelle fonctionnalité.



Sur le même modèle « trans-discipline », il est intéressant de former les développeurs au design. Atlassian a par exemple fait analyser Jira par un designer qui a remarqué que l’application contenait 20 types différents de listes déroulantes. Généralement seulement quelques règles simples et outils pour tester le design sont nécessaires. Comme pour les testeurs, il est primordial d’enseigner des bases de développement au(x) designer(s).


De manière générale la multiplicité et complexité des processus nuisent à la rapidité de développement. Quelques règles simples sont suffisantes, ceci se décline par exemple dans les règles de gestion de configuration pour paralléliser les travaux:

  • Une branche par nouvelle tâche
  • Les branches ont des durées de vie limitées (2 jours en moyenne)
  • Utiliser les Pull Requests pour informer les membres de l’équipe de la disponibilité d’une nouvelle fonctionnalité

Renforcer la communication

Dans un contexte de mondialisation, un nombre croissant de projets se retrouvent avec des acteurs dans différentes régions du globe et des équipes distribuées. Le chat est un choix judicieux qui résout la majorité de ces contraintes. Ce moyen permet de dialoguer à distance, sur différents fuseaux horaires et permet d’ajouter facilement de nouvelles personnes dans la discussion. Par exemple, grâce aux historiques de conversation, les équipes peuvent consulter les discussions réalisées pendant la nuit par les autres membres de l’équipe.

Automatiser

Un des axes cruciaux pour améliorer l’efficacité est l’automatisation. Par exemple, le build de Jira était compliqué, instable, et prenait plus d’une heure. Après optimisation, seulement 10 minutes étaient nécessaires.
Voici des leviers possibles d’amélioration :

  • Eviter de reconstruire les artefacts dont le code n’a pas été modifié
  • Paralléliser au maximum les tests
  • Avoir une stratégie de build différenciée:
    1. Tests de performance durant la nuit
    2. Tests de plateformes toutes les heures
    3. Intégration continue : build + tests unitaires et graphiques après chaque check in
  • Garder un œil sur les statistiques (ex : indicateurs de qualité de code)
  • Détecter les tests aléatoires

Ces axes d’amélioration ne prétendent pas servir de référence pour l’organisation des projets, mais proposent de se poser les bonnes questions pour pouvoir délivrer un projet de qualité dans les meilleures conditions.
En conclusion : « Etre excellent dans tout ce que l’on réalise ».



Retour sur DevoxxFR 2014 #1 : la programmation fonctionnelle en Java

Duy Anh PHAM, Consultant JEE & Grails, revient sur une des présentations de DevoxxFr 2014 qu’il a apprécié (au même titre que « Gradle ne fait pas que remplacer Maven », « PIT, pour savoir si vos tests vous protègent des mutants » et « Do you really get classloaders ? »)

1) LA PROGRAMMATION FONCTIONNELLE ET LES LAMBDAS

Java 8 introduit (enfin!) les expressions lambdas dans le langage et la programmation fonctionnelle.
Le premier bénéfice est de réduire la quantité de code grâce à une syntaxe plus explicite et concise. C’est la promesse d’un code plus robuste, mais aussi vecteur de gains de performances.


Pour en comprendre l’intérêt, nous allons l’illustrer par un exemple. Nous pouvons imaginer une lecture d’un fichier XML volumineux avec l’API SAX et récupérer la valeur d’un attribut en retournant int ou BigDecimal.

public void parse() {
    ...
    if (name.equals("id")) {
        id = getIntAttributeValue(attributes, "id");
    }
    ...
    if (name.equals("volume")) {
        vol = getBigDecimalAttributeValue(attributes, "vol");
    }
    ...
}
 
private int getIntAttributeValue(Attributes attributes, String name) {
    return Integer.parseInt(attributes.getValue(name));
}
 
 
private BigDecimal getBigDecimalValue(Attributes attributes, String name) {
    return new BigDecimal(attributes.getValue(name));
}



Les 2 méthodes se ressemblent et il est possible de factoriser en une seule en passant un paramètre qui sera une fonction effectuant la transformation voulue :

private <T> getValue(Attributes attributes, Function<String> function) {
    return function.apply(attributes.getValue(name)));
}

La fonction doit :

  • recevoir un String et renvoyer un type T (int ou BigDecimal)
  • posséder une méthode pour invoquer, ici apply
  • transformer une méthode en valeur

Un nouveau type aurait été nécessaire pour représenter une telle fonction mais Java possède déjà ce type : les interfaces. Un programmeur peut définir une implémentation par type de retour voulu, l’instancier et le passer en paramètre de getValue au moment de l’appel. Une autre possibilité est de définir une classe anonyme mais elle présente d’écrire des éléments de classe qui ne sont pas du tout utilisés, seul le corps de la méthode importe.

Avec les expression lambdas, il est possible d’écrire directement le code à la place du paramètre

vol = getValue(attributes, "vol" -> new BigDecimal("vol"));

L’expression à gauche de -> est l’ensemble des paramètres de la fonction
L’expression à droite de -> est le corps de la méthode de l’interface

Le code devient :

public void parse() {
    ...
    if (name.equals("id")) {
        id = getValue(attributes, "id" -> Integer.parseInt("id") );
    }
    ...
    if (name.equals("volume")) {
        vol = getValue(attributes, "vol" -> new BigDecimal("vol") );
    }
    ...
}

Une telle interface est appelée interface fonctionnelle qui possède une seule méthode abstraite. Elle est annotée @FunctionalInterface. Elle n’est pas obligatoire mais indique qu’il s’agit d’une une interface fonctionnelle dans la javadoc. Plusieurs interfaces depuis Java 1.0 le sont : Comparable, Runnable.
Le package java.util.function contient des fonctions courantes.


En plus des lambdas, il existe plusieurs références de fonction pour faire de la programmation fonctionnelle :

  • référence vers une méthode statique. Le code s’écrit Integer::parseInt
  • référence vers une méthode d’instance d’une classe. Le code s’écrit String::length
  • référence vers une méthode d’instance d’un objet. Le code s’écrit « Foo »::length

2) LES LAMBDAS DANS LES STREAM

Les lambdas se retrouvent dans l’utilisation de l’API Collection combinée avec la nouvelle API Stream

Collection<Person> persons = new ArrayList<Person>;
// on peuple la liste
 
// on filtre la liste
persons.stream().filter(p -> p.age() > 10);

La collection est transformée en flux puis filtrée à l’aide d’une fonction. La fonction est un prédicat, fourni par le JDK pour réaliser un test, qui retourne vrai si l’âge de la personne est > à 10 ans. Habituellement les traitements logiques travaillent avec une collection complète dans une boucle. Avec les Stream il est possible d’effectuer des traitements à chaque élément et utiliser la programmation fonctionnelle.

@FunctionalInterface
public interface Predicate<T> {
    boolean test(T t);
}

L’introduction de la programmation fonctionnelle est une grande évolution comme les Generics pour Java 5.