Le retour de la Méthode R.A.C.H.E

Posté par  (site web personnel) . Édité par Nils Ratusznik et Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
67
13
jan.
2016
Humour

Il y a plus de 10 ans maintenant, en lisant le journal d'un certain mmh, je découvrais la Méthode R.A.C.H.E de l’International Institute of La RACHE. Il ne s'est pas passé une année depuis sans qu'un collègue ou moi-même y fasse allusion face à un projet à l'issue incertaine. Malheureusement, le domaine n'a pas été renouvelé en 2013 par le propriétaire, et un site parking plein de liens moisis y a pris place.

Malgré la déception, j'ai finalement réussi à racheter le domaine et à le remettre en route…

Le site actuel

Le site est maintenant hébergé sur une page GitHub, peut être forké et est ouvert à toutes les contributions.

Le but de cette réouverture est de faire perdurer cette note d'humour et de continuer à rire des métiers de l'informatique.

Je n'ai aucune idée de l’identité de l'auteur originel de cette page ni de la licence qu'il aurait souhaité pour ce contenu.

Le contenu déposé sur GitHub est par défaut sous licence CC-BY-4.0.

Contribuer au site web la-rache.com

Installation de l'environnement de travail

  • forkez le projet : https://github.com/la-rache/la-rache.com ;
  • clonez votre fork : git clone https://github.com/<votre_user_github>/la-rache.com.git ;
  • allez dans le répertoire de travail : cd la-rache.com ;
  • installez NPM apt-get install npm ;
  • installez les dépendances : npm install.

