最近、諸事情で自宅の引っ越しをしたのですが。そこで、これをきっかけに生活の見直しをしようと思い立ち、自炊生活を始めてみました。ここで一つ、最近試したレシピをご紹介したいと思います。

—下ごしらえ > 調理 > スキャン—

1) 手頃なサイズの文庫本を見つけて、カバーを外し、不要な部分を全部剥ぐ

2) 机にバイスで固定して

3) おもむろに背表紙をカンナでゴリゴリ削る

4) ひたすら削る

5) ある程度削れたら、背表紙をめくってバラバラになったことを確認して下ごしらえ完了

6) ドキュメントスキャナで読み込んで、OCR情報付きのPDFに加工して完了

背表紙が糊で接着されているタイプの本なら、電子レンジやアイロンを使った加熱で糊を溶かして除去していく方法もあるらしいが、自分は上手くいかなかった。コツがあるのかな。

ということで、食べる方じゃなくて、下記のWiki言うところの読む方の自炊でした　:-)

「自炊」とは2ちゃんねるが由来の隠語で、 「自分で漫画や雑誌、書物などを電子化する」という意味です。 自炊技術Wiki

正直このWikiにかなり助けられました。本の解体がこんなに難しいとは思わなかった… 本気で手持ちの本の電子化を考えている人は、裁断機を買った方が賢明なようです。

PLUS 断裁機 裁断幅A3 PK-513 26-128

ところで、何故そんな苦労してまで、本を解体するのかという理由ですが、どうも調べてみると個人が本を電子化するには、今のところ一般向けのドキュメントスキャナを利用するしかなくて、そのためには本を解体する必要がある模様。例えば、自分の買ったのはCanon DR-2010Cで3万円未満くらい、本を解体してしまえば全自動でPDFまで加工してくる。

本をデジタル化するには、一冊アナログの本を解体する必要がある、ってのは不思議と面白い。何かを得るには何かを失う的な。

