Ce retour fait suite au gain d’une licence JRebel lors de la soirée du Toulouse JUG autour du Framework Play.

Présentation rapide

JRebel est un outil proposé par la société ZeroTurnaround à destination des développeurs ayant pour but d’améliorer leur productivité. Pour cela, il fournit un système de prises en compte à chaud des modifications sans nécessiter le redéploiement de l’application ou le redémarrage du serveur.

Il se présente sous la forme d’un plugin « java agent » à déclarer au niveau de la JVM du serveur d’application et d’un fichier de configuration « rebel.xml » à placer à la racine du répertoire contenant les fichiers « .class » pour chaque application et module du projet. A l’exécution, cet agent surveille les classpath indiqués dans le fichier « rebel.xml » puis agit sur le Class Loader en chargeant les nouvelles versions des classes (d’après ce que j’ai pu comprendre, il s’agit d’un monitoring des classpath en se basant sur les timestamp des fichiers .class pour détecter les modifications).

Pour plus de détails, la documentation et les forums permettent une prise en main rapide pour les cas d’utilisation standards.

Prise en Main

Pour prendre en main l’outil, j’ai effectué les premiers tests sur un projet personnel basé sur Spring MVC avec utilisation de Spring Web Flow, le tout s’exécutant dans le conteneur Tomcat.

Pour les technologies Spring, ZeroTurnaround fournit de nombreux exemples (documentation, FAQ, screencast). La mise en place de JRebel a donc été rapide. Pour les quelques problèmes survenus au démarrage, une recherche sur les forums permet de rapidement cerner les erreurs de paramétrage.

Pour les personnes ayant assisté aux soirées sur Play ou Grails, les présentateurs ont mis en avant la prise en compte des modifications sans redémarrage du serveur parmi les avantages par rapport aux autres frameworks JEE dits « standards ». Avec JRebel, un projet Spring « classique » profite d‘un fonctionnement très proche.

L’apport de JRebel est un plus indéniable pour le développement. Il permet d’améliorer la

productivité du développeur aussi bien dans la phase de création que leur de la validation ou du support d’une application. Malgré quelques ratés ayant nécessité de redémarrer Tomcat, ce premier test m’a convaincu de pousser l’expérimentation en condition réelle sur un projet professionnel.

Utilisation en condition réelle

Afin de faire un retour plus pertinent, j’ai configuré JRebel sur mon environnement de

développement professionnel. Point important, la société pour laquelle je travaille utilise un

framework interne, donc non listé comme pris en charge par JRebel.

Alors que la mise en place fut plutôt rapide pour le projet Spring, la tâche a été beaucoup

plus compliquée sur ce second environnement. Après plusieurs échecs, j’ai fini par trouver un paramétrage assurant la prise en compte des modifications pour les projets web principaux, les modules externes étant plus ou moins bien pris en charge.

Après environ trois semaines d’utilisation en condition réelle, JRebel affiche une estimation de 3 heures économisées (pour 14 jours de développement). Toutefois, malgré la prise en compte des modifications, notre framework interne nécessite un redéploiement de l’application web dans la plupart des cas.

La problématique rencontrée n’est pas à mettre sur le compte de JRebel mais sur le fonctionnement particulier de notre framework. Pour que certaines modifications soient prises en compte, la chaîne de démarrage de l’application web est impérative. Pour utiliser JRebel de manière optimale avec ce framework, le développement d’un plugin JRebel prenant en compte ses particularités semble inévitable et met fin à mes tests.

Conclusion

Les Plus :

• JRebel améliore la productivité de développement. Il peut être également intéressant lors de la phase de support où le nombre de redémarrages peut être élevé
• Bonne intégration aux différents IDE et gestion de la majorité des conteneurs de servlet et serveurs JEE
• Gestion d’un grand nombre de frameworks
• Documentation et support

Les Moins :

• Solution payante. Il peut être difficile de justifier l’achat sachant que la solution se limite aux développeurs et ne profite pas aux clients finaux en environnement de production
• Solution complexe à mettre en Å“uvre avec certaines architectures (problème sur la gestion des modifications sur plusieurs modules externes) ou des frameworks « exotiques »

Jonathan Pineau

Pour coller le plus possible aux différentes ambitions des services client, Zendesk propose plusieurs formules d’abonnements : Starter, Regular, Plus+ et Enterprise. Celles-ci ont été affinées au fil du temps grâce à l’expérience accumulée de cet éditeur dans la relation client. Voici un descriptif des principales différences entre ces abonnements : La Starter est la version [...]

Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.

Conditions du test

Afin d’évaluer diverses structures de messages, le prototype utilise une structure arborescente. Traditionnellement, ce type de structure est récursif. Cependant, il n’est pas compatible avec la limitation de Thrift sur la déclaration avancée abordée dans le précédent article.
La profondeur a donc été arbitrairement limitée au niveau 6, soit 127 nœuds au maximum pour un arbre binaire complet. Il y a un type différent par profondeur, de Node0 pour la racine à Node6 pour les feuilles les plus basses. Les arbres générés le sont selon trois paramètres :

