OCTO a accueilli mardi 21 mai la première session du PerfUG à laquelle 25 personnes ont participé. Ci-dessous, le compte-rendu de cette soirée.

Marc Bojoly a commencé par un rappel des objectifs du PerfUG, avant de définir les différents types de tests : performance, charge, rupture et vieillissement.

Puis l’accent a été mis sur les tests de charge et de performance : méthodologie, pistes d’optimisation et outils.

Henri Tremblay a ensuite pris le relai pour la partie travaux pratiques. Sur la base d’une application Java standard, nous avons déroulé un tir de performance et un tir de charge avec Gatling, puis analysé et commenté leurs résultats.

La session s’est terminée par de sympathiques et fructueux échanges autour d’un buffet en terrasse !

Ci-dessous, un petit aperçu en image !

Retrouvez l’ensemble de la présentation sur slideshare !

Ne réaliser que peu ou aucun développement en interne, mais les externaliser à des prestataires est un contexte d’entreprise fréquent. Ces prestataires peuvent être de natures assez hétérogènes, allant de l’agence web au cabinet de conseil, en passant par la grosse SSII. Tous ces prestataires développent des produits chez eux en utilisant leur propre UDD (ou non), et livrent l’application packagée, chacun à leur façon. Un souhait légitime de reprendre la main sur le code et sur toute la phase de compilation et d’analyse qualité émerge nettement chez plusieurs de ces entreprises. Les douleurs peuvent être multiples : une volonté d’indépendance vis-à-vis des prestataires, des régressions dans les livraisons, un release management hétéroclite voire inexistant… En analysant le besoin – des sources à livrer, compiler, analyser et déployer – l’outillage classique d’une UDD apparait comme une évidence. Toutefois, on observe aussi clairement qu’il s’agit là d’une variante fonctionnelle de l’usine de développement. En effet, les prestataires continuent d’utiliser leur propre outillage pendant la phase de développement, mais une fois cette phase terminée, ils livrent le code sur cette nouvelle plateforme qui peut alors le compiler, l’analyser suivant les règles de l’entreprise, le packager, le déployer, etc… C’est ainsi qu’émerge le concept d’Usine De Livraison.

Ce type de situation impose généralement certaines contraintes :
• Le prestataire doit avoir un accès simple aux outils mis à disposition
• Les technologies doivent être accessibles par des prestataires de multiples horizons (SSII, conseil, intégrateurs, agences web…) avec différents niveaux de compétences techniques
• Chaque livraison doit pouvoir être qualifiée puis déployée sur les environnements adéquats
• Ces actions doivent solliciter aussi peu d’actions manuelles que possible

D’autre part, nous distinguons 2 types d’outils dans l’UDL :
• Les outils techniques, destinés à stocker le code, le compiler, l’analyser…
• Les outils de partage et de processus entre les différents acteurs des projets

Les outils techniques

On retrouve dans cette partie tous les outils que l’on trouve dans une UDD classique. Nous n’insisterons donc pas sur ceux dont l’utilisation ne varie pas dans notre cas de figure.
Certaines de ces briques doivent être accessibles aux prestataires, mais ce n’est pas indispensable pour la plupart d’entre elles.
Dépôt de code
Le gestionnaire de code est destiné à recevoir la livraison des sources d’un projet. Le prestataire livre son code sur le dépôt une fois ses développements terminés. En revanche, ce dépôt n’est pas destiné à recevoir les commits de code incrémentaux de la phase de développement. Cette usine ne fait pas office d’usine de développement, qui est laissée à la discrétion du partenaire. Le partenaire livre donc le code d’une application complète et réputée stable en le poussant sur le serveur. Plus qu’un simple dépôt, cette brique fait donc office de point d’entrée de toute livraison et doit être suffisamment ouverte pour que les prestataires puissent y accéder de l’extérieur.

Orchestration de tâches

