Enocre une ressource sur l'archi hexa, ça fait pas de mal !
Probablement la meilleure explication de la méthodologie TDD que j'ai eu l'occasion de voir.
(le son s'améliore avant qu'il ne commence)
Énormément de pragmatisme. Le conférencier a une approche très particulière et personnelle de Tdd. Il s'approprie les bonnes idées sans aucun dogmatisme. Tout au long du live coding et a la fin il propose des idées pour améliorer l'expérience du developpeur, en particulier au sujet de la charge cognitive. Ces idées peuvent vraiment aider des développeurs neuro-atypiques a améliorer leur quotidien.
Communiquer avec les autres est la base de nos relations humaines. Mais, on s’en rend bien compte au quotidien, ce n’est pas toujours facile ! Et peut-être encore moins au niveau professionnel.
Comment faire passer ton message et surtout être entendu ? D’ailleurs sais-tu toi même écouter ?
Lancer une appli SaaS est un grand défi pour un dev, surtout quand tu travailles à côté !
Ecrire du contenu quand on est dev ; certains le font pour le plaisir, sous forme de side project et d’autres se lancent dans l’aventure avec un objectif plus business.
Vue.js ne serait-il pas un jouet ?! Pourquoi ne pas faire du react plutôt ?
Son image de framework facile à appréhender signifie-t-elle un outil moins puissant ?
Y a-t-il un risque de miser sur Vue.js aujourd’hui ?
Quelle opportunité représente ce framework pour les dev ?
On en parle dans l’épisode d’aujourd’hui avec Elise Patrikaien, développeuse front end freelance sur Vu.js et Angular.
Pour suivre Elise Patrikaien sur linkedin : www.linkedin.com/...
Pour suivre Elise Patrikaien sur Twitter : twitter.com/elisepatrikain1
Merci à Élise pour son retour sur Vue.js.
Je suis entièrement d'accord avec elle sur la prise en main vraiment aisée de Vue.js. J'ai eu plusieurs fois l'occasion d'accompagner des devs backends à passer à Vue.js et effectivement, la montée en compétence s'est généralement bien passée, très graduelle et en découvrant au fur et à mesure toutes les fonctionnalités ES6.
Sans compter que depuis l'arrivée du Vue CLI, l'outil de ligne de commande, la gestion de la chaîne d'outillage sous-jacente est grandement simplifiée.
En revanche, bien que je n’aie pas encore essayé la version 3, je suis un peu inquiet entre l’image donnée par Benoît de Python 2 vs 3 sur l’écosystème, et l’impression qu’il repose beaucoup plus qu’avant sur une bonne connaissance de JS/ES laissant de côté la simplicité qui à fait son adoption, mais j’espère me tromper :)
Par contre, mon retour sur l’utilisation de Vue.js en entreprise est mitigé. Pour avoir travaillé sur plusieurs applications, j'ai pu constater que la vélocité baisse très vite dès que l'application commence à se complexifier.
Je pense que ça vient d’une part que Vue.js ne se suffit pas à lui-même. On se retrouve vite à ajouter une couche de gestion des données, généralement la combo Axios pour les appels REST et Vuex pour la gestion des données. Et puis on a plusieurs pages, alors on ajoute un routeur, généralement Vue Routeur. Cette liberté d'ajouter des briques au fur et à mesure du besoin, ça m'a surtout donné l'impression de réinventer la roue en me fabriquant un framework maison.
D’autre part, Vue.js ne propose aucune architecture pour le projet. On a quelques bonnes pratiques qui ont émergées comme le Props Down Events Up(1) et appliquer le bon vieux SRP pour éviter que ça parte trop en plat de spaghettis, mais c'est tout.
Du coup, on a dû expérimenter pour trouver nos propres conventions :
- un package "ui" avec les composants de base réutilisables
- des packages métier avec les composants qui font des traitements et le lien avec le store
- un package "page" pour les composants qui représentent les pages
- un package "store" pour le traitement des données
- un package "api" pour ne pas avoir du Axios partout dans le code
Tout ça consommant du temps et de l'énergie qui auraient pu être utilisés pour du développement de fonctionnalité.
Au final, j'ai du mal à voir l'avantage de cette approche sur les frameworks tel qu'Angular ou Ember.js.
Donc pour répondre à la question initiale du podcast : pour moi, oui, Vue.js est un jouet. Tout comme React d'ailleurs.
Les libs de composant, c’est parfait pour une démo ou un widget météo, mais pour faire une app, c'est vraiment insuffisant. Mon regard se porte maintenant sur les frameworks qui se construisent par dessus ces libs. Élise en a mentionné quelques-uns pour Vue.js : Nuxt et Quasar, qui me semblent également être les plus prometteurs.
(1) jasonformat.com/...
EDIT: reformulations
Pour aller un peu plus loin, je trouve que les webcomponents ont pas mal de potentiel. Ils peuvent être écrits en vanilla js , avec vuejs ou autre. Puis être intégrés avec d'autres frameworks.
Un bon exemple chez Clever Cloud : www.clever-cloud.com/...
Hubert Sablonnière en parle par ici : www.youtube.com/...
Pour suivre le cursus Artisan Développeur : ad302.fr/3syGBo
Pour faire ton diagnostic de pratiques gratuit : ad302.fr/vA9131
Comment devient-on tech lead ?
Faut-il bâtir un chemin de carrière précis ? Est-ce réservé aux seniors ou peut-on y accéder en milieu de carrière ? Quelles compétences ce poste nécessite-t-il ?
www.reuters.com/...
SoundCloud vient de sortir un article sur le pattern BFF (Backend For Frontend) et comment ils considère que c'est légèrement différent d'une approche API Gateway avec GraphQL dans l'implémentation.
C'est assez intéressant :)
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)