hoshikuzuの日記

2004-04-28

■はてなのcookie

はてなのcookie

はてなの Cookie(脳ざらし紀行 2004年04月25日)より引用させて頂きます。

はてなはユーザ認証に全てのサービスで共通の Cookie を使っている。この Cookie はログインしなおしても変わらない。高木浩光@茨城県つくば市 の日記を参照。高木さんがこれを書いたときからはいくらか事情が変わっているだろうけど。

で、はてなグループみたいな新サービス導入時のベータテストにも同じ Cookie が使われてしまうのはどうなんだろうと思う。はてなグループには XSS 脆弱性が結構見つかっている。ベータテストなんだからそれはいいんだけど、他のサービスと同じ Cookie を使うことで、ユーザが必要以上にリスクを負うことになる。

今後もはてなは新しいサービスを導入していくだろう。そのベータテストのたびにユーザが必要のないリスクにさらされるのはおかしい。高木さんが書いているみたいにセッション ID を使う。次善の策としては、今の Cookie を失効して、サービス毎に違う Cookie を新しく発行しなおす。それも駄目なら、ベータテスト時だけの Cookie を発行する。ぐらいはする必要があるじゃなかろうか。

上では、なんだかまるごと引用ですけれど、全部大事なことですから。

いやぁ本当にコレすごく気になっていたんですけどね。

私の場合で喩えて言うと、はてな銀河鉄道の定期券を私が保有し、はてな世界のどこにでもその定期券で行くことが可能、その定期券ひとつ見せればどこででも個人認証が出来てしまうし、逆に言えば常に携帯をする必要もある、そして、その定期券の有効期限は無期限であり、ひとたびその定期券を盗まれると、2度と「星kuzu鉄郎」の名前で定期券を取得できないし、銀河鉄道にのることは許されない。さて、はてなグループという新開地に停車することになったが、そこはまだ治安がよくなくて、いつ定期券を盗まれるかわかったものではない、、という感じでいいのかな?もちろん、定期券はCOOKIEのこと。

cookieの有効範囲が、時間的にも空間的にも極めて強大なのですね。これを巧妙に制限したほうがいいだろう、というお話し。セッションIDも有効だし、新開地ではその範囲でのみ有効な特別パスをもうけてもいいでしょう。

はてなのアルファモードの時に基本設計レベルのアイデアとして充分に検討されていれば良かっただろうになぁ、とも思います。今となっては、かなり修正が大変なのですよねぇ。ふぅ。でも、今後さらにはてなが発展して行くのならば絶対に避けて通れません。たぶんはてなで使っているperlでもセッションIDをほげほげするモジュールがCPANかどこかに落ちているようですけれどねぇ。ユーザの使い勝手が全然違ってくる恐れがありますからねぇ。

■はてなサイン・はてなハンコ

はてなハンコ

完全にはてな内でのお遊びとして、ハンコ機能の実装が欲しいかも。ハンコぺったん。画像ですね。大中小があったり。んで、あらかじめはてなに印鑑登録しておくですよ。どこにペッタンするかはさておき、そのハンコ画像をクリックすると印鑑証明が表示される。ほら、セキュアシールってあるでしょ?verisignのシールとかのノリで。遊びなんで、印鑑証明の内容としては、「はてなで登録済み」と、それから任意でユーザのプロフィールとか訴えたい事(人のいいことみつけましょう運動参加中!)とかを書いておける。(独り言:んー。HTTPSかぁ。)ハンコのかわりにサインのオプションも可能。意匠は腕を振るってご自身が作成してもいいし、はてな有志がmyハンコ屋さんショップを経営してもいいし。

ハンコ押せるのはもちろん、はてな内だけなんだけどね、どんな時に押そうかなぁ。コメント欄で足跡「ペタペタ」とか。ハンコのみOKみたいな。誰が発言したかのところにローマ字のユーザ名じゃぁなくてはてなサインでもいいかな。メッセージは「こんにちわんわ」とかタノシゲにしてサインは「髑髏マーク」付き、ちょっと嫌かも。だから楽しいサインだと嬉しいかも。まぁこの場合はサインの大中小の小を使うとして。

