Dépôt d'exercices

Pour l’instant oui. Mais exercism utilise carrément un outil à eux juste pour faire ça …

Je suis en train de finaliser zDragon.

J’avais déjà fait un peu de recherche dessus et je n’ai pas trouvé de solution permettant de faire ceci.

Du coup l’utilisateur devra savoir lire le latex non compilé

Une autre solution serait d’avoir un site static auto-hébergé sur le repo (gh-pages) qui parse les fichiers md avec remark par exemple.

Malheureusement je crois que le github-markdown ne gère pas les maths, et que c’est pour ça qu’on a un module dans le zMarkdown pour gérer spécifiquement les formules mathématiques (et je crois même que c’est la raison principale pour laquelle on a un zMarkdown xD)

Sinon, j’ai pas envie de briser l’élan, mais je pense qu’il faut d’abord réfléchir à la structuration

Si on reste sur la catégorisation par langage, ça veut dire qu’il faudra copier l’énoncé des exercices d’algo dans chaque dossier.
En soit, je pense que ça a du sens que l’exercice n’apparaisse pas dans le langage si les tests ne sont pas écrit, et ça peut permettre d’ajouter des précisions spécifiques, mais ça peut cacher aux débutants des exercices intéressants simplement parce qu’ils se cantonneront au dossier de leur langage :/
La catégorisation par langage peut faire l’objet d’un dépôt chacun (je pensais aussi à un dépôt par exercice, mais y’a des exos vraiment petit, un dépôt est overkill, je pense qu’un dépôt par langage est un bon compromis) et un dépôt maître qui contient les autres par submodule ?

Aussi l’avantage de la catégorisation par langage serait de s’uniformiser un peu, notamment dans le framework de test unitaire !

Avec une arborescence un peu standardisé, il ne doit pas être très compliqué de faire un script générant le sommaire en markdown

Pour le partage des solutions, je sais pas trop :/ je ne pense pas que se soit bon de le mettre dans le dépôt, et le forum n’est pas très pratique pour ça …
L’idéal c’est une base à la CodinGame mais c’est un travail conséquent !
(En fait CodinGame fait exactement ce qu’on cherche à faire, un énoncé avec des tests unitaires en laissant le choix dans le langage et le partage de la solution proposé par chacun des participants, mais ils le proposent dans leur environnement de développement et par conséquent il y a un gros travail de maintenance pour avoir tout à jour et proposer tout ces langages, et c’est justement une des limites, on ne peut pas programmer dans un langage qu’ils ne proposent pas)

Du coup je pense encore que le plus simple c’est de bien indiquer en gros dans le README que ce serait appréciable de partager sa solution sur le forum de zds avec le tag correspondant au nom de l’exercice
Là le soucis qu’on peut avoir, c’est dans le renommage ou la suppression d’exo …

Perso je suis plus pour une catégorisation par exercice, et pour chaque exercice on propose les langages avec leurs tests comme proposé @informaticienzero.

Euh … Ce que j’essaye de dire depuis pas mal de temps, c’est que pour l’instant on s’en fiche non ?
On verra ça quand on aura un truc utilisable …

À la limite essayer de généraliser les exercices ok mais pour l’instant si on a déjà des exercices avec des testes.

Ouep bien sur.

Ben moi j’ai peur que si la structure change vers une solution comme celle d’informaticienzero ou même n’a plus rien à voir comme celle de A-312, on se retrouve avec une solution batârde pas très agréable
Mais si vous souhaitez faire le pari, ok, ce ne sera pas insurmontable c’est sûr

Outre la peur de l’évolution foireuse à l’avenir, mon soucis est qu’actuellement ce n’est pas clair pour moi et du coup j’ose pas trop m’y mettre
Parce que retranscrire simplement les messages du forum en markdown ne m’intéresse pas trop, par contre je me prendrais bien un exercice C++ en entier.
Je voudrais reformuler l’énoncer pour qu’il soit moins en mode "message de forum", et proposer un Squelette dans lequel devra être inscrit la solution, et une série de test avec Boost.Test
Et j’aurais bien aimé un exemple parce que j’ai pas confiance en moi

