Syoichi's Tumblr

Jan 28 2012

  • エ: 今から10数年前、当時ネットを使って作品を作っている珍しいアーティスト同士として、江渡浩一郎と出会った。彼とは、ネットの、そしてメディア・アートの激変した10年を歩んできた「同郷の士」という感覚がある。いま彼は、産総研※1に在籍し、集合知をテーマにした研究や書籍の執筆、実用的なサービスの開発などといった活動に力を注いでいる。
  • エ: 年の瀬の取材は、1年を振り返るところから話が始まった。
  • エキソニモ(以下エ): 「2010年はどんなことをやってましたか?」 
  • 江渡(以下江): 「朝から晩まで論文執筆だね。新しい作品を作りたくてウズウズしてるw」 
  • エ: 「この号が1月に出るので、この取材のテーマは江渡さんと干支を掛けつつw、2011年のwebについて話せたらと」 
  • 江: 「2010年は、結局twitter※2の年と言える。1月にキャズム※3を超えた」 
  • エ: 「何かキッカケがあったんですかね?」 
  • 江: 「2009年12月にウェブ学会※4というシンポジウムに参加したんだけど、その頃に発表された論考に『日本でのtwitterの“キャズム越え”は、まだまだ先の出来事』と書いてあった。でも、年が明けて首相がtwitterを始めた辺りから、一気にキャズムを超えたみたい」 
  • エ: 「ustreamも躍進しましたね」 
  • 江: 「twitterやustreamが普及して、言論の場がフラットになったね。webが一段階進んだように感じる」 
  • エ: 「90年代のweb初期の感じもありますね」 
  • 江: 「そうそう。webが本来の姿を取り戻したとも言える」
  • エ: 「twitterはどう思います?」 
  • 江: 「素晴らしいと思うけど、議論の土台としては使いにくい。もちろん、議論しにくいようにデザインされてるからだけど。まとめシステムとして今はtogetter※5があるけど、もっとwiki※6の思想を取り入れたら、使いやすいシステムにできるんじゃないかな」
  • エ: 「tumblr※7はやりますか?」 
  • 江: 「以前は中毒だったよw tumblrは、ティム・バーナーズ=リー※8の考える理想のwebに近いんだよね」 
  • エ: 「そうなんですか?」 
  • 江: 「バーナーズ=リーは、もともとブラウザから任意のwebページを編集できる環境を構想していた。その理想を実現したのがwiki。tumblrは、元のページは書き換えられないけど、引用することによって彼の思想に近い環境を実現している」
  • エ: 「最近は、facebook※9も注目されてますが」 
  • 江: 「あんなの新しくもなんともないよw」 
  • エ: 「facebookには、mixi的な閉鎖空間に戻った息苦しさを感じました」
  • 江: 「持論なんだけど、日本はコミュニケーションメディアの最先端なんだよ。掲示板だと2ch、snsだとmixiという形で日本が最先端だった。パクリとはちょっと違うけど、mixi的な生ぬるい馴れ合いの価値がアメリカで再発見されたのがfacebookでは? でも『いいね!』ボタンはいいね!w」 
  • エ: 「いいね!は、はてなスター※10に似てますよね」 
  • 江: 「はてなスターは普及には至らなかったけど、『いいね!』ボタンの先を行ってたよね。これも、日本が最先端の事例の一つだよ」
  • エ: 「スマートフォン※11も面白いと思うんです。位置情報サービスは、まだ未開拓な感じがしますが」 
  • 江: 「foursquare※12は、離陸にまでは至らない気がする。mayorという制度で価値を捏造しようとしたけど、やっぱりヤラセ感が強い。セカイカメラ※13もがんばってるんだけど、場所を中心としたコミュニケーションは共感させるのが難しい。以前から『モノを中心にしたsns』と『ヒトを中心としたsns』の2つの方向性があって、今生き残ってるのはヒト中心だけ。その代表がtwitter。そんな中で、モノ中心で唯一面白いのがinstagram※14だよ」 
  • エ: 「え、あのオシャレなtwitpic※15みたいなやつが?」 
  • 江: 「表面的にはそう見えるせいでよく誤解されるけど、あれは本質的にはネットワーク構造が新しい。iphoneアプリ中心の設計になっていて、webからはほとんどの部分が隠蔽されてる。webにはユーザーページすらない。これは実に新しいよ」 
  • エ: 「わざとそうしてるんですかね」 
  • 江: 「かなり緻密に考えられてる。写真というモノを媒介として、共感によってつながるネットワーク。僕はgirls' networkって呼んでる」 
  • エ: 「girlsってことはboysもある?」 
  • 江: 「twitterみたいな『言語のコミュニケーション』は、論理によってつながっていくから、boys' networkって呼んでる。それに対して、instagramはもっと感覚的につながる」
  • エ: 「具体的に、どういうことですか?」 
  • 江: 「たとえば、ふと夕日の写真を撮ると、それに対してlikeがいくつも付く。つまり、写真の内容じゃなくて、共時的な感覚が共有される。普通に“夕日きれいだね”という」 エ:「夕日の写真なんていうありふれたものがスポッと感覚にハマる感じ?」 
  • 江: 「面白いだろうと狙って撮った写真は、逆にあまりlikeされなかったりw」 
  • エ: 「ナルホド。またしてもコンテンツの危機ですねw」 
  • 江: 「最近のwebサービスは、作り込む部分がコミュニケーションやサービスの部分になってきていて、コンテンツは本当に一瞬で消費されてしまうね」 
  • エ: 「それはすごく感じています。ところで、話飛んで、以前江渡さんのアイコンがgacktだったんですが、あれはナゼ?w」 
  • 江: 「それは・・・ごにょごにょごにょ(本人希望によりカット)」
  • エ: 「・・・ たぶん、江渡さんとwebにまつわる話は延々と続けられる。そんな中で、お互いに同意したことが一つ。
  • エ: 「webの未来は予測不可能」、つまり2011年がどんな年になるかは、知ったこっちゃねーということだ。
  • エ: 「ノーフューチャーもとい、未来は自分で作れ! byアラン・ケイ※16。というわけで今年もよろしく!! ※1~16 ググれ!
+

youkoseki:

概要:長文で難解なユーザポリシーは、これまでサービス企業のやりたいことをユーザに押しつけるために機能していた。しかし炎上リスクを抱えるようになった今、サービス企業は分かりやすいユーザポリシーを書くことが求められる。

A Little Rancor

炎上するプライバシ問題

このところ、私たちのプライバシデータについて、企業の取り扱いかたをめぐるトラブルが相次いでいる。まずは幾つか事例を挙げよう:

  • ミログ社のAppLogは、Androidスマートフォン用のアプリに同梱され、ユーザが使うアプリの情報などを収集することで、広告配信などに活用する。ミログ社はユーザからの承諾を得て情報を収集していると説明していたが、その案内が不十分であったために批判を受け、AppLog事業を停止するに至った。
  • ソニーのゲーム用オンラインサービスPSNでは、ユーザのゲームの進行状況やハードディスクレコーダーTorneの録画傾向などが、誰からも参照できる状態にあることが問題視された。ソニーは謝罪し、利用規約を実情に沿うように改訂している。
  • Carrier IQ社は米国製スマートフォンの多くに、ユーザの位置情報や入力情報を収集するソフトウェアを導入している。Carrier IQは得られた情報を通信キャリアや端末メーカーへ提供することで、通信インフラなどの改善に役立てると説明するが、収集される情報の質量が不透明であるため、多くの反発を招いた。
  • アップルはiPhoneユーザの位置情報を、端末や同期したPC上で長期に保管していたことがセキュリティ研究者の指摘で明らかになった。アップルはこの問題は「バグ」であったと釈明し、アップデートを行った。
  • GoogleのAndroidスマートフォンでは、Androidマーケットでのアプリ購入時、ユーザの住所などがアプリ開発者へ通知される場合があると発覚した。Googleは不具合と認め、謝罪した。

まだまだ他にもあるだろうが、ひとまずはこのあたりにしておこう。それにしても、この一年ほどのあいだに、このような問題が相次いだのはなぜだろうか。

スマートフォンとソーシャルメディア

ひとつには、スマートフォンの普及が挙げられる。スマートフォンでは、GPSによって位置情報を収集したり、電話帳やメールといったユーザ個人と深く紐づいた情報が保存されたりしている。スマートフォンでは多くのアプリがウェブサービスと連携しながら動作しているため、端末で収集・保存されたプライバシ関連情報が、端末の外へどのように発信されているかを把握するのはとても難しい。このため、利用者の期待と実態にギャップが生まれ、トラブルとなることがある。実際、上記の5事例のうち、4事例はスマートフォン関係である。

もうひとつには、ソーシャルメディアの普及により、サービス提供側のユーザを軽視した態度が炎上の対象になりやすくなったことが挙げられる。サービス側から言えば「炎上リスクの拡大」である。

これまではユーザ側からの批判があったとしても、サービス側は「どのようにデータを取り扱うかはユーザポリシーに明示してあるし、ユーザはそれに同意していたのだ」と言うようなことを主張することが多かった。たしかに、難解で長文なユーザポリシーに目を通せば、曖昧な表現で「私達はあなたのデータをいかようにも利用できる」というようなことが書いてあることは多い。規約自体にミスがあるソニーのような例はむしろ稀だ。

もっとも、そのようなユーザポリシーをユーザがちゃんと目を通しているかは疑わしい。スマートフォンの小さな画面では尚更、長文のポリシーなど読ないだろう。だからといって、規約やポリシーであらかじめ断っていれば、サービス側はなにをしても良いということにはならない。たとえ裁判に勝てたとしても、ユーザから反発を受け、炎上して企業価値が下がるようでは、それは負けである。ユーザが規約を読まないのであれば、読みやすい規約にしなければならないのだ。

難解なユーザポリシーはこれまでユーザを煙にまく煙幕として機能していたかもしれない。ただ、ソーシャルメディアが力を持つ今日では、あまり有効な策と言えなくなった。ソーシャルメディアの力を誰よりも知るFacebookが、何度かの失敗を経て、ポリシーの改訂をユーザと事前に協議するようになったことが象徴的だ。

勝手ポリシーという手段

難解で曖昧なユーザポリシーはこれからもしばらく蔓延を続けるだろう。私たちのデータが、私たちの意図しない形で流通し、意図しない用途で利用される事例は今後も続くに違いない。

ならばひとつのアイデアとして、私たち自身がユーザポリシーを簡略化していくというのはどうだろうか。サービスがどのように情報を収集し、利用するか、私たち自身が見極め、整理し、共有する、Wikiのようなシステムになるだろう。情報が分かりやすく整理されれば、ユーザはうっかり不適切なポリシーのサービスを利用することがなくなる。サービス企業にとってもあとになって「こんなひどいポリシーだと思わなかった!」と言われることがなくなるので、メリットがあるはずだ。

ポリシー情報をまとめる際は「どの情報を」「なんのために」「どう扱っているか」を軸に整理することが求められる。それぞれアイコンのように絵でまとめて、ユーザ登録の際にでも「このサービスではメールアドレスを広告に利用します」(メールのアイコンと、広告に繋がるアイコン)、「このアプリでは念のためにあなたの位置情報を永続的に取得しています」(地図のアイコンと、カレンダーに無限大と描かれたアイコン)という形で表示できればベストだ。

あるいは、こうしたデータポリシーと運用についても、なんらかの監査システムを設けるべきなのかもしれない。日本では個人情報の取り扱いがとても厳しい反面、個人情報保護法の範疇にない「プライバシー」データの取り扱いについてはあまり体系的になっていないのが実情である。炎上してからでは遅いのだが。

(この記事を書きあげたところで、Googleからサービス別に分かれていたユーザポリシーを統合するという発表があった。Googleにはサービス連携で広告精度を高めるという大目標がある。しかし、分かりやすいユーザポリシーを用意し、ユーザに知らせるという動きは、文中に挙げたFacebookの例にも通じるだろう)

考えられるアイデア:

  • 文中にも挙げた、既存サービスのユーザポリシーをユーザ間で勝手に「翻訳」するシステム。アイコンなどにより、さまざまなポリシーのアウトラインを共通化し、ポリシー間の違いを明らかにできると良い。たとえば、ドコモとKDDIとソフトバンクのポリシーはどう違うか?
  • ユーザポリシーの監査、コンサルティング業務。絵や動画を使って、ポリシーを簡潔に説明できるサービスの展開も方法も考えられる。
  • いずれにせよ、企業のソーシャルメディア窓口は今後非常に重要なポジションになる。アウトソースすべきか、自社で対応するとしてどのような人材を当てるべきかは、大きな問題だ。

関連情報:

