Matt Raible d’Okta : comment je suis devenu un hipster Java

Matt Raible est un éducateur Java et JavaScript bien connu avec plusieurs livres à son actif et une vaste expérience dans l’industrie. Il est actuellement défenseur des développeurs chez Okta, où il se concentre sur la sécurité, et membre du conseil consultatif technologique de JHipster, une plate-forme de développement hybride Java et JavaScript de premier plan.

JHipster est essentiellement un outil de construction avancé qui rationalise le développement d’applications complètes qui utilisent des frontaux réactifs. Il utilise Spring Boot sur le back-end, prend en charge React, Vue, Angular et d’autres frameworks JS sur le front-end, et inclut un échafaudage pour les magasins de données relationnels basés sur JPA et les magasins de données NoSQL tels que MongoDB et Cassandra. Vous pouvez lire ma présentation de JHipster ici.

J’ai eu la chance de discuter avec Raible de JHipster, Java, JavaScript, sécurité, monolithes vs. microservices, infrastructure cloud, etc.

photo de Matt Raible Matt Raible

Matt Raible

Matthieu Tyson: Vous aidez les gens à apprendre à coder depuis toujours. Vous avez fait beaucoup d’évangélisation Java au fil des ans. Maintenant, vous parlez un peu de JavaScript et des frameworks JavaScript. Qu’est-ce qui vous a amené à regarder davantage JS ?

Matt Raible: JavaScript a été mon premier amour. Je fais partie de ces programmeurs dont le premier langage était le HTML. Retour en 92. J’ai appris JavaScript et CSS peu de temps après et j’ai commencé à créer des sites Web. Je n’ai commencé à apprendre Java qu’en 1999.

Même si le développement du printemps et du back-end était cool, ce n’était pas mon véritable amour. Cela a toujours été l’interface utilisateur. Je me suis remis au développement UI vers 2007-2008, et j’ai été « UI Architect » pour plusieurs clients jusqu’en 2016.

En 2016, je travaillais pour CA en faisant JS le matin et j’avais un autre contrat avec Stormpath en faisant Java l’après-midi. Stormpath a essayé de m’embaucher à temps plein en tant que développeur Java et je leur ai dit : « Non, je ne veux pas vraiment faire Java tout le temps. Nos négociations ont stagné pendant quelques mois. Ensuite, j’ai rédigé une lettre “d’emploi de rêve” et je la leur ai envoyée. Cela impliquait d’être un défenseur (articles de blog, prise de parole, etc.) pour Java et JavaScript.

Tyson: Vous faites partie du conseil technique de JHipster, qui, en tant qu’union de Java et JavaScript, semble être une excellente convergence de vos intérêts. Pouvez-vous me dire comment vous vous êtes impliqué dans ce projet et en quoi il est passionnant ?

Raible: Je suis tombé dessus à l’été 2014. Je travaillais pour un client qui a construit un prototype rapide d’une API et d’une interface utilisateur avec Python en utilisant un framework qui facilitait les choses (j’ai oublié lequel). J’ai pensé que je pouvais faire la même chose en Java, j’ai trouvé JHipster et j’ai livré un prototype similaire en moins de 24 heures. Je ai été impressionné! Et les premières impressions sont durables.

J’avais été consultant indépendant pendant la majeure partie de ma carrière à ce moment-là, et je savais que le marketing était important. Je voyageais pour parler à des conférences de temps en temps, mais je savais qu’il y avait aussi du pouvoir à écrire un livre. J’ai donc parlé à InfoQ de l’écriture du mini-livre JHipster et ils ont accepté de m’aider.

Au cours du processus d’écriture du livre et de création de l’exemple d’application correspondant, j’ai trouvé des bogues et saisi des problèmes. J’ai pu résoudre moi-même certains d’entre eux et j’ai soumis des PR. Après avoir fait cela pendant plusieurs mois, j’ai été invité à être un committer sur le projet.

Ensuite, j’ai eu l’idée de me déguiser en développeur Java à l’ancienne pour lancer une conversation JHipster et de me transformer progressivement en hipster Java au fur et à mesure de la conversation. Je l’ai fait pour la première fois au Denver JUG en avril 2015. Ma meilleure performance de cette conférence a été à Devoxx Belgium en 2015.

Lorsque j’ai rejoint Stormpath, puis Okta, j’ai décidé que l’un des meilleurs moyens d’être un défenseur efficace des développeurs était d’intégrer le produit de l’entreprise dans JHipster. Ensuite, je pourrais continuer à écrire et à parler de JHipster et démontrer le produit de l’entreprise en même temps. Cela a plutôt bien fonctionné et maintenant Okta est le sponsor platine de JHipster ! Nous contribuons 2500 $ par mois.

Tyson: Vous savez, alors que je regardais JHipster, j’ai vu le support d’authentification prêt à l’emploi et j’ai pensé: “Oh merci mon Dieu.” En tant que développeur, je déteste l’authentification, comme ici, je recommence à faire la même chose encore et encore …