• le nombre total de nÅ“uds, qui permet de faire varier le nombre d’objets du message,
• la cardinalité des fratries , qui joue sur la complexité : plus cette cardinalité est faible pour un nombre de nÅ“uds donné, plus les fratries sont petites et nombreuses, donc plus le message est complexe,
• et la taille des nÅ“uds, qui est fonction du champ « description ». Son contenu est une chaîne de caractères différente pour chacun d’eux et générée par décalage des valeurs Unicode des caractères.

La construction des arbres se fait récursivement et équitablement entre les fils d’un nÅ“ud. Ci-dessous trois exemples d’arbre à 5 nÅ“uds avec, de gauche à droite, des tailles de fratries de 1, 2 et 3. Les numéros sont présents à titre indicatif et indiquent l’ordre de création des nÅ“uds par l’algorithme de construction.

Les déclarations dans les IDLs Thrift IDL et Protocol Buffers language sont disponibles en fin d’article. Les versions utilisées sont 0.8.0 pour Thrift, 2.4.1 pour Protocol Buffers et HotSpot 1.6.0_29 pour la JVM.

Impact du nombre d’objets du message

Dans un premier temps, la complexité est fixée au minimum :

• La longueur des descriptions de chaque nÅ“ud est constante (32 caractères),
• le nombre de nÅ“uds est variable,
• la structure choisie est le 1024-tree qui équivaut à un arbre à deux niveaux dans cette étude.

En effet, si la cardinalité des fratries est supérieure au nombre de nœuds n, on obtient un arbre à deux niveaux, une racine Node0 et n-1 enfants Node1. Les 1024-trees de cet article ont tous cette structure car n est toujours inférieur à 1024.

Tracer la taille du message sérialisé en fonction du nombre de nœuds donne le graphe suivant :

Aussi bien sur cet histogramme que sur les suivants, une barre plus basse correspond systématiquement à un meilleur résultat et l’ordre des barres (de gauche à droite) correspond à celui de la légende (de haut en bas).
Sur ce premier graphique, on retrouve un constat du benchmark Java Serializers, mais dans un contexte de message plus complexe : Thrift et protobuf ont des performances très proches.

Le graphique ci-dessous rapporte leurs résultats à ceux de la sérialisation Java. On constate que leur avantage en termes de taille de message s’amenuise à mesure que l’arbre grossit.

Sur le graphique suivant, on observe que la taille moyenne d’un nÅ“ud décroît rapidement pour la sérialisation Java. En effet, le protocole de sérialisation Java ajoute aux informations du message lui-même la description des classes sérialisées. Ce surcoût, important pour un petit message, devient négligeable pour des messages constitués de nombreux objets du même type.

Les protocoles de protobuf et Thrift, quant à eux, contiennent très peu d’information de structure : uniquement un identifiant de champ et un type. Ainsi ils voient la taille moyenne d’un nÅ“ud croître légèrement, car les listes d’enfants augmentent en nombre et taille quand l’arbre grossit.

Impact de la taille des objets

Pour ce second test, on fige la structure du message pour mesurer l’influence de la quantité d’information contenue dans chaque nÅ“ud :

• Un 1024-tree est considéré comme dans le test précédent,
• sa taille est fixée à 31 nÅ“uds,
• la taille du champ « description » est utilisé comme variable.

Les résultats concernant la taille du message sont similaires au test précédent, Thrift et protobuf sont très proches et font mieux que la sérialisation Java surtout pour de petits objets.

Figer la structure du message montre que la différence de taille par rapport au protocole de sérialisation Java est quasi-constante. Ceci est dû au fait que protobuf et Thrift n’apportent aucun gain notable lorsqu’on fait varier la taille de la chaîne de caractères.
En effet, les trois protocoles en jeu la sérialisent sous forme de chaîne en UTF8 précédée de sa longueur. La différence est que le protocole Java utilise 2 octets pour la longueur des chaînes de moins de 2^16 caractères, tandis que les deux frameworks ont recours à un varint. Le saut entre 64 et 128 caractères est dû au fait que le format varint n’utilise qu’un octet pour coder les entiers entre 0 et 127, puis deux de 128 à 2^14.

Impact de la structure du message

Pour évaluer l’influence de la structure du message :

• la description de chaque nÅ“ud est fixée à 32 caractères,
• le nombre de nÅ“uds est variable,
• la cardinalité des fratries prend trois valeurs : 2, 4 et 1024.

Par exemple, voici les trois variations considérées de l’arbre à 7 nÅ“uds :

Le graphique qui suit recense les tailles des messages sérialisés.

