Tout à fait d’accord
À titre d’exemple parlant, React lui-même est en quelque sorte le Spring du front-end
C’est lourd et complexe, et même si on a l’impression que cela facilite le travail, en réalité on met en place un processus plus compliqué pour accomplir des tâches simples, puis on se retrouve avec cette étrange forme de confort qui consiste simplement à rendre ce processus inutilement complexe plus pratique

 

Tout à fait exact.
L’objectif des applications est clairement, avant tout, d’obtenir des autorisations au profit des entreprises.

 

Mais au final, pour les développeurs, il arrive aussi qu’ils doivent se connecter directement au serveur et accéder à la base de données pour des tests d’intégration avec l’application...

 

« Le “cloud” désigne des applications web fonctionnant sur des serveurs dans d’énormes datacenters » -> je ne suis pas d’accord.

Il faut distinguer les services web cloud du SaaS, du PaaS et de l’IaaS. Les premiers ont un objectif clairement orienté vers un usage partagé (Google, Naver, etc.), donc on utilise le cloud commercial actuel,
alors que pour les seconds, l’auto-hébergement est plus avantageux du point de vue de la gestion des coûts (TCO).
Un home server domestique est aussi intéressant, car il n’impose pas de payer des coûts réseau commerciaux.

 

« Le 28 juin 2004, Newsis rapportait dans un article intitulé “La semaine de 5 jours peut au contraire nuire à la santé” les résultats de recherches menées par des professeurs de neurologie et de psychiatrie de la faculté de médecine de l’université Sungkyunkwan. Selon eux, si le nombre de jours de travail diminue, une tendance peut apparaître consistant à moins dormir en semaine puis à tenter de compenser le week-end, ce qui entraîne une accumulation du manque de sommeil au quotidien et peut provoquer un syndrome de privation chronique de sommeil. »

https://www.mediatoday.co.kr/news/articleView.html?idxno=211584

Cela peut sembler évident, mais certaines personnes ne le perçoivent pas forcément ainsi. C’est pourquoi il faut des recherches et des débats sur le sujet.

 

Merci pour ce bon article. Justement, j’en étais aujourd’hui à ma 27e refactorisation.
J’ai commencé en C++, puis en JavaScript, et maintenant me revoilà en Rust...

 

Il y avait une faute de frappe dans l’article. C’est dommage qu’il semble impossible de la corriger. Merci.

 

Pyion Corporation, pour laquelle les deux mentions « retenue » et « non retenue » apparaissent, n’a pas été sélectionnée. Le nombre de sélections est indiqué à 11.

 

En pratique, c’est quasiment la même chose que RHEL.

 

Ils vont choisir une seule de ces organisations et concentrer le budget sur elle, j’imagine…

 

Il faudra gérer les clés pour chaque fournisseur de LLM.

 
nicewook 2025-07-26 | commentaire parent | dans: Voir comme un LLM (strangeloopcanon.com)

Lecture très instructive.

 

Pour la génération de code, sans doute, mais qui va faire la vérification ou la revue du code…

 

Vu le pseudo, on dirait que vous êtes venu faire votre propre promo ; à ce compte-là, il vaudrait peut-être mieux poster dans Show.

 

J’ai désormais une nouvelle connaissance à exhiber d’un air savant.

Merci...

 

J’ai déjà essayé de développer simultanément sur 3 ou 4 projets avec le forfait à 200 $ ; opus se vide vite, mais ça tient au moins 3 heures. Ça doit sans doute se réinitialiser toutes les 5 heures, et dans cet intervalle ça a tenu 3 à 4 heures.

 

Le mot robust était déjà souvent utilisé auparavant, je pense.

 

J’ai l’impression qu’on peut désormais progresser bien plus vite qu’avant sur des technologies qu’on n’avait jamais utilisées ou dans des domaines qu’on n’avait jamais explorés.