Archive

Articles taggués ‘QCon’

QCon London 2012 : « How GitHub Works »

How gitHub works



Parmi les présentations de QCon London 2012 celle sur l’organisation de GitHub était particulièrement intéressante. Retour sur les secrets de fabrication de la petite startup de San Francisco devenue le réseaux sociaux des développeurs open source.

GitHub a été lancé en avril 2008 et fonctionne depuis le début de façon distribué. En effet, les 4 fondateurs étaient chacun aux quatres coins du monde quand ils ont créés GitHub. Même si leur siège est à San Francisco, GitHub continue de recruter des développeurs partout dans le monde pour s’assurer d’avoir les meilleurs talents. GitHub prend bien soin de garder ses employés “happy”, et apparemment cela fonctionne plutôt bien puisque en 4 ans ils sont désormais 60 et toujours 0 démission.




Travailler de façons asynchrone
facilite aussi le travail distribué. Pour cela, toutes les communications passent par le chat ou les commentaires de pull request. L’idée est de limiter au maximum les réunions et les interruptions pour que les gens restent le plus longtemps possible dans “la zone”. La “zone”, c’est le moment où vous êtes hyper concentré sur une tâche et donc hyper productif. Dans notre métier il est parfois nécessaire d’absorber une importante charge cognitive (lecture et analyse) avant de produire quelques nouvelles lignes de code. Donc inutile d’ajouter des distractions et des interruptions alors qu’il est tellement difficile d’arriver à cet état de concentration.
Zach nous explique ensuite qu’il n’y a aucun horaire et que chacun est libre de venir travailler quand il se sent le plus productif. En effet, l’activité de développement requiert de la créativité et vous ne pouvez pas forcer les gens à être créatif pile entre 9h et 17h.



Du point vu de l’organisation, il n’y a pas de managers ou de chef de projets. Les équipes sont seules responsables de leur produit. Seule une ligne directrice est donnée par les 4 fondateurs. Après, libre à chaque membre de l’équipe de proposer et de travailler sur une nouvelle fonctionnalité si elle est reconnue comme intéressante par les autres membres de l’équipe.


Cette organisation peu habituel n’est rendu possible que par quelques facteurs important :

  • GitHub est une startup auto-financé et profitable depuis le début.
  • GitHub utilise GitHub. “eat your own dog food !”
  • GitHub est une société qui vend un produit.

Côté technique, là aussi c’est très intéressant. Du Ruby on Rails dans le cloud avec RackSpace. Ici encore, le mot d’ordre est de livrer la fonctionnalité le plus rapidement pour avoir le feedback le plus tôt possible. GitHub est redéployé entre 5 et 30 fois par jours !

Plusieurs techniques pour faire du continuous deployement sont utilisées.

  • feature branching.
  • Évidemment, comme on pouvait s’y attendre avec une entreprise reposant sur Git, les branches sont à l’honneur. Chaque nouvelle fonctionnalité fait l’objet d’une nouvelle branche. Mais attention, ne confondez pas avec les branches svn classiques que vous connaissez. L’idée ici est d’avoir une branche dont la durée de vie est très courte uniquement pour une feature qui doit rester simple. Les push (commits) sur la branche permettent d’avoir des codes reviews rapidement via l’interface GitHub.

  • super fast tests !
  • L’allié incontournable du continuous deployement, ce sont bien sûr les tests automatisés. Avec 8000 tests en 4 minutes, GitHub réduit très fortement les risques de régression à chaque redéploiement. Pour garantir dans le temps ce niveau de qualité et de réactivité un test lent est lui-même considéré comme une régression.

    Avec des déploiements aussi fréquent, il est nécessaire d’avoir du monitoring de qualité pour remonter au plus tôt les alertes. Les métriques donnent une perspective différente aux performances et permettent de cibler les points de contentions. Zach en profite pour nous montrer les métriques sur les clés ssh rejetées suite à la récente découverte d’une faille de sécurité majeure impactant tous les utilisateurs du site.

    Derrière le site Github, nouveau bastion des projets open source, se cache donc aussi une startup atypique. Elle rappelle fortement une autre société qui propose une organisation similaire : 37Signals, les créateurs du framework ruby on rails. Rien d’étonnant donc à trouver un post du CTO de Github expliquant comment ils ont suivi les judicieux conseils du livre de 37 signals, getting real, pour démarrer leur business.


    Ressources :

    GitHub
    How GitHub Works

    – Zach a écrit après la conférence sur sa façon d’écrire les slides. Je vous le recommande, car la forme était aussi bonne que le fond : Slides for developers

