Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Alain April
    @aapril
    est-ce que c'est ici que tous les étuidiants vont venir discuter pour le Plink de MGL804?
    David Lauzon
    @davidonlaptop
    oui
    on a aussi un chat room pour adamcloud (pour Julien)
    francois-boyer
    @francois-boyer

    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

    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
    @francois-boyer : est-ce que je dois lire entre les lignes ? :-p
    karim73
    @karim73
    D'Accord sur le plan d'actions.
    karim73
    @karim73
    1- faudrait p-e mettre en place un plan controle/qualité pour s'assurer que la premiere phase (debugage du code plink pour identifier/comprendre les algos de chaque foncitionnalité) soit bien reussi, car on n'est pas nombreux a etre a l'aise avec le C/C++
    singemanator
    @singemanator
    Salut, concernant le plan à adopter, je suis plus de l'avis de Khaled. La complexité de chaque fonctionnalité ne sont pas égales. Donc, il serait plus efficace que l'équipe soit divisé en sous-équipe de 4 personnes où chaque équipe s'occupera de migrer 2 fonctionnalités. De plus, la planification des rencontres avec l'ensemble des membres de chaque sous-équipe va être plus facile. @karim73 qu'est ce que tu proposerais comme plan de contrôle/qualité? Et tu es d'accord sur quel plan d'action exactement?
    karim73
    @karim73
    j'ai pas eu le temps d'enumérer le reste des points :
    1) Concernant les inputs a utiliser pour les tests, chaque team pourrait utiliser les outputs generés par plink.
    2) a mon avis, il faudrait composer les teams par skills. Premiere etape importante est de debuger le code source plink pour extraire les fonctionnalités a implementer en scala. Assigner cette tache a quelqu'un qui a peu de connaissance en C/C++ n'est pas productif et on risque d'obtenir des spec de faible qualité ( d'où la mise en place d'une procedure de controle/qualité).
    3) que pensez vous de mettre en place un wiki scala, et un autre spark, pour qu'on partage ce qu'on a appris.
    4) Reste que le premier step primordial est de pouvoir compiler/executer ploink 1.9, moi personnellement j'Ai encore de la misere sur mon ubuntu 12.04 et mon mac yosemite
    singemanator
    @singemanator
    Je suis d'accord avec ce que tu proposes @karim73 . J'ai envoyé un message à l'un des co-développeur de Plink. Il m'a dit qu'il n'utilisait pas d'IDE mais plutôt Emacs pour l'édition. Et pour débugger, il utilisait des "printf". Il m'a aussi dit que c'est tout ce que j'avais besoin pour un outil en ligne de commande comme Plink...
    Aboubakary
    @Aboubakary
    Salut; je me joins à la proposition de faire plutôt deux équipes au lieu de quatre. Tout comme Karim73 l'a dit, le premier pas nécessaire pour avancer, qu'est la compilation n'est pas franchi. C'est après ce niveau que la division en deux équipes sera pertinente.
    ikizema
    @ikizema
    Excellente initiative @singemanator pour l’échange avec les développeurs de Plink. Avec ces infos, je suis encore moins certains de pouvoir utiliser un beau outil de debug comme ce que nous essayions de faire la semaine dernière.
    ikizema
    @ikizema

    Pour la stratégie organisationnelle à prendre, je suis un peu plus partagé. En effet, chaque des stratégies a ses avantages et ses inconvénients. Nous sommes pas suffisamment avancées pour déterminer las stratégie pour l'ensemble du projet. Je propose avancer par les petits pats sur les livrables v0.1.

    Avant tout, l'avancement actuel est le suivant pour les livrables v0.1 :
    I. Getting started Done (reste à compléter la tache dans waffle)
    II. Recette pour compiler plink Done pour Ubuntu 12.04
    To do pour Mac
    III. Implementation –make-bed To do
    IV. Implementation --genome Part1 To do
    V. Command-line (CLI) option parser for Scala To do
    VI . Use a dependency manager to build the project Done Initialisation of Maven project

    Rq : la tache VI était initialement dans v0.2, j'ai pris l'initiative de la mettre en v0.1 car la mise en place d'un projet de travail avec l'organisation de la gestion des descendances me semblait nécessaire pour les taches III et IV. Bien entendu, le projet est initié mais ne comporte pas encore l’ensemble des dépendances qui seront importés au fur et à mesure de l’avancement.

    Les mini taches :
    Tache I – Gestion de projet, reste à mettre en forme les commentaires de la tache sur ce qui a été decidé ou en cours de decision.
    Tache II – Protocoliser l'utilisation des outils pour compilation de plink sous Mac.

    On est 8, je prose de vous repartir sur les taches plus complexes à réaliser (j'estime la difficulté en mettant plus ou moins de personnes à la tache) :
    Tache III – équipe A de 3 personnes
    Tache IV – équipe B de 3 personnes
    Tache V – équipe C de 2 personnes (pour ceux qui ne souhaitent pas faire C/C++ pour le moment)

    Que pensez vous de cette démarche ? Si vous êtes OK, je vous propose de vous repartir en s’assignant la tache dans waffle en respectant les limites des groupes. Je me mets dans l'équipe A pour initier le mouvement.

    Voilà, dites moi si cela vous semble correct pour commencer.

    Ivan

    David Lauzon
    @davidonlaptop
    PVI. Vous pouvez linker les issues GitHub avec le préfixe dièse: #3, #4, #5
    ce qui permet un mouseover sur les issues
    sfcwallace
    @sfcwallace

    Salut, j'ai essayé avec pas mal de IDEs pour le debug (avec gdb) mais je n'ai pas réussi à le faire. En contactant le développeur qui fait la version 1.9 de plink il a confirmé à Karen qu'il se contente de mettre des printf() dans le code. Ce n'est pas du tout efficace mais quand on n'a pas le choix on fait avec.

    Pour le partage des équipes je suis de avis @ikizema pour démarrer l'implémentation.

    Je souhaite être dans l'équipe B

    singemanator
    @singemanator
    Salut, je vais faire la "recette" pour compiler Plink sur Mac. Et je vais me mettre dans l'équipe C.
    Alain April
    @aapril
    est-ce que les autres membres, qui n'ont pas encore communiqué, peuvent nous dire ou ils vont s'impliquer activement?
    Aboubakary
    @Aboubakary
    Salut, je dirais B
    karim73
    @karim73
    @ikizema , le depot plink1-9 contient deja un executable fonctionnel ( donc pas besoin de compiler).
    ikizema
    @ikizema
    @karim73, selon moi, pour faire l'exercice de rétro-ingénierie de PLINK, l'objectif n'est pas uniquement utiliser l’exécutable mais bien comprendre le code source et la manière dont il est compilé. Mais je peux me tromper...
    Update pour la tache #2 :
    La tache est presque terminé, reste 1 point semi-bloquant exprimé dans la tache. Si quelqu’un a la réponse, n'hésitez pas à mettre à jour l'info.
    francois-boyer
    @francois-boyer
    Moi je serai dans l'équipe C.
    sfcwallace
    @sfcwallace
    @karim73 en fait si on souhaite comprendre comment fonctionne le code pour les fonctionnalités à migrer le fait de pouvoir compiler le programme peut nous aider. Le développeur utilise des printf pour faire le "debug". Donc oui pouvoir le compiler pourra aider à comprendre le code source si tu souhaite modifier le code
    singemanator
    @singemanator
    @francois-boyer j'ai crée 4 sous-tâhes pour faire le parser de commande. Les 3 premières peuvent se faire en parallèle. La dernière sous-tâche est celle de l'implémentation. Regardes ce que tu voudrais faire.
    ikizema
    @ikizema
    Bonjour, j'ai ajouté différents espaces de communication pour organiser un peu nos échanges. Les noms sont évocateurs : Administratif (toute communication touchant l'organisation, espace de travail...), DataFormat (pour ce qui est de format de donnés) et Fonction--genome (pour tout ce qui concerne la fonction --genome lol). @francois-boyer, sauf erreur, on est en attente de ton acceptation sur github, as-tu bien reçu l'invitation ? N’hésite pas en cas de problème.
    singemanator
    @singemanator
    excellent. Je vais crée un autre forum pour le parser CLI
    karim73
    @karim73
    maintenant on a un chat room par activité/tâche ?
    ikizema
    @ikizema
    @karim73, pas par tache mais par famille de taches. Cela permettra de communiquer plus clairement sans mélanger les sujets. Une question administrative -> Administration, question concernant le format de donnes -> DataFormat...