Tendances des développeurs du radar technologique de Thoughtworks 27

Le radar technologique de Thoughtworks est un moment régulier pour jeter un coup d'œil à ce que les experts expérimentés de l'industrie pensent être la prochaine vague d'outils, de pratiques et de technologies à envisager ou à cesser d'utiliser.

J'ai toujours hâte d'ajouter de nombreux nouveaux "blips" à ma liste, ou de voir ceux qui sont de plus en plus adoptés depuis votre dernier coup d'œil.

La version 27 est maintenant sortie, et elle poursuit certaines tendances que le radar suit depuis un moment, comme la « plateforme en tant que service » ou les formes de programmation de groupe. Ce tour d'horizon est loin d'être exhaustif, mais juste les blips qui m'ont plu ou qui, je pensais, pourraient vous plaire.

Si l'un d'entre eux vous intéresse, ou si vous avez une opinion sur tout ce que j'ai présenté, rendez-vous sur votre profil et faites-le savoir à nos lecteurs !

Intégration de l'apprentissage automatique

On a vraiment l'impression qu'au cours des 6 derniers mois environ, l'apprentissage automatique est passé de quelque chose avec lequel seuls les développeurs et les scientifiques des données ont interagi à quelque chose dont le public était conscient.

Il y a eu annonce après annonce d'un autre outil basé sur ML ou AI qui a craché une sorte de média après que vous y ayez introduit quelque chose, et nous avons été submergés de milliers d'images et de vidéos étranges de célébrités.

Cela signifie également que les développeurs intéressés par l'expérimentation du ML ont également beaucoup plus de ressources à leur disposition sous la forme d'ensembles de données et de cadres pour utiliser ces ensembles de données.

TinyML , un domaine d'apprentissage automatique permettant une variété de cas d'utilisation toujours actifs et ciblant les appareils fonctionnant sur batterie, est pertinent pour les développeurs expérimentateurs.

Un autre est les magasins de fonctionnalités , une méthode de création de pipelines ML qui pourrait être plus familière aux développeurs d'autres horizons.

Ce radar couvrait également les outils liés au ML pour améliorer l'expérience des développeurs dans la construction et la formation de modèles, par exemple, la pratique de «l'apprentissage automatique fédéré» pour agréger les données du modèle sur les machines pour le traitement ou les données synthétiques pour les tests initiaux du modèle.

Observabilité continue

Bien qu'il s'agisse d'un terme relativement nouveau, «l'observabilité» s'est rapidement développée à partir d'un ensemble lâche de pratiques et de normes pour construire une meilleure image d'un système en cours d'exécution pour devenir un terme plus large pour signifier, eh bien, pour signifier toutes sortes de choses.

Le dernier domaine du flux de travail des développeurs à recevoir des informations est celui qui, je suis surpris, a pris si longtemps, l'observabilité pour l'intégration continue et les pipelines de livraison.

Bien que CI et CD apportent certainement des avantages, les processus tournent souvent mal avec très peu d'informations sur quoi jusqu'à ce que vous essayiez, réessayez.

Maintenant, une poignée de fournisseurs d'observabilité existants et de projets open source apportent des visualisations de style traçage des processus continus pour vous aider, espérons-le, à déboguer tout ce qui se passait.

Nomenclature du logiciel

Alors que les développeurs s'appuient de plus en plus sur des conteneurs et des packages semi-anonymes pour leur travail, ceux qui se concentrent sur la sécurité et la légalité ont regardé et se sont demandé : « Avons-nous confiance en cela ? ».

Cette préoccupation a conduit à une ruée vers la normalisation et la normalisation (en entreprise, en particulier) d'une « nomenclature logicielle », souvent désignée par l'acronyme comique, SBOM.

Alors qu'en théorie, "n'importe qui" peut creuser dans un projet open-source et voir quels sont ses composants, c'est généralement plus facile à dire qu'à faire et n'est pas du tout possible avec des projets à source fermée.

De récentes vulnérabilités très médiatisées dans les logiciels ont révélé comment de petites dépendances peuvent entraîner des problèmes aussi importants. Bien que les SBOM puissent grandement aider, je me demande combien d'entreprises voudront révéler leur fonctionnement interne et être honnêtes à leur sujet.

Codage durable

C'est un sujet que j'ai été inspiré de couvrir moi-même après avoir parlé avec quelqu'un de Thoughtworks de leur outil d'empreinte carbone dans le cloud.

La tendance à lancer sans cesse de nouveaux frameworks, outils et frameworks cloud sur un problème a conduit beaucoup d'entre nous à oublier que toutes ces lignes de code s'exécutent en fait quelque part sur quelque chose.

Et cela entraîne des émissions de carbone. L'eau motivée par des raisons altruistes ou financières, et un ralentissement œcuménique conduit à des économies de coûts, c'est un sujet dont on parle et auquel on réfléchit davantage.

Étroitement liée au coût environnemental des projets et de leur infrastructure, et une option que j'ai vue utilisée par les équipes de production est l'infracost qui estime l'impact sur les coûts des modifications que vous apportez aux définitions de Terraform.

Responsabilités en tant que code

Toute entreprise SaaS définit des indicateurs de niveau de service (SLI) et des objectifs de niveau de service (SLO) auxquels ses clients peuvent s'attendre.

Cependant, la façon dont les entreprises les ont définis a souvent été un peu aléatoire et non standard, et avec tant d'autres choses définies dans les pipelines codifiés, pourquoi pas ce composant fondamental aussi ?

Plusieurs fournisseurs d'observabilité proposent désormais cette option et bien sûr, un groupe de personnes a lancé un standard, OpenSLO .

Un non au nœud

Je touche JavaScript et TypeScript et j'ai récemment remarqué une poignée d'alternatives d'exécution émergentes à Node. Je ne sais pas ce qui ne va pas avec Node, en plus d'être assez vieux maintenant, pour justifier des alternatives, mais je suppose que la concurrence est bonne 🤷‍♂️ ?

Bun est une alternative plus récente que j'ai essayée il y a quelques mois, et j'avoue que je n'étais pas vraiment sûr des avantages qu'il m'apportait, mais il utilise JavaScriptCore de WebKit au lieu du moteur V8 de Chrome.

Encore une fois, la variété n'est pas une mauvaise chose. Bun est écrit en Zig , ce dont je n'avais jamais entendu parler auparavant, et il prétend être un remplacement "drop-in" C/C++.

Ce qui mène bien à…

C+++

Si Zig, Rust et d'autres langages sont quelque chose à dire, de nombreuses personnes pensent que C++ a besoin d'un remplacement plus moderne. Google a jeté une autre option dans la liste des prétendants avec Carbon .

Le langage est encore au stade expérimental mais prétend être plus facile à comprendre et à intégrer. Google a tendance à lancer de nombreux projets expérimentaux, puis à les vider à nouveau, donc la suggestion de Thoughtworks est actuellement "attendre et voir".