HardReggaeCafe＠Ameblo.jp -63ページ目

それを更に進化させて
AISCEAS = ネットでの購買行動のモデル(宣伝会議)
　Attention → Interest → Search → Comparison → Examination → Action → Share
　　　　　　　　　　　　　　　　　　　(比較)　　　　(検討)
というのが今の主流のようです。アンヴィコミュニケーションという
ところの発案で「宣伝会議」に出ていたみたいですけど。

この「比較」「検討」のところでよく悩む
このクチコミや書き込みは正しいのか？という疑問、すなわち
「信憑性」について今日は調べた結果を述べてみます。

今担当している「WeddingPark」でも結婚式に「参列」「下見」「申し込んだ」
「結婚式した」という方からの多数のクチコミが寄せられるのですが
中には悪質な誹謗中傷、事実の歪曲、会場関係者からのなりすましが
あとを絶ちません。

判断基準は社内には一応ガイドラインとして存在するのですが
なかなか一筋縄には行かず、最終的には事業判断となることもあります。

自分なりにAmazonや他のCGMサイトを見て、その考察を書いてみます。
・「参考になった」クチコミは具体的だが長すぎない
・同様に「良かった点」「悪かった点」がきちっと書かれている

ちなみに「参考になった」というのは「買わない」という消費行動にも
つながっているのでこのコンセプト自体を評価するのは難しいです。

・いろいろクチコミでああでもない、こうでもないと書いているけど
　評価をポイントにすると高得点にしているケースも多い
　（まさに消費者の微妙な心理を反映）
・ベストレビュアーが書いたクチコミだからと言って「参考になった」
　数が特別多いとも限らない

このように多種多様で一口にクチコミの信頼性について法則性を
見出そうとしても難しいといえます。

やらせという点では最近は善意の第三者を装って投稿する
「ステルス・マーケティング」というのも結構問題になってきてます。

これがカリスマブロガーや「権威」といわれる先生が書くことで
宣伝効果は絶大で、企業から依頼されて書いた場合のツケとなる
「炎上」もよくある光景です。

さて、信憑性をどのように図ろうかという本題に戻りますが、
これはもう勝手な想定でトライ＆エラーで行くしかない。

GoogleやYahoo!が検索エンジン仕様を公開しないのと同様
（とはいえ小出しに謎は解明されているっぽいけど）
当社も極秘でいくつかの仮説を立てながらそれをポイントにして
高い順にクチコミ信頼度を設定するような感じです。

被リンク数とか実際に行った人しかわからないシークレットキーワードを
用意してそれに対する言及数とかそういう仮説です。

この辺また進展あったら書いてみます。良い評価法があったら是非
教えてください。

デブサミ回顧録・WindowsでPlagger体験「それPla」

DevSummiで一番面白かったトピック。
それはサイボウズラボの竹迫さんが講演した
「PlaggerによるRSS/ATOMフィードのマッシュアップ」

最近は更新コンテンツをRSSなどのフィードにしているサイトが
多くて、自分もいろいろ購読しているのですが、その量が半端じゃないので
読まないままになっているものが山積みになってます。

整理分類して勝手にメールしてくれれば楽なんだけどなー

「それPlaggerでできるよ！」
と天の声。

そうなんです。Plaggerを使えばいろんなことが解決できるのです。

Plaggerの基本的な仕組みは
「購読」「カスタムフィード」
　↓
「変換」
　↓
「出力」「通知」
となっています。

つまり入力→加工→出力というアプリケーションのアタリマエの流れなのですが
これが柔軟にいろいろ変えられるところに面白さがあるわけです。

竹迫さんの事例で言うと…
腹減ったと検索するとピザやら寿司の出前をオーダーしてくれる
などということも出来るようです。

さて、そんな便利なPlaggerはLinux,Windows,Mac OSなどあらゆる
プラットフォームで稼働するという優れもの。

早速Windowsでのインストールですが

