Hatena::Groupasakura

浅倉卓司@blog風味? このページをアンテナに追加 RSSフィード

Error : RSSが取得できませんでした。

2005-12-26(Mon)

ロングテイルについてのまとめ。

| 23:57 |  ロングテイルについてのまとめ。 - 浅倉卓司@blog風味? を含むブックマーク  ロングテイルについてのまとめ。 - 浅倉卓司@blog風味? のブックマークコメント

 もはやロングテイルなんて言葉も見かけなくなりましたが、今年の前半に色々書いたので、いちおうまとめておこうかと。


 そのうち計算しようと書いたのに結局計算しなかったのは、ロングテイルについての考え方が間違ってるんじゃないかな、と感じたからだったりします。

 ロングテイルっていうと、だいたいこんな感じの図で説明されていて、

f:id:asakura-t:20051226232927p:image:w240

計算もそれにあわせてやってたんですが、実際のロングテイルはこんな感じ

f:id:asakura-t:20051226232957p:image:w240

なんじゃないかと。

 要するに「ヘッドが切り捨てている右側」じゃなくて「ヘッドが切り捨ててる下側」が「テイル」の部分でしょ、と。なぜかというと、ヘッドの下の横線の位置がいままでに必要だった経費(コスト)を示すから。ロングテイルの時代になって経費(コスト)が極限まで下がったから緑の部分が採算がとれるようになった、ということでしょう。

 んでもって、前に計算した時に出てきたn=1.608の所で上と下に切り分けると、ヘッド側:0.4776、テイル側:0.5224になる、と。まあ実際には経費(コスト)が0にはならないのでテイル側のほうが大きくなるとは限らないけど、ヘッド側並の面積はとれそうですなぁ、というのがロングテイル論だったのでしょう。


 こんなコトはどーせ誰かが指摘してるでしょう、と思っていたんですが、なんか見かけなかったんですよね。まあ今年の後半はロングテイルのブームが終わってたからかもしれないけど。

 僕が放置していたのは単に図を描くのが面倒くさかったからですが。図を描くのに便利なツールはないですかね?

firewoodfirewood2006/01/06 00:39右方向が扱う品目数とかチャンネル数で、積分した領域が購買層とか視聴者だから、上の図で良いんじゃないかと思います。
Amazonの場合を考えてみると、品目数を10倍にしてもコストは10倍にならない(逆に品目数を1/10にしてもコストはあまり変わらない)のではないかと。

asakura-tasakura-t2006/01/06 09:16 ええ、通常は上の図で構いません。そしてそれはパレートの法則に従います。
 ところでロングテイル論は「Tail側がHead側より大きくなる(あるいは無視できないくらい大きい)」というお話なのですが(だから「パレートの法則を越える」なんて書かれたりもする)、上の図のTail側はHead側より大きくならないし、無視しても良いくらい小さいのです。したがって「ロングテイルを語るときに上の図を使うのは間違いだろう」というのが僕の論旨です。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051226

2005-12-22(Thu)

publicはname、privateはtag。

| 15:28 |  publicはname、privateはtag。 - 浅倉卓司@blog風味? を含むブックマーク  publicはname、privateはtag。 - 浅倉卓司@blog風味? のブックマークコメント

 無名ファイルについては昔ちょっと考えて、せっかく無名にするんなら名前をつけたときに見た目が変わればいいのになんて考えたりもしたのですが。

 半年ぶりに似たようなネタを見かけて*1 *2「お?」とか思ったけど、より深い考察がなされてるようではなかったのでちょっと残念。


 「無名ファイルが作れればいいのに」と思ったのは溜まった画像ファイルを見たときだったのですが、まあ基本的に個人で溜め込むようなファイルならたいてい名前がなくったって困らない。自分で「新規作成」するときなんかは面倒でデフォルトのままにしちゃうしね。

 でもこれが他人に提供するときには「名前」を付けなくちゃ困るんだよね*3。そうしないと意思の疎通ができないから。だから「アプリケーションという他人」に対しても「ファイル名」を提示しなくちゃいけない。

 だったらせめてMy Documentsの下*4だけでもファイル名が不要にならんかな、という思いでWinFSには期待していたのだけれど、しばらくは提供されないみたいだし。いや、WinFSがそんなファイルシステムなのかは知らないけどさ。


 でまあ、My Documentsの中にあるジャンクの中からモノを探す時にはtagが付いていたほうが探しやすいじゃろ、というのにはまあ同意する。

 けど、tagがtreeであるdirectoryに劣っている点もありまして。具体的に言うとtagは基本的にフラットだから、お互いの関係が分からないんだよね。

 例えば「マイメロ」と「ゾイド」と「アルバトロス」というtagがあったときに、どれが「アニメ」なのかは分からない。これに対してdirectoryなら「アニメ」の下に「マイメロ」「ゾイド」があって「漫画」の下に「アルバトロス」があるだろうから、それぞれの関係が分かるっていうメリットがある。

 このおかげで正しいキーワード(tag)が分からなくても、その親キーワードが分かれば探せるっていうメリットがあるのですよ。

 それを解決するにはtagにtagを付ける作業が必要になるわけですが……そこまで考えてたりはしませんよね?

*1http://d.hatena.ne.jp/propella/20050822/p2

*2http://mojix.org/2005/12/12/223718

*3弾さんが言ってることはそういうことなんだと思う。

*4:ここに置かれるのは個人的なファイルだけのはずなので。

kokogikokokogiko2005/12/23 08:21そもそもMy Documentsというのが大属性ですわな。

asakura-tasakura-t2005/12/23 13:45まあそう。「パーソナル」コンピュータであれば昔のMacのような手法もアリだったとは思うけど、今は違いますからね。
なので、PDAはタグでファイル管理ってのもアリな気はする。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051222

2005-12-15(Thu)

みんな考えることは同じなのねー。

| 11:20 |  みんな考えることは同じなのねー。 - 浅倉卓司@blog風味? を含むブックマーク  みんな考えることは同じなのねー。 - 浅倉卓司@blog風味? のブックマークコメント

 分かち書きについては昔ちょっと考えたよーなことはやっぱり他にもやってる人がいるのねー、とか思った。

 前のEstraierでもやってたのか。それは知らなかった。


 僕のやりかたは「を」を特別視して切り分けることと、漢字1文字の後ろに平仮名がきている時はそれをセットにするというのが特徴かな。それで気持ち精度が上がると思ったんだけど、実際に精度が上がってるかどうか調べる方法が分からなくて検証してないという。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051215

2005-12-14(Wed)

Amazonはメタデータが不足してる、の続き

| 16:02 |  Amazonはメタデータが不足してる、の続き - 浅倉卓司@blog風味? を含むブックマーク  Amazonはメタデータが不足してる、の続き - 浅倉卓司@blog風味? のブックマークコメント

 メタデータの項目はどうしようか、そういや前に作りかけた時はやたらと項目が増えてカラムを増やすと大変なことになった気がするなぁ、そもそも書籍とDVDでは必要な項目その他が違うし、じゃあメタデータの項目は自由に増やせばいいじゃん、あれそーいやGoogleBaseってそういう構造だっけ?*1


 ……とか思って「じゃー誰か連携するの作るじゃろ」で放置予定だったのですが、んでも巻数順に並べ換える機能とかなさそうだし、とりあえずスキーマだけ考えた*2

CREATE TABLE `ASINメタデータ` (
  `asin` char(20) NOT NULL, -- あれ、ASINって何桁だっけ?
  `メタデータ値ID` int unsigned NOT NULL,
  `serial` int unsigned,
  UNIQUE (`asin`, `メタデータ値ID`),
  KEY (`メタデータ値ID`),
  FOREIGN KEY (`メタデータ値ID`) REFERENCES `メタデータ値` (`id`)
);
CREATE TRABLE `メタデータ名` (
  `id` int unsigned NOT NULL auto_increment,
  `name` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY (`name`)
);
CREATE TABLE `メタデータ値` (
  `id` int unsigned NOT NULL auto_increment,
  `メタデータ名ID` int unsigned NOT NULL,
  `value` text NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE (`メタデータ名ID`, `value`),
  KEY (`value`),
  FOREIGN KEY (`メタデータ名ID`) REFERENCES `メタデータ名` (`id`)
);

 項目名なんて気にせずタグで一律管理ってのも考えたけど、それはそれで情報量が減るし、まあタグで入れるときに[シリーズ名:星界の紋章:1]とかで管理するようにすりゃええじゃろとか思ってとりあえずこんな形に。

 これでちゃんと要件が満たせるのか(目的の情報が引けるのか)とか、パフォーマンス的に問題ないのかとか、そのへんは全然検証してませんけど。とりあえず忘れないうちに頭の中に浮かんだものをダンプしとけと。


