Hatena::ブログ(Diary)

Dive in Blue RSSフィード

2011-05-17

passenger+sinatraで同一ドメイン内に複数のsinatraアプリを動かす方法

AWSのトーキョーregionに作ったEC2インスタンス(Amazon Linux AMI)上に、passengersinatraインストールし、passengerで同一ドメイン内のサブディレクトリとして複数のアプリを動かしたかったので調べました。(東京regionとか実は関係ない)

やりたかったこと

http://{何かのドメイン}.com/app01/

http://{何かのドメイン}.com/app02/

を別々のsinatraアプリとして動かしたい。

環境

ruby 1.9.2

passenger 3.0.7

sinatra 1.2.6

やりかた

httpd.confの設定
DocumentRoot "/var/www/html"
RackBaseURI /app01
RackBaseURI /app02

<Directory /var/www/html>
   Options FollowSymLinks
</Directory>
DocumentRootにsymlinkを作る
/var/www/html
  ├ app01 -> {$HOME_DIR}/htdocs/app01/public
  └ app02 -> {$HOME_DIR}/htdocs/app02/public
アプリケーション本体

自分のホームディレクトリにこんな感じでアプリケーションを作る

{$HOME_DIR}/htdocs/
  ├ app01
  │ ├ config.ru
  │ ├ app.rb
  │ ├ public/
  │ └ tmp/
  └ app02
    ├ config.ru
    ├ app.rb
    ├ public/
    └ tmp/

It works !

ちょっとはまったところ

config.ru

ruby 1.9.2だとカレントディレクトリへのパスが自動で通ってないらしいので

require 'app'
run Sinatra::Application

では動かない。

require './app'
run Sinatra::Application

で明示的に指定したら上手くいった。

2010-11-21

恋愛黒アワビ理論とその最適解について

だいぶ昔、TV(ぷっすま)のゲームを見ていた時に発見した人生の真理を、先日友達と飲んでいたときに思い出しました。「恋愛黒アワビ理論」と名付けたその真理について、Twitterに書くには余白が狭すぎたのでブログ記事にします。

ゲームの概要はこんな感じでした。

  1. 4つのアワビを使った料理が出てくる
  2. 1つだけ黒アワビ、残り3つは冷凍アワビで作られている
  3. 最初から順々に試食していき、「黒アワビだ!」と思ったところでストップ
  4. ストップした後の料理は確かめることができない

このゲームのポイントは、それが黒アワビだと思ったらストップし、その先を確かめることが出来ない点です。つまり4つを食べ比べて評価することが出来ない。

これってそう、恋愛もまさに同じです。モラルを守って生きる範囲では、何人目の彼女/彼氏が運命の人なのかを判断するには、人は同じ状況下に置かれるわけです。(4つ比べながら選べる人はそうすれば良いと思います)

ということでこの真理(というには大げさです)を「恋愛黒アワビ理論」と名付けましょう。僕は自分にとっての黒アワビを食べたいわけですが、どうしたらその確率を高くすることができるでしょうか?

実はこの恋愛黒アワビ理論、一番黒アワビを選ぶ確率が高い方法があります。この問題は離散数学上の有名な問題で、「お見合い問題」「ナンパ問題」と言われています。「います」とか書いてますがさっきググッて知りました。

以下のページが分かりやすいので引用します。

数学が教える最高の女性と結婚する方法初恋から3人目まではじっと我慢〜恋愛の政治・経済学(14)

◯問題

 「自分が生涯でつき合う女性の数を N 人とします。男性は、女性とつき合っている間に結婚するかどうかを『結婚』『別れる』の二者択一で選ぶとします。いったん結婚を決めたら、それ以後の交際はなくなりゴールインです。また一度別れた女性に後から結婚を申し込むことはできません」

 さて質問です。一番良い女性と結婚する確率を最大にするためには、どのような戦略を取ればいいでしょうか?

◯結論

確率的には、全体の出会い総数の36.8%以降に位置する人と結婚する、例えば10人の女性と交際するとしたら、最初の3人までは恋愛お試し期間として、4人目以降に、最初の3人の女性よりも魅力が上回った女性と結婚するのがベストである、ということになります。

