2011-08-28

英語の名刺(など)で日本人の氏名をどう表記するかという話。

英語で日本人の氏名を記述するとき、Masaaki Shibata のように、名・姓の順で書くのがいまの習慣になっている。これはいつからはじまったのだろう。どうして姓名の順を入れ替えて書くかというと、その源泉は英米の氏名がその順で呼び習わされているので、それに合わせようという発想だろう。

いっぽうで、われわれが呼んでいる順にそのまま Shibata Masaaki とすべきだという意見もある。わざわざ英米の慣習にあわせてひっくり返すのはおかしなことだという、これも一理ある。日本語で英米人の名前をわざわざひっくり返したりはしないんだから。

最近名刺では、Masaaki SHIBATA という表記を見かける。いっぽうで姓・名表記をする人のなかには SHIBATA Masaaki という表記をする人もいる。どちらも、姓名の表記順が議論となり混沌としてきた現実を受けて、こっちが姓ですよ、あるいはこっちが名ですよという識別ができるようにという配慮で、姓のほうに大文字を使っているものと思う。

しかし、大文字で書かれているほうが姓であるという約束ごとは、英語圏で暗黙に通用するのだろうか。姓のほうを大文字にするという発想じたいが、姓・名の順で名乗る日本人的な感覚に頼ったものではないのかな。それに、姓にしろ名にしろ、ぜんぶ大文字の字面というのは叫んでいるようであまり美しくない。

姓名の順が日本と同じ中国や韓国では、日本のようにわざわざ順序を入れ替えたりはしていないので話は楽だ。先日、日本の大学に勤める韓国の方の名刺を目にする機会があったのだが、その英語表記は、「Bae, Yong Joon」のようになっていた。これはうまいやり方だと思った。英語圏でも書面などで姓・名順の表記をすることはあるが、そういうときは、Smith, John のようにカンマで区切る。その表記を使ったわけだ。英語圏の人からすると、これで最初の部分が姓であることが連想され、また名刺にわざわざその表記で名前を刷ることで、呼び名としてはこの順で読むのだな、ということまで伝わるんじゃないだろうか。大文字にするよりは、いいアイデアに思える。もっともこれは名刺のうえでだけの話で、ふつうの文章でこの調子ではやってほしくない。

そもそも、どっちが姓でどっちが名かというのは、そんなにはっきりさせる必要のある要素なのだろうか。家族名か個人名かなんてのはその社会での習慣の問題で、名前の表記に内在させる必然性はないでしょ。ほとんどの場合、名前というのはその人がどう呼ばれているか、という事実を伝達するだけでじゅうぶんなはずだ。あとは名刺を渡すときにでもついでに話して会話のきっかけにすればいいくらいで。どうしても名刺にその情報が必要だという人は、矢印ひいて「こっちがファミリーネームです」と注でもつければそのほうがわかりやすくていい。

個人的には、いずれ混乱が収束するのであれば、自分がどのように呼ばれているかというのを素直に書いて、Shibata Masaaki と書けばそれでよいというのが自然でいいと思う。

2011-07-14

最近いつになく C を書いている。WZ マクロ以来かもしれないくらい。いつか Python に帰ってくるぞ、と。

で、C は、コードの中味以外で気を遣うことが多すぎる、と思った。ライブラリ使うにも、コンパイルに一苦労したり、コンパイル通ってもリンクでこけたり。リンクできても実行時にこけたり。英語のドキュメントを必死で調べたり検索しまくったりしないといけない。

それに、そうしてようやく手に入れたバイナリのライブラリを自分のプロジェクトにどうやって配置したものか迷う。オトナはみんな通ってきた道なんでしょうけど……。

たとえば CUnit 使うとして、バイナリは(あとヘッダファイルは)リポジトリに格納すべき? もちろん自分のコードじゃないから、格納しても基本的に編集するわけじゃない。しかし数年後に同じライブラリが同様に手に入るかというと絶対の保証はないわけで。リポジトリにそういう外部のライブラリも格納しておけば、チェックアウトするだけで、依存しているライブラリを求めてサイト回ってコンパイルする苦労を何度もしなくても、即ビルドできる。

