Tuto
Closed this issue · 20 comments
Je ne sais pas où le mettre à part dans une "issue"...
ci-dessous une nouvelle version de mon tuto, un peu plus détaillé, on passe de 3 pages à 16, mais c'est écrit plus gros pour être adapté à une lecture sur l'iPad.
Merci de relire et vérifier qu'il n'y a pas d'erreur...
Nico
Tuto automatisation route OFP.docx
Je vais relire plus en détails pour vérifier les liens mais ça m'a l'air bien.
Juste deux remarques, tu parles de paramétrer l'album photo sur Revoir Gramet mais pas Lido2Gramet, pourtant si tu as dû le faire pour l'un, tu as dû le faire pour l'autre. La deuxième c'est qu'il faut autoriser workflow à accéder à Photos. (Reproductible en changeant l'autorisation dans Prefences/Confidentialité / Photos
Les liens m'ont l'air bien.
On pourrait le publier sur gihub de manière à pouvoir le modifier facilement.
Example en format markdown:
https://github.com/flyingeek/editolido/blob/gh-pages/tuto/tuto.md
Je ne suis pas contre, en revanche il faut quand même une version pdf pour
la doc partagée
Le dimanche 3 avril 2016, flyingeek notifications@github.com a écrit :
Les liens m'ont l'air bien.
On pourrait le publier sur gihub de manière à pouvoir le modifier
facilement.Example en format markdown:
https://github.com/flyingeek/editolido/blob/gh-pages/tuto/tuto.md—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#12 (comment)
Voilà ce que ça donne en faisant une sortie PDF du markdown depuis Marked
Bon j'ai regénéré tout ça, on obtient:
https://flyingeek.github.io/editolido/tuto/tuto.html
https://flyingeek.github.io/editolido/tuto/tuto.pdf
Pour modifier, sur github tu fais un fork, tu travailles sur gh-pages en creeant une nouvelle branche puis tu fais un pull request pour que je merge les diffs. Tu peux essayer à loisir de modifier ton fork, si tu es perdu, tu effaces tout et tu refork.
Le tuto est en format .md dans tuto/tuto.md
Si je comprends bien :
- je fais un fork
- je fais des modifications
- mais comment je vois le résultat de ces modifications, page html ou pdf?
Merci de ton aide
Pascal
Moi j'utilise http://marked2app.com (pour Mac) qui est un visualisateur/convertisseur de Markdown mais il doit y avoir plein de visualisateur de markdown sur PC.... Les editeurs markdown peuvent être pratique aussi, mais là le gros du travail est fait, c'est plus pour de petites modifs. Sinon pour convertir le docx en markdown j'ai utilisé un outil en ligne de commande: pandoc.
Bon après on peut aussi utiliser OneDrive aussi, mais si markdown semble déroutant au début on s'y fait vite et c'est utilisé partout, y compris ici. Et Editorial gère aussi le markdown pour info. Donc on doit pouvoir utiliser le couple Working Copy/Editorial sur iPad.
J'ai oublié de préciser: pour récupérer les données sur son ordi, il faut cloner son repo avec git. Le plus simple est d'utiliser la fonction "save to computer et use GitHub Desktop" (à coté de download .zip) sur GitHub.
Les mecs, c'est du chinois...
Le dimanche 3 avril 2016, flyingeek notifications@github.com a écrit :
J'ai oublié de préciser: pour récupérer les données sur son ordi, il faut
cloner son repo avec git. Le plus simple est d'utiliser la fonction "save
to computer et use GitHub Desktop" (à coté de download .zip) sur GitHub.—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#12 (comment)
- Si je comprends bien le pdf est créé en local par un programme ad-hoc.
- Juste pour le fun j'ai fait une petite modification de tuto.md, je tente de la pousser
Tu peux pousser autant que tu veux dans ton repo, c'est à la fin en faisant un pull request que ça me proposera de "merger" tes modifs. C'est pour ça qu'il vaut mieux travailler sur une branche dans ton repo: tu peux la supprimer, alors que si tu travailles sur la branche d'origine, il faut refaire un fork.
Envoyé de mon iPad
Le 3 avr. 2016 à 20:26, pgroell notifications@github.com a écrit :
- Si je comprends bien le pdf est créé en local par un programme ad-hoc.
- Juste pour le fun j'ai fait une petite modification de tuto.md, je tente de la pousser
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
@niklas777 https://help.github.com
Envoyé de mon iPad
Le 3 avr. 2016 à 20:00, niklas777 notifications@github.com a écrit :
Les mecs, c'est du chinois...
Le dimanche 3 avril 2016, flyingeek notifications@github.com a écrit :
J'ai oublié de préciser: pour récupérer les données sur son ordi, il faut
cloner son repo avec git. Le plus simple est d'utiliser la fonction "save
to computer et use GitHub Desktop" (à coté de download .zip) sur GitHub.—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#12 (comment)—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
Pour le pdf, oui je le crée pour l'instant à partir de Marked, mais ça doit pouvoir s'automatiser...
Working copy permet l'édition des fichiers .md directement, on peut même s'amuser à le coupler à Textastic, c'est pas de la preview en temps réel mais presque...
http://i.imgur.com/cyHcyYd.jpg
Bon je sais, Nicolas doit se dire mais pourquoi il s'embête y'a Word... :-)
Nicolas, je suis novice en matière de Markdown et Github, voici ce que j'ai compris.
1° Markdown est un système d'écriture qui permet de facilement mettre un texte en forme tout en écrivant (un peu comme le html, c'est du texte qui est mis en forme à l'affichage)
2° Pour Github c'est un peu plus complexe et l'apprentissage n'est pas simple (il y a des trux que je n'arrive pas encore à faire).
Pour te donner mon idée de la chose je vais utiliser une analogie avec Box que tu connais bien.
Sur Github tu peux stocker tes fichiers pour permettre de façon collaborative de les modifier, les améliorer.
Les fichiers d'Eric sont dans sa Box (le repository flyingeek/editolido), naturellement il n'y a que lui qui peut les modifier, c'est ses jouets.
Pour que je puisse les modifier il faut que je les copie dans ma Box, je vais donc créer une fork.
Dans ma box, je peux modifier les fichiers en ligne, il y a un bouton Edition sous forme de crayon en haut à droite (on verra plus tard comment on peut faire en local). Cette modification (ou commit en terme Github) ne modifie pas les fichiers d'Eric. Une fois satisfait de mes modifications je soumets un "pull request" à Eric, il accepte ou non la modification après avoir vu ce que j'ai fait. S'il accepte, il met à jour les fichiers de sa Box avec ceux de ma Box. Quand c'est lui que met à jour ses fichiers, il est indiqué dans mon repo que tje suis en retard sur lui et je peux me mettre à niveau (ça je n'ai pas encore bien saisi comment faire !!!!).
Et les branches : première utilisation, si je ne veux pas modifier les fichiers de base dans ma box mais faire des essais, je créé une branche de ces fichiers (c'est comme une fork mais c'est dans ma propre Box, une fois satisfait je peux faire un "pull" vers mes fichiers principaux (master) pour accepter les nouveautés). Deuxième utilisation découverte avec le tuto c'est la création d'une branche spécifique pour faire la documentation. Il y a peut être d'autres utilisations.
Enfin il est possible de travailler sur les fichiers en local sur un ordinateur et de synchroniser ensuite les modifications avec Github (pour cela utiliser GithubDesktop pour cloner le repo en local et faire les synchronisations). Githubdesktop est disponible en cliquant sur l'icone "Export" à coté du bouton DonwloadZip. (Je n'ai pas encore testé cette façon de procéder).
Voilà, je ne sais pas si c'est plus clair, et c'est sans doute très simplifié.
Pascal
Alors je vais préciser un chouilla.
Git c'est un système qui permet de collaborer à plusieurs sur un projet. Ça conserve un historique des commit. Le repo (l'endroit où sont stockés les fichiers) on peut le cloner, autant de fois qu'on veut. Pour le mettre à jour, on fait un pull si on veut mettre à jour les fichiers, un fetch si on veut mettre à jour l'historique seulement, et pour mettre à jour un autre repo on fait un push vers ce repo. GitHub est un repo comme un autre, il a des fonctions collaboratives et a introduit des choses comme le pull request, qui s'appelle merge dans le monde Git. On peut utiliser n'importe quel client git avec GitHub, ils proposent le leur GitHub desktop. Sur iPad je recommande Working Copy. Sur l'ordi on peut utiliser SourceTree ou GitHub Desktop, Pycharm mon éditeur Python embarque aussi des fonctions git.
GitHub héberge aujourd'hui la quasi totalité des projets open source.
Markdown permet de s'affranchir des balises html et est populaire pour rédiger les blogs, par contre la mise en page est sommaire. Markdown contrairement à docx s'integre bien dans un repo git, le fichier docx (un zip en fait) apparait comme binaire et il est impossible de suivre les modifs.
Envoyé de mon iPad
Le 4 avr. 2016 à 08:48, pgroell notifications@github.com a écrit :
Nicolas, je suis novice en matière de Markdown et Github, voici ce que j'ai compris.
1° Markdown est un système d'écriture qui permet de facilement mettre un texte en forme tout en écrivant (un peu comme le html, c'est du texte qui est mis en forme à l'affichage)
2° Pour Github c'est un peu plus complexe et l'apprentissage n'est pas simple (il y a des trux que je n'arrive pas encore à faire).
Pour te donner mon idée de la chose je vais utiliser une analogie avec Box que tu connais bien.
Sur Github tu peux stocker tes fichiers pour permettre de façon collaborative de les modifier, les améliorer.
Les fichiers d'Eric sont dans sa Box (le repository flyingeek/editolido), naturellement il n'y a que lui qui peut les modifier, c'est ses jouets.
Pour que je puisse les modifier il faut que je les copie dans ma Box, je vais donc créer une fork.
Dans ma box, je peux modifier les fichiers en ligne, il y a un bouton Edition sous forme de crayon en haut à droite (on verra plus tard comment on peut faire en local). Cette modification (ou commit en terme Github) ne modifie pas les fichiers d'Eric. Une fois satisfait de mes modifications je soumets un "pull request" à Eric, il accepte ou non la modification après avoir vu ce que j'ai fait. S'il accepte, il met à jour les fichiers de sa Box avec ceux de ma Box. Quand c'est lui que met à jour ses fichiers, il est indiqué dans mon repo que tje suis en retard sur lui et je peux me mettre à niveau (ça je n'ai pas encore bien saisi comment faire !!!!).
Et les branches : première utilisation, si je ne veux pas modifier les fichiers de base dans ma box mais faire des essais, je créé une branche de ces fichiers (c'est comme une fork mais c'est dans ma propre Box, une fois satisfait je peux faire un "pull" vers mes fichiers principaux (master) pour accepter les nouveautés). Deuxième utilisation découverte avec le tuto c'est la création d'une branche spécifique pour faire la documentation. Il y a peut être d'autres utilisations.
Enfin il est possible de travailler sur les fichiers en local sur un ordinateur et de synchroniser ensuite les modifications avec Github (pour cela utiliser GithubDesktop pour cloner le repo en local et faire les synchronisations). Githubdesktop est disponible en cliquant sur l'icone "Export" à coté du bouton DonwloadZip. (Je n'ai pas encore testé cette façon de procéder).
Voilà, je ne sais pas si c'est plus clair, et c'est sans doute très simplifié.
Pascal—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
Bon sinon nicolas, diffuse ton pdf, on verra plus tard
Le PDF est construit automatiquement à partir du fichier markdown lorsque l'on fait un commit sur la branche gh-pages
https://flyingeek.github.io/editolido/dist/gh-pages-tuto.pdf
Les liens des tutos vers les workflows sont à présent maintenus à jour sur Github.