Building ASP.NET Core docker image on Azure DevOps : no such file or directory

index-hero

When you try to build a docker image for a default ASP.NET Core project template on Azure DevOps for the first time, you should encounter the following error :

Step 6/26 : COPY [« TestClassicApp.Api1/TestClassicApp.Api1.csproj », « TestClassicApp.Api1/ »]

COPY failed: stat /var/lib/docker/tmp/docker-builder260812138/TestClassicApp.Api1/TestClassicApp.Api1.csproj: no such file or directory

##[error]COPY failed: stat /var/lib/docker/tmp/docker-builder260812138/TestClassicApp.Api1/TestClassicApp.Api1.csproj: no such file or directory

##[error]/usr/bin/docker failed with return code: 1

From Azure DevOps logs.

It will be the case if you have a hierarchy in your solution folder where your projects are placed in subfolders.

Problem

The problem comes from the fact that, by default, the docker build task run with the buildContext set to ** (equivalent to the Dockerfile directory). If your project is placed in a subfolder like the sample above, it won’t work.

If we look closer at the Dockerfile instruction, we’ll see that the COPY operation use the full path to the csproj : COPY [« TestClassicApp.Api1/TestClassicApp.Api1.csproj », « TestClassicApp.Api1/ »]. Since we are in the context of the Dockerfile location, there’s no subfolder TestClassicApp.Api1 as the Dockerfile is currently in this folder.

Solution

The simple fix is to specify a parameter to the Docker build task named buildContext :

task: Docker@2
displayName: Build and push an image to container registry
inputs:
  command: buildAndPush
  repository: $(imageRepository)
  dockerfile: $(dockerfilePath)
  containerRegistry: $(dockerRegistryServiceConnection)
  buildContext: .
  tags: |
    $(tag)
Hope this will help other people !

Exécution de code natif dans le navigateur. Tsunami en vue

Web Assembly, Blazor and Co.

Lors de cette édition 2019 de la conférence Build, l’exécution de code natif dans le navigateur a été un bon sujet de discussion. Plusieurs grosses sessions y ont été consacrées. J’ai participé à plusieurs d’entre elles et vous fait un petit retour sur ce que j’ai appris et ce que je pense. N’hésitez pas à me partager vos remarques et commentaires.

WebAssembly (Wasm) est une specification qui définit un format de représentation binaire de code exécutable optimisé et ouvert pour le web. Pour les développeurs .NET ou Java que nous sommes, c’est l’équivalent du IL ou du ByteCode. L’objectif visé est de permettre l’exécution de code natif sur le web.

Aujourd’hui les principaux navigateurs PC ou mobiles du marché implémentent déjà WebAssembly 1.0. Et si vous avez un doute sur les capacités de la technologie, jetez un oeil à la capture d’écran suivante dans laquelle un système d’exploitation Windows 2000 complet tourne à l’intérieur d’une page web. Bluffant!

20190508_084109 (2)
Windows 2000 Professionnel s’exécute à l’intérieur du page HTML!

Pourquoi Web Assembly pourrait être la prochaine révolution du Web?

Voici les principales raisons pour lesquelles WebAssembly a toutes ses chances de percer.

Il offre des performances qui dépassent de loin ce que peut faire Javascript. Il utilise des interfaces qui lui donnent accès aux ressources matérielles communes aux différents types d’appareils. Javascript est interprété et n’exploite pas le multithreading à l’intérieur du navigateur. WebAssembly a moins de limitations de ce côté.

Il offre les mêmes garanties d’isolation (sandboxing) que Javascript. Le code binaire se voit contraint aux mêmes limitations que les scripts (pas d’accès aux systèmes de fichiers, aux processus, à la mémoire etc.). Donc on fait du natif au moins aussi secure que Javascript.

L’exécution de code WebAssembly est disponible par défaut car il fait partie du navigateur. Nul besoin de télécharger des runtimes. C’est un bon avantage par rapport à certaines technologies comme Silverlight ou encore Flash. On se facilite grandement la vie pour le déploiement, la disponibilité et la gestion des versions.

Il garantit une portabilité du code à travers les plateformes. Le même fichier binaire s’exécute dans tous les navigateurs sans adaptation. Il faut savoir que Wasm n’est pas limité à s’exécuter dans des navigateurs. Il est déjà aujourd’hui utilisé dans d’autres contextes comme dans le Blockchain par exemple. C’est juste qu’aujourd’hui l’engouement a pas mal pris du côté de la communauté Web qui y voit de l’intérêt. À terme, Wasm devrait même devenir une cible de compilation dans votre IDE préféré au même titre que x86, x64 ou ARM!

Wasm est un standard du W3C. Le groupe de travail est composé entre autres de représentants des principaux navigateurs du marché. Nul doute que cela contribuer positivement à son adoption, à sa compatibilité et à sa pérennité.

Comment exploiter Web Assembly ?

Aujourd’hui des langages comme C/C++/RUST et Go possèdent déjà du tooling pour produire du binaire au format Wasm. Ce sont des langages qui sont des citoyens de premières classes pour Web Assembly.

WebAssemblyStudio
WebAssembly Studio vous permet de compiler et d’exécuter du code C dans votre navigateur.

Mais qu’en est-il du C# et du code .NET ?

C’est là que les équipes Xamarin et .NET Core entrent en jeux.

L’équipe Xamarin a produit une version du runtime Mono au format Wasm qui fonctionne dans le compilateur et qui est capable de transformer à la volée du code IL .NET vers WebAssembly. Pour ceux qui ne sont pas familier avec Mono, il s’agit d’une implémentation alternative du Framework .NET qui tourne sous Mac, Linux, iOS et Android. Elle est conforme .NET Standard 2.0. Mono est donc le socle technique qui permet l’exécution de code .NET à l’intérieur du navigateur.

20190508_085124 (2)

Du côté de l’équipe ASP.NET Core, on s’est penchés sur la faisabilité et l’opportunité de proposer un rendu client basé sur une réutilisation de certaines technologies disponibles. Elle a donc démarré un projet expérimental dont le nom de code est Blazor. Objectif: proposer les vues Razor de ASP.NET dans le navigateur. Sur les derniers mois, les livraisons à la communauté ont été très fréquentes pour partager les avancées réalisées et récolter du feedback. Après 9 itérations, l’intérêt et la faisabilité ont été prouvées. L’équipe ASP.NET vient d’officialiser sont support.

20190507_142801 (2)
Blazor offre deux modes de fonctionnement pour le rendu. Aujourd’hui, seul le rendu server-side est supporté. Le client-side nécessite encore quelques optimisations.

Je suis allé voir la session de Daniel Roth durant laquelle il a démontré une application web réalisée avec Blazor. C’est durant cette présentation que j’ai vraiment pu prendre la mesure de l’intérêt de cette technologie:

  • Tout d’abord Blazor et le support de .NET en général dans le navigateur permet de réutiliser du code qu’on a déjà éventuellement écrit comme des contrôles utilisateurs, des routines de validation, de la logique d’affaire.
  • On peut utiliser toutes les librairies disponibles sur Nuget.org qui sont compatibles .NET Standard 2.0. C’est un gros plus.
  • On peux valoriser nos connaissances du langage C# et de .NET pour faire du code client! Pas de nécessité de se développer une seconde expertise dans un langage Javascript.

