Liste des packages R sur MLServices

En avril 2015, Microsoft rachetait la société Revolution Analytics pour intégrer sa solution RRE au serveur de bases de données SQL Server. En plus des trois services historiques (Integration Services, Analysis Services, Reporting Services), est donc apparu R Services dans la version 2016 de SQL Server. Un an plus tard, pour la sortie de SQL Server 2017, le service est rebaptisé Machine Learning Services et intègre maintenant le langage Python.

Les deux langages phares de l’Open Source pour la Data Science partagent la notion de packages, c’est-à-dire de libraires apportant des fonctionnalités complémentaires et souvent indispensables.

Ainsi les packages R s’installent avec la ligne de commande :

 install.packages("nomPackage")

Il est maintenant possible de jouer le code R au plus près des données (« in Database Analytics ») en l’encapsulant dans un script T-SQL.

Mais l’appel aux librairies spécifiques est conditionné… par leur présence sur le serveur !

Voici un script qui permet d’obtenir la liste des packages présents sur le serveur hébergeant ML Services :

EXEC sp_execute_external_script
@language = N'R'
, @script = N'
pkg_list = data.frame(installed.packages()[,c(1,3,5,16,2)])
'
, @output_data_1_name = N'pkg_list'
WITH RESULT SETS ((
Package nvarchar(200)
,Version nvarchar(200)
,Depends nvarchar(200)
,Built nvarchar(200)
,LibPath nvarchar(200)
));

Et ci-dessous, un exemple de résultat :

ML Services - pkg du serveur

Paul PETON, Microsoft MVP Artificial Intelligence

 

 

 

 

 

 

 

SCCM – Une vidéo sur l’intégration des mises à jour Third Party

L’intégration de mises à jour Third Party est l’une des fonctionnalités les plus demandées sur le site de commentaires UserVoice de Configuration Manager. Si vous avez regardé les aperçus techniques de Configuration Manager depuis la 1803, vous avez peut-être remarqué que cette nouvelle fonctionnalité était en cours de prévisualisation et même implémenté dans la version 1806 sortie ces derniers jours.

Lire la suite

//Build 2018 – Build intelligent analytics app with MS Graph and Azure

