Auteur

Céline Gilet

Céline GiletDiplômée d'un master MIAGE (Méthodes Informatiques Appliquées à la Gestion des Entreprises), Céline débute sa carrière chez Capgemini où elle participe à la conception et au développement de projets Java J2EE destinés à des grands comptes (Ministère de la Défense, SNCF, MACIF, Direction Générale des Impôts).
Attirée par la culture entrepreneuriale et innovante de Netapsys, Céline décide de rejoindre l'équipe nantaise, début 2009, pour poursuivre dans le domaine des nouvelles technologies.

Fil des billets

Par Céline Gilet, le 24 novembre 2011
Catégorie : Actualité

Devoxx 2011 : comment se dessine l'avenir de Java

La semaine Devoxx 2011 vient de s'achever. Cette année encore, l'événement a été, de l'avis de tous, hors norme. Les keynotes, conférences et quickies se sont enchaînés à un rythme effréné. C'est donc le moment de prendre un peu de recul et de faire le bilan de trois jours de conférence.

Devoxx, c'est avant tout un événement autour des technologies Java. Utilisant moi-même Java depuis plusieurs années, je décide tout naturellement d'assister à la conférence JDK 7, 8 et 9 (histoire de savoir ce qui m'attend très prochainement).

Pour Java 7, des fonctionnalités prometteuses sont annoncées. Parmi elles, je retiendrai :

  • le multi-catch d'exceptions permettant de traiter en un seul bloc plusieurs types d'exceptions (Ex : IOException | SQLException)
  • la nouvelle API IO pour toutes les opérations d'écriture / lecture de fichiers et flux.
  • l'instauration du try-with-resources permettant de gérer plus facilement les exceptions et les fermetures automatiques de ressources (notamment grâce à la création d'une nouvelle interface AutoCloseable).
  • le framework Fork/Join permettant de réaliser enfin facilement des traitements en parallèle.

Pour Java 8, deux projets sont à l'honneur : le projet Jigsaw et le projet Lambda. Je suis assez séduite par la présentation de Jigsaw où la notion de modules apparaît. De la même façon que les fichiers "package-info.java" permettent aujourd'hui de décrire le contenu d'un package, les fichiers "module-info.java" permettront demain de recenser pour un module l'ensemble des dépendances nécessaires et leurs versions. L'objectif de ce projet est d'optimiser le chargement des éléments nécessaires au fonctionnement d'une application.

Ce ne sera plus la définition du classpath mais la configuration par module qui permettra d'obtenir des temps de chargement plus rapide et moins gourmand en espace.

Pour Java 9, l'une des grandes fonctionnalités prévue est la possibilité de customiser sa propre JVM. On parle aussi pour cette version de BigData, de réification des Generics et d'amélioration de l'intégration de composants natifs (C++).

Autre style de conférence, celle traitant des "anti-patterns" les plus courants avec Hibernate. La présentation est originale et basée sur des cas d'utilisation concrets. Et c'est aux participants de la salle de voter pour trouver, dans chacun des cas, quel est le nombre et le type de requêtes générées. On prend alors toute la mesure de la difficulté d'avoir un modèle de données métier bien configuré. Le point le plus délicat dans la mise en place d'un modèle est la gestion des associations entre les objets. En fonction du type de chargement et du choix de l'objet utilisé pour représenter une liste, les résultats sont édifiants. Le choix d'une Collection, d'une List ou d'un Set peut paraître à première vue anodin mais il n'en est rien.

Je découvre également le framework Play que je ne connaissais pas. Beaucoup d'enthousiasme pour ce framework d'autant plus que les speakers ont annoncé la sortie de la version 2.0. La démonstration est convaincante. Tout est compilé y compris le fichier de configuration des routes, les fichiers javascript et les feuilles de style. Les erreurs de compilation apparaissent directement dans le navigateur.

