「分からない」って
すばらしいことだと思いませんか？
全てが分かるのなら――
「知る」ことを望みはしないし 「知らずにいる」ことだってできない
……それはとても
――「知らない」ことで見えてくる世界に
決して触れることはできないのですから――
弟くんが修学旅行中のため、初めて見る(おかげでビデオ録画依頼が大量にあって、もう、たいへん！)。
今回だけしか見ていないけど、とりあえず、きちんとしたコンセプトが見えていて好感がもてる(シスプリアニメと違ってきちんと人物が生きているように見えるというか……)。 ……今回でついに十二人になってしまったようなので、多すぎる登場人物をきちんと管理できるかどうかが気になるところ。
・得尊さんへ
お礼なら可憐ちゃんに。 可憐アンテナのおかげで、こうして情報を提供することができたのですから。
……それにしても、巨↑乳
および巨↓乳
は最強の表記法ですね。
アナリシスパターン読了。
いくつかしっくりこない部分はあるものの、噂ほど難しくはありませんでした。
ビジネスオブジェクトを取り扱っているものですが、何かやりたいことがあってそれに応じてモデルを組みたてるという形をとっていくなら、それ以外でも十分に役立ちそうです(XPと相性がよさそうですね)。 ……あえて言えば、ビジネスの方が要求が形として見えてきやすいため適用しやすい、というところでしょうか？
<!--この調子だと、(趣味でやっている身であっても)ビジネスオブジェクトの本も役に立ちそうですね-->
今日は私の分身の一人、亞里亞の誕生日でした。
ようやく答えました。
ついでに、これまでの100質問をすべてサルベージしました。 リンクはProfileにあります。
それを恐れているにもかかわらず
知らず知らずのうちに、 その状態になるようふるまっているのだとすれば――
――滑稽だ――
……私が答えなくちゃないけないのかな…？
とりあえず、オブジェクト指向とはなにかを読めば、一通りの理解はできると思います。
簡単に説明すると、"セールスマンは人間である(継承)が、他者と向き合ったときおこなう行動(メソッド)は同じであっても、それを実際におこなう時の振舞い方が違う(多態性)"とか、愛は素晴らしいものだと人々は認識している(インターフェース)が、愛がどういうものであるかの定義は人によって違う(多態性)
とか、"彼女はこういうことをしてくれるから、親切なひとだ(包括、カプセル化 (彼女の外見からは親切なひとであるという性質は見えないが、行動という外にあらわれたものを通して性質を知ることができる))"とか、そんな感じです。 (包括の説明があやしいんですが、これは継承のような＊＊であるという関係(is a)ではなく、そういう性質をもっているのだ(has a)ということだと考えてください。 ……カプセル化もそれなりにあやしいのですが、これについては上記URLを参照してください。)
オブジェクト指向がどういうものなのか実感として分かるためにはデザインパターンを学ぶのが一番なのですが、原典であるGoF本(ISBN4-7973-1112-6)は一般認識として難しいものなようです(Smalltalkで書かれているコードに困ってしまったり……)ので、結城さんの書いたJava言語で学ぶデザインパターン入門(ISBN4-7973-1646-2)で学ぶことをおすすめします。
<!--一応、Rubyの本にもデザインパターンについての説明はあるようですが……-->
言葉を嫌いになることができるように
好きになることもできる
せめて、 そう――信じたい
[ネタ元 ピアソン・エデュケーション図書目録 - 2002年 Winter-Spring]
など。
テンプレートを使ったプログラミング技法を解説した、C++パターンプログラミングは来月発売らしいです。……ところで、これってどういう範囲のものなんでしょうか？ 副題に汎用プログラミングとデザインパターンの活用法、とありますが、自動SingletonユーティリティーのようなGoFのパターンをテンプレート化したものなのか、それともテンプレートによって実装された新たなデザインパターンを紹介する本なのかが気になります。……どちらも価値あるものですが……あっ、LokiというC++ライブラリを使って、具体的に説明している
と書いてありますから、それを調べればいいんですね。
<!--POSA2とEssential Java Style : Patterns for Implementationって、どこかで翻訳がすすめられているんでしょうか？ どちらも(分散パターンやxUnitに使われているCollecting Parameterパターンなどの)重要度の高いパターンが多く集められているため、需要のあること間違いなしなのですが、POSA2のパターンは小出しにとはいえぽろぽろと色んなところで紹介されてしますし、Essential Java Style : Patterns for Implementationは書き方がSmalltalkっぽいと批判されているため、翻訳本がでるのかどうかよく分からないのですが……やっぱり翻訳本がでるのを覚悟の上で買うしかないのかな？-->
もっとよく見てごらん
そうすれば――今まで当然だと思っていたことに
多くのものが介在していたことがわかるだろう
真っ向から批判する文はたくさんあるので、あえて別のやり方で……でもないか……
窓の杜 - 【連載】ひぐちたかしのオンラインソフトよもやま話 第33回：オンラインソフト社会の構造改革（中編）〜見直すべき現実と責任〜
さて、法の原則は「契約」だと思います。お総菜の例だと、「この食べ物は食べてもだいじょうぶだということが保証されています」ということが売買時の暗黙の契約として存在している、と考えるのが妥当でしょう。ソフトウェアは「特別」なのではなく、そういった社会通念が形成されてないということになります。これには、腹をこわさない食べ物は容易に存在しえるが、バグが無いソフトウェアの存在は困難だということが背景にあるでしょう。暗黙の契約はものによって変わります。むしろ全て同じほうがおかしい。そもそもソフトウェアの免責は暗黙どころか明示的ですしね。←ある意味「物」からの束縛から逃れたもの、ということになります。それにいまさら物と同じ基準を適応されても困るのねん。 (追記:食品こそ特別。なるほどー)
[フリーソフトウェア - 電波とどいた？ より]
……というか、PL法にはこういう条文があります。
(免責事項)
第四条 前条の場合に場合において、製造業者等は、次の各号に掲げる条項を証明した時は、同条に規定する賠償の責めに任じない。
- 当該製造物をその業者等が引き渡した時における科学的又は技術に関する知見によっては、当該製造物にその欠陥があることを認識することができなかったこと。
- 当該製造物が他の製造物の部品又は原材料として使用された場合において、その欠陥が専ら当該他の製造業者が行なった設計に関する指示に従ったことにより生じ、かつ、その欠陥が生じたことにつき過失がないこと
ですから別に「特別」な枠とみなさなくても、「ソフトの誤使用や意図せざる使い方、バグが防ぎにくい」という一般的な認識や、それらに関する山ほどある証拠などによって、今ある状況の正当性を証明できると思います。
<!--ライブラリやOSのバグってこともありますし……-->
とはいえ、裁判となると必ず勝てるとは限りませんし、費用や時間など様々な苦労を強いられることになってしまうので、それを避けるための手段として免責に関する規約を設けているのです。この辺のことを勘違いしてはいけません。 (ひぐちさんはソフトウェア利用者を守ることばかりに目を向けていて、ソフトウェア作者の権利をないがしろにしてしまっています。利用者に対して配慮するよう呼びかけるのはよいことだと思いますが、その際にソフトウェア作者が(できないことを約束しないことを明示することによって)己の身を守る権利があることを忘れ去ってはいけません。)
こう書くとすぐ「市販商品とオンラインソフトは違う」という意見が出てきそうだが、じゃあなぜオンラインソフトだけが“優遇”されてしかるべきなのだろうか？
ちなみにオンラインソフトに限らず、市販のパッケージソフトでも使用許諾書には同様の免責に関する記述がしばしば見られる。しかしパッケージソフトの場合は電話などによるしっかりしたサポート体制が用意されていることが多いし、開発元や販売元の住所、代表者名、連絡先電話番号が明記してあるなど、社会的責任についての意識はオンラインソフトよりも強いように感じる。
[共に オンラインソフト社会の構造改革（中編） 〜見直すべき現実と責任〜 より]
これは会社としての商品販売戦略です。世の中に出まわる多くの商品にはサポートがあり、それが当然のことのようになってしまったため、(消費者を保護する法律とあいまって)感覚がまひしてしまうのだと思いますが、アフターサービス等のサポートは消費者を獲得するための手段であることを忘れてはいけません。
消費者が自分にとってより有利なものを選ぶように、規約に納得できなかったり、サポート体制に不満があるのならば、そのソフトを使わずに別のソフトを使うという選択肢があります。それを忘れ去り、利用者としての権利ばかり主張するのは傲慢な態度だと言えないでしょうか？
<!--利用規約は押し付けではありません。それに価値を認められるかどうか、納得できるかどうかを検証する確認作業です。契約とは概してそういうものです。-->
猫がプリンタの上で熟睡している。突っついても起きない。可愛いんだけどオレは印刷したいんだよう。
[人間城の主な日々<11月7日> より]
こうして、ねこしばり
の定義が、「外的な要因により、(思い通りにことが運ばなくなり、)やりたいことができないこと。特に、その原因がねこであることを指す」というふうになってしまうわけですね。
その瞬間、薄さも軽さも華奢な足も、一瞬にして致命的な欠陥に変わりました。ぎゃー。やめてやめて、その棚の上を走らないで！！ 倒れるよ、落ちるよ、壊れるよ！
結局、便利で画期的で、どこにだってついてきてくれるはずのピクミンのようなテレビは、その特性を生かした場所にではなく、壁際の、割と無難なポジションに安置される事になりました。
このようにして、物の配置が否応なしに決定されることを、専門用語で「ねこしばり」といいます。（命名、Y.Narushima）
[Narushima's Talk! (なるしまゆりHP「地底探検」内) より]
おまけ
もうちょっと目端が利かないものかと、自分でがっかりする。さっき記録を調べてみたところ、 10章書いてくる間に本半分くらいの量のテキストを破棄していますもの。 (というのは具体的には300KBくらいのテキストということです。『Java言語で学ぶデザインパターン入門』のテキストは約600KB)
いかに書くか、ではなく、いかに削るか、が大事だ、と云ふ教訓。
必要最小限の努力で最大の效果をあげたいと云ふ横着な發想よりも、出來るだけの努力をしてからエッセンスを抽出しようとするプロのライターの方が、良い結果を生むもの。
[闇黒日記<平成13年11月8日> より]
「そうありたい」と思いながらもそうできないことを、どんなに搾ろうとも、削れるほど多くの言葉を生み出さない我が身を恨めしく思っていたけど、ふと思いなおす。 削るとは何も文章になった段階のことだけを意味しないだろう、頭のなかにある考えを文章に直す際にも削るという行為はおこなわれるはず(ついでに言うなら、考えを広げたり膨らませたりすることも)、手段を求めるがあまり目的を見失ってしまっては元も子もない。
だとすれば、野嵜さんの発言は「貧乏性を捨てよ」と言いかえることもできるだろう。本来的には「必要最小限の努力で最大の効果をあげる」というのは、「楽になれるのであればどのような努力もおしまない」や「大きな障害と小さな障害があったとき、小さな障害では遠回りになることに気づいたとき、そこに辿りつくためにあえて大きな障害の方をとる」というようなことをも意味していたはずだ。だが、多くのものは「楽をすること」にこだわりすぎるがあまり、かえって大きな苦労をするはめになったり、楽をしなかったことへの見返りを求めたがる。 そしてその結果、でてきたものをでてきたままの姿で見せようとする。削ろうとする意志は、捨て去ろうとする意志はあまりにも薄い。
<!--言い得て妙なことであれ、至言であれ、そこに存在することがふさわしくないのであれば、捨て去らねばならないというのに-->
結局のところ、「最小限の労力(あるいは行動)で最大限の効果をあげる」ということは可能であるにしろ、「最小限の努力で最大限の効果をあげる」ということは絵空ごとなのだろう。 日々の積み重ねにより習慣化することによって、そこに費やされる労力を減らすことはできる。修練によって労力を減らすことはできる。労力を減らすためのあらゆる手段をとることができる。だが、そこに努力は費やされなかったと言えるだろうか？ 労力を減らそうとしていくプロセスこそが努力ではないだろうか？
……ということを考えていて、ふと思いついた。ある結果に辿りついたときの、そのひとの努力の総量というものは、変わらないものなのではないだろうか？ 簡単なものに少しずつ取りかかっていくという行為における努力は、難しいものに真っ向から取りかかりなおかつやりこなした際の努力を小出しにしたものではないだろうか？ 労力の総量が多いことを、多くの努力をすることだと思いこんでいないだろうか？ 、などということを。
努力があったからこそ「最小限の労力(あるいは行動)で最大限の効果をあげる」ことができるということと、労力を費やしたからといって放棄することをおそれてはいけない――その努力を怠ることによって求めているものに手がとどかなくなるかもしれないということ。この二つを忘れてはいけないだろう。
ただの一言が感じることのできない風のようなただの一言でしかありえないこともあれば、ただの一言であるがゆえに何百何千もの表現よりも心をゆさぶることもあるのだから。
PL 法の対象は「動産」であり、法律制定当時の政府見解では コンピュータソフトウェア単体では製造物責任法は適用されない*1ことが示されています。この点は学説でも異論なく認められているようです (参考: 内閣府国民生活局による製造物責任法の説明)。
*1:ただし、機械などに組み込まれたソフトウェアの欠陥は「機械の欠陥」として PL 法の対象となります。
[製造物責任法とソフトウェア - M's Diary より]
……そうでしたか。いささか拡大解釈しすぎていたようです。
無理矢理適用しようとすると、問題が多く出てきてしまいますし……まあ、当然といえば当然なんでしょうね。
ブギー・ポップが（lainの）続編ぽいというのと同じぐらいには（lainの）姉妹編ぽい作品が最近までやっ ていました。それは、意外に思われるかも知れませんが、シスター・プリンセスです。この作品、現代のキリストと12使徒（お兄ちゃんと12人の妹たち）が失意の内に離散、キリストは海で溺死という悲劇をなかったことにするために、使徒の一人が約束の島に都市を丸ごと造り、アルバイトやら一人何役もこなすやらで住人をでっち上げて、その演劇空間で「幸せなキリストと12使徒」を真に迫って成立させます。結果として、量子論のコペンハーゲン解釈が働き、既に起こってしまった現実が書き換えられてし まう、という。物語の骨組みがlain並にハードなので、結構見る者に真剣な視聴を要求するのですが、 見ていた人の多くはそんな見方はしていないと思われ、ある意味では不遇な作品ではあります。
[バーチャルネカマアイドル・ゆき14歳 経由]
……なるほど、私のシスプリは兄に萌えるべき作品だという意見をもう一歩推し進めると、こういう考えが成り立つわけですね。
[インターネット風時代の流れ - いがぴょんの日記v2 より]
ようやく正式版がでたみたいです。
昨日の日記に付けたし。
「最大限の効果をあげられる」というのは自分にとってそうだということであって、他人にとってもそうであるということを意味しない。どんなに力を注ごうともそのことが他人に評価されるとは限らないし、それがかえって酷評されることもあるだろう。削るという行為であるならばなおさら。物語について言うならば、ある人にとっての世界観の破壊は、削られた結果情報が不足していることによって起きることでもあるし、それまで極限まで削られていたものが別の姿をさらけ出した瞬間に起きることでもある。
だが、だからと言って絶望することはないだろう。世界観の破壊というものは世界観の構築なしにはありえないのだ。失望ということは期待がなければ引き起こされないことなのだ。
<--これ以上書いても蛇足にしかなりそうにないので、やめ。-->
今日の番組は、どれも盛り上がってきたところでいい感じ。
サークルの会合にて、ライトノベル談義。アニメや漫画の話もほんの少し。(海外作品でのオススメものも聞けました。)
最近コンピューター関係の本ばかりしか読んでなかったので、とても参考になりました。……とはいっても、一ヵ月に最低2冊くらいは読んでいますが……
P.S.サークルのメンバーの好みが窺い知れたような気がします。 デビチルを薦められる理由が、アニメが似ても似つかぬ作品にならざるを得なかった過激ぶりだったり……ベイブレードを薦められる理由が、"爆転シュート"という軽快な名前からは考えられない殺伐とした雰囲気や荒唐無稽さを相殺するある種の恐るべきリアリティ(他のスポーツを思い浮かべれば分かるはず…)だったり……
(先週の最後を見てからずっと思っていたのですが、)ヒカルはいつのまにあんなに大きくなっていたのだろう。 ヒカルの内面的な成長が、外見を変化させることによっても描かれていますね。……とても大人っぽくなったような、そんな感じです。
これまでは佐為がいたから、姿を消しからも佐為の影を追いかけていたから、子供として描かれてきた。ヒカルがヒカルを超えたとき、衝撃的な出来事を乗り越え、自分のこれまでを肯定した上で新たに自分の進むべき道を見つけた時、大人として描かれるようになった。そういうことなのでしょうか？
……ということは、これからは大人のヒカルとしての姿が描かれていくわけですね。今後が楽しみなような、恐いような……
つきねこ日記 - 2001年11月12日で、ホームページビルダーの新バージョンについて触れていたので、今度こそXHTMLサポートだろうと期待(手抜きしたいだけ)に胸を膨らませて確認しに行ってみる。
XHTMLはサポートしようとしないんですか……もう諦めるしかないですね、これは。
「テンプレート使用の副作用により、誰でも似たようなデザインになる」という現象から逃れようとする動きと、デザインに対するニーズの高まりが、どこでも配置モードを生んだんでしょうけど……tableとdivによるレイアウトに頼りきっていて、CSSをオフにすると悲惨なことになるダメなソースを吐くように改悪されています。
<!--最後の意味深な銃声が解釈に余地を与えているため、どんな解釈をすることも可能ですが……誕生
というサブタイトルを尊重し、ここにノワールが生まれたという意味に解釈します-->
ノワールの名をも棄てることによって、はじめてノワールたることができる……
「何ものにも束縛されない」ノワールを望みながら、それゆえに「何ものにも束縛されない」という己の理想によって束縛しようとしていたアルテナは、皮肉にも己の望んでいない形によって己の理想を実現させることになる。 アルテナの死とノワールの誕生。それはアルテナの望んだ形での実現ではなかった……だが、むしろそれでよいのだろう。もしアルテナの望んだ通りことが運ばれたならば、「何ものにも束縛されない」はずの者達にアルテナの影がつきまとうということになっていたのだろうから。
アルテナはノワールをもっともよく知るがゆえに、ノワールというものについて重大な誤解をしていたのではないだろうか？ アルテナはノワールが「何ものにも束縛されない」こそが重要だと思っていたがゆえに、片方を欠けさせることへのためらいがなかった。だが、むしろノワールは「絆」こそが重要であり、その「絆」ゆえに他の「何ものにも束縛されない」という性質を帯びていただけだったのだろう。
さて、「愛で人を殺すことができるのなら、憎しみで人を救うこともできるでしょう」
ですが、私は作品においてこの命題が否定されたとは思いません。確かに前回の時点では「憎しみでは人を救えない」
と否定されました。ですが、それまでの話を通して二人はもはやそちらの側に安定した存在ではなくなっていた。それゆえアルテナとの邂逅が最後の一押しとなり、アルテナの意図した形でなかったとはいえ、二人の性質を変質させてしまった。 よって、作品から命題に対する明確な答えが与えられることはなく、持ち越された――視聴者の手に委ねられた、と解釈します。
今日一日、シュガーが頭に残って離れそうにありません……
一生懸命になることが、
このお話では救いがあったけど、救いが訪れないことも多い。ちょっとしたことがきっかけで、お互いの想いがすれちがい――そのまま終わってしまう事だって多い。
気づかぬことの痛み。人一倍察しの悪い私にとって、それはとても身近で、そしてとても痛いこと。 「相手に行為を寄せていながら、そのつもりで相手を踏みにじってしまう^」なんてことに覚えがあるだけに、この2話はつらく、それでも目を背けることのできない話でした。
軽いことには違いないのですが、そう言うばかりでは能がないので、2時間半ほどかけてメモリの使用量について調べてみました。
(画面に表示していない状態や、そこから復帰させた直後の使用メモリが極端に少ない状態を除きます。 なお、ここに挙げられているWin IEのメモリ使用量はWindows2000でのものです。9X系ではより多くのメモリを使用すると思われます。)
| ブラウザ | 使用メモリ(M) |
|---|---|
| WinIE*3 | 約(8~14)*3 |
| DonutR(WinIEコアのタブブラウザ) | 約10~14 |
| Mozilla(Lo-Fi (軽量スキン)) | 約16~25 |
| Opera | 約10~15 |
私の気になっていた本は……結局どれも今月は発売されなそう……。Amazonによると、Effective Javaは12/03発売予定だそうです。
Borland(R) JBuilderTM 6がでるようですが、できればJava 1.4のリリースを待って欲しかった…… ユニットテストが標準搭載というのがうりの一つであるようですが、使用できる機能は製品形態により異なります
……とのこと。Personal版にはどの程度のものが提供されるのでしょうか？
<--先日どこかで話がでていたKylix 2の日本語版やEnterprise Serverもすかさずリリースされるそうです。-->
さて、児童ポルノ関連で日本はどう動くか……児童ポルノ禁止法に直接響いてくるだけに、気になるところです。
牛乳ブラウザの件は、どうやら解決したようですね。 UA 偽装機能がWebにどういう影響を及ぼすか……気になるところです。
[デザインパターン・メーリングリスト 経由]
[XML/DOM Programming 経由]
そういう心配はしなくていいですよ、言葉の綾です。ゆっこさんはそう言って、相手の危険性を喚起しているんですよ。 >可憐ちゃん。
[回顧録 経由]
既にあったんですか……危ない危ない、車輪の再発明を行うところでした。
(中略)
しかしすげぇ勢いの大拡張。ぜんぶ実用になったらなんてシアワセなんだろう…毎度のことながら。
[CSS3 せれくたー - ねこめしにっき より]
SVGやSMIL向けだとしか思えない凝り過ぎたロジックのものもありますが、E ~ F、E:not(s)あたりは素直に喜べます。 langによる指定がわざわざ別のものとして用意されているのは、音声スタイルを意識してのことでしょうか？
で、それが実現するのは 10 年以内ですか？ その前に HTML4/CSS2 の完全サポートはいつになりますか。 ＞ 全ブラウザベンダ?
[CSS3 せれくたー - ねこめしにっき より]
それは言わない約束……じゃなくて、特になにかと批判の対象なっているMicrosoftには頑張ってもらいたいところ。SVGもありますし、もう、顧客の要望があれば実装する
なんて言っている場合じゃありませんよ。
Gファンタジーの高河ゆんの新作LOVELESSを見て、ねこみみ美青年の色っぽさに、思わずどきっとさせられたり。
やってしまうと、その証として耳がとれてしまうなんて……ある意味すごい設定……。
まさに、今回の番組は粒揃いでした。 その反面、コメットさんが、話はいよいよ進んでいるわりにはパワーダウンしているように見えて残念なのですが……後に向けて今は抑えているのだと信じたい……。
目当ての人がいなかったので、二次会(お食事会)でお話しを聞いていました。
好きな話題のせいか、サークルでは多弁になってしまうことが多いだけに、終わった後「話を聞いているだけで面白い？」と聞かれてしまいましたが、そのことで逆に「私は人が話しているのを聞くことが、だいすきなんだなぁ」と逆に実感してみたり。
いらぬ心配をかけてしまったようで、ごめんなさい。
……たぶん、ここは見ていないでしょうけど……
普通に面白い作品でした。
制作者の理想が表れた、クライマックスと結末だったと思います。
川俣さんも、ひぐちさんも、多分、胸にある伝えたい想いは決して悪くないはずなのに、表から見える(に現れる)主張は正しいとは言えないものになってしまうんですよね……。
批判はスラッシュドットで十分になされていると思いますので、あえて批判はしません……
本当はいろいろとコメントしたかったけど、シュガーに備えて寝るので……
自分が目指そうとしているものの領域を侵そうとしている相手に――自分とは違ってそれに手が届きそうな相手に、反発し、嫉妬しつつも、相手を認める話。
……前回、前々回ときらめき探しのテーマの部分を描き始める段階になって、お話が格段によくなってきたような気がします。見習い季節使いたちがそれと知らずに人間たちのきらめきと触れあう中で、どう思い、どう感じていくのか……今後が楽しみ。
いまさらですが、シュガーって児童文学のような話ですね。
……ここで再び、紅麗との対比が描かれることになるとは……
水鏡と師匠の話とか、思ったよりぬるくてあれれと思う話が多かっただけに、ここ数週間の真摯な描きっぷりはすばらしいと思う。 幽々白書を超えるか、二番煎じに収まってしまうかの正念場なだけに、今後の展開から目が離せない。
「内輪であることを明示するために、アクセス性をわざと下げる」というアプローチもあると思うのですが……その辺はどうなのでしょうか？ (もちろん、そういう部分以外はきちんとしていることが前提となるわけですが……)
- 例文１
- 看護婦コメットさんにヤラレた人が あ っち こ ち に出現の模様〜。
これについては、以下のように書けるようになって、なおかつブラウザがサポートしてくれるのであれば、問題はなくなるんでしょうけど……
<a xlink:type="extended" title="看護婦コメットさんにヤラレた人々の感想">
<!--==ローカルリソース==-->
<local xlink:type="resource" xlink:label="nurce-commet">
看護婦コメットさんにヤラレた人があっちこちに出現
</local>
<!--==リモートリソース==-->
<remote xlink:type="locator" xlink:label="shelarcy" title="私の感想"
xlink:href="http://page.freett.com/shelarcy/diary2001-11.htm#xhlink0"/>
<remote xlink:type="locator" xlink:label="arimika" title="ありみかさんの感想"
xlink:href="http://www.remus.dti.ne.jp/~a-satomi/nikki/2001_11c.html#day22num04">
<linktitle xlink:type="title">
さとみちんは<q title="ココロ図書館に対する黒田さん自身の感想らしい">萌え死</q>しそう？
</linktitle>
</remote>
<!--==ローカルリソースを最初に表示、私の感想を(最)後に表示==-->
<arc xlink:type="arc" xlink:form="nurce-commet" xlink:to="shelarcy"
xlink:actuate="onRequest" xlink:show="replace"/>
</a>
XLinkの名前空間はDTDで既に指定されているものとします。(スマートな方法ではありませんが、XLinkは標準規格なので問題ないと思います。)
ソフトウェアの達人たち - 認知科学からのアプローチ(ISBN:4-7952-9733-9)読了。
一つのテーマに対し、多彩な視点から様々に語られるというのは、とても素晴らしいことだということを再確信。
――そこには様々な知恵と輝きが凝縮されているのだから。
中途半端に啓発を意識しているため、基本的なことばかりで、「では、どうすればいいか？」ということに対して具体的に答えていなくて困るといったといった欠点はあるものの、アイデア箱であることに間違えはなく、それなりに参考になりました。
うちは寝る時間に厳しいため(特にお父様が)、堕ちゆく星々を眺めることも、チャットに参加することも、できませんでした。
流星群とか「星降る夜」
や「星に願いを」
と聞いて、STARGAZER 星に願いを を思い出してみたり。
気になっていた本のうちいくつかは、ピアソンの刊行予定に載っている通りにきちんと発売される模様。 どうやら、すべての本がすぐにAmazonに掲載されるというわけではないようですね。
読む年齢についての話は、同時に、「そこまで到達していない」
と「そこを通り過ぎてしまった」という話でもあるのでしょう。(参照：らむださんの読む年齢に対しての話)
私はまだいつ頃にその作品に触れておけばよかったという思いをしたことはないのですが、もっと早くこの作品に出会いたかったなと思ったり、もう少し違うときに出会っていたらどうだっただろうか、と思うことはあります。 ……絶対いいから読んでと言われた作品なのに、今の状態で呼んでしまったためピンとこなくなってしまっていたという、苦い思い出が……
本人の読んできた背景というものもあるんでしょうけど…… 中二までは主に民話とか童話の類の何度も読み返すことばかりしていたり、小学生にして既に大人向けの漫画も分け隔てなく読んでいたり、中学まではそもそもテレビを見る習慣がなくて、その頃の作品を見逃したりしているので、(あとは書き手指向なところがあるので)その辺で大いに感覚が違ってしまっているのだという自覚あり……
……だから、人が薦めるのを聞いたら、すぐにでもそれを読んでみようと思ったり、「この順番の方がいい」という話を聞いたら、それに従おうとしてしまうわけです。 ……そのことで逆に後悔することもあります。人の話を聞いてしまったことで、聞かなければ感じ取れたであろうことを、その順番に従わなければ得られたであろう想いを、感じ取れなくなってしまうのですから。
……なんか、いつか同じことを書いたような気がするのを拭えません。
<!--どうでもいいことですが、フルバを観た直後なせいで、日記を書いているときの脳内音声が、本田透になってしまっています。(いつもは亞里亞や千影、他なんですが)-->
何もHTMLについてだけ試行錯誤しているわけではありませんが、Web上にリソースを作るとなると必然的にHTMLを使うことになるため、どうしてもHTMLに関する模索という形になってしまいます。
引用を多用してみたり、リンクに関するスタンスを変えてみたり、そういう工夫をして、どうしたらその文章そのもので意味を持ったまま、リンク先に対する(参照先のものとしての)価値をもたせることができるか？ ということについて考えているのですが、日記はリソースとして役に立たないという意見を読んで、「なるほどな」と思わせられたり……
そんなわけで、遅まきながらいくつか意見を……
バリ略語であるkbdに対して、勇ましくフルスペルmouseで良いのかというつっこみじゃなく。mouseがでるなら、<pen>とか、<gun>とか、<handle>とか、<footpedal>とか、<speak>とか、<screen>なんかをつけても良いのではっていうことで。
(中略)
speakはもちろん、kbd、mouseが出るなら、音声エージェントのための要素も必要と言うわけで。screenは画面タッチデバイスだから、マウス系になるのか。筆圧コントロールみたいなのもあるなってのは、ペンと一緒か。
こう考えると、kbdってない方が素敵っていう要素なのかもなあ。
[キーバインド - つきねこ日記 より]
鳩丸倶楽部で取り上げられていましたが、HTML2.0では以下のように定義されていたようですね。
The <KBD> element indicates text typed by a user, typically rendered in a mono-spaced font. This is commonly used in instruction manuals. For example:
Enter <kbd>FIND IT</kbd> to search the database.
[Hypertext Markup Language - 2.0 より]
すると、やはりkbd要素は過去の遺物ですね。 デバイスといえばキーボードであったころの名残であり、またコンピューターのことを語ればよかった頃のものであり、今の実情にはあわないと。
……とはいえ、kbd要素を使わなかったり、キーボード以外のものに使うのは気が咎めるので、仕様レベルでなんとかして欲しいですね。(input要素は既にとられているので、operate要素でも作ってそこに統合するとか……)
<!--コミットしなくちゃダメデスカ……？-->
操作一般までページ製作者が各自に（勝手に）構築したら大混乱は必至。そーいうものは UA が、というかこのバヤイはブラウザ一般ですけど、がよしなが提供すべきだと思います。 W3C とかが「Web ぱげ UI ガイドライン」みたいなのを決めたって、どうせ大多数の人は従いやしないし好き勝手やられてゴチャゴチャになるだけかも。ちょうどデザイナー（えてして GUI 論はシロート）オリジナルの腐った UI が乱舞しまくってるフラッシュコンテンツのように。(中略)
現状はブラウザの実装がナニなので、たとえばパゲ間移動ナビリンクやフォームコントロールなどに accesskey を設定することが「良い＝アクセシブル」とされてますけど、パゲ作者によってキー割り当てがマチマチだから、実質使えない。
確かにページ製作者にUIをまかせることになれば混乱はんまぬがれえないのですが……そんなのではなく、accesskeyガイドラインやブラウザUIガイドラインは用意すべきだったのかもしれません。
もちろん長いものになると、読まれなくなったり、守られなくなったりするので、フォームとlink要素でいうところのtop、up、contents、previous、nextぐらいに限定したものを。そうすればページごとのaccesskeyがまちまちであることに悩まされることはなかったでしょうし、これは使ってはダメというショートカットキーが指定されているならば、accesskeyとショートカットキーが被って使えないということもなかったでしょうから。
ブラウザの実装にユーザーがなれてしまっていることを考えると、既に手遅れだとも思いますが……(日々の活動を通してデザインの言語が培われていき、その言語に従わないものは受け入れられない
)
<!--ありみかさんが言っていた「データ」「表示」「操作」に分割というのは、MVCアーキテクチャーと一般(ソフトウェア開発の領域)には言われます。HTML+CSS+ブラウザという体制を、広い意味ではMVCアーキテクチャーととらえることもできるとは思いますが、視覚ブラウザのみに傾倒している現状を考えると、ViewとControllerを一緒のものとして取り扱った変形であるDocment-Viewアーキテクチャーととらえた方が妥当だと思います。-->
昨日の日記の蛇足に書き間違えあり。あやうく、本当の蛇足になってしまうところでした。
データとそれ以外を分けるのが目的なので、
今号の「わたしの狼さん。」と「ぴたテン」の描写が絶妙。……私がそういうシーンを好きなだけかもしれないけど。
(私の知っている範囲では)サミーの頃からそうでしたが、黒田さんは"合わせ鏡"を描くのがうまい。
その頃どうしてたかを描くための一般的な方法を使っても良かったはずなのに、わざわざ"合わせ鏡"の多重構造を構築してしまう心意気に、思わず「ああっ」と声を漏らしそうになった。(別の視点から同じことに対する描写が行われるってことは、微妙に違う同じシチュエーション・セリフを味わえる、ってことでもあるし……)
さまざまな角度からの反射によって、そこに創り出された物語は、まるで
こころといいな、二人に大切なことがあり――それを守るためにしようとすることがあり――そうしようとするあまりに、忘れそうになっていた想いを、見失う前に、取り戻す。二人は忘れてはならない想いを忘れてしまうという罠を、乗り切ったのだ。
ココロ図書館において成長は課題ではない。だからその描写は劇的なものではなく、淡い。だけど、それでも彼女たちは一歩ずつ先に進んでいるのだ。外から見て分かるような変化ではないかもしれないけど、確実に、一歩ずつ。ときにはもとに戻ってしまうこともあるだろう。でも、確かに彼女達は歩んでいるのだ。――ある意味、ココロ図書館の根幹を示した作品だったのかもしれない。
レポート提出が近いようなので、一日ぐらいしか借りてないプログラミングPerlを返し、関係する本を借りようとしたものの、貸し出し中のだっため代わりに『ライト、ついていますか――問題発見の人間学(ISBN:4-320-02368-4)』と『ピープルウェア[初版](ISBN:4-8222-7082-3)』を借りてきてみる。(何の解決にもなっていない……)
概観ぐらいはつかみました。……確かにオブジェクトの部分がなりきれていない
という感じですね。オブジェクトというよりは構造化プログラミングっぽい気がします。
構造化プログラミングとオブジェクト指向の関係は微妙で、オブジェクト指向に構造化プログラミングの手法を組み合わせる分には何ら問題ないんですけど、逆に構造化プログラミングにオブジェクト指向を取り入れようとすると、オブジェクト指向は本領を発揮できなかったりします……。
そういうことを考えると、Perlのオブジェクト指向は諸刃の剣なんでしょうね……
「問題は何なのか？ どこにあるのか？ そもそも、問題ないと考えるのは正しいのか？」――視点を変えることの重要性を再確信させるどころか、さらに広げてくれる本。
……どこかで読んだような気が……結構、引用されてるのかな？
「TRPGのネタとして使える」、と思ってはいけませんか？
メテオたん
夢を、夢を見ていました。
夢の中の私は、気がつくと、ある少女の姿に扮した幼女たちに囲まれていました。
私はすぐに、彼女達が何に扮しているかに気づきました。
その姿が――おそらく私と同じ、"メテオさん"であることに。
……願望でもあるのでしょうか？
夢の中で本を手にとってはみたものの、読めずに目がさめる。
……どんな内容だったのか、すっごく気になります。
神、祈り、信仰……ってことでリンクにまとめてみようと思ったけど、挫折。 タイミング逃しましたし……
UML PRESS Vol.1。第一号らしく、いろんな技術をざっと紹介するといった感じ。
私みたいに、本があるなら本に当たろうという気持ちだったり、いくつかの技術については既に知っていて、なおかつ最新情報についての把握が必要でない人にはいらないかも……
「acornym要素よりもabbr要素を使った方がよい。kbd要素は使わないほうがよいかもしれない。既に、(XHTMLがXMLとして扱われるように)パラダイムが移行しているにもかかわらず、Webブラウザのみを意識しすぎていないだろうか？」……ってことですか。
課題は結構多いですね……