Contrat signé

Tout d’abord une bonne nouvelle pour les personnes qui ont suivi ma recherche d’emploi: je suis recruté en tant qu’ingénieur dans la société Intellicore afin d’y effectuer du développement WebObjects.  J’ai signé mon contrat et je suis actuellement en période d’essai. Beaucoup d’excitation pour ce premier contrat de travail, je donnerai quelques retours prochainement.
Merci à tous ceux qui ont suivi l’évolution de ma recherche et m’ont fourni des contacts.

Mise à jour de Wordpress et nouveau thème

Histoire que vous sachiez que je ne laisse pas mon blog à l’abandon, wordpress vient d’être mis à jour à la dernière version à savoir 2.8.5 comblant les dernières failles de sécurités découvertes.
Pour fêter mon changement de statut j’ai décidé de changer le thème du blog. J’espère que le nouveau vous plait. J’ai fait quelques modifications afin de corriger quelques traductions manquantes ou enlever des bugs du thème. Si vous remarquez un problème n’hésitez pas à m’en faire part j’essaierai de le corriger dans la mesure du possible.

Tutoriaux WebObjects

Actuellement je visionne des podcasts mis à disposition par la communauté WebObjects. Je suis en train de préparer un premier billet qui devrait arriver dans la journée. Surveillez mon flux RSS ça devrait arriver bientôt

Expert bien avant l’heure

Flex est une technologie jeune qui a le vent en poupe depuis peu. Combien de personnes en France peuvent justifier une expérience professionnelle d’un an de développement sur ce framework ? Peu.
Aussi malgré le fait que je sorte à peine d’école, je suis considéré comme « Expert Flex ». Les propositions qui m’ont été faites sur Flex était simples: vous savez des choses, utilisez les ! Mais ça ne colle pas vraiment avec ma vision du premier emploi. Je n’ai pas l’âge d’être un expert, j’ai envie d’apprendre des choses, découvrir de nouvelles possibilités. J’ai envie que mon entreprise m’apporte quelque chose en retour du travail que je fournis, et non pas livrer mes connaissances sans en avoir en retour, ou trop peu.

Outil principalement graphique

Lorsque l’on fait une application il y a deux aspects: la logique métier et l’aspect graphique.
Personnellement c’est la logique métier qui m’amuse le plus, la réflexion sur le modèle, les algorithmes, … Faire les fenêtres ne me dérange pas mais je ne suis pas bon d’une part, et je n’ai pas envie de me prendre la tête avec d’autre part. Le soucis avec Flex est que l’on passe la plupart de son temps à travailler sur l’aspect graphique. La principale préoccupation dans le développement en Flex est d’encastrer correctement les éléments d’interface tout en trouvant comment contourner les limitations imposées pour arriver à ce que l’on veut …
Après, je parle pour moi-même ! De très nombreuses personnes s’éclatent sans doute à faire des interfaces bien agencées mais ce n’est pas mon cas, et ça transforme donc souvent Flex en source d’ennui.

Limitations …

Je l’ai abordé précédemment, le framework en version 3 est par endroit vraiment mal foutu. L’API est pauvre, certaines choses sont mal pensées et on finit rapidement par passer plus de temps à réfléchir sur les difficultés de l’outil que sur l’application sur laquelle on travaille… Depuis quelques jours j’ai recommencé à faire du Java et je suis en permanence impressionné par la rapidité et la facilité avec laquelle j’avance. Inutile de luter contre le langage et le framework, au contraire ils aident à aller plus vite !!!
Pour reprendre le point précédent, je dirais qu’avec Flex on passe 20% de son temps à faire du code métier, 30% de son temps à coder des contournements du framework et 50% de son temps à lutter avec les composants graphiques. Un outil bien peu productif donc au final.

Enfermement

Après avoir vu l’effet d’une expérience d’un an, je n’ai pas envie de voir comment je serais traité si je venais à avoir une expérience de 5 ans en Flex… En tant que jeune diplômé j’ai encore la possibilité facilement de changer d’horizon car les entreprises tolèrent que je débute, mais d’ici quelques années ce sera sans doute plus difficile à faire.
J’évite cet enfermement d’une part parce que je ne me vois pas faire du Flex toute ma carrière, mais aussi parce que cela peut s’avérer dangereux. Miser toute ma carrière sur une technologie qui aura peut-être complètement disparu dans quelques années n’est pas rassurant. Même si Flex est à la mode en ce moment, qui sait ce qu’il adviendra dans les 5 ans à venir ? Notamment avec son étroite collaboration avec Flash que beaucoup de gens voudraient voir disparaitre de leur navigateur…

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

Comme vous pourrez l’avoir deviné, je m’appelle Pierre Schambacher. J’ai 22 ans et je termine actuellement le stage de fin d’études de mon école Polytech’Nice Sophia. C’est le 1er Octobre de cette année que je serai diplômé et disponible sur le marché du travail, et c’est afin de trouver un emploi que j’ouvre ce site.

Sur ce site vous trouverez différentes pages pouvant vous être utiles:

• Le CV, une version Web où vous pourrez voir mes expériences professionnelles et mes diplômes, ainsi que télécharger une version imprimable au format classique.
• Les Projets, qui ne sont pas des expériences professionnelles mais des projets réalisés dans le cadre de mes études, ou certain projets personnels travaillés sur mon temps libre.
• Le Profil, où je tente de décrire ma personnalité dans mon travail si vous vous intéressez au moins autant au comportement qu’aux compétences.
• Les Contacts afin de pouvoir me joindre, par téléphone, mail, ou par un réseau social. Merci de n’utiliser ces contacts que dans un but sérieux.

Comme vous pourrez le voir, je suis ouvert à beaucoup de technologies (Java, C#, Flex, Objective C, …). Géographiquement parlant, je suis véhiculé et peux travailler sur Sophia Antipolis, Nice, Monaco ou leurs environs.

Merci à vous pour votre visite. N’hésitez pas à laisser un commentaire afin de me donner vos impressions sur le site afin que je puisse l’améliorer.