写真:JD Hancock

+
Jan 27 2012
及川が開発にあたって重視するのは、「誰のために、何のために作るのか」という“目的”を常に念頭に置くことだ。専門性の高いエンジニアたちは、ともすれば技術的な論理や制約にとらわれ、「どうやって作るか」という“手段”に目が行きがちだ。しかし、それではブレークスルーは生まれない。「ユーザーはそもそも何を求めているのか」を徹底的に考え、目指すべき理想のゴールを常に思い描く。そこから、今まで誰も気付かなかった新しいものが生まれると考えている。
第173回 及川卓也(2012年1月23日放送)| これまでの放送 | NHK プロフェッショナル 仕事の流儀

via Taku Kudo - Google+ - テレビ受けしやすい話より、「放送されなかった流儀」がより現実的だと思う。若いエンジニア・研究者は「手段の目的化」の罠に…
Jan 23 2012
Filesonic と Fileserve はもう終わりになりました。 Filejungle と Uploadstation も多分まもなく終了いたします。
サーバーの経費は少し厳しくなりますが、二三台ほど潰せば、残るのサーバーは自力で維持できます。
地元のサイト (中国語) の VIP 会員は FTP アクセスがあります(40TB 前後、10x100Mbps)。安全のため、すべての VIP 会員は審査を受けなければなりません。
外部への開放は可能ですが、匿名の支払い方法が必要です。今の価格は1000円/400GB程度です。新作一ヶ月は250円くらいとなります。
興味があれば、コメントとかメールで送ってください。

FlowerTradeWind のギャルゲー図書館 DDL の終末? (End of DDL)

Piracyの最前線の一端? 報酬プログラムがあるCyberlockerが衰退すれば、コンテンツの違法なアップロードをするインセンティブは減退せざるを得ない。それでも続けようとする人は、こうしてプライベートな・クローズドな・閉鎖的な環境の中でファイルシェアリングしていく事になるんだろうか。また、一度報酬プログラムを経験してしまった人はBitTorrentに切り替えるか、あるいはまたそれに戻ろうと考えるだろうか?

+

yomotsu:

ずどさんがはまろぐってたからついでに。

昔いろいろ悩んでいた頃があって、前の会社にいたころいろいろ試してました。キャンペーンページのような、すぐ消えるであろうページだったのでいろいろやってました。

例えば「.」でつなげてみるとか。

<div class="mod.sample.vertical">サンプル縦長版</div>

でもCSSも一手間加えないといけないのでやめました。CSSでは、「.」は普通には使えませんが、エスケープすれば使えます。

.mod\.sample\.vertical{
(snip)
}

あと、マルチバイト文字をクラス属性値にしてみたり。

<div class="大見出し">大見出し</div>
.大見出し{
(snip)
}

マルチバイト文字は普通に使えます。たしか。

ただの文字列ですし、予約語とか気にせず好きにすればいいんじゃないですかね

+
class/id の名前にハイフン区切りの文字列が使われているのはある程度歴史的経緯があります。

* CSS では、伝統的にプロパティの名前や擬似要素の名前などはハイフン区切りの文字列で統一されていました。
* CSS2 (CSS2.1 の1つ前の版)では、クラスセレクタ・IDセレクタの名前にアンダースコアを直に(エスケープせずに)含むことが文法的に許されていなかったのに対し、ハイフンは問題なく使用できました。
http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html#tokenization
* HTML4.0 (HTML4.01 の1つ前の版)では、要素の属性としてアンダースコアを含む文字列を指定する場合、クォーテーションマークを省略することが許されていませんでしたが、ハイフンを含む属性値に対してクォーテーションマークを省略することは許されていました。
http://www.w3.org/TR/1998/REC-html40-19980424/intro/sgmltut.html#h-3.2.2

(ただし、 HTML4.01/CSS2.1 ではアンダースコアを含んでも良いように文面が修正されました。おそらく世の中のページではアンダースコアがバンバン使われており、ブラウザもそれを受け入れていたために規格が修正されたのだと思います)

記事の筆者の方は他のプログラミング言語と比較されているようですが、 CSS はもともと文法的にハイフン区切りの文字列を推奨するように作られていた節があります。少なくとも、私の知る限り、ハイフン区切りの文字列が文法的に許可されていなかったことはありませんでした。

