I.T. aware

KapIT propose dans sa section lab plusieurs utilitaires pour les technologies Flex parmi lesquels on retrouve:

• KapInspect

KapInspect est l’équivalent Flex de la célèbre console Firebug. Activée sur un simple clic elle permet d’inspecter l’ensemble des composants flex présent sur la page, de visualiser et de modifier leurs propriétés.

• Cairngorm console et purMVC console
  

Ces consoles permettent de visualiser à l’exécution les différents composants du framework.

L’intégration est très simple. Après avoir inclus les .swc dans le classpath de votre projet il suffit d’insérer les tags correspondants dans votre fichier mxml

Par exemple :

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" xmlns:kapit="fr.kapit.*"> ... <kapit:KapInspect/> </mx:Application>

A l’exécution il suffit d’enchainer la combinaison Ctrl+Alt+Click pour voir apparaitre la console. A noter que on peut utiliser en parallèle les différentes consoles.
L’intégration de la console pureMVC est un peu plus couteuse car elle nécessite de modifier le code de votre Facade afin d’étendre la classe DebugFacade. Tout est expliqué la

Les journées de l’utilisabilité organisées par Fred Cavazza pour Paris ont été l’occasion d’aborder les thèmes importants des applications riches. Des présentations intéressantes qui m’ont conforté dans ma vision du RIA et notamment de la relation développeur/graphiste/ergonome/utilisateur.
Ce que j’en retient :
Lire la suite »

Pour implémenter le pattern singleton en action script on se heurte rapidement à une limitation du langage: on ne peut pas rendre un constructeur privé or il s’agit de la base du pattern. En regardant sur internet on trouve plusieurs solutions plus ou moins évoluées qui permettent de protéger l’usage du constructeur. Souvent une exception est levée si le constructeur n’est pas invoqué par la méthode static getInstance. L’inconvénient de cette approche est que l’erreur est visible uniquement à l’exécution et non à la compilation. Dans le livre “ActionScript 3.0 Design Patterns” l’auteur propose une autre approche.
Lire la suite »

Le Paris JUG était cette fois ci consacré à GWT et à l’implémentation de Restlet pour GWT. Deux présentations rondement menée par Didier Girard et Jerome Louvel. J’ai été impressionné par le nombre de participant, pensant que GWT était déjà dans les moeurs. Bravo à Didier de continuer à promouvoir cette technologie innovante et à Jérôme d’y apporter le concept REST.
Reste que je m’étonne de la vision que les gens ont du RIA. Pour beaucoup j’ai l’impression que RIA veut dire application web riche. Or la notion de “riche” est simplement une reconsidération de l’expérience utilisateur et cela ne passe pas obligatoirement par le navigateur. GWT, Ajax, AppletFX, Flex ou Silverlight n’ont pas le monopole du RIA simplement parce qu’ils s’exécutent dans un navigateur.
Javascript a permis de dépasser les limites de HTML dans le navigateur et a donné une nouvelle dimension aux applications web. Le navigateur devient maintenant un runtime Javascript et utilise comme bibliothèque graphique le HTML. Comme Java avec Swing, C# avec WPF ou Silverlight, AS3 avec Flash et Flex.
iTunes est surement une des premières RIA et ce n’est pas une application web. Comme je le disais déjà il faut simplement différencier Rich Web Application et Rich Desktop Application. Une RWA s’éxecute dans le navigateur, une RDA s’éxecute dans un OS.
Il y a avantages et inconvénients dans les deux approches mais la diffusion et la maintenance qui ont longtemps été les points forts des applications web ne sont plus vrais aujourd’hui.
Comme vous ne vous étonnez plus d’avoir votre Windows automatiquement mis à jour il est aujourd’hui tout à fait possible pour une RDA d’être diffusée et maintenu via le Web. Java Web Start en est un bel exemple et Adobe AIR sait le faire aussi. Mais vous me direz que pour faire tourner du Java ou du Air il faut installer respectivement la JVM et le runtime AIR. Oui c’est vrai comme récemment vous avez installé Chrome ou il y a plus longtemps Firefox. La différence se fait avec Windows qui embarque son navigateur IE et que dès lors que vous achetez un PC en Windows vous l’avez. A un moment donné on installe un runtime et a moins d’être terriblement fainéant personne n’est obligé de se contenter de Windows/IE.
La où il faut être vigilant avec une RDA c’est de ne pas retomber dans l’ancien modèle client/serveur. La RDA doit rester une couche client et ne pas embarquer de métier qui lui doit toujours se trouver coté serveur.
Apple avait déjà expérimenté cela intelligemment avec WebObjects Java Client et continue aujourd’hui à proposer des API similaires pour Cocoa et maintenant IPhone SDK.
Au slogan “the browser is the platform” je réponds “the browser is a platform”. Les architectures de demain ne doivent pas être dépendantes de la couche client car celle-ci doit être développée dans la meilleure technologie pour répondre aux objectifs de l’application et du besoin client en privilégiant ergonomie et performance.
Notre application ResUrgences est en mode web depuis 8 ans maintenant dans un secteur (la santé) ou les applications sont souvent du client/serveur. Pourtant son extension du service d’urgences au SMUR nous oblige à reconsidérer le web car l’utilisation d’une application web sur tablette pc en mode déconnecté, bien que pas impossible, n’est pas adaptée. Notamment quant il s’agit de s’interconnecter avec du matériel de monitoring et d’électro-cardiogramme.
Alors quel choix faire entre RWA et RDA ? La première étape c’est de penser RIA, donc d’avoir un métier coté serveur respectant une architecture SOA et accessible via des services diffusant des formats diverses via des protocoles diverses. A partir de là différents critères vont rentrer en jeu : ergonomie, performance, accessibilité, environnement (OS et matériel), ouverture, sécurité, compatibilité avec un existant … Il n’y a donc pas de réponse évidente. Je cherche depuis un moment faire un tableau qui définit quelle technologie pour quels besoins et au final je pense que c’est inutile.
Ce qu’il faut considérer c’est que :

