ネコ情報
ネコを各種ブログ(Blog)から一括検索します。
トップ > マンチキン > マンチキン - 人気ブログ(Blog)検索結果詳細 (2008年10月12日 7時)
iTunes Store の Gift Certificate
私と mara は、iTunes Store の US 店にアカウントを作って楽曲を買ってます。どーやって登録したかは3年前のことなのですっかり忘れてしまった。まあアメリカの住所で登録して、ドル建ての Gift Certificate を買ってきて redeem して楽曲の購入に充ててるわけです。日本店と違って山のように楽曲が用意されてるので素晴らしい。Rafal Blechacz から Ginger Does’em All まで置いてあるし。
この方法の欠点は、Gift Certificate が高くつくこと。Gift Certificate は日本国内でも売ってる店がいくつかあって、私は ベースオントップ とかで買ってたんですが、だいたい$10で1500～1600円ぐらいするんだよね。$0.99の曲を買うと、iTunes Store Japan の1曲150円よりも高くつくことに。
今日検索してて、$100 の Gift Certificate を $89 という破格の値段で売ってる オンラインショップ を発見しました。今の相場だと$1=106円ぐらいだから、$89=9400円ぐらい。1曲あたり94円という計算になって、お得なのぢゃ。
でもやっぱ怪しいと思うよね。なんでそんなに安く売れるんじゃいと。しかもサイトが blogspot.com 上にあるってどうよ。そりゃまあ最近は WordPress 使ってショッピングサイト構築する例も最近増えてきてるけど、blogspot て…
なので、いきなり $100 を買うのは怖いので、まずは $40 の方を購入してみました。$40分の Gift Certificate が $38 で買えます。まあ4000円弱なら失敗してもいいかあと。
支払いは PayPal ないしクレジットカードが使えます。PayPal使おうとしたら、Kivaに出資したとき以来使ってなかったのでパスワードすっかり忘れてて焦ったぜ。
支払いを済ませると、3時間ほどでメールが送られてきました。ベースオントップなんかは数分で送られてきたけど、ちょっと時間がかかる。これは後述する理由で仕方が無いことのようです。メールに Certificate Code が書いてあるので、これを iTunes から入力すれば完了。無事 Redeem できたぜ。
この店を使う際の注意点ですが、Redeem を24時間以内に行う必要があるそおです。なんと、この店が売っている Gift Certificate は、一部企業のプロモーション用に作られた特別なコードだそうで、発行後24時間で無効になってしまうんだそおな。注文受けてから発行するんだな。だから安い、と FAQ List に書いてあった。ええっ、そんな Gift Certificate なんてあるの? と、注文する前はまた疑心暗鬼になったんですが、どうも本当らしい。もし何かの事情で24時間以内に Redeem できなかった場合は、メールで相談してくれ、だそうな。ひー。
んで、支払いしてから数時間でメールが送られてきて(FAQ List によれば概ね6時間以内だそうな)、それも含めて24時間以内に Redeem しなきゃいけないのって、結構タイトだわな。ここは注意すべき。
というわけで、こんだけ宣伝してあげたんだからお礼に $100 の Gift Certificate 送ってきてくれるぐらいしても罰当たらないぢゃないかと思った ＞ iTunes Gift Card Store
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年9月28日 14時53分
WordPress 用 XCache 新ドライバ
WordPress を 2.5 にしてから XCache による Object Cache の挙動がおかしい問題が発生していて、具体的には以下の二つ。
- Dashboard で Spam を削除しても Spam 通数の数字が変わらない
- 記事をポストすると、wp_post テーブルの post_date_gmt カラムに投稿日時が入らず、atom フィード上の投稿日時が酷いことになる
他にも細々したのが出てたけど気付いてないだけかもしれん。
今月に入って、Geek Rumbling で新しい XCache ドライバが発表されて、ようやく謎が解けました。
WordPress 2.5 から、Object Cache の API が新しくなり、global groups と non-persistent groups の二種類のキャッシュの区分けができたそうな。ちょ、そんな大切なこと、ちゃんとドキュメントしといてくれよ。そりゃ Trac を全部読んでればわかったかもしれんけどさあ。すまんが私は最近忙しいのだ (主に Twitter に)。
そんなこんなで、Geek Rumbling の Douglas Campbell が新API対応の新しい XCache ドライバをリリースしてます。
先日試したときは、同一サーバ上で WordPress を複数インスタンス起動している際に、両方のキャッシュが混じる、という困ったバグがありました。これは、自分がどのインスタンスで動いているかを識別する際に get_option(’siteurl’) で URL を取って来てプレフィクスとするが、実は 2.5 以降の WordPress では get_option 自身もキャッシュされてしまうつう問題があり、そのために発生していたようです。9/9付のコメントで「これから直す」と言っていたんで、そろそろ直る頃か。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年9月11日 20時19分
サーバ更改
ようやくながら *.rauru-block.org サーバを、ハード/ソフト合わせて更改しました。速くなったぜー。
| 更改前 | 更改後 | |
|---|---|---|
| CPU | Pentium 4 (Tualatin) 1.7GHz | Core2Duo E6450 2.13GHz |
| マザーボード | ASUS P4B-MX | ECS GF7100PVT-M3 |
| メモリ | 1Gbyte | 2Gbyte |
| HDD | ATA | SATA |
| ファイルシステム | ReiserFS | JFS |
| OS | Debian Lenny | Debian Sid |
Sid なのでコケたらすまん。まあ一昔前と違って最近は Sid に流れてくるものもそうそうヤバいものは無くなってきたけど (experimental もできたし)。
ワンルームの居室内で24時間稼動なんでファンレス仕様なんですが、でっかいヒートシンク (Scythe の Ninja) つけてCPU温度30度で安定してます。Core2Duo 素晴らしいな。当初予定してた Pentium 4 Northwood 3G だと50度ぐらい行ってただろうからなー。
入れ替え工程はこんな感じでした。
- Lenny 上で SATAやらJFSやらを組み込んで kernel 再構築
- マザーボード入れ替えて、Lenny の HDD をそのままつないで立ち上げ
- Windows機として使用中の Core2Duo E6800 マシンに新HDD(SATA)をつなげて Sid を新規インストール (Lenny をインストールして Sid にバージョンアップ)
- 新HDDをつないで、Lenny のシステムから /usr/local や /etc 以下の必要なとこをコピー
- 新HDDから Sid としてブート、設定が足りてないとこをちまちま修正
NIC/PPP, bind9, postfix, apache, php については /etc 以下の設定ファイルのコピーだけでほぼ問題無く移行できました。実は apache でなんか warning が出てるんだが、とりあえず動いてるので、あとで直す。
当初は XFS で行く計画だったんですが、Lenny のインストーラが XFS だと grub をインストールできないとかほざくので、面倒になって JFS にしました。しかし8年前の時点で ReiserFS を選んだ私の判断は全くあれぢゃった。
X11をゼロからインストールするのは3年ぶりぐらいだったんですが、昔に比べて楽になってるなー。初めて Locale を ja_JP.UTF-8 にしてみたけど、まるで問題無い。
あとやることは、Sid 上で Core2Duo 最適化した kernel 作って置き換えぢゃな。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年9月8日 14時49分
プライバシーと空気
Google Street View の日本でのサービス開始を発端としてプライバシーの議論が俄かに活発になっているようで、ultraviolet もはてな日記の方に 記事 を書いていた。プライバシーが幻想に過ぎないという点には私も賛成だが、ultraviolet が言うように実害さえ取り除けばプライバシーの無い社会が日本で受け入れられるかと言うと、そうでもないように思う。
Google Street View への反発を「気持ち悪さ」と言った気分の問題として捉える意見も見られるが、実際にはもう少し込み入っている。ここでは「空気」の概念に当てはめて考えてみる。
山本七平は今日では主に偽ユダヤ人として知られているが、彼は 「空気」の研究 の中で、日本を「虚構の中に真実を求める社会」と総括している。これは日本社会における「空気」を考える上で押さえておかねばならない視点だろう。
もちろん虚構の物語によって社会が支えられるという話は日本社会だけの特性ではない。真に本質的な違いは、虚構の維持方法にある。
他の文化圏では、虚構を維持するために極めて大きなコストが費やされている。例えばアメリカ人が「強いアメリカ」という虚構を維持するためにどれだけのコストを払っているか考えてみるといい。虚構が時代遅れとなった場合でも、多大なコストを費やしている社会構造があるため、すぐに方向転換することがなかなかできない。大英帝国のようにゆっくり没落していくことになる。
これに対して日本社会では、虚構を維持するコストが極めて安い。しかも、今まで依拠してきた虚構がダメとなった場合でも、いとも簡単に別の虚構へと乗り換えることができる。その低コストを実現している秘密が「空気」である。
日本では、どう考えても無理があるというような虚構でも、皆が「見て見ぬふりをする」ことで虚構が維持される。その維持のために、「それは虚構だ」と指摘するような者を「空気を読めないやつ」として排除する機構が働いている。
そしてこの空気は、何かきっかけがありさえすれば即座に一変する。明治維新や戦後復興に成功したのもそのお陰だろう。ただし空気の変化には、現実としてのきっかけが必要である。きっかけとは多くの場合「痛い目に遭う」ことを指す。黒船や敗戦などがそれに該当する。痛い目に遭う前に「このままだと絶対ダメになる」と論理で説明したところで、それによって日本人の空気が変わることは無い。
このように日本社会には空気によって維持される虚構が存在しているわけだが、虚構だけで生きていけるほど現実世界が甘くないこともまた事実である。そのため日本社会は、建前と本音という二重構造を用意し、建前として虚構を維持する一方で、本音によって現実への対処を行っている。あからさまに本音を口に出すと虚構を崩してしまうため、日本人は本音をはっきり口に出すことを好まない。そこで、相手の建前の言から行間を読み取って本音としてうまく対処する(ただし対処する側も表向きは建前を通し続ける)ことが日本人には求められる。これも「空気を読む」と言われる行為の一つである。
日本人にとってのプライバシーも、こうした「虚構」の一つだと考えられる。例えプライバシーが失われることによる実害が全て解決したとしても、「プライバシーが保たれた安心な暮らし」という虚構を崩されることが日本人心理にとって最大の問題となる。Google Street View が嫌われるのは、それが「虚構を壊そうとする空気を読めないやつ」であるからという面が強い。そのように考えると、他の面でセキュリティ意識の低い人たちでも Google Street View について特別に問題視する理由が説明できる。例えばSSLのオレオレ証明書などは安心についての虚構を壊さないのだ (このことから私は日本におけるセキュリティ啓蒙活動が今後もあまり成果を上げられないだろうと予想している)。
そしてこのプライバシーという虚構を守る空気は、現実に日本人が痛い目に遭わない限り変化しないだろうと私は予想する。Google Street View が便利だからというだけでは、空気の相転移を起こすのに不足だろう。
おそらく日本人は、Google Street View に対しても、建前と本音の使い分けで対応していくことになるだろう。建前としてセキュリティという幻想はあくまで守られなければならないし、Google Street View も好ましいものとは認められない。しかし、具体的にどういう形でかはわからないが、その幻想の例外として許容される本音としての領域で、Google Street View のようなサービスが現実に使われることになる。そして、その二重構造の無理が蓄積して行って限界に達したとき、空気の相転移が起こり、日本人のプライバシー観も一変する。私はこのように予想している。
The Transparent Society の話は、これは空気とは全く独立して非常に大きな話となるので、稿を改めて書きたい。
作者: duke http://www.rauru-block.org/mediawiki/index.php/User:Duke
更新日:2008年8月15日 8時7分
RPGとフレームワーク
妄想科學日報の TRPG判定処理の問題として を読んで考えたこと。最近 RPG (日本ではテーブルトークRPGという和製英語で呼ばれるアレ) からすっかり遠ざかっているんだけど、この辺りの問題は10年前からいろいろ言われておったよ。
思うんだけど、RPG のルールって、サブルーチン的ライブラリの集合体みたいなもんであって、フレームワークが普及する以前のプログラミングを見てるようぢゃよねえ。個々の部品はあるけど、全体図が無い。「RPGのルール==判定ルール」と思われているところからして、アレだと思う。ブックマークコメントで指摘されてるトーキョーNOVAとか私も結構好きなんだけど、やっぱり部品ライブラリの域を出てないかなと。
大抵のゲームマスターにとって全体図は「ストーリー」なんだと思われる。自分で作ったストーリーに、細部に部品として判定ルールを当てはめて、それでゲームシナリオに仕立ててる。なんだが、ゲームマスターの用意するストーリーが、ゲームとして楽しめるものになってるかってえと、この二つはなかなかに相性が悪い。昔よく言われてた「吟遊詩人マスター」なんかだと、本当はゲーム性なんて不要なんだけどRPGってサイコロ振らせなきゃプレイヤーが満足しないから仕方なく付け足しとこうか?みたいな感があった。最近はさすがにそういうのは見なくなったけど、リソース管理とかの戦略的面白さまで織り込んだ全体図を描けるゲームマスターはあんまりいない。
私はやっぱ、ゲーム性の高い全体図をルールによるフレームワークとして用意する方が良いと思うなあ。全体図はルールによって最初から与えられてて、ゲームマスターは細部をプラグインとして実装することで創造性を発揮するってやり方。
その場合のルールってのは「判定」のためのルールじゃなくなる。むしろ個々の判定のやり方はゲームマスターが自分でプラグインとして(インタフェース規定に沿って)実装するのでも構わないのかもしれん。ルールが規定すべきはそこじゃなくて、ゲーム全体の流れとか、リソース管理のあり方とかの方。そしてプレイヤーにとっても、個々の判定や戦闘でサイコロ振って一喜一憂するところにゲーム性を見出すんじゃなくて、フレームワークとしての大きなゲームを操ることを楽しんでもらう。例えばそうだな、プレイヤーにはそれぞれ大きな戦略目標があって、一回の判定で失敗しても(あるいは戦闘で負けても) 実はそこでリソース温存できたことで戦略目標実現に近づいてるんだ、的な、そういう大きな枠組みがルールとして提供されるようなゲームが好きぢゃな。
あと「成功判定」て言葉に囚われすぎだって話も10年前からあった。1回の行為について成功か失敗かを判定するルールがあっても、戦闘以外のシーンだとプレイヤーが成功するまで繰り返すってことが往々にしてある。だから実行できる回数の制限とか失敗したときのペナルティとかが無いといかん、ってとこまでは誰でも思いつくけど、それならいっそ、成功すること前提で「成功するまでにどれだけのリソースを消費したか」を判定するようなルールの方がいいんぢゃね? 消費リソースが手持ち量を上回ったら失敗、とか。リソースには例えば「時間」も含まれるし、定量的なリソースでなくても例えば「状態」「人間関係」みたいな定性的なリソースもありえる。戦闘も「勝つまでにHPをいくら消費するか」の判定にしてもいいかもしれん。みたいな話まであったように記憶してるんだけど、その辺の話がその後進んだのかについてはようわからん。まあともかく、RPG のプレイにおいて真に重要なのは、「個々の行為が成功するか失敗するか」では無いと思うんぢゃよ。
Postedit on 2008/08/15
補足。トーキョーNOVAやエンゼルギアはフレームワークではありません。単にリソース管理が行為判定と並んで個別部品ライブラリとして用意されてるだけです。ヒーローポイントとかのリソース管理があればフレームワークになるわけじゃない。そんなゲームは昔からいくらでもある。
じゃあどういうゲームならフレームワークになるのかってえと、これは実例が無いので説明が難しいな。私も概念としてしか頭に浮かんでない。無理な例えをするなら、今の RPG てのは CGI.pm で、フレームワークの用意された RPG てのは Catalyst だと。もちろんゲームマスターもハリウッドの原則に従ってルールフレームワークから呼び出される。ほんとにそんなんが実現可能なのかどうかは、私もよくわからんのだけど。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年8月15日 4時12分
ポジティブなシングルのための
STOP! STD の話をはてな日記に書いたついでに digg のコメント読んでてその中に出てきたんで初めて知ったんですが、アメリカには STDMatch っつうサービスがあるんですね。最初てっきりジョークサイトだと思い込んで、冗談にしてはえらく気合入ってるなとか思ってたんですが、実は真面目なサービスだった。
どういうサービスかと言うと、男女の出会いを取り持つオンラインデートサイトなんですが(身元証明の登録が義務付けられてたりするので日本で言えば出会い系サイトよりも結婚相談所サービスに近い)、普通のマッチングサイトと違って、ポジティブなシングルのための出会い系サービスなんだそうです。この場合のポジティブてのは、HIVポジティブとかそういう意味ね。性感染症検査が陽性の人。
えええええええーって思うよね。でも確かに理屈はそれなりに通ってるんですよ。
例えば性器ヘルペスって、一度感染すると完全には治らず、非感染者との性交渉では相手に感染させてしまうリスクが若干ながら一生残り続けます。普段は感染力無いんだけど、時々ウィルスが分泌されて感染力持つことがあるから。しかもヘルペスウィルスは感染力が強いので、コンドームを使っても完全には防げない。なのでこの病気にかかったら、非感染者との性行為は慎重にしなきゃいかんてことになります。
でも、相手も同じヘルペス持ちだったらいいじゃーん? もともと感染してるんだからもうそれ以上悪くならないじゃーん? てな話が出てくるわけですよ。まあ確かにそうだな。でもヘルペス感染者は自分が感染してることをおおっぴらにしないので、感染者を探すのは恐ろしく難しい。
そこで STDmatch の登場となります。実名は伏せたままで、自分の感染してる病名だけは明かして、同じ病気の相手を探せる、てのが STDMatch の売りです。確かに Internet の特性をフルに生かしたサービスだわなあ。
この手のSTD感染者へのデートサイトてのは STDMatch だけでなく、他にもいろいろあるそうです。昨年春には CNN が STD感染者向けデートサイトが大流行 て記事を載せてます。近年アメリカ人の間ではSTD感染率が上昇してきてるんで、この手のサイトの需要が高まってると。
Cracked.com も STDmatch を紹介する記事 載せてるけど、普通のデートサイトとの違いの説明には笑った。曰く
STDMatch works like any other dating site in that everyone has an STD. The only real difference is nobody is lying about it.
STDMatch と他のデートサイトとの共通点は、ユーザがみんなSTDに感染している点だ。違うのは、STDMatch のユーザはそのことを隠さないという点だ。
わははは。しかしそれが冗談で済まない実情もあるんだろなあ。
しかし実際どうよ。ヘルペスならまだいいけど、例えばHPVとかだと、一口にHPVと言ってもその中で細かい型があって、「HPV感染者同士だから」とセックスすると新しい型のHPVをもらってリスクアップ、てなこともあり得るわな。いろいろとまずいような気もするんだが。
でも一方で、ヘルペスのような難治性STD感染者は、たとえプラトニックな関係であっても相手を見つけにくい、相手の理解が得られにくい、つう問題があります。ヘルペス感染者は、理想の相手とつきあえたとしても、「隠し通すべきか、打ち明けるべきか」ということで深く悩むんだそうです。悲しいことに、打ち明けるとたいていの相手は逃げて行ってしまう。STDに対する誤解と偏見もそれを後押しします。「STDに理解がある」と言う人は多いけれど、自分のつきあってる相手が実際にSTDだと言うことになると態度の豹変する人もやっぱり多い。
一方でアメリカのデートサイトてのは、日本の出会い系サイトとは違って、セックスだけが目的とは限らない。同好の士として語り合える友人としてのお付き合いとかも dating の意味には含まれます。そういう形での心理的・社会的サポート機能も、こういったSTD感染者用デートサイトは果たしているようです。CNNの記事などを読むと、セックスできるかどうかよりも「STDのことに真に理解のある仲間」と交流できることが利用者にとって一番嬉しいことらしい。
なんとも考えさせられる話ぢゃよなあ。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年8月7日 20時42分
GreasePocket
私は基本的に iPhone に興味が無いのであんまそういう動向にも気を配って無いんですけど、そういう私でもこれは興味を引かれる話だなあ。Firefox の GreaseMonkey 相当のモノを iPhone Safari 用に作ろうというプロジェクトがあるんだそおです。GreasePocket てのがそのプロジェクト名。GreasePocket 開発 blog もある。ReadWriteWeb で読んで知りました。
まだ開発が始まって数日目なので、Alpha というかコンセプト検証段階みたいです。作ってるのは Ishan Anand という人。先週末の iPhone Devcamp でスタートしたっぽい。
実用的なところまで開発が進めば、GreaseMonkey と似たようなことが iPhone でもできるわけで、私が使ってるとこだと Autopagerize みたいなのが動くわけだな。もちろん、敢えて LDRize を iPhone に移植したいとゆう人がいればそれも構わんぞよ。
Anand の話によると、現在直面してる課題はセキュリティだそうな。普通のページに埋め込まれた javascript と GreasePocket スクリプトをきちんと区別して動かすのが難しいらしい。
例えば、GreasePocket スクリプトから iPhone 内蔵 GPS の情報を取得できると、いかにも便利そうですよね。GreaseMonkey よりも便利になるかもしらん。なので GreasePocket をそういう作りにしたとする。そしたら、同じようにして GPS にアクセスする Javascript コードを埋め込んだページを作っておいといて、誰かが迂闊にそのページを踏んだら位置情報が勝手に送信されてしまう、とかそういうこともできちゃうかもしれない。
この問題を解決できないと結構悲しいことになってしまうので、現在なんとかする方法を募集中とのこと。
あと、Apple がこういう GreasePocket を許容するかね、て話はあります。
ReadWriteWeb の Marshall Kirkpatrick はそのことに結構楽天的で、それどころか上記のセキュリティ問題も Apple がファームアップデートで対応してくれたりせんだろかみたいなこと書いてますけど、どうぢゃろうのう。
GreasePocket さえ入れればあとは勝手に好きなスクリプト入れられる、みたいなフリーダムな体制って、Jobs 的に NG なんじゃないかつう気もします。やつはユーザを縛りたがるかんな。GreasePocket スクリプトも Apple で検閲した上で iPhone App Store で配布、みたいな折衷案のが現実的かもしらん。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年8月5日 20時24分
WordPressオタが非WordPressオタの彼女にplugin世界を軽く紹介するための10本
出遅れ感と言うより今更感が濃厚に漂っておるけど、ほれ、お約束だし。元ネタは アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本 のアレね。ネタ性を優先したので、WordPress かどうかに関係ない話題の方が中心になってる気もしなくもない。
——–
まあ、どのくらいの数の WordPress オタがそういう彼女をゲットできるかは別にして、「WordPress オタではまったくないんだが、しかし自分の WordPress 趣味を肯定的に黙認してくれて、その上で全く知らない WordPress の世界とはなんなのか、ちょっとだけ好奇心持ってる」ような、WordPress オタの都合のいい妄想の中に出てきそうな彼女に、WordPress のことを紹介するために見せるべき plugin 10本を選んでみたいのだけれど。
(要は「脱オタクファッションガイド」の正反対版だな。彼女に WordPress を布教するのではなく、相互XFNリンクの入口として)
あくまで「入口」なので、PHP の入れ直しを伴う要 PHP5 の plugin は避けたい。
できれば、PEAR が必要なものも避けたい。
あと、いくら WordPress 的といっても SQL Injection を感じすぎるものは避けたい。
オールドPHPファンが『RegisterGlobal』は外せないと言っても、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
Blog知識はいわゆる「レンタルブログ」的なものを除けば、MovableType程度はインストールしている
MySQL 5.* 度も低いが、頭はけっこう UTF-8
という条件で。
まずは俺的に。出した順番は実質的には意味がない。
All in One SEO Pack
まあ、いきなりここかよとも思うけれど、「Blog名が記事タイトルの前」を濃縮しきっていて、「Blog名が記事タイトルの後」を決定づけたという点では外せないんだよなあ。2.6コンパチだし。
ただ、ここで SEO 全開にしてしまうと、彼女との関係が崩れるかも。
この設定項目過多な plugin について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の設定項目を彼女に伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
ShareThis, Sociable
アレって典型的な「WordPress オタが考えるソーシャルニュース系サイトに受け入れられそうなplugin (そう WordPress オタが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「WordPress 使いとしてはこの二つは“リンクスパム”としていいと思うんだけど、率直に言ってどう？」って。
WP Super Cache
ある種の WordPress オタが持ってるパフォーマンスへの憧憬と、Doncha 製作のオタ的な digg されることへのこだわりを彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも MovableType 的な
「mod_rewrite での静的HTMLファイルに直リダイレクト」を体現する Super Cache
「いったん PHP を動かしてキャッシュファイルを読み込む」を体現する WP Cache
の2モードをはじめとして、オタ好きのするオプションを管理画面にちりばめているのが、紹介してみたい理由。
Gengo
たぶんこれを見た彼女は「『言語』だよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜のpluginがその後続いていないこと、これが非英語圏ではそこそこ人気になったこと、非英語圏にならって、それが日本に輸入されてもおかしくはなさそうなのに、日本国内では、なんかを非マルチリンガル彼女と話してみたいかな、という妄想的願望。
Woopra
「やっぱり WordPress はアクセス解析したがる人のためのものだよね」という話になったときに、そこで選ぶのは Google Analytics でもいいのだけれど、そこでこっちを選んだのは、このサービスにかける Layered Technology の思いが好きだから
断腸の思いで削りに削ってそれでもクライアントに JavaVM 必須、っていう要求条件が、どうしても俺の心をつかんでしまうのは、その「専用クライアントアプリ」への諦めきれなさがいかにもオタ的だなあと思えてしまうから
その要求条件を俺自身は過大とは思わないし、もう削れないだろうとは思うけれど、一方でこれが Google だったらきっちり AJAX にしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけて専用クライアントアプリを作ってしまう、というあたり、どうしても「自分のアプリケーションを形作ってきたプラットフォームが捨てられないオタク」としては、たとえ Layered Technology がそういう会社でなかったとしても、親近感を禁じ得ない。サービス自体の高評価と合わせて、そんなことを彼女に話してみたい。
SSL Admin
今のレンタルサーバで SSL でログインしたことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
高木浩光よりも前の段階で、オレオレ証明書とか期限切れ証明書とかはこの plugin で頂点に達していたとも言えて、こういうクオリティのセキュリティが WordPress でこの時代に行われてたんだよ、というのは、別に俺自身がなんらそこに貢献してなくとも、なんとなく WordPress 好きとしては不思議に誇らしいし、いわゆる FireFox 3 でしか SSL を知らない彼女には見せてあげたいなと思う。
AJAXed Wordpress
AJAX の「UI」あるいは「エクスペリエンス」を Javascript 使いとして教えたい、というお節介焼きから見せる、ということではなくて。
「AJAX って名前がかっこいい」的な感覚がオタには共通してあるのかなということを感じていて、だからこそ eyeOS は AJAX 以外ではあり得なかったとも思う。
「Buzzwordになりさえすればいい」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の源は AJAX にあったんじゃないか、という、そんな理屈はかけらも口にせずに、単純に楽しんでもらえるかどうかを見てみたい。
MyCaptcha
これは Captcha だよなあ。認証が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういうジュベナイル小説風味の文字をこういうかたちで画像化して、それが彼女に読めるか、Spam を弾けるか、というのを見てみたい。
WP-Amazon
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的に WP-Amazon を選んだ。
SEO から始まってアフィリエイトで終わるのもそれなりに収まりはいいだろうし、amazon 以降のアサマシ系の先駆けとなった plugin でもあるし、紹介する価値はあるのだろうけど、もっと他にいい plugin がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら
教えてください。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年8月4日 10時14分
PlayCrafter
自分でもゲーム作ってみてから書こうと思ったんだけど、疲労が激しくて、アカウント作ったところで力尽きたので、その程度の紹介ですが書きます。ブラウザ上の簡単操作でゲームを作って、それをサイト上で公開・共有できるサイト、PlayCrafter てのがオープンしたそおです。Read/WriteWeb で知ったのだった。
どんな操作でゲームを作るのかってデモビデオもあって、こんな感じ。
ゲーム自体はカジュアルゲームの部類で、そんなに凝ったものは作れない感じです。何種類かあるテンプレートを選んで、背景画像を選んで、パラメタをいくつか決めて、キャラクタとかを選んで配置するようなもの。まあ所詮ブラウザベースのゲームぢゃしね。
しかしこのサイト、凝ったゲームを作るというよりは、自作ゲームを媒介とする SNS としての位置づけが強いと見た。他のユーザが作ったゲームにコメントや Hollers (はてなスターや拍手みたいなもんだと思う) を付けられて、また他のユーザを Follow することができて、Follow してるユーザの新作ゲームが表示されたりとか、そういう SNS な機能がやたらと充実してます。つまり、いかにも Web 2.0 的ってことだな。
あと、My Revenue Sharing という謎のメニューもあります。どうも、自作ゲームがアクセスを集めれば、サイトの広告収入の一部がリベニューシェアとして支払われるらしい。日本にまで送金してくれるのかどうかは謎ですが。
昨日書いた プログラム言語が難しい という話も、こういうテンプレート込みのツールとしてなら解決策の一つになるのかもしれんね。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月23日 18時49分
椅子が無いならなぜ大工用具を使わないんでしょう
マリーアントワネットがあれなら海原雄山でどうだ。「店主、椅子とはそもそも何なのだ?」
私にとってのプログラムの難しさというのは、椅子を作りたいのに、丸太と大工道具一式を渡されて、道具の説明を一通りされて「じゃあ後は頑張ってね」と言われる感じです。欲しいのは椅子なのに、道具の使い方とか使い分けとか覚えないとダメというのは結構苦痛です。
思ったんですが、椅子の形や仕様が最初から決まってて、その通りの椅子を作るだけだったら、簡単なんですよ。もちろん、色とか大きさとかはメニューの中からお選びいただけます。
一方プログラミングを楽しむ習性のある人って、自分の作りたいもののイメージ自体をプログラムしながら固めてくんじゃないかな。作ってくうちに、自分が作りたかったのは実は椅子じゃなくて梯子だったと判明したり。たいていのプログラミング言語は、そういう人のために作られてる。
プログラミングに縁の無い人って、「プログラム言語が難しい」からプログラミングができないと思ってますよね。確かにとっつき難いのは事実なんですが、でも真の難しさはそこじゃないと思う。プログラミングてのは、「こんなのが欲しい」の「こんなの」つう漠然としたイメージを、論理的に厳密な動作シーケンスに落とし込んでいく作業なんです。漠然としたイメージ思い浮かべてる間だったら考えなくて良かったことを、ちゃんと考えて一つ一つ決めてかなきゃいけない。ウォーターフォール型の開発では、最初に要求獲得して仕様書に落とします。最近の私みたいな趣味のプログラマだと、そんなん面倒なので、スパイラル開発と称してコード書きながらイメージを固めていきます。やー本当はテストコード先に書くべきだと思うんだけどさー。
ちょっと前に duke がこんな話を書いてたんですが、
コントロールフリーク (Rauru Blog)
実際のところ、コントロールフリーク的性格を持たない人が他人に仕事を依頼する際、依頼の時点では「自分が何を求めているか」もあまり明確ではないことが多々ある。そのような場合、欧米人であれば依頼内容についてのディスカッションを通じて、日本人であれば依頼された側が空気を読んで、何が求められているかを明確化する。いずれにせよ、依頼される側にもそれなりの対人関係スキルが必要となる。
ところが今日の機械はそのようなスキルを持っていない。明確な指示や操作が必要となり、それには過程や手段についての知識が前提となる。コントロールフリーク的性格を持たない人にとって、これは苦痛である。コントロールフリーク的性格を持たない人にとって望ましい機械とは、過程や手段について一切知識が無くても、ボタンを1個押しさえすれば、自分の意図を汲み取って万事良しなにやってくれるようなものである。
たぶん、多くの人が実際に必要としてるのはプログラム言語じゃないんだと思う。人力検索はてなで「こんなのが欲しいんだけどそれを実現してくれる何かを教えて」と聞くと、別のはてなーが「こんなの」を空気読んで適切に判断してくれて、出来合いのものの中から一番近いものを「どうぞ」って教えてあげて、それはアプリケーションかもしれないし何かのプラグインかもしれないけど、単一の目的だけ実現してくれるような何かで、それ入れて最低限(色とか)カスタマイズすれば動く。そんな仕組みとかコミュニティみたいなのとかが求められてるんだと思う。例えば WordPress が 問題ありまくりなコード にも関わらず大繁栄してるのも、導入し易い Theme や Plugin が無駄に大量に溢れてるコミュニティのお陰なんだろうと思っとります。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月24日 15時33分
WordPress のコードとしての問題
今日はプログラミングのお話。この Rauru Blog で使っている WordPress とゆう Blog プラットフォームについては私も3年前に使い始めてから愛憎半ばするものがあるわけですが、先週末は WordPress について「確かに WordPress には問題が多いのを否定できんのう」と思う文章をいろいろ見かけたので(主にotsuneさん経由)、言及しておこう。
まず、WordPress が コボラライゼーション の実例になりかけていることの警鐘。
僕は Ben が WordPress を使ってることを知った。というわけで、僕はダウンロードしてそのソースにざっと目を通してみたんだ。そしたらすぐに気がついたんだ。
- PHP 5 は使われていない
- 関数名のプリフィックスで同じような関数がまとめられていて、クラスに隠蔽されていない
- bound parameters が SQL 文で使われていない
- Model, View, Controller の間の区別がそれほどない
- XML の生成が print() や echo() 経由で行われていて、 PHP の XML クラスや関数を使っていない
これらの殆どが即座に警告を引き起こした。 SQL bound parameters がの欠落は SQL インジェクションへの防御が難しくなるって事だ。 MVC の欠落は XSS の可能性を増加させる。クラスを使わないって事は、 API を理解しづらくなるって事だ。 PHP 5 の可視範囲のキーワード (public, protected, private)を使わないって事は、将来におけるコードの対応を確実にするのが難しくなるってことだ。
National Vulnerability Database で WordPress のおおまかな経緯について疑惑を強めたところで、僕はこいつにはチャンスを与えないことを決めた。このソフトウェアは簡単に使えるし多分きちんと動くだろうけど、僕はセキュリティを運否天賦に委ねる気には全くなれない。そのうえ、PHP 伝道師としては三年に渡る PHP の発展を利用していないソフトウェアを自分のサイトに置くべきじゃないだろう。
しかしなぜ WordPress がコボラライズしているのか。一つ目には PHP4 のサポートを落とすわけにはいかん っつう WordPress 側の姿勢があります。WordPress は PHP4 (4.3以降) でも動かにゃならんのだそおです。Ryan Boren が去年 WordPress and PHP 5 つう記事でそれを明言してる。互換性の呪縛ぢゃよのう。落として欲しいんだがなあ…
そしてもう一つ。これも根っこが一緒っちゃあ一緒なんですが、カジュアルな開発者への訴求力
つう点があります。ここで言うカジュアルな開発者てのは、クラス/オブジェクトを扱えない開発者 ならびに セキュリティ意識の低い開発者 を足して二で割ったような意味だと思ってください。WordPress が MovableType を超える人気を得た要因には、これもでかかったと私は思ってます。つまりこういう話。
WordPressに見るオープンソースWebアプリに向いた設計とは (pot)
とりあえずタイトルに対する結論から列挙しますと、（bbPressですが）
- 言語はPHPしかありえない
- インストールに黒い画面（ターミナル）を使う必要があってはいけない
- FrontControllerを使わない。（URL見たまんまのファイルがあること）
- クラスを使わない。functions.phpとかにbb_xxxxとかいう関数を列挙する。
- テンプレート言語はPHP。theme/default/以下とかに置いて、前述のURL見たまんまファイルと同名にする。（register.phpとか）
- ディレクトリ構造はフラットに近くする
- gettextを使っておくと自然と翻訳してくれる人が現れる
作者はとにかく「サードパーティー開発者」と「ユーザー」に奉仕して、DRYに反していても誰にでもわかりやすいまま頑張ってスパゲッティにならないようにします。
より多くの「サードパーティー開発者」に気に入ってもらえるようにすることがひいてはプラグインの増加、ソフト自身の価値向上につながるんですね。
このサードパーティ開発者/ユーザと呼ばれてる人たちですが、WordPress の開発コミュニティにはだいたい以下の3種類の人がいます。ただしこの3種類は綺麗には分かれていません。境界が曖昧で、それが開発者を集めるには役に立っているんですが、同時に問題も引き起こしてると思う。
- Theme 開発者
- Plugin 開発者
- コア開発者
WordPress における Theme てのは MovableType におけるテンプレートに相当するものです。ただし、MovableType のテンプレートはほんとにテンプレートですが、WordPress の Theme は PHP 実行ファイルです。Theme ファイルが本当に PHP として実行されます。なので、悪質なコードが埋め込まれた Theme を WordPress にインストールすると、それが PHP (たいてい Apache) の権限で実行されるため、ろくでもないことになります。
しかし WordPress の Theme 作成に関するドキュメントは、そのことについて開発者の注意を喚起する書き方になってるとは言いがたい。逆に、そういう意識が無いままでも — 極端な話 PHP について知識が無くても — Theme ファイルを書けるよう 親切な 書き方になってます。PHP の関数を テンプレートタグ と呼んでるのもその一例です。例えば <?php bloginfo('name'); ?> てのは Blog 名を表示するタグとされてます。PHP のことを何も知らなくても、Theme ファイルにこの呪文のようなタグを書けば blog 名が表示されるんです。なんてわかりやすいんでしょう!
んで、これで WordPress のコード書きに慣れた人が PHP というものを理解してくると、次は plugin を書くようになるんですよ。え? そんなん危険だろって? いや、Theme でも PHP のコード書く以上何でもできちゃうんで、plugin だけが特に危険ってことは無いんぢゃよー。
WordPress の plugin は hook と呼ばれる callback な API を使います。WordPress 本体コアのコードには、いたるところに apply_filter() とか do_action() とかいった関数が埋め込まれてます。それぞれに do_action('save_post') みたいな感じでフック名が引数として埋め込まれてます。PHPの実行がこの行に差し掛かると、同じフック名で登録された callback 関数を呼ぶんです。plugin 側では起動時に add_filter() とか add_action() とか言った関数を使って、フック名と callback 先の関数名を指定して登録しときます。do_action の場合は引数無しで呼ばれるので、やりたいことをやる。do_filter の場合は引数で文字列が渡されるのでそれを書き換えて返す、要するに文字列フィルタです。文字列を書き換える方法さえ知ってれば、クラスとかオブジェクトについて何もわかってなくても大丈夫。preg_replace() 使えるような開発者は御の字ぢゃ。たいていの plugin は単に受け取った文字列の前か後に何ぞ連結して返してるだけだぞ。
plugin 側が WordPress 本体コアの情報を参照しなきゃいかん場合、グローバル変数およびグローバル関数で情報を取ってきます。グローバル関数の方は、先に紹介した Theme 用のタグとよく似ているため(例えばblog名をprintするのはbloginfo('name')で、変数に代入するのはget_bloginfo('name'))、Theme 作成に慣れた人だとわかりやすい仕組みなのだな。クラスやオブジェクトについて何もわかってなくても大丈夫。
つうわけで、あれだ。この WordPress の plugin コードに、変数や関数の隠蔽によるメンテナンス性向上は決してない! と思っていただこうッ! いやすまん嘘だ。わかってる開発者はせめて自分のコードだけでもそれなりにしようとして、自分の plugin の中だけクラス分けしてコード書いてはいるよ。この辺の恨みつらみについては コードが汚い と文句ぶー垂れたことがある。
DBのクエリで bound parameter 使わず mysql_query() に SQL 文をパラメタ込みの文字列として直に流し込んでるのも、実はこの plugin API のためなんすよ。SQL文を filter フックで plugin が書き換えられるようになってるんです。where 句の検索条件を plugin でいくらでも付け加えられて、それもフィルタでの文字列連結だけで簡単にできる。めちゃくちゃ面白い plugin を簡単に書けるひみつもそこにあるのだった。それは当然、GET引数をそのまま文字列として SQL に入れ込むのもアリ。その場合 GET引数を サニタイズ する責任は plugin 側にあります。
なので WordPress では、plugin のせいで SQL Injection 起こすっつう例が過去けっこーありました。今後もあるだろうなあ…
コア開発者ともなるとさすがにそれなりなんですが、上記のような Theme / Plugin 開発者にやさしい姿勢は維持しないといかんので、今のような状況になっちょるわけですよ。何とかして欲しいとは私も思う。
コア開発チームは、このカジュアル開発者にやさしい姿勢は維持しつつ、いかにも穴が開きそうなところはなんとか手を打つっつう、かなーり難しいバランス取りを頑張ってるようです。まあ、応援するしかない。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月14日 12時36分
ミサイルの水増し
昨日はイランが再びミサイル試射実験を行ったため、ドルが急落したりして大変だったようです。
このミサイル試射実験の写真をイラン軍当局がWWWサイトに掲載し、それをAFP通信社が世界中に配信しておりました。Finantial Times や BBC News, Yahoo! News その他がこぞってこの写真を掲載してた様子です。
ところがこの写真、New York Times がよくよく分析してみたところ、なんと Photoshop 加工によりミサイルの数が1基水増しされてた!!
同一写真内でコピー&ペーストして、ミサイルを捏造していたよおです。黄色の枠でかこったところを赤の枠のところにコピーした模様。言われてみると煙の形までしっかり同じだな。
しかもそのニュースが伝わるか伝わらないかのうちに、イラン軍当局、WWWサイトの写真をしれっとミサイルの数が1基少ないバージョンに差し替えてしまいました。たぶんこっちが本物で、それを加工して1基捏造したんだな。そのため、AFP通信社も「これはディジタル修正された写真である」と認めて写真の配信を撤回した模様です。
イラン軍、やるな。合成の腕もなかなかたいしたものぢゃ。
しかしそんなに1基でも多く見せることにこだわりたかったんかのう… いや待てよ、一番手前のロンチャーって、ひょっとして不発? とするとまさか、不発でしたってバレると担当者が銃殺とかになるんで責任逃れで捏造した?
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月10日 16時47分
Diebold のポスター
Tumblr ったけどあんまり reblog 数を稼げなかったネタを再利用する試み。
アメリカに Diebold っつう電子機器メーカーがあります。主に ATM とか作ってる。この子会社で Diebold Election Systems っつう会社があり、こっちは電子投票システムを専門に作ってました。日本の選挙って紙に書いて投票しますけど、アメリカではこの Diebold のタッチパネル式投票機を使って投票するのが流行りだったんですよ。てのもほら、2000年の大統領選挙で開票が大問題になったでそ。電子投票なら問題無いはずだと Diebold が売り込んで、2002年頃から全米各地で採用になった。
ところがその後この会社がスキャンダルまみれ。まずは2002年、この会社の副社長が、自分で書いた ATM のプログラムにバックドアを仕掛けていたことが判明し、訴えられます。
次は2003年、社長の Walden O’Dell が、この人はブッシュ大統領の熱烈な支持者だったんですが、共和党のお偉方に送った手紙の中で「オハイオ州がブッシュに投票することを保証する」と書いてしまったんですね。おそらく熱心に選挙応援するぜって意味だったんでしょうが、なんせ前の年にバックドア事件を起こしたばかり。たちまち「電子投票にもバックドアが仕掛けられてるんじゃないか?」と大騒ぎになりました。
そしたら、さすがにバックドアでは無かったんですが、本当にセキュリティホールが見つかってしまいます。悪意あるクラッカーが投票システムに侵入して票数を書き換えてしまう恐れがある。ちょうど2004年の大統領選の頃だったので、ますます大騒ぎになりました。Diebold がソフトウェアを秘密にしてセキュリティホールの詳細を明らかにしなかったのも火に油を注いだ。オープンソース陣営が「投票システムこそオープンソースにすべきだ」と声を大にし、その論争にレッシグまで参戦する始末。
他にも、「絶対当社製品の非を認めるな、例え本当にバグがあっても」と書いてある社内メモが流出したり、政府要人との汚職が噂されたり、まあほんとにもう何とかの総合商社って感じなのが Diebold なんですが、その会社がまだスキャンダルにまみれてなかったころに作ったポスターがこれです。スターリンが言ったとされる言葉「重要なのは誰が投票するかじゃない、だれが票を数えるかだ」を引いてきて、スターリンみたいに開票結果を人為的に操作するやつがいるといかんから正確無比な我が社の製品をお使いください、って意図のポスターです。しかしスキャンダルまみれの今となってしまっては…
他にも、チャーチルの「民主主義は最悪の政治形態だ、今まで人類に試されたあらゆる政治形態を除けばだが」を引いてきて「今や (Diebold のシステムのお陰で) 民主主義は新しく生まれ変わった!」と称するポスターとか、かなり楽しいポスターがてんこもり だったようです。スキャンダルが無ければ独創的な広告と言うことになっていたんぢゃろうが、むう、独創的なのも良し悪しぢゃのう…
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月10日 2時26分
ドライアイスと地球温暖化
id:hasenka さんとこで 二酸化炭素排出削減でドライアイスはどうなる つう疑問を読んだので、まじめに答えてみる。
「そもそもドライアイスってどうやって作るんだろう? 原料の二酸化炭素はどこからくるの?」って疑問に思ったことは無いですか?
実はドライアイスって、石油精製や製鉄の際に出る二酸化炭素を回収して作るんですよ。だから既に一度リサイクル済みなんです。
我々がドライアイスの消費を控えると、ドライアイス製造元は生産調整することになります。でも石油や鉄鋼の生産量は変わらないので、ドライアイスになるはずだった二酸化炭素が余ります。現状では、余った二酸化炭素は大気中に放出されるだけ。
同じことは炭酸飲料にも言えます。コーラに入ってる炭酸も、石油精製や製鉄の際に出る二酸化炭素をリサイクルしてるんですよ。
もし、ドライアイスの消費量が激増して、「石油精製施設や製鉄所から出る二酸化炭素だけじゃ足りなくなった、石油を燃やして二酸化炭素を作らないと!」なんてことになったら、さすがにそれはヤバいです。つうか、そんなに使うなよ。
あるいは、何か素晴らしい技術革新のお陰で「石油精製施設や製鉄所から出る二酸化炭素が激減した!」てことになったら、それもやっぱヤバいです。でもそれがあったらCO2問題って解決してるよな。
まあ、今の枠組みの中でドライアイスの消費が多少増減するぐらいだったら、それ自体が大気中の二酸化炭素量に与えるインパクトはゼロと考えていいでしょう。ドライアイス製造時に冷やすための電力は使いますが、でもそれはドライアイス以外の冷媒を使っても同じことぢゃからのう。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月8日 5時8分
Influencer 広告
slashdot.org で知ったのだが、Google が Network Node Ad Targeting と題する特許を2006年暮れに出願していたようだ。簡単に言うならば、人間関係を元に広告を打つ特許である。
Abstract は以下のように記されている。
A computer-implemented method for displaying advertisements to members of a network comprises identifying one or more communities of members, identifying one or more influencers in the one or more communities, and placing one or more advertisements at the profiles of one or more members in the identified one or more communities.
特許文体なのでこれを読んでも何の役に立つのかわかりにくいが、slashdot での議論を読んで考えるに、どうもこういうことらしい。
- どのユーザがどのコミュニティに属しているかを識別する
- そのコミュニティの面々に影響を与える重要ユーザ(Influencer)を識別する
- Influence の profile ページに集中して広告を打つことで、コミュニティ全体への広告浸透を狙う
例えば、メンバの大半が特定のジャンルの音楽を好むようなコミュニティがあり、かつそのコミュニティのリーダーと言うか影響力の強いユーザがいた場合、その影響力の強いユーザの profile ページにそのジャンルの音楽の広告を集中して表示する、といった使い方が想定されているようだ。
コミュニティの識別、コミュニティメンバの好む対象の識別、それに重要ユーザの識別は、いずれもリンクを集計することによって行うと特許中には記述されている。コミュニティの構成は絶えず変化しているため、それに追随できるアルゴリズムが必要となるが、Google お得意の Pagerank 集計のような手法で行うのだろう。
この集計のためのデータを取ってくる手法として、特許では単に WWW ページ間のリンクを取るかのような書き方がされて細部はぼかされているが、実際に行われるだろう効果的な方法はいくつも考えられる。
最も簡単なのは SNS だろう。Facebook や mixi の個人の profile ページには、友人関係のデータや興味対象について情報が詰まっている。ただし Facebook も mixi も、SNS にログインしなければそうしたデータが見えず、Googlebot で拾えない状況にある。昨年から Google は Facebook に対抗して SNS 分野に攻勢をかけつつあるが (例えば OpenSocial など)、それと符合する話である。
それと並行する話として、Googlebot で拾えるような場所に友人関係データや興味対象を書いてくれると有り難い、という話もある。XFN なら自分の友達を記述できるし、FOAF なら foaf:interest 属性などで興味の対象まで記述できる。個々のユーザがそういったものを書いておけば、Google はそれを拾ってコミュニティを識別し、Influencer を検出できるだろう。今年2月に公開された Social Graph API も、ひょっとしたらそうした研究に付随する成果なのかもしれない。
あるいは、既存のソーシャル系サービスを使うのも手である。例えば Twitter におけるユーザクラスタの検出 が少し前に話題になったが、あれなどはまさにこの特許の目指しているものではないかと思える。クラスタ内で Favorites を集めているユーザは Influencer である可能性が高い。
例えば、携帯電話クラスタ 内で favorites の多いユーザの profile に iPhone の広告を載せれば、iPhone に興味の無い ultraviolet も iPhone を買う気になるかもしれない。表示する広告はこんなものがいいだろう。「iPhone なら 裏蓋が無くなる こともありません」
唯一疑問に思う点として、Twitter や SNS で、自分と同じコミュニティに属する友達の profile ページをそんなに毎回見るものだろうか、との疑問はある。私の感覚からすると、profile ページとは初対面の相手に対して情報を与えるためのものであって、一旦友達になってしまったらあまり見る必要も無いのでは、と思える。ただし Facebook だと、友達にならなければ profile ページを見ることすらできないような設定もあるため、世の中の人は私が思うより遥かに頻繁に友達の profile ページを眺めているのかもしれない。
いずれにせよ、今回のこの特許からは、Google が「ユーザ間の人間関係をマネタイズする」べく着々と手を打っていたとわかる。ultraviolet が Social Graph の話 の中で予想したとおりである。
slashdot では FriendRank という言葉を使ってこの状況を少し意地悪く表現している。特許の中では「Influencer が自分の profile 中に広告を許可のための金銭的インセンティブ」についての言及があるが、これは要するに「コミュニティ内での影響力が強い人ほど AdSense 単価も高くなる」ようなシステムのことだろう。影響力の強さを FriendRank と表現しているわけだ。
数年後の AdSense 界隈では、Influence Optimization などと言って自分の FriendRank を高めるためのテクニックが流行るのかもしれない。
作者: duke http://www.rauru-block.org/mediawiki/index.php/User:Duke
更新日:2008年7月7日 9時37分
ログを紙で提出
TechCrunch の GoogleはYouTubeデータを紙でViacomに渡すべきだ を読んだけど、これはダメでしょ
奇抜なアイデアだとは思うけど、実際には提出期限が切られてるわけだし、それまでに12テラバイト分を紙にプリントアウトして用意するのは、現実問題としてすごい困難
大量の紙資源を浪費し、Google に多大な負担を強いた上で、俺のプライバシーが Viacom の手に渡るのはやだやだやだ
って駄々を捏ねてる、って風に見えるんだけど
この記事を書いた Erick Schonfeld って、これに限らず最近目に余るものが多いと思う
例えば ロングテール理論にケチをつけた にしても、Anita Elberse の論文 は Long Tail を否定してるわけじゃなくて、Chris Anderson の恐ろしくお気楽な Long Tail 礼賛に対して それほど楽観的なもんじゃない
と戒めているもの
Long Tail 的なビジネスに乗り出そうとする小売業者に対するアドバイスまで書いてあって、TechCrunch より遥かに役に立つ内容なのに
ところで、ログを紙で提出するのがアメリカではこんな感じでジョークになるけど、日本では冗談じゃなく本当に紙で提出してる ってことをみんな知ってるのかな
警察がISPのIPアドレス割り当てログを提供させるときって、裁判所から差し押さえ令状を取って、って形になるんだけど、情報のような無形物を差し押さえるのは日本の法慣習的にめんどい(やってやれないことはないらしいけど)
だから、警察は予め ISP に「○月○日に差し押さえに行くから××に関連するとこだけをログから抜き出して紙に印刷して△△の場所に用意しといて」と依頼して、その日付と場所の書かれた差し押さえ礼状を持ってって、プリントアウトを差し押さえる、てのが多いパターン
それもどうなのかなあ
作者: mara http://www.rauru-block.org/mediawiki/index.php/User:Mara
更新日:2008年7月4日 18時12分
プログラミング言語の生誕地
reddit で拾ってきたネタですが、メジャーなプログラミング言語が生まれた場所を Google Maps 上にプロットした地図だそおです。
そうか、Ruby の生誕地って Shimane Prefecture だったなそう言えば。しかし知らない言語って結構いっぱいあるなー。
でもこの地図ってオチがあって、Perl も Python も Ruby も入ってるけど、PHP が入ってないんだよね…
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年7月3日 17時16分
性格を伝える profile の書き方
slashdot.org で Do YouJustGetMe? Do I Even Get Myself? って記事が紹介されてるのを読んで知ったんだけど、SNS の自己紹介 profile でどれだけ自分の性格が相手に正しく伝わるかって研究が行われてたらしい
What Elements of an Online Social Networking Profile Predict Target-Rater Agreement in Personality Impressions?と題して、International Conference on Weblogs and Social Media (ICWSM 2008)発表されてる
この研究のためだけに、会員同士を知り合わせてお互いの profile から相手の性格を予想させる youjustgetme.com ってサイトを作って、あと Facebook でも同じ目的の app を作って、ネットユーザに使わせて、データをまとめたらしい
各ユーザの性格は Big Five personality traits ってテストで判定して、相手の性格を予想するのもその結果に合わせた予想を出させ、予想とテスト判定結果の一致度を比較する、っていう手法
この研究の結果わかったことは四つ挙げられてるんだけど
- youjustgetme.com では、profileからの予想と実際の性格との一致度は相関係数にして0.29で、まあそこそこ高かった、つまり人々はそれなりによく相手の性格を予想できてた
- Facebook はさらに一致度が高く、相関係数は0.41で、結構よく予想できてた
- 男性と女性を比較すると、女性の方が相手の性格をよく予想できてたし、また男性にとっても女性のprofileから性格を予想する方がよく予想できてた
- 相手の性格を知るのに役立つprofile項目と逆に足を引っ張る項目がはっきり分かれた
最初の二つはほとんど自明だからいいよね
三番目も、女性の方が相手の性格を見抜く直感に優れてるてのはよく言われる話で、これも妥当かな
Joe McCarthy は 女性は脳の構造からして…
とか言って Female Brain とかいうまた ultraviolet が聞いたら眉唾だと怒りそうな本を持ち出して来てるけど、まあ男女の脳に本当に機能的な性差があるのかってのは未知の部分の方が多いからおいとくとして、女性の方がコミュニケーションに用いる直感的認識を鍛えられてるってのはたぶん確か
男性から見ても女性の方が予想しやすいって言うのは、女性の方が profile を書くのが上手いってことかな
男性の方が profile 上で自分の性格をうまく騙してるとか、あるいは見栄を張ってるってことかもしれないけど
面白いのは四番目、自分の性格をよく伝えるには profile に何を書けばいいのか
項目があった場合と無かった場合とで相関係数に大きく差が出たトップ5項目のリストがあるんだけど、それによると
- 自分が面白い/笑えると思った動画へのリンク
- 何をしてるときが一番生き生きしてるか
- 今まで自分がやったことのうち一番困った/当惑したこと
- 今まで自分がやったことのうち一番人に誇れること
- 自分の精神性(宗教的な意味で)
逆に足を引っ張ったワースト4が
- 本人以外を使った顔写真
- ひどいと思うWebsite
- ひどいと思う人
- 素晴らしいと思う本
一番役に立ったとされるおもしろ動画へのリンクだけど、相手の笑いのツボが理解できるってことなのかな
お馬鹿な鉄塔のGIFアニメ なんかを日記に貼り付けてた ultraviolet がどう評価されるのか知りたい
素晴らしいと思う本を挙げるのが逆に足を引っ張ったのは謎で、McCarthy も Facebook の profile で好きな本を挙げることが自分のブランディングに役立つって主張する New York Times の記事 を引用して不思議がってるけど、無理して説明こじつけるなら、素晴らしい本(Great Books)を挙げるってことになるとみんな見栄を張りたがるんじゃないかな
ほとんどSF作家と漫画家しか挙げてない ultraviolet はまあ大丈夫なんじゃないの
見栄張ってそうに見えるのはガルシア・マルケスだけだけど、あれについては理由があるってのもわかる
ココロ社の人とかに役に立つライフハックかもと思うけど、でもこの研究って自分の性格を正しく相手に伝えるテクニックであって、実は正しく伝えない方が相手に「会ってみたい」という気を起こさせるケースもあるのかも
作者: mara http://www.rauru-block.org/mediawiki/index.php/User:Mara
更新日:2008年6月30日 8時44分
WikiTrust
Read/WriteWeb の記事 で知ったのだが、カリフォルニア大サンタクルーズ校の研究者の手による WikiTrust プロジェクトがデモを開始しているらしい。
この WikiTrust のデモは、Wikipedia のテキストのどの部分がどの編集者の手によるものかを履歴から分析し、信頼性の怪しい編集者の手による部分にはオレンジ色をつけて表示する、というものである。
私も2年半ほど前に 同じような方法 を提案したことがある。当時はブラウザ側の Javascript で処理する方法で考えたため ultraviolet に実現困難などと言われてしまったが、この WikiTrust は Wikipedia からデータを取ってきて別サービスとして専用サーバ上で処理することで処理負荷問題を解決しているようだ。
このような方法では編集者の信頼性をどう計るかが鍵となるが、WikiTrust では興味深い方法を用いている。編集者が記事を書き、後で別の編集者がそれを修正した時、内容が修正されてしまえば信頼性が下がったと見なされる。逆に無修正で残されれば、信頼性が揚がる。履歴が全て残る Wikipedia ならではの計測方法だと言えよう。無闇に Edit War に参加すると自分の信頼性を下げる結果になるのかもしれない。
このデモでは、2007年2月6日時点での英語版 Wikipedia のスナップショットを元に編集者・記事の信頼性を計算している。さすがに計算には時間がかかるようで、リアルタイムに編集される Wikipedia 現行版にキャッチアップさせるのは現時点では難しいようだ。
また、アカウント無しの匿名編集者による編集については、編集者の履歴を追うことが難しいため、テキストの編集履歴のみから信頼性が計算されている。編集を生き延びたテキストは信頼性が高い、一度削除されたが後の編集で復活されたテキストは信頼性が削除前より上がる、といった計算方法が使われているようだ。
このように現時点での課題もいろいろとあるが、この WikiTrust は基本的に、Wikipedia の信頼性を「誰が編集したか」によって計ろうとするものであり、その思想自体は妥当なものと考えられる。
少し前に津田大介氏が Twitter で 俺はネットの一部にある「誰が言ったかが重要じゃない。何を言ったかが重要なんだ」って概念を根本的に信頼していない。それが14年ネット見てきた結論。
と発言していたが、私も20年間ネットを見てきて同じ結論を持っている。
ネットでの匿名性については議論が尽きないが、実名をネット上で使わないにしても少なくともアイデンティティの追跡可能性は必要だろうと私は考えている。そのような見方に立つため、ja.wikipedia でアカウントを作らずに匿名のまま編集するユーザが多いということを、若干の懸念として感じてはいる。
作者: duke http://www.rauru-block.org/mediawiki/index.php/User:Duke
更新日:2008年6月29日 18時19分
最近の WordPress plugin
久々に WordPress の plugin をいくつか試してみました。
Exploit Scanner
WordPress にあやしそうなコードがアップロードされていないか、MySQL データベースおよび plugin その他のファイルから検索してくれる plugin です。
でも単純な文字列比較で検索してるので、Exploit Scanner 自身が引っかかるというちょっとお間抜けな面もある。後述する TipJoy plugin と、あと Britannica Widget とかが、iframe を使ってるので引っかかりました。iframe とか eval とか shell_exec とか使ってるのは全部あやしいと見なすみたいね。
Seesmic plugin
WebCam とかを使ってその場でコメントを動画で撮影して投稿するっつう plugin です。動画コメントする人は自分で Seesmic のアカウント持ってないといかんのですが、Seesmic のあの flash インタフェースがそのまま使えるので便利。TechCrunch英語版 もこの plugin 使ってるんだよね。
Microkid’s Related Posts plugin
関連する記事を表示するのに今は WP 2.3 Related Posts plugin 使ってるんですが、これは tag の一致度を使って関連発言を引っ張ってきます。これに対して Microkid 製 plugin は、記事をポストするときに関連発言を手で指定するようになってる。もちろんポスト画面から過去記事を検索できるようになってます。これはこれで便利。
しかし、既に過去記事数1,600を超えるうちのようなとこでこれを入れると、過去記事にも全部関連発言を手で設定し直すって話になるので、非実用的ぢゃよな。手動登録が無い場合は tag で引っ張ってきて、登録があればそっちを優先する、的な動作をして欲しいので、暇な時に改造できそうか眺めてみよう。
TipJoy Plugin
TipJoy の投げ銭箱を設置する plugin です。TipJoy の詳細については TechCrunch の解説を読んでもらうとして、10セント(10円ちょい)ぐらいの単位で投げ銭を払うシステムです。今回設置した plugin は TipJoy 謹製のやつ。この他に TipThis っつうもっと高機能な plugin もあるんですが、そっちはなぜかうまく動かんかった。
is_single() の時だと、この記事の下あたりに TipJoy 表示が出てるはずです。チップ絶賛受付ちゅう。
作者: ultraviolet http://www.hatena.ne.jp/raurublock/
更新日:2008年6月28日 17時14分