Le langage Ruby

a marqué ce sujet comme résolu.

Salut !

Tout d'abord, je te souhaite bon courage, et j'espère ce tutoriel aboutira, contrairement aux nombreuses beta du sdz ^^

Je vais essayer de donner mon avis au fur et mesure que je lis ton tuto :

  • Introduction Je pense que l'installation ne devrait pas faire partie de l'intro. Tu pourrais par exemple brièvement raconter l'histoire de Ruby, mettre une note sur le créateur (Matz). C'est surtout l'endroit ou tu vas devoir expliquer pourquoi Ruby est intéressant à apprendre (Conception objet, langage très dynamique, syntaxe élégante, …).
  • Installation A mon avis, tu devrais prendre un chapitre pour l'installation. Ici, seul les utilisateurs de windows sont concernés, c'est un sacré problème. Bien que le lien que tu donne propose différents moyen d'installation, celui ci n'est pas très explicite : on ne sait pas trop quelle méthode choisir. C'est aussi le chapitre idéale pour parler des outils comme RVM, en expliquant leur utilité, et pourquoi pas indiquer un lien vers un tutoriel pour avoir plus de détails.
  • Prise en main A l'instar du reste, c'est beaucoup trop pauvre. Tu présente irb comme une bête calculatrice (à noter, on ne dis pas l'irb mais irb tout court ;) ) Le lecteur peut dès maintenant tester les opérations sur les string, entiers, flottant. Éventuellement, on pourrait aussi présenter rapidement les conteneurs : Array et Hash. Mais surtout, ne pas inciter à écrire dans des fichiers tout de suite, irb permet de se familiariser avec les bases du langage, il faut en profiter !

D'autre part, je vois que dans ton plan tu comptes parler des méthodes avant même de parler d'un objet. C'est quelque peu déroutant, puisque une méthode est intimement lié à un objet.

Je te conseillerais donc d'étoffer ton chapitre sur l'installation. Ensuite, il faudrait présenter au lecteur la plupart des types courant de ruby : entiers, flottants, string, listes et dictionnaires (dans irb).

Avant de parler des structures conditionnelles, il faut être au courant de ce qui vaut vrai ou faux, à savoir seulement false et nil sont interprété comme faux.

Donc je te conseillerais d'étoffer ce que tu as déjà, et de revoir ton plan, de le complexifier un peu plus.

Si jamais tu as besoin d'aide, n'hésite pas à me contacter, cependant je ne me juge pas assez expérimenté pour enseigner quoi que ce soit ^^

Le cours à ce jour

Lien de la bêta

J'ai seulement écris deux chapitres. En effet, j'ai eu quelques soucis techniques avec mon ordi portable parce que j'ai du changer la carte mère alors que je suis à la campagne (et pas chez moi).
Imaginez un peu le temps que ça met …

La bêta est donc ouverte avec les modifications suivantes :

  • Modification du premier chapitre (déplacement de l'extrait "Ecrire dans des fichiers" + petit message HELP pour l'installation sur d'autres machines)
  • Création de la Partie Annexe avec "Ecrire dans des fichiers"
  • Création de l'extrait 1.2.5 "La méthode gets" dans le plan
  • Modification du plan (Méthode -> Fonction) + gets
  • Chapitre 2 et 3 de la partie 1 terminés.

N'hésitez pas à me contacter (ici ou par MP) si vous trouvez une faute/coquille/erreur/etc.

Autre chose ! Si vous maîtrisez le Ruby contactez-moi par MP, j'ai besoin qu'on m’éclaircisse sur un point (la boucle for).

Je pars pendant 4 ou 5 jours sans aucune connexion internet (même pas sur mon phone, sauf peut être pendant quelques heures mardi :euh: ). Donc soyez patients :ange:


Merci pour ton commentaire très construit GaaH, j'en ai pris compte dans ma rédaction ! Je vais donc répondre à tout (enfin je vais essayer).

Introduction - Je pense que l'installation ne devrait pas faire partie de l'intro. Tu pourrais par exemple brièvement raconter l'histoire de Ruby, mettre une note sur le créateur (Matz). C'est surtout l'endroit ou tu vas devoir expliquer pourquoi Ruby est intéressant à apprendre (Conception > objet, langage très dynamique, syntaxe élégante, …).

J'avais commencé à écrire un "copié-collé" de Wikipédia et ça m'a très vite saoulé. Je n'arrive pas à écrire cette partie, disons que j'ai un peu le "syndrome de la page blanche" … Je m'y attellerai sûrement plus tardn c'est dans liste de TODO.

Installation - A mon avis, tu devrais prendre un chapitre pour l'installation. Ici, seul les utilisateurs de windows sont concernés, c'est un sacré problème. Bien que le lien que tu donne propose différents moyen d'installation, celui ci n'est pas très explicite : on ne sait pas trop quelle méthode choisir.

Malheureusement je ne possède ni de Mac ni d'appareils sous Linux, j'ai donc mis un Helper pour demander des images aux gens (c'est pas génial mais c'est la seule solution que j'ai trouvé).

Tu présente irb comme une bête calculatrice.
Ne pas inciter à écrire dans des fichiers tout de suite, irb permet de se familiariser avec les bases du langage, il faut en profiter !

Tu as raison, j'ai appliqué ton conseil.

Avant de parler des structures conditionnelles, il faut être au courant de ce qui vaut vrai ou faux, à savoir seulement false et nil sont interprété comme faux.

J'ai totalement oublié ce point là !! Je rajoute aussi à ma TODO liste.

D'autre part, je vois que dans ton plan tu comptes parler des méthodes avant même de parler d'un objet

En effet, erreur de ma part. Je parlerai non pas des méthodes mais des fonctions.


Encore merci à toi pour ta critique, n'hésite pas me donner d'autres conseils !

+0 -0

j'ai besoin qu'on m’éclaircisse sur un point (la boucle for).

Hum je n'ai pas lu le fond mais ce point me fait tiquer. Un apprenant doit maitriser son sujet pour l'enseigner correctement au risque de tromper le lecteur. Je ne doute pas de ta motivation et de tes connaissances mais je suis circonspect que tu souhaite écrire un cours sur un langage dont tu ne maitrise pas entièrement les rouages, surtout une structure de langage aussi commune qu'une boucle for.

Pourrais tu expliciter ton problème avec cette construction ? Je ne connais pas Ruby mais j'aimerai bien savoir les détails qui te posent problèmes.

Rédiger un cours prend énormément de temps. Tu es motivé et tu semble avoir du temps, c'est chouette et tu peux aller au bout. Mais si tu ne maitrise pas parfaitement le language, ce serait une erreur de continuer ainsi. L'idéal serait alors que tu trouve un co auteur spécialiste de ruby qui, si il n'a pas le temps de rédiger, peut te relire et corriger les erreurs qu'ils trouvera. D'une manière général deux pairs d'yeux valent mieux qu'une.

Bonne chance dans tous les cas.

Merci à toi Kje.
En effet j'ai eu un petit souci avec la boucle for parce qu'elle est différente en Ruby qu'en Python ou en Java, et j'avais oublié le principe. Seulement je m'en suis souvenu donc je màj le cours à mon retour de congé (d'ici vendredi normalement).

D'une manière général deux pairs d'yeux valent mieux qu'une.

En effet, j'ai peut être qqn qui peut m'aider

Je ne peux qu'être d'accord avec Kje, j'ai aussi eu un petit frémissement en lisant ta bio, notamment lors du passage "J'ai donc appris le Ruby grâce à un livre, un peu nul d'ailleurs." (Et aussi a cause de ton age, mais comme le dis si bien l'autre, "la vaillance n'attend point le nombre des années")

De manière générale, la boucle for ne sert à rien, ça reste du sucre syntaxique pour

1
2
3
4
5
6
7
enumerable.each do |e|
  # Ton code
end

for e in enumerable do
  # Ton code
end

Petit message pour vous quelques choses :

  • Finalement j'ai cette journée de libre (il pleut donc je ne peux pas partir) mais ça on s'en fout
  • Annexe sur la boucle for écrite ;)
  • Quelques lignes dans la partie des variable pour parler des constantes
  • Une nouvelle annexe sur la boucle begin...end while (équivalent à do...while en python) dans le chapitre 3
  • Titi_Alone ajouté comme co-auteur pour m'aider dans la rédaction

Ça va pas du tout. Il y a plein de petites erreurs, et des choses manques. Cependant, ce n'est pas le plus grave puisque ce n'est qu'une bêta.

Cependant, quand je lis des choses comme

La boucle do sert à afficher les éléments d'un tableau.

Ou encore

Elle peut également avoir une valeur de retour, mais ce n'est pas obligatoire. Dans le cas où elle n'en a pas, on appelle cette fonction une procédure.

Bah ça me fait voir rouge. La boucle Do n’existe pas. Le mot clé do, dans ce contexte, ouvre un block qui sera passé en paramètre à la méthode each (méthode appartenant au module Enumerable). Et les blocs, ça ne sert pas qu'à faire des boucles !

De plus, en Ruby, une méthode à toujours une valeur de retour. Si celle si n'est pas renseigné, la méthode renvoie nil. C'est aussi simple que ça. Il n'y a pas de fonction, pas de procédure, que des méthodes !

1
2
3
2.1.0 :001 > puts "Et puis merde, même irb dis que ça renvoi nil !"
Et puis merde, même irb dis que ça renvoi nil !
 => nil 

Je passe sur le fait que la syntaxe d'une fonction est mal expliquée. Comme je l'ai dis, ce n'est qu'une bêta. Mais pensez à parler des parenthèses optionnelles plutôt que d'en mettre, puis de ne plus en mettre. (Renseignez vous sur les conventions Ruby aussi, histoire de ne pas prendre des mauvaises habitudes)

EDIT: Mmmh, après relecture ce message me semble un peu agressif. N'allez pas prendre ça mal !

+0 -0

Plop.

Je suis toujours hesitant quand a la co-rédaction du tuto, j'ai rédigé, pour le moment, une courte introduction au langage. Maintenant, en relisant le tuto', je pense que tout, ou presque, est a revoir. Donc je reste en co-auteur pour le moment et je continue de rédiger un coup, mais il n'est pas exclu que je parte sur la rédaction de mon propre tuto' sur Ruby plus tard.

J'pense pas que ce soit une super idée que tous le monde parte faire son tuto, au final il y aura plein de bouts de cours inachevés en bêta. Pas top.

A la limite, ce que je peux proposer, c'est de changer le titre du cours par "Une introduction à Ruby, le meilleur langage interprété de tous les temps"1, et peut être que je pourrais participer au projet, si tous le monde est d'accord.


  1. Ou juste "Une introduction à Ruby". 

Bonjour !

J'aimerais poster quelques commentaires :

  • Faire presque toute une partie sur les boucles au début du cours me paraît un très mauvais choix étant donné que Ruby dispose de constructions de haut niveau (Array#each, Fixnum#times…) permettant d'exprimer toutes ces boucles de manière plus naturelle et plus sûre. Qui plus est, il s'agit d'une très mauvaise pratique en Ruby d'utiliser des boucles, on leur préfère très largement les fonctions susnommées. ;
  • Je reviens sur ce qu'a dit GaaH, for n'est pas du sucre syntaxique pour Enumerable#each, ce serait presque l'inverse. En fait, il est fort probable que la fonction Enumerable#each utilise for en interne ;
  • begin ... end while n'est pas vraiment une construction du langage en tant que tel. Il s'agit que réalité de la construction begin … end (qui regroupe diverses instructions en une seule) suivit de la notation while postfixée (tout comme le fameux puts "OK" if condition == true). Mais bon, ça c'est un détail. :) ;
  • Le chapitre "Parcourir le contenu d'un tableau avec Do " devrait plutôt être nommé "Parcourir un tableau avec each" puisque la fonction est bien Array#each et non do qui n'est que le mot-clef introduisant un bloc. ;
  • En parlant de blocs, je trouve dommage de ne pas les introduire dans le cours plus tôt. D'un point de vue utilisateur bien sûr ! Type "apprendre à créer un Array grâce à un bloc" ou "Compter avec un Fixnum#times". Puis, éventuellement bien plus tard, expliquer les tenants et aboutissants des blocs.

Ceci est mon humble avis, ça vaut ce que ça vaut… :)

Par ailleurs, j'ai l'intention de rédiger un tuto complet sur les blocs, de l'utilisation de fonctions d'ordre supérieur jusqu'à la création de fonctions utilisant des blocs. Donc je réserve. :D

Effectivement, il est question d'une fonction "each_with_index_i", qui je pense fait ce que j'ai prévu. Maintenant, j'ai bien dit "probable". Et, quoiqu'il en soit, que each soit récursive ou itérative, il n'empêche qu'elle n'est en aucun cas la base de la boucle for car complètement indépendante.

La question n'est pas de savoir si elle est utile ou non. Je suis persuadé qu'elle est utile, et pour cause, dans beaucoup d'autres langages c'est le cas. En Ruby, comme je l'ai dit plus haut, on a des outils bien plus intéressants comme Enumerable#each ou Fixnum#times rendant de ce fait la boucle for obsolète dans la plupart des cas. Comme je l'ai aussi dit, utiliser des boucles en Ruby est une mauvaise pratique quand on peut faire autrement (90% des cas).

Chipotage : comme tu le dis, elle ne t'es pas très utile, mais ça ne veut pas dire qu'elle ne l'est pas tout court ;)

Après lecture de ton message GaaH, je me rends compte que je ne maîtrise pas assez le langage pour écrire un cours parfait et fini. Je me suis lancé dans l'écriture de ce cours parce que le Ruby est un langage qui me plaît (bien que je ne l'ai pas approfondi) et qui est facile à apprendre. Peut être que je n'aurais pas dû ?

Je rejoins l'opinion de GaaH en ce qui concerne l'écriture d'un autre tutoriel sur Ruby, ce n'est pas une bonne idée - à part si c'est pour écrire un tuto qui approfondirai ma courte introduction.

Du coup je rejoins aussi l'idée de Kje, il faudrait qu'une personne qui maîtrise ce langage corrige ce tutoriel pour le rendre buvable.

PS : j'ai modifié le nom du tuto comme me l'a conseillé GaaH

C'est déjà très mature de reconnaitre son manque de connaissance dans un domaine.

Je suis développeur professionnel (c'est mon boulot) et pourtant je ne suis pas sur de pouvoir écrire un tutoriel aujourd'hui et encore moins un sur Ruby il n'y a donc aucune honte.

Ce qui est bien dans le fait que tu t'en sois rendu compte assez tôt c'est d'éviter de se pencher dessus trop longtemps pour au final devoir tout réécrire.

Après faut voir ce qui peut être le plus intéressant :

  • qu'une tierce personne relise ce que écris et donc que tu continue
  • qu'une tierce personne reparte de ce que tu as écris en modifiant certaines choses (dont le plan)
  • qu'une tierce personne reparte de zéro (solution préférée à mon goût)

Si tu ne maîtrise pas assez le langage je pense que ce serait contre-productif que tu continue l'écriture et qu'une personne fasse les corrections.

Je pense que c'est mieux qu'une personne qui maîtrise mieux le langage fasse son propre tuto (quitte à reprendre des idées de plan de tiens).

Rien ne t'empêchera par la suite de faire un tuto sur le langage Ruby, tu pourra très bien faire sur une GEM en particulier ou ce genre de chose, je suis sur que ce serait très apprécié.

Plusieurs personnes ont exprimé leur envie de faire un tuto (Raitom qui s'occupe de rails, titi_alone, lalla qui semble partir sur les blocs mais peut être qu'il/elle serait intéressé-e) peut être qu'il faudrait voir avec eux.

P.S : ne prend surtout pas mal ce message :D il n'a absolument pas l'objectif de t'accuser :)

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte