Jean-Baptiste Cazaux nous a donné un cours du soir la semaine dernière sur la technologie Flex d’Adobe.

Cela a pu donner l’occasion aux consultants présents de confirmer une récente étude du cabinet Gartner sur le marché des technologies RIA. A la lumière des démonstrations du présentateur, nous avons effectivement constaté la maturité de la plate-forme.

Le programme fut riche:

• Démos d’applications Flex et AIR
• Présentation du langage et des outils
• Debug d’une application
• Extensions de composants graphiques
• La gestion des évènements
• Les layouts
• Le Framework MVC Cairngorm

Le moins que l’on puisse dire, c’est que Jean-Baptiste a su nous donner envie d’aller plus loin dans la découverte de la plate-forme applicative. Nous nous revoyons d’ailleurs cette semaine pour la suite de la présentation.

Ce Samedi 31 Janvier a eu lieu un JavaCamp à Paris, le JavaCampParis 3.

A partir de 9h30 – 10h, les premiers participants sont arrivés; et après un détour par la machine à café, le JavaCamp a démarré.

Les personnes présentes ont alors proposé des sujets qui les intéressaient (et se sont aussi présentées); ensuite, une “refactorisation” des sujets proposés a mis en évidence 7 thèmes :

• TDD (Test Driven Development)
• langages de scripting autour de la JVM (Scala, Groovy, Ruby)
• DDD (Domain Driven Design)
• les langages RIA et les frameworks Web: GWT, Flex, Wicket
• Scrum
• JEE 6 et Spring
• SOA
• Les Mocks

Ces thèmes ont pu être débattus/présentés par les participants dans 2 salles et sur 4 créneaux horaires : 10h15 -11h30, 10h45-13h00, 13h30-14h30, 14h45-16h.

Pendant la séance “les langages RIA et les frameworks Web: GWT, Flex, Wicket”, Tarik, et Eric, nous ont présenté Wicket (en avant premiere de ParisJug) et leur framework au dessus Wicket (pour faciliter et mettre à jour dynamiquement les formulaires dans Wicket); et avant de plus partir sur Flex, j’ai pu présenter la mise en oeuvre de GWT.

En abordant les “langages de scripting autour de la JVM (Scala, Groovy, Ruby)”, on a pu parler de la facilité d’intégration, de la mise en oeuvre, de l’intéret et de la pertinence des iDE dans le cadre des développements Scala (qui est compilé), Ruby, Groovy et Java Fx.

En parallèle, dans la salle “Solaris”, les débats ont porté sur la testabilité des programmes java. Nous avons eu un bon aperçu des différentes pratiques et technologies associées aux tests logiciels. En vrac: les x-Unit, Selenium, GreenPepper, FitNesse, Concordion, Bumblebee, SWTBot. Le débat suivant fut une présentation de DDD (Domain Driven Design) par Sébastien Letélié et le principal framework : Qi4j. Une approche intéressante qui est une “sur-couche” à la programmation orientée objet. Cette vision incite les objets java à se décomposer par comportement. On obtient donc un composite formé de plusieurs associations.

Dans l’autre salle, durant la séance “Scrum”, après de brefs retour d’expérience, Eric (pas le même que celui de Wicket, mais le co-organisateur) a pris la parole, et après avoir défini Scrum, nous a fait part de son avis sur combien Scrum peut être mal appliqué, et, ainsi souffrir d’une image négative; d’ailleurs le sujet a ensuite débordé sur le cycle de vie des méthodologies projets (la courbe des experts, early adopters, main stream users, …), et un comparatif entre ces dernières.

Un grand merci aux sponsors de la journée, Sun (pour les locaux) et Valtech (pour le petit déjeuner et les pizzas à midi), ainsi qu’à Jean Yves Pronier (côté Sun pour les locaux), Eric Lefevre-Ardant (co-organisateur avec moi-même), Eric Le Merdy, Claude Falguière (soutiens) et Alexis Moussine-Pouchkine (qui nous a mis en contact avec Jean-Yves), ainsi qu’aux participants pour le bon déroulement de la journée.

D’autres retours:

• I.T. Aware (Sébastien Letélié): http://www.itaware.eu/2009/01/31/javacamp-iii-tdd-et-ddd/
• Tom’s Quest: http://www.tomsquest.com/blog/javacamp-3-compte-rendu/
• The Coder’s Breakfast: http://thecodersbreakfast.net/index.php?post/2009/02/01/Java-Barcamp-3-%3A-compte-rendu
• Photos d’Eric Lefevre: http://flickr.com/photos/elefevre/sets/72157613231545482/

suite de Paris On Rails 2008 première partie

Tests d’interface Web avec Rails par Jean Michel Garnier

