Dépôt d'exercices

Je suis du même avis que @SpaceFox.

PS: J’aime bien le terme d'@amael : « banque d’exercices »

Surtout que les exercices deviennent techniquement exploitables dès la phase 1. et commencent à avoir une vraie valeur ajoutée dès la phase 2.

Si on se met à la place des utilisateurs de ces exercices, ces priorités relèvent du "bon sens" pour eux :

• On leur donne des exercices,
• On leur donne ensuite un moyen de travailler de façon autonome et de se corriger,
• Et enfin, on rajoute les jantes alu et le moteur à énergie solaire et on pimpe le truc pour le "vendre".

Pardon, j’ai pas suivi le débats.

Dépots créer

Je clos un peu le débats mais j’avais prévenu ^^"
Au pire, Git c’est centraliser, vous pouvez push depuis ailleurs.

J’ai mis tous les exercices Python du message initial. Et certains exercice en C (une partie des défis). Ainsi qu’un README. Toute contribution est la bienvenue.
Il me reste la TODO list à faire. Mais finalement le peuble à l’air d’avoir plus envie de le faire sous forme de ticket. Il me reste pas mal de trajet avant d’arriver à la PyConFR donc bon j’espère avoir le temps/l’envie/le courage de le faire sous forme de ticket.

Si j’ai le courage :

• TODO sous forme de ticket
• Finir de récupérer les exercices en C
• Faire les tests unitaires en C
• Faire les tests unitaires en Python

Je le dis afin que si quelqu’un veut faire un truc on puisse s’organiser.

Pour finir, il y a quand même un question à se poser au niveau du droit d’auteur (mettre les auteurs des exercices, et surtout, avons-nous le droit d’extraire l’énoncé de certains exercices sans la permission de l’auteur). Ce sont des problèmes que je me poserais plus tard mais il faudra y réfléchir je pense.

@ache je vois que tu as séparé par langage à la racine. Mais les exos qu’il y a pour chacun d’eux sont spécifique au langage ? Genre un exo Python peut-être faite en C normalement ? (Sauf s’il traite d’un aspect du langage).

Mieux vaut-t-il pas du coup avoir un répertoire par exo et en sous répertoire les solutions dans différents langages (quand ça ne traite pas d’un aspect d’un langage) ?

En fait, on manquera très vite d’un index des exercices. En l’état, ce n’est pas tellement explorable.

@Heziode Ça se discute, j’ai suivi le plan d’informaticienzero.

Certains sont vraiment spécifique au langage, d’autres non mais nécessiterait une réorganisation.
Dans tous les cas, si on fait des tests unitaires, un code d’exemple et tout, il faudra faire choisir un langage.

Un index ! J’approuve à 100%, je pense que c’est très bien vu.

Un index dans quel sens ? $0, 1, … n$ ou une sorte de sommaire ?

Une sorte de sommaire plutôt.

Sur Github, ça discute licence libre, licence par défaut, et les libertés minimums des licences des énoncés des exercices.

C’est peut-être un peu tôt pour l’instant mais bon …

L’idéal serait de mon point du vue: essayé de rentrer en contact avec la personne qui a écrit l’exercice à l’origine pour lui demander l’autorisation.

Si pas de réponses ou personne non contactable, modifier (ré-écrire) l’exercice avec le même objectif.

Quant à la licence, une licence libre serait bien, quant à laquel choisir, là je n’ai pas d’idée pour le moment.

Pour tous les miens (y’en a une pelletée en Python) vous pouvez évidemment considérer qu’ils sont en CC-BY.

Arf, il faut rajouter ton pseudo ! x)

Ok merci, c’est noté

C’est la licence la plus permissive qui soit autorisée par la loi Française, en fait. Sinon honnêtement j’aurais choisi la WTFPL (Do What The Fuck You Want Public License).

Je pense que c’est une vraie question.

