ヤフオクに凄いものガっ！
http://page.auctions.yahoo.co.jp/jp/auction/65997681
AlphaServer ES40 だよー。21264 が 4 発。 いいなあっ。
どうも、春に Alpha が出る確率が高いような気がする。 やっぱこの時期に放出されんのかね。
(07:53)
とりあえずフォルネウス (影) をぬっころしておいた。 やっぱ四魔貴族戦の音楽はかっこいいなあ。影も実体も。
それにしても最初にやったのが 8 年前だけあってすっかり忘れてる。 「ぬれてにあわ ぬれてにあわ」とか「きょ・う・じゅ」とか、 本筋と全然関係ないキーワードは覚えてるんだけど。
(10:15)
ホームを歩きながら Wiki で日本語ページ名を扱う方法を考えていたら すごいアイデアを思いつきますた！
「t-code エンコーディング」
[[ ]] の中に t-code でページ名 (もちろん日本語) を書いておくと 変換後の文字列がページキャプションになる。 変換前の文字列が URL になる。
(15:11)
http://cvs.m17n.org/~akr/diary/d2004_03.html#a2004_03_25_1
簡潔であり、かつ変更に強い記法が一番よいという点は同意します。 しかし、まず他のメソッド内でローカル変数に代入させるという操作自体が、 ぼくは Ruby 的でないと思うのです。 つまり、ローカル変数に代入させるということ自体をまずあきらめている。 そしてローカル変数がだめなら他の変数系は論外だし、 そうなるとどうしてもメソッド呼び出しくらいはやらなきゃだめでしょう。 それじゃどうせ m[:foo] と比べてたいして短くならないんだから これ以上短くするのは潔くあきらめたほうがよいと思います。 以上が前回の発言の背景です。
また他に akr さんの案で弱いと思うのは、 リテラルとして書かれた場合にのみ働くというところです。 この自動代入機能 (と仮に呼ぶ) は、 確かに変化に強い記法の中では最も簡潔であって、プログラマに好まれます。 従ってプログラマはできることならそちらを使いたいので、 正規表現を複数のパーツに分割したり定数に入れたりするのをやめてしまうかもしれません。 これはより広い視点で見たときにコードの質を落とす圧力となるのではないでしょうか。
と、ここまで書いたところで全然違う活用案を思いつきました。 MatchData の特異メソッドにするってのはどうだろう。
m = /xxx(?<foo>....)xxx/.match(str) p m.foo
(16:18)
t-code と同軸のネタで、 ローマ字入力しておくとひらがなに変わるというのもあります。 別にカナ打ちでもいいですが。
さらに、SKK 風にシフトを入れて打つと WikiName っぽくなるので それを適当に変換するという無理無理なネタも考えました。 submit すると変換候補をリストアップして返してくるので、 そこから選びます。
無駄すぎる。
(16:58)
マジにネタレスというのはどうだろ。 「マジパンにレタス」と少し似ている。
どうでもいいか……
唐突に話を始めます。
現在 BitChannel は日本語ページ名を認めていません。 BracketName はあるんですが、[a-zA-Z0-9] 以外が入ってるとリンクになりません。 日本語ページ名のいい実装を思いついてから許可しようと考えているからです。
では、どんな条件を満たすのが (BitChannel 的に) いい実装でしょうか。 少なくとも以下の条件は必要だと考えています。
えらい厳しい要求にも見えますが、 WikiName だけの Wiki ではこの条件がすべて満たされています。 したがって日本語を入れる際にも この条件は満たしたまま導入しなければ我々の負けです (そういう問題か？)
なお WikiName の特徴としてもう一つ挙げられるのが、 文字を追加するのではなく、文字を削ることで意味を持たせる点です。 できることならこの特徴もエミュレートしたかったんですが、 あまりにも無理そうだったのでやめました。 人間、限度はわきまえないといかん。
まず Wiki ソース上でリンクを作成する方法について考える。
[1] BracketName。[[ ]] でくくって指定する。 ソースと表示画面で見ためが違うのがちょっと嬉しくない。 またどんな文字列でもリンクにできてしまうのは両刃の刃。
[2] 1 の変形で、””や「」でくくる。 こちらの場合は ””などの区切り文字自体も表示されることが多いようだ。 その点で 1 よりは多少よい。しかし見ためがあまり嬉しくない。
[3] はてなキーワード方式。 既存の日本語ページ名と一致する部分文字列が自動的にそのページへのリンクになる。 この方式は特殊な工夫を併用しないかぎり ページの作成に「新規作成」メニューが必要になるので許容できない。
[4] スペースで区切られた部分文字列が「××の××」であった場合、それをリンクとする。 「××」は漢字・カタカナ・ひらがなのいずれかでなければならない。 行頭に置くと pre ブロックの文法と衝突するのが問題。 マッチしすぎそうなのが問題。 直感的でないのが問題。 ルールが独特すぎるのも問題。
[5] XXXXX-no-XXXXX をリンクとする。 これをひらがなに変換してページ名とする。 漢字は使えない。
[6] t-cod(ry
[7] 任意桁を縦読みしたときに「リンク」ってなってたらリンク
[8] 「→」を前にくっつける。本質的には BracketName とたいして違わない。 (SKK だと zl で「→」が出せることに頼って他の IME ユーザを度外視した作戦)
[9] 一文字だけの行が三行以上続いてたら全部つなげてリンク
[10] ある行が「××の××」という形式だったらリンク
なんかあれを思い出すね、傘の使い道をたくさん考えなさいってやつ。
次に、ページ名を URL にマッピングする方式について考える。
[1] ページタイトル文字列をそのまま URL エンコードして生成する。 最も一般的だが、この方式は URL を意味不明かつ % まみれにするので許容できない。 また URL が内部文字コードに依存する点は明らかに問題である。
[2] ID 方式。システム側がページに ID を割り振り、URL ではそちらを使う。 この方式は URL が意味不明になるので許容できない。
[3] 最初にページを作るときにアルファベット名を指定させ、URL ではそれを使う。 この方式では最適な URL を生成できるが、 ページ作成の手間が多少増えるのが問題である。
[4] ページ名を kakasi にかけて無理矢理アルファベットに変換する。 この方式では 3 におけるページ作成の手間を削減できるが、 必ずしも読みやすいとは言えない。 またインストールの手間も増える。
[5] だから t-cod(ry
現実的なのは BracketName と生成時の別名指定か。 「ソース上と表示画面上の見ためが同じ」 というポリシーだけ捨てれば採用できる。 でも、本当にそれでいいのかなあ。おもしろくないなあ。
おもしろさだけで言えば「××の××」形式だろう。 「××の××」ってのは、なーんとなく 「形容詞 + 名詞」のページが多いかと思って選んだんだけど、 ちゃんと統計をとって決めれば意外と使えるかもしれない。
それにつけても眠い。 眠いからこんなはっちゃけたないようがないようなないようになってるわけか。
(19:33)
そういえば、メインバックエンドに CVS がいる Wiki で MonaWiki というのがあるんですね。例によって YukiWiki 系だそうです。
http://www.hyuki.com/yukiwiki/wiki.cgi?MonaWiki
(19:42)
それで、そのURLからはページ名がすぐに思い浮かぶのですか？
＞t-code使いの方々
「リテラルとして書かれた場合のみ」：処理系の立場からすると、動的なregexpはevalするコード、リテラルは地のコードってことなんで不自然じゃないですね。むしろregexpを言語外のエンティティとして扱ってきた歴史が、両者の混在に対してなんか落ち着かない感じを覚える理由なんではないかと(自分では)思います。
（少なくとも私は）思い浮かばないですね。謎の文字列にしか見えません。
またその文字列のとおりにキーボード上で指を動かしても、脳内デコードはできません。
漢字->指の動き○、漢字->謎の文字列×、
指の動き->漢字×、謎の文字列->漢字×
私の場合もこうです。
わかりにくさを利用してパスワードをT-Codeでいれることがあります。
そうかあ、t-code エンコーディングはだめですか。
とすると流用できそうなのは、単に圧縮度の高いエンコード手段、
くらいでしょうか。