Comme le soutient cet article, la capacité à bien « documenter » est vraiment importante.
Elle ne sert pas seulement à mettre en avant ses propres points forts et à faire valoir ses résultats, elle aide aussi à travailler plus confortablement et à donner des consignes aux autres.
Il n’est pas nécessaire de produire dès le départ des supports ou des documents impressionnants. Même si c’est simple, l’important est de prendre l’habitude d’organiser ses idées et de les consigner dans un document.
Je le sais moi aussi en théorie, mais je n’arrive pas vraiment à le mettre en pratique… C’est vraiment un sujet difficile.
Je ne connais peut-être pas les fondamentaux jusqu’au plus profond, mais j’ai vu que ne pas les connaître produit des résultats vraiment aberrants et totalement inimaginables.
Par exemple, implémenter une recherche en chargeant tous les enregistrements de la base de données en mémoire, puis en recherchant en mémoire.
Quand il y a peu d’enregistrements, ça fonctionne bien, mais quand ils deviennent nombreux, la mémoire explose.
Ils codent ainsi parce qu’ils ne comprennent absolument pas la différence entre la mémoire et une base de données.
Ce n’est qu’un exemple, et à chaque fois ils implémentent dans des directions vraiment inimaginables.
Un programmeur « ordinaire » ne peut vraiment pas l’imaginer.
Je suis moi aussi d’accord avec cet article.
Je pense que définir les problèmes à partir de valeurs d’état abstraites est utile pour identifier les problèmes, et j’essaie de créer des outils de gestion d’état visuels, explicites et clairs, comme la visualisation des états avec des diagrammes, Unreal Blueprint ou des workflows.
Je devrais sans doute m’intéresser d’abord au langage.
C’est un texte qui me rappelle mes cours de spécialisation en théorie de la calculabilité ! Je le recommande à celles et ceux qui programment pour approfondir le sujet.
Quoi qu’il en soit, le travail concret de l’ingénierie logicielle va beaucoup évoluer. Les machines à coder perdront en compétitivité, mais je parie que les ingénieurs capables de créer de vrais produits de bout en bout survivront.
J’ai travaillé dans le développement, puis j’ai aussi fait un peu de planification pendant quelques années, et le message du texte sur le fait qu’il faut « vendre » m’a vraiment parlé.
Même si un produit a été préparé et conçu avec énormément de soin, si l’on ne parvient pas à le défendre et à le vendre efficacement auprès de ses collègues, on ne peut pas obtenir leur soutien,
et au final, le projet ne peut pas avancer correctement.
S’il y a une idée que l’on a en tête, j’en ai retenu la leçon suivante : il est aussi essentiel de la faire connaître efficacement autour de soi afin d’obtenir l’adhésion des autres.
Ah, je corrigerai ça plus tard.
Du coup,
<selectlist>ne devient plus nécessaire ?Show GN : jeu web de combat/classement de configurations de personnages
Petite parenthèse : dans le bot Slack, le
<select>du titre ne s’affiche pas, haha.Je ne m’en étais pas rendu compte quand je l’ai vu hier, mais c’est Microsoft en fait, wow. Je vais l’essayer.
On dirait que les blogueurs qui surveillaient les nouveaux commits pour prédire les futures fonctionnalités vont être déçus.
Je comprends..!
Comme le soutient cet article, la capacité à bien « documenter » est vraiment importante.
Elle ne sert pas seulement à mettre en avant ses propres points forts et à faire valoir ses résultats, elle aide aussi à travailler plus confortablement et à donner des consignes aux autres.
Il n’est pas nécessaire de produire dès le départ des supports ou des documents impressionnants. Même si c’est simple, l’important est de prendre l’habitude d’organiser ses idées et de les consigner dans un document.
Je le sais moi aussi en théorie, mais je n’arrive pas vraiment à le mettre en pratique… C’est vraiment un sujet difficile.
Je ne connais peut-être pas les fondamentaux jusqu’au plus profond, mais j’ai vu que ne pas les connaître produit des résultats vraiment aberrants et totalement inimaginables.
Par exemple, implémenter une recherche en chargeant tous les enregistrements de la base de données en mémoire, puis en recherchant en mémoire.
Quand il y a peu d’enregistrements, ça fonctionne bien, mais quand ils deviennent nombreux, la mémoire explose.
Ils codent ainsi parce qu’ils ne comprennent absolument pas la différence entre la mémoire et une base de données.
Ce n’est qu’un exemple, et à chaque fois ils implémentent dans des directions vraiment inimaginables.
Un programmeur « ordinaire » ne peut vraiment pas l’imaginer.
https://fr.news.hada.io/topic?id=4138
Il y a aussi un certain Coolify.
Je suis moi aussi d’accord avec cet article.
Je pense que définir les problèmes à partir de valeurs d’état abstraites est utile pour identifier les problèmes, et j’essaie de créer des outils de gestion d’état visuels, explicites et clairs, comme la visualisation des états avec des diagrammes, Unreal Blueprint ou des workflows.
Je devrais sans doute m’intéresser d’abord au langage.
C’est un texte qui me rappelle mes cours de spécialisation en théorie de la calculabilité ! Je le recommande à celles et ceux qui programment pour approfondir le sujet.
C’est vraiment génial, non ? Je n’en reviens pas qu’il existe même ce genre de chose en open source haha
Le pire est mieux !
Quoi qu’il en soit, le travail concret de l’ingénierie logicielle va beaucoup évoluer. Les machines à coder perdront en compétitivité, mais je parie que les ingénieurs capables de créer de vrais produits de bout en bout survivront.
Je pense aussi que l’OpenAPI function calling n’est-il pas meilleur ? Rien que le fait de tout refaire avec le protocole MCP, c’est déjà du travail.
J’ai travaillé dans le développement, puis j’ai aussi fait un peu de planification pendant quelques années, et le message du texte sur le fait qu’il faut « vendre » m’a vraiment parlé.
Même si un produit a été préparé et conçu avec énormément de soin, si l’on ne parvient pas à le défendre et à le vendre efficacement auprès de ses collègues, on ne peut pas obtenir leur soutien,
et au final, le projet ne peut pas avancer correctement.
S’il y a une idée que l’on a en tête, j’en ai retenu la leçon suivante : il est aussi essentiel de la faire connaître efficacement autour de soi afin d’obtenir l’adhésion des autres.
À l’époque où même Docker Desktop utilise Kubernetes, c’est un peu dommage qu’il ne prenne en charge que Docker Swarm.
> ERROR: Unsupported distribution 'manjaro'
J’ai voulu faire un test, mais Manjaro n’est pas pris en charge. C’est un peu dommage, cela dit.
Anthropic publie Model Context Protocol en open source
Comment développer avec Model Context Protocol (MCP)
Explication comparative entre MCP et les API
Awesome MCP Servers - Liste des serveurs prenant en charge Model Context Protocol