Pour tous les protocoles de sérialisation, le comportement est similaire : plus de complexité conduit à un message sérialisé moins compact.
Cela est dû au fait que plus de complexité se traduit par un plus grand nombre de listes de noeuds-enfants. Cependant, la variation reste négligeable (environ 1%) pour Thrift et protobuf.

Le protocole de sérialisation Java est lui plus fortement influencé (jusqu’à 13%). En effet la quantité d’information utilisée par les descripteurs de classes est liée au nombre de types de classes mises en jeu. Plus les fratries sont grandes, moins on utilise de classes différentes. Par exemple, pour 63 nÅ“uds, le 2-tree utilise toutes les classes de Node0 à Node5, le 4-tree s’arrête à Node3, et le 1024-tree à Node1.
Le résultat particulièrement bon du 2-tree de taille 127 est lié au fait que Node6 n’a pas de liste d’enfants et est donc plus compact que les autres types de Nodes. Dans cet arbre, la majorité des nÅ“uds (64) est de type Node6.

Les tailles moyennes par nÅ“ud sont représentées dans l’histogramme ci-dessous :

L’évolution est conforme aux observations du premier test : l’écart entre Java et les deux frameworks s’amenuise lorsqu’on augmente la taille du graphe sans pour autant être négligeable.

En traçant le gain apporté par les deux frameworks par rapport à la sérialisation Java on obtient :

Par exemple, en considérant le message du 4-tree à 63 nœuds et un système devant soutenir une charge de 10000 requêtes/s, le remplacement de la sérialisation Java par Thrift permet de diminuer le besoin de bande passante de 75.45 Mo/s à 40.68Mo/s, soit un gain de 46%.

Conclusion

Cet article a présenté une comparaison portant sur la taille de sérialisation avec des messages complexes. Par rapport au benchmark JVM-serializers, l’avantage de Thrift et protobuf sur la sérialisation native Java est moins décisif en termes de compacité, même s’il reste intéressant.

La taille du message sérialisé par Thrift ou Protocol Buffers n’est pas influencée par la structure même du message. C’est surtout son volume qui a un impact : les deux frameworks offrent une sérialisation bien plus compacte que celle de Java surtout sur de petits messages. Cette observation rejoint le fait que Protocol Buffers n’est pas particulièrement adapté aux volumes de données importants.

Il faut rappeler qu’employer la sérialisation native Java comme référence n’est légitime que parce que cet article se limite aux protocoles de sérialisation. Thrift et Protocol Buffers offrent d’autres avantages tels l’interopérabilité avec plusieurs langages et la compatibilité ascendante et descendante des messages. Ils sont abordés dans l’article précédent.

Pour aller plus loin, on pourrait analyser les temps de sérialisation, l’empreinte mémoire, l’intégration aux processus de build…

Annexes

Voici la déclaration des objets en Thrift IDL : tree.thrift

namespace java com.octo.example.serialization.model.thrift

enum RoomType {
        SINGLE =0,
        DOUBLE =1,
        SUITE =2
}
struct Node6 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
}
struct Node5 {
    1: optional i32 number,
    2: optional bool even,
    3: optional double rate,
    4: optional RoomType type,
    5: optional string description,
    6: list children,
}
[...]

et ainsi de suite jusqu’au Node0, qui correspond la racine de l’arbre. L’ordre employé évite le recours à la déclaration avancée.

Ci-dessous, l’équivalent en Protocol Buffers language : tree.proto

package serialization;

option java_package = "com.octo.example.serialization.model";
option java_outer_classname = "LimitedTreeProto";

enum RoomType {
    SINGLE =0;
    DOUBLE =1;
    SUITE =2;
}
message Node0 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
    repeated Node1 children = 6;
}
[...]
message Node6 {
    optional int32 number =1;
    optional bool even =2;
    optional double rate =3;
    optional RoomType type =4;
    optional string description = 5;
}

L’ordre des nÅ“uds plus naturel est supporté par le compilateur Protobuf.

Suggestion d'articles :

1. Sérialisation : Thrift et Protocol Buffers, principes et aperçu
2. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?
3. Les nouveautés du langage dans Java 7

Il y a toujours une première fois. La mienne s’est très bien passée, merci ! Sans transition, en voici un rapide compte-rendu : Introduction Par une froide mais belle matinée hivernale, une soixantaine de participants s’est rassemblée à La Cantine, sympathique lieu de coworking parisien proche des Grands Boulevard, où les attendait boissons froides et chaudes, pour la [...]

Enregistré le 2 janvier 2012

Telechargement de l’episode LesCastCodeurs-Episode–52.mp3

Interview Jean-François Grang

@jfgrang
Octo
iTimeSheet

Les articles sur le mobile sur le blog d’OCTO : http://blog.octo.com/tag/mobilite

L’interaction avec le reste du SI et des applis Java en particulier

JSON Kit
SBJson
GHUnit
OCUnit
OCMock

L’interface utilisateur et autre

iCloud
Siri
USI
Patently Apple

