Coding Dojo à Grenoble

Posté par (page perso) . Modéré par Mouns.
Tags :
7
19
déc.
2008
Communauté
Dans le cadre du CARA, nous organisons un Coding Dojo à Grenoble.

Mais qu'est ce donc que cela ? Il s'agit d'un lieu d'entraînement (d'où le terme de dojo) pour pouvoir étudier, tester et apprendre des techniques et des langages de code. Finie la prise de risque sur un projet, venez vous entraîner dans un lieu sûr, sans risque, entouré des meilleurs professionnels de la région (c'est à dire vous ;o) ).

Attention il ne s'agit pas d'une formation "classique" avec un professeur et des élèves attentifs, ici tout le monde participe et tout le monde s'enrichit !
  • Vous rêvez d'apprendre Ruby sous Linux mais vous codez votre projet en C# ;
  • Si vous parlez de langage fonctionnel à votre chef de projet il va vous regarder avec des yeux comme des soucoupes ;
  • Si TDD vous évoque T'es Dans la Déprime sur un projet en cycle en V ;
  • Si vous voulez vivre des sensations eXtrem Programming.
Bref, si ces phrases vous interpellent c'est qu'il est temps de venir nous rejoindre. Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.

Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.
– LaurentBossavit

Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d’entraînement pour parfaire leurs techniques. Le principe d’un dojo de code est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d’un projet.

Le Pragmatic Programmer Dave Thomas a eu l’idée de proposer des 'kata’ de codes, à savoir des exercices simples permettant d’apprendre et de réviser des techniques de codage. Laurent Bossavit a ensuite étendu cela à des séances en groupe et c’est ainsi que sont nés les dojos de code.

On distingue deux types d'exercices :
  • Les katas : démonstration au tableau en partant de zéro ;
  • les randoris : des paires tournant toutes le 5 - 7 minutes et codant au tableau, l'assistance ne pouvant interrompre que pendant que les tests sont verts.

