26 mars 2010

Flash à bout de souffle (?)

Quand on parle d'interface web sexy, on pense souvent à Flash. Il faut dire que les années IE6 (qui se prolongent pour certains) ont fait des dégâts pour la réputation de JavaScript et que Flash était la seule solution viable.
Aujourd'hui HTML5 est mature et bien supporté par les navigateurs récents. Le ralliement d' IE 9 est un signe des temps qui montre que c'est bien la plateforme du futur.

OK mais qu'en est-il de la productivité des développeurs ?

Personnellement je suis fan de GWT car il me permet de rester dans le même langage sur toute ma chaîne de développement. Mais ceux qui ont franchi le pas d'apprendre ActionScript et d'acheter FlexBuilder n'ont pas ce genre de considérations.

Je tombe via Ajaxian.com sur ce billet, qui décrit l'abandon de Flash pour HTML5 (canvas). L'intérêt de ce billet n'est pas la prouesse technologique de faire "aussi bien" que la référence Flash - quoi que c'est déjà intéressant pour ça - mais qu'il argumente le pourquoi et les avantages de cette migration.

  • moins de code et un "livrable" plus compact. Une bonne baffe pour ceux qui voyaient dans le format binaire de Flash un argument de compacité;
  • un meilleur support sous Linux (j'y ajouterais les plateformes mobiles, qui ne sont pas la cible ici);
  • une chaîne de production plus simple, en l'absence de phase de compilation;
  • une meilleure intégration avec le reste de la page web (événements clavier, gestion du curseur ...)

Cependant, le billet met aussi en évidence les points forts de Flash :
  • support des polices de caractères embarquées;
  • des manques dans HTML5 sur la manipulation de fragments HTML, le clipping et le rafraichissement

HTML5 n'est donc pas la solution miracle à tous les problèmes (chaque techno passe par une phase où tout le monde y voit le messie avant de comprendre qu'elle a ses limites et ses faiblesses). Par contre c'est une alternative viable et performantes à Flash pour de nombreuses utilisations. Dans certains cas, cela peut même être une solution plus universelle et plus performante (il n'y a toujours pas de lecteur Flash sur l'iPhone à ma connaissance)

23 mars 2010

Un Nexus "agence"

Au premiers temps, j'ai géré un "maven_proxy", lequel s'est rapidement noyé sous une masse de jars hétéroclites. Il faut dire qu'à cet époque il n'y avait pas de consensus sur le référencement des apis Java, sans parler de la migration vers Maven2 qui s'est jouée pour nous à cette époque. Il en ressort un répertoire maven_repo avec des doublons, triplets, voir plus (6 versions de EJB2.jar).

J'ai alors contribué à Archiva pour supporter la conversion à la volée des requêtes Maven1 sur une repository Maven2. Ca m'a valu mon titre de committer puis de PMC sur le projet. Archiva a ainsi tourné quelques temps en version SNAPSHOT pour remplacer le proxy vieillissant. Si le service était là, ça restait du developpement "direct to production" pour corriger les divers problèmes rencontrés.

Force est de constater qu'après cette date j'ai manqué de temps pour contribuer à Archiva, et que le repository associé, géré par un Archiva 1.0 en manque de suivi, est lui aussi parti en vrille. Au dernière nouvelles, il n'arrive plus à télécharger de nouveaux JARs (sans doute à cause des métadonnées), et la tentative de mise à jour vers une version récente d'Archiva a été un échec. Il faudrait reconstruire toute la conf et le repo, pas le temps ...

Je me tourne donc vers Nexus, que j'ai du installer pour un gros projet afin de publier des SNAPSHOTs, évitant à chaque membre de l'équipe de devoir ouvrir 20 modules sous Eclipse. Il faut bien l'admettre, Nexus marche très bien et sa configuration de base est à la portée du premier venu.

Le temps est donc venu de trahir ceux qui m'ont offert mon eMail en "@apache.org" et de renier Archiva pour passer à Nexus -- le côté obscur de la force, tout ça.

Step 1 : demander la création d'une VM - avec un gros disque - et y installer un Ubuntu (y'a que ça de vrai)

Step 2 : suivre la doc de Nexus qui est tellement bien faite que ça fait mal pour les autres

Step 3 : configurer les proxies qui vont bien pour récolter sur le Net toutes les bibliothèques qui vont bien

Step 4 [c'est là que ça devient intéressant] : jouer avec les rôles pour autoriser finement l'accès au repository private, là où chaque projet va pouvoir déployer ses propres artefacts. L'idée est de fournir un réceptacle commun, afin de limiter la conf, mais de restreindre l'accès en fonction des projets considérés pour ne pas risquer de se marcher sur les pieds. Je ne cherche pas à réinventer la poudre, je me base simplement sur les articles qu'on trouve sur le blog de sonatype [1] et [2].

Résultat des courses : 
En deux heures à peine, j'ai un système qui sert de cache pour les accès au repos central, jboss, apache.snapshots et compagnie. Pour chaque projet qui en fait la demande, je crée juste un nouveau rôle correspondant au groupId sélectionné et un user avec ce rôle. Le projet peut alors déployer à sa guise ses propres binaires.

Dans les quelques cas où un binaire "commun" est proposé, si on me fournit des métadonnées propres, une identification de version bien faite et tout ça, j'upload dans le repo thirdParty pour tenir compagnie au driver jdbc Oracle et aux classes du client MQSeries.

Pour les projets qui n'arrivent pas, ou n'ont pas l'habitude d'identifier la version exacte ou la provenance d'un binaire (généralement un legacy ou un progiciel), le déploiement est fait dans le groupId du projet, pour éviter de polluer le reste du repository avec des artifacts peu fiables.

Conclusion :
Les mécanismes avancés de Nexus en font une solution de choix. Si je n'ai pas fait un monitoring aussi poussé qu'Arnaud sur le sujet, il est clair qu'il est plus stable et moins consommateur qu'Archiva. Par ailleurs, installation et configuration sont un jeu d'enfant, qui plus est avec une doc d'une grande qualité. Et pour ceux à qui ça ne suffirait toujours pas, il y a encore la version "Pro" avec des fonctionnalités encore plus riches, à voir si vous en avez l'usage.

Nexus me retire une aiguille du pied, nous avons maintenant un repo "agence" fiable et facile à administrer. Une ressource facile à mettre en commun et qui facilite la vie.