どんな雰囲気でハンコ押すのかなぁ。まずログインしていると考えてと。そうだなぁ。ハンコを許される場所ではハンコの形のsubmitボタン(image画像)が登場すればいいかな?で押すっとポン。「いわし」とかで押すのも有りとか。いわしで貢献するとハンコが銅になったり銀になったり金印に昇格したりして。わはは。プラチナ印だけは本当にすごい栄誉でめったにもらえないとか。うーん。

はてなグループ「金印」とかあったら畏れ多くて私なら近づかないかも。

投げ銭とかあるけどさ、投げ「栄誉」とかあってもいいんじゃぁないの?とか。ORKUTのアレ、なんてったっけ、そうそう、カルマみたいな。で、ハンコ成長システム。

そうだなぁ、金印って人によってはイヤミにみえるかもしれないから、単純な動画gifあたりで、よく見ると稀にキラっと光るぐらいでいいかも。奥ゆかしい。どうせモジュールで埋め込まれるから、システムが提供するスタイルシートで動かない画像を飾っておいてもいいいんだし。金印もらった後でも定期的に降格してもいいかな。今すげぇ奴ぐらいの感覚のハンコでもいいんじゃぁないのかなぁ。で、何回も今すげぇ奴になる人って、やっぱし、永世今すげぇ奴に祭ってソレキリ昇格なしでもいいし。

ハンコごときで一喜一憂する人って出てくるかなぁ。人間いろいろだからなぁ。あと、ハンコのツヤを見てヒトをさげすむ奴とか出てくるといやだなぁ。まぁそれこそ杞憂かもしれないけれどね。楽しくやれればイイ遊びツールとして「はてなハンコ」いかがっすか。

まだ形にものってませんねぇ。というわけで軽いノリで、はてなグループへの要望へのpingがふさわしいかな。

■はてなの見たよマーク

見たよマークって何さ

グループウェアとしてのはてなグループに、マジに便利な機能の追加、を提案してみようと思います。ぢつはコチラが先に思いついていて、上でのべた「はてなハンコ」はその際の空想の産物だったりします。でもこちらは遊びとしてのハンコうんぬんではなくて、マジに使えるんではないかと。数年前にこのアイデアを会社の先輩から聞いた時にすげぇ便利だと実感したけど、なかなかそういうCGIってなかったんですよ、実装そのものは簡単な割りに。独立したものとして正式に提案したいと思います。

とは言え、仕様をキチんと展開できるほどアタマよくないので、雰囲気だけの説明にいたします。

では、見たよマークの登場です。グループウェアの機能を使って「広報」なり「連絡伝達事項」なり「緊急告知」なりを掲示したとします。現行のグループウェアでは、連絡を見た者が「見たよ」とハンコを押すだけの機能ってなかなかみないんです。はてなではこれを実装してほしいと。仰々しい決済ワークフローの印章押下とかはあるけど、あんなんじゃぁなくて。もっと単体で気楽に使える奴が欲しいんですね。「突然だけどオフするぞ連絡~。左にハンコでこれない、右にハンコでイクイク!、まんなかで、とりあえず見たけどスケジュール調整中。どんどんハンコ押してね。」って奴ですね。これのスゴいところって、仲間内、グループ内で、「おい、あいつまだ見てないんじゃぁないの?知らせてやろうか」とか動きが出てくるところなんですね。また、掲示内容作者にしても「あぁ彼にはまだ連絡ついてないんだなぁ」とかワカルシ。

掲示者は、グループの枠組みを超えて、もしくはグループ内の全て、もしくは特定のメンバー(複数)のみ、の各レベルを選択して、時限を切ってハンコの押印機能付き掲示を出す事が出来ることにすると使い方にバリエーションが出てくると思います。

見たよマークの使い方を考える。

企業ユースで考えますと、たとえば、こんな時に便利です。24時間交代シフト年間3日間だけが休業日、そんな企業のとあるセクションの課長さんが悩んでいました。「読んだらハンコを押せとばかりに紙で回覧板を作ってもどこへいったか不明になってしまうし、だいたいオレが部下に伝達事項が伝わっているかどうかを知らないことも恐ろしい。係長Bや係長C、主任Dだって、俺が不在のときには立派なチーフだ。あいつらだって周りのみんながドレだけ伝達事項を知っているかがすぐにわからないと困るよなぁ。そうそう、一番シタッパだけど見所のあるE。あいつなら、ドジなCが伝達事項を知らないとわかればCにそっと教えるだろうしな。要するお互いに教えあうツールがあればいいんだ。紙では絶対に出来ないからなぁ。」こんな課長さんにはバカウケかもしれません。

