Amazon Direct Publishing（KDP）で『フェアトレードは甘くない』という本を共著で出版した（https://www.amazon.co.jp/dp/B0CCLM8SFP）。 当初はKindle版だけだったが、11月16日、紙のバージョンも入手できるようになった。

当初、出版社からの出版を念頭にいくつかの出版社に当たってみたが、芳しい返事がなかった。どうしたものかと共著者と話していて、今更、出版社経由じゃなくてもいいんでは？ということになった。

もともと原稿をMarkdownで執筆していたこともあり、このままKDPで出版すればすごく楽なのでは？とKDPの利用を決断した。

昔と違って、今は出版社の格というものはそんなにない気がする。むしろ検索でどれだけひっかかるかのほうが重要だ。

個人のマーケティング努力によって、販売数は稼げるということだ。

なお、具体的な出版手順は、同僚の太田氏が全部やってくれた。

三人での執筆となるとKDPも共同アカウントが必要なのか？振込口座の登録が必要だが三人共同の口座というのは作成できるのか？などと逡巡しているうちに、さっさと自分のアカウントで手続きを済ませてくれた。

この本の原稿はMarkdownで作成した。Githubにリポジトリを作成して、共同で編集していくスタイルだ。

基本的には各自ブランチを作成して執筆して、僕がmasterにマージすることにした。ただし、みんなが不慣れなこともあり、変更の競合とか、誰がどの時点のmasterからブランチを作成しているのかとか、口頭で確認しながら作業したりした。

一度は、変更が消えてしまって、手作業で復元、なんてこともやった。

Gitを使っているので、変更が消えることはないはずで、修正したものが消えてしまっても復元が可能なはずなのだが、その辺も不慣れすぎて分からなかった。

ただ、Gitを使えば、ファイル名を「原稿V2.321203坂田修正1204太田コメント」的なものにしなくてもよいことはわかった。 Gitの中で、同じファイルにお互い変更を繰り返していけば、それだけでバージョン管理ができてしまう。

Wordなどでもバージョン管理はできるのだが、あまり使っている人がいない。

文書を手書きではなくコンピュータを使うことのメリットとして、バージョン管理はもっと注目されてよい。

本の原稿はMarkdownで作成した。Markdownというのは、テキストファイルに見出しなどに一定の適宜記号を使用することで、文章構造を表現できるものだ。

文章を書くなら、Wordでも良かったのかもしれないが、せっかくなので新しいことをやろうということで、Markdownでの執筆に踏み切った。共著者の二人も分析の際にはR Markdownを使っていたので、それほど抵抗はなかったようだ。

図表番号が自動でつかないなどの問題はあったものの、原稿ファイルがとても軽いのはよかった。ファイルを開くのも保存するのも一瞬だ。

なにより執筆を使い慣れたエディタで行えるのはありがたい。僕はEmacsだし、二人の共著者はVisual Studio Codeを使用している。それぞれ好きなエディタを使えるから、相手に合わせる必要もない。おまけに僕のWordはしばらくつかっているとなぜか保存できなくなったり日本語変換できなくなったりする。

作家の懐具合というのは外から見るとよくわからない。

僕らのような並の研究者は本を書いて儲けるということはあまり期待していない。印税率が何％なのかすら知らない。だいたい印刷部数が2000部とかなので、本を一冊書いて印税が10％と考えると20万円入ってくるかどうかというところだと思う。本を書く労力を考えると時給いくらなんだ？と言いたくなる。だから、お金のことを考えること自体を放棄している。

それでも20万円だ。もし出版で20万円入ってきたらどうしようか？３人で執筆したから３で割って一人７万円ぐらいか。

KDPのばあい、売上から著者に支払われる金額はかなり高い（検索すると、35％ぐらいみたい）。そのため、販売部数が少なくても多少の売上にはなるかもしれない。

ちょっぴり期待してしまうけれど、せっかくフェアトレードをテーマに書いたのだから、フェアトレードコミュニティに貢献してみたい。フェアトレードはビジネスだと言われるけれど、それはフェアトレードでモノを売っている人だけだ。フェアトレードに関する普及啓発活動を行っている人はほとんどがボランティアだ。現に僕はフェアトレードタウンの認定委員だが、活動にともなう収入はない。

もし僕たちが本を書くことで、そういう人たちに少しでも貢献できたら楽しいんじゃないだろうか？僕たちは研究の過程で色んな人にお世話になっている。そういう人たちに謝辞を述べることができるけれど、現場の人が一番欲しいのはやっぱりお金だろう。それも当事者が自由に使えるお金だ。

