Category Archives: log

log

Flashのことを笑っている場合じゃない

Web開発の現状を25のトゥウィートで斬るとこうなる–iPhoneを見捨てたFacebookデベロッパの告白のはなし。

Apple vs Adobeで大揉めしてみんなに楽しい娯楽を提供してくれているけれど、我々ウェブ開発者(というのは大雑把すぎるくくりだけれど)にとってはFlashなんてはなから選択肢に入っていないのだから単なるゴシップでしかない。

でもJoe Hewittの話はひとごとではない。
彼は10年前の2001年にcanvasを実装し[canvas]、Firebugを作り[firebug]、facebookのiPhone向けWeb版を作り、facebookのiPhoneアプリを作りセットでいろんなiPhoneアプリで使われてるthree20を作り、Appleの身勝手にうんざりしてiPhoneアプリはもうやらないと宣言してた。

彼のいまのウェブに対する見方はこのふたつのtweetに集約されてる。

I’ve always preferred the web, but native platforms have been kicking its ass. I go where the power is.

Twitter / Joe Hewitt: @sprynmr I’ve always prefe …

Hopefully we’ll look back on today as the day the mobile web began to eclipse proprietary mobile platforms. Still a ways to go, though.

Twitter / Joe Hewitt: Hopefully we’ll look back …

いつだってウェブのほうが好きだけど、今はネイティブアプリがきてる。自分はパワーのあるところに行く。
いつか今日が独占的モバイルプラットフォームをモバイルウェブが侵食し始めた日だったって振り返れたらいいね。まだまだ先そうだけど。

the web sucks

TechCrunchには載ってなかったけどHewittがtwitterで紹介していた The web sucks. Browsers need to innovate – Sachin’s Posterous この記事は秀逸だ。いかにブラウザを基盤としたウェブアプリがだめで、ネイティブプラットホーム上のアプリが優れているかについて細かく例を挙げて教えてくれる。(日本語でも読めるよ PosterousのCEO「Webはクソ。ブラウザはマジなんとかしろ」 – 床のトルストイ、ゲイとするとのこと)

そして現実にiPhoneユーザの多くは普段ネイティブのアプリを利用していて、ウェブアプリを使っていることは稀だ。twitterやgmailはiPhone向けに最適化されたウェブページを持っているが一体誰がそれを使っているだろうか? ネイティブアプリは文字通りなんでもできる(Appleがダメだということを除いて)。ウェブアプリにはブラウザでできることしかできない。
いままでウェブ開発者はブラウザでできないことはできないのだと無意識に思い込んでいたけれど、iPhoneアプリがコンピュータにはなんだってできるんだということを思い出させてくれたはずだ。アプリで写真をとって位置情報つきでサーバにアップロードするみたいな今となっては当たり前のようにやっていることができないし、後で読むためのフィードデータをバックグラウンドでデータをダウンロードして保存しておくことはウェブアプリでもできるけどネイティブアプリと比較するとパフォーマンスが悪すぎる。

これからの主戦場である(既にそうだ)モバイルプラットホームでウェブ/ウェブアプリはユーザに選ばれなくなって、代わりにネイティブのアプリケーションに時間が費やされている。

スティーブジョブズはiPhoneにFlashを載せない理由としてThoughts on Flashで”中間層がイノベーションを阻害するから”だと言った。それは”Flashを載せないため”の理由でしかないだろう。Flashのことは我々には関係ない。でもHTMLだってプラットホーム上にある中間層であり、イノベーションについていけてない(=阻害している)のはFlashと同じだ。

この一連の話が気になったのは、まえに似たようなことを思ったからだ。
2008年の12月にiPhoneのアプリを書いてたときにこう書いてた。

なるほど、ウェブの時代は終わって再びソフトウェアの時代が帰ってきたのだ。

not enough memory

余談

ウェブアプリケーションだけがウェブじゃないみたいな話は Understand The Web · Ben Ward に書かれてました。

The web sucks. Browsers need to innovate – Sachin’s Posterous

People are using apps more because the experience is much better. We will see a decline in web traffic and search in the coming years

というくだりがあってはっとさせられるもののそんなでもないんじゃないかと思うけど、でも既にGoogleはちゃんとAndroid+AdMobを持っている。

参考

  1. Twitter / Joe Hewitt: While waxing nostalgic, I …
    Bug 102285 – create xul canvas tag for custom painting control
  2. Firebug :: Add-ons for Firefox

chromeのねんどろいどテーマ

joinだけしてあるのを思い出してtiarraから#chromiumのログを見てみたら

2009.10.01.txt:11:21:40 <#chromium@freenode:aboodman> w00t: http://dl.getdropbox.com/u/124107/success.png
2009.10.01.txt:11:22:03 <#chromium@freenode:aboodman> (first successful render of browser action badges)

というのを発見。

Greasemonkeyのはじめの開発者で今はchromeのextensionまわりの開発を担当しているAaronがiPhoneのアイコンみたいに数字がお手軽に表示できるAPIができたぜー、といってるんだけど

このテーマはなんだAaron!
Aaronはねんどろいど(わからなかったのでid:HolyGrailに聞いたら速攻で教えてもらえて解決した)のテーマを作ってchromiumに使ったりするキャラだったのか、そうかそうかいいひとそうなオーラを出しているうえにオタク?だなんてほんとうにいいやつじゃないかとおもいました。実際には自作じゃなくてGoogle Chrome テーマ ギャラリー: Good Smile Companyみたいだけどaaronさんいいひとそうです。先々週に結婚されてました。おめでとうございます。youngpup.net – Aaron Boodman’s personal blog

そんなAaronのextension API仕様に関する後悔。

2009.10.03.txt:05:56:35 <#chromium@freenode:aboodman> you need to pass a null for the first argument
2009.10.03.txt:05:56:37 <#chromium@freenode:aboodman> (our implementation of 'optional' is bad)
2009.10.03.txt:05:56:45 <#chromium@freenode:aboodman> you should have at least gotten an error

僕もそう思います。optionalなのは省略できるんだと思ってました。

もうひとつ。こっちはvideoタグがらみでx264とTheoraのコーデック品質比較画像。

