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.

Agrégateur de flux

Meetup JHipster le 29 septembre

Blog d’Ippon Technologies - il y a 4 heures 20 min

Ippon Technologies reçoit dans ses locaux parisiens, le 29 Septembre 2016, le 5ème Meetup JHipster. Il sera animé par Julien Dubois, Chief Innovation Officer chez Ippon Technologies, et surtout créateur et principal développeur de JHipster.

Au menu, retour d’expĂ©rience d’un “grand” utilisateur : Orange !

Ludovic Chanal (leader technique Java et AngularJS) et Valentin Magne (développeur fullstack) nous expliqueront comment JHipster a permis d’offrir aux conseillers clients des smart store Orange le SI sur une tablette iPad.

Puis ensuite, Julien Dubois nous fera un retour sur l’un de ces projets en cours qui traite de Data vizualisation avec Kafka & Websockets.

Informations pratiques :

3 mars 2016 Ă  partir de 19h00

47 avenue de la grande armée – 75116 Paris

MĂ©tro : Argentine

Catégories: Blog Société

Formats et méthodes de sérialisation REST

Blog d’Ippon Technologies - il y a 8 heures 46 min

Les services Web sont devenus prépondérants dans les architectures techniques actuelles, les notions de micro-services et de services API-first en sont l’exemple parfait. Bien souvent lors de la création de ces services, nous ne réfléchissons que très peu au format d’échange, nous avons tendance à utiliser des messages sérialisés en JSON ou en XML par simplicité et habitude. Néanmoins, la multiplication des services Web qu’une entreprise possède et la communication entre ces derniers peut rapidement créer des situations problématiques lors de montées en version ou de création d’un nouveau service. Il faut donc prendre en compte plusieurs facteurs afin de déterminer la solution technique à utiliser pour la création d’un service :

  • la facilitĂ© d’utilisation,
  • la flexibilitĂ©,
  • le support (communautĂ© ou entreprise),
  • la performance.

Il faut en effet être capable de mettre rapidement la solution en place, de pouvoir l’utiliser avec différents langages selon le contexte, de disposer d’une communauté suffisamment large soutenant le produit (ou une entreprise) et être performant afin de répondre le plus rapidement possible.

Dans cet article nous allons parler des diffĂ©rentes autres possibilitĂ©s qui s’offrent Ă  vous lors du choix du format de sĂ©rialisation de vos services Web et comment choisir le format correspondant Ă  vos besoins.

Pourquoi changer ?

Il existe de très nombreux formats de sĂ©rialisation : JSON, SOAP, XML-RPC, Protocol Buffers, Avro, Apache Thrift, etc. Historiquement, les premiers schĂ©mas utilisĂ©s dans les applications de service (Ă  grande Ă©chelle) sont apparus avec des formats SGML (via DTD), XML (via XSL), etc. Le protocole SOAP par exemple permet de valider les donnĂ©es transitant, mais il pose un problème de lourdeur de crĂ©ation et d’utilisation de l’application. En effet, la rigiditĂ© et la verbositĂ© du XML entraĂ®ne des surcoĂ»ts au niveau du dĂ©veloppement. Notamment au niveau des tests oĂą la construction des requĂŞte peut nĂ©cessiter l’utilisation de programme extĂ©rieurs comme “SOAP UI” par exemple. C’est une des raisons qui a entraĂ®nĂ© l’ascension du JSON, bien plus clair, mais qui oublie un peu l’aspect validation. Le JSON, très largement utilisĂ© dans les Ă©changes entre services, a permis de mettre en lumière de nombreuses solutions de sĂ©rialisation lĂ©gères et sĂ©curisantes. Pour toutes ces raisons, nous n’Ă©tudierons pas le format XML dans cet article. On peut alors se poser la question du changement de format.

Les contrats de service…

Lors de la création d’un service Web utilisant des données plus ou moins complexes, il est nécessaire de définir les types d’objets échangés. Bien souvent, il faut créer les classes représentant ces objets et c’est directement en lisant le code source que l’on obtient des informations sur leur contenu. L’utilisation de schémas permet de représenter les données transitantes de manière simple et compréhensible par le plus grand nombre. C’est un moyen efficace de savoir quel objet est obtenu ou attendu par n’importe quel utilisateur du service. On peut ainsi définir les objets transitants de façon plus structurée et donner plus de sens à la donnée tout en facilitant la compréhension.

On peut aussi parler des fonction de dĂ©finition de contraintes Ă  appliquer sur chaque champ. Ces contraintes portent sur plusieurs aspects comme le type, le nombre d’occurrences ou les cardinalitĂ©s et les restrictions de champs obligatoires. On peut ainsi dĂ©finir des modèles de donnĂ©es structurĂ©es et les valider au runtime sans avoir Ă  Ă©crire des lignes de code dans chaque application (sĂ©rialisation / dĂ©sĂ©rialisation des donnĂ©es). On Ă©vite l’écriture de code de validation et on s’abstrait encore un peu plus du langage de programmation pour permettre au plus grand nombre de consommer ou produire pour notre service Web.

Le JSON dispose d’un système de schéma avec json-schema par exemple. Mais cette solution est très basique et ne procure pas de solution de gestion de contrat de service avancé.

Et leur usage avancé

Ainsi de nombreuses autres fonctionnalités accompagnent l’utilisation des contrats de service avec certains nouveaux formats de sérialisation. Il existe par exemple des mécanismes d’enregistrement de schémas pour ne pas avoir à dupliquer les schémas de chaque côté (client / serveur) du service et ainsi faciliter encore plus leur partage et leur utilisation.

De même les formats comme Avro permettent de générer des classes d’accès aux données s’adaptant au schéma ce qui peut simplifier l’utilisation.

La plupart des technologies que nous allons dĂ©crire disposent d’un système d’Ă©volution de schĂ©ma. Ce système permet par exemple de dĂ©finir de nouveaux champs attendus par un service Web, pour ajouter une fonctionnalitĂ© par exemple, sans impacter les client du service. Cela Ă©limine tous les codes basĂ©s sur une version donnĂ©e et notamment les imbrications de “if” permettant de traiter chaque version. Cela permet de limiter les modifications bloquantes sur les types des champs ou encore le respect des contraintes entre les diffĂ©rentes Ă©volutions d’un mĂŞme schĂ©ma. En effet, la plupart du temps, un champ marquĂ© comme requis ne peut pas devenir optionnel dans une nouvelle version du schĂ©ma (Ă  moins de changer complètement le type de retour). Un utilisateur d’une ancienne version du schĂ©ma sera toujours en capacitĂ© d’envoyer des donnĂ©es grâce Ă  cette contrainte. C’est ce qu’on appelle de la rĂ©tro-compatibilitĂ©. C’est donc un outil très utile mais aussi dangereux : il ne faut pas tout dĂ©clarer en required sous peine d’obtenir un schĂ©ma peu flexible ! Par exemple, si on ajoute un champ required, il faut que tous les utilisateurs l’aient prĂ©alablement inclus pour Ă©viter une erreur de validation de schĂ©ma (cette fonctionnalitĂ© a d’ailleurs disparue dans proto3).

Mise en place des solutions

En se basant sur la partie précédente nous allons donc comparer trois formats actuels : le JSON, Protocol Buffers et enfin Avro. Pour comparer les différentes méthodes, l’idée est simple. On va utiliser deux applications Java, une serveur et une cliente, exposant quelques métriques pour la performance. Nous mesurerons principalement les temps d’exécution à divers instants de l’application et la taille des messages HTTP. Nous utiliserons Spring Boot pour ces applications et le message envoyé sera une map contenant un type complexe (des personnes).

protocols_app

On a ajouté un filtre sur les requêtes HTTP permettant de récupérer la taille du contenu.

@Configuration
public class Filter {

    /**
     * Filter used to add various header to http responses.
     * We are particularly interested by the content-length.
     */
    @Bean
    public FilterRegistrationBean filterRegistrationBean() {
        FilterRegistrationBean filterBean = new FilterRegistrationBean();
        filterBean.setFilter(new ShallowEtagHeaderFilter());
        filterBean.setUrlPatterns(Collections.singletonList("*"));
        return filterBean;
    }
}

On utilisera la même application (en modifiant l’utilisation du protocole) afin de valider les différences entre les solutions.

JSON

Commençons par la solution la plus conventionnelle pour la création d’une API, l’utilisation du JSON. Aujourd’hui le JSON est roi et ce pour plusieurs raisons :

  • Facilement lisible pour les humains et très facile Ă  mettre en place,
  • Multi-langage / plateforme, actuellement des parseurs sont disponibles pour la grande majoritĂ© des langages de programmation.

Pour retourner des valeurs sous forme de JSON il suffit de créer un objet Java. Par défaut dans Spring Boot c’est le Jackson2HttpMessageConverter qui est utilisé pour sérialiser l’objet JSON pour le message HTTP.

Voici le contrĂ´leur permettant de retourner du JSON:

@RestController
public class Controller {

    private ObjectBuilder objectBuilder;

    @Autowired
    public Controller(ObjectBuilder objectBuilder) {
        this.objectBuilder = objectBuilder;
    }

    @RequestMapping(value = "/json", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public Map<String, JsonPerson> getJsonPeople(@RequestParam(required = false) Integer size) {
        return objectBuilder.jsonBuilder(size);
    }
}

Comme on peut le constater c’est on ne peut plus simple et c’est pourquoi on ne creuse souvent pas plus loin. Mais qu’en est-il des aspects performances ?

Protocol Buffer

Protocol buffer est à l’origine un protocole développé par Google. Il permet de définir des structures de message ou schémas et de les utiliser pour créer du contenu binaire de façon optimisée (le plus léger possible). L’application cliente devra disposer du schéma pour récupérer le contenu original. Voici le schéma .proto concernant notre modèle de test :

option java_package = "fgarcia.test.protocols.protobuf";
option java_outer_classname = "ContentProtos";

message Person {
    required string firstName = 1;
    required string lastName = 2;
    required string address = 3;
    required int32 age = 4;
    repeated string moreInfo = 5;
}

message MapEntry {
    required string key = 1;
    required Person value = 2;
}

message PeopleList {
    repeated MapEntry entry = 1;
}

Le format d’un fichier .proto est très simple. Il ressemble à la déclaration d’une structure en C par exemple. Il suffit de spécifier le package Java et le nom de la classe qui contiendra le code généré et de spécifier le format des messages. Des mots clés tel que “required”, “optional” ou “repeated” permettent de donner des contraintes sur les schémas (attention à la rétrocompatibilité). Ici on a recréé la structure de notre Map<String, Person> sous forme de schéma Protobuf.

Des plugins Maven existent pour permettre de générer les classes correspondant aux schémas et les classes générées permettent de créer des instances à l’aide du pattern builder :

