Blog Objet Direct

Cet article est un résumé de la première soirée du Domain Driven Design Users’ Group Paris (lancé le 17 février dernier), avec une présentation de Greg Young sur le « Command and Query Responsability Segregation ».
Greg Young commence à nous présenter une architecture très classique dans les développements actuels.

L’ensemble de cette architecture se base sur une omniprésence de Data Transfert Objects sur l’ensemble des couches. Le comportement de l’application se retrouve dans le client. La montée en charge de l’application est très vite reportée sur la base de données. De plus on arrive très vite à parler avec des verbes techniques (Request DTO, Send DTO). Il n’y pas de modèle du domaine.

La première étape est de faire la transition entre les deux schémas ci-dessus. Le client ne doit plus travailler uniquement avec des DTOs.
Il doit communiquer au client avec le serveur à travers des commandes. Le service applicatif gère l’objet du domaine.
Cet objet encapsule son état et offre des comportements. On peut ainsi remettre en place les cas d’utilisation ou « user stories ».
L’étape suivante consiste à séparer l’écriture de la lecture car ces deux chemins représentent deux cas d’utilisation différents, avec leurs propres contraintes et besoins.

Dans le cas de la lecture, il est intéressant de remplacer l’accès à la base de données par un accès rapide et simple à la base de données (direct to DTO). Il reste maintenant le problème de la base de données. Avoir une seule base de données pour les deux cas d’utilisation est une solution simple dans le cas d’un système existant.
Cependant dans la majorité des applications (sauf peut-être certains systèmes financiers), il y a énormément plus de lecture que d’écriture. Il peut être alors très intéressant d’avoir deux bases de données avec un système de duplication maintenant la consistence des données entre les deux bases.

La base de données en écriture peut être normalisée et la base en lecture dénormalisée.
C’est une très bonne solution quand on pense au problème des rapports qui sont faits sur les bases.

La soirée du Paris JUG a commencé par une présentation de JDuchess : communauté féminine autour de Java. Il s’agit d’un groupe international qui a été fondé en Hollande.

Ensuite, la soirée « Emmanuel Bernard » s’est déroulée en deux parties : la première sur Hibernate Search et la seconde sur le design des APIs.

Première partie : Hibernate Search : recherche full-text pour des applications utilisant Hibernate.

Pour la recherche, il existe plusieurs modules de recherche full-text (par exemple avec SQL Server). Cependant, il n’existe pas de standard sur ces modules de recherche. Une autre solution pour réaliser de la recherche full-text est d’utiliser une librairie. Hibernate Search est basé sur  « Lucene », il permet de réaliser une recherche full-text avec les caractéristiques suivantes :

• ordonne les résultats, les documents les plus pertinents seront dans les premiers résultats.

• tolère les fautes de frappe ou orthographiques

• on peut donner des priorités aux différents champs

La recherche full-text va s’appuyer sur un analyseur et plusieurs filtres. Parmi les filtres, on peut mettre tout en minuscule (recherche insensible à la case), enlever certains mots (le, la les).

Il y a plusieurs techniques qui permettent de comparer deux mots et donc qui permettent une recherche :

• Recherche par approximation avec le calcul de distance de Levenshtein (distance entre deux mots). Si entre deux mots, 1 seule lettre change => bonne distance.

• Recherche N-gram : cette technique permet de tolérer les fautes de saisie de l’utilisateur. Par exemple, au lieu de rechercher Hibernate, on découpe le mot en fragments de 3 lettres : Hib, ibe, ber et on recherche ces fragments … (le nombre de lettres du fragment est configurable).

D’un point de vue technique :

• L’annotation @Indexed mise sur une entité permet de l’indexer en full-text. L’index sera mis à jour pour toute modification de l’entité.

• L’annotation @Field crée un champ de recherche dans Lucene

Remarque : La recherche full-text se réalise uniquement sur du texte, des chaînes de caractères, Hibernate Search possède donc ses propres convertisseurs (date…)