Jean Michel a commencé par une présentation de RSpec, et a enchaîné sur le TDD JavaScript : Screw Unit pour tester son JavaScript.
Ensuite il a continué sur les tests fonctionnels (plus de la moitié des erreurs apparaissent dans les spécifications fonctionnelles), en présentant Cucumber (ou Rspect Story Runner), framework de tests fonctionnels pour Ruby On Rails (qui va être intégré dans RSpec) , mais peut être utilisable en Java ou .Net via JRuby ou IronRuby.
Cucumber permet un formalisme à la RSpec, aussi bien que FIT (tableaux exécutables).
Pour les tests d’acceptance Web, WebRat (Ruby Acceptance Testing), basé sur HTMLUnit (Java), s’utilise via JRuby, et propose une interface pour plusieurs types de session; dont Webrat::SeleniumSession, une des plus avancées.

Enfin, sont évoqués les serveurs d’intégration continus pour Ruby, comme CruiseControl.rb et Hudson, via JRuby.

Ce qui nous amène à la seconde présentation orientée tests fonctionnels du jour (Gilles t’aurais du venir ! )

Tests d’acceptance Web à forte valeur ajoutée (par Philippe Hanrigou , de ThoughtWorks)

Les tests d’acceptance Web avec Selenium ou Watir sont compliqués à maintenir, ou sont trop longs à exécuter.
Fit est parfait pour tester le backend, tests du code métier, mais pas pour IHM.
Philippe nous décrit la difficulté de maintenir des tests d’acceptance, et insiste sur le fait que l’ensemble des développeurs de l’équipe doivent prendre en compte la difficulté à maintenir et écrire des tests d’acceptance web, pas juste les nouveaux venus sur le projet !

Pour faciliter le travail, l’outil qu’il utilise est Selenium Rspec Report, qui ajoute des fonctionnalités à RSpec : un maximum d’informations sont remontées : l’état du DOM lorsque le test a planté, un screenshot, les logs Selenium, pour pouvoir mieux suivre les tests d’acceptance et pourquoi ils ont échoué.
Pour accélérer ces tests,q ui peuvent être longs, on peut utiliser Selenium Grid pour paralléliser l’exécution des tests.

Philippe a aussi expliqué que les fixtures rails n’étaient pas la meilleure solution pour initialiser l’état lors des tests fonctionnels.
Pour pouvoir initialiserle domaine métier, pas juste le modèle, il a introduit Object Mother : design pattern pour tests d’acceptance implémenté par Object Daddy et Factory Girls, opposé aux Mocks car contient tout le domaine métier, pas juste un objet !
En conclusion, les tests d’acceptance Web sont difficiles, mais pas insurmontables : il faut paralléliser (avec Deep Test ?), isoler, être le plus précis possible.

Rails Performance par Michael Koriaski, membre de l’équipe core rails

Tout d’abord, a t on besoin d’optimiser ?Si oui, se concentrer sur quels axes d’amélioration ?

A priori, monter en puissance avec l’achat de nouveau matériel est ce qui coûterait le moins cher (sauf si on s’appelle Google ou Microsoft!)

Pour savoir ce qu’il faut optimiser, il faut se baser sur la performance perçue par l’utilisateur, et on se rend compte que le temps de chargement d’une page html représente 0.5% du temps que l’utilisateur attend; les images, les javascript, les CSS, etc… pèsent beaucoup plus lourd dans la balance !

Ainsi, on doit se concentrer sur sur le serveur front qui sert les fichiers statiques !

Enfin, on peut se poser des questions sur son appli rails :