あれ、日本語で表示されるようになってる。

| 16:02 |  あれ、日本語で表示されるようになってる。 - 浅倉卓司@blog風味? を含むブックマーク  あれ、日本語で表示されるようになってる。 - 浅倉卓司@blog風味? のブックマークコメント

 MySQLドキュメントを見に行ったら、日本語で表示されてびっくり。あー、トップも日本語だ。

 いつのまに……。

*1:調べてないけど。

*2:英語名考えるのがヤだったんで、とりあえずテーブル名その他は日本語にしてある。何かいい名称はないですかね。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051214

2005-12-13(Tue)

もっと学校で勉強で勉強しておけば良かったとつくづく思う。学校の勉強が役に立たないなんて言ったのは誰だよ。

| 17:42 |  もっと学校で勉強で勉強しておけば良かったとつくづく思う。学校の勉強が役に立たないなんて言ったのは誰だよ。 - 浅倉卓司@blog風味? を含むブックマーク  もっと学校で勉強で勉強しておけば良かったとつくづく思う。学校の勉強が役に立たないなんて言ったのは誰だよ。 - 浅倉卓司@blog風味? のブックマークコメント

 僕も確率は専門としてはほとんど学んでないです。なので、前に書いたのは高校の確率のことです。

http://d.hatena.ne.jp/succeed/20051213

独立事象と直交概念って違うんじゃないかなあ?

 元ネタが直交概念か独立事象かなんていうのはどうでも良くて、単に同じことを考える(述べる)のに自分なら独立事象を考えるなぁと思ったのと、じゃあその差異はなんだろう? と考えたときに幾何と確率に対する馴染み深さを思いついただけです。

 元ネタをそれが正しいのか否かを検証するときに、「そのベクトルの内積の和が0であるか」を考えるより「相互の確率に影響があるか」のほうが(僕には)分かりやすいと感じた、というのもありますけれど。


 ――とここまで書いて、「あ、技術の『方向性』という発想だから、ベクトルで、直交なのね」とかいまさら思ったり。うーん、方向性かー。いまいちピンとこないのは、自分がやってきた(学んできた)ことはだいたい同じ方向を向いてると思ってるから、かもしんない*1

そうじゃなければシミュレーションで10000回繰り返した方が大抵早く終わる。

(略)

