過去の日記

2006-12-08 [長年日記]

魂の座 [hatena]

死後の世界を信じてますか?
http://q.hatena.ne.jp/1165519804

生前、生後、死後と続く単一の存——魂と呼べる"もの"*1——が在るかどうか?(在ると思いますか?)という問いに置き換えるべきではないか?

Windows VistaのJIS2004対応 まとめ その1 (というか添削希望) [tech]

構成しなおして、

Windows VistaのJIS2004対応 まとめなおし

に再掲。


ここから下は削除予定!!


Windowsの次期バージョンWindows Vista(TM)において日本語フォント環境を一新
マイクロソフト,新文字セット「JIS2004」への移行措置を明らかに - ニュース:ITpro

JIS2004の(JIS第3水準,第4水準を含む)全ての文字はUnicodeでも定義済みである。
MSゴシックファミリー,MS明朝ファミリーと、追加になるメイリオフォントが対象。


この話については、Character Set(文字集合)と符号化(Encoding)の違いを意識する必要があるだろう。(上で書いた"Unicode"は、正確には曖昧さを避けるなら"Unicodeで定められたCharacter Set"と書くべきもの)

404 Blog Not Found:Unicodeは文字集合か符号化方式か
404 Blog Not Found:備忘録: Unicode, UCS, and UTF
Character Set vs. Encoding

あたりか。


で、認識する必要があるのは以下の3点か。


(1)字体字形*2が変更になる文字がある
code point はそのままだが、字形(グリフ)が変わる文字がある。
詳細は以下のpdf。

http://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf

「JISでは字形は規定していない」ので、「パソコンなどに搭載される字形の変更を求めるものではない」が、Vista で搭載されるフォントでは字形が変更される。


(2)文字が追加される case1
UTF-8で3バイト、UTF-16で2バイトに符号化される範囲*3の未定義だったcode pointに、新たに文字が定義された。


(3)文字が追加される case2
UTF-8で4バイト、UTF-16で4バイトに符号化される範囲*4のcode pointに、新たに文字が定義された。


(1)についてはエンドユーザへの周知が必要である、という点を除けば大きな問題ではないだろう。
Vista と XPとで、同じデータを同じアプリケーションで見ているのに字が違うとなるわけだ。
そんなケースでは因果が判りやすいのだが、クライアント(例えばブラウザ上で走っているWebアプリケーション)からの要求を受けて、サーバ側の方でプリンタから出力になるケースでは混乱するかも。Webサーバとか、プリンタサーバとかネットワーク機能搭載の複合機とかが間に入ると、エンドユーザには判りにくくなるのではないか。「画面と紙とで字が違う! なんで!?」となるだろう。


(2)についてはアプリケーションで気をつけることは多くない。
文字種チェックのロジックがすでに入っている場合は、それが正しく機能するかを確認する必要はある。他のシステムとの連携があってそちら側がShift-JISしか受け付けませんよ、という様なケースでは当然どこかにデータの範囲をチェックするロジックがあるはず。入力時に入れさせないのか、出力時に下駄(〓)にするのかという選択肢はあるだろうが、いずれにせよチェックするロジックはあるはず。
Javaでコード変換の時に'?'になるからそれに任せてしまえ、みたいな対応をしているところもあるだろうけど……。


(3)について。
極端なケースを挙げると、漢字1文字を格納する領域(DB上の項目とかメモリ領域とか)として、UTF-8での符号化を前提に3バイトしか確保していない、なんて対応をしていると問題がある(というか、今までも問題はあったのだけど表面化していないというだけである)。
UTF-16での符号化を前提に1文字あたり2バイトしか確保していない、などはいかにもありそうである。10文字の入力に対して20バイトを確保しておいてそれでOKとしているようでは危ない。
追記
まさかとは思うけど、UTF-16が"1文字を2バイトに"符号化する方法だといまだに思っている人はいない……よな?


Javaのchar型がどういう扱いになるのかとか調べないといけないなぁ。
追記
Javaについての資料へのリンクは

JIS2004で追加になった文字をJavaで扱う

で書いた。