Une application Play 2.0 peut être facilement déployée dans le cloud (Elastic Deploiement). C'est la plateforme de cloud Heroku qui est prise pour la démonstration. En quelques commandes et un peu de connaissances GIT, l'application est montée dans le cloud. Seul bémol de taille pour les utilisateurs courants de Play, la migration de version 1.x vers la version 2.0 n'est pas possible en partie à cause du changement effectué dans la façon d'appréhender les templates.

La productivité des développements a évidemment été abordée à travers des présentations sur la génération de code à partir de modèles et outils. Les différences d'approche entre le projet EMF d'Eclipse et Spring ROO ont été mises en parallèle. Il en ressort que le choix EMF ou Spring ROO n'a pas de réponse simple et unique : des aspects organisationnels et financiers pèseront dans la balance. En tout état de cause, Spring ROO permet de générer très rapidement, depuis des commandes shell, les classes de différentes couches applicatives (DAO, Service, Repository, IHM). Le framework propose pour la génération un large panel de technologies allant de la base de données à la couche IHM (Hibernate, Spring, JPA, JSF2).

Spring ROO propose également de faire du "Reverse Engineering" en créant une application à partir d'une base de données existante. La productivité apportée par l'outil est évidente. Il faudrait bien entendu regarder en détail le code généré pour bien mesurer sa qualité et les dépendances créées. En tout cas, pour une réalisation de prototype ou une application de "Reverse Engineering", la solution Spring ROO n'est pas à écarter.

Pour terminer, quelques mots sur la conférence "Socializing your Spring Applications". Les applications aujourd'hui ont besoin de récupérer les informations d'un profil Facebook, de récupérer des tweets sur un sujet donné, de récupérer sur FlickR des photos d'un tag particulier... Spring Social est une extension de Spring Framework dont le but est de permettre et faciliter la connectivité avec d'autres systèmes fournisseurs de services. La classe RestTemplate permettait déjà de faire des opérations de ce genre dans différents modes (REST / HTTP) et différents formats (JSON, XML). Spring Social propose désormais des templates spécifiques à chaque fournisseur (TwitterTemplate, LinkedInTemplate...) et propose un mode d'authentification simplifié basé sur le protocole oAuth2 où il n'est plus nécessaire de gérer une politique complexe de token.

Venir à Devoxx, c'est se faire une idée des outils et frameworks de demain. Sortir du quotidien des projets et regarder ce qu'il existe sur le marché permettra de proposer des technologies parfois plus adaptées ou plus productives. Donc si vous avez l'occasion de participer à Devoxx l'année prochaine, surtout n'hésitez pas.

Par Céline Gilet, le 24 novembre 2011
Catégorie : Actualité

Ceylon : le nouveau langage de programmation

Parmi les dernières sessions de Devoxx 2011, l'une propose de découvrir un nouveau langage de programmation destiné à la JVM. Il s'agit du langage Ceylon lancé par Red Hat. Alors réelle révolution ou s'agit-il ni plus ni moins qu'un énième langage de programmation ?

Le langage Ceylon s'inspire fortement du monde Java : vous ne serez donc pas dépaysé en voyant les premières lignes de code. Les créateurs du langage ont voulu gommer certains défauts de Java et s'inspirer d'éléments syntaxiques venant de Scala ou du C#.

Le slogan de Ceylon est "Say more, more clearly". La volonté est clairement affichée : le langage doit s'apprendre facilement, être intuitif pour les habitués de Java et surtout moins verbeux.

Les principales caractéristiques et composantes de Ceylon sont alors passées en revue :

  • L'amélioration de la gestion du "Type Safe" : les speakers nous promettent la fin des NullPointerException et de beaucoup d'autres exceptions levées seulement au moment de l'exécution dans Java. Le mot réservé "exists" permet de tester l'existence réelle d'un objet.
  • La simplification des niveaux de visibilité. Pour Java, on trouvait 4 niveaux (public, private, protected et package). Pour Ceylon, seuls 2 niveaux ("shared" qui équivaut au "public" et le reste prend le scope de "private").
  • Une représentation basée sur une syntaxe déclarative pour s'affranchir du XML.
  • La suppression du mot clé "new" pour construire des nouvelles instances d'objet.
  • La gestion des types dans un switch-case (case(is Rectangle) {...} case(is Circle) {...})
  • La fin de la surcharge ("overloading") à la fois au niveau des méthodes et des constructeurs. Chaque objet devra avoir désormais un seul et unique constructeur. Cette suppression de l'overloading peut faire peur et être perçue comme une régression par rapport à Java mais en contrepartie, le passage des paramètres de méthodes devient optionnel.
  • La possibilité de définir des méthodes directement à l'intérieur du constructeur.