Je trouve que ce dernier point est important pour les entreprises qui ont fortement investi dans la formation de leurs employés ces dernières années.

20190507_142715 (3)
L’application Blazzing Pizza exploite pleinement Blazor pour le rendu. Tapez le lien dans votre navigateur pour accéder au code et aux explications.

La plateforme Uno

La compagnie nventive, basée à Montréal, a développé une plateforme qui s’appelle Uno et qui elle aussi offre une option d’exécution dans le navigateur.

Uno propose d’utiliser la technologie XAML introduite par WPF pour concevoir l’interface de votre application quelque soit la plateforme sur laquelle elle doit fonctionner ultimement. Elle s’appuit sur un tooling de conversion qui va produire un rendu équivalent, mais en utilisant des fonctionnalités natives aux plateformes cibles. Ainsi, par exemple, le Button XAML deviendra un DIV dans votre navigateur.

Uno possède déjà une bonne maturité et une notoriété grandissante. nventive l’utilise depuis longtemps pour développer des applications mobiles pour de grandes entreprises partout dans le monde (UPS, Red Bull etc). C’est assez récemment que l’équipe a développé le support pour Web Assembly.

En conclusion

En revenant du Build, je suis pas mal convaincu que nous allons beaucoup entendre parler de Web Assembly dans les mois qui viennent. Le tooling autour de C# et de .NET va certainement évoluer rapidement et cela va valoir la peine de se pencher sur cette technologie qui a tellement à offrir.

Je retiens aussi que pour les entreprises qui veulent préserver leurs investissements dans le temps que c’est une technologie qui offre des perspectives uniques en terme de réutilisation de code et de réutilisation des connaissances des développeurs.

I believe

Build 2019 – Jour 2

Écrire un article résumant une journée complète de conférences qui n’aurait pas l’air de sauter du coq à l’âne n’est pas une tâche facile. Pourtant, je pense que l’information recueillie aujourd’hui est très pertinente. C’est pourquoi je vous propose des résumés des différentes présentations intéressantes auxquelles j’ai assisté aujourd’hui à la deuxième journée de la conférence Build 2019 de Microsoft.

Productivité avec Visual Studio 2019

20190507_153018 (2).jpg

Le but n’était pas de vous énumérer toutes les améliorations de VS 2019 comme une liste d’épicerie, je mentionnerai seulement celles qui m’apparaissent plus pertinentes. Pour la liste complète, vous pouvez consulter les notes de livraison.

Depuis la version 2017, Visual Studio améliore sans cesse ses performances. Il gère de mieux en mieux les solutions de grande taille et la nouvelle expérience de démarrage ainsi que les filtres de solutions sont dans cette lignée.

Les Code lens sont maintenant offertes dans la version Community et sont aussi extensibles. Il est maintenant possible de créer ses propres Code lens!!!

On peut aussi voir ou éditer les fichiers de projet avec un banal double-clique. Know it, learn it, love it!

Aperçu de certaines fonctions

Dans les versions Preview, certaines fonctions sont disponibles pour recueillir le feedback. L’ajout de l’auto-complétion dans les chaînes de caractères RegEx a notamment retenu mon attention.

Aussi, IntelliCode a été livré formellement, mais certaines nouvelles fonctionnalités sont déjà en route.

Pour rappel, IntelliCode permet d’utiliser le Machine Learning pour améliorer l’expérience des développeurs. Entre autres, les éléments d’intellisense les plus populaires, dans le contexte de notre curseur, apparaîssent en premier.

Il sera prochainement possible d’entraîner le modèle d’IntelliCode avec notre propre code pour qu’il soit en mesure de nous aider avec les classes que nous développons nous-mêmes. L’exécution se fait localement pour plus de confidentialité. Il sera également possible de partager le modèle ainsi généré avec nos collègues au besoin.

Toute les équipes finissent par avoir une convention de style pour le code. Le fichier .editorconfig permet aux utilisateurs de VS de personnaliser cette expérience. Toutefois, il peut être difficile de répertorier toutes ces conventions. IntelliCode viendra à la rescousse et permettra de générer un fichier .editorconfig basé sur les conventions informelles de notre base de code.

JAM Stack + Azure Functions

Cette présentation était constituée d’une série de démos pour montrer l’intégration des différents outils de la JAM Stack telle que vue par John Papa et Matt Hernandez. Cet acronyme sert à désigner un ensemble de technologies qui fonctionnent bien ensembles. On parle ici de Javascript, APIs et Markup.

20190507_083546

Les démos ont servi à montrer comment il était facile de développer une application Angular dans VS Code qui repose sur un back-end Azure Functions écrit en TypeScript dans le même répertoire que l’application Angular. En plus des capacités formidables d’édition web, VS Code est un excellent outil pour développer et déboguer les Azure Functions localement sur notre poste. La démo utilisait NodeJS pour l’exécution locale et les présentateurs ont montré comment démarrer l’Azure Function et l’application web dans le navigateur en même temps en appuyant sur F5. L’utlisation du fichier launch.json étant la clé.

Les présentateurs ont aussi utilisé les extensions VS Code pour déployer leur application dans Azure directement, ce qui procure une expérience très intuitive et une boucle de rétroaction rapide. Ils ont terminés en montrant comment Azure DevOps pouvait être utilisé simplement pour assembler des artéfacts de déploiement et ensuite les déployer vers les ressources Azure. Dans le pipeline de build, l’utilisation des tâches npm permet de réutiliser le même outillage que l’environnement local pour la partie Angular. Bref, l’intégration est très intéressante et semble assez mature.

Windows Subsystem for Linux v2 (WSL2)

Microsoft a annoncé la nouvelle version de son Windows Subsystem for Linux : WSL 2. Les deux principaux avantages sont la performance et la compatibilité avec les fonctionnalités natives des distributions Linux. Le tout repose sur l’utilisation de la virtualisation légère qu’ils appellent Lightweight utility VM qui est rendu possible avec les travaux qui ont été faits pour le support des conteneurs dans Windows. Une VM Linux est donc démarrée par la couche WSL 2 qui s’occupe d’abstraire les détails pour nous. C’est pourquoi Microsoft distribuera les versions du noyau Linux via les Windows Update. Qui aurait dit que cela se produirait un jour? Toutes les distribution de Linux seront exécutées dans une seule VM en utilisant les fonctionnalités natives qui soutiennent les technologies des conteneurs sous Linux. Il est donc possible d’accéder aux fichiers Windows à partir de WSL et aussi d’accéder aux fichiers de la VM Linux à partir de Windows comme si de rien n’était. Les avancées de WSL 2 permettent aussi l’utilisation de Docker dans WSL directement.

20190507_104059.jpg

À la fin de la présentation, un rappel a été fait sur le mode « remote » de VS Code. Ce dernier permet d’exécuter l’interface utilisateur sous windows, mais de déléguer l’ensemble de l’exécution au WSL. Pour en savoir plus

Développement de microservices avec AKS, GitHub et Azure Pipelines

