Author Archive

Javascript et Maven

Posted by on Mercredi, 29 août, 2012

Le moins que l’on puisse dire, c’est que le  javascript a le vent en poupe.
Le trinôme HTML5/CSS3/Javascript se taille la part du lion pour la réalisation des applications et sites front.
Les plus grands acteurs du web l’ont complètement adopté. Il suffit d’observer le nombre de framworks, les annonces d’Adobe sur l’abandon du flex au profit des standards du web, l’avènement du mobile… Bref tous les indicateurs sont au beau fixe pour faire du Javascript le langage pivot des applications d’aujourd’hui et de demain. Ce langage hier décrié, gagne donc ces lettres de noblesses et attire de plus en plus les “ingénieurs respectables” qui apportent leur savoir-faire.

La conséquence de tout cela est que les projets se complexifient et on y retrouve de plus en plus de concepts jusque là réservés au backoffice : pattern, MVC, injection de dépendance et bien sur industrialisation. Et quel outil mieux que maven pouvait occuper le créneau du build.

Maven et Javascript. Il y a 3-4 ans cela aurait fait sourire, mais maintenant nous l’utilisons au quotidien. Mais pour quoi faire ?

L’intérêt est le même que pour les projets backoffice. Automatiser un certain nombre de tâches tout au long du cycle de vie du projet.

Nous voulons maitriser le processus de build, avoir un système uniforme qui garantie la pérennité du code en :

  • validant le code javascript (jslint)
  • concaténant des fichiers javascritpts ou css
  • minifiant ces fichiers
  • exécutant des test unitaires
  • générant des packages de livraisons …

Nous pouvons également ajouter nos projets dans un outils d’intégration continue comme Jenkins afin d’automatiser les build et les déploiements.

Cela permettra aussi de faciliter les processus de livraison. On imagine facilement des livraisons différentes en fonction du contexte (debug/prod) à l’aide des profils activés lors du build.

On pourra également  générer plusieurs type de “livrables”. Par exemple on automatisera la génération des sources différentes selon un contexte mobile/desktop.

Bref le maître mot est laissons faire maven pour le build et concentrons nous sur le contenu.

Mais contrairement aux environnements Java on est encore loin du célèbre “convention over configuration” et la mise en place peut engendrer pas mal de bidouilles dans vos pom.

La “mavenisation” de nos projet peut se faire à plusieurs niveaux.

assembly plugin/dependancy plugin

Sans utiliser des plugin maven spécialisés nous pouvons jeter un coup d’œil sur les bons vieux plugins maven. Le binôme assembly plugin/dependancy plugin permet de résoudre un certain nombre de situations

En effet l’assembly plugin vous permet de vous constituer une archive facilement déployable dans d’autres projets.

Imaginez par exemple que vous ayez codé un composant complet dans un projet que vous aimeriez utiliser plus tard. Pour éviter les copier/coller, vous en faites une dépendance.

Cette configuration indique d’utiliser le fichier my-assembly.xml qui spécifie les fichiers à inclure dans notre dépendance. On utilise l’id de l’assembleur comme classifier (appendAssemblyId).

Et zou ! Vous voila avec une nouvelle dépendance identifiée par le groupid/artifactid du projet et le classifier choisi.

Du coup au prochain build vous aurez dans le répertoire target le fichier suivant:

groupid-artifactid-version-my-script.zip

Et cette dépendance pourra être utilisée dans d’autres projets grâce au maven-dependency-plugin

On indique juste les attributs de la dépendance ainsi que le répertoire dans laquelle on souhaite la dezipper (outputDirectory)

Ces solution permettent de packager et récupérer des ressources en utilisant maven. Mais il n’y a aucun ajout spécifique lié à nos langages quotidiens.

Pour retrouver des fonctionnalités dédiées au javascript et aux css il faut se tourner vers des plugins spécialisés.

Javascript Maven Plugin

Pour la petite histoire nous avons commencez à l’utiliser en 2011 dans une version 1.0-alpha-1-SNAPSHOT qui est au point mort mais qui apporte un grand nombre de fonctionnalités.