数学的な証明

 つき合う人数 N 人に対して、そのうち最高の女性が j 番目に現れると仮定。(s − 1) 番目まではデータ収集とし、s 番目から結婚への意思決定を開始。s 番目以降は、それまでの中で一番良い人物であったらその人と結婚するという戦略を取る。

 最初の (j − 1) 人の内で仮の最高の女性が最初から (s − 1) 番目までに現れる必要がある。 その確率は (s − 1)/(j − 1)。

 s 人目から本番とした時、最高の女性(交際範囲のうちナンバーワンの女性)をゲットできる確率は、

Ps,n = (1/n)Σj=sn (s − 1)/(j − 1) = (s − 1)/nΣj=sn 1/(j − 1) = −xlnx

 n→∞ の時には 、j/n→t、1/n→dt、s/n→x で、 P = x∫x1 dt/t = −x log x となり、

 x = 1/e の時 P = 1/e (約36.8%)になる。

しかし、この恋愛黒アワビ理論の最適解を実世界に応用するのには、「付き合う人数N」が全く分からないという致命的な不都合があります。N=3なのに3つ見送ったらもうアウトですが、逆にN=30なら10球見逃してもいいわけで。ここが何とも悩ましい。

結論としては「初恋の相手と焦って結婚するな」「でも、今見逃したの黒アワビかも知れないのに、もうボール来ないよ」というところでしょうか。以上どうでもいい記事でした。

2010-07-24

「ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜」に出席してきました

KVSについて興味を持って調べているのですが、他社でどのようなKVSが、どう利用されているのか、どう評価されているのかが聞きたかったので、グリーCTOの藤本さんが講師を務めたセミナー、「ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜」に出席してきました。

データ集計をどうやってやるかとか、Consistencyな更新(cas操作を使う)とか、シリアライズ形式のこととか、気になっていた部分のお話をたくさん聞けたので、とてもためになるセミナーでした。

忘れないうちに気になったところを簡単にメモしておきます。

*スライドの流れ通りではないです

1:1型(key : value)KVS

  • いわゆるKVS。単純な実装なので安定感がある。利用実績も豊富
  • kumofs, Flare, voldemote, Tokyo Tyrant, etc..たくさんのソリューションがある
  • グリーでは足あと帳という機能で1:1型のKVSを利用している(多分Flare?)
一つのKeyに対応するデータを複数格納したい場合
  1. Keyを分けて複数に格納する
    • getのクエリが多くなりがちなので、multi-getで取ってくる
    • set時にトランザクション処理ができないのが問題
      • 例)ユーザーAのHPとMPを同時に更新したいのに、HPだけ更新が成功しMPは失敗するようなことがあり得る
  2. Valueにシリアライズした階層データ(PHPArrayとかRubyPerlのHash)を格納する
    • 藤本さん的にはどんどんシリアライズして使っちゃう(キーを分けて持つより良い)
    • シリアライズのフォーマットは、グリーではシンプルにPHPのserializeを使ってる
    • 多言語間でやり取りするならJSON、MessagePack。MessagePackはいいんじゃないか
casについて
  • memcachedがサポートしているデータ操作の一つ
  • compare and swap の略、比較してから交換する。
  • データ取得後更新する時に、他のプロセスから値が更新されていないかどうかを知るための仕組み
集計どうしよう問題

基本的に1:1型のKVSではKeyでの検索もValueでの検索も出来ない。でも集計が必要なときは以下のような方法

  1. 全データDumpする
    • これはイケテないから無しだと思う(藤本さん)
  2. 適当なタイミングでRDBMSにFlush
    • こっちの方が無難だと思う(藤本さん)

1:n型(key : value)KVS

  • 1つのKeyに対し複数のValueを持つタイプのKVS。
  • Redis, MongoDB, CouchDB, Cassandra, GAE/DataStore, HBaseとか
  • 複雑な実装。パフォーマンスなどいろいろ問題
Redis
  • Valueのデータ型としてListをサポート。
    • push / pop などの操作ができる
  • しかし、、実装がいけてない気がする
    • パーティションの機能がない
    • マスター/スレーブの設定が面倒
    • スレーブに書き込めちゃう