Nous contacter

Contactez-nous via twitter http://twitter.com/lescastcodeurs
sur le groupe Google http://groups.google.com/group/lescastcodeurs
ou sur le site web http://lescastcodeurs.com/
Flattr-ez nous (dons) sur http://lescastcodeurs.com/

Lors de mes pérégrinations au sein de mes différentsprojets et surtout, lors de discussions à bâton rompu avec les membres desassociations que j'ai pu rencontrer, le thème régie et forfait fait débat.
En effet, tout dépend de ce que vous vendez :·             Une société de service voudra vendre desressources dans un projet agile :o  Dans cecas, elle vend des CVo  Et lepilotage du projet est fait par le client, même en ajoutant des closes hybridesavec un Scrum Master ou un coach.o  Cela neme satisfait pas vraiment, c’est de l’interim…. ·             Une société de service voudra vendre unprojet agile :o  Dans cecas, elle fournit toutes les ressources pour aboutir à la réussite de ce projetet principalement un Product Owner et un Scrum Master.o  Elle peutcomposer avec des développeurs internes à la condition que ceux-ci soientdédiés à 100% au projet.o  A mesyeux, c’est déjà mieux. Mais que dit l’ Agile Manifesto ?J’ai relu les 12principes sous-jacents au manifeste et voici mes conclusions :

1.   satisfaire le client en livrant rapidement etrégulièrement des fonctionnalités à grande valeur ajoutée.a.   Régie : Pas concerné. La régie, c’est uneobligation de moyens et pas de résultat. Est-ce que la fourniture de moyensrépond à cette attente ?b.   Forfait : Obligation de résultat: livrer =satisfaire

2.   Les processus Agiles exploitent le changement pourdonner un avantage compétitif au client.a.   Régie : Une ressource peut détecter une solutionde changement, mais celle-ci reste dans son silo fonctionnel.b.   Forfait : Le changement initie une modification dupérimètre du projet, une action, un ou plusieurs livrables.

3.   Livrez fréquemment un logiciel opérationnel avecdes cycles de quelques semaines à quelques mois et une préférence pour les pluscourts.a.   Régie : Une ressource exécute une décision liée àla gestion des livrables. Elle aide, interagit, mais n'a pas de lead.b.   Forfait : Il s'agit d'un processus, d'une cadence ainsiqu'une validation de la qualité des livrables.

4.   Les utilisateurs ou leurs représentants etles développeurs doivent travailler ensemble quotidiennement tout au long du projet.a.   Régie : En tant que ressource, je contribue à l'effortde façon Co-productive.b.   Forfait : Le processus est le "comment" pourvalider le ou les livrables du projet.

5.   Réalisez les projets avec des personnes motivées.a.   Régie : Par principe, cette règle n'est pas liéeau contrat en "régie". Mais, elle est une règle de vie.b.   Forfait : Peut éventuellement apparentée auprocessus du projet. Le mode "forfait" donne la possibilité au client(sponsor) de revenir sur cette partie.

6.   La méthode la plus simple et la plus efficacepour transmettre de l’information à l'équipe de développement et àl’intérieur de celle-ci est le dialogue en face à face.a.   Régie : Règle de vie. Mais que ce passe-t-illorsque vous avez plusieurs prestataires dans la même équipe ?b.   Forfait : C’est la partie communication du ProcessProjet.

7.   Un logiciel opérationnel est la principale mesured’avancement.a.   Régie : L'obligation de moyen n'oblige pas ledéveloppeur à fournir cela. C'est, dans ce cas, plutôt une mesuredéontologique.b.   Forfait : Il s'agit de la validation des livrables.

8.   Ensemble, les commanditaires, les développeurs etles utilisateurs devraient être capables de maintenir indéfiniment un rythmeconstant.a.   Régie : Mais en fait, Oui/Non serait approprié.Oui pour l’équipe de développement. Non pour les autres acteurs du projet :MOA, Tests externes, BI, etc…b.   Forfait : Tous les développements disposent d'une date defin et une unité de mesure, même dans la recherche. Le forfait permet deconserver la main sur la gestion du temps.

9.   Une attention continue à l'excellence technique età une bonne conception renforcent l’Agilité.a.   Régie : Règle déontologique.b.   Forfait : Règle déontologique.

10.               Lasimplicité – c’est-à-dire l’art de minimiser la quantité de travailinutile – est essentiel.a.   Régie : Ce n'est pas lié au mode régie enparticulier.b.   Forfait : Il s'agit avant tout de la réduction durisque d'échec et la sécurisation des livrables. Cependant trop de simpliciténuit à la créativité et réduit l’interactivité entre les membres des équipes autogéréesdans un système complexe auto-adaptatif (cf. Cynefin).

