Zenn
Closed19

執筆環境 選定過程: 非codeのtextをcode-likeに書く

GitHub
GitLab
Linear
#
novelwriter
Writerside
たとえば😄たとえば😄

先行事例

Summary

  • code-likeにする とは何を指す？
    • VSCode or GitHub Codespaces で書く
    • Git とGitHub を使う: バックアップ, バージョン管理, ブランチ管理, Issue管理などを行う
    • (GitLabを使う: アジャイル-likeに進めるのに適している)
  • code-likeにすると得られるもの
    • 執筆環境の拡張性
    • 校正, 表記揺れチェック の自動化
    • 辞書登録
    • エクスポート(ファイル変換)の簡便化
    • GitHub Issuesベースのtodo管理
      • ※最初は、Projectsは不要そう
    • PR/comment機能の活用による、1人/複数人でのレビューのしやすさ、指示出しのしやすさ
    • よく考えたら、複数version、ドラフトを書き出せるのも良いのかも
      • ブランチを複数生やせば、違う人間かのように、違う草稿が書けるな

List

  • 執筆環境をGitHubで構築する可能性
    • GitHub + IDE
      • (+GitHub Pages)
    • 得たもの
      • カスタマイズできるIDE、拡張性が担保される
      • Lintなどで校正, 表記揺れチェック, 辞書登録
      • ファイル変換(PDF)
        • e.g. Pandoc
  • GitHub上に構築した小説執筆環境について
  • Pull Request駆動で小説を開発する
    • PR駆動執筆、の意義
        1. 情報整理の場としての Pull Request

          • Pull Request を使っていくと、自ずとコミット履歴は分割・整理されていき、検索性が上がる。
            コミット履歴を直接確認するのではなく、当時作成した Pull Request から辿ればいいからだ。

        • Pull Request にはコメントを投稿する機能もあるから、それらを駆使すれば更にわかりやすく整理できる。
          私の場合は、自分の原稿に対するツッコミや悩んでいることを適当に投稿している。

        • 思いついた設定や伏線をコメントすることで、プロットへ転記する前に忘れてしまう悲劇を回避できる。

        • Pull Request はファイルごとに作成してもいいし、修正したい内容に応じて作成してもいい。
          Issue にするほどでもない課題でも、Pull Request のコメントなら気軽に書き込んでしまっていい。
          適当に作成して、適当に原稿を修正して、適当に情報を放り込んで、適当にマージする。
          マージしたあとも Pull Request 自体は閲覧できるから、適宜そこから必要な情報にアクセスすればよい。

  • コメントとコメントアウトは人間が読む文章を書くのにも便利だぞ 読書猿Classic: between / beyond readers
    • コメントアウトには、実利もあるし、精神衛生上の良さもある

      • 思考の跡をコメントとして残しながら書くといい。
        「ここはもっといい例は無いのか？」
        「前の章と矛盾してる？」
        「ここまで言うのは言い過ぎでは？」
        みたいな本音とか頭の中のぶつくさ（ツッコミ、自己添削、悲嘆など）をメタ・レベルの記述として、本文とは区別できるようにして残しておくのだ。

      • 最初から完成品を書こうとすると、これで本当にいいのかと、書く手が怖気づく。
        　何通りもの書き方を思いついても、どれにすればいいか考え出し決めきれないと手が止まる。そんな時はすべて書き出しておいて「あとで選ぶ」とコメントしておけばいい。そして結局選ばれないものは、いつの段階でもコメント扱いしておけば、最終稿では本文に残らない。
        　この、完全に消してしまうかわりに、コメント扱いすることで「ないことにする」のをコメントアウト（comment out）という。
        　逆にコメント扱いをやめ、やっぱり使うことにするのをアンコメント（uncomment）といったりもする。
        　コメントアウト／アンコメントをうまく使えば、迷って決め切れずに手が止まる事態を避けて、先に進むことができる。

      • アウトラインができている文章（たとえば論文系の書き物）だと、アウトラインをコメントの形で流し込んで、その間に本文を挿入しながら書いていくこともできる。
        　つまりアウトライン＝意図（何を書くべきか？なぜ書くべきか？）の覚え書き、と考えてコメントとして扱う訳だ。

    • #で始まるコメント行をすべて消して最終稿をつくるには(中略)「すべて置換」や「一括置換」（Replace All)すればいい

  • GitHub Codespaces で小説を書く時代
    • GitHub Codespacesを使おう
      • GitHub 上にローカルリポジトリも置いて、端末を問わず使い回す
  • GitHub Projects で日常のタスク管理を行う
    • メモ: Issue Templateが便利そう
  • GitHub IssuesとProjectsでチケット管理

    • Issuesを使うことで、要望や実装、不具合単位でチケットを作ることが出来るため、事前の議論や管理もしやすくなります。

    • Commit時のコメントにチケット番号（#1 等）を含めれば、該当Issusにリンクが生成されるため、変更を追うことも容易になります。

    • (Projectsは)Issuesの各チケットを横断的に管理できることを主な目的にしている

  • VScodeとGitHubで差分管理して小説を書こう | estampie
    • 性的な内容は上げられない、らしい
    • ブランチを生やす必要がない
      • が、やった方が良さそうな気がするな PR merge を儀式として使いたいし
  • 小説家はたぶん永久にGitを使えるようにならない | 高橋文樹.com | 文芸活動
    • 割に合わないよ(むずいよ)
  • 小説Git 1：はじめに – Taiyo Fujii, writing
  • 同人小説にGitなんていらねえ！　でもいる - 神原のブログ
  • 【令和4年最新版】文章制作環境 シンプル Markdown 高いカスタマイズ性 Gitとの連動でき - 神原のブログ
    • VSCodeとObsidianで、同じフォルダー/ファイルを扱える、のが良い
      • Why Obsidian?
        • アウトライナーとして、VSCodeより使いやすい
  • ぼくのかんがえたさいきょうの小説執筆環境
  • 世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ #Git - Qiita

    • 『あの表現、捨てたけどここで再利用したい！』

      • 小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない！」となってバッサリ切り捨てることがあります。
        そして後になって「あ、ここはあの時の文章が使えるのでは？」という時が必ず来ます。1割くらいの確率ですが。
        そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
        でも Git なら大丈夫。全部記録しているからね。

        • あるか？
          • これまではないけど、まあでも、スパッと思い切りよく案を捨てれるのは良いattitudeかも

    • 今日は何文字進んだ、っていう進捗管理もできる

    • レビュー受けやすくなるのはいいな(相手がGitHub使いの場合だが)
  • 文章に関わる全ての人のための Git & GitHub 入門 1-1「Git と GitHub を使うメリット」 #Git - Qiita

    • GitHub を使うと
      変更点に関して、必要に応じた濃さで議論できる。
      査読者は片っ端から修正案を挙げて、筆者は片っ端から案を検討できる。
      互いの待ち時間が圧倒的に圧縮された結果、校正校閲が爆速になる。
      議論の内容が原稿ファイルに書き込まれることはない。

  • 文章に関わる全ての人のための Git & GitHub 入門 1-2「コミットを積み上げる」 #Git - Qiita
  • 文章に関わる全ての人のための Git & GitHub 入門 1-3「コミットを理解して活用する」 #Git - Qiita
  • GitHub でテキスト管理を行う GaaTS(GitHub as a Text Storage) について #GitHub - Qiita
    • GitHub のどこにテキストを格納すればいいか
      • まあRepoだな
      • Gistも一度試しても良いかも
  • k16's note: 執筆・編集のためのGit（GitHub）ワークフローを考えてみた

    • 経験上、文章の執筆・編集では作業内容ごとにコミットを整理したりブランチを切ったりするのが難しいなあと感じる場面がとてもよくあります。 文章の修正を局所的で互いに独立したコミットに収めることができず、コミットどうしが密に結合したり、一見すると巨大すぎるような修正コミットが発生したり、他の人の作業と競合したりしがちなのです。

    • 次のようなポリシーで執筆・編集をするのがよさそうだというのが現時点での結論です。

      • 「じっくり読まなければ何となくいい感じ」まで達している原稿は、これから入れる修正の意図を明らかにしたいので、issueで議論してからコミットしたり、ブランチを切ってPull Requestにしたりする

      • それ以前の段階では、用字用語統一、誤記修正、タグ追加などの作業はブルドーザーによる整形作業だと割り切り、細かく管理するのはあきらめる。経験上、どのみちrevertやrebaseが不可能な作業なので徒労に終わる。信頼できる担当者どうしで作業をしているなら、見つけた人がmasterに随時pushするのが、他の作業との競合を回避するためにも効率的

      • それ以前の段階における局所的な文章の修正は、「じっくり読まなければ何となくいい感じ」ゾーンまではissueやコメントに留める。それ以降はPull Requestにする

      • それ以前の段階における節以上の範囲におよぶ内容上の修正は、作業範囲を隔離するためのブランチを切って作業する（このブランチではmasterにおける用字用語統一などの修正を適宜取り込みながら作業をする。Pull Requestにしてからマージしてもよいし、手動でマージしてもよい）

