雑談。
オープンアプリで遊ぶ
とりあえず、ライフゲームを作ってみました。わーい。
ちなみにセルの配置を変える方法はソースを書き換えてリビルド！
これでだいたいフレームワーク的にどういうものか見通しがついた。以下のページが入門として参考になりました。Java も食わず嫌いでしたがそんなに悪くないですね。
2008-02-17
それで結局、IE 7 にはしたほうがいいの？ 雑談。
あまりにいろいろなことに手を出しすぎていてワケワカな感じになりつつあるので近況をまとめておこうかと。ここに書いたことのうちどれがどこまで伸びるかは自分にもわからない……。
その一、平安時代（というか上代−中古の日本文学）
相変わらず『枕草子』を読みつつ、疲れてきたら図書館で借りてきた物語文学についての本などをかじったりという日々。枕草子は今年中に読めるだろうか、という感じ。難しい箇所では、古語辞典片手に一時間で十行ほどしか進まないときもあったりする。このあと源氏に進みたいんだけど……。もともと文法的なところに興味があって読むようになったので、原文でないとだめなのです。難しいけど、昔の人は今と全然違う言語感覚で文章を書いていたのかというのがおもしろくてたまらない。助詞の使われ方とかですね。で、内容がわかると中身も面白かったりして二度おいしい。おもしろすぎて引きこもり気味だ。孤独に脳内で平安時代と熱く交流しています。みんな、「女同士の友情はあるか？」って言ってる人がいたら、「中宮定子と清少納言の間には友情と呼べるものがあった」って言ってやろうぜ。
まあ端から見れば、要はアンサイクロペディアの平安時代の項の状態なわけですが。そうか、そういう方面で需要があったのね。そうなると図書館で王朝文学関連の本を借りまくってるのは自分だけじゃないかもしれないぞ。「ソ連軍に徴用された物理学者」
は笑った。
しかし、平安から鎌倉時代にかけての物語文学の変遷は今のサブカルコンテンツのそれをみているようでもある。源氏がガンダムなら『狭衣物語』がエヴァンゲリオンか、みたいな。ああ、もうこういうこと言い出す時点でいろいろとアレだ。まあいいや。ひらたくいうと、後期の物語文学は古典の引用とお約束でいっぱいの自己完結的なものになっていくのです。だから場面と人物設定だけ見れば、「ああこれは○○ものね」みたいな感じで、あとはどっかで見たような描写が続く。当然似たような作品ばっかり量産される。そしてそういうのはもはや文学史的には破壊力がないので、竹取物語や源氏物語のように現代にまで伝わっているものはほとんどない。『堤中納言物語』くらいか。だけど堤中納言もほぼシチュエーション／キャラクター萌えだけのアンソロジーみたいなもんです。
その二、一太郎＋ATOK
ここ数年、マイクロソフトの技術情報のページがやたら使いにくい。Google から検索で飛んできても「お探しのページがありません」みたいなことになってたり。さらにある時期から機械翻訳の文書を載せるようになった。あれを堂々と載せて平気でいられるという感覚はまともでないと思うのですが。ほかの言語圏はどうなんですかね。機械翻訳がなかなか使えるというところもあるのかもしれない、でも……。さらに
のような話を読むと、MS は日本に注ぐリソースをセーブするようになったのだという印象が拭えない。これは日本市場を軽視するようになったからじゃなくて、「圧倒的に勝ちを収めてしまった」からだと思う。Office を浸透させるまでは、Word も MS-IME も、打倒一太郎・打倒 ATOK でどんどんよくなっていくが、ひとたび競争に勝ってしまうともはやさらに開発を進める理由もなくなる。IE がなかなか改善されないのと同様の、勝利者の緩慢さがオフィススイートや OS にも現れてきているようだ。前者のほうのリンクにあるゲイツがメイリオのバンドルに難色を示すくだりなんかは、なめられたもんだという感じ。日本語の本文をプロポーショナルフォントで読むことに慣らされてしまった我々も我々だけど。
Mac の EGWORD もなくなってしまったそうで、パソコンの日本語環境はまた寂しい時代になりつつあるのかもしれない。しかも今はかつてよりそのことで不満を訴える人の割合は減ってきている。しかし、PC に縦書き原稿用紙の背景を表示させてこれがいい、みたいなことを言っている冗談みたいな人たちは無視しておくとして、縦書きの文書も作れるようになっているべきだ、とは思う。
縦書きなんていらないという意見の人もいるけど、この手の意見は敗戦後の日本語ローマ字化論や、かな漢字変換がまだ重い処理だった頃に同様の主張を繰り広げていた人たちと似たようなものではないかという気がする。なんというか、抑圧の果ての逆ギレみたいな。しかしいまや処理リソースがないといういいわけはできないでしょう。やってないというだけの話。OS に十分な API が用意されてない？ 昔は漢字かな交じり文の入力だってハックでやってたんですよ！？
振り返ってみれば WZ の縦書きもいまや貴重にすら見えてくる。
そういうわけで、ある種の息苦しさを感じていたので、一度縦書き環境について調べてみようと、一太郎 2008 を買ってみました。まあ本格的に使うようにはならないと思うけど、知人の国語教師が「配布物作るのにこれしか選択肢がない」と言っていた真意を測りたいというのもあり。
OpenOffice.org も試しておきたいけど、あんまり期待できないだろうなあ。
さて、そういうのとは別に、じつは ATOK にも興味があったのです。というのは、最近の ATOK は、文語変換モードがあるのです。古典文学を読んでいると、メモ的なことを PC に書いておいたりしたくもなるのですが、引用や例文なんかが打ちにくくて「どうして単語登録に『四段活用』がないんだ！！」とかしょうもないフラストレーションをためてたもので。
そう考えると、IME も選択肢がすっかり減ってしまった。オープンソースのリファレンス実装みたいなのがあればいいんですけど。まああっても「四段活用を入れろ」とかは言えないか。
文語モードはなかなかナイス。「あなかま。」も「などかはさしもうちとけつる。」も「あやしうこそものぐるほしけれ。」も一発で変換できるぞ！ しかし「大進生昌が家」（だいじんなりまさがいへ）は変換できないな。固有名詞はさすがに現代語ほど充実はしてないようで。あと《係り結びの不一致》とか指摘してくれたりもしない（あたりまえだ）。
いつのまにか話が戻ってる。まあそれくらい平安時代ははまってるってことです。
その三、オープンアプリ
オープンアプリというのは、ありていにいうと au の Java 実行環境のことです。機種変更した INFOBAR 2 にせっかく付いているので、ちょっと調べてみたんです。でもローカルのリソースにはまったくアクセスできないし、データの保存に使える領域もちょっとしかないのね。これじゃ実質ゲーム専用環境だ。
なにか役に立つビューア的なものが（←どうせ古語辞典とかですが）作れるかと色めき立ったんだけど、残念。
その四、EPWING / システムソフト電子辞書
以前遊びでちょっとやってみた、EPWING 辞書を読む Python モジュールがあるのですが（不完全だけど）、もうちょっとがんばってみようかな。どうせ目的は古語辞典とかですが。
で、
なんとなく漠然とした不安もあり、FreeType 2 をビルドしてみたり。なんだそりゃ。
2008-02-11
一部の人には発表する前に見つかってしまいましたが、一年以上前にテストを始めて、しかも半年近く止まったままだった掲示板を復活、正式に公開することにしました（トップページからリンクを張った）。ここを読んでいる人は雑談の感想でも書いてやってください。まだいくつかいじるところがありますが、あとは動かしながら手を入れていくことにしました。おかしなところに気づいたらご指摘ください。
テスト中に覗いていた人はブラウザのキャッシュを一旦空にしたほうがいいかもしれません。一時期へんなヘッダを吐いていたので。
掲示板にはウェブ・フィード (RSS) が付きました。RSS アプリケーションについては疎いので、フィードに入れてあるデータの内容や形式についてもご意見いただければ。
一段落したらソースを公開する予定です。
CGI のテストをしていてキーッ！となったこと
その一、Firefox は RSS 1.0 の description 要素を、二重に解釈してマークアップしたコンテンツとして表示する。つまり、
<a href="http://example.com">サンプル</a>
上のようなテキストを（これはマークアップですらないことに注目）、
のように表示する。そもそもこれは規格を逸脱しているし、こういうことをやるために content:encoding があるんじゃないの？ 掲示板の投稿データはテキストなので、はじめは description にテキストとして配信しようとしていたのですが、この実装を見て仕方なく content:encoding に入れることに。content:encoding あんまり好きじゃないんですけど。Mozilla の中の人は仕様にうるさいものとばかり思ってたら、基本的なところでなぜこんなだらしない実装にしてあるんだろう。
その二、email.Utils モジュールの parsedate 関数はタイムゾーン指定を見ていない。
>>> from email.Utils import parsedate
>>> parsedate('Wed, 06 Feb 2008 01:30:15 GMT')
(2008, 2, 6, 1, 30, 15, 0, 1, -1)
>>> parsedate('Wed, 06 Feb 2008 10:30:15 +0900')
(2008, 2, 6, 10, 30, 15, 0, 1, -1)
このふたつはどちらも同じ時刻なんですが、タイムゾーンの指定を無視して時刻の数字しか見てない。そうならそうとドキュメントに書いておいてほしかった……。formatdate と可逆だとばかり思ってたので、更新時刻の処理がどうしても合わなくて数時間悩んだよ。
2008-02-08
雑談。
Python の文字コードサポートが整っているのは、Guido がヨーロッパ人だからなんだろうか。
以下うろおぼえにもとづく戯言。
ヨーロッパでは、ASCII の 128 文字に、アクセント記号付きアルファベットや各種記号などを加えた、8 ビット 256 文字の 1 バイト固定の文字コードを使っているのですが、困ったことに後半 128 文字の割り当てが規格によってばらばらで、しかもなまじ 1 バイト固定長のため、バイトの並び具合からの文字コードの推測が非現実的であるという問題があるそうで。ある意味これは Shift_JIS / ISO-2022-JP / EUC-JP の自動判別がそれなりの精度で効く日本語よりも深刻なわけです。だから、文字コードについてはアメリカ人がほんとにほんとにわかってないのだけ突出してるという状況なのかも。しかし影響力は大きいのでまたこれが。
で、ヨーロッパの事情からすると 8 ビット 256 マスのテーブルの「どこにどの文字が入っているか」という問題のとらえ方なので、「文字セット」という言い方がされるんじゃないかと思う。W3C の HTTP でも Content-Type: text/html; charset=iso-8859-1 ですよね。しかし日本語の文字コード事情からすると、文字集合（どの文字をどう並べた表を使うか）は JIS X 0208 なりなんなりで決まっていて、そのバイト表現（符号化方式）が違っているというのが問題になってくる。だから用語としては encoding のほうがしっくりくる（自分は）。encoding のほうが「文字の区点番号」と、その「区点番号のバイト表現」とを抽象化してるから、より一般的な概念じゃないかな。charset だとそこがまだ未分化な感じがする（文字の番号が即そのままバイト値）。
プログラムの変数名なんかは、encoding で統一してます。
Python では、
- encode
- 抽象的な概念としての「文字列」 → 具体的なバイト列表現
- 例:
u'いろは'.encode('shift_jis') - decode
- 抽象的な概念としての「文字列」 ← 具体的なバイト列表現
- 例:
'¥x82¥xa2¥x82¥xeb¥x82¥xcd'.decode('shift_jis')
というレイヤーがはっきりしてる（言うまでもないけど、矢印の左側が unicode オブジェクトで、右側が str オブジェクトということになる）ので、「文字コードを意識したプログラミング」がやりやすい。
しかしどうも世のなかには「文字コードを意識しないプログラミング」をしている時に問題がもっとも起きにくいのが文字コード処理に優れたプログラミング言語であると考える方々もいるようで。
……などとえらそうなことを書いてたら、掲示板をテストしていて気づいたことを書く時間がなくなってしまった。
2008-02-02
で、lazer eyes ってなんなの？
雑談。掲示板の復活が見えてきた。CGI の動作検証のために、再び ThinkPad に Apache を入れたけど、いまのおそろしく潤沢な処理リソース（デュアルコアに、2 GB のメモリ）では、仰々しいとか重いとかいう感覚はもはやまったくしないすね。
よく読んでいるウェブ日記の中の方々の少なからずが HP のサーバ（いまキャンペーンで馬鹿みたいに安い）を買っている。しかも二台とか。法人より個人で買ってるほうが多いんじゃないかという気が……。
おまけ
「さくらPython」に関連して、先日このようなやりとりがあったので一応ご紹介しておきます。