Mais depuis peu une version 2 est sortit et elle à l’air très complète. On en reparlera une autre fois
Alors comment ça se passe avec l’ancienne version ?

Installation

Pour utiliser ce plugin dans votre projet il faut déclarer le repo suivant dans la section pluginRepositories

Vous définissez ensuite votre projet en packaging javascript.

C’est pour cela que vous devez systématiquement rajouter la propriété extension dans la configuration du plugin.

Gestion des ressources

Ce plugin ne gère que les fichiers javascript.

Mais dans le package finale on désire souvent ajouter d’autres fichiers (css,images,html…). La gestion des autre ressources passe par le maven-resources-plugin. C’est à dire que par défaut tous les fichiers présents dans le répertoire src/main/resources seront incluent dans le package.

Pour modifier ce comportement par défaut et inclure d’autres ressources il faut les déclarer manuellement.

Goal compile

Ce goal va permettre de copier l’ensemble des scripts de sourceDirectory (src/main/javascript par défaut) dans le répertoire identifié par outputDirectory (${project.build.outputDirectory} par défaut).

On peut également contrôler les fichiers à inclure ou exclure (à noter que l’exclusion prime sur l’inclusion).

Avec un descripteur (descriptor) les fichiers mentionnés  seront concaténés en un seul fichier. Les autres seront juste copiés.

Dans cet exemple on décide de générer le fichier site.js dans le répertoire build à partir des fichiers file1.js et file2.js

Attention les règles d’inclusion/d’exclusion du pom priment sur les inclusions du fichiers d’assembler.

Le plugin exécute par défaut un goal compile ayant pour id ‘default-compile’. Si vous désirez votre propre configuration sans que le goal soit exécuté 2 fois il suffit de reprendre cet id.

Goal package

Ce goal va permettre de packager le répertoire de build sous forme de jar. Les réglages par défaut sont en général suffisant et il n’est pas nécessaire de rajouter une conf spécifique mais on peut vouloir spécifier un classifier ou indiquer le répertoire à packager

La propriété scriptsDirectory indique le répertoire root qui sera packagé. Donc si vous le faites pointer sur le répertoire contenant vos scripts, vous n’inclurez pas dans l’archive les autres ressources.
De même que pour le goal compile, il existe une exécution par défaut appelée default-package.

Goal compress

Ce goal sera exécuté après le phase de compilation sur les scripts produits. Tous les path sont configurables.

La propriété webappDirectory permet de spécifier le répertoire root et la propriété scripts indique le nom du répertoire dans lequel se trouvent les fichiers javascript à compresser.
Par défaut le compressor utilisé est jsmin mais il est préférable d’utiliser celui de yahooUI car il permet une validation des scripts avant la compression qui fait échouer le build en cas d’erreurs.

Goal inplace

Ce goal est utilisé pour inclure des dépendances javascript dans votre projet. Les dépendances doivent être buildées avec ce plugin pour pouvoir être incluses.

Si par exemple vous avez un framework js buildé de façon autonome vous pourrez alors inclure ces sources dans votre projet. Pour cela il vous suffit de le déclarer en dépendance avec le type javascript

Il faut ensuite configurer le goal pour lui indiquer ou dezipper les sources (warSourceDirectory).
Je mes un / dans libsDirectory et scriptsDirectory sinon le plugin par défaut utilise une arborescence script/libs/lib.

Goal jsunit

Ce goal permet de lancer les test unitaires. Nous ne l’utilisons pas car :

  • il n’est pas facilement transposable (path vers un exécutable de browser)
  • la gestion des ressources à inclure n’est pas aisée (l’inclusion se fait dans les fichiers de test)
  • il fait appel a jsunit qui est obsolète maintenant (on notera la référence à jasmine sur la home du projet :-) )

Du coup nous configurons le plugin en skip test pour pouvoir utiliser jasmine.

Jsdoc

Codehauss fournit également un plugin permettant de générer la jsdoc.

La définition du plugin est :

Et on l’éxécute de la façon suivante :

On indique uniquement la localisation des sources à parser (sourceDirectory).

On retrouve alors dans le target/site/jsdoc l’arborescence du site correspondant à notre documentation.