Microsoft est sérieux pour ce qui est de l’intégration de Kubernetes dans ses différentes plateformes. En plus de l’expérience du portail Azure en constante amélioration, les outils de développement demeurent une priorité. Dans une présentation comportant plusieurs démos, nous avons vu à quel point il est facile d’itérer rapidement dans un contexte AKS avec Visual Studio. Le débogage d’un conteneur dans AKS est possible directement à partir de notre IDE favori. Une possibilité incroyable est aussi de pouvoir modifier notre application sans avoir à regénérer notre image de conteneur et à la publier dans AKS. L’exécution se fait localement et AKS route les appels vers notre machine de développement, ce qui accélère grandement le développement. Tout cela est rendu possible grâce à DevSpaces : des espaces de développement isolés dans un cluster partagé. Un développeur peut alors modifier un composant et le tester sans impact sur les autres personnes qui effectuent des essais dans le même environnement.

20190507_130315

Des outils de ligne de commande ont été ajoutés à la CLI Azure pour faciliter le démarrage. Par exemple,  pour configurer notre espace, les lignes de commande suivantes sont suffisantes :

az aks use-dev-spaces -g [resourceGroupName] -n [clusterName]

az azds prep

az azds up

Il est donc facile de démarrer rapidement avec AKS dans Azure.

Des ajouts intéressants ont été fait dans Azure DevOps qui permettent de voir nos environnements Kubernetes directement dans le portail Azure DevOps.

Screenshot_20190507-225111_Chrome (2).jpg

Toujours dans le but d’accélérer le démarrage avec AKS, Azure DevOps fournit maintenant un assistant de création de pipeline pour AKS. Ce dernier automatise la création des fichiers azure-pipelines.yaml et des manifestes requis par Kubernetes pour déployer notre application. Le tout est alors archivé dans notre dépôt de code pour être modifié comme du code par la suite.

Un scénario qui est vraiment intéressant avec tous ces ajouts est celui de pouvoir effectuer des tests manuels dans un espace DevSpaces AKS basé sur une Pull Request. En détectant qu’un pipeline de déploiement a été déclenché à partir d’une Pull Request, on peut concevoir notre pipeline de sorte qu’il crée un espace DevSpaces à la volée pour nos tests. Toutes ces étapes sont intégrées également dans GitHub.

Conclusion

En plus des nouveautés mentionnées plus haut, une foule d’autres sujets ont capté mon attention comme l’annonce de l’API Management d’Azure qui permettra de fédérer des gateways on-prem avec Azure à l’aide de conteneurs.

De plus, les discussions avec les équipes des différentes produits sont très intéressantes pour obtenir des réponses détaillées sur une foule de sujets.

Encore une autre belle journée en perspective demain. Au menu, Web Assembly et plus!

 

Build 2019 – Jour 1

20190506_104437

De retour avec un article portant sur la conférence Build de Microsoft encore cette année. Avec beaucoup de plaisir, j’ai la chance d’y assister en direct de Seattle avec plusieurs collègues.

La première journée a été marquée par plusieurs annonces importantes au niveau d’Azure et de .NET. Voici ce que j’ai retenu de cette première journée de conférence.

Azure Keynote

20190506_110228.jpg

Scott Guthrie a orchestré le keynote technique portant sur Azure et certains outils de développement. Portant son légendaire polo rouge, il a procédé à plusieurs annonces qui ne sont pas négligeables. Pour les gens qui suivent les nouveautés de manière assidue, rien n’est apparu comme révolutionnaire, mais je pense que c’est du à la cadence de livraison rapide à laquelle Microsoft nous a maintenant habitué. Voyons quand même les éléments dignes de mention.

Annonce de Visual Studio Online

Microsoft fournit maintenant un éditeur web en ligne pour Azure DevOps. Il agira en tant que companion aux éditeurs VS Code et Visual Studio. Des fonctionnalités comme Live Share et IntelliCode sont à prévoir éventuellement.

20190506_112245.jpg

Outillage Azure DevOps

Donovan Brown est revenu sur différents ajouts récents dans l’outillage entourant Azure DevOps comme l’outil Azure CLI qui inclut des extensions pour Azure DevOps. Aussi, l’annonce importante a été celle de pouvoir unifier les pipelines CI/CD dans un seul et même pipeline. Tout ça se fera en YAML. Avec l’ajout récent d’un soutien visuel pour la configuration des tâches, l’expérience devient très intéressante.
Suite à l’acquisition de GitHub, Microsoft continue d’améliorer l’intégration entre GitHub et Azure DevOps en fournissant maintenant des ensembles de licences pour MSDN et GitHub Enterprise ainsi que la possibilité d’utiliser Azure AD pour s’authentifier dans GitHub.

Nouveaux services Azure

Plusieurs services Azure ont été annoncés en aperçu ou en disponibilité générale, mais j’ai noté particulièrement les ajouts à AppService qui disposera d’une intégration VNet pour les applications basées sur Linux. Nos applications .NET Core pourront donc utiliser la même intégration VNet qui est actuellement en aperçu du côté Windows (v2).20190506_113521.jpg

Quelques nouveautés du côté AKS sont aussi digne de mention. Pour commencer, la disponibilité générale des kubelets virtuels. Aussi, il faut voir Kubernetes Event-Driven Auto-scaling (KEDA). Il s’agit de pouvoir gérer l’élasticité des clusters Kubernetes à l’aide des événements disponibles dans Azure et des Azure Functions. Par ailleurs, ces dernières pourront aussi être exécutées sous Kubernetes dans des conteneurs.

20190506_113728.jpg

Plusieurs services de bases de données ont été bonifiés pour offrir des capacités « hyperscale ». Pour les énormes besoins en terme de données ou de performance, les BD opérationnelles pourront utiliser des ressources de grande envergure (Disponible pour SQL Server, MySQL et PostgresSQL).

Power Platform

Microsoft met beaucoup de l’avant les technologies Microsoft 365 dans sa conférence comme les Power Apps, Microsoft Flow et Power BI. Le but de Power Apps est d’offir la possibilité aux organisations de fournir des solutions logicielles sans nécessairement avoir recours à des développeurs. Au minimum, leur tâche sera dramatiquement réduite. Une démo a d’ailleurs été faite démontrant la possibilité de créer une application mobile à partir d’un outil de conception web. Pour en savoir plus, consultez le site PowerApps.

20190506_123049.jpg

.NET Platform Roadmap

20190506_135216

Une session avec les « lower Scotts » avait lieu aujourd’hui au sujet des nouveautés dans le monde .NET. Il faut dire que la grosse nouvelle a été publiée un peu plus tôt dans la journée lorsque .NET 5 a été révélé. Il y aura une seule version de .NET à partir de 2020 pour développer sur toutes les plateformes (Windows, Linux et MacOS). Notons en particulier les possibilités d’interopérabilité avec Java et Swift et les options de compilation JIT et Ahead of Time (AOT). .NET 5 sera la suite de .NET Core. Les applications .NET Framework peuvent donc continuer leur migration vers .NET Core selon les besoins. À noter que la version .NET 4.8 demeurera supportée avec les différentes versions de Windows.