以前検討した際(2020ごろ)のおぼろげな記憶

  • code-likeな執筆環境を検討した理由(おぼろげな記憶)
    • 既存ツールに不満があった
      • 当時利用していたツールと、そのワークフロー
          1. Roam Researchに書く
          • v1とかv2とか、雰囲気で分割して書き直していた
            • 個々のversionはある程度の完成稿を指し、これをWord経由でpdfに出力して周囲のレビューを得ていた
            • 他者や自分自身のレビューによってtodoを洗い出し、次のversionでそれらを適用(実装)するという流れがあった
              • ※todoは思いつきやふわっとした方向性レベルのものも多く、全てが次のversionに反映されるとは限らなかった
          1. versionごとに、Wordにペーストして書式を整え、pdfでエクスポートする
          1. Finderで/Dropboxで/GoodNotesで管理する
            • 超テキトーだったので、時間を置いた今見返すと、どれが最新版かわからなかったりもする。
      • 既存ツールの良さ
        • それなりにサクサク動作する
        • メモりやすい
        • todoを簡単に切り出せる
        • Block Reference(同期引用)が使える
      • 既存ツールへの不満の内容
        • どこに最新版があるかわからない
          • Roam Researchに書きかけの原稿があるのか？pdfでエクスポートしたのか？
        • Roam Researchが異様に重くなる
          • 長文を書き連ねていくと動作がもっさりする
        • todoやメモを見失う
          • このtodoって今回のversionで達成できてる？できてない？わからん！
          • なんかxxをxxしたいみたいなのあった気がするけどどこに書いたっけそのメモ？
        • versionからversionへ、Linearに進んでいかない感触。無駄な往復が多い
          • 全てのversionの間であっちこっち行ったり来たるするのは大事なのだが、あるversionから次のversionへは、勢いと切り捨てをもって進むようにしたい
        • 進捗が実感しにくい
          • 今全体のどこをやっている？→把握に時間がかかる
          • 今日どれくらい進んだ？→わからない
          • 正しい方向に適切なスピードで進めている？いない？→わからない
  • 検討した結果、declineした理由(おぼろげな記憶)
    • 細かいdiff管理は(日本語だから?)機能しなかった記憶がある
    • コミットの単位とか節目とかコミットメッセージとか考えたくねえ！と思ってたような気がするな
    • ファイルの分割やその順番の編集が面倒だった気がする
      • e.g. このパラグラフ（a file）を冒頭に持ってこよう、みたいなのをどうやればいいのか
        • codeのfilesにおいて「順序」という概念がないため
          • メモ: じゃあ「構成」というファイルをメタに作れば良い気がするな。それじゃあかんのか？
    • 労力が見合わない
      • ファイルとパラグラフ/セクションの分割が面倒だったような？
    • 各ファイルにコメントでメモっていっても、後で拾えなかったような気がする
