Chose promise, chose dûe ! Voici le compte rendu de cette deuxième et dernière journée du MSDN & Technet Tour 2008 à Strasbourg. Plus technique cette journée fût, comme la journée d'hier on ne peut plus enrichissante. Voici le programme que j'ai suivi :

• Développement sécurisé en 3 lettres : SDL (Eric Mittelette et Eric Vernié)
• Les nouveautés de Internet Explorer 8 pour les développeurs (Pierre Lagarde)
• Présentation de la famille Windows Embedded pour les développeurs (Pierre Cauchois)
  
• Faire du code parallèle pour WPF aujourd'hui et demain (Eric Vernié)

Rentrons directement dans le vif du sujet avec la première session technique!

Développement sécurisé en 3 lettres : SDL

Un début de journée qui attaque fort, mais dans la bonne humeur ! Eric Mittelette et Eric Vernié ont fait une présentation de la fameuse méthode SDL (Secure Developpment Lifecycle). Cette méthode permet de gérer l'importante problématique qu'est la sécurité dans le cycle de vie d'un projet. Première chose à retenir : la sécurité absolue n'existe pas et n'existera jamais. Ce n'est pourtant pas une raison pour négliger celle-ci. Les retours d'expériences des deux speakers nous ont montré que celle-ci reste un aspect souvent négligé dans un projet (vous savez le "on verra ça plus tard") alors qu'elle est priomordiale.

Pour mener à bien cette quête, la méthode SDL fournit une guideline permettant d'établir un plan de sécurité autour d'un projet de développement. Cette technique est d'ailleurs employée depuis 2002 en interne, dans les équipes de développement de Microsoft et aurait permis une réduction de plus de 40% des failles de sécurité entre les OS Windows XP et Windows Vista. L'idée de cette méthode est de vous permettre de concevoir des applications nécéssitant le moins de patchs de sécurité possible afin de préserver votre crédibilité face à vos clients et surtout la confiance qu'ils vous accordent. Elle se déroule en 6 phases décrites ci-dessous :

Phase 1 : Nommer le coach sécurité

C'est dans cette phase que l'on doit désigner un conseiller sécurité. En effet, il est rare que tous les développeurs soient expérimentés en matière de sécurité informatique et sur tous les domaines. Pour reprendre les termes d'Eric Mittelette : "il faut apporter un regard neuf et non naïf au projet". C'est cette personne qui doit être en contact directe avec l'équipe sécurité et l'équipe de développement. Elle est réellement la référence en matière de sécurité et est présente pour préparer les phases de tests, suivre le projet d'un oeil sécuritaire et surtout préparer la phase 5 de la SDL, la Revue Finale de Sécurité (FSR). 

Phase 2 : Modélisation des menaces 

Cette phase, également appelée phase de conception, consiste en la mise en place de directives de conception et d'architecture en matière de sécurité. Il faut faire un listing des attaques qui pourraient se produire et définir ce que l'on appel "la surface d'attaque de l'application". Typiquement, il s'agit des points où l'on demande à l'utilisateur de saisir des données, mais pas uniquement. Cette phase s'effectue sous forme d'un brainstorming général entre les équipes de développement et de sécurité. C'est dans celle ci que l'on doit réellement définir toutes les règles à suivre.

Phase 3 : Phase d'Implémentations

Cette phase consiste en l'application des règles établies dans l'étapes précédentes que ce soit l'application de normes de code ou encore d'exécution de test. Le simple fait de conventionner le nommage des variables peut constituer une approche sécurisé du développement. Il ne faut pas hésiter à pratiquer de l'analyse de code à l'aide des outils proposés par Visual Studio, notamment les outils de métrique de code permettant d'analyser la converture du code : un code non couvert par les tests est potentiellement un risque de sécurité !

Phase 4 : Tests de sécurité ciblés