Il est possible d’utiliser l’annotation @Fields qui permet de définir plusieurs types de recherche sur le même attribut. Il est possible de pondérer les différents critères. Par exemple, un mot trouvé dans un titre aura une meilleure pertinence que le même mot trouvé dans la description.

• Recherche phonétique : prendre un mot et réaliser de la réduction phonétique (métaphone ou double métaphone, bien adapté aux langages latins).

• Recherche de synonymes : on n’indexe pas le mot lui-même mais un mot de référence. Par exemple, pour like, cherish, le mot de référence sera love. On crée alors un sous-ensemble de la langue

• Recherche par mots de la même famille (loving =>love) : on réduit un mot à sa racine. Le docteur Porter a écrit un algorithme sur ce principe appliqué à la langue anglaise (langage snowball). Ce dernier type de recherche est présent dans Hibernate Search, il s’agit de l’analyseur stem.

Astuce : il peut être judicieux de mettre plusieurs fields sur le même attribut pour pouvoir ajuster la pondération même en production.

Conclusion : Lucene est assez bas niveau, il peut donc être assez complexe à utiliser. Hibernate search est plus facile à mettre en place et permet de se concentrer sur le moteur de recherche.

Deuxième partie : Design d’API

Cette partie nous a exposé les bonnes pratiques pour faire de bonnes API (donc qui seront facilement utilisables par un maximum de personnes).

• Tout d’abord, faire des APIs prend beaucoup de temps et aboutit à un produit qui ne satisfera jamais entièrement tout le monde.

• Pour une API, il est préférable d’exposer que quelques méthodes (5 par exemple)

• Il est bien que l’API couvre 80% des cas (les cas les plus fréquents) et si besoin qu’on puisse l’étendre pour des demandes bien spécifiques.
• Une API doit être lisible et compréhensible de tous.
• Une citation prise du snowboard et adaptée à la réalisation d’API : « If you don’t fall, you don’t make progress »
• Utilisez l’API pendant que vous la développez
• Pensez au-delà du code, la sémantique est très importante
• Pour les méthodes, trouver un nom court et explicite

Bon pattern : method chaining pattern. La méthode renvoie l’objet lui-même, on peut donc appeler des méthodes à la chaîne.

Conclusion : pour une API, rendez les choses difficiles pour vous et simples pour les autres. Pour faire de bonnes APIs, il faut essayer et réessayer, penser aux utilisateurs et au futur de l’API.

Merci à Emmanuel Bernard pour cette soirée riche en enseignements. Une bonne présentation illustrée par de nombreux exemples de code et de démonstrations. Pour en savoir plus sur lui : http://blog.emmanuelbernard.com

Pour en savoir plus sur cette soirée, et si vous avez un compte google wave, une wave détaillant la dernière soirée du Paris JUG est accessible ici.

Introduction à la programmation sur iPhone

Partie 1. Langage, interface & contrôles standards

Avec l’App Store, première boutique d’applications tierces sur mobile, l’iPhone d’Apple a donné un joli coup de pied dans la fourmilière de la mobilité. Bien que faisant partie du paysage depuis 2 ans et 100000 applications, son retentissement ne semble pas vouloir s’estomper.

Cela est du, en partie, à la pertinence des choix techniques et des outils – Objective-C et Cocoa Touch – retenus pour son développement. Conscients de l’impact avec lequel il a durablement changé la donne, nous consacrerons ici une série d’articles techniques permettant de s’y acclimater progressivement.

Le premier article sur le sujet – Partie 1. Langage, interface & contrôles standards – est disponible sur le wiki et en pdf.

Je continue mon tutorial sur soapUI. Voyons cette fois-ci comment utiliser soapUI pour réaliser des tests de charge.