L’orchestrateur de tâches permet de planifier les différentes tâches nécessaires aux mécanismes de l’UDL (compilation, analyse qualité, déploiement,…). Une 1ère tâche du type continuous deployment permet de détecter toute nouvelle livraison de code, puis de compiler et déployer l’application sur l’environnement adéquat. Une autre tâche, qu’on préfèrera laisser manuelle, peut permettre le déploiement sur les autres environnements (recette, préproduction, production…). Enfin, comme pour toute UDD classique, une tâche du type nightly build peut générer les rapports de test et de qualité.

Analyse de code

Ces outils permettent de parcourir le code livré et d’exécuter les tests unitaires associés pour générer des rapports qualité.

Référentiel d’artefacts

Une telle brique permet de partager des librairies communes entre les différents projets.

Les outils d’échanges

Wiki

Un wiki est indispensable pour partager toute la documentation de l’UDL avec le prestataire. Il décrit les différents processus, les guidelines et les outils que le prestataire doit comprendre et utiliser.
Il permet aussi de centraliser les échanges entre client et prestataires. Ainsi, lorsque l’un des prestataires a livré du code, il peut accéder à l’espace wiki dédié au projet pour y créer une fiche de livraison. Cette fiche peut renseigner toutes les informations techniques nécessaires au déploiement de l’application (exécution de scripts SQL, batchs…). Cet outil doit donc proposer un accès extérieur pour les prestataires.

Ticketing

Un outil de ticketing permet de centraliser et uniformiser les demandes entre l’entreprise et ses prestataires. La gestion des anomalies et des évolutions peut alors être entièrement gérée par l’outil. Ici aussi, l’accès ne doit pas être restreint au réseau de l’entreprise.

Mise en oeuvre

Dans ce type de chantier, la difficulté réside dans l’harmonisation et l’évangélisation des pratiques à travers les différents prestataires. En effet, une UDD implique de configurer des outils pour répondre aux besoins induits par la nature des développements. Une UDL, au contraire, impose de modeler ses développements pour qu’ils soient compatibles avec les outils mis en place.
Une première solution est de laisser aux prestataires le soin de configurer leurs tâches Jenkins pour plus de souplesse et de flexibilité. Cela permet de faire tendre l’organisation vers un fonctionnement orienté DevOps. Si cette approche est séduisante en théorie, sa mise en pratique impose une volonté d’ouverture de l’entreprise et une maturité avancée des prestataires. Une entreprise ayant affaire à plusieurs dizaines de prestataires, dont la nature et la qualité des développements s’étalent sur un spectre très large aura du mal à appliquer une telle démarche.

Une seconde solution plus pragmatique dans cette situation consiste à mettre en place des pratiques qui constituent le dénominateur commun entre tous les projets pour les rendre compatibles à l’UDL. Ces pratiques sont de plusieurs natures :
• Adhérence à l’écosystème du client :
Selon la typologie du projet, des technologies sont présélectionnées (par exemple, une web applications Java pour du transactionnel et iOS natif pour du mobile)
• Uniformisation des outils :
Les outils d’aide à la compilation sont imposés selon la technologie (par exemple, Maven, Gradle, CocoaPods, etc.)
• Structure du projet :
Afin de d’assurer la lisibilité et la maintenabilité d’une application, l’entreprise peut définir des structures squelettes par typologie de projet (l’équivalent d’archétypes Maven) pour les technologies où cela est pertinent.
• Minimum Buildable Product :
Afin de s’assurer de la conformité de la configuration d’un projet, on peut demander aux prestataires de livrer au plus tôt une version minimale de leur application. Celle-ci ne doit pas forcément répondre au moindre besoin fonctionnel, mais valider que la stack technologique appliquée est bien adaptée aux exigences de l’UDL.

Ce fonctionnement impose d’être en veille permanente pour ne pas imposer une technologie obsolète, orpheline ou peu répandue. Pour Android par exemple, la technologie Ant peut être la plus indiquée car la plus répandue dans un premier temps. Il est toutefois possible que Maven devienne rapidement la technologie de prédilection. Il faudra alors adapter l’UDL en conséquence.

