Le blog de Fabien DUMINY

Un blog utilisant WordPress

Skip to: Content | Sidebar | Footer

Suivez #JNode sur twitter

12 décembre, 2013 (21:35) | JNode | By: fabien

JNode, le système d’exploitation libre développé en Java, a maintenant son compte twitter. Suivez #JNode !

JNode sur GitHub !

12 décembre, 2013 (21:17) | JNode | By: fabien

GitHub est maintenant le dépôt principal pour les sources de JNode : https://github.com/jnode. Nous utilisons maintenant le gestionnaire de bug de GitHub.

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

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

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.

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.

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.

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

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.

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.

MySQL query error