あとHTMLの実体参照とかも、調べなおしたい。HTML自体はEUC-JPで書かれたものであっても実体参照として 𪚲 と書くと……、𪚲 となってフォント次第では表示可能なのだ。これはdankogaiさんのエントリを読み直していて気がついた。
追記 (2006/12/12)
曖昧だったのでちゃんと書きます。
𪚲 は月に亀の漢字。WinXPにメイリオフォントをインストールしていることが前提。Firefoxだと実体参照が解決されその漢字が表示される。ブラウザのフォントをメイリオに指定していなくても——つまりMSゴシックなどを指定していたとしても、その漢字の部分だけメイリオで表示される(フォント内のメタデータ(?)の Unicode Range を参照して、表示可能なフォントを探し出しているのか?)。IE6ではたとえメイリオを指定しても駄目。IE7で、ブラウザのフォントにメイリオを指定すると、実体参照が解釈されてその漢字が表示される(追記:UTF-8で4バイトになる文字が表示されない様。別のマシンでは表示できていたような気がするのだけど……)。IEについてまとめる。メイリオなどの、追加文字を表示可能なフォントをIEの表示に設定しない限り、追加文字は表示されない。html自身の符号化がUTF-8,UTF-16の場合、IE6およびIE7で、UTF-8で3バイトに符号化される文字は表示可能。html自身の符号化がshift_jis,EUC-JPの場合、IE7では実体参照が解決されて正しい文字を——UTF-8で4バイトに符号化される文字も含めて——表示可能だが、IE6では全く表示できない。
ブラウザのフォントにMSゴシックを指定すると'・'(中黒っぽい記号)で表示される。そう表示されるがちゃんと'その文字'なのでコピー&ペーストするとUnicode形式でクリップボードに取り込まれる。
ちなみに、メイリオフォントをインストールしていないマシンではFirefoxで'?'(クエスチョンマーク)で表示される。
追記 (2006/12/13)
"JIS2004に対応した"とここで言っているところのフォントは、あとあと Windows XP に対しても配布されるらしい。
追記 (2006/12/18)
JIS2004の文字を入力するテストがしたいなら、上記の様なhtmlファイルを作って、コピー&ペーストするとよいだろう。


追記
HTMLの実体参照によって表示されないフォントでも入力することができるわけで、今までずっと存在していた問題が「Vistaが出たらユーザでも解っちゃうよ。ヤバイ!」という事になりそうだ、と、つまりはそういう話なのだなぁ。


まとめ その1 とかエントリタイトルに書いたけどその2があるかは不明……。
そのようなまとめならもうあるよ、という話になると思うけど、これは「自分が判っていること」とか「自分がどう認識しているか?」を明にするために書いたものなので(私にとっては)無駄なことではないのだ。


追記

電脳社会の日本語 (文春新書)

  • 作者: 加藤 弘一
  • 出版社/メーカー: 文藝春秋
  • 発売: 2000-03
  • ASIN: 416660094X
  • メディア: 新書
  • amazon.co.jp詳細へ

は注文した……が、いつ来るのやら。


追記 2006/12/14
JIS X 0213(JIS2004のことね)に記述がある符号化——ISO/IEC 2022, EUC-JIS-2004, ISO-2022-JP-2004, Shift_JIS-2004——のことを無視して、Unicode(での符号化)のことしか話をしてないけど現実不都合ないよな?
Vista のメモ帳(notepad)で保存するときにそれらの符号化が選べるようだと問題ありか……。
詳しくは見ていないが、EUCの場合はUTF-8/UF-16で4バイトに符号化される文字でも今までと同様の考え方で符号化できる……らしい。
そうそう。
UTF-8/UF-16で4バイトに符号化される文字を扱うには、実はメモ帳がよい。Unicode対応したとされている秀丸やEmEditorでも、その様な文字を使うと正しく符号化されないように見えた(間違っていたらツッコミ希望)。


追記 2006/12/19
秀丸は Surrogate Pair で表現される文字への対応が今βテスト中みたい。


2006/12/8 14:55 修正
"符号"と書いていた箇所を"code point"に変更。


2006/12/13 18:50 修正
"エンコード"や"encoding"と表記が揺れていた箇所を"符号化"に変更。

煮玉子 [hatena]

ラーメン店で出てくるような煮玉子を自宅でも作ろうと思うのですが、上手にできるレシピがあれば教えて下さい。
http://q.hatena.ne.jp/1165541343

