Prêt pour le daily de demain les pisseurs de code ?

Le 20 février 2021 à 15:22:54 NotMyStatue a écrit :

Le 20 février 2021 à 14:01:38 alpachinois69 a écrit :

Le 20 février 2021 à 13:40:42 NotMyStatue a écrit :

Le 20 février 2021 à 11:16:26 ethyl-acetate a écrit :
Dans un pattern avec une API gateway, on évite completement les discussions directement entre microservices ? On essaie de centraliser au max ?

Alors , oui c'est logiquement la Gateway qui va s'occuper de l'agrégation de la donnée.

Après deux points quand même :
- Mettre en place une Gateway pour une application assez simple va amener de la complexité inutile et elle vous servira juste à faire un rebond.
- Un microservice doit être correctement défini. On définit un contexte précis (notion de Bounded Context)
Exemple vu en entreprise : Microservice Utilisateur, Society, Addresse ...
Ca ne représente aucune entité dans le business et ça amène a des lourderies au niveau de la maintenance.

Enfin si tu veux de la communication entre MS, il faut comprendre le comment du pourquoi
Un microservice Order qui va valider une commande et doit par exemple parler au Microservice Shipping...
Un service bus est une solution (surement la plus propre).

Micrservice adresse?

Décidément les archi pour un potable t'en as 3 qui puent la merde

C'est si étonnant que ça ?
La plus part des gens effectuent des découpages par entités et non pas par fonctionnalité.

Et encore ça dépends ce que tu entends par potable

Potable dans le sens qu'il comprend les problématiques métiers ET technique.Je devrais me lancer dedans je pense si je trouve rien en cto. Si les architectes microservices connaissent pas les principes ddd et découpage en bounded context j'ai alors toute mes chances

Le 20 février 2021 à 15:29:34 ethyl-acetate a écrit :
On a une app de reconnaissance faciale qu'on avait poc avec un pote, on voudrait essayer de faire grossir un peu le projet et de revoir completement l'archi du truc, on sait pas vraiment comment s'y prendre

C'est super ca. Vous l'avez fait en quoi? En C++ avec OpenCV?

Le 20 février 2021 à 15:37:27 Pierre_Aronnax a écrit :

Le 20 février 2021 à 15:29:34 ethyl-acetate a écrit :
On a une app de reconnaissance faciale qu'on avait poc avec un pote, on voudrait essayer de faire grossir un peu le projet et de revoir completement l'archi du truc, on sait pas vraiment comment s'y prendre

C'est super ca. Vous l'avez fait en quoi? En C++ avec OpenCV?

dlib et python pour train le model

Le 20 février 2021 à 15:29:49 alpachinois69 a écrit :

Le 20 février 2021 à 15:22:54 NotMyStatue a écrit :

Le 20 février 2021 à 14:01:38 alpachinois69 a écrit :

Le 20 février 2021 à 13:40:42 NotMyStatue a écrit :

Le 20 février 2021 à 11:16:26 ethyl-acetate a écrit :
Dans un pattern avec une API gateway, on évite completement les discussions directement entre microservices ? On essaie de centraliser au max ?

Alors , oui c'est logiquement la Gateway qui va s'occuper de l'agrégation de la donnée.

Après deux points quand même :
- Mettre en place une Gateway pour une application assez simple va amener de la complexité inutile et elle vous servira juste à faire un rebond.
- Un microservice doit être correctement défini. On définit un contexte précis (notion de Bounded Context)
Exemple vu en entreprise : Microservice Utilisateur, Society, Addresse ...
Ca ne représente aucune entité dans le business et ça amène a des lourderies au niveau de la maintenance.

Enfin si tu veux de la communication entre MS, il faut comprendre le comment du pourquoi
Un microservice Order qui va valider une commande et doit par exemple parler au Microservice Shipping...
Un service bus est une solution (surement la plus propre).

Micrservice adresse?

Décidément les archi pour un potable t'en as 3 qui puent la merde

C'est si étonnant que ça ?
La plus part des gens effectuent des découpages par entités et non pas par fonctionnalité.

Et encore ça dépends ce que tu entends par potable

Potable dans le sens qu'il comprend les problématiques métiers ET technique.Je devrais me lancer dedans je pense si je trouve rien en cto. Si les architectes microservices connaissent pas les principes ddd et découpage en bounded context j'ai alors toute mes chances

Je pense qu'il y a plusieurs problèmes dans ce genre de cas.. Et que mêmes avec les connaissances, c'est pas aussi simple de mettre en place.

- Travailler sur du legacy code dans une entreprise où rien n'est documenté et que les devs tentent de sauver la barraque tant qu'ils peuvent.
- Business peu ou pas présent (je parle des personnes)
- Temps et moyen limité

J'essaye déjà de faire comprendre l'importance d'avoir un modèle d'écriture et lecture mais déjà la plupart des gens sont perdus et comprennent rien.

Je bosse avec deux personnes : 31 et 42 ans et l'adage "tester , c'est douté", est bien présent.
C'est quasiment impossible d'expliquer divers pratique de DDD , CQRS , ES, Tests unitaires car l'argument ultime par rapport à ça, c'est le manque de temps et c'est difficilement contrable quand t'as pas envie de faire des journées de 12h

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Le 20 février 2021 à 15:58:39 ethyl-acetate a écrit :
c'est à lire martin fowler ?

