スポンサーサイト

--年--月--日 --:--

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

DevQuizのしりとりを可視化

2010年08月25日 00:54

Google Developer Days の Dev Quiz のしりとりを解くために可視化を試みた。実際にはツールを作るために性質を調べているうちに解けてしまったので使っていないのだけど・・・。

利用したツールは大好きなCytoscape Webです。


しりとり3:(←拡大縮小できます)

スクリーンショット(2010-08-25 1.02.05)

この、下のマリモの中に先に押し込まれた方が負け。


# 1と2も全然構造が違って味わい深い。


しりとり1:

スクリーンショット(2010-08-25 1.12.35)

しりとり2:
スクリーンショット(2010-08-25 1.12.59)

おわり。
スポンサーサイト

Soramegraph:深く検索する機能

2010年08月01日 04:47

Soramegraph(説明)にグラフのを少しずつ深く検索する機能を追加しました。
「ウナギ」から始めた深さ3の空目グラフです。

スクリーンショット(2010-08-01 3.56.59)

利用法:キーワードを変えずに検索ボタンを押すと、深さを1増加させて検索・描画します。
スクリーンショット(2010-08-01 4.39.19)


エッジをまとめて表示するようにしないと見辛いかも・・・。

Soramegraph

2010年07月17日 17:05

Soramegraph


Twitterを眺めていると、「〇〇を××に空目した」というTweetをよく見ることがあります。
Soramegraphは空目Tweetを解析して〇〇→××というグラフとして可視化し、
次のような形でコミュニケーションを豊かにします。

 ・空目し易い単語・され易い単語を把握し、誤解を避けた・あえて誤解を
  狙ったコミュニケーションをする。
 ・空目Tweetを俯瞰することで、自分と感性が近い人を発見し、見守る。

【使い方】
三つのことしかできません。
・キーワード検索を実行すると、リアルタイムTweeter検索結果と、蓄積データから
 生成されたグラフを表示します。
・グラフの矢印をクリックすると、対応するTweetが画面上部に表示されます。
・グラフの頂点をクリックすると、グラフのラベルとして表示されている単語で
 キーワード検索が実行されます。

【利用ツール】
Cytoscape Web
Google App Engine
Twiiter4J

【中身】
空目の分解は、特に学習などしておりません。まだまだ、誤認識は結構多いです。

【傾向】
空目の元となる単語はバズっている単語が多く、空目の先となる単語は下ネタ系である傾向が顕著です。

【サンプル】
上下のポストをごらんください。
ブブゼラの空目されっぷり
ブブゼラの空目されっぷり2


【その他】
ご意見、ご指摘などございましたらコメントください。よろしくおねがいいたします。

【追記】
Baidu「不自然言語処理コンテスト」でグランプリを頂きました。
【受賞作品発表】不自然言語処理コンテスト開催報告~ほんとにやったよスイカ割り~
Baiduの皆様、審査員の皆様ありがとうございました。また他の方の発表(技術、アイデア共に)も非常に勉強になりました。あの場で培った知識を何かに生かしたい・・・。

ペンローズのインタビュー

2010年05月28日 02:07

ペンローズネタの復習

いまの子供はアインシュタインロマンが始まるまでテレビの前で待つのではなく、Youtubeを検索すればこんなのみられるわけだ。その代わり英語は必要か。子供に英語は教えないと・・・どうやって?。


・ペンローズのインタビュー


・ホーキング放射


・あとはあんまり関係ないけど、LHCをラップで紹介している動画。

Introducing FlockDB(2)

2010年05月12日 03:09

Introducing FlockDBの続きを訳しながらメモ。
 前半→Introducing FlockDB (1)

「教訓」で述べられていることは参考になる。特に正常系とエラー系で同じパスを通るようにする、というのは応用出来そうなアイデア。


(続き)

書き込み処理はシステムに入力された時刻に対して冪等で可換である。
我々は操作の実行の順序によらず同じ結果を得ることができる。
故に我々は一時的なネットワークやハードウェアの故障を隠すことができ、
時間がったったあとに再実行することができる。特にこれは初期の展開に
効果的である。