    /**
     * Create a single protobuf Person.
     */
    private ContentProtos.Person createProtoPerson(int i) {
        return ContentProtos.Person.newBuilder()
                .setFirstName("Foo " + i)
                .setLastName("Bar " + i)
                .setAge(i)
                .setAddress(i + " bar street Paris")
                .addAllMoreInfo(Arrays.asList("foo", "bar", "babar", "foofoo"))
                .build();
    }

Il suffit ensuite de configurer RestTemplate afin qu’il puisse sérialiser / désérialiser les messages. C’est assez simple car la librairie protobuf-java intègre le ProtobuffHttpMessageConverter.

@Bean
public RestTemplate restTemplate() {
    RestTemplate restTemplate = new RestTemplate();
    restTemplate.getMessageConverters().add(protobufHttpMessageConverter());
    restTemplate.getMessageConverters().add(avroHttpMessageConverter());
    return restTemplate;
}

@Bean
public ProtobufHttpMessageConverter protobufHttpMessageConverter() {
    return new ProtobufHttpMessageConverter();
}
Avro

Avro, à l’instar de Protocol Buffer, utilise des schémas pour convertir le texte en contenu binaire (le plus léger possible). Ce protocole est maintenu et développé par la fondation Apache et connaît un grand essor. Il possède la même philosophie que Protocol Buffer. Contrairement à ce dernier, il permet néanmoins de se passer de la génération de code pour les langages non typés et il permet de schématiser des appels RPC… Il est utilisé par divers acteurs importants, par exemple par la solution Confluent encapsulant le broker Kafka.

La création de schéma est cette fois uniquement utile pour les langages fortement typés. C’est le cas du Java, il faut donc définir un schéma et utiliser un outil de génération de classes.

Le format de schéma est encore une fois assez simple. Il correspond en fait à un JSON décrivant le schéma. Cela permet de faciliter l’utilisation des schémas avec des librairies existantes.

[{
 "namespace": "fgarcia.test.protocols.avro",
 "type": "record",
 "name": "Person",
 "fields": [
     {"name": "firstName", "type": "string"},
     {"name": "lastName",  "type": "string"},
     {"name": "address", "type": "string"},
     {"name": "age", "type": "int"},
     {"name": "moreInfo", "type": {"type": "array", "items": "string"}}
 ]
},
{
 "namespace": "fgarcia.test.protocols.avro",
 "type": "record",
 "name": "PeopleList",
 "fields": [
    {"name": "items", "type": {
        "type": "map", "values": "fgarcia.test.protocols.avro.Person"}
    }]
}]

On peut remarquer l’utilisation du type “record” ou encore “map” pour définir des formats de contenu et l’utilisation de types simples pour décrire les valeurs que prendront chacun des champs. Les contraintes d’obligation de champs sont faites en fonction des types de ces derniers, si “null” est indiqué alors le champ est optionnel.
Après génération du code à l’aide d’un plugin Maven, on peut créer des objets Avro à l’aide soit du pattern builder pour une validation automatique et une initialisation des variables ou bien de manière classique avec un constructeur.

/**
* Create a single avro Person.
*/
private Person createAvroPerson(int i) {
    return Person.newBuilder()
            .setFirstName("Foo " + i)
            .setLastName("Bar " + i)
            .setAge(i)
            .setAddress(i + " bar street Paris")
            .setMoreInfo(Arrays.asList("foo", "bar", "babar", "foofoo"))
            .build();
}

RestTemplate ne fournissant pas la compatibilité avec Avro, nous avons dû créer la classe AvroHttpMessageConverter. Implémentation de AbstractHttpMessageConverter, elle convertit les objets java en messages HTTP au format Avro. Cette implémentation est disponible sur GitHub.

Comparatif La facilité d’utilisation

Comme vu dans la partie précédente, c’est de loin le JSON qui est le plus simple à mettre en place. Il est utilisé de façon native avec Spring Boot et ne nécessite pas de code spécifique. Protobuf et Avro requièrent par contre quelques modifications au niveau sérialisation et désérialisation. Elles sont néanmoins assez simples à mettre en oeuvre. Il existe aussi des librairies permettant de faciliter la conversion de types (binaire => Avro par exemple) et qui réduisent la nécessité d’utiliser la génération de code. Bijection (librairie open source développée par Twitter) rentre par exemple dans cette catégorie.

La flexibilité et support

En terme de flexibilité, c’est ex æquo pour les différents formats présentés. Ils sont tous compatibles avec les langages de programmation majeurs, parfois même avec des fonctionnalités de prise en compte de schéma automatique avec les langages non typés par exemple.

Concernant le support, le JSON est universel et est le format par défaut sur Spring Boot, il est donc largement supporté par la communauté. On peut en dire de même pour Avro qui est maintenu par la fondation Apache et dont la dernière version date de mai 2016. Enfin Protobuf, historiquement créé par Google est aujourd’hui sous licence libre et vient d’être releasé en version 3.0.0.

Utilisation des contrats de service

Nous disions précédemment que les trois formats peuvent définir des contrats de service mais avec une granularité différente. Pour le JSON c’est un support basique avec définition et validation des données. …… Pour Protobuf et Avro ce sont des solutions complètes. On dispose des fonctionnalités de base auxquelles on peut ajouter un schéma registry, un système de versionning poussé et des classes d’accès simples générées à partir des schémas. Il existe même un framework pour effectuer du RPC avec Protobuf.

Performances

Sur 100 requĂŞtes contenant 1000 objets dans la map, nous obtenons les valeurs moyennes suivantes :

JSON JSON
(GZIP) Protobuf Protobuf
(GZIP) Avro Avro
(GZIP) Temps serveur (ms) 339,96 63,5 289,22 93,32 241,04 88,21 Temps client (ms) 6,52 8,43 21,68 24,64 10,29 12 Temps total (ms) 346,48 71,93 310,9 117,96 251,33 100,21 Taille (kilobytes) 132.3 74.6 63.9

Deux jeux de tests ont été effectués : un avec compression GZIP et un sans. Commençons par analyser le cas sans compression.

Pour le JSON on remarque donc que les messages sont assez volumineux et que le traitement total (temps serveur plus temps client) est d’environ 346ms. Les messages sont les plus volumineux de nos tests et le temps de traitement côté serveur est très long. Par contre le temps de désérialisation et le traitement côté client sont très courts. C’est donc le facteur taille des messages qui conditionne le plus le temps serveur pour le JSON.

Pour Protobuf on remarque que les messages sont un peu moins volumineux et que le traitement total est légèrement plus court (310ms). La taille des messages influe sur le temps de traitement côté serveur qui est plus rapide mais la désérialisation côté client est en revanche bien plus longue (quasiment 4 fois plus long que le JSON). C’est donc un facteur à prendre en compte, à savoir si augmenter le traitement du client est acceptable.

Avro crée les documents les plus petits et dispose du temps de traitement total le plus faible (251ms). Le temps de traitement côté client est plus long que pour le JSON mais le temps de transfert serveur est bien plus court. C’est donc la solution la plus performante de ce comparatif. Elle peut être très intéressante dans le cadre d’applications mobiles en Javascript par exemple car elle réduit grandement la taille des objets transférés, ce qui est fondamental pour les connections mobiles.

Si l’on prend en compte la compression GZIP, tout bascule. Le JSON profite énormément de la compression des données pour une très légère augmentation du coût de désérialisation. Ce gain est bien plus significatif que pour les autres formats car la taille de l’objet permet d’avoir un réel impact sur le coût réseau. Il est important pour les autres formats mais ces derniers ont déjà optimisé leurs contenus binaire, l’impact est donc moindre.

Ainsi en terme de performance pure on obtient le classement suivant :

  1. Json Gzippé
  2. Avro Gzippé
  3. Protobuf Gzippé
  4. Avro
  5. Protobuf
  6. Json
Conclusion

On peut dire qu’il n’y a pas de solution miracle. Il faut utiliser le bon outil en fonction du besoin. Le JSON est un format qui a fait ses preuves et qui a la grande force d’être très lisible, et ce directement au sein du navigateur. Ce format est quasi parfait pour tous les points mais est très basique dans son utilisation et peut montrer des limites dans des entreprises de taille importantes ou la multiplication des services demande l’utilisation de fonctions avancés de contrats de service.

Protobuf contrairement à la sérialisation du JSON envoie du binaire, sa lisibilité est donc réduite. Il est dépendant d’un schéma et cela lui confère de bien meilleures performances que le JSON (en non Gzippé) même s’il est assez lourd au niveau désérialisation (côté client). C’est un facteur à prendre à compte pour le choix du format.

Pour finir, Avro pousse un peu plus loin que Protobuf avec des schémas écrits en JSON pour la lisibilité et la facilité d’utilisation. Cela semble être la meilleure alternative si l’on décide de s’éloigner du JSON pour gagner en industrialisation et en fiabilité en perdant le moins de performance et en sacrifiant un peu de simplicité et de lisibilité (format binaire).

On ne connait pas encore les formats qui vont emmerger dans le futur, Protobuf et Avro permettent de s’affranchir du langage et du format pour la transition des donnĂ©es et est notamment utile pour la communication dans des systèmes distribuĂ©s (comme  HDFS par exemple). Protobuf et Avro entrent aussi en rĂ©sonance avec l’émergence des technologies d’enregistrement de schĂ©mas et de validation des applications de services. Ce sont des outils qui permettent de mutualiser les schĂ©mas des protocoles afin qu’ils soient utilisĂ©s par diffĂ©rentes Ă©quipes, avec diffĂ©rents langages de programmation. Ainsi on valide les donnĂ©es transitant et on Ă©vite les incohĂ©rences lors de mises Ă  jour de contenu (les schema-registry assurent la rĂ©trocompatibilitĂ©). Le changement de format de donnĂ©es permet donc d’apporter plus que la performance. Comme avec SOAP par le passĂ© on dispose donc maintenant de moyens de garder un aspect validation du format de contenu avec des performances aussi bonnes voire meilleures que le standard JSON. MĂŞme si ce n’est pas le cas dans les exemples de l’article, il existe des dizaines de formats de sĂ©rialisation, plus ou moins connus ou supportĂ©s, il est nĂ©anmoins peu intĂ©ressant d’en comparer des centaines. Vous pouvez tout de mĂŞme trouver des comparatifs de performance (uniquement) ici par exemple.

L’ensemble du code source est disponible ici : https://github.com/garciafl/protocols

Sources:

Catégories: Blog Société

Garde fou

Une discussion lancĂ©e par @gregalexandre avec @xnopre sur les gardes fous… et TDD.
Mettre en place des garde-fous génère des comportements de fou
@pierre_fauvel:@gregalexandre precise
@gregalexandre:@pierre_fauvel qu’est-ce que ça t’inspire ?
@pierre_fauvel:@gregalexandre Sentiments mĂŞlĂ©s. S’il s’agit de crĂ©ativitĂ© ou de dynamique coll. je plussoie. Dans d’autres contextes je suis moins pour.[1]
*1@gregalexandre:@pierre_fauvel l’effet pervers des cadres de contrĂ´le qui peuvent dĂ©responsabiliser voir lĂ©gimiter de mauvais comportements.[2]
*2@pierre_fauvel:@gregalexandre en koi un cadre legitime-t-il un mauvais comportement ? Un exemple ?
@gregalexandre:@pierre_fauvel exemple : mĂ©comprĂ©hension du rĂ´le de Scrum Master gardien du cadre, en posture haute qui fait que…
@gregalexandre:@pierre_fauvel …l’Ă©quipe n’est plus responsable de son cadre. SM pas lĂ , plus de cadre. C’est normal c’est lĂ©gitime[3]
*3@pierre_fauvel:@gregalexandre mais je te rejoins : poser une regle deresponsabilise un peu.
@gregalexandre:@pierre_fauvel je prĂ©ciserais par « SE FAIRE IMPOSER une rĂ©gle dĂ©responsabilise un peu » :)
@pierre_fauvel:@gregalexandre oui, par le sm ou par le service qualitĂ©. On ne se l’approprie pas, on ne se sent pas responsable
@gregalexandre:@pierre_fauvel exemple : DoD dĂ©finie par le service qualitĂ©, le contrat de prestation, le kit de dĂ©marrage agile d’une entreprise…[4]
*4@pierre_fauvel:@gregalexandre les dod predefinies, kits de demarrage sont Ă  remplacer par une bonne formation et biblio et une capi des projets exemplaires
@gregalexandre:@pierre_fauvel aha, qu’est-ce qu’un projet exemplaire ? Les pratiques d’un projet, mĂŞme exemplaire, peuvent elles ĂŞtre appliquĂ©es Ă  tous ?
*4@pierre_fauvel:@gregalexandre l’equipe presta doit se sentir engagee par le contrat de prestation sinon la prestation va mal se passer
*3@pierre_fauvel:@gregalexandre dans garde fou je vois « mettre une limite a un espace de libertĂ© » pas « organisation fine de l’espace »
@gregalexandre:@pierre_fauvel mea culpa sur le deuxième exemple. Oui garde fou = ce qui empeche de faire des folies, des imprudences[5]
*5@gregalexandre:@pierre_fauvel c’est marrant mais je me rends compte que ma phrase peut servir d’argument pour les anti-TDD…[6]
*6@pierre_fauvel:@gregalexandre tdd est un garde fou qui permet de faire des refactorings profonds sans risque
*6@gregalexandre:@pierre_fauvel … j’ai dĂ©jĂ  entendu que le pb du test Ă©tait que les dĂ©veloppeurs diminuaient leur vigilance…
@pierre_fauvel:@gregalexandre jamais vu moins de bug que dans une equipe full tdd
@gregalexandre:@pierre_fauvel ah, encore un lien de comportement. Dans quelle mesure faire du full TDD s’inscrit-il dans une volontĂ© de faire du bon code ?
@pierre_fauvel:@gregalexandre ben ca elimine les bugs et a plein de vertus ( conception basee sur le comportement )
@gregalexandre:@pierre_fauvel je veux dire : quand tu fais de la TDD, n’est-ce pas que tu es dĂ©jĂ  dans une recherche du meilleur livrable possible ?
@pierre_fauvel:@gregalexandre je pense qu’il y a un large spectre entre zero tdd et full tdd. Et que certaines habitudes de tdd tuent la vigilance
@gregalexandre:@pierre_fauvel y a-t-il des devs dans la salle qui aimeraient participer Ă  la discussion ? Qu’en penses-tu @xnopre ?[7]
*7@xnopre:@gregalexandre @pierre_fauvel Avec plaisir, mais Twitter risque de nous limiter… « certaines habitudes de tdd tuent la vigilance » ???[8]
*8@pierre_fauvel:@xnopre @gregalexandre les habitudes tuent la vigilance, plus largement.
@gregalexandre:@pierre_fauvel @xnopre ouiiiii la discussion repart ! Est-ce que dans habitude (dans ce cas lĂ ) on peut parler de « tester le test » ?[9]
*9@xnopre:@gregalexandre @pierre_fauvel Je n’ai pas encore vu du #TDD mis en oeuvre au pt d’avoir des habitudes… en encore – de tuer la vigilance[10]
*10@pierre_fauvel:@xnopre @gregalexandre ben par exemple ce qu’on choisit de ne pas tester parce que ca marche toujours
@xnopre:. @pierre_fauvel @gregalexandre Lorsque je propose aux équipe de ne pas tout tester, ce n’est jamais pour cette raison… ;-)[11]
*11@pierre_fauvel:@xnopre @gregalexandre precise pour quelle raison ?
@xnopre:. @pierre_fauvel @gregalexandre Ne pas tester si on ne sait pas tester (IHM, framework, …) mais dans ce cas, code minimum[12]
*12@gregalexandre:@xnopre @pierre_fauvel pas compris le « dans ce cas, code minimum »
@xnopre:. @gregalexandre @pierre_fauvel On ne sait pas tester une partie du code ? OK mais on y laisse un minimum du code …
@xnopre:. @gregalexandre @pierre_fauvel … et on sort tout le reste ailleurs en le couvrant par les TU ;-)[13]
*13@xnopre:. @gregalexandre @pierre_fauvel Tiens, un bon sujet d’article de blog … ;-)
@gregalexandre:@xnopre @pierre_fauvel que j’aurai plaisir Ă  lire :)
@xnopre:@gregalexandre @pierre_fauvel que je risque de ne pas avoir le temps d’écrire… ;-)[14]
*14@pierre_fauvel:@xnopre @gregalexandre a defaut d’ecrire un article, et avec votre accord, je mettrai cette discussion sur mon blog.[15]
*15@xnopre:. @pierre_fauvel @gregalexandre Pourquoi pas, mais ça mériterait plus de détails et d’arguments, impossible sur Twitter… :-([16]
*16@pierre_fauvel:@xnopre @gregalexandre hangout publié sur youtube ?
@gregalexandre:@pierre_fauvel @xnopre as usual pour moi, je ferais un hangout youtube si on avait un dĂ©bat, lĂ  on est tous d’accord c’est moins fun
@xnopre:@gregalexandre @pierre_fauvel :-) … donc faut trouver des personnes moins ou pas d’accord … ;-)[17]
*17@gregalexandre:@xnopre @pierre_fauvel non je pense que ça peut ĂŞtre intĂ©ressant avec d’autres praticiens (chose que je ne suis pas)[18]
*18@pierre_fauvel:@gregalexandre @xnopre ca vaudrait la peine de faire un atelier : le meme kata avec des equipes en parallele, des strategies tdd différentes
@xnopre:@pierre_fauvel @gregalexandre Une idée intéressante à creuser ! ;-)
@xnopre:. @pierre_fauvel @gregalexandre Ou quelques praticiens qui résolvent chacun à leur manière un même Kata
@xnopre:. @pierre_fauvel @gregalexandre Problème, éviter les influences, donc pourquoi pas via video-cast ?[19]
*19@pierre_fauvel:@xnopre @gregalexandre chacun dans son coin et on regarde les videos après ?[20]
*20@xnopre:@pierre_fauvel @gregalexandre Oui, pour Ă©viter les influences, sinon le premier Ă  passer pourrait influencer les suivants, non ?[21]
*16@xnopre:@pierre_fauvel @gregalexandre Une idĂ©e de solution pour Ă©changer plus largement ? G+ ? …
@gregalexandre:@xnopre @pierre_fauvel un café ou Agile Grenoble ? :)
*10@xnopre:. @gregalexandre @pierre_fauvel De mes rencontres et interventions, le #TDD est très peu pratiquĂ© :-( , y’a encore du boulot ! …[22]
*3@gregalexandre:@pierre_fauvel ou encore : mise en place d’indicateurs de qualitĂ© de code (par une personne extĂ©rieure Ă  l’Ă©quipe)…
@gregalexandre:@pierre_fauvel …gĂ©nère des techniques pour mettre l’indicateur au vert sans pour autant amĂ©liorer la qualitĂ© du code
@gregalexandre:@pierre_fauvel … aux yeux de l’Ă©quipe, ce comportement est lĂ©gitime face Ă  un indicateur qui parait abusif
*1@gregalexandre:@pierre_fauvel j’Ă©tais, de mon cĂ´tĂ©, plus sur la dynamique collective