D’autres nouveautés ont aussi été relatées comme ML.NET 1.0 et son Model Builder. Ce dernier permet de créer et entraîner des modèles de machine learning localement sur notre machine. Un assistant facile d’utilisation est rendu disponible directement dans Visual Studio. Les outils .NET pour Apache Spark ont aussi été démontrés de manière complète avec des performances meilleures que Python.

20190506_142125.jpg

Pour ce qui est de .NET Core 3 qui supporte WinForms, WPF et UWP, Microsoft garde le cap et rappel les avantages de migrer nos applications vers .NET Core :

20190506_143501.jpg

Un bref rappel a aussi été fait pour les plus récentes nouveautés de ASP.NET Core 3 comme :

Windows Containers

Pour finir, une session a eu lieu sur l’état des conteneurs dans Windows. C’est définitivement Windows 2019 qui offre le meilleur support pour les conteneurs Windows, mais il m’est apparu assez clair que la maturité n’était pas au rendez-vous. Les tailles d’images demeurent volumineuses et la complexité d’utilisation est plus grande que du côté Linux. Actuellement, il n’est pas possible de récupérer les logs émis par le processus dans le conteneur de manière standard dans StdOut, ce qui limite plusieurs scénarios. À terme, on pourra y retrouver les journaux applicatifs des événements (EventLog) ainsi que certains logs IIS, ce qui est quand même pas mal du tout. Les avancées les plus intéressantes sont du côté de AKS qui permettra d’avoir des noeuds mixtes Windows et Linux.

Conclusion

C’est une première journée très chargée que nous avons eu et nous en attendons une autre semblable demain. Bien qu’il n’y aura pas de keynote à suivre, de multiples présentations très intéressantes tourneront autour d’Azure, .NET et Kubernetes. Stay tuned!

Build 2018 – Résumé Jour 1

IMG_3267[1]C’est avec grand plaisir que je participe à la conférence Build 2018 de Microsoft encore cette année. Ayant été très surpris par la teneur des présentations l’an dernier, les attentes étaient élevées pour la première journée. Voyons un peu ce qui a été marquant.

Keynote

Initiée par le grand patron de Microsoft, Satya Nadella, cette présentation comportait deux volets : partager la vision du géant mondial de l’informatique et présenter les nouveautés autour du cloud.

Microsoft veut assurément pénétrer de nouveaux marchés en attirant de nouveaux secteurs à consommer ses services d’infonuagique. La majorité des exemples démontrés dans la première partie du Keynote était orientés vers des périphériques pouvant bénéficier de l’intelligence artificielle ou des autres services Azure. On y a entendu les termes suivants : Intelligent Cloud et Intelligent Edge. Étant donné la charge de calcul importante requise par les algorithmes d’IA, Microsoft a présenté plusieurs façons d’exécuter du code provenant d’Azure au sein des appareils intelligents. Des drones et des caméras embarquant des technologies de reconnaissance visuelle ont retenu l’attention.

Plusieurs mises à jour sur les produits Azure ont été révélées, mais la démonstration la plus hallucinante a été celle d’une réunion à travers laquelle nous avons pu voir de la traduction simultanée, de la prise de note assurée par les applications, des intégrations entre les téléphones, les ordinateurs et des périphériques de réalité virtuelle. Je vous recommande d’y jeter un coup d’œil.

Une des annonces les plus inattendues durant cette présentation a été celle de l’intégration de Cortana et Alexa. Les deux assistants personnels que l’on croyait en compétition seront accessibles facilement sur les différentes plateformes. Il sera donc possible d’invoquer Alexa sur un PC Win10 et aussi d’utiliser Cortana sur un appareil Alexa.

Est ensuite apparu le mythique polo rouge. Scott Gu était présent pour faire plusieurs annonces au niveau d’Azure, mais a aussi laissé la place à Amanda Silver qui a fait une présentation plus qu’intéressante de Visual Studio Live Share. En bref, cette fonctionnalité disponible en preview dans VS 2017 permet de collaborer à 2 sur le même bout de code pour déboguer ou pour aider le développement. Ce qui est le plus étonnant, c’est que ça fonctionne pour tous les langages, sur Windows et sur Mac et avec Visual Studio et Visual Studio Code.

Scott Hanselman a aussi présenté AKS, le service géré Kubernetes dans Azure. L’élément intéressant a sans aucun doute été le Dev Space. Il permet au développeur de pouvoir tester dans un environnement kubernetes complet sans rien avoir sur son poste. Hit F5!

Scott Gu a aussi présenté plusieurs avancées dans IoT Hub, IoT Edge, Cognitive Services, Search API et Cosmos DB.

Visual Studio – présent et futur

IMG_3293[1]Pour cette présentation, mes attentes n’étaient pas élevées étant donné la maturité de l’IDE réputé. Bien que le malheur se soit abattu sur les démonstrations, j’ai été impressionné par la quantité de fonctionnalités impressionnantes qui ont été ajoutées à l’outil. Voici les points les plus marquants.

Visual Studio Live Share

IMG_3296[1]

Comme mentionné dans le Keynote, cette fonction permet de partager une session Visual Studio avec un collègue. Ce qui est intéressant de noté, c’est qu’il n’est pas nécessaire pour notre collègue d’avoir les sources et les binaires sur son poste pour participer. En effet, tout le code source est récupéré de l’ordinateur qui initie la session de partage. Durant ces sessions de partage, il est possible de voir le curseur de l’autre personne, de modifier le fichier de part et d’autre et aussi d’utiliser le débogueur. L’accès aux variables et aux outils de débogage standards est aussi supporté. Il est aussi possible de partager un serveur qui exécute le code qui est en édition. De cette façon, nul besoin de compiler le code sur la machine distante. Une session terminale peut aussi être initiée afin d’exécuter des commandes à distance comme l’exécution des tests.

Éléments de productivité

IMG_3294[1]

Plusieurs nouveautés présentes dans les mises à jour récentes de Visual Studio ont été présentées, mais ce qui a retenu mon attention est sans aucun doute IntelliCode. Cette fonctionnalité tire partie du Machine Learning pour analyser le code de plus de 2000 dépôts dans GitHub et proposer en premier les choix les plus propices dans l’IntelliSense. IntelliCode peut aussi générer un fichier EditorConfig en fonction des habitudes détectées dans le code. Il propose également à un réviseur de porter son attention sur différents aspects lors d’une pull request comme les variables mal utilisées (bugs potentiels) et les fichiers qui sont susceptibles de demander plus de corrections.

Un élément qui m’est apparu évident est aussi que l’écart se rétrécit entre ReSharper et Visual Studio. Plusieurs réusinages ont été ajoutés (TypeScript inclut) et plusieurs fonctionnalités pour naviguer plus facilement dans le code (Ctrl+T, Naviguer dans le code décompilé) font maintenant partie de l’outil de base.

Intégration des Pull Requests dans l’IDE

L’équipe Visual Studio ne s’est pas contentée d’intégrer la création et l’approbation des pull requests dans l’IDE. En plus, Visual Studio permet de réviser le code comme s’il faisait parti de notre solution. Ça donne le même effet que de déréserver du code avec TFVC. Toutefois, plutôt que de seulement voir la version finale, il est possible de voir les différences de différentes manières (inline, côte à côte, etc.). On y voit le résultat de l’exécution des tests (réussite et couverture) directement dans les fichiers modifiés. Il est aussi possible de déboguer le code contenu dans la pull request. Wow!

 

