Masaaki Shibata blog
あけましておめでとうございます。今年もよろしくお願い申しあげます。
「さくらのレンタルサーバで Python 外部モジュールを使う」を少し改訂しました。FreeBSD のバージョンが 6.0 になって #! の引数解釈と env の挙動に調整が入ったせいで通用しない記述になっていたところを削除。どんどん内容なくなってくけど（苦笑）。ゲストブックから指摘いただきました。ありがとうございます。
まあ削っていいところを言い出したら、そもそもモジュールのホームへのインストール方法と sys.path へのパスの手動追加以外はまるっと落としたっていいわけですが。でも、どういう思考経過を経てそういう解法に落ちついているのかというのは知ってたほうがいいとは思うし、残しておこうかな。
もう年の瀬ですね。
「Python のインクリメンタル・デコーダ」 という覚え書きを追加しました。これを知る最近まで余ったバイトは自力で管理してた。俺の時間を返せと思ったので後世のためにまとめたもの。
ひみつメモ帳 0.8.7 を公開。といっても新しいライブラリでコンパイルしただけです……。
もっと頻繁に（いろいろ）更新したいんだ、ほんとは。
いまは、なにかやろうと思えばネットでいろいろライブラリとか探して、ドキュメントも読んで、動かすとこまではできる能力は自分にはついているらしいことはどうもわかってきたけど、それだけじゃだめだね。もっと速くできるようにしたい。フットワーク軽くしたいっす。
英語の名刺（など）で日本人の氏名をどう表記するかという話。
英語で日本人の氏名を記述するとき、Masaaki Shibata のように、名・姓の順で書くのがいまの習慣になっている。これはいつからはじまったのだろう。どうして姓名の順を入れ替えて書くかというと、その源泉は英米の氏名がその順で呼び習わされているので、それに合わせようという発想だろう。
いっぽうで、われわれが呼んでいる順にそのまま Shibata Masaaki とすべきだという意見もある。わざわざ英米の慣習にあわせてひっくり返すのはおかしなことだという、これも一理ある。日本語で英米人の名前をわざわざひっくり返したりはしないんだから。
最近名刺では、Masaaki SHIBATA という表記を見かける。いっぽうで姓・名表記をする人のなかには SHIBATA Masaaki という表記をする人もいる。どちらも、姓名の表記順が議論となり混沌としてきた現実を受けて、こっちが姓ですよ、あるいはこっちが名ですよという識別ができるようにという配慮で、姓のほうに大文字を使っているものと思う。
しかし、大文字で書かれているほうが姓であるという約束ごとは、英語圏で暗黙に通用するのだろうか。姓のほうを大文字にするという発想じたいが、姓・名の順で名乗る日本人的な感覚に頼ったものではないのかな。それに、姓にしろ名にしろ、ぜんぶ大文字の字面というのは叫んでいるようであまり美しくない。
姓名の順が日本と同じ中国や韓国では、日本のようにわざわざ順序を入れ替えたりはしていないので話は楽だ。先日、日本の大学に勤める韓国の方の名刺を目にする機会があったのだが、その英語表記は、「Bae, Yong Joon」のようになっていた。これはうまいやり方だと思った。英語圏でも書面などで姓・名順の表記をすることはあるが、そういうときは、Smith, John のようにカンマで区切る。その表記を使ったわけだ。英語圏の人からすると、これで最初の部分が姓であることが連想され、また名刺にわざわざその表記で名前を刷ることで、呼び名としてはこの順で読むのだな、ということまで伝わるんじゃないだろうか。大文字にするよりは、いいアイデアに思える。もっともこれは名刺のうえでだけの話で、ふつうの文章でこの調子ではやってほしくない。
そもそも、どっちが姓でどっちが名かというのは、そんなにはっきりさせる必要のある要素なのだろうか。家族名か個人名かなんてのはその社会での習慣の問題で、名前の表記に内在させる必然性はないでしょ。ほとんどの場合、名前というのはその人がどう呼ばれているか、という事実を伝達するだけでじゅうぶんなはずだ。あとは名刺を渡すときにでもついでに話して会話のきっかけにすればいいくらいで。どうしても名刺にその情報が必要だという人は、矢印ひいて「こっちがファミリーネームです」と注でもつければそのほうがわかりやすくていい。
個人的には、いずれ混乱が収束するのであれば、自分がどのように呼ばれているかというのを素直に書いて、Shibata Masaaki と書けばそれでよいというのが自然でいいと思う。
最近いつになく C を書いている。WZ マクロ以来かもしれないくらい。いつか Python に帰ってくるぞ、と。
で、C は、コードの中味以外で気を遣うことが多すぎる、と思った。ライブラリ使うにも、コンパイルに一苦労したり、コンパイル通ってもリンクでこけたり。リンクできても実行時にこけたり。英語のドキュメントを必死で調べたり検索しまくったりしないといけない。
それに、そうしてようやく手に入れたバイナリのライブラリを自分のプロジェクトにどうやって配置したものか迷う。オトナはみんな通ってきた道なんでしょうけど……。
たとえば CUnit 使うとして、バイナリは（あとヘッダファイルは）リポジトリに格納すべき？ もちろん自分のコードじゃないから、格納しても基本的に編集するわけじゃない。しかし数年後に同じライブラリが同様に手に入るかというと絶対の保証はないわけで。リポジトリにそういう外部のライブラリも格納しておけば、チェックアウトするだけで、依存しているライブラリを求めてサイト回ってコンパイルする苦労を何度もしなくても、即ビルドできる。
ところがそういうバイナリは、それだけぽんとリポジトリに入っていてもそのうち素性がわからなくなる（はず）。じゃあ元のソースコードもリポジトリに入れときますか、ということになるとさらにプロジェクトの容量が肥大化する。CUnit くらいならそんなに大きくないからいいけど、wxWidgets くらいまで行ったらどうすんの？ それにそういう外部のライブラリ使うプロジェクトが複数あったら？ （実際あるけど。）各プロジェクトにそれぞれリンクするバイナリを入れとくの？
で、思いついて svn:externals とか駆使してみたりしたんだけど、これを入れると svn up が遅くなる！ 外部リンクひとつごとに、たとえ同じリポジトリからでも別個にセッション張るそうで、やたら時間がかかって調子が狂う。ちゃんと動いていることは動いているんだけど、作業効率のこと考えると svn:externals はあんまりよくないね……。
このへんのノウハウは『Subversion 実践入門』という本を参考にしてるのだけど、実際にどこまで踏み込むかはプロジェクトごとにそれぞれなんだろうな。というわけでまだ模索中。
昔はそれぞれのコンピュータに CUnit なり wx なりインストールしとけばいいじゃない、とおおらかに思ってたけど、できれば隔離したいのよね。依存関係が曖昧になりそうで。それはちゃんと書いとけばいいのか。で、バイナリはどこかに保存しておく？ そのままじゃコンパイル通らなくて、たとえば Makefile いじったりしたのはどう記録しとく？ 動的リンクで DLL が必要になったら？
なんかちゃんとやろうとするとどんどん深みにはまっていく気がする。そんな話。