Applications: Managed vs Native

Disclaimer: cet article n’engage pas le point de vue de mon employeur ou de Microsoft. Je travaille dans le monde du Services Microsoft, je fais du développement .NET/C# et C++, des audits, de la formation ; je contribue en C/C++ à Windows, mais je ne fais pas de Java. Question de principes.

Les années 2000 ont vu l’explosion des langages dit “Managed” comme Java ou NET. Leurs caractéristiques sont les suivantes:

  • Productivité accrue
  • Compilation du code en un langage intermédiaire (bytecode ou MSIL) avec des méta-data
  • Langage dérivé de C++
  • Environnement d’exécution securisé sous forme de machine virtuelle qui emet du code à la volée (JIT ou Just In Time Compilation) à partir du bytecode ou du MSIL quelque soit l’architecture matérielle, l’OS ou le processeur
  • Suppression automatique de la mémoire allouée (Garbage Collector)
  • Framework (super boite à outils) qui contient des packages pour coder l’accès aux données, les Web Services, les structures de données, la crypto, la sécurité, l’UI, le support XML, JSON, etc.

Ces systèmes “managed” existent depuis 20 environ et ont bati leur réputation en dénigrant les langages traditionnels à base de compilation native qui ciblent une architecture matériel ou processeur ou OS distinct.

L’application “Managed” est par nature “safe et secure” car le code ne peut être modifié par une main extérieure. La langage contient des exceptions et le code est déterministe et le code intermédiaire généré contient des met-data et checksum qui assurent que le code généré est sécurisé.

Comparé au code C++ qui était pointé du doigt (car code majoritairement utilisé par les développeurs dans les années 90-2000) qui permettait d’être attaqué par buffer overflow, etc. Le message était le suivant: C++ est unsafe et unsecure. Venez faire du Java/.NET à la place.

Pour bien charger la mule, on ne parle plus de code compilé ou code C/C++ mais de code “Unmanaged”. C’est une escroquerie intellectuelle. On n’est pas ici pour se raconter des histoires: C’est complètement faux de dire qu’un code C/C++ est unsafe et unsecure. L’OS est fait avec ! le Shell, etc.

Ces systèmes Managed ont expliqué qu’il n’y aurait jamais de virus fait avec. Avec le recul, on s’aperçoit qu’il n’y a jamais eu autant de logiciels malveillants faits avec ses technologies car très faciles à utiliser pour coder de la socket bas niveau par exemple, faire des outils d’attaque DOS.

Revenons au comparatif de fonctionnalités pour un code “Unmanaged”:

  • Compilation du code C++ en assembleur optimisé (code pour pipelines parallèles et code vectorisé, support des instructions étendues pour les processeurs Intel ou AMD) => “Power and Performance”
  • Support des APIs de l’OS hôte : accès illimité aux API du système d’exploitation
  • Gestion automatique de la mémoire en C++ Moderne (C++11) via les smart pointers
  • Code syntaxiquement compatible à 90% avec Java ou C# en C++ Moderne

La vérité du terrain: Regardons la liste des applications que nous faisons tourner au quotidien sur nos PC par exemple:

  • Windows, Linux: OS en C/C++.
  • Suite Office: Word, Excel, Outlook, PowerPoint : C/C++
  • Outils: 7zip, Adobe reader, Chrome, VLC : C/C++

Bref, les vrais logiciels sont faits en C/C++. Pourquoi ? Parce que c’est rapide, fiable et que l’expérience utilisateur est maximum. Je fais une action, le logiciel répond immédiatement.

N’avez vous jamais eu la frustration de clicker dans une application et d’attendre 3 secondes avant que cela répondent…. ?

Le monde du mobile a revu l’essence du monde Unmanaged car les devices ont un petit processeur, peu de mémoire et peu de stockage. Et là, l’utilisateur veut de la performance et du répondant. Une application qui met 30 secondes à se lancer est swappée rapidement. Le mobile a besoin de traiter les images de la caméra, par exemple, il lui faut du natif ! Pas le choix…

Quel est le bilan des systèmes du “Managed” depuis 2000 ?

Java a sorti son épingle du jeu et est massivement utilisé sur les systèmes Linux comme Red Hat. De la guerre .NET/Java, il est clair que Microsoft n’a pas su gagné le combat. D’une part en interne, Microsoft a une relation schizophrène avec .NET, Microsoft propose la technologie mais ne fait pas ses logiciels avec. Microsoft fait 95% de ses logiciels en C/C++ avec la stack C++ Moderne.

