青木日記

■ Ruby会議2008

週末はRuby会議2008。 スタッフの人が「まさかLTの途中に来るやつなんていねえよな〜」 と油断している隙を狙って到着してやりました。KY。

んで、わたしの発表は凝りずに 「日本Rubyのリファレンスマニュアル2008・初夏」です。 リファレンスマニュアルも 1 年でずいぶん進みました。 資料とか↓

http://i.loveruby.net/rubykaigi2008/

今年もよいRuby会議でした。 みなさま本当にお疲れさまでした。

あーRubyのコードが書きてぇ〜

(02:02)

■ 「ふつう」3点セット

Ruby会議のゴルフで「ふつう賞」なる賞があったらしい。 その賞品が「ふつう」3点セット。 内訳は、 『ふつうのLinuxプログラミング』 『ふつうのHaskellプログラミング』 『ふつうのコンパイラ』(出版されしだい送付)

ちょ……待っ

(02:45)

■ 書籍執筆支援システムReVIEW

ReVIEW の反応が意外とあったので tar.gz にかためてみた。

• http://i.loveruby.net/archive/review/review-20080624.tar.gz

自分が使うことしか考えてなかったのでドキュメントはない。 ReVIEW フォーマットの説明だけは以前必要にかられたので書いてある。 doc/format.txt を参照。

使いかたをチョー簡単に書く。

◆インストール

Ruby 1.8 があればオケ。 ちょっと古い 1.9 (M17N 導入のしばらくあと) でも動いてた。今は知らん。 setup.rb でインストールしてもよいけど、 tar.gz を展開してそのまま bin にパスを通せば使えるのでそっちがおすすめ。

◆使いかた / 最初にすること

まずディレクトリを作って章ごとにテキストファイルを作る。 拡張子は「.re」。 でもって CHAPS というファイルを作り、その中には章の順にファイル名を書く。 例えば 1 章が intro.re で 2 章が lexer.re、3 章が parser.re なら、 CHAPS ファイルは次のようにする。

intro.re
lexer.re
parser.re

また、章を「部」に分けるときは空行を入れる。 例えば以下は「ふつりな」の CHAPS。

intro.re
　
abstract1.re
abstract2.re
abstract3.re
　
stream_sys.re
stream_stdio.re
practice1.re
practice2.re
　
hier.re
fs.re
　
memory.re
process.re
signal.re
etc.re
　
network.re
httpd.re
httpd2.re
　
advanced.re

また preface.re, postscript.re, appendix.re というファイルを作ると、 それぞれ前書き・後書き・付録と自動認識されて、なんとなくそれっぽく処理される (CHAPS に入れてはいけない)。

あと、原稿は EUC-JP でしか書いたことがない。 Shift JIS だったりすると何か起こるかも。

◆使いかた / 目次出力

review-vol コマンドは章目次と章ごとの分量を表示する。 引数なしで review-vol と打てばよい。その他の使いかたは --help 参照。 「review-vol」は名前が長いので、ローカルでは「list」に alias している。

review-index コマンドは詳細な目次と、章・節・項ごとの推測行数を表示する。 デフォルトの組版メトリックは A5 (ふつうシリーズの大きさ)。 ちなみに A5 だと 1 ページ ≒ 1KB で近似できる。 B5 変形なら 1 ページ ≒ 2KB。 当然ながら、節の分量はあんまりバラつかないほうがよい。 本の分量と内容にもよるが、 ふつうシリーズでは 1 節を 200 行前後にまとめることを目標にしている。 コマンドの詳細は --help オプションを参照のこと。 あと、「review-index」も名前が長いので 「ind」を alias にしている。

◆使いかた / フォーマット変換

review-compile コマンドはフォーマットを変換する。 review-compile --html で HTML を生成、 review-compile --latex で LaTeX を生成、 という感じ。 ln -s review-compile review2html してもよい。 あとは review-compile --help を見よ

◆使いかた / プリプロセッサ

review-preproc コマンドはプリプロセスをかける。 プリプロセスの主な目的はソースコード引用を更新すること。

他人に話すときはフォーマット変換のほうが目立つので そっちを話すが、ReVIEW を最初に作った動機はソースコード引用を自動化することであった。 プログラミング関連書籍における執筆支援システムの役割は、 ソースコード引用に始まりソースコード引用に終わると言うとやや過言である。

◆使いかた / その他

あと、「記述・参照関係のチェック」 (もうこの専門用語は説明したかどうか、みたいなことをチェックする機能) とか「NG ワードのチェック」とかあるんだけど、 説明が面倒なのと、もしかすると今動かないかもしれないので説明しない。 まあ NG ワードなんて grep すりゃ済むから、専用コマンドなんていらんか。

◆ライセンスとか

LGPL。例によって無保証。 あと、いまバグレポートとか機能追加要望とかもらっても絶対に反応できません。 ふつぱいらが書き終わったら反応するかも。

(03:04)

■ iPhone

そういえば iPhone は買うね。これは買うよ。 たとえ月額 8000 円近くても買うよ。 永らく au だったけどついに SBM に乗り換えか……。

(03:40)