記事中で、ソースコードを引用しやすくした。具体的には、{大なり、小なり、ダブルクウォート、バックスラッシュ}について、”<”などというふうに置き換えるようにした。

方法としては、置き換えたい部分を選択して「記号」ボタンを押すと、選択文字列を調べて置き換えるというやり方にした。

しかしここで問題が…。そもそも記事中にタグを使用できるようになっているためか、一度投稿した記事を読み込んで修正するときに、上述の置き換えが逆変換(元に戻される)されてしまうようだ。どこでそれをしているのか追いきれない。(というかそろそろ空が白んできている。かなり眠いのだ…。)

まぁ、読み込み時に元に戻ってくれた方が、”<”とか書かれているよりソースを読みやすいのは確かだし、ソースの一部の色を変えたりタグを挿入したりすることもありえるだろうし、そうすると自動対応させるのはちょっと無理っぽい。手動の今の仕様でいいか。


正解がみあたらないことが多すぎる。一例をあげてみよう。解いてみて欲しい。(教員試験の例。)

---
(問い)コンピュータについて述べた次の文のうち,正しいものの組み合わせを選べ。

(1)操作の対象が絵(アイコン)で表現されるユーザーインターフェイス,またはそれを実現するソフトウェア製品をGUIという。
(2)デジタル信号で情報を区別,分類する機能をデジタル・デバイドという。
(3)ハードディスクの中で,ファイルがバラバラになって書き込まれているのを整理して,できる限り連続したユニットに移動して,ファイルを速く開くことができるようにするツールをスキャンディスクという。
(4)データの読み出しだけが可能なメモリはRAM,読み出しも書き込みも可能なメモリはROMである。
(5)Webページを閲覧するためのアプリケーションをブラウザという。代表的なものにInternet ExplorerやNetscape Navigatorがある。

[1]-(1),(3) [2]-(2),(6) [3]-(4),(5) [4]-(2),(3) [5]-(1),(5)

(正解)[5]
---
どうだろうか。正解の組み合わせに入っている(1)が、ムチャクチャである。GUIの定義?この定義だとGUIとは、ソフトウェア製品のことらしい。頭痛がする。

GUI(Graphical User Interface)とは、グラフィック表示機能を用いたユーザーインターフェイスのことである。アイコンなどあろうがなかろうが関係ない。よく比較されるCUI(Character User Interface)は、グラフィック表示機能を用いずキャラクター表示機能のみで構成されたユーザーインターフェイスのことであり、それとの対義語になっているのだ。ましてや「操作対象をアイコンで表示する機能を実現しているソフトウェア製品」を「GUI」などと呼ぶことはない。

とりあえず「操作対象をアイコンで表示する」などという特定の表現方法のことを言うのではない、ということだけでもわかってから出題してくれないと、受験生は正解をマークできない。これの出題者は、IBM様のサポートページでもどうぞ。このぐらい噛みくだいてあれば理解できるのでは…。

数学なんていう厳密な領域の出題に、こんなのがボロボロ出題されている。どれもコンピュータの用語問題だ。問題として成立しえない問題しか出せないのなら、もう出すのをやめて欲しいと思うのだ。仮にも国家試験の合否を決める問題なわけだし…。


文字列を1文字ずつみて ACSIIコードを16進表示するスクリプトを PHP で書いた。

side bar に「WEPキー作成補助」として追加した。

単純なものだが WEP キーを無線ルータに設定するとき重宝しそうだ。客先で時間がおしてくると、文字列→16進を紙で照合するのも大変だし間違いが生じそうだからだ。

核の部分はこれだけ。

for ($i = 0; $i < strlen($str); $i++) {
print strtolower(bin2hex($str[$i]));//または strtoupper(...)。
}

それにしても、製作の過程で検算のために ASCII コード表など拝見したが、なつかしい。自分がマイコンに触れた頃は、グラフィック画面などなく、文字コードといえばコレのJIS拡張版(半角カナ等付き)もう少し正確にいうとメーカー独自のセミグラフィックコード(≒絵文字)の入ったコード表が唯一全てだった。今はややこしい…。


以前、既存のカテゴリー分けに左右されず、「重要な記事の一覧」のようなカテゴリーが実現できないか考えたことがあった。

あのときは rNote の投稿記事ファイルの取り扱いに、シンボリックリンクのような機構を追加することで、新規に追加した「重要な記事の一覧」カテゴリーから既存カテゴリーの記事を参照するような構造で実現しようと考えた。