Mot de la fin

Voilà ce qui a retenu mon attention particulièrement pour cette première journée. En espérant que la deuxième journée sera tout aussi riche.

Faciliter le passage à l’architecture microservices

Microservices

Image : http://comunytek.com/en/introduction-to-microservices/

Quand on regarde les tendances de l’industrie actuelle, il est difficile de ne pas entendre parler d’infonuagique (cloud) et des microservices. Depuis quelques années, des leaders comme Netflix, LinkedIn, Twitter, Google, Amazon et Microsoft se sont imposés dans ces domaines et ont bien voulu partager leur savoir-faire en publiant des plateformes open-source et des articles. Bien que l’univers du cloud et des microservices requiert des changements dans la manière de gérer les technologies et les infrastructures, il faut aussi adapter l’architecture logicielle pour aborder ces nouveaux paradigmes correctement.

Dans le contexte d’une application existante, le passage au cloud et à l’architecture microservices doit se faire de manière itérative. Il n’est pas judicieux de tout changer en même temps, car il devient impossible de mesurer si l’investissement aura eu les bénéfices escomptés. Alors, par où commencer?

Selon Sam Newman, la bonne pratique est de commencer par modifier la structure du code petit à petit afin de tendre vers l’indépendance des déploiements. Qui dit indépendance des déploiement dit évidemment découplage. Alors on doit commencer à créer des plus petites unités de déploiement dans notre logiciel qui soient découplées les unes des autres. Ce genre de changement peut se faire sans contrainte d’infrastructure et sans impact sur la sécurité. Voyons donc en détail comment on peut se préparer à l’approche microservice dès aujourd’hui.

Définir les frontières d’un service

Le principal défi au niveau du design dans l’architecture microservice est de déterminer les frontières d’un service. On sait que le monolithe n’est pas une bonne idée. On sait aussi qu’il n’est peut-être pas optimal de créer un service par classe de logique d’affaire (aussi appelé classe du domaine). Alors on doit trouver le juste milieu. Mais comment? Il n’y a pas de réponse toute faite à ce sujet, mais l’élément qui revient le plus souvent dans la littérature est d’utiliser le concept du Bounded Context tiré du Domain Driven Design. Celui-ci serait trop long à décrire dans cet article, mais l’idée est de s’assurer que notre service est lié à une seule fonction d’affaire. Par exemple, dans un site de commerce en ligne, les fonctions de gestion des commandes et de gestion des livraisons ne devraient pas faire partie du même service. En effet, pour faire un lien avec le Single-Responsibility-Principle (SRP) des principes SOLID, un service ne devrait avoir qu’une seule raison de changer. Normalement, les fonctions d’affaires tendent à rester relativement stables dans une entreprise. C’est sans doute l’élément qui changera le moins souvent. C’est donc une bonne idée de créer des services qui sont alignés avec ces fonctions d’affaires afin de minimiser les changements de frontières qui pourraient survenir. Toutefois, la connaissance de notre domaine d’affaire peut évoluer et amener à faire des changements dans la topologie des services. Le découpage et le niveau de découplage du code peut rendre ces changements très pénibles ou très faciles. Il est donc important de s’y attarder.

Le problème avec le découpage en couche

Pendant plusieurs années, l’architecture n-tiers proposait de séparer les composants logiciels par couche applicative.

N-Tiers

Cette façon de faire permet d’ordonner et de structurer le code pour séparer les responsabilités. Toutefois, elle n’est pas orientée vers les tests automatisés, car elle rend difficile la substitution et elle n’encourage pas le SRP en n’étant pas alignée sur les fonctions d’affaires. Il est aussi difficile d’éviter de faire un gros spaghetti et de comprendre d’un coup d’œil quel est le but de l’application. Lorsqu’un développeur veut créer un service avec une ou plusieurs classes de logique d’affaires, il doit effectuer une analyse des dépendances entre les classes afin de mesurer l’impact du changement. Cette approche rend plus difficile l’évolution de l’architecture.

Cohésion forte, couplage faible

En SOA, c’est sans doute le principe qui fait le plus consensus. Un service doit rassembler des opérations à forte cohésion. Tous les éléments d’un même sujet devraient être traités dans le même service. De plus, chaque service devrait être faiblement couplé avec ses pairs. Ainsi, on tend à diminuer les vagues de changements. C’est ce principe que reprend Uncle Bob dans son livre Clean Architecture. Il applique ce principe non seulement au niveau des services, mais aussi au niveau des composants. Il énonce certains principes permettant d’évaluer la cohésion et le couplage afin de créer les bons regroupements dans le code.

En DDD, le principe de cohésion forte encourage à regrouper les éléments du domaine qui sont intimement liés en agrégats. Toutefois, le couplage entre ces derniers doit être évité. On doit également éviter le couplage avec les technologies. L’interface utilisateur ou le moteur de base de données utilisé doivent être traités comme des détails d’implémentation qui sont jetables. Ce qui va perdurer dans le temps, comme mentionné précédemment, c’est la logique d’affaire et non la version de notre SQL Server. L’emphase doit être mis sur l’isolation de notre logique d’affaire. Elle doit être pure.

Pour ce faire, différentes approches ont été documentées dans le passé. Hexagonal Architecture (Port and Adapter), Onion Architecture et Clean Architecture sont toutes des variantes, mais partent du même principe. On doit inverser les dépendances. Pour ma part, je trouve que l’appellation « architecture en oignon » est celle qui parle le plus. On veut ajouter des couches autour de notre domaine. On représente nos couches de la manière suivante :

OnionArch

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Le sens des dépendances doit toujours être vers le centre. Une fois qu’on a intégré ce paradigme dans notre code (merci aux IoC Containers), on obtient une architecture testable et plus modulaire. Toutefois, reste encore à trouver une manière de regrouper ces différentes couches en composants.

Découpage en composants adapté aux microservices

Si on résume, le but est d’isoler les classes de domaine afin qu’elles soient indépendantes des détails d’implémentation comme les bases de données et les composants UI. Le réflexe que j’ai eu dans le passé a été de créer un composant séparé pour chaque élément d’infrastructure (UI, Données, Cross-cutting concern). En .NET, c’est le seul mécanisme qui permet d’éviter à une classe du domaine de pouvoir instancier une classe d’accès aux données directement. Le fait de faire une référence vers le domaine dans le composant d’accès aux données empêche donc d’avoir une référence dans l’autre sens, et donc, le domaine ne peut avoir de dépendance directe inverse, ce qui créerait une référence circulaire. Toutefois, cette approche n’est pas parfaite : elle ne permet pas d’hurler l’architecture. On peut toujours s’en tirer avec une nomenclature de composant, mais ce n’est pas ce qui a de plus évident. Par ailleurs, s’en sont suivi deux phénomènes intéressants :

  1. Les composants UI ne sont pas obligés de passer par le domaine pour accéder aux données, ce qui nuit à la centralisation de la logique d’affaire
    1. En effet, nous avons vite vu apparaître des classes de la couche UI qui accédaient directement aux données.
  2. Lors d’une modification au domaine, on devait effectuer des changements dans plus d’un composant, ce qui montre que la cohésion n’était peut-être pas au maximum.