Vous allez me dire oui mais pour les entreprises ? OK, dans le monde du Services, les sociétés Gold Partners font du .NET. Mais les systèmes d’informations faits en NET sont rares comparés aux SI Java. Les entreprises réservent leurs applications d’entrée gamme aux technologies Windows et .NET mais dès qu’il faut attaquer le coeur de métier, aller sur les gros serveurs Linux ou Unux, Java est utilisé. Microsoft a du mal à se faire une place dans les grosses sociétés pour le SI stratégique. OK on vend des WS en .NET, un peu de SQL Server à droite à gauche, du SharePoint, mais ça reste de taille moyenne en général. Microsoft est le choix des petits et moyens systèmes. Oui, cela fait des milliers de clients mais de petites structures. Quelques appz clients lourds mais pas de SI stratégiques… Microsoft perse dans les entreprises avec Windows Server, Active Directory, la suite Office, la messagerie mais à l’époque du Web, le discours du développement Microsoft est très flou. On nous parle de .NET Framework 5.0, de .NET Core 3.0 Preview 6 , de .NET Standard 2.2, c’est très flou et assez compliqué…Dans le monde des services public, Java est utilisé massivement. Dans les banques, c’est 50/50 avantage Java.

Avec le cloud, la donne change un peu… On peut héberger pleins de petits serveurs et la guerre n’est plus Java./NET mais Web/JS vs le reste du monde.

Code Review Microsoft : Le diable se cache dans le détail

En ce moment, je contribue au code source Microsoft de Windows Terminal. Le projet est en open-source sur GitHub et Microsoft accepte les contribution externes.

J’ai commencé par observer le code source qui est assez important et puis j’ai opté pour la création d’une issue suite à des commentaires dans le code qui disaient “changer ci, changer ça, TODO MSFT, etc”.

Après plusieurs jours de réflections, j’ai commencé de jardiner dans le code. Tu modifies un fichier cpp , un ou deux fichier .h et puis les classes utilisatrices ont des changements à répercuter. Bref, tu modifies 15 fichiers au final pour un juste petit changement… Mon premier commit a été massif mais ce fut libérateur. J’ai réalisé que je pouvais le faire. D’un autre côté, cela fait plus de 15 ans que j’ai accès au code source de Windows, donc avec le temps ça serait malheureux de ne pas y arriver… ça serait une faute depuis tout ce temps !

Le temps du Pull Request est venu… C’est le moment ou tu remontes les changements de ta branche chez le projet principale et là, tu décris tes corrections et tu passes par la revue de code ou code review et là, chez Microsoft c’est impitoyable…

Exemple sur l’utilisation de smart pointers:

  • ne pas mettre de pointeur, passer un smart pointer
  • ne pas passer un smart pointeur si une réfrence suffit
  • mettre les ref en const
  • oter les copies de variables inutiles

Au départ, j’avais fait pas de changement et mis des smart pointers là ou des références pouvaient sufir… Le code a été revu. Doc ici: https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/

Comme je disais sur le réseau social LinkedIn, contribuer au code source Windows, c’est exigeant, c’est un autre métier… On m’en a voulu pour ces paroles car on pensait que je critiquais les sociétés de services. Non… ce n’est pas ça. Le code review de Microsoft est impitoyable, rien n’est laissé au hasard. C’est impressionnant. Et pourtant, je fais du code review, je fais même du coaching en code review. C’est mon dada et bien là, je me suis retrouvé avec pleins de requests changes…

Un PR à moi: https://github.com/microsoft/terminal/pull/1161

Articles pour le magazine Programmez de Juin 2019

Nous avons écrit 5 articles pour le magazine n°230 Programmez de Juin 2019:

  • la première partie du Dossier .NET Core 3
  • un article sur SQL Server
  • la deuxième partie sur Azure Dev Ops

La suite du Dossier .NET Core 3 avec C# 8 et EF Core dans prochaine numéro de Juillet-Août 2019.

Aussi à paraitre en Juillet-Août un article sur “les techniques de Reverse Engineering”.

Welcome Léger D.

Bienvenue à Léger Djiba. Il est spécialiste en développement logiciel et est notre 26ème Ranger.