• Qu’est ce qui est lent ? (on utilise des outils de benchmarks pour le savoir, avec éventuellement un Ruby instrumenté comme Ruby ENterprise Edition pour connaître les allocations des objets)
• Pourquoi est ce lent ? (essayer d’optimiser les allers retours sur le réseau en se servant des entêtes HTTP, et les Entity tags ce que Rails 2.2 peut faire, on dit au navigateur : “cest bon, t’as déjà la bonne version en cache !”
• Rendre plus rapide (contrer le syndrome des N+1 requêtes en remaniant ses boucles et relations, régler le Garbage Collector de Ruby (augmenter sa tailel de départ par exemple) , etc…

Interview de David Heinemeier Hansson à Chicago, créateur de Ruby on Rails, via Ichat

Rails 2.2 a de meilleures performances par rapport aux versions précédentes, en particulier l’équipe de développement s’est concentrée sur HTTP (Etag, MemCache, etc..)
Rails 2.2 est compatible avec JRuby et Ruby 1.9, l’équipe essaie de faire fonctionner Rails sur le maximum de serveurs Web (via Rack).
Beaucoup de ménage a été fait, toute le code déprécié a été enlevé.

Liquid : moteur de templates en Ruby par Didier Lafforgue

Inspiré de smarty (issu de la communauté PHP)
Présentation des drops, filtres
S’installe en Gem ou en plugin.
Didier a évoqué un service qui a l’air excellent : hébergement (+git) et déploiement Rails : Heroku.com

La fin

Enfin Thomas Lissajou a amené un débat de clotûre sur le thème : “Agile Web Development with Rails, et vous ?”

Et bien, on découvre qu’il y a 2 groupes dans la communauté Rails : ceux qui en font et en sont convaincus (TDD, tests d’acceptance) et ceux qui considèrent que c’est réservé aux autres projets, car ils n’ont pas le temps ni les moyens; il y a beaucoup à parier que ces personnes, au fil de leur carrière ne tarderont pas à en être convaincu !

J’ai été ravi d’assister pour la 1ère fois à ParisOnRails, vivement l’an prochain !

Quelques commentaires sur la soirée Paris Java User Group de mardi dernier, sur le MDA et sur Flex.

(more…)

Le 19 juin, Valtech Training organise un atelier clients riches Web : GWT, Silverlight et Flex.

A l’heure où Web 2 devient l’expression la plus utilisée de la presse informatique et où les éditeurs se livrent à une escalade d’annonces, nous vous proposons de vous forger votre opinion sur les technologies les plus en vue du monde Rich Internet Application : Flex, GWT et Silverlight.

Après une introduction rapide aux problématiques et solutions du client riche, vous pratiquerez lors de trois ateliers techniques successifs de 2 heures. Vous écrirez donc votre première application dans chacune de ces technologies et serez ainsi amené à juger de leur facilité de mise en œuvre : essayez-les, choisissez !

Je veux m’inscrire !

J’ai connu le framework Ext-js après avoir eu la charge d’évolutions sur une mini-application web.

Ce qui est frappant c’est que les gens qui éditent ce framework ont rétablit pour les applis web un équilibrage qui existe toujours dans les applications lourdes (Desktop). Ils ont replacé la gestion de l’interface homme machine du côté du client. Cette librairie en langage Javascript offre des services d’interaction avec le javascript (JSON, extension des API natives, etc.), avec le serveur (Ajax) et une gamme de composants graphiques d’interaction. L’interface d’une application web construite sur ce modèle est donc la composition de:

• vues (pages HTML) qui initialisent le squelette de la page,
• contrôleurs (scripts Javascript) qui intègrent les composants graphiques et qui dynamisent ce squelette,
• modèles (scripts Javascript) qui récupèrent les données du serveur.

Pour le développeur

Du point de vue du développeur, c’est une librairie agréable à utiliser pour peu qu’on se familiarise avec le javascript du XXI ème siècle (qui n’a plus rien de commun avec le scripting verbeux et inmaintenable qu’on vous demandait de faire marcher sous IE et Netscape en l’an 2000). Mécanismes de listener, panels, layout, on se croirait presque en train de faire du Swing ! Ce qui m’a posé le plus de problèmes est le typage faible ainsi que le passage de pointeurs de fonctions qui ne ressemble pas à ce qu’on fait habituellement en objet mais qui est très pratique pour passer un callback. Du côté des outils, c’est firefox+firebug associé à Eclipse WTP avec lien des sources directement dans Tomcat.

Le marché

Le besoin d’applications riches tournant dans le conteneur d’application qu’on appelle navigateur web, avec déploiement instantané et accès concurrent est très fort. Les solutions pour augmenter l’expérience utilisateur et la productivité des développeurs existent; j’ai parlé de Ext-js mais il y a aussi Flex d’Adobe ou Silverlight de Microsoft. Ext-js repose sur les standards et arrive à faire tourner ses applications dans le navigateur, mais ce n’est pas le cas de Flex ou Silverlight qui requierent tous deux un plug-in container d’application.

Les standards du web ont été conçus sur un modèle documentaire. Sauront-il inventer un standard de l’application web ? Si on regarde côté applications ‘Desktop’, il n’existe aucun standard de ce type car pour moi, un standard est plutôt lourd et peu évolutif. Je pense que la concurrence dans ce domaine permet de développer l’innovation et les bénéfices pour les utilisateurs. Le risque majeur est qu’un acteur du marché développe un monopole avec l’emprise sur le web que cela induit.

Conclusion

Pour finir, je pense que pour un développeur de vraies applications web (i.e. pas de sites web), il est plus agréable de travailler avec un Framework de qualité comme Ext-js que de redévelopper sans cesse l’interface utilisateur sur chaque page.

Pour le responsable technique/décideur, la question de la pérennité du framework dans un marché aussi versatile que celui des interfaces web est cruciale (je me demande toujours pourquoi JSF n’est pas adopté en masse – l’objet d’un autre article peut-être).

Pour les utilisateurs, le seul désagrément est la quasi-disparition du rafraîchissement des pages dont ils avaient fini par s’accommoder !