D’autre part, il faut prendre garde à ne pas s’enfermer dans les langages choisis au départ et se laisser la possibilité d’ajouter une technologie à l’UDL si nécessaire. Si l’on juge qu’une nouvelle technologie doit être ajoutée à l’écosystème de l’entreprise, il faut alors faire l’état de l’art des meilleures pratiques, en tirer des guidelines, créer des modèles de tâches correspondants et appliquer tous ces éléments sur un projet pilote, avant d’en généraliser l’usage.

Bilan

Chez OCTO, nous avons déjà eu l’occasion d’implémenter un tel pattern, cela a été très enrichissant et relativement fluide. Le principal risque identifié est une réaction de rejet face à un changement d’usage aussi radical. Pour faciliter au maximum la transition vers ce mode de fonctionnement, il est important d’impliquer les prestataires dans la conception et le montage de l’UDL. Il faut également le sensibiliser aux améliorations notables qu’elle constituera une fois le projet migré et procéder à la migration par étapes successives. D’autre part, les chefs de projet côté entreprise doivent aussi être impliqués au plus tôt dans le chantier pour qu’ils puissent en saisir les principes et y adhérer pleinement. En effet, ce sont eux qui seront par la suite les moteurs de l’implication des différents acteurs au sein des nouveaux outils proposés.

Par ailleurs, si l’UDL est un facilitateur certain dans les processus humains et techniques de livraison applicative, l’automatisation totale de certaines tâches reste aujourd’hui difficile (modification de configuration, exécution de scripts SQL, publication d’application mobile sur un MDM…). L’utilisation d’outils de gestion de configuration d’infrastructure tels que Chef ou Puppet permet alors de pousser encore plus loin le concept d’UDL.

Petit-déjeuner mercredi 12 juin à Genève

Big Data, MapReduce, calculs distribués, NoSQL, sont autant de buzz words et de concepts cantonnés jusqu’à maintenant à quelques acteurs spécifiques. Pourtant, il est un état de fait : nous sommes assis sur une quantité gigantesque de données dont il est difficile d’extraire l’information… D’autre part MapReduce est une solution éprouvée pour analyser d’énormes quantités de données (ou Big Data). Elle a, par exemple, été mise en œuvre par Google pour indexer le web, par LinkedIn pour calculer ses campagnes d’email…

Dans ces conditions, ces concepts ont-ils un intérêt dans nos SI ? Quel est le niveau de maturité de ces solutions ? Quels sont les opportunités métiers liées à Big Data ?

Une fois ces promesses identifiées et que l’on fait, par exemple, le choix d’Hadoop, encore faut-il savoir maîtriser cet écosystème, son architecture et la configuration d’un cluster adapté aux besoins métiers. Dans ce petit-déjeuner, pas de théorie uniquement mais des retours d’expérience de projets avec OCTO.

Les thèmes abordés seront :

• Big Data : quels sont les facteurs actuels qui poussent à l’émergence de ce concept et de ces solutions ? »
• Big Data : pour quels usages ?
• Quels composants logiciels pour compléter le puzzle Hadoop pour offrir une solution Big Data utilisable par les métiers?
• Comment dimensionner et configurer un cluster Hadoop adapté aux besoins? Comment benchmarker les performances d’un cluster?
• Quelles sont les best practices et les pièges à éviter dans la mise en œuvre ?
• Des retours d’expérience de projets

Ce petit-déjeuner s’adresse autant aux décideurs IT, métiers, chefs de projet, architectes qu’aux architectes techniques, responsables de production, experts et développeurs.

Cliquez ici pour vous inscrire à ce petit-déjeuner

Comment réaliser une application smartphone, une application métier ou un site internet sans connaitre l’âge des utilisateurs, leurs catégories socio-professionnel, leurs attentes, leurs habitudes…? 

Chez OCTO nous sommes convaincus de l’importance des personas, c’est pourquoi nos UX Designer qui sont impliqués dès le début des projets, pratiquent très régulièrement cette méthode pendant la phase du cadrage.