草案としてお伺いをたててみる。

見たよマークは便利なツールだと思いますので提案します。もっと洗練されればヨサゲなので、とりあえずこちらへ。>はてなグループへの要望

■キーワードの親子

キーワードの親子について思考してみる。

キーワードの親子について思考してみる。を拝見しましたが、よさそうですね。使い方は無限にあると思います。親と子という言葉に惑わされなければ応用範囲はかなりあると思われます。賛成。

どうやって実現するのかなぁ。キーワードはひとつの記録単位としてレコードになっているとして。同じ表意文字なり表音文字でありながら異なる意味もあるケースをあらかじめ想定しておいたほうがいいのかな。ひとつの表意文字なり表音文字で出来たキーワードは、複数登録できればいいよね。そういう仮定にしておきます。後から制限かけてもいいけど。たぶん、複数登録のほうが親子を設定する時にはシンプルな概念になるはず。ナポレオンの子供にニセモノワインなんてあったりナポレオン3世とかが同列でいたりしたらいや~んだから。子供だけ検索するときって、親のキーワードの意味をユニークにしぼりたいものです。ひとつの言葉としてのキーワードでも、複数の意味がある場合には、レコードとしてわけるべきでしょうね、親子縁組するときの理想としては。でないと、こんな親はいらねぇとかいう紛争がおきるかも。神とかいうキーワードだって本当は複数あっていいよね。キリスト教の考えのキーワードならそれ専用のレコードに対する子供なり親なりの関係を設定したあげればいい。そうすれば、探偵「神(じん)」(だれだそれ)の子供としては検索してもキリスト教の情報は出てこないけど、きっとそれでいいと思うのですよ。神Ⅰとか神Ⅱとか神Ⅲとかあっていい。もちろん、ⅠとかⅡとか明示すると怒るひといるかもしれないからレコード内部で単純に生成順に添え字をつけておくだけでいいや。見えなくてもいい。っていうかみえたらあかん。

ええっと、私は発想が歪んでいるので(笑)極限状況を考えたりします。あるレコードの親なり子供なりが、あるレコードそれ自身であってよいか。また禁止すべきか。これは、、微妙。一応、そんなことはないことにしておきます。これくらいなら機械で簡単に判断できる。

AはBを子供にもち、BはAを子供にもつ、これはどうだ。これね、機械で判定ロジック作るの、実はひどく難しい。へたすると永久ループだよね。AからB、C、D、E、Fとかまでいって、そこでFがAを子供に持つ、、なんて調べられるわけないわさ。なので、人間様に判定をゆだねましょう。そんなことしないでね、っているルールにするしかないよね。でないと全部の親子を調べ尽くしてループにならないようにする検査が必要。専用の大型コンピュータが専用のデータ構造を持ってないと難しそう。

レコードはどういう構造を持っていればいいのかな?ひとつのレコードは複数の意味のことなる子供を持っていいのかな。また、複数の意味のことなる親をもっていいのかな?これは可能であるように設計しておきたいものですよね。でないと親子関係が平板でつまらないものになります。ということはですね。物理的なファイル構造としては、レコード内部に親に関する情報とか子供に関する情報をそれぞれ無限子記録できるように、、、って無理じゃん。駄目。だから、レコードと親子の記述は物理的には別の記憶領域に割り当てられるのでしょうね。きっと。だいたい困るのはおそらく子供の数の上限だね、たぶん。サッカーチームのメンバーとか考えるとそうだよねぇ。アルビレックスというチームのレコードをひっぱってきて、そこからの子供をみつけるときに「登録選手」という関連で拾い出す作業。うぅむ。

だんだん切なくなってきたぞ。子供が親を持っているのはいいんだけど、親子関係がユニークでもないだろうしね。血縁の親だったり育ての親だったり義理の親だったり、恩師だったり、K-1の生みの親だったり。

