28 Nov 2014

Dojo #11

Cette semaine, pour faciliter la logistique, nous avons préférer dérouler deux sujets différents sur les deux sites de Lille et Nanterre.

@Nanterre

Nous avons déroulé un sujet peu connu des participants : GameOfLife.

Technologies :

  • 1 groupe C#
  • 1 groupe Javascript
  • 1 groupe Java

Nous avons eu plusieurs méthodes de modélisation de la grille :

  • Une matrice contenant des booléens correspondants à l’état de la cellule (vivante ou morte)
  • Une matrice contenant une liste de cellule, chaque cellule étant représentée par ses coordonnées et son état.
  • Une liste d’objets cellule (une cellule est représentée par ses coordonnées dans la grille – X et Y) qui permet de stocker les cellules vivantes ; avec deux attributs permettant d’avoir la longueur et la largeur de la grille

Les questions se sont beaucoup portées sur les méthodes de test unitaire :

  • Est-ce que l’on teste l’état de la grille entière pour des inputs particuliers ?
  • Est-ce que l’on teste l’état d’une cellule unique pour un scénario donné ?

Les discussions autour de ces questions ont permis de mieux cerner le concept des tests unitaires pour certains et de découvrir pour d’autres.

@Lille

Un dojo un peu inhabituel dans lequel nous avons décidé de résoudre des challenges proposé par le site CodinGame.

Qu’est ce qu’un randori ?

Le mode randori pour un dojo consiste à n’avoir qu’une seule machine et 2 programmeurs actifs uniquement en même temps.
Les autres programmeurs durant le randori participent en prodiguant conseils et remarques.
Au bout de 7 minutes, le programmeur devant le clavier laisse sa place à un autre de l’assistance.
L’idée est que la résolution du problème se fait en communauté.
WP_20141119_13_23_13_Pro

Qu’est ce que CodinGame ?

CodingGame est un site de recrutement qui propose des challenges de code à résoudre. Nous allons juste tenter de résoudre les challenges à travers leur sympathique interface.
Ils fournissent un environnement de développement à travers une page web dans lequel on peut écrire du code et visualiser le résultat.
Ils fournissent aussi pour chaque challenge une série de tests sous forme graphique qui permettent de valider si le code que l’on a écrit fonctionne.
Cette forme de test à un avantage : les tests sont plutôt progressifs, vous proposant d’étoffer le code à produire étape après étape et de faire émerger une solution, mais il y a aussi un gros désavantage, le programmeur n’écrit pas les tests lui même et surtout il ne choisit pas la prochaine étape de test à écrire vu que c’est prémâché.
C’est vraiment un très gros désavantage dans la constitution d’un dojo ou l’on s’entraine à écrire beaucoup de code de test, cela est un peu compensé par le fait que les exercices sont visuellement plutôt réussi.
Nous l’avons pris comme une parenthèse amusante dans l’ensemble de nos dojos et cela était plutôt réussi.

Share