3 nouveaux séminaires techniques organisés et animés par Objet Direct, en mai et juin : « L’agilité : innovation utile au business ! » avec le retour d’expérience d’une grande banque d’investissement.

Ce séminaire se propose de vous faire découvrir concrètement le quotidien d’une équipe agile, à travers l’illustration par des projets réels réalisés pour une grande banque d’investissement. Nous aborderons dans ce séminaire les difficultés rencontrées et des solutions pour les surmonter.

=> le 31 mai à Grenoble, le 31 mai à Lyon, le 19 juin à Toulouse, 8h30-12h (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.

Lors de cette soirée, le speaker, Régis Médina qui est l’un des pionniers de l’agile en France a animé la conférence : « Software kaizen : le lean pour améliorer la satisfaction des utilisateurs”.

Voici ce que j’ai retenu de cette soirée :

Régis Médina nous a montré comment appliquer les principes du Kaizen pour améliorer en continu le niveau de satisfaction du client.

Le constat :

Les pratiques agiles préconisées dans XP ou SCRUM visent à améliorer de façon continue le processus de développement. Les équipes progressent d’itération en itération pour livrer de plus en plus rapidement des fonctionnalités bien codées (code simple, maintenable et testé). Coté client, il est prévu une implication en continu afin de fournir des besoins priorisés et réceptionner les livrables en fin de chaque itération. Pour SCRUM, une démo est prévue en fin de sprint. L’équipe présente alors les nouvelles fonctionnalités au client. Celui-ci fait des retours et exprime sa satisfaction. On pourrait croire que ce fonctionnement agile permet de satisfaire complètement le client. Ce n’est en fait pas le cas. Ecouter le client ne suffit pas. Avoir un bon Product Owner non plus.

L’utilisation du Software Kaizen :

Le Software Kaizen propose le cycle d’amélioration inspiré de la roue de Deming qui est une illustration de la méthode de gestion de la qualité dite PDCA (Plan-Do-Check-Act).

1 – La voix du client

• donnez-moi ce que j’attends
• quand je le veux
• où je le veux
• soyez fiables
• ne me faites pas perdre mon temps

Seul le premier point de cette liste concerne l’apport de valeur. Les autres points sont du gaspillage à éviter (le lead time). La réduction de ce gaspillage d’utilisation nécessite un changement de logique : il faut passer de Ajouter des fonctionnalités rapidement à Résoudre efficacement les problèmes du client.

2 – Mesurer la performance en mettant en place des indicateurs

• mesure de la satisfaction client
• mesure de la qualité (requêtes support, réclamation, signalement de bugs…)
• mesure du lead time

3 – Voir les problèmes

Cet exercice est difficile car l’équipe projet à l’handicap du savoir pour résoudre correctement les problèmes du client. Elle en sait trop sur le produit et pas assez sur le métier. Régis Médina qualifie ce handicape de double malédiction.

Il propose d’aller sur le terrain à la rencontre de l’utilisateur (démarche GO&SEE – Genshi Genbustu).

Il faut aller s’assoir à coté de l’utilisateur final et lui demander de penser tout haut en manipulant l’application. Il ne faut rien lui dire de plus. Il reste à apprendre à repérer les gaspillages et les obstacles (surproduction, attentes, transports de données, traitements inutiles, ressaisie de données, conversion, les tâches en attente, les mouvements inutiles, les corrections…).

4 – Résoudre les problèmes

Parmi tous les points de gaspillages relevés, il faut sélectionner les trois les plus importants et intégrer à l’itération suivante des évolutions correctives et expérimenter de nouveau.

5 – Apprentissage

Ce point est principalement constitué d’une montée en compétence sur le métier et sur les contraintes des utilisateurs.

A expérimenter le plus vite possible…

Le jeudi 19 Avril 2012, j’ai eu la chance de pouvoir présenter un « quickie » (présentation qui dure environ une quinzaine de minutes) à la première édition de Devoxx France, qui a lieu au Mariott Hotel à Paris.

Je vous propose ci-dessous une synthèse de ma présentation « Sexy, le développement Web mobile ? »

Commençons par un constat :

On estime que la moitié des connexions à l’Internet se feront à travers nos smartphones d’ici 2014. En début d’année, Twitter a déclaré que 30% des tweets se font à travers les smartphones, et 18% uniquement via le site Web Mobile.

Ainsi, il est devenu important, et même vital, d’être visible et présent sur le monde de la mobilité. On ne peut s’y tromper : 70% des entreprises ont soit une application mobile, soit une application en cours de développement ou envisage d’en avoir une.

A l’heure actuelle, les entreprises ont le choix principalement entre

• le développement d’applications natives (pour iOS, Android, Blackberry),
• le développement Web Mobile (se basant sur les technologies Web modernes comme HTML5 et CSS3)
• ou encore le développement Web Mobile hybride (qui fait le pont entre les deux univers précédents, le framework phare étant Cordova, le nouveau nom de PhoneGap).

Il existe d’autres approches, mais elles restent « exotiques ».

Quels sont les avantages du natif ?

Le développement natif permet tout d’abord, l’accès aux couches basses  du smartphone (SMS, répertoire, etc.) ce que ne permettent pas les autres approches.

Chaque plateforme (iOs, Android, …) propose ensuite un ensemble d’outils / environnements de développement propre facilitant la conception et la réalisation d’applications très performantes.

Enfin l’approche native offre la possibilité de publication de son application au travers des « markets » (Apple store, android market) permettant ainsi sa diffusion à large échelle.

Par contre cela implique de développer la même application pour chaque plateforme cible, soit à minima 3 versions différentes (Android, iOs et BBY) afin d’adresser 95% du marché des smartphones et tablettes, ce qui coûte bien évidemment du temps et de l’argent, et amène le problème des ressources.

En effet, pour le monde Android et Blackberry, un profil de développement avec des compétences Java pourra prendre en main rapidement ces environnements, tandis que poir iOS, les compétences restent rares, et la montée en compétence est reconnue comme longue et douloureuse.

            

Le web mobile

Premier avantage : plusieurs plateformes sont ciblées ce qui permet une réduction des coûts. Il y aura cependant des adaptations à faire, notamment en ce qui concerne les IHM et le code. Mais étant donné qu’on est dans le monde du Web, on est habitué à faire des adaptions, pour les différents navigateurs et leurs différentes versions. Ainsi, on peut toujours espérer avoir un code commun à plus de 95%.

Les performances du Web Mobile sont vraiment correctes. Quand j’ai écrit ma première application il y a de cela 2 ans, j’ai été bluffé par la vélocité (je m’attendais à ce que ce soit très lent, car j’avais un très grand nombre de fichiers JavaScipts). Grâce à HTML5 et CSS3, l’interaction avec le smartphone et l’utilisateur est plutôt bonne, avec une IHM professionnelle (je peux citer le site du New York Times, qui est fait en CSS3 et qui est bluffant).

En revanche, il n’est pas possible de créer des applications nécessitant de hautes performances, comme pour la réalité augmentée. On ne peut pas accéder à toutes les couches basses. Et l’ergonomie n’est pas à 100% en adéquation avec la plateforme (ce qui est normal vu que nous faisons une application pivot).

Pourquoi alors je considère que le développement Web Mobile est sexy ? D’une part, on trouve des moteurs Web modernes et performants (pour être plus précis, on trouve Webkit !). Pour rappel, le premier moteur Web HTML5 se trouvait sur un smartphone, et plus précisément sur un iPhone … en 2007 !! Alors qu’il faudra attendre plusieurs mois encore avant de voir en apparaitre un sur Desktop. La compatibilité HTML5 et CSS3 est très bonne. Il faut juste s’assurer que les fonctionnalités ont été activées. Par exemple, WebSocket n’est pas accessible sous Android alors qu’il l’est sur iOS et Blackberry.

Une communauté de plus en plus forte s’est formée ces dernières années, autour de nombreux sites dédiés à ce sujet, comme html5rocks.com, qui fût le premier site à expliquer HTML5 et à donner des tutoriaux. Je regarde régulièrement ce site qui reste pour moi une bible.

Et tout cela s’articule autour de technologies adaptées et en évolution que sont HTML5 et CSS3. Le terme « évolution » est important ici, car si on va voir sur le site du W3C, ces deux technologiess sont encore en état de brouillon. Pour CSS3, c’est quasi-finalisée. Pour HTML5, de nombreuses fonctionnalités sont proposées de mois en mois. Par exemple, courant 2011, une API a été proposée pour accéder à la liste des contacts du téléphone. Début 2012, une autre proposait de faire vibrer le téléphone. Ainsi, le Web Mobile mute de plus en plus afin de pouvoir mieux s’intégrer à nos smartphones.

          

De plus, il est possible de faire du Web Mobile hybride ! Cela consiste à embarquer nos fichiers HTML5, CSS3 et JavaScript au sein d’un wrapper natif. Cela permet non seulement d’être présent sur les markets, mais aussi de faire un pont entre nos pages Web et le natif. On peut imaginer de pouvoir lister nos SMS sur une page Web en communiquant via JSON au natif qui lui va s’occuper de chercher les dits SMS.

Techniquement, que devons-nous utiliser ?

Pour commencer, on aura besoin d’HTML5, de CSS3 et de JavaScript. Mais il ne faut pas perdre de vue que le W3C propose des fondations ! Ainsi, on ne trouvera pas de base des widgets fancy ou sexy. On va donc utiliser des frameworks JavaScripts adaptés, comme jQuery Mobile de « The Filament Group » (que j’utilise massivement) ou encore la solution payante qu’est SenchaTouch de Sencha Labs.

          

Il existe deux frameworks assez récents qui sont prometteurs, et les deux se basant sur jQuery. Le premier est KendoUI (solution payante) qui propose des widgets assez puissant, basé sur HTML5/CSS3, qui rivalisent vraiment avec ceux de jQuery UI. Il s’adapte également pour le Web Mobile, notamment sur le style d’affichage très proche de la plateforme où le site s’affiche. Ensuite, on trouve Bootstrap, par l’équipe de Github, qui propose un framework léger, simple à utiliser et surtout Design Responsive. Un framework vraiment prometteur.

           

Si on souhaite faire du Web Mobile hybride, on va utiliser un framework comme Apache Cordova (anciennement, PhoneGap), qui propose des enveloppes natives pour de nombreuses plateformes (comme iOS, Android, Blackberry, Windows Phone 7, Bada …) et aussi une API JavaScript permettant d’accéder à une partie des couches basses. Cette API va être fortement enrichie dans sa version 2.0, et il est à noter que ce framework propose un système de plugin. Personnellement, j’ai écrit un petit plugin Android pour dialoguer avec l’application native Twitter, et j’ai pu le faire simplement grâce à cela.

     

Néanmoins, il faut faire attention lorsqu’on utilise le Web Mobile. D’une part, il faut se forger une expérience Web Mobile. Il faut évidemment apprendre de nouvelles technos/frameworks, mais également prendre en compte des problèmes qu’on a l’habitude mettre de côté, comme la taille de l’écran, bien plus petite que nos écrans de bureau (la norme maintenant est 1024 par 768, mais on estime que la prochaine norme sera la taille d’une tablette, voire d’un smartphone), ainsi que le débit du réseau (la 3G ne rivalisant pas avec la fibre d’entreprise).

De plus, il faut s’assurer de l’adéquation entre le besoin et la solution. Si votre client souhaite une ergonomie parfaitement en adéquation avec la plateforme, ou de hautes performances, le Web Mobile n’est pas fait pour vous.

Néanmoins, celui-ci peut répondre à plus de 85% des besoins qu’on peut rencontrer. Ainsi, selon moi, il ne faut pas hésiter à sauter le pas car le Web Mobile à mes yeux a un avenir prometteur et va dans le bon sens. Et je n’hésite pas dire que le développement Web Mobile est sexy !

Vous pouvez consulter les slides de ma présentation sur le lien suivant:

SysML, le langage de modélisation OMG basé sur UML et adapté à l’ingénierie système, est actuellement en version 1.3 bêta. Cette version devrait être officielle au mois de Juin.

SysML 1.3 apporte de nombreux changements à la définition des ports, points d’interactions sur les Blocs. Pour rappel, SysML 1.2 intègre les ports standards pour exposer des interfaces, et les ports de flux (flow ports) pour représenter ce qui peut circuler en entrée et/ou en sortie d’un bloc, que ce soit des données, de la matière ou de l’énergie.

Les “flow port” et les “port specifications” de SysML 1.2 ont été abandonnés dans la version 1.3, mais leurs concepts ont été conservés. Les changements apportés dans la version 1.3 portent sur la définition et l’implémentation de ces concepts, qui se résume de manière non-exhaustive par les points suivants :

• Ports complets (full ports)
  • permet de représenter une partie intégrante du bloc sur la frontière du bloc principal (main block boundary)
  • un port complet est typé par un bloc; il peut ainsi combiner les flux d’éléments en entrée/sortie et l’exécution d’opérations, remplaçant respectivement les flow ports et les ports standards de SysML 1.2
  • les interfaces ne sont alors plus exposées sur le port, supprimant l’utilisation de la notation lollipop
  • les ports complets peuvent être « conjugés » comme dans les flow ports de SysML 1.2 ayant pour effet d’inverser la direction des éléments ; cela a le même effet sur les opérations i.e. les opérations fournies par le bloc sont alors des opérations requises

• Ports proxy
  • sert de proxy aux fonctions du bloc principal ou de ses parties intégrantes
  • un port proxy ne porte pas de comportement, ni ne constitue une partie du bloc principal
  • les flux d’éléments ou l’exécution d’opérations sur le port proxy sont transmis directement vers le bloc principal ou une partie intégrante
  • un port proxy est typé par un bloc d’interface (block interface) pour spécifier les fonctions disponibles (éléments, opérations), alors que les ports complets comme indiqué précédemment sont typés par des blocs

• Ports et flux imbriqués (nested ports & flows) : SysML permet de définir des ports imbriqués ; pour cela le bloc utilisé comme type du port possède lui-même des ports

• Blocs d’association : ces blocs permettent de définir la compatibilité entre ports de blocs différents

En conclusion
SysML 1.3 propose une implémentation et une approche plus complète que la version 1.2 actuelle pour gérer la notion de ports, flux et connecteurs sur les Blocs. Il évite par exemple la duplication de ports si l’on a besoin de définir un port pour transmettre des éléments et fournir des opérations.
Ce changement pourrait avoir un impact non négligeable dans l’organisation du modèle comme l’on ne va plus exposer les interfaces sur un port. Par exemple, il semble que ce sera le bloc, utilisé comme type du full port, qui va réaliser les interfaces du modèle (dans le cas où un référentiel d’interfaces existe). Si un bloc doit appeler des opérations d’un autre bloc, on remplacera donc le lien entre deux interfaces required/provided de SysML 1.2, par le lien entre un full port et son inverse (full port du même type mais conjugué).
La seconde édition du livre “A Practical Guide to SysML” de Sanford Friedenthal (consultant MBSE et membre de l’OMG),  Alan Moore, et Rick Steiner est déjà disponible et intègre SysML 1.3 (cf. chapitre 7.6) ; ce livre fournit ainsi des exemples concrets sur l’utilisation de full ports, proxy ports, interface blocks, etc.
Lorsque le langage SysML 1.3 sera officiel, il sera intéressant de voir si les éditeurs d’outils de modélisation SysML tel que Sparx Systems (Enterprise Architect) auront intégrés ces nouveaux principes par une utilisation simple (par exemple pouvoir changer facilement une partie intégrante en ‘full port’ par le choix de la porter sur la frontière du bloc).

Afin de cibler un public plus large – généralement iOS et Android – nombre d’entre nous avons décidé de nous lancer dans la création d’applications Web mobile.

L’outillage est souvent vu par les développeurs comme un point faible du Web Mobile par rapport à des approches de développement plus traditionnelles : Objective C ou Java. Comment par exemple déboguer et analyser une application qui s’exécute sur le mobile ?

En effet, bien que les smartphones et les tablettes utilisent très massivement le moteur de rendu Webkit (à l’exception de Windows Phone), ces derniers le configurent de manière différente. Ainsi, certaines fonctionnalités de HTML5/CSS3 sont désactivées, ou encore le comportement des pages peut varier.

Pour ma part, avant d’utiliser Weinre, je commençais par tester mon application dans Google Chrome en mode non sécurisé (désactivation de la sécurité cross-domain, accès aux fichiers locaux) et  en exploitant les nombreux outils et plugins de Chrome. Pour avoir la sensation d’être sur un mobile, j’incorporais mon application dans un template représentant un smartphone.

Enfin, je terminais mes tests en lançant l’application sur les différents émulateurs et simulateurs. Néanmoins, quand l’affichage n’était pas satisfaisant, j’étais obligé de modifier HTML, CSS et JavaScript souvent en tâtonnant et de recommencer les tests jusqu’à trouver la solution : ce qui était long et fastidieux.

Heureusement pour nous, un outil vient nous aider : Weinre !

Cet outil est intégré dans la solution Cloud de PhoneGap. Il permet d’analyser son application Web à distance ! Et cela très facilement ! Pour cela, rien de plus simple, télécharger le projet puis taper la commande suivante :

java -jar "DIRECTORY_PATH\weinre.jar" -httpPort 8081 -boundHost -all-

A partir de là, vous pouvez ouvrir sur votre navigateur de bureau deux liens :

• http://127.0.0.1:8081/
  • Lien principal détaillant la marche à suivre

• http://127.0.0.1:8081/client/
• Lien permettant de voir vos pages actuellements utilisées sur les smartphones et tablettes

Ensuite, il suffit d’ajouter ce bout de script en bas de votre page HTML (dans le tag BODY, évidemment) :

<!– —————————————————————— –>

<!– ————————– Weinre Part ————————— –>

<!– ——————— For debugging —————————— –>

<script type= »text/javascript » src= »http://youripaddress:8081/target/target-script-min.js#anonymous »></script>

<!– —————————————————————— –>

Et voilà ! Désormais, c’est à vous de jouer !

En vous rendant sur le lien http://127.0.0.1:8081/client/, vous ferez alors une liste de liens. Elle correspond aux pages qui se sont connectés sur notre serveur Weinre.

Nous pouvons cliquer sur l’un des liens et alors nous pourronsons naviguer dans l’explorateur de DOM et de CSS, le gestionnaire de ressources et la console JavaScript.

Et ce qui est pas mal, c’est que lorsque nous inspectons un élément DOM, l’élément est en surbrillance sur la page à distance !

Voilà comment installer et utiliser un outil tout simple qui va nous faciliter la vie.

• les 3 speakers Objet Direct du Devoxx France : http://t.co/r7OTNDYB, http://t.co/W5zeVTpS et http://t.co/Sjtca0xA – à ne pas manquer ! #

• Brainstorming réseaux sociaux chez Objet Direct #

Le Google Tech User Group parisien organise le 12 avril à l’ECE une soirée dédiée aux APIs YouTube pour mobile et au nouveau langage de programmation de Google, Dart.

Au programme à partir de 18h45 :

• Les API YouTube mobile pour les créateurs de contenus, les joueurs et les consommateurs.

  Une heure de vidéo est uploadé sur YouTube chaque seconde et les vidéos sont regardées 4 milliards de fois par jour. De plus en plus de contenu est uploadé sur YouTube et visionné via les smartphones. La rencontre de ces deux tendances offre de nouvelles perspectives aux développeurs d’applications mobiles.
  Venez apprendre comment exploiter les APIs YouTube pour créer de nouveaux services. Vous découvrirez comment des earlys adopters ont construit des applications mobiles innovantes en utilisant ces apis.
  Par  Jarek Wilkiewicz (Developper Advocate Youtube APIs) (en anglais).

• Buffet offert par Objet Direct

• Lightning talks

  De courtes présentations, 4 x 5 minutes, pour présenter des outils / hacks / libs / projets. Tous les slots ne sont pas encore pris, donc si vous avez un projet fun en rapport avec les technos Google à présenter n’hésitez pas à le proposer !

• Le langage de programmation DART

  Dart est un nouveau langage de programmation développé par Google pour faciliter la développement d’application Web. Le but est de remplacer Javascript en proposant un langage plus simple et plus structuré et surtout plus adapté au web.
  Par Shannon « JJ » Behrens (en anglais).

Plus d’informations et inscription sur la page meetup.

How gitHub works

Parmi les présentations de QCon London 2012 celle sur l’organisation de GitHub était particulièrement intéressante. Retour sur les secrets de fabrication de la petite startup de San Francisco devenue le réseaux sociaux des développeurs open source.

GitHub a été lancé en avril 2008 et fonctionne depuis le début de façon distribué. En effet, les 4 fondateurs étaient chacun aux quatres coins du monde quand ils ont créés GitHub. Même si leur siège est à San Francisco, GitHub continue de recruter des développeurs partout dans le monde pour s’assurer d’avoir les meilleurs talents. GitHub prend bien soin de garder ses employés “happy”, et apparemment cela fonctionne plutôt bien puisque en 4 ans ils sont désormais 60 et toujours 0 démission.




Travailler de façons asynchrone facilite aussi le travail distribué. Pour cela, toutes les communications passent par le chat ou les commentaires de pull request. L’idée est de limiter au maximum les réunions et les interruptions pour que les gens restent le plus longtemps possible dans “la zone”. La “zone”, c’est le moment où vous êtes hyper concentré sur une tâche et donc hyper productif. Dans notre métier il est parfois nécessaire d’absorber une importante charge cognitive (lecture et analyse) avant de produire quelques nouvelles lignes de code. Donc inutile d’ajouter des distractions et des interruptions alors qu’il est tellement difficile d’arriver à cet état de concentration.
Zach nous explique ensuite qu’il n’y a aucun horaire et que chacun est libre de venir travailler quand il se sent le plus productif. En effet, l’activité de développement requiert de la créativité et vous ne pouvez pas forcer les gens à être créatif pile entre 9h et 17h.

Du point vu de l’organisation, il n’y a pas de managers ou de chef de projets. Les équipes sont seules responsables de leur produit. Seule une ligne directrice est donnée par les 4 fondateurs. Après, libre à chaque membre de l’équipe de proposer et de travailler sur une nouvelle fonctionnalité si elle est reconnue comme intéressante par les autres membres de l’équipe.

Cette organisation peu habituel n’est rendu possible que par quelques facteurs important :

• GitHub est une startup auto-financé et profitable depuis le début.
• GitHub utilise GitHub. “eat your own dog food !”
• GitHub est une société qui vend un produit.

Côté technique, là aussi c’est très intéressant. Du Ruby on Rails dans le cloud avec RackSpace. Ici encore, le mot d’ordre est de livrer la fonctionnalité le plus rapidement pour avoir le feedback le plus tôt possible. GitHub est redéployé entre 5 et 30 fois par jours !

Plusieurs techniques pour faire du continuous deployement sont utilisées.

• feature branching.

Évidemment, comme on pouvait s’y attendre avec une entreprise reposant sur Git, les branches sont à l’honneur. Chaque nouvelle fonctionnalité fait l’objet d’une nouvelle branche. Mais attention, ne confondez pas avec les branches svn classiques que vous connaissez. L’idée ici est d’avoir une branche dont la durée de vie est très courte uniquement pour une feature qui doit rester simple. Les push (commits) sur la branche permettent d’avoir des codes reviews rapidement via l’interface GitHub.

• super fast tests !

L’allié incontournable du continuous deployement, ce sont bien sûr les tests automatisés. Avec 8000 tests en 4 minutes, GitHub réduit très fortement les risques de régression à chaque redéploiement. Pour garantir dans le temps ce niveau de qualité et de réactivité un test lent est lui-même considéré comme une régression.

Avec des déploiements aussi fréquent, il est nécessaire d’avoir du monitoring de qualité pour remonter au plus tôt les alertes. Les métriques donnent une perspective différente aux performances et permettent de cibler les points de contentions. Zach en profite pour nous montrer les métriques sur les clés ssh rejetées suite à la récente découverte d’une faille de sécurité majeure impactant tous les utilisateurs du site.

Derrière le site Github, nouveau bastion des projets open source, se cache donc aussi une startup atypique. Elle rappelle fortement une autre société qui propose une organisation similaire : 37Signals, les créateurs du framework ruby on rails. Rien d’étonnant donc à trouver un post du CTO de Github expliquant comment ils ont suivi les judicieux conseils du livre de 37 signals, getting real, pour démarrer leur business.




Ressources :

- GitHub
- How GitHub Works

- Zach a écrit après la conférence sur sa façon d’écrire les slides. Je vous le recommande, car la forme était aussi bonne que le fond : Slides for developers

• 

• Tweet

Voici la soirée initialement prévue en décembre dernier reprogrammée ce jeudi soir dans les locaux de SUPINFO par l’Alpes JUG.

InifiniSpan est une pièce essentielle dans la course à la mise à disposition d’une plateforme Cloud chez JBoss à l’image de Google AppEngine.

InfiniSpan se veut un concurrent open source direct de solutions telles que Oracle Coherence.
Ce cache distribué qui s’apparente au famille NoSQL de type clés valeurs, sert également comme cible de prédilection pour le développement du projet Hibernate Object Grid Mapper (OGM).

A ne pas manquer …