Merci beaucoup d’avoir pris le temps de lire l’article et d’écrire un retour aussi détaillé. C’est exactement pour recevoir ce genre de remarques que je l’ai publié, donc ça me fait vraiment plaisir. :-)
Tu as tout à fait raison pour le dépôt GitHub en anglais. Jusqu’à la publication, je n’avais pas encore complètement tranché entre l’anglais, pour toucher davantage de monde, et le français, qui correspond beaucoup mieux à ce que j’ai envie de faire. C’est finalement en terminant l’article que j’ai fait mon choix : la série sera en français.
Je lis l’anglais technique sans problème, mais je préfère lire et écrire en français. J’ai aussi envie de travailler mon style et de montrer qu’on peut produire de la documentation technique précise et agréable à lire dans notre langue. J’ai simplement oublié que le dépôt était resté en anglais après cette décision. Je vais donc le repasser en français. Merci de m’avoir signalé cette incohérence.
Pour la longueur, tu mets aussi le doigt sur quelque chose avec lequel j’ai beaucoup hésité. Je voulais que ce premier article arrive à un résultat concret, même modeste, et j’avais peur qu’en le découpant trop il s’arrête avant d’avoir produit quoi que ce soit d’intéressant. Mais, à l’arrivée, j’ai empilé beaucoup de sujets : extensions et formats, signatures binaires, ISO 9660, Joliet, PlayStation 3, commandes shell, puis Haskell. Il y a en plus une double manipulation, puisque je mène d’abord l’enquête avec le shell avant de la refaire dans GHCi.
Le passage par ISO 9660 avait une raison : avant d’atteindre les fichiers propres au jeu, il faut comprendre les couches extérieures de l’image qui permettent de les retrouver. Ce n’est donc pas le sujet final du projet, mais une étape vers les données de Demon’s Souls. Si cela ressemble à un long détour, c’est que je ne l’ai probablement pas assez bien expliqué.
Ta remarque sur la reproductibilité est également très juste. Les commandes et leurs sorties permettent de voir où se trouvent les informations et de refaire le raisonnement sur une autre image. Mais elles ne permettent pas de rejouer l’expérience à l’identique ni de modifier mes données, puisque je ne peux pas redistribuer l’image du jeu.
Je pourrais utiliser une image ISO libre pour cet article, mais ce ne serait pas vraiment cohérent avec la suite : je vais rapidement travailler sur des données issues des jeux FromSoftware que je ne pourrai pas davantage redistribuer. Je préfère donc assumer ce corpus plutôt que de donner provisoirement une fausse impression de reproductibilité.
En revanche, ton commentaire me donne une idée de découpage qui me paraît bien meilleure : faire les articles généraux (lecture binaire, offsets, endianness, description des structures, etc.) avec des données synthétiques ou librement accessibles, afin qu’ils soient entièrement reproductibles. Puis publier entre eux des articles plus courts et plus pratiques montrant comment appliquer ces notions à mes exemplaires de Demon’s Souls, Dark Souls ou Dark Souls II.
Je crois que mon premier article a essayé d’être ces deux choses à la fois, ce qui explique sans doute sa longueur. Pour la suite, je vais essayer de mieux séparer les fondations générales, reproductibles et pédagogiques, des études de cas concrètes sur les jeux.
Enfin, Haskell est un choix complètement assumé : c’est un langage que j’aime beaucoup et que j’ai envie d’approfondir. Mais cela ne veut pas dire qu’il est immédiatement accessible à tout le monde. Je dois mieux annoncer les prérequis et éviter de demander au même article d’introduire à la fois Haskell, l’analyse binaire et les particularités d’une image PlayStation 3.
Merci encore pour ton retour. Il ne m’aide pas seulement à corriger quelques détails : il me donne une structure beaucoup plus claire pour toute la suite de la série. :-)
[^] # Re: ok, mais pourquoi ISO
Posté par s[e]th & h[o]lth (site web personnel) . En réponse au journal D’une image nommée .iso à un premier probe en Haskell. Évalué à 5 (+4/-0).
Merci beaucoup d’avoir pris le temps de lire l’article et d’écrire un retour aussi détaillé. C’est exactement pour recevoir ce genre de remarques que je l’ai publié, donc ça me fait vraiment plaisir. :-)
Tu as tout à fait raison pour le dépôt GitHub en anglais. Jusqu’à la publication, je n’avais pas encore complètement tranché entre l’anglais, pour toucher davantage de monde, et le français, qui correspond beaucoup mieux à ce que j’ai envie de faire. C’est finalement en terminant l’article que j’ai fait mon choix : la série sera en français.
Je lis l’anglais technique sans problème, mais je préfère lire et écrire en français. J’ai aussi envie de travailler mon style et de montrer qu’on peut produire de la documentation technique précise et agréable à lire dans notre langue. J’ai simplement oublié que le dépôt était resté en anglais après cette décision. Je vais donc le repasser en français. Merci de m’avoir signalé cette incohérence.
Pour la longueur, tu mets aussi le doigt sur quelque chose avec lequel j’ai beaucoup hésité. Je voulais que ce premier article arrive à un résultat concret, même modeste, et j’avais peur qu’en le découpant trop il s’arrête avant d’avoir produit quoi que ce soit d’intéressant. Mais, à l’arrivée, j’ai empilé beaucoup de sujets : extensions et formats, signatures binaires, ISO 9660, Joliet, PlayStation 3, commandes shell, puis Haskell. Il y a en plus une double manipulation, puisque je mène d’abord l’enquête avec le shell avant de la refaire dans GHCi.
Le passage par ISO 9660 avait une raison : avant d’atteindre les fichiers propres au jeu, il faut comprendre les couches extérieures de l’image qui permettent de les retrouver. Ce n’est donc pas le sujet final du projet, mais une étape vers les données de Demon’s Souls. Si cela ressemble à un long détour, c’est que je ne l’ai probablement pas assez bien expliqué.
Ta remarque sur la reproductibilité est également très juste. Les commandes et leurs sorties permettent de voir où se trouvent les informations et de refaire le raisonnement sur une autre image. Mais elles ne permettent pas de rejouer l’expérience à l’identique ni de modifier mes données, puisque je ne peux pas redistribuer l’image du jeu.
Je pourrais utiliser une image ISO libre pour cet article, mais ce ne serait pas vraiment cohérent avec la suite : je vais rapidement travailler sur des données issues des jeux FromSoftware que je ne pourrai pas davantage redistribuer. Je préfère donc assumer ce corpus plutôt que de donner provisoirement une fausse impression de reproductibilité.
En revanche, ton commentaire me donne une idée de découpage qui me paraît bien meilleure : faire les articles généraux (lecture binaire, offsets, endianness, description des structures, etc.) avec des données synthétiques ou librement accessibles, afin qu’ils soient entièrement reproductibles. Puis publier entre eux des articles plus courts et plus pratiques montrant comment appliquer ces notions à mes exemplaires de Demon’s Souls, Dark Souls ou Dark Souls II.
Je crois que mon premier article a essayé d’être ces deux choses à la fois, ce qui explique sans doute sa longueur. Pour la suite, je vais essayer de mieux séparer les fondations générales, reproductibles et pédagogiques, des études de cas concrètes sur les jeux.
Enfin, Haskell est un choix complètement assumé : c’est un langage que j’aime beaucoup et que j’ai envie d’approfondir. Mais cela ne veut pas dire qu’il est immédiatement accessible à tout le monde. Je dois mieux annoncer les prérequis et éviter de demander au même article d’introduire à la fois Haskell, l’analyse binaire et les particularités d’une image PlayStation 3.
Merci encore pour ton retour. Il ne m’aide pas seulement à corriger quelques détails : il me donne une structure beaucoup plus claire pour toute la suite de la série. :-)