よしきさんのところには無事届いたそうで何より。 ちなみに あおきさん のご推察の通り、引用文を選んだのはわたしです。はい。 最初は「はじめに」しかなかったんですが、わりと完成直前に なってから「各部の扉にもつけましょう」ということになったのでした。 わたしとしては三原順があることよりも、三原順で始まって 紺野キタ(しかも『ひみつの階段』ではなく『ひみつのドミトリー』だ) でしめる、という構成に趣きを感じていただきたいところ なんですが、まあどうでもいいです(汗
「面倒くさい理屈」はあんまり書かないようにしたつもり だったんですが(^^; って、面倒くささの度合いが違うのか。 とりあえず第2部8章「クラスとモジュール」はやっぱり 判りにくいかもしれないので、 一読目はさらっと流し読みしていただいて構いません。 二人がかりでかなーりいじり倒したところだったんですが、 相当分量を裂いて説明しないと駄目なのかも。
また、第3部をある程度読んだら、第5部の第22章「ログの解析」を 読むといいかも。この章はいかにも由緒正しい使い捨てスクリプト的と いうか、「とりあえず目の前のデータをやっつける」際の基本に なってます。たぶん。
それと、20章「イテレータ」と21章「Mix-in」は、 Rubyの特徴的なところでもあり、またサンプルのスクリプトも イテレータとMix-inの使い方としてはわかりやすいんじゃないかと 思うので、よく読んでほしいところだったりします。 この本のハイライトじゃないかな、とひそかに思っていたり。
shakaさんとこ でnDiaryとtDiaryの比較がありましたが、nDiaryでも
はできます。ていうかこのページではそうやってます。refererに ついてはちょっと仕様が異なりますが。
さらに、nDiaryでもCGI+SSIを使えばツッコミ機能みたいなものを 実装できますが、「Rubyでもいいから欲しい」(=サーバサイドで RubyのCGI/SSIを実行できる)という人はどれくらいいますか？ や、自分のところで使う予定がない(荒らし対策とか厄介そう)なので、 それほど実装したいとは思わないのですが。
あと、段落と空行の使い分けですが、
という感じがいいんじゃないかと。
shakaさんが求める空行は、ようするにセパレータですよね。段落より 大きく、章や節より小さい部分に分割するための。 HTMLには、そのようなセパレータは存在しないはずです (だよね？＞やのセソセイ)。論理的には HR要素が近いような気がしますが、ちょっと違いますし。 また、DIV要素を使いまくる、という方法もありそうですが、これはこれで 面倒くさそうですし。 というわけで、「空行からは無名の小節が始まっている」と見なす ことにするのがいいんじゃないかと。
ところで、やのが書いているUnicode3.2の話は、83JISというよりは、
97JISで行わなかった、
「簡略化された文字を「いわゆる正字印刷標準字体」に戻す変更」なのじゃないかと
思います。この問題、(規格としてはともかく)実装としては未だに
解決できているとは言い難いわけで、Unicodeがグリフのレベルで
変更を行うという判断については、一概に否定できないように思います。
いやまあ日本人としては、「それはfontレベルで決着をつける べきなんだから、codepointとしては何も決めないようにするべき。 あとはAPIで何とかするか、variant selectorでも何でも勝手に使えば？ だってUnicodeってそういう方針なんでしょ？」と言いたいところ ではあるかもしれませんけど。
例の「青少年有害社会環境対策基本法案」の騒ぎもあって、 戦後の日本において実際に行われていた検閲について知りたくなった ので、読んでみました。
内容は、「占領下、日本ではアメリカによる検閲が 行われた。その目的は、それまでの日本の思想と文化を殲滅 するためであった。その実体は公には秘匿されていたが、 検閲には多くの日本人を巻き込ませた。それは日本人が 検閲される対象と検閲そのものをタブーとし、 仕組まれたことを意識せずに ある種の価値観で自主検閲をさせる(しかも『検閲している／させられている』 という意識なしに)ためであった」というものです。 なんていうか、一部の2ちゃんねら辺りが聞くと手を叩いて 喜ぶか、「アメリカならやって当然だね」とうそぶきそうな内容です。
歴史家としての江藤淳に対する評価はよく知らない(というか評価低そう)ので、 検閲政策の評価についても今ひとつ信用できないのが難点です。 他に日本の歴史家による、この江藤の仕事を評価したものや、 江藤の仕事を継ぐような作業を行っている人はいるのでしょうか？
とりあえず信頼できそうな数値だけ挙げておきます。
桁は合ってるかな？ 郵便のうち月400万通を開封して検閲する というのはちょっとすごそうです。「この結果、CCD当局は、 いかなる世論調査機関が企てても果し得ない、精密極まる 日本の世論動向を把握するにいたったのであった」(p.249) とか書かれています。
この話は、「忘却の穴」を強く想起させます。 ここで言う「忘却の穴」とはハンナ・アーレントが提唱した概念で、 ナチスのホロコーストで行われた 「虐殺された人間が存在していたという記録・記憶や虐殺そのものの記録をも、 政治的に組織された大規模な権力を使って抹消しながら行われる虐殺行為」 という、 「作動した痕跡そのものを自ら消していくような権力の作動」 のことを指しています (この言葉は、稲葉振一郎さんの『リベラリズムの存在証明』【 bk1 / ISIZE / 旭屋 / Jbook / BOL / 紀伊國屋 / amazon / eS! / 富士山 / 本屋さん 】で 知りました)。
虐殺のような極端な行為は、それが大規模になればなるほど、 隠蔽が難しくなるでしょう。そうすると、その痕跡を 消していくためにも、副次的な虐殺またはそれに相当する 暴力を駆使する必要がある……という、悪循環に 陥る危険性が高くなります。
一方で、「価値観の組み替え」程度(!)であれば、 隠蔽作業の困難もぐっと減ります。隠蔽に加担する人々に とっても、隠蔽することの罪悪感はそれほどの重みを持たずに 済むかもしれません。それは隠蔽をより巧妙なものへと変化させる ことになります。
言うまでもなく、CCDの検閲政策では、「検閲制度への言及」も 検閲対象になっています。
(略)
(四) 検閲制度への言及
出版、映画、新聞、雑誌の検閲が行われていることに関する 直接間接の言及がこれに相当する。
(略)
(A Brief Explanation of the Categories of Deletions and Suppressions, dated 25 November, 1946, The National Recored Center, RG 331, Box No. 8568.) (p.238)
『Unicodeはギリシャ文字の「ファイ」の二つの意味を区別して符号化していますが、 意味的な使い方とよく使われる字体が異なっていました。そのため、Unicode 3.2では二つの 文字の字体のコードポイントを入れ替えました。』……ということなのかと思ってました。
83JISと97JISとUnicode3.2の違いについては、後者２つが「みんな（って誰？）が 期待している字体と異なる字体が使われているため、それを変更する」という 意味からです。83JISの変更理由については事情がかなり違いますから。
それと、97JISで変更するのが得策ではなかったのは、それが97年だったからで、 もっと早い時期なら再変更の方が混乱は少なかったかもと思ってますけど、甘いですかね？ もっとも、JISでそのようなことをやろうとした場合には、(当時は「嘘字」と 思われていた)地名字などについても一悶着ありそうでしたし、そもそも そんな素早い対応をJISに期待するのが間違い、という気もするしで、 結果としてはやはり再変更という選択肢はなかったように思いますが。
実装については、WordやExcelなどでは入力・表示できないと思ってたんですが、 違いましたっけ？ 違ってたらごめんなさい。
(あと、呼び捨てって気になる？ 気になるようなら変えるけど(私信)。 しかし呼び捨て＋ですます体って、「お前らJIS X 0213の使い方教えてください」 みたいな文体のような気がしないでもなく(謎))
よしきさんのご指摘(4月16日)ですが、 それは本文です。たぶん。if文の条件判断には、true/falseではなくnilを使う こともできるよん、ということをさらっと紹介したかったなあ、という気持ちが 込められているような気がします。
あおきさんのご指摘(4/16)の これの話ですが、 山村暮鳥は1924年に亡くなったんだそうです。 つうか、4行バージョン(3行目が「かすかなるむぎぶえ」となる)の 元ネタも当然あったりするんですが、その辺のことを書き出すと きりがない上、どうにもお間抜けさんに見えるような気がするので、 あんまり書きません(_o_)
でも、あおきさんに引用を気に入っていただけたのはちょっと意外かも。 どちらかというとRubyを知らない人向けだったので。
ところで、tDiaryのような、
という方法ですが、これは良し悪しですよねえ。CGIをばしばし 叩くのはサーバに負荷がかかるので、ちょっと気が引ける、 というのはあります。もちろん、余裕があるサーバを使っている 場合には、たいして問題にはならないのかもしれないわけで、 利便性の面からこのような設計を行う、というのも正しいと 思います。
nDiaryは静的生成が基本なので、ツッコミを実装する際にも 特にページ表示機能の切り分けは行うべきではないんでしょうね。
うわ、そうかもしれません(汗。そういえばUnicode3.0は まだ買ってないのでした。うーん。
時期の話 ですが、
ということだったら、実際「大丈夫」だったかもしれません。
インプリメンタに気を配っているというのは、JIS X 0212の 実装が進まなかったことの反映ですよね。 codepointの範囲を変更した件 (当初予定していたcodepointの範囲ではいろんなソフトで障害が出る、 というのが仮公開期間中に判明したので、codepointを 狭めることになった)は、ちょっとあややと思いましたけど、 最終的にはなんとかなりましたし。
よしだむさんは3月にあった、RubyとSablotronの発表は 見られたのでしょうか？
浩子さんの新アルバムを買いました。
「翼」というタイトルとは裏腹に、飛翔感に徹底的に欠けてます。 これから飛ぶための、あるいは飛ぶためのはずだったものとしての翼、 ということかもしれません。
『ゆりかごの歌』の「そう作られた」という言葉が重いです。
む、ちょっと前提が違っているかも。 まあ「折り込み済み」なのはtDiaryとしては当然なんでしょうね。
大元の問題は、
というところにあります。 「ツッコミ欄はあくまでツッコミであって掲示板ではないのだ」というのは 主に後者にかかるところですね。
この問題の解決策としては、
が考えられます。tDiaryで実践しているのは3番目ですね。 が、1番目や2番目の選択肢も考えられるわけです。 2番目ではなくて3番目を選んだ理由が、「利便性」ではないか、ということなのでした。 んー、説明が少なくてすみません。
そうです。って、そもそも行かれてなかったんですね。ざんねん。