たとえば😄たとえば😄

肌感/見立て

  • セクション/パラグラフごとにファイルを分割することで、視野に入る情報を制限できるので、切断/有限化(cf. 千葉雅也)がしやすくなりそうではある
  • チケットベースで執筆(開発)するようになれば、受け入れ条件も明示的になり、PRを厳しくレビューできるようになるので、完成稿前のドラフト作成が捗りそうな気もする
たとえば😄たとえば😄

あーなんか、小説をcode-likeに書くべきじゃねえわと思ったような気がする
コードは部分が部分として機能を持つけれど、小説は部分が部分単体としてのみならず全体の中でも意味を発揮するので、ファイル分割という手法と相性が悪いと思った記憶があるな

逆に、論文はcode-likeに書くのが良いかも

たとえば😄たとえば😄

論文をcode-likeに書く

示唆

  • 可能
  • 便利

参考

たとえば😄たとえば😄

日本語で(行単位でなく)単語/文字単位でdiffを取る方法

結論

  • --word-diff-regexoptionを使う

参考

git diff --word-diff-regex=$'[^\x80-\xbf][\x80-\xbf]*' --word-diff=color

git diff --word-diff-regex=$'[^\x80-\xbf][\x80-\xbf]*' --word-diff=color
  • コレを ~/.bashrc にエイリアスとして書いておけば使いやすくなる。
  • 日本語の文字単位diffオプションをgit aliasに設定する - 果樹園

    • git aliasとして .gitconfig に次のように設定し git diffr や git showr <commit> のように簡単に実行したかったが、この書き方では正規表現が問題になる

    • git aliasなんだから外部化してしまえばええやん

      • git aliasは ! を先頭につける書き方をすると任意の外部コマンドやシェルスクリプトを実行できるので、やりたいことをシェルスクリプトにしてそれを呼び出す様にしてしまえばいい

  • 橋本商会 » 文字単位でgit diff