• l’accès aux resources locales (fichiers, applications, périphériques USB, serie, Bluetooth) est un argument pour pencher vers le RDA. Bien que cela peut être pallié avec un applet et de plus en plus avec Gears (mais cela revient à mixer RDA et RIA, pourquoi pas d’ailleurs c’est ce que je fais) et que le Flash plugin permet déjà l’accès à la caméra.
• la notion de “push”, pour envoyer des données vers un client depuis le serveur est maintenant possible avec des RWA (Comet, reverse Ajax) et bientôt standardisée dans HTML 5 (WebSocket).
• les échanges asynchrones via des MOM avec des queues coté client ne peuvent pas encore se faire en RWA. Gears devrait proposer une API et LifeCycle Data Service ne le propose pas reellement car la queue reste coté serveur.
• l’uniformisation des applicatifs avec une même plate-forme de déploiement indépendante de l’OS est sûrement l’argument le plus percutant pour le SI pour choisir une RWA

Dans un post précédent je disais que ce qui manquait à JavaFX était un outil de conception graphique pour permettre une collaboration graphiste/développeur selon moi indispensable à l’adhésion de la communauté à cette technologie. Sachant que les graphistes ne changeront pas d’outils facilement la meilleure approche serait de faire un pont entre les outils de design existants et JavaFX. C’est l’objectif de Project NILE en proposant un plugin Illustrator et un plugin Photoshop permettant d’exporter un FXD ou un fichier FX mais aussi un convertisseur SVG et un visualiseur graphique.
C’est selon moi la bonne stratégie, je me suis donc lancé dans un test.
Lire la suite »

L’ adoption du client riche n’est pas que l’ engouement pour une nouvelle mode, c’est une réponse à une demande utilisateur pour qui l’informatique se doit d’être simple et intuitive. Les technologies et les outils se mettent en place, mais nous avons besoin de repenser la manière de concevoir les applications en impliquant plus l’utilisateur dans l’interface visuelle. Le client riche nous permet aujourd’hui de réaliser tous ce que peuvent imaginer les utilisateurs et c’est cette capacité qui rend ce concept innovant. Le problème c’est que l’utilisateur n’a pas toujours les moyens d’imaginer ce qui serait le mieux, il faut faire intervenir des personnes qui connaissent le métier, maîtrise les concepts d’ergonomie, ont une connaissance du design et de ce que tout cela peut coûter en terme de développement. C’est cet ensemble de compétences qu’il faut coordonner face à l’expression des besoins utilisateurs. On peut résumer cette approche sous forme d’un tetraèdre :

L’ochestrateur à le rôle bien particulier de mettre en harmonie le technique et le visuel avec le métier. Toute la difficulté réside à trouver la personne qui maîtrise les trois concepts précités et est capable de comprendre les subtilités de différents métiers. A mon avis la réussite d’un projet client riche passe par cette approche.

Le titre est un peu racoleur je vous l’accorde mais l’objectif de ce billet est plutôt de se familiariser avec 3 façons de faire du RIA et de les comparer au travers d’un composant central d’une application : le grid.
Je me suis donc employé à recréer un écran simple contenant un label, un bouton et un grid.
Lire la suite »

C’est un fait les applications Web deviennent asynchrones. En effet l’arrivée d’AJAX à permis d’en finir avec des temps de réponse long due à la vielle pratique du response-request loop pour charger une page entière. Bien avant AJAX cette technique était déjà pratiquée en utilisant une Applet cachée qui permettait d’accèder à un MOM (Message Oriented Middleware). Le MOM ne serait il pas en train de s’imposer comme l’architecture d’échange la plus appropriée des applications web ?

Lire la suite »

C’est avec plaisir que j’ai pu assister à la présentation de la dernière gamme de produit pour l’entreprise du portail eXo platform. Benjamin Mestrallet et Francois Moron ont réussi à réunir des personnes de qualité que même les plus grands aimeraient avoir pour leur présentations. Après un bref historique de eXo platform Benjamin à présenter les 4 produits entreprises :

• ECM
• Collaboration Suite (mail, contact, calendrier)
• Live room (video conference)
• Forum / Faq

Lire la suite »

Vous pouvez retrouvez sur TV4IT une interview de Guillaume Bodet (DT de Xebia) pour un premier retour d’expérience sur Flex vs Ajax. Malgré mon attachement naturel vers les technologies Ajax je regarde vraiment de très prêt l’offre Adobe et j’avoue : je suis séduit….Je pense publier quelques billets bientôt sur ce sujet. Je nuancerais juste un peu les propos de Guillaume Bodet sur l’avenir d’ajax. Là ou il voit une “technologie transitoire” je préfère penser que les technos Ajax deviendront le standart minimum pour développer une application web. Je pense qu’Ajax (j’aime pas cet acronyme qui veut tout et rien dire à la fois) a donc encore de beaux jours devant lui mais il faut absolument commencer à s’immerger dans l’environnement d’ Adobe.