11.               Lesmeilleures architectures, spécifications et conceptions émergent d'équipesauto organisées.a.   Régie : La régie lie un profil, un individu et pasune équipe.b.   Forfait ; Le mode au forfait favorise la vente d'unprojet. L'interaction du client sur l'organisation du projet est nulle. De cefait, l'autogestion peut être sécurisée.

12.               Ã€intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace,puis règle et modifie son comportement en conséquence.a.   Régie : Travail d'équipeb.   Forfait : Amélioration continue = réduction desrisques.

Conclusion :·        L’Agilitéen mode régie est un non sens. Quelle différence y-a-t-il entre un développeuragile et un développeur catholique ? En régie, si vous envoyez un développeur agile chez un client « traditionnel Â»pensez-vous vraiment que celui-ci évangélisera tout le monde ? est-ce quec’est ce que l’on demande ?
·        Cettedémonstration n’est pas parfaite car il y a toujours des cas particuliers.

·        Il ya des versions alternatives qui vont bien à l’agilité, tels que les contrats desupport (tickets).
·        Dans moncas, en tant que coach et Agile PMO, je ne fais que des contrats de support oudes contrats au forfait.

·        Très souvent,les contrats au forfait s’enchaînent les uns aux autres chez un client. A chaquefois, nous définissons un objectif (Plan de Release, Project Backlog) etcelui-ci est géré en parallèle de façon collégiale avec le client.
Tu faisde l’agilité en régie? Nnoooonnn...Le principede la régie est de fournir des profils pouvant intégrer un projet ou, plussouvent, une équipe existante. Dans un autre contexte, on appelle cela de l’interim.Mais,bon... c’est le marché qui décide.

Suite de notre cycle d’ateliers dédiés aux praticiens agiles, avec une nouvelle session au format Open Space le 14 Février de 14h à 18h dans les locaux d’OCTO. 3 bonnes raisons d’y participer :

 

1.Un rendez-vous dédié aux acteurs des DSI :

Le calendrier IT agile est déjà plutôt chargé, mais il se compose pour majeure partie de rendez-vous réservés aux « experts » de l’agile : gourous, coachs, formateurs, etc. Aucun n’est dédié à ceux qui font au quotidien, c’est à dire aux équipes internes au sein des DSI. Or Product Owner, ScrumMaster, MOA, Tech Lead, PMO, tous sont confrontés à des problématiques récurrentes au sein de leurs projets agiles.

 

2.De nouvelles pistes pour continuer à progresser :

L’objectif des Open Spaces est de partager entre pairs vos questions, vos problématiques, vos doutes, vos convictions et vos retours d’expérience :

• Comment intégrer les équipes UX ou Webdesign dans le process agile ?
• Comment donner de la visibilité à long terme à sa hiérarchie ?
• Comment diffuser la culture de l’amélioration continue ?
• Comment garantir le pérennité des rituels ?
• Comment mieux coopérer avec les équipes d’exploitation ?

Après plusieurs mois, voire plusieurs années de pratiques agiles au sein de ses équipes, il est primordial de lever de temps en temps la tête du guidon et de considérer au-dehors les choix que d’autres ont faits.

 

3.Un support illustré retraçant les échanges :

Comme lors de la première session cet automne, Véronique Olivier-Martin revient pour capter la substantifique moelle de nos échanges et la restituer sous forme d’illustrations sur une fresque murale véléda. Chaque participant repartira avec une version numérisée du croquis d’ensemble retraçant l’évolution des échanges au fil de la session et quelques zooms en bonus sur les croquis les plus percutants !

 

A l’issue de cet atelier, vous aurez pu :

• Proposer des sujets au coeur de vos problématiques et les traiter avec vos pairs sous d’autres angles
• Partager votre propre expérience d’agiliste sur des questions que se posent d’autres praticiens, au sein d’autres organisations
• Découvrir des pratiques agiles, des process et des organisations en place dans d’autres DSI
• Etendre votre réseau au sein de la communauté agile

Animateurs :

Christophe Thibaut & Mathieu Gandin : Consultants Seniors et Coachs Agile OCTO

Progamme :

• 14h : Accueil
• 14h00-14h15 : proposition des sujets
• 14h15-17h45 : Open Space ( 2 à 3 sessions d’ateliers suivis de restitutions)
• 17h45-18h : Restitution finale

Cliquez ici pour vous inscrire à l’Open Space du 14 Février

Suggestion d'articles :

1. Retour sur la première session Open Space praticiens agiles
2. Open Space pour les praticiens agiles le 24 novembre chez OCTO
3. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »

Notre Ippevent “Au coeur du BPM avec Bonita” du 19 mai 2012 avait connu un gros succès. Malheureusement un soucis technique nous avait empêché de diffuser la vidéo de cette conférence. Comme le sujet est important et nous sort un peu des considération purement technique de notre quotidien pour nous parler d’outils permettant de travailler avec les gens du métier, nous avons refait cette présentation pour que chacun puisse en bénéficier.

