23 Conférence NCrafts 2015 - Blog Nexeo
.NET

Conférence NCrafts 2015

18 juin 2015

ncraft Lors de la conférence NCraft à laquelle nexdotnet s’est rendu les 21 et 22 mai en compagnie de Guillaume (qui a lui aussi posté son retour sur cette conférence), nous avons pu assister à de nombreuses conférences. Tout d’abord c’est dans une ambiance conviviale et avec environ 200 participants qu’a eu lieu cet événement. Voici quelques-unes des conférence auxquelles nous avons assisté « Continous delivery : the missing parts» animé par Paul Stack Comme le rappelle Paul l’intérêt du déploiement continu, c’est d’abord de ne compiler qu’un seul binaire (et non pas des différents en fonction des environnements) : ce principe déjà mentionné dans le manifeste agile est fondamental pour avoir un logiciel fiable. Bien sûr, le but est de déployer en production, et il est justement intéressant de savoir en combien de temps pourrait être déployée en production une modification minimale qui n’aurait impacté qu’une seule ligne de code. Dès lors que l’on augmente le nombre de déploiements alors l’intégration continue prend tout son sens. C’est ainsi que Netflix arrive à 10 déploiements par jour. Pour qu’un tel rythme puisse être tenu il faut aussi maintenir les outils. Et afin de pouvoir mesurer les gains de performance , il faut mettre en place des métriques et de l’automatisation, ainsi que de la gestion de la configuration. Le monitoring permet notamment de détecter plus rapidement lorsqu’un problème survient Afin de pouvoir déployer rapidement en toute situation, et surtout rapidement une infrastructure jetable (disposable infrastrure) est bien plus recommandée qu’une infrasture figée. En effet, le serveur peut être entièrement reconstruit à partir de zéro (c’est d’ailleurs le cas pour Netflix qui va jusqu’à automatiser la reconstruction arbitraire de pages et serveurs) « TDD autopsy » par Thomas Pierrain et Bruno Boucard Tout d’abord avant de développer un traitement, il est essentiel de savoir précisément ce que l’on va effectuer, et d’échanger avec d’autres. Concernant les tests unitaires la bonne habitude à prendre c’est de préfixer les noms des méthodes de test par le verbe should : cela permet de s’habituer à tester non pas des méthodes mais tester des comportements. Une méthode de test pourra donc s’appeler par exemple « ShouldApplyADiscount ».En nommant ainsi vos méthodes de tests, vous éviterez un gros ralentissement progressif causé par les tests. Voici l’ouvrage recommandé : Growing object oriented software, guided by tests     livre                 « Full time pair programming» animé par Houssam Fakih Houssam Fakih nous a fait un retour d’expérience sur 3 années de « pair programming » a plein temps . Cela n’est pas aussi trivial que que nous le pensons et les points principaux sont les suivants :

Comme le dit Kent Beck, le « pair programming » c’est gaspiller moins Ecrire du code à deux c’est aussi partager la responsabilité. Si l’on applique le principe du « TDD mantra » alors l’un écrit le test et l’autre le code qui permettra de faire passer ce test « Future de l’expérience utilisateur» animé par Vincent Guigui L’interface utilisateur doit trouver le juste milieu entre « facilité d’utilisation » et « précision ».Les utilisateurs préfèrent ne pas avoir à subir une courbe d’apprentissage pour prendre en main l’interface utilisateur. L’utilisateur ne doit pas devenir « esclave » de la machine. On peut utiliser la technologie pour transformer l’information en communication : cf la démo dans laquelle à partir d’un Kinect qui scanne la salle, le présentateur place ses meubles dans l’espace détecté. Dans le commerce les technologies immersives permettent de réduire la barrière avec la boutique Sa présentation est disponible ici : http://fr.slideshare.net/gcrao78 « Traitement de gros volumes de données» lors de la conférence « Sweet dreams are made of this » animéé par Yann Schwartz Le traitement de gros volumes de données peut aussi se faire sans Hadoop : mais cela nécessite une excellente connaissance des autres librairies que l’on souhaite adopter afin de pouvoir déterminer leurs lacunes ou dépendances. En effet quand la volumétrie est telle que ce sont près de 10 millions de messages par seconde, alors les problématiques suivantes peuvent se poser :

  When DDD meets documentation par Cyrille Martraire La documentation participe au transfert de connaissance. On pourrait même dire que le code est une documentation !Il existe des outils permettant de générer de la documentation à chaque compilation, directement à partir de métadonnées positionnées dans le code : l’outil tzatziki permet de générer des pdf. Il devient ainsi possible de générer un glossaire à jour des termes métiers manipulés par le traitement.

Ajouter un commentaire


Votre commentaire sera modifié par le site si besoin.

À lire également

Nexeo a accueilli un ‘Code Retreat’ dans ses bureaux le 16 janvier 2016. Beaucoup de passion, beaucoup…

Vous avez entendu parler de Visual Studio 2015 mais vous ne savez plus trop ce qu’il apporte…

Lors de la conférence NCraft à laquelle nexdotnet s’est rendu les 21 et 22 mai en compagnie…