Depuis quelques semaines, je suis amené à utiliser Locust. Il s’agit d’un outil destiné à effectuer des tests de monter en charge, stress tests ou des tests de performance.

Comme beaucoup de solutions open source, Locust repose sur l’usage d’une interface en ligne de commandes, de scripts et fichiers de configuration. Bien entendu, avant de pouvoir jouer avec tout cela il faut préparer son environnement de travail (installer Python, Locust, …).

La courbe d’apprentissage relative à cet outil est plutôt rapide, mais il y a là de nombreuses tâches rébarbatives et d’autres que l’on ne fait qu’une foi, mais qu’il faudra savoir communiquer à ses collègues pour qu’ils arrivent à les reproduire.

Comme pour C#, Microsoft a annoncé une nouvelle version de Visual Basic pour .net 5. Il s’agit de VB 16. Mais quelles sont les nouveautés ?

Malheureusement, il n’y en a pas. VB 16 n’apporte rien de nouveau à Visual Basic. VB 16 a été créé combler le manque de support de Visual Basic dans .net Core 3.1.

Microsoft n’a pas présenté de roadmap pour VB. Une légère allusion au futur de VB a été ajoutée à la documentation. Les informations fournies ne sont pas rassurantes :

• De nombreuses fonctionnalités du runtime VB dépendent de WinForm.
• Celles-ci feront leur apparition lors d’une prochaine itération de VB .net.

Si l’on fait très attention à la manière dont ces informations sont rédigées :

• On ne parle ici que de fonctionnalités manquantes et non de nouveautés.
• On ne sait pas quelles portions de runtime VB n’ont pas déjà été reprises pour .net 5.
• La dépendance à WinForm laisse penser que l’intégralité de WinForm n’est pas portée vers .net 5 (surprenant ?!).
• Il n’est pas dit que la prochaine monture de VB sera concernée par ces ajouts.

Malgré l’ajout du support de .net 5, je ne suis pas très optimiste. Il semble que cette version de VB soit là uniquement pour permettre aux développeurs .net Framework de migrer vers .net 5.

Quelques références sur le sujet :

• Visual Basic updates
• What's new for Visual Basic
• Visual Basic 16
• Les articles du blog dotnet dédié à VB.

À chaque version de .net, le mot « natif » est remis en avant. Ceci avec plus ou moins de succès. Cette semaine, j’ai parcouru la documentation .net. Il y a de quoi hérisser le poil des développeurs C et C++. Oui, il y en a encore et on en a besoin (petite question idiote : il est fait en quoi notre runtime ?).

Moi-même ancien développeur C++, je tente d’éviter les abus de langage (sans pourtant y arriver).

Oui, dans l’ancien temps nous commencions presque tous par une première expérience C++ ou VB. Pas de chance, dirons certains, j’ai fait les deux et .net Framework 1.0.

Aujourd’hui, pour faire simple :

• Oui, .net 5 offre des performances proches du natif à nos applications.
• Non, nos applications .net 5, ce n’est pas du natif.
• Une application .net 5 reste une application écrite en code managé avec toute la magie offerte par le runtime : sa gestion de la mémoire, de la sécurité, la protection des types, … etc…

Le JIT, l’AOT, c’est magique. Mais quand l’on ne déploie pas le runtime .net5, on l’embarque d’une manière ou d’une autre (les single file applications ne sont pas non plus le Saint Graal d’un .net natif).

J'ai eu la chance de pouvoir écrire un article pour le numéro spécial de programmez de cet automne. Au menu : Dev Windows, .net 5 et de nombreux conseils pour ne pas rater son projet.

Il y aura bien d'autres bonnes choses dans ce numéro que je vous recommande vivement.

Merci à François Tonic et Programmez!

Coder encore et encore des méthodes pour échanger des settings entre l’application Fitbit et les applications Fitbit OS, n’est pas trivial. Avoir à les corriger et reporter la modification sur toutes ses applications l’est encore moins. Plus vous publierez d’application et plus ce type de tâches sera chronophage.

Afin de faciliter la vie des développeurs, j’ai extrait le code que j’utilise couramment pour mes propres applications et en ai fait un module installable via NPM.