Cette dernière session montrait comment il va être possible de construire et vendre des solutions d’analyse des données disponibles depuis le Graph Microsoft 365 (documents, mails, meetings…). Le service est en preview sur invitation (http://aka.ms/o365analyticspreview).

Ce type de solution va combiner plusieurs modules existants ou à venir :

  • Azure Data Factory (https://azure.microsoft.com/en-us/services/data-factory) pour extraire et préparer les données à analyser
  • O365 Privilege Access Management pour gérer les accès au Graph depuis le portail d’administration
  • Azure Managed Application pour packager sa solution et la publier sur le Market Place de telle sorte qu’elle s’installe de manière sécurisée sur le tenant du client sans avoir besoin d’y accéder en tant qu’éditeur

Et tous les services Azures pour stocker, transformer, analyser, extrapoler, afficher la données.

Les exemples de scénarios sont très variés : identifier les sujets majeurs dans l’entreprise et les documents liés, analyser les modes de collaboration, améliorer son organisation…

 

 

//Build 2018 – SmartUI with Adaptive Card and MS Graph

Ce talk au format court montrait essentiellement des démos de différents scénarios d’intégration de l’API Microsoft Graph :

//Build 2018 – Adaptive Cards in Bot, Windows, Outlook and your own application

L’objectif d’une Card est de publier du contenu au sein d’une autre application, il y a donc 2 acteurs : l’auteur du contenu et le conteneur en charge du rendu. Il existe déjà des formats de Card (Twitter, Open Graph, Messenger…) mais qui sont relativement rigides, et le problème d’intégrer un HTML Canvas donnerait trop de liberté, d’où l’idée des Adaptive Cards !

On démarre par une belle démo des différentes expériences utilisateurs dans un Bot, dans Teams, dans le Notification Center de Windows, dans une app UWP, dans Outlook et même Cortana ! Les sources de la démo sont sur https://github.com/matthidinger/ContosoScubaBot.

Au passage, on apprend que le support des Adaptive Cards est déjà sur la version Web d’Outlook Web, et arrivera à la fin du mois sur Outlook Desktop.

Une Adaptive Card a donc un rendu natif et adapté à son conteneur, peut être créer à faible cout, et uniquement via une déclaration JSON décrivant le contenu, les actions, les champs de saisie, de la voix…

La seconde démo nous montre comment créer son Adaptive Card sur http://adaptivecards.io/visualizer . Ils travaillent aussi sur un designer http://acdesignerbeta.azurewebsites.net/ pour créer son fichier JSON plus simplement.

Pour la troisième démo, on voit la construction de bout en bout d’une Adaptive Card « Hello Word » pour Outlook :

  1. Création du modèle dans le designer en ligne
  2. Utilisation d’une Azure Function
  3. Test d’envoi depuis https://messagecardplayground.azurewebsites.net/
  4. Affichage dans Outlook O365
  5. Puis dans Outlook Deskop où le contenu a été mis à jour

Pour construire ses Cards dans son back-end, on peut utiliser les objets C#, parser des templates JSON, utiliser des vues Razor pour générer le JSON ou des composants .acx en NodeJS.

On continue par le rendu d’une Adaptive Card dans son application via les SDK disponibles pour JS/HTML, WPF, UWP, iOS ou Android (Xamarin et ReactNative à venir). Là aussi, on a un fichier host.config pour déclarer comment le rendu doit se faire dans l’application. Ensuite on doit brancher les évènements si la Card contient des actions.

On finit par Adaptive Card V2 (en construction)

  • Inclure simplement des sous Cards juste par une URL vers du contenu décrits via des schémas comme ceux de schema.org (exemple restaurant)
  • Utiliser une bibliothèque de templates
  • Transformer côté client un contenu pour le binder sur son template
  • Gérer un état de la Card en rappelant le fournisseur du contenu

 

Une super session à revoir pour ceux qui veulent se lancer sur le sujet !

//Build 2018 – Continuous Monitoring for DevOps with Azure Application Insights & Log Analytics

La session commence par un courte introduction sur l’importance du monitoring dans le cycle DevOps, et avant tout pourquoi monitorer son application :

  1. Pour rendre visible l’état général de son application
  2. Pour trouver et résoudre les problèmes
  3. Pour l’optimiser en apprenant

azure-monitoring

Et pour monitorer son application, Azure propose des outils out-of-the-box analysant à la fois des données opérationnelles et des données applicatives. Tous outils peuvent être personnalisés pour surveiller des scénarios spécifiques.

La suite était une longue série d’exemples d’usage des outils sur le portail :

  • L’écran Health d’un nœud Kubernetes avec un drill-down vers Log Analytics pour regarder en détail les évènements liés
  • La configuration d’alertes sur des métriques avec en preview le choix de seuils dynamiques (déterminés par du ML sur les données historiques) plutôt qu’un seuil statique unique
  • Les différents choix d’action sur les alertes : email, sms, déclenchement d’un Logic App, lien vers son ITSM…
  • L’écran Application Map d’un site Web pour suivre les différentes ressources Azure liées et leurs interactions
  • L’écran Failures pour analyser les exceptions, voir le détail d’un transaction de bout en bout, ouvrir un snapshot de debug dans Visual Studio avec les données captées en production, ouvrir un ticket dans VSTS…
  • Le Live Metrics Stream
  • L’ajout de tâches de monitoring dans une release VSTS : ajout d’AppInsights, configuration d’alerte, ajout d’un tag de version dans AppInsights
  • L’écran Users pour analyser l’usage du site
  • L’enregistrement de chemin d’analyse dans un Workbook partageable
  • Et plein d’exemples de requête sur les données AppInsights (un cours Pluralsight devrait sortir sur le sujet !)

J’ajouterai le lien vers la vidéo parce que c’était vraiment riche !