2005年03月30日

さらば、ギガヘルツ

その昔、ケータイコンテンツ黎明期より賑わっていたギガヘルツというコミュニティがあったのですが。
そのドメインはgigahz.netなのですが、先ほどWebにアクセスしてみたら消滅してますた。

gigahz.netはギガコードというMSNコードの前身のサイトがあった所ですが消えてました。
自動的にiアプリ開発者コミュニティも消滅すか。

MLの方はなんもアナウンスなかった気がするけどな・・・・


さらば!

Posted by Yappo at 23:20 | Comments (1) | TrackBack

YappoLabsにてRastを仮採用しました

前回のネタ続きですが、iYappoのクロウラー収集データを含めた情報をRastを用いて検索可能にしてみました。
検索例
いつの間にかLabsは携帯ユーザー含め一般解放してたりするです。
Labsもいくつかの新要素が導入されてますが、説明はそのうち・・・

データ構造は適当に設定したので見栄えが変ですが、既存のlike '%%'な検索より随分と高速になりました。
like検索といっても多段キャッシュ機構をiYappoで持っていたので意外と速かったりしますが。
クロウラーやら運用ポリシーやらを整理しなおしてから正式採用するかどうか決めようかなと思います。

なぜRastなのかというと

  • N-gram
  • サンプルスクリプトが付いてくる
  • チュートリアルが親切
  • APIリファレンスが作れらている
  • 文書属性を自由に設定でき、それらをソート対象に出来る
  • APR
    って所がポイントでした。

    特にN-gramとソートが重要でした。
    なんせ携帯サイトの文章は、わかち書きしにくい、辞書の超整備が必要なのでN-gram必須だったりするのです。
    あとソートなんかは、日付順やTF・IDFなんかよりも独自ランキングのスコアを利用しないと気持ちの良い検索結果にならないので。

    iYappoのメインエンジンをNamazuの超カスタマイズ版にしようかmysql上で実装しようか、QDBM使ってゴリゴリやろうかと、あれこれ悩んでいたのですが、ニーズにマッチした物が公開されて嬉しい限りです。


    Sennaを導入しなかった理由は、
    SennaはMysqlの全文検索機能に置き換える事が出来て、文書属性の要件を満たしそうなのですが、いかんせんMysqlって所に引っ掛かりがあって手を出してないです。
    じゃぁ、単独でAPIたたけよって話しになるのですが、そうなると文書属性がクリアされなそうなのですよ。
    むしろSennaはMysqlと組み合わせることにより真価を発揮すると見ていますが(技術分野以外を含む)
    mysqlにパッチ当てたりしないとmysql上で利用できなかったり、そもそも全文検索専用のデーモン立ち上げなきゃいけないしでややこしいから採用しなかっただけです。
    実績は十分に有るそうなので、ドキュメントが纏まってやる気が出たら手をつけるかも。

    クロウラーもPOEで構築しようと思ったXangoなんつうのもあってビックリですが、Xangoは採用しない方向です。
    もうちょっとシンプルなフレームワーク作って、それに色んな手法を乗っけようかなと。
    それらとは別に、携帯サイトに利用されるURLを良い感じに解析するモジュールとかとか。


    今回はyappodの採用は考えない方向でした。
    あまり下のレイヤに頭使いたくなかったのです。
    yappodなんかも、要件満たしてたりするんですけどねぇ。
    根本的な再設計が必要かと。

    Posted by Yappo at 22:37 | Comments (0) | TrackBack
  • Rastメモ その壱

    Rast
    先月末より公開された、未踏プロジェクトの成果物。
    N-gramな全文検索システムです。

    特徴としては

  • use BerkeleyDB & APR
  • Rast API
  • N-gram
  • 文書の属性値を自由に設定可能
  • ソート対象を独自の属性値に指定可能
  • Rubyバインド
  • 指定したすべての属性値に対しての検索
  • 分散化(対応予定)

    ライブラリ化してあるため、APIを用いて自分好みの検索プログラムを作成できます。
    現在は簡単なサンプル検索システムのコードが付属。
    現在はVer0.0.1で、8月に正式リリース予定。
    BerkeleyDBとAPRを用いているため、現時点でも安定している感じ。

    特にN-gramや、文書属性を自由に設定できてソート対象に出来るなんて所がツボにきました。
    C言語に抵抗がなくてAPRに慣れている人には、良いライブラリかも。

    今のところ、ユニークな属性を設定してしまうと文書を削除しても内部的に削除されないようで、同じ属性値のデータをupdateする事が出来なくなります。
    具体的には、削除フラグをセットしてるだけでdeleteしてないっぽ。

    他にもindex作成中はDBにロックがかかって検索出来なくなるので、いったんDBをコピーしてからindexの更新をしなきゃいけなさそう。
    mknmzなんかは、この辺りを自動的にやってくれてるけど、rastだと自分で処理してあげないとな。
    yappodなんかも、rastとにいかよった部分があってコピーしてindex更新してたっけ…

    indexサイズは、属性の取り方で変化しますが、約6万件600MBのデータが約400MBくらいになってます。
    大部分(300MB)が単語出現位置用ファイルにて消費されとります。
    indexのスピードは、感覚的にそこそこって感じでしょうか。スケールしだいで遅くなるのかなぁ。

    バインディングは、標準でRubyのライブラリが添付されていてPHPも公開されていたのですがGPL/LGPLとかのライセンス問題で公開停止中…
    Perlはまだないっぽい。

    追記:Sennaってのもあるみたい。2ch検索の中の人かなぁ

    Posted by Yappo at 13:03 | Comments (3) | TrackBack
  • 2005年03月20日

    二日目






    八年ぶりになのにすべれるもんですな。
    そんなわけで高崎通過

    Posted by Yappo at 19:54 | Comments (0) | TrackBack

    2005年03月19日

    ついた





    なんか豪勢

    Posted by Yappo at 15:55 | Comments (0) | TrackBack

    ここは誰?




    わたしはどこ?

    Posted by Yappo at 13:53 | Comments (0) | TrackBack

    2005年03月18日

    Google XのようなものをiYappoに

    巷で話題になったGoogle XのようなインターフェィスをiYappo(PC版)のTopに設置してみました。
    自分は生でGoogleXを見ることが出来なかったのですがCeekz LogsさんのGoogle X のミラーコピーで紹介されていたDock のようなに解説つきのバックアップを発見したので、これを参考に実装してみました。

    ただ、本家の実装はアイコンがただ大きくなるだけで、面白みが少ないのでiYappo版ではちょっとしたギミックをいくつか追加しています。
    例としては、アイコンにカーソルを合わせるとアイコンが跳ねます。
    iYappo
    iYappo Xと書いてありますけど、Googleやらmacやらを意識していたわけでなく、新しいiYappoのシステムのコード名がiYappoX(エックス)だったりするのです。

    naoyaさんのズーミングなまず君 - ぶっちゃけ Google X で騒いでる場合じゃないでも触れられている通り、結構前から似たようなものは有ったのですけどね。
    確かに、ズーミングなまず君を始めて見た時には、色々な衝撃を受けました。
    BulkYAの画像閲覧でも似たような雰囲気を醸し出しちゃったりもしてるけど。

    ちなみにアイコンは、一枚15秒くらいで適当に書き上げました。
    絵心無いくせに、それぞれのサービスをイメージして健気に書いたですよ。

    Posted by Yappo at 22:37 | Comments (0) | TrackBack

    2005年03月17日

    続・しますた

    デルのリリース文に修正はいってますた。


    デル株式会社(本社:川崎市幸区、代表取締役社長:浜田 宏、www.dell.com/jp/)は本日、携帯電話から同社のPC製品を注文できるホームページ「デル・モバイル・ショッピング」を開設したことを発表しました。「デル・モバイル・ショッピング」には、PC製品の同サイト限定パッケージや、お得なキャンペーン情報などが掲載されており、本日2005年3月15日よりご利用いただくことができます。また、同サイトの開設を記念して、4月30日までの期間中、プレゼントキャンペーンも実施します

    「しました」のタイピングミスかと思ってたですよ。
    uとiって隣同士だから、理解できたのに。文章としては変だったけど。

    でも「た」をけづるなんて。
    もう意図的に「しますた」って書いてたんじゃないかwwwwwwwwwwww
    あ、リリース文書いた中の人が無意識で書いてた可能性もあるな。

    別にDellキライじゃないですってば

    Posted by Yappo at 14:19 | Comments (0) | TrackBack

    2005年03月16日

    Dellが携帯ショッピングを開始しますた。

    Dellのリリース文章より


    デル株式会社(本社:川崎市幸区、代表取締役社長:浜田 宏、www.dell.com/jp/)は本日、携帯電話から同社のPC製品を注文できるホームページ「デル・モバイル・ショッピング」を開設したことを発表しました。「デル・モバイル・ショッピング」には、PC製品の同サイト限定パッケージや、お得なキャンペーン情報などが掲載されており、本日2005年3月15日よりご利用いただくことができます。また、同サイトの開設を記念して、4月30日までの期間中、プレゼントキャンペーンも実施しますた

    さっそくiYappoに登録されいるDellモバイルに行って見たら、内容とURLが変わったらしく新しいURLへ案内されますた。
    http://bemss.jp/dell/
    bemssってなんだ?と思って調べたらビートレンドという会社にたどり着きますた。

    なんだかよく分からないのでDellの担当者に聞いてみようと思いますた。

    Posted by Yappo at 15:49 | Comments (0) | TrackBack

    A9 OpenSearchに対応しました

    OpenSearch by A9より


    Google, Yahoo!, Microsoft と Web 2.0 な話題がつづいてましたが、Etech にあわせてか、Amazon (A9) がサーチと RSS のテクノロジー A9 OpenSearch をリリース。

    って事なので、blogdb.jpも追随してみました。
    検索結果のテンプレートの変更とOpenSearch Descriptionというxmlを書くだけで簡単に対応できちゃいました。


    そんな事よりblogdb.jpを安定させなきゃ

    Posted by Yappo at 14:29 | Comments (0) | TrackBack

    2005年03月15日

    BIG-IP v9 memo

    @ITより。
    製品詳細

  • カーネルがLinuxに

  • TMMデーモン

  • フルプロクシアーキテクチャ
    L4以上のデータをいじれるそうで

  • UDP正式対応

  • OneConnect
    Apacheのモジュールに特殊な事やってたら問題ありそうね

  • HTTPリクエストのパイプライン化
    モバイルサイトで絶大な効果かな

  • gzip圧縮
    レスポンスデータを透過的に圧縮するそうで

  • IPv6/IPv4ゲートウェイ
  • BIG-IP側に全部任せちゃうと大変な事になりそうでもあるな。
    最上位モデルで32/64 bit HyperTransport 2.4 GHz x 2と専用ASIC搭載だそうだ。

    ハードはいいから、これらを実現するソフトをだれか作ってないかな

    Posted by Yappo at 16:56 | Comments (0) | TrackBack

    算数おわりました

    締切日の朝かよって突っ込みは無しでorz

    Posted by Yappo at 05:22 | Comments (0) | TrackBack

    2005年03月13日

    オイ!23区で天気雪だぞ!

    めちゃくちゃ晴れて良い天気なのに、雪が激しく振っているのですが?in 江東区
    桜吹雪かと思ったら、本物の吹雪じゃないか。


    地球の寿命も残りわずかですな。


    と書いてる間に、吹雪が止まった。

    Posted by Yappo at 14:15 | Comments (0) | TrackBack

    2005年03月09日

    DBIのクエリを透過的にキャッシュするDBIx::QueryCacheを作ってみた

    同じクエリが良く発行されていて、DBサーバにまで負荷をかけずにフロントエンドでキャッシュする仕組みが無いかと思っていて、
    どこかで実装されている物だと思い探していたのですが、無いようなのので実装してみました。

    DBI経由で取得するクエリの結果を透過的にキャッシュする事が可能なモジュールです。
    透過的と言っても、キャッシュしないSQL分を正規表現で指定して弾くというだけで
    アプリケーションによっては、不都合が大量に出てくるので明示的にキャッシュのON/OFFを指定するメソッドも追加しています。
    現在は、MFPMにて試験的に導入されています。

    ソース
    説明

    開発の思想としては、キャッシュにヒットする事でパフォーマンスが向上する事は考えておらず、
    キャッシュにヒットさせることでDBサーバのクエリ数を減らし、結果的に全体のパフォーマンスを向上させる事を考えています。
    なので、DBサーバとフロントエンドが同居している場合はどうなるかは分かりません。
    ただし、indexを使わないwhereクエリなどではパフォーマンスが上がりそうです。
    キャッシュのさせ方を間違えると効果が期待出来ないので、かなり諸刃の剣なモジュールだとは思います。

    開発はDBD::mysql環境のみで行っているので、DBD::Pgとかでどうなるかは分かっていません。
    MySQL環境で開発した影響で、SQL_CALC_FOUND_ROWS /FOUND_ROWSもうまく取り扱えるように実装されています。

    使い方は


    use DBIx::QueryCache;

    my $attr = { _DBIx_QueryCache_dir => $cache_dir };
    my $dbh = DBIx::QueryCache->connect($data_source, $username, $auth, $attr);

    としてDBIと同じようにconnectをしておいて


    #キャッシュさせるクエリ
    $sth = $dbh->prepare_enable($statement[, $expries]);

    #キャッシュさせたくないクエリ
    $sth = $dbh->prepare_disable($statement);


    って感じです。
    connectのオプションのつけ方しだいで、既存のprepareのみを使用してキャッシュ処理を行う事も可能です。

    当初は、既存のソースコードの変更を最小限にしつつ、キャッシュ機能が使えるようにしたかったのですが
    アプリケーションによっては、明示的にキャッシュ制御が出来ないと不都合が起きてしまうので
    今のような中途半端な仕様になってしました。。。

    デフォルトでは、Cache::FileCacheを用いてキャッシュ処理を行っていますが、get/set/sizeメソッドが実装されている物なら、どれでも使えます。
    ただし、Cache::FileはCache::FileCache使用時よりも3倍遅いので推奨しません。


    肝心のパフォーマンスですが。
    単純なselect文では標準のDBIの方が早いです。
    like '%key%'のようなインデックスを使わないクエリの場合は、こちらの方が早いです。
    早いと言ってもキャッシュに引っかからなければパフォーマンスはでません。

    参考程度に、軽くパフォーマンス測定をした時の結果を載せておきます。
    PerlスクリプトのあるマシンとDBサーバは物理的に異なるマシンで、100MのLANで接続された環境となっています。
    コードA


    use DBIx::QueryCache;

    my $dbh = DBIx::QueryCache->connect($data_source, $username, $auth,
    {
    _DBIx_QueryCache_dir => './DBIxQueryCacheTEST',
    });
    for (my $i = 0;$i < 100;$i++) {
    for (my $ii = 1;$ii < 100;$ii++) {
    my $sth = $dbh->prepare_enable("select * from FAVORITE_PM limit $ii");
    $sth->execute;
    while (my $row = $sth->fetchrow_arrayref) {
    }
    }
    }

    コードB


    use DBI;

    my $dbh = DBI->connect($data_source, $username, $auth);
    for (my $i = 0;$i < 100;$i++) {
    for (my $ii = 1;$ii < 100;$ii++) {
    my $sth = $dbh->prepare("select sql_calc_found_rows * from FAVORITE_PM limit $ii");
    $sth->execute;
    while (my $row = $sth->fetchrow_arrayref) {
    }
    }
    }

    コードC


    use DBIx::QueryCache;

    my $dbh = DBIx::QueryCache->connect($data_source, $username, $auth,
    {
    _DBIx_QueryCache_dir => './DBIxQueryCacheTEST',
    });
    for (my $i = 0;$i < 100;$i++) {
    for (my $ii = 1;$ii < 100;$ii++) {
    my $sth = $dbh->prepare_enable("select * from MODULE_MASTER where DESCRIPTION like '%dbi%' limit $ii");
    $sth->execute;
    while (my $row = $sth->fetchrow_arrayref) {
    }
    }
    }

    コードD


    use DBI;

    my $dbh = DBI->connect($data_source, $username, $auth);
    for (my $i = 0;$i < 100;$i++) {
    for (my $ii = 1;$ii < 100;$ii++) {
    my $sth = $dbh->prepare("select * from MODULE_MASTER where DESCRIPTION like '%dbi%' limit $ii");
    $sth->execute;
    while (my $row = $sth->fetchrow_arrayref) {
    }
    }
    }

    各コードを3回実行した時の中間タイム

    A B C D
    real 0m21.455s 0m17.840s 0m8.705s 0m12.179s
    user 0m20.461s 0m6.654s 0m7.964s 0m2.035s
    sys 0m0.880s 0m3.478s 0m0.737s 0m1.098s

    現状はApache::DBIやClass::DBIなどの事を考慮していません。

    あとは、ある程度動作実績をつけて、ドキュメントを英文にしてCPANに登録する感じかな。

    Posted by Yappo at 04:25 | Comments (0) | TrackBack

    2005年03月06日

    エキサイト、シーエー・モバイルと提携し携帯サイトに検索・広告機能付加

    エキサイト、シーエー・モバイルと提携し携帯サイトに検索・広告機能付加

    多くは語れないけど、エキサイトがモバイルもOEMになるのは、感慨深いです。はい。

    あぁゴメンナサイごめんなさい

    Posted by Yappo at 03:01 | Comments (1) | TrackBack

    電通から日本の広告費のレポートが来た

    数年前から、広告費に関するアンケートのお願いメールが何故か個人宛に来ていたのだが
    今回から気持ちを入れ換えてアンケートに記入してみたら報告書が本日届いた。

    書類には引用や著作に関する注意事項が無かったので、どこまで引用していいのかどうか分からないけど、概要だけさらっとメモ。

    2004年のインターネット広告費は1814億円(うちモバイル媒体は180億円)だそうだ。
    広告全体の比率としては3.1%で、2003年より1%増えているようです。
    最近話題になったラジオは1795億円となり、年々減少傾向みたい。

    衛星メディア関連(436億円)以外の媒体に関しては、2003年まではインターネット広告が再開だったのですが、2004年はいくつかの媒体を追い抜いています。

  • POP広告:1745億円

  • 電話帳広告:1342億円
  • インターネット広告の伸びが衰えないのであれば、今年は下記の媒体を追い抜くかもしれません。

  • 屋外:2667億円

  • 交通:2384億円
  • なお、電通の予測では今年の広告費は昨年より減少するらしい。

    Posted by Yappo at 01:55 | Comments (0) | TrackBack

    中の人の重い一日with検索会議

    14:20 起きる
    14:30 寝るwww
    16:10 目が覚める
        遅刻しそうなため、1分くらい/panic motionして落ち着く
        ヒルズの中の会社の中の人にメッセンジャ

    Yappo@DBIx::QueryCache の発言 :
    ねぼうですorz
    ????? の発言 :
    orz

    16:20 家出る。走る。ひたすら走る。公園の中突っ切る。
        これがジョギングだったら、どんなに有意義な休日だか
    17:10 六本木着く、ヒルズまでひたすら走る。何を勘違いしたかYahooのオフィスに向かう。
        過ちに気づきつつも目的地へ走る。
        エレベータのって気づいたら、はてなの中の人と二人っきりだと気づく
        そして自分の手には、WEB+DB PRESSが、いっその事「サインください!」とジャニーズファンさながらの攻撃をしてみようと思ったがポスカが無い事に気づき断念。
        まねして腕組みしつつエレベータで体力回復。
    17:20 到着、事態を飲み込みつつスライドを見る。どうやら事前エントリ時のネタをつまみに話しているようだ。
        そして、どこかで書いたような文章が原文ママでスクリーンに
    司会の人:・・・・・・これはスルーで

    ○| ̄|_

    じゃぁはじめから資料にいれとくなyppppp!

    17:30 ついに、お待ちかねのY!本体のエンジニアによるプレゼン開始
        MySQLエバンジェリストのお話は、現在の取り組みやこれからのお話など。
        シェアリングサーチとかの単語が出てたかな。
        頑張って英語を聞いていたんですが、激しく聞き取りにくい発音(最近スコットランド人の教師とばかりコミュニケーションしてるせいかな・・・)で通訳さんスゲーと思
    った。

        そして、エンジニア担当の方のお話、テーマは「検索エンジンとかの作り方を考えてみよっか」のような感じ。
        検索エンジンを作る際に考える事のうち、次の4点について説明しましょうってな感じで始まった。
        1.スケーラビリティ
         たとえば、10億100億(10Billionって言ってたorz)のサイトを収集するとしましょう、1ページあたりのサイズの平均は20kと仮定すると、全体で200Tのデータ量になります。
         検索エンジンは鮮度が重要なほど良いでしょうから、これらを毎日取得したいと思います。すると約20Gbpsほどの帯域を持つ回線が必要になります。
         また、これらのデータを100万サイトずつ1台のサーバにデータを格納すると1万台のサーバが必要になります。

         なるほどね、Yahooも1クラスタあたり100万URLずつ保存してるのかな、Googleもスペックから逆算すると100万くらいだしね、昔yappodをカリカリに作り込んだ時も100万くらいが分岐点だったかな。
         通訳の人が「大きな問題」とか通訳してたのは愛嬌かな。

         2.クエリ 3.ランキング 4.spam って感じだった。
         隙あらばリクルーティングも混ぜとりましたな。
         この方の英語は聞き取りやすく(ハリウッド映画の中国人の英語みたいな感じ、実際そっち系の方でしたが)、時たまギャグも出て通訳される前にみんな笑っとりましたな。
         むしろ通訳要らないセッションだったかもね。技術者の集まりだし。
         しかしYahooも変わったもんだなぁと思わせる内容でした。

    18:00 そして、全体会議のコーナー。15分くらいで、お題(Yahoo! Web Serviceを活用して有用なサービスを考える)に見合いつつも不真面目なネタを考えようとしたからきつかった。
         提出したのは「利用者の食生活情報を元にWeb上の該当する食材データを探し、それらを食すると今後の健康状態がどうなるかを計算して、利用者に提示していくもの」って感じのものにしてみた。

        しかし、検索会議と題されている割には検索窓にキーワードを入れるキーワード検索に比重が傾いていたきがしたなぁ・・・なんかキーワード検索会議って印象を持ちました。司会サポートの大也さんは、そういう感じでは無かったけれども。

        締めくくりに、日本支社の方が、視覚的に良いインターフェィスも~って話をしていた。

    19:00 そして、Yahooから参加者全員にお土産配布。太っ腹!
        ↓が、みやげ物一覧。
    Y_miyage.jpg
    奥が見えにくいけど、左がYahoo!トートバッグ、右がお土産入ってた紙袋で真ん中のがYahoo!ソードです。

        そして帰りの時間です。AU公式検索の中の人を発見したので、一緒に駅まであるいた。
        その他の中の人たちは見つけられなかった・・・
        そして大江戸線にJoin in
    19:15 気が代わったので帰るのをやめて、ユリカモメにのってフジテレビへ
        電車代無駄になった挙句、ユリカモメたかい。ヌッコロス
    20:00 六本木からフジテレビまで面倒な交通路なのにホリエモンの中の人はよくフジテレビ買う気になったなぁと思いつつ通報されないうちに、アクアシティへ。

        マジスティックを衝動買いし、ワイン屋さんにて何を買おうかめちゃくちゃ悩む、本日一番頭を働かせた瞬間である。とりあえず欲しくなったものを全て買う。
        そして、帰ろうかと思い出口に向かうと台場みやげ物屋を発見。即座に欲しくなっちゃったものだけ全て購入。
        久しぶりに財布の中身見ないで買い物しちゃった。
    21:00 アクアシティ前のバス停でバスを待つ。なんとQRコードが!バスの現在位置提供サービスにリンクしているようだ。
        このサービス自体は知っていたが、バス停にQRコードが有る事でお買い物しながら乗りたいバスがどこにいるかを把握できるのでめちゃ便利。
        こういうリンクのさせ方こそ、モバイルの生きる道だよね。
    21:30 家まであるく、が、荷物重すぎる、買い物しすぎた泣きそう。
        そしてS社の方に頼まれていた件を、やったと思っていたのにやっていないと気づく。激しく財熱燗に襲われ、心身ともに重くなる。はいやります、ごめんなさい。

    Yahooの本日の出費予想。
    商品券28万
    会場費10万
    お土産台100万
    その他100万
    計250万くらい
    Yahooが得たものPrice less(かな?)
    対コアユーザへのfun,pr,囲い込み,リクルート費用なのかなぁ…アイディア料のはずもないよなぁ・・

    Yahooが良い会社だというのが認識できた日でした。

    あーあと、グループディスカッション中に
    「みなさんMixiは?」って場面があり、全員やっとりました。
    greeという言葉は出ないのね…


    ※ごく一部にフィクションが含まれております。

    Posted by Yappo at 00:25 | Comments (0) | TrackBack

    2005年03月04日

    jigブラウザ、WEB版でWIN端末、ボーダフォンにも対応

    jigブラウザ、WEB版でWIN端末、ボーダフォンにも対応

    ………………………


    退化?

    え。。。jigがこのサービスをやる意義が、いまいちわからない。。。。

    Posted by Yappo at 20:59 | Comments (7) | TrackBack

    2005年03月02日

    BulkYAで大幅な機能追加しました

    当初はヤフオクのRSS検索を串刺しにor検索出来る事を売りにしていたBulkYAですが。
    あっさりと本家にor検索があることが判明してしまい、しばらく途方にくれていました。

    ただ、様々な方の助言を得る事も出来たので、あれもこれも追加していくうちに
    なかなか良い形にまとまってきたのではないかと思っています。

    まずは、ヤフオク専用の検索サイトをやめました。
    ビッターズと楽天フリマも並列に検索するようにしました。
    3社のオークションを並列に検索をするメタサーチと考えていただければ分かりやすいです。

    ビッターズや楽天に対応した事で、各オークションの縮小画像も同時に表示するようになりました。
    画像のみを並べて商品画像のみで比較する事もできます。
    オークションによっては、画像のサイズにバラつきがあるため、imgタグでサイズを固定していますが
    マウスフォーカスを当てると、実サイズにリサイズされていきます。
    このあたりの、画像がぐりぐり切り替わる様子は見ていて楽しいです。

    ただ単に各社オークションを串刺し検索するだけというのも面白みが無いので
    検索に引っかかったオークションを自動的に分類して、分類別にまとめる機能も提供しました。
    これをクラスタと表記しています。
    とても単純なロジックでクラスタしているのですが、それなりに分類されていて面白いです。
    有名人で検索した時は、ライブ会場別にチケットがクラスタされてたりとか。
    このぐらいの小規模なデータでも十分使い物になるんだなぁと。本格的にやるには辞書整備など必須ですが。

    クラスタ機能はAjaxするかどうか悩みました。
    実装当初は、各クラスタワード毎に対応する商品リストHTMLを作成しておき、クラスタワードがクリックされるたびに、リストHTMLが格納されているDIVタグを表示・非表示と切り替えていました。
    この方法だと、1M近くのHTMLを吐き出してしまう事があり実用的でなく、でもクラスタの表示切替くらいは画面移動させたくないので、Ajax化でもしてしまおうかとも思ったのですが、毎HTTPトランザクション毎にクラスタ作成するのもクラスタのキャッシュをサーバに置いておくのも嫌な感じがしたため、検索結果のデータをJavaScriptのオブジェクトとしてHTMLに書き出しておき、必要な時にHTML中のデータを基にして描画するようにしました。

    何が言いたいかというと
    最初のリクエスト時に画面中で必要なオブジェクトを作成しておいたらAjaxを使う必要が無くなった。
    という感じでしょうか。
    ページが表示されて数分経過したらAjaxで最新のオブジェクトを取ってくるようにするのは良さげですが。

    あやうく一度で済む物にまでAjax使いそうになってしまった。
    Ajaxの使い所って非常にむつかしい…

    この機能追加により、JavaScript必須なサイトになっちゃいましたが。

    Posted by Yappo at 03:53 | Comments (0) | TrackBack