Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activitĂ©s liĂ©es au dĂ©veloppement d’applications informatiques en entreprise.

Blog Xebia France - J2EE, Agilité et SOA
Syndiquer le contenu Blog Xebia - Cabinet de conseil IT
Cabinet de conseil Agile spécialisé dans les technologies Big Data, DevOps, Web, Architectures Java et mobile
Mis à jour : il y a 1 heure 23 min

Spring Framework 5 : tour d’horizon des nouveautĂ©s

lun, 07/17/2017 - 11:00

Spring

 

Spring a sorti la premiĂšre release candidate de la version 5 de son framework il y a un peu plus d’un mois.

A l’heure ou nous Ă©crivons cet article, la version 5 de Spring est disponible en RC2. Une RC3 est prĂ©vue pour courant juillet, peu de temps avant la version finale.

Nous vous proposons par conséquent de découvrir ensemble les nouveautés et améliorations apportées à Spring Framework 5.

Passage Ă  Java 8

Dans sa version 4, Spring était compatible avec Java 6. Avec la version 5, le code du framework a été réécrit en Java 8.

Les développeurs en ont donc profité pour :

  • AmĂ©liorer l’accĂšs aux paramĂštres d’une mĂ©thode en utilisant les amĂ©liorations de la rĂ©flexivitĂ© de Java 8
  • Utiliser les mĂ©thodes par dĂ©faut des interfaces de Spring
  • Utiliser les classes Charset et StandardCharsets (disponible depuis le JDK 7)

Et dans une optique de compatibilitĂ© avec Java 9, l’instanciation des classes se fera dĂ©sormais par Constructor#newInstance au lieu de Class#newInstance qui va devenir obsolĂšte.

Spring WebFlux

Spring se met à la programmation réactive avec WebFlux dans sa version 5.

ConcrĂštement, il s’agit de pouvoir implĂ©menter une application web (contrĂŽleur REST) ou des clients HTTP de maniĂšre rĂ©active. Pour ce faire, Spring 5 intĂšgre dĂ©sormais Reactor et permet de manipuler les objets Mono (qui contient un objet) et Flux (qui peut contenir N objet(s)).

PlutĂŽt qu’un long discours, un peu de code :

ImplĂ©mentation d’un contrĂŽleur rĂ©active

Voici un exemple d’un contrĂŽleur qui expose une API rĂ©active.

@RestController
public class PersonController {

 private final PersonService service;

 public PersonController(PersonService service) {
  this.service = service;
 }

 @PostMapping("/person")
 Mono<Void> create(@RequestBody Publisher<Person> personStream) {
  return this.service.save(personStream).then();
 }

 @GetMapping("/person", produces = "text/event-stream")
 Flux<Person> list() {
  return this.service.findAll();
 }

 @GetMapping("/person/{id}")
 Mono<Person> findById(@PathVariable String id) {
  return this.service.findOne(id);
 }

Notez que la mĂ©thode list envoie des Ă©vĂ©nements au consommateur du service. Ce paradigme est connu sous le nom server-sent events (SSE). Ces Ă©vĂ©nements lancĂ©s par le serveur peuvent ĂȘtres consommĂ©s par des clients de diffĂ©rentes natures: client frontal en JavaScript, ou WebClient de Spring en Java.

Ci-dessous, l’implĂ©mentation d’un contrĂŽleur AngularJS permettant l’utilisation d’un service web utilisant SSE grĂące Ă  l’interface EventSource :

var personModule = angular.module('persons', []);
personModule.controller('PersonsCtrl', function($scope, Persons) {
   
  $scope.init = function() {
    var source = new EventSource('/persons');
    source.onmessage = function(event) {
      $scope.$apply(function () {
        $scope.entries = JSON.parse(event.data)
      });
    };
  };
 
});

Consommer un service réactive avec Spring

Avec Spring 5, nous pouvons maintenant utiliser WebClient, une alternative non bloquante Ă  RestTemplate qui nous permet de consommer une API REST :

WebClient client = WebClient.create("http://localhost:8080");
Mono<Account> account = client.get()
  .url("/persons/{id}", 1L)
  .accept(APPLICATION_JSON)
  .exchange(request)
  .then(response -> response.bodyToMono(Account.class));

Et pour les tests d’intĂ©gration, grĂące au module spring-test, il nous est possible de facilement tester nos API grĂące au WebTestClient. Une caractĂ©ristique importante de la classe WebTestClient est qu’on peut tester les points d’accĂšs exposĂ©s par un contrĂŽleur sans dĂ©marrer un serveur de servlets (Tomcat, Netty ou autre). Cette classe propose quelques mĂ©thodes permettant de lancer des assertions sur la rĂ©ponse reçue du serveur. Voici un exemple de code :

WebTestClient client = WebTestClient
        .bindToController(new PersonController())
        .build();

client.get().uri("/persons/42")
        .exchange()
        .expectStatus().isOk()
        .expectHeader().contentType(MediaType.APPLICATION_JSON_UTF8)
        .expectBody(Person.class).value().isEqualTo(new Person("John"));

Bien entendu, on peut aussi se connecter une URI comme d’habitude :

WebTestClient client = WebTestClient
        .bindToServer().baseUrl("http://localhost:8080")
        .build();

client.get()...

Support avec Kotlin 1.1+

Kotlin a le vent en poupe. Et avec Spring 5, il sera possible d’utiliser le framework avec le langage de JetBrains.

Ainsi, voici comment implémenter un contrÎleur REST avec Kotlin :

{
    ("/blog" and accept(TEXT_HTML)).nest {
        GET("/", fooHandler::findAllView)
        GET("/{slug}", fooHandler::findOneView)
    }
    ("/api/blog" and accept(APPLICATION_JSON)).nest {
        GET("/", this@barHandler::findAll)
        GET("/{id}", this@barHandler::findOne)
    }
}

Améliorations pour les tests

Dans sa version 5, Spring sera entiĂšrement compatible avec les extensions de JUnit 5, en proposant SpringExtension, qui reprendra les mĂȘmes fonctionnalitĂ©s du Spring TestContext Framework.

Nous aurons aussi le droit Ă  plusieurs nouvelles annotations :

  • @SpringJUnitConfig : Ă©quivalent Ă  @ExtendWith(SpringExtension.class) (de JUnit 5) et @ContextConfiguration
  • @SpringJUnitWebConfig : tout comme @SpringJUnitConfig, avec en plus @WebAppConfiguration

Pour davantage d’informations, n’hĂ©sitez pas Ă  consulter la release notes ainsi que la documentation de Spring Framework 5.

Des exemples d’utilisation de Spring 5 sont disponibles sur GitHub, que ce soit en Java et en Kotlin.

Catégories: Blog Société

Revue de Presse Xebia

jeu, 07/13/2017 - 16:00

revue de presse Xebia
La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

MobilitĂ© Vision Framework – Exemples & APIs http://www.gravatar.com/avatar/3f309c992e2b1a5c3c014e63810a2f68http://blog.xebia.fr/author/scivettahttp://twitter.com/viteinfinitehttp://github.com/viteinfinitePar Simone Civetta

Depuis l’annonce de Vision Framework lors de la derniĂšre WWDC en juin, GitHub et Medium abondent d’exemples de mises en pratique. Si vous ne savez pas lequel choisir, ou si tout simplement vous voulez commencer avec une implĂ©mentation la plus minimaliste possible, voici un article et un repository qui, Ă  l’aide de quelque snippets, fournissent une vision d’ensemble efficace des principales fonctionnalitĂ©s et des APIs du framework. En particulier :

  • reconnaissance de QR Code
  • reconnaissance de visages
  • reconnaissance des « landmarks » d’un visage (bouche, yeux, nez,…)
  • reconnaissance de textes
  • suivi (tracking) d’objet
  • Vision + CoreML
Back Kafka propose de l’exactly-once-delivery ! http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Article en cours d’Ă©criture

Confluent vient d’annoncer le support du presque mythique « exactly-once-delivery » par Apache Kafka.

La problĂ©matique est simple Ă  prĂ©senter : garantir qu’un message sera dĂ©livrĂ© et traitĂ© une seule fois; pas 0, pas 2, pas 5; une… et ce mĂȘme en cas de problĂšme (partition rĂ©seau, crash d’un composant).

En revanche, elle est bien moins simple Ă  rĂ©soudre et encore moins de maniĂšre performante ! C’est

  • Idempotence: Exactly-once in order semantics per partition. The producer send operation is now idempotent… written once on broker
  • Transactions: Atomic writes across multiple partitions

De maniĂšre plus gĂ©nĂ©rale, cet article est un excellent rĂ©sumĂ© des problĂ©matiques de livraison de messages, et a mĂȘme Ă©tĂ© applaudi par Wernel Vogels, le CTO d’Amazon.

Data Spark 2.2 : une petit pas pour le streaming, un grand pas pour le développeur http://blog.xebia.fr/author/slequeuxhttp://twitter.com/slequeuxPar Sylvain Lequeux

Ce mardi 11 juillet, Apache Spark 2.2 a été annoncé en release. Outre les ajouts de nouveaux algorithmes distribués (cette fois-ci majoritairement sur GraphX, MLLib et SparkR), une annonce forte est faite dans la release note.

Spark Structured Streaming est maintenant considĂ©rĂ© comme « production ready ». Ceci signifie que le tag « experimental » n’est maintenant plus prĂ©cisĂ© et que les Ă©quipes de dĂ©veloppement du framework considĂšrent le tout comme suffisamment mature pour ĂȘtre exploitĂ© par tous.

Catégories: Blog Société

DĂ©veloppement Agile et Craft

lun, 07/10/2017 - 11:00

développement agile

Vous ĂȘtes dĂ©veloppeur mobile pour un journal d’information bien connu. Les articles paraissent sur un site web et l’application Android correspondante est utilisĂ©e par des centaines de milliers d’utilisateurs. Elle permet de rĂ©agir sur les articles, et les utilisateurs ne s’en privent pas : c’est le thĂ©Ăątre de dĂ©bats d’un haut niveau Ă©motionnel, si ce n’est orthographique.

Mais un matin, aucune rĂ©action postĂ©e depuis l’application ne paraĂźt plus sur le site. Les avis dĂ©favorables s’accumulent sur le Play Store :

Impossible de rĂ©agir depuis l’application. Aucune rĂ©action envoyĂ©e depuis l’application ne parvient aux modĂ©rateurs, alors que les rĂ©actions envoyĂ©es depuis le site passent sans problĂšme. –RaphaĂ«l H.

Je suis abonnĂ© mais aucun des messages que je dĂ©pose avec mon smartphone ne s’affiche lorsque je commente l’actualitĂ©… –Michel K.

[…] Censure des commentaires n’allant pas dans le sens des articles, je me suis donc dĂ©sabonnĂ©… […] –Adrien V.

Cette situation demande d’agir vite et bien. C’est l’occasion d’illustrer une approche de dĂ©veloppement qui mĂȘle agilitĂ© et savoir-faire (craftsmanship).

Voici le comportement de l’application en matiĂšre de commentaires :

  • L’application permet de poster un commentaire en rĂ©action Ă  l’article lui-mĂȘme (indicateur response à false)
  • Elle permet de rĂ©pondre au commentaire d’un autre utilisateur (indicateur response à true)

Avant de vous distraire de votre tĂąche en cours, votre leader technique a pris le temps d’analyser l’anomalie : l’application ne poste pas les commentaires correctement. Le mapping entre l’indicateur response et la valeur envoyĂ©e Ă  l’API est incorrect. C’est un « if » qui a Ă©tĂ© codĂ© Ă  l’envers.

Le code en question rĂ©vĂšle l’erreur de mapping concernant la valeur du paramĂštre responseFlag attendu par l’API.

sendReaction(message, item, response);
public void sendReaction(String message, String answeredItem, boolean response) {
 
    int responseFlag;
    if (response) responseFlag = 0;
    else responseFlag = 1;
                    
    api.postReaction(message, answeredItem, responseFlag);
}
Agilité

Compte tenu de l’importance du bug, vous mettez de cĂŽtĂ© vos dĂ©veloppements en cours. Vous committez vos changements et vous passez sur une nouvelle branche issue de la version de production.

Votre premier rĂ©flexe est d’ouvrir le test unitaire (TU) du code en question. Qui n’existe pas. Damned. Le bug aurait pu ĂȘtre repĂ©rĂ© si un test avait Ă©tĂ© rĂ©digĂ© lors du dĂ©veloppement initial.

Le code est dans une Activity Android. Vous Ă©valuez l’investissement que constitue la rĂ©daction d’un nouveau test unitaire dans cette situation, et vous prĂ©fĂ©rez laisser le TU de cĂŽtĂ© le temps de produire un correctif dĂ©montrable afin de rassurer votre client.

Vous appliquez le correctif qui consiste Ă  inverser les branches du if. Dans l’immĂ©diat, vous privilĂ©giez la correction du bug par rapport au refactoring.

public void sendReaction(String message, String answeredItem, boolean response) {
 
    int responseFlag;
    if (response) responseFlag = 1;
    else responseFlag = 0;
                    
    api.postReaction(message, answeredItem, responseFlag);
}

Vous testez le correctif sur votre poste de dĂ©veloppement, puis vous publiez le code sur une branche du dĂ©pĂŽt de votre organisation. Le leader technique valide vos changements, vous faites le merge dans la branche d’intĂ©gration.

Votre serveur d’intĂ©gration continue met automatiquement Ă  disposition du reste de l’Ă©quipe une version de recette. Votre Ă©quipe pratique le dogfooding : c’est quand les membres de l’Ă©quipe sont les premiers utilisateurs de leur propre application. Cette pratique permet de confirmer l’absence de rĂ©gression dans des conditions rĂ©elles d’utilisation. Vous montrez le correctif Ă  votre client qui confirme la correction.

Craftsmanship

Et maintenant ? Le processus minimal est respectĂ©, du point de vue de votre client, vous pourriez donc livrer une nouvelle version hotfix de votre application et passer au ticket suivant, mais votre travail n’est pas terminĂ©. Dans la mĂ©thode sendReaction, au moins un refactoring vous dĂ©mange. Et votre beau correctif n’est toujours pas testĂ© unitairement.

Compte tenu de la simplicité du correctif, vous pouvez tout reprendre du début.

Vous commencez par écrire un test automatisé. Ici, le plus approprié est un test unitaire qui vérifie la logique du if.

Mais avant de pouvoir Ă©crire ce test unitaire, le code doit ĂȘtre repensĂ©. La classe impactĂ©e par le correctif est fortement couplĂ©e avec le framework Android qui est difficile Ă  simuler dans un test unitaire. Vous avez deux solutions :

  • Mettre en place le framework Robolectric pour simuler le framework Android dans votre TU
  • Appliquer le pattern Passive View pour sortir la logique du if dans une classe sĂ©parĂ©e, qui serait testable facilement car non dĂ©pendante du framework

Vous choisissez la Passive View car vous pensez que Robolectric ralentirait l’exĂ©cution de vos tests, et Ă  cause du dĂ©lai des mises Ă  jour de Robolectric suite Ă  celles du SDK Android.

DÚs que le test passe, vous en profitez pour transformer le paramÚtre response en enum, petit refactoring qui vous démangeait :

public void sendReaction(String message, String answeredItem, CommentType commentType) {
 
    api.postReaction(message, answeredItem, commentType.getApiFlag());
} 
enum CommentType {

    INITIAL("0"), ANSWER("1");

    private String mApiFlag;

    CommentType(final String apiFlag) {
        mApiFlag = apiFlag;
    }

