タグ

ブックマーク / llamerada.hatenadiary.org (16)

  • Googleの分散データ処理言語Sawzallの統計ライブラリをC++, Ruby, Pythonから利用するライブラリSZaruを公開しました - llameradaの日記

    Googleで利用されている分散データ処理言語SawzallのOSS実装 szl が公開されました。 公開されたソースの中にはSawzallの実行環境の他に大規模データ向けの統計ライブラリが含まれています。この統計ライブラリには高度なアルゴリズムが実装されているので、これを他の言語からも利用できると便利だなと思い、C++, Ruby, Pythonから利用できるようにしました。 便利な統計アルゴリズムの1つに出現回数が上位のN件の要素の抽出(top-N)があります。 top-Nを求める具体例としては、自然言語処理でよく使う、出現回数上位の単語を求める処理があります。この処理の単純な実装では、まず全単語の出現回数を求めておき、次に各単語を出現回数の降順でソートして出現回数上位の単語を求めます。しかし、この実装ではユニークな単語数K(数十万から数百万)に比例したメモリと計算量が必要となります。

    Googleの分散データ処理言語Sawzallの統計ライブラリをC++, Ruby, Pythonから利用するライブラリSZaruを公開しました - llameradaの日記
  • レコメンド(推薦)・サービスに一番大切なこと - llameradaの日記

    flickrの写真をクリック履歴から自動的に推薦するサービス「フォト見る」を数日前にリリースしました。さいわい、気に入って頂いた方もいるようです(Route 477(2009-03-12))。「フォト見る」をリリースしてみて思ったのですが、レコメンド(推薦)を軸としたサービスでは初心者ユーザにいかに使ってもらえるかが一番大切だなと思いました。 ユーザに何かを推薦するには、当たり前ですが、そのユーザの好みを知っている必要があります。例えば、「フォト見る」では、ユーザが過去にクリックした写真から好みを推定しています。ところが、初めてページを訪れたユーザの好みは全く分かりません。1つでも写真をクリックしてくれれば、ユーザの好みが少しでも分かります。ところが、ユーザの好みが分からない状態では推薦は無理なので、初めてのユーザに対してはどうでもよい写真が表示されやすく、写真をクリックしてもらうのがなか

    レコメンド(推薦)・サービスに一番大切なこと - llameradaの日記
    yuiseki
    yuiseki 2009/03/22
  • Key Value Store勉強会に参加してきた - llameradaの日記

    とても楽しかった。ミドルウェア系の勉強会が一番自分の関心に近いみたい。印象に残ったことを何点か。 Masterがあるタイプの分散ソフトウェアで、障害時のMaster選択に苦労した話を聞いて、Chubbyが便利な理由が改めてよくわかった。 Key Value Store だとランダム・リードが主なユースケースなので分散ハッシュのアプローチが有効みたいで、分散システム系はだいたいそうだった。全文検索みたいなユースケースだとシーケンシャル・リードが大事なので、BigTableのようなB-Treeのアプローチの方が有効だが、そのあたりはあまり開拓されていないみたい。 TokyoCabinetを最下層のストレージに使っているケースが多かった。

    Key Value Store勉強会に参加してきた - llameradaの日記
    yuiseki
    yuiseki 2009/02/23
  • TinySegmenterをRubyに移植 - llameradaの日記

    Javascriptだけで書かれたコンパクトな分かち書きソフトウェアであるTinySegmenterをRubyに移植しました。移植してから別実装があるのに気がつきましたが、気にせず公開することにします。 Codereposにアップしてありますので、下記のURLよりダウンロードできます。 http://svn.coderepos.org/share/lang/ruby/ruby_tiny_segmenter/ MeCabに対するTinySegmenterの利点は、Ruby だけで書かれているので、どんな環境でも簡単に動作する点です。インストールも簡単です。Windows環境でMeCabをRubyから扱うのは少し面倒ですが、TinySegmenterならば殆んど問題ありません。 実行例はこんな感じです。 require "tiny_segmenter" words = TinySegmente

    TinySegmenterをRubyに移植 - llameradaの日記
    yuiseki
    yuiseki 2008/12/25
    おおおお
  • llameradaの日記 - Ruby on Railsによるソーシャル・ブックマーク管理デスクトップ・アプリケーション

    Ruby on Railsで作成したweb アプリケーションは、exe形式の実行ファイルにすることが出来る。詳しくは、Distributing Rails Applications - A Tutorialを参照のこと。 この仕組みを知って、何か面白いことが出来ないかなと考えていた。そこで、前から欲しかったソーシャル・ブックマーク管理デスクトップ・アプリケーションを作った。現在のところ、del.icio.usとはてなブックマークに対応している。 何故、こんなアプリが欲しかったいうかというと、自分のブックマークを迅速に検索したいからだ。私はソーシャル・ブックマークとしてdel.icio.usを使っているが、del.icio.usのサーバはそれなりに重い。そのため、目的のブックマークを探し出すのに時間がかかってイライラすることがある。 デスクトップ・アプリケーションならば、計算資源に余裕がある

    llameradaの日記 - Ruby on Railsによるソーシャル・ブックマーク管理デスクトップ・アプリケーション
    yuiseki
    yuiseki 2008/06/22
  • TagGridのデータ配置アルゴリズムの簡単な解説 - llameradaの日記

    はじめに TagGridでは16000毎のFlickrの写真を、写真のタグにしたがって格子状に配置しています。この配置アルゴリズムについて簡単に説明したいと思います。 基的なアイデア まず、入力となるのはN個のタグ付きデータとします。また、K種類のタグがあるとします。 TagGridでは、このN個のデータとK種類のタグがそれぞれ平面上に配置されるとします。 データだけでなく、タグも2次元平面上に配置するのが大事な点です。 基的な考え方としては、あるデータのタグが例えばseaとsunの場合、このデータの位置がseaタグと sunタグの近くになるようにデータとタグを配置します。データは複数のタグを持つので、一番良い配置方法というのは簡単には決定できません。そこで、なるだけ良さそうな配置を求めてみます。 フォーマルな問題定義 基的なアイデアを、もう少しフォーマルに定義します。 n番目のデー

    TagGridのデータ配置アルゴリズムの簡単な解説 - llameradaの日記
    yuiseki
    yuiseki 2008/05/24
  • 「なぞり出し」ユーザ・インターフェイスを「気持ちいい」と感じる理由 - llameradaの日記

    はじめに 先日公開したTagGridは比較的好評だったようでAsiajinにもとりあげて頂きました。 Flickr mashup on Google App Engine from Japan – Asiajin TagGridでは、画面全体を埋めつくすように75x75のサムネイル画像を表示しています。1024x768と比較的小さいウィンドウサイズの場合でも、表示される写真の数は70枚くらいになります。 TagGridでは、これらのサムネイル画像を一度に全部表示するのではなく、マウスを移動させるごとに、マウスでなぞった箇所の写真を表示するようにしています。このUIは個人的にもかなり気に入っているのですが、はてなブックマークでのコメントでも「気持ちいい」との評価を頂けているようです。そこで、このUIをなぜ「気持ちいい」と感じるのか理由を考えてみました。 はてなブックマーク - 16000枚の

    「なぞり出し」ユーザ・インターフェイスを「気持ちいい」と感じる理由 - llameradaの日記
    yuiseki
    yuiseki 2008/05/15
  • 16000枚のFlickrの写真を気楽に眺めるためのサービスを作ってみた - llameradaの日記

    はじめに Flickrには綺麗な写真がたくさんありますが、写真を探すには検索キーワードの入力や、それりのクリック操作が必要で、ものぐさな私には少々面倒でした。また、Flickrは日から遠いので、画面切替に時間がかかります。そこで、画面切替とクリック操作のあまりいらない、気楽に写真を探すためのインターフェイスを作ってみました。 http://taggrid.appspot.com/flickr/popular.html スクリーンショットの一部です。 アイデア 基的なアイデアは次の3点です。 16000枚の写真を格子上に配置 Google Maps風のAjaxインターフェイス 似ている写真を近くに配置 1. の16000枚の写真はPopular Tags on Flickr | Flickrを起点にしてFlickr APIを使って取得しました。 2. のAjaxインターフェイスは自分でゴ

    yuiseki
    yuiseki 2008/05/13
    sugoi ryouga
  • Google App Engineから感じるGoogleのメッセージ - llameradaの日記

    Google App Engine]のチュートリアルを試したみた。 pythonは殆んど知らないが、Railsに似たフレームワーク構成になっているので、だいたいなんとかなった。 Google App. Engineの特長をまとめるとこんな感じだろうか。第一印象なので、間違っているところはあると思うが、大筋ははずしていないと思う。 インストールが楽 一瞬で開発環境が整う。インストール後、コンソールでコマンドを叩けば、すぐに開発にかかれる。必要なのはエディタとWebブラウザとアイデアだけ。 デブロイが楽 ローカル環境とサーバ環境の差を意識する必要がない。コマンド一発で、ローカルの開発環境がサーバ環境にアップされる。アプリケーションにバージョン番号があって、古いバージョンに戻せるなど、周辺ツールも整っているみたい。 サービス公開が楽 信頼性(リライアビリティ)や拡張性(スケーラビリティ)を(基

    Google App Engineから感じるGoogleのメッセージ - llameradaの日記
    yuiseki
    yuiseki 2008/04/09
  • UTF-8文字列を圧縮されたUTF-8文字列に変換するライブラリ u-lzss - llameradaの日記

    UTF-8文字列の圧縮ライブラリを作っている。いまさら圧縮ライブラリをなぜ作るのかというと、JavaScriptによる全文検索エンジンで、インデックスの圧縮を行いたいからである。検索結果に概要文を出すには、インデックスが元テキスト全てを含む必要がある。従って、インデックスサイズの肥大化を避けるには、圧縮が必要不可欠である。ところが、次の条件を満たすライブラリを見つけられなかった。 圧縮後のデータがUTF-8文字列 JavaScriptで復元可能 前者の条件が必要なのは、JavaScriptでバイナリが扱えない為、圧縮後のデータがUTF-8文字列である必要がある為である。後者の条件は当たり前であるが、意外に該当するライブラリは少なかった。JavaScriptによるzipの解凍ライブラリは公開されているが、ライセンスが不明であった。 しょうがないので、LZSS符号をベースに、自分でライブラリを

    UTF-8文字列を圧縮されたUTF-8文字列に変換するライブラリ u-lzss - llameradaの日記
    yuiseki
    yuiseki 2007/02/19
  • JavaScriptによる全文検索エンジン - llameradaの日記

    JavaScriptでインデックス型の全文検索エンジンを作ってみた。全文検索エンジンを作る際に問題となるのは、インデックスデータを部分的に読み込む方法である。通常はmmapやpreadなどを使ってファイルの一部を部分的に読み込むのだが、もちろん、ブラウザには使えない。ブラウザでファイルの一部分を読み込むには2通りの方法がある。1つは、ファイルを多数のファイルに分割する方法であり、もう1つはHTTPリクエストのRangeヘッダを利用して、ファイルの一部を取得する方法である。前者の利点は、ブラウザのキャッシュが効くことや、対応ブラウザが多いことである。後者の利点は、ファイル数が少なくなるので、インデックスの管理が容易になることである。今回はRangeヘッダの実用性にも興味があったので、後者の方法を用いた。 参考ページ:最速インターフェース研究会 :: Ajaxを使ったシンプルなチャット 転置イ

    JavaScriptによる全文検索エンジン - llameradaの日記
    yuiseki
    yuiseki 2007/01/24
  • クラスタリング技術を使った「はてなブックマーク」でのお気に入りユーザ数ランキング(簡易ジャンル別) - llameradaの日記

    今度は「はてなブックマーク」の「お気に入り」ネットワークで、ジャンル別のランキングを求めてみました。同じユーザから「お気に入り」されているユーザは、同じジャンルに分類されます。詳細は以前の記事を参照してください。 参考リンク:クラスタリング技術を使ったAmazon DVDでの出演回数ランキング(簡易ジャンル別) - llameradaの日記 結果をみると「はてな」の人々が同じクラスタに分類されたり、サブカル系のブックマークをするユーザがまとまっているなど、そんなに結果は悪くないようです。新たな「お気に入り」を探す手助けになるかもしれません。なお、ユーザ数は今回収集した3647ユーザ中での数になりますので、実際より少なくなります。 追記:深い考えもなしに公開してしまいましたが、人を分類するのは問題が多いです。しかも、クラスタリング技術は基的に大雑把で分類精度はあまり高くないのが普通です。い

    クラスタリング技術を使った「はてなブックマーク」でのお気に入りユーザ数ランキング(簡易ジャンル別) - llameradaの日記
    yuiseki
    yuiseki 2006/05/09
    hoooo
  • イチローのベーコン指数は4次 - Amazon DVD データベースでのスモールワールドネットワーク - llameradaの日記

    ベーコン指数というのをご存知だろうか?まず、俳優ケビン・ベーコンと共演した俳優のベーコン指数を1次とする。そして、ベーコン指数が1次の俳優と共演した俳優のベーコン指数を2次とする。この操作を繰り返して、俳優のベーコン指数を定義する。すると、殆どの俳優(日人やインド人も含めて)が6次以下のベーコン指数を持つ。このような現象をスモール・ワールド現象と呼び、このようなネットワークをスモールワールドネットワークと呼ぶ。いわゆる「世間は狭い」というやつである。 参考:スモール・ワールド現象 - Wikipedia この現象は中々面白いのだが、簡単に体験できるサービスがなかった。ベーコン指数を求めるサービスはあるのだが、ケビン・ベーコンは日人とあまりなじみがない。 そこで、Amazon.co.jpが持つDVDのデータベースを使って、任意の俳優間で、両者をつなげる俳優の共演関係を求めるサービスを作っ

    イチローのベーコン指数は4次 - Amazon DVD データベースでのスモールワールドネットワーク - llameradaの日記
    yuiseki
    yuiseki 2006/05/07
    これはすごい
  • Amzakeが使っている3つのWebサービス - llameradaの日記

    Amzakeで使っているWebサービスを紹介する。なお、Amzakeは次のようなサービスである。まず、ブログ記事などのテキストを入力すると、そのテキストに関連する商品が一覧表示される。そこで、気に入った商品をクリックすることで、商品を紹介するアフィリエイトが作れる。使っているWebサービスは次の3つである。 はてなダイアリーキーワード自動リンクAPI http://developer.yahoo.co.jp/search/web/V1/webSearch.html http://www.amazon.co.jp/exec/obidos/subst/associates/join/webservices.html/250-3683369-0905838 まず、「はてなダイアリーキーワード自動リンクAPI」を利用して、入力テキストのキーワードを抽出する。キーワード抽出は結構難しいタスクなのだが

  • llameradaの日記 - ユーザがページに滞在した時間をサーバに記録するJavaScript

    Ajaxの普及に伴い、ページ当たりのユーザの滞在時間が注目されるようになっている。従来、サービスがユーザに与えるインプレッションの指標としてページ・ビューが広く用いられている。しかし、Ajaxを利用するとページの移動があまり発生しないため、ページ・ビューが低くなってしまう。そこで、インプレッションの指標として、滞在時間を使おうという動きがある。 今回、JavaScriptでユーザの滞在期間が記録できるかどうか調べてみた。取り組む前は難しいかなと思ったが、実際にはとても簡単であった。コードは下記。 (function(){ var start = new Date; window.onunload = function(){ var time = (new Date - start ); var image = new Image; image.src = "/dummy?t=" + tim

    llameradaの日記 - ユーザがページに滞在した時間をサーバに記録するJavaScript
    yuiseki
    yuiseki 2006/03/21
  • 使い捨てWebアプリケーションを作る為の道具としてのRuby on Rails - llameradaの日記

    私のとってRuby on Rails(RoR)は、使い捨てWebアプリケーション(WebApp)を作る為の道具である。ちょうど、Rubyが私にとって使い捨てプログラムを作る為の道具であるように。そして、RoRは使い捨てWebAppを作るのにとても向いている道具だと思う。念の為に言っておくと、別にRoRやRuby格的なアプリケーションに向いていないと主張するつもりはない。単にRoRやRuby格的なアプリケーションを作る機会がないだけである。 何故、RoRが使い捨てWebAppに向くのか?その理由は色々とあるが、一番の理由はやはりAgile(素早い)ということだろう。10分でWebAppが作れるのはやはり魅力的である。 私が使い捨てWebAppを作る目的の大部分は、内部DBのメンテナンス・ツールとしてである。内部DBのメンテナンス・ツールのGUIが欲しいが、ちゃんとしたツールを作るのが

    使い捨てWebアプリケーションを作る為の道具としてのRuby on Rails - llameradaの日記
    yuiseki
    yuiseki 2006/03/14
  • 1