Le blog de Fabien DUMINY

Un blog utilisant WordPress

Skip to: Content | Sidebar | Footer

Devoxx France 2013 – Domotique Low Cost, façon DIY

23 mai, 2013 (09:00) | Devoxx France 2013 | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « Domotique Low Cost, façon DIY » présentée par Laurent Huet.

Les raisons de mettre en place une installation de domotique peuvent être l’automatisation ou la surveillance. Mais quelle solution adopter ?

Les magasins grand public de bricolage proposent des centrales domotique mais celles-ci coûtent environ 450 €, auxquels il faut rajouter le prix des accessoires. Elles ne sont pas très pratiques et assez coûteuses.

L’alternative consiste à réaliser soi-même (en anglais : DIY pour « Do It Yourself ») une centrale de domotique. Deux possibilités s’offrent alors au bricoleur : récupérer du matériel existant (console de jeux …) ou acheter une carte basée sur un processeur ARM sous Linux. Les 3 cartes les plus connues sont :

  • Raspberry Pi (45 €, 60 € avec les accessoires) : par défaut, cette carte ne contient pas de port analogique
  • BeagleBone (90 €) : celle-ci est beaucoup plus puissante et dispose de plus de connecteurs d’entrées/sorties
  • Arduino (20 €)

Pour le langage de programmation, il faut choisir celui qui (vous) convient (parfois certaines entrées/sorties nécessitent des réactions à la microseconde). Comme ces cartes fonctionnent souvent sous Linux, ce langage est souvent le C/C++ et l’accès au périphérique se fait via l’API Sysfs, un système de fichier Linux permettant de piloter les périphériques. En ce qui concerne la partie matériel, il faut souvent piloter des composants fonctionnant sous courant fort : cela nécessite l’utilisation d’un relai ou un triac (5 €).

Lorsqu’on veut connecter plusieurs capteurs sur un même port, il faut utiliser un bus associé à un UART. Il en existe de différents types :

  • bus 1-Wire : 1 seul fil sur lequel se connecte chaque capteur muni d’une puce avec un code unique
  • bus I2C : bus série sur 3 fils
  • bus SPI
  • bus CAN : utilisé dans l’automobile

Il est également envisageable d’utiliser une liaison radio, notamment dans le cas où le capteur se trouve dans un endroit difficile d’accès.

Comme exemple d’application, Laurent propose de se connecter au compteur EDF afin de visualiser en temps réel la consommation électrique et la puissance utilisée. Cela n’est possible qu’avec le compteur électronique, et pas avec le compteur mécanique avec un petit disque qui tourne (image). Il ne faut surtout pas toucher à la partie scellée par un plomb (qui est la propriété d’EDF). Pour récupérer les informations, il faut se connecter avec une liaison série au bornier client, en utilisant un convertisseur UART/TTL. Les spécifications EDF sont disponibles sur le web.

Attention : Laurent nous signale qu’il est facile de griller une carte SD en écrivant sur celle-ci toutes les minutes, pendant 3 mois. En effet, le nombre d’écriture sur ce genre de composant est limité.

Pour ses développements, Laurent utilise l’environnement de développement Javascript Cloud9 (basé sur Node.js) tournant directement sur la carte BeagleBoard. Il termine par une démonstration d’un petit serveur en HTML 5, tournant sur BeagleBoard et affichant la température ambiante mesurée par un capteur (2 €). L’ensemble coûte moins de 150 €.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , , ,
Comments: -

Devoxx France 2013 – NIO, pas si simple ?

21 mai, 2013 (09:00) | Devoxx France 2013, Java | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « NIO, pas si simple ? » présentée par Emmanuel Lecharny.