あと、そもそも何故本の電子化をするかというと、今回の引っ越しで家にある本の整理をしたところおよそ1000冊程あって、引っ越しの整理で死にそうな思いをしました… さらに、新居で少し部屋が狭くなったこともあり、断腸の思いで結局500冊程ブックオフで処分してしまいました。悲しい！:-(

この教訓を生かすために、次からは良い本は残し、ピンとこなかった本は電子化して残そうかなと考えた次第です。本を解体するのはもったいないけど、どうせ次の引っ越しで処分をするならまだ電子化したほうがまし、かなと。

一生引っ越さない、という選択肢も無くは無いが、それでもいずれは限界が来るようですし

さて、木造の床は、何冊の本まで耐えられるのか？http://oshiete.homes.jp/kotaeru.php3?qid=2537813 こちらを信じる限り8畳の部屋なら、最低2,400kgまでは耐えれるように設計するらしい。（ちなみに、「豊島区の底抜けおじさん」は、最低でも6,000kgは溜め込んでたらしいよ。部屋の広さに関して情報見つからんけど、20畳以上の部屋であるわけなさそうなので、そりゃ底抜けるわ。というより、よく耐えたよ。）8畳にはサンデー14,000冊まで

また技術書は、重い・持ちにくい・検索できない、と三重苦なので読み終わった後はPDFで保管できると、実用的にも良いかな。デスクトップ検索で横断検索できるのは便利そう。

あと本をデジタル化してしまえば、本というインターフェイスを変えて読むこともできる。iPhoneで読むとか、読みながら良い文があったらTumblrで引用してメモするとか、本の中身を分析してメタデータの加工・付加もできる、相互の引用関係をリンクとして抜き出してみたり。

「ある本に違う本を読ませて、自分の中の文章がどこに出てくんのか、自分の中の文章がどっから来たのかってのを探してる」わけ。そんなことして、何になんのか、ってのは、また近い将来詳しく見ていきたいけど、とりあえず、今日は、Amazonに行って、どんなことになってきてるのか見てみましょ。 Amazonで「本が本を読む」様子でもみましょ

というか、この id:bookscanner さんのサイトが凄い詳しくて、刺激的。電子書籍業界？の人なのかな。

本を電子化することで起こる、人間に関わるインターフェイスの未来（電子ブックビューアとか）も面白いけど、コンピュータが本を分析・加工する、データベース＆メタデータの未来（本が本を読む世界と表現されてる）が面白い、と書かれている。

と、色々将来に期待はあるけど、まぁ取り急ぎぼちぼちいらない本の電子化を進めつつ、やっぱ電子ブックビューア買うしか無いかな・・、Kindle DXもタイミングよく発表されたし。

このブログ、ここ一年程色々とあり更新が滞ってましたが、、そろそろ復活しようかなと思います。 どうせなので、ついでにブログエンジンも見直そうかと思い、最近 Github のユーザページで使われている Jekyll で作ってみました。

決め手としては、当初はGithubのホスティング利用を考えていたので

• Gitで記事を履歴管理できる（Emacsとかで書いて、GitでPush）
• ホスティングが無料（Github利用）
• Markdown記法が使えるし、コードハイライトもある
• 単純にHTMLを再構築していくタイプなので、DBが不要でシンプル（コメントは別サービスを使うので良い）
• いざとなったら自分でホスティング簡単だし、カスタマイズもforkすれば簡単

という辺りを狙っていました。

まあ結局は、古いブログからの移行の問題（リダイレクト設定したいURLが少々）と、細かい部分でやっぱJekyllをforkしてカスタマイズしたくなったので、結局自分のサーバでホスティングすることに落ち着きました。

それにしても改めて、Github便利ですね。gitとしても普通に便利ながら、Rubyに限定すればGemを自動で生成してくれて配布が簡単だったり、今回使わなかったユーザページ機能も、ちょっとしたプロジェクトの更新情報を書いていくには丁度良いくらいで便利。

あとJekyllのスペックが Cucumber で書いてあって、初めてちゃんと読んだけど、このCucumberの可読性は凄いなぁ、驚異的。これで自動テストできると思うと、本当にエクセルでテスト仕様書を作るのが馬鹿らしくなってくる… まあ必要な時は書くしかないと思うけど、この仕様書がそのまま自動テストのコードってのは魅力的だな。

後は、RSSのリダイレクト設定とか、ゆくゆくしていこうと思います。

参考ページ

• Github Pages - Home
• Jekyll - Github:wiki
• Jekyllで始める簡単ブログ

前回から引き続き、OpenIDの "関連付け" と OpenSocial の汎用データストレージについて

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (1)

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (2)

association（共有鍵の交換）

OpenIDのspecでは認証リクエスト前にOpenID認証局と共有鍵の交換を行うことが推奨されている。

参考：http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#associations

本来、鍵交換にはDiffie-Hellman鍵共有アルゴリズムを利用するべき、と思うけど今回DH鍵交換アルゴリズムを実装するのが目的ではないのでsettion_typeは一番単純な "no-encryption" で実装する。

なお "no-encryption" の場合SSL（https）で通信するべきとのこと（"no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption.）

まずOpenID RPからOPへ association リクエストを投げる、前回のHTMLベース探索と同様に OpenSocial API の makeRequest で通信を行い、認証結果を受け取る。

openid.association = function(request_option, callback){
  var self = this;
  var params = {};
  params.contentType = gadgets.io.ContentType.TEXT;

  //パラメータをクエリーストリングとして付加しURLを組み立てる
  var param = [];
  param.push(["openid.ns","http://specs.openid.net/auth/2.0"]);
  param.push(["openid.mode", "associate"]);
  param.push(["openid.assoc_type", "HMAC-SHA1"]);
  param.push(["openid.session_type", "no-encryption"]);
  var url = this.makeURL(request_option.provider, param);

  //association HTTPリクエスト
  gadgets.io.makeRequest(url, function(result){
    //association レスポンス解析
  }, params);
}

送る方は簡単 session_type は "no-encryption"

共有鍵のキャッシュ -> OpenSocial汎用データストレージ

associationレスポンスを解析し有効期限（expire）が切れるまでキャッシュしておく。

今回はキャッシュのために OpenSocial API の汎用データストレージを利用する。このストレージ領域には key & value で任意の文字列を保存することが可能で、各アプリケーションそれぞれ別の保存領域となり、ユーザ毎にユニークとなるというデータストレージらしい。

opensocial.DataRequest クラスの newUpdatePersonAppDataRequest(ユーザID, key, value) メソッドを利用する。

http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newUpdatePersonAppDataRequest

下記のようにパラメータを解析し結果をJSON形式の文字列へ変換、それをvalue、OPエンドポイントURLをkeyとする。

gadgets.io.makeRequest(url, function(result){
  var results = {};

  //レスポンス結果を解析
  var params = result.data.split("\n");
  for(var i=0; i < params.length; i++){
    if(params[i].search(":") > 0){
      var param = params[i].match(/^([^:]*):(.*)/);
      results[param[1]] = param[2];
    }
  }

  //assoc_handle, mac_key, expires等必要な情報をJSON形式の文字列へ
  var value = this.toJSON({
    "assoc_type":results["assoc_type"],
    "expires_in":results["expires_in"],
    "mac_key":results["mac_key"],
    "session_type":results["session_type"]
  });
  
  //汎用データストレージへ保存、keyはOPエンドポイントURL
  var req = opensocial.newDataRequest();
  var key = request_option.provider;
  req.add(req.newUpdatePersonAppDataRequest(req.PersonId.VIEWER, key, value));
  req.send(function(data){
    callback(result, data);
  });
}, params);

本来のDH鍵交換でやる場合は・・・HTTPリクエストをやって、データストレージへ期限切れるまでキャッシュという大枠は変わらない筈。

今回の gadgets.io.makeRequest API のようにOpenSocialコンテナ（myspace / orkut等）がプロキシとして働くHTTPリクエストの場合でも、DH鍵交換アルゴリズムなら盗聴の危険性は無いってことで良いのかな。あ、でもOpenSocialコンテナによる改竄の危険はあるのか。

まあ実装実験ということで。

以上

ちょっとしたJavaScriptのアプリケーションを作る時に、ちょっとしたデータ保存領域が欲しい事は結構あると思う。（占いアプリで占い履歴とか、占い選択肢とか）

その時サーバを自分で立ててWebAPIでデータストレージを用意してやるのは面倒、かなり面倒。

OpenSocial標準のAPIで汎用的なデータストレージが用意されていて、key & value ペアで任意の文字列を保存できるのは結構使い所ありそうだと思う。JSONにしてやれば構造化もできるわけだし。

AmazonEC2上で動いて、Webブラウザから開発・運用できるRailsアプリケーションのホスティングサービスheroku.com

Herokuが、ブラウザー内でRuby on Railsの開発を可能に

Heroku.com

がGitによるソース管理 & ローカル開発に対応したそうなので、ひとつ試してみる。Macで

Gitとherokuクライアントのインストール

まずPCにGitが入ってないのでインストール。そういえばGitが海外のRubistの間で流行ってるらしいねー、Coderepos的なGithubってGitリポジトリ共有サイトもあるらしいし。で今回のherokuもソース管理にGitを使うのでインストール

% sudo port install git-core

その後、herokuのコマンドラインクライアントをインストール

% sudo gem install heroku

自分用のssh公開・秘密鍵が無ければ用意しておく

% ssh-keygen -t rsa

自分のherokuアカウントと、ssh公開鍵を関連付ける

% heroku list
Enter your Heroku credentials.
Email: mymail@example.com
Password: ********
Uploading ssh public key
=== My Apps
resttest

登録成功、この時点でWeb上から作成済みのアプリケーションがあると、表示される。

テストアプリケーション作成

コマンドラインから新しいアプリケーション "tktest" を作成

% heroku create tktest
Created http://tktest.heroku.com/

ブラウザで開くと確かに作成済み、次にリポジトリからローカルへ落とす

% heroku clone tktest

裏では git clone tktest@tktest.heroku.com みたいなコマンドを実行してるっぽい。ここで何故かssh-keyが見付からないと言われたので ~/.ssh/config を書いておいた、Protocol 1 は不要だと思う。

% emacs ~/.ssh/config
Host *
IdentityFile ~/.ssh/id_dsa
IdentityFile ~/.ssh/identity
Protocol 2,1

tktestフォルダ内に通常通りRailsアプリのディレクトリができている筈

% cd ./tktest
% ruby script/server

mongrelが立ち上がり、とりあえずローカル開発準備完了

編集、コミット、デプロイ

新しいコードを作って適当に編集

% ruby script/generate scaffold Post body:text
.........

とりあえずできた、localhostで確認してからコミットする

% git add .
% git commit

gitの使い方がよく判らないけど、とりあえずコミット完了。本番環境へ反映する

% git push
Enter passphrase for key '.ssh/id_rsa':
Counting objects: 43, done.
Compressing objects: 100% (29/29), done.
.........
HEAD is now at e6b0b72... test
NOTICE: CREATE TABLE will create implicit sequence "posts_id_seq" for serial column "posts.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "posts_pkey" for table "posts"
(in /mnt/home/userapps/15472)
== 1 CreatePosts: migrating ===================================================
-- create_table(:posts)
-> 0.1817s
== 1 CreatePosts: migrated (0.1818s) ==========================================

herokuのリポジトリへPushと同時に rake db:migrate と mongrelの再起動までやってくれるぽい。確認してみる

http://tktest.heroku.com/posts

うむうむ、動いてる。

以上

まあちょっとしたアプリケーション作るには楽で良いなheroku.com。現在はベータ中で無料、正式サービスになると課金が始まるらしいけどAmazon EC2で動いているので、課金額もそれくらいになるのかな。Google App Engineと比べると面白い機能は無いけど、作ったサービスの人気が出て自分のサーバで運用したくなったときにheroku.comは良いな。Rails & mongrel & MySQL(?) という普通の環境なので。

例えば突然 heroku.com のサーバが爆発してサービスが止まっても、ローカルにソースコード一式がで揃っているので自分のサーバを用意して復旧できる。データのバックアップだけは気を付ける必要あるけど、ちなみに heroku.com 本番環境の管理はWebからやれ、というポリシーらしい

DB管理画面

コンソール画面（ruby script/console）

あと、rakeタスクを実行する画面もある。

そういえば、ちょうど昨日Google app engineでちょっとしたアプリケーションを作る話を読んで

Google App Engineの使い道、tiny web service

確かに「サーバサイドで処理しないとできないけど、わざわざサーバを用意するのは面倒だな」ってときに、Google app engine や heroku.com や appjet.com なんかの環境が便利だなと思った。

そういえば、半年ほど前からfooo.nameの監視にmuninを入れていて、muninプラグインを書いてRailsのパフォーマンスをモニタリングできるようしているのですが

その手順を書いておくと誰か嬉しい人がいるかなと思ったので、メモを残しておきます。サーバはAmazon EC2

muninのインストール

apt-getでmuninをインストール

% apt-get install munin munin-node
% /etc/init.d/munin-node start

Apache・MySQL・CPU / メモリ / ネットワーク / ロードアベレージ 辺りのモニタリングが始まる。実際にはcronが設定されていてデフォルト５分に１回モニタリング結果がHTMLとして出力される。出力される場所はconfigファイル /etc/munin/munin.conf にあるので、好みで編集

% emacs /etc/munin/munin.conf
dbdir /var/lib/munin
htmldir /var/www/munin
logdir /var/log/munin
rundir /var/run/munin

あとは /var/www/munin 以下をApacheで見えるように設定、Virtual hostを設定してBasic認証を掛けておいた

% emacs /etc/apache2/httpd.conf
<VirtualHost *:80>
  DocumentRoot /var/www/munin
  ServerName *********
</VirtualHost>
<Directory "/var/www/munin">
  AuthType Basic
  AuthName "Munin zone"
  AuthUserFile /etc/apache2/.htpasswd
  Require user ********
</Directory>

Railsのログをmuninでモニタリング

あとは、この↓サイトを真似してやればOK

Monitoring Rails Performance with Munin and a Mongrel

Railsの出力するlogから total / render / db の時間を見つけ max と avg の値を求め、muninでそれを監視する。Railsアプリケーションの scriptフォルダへ以下のスクリプトを置く

% emacs script/rails_log_monitor.rb
・・・・・・
h = Mongrel::HttpServer.new("127.0.0.1", PORT)
h.register("/avg_response_time", ResponseTimeHandler.new(:average))
h.register("/max_response_time", ResponseTimeHandler.new(:max))
h.run.join
rails_log_monitor.rb

上記スクリプトを実行すると port 8888 でmongrelが立ち上がる、muninはそこへアクセスし結果を取得する

% ruby script/rails_log_monitor.rb

次に、muninプラグインとして下記のスクリプトを /etc/munin/plugins 配下へ

avg_response_time

avg_response_time と max_response_time という名前で置いておく。結果muninが http://127.0.0.1:8888/#{ファイル名} へアクセスし結果を取得、グラフ化。

以上

基本このサイトを真似してやればOK、rails_log_moniter.rb を好きにいじれば ”特定のアクション・コントローラ・処理" 等をグラフ化してモニタリングできる筈。