その後考え方がより一般化されて、記事本体に、その記事の属性を表す文字列の集合を保持するタグを追加しておき、その属性とカテゴリーの対応表を作ってやり、本体はその対応に応じてカテゴリーごとの記事への閲覧機能を提供するようにすればよいのではないかと考えた。

例えば:
・ある投稿記事の属性キータグの内容:漫画,美少女,パンヤ,ゲーム
・blogのもつカテゴリー:漫画、ゲーム、健康、アウトドア
・カテゴリーごとの、閲覧対象となる属性:漫画=漫画、ゲーム=ゲーム,パンヤ、健康=健康,健康法,体操,薬、アウトドア=アウトドア
だった場合は、その blog の漫画カテゴリーおよびゲームカテゴリにて、その記事が閲覧可能となる…という寸法だ。

そこまで考えて、そこで放置した。というのも、それはまさに DB の導入がうってつけの事例だと気づいたからだ。記事ごとの属性文字列を DB で管理し SQL で検索する形になろう。rNote は DB を使っていないので、これの実現は保留した。(しかし最近、 DB 無しでも静的にキャッシュ生成するときに同等の処理をしてやれば実現できるんだろうなと思いつつ…。実現するといいなぁ。)

前置きが長くなったが今回は、 blog 自体の記事属性ごとのカテゴライズの話ではなく、外部に記事の情報を伝えるためのカテゴライズに、同じ考えが応用できると気づいたという話だ。

ちょうどタイミングよく、亜細亜ノ蛾さんの「ブログの記事にタグを付ける利点と方法」を発見した。どうやら、同じようなことはみな考えるらしい。

同記事を参考に、TechnoratiTechnorati: Tags に対応するように実装内容を考えてみた。

・記事にタグ <Keys></Keys> を追加する。
・同タグの内容は、タグの埋め込まれた記事のもつ属性を表す文字列の集合とする。区切り文字は半角のカンマ ( ',' ) とする。
・rNote 本体は、投稿記事の表示にあたって、同タグに列挙された属性の数だけ、 Technorati: Tags 形式のタグに順番に置き換える。

本体に手を入れないようにスキンでとりあえず実装したみた。(抜粋)

<div class="text">
<%=$Text%>
</div>
<%=$WriteBack%>
<if def_tag="Keys">
<div class="keys">
この記事の属性キー
<?php
$string = '<%=$Keys%>';
$tkn = strtok($string,",");
while($tkn) {
print "[ <a href=\"http://technorati.com/tags/".$tkn."\" rel=\"tag\">".$tkn."</a> ]";
$tkn = strtok(",");
}
?>
</div>
</if>
</div>
しかしこのままでは、属性が複数の場合に対応できない。スキンの中に php を書いて実現できそうだが方法がまだわからないのでいったん保留。やり方は他にもあるかも知れない。rinn@rNote 掲示板で php 内の変数に記事のタグの値を受け渡すやり方を教えていただけたので、上のスキンの記述を修正してあります。これで複数キー列挙に対応できました。(感謝~)

自分がどのようなカテゴリーの情報を発信しているかを相手に適切に伝えるというのは確かに有効な手段だと思う。ただ、その仕組みは標準化されていないようだから Technorati の実装だけでなく色々出てくるものに対応できるように…と考えると、やはり上で考えたように「属性キー」という上位のレベルで情報を保持しておき、下位の個々の実装に対する仕組みは適宜追加・置換して組み込んでやれる体勢にしておくのが良さげな気がした。

[コメントの受付は終了しています ]
1: sabakan (06/25 22:32)
どうも、はじめまして。
鯖Memoの運営をしているsabakanです。
コメント有難う御座いました。
御言葉に甘えて冬星さんのアイディアを流用させて戴きました :-)
2: 冬星 (06/27 05:30)
こちらこそありがたく。逆に参考にさせて頂く事も。
1エントリーが複数属性を主張するのは私的には大いに有りだと思いますが、Technoratiで1エントリーが複数のタグをもつことを考慮しているかイマイチわからずです。複数タグを埋めた記事の更新ping打ったら1個目のタグだけエントリーされるのかも知れませんが…。
この記事のリンク元 | 6 | 3 | 3 | 2 | 1 |

【疑問点】
光の混色、色の混色はなぜ混色された色が異なるのか。異ならないはずではないか。

【論旨】
・光の三原色の説明では、赤・緑・青を三原色として、赤+緑=黄、緑+青=シアン、青+赤=紫、赤+緑+青=白、となっている。(加法混色)
・色の三原色の説明では、赤紫・黄・青を三原色として、赤紫+黄=赤、黄+青=緑、青+赤紫=紫、赤紫+黄+青=黒、となっている。(減法混色)

