Il peut être pratique de fournir un repository Git plein de code à télécharger dans un tuto. Parfois le code a plusieurs états, comme autant d’étapes que vous voulez que le lecteur découvre au fur et à mesure.
Voici un petit alias Git qui permet de faire exactement cela. Mettez dans votre fichier ~/.gitconfig :
[alias] prev = checkout HEAD^1 next = "!sh -c 'git log --reverse --pretty=%H master | awk \"/$(git rev-parse HEAD)/{getline;print}\" | xargs git checkout'" |
Et votre lecteur pourra juste faire :
git next git prev |
Pour passer au commit suivant ou précédent dans votre repo, comme un wizard. Vous pouvez alors dans votre tuto parler du code dans un état donné, puis lui demander de faire git next, puis parler du nouvel état du code, etc.
Je n’ai jamais compris git :/ snif.
Super cette astuce !
Même si les dépots git liés à des tutos n’ont parfois qu’un seul commit “First commit”
@JeromeJ : je me tate à faire un bon tuto sur la question. Mais c’est looooooooooooooooooooooong.
Ah en tout cas un tuto sur Git serait vraiment le bienvenu !
Ha ce Git!! l’outil du siècle :)
Mais comment faites-vous pour écrire autant de tutos, d’articles !! vous avez un débit impressionnant, et de qualité en plus :p
Avouez, vous n’êtes pas humains :p
Bonne continuation .
Ch.
On est des bots codés avec des chaînes de markov calibrées sur le site du zéro.
Hey Sam, toi qui est prof, aurait-tu quelque chose à dire ? Sur le thème: Apprentissage par le cours magistral, versus apprentissage par l’exemple. Caractéristiques, singularités. Qu’est-ce qu’un exemple?
dans le style tuto bien foutu sur le workflow de release/branch :
A Successful Git Branching Model
@roro : non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.
@Sam : Qui me dit: ” Non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.”
Normal. C’est pour cela que pour homologuer un nouveau système de freinage il faut passer par les essais sur route.
Pour être plus clair: Je vais à l’article: “Comment améliorer la communauté python francophonne”.
Là, je fais un copié/collé dans le bloc-note de Windoze, de:
1)- “Le bout de code de Guido VR”, et
2)-“Le mème bout commenté par Max”.
J’ouvre le shell, j’y colle le premier: ça marche; j’y colle le deuxième, ça marche pas. (indentation)
Tout ça pour dire, que l’exemple “véritable” est la meilleure, (je n’ose pas dire la seule) façon de valider un code.
D’où la question: qu’est-ce qu’un exemple ?
Je ne sais pas répondre à cette question.
Et bien c’est simple; c’est un truc qui donne la preuve que le code fonctionne.
D’où la nécessité de disposer d’une sorte de banc d’essai réutilisable,dans lequel on pourra inclure un bout de code et tester son fonctionnement.
Ce “banc” pouvant de plus, servir de base de départ à des projets, quitte à en élaguer l’inutile.
Il y a longtemps que je me suis bricolés de tels bancs ( mais ils sont dans un langage dont la seule évocation est honteuse, pour les élites de la prog.)
Ca exclue le pseudo code, le cas d’école, l’idée théoerique en général. Le problème avec cette idée c’est qu’elle exclude les cas complexes qui ne peuvent pas se représenter par un simple snippet applicable. Il nie aussi la relation qu’il y a entre plusieurs bouts de code, qui peut être ce que l’exemple veut illustrer.
C’est pour ça que je n’ai pas voulu me risquer à répondre cette question, c’est parceque je ne pense pas pouvoir y répondre sans dire une contre vérité.
Et c’est pourquoi, je ne développe pas en python à partir de zéro.
Je préfère bricoler sur des codes existants, et fonctionnels, même si ce sont parfois des trés gros morceaux.
Comme le code fonctionne, je peux tester mes modifs, “in situ”.
Parce qu’en prog, on a beau savoir ce qu’on fait, on fini toujours, à un moment, par avancer à l’intuite”, et c’est là que les soucis commencent.
Un banc d’essais peut être simple, complexe, ou non réalisable; en fonction de ce qu’on a à tester.
Et vu la poly(morphie!?!) du python, de tels bancs ne sont pas évidents à concevoir.
Cela reste un bel exercice d’imagination.
Un truc qui marche bien aussi c’est utiliser les branches/pull-request pour faire des tutoriaux:
https://github.com/leplatrem/django-leaflet-geojson/pull/1/files