Johnny Beuve

20 avr 2012

Les six chapeaux de réflexion d’Edward de Bono traduit par Michèle Sauvalle.

Catégorie : Non classé — Johnny Beuve @ 19 h 36 min

C’est une technique qui permet de débattre d’un sujet, en appliquant la pensée parallèle.

Très simple à comprendre.

Très simple à mettre en oeuvre.

Très efficace quand il s’agit d’explorer un sujet en général afin d’aboutir à une prise de décision.

Beaucoup de sociétés (ABB, Siemens, MDS, Connex, Statoil, …) économisent de l’argent grâce à cette méthode.

Pensées parallèles

La pensée occidentale se préoccupe de « ce qui est » que l’on définit par l’analyse, le jugement et l’argumentation.
Cela fonctionne très bien dans un monde stable ou les situations du passé se reproduisent, par exemple quand un médecin diagnostique une rougeole.
C’est notre héritage culturel (Socrate « argumentation », Platon « la vérité se cache sous les apparences », Aristote « Chaque chose que nous rencontrons doit rentrer dans une case »)

La pensée parallèle s’attache à « ce qui peut être » . Exemple : quatre personnes situées aux quatre coins d’une maison ont une vision différente de cette dernière. Plutôt que de confronter ces visions, l’idée est de faire le tour ensemble de la maison et de regarder en parallèle dans la même direction et si les visions sont contradictoires, elles sont mises en parallèles. On ne fera de choix que si cela est nécessaire. On cherche simplement à avancer.

Les six chapeaux

Les chapeaux symbolisent les directions de réflexion.

Chapeau blanc

Neutre et objectif, le chapeau blanc expose les faits, les données, les chiffres et leur source.

Si le fait énoncé n’est pas vérifiable cela est clairement dit.
Si deux informations ne concordent pas on les accepte toutes les deux. On approfondira le sujet seulement si c’est nécessaire.

Les questions à se poser en chapeau blanc :

De quelle information disposons-nous ?
De quelle information avons nous-besoin ?
Quelle information est manquante ?
Quelles questions devons-nous poser ?
Quels sont les moyens envisagés pour obtenir cette information ?

Chapeau souvent utilisé en début de session.

Chapeau rouge

Le chapeau rouge exprime les émotions, les sentiments, les intuitions. Il n’a pas à se justifier auprès des autres chapeaux.
Ce chapeau peut servir au début, pour comprendre les sentiments de chacun ou pour valider, invalider une décision.
Le chapeau rouge, offrant un exutoire aux sentiments, aux émotions, permet à la session d’être moins polluée par les émotions.

Chapeau noir

C’est l’avocat du diable!
Le chapeau noir évoque les risques , les dangers, les obstacles, les problèmes les inconvénients potentiels.
Attention ce chapeau ne doit pas être utilisé pour argumenter. L’argumentation étant interdite.
Le chapeau noir ne peut être utilisé en phase chapeau vert ou jaune car cela casse le rythme et ne permet pas d’approfondir les choses.

Chapeau jaune

C’est le soleil et l’optimisme.
Le chapeau jaune est constructif et positif. Il s’agit de rechercher les opportunités, la valorisation d’une idée.
Cet exercice n’est pas facile, mais n’hésitez pas à consacrer du temps sous ce chapeau car il permet de soulever des opportunités souvent inattendues.

Chapeau vert

C’est la fertilité des plantes, la semence des idées.
Il s’inspire de la pensée latérale, terme inventé par l’auteur et qui fait maintenant partie du dictionnaire anglais. Il s’agit de faire émerger les idées en poussant à changer de point de vue, de paradigme, de schéma de pensée ; en utilisant la provocation et le mouvement. Le chapeau vert sort des sentiers battus et propose des idées neuves.
On remplace le jugement par le mouvement. (Surtout pas de chapeau noir donc).

Chapeau bleu