そもそも組み合わされている原色の色合いが等しくないのでややこしいが、要するに、光の混色では、原色を混ぜ合わせていくと色が白に近づいていく(明度が増す)が、色の混色では逆に黒に近づく。(明度が減る)

しかしどうもおかしいと感じる。

「ある色が目に見える」とは、一体どういうことなのか。

色が見えるためには、光が網膜に届かないとならない。届いた光の波長に応じた色を脳が感じるのだ。青いライトの光を見て「青い」と感じるのも、青い色で塗られた絵をみて「青い」と感じるのも、青の波長の光が網膜に届いたという点では等しい。

(A)今、同じ照度の赤色光、緑色光、青色光を光源からスクリーンの同一地点に照射し、スクリーン上に白色光を観測したとする。この場合観察者が白色光を観測するまでの流れはこうなる。

1.赤色光源から赤色光、緑色光源から緑色光、青色光源から青色光の、それぞれの波長をもつ光子がスクリーンに向けて飛び出す。
2.各波長の光子が多数、スクリーンに衝突し、反射する。
3.反射した各波長の光子が、ほぼ同時に観測者の網膜に到達する。
4.網膜上が受けた各波長の光子の合成結果として、「白っぽい色」と脳が認識する。

(B)次に、同じ分量ずつ赤色、緑色、青色の絵の具を混ぜて紙に塗り、十分な環境光のもとで観測したとき、観察者が紙の上にみえる色を観測するまでの流れはこうなる。

1.紙の上に存在する、赤色、緑色、青色の絵の具の粒子に環境光が到達する。
2.赤色粒子から赤色光、緑色粒子から緑色光、青色粒子から青色光の波長をもつ光が反射する。
3.反射した各波長の光子が、ほぼ同時に観測者の網膜に到達する。
4.網膜上が受けた各波長の光子の合成結果として、「黒っぽい色」と脳が認識する。

この場合絵の具の粒子が紙の上に並んでいるさまを表現したが、わかりにくければ、同じ明度かつ同じ直径で、紙の上に非常に細かく隙間無く点描された…と考えてもよろしかろう。

さて、いずれにしても(A)、(B)を比較してどうだろうか。同じ波長の光子が、同じ割合ずつ、観測者の網膜に到達してはいないだろうか。

ではなぜ、にも関わらず、光の場合は白っぽい色に見え、絵の具の場合は黒っぽい色にみえるのか。他の色同士の組み合わせの場合も、なぜ、光の混色と色の混色では結果が異なるのか。

まったくもって不可解だ。幼いころからずっと疑問に思い続けている。本件納得のいく解が見出せずにいる。

[コメントの受付は終了しています ]
1: りん (06/21 21:49)
2.赤色粒子から赤色光、緑色粒子から緑色光、青色粒子から青色光の波長をもつ光が反射する。

これが間違い。赤インクは「赤い色を出す」のではなく「赤以外の色を吸収」します。
同じ事を言ってるようですが、実は全然違う事に注意。
絵の具をいっぱい混ぜると、あらゆる色が吸収されて、結果として黒になっちゃいます。
(点描された場合も常に減法であると言う意味において一緒)
2: りん (06/22 16:17)
すまん、ちょっと修正。
点描の場合は、モニターも紙も同じになりますね。例えば赤と黄色のタイリングは肌色になる。
昔の、8色や16色時代のタイルペイントで描かれた絵をプリントアウトしても、色は変わったりしないし。

「加法」とか「減法」というのは、あくまで「光を重ねた時」「絵の具を混ぜた時」の事。
3: 冬星 (06/23 08:25)
解説ありがとうございます。むむぅ、色の方は吸収なのですか。
で、すみません…わかりそうで、わかりませんでした。orz
点描(赤と黄色のタイリングの例など)だとなぜOKなんでしょう。もし点描がOKなら、混色した赤と黄色の絵の具も、顕微鏡で拡大してみたら赤絵の具の粒子と黄絵の具の粒子が隙間なく(まだらに)敷き詰められた点描状態です。サイズの違いはありますが本質的に同じなわけで…。
4: りん (06/23 19:30)
粒子一個分の厚みで均一に塗られたら点描と同じになるだろうけど、実際は絵の具は縦方向にも重なるので。
5: 冬星 (06/23 21:44)
なるほど…厚みですか。重なり合って薄い層で混ざりあう色粒子に吸収されると…。
目から鱗です!積年の謎がスッキリしました。やっとコレ明快に答えてくれた方に出会えたました。うぉぉ嬉しいっっっ、ありがとうございます。(涙