L’infographie suivante vous propose d’étudier et de bien comprendre ce que sont les personas, d’en connaitre les bénéfices et les bonnes raisons pour pratiquer cette méthode de travail.

Made Personas with Love

Jeudi 23 mai

Un produit qui déchire, une équipe qui déchire… un leader qui déchire

David Alia (@davidalia)
Découvrez les principes qui permettent à un leader de créer pour son équipe un environnement propice à l’innovation, une culture d’amélioration continue et de confiance mutuelle. Comment l’aider à se mettre dans une succession permanente d’équilibres instables entre challenge et stabilité, entre enjeux et plaisir, à conserver un sens aigu de l’initiative, une motivation à toujours faire mieux, individuellement et collectivement ?

Le Respect en Action

Jonathan Scher (@jonathan_scher) et Cyrille Deruel (@CyrilleDeruel)
Vous connaissez ces équipes dans une spirale descendante : les seules phrases qui sortent viennent du désespoir. Encore un bug, ça ne marche toujours pas, je n’arrive pas…

Travaillant comme consultants, ce cas nous est arrivé plusieurs fois. Nous avons maintenant une méthode : nous remettons en place les bases du respect. En moins de 6 semaines, l’équipe est à nouveau pleine d’espoir, productive.
Nous vous présenterons notre vision du modèle des trois CO – communication, considération, et coopération, ainsi que notre démarche inspirée de celle de Kotter pour sa mise en application.

Indiana Jones et le temple du Legacy Code

Mathieu Gandin (@octomga)
Selon The Economics Of Software Maintenance In The 21 Century, nous passons 80% de notre temps à maintenir du code existant et pénible à modifier. Dans cette situation nous devenons des archéologues du code, tandis que les contraintes de temps se font plus fortes. On parle alors de code Legacy.

A l’issue de cette session vous repartirez avec :

Une longue séance de livecoding pour présenter des techniques pour tester et remanier du code en profondeur
Une introduction à une démarche pour avoir une vue d’ensemble de votre gros code legacy
Une présentation de la matrice de gestion du temps de Covey pour vous organiser sur le long terme dans la reprise de votre code legacy

Clean Code Game

Michel Domenjoud et Mathieu Gandin (@octomga)
Maintenir une base de code propre et bien testé est un facteur clé de succès de la réalisation d’un produit. Mais avant d’en arriver là, il convient, en tant que développeur, d’adopter une certaine discipline en terme de refactoring de code.

Pendant cet atelier de 3h nous aurons l’occasion de vous faire coder et reprendre du code existant pour en faire du beau code en suivant des principes énoncés par Robert Martin dans le livre Clean Code. Et vous verrez que plus votre code sera propre, plus vous serez productif.

Vendredi 24 mai

Communautés de pratique en pratique

Cyrille Deruel (@CyrilleDeruel)
Vous rêvez d’avoir des réunions où les développeurs échangent leurs techniques, présentent leurs dernières trouvailles, les derniers frameworks utilisés, où les testeurs partagent leurs douleurs et leurs solutions, où des personnes échangent autour de différentes problématiques ?

Ne cherchez plus : Créez des communautés de pratique.

Découvrez à travers cette session comment créer des communautés de pratique auto-organisées, quels outils j’utilise pour garantir l’auto-organisation et surtout quelles règles de communication j’utilise.

Les paradoxes du leadership

Marc Cherfi (@reporter4change) et Thomas Lissajoux
Vous êtes un manager, un coach ou un leader. En tout cas vous êtes un agent de changement et vous faites de votre mieux. Pourtant, parfois, la résistance et les frictions semblent inévitables et les résultats sont au mieux passables, quand la situation ne dégénère pas ou se verrouille.

Nous analyserons les forces en jeu et présenterons les leçons que nous en avons tiré, en essayant de proposer des pistes pour débloquer ces situations.

A l’issue de cette session, vous aurez :

• découvert des exemples concrets de situations où rien ne semble marcher,
• appris à identifier ce genre de situations et de comportements paradoxaux,
• compris les forces en jeu pour prendre du recul,
• des options à votre disposition pour essayer de les débloquer.

