Jérôme Truffot

Astuce JSF : Expression Language et appel à fonctions

Léon — Fri, 05 Sep 2008 10:05:00 +0200

Là encore, je suis loin d'avoir l'expérience suffisante pour me décréter expert en JSF. Mais comme j'en fait au boulot, je partage cette astuce pour concaténer deux strings, et plus généralement pour appeler des fonctions depuis JSF. Rien de génial, c'est plutôt de la bidouille mais dans certains cas, ça peut être pratique.

Je vais commencer par une petite présentation rapide de JSF en citant l'article wikipédia : Java Server Faces (abrégé en JSF) est un framework Java basé sur les composants, pour le développement d'applications Web , et fait partie du standard Java EE. Il suit la méthode de conception Modèle-Vue-Contrôleur. Ce que j'appellerai simplement JSF dans la suite de ce billet est la vue. C'est un assemblage de composants (appelés "tags") qui font appel à un ou plusieurs contrôleurs (instance d'une classe Java) pour récupérer des données et les mettre en page. Les contrôleurs font le lien entre les vues et la logique métier (partie Modèle) qui récupère et/ou "calcule" les données.

Voilà pour le principe. En pratique, on peut avoir besoin de faire des opérations très basiques dans la vue. Pour récupérer les données dans la vue via les contrôleurs, et faire ce opérations basiques, JSF utilise les Expressions Languages (EL). Elles supportent l'appel aux getters des contrôleurs ainsi qu'aux méthodes de type isQuelqueChose qui renvoient un booléen (pour les tests). Elles supportent également les opérateurs arithmétiques pour les types numériques ainsi que les opérateurs relationnels et logiques pour les types numériques, les booléens et les Strings.

Ainsi, la première limitation est de ne pas pouvoir appeler les méthodes qu'on souhaite. Si vous avez un objet (bean) et que vous voulez appeler la méthode toto, vous écrivez bean.toto (remarquer l'absence de parenthèse, on ne peut pas passer d'arguments !). Et bien à l'exécution, les EL vont chercher à appeler la méthode getToto() et non toto()...

Cependant, on peut utilisé des objets de type Map (beans mappés). Par exemple, on peut récupérer la map toto, attribut du contrôleur, via son getter, puis récupérer la valeur correspondante dans cette map à la clé tete (vous avez compris que je cherche à récupérer la valeur de la tête à Toto ! :D). Pour cela, on écrit controleur.toto["tete"]. Si j'avais voulu faire la même chose par une méthode toto qui prend un String comme argument, j'aurais écrit controleur.toto("tete")... La différence n'est pas énorme ;-).

Finalement, mettre des crochets à la place de parenthèses, ça n'a pas l'air si choquant... Enfin, il faut tout de même se dire que dans une utilisation "normal", la map toto contiendra toutes les valeurs susceptibles d'être passer en argument. Ce n'est donc pas vraiment une vrai fonction. Si on ne s'intéresse qu'à une partie de l'anatomie de Toto, ça va. Si ma méthode toto se charge de concaténer un String au String passé en argument, il faut stocker tous les Strings possibles et imaginables ?! Bref, on ne va pas faire ça !

L'astuce (appelée également bidouille ;-)), que je propose, consiste à utiliser une "fausse" map. On va se fabriquer une map qui ne stocke aucune information et dont la méthode get fera le "calcul" qu'on souhaite. Pour cela, on va utiliser la classe AbstractMap du package standard java.util.

private Map<String, String> toto =
	new AbstractMap<String, String>() {
		@Override
		public Set<Entry<String, String>> entrySet() {
			return null;
		}

		@Override
		public String get(final Object arg0) {
			return "PREFIX" + arg0.toString();
		}
	};

Tout ça pour ça... Si c'est pas malheureux...

Comparateurs génériques en Java

Léon — Thu, 04 Sep 2008 16:13:00 +0200

Il n'y a rien de plus énervant que d'écrire plusieurs fois la même chose. Et rien ne ressemble plus à un comparateur qu'un autre comparateur. Par exemple, trier des personnes suivant leur nom, leur âge, la couleur de leurs cheveux ou la taille de leur forte poitrine (spéciale dédicace à Elie Semoun ;-)), c'est un peu la même chose. Sans être un grand spécialiste du Java, je me suis intéressé aux génériques pour simplifier l'écriture de mes comparateurs.

Le problème est le suivant : on veut comparer deux instances de la classe T (pour un tri par exemple) en comparant un de leurs attributs de classe E. On va écrire un comparateur générique pour mutualiser un maximum de chose. Évidemment, nos "vrais" comparateur en hériteront.

Notre comparateur générique implémente logiquement l'interface Comparator<T>. Pour cela, il implémente la méthode compare qui compare deux objets de classe T. L'idée générique est de comparer un attribut particulier (le même sur les deux objets) de classe E en utilisant un comparateur de E particulier. Deux problèmes se posent alors à nous.

Comment récupérer l'attribut sur lequel porte la comparaison ? La méthode qui récupère l'attribut qui nous intéresse est forcément spécifique à la classe T et à l'attribut. Pour se mettre d'accord sur la méthode qui renvoi l'attribut, le mieux serait d'imposer le nom de la méthode en héritant d'une interface. Cette méthode serait implémentée dans les "vrais" comparateurs. Là, comme le constructeur générique implémente déjà certaine méthode, il me semble que le mieux est de faire une méthode abstraite valueOf (ce qui doit être sensiblement la même chose qu'une interface...).