半熟じゃなくて「味付煮玉子」でいいのなら、肉じゃがを作っている時に剥いたゆで卵を一緒に煮るとか、残り汁を使うなんてのでも意外に美味しい。

ちょっとメモ [気になる本]

神は沈黙せず(上) (角川文庫)

  • 作者: 山本 弘
  • 出版社/メーカー: KADOKAWA
  • 発売: 2006-11-23
  • ASIN: 4044601135
  • メディア: 文庫
  • amazon.co.jp詳細へ

神は沈黙せず(下) (角川文庫)

  • 作者: 山本 弘
  • 出版社/メーカー: KADOKAWA
  • 発売: 2006-11-23
  • ASIN: 4044601143
  • メディア: 文庫
  • amazon.co.jp詳細へ

バタフライ 5 (バーズコミックススペシャル)

  • 作者: 相川 有
  • 出版社/メーカー: 幻冬舎コミックス
  • 発売: 2006-11-24
  • ASIN: 4344808622
  • メディア: コミック
  • amazon.co.jp詳細へ

電脳社会の日本語 (文春新書)

  • 作者: 加藤 弘一
  • 出版社/メーカー: 文藝春秋
  • 発売: 2000-03
  • ASIN: 416660094X
  • メディア: 新書
  • amazon.co.jp詳細へ

観用少女【完全版】 明珠 (コミック愛蔵版)

  • 作者: 川原 由美子
  • 出版社/メーカー: 朝日ソノラマ
  • 発売: 2006-12-15
  • ASIN: 4257905700
  • メディア: コミック
  • amazon.co.jp詳細へ

エンジニアのための時間管理術 (後編) [tech][book]

エンジニアのための時間管理術 (前編)
エンジニアのための時間管理術 (中編)

の続き。では電子メールの管理の章から。


p152

保存した電子メールは、[Save]と[Receipts]の2つのフォルダのどちらかに送られます。筆者は、金融取引に関するメッセージを[Receipts]フォルダに保存し、それ以外を[Save]フォルダに保存しています。以前は、用件ごとにフォルダを用意していたので、小さなフォルダが無数にありました。そして、これらのフォルダをスクロールするのは時間の無駄使いであることに気づきました。必要な物は[Save]と[Receipts]のどちらかにあります。

すごいなぁ。でもその通りだ。
もう少し、同じ節から拾ってみよう。
p150

メッセージを読み始めたら、必ず最後まで読み、ここに列挙したいずれかの方法で処理するのです。

とあって列挙されている方法はというと……、

  • 削除
  • 保管
  • 返信して削除
  • 委任または転送して削除
  • すぐに実行して削除

である。いさぎよいなぁ。さっきのp152からの引用は「保管」の項目からのものだった。
この前の項が「フィルタ」という項目でメーリングリストからのものは受信した時にフィルタしてしまう、とあるのでそれ以外のメッセージに対する処理がこれらのいずれかの方法だと言うのだ。
「削除」は単純だ。自分に関わりが無いと判断できるメール。とくにbccで来たものはたいていこれだという。
「保管」については前述した。これは「読んだ」ことに価値があるものではなくて、「保管しておく」ことに意味があるメッセージは保管せよ、と言っているのだ。
違和感を覚えたとしても続けて見ていく。
「返信して削除」は読んで字のごとく……ではない。リクエストトラッカーやオーガナイザに内容を転記して、「メッセージを受け取りました。いついつまでに返事をします」と返信して、削除、なのである。
「委任または転送して削除」これは読んで字のごとく。要求元にもccを送信して、誰に委任したかが判るようにする、という。ただ、これは筆者が相手にしているのが主に社内の人間だからだと思う。会社のIT部門の人が、社内の人間を相手にする時はこれでいいのだろう。そうではなくて社外への場合は、1つ前の「返信して削除」の様に、「リクエストトラッカーに追加しました。以降はチケット番号xxxxにて△△までお問い合わせ下さい」という中身に実質なるのではないかと思う。
「すぐに実行して削除」も読んで字のごとく。
簡単に言うと、ここで筆者が主張しているのは、

  • メーラをTodoリストのように、タスク管理に使うな。タスク管理に使っているツールがあるならそこに入れてメールを削除しろ
  • メールは削除してフォルダの中身は一定以下に保て。ただしゴミ箱に移動することも削除にあたることに注意