だけれども、それは怠惰な思考の始まりでもある。

 モンテカルロ法を馬鹿にするな~(w

 ま、こういうのはTPOにあわせて手頃なツールを使うのがよろしいかと。「早く終わる」程度のオーダーならそれでいいし。実際には計算量を減らすためにあーだこーだ考えるわけですしね。

 でもって、確率論をシミュレーションにしか使わないのはもったいないと思いますよ。

*1:いちおう学校では演算回路の作成とかCPUの作成とかしたし、上のレイヤだとネットワークとかデータベースとかもやってたし。ヒューマン・インターフェイスには手を出しこそねたけど、仕事をしてからは考えざるをえなかったしね。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051213

2005-12-12(Mon)

確率論はとってなかったりするのかな?

| 00:38 |  確率論はとってなかったりするのかな? - 浅倉卓司@blog風味? を含むブックマーク  確率論はとってなかったりするのかな? - 浅倉卓司@blog風味? のブックマークコメント

 d:id:naoyaさんの「直交する技術から複数のものを学ぶ*1」を見て「なんでわざわざ直交言うかなー、独立事象でええやん」と思ったわけですよ。だって、関係しない事象のことはふつう独立事象って言うじゃないですか。

 なんでじゃろとか思っていたら弾さんのトコに「依存関係がないことを英語でもこう呼ぶ」なんて書かれてて、「へー、普通に言うんだ」なんて感心したり。

 で、さらにTBにあった「直交概念」を読んで、ふと思ったわけですよ。ひょっとして、普通の人には確率より幾何のほうが馴染み深いんじゃないか、と。いやこの記事を書いた人は論理式書いてたりするから確率もやってそうだけど、逆に「論理式、何それ?」な人は確率やってなさそうな気がして。


 そういや最近読んだ「使える!確率的思考」には「学校の確率はイヤなモノ」的なことが書かれていて、その時は「確率はかなり楽な勉強だったのに。営業トーク?」としか思わなかったのですが、案外みんな苦手にしてるんでしょうかね。

 まあ、だとしたら小島寛之さんのこの2冊はおすすめ。

使える!確率的思考 (ちくま新書) 使える!確率的思考 + 確率的発想法~数学を日常に活かす 確率的発想法

 いや、確率が得意だった人にこそおすすめかもしんない。

 特に「確率的発想法」の「リスクと不確実性の違い」や「コモン・ノレッジと集団的不可知性」、あるいは筆者の語る意思決定理論はなかなか面白かったです。

 たぶん弾さんがそのうちレビュー載せるんじゃないかなぁ。片方は筑摩だし。それとも弾さん的には物足りない本でしたでしょうか。

*1:ところで、この記事には「ローレベルレイヤを極めているバイナリアンは、どことなく数学的にコンピュータにアプローチすることに長けている人たちというイメージだった」なんていう恐ろしいことが書かれていて、「だったら中高生の頃のほうがオレは数学できてたことにならね?」なんて思ったりもしたのですが。そもそも「数学的」とか言われても範囲が広すぎて「どの数学よ?」とかしか言えないんじゃね?

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051212

2005-12-05(Mon)

SmartyのTips

| 18:33 |  SmartyのTips - 浅倉卓司@blog風味? を含むブックマーク  SmartyのTips - 浅倉卓司@blog風味? のブックマークコメント

  • どうやら改行コードはCR+LFに変換してくれるらしい。
    • メールのテンプレートとして使って気付いた。ドキュメントにこのあたりのことは書かれてなかったと思うんだけど。それともどこかに書かれてるのかな?
  • 標準のデリミタが{,}なのはアホかと思った。JavaScriptとかCSSが入ってるとエラーになるじゃん……。
    • なので、Template-Toolkitみたいに[%,%]にするか、あるいは{{,}}にするのを推奨。
    • ちなみに、{,}が決め打ちになってる部分があって、どこかのバージョンでFixされたらしい*1

 ――ということが書かれているサイトとか見かけなかったので、いちおうメモ。

*1:2.6.8だった。{strip}が決め打ちだったらしい。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051205

2005-12-04(Sun)

このへんの鍵のやりとりはViViのやり方が秀逸な気がする

| 23:08 |  このへんの鍵のやりとりはViViのやり方が秀逸な気がする - 浅倉卓司@blog風味? を含むブックマーク  このへんの鍵のやりとりはViViのやり方が秀逸な気がする - 浅倉卓司@blog風味? のブックマークコメント

と、http://d.hatena.ne.jp/ryoko_komachi/20051129/1133309150 のコメントを見てちょっと思った。


 こういうのを見ると、もうちょっと津田さんのセンスが普及してもいいのに、とか思わないでもないのです>津田さん

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051204

2005-12-03(Sat)

Amazonにはメタデータが足りなすぎるのに誰もそれを補完しようとしない件について

| 01:12 |  Amazonにはメタデータが足りなすぎるのに誰もそれを補完しようとしない件について - 浅倉卓司@blog風味? を含むブックマーク  Amazonにはメタデータが足りなすぎるのに誰もそれを補完しようとしない件について - 浅倉卓司@blog風味? のブックマークコメント

 はてなブックマークのコレクションを使う気になれなかったり*1、あるいはその他Amazonを利用したウェブ書棚システムを利用する気になれないのは、それらを使っても「本を整理した」って気分になれないからなんですよ。

 「超」整理法的には間違っていると分かっていても、やっぱり同一作品・シリーズは順番に並べたいし、作家買いしてる本は作家別にしたいし、あるいはレーベルごとにまとめたりとかしたい。「コレクション」とか「書棚」と名乗るんならさ。

 んでもAmazonはそれらのデータを持っていないからか*2、そういったのを綺麗に振り分けることができるシステムがないんですよね。


 で、そのうち気が向いたら作るかー、んじゃメタデータの構造をどうしようか、そういや昔似たようなこと仕事で依頼されてその時は「このデータどうするんですか?」って聞いたら「気合いで入力します」とか言ってたなぁ、本当に入力してるんならそのデータ公開してくれないかなぁ、とかぐだぐだ考えていたわけですよ。

 で、ふと、こういう物こそみんなで入力すべきというか、コレクション・書棚で他人が入力したデータを使いたいよね、だったらマルチアカウント対応にしなくちゃいけないけどそうすると色々面倒くさいんだよなぁ、とか思ってこんなことを書いたのですが、まあそれはそれとして。

 まあこの手のデータの入力をみんなでやろーっていうのは最近の流行りですし、ひょっとしてどこかで誰かが既に作ってるかもしれませんので、どこかで見かけたら教えてくださいとか、そういう話。


 ちなみに気が向くとしたら、バーコードがちゃんと撮れるケータイ端末でも買っちゃって「これ何に使おう?」とか考えたときくらいかな。たぶん。

*1:ダイアリーを有料で使ってればアソシエイトIDを付加してくれるかと思ったら違った、というのもないことはない。

*2:あ、そういや一部はブラウズツリーで持ってるんだよな。忘れてた。中途半端で使いにくいけど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051203

2005-12-02(Fri)

なんでもオープンとか言うなら、ぜひともユーザー認証もオープンに

| 12:01 |  なんでもオープンとか言うなら、ぜひともユーザー認証もオープンに - 浅倉卓司@blog風味? を含むブックマーク  なんでもオープンとか言うなら、ぜひともユーザー認証もオープンに - 浅倉卓司@blog風味? のブックマークコメント

――とか個人的には思うんだけど、どうだろう?

 個人でウェブアプリケーションをでっち上げるときに面倒なのがユーザー認証の部分なので*1

 TypeKeyとかOpenIDとか使えばいいのかな、とも思うけど*2。まあ気が向いたら是非に。


 あ、べつにはてなでなくてもlivedoorでもYahoo! Japanでもその他ポータル/プロバイダでもいいですけど。


補足

 ちなみに僕が考えている遷移は

  1. サービス側から開発者IDとサービスIDを付けて、はてなの認証ページに移動
  2. はてなの認証ページではてなIDとパスワードの入力
  3. 入力を確認したら、はてなIDとワンタイムパスワードを付けてサービスIDに登録されたサービスURLにリダイレクト
  4. サービス側に戻ってきたら、はてなIDとワンタイムパスワード(と開発者IDとサービスID)を使ってはてな認証APIでそれを確認
  5. はてな認証APIで通ったら、サービス側は以後そのIDを利用

――って感じです。

 これなら他所でパスワードを入力する不安がなくなるし、認証提供側としても問題がある開発者/サービスに対して提供を停止できていいんじゃないかと思うんですけど。いかがでしょ?


追記

 あー、miyagawaさんが何か書いてるじゃん。

http://blog.bulknews.net/mt/archives/001852.html

 IDはとらないのが普通なのかー。まあそりゃそうか。

 ただそれだとサービス毎にIDが分散しちゃうのが難点なのですよね。。。

 「あれ、ここのIDなんだっけ?」とか考えること良くあるので。うーん。

*1:いやまあ作ってもいいけど、これ以上アカウントが増えるのは嫌だし。

*2:このあたりのドキュメントってどのへんにまとまってるんだろう。

kokogikokokogiko2005/12/02 12:41ここだけの秘密ですが、
ttp://yadis.jp/openid/hatena/kokogiko
とか作ってたりします。
(この上で開発もやってたりするので余裕で動かなくなることあり)
サーバ間の信頼状況保存に関する処理とかほったらかしてたり、利用規約とか作ってなかったり、あとhttps取得の申請とかしないといけないのですが、やる暇がぜんぜんなくて放置・未公開です。
今、asakura-tで試してみたら、うまく動いてないみたいですね。IDを拾う正規表現がうまくヒットしてないっぽいので、また直しておきます。

kokogikokokogiko2005/12/02 23:00補足を受けて…他のページでPASSを入れる怖さはあるので、一応恒久サービスのつもりはなくて、むしろはてなさんうちでも作れるくらい簡単なんだから対応してくださいよー、くらいのつもり。
本家対応を待つ!みたいな。
後、書かれてる遷移、開発者側のAPIキーのあたりを除けばそのままOpenID流用でできますよ。
OpenIDの識別用URIが認証サービス側のIDから一意に生成できるなら、ユーザには長いURI入れてもらわなくても、ユーザIDだけ入れてもらって、システム側で補完してやればいいので。
実際、MovableTypeのOpenIDプラグインも、LiveJournalのIDはURIでなくIDを入れるだけでOpenIDの遷移に入れるようになっています。

kokogikokokogiko2005/12/02 23:11あと、開発者APIキーに関しても、果たして特定のサイトにIDを渡してよいかを判断するのはIDサービス側なのか?個々のユーザではないのか、という議論があると思います。
OpenIDでは、IDサーバにログイン状態のままだと認証されたくないサイトでも認証されてしまうので(一種のCSRF)、初めて認証されるサイトではそのルートに本当にIDを送ってよいかを、ユーザに確認するフェーズがあります(認証サーバ側が対応していればですが)。
これを使えばいいように思います。

asakura-tasakura-t2005/12/02 23:13 いろいろアドバイスどうもです。今日ちょろっと調べてたんですが、OpenIDとかで問題なさそうだという感触はありました。
 まあ問題はそれで何を作るかって話になるのですけどね……。

kuippakuippa2005/12/04 00:05こんばんは、こんなのありますよ。( ゚д゚)ノ⌒
http://i.hatena.ne.jp/idea/421
ヘタにメールアドレスとか抱えたくないので、ある程度公証されたIDがわかるだけで俺みたいにどうでもいいフリーネットサービスを提供しようとする立場としては大変ありがたいのだけど…。どうもはてなは腰が重いみたいだ。

asakura-tasakura-t2005/12/04 00:24はてなアイデアには全く期待してませんので~ :P
やりたくない理由も想像はできるので腰が重いのは別にいいけど、だったら「なんでもオープン」なんて言って欲しくないとは思う。
というわけで、現状ではOpenIDとかで行くのがいいんじゃないの、とは思います。

2005-12-01(Thu)

情報収集法よりも情報出力法のほうが気になりますよ。

| 01:05 |  情報収集法よりも情報出力法のほうが気になりますよ。 - 浅倉卓司@blog風味? を含むブックマーク  情報収集法よりも情報出力法のほうが気になりますよ。 - 浅倉卓司@blog風味? のブックマークコメント

 趣味や仕事の範囲のネタはほっといても集まるし*1、必要になってから調べても大抵は問題ないし。

 それより出力のほうが大変。

http://d.hatena.ne.jp/naoya/20051201/1133434292

http://d.hatena.ne.jp/tomozo3/20051130/1133334916


 書きたい(出力したい)ネタがあっても、それらを全部書けるわけでもないからねぇ。

 なんか手頃な吐き出し方とかないものでしょーか。

*1:だから趣味や仕事とは関係ないネタの収集法はちょっと気になる。

kokogikokokogiko2005/12/02 07:58> 書きたい(出力したい)ネタがあっても、それらを全部書けるわけでもないからねぇ。
> なんか手頃な吐き出し方とかないものでしょーか。
禿同。
(ニュースサイトとか芸としてやってる人は別として)別にわざわざ書くこと探してまで書く必要はないよなって思ってます。
むしろ出せない方がつらいですよね。
本当は1日2回は更新したい勢いなのに、週1しか更新できないとか。

asakura-tasakura-t2005/12/02 08:31 そうそう。ネタはあるのにうまくまとまらなくて放置してたり。
 まとまらなくてもとりあえず書けばいいと思っているんだけれど。書き始めると時間がかかっちゃうんですよね……。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20051201
2004 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2008 | 02 | 03 | 04 | 06 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 02 | 03 | 04 | 05 | 07 | 08 | 10 | 11 | 12 |
2013 | 01 | 05 | 07 |
2014 | 01 | 02 |
2016 | 01 |
2017 | 01 | 05 |