Categories: Divers Tags: , ,

QCon London 2012

Du 7 au 9 mars dernier, Objet Direct était présent à l’édition Londonienne de QCON, la conférence sur le développement logiciel propulsée par le site d’information InfoQ.

Avec 700 participants,  6 sessions en parallèles et 100 présentations programmées, l’événement a réunit de nombreux speakers de renommée internationale tels que: Martin Fowler, Greg Young (Domain Driven Design et CQRS), Dan North (Behavior Driven Development), Rich Hickey (Inventeur du langage Clojure).

Les sujets phares de cette année étaient le NoSql, porté par la keynote de M.Fowler, les architectures mobiles, le web et HTML5, les architectures scalables et sans oublier devops.
Mais surtout un élément commun qui ressortait de nombreuses talks était la recherche de la simplicité dans les architectures dans le but de livrer toujours plus de valeurs à nos clients.
Les keynotes de Rich Hickey et de Greg Young y étaient d’ailleurs dédiées.

L’occasion durant ces 3 jours de prendre du recul sur notre métier et de faire le point sur les dernières innovations et les bonnes pratiques d’architecture. Avec autant de contenu, impossible de revenir sur tout. Je vous propose donc un petit tour des sujets et conférences qui m’ont le plus marqué.

Lire la suite…

QCon London 2011

Petit article sur une série de conférences qui a lieu sur Londres du 9 au 12 Mars 2011 : la QCon London.  Pour rappel, la QCon est organisée par InfoQ, une communauté indépendante sur l’Internet axée sur la veille, l’innovation technologique et l’agilité..

Les conférences révèlent les grandes tendances dans le monde, à savoir le Cloud, la mobilité, les bases de données NoSQL, HTML5 et enfin les nouvelles méthodes de gestion de projets  telles que Lean et Kanban. D’ailleurs, la première journée s’est ouverte par une excellente conférence de Craig Larman. Il  nous a exposé ses retours d’expériences, ses points de vue et les bonnes pratiques à adopter vis-à-vis de Lean et de son utilisation dans des gros projets nécessitant de nombreuses équipes réparties dans le monde. Grosso modo, il faut monter des petites équipes (d’environ 10 personnes) polyvalentes avec une personne par site qui orientera les personnes des autres sites vers le bon interlocuteur, et surtout utiliser la visioconférence, car « voir, c’est croire ».

Nous avons pu également avoir un aperçu du futur de Java. Ce dernier se repose sur deux dates : fin 2011 et fin 2012. Nous devrions voir arriver d’ici la fin de l’année le très attendu Java 7, dont le numéro pourrait refléter le nombre d’années de retard. Celui-ci s’orientera principalement sur une modification de la JVM afin qu’elle puisse supporter plus facilement des langages pur objet tel que Ruby, et aussi sur une meilleure gestion du traitement en parallèle, grâce à l’api java.util.concurrency. Fin 2012 verra la naissance de Java 8 qui apportera plus de nouveautés dans le langage avec les très attendues lambda fonctions, quelques nouveaux sucres syntaxiques pour facilité l’écriture, et aussi un mécanisme intéressant pour enrichir les interfaces sans impacter les implémentations (en proposant une implémentation par défaut, un peu comme les valeurs par défaut dans les annotations).

Nous avons pu également apprendre sur les futures orientations choisies pour JEE7. Celui-ci s’oriente naturellement vers le cloud (privé ?) avec la virtualisation du serveur d’application. Un exemple nous a été donné avec le serveur GlassFish 3.1 où avec un simple fichier déclaratif « cloud.xml », nous pouvions spécifier le nombre minimum d’instances de GlassFish sur lesquelles déployer l’application. Nous avons assisté au déploiement de l’application sur les 3 serveurs d’application et au monitoring de leur activité. A noter que chacune des instances était placée dans une machine virtuelle (certainement gérée par VirtualBox de Oracle).JEE7 améliorera aussi l’isolation des applications, gèrera la coexistence de versions différentes d’une même application. Un support d’HTML5 est prévu, comme le support du JSON, des WebSockets (déjà planifié pour JSF 2.2), des nouveaux types de champs pour les formulaires.

