Blog Objet Direct

RIA Services pour Silverlight 4 est disponible ici

Brad Adams décrit quelques fonctionnalités dans son annonce.

• 

3 nouveaux événements techniques organisés et animés par Objet Direct, en avril : « Enterprise Architect, outil stratégique du dialogue entre le métier, l’IT et les applications »
… Pour des modèles UML utiles, à jour et partagés.

Quels sont les scénarios qui favorisent une utilisation pragmatique des modèles au sein des projets, petits, grands, agiles ou en cascade ? Quels sont les atouts d’Enterprise Architect ?
Réponses et démos lors de ces séminaires Objet Direct, avec les retours d’expérience projets menés chez PSA, EDF, au Conseil d’Etat et au CHU de Grenoble.

=> le 7 avril à Lyon, le 8 avril à Grenoble, le 14 avril à Paris, 9h-11h (accueil petit déjeuner)
Evénements gratuits, sur réservation ferme.
En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

• 

Un tout nouveau « user group », pour rassembler les utilisateurs du langage Scala : le Paris Scala User Group organise des rencontres périodiques pour partager expériences, idées, projets ou connaissances.

• 

Un an après la sortie de la première version, ASP.NET MVC est disponible en version 2.

ASP.NET MVC propose une alternative aux WebForms suivant une architecture MVC. Cette approche a des avantages et des inconvénients  : on aime ou n’aime pas. Personnellement, je n’adhère pas à l’approche helper qui mélangent des balises ASP.NET dans le code Html. Néanmoins, une des fonctionnalités de la version 2 mérite attention : les helpers sont maintenant typés et l’on peut utiliser des expressions lambda à la place des magic string.

En ASP.NET MVC 1, pour définir un champ input lié à une propriété Nom d’un modèle , on avait quelque chose de ce genre:
<%= Html.TextBox("Name", Model.Name) %>

Pour le même résultat en ASP.NET MVC 2, on utilise
<%= Html.TextBoxFor( m => m.Name) %>

L’annonce de Scott Guthrie.

• 

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 …

•