Interview de Florent Benoit, contributeur sur le projet Eclipse Che

Peux-tu te présenter en quelques mots ?

Je m'appelle Florent Benoit et je suis basé dans le bassin grenoblois. Je suis marié et papa d'un ravissant petit bout de chou qui a fêté sa première bougie pendant les fêtes de Noël 2017.

Quel est ton parcours professionnel ?

J'ai commencé par travailler chez Bull en 2003 après mon stage d'apprentissage de fin d'études. Le projet sur lequel j'ai travaillé se nommait OW2 JOnAS, un serveur d'application open source Java EE ainsi que OW2 EasyBeans, un conteneur EJB. Après une dizaine d'années à travailler sur le middleware Java et à participer aux spécifications Java EE, j'ai changé de cap et j'ai rejoint la société Serli en janvier 2014 pour travailler sur le projet Codenvy qui était alors purement en mode SaaS (Software as a Service). J'ai commencé par travailler sur des plugins autour des technologies JavaScript (type Bower, Gulp, Angular). J'ai ensuite été recruté par la société Codenvy en 2015 où j'ai travaillé sur toutes les parties de Codenvy et Eclipse Che (du CLI, écrit en bash, à l'IDE avec du GWT/JavaScript, le dashboard en TypeScript et la partie serveur en Java/Guice/JAX-RS, etc.).

Depuis juin 2017 je suis un employé Red Hat, la société Codenvy ayant été achetée par Red Hat.

Peux-tu nous décrire Codenvy ?

Au tout début, un éditeur en JavaScript a été développé, l'éditeur étant un composant d'eXo platform (une solution de travail collaboratif), afin de pouvoir faire de l'édition directement depuis son navigateur sans avoir à lancer un IDE sur sa propre machine. On évitait ainsi d'installer un éditeur sur sa machine, compiler le code puis l'envoyer à distance, tout étant géré depuis son navigateur web.

C'est de ce projet qu'est né Codenvy, une société dont le but serait de fournir un workspace à la demande avec la partie cliente qui tourne dans un navigateur web. La société a été créée en novembre 2012.

La solution était articulée autour d'un modèle uniquement SaaS avec une partie gratuite. Chaque personne qui créait un compte avait droit à un quota d'heures de calcul chaque mois. Ce modèle a ensuite évolué pour finir à un modèle où l'on a un workspace qui peut contenir plusieurs projets associé à un ou plusieurs environnements d'exécution (basés sur Docker ou OpenShift) mais avec une quantité de mémoire allouée : 3Go par workspace en gratuit, avec une option payante pour ajouter de la mémoire.