C'est une phase de vérification du produit lorsque celui-ci est terminé. Il s'agit ici de mettre en place des tests utilisateurs, mais aussi des tests plus ciblés et plus poussés en matière de sécurité. Si votre entreprise compte plusieurs équipes de développement, il est bon de demander, pendant cette phase, à une autre équipe de tester le projet. Elle apportera un regard externe non négligeable dans une politique de sécurité stricte.

Phase 5 : Revue Finale de Sécurité

Cette phase n'a qu'un seul but, répondre à la question "Peut-on livrer le logiciel au client, du point de vue de la sécurité ?". Il est recommandé de mener cette phase au moins deux mois avant la livraison finale du logiciel, ce qui permettra d'avoir une version vraiment stable. Dans cette phase, il faut s'assurer que toutes les menaces de sécurité trouvées lors de la phase 2 sont couvertes, mais aussi que le logiciel ne compte plus de bugs (dans l'idéal). Il s'agit aussi d'une étape de validation de la méthode SDL. En effet, on parle de guideline en matière de sécurité, il ne s'agit pas d'une méthode miracle, garantie 100% sans risques. La méthode SDL reste modulable selon le type de projet que vous menez.

Phase 6 : Mises à jour correctives

Cette phase est permanante du début de la commercialisation du produit à sa fin de vie. Il s'agit de continuer à tester l'application ou du moins de rester réactif aux bugs et éventuelles attaques qui pourraient être rapportés par vos clients afin de les corriger le plus rapidement possible.

Conclusion SDL :

Je voulais juste préciser qu'il s'agit d'un résumé rapide de ce que j'ai pu apprendre pendant cette session, et que cela reste surement très incomplet. Je n'ai d'ailleurs pas la prétention de pouvoir aujourd'hui vous faire un exposé complet sur la méthode SDL! Pour les personnes intéressées, Microsoft à lancé une grande campagne pour promouvoir cette méthode : La méthode SDL contre les mécapoulets. Sur le ton de l'humour g33k, la méthode est introduite par une vidéo ou 3 développeurs doivent sauver le monde d'une attaque de robots poulets (il fallait y penser ).

Vous retrouverez énormément d'informations sur la SDL sur le site : http://www.mecapoulets-lefilm.fr . 

Les nouveautés de Internet Explorer 8 pour les développeurs

Je vous parlais hier brièvement de la béta 2 du navigateur de la firme de Redmond, Internet Explorer 8. Curieux suite à la session plénière de la veille, j'ai choisis d'assister à cette session animée par Pierre Lagarde. Ce dernier à commencé par introduire cette nouvelle version, notamment en termes de nouveautés. Voici les grands points qui sont à retenir :

Côté moteur de rendu, Internet Explorer 8 en embarque non pas un, non pas deux, mais trois ! En effet, on retrouve par défaut le nouveau moteur de rendu Internet Explorer 8 (respectueux des derniers standards du W3C en matière de HTML et des normes CSS 2.1 par succès du test ACID 2), mais aussi les moteurs de rendu de Internet Explorer 7 et 5.5. Lors de la navigation, vous pouvez d'ailleurs switcher très facilement entre les modes IE8 et IE7. On notera ici que ce switch ne nécéssite plus le redémarrage du navigateur comme dans la première béta. Si votre site n'est pas encore compatibles avec le moteur de rendu Internet Explorer 8, mettez vous au boulot! Non, plus sérieusement, vous avez la possibilité de forcer le passage du navigateur en mode IE 7 et ce de manière totalement transparente pour l'utilisateur, à l'aide d'un simple méta-tag à placer dans vos pages :

     <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Pour les développeurs ASP.NET, sachez qu'il est possible de définir le moteur de rendu du site directement via le fichier de configuration de l'application web :

    <configuration>
      <system.webServer>
        <httpProtocol>
           <customHeaders>
            <clear />
            <add name="X-UA-Compatible" value="IE=EmulateIE7">
          </customHeaders>
        </httpProtocol>
      </system.webServer>
</configuration>

Rien de bien contraignant qui forcerait le retardement de passage à ce nouveau navigateur (convaincu, je l'installe au moment même ou j'écris ces lignes).

D'autre part Internet Explorer 8 apporte des amélioraitons au niveau performances, notamment du parsing et du rendu HTML, ainsi qu'une exécution plus rapide du JavaScript.

Côté outils pour les développeur, Internet Explorer 8 embarque de nombreuses de nouveautés, notamment une intégration native de la Developper Toolbar munie de nouvelles fonctionnalités telles que l'affichage hiérarchique du DOM HTML ou encore le debug au sein du navigateur du code JavaScript. Cette seconde nouveauté est non négligeable pour les développeurs. En effet, là ou avant la tâche était assez fastidieuse (lancement de la page web, attachement du processus à Visual Studio et debug du code JS, si ça marchait...), en quelques clics, vous avez accès au deboggeur. Plus que du déboggage, Internet Explorer 8 permet maintenant le Profiling du code JavaScript, c'est à dire le suivi du code côté client, la mesure du temps d'exécution ect...

Vous retrouverez ci-dessous quelques screenshots que je viens de réaliser des outils de développement embarqués à IE 8 : (Cliquez pour agrandir)

    

    

 

 

Vous retrouverez une introduction aux accélérateurs sur le centre de développement MSDN.

Enfin, un petit point pour les développeur web qui souhaiteraient pouvoir développer et tester leurs sites Internet sur les différentes versions d'Internet Explorer, sachez qu'il existe un outil, IETester, permettant de rendre votre site Internet selon différents moteurs de rendu. Vous trouverez plus d'informations sur cette page.Il est à noter également que Microsoft propose une VPC XP exécutant IE8 pour ceux qui ne souhaitent pas encore installer la nouvelle version du navigateur. Rendez-vous sur cette page pour plus d'informations et les liens de téléchargement.

Une dernière chose que l'on peut préciser est le gestionnaire de crash IE8. En effet, avec cette nouvelle version, un processus est exécuté par onglet ce qui permet de ne pas perdre tout ses onglets en cas de crash d'une page.

Présentation de la famille Windows Embedded pour les développeurs

Cette session était animée par Pierre Cauchois est avait pour but de présenter d'une part la famille des OS "Embedded" de Microsoft et surtout les outils permettant de développer en .NET pour ces machines. Nous sommes tous les jours confronté aux systèmes embarqués : dans nos réveils, chaînes hifi, lave-linge, bus, voiture, avion... et la tendance ne va pas aller à la baisse avec l'arrivée de la domotique, de plus en plus présente. 

Microsoft propose deux grandes gammes de systèmes :

Parmi ceux de la famille Embedded, on distingue encore 3 grandes familles :

A chaque famille d'OS correspond une version du .NET Framework. En effet, Microsoft souhaite démocratiser le développement dans le domaine des systèmes embarqués et un moyen de le faire simplement est de proposer aux développeurs les mêmes outils et langages, quelques soit la plateforme sur laquelle ils développent.

Les familles Embedded Enterprise et Embedded Standard exécutent sans soucis le .NET Framework dans sa version complète. En revanche, la famille d'OS Embedded CE exécute une version allégée du .NET Framework, appelée .NET Compact Framework, permettant néanmoins d'éffectuer des développements très complets pour les terminaux.

Du côté des laboratoires de Microsoft Research, on apprend l'existence d'un .NET µFramework (micro framework) ne nécéssitant pas de système d'exploitation pour exécuter des applications, celui-ci étant capable de communiquer directement avec des micro-processeurs. On apprend aussi l'éxistence d'un outil appelé Robotics Studio permettant la création d'application robotiques. Je ne rentrerai pas spécialement dans le détail de ces deux technologies par manque de connaissances, mais sachez par exemple que le µFramework ne pèse que quelques 64 ko, donc présage la présence d'application .NET dans tous les objets électroniques que nous manipulons au quotidien.

De plus, vous pouvez bien entendu développer avec Visual Studio, quelque soit les .NET Framework que j'ai pu cité ci-dessus. En ce qui concerne le développement avec le µFramework et Robotics Studio, Microsoft fournit des émulateurs permettant de simuler le comportement de vos cartes électroniques ou robots, évitant ainsi des pertes matérielles souvent chère :]

Robotics Studio introduit un nouveau langage, Visual Programming Language qui vous permet de "dessiner" le comportement de votre robot :

Pour une introduction plus complète à Robotics Studio, rendez-vous sur cette page (Anglais).

Faire du code parallèle pour WPF aujourd'hui et demain

Animée par Eric Vernié, cette session avait pour but de présenter les différentes façon de paralléliser du code dans une application WPF (Windows Presentation Foundation). Cette problématique est en effet complètement d'actualité. Nos applications sont la plupart du temps développées pour une architecture mono-coeur et il ne faut pas se voiler la face, le fait d'exécuter une application mono-thread sur une plateforme multi-coeur ne la fera pas accélérer! Il est donc temps de changer nos méthodes de développement et de passer véritablement au multi-threading et à la parallelisation de tâches.

Eric Vernié nous a présenté au cours de cette session des statistique issues des laboratoires d'Intel montrant que d'ici 2020, au rythme d'augmentation des fréquences prédits par la loi de Moore, et en admettant que nous conservions une architecture mono-coeur, la dissipation thermique de nos processeurs atteindrait celle de la surface du soleil. Ironie, exagération ou vérité ? Bonne question, quoi qu'il en soit, l'avenir est dans l'architecture multi-coeur. Il a aussi été souligné qu'un overclocking de 20% de la puissance du processeur provoque un gain de performance moyon de 13% et une augmentation de la consommation de 73%, alors que la baisse de 20% de sa puissance entraîne une perte de 13% de performance contre une baisse de consommation avoisinnant les 50%. Quelle conséquence doit-on tirer du multi-coeur ?

Il existe de nombreuses méthodes pour écrire du code multithreadé. De l'instanciation de Thread pure et dure, en passant par les composants BackgroundWorker ou ThreadPool qui nous facilite la vie, jusqu'à quelque chose de plus récent, les .NET Parallel Extensions. Derrière ce nom se cache un framework, dont la dernière CTP sortie en Juin 2008 est disponible sur cette page, qui va nous permettre de paralléliser des traitements et ce très simplement. 

Au travers des différentes démonstrations effectuées par Eric, nous avons pu constater que sur certains traitements, la parallélisation apporte un réel confort aux utilisateurs dans l'utilisation des applications, mais aussi des performances accrues, les tâches s'exécutant de manière simultannée sur les différents coeurs de notre machine.

Vous pouvez retrouver une introduction aux extensions paralèlles à .NET dans cet article d'Eric Vernié.

Conclusion

Pour ma part, je suis content d'avoir pris ces deux jours pour me rendre au MSDN & Technet Tour afin d'assister à toutes ces sessions techniques, animées par des passionnés, qui il faut le souligner, restent très accéssibles pour discuter et répondre aux questions.

On retiendra donc de ces deux jours le flot de nouveautés que nous avons accueillies durant toutes cette années 2008 dans la monde Microsoft. A priori, de grosses nouveautés sont encore attendues d'ici la semaine prochaine. En effet, c'est à partir du 27 et jusqu'au 30 Octobre que se déroule la PDC2008 (Professional Developers Conference) à Los Angeles. Cet évènement devrait être le lieu de grosses annonces concernant le futur OS de Microsoft, Windows Seven. On en apprendra surement plus également sur la future mouture de Visual Studio, qui je vous rappel sera appelée Visual Studio 2010, ainsi que sur le .NET Framework 4. Le mois de novembre devrait aussi être le moment d'annonce concernant la méthode SDL vue plus haut dans cet article.

Bref, beaucoup de chose en perspéctive. Le prochain évènement Microsoft en France (à part la fin du MSDN & Technet Tour en région) sera les Techdays 2009, au Palais des Congrès à Paris, les 10, 11 et 12 Févrirer 2009.

A bientôt

Permalien | Commentaires (0) | Post RSS |

Catégories : Evènement | Microsoft