Whiteのふりーとーく

@ゼロ和ゲーム

そーゆー風俗めいた商売するんやったら所謂上納金ってもんが要求されそうな気がするし、それで資金が流れる先が元気になると困る人達がいたりするわけでありますよね、とか思ったり。

摘発により不幸な人が発生する必要があるからこそ、定期的に摘発する、なんて汚れた見方もできたりなんかしちゃったりしますけども。

ま、なんにせよ憶測ですが。

@変化済ゲーム

なんの意味がとは言いますが、より高い効率を叩き出すbotを作るという行為それ自体が、ゲームとなりえることには留意。マルチプレイヤーゲームなんだから、それも含めてゲーム環境なわけで。ただ人生同様にクソゲーなだけってこと。

周りの迷惑だからやめろよというなら、同じ事を先にヘッジファンドに言ってやってください。いやマジで。

@

片付けて散髪行って戻って片付けて昼寝したら夜。原稿はちっとも。その上明日の夕方ぐらいに友人が攻めてくるらしいですよ？　どうしましょう？

@

なんの気まぐれかHe loves wellとか公開。小説ってよか、詩だけども。

@'progressively' active report

バリバリ執筆……しなければならないはずなのに友人達が夜を徹して遊びに来た結果、部屋が片付いた上に今回分の構想破棄、再構築ということになりました。このままつまらん話書いてていいのかなー、とは思っていたので、相談と言うか一方的愚痴りの相手になってくれた面々、感謝です。

_けれどもこれで日程が更にうひー！なことに。間に合うんかなぁ。

@Type

っていうか、確かにはしゃいでました。俺、性根は猫だと思うけど、犬っぽく振る舞うのが好きだから。だから、肝心なところで、俺はすごく猫かもしれません。自然体指向なくせに強がりでカッコつけさんだし。

でも、言ってることとか、やってることの、裏付けの気持ちには嘘はないつもり。だから、信じてくれるなら。お買い得だと、思いますよ？

@'progressively' active report

書いてます、書いてます。

プロット破棄して再構成しながら書きになったら急に筆が進んでます。キャラ構成とか整理して、おかげでずいぶん回ってます。敵はやっぱり時間ですが、今までに比べてずっと楽しく書けてます。最悪初稿をそのまま校正して投入、とかかもだけど、間に合いはするんじゃないかってペースです。

@お値段

たった８万円では自転車なんてせいぜい１台しか買えないヨー、とか思った私はダメですか(Y/y?)

@謎。

……すごく、気になってます。すぐ返事しなかったのが悪いのだけど。本当はいつでもって言いたくても、タイミングってものがあるわけで。っていうか、余裕、ないのかな。強がっているだけなのかも。猫は猫なりにあまえんぼなんですけど。

なんで弁明してるかな。そのへんでもう、負けてるような。

@興味分野

N-gram型日本語全文検索エンジン、だそうな。環境がリッチなら望ましい選択肢ではあるのよね。Unicode化すればゴミも減らせる効果があるし。UnicodeなN-gramエンジンは興味はあったのだけどなぁ。っていうか、今からでも作るのはアリだけど。

@発散的雑考

形態素解析型よりはN-Gram型のような、「意味付けをしない」システムの方が好きである。言語とはそもそも、そのようなものではないか。乳幼児は言語を「意味」という固まりでは認識しないのではないか。そしてあるがままを模倣し理解し再構成していくことにより、そこに単位を、意味を見出していくのではないか。その過程こそが、人が言語を習得していくということではないか。であれば、形態素解析などという外部知識ベースを与えず、単純に文章そのものから知識を構成するような方がより人間の知性に近しい働きをするのではないか。

@備忘録

同居人と会話。サクラ大戦の主に絵の点から、いかにギャルゲーと作り方が違うかという話。サクラの絵（原画）はアニメーション製作の体制により作られている。すなわち、「キャラ原案→（量産用の）キャラデザ→複数の原画家による原画製作」という体制。多くのエロゲー／ギャルゲーは「原画家がなんとなくキャラデザ」という体制であろう。

こんなリッチな作り方をしているギャルゲーがサクラ以外にあるか？ 根本的に売る気が違うと言ってもいい。ゲームとアニメの両方を知っている広井あっての方法だ。もちろんエロゲー／ギャルゲーがある種画集としての価値を持ち合わせている点は無視できないが、量産とは正反対の思考だろう。藤島康介にいちいち原画を描かせていたら、あんな速度のシリーズ展開は不可能だ。

@

ごうさんの続CVSとか読んで。例のごとく発散してますが。

_RCS等の古いバージョン管理システムとcvsの違いは、通常のWebページとWikiの違いに似てるかもしれない、と思ってみたり。だからcvsとWikiの相性ってよいのだろうけど。

_まあ、CVSがあれこれ問題多いのは事実で、たとえばファイルの移動(改名)が面倒ってのは有名。だけどこれを解決するにはファイルをもう一段上のメタレベルで保持・管理する必要があるわけで、diff + patchの管理システムであるRCSから発展し、結果としてUNIXファイルシステムにべっとりのCVSとしてはそこまでやるのは行きすぎだとも思うわけで。そろそろそのへんのことも考えた新しい枠組みに基づくツールが求められてるような感じはしてたり。

まあ、融通が効かないと言ってもMS製品ぐらいには融通効くんじゃないですかね(ぉ

_ところで要らんファイルはファイルシステムそのものがオブジェクト指向的というかアスペクト指向的なら解決できますね。ファイルが「内容」の他に「バージョン情報」も持ってしまえば(そしてコンテキストに応じて適切なものが見えれば)よい。

……っていうか、TreeStore.pmってそういうモデルを提供するためフレームワークだ、とか考えてなかったか？＞俺

@

なにげにアニメ者的に必見のシスタープリンセスRePure。Aパートはそのクオリティの低さに、Bパートはそのクオリティの高さに注目ってことで。今週もそれぞれ凄かった。

_特にBパート。毎回「今回のアニメーター」が脚本などさして気にせず個人作品を作るというスタイルなのだけれど。今回は凄かった。キャラデザはどこへやら。完全にアニメーターの意図に合わせた絵。もう笑顔がスンゴイの。あんなに笑顔笑顔した笑顔のアニメートを見たのは久々です。敵はジブリとかチャップリンとかですか？という勢い。

_「シスプリのアニメ」としては最低だけど、「アニメーション」としては必見、かも。

@仕事

「仕様書」という名の要望書（願望書？）を元に実装して、それから「連絡票」と言う名のパッチを書く。実装物がなんかあれこれの資料と食い違ってる気もするが、私は「仕様書」に従ったまでである。まあ、よくあることか。

@

そもそもあらゆる言語は人間の脳にとってある種の制約として機能するという側面を持つだろう。そういう意味では表記以前に言語が正しくないのだと言えるかもしれない。

そもそも思考にとって言語が邪魔ならそれに合わせて言語は変化してしまうだろう。たとえばある単語についての誤解が是正されるとき、これを「彼の私的言語が変化した」と捉えることが可能だろう(*1)。

_なにかを記述するのに、正しいもなにもない。あるのは記述しようという意図と、手法、そして結果だけだ。それが「正しい」かどうかを決めているのは記述者、あるいは読者でしかない。

あなたがそれを「正しく」ないというのと同じぐらい、『あなたがそれを「正しく」ない』」ということは「正しく」ない。（そして、私がそれを「正しく」ないと言うことも、同様に「正しく」ない）。

@蛙が如何なるものなるか。

「蛙」というオブジェクトと「解剖」というメソッドについて考える。なお、半分ぐらい詭弁というか余汰なので注意せよ。余汰が無示唆であるとは限らないことには注意。

_ところでこの話、厳密には「蛙」というクラスとそこから生成された「蛙」オブジェクト（インスタンス）、そしてそれらの持つ「解剖」というメソッドとか言わなければならないように思える。しかし、その差は（重要ではあるが）説明するのが面倒なので説明しない。

ともかく、よくあるクラス指向的アプローチとしては、「蛙」が「解剖」というメソッドを持っていると考えるであろう。C++とかJava風に書けば、蛙.解剖()といった感じか。オブジェクト「蛙」が「解剖」というメソッドを持っているということは、「蛙」が「解剖」というメソッドを知っているということでもある。

このとき、「蛙」は「解剖」の動作主体ではない。「蛙」は「解剖」の動作対象である。解剖を実際に行うのはたとえば人間であり、従って動作主体にメソッドを割り振るとするならば、人間.解剖(蛙)とするべきである。

_もちろん「解剖」というメソッドを「蛙」というオブジェクト（この場合正しくはクラス）に、すなわち動作対象に割り当てるあたりがクラス指向の妙なのだと思うが、このとき「解剖」を実行しようとするなにものかの意図が暗黙のうちに反映されてしまっているのではないかと思う。

考えてみよう。そもそも蛙にとっては解剖されるなどイレギュラーな事件である。解剖されることが目的で生きている蛙などいない。少なくとも、蛙自身は己が解剖されるなど露ほども想像すまい。だというのに、オブジェクト「蛙」は「解剖」というメソッドを持ち、すなわち「蛙」は「解剖されかた」を知っている。人間の「蛙は解剖するもの」という勝手な思い込みによって、蛙というオブジェクトは規定されているわけである。

_従って極端な話、クラス中心型オブジェクト指向言語におけるクラスとは「○○は、××すべきものだ」とかいう思い込みの集合、と考えることも出来る。あまつさえ、クラス中心型オブジェクト指向言語においてオブジェクトとは「思い込み（＝クラス）」から生成されるのだとも言える。

_ここで相変わらずPerlの極めていいかげんなオブジェクト指向記法を持ち出すならば、オブジェクト（データ）と思い込み（クラス）は別個の存在である。蛙は誰がなにか言わなくとも蛙であるが、人間が捕まえて「お前は人間に捕まった蛙だ！」と宣言(bless)されることによって「解剖」というメソッドを付与される。もちろんその後蛙が逃げ出し野性に帰れば（ここでも蛙はblessされるだろう）、蛙は「解剖」というメソッドから解き放たれる、というわけだ。

_といったところで結論のでないまま話は終わる。そもそも結論が出るような話ではない。確かに、出そうと思えば結論を出すことはできるだろう。しかしそれは私が「結論を出そう」とした結果に過ぎないだろう。誰かが結論を出せるからと言って、この話自身が結論を持っているとは限らないのである。

@

ツッコミに反応とかー。

love lettersがあって、Love Letters Vがある。“V”をローマ数字と見なすと、途中の番号は？

II、IIIはこのあいだの北伐の際に出したGD#なる本に収録です。IVはここの2002/09/30付に存在してます。それから弁明めいた注意書きとかもあったり。

@冬支度

原稿が忙しいのに何故か友人が遊びに来る。彼らが自動車でやってきたので、折角だから灯油を買いに。更についでに近所のホームセンターでこたつ布団購入。ということで、部屋にはこたつを展開してみる。部屋PCもデスクトップからこたつトップへ移動。微妙に温まりながら、疲れて寝ている友人を尻目に原稿書き。

@坊主憎けりゃ〜My style "Love & Peace".

だからって袈裟まで憎むのはどうかと思うが、袈裟まで憎まれる坊主にも問題があるとは思う。ともかく、それで袈裟を着ている別の坊主まで憎むのは不幸なんじゃとは思うけど。

今は無理かもしれないけれど、お互い努力ぐらいはしましょうよ、なんてガキみたいなことは言いたい気分。とか書くと、自分で出来もしないことをとか言われそうだけど。でも俺はどこまでもガキっぽい考えでいたいし、それを押し通すために強くなりたいとも思ってるわけで。

@

「蛙が如何なるものなるか」にツッコミとか来てみたり。

「蛙が如何なるものなるか」読んで、をなんとなく思い出したりしました。

また、動作の主体については、ＲＰＧなんか作ろうとクラス設計していると、攻撃側.攻撃とかしたいけど、ダメージ与えるためには、防御側.攻撃（を受ける）になったりとか、感覚的になかなか一致しないところがあったりしますね。

そうですね。馬鹿げた書き方をしてはいますが、真面目な書き方をすると、「オブジェクト/クラス」という枠組でモデリングを行う際の、分析方針って話になりますから。

_攻撃側.攻撃や防御側.攻撃には別種の問題もあると思います。本来問題の動作（攻撃）には、主体、動作、対象の３つが存在する。これをクラスメソッドに割り振る場合、「主体と対象のどちらにメソッドを割り当てるか」という点でメタファを決定する必要がある。

感覚的に納得しやすいモデルを指向するなら、「攻撃オブジェクト」を規定するという手もありそうです。メッセージモデル的な考え方ですね。攻撃 = 攻撃側.攻撃で攻撃オブジェクトを生成し、防御側.防御(攻撃)でそれを防御させる、って感じですか？

_これを、「メッセージ指向」とでも言うべきメタファに基づく言語で書けば、攻撃側.攻撃 -> 防御側とかなるでしょうか。かなり直感的でいいかも。

@

RSSとhina.di。hina.diは、図体がでかいわりには人間様にとって有用な情報が少ないかな、と思います。事実上日付だけ。

たとえばサマリーとして「更新箇所のトピック名」とかが入ってれば、hina.diもぜんぜん違う使われ方をされるような。というわけで、はてなアンテナあたりが独自拡張でサマリー流せば、とか思ってみたり。

@'progressively' active report

週末は原稿停滞しました。書こうとして、手を動かしはしたのだけど、でもばっちり停滞しました。プロットの練成不足にやられた感じ。

しょ−がないので、落としても構うかとあせらず急がずやってます。考えてから書いて、考えてから書いて、のんびりじっくり気に入るように。詰まったら積極的に散歩に出たりなんかして。プログラム書くときと一緒ですな。結局こっちの方が進みがいいみたいだし。

そんなわけで、本は出るかどうかわかりません。このままのんびりやってけば、ぎりぎり出せるかなっていうペ−ス。

ここのところ風邪引きさんなので微妙ですが、どこかで一回、無理するかな？

@CM63

ということでProgressiveの母体と言うかなんというかのジャンク・ヤードは、日曜日西あ63aらしいです。えらい人も言うとりますが、予定通りなら激しく新刊出まくりなはず。

ちうことで、私もきりきり書かないとねー。

@

Perlの自然言語主義。とてもLarryらしく、なんの話をしてるのかよくわからない(褒め言葉)文。このしなやかさは見習いたい。それは必然として、世の中全てを虚仮にするということでもあるのだけど。勘違いされたかもしれないので追記。たかが(失礼)プログラム言語の設計の話をしながらも、これだけ多様な示唆を含む文章を書ける(でもやっぱりプログラム言語の話をしている)ということを、褒めているつもり、です。ところですべてを虚仮にするということは、全てを平等に扱うということでもあります。全てを斜めに見て、いろんなところから見て、そして最後に正しく正面から見る、というLarryのやりくちは、真似したいと思うところ。

@

hina.diでサマリ話。

生成が難しいというのは真面目にやればその通りですが、本当に「よい」サマリの必要性が高いかと言うと疑問です。相手は論文とかじゃないんだし、「先頭数百バイト」でも十分な精度が得られるような気もするですよ。そもそもわかんなかったら本体見に行きゃOKだし。

もちろんサマリを作るときに、日記システム（＝ドキュメント管理・表示系）を限定して、マークアップのパターンを参考にすればなお良いかもしれませんけど。

@非当事者サマリ問題

第三者がサマリを作ることの是非、って話になるのでしょうか。先に結論を言うならば、「先頭何バイトか抜き出しとかならそんな目鯨立てることでもないだろ」ってとこですか。

_第三者による「サマリ」ってのは、そもそも内容を適切なニュアンスで伝えるものではない、と思います。日記用のサマリというのは速報的なものであって、速報的なサマリってのは、（自分にとって）有意な情報であるかどうかの判断材料になれば十分でしょう。「今」わざわざ見に行く価値があるか判断できればそれでよい。

そうして流されたサマリって、わかりやすく言えば「噂」なのかも。「噂」の真偽を確かめたければ「元のソース」を見ればいい、

噂を流されることさえ嫌なら自分でコントロールすりゃいいわけで。自分でサマリを生成して流してもいいし、「サマリは作らないでね」ってお願いしてもいい。そもそも公開するべきでない、とか言いたくなるのはこの手の話の常ですが:-P

_という話は各種検索エンジンやInternet Archiveの問題と相似形のように思えるですよ。それに、ロボットもシステムもなくたって、この段の先頭でやったみたいに勝手にサマリを作ることはできるし、それを流すこともできるわけで（それが実効を持つかは別）。

そもそも情報公開する限りは第三者の意志の流れに巻き込まれてしまうことは避けられないわけで、なんて言うこともできますが、それは激しく程度問題に陥りますか。

@サマリ問題

ということで、日記のサマリ話の続き。

_「既存の検索エンジン群と何が違うんでしょうか」の意味の取り方が難しい（いろいろ取れる）のですが、とりあえず一番話が面白くなりそうな方向に取ってみます。

サマリ生成・流通系と既存の検索エンジン群の違いは、おそらく「速さ」にあるでしょう（既に、私が「速報的」、あづみさんが「今話題のネタ」として言及している点ですが）。「正確さ」はわりと二の次で、「今、旬な話題を追いかけたい」、という需要は間違いなくあるでしょう。

もちろん現状の日記系・個人ニュース系サイトでも、誰かの自発的なポインタ収集という形で実現されることはありますが、これを半自動化できないか、というのが私の考えのベースです。

この需要を考えたとき、基盤となるシステムさえあるのなら「更新差分やサマリを提供する」のがよいように思えます。で、これをやるときにはてなアンテナならもう差分抽出をやってるよね、というのが先の発言の意図、でした。

まあともかく、そうやって提供された差分／サマリを将来的にはP2P的というかNetNews的と言うかそういう流通基盤に載せて、一定期間でexpireするようにして、必要な時にはてきとーに検索かければそれなりの精度のサマリ一覧が、得られそうな気がします。

ところでnamazu横断検索では、結局「新しい」かどうかの確認とか、あっちこっちから集めた検索結果をフィルタリングするとかの部分で、結局は差分/サマリを扱う時と同様のコストがかかりそうな気がします。

_生成方式の話は、少し別の話になると思います。

もちろん理想的には、ページ管理者本人がサマリを作るべきでしょう。しかし日記のように更新頻度が高いものでは楽をしたいわけで、楽をしたいならサマリを一々考えて作るなど面倒なわけで、ならばコンピュータにやらせて手抜きがしたいと考えるわけで。ということで手抜きの仕方を考えましょうと。

ということで、Web日記のような文書において、サマリの自動生成をするには「ターゲッティング」と「要約」が重要な課題となるとか考えてみました。

このうち要約に関しては、自然言語処理技術の進化を待つべきでしょう。一朝一夕のquick hackで作れるようなものじゃなさそうなので。類似度検索とかその他あれこれ、タイミング良く/.-jとかにそれっぽい話題が上がったりもしてますが、そろそろお手軽実用ベースに落ちてきそうな雰囲気でここ３年ぐらいが狙い目の分野かなー、とか思ってますがそれは余談。

そんなわけでお手軽quick hacker的思考としては、ターゲッティングの方を重要することになります。でま、このときに、マークアップその他の情報をヒントにすれば、適切なターゲッティングが可能なのではと思います。たとえば私の日記の場合、以下のものなんかがヒントに利用できそうです。

• 記事にトピック名を付けている
• 記事中にリンクがある（リンク数が多い方が重要度高そう？）
• 記事の長さ

同様に、あづみさんのスタイルであれば、「カテゴリ登録されている」ことをヒントにサマリ作成すれば、S/N比は上げられると思います。で、ターゲッティングさえ的確なら、ターゲット先頭から一定バイト、とかでも案外実用に値するものができちゃうように思うわけです。

_とかなんとか、ぐだぐだ言わずにやってみろって言われそうな気もしますが。