Après une introduction, voici un compte-rendu de ma première matinée à l’USI 2013. Le thème de cette demie journée est « Ailleurs« .
Au programme :
- Patterns of Software Change par Michael Feathers
- LinkedIn : the Serious Network par Stéphane Distinguin
- The Cloud Computing par Amazon Web Service, de Adam Selipsky
Je commence par une présentation sur les modèles de changement d’architecture logicielle par Michael Feathers. Consultant indépendant, c’est l’auteur entre autre de « Working effectively with Legacy Code« . Son expertise s’est forgée aux cours des années sur le suivi de plusieurs gros projets. Il y a un contraste entre ce que le logiciel devrait être et ce qu’il est vraiment. Pour reprendre l’image de Neal Ford présentée il y a quelques années à l’USI, imaginez-vous dans un MacDo. La spécification, c’est la belle photo du hamburger, bien épais et apétissant. L’implémentation c’est finalement le machin tiède que l’on vous amène dans une boîte en carton. Il en va de même pour le décalage entre la spécification et l’implémentation.
Au fil des années, les méthodes de gestion de projets ont évolué. D’ailleurs, on ne présente plus le Lean, l’Agilité ou TDD. Mais cela ne change pas le problème du « vieux code ». Selon Michael, l’Architecture c’est la partie du logiciel que l’on ne peut pas changer sans avoir ensuite un nouveau système. Martin Fowler disait plutôt que l’Architecture, c’est ce qui coûte cher à modifier.
Ce que j’ai retenu c’est d’abord la vision et ensuite les méthodes qui permettent de gérer du code Legacy. L’auteur prend pour image une plante, puis un jardin qui n’aurait pas été suffisamment entretenu. Il parle d’Organic Pattern. Si le tronc de l’arbre ne peut pas être coupé, il faut élaguer et entretenir les branches, sur lesquelles le nouveau code viendra se poser.
Parmi les patterns, il cite celui de « Single Responsibility principle« , théorisé par Uncle Bob (Bob C. Martin) et dans la conception orientée objet. Il faut donc retenir qu’un code-base doit être entretenu en permanence. Il y a toujours quelque chose à faire. Je pense que c’est vrai pour beaucoup de projets sur lesquels j’ai travaillé.
L’autre idée que j’ai retenu de sa présentation c’est l’idée d’observer les commits et l’activité du repository. Il y a des outils d’analyse statiques et dynamiques comme ceux de SonarSource. Mais ici il présente quelques idées intéressantes, en s’appuyant uniquement sur l’historique des commits d’un projet.
Vous pouvez par exemple voir quelles sont les 5 classes les plus modifiées. Ne faut-il pas diviser vers différents fichiers pour faciliter la maintenance ? Vous pouvez voir aussi si un fichier a été récemment modifié ou si cela fait 2 ans que personne n’y a touché. Vous pouvez aussi essayer de voir quels classes sont souvent modifiés ensemble. Par exemple vous découvrirez que la class Inventory est souvent modifiée en même temps que la classe Order. Ceci vous permet de vérifier le couplage et votre domaine.
Il cite un moment les tests et parle d’un sujet encore tabou : la dictature du test. Il y a ceux qui ne testent pas. Il y a ceux qui testent absolument tout. Les plus dangereux sont ceux qui refactorent le code existant pour pouvoir faciliter les tests.
Nan mais allo quoi... ton métier c’est d’écrire du test ou d’écrire du code métier ?
La couverture des meilleurs projets open-source n’excède pas 80%. Et encore, lorsqu’il s’agit de librairies ou de frameworks, je pense que cela n’a rien à voir avec votre application de gestion. Testez, mais ne perdez pas de vue qu’il faut aussi coder une application et créer de la valeur. J’ai noté d’autres idées, comme l’évolution du code en permanence, la vision biologiste du code de son application, et enfin quelques rappels comme la fameuse loi de Melvin Conway de 1969.
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
Le temps de discuter avec quelques geeks, je file écouter la présentation de Stéphane Distinguin, de Faber Novel sur LinkedIn.
Est-ce que vous connaissez l’acronyme GAFA ? Cela designe Google-Apple-Facebook-Amazon. Si ces 4 grands sont bien identifiés sur Internet, nous allons voir le potentiel de LinkedIn. La vision de Stéphane Distinguin est que LinkedIn est un grande en devenir. La mission de LinkedIn est de connecter les professionnels du monde entier. La moyenne d’âge des utilisateurs de LinkedIn est autour de 41 ans. 80% des personnes inscrites sur LinkedIn ont plus de 35 ans. 69% des utilisateurs ont un revenu supérieur à 60kUSD par an… Bref cela n’a rien à voir avec la population de Facebook.
D’ailleurs, une autre étude montre que les utilisateurs de LinkedIn ne passent que 20% de leur temps par mois sur le réseau pour l’instant, contre plus de 7h par exemple pour les utilisateurs de Facebook. LinkedIn est cependant bien valorisé, et une étude économique montre que la valeur moyenne de l’utilisateur LinkedIn est de 81 USD contre 50 USD pour Facebook. Bref LinkedIn ne viste pas le volume mais la valeur.
La vision de LinkedIn est de devenir une plateforme pour faire du « Business as a Service ». Il s’agit de mettre en relation des professionnels, et d’aller au delà du recrutement. Pour cela, la plateforme a 3 propositions de valeur : le recrutement, la mise en relation et enfin le contenu. Vous ne l’avez peut-être pas noté, mais LinkedIn s’intéresse à vous pour vous pousser du contenu « qualifié » et augmenter aussi le temps que vous passerez sur le site. D’ailleurs, LinkedIn a racheté SlideShare, Pulse et Maybe? (sondages sociaux). L’objectif est de livrer du contenu venant d’influenceurs.
Pour la partie recrutement, LinkedIn a ajouté les talents/compétences. Au passage, ceci permet de savoir ce qui vous intéresse… et de vous vendre plus tard du contenu sponsorisé susceptible de vous intéresser. Vous pouvez aussi pousser du contenu sur LinkedIn, comme par exemple un article de Blog. Si votre contenu est plébiscité, vous devenez un influenceur capable de créer du contenu qualifié.
LinkedIn consacre 25% de son C.A à la recherche et au développement. Pas si étonnant lorsqu’il s’agit de développer la plateforme. Il y a bien eu quelques soucis de sécurité en juin 2012 avec des mots de passes volés, ou des histoires de surveillance d’employés par des entreprises indélicates… mais globalement pas de grosses casseroles.
J’ajouterai que LinkedIn est profondément Java. Depuis le départ.
Et je vais vous raconter pourquoi. En février 2003, je suis à Palo-Alto pour quelques semaines pour être formé sur un logiciel de Reuters. Il se trouve que la personne qui me forme, car il quitte la société, est un autre Français, Yan Pujante. En partant en mars, il me raconte cette aventure de LinkedIn, sur laquelle il travaille avec quelques personnes depuis plusieurs mois. Au moment où il me raconte cela, Facebook n’existe pas encore. Il part quelques temps plus tard… Et je crois avoir été dans les premiers utilisateurs à l’été 2003… Il y a 10 ans…
Bref LinkedIn a le potentiel pour devenir un réseau global de mise en relation entre professionnels.
Bonne présentation de Stéphane Distinguin.
Il est temps de descendre maintenant dans le grand amphithéâtre pour écouter la 2eme keynote de l’USI 2013 par Amazon.
Adam Sepilsky est Vice-Président Produit, Marketing, Vente & Support.
Voilà…. mais ne partez pas car vous allez apprendre quelques trucs sur AWS.
Amazon s’est lancé dans le développement d’une plateforme mutualisée, sans que cela soit pensé comme du Cloud Computing. Cela commence vers 2000, il y a presque 13 ans. Rapidement Amazon développe des solutions en interne pour installer des machines, répartir la charge, faire des sauvegardes, etc. Le souci c’est que fin 2004/2005, une étude interne montre que les ingénieurs systèmes passent 70% de leur temps à faire des tâches sans valeur ajoutée, et 30% à contribuer à la valeur de la plateforme. Il fallait rationaliser et penser à un nouveau modèle. L’idée est de renverser cette tendance. Au lancement le 14 mars 2006, cela démarre tout d’abord avec le stockage et Amazon S3. Le succès est très rapide, les développeurs en veulent plus. D’année en année, Amazon ajoute des fonctionnalités, avec aujourd’hui presque 159 fonctions différentes.
Amazon AWS en 2013 c’est 8 régions, 25 zones de disponibilités et 36 locations dédiées. Une région correspond à plusieurs centres de données. En 2003 cela occupe 800 employés d’AWS et correspond à 5 millions. En 2007, plus de 330 000 développeurs utilisent déjà AWS. En 2009, le petit Nicolas (c’est moi) participe à sa première conférence de l’USI et écoute déjà une présentation sur AWS…
On estime à 1.5 Milliard de dollar le revenu généré par AWS, quoiqu’il soit difficile de connaître ces chiffres.
AWS est utilisé par des sites comme AirBnB, FourSquare, Netflix ou Spotify. Il y a différentes motivations et type d’utilisation. Il y a ceux qui mettent l’ensemble de leur infra sur Amazon, comme Netflix. Il y en a d’autres qui n’utilisent qu’une partie, comme Amazon S3 pour les images ou CloudFront pour la fonction CDN. Netflix est un exemple intéressant avec presque 10 000 machines, plus de 70 millions d’événements par jour. Lors des pics d’utilisation de Netflix (plateforme qui vous permet de regarder à la demande des films et des séries aux USA), un tiers de la bande passante est consommé par Netflix. Le volume représenterait plus d’1 Petabyte (soit 1 048 576 Go).
Ce que l’on retient c’est qu’Amazon AWS est vraiment un fournisseur de machines et surtout de services. Il faut regarder AWS avec une vision infrastructure.
Il est maintenant temps de déjeuner et de discuter avec tout le monde, avant d’aller écouter ensuite Jean-Pierre Raffarin, ex-Premier ministre, qui viendra parler de géopolitique et d’économie.
La suite dans un prochain numéro.