たとえば😄たとえば😄
  • 1st draftは、今まで通り、紙かRoam Researchが良さそう
    • 勢い、余計なことを気にせずに済むこと、が大事なので
    • 構成が未確定なので
  • ある段階から、開発likeに、チケット駆動で執筆するのが良さそう
    • ある段階とは？
      • 骨子が固まったら
        • どうやって私はそれを知りうるのか？
          • ？
たとえば😄たとえば😄

論文や小説でブランチ戦略をどうするか、は、チーム開発とも、個人開発とも、異なるベストなやり方がありそう

たとえば😄たとえば😄

今回検討しない(見送る)可能性の枝

Why

  • 少人数〜大人数開発には良いのかも。試したい
  • 完全に1人だと、too muchかもしれないと思った
  • 非tech projectだと、too muchかもしれないと思った
たとえば😄たとえば😄

GitLab? GitHub?

結論

  • GitHubでいく

理由

影響

無駄話

  • GitLabはEpicが確認しにくい
    • (そのようなUIが正しいのかもしれないが)
    • EpicはGroupに属する
    • IssueはProject(GitHubでいうrepository)に属する
    • Project内にいる時に、Epicを見にいくのに最低でも2-3の遷移が必要だった
      • 私がアホなだけかも
たとえば😄たとえば😄

VSCode設定

やったこと

text環境整備

markdown環境整備

  • (略)
  • .md.txtで、novel-writerを使いつつ、markdown関係の記法も使えるようにした
    • 以下スレを参照:

困っていること

  • *.md.txtがnovelとして認識されているのかいないのか……？
    • ※markdownとして認識されるようにしたのは私なのでトラブルは私の責任で、Taiyo Fujii氏のせいでも読書猿氏のせいでもない
    • novel-writerのほとんどの機能は使えている(ありがたい)
    • ただ、前後のシーンのナビゲーターだけが有効にならない
      • *.txtでは有効になる
たとえば😄たとえば😄

'setting.json'ファイル内のnovelのところ編集したらよいとかなんだろうか？わからんけど