Catégories: Blog Individuel

Gagne ta place pour Bdx.io

Blog d’Ippon Technologies - ven, 09/23/2016 - 13:47

Le 21 octobre 2016 Ippon sponsorise le Bdx.io.

 

Le Bdx.io est clairement LA journée bordelaise pour les développeurs sur les technologies de demain.

A cette occasion Ippon vous propose de gagner 3 places en participant à notre jeu concours !

Tentez votre chance jusqu’au 16 octobre, les rĂ©sultats seront annoncĂ©s par mail le 17 octobre.

icc_affiche_bdx-io-1

Catégories: Blog Société

Vidéo Ippevent – Lessons Learned: Using Spark and Microservices

Blog d’Ippon Technologies - ven, 09/23/2016 - 08:55

Le 24 aoĂ»t, Alexis Seigneurin consultant pour Ippon USA nous a prĂ©sentĂ© son retour d’expĂ©rience sur Spark et les Microservices :

Catégories: Blog Société

[PO Dojo] Session de rentrée – Comment donner du sens à votre projet

Agile Nantes - ven, 09/23/2016 - 05:48
Pour cette rentrĂ©e, si on commençait par le tout-tout dĂ©but du projet ??  … Avant mĂŞme l’Ă©criture des user stories … avant mĂŞme la story map … avant mĂŞme le « why » du projet ??  Nous vous proposons de (re) dĂ©couvrir les outils qui donneront du sens Ă  la priorisation des vos user stories … De la [...]
Catégories: Association

SLAs in JIRA Service Desk

Le blog de Valiantys - jeu, 09/22/2016 - 13:55

SLAs explained Some service contracts involve agreements on response times, or SLAs (Service Level Agreements), to solve requests. Teams and customers need this information for each request in order to better handle priorities and guarantee optimal service quality. But that’s not all – SLAs can also help identify areas for improvement. The good news is that ...

The post SLAs in JIRA Service Desk appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

Feign, encore un client HTTP ?

Blog d’Ippon Technologies - mer, 09/21/2016 - 13:02

Depuis les prémices de Java, il est possible de requêter sur le protocole HTTP, soit de manière native avec le package java.net, soit avec l’un des nombreux clients qui ont vu le jour. Certaines librairies sont éprouvées depuis quelques temps déjà. On peut ainsi parler de :

  • Apache HttpClient,
  • Jersey,
  • RestTemplate (Spring),
  • CXF,
  • JAXRS,
  • Google Http Client,
  • Unirest,
  • Restlet,
  • etc.

À l’origine développé et utilisé par Netflix OSS depuis quelques années, Feign est aujourd’hui proposé par OpenFeign comme librairie open-source. Quelles sont ses possibilités et comment l’utiliser ?

Spring Cloud propose une définition complète du client HTTP :

Feign is a declarative web service client. It makes writing web service clients easier. To use Feign create an interface and annotate it. It has pluggable annotation support including Feign annotations and JAX-RS annotations. Feign also supports pluggable encoders and decoders. Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web. Spring Cloud integrates Ribbon and Eureka to provide a load balanced http client when using Feign.

Le but de cette libraire est donc très clairement de simplifier et minimiser l’écriture du requêtage HTTP tout en s’inscrivant dans la lignée des “Convention Over Configuration”.

Un premier exemple : GET

N.B. : une des agences Ippon étant basée à Bordeaux, la thématique de notre Api s’organise autour du vin :-)

public interface WineAPI {
    @RequestLine("GET /wines")
    List getWineDesignations();
}

public static void main(String … args) {
    WineAPI api = Feign.builder()
                       .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

    List wineDesignation = api.getWineDesignations();
}

Plutôt simple, non ? Une interface est déclarée avec une méthode annotée @RequestLine qui définit le verbe HTTP et le contexte à utiliser. Il suffit ensuite de créer le client Feign en ciblant la précédente interface et l’URL à appeler. Comme nous pouvons le voir, la déclaration du client repose sur une fluent interface afin de favoriser la déclaration/lecture/…

POST et paramètre de contexte
public interface WineAPI {
    @RequestLine("GET /wines/{wineId}")
    Wine getWine(@Param("wineId") long wineId);

    @Headers("Content-Type: application/json")
    @RequestLine("POST /wines")
    void create(Wine wine);
}

public static void main(String … args) {
    WineAPI api = Feign.builder()
                       .encoder(new JacksonEncoder())
                       .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

    Wine wine = api.getWine(1);

    Wine chateauPessacLeognan = new Wine();
    api.create(chateauPessacLeognan);
}

L’exemple propose de récupérer un vin par son identifiant renseigné dans le contexte, puis d’enregistrer un nouveau vin via une requête POST. Trois nouvelles choses :

  • l’utilisation de l’annotation @Param pour renseigner un paramètre dans le contexte,
  • @Header pour dĂ©finir le content-type,
  • l’affectation d’un “encoder” au niveau du client Feign afin de spĂ©cifier la sĂ©rialisation Ă  effectuer.

Le principe est identique pour tous les verbes HTTP.

Encodeurs et décodeurs

Si votre interface retourne autre chose que Response, String, byte[] ou void, il est obligatoire de configurer un décodeur ou encodeur. De façon native, Feign en propose plusieurs couvrant majoritairement les usages actuels. On peut citer :

  • Gson : GsonEncoder/GsonDecoder
WineAPI api = Feign.builder()
                   .encoder(new GsonEncoder())
                   .decoder(new GsonDecoder())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
  • Jackson : JacksonEncoder/JacksonDecoder
WineAPI api = Feign.builder()
                   .encoder(new JacksonEncoder())
                   .decoder(new JacksonDecoder())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
  • JAXB : JAXBEncoder/JAXBDecoder
WineAPI api = Feign.builder()
                   .encoder(new JAXBEncoder())
                   .decoder(new JAXBDecoder())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
  • Sax : SAXDecoder
WineAPI api = Feign.builder()
                   .decoder(SAXDecoder.builder()
                                      .registerContentHandler(SomeHandler.class)
                                      .build())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

Si votre bonheur ne se trouve pas dans cette liste, il est toujours possible d’en créer un spécifique en surchargeant la classe DefaultEncoder.

ErrorDecoder

Dans le cas d’erreurs, Feign envoie une unique exception de type FeignException. Il est cependant toujours conseillé de gérer les différents types d’erreur. Il suffit simplement ici de créer une classe implémentant ErrorDecoder et de l’affecter au builder :

public class WineErrorDecoder implements ErrorDecoder {
    @Override
    public Exception decode(String methodKey, Response response) {
        if (response.status() >= 400 && response.status() <= 499) { return new WineClientException(response.status(), response.reason()); } if (response.status() >= 500 && response.status() <= 599) {
            return new WineServerException(response.status(), response.reason());
        }
        return errorStatus(methodKey, response);
    }
}

L’affectation s’effectue au niveau du client Feign :

WineAPI api = Feign.builder()
                   .errorDecoder(new WineErrorDecoder())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
Headers

Feign propose différentes méthodes pour spécifier les headers HTTP :

  • Au niveau de l’API avec l’annotation @Headers sur l’interface.
  • Sur une mĂ©thode spĂ©cifique avec lĂ  encore l’annotation @Headers.
  • De manière dynamique en ajoutant l’annotation @HeaderMap sur le paramètre typĂ© Map<String, Object> de la mĂ©thode.
@Headers(“Accept-Charset: utf-8“)
public interface WineAPI {

    @RequestLine("GET /wines/{wineId}")
    Wine getWine(@Param("wineId") long wineId);

    @Headers("Content-Type: application/json")
    @RequestLine("POST /wines")
    void create(Wine wine);

    @RequestLine("GET /wines/white")
    void getWhiteWines(@HeaderMap Map<String, Object> headerMap);
}
Logs HTTP

Par défaut, les logs HTTP ne sont pas récupérés. Il est toutefois possible de les logger. Avec SLF4J (à importer comme module complémentaire) :

WineAPI api = Feign.builder()
                   .logger(new Slf4jLogger())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

Ou avec JavaLogger :

WineAPI api = Feign.builder()
                   .logger(new Logger.JavaLogger().appendToFile("logs/http.log"))
                   .logLevel(Logger.Level.FULL)
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

Il existe quatre niveaux de logs HTTP :

  • Logger.Level.BASIC