僕たちは年末に本の収益を寄付する先を相談して決めることにした。支援対象はフェアトレードに限定せず、社会貢献活動をしている団体だ。ずっと同じ団体に寄付してもいいけれど、各自の関心は異なるし、時期によっても異なるだろう。そういうことを勘案して、毎年寄付先を決めてみる。

というわけで、僕たちは本を出版した。販売部数とか寄付先とかはここでも報告する予定だ。

教科書を書いた。参考文献の大半は日本語だが一部英語のものも混じっている。翻訳書も多く含まれている。

執筆にはemacsとorg-modeを選択した。 文献の管理にはZoteroを使用し、org-modeとZoteroをつなぐ文献管理ツールにはBiblatexを選択した。

普通はWordで書くのかもしれないが、長文を書くときには長らくこの組み合わせを使用している。 だが、文献リストをツールを使って管理しなければならない日本語文献を書いたことがなかった。

今回の取組で、LaTeXで日本語文献を扱うのは、想像以上にめんどうなことがわかった。 同時に、ChatGPTに設定を聞きながら進めてみたところ、かなり助けられた。が、いちばん大事なところで嘘っぽい話もあったので注意が必要だ。 ChatGPTに頼るなら、ある程度問題がわかっていないと、逆にはまるかもしれない。

コンピュータにファイルをどのように保管しているだろうか？学生にファイルを探させると、なかなか見つけられないという人がいる。 一定のルールを設けて、ファイル管理をする習慣をつけることで、ファイルの迷子がなくなる。

クラウドが活用できるようになったため、PCに過去のファイルを大量に保管する必要はほとんどなくなっている。 いつ作ったのか覚えていないようなファイルが、なんらかのきっかけでセキュリティリスクを起こさないとも限らない。

おまけに、移動が多い僕の場合、普段使用しないPCを使用せざるを得ないこと、PCが壊れて緊急に作業する環境が必要になることなどがある。

そこで、僕は作業用のフォルダとアーカイブフォルダに分けて使用している。 そして、アーカイブフォルダには過去のファイルを入れる。そして、過去のファイルは変更しないという原則を設けている。

作業用のフォルダは次の５つだ。

• 01urgent
• 02work
• 03references
• 05done
• 08books

01urgentは小さな仕事で締め切りがあるもの、早めにやりたいものを入れている。 このフォルダにあるものは完了したら05doneに送り込む。 01urgentは毎日見て、Todoリストに追加してから作業する。

02workはプロジェクトとなっているものをプロジェクトごとに入れている。僕の場合、各講義科目や学内の委員会、研究プロジェクトなどだ。

03referencesには、証明書のコピーやアプリの操作方法をまとめたチートシート、マニュアルなどが入る。このフォルダは参照用のものを入れておくので、変更することはない。Notionなどを利用するようになり、このフォルダの必要性は薄れている。

05doneは主に01urgentで作業が終わったものを入れている。

08booksにはスキャンした本とか、pdfで配布されている報告書などが入っている。ただし、読むというよりは参照するものはZoteroの方に入れている。

フォルダ名に連番をつけているのはソートのときに便利なようにと思ってのことだが、これらのフォルダはWindowsの場合、左側のクイックアクセスにピンどめしているので、番号はいらないのかもしれない。

基本的に01-05のフォルダを中身を見ずにすべて年度名のフォルダに入れる。2022年度なら、2022だ。

そして再び、手作業で01-05のフォルダを作成し、クイックアクセスにピンどめする。 しばらくは、前年度の01-05のフォルダを使用することが多くなるので、これらは新年度の各フォルダ内にショートカットを作っている。

こうすると、ディレクトリのトップに、01-05のフォルダと過年度のフォルダが並ぶ。

あまりたくさん過年度のファイルがあると目障りだし、なにかの折に削除してしまうかもしれない。 そこで、過年度のファイル保存用のディレクトリを作っておく。

例えば、> oldfilesとしておいて、ここに３年以上前のフォルダを入れている。

よって、2023年度のフォルダ構成はこうなる。

• 01urgent
• 02work
• 03references
• 05done
• 08books
• 2022
• 2021
• oldfiles

oldfiles以下には過去のファイルが年度ごとに保存されている。 けっこう10年以上前の仕事のファイルを参照したくなることがある。意外と「何年頃にやったあの仕事」ということは覚えているものなので、年ごとにファイルを分けておくと、探すのが早い。

ちなみに、これらのファイルはすべてクラウドにおいている。そして、oldfilesと2021はクラウド上だけにあり、ローカルには同期していない。

１年前のファイル（2022）は使うことがけっこうあるので、ローカルに同期している。

2022年の12月頃になると、翌年度の打ち合わせとか資料作成等が始まるプロジェクトがある。 これらは、02workにおいておくと、移行の際に面倒なのでそういうものは、01urgentと02workの中に翌年度（2023）のフォルダを作り、ファイルを保管している。

先週新しいPCを入手したので、いろいろアプリをインストールしたり設定したりしていた。 そのときに、フォントがうまく入らなかった。

フォントをダブルクリックして開くプレビュー画面で「インストール」ボタンを押すと、そのフォントが「正しいフォントではない」的なことを言われる。

コントロールパネルからのインストールなども試したけど同じ症状。

どうにも手がないのでMicrosoftのチャットサポートに連絡してみた。

サポートは初心者にも対応できるように、すごく簡単なところから順に実験する。 まず、ストア上にあるフォントをアプリとしてインストールを試したあと、管理ページからのインストール、ダブルクリックでのインストールを試させられる。 こちらがそれまで何をトライしたのかなんて一切聞かない。

ストレスが溜まることに、一つメッセージが来てから次のメッセージが来るまでが30秒～１分ぐらいかかる（体感）。

そんなわけで、すでにやってだめだから相談しているこの３つの方法を試すだけで、50分かかった。

あげくに提示されたオプションは修復インストール。

そして、修復インストールを行うと、フォントはぶじインストールできるようになった。

原因についてなどの説明は一切ない。

Windowsは複雑なシステムで、けっこうシステムの深めのところまでソフトが設定を変えられる。 おそらくそのせいで、サポートも大変なんだと思う。

だけど、今回の件は、「３つのフォントのインストール試行をしてそれでもだめなら修復インストールしてくれ。わからなければ引き続き質問を」という案内を最初にしてくれればあとは自分でできる。 それを手取り足取りやろうとするから余計にストレスが溜まる。

正直、問題が解決しても、原因はわからないしチャットに割いた時間の喪失感が強い。

論文を執筆するときに、作業の進捗を記録することがよいとよく言われる。 でも、毎回字数を数えるのもちょっとめんどうだ。

例えば、その日の作業を終えるときにgitでコミットする。コミットメッセージに進んだ字数を自動的に入れておいてくれればかなり楽ではないか。

なんかいいのないかな？と探していたら、jMatsuzakiさんという方が、便利なシェルスクリプトを公開してくれている。

執筆やプログラミングの相棒として使える「Git Character Counter」なるものを作成して公開しました。 （出所：「Gitリポジトリに追加された文字数をカウントするシェルスクリプト公開 | jMatsuzaki」、（https://jmatsuzaki.com/archives/28195）

しかし、僕の環境だとうまく動かないのか、コミットメッセージに入れてくれるわけではないようだ。

汎用的に、「どれだけ進んだかな？」ということには使えそうなんだけど。

少し調べてみると、.git/hooks/prepare-commit-msgでコミットメッセージを編集できるらしい。

issue番号を自動で入力する （出所：「git commitする時にissue番号を自動で入力するgit hooks」、（https://gist.github.com/saxsir/5cd33801fc2a77a1b1f8）

jMatsuzakiさんのスクリプトをsaxirさんのスクリプトに混ぜ込むと、うまく動くものができた。

ただし、僕のばあい、sedとwcコマンドは別途用意した。 まず、scoopでsedコマンドをインストールした。wcはscoopには見つからなくて、どうしようもなかったので、wslのwcを使用した。 sedもwslのものを使うなら、それぞれの前にwslを入れておくとよい。

それから、今回の利用方法ではステージングされているファイルとリポジトリの最新のコミットとの差分を見ればいいので、オプションも決め打ちにしておいた。

最終的には以下で動くようになった。

#!/bin/sh
if [ "$2" == "" ] ; then
  mv $1 $1.tmp
  echo -e "\nprogress: `git diff -p -b -w -U0 --diff-filter=AM --ignore-cr-at-eol --ignore-space-at-eol --ignore-blank-lines --ignore-matching-lines="^(---|uid|title|aliases|date|update|tags[]|draft)" "@" "--cached" | grep ^+ | grep -v ^+++ | sed s/^+// | sed -e ':a' -e 'N' -e '$!ba' -e 's/\n//g' | wsl wc -m`" > $1
  cat $1.tmp >> $1
fi

コミットしてみると、以下のようなコミットメッセージが作成される。

問題文の空欄に入る適切な語句を語群から選択する問題を簡単に作る。

特に、キーワードにランダムな記号を割り当てて、記号順にソートするところがめんどうなので、これを自動化したい。

僕のブログから、適当な文章を抜き出して、問題文としてみる。

• 問題文から選択肢群をスクリプトで抜き出すこと。
• 選択肢を抜き出した問題文の[]に自動で解答番号を入れること。

簡単にやれるけど、今日は早くテスト作らないと締切に間に合わないので、次回に回すことにした。

なんか、テストのたびにスクリプト書いてる気がするので、記録に残しておく。

問題文は次のようにする。正しい選択肢に続けて|を入れて、ダミー選択肢を入れる。別にダミーがなくて選択肢一つでもかまわない。 こうしておくと、各解答欄の最初のキーワードを正答として集めてくれる。

解答候補は重複していてもかまわない。後で重複は削除する。

Zoteroは[ライブラリ|ブラブラリ]とオンラインのアカウントが紐ついているので、別アカウントと同期することは[できない|できる]。 今回、紐付けを[削除|強化|あれ]して、別アカウントと同期できたので、記録に残す。 

小学生から[高校生|中学生]までの計算[ドリル|地獄]を自動で生成してくれる。これ、かなりいいツールだ。 ただ、僕の環境では[pLaTeX環境|Word|Excel]がない。そこで、LuaLaTeXに対応させてみた。

ここが次に自動化したいところだが、今は問題文から、[]の中身を手作業で取り出して、次のようなファイルを生成してkeys.csvとしておく。

1, ライブラリ|ブラブラリ
2, できない|できる
3, 削除|強化|あれ
4, 高校生|中学生
5, ドリル|地獄
6, pLaTeX環境|Word|Excel

このとき、問題文は次のように変更しておく。

Zoteroは[1]とオンラインのアカウントが紐ついているので、別アカウントと同期することは[2]。 今回、紐付けを[3]して、別アカウントと同期できたので、記録に残す。 

小学生から[4]までの計算[5]を自動で生成してくれる。これ、かなりいいツールだ。 ただ、僕の環境では[6]がない。そこで、LuaLaTeXに対応させてみた。

先のkeys.csvをスクリプトにかけると、以下のように語群ができる。 問題番号と解答記号のリストは、correctanswers.csvに保存されているので、採点時はそちらを参照する。

ア. pLaTeX環境、イ. できる、ウ. 地獄、エ. Word、オ. ドリル、カ. できない、キ. Excel、ク. 高校生、ケ. 中学生、コ. ライブラリ、サ. 強化、シ. あれ、ス. ブラブラリ、セ. 削除

なにか、説明が必要だろうか？

Pythonスクリプトによくあるのがこれだ。

if __name__ == '__main__'

この説明は以下で詳しくされている。__name__にはモジュールのファイル名から.pyを除いたものが入るのだそうだ。

https://note.nkmk.me/python-if-name-main/

が、なんだか腑におちなかったので確かめてみた。

つまりはファイル名ではなく、呼び出したモジュール名なのでは？という疑問だ。 試してみたら、やはりファイル名だった。

次のように実験した。

print('This is __name__ test.')

def nametest():
    print(__name__)

if __name__ == '__main__':
   nametest()

This is __name__ test.
__main__

先程のスクリプトを"maintest.py"として保存して、次のスクリプトを実行する。

def func():
    print('Hello!')
    print('__name__ is', __name__)

maintest.nametest()

実行結果はこうだ。

This is __name__ test.
maintest

まず、モジュールを読み込んだときに、「This is name test.」が表示される。 これは、関数等に入っていないので、読み込み時に実行されるようだ。

理由はわからないのだが、PC上のMendeleyが起動しなくなった。ライブラリを消したりアプリの再インストールをしてみても同じだ。

しょうがないので、ZoteroとPaperPileを比較して、Zoteroを使うことにした。だいたい機能的には似たようなものなのだが、Zoteroはオープンソースだし、Electronベースなのでこちらがいいかなと感じた。

PaperPileは月に300円ぐらいの課金モデルなのだがそれはあまり気にしていない。仕事で使うものなので、無料であることより長く開発が継続される方がいい。というわけで、Zoteroには毎年一定額を寄付することにした。

Zoteroは非常に便利で常用するつもりだ。 使っていくうえで、ちょっと便利な使い方、ちょっとした問題を解決する設定などを備忘録的にこちらに追加していく。