Originaire de Côte d’Ivoire, Léger est un développeur logiciel expérimenté.

Il maîtrise les sujets suivants:

  • BI
  • Biometrics
  • e-commerce
  • Microsoft. NET
  • JAVA
  • N-tier architecture
  • UML
  • AGILE(XP, Scrum, Lean)
  • open source technologies
  • Xamarin
  • Arduino 
  • Windows Phone

Welcome John D.

Bienvenue à John Dennison. Il est spécialiste en développement logiciel et est notre 25ème Ranger.

Originaire d’Irlande, John est un développeur confirmé qui possède de nombreuses années d’expériences dans le domaine du développement logiciel. Ses centres d’intérêts sont :

  • Performance
  • Fiabilisation
  • CI / CD
  • NoOps
  • BDD (Specflow)
  • micro services
  • DDD

Dossier .NET Core 3 pour Programmez de Juin 2019

La communauté des NET Azure Rangers contribue activement au dossier NET Core 3 de programmez de Juin 2019. En théorie, on partirait sur les bases suivantes:

  • Hamza : C# 8
  • Jean-Pierre : Support WinForms et WPF
  • Cédric M. : EF Core
  • Christophe P : ASP.NET Core
  • Christophe P : XAML Islands

Les NET Azure Rangers participent aussi sur 2 autres articles:

  • Laurent G. : Serverless
  • Jean-Nicolas B. : SQL Server, les indexes

A suivre…

Création logiciel, Hiérarchie et libre-arbitre

En réaction au post précédent Nous sommes tous des Architectes, j’ai reçu un commentaire sur LinkedIn qui disait cela:

<< Sébastien L. : Il y a un temps pour tout et une autorité pour tout. Le libre arbitre n’est pas possible dans une chaine hiérarchique car celle-ci serait rompue. La hiérarchie porte les responsabilités et décide. Il en est ainsi. >>

J’avais commencé de faire une réponse puis mon browser s’est fermé suite à une mauvaise manip et j’ai perdu mon texte. Voici la synthèse mieux écrite…

En matière de construction logiciel moderne, la notion d’autorité au sens primaire avec responsabilité et décision et relation maître-esclave n’existe pas. Construire un logiciel, c’est un travail d’ingénierie collaboratif. Ce n’est pas un travail à la tâche avec un patron et des ouvriers presse-boutons. L’armée ne sait pas faire et ne saura jamais faire un grand logiciel. Un logiciel est une construction de l’esprit fait par un ou plusieurs individus de manière collaborative. Cela peut être créatif ou scientifique mais cela reste un art. Le coup du “y a une chaîne hiérarchique qui porte responsabilités et décide !” est représentatif du système français et des SSII… Ce modèle est stupide. Avec cela, on fait de mauvais logiciels, sans qualité et sans âme que personne en veut utiliser… Les développeurs quittent le navire, le travail est médiocre et on tombe dans la caricature.

Un logiciel moderne, c’est une construction en légo. Il y a des centaines de briques. La responsabilité de la construction logicielle appartient aux Architectes et à eux seuls. Les design et le codage des briques est le domaine de développeurs. Comme vous le savez, un développeur est aussi un architecte.

Chaque développeur est autonome via:

  • sa capacité à designer les composants
  • sa manière d’implémenter les composants
  • sa vision de l’utilisation des composants qu’il veut donner

Ce n’est pas une personne qui possède le titre de chef de projet qui va expliquer au développeur comment il doit procéder, sur combien de temps, etc. Dans le monde du développement logiciel moderne, le terme de chef de projet n’existe plus ! Il a des gens qui coordonnent les réunions, s’occupe du planning mais n’ont aucune responsabilité dans l’architecture et le développement logiciel. Il ne fait pas autorité au sens propre. Cette notion de chef est bâtarde. Que ce soit dans les chiffrages ou dans les choix d’architecture, le développeur est autonome et se fait respecter. Ce n’est pas quelqu’un sorti de nul part qui va imposer un développement en x jours. Non non non ! Le développeur fait une estimation et c’est sur cette base que le planning se fait. Il peut y avoir des réajustements ou le chiffrage peut être optimisé mais ce n’est pas une relation hiérarchique: “code moi ça en x jours !”. Le chef de projet n’apporte aucune valeur ajoutée dans la construction logicielle contrairement aux architectes et développeurs. On lui demande bien parler et de bien communiquer mais il n’est pas le responsable hiérarchique de l’équipe. Il n’est pas qualifié pour cela.