だから、レコードには親子関係を全部網羅するのは難しい。親子関係だけを情報にもつ別の記憶構造が必要で、そちらをいくら書き換えてもレコードには影響が出ないようにしなくてはいけない。ううむ。どうするんだろ。

もう1回考えて見る。ええっと。まず、チームごとの選手名鑑をキーワードシステムの親子関連つけで実現してみよう。ええっと、抽象的に考えれば「選手名鑑」というひとつの関連付けがあればことたりる。だけれども、きっと誰かさんは「アルビレックスの選手名鑑」を作りたいはずだ。これは困るなぁ。「選手名艦」という親子関係をまず最初にシステムに登録。で、「親としてふさわしいチーム」に「アルビレックス」を登録。これなら拡張性が高いはず。ほかのチームの選手名鑑としても使えそう。「パープルサンガ」を「親としてふさわしいチーム」にもとりあえずいれておこう。だから、最初から「アルビレックスの選手名鑑」って作るより「サッカーチームの選手名鑑」がいいだろう。おい待て。町の草サッカーはどうするんだ。親としてふさわしいチームに登録していのか。高度に抽象化された「選手名鑑」ならOKなんだろうけどなぁ。実際にはJ1だけ、ってしぼるものなのか。それとも世界のプロサッカーにすべきか。結構親子って大変なんじゃぁないのかな。

気をとりなおそう。なんでもいいや。とにかく、レコードとは別に特定の「親子」を表す情報構造が必要だということはわかった。以後、この「親子」を表す情報構造を「セット」と呼ぶ。で、特定の「親子」の意味ごとにユニークに「セット」が形成される。という感じかな。セットの構造を考えてみよう。セットは、親レコードと子レコードのふたつの部分からなる。ここで親だの子だののレコードとか言ってしまったが、もともとからあるキーワードそれ自体をあらわす意味がユニークな情報単位もレコードって、さっき名前をつけてしまった。そうだなぁ。言い換え。セットの構造を考えてみよう。セットは、親ミームと子ミームのふたつの部分を含む。ミームってなんだ。今アタマのなかから出てきた単語だ。アシモフのSFに出てきたんだよ、情報のかたまりだ。J1選手名鑑を作りたければ、「J1選手名鑑セット」をシステムに宣言する。そうすると、システム内部で「J1選手名鑑親ミーム」と「J1選手名鑑子ミーム」のふたつの入れ物が出来るわけだ。ううむ。これだけでは、まだセットではないなぁ。アルビレックス選手名鑑だけとりあえず形成したいときはどうするんだろう。「J1選手名鑑親ミーム」にアルビレックスを登録して、そのポインタとして、キーワードアルビレックスを設定しておけばいいかなぁ。これだと、アルビがJ1から降格しても、「J1選手名鑑親ミーム」からとりのぞけばいいだけで、キーワードとしてのアルビには影響がでないものな。あ、重大だなぁ。アルビ降格のときには、「J1選手名鑑子ミーム」の内容に激烈な変化がおきるなぁ。あとで考えられるようなら考えることとする。メンテがたいへんだなぁ。もとい。で、、「J1選手名鑑親ミーム」にアルビを登録した。次に、「J1選手名鑑子ミーム」にアルビの登録選手をとりあえず全員登録するわけだ。とは言え、こちらもキーワードへのポインタのみ登録だな。移籍があってもポインタだけいじればいいんだし。パーオプルサンガもはいるよな、親ミーム。サンガの選手を子ミームに登録。これで、、まだセットとしては完成してないよね。チームが足りないとかそうじゃなくて。

親ミームにはアルビとサンガがいる。子ミームにはいっぱい選手がいる。で、選手Aはアルビとサンガのどちらに配属なのか。

特定の子供から特定のセットに関して「親は一意に決まる」というルールは正当化できるだろう。別の親がほしければ、別の意味のセットを形成すればいいだけのこと。そこはそれ、柔軟に。、「J1選手名鑑セット」では、A選手に注目した時に、所属しているチームはどこなのか、「子ミーム」のA選手の情報ポインタにしっかり書いてあるほうがいいだろう。アルビかサンガかぐらいは情報としてもっておける。「J1選手名鑑子ミーム」のそれぞれのポインタは、「J1選手名鑑親ミーム」のどのポインタが親なのかを必ず持つこととする。親ミームがユニークに定まらない子ミームの存在は逆にいうと許さない、こういうわけかな。親なしの子ミームがいるときっとガベージ(ごみ)になるから駄目。それゆえ、アルビがJ1から降格したら、メンテが大変。仕方がないかぁ。。