Ça tombe également bien avec le partenariat que vient de signer Ippon avec BonitaSoft en ce début d’année.

Agenda :

• Introduction aux enjeux d’analyse de données en temps réel
• Présentation des architectures d’analyse de données
• Présentation de la solution Open Source ESPER
• Présentation de la solution ActivePivot Sentinel (Quartet FS)
• Questions/Réponses

Définition : « Un système d’analyse de données temps réel est un système évènementiel disponible, scalable et stable capable de prendre des décisions (actions) avec une latence inférieure à 100ms »

100ms est l’ordre de grandeur retenu lorsque l’on parle de « temps réel ». Cette valeur permet de prendre les décisions dans un temps adapté au business.

Quelles différences avec l’analyse traditionnelle ?

• Les systèmes décisionnels sont construits sur des mécanismes qui imposent la duplication des données… donc avec un temps de latence importants.
• Notion de reporting opérationnel c’est à dire sur des données vivantes : on dépasse rapidement les 1000 TPS (transactions par secondes), ce qui est une limite au-delà de laquelle la latence des SGBDR explose (source : TPC.org).
• La prise de décision ne peut pas être prise dans la zone de stockage à cause de la latence, mais doit l’être idéalement en amont (à l’extérieur) pour une meilleure réactivité.

Quels intérêts pour les entreprises ?

Les entreprises sont déjà aujourd’hui confrontées aux problématiques de volumétrie. A cela s’y ajoute 3 nouveaux facteurs majeurs entraînant toujours plus de données dans nos systèmes :

• Une multiplication des appareils connectés, entraînant une augmentation des évènements qui devront être traités, et l’augmentation des sources d’évènements
• Une fusion des poches d’utilisateurs et une augmentation de leur nombre.
• Une forte volatilité du trafic (pic de connexion / utilisation) qui suit le rythme du métier (ex : saisonnalités dans le e-Commerce).

Pourquoi CEP ?

Définition : Le  Complex Event Processing (CEP) est une technique permettant de manipuler des événements au fur et à mesure de leur prise en compte, d’identifier des relations entre ces événements (corrélation, causalité, patterns), et d’en tirer de l’information sous forme de nouveaux événements dits « dérivés » ou « complexes ».

Le CEP apparaît être une opportunité pour l’analyse et la prise de décision en temps réel là ou même le stockage sur cache/grille de données seul peut montrer ses limites :

• la synchronisation cache/stock sur disque devient un problème sur de gros volumes de données
• Le décisionnel implique des requêtes complexes sur des volumes de données importants

Pourquoi faire converger Big Data et CEP ?

• Pour mieux tirer profit de l’augmentation des volumes de données : les SI ont besoin d’infos de plus en plus détaillées.
• Pour permettre des analyses de plus en plus complexes (systèmes de scoring, détection de comportement, machine learning…).
• Pour traiter efficacement de nouvelles sources de données (sociales, peu structurées…)
• Pour permettre, et c’est un point fondamental, de faire des expérimentations (ie. pouvoir interroger le système, découvrir de nouvelles règles, les tester, les mettre en place et les adapter si besoin).

L’intérêt principal du CEP réside dans le traitement en mémoire de l’événement avant son stockage, afin de conserver une forte réactivité.

Détails sur l’analyse en temps réel :

• Traitement évènementiel à faible latence
• Traitement en mémoire
• Fonctionnalités de traitement des évènements (jointure de flux corrélés, pattern matching, règles)
• Historisation des évènements traités
• Simulation sur des données historiques (backtesting)
• Des IHM sont présentes et répondent aux questions des données historiques et des données en temps réel (que s’est-il passé/que se passe-t-il ?). Permet de visualiser et d’explorer les données
• Il existe des IHM d’édition des règles utilisable directement par les métier / les analystes et sans besoin de développements particuliers.

Enjeux de l’analyse en temps réel :

• Latence
• Débit
• Consommation de mémoire
• Répartition sur plusieurs nÅ“uds
• Reprise sur panne
• Initialisation à partir de l’historique
• Richesse des interfaces pour l’analyse des données temps-réel et historique
• Possibilité de modifier facilement les règles d’analyse et de les valider rapidement

L’approche peut se faire par :

• des outils de pur CEP : (ex : Streambase, Tibco Business Events, Microsoft StreamInsight, ESPER…) : particulièrement performants sur l’analyse des évènements sur des échelles de temps courtes, il faudra leur adjoindre des systèmes de stockage des données historiques, et d’IHM évoluée
• des outils de datagrid : (ex : SQLFire, GigaSpaces) : très adapté au stockage à fort débit d’écriture, et fournissant des possibilités de traitement des données à chaud (type trigger), ces outils devront être secondés d’IHM évoluées pour répondre au besoin
• des outils OLAP en mémoire : (ex QuartetFS) : outils très adaptés au cas des analyses multidimensionnelles en temps-réel

