Sortie de Qt Visual Studio Tools 2.1.2 Beta

L’intégration de Qt à Visual Studio poursuit son bonhomme de chemin avec la version 2.1.2. Celle-ci est la première à être compatible avec Visual Studio 2017.

Depuis la 2.0, l’extension gère la coloration syntaxique pour QML. L’importation des projets QMake de grande taille est plus rapide. La variable d’environnement $(QTDIR) est mieux gérée, ce qui réduit le risque d’erreur.

Cette version n’a qu’un problème connu : elle force à utiliser le SDK Windows en version 8.1, ce qui cause des problèmes s’il n’est pas installé. Il est cependant possible de contourner ce défaut.

Voir aussi : Qt Visual Studio Tools Version 2.1.2 Beta, la liste des changements.

Télécharger le paquet VSIX directement ou depuis Visual Studio Marketplace (version 2.1.1 pour le moment).

Advertisements

Les nouveautés de Qt Location 5.9

Qt Location est le module de Qt chargé de l’affichage des cartes et de l’interaction avec elles. Il a reçu bon nombre d’améliorations avec Qt 5.9, pour éliminer des limitations anciennes.

Une des nouveautés principales est la possibilité de faire tourner les cartes et de les incliner à volonté, tant pour les cartes que les items ajoutés. Deux nouveaux gestes sont reconnus pour les interfaces tactiles : la rotation avec deux doigts qui tournent et l’inclinaison avec un glissement vertical des deux doigts.

En zoomant un peu trop, Qt Location avait la fâcheuse habitude de remplacer les zones pas encore chargées par la couleur d’arrière plan — contrairement à presque tous les services comparables. Désormais, les parties manquantes seront remplacées par une approximation basée sur les données disponibles en cache, ce qui améliore énormément le rendu.

Avant Qt 5.9, Qt Location ne pouvait afficher des cartes que selon une méthode fixe : découper la cartes en petites zones et les donner au moteur de rendu intégré. Maintenant, le module s’ouvre à des moteurs de rend externes : toute implémentation de QGeoMap peut directement ajouter des nœuds au graphe de scène Qt Quick. Justement, Qt 5.9 est livré avec une extension exploitant cette nouvelle flexibilité, basée sur Mapbox.

Toujours dans le domaine du rendu, toute implémentation de QGeoMap peut désormais indiquer les types d’items qu’elle peut afficher à l’écran. Dans ce cas, Qt Location laisse l’extension se charger du rendu de ces items et de leur apparence — tout ce qui n’est pas géré par l’extension ne sera pas affiché. Mapbox est dans ce cas : il est possible de dessiner des rectangles, des cercles, des polygones, mais pas des bordures.

D’autres fonctionnalités ont été implémentées, elles sont décrites en plus ample détail sur le blog de Qt.

La science des données est-elle morte ?

L’apprentissage automatique et la science des données sont maintenant partout, l’actualité le montre assez. En exploitant des jeux de données immenses, il devient possible de résoudre n’importe quel problème, comme détecter si quelqu’un s’est fait voler son identité en ligne ou jouer au go.

Le problème, c’est que, pour atteindre ces résultats, il faut de la créativité, pas simplement une capacité d’écrire du code : en d’autres termes, il faut des scientifiques des données. Ils sont cependant une ressource rare, que les entreprises s’arrachent.

La solution est toute trouvée dans un grand nombre de cas : des services en ligne proposant les modèles de sociétés privées, appelables par une API REST ou autre. Ainsi, un même genre de problème est résolu une seule fois, avec des jeux de données de plus grande taille, qui grandissent sans cesse avec l’utilisation de la plateforme. C’est notamment le cas d’IBM Watson, dont les capacités n’ont de cesse d’étonner.

L’efficacité de ces services est souvent extrêmement bonne, largement suffisante pour ne pas justifier l’engagement d’un scientifique des données. Dans certains cas, des solutions plus spécifiques peuvent apporter une meilleure performance, une prédiction juste dans 95 % des cas plutôt que 80 % en utilisant un service tout fait, mais avec un coût autre — et un bénéfice plus que très relatif, selon le cas d’utilisation. Dans d’autres cas, battre un service en ligne (de traduction automatique, notamment) requiert des compétences très poussées, des solutions algorithmiques avancées et une puissance de calcul pas à la portée du premier venu.

Ce constat est suffisant pour que certains affirment d’ores et déjà que la science des données telle qu’on la connaît pour l’instant est morte et enterrée : il n’y a plus besoin d’engager quelqu’un qui a des compétences spécifiques dans ce domaine, pour la plupart des besoins. Le scientifique des données “du futur” aura donc tendance à devenir un chef d’orchestre, qui arrange savamment les différentes API avec des données traitées en conséquence.

Ce ne serait pas le premier domaine à subir une telle évolution. La recherche opérationnelle était autrefois présente dans bon nombre d’entreprises, avec des services dédiés, bon nombre des tâches sont maintenant reprises par des sociétés qui proposent des logiciels clé-en-main — les services de recherche opérationnelle ont depuis souvent fusionné avec ceux de science des données.

Néanmoins, dans tous les cas, des gens avec ces compétences spécifiques restent requis : d’un côté, il faut construire ces services en ligne ; de l’autre, tous les besoins ne sont pas remplis par des logiciels existants, il faudra toujours développer, de temps à autre, une solution sur-mesure.

N’est-ce pas ?