Ses conférences ont aussi été l’occasion de rencontrer des gens de FaceBook. Ils nous ont parlé de l’utilisation d’HTML5 pour la version mobile de leur site (et de la création de la communauté WURFL pour référencer les spécificités de chaque mobile sur l’HTML). Les gens de Twitter nous ont parlé de la gestion de leurs données et de leurs volumétries extrêmes (près d’un milliard de tweets sont enregistrés par mois, ce qui représente pas loin de 300 Go de données). Nous avons pu aussi compter sur Google qui nous a expliqué leurs démarches par rapport à l’innovation avec la mise en avant du « pretotyping ». Son but  : voir si l’intérêt des gens par rapport à une idée se maintient dans la durée Cela consiste à « créer » une maquette très simpliste. Le cas plus célèbre est celui du créateur du Palm qui avant de créer le 1er appareil avait fait des fiches sur un carnet pour représenter son interface et tester son idée en simulant les actions courantes.

Nous avons aussi assisté à une conférence de Netflix expliquant la stratégie retenue pour migrer des données d’une base Oracle vers une base NoSQL. L’infrastructure retenue fut celle d’Amazon. La migration a pris environ 2 ans. Ils ont du redévelopper un certain nombre de services de base comme la sauvegarde / restauration. Ils ont commencé avec SimpleDB et continué avec Cassandra. La conférence a été l’occasion d’un retour d’expérience très riche au travers de la présentation de nombreuses bonnes pratiques. La présentation est disponible ici : http://qconlondon.com/london-2011/file?path=/qcon-london-2011/slides/SiddharthAnand_NoSQLNetflix.pdf

Les slides peuvent être téléchargés sur le site de la QCon (http://qconlondon.com) et sur le site d’InfoQ, vous pourrez voir dans les semaines qui arrivent les vidéos prisent lors des conférences.

Julien Roche & Philippe Guédez

Categories: Actualités, Divers Tags: , , , ,

JAOO/GOTOcon Aarhus 2010 – Retour global

JAOO

JAOO

Whooosh … ça décoiffe, au sortir de cette conférence j’ai l’impression d’être dans une de ces boules à neige (qui colle bien avec l’image qu’on se fait du Danemark qui plus est :-)) : on vient de secouer plein de choses et il faut maintenant attendre que les flocons se posent. Dans ma tête… et surtout sur le marché : qui travaille avec Git chez son client ?
En effet la conférence (Java And Object Oriented) qui s’annonçait de développeur à développeur n’a pas (plus autant ?) les pieds sur terre, d’où son changement de nom en gotocon (je n’ai toujours pas compris ce nouveau nom d’ailleurs… faire fuir les développeurs ?), plus particulièrement au vu du contenu du premier jour de conférence où Java était… absent !

Par contre, sur le côté novateur (pour notre réalité bien sûr, pas pour Google, Twitter et cie)  de cette conférence, petite soeur du QCon, est très intéressant. On y retrouve tous les sujets les plus récents que l’on peut suivre sur twitter et la blogosphère. On change ici totalement de monde : on est dans l’univers des leaders de pensée, déconnectés de notre réalité quotidienne. Les sujets majeurs tournent autour des grands du web dont on peut/doit prendre des idées mais qui resteront difficilement vendables à court terme dans notre réalité.
Un point très appréciable néanmoins: malgré cette volonté de ne montrer que des sujets de pointe, on a quasi systématiquement un rappel assez complet de l’historique du sujet.

Pour ma part, le message que je retiendrai de cette conférence (que ce soit pour les sessions que j’ai pu suivre ou non) c’est que ces gens, en avance (où sommes nous en retard ?) sur leur temps se battent contre 2 mastodontes qui a leur sens entravent la productivité :

  • Les méthodologies lourdes dont certaines applications de Scrum notamment quand la méthode est mal utilisée voire incomprise (le backlog semble être dans la ligne de mire des prochaines évolutions de l’agilité)
  • Java qui n’a pas (réellement) évolué depuis 6 ans et qui peine à évoluer (cf. le plan « B »)

Des retours plus précis suivront ce billet d’introduction … à bientôt !

QCon London 2010 – Udi Dahan – Avoid a Failed SOA

“Business & Autonomous Components to the Rescue”

image Malgré un sujet pas très original, avec peu d’idées réellement neuves, probablement la meilleure présentation à laquelle j’ai assisté aux QCon 2010 de Londres. J’y ai été particulièrement sensible, du fait que j’ai moi-même réalisé et animé des séminaires sur des sujets similaires. Et j’ai pris une leçon, sur la forme comme sur le fond.

Sur le fond, finalement, un seul message simple est véhiculé par Udi Dahan : une condition nécessaire à la réussite d’une SOA c’est l’émergence de composants très faiblement couplés. Pas vraiment une surprise. Mais c’est grâce à une forme étudiée que son discours (simple mais pas simpliste) amène à se poser des questions profondes.