Démo ESPER (moteur CEP Java) : nous ne sommes pas en mesure de vous proposer les vidéos aujourd’hui ; nous vous proposons de retrouver les démos en vidéos plus tard.

Démo ActivePivot Sentinel : nous ne sommes pas en mesure de vous proposer les vidéos aujourd’hui ; nous vous proposons de retrouver les démos en vidéos plus tard.

Suggestion d'articles :

1. L’analyse décisionnelle en temps réel Convergence entre Big Data et Complex Event Processing
2. OCTO organise un petit-déjeuner sur le thème « Usability » le 09 octobre à Paris
3. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology

Avec cette vidéo vous allez découvrir comment Kirk a procédé lors de cet atelier pour identifier les points d’amélioration d’un système et la manière de les résoudre. Tout cela sans préparation initiale ni code source : du live optimizing !
Écoutez également Lire la suite de cet article …

Pour des applications d’entreprise il est nécessaire de prévoir une solution de reporting pour vos utilisateurs ! Chez So@t, notre système d’information utilise les contrôles Telerik, nous avons donc voulu tester Telerik Reporting. Telerik Reporting fourni un ReportViewer très bien fait compatible avec Silverlight, WPF, ASP.Net, Azure et Windows Forms qui supporte l’impression ainsi que l’extraction des [...]

Une date à retenir ? Oui !  Le mardi 31/01/2012 pour nous faire part de vos idées sur les sujets IT, techniques, métiers ou liés aux aspects managériaux de la DSI !

Pas d’idée de session ? Aucun problème ! Vous pouvez élire votre session préférée en votant pour elle !  D’ailleurs vous pouvez aussi la partager  pour augmenter le nombre de vote !

Pour rappel : la qualité du résumé de session proposé (fond et forme) sera le critère de sélection principal pour l’équipe USI. Merci donc d’en tenir compte lors du remplissage de ce formulaire.

L’équipe programme étudiera toutes les propositions et sélectionnera les sessions qui lui paraîtront les plus intéressantes. Vous serez peut-être invité à venir présenter votre session lors d’une journée dédiée : mi février et nous informerons de notre décision finale fin mars 2012.

Cliquez ici pour soumettre votre session à l’USI

On attend vos candidatures avec impatience !

 

Suggestion d'articles :

1. Appel à candidature : proposez votre session à USI 2012 !
2. Avez vous la culture Cloud ? sur tv4it.net
3. Derniers jours pour profiter de votre place USI 2011 à -20%, les 28&29 juin prochains !

Voici quelques liens intéressants vers du contenu de programmation et gestion de projet informatique récoltés ce mois-ci. Flex est mort, vive Flex! Truc de coach: un Backlog enrichi et visuel Groovy 2.0 va vous plaire ! Continuous Deployment et Java PaaS avec CloudBees Code Retreat : Mode d’emploi Introduction au RIA avec Openlaszlo Versionner vos [...]

Bien que les containers IoC soient très répandus et utilisés par de développeurs, ils sont souvent considérés comme obscures et compliqués. Dans cette session j’aimerais présenter quelques exemples de mauvaise utilisation, expliquer quelques aspects concernant les containers IoC qui sont plus ou moins compris par les développeurs et démontrer comment ils doivent être utilisés correctement. [...]

La prochaine session du Paris Scala User Group aura lieu jeudi 26 Janvier à 19h30 dans les locaux de Xebia.

À cette occasion, Stéphane Landelle nous Lire la suite de cet article …

Ce bug est un vieux bug, à en juger par sa description sur le site Connect qui date de 2008 avec un problème remonté sous SQL Server 2005. https://connect.microsoft.com/SQLServer/feedback/details/328811/scope-identity-sometimes-returns-inco...

La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Actualité éditeurs / SSII

• Amazon dévoile DynamoDB (Par Alexandre Dutra)
• Sortie de Visuwall 0.3 (Par Julien Smadja et Arnaud Lemaire)

Evénements de notre communauté en France et à l’étranger

• Common Crawl Corpus : le web disponible sur les disques d’Amazon Web Service (Par Bertrand Dechoux)

Lire la suite de cet article …

Après les 4 P du marketing (revisités ou non par l’ère digitale), voici aujourd’hui un outil de facilitation et surtout de préparation de workshops à la fois ultra simple, visuel et terriblement efficace. Créé par James Macanufo (l’un des 3 auteurs de Gamestorming), les 7P vous permettent d’aller à l’essentiel, de bien cadrer votre workshop, bref [...]

Que l’on me pardonne de paraphraser ici la déclaration rituelle qui accompagnait l’inhumation du Roy de France et la transmission immédiate de la monarchie à son successeur désigné.

L’analogie me parait en effet appropriée dès lors que « Adobe Flex », roi incontestable des technologies RIA, est mort et « Apache Flex » est né (du moins c’est en cours).