feign.Logger - [WineAPI#getWineDesignations] ---> GET http://api.wine.bordeaux.ippon.fr/wines HTTP/1.1
feign.Logger - [WineAPI#getWineDesignations] <--- HTTP/1.1 200 OK (59ms)
  • Logger.Level.HEADERS (BASIC + Headers)
feign.Logger - [WineAPI#getWineDesignations] ---> GET http://api.wine.bordeaux.ippon.fr/wines HTTP/1.1
feign.Logger - [WineAPI#getWineDesignations] ---> END HTTP (0-byte body)
feign.Logger - [WineAPI#getWineDesignations] <--- HTTP/1.1 200 OK (49ms)
feign.Logger - [WineAPI#getWineDesignations] Server: Jetty(8.y.z-SNAPSHOT)
feign.Logger - [WineAPI#getWineDesignations] Content-Length: 6431
feign.Logger - [WineAPI#getWineDesignations] Content-Type: application/json
feign.Logger - [WineAPI#getWineDesignations] <--- END HTTP (6431-byte body)
  • Logger.Level.FULL (HEADERS + contenu de la rĂ©ponse)
feign.Logger - [WineAPI#getWineDesignations] ---> GET http://api.wine.bordeaux.ippon.fr/wines HTTP/1.1
feign.Logger - [WineAPI#getWineDesignations] ---> END HTTP (0-byte body)
feign.Logger - [WineAPI#getWineDesignations] <--- HTTP/1.1 200 OK (48ms)
feign.Logger - [WineAPI#getWineDesignations] Server: Jetty(8.y.z-SNAPSHOT)
feign.Logger - [WineAPI#getWineDesignations] Content-Length: 6431
feign.Logger - [WineAPI#getWineDesignations] Content-Type: application/json
feign.Logger - [WineAPI#getWineDesignations]
feign.Logger - [WineAPI#getWineDesignations] ["bordeaux", "bourgogne", "graves", "jurançon"]
feign.Logger - [WineAPI#getWineDesignations] <--- END HTTP (6431-byte body)
  • Logger.Level.NONE

Aucun log HTTP n’est tracé...

Intercepteur de requĂŞtes

Dans le cas où toutes les requêtes doivent être modifiées, peu importe la cible, Feign propose d’utiliser des intercepteurs de requêtes. L’exemple ci-dessous ajoute la date du jour comme Header à chaque requête :

WineAPI api = Feign.builder()
                   .requestInterceptor(template -> template.header (“Date”, Instant.now.string()))
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");

Un autre exemple courant est l’authentification avec la classe feign.auth.BasicAuthRequestInterceptor :

WineAPI api = Feign.builder()
                   .requestInterceptor(new BasicAuthRequestInterceptor(username, password))
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
L’intégration avec …

Un autre but de Feign, tout aussi important, est de s’intégrer facilement avec Netflix OSS et d’autres librairies Open Source (Spring Source en est un exemple).

Hystrix

Cette librairie Netflix OSS permet d’utiliser le pattern Circuit Breaker. Le module HystrixFeign englobe ainsi les requêtes HTTP dans le Hystrix et configure ainsi le Circuit Breaker. Après avoir intégré le module dans le classpath, il reste à configurer Feign pour utiliser feign.hystrix.HystrixInvocationHandler :

WineAPI api = HystrixFeign.builder()
                          .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
Ribbon

Ribbon sert de Load Balancer et intervient comme Routeur Dynamique. Il est généralement couplé avec Eureka pour la découverte des services. Son intégration, en tant que module Feign, permet de surcharger la résolution d’URL et de profiter des caractéristiques de Ribbon.

Routage dynamique
WineAPI api = Feign.builder()
                   .client(new RibbonClient())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
Load balancing
WineAPI api = Feign.builder()
                   .target(LoadBalancingTarget.create(WineAPI.class, "https://api.wine.bordeaux.ippon.fr"));
Spring Cloud

Spring Cloud Netflix est basé, comme son nom l’indique, sur les composants Netflix OSS. Reposant sur les principes d’Auto Configuration et Convention over Configuration, l’utilisation de Feign est d’autant plus simplifiée. Plus besoin de définir le client, il est configuré directement par Spring.

@FeignClient(name = "wine-api", url = "https://api.wine.bordeaux.ippon.fr")
public interface WineAPI {
    @RequestLine("GET /wines")
    List getWineDesignations();
}

@Service
public class WineService {
    @Inject
    private WineAPI api;

    public void doSomething(){
        List wines = api.getWineDesignations();
    }
}
Les autres paramètres du client Feign Options

Le builder Feign propose de spécifier des options. Actuellement, les options par défaut se focalisent sur les timeout de connexion ou de lecture. L’implémentation par défaut des options est la suivante :

public static class Options {

    private final int connectTimeoutMillis;
    private final int readTimeoutMillis;

    public Options(int connectTimeoutMillis, int readTimeoutMillis) {
        this.connectTimeoutMillis = connectTimeoutMillis;
        this.readTimeoutMillis = readTimeoutMillis;
    }

    public Options() {
        this(10 * 1000, 60 * 1000);
    }
}

Il est ainsi possible de surcharger cette classe pour modifier les valeurs par défaut. Il suffit ensuite de les fixer dans le builder :

WineAPI api = Feign.builder()
                   .options(new WineApiOptions())
                   .target(WineAPI.class, "https://api.wine.bordeaux.ippon.fr");
Contract

Il est possible de définir un contrat sur le client. Des nouvelles annotations ainsi que d’autres comportements peuvent être définis à travers ce dernier. Par défaut, le contrat utilisé est la classe feign.contract.Default. Cette classe s'occupe de parser et valider les différents paramètres, interfaces et annotations définis sur la classe cible (paramètre de la méthode target). Dans notre exemple, l’interface WineAPI sera vérifiée ainsi que toutes les méthodes définies.

Il est encore une fois possible de définir le comportement d’un nouveau contrat ou alors d'utiliser le module JAXRS et sa classe feign.jaxrs.JAXRSContract.

Retryer

Un retryer par défaut est configuré dans le client Feign. Couplé avec l’ErrorDecoder par défaut, il est utilisé uniquement si le header de la réponse possède la propriété “retry-after”.

Au final

Vous connaissez à présent les principales caractéristiques de ce client HTTP qu'est Feign. Simple d’utilisation, sa maîtrise en est d’autant plus rapide. Son intégration avec d’autres librairies est grandement facilitée. Bref, Feign possède les principales caractéristiques pour en faire l’un des principaux clients HTTP.

“You can’t FEIGN ignorance now”.

Sources

https://github.com/OpenFeign/feign
http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html#spring-cloud-feign
https://dzone.com/articles/the-netflix-stack-using-spring-boot-part-3-feign

Catégories: Blog Société

Domain Driven Design (DDD) ou la conception pilotée par le domaine

Lors de l’évènement NCrafts 2016, j’ai entendu dans plusieurs confĂ©rences auxquelles j’ai participĂ©, l’acronyme DDD et le nom du livre bleu « Domain Driven Design » d’Eric Evans. J’ai donc appris que cette approche de conception Ă©tait devenue très populaire parmi les craftsmen et j’ai dĂ©cidĂ© d’écrire un article sur ce sujet. Ce qu’il faut savoir avant […]
Catégories: Blog Société

Firebase : le nouveau Parse ?

De la base de données temps réel créée par une startup en 2012 à la galaxie de services développés pafirebaser Google, Firebase a bien changé depuis son rachat en 2014. Nous vous proposons un petit tour d’horizon des différentes fonctionnalités sous l’angle du retour d’expérience ainsi qu’une petite analyse de la stratégie du géant du web vis-à-vis des outils de développement mobile.

Realtime database : un jeu d’enfant

Realtime databaseComme nous venons de l’évoquer en introduction, la fonctionnalité phare que Firebase offre est sa base de données dite “temps-réel”. Concrètement, cela se traduit par une structure de données au format json synchronisée de manière automatique et quasi instantanée avec en prime une gestion des interruptions réseau. Sa force réside principalement dans sa facilité de mise en oeuvre. En seulement quelques lignes de code et moins de temps qu’il ne faut pour lancer la compilation, le SDK est intégré, configuré et la première salve de données synchronisée. Un jeu d’enfant. Qui plus est, tous les services Firebase sont disponibles sur les deux plateformes mobiles principales (Android et iOS) ainsi que sur le web* via une API et un SDK Javascript. Si votre besoin est la mise en place d’un chat cross-platform, ce service va vous faire gagner beaucoup de temps. Mais les cas d’usages sont évidemment bien plus nombreux et variés. A Octo, nous avons par exemple réalisé une application de partage de photos en interne via une application mobile qui repose sur cette solution. Les photos en elles-mêmes sont stockées chez un hébergeur tiers mais toutes les informations relatives aux clichés sont persistées et synchronisées dans la base de données temps réel. Un autre avantage à son utilisation est la gestion de l’authentification et des droits d’accès aux données. En effet, si l’identification via le compte Google est sans effort, elle l’est tout autant via d’autres fournisseurs d’identités tels que Facebook, Twitter ou Github. Une version beta d’un module d’authentification unifiée sur mobile est même disponible sur Github. D’autre part, il est possible d’administrer les droits en écriture et lecture aux données depuis la console web grâce à un moteur de règles assez efficace.

* à l’exception du Crash Reporting et du Remote Config, inapplicables sur web

Analytics : la fin de la corvée de taggage

AnalyticsA côté de cette fonctionnalité historique s’ajoutent donc des services très importants pour les développeurs d’applications mobiles. La suivante est une des spécialités de Google et elle est au centre de la galaxie Firebase : l’analytics. En effet, s’il y a un domaine dans lequel le géant peut revendiquer une hégémonie, c’est dans l’analyse de trafic de sites web.

Dès que vous intĂ©grez le SDK de Firebase, sans mĂŞme ajouter une seule ligne de code, une masse assez importante de donnĂ©es concernant vos utilisateurs (âge, sexe, zone gĂ©ographique par exemple) ainsi que leurs usages (rĂ©tention, dĂ©sinstallation) remontent automatiquement. Ces donnĂ©es prĂ©cieuses pour comprendre quels sont les points forts et faibles de votre application sont agrĂ©gĂ©es sous la forme de rapports explorables dans le temps. Vous pouvez par ailleurs dĂ©finir des Ă©vĂ©nements personnalisĂ©s afin de suivre l’évolution de tel ou tel comportement. A noter qu’il y a une distinction entre ces Ă©vĂ©nements – l’ouverture de tel Ă©cran par exemple – et les “propriĂ©tĂ©s utilisateurs” qui regroupent les donnĂ©es concernant les caractĂ©ristiques d’une personne ayant installĂ© votre application. La distinction a notamment pour consĂ©quence de ne pas pouvoir suivre l’évolution de ces propriĂ©tĂ©s utilisateurs puisque celles-ci ne varient pas dans le temps. Par exemple, si vous souhaitez mesurer le nombre d’utilisateurs qui ont dĂ©cidĂ© de ne pas accepter la rĂ©ception de notification, vous n’aurez pas l’évolution temporelle de ce ceux-ci mais seulement une photographie Ă  l’instant T de la population. Si vous dĂ©sirez ajouter la dimension temporelle Ă  cette donnĂ©e tout en la recoupant avec d’autres informations, l’utilisation des Ă©vĂ©nements est recommandĂ©e mais vous devrez faire appel Ă  un service tiers de Google (Big Query). A noter que les donnĂ©es rĂ©coltĂ©es par Firebase sont exploitables dans un dĂ©lai de 24 heures (certainement pour des raisons de consolidation). Enfin, il est intĂ©ressant de noter la possibilitĂ© de crĂ©er des cohortes d’utilisateurs afin de suivre des micro-tendances dans une population ou encore la possibilitĂ© de rĂ©colter celles concernant les achats in-app directement sur les stores respectifs (App Store compris).

Pour aller plus loin : https://medium.com/google-developer-experts/firebase-analytics-vs-google-analytics-b2010f34d2bb#.3q35ui3zk

Remote Config (ou l’A/B testing facile et rapide)

Remote configParmi les autres services qui méritent notre attention, “Remote Config” est certainement le plus intéressant ensuite. En effet, il s’agit ici de définir un ensemble de clés / valeurs afin de rendre configurable à distance des fonctionnalités de votre application. Là encore, la force de la fonctionnalité réside dans sa simplicité de mise en oeuvre. Quelques lignes de code suffisent pour l’intégrer ainsi qu’un fichier de configuration où vous définissez les valeurs par défaut de vos paramètres. Et le tour est joué ! Libre à vous de modifier ensuite la valeur de ces paramètres dans l’interface web lorsque le besoin s’en fait sentir. Les modifications prendront effet dès l’expiration du cache que vous aurez éventuellement redéfini (12 heures par défaut). C’est un outil très utile pour ne pas avoir à maintenir et héberger des fichiers de configurations statiques ou pire encore : définir “en dur” la valeur de ces paramètres qui nécessitent une mise à jour de l’application à chaque modification. Enfin, il est intéressant de noter que les valeurs peuvent être conditionnées par des contraintes telles que la plateforme (iOS/Android), une version de l’application, la langue du téléphone ou encore un pourcentage déterminé de la population d’utilisateurs. Un outil qui peut donc servir pour vos campagnes d’A/B testing dès lors que vous le couplez à l’analytics ! Nous avons par exemple fait l’usage de cette fonctionnalité afin d’afficher deux versions différentes d’une incitation à l’abonnement dans l’application La Matinale du Monde : cela nous permet de mesurer quelle version de l’incitation va maximiser le taux de conversion. En effet, celle qui va conduire au plus grand nombre de nouveaux abonnés est ensuite diffusée à l’ensemble des utilisateurs. Plus d’infos sur le Remote Config ici.

Hébergement web : le déploiement en une ligne de commande

cdnDeux autres services qui ne sont pas révolutionnaires mais fort appréciables sont aussi mis à disposition : l’hébergement de fichiers statiques et de fichiers volumineux. Le premier permettant d’y déployer en deux commandes (grâce à la Firebase CLI) des applications front (JS, HTML/CSS) sur le CDN de Google et le second d’y stocker vos assets v
olumineux (ou ceux générés par vos utilisateurs).

Nous avons pu utiliser ces outils afin de mettre en place un “mock d’API” afin de réaliser des tests en conditions réelles sans pour autant dépendre du backend de production. Cela nous a fait gagner du temps et de la flexibilité. Plus d’infos sur l’hébergement ici et là.

Test Labs & Crash Reporting : adieu les bugs

Bug reportingCôté développeurs, on appréciera également la présence du Test Lab (bien que seulement accessible à partir du plan “Blaze”) ainsi que du Crash Monitoring qui permettent de détecter en amont et en aval les éventuels comportements anormaux de votre application.

Le premier grâce Ă  une batterie de devices sur lesquels vont s’exĂ©cuter des tests d’interfaces (ou des Monkey Tests) puis vous gĂ©nĂ©rer un rapport avec des screenshots afin de comprendre les parcours effectuĂ©s.

Le second se charge plus classiquement de remonter les stacktraces des plantages que vos utilisateurs ont pu subir avec les informations complémentaires telles que le modèle ou la version du système. On notera que ces deux services sont déjà présents dans la console d’administration du Play Store. L’avenir nous dira s’ils peuvent coexister ou si celui de Firebase va supplanter l’existant. Cependant, il est intéressant de noter que cette fonctionnalité vient en enrichir une autre que nous évoquions plus haut : l’analytics. Il est possible de segmenter votre population d’utilisateurs selon un critère bien particulier : “ont-ils été impacté ou non par un certain crash ?”. On pourrait ainsi imaginer définir une population d’utilisateurs victimes d’un bug et choisir ensuite de les cibler grâce à Remote Config afin de leur afficher un message d’explication, voire les inciter à mettre à jour leur application. On voit là toute la puissance des différents services dès lors qu’on les fait interagir.

Plus d’infos sur le Crash Reporting ici.

Dynamic Links & Push Notification : un seul système pour les relancer tous

fcmEnfin, on peut citer les deux dernières fonctionnalités de Firebase que sont le Dynamic Links et le service de notifications. Nous ne nous attarderons pas sur ce dernier qui vient en remplacement du système actuel côté Android (Google Cloud Messaging devient Firebase Cloud Messaging) qui centralise et simplifie l’envoi de push sur une seule et même interface (aussi disponible pour iOS).

Quant au Dynamic Links, c’est lĂ  encore une manière d’unifier et centraliser les points d’entrĂ©e dans vos applications en crĂ©ant des deep links communs. Les URLs gĂ©nĂ©rĂ©es sont “intelligentes” puisqu’elles redirigent les utilisateurs tantĂ´t sur le store d’application de son tĂ©lĂ©phone (App Store ou Play Store) si l’application n’est pas installĂ©e tantĂ´t directement dans l’application si celle-ci est dĂ©jĂ  prĂ©sente. Vous pouvez Ă©galement dĂ©finir des URLs web de fallback dans le cas oĂą l’utilisateur tenterait d’ouvrir le lien dans un navigateur sur ordinateur.

Firebase : le nouveau Parse ?

parseBien que leurs ambitions semblent différentes et que les fonctionnalités divergent, un point commun nous fait inévitablement penser au “backend-mobile-as-a-service” Parse. Une question que l’on est en droit de se poser quand on connaît son destin funeste : Firebase peut-elle subir le même sort ? Il existe au passage une documentation pour migrer d’une implémentation de Parse à l’utilisation de Firebase (guide iOS et Android).

La réponse la plus probable est non. Pour plusieurs raisons.

La plus évidente étant que, s’ils tentent tous les deux de simplifier le travail des développeurs mobiles en leur fournissant une solution clé en main pour leur backend, c’est bien là leur seul point commun. En effet, Firebase est plus un ensemble de services regroupés sous la même bannière plutôt qu’un “simple” serveur pour applications mobiles. Il est donc possible qu’un jour, certains services soient dépréciés s’ils sont jugés dépassés par Google mais ils seront certainement remplacés par de nouveaux produits qui viendront compenser leur disparition. Car c’est là aussi que réside la force de la franchise Firebase : elle va très certainement s’enrichir de nouveaux services dans le futur. Vous pouvez d’ailleurs vous-même faire la demande de nouvelles fonctionnalités grâce à ce formulaire mis à disposition par Google : https://firebase.google.com/support/contact/bugs-features/

Un service de Mobile Application Management Ă  venir ?

Personnellement, je ne serais pas surpris de voir, par exemple, un MAM faire son apparition dans la liste des produits Ă  moyen ou long terme. En effet, Firebase et le Play Store ne sont finalement que deux facettes diffĂ©rentes d’une seule et mĂŞme pièce : l’une Ă  destination des dĂ©veloppeurs, l’autre du reste du monde. On a vu qu’il y avait parfois dans l’offre de Google une certaine redondance (le Cloud Test Lab ou encore l’analytics par exemple).

Ce qui peut nous faire croire qu’un MAM pourrait ĂŞtre dans les cartons de Google c’est que ce qui transpire de la stratĂ©gie Firebase c’est une tendance Ă  l’unification des offres en proposant systĂ©matiquement les services en cross-platform. Ils pourraient donc proposer cette solution de MAM Ă  travers Firebase en y mettant Ă  disposition les SDKs nĂ©cessaires Ă  l’intĂ©gration de la solution tout en gardant l’interface de gestion indĂ©pendante dans une sorte de store privĂ© unifiĂ© qui s’appuierait en partie sur le Play Store existant pour Android ainsi qu’une solution spĂ©cifique dĂ©veloppĂ©e pour iOS. Tout cela n’est que spĂ©culation mais seul l’avenir nous dira quelle direction Firebase va pouvoir prendre dans le futur.

Conclusion

En conclusion, la volontĂ© de Google est bien de fournir tous les services web nĂ©cessaires au bon fonctionnement d’applications mobiles et habituellement dĂ©veloppĂ©s en interne ou servis par de nombreux tiers (dont la qualitĂ© et la facilitĂ© d’intĂ©gration sont très variables). Nous pourrions, en thĂ©orie, dans les applications oĂą nous l’avons intĂ©grĂ©, nous sĂ©parer d’au moins deux services fournis par des tiers (sans compter la solution de publicitĂ© que nous n’avons pas testĂ©e) et donc d’autant de SDKs peu satisfaisants. La qualitĂ© globale de nos applications ne peut donc qu’être meilleure en utilisant des services Firebase.

Attention tout de mĂŞme aux tarifs ! Car si le fair-use est largement suffisant pour une utilisation restreinte, la facture peut devenir salĂ©e si votre application doit en faire un usage intensif. Et c’est bien lĂ  que rĂ©side une partie de la stratĂ©gie de Google : un bon nombre de services que nous avons citĂ©s dans cet article sont “gratuits” et servent en fait de produits d’appel pour d’autres produits dont les tarifs sont, certes adaptatifs, mais pas forcĂ©ment compĂ©titifs. C’est lĂ  certainement le prix de la simplicitĂ© de mise en oeuvre. Mais il faut aussi garder Ă  l’esprit que le fonds de commerce initial de Google rĂ©side dans la data. Et plus prĂ©cisĂ©ment dans l’accumulation de celle-ci puis son analyse statistique Ă  des fins publicitaires. On est donc en droit de se demander si derrière les produits d’appel “gratuits” que nous avons Ă©voquĂ©s, nous ne passons pas Ă  la caisse une seconde fois en partageant des donnĂ©es sur les utilisateurs de nos applications ainsi que sur leurs usages. Le vĂ©ritable enjeu pour Google est bien sĂ»r de conserver la main sur les donnĂ©es gĂ©nĂ©rĂ©es par les applications mobiles et leurs utilisateurs grâce Ă  une facilitĂ© d’intĂ©gration inĂ©galĂ©e sur le marchĂ©.

Au final, les produits estampillés Firebase sont puissants et faciles à mettre en oeuvre mais il faut veiller à ne pas devenir totalement dépendant d’un seul acteur qui a, d’une manière générale, tendance à vouloir se rendre indispensable.

Articles suggested :

  1. Quelles interfaces pour les voitures de demain ? (1/3)
  2. Quelles interfaces pour les voitures de demain ? (2/3)
  3. Quelles interfaces pour les voitures de demain ? (3/3)

Catégories: Blog Société

RH Agile: Une CoP Agile qui marche- Conférence à Lille le 13 oct

Qualitystreet - Jean Claude GROSJEAN - mar, 09/20/2016 - 14:02

Les communautĂ©s de pratiques sont au coeur de toute dĂ©marche de transformation dans l’Entreprise; et ces CoP agile dont je vais vous parler, ont cette extraordinaire capacitĂ© de rĂ©unir dans un mĂŞme Ă©lan, des acteurs de l’Entreprise qui n’ont pas encore l’habitude de collaborer efficacement ensemble: Equipes IT, SCM, Product Owners, Management et RH. Comme vous…

The post RH Agile: Une CoP Agile qui marche- Conférence à Lille le 13 oct appeared first on QualityStreet - Blog Pro de Jean Claude Grosjean.

Catégories: Blog Individuel

Confluence for sales teams

Le blog de Valiantys - mar, 09/20/2016 - 09:05

Confluence for sales teams – does it work? Yes! As an Atlassian Platinum Expert, Valiantys has of course chosen to use Confluence for its internal documentation. In this blog post, we’ll review why, and how, the Valiantys sales team uses Confluence. We share everything One of the main functions of Confluence is to allow knowledge ...

The post Confluence for sales teams appeared first on Valiantys Blog - Atlassian Expert.

Catégories: Blog Société

C’est la rentrée de l’open source et du Hackergarten.

Hackergarten
Cette fois c’est officiel : la fin des vacances est là.
La rentrée débute et vous vous demandez sans doute dans quel projet open source vous voulez participer à partir de septembre ?
Le Hackergarten de la rentrée tombe à pic !
Venez nombreux coder pour le bien commun : mardi 27 septembre 2016, dans les locaux de Xebia, 156 boulevard Haussmann Paris, 7e Ă©tage.

Même si on vous l’a déjà expliqué précédemment, il est toujours utile de vous rappeler quel est le but de ce meetup : organiser des rencontres physiques entre contributeurs majeurs voire créateurs de projets open source et de futurs contributeurs. Quoi de plus simple pour démarrer sur un projet que de faire du pair programming avec un développeur chevronné qui vous installe tous les outils en moins de temps qu’il ne faut pour le dire ?
Hackergarten c’est l’endroit idĂ©al pour commencer l’annĂ©e en rayant de votre liste une de vos bonnes rĂ©solutions : sauter le pas pour contribuer Ă  l’open source ! Ne soyez pas timides, mais n’oubliez pas d’emmener votre machine avec vous.

Si vous souhaitez participer à cette session, seront présents :

L’inscription est gratuite et le buffet est offert pour vous récompenser de votre séance de coding. Alors n’hésitez pas à participer.

Catégories: Blog Société

Industrialiser le développement et déploiement de plugins Kibana (avec Docker)

par Alexandre Masselot (OCTO Technology Switzerland), Catherine Zwahlen (OCTO Technology Switzerland) et Jonathan Gianfreda.

La possibilitĂ© de personnaliser des plugins est une promesse forte de Kibana. Nous proposons un article sur comment Ă©crire de tels plugins de A Ă  Z. Mais ce chemin comprend plus que l’Ă©criture per se d’un plugin: il nous faudra aussi aborder des points comme: « comment mettre in place le dĂ©ploiement continu? », « comment mettre en place un environnement avec des donnĂ©es initiales? » Ces questions nous embarquent dans la construction d’une infrastructure de dĂ©veloppement et de CI, basĂ©e sur Docker.

La suite de l’article en anglais…

Catégories: Blog Société

Scrum pour la Recherche

J’ai récemment coaché une équipe de R&D sur un projet impliquant beaucoup de travaux de recherche. L’équipe devait trouver des solutions innovantes à des problématiques complexes liées au traitement de l’image. Cela passait par la lecture de papiers scientifiques, l’étude de « l’état de l’art », le test de diverses solutions, parfois en creusant profondément une piste pour finalement se rendre compte qu’elle n’était pas viable, etc.

Ces solutions étaient alors implémentées et livrées par l’équipe dans un moteur de traitement d’image pouvant être utilisé tel quel par certains clients, ou intégré par d’autres, dans des applications grand public.

Les membres de cette Ă©quipe connaissaient vaguement Scrum, mais avaient du mal Ă  voir comment cela pouvait fonctionner sur leur projet. La littĂ©rature Agile ne les aidait pas non plus beaucoup – comme s’ils Ă©taient parmi les premiers Ă  vouloir utiliser Scrum pour la Recherche.

Voici donc comment nous nous y sommes pris pour implémenter Scrum sur ce projet, et les 5 clés de notre succès.

1. Accepter l’incertitude

Lorsqu’une Ă©quipe Scrum doit dĂ©terminer si elle peut implĂ©menter directement une User Story, ou si elle ferait mieux de passer par un « Spike » afin d’acquĂ©rir d’abord de la connaissance et de lever certains risques, elle Ă©value le niveau d’incertitude. Si celui-ci est au-delĂ  d’un certain seuil – appelons le « Seuil de Spike »  que l’équipe a inconsciemment dĂ©fini comme Ă©tant le maximum d’incertitude qu’ils Ă©taient prĂŞts Ă  accepter dans leur Sprint, alors, il commencent par un Spike.

Même si tout ceci est très abstrait, dans l’ensemble, j’ai le sentiment que ce « Seuil de Spike » est à peu près le même dans toutes les équipes que j’ai coaché auparavant. Ce seuil est tel qu’environ 10% des User Stories doivent être précédées d’un Spike afin de gagner en certitude.
Scrum pour la Recherche

Sur ce projet-là, définir un « Seuil de Spike » équivalent nous aurait amené à avoir un Spike pour plus de la moitié de nos User Stories. Ce que nous ne voulions pas car cela aurait réduit notre capacité à livrer de la valeur à nos utilisateurs rapidement. Nous avons donc convenu d’accepter d’avantage d’incertitude dans nos Sprints en augmentant notre « Seuil de Spike » afin de garder un nombre relativement faible de Spikes dans nos Sprints et d’avoir une chance de livrer plus rapidement de la valeur.

scrum pour la recherche

Nous avons donc dû apprendre à chiffrer des User Stories alors qu’une part non négligeable du travail restait à découvrir. Nous avons limité les dégâts en nous dotant d’une bonne baseline pour l’estimation en Story Points, et en l’améliorant régulièrement.

Notez que malgré tout ça, nous avions plus de Spikes dans nos Sprints que la plupart des équipes Scrum.

2. Accepter d’échouer

En acceptant cette incertitude dans nos Sprints, ce que l’on accepte aussi – en plus d’un grand écart-type sur la Vélocité – c’est l’échec pur et simple ! Nous avons accepté que parfois, une User Story serait abandonnée après quelques jours de travail et que nous aurions alors à trouver quoi faire à la place, en plein milieu du Sprint.

Accepter d’échouer, ce n’est facile pour personne, mais je crois que c’était encore plus difficile pour certaines personnes de cette équipe. Les chercheurs et les docteurs n’aimant vraiment pas échouer ! Ils aiment penser qu’ils ont « réfléchi à tout » avant de se lancer dans l’implémentation. Et lorsque l’implémentation commence, ils aiment que ce soit fluide.

3. Le Buffer d’Interruption

L’autre ajustement clĂ© que nous avons mis en place s’inspire d’un classique des « Patterns » listĂ©s sur ScrumPlop, et un des favoris de Jeff Sutherland himself : Illegitimus Non Interruptus. Avec les spĂ©cificitĂ©s suivantes :

  • Ce buffer reprĂ©sentait parfois jusqu’à 40% de la vĂ©locitĂ© de l’équipe. C’était assez nouveau pour moi, pour autant, je crois savoir que certaines Ă©quipes (celles qui font beaucoup de support ou de maintenance notamment) utilisent un buffer encore plus gros, donc ce n’est pas si exotique que cela.
  • Nous utilisions ce buffer, non pas seulement pour gĂ©rer des imprĂ©vus (support, bugs et autres urgences), mais principalement pour ajouter des User Stories au Sprint Ă  mesure que l’équipe avançait dans le Sprint, en fonction de ce qu’elle dĂ©couvrait.
    Par exemple, si notre vĂ©locitĂ© Ă©tait de 30, notre backlog de Sprint, d’une durĂ©e de 3 semaines, pouvait ressembler Ă  ceci :
    – Une User Story à 5 points
    – Une User Story Ă  3 points
    – Un Spike Ă  5 points
    – Une User Story Ă  2 points
    – Un Spike Ă  3 points
    – Un buffer de 12 pointsA la fin des Spikes, nous nous posions alors la question de quoi rajouter au Sprint, au vu des nouvelles connaissances acquises par l’équipe et sachant que nous ne pouvions pas ajouter plus de 12 points. Bien que cette approche ne soit pas recommandable partout, elle nous a clairement semblĂ© une meilleure approche que de s’obliger Ă  attendre le prochain Sprint Planning pour continuer sur un sujet.

Je dois dire que ce Buffer fut un élément clé de la réussite de Scrum sur ce projet, et d’une certaine adhésion de l’équipe à Scrum. Avant cela, l’équipe voyait Scrum comme une « méthode consistant à définir 100% du travail à faire toutes les trois semaines, et interdisant de se tromper, de changer d’avis, ou de découvrir de nouvelles informations entre deux Sprint Plannings ».

4. Devenir des champions du découpage des User Stories

DĂ©couper des User Stories n’est jamais simple au tout dĂ©but. Mais ici, ce l’Ă©tait encore moins. Il nous a fallu ĂŞtre parfois très ingĂ©nieux pour trouver l’ultime dĂ©coupage qui rendrait notre User Story suffisamment « petite » (voir plus loin) pour rentrer dans un Sprint. Il nous a aussi fallu apprendre Ă  faire des compromis – mais les bons – sur nos User Stories ; Ă  renoncer Ă  une des lettres de « INVEST » parfois… Pour cela, je me suis tournĂ© vers les meilleurs : Craig Larman et Bas Vodde, qui, dans leurs livres Scaling Lean and Agile Development et Practices for Scaling Lean and Agile Development prĂ©sentent une sĂ©rie de techniques de dĂ©coupage avec lesquelles nous nous sommes familiarisĂ©s.

J’ai organisé un atelier dans lequel, par petits groupes et sur des User Stories réelles de l’équipe, nous avons expérimenté différentes manières de découper, et comparé les avantages et les inconvénients de chacune. Notre façon de découper le travail était par ailleurs un sujet récurrent de nos Sprint Retrospectives. Au final, nos techniques de découpage favorites étaient :

  • le dĂ©coupage par « Stub » (implĂ©mentation d’un « faux » pour une partie non-disponible du système, de l’algorithme, afin d’ĂŞtre en mesure de travailler sur d’autres parties)
  • le dĂ©coupage par taux de succès (l’algorithme doit donner un taux satisfaisant sur 50% de la base, puis 70%, 90%, etc.)
  • le dĂ©coupage par performance (la fonctionnalité peut d’abord s’exĂ©cuter sans contrainte de temps, puis en moins d’une minute, de 500 millisecondes, etc.)
  • le dĂ©coupage par type de donnĂ©es (images RGB, images RAW)
5. Redéfinir « Small »

Jusqu’à mon intervention sur ce projet, j’avais tendance à définir une User Story « petite » comme représentant « jusqu’à 50 heures de travail ». C’est ce que je disais aux équipes que je coachais, et cela ne fonctionnait pas trop mal. Ici, cela n’était tout simplement pas possible. L’incertitude était trop grande, le domaine, et le code, trop complexe. A titre d’illustration, nous avons une fois réalisé le simple « squelette » d’une fonctionnalité. Une implémentation parfaite d’une fonctionnalité ne faisant concrètement rien, mais respectant notre « Definition of Done ». Cela nous a pris 30 heures. Donc si 50 est le maximum autorisé, cela ne nous laisse pas grand-chose pour trouver une solution à un quelconque problème, l’implémenter, encore moins pour essayer, se tromper, et recommencer.

A la place, nous sommes convenus d’une autre définition de « Small » : « un binôme pendant un demi Sprint ». C’est-à-dire 120 heures de travail. C’est ce que nous visions comme taille maximale lors des découpages. Et cela restait encore parfois compliqué…

Et voilĂ , c’est tout ! Nous avons donc dĂ©montrĂ© que Scrum pouvait tout Ă  fait fonctionner sur ce type de projet Ă  l’incertitude forte. Bien sĂ»r, nous aurions pu aussi adopter une approche Kanban qui facilite une gestion au fil de l’eau, mais nous apprĂ©cions la cadence imposĂ©e par Scrum, ses objectifs de Sprint atteignables Ă  court terme et le temps dĂ©diĂ© pour prendre du recul sur le produit et le process entre les Sprints. Au delĂ  du cadre choisi, je dirais que le plus important reste de s’adapter aux prĂ©fĂ©rences de l’Ă©quipe et aux Ă©lĂ©ments avec lesquels elle se sent le plus Ă  l’aise. Ainsi, mĂŞme en R&D Scrum fonctionne. Il faut simplement se rappeler que Scrum est un Framework dĂ©finissant peu de choses au final, et dans le cadre duquel il revient Ă  chaque Ă©quipe d’essayer des choses, d’inspecter, de s’adapter, et de recommencer.

Ce billet a été initialement posté en anglais sur le site de la Scrum Alliance : Scrum for Research.

Catégories: Blog Société

LCC 154 - Interview sur Groovy avec CĂ©dric Champeau et Guillaume Laforge

Cédric et Guillaume nous font un tour de Groovy le langage mais aussi l’écosystème et sa place dans l’univers.

Enregistré le 6 septembre 2016

Téléchargement de l’épisode LesCastCodeurs-Episode–154.mp3

Interview Ta vie, ton Ĺ“uvre

Guillaume Laforge
@glaforge
Google

CĂ©dric Champeau
@CedricChampeau
Gradle

Le langage

Qu’est-ce que Groovy en quelques mots ?
Les langages dynamiques sont moins hype qu’il y a 5 ans, quels sont les avantages selon vous ?

Quelles sont les points les plus intéressants selon vous de Groovy ?

Groovy
Rhino
BeanShell
Fondation Apache

Pouvez vous expliquer le Metaobject Protocol ?
Et la fonctionnalité AST ?
Les transformations AST

Langage interprété vs compilé d’après Wikipedia, réponse StackOverflow

Qu’est ce que Groovy statique ?

Ou est-ce que vous voyez les usages typiques de Groovy ?

Plateforme et usages

Grails est la plateforme utilisant Groovy la plus connue.
Pouvez vous expliquer le principe, et comment cela fonctionne ?
Des exemples de points ou une plateforme spécifique bénéficie d’un langage dynamique ?
Grails

Quels sont les dernières évolutions de Grails

D’autres plateformes ou outils à Mentionner ?

Gradle
Spock
GPars
Ratpack

Sous le capot

Comment Groovy est implémenté ?
C’est compliqué d’écrire un compilo ?

Java 9, des progrès ?
Jigsaw

La JVM est plus mutilangages (invokedynamic): vous en avez profité ?
Est-ce l’inter-opérabilité entre les langages de la JVM s’améliore ? Des plans de standardisation ?
Truffle
Dynalink

Le Futur

Quel sont les choses sur lesquelles vous travaillez ?
Antlr

Nous contacter

Contactez-nous via twitter https://twitter.com/lescastcodeurs
sur le groupe Google https://groups.google.com/group/lescastcodeurs
ou sur le site web https://lescastcodeurs.com/
Flattr-ez nous (dons) sur https://lescastcodeurs.com/
En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

Managing for happiness avec Jurgen Appelo chez Xebia

managing for hapinessXebia a le plaisir de vous convier à une présentation sur le thème Management 3.0 animée par Patrick Sarfati et Jurgen Appelo le 7 octobre à 17h.

Jurgen prĂ©sentera son nouveau livre : « Managing for happiness » qu’il se fera un plaisir de dĂ©dicacer pour ceux qui le souhaitent.

L’ouvrage abordera les thèmes suivants :
– Outils et pratiques accĂ©lĂ©rant la  motivation de vos Ă©quipes

– La mesure de la performance, en particulier dans des Ă©quipes agiles

– Comment rĂ©compenser les collaborateurs d’une meilleure façon que les systèmes de bonus parfois contre productifs?

– Comment remplacer les Ă©valuations de performance annuelles ?

– Comment changer la culture d’une organisation pour aller vers plus d’agilité ?

http://wtvr.com/2016/08/10/manage-your-happiness/

Ce livre est Ă  la base de l’atelier « Management 3.0 workout » de Jurgen, animĂ©e en partenariat avec Patrick et Xebia le 20 janvier Ă  Paris dans nos locaux (consulter le programme).

Cet Ă©vènement dĂ©marrera à 17h avec une prĂ©sentation d’une heure (17h30-18h30) suivi d’un buffet en prĂ©sence de Jurgen et de Patrick. L’inscription se fait sur ici. 

RDV dans nos locaux, au 156, boulevard Haussmann, Ă©tage 7, Paris 8.

Catégories: Blog Société

1CUBE&GO arrive Ă  Grenoble

cube_marche2_800_350-svgProposer des formations Ă  l’agilitĂ© courtes, ciblĂ©es, orientĂ©e pratiques et Ă©changes, et payables directement par CB, c’est l’objectif de 1CUBE&GO.

A l’origine de ce nouveau concept, il y a 3 compères : Romain Couturier, GrĂ©gory Alexandre et Alfred Almendra. Et lorsque Romain m’en a parlĂ© lors de la dernière rĂ©union de la FĂ©dĂ©ration Agile, j’ai tout de suite eu envie d’y participer (tout comme Claudio qui fait de mĂŞme sur Toulouse).

Quelques informations sur le prochain 1CUBE&GO sur Grenoble

Date : lundi 7 novembre de 14h00 Ă  17h30

Sujet : Prioriser, estimer et Planifier

Lieu : A définir en fonction du nombre de participants

Inscription : Paiement direct via Yurplan

Vous trouverez ci-dessous quelques raisons qui me font adhérer à 1CUBE&GO et qui pourrait vous donner envie de venir :)

Une formation ciblée à plusieurs avec un coachagile

Bien souvent, les praticiens de l’agilitĂ© se trouvent confrontĂ©s Ă  des questions spĂ©cifiques sur leur pratique de l’agilitĂ©.

  • La recherche documentaire (livre ou web) est gĂ©nĂ©ralement longue et il est parfois difficile d’y retrouver sa propre problĂ©matique.
  • La prĂ©sence d’un coachagile est souvent une bonne aide car il peut avoir dĂ©jĂ  rencontrĂ© un problème similaire dans une autre Ă©quipe ou organisation
  • Les collègues sont Ă©galement une aide en expliquant comment ils pratiquent eux-mĂŞme dans leurs Ă©quipes. Reste alors Ă  Ă©valuer la possibilitĂ© d’adapter leurs pratiques au fonctionnement de votre Ă©quipe.
  • Et parfois c’est le questionnement mĂŞme du praticien qui devrait ĂŞtre remis en cause.

1CUBE&GO c’est l’occasion de pratiquer des techniques nouvelles, ou approfondir des techniques connues, liĂ©es Ă  votre problĂ©matique. De faire cela en prĂ©sentiel avec d’autres personnes ayant des questions similaires. En prĂ©sence d’un coachagile pour vous aider Ă  faire le tri dans vos questions et vous aider Ă  trouver la façon de faire la mieux adapter dans votre contexte spĂ©cifique.

Une formation courte à un coût raisonnable

Vous manquez de temps, comme beaucoup d’autres,  et je pense nĂ©anmoins qu’il est raisonnable d’investir 1/2 journĂ©e pour traiter un sujet qui vous intĂ©resse vraiment. Je peux vous garantir que ces 3h30 de pratiques vous apporteront de vrais bĂ©nĂ©fices dans votre pratique de l’agilitĂ©.

Vous avez dĂ©jĂ  achetez un livre Ă  40 € parlant d’agilitĂ©. 1CUBE&GO ne coute que l’Ă©quivalent de 4,5 livres (ou 51 kg de noix pour les Grenoblois) et devrait vous apporter tout autant que leur simple lecture sans pratique.

Le paiement est direct, comme un achat de fourniture, pour simplifier le traitement administratif liĂ© Ă  la mise en place d’une convention de formation. A vous de vĂ©rifier au prĂ©alable que vous pourrez vous le faire rembourser en note de frais :)

Une formation presque « Ă  la carte »

Il existe plusieurs cubes (9 actuellement), et si l’un des sujets vous intĂ©resse particulièrement, il vous suffit de demander et nous ferons en sorte d’en organiser un rapidement sur Grenoble.

Par contre, c’est quand mĂŞme nous qui fixons les dates :)

Catégories: Blog Individuel

Lancement de la nouvelle Ă©dition de Science Factor

A Duchess Community Blog for France - lun, 09/19/2016 - 08:00
Le premier concours d’innovation technique et scientifique auquel les filles participent autant que les garçons

ImaginĂ© par Global contact et parrainé entre autres par le Ministère de l’Education Nationale ainsi que celui de l’Enseignement SupĂ©rieur et de la Recherche, c’est dĂ©jĂ  la 5ème Ă©dition qui a Ă©tĂ© lancĂ©e le 9 septembre 2016.

Avec cette volontĂ© de mixitĂ© assumĂ©e, Science Factor propose un concours d’innovation en Ă©quipe, pilotĂ© par des filles.

En effet, le but de l’initiative est de susciter des vocations dans les filières scientifiques chez les collĂ©gien-ne-s et lycĂ©en-ne-s.

Et nous les Duchess, ça nous parle !

Pour que les …

Cet article Lancement de la nouvelle Ă©dition de Science Factor est apparu en premier sur Duchess France.

Catégories: Association

Middlewares et autres outils : ce qu’il faut vérifier avant d’acheter

Si vous voulez faire évoluer vos pratiques et en tirer des bénéfices, vos outils doivent être à la hauteur

De quoi s’agit-il ?

Quand j’ai commencĂ© Ă  travailler dans les annĂ©es 2000, les dinosaures dominaient le monde les projets Ă©taient en train de changer. Grâce aux tests automatisĂ©s, Ă  l’extreme programming et aux nouveaux outils qui arrivaient comme les serveurs d’applications et Subversion, on allait apprendre Ă  dĂ©velopper mieux et plus vite.

Les middlewares d’entreprise faisaient partie des points qui posaient problème : ils étaient lourds et inadaptés à nos nouvelles manières de travailler, et ont commencé à devenir des goulets d’étranglement.

Presque 15 ans plus tard, avec les pratiques agiles et le devops, le monde du développement a bien changé. Malheureusement, ce n’est pas le cas pour un certain nombre d’outils : ils ont enrichi leurs fonctionnalités, mais ne se sont pas transformés.

Parfois non industrialisables, non testables ou difficiles à intégrer dans votre SI : ces outils peuvent désormais constituer un vrai frein pour votre capacité à faire. Un environnement technique est toujours nivelé par le bas : le plus mauvais outil dicte ses contraintes à toute la chaîne, du développement à l’exploitation. L’utilisation d’une seule mauvaise brique peut donc avoir des conséquences très lourdes.

S’il est parfois possible de contourner ces restrictions, cela nécessite souvent des rustines fragiles. Rappelez-vous que les outils sont sensés vous aider et non se mettre sur votre route pour vous empêcher de travailler. Avec ces logiciels souvent très complexes, on pense surtout aux fonctionnalités qu’ils promettent et on oublie souvent leurs inconvénients alors que ceux-ci sont pourtant très importants.

Prendre conscience des différents types de limitations peut vous aider dans deux situations :

  • Si vous devez choisir un nouvel outil, ils vous permettent de complĂ©ter votre grille de critères pour ne pas vous tromper. Chez OCTO, lors de ce type de missions, cela fait longtemps qu’ils font partie des prĂ©requis.
  • Si vous avez dĂ©jĂ  ces outils, cela vous rappellera les limites qu’ils vous imposent, et vous fera peut-ĂŞtre rĂ©aliser qu’il est temps d’en changer.

En revanche, cet article ne vous aidera pas à savoir si ce genre d’outil est encore nécessaire, il s’agit d’un autre sujet qui mérite d’être traité à part.

De quels outils parle-t-on ? Des middlewares d'entreprise dans leur habitat naturel, photo par Arian Zwegers en CC

Des middlewares d’entreprise dans leur habitat naturel, photo par Arian Zwegers en CC

C’est un groupe aux limites assez floues mais qu’on peut délimiter par un certain nombre de caractéristiques :
  • ils sont transverses ;
  • ils peuvent ĂŞtre structurants pour le SI suivant l’usage qui en est fait ;
  • ils n’apportent pas de valeur mĂ©tier Ă  proprement parler mais des fonctionnalitĂ©s techniques ;
  • ils ne sont pas choisis par les projets mais de manière transverse, gĂ©nĂ©ralement par une cellule d’architecture et/ou l’équipe en charge de l’exploitation ;
  • ils sont choisis pour durer, et sont donc souvent Ă©valuĂ©s pour leur capacitĂ© Ă  rĂ©pondre Ă  des besoins futurs.

Les exemples les plus caractéristiques sont les middlewares d’entreprise : appliances de sécurité, brique de transfert de fichiers, bus de messages, bus d’entreprises, ETL, outils d’API management et appliances de sécurité. De nombreuses autres briques logicielles suivent tout ou partie des mêmes règles, par exemples les serveurs d’applications ou les base de données.

Logiciels propriétaires

Les logiciels d’entreprises sont un des domaines où les logiciels propriétaires sont encore très représentés. Selon les pratiques des éditeurs, cela peut avoir des conséquences sur leur utilisation.

La gestion des licences

Nous comprenons que l’éditeur veuille s’assurer que ses logiciels soient dûment utilisés, mais il faut que cela soit fait proprement.

L’idéal est un fichier de licence fixe à copier sur les serveurs, que cela soit un fichier unique ou un fichier par environnement : avec des outils de déploiement, il n’y a pas de dégradation par rapport à un outil ouvert.

La capacité des outils de middleware à être élastique est maintenant souvent mise en avant (et on en reparlera plus bas). Si ce sujet est important pour vous, vérifiez que l’ajout de nœuds dans un cluster ne nécessitera pas de changer en même temps le fichier de licence dans chacun des serveurs, y compris les serveurs existants.

Depuis que les dongle matĂ©riels ont quasiment disparu, la pire situation est un « serveur de licences » que l’outil appelle pour valider sa licence.

Deux cas se posent.

Serveur de licence hébergé localement
  • Cela ajoute de la complexitĂ© dans le SI sans bĂ©nĂ©fice pour vous.
  • Ils sont souvent moins bien outillĂ©s et documentĂ©s que les serveurs opĂ©rationnels, les installer et les opĂ©rer est la plupart du temps plus difficile.
  • Ils sont rarement prĂ©vus pour fonctionner en haute disponibilitĂ© ce qui en fait des SPOFs. Quand les serveurs opĂ©rationnels doivent appeler le serveur de licences rĂ©gulièrement ou lors de chaque dĂ©marrage pour pouvoir fonctionner, un serveur de licences non accessible, c’est un morceau ou tout votre SI qui s’arrĂŞte.
Serveur hébergé par l’éditeur
  • Le mĂŞme risque opĂ©rationnel se pose en cas de serveur indisponible : ĂŞtes-vous prĂŞt Ă  vous passer de votre ESB Ă  usage strictement interne si votre connexion Internet tombe ?
  • Un risque de sĂ©curitĂ© : sans tomber dans la paranoĂŻa, un serveur qui fait un appel sortant que vous ne maitrisez pas est toujours dangereux. Ă€ vous d’en Ă©valuer les consĂ©quences.
Les conséquences du coût des licences

Le prix est d’abord un critère de choix pour sélectionner la solution, mais il peut aussi avoir des conséquences sur son utilisation.

Mutualiser les instances

Si le prix est payé par serveur ou par processeur, vous aurez intérêt à diminuer le nombre d’instances pour économiser. Il en résulte souvent une tentation de mutualiser les serveurs au-delà du raisonnable. Le cas qu’on rencontre couramment est celui des serveurs d’applications Java. Les limitations du modèle J2E font que — malgré ce qu’en disent certains éditeurs — utiliser un seul serveur pour plusieurs applications pose beaucoup de difficultés : ressources non isolées, fuites mémoires… Les utilisateurs qui ont le choix utilisent systématiquement un serveur par application, les seuls qui mutualisent leurs serveurs sont ceux qui le font pour limiter leurs coûts de licence, et leur système est moins fiable en contrepartie.

Mutualiser les environnements

On peut aussi être amené à mutualiser les environnements : en fonction de la pression sur les prix, on mutualisera les serveurs de plusieurs environnements au lieu de les isoler.

Les problèmes que cela pose dépendent de la manière dont la mutualisation est mise en œuvre :

  • Les environnements de prĂ©-production et de production sont souvent les seuls Ă  fonctionner en cluster, augmentant d’autant les prix. Quand ils s’exĂ©cutent sur les mĂŞmes serveurs, les tests de performance effectuĂ©s en prĂ©-production risquent de perturber la production.
  • Si les environnements de tests sont mutualisĂ©s et celui de production dĂ©diĂ©, le risque est d’avoir des configurations diffĂ©rentes et donc des rĂ©gressions.
Quand un test de performance fait tomber les serveurs de pré-production, et qu'ils sont mutualisés avec les serveurs de production

Quand un test de performance fait tomber les serveurs de prĂ©-production, et qu’ils sont mutualisĂ©s avec les serveurs de production

Être forcé d’utiliser deux outils

Pour des raisons de coûts, il est parfois nécessaire d’utiliser deux outils différents. Cela peut arriver dans deux cas.

Deux outils en fonction des projets

Cette approche repose sur l’idée que, pour les besoins les plus importants, seule peut convenir une solution vendue par un grand éditeur. Il s’agit d’une survivance des années 2000 où les solutions open source ou vendues par des petits éditeurs étaient souvent moins avancées, et leur support réputé moins fiable. Étant donné le prix de la solution critique, il n’est malheureusement pas possible de l’utiliser partout. Il est donc nécessaire de choisir une deuxième solution pour les autres besoins, ce qui complexifie votre système et augmente son coût.

Un outil réservé à la production

Si, pour certains éditeurs, les licences ne sont nécessaires que pour la production, pour d’autres, il en faut une pour tous les serveurs. Même si les prix sont alors souvent dégressifs en fonction de l’usage, par exemple les instances de recette à moitié prix, cela peut vite faire monter l’addition quand les environnements se multiplient.

La solution alors choisie est d’utiliser l’outil propriétaire pour la production et la pré-production, et un outil open source pour les autres usages, du développement à la recette. Cela se voit beaucoup pour les serveurs d’application Java, et parfois pour des bases de données SQL.

Cela ajoute des bugs supplémentaires qui sont à corriger par l’équipe, bugs détectés très tard dans le cycle du projet et qui ne peuvent pas être testés avant la pré-production.

Architecture

La qualité de service attendu des systèmes a beaucoup monté ces dernières années, et par conséquent les prérequis en termes d’architecture.

Haute disponibilité

La haute disponibilité fait désormais partie des fonctionnalités standard exigées des produits, mais une subtilité est tout de même à vérifier : dans le cas où, en plus des serveurs d’exécution, existe un serveur d’administration, celui-ci peut ne pas être en haute disponibilité. Même si la criticité est moindre (quand le serveur d’administration est indisponible, le système devrait continuer à fonctionner le temps qu’il soit réparé), il s’agit tout de même d’un point de fragilité.

Scalabilité

L’autre élément à examiner est la scalabilité. Même si on parle beaucoup d’élasticité, on a rarement besoin d’ajouter ou de supprimer des instances à tout bout de champs. Par contre une augmentation de trafic peut nécessiter d’ajouter une instance d’ici quelques mois et il est important d’en connaître les impacts.

Si beaucoup de produits revendiquent désormais cette propriété, certains prennent des libertés avec sa définition courante : selon les outils, changer le nombre d’instances peut se faire à chaud et être totalement transparent, diminuer les performance pendant le rééquilibrage de données, voire nécessiter un arrêt complet.

Physique ou virtuel ?

Pour l’hébergement, la virtualisation est désormais la règle. Un logiciel qui nécessite d’être hébergé sur du bare metal aura donc besoin d’une bonne raison pour cela. Encourager l’utilisation du bare metal pour gagner des performances est un chose, la forcer en est une autre.

En dehors de quelques systèmes de niche (sécurité, très haute performance), les appliances physiques sont désormais une espèce disparue et avec elles, le besoin de déplacer et de recabler des serveurs quand une configuration changeait. Le remplacement par des appliances virtuelles supprime la contrainte physique, mais pas les autres :

  • vous ne pourrez pas monitorer cette brique de la mĂŞme manière que les autres ;
  • il faut faire confiance Ă  l’éditeur pour maintenir le système Ă  jour et sĂ©curisĂ©, ce qui devient de moins en moins acceptable avec la multiplication des failles de sĂ©curitĂ© publiĂ©es.
Quand tu attends que l'éditeur publie un correctif de son image disque après une mise à jour critique d'OpenSSL

Quand tu attends que l’Ă©diteur publie un correctif de son image disque après une mise Ă  jour critique d’OpenSSL

Il s’agit donc toujours d’un pis-aller.

En cas d’appliance logique :

  • La solution doit ĂŞtre compatible avec les diffĂ©rents systèmes de virtualisation du marchĂ©. Si l’outil ne fonctionne qu’avec VMware, et mĂŞme si vous utilisez VMware actuellement, il est important de se laisser la possibilitĂ© de migrer vers une autre solution.
  • L’image doit utiliser cloud-init, pour une intĂ©gration facile dans vos outils de provisioning, sinon un coĂ»t et un dĂ©lai supplĂ©mentaires sont Ă  prĂ©voir.

L’avenir dans ce domaine est probablement d’aller vers du Docker : l’éditeur gardera la main sur l’installation et les projets.

DĂ©ploiement et configuration

Pour l’installation, l’outil doit être fourni sous forme d’un package adapté à votre distribution (deb, rpm…). Pour être facilement exploitable, le mieux est de respecter la norme LSB : par exemple, vous trouverez facilement les différents fichiers.

Pour la configuration du socle du logiciel, des recettes de déploiement type Chef / Puppet / Ansible sont désormais la norme. S’ils sont fournis pour un outil qui n’est pas celui que vous utilisez, le portage ne devrait pas être compliqué à condition que l’éditeur ait bien fait son travail.

Pour être facilement utilisables, les fichiers de configurations doivent respecter certains critères :

  • ils doivent ĂŞtre lisibles et Ă©ditables facilement par des humains, pas question par exemple d’avoir des fichiers contenant des objets Java sĂ©ralisĂ©s en XML, ou du XML avec des champs CDATA ;
  • chaque variable doit ĂŞtre prĂ©sente Ă  un seul endroit, gare par exemple aux outils sous forme de composants oĂą chacun a son fichier de configuration propre qui duplique les mĂŞmes Ă©lĂ©ments sans possibilitĂ© de partager les parties identiques.
DĂ©veloppement en Ă©quipe et gestion de version

Sur le papier, une des fonctionnalités les plus mises en avant des middlewares d’entreprise était un outil graphique permettant d’utiliser le logiciel sans recourir au terminal ou éditer de fichiers.

Si ce but est louable, la manière dont il est souvent mis en pratique pose problème.

D’abord, sous prétexte de ne pas avoir besoin d’éditer de fichiers, les fichiers générés par ces outils sont souvent des fichiers binaires. Il est donc impossible d’éditer les fichiers directement et tout doit passer par l’éditeur fourni. Tous les workflows automatiques reposant sur la capacité à modifier des fichiers textuels sont inapplicables, comme le report de modifications entre branches via un outil de gestion de version ou entre environnements via un outil de déploiement. Remplacer ces opérations qui s’automatisent facilement par des opérations manuelles coûte du temps et présente des risques : vous pouvez dire adieu à votre pipeline de déploiement automatisé et bonjour aux régressions.

Après un merge sur un fichier de configuration binaire

Après un merge sur un fichier de configuration binaire

Il reste possible de s’en sortir en utilisant un outil comme Selenium ou  Sikuli pour piloter la saisie de la configuration dans l’outil graphique, mais il s’agit d’une approche coûteuse et fragile à n’utiliser qu’en dernier ressort.

Ensuite les outils utilisant cette approche sont conçus pour être utilisés par une seule personne à la fois. Dans les organisations où un groupe de personne bien identifié est en charge de chaque outil, cette limite est acceptable. On fait une demande à l’équipe en question, qui s’en charge dès qu’elle le peut, en jonglant entre les priorités et ses ressources souvent limitées. Avec le raccourcissement des cycles de développement, ce type de fonctionnement devient invivable : tout est fait pour limiter les dépendances entre équipes et favoriser l’autonomie des équipes. Ce type d’outil devient donc inadapté : pas question de devoir réserver son tour pour avoir le droit de configurer un outil. Les middlewares étant souvent transverses, impossible non plus d’avoir une instance par équipe.

Tests unitaires

Pour les outils ne fournissant que de l’infrastructure, des tests d’intégrations sont suffisant. En revanche, les outils embarquant du code ou du pseudo-code comme les ESB doivent fournir des fonctionnalités permettant d’écrire des tests unitaires automatisés. Ces tests doivent pouvoir se greffer dans votre usine de build, c’est-à-dire :

  • exĂ©cution depuis une ligne de commande et non par un client graphique ;
  • rĂ©sultat ĂŞtre facilement exploitable: messages d’erreurs clairs et utilisation de code de retour pour indiquer le rĂ©sultat des tests.
Exploitabilité

Derniers prérequis : l’exploitabilité de la solution. Sur les outils d’entreprise, l’outil graphique de configuration dont on a parlé plus haut s’accompagnait souvent d’une console d’administration intégrée. Celle-ci fournissait du monitoring et des logs centralisés à une époque où ils étaient encore l’exception. Ce n’est plus le cas désormais, et malheureusement — comme pour la configuration — quand on choisit de ne pas utiliser l’outil fourni pour regarder sous le capot, les choses ne sont pas si rose.

Monitoring

L’application doit pouvoir se monitorer aussi facilement que les autres briques de votre SI :

  • utilisation de formats et de protocoles standards : JMX, SNMP, HTTP, REST, JSON, XML ;
  • le polling ne doit pas ĂŞtre nĂ©cessaire : tous les changements d’état doivent ĂŞtre poussĂ©s ;
  • les informations doivent ĂŞtre accessibles via une API.
Log

Pour être utile, un log doit être accessible et lisible et s’intégrer dans votre chaîne de traitement existante, ce qui nécessite :

  • des connecteurs standard pour l’écriture, Syslog est un minimum ;
  • des formats faciles Ă  parser et univoques : des entrĂ©es monolignes car c’est ce que savent traiter la majoritĂ© des outils, et un format unique par type de log.
Votre parseur de log quand il rencontre une stacktrace Java au milieu d'un fichier de log d'accès

Votre parseur de log quand il rencontre une stacktrace Java au milieu d’un fichier de log d’accès

Gardez espoir

En lisant cet article vous risquez un coup de blues, surtout s’il vous rappelle des souvenirs. Rassurez vous, la situation n’est pas si terrible et elle a même tendance à s’améliorer :

  • Peu d’outils cumulent tous les travers Ă©voquĂ©s ici : la plupart en ont seulement quelques uns. Malheureusement en empilant plusieurs briques avec chacune ses problèmes, les effets se cumulent.
  • Les outils rĂ©cents sont pensĂ©s pour rĂ©pondre aux nouvelles manières de travailler et n’ont donc pas tous les dĂ©fauts de leurs prĂ©dĂ©cesseurs. C’est par exemple le cas de beaucoup des solutions d’abord dĂ©veloppĂ©s pour des besoins internes avant d’être open-sourcĂ©es.

Pour les logiciels plus anciens, la situation est plus sombre. Au cœur des SI, ils sont difficiles à remplacer, et les éditeurs le savent. Ils font donc peu d’efforts pour faire évoluer leurs produits sur ces sujets. Pour améliorer les choses, la meilleure manière sera d’introduire un nouvel outil, souvent par le biais d’un besoin incompatible avec le système existant, puis de travailler à réduire l’emprise de l’outil historique.

Ă€ retenir

Des outils de middleware peuvent être un vrai frein pour votre capacité à livrer mieux et plus vite. Lorsque vous choisissez un tel outil, il faut absolument vérifier ces prérequis :

  • est-ce-qu’il impose des contraintes spĂ©cifiques qui gĂŞnent son utilisation ?
  • est-ce-qu’il est testable ?
  • est-ce-qu’il s’intègre dans vos process de dĂ©veloppement ?
  • est-ce-qu’il s’intègre dans vos process de dĂ©ploiement ?
  • est-ce-qu’il est facile Ă  opĂ©rer ?
Catégories: Blog Société

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux