AlcionTech

Vu sur Advogato : Javascript bouscule le modèle MVC.

''When HTML first came out, browsers could have been called "Application Thin Clients", if the buzzword had been in use at the time. The introduction of javascript made it possible to execute code on the client, and this turned browsers into something much more than just a "display" mechanism.

Before Javascript, Web application development was simple: everything was done server-side. The concept of MVC - Model View Controller - was easy: the HTML was generated, and that was the view. With Javascript being a full-blown programming language, the lines are being blurred between which code is responsible for the View, the Controller and even the Model. The resultant split of responsibility across client and server in wildly diverse programming languages is driving many developers to alternative technologies such as Flash, and causing headaches for those Web developers who remain.''

Je me fais un petit peu de pub:

Si vous êtes intéressés par les technos du Web 2.0 (javascript, html, css, php,...) et la représentation cartographique de données, je vous invites à faire un passage par mon site perso. Vous y trouverez plusieurs projets de veille technologique sur ces sujets, dont un à même eu le privilège d'être 'Mashup of the day" sur programmableweb.com.

• Mapified Kayak: une jolie couche de présentation pour le métamoteur de recherche de voyages Kayak, et la possibilité de rechercher plusieurs destinations et dates d'un coup (Google Maps + Kayak API).
• Overflown Countries: pour savoir quels pays vous survolez lors de vos voyages (Google Maps + Geonames API).
• Mapified Stock Indices: une présentation géolocalisée des variations d'indices boursiers asiatiques (Google Maps + Geonames + Dapper API).
• Mapified Rss: pour géolocaliser n'importe quel flux RSS et mettre en surbrillance les pays (Google Maps + Geonames API).
• GoogleMaps vs YahooMaps: les 2 cartes sur la même page pour comparer facilement les niveaux de zoom disponibles. Une fonction de synchronisation est fournie (Google Maps + Yahoo Maps API).
  

Bien que personnels, ces projets constituent également des démos pour présenter notre offre E-business et les compétences des ingénieurs d'Alcion dans ce domaine. Dans cette optique, si vous êtes vous-mêmes ingénieurs d'Alcion, n'hésitez pas à faire partager vos projets logiciels sur ce blog.

Ce mois-ci, une conférence pleine de bonnes nouvelles : on peut développer des écrans portables et sexy en Java, sans avoir besoin de connaître Javascript !

En introduction, un coup de projecteur sur JavaFX, sur le thème de "comment faire du flash, en java".

En plat principal, GWT, un framework qui a le potentiel de changer la donne. Il permet de réaliser des applications Ajax portables, en Java. Ses caractéristiques principales sont :

• il est open-source ;
• il n'impose pas d'apprendre javascript pour faire de l'ajax,
• il absorbe les nuances de navigateurs,
• il gère automatiquement des concepts de haut niveau comme la sérialisation, les appels RPC, et la traduction de code java->javascript pour exécution des traitements locaux au navigateur, ce qui est une petite prouesse.

Après 6 mois sur le terrain, il commence à être adopté par certains de nos clients.

Thierry a travaillé quelques semaines sur GWT. Il vous en expliquera les concepts, les principes de développement et vous fera une démo couvrant le design d'écrans, le remoting et l'exécution de code au sein du navigateur.

Que vient faire ici ce barbu frisé ? C'est Ajax le Grand, héros de la guerre de Troie... ;-)

Dans un billet précédent de ce blog, nous avions vu qu'il était possible de construire des flux rss (dapper) et de géolocaliser leur contenu (yahoo!pipe). Nous avions pris comme exemple les variations des indices principaux des bourses asiatiques.
La présentation par défaut sur la page du pipe a le bon goût d'exister mais convenons que le rendu n'est pas percutant. Il faut en effet cliquer sur chaque marqueur pour avoir les informations.
L'idéal serait d'avoir des marqueurs représentatifs de la variation de l'indice, vert quand positif, rouge quand négatif, avec une taille proportionnelle à cette variation.
Pour arriver à ce résultat, il faut un peu programmer. Un API maps est fourni par Google et Yahoo! donc nous allons travailler avec les 2 pour comparer.
Le principe est relativement simple, dans chaque carte (YMap et GMap), pour chaque pays présent dans le flux RSS, on ajoute un marqueur (YMarker, GMarker) personnalisé (YImage ou GIcon). La hauteur du marqueur est ajustée par la formule Math.round(Math.abs(fChange) * 20) et donc d'avoir une hauteur de 20px pour une variation d'indice de 1%. Le fichier source est disponible en annexe (fonction fFillYahooMapWithGeo et fFillGoogleMapWithGeo).
Les résultats sont visibles ci-dessous, avec à gauche Google en haut et Yahoo en bas.

