Quand tu fais du code, il t'arrives de rencontrer des trucs affreux ?!
Alors comment passer d'un code crade à quelque chose d'évolutif et surtout durable ?  


Partagé par Artisan Développeur
il y a presque 2 ans
2

Derniers commentaires :
Marc Bouvier il y a presque 2 ans
Bravo! Cette vidéo est un excellent aperçu de l'approche TDD, et architecture hexagonale!
Très dynamique avec plein de bonnes explications.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Agilité
Alignement
Autonomie
Bonnes pratiques
Conférence
Culture
DevOps
Organisation
Produit
Retour d'experience
Théorie des contraintes
Vision systémique

Agilité à l'échelle, un mythe ? Une réalité ?


Partagé par Marc Bouvier
il y a environ 2 ans
0

Derniers commentaires :
Marc Bouvier il y a environ 2 ans
Je crois que mon résumé de cette ressource a été tronqué. Le voici ci dessous.

Agilité à l'échelle, un mythe ? Une réalité ?

Daniel Terhirst-North et Anna Urbaniak s'appuient sur leurs expériences et collaborations pour dessiner leur vision globale de cette problématique organisationnelle. Ils proposent des idées pour aider à comprendre et naviguer dans des organisations afin de développer des produits.

Plutôt que de vanter les mérites de tel ou tel Framework © ou Outil®, ils déconstruisent les enjeux des organisations en identifiant 2 états d'esprit.
- "digital product" mindset
- "industrial"

Les conférenciers définissent les 2 états d'esprit et les caractéristiques qui les opposent.
Ils développent pourquoi les organisations qui envisagent l'agilité à l'échelle nécessitent un équilibre entre les deux états d'esprit pour réussir.

Ils en arrivent au constat qu'il est nécessaire pour ces organisations d'atteindre l'autonomie par le biais de l'alignement.

Ils définissent les notions d'autonomie et d'alignement, dont les composantes permettent de comprendre et d'agir sur les organisations.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques

Les BPM sont des outils très intéressants. Par contre, il s'agit d'une solution technique qui apporte une complexité sous-jacente assez conséquente. Dans le monde de l'entreprise, on y fait ce recours très souvent pour modéliser des process métiers à point de devenir un choix par défaut assez dogmatique, un nième marteau de Maslow. Il est intéressant de voir d'autres alternatives à cette solution.


Partagé par Walid Debbech
il y a environ 2 ans
1

Derniers commentaires :
Marc Bouvier il y a environ 2 ans
Je confirme pour avoir travaillé dans un environnement où ce genre de système était en place.
J'ai pu constater le vendor locking que ça entraînait et la complexité accidentelle que ça engendrait. Ajouter à cela la difficulté de mettre en place des migrations et la quasi impossibilité de tester automatiquement.

Ma perception a été que les avantages que ça apportait (car il y en avait : traçabilité clé en main, outils de visualisation,...) étaient rapidement éclipsés par leurs inconvénients.
Walid il y a environ 2 ans - modifié il y a environ 2 ans
Effectivement quand on met tout dans la balance, le jeu ne vaut pas la chandelle !
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
TDD

Je me bats avec notre code base pour faire des tests lisibles et pas trop répétitifs mais je ne suis pas ravi par le résultat. Récemment, nous avons décidé d'arrêter de mocker le "domaine" lorsque nous testons les contrôleurs. Les tests sont moches mais éfficaces et testent les grandes lignes (le domaine est plus facile à tester pour couvrir tous les cas). Mais je m'étonne d'être de moins en moins convaincu par les tests unitaires (unité=classe).


Partagé par Blaise
il y a environ 2 ans
0

Derniers commentaires :
Benoit GANTAUME il y a environ 2 ans
J'ai beaucoup aimé la série d'interview qui ont suivi la publication de l'article de DHH.
Marc Bouvier il y a environ 2 ans
Je trouve que Sebastian Daschner a pas mal de pratiques intéressantes pour adresser les challenges que tu évoques


blog.sebastian-daschner.com/...
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.

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 


Partagé par Artisan Développeur
il y a plus de 2 ans
0

Derniers commentaires :
Mathieu Barberot il y a plus de 2 ans - modifié il y a plus de 2 ans
Hello,

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
Marc Bouvier il y a plus de 2 ans
Hello Mathieu. Yeps, sur le sujet de la complexité pour des applications d'entreprise, je trouve que Nuxt et se conventions adressent plutôt bien ces problématiques.

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 ajouter un commentaire, tu dois te connecter ou créer un compte.
Clean Architecture

Un excellent talk proposant un exemple de clean architecture sur un projet front, en séparant la partie logique d'un composant (la logique 'contrôleur' : le data-model et son comportement) de son application sur le DOM (gérée par un framework). Ainsi, la logique de l’application est complètement découplée de la stack utilisée : dans la démo, on passe facilement d'une application écrite en Angular à une application écrite en React.


Partagé par Elise Patrikainen
il y a presque 3 ans
1

Derniers commentaires :
Marc Bouvier il y a plus de 2 ans - modifié il y a plus de 2 ans
Je trouve que les talks de alpescraft abordent des sujets très intéressants.
Elise Patrikainen il y a plus de 2 ans
Oui je suis d'accord, j'avais même envie d'y aller l'année prochaine. Il y a des gens qui y vont ici ?
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
TDD

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)


Partagé par Emmanuel Riche
il y a presque 3 ans
7

Derniers commentaires :
Marc Bouvier il y a presque 3 ans
Tout à fait d'accord. Je l'ai ajoutée dans ma liste de vidéos les plus utiles de tous les temps.

É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.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques

Récemment, Dart 2.12 a été livré dans Flutter 2. Cette mise à jour contient l’une des fonctionnalités les plus importantes du langage qui est le Null Safety.


Partagé par Benoit GANTAUME
il y a presque 3 ans
1

Derniers commentaires :
Mathieu Barberot il y a presque 3 ans
Venant de Java et ayant adopté Kotlin (qui implémente aussi le Null Safety) pour mes projets perso, j'apprécie beaucoup cette sécurité de ne plus avoir à me soucier de la fameuse NullPointerException qu'on rencontre si souvent en Java lorsqu'on tente d'utiliser une variable "null".
Au final, lorsque je programme en Java (le monde professionnel ne semble toujours pas prêt pour Kotlin) je me rends compte que mon code est devenu plus défensif qu'il y a quelques années justement pour vérifier ce genre de chose et retrouver la sérénité que j'ai sur du Kotlin :/
Marc Bouvier il y a presque 3 ans
En effet la null safety par défaut permet de déporter le problème à un seul endroit : les entrées-sorties (I/O). Dans la plupart des autres cas, je trouve que le fait de ne pas pouvoir utiliser des valeurs null par défaut nous oblige a nous poser la raison métier du cas particulier et a questionner notre conception.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
Culture

Un super article de la part d'un confrère Artisan, sur une technique simple et efficace pour mettre le pied à l'étrier sur un projet !


Partagé par Damien Palagi
il y a presque 3 ans
3

Derniers commentaires :
Marc Bouvier il y a presque 3 ans
Merci pour le partage, ca m'a fait pensé à mes vieux cours de merise mais en plus sexy :).

En tout cas, ça pourrait répondre à des problématique que j'ai (syndrome de la feuille blanche)
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Bonnes pratiques
Clean Code

Du code impeccable écrit partout pareil, ça donne envie, non ? Et pourtant, l’idée s’avère bien plus risquée qu’elle n’y parait.


Partagé par Léo Driat
il y a presque 3 ans
2

Derniers commentaires :
Mathieu Barberot il y a presque 3 ans - modifié il y a presque 3 ans
Globalement d'accord.
J'aurais quand même tendance à poser un .editorconfig d'office dans n'importe quel projet pour les conventions les plus basiques : encodage des fichiers, espaces/tabulations, cr/lf en fin de ligne...
C'est supporté par tous les éditeurs, ça ne mange pas de pain et ça évite bien des problèmes (je pense à toi, le caractère de fin de ligne différent selon l'OS et aussi à toi fichier YAML qui ne supporte pas les tabulations).
Pour les aspects plus avancés, je recommanderais les conventions officielles (s'il y en a) et de n'en diverger qu'exceptionnellement : un nouvel arrivant aura déjà bien assez de sujets qui nécessitent une réadaptation.
Marc Bouvier il y a environ 2 ans
Je rajoute aussi un `.gitattributes` pour forcer les fins de ligne automatiquement via git.
Pour ajouter un commentaire, tu dois te connecter ou créer un compte.
Artisan Développeur utilise des cookies afin de t'offrir les meilleurs services. En poursuivant ta navigation, tu acceptes l’utilisation de cookies. En savoir plus