Cela vous dérange-t-il de parler un peu en détail de la prise en charge de l’authentification dans JHipster et de la manière dont elle s’intègre à Auth0/Okta ?

Raible: Lorsque j’ai commencé à intégrer auth dans JHipster, c’était via le module Stormpath que j’avais créé. Étant donné que Stormpath utilisait une configuration intégrée à l’époque, l’intégration consistait principalement à ajouter les SDK Stormpath. Vous pouvez en savoir plus ici.

Ensuite, Okta a acheté Stormpath en février 2017. Comme nous avons arrêté l’API Stormpath en août 2017, ce module n’était plus utile. En septembre 2017, j’ai commencé à refactoriser l’implémentation OAuth de JHipster. Vous pouvez en savoir plus sur la plupart de ces efforts dans le billet de blog suivant : Utiliser le support OpenID Connect avec JHipster.

L’implémentation OAuth de JHipster à l’époque impliquait l’utilisation d’un serveur d’autorisation de Spring Security et la mise de l’ID client et du secret dans le code côté client. c’était un énorme trou de sécurité. Au cours d’un mois, nous avons tout refactorisé pour qu’il se passe côté serveur et ne stocke jamais de jetons sur le client. Cinq ans plus tard, je pense toujours que c’était une bonne décision.

Tyson: Je parle un peu de frapper Auth0 à partir d’un contexte Node.js ici. J’ai l’impression que nous avons parcouru un long chemin pour rendre la sécurité moins contraignante et plus conviviale pour les développeurs. Que voyez-vous comme tendances ou directions dans lesquelles l’espace évolue ?

raisonnable : Je suis d’accord, mais je pense que nous avons du chemin à faire.

J’aime comparer la sécurité aux tests. La plupart des développeurs savent qu’ils doivent tester et il existe de nombreux outils pour montrer la couverture des tests. La plupart des IDE prennent même en charge l’affichage de la couverture de test des classes. Il n’y a pas grand-chose dans l’espace de sécurité en ce qui concerne les plugins IDE pour signaler les problèmes de sécurité aux développeurs. Je pense que les choses s’améliorent cependant. Snyk a un plugin IntelliJ pour corriger les vulnérabilités. Vous pouvez effectuer des vérifications OWASP avec Maven, et le Dependabot de GitHub est assez astucieux.

Un gros problème que je vois est que les développeurs (ou leurs clients) souhaitent implémenter SAML au lieu d’OIDC. Pour citer mon ami Joël Francusic, “SAML est à OIDC ce que SOAP est à REST.” Je ne vois pas beaucoup de gens implémenter des API SOAP, alors pourquoi les gens implémentent-ils encore SAML ? Je ne pense pas que ce soit la faute des développeurs, mais des décideurs mal informés.

En ce qui concerne la convivialité pour les développeurs, lors de ma première rencontre Trish, en 2010, elle était vendeuse dans le secteur de la sécurité. J’ai voyagé avec elle à une conférence sur la cybersécurité à Kansas City. Elle m’a présenté à certains de ses amis infosec. Lorsqu’ils m’ont demandé ce que je faisais, j’ai répondu « Je suis un développeur ». L’une des premières réponses a été: “Je parie que je peux pirater votre merde.” C’était alarmant pour moi.

J’ai pensé : « Hé, on vient de se rencontrer et tu m’insultes déjà ?! À partir de ce moment, j’ai commencé à chercher à faire plus de discussions sur la sécurité pour essayer de rendre la sécurité plus conviviale pour les développeurs. J’ai fait des discussions similaires dans le passé expliquant JavaScript et les technologies Web aux développeurs Java pour essayer de les aider à adopter les technologies Web plutôt que de les ignorer en utilisant JSF [Java Server Faces]†

Tyson: Ouais. Il semble que si vous passez beaucoup de temps à vous concentrer sur le piratage, vous pouvez casser des choses, et si vous ne le faites pas, vous êtes vulnérable à ceux qui le font.

Puis-je poser des questions sur les trucs Spring Native / JHipster qui sont récemment sortis? Quel est le principal plat à emporter là-bas?

Raible: Le principal point à retenir est que vous faites démarrer votre application JHipster + Spring Boot en quelques millisecondes au lieu de quelques secondes si vous intégrez JHipster Native.

Nous avons également des plans pour Micronaut et Quarkus. Ils ont un support natif intégré, mais nous devons faire du travail pour les faire fonctionner avec JHipster.

Il existe également des plans pour NestJS et .NET Core, mais ils n’ont aucun type de support natif.

JHipster Native (et Spring Native) ne sera probablement que temporaire car Spring Boot 3 prévoit d’avoir le natif par défaut. Une fois que nous aurons mis à niveau (sa sortie est prévue pour fin 2022), nous n’aurons plus besoin de JHipster Native. Bien sûr, les applications existantes basées sur Spring Boot 2.x en auront toujours besoin.

Tyson: Vous avez également beaucoup écrit sur l’infrastructure : les microservices, Kubernetes, etc. À votre avis, où en sont les choses ? Des tendances ou développements intéressants ?