Une grande partie du développement est réalisée par des équipes en Ukraine (historiquement, Codenvy avait l'essentiel des développeurs en Ukraine) mais un grand nombre de développeurs a également rejoint le projet avec le rachat par Red Hat et les développeurs sont désormais dans le monde entier.

Peux-tu nous décrire tes activités au sein de Codenvy ?

Suite à l'acquisition de Codenvy par Red Hat, je suis rattaché à une équipe transverse des équipes de développement d'Eclipse Che, avec comme but de chercher des innovations, prototyper des intégrations avec des nouveaux produits mais aussi discuter avec les gens des différentes communautés open source pour améliorer le produit. J'ai par exemple récemment expérimenté des plugins IDE en pur JavaScript, des workspaces avec des containers en mode Side-Car, l'ajout du support de Java 9 dans Eclipse Che, etc.

Quelles sont ses activités et solutions ?

Codenvy a évolué depuis le modèle uniquement SaaS. Il y a désormais trois composantes.

1. Le modèle purement gratuit en SaaS sur https://codenvy.io
2. Un modèle payant SaaS avec gestion d'équipes et plus de mémoire.
3. Un mode ‘On-Premises' avec : soit l'installation sur les serveurs de l'entreprise, soit une gestion par Codenvy.

Depuis le rachat par Red Hat, http://OpenShift.io (et OpenShift) font partie intégrante des solutions. Mais Codenvy est aussi le premier contributeur du projet Open Source Eclipse Che, sous license EPL 1.0, qui est le socle technique autour duquel Codenvy a bâti ses solutions.

Pourquoi Codenvy s'est impliquée dans la mise en place d'Eclipse Che ?

Après avoir développé une offre SaaS, Codenvy voulait s'ouvrir à la communauté des développeurs pour que toute personne puisse réaliser des plugins. Afin de faciliter une mise en œuvre locale, nous avons expurgé Codenvy des plugins “cloud” et de la gestion utilisateur, multitenant, etc. Cela a abouti à la création d'Eclipse Che, un framework permettant d'avoir toutes les fonctionnalités pour faire tourner un workspace à la demande sur sa proche machine, le socle de Codenvy étant Eclipse Che.

Ensuite, afin de faciliter encore plus le lancement local sur les différentes plateformes (Linux, macOs, Windows, etc) il a été décidé que le prérequis serait d'avoir Docker et que le CLI de lancement d'Eclipse Che serait basé sur Docker afin que la portabilité et l'installation soit uniforme quel que soit le système d'exploitation.

Suite au rachat de Codenvy par Red Hat, penses-tu qu'Eclipse Che va prendre encore plus d'importance ?

Tout d'abord, de par la culture open source de Red Hat, beaucoup de fonctions qui composaient le produit Codenvy sont migrées vers Eclipse Che sous license open source.

Cela signifie que la gestion multiutilisateur ainsi que le multitenant deviennent des fonctions intégrées dans Eclipse Che. Eclipse Che n'est donc plus uniquement un mode monoutilisateur local, vous pouvez déployer Eclipse Che sur de larges infrastructures de manière native.

Donc pour répondre à la question je réponds par l'affirmative car les usages sont décuplés.

Peux-tu nous présenter le but d'Eclipse Che ?

Le but d'Eclipse Che est d'avoir un workspace portable et à la demande avec l'ensemble des outils prêts à fonctionner. Par exemple, j'arrive sur un projet sur lequel je souhaite travailler, il me suffit de demander la création d'un workspace et je peux travailler dessus immédiatement : les commandes pour construire, lancer un projet, déboguer un projet, etc. sont déjà toutes configurées.

J'ai besoin de corriger un bogue dans une vieille branche de code ? Pas de problème, je peux là aussi demander la création d'un workspace qui fonctionnera parfaitement. Pas besoin de se dire qu'il faut réinstaller sur sa machine de vieilles versions de composants pour revenir dans un état précédent.

Penses-tu que l'avenir est aux IDE cloud ?

Je pense que les cloud IDE font partie de l'avenir car ils permettent de répondre à plusieurs cas d'utilisation qui facilitent drastiquement la vie d'un développeur.

Un développeur a envie d'essayer une techno ou un produit ? En un clic vous avez un workspace qui permet de le tester. Et en un clic vous pouvez supprimer tout cet environnement.

Si le projet nécessite beaucoup de ressources pour la compilation, en déportant cela sur une machine bien plus puissante, cela permet de travailler sur plusieurs projets en parallèle sans être limité par la machine où se trouve le navigateur Web.

Enfin, quid si lorsque je travaille dans l'éditeur, lorsque je tape ou que je sauvegarde une nouvelle version, l'ensemble des tests unitaires sont exécutés en tâche de fond et que le résultat est directement affiché dans l'éditeur avec un warning m'informant que j'ai tout cassé ?

Grâce aux ressources décuplées de par le cloud, ils font partie de l'avenir.

Est-ce que l'arrivée d'un IDE Cloud signe la fin à court ou moyen terme de l'IDE bureautique ?

Je ne pense pas que cela signifie la fin à court terme des IDE Desktop classique. Si un développeur utilise un IDE depuis plus de 10 ans, je ne le vois pas remplacer en 1 clic son IDE favori. Mais avec les nouveaux cas d'utilisation, le développeur sera tenté de l'utiliser de manière occasionnelle et même régulière. Par exemple pouvoir contribuer à un projet en quelques minutes, faire un correctif sur une ancienne version ou bien reproduire le problème en un clic car l'intégration continue vient d'envoyer un mail car le build du projet est cassé.

Rien de tel aussi que de pouvoir utiliser un mode “pair programming” à distance.

Enfin, on cite toujours le cas de “et si je suis dans un train ou un avion, comment je fais” ? Dans ce cas là il y a un mode local qui est possible mais dans ce cadre on entre plus dans une optique bureautique à nouveau.

Le mode hybride sera le plus souvent utilisé (utilisation locale possible mais avec utilisation d'outils cloud le plus souvent).

Le nombre de fonctionnalités revient également souvent dans les comparaisons. Il y a beaucoup de personnes qui utilisent Google Docs par rapport aux produits Desktop bien qu'il y ait moins de fonctionnalités. Je dirais qu'ici c'est la même chose pour les IDE, la facilité d'utilisation peut l'emporter.

Quelle est la roadmap d'Eclipse Che ?

Je détaillerai la roadmap à court terme d'Eclipse Che 6 dans une prochaine section mais l'axe majeur d'Eclipse Che est la simplification pour l'utilisateur final et aussi pour le développeur qui souhaite personnaliser ou contribuer à Eclipse Che :

• des plugins simple à écrire et exécuter/ajouter ;
• un support de plus en plus de technologies avec les langage serveurs (Language Server Protocol) et le protocole de debug ;
• une exécution encore plus rapide (parallélisation, lazy loading, mode hybride, passivation, etc.) ;
• une approche encore plus modulaire.

Quelles sont les limites entre Eclipse Che et la version bureautique actuelle ?

Une différence majeure entre Eclipse Che et Eclipse IDE est que Eclipse IDE suppose que la partie cliente et la partie serveur sont colocalisées. De ce fait, des plugins qui ont été écrits spécialement pour Eclipse IDE seront difficilement portables vers Eclipse Che s'il n'y a pas un bon découpage entre la partie affichage et la partie métier (serveur). La partie cliente étant différente dans les deux cas.

L'avantage d'Eclipse Che par rapport à Eclipse IDE est qu'il n'y a aucune adhérence au système d'exploitation ou aux différents outils sur la machine. Du moment que vous avez Docker c'est simple. Votre projet peut nécessiter autant d'outils différents et incompatibles entre les versions, chaque workspace disposera de ses propres outils. Vous pouvez avoir des plugins en fonction de chaque workspace facilement.

Enfin dans Eclipse IDE les plugins sont dynamiques au contraire d'Eclipse Che mais cela est en passe d'être levé avec la version 6.0 d'Eclipse Che.

À quoi doit-on s'attendre dans Che 6 ?

La prochaine version 6.0 est la prochaine version majeure d'Eclipse Che suite au rachat de Codenvy par Red Hat.

De ce fait en nouveauté il y a la continuité de la mise en open source des composants de Codenvy (multiutilisateur, multitenant, permissions, etc.) mais aussi des choses qui arriveront dans les prochaines versions de Che :

• simplification de l'extensibilité des plugins IDE (ajout possible dynamique de plugins en pur JavaScript (ou TypeScript) sans avoir à générer à nouveau un binaire Eclipse Che) ;
• amélioration de l'onboarding d'un workspace : temps d'attente réduit ;
• en ce qui concerne Java: le passage à l'utilisation de jdt.ls : cela permettra un meilleur découpage entre Eclipse Che et la partie “Java” tout en apportant le support Java 9 dans les projets ;
• utilisation d'un mode side-car pour les conteneurs d'un workspace. (par exemple lancer un language server avec son propre conteneur) ;
• refonte de la partie SPI pour se connecter à diverses implémentations de conteneurs : Docker, OpenShift, etc.

Pour résumer, pour l'utilisateur final, ce sera :

• des workspaces qui démarrent plus vite ;
• plus de fonctionnalités sur les technologies (avec le support de conteneur “language server”) ;
• des plugins faciles à écrire, à compiler et exécuter.

Connais-tu Developpez.com ? Si oui, qu'est-ce que cela t'apporte ou t'a apporté ?

Je connais Developpez.com depuis très longtemps mais j'ai vraiment commencé à consulter le site lorsqu'il y a eu la mise en place des forums. C'est une mine d'information pour les développeurs qui n'aiment pas trop la langue de Shakespeare mais aussi une source centralisée de cours ou tutoriels pour diverses technologies/langages. Il y a également Stackoverflow qui a apporté des discussions/forums mais cela est toujours en anglais.

Quelles sont tes impressions sur cette communauté francophone basée sur le développement ?

Pour faire suite à la question précédente, j'aime le fait, lorsque l'on travaille sur un projet open source, de pouvoir voir les questions posées ou les retours sur ces projets par la communauté francophone. En effet, parfois les retours sont totalement différents par rapport aux retours via mailing list ou Github issues mais on découvre aussi des problèmes qui ne sont pas remontés au projet.

Vous trouverez ci-dessous les différents projets open source sur lesquels Florent a travaillé.

Eclipse Che

• Site officiel : http://www.eclipse.org/che/
• Tutoriel : https://soat.developpez.com/tutoriels/eclipse/presentation-eclipse-che-ide-cloud/

Openshift.io

• Site officiel : https://www.openshift.com/

Nous tenons à remercier Florent Benoit d'avoir accepté de se prêter à cette interview et de nous faire partager son expérience sur ses contributions à Eclipse Che.

Nous tenons à remercier genthial pour la relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.