Au niveau des attributs, les getters et setters au sens Java disparaissent. Par défaut, les attributs sont "immutables" à moins qu'ils soient marqués "variable". Et un nouvel opérateur d'assignation ":=" fait son apparition.

Au niveau des abstractions, le "override" de Java devient "actual" pour Ceylon. Par défaut, les éléments ne sont pas redéfinissables.
Pour permettre la redéfinition ("overridding"), il faut explicitement le faire à l'aide des mots réservés "default" ou "formal".

Au niveau des interfaces, de la flexibilité a été apportée. Il est désormais possible de définir dans une interface des méthodes concrètes. De nouveaux mots réservés apparaissent au niveau des définitions de méthodes (passage de "public abstract" à "shared formal") et au niveau de l'implémentation (passage de "implements" à "satisfies").

L'introduction d'objets séquences dans lesquels il est possible de mettre des objets de différents types (union type ou intersection type).

Puis vient le moment de la démonstration où sont créés les premiers fichiers ".ceylon". Un plugin Eclipse dédié au développement Ceylon est téléchargeable. On y retrouve l'auto-complétion, des outils de refactor et d'extraction de code ainsi qu'un debugger.

Il n'existe pas encore de version officielle de Ceylon. L'équipe Red Hat prévoit 3 Milestones avant de sortir la version 1.0. Aucune date officielle n'a été communiquée pour la 1ère Milestone mais les speakers nous promettent sa sortie sous peu.

Pour ce qui est de la simplicité de prise en main du langage, l'objectif me paraît en tout cas rempli. Certes, il y a quelques fonctionnalités qui me semblent intéressantes et prometteuses (comme l'amélioration du "type safe", l'ouverture des interfaces ou les nouveaux objets séquences) mais beaucoup de composantes ne sont en définitive que du sucre syntaxique.

Reste à savoir ce que les développeurs feront comme accueil à ce nouveau langage à sa sortie officielle.

Par Céline Gilet, le 24 novembre 2011
Catégorie : Java J2EE

Hibernate OGM : bientôt un nouveau module dans le monde Hibernate ?

Plus besoin de présenter les modules existants du monde Hibernate : Search, Validator, Shards et Envers. Mais un nouveau est apparu dans l'une des conférences de Devoxx animée par Emmanuel Bernard : il s'agit d'Hibernate OGM.

Dans les couloirs de Devoxx, tout le monde parle NoSQL et BigData : plusieurs conférences étaient proposées sur ce sujet notamment avec des démonstrations de Cassandra et MongoDB. Actuellement, la volumétrie des données et la complexité de certains modèles métiers nécessitent de revoir la façon dont sont organisées et stockées les données. La performance et la disponibilité des données sont au cœur des problématiques de beaucoup d'applications.

Mais Hibernate ne compte pas faire objet de figuration dans le monde NoSQL et propose de faire du NoSQL en conservant son API de persistence JPA et en proposant une décorrélation des objets et de la structure de données. Les entités ne seront plus stockées dans une base de données relationnelle mais sous forme d'entrées clé/valeur (à l'image d'une Map).

Hibernate OGM (Object Grid Mapper) a pour objectif de conserver la gestion actuelle de la persistance des entités (objets métiers) mais en proposant un stockage basé sur les dataGrids reconnus pour leur gestion simplifiée de la scalabilité.

En d'autres termes, le projet OGM nous permet de persister nos entités métier existantes dans une base de données non relationnelle sans être obligé de revoir la conception du modèle métier. OGM assure aussi la continuité du langage de requêtes JP-QL, même si pour le moment certaines requêtes complexes restent encore non réalisables.

