Facebook の可能性と fb phone の必然性
google がどれだけ世界を変えたかを考え、次に世の情報や価値はパブリックな領域とプライベートな領域に分散する事を思い浮かべた時、fb の価値が見える気がする。
プライベートな領域にアクセスするには Social Graph が極めて有効な手段なのだ。
プライベートな領域はまだ未開拓で、かつ開拓されたパブリックな領域よりも豊かな可能性を秘めている。
Facebook phone については色んな角度から見る事が出来ると思うけど、ここはひとつ Social Graph の観点から眺めてみたい。
今の Social Graph 形成はとても貧弱で、fb phone はそれを次のパラダイムに押し上げる可能性がある。
fb の friend suggestion は結構優秀＆便利で、Social Graph の形成手段というのは本来ああいったマシンによる整理＋ユーザコントロールの形を取るべきだ。
人間の時間、アテンションは世の中で最も貴重な資源だし、Social Graph はもっと "影" に沿うと価値が上がる。
今の iPhone が果たしている日常の役割、利便性と fb の機能性、Social Graph を考え合わせるとめちゃめちゃ相性が良い、、iPhone を覆せるとしたら fb phone だろう、というのは置いておいて。
fb phone のような SNS サービスと連動したエージェントの利点はシャドウデータを取れる事だ。
知り合った人を fb で探すのではなく、GPS や議事録アプリのようなアクティビティのメタデータからあるタイミングで "you may know.." とエージェントが提示してくれるようになる。
日常を密接に支えるユーザの一部であるエージェントだからこそ、ユーザのコンテキストを察知する事が出来て、従って Social Graph の自動分類も可能になる。
（人々をどうクラスタリングするか、というのは SN Provider にとって極めて重要な箇所だ）
"my gf" のタグを付けていればディズニーランドで撮った写真は自動共有されるハズ。
通貨革命やグルーポンの次を行くサービスなど、その上で構築出来るリアル（! ゲーム）なソーシャルアプリケーションの可能性も期待出来るのでは。
fb phone はリアルな Social Graph をもっと豊かに構築する手段であり、私たちの生活を変えちゃう可能性のあるソリューションだ。
（と同時に fb を抜きん出た存在に上げ、そのレイヤに於いて fb 以外の選択肢を駆逐する手段になるのかもね）
欠点があるとすれば中央集権的なデータ構造と fb の信頼されなさ、傲慢さ、、
理想論だと思うけど、人は利便性に惹かれて釣られちゃうものだと思うけど、データは端末に閉じて存在し暗号化されてユーザの許可があって初めてアンロックされるべきだと思うんだ。
この辺のアーキテクチャ、構造って社会性や人類社会の発展方向を決める重要な部分だと思うよ。
fb なぁ、、
AppleScript 覚え書き
TextMate, QuickSilver を使っていると AppleScript が欠かせないものになってくる。
今まで見よう見まねで AppleScript を使っていたけど思うようにいかない、、のでリファレンスに目を通してみた。
メインはコードと一緒に gist に、gist に書けなかった覚え書きをここにメモ。
学び終えた今は MacRuby 頑張れ！！の気持ちでいっぱいです。
AppleScript is an object-oriented language. An object is an instantiation of a class definition, which can include properties and actions. "script" is the top-level object, which is the overall script we are working in.
自然言語的な見かけを持てるよう設計された言語で、面白いけどとっつき悪いように思う。
-- オブジェクトのプロパティを of で辿る。 as integer でキャスト (coercion) -- log や say は utf-8 クラスが扱えないので注意 log(size of first file of window 1 of application "Finder" as integer)
handler、所謂関数の定義は
-- 普通ぽい形 -- AS っぽい事をしたい人は log に代えて say を使うとか on rock(clock) log (clock as text) end rock rock(current date) -- こうも書ける on rock around clock log (clock as text) end rock -- 呼び出し側も変わる。() では呼べない。 rock around current date -- optional に the も使える on rock around the clock log (clock as text) end rock -- こちらの the も省略可能 rock around the current date
更に
-- labeled parameters
to findNumbers of numberList above minLimit given rounding:roundBoolean
end findNumbers
-- call
findNumbers of myList above 19 given rounding:true
-- もしくは
findNumbers of {5.1, 20.1, 20.5, 33} above 20 with rounding
findNumbers of {5.1, 20.1, 20.5, 33.7} above 20 without rounding
-- patterned positional parameters
on hl({x,y})
log x * y
end hl
hl({10, 20})シェルスクリプト実行
-- シェルスクリプト実行 log (do shell script "cd ~; ls") -- Technical Note TN2065, do shell script in AppleScript. -- http://developer.apple.com/mac/library/technotes/tn2002/tn2065.html
tell について、ScriptEditor にて次を実行する
log name of window 1 as text tell application "Finder" log name of window 1 as text end tell log name of window 1 of application "Finder" as text
どのオブジェクトにメッセージ送信されるかにより結果が変わっている。
... of me や my ... でステートメント単位でコントロール出来る。 tell を使うとブロック内を括れる。
tell の外部と内部ではスコープが異なるので外部で定義されているハンドラの参照には my や of me が必要 (me はスクリプト自体を指す)
tell application "Finder" my fn(name of window 1) end tell on fn(x) log x & "!!!" end fn
シェルから AppleScript を使う
#!/usr/bin/osascript
osascript -e 'tell app "Address Book" to get the name of every person' | perl -pe 's/, /\n/g' | sort | uniq
Interface Builder を一発で呼び出す QS 用 AppleScript
キーストローク1発で任意のアプリケーションにスイッチし、かつ全ウィンドウを前面に持ってくる QS Action 用の AppleScript を書きました。
てか Interface Builder 用です。
QS の Action に登録後、QS -> . -> Interface Builder とタイプ -> Action で当該スクリプトを呼び出す、として使います。
QS のトリガは便利なのですが、複数のウィンドウを持つアプリケーションでは他のウィンドウが前面に出てこない事があり、AppleScript で何とかしました。
何故か Text で Application 指定していますが、パクり元サンプルが text を使っておりそのまま作ったら動いたので放置しとります。
Application を渡した方がキレイだと思うので誰かりファクタリングしてください。
menu 操作が便利だったのでコードを残していますが、activate しただけで Bring All to Front っぽい動作になっていたような気も、、、
動いている＆自分が満足で今はいじる気が無いので晒しておきます。
mongoid 2.0.0.beta.6 で遊ぶ
MongoId 可愛いよ、MongoId。
mongo 標準のシェルに潜るより r c してコンソールから叩く方が楽なので困る（嬉しい意味で）。
以前はこう出来たのが
where(:price => {'$gt' => 0})
今はこう
where(:price.gt => 0})
また exclude, not_in のような見慣れないメソッドがあった。
使っていないので見落としていただけかも。
bson のデータ型に対する厳格さが増したかも知れない。
以前は $gt => 0 で取れたのが取れなくなっている。
# これはもうダメ、nil が返る Entry.first(:conditions=>{:published_at => {'$gt' => 0}}) # こうする Entry.first(:conditions => {:published_at => nil}) => #<Entry _id: 4befcdc10482931424000006, .. # 逆の場合は Entry.first(:conditions => {:published_at.ne => nil}) => #<Entry _id: 4befcdc104829314240000… # 値指定なら Entry.first(:conditions => {:published_at.gt => 2.years.ago.utc}) => #<Entry _id: 4befcdc10482931424000001, …
MongoId はよく出来ていると思う。
インタフェースのクセが AR2 時代のそれなので AR3 の cool さを見てしまうとちょっと寂しいけど。
機能的には満足しておりますです。
Ruby/AppleEvent ブリッジの覚え書き
AppleScript っぽい事を ruby で、な環境を一通り調べてみた。
rb-applescript
今はこれが現役、Ruby だけでなく python, Objective-C のバインディングがある。
ところが困った事に、クリップボードにアクセスしようとすると osax が 64bit ruby で動かないようだ。
dynamically retrieve scripting addition terminology within a 64-bit process
と言われる。
RubyOSA
既に開発中止らしい。けど中身はそれほど悪くない。個人的には好き。
- GEM 版はコンパイルエラーでインストールに失敗する
- port 版は rdoc-osa コマンドが古いのでお勧め出来ない
ではどうするかというと、github にある Snow Leopard 対応版を使う。
gem install pbosetti-rubyosa
で、、クリップボードにアクセスする方法を探しまわったが見つからずに断念。
クリップボードが扱えない件
さくさく ruby でスクリプティングなら rb-appscript でも RubyOSA でも役割は果たせる。
問題はクリップボードですよ。
ペースト操作だけなら AppleScript の
tell application "System Events" to keystroke "v" using command down
これを
sys = OSA.app 'System Events' sys.keystroke 'v', OSA::SystemEvents::EMDS::COMMAND_DOWN
と同等の事が出来るが、クリップボードに書き戻す手段が無い。
pbcopy/pbpaste を試したがコマンド経由だとマルチバイト文字が扱えない。
マルチバイトを有効にした terminal app を activate して実行する方法があるものの、スマートでない＆ウィンドウが一枚立ち上がったりするので諦めた。
ruby-cocoa だと上手く行くが、こちらは力量不足で NSString オブジェクトと ruby の String を相互変換する方法が分からなかった。
という事でクリップボードは諦めて osax のアップデート待ち中。
ソースコードから自分でコンパイルすれば良いような気もする。
QuickSilver と組み合わせてクリップボードフィルタを作りたかったのだけど、今回は諦めた。
日本語が絡まなければ目的は達成、、うーむ。
オープンソースの検索エンジン Sphinx について調べたメモ
注意点としては
- 日本語は UTF-8 一択
- 検索対象 DB も UTF-8 だと楽
- Ngram のみ
- インデックスの部分的な更新に難あり
- blog, ニュース, フォーラムといった蓄積型のコンテンツには良い
- 更新柔軟性よりパフォーマンスやスケールを取っている
- 今後、別方式のインデックスを実装するプランはある
ライセンスは GPL v2 or 商用（embeded 用）
概要
ドキュメント を読んだメモ。
検索
document は複数の field を持ち、また検索用メタ情報である attribute を持つ。
field は検索に用いられる index 対象となるフィールドであり、Sphinx はこのフィールドを複数個持てる（デフォで上限32個？）
attribute はソートや、グルーピング、検索結果の絞り込みに使われる。詳細は 3.2 Attributes 参照。
検索モード
マッチングモード（ドキュメントの実例を見た方が早い）
- ALL: 全てを含む（デフォルト）
- ANY: いずれかを含む
- PHRASE: クエリをフレーズと見なす、perfect match（語順等）
- BOOLEAN: and, or, not, grouping 演算子が使える
- EXTENDED2: internal query。 @* hello 等
- FULL_SCAN:
以下は読み飛ばした。こんな機能もあるよ、程度に列挙
- weighting, sorting mode, grouping (clustering)
- distributed searching
- multi-server, multi-cpu, multi-core
- 水平分割して割り振る
インデックス
- 現在は"高速で、更新コストが極めて高い"タイプのインデックスのみ利用可能
- 将来的に、検索速度の代わりに更新に利便性のあるインデックスなど、インデックスタイプを選択できる予定らしい
live update は極めてコストが高く、構築し直しとさほど変わりない。
代案としてインデックスを分割する方法がある。
- 更新頻度の高いインデックス
- ほぼ不変のインデックス
と二つに分けて、更新コストや影響を区切る。
詳細は 3.10. Live index updates にある。
また index の統合については 3.11. index merging にある。
例にある SQL では初回インデックス生成時 (main) の MAX(id) をカウンタテーブルに保存しておき、それ以降のデータソース/インデックスは delta として扱うような内容になっている。
- インデックスを分割した際のデメリットやパフォーマンスの低下については未発見。
- 例にあるように今までの投稿 + 新しい投稿といった足し込んでいけるものは main+delta に index merging を使って対処出来そうだが、全体に更新がかかるようなものはどうするのが良いか不明
- 実は例示が極端なだけで、データ量が少なければインデックスを再生成しまくれるのかも知れない。
データソース
Sphinx が検索対象とするデータ、または検索インデックスを作成する元データをデータソースという。
Sphinx がデータソースにアクセスするためのコードをデータドライバという。
データソースの制限
- ドキュメントID必須、ID は一意であり、unsigned non-zero integer numbers である事
- 32bit or 64bit は build time setting で指定
Sphinx のデータドライバは
- sql driver
- xmlpipe
sql driver には ranged query 機能があり、1,000 件単位で処理する等して、ロックとメモリ消費を現実的な範囲に落とす事が出来る。
データソース生成時には文字変換テーブルが使える
- インデックス作成時に charset table を参照し、データソースの変換を行う。
- 例えば Abc, abc, ABC は検索語、データソースがいずれであってもヒット可能となる。
- English & Russian しかないので、おまいらの書いた変換テーブルがあればコミットしてね！との事。
MySQL protocol & SphinQL
SELECT * FROM test1 WHERE MATCH('test');
etc
filter
- 例: ENG で検索した後、model=3 に絞る
- 値の複数指定は可能
- 範囲指定可能
$ /usr/local/bin/search \
--config /usr/local/etc/sphinx.conf --filter model 3 ENG
index 'catalog': query 'ENG ': returned 1 matches of 1 total in 0.000 sec
displaying matches:
1. document=9, weight=1, assembly=5, model=3
id=9
partno=ENG976
description=Large cylinder head
price=65
words:
1. 'eng': 2 documents, 2 hits
全文検索について簡単に調べたメモ
さっくり調べる。
概要を知る
読む
メモ
- 形態素解析:
- 辞書品質により検索落ちも
- N-Gram:
- ノイズ: 京都 -> 東京都庁
- インデックスサイズ肥大化
- 評価指標
- recall (再現率): 検索漏れの少なさ
- precision (適合率): 検索ノイズの少なさ
- recall と precision はトレードオフ
日本語縛りなら形態素解析 ?
- Ngram の利点は言語選ばず適用可能なこと
- 但し原理的に精度が形態素解析に及ばない
- 検索抜けを回避したい等の明確な理由により検討余地あり
- 日本語は特殊処理を要する傾向がある
形態素解析の欠点
- 処理時間
- 辞書の分割単位と検索漏れ
- 辞書:マカデミアナッツ クエリ:ナッツ でノーヒット
ソリューション
Solr
groonga
Sphinx
（抜粋＆並び替え）
http://www.sphinxsearch.com/about.html
..Sphinx was specially designed to integrate well with SQL databases .. built-in data sources support fetching data either via direct connection to MySQL or PostgreSQL, or using XML pipe
..supports MySQL natively (MyISAM and InnoDB tables are both supported)
..distributed under GPL version 2. Commercial license is also available for embedded use.
疑問
2008 年の記事
Sphinx はインストールや維持管理が容易であり、また非常に高機能です。しかも Sphinx の最近のリリースでは、ネイティブの MySQL エンジンを提供しており、Sphinx デーモンを別途実行する必要がありません。
http://www.ibm.com/developerworks/jp/opensource/library/os-php-apachesolr
Sphinx は時間と共に改善が続けられており、ショッピング・サイトやブログ、その他数多くのアプリケーションに理想的なものになっています。Sphinx のサイトによれば、1 つのアプリケーションが今や 7 億の文書、または約 1.2 テラバイトのデータを索引付けすることができます。私は迷わず Sphinx をお薦めします。
しかし Sphinx は、アプリケーションやサイトの人気が高まり、利用数が増えるにつれて求められる、あるいは提供が必要となる、いくつかの機能をまだサポートしていません。
特に、Sphinx はまだ索引を自動的に複製したり配布したりする機能がないため、Sphinx のデーモンが単一障害点になっています。
(この回避策として、数台のマシンが同じデータベースに索引を付けるようにし、そうしたシステムをクラスター化する方法があります。)
Sphinx は (Google がキャッシュしたページを表示する際に強調するように) 検索結果を強調表示することはなく、最近の検索結果を保持したりキャッシュしたりすることはなく、また正規表現 (regex) も日付に基づく操作もサポートしていません。
実践 MySQL パフォーマンス第二版 付録C
C.1 概要：一般的なSphinx検索
C.2 Sphinxを使用する理由
C.2.1 効率的でスケーラブルな全文検索
C.2.2 WHERE句の効率的な適用
C.2.3 結果を上位のものから順に検索する
C.2.4 GROUP BYクエリの最適化
C.2.5 結果セットの並行生成
C.2.6 スケーリング
C.2.7 シャードデータの集計
C.3 アーキテクチャの概要
C.3.1 インストールの概要
C.3.2 パーティションの一般的な用途
C.4 特別な機能
C.4.1 フレーズ近傍ランキング
C.4.2 属性のサポート
C.4.3 フィルタリング
C.4.4 SphinxSEストレージエンジン
C.4.5 高度なパフォーマンス制御
C.5 実装の実例
C.5.1 Mininova.orgの全文検索
C.5.2 BoardReader.comでの全文検索
C.5.3 Sahibinden.comでの選択の最適化
C.5.4 BoardReader.comでのGROUP BYの最適化
C.5.5 Grouply.comでのシャードJOINクエリの最適化
C.6 まとめ
MySQL 周りのお話
MySQL 5.0
http://www.mysql.gr.jp/frame/modules/bwiki/index.php?plugin=attach&refer=matsunobu&openfile=MySQL_perf.pdf
– Tritonn/Senna
• 住商情報システムと未来検索ブラジルによるサポート提供
• 最も実績がある
MySQL 5.1以降
– Sphinx
• http://www.sphinxsearch.com/
• MySQLのストレージエンジンとして動作し、UTF-8であればBi-gram方式に より、日本語の全文検索が可能
• 分散検索エンジン。非常に高速
• Craigslistなど、海外の大規模サイトでの実績が多数
• 利用方法がやや特殊
– FulltextParserPlugin
• http://mysqlftppc.wiki.sourceforge.net/Home-j
– mroonga/groonga
• Sennaの後継にあたる。現在開発中
MongoDB の検索ストラテジちょこっと
- http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo
- http://www.businessinsider.com/how-we-use-mongodb-2009-11