1.ActiveStateのサイトからActivePerl5.8.7を取得
　（バージョンが違うだけで全くインストールできないので注意！）

2.ppm プロンプトからTcoolのリポジトリをPPMに追加
> rep add tcool http://ppm.tcool.org/server/ppmserver.cgi?urn:PPMServer
> rep up tcool
> search Plagger

3.ppm プロンプトからPlaggerのインストール
> install Plagger
（基本全部Enterで大丈夫）

4.SSLパッケージを入れ替え
　1)theoryx5のリポジトリ追加
　　rep add theoryx5 http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58
　2)SSLeayのパッケージ検索
　　rep up theoryx5（2回やると最上位に）
　　search SSLeay
　3)インストール
　　install -force 1

5.Plaggerの3大罠の一つ「assetsの罠」を回避するためPlaggerのソース
　からassetsを持ってきて入れ替えする
　入れ替える先はC:\Perl\bin
　Plagger-0.7.9.tar

と結構初心者には高いハードル。

わからなくなったら調べて、直して、というアプリ開発の健全なサイクル
が確立されて文化的な貢献が云々と話していた気がします。

で、起動する前にやらせたいことをYAMLというコンフィグファイルに
記載しておきます。

最初に書いたやつはこんな感じ。

---------------------

c:\perl\bin\config.yaml

---------------------

plugins:
- module: Subscription::Config
config:
feed:
- http://blog.bulknews.net/mt/index.rdf
- http://phpspot.org/blog/atom.xml
- http://www.pheedo.jp/f/JapaneseTechCrunch
- http://blog.japan.cnet.com/kenn/index.rdf
- http://www.asks.jp/users/hiro/data/rss
- http://www.socialnetworking.jp/index.rdf

- module: Filter::Rule
rule:
expression: $args->{entry}->body =~ m/WEB2.0|SNS|PHP|microsoft|JAVA/

- module: Filter::Rule
rule:
module: Deduped

- module: Publish::Gmail
config:
mailto:
- oresama@dot.com
mailfrom: hardreggaecafe@gmail.com
mailroute:
via: smtp_tls
host: smtp.gmail.com:587
username: hardreggaecafe@gmail.com
password: password

何も言わずこれを書いてみてください。ちなみにYAMLはタブではなく
インデントはすべてスペースです。
修正が必要なのはアグリゲートするRSSのところと、引っかける
キーワードとメールを送るSMTPサーバにGmailを使っているのでそこの
設定のところです。

賢明な皆様でしたら書いてある内容は何となくお分かりかと。

この辺のドキュメント
http://plagger.org/trac/wiki/
やインターネット上にいろいろな情報が流れているので
是非ググって見てください。

Plaggerはもちろんオープンソース。コミュニティのコミッタも
40人ほどいるとかで今最もアツいと思います。

プラグインも続々有志によって開発されており、Mixi情報もゲット
できたりするようです。

- module: CustomFeed::Mixi
config:
email: hardreggaecafe@gmail.com
password: password
fetch_body: 1
show_icon: 1
feed_type:
- RecentComment
- FriendDiary
- Message

こんなものを書いておけばアグリゲートするみたい。

あとは、環境変数のPATHにc:\perl\bin（Plaggerが入っているとこ）を
確認してコマンドプロンプトから

Plagger

と入力するだけです。

どうです？何やらメールで飛んできませんか？

キーワードに合致したエントリが続々送られてくるかと。

- module: Filter::Rule
rule:
module: Deduped

この設定がされていると、次から重複エントリは送信されません。

ということで、スタートメニューから
「アクセサリ」→「システムツール」→「タスク」
を立ち上げて定期的にバッチ起動させれば、あとは時間が到来すれば
自動でアグリゲートして送付という構図が出来上がります。

RSSみたいに必ずしもフィード化されているものでなくても
サイトの情報から必要な項目だけ切りだして送ったりとか、Excelに吐きだす
とかも出来るみたいです。