Des métaphores qui nous transforment

Christophe Thibaut (@ToF_)
Dans notre domaine il semble qu’il y ait un process pour tout, et même l’agile, en dépit des proclamations, est l’occasion d’un retour sempiternel au process, aux outils, aux recettes.

Dans cette session j’aimerais vous inviter à quitter le règne conceptuel afin de découvrir le surprenant pouvoir des métaphores. Plus qu’une simple figure de discours, la métaphore structure notre pensée et nos actions, elle définit notre réalité. En (re-)découvrant dans leur portée et leur profondeur les métaphores qui nous gouvernent, pouvons nous transformer nos projets ?

Tester autrement : Le Guide du Testeur Intergalactique

Rémy-Christophe Schermesser (@El_Picador)
Vous connaissez déjà TDD, votre couverture de code frise les 80 %, jUnit n’a plus de secret pour vous ? Mais vous sentez que vous pourriez faire plus de vos tests, que les outils que vous utilisez ont des limites. Ou alors vous en avez marre du train train assertEquals ?

Pas de panique ! Nous allons voir ensemble comment faire des tests unitaires autrement. Nous traiterons entre autres :

• Le Mutation Testing
• Le BDD, Behaviour Driven Development
• Le Property Testing.

De l’autre côté de l’Atlantique, les Géants du Web réinventent la façon de faire de l’informatique. Ils s’appellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus.

Maintenant que ces pionniers nous ont montré la voie, nous ne pouvons plus continuer à travailler comme avant.

Rejoignez-nous pour cet événement où Damien Joguet, directeur associé d’OCTO Technology et Laurent Brisse présenteront ces pratiques innovantes qui font le succès des Géants du Web. Venez partager notre passion pour ce sujet !

Ce petit-déjeuner, qui fait suite à la sortie de cet ouvrage, dévoilera notamment comment ces géants :

• adressent les usages des utilisateurs via des pratiques de  Test A/B et de Feature Flipping ;
• réduisent leur Time To Market au moyen de démarche comme le Lean Startup  et le Continuous Deployment ;
• conservent une excellence dans la qualité de leurs produits à l’aide d’organisations composées en Pizza team et orientées Feature tout en cultivant l’obsession de la mesure ;
• font face à des enjeux énormes de fréquentation de leur site grâce aux technologies NOSQL et au Commodity Hardware.

Ce séminaire s’adresse à tous ceux qui ont envie de s’inspirer de la culture des Géants du Web : marketing, chefs de produits, architectes, geeks, managers ou responsables DSI.

Merci de noter que l’inscription est gratuite mais obligatoire !

Programme :

08h45 :
Accueil

09h15 – 10h30 :
Présentation des 10 meilleures pratiques des Géants du Web

10h30 – 11h00 :
Conclusion - Questions / Réponses

Lieu :

Grace à l’amabilité du Groupe ADEO, ce petit-déjeuner se déroulera dans l’amphithéâtre situé sur son site de Ronchin.

Rue Sadi Carnot

59790 Ronchin

Intervenants :

• Damien Joguet, Directeur associé OCTO
• Laurent Brisse, Manager

Cliquez ici pour vous inscrire au petit-déjeuner : Les Géants du Web

Cette formation aura lieu chez OCTO, au 50, avenue des Champs Elysées, 75008 Paris. Les places sont limitées et idéalement réservées aux équipes d’architecture technique qui s’apprêtent à concevoir ou exploitent des clusters de stockage et de traitements Hadoop. Cette formation, dispensée en anglais, est au prix de €1,650.00.

Inscriptions ici ! http://www.eventbrite.com/event/5466460330

Learning Objectives

