Kinect for Windows SDK: Released!

Par | Classé dans .NET, News | Le 21/06/2011

Tags « »

0

Dévoilé durant le MIX11 qui s’est déroulé à Las Vegas en avril dernier, c’est finalement à la date du 16 juin 2011 que Microsoft a décidé de mettre à disposition le kit de développement (SDK) Kinect pour Windows. Les développeurs en herbe ou passionnés peuvent désormais se donner à coeur joie dans la conception d’applications exploitant les fonctionnalités interactives de la machine. Espérons voir fleurir rapidement sur la toile bon nombre d’outils qui sauront tirer partie de ce petit bijou technologique !

Kinect pour Windows

Sortie du SDK Kinect pour Windows

Initialement dénommé “Project Natal”, le Kinect possède désormais une place d’honneur dans le World Guiness Book comme étant l'”accessoire High-Tech le plus vendu dans un court laps de temps” (dixit. World Guiness Book). Initialement conçu pour la console de Microsoft, la Xbox 360, le Kinect s’est voulu être une nouvelle façon de jouer aux jeux vidéos sans manettes appelé également Motion Gaming. Il a rapidement réussi à attiser la sympathie du public avec son concept de commande à la fois ludique et innovante et offrant alors de nouvelles possibilités en terme d’intéractions. Disposant de deux caméras, un capteur de champ par infra-rouge et d’un microphone, le Kinect fonctionne par reconnaissance spatiale d’un corps en mouvement.

Mais les curieux n’avaient pas attendu cette sortie pour mettre au point un pilote compatible Windows pour faire leurs premiers essais. C’est ainsi que le kit CL-NUI Platform a sévi sur internet et proposait déjà de prendre le contrôle sur les capteurs vidéos de l’appareil. On a pu voir apparaître quelques démos techniques (des exemples sur http://kinecthacks.net/) prenant en compte la détection de mouvements qui laisse présager d’autres innovations dans la conception d’interfaces interractives différentes du mythique combo clavier/souris ou plus récemment écran tactile : robotique, réalité augmenté, … Minority Report, ça vous rappelle des souvenirs ?

Lire la suite…

Ou comment reporter à plus tard…

Par | Classé dans BRMS, Intermédiaire | Le 15/06/2011

Tags « »

0

Tel que l’analyse Neal Ford à travers son concept d’Emergent Design, plus un projet (informatique) avance, plus les connaissances sur celui-ci sont avancées, ce qui demande à reculer au maximum toute prise de décision concernant ce projet.

La connaissance acquise est essentiellement métier et ergonomique (pour autant que la technologie employée est maitrisée). Si pour les aspects ergonomiques, un prototypage graphique peut (ou devrait) être proposé, comment faire de même avec le code sous-jacent, le code représentant les connaissances métier ?

Un première approche se base sur un processus itératif, suivant un processus dit “agile”. Cela est toutefois rarement compatible avec des langages de développement “classiques”. En effet, il faut alors prendre très tôt des décisions majeures et structurantes. De plus les changements deviennent de plus en plus difficiles et coûteux. Il conviendrait donc de pouvoir poursuivre le plus tardivement possible la phase de conception, ce qui peut apparaître contradictoire avec cette approche “agile”. De plus, l’expérience montre que même les meilleures des conceptions ne peuvent prévenir de nécessités de correctifs en phase de réalisation.

L’idéal serait donc de pouvoir disposer d’un langage tout à la fois de spécification tout en étant exécutable pour pouvoir valider cette même spécification à travers des cas de test. Cela est rendu possible par des langages de type “règles métier”. En effet, ceux-ci permettent pour la plupart de construire des modèles objets (dits “BOM”) de façon souple, voire dynamique, tout en proposant (plus ou moins automatiquement suivant le Business Rule Management System utilisé) un langage de type DSL permettant d’exprimer et d’exécuter des règles métier s’appliquant sur ces objets.

À noter que les principaux BRMS proposant une couche d’interfaçage entre le code décrivant les règles et le framework sous-jascent (Java, .NET, xml, Cobol, etc.), il est tout à fait possible de ne faire le choix de ce(s) framework(s) (plusieurs pouvant cohabiter) que tardivement en fonction des contraintes finales de l’application à développer.

On s’aperçoit également que cette technologie permet de gérer beaucoup plus facilement les cas particuliers. En effet, ces “cas” sont en général caractérisables par un ensemble de contraintes, pouvant être soit directement exprimées au niveau des règles, soit être gérées par le ruleflow. De plus, le fait d’exprimer clairement le domaine métier au sein de règles fait ressortir beaucoup plus facilement ces cas “hors normes”.

Enfin, il est bien rare que la première mise en production d’une application soit la dernière pierre de l’édifice. Les phases de maintenance et de migrations sont primordiales dans la vie d’un logiciel. Des correctifs et évolutions sont donc à prévoir. Ici aussi, les points soulignés ci-dessus (changement de framework sous-jascent, traitement des cas particuliers, etc.) pourront être mis à profit. Avec de plus un avantage décisif par rapport aux langages informatiques traditionnels : le code des règles étant tout à la fois le code exécuté (et donc évoluant avec les mises à jour) et les spécifications de l’application, il y a alors garantie de non divergence entre ces deux aspects, ce qui bien qu’essentiel pour la maintenance est rarement le cas pour la plupart des applications informatiques.

En conclusion, l’usage d’une approche “règles métier” permet de changer radicalement le mode de développement d’applications informatiques, tout particulièrement en permettant de retarder les prises de décisions au moment où la connaissance du sujet est enfin suffisamment avancée, tout en facilitant les ajustements rendus nécessaires dans les phases ultérieures du projet.