Modification des sources

  • éditez le début de page et le pied de page dans src/parts ;
  • éditez les corps des pages dans src/*.html ;
  • éditez les images dans src/img ;
  • éditez les css dans src/css ;
  • éditez les js dans src/js.

Génération du code HTML

  • ./node_modules/grunt-cli/bin/grunt.

Visualisation du code

  • Ouvrez build/index.html avec votre navigateur préféré.

Partage de vos modifications

  • si vous avez ajouté de nouveaux fichiers : git add <fichier> ;
  • commentez vos modifications : git commit -am "<votre commentaire sur vos modifications" ;
  • poussez les dans votre repo git push ;
  • depuis votre espace GitHub, faites un merge request.

Aller plus loin

  • # license

    Posté par  (site web personnel) . Évalué à 5.

    D'après la FAQ du site je dirais domaine public. De rien ;)

  • # Enfin, des moules qui se sortent les doigts …

    Posté par  (site web personnel) . Évalué à 10.

    Merci !

    • [^] # Re: Enfin, des moules qui se sortent les doigts …

      Posté par  . Évalué à 10.

      ouais, enfin , faire un site avec autant de methode pour promouvoir la R.A.C.H.E je trouve que c'est un peu dévoyer l'esprit du concept.Il aurait fallu reprendre ça dans frontpage(ou au pire l'éditeur html d'openoffice) et publier les sources dans un .rar

      ps: ce mommentaire a été écrit à la rache

      « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

  • # nodejs

    Posté par  . Évalué à 1.

    Sur mon système (dernière Debian) il faut remplacer node par nodejs dans le fichier node_modules/grunt-cli/bin/grunt

    • [^] # Re: nodejs

      Posté par  (site web personnel) . Évalué à 5.

      Ou : sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10

      http://la-rache.com

  • # saimal.fr

    Posté par  . Évalué à 8.

    nous manque aussi !

    • [^] # Re: saimal.fr

      Posté par  (Mastodon) . Évalué à 4.

      Il est à moi celui-là, et ça fait longtemps que j'ai envie de le relancer, mais le temps qui passe, la flemme, toussa… et pouf, on en est là !

      • [^] # Re: saimal.fr

        Posté par  . Évalué à 4.

        http://la-flemme.saimal.fr

        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

        • [^] # Re: saimal.fr

          Posté par  . Évalué à 2.

          punycode(Firefox ne peut trouver le serveur à l'adresse la-flemme.saimal.fr.).saimal.fr

          PS: ce commentaire ayant été conçu à la RACHE extension flemme, le lecteur est invité à calculer le résultat de la fonction punycode lui même.

  • # Architecture du site

    Posté par  . Évalué à 10.

    Je suis étonné qu'un site statique constitué avec la méthode la RACHE se contente de node.js. Je m'attendais à du J2EE avec moultes bibliothèques tierce partie pour mettre en place l'indispensable architecture n-tiers, l'ORM multi-tenants, l'inversion de contrôle et les stratégies d'usines de visiteurs de gestionnaires abstraits d'orchestrateurs répartis d'écriture de fichier HTML.

  • # Excellent!

    Posté par  . Évalué à 4.

    Je l'avais oubliée celle là ^^ Merci pour l'initiative et les barres de rire!

  • # Méthode testée et approuvée

    Posté par  (site web personnel) . Évalué à 10.

    Après être passé par la programmation agile avec des stands up meeting et une intégration continue, je dois avouer que j'étais un peu réticent à passer à la méthode R.A.C.H.E. Mais le site web m'a convaincu et j'ai été agréablement surpris. Depuis mes projets sont livrés en avance et j'ai même du temps libre pour évaluer le million de frameworks Javascript, bien qu'une migration à Perl 6 ait sûrement plus de sens en 2016.

    Par contre, un ami m'a très bien vendu une autre méthode qui semble autrement plus efficace https://www.youtube.com/watch?v=p8oi6M4z_e0 (*) ! Quelqu'un a testé et pourrait me faire des retours ? J'ai un peu peur pour l'état de mon clavier, mais ce détail mis à part, c'est assez bluffant. Tiens, je vais retourner voir la vidéo du tutoriel d'ailleurs, au cas où j'aurai loupé des détails sur la mise en place.

    (*) La méthode « Je code avec le cul, lalalalalère. Si ça bugue ou plante, j'men fous ! On m'paye pas pour tester ! Je code avec le cul, lalalalalère. Même si le programme marche pas, tu s'ras pas remboursé ! ».

    • [^] # Re: Méthode testée et approuvée

      Posté par  . Évalué à 10.

      Par contre, un ami m'a très bien vendu une autre méthode qui semble autrement plus efficace

      J'approuve. En suivant cette méthode, tu auras peut-être la chance d'être courtisé par un fournisseur de cloud souverain.

    • [^] # Re: Méthode testée et approuvée = les 2 ?

      Posté par  . Évalué à 10. Dernière modification le 14 janvier 2016 à 11:02.

      Je suis depuis quelques temps dans une société qui, à ma grande surprise, m'a fait découvrir un hybride méconnu : faire de l'Agile/Scrum pour finalement terminer à la RACHE. Avec tous les plaisirs des retours client interrompant pendant une tache déjà prioritaire ou bien la doc par transmission orale, je me suis posé cette question existentielle :

      Suis je en présence d'une espèce nouvelle de méthode ?

      Tel l'Indiana Jones des open-space, je me suis frotté mon menton mal rasé tout en me projetant vers un avenir radieux. Car si la réponse est "oui", cela m'ouvrirait des horizons insoupçonnables :je pourrais breveter cette méthode nouvelle, la ScRACHEum qui pourrait être un truc hype over-cool. Je me vois bien parcourir le monde pour prodiguer la bonne parole au travers de formations certifiées ScRACHEum dont le principe principal serait le suivant:

      pendant la réunion de 1h30 quotidienne chacun des intervenants utiliserait un Occulus Rift (c'est hype j'ai dit) pour placer ses post-it sur le tableau virtuel des backlogs pour qu'ensuite le Rache-Master puisse les recopier dans un cahier et garder les taches pour lui.

    • [^] # Re: Méthode testée et approuvée

      Posté par  (site web personnel) . Évalué à 4.

      Tiens, je vais retourner voir la vidéo du tutoriel d'ailleurs, au cas où j'aurai loupé des détails sur la mise en place.

      Ce n'est pas forcément facile pout tout le monde d'avoir autant de barbe!

  • # Agile ? la RACHE !

    Posté par  . Évalué à 10. Dernière modification le 13 janvier 2016 à 23:33.

    En fin de compte, la méthode "Agile" n'est juste qu'une remise au goût du jour (certains diront : une resucée) de la méthode R.A.C.H.E, qui avait déjà en son temps tout inventé et fait ses preuves : on spécifie sur des post-it, mais on les colle sur un "paper-board", c'est plus classe, et plus riche à cause des couleurs, on développe "agile", c'est à dire vite-fait (mal fait), c'est pas grave si c'est mauvais, c'est juste pour montrer à l'utilisateur, en même temps, on débeugue, et avant que ça soit fini, on met en prod, fièrement, parce que ça a été vite ! Et là je dis c'est 100% conforme à la RACHE !

    • [^] # Re: Agile ? la RACHE !

      Posté par  (site web personnel) . Évalué à 6.

      avant que ça soit fini, on met en prod, fièrement, parce que ça a été vite

      mettre idéalement en prod' un vendredi de préférence ou tout jour se terminant en 'dredi !

  • # Contribuer au projet sans GitHub

    Posté par  (site web personnel) . Évalué à 10.

    Git n'étant pas GitHub, je rappelle qu'il est tout à fait possible de proposer des modifications, sous la forme de demande de pull, sans passer par là. Il faut :

    1. cloner le projet quelque part ;
    2. faire ses modifications, les commiter ;
    3. publier son dépôt quelque part, disons git://git.example.com/la-rache.com ;
    4. contacter — par courrier électronique, par messagerie instantanée, par SMS, peu importe — le responsable du dépôt principal pour lui suggérer de faire un git pull git://git.example.com/la-rache.com master.

    GitHub n'ont inventé ni Git, ni la demande de pull.

    • [^] # Re: Contribuer au projet sans GitHub

      Posté par  . Évalué à 10.

      Ta méthode est beaucoup trop structurée (4 étapes, c'est 3 de trop) pour être compatible avec La Rache. Je n'approuve pas.

      • [^] # Re: Contribuer au projet sans GitHub

        Posté par  . Évalué à 10.

        Alors qu'une demande du type « J'ai pas eu le temps de créer un compte sur github, je peux envoyer mes patch par email ? » aurait probablement toutes ses chances non ?

        • [^] # Re: Contribuer au projet sans GitHub

          Posté par  . Évalué à 7.

          Un "patch", comme le nom l'indique ("rustine" en anglais), c'est beaucoup trop fragile pour être utilisé en environnement de production industriel. Il vaut mieux zipper l'arbre de sources et l'envoyer sur un serveur FTP où le destinataire peut le récupérer à sa guise. Ou, à la limite, intégrer le texte du fichier modifié dans un format pérenne comme PDF, ce qui permet par exemple de l'adjoindre à un compte-rendu de réunion ou à une TODO-liste écrite par un commercial.

    • [^] # Re: Contribuer au projet sans GitHub

      Posté par  . Évalué à 4.

      Pour des modifs pas trop volumineuses, on peut aussi simplement envoyer un patch par e-mail, même pas besoin d’avoir son propre dépôt public qelque part.

      Malheureusement il y a des développeurs « responsables du dépôt principal » qui ne connaissent rien d’autre que GitHub et ne savent rien faire en-dehors…

      J’ai déjà envoyé des patchs simplissimes (genre une ligne) à un développeur upstream qui, au lieu de les appliquer directement sur son dépôt, les a importé sur GitHub pour pouvoir créer des « Pull requests » et immédiatement les merger via l’interface de GitHub…

      (Non pas que ça me dérange outre mesure, après tout c’est le développeur upstream qui à mon avis se complique inutilement la tâche, pas moi… et à vrai dire je préfère ça plutôt qu’il me renvoie mon patch en me demandant de faire moi-même la pull request sur GitHub.)

    • [^] # Re: Contribuer au projet sans GitHub

      Posté par  . Évalué à 10.

      GitHub n'ont inventé ni Git, ni la demande de pull.

      Anéfé c'est emmaüs qui a inventé la demande de pull.

      *splash!*

    • [^] # Re: Contribuer au projet sans GitHub

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      contacter le responsable du dépôt principal pour lui suggérer de faire un git pull

      Si le responsable du dépot est inconcient ou te fait hyper confiance, pourquoi pas.

      Mais un responsable vraiment responsable, va

      1. d'abord cloner ton dépot
      2. faire une review et commenter
      3. faire ensuite le pull

      Au mieux, pour le responsable, ça lui fait faire donc 3 manips. Au pire Nx2+1 manips quand il demande N fois de corriger des choses. Et encore, la review peut être pénible quand on veut un diff globale entre deux branches (car là il faut créer un remote qui pointe vers le dépôt contributeur, puller la branche en question dans une branche spécifique etc… ça en fait des manip…)

      Alors qu'avec github, il n'en a au pire que N+1 :

      1. faire une review et commenter
      2. cliquer sur un bouton

      Sans pour autant que toi, en tant que contributeur, cela te demande plus de manipulation. Au contraire : tu n'as pas à chercher par quel moyen de communication tu dois lui envoyer un patch.

      Franchement, je préfère largement que les contributeurs passent par github, plutôt que de m'envoyer des patchs par mail ou me donner l'url de leur dépôt. Quand j'ai régulièrement des contributions, je gagne du temps à faire les reviews et les merge.

      À moins qu'il y ait des fonctionnalités dans git que je ne soupçonne pas, qui permettrait de faire les reviews et les merges de dépots distants en une seule commande…

      • [^] # Re: Contribuer au projet sans GitHub

        Posté par  (site web personnel) . Évalué à 6.

        À moins qu'il y ait des fonctionnalités dans git que je ne soupçonne pas, qui permettrait de faire les reviews et les merges de dépots distants en une seule commande…

        En une seule commande, non, mais clairement, il y a plus simple que ton procédé en trois étapes. Déjà, il est inutile de cloner tout le dépôt du contributeur, on peut tout à fait rester dans son dépôt de travail et récupérer seulement la branche qu'il propose. Ensuite, pour cela on n'a même pas besoin de créer pour cela une nouvelle branche nommée, on peut faire un git fetch anonyme, et Git le met dans FETCH_HEAD, qu'on peut ensuite utiliser pour examiner tout ce qu'on veut.

        Ça va donc ressembler à ça :

        git fetch git://git.example.com/la-rache.com master
git log -p FETCH_HEAD
git merge FETCH_HEAD

        Le git log peut être remplacé par un examen avec l'outil que vous voudrez, par exemple gitg FETCH_HEAD.

        Ça fait toujours trois étapes en effet :

        1. récupérer la branche proposée ;
        2. l'examiner ;
        3. l'intégrer.

        Mais ces trois étapes sont tout à fait comparables aux trois étapes nécessaires avec GitHub, en tenant compte de celle que tu avais oubliée :

        1. cliquer sur un bouton pour aller voir la branche proposée ;
        2. l'examiner et commenter ;
        3. cliquer sur un bouton pour l'intégrer.

      • [^] # Re: Contribuer au projet sans GitHub

        Posté par  (site web personnel) . Évalué à 1.

        Quand le patch fait 2 lignes de HTML, le consulter et l'accepter via son smartphone ne tuera personne …

        http://la-rache.com

        • [^] # Re: Contribuer au projet sans GitHub

          Posté par  . Évalué à 10.

          On laisse en exercice au lecteur la rédaction d'un patch de deux lignes de HTML capable de tuer quelqu'un. C'est niveau débutant.

      • [^] # Re: Contribuer au projet sans GitHub

        Posté par  . Évalué à 3.

        d'abord cloner ton dépot
        faire une review et commenter
        faire ensuite le pull

        ???? Vraiment, les utilisateurs de Github font tout en ligne et n’ont jamais de dépôt local ? Du coup, pour Git c’est GitHub, et pour Vim c’est GoogleDocs ?

        Parce-que sinon, le développer il fait comme pour le reste de son code, un « fetch » dans une nouvelle branche et il a tout sous la main dans son dépôt git. Du coup, c’est le même endroit pour la relecture, le « merge », le « push », même un éventuel « rebase » s’il a du code pas encore partagé qui est impacté et qui bénéficie de la modif, etc…

    • [^] # Re: Contribuer au projet sans GitHub

      Posté par  (site web personnel) . Évalué à 6.

      Sinon, pour contribuer à la rache sans github en suivant la méthode R.A.C.H.E, tu fais "clic droit" -> "enregistrer la page sous". Tu l'ouvre avec Word, tu modifies le contenu à changer (genre une faute d'orthographe), tu sauvegardes, puis tu envoies la nouvelle page HTML au webmaster par email.

      Par contre faut faire vite avant que quelqu'un d'autre ne contribue entre le moment ou tu récupère la page et l'envoi du résultat, sinon le merge sera difficile. Enfin bon, ce sera le problème du webmaster :-)

  • # merci

    Posté par  . Évalué à 3.

    Merci d'avoir redonné vie au site !

  • # G.E.N.I.A.L.

    Posté par  (site web personnel) . Évalué à 5.

    j'avais découvert ce site pendant mes études, quelle tristesse quand j'ai voulu le montrer à mes collègues pour un projet de sys admin qui partait en live, quand j'ai vu que le site était down en 2014.

    :D

    • [^] # Re: G.E.N.I.A.L.

      Posté par  (site web personnel) . Évalué à 2.

      tu as web archive pour cela :-)

      il est malencontreusement filtré dans pas mal d'entreprises ayant un proxy filtrant et empêchant la catégorie "proxy" de bluecoat :/ Reste à faire comme tout le monde et utiliser son ordiphone pour cela :-) (même si ce n'est pas Internet le plus souvent, ça passe un peu mieux).

Suivre le flux des commentaires

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