Il faut ajouter un nouveau test de charge sur le TestCase voulu.
Note: il faut savoir que le test de charge va lancer tous les tests en parallèle, donc il ne faut pas qu’il y a de dépendance entre les services du TestCase, car ceci pourrait fausser vos résultats.

Une fenêtre s’ouvre, il est possible de choisir la stratégie de test et de la configurer.
A savoir : la durée du test, le nombre de threads à utiliser, le délai (aléatoire ou non) entre chaque nouvelle requête, etc.

Sur cette image on peut se rendre compte qu’un service qui renvoie une stacktrace d’exception est couteuse en temps et en données.

Le tableau de résultat affiche : le temps de réponse min max moyen, le nombre de requêtes totales lancées lors du test, le total de données transférées, le nombre d’erreur.

De plus, la console de log en dessous permet d’avoir des détails sur les tests déroulés, comme l’heure de début et de fin du test, les éventuelles erreurs, etc …

Après le lancement du Domain Driven Users’ Group Parisien avec Eric Evans le 17  février dernier,  Grégory Weinbach et Jérémie Grodziski organisent une 1ère rencontre le 3 mars à 19h,  à la Cantine.

La réunion se déroulera en deux parties : une présentation de Greg Young suivie d’un « Design Dojo » (atelier pratique).

Inscriptions obligatoires (places limitées).

Cette réunion est sponsorisée par Objet Direct et Zenika.

L’inscription au groupe est gratuite !

C’est bientôt le troisième mardi du mois.
OK, rien d’extraordinaire : c’est le cas tous les mois depuis que Dieu a créé la Terre en 7 jours (alors qu’Il a mis grosso modo 4,54 milliards d’années pour créer Java, c’est dire le niveau de maturité du truc).
Mais tous les troisièmes mardi du mois, c’est une nouvelle soirée au Lyon JUG, dont Objet Direct est un tout récent nouveau sponsor platinium.

Ce mardi 23 février, soirée JavaEE6, animée par Antonio Goncalves : pas moins qu’un Java Champion qui participe aux JSR des APIs Java EE 6, écrit des livres de référence sur JavaEE, et a accessoirement fondé le Paris JUG, premier JUG en France. Il continue sa tournée, après son passage à l’Alpes JUG.
Certes, ce n’est pas Dieu (Il demandait trop cher pour intervenir), mais on devrait donc pouvoir s’attendre à des informations plutôt pertinentes.
Inscription et détails pratiques : sur la page officielle, as usual.

A fouiller la multitude de blogs des équipes Microsoft (en passant voici un bon point de départ) on trouve des choses intéressantes.

Comme ce lien vers le blog de Mike Taulty qui fournit une présentation très complète de Silverlight (incluant les features de la v4) en 77 slides très bien fait.

Téléchargement direct des slides (format zip puis pptx, ~12 MO)

Le Alpes JUG (Java User Group)  consacre sa première soirée au Java EE 6.

Elle se déroulera le lundi 22 Février 2010 à UFR IMAG 60, rue de la Chimie dans l’amphithéatre F018  (Domaine universitaire de Saint-Martin d’Hères et Gières, à côté de Grenoble)

Détails pratiques et inscriptions sur la page officielle.

Au sein du groupe Objet Direct est né un laboratoire de nouvelles technologies : OD Labs. L’objectif de ce dernier est d’être un pôle d’innovation, mais aussi de soutenir des projets innovants dont l’un d’entre eux se nomme wiQuery.

wiQuery est un projet OpenSource (régi sous la licence MIT), qui se propose de coupler et de faciliter l’utilisation de Wicket avec jQuery afin d’obtenir des composants et des comportements riches, mais aussi d’offrir des composants Wicket couplés avec jQuery UI et de pouvoir insérer les plugins jQuery existant.

Introduction

Pourquoi jQuery ? Tout simplement parce que c’est un framework javascript qui est simple d’utilisation, performant, et aussi non intrusif. De plus, de très nombreux plugins sont issus de ce framework, notamment jQuery UI, qui propose des composants, des effets et des comportements très intéressants (encore plus dans la prochaine version).