    public String getApiFlag() {
        return mApiFlag;
    }
}

Vous adaptez votre test unitaire au changement de signature de la méthode sendReaction().

Ensuite vous faites en sorte que votre dĂ©veloppement puisse ĂȘtre repris et maintenu facilement par un autre dĂ©veloppeur, grĂące Ă  une sĂ©ance de revue de code. En support Ă©crit, vous prĂ©parez une pull request dĂ©taillĂ©e sur GitHub dont la description rappelle :

Le besoin fonctionnel Correction d’un bug au niveau des rĂ©actions La spĂ©cification technique
  • Extraction de la logique dans une classe dĂ©couplĂ©e
  • Inversion du sens du if
Le scénario de test
  1. Brancher l’application sur un environnement de recette
  2. Poster un commentaire sur un article
  3. Poster une réaction à un autre commentaire
  4. Observer qu’ils sont bien reçus par le backend et que leur type est correct

Ce niveau de dĂ©tail par Ă©crit permet de garder une documentation Ă©crite et indexĂ©e au sujet du correctif au cas oĂč un autre besoin impacterait ce pĂ©rimĂštre de code.

NB : l’idĂ©al serait d’intĂ©grer la documentation au code afin de la rendre plus « vivante » et pour qu’elle puisse Ă©voluer avec le code. Mais ce type d’approche est coĂ»teux Ă  mettre en place sur du code existant ; vous laissez donc de cĂŽtĂ© ce chantier pour l’instant.

Quelques heures plus tard, la version corrigĂ©e est publiĂ©e sur le Play Store, certains utilisateurs l’ont installĂ©e, et les premiĂšres rĂ©actions des utilisateurs arrivent sur les articles. Vous retrouvez enfin leur douce prose, les trolls, la crĂ©ativitĂ© orthographique.

Conclusion

À partir d’une situation vĂ©cue, dans le contexte du dĂ©veloppement mobile, cet article illustre l’application des valeurs agiles et craft.

Dans le contexte d’un bug sensible, cette approche s’appuie sur les valeurs agiles pour prendre en compte les attentes du client en termes de rapiditĂ© de mise au point d’un correctif.

Elle s’appuie aussi sur les valeurs craft pour permettre Ă  la base de code de rester saine et comprĂ©hensible par les autres dĂ©veloppeurs, prĂ©sents et futurs.

Références
Catégories: Blog Société

CSS : .container, la classe Ă  abattre

ven, 06/30/2017 - 16:00

Il n’y pas si longtemps, un comparse dĂ©veloppeur m’a interrogĂ© sur l’utilitĂ© d’une classe html/css*1 prĂ©sente dans ma codebase :

<div class="container">
...
</div>

Un bureau d’investigation de haute volĂ©e (composĂ© de moi-mĂȘme) dĂ©buta alors une folle enquĂȘte sur ce mystĂ©rieux .container, son parcours et ses motivations …

.container, qui est-il ? D’oĂč vient-il ?

Quand j’ai commencĂ© Ă  faire de l’intĂ©gration html/css, il y avait cette classe, container, un peu partout. En gĂ©nĂ©ral, elle englobait tout le contenu du site, de cette maniĂšre :

<html>
    <head><!-- ... --></head>
    <body>
        <div class="container">
            <!-- Et lĂ , bim, bam, boum, on met tout son contenu !!! -->
        </div>
    </body>
</html>

Pour faire simple, elle centrait le contenu de la page et c’était visiblement une pratique normĂ©e dans le monde du css, car tout le monde utilisait cette classe.

Et selon les projets, on pouvait trouver des variantes, comme les classes wrapper, section*2, ou encore l’id content, et parfois, une combinaison de tout ça, en gĂ©nĂ©ral avec un nesting, soyons francs, assez alĂ©atoire, mais ça ressemblait grosso modo Ă  cette satanĂ©e maquette qu’il nous fallait intĂ©grer, alors tout allait bien.

.container, oĂč est-il ? Que fait-il ?

Aujourd’hui, si on google rapidement « css container », on tombe sur diffĂ©rents frameworks css qui intĂšgrent une classe container. Bien que je ne conseille pas l’utilisation des frameworks CSS, Ă  moins de n’avoir aucune maquette Ă  respecter, ils restent de bons moyens pour jauger l’Ă©tat de l’art en CSS. Regardons donc un peu plus en dĂ©tails les implĂ©mentations de .container mises en place dans certains frameworks*3 :

  • Bootstrap : http://getbootstrap.com/css/#overview-container
    .container {
        /* On ajoute une marge sur les cotés de l'écran */
        padding-right: 15px;
        padding-left: 15px;
    
        /* Et on centre */
        margin-right: auto;
        margin-left: auto;
    }
    
    /* Sur les grands Ă©crans, on limite la largeur du contenu */
    @media (min-width: 1200px){
        .container {
            width: 1170px;
        }
    }
    
  • Materialize : http://materializecss.com/grid.html
    .container {
        /* On centre */
        margin: 0 auto;
    
        /* On limite la largeur pour les grands Ă©crans */
        max-width: 1280px;
    
        /* On gÚre la présence d'une marge */
        width: 90%;
    }
    
    /*
    * Comme la dite marge est exprimée en pourcentage,
    * on l'augmente sur les devices moins larges.
    */
    @media only screen and (min-width: 993px){
        .container {
            width: 85%;
        }
    }
    
  • Skeleton : http://getskeleton.com/
    .container {
        /* On limite la largeur */
        width: 100%;
        max-width: 960px;
    
        /* On centre */
        margin: 0 auto;
    
        /* Et on ajoute une marge (sur les petits Ă©crans seulement) */
        padding: 0 20px;
    
        /*
        * Le "box-sizing: border-box;" permet de ne pas impacter la width avec le padding
        * La largeur max réelle du contenu est donc de 920px =&gt; 960 - (2 x 20)
        */
        box-sizing: border-box;
    }
    
    /* Sur les écrans plus larges, la marge est gérée en pourcentage */
    @media (min-width: 400px) {
        .container {
            width: 85%;
            padding: 0;
        }
    }
    
  • W3.CSS : https://www.w3schools.com/w3css/w3css_containers.asp
    /*
    * W3.CSS se rapproche plus de la charte graphique de w3 school,
    * lĂ  oĂč les prĂ©cĂ©dents frameworks se veulent plus agnostiques
    */
    
    /* Ici, le container sert simplement à gérer un padding */
    .w3-container {
        padding: 0.01em 16px;
    }
    

Hormis pour ce dernier exemple, on distingue donc deux utilités à notre classe container, centrer le contenu et y ajouter une marge horizontale.

 .container, pourquoi fait-il ça ?

Pour que votre contenu reste lisible. Explications. Une page web est composĂ©e d’Ă©lĂ©ments qui peuvent ĂȘtre :

  • Textuels (ou images liĂ©es) et/ou interactifs ;
  • DĂ©coratifs (image de background, bandeau de couleur, etc.).

Si pour ces derniers, on peut souhaiter qu’ils s’Ă©tendent sur toute la largeur de l’Ă©cran, pour le contenu texte/interactif, il est important d’avoir :

  • Une marge de confort afin d’Ă©viter que votre contenu ne soit collĂ© aux bords de l’Ă©cran (notamment sur les devices mobiles). Cela permet de conserver une lisibilitĂ© de votre texte. En gĂ©nĂ©ral, cette marge se situe entre 15 et 20 pixels ;
  • Une largeur utile, qui correspond Ă  la largeur d’Ă©cran au delĂ  de laquelle il devient inutile (voir contre-productif) d’Ă©taler son contenu sur toute la largeur disponible, au risque de sortir du champ de vision de l’internaute des Ă©lĂ©ments qu’il est censĂ© voir. Souvent, cette largeur utile est centrĂ©e.

Du coup la classe container rĂ©pond effectivement Ă  ces deux besoins. Toutefois, elle peut parfaitement ĂȘtre remplacĂ©e, et par quelque chose de mieux qui plus est !

.container, pourquoi doit-il disparaĂźtre ?

Car il manque d’expressivitĂ©. SĂ©mantiquement parlant, le terme container apporte Ă  peu prĂ©s autant d’informations qu’une classe foobar. Quasiment tous les tags HTML sont destinĂ©s Ă  contenir quelque chose.

Étant donnĂ© qu’on sait maintenant ce que faisait .container, et pourquoi il le faisait, on peut sereinement le remplacer par deux classes :

  • .margin-constraint afin de gĂ©rer notre marge de confort ;
  • .useful-width afin de gĂ©rer notre largeur utile.
Une implémentation CSS ?

Partons sur une largeur utile de 800px et des marges de confort de 20px. Cela nous donne :

<!DOCTYPE html>
<html>
<head></head>
<body>
    <div class="full-width">
    Ici, on aura des éléments purement décoratifs qui peuvent s'étaler sur toute la largeur de l'écran (une image, ou encore un bandeau de
    couleur...)
 
        <div class="margin-constraint">
        Ici on peut par exemple placer des éléments qui doivent s'étaler sur toute la largeur,
        mais ne doivent pas ĂȘtre juste au bord de l'Ă©cran (certaines dĂ©corations, Ă©ventuellement certains Ă©lĂ©ments de menu...)
             
            <div class="useful-width">
            Notre contenu textuel ira généralement ici. Il restera sur une largeur agréable à la lecture
            et gardera un espace par rapport au bord de l'Ă©cran.
            </div>
        </div>
    </div>
</body>
</html>
.margin-constraint{
    /*On indique tout simplement une marge*/
    margin-left: 20px;
    margin-right: 20px;
}
 
.useful-width{
    /*On rĂšgle ensuite la largeur utile puis on centre*/
    max-width: 800px;
    margin-left: auto;
    margin-right: auto;
}
 
.margin-constraint, .useful-width{
    /*Si vous utilisez uniquement des div, cette derniĂšre rĂšgle css n'est mĂȘme pas nĂ©cessaire*/
    display: block;
    width: auto;
}

Au final, niveau css, on gagne en simplicité comparé aux implémentations de container précédemment évoquées :

  • Pas de media query;
  • On utilise des propriĂ©tĂ©s qui sont sĂ©mantiquement plus proches de ce que l’on souhaite rĂ©aliser ;
  • Si on travaille avec une maquette, on peut directement utiliser les valeurs dĂ©duites de cette derniĂšre, plutĂŽt que de devoir faire un calcul du type (largeur utile – 2 * marge de confort) ou utiliser un pourcentage un peu approximatif (voir les exemples en dĂ©but d’article).

Le principal dĂ©savantage de cette technique est qu’elle nĂ©cessite l’utilisation de 2 balises html imbriquĂ©es (.margin-constraint > .useful-width). Mais avec une petite rĂšgle css en plus, vous pourrez Ă©galement utiliser les deux classes sur une mĂȘme balise. Voyez le rĂ©sultat ici : https://codepen.io/alexistessier/pen/XRLoxv.

À noter : Une autre approche courante consiste Ă  dĂ©finir une max-width puis Ă  appliquer un padding afin de gĂ©rer la marge. Je ne suis pas fan de cette façon de faire car elle implique de forcer le box-sizing (propriĂ©tĂ© assez obscure et globalement assez mal comprise) de l’Ă©lĂ©ment si on veut s’assurer que le padding soit ou non inclus dans la largeur finale de l’Ă©lĂ©ment. Autant que possible, je prĂ©fĂšre utiliser des propriĂ©tĂ©s simples Ă  apprĂ©hender.

Pour conclure

Au delĂ  de vous exhorter Ă  Ă©liminer mĂ©thodiquement tout .container que vous pourriez trouver dans vos CSS, le but de cet article Ă©tait surtout de revenir Ă  des fondamentaux et d’essayer de se souvenir quelles problĂ©matiques rĂ©solvent les frameworks CSS lorsqu’ils mettent une classe tel que container Ă  notre disposition.

Tchao’

Notes de bas de page

  • *1 : En rĂ©alitĂ©, il s’agissait d’un helper en stylus, un prĂ©processeur css qu’il est bien pour styler des choses.
  • *2 : Mais ça c’Ă©tait avant le tag section de HTML5.
  • *3 : Les css prĂ©sentĂ©es dans cet article sont des versions simplifiĂ©es de ce que vous pourrez trouver si vous allez voir vous mĂȘme dans le code source des frameworks css concernĂ©s.
Catégories: Blog Société

Revue de Presse Xebia

jeu, 06/29/2017 - 16:00

revue de presse XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

 

Mobilité Android Things Console developer preview http://www.gravatar.com/avatar/15de70d494a999da31d0a8dbd0bb38e6http://blog.xebia.fr/author/nullhttp://twitter.com/bonbonkinghttp://github.com/jinqianPar Qian Jin

Encore une nouveautĂ© sur Android Things pour complĂ©ter l’offre de la plateforme ! Google vient d’annoncer la preview pour la console d’Android Things. La console permet de gĂ©rer tous les aspects des logiciels de l’objet, y compris la crĂ©ation d’images d’usine, ainsi que la mise Ă  jour du systĂšme d’exploitation et des APK fournis par les dĂ©veloppeurs.

Craftsmanship BDD in JavaScript : Getting Started with Cucumber and Gherkin – Craftsmanship http://blog.xebia.fr/author/nullhttp://twitter.com/nullPar Sarah Buisson

 Vous avez toujours rĂȘvĂ© de mettre en place des tests BDD sur le front de votre projet sans jamais vous lancer ? Dans son dernier article, Graham Cox vous explique pas Ă  pas les bases du BDD, du gherkins et comment mettre en place des tests de comportements automatisĂ©s dans votre projet gĂące Ă  Cucumber. Un article trĂšs pĂ©dagogique, accessible Ă  tous  !

DevOps Shipping des logs Ă  Algolia http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Algolia nous propose cette semaine un rapide retour sur la gestion de leurs logs et sur l’architecture qu’ils ont conçu afin de supporter leur envoi et leur traitement. En effet, leur volumĂ©trie (1 milliard de lignes de logs par jour) ne leur permettait pas de rentrer dans les modĂšles des solutions en SaaS, et ne permettait pas non plus de se tourner vers les solutions de streaming des principaux fournisseurs de cloud pour des raisons de coĂ»t.

Au final, la solution implĂ©mentĂ©e est un simple Pub/Sub, mais la partie intĂ©ressante est l’introduction d’un « orchestrateur » fait maison et servant Ă  envoyer les logs rĂ©cupĂ©rĂ©s sous forme de batch afin de rĂ©duire les coĂ»ts.

Releases : CoreDNS et Deep Learning AMI http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Comme chaque mois désormais, voici un résumé des principales releases intéressantes ayant eu lieu ce mois-ci :

  • AMI de Deep Learning d’AWS : L’image (AMI) mise Ă  disposition par Amazon et embarquant une installation fonctionnelle des principaux outils de Machine Learning est dĂ©sormais disponible sous une nouvelle version embarquant Apache MXNet v0.10 and TensorFlow v1.1.
  • CoreDNS-008 : Un des changements notables de cette release est l’abandon de logging vers un fichier; dĂ©sormais, comme toute application 12factor-compliant, CoreDNS ne loggera que vers sa sortie standard. On notera Ă©galement l’ajout de la notion de prefetch au cache, permettant de re-rĂ©cupĂ©rer un record DNS avant l’expiration de son TTL.
  • Gitlab 9.3 : Avec cette nouvelle version, Gitlab nous propose en nouveautĂ©s phares l’intĂ©gration de la qualitĂ© de code et la gestion de pipelines multi-projets pour Gitlab CI. Pour le reste, et comme ils nous y ont habituĂ©, de nombreuses autres nouveautĂ©s et amĂ©liorations sont disponibles dans l’annonce de cette version !
Catégories: Blog Société

DevOps – OĂč s’arrĂȘte la responsabilitĂ© d’une feature team ?

lun, 06/26/2017 - 11:00

 

 

Une Ă©quipe agile doit ĂȘtre autonome et responsable de bout en bout, voilĂ  le casse-tĂȘte qu’il faut se prĂ©parer Ă  rĂ©soudre quand on se lance dans une organisation en Feature Teams. Autonome ne veut pas dire libre ! Quand on oublie le monde des start-ups et qu’on cherche Ă  appliquer ce modĂšle organisationnel dans une grande entreprise, la confrontation Ă  la rĂ©alitĂ© est dure. Afin de rendre ce modĂšle possible, il faut construire des Ă©quipes au service des Feature Teams : bienvenue dans une organisation « as-a-service ».

Une équipe capable de livrer un incrément de valeur

Nous parlons réguliÚrement de Feature Teams sur le blog de Xebia. Prenons la définition du framework agile LeSS qui définit une Feature Team avec les caractéristiques suivantes :

