EclipseCon France 2013

  • Sharebar

L’EclipseCon France 2013 s’est déroulée les 5 et 6 juin 2013 à Toulouse. Voici les présentations les plus marquantes auxquelles j’ai pu assister.

Git & EGit beginner workshop

EGit est le « team provider » Eclipse pour travailler avec Git. Cet atelier était un tutoriel destiné aux débutants, pour ceux qui, comme moi, n’ont pas encore eu l’occasion de s’y frotter (tout en en ayant entendu beaucoup de bien…)

Alors, certes, un SCM distribué, c’est agréable : vous pouvez travailler (commit) dans votre coin et  publier plus tard vos travaux à vos coéquipiers. Mais il faut bien avouer que cela induit une certaine lourdeur. Il y a de nouvelles commandes à apprivoiser, en plus des classiques commit, update, merge : rebase, pull, push et j’en oublie certainement…

Actuellement utilisateur régulier de CVS et occasionnel de SVN, j’ai notamment apprécié une fonctionnalité de Egit : la « staging area », une sorte de « commit wizard ». Il s’agit en fait d’un espace temporaire dans lequel vous pouvez construire votre commit en y ajoutant et enlevant des fichiers, et en saisissant le commentaire (si souvent négligé et pourtant si utile !)

Remarque : CVS dans Eclipse propose une fonction à peu près similaire (et peut-être un peu plus complète) mais assez cachée : les « change sets ».

Mais bien sûr, l’immense avantage de Git, c’est la vue « Historique » qui présente un graphe complet (et pas juste une liste de commits triés par date). Reste à savoir à quoi ressemble ce graphe après quelques années…

Un petit reproche : quand on fusionne deux branches, en cas de conflits, le réflexe de EGit est de modifier le code source en incluant les marqueurs textuels du diff classique. J’aurais préféré une prévisualisation avec un éditeur graphique de différences (« two-way compare »). Remarque : cet éditeur peut être ouvert sur  le fichier source en conflit après la fusion pour aider la résolution.

Mon impression générale : si CVS proposait une solution simpliste au problème complexe du SCM, Git propose une solution plus complète mais aussi beaucoup plus complexe. L’intégration dans Eclipse est bien faite mais manque de fluidité dans son utilisation. Elle demande un investissement non négligeable.

Tycho: the mandatory tool to build your Eclipse based product

Tycho est une extension de Maven dédiée à la construction de produits Eclipse (OSGi, p2) : plugins, features, update sites, products, etc.

En plus de la construction d’artefacts, Tycho peut prendre en charge l’exécution de tests unitaires (y compris de l’interface graphique avec SWTBot comme démontré lors de cet atelier). Et tout cela pour toutes les plateformes que vous voulez : selon l’OS, l’architecture, la version Eclipse, etc.

Premier avantage : Tycho découvre les dépendances depuis les méta-données OSGi (plugins metadata, etc.) au lieu du pom.xml. Inutile donc de coder en double les dépendances.

Second avantage : Intégré dans Maven, vous bénéficiez de tout de ce qui vient naturellement avec (Jenkins, Jacoco, Sonar, etc.)

Quelques bémols tout de même : Ce produit est encore en incubation aujourd’hui. Certaines commandes maven sont à privilégier (mvn verify plutôt que mvn install, par exemple). Les dépôts de composants ne sont pas des dépôts Maven standard, mais des dépôts p2 (remarque : il existe des passerelles).

Software Quality: the Eclipse Way and Beyond

Le groupe de travail PolarSys a lancé une initiative visant à définir une modélisation de la qualité d’un projet logiciel typique du monde Eclipse. Cette modélisation est en cours d’élaboration et le processus d’assurance qualité recherché a pour objectif : d’être entièrement automatisé (mesure sans intervention humaine), transparent pour ses utilisateurs (lisible par un humain), utilisable à des fins d’amélioration de la qualité (et non pas pour mettre en concurrence les projets audités).

Trois domaines de qualité sont audités : le produit, le processus de développement et la communauté. Pour que l’automatisation soit complète, des métriques précises ont été choisies dans chaque domaine. Pour le produit, elles sont connues : lignes de code, pourcentage de commentaires, mauvaises pratiques, etc. Pour le processus de développement, on comptera les jalons, les revues, les demandes d’évolution, etc. Pour la communauté, ce sont les mailing lists qui sont audités (nombre de sujets abordés, nombre d’auteurs, délai pour obtenir une réponse, etc.).

Un projet bien ambitieux, donc, mais très intéressant.

Orion deployed: Orion goes from prototype to production

Orion est un « IDE allégé » en ligne, utilisable directement dans votre navigateur. On y trouve notamment : un éditeur texte avec coloration syntaxique, un navigateur de fichiers, une console (pour exécuter des commandes !), des fonctions de recherche, un éditeur de différences entre fichiers, l’intégration avec Git, le branding, etc. Attention tout de même : ce n’est pas Eclipse dans votre navigateur…

