Tout d’abord, vous pouvez librement télécharger mon cours (bien que sans doute peu explicite sans le discours prévu pour l’accompagner) ainsi que le TP.

Bonjour, je suis votre prof aujourd’hui

C’est assez impressionnant de rentrer dans une salle pour y faire cours, et que tous les élèves viennent vous saluer en arrivant… car en effet il y a encore un mois j’étais un étudiant comme eux et je connaissais déjà la plupart de mes élèves. Évidemment cela aide d’une part à être en confiance et d’autre part à avoir le calme dans la classe

Le Cours

Concernant le cours en lui-même, je savais que je serais probablement limite pour tenir les 2h prévues, mais la réalité s’est avéré encore pire que prévue. Une fois devant cette 15aine d’étudiants (et amis) je n’ai pas pu m’empêcher de tracer à vive allure, enchaînant slide sur slide et arrivant au bout bien plus vite que prévu… Certains m’ont dit en fin du cours qu’ils auraient aimé que je ralentisse mais personne n’a osé m’interrompre, dommage

J’ai eu un certain nombre de questions en fin de cours, portant plus sur les cas où Flex est un bon choix que sur des points techniques, c’est bon signe d’une part sur l’explication que j’en ai faite et sur leur maturité de réflexion d’autre part. Dommage en revanche que mon expérience Flex se soit faite sur un projet confidentiel, m’empêchant de dire beaucoup…

Le TP

Après une longue séance « install party » de Flex Builder, nous voilà partis pour un TP avec pour objectif de développer un client Twitter. Je suis assez satisfait dans le sens où beaucoup sont allé assez loin dans un petit projet qui pouvait s’avérer ardu pour un néophyte. J’ai même quelques étudiants n’ayant jamais vu Flex (ou JavaFX ni Silverlight) qui sont arrivés à terminer le client avec toutes les fonctionnalités demandées (Yohann si tu me lis ).
Autre chose que j’ai remarqué, beaucoup ont préféré me pauser des questions sur la marche à suivre plutôt que de chercher sur Google, j’espère que c’était parce qu’il s’agissait d’un cours et qu’ils ont bien le réflexe de chercher sur internet ailleurs. En tout cas j’ai été bien occupé pendant ces 2h et je remercie encore Christian et Sandie qui m’ont assisté pour répondre à toutes les questions. En tout cas, coup de chance mis à part un plantage d’une configuration eclipse j’ai pu répondre à toutes les questions

Au final, quoi dire ?

Premièrement j’ai ressenti la certaine « expertise » pour laquelle on m’a demandé d’intervenir dans le sens où je ne sais plus vraiment ce qui est évident et ce qui ne l’est pas. Le TP notamment contient de nombreuses explications de choses qui ont été lues en diagonales car évidentes, mais en revanche je ne dis rien sur le fonctionnement d’un HTTPService qui n’est pas des plus simples pour le néophyte. Si j’avais à recommencer je m’aiderais surement de quelqu’un n’ayant jamais touché à Flex pour vérifier que je n’oublie pas de parler d’un point difficile et que je ne m’étends pas sur une évidence.
Deuxièmement j’ai été surpris par la rapidité de compréhension de mon auditoire. Comme je l’ai déjà dit nombreux sont ceux qui se sont bien avancé dans le TP et plusieurs l’ont terminé. Je ne pense pas que ma prestation ait quelque chose à voir là dedans, je pense tout simplement avoir eu un bon auditoire attentif et sérieux et je sais ma chance sur ce point.
Troisièmement et dernièrement, un cours est quelque chose de long à préparer. Il m’a fallu une bonne demi journée pour préparer ma présentation et encore un peu plus pour le TP. L’élaboration du TP est vraiment longue du fait que l’on code quelque chose, qu’on en vérifie la robustesse, et il faut ensuite trouver comment guider les élèves à faire ce que l’on vient de faire, en les aidant un peu mais pas trop non plus. Malgré le temps que j’ai consacré à toute cette préparation, le cours était très loin d’être parfait mais j’espère que j’aurais l’occasion une prochaine fois de faire mieux.

Il me restera de cette expérience des connaissances sur Flex et Java/WebObjects, mais aussi beaucoup de choses sur l’architecture logicielle, l’organisation dans les petites entreprises, la gestion de projet, les rapports humain et bien d’autre chose encore.