Cassandra
  • もっとテーブルっぽい
  • Writeの性能を上げることに血道を上げている印象
    • スゴイけど、それSSDでよくない?

その他メモ

  • プレゼンツール
  • 5キー問題に如何にして耐えるか(携帯ブラウザのリロードボタン)
  • ベクタークロック
  • KVSからのデータの検索
    • Keyで検索
    • Valueで検索
    • Like的な何か
  • index server
  • ring / sorted keys
  • skip graph
  • MongoDBの実装は結構PowerPlayな感じ・・

補遺

  • カウンターとかキューのようなデータ構造が、casを使えば実装できます。cas操作についてはこのページが分かりやすいです
  • 懇親会でちょっと藤本さんとお話させていただきました。新しい技術は導入いろいろ難しいですよねと言ったら、「実績は作ればいいんですよ!」と言われてプレッシャー。。

2010-07-22

公務員の人件費に関わる支出は「短期的」には増えても仕方ない

参院選もちょっと忘却の彼方に去りつつある今(2010/07/21)、かなり時期を逸していますが、公務員の人件費削減と天下り根絶のお話です。結論からいうと僕は、「将来的な」公務員人件費の削減と天下りの根絶には、「短期的に」公務員の人件費に関わる支出が増えるのはやむ無し、と思っています。(予算の専門家ではないので、本当はこういうお金がどこから出てくるのかも良く分かっていないですが)

公務員の人件費削減と天下り根絶は複雑な問題

先の参院選でどこの政党公務員の人件費削減と天下り根絶を掲げていましたが、これは日本の労働市場にも絡んだ複雑な話で、単純な賃下げや首切りでは上手くいかないです。公務員だって人の子なんだから、何のオプションも無くいきなり賃下げ・首切りなんて受け入れられるわけがない。だったら天下りなんて当然なくならないよと思うわけです。

日本の硬直化した労働市場で、支援なしに公務員が民間に移れるか

で、問題なのが、日本の労働市場の流動性が低すぎて人材がポータブルでない点。公務員の人件費を減らし、かつ天下りを根絶するつもりなら、リストラされた公務員がどうやって糧を得ていけるのか、国がビジョンを示し、お金も使うことが必要。つまり、労働市場の流動性を高めるとともに、民間に移った人材が独り立ちして働けるように、一部税金を使ってでも再就職支援をすべきではないかと。(この「支援」という言葉が曖昧で気に入らないけど仕方ない)

退職時オプションとして給与の上乗せも

合法的な解雇がタブー視されている日本ではあまり知られていない(僕が知らなかっただけかもしれない)けど、海外でも整理解雇時には就職斡旋や退職金割増でオプションを付けるのが普通らしい。日本でも早期退職制度(を口実にした解雇)で2年分の給与をオプションにする企業もあるとか。これがないといきなり失業者を大量に生み出すことになってしまうのだし、企業と従業員の信頼関係的にも必要な支出だと思います。

天下りは副作用の大きい退職時オプション

公務員についてみると、天下りは退職オプションの歪んだ形といえます。そもそも天下り自体が悪いというより、天下りした先で収益性のない事業で国の予算を浪費することが一番大きな問題。だから、2年以上の給与を退職時に上乗せするオプションにまで踏み込んで、公務員の「天下りでない」民間への流入を支援すべきだと思っています。そのためには税金の一時的な投入も仕方ないのかなと。

ちなみに

僕は市場を重視した「小さな政府」を支持していて、市場に多くを任せ、運悪く落とされた人はセーフティネットでサポートし、何度でもチャレンジ可能な社会が望ましいと考えています。(キレイ事言うのは簡単だけど、解決しないといけない問題が沢山あるのは分かってるつもり)

独り言

雇用とか社会に関するエントリを書くとネガティブな反応も結構多かったり。プロの書き手でない僕は結構落ち込んだりもするので、慎重に書いたつもりですがちょっと怖いなー。

2010-07-20

UQWiMAXでBフレッツを置換し、低価格でどこでも定額インターネット

ネコがダンボールに滑り込むCMで有名なUQWiMAX。若干イロモノ感の漂うCMとは裏腹に、サービスは硬派な無線データ通信キャリア+端末プロバイダで、ビックカメラなどの小売業者にもMVNOとしてサービスを提供しています。このビックカメラがMVNOしているUQWiMAXがお買い得だったので契約してみました。

