Les side projects me donnent la liberté de tout décider moi-même. Et ce n’est pas grave s’ils ne réussissent pas.
Moi aussi, j’aime beaucoup mes propres side projects, que je fais en regroupant le temps que je passerais sinon sur les jeux vidéo ou sur Netflix/YouTube. haha
Moi aussi, je suis en train de m’épuiser à force de travailler, mais l’idée d’un side project continue de me trotter dans la tête. Regarder YouTube ne m’amuse plus non plus... Étudier ne m’amuse plus non plus, et une fois que j’aurai changé de ноутбук, je compte essayer de lancer un side project avec Flutter. :)
Je pense que, lorsqu’on ne sait pas dans quelles contraintes un développeur utilisera React, la documentation officielle devrait être rédigée dans un environnement aussi proche que possible du vanilla.
React peut tout à fait être utilisé avec des frameworks web développés dans divers langages (par ex. Go, Rust, Java, etc.), sans forcément passer par un framework basé sur React.
-> En réalité, c’est précisément pour cette raison qu’il me semble que, au moins pour la section « Get Started » de la documentation officielle de React, il serait préférable de guider les utilisateurs vers une utilisation de React avec le moins de dépendances possible, en se limitant à React lui-même.
Cela semble adapté à l’APPLE SILICON disposant d’une marge de RAM, ou aux systèmes de type NPU. Pour l’utiliser sur un serveur GPU pur, le fait que le modèle aux spécifications minimales nécessite une quantification int4 sur H100 est un peu…
React n’est rien de plus qu’une bibliothèque d’interface utilisateur basée sur des composants. Il est simple d’afficher des composants dans du HTML, mais il faut de nombreuses fonctionnalités pour créer un site web ou une application. C’est pourquoi nous recommandons un framework. Ce n’est pas propre à React : une grande partie du web moderne est construite à l’aide de frameworks web. De plus, React peut être utilisé non seulement avec des frameworks basés sur React, mais aussi avec des frameworks web écrits dans divers langages (par ex. Go, Rust, Java, etc.) ; au final, le choix revient toujours à l’utilisateur.
Est-ce que ce sera finalement plus rapide que les wrappers CUDA existants comme CuPy ou PyTorch ? L’avantage de CuPy et de torch, c’est que leur API est presque identique à celle de NumPy, ce qui permettait de porter sans trop d’effort du code de test écrit avec NumPy ; il faudra voir à l’usage ce qu’il en est pour celui-ci.
Ce qui est vraiment frustrant, c’est que
Avant : réflexion => code (lent) => débogage
IA : réflexion => rédaction d’un prompt précis => code (instantané) => débogage
Mais en général, aller plus vite en écrivant directement du code qu’en transformant ma pensée en prompt, non ? Sauf quand il s’agit de faire quelque chose de déjà très bien connu... Et quand la fiabilité est importante, de toute façon il faut relire la logique à l’œil après coup, donc on ne peut pas vraiment déléguer, et à partir du moment où on délègue, on perd aussi une forme de conscience professionnelle.
Swift, c’est bien, mais est-ce que Swift, laissé à l’abandon, pourra renaître ?..
Les side projects me donnent la liberté de tout décider moi-même. Et ce n’est pas grave s’ils ne réussissent pas.
Moi aussi, j’aime beaucoup mes propres side projects, que je fais en regroupant le temps que je passerais sinon sur les jeux vidéo ou sur Netflix/YouTube. haha
Merci pour ce bel article.
Moi aussi, je suis en train de m’épuiser à force de travailler, mais l’idée d’un side project continue de me trotter dans la tête. Regarder YouTube ne m’amuse plus non plus... Étudier ne m’amuse plus non plus, et une fois que j’aurai changé de ноутбук, je compte essayer de lancer un side project avec Flutter. :)
Je pense que, lorsqu’on ne sait pas dans quelles contraintes un développeur utilisera React, la documentation officielle devrait être rédigée dans un environnement aussi proche que possible du vanilla.
React peut tout à fait être utilisé avec des frameworks web développés dans divers langages (par ex. Go, Rust, Java, etc.), sans forcément passer par un framework basé sur React.
-> En réalité, c’est précisément pour cette raison qu’il me semble que, au moins pour la section « Get Started » de la documentation officielle de React, il serait préférable de guider les utilisateurs vers une utilisation de React avec le moins de dépendances possible, en se limitant à React lui-même.
Cela semble adapté à l’APPLE SILICON disposant d’une marge de RAM, ou aux systèmes de type NPU. Pour l’utiliser sur un serveur GPU pur, le fait que le modèle aux spécifications minimales nécessite une quantification int4 sur H100 est un peu…
En pratique, la configuration minimale avec quantification incluse, c’est l’A100, mais les performances restent ambiguës, donc bon… snif snif
React n’est rien de plus qu’une bibliothèque d’interface utilisateur basée sur des composants. Il est simple d’afficher des composants dans du HTML, mais il faut de nombreuses fonctionnalités pour créer un site web ou une application. C’est pourquoi nous recommandons un framework. Ce n’est pas propre à React : une grande partie du web moderne est construite à l’aide de frameworks web. De plus, React peut être utilisé non seulement avec des frameworks basés sur React, mais aussi avec des frameworks web écrits dans divers langages (par ex. Go, Rust, Java, etc.) ; au final, le choix revient toujours à l’utilisateur.
Aujourd'hui, Llama 4 est sorti. https://fr.news.hada.io/topic?id=20166
Je vais essayer de l’installer et de l’utiliser.
Hahahahahahahaha
Haha, tout à fait d’accord.
Y a-t-il quelque chose de meilleur que Google Gemma 3 ?
Est-ce que ce sera finalement plus rapide que les wrappers CUDA existants comme CuPy ou PyTorch ? L’avantage de CuPy et de torch, c’est que leur API est presque identique à celle de NumPy, ce qui permettait de porter sans trop d’effort du code de test écrit avec NumPy ; il faudra voir à l’usage ce qu’il en est pour celui-ci.
Je n’y avais jamais pensé une seule seconde… mais ce genre de chose arrive aussi. Une vraie histoire d’horreur.
Très bien ! ^0^
Ce qui est vraiment frustrant, c’est que
Avant : réflexion => code (lent) => débogage
IA : réflexion => rédaction d’un prompt précis => code (instantané) => débogage
Mais en général, aller plus vite en écrivant directement du code qu’en transformant ma pensée en prompt, non ? Sauf quand il s’agit de faire quelque chose de déjà très bien connu... Et quand la fiabilité est importante, de toute façon il faut relire la logique à l’œil après coup, donc on ne peut pas vraiment déléguer, et à partir du moment où on délègue, on perd aussi une forme de conscience professionnelle.
La première vitesse, c’est réel ? C’est beaucoup trop lent...