(´･д･`) ｴｰ
2008年7月17日木曜日
2008年7月13日日曜日
SBM研究会に参加
SBM研究会に参加しました。
事務局のみなさん、ありがとうございました。大変有意義な研究会でした。
会場の東工大岡山キャンパスには初めて行きましたが、広い敷地に緑が多くとても素敵な場所でした。
感想を少し書いておきます。
---
■「ソーシャルメディアとマーケティング」
内容のみならず独特の語り口調がとても面白かった。
ソーシャルブックマークは総合型ではなく閉鎖型（特化型？）でまず成功した後に、総合型に発展していくほうがよい、という結論には同意。（私はその考えに基づいて特化型SBMを自由に作れるサービスを作成し、実験的に公開している。）
■「SBMデータを用いたwebコンテンツ推薦」
コラボレーティブフィルタリング手法について。自分からは積極的に勉強しない分野なので、とても勉強になった。
■「SBMにヒントを得たコメント共有サービスの一提案」
コモンズ・マーカーの解説。
非常に完成度の高いシステムと感じた。今後サービスとしてどう盛り上げていくのか注目したい。開発者の方がマイクロブログとSBMの近似性に言及していたが、その点は私も常々感じていた。
■「お前のモノ（ブックマーク）は俺のモノ、俺のモノ（ブックマーク）も俺のモノ」
P2P型SBMのアイデアについて。興味深いアイデアだと思うが、P2P型SBMツールをインストールさせる動機が課題になるのではないか。
■「ソーシャルグラフってどうよ？」
ソーシャルグラフに関する解説。ソーシャルグラフは折れ線グラフの共有ではありません、などユーモアを交えて解説されており楽しかった。
講演途中で豪雨。
■「私がチャレンジしたSBMデータマイニング」
はてブのデータを利用したサービスの動作原理について。
新しいSBMを作るのではなく、はてブのhotentryの見せ方を変えてユーザーに提示するアプローチはSBM普及の手段の一つとして非常に有効だと思う。（はてブユーザーの行動特性、コミュニティカラーはhotentryの内容に大きく影響されるのではないか。フィードバック内容を変えれば、行動も変わる。）
■パネルディスカッション「SBMの課題とこれからSBMが進むべき道」
アカデミック、ビジネスの両サイドからパネリストが選出されており、若干消化不良感はありつつも、興味深い内容だった。
参加者のモバイルPC所有率が高く、Twitterでリアルタイムに感想を投稿している人が多かった。私はPCを持っていかなかったし、携帯の電池も切れそうだったのでTwitterにアクセスできず、隣に座っていた某氏にタイムラインを見せてもらっていた。タイムラインに参加できないことに、なんだかとても疎外感を感じた。
ニコニコ大会議でのコメントリアルタイム共有で参加者が感じた新しい現実感とおそらく同様の感覚だったのではないか。
私もSBMには非常に高い関心を持っていて、気がつけばこれまでに３つのSBMを作成している。一つはイントラでSBMを評価するためのプロトタイプ、残りの二つは個人的に作成して公開中のものだ。
今回の研究会の内容はアカデミックな要素が多く、SBMが一般に普及した後にどのように情報評価システムとしての品質を維持するか、という点に問題意識があったと理解している。
一方で、私の問題意識は、どうすればSBMが一般に普及するのかという点にある。アルゴリズムよりもユーザー心理やコミュニティ論に興味がある。
普段の問題意識と異なる内容だったため、逆に自分の立ち位置を再確認できたし、新しいインプットを得ることができた。１０時から６時までと長丁場の研究会だったが、得るものの多い一日だった。
講演を聞きながら、いくつかSBMの新しいアイデアを思いついたので暇を見つけて作成してみたいと思っている。
2008年7月11日金曜日
GQLでSQLのLIKEを使いたい
Read this Laterですがメール送信の宛先をプルダウンだけではなく自由入力を可能にしました。
また、入力中に登録済みメールアドレスから部分一致する候補をインクリメンタルサーチで表示します。
で、LIKE文を使って入力内容と一致するメールアドレスを抽出したかったんだけど、結論から言うとGQLではLIKEは使えません。
クエリを工夫することで前方一致(abc%)はできるんだけど、部分一致(%abc%)はできない。
http://groups.google.com/group/google-appengine/browse_thread/thread/13fef4201063d894/06629858e8f201b3?lnk=gst&q=LIKE+query#06629858e8f201b3
結局どうしたかというと、全件抽出して一つずつ正規表現でマッチングしました。
対象が高々数十件なので、とりあえず実行速度的には使用に耐えられそう。
2008年7月10日木曜日
Read this LaterとGmailで気になる記事のデータベースを
'Read this Later(RTL)'は人にネット上の記事を勧めるツールなわけですが，自分宛に備忘録として送っても便利ですね．
自分宛だと「あとで読む」とバリューがかぶるわけですが，記事の選択領域をクリップしてメールしてくれるので，RTLのほうがちょっと便利かな．
GmailでRTLからのメールをラベル付けしておけば，クリップした記事を一覧するのもキーワードで検索するのも簡単です．
RTLに送信履歴の検索機能をつけようかどうか迷ったんだけど，Gmailの強力な検索機能を使った方が便利なので，結局今のところ実装の予定はないです．
気になる記事はポイントを引用してどんどん自分宛に送っておけば，結構便利なデータベースになりそう．
2008年7月9日水曜日
サンデープログラマーにGoogle App Engineをお勧めする理由
僕はこれまでレンタルサーバーを借りてPHPでWebサービスを作って公開してたんですが，今やすっかりGAEの虜です．
僕が最初に感じたGAEの利点は次の二つ．
１．環境構築が不要
GAEの開発環境はSDKをダウンロードしてインストールすれば構築完了です．
たとえば，PHPでWebサービスを開発する場合は，ApacheやMySQLをインストールしてなんたら.cnfを書き換えて，.htaccessを設定してSmartyやらpdoやらgdやらをインストールしてchmodしてなんて作業を延々としないといけません．開発マシンがクラッシュしたりすると，もう一度同じ作業をする必要があって，あれ前回どういう手順だったけと思いだしながらやるわけです．うげぇ．
一方でGAEは数クリックで開発環境の構築完了．
僕のようなミドルウェアから下のレイヤーには興味がなく，アプリケーションを作りたいだけの人間にはうってつけです．
２．ユーザー登録機能の実装が不要
GAEではGoogle Accountでの認証をサポートしています．
従来ならメールアドレスとIDを入力して確認メール送ってメール内のURLがクリックされたらアカウントをアクティベートして，なんていうユーザー登録の仕組みを地道に作ってたわけですが，これも不要．
ユーザーがGoogle Accountを持っている人に限られてしまう可能性はあるけど，新しいネットサービスを使ってみようと思う人であれば，Gmailを使っていそうだから問題ない．
ユーザー認証の実装はなんと次の4行で出来てしまいます．
user = users.get_current_user()if user:#認証済みの場合の処理else:#ログイン画面にリダイレクト．ログイン後は最初にアクセスした画面に再度リダイレクト．self.redirect(users.create_login_url(self.request.uri))
アプリ開発者がアプリ開発に集中できる．これがGAEをお勧めする理由です．
GQLではJOINやGROUP BYができなかったりと制限は色々とあるのですが，それもスケーラビリティの代償と考えれば納得できます．
僕は.NET数年，PHP半年という経験のサンデープログラマーなのですが，最初はPythonに抵抗感があったものの，Python+Djangoを数日勉強しただけでアプリを開発することができました．
Read this Laterも実装自体にかかったのは１０数時間です．
そしてこれが無料なんです．
Google App EngineでSession変数を使う
2008年7月7日月曜日
Google App EngineでIndexエラー
下記のようなエラーが発生する場合がある。
NeedIndexError: no matching index found
This query needs this index:
GAE管理画面で、メニューからDatastore→Indexesを選択し、Indexのstatusを確認する。
statusがServingではなく、Buildingになっている場合は上記エラーが発生する。
2008年7月2日水曜日
登録:
投稿 (Atom)