なぜ興味を持ったか

  • iPad-WiFi版が移動中に役に立たないため、使うシチュエーションがかなり限定されていた。もっと使いたい。
  • NTTの固定回線(ぷらら+Bフレッツ)をWiMAXに置換できれば、月4,000円くらいの定額で部屋でも外出先でもネットが使える

他社サービスとの比較(2010.7.20現在)

名前イーモバイルドコモUQWiMAX(*1)
通信速度 下り/上り7.2Mbps/5.8Mbps7.2Mbps/5.8Mbps40Mbps/10Mbps
長期契約割引/解約金 (*2)2年/33,600円〜1,400円2年/26,880円〜9,975円1ヶ月/2,100円
実質本体価格(定価)1円(37,800円)1円(37,000円)4,800円(19,799円)
月額利用料 定価5,980円9,764円4,480円
月額利用料 割引利用時3,980円/4,980円4,410円/5,980円3,780円/4,480円
転送量制限366Mb/日300万パケット/3日無制限

*1 UQWiMAXビックカメラキャンペーンの内容

  • URoad-7000という機種を、希望小売価格19,800円を、BIC定額プランとセットで4,800円で販売。
  • ビック定額プランでは1ヶ月3,780円の定額料金でWiMAXが利用可能。
  • 解約違約金は最初の一ヶ月だけ、2,100円。
  • 〜2010/7/31までに契約すると、〜2010/8/31まで、3,780円の基本使用料が無料

詳しくはこちら - http://www.biccamera.com/bicbic/jsp/w/service/bic_wimax/index.jsp

*2 割引は複雑なので下記の契約について

~イーモバイル:にねんM契約時

~ドコモ:定額データプラン スタンダード(バリュープラン含む)を新規契約と同時に定額データ スタンダード割契約時

各社サービスを比較した感想

  • イーモバイルのメリット
    • 端末が小さくてカワイイ
  • イーモバイルのデメリット
    • 契約の縛りがきつい(解約手数料が高い)
    • 上限転送量が決められてる(366M/day)
  • ドコモのメリット
    • サービスエリアが圧倒的に広い
  • ドコモのデメリット
    • 料金が高め(最初の1年は4,410円、2年目〜は5,900円)
    • 契約の縛りがきつい(2年以内の解約は26,880円〜9,975円くらい)
    • 上限転送量が決められている(300万パケット/直近3日間)
  • UQWiMAXのメリット
    • 回線速度が速い
    • 上限転送量がない
    • 1ヶ月使えば解約違約金がかからない
  • UQWiMAXのデメリット
    • エリアが狭い(自宅でどれくらいの電波受信可能か?)

UQWiMAXの一番の懸念点は電波が入るかどうかです。「TryWimax」という、15日間端末を無料で貸し出すキャンペーンを提供していますが、8/31まで無料だったら、購入しても大して損はしなさそうだったので、思い切って買って試してみることにしました。

UQWiMAXを試してみた感想

電波について
  • 自宅内(練馬区の西の外れ)
    • マンションが鉄筋で少し電波が弱いです。回線速度は平均で下り2Mbps、上り1Mbpsくらいです。
  • 移動中(自宅〜東久留米間)
    • 電車に乗っている間は全く切れず。速度は測っていませんが電波シグナルは最大を示していました。
端末について
  • URoad-7000の端末はイケテないところが多いです
    • WiFi稼働中は電池が3.5時間しか持たない。
    • アダプタからしか充電ができない。USB接続は給電のみ(充電はされない)
      • ドコモのポータブルWiFiBuffalo)などはUSBから充電可能
    • 端末のデザインがかなり残念すぎる。。

結論

  • 回線速度的には、僕が家で使う用途には全く問題ありませんでした。
    • オンラインゲームなどで激しく使う場合は物足りないかも知れませんが
  • 固定回線のBフレッツは解約し、しばらくUQWiMAX一本で行こうと思っています。
  • もっとスペックのいい端末がでたり、ドコモが本気出してきたら乗り換るかもです。