Raible: J’aime Chez Kelsey Hightower poste de 2020 sur la façon dont les monolithes sont l’avenir. Je pense que les développeurs s’intéressent beaucoup aux microservices, car ils veulent en savoir plus sur tout ce qui compose les microservices, créer leur CV et utiliser les dernières technologies «à la mode». Cependant, à mon avis, il y a beaucoup de fois où un monolithe fonctionnera très bien. Là où les monolithes tombent en panne, c’est quand vous avez une tonne de personnes qui y travaillent et que vous devez faire évoluer les gens et la capacité de pousser le code rapidement sans attendre les autres.

Les microservices sont souvent entravés par la loi de Conway dans la mesure où votre organisation doit avoir la capacité de créer des équipes de produits capables de proposer des idées, de les livrer et de les maintenir de manière indépendante. Si votre organisation a la capacité de le faire sans compter sur les autres, il y a de fortes chances que l’adoption de microservices fonctionne bien pour vous.

L’échelle d’un monolithe n’est généralement pas un problème, c’est l’échelle des personnes. Quand je travaillais chez LinkedIn en 2007-2008, ils avaient un monolithe et ça fonctionnait très bien. Cependant, ils ne se déployaient que le jeudi et c’était un problème de vélocité. Ils ont finalement adopté les microservices en raison de leur problème de mise à l’échelle des personnes, et non à cause de problèmes de mise à l’échelle de la technologie.

Je n’ai pas une bonne idée de la direction que prennent les choses, mais je pense que Kubernetes nécessite beaucoup de YAML de bas niveau pour que les choses fonctionnent. Je ne peux pas m’empêcher de penser qu’il y a une meilleure façon de configurer les choses. Idéalement, il y aurait une sorte de syntaxe assez facile à mémoriser. Ou peut-être qu’il y aura éventuellement quelque chose comme JHipster qui pourra générer tout le YAML pour vous.

Tyson: Super intéressant. Pourriez-vous expliquer en quoi la mise à l’échelle des personnes est un goulot d’étranglement ? Décrivez un peu plus ce que cela signifie ?

Raible: Toutes les entreprises sont des entreprises technologiques de nos jours et il y a de fortes chances qu’elles aient des développeurs. Plus l’entreprise est grande, plus elle a tendance à avoir de développeurs ou à en sous-traiter. S’ils travaillent tous sur le même projet (c’est-à-dire le monolithe) et engagent des milliers de lignes de code par heure, il y aura forcément des conflits. Cela se transforme en un cauchemar de fusion lors de la libération. Cependant, si vous avez des milliers de développeurs et qu’il y a des équipes de moins de 10 personnes qui travaillent sur des centaines de microservices, il y a moins de risques de conflits. De plus, avec les microservices, vous devriez pouvoir déployer indépendamment et minimiser les dépendances entre les équipes.

Histoire connexe amusante : Quand j’ai entendu pour la première fois James Gouverneur parler de la façon dont, lorsque les entreprises Web grandissent, elles se transforment en boutiques Java. J’ai pensé une fois que c’était parce que Java était un meilleur langage et que le typage statique facilitait l’évolutivité. Après avoir entendu l’un des discours de James en personne, j’ai appris que c’était plus parce que Java possède le plus grand écosystème de développeurs. Lorsque vous essayez d’embaucher des centaines de développeurs à la fois pour faire évoluer votre entreprise, c’est l’un des plus faciles à embaucher.

Tyson: C’est super ! Bon, une dernière question pour conclure. Je suis curieux de savoir si vous avez des réflexions sur la vie de codage, en tant que développeur (comme moi) qui existe depuis assez longtemps pour revenir un peu sur les choses.

Raible: C’est tout simplement fabuleux ! Je suis allé à l’école à DU [University of Denver] lorsque nous utilisions Pine pour le courrier électronique et que Lynx était mon premier navigateur. Voir Internet devenir visuel avec SlipKnot puis Netscape 1.0 était incroyable. J’ai commencé à utiliser Struts 1.0 juste après sa sortie, je l’ai adoré et je me suis fortement impliqué dans sa communauté. J’ai été récompensé avec beaucoup de nouveaux amis et des solutions aux problèmes que j’ai rencontrés. Puis vinrent les blogs, AppFuse, Spring, mon livre sur Spring, parlant (inspiré par Bruce Snyder), la renaissance de JavaScript et ma plongée dans le développement de l’interface utilisateur.

Ce que j’ai le plus apprécié de tout le trajet, ce sont les amis que je me suis fait dans la communauté open source en cours de route. Quand tu vas à une conférence et que tu arrives à traîner ou à bidouiller avec quelqu’un que tu connais depuis presque 20 ans, c’est vraiment spécial. Ma capacité à travailler à distance depuis 2002 a également été une véritable bénédiction. J’aime avoir la liberté de travailler de n’importe où avec un bon internet !

Tyson: Merci Matt, ça a été super de te retrouver !

Raible: C’était amusant de discuter avec vous !

Copyright © 2022 IDG Communications, Inc.

Leave a Comment

Your email address will not be published.