この辺に詳しいこと載ってます。

そもそもの開発者Six Apartの宮川さんも多く文献を残しています。
それがhttp://pllager.org のwikiに集約されています。

サイボウズラボの社員でありながらShibuya Perl Mongers（Perlのユーザコミュ）
として積極的に広めようといろんな仕掛けを見せてくれる
竹迫さんはさながらPlaggerのエヴァンジェリストってところでしょうか。

当日は羽織袴で登場し、Wiiリモコンでプレゼン資料を次々めくる。

会場にいた人は完全にクギづけでしたよ（ｗ

デブサミ回顧録・Mixiのスケールアウト術

かなりのご無沙汰だったのですが、実は新たな
サービスを始めるために裏で悪戦苦闘しています。

その苦戦の過程は別のブログに収めているのですが
ちょっと内緒。4月過ぎたら公開します。

そんな中、先月はデベロッパーサミットに参加してきました。

１つはMixiのバタラさんのサーバスケールアウトの話。

バタラさんは2005年にも別のカンファレンス（YAPC::Asia 2006 Tokyo）
でも同様の講義を行っています。

それによると
・パフォーマンス拡張には2通りあって、スケールアップとスケールアウトがある
・サーバのパワー自体を拡張するスケールアップには限界がある
（CPUでもXeon3.5Ghz×２、メモリも最大4GBぐらいか）
・サーバの数だけパフォーマンスが上がるスケールアウトは一般的ニーズに
　合致する（スモールスタートできるし）
てな感じで、具体的なスケールアウトの手法についてはWEBサーバとDBサーバで

それぞれテクニックがあるらしいので覚えている範囲で書き連ねてみます。

[WEBサーバ]
・静的コンテンツと動的コンテンツで若干対応法が違う
・ただし、基本はキャッシュ機能を利用する
・静的コンテンツはキャッシュのヒット率が良く、コンテンツ更新度は低い
・キャッシュサーバとオリジンサーバ（コンテンツの元になるサイト）の組み合わせ
・キャッシュサーバが増えるとオリジンサーバは負荷が上がる
・解決するために多断層キャッシュサーバをさらにクラスタ化するという方法で
　負荷分散を行う
・動的コンテンツはキャッシュのヒット率が悪く、コンテンツ更新度は高い
・ロードバランサで単純に負荷分散しただけでは動画や画像アップロード
　するとそこがボトルネックになってしまう
・これを解消するために機能に応じてクラスタ化する（アップロード用の
　セグメントを作る）
・加えて共有メモリを利用する
・共有メモリはノードワイドとシステムワイドがある
・ノードワイドは一つのサーバ内でプロセス間でメモリを共有
・システムワイドは複数サーバ間でメモリを共有（memcached）
・スピードはノードワイドが有利
・スケーラビリティはシステムワイドが有利

[DBサーバ]
・DBサーバのスケールアウト戦略は基本レプリケーションとデータ分散
・最初はマスタースレーブで更新はマスター、参照はスレーブという
　オーソドックス戦法
・問題点はレプリケーションのクラシック問題と更新数が増えた場合
・対処法としてデータをいくつかに分散してそれぞれ別DBにする
・メール用、掲示板用、…とそれぞれに別DBに分散させる
・DBの分散できる数に限界があるので、さらにパーテショニングキーを
　使っての分散処理を検討
・プライマリキーなどをHashで分散させる
・たとえばノード数で割った余りというアルゴリズムベースで分散させると
　サーバを増やした時にノードIDがずれてしまう
・これを回避しようとするとノード数を倍に増やしていかなくてはいけなくなる
・動的にパーティションマップを更新するマネージャーベースの
　手法ならノード数を倍増やす必要はなくなる
・マネージャベースはノードを管理するDBを別に用意する手法
といった話でスケールアウトのシナリオについて教えてくれました。