Je ne sais pas encore où je vais travailler. Actuellement je cherche toujours un emploi (voir mon CV).
Plus de nouvelles bientôt.

À venir bientôt un tutoriel très complet sur GIT, la version en ligne de mon cours sur Flex à Polytech’Nice Sophia et j’espère pouvoir me lancer et parler de mes premières impressions sur COCOA.

Adobe Flex est un framework de développement de clients riches (ou clients lourds) compilé vers la machine virtuelle Flash. Pour les personnes connaissant Silverlight, Flex a inspiré Microsoft pour sa création. Les interfaces sont réalisées à l’aide d’un langage basé sur XML, le MXML (XAML pour Silverlight) et le comportement est écrit à l’aide du langage Action Script 3 (.Net pour Silverlight).
Il ne surtout pas considérer Flex comme un outil fait pour les designeurs, c’est un framework créé pour les développeurs.

Déploiement

Comme dit dans l’introduction, Flex est compilé dans un fichier SWF qui est lu par la machine virtuelle Flash. Pour lire une application Flex, la version 9 du plug-in est au minimum nécessaire, or plus de 95% des personnes répondent à ce besoin. C’est un point assez fort du framework, surtout en comparaison avec Silverlight qui peine à passer les 30% (toutes versions confondues).
Étant donné que Flex se base sur le plug-in Flash, vous bénéficiez également d’une compatibilité entre les différents systèmes d’exploitation et les différents navigateurs. Pas de mal de tête à assurer le même rendu entre IE6 sur Windows et Safari sur Mac, c’est le travail des gens d’Adobe.
Pas de doute ici, c’est un gros point fort et un très bon travail d’Adobe qui donne à Flex un avantage certain sur ses concurrents directs. On pourra également remarquer sur l’utilisation de Flash la mise à disposition d’une excellente librairie pour créer des animations de l’interface qui donnent un cachet très professionnel aux applications.

ActionScript et API

Le comportement et le business d’une application Flex est décrit dans le langage ActionScript 3. Pour le langage en lui-même, il est souple et propose un certain nombre de fonctionnalités puissantes et pratiques, je citerais en exemple la possibilité d’appeler une méthode sur une variable à l’aide de l’opérateur [] comme suit: maVariable["maMethode"].
En revanche on peut vraiment reprocher à Adobe la pauvreté de l’API. Pour l’anecdote, sachez que la méthode addAll permettant d’ajouter tous les éléments d’un tableau dans un autre tableau vient d’être implémentée dans la version 3.4 du framework … Sachez également que la gestion de dictionnaire est extrêmement réduite, impossible par exemple de récupérer l’ensemble des clés d’un dictionnaire …
Il est certes possible d’écrire soit-même toutes ses classes, mais d’une part on n’a pas forcément envie de coder toutes les classes de base lorsque l’on s’attaque à un projet ambitieux et d’autre part, si Adobe comble le manque un jour il faudra faire le remplacement partout.

Modèle MVC

A première vue, Flex semble proposer une bonne architecture pour respecter le pattern Modèle-Vue-Contrôleur avec les interfaces et leur comportement décrites en MXML, des classes de comportement et des classes de modèle. Cependant en pratique, on a rapidement tendance à mélanger la vue et le contrôleur. En effet il est possible d’écrire de l’ActionScript dans le fichier MXML et la tentation est grande d’y écrire le code business de la vue.

Quelques framework tentent d’imposer de bonnes pratiques (je citerais Cairngorn et Tide) mais ils ne sont pas toujours simple à mettre en place. En pratique il devient également difficile de maintenir du code propre au sein d’un projet de grande envergure. Le projet peut être découpé en modules qui sont chargés à la demande, mais on arrive assez facilement à des dépendances inter-modules ou de la recopie de code pour effectuer la même action dans deux endroits différents mais inaccessibles entre eux.

Asynchronisme et thread unique

Le plug-in Flash est presque mono-threadé. Je dis presque car en réalité un deuxième thread existe, qui attend les réponses aux requêtes effectuées vers des adresses externes. De cette situation ressort deux choses.

Toute demande de données est asynchrone. La demande est déposée vers le thread de communication qui propagera un évènement lorsque celle-ci sera complétée. S’il n’est pas dérangeant que vos données arrivent de façon asynchrone, pas de soucis mais dans le cas où vous aimeriez attendre d’avoir concrètement les informations, vous allez commencer à rencontrer des difficultés.