YUI Compressor Maven Mojo

Comme son nom l’indique ce plugin se concentre sur les problématiques de compression et de validation.

Il ne nécessite pas de packaging particulier et s’insère dans un processus “classique” de build. A vous de voir si vous voulez un packaging war ou jar.

Installation

Pour utiliser ce plugin dans votre projet il faut déclarer le repo suivant dans la section pluginRepositories.

Et il suffit ensuite de le déclarer dans la section plugins de votre pom.

Gestion des ressources

Ce plugin ne manipule que les fichiers js et css. Il se constitue un pool de ressources à partir :

  • des fichiers contenus dans le répertoire définit par la propriété sourceDirectory.
  • des fichiers contenus dans les répertoires de ressources (par defaut src/main/resources)
  • des fichiers contenus dans le répertoire définit par la propriété warSourceDirectory (par défaut src/main/webapp)

La propriété nosuffix permet de ne pas rajouter de suffixe aux fichiers manipulés et de remplacer l’original. Sinon par défaut le fichier compressé est suffixé de -min.

Goal jslin et compress

Le goal jslint permet de lancer une validation jslint sur les fichiers js et le goal compress permet la compresion et la concaténation.

Le résultat de la compression dépend de l’origine des fichiers:

  • Les fichiers provenant de sourceDirectory et des ressources se retrouveront dans le répertoire définit par la propriété outputDirectory
  • les fichiers provenant de warSourceDirectory se retrouveront dans le répertoire définit par la propriété webappDirectory (par defaut
    ${project.build.directory}/${project.build.finalName})

La compression est toujours précédée d’une phase de validation.

Agrégation

Le plugin permet également de concaténer les fichiers js et css en un seul. Ici, pas d’assembleur, les règles d’inclusions et d’exclusions se font directement dans le pom à l’intérieur d’une section aggrégation.

On fournit au plugin une liste de fichiers à inclure ou exclure (l’exclusion étant prioritaire sur l’inclusion).
Pour déterminer le path du fichier traité, le plugin utilise comme répertoire de base le répertoire parent du fichier déclaré dans output.

On peut modifier ce répertoire grâce à la propriété inputDir.

Attention pour un packaging de type war par défaut le goal compress s’exécute pendant la phase process-resources. Du coup des fichiers peuvent être écrasés lors de la phase de Processing du maven-war-plugin. Pour y pallier vous pouvez :

  • déclarer que vos goal s’éxécutent durant la phase package
  • configurer le maven-war-plugin pour exclure des fichiers à copier

Jasmine

Ce plugin permet d’executer les test jasmine.

Il suffit de lui indiquer :

  • le root des sources (jsSrcDir)
  • le root des script de test (jsTestSrcDir)
  • les différents fichiers à inclure dans le contexte d’éxécution (sourceIncludes)
  • les différentes suites de test à exécuter (specIncludes)

Attention, pensez à utilisez au moins la version 1.2.0.0 et à mettre la propriété extension à true. Sinon vous constaterez que vos différentes phases de build sont exécutées 2 fois.

La section sourceIncludes permet de spécifier les fichiers à ajouter au contexte d’éxécution. C’est typiquement ici que l’on ajoute :

  • les librairies et framework (jquery, mootools)
  • les classes à tester

Si vous désirez rajouter des librairies dans votre contexte de test (jasmine-jquery par exemple) il faut les référencer dans la section specIncludes.

Vous verrez alors dans la console le résultat d’éxécutions de vos différents “describe” et “it”

Conclusion

Le plus souvent, dans des projets web nous utilisons une combinaison des différentes solutions décrites ci-dessus. Le pom ci-dessous est représentatif d’un vrai projet web.

  • Avec le maven-resources-plugin on définit les ressources à inclure (images,skin pour les css)
  • On rajoute des dépendances static (css) avec le maven-dependency-plugin
  • On agrège les css en un fichier avec le yuicompressor-maven-plugin
  • On récupère des dépendances javascript avec le goal inplace du javascript-maven-plugin
  • On compile,agrège et minifie l’ensemble des fichiers javascripts avec le javascript-maven-plugin
  • On crée des dépendances spécifiques avec le maven-assembly-plugin
  • On test les scripts à l’aide du jasmine-maven-plugin

