「動かして学ぶ!Rust入門」の執筆
Zennで公開している「Rust入門」が「動かして学ぶ!Rust入門」として書籍化されました.ここでは、書籍の執筆について色々と書くことにしました.
はじめに
大変嬉しいことにZennで公開している「Rust入門」を書籍化することになりました.「動かして学ぶ!Rust入門」という名前で 2023年4月24日発売です.
動かして学ぶ!Rust入門 | Amazon動かして学ぶ!Rust入門
動かして学ぶ!Rust入門 | SE Book動かして学ぶ!Rust入門
ここでは、執筆についてやったことや思ったことなどをここにまとめておきます.
出版社からは許可をもらっています.
執筆依頼
まず、はじめに翔泳社の編集者さんから執筆依頼のメールが届きました.書籍執筆は私の1つの夢ではあったので、快諾の連絡をして打合せや構成案の提出などをして契約しました.その後、執筆期間に入ります.
実際の執筆
私のスタイルとして、最初に必要な情報をとにかく集 めます.今回は Notion を使いました.また、コードなどの参考になりそうなものはプロジェクトフォルダを作成してそこにまとめていました.執筆前に構成案を作成するのですが、その構成に合わせて資料をすべて集めます.資料を集めて、「これで書ける」と感じたら執筆を開始します.これは今回の執筆よりも前からやっている方法で今回も変わりませんでした.ちなみに、今回の執筆でそう思ったタイミングは、原稿締め切り1カ月を切っていたときです.実際に原稿はギリギリ間に合ったのですが、全くこのやり方はオススメしません.とはいえ、このやり方そのものは決して悪い方法ではなく、もっと時間に余裕を持たせようというお話です.構成を考えて調べながら書くことも可能とは思いますが、それではいつ書き終わるかが全く予想できません.特に、調べながら書く場合はあるトピックに予定以上に時間がかかることがあると破綻してしまいます.ですので、最初に資料集めをした方が書きやすいと感じています.先に全て調べなくとも、ある程度は事前にすべてチェックしておいたほうがいいです.
今回の執筆では、Markdownで原稿を書き、git で管理していました.また、mdbook を使用しています.mdbook は最初から使用することを決めていました.少なくとも今は rust に関して執筆するなら mdbook がオススメです.なにより、ブラウザ上ですぐにコードを実行して確認することができるのが便利です.複雑なコードは厳しいですが、簡単なコードなら十分です.また、vscode とも相性がいいです.SUMMARY.md から各ファイルにすぐジャンプできます.
今回の執筆は Zenn で公開している「Rust入門」を加筆したものになっています.この「Rust入門」は、もともと「Rustではじめるレイトレーシング入門」から Rust の解説部分を抜き出したものです.また、「Rustではじめるレイトレーシング入門」も「レイトレーシング入門」のC++部分をRustに書き直し、また、Rustの解説を追加したものになっています.構成段階で、編集者さんとお話したときにレイトレーシングのサンプル部分を使ってもいいか確認して入れていました.今回、A5サイズの書籍ということで手元にあった書籍を調べて行数や1行に表示する文字数を調べました.それぞれ、ばらばらで統一されていなかったのが意外で印象的でした.同じ出版社でもです.なので平均値(横38文字、縦33行)を算出して「Rust入門」の記事をTeXを使ってA5サイズで出力したところ約80ページしかなりませんでした.最初は250ページぐらいを想定とのことでしたので、かなり加筆しなければならないとわかっていました.サンプルとしてレイトレを追加したとしてもです.また、ボリューム的にも250ページはちょっと薄いかなと思ったので、300~350ページを目標としました.この時に「計画書」という資料を私の方で作って具体的にどの部分をどれくらいのページ数にするか適当に決めています.この資料は依頼されたわけではなく、勝手に私が作ったものです.実際にサンプルのページ数を除けば、このときの計画通りになったとちょっと驚いています.
構成案はまず編集者さんが提示してくれますので、それをもとに作ります.私の場合、20日間の期間がありました.ギリギリまで使って考えて構成し提出しました.これも多少「節」の移動や統合はあったものの、ほぼこのときの構成通りに執筆しています.
加筆内容としては、まずコードの量を増やしました.タイトルにもある通り「動かして学ぶ」シリーズなので、コード例を多く提示しました.「Rustの文法と機能」と「アプリケーションの開発」では、それぞれ250個、225個のリスト(コード)があります.同じ「動かして学ぶ」シリーズ(今回のはNextOneシリーズということで少し違います)で「Pythonで動かして学ぶ!機械学習の教科書」という書籍があって所持しているのですが、本当に手を動かして学べる良著だったので、参考にさせてもらいました.とはいっても、Rust入門の方はコード例を多くしているのであって、別に動かす必要はないので少し違います. 次に、「アプリケーションの開発」では単語推理ゲームとレイトレーシングを書きました.単語推理ゲームはWordleとして有名ですし、レイトレーシングはこれもまた有名なコーネルボックスのプログラムになっています.レイトレーシングは既に書いてあるのでそれの調整で済みました.いくつか間違いが見つかったのでいずれPDF版にも反映させようと思います.単語推理ゲーム はicedクレートを使ったサンプルです.単語推理ゲームのロジック部分は参考にしたコードはあるのですが、それはCLIなのでGUI版を作成しました.icedクレートと注目していた tauri を使うか少し迷ったのですが、tauri はRust以外にも説明しなければいけないことが多いので、Rustだけで完結するicedクレートにしました.これは、1日で書き上げました(もちろん事前に調べていたから).ただ、説明が不十分だったり、書き方が他の部分と比べて手抜きすぎて、ここは赤字が多かったです.
執筆期間は土日、平日の夜などはフルに執筆に使っていました.体調を少しでも崩していたらやばかったですね.
当初は250ページ、目標は300ページとしていましたが、最終的には440ページ近くになりました(書籍の詳細を見るともっと多いですが、それは目次や索引などが含まれています).何とかなるものだなー.赤字などでいろいろ説明不足な部分も指摘されたのですが、これ以上ページ数を増やしたくなかったので、結構省いています.見本誌を頂いて中を見たときは、意外にスカスカだなと思いました.これはコードを追加した影響だと思います.いい感じに読みやすくなっているのかもしれません.
締め切りはどれも間に合わせました.スケジュール通りに対応できたと思います.実は予定よりもスケジュールは伸びているのですが、少なくとも私が原因ではないと思っています(まあ、原稿がまずかったのかもしれません).
監査
今回は監査を付けていません .これは編集者さんに手配してもらったり、自分でお願いすることも出来るそうです.まあ、今回の件についてはお願いできる人が思いつきませんでした.
校正・検証
原稿を書き終えてから、校正やら検証が始まります.検証は原稿に書かれているプログラムや画面が正しいかどうかチェックしてくれます.これは編集者さんの方で手配してくれます.原稿をもとに組版したものが送られてくるので、検証報告を確認しながら、チェックをして赤字という形で訂正指示をします.このとき、校正記号を知らなかったので、最初は私なりに描きこんでいたのですが、ちょっと改行問題(後述)が大きかったので、もっと簡単に表せないかと思い、校正記号について調べました(校正のルールと必ず覚えておくべき校正記号一覧 | 凸版).まさに知りたかったことだったので、特に改行や字下げなど利用しました.それ以外はむしろ面倒だったので使っていません.というのも手書きならまだしもPDFでのやり取りだったので、描画ツールを使って描くにはあまりにも面倒すぎます.専用のツールがあるなら楽なんですけどね.
特に校正で大変だったのが、改行問題です.これは Markdown に関係してきます.DocusaurusやZennなどMarkdown形式でドキュメントを書いた場合、改行をどのように扱うかはそれぞれのレンダリング処理に依存します.多くはMarkdownファイルで改行 してすぐに文章を書いている場合、改行が間に入りません.mdbookもそうです.しかし、原稿として提出した場合、改行はそのまま改行として処理されます.ですので、mdbookでビルドして確認したものと組版されたものとでは結構違っていました.組版されたものは想定外の改行が多く、その度に字下げ処理されてしまい、この校正指示が大変でした(だから校正記号を調べました).これが改行問題です.他の書籍でも結構無駄に改行が入っているものを見かけます.Markdownで書いているのかなと思ってしまいます.これは厄介な問題で、それなら改行しなければいいのではと思うかもしれませんが、日本語を含めた文書でgit管理する場合、行単位での比較になりがちなので、1行にまとめてしまうとわかりづらくなってしまいます.これに関しては結局のところ、Markdown側の改行を消すしかないとの結論に今はなっています.diffの問題や執筆も1行にまとめることで書きづらくなってしまいますけどね.ではどう対応したらいいかということですが、考えられる方法として執筆時は改行あり、提出時は改行なしに変換するツールを作る方法があります.フォーマッタのようなものです.
校正に関しては原稿と一緒にgitに記録して管理していました.特に必要はなかったのですが、基本1つの校正指示に1コミットという方法を使ってやっていたのですが、あまりにも多かったので、後半は少しまとめてコミットしていたこともあります.それでも、校了になるまでに、1331回コミットしていました.