以上で子供から親を特定するお話しはほぼ決まり。

で、アルビだけを見た場合に、アルビに所属するメンバの子ミームだけを検索したいわけだ。子ミーム全体はどのような構造にしておくか。芋弦にしよう。親ミーム内のアルビのポインタを見ると、そこには、「最初の子供はA」「最後の子供はZ」というポインタが書きこまれていることとする。芋弦ポインタ。システムはユーザの要請により、「J1選手名鑑」をキーワードから検索することになり「J1選手名鑑セット」を用いていいかとユーザにたずねる。ユーザはYESと答える。システムは「J1選手名鑑親ミーム」に属するポインタを複数提示する。ユーザは次のように思う。「なんだよ、サンガとアルビだけかよ。まぁいいか。あとで俺ががお気に入りのチームを投入しておこう」「さてと、アルビってあまり知らないんだけど、どうよ?」ユーザはアルビという名前のついた親ミームを選択しことをシステムに告げる。システムは、アルビ親ミームの内容を読み出し、ユーザにたずねる。「アルビレックスのチーム情報をみますか。アルビの選手をみますか。」ユーザはチームを選択。システムは親ミームに書いてあるキーワードへのポインタを元にレコードを読み出し提示。ユーザは別ウインドウでキーワードアルビの内容を閲覧後、その別ウインドウを閉じた。ユーザはさらに、「アルビレックスのチーム情報をみますか。アルビの選手をみますか。」の 問いかけに「アルビの選手」を選択。システムは、親ミームのアルビのポインタ内に書きこまれている最初の子ミームへのポインタを元に、キーワードからA選手を読み出した。画面に最初の子供Aを表示した。この画面には、A選手のキーワードの内容と、前、後、親へリンクがある。前は選択できないようだ。親はアルビのチームへのリンク。後ろは、B選手へのリンクだ。子ミームには、「J1選手セット」の親ミームへのポインタおよびに次の子ミームへのポインタ、前の子ミームへのポインタがある。B選手からはじまって次々にたぐっていけば、最後の子供Z選手まで閲覧可能だろう。

子供ミームは、「前、後、親」への三つのポインタを備えていればよいようだ。出現順位は今は考えていなかったが、たとえばチーム入団順でも良いだろう。では、入団順ではなくて、あいうえお順でも見たければどうするか。この場合には、「J1選手名鑑セット」では使えない。「J1選手名鑑セット(名前順)」というセットをあらかじめ用意する必要があるだろう。親ミームと子ミームを「J1選手名鑑セット」「J1選手名鑑セット(名前順)」とで共通に持てるか?という疑問も出てくるが、、、どうしたものか。原則、セットが違えば、親ミーム、子ミームもそれぞれ独立の記憶情報領域にあったほうが、削除のことを考えると楽だろう。

キーワードシステムへ後付け(あとづけ)でかぶせる親子セットとしての考え方の基本を以上でみてきたけれど、これだけでは、まだ、動かない。。。セットは作成できても、キーワードシステムの各キーワードに対して、どんなセットが適用可能なのかを調べるやりかたが考慮されていないからだ。どうしようか。namazuみたいな方式はできないかなぁ。特定のキーワードを指示するとそれを使用している全てのセットの一覧が出てくるようにしたいかもしれない。ナポレオンなら「洋酒」「フランス歴史上人物」「トランプゲーム」「スパイ」とかのセットの一覧が出てくる。まぁこちらは恐らく索引作りはリアルタイムには出来ないだろうなぁ。定期的にリフレッシュなのかなぁ。

親子ミームで木構造を作れるか

上でぼんやり考えた親子構造は「セット」「親ミーム」「子ミーム」によるもので、はっきり言えることがひとつ、これだけでは木構造ではないということ。キーワードのツリー化とは似てもいないけど、汎用化を志向しているので、なんとなく柔らかそうな気がする。

で、この「セット」「親ミーム」「子ミーム」を使って、特定の木構造を実現する集合を考えて見る。