  • elle a un backlog orientĂ© fonctionnalitĂ©
  • elle est cross fonctionnelle et cross composant
  • elle est stable et durable
  • elle est capable de livrer un incrĂ©ment de valeur.

Ces caractĂ©ristiques vont donner de l’autonomie Ă  l’Ă©quipe, moins il y a de dĂ©pendances, plus l’Ă©quipe sera en mesure de limiter les temps morts et les blocages. La complexitĂ© des plannings sera rĂ©duite par la mĂȘme occasion.

Les responsabilitĂ©s d’une Feature Team

Quand on parle de responsabilitĂ©s, ça commence Ă  se compliquer. Il vous est peut-ĂȘtre arrivĂ© d’entendre un ops dire aprĂšs un week-end d’astreinte :  » c’est pas le dev qui va se lever la nuit quand un serveur tombe ! « . Dans une organisation en Feature Team, il faut assumer le revers de la mĂ©daille : pour aller plus vite, il faut endosser plus de responsabilitĂ©s. Si je veux choisir une stack technique plus spĂ©cifique ou un OS diffĂ©rent des standards de l’entreprise, je ne peux pas attendre de support d’une Ă©quipe tierce : il faudra l’assumer soi-mĂȘme. RĂ©duire ses dĂ©pendances est allĂ©chant mais il faudra accepter les inconvĂ©nients de cette stratĂ©gie.

Les Platform Teams, une nouvelle organisation des « ops »

Pour que les Feature Teams ne deviennent pas des usines Ă  produire des fonctionnalitĂ©s impossibles Ă  maintenir, il faut les aider. L’importance des fournisseurs « as-a-service » dans le modĂšle d’organisation en Feature Teams est fondamentale. Pour aller vite, une Feature Team cherchera sans doute Ă  prendre le service le plus simple pour pouvoir le rendre spĂ©cifique Ă  son besoin. C’est le IaaS (Infrastructure as a Service) : « un serveur et les clĂ©s du camion ».

Certains fournisseurs vont plus loin et proposent des services plus Ă©voluĂ©s avec une garantie de maintien en service : le PaaS (Platform as a Service). Ils se peut que les Feature Teams soient heureuses d’utiliser ce service. Attention ! Ce service devra ĂȘtre construit en collaboration pour favoriser l’expĂ©rience utilisateur des membres de la Feature Team. Sans ce prĂ©-requis les Feature Teams se tourneront vers le IaaS. Oublier ses utilisateurs en interne a les mĂȘmes rĂ©percutions que de ne pas Ă©couter ses clients : ils s’Ă©loignent. Il faudra alors obliger l’utilisation des services PaaS pour des raisons stratĂ©giques ou sĂ©curitaires… Mauvaise idĂ©e !

DerniĂšre possibilitĂ©, le SaaS (Software as a Service). Une solution dans laquelle les Feature Teams utiliseront un logiciel clĂ© en main, avec les garanties et bien sĂ»r les contraintes. Les Platform Teams pourront soit dĂ©velopper et proposer la solution logicielle, soit acquĂ©rir une solution et la proposer. Dans tous les cas, il s’agit de solutions en libre-service mises Ă  disposition sur une plateforme.

 

Appelons ces Ă©quipes des Platform Teams. À l’instar des Feature Teams, ces Ă©quipes sont cross fonctionnelles, cross composant, stable et durable. Elles fonctionnent de maniĂšre agile et travaillent avec un product owner. Si vous ĂȘtes familier du modĂšle spotify, elles portent le nom d’infrastructures squads et elle ont le rĂŽle de « enable and support » (permettre et supporter). Ces Ă©quipes ops « as-a-service » sont des piĂšces importantes d’une organisation qui se veut devops.

Définir une limite de responsabilité

Afin que les Feature Teams et les Platform Teams puissent travailler ensemble sans se marcher dessus, il faut dĂ©finir la limite de responsabilitĂ© de chacune. C’est le point de dĂ©couplage. Les Platform Teams doivent livrer sur une plateforme self-service. Ce produit “as-a-service” requiert de la maintenance, de l’innovation et des responsables. Ce modĂšle permet aux Feature Teams de dĂ©velopper des produits dont elles vont pouvoir garder la responsabilitĂ© du cycle de vie en entier. Elles bĂ©nĂ©ficieront de services avec un support, d’une stack technique et de configurations validĂ©es par l’entreprise. Par exemple des distributions d’OS validĂ©es, des serveurs avec les patchs de sĂ©curitĂ© Ă  jour.

Quelles Platform Teams pour mon organisation ?

DerriĂšre chaque service qui fonctionne avec un systĂšme de ticket, il y a sans doute la possibilitĂ© de crĂ©er une ou plusieurs Platform Teams. Cela implique des changements. Le premier est de passer d’une activitĂ© de run Ă  une activitĂ© de mise Ă  disposition de service. Ceci se fait concrĂštement par la production d’API’s qui seront mises Ă  disposition des Feature teams. Par exemple, des DBA’s qui proposent une API de refresh des bases de donnĂ©es ou des administrateurs systĂšmes qui proposent une API pour redĂ©marrer des serveurs automatiquement. A chaque action automatisĂ©e et « APIsĂ©e », le temps gagnĂ© devra ĂȘtre rĂ©investi dans la transformation en Ă©quipe « as-a-service ». Chaque service de ce type mis Ă  disposition permettra aux Platform Teams de se libĂ©rer du temps. Temps qu’il faudra mettre Ă  profit pour Ă©tudier les besoins des Feature Teams et proposer des services Ă  forte valeur ajoutĂ©e, comme n’importe quelle Ă©quipe agile. Peu a peu les Platform Teams apprendront Ă  comprendre leurs utilisateurs pour gagner le badge « build the right thing » en plus de « build the thing right » dans le challenge du continuous delivery.

A la recherche du point D

C’est maintenant le moment de faire une introspection sur votre systĂšme d’information. Il n’y a Ă©videmment pas de rĂ©ponse universelle dans le choix de votre ou vos point(s) de dĂ©couplage. Par culture, de nombreuses organisations sont trĂšs prescriptives et vont vouloir tout encadrer (PaaS voir SaaS) mais est-ce bĂ©nĂ©fique dans un contexte agile oĂč les Ă©quipes gagnent en autonomie et en responsabilitĂ© ? Est-ce que l’Ă©nergie, et donc le budget, investis en valent vraiment la peine? Dans ce cas, un point de dĂ©couplage IaaS donnera sans doute la possibilitĂ© de commencer dĂšs demain. Autre exemple, si le service n’est pas critique ou diffĂ©renciant pour votre mĂ©tier, le SaaS sera sans doute une alternative intĂ©ressante. DĂ©velopper son outil de post-it virtuel ou son pipeline de dĂ©ploiement est rarement une stratĂ©gie gagnante. Il vous reste donc Ă  vous lancer dans votre transformation en Feature Team avec la dĂ©finition des responsabilitĂ©s Ă  l’esprit.

Catégories: Blog Société

Revue de Presse Xebia

jeu, 06/22/2017 - 16:00

revue de presse XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

 

Mobilité Swift 4 rétropédale http://blog.xebia.fr/author/nullhttp://twitter.com/nullhttp://github.com/mbretonPar JC Pastant

Suite aux retours de la communautĂ© aprĂšs la premiĂšre bĂȘta de Swift 4, la Core team a dĂ©cidĂ© de retirer la proposal SE-110 de la release finale.

Cette proposition supprimait le coalescing implicite entre f(x,y) et f((x,y)) ce qui, au regard des retours particuliÚrement négatifs, engendrait une verbosité accrue non négligeable.

Si vous aviez déjà migré sur Swift 4 beta 1, attendez-vous à devoir dé-migrer une partie de votre code ! ;)

Data Google permet d’entraĂźner un modĂšle multi-tĂąches avec MultiModel http://blog.xebia.fr/author/ybenoithttp://twitter.com/%40YoannBENOIThttp://github.com/ybenoitPar Yoann Benoit

Dans un rĂ©cent article de leur blog, Google Research prĂ©sente MultiModel, un modĂšle capable d’ĂȘtre entraĂźnĂ© sur plusieurs tĂąches (image recognition, translation, speech recognition). Cette implĂ©mentation ouvre les portes aux systĂšmes d’Intelligence Artificielle gĂ©nĂ©rale, capables de prendre des dĂ©cisions dans plusieurs domaines grĂące Ă  un seul et mĂȘme modĂšle. Il est intĂ©ressant de constater que les donnĂ©es par rapport Ă  un domaine spĂ©cifique (image captionning par exemple) permettent aussi d’amĂ©liorer les performances dans d’autres domaines. MultiModel a Ă©tĂ© rendu open-source avec la nouvelle librairie Tensor2Tensor de TensorFlow.

DevOps DĂ©ploiement de modĂšles de machine learning sur Kubernetes par Domino http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Domino, proposant Ă  ses utilisateurs de publier leurs modĂšles de machine learning en Python ou R sous forme d’API REST pour eux, viennent de complĂštement rĂ©-architecturer leur infrastructure en se basant sur Kubernetes, et nous proposent un retour sur cette mise en place.

Le point principalement mis en avant est celui de la facilité de déploiement offerte par Kubernetes, qui permet en effet de déployer les nouvelles versions de modÚles de maniÚre vraiment simple et automatisée.

MalgrĂ© cette facilitĂ©, la problĂ©matique d’exposition des services de maniĂšre tout aussi automatique et transparente s’est posĂ©e : pour y rĂ©pondre, ils ont choisi de se tourner vers Traefik, le reverse-proxy/load-balancer dynamique en Go capable de directement se connecter Ă  Kubernetes pour exposer et load-balancer des services.

4 rĂŽles pour un leader DevOps http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Mettons pour une fois le cĂŽtĂ© technique de cĂŽtĂ© avec cet article de Jaxenter sur les 4 rĂŽles d’un leader DevOps.

Les 4 roles évoqués sont les suivants :

  • Role 1 – Tell the Story
  • Role 2 – Be the safety guard!
  • Role 3 – Build the Kernel team
  • Role 4 – Be the communication enabler

En rĂ©alitĂ©, cet article adresse de maniĂšre large la problĂ©matique du leadership face au changement, s’appliquant donc logiquement Ă  toute dĂ©marche de transformation DevOps. On parle bien ici de leadership, permettant d’inciter ceux concernĂ©s par le changement Ă  en ĂȘtre eux-mĂȘmes les acteurs, et non pas de management.

Le Role 1 évoqué ici (« Tell the Story ») correspond au final trÚs bien à ce que Simon Sinek décrit dans sa conférence « Start With Why »; une conférence à regarder pour quiconque intéressé par ces problématiques de leadership !

Catégories: Blog Société

Retour sur l’aprùs-midi du Domain-Driven Design

lun, 06/19/2017 - 11:00

Le 7 juin dernier s’est dĂ©roulé l’aprĂšs-midi du Domain-Driven Design au centre de confĂ©rence Microsoft, Ă  Issy-les-Moulineaux. Cet Ă©vĂšnement, animĂ© par Thomas Pierrain, Bruno Boucard et JĂ©rĂ©mie Grodziski (co-organisateurs du meetup DDD Paris et fondateurs du mouvement « Let’s reboot DDD »), avait pour objectif l’introduction aux patterns techniques et Ă  l’approche du DDD au travers d’un live-coding longue durĂ©e sur un code legacy. Autrement dit, les conditions que nous, dĂ©veloppeurs, rencontrons au quotidien par opposition aux prĂ©sentations partant habituellement d’une feuille blanche.

Xebia Ă©tait prĂ©sente Ă  cet Ă©vĂšnement et vous propose de revenir sur ce dernier en vous fournissant un certain nombre de pointeurs pour creuser le sujet et ĂȘtre en mesure de l’appliquer dĂšs Ă  prĂ©sent sur vos bases de code.

L’aprĂšs-midi s’est articulĂ© autour d’une keynote revenant sur la genĂšse du DDD suivie de 3 sessions de live-coding respectivement dĂ©diĂ©es Ă  la pose d’un harnais de tests, Ă  l’utilisation des patterns techniques du DDD et Ă  celle des concepts d’une architecture hexagonale. Nous vous proposons de suivre ce mĂȘme cheminement dans ce compte-rendu.

Keynote

Le DDD trouve son origine dans un constat simple : il est devenu aisé de faire du logiciel mais les coûts de maintenance restent trop élevés, dû notamment à la complexité. Cette derniÚre est de 3 types : le domaine, le logiciel et les individus.

Combattre la complexité au coeur du logiciel

Le best-seller d’Eric Evans, Ă  l’origine du DDD, propose de « combattre la complexitĂ© au coeur du logiciel ».
JĂ©rĂ©mie Grodziski dĂ©finit ce dernier comme « l’ensemble des concepts qui permettent de rĂ©soudre des problĂšmes Ă  travers des cas d’utilisation ».
Ce coeur varie bien Ă©videment d’un contexte Ă  l’autre.

Par exemple, dans le domaine de la comptabilitĂ© Ă  double entrĂ©e, on utilise les concepts de compte, dĂ©bit, crĂ©dit, montant, etc. pour rĂ©soudre des problĂšmes de traçabilitĂ© et de robustesse. Autre exemple, dans le domaine des environnements de dĂ©veloppement intĂ©grĂ©s, on utilise les concepts de projet, fichier, refactoring, analyse, etc. pour rĂ©soudre des problĂšmes d’intĂ©gration et de productivitĂ©.

Pour traiter cette complexitĂ©, on cherche un meilleur alignement entre l’espace du problĂšme et l’espace de la solution. Et celui-ci passe incontestablement par une meilleure comprĂ©hension entre les personnes. Pour reprendre le mojo de Thomas et JĂ©rĂ©mie : « Make the implicit, explicit » (« Explicitez les implicites ! »).

DDD, une boite Ă  outils des plus riches

DDD peut ĂȘtre vu comme :

  • une approche de conception (prendre des dĂ©cisions plus ou moins impactantes mais de maniĂšre consciente).
  • et une boite Ă  outils Ă  2 Ă©tages :
    • lorsque l’on code, via les patterns tactiques (entitĂ©s, values objects, fonctions pures, etc.).
    • lorsque l’on architecture, via les patterns stratĂ©giques (bounded contexts, couches d’anti-corruption, architecture hexagonale, etc.).

Attention ! DDD n’est surtout pas un processus ou une mĂ©thode qui nous dit quoi faire Ă  chaque instant.
Il s’agit de faire usage de cette approche et de cette boite Ă  outils pour connecter nos dĂ©cisions aux objectifs du mĂ©tier.

En résumé, le DDD cherche à répondre à la question suivante : « comment intégrer au mieux le domaine dans le logiciel ? »

Contexte du live-coding

Thomas, Bruno & JĂ©rĂ©mie se sont inspirĂ©s du kata TrainReservation d’Emily Bache pour mener Ă  bien leur aprĂšs-midi de live-coding (4h au total, respect !).
Dans ce dernier, il s’agit de rĂ©server des billets de train en tenant compte d’un certain nombre de rĂšgles telles que :

  • Ne pas dĂ©passer 70% des places rĂ©servĂ©es dans le train (pour laisser la possibilitĂ© de mener des opĂ©rations de derniĂšre minute).
  • Ne pas dĂ©passer 70% des places rĂ©servĂ©es dans chaque voiture (on n’aime pas voyager dans un train bondé !).
  • Garder les siĂšges d’une mĂȘme rĂ©servation dans la mĂȘme voiture.

#AMDDD du legacy jusque dans les blagues

Catégories: Blog Société

Conférence Best of Web 2017

ven, 06/16/2017 - 11:00

Conférence Best of Web

La troisiĂšme Ă©dition de Best Of Web a eu lieu les 8 et 9 Juin derniers, ce fut l’occasion de retrouver les meilleurs talks des 19 meetups web que regroupe cette confĂ©rence annuelle. Quelques Xebians ont assistĂ© Ă  cette Ă©dition dont voici un petit compte-rendu :

La Keynote

Thomas Guenoux (@thomasgx), co-fondateur de @commitStrip a introduit cette journĂ©e en abordant l’avenir du mĂ©tier de dĂ©veloppeur. Il note la fin du dĂ©veloppeur full stack, avec la spĂ©cialisation des compĂ©tences dans diffĂ©rents domaines que sont l’IoT, l’ops, la sĂ©curitĂ©, la blockchain, le machine learning, les bots, l’IA,… Il situe l’Ă©poque actuelle dans la quatriĂšme rĂ©volution industrielle, celle qui amĂšnera au dĂ©veloppement d’une intelligence artificielle qui dĂ©passera celle des Hommes, et qui pourrait Ă  terme mettre fin Ă  des mĂ©tiers comme celui d’avocat ou de mĂ©decin.

On estime Ă  2040 la date Ă  laquelle les machines atteindront le niveau d’intelligence des hommes. Thomas pose alors la question de la responsabilitĂ© du milieu de l’informatique et de l’Ă©thique nĂ©cessaire pour les choix qui devront ĂȘtre faits. Il estime qu’une majoritĂ© des dĂ©veloppeurs actuels se spĂ©cialiseront dans le domaine de l’intelligence artificielle dans un avenir proche et appelle Ă  se positionner en dĂ©veloppeur universel, un dĂ©veloppeur qui saura penser Ă  sa place dans le monde, Ă  ses actions, aux valeurs qu’elles peuvent crĂ©er mais aussi aux Ă©ventuelles consĂ©quences nĂ©fastes qui pourraient en dĂ©couler.

La technique des Fab Four

RĂ©mi Parmentier (@HTeuMeuLeu) est intĂ©grateur HTML et CSS. Il a eu Ă  se confronter Ă  l’Ă©dition d’un email en Responsive Design, qui devait ĂȘtre rendu dans la plupart des clients mails. Sa premiĂšre idĂ©e fut d’utiliser les Media queries, mais voilĂ  ce qu’il a remarquĂ© :

support de media sur mobile

Il s’est alors demandĂ© si l’usage de flexbox pouvait ĂȘtre une solution. Cependant, le rendu dans Gmail Ă©tait dĂ©sastreux.

C’est en remarquant la prioritĂ© de ‘min-width‘ appliquĂ©e Ă  un mĂȘme Ă©lĂ©ment dans le cas suivant :

  • min-width: 480px
  • width: 320px
  • max-width: 160px

dont la taille rendu Ă©tait de 480px qu’il a crĂ©Ă© la technique des « Fab Four« .

Cette technique s’Ă©crit de la maniĂšre suivante :

technique

