Il est inévitable que les développeurs juniors choisissent React, mais le vrai problème, c’est que les développeurs seniors cessent de réfléchir à d’autres alternatives.
En y réfléchissant après avoir posté mon commentaire, je me demande comment se fait la vérification d’âge si c’est sous forme de distributeur automatique dans un café sans personnel. Est-ce que le distributeur a aussi une fonction de lecture de pièce d’identité ?..
Je ne le savais pas non plus, étant non-fumeur, mais je l’ai découvert récemment en voyant un distributeur automatique de cigarettes électroniques jetables dans un café sans personnel qui a ouvert près de chez moi. Dans les commentaires de Hacker News ci-dessous aussi, la moitié parle de ce gaspillage absurde de ressources. Haha
Ça me rappelle mes souvenirs (?) de la fin des années 2000, quand je travaillais dans une entreprise de logiciels de navigation automobile et que je développais un module de recherche d’itinéraire.
On n’utilise pas Dijkstra pour la recherche d’itinéraire en navigation, car c’est trop lent ; on emploie plutôt A* (A Star), une version améliorée par heuristique. En vérifiant, je vois qu’A* n’est pas un algorithme SSSP mais SPSP (Single-Pair Shortest Path).
markitdown est pratique pour convertir entre différents formats, mais il ne faut surtout pas l’utiliser pour les PDF.
Il existe déjà beaucoup de méthodes d’extraction de documents utilisant des LLM multimodaux comme Gemini, et les résultats sont plutôt bons, y compris dans les benchmarks. Le problème, c’est le coût.
Ce n’est pas vraiment du bas niveau… Pour implémenter un formulaire, on pourrait s’en sortir en utilisant simplement les balises input HTML, mais avec le state, le JSX, les composants contrôlés/non contrôlés, il faut apprendre beaucoup de choses inutiles et générer beaucoup de code, donc j’imagine que c’est peut-être ce qui a motivé l’auteur de l’article.
On dirait que dire qu’une nouvelle méthode est apparue revient à dire que l’ancienne est morte.
Est-il vraiment vrai qu’on ne peut plus utiliser la méthode existante et qu’il faut absolument utiliser la nouvelle ?
J’adhère beaucoup au concept, donc j’ai fait quelques tests ce week-end sur un nouveau projet, mais cela ne fonctionne pas aussi bien que je l’espérais. Il semble qu’il y ait encore beaucoup d’améliorations à apporter. En gros, le fonctionnement est le suivant, comme cela a déjà été présenté plusieurs fois :
Rédaction de la constitution → rédaction de la spec → rédaction des tâches → implémentation
Le problème, c’est que :
le fichier constitution.md est un guide clé sur la manière de développer, mais il ne contient pas ce que cette application deviendra au final
spec.md est un document qui décrit une fonctionnalité
il n’existe pas de document maître expliquant « ce qu’est cette application »
en lisant les discussions en cours sur GitHub, j’ai l’impression que la chaîne des specs finira par devenir la source of truth ; cela me laisse perplexe, mais je peux à peu près comprendre l’idée
les commandes /specify et /tasaks génèrent beaucoup de documents comme livrables (ce qui était l’objectif), mais du coup elles consomment rapidement le contexte (j’utilise Claude Code)
une fois l’implémentation lancée, on s’éloigne temporairement de Spec Kit et on finit l’implémentation comme d’habitude en discutant avec Claude Code
quand tout le contexte est consommé et qu’on compacte, ou qu’on démarre une nouvelle session, il oublie l’existence des documents générés par Spec Kit
en avançant sur les tâches définies dans tasks.md, on finit parfois par écraser ce qui avait été bien fait au début, et on crée aussi de nouvelles fonctionnalités en corrigeant des bugs ; on s’éloigne donc de plus en plus de tasks.md. Je ne vois pas l’intérêt de conserver tasks.md de manière permanente.
Pour l’instant, la conclusion à laquelle je suis arrivé est la suivante :
même si le résultat diffère de l’idée de départ, il faut d’abord terminer la spec, puis en créer une nouvelle pour corriger progressivement
la spec initiale ne peut qu’être volumineuse ; il vaudrait mieux ne pas décrire du tout les fonctionnalités de l’application et se limiter à créer du boilerplate
pour construire quelque chose au niveau PoC, il vaut mieux ne pas utiliser Spec Kit
Oh, ça a l’air plutôt pas mal.
Oh… c’est plutôt convaincant.
Il est inévitable que les développeurs juniors choisissent React, mais le vrai problème, c’est que les développeurs seniors cessent de réfléchir à d’autres alternatives.
Contenu intéressant.
> Refuser de recruter des talents meilleurs que soi
Je l’ai souvent vu, non seulement chez les fondateurs, mais aussi à des postes de leadership.
D’après mon expérience, je me retrouve beaucoup dans le point 3.
Le pire format : le PDF
En y réfléchissant après avoir posté mon commentaire, je me demande comment se fait la vérification d’âge si c’est sous forme de distributeur automatique dans un café sans personnel. Est-ce que le distributeur a aussi une fonction de lecture de pièce d’identité ?..
Je ne le savais pas non plus, étant non-fumeur, mais je l’ai découvert récemment en voyant un distributeur automatique de cigarettes électroniques jetables dans un café sans personnel qui a ouvert près de chez moi. Dans les commentaires de Hacker News ci-dessous aussi, la moitié parle de ce gaspillage absurde de ressources. Haha
Ça me rappelle mes souvenirs (?) de la fin des années 2000, quand je travaillais dans une entreprise de logiciels de navigation automobile et que je développais un module de recherche d’itinéraire.
On n’utilise pas Dijkstra pour la recherche d’itinéraire en navigation, car c’est trop lent ; on emploie plutôt A* (A Star), une version améliorée par heuristique. En vérifiant, je vois qu’A* n’est pas un algorithme SSSP mais SPSP (Single-Pair Shortest Path).
Pour en avoir fabriqué un moi-même, je peux dire que, pour la personnalisation, il faut parfois plus de 2 gigaoctets d’informations.
markitdownest pratique pour convertir entre différents formats, mais il ne faut surtout pas l’utiliser pour les PDF.Il existe déjà beaucoup de méthodes d’extraction de documents utilisant des LLM multimodaux comme Gemini, et les résultats sont plutôt bons, y compris dans les benchmarks. Le problème, c’est le coût.
Des outils comme
doclingsont bien aussi.Les fonctionnalités et l’approche semblent être les mêmes qu’Atlas : https://atlasgo.io/
Je me reconnais beaucoup dans ces trois principaux pièges. Le simple fait d’avoir un seul gatekeeper peut déjà entraîner plusieurs effets néfastes.
Ce n’est pas vraiment du bas niveau… Pour implémenter un formulaire, on pourrait s’en sortir en utilisant simplement les balises
inputHTML, mais avec le state, le JSX, les composants contrôlés/non contrôlés, il faut apprendre beaucoup de choses inutiles et générer beaucoup de code, donc j’imagine que c’est peut-être ce qui a motivé l’auteur de l’article.Je ne fume pas, donc je me demandais de quoi il s’agissait, mais vous voulez dire qu’un produit jetable consomme beaucoup trop de ressources.
La grandeur d’un karma à -47 mdr
On dirait que dire qu’une nouvelle méthode est apparue revient à dire que l’ancienne est morte.
Est-il vraiment vrai qu’on ne peut plus utiliser la méthode existante et qu’il faut absolument utiliser la nouvelle ?
J’adhère beaucoup au concept, donc j’ai fait quelques tests ce week-end sur un nouveau projet, mais cela ne fonctionne pas aussi bien que je l’espérais. Il semble qu’il y ait encore beaucoup d’améliorations à apporter. En gros, le fonctionnement est le suivant, comme cela a déjà été présenté plusieurs fois :
Rédaction de la constitution → rédaction de la spec → rédaction des tâches → implémentation
Le problème, c’est que :
/specifyet/tasaksgénèrent beaucoup de documents comme livrables (ce qui était l’objectif), mais du coup elles consomment rapidement le contexte (j’utilise Claude Code)Pour l’instant, la conclusion à laquelle je suis arrivé est la suivante :
hahahahahaha