La construction moderne d’un logiciel est orientée objet. Ce n’est pas simple et cela demande aux membres de l’équipe de modéliser et manipuler des quantités importantes de classes regroupées sous formes de hiérarchies et de savoir prendre du recul pour implémenter tous ses éléments sachant que des modifications dans une construction orientée objet alias OOP (interfaces, méthodes virtuelles, héritage de classes) peuvent être complexes et douloureuses…

La qualité dans le monde moderne n’est pas un option. Si un développeur réalise une construction de classes et que son utilisation est trop complexe, il doit y rajouter des choses, casses des choses, transformer et cela peut avoir des effets boules de neige. Seule la maturité du développeur permet de s’assurer qu’une implémentation est correcte la première fois sans avoir à y revenir après. Ceci n’est pas prévisible. La création de Test Unitaires via la conception permet de gérer cela. Cela veut dire qu’il faut prévoir ce temps de TUs.

Construire un logiciel via l’OOP c’est le fruit d’un travail scientifique de mise en relations d’éléments concrets issus d’abstractions et implémentés via des comportements dans des classes. On joue aux légos.

Y a ceux qui construisent les briques et y a ceux qui utilisent les briques. Ces deux catégories de développeurs ne font pas le même métier. Celui qui fait une brique réalise un travail de modélisation et met sa casquette d’Architecte et créé des classes. L’autre développeur ne fait que les utiliser… La travail collaboratif induit une communication permanente par exemple sur le confort d’utilisation des classes. Les interactions sont permanentes et un utilisateur de classe peut remonter un problème qui va nécessité au créateur de celle-ci de faire un fix ASAP et mettre à disposition une nouvelle version… cela peut provoquer des blocages.. Encore une fois, c’est un problème d’Architecture.

Quand une équipe est constitué d’éléments remarquables, il n’y a pas de hiérarchie. C’est la meilleur idée qui gagne. C’est le design le plus performant et le plus élégant qui l’emporte. Priorité à l’ingénierie.

Sans briser mon NDA avec Microsoft et mon accès au code source Windows, je peux vous dire que le code source de Windows, malgré son immensité est un travail d’orfèvre. On y trouve du C++ Moderne, des abstractions en pagailles, du code clean. Power & Peformance. Built on the metal !

Nous sommes tous des Architectes

Un bon développeur est aussi un architecte. On ne code pas n’importe quoi n’importe comment. Et pour cela, faut être formé. Dès que je vois une conférence chez Microsoft par exemple ou un nouveau book, j’invite mes connaissances professionnelles à y aller ou à lire cet ebook. Dernièrement, on me dit Pic, je peux pas lire ton ebook au bureau mon patron m’a fait la remarque… Là tu te dis, OK le monde fabuleux des PME a encore frappé… Par devant je suis Gold Partner Microsoft, un pure player mais la réalité c’et que tu dois pisser du code sans valeur ajoutée à la chaîne et que tu dois te former sur ton temps libre. Tu demandes un accès Pluralsight, c’est non. Tu lis des ebooks, c’est non. C’est quoi ces boites de m**** ? Au bureau, un consultant se doit de se former régulièrement, ça fait partie du métier. Tu veux être vendu à 350 € la journée ou à 1000 € ? Tu veux faire du .NET/C# à la pointe ? De la modernisation des Appz dans le cloud Azure ou du cloud-native ? Ah Oui Pic, la formation chez MS elle me servirait bien mais je peux, je suis en retard sur mon projet et si je m’absente, tu vois… Non je vois pas! Si ton patron qui ne te forme déjà pas, refuse que t’aille en séminaire, c’est un idiot. Change de job. Vite ! Améliore ton quotidien.

Les Rangers MVP

Microsoft MVP

Voici la liste des MVPs Microsoft:

  • [MVP Developer Technologies] Anthony Giretti
  • [MVP Azure] Cédric GEORGEOT
  • [MVP FoxPro] Frédéric Steczycki
  • [MVP Azure] Laurent Grangeau
  • [MVP Azure] Cédric Leblond
  • [MVP Azure] Cédric Derue
  • [MVP Developer Technologies] Gora LEYE
  • [MVP Developer Technologies] Christophe Pichaud