Sur la forme donc, un discours extrêmement clair sans utilisation d’aucun buzz, et un enchaînement logique des idées qui mène inexorablement l’auditoire à ses conclusions inéluctables. Quand la vidéo de cette présentation sera en ligne sur InfoQ (malheureusement, ils les distillent pendant six mois), ne la ratez pas.image

Je vais tenter de résumer.

Le sujet c’est le projet d’intégration. Pourquoi ça rate souvent, et comment faire que ça rate moins :-) On a le droit de se tromper plusieurs fois, mais à chaque fois différemment !

La présentation oscille autour de l’architecture entre la vision métier et la vision technologique.

SOA et couplage faible

Un des objectifs de la SOA est d’atteindre un couplage faible entre composants métiers autonomes. Tout le monde est d’accord là-dessus. Mais ce couplage faible doit être une exigence à la fois métier et technique qu’il faut prendre en compte à la conception comme à l’exécution.

imageUdi part d’un SI théorique plutôt bien aligné sur le métier (avec une véritable architecture fonctionnelle explicite) dont on pourrait se dire qu’il est facilement “SOAisable”.

Il montre qu’une intégration des applications par des services (une SOA) peut, en fait, mener facilement à des applications très fortement couplées qui amènent, en production, leur lot de contentions (mémoire, threads, locks base de données…) .

So what ? Qu’est-ce qu’on a loupé ?

On a oublié que pour obtenir le découplage à l’exécution il faut des communications asynchrones (d’un point de vue fonctionnel et pas seulement technique). Et il y a de fortes conséquences sur… la conception.

Il faut donc basculer du requête/réponse à la publication/abonnement (d’une architecture orientée services vers une architecture orientée événements). C’est la succession d’émission d’événements qui matérialise le processus et non l’orchestration d’appel de services. Et c’est l’émetteur qui définit le contrat de service et non le receveur. On parle d’Event Driven Architecture (EDA).

Mon avis

Même si ce qui vient d’être dit est parfaitement logique en terme d’affectation de responsabilités, la plupart des démarches de conception travaillent dans l’autre sens : le contrat de service est défini à partir du besoin du client du service (c’est ce qu’on fait quand on fait de la conception d’application : c’est le scénario d’utilisation qui définit les services publiés par le serveur métier). Il faut donc changer radicalement son mode dimagee conception lorsqu’on fait de la SOA/EDA : les contrats de service doivent être définis uniquement par les changements d’état des objets métier et non par les “clients” de ces changements d’état.

Autre réflexion que m’inspire cette vision (originale) de ce qu’est un processus SI : un enchainement infini d’événements. On ne peut plus définir un Processus avec un début (l’Evénement déclencheur) et une fin (un Produit de sortie) créant de la valeur pour son Client. C’est une révolution conceptuelle (on remet en cause la définition d’un processus selon l’ISO !) et surtout, ça pose un gros problème. Comment appliquer la doctrine millénaire du consultant en processus : “centrer les processus de l’entreprise sur le client”, si le client de l’entreprise n’est plus le client du processus ? Je n’ai pas de réponse pour le moment :-)

Composants métier autonomes

Udi Dahan évoque ensuite une autre question délicate. Comment partitionner les services en composants autonomes ? A nouveau, une réponse évidente est : aligner les composants sur le métier. Un composant métier par bloc fonctionnel. Un rêve d’urbaniste !

Il montre qu’en fait, ce partitionnement “idéal” ne répond pas toujours au besoin et  imageparticulièrement aux exigences non fonctionnelles. Il donne l’exemple des SLA différents en fonction du type de client et propose donc des composants métier autonomes techniquement (potentiellement très différents dans l’implémentation), définissant les mêmes contrats de service mais implémentés différemment.

Mais à nouveau, comment éviter un couplage si, finalement le routage des événement doit se faire en fonction de leur contenu (l’événement contenant un “petit client” doit être routé vers le composant dédié petit client, l’événement “gros client” vers le composant dédié gros client).

Le fonctionnement EDA précédent permet, à nouveau, à chaque composant d’être autonome dans la prise de décision : tous les composants d’un même métier sont abonnés aux mêmes événements et chacun décide de manière autonome de traiter ou non un événement particulier en fonction de son contenu.

A bientôt pour d’autres conférences QCon.

Categories: Web Services - SOA Tags: , , , ,

QCon, Modèles et Intégrisme

This post is available in english on my personal blog.

QConJe rentre juste de trois jours aux QCon de Londres. C’est comme toujours un grand moment permettant une véritable prise de recul. Je peux respirer, ouvrir les yeux sur ce que font les autres et comment ils travaillent, sentir quelles sont les tendances et surtout, tenter d’appréhender ce que sera mon job dans un an, voire, plus loin.

