Premier pas dans l’internet des objets avec les Beacons

Nous voulons partager avec vous notre projet Beacon tout juste sorti par notre équipe Innovation.

L’idée est de pouvoir accompagner nos clients dans leurs projets disruptifs et force est de constater que l’Internet des Objets (IoT) est au cœur des enjeux du moment. L’annonce de Google concernant le ‘Web Physique’ (https://github.com/google/physical-web/blob/master/documentation/introduction.md ) ne va pas démentir cette observation.


Toujours plus contextualisée et personnalisée, l’information va vivre au contact des balises Beacons, tags NFC ou autre. Notre projet est de démontrer le potentiel de ces technologies en associant une application mobile avec une solution Web qui officie à la fois comme pilote des fonctions contextualisées et réceptacle du flot de données généré (…Big Data, le mot est lâché).


Fonctionnement schématique de la solution

Fonctionnement schématique de la solution



Première étape, l’acquisition de la balise et sa configuration.

On trouve des sites qui offrent des packages prêts à l’emploi, il faut ensuite associer paramétrer les quelques informations qui seront émises par notre balise.

  • UUID : c’est l’identifiant unique de notre balise, modifiable et donc personnalisable
  • Major : un des paramètres modifiables; on pourra y associer par exemple un numéro de magasin
  • Minor : autre paramètre, qu’on peut penser comme une précision apportée à un ensemble de balises reliées par la valeur d’un ‘Major’, comme le rayon d’un magasin
Balises utilisées pour le projet d'Infotel

Deuxième étape, créer l’application qui va capter le signal et prendre la décision appropriée :

Prérequis, il faut que votre téléphone embarque la prise en charge du BlueTooth Low Energy, qui est aujourd’hui disponible pour les smartphone sous iOS, Android 4.3 et Windows 8.
Une fois maîtrisée la détection du signal, on crée différentes interactions, différenciées selon que l’application est en veille ou en premier plan.

Capture Alerte iBeacon Catpure notification présence iBeacon
Envoyer une alerte ou un message associé à la proximité d’une balise Lorsque l’application est en veille, les notifications sont possibles, de manière plus ou moins intrusive.
Pour une interaction plus riche, on propose l’affichage d’un contenu HTML qui est fourni par notre serveur, mais on pourrait également constituer un message si l’application mobile embarque la logique (catalogue de produit embarqué, envois de messages en mode chat).

Voici le périmètre de notre solution :

  • Créer une application qui capte les signaux des Beacons,
  • Dans une approche connectée, envoyer au serveur les informations techniques de la balise associée à son identifiant,
  • Recevoir en retour l’action à déclencher qui se peut prendre une des valeurs suivantes :
    Aucune action : nous voulons simplement enregistrer le passage de notre usager,
    Réveil de l’application,
    Affichage d’une notification,
    Affichage d’un contenu Web (dans une WebView).
  • Filtrer les événements pour ne pas prendre en compte les signaux qui ne sont pas directement liés à notre parc de balises,
  • Afficher un sémaphore de présence de balises.


Par ailleurs, nous avons ajouté quelques fonctionnalités pour l’administration du parc : historique des signaux captés, débogage avec visualisation des informations techniques, configuration, et comportement par défaut au travers de ‘bouchons’ pour simuler une connexion à notre serveur.


Troisième étape, piloter son parc.


Il faut ensuite associer du contenu et des comportements à chaque balise, ce que nous faisons dans notre application centrale. En voici quelques captures d’écran représentatives.

Paramétrage d'une balise

Paramétrage d'une balise et association d'actions

création d'une action

Création d'une action type

Création d'une action générique

Visualisation d'une événement lié à une balise



Quatrième étape, analyser et améliorer.


Pour faire vivre la donnée et comprendre les comportements relevés par nos balises, rien de mieux que d’utiliser la masse d’information correspondant aux événements en les déversant dans ElasticSearch (par exemple).

On crée ainsi des tableaux de bord dans lesquels on décline les différentes actions, avec une visualisation temporelle.

On peut ensuite se pencher sur une classification et une analyse plus poussée.



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 ».