Alors, faut-il s’en réjouir ? Oui, assurément, c’est une excellente nouvelle, et qu’il conviendra de célébrer justement en temps utile.

Et je dirais même plus, remercions Adobe pour ce cadeau qui nous est offert, en toute franchise, mais sans naïveté.

Il ne nous intéresse pas de chercher à analyser les raisons internes à Adobe qui ont motivé ce choix, laissons à César ce qui lui appartient, et regardons l’avenir de Flex, dont il ne tient qu’à nous qu’il soit glorieux.

Pour nous qui sommes développeurs Flex depuis 2004 et la version 1, nous n’avons cessé de pousser le framework dans ses retranchements, et toujours nous avons réussi à produire des applications (d’entreprise) esthétiques et de qualité, sans sacrifier pour autant l’industrialisation logicielle, qui est, hélas, trop souvent négligée.

A l’heure actuelle, nous affirmons que Flex reste le meilleur environnement de développement d’applications riches multi-plateforme, tant en terme de productivité que de richesse graphique ou fonctionnelle.

Les arguments en faveur (ou pas) de cette thèse ont été déjà largement exposés et sont accessibles via les liens ci-dessous :

• After 6 years doing Flex, am I moving to HTML5?
• The Future of the Flex Framework in Enterprise IT
• Adobe Flash Wounded but Death Exaggerated

Notre intention aujourd’hui est de continuer plus que jamais à utiliser Flex, et de renforcer notre présence dans son éco-système, en poursuivant la publication de composants, et en contribuant activement au framework Apache Flex.

Flex reloaded

Avec (et surtout sans) Adobe, Flex va continuer sa vie. Beaucoup de volontaires participent déjà au projet Apache Flex. De manière générale, les entreprises qui ont choisi Flex comme outil de développement de RIA continueront à l’utiliser, d’abord parce qu’il n’y a pas encore d’alternatives sérieuses offrant les mêmes possibilités et la même productivité.

Chez Kap IT nous n’avons pas diminué notre activité sur Flex, au contraire, nous continuons même à recruter de nouveaux clients (et des développeurs aussi…).

Nous restons convaincus que Flex restera encore pendant plusieurs années la plate-forme de choix pour les applications d’entreprise. Nous continuerons donc à investir dans Flex, sans doute plus qu’avant, en nous investissant dans le projet Spoon et la fondation Apache et en continuant à recruter et former ceux qui partagent cette conviction.

A ce propos, nous participons au « Logo Contest », dans lequel nous avons proposé deux déclinaisons différentes du futur logo Flex (et entre nous, ce changement est plutôt bienvenu) que vous pouvez découvrir dans cet article.

Flex n’est qu’un outil

Notre expertise en matière de RIA d’entreprise ne s’arrête évidement pas à la technologie. Les nombreux projets que nous avons réalisés pour nos clients nous ont permis de capitaliser sur les autres domaines qui permettent de réaliser des applications riches de qualité comme la méthodologie, l’ergonomie, le design ou encore l’assurance qualité. Ces domaines sont indépendants des langages et des plate-formes utilisés et nous sommes donc libres de changer s’il le faut. Si d’aventure une solution pour les RIA d’entreprise aussi productive et puissante que Flex devenait disponible, nous serions prêts.

A suivre…

Les prochains mois seront riches en surprises, surtout, restez online !

Il me reste à vous souhaiter une excellente année 2012, ainsi que beaucoup de projets Flex fructueux et passionnants.
Et de concert, souhaitons tous une Longue Vie à Apache Flex !

OCTO organise le mardi 07 février 2012 à partir de 8h45 un petit-déjeuner gratuit, aux Salons Wagram  « L’agilité à grande échelle » : retour d’expérience en partenariat avec Strator.

 

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

 

Qui a dit que l’agile n’était pas adapté aux gros projets ?

Strator et OCTO Technology se proposent de partager avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…

A l’issue de ce séminaire nous aurons partagé avec vous :

• Nos Do’s & Don’t à propos des méthodes agiles lorsqu’elles sont appliquées à de gros projets
• Les modèles d’organisation que nous avons mis en oeuvre
• Nos meilleures pratiques pour diriger des équipes projets géographiquement distribuées
• Les outils et les compétences clés pour démarrer un tel projet

 

Ce petit-déjeuner s’adresse aux :

• DSI
• Chefs de projets
• Responsables Innovation / e-business / Internet
• Responsables MOA / MOE
• Architectes

 

Intervenant(s) :
Philippe Chevalier – Strator, Directeur Technique
Herv̩ Lourdin РOCTO, Delivery Manager
Mathieu Despriee – OCTO, Manager

 

Ce petit-déjeuner est à destination de nos clients et prospects en priorité.

Cliquez ici pour vous inscrire au petit-déjeuner : Agilité

Suggestion d'articles :

1. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology
2. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide
3. OCTO organise un petit-déjeuner sur l’agilité, jeudi 12 novembre