/**
 * @param obj
 * @return comparative value of the object
 */
abstract E valueOf(final T obj);

D'où sort ce comparateur de E ? L'idéal aurait certainement été de pouvoir passer la classe de ce comparateur en tant que paramètre de notre comparateur générique. Malheureusement, je n'ai pas réussi un tel exploit. Les voix des générics java sont impénétrables ;-). La solution que je propose, c'est simplement de passer l'instance du comparateur de E au constructeur de notre comparateur générique.

/** * Intermediate comparator.
 */
private Comparator<E> comparator;

/**
 * Constructor.
 * @param c intermediate comparator
 */
public AbstractComparator(final Comparator<E> c) {
   comparator = c;
}

On a maintenant tout ce qu'il nous faut pour implémenter la méthode compare de l'interface Comparator<T>.

public int compare(final T o1, final T o2) {
   return comparator.compare(valueOf(o1), valueOf(o2));
}

Bien, ça semble déjà pas mal. Il manque tout de même un petit truc. Ce genre de comparateur, ça ne change pas beaucoup au cours de l'exécution. Ce serait dommage de créer une multitude d'instances d'un même comparateur. Bref, on va faire l'effort de mettre en place un beau design pattern Singleton ! :D

Pour cela, on commence par passer le constructeur en protected. Ensuite, les comparateurs implémenteront une méthode de classe (static) getInstance. Cette méthode crée l'instance du comparateur si elle n'existe pas encore et la retourne. Rien que du classique... Trop classique même ! On ne va pas s'embêter à récrire tout ça à chaque fois ? Allez hop ! On va mutualiser le code dans le comparateur générique.

L'idée est la suivante. Dans mon "vrai" comparateur, la méthode getInstance va appeler la méthode getInstance du comparateur générique dont il hérite avec en paramètre, le nom de sa classe (histoire que le comparateur générique s'y retrouve ;-). N'oubliez pas que du coup, le comparateur générique stocke toutes les instances de tous les comparateurs qui en dérivent !! Et pour les stocker, on va utiliser une simple map avec comme clé, la class des comparateurs. Cette map est forcément un attribut de classe.

private static Map<Class, Comparator> comparators;

Ensuite, la méthode getInstance, méthode de classe également, prend une classe en paramètre et renvoi le comparateur correspondant. Cette méthode de classe est donc forcément générique, et son paramètre U implémente l'interface Comparator. Comme c'est la classe (et non une instance) qui est passée en argument, on va utiliser la méthode newInstance pour construire l'instance. En cas de problème, cette méthode lance des exceptions de type InstantiationException ou IllegalAccessException.

protected static <U extends Comparator> U getInstance(final Class<U> c)    throws InstantiationException, IllegalAccessException {
    if (comparators == null) {
        comparators = new HashMap<Class, Comparator>();
    }
    if (!comparators.containsKey(c)) {
        comparators.put(c, c.newInstance());
    }
    return (U) comparators.get(c);
}

Voilà notre super comparateur générique !

public abstract class AbstractComparator<T, E> implements Comparator<T> {    /**
     * comparators.
     */
    @SuppressWarnings("unchecked")
    private static Map<Class, Comparator> comparators;
    
    /**
     * Intermediate comparator.
     */
    private Comparator<E> comparator;
    
    /**
     * Bean constructor.
     * @param c comparator
     */
    protected AbstractComparator(final Comparator<E> c) {
        comparator = c;
    }
    
    /**
     * @param <U> generic parameter of the class
     * @param c class of the researched comparator
     * @return the researched comparator
     * @throws InstantiationException
     * @throws IllegalAccessException 
     */
    @SuppressWarnings("unchecked")
    protected static <U extends Comparator> U getInstance(final Class<U> c)
        throws InstantiationException, IllegalAccessException {
        if (comparators == null) {
            comparators = new HashMap<Class, Comparator>();
        }
        if (!comparators.containsKey(c)) {
            comparators.put(c, c.newInstance());
        }
        return (U) comparators.get(c);
    }

    /**
     * @param o1
     * @param o2
     * @return comparison between a1 and o2
     * @see java.util.Comparator#compare(java.lang.Object, java.lang.Object)
     */
    public int compare(final T o1, final T o2) {
        return comparator.compare(valueOf(o1), valueOf(o2));
    }
    
    /**
     * @param obj
     * @return comparative value of the object
     */
    abstract E valueOf(final T obj);

}

Passons à l'implémentation d'un comparateur ABComparator héritant de ce comparateur générique. Je dispose des ingrédients suivants. Une classe A possède un attribut value de type B sur lequel repose la comparaison. Elle possède également une méthode getValue qui permet de récupérer cet attribut. Enfin, je dispose d'un comparateur de B appelé BComparator.

public class ABComparator extends AbstractComparator<A, B> {    
    /**
     * Constructor.
     * @throws IllegalAccessException
     * @throws InstantiationException
     */
    protected ABComparator() throws InstantiationException, IllegalAccessException {
        super(getInstance(BComparator.class));
    }