Organisation, animation de la réflexion. C’est le bleu du ciel qui englobe tout. Le chapeau bleu présente le sujet et la suite des chapeaux à suivre pour traiter le sujet. Il anime la séance.

Règles du jeu

Les chapeaux peuvent être utilisés :

séquentiellement avec un ordre défini par le chapeau bleu. Tout le monde met le même chapeau en même temps. (Un même chapeau peut être utilisé plusieurs fois)
de manière isolé « je voudrais un peu de réflexion en chapeau jaune »
pour animer une séance ou pour une réflexion personnelle.

Recommandations

Notre cerveau ne sait pas se concentrer simultanément dans plusieurs directions.
Il est donc important de garder le chapeau indiqué suffisamment longtemps pour approfondir le sujet.

De manière générale, prenez vraiment le temps de faire le tour des opportunités en chapeau jaune.

Attention les chapeaux ne sont pas des catégories de personnes. Il faut résister à cette tentation.
Le risque est de conforter une personne dans un mode. On perdra la valeur qu’elle pourrait apporter dans un autre mode.

Conclusion

Cette méthode économise du temps.
Les décisions semblent évidentes à prendre.
Suppression des problèmes d’ego (confrontations, argumentations) .
Une seule chose à la fois optimise notre cerveau.

Mots-clefs : Efficacité, livres

Commentaires (0)

13 avr 2012

Requêtes XPath, un jeu d’enfant avec Jaxp13XPathTemplate de Spring

Catégorie : Non classé — Johnny Beuve @ 8 h 33 min

Un exemple autonome de test unitaire pour comprendre comment fonctionne le Template Jaxp13XPathTemplate du framework Spring . Cela sert à ça aussi les tests


public class XpathSimpleTest {

    private String xmlBody = "<root\n" +
            "xmlns:h=\"http://www.w3.org/TR/html4/\"\n" +
            "xmlns:f=\"http://www.w3schools.com/furniture\">\n" +
            "\n" +
            "<h:table>\n" +
            "  <h:tr>\n" +
            "    <h:td>Apples</h:td>\n" +
            "    <h:td>Bananas</h:td>\n" +
            "  </h:tr>\n" +
            "</h:table>\n" +
            "\n" +
            "<f:table>\n" +
            "  <f:name>African Coffee Table</f:name>\n" +
            "  <f:width>80</f:width>\n" +
            "  <f:length>120</f:length>\n" +
            "</f:table>\n" +
            "\n" +
            "</root>";

    @org.junit.Test
    public void exampleXPathTemplate()
            throws javax.xml.parsers.ParserConfigurationException,
            org.xml.sax.SAXException,
            java.io.IOException {

        org.w3c.dom.Document doc = null;

        // string xml en Document
        javax.xml.parsers.DocumentBuilder db;
        javax.xml.parsers.DocumentBuilderFactory
                factory = javax.xml.parsers.DocumentBuilderFactory.newInstance();
        factory.setNamespaceAware(true);
        db = factory.newDocumentBuilder();
        java.io.InputStream
                is = new java.io.ByteArrayInputStream(xmlBody.getBytes());
        doc = db.parse(is);

        // get namespace as Hasmap<localName, URI>
        java.util.HashMap<String, String> namespaces = new java.util.HashMap<String, String>();
        for (int i = 0; i < doc.getDocumentElement().getAttributes().getLength(); i++) {
            String localName = doc.getDocumentElement().getAttributes().item(i).getLocalName();
            String textContent = doc.getDocumentElement().getAttributes().item(i).getTextContent();
            namespaces.put(localName, textContent);
        }

        // Requete Xpath
        javax.xml.transform.dom.DOMSource domSource = new javax.xml.transform.dom.DOMSource(doc);
        org.springframework.xml.xpath.XPathOperations
                template = new org.springframework.xml.xpath.Jaxp13XPathTemplate();
        ((org.springframework.xml.xpath.Jaxp13XPathTemplate) template).setNamespaces(namespaces);
        junit.framework.Assert.assertEquals(" La valeur root/f:table/f:length ",
                "120",
                template.evaluateAsString("root/f:table/f:length", domSource));
        junit.framework.Assert.assertEquals(" Un path  root/f:table/f:pathNexistePas ramène ",
                "",
                template.evaluateAsString("root/f:table/f:pathNexistePas", domSource));
    }
}

Mots-clefs : Java

Commentaires (0)

27 avr 2011

Un petit pas peut changer votre vie. La voie du Kaizen. Robert Maurer

Catégorie : Non classé — Johnny Beuve @ 9 h 57 min

Le Kaizen est une des méthodes principales du Lean et consiste à promouvoir l’amélioration continue à travers de petites actions, de petits objectifs. Cette méthode est utilisée par les entreprises Japonaises.

Robert Maurer, psychologue de formation, applique cette méthode avec ses patients et non plus à l’entreprise. Son livre aborde cette méthode avec ces deux visions entreprise/psychologie.

Je vous propose un résumé mindmap :

Introduction :

Pourquoi le Kaizen marche :

Poser de petites questions pour remodeler votre cerveaux :

Ayez des petites pensées :

Faites des petites actions :

Résolvez de petits problèmes :

Accordez de petites récompenses :

Identifiez les petits moments :

Vue globale :

Lien sur pdf.

Mots-clefs : Efficacité, livres

Commentaires (0)

23 jan 2011

Séparer tests unitaires et tests d’intégrations

Catégorie : Non classé — Johnny Beuve @ 21 h 05 min

Des tests automatiques soignés, c’est très bien et je ne peux que vous encourager à continuer.
Des tests unitaires et des tests d’intégrations séparés c’est encore mieux. Mais comment faire?

1. Profils Maven

On peut jouer avec les profils maven. L’idée est d’exclure les tests d’intégrations en temps normal et de créer un profil maven juste pour les tests d’intégrations. L’exclusion peut se faire avec les noms des packages ou un suffixe de nom de classe. Ici un exemple de config avec le plugin de surefire et JUnit :

Build normal, on exclut les tests unitaires (mvn install) :



<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.4.3</version>
                <configuration>
                    <skip>true</skip>
                </configuration>
                <executions>
                    <execution>
                        <id>surefire-test</id>
                        <phase>test</phase>
                        <goals>
                            <goal>test</goal>
                        </goals>
                        <configuration>
                            <skip>false</skip>
                            <excludes>
                                <exclude>**/integrationtest/**</exclude>
                            </excludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Build avec les tests d’intégrations (mvn install -Pintegrationtest)



<profiles>
        <profile>
            <id>integrationtest</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.4.3</version>
                        <configuration>
                            <skip>true</skip>
                        </configuration>
                        <executions>
                            <execution>
                                <id>surefire-itest</id>
                                <phase>integration-test</phase>
                                <goals>
                                    <goal>test</goal>
                                </goals>
                                <configuration>
                                    <skip>false</skip>
                                    <includes>
                                        <include>**/integrationtest/**</include>
                                    </includes>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

Une alternative consiste à faire une « test suite » et à la mettre dans la liste d’inclusion. Ainsi on maîtrise exactement qu’elles classes sont exécutées lors des tests.



         <configuration>
          <includes>
            <include>**/*TestSuite.java</include>
          </includes>
          <systemProperties>
            <property>
              <name>monapplication.db.target</name>
              <value>${monapplication.db.target}</value>
            </property>
          </systemProperties>
        </configuration>

2. TestNG

Avec TestNG il suffit d’annoter la class @Test(groups = « integration ») et de mettre les groupes dans la config Surefire ou FailSafe de maven. L’avantage c’est qu’il est relativement aisé de classer ses Tests. Ici un exemple avec TestNg et le plugin surefire :

Code java :



package org.jo.testit;

import org.junit.Assert;
import org.testng.annotations.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Created by IntelliJ IDEA.
 */
@Test
public class CalculatorNgTest {
    static Logger logger = LoggerFactory.getLogger(CalculatorNgTest.class);

    //@Test(groups = "unittest,integrationtest", suiteName = "suite1" )
    @Test(groups = "unittest,integrationtest")
    public void testAdd() {
        logger.debug("RUNNING Test NG UNIT test!");
        Assert.assertEquals("30", 30, Calculator.add(10, 20));
        // TODO Pourquoi ce test n'est pas lancé quand on fait mvn install -Pintegrationtest
    }
}

Au niveau du plugin surefire :



                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.4.3</version>
                        <configuration>
                            <groups>integrationtest</groups>
                        </configuration>
                    </plugin>

3. Plugin FailSafe

Le plugin FailSafe permet de simplifier la config. Surtout il fait le post-integrationtest même si les tests d’intégrations plantent, ce que ne fait pas Surefire. L’idée est donc d’utiliser Surefire pour les tests unitaires et FailSafe pour les tests d’intégrations en attachant l’exécution à la phase integration-test par exemple. Attention, par convention le plugin FailSafe exécute les tests src/test/java/<above packages>/*IT.java. Si par hasard vos tests ne respectaient pas cette règle de nommage il faut les inclure explicitement. Ici un exemple de config :



          <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>2.7.1</version>
                <configuration>
                    <groups>integrationtest</groups>
                    <includes>
                        <include>**/*Test.java</include>
                    </includes>
                </configuration>
                <executions>
                    <execution>
                        <id>integration-test</id>
                        <phase>integration-test</phase>
                        <goals>
                            <goal>integration-test</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>verify</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

4. @IfProfileValue de spring

Si vous faites du Spring l’annotation @IfProfileValue(name= »nom-de-la-variable », value= »valeur ») permet de lancer le test que si la variable d’environnement est valide. Pour qu’ils soient exécutés, il suffit de les lancer avec -Dnom-de-la-variable=valeur. Si on utilise maven il faudra spécifier une variable système. Exemple ici :

Code java :



package org.jo.testit;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.test.annotation.IfProfileValue;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

/**
 */
@ContextConfiguration(locations = {"/META-INF/spring/config.xml"})
@RunWith(SpringJUnit4ClassRunner.class)
public class CalculatorTest {
    static Logger logger = LoggerFactory.getLogger(CalculatorTest.class);

    @Test
    @IfProfileValue(name = "group-unittest", value = "true")
    public void testAdd() {
        logger.debug("RUNNING UNIT test!");

        Assert.assertEquals("30", 30, Calculator.add(10, 20));
    }
}

Config maven :



                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.4.3</version>
                        <configuration>
                            <skip>true</skip>
                        </configuration>
                        <executions>
                            <execution>
                                <id>surefire-itest</id>
                                <phase>integration-test</phase>
                                <goals>
                                    <goal>test</goal>
                                </goals>
                                <configuration>
                                    <skip>false</skip>
                                    <systemProperties>
                                        <property>
                                            <name>group-unittest</name>
                                            <value>true</value>
                                        </property>
                                        <property>
                                            <name>group-integrationtest</name>
                                            <value>true</value>
                                        </property>
                                    </systemProperties>
                                </configuration>

Il existe sûrement d’autres manières de procéder. A vous de choisir selon les besoins et le contexte du projet. Vous trouvez pour chacun des points abordés ici un exemple dans un projet maven dans ce Zip.

Nous n’avons pas parler des tests fonctionnels, peut-être dans un autre article

Mots-clefs : Java, Spring, Tests

Commentaires (0)

06 août 2010

Technique de recueil des besoins

Catégorie : Non classé — Johnny Beuve @ 20 h 29 min

J’aimerais vous faire partager une technique de recueil de besoins que j’ai découverte dans un livre écrit par Véronique Messager Rota : « Gestion de projet vers les méthodes agiles ». La technique des neuf cases de Solution Selling (http://www.spisales.com)

La technique est très simple et consiste à passer par trois étapes :

quel est le problème,
quel est l’impact,
visualiser la solution

Pour chacune des étapes, suivez le shéma suivant :

Questions ouvertes : Dites moi! Racontez moi! et puis?
Contrôle : Combien? Quand? Où?
Validation par re-formulation : « Si je comprends bien… » La re-formulation permet de faire savoir au client ce que vous avez compris. Clef pour éviter des incompréhensions.

Le compte y est 3 X 3 = 9 cases.

Ne partez pas sur la solution directement vous perdrez le contexte et louperez parfois des opportunités de rendre service simplement et durablement. Insistez pour reprendre dès le début le problème. Souvent on pense savoir et le client pense connaître la solution.

Laissez parler le client, prenez tout votre temps. Tous les détails sont intéressants. Parfois vos questions permettront de réévaluer l’importance du problème. En posant des questions on relativise le degré d’urgence.

Parfois le client n’a pas d’idée claire sur la solution. On peut essayer de changer de point de vue en jouant un rôle. (Si vous étiez responsable de la livraison, qu’est ce que vous feriez…)

Mots-clefs : Efficacité, PM

Commentaires (0)

22 mar 2010

Connaissez vous la tactique du pomodoro?

Catégorie : Non classé — Johnny Beuve @ 14 h 00 min

Pomodoro signifie tomate en Italien et fait référence au minuteur en forme de tomate que l’on trouve souvent dans les cuisines.

La technique consiste à :

lister les tâches de la journée puis rassemblez les dans des lots de 25 minutes
pour chaque itération :
- travailler sans interruption avec une concentration maximale pendant une durée de temps toujours fixe (25 mn).
- s’accorder 5 minutes de pause, histoire de réveiller un peu notre cerveau intuitif.
- faire une pause toutes les 2h environ.
à la fin de la journée, faites le point et commencez à planifier la journée suivante, la soirée n’en sera que plus légère.

Pour plus de détails sur cette technique vous pouvez aller sur le site http://www.pomodoro-book.com/.

Si vous n’avez pas de pomodoro, allez sur cette URL : http://timberfrog.com/countdown/?l=fr

La tactique de cette technique est de nous forcer à utiliser un peu notre cerveau droit qui, très généreusement, nous donne souvent une solution géniale à notre problème du moment. Si cela vous intéresse je vous encourage à lire ce livre merveilleux « Pragmatic Thinking & Learning », Andy Hunt donne des pistes pour utiliser nos cerveaux plus judicieusement. (Dans le livre il parle de R-Mode (right rich) et L-mode (left linear)).

Quelques conseils :

pour protéger vos pomodoros :
- faites part de votre mode de fonctionnement à vos collègues,
- notez simplement lorsque quelqu’un vous interrompt, la tâche à faire mais ne faites la tâche qu’après la fin du pomodoro.
- si vous avez trop de tâches à faire lors de vos pauses rallongez le temps de pause pour laisser le cerveau respirer, ou bien faites un pomodoro avec toutes ces tâches. (Laissez votre cerveau respirer)
Si votre tâche est finie, restez concentré sur la tâche en cours jusqu’à la fin des 25 minutes.

Cette technique est un cadeau du ciel pour se débarrasser des tâches barbantes.

Personnellement je couple cette technique avec une autre technique, la GTD (Getting Thinks Done), cela me permet de désencombrer mes petits cerveaux.

Piste : j’ai tendance à utiliser cette technique en pair programming, mais je ne suis pas entièrement confortable et sûr que changer toutes les 25 minutes de rôle soit une bonne approche. Je suis convaincu par des cycles de concentration court de 20-30 minutes (peut-être même plus), du bien fondé des pauses, mais en pair programing il faut peut être laisser plus de liberté pour additionner les richesses des deux cerveaux sur l’histoire que l’on est en train de raconter.

Mots-clefs : Efficacité

Commentaires (0)

22 mar 2010

Clean Code: A Handbook of Agile Software Craftsmanship

Catégorie : Non classé — Johnny Beuve @ 11 h 32 min

Ce livre décrit les bonnes techniques de programmation, ou plus exactement, décrit comment raconter des histoires faciles à lire et à modifier. Tout professionnel dans le domaine du développement software devrait lire un livre de ce genre.

Vous trouverez une fiche de lecture de ce livre sous forme de mind map. Vous pourrez télécharger une version PDF de cette fiche.

Je recommande chaudement ce livre. Ne le prêtez pas vous ne le reverrez plus. Attention, bien que les principes soient applicables à tous langages Clean Code est résolument Java. Aussi l’auteur donne rarement de références. (Vous pourrez trouver ce genre de références dans ce livre : Code Complete http://cc2e.com/).

PDF (Vous pouvez aussi cliquer sur l’image.)

Heuristiques :
PDF(Vous pouvez aussi cliquer sur l’image.)

Mots-clefs : livres

Commentaires (2)

10 mar 2010

Mise en place de JMX avec Spring

Catégorie : Non classé — Johnny Beuve @ 22 h 25 min

JMX (Java Management eXtension) permet de superviser et d’administrer les ressources logiciels s’exécutant sur une JVM locale ou distante. Cette approche permet donc d’inspecter l’état d’une application en production, de modifier son comportement, de notifier des évènements sans avoir une interruption de service.

La plupart des serveurs d’applications java incluent JMX. (JBoss, Websphère, Weblogic).

Cet article décrit rapidement JMX et propose un exemple très simple avec et sans le framework Spring.

JMX est composé de trois couches :

La couche instrumentation définit les ressources qui vont être monitorées. Ces ressources sont des MBeans qui ressemblent à de simples POJOs.
La couche agent qui permet le déploiement des MBeans, les notifications et le monitoring. Toutes communications avec les ressources monitorées passent donc par cette couche. Le composant principal de cette couche est le MBeanServeur qui enregistre notamment les MBeans.
La couche Remote Management gère les communications externes avec les agents au travers des adapteurs et des connecteurs. Les adapteurs permettent à un client de communiquer avec un MBeanServeur selon un protocole donné.

Quelles sont les étapes pour enregistrer un MBean

Il faut créer une interface dont le nom finit par MBean. Par exemple InstrumentMBean
Implémenter cette interface dans une classe dont le nom est celui de l’interface mais sans MBean à la fin. Par exemple Instrument. Attention la classe implémentant l’interface du MBean doit se trouver dans le même package, et avoir un constructeur sans paramètre.
Ensuite il suffit d’enregistrer cet MBean dans un MBeanServeur.
- Instancier le MBean
- Obtenir une référence de MBeanServer
- Construire un ObjectName (Un ObjectName est composé de deux parties, le domaine et une paire (nom,valeur) séparée par des : , cela donne : mon.domaine:type=MonMBeanAMoi)
- Enregistrer le Mbean dans le MBeanServer en utilisant l’ObjectName unique que vous avez créé.

Votre MBean est enregistré, vous pouvez maintenant le consulter en utilisant la jconsole.

Faisons un exemple :

Interface :


package tuto.jmx;

public interface InstrumentMBean {
	public boolean isRunning();
	public void setRunning(boolean running);
	public void start();
	public void stop();
}

Implémentation :


package tuto.jmx;

public class Instrument implements InstrumentMBean {
	boolean running = false;

	@Override
	public boolean isRunning() {
		return running;
	}

	@Override
	public void setRunning(boolean running) {
		this.running = running;
	}

	@Override
	public void start() {
		running = true;
	}

	@Override
	public void stop() {
		running = false;
	}
}

Agent :


package tuto.jmx;

import java.lang.management.ManagementFactory;
import javax.management.MBeanServer;
import javax.management.ObjectName;

public class AgentMain {
	public static void main(String[] args) {
		Instrument instrument = new Instrument();
		MBeanServer ms = ManagementFactory.getPlatformMBeanServer();

		try {
			ObjectName oa = new ObjectName("mon.domaine:type=MonInstrument");
			ms.registerMBean(instrument, oa);
			System.out.println("Agent Running...");
			Thread.sleep(60000l);
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

Lancer le main et lancer simplement la jconsole (attention si vous utilisez java5, il faut lancer le main avec les paramètres suivants pour pouvoir se connecter en remote avec la jconsole « -Dcom.sun.management.jmxremote »)

On se connecte :

on regarde les mbeans :

Comment faire avec Spring :

Il faut juste créer un MBean. Par exemple ObservationBean
Il faut déclarer cet MBean dans le document de configuration de Spring

Voilà c’est suffisant vous pouvez maintenant lancer votre application Spring et consulter via la JConsole le MBean

Faisons un exemple :

Création du MBean :


package org.jo.dto;

import org.springframework.jmx.export.annotation.ManagedAttribute;
import org.springframework.jmx.export.annotation.ManagedResource;

/**
 * MBean dispayed in JMX console.
 */
@ManagedResource
public class ObservationBean {
	private Integer nbrEvent = 0;
	private Integer nbrBoundaryEvent = 10;

	public ObservationBean() {
		super();
	}

	public ObservationBean(Integer nbrEvent, Integer nbrBoundaryEvent) {
		super();
		setNbrBoundaryEvent(nbrBoundaryEvent);
		setNbrEvent(nbrEvent);
	}

	@ManagedAttribute
	public Integer getNbrEvent() {
		return nbrEvent;
	}

	public void setNbrEvent(Integer nbrEvent) {
		this.nbrEvent = nbrEvent;
	}

	@ManagedAttribute
	public Integer getNbrBoundaryEvent() {
		return nbrBoundaryEvent;
	}

	@ManagedAttribute
	public void setNbrBoundaryEvent(Integer nbrBoundaryEvent) {
		this.nbrBoundaryEvent = nbrBoundaryEvent;
	}

	@ManagedAttribute
	public boolean isOk() {
		return nbrEvent < nbrBoundaryEvent;
	}

	@Override
	public String toString() {
		return "System is " + (isOk()? "OK ": "HS ") + "(" + getNbrEvent()
				+ " event(s) for a limit of " + getNbrBoundaryEvent() + ")";
	}
}

@ManagedResource : cette annotation déclare le Bean comme MBean.
@ManagedAttribute : spécifie les attributs accessibles par les clients JMX.

Le document de configuration Spring est très simple :


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

	<context:annotation-config />
	<context:mbean-export />

	<bean class="org.jo.jmx.ObservationEntry">
		<constructor-arg ref="observation" />
	</bean>

	<!-- Observation under jmx -->
	<bean id="observation" class="org.jo.dto.ObservationBean">
	</bean>

</beans>

Pour activer les annotations :

<context:annotation-config />

Pour exporter les MBeans Standards et des @ManagedResource

<context:mbean-export />

Conclusion

JMX est facile à mettre en place (encore plus facile avec Spring). Le champ d’application est large. On peut imaginer par exemple un MBean qui permet de faire fonctionner votre application en mode dégradé. Un autre MBean qui donne la possibilité de recharger les propriétés de votre application. Un MBean qui vous donne une vue générale de l’état des ressources dont a besoin votre application pour fonctionner normalement. Les administrateurs des serveurs d’applications seront enchantés.

Download

Vous trouverez ici un projet qui reprend les exemples de cet article. C’est un projet Maven2.

Mots-clefs : Java, JMX, Spring

Commentaires (0)

10 mar 2010

Savez vous autoboxer à la mode de chez nous

Catégorie : Non classé — Johnny Beuve @ 15 h 25 min

L’autoboxing permet de transformer automatiquement une variable de type primitif en un objet du type du wrapper correspondant. L’unboxing est l’opération inverse. Cela permet par exemple de faire la chose suivante


Integer i = 100;
Integer x = 100;

if (i == x) {
System.out.println("(i = 100) == (x = 100)");
}

Ce qui donne :

(i = 100) == (x = 100)

Ce n’est donc pas l’adresse mémoire des deux Integers qui est comparée. Les Objets Integers x et i sont transformés en primitives, la valeur de ces primitives est ensuite comparée.

Regardons l’exemple suivant :


Integer i = 10000;
Integer x = 10000;

if (i != x) {
System.out.println("(i = 10000) != (x = 10000)");
}
if (i == x) {
System.out.println("(i = 10000) == (x = 10000)");
}

Ce qui donne :

(i = 10000) != (x = 10000)

Comment cela est il possible?

Utiliser l’opérateur == avec des Wrappers est valide sur des Booleans, Bytes, Characters de \u0000 à \u007f (127 en décimal), Shorts et Integers de -128 à 127. Il y a donc cette limite (-128..127) à respecter ce qui rend l’utilisation de l’opérateur == sur des wrappers risquée.

Mais regardons encore un peu plus en détail cet exemple


Integer i = 10000;
int x = 10000;

if (i != x) {
  System.out.println("(i = 10000) != (x = 10000)");
}
if (i == x) {
  System.out.println("(i = 10000) == (x = 10000)");
}

Ce qui donne :

(i = 10000) == (x = 10000)

On constate que lorsqu’un des opérandes est une primitive l’unboxing est réalisé.

Résumons :

L’opérateur == avec des Wrappers est valide sur des :
- Booleans,
- Bytes,
- Characters de \u0000 à \u007f (127 en décimal),
- Shorts et Integers de -128 à 127.
Lorsqu’un des opérandes est une primitive la comparaison est correctement réalisée.

Mais rien ne vaut un test unitaire pour illustrer ce comportement :


/*
* Unit Test on == operator with wrapper
*/
package wrappers.brouillon;
import org.junit.Test;
import static org.junit.Assert.*;

/**
*
* @author jo
*/
public class AutoBoxingAlaModeTest {

public AutoBoxingAlaModeTest() {
}

public boolean doEqualsWithWrappers(Integer i, Integer x) {
    if (i == x) {
      return true;
    }
    return false;
  }

public boolean doEqualsWithWrapperAndPrimitive(Integer i, int x) {
    if (i == x) {
      return true;
    }
    return false;
  }

@Test
public void equalOperatorOnWrappers() {
  Integer int1000IObject = 1000;
  Integer int1000XObject = 1000;
  Integer int1000XPrimitif = 1000;

  Integer int100IObject = 100;
  Integer int100XObject = 100;

  assertEquals("Deux Integers avec les mêmes valeurs comprises entre -127 et 128  sont ==",
    true, doEqualsWithWrappers(int100IObject, int100XObject));
  assertEquals("Deux Integers avec les mêmes valeurs non comprises entre -127 et 128 sont !=",
    false, doEqualsWithWrappers(int1000IObject, int1000XObject));
  assertEquals("Un Integer et une primitive avec les mêmes valeurs non comprises entre -127 et 128  sont ==",
    true, doEqualsWithWrapperAndPrimitive(int1000IObject, int1000XPrimitif));
  }
}

Mots-clefs : Java

Commentaires fermés

09 mar 2010

Fiche de lecture : Comment développer son leadership

Catégorie : Non classé — Johnny Beuve @ 10 h 32 min

« Comment développer son leadership » Auteur Ken Blanchard, Mark Miller.

S Signalez l’avenir

E Engagez les personnes et faites-les grandir

R Réinventez sans cesse

V Valorisez les résultats et les relations

I Incarnez les valeurs

R Réfléchissez toujours

Mots-clefs : Efficacité, Leadership, livres, Management

Commentaires (0)