たとえば😄たとえば😄
  • novel-writerに準拠し、書く対象のフォルダは以下のようになる
    • メタなドキュメント(仕様書的な)
      • .txt or .md( or .md.txt)
    • 本文 ←文字カウントに使用
      • .txt
        • novel扱いになる
  • 上記は小説でも論文でも、たいていの書き物で使える
  • 改善の余地がありそうなところ
    • 本文の構成を、フォルダ/ファイルのディレクトリ構造で指定することになる
      • これが意味するところ:
        • ファイル内で、markdownのheading(h1, h2……)で構成を作ることができない/しない
          • 良し悪しがある
        • ≒ビートシート/全体の構成は、常にディレクトリ構造を閲覧することで確認する
          • ビートシート = ビート < シーン < シークエンス < 幕
      • 生まれる問い/前提:
        • Q. ファイルをどの単位で区切るか？(を、事前にある程度決めておくことが推奨される)
          • e.g.
            • ファイルをシーンに対応する形で区切り、ビートはそのファイル内でmarkdown headingで区切る、ということができない/しない
              • Q. では、ビートごとにファイルを区切るのか？
              • ≒ ナビゲータに従い、当該ビートと次のビートの冒頭だけを見ながら書くのか？
                • さすがに細かすぎる気もするし、
                • 逆に良い気もするな
              • or シーンごとにファイルを区切り、ビートは雰囲気で管理するのか？
                • 良い気もするし、悪い気もする
                  • ビート個々の質は下がるけど流れは良さそう
たとえば😄たとえば😄

青空文庫記法、めんどくせえな
とは思いつつ、これが業界標準なら早めに慣れておこう

たとえば😄たとえば😄

書いてみた。以下を用いて執筆することは可能っぽい

  • Git
  • GitHub
  • VSCode
    • novel-writerなど
  • (Linearなど、プラクティスを自然に実施するためのツール)

ツールに慣れたら、合理性の検証に移るかな

たとえば😄たとえば😄

markdownとnovel(novel-writer)を併用することは可能か？

前提

  • MacOS Ventura 13.6.3
  • VSCode 1.87.2

示唆

  • 無理っぽいので大人しく、本文: .txt(novelとして認識される), ドキュメント: .mdでいく

検証

1. .md.txtはmarkdownです式

結論

  • 惜しい
    • 前後のシーンのナビゲータが有効にならない
      • そもそも何も出ない

やったこと

  • 設定 > Files: Associationsにて、項目*.md.txt, 値markdownを設定する as below

起こったこと

  • 全ての.md.txtファイルが以下のように挙動する
    • markdown記法が使える
    • markdown用のVSCode extensionが有効に作用する
    • VSCode右下「言語モードの選択」にはmarkdownと表示される
    • novel-writerのほとんどの機能は有効になっている(ように見える)
      • 左サイドバー「ノベルライター」から開ける「ノベルライター: 原稿ツリー」に表示され、文字数もカウントされる
      • 下部バーにも文字数カウントが行われている
      • PDFプレビューも縦書きプレビューもできる
    • ただ、novel-writerの一部機能が有効にならない
        1. 形態素の認識
          • 今回はnice-to-haveだったので、これはスルー
        1. 前後のシーンのナビゲータが出ない
          • 残念😭
          • ※同じ環境下で.txtファイルは、もちろん原稿ツリーにも表示され、かつ前後のシーンのナビゲータが出ていたし、正しく動作していた(後述するようなバグらしきものは出なかった)

2. .mdはnovelです式

結論

  • 無意味

やったこと

  • 設定 > Files: Associationsにて、項目*.md, 値novelを設定する

起こったこと

  • 全ての.mdファイルが以下のように挙動する
    • VSCode右下「言語モードの選択」にはnovelと表示される
    • 各ファイルのiconはmarkdownになっている
      -ファイル内で、markdown記法は使えない
    • markdown用のVSCode extensionが有効に作用しない
    • 前後のシーンのナビゲータは出るが、誤っている
      • レポジトリ内の先頭のファイルが出ている
        • (バグ？)
    • 左サイドバー「ノベルライター」から開ける「ノベルライター: 原稿ツリー」には、.mdファイルは表示されない
      • ので、文字数カウントもできない
たとえば😄たとえば😄

Linear.appと紐づけて、「このcycleでやったこと」を振り返れるようにしておくと良さそうだな
できればその中身も、Linear.appやGitHubの中ではなく、ドキュメントとして閲覧できるようにしたいが…
イミュータブルドキュメントモデルをstrictにやってみるか？

このスクラップは29日前にクローズされました