Il y a 7 ans -

Temps de lecture 8 minutes

Revue de Presse Xebia

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

Agilité

Successful Project with Behavior-Driven Development

Cet article a attiré notre attention pour 2 raisons : il prend le temps d’expliquer le BDD et surtout il fait un retour chiffré sur les impacts sur un projet : Passer de 30% à 2% de retours sur les tickets testés !

L’auteur cite 5 bénéfices du BDD :

  1. La documentation vivante
  2. Une meilleure compréhension de ce qu’on code
  3. Améliore la communication entre les experts du domaine et les développeurs
  4. Encourage la qualité
  5. Réduction du pourcentage de tickets qui ne passe pas les tests à la fin du sprint

Culture vs processus : le match du siècle ?

Au siècle dernier, le manifeste agile nous disait que pour avoir un développement de logiciel de qualité, les individus et leurs interactions apportaient plus de valeur que les processus et les outils. Dans ce nouveau siècle, qui voit fleurir les intentions de transformation de DSI ou d’entreprise vers l’agilité, avec des problématiques qui débordent largement hors du monde du logiciel, on voit que le processus reprend le dessus et que beaucoup de transformations sont des transformations du processus. Si SCRUM ressemble à un processus, il ne faut pas en oublier les fondements culturels portés par le SCRUM MASTER. InfoQ propose un livre blanc qui présente aux décideurs voulant s’engager dans une telle transformation, l’importance de mener de front changement de culture et de pratiques. Sans quoi la transformation agile n’apportera aucun bénéfice voire même pourra entraîner des douleurs humaines et des surcoûts.

Retrouvez le livre blanc, Why agile works.

Anatomy of an Agile User Story Map

Nicolas Muldoon a travaillé par le passé en tant que Product Manager chez Atlassian, l’éditeur derrière Jira. Il propose dans son article Anatomy of an Agile User Story Map une explication du format ainsi qu’une approche pour la constituer, au travers d’un exemple simple (voire universel) : consommer des films sur une apple TV. Sans être révolutionnaire, il contient le minimum vital pour pouvoir faire émerger des Story Maps efficaces. 5 minutes de lecture qui permettent de se rappeler quels sont les bons réflexes à cultiver pour cette étape ‘must have’ dans la constitution du backlog.

Mobilité

Fabric dévoile son application mobile

Annoncé dans le billet Introducing the Fabric mobile app, l’application de Fabric va vous permettre de monitorer les métriques (Crashlytics et Answer) de vos applications directement depuis votre téléphone. Disponible sur AppStore et PlayStore.

Craftsmanship

Le TDD seul ne mène pas forcément à un bon design

Faire du TDD implique-t-il automatiquement qu’on fait du bon design ? Pas forcément. Et Sandro Mancuso lui-même a changé d’avis il n’y a pas si longtemps dans son article Does TDD really lead to good design?

Il y argumente que l’on devrait probablement enseigner comment designer avant (ou en même temps que) d’enseigner le TDD.

Pas mal de liens intéressants dans l’article, ainsi qu’un petit rappel des principales approches de bon design (« 4 Simples Règles de Design », SOLID et Domain Driven Design) et des deux approches du TDD (« Classique » ou école de Detroit, et « Outside-in » ou école de Londres/Mockist)

Merci à Alexandre Victoor pour m’avoir pointé vers l’article.

Front

Les différentes étapes d’une phase de Design pour un site responsive

Dissecting-Design

Smashing magazine a publié en début de semaine un article qui résume les différentes étapes pour designer un site responsive. On retiendra les techniques suivantes:

Back

Comparatif de la latence des files de messages

Un nouveau benchmark sur les files de messages me direz-vous  ? Oui mais celui-ci, intitulé « Benchmarking Message Queue Latency », se concentre sur ce qui se passe au delà du 99ème percentile et on y découvre des choses très intéressantes à propos des 4 files de messages testées (RabbitMQ, Kafka 0.8 et 0.9, Redis et NATS) :

  • En général tout se passe bien jusqu’au 99ème percentile, au-delà c’est parfois très différent
  • La différence entre Kafka 0.8 et 0.9 est ainsi impressionnante
  • RabbitMQ et Kafka 0.9 présente des latences très similaires
  • Autant pour les documents de faible taille (1KB) Redis et NATS se débrouillent bien mieux que RabbitMQ et Kafka autant pour les documents de 1MB la distribution n’est pas la même. On constate que Kafka offre de bien meilleures latences que NATS.

Comme bien souvent un benchmark n’est représentatif que d’une situation particulière et il faudra refaire les tests pour son environnement mais si la latence de vos files de message est important alors allez voir cet article !

Kafka Connect : construire des pipelines de données à faible latence

On reste toujours dans le domaine des files de messages avec l’annonce réalisée par la société Confluent de Kafka Connect.

Concrètement il s’agit d’un framework permettant la réalisation de connecteurs pour Kafka. Le but étant d’abstraire le développeur des problèmes classiques à résoudre lors de la création d’un connecteur pour Kafka : gestion des offsets, partitionnement, tolérance à la panne, monitoring etc.

construire des pipelines de données à faible latence

Pour le moment deux connecteurs sont officiellement disponibles (HDFS et JDBC) sur la page dédiée mais il est possible d’en trouver d’autres sur GitHub (par exemple pour Cassandra).

Stream Processing : quel outil choisir ?

Après avoir construit votre pipeline de données vous aurez probablement besoin de traiter les données au fur et à mesure de leur arrivée. Quoi de mieux que cela qu’un comparatif entre les outils de streaming processing ?

Il faudra aimer la fondation Apache par contre car les outils testés sont : Apache Samza, Apache Storm et Apache Spark (il ne manque qu’Apache Flink et la tribu aurait été complète).

Chaque outil est présenté et comme bien souvent il faudra choisir le bon outil pour la bonne tâche :

Outil comparatif de stream processing

IBM mise sur Swift en présentant Swift Package Catalog et Kitura

Depuis les accords commerciaux entre Apple et IBM, l’écosystème Swift a déjà bénéficié des premiers efforts de Big Blue sur le nouveau langage made in Cupertino. Apparemment, ce n’est pas fini : depuis quelques jours, les investissement de IBM dans la plateforme deviennent de plus en plus surprenants. En effet, le géant américain a récemment publié les résultats de deux initiatives Open-Source :

  • Swift Package Catalog : il s’agit d’un répertoire de projets Open-Source Swift qui s’intègre à la perfection avec Swift Package Manager et qui permet de trouver facilement les dépendances Open-Source pour nos projets Swift. Pour le moment, SPC se limite à indexer les projets OpenSource ajoutés à GitHub qui possèdent un fichier Package.swift.
  • Kitura : un framework Web pour construire des Web Services en Swift. Kitura apporte une DSL s’inspirant à express.js et permet de profiter pleinement du Grand Central Dispatch pour optimiser la gestion de la concurrence.

L’initiative de IBM nous confirme donc que c’est désormais le bon moment pour analyser plus concrètement les possibilités offertes par l’environnement lié à Swift.

Commentaire

0 réponses pour " Revue de Presse Xebia "

  1. Published by , Il y a 7 ans

    @Kafka Connect
    Ce serait intéressant de proposer pour Spring XD un module Kafka Connect de type Source. Pour l’instant, dans Spring XD, le seul connecteur continuous query qui fait du diff est un connecteur GemFire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.