Rappel des différentes API d’entrées/sorties en Java

  • BIO (Blocking IO)

    Cette API, présente depuis le début de Java, permet la programmation classique d’entrées/sorties bloquantes, comme en langage C.

    Elle est plus performante que les 2 autres API. Chaque opération bloque un thread. Il faut donc l’utiliser quand il y a peu de connections simultanées (chaque connexion dispose de son thread dédié), c’est à dire 10000 au maximum.
  • NIO (New I/O)

    Cette API, apparue avec le jdk 1.4, est plus complexe à utiliser. Il faut d’abord appeler l’une des méthodes select (select() ou select(long)), ce qui bloque le thread appelant en attente d’une opération possible (accept, connect, read, write) sur l’un des sélecteurs. Ensuite, on exécute l’opération pour laquelle chaque sélecteur est prêt.

    Avec cette API, un thread est réveillé quand une donnée est reçue. Elle fonctionne sur un mode événementiel et il faut donc moins de threads que de connections. Elle ne sert pas à règler les problèmes de charge et est environ 20 à 30% moins rapide que BIO.

  • AIO (Async IO) ou NIO2

    C’est la deuxième version de NIO, apparue dans le jdk 7. Dans cette version, le système d’exploitation gère le select. NIO2 un peu plus rapide que NIO, de l’ordre de 2 à 3%.

Pour un mode non connecté, il faut utiliser BIO. Pour un mode connecté avec beaucoup de connections, il faut utiliser NIO. Quand à l’API AIO (NIO2), il est préférable de l’éviter car elle apporte un gain minime par rapport à NIO, au prix d’une utilisation importante de la mémoire.

Le framework Apache Mina

Celui-ci constitue une alternative au projet Netty et fournit une API de haut niveau afin de masquer les API bas niveau d’entrées/sorties en Java. Actuellement, l’implémentation est basée sur NIO mais les futures versions permettront de choisir entre BIO, NIO et AIO (NIO2).

L’écriture d’un serveur de type « echo » nécessite seulement 6 lignes de code.

Mina fonctionne suivant 2 protocoles : TCP et UDP.

  • Mode TCP

    Une nouvelle session est créée lors du bind.
    En lecture/écriture, on reçoit/envoit des fragments de message dans le désordre.
  • Mode UDP

    Une nouvelle session est créée lors du premier message d’un client identifié par son adresse IP.
    Ce mode est sans état par défaut mais il est possible de gérer un état.
    En lecture/écriture, on reçoit/envoit un message complet ou rien (mais on ne le sait pas).

Mina est architecturé sur un modèle événementiel :

  • exception capturée
  • message reçu
  • message envoyé : les envois sont mémorisés tant que le client ne lit pas ses messages, ce qui peut conduire à un accroissement de l’utilisation de la mémoire
  • session fermée
  • session créée
  • session inactive : on distingue l’inactivité en lecture, en écriture ou les 2
  • session ouverte

Au niveau paramétrage, Mina permet de rajouter des filtres pour traiter les messages, des encodeurs/décodeurs et de spécifier un Executor.

On trouve des encodeurs/décodeurs pour les messages à taille fixe, avec délimiteur (retour chariot ou autre caractère), les messages avec couples longueur/valeur. Il est possible d’en écrire d’autres en faisant attention qu’ils soient sans état car ils sont partagés entre plusieurs threads. Si on souhaite mémoriser un état, il faut utiliser la session.

Pour terminer, Emmanuel nous indique que le goulot d’étranglement est rarement au niveau du réseau ethernet mais plus souvent au niveau des accès disque (car ceux-ci sont nettement plus lents).

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , , , , ,
Comments: -

Devoxx France 2013 – Architecturer pour la livraison continue

7 mai, 2013 (09:00) | Devoxx France 2013 | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « Architecting for Continuous Delivery » présentée par Axel Fontaine.

Facebook, Flickr et Stack Overflow font plusieurs mises en production par jour et donc du déploiement continu. Remarque : on constate que le numéro de version du site Stack Overflow se trouve en bas de page.

Le déploiement continu ne doit pas se faire à partir d’une version snapshot afin de permettre la reproductibilité. Le cycle est donc : lancer tous les tests, créer une nouvelle version et faire le déploiement dans l’environnement de déploiement continu.
Lorsque le déploiement est manuel, il faut l’automatiser. La version déployée doit contenir le code, les différences entre les bases, ainsi que la configuration de tous les environnements (intégration, recette, production …). La détection de l’environnement doit se faire automatiquement, par l’intermédiaire d’une variable d’environnement, d’un fichier présent dans un endroit précis …

Gestion des modifications de la base de données

Axel conseille de choisir un outil pour gérer les différentes versions d’une base de données ainsi que l’ordre d’execution des scripts :

  • Flyway est un projet libre de migration de base de données. Il enregistre la version de chacun des scripts joués. On peut partir d’une base existante pour générer la première version des scripts.
  • Liquibase est un autre projet libre avec des fonctionnalités similaires.

Gestion des nouvelles fonctionnalités

La bascule de fonctionnalité (en anglais : Feature toggle) permet d’éviter la création de branches (et donc la fusion des branches et la duplication de l’environnement d’intégration continue). Cela se traduit souvent dans le code par un ‘if’, ce qui évite de casser le code existant. L’ancien code sera supprimé plus tard quand tout sera correct en production.

Gestion des serveurs

Pour palier au crash éventuel d’un serveur et maintenir le site web toujours actif, il faut utiliser 2 machines.

Lors d’une mise en production, l’une des machines sert au déploiement de la nouvelle version, toujours connectée sur la même base de données. La compatibilité de l’ancien serveur avec la base de données doit être assurée : au lieu de renommer une colonne, il faut en rajouter une autre ainsi qu’un trigger qui fait la copie de l’ancienne colonne vers la nouvelle. L’ancienne colonne et le trigger seront supprimés plus tard. Pour une application web fonctionnant sous tomcat, l’utilisation d’un cache de session partagé tel que memcached-session-manager permet de conserver les sessions actuellement actives. Chaque machine héberge une instance de tomcat et une instance de memcached. Le passage à la nouvelle version se fait ainsi de manière totalement transparente pour les utilisateurs.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , ,
Comments: -

Devoxx France 2013 – Déminage d’une application avec JRockit Mission Control

2 mai, 2013 (09:00) | Devoxx France 2013, Java | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « Déminage d’une application avec JRockit Mission Control » présentée par François Ostyn.

JRockit Mission Control est un outil pour la JVM JRockit comprenant :

  • une console JMX
  • un enregistreur d’événements se produisant dans la JVM : Flight recorder
  • un analyseur de mémoire pour aider à localiser les fuites mémoire : Memleak analyser

Afin de ne maintenir qu’une seule JVM, Oracle a créé le projet HotRockit dans le but de fusionner JRockit et Hotspot. Ses résultats seront progressivement intégrés dans Hotspot.

Depuis Java SE 7 update 4, Hotspot a les même mesures (metrics) que JRockit, ce qui permet d’utiliser JRockit Mission Control avec Hotspot. Celui-ci peut être utilisé de 2 manières : avec le plugin eclipse ou en ligne de commande.

Grâce au plugin eclipse, Memleak analyser détecte l’accroissement du nombre d’instances d’une classe et permet la visualisation de la pile d’appel. Flight recorder peut récupérer à postériori la liste des événements, ce qui permet de visualiser l’utilisation du tas, du processeur … En mode déconnecté, le plugin permet aussi de voir les fuites mémoire mais pas le graphe d’appel (visible uniquement en mode connecté).

La commande jcmd (appelée jrcmd dans JRockit) permet de faire les même requêtes qu’avec le plugin eclipse. Celle-ci permet aussi de récupérer un fichier .jfr visualisable avec le plugin eclipse.

Pour terminer, il faut noter que JRockit Mission Control est gratuit en développement mais pas en production et, d’après François, il est plus rapide que des outils de profilage tels que Yourkit car les mesures (metrics) sont codées en natif dans la JVM.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , , ,
Comments: -

Devoxx France 2013 – (Reality)-[:IS_A]->(Graph)

30 avril, 2013 (09:00) | Devoxx France 2013, Java | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « (Reality)-[:IS_A]->(Graph) » présentée par Florent Biville.

Intérêt d’une base de données orientée graphe

Internet, les réseaux sociaux, les réseaux de communication et les dépendances d’un projet maven constituent des exemples de graphes dans la réalité. Il existe plein d’algorithmes efficaces de recherche avec une complexité linéaire. Les graphes ont une structure simple : des noeuds reliés par des relations (orientées ou non). Dans une base de données relationnelle, il faut rajouter une table appelée table de jointure alors que ce concept est déjà présent dans un graphe.

Neo4j

Neo4j est une base de données orientée graphe, libre dans sa version community (sources sur github) et utilisant Lucene pour l’indexation. Un noeud est représenté par une liste de paires clé/valeur. Une relation est représentée par une liste de paires clé/valeur, une étiquette et un sens. Toutes les écritures sont transactionnelles (dans Neo4j une transaction a les propriétés ACID).