• Understand the environment and differentiators of the MapR distribution for Apache Hadoop
• Understand MapReduce and MapR Lockless Storage Services (MapR-FS)
• Verify system requirements for the hardware and operating system
• Plan, install and configure MapR clusters, including High Availability (HA)
• Access MapR clusters, including via standard NFS
• Use volumes as key management level
• Monitor clusters via the command line and the MapR Control System
• Monitor and maintain clusters for health and peak performance
• Manage nodes through the life cycle of a cluster
• Optimize topologies and volumes to control data placement on clusters
• Manage access to data by configuring users, groups, and quotas
• Tune clusters for best performance
• Manage the safety, stability, and ease of deployment of data through use of Volumes, Snapshots and Mirrors

Target Audience

This course targets IT administrators and operators with at least basic Linux system administration experience.  Prior Hadoop experience is not required.

Course Outline

• Overview of MapR Administration and Management
• Introduction to MapReduce and Apache Hadoop
• Basics of MapR Architecture
• MapR Installation
• Managing Services
• Managing Nodes
• Tuning MapReduce
• Working with Volumes, Snapshots and Mirrors
• Managing Remote Clusters
• Monitoring and Troubleshooting
• Disaster Recovery

Lab Requirements

Each student should bring their own laptop.

Course Length

3 day (8 hours each) of lecture, instructor demo, and hands-on lab exercises.

LA MORT PROCHAINE DU GC – Philippe Prados
Quelques signaux faibles pour polémiquer lors de cette présentation plutôt technique :

• Fin de la loi de Moore en 2018
• NECESSITE de l’algorithme G1
• Ralentissement des programmes en 64 bits par rapport à 32 bits
• De nouveaux frameworks pour gérer la mémoire hors heap
• Émergence du Big-Data et du Database in Memory
• Apple déprécie le GC d’Objective-C
• Comment retarder l’échéance ?
• Les solutions alternatives ?
• Sélectionner maintenant les technos de demain

 Accéder aux slides de présentation
Contacter le speaker

MUSCLEZ VOS APPLIS ANDROID AVEC LES OUTILS DU MONDE JAVA – Jérôme Van Der Linden et Stéphane Nicolas

Dans cette session Tools in Action, Jérôme et Stéphane proposent un tour d’horizon des technologies qui peuvent nous aider à amener Android aux standards industriels Java.
Ils proposent à la communauté Android de profiter des 17 ans d’expérience de la communauté Java (Android vient de fêter ses 4 ans…) et d’utiliser des outils reconnus de qualité industrielle tels que Jenkins, Maven, Sonar, findbugs, pmd, checkstyle et de les combiner à Lint, Robolectric, UIAutomator.

• Accéder aux slides de présentation
• Contacter Stéphane ou  Jérôme

DU JAVASCRIPT PROPRE ? CHALLENGE ACCEPTED – Julien Jakubowski (avec Romain Linsolas)

Il y a quelques années, je bidouillais en JavaScript. Un effet “bling bling” par-ci, un contrôle de saisie par-là. L’essentiel de mon application était écrite en Java et tournait côté serveur. Mais voilà, Gmail et Google Spreadsheets sont sortis depuis longtemps. On s’attend maintenant à des applications web qui répondent instantanément et qui fonctionnent offline. Et pour cela, il faut bien plus de code JavaScript qu’avant.
Mais 20 000 lignes de JavaScript pour un site web ? Sérieux ? Dans ce language sale, qui n’a pas la moitié des outils de Java ?
J’ai appris. Et l’écosystème JavaScript a évolué.
Lors de cette session, je vous dévoilerai comment maintenant j’écris, sans stress, des applications JavaScript complexes.

• Accéder aux slides de présentation
• Contacter Julien via Linkedin ou twitter : @jak78

LES LAMBDA ARRIVENT ! EN ATTENDANT, ÊTES-VOUS SURS D’AVOIR COMPRIS LES GENERIQUES ? – Henri Tremblay