    /**
     * @see org.esupportail.ca.domain.beans.comparators.AbstractComparator#valueOf(java.lang.Object)
     */
    @Override
    public B valueOf(final A a) {
        if (a == null) {
            return null;
        }
        return a.getValue();
    }

    /**
     * @return the ABComparator instance
     * @throws InstantiationException
     * @throws IllegalAccessException
     */
    public static ABComparator getInstance() throws InstantiationException, IllegalAccessException {
        return getInstance(ABComparator.class);
    }
}

Simple et rapide à écrire ! Maintenant, les comparateurs, ça dépote ! :D Enfin presque... Encore faut-il avoir le comparateur de B sous la main. Par exemple, si B est String ou un type de base, il faut écrire les comparateurs correspondants...

Le pire, c'est que la plupart de ces types de base implémente l'interface Comparable. C'est-à-dire qu'il possède une méthode compareTo pour comparer une instance à une autre passée en argument. Du coup, on se retrouve à récrire pour toutes ces classes la même méthode compare qui teste si la première instance est nulle, et si elle ne l'est pas, elle retourne le résultat de la méthode compareTo appliquée à cette instance. Bref, c'est laborieux. Simplifions nous la vie avec les génériques !! :D

On va donc écrire un comparateur générique pour les classes implémentant l'interface Comparable.

public class ComparableComparator<T extends Comparable<T>> implements Comparator<T> {    /**
     * Constructor.
     */
    public ComparableComparator() {
        super();
    }

    /**
     * @param o1 first object to compare
     * @param o2 second object to compare
     * @return comparison result
     * @see java.util.Comparator#compare(java.lang.Object, java.lang.Object)
     */
    public int compare(final T o1, final T o2) {
        if (o1 == null) {
            if (o2 == null) {
                return 0;
            }
            return -1;
        }
        return o1.compareTo(o2);
    }
}

Parfait, maintenant je peux initialiser par exemple mon comparateur de String : new ComparableComparator<String>(). Super, mais il se repose le problème de l'unicité de l'instance pour ces comparateurs. "Singleton, singleton, singleton !" hurlent mes compagnons ! Sous la pression populaire, je m'exécute ! :D

Vous avez compris le coup de la map pour stocker les instances. Le problème avec les génériques en Java, c'est qu'on ne peut pas instancier une classe générique comme tout à l'heure avec le newInstance (ou alors je ne sais pas faire ;-)). Par exemple, je ne peux écrire ComparableComparator<String>.newInstance. De même, ComparableComparator<String>.class n'est pas correct et je ne peux pas le passer en argument d'une méthode. Du coup, la seule solution que j'ai trouvé pour le moment, c'est d'instancier les comparateurs un par un à la main, dans une zone static du ComparableComparator... Comme je disais, je ne suis pas un grand spécialiste de ce langage mais il me semble que ça fait parti des limitations un peu embêtantes des génériques en Java... Dommage...

/** * comparators.
 */
@SuppressWarnings("unchecked")
private static Map<Class, ComparableComparator> comparators = new HashMap<Class, ComparableComparator>();
static {
    comparators.put(Date.class, new ComparableComparator<Date>());
    comparators.put(String.class, new ComparableComparator<String>());
}

Ensuite, la méthode getInstance prend la classe "Comparable" en argument. Si le comparateur correspondant n'est pas dans la map, une InstantiationException est lancée.

public static <E extends Comparable<E>> ComparableComparator getInstance(final Class<E> c)    throws InstantiationException {
    if (!comparators.containsKey(c)) {
        throw new InstantiationException(
            "No ComparableComparator could be initialized for the class " + c);
    }
    return comparators.get(c);
}

Voilà encore un joli exemple de l'utilité et des limites des génériques en Java ! :D

/** * Generic comparator for class which implements the Comparable interface.
 * @param <T> the generic comparable class
 */
public class ComparableComparator<T extends Comparable<T>> implements Comparator<T> {
    
    /**
     * comparators.
     */
    @SuppressWarnings("unchecked")
    private static Map<Class, ComparableComparator> comparators = new HashMap<Class, ComparableComparator>();
    static {
        comparators.put(Date.class, new ComparableComparator<Date>());
        comparators.put(String.class, new ComparableComparator<String>());
    }

    /**
     * Constructor.
     */
    private ComparableComparator() {
        super();
    }
    
    /**
     * @param <E>
     * @param c
     * @return the corresponding ComparableComparator
     * @throws InstantiationException
     */
    @SuppressWarnings("unchecked")
    public static <E extends Comparable<E>> ComparableComparator getInstance(final Class<E> c)
        throws InstantiationException {
        if (!comparators.containsKey(c)) {
            throw new InstantiationException(
                "No ComparableComparator could be initialized for the class " + c);
        }
        return comparators.get(c);
    }

    /**
     * @param o1 first object to compare
     * @param o2 second object to compare
     * @return comparison result
     * @see java.util.Comparator#compare(java.lang.Object, java.lang.Object)
     */
    public int compare(final T o1, final T o2) {
        if (o1 == null) {
            if (o2 == null) {
                return 0;
            }
            return -1;
        }
        return o1.compareTo(o2);
    }

}

k-Splittable Delay Constrained Routing Problem : A Branch-and-Price Approach