L’utilisation de maven est donc possible pour builder vos applications web. La difficulté principale réside dans la gestion des ressources et vous risquez de passer du temps à déterminer les différents path pour contrôler finement le devenir de vos fichiers.
Mais bref, on le constate bien, les outils sont là. Il reste un degré de maturation à franchir, mais gageons que l’engouement suscité fera que, de plus en plus de développeurs Java proposeront des solutions d’intégrations continus.

Spring User Group France

Posted by on Samedi, 29 mai, 2010

Jeudi Olivier nous a fait la présentation de spring-batch qu’il avait faite au Spring User Group France.

C’était bien évidemment très intéressant et vous pouvez d’ailleurs retrouvez la prez ici

Bref je vous encourage à suivre l’actualité du SUGFR pour ne pas manquer les prochaines présentations.

SIlverlight et Expression Blend

Posted by on Samedi, 27 mars, 2010

J’ai eu l’occasion hier de participer à une journée d’initiation à Silverglight en partenariat avec Microsoft et Regard.net animée par Eric Ambrosi. Il s’agissait essentiellement d’une journée de découverte par la pratique des outils de la suite Expression, en particulier Expression Blend.

Cette suite permet d’ établir le lien entre les phases de design et d’implémentations. Elle introduit également un nouveau type de profil que Eric appelle le “designer technique”. En effet il ou elle doit posséder la sensibilité artistique pour pouvoir concevoir et animer une interface utilisateur mais également la casquette technique pour interagir avec les composants (connaitre leur constituants, leur propriétés…)
Rappellez vous Seb et moi même avons souvent abordé le manque qu’il y avait dans le workflow de la conception à l’implémentation. En effet il existe un vide logiciel entre les outils de design et les environnements de développement

Adobe y répond avec Catalyst.

Catalyst permet de commencer un projet en partant du travail du designer (photoshop, illustrator…). On peut ainsi animer les calques et créer de véritables composants. Dans l’idéal l’ingénieur récupere ainsi les vues pour y pluger son code métier.

J’ai été relativement impressionné par l’avance de microsoft sur ce type de d’outils. Blend est en effet relativement complet et permet

  • la conception des interfaces (mise en place des composants modifications de leur propriétés, créations de ressources réutilisables ….)
  • la conception d’animations (enregistrement sur une timeline des transitions au niveau d’un ou plusieurs composant…)
  • la conceptions d’états (gestion des propriétés d’un ou plusieurs composants  au seins de différents états)
  • l’utilisation de source datas générées pour simuler le comportement de l’interface…

A tout moment le fichier xaml généré peut être ouvert dans visual studio pour permetre de travailler sur le code behind en C#.

Bref au final je pense que Adobe et Microsoft vont dans la même bonne direction en proposant un expérience utilisateur très performante, visuelle et en offrant des solutions pour faciliter leur mise en place.

PS: Au final j’en ai profité pour tester en live Surface. Bluffant……

Back from MAX 2009

Posted by on Mardi, 20 octobre, 2009

Aujourd’hui j’ai assisté à la session Back from MAX 2009Yan de Baao, Thibault et  Michaël nous ont parlé des dernières annonces du Max 2009 avec en vrac :

  • les nouveautés de flex 4 et de flash builder 4 (amélioration de la coopération entre spark et halo, rajout de propriété style aux composants spark,  renommage de composants…)
  • LiveCycle Data Service3 et le model driven development (je reviendrait dessus)
  • LiveCycle Collaboration Services (ex projet Cocomo)
  • Et la news passée inaperçue….Flash sur l’iphone

Des ateliers thématiques permettaient de préciser ces différents sujets. J’ai assisté au 2 ateliers suivants :

Flash Catalyst

Il s’agissait de présenter les nouveautés apportés par la Béta 2. Au programme :

  • Plus d’effets et de transitions
  • Un nouveau composant scrollable
  • La possibilité d’exporter le résultat en Air

