These are chat archives for GELOG/adam-ibs

21st
May 2015
francois-boyer
@francois-boyer
May 21 2015 16:57

Bonjour à tous,

Je souhaitais mettre sur "papier" la stratégie d'attaque qui a été choisie hier soir pendant le cours. La première étape est de créé deux procédures (une pour Linux et une pour Mac) qui vont démontrer les étapes exactes que nous devons réaliser pour downloader/installer/compiler et être en mesure de faire des brakes-points dans le code de PLink afin d'être en mesure de tracer le code et débuter nos démarches de compréhension de ce que PLink mange en hiver. Ivan s'est porté volontaire pour la procédure Linux et Karen s'est proposée pour la version MAC. Nous devrions tous ensuite être en mesure d'attaquer le projet avec un peu plus d'assurance.

Ceci dit, voici comment on voyait la suite des choses:

  1. Il y principalement 4 fonctionnalités à migrer soit:
    1.1 Lire les fichiers textes
    1.2 Créer la matrice de paires IBS
    1.3 Analyses des données IBS Clustering
    1.4 Analyses des données MDS et représentation graphique
  1. On aimerait créer 4 petits groupes au sein du main groupe (Ci après nommé "team"). L'idée est de créer des teams de travail "indépendant" les uns des autres pour être en mesure d'optimiser les temps dont nous disposons et de travailler parallèlement. En gros, ça se résume à dire que chaque team attend quelque chose en entré d'un autre team et qu'il doit fournir en sorti quelque chose à l'autre team (chaque team devra créer son module dans une branche distincte de GIT). Le temps que chaque team reçoive ce qu'il attend en entré, nous n'auront qu'à "hard-codé" ce que chacun attend.

2.1 Chacun des teams doit premièrement s'attaquer à la compréhension de ce que PLink effectue présentement pour sa fonctionnalité (tracer le code exécuter par break-points).

2.2 Il faut ensuite "documenter" notre compréhension dans le WIKI pour transmettre aux autres teams ce que nos recherches nous auront permis de comprendre

2.3 Quand chaque team aura bien saisie le travail à faire, on se fera une session de travail intense et on s'arrangera pour discuter des entrés et sorties que chaque team attend et doit remettre (dans 2 semaines max).

2.4 Chaque team s'affèrera alors à convertir leur fonctionnalité en Scala. Il est important de noter que si un team termine sa partie avant les autres que les membres du team seront dissous dans d'autres teams pour aider les autres dans leur tâches. Donc plus on avancera, plus nos efforts ce concentreront sur ce qui est plus difficile.

2.5 Aussi, il sera important de ne pas trop attendre à la fin pour joindre ensemble le travail de chacun des teams pour s'éviter des "oups" désagréables. L'idée de travailler par team n'est pas de couper les ponts de communications... il faudra rester proche les uns des autres. Si jamais vous trouvez que c'est pertinent, on pourrait même élire un TeamLead par team qui lui coordonnera avec les autres TeamLead (je ne croirais pas que ce soit nécessaire... mais je propose au cas).

  1. N'oubliez pas que nous avons de super clients. David par exemple (oui david je sais que tu lis) est super motivé et semble vraiment disponible et enclin à nous donner un sacré coup de main. Comme il le disais, si jamais vous avez des questions à lui transmettre, envoyez-les moi et je réunirai les questions de tous pour les lui envoyer une ou deux fois par semaines.

Note: Je sais que certain voit ce projet comme une énorme montagne. C'est vrai... je pense pareil... mais sérieusement attaquons le projet étape par étape et ça s'éclaircira peu à peu. Et rappelez-vous que quand un développeur sait programmer dans au moins un langage, il faut apprendre n'importe lequel.

Voilà. Est-ce que ce plan vous convient!?

Moi je me propose de travailler sur la lecture des fichiers textes et de la persistance des données à l'aide de ADAM et Parquet. Et vous?

sfcwallace
@sfcwallace
May 21 2015 17:56

Salut,
je suis d'accord pour l'idée de se diviser en équipes afin de faire toutes les fonctionnalités.
Par contre je ne pense pas que de se diviser en 4 équipes de 2 soit pertinent qu'on voit que la complexité varie d'une fonctionnalité à une autre. David et Béatriz ont confirmé hier que c'est surtout les fonctionnalités 1.2 et 1.3 qui sont pas mal les plus complexes implémenter.
De ce fait je propose que:

  • une équipe de 4 personnes travaille sur les fonctionnalités 1.1 et 1.2
  • une deuxième équipe de 4 personnes travaille sur les fonctionnalités 1.3 et 1.4

Par ailleurs je suis d'accord pour avoir un team leader par équipe pour assurer la communication et l'intégration de toutes les fonctionnalités à implémenter.

À part ça je n'ai pas de commentaire sur le reste du plan.

David Lauzon
@davidonlaptop
May 21 2015 20:09
@francois-boyer : est-ce que je dois lire entre les lignes ? :-p