Pour les recherches, il ne faut pas partir de l’identifiant mais utiliser l’index. En effet, les identifiants de noeuds peuvent être recyclés. Le langage de requêtage de Neo4j se nomme cypher et ressemble à ceci :

    START person=node:Person('name: *')
    WHERE person.firstName = 'james' AND person.age > 35
    RETURN person



L’API par défaut est REST (avec une représentation json) mais il existe une couche scala et java.

En ce qui concerne l’API java, on crée une instance de la classe TraversalDescriptionImpl et, via son interface TraversalDescription, on décrit la requête en précisant la stratégie de parcours du graphe, ainsi que les noeuds recherchés. Ensuite, on lance la requête ainsi définie en précisant un ensemble de noeuds comme points de départ.

D’autre part, cypher-dsl (basé sur Querydsl) fournit un DSL pour exprimer une requête comme celle-ci :

    QPerson person = QPerson.person;
    CypherQueryDSL.start( node( "person", 1, 2, 3 ) )
                .where( person.firstName.eq( "james" ).and( person.age.gt( 35 ) ) )
                .returns( nodes( "person" ) )



Spring Data Neo4j fournit une implémentation de Spring Data permettant de faire des requêtes de type JPA sur une base de données Neo4j.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , ,
Comments: -

Devoxx France 2013 – No(Geo)SQL

25 avril, 2013 (09:00) | Devoxx France 2013, Java | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « No(Geo)SQL » présentée par Nicolas Helleringer.

La modélisation géographique (aussi appelée spatiale) est possible dans les SGBD depuis longtemps mais ne fait toujours pas partie des fonctions de base. Les systèmes d’information géographiques (SIG) fournissent des services basés sur la localisation (en anglais, on dit LBS pour Location Based Services). La représentation du monde physique et le Géomarketing sont des utilisations typiques qui nécessitent un fond de carte associé à des informations spécifiques au système.

Il est difficile de représenter un polygone dans une colonne de SGBD car celui-ci est défini par des points et des vertex, en 2 ou 3 dimensions et souvent de manière dense.

L’OpenGIS Consortium a créé une surcouche complexe pour SQL, spécifiée par plus de 50 normes sur les SIG !

Parmi les plateformes LBS, la plus connue est Google Maps qui fourni une abstraction du format des adresses (l’europe, l’amérique et la ville de tokyo n’utilisent pas les même formats). Celui-ci gère la localisation des adresses, l’affichage des rues, du fond de carte, la prise en compte du navigateur. Il ne reste plus au client qu’à gérer ses données spécifiques sur son propre serveur. Celles-ci sont modélisées en SQL avec une latitude et une longitude. Cela présente des inconvénients, même sur un petit interval, car il faut un index sur la longitude et la latitude, ce qui peut être assez lourd.

Il existe différents algorithmes permettant de rechercher des données géographiques de manière optimale : arbre équilibré (en anglais B-tree), Quadtree (partitionnement d’un espace bidimensionnel), R-tree. En NoSQL, certaines bases de données gèrent les données spatiales : Neo4j (R-tree et Quadtree), mongoDB (B-tree).

Hibernate Search Spatial est une extension Hibernate ajoutant la gestion des données spatiales. L’indexation utilise l’algorithme Quadtree pour répartir l’ensemble des valeurs sur un maillage plus ou moins serré afin d’encadrer rapidement le secteur recherché. Cette extension introduit l’annotation @Spatial, à placer sur une classe (entité), ainsi que les annotations @Longitude et @Latitude à placer sur les champs de l’entité qui définissent un emplacement.

Pour terminer, Nicolas nous parle de la base de données libre GeoNames, qui contient les noms de nombreux lieux dans tous les pays (ville, rue, lac …). Comme exemple d’utilisation, il suggère une application mobile qui utilise la position GPS courante pour trouver un coiffeur à proximité.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , ,
Comments: -

Devoxx France 2013 – Posez vos conventions Java sur le divan de Freud

23 avril, 2013 (09:00) | Devoxx France 2013 | By: fabien

Parmi les quickies de Devoxx France 2013, j’ai assisté à la présentation intitulée « Posez vos conventions Java sur le divan de Freud » présentée par Raphael Brugier.

Freud est un outil d’analyse statique qui permet de forcer l’application de certaines conventions et interdire l’utilisation de certaines librairies ou API.

