passenger+sinatraで同一ドメイン内に複数のsinatraアプリを動かす方法
AWSのトーキョーregionに作ったEC2のインスタンス（Amazon Linux AMI）上に、passengerとsinatraをインストールし、passengerで同一ドメイン内のサブディレクトリとして複数のアプリを動かしたかったので調べました。（東京regionとか実は関係ない）
やりかた
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 !
恋愛黒アワビ理論とその最適解について
だいぶ昔、TV（ぷっすま）のゲームを見ていた時に発見した人生の真理を、先日友達と飲んでいたときに思い出しました。「恋愛黒アワビ理論」と名付けたその真理について、Twitterに書くには余白が狭すぎたのでブログ記事にします。
ゲームの概要はこんな感じでした。
- 4つのアワビを使った料理が出てくる
- 1つだけ黒アワビ、残り3つは冷凍アワビで作られている
- 最初から順々に試食していき、「黒アワビだ！」と思ったところでストップ
- ストップした後の料理は確かめることができない
このゲームのポイントは、それが黒アワビだと思ったらストップし、その先を確かめることが出来ない点です。つまり４つを食べ比べて評価することが出来ない。
これってそう、恋愛もまさに同じです。モラルを守って生きる範囲では、何人目の彼女/彼氏が運命の人なのかを判断するには、人は同じ状況下に置かれるわけです。（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)/ｎΣ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球見逃してもいいわけで。ここが何とも悩ましい。
結論としては「初恋の相手と焦って結婚するな」「でも、今見逃したの黒アワビかも知れないのに、もうボール来ないよ」というところでしょうか。以上どうでもいい記事でした。
「ソーシャルアプリで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に対応するデータを複数格納したい場合
casについて
- memcachedがサポートしているデータ操作の一つ
- compare and swap の略、比較してから交換する。
- データ取得後更新する時に、他のプロセスから値が更新されていないかどうかを知るための仕組み
1:n型（key : value）KVS
- 1つのKeyに対し複数のValueを持つタイプのKVS。
- Redis, MongoDB, CouchDB, Cassandra, GAE/DataStore, HBaseとか
- 複雑な実装。パフォーマンスなどいろいろ問題
Redis
Cassandra
- もっとテーブルっぽい
- Writeの性能を上げることに血道を上げている印象
- スゴイけど、それSSDでよくない？
その他メモ
補遺
- カウンターとかキューのようなデータ構造が、casを使えば実装できます。cas操作についてはこのページが分かりやすいです
- memcachedプロトコルCAS操作について - さくらインターネット研究所Blog
- 懇親会でちょっと藤本さんとお話させていただきました。新しい技術は導入いろいろ難しいですよねと言ったら、「実績は作ればいいんですよ！」と言われてプレッシャー。。
公務員の人件費に関わる支出は「短期的」には増えても仕方ない
参院選もちょっと忘却の彼方に去りつつある今（2010/07/21）、かなり時期を逸していますが、公務員の人件費削減と天下り根絶のお話です。結論からいうと僕は、「将来的な」公務員人件費の削減と天下りの根絶には、「短期的に」公務員の人件費に関わる支出が増えるのはやむ無し、と思っています。（予算の専門家ではないので、本当はこういうお金がどこから出てくるのかも良く分かっていないですが）
公務員の人件費削減と天下り根絶は複雑な問題
先の参院選でどこの政党も公務員の人件費削減と天下り根絶を掲げていましたが、これは日本の労働市場にも絡んだ複雑な話で、単純な賃下げや首切りでは上手くいかないです。公務員だって人の子なんだから、何のオプションも無くいきなり賃下げ・首切りなんて受け入れられるわけがない。だったら天下りなんて当然なくならないよと思うわけです。
日本の硬直化した労働市場で、支援なしに公務員が民間に移れるか
で、問題なのが、日本の労働市場の流動性が低すぎて人材がポータブルでない点。公務員の人件費を減らし、かつ天下りを根絶するつもりなら、リストラされた公務員がどうやって糧を得ていけるのか、国がビジョンを示し、お金も使うことが必要。つまり、労働市場の流動性を高めるとともに、民間に移った人材が独り立ちして働けるように、一部税金を使ってでも再就職支援をすべきではないかと。（この「支援」という言葉が曖昧で気に入らないけど仕方ない）
退職時オプションとして給与の上乗せも
合法的な解雇がタブー視されている日本ではあまり知られていない（僕が知らなかっただけかもしれない）けど、海外でも整理解雇時には就職斡旋や退職金割増でオプションを付けるのが普通らしい。日本でも早期退職制度（を口実にした解雇）で2年分の給与をオプションにする企業もあるとか。これがないといきなり失業者を大量に生み出すことになってしまうのだし、企業と従業員の信頼関係的にも必要な支出だと思います。
天下りは副作用の大きい退職時オプション
公務員についてみると、天下りは退職オプションの歪んだ形といえます。そもそも天下り自体が悪いというより、天下りした先で収益性のない事業で国の予算を浪費することが一番大きな問題。だから、2年以上の給与を退職時に上乗せするオプションにまで踏み込んで、公務員の「天下りでない」民間への流入を支援すべきだと思っています。そのためには税金の一時的な投入も仕方ないのかなと。
ちなみに
僕は市場を重視した「小さな政府」を支持していて、市場に多くを任せ、運悪く落とされた人はセーフティネットでサポートし、何度でもチャレンジ可能な社会が望ましいと考えています。（キレイ事言うのは簡単だけど、解決しないといけない問題が沢山あるのは分かってるつもり）
独り言
雇用とか社会に関するエントリを書くとネガティブな反応も結構多かったり。プロの書き手でない僕は結構落ち込んだりもするので、慎重に書いたつもりですがちょっと怖いなー。
UQWiMAXでBフレッツを置換し、低価格でどこでも定額インターネット
ネコがダンボールに滑り込むCMで有名なUQWiMAX。若干イロモノ感の漂うCMとは裏腹に、サービスは硬派な無線データ通信キャリア＋端末プロバイダで、ビックカメラなどの小売業者にもMVNOとしてサービスを提供しています。このビックカメラがMVNOしているUQWiMAXがお買い得だったので契約してみました。
なぜ興味を持ったか
他社サービスとの比較（2010.7.20現在）
| 名前 | イーモバイル | ドコモ | UQWiMAX（＊1） |
|---|---|---|---|
| 通信速度 下り/上り | 7.2Mbps/5.8Mbps | 7.2Mbps/5.8Mbps | 40Mbps/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くらいです。
- 移動中（自宅〜東久留米間）
- 電車に乗っている間は全く切れず。速度は測っていませんが電波シグナルは最大を示していました。
結論
- 回線速度的には、僕が家で使う用途には全く問題ありませんでした。
- オンラインゲームなどで激しく使う場合は物足りないかも知れませんが
- 固定回線のBフレッツは解約し、しばらくUQWiMAX一本で行こうと思っています。
- もっとスペックのいい端末がでたり、ドコモが本気出してきたら乗り換るかもです。
Solr勉強会に参加してきました
最近導入事例が増えてきて注目度が高まっている（気がする）Apache Solrという全文検索エンジンがあります。前職では導入していたのですがあまりよく分かっていなかったので、ちゃんと勉強してみようと第3回Solr勉強会というのに参加してみました。すごく面白かったので忘れないうちにメモメモしときます。
メモの量が偏ってるのは最初の方の発表ほどちゃんとメモしていたためです。後の発表もとても面白かったですよー。
勉強会のアジェンダはこちら http://atnd.org/events/4980
ロンウイット 関口さん
遅刻してしまいほとんど聞けず残念。
サイバーエージェント 田代さん アメブロの検索にSolr1.4を使った話
- アメーバは元々Javaで書かれたサービス＝＞Luceneを結構使っていた
- Solr1.4に移行する前のパフォーマンス
- データ量6000万件（直近3〜6ヶ月のデータだけしか保持できない）
- スケールしにくい作り
- QPS（秒間あたりクエリ数）50くらい
- しょっちゅう検索不能になる＝＞社長に怒られたｗ
- Solrの分散検索とレプリケーション機能を使いたくてスイッチ
- インフラ構成
- Solr1.4移行後のパフォーマンス
- クエリ数 350万〜450万 / day
- QPS 85〜100 =>まだまだ出そう
- レスポンス速度 平均30ms
- 移行後に扱っているデータ量
- 随時検索用 - 2億記事 20shards
- アメーバIDでの検索用 - 4億記事 59shards
- データの増加量 70万記事/day
- 1shardあたりのデータ量 11〜15GB（6000〜9000万記事）
- インデックスの更新頻度
- 4分に1度
- 日本語解析アルゴリズム
- 苦労したこと
- 転送速度（Master<->Slaveのこと？？）
- AutoWarming？で落ちた
感想：こんなにノウハウを惜しみなく公開していいのか！と思うほど素晴らしい内容でした。プレゼン資料公開して欲しいです！
サイバーエージェント 安田さん アメーバなう検索について
- Solr1.4.1
- ドキュメント量 3500万（2ヶ月しか保持しない）
- データサイズ 4.5GB
- 反映時間は速い（リアルタイム検索しないといけないから）
- 1〜10secでインデックス更新
- パーティション 12shards
- IDの剰余によるハッシュと時間レンジ
- ストアデータの保持に工夫をしている
- 死活監視
- LBHttpSolrServerを参考に自作
- shardは冗長化
- 日本語解析ロジック
- SenTokenizer -> EgdeNgramFilter -> StopFilter
- 誤検知は1%位は発生する
- レプリケーションのノウハウ
- MasterはIOが多く発生する
- Slaveはメモリをたくさん積む（空きメモリ>1shardのデータサイズ）
感想：こちらもノウハウ満載なプレゼン。ちょうどMessagePackについて調べていたので興味津々
追記：LuceneインデックスのMessagePackで圧縮の元記事はこちらですね。 LuceneのインデックスにStoreするデータをMessagePackで圧縮してみた
マピオン 岩澤さん 前に失敗したSolr1.4化を達成した話
- Mapionの場合、Solrのキャッシュ機構を使うとFullGC連発
- IO-Drive？を使うとイイよって言われたけど駄目だった
- OSにSolarisを使っていたのでZFSのキャッシュ機構をフルに活用
- ZFSのキャッシュ上限は空きメモリの範囲にしておいたほうがいい
- 地道なチューニングでレスポンス速度はSolr1.3の時の20倍以上に高速化
- レスポンス数
- 1000万クエリ / day
- 最大400クエリ / sec
- これを4台のSolrで捌く
- 1.3の時は16台必要だった
- 京都府問題
疑問点：マージ用Solrっていったいなんだろう？
補遺：SolrのキャッシュについてTwitterで以下のようなフォローが岩澤さんご本人から
"これは一情報＋キーワードで同じクエリが少ないことが多いマピオン独特の場合だと思います。他のユーザさんは使ったほうが断然イイみたいですよ。 " http://twitter.com/iwazer/status/18111512921
チームラボ田村さん キーワードレスサーチについて
- ユーザーは受動的に情報を取得したい
- キーワードとか最初に分からない場合が多い
- 文字情報以外も検索したい
- ＝＞キーワードレスサーチ
- ジクレポ
- コレカモ
- イメージ検索
- 画像をopenCVで解析し、色や形などの特徴情報を抽出
- 抽出した情報を数値として保存してしまう
- 商品の詳細説明文と検索をかけたり
感想：イメージ検索こうやって実装できるんだーと目からウロコ。
LT
- Basis Technology 黒坂さん「Lucid Imagination 最新動向 (仮題)」
- ECナビ春山さん Solrを動かすTomcatにメモリを割り当て過ぎたら死んだ話
- 24GB以上のメモリ割り当てちゃいかんよと
iPadがBuffaroのWiFiアクセスポイントにつながらなかった時のメモ
5/31 追記 結構PVがあるのでググったら、やっぱり同じ問題の人が多そうで、機器のファームウェア更新で解決するみたいです。参考 - こことかこことか
iPadをBuffaroのWZR2-G300Nという機器で構築しているWiFiネットワークに接続しようとしたら、どうにも動かなかったので対処した時のメモ。正直ネットワークには疎く、意味不明な記述があるかも知れませんが、もしかして同じ機器を使っている人がいたら役に立つかもと思い、一応記事にしておきます。
結果的にはファームウェアアップデートで解決しました。
iPadのネットワーク設定
DHCPサーバーから割り当てられるIPアドレスが「169.254.***.***」（詳細は忘れました。）のようになっていて、明らかにプライベートネットワークのIPアドレスではない。同じWiFiにつないでいるMacBookとiPhoneは、それぞれ192.168.1.2と1.3が割り当てられていて正常に動作しているのでDHCPサーバーの不調では無さそう。
ネットワーク構成
WiFiのアクセスポイントにはBuffaroのWZR2-G300Nという機器を使っている。DHCPサーバーとしての機能はNTTから借りてるルーターに任せていて、WZR2-G300Nはブリッジモード（WiFiのアクセスポイントとしてのみの機能）で動作させている。
障害の状況
WZR2-G300NにはDHCPサーバーから192.168.1.4が割り当てられていたので、iPadから192.168.1.4にアクセスしてみると繋がらない。ルーター、アクセスポイント、iPadの再起動をしても解決せず、同じIPアドレスが割り当てられ続ける。iPadのネットワーク接続を削除しても同じ。
解決編
WZR2-G300Nのファームウェアのバグが疑われたので、アップデータを探すとやっぱりあった。
ドライバーダウンロード WZR2-G300Nシリーズ | BUFFALO バッファロー
バージョンアップ内容を読むと「特定の無線LAN子機と接続出来ないことがあるのを解決」という件があるのでどうもこれっぽいなと思い、ファームウェアアップデートをしたらあっけなく解決ー。