こういう経緯を見る限り、 class/id の名前にハイフン区切りの文字列を使うのは当たり前の帰結のように思えます。古い規格とは言えど、あえて文法違反を犯す必要はどこにもないですから……
Yuta Kitamura - Google+ - http://uupaa.hatenablog.com/entry/2012/01/22/013509…
Jan 22 2012

hamalog:

を見て、自分はいつも-を使ってるので、その理由を書いてみる。

結論から言うと、-でも_でもキャメルでもどれでもいいと思う。で、自分が-を使っているのは、jQuery UIのcssがそのように書かれていて、僕が年中、ヘビーにjQuery UIのベースとなっているwidgetというフレームワークを使っているから。そして、仕事でやる場合にはだいたいコレを使うので、それに習っている感じ。参照:The jQuery UI CSS Framework

-を使う時は、名前空間的な意味合いで使う。単語の区切り目としては使わない。具体的には、こんな感じ。ここで使っているmod-は、モジュールの単位を表す、mod-modulenameを起点にしてそっから下のひとまとまりがcssをごそっと適用するひとかたまりだよーという意味。apply-は、なんかJSをユーティリティ的にぽこっと適用するときに使う。

単語の区切り目は、キャメルケースにしたいところだけどあえてoremoduleみたいに全部小文字で書いちゃう。これは、jQuery UIがなんかそうしてたからだった気がする。あと、widgetは、カスタムイベント名を何故か全部小文字にしやがるので、とりあえずそんな長い単語は使わんから小文字に統一しておくかというぐらい。ま、jQuery UIが敷いているコーディングルールだと思う。たぶん。

widgetは、こんな感じでjQueryプラグイン上でOOPをするようなフレームワークで、こいつを書くと、例えばこの例だと、$.fn.hoge が作られ、コレを適用すると、そのウィジェットは、classにmod-hogeが付いてる前提で話が進む。別にそれをどうこうするわけじゃないけど、とりあえずそういう考えで作られてるものだったりするので、そんな感じでハイフンを付けてる。そーしとけば、html見たときにどのウィジェットと対応してるのか分かったりするのでやや便利。

これって、そもそもjQuery UIが-じゃなくて_にすべきだってでしょ常考とかも思うけど、まーそうなってるんでそうしてる。これはただのコーディングルール的なもので、超絶意味があるとも思わない。というか、_の方がJS的には嬉しいよ…

html+cssの設計的な視点からすると、mod-hogeの中に来る要素にはmod-hoge-hdとかmod-hoge-pとかなんとかそんな感じでclassを振っていく。で、これは非常に冗長な感じがする。たしかにそれはそうなんだけど、テンプレエンジンでちょっとしたhtmlソースの断片を扱うときには、それが何を示しているか分かりやすいというメリットがある。あと、モジュールが入れ子になった時も分かりやすいとか。が、確かに冗長ではある。安全策で固い書き方という印象。

あとは、なんかそういうふうに名前空間的に使っておけば、mod-modulenameのmodulename部分が被っていなければいらんところで知らんスタイルがかかったりしないので、良い気がしてる。そんでもって、ハイフンでそういうふうにしておけば、同じクラス名になったりとかしなさそうな気がする。_でも同じだけど、キャメルだとなんか被っちゃいそう(な気がするだけ)

まとめると、おれはjQuery UIに従うぜジョジョーーーッということで、別に_でもキャメルでもいい気がする。というか、元記事にあるように、vimで全部選択できないから、個人的には_の方が好き。というか_のほうが良いと思うんだけど。

+
How do you kill the movie and TV industries? Or more precisely (since at this level, technological progress is probably predetermined) what is going to kill them? Mostly not what they like to believe is killing them, filesharing. What’s going to kill movies and TV is what’s already killing them: better ways to entertain people. So the best way to approach this problem is to ask yourself: what are people going to do for fun in 20 years instead of what they do now?

YCRFS 9: Kill Hollywood

Y CombinatorのRFS(Request For Startups)の9番目が出たね。RFSは以下のようなもの。

http://ycombinator.com/rfs.html

今回のRFSはSOPA/PIPAのマスターマインドとされるハリウッドやテレビ業界に変わるこれから20年後のエンターテイメントの新しい形をスタートアップに求めている。