La démo est toujours aussi bluffante mais je suis de plus en plus partagé sur l’apport de Catalyst sur de grands projets. Tout d’abord la version actuelle ne permet pas des allers/retours entre catalyst et flash builder ce qui la rend inutilisable. (même si ce défaut devrait être corrigé dans la 1.0… ou pas…). J’étais pourtant plein d’espérances pour ce projet qui est le chainon manquant entre le designer et le développeur. Je reste convaincu que c’est un outils de prototypage excellent mais je suis septique pour la communication Catalyst/flex. J’ai hâte de l’éprouver….

LiveCycle Data Services 3

Michaël nous a présenté  LCDS avec:

  • le remoting (blazeds)
  • le messaging avec un push en temps réel (super…)
  • la génération de pdf
  • Et surtout le model-driven development

L’idée est de confier au modèle un maximum de responsabilités. A partir d’une source de données un modèle est déployé avec une vue particulière dans Flex builder. L’ensemble des services et value object sont générés et accessibles dans la vue designer. De là on peut:

  • relier les données à une datagrid par simple drag and drop
  • créer des formulaires crud en 2 clic
  • paramétrer des filtres ou des conditions directement au niveau du modèle

En java la synchronisation des données est assurée par LCDS.

Idéal pour réaliser une application CRUD (simple)  en trois clic…

Et pour finir cette journée, un super buffet,des discussions techniques, des rencontres, des goodies….

FLASH CATALYST ET FLASH BUILDER 4

Posted by on Jeudi, 4 juin, 2009

Hier, Adobe a présenté à la communauté les derniers arrivants de leur offre et concrètise leur plateforme Flash composée des trois produits : Flash Pro, Flash Builder et Flash Catalyst.

Flashbuilder 4 (ex: flexbuilder) correspond à l’environnement de développement RIA.
De nombreuses modifications ont été apportées à l’outil:

  • augmentation de la productivité (refactoring, génération de getter/setter, génération de handler d’évènement….)
  • amélioration de la gestion des données (introspection des services distants, génération de classes…)

Le modele de composant à également été relooké. En effet les composants natifs sont maintenant déclinés sous la forme de MVC. L’ambition est de faciliter le skinage des applications flex. D’après Adobe FB4 devrait aussi d’offrir un environnement de développement pour l’AS3 et non seulement pour Flex.

Le deuxième outil présenté était Flash Catalyst. Ce produit peut prendre en charge des fichiers Photoshop, Fireworks, Illustrator. Il propose (via une interface étudiée sur les modèles des logiciels créatifs/vidéo) d’animer les éléments ou page et de skiner des composants (boutons, scroll, etc..).
A tout moment, le designer peut rééditer des éléments graphiques de sa maquette via Illustrator et récupérer automatiquement ses modifications dans Catalyst.

Catalyst a pour vocation de permettre aux designers  :

  • De prototyper/animer simplement leurs interfaces (pour des présentations clients)
  • D’exporter l’interface animée vers FlashBuilder afin qu’elle soit directement utilisable par le développeur sans phase de découpage d’images ou de skinnage manuel des composants et tout en conservant les animations produites dans Catalyst.

Les échanges entre Catalyst et Flex seront bi-directionnelles pour la sortie finale de la V1 de Catalyst : Il sera donc tout simplement possible d’éditer un projet FlashBuilder dans Catalyst et de reskiner a la volée certains éléments.
Par contre, l’utilisation de Catalyst est exclusivement réservée aux créas qui organisent les calques dans des dossiers et nomment chacun des calques. Sans cette rigueur, Catalyst devient totalement inutilisable.

Pour Catalyst les avis sont très partagés. Il semble que les possibilités soient quand même limitées (en terme d’effets, de retour….) mais se prête particulièrement à de la RIA. Les fans d’animations “Wahoo” devront malheureusement conserver leur Flash Pro :) . J’attend de le tester sur un vrai projet pour valider le workflow complet et de constater le gain de productivité…

A suivre

BAAO ET SON FLEX ROAD 2009

Posted by on Mercredi, 27 mai, 2009

