k16's note

書籍『ゼロから創る暗号通貨』をどう読むか

2018-10-25T14:41:00.000+09:00

濵津誠著『ゼロから創る暗号通貨』（2018年10月、PEAKS発行）の編集をお手伝いしました。この本はどんな本かというと……

土台となるP2Pネットワークから暗号通貨を自前で作ってみることで、ブロックチェーンを応用したまったく新しいサービスと未来を創るところまで意識できる本
著者の濵津さん自身が教師役となり、ブロックチェーンの「うさんくさくない」部分の全体がわかるように、読者をひっぱっていってくれる本

要するに、ブロックチェーンの技術を通して、濵津さんという凄腕技術者が読者のメンターになってくれる本です。これまでクラウドファンディングで出資者しか読めなかったのが、今日から一般にも購入できるようになりました！

著者：濵津誠,
製本版,電子版
PEAKSで購入する

以下は、個人的な回想と、本書でぼくが何をしたかの舞台裏。

暗号通貨についてざっくりと知りたいなと思って、「暗号通貨」で検索してみると、投資して儲けたい人向けの記事と、通貨としての側面について考察する社会派な記事ばかりがトップに並びます。この結果だけ見ると、だいぶうさんくさい。でも、暗号通貨というかブロックチェーンって技術的には面白そうなトピックだし、キャッチアップはしておきたいな。

というわけで、その昔、サトシ・ナカモトの原論文（PDF）とされているものを斜めに眺めてみたことがあります。以下、たぶんそのころにぼくが感じたであろうこと。

どうやら、ビットコインにおける「コイン」とは、取引の記録をつなげたものらしい。ということは、そのコインが使われた取引の記録を、そのままコインとして使おうという発想か。で、この論文の冒頭にあるのが、取引の連鎖としてのコインの構成図というわけね。ブロック暗号化方式におけるブロックチェーンみたいだな、ああ、それで「ブロックチェーン」っていうのか。しかし、原論文でその図が出てくるところには、「We define an electronic coin a chain of digital signatures」（電子コインとは、ディジタル署名の連鎖のことである）と書いてあるぞ。このディジタル署名で、コインを使った人を特定しようというのだろうか。分散されたタイムスタンプサーバで「Proof of Work」を計算し、その「証拠」をブロックに埋めることで、CPUパワーに基いた安全な取引が実現する？何をいってるのかさっぱりわからないぞ。ブロックの図の中に出てくる「nonce」が「証拠」のことなのかな……。

論文だからしょうがないかもなんだけど、だいたいこんな感じで、半分くらい読んだところで放置してました。こんな「ふわふわ」した概念を具体的にどうやって「通貨」として使えるように実装できるのか、そもそも、この論文のどのへんが画期的なのか、まったく想像つかないぞ！

PEAKSの永野さんから「暗号通貨の本をクラウドファンディングで出すことになったので編集を手伝ってほしい」という相談を受けたのは、そんなときのことでした（うそです、実際に論文を読んでみたのは4-5年前のこと）。

PEAKSについては、『プロフェッショナルIPv6』と同時期にクラウドファンディングの技術書を始めた（シンクロ改行ニシティ）というくらいの情報しか持っておらず、ただiOSとかAndroidとかの現場よりの内容が多い印象だったので、暗号通貨というテーマはかなり意外に感じたのを覚えています。それなのにぼくに編集依頼がくるということは、もしかしたらだいぶ固い感じの内容なのかなあと勝手に想像していました。

ところが、著者の濵津さんの原稿をはじめて目にして、肩透かしを受けることになります。原稿に対する第一印象は、「ラノベだこれ」。

しかも、その時点で出来上がっている原稿の大半は、ぜんぜん暗号通貨っぽくない。ひたすらPythonでP2Pネットワークを作り始めているのです。確かに暗号通貨って分散ネットワーク上のアプリケーションだし、書名のとおり「ゼロから創る」んだろうけど、本の構成として正直これでいいのだろうか。わざわざ「創る」という表記になってるのも気になる。それに、対話形式の本文って、これまたかなり難易度が高い手法を選んだな……。

そんなことを思いつつ、まずは文章になっている情報を整理するつもりで読み始めて、1章と2章を読み終えたところで、この本が対話形式なのは単なる思いつきではなく完全に意図的だなと気づきました。これなら、「マンガでわかる」みたいな本と同じように、頭ごなしに概念から入るのがつらい人向けに最初の一歩から教師役が寄り添って説明していく本にできそう。そして暗号通貨というのは、数年前にぼく自身がぶちあたったように、

なぜそういう概念を導入したいのか
その概念はどういう技術に落とし込めるのか
それらを組み合わせて何ができるのか

が見えにくいテーマなのかもしれず、それならば対話形式はもってこいかもしれない。

とはいえ、対話形式って、ケレン味を感じさせることなく読ませるのが難しいんですよね。そもそも登場人物の役割分担を書き分けるのが難しい。生徒役がありえないほど高スキルな質問をしてしまう、みたいなことがないようにしないといけない。かといって、先生役がひたすら説明するのもうまくない。ぼくが最初に原稿を見たのは、ちょうどサポーター向けの最初のプレビューが始まっていたころだったのですが、そのへんの調整はまだまだ必要そうな状態に見えました。

そこで、まずは教師役の兄と生徒役の弟の口調を整理しつつ、弟のペルソナを「Pythonでコードはごりごり書けるけど技術の背景にある設計思想はまだ読み取れない学生」としつつ、それがぶれないように兄と弟のセリフを整理しました。兄の説明についても、飛躍を埋めるような調整を全体に入れました。ついでに、なぜ暗号通貨の本を読んでいるはずなのにP2Pネットワークを創らされているのか動機を明確にしたり、いま全体のうちどの部分を説明しているのか迷子にならないようにサブ見出しを適宜入れたり、そういう通常の編集も加えていきました。

ちょっと驚いたのは、ぼくの本文編集と並行して、hagino3000さんが全体にわたってPythonのコードをレビューされていたことです。これでは弟が凄腕のPythonistaになってしまうー、という危惧を感じないではなかったのですが、これは読者にとってはすごくうれしいことだと思いました。なるほどPEAKSではそういうところにちゃんとコストをかけているのか、という驚きでした。

最終的に完成した『ゼロから創る暗号通貨』という本、すでにクラウドファンディングで支援された方々の手元には届いているのですが、今日からPEAKSのサイトで一般発売も開始したようです。

ゼロから創る暗号通貨

著者：濵津誠,
製本版,電子版
PEAKSで購入する

実際に読むとわかりますが、この本では暗号通貨をやるのにP2Pネットワークから本気で作り始めます。それは、P2Pネットワークにおいて個々のノードがブロックチェーンを構成するという点が、リアルな通貨との交換可能性みたいな部分にとどまらず、暗号通貨の技術的な応用可能性が開けてくるところだからです。「土台となるP2Pネットワークから暗号通貨を自前で作ってみることで、ブロックチェーンを応用したまったく新しいサービスと未来を創る」ところまで意識できる内容になっているのが本書の魅力だと思います（それで書名は「作る」じゃなくて「創る」だったんだね）。もちろん、「著者の濵津さん自身が教師役となり、ブロックチェーンの「うさんくさくない」部分の全体がわかるように、読者をひっぱっていってくれる本」という点も魅力です。上記のリンク経由で本を買っていただけると私にキックバックがあるそうなので、暗号通貨のその先にあるブロックチェーンの応用が気になる方、濵津さんみたいな技術者になりたい方は、ぜひ！

っていうか、このブログ記事を書くのに、さっきサトシ・ナカモトの論文を読み返してみたんですよ。そしたら、たぶん『ゼロから創る暗号通貨』をひととおり読んだおかげで、するするわかる。ような気がする。

日本語の編集をしていてよく直すパターン15選（増えるかも）

2018-08-15T17:41:00.001+09:00

『校正のバイトをしててよく直す箇所10選｜bxjp｜note（ノート）』という記事を読んで、よくパターン化されていて素晴らしいって思っていました。ところが、記事の趣旨を勘違いした方からの冷たい反応を受けて有料にされたということで、あまりも残念なので自分の立場で再編してみました。1～10は元記事のパターンに対してぼくの考え方を添えたもの、A以降は、元記事を見てぼくが反射的に思いついたパターンです。

まあ、こういうパターンは便利だけど、パターン化できる修正を積み重ねれば悪文がなくなるほど自然言語は簡単ではないので、編集や校正をする人はたいへんですね。自分は、こういうパターンも直すけれど、段落の役割を整理する、みたいな修正のほうが専門です。（専門とは？）

追記：これは文の書き方指南じゃなくて、文の編集校正で何をやってるか報告です。

1. 順接の「が」が頻出

順接の「が」は撲滅を目指すべきです。なるべく減らす、とか言ってる場合ではない。

2. 「も」を使いがち

「も」が必要以上に使われているのは論外として、「も」の位置も直したほうがいい場合っていうのが意外と多い。つまり、「も」の位置を直したほうがいい場合っていうのも意外と多い。

3. 「することができる」を使いがち

発話で「〇〇できる」と短く言い切るのは不安かもしれませんが、書き言葉では「することが」成分はおおむね不要です。ざくざく削ぎ落としていきます。

4. 途中で主語が入れ替わっている

書き手が長い文を書いていると、しばしば主語が入れ替わってしまう。ところで、前の文では主語が入れ替わっていて、日本語では許容される場面も多く、徹底するのは難しい気がします。とはいえ、やっぱり読みやすくはないので、たいていの場合は文章ごと書き直します。

5. 意味のまとまりで「、」を打たない

読点は意味の区切りとは限らないので難しいなあ（そもそも意味とは）。ただ、発話の調子に合わせて入れるものではない、とだけは言えます。

6. 列挙するときに余計な語句を入れてくる

これはよくわからなかった。

7. そこ漢字？ってところが漢字

～と言う、無い、出来る、何れも漢字にして欲しく無い。

8. 同じ表現・言葉が近い位置に出てくる

同じものは同じ表現にするのが原則。そのうえで、微妙に違う話が同じ表現になるのを避けたい場合、箇条書きにするといった工夫を施す場合があります。

9. 表現がバラエティ豊かすぎる

非標準的な語法やレトリックは、多用すると印象が悪いので、きもち控えめに修正することがよくあります。

10. 同じことを書いている＆省略せずに書いている

どんなに重要な話でも、同じ内容の文が近距離で繰り返されている場合には、ざっくり要約するか、別の表現に書き換えるなどします。

A. 因果関係を示すために「ため」を使わない

「ため」は多義的なので、目的を示すための利用に限定していきます。

B. 「の」でなくてもいい場所から「の」を追放する

「ぼくのかんがえたさいきょうのまとめ」よりも「ぼくがかんがえたさいきょうのまとめ」

C. 「イ形容詞＋です」を避ける

わりと多いです。うまくないです。

D. 「行う」を減らす

便利なのでつい多用しがちだけど、だいたいは動詞ひとつで言い換えられます。「することができる」と似てるかもしれない。

E. 目的語の不足や、位置の修正

「「何を」がないことが多い。」みたいな文だと、わかってる人にしか伝わりません。「読者が、文脈から動詞の対象となるモノを推察するしかない文章が少なくありません。」くらいたっぷり書いてほしいわけです。それをさらに編集で「動詞の対象となるモノを、読者が文脈から推察するしかない文章が少なくありません。」と直したりします。

技術書をクラウドファンディングで出版してみた

2018-07-07T22:04:00.004+09:00

あきみちさんから、「IPv6本を出すということで、クラウドファンディングで協賛を呼びかけよう」（原文ママ）というアイデアを聞いたのは、TwitterのDMのやり取りを読み返すと2016年11月23日のことだったらしい。 DMには時刻が表示されないので正確な時間はわからないけど、その後のやり取りがいつの間にか11月24日になっているので、たぶんそういう時間帯だ。

それに対するぼくの最初の返答は、「それは既存の出版社だと面倒そうだ」（原文ママ）だ。言外に「うち（ラムダノート）ならできるよ」が含意されていることは、起業前からいろいろ相談にのってくれていたあきみちさんには間違いなく伝わる。とはいえ、そのころはまだ『プロフェッショナルSSL/TLS』も制作中だったし、直販ストアもなかったし、ラムダノートは胸を張って「出版社」と言える状態ではなかった。

そもそも、あきみちさんやぼくは技術自体というより技術解説でご飯を食べている人間であり、必要としている人がいる内容だからといって、採算度外視では動けない。当時はまだクラウドファンディングで技術書を作るという先行事例もなく、どれくらい集めればいいのか、どれくらい集まればいいのか、どういうふうに具体化すればいいのか、まったく見当もつかなかった。にもかかわらずぼくは、あきみちさんにいくつか質問したあとで、「だれにでも通用するやり方じゃないですが、あきみちさんでIPv6の本なら確度高い。」（原文ママ）と応じていた。はっきりいって軽率である。まあでも、考えていてもわからないことは、やってみるしかないので、当時のぼくはやってみることにしたのだろう。

それから急いで企画書っぽいものを作り、直接支援をお願いできそうな会社にあきみちさんから打診し、ぼくのほうでもMakuakeに問い合わせを入れた。完成品をCC BY-NC-SAで公開することをふくめて、翌月にはだいたいプロジェクトの形が決まった。当時の企画書の1枚めはこんな感じ。

このときの企画書をいま見返すと、本の構成も、収益化のモデルも、基本的なコンセプトはこの時点からほとんどずれていない。本の構成については実際に本を読んでもらうとして、ここでは収益化のモデルという視点で現時点で個人的に感じていることをメモしておこうと思う。

「こういう本が最小限の負担で読める世界」に出資してもらう

『プロフェッショナルIPv6』の商売モデルは、たぶんこんな感じになっている。

つまり、この本の著者と出版社には、本という商品だけでなく、「こういう本が最小限の負担で読める世界」を実現することへの対価として出資してもらえたし、応援してもらえた（本当にありがとうございます）。そうした出資を広く集めるうえでクラウドファンディングという方法は相性がよかったし、任意の金額を著者に直接渡せるという電子版の提供方法を手軽に導入できたのは大きかった（BOOTH、まじ便利）。

一方、多くの本の企画は、基本的にはこんな商売モデルでやっている。

この方法だと、動物の絵がカバーにあるわけでも全国の書店にフリー入帳で配本できるわけでもない新興の出版社から発行される「IPv6の解説書」は、完全に「知る人ぞ知る」ものになっていただろう。あきみちさんとぼくの実情からすると、最悪、陽の目をみなかった可能性もある。こうやって多くの人に届けることはできなかったかもしれないし、著者に利益を還元できなかったかもしれないし、うちも資金繰りに困っていたかもしれない。

教訓と抱負

『プロフェッショナルIPv6』は、たぶん、「こういう本が最小限の負担で読める世界が欲しい」という人を巻き込めた。つまり、「読ませたい人」の支援で成立した。そして、この事実からは、技術書の出版に従事している自分たちにとっての教訓めいたものが導き出せる気がしている。

実のところ、技術書の多くは、これまでだって「読ませたい人」からリソースを分けてもらうことで「商売」をしている。その最たる相手は、印税収入を期待せずに採算度外視で執筆してくれる著者。それから、謝辞と献本程度の対価で内容のレビューをしてくれる有識者や、やはり献本程度の対価で宣伝をしてくれるインフルエンサー。みんな、「読ませたい人」として、自分が持っているリソースを本という商品に投下してくれている。出版社は、そうした人たちの善意に頼ることで、対価を払ってまで読みたいことを自覚している人の総数だけでは成立しないかもしれない本を作って売るという商売をかろうじて維持している。

ぼくら版元の編集者の人間は、そのことに意識的でなければならないと思う。版元の編集者も「読ませたい人」ではあるだろうけど、その実現のために持ち出しで出資をしているわけではないので（むしろ多くの場合は十分な対価を得ている）、気を抜くとこの事実を忘れがちになるので本当に注意しなければならない。ページあたり数百円とかで編集制作をやってくれる編集プロダクションが版元編集者のコストを肩代わりしている可能性にも意識的であるべき。閑話休題。

教訓は、なにも警鐘を鳴らす方向だけではない。『プロフェッショナルIPv6』では、「こういう本が最小限の負担で読める世界が欲しい」という人から直接出資をしてもらったことで、商売として出版できるチャンスが広がった。あきみちさんという著者が十数年かけてインターネット上で築き上げた人徳があってはじめて実現するクラウドファンディングではあったけれど、とにもかくにもこういう形で出版ができたということは、「読みたいことを自覚していてお金を出してくれる人」の絶対数が多くないことが多い技術書みたいなジャンルの出版にとっては、わりと未来がある話なんじゃないだろうか、とも思う。

そんなわけで、『プロフェッショナルIPv6』をひとまず公開にまでこぎつけた現時点で個人的に感慨深いのは、クラウドファンディングという手段の面よりも、「こういう本が最小限の負担で読める世界」に出資したいと感じる人にうまく届けられたかな、という点にあったりする。締め切りに追われるのが精神的につらいのもあって、正直なところ、これからクラウドファンディングで本をばんばん企画していく予定はない。でも、「こういう本が最小限の負担で読める世界が欲しい」、もうちょっと厳密に言うと、「こういう技術情報がある世界が欲しい」という人や組織に出資してもらえるような企画、あるいは仕掛けを考えて、そのうえでコンテンツの制作をこれからもがんばっていければ嬉しいなという気持ちでいる。

宣伝

というわけで、ラムダノートの本をよろしくお願いします。

https://www.lambdanote.com/

プロフェッショナルIPv6

コマンド定義の中で\catcodeを変える

2018-04-30T22:45:00.000+09:00

LaTeXではシングルクォート記号がデフォルトで「’」になる。Unicodeでいえば、RIGHT SINGLE QUOTATION MARK（U+2019）。この挙動は、本文ならよいのだけど、等幅フォントにするような場面では都合が悪い。等幅フォントのときにみんなが期待するシングルクォートは「'」である。

みんなが期待する挙動なので、当然、そのためのパッケージがすでにある。upquoteパッケージである。しかし、このupquoteパッケージは、\verbコマンドおよびverbatim環境向けに作られている。fancyverb環境やalltt環境でも使えるが、\textttコマンド内の挙動には影響しない。つまり、upquoteパッケージを使っても、\texttt内のシングルクォート記号は「’」になる。

\texttt{...}の中でシングルクォート記号を直立タイプ「'」にするにはどうするか。すぐに思いつくのは、「'」をアクティブ文字にして、OT1/cmttの\char13にするという方法。あるいは、textcompパッケージで提供されている\textquotesingleにするという方法。実際、upquoteパッケージの実装もそのようになっている。その方針をそのまま実装するとこうなる。

\let\orgtexttt\texttt
\def\texttt#1{%
  \catcode`'=\active
  \def'{\textquotesingle}
  \orgtexttt{#1}}

もちろん、これは動かない。この\defの中身はすでにTeXの入力ルーチンで読み込まれているので、\def'{\textquotesingle}の時点では「'」がアクティブ文字になっていない。そのため、ふつうの文字である「'」に対して\defすることになってしまうからだ。結果として、「コントロールシーケンスやアクティブ文字であるべき場所にふつうの文字がある」というエラーになる。

! Missing control sequence inserted.

                \inaccessible

こういう場合の常套手段として、「\lowercaseトリック」と呼ばれるものが知られている。このトリックのポイントは、\lowercaseというコマンドの引数が、「すべての文字を小文字として解釈してくれて、しかもカテゴリーコードに関しては無視してくれるような世界」になることにある。そういう世界で、「'」のことを、なにか「\defの1つめの引数に置いても怒られない都合がいいアクティブ文字」の小文字にしておく。幸い、TeXには、そのような都合がいい文字がある。「~」だ。\def~{...}であれば、\def\texttt#1{...}の定義部の中にいきなり書いても怒られない。そこで、「~は'の小文字」ということにしておいて、\def~{...}と書けば、この\defにより実際には「'」に対する定義が書けることになる。

あるアルファベットに対する「小文字」を定義するためのプリミティブは\lccodeだ。これを使い、「'」のことを「~の小文字である」ということにして、その文脈で\lowercase{...}内で\def~{\textquotesingle}すればよい。

\def\texttt#1{%
  \catcode`'=\active
  \begingroup
    \lccode`~=`' %
    \lowercase{\endgroup
      \def~}{\textquotesingle}
  \orgtexttt{#1}}

\lccode`~=`'のスコープを定めている\begingroupと\endgroupの組に対し、\lowercase{...}のカッコがきちんと入れ子になっていない。あまつさえ\def~{\textquotesingle}にも「}」がまたがってしまっている。気持ち悪いかもしれないけど、これで問題はない。少なくとも、\def~を\begingroup～\endgroupの中に入れてしまうと、この\defがローカルになってしまうので、「'」がアクティブになるだけなって定義がないままとなりエラーになってしまう。

! Use of ' doesn't match its definition.

まあ、\gdefにすればいいだけだけど。

\def\texttt#1{%
  \catcode`'=\active
  \begingroup
    \lccode`~=`' %
    \lowercase{%
      \gdef~}{\textquotesingle}\endgroup
  \orgtexttt{#1}}

（ところで、\endgroupが\lowercase{の直後で問題ないことの根拠は、正直なところよく理解していない。\lowercaseが大文字小文字の対応表をメモリに展開するのが引数を読む前、だからなんだろうなあ。）

さて、\lowercaseトリックのおかげで「'」がアクティブ化される前に「\def'」と書くことを回避できたので、こでれエラーにならずに動く。しかし、挙動は依然としておかしい。ブロック要素で最初に登場する\textttの中では「'」の定義が効いておらず、その後ろに出てくる「'」が、\textttの中だろうが外だろうが\textquotesingleになってしまうのである。

*\texttt{\show'}
> the character '. % \textttの中だけど、文字
...
*\show'
> '=macro:
->\textquotesingle . % \textttの外だけど、アクティブになってる
...
*\texttt{\show'}
> '=macro:
->\textquotesingle . % 2つめの\textttの中ではアクティブに
...

最初に登場する\textttの中で「'」の定義が効かない原因は、すぐにわかった。\textttの引数はすでに読み込まれているから、「'」に対する\catcodeは効いてないのである。\defに対しては\lowercaseトリックのおかげでごまかせたが、この状態では\textttの引数に対して「'」が\textquotesingleとして扱われることはない。

この欠陥に対処するには、\textttの引数が読み込まれるのを遅らせればいい。そういう場合の常套手段は、マクロの展開を二段階にしてサブのほうで引数を読み込ませる、というもの。つまりこんなふうにする。

\let\orgtexttt\texttt
\def\texttt{%
  \begingroup
    \catcode`'=\active
    \x@texttt}
\def\x@texttt#1{%
  \begingroup
    \lccode`~=`' %
    \lowercase{\endgroup
      \def~}{\textquotesingle}
  \orgtexttt{#1}
  \endgroup}

これで、目的のマクロそのものは完成した。

これにて本件は落着といたす、でもいいんだけど、1つ前の定義が「最初に登場する\textttより後ろで、\textttの中だろうが外だろうがシングルクォートが\textquotesingleになってしまう」という挙動だったのが謎い。まったく\textquotesingleにならない、というなら納得できるんだけど、~~なぜ\textttの引数内で閉じているはずの\catcode`'=\activeが外に漏れてしまっているのか。~~

どう考えても、オリジナルの\textttの定義に何かある。しょうがないのでlatex.ltxを覗くと、\textttの定義は事実上こうなっていた。

\DeclareRobustCommand\texttt[1]{% \ifmmode \nfss@text{\ttfamily #1}% \else \hmode@bgroup \text@command{#1}% \ttfamily\check@icl #1\check@icr \expandafter \egroup \fi}

なんなんだよ、この下から3行めの\expandafter。。これのおかげで、\texttt（を再定義したものの中にある\orgtexttt）の引数が読まれるとき、もりもり後ろのほうまで読まれてしまって、\catcode`'=\activeがしばらく先まで有効になってしまっていたっぽい。

この\expandafterは、\textttに限らず、NFSSが提供するフォント変更コマンドすべてに登場する（ようなマクロになっている）。これ、なんのために必要なの？

なにも謎くなかった。先の動作しない\textttの定義で\catcode`'=\activeは閉じてない。ZRさんありがとうございます。

ダメな方の \texttt で、例えば
\texttt{\show'}
を一回展開すると
\catcode`'=\active \begingroup …
となる。\catcode 文はグループ外だから、\begingroup 以降のゴチャゴチャに関わらず、とにかく ' はアクティブになったまま。
— ZR-TeXnobabbler（∉∅） (@zr_tex8r) 2018年4月30日

技術書のレビューの経験則

2018-03-05T15:34:00.000+09:00

出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。

一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。

というわけで、技術書の制作における「レビュー」について、自分の経験をもとに知見を整理しておきたい。自分の経験をもとにはしているけど、たぶん日本で技術書のレビューをまわしてきた経験数では上位にいるはずなので、独りよがりではあるかもだけど意味がなくはないはず。

余談だけど、たぶんこういう出版前の状態を有志にボランティアでレビューしてもらうという文化を技術書界隈で積極的に始めたのはアスキーなんじゃないかなと思う。少なくともぼくが最初にこういうプロセスの存在を知ったのは、アスキーの256本とかで執筆兼レビューのためにメーリングリストを使っているのを見たときだった。彼らがどこまで意識的にこれをプロセス化していたのかは知らないけれど、この記事は、彼らがやっていたプロセスをぼくの前職のチームの先輩だった森田さんが取り込み、いろいろな著者、訳者に協力してもらいながら発達させてきた手法がベースになっている。

技術書のレビューのパターン

まず、レビューと一口にいっても王道のプロセスがあるわけではなくて、依頼方法およびレビュアーどうしのインタラクションの有無によっていくつかの形に分類できる。

	レビュー内容は制作サイドだけが見たい	レビュー内容が他のレビュアーにも見えてよい
制作サイドで知己がある人に依頼	①	②
制作サイドで知己がない人に依頼	③	④
不特定多数	⑤	⑥

上記の表のいずれのパターンに該当するかによって、レビューの具体的な手法やツールがだいたい決まる。

技術書のレビューの手法

とはいえ、実際にはレビューの具体的な手法やツールがまずあり、その結果として上記の表のいずれかに当てはまるという状況が多いだろう。いずれにしても、誰にどういう方法でレビューをしてもらうかは、レビューに使うツールやプロセスに依存する。そこで、次はツールという観点から上記の表の各セルとの適正について整理してみよう。

バグトラッキングシステムを利用する方法

②と④の場合は、プライベートなバグトラッキングシステムを使うことが多い。自分がかかわるプロジェクトだと、一昔前はTracのチケット、いまではGitHubのissueとしてフィードバックをもらっている。もちろん、TracやGitHubなどのシステム側で不特定多数の参加を許可するようにすれば、⑥の場合にも使える。

バグトラッキングシステムを使うメリットとしては、あるレビュアーが見つけた問題を制作サイドやレビュー陣営全体で共有しやすいことが挙げられる。原稿のバージョン管理をしている場合にはリポジトリに関連付けられたバグトラッキングシステムを使えるので、フィードバックへの対応履歴を管理しやすいというのも魅力。ひとことでいえば、レビュアーとレビューを受ける側のトータルでの負担が最小化される方法だといえる。

レビュアーどうしでチケットやissueで議論ができるので、著者や編集者だけ、つまり制作サイドだけでは思いつかないような解決策が出たり、特定のレビュアーの偏った意見なのかそうでないのかを客観的に判断する材料ができたりするというメリットもある。

デメリットは、レビュアーが見つけた問題をチケットやissueにするときに、指摘したい場所を一意に伝えにくいこと。ほとんどの場合、レビュアーが見る対象というのは、原稿ソースに技術的にアクセスができる場合でも、組版されたPDFである。そのため、一般には「mページのk行め」のような指示方法になるしかないのだけれど、これには次の難点がある。

レビューを受け取る側ではPDFでなく原稿ソースのほうを見ているので、「mページのk行め」という情報は使わず、指摘内容からキーワードをgrepして該当箇所を探している。つまり、「mページのk行め」まで粒度が細かい情報は無駄になってしまうことが多い。原稿ソースが頻繁に更新される環境だと、レビュー対象のPDFと制作進行中のPDFとで場所の乖離がさらに激しくなる
「mページのk行め」のような指摘は、他のレビュアーにとっても優しくないので、指摘のダブりが意外と発生しやすい。ダブりを防ぐために修正ずみの問題をすぐにクローズしないといった運用をしても、なおダブる。そもそも修正ずみの問題をクローズできないのでは、バグトラッキングシステムを使う利点が半減してしまう

場所の指示がめんどうであることに加えて、バグトラッキングシステムを利用することには、レビュアーが他のレビュアーの意見を読めてしまうことによるデメリットもある。

うまく回ればレビュアーどうしの議論によって問題の文脈がはっきりするのだが、ときには議論の発散という形でデメリットになる場合もある
声が大きい有名人がレビュアーにいることで他のレビュアーが委縮してしまい指摘しづらい雰囲気ができたり、そのようなレビュアーの意見に流される可能性がある

まとめると、バグトラッキングシステムを使った技術書のレビューには、手軽に問題を管理できる一方で、指摘箇所を一意に特定するのが困難であり、他のレビュアーとのインタラクションが不可避であるというデメリットがある。そのため、冒頭の表における②のような著者や編集者が議論をコントロールしやすいレビュアーの集合である場合に向いた手法だといえる。 ④の場合には、レビューの要件を具体的に明文化しておく必要があるだろう（もちろん②のケースでも明文化したほうがいいんだろうけど）。一方、レビュアーが他のレビュアーの意見によってバイアスを受けるのを避けたい場合（①、③、⑤）、自転車小屋の屋根の色をめぐる議論に巻き込まれたくないという場合（⑥）には、使えない。

問題点を個別に直接送ってもらう方法

複数のレビュアーがバグトラッキングシステムで相互に意見を交わしながら技術書のクオリティを上げていく作業は、うまく回ると本当に楽しい。それ自体がエンターテインメントだったと感じることも少なくない。しかし、そういう場が醸成されるまでには時間がかかるし、そもそも成功するとは限らない。オープンソースプロジェクトに慣れている著者かどうかという文化的な違いによる困難もある。前述したように、レビュアーが他のレビュアーの意見によってバイアスを受けることを避けたい場合もある。

そこで、著者 and/or 編集者が個別にレビューを依頼し、一対一でフィードバックを返してもらうというケースもかなり多い。その場合には、メールで指摘をもらったり、PDFのコメント機能を使ってもらったり、最近だとDropboxのコメント機能を使うこともある（Google Driveにも同様の機能はあるので使えるかもしれない）。

この方法は、フィードバックをもらうという一点に特化すればもっとも優れている。 Acrobatのレビュー機能やDropboxのコメント機能を使えば、バグトラッキングシステムでは不可避だった指摘箇所を一意に特定する難しさがある程度は解消できるという利点もある。

難しいのは、なんといっても人選。バグトラッキングシステムを利用すれば十数人規模になってもハンドリング可能だけど、個別にやり取りをする負荷を考えると、数人に抑えたいところ。となると、ピンポイントで適切な人に依頼するのが現実的だといえるだろう。そういうわけで、冒頭の表における①や③に向いた方法だといえる。 ⑤でも使えなくはないけれど、というか⑤をやりたいときはこの方法しかないんだけど、制作サイドが個別のやり取りの負荷を覚悟する必要がある。

クラウド上で共有したPDFにコメントを付けてもらう方法

DropboxにPDFを置くと、閲覧できる人が誰でも文字列をハイライトしてコメントをつけられるようになる。この機能は、個別に指摘をもらう場合だけでなく、複数のレビュアーから同時に指摘を受ける場合にも使える。 Dropboxによる方法のメリットは、実施前の手間が最小であること。なにしろ、Dropboxに置いてリンクを伝えるだけでいい。 モダンブラウザがあれば説明不要で直観的に指摘箇所を一意に特定できるのもお手軽さにつながる。

デメリットは、DropboxのPDFビューアーはPDFの仕様に準拠していない独自の拡張で、次のような不自由があること。

書籍全体の検索ができない場合がある。検索対象になるのはブラウザが描画ツリーを構築した部分だけ
コメントのステータスが未解決と解決済みの2つしかないので、複数のレビュアーからの指摘がダブらないようにするにはすべて未解決にしておくしかない。そのため、レビューを締め切るまで取り込み作業がしにくい
個々のコメントにURLが付かないので、議論が始まったコメントや見逃したコメントを通知をたどって追いかけるしかない
PDFデータにはコメントが埋め込まれないので、ダウンロードしてPDFリーダーでコメントを管理することも、PDFデータからコメントを抜き出すこともできない

このような制約があるので、DropboxでPDFにコメントをもらう方法をうまくまわすには、PDFのページ範囲を小さく章単位などに絞ったり、レビューの締め切りまではコメントを解決済みステータスにしないようにしたり、少し工夫がいる。それでも、指摘箇所を一意に特定しやすいというメリットは大きいので、Slackなどの他メディアでレビュアーと制作サイドが気軽に議論ができる②のような状況であれば、かなり魅力的だと思う。

もうひとつ、Dropboxに代表される共有PDFへのコメント書き込みには、指摘がミクロに偏りがちになってしまうという見過ごせない欠点がある。この欠点を補うにも、レビュアーと制作サイドとが雑談できる場の用意が重要な気がしている。

なお、この方法で技術書のレビューが可能なのはDropboxだけではない。 Google Docsにも指摘が行単位になるけど同様の機能はあるし、Adobe Readerにも共有レビューという機能がある。 PDFの仕様にそったアノテーション機能であるAdobe Readerの共有レビューが使えるのがベストなんだけど、Adobe ReaderがLinuxベースの環境で事実上使えなかったり、macOSでもインストールしてない人がいたりするから、つらい。

技術書のレビューをする側の心得

ここまでは、技術書のレビューを受ける側に向けた話だった。ここでは、レビューをするときにどんなことを意識したらいいかについてざっくり書いてみる。ただし、ぼく自身はレビューを受ける側の立場に立つことが多いので、主にレビューを受ける側の視点が多分に混ざります。

レビューでがんばって探しちゃだめな問題

レビューで何を見るべきかを要約するのは難しいけど、がんばって見てはいけない問題というのはある。建前としては「気づいたことを何でも指摘してほしい」なんだけど、何に気付くかは「何に気付こうと思って読んでいるか」に多分に影響されるので、「この点については意識的に探す必要がない」を意識するのはけっこう重要。

誤字脱字など、日本語上のミス
漢字や送り仮名などの表記ゆれ
レイアウトの不備

これらは、「気づいたなら指摘しておく」という態度で読めば十分で、レビューというプロセスでがんばって探すべき問題ではない。逆に言うと、制作サイドの心得として、これらの問題をなるべくつぶした状態でレビューを開始すべきともいえる。

なんだけど、時間的な制約もあるので、現実にはそうでない原稿をレビューすることになる機会もある。そういう問題が多く残っている状態でレビューをすることになった場合には、上記のような問題を一生懸命に探してあげるのではなく、「この章は誤字脱字が目立つけどあとで修正されるのですよね？」といった大局的なコメントを残すのがよい。 技術書のレビューの主眼は、あくまでも第三者の目を取り入れることであり、校正作業のボランティアではないのだから。

レイアウトについても同様で、完成途中のPDFを見るとどうしてもアラが目立つけど、それはやはりレビュアーが気を配る部分ではない。「レイアウトの不備で有意義なレビューが困難である」といった指摘に留めよう。

ミクロな指摘より、マクロな指摘を

誤字やレイアウトの不備にも関係するけれど、第三者であるレビュアーがミクロに指摘したくなるような原稿の問題は、もっと広いスコープでの問題という場合が少なくない。なんか日本語がわかりにくいなあと思って、語の位置を変えたり読点を追加したりしたミクロな修正案を出すのは、実は解決になっていないことが多い。レビュアーがミクロな指摘で解消を試みた問題の根本的な原因は、より広いスコープで原稿の問題を解消できる人、つまり制作サイドでないと対処できないことが多い。

レビュアーとしては、なんか日本語がわかりにくいなあと感じる箇所があったら、「〇〇ということが言いたいんだと思うんだけど、なんか日本語がわかりにくいなあ」と指摘するのがベター。〇〇すらわからないなら、「文意が不明」といったコメントでも十分。

自分にとって理想的な本にする機会ではない

技術書のレビューは、校正作業のボランティア募集にならないためにも、制作プロセスではかなり後の工程になる。つまり、レビュアーとしては、本のコンセプトや表現方法、近日中の出版については了解しているということが前提になる。したがって、内容に間違いがあると考えられるなら指摘すべきだけど、本の表現に対して調整を要求する場ではないという自覚は必要である。

文章に対するレビューというのは、センシティブなプロセスだ。指摘者以外にとってどちらでもいい話であることも少なくない。どちらでもいい話に「どちらでもいい」というのは精神力がいるものなので、はじめから不採用前提くらいの気持ちだとみんなが楽になる。たとえば、同じ内容ならこっちを説明すべきとか、説明の日本語表現はこっちのほうがいいとか、そういう指摘についての最終的な決定権は制作サイドにゆだねる。制作サイドもまじえて議論になり、最終的な文章表現をなにか決定しないといけなくなったところで、代替案の作文をするくらいが双方の負担にならず、ちょうどいい。

逆に、著者や編集者には、無慈悲な独裁者となる覚悟が必要だといえる。そういう意味ではオープンソースのコミッターと同じなのかも。報われないかもしれない指摘であるという点について双方が納得していないと、レビューは回らない。

実践例

いままさに進行中の本の大規模レビューは、冒頭の表だと④、もしくは⑥に近いプロジェクトである。そこで、指摘箇所を一意に特定する部分の困難さを回避しつつ、指摘の重複回避や原稿（他のプライベートリポジトリ）への取り込み状況の管理を可能するために、次のようなレビュー方法を採用した。

フィードバックはPDFのページ単位で受ける。そのために、各ページ用のGitHub issueをあらかじめ全ページぶん用意しておく
指摘をするときの負荷を下げるために、PDFの各ページに、各ページ用GitHub issueへのリンクを埋め込んでおく。そこをクリックすれば、そのページに対するコメントを書き込めるページがブラウザで開くしくみ

さらに、上で紹介した経験則を踏まえて、レビュアーには下記のようなお願いをしている。

PDFを読んでページごとのissueに指摘を追記していってください。代案は不要です。なお、マンパワーの都合でissue上では無反応の可能性が高いです。ごめんなさい。

具体的に指摘をいただきたいポイント

内容の間違い

解説がほしいトピック

意味が取れない段落

下記の指摘も歓迎です（grepをかけるので存在の指摘だけで十分です）

技術用語の不統一

スペルミス、誤字、脱字

下記については、指摘は不要です（最終までには自然に直ります）

日本語表記（漢字や送り仮名）の不統一

レイアウトの不備

その他、局所的な日本語の問題

前半で述べたように、そもそも適切なレビューの手法は要求事項によって変わってくるので、これがベストな技術書のレビュー手法というわけではない。最大で十数人くらい、著者が中心になってSNSなどで直接連絡がつく範囲に依頼するなら、いまのところDropboxへのコメントはかなり手軽に思える。ピンポイントでお願いする人がいる場合も、DropboxへのコメントやPDFへのアノテーションがベストだろう。一方、ある程度の議論が予測されたり、原稿のバージョン管理との親和性が優先されるなら、これからもGitHubのissueを使うと思う。

そしていずれにせよ、レビュアーに何を見てもらいたいか（見る必要がないのか）、レビューにあたって最終決定権は制作サイドの独断的な判断になることについては、何らかの形でレビュアーと制作サイドとで意識共有ができているべき。

RubyでつくるRuby発売中

2018-01-12T14:13:00.001+09:00

カート埋め込みのテスト。デフォルトだと書籍ページへのリンクにはならないのかな。カートに入れてしまったときに画面に常駐するカートボタンは、数をゼロにすると消えるようです。

2018年賀状

2017-12-31T10:36:00.000+09:00

年賀状書いた。

%!
<< /PageSize [285 420] >> setpagedevice

% excerpt from Bill Casselman's 
% "Mathematical Illustrations - a manual of geometry and PostScript"
/ctransform { load
    1 dict begin
    /f exch def
    [{[3 1 roll f {moveto}]}
     {[3 1 roll f {lineto}]}
     {[7 1 roll
       f 6 2 roll
       f 6 2 roll
       f 6 2 roll
       {curveto}]}
     {[{closepath}]}
     pathforall]
    newpath
    {aload pop exec} forall
    end
} def

/f {/y exch def
    /x exch def
    x y fsub 5 y mul cos mul
    y x fsub 3 y mul cos mul
} def

/fsub { % u = sin (a √(30 - (b^2 / 10))) * 460 
    /b exch def
    /a exch def
    a 30 b dup mul 10 div sub sqrt mul sin 460 mul
} def

/setrandcolor { % def
    /r1 {rand 5 mod 3 div} def
    /r2 {rand 7 mod 6 div} def
    /r3 {rand 5 mod 6 div} def
    r1 r2 r3 setrgbcolor
} def

1 1 20 { % for

    /n exch def

    newpath
    /ShowcardGothic-Reg findfont 4 scalefont setfont
    -0.4 9 moveto (2018) true charpath
    -0.1 6 moveto (1820) true charpath
     0   3 moveto (2018) true charpath
    -0.1 0 moveto (1820) true charpath
    /f ctransform
    gsave

    clip
    newpath
    /j {
        /x exch def
        rand x mod x div 30 mul
    } def

    0 5 400 {
        /i exch def
        10 j setlinewidth
         setrandcolor
         0 i moveto
         300 i lineto
         stroke
     } for
 
     grestore
     currentlinewidth 2 mul setlinewidth
     0.1 0 0 setrgbcolor 
     stroke
 
     3 410 moveto
     /Georgia-Bold findfont 5 scalefont setfont
     0.3 0.2 0.2 setrgbcolor
     n =string cvs show
     (/20) show
 
     showpage
 } for

2018 by Keiichiro Shikano on Scribd

今年は球体を作ってみたいなと思って、はじめはエッシャーふうの非ユークリッド空間の円盤への写像を「2018」のパターンで埋めようと思ったのだけど、ちょっと調べたら、それをやるには3つか5つの頂点を持つような「2018」をデザインしてそれを中心から外周へと再帰的に貼り付けていくことになりそうで、デザイン力が要求されるし、コードを書く時間もないから、やめ。正方形を円へと等角写像で膨らませて輪郭を作りつつ、sinをとって膨らみ感を強調し、x軸で多少オフセットして、全体にそれっぽく見せることでごまかしています。

フォントはShowCard Gothicというボリューム感のあるフォントを選びました。

にしても、はじめてPostScript手書きで年賀状を作ってからもう10年になるのかあ。ということで、これを機に過去のぶんもすべてGitHubにまとめておきました。

New Year Cards in PostScript
https://github.com/k16shikano/new-year-car

もともとPostScriptしばりというわけでもなく、なんとなく西暦の文字列を使って世界で1枚だけの年賀状をアルゴリズミックに生成するつもりしかなくて、2009年はPostScriptじゃないしコードも残っていなかった（Gaucheで書き捨てた）。まあでも、よく10年続いたなと思う。

10年続きはしたけれど、年に一回しか書かないこともあり、PostScript力にはたいした進歩が感じられませんね。

TeXでつくるMarkdownパーサ

2017-12-24T14:48:00.000+09:00

この記事はTeX ＆ LaTeX Advent Calendar 2017の24日めのために書きました。

TeXの中でMarkdownを書ける

先月のことなんですが、TeXの、TeXによる、TeXのためのMarkdownパーサをつくました。

markdown-tex
https://github.com/k16shikano/markdown-tex

TeXで実装されてるので、当然、TeXで書く文書のなかで、シームレスにMarkdownを使えます。具体的には、こんな感じに、\begin{markdown}から\end{markdown}のなかにMarkdown記法が書けます。

\documentclass{article}
\usepackage{md}

\begin{document}
\begin{markdown}

# markdown-tex

markdown processor in TeX. 
As inline styles, `tt`, *italic*, and **bold** are available. 

## subsection

Here is a enumerate list.

1. enumerate
1. in 
1. the markdown way

This is an itemize list. 

* this block
* will be
* itemized

And a quotation. 

> Quote Somethin
> Really **Awesome**!

\end{markdown}
\end{document}

これをふつうにTeXで処理すると、記法から期待されるようなPDFができるわけです。

とはいっても、先月の時点でサポートしていた記法はそんなに多くなくて、これくらい。

行頭の「#」の個数に応じた見出し化
行頭の「*」で箇条書き
行頭の「<」でインデント
行頭の数字で連番箇条書き
行頭スペース4個でインデントするとコードブロック化
`..`で囲むとインライン等幅
*..*で囲むとインラインイタリック
**..**で囲むとインライン強調

これ以外の要素を書きたかったら、いったん\end{markdown}して、生のTeXを書いてください。TeXなので、組版に関することなら、なんでもできます。

Markdownの中でTeXを書ける

この記事を読んでいる人はみんなTeX Conf 2017に参加しているので既知だと思いますが、念のため補足すると、このMarkdownパーサはTeX Conf 2017で発表した「TeXは軽量マークアップ言語の夢を見るか」のために作ったものです。この発表では、Markdownをはじめとするマークアップ記法と、TeX（LaTeX）によって得られる表現力との関係について考察しました。「Markdownについて話すのにMarkdownパーサの実装経験がなければ刺されるかも」という強迫観念から取り組んだ、概念実証のための実装です。

TeXは軽量マークアップの夢を見るか from Keiichiro Shikano

で、TeXのなかでMarkdownを使えるからといってうれしいことはあまりないし、それで済ませるつもりだったですが、せっかくTeXなので、先日ちょっと手を入れて\TeXくらいは生で書けるようにしました。その副作用で、コントロールシーケンスや数式も入れられるようになりました！

# markdown-tex

markdown processor in TeX. 
As inline styles, `tt`, *italic*, and **bold** are available. 
Inline equation in \TeX notation $\int_0^1\frac{1}{x}dx = \infty$.

\hfill December 24 2017

## subsection

Here is a enumerate list.

1. enumerate
1. in 
…

しかし、実はこれは誇大広告で、厳密にいうと2つの条件を満たすマクロやコマンドだけがMarkdown記法の中で使えます。

1つめの制約は、完全展開できる必要があるという点です。たとえば、\sqrtは使えません。これは、latex.ltxにおける\sqrtの定義では\@ifnextcharが利用されていて、そのなかでは展開されない\futureletが使われているからです。

なんで完全展開可能性が必要かというと、Markdown記法の構文解析を簡単にするために、対象となるトークンリストをいったん「完全展開された文字列」へと変換しているからです。これにはexpl3の\tl_set_rescan:Nnxを使っています。その際、TeXの入力を完全展開すると空白文字が集約されてしまってMarkdown記法として構文解析できなくなるので、これらは文字列とみなして完全展開しています。

\tl_set_rescan:Nnx \md_tokens
  {
    \char_set_catcode_letter:n {  32 }% SPACE
  } { \BODY }

これで\md_tokens変数に「完全展開された文字列」が入るので、それを構文解析し、それをTeXの胃袋に送ってPDFを作らせる、というのが先月までの実装でした。そんなわけで、この状態でMarkdown記法の中に\TeXと書くと、このマクロが完全展開されたT\kern -..5ex\hbox E\kern -.\@mがそのままPDFに出てきてしまう状態でした。

では、Markdown記法の中に\TeXと書いて期待する出力結果を得るにはどうすればいいでしょうか？完全展開をやめればよさそうですが、前述したようにスペースの扱いの都合があるので、文字列にしてからパースするという方針は変えがたい。となると、完全展開された文字列をパースするときにTeXのプリミティブをパースしてコントロールシーケンスに変換し直し、それをTeXの胃袋に送ればいいのではないか？

というわけで、そんなようなコードを追加して、無事に\TeXのようなマクロがMarkdown記法のなかに埋め込めるようになりました。