Dans les projets classiques, ces conventions sont écrites dans un document ou sur un wiki. C’est juste une documentation qui ne force pas réellement son application. Une autre alternative est l’utilisation de Checkstyle mais celui-ci n’est pas toujours facile à adapter aux besoins et surtout l’analyse du code est tardive (après la compilation).

Freud fournit un DSL (langage spécifique au domaine) du code java, utilisable pour des assertions dans les tests JUnit. Son analyse peut se faire à différents niveaux : code source, classe (par l’API reflection), bytecode …

D’autres types de fichier sont également supportés : fichier de propriétés, CSS, texte …

Pour l’utilisation, il faut faire un fork du projet sur github et construire le projet soi-même car il n’existe pas d’artefact maven.

Au niveau des outils d’analyse statique, Freud est plus proche de Checkstyle que de FindBugs car l’analyse poussée est difficile.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , ,
Comments: -

Devoxx France 2013 – De compiletout.bat à l’Usine Logicielle pour Java

18 avril, 2013 (09:00) | Devoxx France 2013 | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « De compiletout.bat à l’Usine Logicielle pour Java » présentée par Guillaume Rams.

Voici quelques outils qui peuvent servir dans le cycle de vie d’un projet :

  • crap4j analyse les risques lors d’un changement du code
  • Sonar / Checkstyle / pmd :
    Au lieu d’utiliser directement pmd et checkstyle, il vaut mieux utiliser Sonar, un outil de collecte générant des rapports sur la qualité d’un logiciel. Il ne fait pas de mesures par lui-même mais délègue cela à des outils spécifiques.

Le terme « Smoke Tests » désigne les tests minimaux qui soient automatisables pour une version déployée. Guillaume conseille de mettre en place ce genre de test, ce qui sera toujours mieux que rien du tout. Pour une application web, cela pourrait se traduire par « afficher la page d’accueil ».

Pour terminer, Guillaume parle de Clinker, un écosystème comprenant une usine logicielle complète pour Java. Il existe en 2 versions : Clinker Cloud pour un hébergement payant dans le cloud et Clinker Virtual Appliance, une machine virtuelle à télécharger gratuitement et à faire tourner dans VMWare ou VirtualBox.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , , , ,
Comments: -

Devoxx France 2013 – Implémenter la qualité sur un projet Java

16 avril, 2013 (09:00) | Devoxx France 2013 | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « Implémenter la qualité sur un projet Java » présentée par Vincent Massol (profil github), contributeur du projet XWiki.

Vincent nous parle des bonnes pratiques dans la gestion d’un projet Java, en prenant comme modèle son expérience sur XWiki.

Stabilité de l’API

Il faut faire attention aux utilisateurs et même aux développeurs du framework.

Clirr est un outil qui casse la construction d’un projet s’il y a un changement dans une API. La comparaison peut se faire au niveau binaire ou au niveau du code source. Lorsque l’on a intentionnellement changé l’API, il faut documenter le changement pour qu’il soit ignoré par l’outil, qui signalera cela dans son rapport.

Voici quelques pratiques mise en place sur le projet XWiki pour la gestion de ses API :

  • Création d’un package ‘internal’ : Les classes/méthodes/attributs présents dans ce paquetage peuvent être visibles au sens Java mais le développeur ne doit pas les utiliser. S’il le fait quand même, il prend le risque que son code ne compile plus ou ne s’execute plus lors d’une nouvelle version de la librairie. Il ne faut pas oublier d’exclure ce paquetage de la javadoc et de l’analyse Clirr.
  • Gestion de la dépréciation dans l’API
    • Version courante : Utiliser l’annotation @Deprecated dans le code et le tag @deprecated dans la javadoc (voir aussi la documentation Oracle sur le sujet).
    • Future version : Déplacer le code déprécié vers des artefacts dont le nom se termine par « -legacy ». Les classes dépréciées sont déplacées. Les méthodes dépréciées sont déplacées en utilisant AspectJ.
  • Gestion d’une nouvelle API : Celle-ci est potentiellement instable. Il faut utiliser l’annotation @Unstable et préciser une limite de validité.

Attention à l’ajout de méthodes dans une interface ! Mais cela ne sera plus un problème à partir du jdk8, qui permet d’ajouter une implémentation par défaut sur une interface.

L’enfer des jars