Pour moi, le dernier chapitre du livre Clean Architecture de Uncle Bob est sans doute le plus révélateur. Écrit par Simon Brown (auteur du framework C4), ce chapitre décrit une manière de regrouper les classes différemment. Il propose de regrouper dans un même composant les éléments suivants :

  1. Couche service (pas confondre avec le projet Web API ou WCF qui sont plus du UI d’une certaine façon)
  2. Accès aux données

Dans ce composant, la seule chose qui demeure publique est la porte d’entrée du composant. On obtient une architecture comme celle qui suit :

MSFinal

(En pâle, les types qui sont internes)

Brown propose de tirer profit du compilateur pour faire respecter l’architecture en rendant internal les éléments d’accès aux données et les classes du domaine. On obtient une architecture plus parlante. Juste en regardant les composants on comprends où se trouve la gestion des commandes. Aussi, le découplage demeure inchangé. Par ailleurs, il devient facile de déplacer un concept d’un service vers un autre. On vient ainsi se donner de la flexibilité quand vient le temps de revoir le découpage des services en approche microservices. Pas d’analyse d’impact très longue, tout est dans le composant. C’est une façon d’adapter notre architecture en prévision d’une migration vers les microservices.

Les plus malins auront toutefois noté qu’il devient plus facile d’instancier une classe d’infrastructure et donc de ne pas respecter le sens des dépendances. C’est en effet un compromis, mais puisque ce problème ne peut pas se propager à l’extérieur du composant, on peut découvrir les fautes et le redressement sera en général plus rapide. On y gagne toutefois une plus forte cohésion et on évite de disperser la logique d’affaire.

Comme ces composants sont très autonomes, il devient facile de déployer ces derniers de différentes façons. L’évolution d’un composant comme celui-là peut être confié à une équipe indépendante étant donné qu’il a très peu de dépendances externes.

Conclusion

Même si l’adoption de l’approche microservice comporte de nombreux enjeux, il est possible de commencer dès aujourd’hui à se préparer dans notre code patrimonial. Une fois l’indépendance du code obtenu, il faut s’attaquer aux bases de données, ce qui n’est pas une mince affaire non plus. Comme la route est longue, ça nous force à travailler là où les gains sont les plus nécessaires. L’architecture microservice n’est pas une destination, mais plutôt un outil qu’on doit utiliser pour atteindre des objectifs spécifiques.

Sonarqube – Plugin VB.NET Gratuit

sonarLogo

Sonarqube est un outil plus qu’intéressant pour gérer les métriques de code de manière centralisée. Il permet de voir du même coup d’œil les analyses statiques de code de plusieurs langages comme C#, JavaScript, Java et plusieurs autres. Le principal élément d’intérêt dans cet outil est de pouvoir évaluer et quantifier la dette technique d’une application.

Le problème?

L’organisation pour laquelle je travaille était très intéressée par l’outil (bon d’accord, disons que c’était moi plus que les autres…), mais un élément était bloquant pour vraiment évaluer l’outil : l’analyse du langage VB.NET coutait 6000 euros et est maintenant inclus dans un package pour entreprise qui requiert un abonnement. Bref, difficile de valider l’utilité de l’outil quand notre dette réside probablement dans le code patrimonial qui a été fait depuis plusieurs années, principalement en VB.NET.

 

Radin ou ingénieux?

Les motivations derrière la découverte que j’ai faite peuvent laisser place à interprétation mais, en analysant le code du plugin C#, j’ai pu remarquer que l’équipe SonarSource avait publié tous les éléments pour créer notre propre plugin VB.NET sans trop d’efforts. Un bon travail de copier-coller et le tour est joué.

 

Résultat (GitHub)

J’ai placé les sources dans GitHub dans un « fork » du repository de SonarSource que vous trouverez à l’emplacement suivant. J’hésite encore à faire une pull request pour leur proposer de le rendre gratuit pour tous.

https://github.com/karoldeland/sonar-csharp/commit/a1d748832f6fba1a940288450c436a50f63e1088

 

Pour arriver à compiler le plugin VB.NET, juste à suivre les instructions pour le plugin C#. Bonne chance avec Maven ! 🙂

Suis-je seul à trouver ce hack super cool? 🙂

Petits trucs…