Quelques composants riches

Si nous voulions intégrer un plugin jQuery dans Wicket, que nous faudrait-il faire ?

1. Importer les ressources javascripts et CSS liées à ce plugin
2. Générer / écrire du code javascript / jQuery afin de pouvoir exécuter le plugin
3. Ecrire le code Java / Wicket, ainsi que le fichier XHTML lié.

wiQuery se propose de s’occuper des deux premiers points, de faciliter l’écriture du code Wicket mais aussi de générer et d’injecter le code javascript au bon moment, à savoir soit au chargement de la page, soit lors d’une transaction Ajax.

Structure de wiQuery

La base de wiQuery se constitue d’un générateur de code jQuery, qui permet ainsi à la mécanique de plugin de les utiliser dans des composants ou des behaviors Wicket. Ce système de plugin a permis d’insérer tous les composants, effets et comportements actuels de jQuery UI et permet également d’intégrer n’importe quel plugin jQuery et d’y accéder via Wicket.

Le générateur de javascript / jQuery

Le générateur code se divise en trois grands types d’objets :

• JsStatement : C’est le type principal. Il a pour but de chainer des portions de code javascript et offre des méthodes afin d’écrire de manière simplifiée et guidée du code jQuery.
• JsQuery : Cet objet se base sur l’élément précédent afin de créer un sélecteur jQuery à qui nous pouvons chainer des méthodes et des arguments.
• JsScope : Cet objet a pour but de créer une fonction (closure) javascript.

Ainsi, pour générer le code jQuery suivant pour l’appliquer sur un composant Wicket :

Il nous suffit de taper le code wiQuery suivant :

Petite remarque tout de même : il est utile d’utiliser ce générateur dans le cas où nous voulons générer des petites portions de code Javascript / jQuery. Si votre objectif est d’intégrer un plugin de votre composition, il vaut mieux écrire le fichier .js et l’importer en tant que ressource wiQuery.

Comment intégrer wiQuery ?

Il existe deux moyens simples d’intégrer wiQuery à son application Wicket :

1. Hériter de la classe WiQueryWebApplication,
2. Si le point précédent ne vous est pas possible, il suffit dans la méthode init() de votre classe Application d’insérer le bout de code suivant, activant ainsi pleinement wiQuery :

Evénements Javascript

Le framework wiQuery vous permet de coupler vos composants Wicket à des événements Javascripts. Dans un premier temps, nous pouvons juste exécuter du code javascript simple, côté client :

Dans un second temps, l’événement javascript peut effectuer une transaction Ajax, afin de pouvoir exécuter un traitement côté serveur :

wiQuery UI

Comme dit plutôt dans cet article, wiQuery a intégré le framework javascript jQuery UI. Ainsi, nous pouvons disposer en Wicket des composants suivants :

• Un accordéon
• Une fenêtre de dialogue
• Un slider
• Une barre de progression
• Des onglets
• Un datepicker

Pour ce qui concerne les behaviors Wicket, nous avons les comportements suivants :

• Draggable
• Droppable
• Sortable
• Resizable
• Selectable

Il est à noter que ces derniers peuvent s’utiliser de deux manières : soit de manière classique, activant ainsi le comportement, soit de manière Ajax. Dans ce dernier cas, selon le comportement, des événements importants pourront être relevés et transmis via Ajax. Ces événements seront répercutés directement dans votre code Wicket. Par exemple sur le comportement « Droppable », nous aurons un événement levé et dans la méthode wiQuery « onDrop » (que vous aurez à déclarer), le composant Wicket qui aura été déposé dans la zone de drop sera fourni.

Créer ses plugins

wiQuery est un framework d’intégration. De ce fait, il permet d’élaborer des plugins wiQuery et de les intégrer / exécuter au sein du framework. C’est ainsi qu’a été intégré le plugin jQuery UI.