確かに今の映画業界やテレビ業界は余裕がなくなって、寛容でなくなったからSOPA/PIPAのような政治に守ってもらう方向にいっているのは事実だ。でも、以前として巨大な力とリソースを持っているし、コンテンツの制作とその配布に強大な権限を持っている。そこを切りくずさないと「ハリウッドを殺す」ことはできないよね。

Paul Grahamが書いたと思われるこの文章は、ほかのRFSに比べると問題設定が少し散漫だ。「ハリウッドを殺す」ためのアイディアということだが、つまりエンターテイメントコンテンツの供給側に革新を起こすか、需要側のテレビや映画を楽しむ大衆の選好を変更させるかのどちらかであろう。この文章でPaul Grahamはビデオゲームを持ちだして需要側の選好を変える例を出しているけれど、まあ需要側の選好変更は20年程度ではなかなか難しそうだ(注1)。

一方で、供給側のコンテンツの制作と配布について、どちらかに絞って小さなテクノロジーの革新ができると、もしかしたら「ハリウッドを殺す」最初の一投ができるかもしれない。

例えば、コンテンツの制作については、人類史上かつてないほど動画制作のツールを手に入れた時代は他にない。スマートフォンを持っている人なら誰もがフルHDのビデオカメラを持っていることになる。数万円だせばプロが使う動画編集ソフトも手に入れることができる。だれもが潜在的にはハリウッド監督や製作者になるテクノロジーは手元にある。そのエンパワーメントされた状況をうまく利用できれば、コンテンツ制作の破壊的な低価格化を生み出すこともできるかもしれない。

また例えば、現在はYoutubeなどの無料動画シェアリングサイトの競争が一段落して、寡占化となった状況である。その一方で有料の動画の配布についてはHulu/Netflixなど既得権の業界にガッチリ掴まれている。この有料動画の配布についてインディペンデントな監督や良質のドキュメンタリーの製作者が作る動画を安価にうまく配信し、それらの製作者に売上をシェアリングできるプラットフォームを作ることができたら、「ハリウッドを殺す」キッカケができるかもしれない。

ただどう考えても「ハリウッドを殺す」ことは、尋常でないほど大変なことは確実だ。

—-
(注1) 例えば、現在多くの人が自分の余暇の時間消費として利用しているハリウッドやテレビのエンタメコンテンツであるが、それをなくして新たなエンタメでないコンテンツを導入することを考えよう。例えば、無料の学問のビデオ講義を視聴したり、文学作品を楽しんだりと、知識や芸術系のコンテンツはエンタメコンテンツより多くの余暇の時間を消費するものである。しかし、そのコンテンツを楽しむにはリテラシーが大きく必要であり、皆がそのリテラシーなど望むべくもないことから、やはり「小人閑居して不善を為す」が如くエンタメコンテンツで余暇の時間消費をするだろう。

(via kashino)

+
Jan 21 2012

Pinterestでは何かをコレクションしてもそのコレクションはコレクションに過ぎず、まとめサイト(キュレーション・サービス)のようなコンテンツになりづらいのが良い気がする。まぁ無理やり長いコメント書いてBoardで完結するようにもできちゃうけど、不恰好だしあんまりそうしている人はいない。画像でキャッチし簡潔なコメントで更に興味をもたせ、元サイトへ誘導みたいなのが結構上手く回ってるようなイメージ。

あとはあんまり必死にならなくてもだらだら楽しめる所が良い気がする。他のソーシャルなウェブサービスと違って時間軸的な要素がほぼないので、タイムラインを目を皿のようにして追っかける必要がない。リアルタイムの先にある何かがあるとかいうと褒め過ぎだけど、TwitterFacebook、場合によってはブログにもあるソーシャル疲れとは無縁なんじゃないかと思う。

Wallpapers on Pinterest - Weblog - hail2u.net
+

DashboardやLikeのページでポストをReblogできるキーボードショートカットを追加するシンプルなUser Script、Reblogableを0.0.2へ更新。

インストールはこちら。

https://raw.github.com/gist/1609210/reblogable.user.js

ソースコードはこちら。

Add shortcut key T for Reblog on Tumblr Dashboard. — Gist

更新の要点は以下。

  1. 「http://www.tumblr.com/show/photos 」なページや、タグのページでも動作するように
  2. 「redirect_to」に「data:text/plain,」ではなく「/favicon.ico」を設定
  3. 検索やreply、Answerへ文字を入力する際に、ポストを誤爆しないように