A priori, la plupart des exos, sauf ceux focalisés sur la fonctionnalité X d’un langage, ne sont pas liés à un langage particulier, et que cette distinction n’a pas lieu d’être (par exemple: on peut très bien faire un solveur de sudoku en java ou python plutôt qu’en C). C’était clairement un défaut sur le SdZ à mon sens, et il est vraiment dommage de le reproduire.

Maintenant, il est clair que la formulation des exercices est au départ souvent orientée en fonction d’un langage source, et je suis bien conscient que modifier cela demande un effort d’édition certain. Mais d’un autre coté, cela permettrait de mieux s’approprier les exos originaux.

En ce qui concerne les tests unitaires, on peut imaginer pour chaque exo un fichier data commun et des fichiers de test différents en fonction des langages.

Je viens de faire ce que j’aurais du faire au début, c’est à dire le tri des exercices, avec ceux spécifiques à un langage et ceux généraux. J’ai aussi fait une liste de ceux en double qu’il vaut mieux fusionner.

Indépendant du langage

Spécifiques C

Spécifiques C++

Spécifiques Python

Exercices similaires / en double —> À fusionner

@yoch Je pensais justement à quelque chose comme ceci. Et même si les exercices ont été rédiger pour un langage à la base, comme tu l’as dit-ils sont généralement focalisés sur une notion algorithmique, design pattern, etc. un aspect « théorique » qui peut-être commun à plusieurs langages.

Du coup, à l’exception des exercices qui touche un aspect particulier d’un langages, tous les exercices peuvent être généraliser bosser sur un ensemble de notions. Par contre du ça donne une sacré charge de boulot de les « généraliser ».

Pour que ça puisse avancer rapidement et efficacement, voici ce que je proposerais :

1. on établit (ici ou sur github) une liste d’exercices à porter / améliorer (voir le message d'@informaticienzero ci-dessus)
2. toute personne intéressée peut indiquer qu’il prend en charge l’exo en question
3. une fois l’exercice prêt, il fait une pull-request sur le dépôt

Comme ceci, chaque ajout n’est pas très long à faire et tout le monde peut participer. (et puis, notez que ce mois-ci, chaque PR compte pour Hacktoberfest )

NB: J’ai commencé en soumettant une PR pour zSudoku.

J’ai une PR pour le zDéfi #1.

J’aimerai proposer quelque chose. Nous sommes d’accord qu’il est bien de ne pas partir sur un découpage par langage quand la plupart des exercices sont faisables avec n’importe lequel. Du coup, comment organiser le repo ?

Je propose qu’on créé un dossier par exercice. Ce dossier contiendra l’énoncé, éventuellement des ressources supplémentaires, ainsi que deux dossiers : Tests, qui contiendra les tests unitaires, et Solutions, où l’on met les codes des gens qui ont résolu l’exercice, peu importe le langage.

• Exercice

  • Solutions

    • informaticienzero_exo.cpp
    • nohar_exo.py
    • développeuse_avec_gants_vaisselle_haskell.hs

  • Tests

    • tests.py
    • tests.cpp
    • tests.hs
  • Énoncé.md
  • Éventuelles ressources supplémentaires.

Ensuite, chaque personne qui fait un PR met l’index dans le README à jour. Qu’en dites-vous ?

Je ne sais pas vraiment si on devrait inclure les solutions. La question se pose je pense.

Niveau organisation, le plus simple, c’est de faire un git pull ... et d’avoir son exercice et uniquement son exercice. Ce qui néssécite un dépos par exercices. Mais penser à ça pour l’instant est un peu tôt je pense.

Ça me parait totalement overkill de faire ca.

Peut-être un sous répertoire par langage dans solutions, car pour des projets genre javaquarium il y a besoins de plus d’un fichier pour le réaliser.

Le fait de suivre cette architecture peut permettre de généré un index relativement facilement.

Par exemple, c’est ce que fait guide.freecodecamp.org (le repo), à coup de requête GraphQL ils tappent l’api V4 de github pour récupérer l’architecture du repo et génèrent l’arborescences des cours avec.

Un autre exemple, codechef à une architecture similaire, il donne un exo et il y a des solutions dans différents langages.