J’ai aussi pu intégrer mon nouveau plugin dans TFS 2017 à l’aide des tâches fournies dans le « marketplace ». Toutefois, comme l’exécution des tests unitaires pour tous mes projets étaient conservés dans un fichier unique (C# et VB.NET combinés), on doit faire l’importation du fichier trx par un seul des deux plugins .NET. Pour la couverture de code, on peut importer le même fichier .coveragexml par les deux plugins et tout fonctionne correctement.

Sonarqube – Règle S3776 – Complexité cognitive

L’équipe de SonarSource a publié un article intéressant sur la complexité cognitive. Il s’agit d’une métrique de code qui permet d’évaluer la complexité d’une méthode de manière à mieux représenter la complexité comparativement à la complexité cyclomatique.

Laquelle des deux méthodes suivantes vous apparaît comme plus complexe?

int sumOfPrimes(int max) {              // +1
  int total = 0;
  OUT: for (int i = 1; i <= max; ++i) { // +1
    for (int j = 2; j < i; ++j) {       // +1
      if (i % j == 0) {                 // +1
        continue OUT;
      }
    }
    total += i;
  }
  return total;
}                  // Cyclomatic Complexity 4
  String getWords(int number) { // +1
    switch (number) {
      case 1:                   // +1
        return "one";
      case 2:                   // +1
        return "a couple";
      default:                  // +1
        return "lots";
    }
  }        // Cyclomatic Complexity 4

Source : https://blog.sonarsource.com/cognitive-complexity-because-testability-understandability/

Dans ce cas, la complexité cyclomatique ne représente pas la réelle complexité que perçoit le développeur en lisant le code. Quand on gère comme il se doit notre dette technique, on tente d’éviter les pertes de temps reliées à la compréhension du code. Pour détecter ces « code smells », on peut donc se fier à la métrique de complexité cognitive.

SonarLint et Sonarqube sont des outils qui permettent de détecter la trop grande complexité cognitive dans le code de multiples langages comme C#, Java, Python, etc..

Malheureusement, on ne peut pas personnaliser la limite de complexité dans SonarLint pour Visual Studio.

http://www.sonarlint.org/visualstudio/rules/index.html#sonarLintVersion=2.12.0&ruleId=S3776&language=C#

On peut quand même bénéficier de cette validation gratuitement dans le code C#. Cependant, elle ne contribue pas à faire augmenter la quantité de dette technique dans l’outil Sonarqube. Difficile d’évaluer une durée de correction en fonction de la complexité.

Pour le détail sur la manière de calculer la métrique, consulter le blog de sonarsource.

Microsoft Build 2017–Résumé des conférences jour 3

La troisième journée de la conférence comporte beaucoup moins de grandes annonces du côté des innovations, mais elle ne manque pas d’intérêt pour autant. Plusieurs présentations ont retenu mon attention lors de cette journée. Voici un survol de ce que j’ai apprécié.

Future of Visual Studio

IMG_2051[1].JPG

Aujourd’hui, les outils de développements sont tellement évolués qu’il est difficile d’y ajouter énormément de fonctionnalités. Combiné à un rythme de livraison beaucoup plus rapide qu’auparavant, ce genre de présentation est constitué d’un paquet de petits trucs et astuces. Il est donc difficile de tout vous relater dans un article, mais je vais me concentrer sur les éléments importants.

Productivité

La première partie de la présentation a porté sur les différents ajouts de productivité qui ont été fait à Visual Studio. Quelques nouveaux refactorings comme la possibilité d’ajouter une vérification pour les références nulles dans les méthodes et la possibilité de convertir automatiquement vers les interpolations de chaînes de caractères lorsque c’est possible. Un rappel a aussi été fait sur la possibilité de filtrer les éléments dans l’intellisense. Aussi, la fonction de recherche des références dans le code a été améliorée. La fenêtre des résultats présente les éléments trouvés dans une arborescence décrivant le composant et la classe contenant la méthode trouvée.

FindAllRef

Une extension permettant d’afficher la liste des erreurs et des avertissements directement dans la fenêtre d’archivage du code (Check-in/Commit) verra aussi bientôt le jour. Pour ceux qui n’auraient pas encore le réflexe de réviser le travail avant d’archiver. On y verra donc aussi les informations produites par les différents outils d’analyse statique de code.

D’autres extensions ont été ajoutées pour permettre de créer automatiquement les configurations d’assemblage (Build) et de déploiement (Release) dans VSTS. Disponible sur le menu contextuel du projet dans l’explorateur de solution, on peut entrer les informations Azure pour spécifier les destinations du déploiement directement. Il est aussi possible, par un menu contextuel semblable, de générer le projet docker-compose automatiquement pour rendre compatible notre application avec cette technologie.

Une nouvelle fonctionnalité de Visual Studio 2017 est le support natif pour les fichiers EditorConfig (.editorConfig). Ces fichiers qui résident dans le répertoire de projet servent à personnaliser les paramètres des éditeurs de texte. On peut ainsi indiquer le caractère de saut de ligne (et d’autres options) par type de fichier. Pour plus de détails, voir le projet sur GitHub.

Développement Linux

Le sous-système Linux Ubuntu était déjà disponible sur Windows 10 sans virtualisation. L’ajout de Fedora et de Suse montre que Microsoft veut devenir le leader des outils de développement pour toutes les plateformes. L’équipe Visual Studio a ainsi ajouté des facilités pour déboguer du code destiné à Linux directement sur Windows. En créant un canal SSH vers le sous-système Linux, Visual Studio peut donc s’accrocher au processus Linux pour une expérience de débogage ultime.IMG_2055[1].JPG

https://www.hanselman.com/blog/WritingAndDebuggingLinuxCApplicationsFromVisualStudioUsingTheWindowsSubsystemForLinux.aspx

 

 

Open Q&A: Moving 65,000 Microsofties to DevOps on the public cloud

IMG_2057[1].JPGJ’ai assisté à cette présentation qui était en fait une tribune où l’on pouvait poser des questions à des employés de Microsoft qui ont vécu le passage au DevOps à l’interne. Les panélistes provenaient des équipes Bing, Skype, Azure et Windows. Il a été question du passage à Git pour les équipes (avantages/inconvénients) et de l’adoption des pratiques d’intégration continue et de déploiement continue dans le cloud. Il a été intéressant de voir que les questionnements sur Git sont les mêmes que nous avons eu à mon emploi actuel. Dans tous les sujets, l’idée qui revenait sans cesse était de trouver la balance entre les avantages et les inconvénients.

Pour le passage à Git, ils ont à peu près tous optés pour une approche impliquant un champion dans chaque équipe. Cette personne était responsable de faciliter la transition à Git pour son équipe et de remonter les enjeux à la coordination lorsque nécessaire. Par ailleurs, il a été noté qu’il est difficile de trouver le juste milieu entre la gouvernance/standardisation et la flexibilité/autonomie. L’idée est de commencer à quelque part et d’ajuster les pratiques et les outils lorsque le besoin s’en fait sentir. Pour l’aspect gouvernance, ils recommandent une façon de faire que je prônais moi-même déjà : créer une autoroute. Si le chemin pour l’adoption est déjà tracé et qu’il est rapide, efficace et répond aux besoins à 80%, les gens embarquerons naturellement. Il faut donc opter pour la préconfiguration des outils plutôt que de tenter de mettre des contrôles en place.

 

Blockchain on Azure

Je me suis rendu à cette présentation dans le but d’en apprendre plus sur ce qu’est le Blockchain. Cette technologie repose sur le même genre de technologies que Bitcoin. Elle pourrait bien révolutionner le monde complètement en facilitant les échanges transactionnels de toutes sortes. C’est donc avec toute la volonté d’apprendre possible que j’ai assisté à cette conférence. Malheureusement, j’ai du m’avouer vaincu. J’ai du vérifier plusieurs fois si du sang ne s’échappait pas de mon nez ou de mes oreilles. Le contenu était vraiment complexe. Voici toutefois le contenu que j’ai retenu.

Le Blockchain est une technologie immature qui repose sur les piliers suivants :

  1. Chiffrage
  2. Ledger
  3. Base de données distribuées
  4. Partagés entre les organisatons/individus

Blockchain2.png

Microsoft est en train de développer des outils permettant d’abstraire la complexité de cette technologie. Il supporte déjà plus d’une technologie de Blockchain dans Azure et compte rendre plus accessible leur utilisation. Un Blockchain est constitué d’une partie donnée (document avec propriété fixe et dynamiques), d’une partie logique (permettant de faire des calculs déterministes, et de son stockage (ledger). Cette structure commence à se formaliser autour du concept de Cryptlet qui vient encadrer comment séparer et sécuriser la séparation des constituants.

Blockchain.png

Je sais que mon résumé est flou et décousu, mais je vous invite à écouter la présentation pour avoir plus de détails.

Modern Front-End web development in Visual Studio 2017

C’est avec cette présentation du très connu Mads Kristensen que j’ai terminé ma conférence. Il était là pour nous parler de comment Microsoft se positionnait pour offrir des outils de développement web adaptés aux façons de faire qui émergent dans l’industrie. Certains diront que l’utilisation de Sublime, NPM, WebPack, Bower, Gulp et Grunt n’est pas nouvelle. Microsoft continue quand même d’intégrer certains de ces outils dans Visual Studio.

Trucs et astuces

Ce qui est bien avec Mads Kristensen, c’est qu’il accorde beaucoup d’importance aux détails. Voici quelques trucs qu’ils nous a révélés :

  1. Le débogueur Javascript pour chrome est disponible et facilitera la vie de plusieurs.
  2. L’utilisation de l’outil TypeScript dans Visual Studio peut servir même si on ne fait pas de Javascript :
    1. L’activation de l’outil (V 2.x) permet entre autres de valider certaines erreurs comme l’oubli d’un point-virgule ou les variables non déclarées dans les fichiers .js.
    2. On peut aussi transpiler le code ES2105 vers ES5

Récupération des librairies

Microsoft travaille depuis un moment sur une extension à Visual Studio qui s’appelle Library Installer. Via un fichier Library.json présent dans le répertoire du site web, cet outils permet de récupérer une librairie de cdnjs, mais aussi de filtrer pour seulement obtenir les fichiers nécessaires. Si vous avez besoin de jQuery et non de son cousin jQuery UI ou si vous voulez récupérer seulement la version minifiée, cet outil permet de le faire. Il permet également de configurer l’emplacement de destination.

L’extension fonctionne avec un modèle fournisseur. C’est donc dire qu’il peut récupérer les fichiers de multiples sources différentes. Pour le moment, cdnjs et filesystem sont les deux seuls fournisseurs disponibles. Toutefois, la communauté s’empressera probablement de créer les autres fournisseurs rapidement.

L’extension sera intégré à Visual Studio 2017 de manière native dans les prochaines semaines.

https://github.com/aspnet/LibraryInstaller

Conclusion

Voilà ce qui met fin à mon séjour à la conférence Microsoft Build 2017. Ce fut une expérience inimaginable. La quantité de matière à absorber était impressionnante et l’ambiance formidable. Je souhaite un jour y retourner pour vous transmettre encore une fois l’information le mieux possible.

En espérant que vous avez apprécié!

Présentation du projet Rome

Dans mon précédent billet, j’expliquais que nous nous dirigions vers un monde ou l’interface utilisateur ne se limiterait pas à une application sur un appareil mais s’étendrait sur plusieurs appareils. Aujourd’hui nous disposons déjà d’une multitude d’appareils intelligents : téléphones, PC de bureau, consoles de jeux, système embarqué dans les véhicules.

J’ai assisté à deux sessions en lien avec le projet Rome. Elles m’ont permis de me rendre compte que l’intention était même d’aller plus loin que de partager l’expérience utilisateur sur plusieurs appareils.

La première présentation a débuté sur une citation de Bill Buxton, chercheur Microsoft, que je vous laisse regarder ci-dessous

Bill_Buxton

+ appareils = + problèmes

Il est un fait que nous utilisons plusieurs appareils au cours d’une même journée. Microsoft avance qu’environ 42% des utilisateurs commencent des activités sur un appareil et les finalisent sur un autre. Pouvoir suivre l’activité d’un utilisateur dans ses différents contextes est très difficile, lui permettre de reprendre ses activités dans un contexte différent l’est encore plus.

Le projet Rome vise justement à fournir les outils qui vont permettre maximiser l’engagement avec nos utilisateurs à travers les applications, les appareils et les plateformes qu’ils utilisent.

Project Rome se compose :

  1. D’un runtime à installer sur les appareils qui permet de lancer des applications et de faire communiquer des applications entre elles.
  2. De services d’infrastructure dans le Cloud qui permettent de stocker les utilisateurs, leurs appareils et leurs activités. C’est la technologie Microsoft Graph qui est derrière.
  3. D’un modèle applicatif qui permet de développer des applications qui profitent des opportunités offertes par le runtime.

Activités, cartes et ligne du temps

Une application qui utilise le projet Rome peut enregistrer dans le Cloud des traces d’activités d’un utilisateur. Ces traces viennent nourrir un fil d’activités qui sert de base à la construction d’une ligne du temps des actions passées pour cet utilisateur.

Il y a deux manières d’exploiter le fil des activités enregistrées :

  1. Cortana, l’intelligence artificielle développée par Microsoft, est en mesure d’accéder aux activités passées pour vous proposer de les continuer. Ainsi par exemple si je commence à lire un article sur mon PC, Cortana me proposera d’en continuer la lecture sur mon téléphone intelligent et défilera même le texte pour me laisser là où j’avais arrêté ma lecture. Cortana est disponible sur Windows 10, Windows Phone, iOS et Android.
    Cortana
  2. Sous peu l’application Microsoft Timeline vous permettra de visualiser votre fil d’activités. Il vous sera possible d’en sélectionner une et de la reprendre. La photo ci-dessous montre l’interface de Microsoft Timeline
    Timeline

Dans les deux photos ci-dessus vous pouvez voir que chaque activité est représentée par une carte visuelle. Le rendu de la carte est adapté en fonction du contexte de l’utilisateur. Sur un téléphone, la carte sera sommaire, sur un écran d’ordinateur elle affichera plus d’informations avec une mise en page plus sophistiquée.

Il est possible de développer nos propres cartes grâce à la technologie Adaptative Cards.

Développer avec le projet Rome

Le projet Rome offre différents SDK, un par plateforme (PC, Window Phone, iOs, Android). Les librairies offertes supportent plusieurs framework et langages dont notamment .NET, Java et Javascript.

Ces SDK couvrent plusieurs aspects dont voici les principaux :

  • Les fonctions de découverte d’appareils permettent d’interroger Microsoft Graph pour obtenir les appareils d’un utilisateur. Il y a aussi la possibilité de découvrir les appareils à proximité via Bluetooth.
  • Les fonctions qui permettent de lancer des commandes sur des appareils distants (RemoteLauncher).
  • Les fonctions qui permettent à deux applications d’ouvrir un canal de communication et de s’échanger des messages. Les deux applications peuvent s’exécuter sur un même appareil ou sur deux appareils différents. Cette fonctionnalité permet à une application de devenir un service puisqu’elle devient capable de recevoir des requêtes, de les traiter et d’envoyer éventuellement une réponse.
  • Les fonctions qui permettent d’accéder à Microsoft Graph pour créer, lire ou effacer des activités et des appareils. Microsoft Graph peut être consommé directement via un API REST ou via un modèle objet client.

Les opportunités

Le projet Rome offre la possibilité de garder le contact avec un utilisateur alors qu’il change de contexte.

Plusieurs types d’applications peuvent profiter du projet Rome :

  • Les applications d’édition de documents comme Word, Powerpoint, Illustrator peuvent s’en servir pour permettre aux utilisateurs de travailler sur ces documents dans plusieurs contextes.
  • Les applications multimédia peuvent s’en servir pour continuer la lecture d’un document multimédia sur un autre appareil.
  • Les applications d’entreprise peuvent s’en servir pour permettre à un utilisateur de disposer des informations qui lui sont utiles quel que soit l’appareil sur lequel il travaille. Un utilisateur pourrait commencer à saisir des informations de bases sur son téléphone ou sur une tablette alors qu’il est en visite chez un client. De retour au bureau, il pourrait compléter la saisie du dossier sur son PC.
  • Les jeux peuvent s’en servir pour permettre à un commencer à jouer sur une plateforme pour ensuite la continuer sur une autre.

Rome ne s’est pas fait en 1 jour

Project Rome avait déjà été démontré au Build 2016. A cette époque seul le SDK pour Windows avait été dévoilé. Aujourd’hui les SDK pour iOS, Android et MS Graph sont disponibles en preview. Nous n’avons pas eu de date précise pour la disponibilité d’une version finale mais on peut raisonnablement penser que cela coïncidera avec la prochaine mise à jour de Windows 10 appelée Windows 10 Fall Creators Update à venir Q3 2017.

Rome_1jour