Archives par mot-clé : making of

Documenter son travail de creative coding

La documentation d’un travail est une partie indispensable à tout projet. D’une part parce que la documentation d’un projet permet d’en retracer la genèse mais également parce qu’elle permet d’en retrouver les sources. Cela est d’autant plus utile dans le cadre d’un projet de creative coding.

Qui ne s’est jamais replongé dans un projet une semaine, un mois ou un an après en se posant l’une des questions suivantes :

  1. « Pourquoi avais-je fais ces choix graphiques ? »
  2. « Quelle était la problématique de départ? Quels étaient mes conclusions ? »
  3. « Que peut bien faire cette fonction ? Comment fonctionne-t-elle ? »

Autant de questions qui montrent l’importance d’un travail documenté.

Commenter son code

L’une des premières méthodes de documentation est sans aucun doute l’ajout de commentaires au code source du projet. Évidemment il est inutile de documenter la moindre ligne de code. Ainsi il est plus judicieux de documenter les algorithmes dont il sera important se de rappeler du fonctionnement.

L’exemple suivant montre une méthode commentée permettant de calculer la position d’un point sur un cercle.

Dans le cas de certaines fonctions nous utiliserons des commentaires plus détaillés permettant de retrouver le détail de l’algorithme. L’exemple suivant montre une fonction documentée permettant d’appliquer une rotation à un vecteur en 3 dimensions autour d’un vecteur servant d’axe.

Codes et attribution

Réutiliser des codes (entier ou par portions) trouvés sur internet est un bon exercice pratique cependant la réutilisation de code sans en avoir citer la source peut être considérée comme de la copie et du plagiat.

Le developpement a toujours impliqué l’utilisation de code provenant d’autres sources et nous avons la chance de profiter d’une communauté open source. Sans le partage de savoir de cette communauté celle-ci ne grandirait pas et votre travail ne verrait sans doute pas le jour. C’est la raison pour laquelle il est éthique de citer ses sources.

Tout comme vous citez les sources original dans vos travaux graphiques et écrits, vous devez citer l’ensemble des sources techniques afférant à votre projet tel que les auteurs des algorithmes ou outils incorporés à vos projets ou les documents de recherches et cours utilisés dans la création de votre projet.

Texte original de Scott Murray, Assistant Professor, Design Department of Art + Architecture, University of San Francisco.

Lorsque que vous utilisez une fonction ou un code réalisé par un autre développeur il est donc important d’en citer la source. Tout comme le commentaire de fonction, citer la source vous permet à vous et aux autres personnes qui auront accès à votre code de retrouver l’origine de l’algorithme, du programme et de sa documentation. Lorsque nous citons la provenance d’une méthode nous utiliserons la méthode suivante :

edit (26/11/2015) : Jonathan, collègue enseignant et co-créateur du site disruptions.fr, m’a fait remonter un commentaire en ce qui concerne l’importance de la citation du code d’autrui :

En ce qui concerne les citations du code d’autrui, en plus de l’aspect morale, il y a un côté bassement pragmatique – parfois le code ne fonctionne pas dans telle ou telle condition. D’avoir le lien accessible permet de vérifier s’il y a une mise à jour [tenant compte de votre problème] ou de dialoguer avec l’auteur pour déceler le problème.

Jonathan Munn

Documenter l’ensemble de son travail

ixd-documentation
Extrait de la documentation d’un projet d’installation interactive — Bonjour, interactive lab 2015

Si l’utilisation des commentaires permet à la fois de documenter son code et d’en citer les sources et références, ils ne permettent pas d’incorporer des images ou vidéos. Lors de la réalisation d’un projet il est important de tenir à jour une documentation complète permettant à tout instant de revenir en arrière sur la phase d’un projet. Cette documentation est destinée avant tout à nous même et aux collaborateurs du projet. Elle ne requiert donc pas de mise en forme particulière et peut tout à fait prendre la forme d’un document texte. Pour ma part mes documentations prennent la forme d’un document texte reprenant les points suivants :

  1. Concept
  2. Références
  3. Détail de l’idée
  4. Parcours utilisateur
  5. Questionnement :
    remise en cause ou points à explorer durant le projet
  6. Pour aller plus loin :
    Déclinaisons et évolutions possibles du projet
  7. Scénographie / format d’exploitation
  8. Cahier des charges techniques :
    Technologies envisagées, langages, librairies…
  9. Notes de développement :
    Note au jour le jour du développement effectué indiquant les problèmes rencontrés, les solutions envisagées, les sources et les références.

Une fois le projet terminé, le document pourra alors être remise en forme afin de réaliser le making of ou servir aux évolutions futur du projet.