Le monde du Web et les technologies sous-jacentes (html5, javascript…) ne cessent d’évoluer.

Backbone, qui est passé en version 1.0, est il déjà de l’histoire ancienne ?
Venez assister au plus grand combat de frameworks javascript ayant eu lieu dans les Alpes.

Dans le coin gauche Philippe Charrière viendra avec son mighty Backbone crunch se mesurer aux deux challengers.
Sébastien Letélié se défendra à grands coups d’Angular aidé ou trahi par Paul Chavard et son attaque Ember.

Détails et inscriptions : http://www.jugevents.org/jugevents/event/50260

Attention les prochaines sessions de l’Alpes JUG se fera dans les locaux de Kelkoo, à Echirolles, 6 rue des méridiens dans le parc d’entreprises  Sud Galaxie.

Agrandir le plan

Rendez vous le Lundi 29 Avril pour une présentation sur NoSQL et ModeShape 3 par Randall Hauch.

Description du talk (en anglais) :
ModeShape 3 is an elastic, strongly-consistent hierarchical database that supports queries, full-text search, versioning, events, locking and use of schema-rich or schema- less constraints. It’s perfect for storing files and hierarchically structured data that will be accessed by navigation or queries. You can choose where (if at all) you want ModeShape to enforce your schema, but your structure and schema can always evolve as your needs change. Sequencers make it easy to extract structure from stored files, and federation can bring into your database information from external systems. It’s fast, sits on top of an Infinispan data grid, and open source. Learn about the benefits of ModeShape 3, and how to deploy and use it to store your own data.

 

Pour vous inscrire : http://www.jugevents.org/jugevents/event/50294

Et encore un grand merci à Kelkoo de nous accueillir dans leur locaux!

 

Un petit problème de salle, nous a fait découvrir les magnifiques locaux de Col’In.Et donc au au final, ça c’est bien passé !
La présentation s’est déroulée en trois parties :

• Stéphane fait des rappels sur les tests de charge, performance, stress …
• présentation Gatling en duo avec Pierre
• une session de questions / réponses et démonstration immédiate par le code

Gatling, faites tomber la foudre

Ce qu’on a particulièrement retenu

1. L’insoupçonnée influence du [ISP]aaS sur les tests de charge:
   C’est fini le temps du serveur surdimensionné qu’on budgète pour le projet. Aujourd’hui, avec la location de services, la facture vous rappelle chaque mois que des tests de charges pourraient vous faire gagner de l’argent !
   Le Green-IT est aussi un bon argument pour ces tests.
2. L’effet « intervention extérieure ».

Oui, c’est souvent ce qu’il faut pour se rendre-compte que la dette technique est partie à la dérive.
Donc avant même de démarrer les tests de charge, il faut s’assurer que le frein à main est desserré:

• Regarder ce qui se passe sur le client (Javascript, utiliser Firebug, PageSpeed Insight …)
• Regarder sur le serveur : VisualVM, loguer les requêtes SQL …

D’un autre coté, cela peut être l’occasion de présenter des améliorations de 200%, là où la plupart des projets sont contents de gagner 10%.

Le projet Gatling est sous une licence Apache très libre. Ainsi, certaines sociétés proposent des services de tests de charge en embarquant du Gatling sous le capot.
Le projet est né d’un réel besoin de consultant réalisant des prestations de tests de charge. JMeter a ses limites et avait jusqu’à  peu guère de concurrents sérieux.
Donc, il y a un an et demi environs, naissance du projet avec 4 points clés:

• Asynchrone
• Sortir du paradigme 1 utilisateur =  1 thread
• IO non bloquantes
• du texte ! « Un DSL oui, du XML éditable à travers une interface ad-hoc non ! »

Pierre Dal-pra

Pour l’implémentation, Play! semble avoir été une source d’inspiration, l’équipe a donc choisit Scala, le modèle Actors et DSL. Puissant à l’intérieur, simple à l’extérieur.
L’API est très bien pensée, Gatling est utilisé pour des tests de charge sur HTTP, mais dès le départ, il a été conçu « protocol agnostique » et donc il existe des modules pour d’autres protocoles (hélas pas disponibles en opensource).
C’est d’ailleurs sans doute la force de l’outil d’avoir découplé le DSL, les API et le moteur d’exécution. Cela lui donne beaucoup de marge de progression : il sera possible de remplacer certaines parties sans tout casser.
Par exemple passer de Netty à Spray, utiliser le support du clustering d’Akka et surtout écrire des « drivers » pour d’autres protocoles: JDBC, LDAP, WebSockets … et même pour des API Java.

L’idéal en terme d’outils de tests de charge HTTP serait bien sûr d’émuler le navigateur. C’est l’approche de Sélenium pour les tests fonctionnels. Mais comment passer à l’échelle pour des milliers de navigateurs ? Bien que les performances s’améliorent pour les outils simulant les navigateurs, mais elles suffisent à peine à couvrir l’évolution des sites web. Combien d’onglets ouverts avant que votre machine ne soit à la ramasse: 20 ? 30 ?
Donc on n’échappera pas à Gatling.

Une question récurrente avec les tests concerne la maintenance. En quelques jours l’équipe de developpement peut ruiner des mois de travail. Quelque soit l’outil, il existe des solutions simples.
Ne pas laisser pourrir la situation:
- intégrer les tests de charge au processus de CI. Sans forcement bourriner le serveur, il suffit d’une exécution pour vérifier que le scénario passe.
- dans le cadre d’une équipe agile, les tests de charge ne sont pas isolé, séparé du reste des développeurs. Ca tombe bien, c’est du code, il est versionné comme du code, c’est développeurs friendly. (Pas clickodrome à la JMeter).

Ensuite le DSL de Gatling permet de factoriser les scénarios de tests. Une procédure de login ne s’écrit qu’une fois. En évitant les répétitions, en utilisant des identifiants clairs, comme « #id-button-ok » au lieu de « //div/form[7]/input[3]« , on peut au moins limiter les dégâts.

Et comme ces questions amènent forcément à parler de DevOps : mention spéciale à Henry Gomez qui n’était pas là, malheureusement pour recueillir ses éloges.

Grand merci pour cette conférence à la fois proche du terrain et utilisant des techno de pointe.