Clairement
Et Uncle bob aussi (même si ce que dit ce dernier je trouve que ça coule de source bien souvent)

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

C'est surtout le mouvement de marche forcée qui me va pas. Suffit de voir le js et ses 750 bibliothèques pour au final apporter beaucoup de choses?

Je suis pas ton manager, je pense pas que celui-ci soit certifié Microsoft azure ou soit dba à ces heures perdus ?

Je le dis en tant que technicien. Je vois des gens qui bossent même le week-end et les vacances car veulent check le dernier framework sorti.

Le 20 février 2021 à 17:28:23 moishemea a écrit :

Le 20 février 2021 à 17:24:24 NotMyStatue a écrit :

Le 20 février 2021 à 17:09:29 alpachinois69 a écrit :

Le 20 février 2021 à 16:57:08 NotMyStatue a écrit :

Le 20 février 2021 à 16:47:40 alpachinois69 a écrit :

Le 20 février 2021 à 16:42:51 NotMyStatue a écrit :

Le 20 février 2021 à 16:40:59 alpachinois69 a écrit :

Le 20 février 2021 à 16:33:34 NotMyStatue a écrit :

Le 20 février 2021 à 16:27:59 alpachinois69 a écrit :
Ddd, cqrs c'est carrément pas plus long à faire. C'est à l'architecte de bien faire les choses. Les tests tout ça oui ça prend beaucoup de temps à faire au début. Après on fait nos débats de geek mais faut également comprendre le reste.

Quand c'est mis en place , en effet.
Par contre l'envie de taper un dbContext dans le controller et tout faire comme un sac reste toujours présente malgré tout

Tu entends quoi par comprendre le reste ?

Comprendre les enjeux business.

Les fameux enjeux business.

Oui quand t'as des mecs qui veulent absolument mettre du azure bus car c'est hype alors que le métier c'est de faire des formulaires html voilà quoi

Je vois aussi que cet argument a déjà été utilisé mainte et mainte fois pour éviter toute évolution des systèmes.
Ou imposer des technologies sans aucune raison valable si ce n'est que : "c'est bon pour le business" .

Je vois encore ce bon vieux intégrateur qui continue a faire son petit jquery car Angular, React, Vue , c'est pas bon pour le business mais des framework Js obscures correspondent parfaitement à l'use case

Tout est une question d'équilibre. L'informatique tu fais évoluer quand c'est nécessaires. Si ton site en jquery est bien construit et fonctionne encore migrer sur angular va te servir à quoi si aucun gain productivité et qu'on ne trouve pas de faille secu?

Refaire ton système implique donc un gros budget pour tout et former tes utilisateurs qui peuvent se dire fuck on veut pas de votre outils 2.0

Ne serait-ce pas plus intelligent de mettre le budget pour des technos plus récentes dans de nouveaux projets qui améliorent vraiment les choses?

Tu tiens plus ou moins le même discours que mon ancien manager ce qui me fait assez peur

Et à savoir que la carotte fonctionnait plutôt bien car une fois les nouveaux projets arrivaient , on reprenait les mêmes stacks pourris sous prétexte qu'on a pas de temps à perdre .

Je déteste ce genre de discours car ça finit par mettre une boucle sur les développeurs.
Ils vont continuer le train-train quotidien et s'enfermer dans des technos sans jamais évoluer.
Tu finis par ne plus être employable dans le monde du travail mais bon vu que c'est pour le business, c'est acceptable

Après si l'entreprise décide d'évoluer, ça peut fonctionner mais la réalité que j'ai vu sur le terrain , c'est souvent l'inverse.

Dans ma boîte c’est pareil

Le discours : « pourquoi changer une équipe qui gagne » alors que c’est pas vraiment le cas.
On tourne tout récemment des projets sur du Symfony/Vue.js mais c’est bancal car nouveaux pour nous et pas de montée en compétences desssu.... car les développeurs doivent se former à côté.
Sauf que passe un certain âge, avec des contraintes familiales, l’auto formation t’en fait de moins en moins.

Bref du coup, les projets avec nouvelles technos se cassent la gueule et ceux avec des anciennes technos fonctionnent bien que ça peut générer une dette technique.... d’ici là le CTO aura ramassé ce qu’il faut pour se barrer ailleurs et ça ne sera plus son problème.

Pour une boite, avoir des technos à jour et "sexy" ça permet aussi d'intéresser les bons développeurs qui cherchent une mission.

Le 20 février 2021 à 17:30:55 alpachinois69 a écrit :

Je suis pas ton manager, je pense pas que celui-ci soit certifié Microsoft azure ou soit dba à ces heures perdus ?

Juste comme ça, les certif on s'en branle.
J'ai fait passer un entretien récemment à un mec triplement certifié (spring, java et AWS). Le mec était nul et quand j'ai vu son code... il était pas à jour dans ses pratiques.
A côté j'ai fait passer un entretien à qqn pas certifié mais qui a bossé dans plein de boites reconnues de mon milieu et qui fait de la veille... c'était bien plus intéressant.

Je préfère mille fois un mec qui fait de la veille, qui va à des conférences tech, qu'un bulshiter qui a farmé une semaine pour être certifié