ところがそういうバイナリは、それだけぽんとリポジトリに入っていてもそのうち素性がわからなくなる(はず)。じゃあ元のソースコードもリポジトリに入れときますか、ということになるとさらにプロジェクトの容量が肥大化する。CUnit くらいならそんなに大きくないからいいけど、wxWidgets くらいまで行ったらどうすんの? それにそういう外部のライブラリ使うプロジェクトが複数あったら? (実際あるけど。)各プロジェクトにそれぞれリンクするバイナリを入れとくの?

で、思いついて svn:externals とか駆使してみたりしたんだけど、これを入れると svn up が遅くなる! 外部リンクひとつごとに、たとえ同じリポジトリからでも別個にセッション張るそうで、やたら時間がかかって調子が狂う。ちゃんと動いていることは動いているんだけど、作業効率のこと考えると svn:externals はあんまりよくないね……。

このへんのノウハウは『Subversion 実践入門』という本を参考にしてるのだけど、実際にどこまで踏み込むかはプロジェクトごとにそれぞれなんだろうな。というわけでまだ模索中。

昔はそれぞれのコンピュータに CUnit なり wx なりインストールしとけばいいじゃない、とおおらかに思ってたけど、できれば隔離したいのよね。依存関係が曖昧になりそうで。それはちゃんと書いとけばいいのか。で、バイナリはどこかに保存しておく? そのままじゃコンパイル通らなくて、たとえば Makefile いじったりしたのはどう記録しとく? 動的リンクで DLL が必要になったら?

なんかちゃんとやろうとするとどんどん深みにはまっていく気がする。そんな話。

2010-11-22

ツイッターがあるとますますここを書かなくなる。言いたいことはあるんだけど、140 字では足りなくて書くのをあきらめたりする始末。早くブログにしなさいってことか。

更新情報

「__del__, gc, 循環参照, weakref」という覚え書きを書きました。

2010-09-29

ひみつメモ帳 for Mac OS X

最近 Cocoa のプログラミングについて調べたりしているのですよ。Objective-C も Xcode も最初はどうしていいかわからなかったけど、わかってくるとよくできていると感心するようになってきた。ほんとはこれで iOS アプリを作れるようになりたいのだけど。

学習をかねて、「ひみつメモ帳」の Mac 版を作りました。Mac をお使いの方は試しに使ってみて動いたかどうか報告いただけるとありがたいです。

動作環境:
Mac OS X バージョン 10.6 (Snow Leopard) 以降 (Universal Binary)

初めての Mac アプリなので(配布方法含め)これでいいのか自信がない。

とはいえ、これでようやくウェブサイトのパスワードなどを記録したひみつテキスト (*.txts) を Dropbox などのストレージサービスに保存してさえおけば、 Windows からも Mac からも参照できるようになったぞ。これこそ当初のもくろみだったのに、一年近くかかってしまった。

余談だけど、当初はクロスプラットフォームにするのにいいかと思って、コードは wxWidgets を使って書いていた。しかし Mac 版を作るとなると、メニュー構成やらなにやらで結局 Xcode を使って Cocoa で書いたほうが無理がないことに気づいた。Windows 版も最初から C# で書けばよかったのかな? ただ .NET Framework はネイティブのライブラリ (OpenSSL) と組み合わせるのがめんどくさそう。できればシングルバイナリにしたいのですよ。あるいは、wx ならせめて wxPython を使っていたほうが幸せだったかもしれない。まあなんでも経験ということで。

その他近況

  • ThinkPad X201s 買った。
  • iPhone 4 買った。

iPad や Kindle まで手を出して、どう考えても今年は買いすぎ。なんの風が吹いていたのか。ThinkPad と iPod はいずれ買い換えなくてはいけなかったのだけど。まあ散財に見えるよね……。

Xcode 使うと iMac (2006年、Core 2 Duo) のビルドが遅いなあとか思ってしまうのだけど、今年は自制しよう。

ツイッターだと環境構築とかアプリの話とかができないのでなにか書くかも。といっても流行りものなんであんまりあらためて書くことないかなあ。

2010-08-30

Kindle 3 を買ったので。

Kindle 3 について

Kindle 2 からの変化を踏まえた、Kindle 3 についての覚え書き。

筐体

小さく、軽くなった。Kindle 2 でもじゅうぶん小さく、軽かったけど。