Il est impossible d’effectuer deux actions à la fois, cela incluant le dessin de l’interface ou le traitement d’un clic souris. Par conséquent, si vous lancez un traitement lourd de calculs, l’interface sera figée. Avantage en contrepartie, vous n’avez pas du tout à vous préoccupé de problèmes de validité des données entres threads ou de deadlocks, cela est impossible !

Bindings

Il est possible dans les interfaces MXML de réaliser des « bindings » entre une variable ActionScript et une propriété d’un élément graphique. Une fois le binding mis en place, la modification de la valeur de la variable entrainera la modification de la valeur de la propriété de l’élément graphique. Cela est très pratique puisque le mécanisme permet de réaliser à vitesse grand V l’écran de visualisation d’un objet Business en « bindant » sur ses différents attributs.

Dans la version 3 de Flex quelques embuches appaissent pour mettre en place des double bindings, c’est à dire que les modifications de valeur s’effectuent dans les deux sens. En effet, le premier binding mis en place aura pour effet d’effacer la valeur d’une des deux variables avec la valeur de l’autre. Dans le cas d’un objet business et un objet graphique, il vaut mieux effacer la valeur de la propriété graphique avec celle de l’objet business et non pas le contraire … Ce petit problème a été corrigé dans Flex 4 qui sortira prochainement.

Flex est un outil

En conclusion de l’article et avant de tirer avantages et inconvénient, j’aimerais donner un avis très subjectif sur le framework. Flex un outil jeune mais toutefois puissant pour développer rapidement les applications pour lesquelles il a été créé. Et je vais insister sur ce point.

A mon idée, Flex est parfait pour des applications simples, avec peu de code business. La manière classique de travailler va être d’appeler un WebService ou une page Web, parser les résultats pour remplir des variables sur lesquelles l’interface est bindée. Le résultat sera obtenu rapidement, propre, et joliment animée.

En revanche, Flex n’est pas fait pour une lourde application avec de nombreuses implications de code business entre les écrans et des grappes d’objets à récupérer, modifier, renvoyer, etc. Pour avoir tenté d’utiliser le framework pour ce type d’application, je peux dire qu’on passe plus de temps à lutter contre Flex qu’à lutter contre les difficultés de l’application elle-même.

Comme beaucoup d’autres framework, Flex est un outil. Flex est un tournevis cruciforme. Si votre application est faite de vis cruciformes, ce sera un excellent outil et vous allez aboutir rapidement à un résultat de qualité. Si en revanche vous devez fabriquer une chaise avec des clous, vous êtes condamné à taper sur les clous avec le manche, et au final vos clous seront plantés de travers, votre chaise sera bancale et s’effondrera à la troisième personne qui tentera de s’assoir dessus et enfin vous vous serez fait mal à la main.

Mais assez parlé et voyons le bilan avantages/inconvénients

Avantages

• Compatibilité OS/Navigateur
• Plug-In flash très répandu (95%)
• Animations simple à utiliser et très classes
• Pas de problématique de programmation concurrente
• Mécanisme de binding très pratique

Inconvénients

• Inconvénients de Flash (vous devriez les trouver facilement sur d’autres sites)
• Pauvreté de l’API ActionScript
• Trop grande facilité de mélanger Vue et Contrôleur
• Impossibilité d’utiliser la programmation concurrente
• Obligation de récupérer les données de façon asynchrone
• Doubles bindings laborieux (résolu normalement dans Flex 4)

WebObjects est un framework initialement développé en Objective C par la société NeXT de Steve Jobs qui sera ensuite rachetée par Apple. Il est constitué d’une couche basse d’abstraction de la base de donnée appelée EOModel, d’une architecture de gestion de cache et de persistance et d’un moteur de template. WebObjects passera progressivement d’Objective C à Java vers l’an 2000. Bien que différents par de nombreux points, il est comparable aux technologies J2EE.

Je tiens à signaler que mes commentaires sont faits sur la version 5.3 de WebObjects et je ne sais pas si certaines choses n’ont pas été corrigées en version 5.4.

Coût de formation et cadre de développement