2009.08.13.txt:2435:09:36:26 <#chromium@freenode:Dopefish> Simetrical: http://imk.cx/temppics/extra_x264.png -- http://imk.cx/temppics/extra_theora.png -- the theora one was about 1400 - 1500 kbps higher in bitrate

X264

Extra X264

theora

Extra Theora
theoraのほうがぼんやりしてるのにビットレートは高い、のはいいけどそのサンプルがなぜ東方永夜抄なのか!? よくしらないけどいったいどうやって手に入れたんでしょう。

日本はすごいんだということを知った#chromiumでした。

reblogと平和的自然淘汰

自然淘汰、と聞くと、環境に適合できない個体が生命を維持できなくなって死ぬ、というイメージがある。寒さに弱い個体が寒くなった時に死ぬ、とか、ある病気に弱い個体が病気にかかって死ぬ、とか。

素数ゼミはいかにして生存競争に勝利したか

去年、17年周期で一斉に出てくる17年ゼミはなぜ全部の個体が17年に一度出てくるのか、日本のように7年で成虫になるセミが毎年出てこないのはなぜなのかがわからない、という怒りをはてなダイアリーに書きなぐっていたchiaki25さんに素数ゼミの謎という本を紹介していただいた。この本ではなんで17年に一度一斉に出るようになったのかは3行くらいのあいまいな記述でしか説明されていなくてけっきょくわからなかった。けれども、17年に一度一斉に出るようになってから以降の素数ゼミだけが生き残る理由が確率的に説明されている部分で、今まで持っていた自然淘汰に対するイメージが変わった。ちなみに著者の吉村氏は数理生態学研究者です。

17年(または13年)周期の素数ゼミが生き残れた理由は、素数だとほかのセミと食料リソースの競合が起きにくいからだと思っていたら、そうではなくて同じ年に出てきたほかの周期ゼミと交雑してしまうと生まれたセミの周期がずれてしまって、その周期ゼミの個体数が減るのが原因だ、と説明されていた。
12年ゼミは15年ゼミと60年周期で出会って交雑することになる。その年、確率的に12年ゼミの半分は出会った相手のセミが15年ゼミなのでその子孫のセミが12年ではなく13年だったり14年だったり15年周期のセミになってしまう。結果として60年に一度15年ゼミと一緒に出てきて交雑してしまうたびにその個体数を減らしてしまう。
それに対して数学的にほかのセミと一緒に出てくることが稀な17年ゼミは、12年ゼミと交雑することになるまでの194年間は交雑することもなく17年ゼミ同士で子孫を残すためその個体数を保つことができる。一方でその194年の間に、12年ゼミは15年ゼミと3回の交雑を重ねて絶対数を減らしてしまう。194年に一度の年、数を減らした12年ゼミと個体数を保ったままの17年ゼミが一緒に出てくると、12年ゼミが出会う相手のセミは17年ゼミの確率が高いのに対して、多数を占める17年ゼミは12年ゼミと出会う確率は相対的に低い。結果として12年ゼミは17年ゼミと交雑する確率が相対的に高く、さらに個体数を減らすことになる。一方、17年ゼミはその個体数が多いがゆえに17年ゼミ同士で出会う確率が高く、個体数は減りにくい。

こうして年月が過ぎていけば、非素数周期のセミたちは頻繁に交雑を重ねて個体数を減らしていってゆるやかにゼロに近づいていく。素数ゼミも数百年に一度交雑して個体数を減らすこともあっただろうが、どちらが先に個体数だけがものをいう交雑によって絶滅するかといえばほかの周期ゼミとの公倍数が小さい非素数ゼミのほうだ。

素数ゼミが非素数ゼミにはない優れた能力でもってして、限られた食料を巡る暴力的競争で勝利して非素数ゼミを絶滅に追いやったわけではなく、しかし真綿で首を絞めるような優しく残酷な方法で非素数ゼミを絶滅させたのだ。

コピーによる平和的自然淘汰

そして話は現代に。

ほかの投稿をコピーしてそのまま投稿するreBlogの概念はTumblrだけにとどまることなく、今ではFriendFeedのReshare, reblip, Twitter上で生まれた文化としてのRetweet(それを集めているretweet.comもある)と、その後のサービスに概念だけでなくRe-*という名前とともにコピーされていっている。

Tumblrのdashboardにはネガティブなものがあまり流れてこない、と、昔誰かが書いていた(出典見つけられず)。
それはネガティブなもののreblogability(reblogされやすさ、ひとに受容されreblogしてもらえる可能性)がポジティブなものよりも相対的に低い。たとえネガティブなものがどこかのdashboardに混じって、その隣のdashboardにreblogを通じてコピーされたとしても、その何倍ものポジティブなものがコピーされるために、割合的には各ユーザのdashboardという世代を重ねるごとに相対的にその数を減らしていく。結果として誰かが明示的にネガティブなものを削除(暴力的淘汰)をしなくても、平和的に淘汰される(平和的に淘汰されるだけだから全然流れてこないわけじゃない)。

reblogのようになにかがコピーされて伝搬される現象は、新しいものではなく昔からある。マスメディアもブログも、どこかの企業が出したプレスリリースをコピーしたり書き換えたりして文章を作る。それを読んだ人たちがブログに書く。それを読んだ人がまた書いたりする。そうして人を介して広まるものがあることは昔からよく知られている。ただ、それらの伝統的プラットホームは、伝搬するときの時間コストが現代的Re-*プラットホームに比べて高いために平和的自然淘汰が進む前に人々の関心が次に移っていってしまった。現代的Re-*プラットホームでは伝統的プラットホームで10分かけてひとつの話を書く間に、その20倍くらいの話を伝搬させることができる。そのぶん短い時間で世代を重ねることができて、ネガティブなものはポジティブなものに比べてコピーされにくい、というわずかな差を体感できるようになったのだ。

GROOVISIONSによるHalfbyのPVみたいな農林水産省ビデオ(390円) “食料の未来を確かなものにするために”

実家に帰った時に宣伝しろと言われた気がするので宣伝。べつに農林水産省やYouTubeのまわしものでもございませんが。

ちょっとまえに話題に上っていたgroovisionsによるHALFBY – Rodeo MachineのPVをみなさまおぼえていらっしゃいますか。こんなやつです(毎回groovisionsが手がけてるんでしょうか)。

今回、このイラストのテイストはそのまま、音楽も農林水産省(というかおかたそうな官庁)とは思えないようなポップさで、日本の食料自給に関する現在の問題とその対策について大まじめに、でもちょっと楽しく説明してくれるビデオがYouTube農林水産省特設サイトで公開されています!3ヶ月前からあったみたいですけど…

ビデオは4分20秒。この短い時間で我が国の食料自給について造詣を深めることができます。

日本の食料自給率は40%で先進国では最低、江戸時代からの伝統的な料理であるてんぷらそばも、今では原料の80%は輸入に頼っているとかいうまじめなはなしを
にわとり
かわいいウシ(tumblrのユーザならウシがどれだけかわいいかはみんな知っていますよね)やブタやニワトリがひょこひょこするアニメーションといっしょに
うし
説明してくれます。

なんか結論は『日本は山ばっかだから平地を全部農地にしてもまだ半分足りません。だからみんな肉食べるのやめて魚にしようね』っていう話のようで日本の食料自給はエネルギー問題同様解決は難しいようです!
さかな

DVD配布!

このビデオ、小学生のとき以来忘れていたこの難しい問題について真摯にみんなで学びたいというあなたに農林水産省がDVDを送ってくれます!返信用の封筒に宛先を書いて、配布申込書と390円分の切手を同封のうえ、農林水産省大臣官房情報評価課企画係までお送りください。くわしくは農林水産省 DVDパッケージの配布についてから。

ジャケット

カレンダー!!

それだけではなく、机の上でさりげなく日本の食料自給について問題提起したいあなたのために平成21年のカレンダーも用意されています。groovisionsのイラストに官僚的文章の妙味、旧暦の日付まで入っているなげやりなカレンダー、ダウンロードして印刷すれば同僚の食に関する意識も自然と高まるに違いありません。

カレンダー

日本の食料の未来を確かなものにするためにみなさま御一瞥を。

ちなみにこれ、英語版のYouTube – Ensuring the Future of Foodもあって英語版は67,000回再生されているのに対して日本語版は31,000回にとどまっております。誰が見てるんだ。

program portalでのuuid登録を半自動でやるためのjavascript snippet

AdHoc配布はデバイスの登録が地味に大変だと書かれていたのをどこかで読んだので(たぶん2tch関連)、楽にすべくjavascriptのコードを書きました。全自動にするのは難しくてコード書くのよりも手作業にした方が早そうだったので半自動です。+ボタンは人間が押してワクを増やしてあげる必要があります。

Firebug consoleで実行して、手動で+を増やすと自動でデバイス名とuuidが埋まります。

window.setInterval( function () {
[
  "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx03f2",
  "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx10d4",
].map ( function (uuid, index) {
$('add_deviceNameList_' + index + '_').value = "dev" + "000".substr(0, 3 - String(index).length) + index;
$('add_deviceNumberList_' + index + '_').value = uuid;
} );
}, 100);

みんなの地図3体験レポート

注記

この投稿は「みんなの地図」モニター体験イベントの体験レポートです。

ブログへの記事掲載時には以下のワードを入れて頂きますようお願いいたします。

  1. イベント内容・商品についての率直なご感想
  2. 「ゼンリン」「みんなの地図3」の2ワード
  3. 製品ページURL(http://www.zenrin.co.jp/product/minchizu3.html)

・体験レポート掲載時にはタグの埋め込みをお願いいたします。

という条件の下で書いています。

Topimage

さいきんはあんまりですが、位置情報系のはなしには興味があってGPSのトラックログをgoogle maps に落とすとか、日本のヤフーのジオコーダを発掘したりしていたので、ちょっとGPS繋げてたらログとれたりしないのかなー、というくらいの興味でモニタに応募してみたら当たって、みんなの地図3をいじらせていただきました。

みんなの地図3はおおざっぱにいえば、カーナビの歩行者バージョンです。カーナビの歩行者バージョンといえばナビタイム。自分は4年くらいナビタイムのAU向けOEMなEZナビウォークのユーザなので、EZナビウォークと比べていいところ悪いところを中心にご紹介したいと思います。

GPS+PlaceEngine

みんなの地図3は、PSP用のGPSを繋げばGPSから位置情報を得て目的地までナビゲートしてくれます。残念ながら今回のモニタではGPSは品切れで数が調達できなかったそうで、GPS機能は試してないのですが、GPSがないときはPlaceEngineでだいたいの位置はわかるようになっています。
PlaceEngineだと、幹線道路沿いであればわりと正確(50~100mくらいの誤差)にとれますが、そこから一本はいると弱い(100~200mくらいずれる)かんじでした。

EZナビウォークはGPS+基地局との距離でナビゲートしてくれるそうですが、たまにおかしくなったりもするけどわりといい感じです。みんなの地図+GPSでは使っていないのでどっちがいいかはわかりません。

目的地の入力

目的地の入力は住所か駅名か施設名。施設のカテゴリで絞り込みもできます。みんなの地図は全部のデータをローカルで持っているので、住所を一段階ずつ選んでいくたびにサーバと通信し始めるEZナビウォークみたいにいちいち待たされたりしなくていいです。逆にEZナビウォークには電話番号で目的地を検索する機能があるけどみんなの地図にはありません。でも個人的には電話番号で目的地を入れたこと、ないです。

EZナビウォークのカテゴリを細かく見たことないので(いちいち通信が入るので細かく見るのがすんごい不快だっていうのもあります)もしかしたらEZナビウォークにもあるのかもしれないけど、みんなの地図にはトイレっていうカテゴリがあって、トイレが検索できます。ただ、きれいかきれいでないかに関わらず全てのトイレが出てくるので、きれいなトイレだけをリストするとかできるともっといいんじゃないかなー

ナビゲーションとスケジューリング

目的地と現在地を決めると、なんかてきとうに検索してくれるEZナビウォークと違って経路の探索条件を選べます。”おまかせ”と”屋根を優先”と”楽な道を優先”とがあって、たぶん距離と屋根と高低差を考慮してくれるんだと思います。そういう細かい指定ができるのはいいところですが、探索できる距離が10km以内に限られているので(徒歩前提なので距離が長くなると計算量が大きくなって大変だそうです)、道案内という目的では最寄りの駅から目的地に行くときにしか使えなさそうです。

担当のかたのおはなしによれば、当然電車の乗り換え情報も含めて経路の決定をしたかったけど、乗り換え情報は時刻表のデータ量が半端でなくて入れられなかったとのこと(あと3ヶ月に一回時刻表データのアップデートが必要になるのもちょっと不便そう)。

駅までどう行って、何時の電車に乗ってどこで乗り換えるか、っていうのを含めてスケジューリングする、という点ではEZナビウォークと比べたら勝てないなーという状況です。ここはネットワークに常に繋げられるケータイの強いところですねー。でもそれ以外のところはほんとEZナビウォークいいとこなかったです(はじめてEZナビウォーク使ったときはほんと感動したんだけど)。

地図をメモリにコピーできる!

えー、みんなの地図3はUMDが2枚入っています。みんなの地図を使うの1枚目のUMDだけで可能なんですが2枚目のUMDに入っている都市部の詳細な地図データなんかをまるまるメモリースティックにコピーして使うことができるようになっています。これがすばらしいっす。

地図データをメモリースティックにコピーしておくと、地図をスクロールして端まできたときに地図のデータをUMDじゃなくてメモリースティックから読み出すようになるので、データのロードで待たされることがなくなります。

EZナビウォークはこの点最悪で、ちょっとスクロールさせるとすぐサーバと通信し始めるし(しかもベクトルデータをロードしてくるだけのわりになんか遅い)、縮尺を変更するとやっぱりまた通信ですげーむかつくんですが、みんなの地図でデータをメモリースティックにコピーしている状態だとメモリースティックのアクセスランプを見てないとデータが読み込まれているのに気がつかなくて google maps でえんえんスクロールさせられるのと同じ感覚でえんえんスクロールさせられます(縮尺を変えたときはちょっとひっかかるけどEZナビウォークとは比較になんないほど快適)。ちなみにコピーに必要な容量は、首都圏全部コピーしてもたぶん500Mいかないと思います(東京都だけだと80Mくらいでした)。

この点はみんなの地図2にはなくてみんなの地図3にはある、ほんとにすばらしいところ。ちなみにUMDからメモリにデータをコピーするのとかSCEのひとが嫌がらなかったのか、という質問もあって、担当の方によればそんなに大変ではなかったそうですが、それでもやっぱりそういう政治的に面倒そうだけどやったほうがいいことをきちんとやっているところはかっこいいなーと思いました。

画面が大きいので地図が見やすい

使ってみて意外によかったのは、PSPの画面はケータイの画面に比べて物理的なサイズでだいたい倍くらいあるぶん、地図が見やすいです。端末によってはケータイのほうが解像度は高いんですが、画面が小さいと歩きながら見たりするのは厳しくて、その点はPSPで動くぶんみんなの地図の地図は見やすかったです。あと地図の表示モードがナイトとかアウトドアとか、道路強調、鉄道強調、住所強調、とか10種類くらいあって、このへんはさすが紙の地図を作っている会社だなあと思いました。機能的には地味だけど、地図のベクトルデータをどうレンダリングするかのデザインは地図の見やすさにとって非常に重要なところなのです。

あ、あと地図を見るときにはあんまり使わないんですが、L/Rで地図を回転させることができて、これがめちゃめちゃきれいにストレス無くまわります。EZナビウォークのコンパス付き端末だと向いている方向にあわせて地図が回転するんですが(みんなの地図でもGPSをつけていれば進行方向にあわせて回転してくれるそうです)、0.5fps出てないだろくらいに遅くて、それに慣れていたので感激でした。さすがゲーム用ハードウェアは違うと思いました。

GPSの位置情報ログがとれる

そしてロガーにとって何より気になるのがGPSの位置情報のログがとれるかというところ。これがみんなの地図3ではちゃんとGPSの位置情報ログがとれるようになっているのです(PlaceEngineで測位している場合のログはとれないそうです)。とったログは、いまのところみんなの地図の中で見ることはできないそうなのですが(ということは逆に考えると取ったデータをどうこうしたいというものずきな人のためだけにこういう機能を用意してくれているわけです!)、データは標準的な形式(名前も聞いたのですがメモり忘れていました)で書き出されているそうなので、おんなじゼンリンさんの製品だしDraw Track Log to Zenrin Zで紹介されているツールなんかで読み出せるんだと思います。

惜しいのはお聞きした話だとPSPの電池が3,4時間くらいしか持たないというところ。GPSのロギング専用端末には勝てないけど、でもお手軽ロギングプラットホームとしては最適です。

まとめ

みんなの地図3はPSPで地図を見るソフトウェアとしては、ほとんど完成されています。使っていてここはどうかなと思うようなところはほんとにほとんどありません。UMDからメモリースティックにデータをコピーできるところは特に秀逸で、データのロードで待たされたりすることがなくえんえん地図をスクロールしていけるところは感動的です(みんなの地図2ではUMDに読みにいっていたのでわりと待たされました)。

いまいるところから目的地までをどんな方法でもいいからナビゲートする、という点では、電車の乗り換え案内をしてくれるという点では、常にネットワークに繋げられるケータイの上で動いてるのもあってEZナビウォークのほうが優れています。

製品の企画をされている方に、いろいろ細かい技術的なはなし(GPSのログデータの形式だとか、みんなの地図にあるソーシャル要素のPetamapとのデータ交換形式とか)を聞いてみてもちゃんとご存じで(というか自分は知ってるうちに入んないかんじでした)、製品というか、地図だけでなくその周辺文化(GPSでログをとって楽しんでる人がいるとか….)にも造詣が深そうなのが感じられて、みんなの地図3で足りていない部分は次のバージョンで確実によくなるんだろうなーと思いながら、イベントから帰ってきました。

ゼロオーバーヘッド・ブロギングの時代

tumblrのファウンダーであるDavidのインタビュー Read/WriteTalk » Blog Archive » David Karp – CEO, Tumblr や、投資しているVC(25%くらい)のTumblrについての説明 Tumblr | Union Square Ventures の中や、lifehacker.comでの紹介 Geek to Live: Instant, no-overhead blog with Tumblrのタイトルで、no-overheadというキーワードが出てくる。いままでのブログに比べて、書くときに必要な付随する作業が少なくてブログを書くのにかかる時間が短くなる、という意味。

はっきりと文字で目にしたのはこのときだけれど、振り返ればWakoopaのときからこのno-overheadの流れがあった。

時間がないのでスケールしない

インターネットでどんなサービスを使うにしても、時間をかけないではできない。だからユーザが新しいサービスを使いはじめるには、今まで使っていた何かを止めないといけないし(自分はtumblrのdashboardをみはじめてdiggを見るのを止めた)、今使っているサービスを、新しいサービスを使うために使わなくなったりする(twitterをつかいはじめてmixiをやめた、とか)。
時間は有限なのだ。

アバウトミーにいくつか自分のフィードを登録してひとつにしてみたとき、自分がインターネットにかけている時間だと、一日にせいぜい20~30くらいのアクティビティしか生成できないことにきがついた。ブログは1日に書けても1~2, ブックマークで5~10, twiterで10~20くらい。逆に言えばソーシャルなCGMサービスは、一人のユーザが一日にこれくらいしか生成できないデータを、自分のところにどれくらい集められるのか、を巡って争っていることになる。たいへんそうだ。

でも、そこにLast.fmの再生した曲リストを入れると、一日のアクティビティは軽く100を越えるのだった。Last.fmの再生した曲リストはiScrobber経由で自動的に送られる。だから一度インストールしたらもう後は時間がかからない。新しく使い始めてもらうのに、今まで使っているサービスのどれかを止めて、その浮いた時間をあててもらう必要もない。

Wakoopaもそうだ。
いちどネイティブのアプリケーションを入れてしまえば、あとはキカイが自動で使ってるソフトウェアのログを取ってサーバにアップロードし続ける。ユーザの習慣の一部を変えてもらって(習慣を変えるのは大変なことだ。だからみんなテレビを見続けているし、メルマガを読み続けてるし、いまどきブログなんか書いてるし、朝早く起きれないでいる)、習慣的に使ってもらうだけの時間を作ってもらう必要はなく、一度だけ気まぐれでアプリケーションをいれてもらうだけでいい。

Wakoopaはともかく、この、ユーザの行動を自動で収集してコンテンツにするアプローチは、使ってもらうのに時間がかからないので(本当にゼロだ)、ユーザに習慣を変えてもらうような絶望的な努力を要求しないし、なによりスケールする。twitterはじめたからmixi使わなくなった、はあっても、Wakoopaをはじめるのになにかを止める必要はない。そしてtwitterをはじめたからといってWakoopaを使うのを止める必要もない。ユーザの行動を自動で収集してコンテンツにするアプローチのものは、ユーザにとって最も貴重で、(先進国においては)最も高価なリソースである時間を巡って競合することなく、いくつでも使うことができる。マシンのリソースが許す限り。

i-modeのあとに残されたもの

キカイでデータを集めるとして、じゃあ何がおもしろいかな、と思って、クリップボードのデータをモニタしてアップロードするやつとか(ControlCがほんとにまじめにやってるのを知ったときにはアホかと思った)、ライフスライスのように定期的にスクリーンショットをとってアップロードするやつとかをぼんやり考えてた。

去年のおわりにちょっとはやったMyMiniCityも、ニンゲンははじめにアカウントをつくってどこかに設置した後はキカイが全部やってくれる。MyMiniCityこそがUGCの最終形態 – webdogと書かれ、その中に

UGCサイトで大切なのはとにかく、ユーザーに手間をかけさせないこと。

という文章を発見したときにこのno-overheadはなにかのキーなのだと再認識した。

昔(2001年くらい)T氏が、彼の先生がi-modeの成功は普段の生活の中にある細切れのわずかな時間を積み上げることを可能にしたことだというようなことを言っていた、と言っていたことを思い出す。i-modeはユーザの今まで何にもならないまま残されていた分単位の時間に入り込んだ。いまでは空いている1分に満たない時間ですら、ケータイでともだちにメールしてみたり、R25のニュースを読むことに費やされる。だからもうユーザには1分単位の時間ですら残っていない。

でも、必要な時間がゼロ、という世界には、文字通り無限の可能性が残されている。

補足 2008.3.11

思ってたより多くの人に読んでもらえたみたいでうれしいです。
mal_blue@tumblrで、キカイが自動でデータを作る(zero-overhead)のと、ニンゲンがデータを作るのを楽にする(less-overhead)は分けて考えるとより考えが深まる、と指摘をいただいき、自分でも書きながらもやもやしていた部分について考えるきっかけになったのでご紹介しておきます。

See Also

盛り込みたかったけどうまく入れられなかったもの。

Memory Plus 生ログ – 気紛 – きまぐれ -
キカイで自動的になにかをするのは、必然的にログをとることにも通じている。ほとんど偏執的ロガーのように思える研究者たちの話。
I am gathering you
スクリーンショットライフスライス。

WordPressのテーマをかえた

ずっと前から変えたいと思ってたのをやっと変えた。Windowsからだと相変わらず汚い。フォントがよくないだけだ。OSXから見たら文字がきれいすぎてきれいに見える。
Hemingway WordPress theme widgetized for WordPress 2.2+ – Ninja Monkeys!

ついでにWordpressのバージョンも上げた。あげるときは慎重にしないとだめって知ってた気がするけど、てきとうに上書きしたら重大なトラブルに。adminでログインできるのに権限がないとか言われてなにもできない。db見ても問題なさそうなんだけど….

ほんとはこれもpostできない。ソース書き換えて権限ごまかした。
wp-includes/capabilities.php:454のあたり。
Wordpressのコードはプログラムを書くのにあまり慣れていないひとがいろいろ覚えながら書いていったんじゃないのかというかんじにひどいコードと努力したあとが見られる(でもかえって難解になってる)コードがまじっててわかりにくい。

しばらく(当分?)おかしいところがありますがご容赦ください。

Scissors, Fools, Tools

このサービスはこういうふうに使うもので、そういう使い方は間違っている、正しくない、みたいなのを見かける。ひらめいったーで、それ用に作られたツールはないけれど、これをこうつかえばそのまま代用できるじゃん、みたいなのを見かけたりする。

たいていのサービスは、つくったひとがこういうことがしたい、というのを元に機能やみためがデザインされている。Creating Passionate Users: Making happy usersに書いてあった

“Make the right thing easy and the wrong thing hard.”

というフレーズそのままで、そのサービスが想定している使い方であれば、かんたんに使えるし(想定している使い方をかんたんにできないのならそもそもデザインがおかしい)、想定していない使い方だとかんたんにはできないことが多い。

想定されていない使いかた

でも、たいていのサービスは、想定されている使い方以外の使い方ができる。カレンダーの予定欄に日記を書くことだってできるし、ブログにひたすら写真だけをアップロードして写真倉庫にすることだってできる。

想定されていない使い方をするのはかっこいい。想定されていない使い方をしているのに、いちばんはじめに出会ったのは8年くらい前だろうか。とある日本のサイトに設置されているチャットに、なぜかドイツの人たちが入り浸ってドイツ語でチャットしまくっていた。あるツールが設置されている理由を完全に無視して他の使い方をすることができるというのにそのとき気がついた。

2chくわしくないのだけれど、2chでスレにしおりを入れるというのも、かっこよかった。

 −−−−−−−−−−−−−−−−−−−−−−−−−−
俺様用しおり
 ∧_∧
( ・∀・)< 今日はここまで読んだ
−−−−−−−−−−−−−−−−−−−−−−−−−−

みたいなカキコをする。ほんとにしおりとして使うためにカキコしてるわけじゃないだろうけど、みんなで使うためのものを自分だけのために使うという考え方に、ドイツ人がチャットを占拠しているのとおなじものを感じた。

そのツールを作ったひとが想定している使い方をばっさり無視して、自分の好きなように使うのはかっこいい。

メッセンジャー

ある日、自転車メッセンジャーのスタイルを読んで

無鉄砲で危険で、時には法律違反だって思われるような走りで沢山の人をイライラさせたりしてたら…ほら、これって若者の崇拝するアイコンの持つ条件がほとんど揃ってますよね!(笑)

の部分で人間の本性を考えるに似たようなことが書かれていたのを思い出した。

男性は痛みによく耐え、地位や注目や、そのほかのあやしげな報酬のために生命の危険をおかそとうする意欲も強い。「崇高なまでにばかげた方法でみずからを遺伝子プールから抹消し、人類の長期の存続を確実にした個人」に毎年贈られるダーウィン賞は、ただでコーラを手に入れようとして販売機を傾け、その下敷きになってしまった男、だれがいちばん強く対戦者地雷を踏みつけられるかを競った三人の男、気象観測用の気球を結びつけた芝生用のイスに座って地上二マイルまで飛びあがり、海まで流されたパイロット志願者(彼はヘリコプターに救助されたため、選外賞しかもらえなかった)などである。

人間の本性を考える(中)124ページより。

ちょうどこの本を読んでいたときに小学生が閉まる防火シャッターをくぐって遊んでいて挟まれる事故があったので、よく覚えている。でも、小学生の男の子的には確実に防火シャッターが最も閉まっている状態でくぐり抜けたやつが当然偉くて賞賛の的になるのは当然だ。今の自分でも共感できる。自分も階段を何段飛ばしで飛び降りれるか、みたいなのをあやしげな報酬のためにやった。

大人になると、そのあやしげな報酬がどれくらい実体のあるものかを判断するようになるけれど、それでもやっぱり心の中にはそういうあやしげな報酬のために危険をおかそとうすることをかっこいいと感じる部分はそのまま残っている。馬鹿げたことをしているという目で眺めつつも、賞賛を贈らないではいられない。

Napsterは、圧倒的に便利だったというのもあるけれど、それだけではなくてインターネット上に無鉄砲で危険で、時には法律違反だって思われるような小学生男子的価値観と照らし合わせて”かっこいい”ものをはじめて(自分の知る限り、だけど)みせてくれたところにしびれたのかもしれない。

マッシュアップ

そんな小学生男子的価値観でいけば、サービスをサービスが想定している方法で使うことほどださいものはない。nisshi.yugop: About Samplingで書かれている

所謂マッシュアップ(死語)における引用元/引用先の関係としては、こんな風に引用元を全くもって粗末に使い倒し、美味しいとこだけおんぶに抱っこしつつ、ひょいっと違うレベルに組み替えてしまう、てのが最高なんだと思う。よくある「とりあえずマッシュアップしてみました!えへ!」的なサービスって、「お前らGoogleとAmazonの奴隷か」みたいな感じが否めないんだけど、このサービスぐらい「美味しいとこだけイタダキマース」感が強いと、 YouTubeの中の人、ちょっとイラっとしそうだもん。

の部分には、上に書いた小学生男子的価値観でかっこいい!というのがあるんじゃないかと思う。用意されたAPIを、相手の意図とは違う、世の中の作法を無視した方法でもって使うからかっこいいのだと思う。

沢山の人をイライラさせたりあやしげな報酬のために才能の無駄遣いをすること、それは昔に男子小学生だったことがあるひとならどこかにやっぱり今でも持っている評価基準なんじゃないかとこのごろ思う。

Firebug1.1にするとFirefox3(Gran Paradiso)でFirebugが使える

補足 2008.5.16

Firefox3beta3くらいからはFirebug Releasesにある1.2alphaしか動きません。

古いはなしですが今日知りました。
Please try Firebug 1.1 on Gran Paradiso (Firefox 3.0) – Firebug | Google Groups に書かれているとおりでFirebug1.1ならFirefox3でも動きました。時々表示が乱れたり、不安定だったりもしますが使えないよりぜんぜんよし。

ダウンロードはfireclispから。

そのほか細かい変更点もあるみたいです。
Firebug 1.1 (beta) at Michael Sync

HTMLツリーとエレメントの情報が同時に見られるようになったのは地味に便利。

mixiステーション2.2のリリースとFirefox版mixiツールバー

前にどこかでmixiツールバーを開発されているグルコースの人のブログでFirefox extensionのつくりかたのはなしが書かれていたので、これはFirefox版を作ってるってことかなーと思っていたらFirefox版、出てきました。[mixi] mixiツールバー機能について

インストールしたもののなにが変わってるのかよくわからなくて、mixiステーションを起動したときに新バージョンの修正点が書かれていたやつをもう一度見られないかと探して http://download.mixi.jp/station/update/mixi_win.plist にアクセスしたら表示されるのを発見しました。

今回はFirefox版のリリースがメインのようで、とくに新しい機能とかAPIがあるわけではないようです。

mixiステーション、入れておくと新しくなったら教えてくれるので地味に便利です。

英語版のFirefoxでXULのエラーが出る問題

英語版のFirefoxだとXULのエラーが出てきます。

原因はchrome.manifestが

locale	mixi_toolbar	en-US	jar:chrome/mixi_toolbar.jar!/locale/en-US/
locale	mixi_toolbar	ja-JP	jar:chrome/mixi_toolbar.jar!/locale/ja-JP/

英語のlocaleを定義しているけれど、実際にはlocale/en-USがはいってないのが原因でした。
en-USの行を削れば英語版のFirefoxでも問題が無くなるので削ってください。よろしくおねがいします。

Technorati Tags: ,

tumblr 3.0

ほとんど内容とは関係ないんだけどTräumen Vinyl von elektrischen Schafen?を読んで昨日のことを思い出した。

きのう自宅でtumblrがみたくなって(なんでだったか忘れた)、ひさびさWindowsマシンを起動したらFirefoxにFirebugしか入ってなかった。
いつもの快適さでTumblrを楽しむには

こんだけのスクリプトを入れなければいけないのに気がついた。

こんだけのスクリプトを入れるのと入れないのとではTumblrのつかいごこちには格段の差があって、それがそのまま1秒間に見られるpostの数に直結して、それはそのままどれだけ楽しめるかにも直結する。同じ時間でたくさん見られた方が楽しいpostに当たる確率は高くなる。
Tumblrの素のままのデザインでは、ぜんぜんRPM(Reblog Per Minute)なんて指向されていないし、Reblogされた写真はそもそも白くなってるし、写真はクリックしないと大きくならないし、次のページを読みにいくには次のページリンクを押さないといけない。
Tumblrのもともとのデザインは、いま日本のユーザがTumblrを楽しんでいるような使い方を想定してデザインされてはいない。

そんなサービスの上に、いろんなスクリプトを積み上げて、自分たちが好きなように目で見たときのみえかたを書き換えるだけでなく、サービスをどう楽しむかまでを書き換えている。誰かがハックして楽しむことができる余地を残すことは大切かもねとどこかで書いていたけれど、Tumblrにはどうでもいいような機能がなかったぶん、どうでもいいような機能をいくらでも追加できたからここまでこれたのかもしれない。

だからTumblrがv3でどうでもいいような機能を押し付けがましくのせてきてぼくらの遊ぶ余地が無くならない限り、どう変わろうと(もしくはどんなに単体ですばらしいおもちゃが追加されようと)またみんなで好き勝手なスクリプトをTumblrのうえにたくさん積み上げて、好き勝手に楽しむだろう。

Davidはsenduitにしても必要ないつまらない機能をつけたりしないことを哲学にしているようなのでそんな心配はいらないと思うけど。

4,000万ユーザのFrance telecomがOpenIDを採用

MoMB: OpenID d’Orange より。

アップル、フランスで純正SIMロックフリー iPhoneを販売 – Engadget Japanese で有名になったフランスの最大手(?)のFrance telecom(NTTの携帯部門がDoCoMoみたいにFrance telecomの携帯部門がOrangeなのでしょうか)がOpenIDを採用だそうです。リンク先はフランス語で読めないので blognation France » Blog Archive » “Et puis zut” France Telecom Announce OpenID For All に書いてあるのを見ると

France Telecom at Digital ID World today in San Francisco have just announced that all France Telecom subscribers (~40-million — the country is about 65-million people) now have an OpenID.

6,500万人しかいないフランスで4,000万のOpenIDが作られることになるとのこと。

This makes FT the first major telco to support OpenID! They’re also talking about allowing access to Orange branded services with external accounts (hopefully OpenIDs). They just showed a draft screenshot of OpenID logins along with Google and Yahoo auth. Go to http://openid.orange.fr to learn more. Dave Recordon

とうぜん世界ではじめての(メジャーな、って書いてあるのは他に例があったのか?)電話事業者による採用だそうで。さらにGoogleとYahooでも認証できるスクリーンショットが載ってるよって書いてあるけど、見に行くとぜんぶフランス語で書いてあるのでどなたかフランス語の読める方お願いします~~

ユーザが自社のOpenIDで他のサービスを利用するようになれば、他のキャリアにスイッチしようが無くなるというところを見越してなのでしょうか。なににしても信頼性が第一に問われる大規模な通信事業者がまだまだ普及していない新しいテクノロジーを採用してしまうところがすごいです。よのなかすごい勢いで進化してる。いまごろ2.0では遅いっす!

と思ったらちょっと古いニュースでふつうにTechCrunch Japanese アーカイブ » France TelecomのOrange携帯サービス、OpenID採用へとか載ってました….

さらにフランス語しか書いてなくて分からないけどMoMB: dream’OrangeものってるのでOrangeはまたなんかへんなことやってるのでは。

kill all snap.com thumbnails popup

前もほんとにうざいから消そうとしてなぜかうまくできなくてあきらめてたけどアタマにきたのでもう一度ソース見たらすぐわかった。

hostsに
127.0.0.1 spa.snap.com glance.heartrails.com shots.snap.com
を書く。

ポップアップでサイトのサムネイルなんかみたくねーつーの。
それともあれ入れてるとデータとってくれたりするとかなんか便利だったりすんの?

2008.8.13追記。
glance.heartrails.com も追加。

googleの検索履歴が18ヶ月で消えちゃうようになる?

TechCrunch Japanese アーカイブ » プライバシーが流行の定番に で、なんか

Googleが「ユーザーの検索履歴保存期間を2038年までから18ヶ月へと短縮する」、と発表した。

なんて書かれてるんだけどこれは Google Web History で見られる検索履歴のデータが含まれちゃうのかな。ちょっとかなしいけど18ヶ月あれば実用上は問題ないかな。履歴の完全性が失われるっていうのは精神的に悲しいけれど。

キカイにコードを生成させること

きのう一日かけて、けっきょくキカイでXPathを生成すると、すんげー硬直的なのができて変化に対して強いものを作ろうとするとニンゲンの助けが必要だって言うことがわかった。

だけどうちに帰るときに、キカイが生成するコード(今回はXPathなんだけど)を気にする必要なんてないと思った。ソースが変わると確かにうまくマッチできなくなるんだけど、でもそしたらもっかいスクリプトを走らせてXPathを生成しなおせばまた動くようになる。だからうまくデータが取れたかどうかのvalidationをきちんとしてあげればいいだけのことだ。

いままではマッチに失敗するようになったら、ニンゲンがソースを見て、アタマを(ほんのちょっとだけ)使って直してあげる必要があった。でも、キカイで生成するのならば、ニンゲンは何も考えずに一度スクリプトを走らせるだけで済む。このプロセスは自動化できるので劇的にソースが変わらない限りニンゲンは何もしなくても済むようにもできる。実質的にニンゲンが何もしなくても、コードが常に正しい結果を出力するのならば、その中で使われているXPathが汚いことの何が問題だろうか。キカイが生成してキカイが解釈するだけのものにニンゲンにとっての美しさなんて必要ない。

それはコンパイラの吐き出すアセンブラコードがニンゲンから見たら美しくなかったりするのとかわらない。コンパイラが生成するアセンブラのコードが人間から見て美しくないからといって我々はコンパイラを使うことをあきらめたりはしない。

それにしても、いまでは

  1. テンプレートエンジン用のコードをsmartyで書く
  2. smartyが吐き出したPHPコード(ニンゲンの目にはとても汚い)をPHPのopcodeに落とす
  3. PHPのopcodeをzendVMが実行する
  4. zendVMの中でCのコンパイラが吐き出したx86バイナリが実行される
  5. x86命令がCPUの中でuOps分解される
  6. よくしらないけどuOpsが実行される

っていうすごいことになってる。

こうなってるのはこういう手法が有効だからだ。
だから今までニンゲンが書いてたいものをキカイに書かせるのは悪くないアイディアなはず。

aboutme moo card

先週の土曜日くらいに届いてたのをずっと書くのを忘れてましたがサブドメインのURLをつくったひと1000名様にプレゼントだったmooのミニカードがきました。当たりましたメールも何も送らずに発送してびっくりさせてくれるあたり、誕生日にはメールをキカイに送らせてくるいままでのニフティとは一線を画しています。

Dsc03726

CSS Niteについてのコメントについて謝罪

Transrain – CSS Niteについて考えてみる でコメントして後で収支を CSS Nite公式ブログ:収支概算を公表します:[Web標準の日々] で公開されてるのを読んで自分の認識が間違っていることが分かったのでここで謝罪します。
大きなイベントに多大な手間がかかること、チケット代のほとんどが会場費、人件費で消え、来場者数が1割減ると赤字になるくらいの値段で運営されていることには考えが回っていませんでした。小さな勉強会ではなく、大きなイベントで、かつウェブ標準という直接誰の利益にもならない事柄を扱うことは、業界全体の発展、利益には欠かせないことだと考えを改めました。

ただ、当初自分がなんかうさんくさいと感じていたのは事実で、それは多くの人数を集め、小さな勉強会などからすると高いチケット料で頻繁にイベントを開催されているけれど、誰がどういう気持ちでやってるのかが見えてこなかったところにそう感じていたのかなと思います。主催の鷹野さんが自分たちの名前を出すことを控えておられたからこそ、イベントに対する志をアピールしたりはされなかったのだと今では納得できますが、はじめはそういう印象を受けていました。

鷹野さんがCSS Niteにかける意気込み(それこそブログで中身がどうなってるのか分からないと書かれたことに対して、真摯に誤解を解き、相手に理解される努力をするところ)を知り、感銘を受けました。今後もCSS NiteがWeb標準の普及に影響力あるイベントとして長く続いていくよう、陰ながら応援していきます。

はてなブックマークの日本語URLの扱いがへんな件

URLが長くなるのがいやなので、いつもはslugを設定してるのだけど mixiのあしあとAPI発掘 はslugを設定するのを忘れてタイトルがそのままURLになってたのだけど、そうするとはてなブックマーク – ido.nu の注目エントリーでひどいことになってた。

リンクされているURLをみてみると

  • http://ido.nu/kuma/2007/06/29/mixi%e3%81%ae%e3%81%82%e3%81%97%e3%81%82%e3%81%a8api%e7%99%ba%e6%8e%98/
  • http://ido.nu/kuma/2007/06/29/mixi%E3%81%AE%E3%81%82%E3%81%97%E3%81%82%E3%81%A8api%E7%99%BA%E6%8E%98/
  • http://ido.nu/kuma/2007/06/29/mixiのあしあとapi発掘/
  • http://ido.nu/kuma/2007/06/29/mixi%25e3%2581%25ae%25e3%2581%2582%25e3%2581%2597%25e3%2581%2582%25e3%2581%25a8api%25e7%2599%25ba%25e6%258e%2598/

の4つがある。

wordpressがエントリのpermalinkとして表示しているのは1番目のやつ。2番目は16進でエンコードしたときのA-Fの範囲を大文字にしたもの。3番目はエンコードされてるのをデコードしてそのままUTF-8で出力しているもの。4番目は、ひとつめのURLをさらにもう一度URLエンコードしたもの。これらがべつべつのものとして認識されるということは、エンコードされている部分を含めて case-sensitive で単純に違うものは違うものとして認識しているっぽい。

4番目はbookmarkletの問題かなにかっぽいのでおいとくとして(むしろこのURLでちゃんとエントリが表示できるWordPressかmod_rewriteかなにかのほうが仕様としておかしい)、エンコードされているものはほんとはURLにそのまま書きたいけどHTTPの仕様上直接書けないのでエンコードして表現しているだけなのだから、エンコードされている部分はデコードしてから集計してあげるのが正しいのでは。

日本語だとURLが極めて長くなるのが困ったところだけどSEOいいとかでURLにタイトルを入れているところは多くなってきていて、VOXやamazonでも使われているのでなんとかしてもいいんじゃないでしょうか。

追記

http://ido.nu/kuma/2007/06/29/mixi%u306E%u3042%u3057%u3042%u3068api%u767A%u6398/ っていうUnicodeをエスケープしたバージョンもありました。