Elle est utilisable sur la plupart des clients web.

Vous pouvez retrouver ses diapositives sur https://speakerdeck.com/hteumeuleu

SOLID principles for Front-End Developers

GrĂ©gory Ruiz (@gregoryruiz) nous parle du design orientĂ© objet appelĂ© SOLID. Il travaille sur un projet front-end impliquant beaucoup de monde et sur lequel certains dĂ©parts ont amenĂ© Ă  perdre la maĂźtrise d’une partie du code. GrĂ©gory a dĂ» trouver des solutions pour amĂ©liorer la cohĂ©rence du code au sein de l’Ă©quipe, notamment :

  • re-travailler les tests
  • crĂ©er une documentation vivante
  • revoir le nommage du code
  • rĂ©-organiser le code
  • appliquer des designs patterns
  • mettre en pratique certains principes : KISS, DRY, YAGNI,… et SOLID

GrĂ©gory nous livre son retour d’expĂ©rience de la mise en pratique de SOLID. GrĂące Ă  l’usage de Typescript, il a rĂ©ussi Ă  respecter ses principes en s’inspirant des design patterns de Java et en utilisant en particulier les interfaces et les classes abstraites. Vous pourrez trouver davantage de prĂ©cision sur les principes SOLID sur cet article de blog : http://blog.xebia.fr/2011/07/18/les-principes-solid/.

React Storybook : Concevoir, DĂ©velopper, Documenter et DĂ©bugger ses composants d’interface React

Marie-Laure Thuret (@mlthuret) nous prĂ©sente un outil qui lui est devenu indispensable aujourd’hui en tant que dĂ©veloppeuse ReactJs chez Algolia, il s’agit de React Storybook.

Cet outil :

  • offre un environnement de dĂ©veloppement des composants React totalement isolĂ©, en hot reload
  • du fait de l’isolement du composant, il favorise le dĂ©veloppement en API-first
  • permet Ă©galement de tester le composant et de manipuler les props pour voir les effets sur le rendu
  • peut ĂȘtre mis en ligne, et offrir une documentation vivante. C’est le choix qu’Ă  fait Algolia, Ă  titre d’exemple voici le lien vers leur storybook : https://community.algolia.com/react-instantsearch/storybook/

Marie-Laure nous a expliquĂ© qu’une version est Ă©galement en dĂ©veloppement pour VueJs.

Service-Public.fr : Accessibilité et Agilité

Adrien Saunier (@adriensaunier) est dĂ©veloppeur sur le projet www.service-public.fr. Ce site recense 10 millions de visiteurs par mois et plus de 178 000 pages, pour autant il a reçu le label e-accessible. Obtenir ce label, c’est respecter les directives en vigueur : internationales avec WCAG, nationales avec RGAA qui contient des tests avec plus de 130 critĂšres. Il s’agit en particulier de permettre de naviguer en utilisant uniquement le clavier, d’avoir une diffĂ©renciation claire des couleurs, de permettre un accĂšs rapide Ă  toutes les fonctionnalitĂ©s ou bien d’ĂȘtre adaptĂ© Ă  l’usage d’un outil de synthĂšse vocale.

Adrien a expliquĂ© comment le projet s’est adaptĂ© pour permettre la mise en place des contraintes induites par une bonne accessibilitĂ© et pour Ă©voluer en les conservant. Il s’agit principalement d’impliquer tout le monde : PO, UX, dĂ©veloppeurs, testeurs pour que chacun se sente concernĂ© et surtout pour anticiper les implications des contraintes Ă  respecter et Ă©viter les bugs qui sont sources de douleur. Des experts sur le sujet sont Ă©galement intervenus, et ont intĂ©grĂ© l’Ă©quipe.

Adrien a prĂ©sentĂ© quelques points qu’il est bon de suivre :

  • une syntaxe HTML valide
  • l’utilisation du site au clavier
  • la hiĂ©rarchie des titres
  • avoir des noms de pages signifiants
  • ne pas avoir une information portĂ©e uniquement par les couleurs
  • avoir des images avec une alternative textuelle qui les dĂ©crivent
  • permettre de zoomer, dĂ©-zoomer sans perte d’information
Elm + Web Components = <3