Zoteroは文献管理ツールだ。Mendeleyとほぼ同様に使える。

僕は、Zoteroのライブラリを自動でbibtexにエクスポートしてLatexなどで使っている。文献のメモなどはEmacs上のOrg-roam-bibtexの機能を使っている。 この環境についてはいずれ書く予定だ。

今はまだじゅうぶんに慣れていなくて、なんとなく使えている感じだ。それでもZoteroとEmacs、Citarの連携はおそろしく便利だ。研究を始めた頃にこの環境を構築していればどれだけ幸せだったか・・・とため息が出てしまう。

EmacsはUNIXの文化に深く染まっているので、一つのことをやるのにいくつものツール・ライブラリを組み合わせる事が多い。Emacsで論文を執筆するときもEmacsは執筆のハブのような感じでかなりたくさんのライブラリや外部ツールを使っている。その一つ一つを理解するのはとても大変だし、ましてやよくわからないままに環境を構築するのは大変だ。

実はZoteroも少し似たような感じがあって、アドオンを駆使して、いろんなことを実現できる。外部ツールを使うとさらに便利になる。

Zoteroはライブラリとオンラインのアカウントが紐ついているので、別アカウントと同期することはできない。 今回、紐付けを削除して、別アカウントと同期できたので、記録に残す。

ローカルとZotero.orgをSyncしていたのだが、ローカルのライブラリを大幅に変更した。 Syncして、オンラインからデータがダウンロードされると嫌だなと思い、Zotero.orgのアカウントを削除した。

本来、ZoteroのSyncメニュー（同期）には「リセット」というオプションがあり、そのオプションを使えば、オンライン上のライブラリを強制的にローカルのデータで上書きできる。 それを知ったのは、オンラインのアカウントを削除してからだった。

さて、オンラインのアカウントを新規に作り直して、ローカルのデータをアップロードしようとしたら、これができない。 Zoteroの仕様で、ローカルにあるライブラリとオンラインのアカウントは１対１で紐ついている。 そして一度これを作ってしまうと、もう変更はできない。

もう存在しないアカウントに紐ついたライブラリは、二度とオンラインと同期できなくなってしまった。 さすがにこれは困るので、いろいろと試行錯誤をしてみた。

まずは、オンラインと紐付いていないライブラリを作成して、旧ライブラリからデータをインポートすることを試した。

データのエクスポート・インポートを行うと、登録日が削除されてしまうのが問題だ。正直、「いつごろのしごとに関連して追加した論文」という記憶で論文を検索することもあるので、登録日は削除してほしくない。

でもまあ、とりあえずやれるかどうかは試してみたい。 旧ライブラリからエクスポートしたものをインポートしようとしてみた。 インポートはできたが、せっかくフォルダ分けしたライブラリのフォルダが全部解除されてしまっている！

これはだめだ！と思い、次の手段に移行した。

※　後日よく見たら、僕がインポートしていたのはbibファイルで今エクスポートしたものではなかった。 エクスポートしたフォルダの中に、さらに「マイライブラリ」というフォルダが作られていて、そのなかにZotero形式（RDF）でエクスポートしたライブラリがあった。 こちらをインポートしたら、フォルダ構造もちゃんと再現された。

だが、残念ながら、僕がエクスポートしたのは、PDFをファイルのないもの。 この辺、よくわからない。

次の手段と言っても、もはや、普通の方法ではできない！と覚悟した。

オンラインとの紐付きはなにか設定ファイルにあるのかな？と思い、Zoteroのライブラリを見てみた。そうすると、Zoteroのデータベースはsqlite形式で保管されている事がわかった。

sqliteを閲覧・編集できるツールを持ってきて、中を見てみた。

なるほど、過去と連携した形跡がsettingsとかに確かに残っている。

削除するのは、usersテーブルとsettingsテーブルにあるオンラインのアカウント名とID番号だ。 該当するレコードを削除すると、過去にSyncしたオンライン上のアカウントを忘れてくれる。

さて、これでSyncすればいいのかな？と思うと、「_libraryStorageVersion cannot decreased」というエラーが出てしまう。 どうやら、こちらのライブラリのバージョンとオンラインのバージョンの不整合のようだ。

これを修正するのは、librariesテーブルだ。 versionとstorageversionがあるが、versionの方を古いように修正する。

以上でZoteroを再起動して、同期の設定をする。 僕は同期の設定をした直後に「リセット」するようにした。

ここまでやると、ライブラリのエクスポート・インポートを経ずに新しいアカウントとの同期が実現した。