Promis, je vous ferai, dans les jours qui viennent, une compilation des meilleurs moments de la conférence et des points les plus marquants. Mais avant tout, je voulais vous faire une réaction à chaud sur quelque chose qui me semble important.

Je reviens aujourd’hui avec un goût désagréable dans la bouche (non ce n’était pas la bière qui était, comme toujours, excellente). Un goût amer et un peu de colère aussi.

En deux mots : la modélisation n’est plus simplement absente (comme c’était pratiquement le cas lors des deux dernières éditions), c’est devenu un gros mot.

Que le code soit à l’honneur, c’est bien naturel dans une conférence consacrée au développement. Que l’on fustige les erreurs commises par le passé (en particulier la “sur modélisation” symptomatique d’un déficit de confiance dans les processus de développement) me semble aussi plutôt sain.

Mais que l’on entende des sentences définitives du genre “comme chacun le sait, les modèles ne servent absolument à rien” dans la bouche de stars comme Robert C. Martin, alias Uncle Bob (qui a pourtant écrit en 2003 un remarqué “UML for Java Programmers” !), qu’un Dan North (par ailleurs excellent, je vous en reparlerai) considère l’usage d’un modeleur comme une inutile “complification”, relève de l’hypocrisie, de la démagogie ou de l’intégrisme (voire de la simple bêtise, indissociable du dernier).

La seule conférence à laquelle j’ai assisté qui faisait encore la part belle aux modèles était celle d’Eric Evans qui parlait de conception agile. Encore avait-il rayé le mot Modèle du titre, pour celui de Design plus consensuel. C’est lui qui a, d’ailleurs, eu le mot juste : en abandonnant la modélisation, la communauté du développement a, un peu trop rapidement “jeté le bébé avec l’eau du bain” (sic).

En fait, j’ai eu l’impression d’être dans le domaine du religieux et d’assister à des professions de foi.

Il y a, d’un côté, les fondamentalistes du code, pure monothéistes, nostalgiques d’un âge d’or mythique où le développeur était le seul maître de sa production, en relation directe avec Dieu (le Product Owner), dépositaires d’un savoir millénaire (le Software Craftsmanship) qui se transmet de bouche de gourou à oreille de disciple.

Et il y a la secte des UMListes, vus comme de dangereux illuminés schismatiques, dont les délires auraient corrompus le monde parfait des précédents et qu’il faut exterminer par tous les moyens. J’ai eu l’impression d’être soumis à une fatwa.

Comme toujours lorsqu’il y a des problèmes, il faut trouver des boucs émissaires. Les modèles (et ceux qui les font) semblent jouer ce rôle aujourd’hui : symboles du “Big Upfront Design”, c’est eux qui portent la responsabilité des échecs des grands projets. Les modèles sont vus comme des artefacts de pure documentation : modéliser serait une activité chronophage et inutile (voire perverse), en particulier dans un monde agile.

Dans un tel environnement, impossible de sortir ma carte de visite : sous mon nom, il y a marqué “MDA business line manager”. Comme une maladie honteuse.

Pourtant, il me semble que modéliser, au contraire de développer, permet :

  • d’analyser un problème,
  • de compresser sa complexité,
  • d’appréhender sa globalité,
  • de s’abstraire de contingences techniques,
  • de communiquer.

Mon cerveau n’est pas suffisant pour faire tout ça sans assistance. J’ai besoin d’UML (ou de tout autre formalisme), à la fois comme d’une béquille, d’un tableau blanc, d’une extension de mémoire et d’un formulaire de maths.

Modéliser n’est pas antagoniste de développer (sans parler de MDA qui combine les deux activités) : modéliser permet simplement de mieux développer.

Et d’ailleurs, le code EST un modèle (“système d’abstractions qui décrit des aspects sélectionnés d’un domaine”), au même titre qu’un diagramme UML. Juste un peu plus verbeux (et un peu plus facilement exécutable).

Pour conclure, il me semble que ce hiatus est, avant tout, très représentatif de modes de pensées différents : une pensée analytique “à la française” (après tout, Descartes et Merise sont des créations bien de chez nous) face à une pensée pragmatique anglo-saxonne.

J’aime à penser qu’il y a du bon dans les deux mondes et que les deux se complètent agréablement. C’est même ce qui, à mon avis, constitue l’intérêt principal de notre métier : analyser des problèmes pour informatiser leur résolution. C’est ce qui quotidiennement renouvelle ma motivation : comment faire rentrer dans un (bon) programme la complexité du monde réel.