> Si le code TypeScript n’est plus écrit en TypeScript, l’équipe cessera de l’utiliser directement, ce qui pourrait affecter à long terme l’expérience de développement.
On parle de dogfooding, le fait d’utiliser soi-même ce qu’on a créé. Mais dans le cas d’un langage, ça me fait un peu réfléchir.
Cela dit, quand on veut adopter les technologies les plus récentes (?), il arrive assez souvent que JUnit4 soit un frein, donc personnellement j’ai le petit espoir qu’on migre vers JUnit5. https://docs.gradle.com/develocity/test-distribution/
On peut faire fonctionner des tests JUnit4 sur JUnit5 sans gros changements en utilisant junit-vintage-engine, mais le surcoût est assez important. (environ 20 % plus lent)
En tant que personne qui s’est retrouvée un peu par hasard à se fixer comme ingénieur build d’applications Android, si je devais donner mon avis...
Build : gradle
Même si c’est extrêmement gros ou complexe, il faut utiliser gradle... (regard au loin)
Les projets ci-dessous sont en cours pour améliorer les performances de build de gradle sur des projets très volumineux ou complexes ; si vous utilisez gradle sur un gros projet, mieux vaut préparer la migration à l’avance.
Personnellement, je ne pense pas qu’il soit nécessaire d’exposer les couches d’architecture au système de build.
Dans le cas de l’application que je gère, nous exposons au système de build les modules feature-api / feature-impl.
feature-app :
modèle de données, ou interface liée à d’autres modules
feature-impl:
implémentation réelle de la feature
Avec cette organisation, les changements de code dans feature-impl n’impactent pas les autres modules qui référencent feature-api (isolation des dépendances), ce qui aide beaucoup à améliorer les builds incrémentaux et le taux de hit du build cache.
Tests unitaires - junit 4
Je pense que la décision de Google y est pour beaucoup.
On dirait que les services qui limitent le nombre d’utilisations ou le temps reviennent à la mode en ce moment, mais j’ai l’impression que ça risque de faire un feu de paille comme cette appli à la mode il y a quelque temps — dont je ne me souviens plus exactement du nom — où on parlait un peu comme dans une émission.
Une charge CPU à 100 % n’est pas normale pour un ordinateur,
mais pour la charge de travail des humains, on en conclut qu’il faut travailler encore plus dur...
Hum... soit dit en passant, ces dernières années, on observe un phénomène assez étrange : la plupart des startups choisissent Flutter, tandis que les grandes entreprises comme META et OpenAI s’orientent vers le natif...
C’est une bonne nouvelle ! De façon assez surprenante, le langage TypeScript de MS semble faire, contrairement aux attentes, beaucoup de choix vraiment inattendus. Du point de vue de MS, c’est presque son premier projet open source, et contrairement à Dart de Google, qui cherchait à remplacer JS, le choix d’avoir voulu compléter JS paraît très judicieux ; et pour ce portage natif aussi, alors qu’ils ont sans doute beaucoup de langages maison, il est étonnant qu’ils aient choisi le Go de Google.
J’ai déjà eu recours à des solutions de repli parce que l’utilisation de types génériques définis de façon récursive ralentissait tout. Si c’est 10 fois plus rapide, j’espère que ce genre de point pourra aussi être amélioré.
Vous semblez parler de runtimes comme Node, mais ici il s’agit du compilateur du langage TS lui-même.
> Si le code TypeScript n’est plus écrit en TypeScript, l’équipe cessera de l’utiliser directement, ce qui pourrait affecter à long terme l’expérience de développement.
On parle de dogfooding, le fait d’utiliser soi-même ce qu’on a créé. Mais dans le cas d’un langage, ça me fait un peu réfléchir.
Cela dit, quand on veut adopter les technologies les plus récentes (?), il arrive assez souvent que JUnit4 soit un frein, donc personnellement j’ai le petit espoir qu’on migre vers JUnit5.
https://docs.gradle.com/develocity/test-distribution/
On peut faire fonctionner des tests JUnit4 sur JUnit5 sans gros changements en utilisant
junit-vintage-engine, mais le surcoût est assez important. (environ 20 % plus lent)En tant que personne qui s’est retrouvée un peu par hasard à se fixer comme ingénieur build d’applications Android, si je devais donner mon avis...
Même si c’est extrêmement gros ou complexe, il faut utiliser gradle... (regard au loin)
Les projets ci-dessous sont en cours pour améliorer les performances de build de gradle sur des projets très volumineux ou complexes ; si vous utilisez gradle sur un gros projet, mieux vaut préparer la migration à l’avance.
Personnellement, je ne pense pas qu’il soit nécessaire d’exposer les couches d’architecture au système de build.
Dans le cas de l’application que je gère, nous exposons au système de build les modules
feature-api/feature-impl.Avec cette organisation, les changements de code dans
feature-impln’impactent pas les autres modules qui référencentfeature-api(isolation des dépendances), ce qui aide beaucoup à améliorer les builds incrémentaux et le taux de hit du build cache.Je pense que la décision de Google y est pour beaucoup.
Cela dit, le plugin de screenshot testing sorti récemment est basé sur JUnit5.
On dirait Clubhouse ; c’est exactement ce qui m’est venu à l’esprit aussi.
On dirait que les services qui limitent le nombre d’utilisations ou le temps reviennent à la mode en ce moment, mais j’ai l’impression que ça risque de faire un feu de paille comme cette appli à la mode il y a quelque temps — dont je ne me souviens plus exactement du nom — où on parlait un peu comme dans une émission.
Quelle gloire pour la famille Huh !
Le trafic risque d’être massivement concentré uniquement sur cette plage horaire, il faudra donc un traitement efficace.
J’ai peur qu’à terme, la maintenance de la base de code TypeScript existante ne soit négligée.
Le développement du langage C# ne s’est pas arrêté, mais j’ai trop souvent l’impression que les frameworks utilisant C# sont laissés à l’abandon.
Je suis en train de le tester, et j’ai l’impression d’avoir affaire à une sorte de coffret cadeau tout-en-un.
On voit souvent passer des articles de ce genre, mais la cupidité humaine n’a pas de fin et on répète toujours les mêmes erreurs
Une charge CPU à 100 % n’est pas normale pour un ordinateur,
mais pour la charge de travail des humains, on en conclut qu’il faut travailler encore plus dur...
Hum... soit dit en passant, ces dernières années, on observe un phénomène assez étrange : la plupart des startups choisissent Flutter, tandis que les grandes entreprises comme META et OpenAI s’orientent vers le natif...
Je comprends cela dit aussi ce que peuvent ressentir les développeurs .NET...
C’est une bonne nouvelle ! De façon assez surprenante, le langage TypeScript de MS semble faire, contrairement aux attentes, beaucoup de choix vraiment inattendus. Du point de vue de MS, c’est presque son premier projet open source, et contrairement à Dart de Google, qui cherchait à remplacer JS, le choix d’avoir voulu compléter JS paraît très judicieux ; et pour ce portage natif aussi, alors qu’ils ont sans doute beaucoup de langages maison, il est étonnant qu’ils aient choisi le Go de Google.
Les développeurs .NET et Rust sont visiblement très en colère.
Brother, mise à jour forcée du firmware empêchant l’utilisation de cartouches d’encre tierces pour imprimantes
Tiens, il me semblait qu’ils avaient déjà créé un toolchain basé sur Rust du côté de Deno... pourquoi passer soudainement à Go ?
J’ai déjà eu recours à des solutions de repli parce que l’utilisation de types génériques définis de façon récursive ralentissait tout. Si c’est 10 fois plus rapide, j’espère que ce genre de point pourra aussi être amélioré.
Le fil de discussion sur la question de savoir pourquoi Go est assez intéressant.
https://github.com/microsoft/typescript-go/discussions/411
Il y a aussi beaucoup de points à examiner...