La démonstration montre que le passage au NoSQL sur une application existante se fait relativement rapidement : quelques modifications dans le fichier de configuration "persistence.xml" (ajout d'un provider HibernateOgnProvider) et ajouts d'annotations d'indexation.

Immédiatement, on constate que nos objets sont bien stockés sous forme de clé/valeur. La clé est constituée du nom de la table et de l'identifiant de l'objet. Et pour gérer les associations / relations entre les objets, OGM stocke un cache d'association avec une clé par navigation.

Emmanuel Bernard nous révèle alors, en détail, les outils et frameworks utilisés par OGM :

  • Hibernate Core avec JPA/EntityManager pour la persistance des entités,
  • Hibernate Search pour l'indexation des objets et composants de requêtes,
  • Teiid pour permettre les jointures complexes et les agrégations de données,
  • Infinispan pour le stockage distribué des données clé/valeur et des indexes Lucene.

Le principal inconvénient des outils actuels NoSQL est l'incapacité de gérer et de garantir le mode ACID (Atomicité, Cohérence, Isolisation et Durabilité) que toute transaction en base de données devrait avoir. Le recours à Infinispan dans OGM permet d'assurer cette gestion de transaction.

Le principe actuel d'OGM est donc d'utiliser et de combiner des projets matures ayant déjà faits leurs preuves dans des domaines différents.
L'objectif est de fournir:

Une structure relationnelle

avec un stockage en mode NoSQL clé/valeur

et toujours avec une API de requêtage (JP-QL)

Il existe à ce jour qu'une version alpha d'Hibernate OGM mais je pense que c'est un projet qui mérite d'être suivi car l'approche proposée pour combiner le modèle relationnel et le NoSQL me semble intéressante et relativement peu coûteuse à mettre en place.

Par Céline Gilet, le 18 novembre 2011
Catégorie : Java J2EE

Spring 3.1 : ce que nous réserve la prochaine version

Dans la panoplie des conférences Devoxx 2011, les équipes de SpringSource ont présenté les nouveautés et améliorations de la future version 3.1, et nous donnent même en avant-première les perspectives à venir !

Parmi les grandes nouveautés de Spring 3.1 présentées lors de la conférence Devoxx, j'en retiens deux. La première concerne les outils d'abstraction d'environnement à travers la définition de profils, et la seconde la possibilité de mettre en place simplement un système de cache.
L'exemple pris lors de la démonstration concerne la problématique récurrente de définition de la base de données. Dans le cas du profil de développement, c'est une base embarquée en mémoire qui sera utilisée alors que pour le profil de production, ce sera une base Oracle.
Pour mettre en place cette abstraction d'environnement, Spring propose de définir des profils. Pour définir un profil, rien de plus simple : il suffit de lui attribuer un nom.

  • Configuration par fichier XML avec l'attribut profile
<beans profile="production">

         <bean id="dataSource" class="...">

     </beans>

     <beans profile="dev,integ">

        <bean id="dataSource" class="...">

     </beans>
  • Configuration par annotation @Profile("production")

En fonction du profil activé au chargement de l'application, c'est seulement les éléments de configuration propres à ce profil qui seront utilisés : les autres seront purement et simplement ignorés. Il est même possible d'associer et de combiner les profils afin d'en avoir plusieurs actifs en même temps (à partir du moment où ils ne rentrent pas en conflit).

L'activation de profil(s) peut se faire de trois façons différentes :

  • En renseignant un paramètre d'initialisation dans le fichier "web.xml"

<param-name>spring.profiles.active</param-name>

<param-value>production</param-value>

  • En valorisant par programmation la propriété activeProfiles sur l'environnement du contexte

context.getEnvironment().setActivesProfile("production");

En passant l'information directement en ligne de commande en valorisant l'argument -Dspring.profiles.active

La gestion de l'abstraction d'environnement proposée par Spring permet donc de réduire le nombre de fichiers de configuration et/ou propriétés (plus besoin d'avoir autant de fichiers que de profils). Cela permet aussi de supprimer la substitution dynamique des variables de configuration (qu'il était possible d'effectuer en filtrant les ressources avec Maven).

Concernant la politique de définition de cache, là aussi, ce que propose Spring me semble intéressant. Il s'agit en fait d'un système générique de définition de cache complètement transparent. Le développeur indique quels éléments ou quels objets il souhaite mettre en cache. Le système de cache de Spring est complètement pluggable : vous pouvez brancher derrière votre gestionnaire de cache préféré : ehcache, concurrentMap... Là aussi, des annotations intuitives : @Cacheable, @CacheEvict, @CachePut. La mise en cache ou le retrait peut également intégrer des conditions qu'il est possible de mettre directement en argument de l'annotation via une expression SpringEL du type (#montant > 2000).

La définition d'un système de cache applicatif est généralement considérée comme relativement complexe à mettre en œuvre par les développeurs. C'est une des raisons pour laquelle sa mise en place intervient généralement assez tardivement dans le développement d'une application. C'est lorsque des soucis de performance commencent à apparaître que l'équipe de développement se penche sur la question de l'ajout d'un gestionnaire de cache. Avec la prochaine version de Spring, plus d'excuses. Les annotations de cache peuvent être déjà réfléchies et posées sur les classes de l'application même si la définition concrète du gestionnaire de cache n'est pas encore faite.

Avec la version actuelle de Spring, la configuration par annotations avait déjà une place importante. Avec la version 3.1, la dynamique continue et s'intensifie encore ! A la question "Qui utilise encore les fichiers XML pour configurer son contexte applicatif, très peu de mains se sont levées dans la salle !". Il semble donc que les annotations aient un très bel avenir.

Au delà des nouvelles fonctionnalités de la version 3.1, la politique de Spring pour le futur est clairement de s'ouvrir toujours plus et de faciliter l'interaction avec les outils et autres frameworks en vogue (JSF 2.x, Bean Validation, JPA, Java EE7, JCache...). Mais patience, ce sera pour les prochaines versions...

Quant à la roadmap proche, Spring 3.1 sera proposé en Release Candidate 2 (RC2) la semaine prochaine. Plus que quelques jours à attendre !

Par Céline Gilet, le 13 juin 2011

Hibernate Envers : Audit et Suivi de version

Hibernate Envers permet de tracer les modifications sur les objets métiers d'une application mappés en base de données. Le suivi de modifications repose sur le principe de révisions. Chaque sauvegarde (transaction commitée) donne lieu à la création d'une nouvelle version qui regroupe l'ensemble des données modifiées.

Chaque entité auditée va être représentée par deux tables :

  • Une table pour les données actuelles de l'entité
  • Une table d'historique contenant le suivi des modifications de l'entité

L'exemple suivant montre les étapes à suivre pour mettre en place Hibernate Envers.

 
Lire la suite
Par Céline Gilet, le 03 mai 2011
Catégorie : Java J2EE

Les collators : un autre moyen de comparaison

Il nous est tous arrivé d'avoir à comparer des chaînes de caractères dans nos programmes Java. Tout le monde connaît les 2 méthodes de comparaison de la classe java.lang.String :

  • compareTo (qui permet de comparer 2 chaînes de caractères)
  • compareToIgnoreCase (qui permet de comparer 2 chaînes de caractères sans tenir compte de la casse (minuscules ou majuscules))

Mais il existe également une autre classe (fournie avec le JDK) qui permet de faire des comparaisons plus élaborées : il s'agit de la classe java.text.Collator.

Petit tour d'horizon des possibilités offertes par les collators.

 
Lire la suite
Par Céline Gilet, le 24 mars 2011

Hibernate et la personnalisation des fichiers d'imports

Hibernate offre la possibilité de créer la structure d'un schéma de base de données directement à partir de la définition du mapping (fichiers hbm ou annotations selon les goûts) en positionnant la propriété "hibernate.hbm2ddl.auto" à "create" ou "create-drop".

A la fin de la création de la structure de la base de données, Hibernate vérifie si un fichier "import.sql" est présent dans le classpath. Si ce fichier est trouvé, les commandes SQL sont exécutées par le moteur hbm2dll.

Jusqu'à la version 3.5, il fallait que ce fichier s'appelle impérativement "import.sql".

 
Lire la suite
Par Céline Gilet, le 17 février 2011
Catégorie : Java J2EE

Intégration de contenu FlickR dans une application Java

Dans le cadre de la mise en place d'un outil d'aide au choix des végétaux, nous avons du intégré au sein de notre application les images du client stockées sous son compte FlickR.
FlickR est un site web gratuit qui permet de mettre en ligne des photos et/ou vidéos.

Le contenu posté sous FlickR intègre différents niveaux de protection :

  • public
  • privé (restriction à un utilisateur ou à un groupe d'utilisateurs)

Le besoin consistait à récupérer de façon dynamique les images répondant à un ensemble de tags décrivant les végétaux (famille, espèce, genre...).
Le contenu des images étant protégé, nous avons également mis en place un mécanisme d'authentification basé sur un système de jetons.

Pour la récupération des images depuis notre application Java, nous avons testé deux méthodes

  • l'utilisation de FlickrJ
  • le requêtage en mode REST à l'aide de Spring 3

Au final, nous avons retenu le requêtage en mode REST puisque les fonctionnalités proposées dans l'API FlickrJ sur les recherches d'images étaient trop restrictives.

Pour avoir plus d'informations sur les services FlickR, vous pouvez consulter http://www.flickr.com/services/api/.

 
Par Céline Gilet, le 04 avril 2009

Scrum et XP : Retours d'expérience

Jeudi dernier, le groupe des praticiens Agiles de Nantes proposaient deux retours d'expérience autour des méthodes Scrum et de la mise en place de l'eXtreme Programming (XP).
Nous avons aussi pu bénéficier d'un retour sur la formation ScrumMaster dispensée par Pyxis.
Petit résumé de la soirée...

 
Lire la suite
Par Céline Gilet, le 11 mars 2009

Requêtes de recherche sous Oracle, Informix, Postgresql : gestion de la casse et des accents

Pour qu’un outil de recherche soit performant et agréable à utiliser, il faut qu’il soit capable de retourner tous les éléments susceptibles de correspondre à ce que l’utilisateur recherche sans tenir compte de la casse et/ou des accents.

Sous Oracle, il est possible d’utiliser l'opérateur « TRANSLATE » pour gérer ce genre de problème.

SELECT * FROM TABLE
WHERE TRANSLATE(UPPER(monChamp),’ ÉÈÊËÀÄÂÎÏÔÖÛÜ’,’ EEEEAAAIIOOUU’))
LIKE TRANSLATE(UPPER(‘%requêtes%’), ‘ÉÈÊËÀÄÂÎÏÔÖÛÜ’, ‘EEEEAAAIIOOUU’);

Sous Informix, il est possible de passer par le « MATCHES » et les regexp.

SELECT * FROM TABLE
WHERE UPPER(monChamp) MATCHES ‘*R\[EÉÈÊËéèêë\]Q\[UÛÜûü\]\[EÉÈÊËéèêë\]T\[EÉÈÊËéèêë\]S*’;

Après un «MATCHES», il est possible d’utiliser les symboles suivants :

  • * : représente une chaîne de 0 ou plusieurs caractères
  • ? : représente un seul caractère
  • […] : contient un ensemble de caractères

Sous Postgresql, la solution passe par l'utilisation du « SIMILAR TO » et des regexp.

SELECT * FROM TABLE
WHERE UPPER(monChamp) SIMILAR TO ‘%R\[EÉÈÊËéèêë\]Q\[UÛÜûü\]\[EÉÈÊËéèêë\]T\[EÉÈÊËéèêë\]S%’;

En résultat de requête, nous aurons bien toutes les lignes contenant ‘requete’ sans tenir compte de la casse et/ou des accents :

  • requete
  • requête
  • REQUETE
  • REQUÊTE
  • ...