KĂ©vin Lebrun (https://github.com/kevinlebrun), tech-lead chez Meetic, s’est intĂ©ressĂ© Ă  Elm. Ce langage vise Ă  faciliter le dĂ©veloppement fonctionnel dans le Web, avec pour avantages :

  • intĂ©gration avec des projets web JS : se compile vers javascript
  • pas d’exception en runtime : lors de la compilation, il dĂ©tecte les infĂ©rences de type
  • de trĂšs bonnes performances :
    performances elm
  • dĂ©tecte les changements de version des modules utilisĂ©s pour Ă©viter les « surprises » de patch
  • plus qu’un langage, il dĂ©finit une architecture de dĂ©veloppement

KĂ©vin nous a montrĂ© le dĂ©veloppement d’un petit compteur ainsi que les interactions Elm, Polymer, et Vue.js.

Faire du bruit avec Pizzicato.JS

Impressionnante prĂ©sentation d’Alejandro Mantecon Guillen (@alemangui), il a jouĂ© de la guitare pour montrer les capacitĂ©s de sa bibliothĂšque Pizzicato.JS. En utilisant l’API de Web Audio disponible sur les navigateurs, la bibliothĂšque :

  • permet de rĂ©cupĂ©rer des sons (via un fichier, le micro ou l’entrĂ©e audio)
  • de transformer le son Ă  la maniĂšre d’une pĂ©dale d’effets
  • de jouer plusieurs pistes en parallĂšle !

Un bon moyen de s’amuser, aussi bien en musique qu’en informatique, d’autant plus que l’usage est facile et le rendu de qualitĂ©.

Faire cohabiter React et d3.js

Christophe Rosset (@topheman) nous a prĂ©sentĂ© comment combiner l’usage de d3.js, qui permet de gĂ©nĂ©rer des graphes de donnĂ©es dynamiques et de React. Les approches des deux bibliothĂšques sont trĂšs diffĂ©rentes car d3 rĂ©cupĂšre les donnĂ©es fournies en entrĂ©e et crĂ©e des mutations sur le DOM alors que React ne manipule jamais directement le DOM. On trouve donc deux approches pour le rendering :

  • qu’il soit fait par d3 en l’adaptant pour qu’il n’interfĂšre pas avec le React lifecyle
  • qu’il soit fait par React en re-implĂ©mentant le travail fait par d3 sur le DOM (en wrappant svg dans jsx)

Vous pouvez trouver toutes les expérimentations de Christophe sur son repo Github : https://github.com/topheman/d3-react-experiments.

Reverse engineering d’une API SOAP chiffrĂ©e

Kévin Raynel (@kraynl) a été confronté à un logiciel de systÚme de paie bien peu pratique, fonctionnant uniquement sous Windows et en a eu assez de passer par une machine virtuelle pour récupérer ses bulletins.

C’est en sniffant les requĂȘtes du logiciel vers l’API qu’il a remarquĂ© qu’elles Ă©taient en HTTP, avec un systĂšme d’authentification custom. Alors, il s’est dit qu’il allait pouvoir faire de la ‘rĂ©tro-ingĂ©nierie’ pour essayer d’utiliser l’API sans passer par le logiciel. Son talk nous explique comment, en sniffant les requĂȘtes avec Charles, en jouant le rĂŽle du « man in the middle » pour outrepasser l’encodage RSA et en dĂ©compilant le code .Net avec reflector, il a pu rĂ©cupĂ©rer ses bulletins de paie en un clic !

Créer une expérience WebVR sur toutes les plateformes

David Rousset (@davrous) dĂ©veloppeur et Ă©vangĂ©liste Microsoft dans la rĂ©alitĂ© virtuelle, nous prĂ©sente le framework dont il est le co-auteur avec David Catuhe (@deltakosh) : babylon.js. Ce framework est un moteur 3D basĂ© sur WebGL et Javascript et fournit une API qui permet de crĂ©er des objects, des scĂšnes et d’interagir avec l’environnement virtuel. Le point fort de l’usage de cet outil pour crĂ©er des environnements virtuels est qu’il se dĂ©ploie en ligne. Il est donc disponible sur toutes les plateformes et permet de toucher une base d’utilisateur trĂšs vaste.

La bibliothĂšque met Ă©galement Ă  disposition un outil pratique pour s’amuser avec les exemples de babylon, il s’agit d’un IDE dans le navigateur qui permet d’afficher le rendu 3D : https://www.babylonjs-playground.com/.

Vous trouverez sur le site www.babylonjs.com plein d’exemples et de documentation sur l’usage du framework.

Tour d’horizon des 3 grandes mĂ©thodologies CSS

Jonathan Verrecchia (@verekia) nous présente les trois grandes méthodes actuelles pour développer son style en CSS :

  1. CSS en CSS
    Le plus simplement du monde, utiliser CSS pour faire du CSS, mais pas sans les outils actuels, David nous donne quelques conseils :

    • prĂ©-processeur : SaSS, qui est le plus rĂ©pandu, pour faciliter l’Ă©criture, utiliser des variables,…
    • conventions de nommage : BEM, SUITCSS ou bien SMACSS
    • post-precesseur : PostCSS, qui permet de rajouter des plugins, vous pouvez les trouver sur ce site : http://postcss.parts/
    • « nettoyeur » : purifyCSS, qui rĂ©cupĂšre uniquement le contenu CSS qui est utilisĂ© dans l’application en analysant le code
  2. CSS en HTML
    Le CSS est écrit en inline, mais avec des classes utilitaires et des variables. On trouve trois principales bibliothÚques : Tachyon, Basscss et Atomic CSS (la plus répandue).
    Il s’agit d’associer une classe Ă  un Ă©lĂ©ment pour un rĂšgle (de type margin-left par exemple). Les avantages sont le poids du CSS qui est constant et le dĂ©veloppement rapide.
    Voici un exemple Atomic, représentant un div de type inline-box, de largeur 33%, padding de 20px et ayant une background-color valant #0280ae.5 : 

    <div class="IbBox W(1/3) P(20px) Bgc(#0280ae.5)"/>
  3. CSS en JS
    Ce sont des feuilles de style que l’on peut importer dans des composants, tout comme le javascript. On trouve plusieurs outils, notamment Webpack qui permet de rĂ©soudre les imports CSS avec css-loader ou styletron. Pour React, on trouve Ă©galement d’autres outils comme styled-components ou glamorous.

En résumé, Jonathan donne ces conseils pour le choix de la méthode :

  • si l’on ne dĂ©veloppe pas en javascript : CSS in CSS
  • pour un projet rapide : CSS in HTML
  • pour la majoritĂ© des cas : CSS in JS
Construction d’une « Raspberry Pi home alarm » en moins de 3h

RaphaĂ«l Dubigny (@rdubigny) vivait dans un appartement dont la capacitĂ© de la porte d’entrĂ©e Ă  empĂȘcher l’intrusion laissait Ă  dĂ©sirer. En rassemblant chez lui ce qui pouvait lui servir, il a trouvĂ© un Raspberry Pi, une camĂ©ra infrarouge, et quelques cĂąbles. Il nous explique dans ce talk comment il a mis en place une alarme connectĂ©e dans son appartement.

Au-delĂ  de son projet, qui lui a permis tout de mĂȘme de mettre en place un dĂ©tecteur de mouvements sur la porte, de prendre des photos du suspect, de stocker ces photos sur GDrive, d’activer une alarme, RaphaĂ«l nous montre l’intĂ©rĂȘt qu’il a trouvĂ© Ă  dĂ©velopper un projet personnel. Non seulement il en retire de la fiertĂ©, mais aussi tout ce qu’il a appris comme le python, la programmation rĂ©active ou bien encore la soudure. Pour motiver son public a faire la mĂȘme dĂ©marche que lui, il explique dans un de ses derniers slides comment se lancer dans un projet personnel :

  • arrĂȘter avec les excuses du type : « j’ai pas le temps »,…
  • rĂ©soudre des problĂšmes utiles
  • itĂ©rer sur des « Petits Trucs Moches Qui Marchent » (PTMQM)
  • aller en production au plus vite (1h)

D’ailleurs, en y regardant de plus prĂšs, on peut Ă©galement penser Ă  ces principes pour ses projets professionnels.

Comment tirer le maximum de vos contributeurs

Vincent Voyer (@vvoyer), d’Algolia, nous explique comment il attire des contributeurs sur ses projets, aussi bien privĂ©s que publics et comment il met au maximum leurs compĂ©tences Ă  profit. Il explique notamment la mĂ©thode mis en place chez Algolia lorsqu’un utilisateur crĂ©e une « issue ». Une sĂ©rie de questions lui ai posĂ©e dans le template de l’issue, afin de prĂ©ciser au maximum le problĂšme :

  • Do you want to request a feature or report a bug?
  • Bug: What is the current behavior?
  • Bug: What is the expected behavior?
  • Bug: What browsers are impacted? Which versions?
  • Feature: What is your use case for such a feature?
  • Feature: What is your proposed API entry? The new option to add? What is the behavior?
  • What is the version you are using? Always use the latest one before opening a bug issue.

D’autre part, il prĂ©cise de garder en tĂȘte les principes suivants lors des rĂ©ponses aux contributeurs :

  • l’utilisateur contribue : apprĂ©cier sa bonne volontĂ©
  • si l’utilisateur est mĂ©content, Ă©viter Ă  tout prix la confrontation
  • ne pas faire d’hypothĂšse ou de supposition a priori sur l’utilisateur ou bien le bug ou la feature
  • essayer d’ĂȘtre le plus clair possible, car la communication Ă©crite est complexe
  • supposer a priori qu’une issue est un problĂšme Ă  rĂ©soudre

Appliquer ces principes permet une forte implication des contributeurs et un gain d’efficacitĂ©.

Conclusion

Best Of Web nous a offert une Ă©dition riche tant en qualitĂ© des talks qu’en variĂ©tĂ© des sujets. Une bonne annĂ©e pour une confĂ©rence qui a su trouver sa place dans les rendez-vous annuels des technologies du Web Ă  Paris.

conférence best of web 2017

Catégories: Blog Société

Revue de Presse Xebia

jeu, 06/15/2017 - 11:00

revue de presse XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Mobilité How to speed up your slow Gradle builds http://www.gravatar.com/avatar/15de70d494a999da31d0a8dbd0bb38e6http://blog.xebia.fr/author/nullhttp://twitter.com/bonbonkinghttp://github.com/jinqianPar Qian Jin

Quelques semaines aprÚs le Google I/O, voici une compilation des astuces extraites depuis la session « Speeding Up Your Android Gradle Builds » avec des explications pour accélérer les builds Gradle dans vos projets Android.

MobileNets: Open-Source Models for Efficient On-Device Vision http://www.gravatar.com/avatar/37a6259cc0c1dae299a7866489dff0bdhttp://blog.xebia.fr/author/nullhttp://twitter.com/bonbonkinghttp://github.com/jinqianPar Qian Jin

Google vient de publier MobileNets, une série des modÚles Mobile-First pour TensorFlow. Ces modÚles sont conçus pour maximiser efficacement la précision tout en étant conscient des ressources restreintes pour une application sur les devices mobiles. La release contient la définition du modÚle en utilisant TF-Slim, ainsi que 16 checkpoints de classification ImageNet pré-entrainés pour les utilisations dans les projets mobiles des toutes les tailles.

Data Le streaming avec Spark, plus rapide que jamais http://www.gravatar.com/avatar/ea9359b0d59422804330a542a4b7f20chttp://blog.xebia.fr/author/ldivadhttp://twitter.com/loicMDivadhttps://github.com/DivLoicPar LoĂŻc DIVAD

Lors du Spark Summit 2017 qui a eu lieu entre le 5 et 7 Juin un nouveau module de Spark a Ă©tĂ© annoncĂ© : Continuous Processing. Un an aprĂšs le lancement de Structured Streaming, le composent unifiant l’écriture des traitements batch en temps rĂ©el, c’est sur les temps de latence que l’entreprise Databricks a dĂ©cidĂ© de mettre l’accent cette annĂ©e. Apache Spark est connu pour avoir un mode streaming basĂ© sur un modĂšle micro-batch.
L’objectif de ce nouveau module est d’aller plus loin et de permettre l’application continue des requĂȘtes dĂ©finies via Structured Streaming. La sortie du mode micro batch promet un passage des latences minimales de 100 millisecondes Ă  moins d’une milliseconde. Ce mode d’exĂ©cution est disponible sur la plateforme cloud de Databricks et son intĂ©gration Ă  Spark est prĂ©vu pour la version 2.3.0.

Il a longtemps Ă©tĂ© question de faire de Spark le moteur de stream processing le plus facile Ă  utiliser, avec Continuous Processing il s’agit maintenant de dĂ©crocher le titre de moteur le plus rapide.

Sparkdl, une nouvelle librairie de Deep Learning pour Spark http://www.gravatar.com/avatar/ea9359b0d59422804330a542a4b7f20chttp://blog.xebia.fr/author/ldivadhttp://twitter.com/LoicMDivadhttp://github.com/DivLoicPar LoĂŻc DIVAD

Le Spark Summit a aussi Ă©tĂ© l’occasion d’introduire une nouvelle librairie open source dĂ©diĂ©e au Deep Learning sur Spark : Deep Learning Pipeline. MĂȘme si il existait dĂ©jĂ  des initiatives comme TensorFrame ou TensorFlowOnSpark cette nouvelle librairie apporte plusieurs nouvelles fonctionnalitĂ©s :

  • Un import et dĂ©codage distribuĂ© d’image pour de la classification.
  • Le transfert learning qui permet d’apprendre Ă  partir de modĂšles dĂ©jĂ  entraĂźnĂ©s.
  • L’interaction avec des modĂšles dĂ©veloppĂ©s avec Kearas ou TensorFlow.
  • L’intĂ©gration aux pipelines de Machine Learning dĂ©jĂ  existantes dans le cadre de tuning de paramĂštres.
  • La possibilitĂ© d’enregistrer des rĂ©seaux entraĂźnĂ©s sous forme d’UDF utilisables en SQL.

Malheureusement cette librairie n’est disponible qu’en python pour l’instant. Aucune information n’a Ă©tĂ© donnĂ©e sur l’intĂ©gration de cette librairie dans Pyspark. La question maintenant est de savoir si elle remplira son objectif en rendant accessible le Deep Learning Ă  une population encore plus grande.

Cloud Enfin de l’autoscaling pour DynamoDB ! http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Amazon vient tout juste d’annoncer son ajout de la capacitĂ© d’autoscaler DynamoDB, une de ses bases de donnĂ©es as a service.

En effet, jusqu’Ă  maintenant, il n’Ă©tait possible de dĂ©finir les « read capacity » et « write capacity » que manuellement, forçant Ă  prĂ©voir la charge soi-mĂȘme et Ă  adapter ces capacitĂ©s en consĂ©quence.

DĂ©sormais, il sera possible d’automatiquement augmenter ou diminuer ces capacitĂ©s en se basant sur des mĂ©triques remontĂ©es par DynamoDB dans CloudWatch.

DevOps Google et Netflix lancent Spinnaker http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Google et Netflix viennent d’officialiser la version 1.0 de Spinnaker, la plateforme de gestion de dĂ©ploiement sur du cloud.

Alors que certains se reposent dĂ©sormais sur les orchestrateurs de conteneurs (Mesos/Marathon, Swarm, Nomad, Kubernetes), d’autres travaillent toujours avec des machines virtuelles sur des Cloud publics ou privĂ©s. Dans ce cadre, une problĂ©matique constante Ă  l’heure du continuous delivery est « comment dĂ©ployer proprement et automatiquement ? »; canary release, blue/green deployment, et tant d’autres mĂ©thodes chacune adaptĂ©e Ă  des besoins diffĂ©rents.

Spinnaker, crĂ©Ă© par Netflix il y a 3 ans, a pour objectif d’ĂȘtre ce gestionnaire de dĂ©ploiement. Un remplacement Open Source qui semble trĂšs crĂ©dible face au « scotch » habituel avec CloudFormation (cĂŽtĂ© AWS) et leurs « ReplacingUpdates » et « RollingUpgrades » qui ne vont souvent pas assez loin et forcent Ă  finir le travail soi-mĂȘme avec des lambdas.

Catégories: Blog Société

Serverless vs Micro-Service avec infrastructure « maison »

jeu, 06/15/2017 - 10:00
Introduction

Aucune infrastructure à gérer, telle est la promesse des architectures serverless et services managés.

Deux solutions d’architectures diffĂ©rentes sont comparĂ©es ici au travers d’un rĂ©el besoin client rencontrĂ© en mission.

Une architecture « classique » organisĂ©e en micro-services et dont l’infrastructure est Ă  la main du client et une architecture serverless / services managĂ©s AWS implĂ©mentĂ©e lors d’une mission.

Afin de faciliter la comparaison, la solution classique est hĂ©bergĂ©e sur AWS et utilise le service EC2 sans l’aide de service managĂ©.

Besoin client

Le besoin qui va nous servir d’exemple tout au long de l’article consiste Ă  acquĂ©rir une fois par jour des points d’intĂ©rĂȘts (POI), Ă  les transformer et les mettre Ă  disposition dans un moteur de recherche afin que la partie front (une carte routiĂšre) les rĂ©cupĂšre pour les afficher.

L’hĂ©tĂ©rogĂ©nĂ©itĂ© des POI en entrĂ©e est Ă©levĂ©e car les partenaires fournisseurs sont divers (Booking, Accor, Airbnb pour les plus connus). Une phase de mapping s’impose afin de convertir le format de chaque fournisseur en un format commun sur lequel seront appliquĂ©es toutes les rĂšgles de gestion. Pour n’en citer qu’une, qui est d’ailleurs la plus impactante niveau code, un rapprochement est appliquĂ© entre les POI des diffĂ©rents fournisseurs. En effet, un POI peut ĂȘtre prĂ©sent dans le catalogue de plusieurs partenaires. L’enjeu mĂ©tier est de constituer une seule entrĂ©e dans le systĂšme qui sĂ©lectionne les informations les plus pertinentes.

L’étape finale consiste Ă  indexer les POI dans un moteur de recherche pour les rendre accessibles. Les recherches effectuĂ©es sont essentiellement gĂ©ographiques ou des filtres sur les prix, les Ă©quipements et le nombre d’étoiles des hĂŽtels. La volumĂ©trie totale des POI est supĂ©rieure Ă  1 million d’Ă©lĂ©ments.

Le traitement fonctionnel peut se schématiser ainsi :

  • Etape 1 : Collecte des POI auprĂšs des partenaires
  • Etape 2 : Mapping & validation de surface
  • Etape 3 : Stockage et rapprochement des POI entres les partenaires
  • Etape 4 : Indexation dans le moteur de recherche

D’un point de vue technique, ce besoin se traduit par la mise en place de quatre services distincts :

  • Un service de collecte de donnĂ©es des diffĂ©rents partenaires ;
  • Un service de mapping et de validation. Les donnĂ©es sont uniformisĂ©es au format du client ;
  • Un service d’insertion en base de donnĂ©es ;
  • Un service d’indexation dans le moteur de recherche.
Solution 1: Micro-services et infrastructure « maison » Partie applicative

L’architecture applicative pour le besoin est simple. Tout s’organise autour d’un bus de messages (ici RabbitMQ). Ce bus permet de rendre nos services indĂ©pendants et permet Ă©galement l’interruption d’un service sans perte de donnĂ©es. En effet, les messages sont persistĂ©s dans le bus. Si un service tombe, les messages lui Ă©tant destinĂ©s seront stockĂ©s dans RabbitMQ. Ces messages seront remis au service quand celui-ci sera de nouveau disponible.

Le scaling de nos services sera Ă©galement facilitĂ©. Lorsqu’un nouveau nƓud est mis en place, il se connectera automatiquement au RabbitMQ. Ce dernier lui distribuera donc des messages comme aux autres nƓuds.

Les services sont développés sur une base Node.js. La base de données choisie est MongoDB, une base orientée document. Un Elasticsearch est également présent.

Enfin, les messages gĂ©nĂ©rant des erreurs sont dirigĂ©s dans une DLQ dans RabbitMQ. Pour rappel une DLQ ou Dead Letter Queue est une file dĂ©diĂ©e oĂč seront envoyĂ©s tous les messages ayant gĂ©nĂ©rĂ©s une erreur (technique ou fonctionnelle) pour analyse et / ou retraitement ultĂ©rieur.

Nous sommes donc en prĂ©sence d’une architecture applicative micro-services des plus classiques.

Partie infrastructure

Lors de la mise en place d’une architecture « classique », la partie infrastructure n’est pas Ă  nĂ©gliger. La tolĂ©rance Ă  la panne et la sĂ©curitĂ© sont des points importants Ă  surveiller.

C’est pourquoi dans notre proposition l’ensemble des instances sont placĂ©es dans des subnets privĂ©s (les Avalaibility Zone sont volontairement masquĂ©es sur le schĂ©ma).

Les instances EC2 sont également placées dans des autoscaling groups afin de perinsertion et une ré-instanciation automatique des briques utilisées en cas de défaillance.

Les outils RabbitMQ, Elasticsearch et MongoDB étant dans des autoscaling groups, leurs IPs sont dynamiques. Afin de faciliter leur utilisation par les services Node.js, des Elastic Load Balancer (ELB) sont placés devant et font office de VIP.

Enfin, l’application ne s’exĂ©cutant qu’une fois par jour, il est possible grĂące aux autoscaling groups d’AWS de dĂ©marrer les machines au moment voulu de l’exĂ©cution. Ceci permet une rĂ©duction de coĂ»t et Ă©vite d’avoir des instances tournant dans le vide 90 % de la journĂ©e.

CÎté provisioning deux solutions sont possibles avec AWS :

  • Packager une AMI avec l’ensemble des outils nĂ©cessaires dĂ©jĂ  installĂ©s. Une fois l’instance dĂ©marrĂ©e, elle est prĂȘte Ă  l’emploi,

  • Utiliser une AMI de base et configurer la machine une fois dĂ©marrĂ©e avec des outils tel Ansible.

Le duo CloudFormation / Ansible est un bon moyen pour provisionner et configurer facilement une infrastructure AWS.

ProblĂ©matiques liĂ©es Ă  l’infrastructure

La mise en place d’une infrastructure a forcĂ©ment un coĂ»t. Au dĂ©veloppement des services applicatifs s’ajoute celui des scripts Ansible et CloudFormation. Les templates CloudFormation dans une infrastructure maison sont plus consĂ©quents que dans une architecture serverless. Ceci est d’autant plus vrai quand aucun service managĂ© n’est utilisĂ©. Les configurations bas niveau compliquent Ă©galement ces templates.

Une fois en production cette infrastructure doit ĂȘtre monitorĂ©e afin de rĂ©agir aux potentiels problĂšmes. GrĂące Ă  la mise en place d’autoscaling group, si une instance tombe, elle sera rĂ©-instanciĂ©e automatiquement.

De mĂȘme, le service Auto Scaling permet de gĂ©rer une montĂ©e en charge de l’applicatif. NĂ©anmoins, avec les contraintes posĂ©es sur le nombre d’instances maximum par groupe, ce service ne permettra pas d’absorber une trĂšs forte montĂ©e en charge. La configuration devra ĂȘtre affinĂ©e en fonction des besoins.

Les mises Ă  jour des systĂšmes et des outils sont Ă©galement Ă  la charge des Ă©quipes.

Avantages liĂ©s Ă  l’infrastructure

La mise en place de sa propre infrastructure n’a pas que des inconvĂ©nients. Que cela soit sur EC2 ou sur son propre datacenter, la main mise sur les outils installĂ©s est totale. Le paramĂ©trage peut ĂȘtre affinĂ© autant que nĂ©cessaire lĂ  oĂč les services managĂ©s imposent des contraintes fortes dans la configuration.

Les derniĂšres versions d’outils arriveront avec du retard le temps d’ĂȘtre intĂ©grĂ©s dans les services managĂ©s alors qu’il est possible d’en bĂ©nĂ©ficier soi-mĂȘme sur une instance (Node.js 7 par exemple).

L’architecture applicative est Ă©galement plus souple et ne doit pas s’adapter au catalogue de services du provider de cloud.

Dans notre exemple, c’est l’architecture logicielle qui a construit l’infrastructure et non l’inverse.

Enfin, un autre avantage est qu’il sera facile de sortir de l’infrastructure AWS pour revenir Ă  une infrastructure interne ou bien migrer vers un autre provider de cloud. Seule la partie infrastructure devra ĂȘtre retouchĂ©e, la partie applicative Ă©tant normalement non impactĂ©e par ce changement.

 

Solution 2 : Serverless & services managés

Ici le principe est de gĂ©rer le moins de serveurs possible en s’appuyant au maximum sur les services managĂ©s fournis par AWS. Les choix de la solution et des technologies vont de fait ĂȘtre influencĂ©s par l’offre AWS.

Choix des technologies Compute

Le code mĂ©tier est dĂ©veloppĂ© en Node.js. Chaque Ă©tape est un microservice implĂ©mentant les diverses rĂšgles de gestion nĂ©cessaires au bon fonctionnement de l’application. Pour l’exĂ©cution, Lambda est un parfait candidat car il permet de se focaliser uniquement sur le code fonctionnel et non pas sur les problĂ©matiques d’installation, de dimensionnement d’infrastructure, de montĂ©e en charge, etc.

Ce choix est d’autant plus judicieux que le traitement de chaque message est court (de l’ordre de quelques secondes) et que l’application fonctionne uniquement quelques heures par jour.

Base de données du référentiel

Le catalogue de services AWS propose diffĂ©rents types de bases de donnĂ©es allant du relationnel (Oracle, Aurora, MySQL, PostgreSQL, SQL Server, MariaDB) au NoSQL (DynamoDB) en passant par des clusters de cache (Redis, Memcached). Le choix s’est arrĂȘtĂ© sur la base relationnelle MySQL qui dispose de fonctionnalitĂ©s JSON facilitant le stockage et la manipulation des POI. En d’autres termes, certaines donnĂ©es de rĂ©fĂ©rence sont dans des tables tandis que le contenu des POI est stockĂ© directement en format JSON dans une colonne.

Toutes les bases de donnĂ©es relationnelles proposĂ©es par AWS sont incluses dans le service Relational Database Service (RDS). Il facilite l’installation, l’administration (backup, restauration) et la haute disponibilitĂ© en proposant nativement un dĂ©ploiement multi-zones de disponibilitĂ©. Toutes ces fonctionnalitĂ©s sont activables en quelques clics dans la console, dans CloudFormation, dans le SDK ou la CLI.

Moteur de recherche

Le choix du moteur de recherche n’est pas aussi riche que pour les base de donnĂ©es. Deux services managĂ©s sont proposĂ©s : CloudSearch et Elasticsearch Service. Le premier est propriĂ©taire et entiĂšrement managĂ© par AWS. Le second, open-source et dĂ©veloppĂ© par la sociĂ©tĂ© Elastic.co, est moins managĂ©. Bien qu’il faille un peu plus de configuration et d’intĂ©gration, notamment sur le scalling, les backup et les restaurations, Elasticsearch Service est retenu car le client souhaite utiliser des technologies standard du marchĂ©.

Infrastructure

Une fois les briques logicielles définies, il reste à les intégrer entre elles pour produire la chaßne de traitement.

Communication entre les Ă©tapes

Chaque Ă©tape mĂ©tier (collecte, mapping, stockage, indexation) est dĂ©veloppĂ©e dans une Lambda qui fait office de micro-service. La communication entre les micro-services est assurĂ©e grĂące Ă  des files SQS. AWS ne proposant pas le dĂ©clenchement de Lambda sur les files SQS, il a fallu dĂ©velopper une Lambda de polling pour lancer le traitement. Hormis cette « tuyauterie » interne, la manipulation de SQS est facile grĂące au SDK JavaScript. Bien qu’utilisant les services managĂ©s AWS, les appels RDS MySQL et Elasticsearch se font Ă  l’aide des SDK officiels des produits.

Reprise

Pour l’analyse et la reprise sur erreurs, les POI non traitĂ©s sont envoyĂ©s dans des Dead Letter Queue (DLQ) SQS. Ce mĂ©canisme est inclus automatiquement dans la configuration d’une file SQS (Use Redrive Policy).

Monitoring

Le monitoring et l’alerting sont dĂ©lĂ©guĂ©s Ă  CloudWatch. Sur chaque DLQ est positionnĂ©e une alarme relative au nombre de messages prĂ©sents. Trop de messages simultanĂ©s indiquent une erreur inhabituelle dans le traitement.

Les mĂ©triques d’Elasticsearch (espace disque, nombre de documents, nombre de nƓuds, CPU, mĂ©moire
) sont remontĂ©es automatiquement dans CloudWatch. A l’instar des DLQ elles peuvent aussi faire l’objet d’alarmes. Le service RDS propose les mĂȘmes fonctionnalitĂ©s.

CloudWatch est doublement intĂ©ressant car il fournit un service de monitoring et d’alarme intĂ©grĂ© avec SNS (Simple Notifications Service). Au dĂ©clenchement d’une alarme il est possible de :

  • ExĂ©cuter une lambda
  • Envoyer un SMS
  • Appeler un webhook HTTP ou HTTPS
  • Envoyer un email

Petit plus, Cloudwatch s’interface avec les outils traditionnels de supervision tels que Grafana ou Elasticsearch/Kibana.

Elasticité

Avec AWS Lambda, la modulation de l’infrastructure en rapport Ă  la charge est automatique. AWS instancie plus de lambdas quand le nombre de requĂȘtes augmente et en retire s’il diminue. Attention, par dĂ©faut tout compte est limitĂ© Ă  1000 exĂ©cutions parallĂšles. NĂ©anmoins une simple demande au support d’AWS suffit Ă  augmenter ce plafond.

Pour MySQL, MariaDB et PostgreSQL, Amazon RDS supporte les rĂ©plicas en lecture en utilisant la rĂ©plication asynchrone native de ces moteurs. Les rĂ©plicas en lecture fonctionnent comme une instance de base qui n’ autoriserait que des connexions en lecture seule. Cependant dans notre cas d’utilisation la base est fortement sollicitĂ©e en Ă©criture et peu en lecture. Seule une scalabilitĂ© verticale convient. Le levier se situe dans le choix du type d’instance (db.t2.large, db.r3.2xlarge, db.m4.xlarge…) qui peut intervenir n’importe quand, au prix d’une interruption de service de quelques minutes.

Le service Elasticsearch n’est pas automatiquement Ă©lastique car le nombre de nƓuds du cluster n’est pas gĂ©rĂ© automatiquement par AWS. Il est cependant possible de mettre Ă  l’échelle le cluster via un appel d’API ou en quelques clics dans la console.

Avantages liés au cloud

AWS fournit une solution complĂšte et homogĂšne pour gĂ©rer un projet de bout en bout. Du calcul au stockage en passant par le monitoring tous les outils sont Ă  disposition. Bien que la crĂ©ation d’une infrastructure soit facilitĂ©e, une certaine expertise est recommandĂ©e pour obtenir une architecture pĂ©renne, sĂ©curisĂ©e et performante.

Avec Lambda (AWS), Functions (Azure), les providers de Cloud surfent sur la vague serverless dont la promesse est de se focaliser sur le code mĂ©tier plutĂŽt que dans des sempiternelles considĂ©rations opĂ©rationnelles (maintenance, patch de sĂ©curitĂ©, uptime, mise Ă  l’échelle
).

ComparĂ© Ă  une infrastructure on-premise, l’adaptation au changement et le Time to Market sont dĂ©routants. Besoin de plus de files de messages ? De changer la base de donnĂ©es ? Ou encore d’auditer l’architecture ? Quelques appels d’API suffisent.

ProblĂ©matiques liĂ©es Ă  l’infrastructure

Choisir une architecture basĂ©e sur des services managĂ©s oriente le choix des briques logicielles. Par exemple sur AWS, si un projet nĂ©cessite une base de donnĂ©es NoSQL, la premiĂšre action sera de regarder si le besoin peut convenir Ă  DynamoDB. De mĂȘme pour le domaine de la recherche avec Elasticsearch en tant que service. Autre exemple concret, que nous avons vu dans le cas fonctionnel de cet article, le broker de message de l’architecture on-premise a Ă©tĂ© remplacĂ© par du SQS pour simplifier la mise en oeuvre et l’exploitation.

Ces choix induisent du vendor lock-in. Quid alors de la rĂ©versibilitĂ© ?  Sur ce point deux Ă©coles s’opposent :

  • Accepter le vendor lock-in : la reversibilitĂ© n’est pas Ă  penser Ă  priori au risque d’utiliser le plus petit dĂ©nominateur commun Ă  toutes les plateformes, Ă  savoir du IaaS et de se priver ainsi de tous les avantages des services managĂ©s. La rĂ©versibilitĂ© doit ĂȘtre abordĂ©e en temps voulu pour prendre en compte tous les aspects et conduire ainsi Ă  un vĂ©ritable projet de migration.

  • Refuser le vendor lock-in : la rĂ©versibilitĂ© doit ĂȘtre pensĂ©e dĂšs le dĂ©part pour ne pas s’enfermer sur une plateforme. Entre la rĂ©daction du document de rĂ©versibilité adĂ©quat et l’intĂ©gration manuelle de diffĂ©rentes briques pour pallier la non utilisation de services managĂ©s, cela demande plus de travail.

Conclusion

Il est difficile de comparer les deux solutions tant le choix de l’une ou de l’autre va impacter l’ensemble de l’architecture. Ceci est vrai d’un point de vue infrastructure bien entendu mais Ă©galement sur la partie code.

Comme nous l’avons vu, une architecture serverless avec services managĂ©s ne signifie en aucun cas « sans infrastructure ». S’il est vrai que les problĂ©matiques machines sont dĂ©lĂ©guĂ©es Ă  l’hĂ©bergeur, il n’en reste pas moins nĂ©cessaire d’avoir une bonne maĂźtrise des services managĂ©s utilisĂ©s.

Ces services ont par ailleurs un impact fort dans le code de l’application. La panoplie d’outils offerte est Ă©galement limitĂ©e Ă  ceux proposĂ©s par l’hĂ©bergeur (ici AWS).

D’un autre cĂŽtĂ©, une architecture micro-services avec une infrastructure maison offre une plus grande souplesse dans le choix des outils mais aussi dans l’articulation des micro-services de l’architecture logicielle. La contrepartie de ce choix est l’obligation de gĂ©rer soi-mĂȘme l’infrastructure. Si AWS offre de multiples services pour simplifier ces phases (autoscaling automatique, provisioning de machines simple), la mise en place et la maintenance de l’infrastructure maison a un coĂ»t non nĂ©gligeable dans la conception de l’application mais aussi dans sa vie en phase de production.

Si une Ă©quipe possĂšde dĂ©jĂ  des Ops (administrateurs systĂšme) expĂ©rimentĂ©s et que la visibilitĂ© sur la charge Ă  venir est suffisante, le choix d’une infrastructure maison peut ĂȘtre pertinent.

A contrario, si le vendor lock-in n’est pas un point de blocage, si l’équipe a peu de bande passante pour le dĂ©veloppement d’une infrastructure et si la charge attendue sur l’application est inconnue, alors une architecture basĂ©e sur du serverless et des services managĂ©s est un choix pertinent. Celui ci permettra de sortir plus rapidement l’application et de gagner en sĂ©curitĂ© sur la montĂ©e en charge.

Enfin, et c’est sans aucun doute un choix pertinent sur des applications de plus grande ampleur, un mix des deux mondes est tout Ă  fait possible et permettra d’avoir une infrastructure souple sur certaines parties et totalement maĂźtrisĂ©e sur d’autres.

Catégories: Blog Société

Meetup : Apprendre Redux avec React Native

mer, 06/14/2017 - 11:00

Xebia a le plaisir d’accueillir le lundi 26 juin le meetup HackJam – Learn Redux with React Native. Un HackJam est une soirĂ©e d’Ă©change de connaissances et d’apprentissage autour des technologies Javascript.

C’est un Ă©vĂ©nement gratuit ouvert Ă  tous les dĂ©veloppeurs. Rendez-vous :

Xebia, 7e Ă©tage

156 Boulevard Haussmann,

75008 Paris

Ă 

18h30

Objectifs du HackJam

Ce HackJam a pour objectif l’apprentissage de Redux en dĂ©buggant une application React Native.

En plus de bĂ©nĂ©ficier d’une introduction Ă  Redux, vous devriez ĂȘtre en mesure de rĂ©pondre Ă  ces questions Ă  la fin de la soirĂ©e :

  • Comment gĂ©rer l’Ă©tat dans mon application avec Redux ?
  • Comment simplifier mes composants en extrayant la logique ?
  • Comment rendre mes composants rĂ©utilisables ?
  • Comment intĂ©grer Ajax avec Redux ?

Comme d’habitude, vous commencerez la soirĂ©e avec une application buggĂ©e, que vous devrez rĂ©parer en moins de trois heures avec l’aide des mentors. Cette mĂ©thode a fait ses preuves en tant que mĂ©thode efficace d’apprentissage de nouveaux concepts.

Prérequis
  • Avoir une bonne connaissance de Javascript.
  • Apporter votre ordinateur.
  • Avoir NodeJS (en version 6 minimum) et Git installĂ© sur votre machine.
  • Installez aussi Expo XDE.

Nous commencerons cette soirée à 18h30. Il y aura de la nourriture pour recharger vos batteries avant de commencer le défi.

N’hĂ©sitez pas Ă  vous inscrire et Ă  inviter vos amis et collĂšgues !

Catégories: Blog Société

XEBIA’S MOBILE THINGS S01E07 – PrĂ©sentation du SDK drone par Parrot

jeu, 06/08/2017 - 17:00

Dans les prĂ©cĂ©dents rendez-vous Mobile Things nous avons parlĂ© clean architecture, intĂ©gration continue et mĂȘme IoT. Pour ce nouveau rendez-vous nous recevons Djavan Bertrand de Parrot qui prĂ©sentera le SDK drone de Parrot qui permet d’interagir avec les nombreux objets connectĂ©s de Parrot. Ce Mobile Things se dĂ©roulera le 28 juin Ă  partir de 19h30 chez Xebia.

Présentation et Workshop

Cette soirée se déroulera en deux parties : une introduction au SDK drone puis un workshop. De nombreux drones seront disponibles pour tester le SDK et créer vos premiÚres applications.

Nous vous donnons donc rendez-vous le 28 juin à 19h30 dans les locaux de Xebia, au 7Úme étage du 156 boulevard Haussmann 75008 Paris.

Nous vous invitons à vous inscrire, dÚs à présent, sur ce lien eventbrite.

Comme d’habitude, cet Ă©vĂ©nement se prolongera autour d’un verre pour Ă©changer et partager vos expĂ©riences avec la communautĂ© mobile.

Catégories: Blog Société

Revue de Presse Xebia

jeu, 06/08/2017 - 16:00

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.


revue de presse Xebia

Mobilité Apple annonce iOS11 http://blog.xebia.fr/author/nullhttp://twitter.com/nullhttp://github.com/mbretonPar JC Pastant

Comme Ă  son accoutumĂ©, Apple a prĂ©sentĂ© durant la WWDC 2017 la derniĂšre version de OS phare : iOS 11. Peu de nouveautĂ©s pour les dĂ©veloppeurs cette annĂ©e, on retiendra sutout l’ajout du drag&drop ainsi qu’un gestionnaire de fichiers qui vous permettra (enfin !) de parcourir les donnĂ©es stockĂ©es sur votre iPhone/iPad comme sur un mac.

Apple s’ouvre au VR et au AR http://blog.xebia.fr/author/nullhttp://twitter.com/nullhttp://github.com/mbretonPar JC Pastant

Comme attendu, Apple a annoncĂ© le support de la VR (Virtual Reality) sur macOS et iOS via une mise Ă  jour de son framework graphique Metal joliment appelĂ©… Metal 2 !

Dans le mĂȘme temps, iOS hĂ©rite d’un framework pour rĂ©aliser des scĂšnes en AR (Augmented Reality) : ARKit. Et le rĂ©sultat semble rĂ©ussi !

DevOps Overview de l’orchestration de conteneurs avec Kubernetes http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Cette semaine, un des ingĂ©nieurs de Onfido partage avec nous un trĂšs bon rĂ©sumĂ© de l’orchestration de conteneurs avec Kubernetes sur de l’AWS, dans un cadre d’intĂ©gration continue.

En effet, partant de la base en rappelant pourquoi le besoin d’orchestration se prĂ©sente rapidement lorsque l’on travaille avec des conteneurs, il y prĂ©sente les principaux concepts de Kubernetes (master/worker, notion de pod et de deployment, daemonset et replicaset, etc).

Prenant ensuite en compte le fait que le « Kubernetes as a Service » de Google Cloud (GCP) est une solution idĂ©ale d’orchestration, il prĂ©sente nĂ©anmoins la solution qu’ils ont retenue pour gĂ©rer leur propre cluster Kubernetes sur AWS. Il en profite donc pour rapidement faire le tour de certaines solutions d’automatisation de dĂ©ploiement d’un cluster Kubernetes (kops, Tectonic, kube-aws et Kraken 2) ainsi que les rĂ©sultats de leurs essais de ces solutions.

Enfin, la partie « comment dĂ©ployer une application sur Kubernetes depuis un Pipeline Jenkins » est abordĂ©e, s’Ă©tendant sur l’exposition du service ainsi dĂ©ployĂ©.

Pour conclure, les problématiques de logging et monitoring sont rapidement évoquées, ainsi que la partie maintenance avec les points à surveiller.

Un bon rĂ©sumĂ© d’un des chemins qu’il est possible de suivre losque l’on se lance dans l’orchestration de conteneurs !

Comment faire tourner Chrome (headless)… dans une lambda sur AWS http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Avec la popularisation des notions de craftmanship, on parle de plus en plus de browser « headless » (comprendre « faire tourner un navigateur sans avoir celui-ci affichĂ© Ă  l’Ă©cran ») permettant notamment de simuler des tests d’applications web sur plusieurs navigateurs.

CĂŽtĂ© Cloud et DevOps, la mouvance « serverless » prend Ă©galement de l’ampleur, avec le service AWS Lambda en tĂȘte de file.

Voici donc un article qui propose de combiner ces 2 points… en faisant tourner Chrome dans une lambda. Du lancement de Chrome lui-mĂȘme en mode headless Ă  la gestion de la lambda, cet article se trouve ĂȘtre Ă  la fois lĂ©ger et trĂšs intĂ©ressant puisque dĂ©taillant des points rarements abordĂ©s. Une bonne lecture pour une fin de semaine !

Catégories: Blog Société

Le TechTrends Conteneurs en exclusivité lors du Paris Container Day.

mer, 06/07/2017 - 11:00

Pour la deuxiĂšme Ă©dition du Paris Container Day, le 13 juin prochain, Xebia et Wescale n’arriveront pas les mains vides. Les 400 participants pourront dĂ©couvrir en exclusivitĂ© le nouveau TechTrends, dĂ©diĂ©… aux conteneurs !

DĂ©couvrir le TechTrends Conteneurs

Classiquement, les dĂ©veloppements logiciels dans les entreprises s’organisent en suivant trois grandes phases : la construction, le dĂ©ploiement et la production. Quels que soient le langage ou la technologie utilisĂ©s, la phase de construction est bien souvent mature en termes d’outillage et de standardisation. Pour le dĂ©ploiement, il existe diffĂ©rents outils d’automatisation permettant d’utiliser des solutions adaptĂ©es Ă  chaque technologie. Si l’on s’intĂ©resse au run, il existe aussi des solutions automatisĂ©es. Cependant, dans l’ensemble, ces outils manquent de standardisation et nĂ©cessitent encore aujourd’hui un grand nombre de tĂąches manuelles lors des opĂ©rations de dĂ©ploiement et de run. Les conteneurs permettent de standardiser ces diffĂ©rentes phases. Ils fournissent un modĂšle de packaging, de dĂ©ploiement et d’exĂ©cution. Ce modĂšle est reproductible et portable. Il s’applique tout aussi bien aux solutions techniques sous Linux qu’à celles sous Windows.

L’utilisation de ce nouveau modĂšle permet de fiabiliser l’ensemble de la chaĂźne de delivery en dĂ©finissant un standard commun du dĂ©veloppement Ă  la production tout en garantissant une portabilitĂ© optimale. Par nature, les conteneurs favorisent l’adoption d’organisation DevOps, car ils concernent l’ensemble de la chaĂźne de delivery.

Le succĂšs des conteneurs est liĂ© Ă  trois facteurs : la maturitĂ©, la simplicitĂ© et le packaging. En effet, les solutions d’exĂ©cution conteneurisĂ©es ne sont pas nĂ©es de la derniĂšre pluie. Les namespaces permettent d’isoler un ensemble de processus et de ressources sous Linux depuis 2002. C’est en 2008 que les choses s’accĂ©lĂšrent avec la crĂ©ation des cgroups, qui permettent de maĂźtriser les ressources allouĂ©es aux processus. Ce moment correspond Ă  la naissance des premiers PaaS dont AppEngine, DotCloud et Mesos qui reposent tous dĂšs le dĂ©part sur la conteneurisation. Mais c’est aussi l’annĂ©e de naissance du projet LXC ou Linux Containers, qui fournit un ensemble d’outils et d’APIs facilitant la crĂ©ation et la gestion des conteneurs d’application ou de systĂšme.

Enfin, en 2013, l’émergence de Docker popularise leur utilisation. Avec ce nouvel outil, la technologie est devenue abordable et facile Ă  utiliser. Docker fournit, de plus, un modĂšle de packaging accompagnĂ© d’un systĂšme de distribution et de dĂ©ploiement simple, rapide et efficace. Aujourd’hui, les images, tout comme les “wars” dans l’écosystĂšme Java, offrent la garantie d’un package portable pouvant ĂȘtre exĂ©cutĂ© sur tous les systĂšmes supportant les cgroups et les namespaces. Les conteneurs offrent donc l’opportunitĂ© d’innover rapidement avec une rĂ©versibilitĂ© Ă  moindre effort.

Comment pouvez-vous tirer parti de ce nouveau paradigme de packaging et de déploiement ?

‱ Dans quels contextes leur utilisation est-elle adaptĂ©e ?

‱ Quels sont les dĂ©fis techniques Ă  adresser ?

‱ Comment tirer le meilleur de la chaüne de delivery avec ces solutions ?

Pour dĂ©couvrir la suite, rendez-vous au Paris Container Day. Il ne vous reste que quelques jours avant l’Ă©vĂ©nement, rĂ©servez vite votre place.

Le TechTrends Conteneurs, est disponible en téléchargement PDF et EPUB sur xebia.fr.

Redécouvrir les autres TechTrends

Les TechTrends sont l’expression du savoir faire des Xebians ; forgĂ© sur le terrain, auprĂšs des clients dans le cadre des projets que nous menons avec eux. Vous y trouverez les nouvelles tendances technologiques et mĂ©thodologiques ainsi que l’état de l’art de notre profession.

Nous tentons de dispenser des conseils directement opérationnels afin de vous guider dans les décisions stratégiques que vous avez à prendre.

Redécouvrez dÚs à présent les différents TechTrends :

Ne manquez pas la nouvelle formation de Xebia Training dédiée aux conteneurs

Xebia Training est fiĂšre de prĂ©senter sa formation dĂ©diĂ©e Ă  l’écosystĂšme des Conteneurs et de Docker, initiĂ©e par deux Xebians, Alexis « Horgix » Chotard et Julien Bonachera.

Cette formation de 4 jours commence par une partie de théorie sur les conteneurs : que sont-ils vraiment ? Pourquoi ont-ils été créés ? Quels en sont les usages ?

Suite Ă  cette partie globale sur les conteneurs, Docker sera abordĂ©, tout d’abord d’un point de vue basique (comment crĂ©er un conteneur Docker et le gĂ©rer), puis d’un point de vue plus avancĂ© et rĂ©ellement concret (applications multi-conteneurs, gestion du rĂ©seau, du placement des donnĂ©es, etc.). Pour finir, la formation couvrira les nouvelles problĂ©matiques mises sur le devant de la scĂšne avec les conteneurs et les environnements dynamiques, temporaires et hautement distribuĂ©s : orchestration, microservices, etc. Bien Ă©videmment, tous ces sujets ne sont pas uniquement traitĂ©s de maniĂšre thĂ©orique : chaque demi-journĂ©e a son lot de « hands-on » avec des mises en pratique concrĂštes : rien ne vaut l’expĂ©rimentation par soi-mĂȘme ! Pour plus de dĂ©tails, rendez-vous sur le site Xebia Training.
Catégories: Blog Société

Offres promotionnelles formations MĂ©thodes Agiles, Big Data et DevOps

ven, 06/02/2017 - 12:41
 

Xebia Training Logo

Software & Agile Training Done Right

PROMOTIONS EXCEPTIONNELLES

 

 

Formations certifiantes agiles

Formation ScrumMaster certifiante de la Scrum Alliance

29-30 juin 2017
25-26 septembre 2017

1 540€ HT 1 440€ HT

En savoir plus

Formation Scrum Product Owner certifiante de la Scrum Alliance

14-15 septembre 2017
26-27 juin 2017

1 540€ HT 1 440€ HT

En savoir plushttp://training.xebia.fr/formation/certification-scrum-product-owner-francais/

 

Formations Management 3.0 certifiantes

12-13 juillet 2017
27-28 septembre 2017

1 735€ HT 1 535€ HT

 

En savoir plus

@

 

 

 

 

  AgilitĂ© Ă  l’Ă©chelle
(SAFe)

   

Formation Leading SAFe certifiante de la Scaled Agile Academy

29-30 juin 2017
12-13 juillet 2017

1 540€ HT 1 240€ HT

En savoir plus

 

NEW

Formation SAFe Program Consultant certifiante (SPC4) de la Scaled Agile Academy

23-26 octobre 2017

En savoir plus

 

Formation Product Manager/Product Owner certifiante
de la Scaled Agile Academy

26-27 juin 2017

1 540€ HT 1 240€ HT

En savoir plus

 

 

 

 

 

  DevOps

 

NEW
Formation Conteneur et Docker

3-6 octobre 2017

2 400€ HT 2 000€ HT

En savoir plus

 

NEW
Formation « Les fondamentaux de DevOps » certifiante de D.A.S.A

30 oct- 1 nov 2017

1 995€ HT 1 795€ HT

En savoir plus

 


Big Data

 

Formation Hadoop/Spark pour développeurs certifiante de Cloudera

4-7 juillet 2017
17-20 octobre 2017

2 995€ HT 2 795€ HT

En savoir plus

NEW
Formation Data Analyst certifiante de Cloudera

18-20 septembre

2 870€ HT 2 570€ HT

En savoir plus

NEW
Formation Apache Kafka Ops de Confluent

18-19 septembre 2017

En savoir plus

Formation Elasticsearch avec Ivan Beauvais

8-10 novembre 2017

1 700€ HT 1 300€ HT

En savoir plus

 

Formation Analyse de données et Machine Learning avec Spark

12-14 juin 2017
25-27 septembre 2017

2 100€ HT 1 800€ HT

En savoir plus

NEW
Formation Apache Kafka pour développeurs officielle de Confluent

22-24 novembre

En savoir plus

Formation MongoDB Essentials officielle de MongoDB Inc

21-24 aout 2017

En savoir plus

Formation Hadoop pour administrateurs certifiante de Cloudera

28-31 août 2017

2 995€ HT 2 795€ HT

En savoir plus

  Si ces formations vous intĂ©ressent, n’hĂ©sitez pas Ă  nous contacter sur info@xebia-training.fr ou par tĂ©lĂ©phone au 01 53 89 99 93 .

Catégories: Blog Société

Revue de Presse Xebia

jeu, 06/01/2017 - 16:00

revue de presse Xebia

La revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

Back Sortie de Node.js v8.0.0 http://www.gravatar.com/avatar/5e5c1678327320ceea9f4f4dff0d66edhttp://blog.xebia.fr/author/pgdejardinhttp://twitter.com/pgdejardinhttp://github.com/pgdejardinPar Paul-Guillaume DĂ©jardin

La nouvelle version de Node.js vient tout juste de sortir et apporte son lot de nouveautés. Vous pourrez y trouver :

  • NPM en version 5.0.0.
  • Un upgrade du moteur V8 en version 5.8 (qu’ils prĂ©voient si c’est possible de monter jusqu’Ă  la version 6.0).
  • Une nouvelle API Node.js (N-API) pour dĂ©velopper des addons et les utiliser sur diffĂ©rentes plateforme ou version de Node.js.
  • L’arrivĂ© de async_hooks permettant de mieux monitorer les operations de Node.js event loop et ainsi permettre de meilleurs diagnostics.
  • WHATWG URL Parser est maintenant stable et utilisable.
  • Quelques changements sur l’API Buffer, avec l’instantiation par dĂ©faut retournera une instance d’un buffer Ă  0 (zero-filling) afin d’Ă©viter des problĂšmes de sĂ©curitĂ©.
  • util.promisify qui permet de wrapper une callback d’une API afin de retourner une promise, comme le permettait Bluebird.

Cette liste n’est qu’une partie des nouveautĂ©s de cette upgrade. La liste complĂšte et leurs explications sont disponibles sur le blog de Node.js. Cette version 8 sera en LTS Ă  partir de novembre 2017.

DevOps Retour sur les outils d’investigation modernes par Weaveworks http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Weaveworks nous partage cette semaine un retour d’expĂ©rience sur les outils d’investigation modernes.

Ce tour d’horizon est vraiment complet : du monitoring avec Prometheus, au dĂ©tail du traçage des requĂȘtes avec OpenTracing, en passant par les outils de profilage CPU et mĂ©moire pour Go, pour finir par les dĂ©tails d’implĂ©mentation de la sĂ©rialisation de leurs messages avec Protobuff; le tout pour dĂ©tailler comment ils ont pu passer de 80ms de latence d’Ă©criture sur un de leurs composantss Ă  25ms.

De vrai dĂ©tails d’investigation sur un problĂšme de performances, mĂ©triques Ă  l’appui, et avec une conclusion pertinente; que demander d’autre ?

Autoscaling de noeuds Jenkins sur GCE par Shazam http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Shazam nous parle de son autscaling de slaves jenkins sur GCE (Google Cloud Engine) dans une optique de réduction de coûts.

En effet, Ă  l’heure actuelle, la plupart des Ă©quipes se reposent sur Jenkins pour leur intĂ©gration continue. Avec l’avĂšnement des conteneurs et des services Ă  la demande, il devient de plus en plus courant de parler de « slaves de CI » Ă  la demande : des noeuds temporaires n’ayant d’autre raison d’exister que de faire tourner un pipeline Ă  un instant donnĂ©. Sans aller jusqu’Ă  des noeuds temporaires conteneurisĂ©s, Shazam nous prĂ©sente ses « Jenkins Node Auto Scaler » (jNAS), qui s’occupe d’autoscaler des slaves Jenkins sur le cloud de Google en se basant sur le nombre de jobs en attente dans la queue Jenkins.

Releases : Grafana, Terraform, Prometheus et Traefik http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Comme chaque mois désormais, voici un résumé des principales releases intéressantes ayant eu lieu ce mois-ci :

  • Grafana 4.3 vient de sortir : les principaux points Ă  retenir sont la gestion de MySQL en backend, l’amĂ©lioration des panels dont un nouveau pour crĂ©er des heatmaps, l’ajout d’un endpoint de healthcheck, ainsi que la possibilitĂ© d’automatiquement afficher une colonne par label dans les tableaux ayant pour source Prometheus, ce qui peut s’avĂ©rer trĂšs utile par exemple pour avoir un dashboard d’alertes !
  • Terraform 0.9.5 vient de son cĂŽtĂ© avec la gestion de Gitlab comme provider ainsi qu’avec le support de nouvelles sources de donnĂ©es et de nouvelles ressources.
  • Prometheus ont annoncĂ© leur nouvelle version majeure, la 2.0, se focalisant notamment sur l’aspect performances et consommation de ressources grĂące Ă  un tout nouveau layer pour le stockage des mĂ©triques; les benchmarks inclus dans l’annonce parlent d’eux-mĂȘme.
  • La release 1.3 de Traefik vient tout juste de sortir : au programme se trouve notamment la possibilitĂ© de configurer de l’authentification basique par frontend (par service donc, le frontend/backend ici Ă©tant les notions de load balancing et non des composants d’une application). On notera Ă©galement la possibilitĂ© de stocker la configuration de Traefik dans DynamoDB ainsi que la possibilitĂ© de filtrer les services dans le dashboard. Enfin, le cycle de release de Traefik Ă©volue pour passer de 4 Ă  2 mois (notamment grĂące aux 4 dĂ©veloppeurs embauchĂ©s suite Ă  leur levĂ©e de fonds) et il semble qu’ils fournissent dĂ©sormais une image Docker se basant sur alpine en plus de celle n’incluant que le binaire, pour ceux qui dĂ©sireraient avoir au moins un shell pour investiguer ou qui voudraient s’assurer que les certificats de confiance sont installĂ©s de maniĂšre connue.
Catégories: Blog Société

GĂ©rer les conflits dans une Ă©quipe agile

mar, 05/30/2017 - 16:00

En tant que coach ou Scrum Master d’une Ă©quipe, comme en tant que manager, on peut ĂȘtre confrontĂ© Ă  des conflits qui entravent le changement, compromettent la performance ou le bien-ĂȘtre des personnes.

Voici, au travers de cet article, un partage de mes outils et de quelques-unes de mes expériences avec les conflits.

Le rĂŽle du coach dans le conflit

Les membres d’une Ă©quipe agile interagissent en permanence, avec une grande autonomie. Ils sont en nĂ©gociation permanente avec leurs collĂšgues pour se rĂ©partir le travail, se mettre d’accord sur des solutions, etc. Cette proximitĂ© crĂ©e nĂ©cessairement des conflits, de diffĂ©rents degrĂ©s au sein de l’Ă©quipe. De plus, Ă  l’inverse des « équipes projet » traditionnelles, les Ă©quipes agiles restent ensemble Ă  temps plein, et sur de bien plus longues pĂ©riodes. Les conflits ne disparaissent donc pas d’eux-mĂȘmes.

L’attitude la plus naturelle pour la plupart des coachs ou des Scrum Masters, Ă  l’instar d’un chef ou d’un manageur traditionnel, c’est de chercher Ă  rĂ©soudre activement le conflit. Mais il existe d’autres modes de rĂ©ponse souvent bien plus puissants.

Les niveaux de conflit

Tout d’abord, qu’entendons-nous par conflit ? S’agit-‘il d’un dĂ©saccord, prĂ©mice Ă  une solution commune et optimale, ou d’une lutte acharnĂ©e visant Ă  dĂ©truire l’autre ?  Speed Leas, auteur de diffĂ©rents livres sur le sujet, considĂšre qu’il y a 6 niveaux de conflits. Le niveau 0 : la dĂ©pression, est dĂ©fini par « de la colĂšre tournĂ©e vers soi-mĂȘme« . Je ne parlerai pas de ce niveau bien particulier dans cet article. Voici donc les 5 autres niveaux :

Niveau 5 : La guerre mondiale

L’objectif est de dĂ©truire l’autre. L’Ă©change a disparu ou est ouvertement insultant. Les personnes peuvent en venir aux mains.

Niveau 4 : La croisade

Le but n’est plus seulement de « vaincre », mais aussi de se dĂ©barrasser des personnes. Les clans s’affrontent par principes interposĂ©s.

Niveau 3 : La compétition

L’objectif n’est plus de rĂ©soudre un problĂšme ni de faire valoir ses idĂ©es, mais de « vaincre ». Des attaques personnelles sont Ă©changĂ©es. Des clans se forment. Le problĂšme est distordu, difficile Ă  dĂ©finir.

Niveau 2 : Le désaccord

Il y a un dĂ©saccord que l’Ă©change ne permet pas de faire disparaĂźtre. Les personnes Ă©prouvent des difficultĂ©s Ă  collaborer, le langage devient sujet Ă  interprĂ©tation, lĂ©gĂšrement personnel.

Niveau 1 : Le problÚme à résoudre

Il y a un problĂšme Ă  rĂ©soudre. L’Ă©quipe collabore et Ă©change des idĂ©es et des faits afin de trouver la meilleure des solutions.

Au delĂ  de la thĂ©orie, cette catĂ©gorisation se rĂ©vĂšle utile pour ensuite identifier les techniques les plus appropriĂ©es pour apprĂ©hender le conflit par la suite…

Les modes de réponse du coach 1Úre réponse : Ne rien faire

Les Ă©quipes agiles, mĂȘmes les nouvelles, sont tout Ă  fait capables de rĂ©soudre un certain nombre de leurs conflits. La meilleure chose Ă  faire pour le coach est donc d’abord de ne rien faire et d’observer. En particulier, j’aime me poser ces deux questions :

  1. Quelle trajectoire prend le conflit ? Est-il en train de monter d’un niveau ou au contraire de baisser ?
  2. Quel impact exactement ce conflit a-t-il sur la performance de l’Ă©quipe ?

Si le conflit est lentement en train de s’estomper, et si l’impact sur la performance de l’Ă©quipe est marginal, alors je reste dans ce mode de rĂ©ponse. Et ce, mĂȘme si je pense pouvoir aider l’Ă©quipe Ă  rĂ©soudre son conflit plus rapidement en intervenant. Car un des objectifs du coach est de rendre l’Ă©quipe autonome, capable de se passer du coach Ă  terme. Or en intervenant, le coach crĂ©e une dĂ©pendance qu’il aura du mal Ă  dĂ©faire par la suite.

NĂ©anmoins si vous dĂ©cidez d’intervenir – par exemple parce que vous constatez aprĂšs plusieurs semaines ou mois que le conflit s’envenime -, il y a plusieurs modes de rĂ©ponses possibles : analyser et rĂ©pondre, travailler sur le cadre, et rĂ©vĂ©ler.

2Úme réponse : Analyser et répondre

Ce mode de rĂ©ponse est bien souvent le plus naturel pour la plupart d’entre nous. Il fait appel Ă  notre esprit d’analyse, et nous donne le sentiment de « prendre les choses en main ». Dans ce mode de rĂ©ponse, nous sommes tentĂ©s de ramener le conflit Ă  un « problĂšme Ă  rĂ©soudre »; occultant ainsi les humains, et leurs Ă©motions. Ce qui est bien sĂ»r plus confortable, mais montre rapidement ses limites. Pour autant, ce mode de rĂ©ponse reste utile parfois bien sĂ»r.

Le coach commence donc par analyser la situation. VoilĂ  par exemple les questions qu’il pourra se poser :

  1. Quel est le niveau de conflit ?
  2. Comment rĂ©agirais-je si j’Ă©tais Ă  la place de A ? de B ?
  3. Du point de vue de A / de B, qu’est ce qui est en jeu dans ce conflit ?
  4. Que dois-je faire ?
  5. Quel est le meilleur timing / la meilleure occasion pour intervenir ?

Plus le niveau de conflit est bas, plus les « techniques » disponibles au coach sont nombreuses et efficaces. L’objectif du coach sera donc, Ă  dĂ©faut de faire disparaĂźtre le conflit, de chercher Ă  le faire descendre de niveau, en utilisant l’une des postures ou techniques ci-dessous.

Au niveau 1 de conflit

Le coach aide Ă  chercher une solution gagnant-gagnant. Il aide chacun Ă  exprimer son point de vue de façon intelligible pour les autres. Il collabore avec l’Ă©quipe, et aide Ă  trouver un consensus auquel tout le monde pourra adhĂ©rer. Pour cela, le coach va chercher Ă  poser les bonnes questions. Des questions qui invitent chacun Ă  prendre du recul et Ă  envisager d’avantages d’options. On parle de « questions puissantes« .

Au niveau 2 de conflit

Le coach offre son soutien au groupe. Il manifeste sa confiance et rappelle au groupe qu’il dĂ©tient les clĂ©s du conflit, et qu’il est responsable de trouver la solution. A ce niveau, le coach peut Ă©galement aider l’Ă©quipe en organisant des jeux ou ateliers autour de la collaboration. Les idĂ©es ne manquent pas dans ce registre mais je vous recommande par exemple un atelier autour du jeu Keep Talking and Nobody Explodes. Le coach peut aussi aider l’Ă©quipe Ă  identifier, ou Ă  se remĂ©morer, ses valeurs partagĂ©es; par exemple Ă  l’aide du Team Value Kit.

Au niveau 3 de conflit

A ce niveau rappelez-vous, les faits peuvent ĂȘtre distordus, et les parties prenantes sont promptes aux gĂ©nĂ©ralitĂ©s … Aussi, le coach pourra, dans le cadre d’une conversation avec tout ou partie des personnes impliquĂ©es dans le conflit, commencer par apporter du concret en ramenant l’Ă©change Ă  des faits prĂ©cis. Tout simplement en demandant « peux-tu donner un exemple de ce que tu dĂ©cris ? » par exemple. J’aime Ă©galement, lorsque je perçois de la prĂ©cipitation dans le jugement ajouter « as-tu un deuxiĂšme exemple ? ». Cette simple question peut permettre de mettre en Ă©vidence une grossiĂšre gĂ©nĂ©ralisation (exemple : « tu es irresponsable » Ă  l’encontre d’un dĂ©veloppeur qui n’aurais omis de lancer les tests qu’une seule fois). Elle montre aussi, tĂŽt dans la discussion, que vous attendez de la discussion qu’elle tourne autour de faits prĂ©cis, et non autour de gĂ©nĂ©ralitĂ©s et autres jugements de valeurs.

Le coach peut parfois aussi contribuer à apporter de la rationalité aux échanges en préparant quelques données ou métriques en amont de la discussion.

Cette approche permet rĂ©guliĂšrement de faire retomber le conflit au niveau 2. A dĂ©faut, le coach pourra aider Ă  trouver une solution accommodante pour tout le monde. Si le problĂšme peut ĂȘtre vu comme une Ă©quation, on pourra « couper la poire en deux ». Si ce n’est pas le cas et que le problĂšme tient plutĂŽt des diffĂ©rences de valeurs, le problĂšme ne se rĂ©soudra qu’au prix d’une concession d’au moins l’une des personnes sur ses valeurs; ce qui entraĂźnera forcĂ©ment une frustration que l’Ă©quipe paiera sur le long terme.

Au niveau 4 de conflit

A ce niveau, le coach doit chercher par tous les moyens Ă  maintenir un environnement sĂ»r, pour s’exprimer, et continuer Ă  travailler. Il pourra endosser ses habits de diplomate, et faire la navette pour communiquer les sentiments et opinions des uns aux autres. Le coach prendra soin de reformuler, avec les personnes, leurs critiques. Pour cela, j’essaye de tout passer Ă  la moulinette du modĂšle « AID », pour « Action, Impact, Desired Behavior ». C’est Ă  dire :

  • Qu’a fait A ? (Action)
  • Quel impact cela a-t-il eu sur B ? (Impact)
  • Qu’est-ce que B aurait aimĂ© que A fasse Ă  la place ? (Desired Behavior)

Exemples :

  • « Tu es agressif » devient « Lorsque tu (…), je me sens agressĂ©. Si quelque chose te gĂȘne dans ma façon de faire, je prĂ©fĂšrerais que tu (…) ».
  • « Tu es irresponsable » devient « Lorsque tu omets de lancer certains tests sur tes changements de code, j’ai le sentiment que tu mets en pĂ©ril notre travail Ă  tous et ça m’angoisse. J’aimerais que l’exĂ©cution des tests soit systĂ©matique, pour tout le monde ».

Le coach procĂšdera ainsi jusqu’Ă  ce que le conflit descende de niveau, afin d’alors commencer Ă  utiliser d’autres outils.

Au niveau 5 de conflit

A ce niveau de conflit – que l’on rencontre rarement en entreprise heureusement – au risque de vous dĂ©cevoir, le coach se contente d’essayer d’empĂȘcher les personnes d’en venir aux mains …

3Úme réponse : Travailler sur le cadre

Ce mode de rĂ©ponse est bien plus puissant que le mode de rĂ©ponse prĂ©cĂ©dent. Ici, le coach, conscient que le systĂšme induit le comportement, cherche Ă  modifier les processus, le cadre de travail, les rĂŽles, les pratiques d’ingĂ©nierie, mais aussi Ă  renforcer les principes et les valeurs agiles.

J’ai par exemple travaillĂ© avec une Ă©quipe responsable du dĂ©veloppement d’un produit complexe nĂ©cessitant de la recherche et du dĂ©veloppement. Les « chercheurs » Ă©taient dans une Ă©quipe, et les « dĂ©veloppeurs » dans une autre. Les relations entre ces deux groupes Ă©taient tendues – allant par moment Ă  un conflit de niveau 3 entre certaines personnes. Nous avons alors changĂ© l’organisation, au profit de 2 Ă©quipes Scrum pluridisciplinaires, avec un objectif commun, un Product Owner commun, travaillant sur un backlog de produit commun, avec des rituels communs. Quelques semaines plus tard, les conflits avaient miraculeusement disparus.

J’ai Ă©galement constatĂ© la disparition de conflits entre les dĂ©veloppeurs d’une Ă©quipe, simplement Ă  la mise en place d’un mĂ©canisme de Pull Requests. J’ai aussi assistĂ© Ă  la disparition d’un conflit entre une Ă©quipe et son Product Owner simplement grĂące Ă  une Definition of Ready. Ou encore vu progressivement s’apaiser les tensions entre un Product Owner et un Scrum Master nouvellement nommĂ©s, en renforcement les rĂŽles et les responsabilitĂ©s de chacun (notamment l’un vis-Ă -vis de l’autre).

Dans chacun de ces exemples, notez qu’il n’est pas nĂ©cessaire de parler du conflit pour qu’il se rĂ©solve ! L’objectif est la recherche d’efficacitĂ©; et la rĂ©solution du conflit un effet de bord.

4Úme réponse : Révéler

Ce mode de rĂ©ponse est Ă  la fois le plus puissant et le plus difficile Ă  manƓuvrer. Le coach cherche ici Ă  rendre l’Ă©quipe consciente de ses conflits, et consciente des vertus de la collaboration. Une bonne façon de dĂ©marrer selon moi consiste Ă  sensibiliser l’Ă©quipe Ă  la gestion des conflits; par exemple sous l’angle des niveaux de conflits ci-dessus. Le coach peut Ă©galement sensibiliser l’Ă©quipe Ă  la communication non-violente. Cette sensibilisation peut inclure un atelier dans lequel le coach amĂšnera les membres de l’Ă©quipe Ă  se faire mutuellement du feedback bienveillant et actionnable. Vous pourrez parler du « feedback wrap » de Jurgen Appelo, ou simplement du modĂšle « AID » Ă©voquĂ© plus haut. Dans ce mode de rĂ©ponse, le coach cherche donc Ă  faire grandir l’Ă©quipe puis il laisse l’Ă©quipe adresser ses conflits, grĂące Ă  cette maturitĂ© nouvelle.

Cette façon d’aborder le conflit est Ă©videmment plus difficile. Elle nĂ©cessite notamment que les propos du coach soient en phase avec son attitude. Si vous parlez communication non-violente Ă  votre Ă©quipe par exemple, vous feriez mieux de la pratiquer vous-mĂȘme pour ĂȘtre crĂ©dible. Elle est aussi potentiellement plus lente. Le coach ne doit donc pas attendre que des conflits surgissent pour commencer Ă  faire grandir l’Ă©quipe sur ces aspects.

VoilĂ  mon approche et mes quelques conseils pour une « gestion agile » des conflits. N’hĂ©sitez pas Ă  partager votre propre expĂ©rience sur le sujet dans les commentaires afin de rendre cet article encore plus utile aux autres. Si vous souhaitez aller plus loin, je vous conseille vivement les travaux de Lyssa Adkins (Coaching Agile Teams) et de Speed Leas (Discover Your Conflict Management Style), desquels cet article s’inspire amplement.

Catégories: Blog Société

XebiCon’17 : SAVE THE DATE : LA XEBICON REVIENT LE 30 NOVEMBRE 2017 !

lun, 05/29/2017 - 11:00
Save the date : rendez-vous le 30 novembre prochain !

C’est avec un grand plaisir que nous vous donnons rendez-vous pour cette nouvelle Ă©dition de la XebiCon, qui se dĂ©roulera cette annĂ©e Ă  l’Espace Grande Arche (Paris La DĂ©fense) !

Nous vous proposerons encore plus de témoignages clients, de conférences techniques et de rencontres (et évidemment plein de surprises).

Profitez dÚs-à-présent des billets « Early Bird » afin de réserver immédiatement vos places.

La XebiCon’16 est toujours disponible en vidĂ©o

Vous souhaitez revivre la journée ? Voici un résumé en 2,55 min !

 Cette édition 2016, vous a permis de découvrir 51 interventions, dont 1 keynote, 23 conférences techniques, 13 témoignages clients, 12 Fast Tracks et 3 Hands-on. Vous souhaitez en revoir certaines ? Les vidéos et présentations sont sur le site de la XebiCon.

À bientît à la XebiCon’17 !

Catégories: Blog Société

Revue de Presse Xebia

ven, 05/26/2017 - 10:58

revue de presse XebiaLa revue de presse hebdomadaire des technologies Big Data, DevOps et Web, architectures Java et mobilité dans des environnements agiles, proposée par Xebia.

 

Front Sortie de create-react-app v1.0.0 http://www.gravatar.com/avatar/6a017173192504f62b15ba840b361d57http://blog.xebia.fr/author/tsimonnethttp://twitter.com/SimonnetTomhttp://github.com/keabardPar Thomas Simonnet

Le 22 Juillet 2016, la communautĂ© React et une de ses figures de proue, Dan Abramov, lançait un boilerplate simple, efficace et supportĂ© par Facebook, pour dĂ©marrer un projet React en quelques minutes : create-react-app. Tout y Ă©tait inclus pour commencer Ă  coder immĂ©diatement, sans avoir Ă  se soucier des longues Ă©tapes de configuration inhĂ©rentes aux projets Javascript : Une suite de testing (Jest, Enzyme), une architecture de fichiers qui suit les standards actuels, une gestion des variables d’environnement etc… Mais surtout une configuration Webpack prĂ©-faĂźte, avec gestion du hot-reload, des loaders les plus communs, de babel et bien plus encore !

Depuis sa sortie, create-react-app a Ă©tĂ© trĂšs largement plebiscitĂ© (>26k stars, >3k forks) et revient encore plus fort avec sa version 1.0.0. Au menu de cette release, le passage Ă  Webpack 2 sorti il y a quelques mois, un runtime error overlay avec lien vers le code incriminĂ© directement dans votre IDE (attention, killer feature), une crĂ©ation par dĂ©faut du projet en mode Progressive Web App etc… Rendez-vous sur la page github du projet pour retrouver tous les dĂ©tails de cette release.

Est-ce que la transpilation est encore nécéssaire ? http://www.gravatar.com/avatar/bfe804724da2fe5bcf203e9246e7bb32http://blog.xebia.fr/author/adauleuhttp://twitter.com/albandauleuPar Alban Dauleu Dauleu

Depuis l’arrivĂ©e d’ES2015, la transpilation est devenue une Ă©tape nĂ©cĂ©ssaire pour produire du code moderne supportĂ© par l’ensemble des navigateurs. D’ailleurs, tous les boilerplates comme create-react-app l’inclue par dĂ©faut. Mais est-elle encore nĂ©cĂ©ssaire aujourd’hui? Dans son article « You might not need to transpile your Javascript« , Alex Ewerlöf se pose la question et alimente sa rĂ©flexion par des statistiques sur les navigateurs actuels, notamment leur support des derniĂšres features du langage Javascript. Il rĂ©pond Ă©galement Ă  une question primordiale : « A quoi ressemblera le futur sans transpilation ? »

DevOps CoreOS annoncent zetcd http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

CoreOS viennent d’annoncer zetcd, un proxy capable de traduire le protocole de Zookeeper vers un cluster etcd en backend.

Techniquement, le mapping des directories de Zookeeper vers une « flat » liste de clĂ©s cotĂ© etcd est intĂ©ressante et originale; il en va de mĂȘme pour leur implĂ©mentation d’un cross-checking capable de rĂ©partir une requĂȘte Ă  la fois vers un vrai Zookeeper et vers un cluster etcd afin d’en comparer les rĂ©sultats pour s’assurer que zetcd rĂ©agit exactement de la mĂȘme maniĂšre que Zookeeper.

CĂŽtĂ© performances, il y a bien Ă©videmment un surcoĂ»t non nĂ©gligeable, mais qui semble rester raisonnable. Gardons Ă  l’esprit qu’il ne s’agit ici que d’une version 0.1 qui sera sans aucun doute sujette Ă  de nombreuses amĂ©liorations !

Sur une note plus personnelle, je me trouvais Ă  la dotScale 2017 il y a un mois, et ai eu le plaisir de discuter avec Benjamin Hindman, co-crĂ©ateur de Mesos ainsi que co-fondateur & architecte en chef Ă  Mesosphere. j’ai abordĂ© avec lui les reproches souvent faits Ă  Zookeeper (que Mesos utilise) ainsi que l’Ă©ventualitĂ© de rendre Mesos compatible avec etcd; la conclusion a Ă©tĂ© que oui, ce serait intĂ©ressant, mais qu’il fallait que quelqu’un prenne le temps de rendre Mesos compatible avec etcd; zetcd arrive donc Ă  point nommĂ© comme solution de repli pour qui aurait dĂ©jĂ  un cluster etcd et souhaiterait s’en servir pour faire tourner Mesos, Kafka ou autre.

Le projet CNI (Container Networking Interface) rejoint la CNCF http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

La CNCF, déjà mentionnée lors de précédentes revues de presse, accueille désormais le projet CNI en son sein.

ConcrĂȘtement, CNI vient se placer entre le runtime des conteneurs et les diffĂ©rents backend rĂ©seau afin de fournir une interface standard. Le projet se dĂ©coupe en 3 parties : une spĂ©cification, un ensemble de plugins, ainsi qu’une bibliothĂšque en Go implĂ©mentant la spĂ©ficiation sus-mentionnĂ©e. Un projet qui est donc le bienvenu dans l’effort de standardisation du monde des conteneurs auquel contribue la CNCF sur tous les fronts.

Google, IBM et Lyft annoncent Istio http://www.gravatar.com/avatar/00ebd4762e0c123dd62894728ab6c94bhttp://blog.xebia.fr/author/achotardhttp://twitter.com/horgixhttp://github.com/horgixPar Alexis Horgix Chotard

Google, IBM et Lyft viennent d’annoncer Istio, un composant ayant pour but de « connecter, gĂ©rer et sĂ©curiser des microservices ».

En rĂ©sumĂ©, il s’agit d’un nouveau linkerd ou Traefik, avec bien sĂ»r quelques diffĂ©rences :

  • Contrairement Ă  Traefik mais comme linkerd, Istio supporte la gestion de requĂȘtes gRPC
  • Contrairement Ă  Traefik et linkerd, Istio ne se limite pas Ă  la couche 7 et sait directement load-balancer et gĂ©rer des flux TCP
  • NouveautĂ© diffĂ©renciante, et non des moindres, toute la partie « management/sĂ©curité » : rate limiting, gestion d’ACLs, d’authentification et d’authorization

Istio se base sur Envoy (d’oĂč la prĂ©sence de Lyft dans le trio crĂ©ateur) et a pour principal but d’en fournir une version plus complĂšte, managĂ©e et « out of the box », ciblant pour l’instant Kubernetes.

Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux