ただのにっき

■ 「後世に残る」のは紙か、電子か。

偶然だと思うが、「本(や資料)を後世に残す」という同じキーワードが踊る記事を立て続けに読んだ。ひとつは日経ビジネスオンラインの「“ブックオフビジネス”は業界全体で取り組むべき」で、古本業界の「目利き」がチョイスした本だけをデジタルアーカイブせよという提言。つっこみどころは色々あるがたぶんログインしないと最期まで読めないと思うので、一部だけ引用:

オンデマンド印刷技術も進化して、トナーの定着率の向上を果たしているが、それでも、紙にインクを吸い込ませるオフセット印刷に比べたら耐久年数には雲泥の差がある。1万年前のアルタミラの洞窟の絵が残されているように、自然物に溶けこんで記録されたデータの方が、はるかに過酷な年月に耐えうるのだ。

古代の壁画はべつに目利きが優れた作品を意図的に残したわけじゃなくて、たくさんあった壁画のうち、破壊や日照を免れて、かつ現代人が目にすることができたごく一部が奇跡的に知られているだけだ。希少性はあるが、同時代に製作された作品の中でとくに優れているわけではない。紙への印刷物にしたって、本当に長期間残そうと思ったら中性紙に顔料インクでも使わなければせいぜい100年というところなわけで、偶然残った1万年前の壁画と、大量生産が可能になってからの書籍の保存を同じ土俵で語るのはずいぶん乱暴な話だ。

我々がいまも優れた書籍を手に取れるのは、「目利き」の意図によって残りやすくなっているのはもちろんだが、それよりも大勢の人が分散して同じ物を保管していたことの方がよっぽど重要だ。どんなに良いものであっても、最初から一品モノとして制作されていたり、すべて同じ場所に保管されていたら、今よりもっとたくさんの作品が消失していたことだろう。このエッセイで「失敗する」と予言されている「電子アーカイブ」もどうやら「一箇所に」「1つだけ」保存するイメージのようだ。紙の本と同じように、複数のコピーを分散して残すという発想はないのだろうか。

もうひとつはTogetterにまとめられた民間事故調のWGメンバーからのメッセージ。事故調の報告書をどのように公表するかというくだりでやはり似たような話が出てくる:

後世の評価に委ねるためには、後世に残る形で報告書を残しておきたいと思う。であるならば、紙媒体のほうがいいのではないだろうか。

ちなみにこの秋山氏の発言から報告書の公表にあたっての要件を拾うと、「できれば無償で公開したい」「多くの人に行き渡らせたい」「後世に残したい」というところなのだが、なぜか行き着いた先が紙の書籍での販売とのこと*1。いまどきこの手の報告書が最初から電子化されていないことはまずありえないので、それをPDFにして(というか報告書の原本がPDFである可能性が高い)、ネットにポンと置くだけでこれらの要件は満たせるはずだが*2。もちろん、書籍という形でしか手に取れない人向けに並行して印刷物を販売するのは良いことだと思うが、Print on Demandのようなサービスだって今はある。どうもこの人も、「後世に残すなら紙」と思い込んでいるようにみえる。

本気で後世に残したいのなら、昆虫や魚がとっている戦略を真似れば良い。つまり「一度に多量に産む」のだ。一品モノの壁画には偶然に頼るほか後世に残る手段がなかったが、印刷技術の登場によってたくさんの複製が作れるようになった。だが紙はかさばって保管に困るし、複製コストも一定レベル以下には下がらない。しかし、電子データなら圧倒的な低コストで無数のコピーを生成でき、しかも保管場所もとらない。分散して保管しておけば、仮に人類が電気テクノロジーを失わないかぎり損なわれることはないだろう。

もちろん、保存メディアの種類だって多いほどよい。電子データだけでなく、紙でも残すべきだし、なんなら石版に彫っても良い。『後世に残るのは紙か、電子か』という問いの答えは「両方!」だ。少なくとも「紙だけ」に頼るよりはよっぽどマシなはずである。

■ いろいろgem化している

先日ようやくgem作成手法をわがものにできた(たぶん)ので、身の回りのいろんな制作物をgem化している。本来はライブラリを配布する仕組みではあるが、もちろんコマンドのパッケージにも使えるわけで、そういうツールはちょこちょこ公開しているので(おもに自分用だけど)。昨日は(数人が使っていると観測されている)Wassrfeedをgem化するなど。

Rubyスクリプトの配布・インストール方法はsetup.rbを始めいろいろあったけど、そういう作業抜きで環境に依存しないように作ろうとした結果が悪名高き「#!/usr/bin/env ruby」なんてshebangだったりするわけだ。そういう課題をgemは解決していたんだなぁ。今ごろ気づくなよという話だけど。ruby 1.9時代ならぜんぶgem化するべきなんだね。

ところで悩ましいのがはてなグラフAPIなのだけど(使ってるんですよ)、これはRubyForge上にあるものがまったくメンテされていないっぽいので勝手にGitHubに載せて1.9対応をしたものなのだけど、これをさらに勝手にgem化するのは気が引ける。というのも本家もgemで配布されているからなんだが。こういう場合はどうしたらいいかしらねー*1。元の開発者がクックパッドに転職しちゃったからなー……って、当の本人がforkしてるじゃん(笑)。

■ Kindle向けニュース配信システムをHeroku上に移動した

約1年ほど前から稼動していた各種ニュース(といっても現時点では日経新聞とInternet Watchだけ)をKindleに配信するシステムを、自前サーバ上のcronからHeroku上のClockworkに移植して、今日から実用開始した。

Kindle向けにニュースを配信する仕組みとしてはレシピが豊富なCalibreを使うのがメジャーなんだけど、クライアントPCを24H稼動しておくというのが節電が叫ばれるいまどきのソリューションとしてはイマイチと感じていて、長らく自分のサーバで回していたんだけど、もうちょっとPaaS(というかHeroku)を使い慣れておきたいと思っていたので練習台に。

Herokuでcron相当のサービスというとClockworkを使うということらしいので、1時間ごとに起きるように組んで、実際に配信するかどうかの判断は別途させるようにした。clockプロセスひとつでDynoを1個使ってしまうので、UIはなし。セコい(笑)。じゃあ設定はどこから与えるかというと、環境変数で指定したURLから毎回読み込むようにしたのだった。Dropboxにでも入れておけばどこからでも設定変更ができるという塩梅。

Heroku上でmobiファイルを生成させるためにkindlegenをgem化したり、メール送信にActiveMailerを使おうと思ったがRailsじゃなければその下で使っているMailを素で使ったほうが楽だとわかったり。もっとも、一番苦労したのはUTCで動いているHerokuに適切なTZを与えることだったりして(Time#localtimeに引数があるなんて初めて知ったよ)。まぁいろいろ勉強になります。

最初はちゃんとWeb UIをつけて誰でも登録して使えるようにしたら便利じゃね? と思っていたんだけど、人のサイトを勝手にスクレイピングして他人に配信するのはどう考えても違法なのであった。あとSendGridのfreeプランはメール送信数に制限があるし(ので各自で動かさないといけない)。とはいえコードは公開してあるもののドキュメントないから誰も動かせないだろうな(笑)。

こんなふうに自前で生成した「電子書籍」をメールで簡単にリーダーに送れて、それをクラウド上で管理できるというのがKindle最大のメリットで*1、このPersonal Documentサービスが完全におれをKindleにロックインしてしまっているのだよなぁ。他社でもこれ相当のことができないと、何かあったときの移転先に困るんだが。KoboやSONYには類似のサービスないのかな。