Le serveur est conçu pour être extensible : il est possible de développer des plugins qui vont venir compléter les fonctionnalités déjà présentes. Et tout cela en étant déployé sur d’autres serveurs physiques !

Quelques autres « fonctionnalités » transversales qui sont encore plus ou moins en travaux : accessibilité, globalisation (caractères unicode, langues RTL, etc.)

OSGi: Don’t let me be Misunderstood

OSGi est le framework sur lequel se base Eclipse pour gérer les plugins. Mais c’est un framework complexe. Très complexe, même. L’objet de cette présentation (pour débutants) était de montrer que cette complexité répond aux problématiques de modularité dans le monde Java. Eh oui, tout cela a une raison, et la voici explicitée en 7 points :

  • OSGi permet de spécifier l’environnement d’exécution de votre application (« quelle version de Java ? »).
  • OSGi permet de différencier artefacts et modules : mort aux JARs, vivent les bundles !
  • OSGi permet de restreindre la visibilité des packages dans un module en en publiant certains (car les mots-clés de Java ne suffisent pas).
  • OSGi permet de charger plusieurs versions différentes d’une même classe pour « éviter » les soucis d’intégration.
  • OSGi donne une sémantique aux numéros de versions pour pouvoir les exploiter et vérifier les dépendances entre modules.
  • OSGi gère le cycle de vie des bundles (de leur installation à leur désinstallation).
  • OSGi propose le pattern µServices pour régler son compte au couplage des modules.

Now that I’ve Got a Model – Where’s my Application?

Une démonstration impressionnante de la puissance du couple EMF+CDO. Grâce à EMF, vous pouviez déjà définir votre modèle et générer :

  • le code correspondant,
  • une interface graphique minimaliste pour manipuler votre modèle, l’enregistrer et le charger avec le format XMI.

Vous n’êtes pas impressionnés ? Qu’à cela ne tienne, EMF peut donner bien plus que cela !

Une fois complétée votre interface graphique à l’aide des divers assistants de PDE et WindowBuilder, vous pouvez remplacer la couche de persistance XMI par un serveur CDO qui vous offre notamment :

  • Un modèle partagé entre utilisateurs sur le réseau (TCP) ;
  • Un modèle persistant, enregistré dans une base de données ou ailleurs ;
  • Des mises à jour en temps réel des interfaces graphiques des clients ;
  • Des verrous sur les objets du modèle (verrous optimistes ou pessimistes, persistants ou non, et transférables d’un utilisateur à un autre) ;
  • Un langage de requêtage.

Dans l’avenir, CDO devra également offrir des mécanismes de migration du modèle persistant.

Cette présentation fut une bonne introduction à Live collaborative modeling goes industrial, feedback par Thales/Obeo du développement d’un atelier de modélisation collaborative utilisant notamment CDO. L’occasion de voir que CDO règle certains, mais pas tous les problèmes…

It’s all about feedback – code review as a great tool in the agile toolbox

SAP présentait ici son retour d’expérience sur la mise en œuvre de revues de code sur les projets agiles (Scrum) internes. En pointant notamment la différence entre pair programming et code review que certains considèrent redondants.

Si le pair programming permet le défrichage de nouveautés, la formation en favorisant la complémentarité des expériences, la revue de code améliore la lisibilité du code, profite à tout le monde puisqu’elle est publique et ouvre la porte aux solutions alternatives.

De plus, la revue de code étant asynchrone, elle peut être menée en parallèle avec d’autres actions et s’insère donc très bien dans les plannings. Évidemment, une partie de la revue de code peut être automatisée avec des outils de vérification du code (style, bad practises, etc.).

Gerrit est un outil de revue de code qui s’appuie sur Git et permet la revue de code changement par changement. Pour faciliter les choses, les changements doivent être les plus petit possibles, accompagnés d’un commentaire pertinent (expliquant le POURQUOI du changement et indiquant éventuellement le niveau de maturité du changement [POC, RFC, WIP]). Les commentaires de revue peuvent être catégorisés (style nit, optional, can be fixed later, unrelated change, etc.) et doivent proposer des alternatives quand c’est nécessaire.

Si tous les membres de toutes les équipes peuvent relire le code de tous les membres de toutes les équipes, il est tout de même utile d’inviter parfois certaines personnes à relire un changement qu’on vient de faire. Et bien sûr, si on attend des commentaires, on veillera à laisser aux autres le temps de relire le changement, en commençant autre chose, par exemple.

Si l’investissement est connu (1 heure par jour et par développeur), le retour sur investissement n’a, lui, pas été chiffré. Mais est-il chiffrable ? Il semble que tout le monde soit satisfait, et c’est plutôt bon signe…

This entry was posted in Conferences, Eclipse, Eclipse Con, Java, Methodologies and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply