Merge principal des différents groupes

[ALambot]

Contient les pages rst du sites, des tâches Inginious et certains .yaml modifiés.

[RobOWt]

Can I test this patch?

Reminder: my commands are

• "ok to test": to add this PR in the checklist of Jenkins
• "test this please": to trigger a new build I will only listen to repo owners.

[francoismichel]

Pour ce qui est déjà fait: Nice ! C'est propre, clair, et les exercices s'insèrent vraiment bien dans la théorie. Petites remarques :

• Dans la section "Conditions complexes", il reste un print au lieu de afficher
• Une ou deux typos (du genre "eet")
• Pour le petite exercice sur le fait d'être "majeur", la réponse se trouve quasiment dans l'exemple du dessus. Que pensez-vous d'une petite modification du style "aux USA, les gens peuvent voire de l'alcool à partir de 21 ans, ..." plutôt que 18 ans ? C'est pas grand chose mais ça éviterait de recopier la réponse de l'exemple pour répondre à l'exercice. Qu'en pensez-vous ?

N'oubliez pas de rajouter le header de la license AGPL sur votre code java pour vos tests unitaires. Un exemple du header est trouvable à la racine du repo (ici)

Vous pouvez aussi utiliser la directive rST authors comme suit:

.. author::

    Vos noms

si vous voulez indiquer vos noms en tant qu'auteurs de la page que vous avez écrite sur le syllabus.

Bien joué et bonne continuation !

[francoismichel]

Dans la page "Expressions"

Quand on combine des variables numériques de types différents, comme des entiers et des réels, l'entier sera converti automatiquement en réel.

Peut-être ambigu ici, je dirais plutôt "[...] converti automatiquement dans le type le plus "large" deux deux (dans l'exemple, ce sera converti en double car tous les int peuvent être représenté avec un double)

Quelque chose du style ?

D'ailleurs vous faites bien la distinction dans la section suivante sur les conversions de types :-)

[AlexandreDubray]

Hello,

premièrement , merci à tous pour le travail fournis! Vous avez tous fait du très bon travail, c'est cool! J'ai passé en revue l'ensemble des pages de théories et pour chaque chapitre je vais proposer des idées ""d'amélioration"", ou des questions que je me suis posé en lisant. Ces idées n'engage que moi et ce sont des propositions dont il faut discuter avec les auteurs de la pages en questions, vos avis sont plus importants :-)

Chapitre sur les variables

Syntaxe des noms de variables

• Pour les exemples au tout début, ça serait plus lisible si c'était mis sous forme de liste peut-être? Je croyais au début que c'était un seul nom
• Je pense qu'il serait peut être intéressant d'inverser ce chapitre avec le chapitre "Déclaration et affectation de variables". Je trouve ça plus logique de d'abord parler de comment on déclare et affecte une variable avant de donner les conventions de nommage en Java

Déclaration et affectation

• Dans votre premier exemple, vous expliqué que, bien qu'on ait changé la valeur de value, celle de calcul ne change pas. C'est très bien et je pense même que ça vaut la peine d'expliqué un peu plus en profondeur ce concept. Qu'en pensez-vous?
• L'exercice sur la portée des variables me semble mal placé. Je pense que c'est un exercice très intéressant, mais le lecteur ne c'est pas (sauf erreur de ma part) vu introduit au concept de portée des variables. C'est un exercice qu'on pourrait reprendre dans le chapitre (à venir) sur les fonctions. Ici je pense que le lecteur sera un peu perdu et ne saura pas trop ce qu'on lui demande. Mais l'exercice reste très intéressant

Chapitre sur les expressions et expression conditionnellle

• Pourquoi avoir séparer les deux chapitres? Ils s'emboitent plutot bien ensemble non?
• Dans la partie sur les expressions conditionnelles, vous introduisez les opérateur &&, || et ! sans vraiment expliquer ce qu'ils font. Je suppose que c'est ce qui viendra dans la partie "Expression logique" ?

Chapitre sur les boucles

Les boucles while

• C'est une très bonne idée de faire une comparaison entre une while et une do ... while. Cependant, je n'utiliserais pas du pseudo-code pour l'expliquée. Le syllabus vise principalement des personnes qui ne sont pas dans le milieu informatique. Le concept de pseudo-code peut leur sembler bizarre et les perturber je pense. À mon avis, il serait plus intéressant de reprendre vos exemple au début, et d'expliquer à partir de vos exemples. Ou alors de changer le pseudo-code en code et de garder la structure actuelle.
• Pour un de vos exemples, vous afficher l'alphabet. Il faudrait alors peut-être donner aux étudiants la manière dont est représenter un caractère en mémoire (codage ASCII par exemple). On leur dit qu'il est encodé sur 2 bytes mais on ne leur dit pas explicitement que un char est en fait un nombre et donc qu'on peut itérer dessus de la manière dont vous le faîtes. C'est donc à voir avec les personnes travaillant sur les types de variables

Chapitre sur les tableau

• Voir issue #5

Voilà, en attente de vos commentaires :-)

[francoismichel]

Comme je l'ai dit précédemment, c'est bien fourni comme Pull Request ! Bravo !

Je réagis à quelques phrases de @AlexandreDubray :

Chapitre sur les variables

Je pense qu'il serait peut être intéressant d'inverser ce chapitre avec le chapitre "Déclaration et affectation de variables". Je trouve ça plus logique de d'abord parler de comment on déclare et affecte une variable avant de donner les conventions de nommage en Java

Pareil, surtout le chapitre de déclaration et affectation semble expliquer le concept de variable.

Concernant cette phrase, dans la page Déclaration et affectation de variable: Un nom utilisé pour faire référence à une donnée stockée en mémoire est donc appelé une variable.

Je pense que concernant la définition du mot variable, on devrait un peu plus coller à la définition du cours de Java, càd quelque chose comme "Une partie de la mémoire réservée pour contenir des données" et non le nom qui désigne cette partie de mémorie.

Dans votre premier exemple, vous expliqué que, bien qu'on ait changé la valeur de value, celle de calcul ne change pas. C'est très bien et je pense même que ça vaut la peine d'expliqué un peu plus en profondeur ce concept. Qu'en pensez-vous?

C'est une très bonne idée. Ca peut aussi être fait après le merge de la pr :-)

Chapitre sur les boucles

C'est une très bonne idée de faire une comparaison entre une while et une do ... while. Cependant, je n'utiliserais pas du pseudo-code pour l'expliquée.

J'imagine que tu fais référence aux exemples sur l'informaticien, avec du pseudo-code écrit en commentaires. C'est vrai que les commentaires peuvent porter à confusion. On pourrait utiliser des méthodes qui représentent le comportement de l'informaticien, il n'y aurait alors pas la confusion avec les commentaires et c'est d'ailleurs fait dans les derniers exemples de la page. Ou printer un message à la place d'appeler une méthode ?

À mon avis, il serait plus intéressant de reprendre vos exemple au début, et d'expliquer à partir de vos exemples. Ou alors de changer le pseudo-code en code et de garder la structure actuelle.

Pourquoi pas mais alors bien introduire le concept abstrait avant de donner l'exemple en code Java.