Développeur, je réponds à vos questions

C'est si compliqué que ça d'être développeur ?

Genre c'est vraiment plusieurs années d'études ou ça peut s'apprendre "sur le tas" ?

Le 07 avril 2023 à 00:17:40 :

Le 07 avril 2023 à 00:16:49 :

Le 07 avril 2023 à 00:15:56 :
quel est la plus grosse erreur que tu as faite en tant que dev ?

En stage il y a plus de 10 ans, j'ai reset les mdp de tous les utilisateurs d'un site top 100 fr

et donc tu as géré ça comment ? ça t'as appris quoi ?

y'avais des backup avec des dump bdd fais tous les jours.
On a remis ni vu ni connu une bdd de la matinée

J'ai dû me faire petit pendant qqs semaines, mais à la fin de mon stage on m'a proposé un CDD

Le 07 avril 2023 à 00:20:46 :

Le 07 avril 2023 à 00:17:40 :

Le 07 avril 2023 à 00:16:49 :

Le 07 avril 2023 à 00:15:56 :
quel est la plus grosse erreur que tu as faite en tant que dev ?

En stage il y a plus de 10 ans, j'ai reset les mdp de tous les utilisateurs d'un site top 100 fr

et donc tu as géré ça comment ? ça t'as appris quoi ?

y'avais des backup avec des dump bdd fais tous les jours.
On a remis ni vu ni connu une bdd de la matinée

J'ai dû me faire petit pendant qqs semaines, mais à la fin de mon stage on m'a proposé un CDD

et tu as pas suggéré que peut être c'est pas très safe de filer un accès en écriture à une base de prod au stagiaire quand on est une boite du top 100 fr ?

Le 07 avril 2023 à 00:21:11 :
Que penses-tu du Cobol ? Est-ce judicieux de se former sur ce langage ? A défaut, sur une double compétence Java/Cobol ?

Non, c'est de l'antiquité.
Go Rust ou Solidity. Sinon python si tu veux pas te prendre la tête

Le 07 avril 2023 à 00:22:14 :

Le 07 avril 2023 à 00:20:46 :

Le 07 avril 2023 à 00:17:40 :

Le 07 avril 2023 à 00:16:49 :

Le 07 avril 2023 à 00:15:56 :
quel est la plus grosse erreur que tu as faite en tant que dev ?

En stage il y a plus de 10 ans, j'ai reset les mdp de tous les utilisateurs d'un site top 100 fr

et donc tu as géré ça comment ? ça t'as appris quoi ?

y'avais des backup avec des dump bdd fais tous les jours.
On a remis ni vu ni connu une bdd de la matinée

J'ai dû me faire petit pendant qqs semaines, mais à la fin de mon stage on m'a proposé un CDD

et tu as pas suggéré que peut être c'est pas très safe de filer un accès en écriture à une base de prod au stagiaire quand on est une boite du top 100 fr ?

C'était il y a plus de 10 ans et les boites (surtout FR) n'étaient pas aussi équipées en matière de CI/CD, non reg et ACL.

Mais mon maître de stage a reconnu à l'époque que c'était de sa faute et qu'il aurait dû relire mon code et l'envoyer pour test QA avant de l'envoyer en prod

Le 07 avril 2023 à 00:22:35 :

Le 07 avril 2023 à 00:21:11 :
Que penses-tu du Cobol ? Est-ce judicieux de se former sur ce langage ? A défaut, sur une double compétence Java/Cobol ?

Non, c'est de l'antiquité.
Go Rust ou Solidity. Sinon python si tu veux pas te prendre la tête

Ah c'est vraiment pas prometteur même à l'étranger ? Vu que personne fait du Cobol ça me semblait être le bon plan

Le 07 avril 2023 à 00:19:48 :

Le 07 avril 2023 à 00:17:09 :
quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

Le 07 avril 2023 à 00:17:09 :
quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients avec des call spécifiques et des requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

Le 07 avril 2023 à 00:17:09 :
quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

Le 07 avril 2023 à 00:17:09 :
quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Niveau 1 de REST = resources
Niveau 2 = verbes HTTP / codes retour
Niveau 3 = hateoas

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

Le 07 avril 2023 à 00:17:09 :
quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Y'a pas de technos à privilégier, tu me parles d'architecture.
Et event-sourcing et CQRS sont eux notions différentes.

Le 07 avril 2023 à 00:37:44 :

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

> Le 07 avril 2023 à 00:17:09 :

>quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Niveau 1 de REST = resources
Niveau 2 = verbes HTTP / codes retours
Niveau 3 = hateoas

ha oui je vois, tu penses que ça vaut le coup d'implémenter le niveau hateoas ?

Le 07 avril 2023 à 00:39:01 :

Le 07 avril 2023 à 00:37:44 :

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

> Le 07 avril 2023 à 00:19:48 :

>> Le 07 avril 2023 à 00:17:09 :

> >quels technique de communication interservices préconises-tu dans une architecture microservices ?

>

> Idéalement les microservices ne devraient pas communiquer entre eux.

> S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

>

> En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.