Sur le plan fonctionnel, un léger avantage à Yahoo! qui permet d'afficher un label par un simple passage de la souris sur le marqueur alors que Google nécessite de cliquer dessus.
Les métriques ne font pas apparaitre de différences significatives entre les 2 API:

• Temps de chargement: environ 4s,
• Nombre de requêtes: légèrement plus pour Yahoo (71 contre 54),
• Octets téléchargés: environ 400kO,
• Nombre de lignes de code propres aux API: une dizaine.
  

Les 2 API offrant un services de géolocalisation, nous pouvons donc essayer d'utiliser directement le flux RSS de Dapper (non géo-localisé) et confier la tâche de géolocalisation aux API. Yahoo le permet très simplement en remplacant un paramètre d'entrée du constructeur de YMarker mais les requêtes sont synchrones (fonction fFillYahooMapWithoutGeo dans le source). L'API Google est plus délicate à mettre en oeuvre car il faut utiliser un objet GClientGeocoder et utiliser une fonction de callback.
Dans les tests, il a été constaté un léger ralentissement (environ 1s) avec cette méthode à cause d'une plus forte utilisation du réseau (17 requêtes de plus).

Avis subjectif de l'auteur:

• Aucune API ne se démarque de l'autre. Celle de Google est légèrement plus complexe mais compense par légèrement plus de fonctionnalités.
• Notre application est bien exigeante en bande passante et temps d'UC puisqu'elle nécessite de mettre en forme le HTML chez Bloomberg, de transférer ce flux de Bloomberg à Dapper qui est alors retraité en RSS, de transférer de Dapper à Yahoo pour géolocaliser, puis enfin de Yahoo au client. Si Bloomberg (ou un autre) fournissait directement le flux rss (idéalement déja géolocalisé et gratuitement), on ne serait pas obligé de faire tout cela :)
  

PS: La démo utilise l'objet XMLhttpRequest qui n'autorise pas chez Firefox les requêtes hors du domaine courant, alors que si chez IE. Donc

• si vous utilisez IE, mettez simplement "urlProxy":"" à la ligne 29 dans maps.htm,
• si vous utilisez Firefox, installez un serveur local (localhost) avec la page php_proxy_simple.php fournie en annexe,

Les Rich Internet Applications présentent bien des avantages mais il faut leur reconnaitre un inconvénient majeur du point de vue de l'ingéniérie logicielle: l'obligation de gérer différents navigateurs.
Le marché des navigateurs est dominé par 2 acteurs: Microsoft Internet Explorer (avec environ 80% de PDM en légère décroissance) et Mozilla Firefox (avec environ 15% de PDM en légère croissance). Si IE6 domine encore (45% de PDM), IE7 prend petit à petit sa succession (35%). Du côté de firefox, la version 2 est devenue ultra-majoritaire. Le bilan est donc qu'il convient de veiller en ce moment à la compatibilité de son application avec 3 navigateurs dans le cas d'un développement destiné au grand public.
Il existe des technologies permettant de faire abstraction du navigateur comme les applets Java ou Flash mais cela oblige l'utilisateur à posséder une JVM ou des plugins spécifiques (dans la bonne version) ... et l'ingénieur les compétences.
Une des grosse tendance de ces dernières années est l'utilisation d'AJAX, ce qui revient à utiliser le javascript, le DOM et les feuilles de styles. Si les choses se passent bien en terme de portabilité avec la syntaxe du javascript, les ennuis apparaissent lorsqu'on accède au DOM, chaque browser ne gérant pas les mêmes entités. Les spécifications du W3C vont vers une standardisation mais celle-ci est lente. On retrouve exactement le même phénomène avec les feuilles de styles (les specs sont ici).