Bref, si on vois tout ça plus tard, je vais essayer d’écrire quelque chose et le proposer en PR, yolo, on verra bien xP

On est dans une phase où tout est possible, rien est fixé et il y a beaucoup de mouvement. C’est normal d’avoir un peu d’appréhension à mettre les mains dans le cambouis et d’avoir peur de faire quelque chose de travers, mais il ne faut pas ! Fais des PR, propose des exercices, commence à ranger les choses de meilleure manière, etc. Si ça coince, on en discute ici ou sur GitHub et ça avancera.

Actuellement, l’objectif numéro 1 est de rapatrier tous les exercices sur GitHub. C’est un choix assez pragmatique, car il permet de gérer relativement facilement n’importe quelle évolution dans le futur.

Ensuite, pour avoir une valeur ajoutée par rapport à d’autres collections d’énoncés, écrire des tests unitaires est vraiment intéressant.

Enfin, quand on aura beaucoup d’exercices et une meilleure vision de la chose, alors on réfléchira à l’organisation des fichiers, etc.

Après l’avantage, c’est que comme on est des bénévoles, on fait ce qu’on veut à la fin.

Proposer un squelette et des tests, c’est déjà ce que j’ai fais sur ma PR et ce que je propose dans mon message précédent avec la structure.

J’ai proposé aussi de joindre des solutions parce que je me souviens combien c’était énervant, en temps que débutant, que certains exercices soient sans solution, ou bien des .zip qui n’existent plus depuis des années.

Ma solution est perfectible et si une meilleure est proposée, on fonce dessus. Simplement, dans un esprit pragmatique et pour éviter les discussions qui durent indéfiniment et tuent l’envie de s’y mettre, je propose qu’on parte dessus, quitte à corriger le tir, quitte à se gourer complètement.

@leroivi : n’hésite pas à demander de l’aide si besoin. Choisis un exercice de ton choix, et traduis-le en markdown. Et les tests Boost, excellente idée. C’est ça qui fait que l’idée du repo est un gros plus.

Pour la structure, c’est sans doute prématuré de décider, mais on peut toujours en discuter.

Si on reste sur la catégorisation par langage, ça veut dire qu’il faudra copier l’énoncé des exercices d’algo dans chaque dossier.
En soit, je pense que ça a du sens que l’exercice n’apparaisse pas dans le langage si les tests ne sont pas écrit, et ça peut permettre d’ajouter des précisions spécifiques, mais ça peut cacher aux débutants des exercices intéressants simplement parce qu’ils se cantonneront au dossier de leur langage :/

Attention à ne pas confondre la structure interne du dépôt et la présentation. Il est tout a fait possible de garder une structure divisée par exercice, et de proposer plusieurs types de présentations: par thème, par langage, par niveau, etc.

Je te rejoins sur ce point, il serait bon d’avoir des standards permettant d’uniformiser tout ça. Mais on en est encore loin je pense.

Pour les tests, rien ne nous empêche d’en fournir plusieurs exemplaires. En C++, on peut ainsi imaginer tests vanillas en utilisant des assertions, Google Test, Boost Test, ce qui ferait trois fichiers et laisse le choix à l’utilisateur de prendre ceux qu’il veut.

@yoch : +1 pour ton idée de faire plusieurs catégories dans le sommaire : liste par ordre alphabétique, liste par langage, liste par thème, etc.

Pour Python, vu qu’il s’agit d’exercices pour débuter, et même si c’est de très loin la meilleure bibliothèque, je pense qu’il vaut mieux renoncer à faire installer pytest aux gens et produire des test avec le module standard unittest. À moins que quelqu’un se sente d’expliquer aux gens sous windows comment installer un paquet du PyPi.

Hello,

Du nouveau par ici ? Le concept est après tout très intéressant.

Je me posais la même question. Moi je n’ai rien fait (oui, j’ai ouvert le sujet mais je n’ai rien fait )