木構造は、たとえば、5代続いた家系図とかを実現できるかどうかについて考えて見ればいいのかな?

さっきの、「J1選手名鑑セット」について思い出すと、親ミームには、アルビと、サンガが登録されていた。で、どちらのチームでも構わないが、それぞれ、同じ「セット」によるたぐりよせで配下の選手を抽出できるわけだ。でも、あくまで2階層。

5代続いた家系のために、4個セットを作ってもいいのだけど、なんだか無駄。という発想。初代ー2代目の親子関係セット、2代目ー3代目の親子セット、、とか4つ?徳川幕府だったらもっと必要だ。

こうした面倒くささは、以下の点を忘れているから出てくるのだろうと思う。2代目は3代目の親だし、初代の子供である。2代目は親でもあり子供でもあるのだという事実。

だからもっと抽象化してしまえば、N代目ーN+1代目親子セットをそれぞれ独自につくらず、ひとつのものとして考えれば良い。ここだけ注目すれば、2階層なのだから、「セット」「親ミーム」「子ミーム」が使える。よーし、5代続いた「ダイクーン家」を考えるぞ。

「ダイクーン家の親子関係のセット」を考える。これにはこのセット専用の親ミームと子ミームが用意される。で、5代の家計図に乗るべき人間は全部、親ミームに放りこむ。同じく、全部子ミームにほうりこむ。これでよし。要は親子関係さえ明示できれいい。誰が誰の子であろうといい。選手名鑑で親ミームにがチームが、子供ミームには選手が登録されていたけど、今回は親ミームも子ミームも同ダイクーン家のメンバーだ。

ちょっと脳内でイメージを描いて見たけど、以上でウマクいきそうだ。養子縁組とか血縁のあるなしで異なるセットを用意してもいいけど、それはまた別の話。公式に家系図を書こうとしているのだから、その基準でのセットがあればいいだろう。別セットで補うことも可能。うむ。初代ダイクーン一世には二人の子供がいる。ダイクーン2世とレオポーン1世だ。既にダイクーン一世は親ミームにほうりこんである。そのポインタを見ると、最初の子供のメンバーはダイクーン2世だ。最後の子供のメンバーはレオポーン一世だ。問題無記述できそうだ。このようにして、全ての、N代目ーN+1代目の関係は登録できる。

だが、これだけでは、まだツリーを構成するにいたっていない。どうやって全員をたぐりよせる?

うむ。判明。親ミームと子供ミームにはそれぞれ同じメンバーがそろっているのだった。それゆえ、もう一つセットを重ねる。子供ミームの中の人が親ミームにもかならずいるので、それを指し示すだけの一対一のセット!これなら、先にに登録してあるセットと親ミーム子ミームを共有してもなんら困らない。(一般には異なるセットでミームを共有することは避けたほうがいいだろう)

ダイクーンⅠ(親ミーム)からダイクーン2世(子ミーム)へたぐれて、ダイクーン2世(子ミーム)からダイクーン2世(親ミーム)へのポインタを別セットで。ダイクーン2世(親ミーム)からカナン2世(子ミーム)へたぐれる。。

こうすれば、ダイクーン家の家系は表現できるだろう。

たぶん、ループしないように考えれば、既存のキーワードに対して、いくらでも恣意的な意味の木構造をバックグラウンドデータベースとして付け加えられるのではないだろうか。

家系図は木構造ではない

家系図は木構造ではない、、ってそうだよね。いとこ同志で結婚してその子が跡取になったら、その子の親ってなによ?って思うもの。私の定義では、特定のセットでは子ミームから親ミームへのポインタは一つだけ。まぁ許して。たぶん親を複数持つと木構造ではなくなる。

はてなキーワードが削除されたらどうする

親子関係がバックグラウンドで定義されているキーワードが削除の運びになったらどうしたら良いだろう。

キーワードは、どのセットに使われているかの一覧をnamazu的に持っていたのだった。子供ミームとして使われているセットを全部洗い出す機能が必要。で、ひとつひとつのセットは壊れているから補修しなくてはいけない。ひとつのセットだけ今、考える事とするとどうなるかな。洋酒セットの子供ミームに「へげへげワイン」がはいっていて、実はこれは洋酒ではないだろう、密造酒だったとする。でキーワードも削除の憂き目にあっている。この場合、洋酒セットの親ミームとして、販売元があったとして、販売元=みじゃみじゃ洋酒店が補修の対象になるわけだ。みじゃみじゃ洋酒店の洋酒が10個あったとして、くだんのヘゲヘゲワインはその1個。みじゃみじゃ洋酒店の最初の子供としてあへあへブランデーがあり、そこから次の子供のむひむひブランデーがあり、そして、へげへげワインがあり、さらにおんぎゃぁワインがあって。あぁ飲みたい。で、へげへげワインは、もはや、みじゃみじゃ洋酒店では販売できないなと。そうすると子供ミームからは抹消。そうすると連鎖が切れる。穴があく。だからむひむひブランデーの次の兄弟はおんぎゃぁワインだよと書き換え。そしておんぎゃぁワインの前の兄弟はむひむひブランデーだよと書き換え。これで、みじゃみじゃ洋酒店の取り扱う洋酒はお掃除完了。

J1からアルビが転落したらどうするんさ。アルビは親ミームだから、まずそこに位置付けて、そこから連鎖する全ての子供ミームを順番にたぐりよせて全部削除。まぁもっとも、大元のキーワードのレコードにはなんら影響がないわけだけど。子供ミームが消えてから親ミームとしてのアルビも抹消。

なんだかすんげぇ大変。J2あたりへそっくりMOVEって手も使えるといいのだなぁとなんとなくわかってくる。

チーム間の移籍はそれほど面倒ではなさそうだなとアタリもつけてみる

やっぱキーワードの削除に際してはある程度お利口なシステムがほとんど自動で親子ミームの補修をしてくれるおうでないと駄目かな。セットからみたレコード=キーワードのデッドリンクがたまる一方だとかわいそうだし。

□ ええとぉ、ベータぐるぅぷについて

すみません、今寝られないので酒買って来ました。飲み始めます。でちょっとだけ気になっていることをアタマがマシなうちに書いておきます。

ベータグループにユーザビリティーやアクセシビリティーについて苦言を言う勇者はいるのだろうか?って。召還が足りない。とか思う。

poponapopona2004/04/30 19:03興味深く読ませてもらってます。最後の「召還がたりない」ってなんでしょ? 使いやすさはまだまだまだ(×100)使いにくいとおもってますけど。参加者が増えないのもきっとそのせい・

hoshikuzuhoshikuzu2004/05/01 00:29ええっとですね、w3c原理主義者をきどった人(書道で言う楷書)でなくてW3Cの将来を真剣に模索している苦労人(書道で言う草書)の融通無碍なかたがたの参加がまだまだかなぁと思ったのです。本当の意味でWEBのことを真剣に憂えているヒトビト。枯れている仙人なヒトビト。私の要求は無茶かもしれませんが、私ははてなが好きですし、枯れた人たちが参入してくれれば、スンゴクでかい仕事をしてくると固く信じています。ありがとうございます>poponaの人

poponapopona2004/05/01 00:41あー、そういうことですか。それだと私はさほど細かいこと気にしないので、該当しないですね。そういう方々は、はてなの仕組みが広まるのが確実なほど有名であれば、やってきてくれそうな気がするのですがね…

hoshikuzuhoshikuzu2004/05/01 00:53細かいことを捨ててホンマに優しいWEB作りって苦労がいるんですワ。ある意味W3Cに造反しないと優しくなれない、、、ちゅうのはあるような気がします。。。デス。SGMLなら幸せだったのに機械偏重なXMLに至っては、もはやWindowsで言うところのNOTEPAD(メモ帳)で手書きでHTML書き下すのとは別世界です。パーサを意識したXMLエディタで自動的にXHTMLを生成する世界になっちゃってるんです。保守的かもしれないですけれど、ヘタクソでにいい、手書きで優しいマークアップが今一番イケテル(古語)だと思われてなりません。

hoshikuzuhoshikuzu2004/05/01 00:57ところでTeXですが、読み方が「てふ」ですって。ぎょぎょぎょ。【はてな】の「てふ」のバージョンアップについてもう少しでまとまりそうです。請うゴキタイ。ゴキブリ退治ではありません<ゴキタイ