Soyons assez clair, le coup d’entrée de WebObjects est assez élevé. Le framework a été pensé pour réaliser des projets d’entreprise et vous ne pourrez pas sortir une page de démonstration en moins d’une heure comme le proposent des plateformes de développement comme Google App Engine. En revanche, une fois formé à l’architecture logiciel vous disposerez d’un cadre de programmation assez stricte dans la forme, mais souple dans les possibilités. Comprenez que vous pourrez faire à peu près n’importe quoi, mais pas n’importe comment. À mon sens, c’est un avantage puisque vous êtes à peu près certain que les personnes utilisant WebObjects vont travailler relativement proprement, contrairement à d’autres technologies où il est possible de faire tout et n’importe quoi, surtout n’importe quoi.

Tenue de charge et modularité

WebObjects est designé pour être capable de gérer de grandes charges, aussi les données sont toujours chargées progressivement au moment où elles sont réellement nécessaires. Au niveau du fonctionnement lui-même, le framework est construit autour de dictionnaires de données. Par exemple pour les attributs d’un objet, les getters vont simplement chercher la valeur dans un dictionnaire à partir du nom de l’attribut. C’est de ce mécanisme que vient toute la souplesse de WebObjects puisqu’il est possible de faire évoluer dynamiquement le modèle pendant l’exécution. Même si les occasions d’utiliser une telle possibilité sont assez rares, elles sont quasiment impossible à réaliser autrement.

Mélange d’API

Comme je l’ai dis dans mon introduction, WebObjects reposait initialement sur le langage Objective C, mais a été migré vers le langage Java depuis plusieurs années maintenant. Cependant les choix qui ont été faits me laissent quelque peu sceptiques. En effet afin que les personnes ayant travaillé avec l’Objective C ne perdent pas leurs connaissances acquises, les classes de  base de NeXT ont été portées en Java. Un ingénieur d’expérience sur l’API Java sera donc un peu perdu face aux NSArray, NSMutableArray et autres NSDictionnary. Pire encore, ces classes implémentent des interfaces de l’API Java, mais n’implémentent pas les méthodes qu’elles apportent, se contentant de propager une exception ! Assez perturbant donc et pouvant se révéler source de surprises.

[MISE A JOUR]
On me signale que le problème des exceptions sur les méthodes ont été corrigé en version 5.4 sauf dans les cas où il y avait une raison. Je m’explique, en WebObjects il éxiste deux types de tableaux, les NSArray en lecture seul et les NSMutableArray en lecture écriture. Bien évidemment la méthode ADD n’a aucun sens dans un NSArray qui ne supporte que des GET. En revanche la méthode ADD ne NSMutableArray ne demande plus d’utiliser à la place la méthode addObject.
Il reste toutefois que quelqu’un ayant utilisé un certain temps les classes de la JRE de base, ArrayList et autres, aura besoin d’un petit temps d’adaptation.

Trouver des personnes

Abordons finalement un point assez critique: les ressources. Il sera difficile à la plupart des personnes ayant des années d’expérience sur des plateformes J2EE de se former à WebObjects en raison des différences conceptuelles et à l’API s’écartant de celle de Java. Le coup de formation est assez élevé et l’intégration à des processus d’entreprises comme Maven, bien qu’existant, peut s’avérer coûteuse en temps.
En comparaison d’autres framework, WebObjects souffre d’une très faible documentation. Le site d’Apple propose une documentation technique, mais très peu d’autres sites proposent des exemples ou des explications différentes de la version officielle. On se retrouve donc facilement le bec dans l’eau devant un problème dont la solution n’est pas documentée sur le site d’Apple. Une solution existe: la mailing list qui est fréquentée par des experts de la technologie, mais on ne peut évidemment pas abuser et questionner ces personnes en permanence.
Il est très profitable d’avoir au sein de son entreprise une personne expérimentée en WebObjects donc, cependant il s’agit d’une ressource rare. Lors d’un recensement récent, 800 développeurs ont été dénombrés dans le Monde, dont 40 en France. Autant dire qu’il est difficile de se procurer un « expert » dans le domaine, sachant que connaissant la technologie, je ne me considère pas du tout comme un expert, mais un simple utilisateur.

En conclusion, voici un petit récapitulatif de ce billet en avantages/inconvénients.

Avantages

• Framework avec architecture
• Développement propre
• Flexible
• Pensé pour tenir la charge

Inconvénients

• Peu de ressources et très peu d’experts
• Mélange d’API Java/Objective C
• Manque de documentation tierce