Why?

• We don't need one until we do

  • you almost never create an object fully formed with all the behavior it is ever going to need
  • when it is complex enough, it costs too much time to replace it with something that has equivalent functionality

• the state machine is a fluffy bunny

  • there is the belief that state machines are more complex than they actually are
  • it is therefore nothing but pragmatism that makes us consider a “full-blown” state machine overkill.

BUT most state machines you’re likely to need in your day-to-day development have nothing in common with their computing theory counterparts

• Adding a state machine library has a learning curve. It is rather small.

So moving to a state machine:

• Integration is painless but moving all the code around to be inline with state machine is a big pain
• Using it from the start is a breeze, as such as future changes.
• We’re now able to easily introduce more states to give our users extra information as well as allow us to track things to a finer grain.
• Return values from state transitions are 100% consistent. There are no strange objects, arrays, nil, boolean depending of the developers.
• It is easy to log
• Refactoring lead to greater code quality with state machines

We seem to shy away from state machines due to misunderstanding of their complexity and/or an inability to quantify the benefits

Pour ça, il faut être impliqué dans les phases d'exploration produit. Il faut prendre du temps pour parler aux utilisateurs. Si votre produit est utilisé sur des chantiers, allez sur les chantiers, s'il est utilisé par le support client, regardez les l'utiliser. Ne reposez jamais sur un proxy de vos utilisateurs, commerciaux et autres parties prenantes internes à votre entreprise, sinon vous allez créer un outil pour ces personnes, pas un produit pour vos clients !

Fait important à retenir, vous n'êtes pas payé pour dire que quelque chose n'est pas faisable, mais pour faire en sorte que ça le soit.
Vous êtes là pour apporter des alternatives sur la table. Et pour cela il faut être actif, comprendre précisément le problème à résoudre, d'où la participation aux interviews utilisateurs, l'analyse quantitative, etc.

Les classiques mais effficaces.

Je penses dériver du sujet et ajouter une touche particulière. par exemple, le système de gestion des stocks peut être spécialisé sur ... du composte, des pièce 3D, öa plateforme de covoiturage peut avoir un système de calcul des émissions de CO2 évolué, etc...

Rust can be used to write all kinds of software (vertically scalable) and the development of software artifacts can be parallelized (horizontally scalable).

while it excels in the lowest half of the stack, it’s pretty ok everywhere else too.

The rust golden rule:

how function signatures are mandatory and authoritative and explicitly define the interface both for the callers of the function and for the function’s body. more

The second feature of Rust is its module system. It's first class support of the concept of libraries.

The third is cargo with its rigid specification for what a package of rust code.

Quelle est la différence entre produit et side project

1. Ne pas écouter ses utilisateurs (car le produit n'est pas fini)
2. Se concentrer sur les fonctionnalités aux lieu de prototype technologiques, surtout lorsque cela est fait par des tech/devs.
3. Un produit demande plusieurs corps de métier à l’œuvre. La vente est importante, ou des compétences légales ou financières.

Un side project c'est un projet qu'on réalise à côté, le soir, le week end. C'est un extra en dehors d'une autre activité. On le fait sans contraintes en mode best effort. Et si j'arrive à une conclusion désormais, c'est que dans beaucoup de sujets, le mode best effort c'est le meilleur moyen d'échouer.

Bref, pour caricaturer, il y a donc deux extrêmes qui ne marchent pas :

• le mode best effort, sans moyen, sans temps alloué
• la profusion de moyens et l'absence de contraintes

Et pour transformer un side project en produit, il faut viser la solution médiane : être à 100% et avoir des contraintes.

caused by AI? Such an AI is incompetent.

• We only ship good work
• We ship when we’re confident
• We ship when the work is finished
• We own the issues after we ship
• We don’t ship if it isn’t right
• We ship our collective best effort
• We ship to our appetite

Les mauvaises pratiques de Capgemini semblent être pointé du doigt. Il s'agit des ESN en général.

Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests

“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.

Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".

Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.

Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.

(avec le TDD)

Ainsi, il ne peut pas y avoir la moindre ligne de code écrite sans test. Au-delà d’une technique de développement, cette technique de conception permet de poser la question explicitement : “Qu’est-ce que tu cherches à vérifier ?” Lorsqu’on répond à cette question, en développant le test automatisé qui matérialise la réponse, alors l’implémentation du morceau de fonctionnalité découle naturellement.

Un bug va obligatoirement engendrer plusieurs heures de perte pour l’organisation au global, en plus de créer des frustrations, de la perte d’image de marque, de détérioration de la confiance envers le produit, des mauvaises notes sur les stores et un risque de perte définitive du client.

Continuous learning :)

A list of podcasts: from JS, Infrastructure, and dev topics

1. Une seule chose à la fois

2. L’andon. On arrête tout.
   Si une personne est bloqué, on arrête tout tant qu'une solution n'est pas trouvé. Si besoin, on fait évoluer les standards.

3. les standards
   Alors si tu sais comment livrer du code de qualité, écris-le et explique-le. Un document qui guide notre façon de travailler et auquel on a nous-même contribué, c’est un outil simple et puissant pour accroître la qualité de ce qu’on fait.

roadmap.sh is a community effort to create roadmaps, guides and other educational content to help guide the developers in picking up the path and guide their learnings.

Our tools are the best, with features that impress

🎶

We build relationships, with developers we meet
And together, we make the product complete

Pour aller plus loin, le code en lui-même n’est peut-être pas si critique, mais ce que l’on a appris en le concevant et l’utilisant l’est bien davantage. C’est cette transmission qu’il est important de rendre possible au sein de l’équipe.

All in one resource that includes dozens of tools and utilities useful for web developers and programmers.

It seems well designed :)

Engineers who do this successfully tend to exhibit the following behaviors:

• They are defensive of their time.
• They “pay themselves first.”
• They defend the time of others.
• They clearly designate interrupt-driven work and batch it.
• They clearly designate low-leverage work, and time-box it.
• They communicate with candor.
• They prioritize ruthlessly.