の2点だと言っていいだろう。
——そうは言っても来たメールが後から大事になることだってあるだろう
「前にこう言いましたよね」と言える様に?
確かにそれはそうだ、だけど保管場所は自分が使っているそのメーラである必要はない。保管していることが重要なら保管すればいい。だが日常の道具としてのメーラにメールを溜めるな。
と言いたいのだろうと感じた。
GTD流に言うと、メーラは In-basket であって、Next actions を管理するものじゃない、ってところだろうか。


p164

会議の種類はさまざまですが、それらを進捗会議と作業会議の2つに大別してみることにします。

必ず前もってそのどちらであるかを告知している、と筆者は言っている。進捗会議で問題の解決を試みると全員の時間を無駄にするだろう。その場合は進捗会議を普通に終了した直後に、関係者のみを残して作業会議を始めるとよい、とも。
特に意識しなくても、その様な進行をするケースは多いように思う。ここでは、その区別を意識し、進捗会議が作業会議の様相を呈してきたらちゃんと本来の道筋に戻れるように舵取りをしよう。ということだろう。区別を意識するのは大切。


時間の浪費の章に「ハードウェアとソフトウェアのインストール」という項が出てくる。エンジニアであれば、なにもそんなものを頼む必要はなく、自分でやりたがるところだ(少なくとも私はそう)。
p169

すべての設定を終えるまでに、不十分なマニュアルとやっかいなハードウェアの問題との格闘に数日、あるいは数週間かかる可能性があります。このシステムのインストールが完了したあと、別のシステムをインストールすることはないので、この知識が利用されることはありません。自分たちで行ったら1週間もかかるような作業を、それを何度となく実行しているVARや再販業者は1日か2日で済ませてしまいます。それが彼らのウリなのです。これらの業者は落とし穴とそれらを回避する方法を知っているはずです。

p170

このアドバイスを実践する際には、担当者に付きまとい、作業をしながら何を行っているのか説明してもらうことを忘れないでください。

とのこと。
コメントはない。私は仕事上、両方の立場になることがあるので……。


p194

Perlによるシステム管理

  • 作者: デイビッド・N. ブランク‐エデルマン
  • 出版社/メーカー: オライリー・ジャパン
  • 発売: 2002-07
  • ASIN: 4873110920
  • メディア: 単行本
  • amazon.co.jp詳細へ

を奨めている。


最後の方は細かいメモをいっぱいとっているけど、ここに書いておくべきだと思うことは多くないなぁ。
おしまい!


書籍たち

エンジニアのための時間管理術

  • 作者: Thomas A. Limoncelli
  • 出版社/メーカー: オライリー・ジャパン
  • 発売: 2006-10-19
  • ASIN: 4873113075
  • メディア: 単行本(ソフトカバー)
  • amazon.co.jp詳細へ

仕事を成し遂げる技術―ストレスなく生産性を発揮する方法

  • 作者: デビッド・アレン
  • 出版社/メーカー: はまの出版
  • 発売: 2001-09
  • ASIN: 4893613332
  • メディア: 単行本
  • amazon.co.jp詳細へ

Life Hacks PRESS ~デジタル世代の「カイゼン」術~

  • 作者: 田口 元,安藤 幸央,平林 純,角 征典,和田 卓人,金子 順,角谷 信太郎
  • 出版社/メーカー: 技術評論社
  • 発売: 2006-03-23
  • ASIN: 4774127280
  • メディア: 大型本
  • amazon.co.jp詳細へ

*1 宗教に依って呼称は異なるかも。

*2 "字体"は"ゴシック体"とか"明朝体"の様に使う用語だと気がついたので修正。

*3 これらの範囲がイコールなのかどうか? は後で確認しないと……。(追記)イコールなわけがない。というツッコミはおいといて、UTF-8で3バイトに符号化されるcode pointの範囲はUTF-16では2バイトになることを確認した。

*4 (追記)UTF-8で4バイトに符号化されるcode pointの範囲はUTF-16では4バイト必要だし、逆もまた然り。