Pour y avoir passé plus d'heures que je n'aurais voulu sur différents projets, il est fondamental d'éviter le champ de mines du cross-browser compliance si l'on veut respecter les délais d'un projet de RIA. Pour cela on s'appuiera au maximum sur les librairies et frameworks disponibles en veillant à régulièrement tester le rendu dans les navigateurs cibles et surtout pas uniquement à la fin des développements.
Notez bien que les librairies ne font pas tout. La RIA Alcionbooks est par exemple non complètement fonctionnelle sous IE dans sa V1.0 malgré l'utilisation de scriptaculous et de nombreuses heures passées dessus par Eric.

Depuis le 5 juin, on peut enfin jouer aux 17 jeux de tirage, de grattage et de pronostics de la Française des Jeux sur le web (www.fdjeux.com), grâce à la mise en production d'une version totalement nouvelle du site de jeu, en remplacement d'une architecture basée sur un client applet java et un serveur C/C++. Ce sont désormais près d'un million de comptes joueurs qui sont ouverts 24h/24 sur une plate-forme à laquelle AlcionGroup a collaboré de près, tant sur le plan de l'architecture, que de la gestion de projet et de l'industrialisation.

• Site JSP + jeux Flash/XML/webservices
• Back-end java, framework propriétaire, Tomcat, Oracle
• Plate-forme transactionnelle sécurisée full-https
• Performances : 5000 sessions simultanées, temps de réponse moyen < 0.3s, sur 24 processeurs AIX
• Système de porte-monnaie permettant le micro-paiement
• équipe de 10 développeurs + 10 testeurs, sur 10 mois.

Aujourd'hui, la Française des jeux peut espérer convertir une part significative des 8 milliards d'euros de CA vers le online et ainsi jouer dans la cours des grands de l'e-business français, derrière voyages-sncf.com mais dans le peloton de tête des ténors de la VPC (notamment fnac.com). Avec un avantage majeur pour le online : la possibilité de limiter les mises des joueurs, qui sont parfaitement identifiés, dans le cadre de la politique de "jeu responsable". Limitation impossible dans le réseau des points de vente traditionnels. Enfin, deux scoops :

• en 2007, on pourra également jouer depuis son mobile ; il s'agit d'une tendance lourde, comme on le voit par exemple au Japon ;
• les systèmes hautement sécurisés rendent honnête. Inutile donc de me demander si j'ai un truc, une martingale ou une backdoor !

AJAX (Asynchronous javascript and XML) désigne un ensemble de technologies permettant la réalisation d'interfaces utilisateurs utilisables dans un simple navigateur, mais au rendu bien plus dynamique que le HTML. De plus en plus utilisé sur le web grand public (maps.google.com...), AJAX s'étend aujourd'hui aux applications intra/extranet, en mal d'ergonomie. Dès 2002/2003, Alcion a mené un grand forfait pour la réalisation d'une plate-forme de téléconférence couplée téléphone/web, qui reposait sur les principes AJAX.
Depuis quelques semaines, le développement AJAX est entré dans l'age adulte grâce à la décision de Google de distribuer gratuitement le framework utilisé en interne le Google Web Toolkit (GWT). Une des qualités majeures de cette solution est qu'elle est J2EE et épargne l'essentiel du développement HTML/Javascript au réalisateur de l'application. Cela tombe bien, c'était le plus délicat et sujet aux bugs et aux incompatibilités entre navigateurs.
L'assemblage des widgets graphiques est déclaratif et n'est pas sans rappeler Swing, jusqu'aux mécanismes de listeners pour la gestion événementielle :

public class Hello implements EntryPoint {
  public void onModuleLoad() {
    Button b = new Button("Click me", new ClickListener() {
      public void onClick(Widget sender) {
        Window.alert("Hello, AJAX");
      }
    });
    RootPanel.get().add(b);
  }
}

http://code.google.com/webtoolkit/