Premier Coding Dojo à Nantes : Partie 2

Le jeudi 29 août dernier a eu lieu le premier Coding Dojo de l’agence Nantaise d’Ippon Technologies.

Après un premier retour d’expérience organisationnel voici nos retours sur les technologies utilisées.

Retour d’expérience technique

AngularJS

Après la présentation, les mécanismes de base d’AngularJS (route, contrôleur, vues, services) sont suffisamment assimilés pour arriver rapidement à un résultat. Résultat que l’on peut visualiser immédiatement sans rafraîchir le navigateur grâce au livereloading (Cf. Yeoman qui embarque le module “connect-livereload” pour Node).

La structuration du projet et la puissance des concepts exposés rassurent les développeurs back-end et surprennent les développeurs web habitués à l’effet spaghetti des projets Javascripts.

Techniquement le seul point sensible abordé à été la mise en place d’un système d’authentification.

Il faut en effet à la fois sécuriser l’affichage ainsi que l’accès aux services retournant des données.

On sent que cela n’a pas été prévu dès le départ dans le framework et une recherche de documentations et d’exemples vous renvoie une multitude d’implémentations différentes sans que l’on sache reconnaître une bonne pratique et un cas adapté.

Cela dit, après quelques recherches et tâtonnements, une intégration avec Spring Security nous a paru la solution la plus élégante avec un back-end Java et avec le module Node Passport avec un back-end Node.

Yeoman

L’utilisation de Yeoman a été plutôt transparente, Grunt et Bower n’ont pas été utilisés (excepté grunt server). Le générateur Angular de Yeoman n’a pas été abordé non plus.

Il nous a surtout permis d’avoir un projet starter kit structuré, ce qui est déjà bien en plus de la minification et du livereload.

Bootstrap & Compass

La partie présentation a été réduite à l’essentiel, seule une démonstration SASS / Compass a été effectuée lors du live coding.

Les cas d’utilisations rencontrés n’ont pas mis en évidence l’intérêt de l‘utilisation d’un pré compileur CSS, toutefois cela n’a pas été non plus un frein dans les développements.

MongoDB

Globalement le passage de fichiers statiques vers un vrai back-end avec MongoDB s’est correctement déroulé.

Les problèmes sont apparus quand il a fallu faire évoluer les schémas :

  1. Il est en effet perturbant pour quelqu’un d’habitué aux bases de données relationnelles d’assimiler le fait que la plupart des solutions NoSQL sont de type schemaless et que l’on peut donc tranquillement faire évoluer le modèle sans reprendre les données anciennes voire mélanger différentes classes dans une même collection (terme MongoDB).
  2. L’autre point perturbateur est la gestion des relations dans les bases NoSQL (la non gestion devrait-on dire), la bonne pratique étant de stocker l’ensemble de la grappe d’un objet au même niveau tant que les exigences de performances ne sont pas élevées et à condition d’abandonner les relations bi-directionnelles. Le point à retenir étant qu’il faut concevoir spécifiquement son modèle pour un stockage NoSQL (ou tout autre stockage de type clé/valeur) de manière spécifique et ne pas hésiter à dénormaliser.

En résumé rien d’exceptionnel, ces difficultés sont classiques lors des premiers projets NoSQL

Node

L’installation et la récupération des plugins nécessaires se sont faites sans soucis.

La modification du service exposant les données (d’un fichier statique vers MongoDB) a aussi été réalisée rapidement.

Le seul problème rencontré (et assez classique) concernait la mutualisation des connexions entre les différents services avec Mongoose (afin d’éviter que chaque service ne possède sa propre connexion).

Ce sujet est suffisamment documenté pour ne pas être un vrai problème bloquant.

Le fait de coder le back-end en javascript n’a pas été plus dérangeant que cela car nous pouvions encore nous appuyer sur des plugins existants stables et bien conçus.

Des développements plus poussés seraient évidemment différemment appréhendés par des novices.

Git

Clairement le point le plus décevant. C’est que nous avons passé un temps important à résoudre des problèmes de conflits ou à récupérer des modifications distantes.

Il ne faut absolument pas sous estimer le passage entre des gestionnaires de configuration comme SVN ou Mercurial vers Git. C’est une très bonne leçon pour nos futures expériences.

En réalité Git pourrait presque faire l’objet d’un Coding Dojo à lui seul !

Nos recommandations :

  • Si pas d’expert en support (ou en tout cas d’utilisateurs confirmés) : abandonner Git !
  • Une branche par User Story (ou sous-branche d’une branche principale si elles sont liées entre elles).
  • Le temps de merge (avec résolution des conflits) doit être pris en compte avant les démonstrations.

Editeur

En plus d’un changement radical dans les technologies, ce Coding Dojo a été l’occasion d’abandonner les IDE traditionnels comme Eclipse/Netbeans pour un IDE beaucoup plus light comme Sublime Text (ou autre).

Ce genre d’IDE est en effet beaucoup plus adapté à la pratique de Yeoman voire d’AngularJS avec les bons plugins.

Le résultat

Voici quelques copies d’écrans du résultat obtenu :

CodingDojo2
CodingDojo1

Consulter le Site web :

http://ippevents.herokuapp.com/#/

Consulter les sources :

https://github.com/ippontech/ippevents-services-node

https://github.com/ippontech/ippevents-front-node

Bilan

Comme dans tout Coding Dojo qui se respecte, un feedback a été demandé aux participants.

Voici la synthèse de leurs impressions :

Les plus

  • Découverte de nouvelles technologies dans l’air du temps (AngularJS, Node)
  • Puissance de Yeoman avec les modules qu’il embarque

Les moins

  • Authentification avec AngularJS.
  • Git sans guru sous la main.
  • Peut être trop de (nouvelles) technologies à appréhender d’un seul coup.

Enfin un dernier point qui n’apparaît pas dans les plus et les moins de la journée parce que pas du tout traité : favoriser les échanges techniques entre les binômes.

Les participants ont manqué de retours à chaud sur les technologies utilisées (forces/faiblesses), remarques et explications sur les implémentations des uns et des autres.

En effet les méthodes agiles sont l’apanage des échanges directs entre les membres d’une équipe et il est dommage de ne pas avoir su répondre à ce besoin.

En résumé une expérience enrichissante et qui sera renouvelée régulièrement chez Ippon Nantes.

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Laisser un commentaire

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


*