Léon — Mon, 10 Sep 2007 17:42:00 +0200

Jé́rôme Truffot, Christophe Duhamel, Philippe Mahey.
Rapport de recherche RR-06-08, LIMOS, Aubière, France, 2006.
En ré́vision dans Networks.

Routing problems which include a QoS based path control play a key role in broadband communication networks. We analyze here an algorithmic procedure based on a branch and price algorithm and on the flow deviation method to solve a non-linear k-splittable flow problem. The model can support end-to-end delay bounds on each path and we compare the behaviour of the algorithm with and without these constraints. The trade-off between QoS guaranties and CPU time is clearly established and we show that minimizing the average delay on all arcs will yield solutions close to the optimal one at a significant computational saving.

@TECHREPORT{Truffot06b,
  author = {J{\'e}r{\^o}me Truffot and Christophe Duhamel and Philippe Mahey},
  title = {{k-Splittable Delay Constrained Routing Problem: A Branch and Price Approach}},
  institution = {LIMOS},
  year = {2006},
  number = {RR-06-08},
  address = {Aubi{\`e}re, France}
}

A Branch and Price Algorithm for the k-splittable Maximum Flow Problem

Léon — Mon, 10 Sep 2007 17:28:00 +0200

Jé́rôme Truffot, Christophe Duhamel.
Rapport de recherche RR-06-04, LIMOS, Aubière, France, 2006.
En révision dans Discrete Optimization.

The Maximum Flow Problem with flow width constraints is a NP-hard problem. Two models are proposed: the first model is a compact node-arc model using two flow conservation blocks per path. For each path, one block defines the path while the other one send the right amount of flow on it. The second model is an extended arc-path model. It is obtained from the first model after a Dantzig-Wolfe reformulation. it is an extended model as it relies on the set of all the paths between the source and the sink nodes. Some symmetry breaking constraints are used to improve the model. A branch and price algorithm is proposed to solve the problem. The column generation reduces to the computation of a shortest path whose cost depends on weights on the arcs and on the path capacity. A polynomial time algorithm is proposed to solve this subproblem. Computational results are shown on a set of medium-sized instances to show the effectiveness of our approach.

@TECHREPORT{Truffot06a,
  author = {J{\'e}r{\^o}me Truffot and Christophe Duhamel},
  title = {{A Branch and Price Algorithm for the k-splittable Maximum Flow Problem}},
  institution = {LIMOS},
  year = {2006},
  number = {RR-06-04},
  address = {Aubi{\`e}re, France}
}

Bounding the number of light paths for robust LSP routing

Léon — Mon, 10 Sep 2007 17:17:00 +0200

Philippe Mahey, Jérôme Truffot
in 8th International Conference on Transparent Optical Networks (ICTON 2006),
pages 18, Nottingham, UK, June 2006

(GRAAL Annual Conference 2006)

Using Branch-and-Price to Solve Multicommodity k-Splittable Flow Problems

Léon — Mon, 10 Sep 2007 16:38:00 +0200

Jérôme Truffot, Christophe Duhamel, Philippe Mahey
dans The Proceedings of 2005 International Network Optimisation Conférence,
20-23 mars 2005, Lisbonne, Portugal

In this paper we present a column generation model and a branch-and-price algorithm for a multicommodity k-splittable flow problem. The k-splittable flow is an extension of the unsplittable flow. It has been introduced by Baier, Köhler and Skutella in [4]. This flow can be split into at most k paths. The k-splittable flow is used to study path limitation constraints in classical flow problems. In this paper we consider only the maximal k-splittable flow problem. First we formulate this problem with two sets of variables for each one of the k paths: path design variables and flow variables. This leads to a large linear mixed integer program with two types of variables. The subproblem is not exactly an unsplittable flow problem since the amount of flow is not known. This degree of freedom complexifies this problem. Moreover the flow conservation constraint alone does not ensure that the decision variables define a single path since any set of directed cycles satisfies this constraint. So an additional constraint is put on each nodes cocycle. It allows only sets of disjoint directed cycles.

Next we present a path decomposition on this model, which gives us an exponential edge-path model. Then a Branch-and-Price algorithm is applied. The branching strategy is based on the work of Barnhart and al. for the integer multicommodity flow problem [5]. The column generation subproblem can be seen as a shortest path problem with "high" enough capacity. We propose a polynomial time algorithm to solve this subproblem. Computational results are improved by introducing strategies like variable ordering and storing paths in a pool. Finally numerical results are reported for the different strategies and with a direct MIP approach.

@inproceedings{Truffot05b,
 author = {J{\'e}r{\^o}me Truffot and Christophe Duhamel and Philippe Mahey},
 title = {{Using Branch-and-Price to Solve Multicommodity k-Splittable
              Flow Problems}},
 booktitle = {The Proceedings of 2005 International Network Optimisation 
                    Conference},
 dates = {20-23 mars}
 year = {2005},
 pages = {811--816},
 location = {Lisbonne, Portugal},
}

Branch & Price pour le problème du multiflot k-séparable de coût minimal

Léon — Sun, 09 Sep 2007 15:48:00 +0200

Jérôme Truffot, Christophe Duhamel, Philippe Mahey
dans les Actes du 6ème congrès ROADEF,
14-16 février 2005, Tours, France, pages 357-358

@inproceedings{Truffot05a,
 author = {J{\'e}r{\^o}me Truffot and Christophe Duhamel and Philippe Mahey},
 title = {{Branch \& Price pour le probl{\`e}me du multiflot $k$-s{\'e}parable de 
              co{\^u}t minimal}},
 booktitle = {les Actes du $6^{\text{{\`e}me}}$ congr{\`e}s ROADEF},
 dates = {14-16 f{\'e}vrier}
 year = {2005},
 pages = {357--358},
 location = {Tours, France},
}

Modélisation des problèmes de routage dans les réseaux GMPLS

Léon — Sun, 09 Sep 2007 15:41:00 +0200

Jérôme Truffot, Bruno Bachelet, Philippe Mahey.
Rapport de recherche LIMOS/RR04-24, Laboratoire LIMOS, Université Blaise Pascal.
2004, Clermont-Ferrand, France.

http://www.isima.fr/limos/publi/RR-...

Cet article présente une analyse et une modélisation des problèmes de routage rencontrés dans les réseaux de communications GMPLS. Nous expliquons en quoi les protocoles de type MPLS et les réseaux optiques modifient les problématiques de routage classiques. De plus, nous considérons des contraintes de qualité de service (QoS), la structure multicouche du réseau et des aspects de sécurisation, permettant de prévenir et de réagir aux pannes. Plusieurs modèles non linéaires pour représenter ces différents aspects, ainsi que des pistes pour les résoudre, sont proposés.

@techreport{Truffot2006,
 author = {Jérôme Truffot and Bruno Bachelet and Philippe Mahey},
 title = {{Modélisation des problèmes de routage dans les réseaux GMPLS}},
 institution = {{LIMOS, Université Blaise Pascal, Clermont-Ferrand, France}},
 year = {2004}
}

Le problème de flot maximal avec contrainte sur le nombre de chemins

Léon — Sun, 09 Sep 2007 15:29:00 +0200

Jérôme Truffot, Christophe Duhamel, Philippe Mahey
dans les Actes de la 4ème conférence Francoro,
18-21 août 2004, Fribourg, Suisse

@inproceedings{Truffot04,
 author = {J{\'e}r{\^o}me Truffot and Christophe Duhamel and Philippe Mahey},
 title = {{Le probl{\`e}me de flot maximal avec contrainte sur 
            le nombre de chemins}},
 booktitle = {dans les Actes de la $4^{\text{{\`e}me}} conf{\'e}rence Francoro},
 dates = {18-21 ao{\^u}t}
 year = {2004},
 pages = {43},
 location = {Fribourg, Suisse},
}

Curriculum Vitae

Léon — Sat, 08 Sep 2007 20:02:00 +0200

Jérôme Truffot - Ingénieur en informatique

28 ans, célibataire

jerome.truffot.2003[at]anelis.isima.fr - http://jerome.truffot.fr

Apt 36 - Résidence Alméria, 39 bd Pochet-Lagaye, 63000 Clermont-Ferrand

Formation

2003 - 2007 : Thèse en informatique au LIMOS-CNRS UMR 6158, Université Blaise Pascal, Clermont-Ferrand, soutenance prévue fin octobre
- Sujet : Conception de réseaux haut débit sous contraintes de sécurisation.
- Thèmes de recherche : recherche opérationnelle, optimisation combinatoire, optimisation convexe, programmation linéaire, optimisation dans les réseaux.
- Participation au projet PRESTO de l'ACI CNRS Sécurité Informatique.

2000 - 2003 : Diplôme d'Ingénieur en Informatique de l'ISIMA. (Institut Supérieur d'Informatique, de Modélisation et de leurs Applications), Clermont-Ferrand.

Option : Calcul et Modélisation Scientifiques.

1997 - 2000 : Classes préparatoires, section mathématiques et physique au lycée Carnot de Dijon.

1997 : Baccalauréat scientifique, spécialité mathématique, mention Assez Bien, au lycée Chevalier d'Eon de Tonnerre.

Expérience professionnelle

2005 - 2007 : Attaché Temporaire d'Enseignement et de Recherche à l'ISIMA
- Programmation numérique : cours/TD/TP, niveau 1ère année.
- Développement objet / C++ : encadrement de TP, niveau 2ème et 3ème année.
- Algorithmique : cours/TD, niveau 1ère année.
- Recherche opérationnelle / Mathématiques : cours/TD, niveau 1ère année N+I (étudiants étrangers).

2003 - 2005 : Vacations à l'ISIMA, encadrement de projets étudiants.

Avr. 2003 - Sep. 2003 : Stage de 5 mois au LIMOS-CNRS UMR 6158.
- Sujet : Étude du problème du flot maximal avec limitation du nombre de chemins.
- Langages utilisés : C, C++.
- Environnement de développement : Unix.

Avr. 2002 - Sep. 2002 : Stage de 5 mois au LISC, unité de recherche du CEMAGREF de Clermont-Ferrand.
- Sujet : Réalisation d'une interface d'exploration de simulations.
- Langages utilisés : Java, XML.
- Environnement de développement : Windows.

Compétences

Recherche opérationnelle : Programmation linéaire, optimisation combinatoire, optimisation convexe, programmation numérique.
Langages de programmation : C/C++, Fortran, Java, Perl, Scheme, Caml.
Autres langages : HTML, XML, XSL, XML Schema, Latex.
Systèmes d'exploitation : Unix, GNU/Linux, Windows.
Outils spécialisés : CPLEX, MatLab.
Module suivi en complément : Bioinformatique.
Langues : Anglais (bon niveau), Allemand (notions).

Charges collectives

Juin 2006 : Membre du comité d'organisation de la Xème journée de l'école doctorale Sciences Pour l'Ingénieur.
Avr. 2005 : Membre du comité d'organisation des journées de présentation des sujets de thèse par les doctorants de 1ère année de l'école doctorale Sciences Pour l'Ingénieur.
Fév. 2004 : Membre du comité d'organisation du forum doctorant entreprise.

Publications

à faire

Activités annexes

Trésorier de l'ANELIS, l'association des ANciens ELèves de l'ISIMA.
Développement du site internet de l'ANELIS.
Randonnées pédestres.

Les Puys de la Vache et de Lassolas

Léon — Sun, 05 Aug 2007 16:38:00 +0200

Après une semaine agréable où la température n'a cessé d'augmenter, ce dimanche a probablement été le jour le plus chaud de cet été. Donc pour profiter pleinement de ma randonnée dominicale, je suis allé chercher la fraicheur matinale. Départ à 8h de la maison du parc des volcans, direction les Puys de la Vache et de Lassolas à travers les cheires boisées et les brumes matinales.

Ces deux puys jumeaux ont des cratères engueulés^[1] leur conférant cette forme si particulière de croissant. Culminant respectivement à 1167 et 1187 mètres, ils offrent un magnifique panorama sur la chaine des puys et la campagne environnante. On peut y admirer le Puy de Dôme au nord, le massif du Sancy au sud-ouest ainsi qu'une multitude de puys boisés tout autour. Contrairement à ces derniers, leurs sommets sont quasiment dépourvues de végétation et sont recouverts essentiellement de grains de pouzzolane, cette roche volcanique rouge ou noire présente sur de nombreux puys auvergnats. La vue s'en trouve d'autant plus dégagée et l'impression de vide démultipliée (amis acrophobes, le panorama en vaut la peine mais allez-y accompagné, ce serait dommage de rester bloqué au milieu de la pente ;-)).

Heureusement que le paysage vaut la peine d'accomplir tous ces efforts car les montées, heureusement relativement courtes, font fonctionner à plein régime coeur, poumons et une multitude de muscles dont j'ignore les noms. Pires encore, les descentes, tout aussi raides, sont casse-pattes et révèle à la perfection les muscles utilisés dans ce type d'exercice. C'est facile, c'est là où on a mal ;-). Si bien que le retour sur le plancher des vaches, et ses pentes plus acceptables, donne envie de se dégourdir les jambes en marchant de plus belle. On jettera néanmoins un oeil curieux et émerveillé sur le splendide paysage lunaire, au pied du Puy de la Vache, composé d'éboulis de pouzzolane rouge et noire et de bombes de lave sur un terrain dégagé, spectacle ahurissant au milieu de la forêt.

Après deux heures à crapahuter dans les collines, j'avais hâte d'attaquer la deuxième partie de ma randonnée qui me mène jusqu'au Puy de Vichatel par les GR 4 - GR 441. De grands chemins parcourent la forêt à l'abris de la chaleur. Je m'adonne alors entièrement au plaisir de la randonnée. Mes jambes s'affolent dans un rythme effréné. Une impression de légèreté me fait voler à travers la vallée. Au comble de mon bonheur, je distance pour un moment la horde de mouches sanguinaires qui me suit depuis mon départ et qui ne faisait rien qu'à m'embêter ...

Le Puy de Vichatel en lui-même n'apporte pas grand chose. D'autant plus que je me suis légèrement perdu dans la montée (j'ai du me tromper à un embranchement ... bref passons ... ;-)). Le cratère au sommet est assez impressionnant mais ça ne vaut pas le Pariou. Dans la descente, on a un point de vue intéressant sur les Puys de la Vache et de Lassolas mais c'est tout. De retour à la voiture après 4h de balade, mes pieds étaient heureux que j'achève là leur calvaire et, moi-même, j'étais heureux qu'ils aient si bien supportés cette épreuve. En début d'après-midi, au paroxysme de la chaleur, chacun se réjouit d'une douche salvatrice et d'une sieste réparatrice ... Quel beau dimanche !

L'itinéraire sur Géoportail.

Quelques photos :

Notes

[1] l'un des cotés a explosé

Le lac d'Aydat

Léon — Sun, 29 Jul 2007 18:34:00 +0200

Encore un beau dimanche ensoleillé. Je ne boude pas mon plaisir et je pars en randonnée, direction le lac d'Aydat à une vingtaine de minutes de Clermont-Ferrand : probablement le lac préféré des clermontois en été. Quand il fait beau et chaud, la berge aménagée est prise d'assaut par une horde de baigneurs assoiffés de fraicheur. Enfin, quand, comme moi, on arrive vers 9h15 un dimanche matin, c'est plutôt calme ;-).

Un grand beau temps et une fraicheur matinale exquise m'ont donc accompagné durant toute cette balade qui consiste à faire le (grand tour du lac. Le panneau de cette petite randonnée prévoie un parcourt de 12,5 Km pour une durée de 3h45. Néanmoins, il n'y a aucune vrai difficulté, pas de puy à grimper, pas de descente vertigineuse, pour tout dire un terrain assez plat en comparaison d'autres balades à faire dans la région. Bref, elle a tout pour me plaire cette rando et je n'ai rien regretté :D.

Pour commencer, on tourne le dos au lac et on part plein ouest, direction la chaine des puys. Ce lac tant promis par la dénomination même de la randonnée se fera pourtant attendre jusqu'aux derniers kilomètres, pour apparaitre sous son meilleur profil (le coquin ;-)). On traverse quelques villages des alentours, aussi calme qu'un dimanche matin. Le temps pour le coeur de prendre son rythme et pour les jambes de se délier, la machine tourne à plein régime et avale les kilomètres. Déjà, on se trouve à quelques pas du Puy de Charmont. A un carrefour, on peut hésiter et aller tout droit à la découverte des puys et des cheires, ces anciennes coulées de laves aujourd'hui recouvertes de forêts. Ces cheires peuvent d'ailleurs avoir une plus grande importance que ce que l'ont pense. Lorsque l'on regarde la carte de la région, on aperçoit que les cheires basses séparent le lac d'Aydat et le lac de la Cassière (merci géoportail). Il fut un temps où ces deux lacs n'en formaient qu'un, avant que cette coulée de lave ne les séparent.

Mais revenons à notre carrefour et la tentation de ces puys boisés si particulier. Tel n'est pas le but de notre escapade. Au contraire, prenons la direction du sud, vers le soleil. Il faut dire qu'il a fait beau toute la journée mais, étrangement, un gros tas de nuages moches comme tout a décidé de stationner sur ces puys (bouh les méchants !!). Nous traversons alors le petit village de Fontclairant et côtoyons les flancs du Puy de la Rode jusqu'au village de Veyreras. Au détour d'une ferme, nous changeons de cap.

Nous continuons de tourner et c'est au tour de l'ouest d'avoir les faveurs de notre regard. Les massifs du Livradois-Forez sont loins. Il y aurait encore beaucoup de ces plaines, de ces cultures et de ces prairies à traverser. Au milieu de cette nature apprivoisée par l'agriculture moderne, un menhir nous rappelle qu'il s'agit aussi de la terre de nos ancêtres. Ici, au milieu de nul part se dresse la Pierre Longue. Obélix l'aura surement laisser trainer par là en pourchassant une cohorte de romains :-). C'est toutefois l'occasion de détourner notre regard vers le massif du Sancy, au loin vers l'Est. Finalement, ce menhir n'est peut-être pas là totalement par hasard ...

En rencontrant le GR30, nous changeons une dernière fois de cap pour retourner, au nord, vers le lac d'Aydat. A proximité du village de Phialeix, nous abordons la descente vers le lac qui se laisse admirer sous toutes ses coutures. Il s'étend de toute son ampleur au travers des moindres plis que la terre forme ici. L'eau tende de s'échapper de tous les côtés. Poussé par le vent, de petites vagues viennent s'échouer impuissantes sur les rives. La berge nord, aménagée, est occupé par les baigneurs. Plus au calme, quelques pécheurs s'adonnent à leur loisir. Au milieu, de petites embarcations à voile font la courses contre des pédalos. Il ne reste plus qu'à rejoindre la berge nord par de charmants chemins à travers les bois. A midi passé, le soleil haut dans le ciel épargne cependant la fraicheur boisée de cette fin de randonnée.

L'itinéraire sur Géoportail.

Quelques photos :

La Roche Branlante

Léon — Sun, 22 Jul 2007 15:36:00 +0200

Après une semaine de mauvais temps en plein mois de Juillet, ce dimanche ensoleillé ne pouvait rimer qu'avec randonnée !

Me voilà donc parti en début d'après-midi en direction de Rochefort-Montagne. Mon fidèle topoguide m'annonce 3h30 de randonnée, plus 30 minutes pour aller voir la Roche Branlante, clou de la balade. Le départ est bien moins brutal que pour le plateau de la Pinière. Je peux alors profiter du beau temps pour ~~prendre des coups de soleil~~ admirer la vallée de la Plane recouverte de prairie et parsemée de quelques petits villages. Les vaches qui pâturent à flanc de colline ne semblent pas perturbées par ma présence. Je continue mon chemin poussé par la brise et le calme de la campagne. Quel plaisir de se dégourdir les jambes dans un grand bol d'air frais.

Du haut de la colline qui sépare les vallées de la Plane et de Fontsalade (du nom des ruisseaux du même nom qui se retrouve un peu au nord de Rochefort-Montagne pour former le ruisseaux de Rochefort), on aperçoit au loin les Roches Tuilière et Sanadoire qui semblent former la porte d'entrée du massif du Sancy. Dans la descente de la vallée de Fontsalade, une ouverture dans la forêt nous laisse admirer cette formation géologique des plus pittoresques.

On remonte ensuite l'autre versant de la vallée jusqu'à la Roche Branlante. Il s'agit d'un énorme bloc rocheux d'environs 5 mètres de haut posé en équilibre sur un autre bloc rocheux. Il n'y a pas d'autre lien entre ces deux blocs que celui imposé par la gravité. Au fil de l'érosion, cet équilibre semble de plus en plus périlleux. Si bien qu'un bon coup d'épaule semble pouvoir faire vaciller cet immense rocher. Nul doute qu'il finira par tomber dans la vallée (j'espère qu'il n'y a personne en dessous ;-). D'ici là, on peut encore admirer une de ces curiosités que la nature nous réserve.

Avant de redescendre vers Rochefort-Montagne, un coup d'oeil au nord nous permet d'admirer la chaîne des Puys dont le si charismatique Puy de Dôme. Laissons maintenant sonner au loin la cloche des vaches en pâture pour regagner la civilisation ...

L'itinéraire sur Géoportail : De bordas (sortie sud de Rochefort-Montagne), on suit le chemin vers le sud en direction de la Plane, puis on tourne direction la Gratade. On traverse ensuite Chez Chocol et le Deveix. Les plus courageux effectueront un petit détour vers la Roche Branlante avant de redescendre vers Rochefort-Montagne.

Quelques photos :

Le tour de la Pinière

Léon — Sat, 14 Jul 2007 16:38:00 +0200

Enfin un peu de soleil, enfin un peu de chaleur, enfin un peu de vacances, enfin un semblant d'été ! C'est décidé ! Je pars me balader ! Je m'imagine déjà en train de trémousser mon popotin sur les chemins de campagne de cette chère Auvergne .

Voilà un moment que je ne m'étais pas accordé un peu de temps pour randonner. J'ai donc essayé de choisir quelque chose de pas trop long, ni trop dur. Je feuillette joyeusement mon guide chamina à la recherche de ma première randonnée de l'été, première d'une longue liste si le temps le permet. Bon, pour une reprise, on va laisser de coté l'ascension du Sancy. Oh ! Des petites randos de 2h, ça a l'air gentil ... Mais on ne sait pas ce que l'été nous réserve. Et si c'était la seule rando que je puisse faire avant le retour de la pluie ? Allez, soyons courageux, 3-4h me semble un minimum. Ah ! Voilà ! Le tour de la Pinière : petite randonnée bucolique d'une dizaine de kilomètres pour un temps annoncé de 3h45. Parfait, ça consiste à faire le tour du plateau de la Pinière qui surplombe Montaigut-le-blanc, charmante bourgade à coté de Champeix, situé à une petite demi-heure de Clermont-Ferrand. Parfait, vraiment parfait ! Et un plateau, c'est tout plat, non ?

Tout plat ? Bougre d'imbécile !! Un plateau, c'est plat, forcément, mais seulement une fois qu'on est grimpé sur la table !!! J'ai pourtant le plateau de Gergovie juste en face de chez moi. Je n'aurais pas du être si surpris une fois arrivé à Montaigut-le-Blanc. Donc le plateau, il est plat mais il est posé tout là haut !! Pour y aller, il va falloir grimper !

Je sors donc les cordes, les piolets et les chaussures à crampon ... Ah, on me fait signe que ce n'est pas la peine. Il y aurait un chemin et ce ne serait même pas la peine d'avoir peur ! Fichtre, étrange rumeur. Il y a tout de même 300 mètres de dénivelé. Courageux comme jamais, je file vérifier la dite rumeur. Et c'est parti ! Je suis les mystérieuses marques jaunes qui bordent le dit chemin. Et le chemin grimpe, et ça monte, et la pente est forte, et le chemin n'est même pas droit. Une fois arriver en haut d'un chemin, on en prend un autre qui monte tout autant. Bah, ce n'est pas grave, Un pied devant l'autre, le b-a-ba de la marche me mènera jusqu'au bout du chemin (qui se trouve être le point de départ, principe primordiale de la petite randonnée intitulé "Principe de conservation de la voiture" ;-)). Bien sûr, sur un tel chemin, il faut pousser un peu plus fort que d'habitude sur la jambe droite pour faire passer le pied droit devant le pied gauche, et un peu plus fort encore sur la jambe gauche pour effectuer l'opération inverse.

Cette compétition puérile entre mes deux pieds a du inquiéter mon coeur qui s'est emballé. Il fallait donc rester concentrer pour ne pas oublier de respirer. Inspiration, expiration ! 400 fois par seconde !!! Les yeux qui sortent des orbites, la sueur qui gicle de chaque pore de mon être. Bon, il est temps de faire une pause. Boire un coup. Admirer ... La vue bien sûr, magnifique : le massif du Sancy, le massif des Monts Dore, des Puys par-ci, des couzes par-là. Le bruit aussi : le vent dans les arbres, les papillons (celui qui n'a jamais entendu un papillon voler n'a aucune imagination !! :D). Et la balade continue.

A force de monter, j'y suis arriver sur ce fichu plateau. Et là haut, c'est le bonheur. Bon oui, c'est plat, mais pas que ça. Il y a encore plus de vent, rafraichissant. Il y a plus de soleil, plus de paysage et plus de silence, de calme, de paix. Un bonheur simple porté par mes deux pieds martyrisés mais, forcément, passionnés ...

Le plateau de la Pinière sur Géoportail.

Quelques photos :