> En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Niveau 1 de REST = resources
Niveau 2 = verbes HTTP / codes retours
Niveau 3 = hateoas

ha oui je vois, tu penses que ça vaut le coup d'implémenter le niveau hateoas ?

J'en ai jamais eu le besoin. Des frameworks permettent de l'avoir à moindre coût.
Si tu es sur une application privée c'est pas forcément la peine vu que les équipes communiquent entre elles.

Le niveau Hateoas c'est de la documentation auto-portée par l'API. Donc surtout utile pour des consommateurs qui ne connaissent pas l'API et les fonctionnalités disponibles.

Le 07 avril 2023 à 00:38:33 :

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

Le 07 avril 2023 à 00:19:48 :

> Le 07 avril 2023 à 00:17:09 :

>quels technique de communication interservices préconises-tu dans une architecture microservices ?

Idéalement les microservices ne devraient pas communiquer entre eux.
S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.
En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Y'a pas de technos à privilégier, tu me parles d'architecture.
Et event-sourcing et CQRS sont eux notions différentes.

ok, comment tu implémentes les projections dans un archi avec de l'event sourcing ?
quid des framework d'event sourcing ?

Le 07 avril 2023 à 00:40:57 :

Le 07 avril 2023 à 00:38:33 :

Le 07 avril 2023 à 00:36:19 :

Le 07 avril 2023 à 00:31:53 :

Le 07 avril 2023 à 00:28:56 :

> Le 07 avril 2023 à 00:19:48 :

>> Le 07 avril 2023 à 00:17:09 :

> >quels technique de communication interservices préconises-tu dans une architecture microservices ?

>

> Idéalement les microservices ne devraient pas communiquer entre eux.

> S'ils le font, faut regarder en fonction des besoins synchrones ou asynchrones.

>

> En synchrone t'as pas beaucoup d'autre choix que de passer par l'HTTP.

> En asynchrone vaut mieux privilégier un message broker, qui te permettra de rejouer les messages en cas d'échec (là où tu perdras la requête http en cas d'erreur car la plupart des app de monitoring n'enregistrent que le get et pas le body d'un post)

une archi microservice sans communication ça existe ça ?
tu fais comment pour que le service order envoie la commande au service production ?
si tu utilises une communication synchrone comment tu choisis entre une api REST ou GraphQL ou RPC ?

Le GraphQL c'est surtout orienté client et c'est un langage de requêtage (en GraphQL on t'impose un seul endpoint /graphql et on n'utilise pas du tout la trame HTTP pour la gestion des codes retours), là où REST c'est une notion d'architecture back à 3 niveaux.

Si t'as pas plusieurs clients et de requêtes compliquées => REST
Si t'as pas besoin de perf de fou et de protobuf, inutile d'utiliser gRPC. On n'est pas tous Google. REST en backend ça suffit à 99% des use cases.

une architecture à 3 niveaux ?

sinon tu me conseilles quoi comme technos pour implémenter du cqrs et de l'event sourcing ?

Y'a pas de technos à privilégier, tu me parles d'architecture.
Et event-sourcing et CQRS sont eux notions différentes.

ok, comment tu implémentes les projections dans un archi avec de l'event sourcing ?

Il y a plusieurs frameworks qui te fournissent tout ça clé en mains.
A l'époque quand j'utilisais ce type d'archi (en 2017) on faisait ça de façon un peu artisanale. Le plus important à comprendre dans l'event sourcing et surtout dans les types d'architecture asynchrones c'est la notion d'acquittement.

Le 07 avril 2023 à 00:47:41 :
pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

Le 07 avril 2023 à 00:48:48 :

Le 07 avril 2023 à 00:47:41 :
pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

Le 07 avril 2023 à 00:50:38 :

Le 07 avril 2023 à 00:48:48 :

Le 07 avril 2023 à 00:47:41 :
pourquoi je devrais me soucier de la notion d'acquittement, ma techno de communication me fournie une garantie de delivery at least once en général

De façon abstraite comme ça je ne pourrais pas te répondre sans voir l'implémentation. Si c'est pris en compte de façon générique par la solution logicielle tant mieux... mais elle ne fait qu'implémenter un pattern

ok tu penses quoi des pratiques "craft" ?
tu utilises le bdd et le tdd ?
j'arrive pas bien à comprendre la différence entre un subdomain et un bounded context

T'as envie de me tester c'est ça ? Je vais pas rentrer dans ton jeu, et je suis coach "Craft".
Je dirais que les pratiques craft et ce que beaucoup vendent sur linkedin c'est du bullshit. Le craftsmanship c'est un état d'esprit et surtout 4 principes: https://manifesto.softwarecraftsmanship.org
Quand on est dans une mission "craft", on essaie d'inculquer une dynamique "craft", mettant en avant la compétence technique. C'est ça qui est important.

Il n'a jamais été question de BDD et de TDD, qui ne sont que des pratiques logicielles et non des principes.
Et qui plus est, le TDD ne veut pas dire faire du code propre et bien tester. Et même en TDD faut différencier l'approche classical TDD (detroit) et l'approche mockiste (London school) qui n'ont rien avoir.