可換な書き込みは新しいパーティションを育成するプロセスを単純化する。
新しいパーティションは書き込みトラフィックを即座に受け入れることができ、
同時に古いパーティションからのデータのダンプをゆっくりと背後で
受け取ることができる。ダンプが一度終わると。パーティションはすぐに
"live"かつ読み取り可能になる。

アプリケーションサーバ("flapps"という愛称)はScalaで書かれていて
ステートレスで水平にスケーラブルである。クエリの負荷が増加してきたら
データベースとは独立してアプリケーションサーバを追加することができる。
それらは非常に小さいthrift APIをクライアントに向けて公開していて、
もっとリッチなインターフェースのためにクライアントはRubyで書いている。

我々はGizzard Libraryを使ってパーティショニングレイヤーを管理している。
フォワーディングレイヤーはsource IDの範囲から物理データベースへのマッピング
を定義し、レプリケーションを同じフォワーディングアドレスに対してそのような
テーブルをツリー状に構築する事によって管理される。書き込み操作はローカルに
ジャーナリングされたあとに認識される。データベースの可用性やパフォーマンスは
Webサイトのレスポンスタイムとは分離される。

それぞれのエッジは二回保存される。ひとつは前向き(ソースIDでインデックスが
つけられ、パーティショニングされる)で、もうひとつは後ろ向き(宛先IDでインデックス
がつけられ、パーティショニングされる)である。「だれが私をフォローしているか?」
のようなクエリが「私がフォローしているのはだれ?」と同じように効率的で、
どちらも必ず同じ単一パーティションで結果を得ることができる。

最終的な結果は必要に応じて拡張できるコモディティサーバのクラスタになった。
冬の間に、我々は誰にも気づかれずに50%ほどデータベースを拡張した。
我々は現在130憶の園児を保存していており、ピークのトラフィックは
秒間2万回の書き込みと10万回の読み込みを維持している。

教訓

もとのゴールとは違うにせよ、いくつかの有用なパターンが我々の経験のあとに残った。:

・ロングテールをカットオフするために積極的なタイムアウトせよ。
あなたはシステムの不公平さを完全にふるい落とすことはできないだろう、例えば
99.9パーセンタイルにあたる問い合わせが非合理に長く待たされるなど。もし複数の
ステートレスなアプリケーションサーバがあったら、あなたは合理的な時間が経った
クライアントを切断し、別のアプリケーションサーバを試す機会を与えることができる。
・すべてのケースをエラーケースとせよ。
または、別の言い方をするとエラーでも通常動作と同じコードのパスを使うようにせよ。
非常事態のみに使われるあまりテストされていないモジュールを作っては
いけない。少なくとも新しいことに挑戦するような感覚になる。我々は
すべての書き込み操作をローカルにキューに入れている(Kestrelをライブラリとして
使っている)、そしてそれらが失敗すれば分離されたエラーキューに投げられる。
このエラーキューは書き込みキューに周期的にフラッシュバックされ、つまり
リトライは最初の実行時と同じコードのパスを通る。
・はじめのうちは何も無意識に実行するな。
たくさんの計器やレバーを与え、一度現れたパターンはスクリプトによる自動化する。
FlockDBはそれぞれの異なったサービス(MySQLやKestrelやThrift)に対するクエリの
レイテンシの分散を測定しタイムアウトの時間を調整することができ、それぞれの
操作のカウントをレポートする、我々はクライアントライブラリがクエリのロードを
突然二倍にしたりするのを見ることがある(または、さらなるハードウェアの追加が)。
手動インスペクションのためになんどもエラーキューを循環している書き込み操作は
ログにダンプされる。バグが発覚することがあれば、それを直して、ジョブを再投入
し、クライアントのエラーであればそれはよいバグレポートとなる。

以上。

(だんだん後半の訳がひどくなってるが・・。)



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。