トップ 最新 追記

KeN's GNU/Linux Diary


2011年08月01日

_ [cooking] ゴーヤチャンプルー、かぶの漬物

好きやねぇ、と言われそうなくらい頻度が高いのだけど、夏バテして食欲がいまいちで、野菜を取る必要があって、味の良い物、というとぴったりなんだよね。


2011年08月02日

_ [cooking] かつおの土佐造り

とりあえず出来合いのもので。


2011年08月04日

_ [cooking] オムライス

ご飯が微妙な量だけ残っていたので、鶏肉、玉葱、ピーマン、ケチャップでチキンライスを作り、卵で包んでオムライスに。 またしてもハインツケチャップの開栓時にひっかけて出血したよ……。プラスチック蓋は相性悪すぎなので、今度買うときは瓶にしよう。


2011年08月05日

_ [cooking] 牛丼、豆腐とワカメの味噌汁

手抜きぎみに牛丼。後からキムチ添え。なぜスーパーのキムチは賞味期限を過ぎてからようやくおいしくなるのか?


2011年08月07日

_ [cooking] スパゲッティボロネーゼ、ブロッコリーの蒸し物

挽肉としめじに少しチーズを入れてラザーニャ風味に。ブロッコリーはルクルーゼ鍋で塩と少々の水を入れて茹でるだけ。


2011年08月08日

_ [cooking] さばの西京焼き、小松菜のゴマ油炒め、梅干し

さばの西京焼きというのは初めて食べたんだけど、予想外においしかった。油っこさが味噌でうまく抜けて風味が増してる。梅干しとの相性も良し。 小松菜はニンニクと一緒にゴマ油で炒めただけだけど、これもいい。


2011年08月09日

_ [cooking] ゴーヤの挽肉詰めスープ、きゅうりのぬか漬け

いつものように鳥挽肉と木耳とショウガ、ネギで。収穫したミニトマトも入れてみた。酸味が加わってなかなかおいしい。


2011年08月10日

_ [cooking] ビーフストロガノフ

かなり放っておいた牛カタマリ肉を使って。ちょっと固くなりすぎてた……圧力鍋にかけてシチューにしちゃったほうがよかったか。


2011年08月13日

_ [news] 出戻り

これまで使っていたblosxomは、生HTMLで何でもできるというのはあるのですが、ファイル名とタイムスタンプベースで管理するというのは更新時期や順序などを考えるのがとても面倒で更新が億劫になる原因の1つでした(忙しかったり、ソーシャル系ツールで手軽なことなら済んでしまっていたというのもあります)。

WordPressなども検討していたのですが、PHPでどうにもオーバースペックな上に見通しが悪く、blosxomの前に使っていたtDiaryに戻ってきてみました。blogを書くことが目的だったはずなのですが、書くためにツールを改造したりドキュメントのバグを見つけたりしているような気がします……。まぁちゃんと中身がわかったらcontributeしていきたいですね。

写真をいっぱい貼り込むような記事を書くにはあまり向かなそうですが、連携ツールなどを考えながらいじっていってみます。

昔の記事は、http://kmuto.jp/d/ でまだ開くことが可能です。旧RSSについては徐々にリダイレクトする予定です(全部単位のものはリダイレクト済み。カテゴリ単位のRSSをtDiaryで実装するよう手直し中です)。

_ [cooking] 豚肉の生姜焼き、トマト、きゅうりのぬか漬け

パートナーが実家から夕食なしで帰宅することになったので、1人メシよりはまともなものを作る。 トマトはご実家からのいただき物。やわらかく味が濃くておいしい。今年はやや酸味多め?


2011年08月14日

_ [cooking] タイカレー

激辛に弱くなってしまったので少し甘めに。


2011年08月15日

_ [computer] 「TeXユーザの集い2011」のお知らせ

今年の「TeXユーザの集い」( http://oku.edu.mie-u.ac.jp/texconf11/ ) の詳細が発表されました。

軽い気持ちで引き受けた午前中の「ディストリビューションラウンドテーブル」がえらく目立ってしまっていて途方に暮れているのですが、upstreamや他ディストリビュータとの間で交流や生産的協議ができればと思っています(「おい、なんでオレに声かけてないんだ!」という方は私までご連絡ください……)。うぅ、今から緊張してきてますヨ。

会場周辺には食事どころがない(あっても休み)ので、テーブルに参加・見学される方は、集いページの各種申込にあるとおり、お弁当を申し込まれることをお勧めします。懇親会もいろいろな方と交流する良い機会ですので、ぜひどうぞ。ちなみに昨年の懇親会の食事はけっこう豪華でした。

電子書籍や組版フォーマッタで高名なアンテナハウスの村上真雄さんの招待講演、奥村先生や各開発者の発表も楽しみです(ライトニングトークの銅鑼娘は誰かいらっしゃらないかな)。

_ [tdiary] 料理写真をプレビューしてXML-RPCで記事投稿する

post-xmlrpc 料理日誌は人に見せるためというよりも自分の覚え書き(最近何を作ったかや、覚えておきたいレシピのメモ)なんだけど、カメラからCFを取り出す→Digikamでアップロードしたいものをインポートする→ファイル名のリネームとサムネールをファイル名が被らないように気をつけながら作る→ファイルをアップロードする→記事を書く という工程がかなり億劫なのが悩みの種だった。

blosxomの特徴である記事ファイルの日付が投稿日付になる、というのも過去日誌をまとめて書くには悪影響で、これらが数ヶ月更新の滞っていた原因。

tDiaryで過去日誌を書くことはもう少し簡単にできるようになったので、あとは工程の面倒さをなんとかする必要がある。CFを取り出すのはしょうがないとして、残りの工程を省力化したい。

ということで、Ruby+Gtkアプリケーションの勉強も兼ねて、post-xmlrpc ( https://github.com/kmuto/post-xmlrpc )というオレオレツールを作ってみた(本当はPython+GtkでPythonの勉強もしたかったのだけど、これをやっているといつまでも肝心の記事に入れないという罠)。

tDiaryでは、ちょっとしたセットアップでXML-RPCで記事投稿ができるようになっている(tdiary-coreのmisc/plugin/xmlrpc/README)。 素のxmlrpc.rbだとnewPostメッセージ時にはその時間の投稿日付しかできないので(まぁ当然だ)、過去日誌に行けるようpublishパラメータを流用するようにちょっとだけ改造。

あとは、gthumbなどの画像プレビューアでCFメディアを開き、これをアップロードしようと決めたらpost-xmlrpcを呼び出し(gthumbだとtoolsに登録しておくのが簡単)。プレビューが開くので、タイトルと内容を記入して「書き込み」を選べば、ローカルフォルダへの写真の移動とリネーム、サムネールの生成、写真と記事のアップロードと自動で進む。インポート〜記事を書く が1手順になったので、かなり楽になった。

習作なのでいろいろダサいところはあるし、中身も自分専用になっているけれども、似たような悩みを抱えている方には便利かも。

_ [cooking] ベトナム風春雨スープ

鳥挽肉とピーマン、ニョクマムで作ったスープに、トマト、春雨で。昨晩のカレーも食べた。


2011年08月16日

_ [review] アジャイルサムライ -達人開発者への道

アジャイルサムライ−達人開発者への道−
Jonathan Rasmusson/西村 直人/角谷 信太郎/近藤 修平/角掛 拓未
オーム社
¥ 2,808

個人的にレビューアで活動しようとしていたものの、別書の作業で忙しくなって図版の調整でのご協力しかできず忸怩たる思いをしていた1冊。

「アジャイルサムライ」というそそるタイトルに、監訳者・訳者は先端的開発手法を追求する永和システムの精鋭揃いとあっては期待せずにはおれないだろう。

そしてその期待どおり、本書はアジャイルソフトウェア開発の良い入門書であり、既存の制作手法を改善するヒント集であり、人生を豊かにするとても面白い読み物だ。

アジャイルソフトウェア開発の原則の1つひとつをわかりやすく説明したものではあるが、ほかのソフトウェア開発手法の現場にもそれらのいくつかは取り込むことができるだろうし、まったく別の業務ドメインや人の生き方そのものにさえも適用できるだろう。Twitterの#agilesamuraiハッシュタグや、各地で開催されている読書会の盛り上がりにも、それが表れている。

細かな内容についてあまり書いてしまうと、楽しみを削ってしまうことになるだろうから、ここまで。後は実際に読んで、実践するだけだ! PDF版もオーム社サイトで販売されている。

_ [debian] Debian 18周年

1993年8月16日にIan Murdockによって設立されたDebian Projectが、今日で18周年を迎えました、というアナウンスが出ています。Ianの小さな宣言から始まったDebian Projectは、今や35,000以上のパッケージ、1,000人以上の公式開発者と公式メンテナ、Aliothにいる11,0000人にも達するコントリビュータ、そして多数のユーザを得て、フリーソフトウェアにおける成功したプロジェクトとなりました。皆からの祝福を贈る http://thank-you.debian.net/ フォームが用意されているので、日本からもドシドシ送っていただければと思います。

自分は1997年あたりからDebianを使い始めた(rex-jp?)ので、14年目ということになるわけですねぇ…。 最近は開発はかなり放置ぎみで、裏方の活動も前田さんたちに引き継ぎを進めているので、DebianやDebian JPへのコミットメントは翻訳やinstaller調整といったことを細々としている程度です。

来年のWheezyフリーズやリリースに合わせて何か良いニュースを出せるよう目論んではいますが、予定はまだ未定ということで。そもそもWheezyがそううまくフリーズできると思ったら大間違いだ!(マタカヨ)

_ [cooking] 冷やしゃぶ

タイムセールでわりと良い牛しゃぶ肉を安く入手。えのきと一緒に茹でて、キュウリ、ミニトマト、豆腐、ミョウガとの取り合わせ。 良い肉をありがたがってじっくり食べた分、とてもおいしかった。


2011年08月17日

_ [cooking] ベーコンと野菜のグリル焼き、コーンスープ

パートナーご実家の野菜をいろいろ使って。 コーンスープは生とうもろこしを牛乳と一緒にミキサーにじっくりかけ、牛乳でさらに薄めてコンソメ、塩、胡椒で味つけし、生クリームを混ぜて一煮立てして濃す。濃すのがちょっと大変。 グリルは固まりベーコン、ウィンナー、シシトウ、ピーマン、トマト、ミニトマト、ナス、インゲンという取り合わせ。


2011年08月18日

_ [cooking] 素麺、鶏肉とピーマンとネギの炒め物

暑くていろいろ大変なので素麺に。薬味にはミョウガ、シシトウ、キュウリ、ミニトマト。


2011年08月19日

_ [cooking] サーモンとかつおの刺身、きゅうりのぬか漬け

刺身づくしという感じで。


2011年08月20日

_ [indesign] 【ネタバレ注意】DTPの勉強会 特別編 第2回 課題制作

DTPの勉強会特別編 第2回 の事前課題制作過程は【ネタバレ注意】を付ける以外は考え中のものを公開するのは 絶賛アリとのことなので、自分が作ってみたものを晒してみる。

その後、ちょっとアップデートをかけた。

テキストフレームの中のテキストを上下センターにする

http://kmuto.jp/indesign/scripts/trial/2nd-task1-vcenter.jsx

上下センターはプロパティ名がわかれば一発。プロパティの値にクラス定数を指定するときに、それをヘルプブラウザで調べるのが難しいことがあるのが罠(保存オプション系が「options」としか書いていないのはひどいよね……)。

対象フレームは選択したものを、ということなので、app.activeDocumentで現在開いているドキュメント、app.selection[0]で選択している物を取得。instanceofでテキストフレームであることを確認する。

1つのテキストフレームを右へ10mm移動、2つのテキストフレームの間隔を3mmにする。

http://kmuto.jp/indesign/scripts/trial/2nd-task2-locate.jsx

設問的に別々の作業なのか、これらを一度に行うということなのか、と判断に悩むところはあるが、別々なら単にスクリプトを後で分ければよいし、1つで順に処理するように作った。

選択している2つのテキストフレームをapp.selection[0]、app.selection[1]で取得。フレームオブジェクトの左上座標と右下座標は geometricBounds visibleBoundsで調べられる(この座標の差を取れば、幅・高さも導出可能)。設問の補足では、3mm間隔というのは水平間隔で、動かす際には右側のフレームを動かすとのこと。普段はgeometricBoundsばかり使っていたのだが、こちらは囲みケイが「含まれない(exclude)」ため、ケイ入りで作っていた場合には3mmのつもりがケイ幅の分だけずれることになる。visibleBoundsにすると、囲みケイを「含む(include)」ものになる。

左か右かはgeometricBounds値を見てもいいが、selectionの挙動では左側にあるほど若い番号が振られるようなので、とりあえず判定はなしで[0]が左、[1]が右と仮定することにした。 嘘。階層で上にあるものから採番されるっぽい(確かにそうなった)。なので、やはりvisibleBoundsの左X座標を比較する必要がある。

右側フレームを動かしてさらに右側フレームを動かすだと奇妙なので、左側のフレームを右方向に10mm移動、その後に左側フレームから3mm右に離して右側フレームを配置、という処理にしてみる。単位座標系は左上基準からは変更しないものとする。

いずれにしても移動処理となるが、移動にはvisibleBoundsプロパティ値を直接修正する方法と、moveメソッドを使う方法がある、はず。自分はmoveはレイヤーやページを変えたいというとき以外はあまり使っていない(何かのバグにひっかかった覚え…)ので、visibleBoundsを使うようにした。visibleBoundsは4つの値を持つ配列だが、X1, Y1, X2, Y2 ではなくて、Y1, X1, Y2, X2 という構成には注意が必要。版面外に出たときの扱いがいまいち謎だったりもする。

ドキュメント設定で単位をミリにしているなら単にこれらの配列値をいじるだけでよいが、一応念のためにここでは単位をバックアップしておいて、終わった後には戻すようにした。スクリプトは自分だけが使うものではないことがあるし、何か設定をいじるときには処理前にバックアップ・処理後にリカバリをするようにしている。

テキストフレーム内の文字「楽しく」にルビをふる、「作成方法」にルビをふる(グループルビ)

http://kmuto.jp/indesign/scripts/trial/2nd-task3-ruby.jsx

XMLインポートの場合だとXMLタグでルビを指定できてしまうので、スクリプトから操作するというのは初めての体験。この設問も別々のスクリプト作成なような気はするけれども、1つのスクリプトにまとめている(先と同様に分けることは容易)。

モノルビとグループルビはRubyTypes定数が違う以外は挙動としては変わらないので、setRubyメソッドを作って共通化した。一応すでにルビがある場合にはいじらないようにしておく。

「楽しく」の「楽」だけを正規表現で取り出すのはちょっとコツがある。それが後方肯定「(?=STRING)」。これで、文字列としては「楽しく」に一致するけれども「マッチした文字列」として返されるのが「楽」だけ、という挙動を実現できる。テキストフレームから正規表現で探すのはテキストフレームオブジェクトのfindGrep()。

これに比べると「作成方法」のほうは肯定表現を使うまでもないので、単純文字列検索のfindText()を使っている。

find系メソッドはInDesignの検索パネルそのままなので、テキストフレームなどの選択範囲、ストーリー、ドキュメントなどいろいろと対象範囲を絞って実行できるのだけど、スクリプト内ではfindメソッドを呼び出すオブジェクトによってそれが決まる、というのがちょっとわかりにくいところかもしれない。

テキストの中の値段をすべて10円アップする

http://kmuto.jp/indesign/scripts/trial/2nd-task4-plusten.jsx

これは思いを深めるとなかなか難しい。値段ということで、数値の後に「円」または「圓」が後ろについている、あるいは数値の前に「¥」(半角/全角)が付いているという前提条件として、数値はいわゆる半角数字のみ、桁区切り「,」がすでに付いているときにはそれを尊重して桁区切りを行い、付いていなければ区切らないということにした(「90円だけど区切りたいんですが」というときには「9,0円」とでもしておきましょう…)。区切り記号が不正な位置にあっても気にしないことにする。

「,を含み得る数値 + 円|圓」は後方肯定の正規表現で「,を含み得る数値」を取り出せる。 「¥ + ,を含み得る数値」は類似の前方肯定(?<=STRING)の正規表現で「,を含み得る数値」を取り出せる。そういえばWindowsだとここで半角円記号を入れるのが大変なのではという気がしてきた。コピペするか、バックスラッシュとして扱って\\とするか、かな。

後で区切りを行うかどうかのために,があるかどうかを調べてから、,を取り除く。

10円アップ自体は単に+10するだけ、ではあるのだけど、取得した「,を含み得る数値」マッチ文字列はその名のとおり文字列なので、そのまま+10だと型推測で文字列が優先されて10という文字列が後ろに付いてしまう点に注意が必要。

その後に桁区切りを行うが、後ろから1文字ずつ調べていって、最初(つまり末尾)を除く3桁が終わるごとに区切るというもの。forなどでごちゃごちゃ回しているけれども、実は正規表現1発で書けるらしい。奥が深い。

追加課題 については、お題2が元々の課題2と同じなのでキャンセル、お題3は課題3とほぼ同じ(「学ぶ」を「楽しく」と同じように入れる)かな。

お題1が新しいけれども、「ページすべての」という意味解釈と、そこから深追いするとちょっと難しい。

選択したテキストフレームの属するページを取得して、ページ直下にあるテキストフレームを探すだけであれば、PageオブジェクトのtextFramesプロパティで簡単に取れる。 ドキュメントのすべてのページの直下にあるテキストフレーム、でもPageオブジェクトをループで取る以外は基本的に同じ。

Pageオブジェクト内にある「インライン等を含むすべてのテキストフレーム」だと、再帰が必要。テキストフレームはテキストフレームまたはグループに含まれる可能性がある。その中にさらに含まれる可能性もあり……ということで、基本的にはループ+再帰で実装は可能だけど、深追いはこのあたりで。

_ [cooking] ハンバーグ、トマト、きゅうりのぬか漬け

手持ちの食材で、ハンバーグに。いただいたトマトの消費を急いだほうがよさそうだったので、ミニトマトとトマトだらけに。


2011年08月21日

_ [cooking] ひじきの煮物

和食。


2011年08月22日

_ [cooking] ロモサルタード、きゅうりのぬか漬け

久々に牛肉、トマト、ピーマン、ポテトでロモサルタードを。ぬか漬けとは合わないね…


2011年08月23日

_ [review] Rails3レシピブック 190の技

Rails3レシピブック 190の技
高橋 征義/松田 明/諸橋 恭介
ソフトバンククリエイティブ
¥ 3,218

発刊からそれなりに経過してしまったけれども、せっかく制作協力させていただいた(編集・DTP)ので、ご紹介。

すっかりWebフレームワークとしての定番としての地位を築いた感のあるRuby on Rails。巷にはすでに多数のRails書籍が刊行されている中で、本書は一体どのような差別化を図っているのだろうか。

本書はレシピ集である。順序立ててサンプルアプリケーションを作りながら学んでいくというスタイルの入門書とは異なり、ある程度の基本操作は教示はするものの、主となるのはRailsを最前線で使用あるいはRails自体の開発に参加している著者たちの知識と経験から蓄積されたTipsにある。

実際、入門書1冊だけでRailsを理解するのは難しいように思う。ステップを踏んでアプリケーションを作っていくのは書いたとおりには進んでいけるものの、そこから自分自身の新たなアプリケーションを作ろうとすると、「こういうことをする方法は本には書いていなかったのだけど、どうしよう?」と困惑することになる。

そこで本書の出番である。本書だけでRailsを理解しようとするのは困難だが、何かの入門書をこなした上で読んでみると、Railsの世界がぐっと身近に感じられ、そして新たな力の解放に驚きと喜びを覚えるのだ。

また、本書は(現時点では)唯一、最新のRails 3.1に対応している単行本である。 Railsの開発速度は速い。先端では常に開発が続けられ、新たな機能が次々と追加されている。同時に、古い時代遅れな機能が削除されたり、まったく別の書式を使うようになったりするなど、プログラマはもとより、出版社泣かせの技術と言える。 本書ではRailsのアクティブ開発者で先端を追い続けている松田さんが著者陣に加わったことで、ギリギリまでRails開発最先端に追従できるよう修正が加えられ、世界最速でのRails 3.1対応書籍となった(その後の開発でちょっと変わっちゃった項目もある、らしいけれども)。 来たるRails 3.1時代にも恐れることなく、本書が役に立つはずだ。

RubyKaigi 2011内特設ジュンク堂での先行発売の注目も高く、直接制作にかかわった本書と『7つの言語 7つの世界』、一部協力した『アジャイルサムライ』と、高々と積み上がっていたのがいずれも完売したのは、感動であった(購入された皆様、ありがとうございます!)。

著者陣も編集・DTP陣も大変な制作作業であったが、なんとか無事に7月のRubyKaigi合わせで見本販売にこぎつけ、この様子を見られて本当に良かったと思う。ジュンク堂のトークセッションも盛況。

いつものようにReVIEWで記述していたことと組版システムの改良もあって、「Rails3.1対応で原稿来ないと編集・DTPを始められませんよ…でも終わりは決まっているけど ><」とか、「レシピ数が190だったはずが189になっていますよ? どこかに1つ増やさないといけませんよ?」とか、「初校→再校→念校で大幅に変えますよ?」とかいった普通なら絶対に無茶という制作進行も、大きな事故なく遂げることができた(実質何日で制作していたことになったのかは考えたくないけど……)。

ただ、レシピのようにページ制約(白部分をなるべく埋めて必要に応じていろいろツメる)のある書籍体裁と、ReVIEW+組み直しというイテレーション制作フローとの相性については考慮の余地があるという振り返りは、今後考えていく必要がありそうだ。

_ [review] 7つの言語 7つの世界

7つの言語 7つの世界
Bruce A. Tate/まつもとゆきひろ/田和 勝
オーム社
¥ 3,456

先の『Rails3レシピブック』と併記しているのは偶然ではない…… 本書も、RubyKaigi 2011での発表に合わせて制作協力した1冊。

「キツイわー、イベント合わせで2冊同時制作はキツイわー」と地獄のミサワ化しそうだが、本書の編集作業はかなり大変だった。査読の方々にはいくら感謝してもしきれない。

7つの言語——Ruby、Io、Prolog、Scala、Erlang、Clojure、Haskell。歴史ある言語もあれば新進気鋭の言語もあり、その中で共通するのは「尖ってる」こと(Rubyは最近すっかり丸くなっている感もあるが、監訳のまつもとさんが本書を機にまた新たなアイデアを考えられるかもしれない)。これらの言語のとりわけ注目すべき性質を、著者Bruce Tate(『JavaからRubyへ』の著者だ!)が実際に使って会得し、紹介するという極めて意欲的なチャレンジの成果が、本書である。

本書は決して言語の入門書ではない。著者の試行錯誤には各言語のエキスパートが見れば奇妙で間違ったやり方に見えるものもあるだろう(特にHaskellerには)。

しかし、本書の目的は、読者が何か新たなことを学ぶという姿勢を身につけ、さまざまなプログラミングパラダイムを教養として次世代のパラダイムシフトに恐れることなく立ち向かえるような心構えを持つことにある。

無論、単なる退屈な言語説明で終わるわけがない。Tate氏は実際に言語の開発者たちにインタビューし、開発の背景や、言語の弱点、もし昔に戻れたらどう実装し直す? といったことまで立ち入って、生の声を届けてくれる。各章は映画をモチーフに構成され、味わいのあるエッセイ仕立てになっている。Rubyは「メリー・ポピンズ」、Prologは「レインマン」、Scalaは「シザーハンズ」、といった具合だ。

ユーモアあふれる文章を楽しみながら、驚くべき言語世界を知るのは、とても素敵な体験になるだろう。

……冒頭で書いたように、この制作はすごく大変だった。オーム社のアジャイル制作システムで、コミット数は900越え。

まず、7つの言語のうち自分が何とか意味を咀嚼できるのはRubyくらいで、後は「Debianにパッケージがあったのでちょっと触ってみたことがある」という程度に過ぎないのがいくつか、Ioに至っては「ナニソレ?」という感じで、コードの検証をするものの、それが正しいのかどうかよくわからない。査読者の方々にいろいろなアドバイスを頂いたり、他書を引いたりでようやく1章1章を進めていく状態だった。

そして、技巧的な英文。映画のエッセンスや、著者流のユーモア、英語文化、と諸々が混じり合い、まったく解釈できない……。そもそも翻訳の田和さんですら悩まれたところなのだから、英語赤点の自分にできるわけがないヨネー。このあたりも査読者やまつもとさんが活躍。

とにもかくにも、この素敵な本を翻訳してくださった田和さん、ブラッシュアップや技術的ツッコミを多数くださった査読者の方々、帰国早々に怒涛のチケット潰しをいただいた監訳のまつもとさん、そして、超絶編集と「え、ここからRubyKaigiに間に合っちゃうの?」という記録的な印刷所入稿を達成したオーム社の方々に、深く感謝。いい本ですよ。

Bruce Tateのもう1冊はこちら。

JavaからRubyへ ―マネージャのための実践移行ガイド
Bruce A. Tate/角谷 信太郎
オライリー・ジャパン
¥ 2,376

_ [cooking] 棒々鶏

残っていたきゅうりを一気に消費。なかなか良い味になった。


2011年08月24日

_ [life] IT書籍の索引について考える

矢吹さんのtweetから始まって、まとまりはないけど索引について思考実験。オチはないよ。

yabuki> …(snip)…あと、プログラミングの本で、巻末の索引が弱いのは辛いということもわかった。これも(重量が重い本が有利だが....

yabuki> Rubyの本でいうなら、「アクセサ」は入っていて欲しい。うろ覚えで、attr_accessor,reader,writerが索引から引けるように。あと、ちょっと古いけど、うさぎ表紙の達人Ruby本はかなりがんばっていたが、そこまでいかずとも

yabuki> メソッドの説明がポイントしてあって、あとは単なる説明と、コード例は分けてあるといい。ひどいのだとコード例にメソッドが使われているのかと思ってさがしても、文章のなかで違う文脈で書いてあってがっかりする。

yabuki> 総じて、機械的にあるから拾うじゃなくて、説明や活用している部分に索引はポイントしておいて欲しい。

これに対して(tweetもしたけれども)思ったことをまとめてみる。泣き言に見えるものもあるかもしれないけど、同情せよというわけではなくて生産的な方向に改善を目指したい。

悲しい現実

「IT書籍での索引が弱い」ということについては、自分も不満を持つ1人だ。ただ、制作協力という立場で実際に索引を作ることもよくある経験からすると、ほとんどの出版社、そして書き下ろしした著者にすら、「索引」は極めて軽い扱いを受けていると思う。

本来は内容を一番知っていて思い入れがある(はず)のは著者なのだが、原稿に索引を埋め込んだり、そうでなくても「索引を作らせてくれ」ということをされる著者というのはとても少ない。そもそも一度も見返さないで原稿でゴザーイと送りつけてくるようなのが…おっと、誰か来たようだ? ちなみに、索引をご自身で作るという著者はこれまでの経験上、「文章も良い著者」の確率が高い。自分が作ったもの、中身の完成度へのこだわりが強いという証左でもあるわけだし。

とはいえ、たいていの著者はそこまでは手が回らないし、終盤のギリギリの工程の中で索引を作るのはよほど慣れていないと難しい。

「終盤のギリギリの工程」と言ったが、ご存じのように、索引というのは索引語句とページ番号(ノンブル)との関係表であるのが普通だ。つまり、ページ番号が確定しないと、正しくそれを参照する索引を作れない。

しかし、ページ番号が確定するのは幸運が宿れば再校(2回目の紙出し)、下手をすると念校(印刷所に納品する前の最終確認紙出し)の時点だ。ほかにもいろいろな作業がある中の合間を縫って索引を作成するわけだが、再校辺りになると出版社側も具体的な刊行スケジュールをほぼ固めている。この中に「索引作成に十分な時間を費す」という項目は残念ながら入らないのが普通だ。かくして、索引を作成する時間猶予は1〜3日(3日は良いほうだ!)程度。

単語の拾い出しではなく、意味に由来した充実した索引を…という思いはあれども、ギリギリの中での索引抽出作業はシンドい。終盤工程ではほかにやらなくてはいけないことも沢山あるしね。実際のところ、意味ベースで作ったのと単語拾い出しで作ったのとでは報酬が変わるわけでもない。逆に、単語拾い出しだったらマッチかけて探せたものを、意味ベースで作ったばっかりにズレに気付かず、「はい、ペナルティ」ということだって最悪あり得る。

調整弁としての索引

そのように、思い入れが感じられないにもかかわらず索引がまだあるのは、「昔からあるから」という伝統と、8ページや16ページの倍数にしなければならないという台割にあるのではないかと思う。前者はともかくとして、後者について。

製本書籍の印刷では、大型印刷機で一度に印刷できる8ページまたは16ページといった数の倍数にページ数を制約することが基本だ。

ページ数が確定するのは終盤で、索引もひととおり拾い出したとしよう。索引対象範囲のページ(すなわち本文)を調整してしまっては索引を壊してしまうため、不可能だ。となると、倍数に収めるためのページ数調整は、必然的にそれ以外の圧縮や引き伸ばしの効くところ…つまり「目次」と「索引」となる。

目次はせいぜい1〜2ページ程度の変動が限度で無茶が効かないけれども、索引は項目の増減や、文字サイズ・行間などで調整がとてもやりやすい。結局こういうやり方だと、「意味ベースでどうこう」という索引が主になることはなく、「索引に割り当てられるのはnページ分だから、項目をこのくらい拾い出す」というページ逆算作業になる。

これが前付からの通しページ、つまり前書きとか目次とかにi、iiといった別数字ではなく、最初のページから込みで1から始めるとなると、目次でのページ数調整も封じられる(目次いじったら本文も変わって索引がうわあぁあぁ)ので、いよいよ索引が迫害対象だ。拾い過ぎても拾わな過ぎても駄目なので、通しページは苦労しがち。

なら電子書籍では?

電子書籍ならとりあえずページ制限はないけれども、そもそも採算取れるビジネスにどこまでなるの?(特にそれがうちみたいな下請けプロダクション業種だとどうなるの?)というのがまずあるわけだけど……。

電子書籍だと普通は単純一致な検索はできるだろうから、これまでのようなおざなり索引は無駄なだけとなる。とはいえ、意味ベースのを作るのは、たとえばePUBみたいなリフロー型だったらどこにアンカー置けばいいの?という疑問はある(繰り返すけど採算も問題)。

今思いついたけど、隠し索引みたいにして意味ベースの情報を埋め込めると面白いかもしれない。あとは大谷先生がtweetされていた「マイ索引機能」は、確かに電子書籍リーダーに実装してほしい。

索引の登録方法

ちなみにInDesignなどのDTPデータに索引を埋め込むことは理論上・機能上は可能ではあるのだけれども、実際にはそんなに簡単な話ではない。特に著者/編集と、DTPで分業している場合、索引の埋め込みはDTPオペレータの手作業になる。想像のとおりケアレスミスの温床で、範囲指定などの複雑な索引構成などは悪夢だ。索引周辺の修正のあおりで索引情報が消えてしまうことだってあるし、昔は索引を埋め込むと1字扱いになって行の文字詰めが壊れるというひどいこともあった(今のInDesignではこれはないはず)。

現在社内で広く使われている索引作成手法では、索引をDTPデータに埋め込むことはしていない。代わりに、索引語句とページ番号のペア、必要なら追加の読み、を並べたテキストファイルを自作のWebアプリケーションで処理して、DTPオペレータがそのまま索引テキストとして流し込めるものを生成するようにしている。WebアプリケーションはTeXで索引を作るmendexkと、漢字かな変換のkakasiを組み合わせたものだ。マーカーペンで紙に書き込んでDTPオペレータに渡して入力を待って……という無駄な作業がなくなり、効率的。ページが変わったときにも追従しやすい。PDFとの照合なども用意しているので、索引語句の間違いやズレなどを見落すことも少なくなった。

ReVIEW原稿の場合には、TeXのように最初から索引を埋め込んでそれを使うことができる。これはInDesignの索引ではなくてXMLで入れるようにしていて、後で専用の拾い出しスクリプトで抽出する。

で、索引はどうしたらいいのか

うーん、やっぱり索引は著者が作るべきなんでないかなぁと思う。「索引を作るまでが著者様の仕事です」ということで。ただ、ReVIEWやTeXのようにテキストからのイテレーションDTPではない、DTPデータがマスターデータになっちゃうような制作方法を取っている場合には、索引を作る時間が十分でないことが多い、というのが問題。

私自身はDebian徹底本を書いたときには5種類くらいの索引タグを使い分けて、DTPオペレータに無理を言って入れてもらった覚えがある。今だとReVIEWで書いて、もっとうまく処理できるんじゃないかなと妄想。

ということでやっぱりオチがありません。

追記

  • k16さん(オーム社編集部)の反応記事。著者・編集者必見。「時間がかかるという覚悟」は難しそうですねぇ……。大半のステークスホルダーにとっては予定どおり入稿できるかが最重要なので、再校出たらもう入稿でしょ?という風潮を変えるところから考えないといけない。

2011年08月25日

_ [cooking] 和カレー、キュウリのぬか漬け

冷蔵庫のいろいろなものを使って豚肉の和風カレー。 Houseのルーに付いてたブイヨンが変な味でちょっと困ったが、ガラムマサラなどを入れてなんとか復旧。


2011年08月26日

_ [review] LinuxカーネルHacks

Linuxカーネル Hacks ―パフォーマンス改善、開発効率向上、省電力化のためのテクニック
池田 宗広/大岩 尚宏/島本 裕志/竹部 晶雄/平松 雅巳/高橋 浩和
オライリージャパン
¥ 4,320

オライリー社さまから献本いただいた。ありがとうございます。

Hacksシリーズの定型に漏れず、本書はLinuxカーネルをフィーチャーして、そのチューニングやデバッグなどの数々のテクニックを集め、それぞれ数ページずつで説明する。

カーネルの入手方法に始まり、プロセス・メモリ・I/O等のリソース管理のインサイド、ファイルシステムとネットワーク、そして今隆盛を極めている感の仮想化(Linus御大はお好きでないようだが)、節電ブームとバッテリ消費が気になるこのご時世にぴったりの省電力手法、最後にデバッグ・プロファイリング・トレース、と75のテクニックをコンパクトにまとめている。

聞くところによるとそもそもの始まりが省電力テクニックとのことで、特にその章の内容は力が入っているように見える。

毎日Gitでカーネルをpullしたりmergeしたりpushしたりしています! という方々には不要かもしれないが、Linuxをユーザとして何気なく使っているけれどももう少し中身を知ってみたいな、というちょうど私のような読者には手頃な本だ。


2011年08月27日

_ [cooking] 焼き餃子

久々に鍋貼。わりと量多めに作ったつもりだったんだけど、結局全部食べてしまった。やばい?


2011年08月29日

_ [cooking] 豚肉と木耳と卵の黒酢炒め、トマトと水菜のサラダ、豆腐とワカメの味噌汁、きゅうりのぬか漬け

黒酢でこってりさっぱりと。いただきトマトもこれで終わり。


2011年08月30日

_ [cooking] 鶏肉とピーマンのナンプラー炒め、豆腐とワカメの味噌汁

具合があんまり良くなかったのでタイ風で少し元気づけ。