\cs_new:Npn \inside_cs:Nnnn #1#2#3#4 {
  \tl_set:Nn \car_line { \tl_head:n { #4 } }
  \tl_set:Nn \cdr_line { \tl_tail:n { #4 } }
  
  \tl_if_head_eq_charcode:nNTF { #4 } { \sp_letter }
     {
       \tl_put_right:Nn #2 { 
         \cs:w #3 \cs_end:
       }
       \exp_args:NNnff \parse_to_end_line_with:Nnnn { #1 } { #2 } { } { \cdr_line }
     }
     {
       \tl_set:Nx \so_far { #3\car_line }
       \exp_args:NNnff \inside_cs:Nnnn { #1 } { #2 } { \so_far } { \cdr_line }
     }
}

ただし、実装をサボっているので、非標準的（？）な利用方法のコントロールシーケンスはパースできません。たとえば、\hbot{foo}はいいけど、\hbox to 10pt{foo}とかはだめ。これがもう1つの制約です。

今回のオチ

にしても、ここまでにやったことを振り返ると、事実上TeXでTeXをパースしているわけで、むだなことをした感が半端ない……。

TeX記法の入力をTeXでパースし、トークンリストが作られた（TeXの仕事）
トークンリストをMarkdown記法としてパースするために、完全展開して文字列化した（\tl_set_rescan:Nnx）
その文字列からコントロールシーケンスを取り出すのに、あらためてTeX記法のパーサを実装に追加した（\cs_new:Npn \inside_cs:Nnnn）

なぜ原稿をテキストで書かなければいけないのか

2017-12-23T12:46:00.000+09:00

これは編集とライティングにまつわるアレコレ Advent Calendar 2017の23日めの記事です。

原稿をどういう形式・記法で書くべきなのか、という質問をときどき受けます。一瞬だけ悩むけど、だいたい答えはこうなります。

「記法はなんでもいいけど、できればテキスト形式で」

今日は、この答えの背景を話します。

まずは「なんでもいい」の部分から。

記法はなんでもいい

出版社や編集者によっては細かく原稿の記法を指定しているようですが、ぼくは特に原稿の記法を決めていません。これは、そういう記法を決めることができずにここまできた、というのが正直な理由です。つまり、ぼくの怠慢なんですが、なにも考えずに怠慢であったというよりは、積極的に怠慢になろうと考えた結果なので、そのへんを少し吐露してみます。

原稿の記法を決めるということは、執筆者の脳内にあるものを吐き出してもらうための形を決めるということです。脳内にあるものを他者に見せるための形を決めるわけではありません。

しかし、書き手が脳内を吐き出すという行為には、「どう見せたいか」という書き手自身の気持ちがどうしても混ざります。この、「どう見せたいか」っていうのは、書く内容に合わせて思いつくものだったり、文章化が難しいから逃げるという側面もあったりするので、書く前から全パターンを網羅しきれるものでもありません。

で、脳内にあるものを吐き出した原稿と呼ばれる何かを、読者向けの見せ方を意識しながら整理する、そんな専門職があります。編集者っていうんですけど、編集者によっては「あるドメインの読者にとってうれしい見せ方」から「適切な吐き出し記法」を逆算し、それを自分のキャリアのどこかの時点できちんと整備して、知見として執筆者と共有できている人がいます。ぼくはそれをサボってきたので、そういう知見をとくに提供できず、「なんでもいいです」という頼りない返事になってしまうというわけでした。

ただし、ここからが重要なんですが、考えなしに「なんでもいいです」といっているわけでもありません。言い訳っぽいですが、吐き出し記法に付随する見え方のほうを意識して見え方に頼った書き方をしてしまったり、汎用のブロック要素を利用した見せ方に依存する書き方が生み出されたり、そういうのを繰り返した結果として、「原稿の記法はあらかじめ決定しないほうがうまくいく」となって現在に至っています。適切な吐き出し記法をいろいろ考えた結果、適切な吐き出し記法を汎用化すると（少なくともぼくには）うまくいかない、というジレンマに陥ったわけです。ポジティブにいうと、好きな記法で吐き出してもらうのが執筆者とぼくにとって楽なケースが多いと判断したということです。

できればテキスト形式で

すでに結論めいたものを書いてしまってますが、どう見せるかの検討に移ってよいのは、脳内にある概念をとりあえず文字列として吐き出し、それを文章にして、さらに段落としてしっかり構成したあとです。もうちょっと正確にいうと、段落の構成を試行錯誤するのと並行して、ようやく見せ方を考えられるようになります。

こんなふうに言うと、「はじめに構成をかっちり固めてから書くんじゃ」という声が聞こえてきそうですが、怒られを恐れずにいえば、それは幻想です。文章を書く前から段落の構成をかっちり固めるには、相当の訓練とあきらめが必要です。むしろ、文字列をダンプしたものから段落を試行錯誤して練り上げることこそが、文章作成の王道だといえるでしょう。

原稿がテキストであることが重要なのは、これが主な理由です。 文字列、文章、段落を行ったり来たりするイテレーションを、コンピュータを使って回しまくるには、テキストデータがいちばん好都合なのです。だから、テキストで書いてください。

さらに、テキストとして吐き出されていれば、編集者が文章や段落をつくる手伝いができます。テキストであればどの環境でもエディタで編集できるから、という面もありますが、もっと大きいのは、テキストであれば差分をとったりバージョン管理システムを利用したりすることで、編集者の作業を執筆者から見て透明にできるからです。

脳内にある情報を原稿として吐き出すのは、たいへんです。それをさらに文章や段落にするのも、けっこうたいへんです。だから、後者のほうを手伝う職業として、編集がいるわけです。しかし、原稿から文章や段落にする過程で、原稿のポイントが失われたり、もともとの執筆者が意図していない情報が紛れ込んだりするのは問題です。この過程では、「編集者がやったこと」がつまびらかになっている必要があります。つまり、編集者の作業が執筆者にとって透明である必要があります。それがコンピュータで不自由なくできるのも、いまのところテキスト形式だけなので、その点でも原稿はテキストにしたいという結論になります。

原稿はソースコード、組版結果はバイナリコード

前述したように、原稿をテキスト形式で書き出し、テキスト形式のまま編集することは、編集者の作業の透明性を高めます。編集者の作業が透明であるということは、作業結果がすべて執筆者の手元で再現できるということでもあります。しかも、バージョン管理システムを使えば、元の原稿に対する差分（の積み重ね）という形で再現できます。

これは、執筆者が自身の吐き出した原稿をソースコードとして保持し、そのゆくすえを終始自分の管理下におけるという意味でもあります。わりと見逃されてる点だと感じてるんですが、「原稿を人に見せる形にまで加工するプロセスが、原稿に責任がある本人にとってアンタッチャブルな状態」って、書き手にとっても編集する側にとっても、けっこう怖くないですか？データとしてアクセスできなければ、どこがどう変わったかをgrepしたり、あとで気づいた用語の間違いを全体にわたって機械的に変換したり、そういう作業が死ぬほどめんどくさくなります。気に喰わない文章や段落を試行錯誤して手直しすることも、気軽にできなくなってしまいます。少なくとも、あとは版面に情報を適切に固定するだけという状態になるまでは、編集者はいうまでもなく執筆者自身も原稿にアクセスできるほうがいいはずです。

原稿に責任がある人が、原稿への計算機によるアクセスを奪われないためには、そもそも原稿がそれにかなった形式である必要があります。その形式として妥当なのは、テキストでしょう。執筆者にもDTPアプリケーションを執筆に使ってもらう、もしくは、執筆者が利用できるワープロソフトで組版もするという可能性もありえなくはないですが、こうした方法は先に言及した「適切な吐き出し形式」に似たジレンマに陥ります。「こう見えてほしい」という気持ちを前提にして吐き出しをすると、しっかりした文章や段落を構成するのが困難になるのです。書いている最中に見せ方を工夫したくなってしまうのは、早すぎる最適化の罠だといってもいいでしょう。まして、WYSIWYG環境で書くのは、バイナリコードを直接いじっているようなものです。（そもそも、見た目の先にある組版という専門性が要求されるプロセスに、非専門家が手軽に介入できる状態はどうなのかという問題もあります。原稿がどう見えてほしいかと、その要求をどう実装するかには、さらに一段階ギャップがあるのです。）

なんだか、ドキュメントにおける構造とスタイルの分離という、よくある話に収斂しているような気もしますね。実際、気のせいじゃありません。この記事で言いたかったことを、構造とスタイルの分離という話に翻訳すると、次のように要約できます。

ドキュメントの構造となる部分の試行錯誤では、テキスト形式を使うのが作業面でもっとも理にかなっている
ドキュメントの構造となる部分は、原稿に責任がある人から最後までアクセスを取り上げるべきでない部分でもあり、それに都合がいいのはテキスト形式である

なお、この記事の趣旨は「執筆や編集にはテキストエディタが最高」ではないので、べつにWordとかGoogle Docs、あるいはIDEなどを執筆や編集に使ってもぜんぜん問題ないです。ただし注意が必要なのは、それらツールにネイティブな形式（.docとか）をソースにしてしまうと、ここに挙げたようなテキストであることの利点が生かせないということです。なので、どんなツールで書くにしろ、どこかの時点ではテキスト形式にして、それを最終的なソース原稿とするのが無難だとおもいます。

記法が決まらないと前に進めないならMarkdown的なやつで

というわけで、文章を書くときは、「とにかく脳内をダンプし、試行錯誤して段落を組み立てる」のが基本です。繰り返しになりますが、脳内を吐き出すときの記法は、どう見えてほしいかという気持ちに無意識に依存してしまいます。その依存を断ち切り、どう見えてほしいかはいったん忘れて文と段落の構成に集中するというのが、一次脱稿でいい状態にもっていくコツ（はやく脱稿するコツではない）です。「段落だけを書く」という覚悟で望みましょう。どんな本にも適用できる決定版の見せ方はないけど、万能の書き方というのは実はあるので、パラグラフライティングをしっかりやってください。

とはいえ、そうはいっても脳内を吐き出すときの記法に何かしら制約があるほうがいいっていう人も少なくないと思います。段落だけとかストイックすぎて無理、見出しの指定方法やインラインの強調方法とか決まってないと書けない、とくに技術書ではコードブロックや図も入れたい、という要求は当然ありますよね。

そんなときは、とりあえず、Markdownふうの記法を使っておきましょう。ここで、CommonMarkか、それともGitHubFlavoredか、といったことを気にする必要はありません。見ためを確認したり、そこからワンパスでHTMLやPDFを生成することが目的ではないからです。ちょっとしたブログ記事ならともかく、どんなMarkdown方言であれ、どのみちMarkdownだけをソースにして本は作れません。 Markdownだけで本が作れたら、XMLとかLaTeXとかとっくに滅んでますね。

まとめ

この記事では、なぜ自由な記法のテキスト形式が原稿の執筆と編集で優位性があるかについて、下記の2点に注目して主張しました。

どう見せるかは考えず、段落の書き込みに集中するためには、見せ方と表裏一体な記法には惑わされないほうがよい
内容に責任をもつ著者や編集者が、自分たちには手が出せない状態になる直前まで計算機を使って原稿を操作するには、データ形式としてテキストが好都合

そのうえで、これらの要求を満足するならツールはテキストエディタでなくてもよいこと、シンプルな段落以外の要素として脳内をダンプする手法としてのMarkdownふう記法の可能性について考えました。

Markdownについては、また明日なにか書くかもしれません。

英語圏のIT系技術書ブランドについての雑感

2017-12-06T09:00:00.000+09:00

この記事はpyspa Advent Calendar 2017の6日めのために書きましたが、アマゾンアソシエイト目的です。

『退屈なことはPythonにやらせよう』が出た

2017年にブレイクしたPythonの本といえば、オライリー・ジャパンから発行された『退屈なことはPythonにやらせよう』ですよね。

実はこの本、そのむかし、自分でも翻訳発行をひそかに検討していたのです。当時の翻訳者候補の方とのDMをさかのぼってみたら、少なくとも2015年7月以前の話でした。「非プログラマーでもプログラミングしようぜ」という趣旨で著された本書は、わたし自身の書籍企画の方向性によくマッチしていました。それで本書に目を付けたのですが、いかんせん分量は多いし、Pythonは日本だと入門者向け言語としていまいち盛り上がらないし（当時の話です）、なにより例題があんまりぐっとこないねという話で、そのときは企画化をパスするという結論を出しました。これは余談にして重要なポイントでもあるんですが、それから起きた出来事を思うと、このとき本書を自分が企画化しなかったのは別の意味でも正解でした。

それから数年たち、Pythonブームという絶好のタイミングで本書が日本語化され、たくさんの人に読まれるに至ったのは、掛け値なしにとてもうれしいことです（ほんとだよ）。逃がした魚は大きい的な気持ちもないではないですが、ぶっちゃけると、オライリーという看板で出たことが本書の日本での普及にとってとても大きなことだったと思います。

さて、ここで「ｱﾚ?」と思う人がいるかもしれません。「この本はオライリーなのに、オライリーの編集者じゃないおまえが企画を検討してたって、いったいどういうこと？」

オライリーの本はO'Reillyの本とは限らない

『退屈なことはPythonにやらせよう』の原書は、O'Reilly Mediaではなく、No Starch Pressという北米の出版社による発行です。

https://www.nostarch.com/

この出版社の名前を聞くのは初めてという人でも、コンピュータ書に関する情報を気にしている方なら、その発行タイトルのなかには知っているものが少なからずあるでしょう。 No Starch Press発行の本で翻訳されているものを、思いつく限りざっと並べてみます（もちろん全部ではありません（たぶん））。

そうそうたるラインナップですよね。さらに面白いことに、No Starch Pressは『マンガでわかる統計学』などの英語版の出版社でもあります。

いまではこんなにすごいNo Starch Pressですが、もとはBill Pollockという人が立ち上げた小さな出版社でした。 2006年にBillさんに会ったころもまだまだ小さい出版社でしたが、この10年くらいで一気に魅力的なラインナップを増やし、いまではIT系技術書界隈でかなりの存在感を示しています。ここでまた余談だけど重要なポイントとして、2006年にBillさんに『マンガでわかる統計学』の版権買ってよという話をするとき、「エディターです」と自己紹介したら、「おれはパブリッシャーだぜ」と冗談で返されたのが自分のなかではものすごい衝撃で、いつかおれもパブリッシャーって名乗るぞとぼんやり思ったのでした（もっともBillさんはぼくのことさえ覚えてない気がする）。

話をもどすと、上記のNo Starch Pressの翻訳書のなかには、『退屈なことはPythonにやらせよう』以外にも、いくつかオライリー・ジャパン発行のものが含まれています。つまりオライリー・ジャパンから発行されている翻訳書は、必ずしも世界的な技術書ブランドであるO'Reilly Mediaのタイトルだけではないのです。オライリー・ジャパンの中の人は、No Starch Pressをはじめ、さまざまな海外の出版社からこれはと思う良タイトルをO'Reilly Mediaに限らず探してきて翻訳発行しているわけです。これぞO'Reillyというカバーだけど動物の版画でない本がけっこうあるのは（宇宙人までいる）、そういうわけなのです。

No Starch Press以外で、日本ではO'Reillyブランドの技術書として誤認されてるんじゃないかなと感じてる本としては、たとえばこんな例があります。

上記6点は、すべて原書出版社がちがいます。当ててみよう。（Hayao(-ε-δ)‏ さんに教えていただいたのでアソシエイト効果がありそうなほうを追記しました。Hayao(-ε-δ)‏ さんありがとうございます！）

なお、逆のパターンである「O'Reillyの本がオライリーから出ているとは限らない」も真です。ただし、最近はO'Reilly Mediaのラインナップの魅力が落ちてるのと、O'Reillyブランドで魅力的なのはオライリー・ジャパンがしっかり出してくるので、ほぼオライリー・ジャパンから出てきているように見えます。

動物だけではない英語圏の技術書ブランド

ここまで長々とアマゾンアソシエイトを張りまくってきましたが、ここからが本記事のタイトルでもある「雑感」です。

2017年現在の英語圏におけるIT系出版社のブランド地図は、たとえば2000年代前半のそれとはかなり変動しています。 2000年代前半は、その当時で創業20年くらいのイケイケO'Reilly Mediaに圧倒的なブランド力がありました。しかし現在は、この記事でも一押しのNo Starch Pressはじめ、やはり中堅どころのManning Publicationsなど、現時点で創業20年前後を迎えている中小の出版社のほうがむしろ精力的に面白い書籍を生み出している印象があります。彗星のごとく登場してあっというまに手堅い出版社となったPragmatic Bookshelfも、これから創業20年前後にかけて、もうひと化けするかもしれません。

そうした出版社に比べると、すでに40年近い歴史を持つO'Reilly Mediaは、経営規模で見ても大手出版社として網羅的なラインナップを擁し、中小出版社の書籍の発売元として流通を支える存在にまで成長していますが、発行書籍の面白さとかクオリティという点では最近ぱっとしないなというのが率直な感想です。それに呼応するように、いま企画が好調なオライリー・ジャパンが、少なくとも翻訳書についてO'Reillyタイトル依存でなくなっているというのは感慨深いところです。そういえばオライリー・ジャパンも、いまちょうど創業20年ちょっとですね。

一方、O'Reilly Mediaよりさらに老舗のPearsonや、そのハイエンドコンピュータ書籍のレーベルとしてのAddison-Wesleyは、タイトル数こそ多くないですが、IT系技術書出版社としての信頼感はいまなお顕在だなあと感じることがわりとあります。タイトルに対する信頼感という意味では、The MIT PressやCambridge University Pressなどの大学出版系も依然として強くて、これからも日本語で読めるようにしていくべきだと思えるような本はこのへんの老舗出版社のものがますます多くなるのかも、と思っています。

精力的といえば、英国を拠点に爆発的にラインナップを増やして一気に存在感を増したPacktという出版社もあります。 Packtの特徴は、とにかく最速であらゆるIT系のトピックについて書籍の形をしたものをそろえるという戦略です。そうしたラインナップ網羅主義は、ある意味ではO'Reilly Mediaが目指してきたところだとも思います。ラインナップ網羅主義には、個別のタイトルの出来不出来をケアできないという面があるので、個人的には避けていきたい方向性ですが、いかんせん展開が速いので、Packtの傾向にも注目だけはしていこうと思っています。

今回のオチ

日本語圏におけるIT系技術書の状況については、あまり大きなことを言える立場にないですが、いろんな人たちの紆余曲折とか踏ん張りとか地道な出版活動とかあって、いろんなブランドが盛り上がったり、消えたり、地に落ちたり、新しく誕生したりしています。

そんななかで、この記事をここまで読んでアマゾンアソシエイトを踏まなかった方には、2017年に4つのタイトルを発売して始動したラムダノートというIT系技術書出版社の名前を覚えてもらえるとうれしいです。

TeXでつくる『RubyでつくるRuby』

2017-12-03T21:41:00.001+09:00

この記事はTeX ＆ LaTeX Advent Calendar 2017の3日めのために書きましたが、宣伝目的です。

TeX ＆ LaTeX Advent Calendar 2017の重点テーマは「TeXでつくるアレ」とのことですが、偶然にも2017年、よく似たタイトルの『RubyでつくるRuby』（遠藤侑介著）という本が出ました。プログラミング言語を学ぶときの例題としてプログラミング言語をつくる以上に格好のネタはない、という趣旨の本です。

プログラミング言語をつくるというと、なにやら難しく聞こえるかもしれませんが、『RubyでつくるRuby』では、わずか150ページのなかにそのエッセンスを凝縮しています。本文の理解を助けるかわいらしいイラストもフルカラーでふんだんに用意されているので、はじめてプログラムを書いてみようかなという人でも、おそらく（願わくば）読み通せる内容です。電子書籍はなく、古き良き紙の本のみですが、電子版がいいという人はAscii.jpでもとになった連載が読めるので、そちらをどうぞ！

プログラミング言語の処理系が扱うデータは「木」

『RubyでつくるRuby』では、プログラミング言語Rubyで書かれたプログラムを処理して実行するプログラミング言語を、プログラミング言語Rubyでつくります。つまり、本書の読者が書くことになるプログラムが処理するのは、Rubyのプログラムです。

Rubyに限りませんが、多くのプログラミング言語では、プログラマーが書いたプログラムを実行する前に、そのプログラムをまず「木」と呼ばれる種類のデータへと変換します。この「木」は、その名のとおり樹木のような姿をしていて、「枝がのびる節」と「葉」があります。

このへんは、文章で説明するよりも、絵で見るほうがはやいでしょう。たとえば、次のようなRubyのプログラム（四則演算だけですが）がどんな木になるかというと……

(1 + 2) / 3 * 4 * (56 / 7 + 8 + 9)

こんな木になります。式で見るより、項どうしの演算の関係がわかりやすいですね。

本書の解説には「木」を扱う場面がたくさん出てくるので、説明文やコードに加えてこんな具合に木の絵をたくさん用意できれば、いま説明しているデータの姿がどんなようすなのか「ひとめ」でわかります。なので、ぜひ木の絵はたくさん載せたい。

かといって、こういう木の絵をぜんぶイラストレーターさんに描いてもらうのもたいへんです。描くほうだけでなく、間違ってないかチェックするほうもめんどくさい。それなりの見た目で、なおかつ間違いなくプログラムの木を描くには、どうすればいいでしょうか？

そう、TeXを使えばいいのです。実際、上に例として出した木もTeXで生成しています。

TeXで木を描く

というわけで、前置きが長くなりましたが、『RubyでつくるRuby』の木の絵をTeXでどう描いたかをちょっと紹介します。書籍『RubyでつくるRuby』では、プログラムの木を、Rubyにおける配列表現からTeXで生成しました。これなら手間もかからず、なにより作図にともなう間違いもありません。

tikz-qtreeパッケージの使い方

木は、プログラムに限らずいろいろな場面に出てくるデータ構造なので、関連するTeXパッケージがわりとたくさん出そろっています。そのなかで『RubyでつくるRuby』の木を描くのに選んだのは、 tikz-qtree というTikZベースのパッケージです。

https://ctan.org/pkg/tikz-qtree

この tikz-qtree パッケージを選んだ理由のひとつは、上下逆向きの木構造を手軽に描けることです。木構造を描くときは、根を上にする（つまり本物の樹木でいったら上下逆）ことが多いのですが、本書の場合にはイラストにある本物っぽい木の絵とシームレスに読み替えてもらいたいので、根を下にして木構造を描ける機能が重要だったのです。

tikz-qtree のミニマルな例を示します。これは 2 * 4 というRubyプログラムの「木」の例です。

\documentclass[tikz,convert={outext=.png}]{standalone} 
\usepackage{tikz-qtree}
\begin{document}

\begin{tikzpicture}
  \Tree [.*
          [2 
           \node[draw]{4};
          ]]
\end{tikzpicture}

\end{document}

\Tree[ ] のなかに、木を描いてきます。 [ ] を入れ子にすると、その中に書いたものが子どもの要素になります。要素としてスペース区切りで値を書き込めば、それが葉になります。子を持つ要素には、値の前に「 . 」をつけます。上の例では、根にあたる「 * 」に「 . 」が必要です。さらに上の例では、TikZの \node 命令がそのまま使えることを示すために、「4」のほうだけ枠をつけてみました（ \node 命令なので末尾に ; を忘れずに！）。

上記を tree.tex として保存し、以下のようにpdflatexで処理すれば……

$ pdflatex --shell-escape tree.tex

こんな絵が得られます。

この木の上下をさかさまにするには、 tikzpicture 環境に [grow'=up] というオプションをつけるだけです。

\documentclass[tikz,convert={outext=.png}]{standalone} 
\usepackage{tikz-qtree}
\begin{document}

\begin{tikzpicture}[grow'=up]
  \Tree [.*
          [2 
           \node[draw]{4};
          ]]
\end{tikzpicture}

\end{document}

このままだと絵として味気ないので、色をぬったり、枠の形を変えたり、線の幅を調整したりするわけですが、そのへんはTikZの \node をごにょごにょいじるというつまらない話なので割愛します。 TikZのマニュアル（むかしは400ページくらいでしたが、いまでは1000ページ超）を片手にがんばってみてください。

TikZソースを木のソースから生成する

木の見た目を整えたら、毎回TikZを手描きするのはばかばかしいので、プログラムで生成するようにします。『RubyでつくるRuby』で描きたいのはプログラムを表す木で、その木はRubyコードとしてはこんなふうな姿をしています。

["*", 2, 4]

本当は、 2 とか 4 が何ものであるかを表すために、もうちょっとメタ情報がついていますが、だいたいこんな感じです。（そもそも、配列でプログラムの木を表すのはあくまでも『RubyでつくるRuby』の中に限定した話で、じっさいのRubyではまったくべつの表現方法です。）

これはどう見てもS式なので、カンマを削除してGaucheで直接読み込んで変換し、 tikz-qtree パッケージを使った木を描くTeXソースを吐くようにしましょう。

(use srfi-13)
(use text.tree)

(define (deco-b b)
  #"\\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\\small ~b};")
  
(define (deco-l l)
  #"\\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\\mystrut\\smash{~l}};")

(define *before-tikz* "\
\n\\begin{tikzpicture}[grow'=up] \
\n  \\tikzset{ \
\n    every tree node/.style={font=\\ttfamily\\large}, \
\n    edge from parent/.append style={very thick}} \
\n  \\Tree ")

(define *end-tikz* "\n\\end{tikzpicture}\n\\clearpage\n")

(define *before-doc* "\
\n\\documentclass[tikz,border=10pt,convert={outext=.png}]{standalone} \
\n\\def\\mystrut{\\rule{0pt}{1.3ex}} \
\n\\usepackage{tikz} \
\n\\usepackage{tikz-qtree} \
\n\\usetikzlibrary{shapes.geometric,shadows}% \
\n\\begin{document}\n")

(define *end-doc* "\n\\end{document}\n")

(define (tikzqtree ts)
  (list *before-tikz* (mkqtree ts) *end-tikz*))

(define (mkqtree ts)
  (cond ((null? ts) "")
        ((pair? ts) (mkbranch
                      (car ts)
                      (map mkqtree (cdr ts))))
        (else (mkleaf ts))))

(define (mkbranch b l)
  (list "[." (deco-b (x->string b)) "\n " l "]"))

(define (mkleaf l)
  (list (deco-l (x->string l)) " "))

(define (main args)
  (call-with-input-file (cadr args)
    (lambda (p)
      (print
       (tree->string
        (list
         *before-doc*
         (map tikzqtree (port->sexp-list p))
         *end-doc*))))))

カンマをプログラムで削除しないのは、カンマなしならS式としてそのままreadできるからです。この手のユーティリティはコーディングが簡単なほうに倒してガッっと書いてしまうのが肝要だと思います。

実行結果

最初に紹介した、わりと複雑なかっこうをしている次のようなRubyの計算式について、プログラムの木を描いてみましょう。

(1 + 2) / 3 * 4 * (56 / 7 + 8 + 9)

この計算式は、『RubyでつくるRuby』ではこんな感じの木（配列の配列）として表されます。

["*", ["*", ["/", ["+", 1, 2], 3], 4], ["+", ["+", ["/", 56, 7], 8], 9]]

この一行をファイルに保存して、カンマだけエディタで削除し、先ほどのGaucheスクリプトで読み込むと……

$ gosh mktree.scm temp.rb > temp.tex

こんな気持ちの悪いLaTeXのソースができます。

\documentclass[tikz,border=10pt,convert={outext=.png}]{standalone}
\def\mystrut{\rule{0pt}{1.3ex}}
\usepackage{tikz}
\usepackage{tikz-qtree}
\usetikzlibrary{shapes.geometric,shadows}%
\begin{document}

\begin{tikzpicture}[grow'=up]
  \tikzset{
    every tree node/.style={font=\ttfamily\large},
    edge from parent/.append style={very thick}}
  \Tree [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small *};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small *};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small /};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{1}}; \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{2}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{3}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{4}}; ][.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small /};
 \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{56}}; \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{7}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{8}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{9}}; ]]
\end{tikzpicture}
\clearpage

\end{document}

これをコンパイルすると……

$ pdflatex --shell-escape temp.tex

冒頭に掲載したような、こんなきれいなpngファイルが得られるというわけでした。

まとめ

『RubyでつくるRuby』を読むと、このような「木」がプログラムそのものだということがわかります。このように生成された図だけでなく、hirekoke画伯描きおろしカラーイラストも豊富に掲載された『RubyでつくるRuby』をいますぐ買おう！

繰り返しになりますが、電子版はラムダノートでは出版していないものの、Ascii.jpでもとになった連載が読めます。ぜんぶ無料！

LLイベント2017の「第2プログラミング言語鑑定団」で鹿野が話したことまとめ

2017-08-21T12:36:00.000+09:00

プログラミング好きにもいろいろあって、仕事で使ってる道具をもっと知りたいという人もいれば、自分が使ったことない道具の話を知りたいという人もいれば、道具はなんでもいいから面白い話がしたいという人もいます。久しぶりに参加したLLイベントは、そんな多様なプログラミング好きが「全員がアウェーな立場」で交流するという、貴重で面白い機会でした。実際、「LL」の1つめのLには去年までは「Lightweight」という意味があり、その単語が示す特徴をもった言語のイベントのようにどうしても見えてたんですが、今年からはそういう区切りも公けになくし、Lは「Learn」の意味になったとのことです。

そのLLイベント2017で、「第2プログラミング言語鑑定団」というセッションに出させてもらいました。司会の小山さんが「Teratail, Yahoo知恵袋などから、それらしい質問をかき集めてマージ」した6パターンの「次に学ぶ言語は何がいい？」に対し、鑑定団の一人としてお勧め言語を紹介せよというのがミッションでした。ぼく以外の鑑定団のメンバーは、ささけんさん、高野さん、高橋さん。一癖あるすごいITエンジニアばっかりだー。このメンバーが集まるというだけで、LLイベントすごいって気持ちになりました。

いっぽう、ぼく自身はただの書籍編集者です。自分の仕事に必要な道具を作ったり環境を整えたりはするけどエンジニアというわけではないし、プログラミングは好きで勉強はするけど研究者ではないし、本職ではない人間になんという無茶ぶりかと思って最初は躊躇したのですが、たぶん、この記事を書かせてもらったことをきっかけに声をかけてもらえたんだろうなあ。

employment.en-japan.com

なお、上記の記事は「ElixirとRustとHaskellにちょっと興味がある人向けの紹介記事を各界の第一人者に書いてもらおう」という企画の前フリなので、そういう目線でやさしい気持ちで読んでもらうと幸いです。 ElixirとRustはすでに公開中。今月中にHaskellも公開される予定です（宣伝）。

ほかの鑑定団の回答

そもそもブログで自分の回答を書くつもりはなかったんですが、ささけんさんがさっくりと自分の回答をまとめて公開したので、まとめざるを得なくなった。

LL2017 プログラミング言語鑑定団資料 from Ken SASAKI

［高野さんと高橋さんが何か公開されたらリンクはる予定地］

鹿野はどんな言語を勧めたか

想定質問は事前に見せてもらってたのですが、じゃあその質問に対して何を答えることが求められてるんだろうというのは、正直なところ当日になってもわからなくて、会場に着くまでは「ちょっとまずいかもなあ」と暗い気持ちでいました。で、それを一緒に来ていた同僚に愚痴ったところ、「お勧め本を紹介したらいいじゃん」という画期的な入れ知恵をしてもらい、その路線でいくことに決めたのでした。

質問1

文系の大学4年生のときにプログラミングが好きになり、独学で C と Java の初歩を学びました。卒業後Web 制作会社に入社し、HTML, CSS,JavaScript を習得しました。Web周辺だけでは将来が不安なので、次に何を学ぶべきか考えています。アドバイスをいただけないでしょうか。

この質問を最初にみたときは「知らんがな」という思いしか去来せず、サイコロでも投げて決めろと言いたかったのですが、言語じゃなくて書籍であれば紹介すべきものがすぐに思いつきました。五十嵐先生の『プログラミング in OCaml』です。なので、回答は「OCaml」にしました。

あらかじめ断っておくと、ぼくはOCamlを実用してるわけではありません。 OCamlのコードをいじったのは、『型システム入門』を作ったとき、OCamlで書かれた原著者ビルド環境を日本語pLaTeX向けに改修したときくらいです。ですが、この本は、OCamlを使うつもりがとくにない人でも、独力でプログラミングを学んできたような人であれば、読むといいことがたくさん書いてあると思っています。具体的には、OCamlというプログラミング言語でのプログラムの書き方だけでなく、どうしてそういう機構になっているのかがいちいち詳しく解説されており、プログラミング言語の理論についても味見できるようになっています。この質問者はWeb周辺の技術を追いかける以外の勉強をしたいようだし、そういう意味でもぴったりではないかと思いました。

質問2

文系大学に通う学生ですが、昔からゲームが好きで、将来はゲームクリエイターになりたいと考えています。そうはいってもプログラミングはまだできないし、特筆したスキルもありません。ゲームクリエイターに関する書籍を読んで、将来こんなゲームを作りたいと夢を膨らませています。私がゲーム開発者になるためにはどの言語から学ぶのがよいでしょうか?

ゲーム作りたいといってる時点で、プログラミング言語を選んでる場合じゃなく、むしろどのゲームエンジンを使ってみればいいかという話なんですよね。なので、回答は「Unity」か「Unreal Engine」にしました。

書籍として紹介したのは、『Unreal Engine 4で極めるゲーム開発』です。無責任にも自分では読んでないんですが、渋川さんが激烈に勧めているので間違いないでしょう。

質問3

Web制作会社でサーバサイドを開発しているソフトウェアエンジニアです。現在使っているプログラミング言語はRubyでフレームワークはRailsです。最近世の中でAIや機械学習がブームになっていて、私もそちら方面のスキルを磨いてより高度な作業をできるようになりたいと考えています。AIや機械学習を使いこなすのに最適なプログラミング言語は何でしょうか?

機械学習で縛られてる設問なので、Pythonからは逃げられないような気がします。ということで、回答としては「Python」。

でも、たぶんPythonを学べばどうなるものでもなく、線形代数なんかを地道に復習したほうがいいような気もします。そのへんからかみ砕いて解説されているという点で、書籍は『ゼロから作るDeep Learning』をお勧めにしました。

質問4

SIerとして大手案件の2次下請けを仕事にしています。主に使っている言語はJavaでフレームワークはStrutsです。噂ではStrutsにもSIerにも未来はもう無いそうで、転職して他の仕事もできるようになりたいのですが、これまでJavaしか使ったことがないのでどうしたら良いか分かりません。これから学ぶのならば、なるべく長く役に立つ技術が良いと思うのですが、何がよいでしょうか。

「長く役に立つ」といったら、これまで長く使われてきた実績があり、これからもそう簡単に消えることはないであろう言語しかないだろうということで、「Common Lisp」か「Haskell」と回答しました。

書籍はそれぞれ『実践Common Lisp』と『すごいHaskell』を紹介。このへんは我田引水させてもらいました。

質問5

プログラミング初心者です。Webサイト作成のためにPHPの学習中ですが、他の言語にも興味があります。しかしなかなか難しいのもあって効率的なプログラミング学習法はないかと頭を悩ませているところです。そこで、おもしろそうと興味を持てば学習がはかどるのではと考えました。面白いプログラミング言語とその理由を教えてください。

面白いプログラミング言語といったら、とりあえずこれを押さえておけということで、「Brainfuck」です。とはいえ、Brainfuckでプログラムを書くんじゃなく、好きな言語でBrainfuckを作ってみたらという提案をしました。やっぱり、プログラミング言語ってこういうことなんだという実感を得るには、なんでもいいから作ってみるのがいちばんで、そのためにもBrainfuckの実装には一度は挑戦してみると楽しいと思います。

というわけで、お勧めした書籍は『Rubyで作る奇妙なプログラミング言語』。

質問6

インフラ運用エンジニアをしています。使える言語はシェルです。仕事ではたくさんのOSSを使用していますが、これらは書かれている言語がC,PHP,Python,Ruby,Node.js,Javaなど多岐にわたります。最近は自動化がブームですが、OSSを使って自動化をやっていくために、どのような言語を学ぶのがよいでしょうか。

OSSのツールを利用していくのに知っておいたほうがいい言語で、質問に出ていないものといって思いつくものは、「Go」しかありませんでした。というわけで書籍としては『プログラミング言語Go』です。

いま思い返すとPerlとかLuaという選択肢もありえましたが、やっぱりあの場でお勧めする言語としてはGoしかありませんでした。なぜなら、Goはラムダノートから近日中に新刊が出る予定だからです。アスキーjpで連載していた「Goならわかるシステムプログラミング」の書籍化です！昨日のLLイベントでも「低レイヤをかじることの重要性」は何度か強調されていて、そのたびにCやアセンブラというキーワードが出ててましたが、いまならそれこそGoで楽に学べます。そういう趣旨で好評の連載に、著者の渋川さんが少し話を追加して、10月くらいに出せるように頑張って制作中。お楽しみに（宣伝）。

質問7（会場からの飛び入り質問）

小学三年生の息子がプログラミングをはじめるのに、Scratchのほかにどんな選択肢がありますか？

小学生にプログラミングを教えるときって、ビジュアル言語じゃない形でコンピュータの開発環境に触れる機会も必要だと思ってるんですよね。かといって、汎用言語はそこそこ覚えないといけないことが多くてつらい。そこで、覚えることが最小限で、コンピュータの生っぽいところを意識できる言語があればいいんですが、その条件を満たす言語はSchemeくらいしかありませんよね（異論は認める）。というわけで「Scheme」をお勧めしました。

参考書籍はもちろん『計算機システムの構造と解釈』です（いまおもうと『Scheme手習い』という手もあった）。

編集というサービスの内容（技術書編）

2017-06-21T13:20:00.000+09:00

技術書の編集者が原稿に対して何を提供するものなのか、整理してみた。順番には意味があります。

原稿をDTP担当者が作業できるデータにする
誤字脱字、非標準的な表記を直す
表記を統一する
文法の間違い、不適切な言い回しを直す
構成の不備、内容の間違いを指摘する
構成の不備、内容の間違いを直す
冗長な内容、文脈から外れる記述を欄外に追い出したり、段落構成を手直ししたりする
段落や文を、文脈に合わせた相に書き直す
行間をうめる
解説画像やイラスト、索引などのメタ情報を作る
原稿を書く
【番外】企画する

どこまでやってほしいか、できるか、追加料金がいくら必要なのかというのを、著者・版元編集者・下請け編集者の間ではっきりさせると、みんなが幸せになる気がする。（だいたい編集外注するときって「編集作業一式」の「ページあたりの単価」になりがちで、しかしその「一式」には上記のような幅があるわけだから、人によって高いとか安いとか感じ方がいろいろ変わってしまうよね……。）

本として書店に並ぶまでに必要な作業は上記のほかにもいっぱいあり（装幀の企画と手配、権利、印刷製本、流通に関連するいろいろな仕事などなど）、上記に挙げた編集業務を担当編集者がぜんぶやるべきという話ではないはず。

たとえば、上記のうち5までは担当編集者が直接やるけど、残りは外部の査読者だったり編集者だったりを雇うことにするとか、あるいは、そこは著者の仕事であると最初から割り切る（ということを著者との間で同意しておく）ほうが、結果的に読者が手にする本にとって最善というケースもあるかもしれない。

なお、弊社では上記のすべてに対応した編集業務の受注が可能です。お気軽にご相談ください。

2017年賀状

2016-12-30T23:24:00.001+09:00

年賀状書いた。

%!PS
<< /PageSize [285 420] >> setpagedevice

/setrandcolor {% def
    /r1 {rand 5 mod 3 div} def
    /r2 {rand 4 mod 4 div} def
    /r3 {rand 3 mod 4 div} def
    r1 r2 r3 setrgbcolor
} def

/f {% def
    dup dup dup
    4 mod 0 eq {(2) 4 1 roll -1 0 rmoveto} if 
    4 mod 1 eq {(0) 3 1 roll -3 0 rmoveto} if 
    4 mod 2 eq {(1) 2 1 roll -3 0 rmoveto} if 
    4 mod 3 eq {(7 ) -5 0 rmoveto} if
} def

/i 4 def

/lineto-chars { % def
  /ex x def /ey y def
  /y exch def /x exch def
  /d x ex sub dup mul y ey sub dup mul add sqrt def
  /R y ey sub x ex sub atan def
  R rotate
  { d 0 le % ifelse
    { exit }
    { setrandcolor 
      /ra rand 5 mod 3 div 10 mul 22 add def
      /Georgia-Bold findfont
      [25 0 0 ra 0 0] makefont setfont
      i f show
      /i i 1 add def
      /d d 7 sub def }
  ifelse
  } loop
  0 R sub rotate
} def

1 1 20 { % for
  /n exch def

  newpath
  0 0 moveto
  135  45 moveto
   85 140
  110 165
  110 130 curveto
  0 0 moveto
  150 130 moveto
  155 190
  210 140
  130  40 curveto
  flattenpath
  {/y exch def /x exch def}{lineto-chars}{}{} pathforall
  gsave
  
  32 230 moveto
  0.9 0.1 0.2 setrgbcolor
  /Georgia-Bold findfont [90 0 0 100 0 0] makefont setfont
  (2017) show
  
  grestore
  showpage
} for

2017 by Keiichiro Shikano on Scribd

PSの解説でよく登場する、パスに沿った文字列描画の簡易版です。まずflattenpathしてカレントパスをlinetoの配列に変換したあと、各linetoが描く直線がX軸になるまで回転→linetoの長さまで数字を順番に書く→回転を戻す、を繰り返しています。どのへんが簡易版かというと、グリフを書き終わったポイントは当然ながらオリジナルのパスからはずれているのだけど、そこへ戻す処理をさぼっています。そのため、ベースになるパス（ハート型）よりも文字列の描く図形のほうが肥大していく、それもフォントや処理系によってずれ幅がけっこう違ってしまう、という緩い仕様です。このコードはWindowsのDistillerに合わせてあります。 gsだと、なぜかずれがもう一回り大きい。

過去のやつ。

JSONをTeXで組版する

2016-12-24T02:54:00.000+09:00

昨今、ドキュメント技術の主戦場といったらウェブです（ワールドワイドなほう）。ウェブ上ではさまざまな構造化テキストが飛び交っています。まっさきに思いつくのは、HTMLをはじめとする、ブラウザがネイティブにレンダリングできる構造化テキストでしょう。

しかしブラウザにはJavaScriptという強力なプログラミング言語の実装が組み込まれているので、HTML以外の構造化テキストをサーバから取得して整形する場合も少なくありません。そのようなデータ形式のひとつにJSONがあります。

最近のWebサービスでは、サーバからHTMLを送らずにJSONデータだけを送り、ブラウザがそれをJavaScriptで解析して画面表示をすべて動的に作っている場合もあるようです。この場合にブラウザがやっていることは、ある種の自動組版だといえるでしょう。そもそもブラウザによるHTMLのレンダリング自体が自動組版だという見方もできますが、それよりさらに抽象化した、JSONを原稿とする自動組版という考え方です。必ずしもページ全体をJSONから表示していなくても、たとえばJSONデータから表を生成してdiv要素に差し込むといった局所的な組版もありえると思います。

ブラウザとJavaScriptでできることがTeXでできないはずがない

というわけで、TeXでJSON組版をしてみました。題材としては、CTANの各パッケージのJSONクエリとかも考えたのですが、残念ながらCTANではパッケージの詳細説明の項目にプレーンテキストではなくHTMLが直書きされている場合があるようです。 TeXで扱うのにHTMLタグは邪魔でしかありません。まさかCTANともあろうものが、TeXでJSONデータを利用することを考えていなかったなんて。

それに、どうせならもっとクリスマスらしい題材にしたいところです。クリスマスといえばホワイトクリスマス、ホワイトクリスマスといえば雪だるま。雪だるまを組版するなら天気予報でしょう。 OpenWeatherMapという会社のサイトで天気予報をはじめとする気象データをJSONにより取得できるので、これを組版していきましょう。

Weather API - OpenWeatherMap

天気予報JSONデータの取得

まずはデータの取得です。TeXからHTTPリクエストを発行する汎用の手法はないので、cURLでもwgetでも好きなものを使ってください。 OpenWeatherMapでサインアップしてAPPIDを手に入れれば、たとえば下記のようなURLによって、東京の5日後までの3時間おき予報データが取得できます。

http://api.openweathermap.org/data/2.5/forecast?q=Tokyo,jp&APPID=0000000000000

参考までに、取得できるのはこんな形のJSONデータです。

{"city":{
  "id":1850147,
  "name":"Tokyo",
  "coord":{"lon":139.691711,"lat":35.689499},
  "country":"JP",
  "population":0,
  "sys":{"population":0}},
 "cod":"200",
 "message":0.0103,
 "cnt":37,
 "list":[
    {"dt":1482483600,
     "main":
       {"temp":9.94,
        "temp_min":8.84,
        "temp_max":9.94,
        "pressure":1015.88,
        "sea_level":1017.11,
        "grnd_level":1015.88,
        "humidity":71,"temp_kf":1.1},
     "weather":[
       {"id":802,
        "main":"Clouds",
        "description":"scattered clouds",
        "icon":"03n"}],
     "clouds":{"all":36},
     "wind":{"speed":6.71,"deg":318.003},
     "rain":{},
     "sys":{"pod":"n"},
     "dt_txt":"2016-12-23 09:00:00"},
     ...

JSONデータのTeXによるパーズ

JSONデータを取得できたら、パーズします。JSONを読むパッケージが見当たらなかったので、ざっくり再帰下降パーザを書きました。TeXは関数型言語なので、素直に書けますね。

https://github.com/k16shikano/jsonlite/blob/master/jsonlite.sty

公開APIは以下の3つ。

・\readJson #1 #2
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータが格納される

・\readJsonValueById #1 #2 #3
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータの、第三引数の名前に対応する値が格納される

・\showJsonValueById #1 #2
第一引数に渡したJSONデータの、第二引数の名前に対応する値が入力に残る

ちょっと例を見てみましょう。青字になっているのがJSONデータです。

\documentclass{article}
\usepackage{jsonlite}

\begin{document}

\readJson{\json}{{"id":[1,2,3], "class":"foo", "data":{"id":"456"}, "info":"Is this a text?"}}
\readJsonValueById{\jsonId}{\json}{"id"}     %=> expl3 sequence
\readJsonValueById{\jsonData}{\json}{"data"} %=> id:456

\readJson{\jsonJsonData}{{\jsonData}}
\showJsonValueById{\jsonJsonData}{"id"}      %=> 456

\end{document}

天気予報JSONデータを表組する

OpenWeatherMap社から提供される天気予報JSONデータから、都市名、予報の時刻、予想天気、予想気温を取ってきて、LaTeXの表として組みましょう。各時刻の予報は、"list"という名前の配列の各要素になっているようです。この配列に対するmapで、表の各行を整形するという戦略にします。実はjsonliteパッケージではJSONの配列をexpl3のシーケンスとして保持するので、シーケンス用のmapが使えます。

\NewDocumentCommand{\showForecast}{ m }{%
  \begin{longtable}{ l | c | r}
    日時 & 空模様 & 気温 \\\hline
    \endfirsthead
    日時 & 空模様 & 気温 \\\hline
    \endhead
    \seq_map_function:cN #1 \format_forecast:n
  \end{longtable}
}

TeX言語のくせにシーケンスとかmapとか、お前はなにを言ってるのだ、という感じかもしれませんが、2016年にもなればそういうものなんです。そもそもTeXは関数型言語なのだからシーケンスに対するmapくらいできないはずがありません。

あとは、\format_forecast:nを書いていくだけなんですが、 OpenWeatherMap社のデータで"weather"がさらに配列になっていたりして無駄にめんどくさいので解説は省略します。 jsonliteパッケージと同じディレクトリに完全なコードを置いてあるので参考にしてください。

https://github.com/k16shikano/jsonlite/blob/master/weather-forecast.tex

天気記号のサポート数がそこそこあるDejaVuSansを使いたかったので、XeLaTeXで実行してみた結果がこれです。DejaVuSansの☃はどことなく品がいいですね。

ところで、Brzozie（ブジョジェ）という地名がどこなのか気になった人がいるかもしれません。ブジョジェはポーランドの湖水地方で、バホテク湖があるところです。来年のTUG2017は、このバホテク湖で毎年開催されているBachoTeXというイベントと合同で5月に開催されることになっています。なんとか参加するぞ。

そしてこの記事は、第五回となるTeX&LaTeXアドベントカレンダーの24日めの記事です。昨日はアセトアミノフェンさん（この記事を見てDejaVuSansを使うことを思いつきました）、明日の最終日はZRさんです。

独立系出版社をやるという覚悟について

2016-12-03T00:51:00.000+09:00

カナダ最大の都市であるトロントから北に向かって1時間ちょっと、荒野だか畑だか牧場だかよくわからない広大な土地を走り抜けたところに、エリンという小さな村があります。 19世紀に開拓された当時からメインストリートであったと思われる道が、川の蛇行している部分を堰き止めるように貫いていて、その両脇だけで主な商圏が形成されているような素朴な村です。

そんな小さな村に、なんと出版社があります。その名もThe Porcupine’s Quill。直訳すると「ヤマアラシの針」ですね。言うまでもなく独立系の出版社で、大手からは陽の目を見るのが難しいカナダ発の文学者やアーティストの作品を手掛けているようです。

今年の7月、この《ヤマアラシの針出版》を訪問する機会がありました。世界中のTeX関係者が集まるTUGという会合があるんですが、2016年の開催地がトロントで、その一環として《ヤマアラシの針出版》の見学会が組まれていたのです。トロントからエリン村まで農道（もしくは牧道）を延々とかっ飛ばし、パン屋さんの前でマイクロバスを降りると、その何軒か隣の靴屋みたいな建物が《ヤマアラシの針出版》の本社でした。

こんなカナダのど田舎に本社を構えているというだけで十分に話として面白いんですが、この出版社、他の多くの出版社と違って、印刷から製本まで本づくりのすべてを自前でやっています。それも、ドイツ製のオフセット印刷機やら製本機やらを社内に一式すべて用意し、経営者であるティムさんと奥さんのエルクさんが手作業で本を作っているのです。ちなみに、やや出来過ぎ感がありますが、お二人の姓は「インクスター」さんといいます。

これが、さっきの建物の地下にあるHeidelberg Kordというオフセット印刷機。とてもよく手入れされていて、油でてかてかしています。インクが香ばしい。

こちらは建物の1階に実装されている、本をかがるための機械。ファンシーな窓の鎧戸と陽光のせいで博物館の展示物っぽいけど、むちゃくちゃ軽快に稼働します。

正直なところ、訪問前にはそれほど大きな期待はしていませんでした。自分とは畑違いの文芸系の出版社っぽいし、そもそも出版社の仕事なんてどこも大差ありません。

しかし実際に《ヤマアラシの針出版》でティムさんから「どういう考えで本を企画し、作り、それを売ってきたか」を語ってもらい、ビンテージな機械が力学を駆使して本を作り上げるようすを目の当たりにすると、いちいち唸りっぱなしでした。出版社っていうのは、こんなふうに本を作って売るっていう仕事であり、その骨格がまさにいま自分の目の前に展開されてるんだなと。

出版社の仕事なんて、確かにどこも大差ないけれど、誠実にやっていくと結局は「モノづくり」になるんだよなという気持ち。
電子書籍もいいけど、モノとしての物理は単純に強いなという気持ち。
年間ノルマで本の形を整えなくても、こんなふうに、やりたい人がやりたいように出版をやれるのが健全だよなという気持ち。
ぼくも、完全に同じやり方ではないかもだけど、こんなふうにして本にかかわっていくぞという気持ち。

なにをかくそう、ぼくも自分で出版をやりたいと思って、昨年2015年の12月1日にラムダノート株式会社という会社を作りました。今年2016年の7月にThe Porcupine’s Quillを訪問して、自分が仕事としてやりたいことは「本を作って買ってもらうこと」なんだなと再確認しました。来年2017年の2月ころには、最初のタイトルとして、TLSの関連書を発行する予定です。年が明けてしばらくしたら直販サイトで予約できるようにする予定（予定）なので、ご期待ください。

そういえば、この最初のタイトルは翻訳ものなんですが、原書を発行しているロンドンの出版社もやっぱり独立系出版社でした。そっちもそっちで4月に訪問してたくさん刺激を受けたので、翻訳発行後にあらためてどこかで話ができればいいなと思います。

なお、この記事はラムダノート株式会社の設立にあたって出資して頂いた株式会社時雨堂の社長になんか書けといわれ、pyspaアドベントカレンダー2016のエントリーとして書きました。pyspaには脱サラする直前からずっと癒されてきました。でも、昨日はイアンさん、明日はモリヨシさんだし、あきらかに場違いな記事だろこれ。

主観でプログラミング言語5種類をあっさり解説

2016-07-01T10:36:00.000+09:00

現在プログラミング言語は200種類存在していると言われてるようですが、これはたぶんLisp族の言語だけを数えた値です。

あるプログラミング言語（汎用のもの）がどんな用途に適しているかは、人によって大きく意見が分かれるので、用途を絞ったからといって適したプログラミング言語が決められるわけではありません。そもそも今日の世界における用途が明日の世界にも存在するとは限らないし。

この記事では、ぼくがHello Worldくらいは書いたことがある言語5種類をあっさりと解説しようと思ったけど、そんな知識もないので、「プログラミングしてみたい人向け、言語に関する5つのアドバイス」です。学習しない言語の選択に役立ててください。

Go

それなりに具体的で明確な「Cを使う」理由があるのでない限り、Cで学べるようなプログラミングはGoで学んだほうがいいと思います。

HaskellかOCaml

これといった目的もなくプログラミングを始めたいなら、静的型付き言語で始めるほうがいろいろ実りがあると思います。異論は認めるけど。 HaskellやOCamlであれば、現代的なアプリケーションを試しに作ってみるのに必要なライブラリもそれなりに充実しています。

Scheme

Schemeがいいのは、コンピュータがなくてもプログラミングを学べる点です。Schemeの実装は黒板だと言われるくらいです。

正規表現

特定のアプリを意識した言語でプログラミングし始めるよりも、正規表現をひととおり自在に使えるほうが、最初のうちは役立つ場面が多いと思います。 Rubyとかも、最初は正規表現全開な感じでテキストフィルタを書いてみるのがいいと思います。

先生や友だちや同僚がよく知っている言語

というわけで、ぼくの近くにいる人はTeXから学ぶことになります。

特殊エンジニア向け数学ガイドツアー本『グッド・マス』の話

2016-06-20T10:21:00.000+09:00

6月25日、つまり今週末、『グッド・マスギークのための数・論理・計算機科学』という本が発売されます。話せば長い事情があって、発売前だけど訳者の次くらいに書籍の内容を熟知しているので、私的な紹介を書いてみました。

計算機のプロが書いた現代数学ガイドツアー

世に数学系の読み物はたくさん出版されています。純粋数学のプロが書いたものもあれば、そうでない人が書いたものもあります。『グッド・マス』は、後者です。著者のマークさんは計算機科学のプロであり、数学のプロではありません。そのため、本書でいう「数学」も、コンピュータエンジニア的な目線で描かれます。たとえば、連分数の話をするときはScalaで実装し始めるし、論理学の話をすれば「Prologはいいぞ」って始まるし、計算といったらチューリングマシンとBrainfuckでありλ計算です。本書を一言で表すと、「コンピュータエンジニア、とくにプログラミング言語とか大好きっ子にとって興味深いであろう観光名所をめぐる現代数学ガイドツアー」です。日常の言葉で抽象数学を分かりやすく伝える系の読み物を期待して読み始めると、肩透かしを食うと思います。

ちなみにですが、そういう方向で数学ネタを気軽に味わいたいとしたら、いまなら"Cakes, Custard and Category Theory"という本が面白いと思います。『ケーキ、カスタード、それに圏論』というタイトルどおり、後半はまるまる圏論の何がおいしいのかを説明するのに割かれています。こないだ翻訳も出たようです（邦題には「圏論」ってないけど）。

この"Cakes, Custard and Category Theory"という本の著者であるEugenia Chengは、生粋のプロ数学者ですが、ユーチューバ―として有名だったりもします。

ナイフを振り回しながら教壇に立つチェン先生かわゆす。

『グッド・マス』の話だった

閑話休題。『グッド・マス』のゴールは、日常の言葉で抽象数学を語ることではなく、コンピュータ好きなら知っていて損のない数学ネタを一通りさらうことです。とくに重視されてるのは、公理的に、論理を使って、構成的に数学という体系を捉える方法を伝えることです。著者のマークさんは、冒頭の第1章から、数学の対象を日常的な感覚だけで語らないよう読者に促します。エンジニアになじみのある日常的な感覚にも頼りつつ、数とか集合、証明といった対象を、現代数学というルールで捉えるやり方を正面から見せてくれる感じです。数学の教科書とは違う方法で、コンピュータ好きな人が「生の数学」を味見する本だといえるでしょう。これが本書の貴重なところだと思います。

もともと単発の記事をまとめた本ということもあって、あからさまなストーリーもなく、面白そうな部分だけをつまみ読みできます。「数って何？」みたいな前半の軽めの話題だけ読んでもいいし、Prologを使って一階の述語論理を学ぶ第4部だけ眺めてもいいし、公理的な集合論のノリをさらってみるだけでもいいでしょう。特に最後の第6部は、正規表現とか再帰、λ計算、型といったプログラミング言語好き向けの話題で占められているので、この辺だけ読むのもお勧めです。とはいえ後半は「数学をやってる現代人が暗に共有している意識を部外者が垣間見る」ことができるような構成になっているので、論理を扱っている第4部くらいからは順番に読むことをお勧めします。自分は、はじめて原書を通しで読んだとき、第1章の自然数の説明でのっけからペアノの公理を持ち出してきたのも後半のためのネタ振りだったのかーと納得しました。

一方、『グッド・マス』にはあまり登場しない数学の話もたくさんあります。解析とか位相に関するネタは本書にはまったく出てきません（ε-δのわかりやすい解説はないし、ドーナツとマグカップがどうこうみたいな話もない）。圏論もないです（Haskellのコードは出てきますが、正規表現の微分を実装するのに使われます）。このへんの話題については期待しないでください。

あと、いわゆる一般人向け数学の本で必ず引き合いに出される黄金比については完全にコケにされているので、そういうのが好きな人は注意してください。目次を見ると黄金比を扱っている章がありますが、これはマークさんが「おれは黄金比をもてはやす連中が嫌いだ」ということを表明するためにある章です。黄金比ネタが好きな人にはこの本はお勧めできません。

もうひとつ触れておきたいのは、なるべく読み手が飽きないようにしたいと思うあまりにマークさんの筆がちょくちょく滑るという点です。ところどころ自由すぎる解釈で書き進めてしまった内容を、コンピュータ系技術書版元であるPragProgsには編集しきることができなかったのか、原書には突っ込みどころのある箇所や単純なミスがけっこう残っています。ただし、そんな暴走気味の部分はcocoatomoが訳注などでしっかり引き締めてくれているし、翻訳版のレビューをしてくれた方々（計算機と数学の両方に足をかけてるプロばかり）にも細かい部分まで目を通してもらえてるので、原文の微妙な勘違いはかなり補正されていました。翻訳版は、私が企画時にぼんやり思い描いていた以上に、かなり安心して楽しめる内容に仕上がっていると思います。

というわけで6月25日発売の『グッド・マスギークのための数・論理・計算機科学』、コンピュータをふだんから使っていて、もうちょっと数学的な考え方を知りたいよという人には、とっかかりとしてお勧めです。

個人的なあとがき

本書のもとになっているのは、主に「数学」に関連したネタを扱う英語圏では有名な古参のブログ "Good Math / Bad Math" です。 "Good Math / Bad Math"は、いまほどインターネット上に一般向け数学ネタが溢れていなかったころから勢いのある筆致で数学系の記事を量産してきたブログで、幾度かの移転を経て現在でもわりと活発に更新が続いています。

"Good Math / Bad Math"
http://www.goodmath.org

過去には『マンガでわかる統計学』の英語版に対する肯定的なレビューがアップされたことなんかもありました。『マンガでわかる統計学』は英語版もかなりよく売れたんですが、その認知度はこのブログにおける紹介記事で一気にあがった感があります。（ただしシリーズ全体の認知度として見ると、Boing Boingで『マンガでわかるデータベース』がネタ的に扱われたことのほうが大きい）

"BOOK REVIEW: THE MANGA GUIDE TO STATISTICS"
http://www.goodmath.org/blog/2008/12/13/book-review-the-manga-guide-to-statistics/

自分はたまたま『マンガでわかる統計学』の英語版に少し関与していたこともあって、それからしばらく"Good Math / Bad Math"の記事をちょくちょくチェックしていました。そんなある日、「このブログをもとにして本を出すよ」という記事が掲載されます。しかも出版社はPragmatic Bookshelf社とのこと。 Pragmatic Bookshelf社といえば、『RailsによるアジャイルWebプログラミング』とか『プログラミングErlang』とか『情熱プログラマー』といったIT系書籍で有名な版元です。これは面白い本になるに違いないと思いながら、続報を待つこと4年、ようやく2013年にベータ版の書籍が発売開始になったのでした。

さっそくβ版を自分で買ってKindleに突っ込み、一通り目を通してみて、「間違いなくそのうちどこかで日本語版が出るだろうな」と確信しました。と同時に、あちこちマークアップの変換結果がコケていたりして、商品としての出来には微妙なところも感じていました。Pragmatic Bookshelf社では独自形式のXML原稿から紙の書籍と電子書籍を生成しているんですが、それなりに数式が多く含まれる本書の原稿に対し、その変換処理の調整がいまいちうまくいっていないのは明白でした。

「どうせ日本語版が出るなら訳本には自分自身が関与したい、いやむしろ、自分が関与せずに日本語版が作られたら書籍として残念な出来になってしまいかねないぞ」というわけのわからない使命感に駆られ、当時所属していた出版社で版権を抑えたうえで翻訳に興味がある有識者がいないかなーと思ってこんなツイートをしてみたのでした。

というわけで、あの伝説の数学ブロガーMARKCCによるプログラマ向け数学入門の "Good Math" を翻訳したいわけですが
— keiichiro shikano λ♪ (@golden_lucky) 2014年4月23日

このツイートに見事に引っかかってくれたのが、そのちょっと前に「スタート代数」という勉強会を主催していたcocoatomoさんでした。自分もスタート代数に何回か参加していたことから、お互いに何となく面識があったこともあって、企画を通して翻訳を進めてもらうまでは実に順調に話が進みました。原著の原稿データから日本語版のPDFを自動生成する環境はこちらで用意し、cocoatomoさんにも翻訳をこまめにgit pushしてもらっていたので、あとは日本語版が少しずつ形になっていくのを時々眺めていればいいという、（個人的には）きわめて理想的な感じで制作が進んでいきました。

ところが、翻訳がずいぶん進んで編集もぼちぼち開始し、これからいよいよ制作も本格化しようという段階になって、自分自身が会社を辞めるしかないという不測の事態になってしまいました。発行までの実務は会社に残った同僚に引き継げることになったし、cocoatomoさんの好意でその後も翻訳制作の作業にリモートで口を出し続けることはできたのですが、直接の担当者として最後まで携われないまま辞めるというのは正直つらい選択でした（念のため補足しておくと、もっとつらいことがあったので辞めた）。

その翻訳版が、ついに6月25日に発行されることになりました。感無量です。数式を含むマークアップの変換についても、仕込んでおいたCI上での作業プロセスを外注で回してもらえたので、書籍として申し分ない感じに仕上がっていると思います。いまの僕には、この本がものすごく売れても特に利益的なものはないのだけど（アマゾンアソシエイトについてはよろしくお願いします）、手に取ってもらう人が増えればとてもうれしいです。

Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ

2016-06-08T16:49:00.001+09:00

これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。

とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。

しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。

まず「認識が違う」と思うのは、プレインオールドでない方法も部分的にはすでにけっこう導入されているという事実です。とくに自分は、全面的に「マークアップ原稿を最後の最後までGitHubで管理する」ための仕組みをもう何年も実際に運用して売り物の本を作ってきました。なので、「出版の中の人は現代的なプラットフォームを使えない」と言われると、どうしても「ぼくはちがうもん」と言いたくなるんですが、なんで自分はできてるのか、という点についてはあとで改めて書きます。

もう一つ、「出版のための現代的なプラットフォームが必要」という話に対して「うーん」って感じてしまうのは、 ルールが決まってる組版で自由な表現をするための仕組みはどうするの？という点に対する回答がないことです。これは、原稿の形式と版管理ではどうにもならない問題です。

実際にそういうプラットフォームで売り物の本を制作してきた経験からすると、毎回いちばん頭を悩ませるのは、プラットフォームをチューニングして、「今回のプロジェクトで作りたい形の本を作れるようにする」部分です。毎回同じ体裁で似たような本を作るなら、yamlなどの設定を書き換えることによるシステム的なチューニングだけで済むかもしれません。というか、実際に済んでいます。それでも、そのチューニングができる人が出版社の中に必要になるんですが、その程度なら、まあ、システムのお守りをする人がプロジェクトごとに担当者に要件を聞いて調整すればいいでしょう。頭が痛いのは、「この本では見出しでこんな表現をしたい」とか、「強調をいくつか使い分けたい」とか、「標準的ではない構成にしたい」とか、そういう個別の本の中身に対する要求に合わせたチューニングです。

そういう要求を吸収できるようにシステムを作りたいということであれば、Markdownの原稿では絶対に無理（無理）なので、素直にLaTeXでもなんでも既存のプラットフォームを使おうよ。。（本音）

勝手が許されない「組版」と、自由な「レイアウト」と、それを吸収するプラットフォーム

出版物は、特に紙の本は、歴史がそれなりにあるので細部のルール（いわゆる組版）がわりときっちりしてます。そのルールを逸脱していると、単純に読みにくい本になります。このへん、ブラウザのレンダリングに任せればいいという発想でWebページを作るのとは違っているので、たとえソースがXMLベースの原稿でも、本気のページ組版のためには、通常のブラウザエンジンではなく専用のフォーマッターが使われています。もしブラウザのレンダリングエンジンでJavaScriptとCSSを使ってきちんと組版しようと思ったら、専門の会社を一つ作らないといけないレベルで大仕事です。

そんなわけで、出版物というのは、組版というミクロな部分の見た目についてはあまり融通が利きません。誰でも使えるInDesignというアプリケーションがあるのにDTPがプロの仕事として成立してるのは、一昔前の業種がいつまでも生き残ってるのでも、デザインセンスが必要だからだけでもなく、組版という仕事が本質的に専門知識を要求されるものだからです。

そうはいっても自動組版したい人、軽量マークアップの原稿を機械的に組版したい人にとっての選択肢は、いまは主にバックグラウンドでLaTeXを使うプラットフォームになると思います。で、そのLaTeXですが、ご存じのとおり鬼門ですよね。もっとも、Markdown+PandocやSphinx、Re:VIEWでとりあえずページ組版されたものを出すなら既成のスタイルを使うだけなので、とくに苦労はいりません。

問題は、ちょっと違った見た目にしたり、新しいレイアウト要素を追加したかったりする場合です。これにはLaTeXのコマンドを使って自分でスタイルを書くしかありません。しかも、新しいレイアウト要素を追加するにはそれだけでは済まず、ソースにおける構造とレイアウトとのマッピングを定義する必要があります。自分は、このような拡張が簡単にできないと死ぬと思ったので、かなり早い段階でそのためのDSLを開発してました。これまで十年くらい、「マークアップしたテキスト原稿を版管理」しながら「本として最後まで作り込む」という環境を実現できてたのは、こういう仕組みを作ったからです。

なお、これは自分だけでなく、「マークアップしたテキスト原稿を版管理」しながら「成果物として最後まで作り込む」を実現している人は、だいたいこのような構造とレイアウトのマッピングをする仕組みを自分たちで作り上げてるようです、というのを昔開催した「版管理＋自動組版」という勉強会で知りました。

厄介なのは、そういう仕組みを「誰もが使える」ようにする点です。 GitHubのようなベースとなるプラットフォームを使い始めてもらうためのハードルが高いわけではありません。自分の経験だと、毎回の書籍原稿における文書の構造とレイアウトを実現するメカニズムの両方をそれなりに理解しないといけないのが唯一の障壁です。そういうことを考えたい人が中に常駐していないと、プラットフォームがあったところで、多様な個々の本に対してそれを適用し続けることができないのです。

むしろ問われてるのは出版ビジネスの考え方かも

というわけで自分は、軽量マークアップのテキスト原稿をGitで管理して本にするという簡単な仕組みが出版社の中に普及しないのは、そういうプラットフォームを使って勝手が許されない組版かつ自由なレイアウトを実現しながら本を作り込もうとする人が足りてないことが大きな理由だと思っています。

もっとも、これは「出版する本は作りこむべきだ」という個人的な思いによる分析なので、単純なプラットフォームで実現できる形の本だけで出版というビジネスを回してやろう、という大胆な発想もありえると思います。そういう発想を追求したい場合は、米O'reillyのAtlas+Safariのような仕組みや、Pragmatic Bookshelf社の取り組みについて調べてみるとよいと思います。

TeXと10年戦ってわかったこと

2016-05-14T11:46:00.000+09:00

世間では「TeX」と一口に言われているけど、実際には3つの異なる側面があります。10年以上TeXで何かやってきたわけだけど、「TeXはアレ」の本質はこの3つがごちゃごちゃになってるとこかなと思ったりしているので、書いてみました。

マークアップ形式としてのTeX
組版エンジンとしてのTeX
プログラミング言語としてのTeX

TeXの話をするときって、これら3つが案外と区別されていないなあと感じることがあります。具体的には、組版エンジンとしての機能について言及している場面でマークアップ形式の話を持ち出されたり、マークアップの話をしているときに名前空間がないからダメといった感じでプログラミング言語として批判されたり、ようするに、あまり建設的ではない。

もちろん、TeXというエコシステムについて何か言うときにはこの3つが不可分で、それぞれを切り出して論じてもしょうがないんだけど、まあポエムなので気にしないことにします。

マークアップ形式としてのTeX

TeXのマークアップというと\と{}がやたらに出てくるアレを思い浮かべると思いますが、「いわゆるTeXのマークアップ」と見なされているものに厳格な文法とかルールはありません。よく、「XML自体はマークアップではなくマークアップを作る仕組みを提供するものだ」と言いますが、TeXはさらにひどくて、シンタックスさえもが自分の知っているTeXでない可能性があるのです。

現状のTeXは、いろいろな人や団体が過去に考案してきた「マークアップ」を、使う人が自分のユーザ文書の用途に応じて混ぜて使っている状態だといえます。なので、たとえば「TeXのマークアップのパーザがほしい」といった要件を満たすものがあるとしたら、それはTeXそのものになります。この、ユーザが目的に応じていくらでも変更できる余地がある、というのが、マークアップとしてのTeXの革新的かつ悲劇的な点なのかなと思っています。

とはいえ、だいたい用途ごとに「デファクト」のマークアップはあって、たとえば文章そのものに対する基本的なマークアップの文法でいま主に実用されているのはLamportさんが拡張したLaTeXです。この、LaTeXで導入され、現在に至るまで主に使われている「いわゆるTeXのマークアップ」は、なかなかよく考えられているなあと思います（もとをただせばScribeのアイデアだし）。数式に対するマークアップも、Knuthが考えたオリジナルTeXにおける数式の書き方を延々と使っているわけではなく、現在ではアメリカ数学会AMSが拡張したやつが広く使われています。 TeXの中で図を使うためのマークアップは、文章や数式とは別体系で、これはいまはTikZが主流になっています。

拡張したマークアップをパーズするための仕掛けはプログラミング言語としてのTeXで作ります。また、その出力であるレイアウトは組版エンジンとしてのTeXで実現します。

というわけで、TeXのマークアップはひどい、ふつうの人には無理、という意見は、種々のマークアップが混在していることからくる感想なのかもしれないと思います。 \や{}や$はオリジナルのTeXに沿って使われることが大半なので、どれも構文は緩く似た感じになり、「えー、なんでこんな一貫性がないのー」って感じますよね。できることに制約がないので、たとえば「○○用のマークアップとかないし、別の表現にするか」という発想にならず、「○○したいだけなのにこんな複雑なことをしなければならないのかくそが」という感想になりやすいという面もあると思います。

文章に対するマークアップとして見た場合、LaTeXのマークアップは別に筋は悪くはないんじゃないですかねえ。現代的な構造化もできるし、もちろん必要に応じて拡張もできる（←そこがアレ）。「マークアップ形式拡張のためのAPIを設計するセンス」を養う本とかどこかにないかなあ。

組版エンジンとしてのTeX

一部のアレな人以外、TeXを使う目的は組版でしょう。これについては、あまり批判的な人はいない気がします。 TeXは当初から組版のための要件がかなり高く、しかもそれが一通り実現されています。さらに、それなりに長い歴史のなかで、本職の組版技術を知る人たちが自分たちの必要とする付加的な要件を本気で実現してきました。そのため、ほとんどの人にとっては、世界中の多くの言語で実用的なブラックボックスとして機能できていると思います（ふだん使っているTeXが組版についてブラックボックスに見えない人は、マークアップとしての側面と混同しているか、ただの組版のプロでしょう）。

プログラミング言語としてのTeX

なんというか、KnuthはもともとTeXをプログラミング言語として設計するつもりはさらさらなかったんじゃないかなあと思います。自分の秘書でも使えるようなマークアップを自分で後から定義できるだけの機能を詰め込んだら、必然的にチューリング完全になってしまったというか。あるいは、組版エンジンとして必要だろうなーと思う機能を作りこんでいて、その機能を外部からつつけるようにしたら、必然的にチューリング完全になってしまったというか。とにかく、プログラミング言語としてのTeXにまともな設計思想はない気がするし、プログラミング言語として使いやすくする開発とかもされてこなかった。なので使いづらいのは当然だし、使いづらさを楽しむのもまた一興かもしれません。そもそもこれだけの機能がなかったら、後に続く人たちが「自分たちも仕事で使える」ものに魔改造できなかっただろうし（←その結果がアレ）。

とはいえ、そうも言ってられないという人たちは一定数いて、その先鋒がLaTeX3プロジェクトです。それこそもう10年以上の歴史があるけど、過去のTeX資産を壊さないように慎重に開発が進められているので、いつになってもLaTeX3は完成しません（←だからアレ）。

とはいえ、LaTeX3のうちプログラミング言語として利用できる部分については現在のLaTeX2eでも使える状態にあります（expl3という）。使いやすいかどうかはともかく、名前空間が実現できたり、関数っぽいものが定義できたり、プログラミング言語としてはふつうになってると思います。次の10年に期待ですね（それまで選択肢がTeXしかないのも微妙だけど）。

執筆・編集のためのGit（GitHub）ワークフローを考えてみた

2016-05-02T10:07:00.001+09:00

まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。

とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。

もちろん、同じソフトウェア開発でもプロジェクトの種類や参加者の考え方によって最適なワークフローは異なるだろうし、ソフトウェア開発で成功するワークフローが執筆・編集には適用できないなんていうことでもありませんが、こうやったら技術書を作る時にうまくいった、あるいはうまくいかなかったという経験に基づく考察をここらでいったん公開しておくのは悪くないかなと思ったので、まとめてみました。

なお、あくまでも経験に基づいた独断を書きなぐったものなので、これが正解と主張するものではないし参考文献とかもありません。また、バージョン管理システムとしてGit（GitHub）が前提の書きっぷりになると思いますが、これも自分の経験に基づく話だからというだけです。が、だいたいどのバージョン管理システムでも通用する話であろうな、とは想像しています。

正史モデル：伝統的な文章のバージョン管理ワークフロー

執筆・編集というプロジェクトの実態

執筆・編集には2つのフェーズがある

「じっくり読まなければ何となくいい感じ」が分水嶺

表面的な問題：統一感と文の品質

根本的な対策：段落や節にまたがる俯瞰的な修正

執筆・編集にとって最適（いまのところ）だと思っているGitワークフロー

余談：「じっくり読まなければ何となくいい感じ」に到達したことを知るには

正史モデル：伝統的な文章のバージョン管理ワークフロー

旧来、印刷して出版される文書は、初校、再校、念校、下版といった形式でバージョン管理されていました。複数の関係者がいる場合には著者の代表や編集者が全員の意見（赤字）をマージして一つの修正指示を練り上げ、それが次の校正に反映されるというワークフローです。つまり、正史が一つだけ存在するモデルです。

この伝統的な正史モデルのワークフローに、バージョン管理システムを適用したいとして、いちばん分かりやすいのは次のようなマイルストーンの細分化でしょう。

従来であれば数日から数カ月おきに確定するバージョン（初校とか再校とか）の間に、バージョン管理システムを使って細かくコミットを重ねていくイメージです。さらにこのワークフローを突き詰めれば、初校や再校といった従来のマイルストーンの役割も消えて、全期間にわたってコミット履歴だけが並ぶことになるでしょう。もちろん何らかのマイルストーンは設定することになるでしょうが、いずれにせよワークフローとしてはあくまでも一直線です。

このワークフローでは、みんなが同一のmasterに対してコミットを重ねていくため、誰かの作業内容が妥当であるかどうかを意識的に確認する役割の人がいるのがベターです。ただし経験では、そのような役割を特定に人に押し付けるのではなく、関係者全員が「あれっ」と思った時点で履歴を検索して適宜blameや再修正をかけられるような空気があるほうが、うまく回ることが多かったと思います。そのような空気は、関係者どうしの広帯域なコミュニケーションを通じて醸成されますが、メール（メーリングリスト）、バグトラッキングシステム（TracやGitHub issue）、会議システム（SlackやSkype）を複数併用していた場合にわりとうまくいっていた印象があります。

執筆・編集というプロジェクトの実態

正史モデルのワークフローには、従来型の延長なので比較的導入しやすいというメリットがありますが、制限もあります。このワークフローでは、どのコミットも、それまでの作業を塗りつぶして上書きする作業として扱います。あとからコミット単位でrevertしたりrebaseしたりすることをあまり考慮していないワークフローだということです。

せっかくバージョン管理システムを使うのだから、作業の内容を明確化してブランチを切ったり、それをあとからチェリーピックしたりマージしたり、逆に過去に加えた変更をなかったことにしたり、そういうことができるほうがうれしいですよね。正史モデルに拘泥してアドホックな上書き修正を積み重ねるのではなく、修正の意図や作業内容に応じてコミットをきっちり切り分けることで、原稿の変更による手戻を防いだり差分を見やすくしたりできるはずです。

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

もちろん、だからといって文章の執筆・編集では正史モデルで徹頭徹尾やるべきという話ではありません。これまでの経験で感じるのは、うまくコミットとして切り分けられる問題もあれば、コミットとして切り分けるのが徒労でしかないような問題もある、という単純な事実です。この二種類の問題を整理したところ、執筆・編集という作業には2つのフェーズがあり、この両フェーズを意識するとそこそこ最適なワークフローが説明できそうだなと気がつきました。

執筆・編集には2つのフェーズがある

正史モデルの説明では、「脱稿」以降のワークフローについてバージョン管理システムを使うかのように説明しましたが、あれは嘘です。バージョン管理システムを使って、共著者、編集者、外部のレビュアーによる共同作業を始めるのは、脱稿よりも前の段階、具体的には「内容をすべて書き出した」時点であるべきです。

ここが重要なんですが、「内容をすべて書き出した」時点は脱稿とは異なります。「内容をすべて書き出した」時点は、ソフトウェア開発でいうと、まだ最低限の機能がコンパイルすら通っていない状態です。ここから待っているのは下記のような作業です。

段落や節の見直し、統廃合、順序の入れ替え
それにともなう文章の書き直し、表現や語調の調性
全体にわたる用字用語（漢字の使い方とか）の統一、誤用や誤植の修正
タグやメタ情報（ルビとか索引とか）の修正、追加

各作業について具体的な内容には踏み込みませんが、ようするに、全体にわたる読み直しとリライトを何度か繰り返すことで、これらの問題をひとつずつ潰していく必要があります。そうやって確認と修正を繰り返していると、あるときふいに原稿が「じっくり読まなければ何となくいい感じ」になっていることに気づきます。このへんでようやく、ソフトウェアでいえば警告を無視すればコンパイルが通った状態、つまり本当の意味での「脱稿」の一歩手前です。

「じっくり読まなければ何となくいい感じ」が分水嶺

「じっくり読まなければ何となくいい感じ」ゾーンまでくると、文書の骨組みや各文に対する大幅な修正は起こりにくくなります。したがって、「どこそこのタイポ修正」とか「この文を修辞的に書き換える」とか「この段落は内容が疑わしい」といった具合に、文書に存在する問題を局所化できる場合が多くなります。「どの箇所にどんな修正がなぜ必要か」をかなり具体的に切り出せるようになるということです。

修正が必要な箇所と、その意図をはっきり区分できるのだから、修正の妥当性や方針をissueで議論したり、必要だと判断できた修正を切り分けたり、そういった作業が現実的になります。「じっくり読まなければ何となくいい感じ」にまで到達した原稿に対しては、issueやブランチを切ったうえで、それに従ってコミットを細かく管理したりPull Requestを発行したりするワークフローが可能だともいえます。

問題なのは、まだ「じっくり読まなければ何となくいい感じ」に到達していない原稿です。この段階になっていない文章を読むと、「どの箇所にどんな修正がなぜ必要か」をはっきりとは明言しにくいけれど、とにかく何かしら修正が必要であると感じます。経験上、この段階の原稿が抱えている問題の多くは、切り分けが困難な問題です。そのため、バージョン管理という視点で考えると、作業を分担したり作業内容に応じたコミットやブランチを駆使しようという努力があまり実を結ばない気がしています。

表面的な問題：統一感と文の品質

「内容をすべて書き出した」時点での原稿は、ソースのバージョン管理という観点で見ると、下記のような問題を抱えている状態です。

統一感がない
読みにくい文がある「ように感じる」

統一感がない

「内容をすべて書き出した」時点の原稿で用字用語がきれいに整っているケースはまずありません。言葉遣いや文体、文章の温度もまちまちです。なんとなく統一感がない状態です。

用字用語が揺れているだけなら機械的に対処できる面はかなりあるし、そのためのツールもいくつかあります。とはいえ、「いう」と「言う」の使い分けみたいな、書き手がふだんあまり意識せずに書いている表現ほど、自動的な統一だと不自然な結果になったり、そもそも自動化しにくいように思います。結局、けっこうなボリュームの本を編集するときは、頭から読みながら気になった時点でgrepして全体に修正をかける、といった作業をある時点で誰かがやっています。そして、この作業は、たとえば用語ごとに独立したコミットとして切り分けるのが案外と困難なのです。しかも、経験上は切り分ける意味もほとんどありません。

文章の統一感を上げる作業を、独立した細かいコミットとして切り分けにくい（切り分ける意味があまりない）理由としていちばん大きいのは、単一の行に複数の用語揺れが混在するケースが珍しくないからです。「行う」と「行なう」の揺れを正す作業と、「無い」を「ない」に開く作業を別々の人がやれば、「行なわ無い」という非標準的な表記を「行わない」に直すだけであっさり衝突します。

それでもコミットを細かく分割すべきという考え方もあると思いますが、個人的な意見としては、これはソフトウェア開発で「関数の仕様を変更したので関数名と引数リストを同時に修正しなければならないが、コミットとしては関数名に対する修正と引数リストに対する修正とで区分する」みたいな話に近いと思っています。つまり実質的には分割の意味がほとんどない。

もう一つの理由は、他の修正作業との関係です。ソフトウェア開発でも、バグ修正とコーディング規約に合わせる作業を同時にやれば、同一の行に対して何度も修正、加筆、削除、入れ替えが発生し、そのため競合が発生しやすくなるでしょう。文章でも、統一感を上げる作業を文章・段落・節全体などの見直し作業と同時にやれば、解消に手間がかかる競合が多発します。そのため、たとえば「用字用語の統一」のためのブランチを切って作業し、後でPull Requestとして一発でマージ、といった理想的に見えるワークフローは、他の作業をまじめにやっているケースほど非現実的だと考えています。この作業は、ブルトーザーで荒地を耕すようなものだと割り切って、見つけた誰かがmasterに対して随時pushしていくほうが経験上はうまくいきます。

読みにくい文がある「ように感じる」

プログラムなら、コンパイルして型エラーが出たりテストに通らなかったりすれば問題の位置がかなり絞り込めます。文章でも、文法上のミスや文章の品質については、指摘して問題箇所を特定してくれるツールがいくつかあります（textlintとかRedPenとかJustRight!とかMS Wordの校正ツールとか）。とはいえ、人間が読むために書いているものをチェックしようとしている以上、結局は誰かが読んで初めて見えてくる問題がかなりあるわけです。文意に曖昧さがないかとか、語調が不自然でないかとか、そういう問題は実際に読んでみなければ見えてきません。

こういった問題を修正しようとして、「この文を読みやすくした」とか「文意をはっきりさせた」といった名目で局所的なコミットをたくさん作ってしまうと、あとで面倒なことになります。というのも、文章を読むことで初めて見つかるような問題というのは、実際には文章レベルより上位の段落や節が抱える問題の一部であることが多いからです。このような問題に対する局所的な修正コミットや、それを意図したPull Requestは、後述する「段落や節に対する俯瞰的な修正」のための作業と競合してしまいます。

このような競合では、「段落や節に対する俯瞰的な修正」のほうが修正として適切なことが多いので、「局所的な修正」の作業は単純に水泡に帰すことになります。「じっくり読まなければ何となくいい感じ」未満の原稿では、「局所的な修正」は「段落や節に対する俯瞰的な修正」と競合するものだと考えたほうがいいでしょう。この段階の原稿に対しては、コミットを小さくすることが正義とは限らないともいえます。「段落や節に対する俯瞰的な修正」を先にやることにして、気が付いた局所的な問題はissueなどの形でコメントを残すのみにしておくのが無難かもしれません。

根本的な対策：段落や節にまたがる俯瞰的な修正

コードが適切にモジュール化されているソフトウェア開発であれば、それほど変更が衝突することなく、個々のモジュールに対する作業を別々の人が同時にできるでしょう。文章でモジュールに相当するのは段落ですが、段落は互いに密に結合しているし、抽象的なインタフェースもないので、互いの順序や文章表現について同時に配慮が必要です。そのため、段落ごとに執筆や編集を分担するという方法は、あまりいい結果になりません。とりあえずまとまった量を読んでみないと問題を切り分けられないし、切り分けている途中で問題が直せてしまったりするので、判断を下しながらある程度の範囲を集中して読み進める、という工程が必要になります。

で、そういう不備を直していると、結果としてまったく別の問題が解消されたりすることがよくあります。段落がまるまる修正されたので誤植が消滅したとか、段落を直した結果としていまいち曖昧だった文意がはっきりしたとか、リライトが必要と思われた節とほぼ同じ内容の説明が他の場所にあったので節ごと不要になったとか。しかし、誰かが該当する文章を局所的に修正していたり用字用語の統一を全体にわたってかけたりしていると、当然、その部分で競合が発生します。

俯瞰的な修正の作業は、かなり大きな範囲全体でコミットとして意味を持つので、他でコミットされたりPull Requestされた局所的な文章の修正をこのコミットの内容と調整するのはけっこう厄介です。経験上うまくいくのは、たとえば「1章の見直し」といった作業内容ベースでブランチを切り、別のブランチでの1章に対する修正は用字用語の統一くらいに留めておく（この程度なら手動でマージできる）というワークフローです。修正する内容に対するブランチを作るのではなく、修正する範囲を区切るためにブランチを作るイメージです。このブランチでは、最終的にmasterへと自動マージできるような状態を維持しながら（masterの内容をときどきmergeしながら）、修正作業を続けるようにします。

執筆・編集にとって最適（いまのところ）だと思っているGitワークフロー

以上、だらだらと背景を書いてきましたが、結論です。

「内容をすべて書き出した」状態から「じっくり読まなければ何となくいい感じ」ゾーンにもっていくまでの間は、各コミットに必要以上に意味を持たせることはあきらめましょう。完全に正史モデルを採用する必要はありませんが、この段階は開墾地をブルトーザーで整地するようなものです。「木を抜く」作業と「穴を埋める」作業は並行してできるわけではないし、あとから一方の作業だけをやり直したいことも通常はありません（将来もし穴が必要になるとしたら、それは別の作業として考えるべきでしょう）。それなりの規模の区画ごとに、全体の出来を眺めつつ、もくもくと均していくのが現実的なはずです。

一方、「じっくり読まなければ何となくいい感じ」ゾーンまで到達した原稿は、問題とその対処がコミットとして明確に切り分けられるので、修正の意図をはっきりさせた最低限のコミットを作り、それをmasterにマージするようにしましょう。

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

「じっくり読まなければ何となくいい感じ」まで達している原稿は、これから入れる修正の意図を明らかにしたいので、issueで議論してからコミットしたり、ブランチを切ってPull Requestにしたりする
それ以前の段階では、用字用語統一、誤記修正、タグ追加などの作業はブルドーザーによる整形作業だと割り切り、細かく管理するのはあきらめる。経験上、どのみちrevertやrebaseが不可能な作業なので徒労に終わる。信頼できる担当者どうしで作業をしているなら、見つけた人がmasterに随時pushするのが、他の作業との競合を回避するためにも効率的
それ以前の段階における局所的な文章の修正は、「じっくり読まなければ何となくいい感じ」ゾーンまではissueやコメントに留める。それ以降はPull Requestにする
それ以前の段階における節以上の範囲におよぶ内容上の修正は、作業範囲を隔離するためのブランチを切って作業する（このブランチではmasterにおける用字用語統一などの修正を適宜取り込みながら作業をする。Pull Requestにしてからマージしてもよいし、手動でマージしてもよい）

このほか、本文では言及しませんでしたが、下記のようなポリシーも経験上は有効であると考えています。

脚注追加のように独立性が高いコミットとして修正を加えられる場合には、どの段階でもPull Requestにしてよい
メタ情報を、永遠にマージしないブランチで管理することもできる。索引タグなどは本文にマージする必要がないかもしれない

余談：「じっくり読まなければ何となくいい感じ」に到達したことを知るには

というわけで、文章のバージョン管理では「じっくり読まなければ何となくいい感じ」に至る前後のフェーズでコミットに対する考え方を変えよう、というのが現時点での自分の結論なのですが、そもそも原稿の状態がこのティッピングポイントを越えたことはどうやって知ればいいのでしょうか？

残念ながら分かりやすい指標はまだ手にしていません。しかし、循環論法めいていますが、ほぼすべてのコミットの意図を明確にできるようになった原稿は「じっくり読まなければ何となくいい感じ」になっているといえそうです。その瞬間に気づくためには、いま施している修正が他の修正に依存していないかどうかを常に意識しながらコミットを刻む必要があるのかもしれません。

バイナリ化したデータ構造を外部のファイルに保存して、コンパイル時にHaskellソースに埋め込む

2016-02-29T09:00:00.000+09:00

Haskellには連想配列のように使えるMapというデータ構造（Data.Map）があります。実行中にキーと値を更新するつもりがなく、コンパイル時に生成される固定的なMapを実行時に毎回使うという場合には、リテラルのリストをソースコードに書いてMapに変換して使うのですが、リストのサイズが1万要素とかになるとソース全体が肥大化してコンパイルに無駄な時間がかかるようになります。生のリストをコンパイルのたびになめる必要はないのだから、Mapに変換したデータを辞書のように外部に持っておいて、それをソースから読み込んで使う方法があるに違いありません。（ようするに、RubyでいうMarshal、PythonでいうPickleがしたい、ということです。）

他のファイルの内容をHaskellソースに埋め込むには、一般にTemplate Haskellが必要です。ありがたいことに、外部のファイルの内容をソースコードに埋め込む機能に特化したfile-embedという便利なパッケージが用意されているので、これをTemplate Haskellと一緒に利用してこの問題を解決してみました。

バイナリの辞書を作る

まず、外部に保持するバイナリ辞書を下記の手順で用意します。

リストからMapを作る
そのMapをバイナリ化する
さらにGzipで圧縮
結果を別ファイルに書き出す

コードにするとこんな感じ。このコードはバイナリの辞書（Map）を生成するだけなので、コンパイルと実行はきっかり一回だけです。

▼ mkdict.hs

{-# LANGUAGE OverloadedStrings #-}

import qualified Data.ByteString.Lazy as BSL
import qualified Data.ByteString.Lazy.UTF8 as BSLU
import qualified Data.Map as Map
import Codec.Compression.GZip (compress)
import Data.Binary (encode)

dictList :: [(Int, BSLU.ByteString)]
dictList =
  zip [1..] $
      (map BSLU.fromString ["西住", "武部", "秋山", "五十鈴", "冷泉", ...その他大勢 ]

main = do
  BSL.putStr $ compress . encode . Map.fromList $ dictList
  return ()

ここでのポイントは、Mapのもとになる連想リストに日本語などの多バイト文字列がある場合、Data.TextではなくData.ByteString.Lazy.UTF8を使うことです。なぜData.Textが使えないかというと、バイナリ化に使うData.BinaryがData.Textに対応していないためです。また、Data.ByteString.Lazy.Char8ではバイト列がぶった切られて日本語の文字が壊れてしまうので、結果的にData.ByteString.Lazy.UTF8を使うしかありません。（ほかによい方法があったら教えてください）

バイナリ辞書をソースに埋め込んで使う

上記で生成したバイナリ辞書をdict.datのような名前でどこかに保存したら、下記のようにしてHaskellソースに埋め込んで使います。

embedFile関数にファイルを指定すると、Template HaskellのQモナドにくるまれたデータが返ってくるので、これを$(...)で取り出す（というかソースファイル中に接ぎ木する）
接ぎ木されるデータは正格なByteStringなので、fromChunksで遅延ByteStringに変換する（fromChunksはByteStringのリストをとるので、リストの文脈に入れるためにreturnしている）
圧縮された状態を解凍
バイナリをほどく

▼ getmessage.hs

{-# LANGUAGE TemplateHaskell #-}

import qualified Data.ByteString.Lazy as BSL
import qualified Data.ByteString.Lazy.UTF8 as BSLU
import qualified Data.Map as Map
import Data.FileEmbed (embedFile)
import Codec.Compression.GZip (decompress)
import Data.Binary (decode)

dictMap :: Map.Map Int BSLU.ByteString
dictMap = decode . decompress $ BSL.fromChunks . return $ $(embedFile "data.dat")

getMember id = putStrLn $ case Map.lookup id dictMap of
  Just x -> BSL.toString x
  Nothing -> error $ "No entry for " ++ id

実行結果

$ ghc mkdict.hs -o mkdict
[1 of 1] Compiling Main             ( mkdict.hs, mkdict.o )
Linking mkdict ...
$ ./mkdict > data.dat
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Prelude>  :l getmember.hs
[1 of 1] Compiling Main             ( getmember.hs, interpreted )
Ok, modules loaded: Main.
*Main> getMember 3
秋山
*Main> getMember 5
冷泉
*Main>

参考資料

Compiling in constants（Haskell Wiki）
: Gzipしたバイナリデータのリテラル表現をソースに埋め込んでいる事例（そんな人間が見ても意味がないデータをソースに貼り付けるのはいやだ）。バイナリ辞書をCに変換して利用する例も紹介されているけど。
Haskellでバイナリデータ（yuga/gist:8255552）: Data.Textに対応したバイナリライブラリがなさそうなんだなということが分かりました。
How to compile a resource into a binary in Haskell?（Stack Overflow）: file-embedパッケージの存在を知りました。

ターミナルモードのEmacsでHaskellを書いているときに補完候補をポップアップしてくれるcompany-ghc

2016-02-21T20:14:00.000+09:00

Haskellのコードを書くときは、Windows 10からTeratermでDebianサーバにSSH接続し、そこでEmacsを-nwで起動して使っています。標準のhaskell-modeでとくに不満はないのですが、いちおうghc-modも入れていて、単純なエラーの確認にはとても重宝しています。でも、ghc-modの補完機能はほとんど使っていませんでした。補完のためのコマンドが手になじまず、調べている間に手打ちしてしてしまうので、ちっとも身に付かなかったからです。

とはいっても、ある程度の量を書いていると、やはり手で打っているのではしんどくなってきます。何とかならないかなーと思っていたところ、company-ghcというものを発見しました。

Company GHC
https://github.com/iquiw/company-ghc

ターミナルで開いているEmacsでも、統合開発環境のような補完メニューを実現するcompany-modeというツールがあって、そのHaskell版をghc-modを介して実現するためのパッケージらしい。試しにインストールしてみたところ、こんなふうに、まるで統合開発環境のようになりました。これならぼくにも使えそう。

インストールと設定の概略

すでにghc-modを入れているなら、そのインストール時にEmacsのパッケージをMELPAから取得できる状態にしていると思います。その場合は、M-x package-installでcompany-ghcを指定するだけで、必要なパッケージを含めてインストールしてくれます（したがって事前にcompany-modeを個別にインストールする必要もありません）。MELPAからパッケージを取得する設定にしていない場合は、init.elかどこかに以下を設定します。

(require 'package)
(add-to-list 'package-archives
  '("melpa-stable" . "http://stable.melpa.org/packages/") t)
(package-initialize)

無事にインストールできたら、まずはcompany-modeを有効にします。haskell-mode利用時のみ有効にすることも可能ですが、せっかくなのでグローバルに有効にしておきます。そのほうがCtrl-c Ctrl-lでGHCiを起動したときにも補完が効くようになるし、いろいろ便利なはず。

(require 'company)
(global-company-mode)

あとは下記のようにcompany-ghcを設定すれば完了です。

(add-to-list 'company-backends 'company-ghc)
(custom-set-variables '(company-ghc-show-info t))

これだけでもとりあえず動くはずですが、company-modeのパラメータを少しいじったほうが使いやすそう。

(setq company-idle-delay 0.5)          ; 補完候補を表示するまでの待ち時間
(setq company-minimum-prefix-length 2) ; 補完候補の表示を開始する入力文字数
(setq company-selection-wrap-around t) ; 補完候補のスクロールが末尾に到達したら先頭に戻る

さらに、補完候補がポップアップ表示される際の背景色などを好みで設定します。下記の設定に加えて、Teratermの［ウィンドウの設定］で「256色モード（xterm形式）」にチェックが入っていて、かつサーバ側の環境変数TERMがxterm-256colorに設定されていないと、とても日常の使用には耐えない悲惨なユーザインタフェースになってしまいます。

(set-face-attribute 'company-tooltip nil                  ; ポップアップ全体
  :foreground "black" :background "ivory1")
(set-face-attribute 'company-tooltip-common nil           ; 入力中の文字列と一致する部分
  :foreground "black" :background "ivory1")
(set-face-attribute 'company-tooltip-selection nil        ; 選択項目の全体
  :foreground "ivory1" :background "DodgerBlue4")
(set-face-attribute 'company-tooltip-common-selection nil ; 選択項目のうち入力中の文字列と一致する部分
  :foreground "ivory1" :background "DodgerBlue4")
(set-face-attribute 'company-preview-common nil           ; 候補が1つしかなくて自動で入力される場合
  :background "black" :foreground "yellow" :underline t)
(set-face-attribute 'company-scrollbar-fg nil             ; ポップアップのスクロールバー
  :background "Midnight Blue")
(set-face-attribute 'company-scrollbar-bg nil             ; ポップアップのスクロールバー
  :background "ivory1")

これで、最初の例のように、いい感じに補完候補が表示されるようになりました。

ちなみに、上記の色の設定例で「候補が1つしかなくて自動で入力される場合」とあるのは、下記のように候補が決定的になった状況のことです。

項目を選択した状態で［F1］を押すと、その項目のヘルプも見られます。

関係ないけど、TeXも捗る。

LaTeXで連番リストに丸数字（\ajMaru）を使えたはずだけどhyperrefで困る話

2016-02-09T19:28:00.000+09:00

LaTeXで丸数字の連番リスト環境の基本

そもそもLaTeXで丸数字を使いたいときは、otfパッケージのajmacros.styの機能を使うのが一番お手軽です。このスタイルでは、数値を指定してさまざまな囲み数字のグリフ（あれば）を呼び出すという便利な機能が提供されています。たとえば、ふつうの丸数字であれば、\ajMaru{数値}として出力できます。



\ajMaru{1}、\ajMaru{100}、\ajMaru{101}





一方、enumerate環境でラベルのスタイルを変えたいときは、\theenumiとか\theenumiiといったコマンドを再定義します。
\theenumiと\theenumiiは、それぞれ「enumi」や「enumii」という名前のカウンタに対応した「アラビア数字」に展開されるコマンドです。
その結果がenumerate環境でラベルを表示するのに使われているので、これらのコマンドの挙動を変えることで別の種類の数字を出力できるというわけです。
たとえばこんなふうにすれば、ラベルが大文字のローマ数字であるような連番環境が作れます。


\renewcommand{\theenumi}{\Roman{enumi}}
\begin{enumerate}
  \item 最初\label{A}
  \item 次\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。





以上の知見を組み合わせれば、こんなふうにして丸数字の連番環境が作れそうです。


\renewcommand{\theenumi}{\ajMaru{enumi}}



しかしこれはうまくいきません。\ajMaruの引数は数値でなければならず、enumiはあくまでもカウンタの名前だからです。



ではどうすればいいかというと、ajmacros.styに用意されている\ajLabelというコマンドを使います。
このコマンドは、後続の\ajMaru{enumi}の中身を実際のカウンタ値として取り出してくれるように定義されています。


\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\begin{enumerate}
  \item 最初\label{A}
  \item 次\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。





hyperrefと一緒に使えなくなっているっぽい（2016年2月現在）


本当ならこれで話は終わりのはずなんですが、相互参照をクリッカブルにしてくれるhyperrefパッケージを同時に使うと話がややこしくなります。
hyperrefは、相互参照をクリッカブルにするためにカウンタ関連の機能をいろいろ勝手にオーバーライドするという鬼仕様なのですが、
ajmacros.styではそれに振り回されないように、
hyperrefを読み込んだ場合には\begin{document}の時点で\ajLabelなどをhyperref用にカスタマイズし直してくれます。



しかし、さらに厄介なことに、hyperrefはときどき内部の振る舞いをドラスティックに変更します。
そのため、せっかく再定義されている\ajLabelがまた使えなくなるという事態が2016年2月現在では発生しているようです。
具体的には、以下のような例で、上記のような事情を理解していないとちょっと追跡しにくいエラーが起きます。


\documentclass[dvipdfmx]{jsarticle}
\usepackage{otf}
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\usepackage{hyperref} % hyperrefを使う
\begin{document}
\begin{enumerate}
  \item 最初\label{A}
  \item 次\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。
\end{document}



実行例


...
! Undefined control sequence.
\ajLabel ...abel \@arabic \else \Hy@ReturnAfterFi
                                                  \hyperref@ajLabel #1\fi {
l.17  \item 最
              初\label{A}
?



エラーが起きている\Hy@ReturnAfterFiは、かつてはhyperref.sty内で定義されて使われていたようですが、現在のhyperrefでは使われていないため、このような事態になってしまうようです。hyperrefパッケージのSVNのログを見ると、どうやら2011年4月に消えたようですね。



  [hyperref-svn] oberdiek: r1291 - trunk

  
  http://mail.gnu.org.ua/mailman/listarchive/hyperref-svn/2011-04/msg00002.html
  



上記のログを見る限り、oberdiekバンドルのltxcmdsパッケージで定義されている\ltx@ReturnAfterFiを使うようにしたので、\Hy@ReturnAfterFiをディスコンにしたようです。
\ajLabelの再定義では、この\Hy@ReturnAfterFiを利用しているので、上記の例がうまく処理できない結果になっているようです。



そこで、\Hy@ReturnAfterFiを\ltx@ReturnAfterFiに変更するだけの以下のパッチをajmacros.sty（1.7b6）に当てて試したところ、意図した挙動に戻りました。
（\Hy@ReturnAfterFiと\ltx@ReturnAfterFiの定義は同一なので当然といえば当然なのですが。。）


--- ajmacros.sty.org    2016-02-09 16:16:17.700785982 +0900
+++ ajmacros.sty        2016-02-09 16:15:57.548561902 +0900

@@ -685,7 +685,7 @@
 %      \def\check@UTF##1##2##3{\ifx\UTF##1\0x##2\else##3\fi}}{}}
 \gdef\ajRedefine@ajCommands{\@ifpackageloaded{hyperref}{%
        \let\hyperref@ajLabel\ajLabel
-       \def\ajLabel##1##{\ifHy@pdfstring\Hy@ReturnAfterElseFi\hyperref@ajLabel\@arabic\else\Hy@ReturnAfterFi\hyperref@ajLabel##1\fi}%
+       \def\ajLabel##1##{\ifHy@pdfstring\Hy@ReturnAfterElseFi\hyperref@ajLabel\@arabic\else\ltx@ReturnAfterFi\hyperref@ajLabel##1\fi}%
        \ajRedefine@ajCommand\"${Lig"$}\"&{Lig"&}\!*{Lig>.}\ajLig{Lig}\ajPICT{PICT}\"({PICT}\ajVar{Var}\@nil\@nil
        \aj@Redefine@ajCommand!{{Maru}!|{KuroMaru}""{Kaku}"#{KuroKaku}!~{MaruKaku}"!{KuroMaruKaku}\@nil\@nil
        \def\!J##1!K{\ifHy@pdfstring(##1)\else\expandafter\ifx\csname ajLig(##1)\endcsname\relax\@ajnumber{##1}{Kakko}%





hyperrefは、電子書籍をLaTeXで制作するうえでは唯一無二のパッケージなのですが、ときどきこういう面倒が起きるのがつらい。。


まとめ


またhyperrefか。



技術書編集者として「これはやられた！」2015年の本
2016-01-27T11:41:00.001+09:00

技術書の年間ランキング的なものについて、編集者たちに「これはやられた！」と思う他社の本を候補として出させたら面白いのでは、という会話を小耳にはさみました。これはまたとないアマゾンアソシエイトの機会！ということで、勝手に自分の候補を上げてみます。



と思ったものの、新刊の技術書をそんなにたくさん読んでいないうえに、去年「これはやられた！」と思った本はいずれも技術書ではなく、どちらかというと数学書っぽい本ばかりでした。それでも、ジュンク堂池袋本店の「新春座談会 このコンピュータ書がすごい！ 2015年版」で取り上げられた本ばかりだし、たぶん技術者が読む（べき）本としても妥当なはずです。

『コンピュータは数学者になれるのか? -数学基礎論から証明とプログラムの理論へ-』




いま自分の本棚を見返したら、この本の隣にたまたま『日本の著作権はなぜこんなに厳しいのか』が並んでいて、一瞬だけ姉妹書に見えました。疑問形タイトル、文芸系とかビジネス系の出版社だと割と普通に見かけるけど、自分で本を企画するときには扱い方がわからず避けてしまうので、そういう書名を使いこなせる編集者になりたいです。というか、たぶん疑問形タイトルって、「これは既成の考え方をなぞった本ではなく、なおかつ人類は読むべきである」ことについて相当な自信がないと付けられない書名な気がします。



この本の場合、コンピュータと数学者のことを「算術計算に秀でたモノ」と考えている人にとっては、確かに「既成の考え方をなぞった本」ではないのでしょう。しかし、コンピュータとは自分が考えたプログラムが本当に動くことを確かめるためのものであるという人や、数学者はコーヒーから証明を生成する仕事であると気づいている人にとっては、どこかで見聞きして知っていたり知らなかったりする話にぐさっと明快な筋道を通してくれる本でした。一般向けの数学の読み物で見かける話も含まれてますが、call/ccは背理法ありの古典論理で純粋関数型言語は直感主義論理に対応しているんだという第5章のクライマックスに至る話を素で楽しめるのは、実際にプログラムを書いている技術者の特権だろうと思います。



出版社は青土社です。選択公理の読み物として一部で有名な‟The Pea and the Sun: A Mathematical Paradox”（Leonard M. Wapner）の翻訳である『バナッハ=タルスキの逆説 豆と太陽は同じ大きさ?』をはじめ（原書しか読んでないので翻訳の出来は知らない）、意外に「え？」っていう理学系の本も出してくるし、割と好きです。「現代思想」とか「ユリイカ」でも思想的な文脈で現代数学の記事をたまに掲載しているし、そのうち計算機科学や機械学習の特集もあるに違ない。


『圏論の歩き方』




Haskellを使うのに圏論はいらないって言うけど、みんな圏論圏論って言ってるので、どうしたって圏論が気になりますよね。そんな人間を狙いうちする本が日本評論社から発売されました。タイトルどおり、圏論の名所をめぐるツアーガイドのような本です。いつか自分の足で行ってみたいけど余裕がなくて行けない場所へ行った気になれる本です。去年の夏に読んで、いまこうやって記事を書くつもりで内容を要約しようとしても、さっぱり具体的な言葉にできないんですが、そのへんもツアーガイドに似ています（実際、「地球の歩き方」なんかにしても、行く場所を決めるときに読んだ内容をあらためて説明しろと言われても言葉に詰まりそう）。



正直、この本のうち計算機に関する部分については、まさに自分でこんな本を作りたかったという気にさせてくれる本でした。この本が企画として面白いと思うのは、コンピュータ書でいえばフレームワークに対する「クックブック」のような本を、数学の一分野で形にしてしまった点です。数学書、コンピュータ書でいえば「コードの動作について説明しただけ」だったり「コード読めばわかるよね」だったり、そんな立ち位置の教科書が少なくない気がします。コンピュータ書の場合には、実行例を見せることで「どんな場面でどんなコードが必要なのか」を説明できたりしますが、それを数学書でやったのがこの本なのかなあと思いました。いわば「圏論の実行例」。あるいは「圏論のクックブック」。もし何らかの事情で圏論について本当に「わかる」必要があるなら、体系的に書かれた教科書を読みながら紙と鉛筆で勉強するのが近道なんですが、そうやって教科書の証明を読み進めるときの「実行例」だけが本として、しかも圏論みたいな分野で出たということで、自分のなかでは「これはやられた！」一冊でした。


『あなたの知らない超絶技巧プログラミングの世界』




自分が過去に企画にできなかった本が企画化され、しかも想像以上に出来がいいのだから、「これはやられた！」一冊として選ばざるをえない。発売当時、くやしさをばねに紹介記事を書いたので、そちらを読んでください。