上記に関して幾つか補足を。

2では、Reblog後のリダイレクトでFaviconへアクセスするように設定する事で、0.0.1で発生していたXMLHttpRequestProgressEvent.typeがerrorになる問題を回避するようにした。また、FaviconはTumblrのページへアクセスしていれば、ブラウザ側でキャッシュされやすいのでリダイレクトによる不必要な通信もある程度抑える事ができると思う。

Chrome(デベロッパーツール)

Firefox(Firebug)

ただし、Operaではキャッシュがちゃんと活用されているかは確認できなかったけど…。

3では、Dashboardなどに存在する入力フォームでTキーを入力した時、ポストを誤ってReblogしてしまう恐れがあったので、Tキーが入力されたか確認する時に、入力フォームで入力しているのかもあわせて確認するようにした。

Jan 20 2012
+
Chromeに限らず(あのIEだって新しいバージョンが出るたびに同じ問題を抱える)、ブラウザにとって既存サイトとの互換性というのが問題になるのですが、そのようなときには、ここに書いてあることを試してみてください。

それでも解決しない場合には、情報をいただけると調べて対応するようにします。

サイト互換性問題にはいくつかの原因があります。

1. ブラウザ側の不具合
2. サイト側の不具合(Web標準に沿っていない。ほかのブラウザでは動作するからということで放置されているなど)
3. サイト側が意図的に特定のブラウザにしか対応しないという方針をとっている。サポートブラウザにしないとか、サポートブラウザ以外ははじくようにしているなど。
4. サイト側が特定のブラウザにしか搭載されていない機能を使っている
5. それ以外。たとえば、最新のWeb標準への対応がどちらかで行われていない(ブラウザ側かサイト側)など

ユーザーが持つ多様なプラットフォームからすべてのWeb上の情報にアクセスすることが可能になるようには、ブラウザベンダーだけではなく、サイトオーナーや標準化団体など、すべての関わる人の協力が必要です。
Takuya Oikawa - Google+ - Chromeに限らず(あのIEだって新しいバージョンが出るたびに同じ問題を抱える)、ブラウザにとって既存サイトとの互換…
+

また、これだけではなく新しいプレイヤーの登場の可能性があると思っています。

それはGoogleやFacebook等のクラウドサービスメーカです。

クラウドサーバメーカは、消費電力を気にして独自のサーバを作ったり、省電力なデータセンターを作っています。これをもっと突き詰めればサーバ向けCPUを設計・製造してもいいはずです。

AppleがAシリーズで設計を行い始めました。私は最初は開発コストをどのように回収するのか疑問だったのですが、iPhone/iPod touch/iPad/Apple TVと豊富なラインナップを揃える事で開発コストを回収しています。出荷数が多ければ自己消費だけでもメリットを享受できます。

たぶんNVIDIAはHPC向けにするためGPU付きTegraを出すでしょう。ですが、サーバ市場にはGPUは今のところ余計です。このためいくつかのARM系CPUメーカではCPUだけ乗せている製品がありますが、それがGoogleやFacebookが気に入るとは限りません。また、同じCPUでサーバを作っている限りサーバ効率でライバルを先にはいけません。差をつけるためにもGoogleやFacebook等のクラウドメーカがCPUから設計してサーバ構築する案も決して悪いと言えないでしょう(ただし、GoogleがARM系CPUを製造しても外販しないでしょうけど)。

最良のシナリオならばARM系CPUはサーバ市場で20%ぐらいのシェアをとることが出来ると思います。とはいえ、競争力旺盛なIntelがこの状況を観客として眺めているとは思えません。Atomをサーバとして準備もしています(なぜもっと早くやらなかったのか理解に苦しみますが)。

また、もしかするとIBMもこの分野に進出するかも知れません。POWERは組み込み系を得意としていますし、Bule Gene/Q等の省電力CPUもあります(HPC向けなのでクラウドサーバ向けではありませんが)。

今までの半導体の歴史は下克上を繰り返してきました。RISCがメインフレームを破り、x86がRISCを追い込みました。ARMがx86を飲み込んでも少しも驚くことはないでしょう。

ARMがサーバ市場を揺るがすのか:少しでもパラノイアになってみる:ITmedia オルタナティブ・ブログ