Pour cela, vous avez accès :

1. A l’interface IWiqueryPlugin qui vous demandera d’implémenter deux méthodes. L’une demandant de charger les ressources Javascript et CSS de votre plugin. L’autre demande de générer le code Javascript / jQuery pour faire fonctionner le plugin. La présence de cette interface permet de charger automatiquement le cœur de jQuery.
2. A l’annotation @WiqueryUIPlugin. Elle permet d’indiquer à wiQuery qu’il faut le cœur de jQuery UI ainsi que le thème jQuery UI.

De ce fait, si nous voulions écrire un plugin pour faire marcher le Slider jQuery UI (déjà présente dans l’API), il nous suffirait de taper le code suivant :

Appliquer des thèmes

Des thèmes (issues de jQuery UI) peuvent être appliqués sur les composants et behaviors wiQuery UI. Pour cela, rien de plus simple, il suffit d’implémenter sur votre classe d’application Wicket l’interface IThemableApplication :

De plus, il possible d’appliquer des parties de ces thèmes sur des composants Wicket non issus de wiQuery. Par exemple, vous avez un bouton, et vous voulez qu’il reprenne le style du thème en cours, il vous suffira de faire :

L’avenir de wiQuery

A l’heure actuelle, la version de wiQuery est la 1.0, et se base sur Wicket 1.4.3, jQuery 1.3.2 et sur jQuery UI 1.7.2. Tous les composants de jQuery UI ont été intégrés, une mécanique de génération de javascript a été mise en place et un système permet d’appliquer les thèmes. De plus, une petite communauté se forme, et sur le site de wiQuery, vous pourrez trouver des vidéos d’aide et une application de démonstration, où pour chaque exemple, vous avez le code Java / XHTML.

La prochaine mouture de wiQuery est la 1.1. Elle s’efforcera de monter les nouvelles versions des différents frameworks utilisés: jQuery 1.4, jQuery 1.8 (avec les nouveaux composants,) et Wicket 1.4.6. L’objectif sera également de renforcer la communauté wiQuery, de fournir plus de documentations, de vidéos, d’exemples, mais surtout de mettre en place une communauté de plugins wiQuery (dont certains seront développés par l’équipe de wiQuery)  que vous pourrez ainsi télécharger et utiliser au sein de vos applications Wicket.

La mouture wiQuery 1.2 quant à elle comprendra la possibilité d’utiliser les IModel de Wicket comme options aux composants wiQuery. Elle s’efforcera également de préserver l’état des composants côté serveur et aussi de proposer des composants wiQuery UI plus poussé.

Je (Grégory Weinbach) m’associe avec un autre féru de modélisation de Domaine, Jérémie Grodziski, pour initier un groupe d’utilisateurs du Domain Driven Design sur Paris.

Le Domain Driven Design (DDD) est une approche de la conception de logiciel dont les principes fondateurs sont :

• Le point d’attention principal doit être le domaine et sa logique,
• La conception de domaine complexe doit être basée sur un modèle.

Le Domain Driven Design n’est pas une technologie ni une méthodologie. C’est une manière de penser et un ensemble de priorités, dont l’objectif est d’accélérer la réalisation des projets qui gèrent des domaines complexes.

L’idée est de faire vivre une communauté, d’échanger sur le sujet, et en particulier de partager des retours d’expérience concrets.

Une rencontre sera organisée tous les deux mois, associée à un atelier ou à une présentation plus formelle.

Le lancement officiel du groupe se fera à l’occasion de la venue en France d’Eric Evans, créateur et pape du DDD lors d’une conférence gratuite (inscription obligatoire) qu’il animera le 17 février sur les “Modèles en action”.

L’inscription au groupe est gratuite. Un site plus complet sera bientôt disponible sur le sujet.

Longue vie au DDDUG (prononcez Didideug) Paris !