J’étais hier à un atelier Flex proposé par Baao en partenariat avec Adobe. L’objectif de cette journée était de présenter  les possibilités de Flex et Air. L’initiative est vraiment très bonne tout d’abord car l’atelier est gratuit. Mais au delà de cela je trouve la “formation” très équilibrée pour une seule journée. On arrive néophyte et on en repart avec  :

  • le principe de base du fonctionnement de Flexbuilder
  • le code de  notre première appli flex (un player vidéo..)
  • Les principes de base d’échange avec le serveur via blazeds
  • Une appli Air….
  • Des slides….

Pas mal en 8 heures

La cerise sur le gâteau petit déjeuner et repas offert ( et on mange bien …)

J’entends déjà les raleurs du fond me dire oui mais c’est qu’à Paris ….pfff

Et bien non car Baao organise un FLEX ROAD et ces ateliers sont proposés dans plusieurs grandes villes de France.

Alors si vous ne connaissez pas encore Flex je vous recommande vraiment de vous inscrire aux prochaines sessions.

Les tontons flexeurs…et les performances

Posted by on Lundi, 30 mars, 2009

J’étais ce soir au dernier événement organisé par les tontons flexeurs. Le thème aujourd’hui était “Flex et les performances à Paris”. Une soirée très sympa sur un thème très intéressant. Les 3 intervenants ont promis que leurs présentations seraient disponibles sur le site des TTF. En attendant en voici un résumé:

Yann Chevalier de BaaO nous à parler de Flex et des performances en évoquant les points suivants

Julien Revel de KapIT a abordé le problème des mémory leak en Flex. J’étais habitué à ce type de problématique en javascript et moins en Flex. Julien nous a présenté:

  • le garbage collector de Flex plutôt performant
  • Les principales sources de leak (les custom tooltip, les poppup, les fenêtres transitoires …)
  • au contraire les “leak safe” (binding interne, le model locator dans cairngorm, les events listener d’objets transitoires vers des objets permanents..)
  • Les “suspects” (Array, map, timer actif, listener vers des objets transitoires…)
  • Des outils pour reperer les leak (essentielement kapInspect et son memory leak plugin)

Enfin Michaël Chaize de Adobe (je vais quand même pas inserer le lien d’adobe…) nous a parlé des échanges de données autour de LCDS. Avec entre autre :

  • la dualité du choix entre un couplage faible avec un format d’échange traditionnel (XML, SOAP, REST) moins performant et un couplage fort propriétaire (RMI, AMF) avec une démo à l’appui sur Census
  • Le data Service et son implémentation coté Serveur (DAO, Assembler et config LCDS) et sa mise en place en flex
  • La démo d’un outils réalisé en interne illustrant les mécanismes de synchronisation et de persistance entre plusieurs clients.

Bref une belle soirée. Vivement la prochaine…..

Some tools for flexing…

Posted by on Dimanche, 25 janvier, 2009

KapIT release in it lab area some tools among which we find:

  • KapInspect

KapInspect is the flex equivalent of the famous Firebug console. Activated on a simple click it allows to inspect all the flex components of the page, to show and to modify their properties.
kapi

Those consoles allow to show at runtime the various components of the framework.

mvc

The integration is quite simple. After setting the .swc component in the project classpath, you just have to add the good tag in your mxml file.

For example :



...


Then to open the console just make a Ctrl+Alt+Click in the flash stage. Notice that you can use the various consoles simultaneously
For pureMVC console you have to change your Facade class to extend DebugFacade. You’ll find explanationhere

Des outils pour Flexer….

Posted by on Dimanche, 25 janvier, 2009

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.
kapi

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

mvc

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 :



...


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

SINGLETON in as3

Posted by on Samedi, 8 novembre, 2008

To implement the pattern singleton in action script we quickly collide with a limitation of the language: we cannot return a private constructor and it is the base of the pattern.
By looking on internet we find several more or less evolved solutions which allow to protect the usage of the constructor.Often an exception is raised if it is not called by the static getInstance method.
The inconvenience of this approach is that the error is raise only during runtime and not in the compilation. In the book “ActionScript 3.0 Design Patterns” the author proposes another approach.
Read the rest of this entry »