J’ai abandonné VS Code après l’avoir utilisé pendant 5 ans, et c’est vraiment bien.

 

Super. Si sqlite faisait ça, j’ai l’impression que ce serait un vrai raz-de-marée. Bon, avec des failles de sécurité aussi.

 
kaydash 2025-03-14 | commentaire parent | dans: Kubernetes et les bases de données (iwanhae.tistory.com)

Les performances se dégradent, les opérations de maintenance deviennent plus difficiles, et en cas d’incident, le nombre important de points de gestion complique l’identification de la cause.
Cela crée une situation exactement opposée à l’objectif initial de k8s, qui est de réduire les points de gestion et la charge opérationnelle.

 
galadbran 2025-03-13 | commentaire parent | dans: TypeScript 10 fois plus rapide (devblogs.microsoft.com)

Ah, en lisant un peu plus l’article, je pense que je me suis embrouillé parce qu’il était aussi question d’un éditeur plus rapide.

  • tsc devient 10 fois plus rapide. Autrement dit, le temps de transpilation de ts vers js est fortement réduit.
  • Le chargement de gros projets développés en ts, comme VSCode, devient beaucoup plus rapide. Cela signifie que la logique qui partage les fonctionnalités de tsc, comme l’analyse syntaxique de ts, a été accélérée.
  • Cela ne veut pas dire que VSCode lui-même s’exécute plus vite.
    C’était donc bien de cela qu’il s’agissait.
 

J’utilise peu Cmd+K dans vscode parce que je l’ai remplacé par Cmd+R, mais on ne voit passer que des témoignages sur les gains de productivité… pff, il faudrait peut-être que je migre.

 

Le livre <Le Projet Phoenix>, souvent mentionné sur GeekNews, raconte une idée similaire. Plus on se rapproche de 100 % de capacité, plus le temps de réponse s’allonge de façon exponentielle.

 

Je suis entièrement d’accord avec ce que cet article avance, tout en partageant aussi le problème que vous avez mentionné,
c’est d’ailleurs un point sur lequel je réfléchis moi-même en ce moment.
Cela variait selon les squads, mais lorsque les membres de l’équipe participaient activement au sprint planning, le problème que vous avez évoqué ne se produisait pas. En partageant le contexte du projet et l’évolution de la situation à chaque sprint, nous avons cherché à faire en sorte que chacun puisse bien prendre conscience des changements de tâches, tout en demandant que le travail soit découpé de manière très fine.
Comme vous l’avez dit, du point de vue de la gestion, si l’on pense au suivi de l’avancement, à la mesure de la vitesse d’exécution, à la réponse aux imprévus, ainsi qu’au coût d’opportunité lorsque le contenu du travail ne se déroule pas comme prévu, il s’avère qu’en fin de compte, mieux vaut découper finement pour que tout avance correctement.

 

Je ne comprends pas. On est loin, même d’un niveau académique, et même du niveau codage d’un élève de primaire ; pourquoi partager ça...

 
  • En tant que professionnel du secteur des sciences de la vie, je souhaite partager brièvement mon retour d’usage.

Le mode Research est proposé en 2 variantes.

  1. Quick summary
  • Le temps nécessaire est d’environ 5 à 6 minutes (sur une 4070 ti super, 16GB, avec Mistral et Gemma 3:12b).
  • Il y a des hallucinations, et les références sont générées directement, mais les refs liées dans le document semblent avoir des sources claires.
  • Il y a une intention de répondre aux questions en se concentrant sur les nouvelles technologies. En particulier, cela cherche à les relier à l’IA.
  1. Detailed Report
  • Le temps nécessaire est d’environ 1 heure (4070 ti super 16GB, Gemma 3:12b).
  • C’est presque comme produire un article de revue complet. En revanche, il y a un problème : le nombre de références chute fortement. Même si l’on admet que le contenu est correct, il devient difficile de l’étayer, donc quelques améliorations sont nécessaires. (Il semble vraisemblablement y avoir une phase de révision itérative pour améliorer la qualité du texte, et les liens de refs paraissent se perdre au cours de ce processus.)
  • Cela dit, le contenu fourni est clairement de meilleure qualité que dans Quick summary.

Divers réglages sont possibles dans le fichier de config. On peut limiter la base de données de recherche à PubMed uniquement, ce qui permet d’améliorer encore la qualité des sources. Il est aussi possible de définir la quantité de texte recherchée à la fois, ainsi que le nombre de chunks à créer lors de l’utilisation du RAG.

Étant donné qu’il s’agit actuellement de la version 0.01V, il est très impressionnant de voir qu’une machine locale peut produire des rapports de ce niveau. En particulier dans les sciences de la vie, les chatbots utilisent souvent des descriptions généralisées, alors que les rapports générés par ce programme emploient une formulation très scientifique.

Le programme ne prend actuellement pas en charge le coréen. Même si la question est posée en coréen, le rapport est généré en anglais.
De plus, lors de l’export en PDF, le coréen ne s’affiche pas lorsqu’on reçoit la réponse sous forme de fichier PDF.

Si les problèmes de disparition des refs pendant la génération du rapport et d’hallucinations sont résolus, je pense que ce sera un outil vraiment puissant.

 

J’ai fini par me lasser de la multitude de plugins d’Obsidian,

alors je suis passé à Reflect et j’en suis très satisfait.

 
kuthia 2025-03-13 | commentaire parent | dans: TypeScript 10 fois plus rapide (devblogs.microsoft.com)

À un moment, j’avais commencé à moins m’intéresser à TS, mais en voyant ce genre de nouvelle, ça me retente bien, non ?

 

C’est pour ça que je réserve carrément mes vendredis après-midi au temps de développement personnel !

 

Je suis totalement d’accord avec ce commentaire. Il y avait a un risque de micromanagement sur les aspects techniques. Ce n’est vraiment pas facile.

 

Abandonner la prise en charge des expressions régulières pour n’être que deux fois plus rapide que ripgrep, ça réduit quand même pas mal son intérêt.
Moi, je pense que je vais simplement continuer à utiliser ripgrep, qui gère les expressions régulières.

 
zihado 2025-03-13 | commentaire parent | dans: GoatDB - NoDB léger pour Deno et React (github.com/goatplatform)

GOAT... impressionnant

 

L’essor de la Chine est impressionnant.

 
killdong 2025-03-13 | commentaire parent | dans: TypeScript 10 fois plus rapide (devblogs.microsoft.com)

Personnellement, il m’arrive avec ts que les types deviennent tellement complexes que… j’en viens presque à abandonner (j’écris juste en any), mais c’est sans doute parce que je ne comprends pas encore assez bien le langage, non ? Selon les situations, je perds vraiment beaucoup de temps juste à essayer de faire disparaître les soulignements rouges.

 

Nous essayons de garder 80 % de charge de travail et 20 % de marge, mais je me demande à chaque fois selon quels critères le faire... Je me demande aussi s’il faut simplement se baser sur le temps.

 

Quand j’ai vécu brièvement à Shanghai pendant environ un an, il m’est arrivé d’aller faire un tour à Hangzhou (à l’époque, c’était pour voir une sorte de spectacle impressionniste), et j’avais trouvé que la ville était propre, que le paysage du lac de l’Ouest était magnifique, et que ce serait vraiment un endroit agréable où vivre. On dirait qu’aujourd’hui, c’est aussi devenu un bon endroit pour entreprendre.