Les lambda expressions en Java arrivent à grands pas (septembre 2013 lors de DevoxxFR… 2014 depuis la semaine dernière). Les génériques sont, eux, apparus en 2004. Eh oui, 9 ans déjà. Et comme dit Joshua Bloch: « Chaque langage a un quota de complexité. Les génériques ont fait exploser celui de Java. » Êtes-vous bien sûrs d’avoir tout compris ? De bien savoir comment vous débarrasser de tous ces warnings qui sournoisement apparaissent dans votre code au moment où vous vous y attendez le moins ? Et plus subtilement, savez-vous justifier l’implémentation ?

Cette session remet les compteurs à zéro, vous donne les clés qu’il vous manquaient pour maîtriser les génériques. Et vous permettra donc d’attendre l’arrivée des lambdas sereinement.

• Accéder aux slides de présentation
• Contacter Henri via linkedin ou twitter @henri_tremblay

LES SECRETS DES GÉANTS DU WEB – 10 PRATIQUES POUR MIEUX TRAVAILLER – Ludovic Cinquin

De l’autre côté de l’Atlantique, les Géants du Web réinventent la façon de faire de l’informatique. Ils s’appellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus.
Les pratiques et les technologies qu’ils mettent en oeuvre sont l’un des fondements du succès remarquable qu’on leur connaît.
Grace à ces nouvelles façons de travailler, ils sont capables de faire plus gros, plus vite, et plus efficace que ce que nous connaissons habituellement.
Comment ces secrets des Géants du Web peuvent-ils être une source d’inspiration pour faire de l’informatique différemment ?
Cette session, qui s’appuie sur l’ouvrage que nous avons publié « les Géant du Web » propose une visite guidée de quelques pratiques clés : culture de la mesure, pizza-team, feature team, commodity hardware, lean startup, MVP, continuous deployment, …

• Accéder au site « Les géants du Web »
  
• Contacter Ludovic via Linkedin

Aller plus loin avec les Géants !

En plus des conférences nos équipes se sont rendus à Devoxx sur le stand OCTO avec pour objectif bien précis de demander aux participants Devoxx de se mesurer aux Géants ! Avec un questionnaire rapide, nous avons sondé la population sur ces pratiques qu’Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus, utilisent avec brio de l’autre côté de l’Atlantique.

Toutes ces pratiques sont d’ailleurs détaillées ici.

Alors, les participants Devoxx sont-ils des Géants du Web ?

Après une rapide analyse, il semblerait que l’ensemble des méthodes appliquées par les Géants du Web soient méconnues en France, malgré quelques buzz intéressants (Lean Startup : connue par près de 70% des participants dont 30% d’entre eux jugent cette méthode inutile, Continuous Deployment : fréquemment utilisée par près de 30% des participants , DevOps : connue par près de 80% des participants et Fluidité de l’expérience utilisateur connue par 70% des participants). Ce qui reste incroyable c’est que seuls 10% des participants au test affirment faire appel à ces techniques fréquemment !

Il reste encore du chemin à parcourir en France !

Que peut-on gagner à mener régulièrement des revues de code sur son projet ? À quel moment vaut-il mieux les faire ? Dans quel cas sont-elles superflues ?

Comment s’y prendre pour organiser une revue de code ? Faut-il s’outiller ? Quelles actions, informations produire en sortie d’une revue de code ?

Nous chercherons ensemble les réponses à ces questions, et à celles que vous pourrez amener.

Vous voulez participer ? Envoyez-moi un mail : fmerizen@octo.com. Premier arrivé premier servi !

N’oubliez pas !

What : la revue de code
When : le vendredi 26/04 à 12h30
Where : OCTO Technology, 50 avenue des Champs Élysées, 75008 Paris, 5ème étage, salle André Gide

Nota : cette session fait suite à une session sur la revue de code qui avait connu un grand succès en octobre 2011. Si vous avez assisté à cette session, nous vous attendons pour nous dire ce que vous avez appris depuis. Et si vous n’avez pas pu y assister, c’est l’occasion de rattraper!

Petit-déjeuner du 28 mai 2013

De l’autre côté de l’Atlantique, les Géants du Web réinventent la façon de faire de l’informatique. Ils s’appellent Amazon, Facebook, Google, Netflix ou LinkedIn pour les plus connus.