Ce n'est pas une coding party, c'est un entraînement et un partage de connaissances et de bonnes pratiques entre codeurs.
  • # Existent-il un projet OpenSource qui a été érit selon la méthode XP.

    Posté par . Évalué à 2.

    Je lisais le Wiki l'eXtreme Programming du Dojo de Paris.

    Connaissez vous un projet Open Source qui a su respecter la méthode XP de bout en bout et de manière strict ?
    • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

      Posté par . Évalué à 1.

      Ca veut dire quoi pour toi "projet open source" ?

      Car la définition "stricte", c'est l'utilisation d'une licence ratifiée par l'OSI.

      Mais la définition commune, c'est non seulement l'usage d'une licence OSI mais aussi d'un développement communautaire, le plus souvent à travers Internet.

      Dans ces conditions, je vois mal comment il est possible d'imposer de façon stricte une quelconque méthode de développement, et à fortiori une méthode agile. Les méthodes doivent correspondre déjà au processus communautaire (c'est-à-dire d'être d'hériter de la méthode plus large "développement communautaire", décrite notamment ici : http://en.wikipedia.org/wiki/Open_source_software_developmen(...) )

      Néanmoins, les méthodes agiles elles-mêmes sont le résultat plus ou moins formel de l'analyse top-down des méthodes de développement utilisées pour les logiciels libres, notamment de leur caractère itératif et incrémental, dans la fin des années 90. Par exemple le noyau Linux n'a pas de processus de développement étiqueté comme agile à ma connaissance, mais la méthode pourrait bien être qualifiée d'agile à mon avis.

      Si tu parles d'un logiciel libre développé in-house en suivant XP à la lettre, il doit en exister, mais il n'y a dans ce cas pas de relation avec le fait qu'il soit libre.

      Dans tous les cas, je ne suis pas convaincu par les intégristes d'XP ou de Scrum qui tiennent à suivre les procédures de façon stricte, même si l'objectif est louable, je pense plutôt qu'il faut comprendre l'essence et les fondements de ces méthodes, l'objectif qu'elles cherchent à atteindre en imposant des règles strictes, pour les adapter à l'environnement et au produit réalisé,
      • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

        Posté par (page perso) . Évalué à 2.

        Moi qui croyais que la spécificité de l'XP c'était justement qu'il n'y avait pas de méthode et qu'on fonçait tout droit... faut que je me remette à jour :D
        • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

          Posté par . Évalué à 1.

          Mhh? Je sais pas si c'est ironique, si les autres linuxfriens connaissent XP et les méthodes agiles, je sais pas pourquoi je suis moinssé... mais je développe en XP+Scrum, j'ai participé à quelques séminaires dessus, et oui: il y a des règles. XP est en soit une méthode agile, je ne parle pas de méthode au sein d'XP.

          Bref, je ne cherche pas à comprendre (pas plus que les moinsseurs je suppose :)).
      • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

        Posté par (page perso) . Évalué à 0.

        Moi je crois savoir pourquoi tu es moinsé. Tu fais transparaître beaucoup de préjugés à propos du libre :
        - C'est développé par un étudiant boutonneux dans son coin
        - Le libre ne sait pas s'organiser sérieusement
        - Une communauté ne sait pas imposer les bons choix
        • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

          Posté par . Évalué à 1.

          Là, je crois que c'est dans la tête de mes moinsseurs alors, car loin de moi cette idée. Le libre c'est un concept éthique et philosophique qui se transcrit dans un contexte juridique : la licence.

          Le modèle de développement, la qualité du code, et le reste des facteurs techniques n'ont strictement rien à voir avec la liberté logicielle.

          En revanche, le "modèle open source" sous entend généralement un développement communautaire, lequel même s'il est on ne peut plus sérieux (noyaux Linux, pile Apache, etc) ne permet pas de suivre des règles de méthodologies strictes. Tu peux pas faire là mélée quotidienne de Scrum dans un développement distant par exemple, ou alors ça devient difficile, surtout avec les faisceaux horaires différents.

          En règle générale, les méthodes agiles, notamment XP et Scrum, sont adaptées à des petits groupes de travail (7-12) "en chair et en os". Le développement d'un logiciel libre en suivant un modèle communautaire peut être décomposé en plusieurs équipes dont certaines utilisent les méthodes agiles indépendamment, en utilisant un backlog commun (trac, jira, ..), mais impossible pour le projet dans sa globalité de suivre à la lettre XP ou Scrum sans l'adapter auparavant.
        • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

          Posté par . Évalué à 2.

          Je crois que surtout que le verbiage à base de buzzwords, de sacro-saintes méthodologies accompagnées de leurs inséparables gourous et thuriféraires, de leurs schismes et de leurs querelles en religion (ainsi que d'une montagne de bouquins inutiles et redondants), les gens hors du monde merveilleux de l'entreprise s'en battent un peu le coquillard.

          Les gens n'ont pas attendu le "XP", le "Scrum" et je ne sais quoi d'autre pour faire des tests unitaires et procéder par itérations fréquentes ("release often, release early", ça vient pas d'un gourou du XP/Agile/Wooloomooloo).

          Maintenant si ça peut être une excuse pour s'amuser à coder sans vexer ses supérieurs, pourquoi pas.
          • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

            Posté par . Évalué à 1.

            J'espère que tu réalises qu'il s'agit d'une partie du génie logiciel que d'étudier les processus de développement et les formaliser.

            Au lieu d'y voir une religion, ou un affront à ceux qui font sans, tu devrais peut-être concevoir que c'est utile et que ça fait partie de l'informatique.

            C'est exactement comme le génie chimique, ou l'ingénierie des ponts, etc: c'est une étape obligée de l'évolution de l'ingénierie informatique. Une meilleure ingénierie informatique où la méthodologie fait partie intégrante des éléments abordés.

            En plus si tu crois que XP ou Scrum se limitent à des pratiques techniques (tests, itérations fréquentes), tu ferais bien de te renseigner :).

            Dans tous les cas, comme je l'ai dit les méthodes agiles sont plus ou moins la formalisation des procédés utilisés dans les gros projets libres, donc évidemment qu'il y a des relations; évidemment que la phrase de Linus s'applique à des processus qui descendent du modèle de développement que Linus à choisi...

            En ce qui concerne les "buzzwords", il faut appeler un chat un chat. Je suis sûr que dans certains milieux, on trouve que "logiciel libre" et/ou "open source" sont des buzzwords, pourtant ils ont une signification précise. Il en va de même pour Scrum, XP, Agile et le reste.

            Je ne suis pas surpris du rejet de ce genre de discussion sur LinuxFr puisque j'en suis venu à la conclusion que les informaticiens sont minoritaires ici.
            • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

              Posté par . Évalué à 3.

              C'est exactement comme le génie chimique, ou l'ingénierie des ponts, etc: c'est une étape obligée de l'évolution de l'ingénierie informatique.

              Justement, non, c'est pas comme. Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.

              (*) ce qui ne veut pas dire que ce soit fait n'importe comment...

              On pourrait rétorquer qu'avec XP/Scrum un logiciel comme le noyau Linux pourrait être écrit beaucoup plus vite, avec beaucoup moins de bugs ; j'attends la démonstration :-).

              Je suis sûr que dans certains milieux, on trouve que "logiciel libre" et/ou "open source" sont des buzzwords, pourtant ils ont une signification précise.

              L'appellation buzzword vise la façon dont un terme est utilisé, à savoir pour rameuter les foules et créer des « courants ». C'est indépendant de l'existence, ou non, d'une « signification précise ». Je me doute bien que tout cela a été codifié très précisément, d'autant plus précisément que cela donne l'illusion de la rigueur et permet de vendre des bouquins bien épais (et aussi d'expliquer, au type qui se plaindrait que pour lui ça ne marche pas, qu'il n'a probablement pas appliqué la méthodologie correctement).

              La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.

              j'en suis venu à la conclusion que les informaticiens sont minoritaires ici.

              Disons qu'à mon avis les gens parlent programmation au sein de leurs projets respectifs (pour ceux qui en font effectivement :-)).
              • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

                Posté par (page perso) . Évalué à 2.

                La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.
                La discipline est nécessaire dans un programme / projet complexe, je ne pense pas que le développement du noyau Linux soit si anarchique que ça. J'en veux pour preuve l'intégration de reiserfs4 (paix à son âme :o(( ) ou de zfs qui ont été refusés car ils ne respectaient pas les 'normes' de codage. Le code est relu avant d'être intégré (tiens une forme de pair-programming même si on est en mode distribué).
                Sinon concernant la notion de codification stricte et la vente de gros livres, ça existe sûrement mais c'est contraire à l'Agile où l'idée est de privilégier l'adaptation et le bout de la chaîne (l'équipe). La méthode est plus un certain nombre de règles que l'on pose pour travailler et réaliser un projet (quelque soit sa licence). Mais je suis bien d'accord il y a énormément de buzz autour de l'agilité, si ça fait progresser tout le monde tant mieux, de toute façon c'est inévitable. Il y aura toujours des parasites (ça existe même dans le libre, et là aussi ça me rend triste). Pour moi l'agilité c'est une 'philosphie', une manière de penser son projet, comme le libre.
                Le chef n'existe plus en tant que tel dans une équipe Agile puisque l'un des mots d'ordre est 'empowered the team' (donner le pouvoir à l'équipe). Je dirai même au contraire que le chef de projet classique a plutôt tendance à disparaitre dans une équipe agile (ce qui n'est pas sans créer une certaine résistance).
                Pour les bugs, désolé moi je me trompe souvent, je remanie mon code très souvent et j'essaye de suivre l'évolution des librairies que j'utilise. Je suis bien content d'avoir une batterie de tests qui m'assure 'automatiquement' que tout fonctionne toujours, plutôt que de devoir rejouer ça à la main où que mes utilisateurs le découvrent en étant bloqué avec mon logiciel en rade :o(. Ce n'est pas parfait mais ça aide et moi je ne veux plus coder sans, j'y gagne en temps et en stress en moins et en plaisir en plus :o).

                PS.: juste pour conclure, l'agilité était l'un des arguments qui a convaincu mon boss d'ouvrir notre logiciel en GPLv3 cette année ;o).
              • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

                Posté par (page perso) . Évalué à 2.


                Des logiciels complexes comme le noyau Linux ont été écrits sans la moindre méthodologie officielle (*), que ce soit Scrum, cycles-en-V, etc. Un programme, ça ne s'« ingénie » pas, ça ne s'usine pas : ça s'écrit.


                D'abord, le noyau Linux a été développé selon une méthode même si celle-ci est propre aux développeurs du noyau et surtout propre à l'approche personnelle de Linus. Méthode qui d'ailleurs s'est raffinée au fur et à mesure des développements. C'est exactement l'approche des méthodes agiles ; la méthode utilisée est une méthode agile.

                Ensuite, un programme s'écrit, certes, mais selon des techniques dites d'ingénierie, de la même façon que le projet dans lequel l'élaboration du programme se fait. Ainsi, par exemple, Scrum va t'aider en donnant des techniques dans la gestion de ton projet tandis que des approches comme XP ou TDD va te fournir des méthodes d'écriture de code te permettant d'atteindre une certaine qualité tout en maintenant une cohésion et une discipline d'équipe. De plus, afin de maintenir un code de qualité tout en maintenant une vélocité d'élaboration du programme, des outils comme l'intégration continue, les tests unitaires et d'intégration automatiques, des outils de contrôle de versions, le source control, etc. sont plus ou moins nécessaires et font partie ce que l'on appelle l'ingénierie logicielle.


                La seule vertu de telles méthodologies, c'est de créer une discipline (notamment en entreprise, où le chef voit son autorité légitimée par l'autorité extérieure de la méthodologie). Mais à ce compte elles se valent probablement toutes, et les querelles de clocher ou de génération sont sans importance.


                D'abord, le propre des méthodes agiles est l'auto-discipline et l'auto-organisation. Ce qui tranche en général des méthodes comme CMMi par exemple qui est malheureusement utilisée le plus souvent de la façon dont tu dis.
                Ensuite, s'il existe une multitude de méthodes dites agiles, et qui émergent en partie du monde du logiciel libre, certaines sont plus connues sous des noms bien précis comme Scrum, Crystal Clear, etc. Or ces dénominations sont importants parce qu'ils permettent de mieux diffuser la connaissance (ce qui ce cache derrière ce nom) et ils permettent aussi de pouvoir les "vendre" à tes manageurs dans une entreprise ... et ça c'est important ; d'où d'ailleurs le buzz autour.

                Derrière les méthodes agiles, je dirais que c'est une sorte de retour du contrôle des développeurs dans la façon dont s'écrivent les programmes, face à un raz bol de toujours payer les pots cassés du fait des décideurs ou manageurs qui n'ont de connaissance du développement logiciel que leur prétention d'y connaitre.
      • [^] # Re: Existent-il un projet OpenSource qui a été érit selon la méthode

        Posté par . Évalué à 2.

        Juste pour répondre avec beaucoup de retard à ce thread mort ^^.

        Vu que le code a une odeur. Une programme écrit via une méthode agile doit avoir une forte :).

        Ce qui m'intéresse aussi est de voir les tests qui sont écrit pour répondre à ce code. Le Framework utilisait pour exploiter ces tests.
        Par exemple faire du XP avec juste lib C Standart, çà doit pas être bien interessant où alors il faut écrire ce framework.

        Les changelog du CVS doive être interessant aussi.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.