Il arrive parfois que certaines classes soient dupliquées à l’exécution (même classes dans 2 jars présents dans le classpath). Lorsque les classes sont différentes, cela constitue un véritable problème qui peut être résolu en utilisant les plugins maven suivants :

  • duplicate-finder pour détecter les classes dupliquées.
  • enforcer pour forcer l’application de certaines règles (version du jdk, version des artefacts …).

Tests de couverture

La librairie JaCoCo mesure la couverture des tests et, si la valeur est en dessous d’un certain seuil, la construction du projet échoue.

Attention : Certains tests peuvent être non déterministes et le taux de couverture peut varier d’une exécution à l’autre, sans modification du code. C’est notamment le cas lorsqu’on utilise la classe ConcurrentHashMap avec plusieurs threads. Vincent propose de rajouter un paramètre nommé threshold (voir la discussion sur le projet github de JaCoCo) pour définir une marge de tolérance par rapport au seuil.

Faux positif/négatif

Un faux positif correspond à un test qui passe alors qu’il aurait dû échouer. A l’opposé, un faux négatif correspond à un test qui ne passe pas alors qu’il aurait dû passer. Exemple de faux négatif : crash, lenteur du système. Voici quelques plugins Jenkins qui peuvent servir dans ces situations :

  • Groovy Postbuild : Ce plugin permet de contrôler le résultat d’un build et éventuellement rajouter un badge sur le sommaire du build et/ou l’historique des builds. Dans notre cas, il peut rechercher du texte dans les logs afin de vérifier qu’un test passe réellement.
  • Email-ext : Ce plugin permet d’étendre la fonctionnalité de notification par email. On pourrait, par exemple, annuler l’envoi d’email lorsque le système est lent (mais l’interface web de jenkins continuerait de montrer le problème).
  • Scriptler : Ce plugin permet de centraliser les scripts Groovy d’une instance Jenkins. On peut aussi jouer un script sur tous les jobs jenkins ou sur tous les noeuds/esclaves. Remarque : le plugin gère 2 sites de partage de scripts : jenkins-scripts et scriptlerweb.

Suivi des défauts

Avec le temps, la courbe des défauts ouverts et celle des défauts corrigés tendent à diverger. Pour atténuer cette divergence, le jeudi a été déclaré jour de correction des défauts par les contributeurs du projet XWiki. Afin de diminuer rapidement les défauts ouverts, ceux-ci commencent par fermer les défauts corrigés et les défauts en doublon. Ensuite, ils corrigent ceux qui sont faciles et en requalifient certains en évolution. Pour voir le résultat, consulter le tableau de bord du projet XWiki.

Pour terminer, Vincent souligne qu’il faut paramétrer les outils afin qu’ils fassent échouer un build lorsqu’une mesure est mauvaise. Sans cela (paramétrage pour émettre un simple avertissement), on va avoir tendance à ignorer le message, puis laisser le problème empirer et finalement ne jamais le corriger.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , ,
Comments: -

Devoxx France 2013 – Simplifiez vos tests avec les assertions AssertJ !

9 avril, 2013 (10:00) | Devoxx France 2013 | By: fabien

Parmi les quickies de Devoxx France 2013, j’ai assisté à la présentation intitulée « Simplifiez vos tests avec les assertions AssertJ ! » présentée par Joel Costigliola (compte github).

Joel était contributeur du projet FEST Assertions, dont la prochaine version contiendra moins d’assertions. Pensant qu’il faut au contraire rajouter plus d’assertions, il a fait un fork du projet sous le nom AssertJ.

Les principaux modules d’AssertJ sont :

De plus, un outil en ligne de commande permet de créer des assertions spécifiques au métier de l’utilisateur. Celui-ci s’intègre aux outils existants à l’aide d’un plugin maven et d’un plugin eclipse (prévu pour avril). Du code est généré à partir du code source des classes métier.

Exemple

    Avec la classe suivante :

    public class Person {
        private String name;
    }



    On obtient du code permettant d’écrire l’assertion :

    assertThat(person).hasName("pierre");



En plus du code généré, l’outil crée la javadoc et documente l’implémentation des méthodes.

Bookmark and Share
[del.icio.us] [Digg] [Google] [LinkedIn] [StumbleUpon] [Windows Live] [Yahoo!] [Email] More »
Powered by Bookmarkify™

Tags: , , , , ,
Comments: -

« Older entries

MySQL query error