キーボードが一列減って、数字キーがなくなった。数字は記号と同様 SYM キー経由で入力する。でも意外と困らないよ。というかキーボードはあまり出番がない。

新しい 5-way ナビゲーションキーに慣れない。Kindle 2 のもあんまり操作しやすくなかったけど。Kindle 3 では、 5-way ナビゲーションの下に Back ボタンがあるのだが、下方向を押しているときに間違ってこの Back ボタンに触れてしまい、操作画面が一つ前に戻ってしまうことがある。これはたいへんなストレス。慣れればいけるのかなあ……。

ディスプレイ

Kindle 2 よりも良くなった(黒がより黒くなった)。が、劇的に変わったわけではない。Kindle 2 でもなかなかの品質であった。表示品質のためだけに Kindle 2 から買い換えることはない。

(ちなみに、前に某氏に聞かれて即答できなかった、Kindle ディスプレイの仕様は、 600 × 800 ピクセル、16 階調モノクロ電子ペーパー。)

電子ペーパーを見たことない人にその表示品質を説明するのは難しい。コントラスト的には新聞紙くらいで、それをラミネート加工した感じといえば近いだろうか。

ファイル名やコンテンツで日本語が表示できるようになった

正確にいうと、日・中・韓およびキリル文字のフォントを内蔵した。

これがいちばんありがたい。USB でパソコンとつなげて UTF-8 のテキストファイルを放り込めば、そのまま読める。小さな文書ならわざわざ電子ブックのフォーマットにする必要もない。

日本語の書体は、出自がよくわからないのだけど、独特のゴシック(サンセリフ)体。意外とまともなんだけれども、読書に最適な書体とはいえないことも確か。技術書やビジネス書なら気にならないかもしれないけど。

Kindle 3 で日本語ファイル名の文書を表示

Kindle 3 で書体は 3 種類から選べるようになったが、どの書体を選んでも日本語の書体は変わらない。内蔵フォントによる日本語コンテンツの表示品質に過度の期待はしないように。Kindle 3 になっても日本語の本格的な読書は PDF に頼ることになると思う。

それから、日本語の入力までできるようになったわけではないことに注意。コレクション(タグのようなもの)を作っても、そのコレクションに日本語の名前を付けることはできない。ノートやソーシャル・ネットワーク機能などで日本語を使えれば素晴らしいのだけれど。

あとはまあ当然といえば当然かもしれないけど、日本語の読み上げには未対応。日本語はぜんぶ読み飛ばします。まあしかたない。(PDF 以外での)縦書きも非対応。まあ当たり前。世の中人がやってくれるのを待ってちゃ駄目なことだってある。

とはいえ、ずらっとならんだローマ字の書名から文書を探すのは苦痛だったので、スキャンした書籍や、「青空キンドル」でPDF にした「青空文庫」の作品など、日本語のデータをたくさん Kindle に入れていた人には便利。

なお、PDF の表示では、日本語の文書はこれまで同様フォントが埋め込まれている必要があるのには注意。

WebKit ベースブラウザ

Kindle にもモダンなブラウザが搭載された。しかし相変わらず “experimental” 扱い。ほんとに WebKit で、JavaScript まで動くので、ぴょこぴょこ動くページでは電子ペーパーの表示速度だとかえってつらいのが泣ける。このあたりが実験的とされるゆえんか。

しかし日本語のページも問題なく表示できるので、テキスト主体のブログなどならそのまま読める。それから、日本語が最初から使えることで、ウェブから Kindle 向けにコンテンツを配布できるハードルは下がったと思うから、ユーザーベースでの今後の展開は期待できるかもしれない。

しかしこのタイミングで「青キンDirect」がなくなるのは残念すぎる……。

Kindle 3 で新聞社のサイトを表示
Kindle 3 でテキスト主体のブログを表示

ちなみに、Kindle は(2 も 3 も)ディスプレイの書き換えが遅いので、これをウェブブラウジング用のタブレット端末として使おうというようなことを考えてはいけません。リファレンス的な用途にもまともに使えません。小説やエッセイなどの読みものをじっくり腰を据えて読むのに最適化されたデバイスです。小説を読むことだけに特化されていると言ってもいいくらい。便利デバイスが欲しい人は iPad を買いましょう。