2008年02月

『The Ruby Programming Language』を読んだ。こいつは良い本だ。副題の"Everything You Need To Know"っていうのは嘘じゃない。翻訳しようっていう話もちらほら聞こえる。当然、翻訳は出すべきだろう。

だが、この本は決して簡単ではない。こいつは『プログラミングPerl』と相似だ。その言語の創始者自身が書いた。そして、初心者が中級者になるために、最後に読むべき本はこれだ。けれども、その言語の流儀を全く知らない、チュートリアルすらやってない入門者は、この本では挫折する。

Ruby Insideも、こう書いてる。

The only downside, in terms of the thousands who might be browsing Amazon looking for a single Ruby book to start off with, is that the Hummingbird is so well focused on documenting the core elements of the Ruby language, it doesn’t work either as a tutorial / beginner’s introduction to Ruby, or as an exhaustive reference work (as, on both fronts, the Pickaxe attempts to be.)

そして、Ruby Insideは『The Ruby Way』を併せて買えと言ってる。うん、あれも良い本だ。だけど、第2版の日本語版が出てない。第1版はRuby 1.6にしか対応してない。

そういう出版状況を合わせて、今日編集さんと相談してきた。私は「入門者が初心者になる」ための本を書く。Rubyの流儀を知らない人がRubyの流儀を覚えるための本だ。そして、その上でMatzの本を買えばいい。そういう本を書きたい。今書いてる本を、そういう風に書き上げるつもりだ。

■ Ruby和書の読み方

プログラミングというものを経験したことがない人は『初めてのプログラミング』を買おう。これは良い入門書で、Rubyを使ってプログラミングという概念を学ぶことができる。同時にRubyの文法もちょっとだけ学ぶことができる。でも、この本だけではRubyについて何かを知ったと言うには不足だ。

プログラミングについて学びつつ、もっとRubyを知りたいならば。それならば、『たのしいRuby』が定番だ。

すぐに何かを作りたいなら、実践的なチュートリアルが欲しいところだ。そうすると、いくつかあるRails本は適当だろう。あと、ゲームプログラミング本もある。

でも、こういう本は他の言語でプログラミングを経験した人には冗長だ。それに、Ruby言語それ自体を学ぶには、「応用的」な内容がノイズになってしまう。そこで、私は「プログラミングは知っているけれどもRubyの流儀を知らない」人のためのRuby言語の本を書く。プログラミングを知っている人なら、これを買って欲しい。(と、自信を持って勧められる出来になったらいいな)

そして、最後に『The Ruby Programming Language』を買うのだ。翻訳はいずれ出るだろう。こうして、Ruby中級者になる。

Ruby上級者になるには?　私だってそれは知らないよ。少なくともRubyの言語機能も端から全部通読してみる必要はあるよね。分かってるつもりでも意外と知らない機能があるんだなー。そこを押さえるためには、Ruby Insideが挙げてるPickaxe本こと『プログラミングRuby』は必ず役に立つ。応用例は『Rubyクックブック』やRubyist Magazine出張版で学ぶことができる。

それから後は、Ruby自体の開発に携わったり、何かすごいライブラリやアプリケーションをRubyで作ったりすればいいんじゃない?

■ まとめ

あれを買え、これを買えって言ってばっかりでお金が掛かりそうで恐縮だけれど。まーね、学習にはお金が掛かるものだよ。でも、書籍だけで学習しようとおもったら、これが最短だと思うな。他にも、webで資料を漁ったり、勉強会に通ったりと道はあるけど、そういうのは時間コストが掛かるしね。どういうバランスでリソースを配分するかっていう問題だ。

私も、大きな口を叩いただけは頑張って書くから、だから(日本式論理飛躍)、出たらみんな買ってね。

携帯電話各社や大手ISPがフィルタリングのために契約しているネットスター社の、webサイトカテゴライズ。試せるサイトがあるので、試してみたわけだが。

ほぅ。素因数分解はトランスジェンダーの話題ですか。そうですか。

ま、目視で確認なんて言って、サイトごとの凄く粗い確認しかしてないんだろうね。だとすると、逆の原理でアダルトサイトを普通のサイトに偽装することもできるよね。

ネットスター社、だからおまえは信用できない。携帯電話各社、ISP各社はとっととこんな会社切って、私と契約しろよ。みんなで1億円ぐらい出資してくれればもっとまともなサービスを作るよ。

第2回RHGの逆襲を開催しました。

発表者は、事前に希望した候補者の中から当日ランダムに選択肢しました。RubyのKernel#randはなかなか優秀です。で、結局randさんのお告げにより私が発表しました。

■ 録画失敗

がーん。当日ばたばたしていて、ustream.tvの録画ボタンを押し忘れました。メインの部分はリアルタイムで見ていた人たちに流れただけで、ネットの海へと消えていきました。

責任とって今回の内容はどこかにしっかりまとめたいと思います。

■ 2nd part

その後、発表候補者だった吉岡さんがもう一度同じ範囲を発表してくださいました。私の発表を聞いた人向けなのでちょっととばし気味ですが、Kernel hackerの視点から鋭い指摘をなさっています。

• http://ustream.tv/myvideos/newest_first/1/Y51IYT3q57ReFBeJt,MCcp.VBYK3cgTY

■ 3rd part

それから、同じく発表候補者だったさわださんが、ハッシュ表のリンクリスト部分について詳しく発表してくださいました。

• http://ustream.tv/myvideos/newest_first/1/S37tNISatl3XA,oOOROMYLF2pLttiKm7

■ 4th part

それから、時間がやや余り気味だったので次章の予習をしました。

• http://ustream.tv/myvideos/newest_first/1/RywhQTCyY6x2ZHKCUthoa7mVyZs1EGo5

■ 代理人募集

録画とか、もうダメです。私、やることが穴だらけです。誰か、ちゃんとできる人、代わってください。

シリーズ・RubyのSymbol。だいぶ空いてしまったけど、気が向いたので続きを書く。

前回は文字列の同一性について復習したのであった。

■ 意義

そう言うわけで、文字列においては同一性と同値性は異なる。特に、Rubyの場合は同じリテラルも評価する度に異なるオブジェクトを生成する。ところが、これは不便な場合があるわけだ。

まず、文字列の同値性比較はコストがかかる。長い文字列を比較にするには時間が掛かる。保持しておくにも長い文字列だったらメモリーを食う。更に、毎回リテラルからオブジェクトを生成するとしたら、無駄なケースが多々ある。Railsに良く出てくる疑似名前付き引数みたいなやつ。

some_method "a" => 1, "b" => 2, "c" => 3

おい、この箇所を通る度に一々文字列のメモリー確保してオブジェクト構築するのか?　その背後ではパフォーマンス厨なら誰もが恐れるmalloc(3)が動いているというのに?

ま、文字列本体についてはRuby処理系もそんなに馬鹿じゃなくて、実際にはもう少し効率の良い処理をする(のだったと思う。確か)。でも内部でRString構造体の確保が毎回必要になるのは本当だ。

とにかく、文字列が含んでいる「文字の列」部分を確保して保持しておくのは色々大変だ。最小限に抑えたい。そこで、internする。

■ intern操作

intern操作によって、文字列はオブジェクトとして一意になる。だから、同一性判定するだけで低コストで比較できる。

10.times do
  p "foo".object_id
end

すると毎回違う結果が出るが、

10.times do
  p "foo".intern.object_id
end

は同じ結果がずらりと並ぶ。この「文字列をinternした結果」こそがSymbolオブジェクトなのである。

internというのは別にRuby固有の話ではない。Javaにだって、String#intern()がある。返ってくるのもStringオブジェクトであるっていう点がRubyと違うけれども。でも、「同値性の判定を同一性で済ませたい」というニーズは言語に依らずにある話。

そう言う感じで、Javaにとっては「文字列をinternしたもの」は文字列そのものだ。前回、文字列リテラルの同一性比較がtrueだったのも、Javaの場合は文字列リテラルはあらかじめinternされているからだ。

そう言う意味で、Symbolは「internされた文字列」に限りなく近い。違うのは、同一性と同値性が同義であることと、変更不能であることぐらいだ。変更可能だったら同一性と同値性の一致が知らない間に崩れていたりして困るからね。

それに、Rubyにしたってしばらく前に1.9ではSymbolはStringのサブクラスだった。Matzがなんか、実装しちゃったのだ。私は大反対の立場で、まぁ、諸々の反対とバグが沢山出たことで取りやめになったけど。

■ メモリー

同じ内容のシンボルは常にオブジェクトとして同一である。従って、

10.times do
 :foo
end

これは新たなオブジェクトを生成したりしない。詳しいことは次回扱うけれども、:fooみたいなシンボルリテラルの実体はRubyがソースコードを解析した時点で解決される。実行時にはメモリーの確保を伴わない。だから、速いしメモリーを食わない。

何故Railsがシンボルをいっぱい使っているのか?　1つの答えはこれだろう。

■ シンボルとは

シンボルとは何か。答えの1つはこれだ。

• 変更できない「文字列のようなもの」
  • 変更のためのメソッドを持っていない
  • 同値ならば、必ず同一である

明日、「RHGの逆襲」第2回を開催します。Ruby 1.9のソースコードを読む集いです。

会場からustream.tvで中継をおこなう予定です。13:00過ぎくらいから http://ustream.tv/channel/yugui にて流すでしょう。ustream付属のチャットでのコメントも歓迎します。

むぅ。Kernel::DATAはbindingでも保持してないのか。

a.rb:

require 'b'
p [DATA.read, __FILE__]
p eval("[DATA.read, __FILE__]", $b)
__END__
from a

b.rb:

$b = binding
__END__
from b

評価時の__FILE__に従うことを期待しちゃうかなぁ。うん。

Rails勉強会@東京 第27回に行ってきた。今回は伊藤忠テクノソリューションズさんの会議室を借りて開催。形式はいつものごとく、オープンスペースを前後半2回に分けて開催。

■ 前半

前半セッションでは、私が今書いているRuby入門書のダメ出しをやった。

細かいところは公開できないのだけれども、書籍の構成や技術的な表現について、執筆経験豊富なメンバーからいろいろな意見を頂いた。

■ 技術書の出版技法について

某オーム社ではSubversionで原稿を管理してるそうな。これはちょっと前に話題になったね。

私の場合は、原稿はRDで書いてる。

• 出版社側に出すのは独自の簡易マークアップ言語なので、rdtoolをつかってトランスレータを作成した。
• 書きながら分量を知りたいので自分でそれっぽいPDFを作成している。rd2latexをベースにカスタマイズしたトランスレータでRD→LaTeX→PDFと変換してる。
• 依存関係は勿論Rakeで管理。
• 原稿やコード例はSubversionで管理してるけど、これはローカルリポジトリで出版社側とは共有してない。

他の某Ruby書籍の場合は関係者用のWikiで原稿管理してるみたい。

某Rails書籍の場合、やっぱりSubversionで管理してるそうな。こっちは出版社側と共有してて編集者さんがコメントを付けてコミットしたりするそうな。

やっぱりプログラマからすると、作成したデータをバージョン管理しないというのはあり得ない話だ。バージョン管理しないとデータロストやデグレードに関して強い不安を感じる。加えて、Subversionで管理すると

• 共著が楽
• リポジトリを共有すれば、日々の原稿の進捗を見られるので編集者も安心

というメリットがある。

■ RDの未来

最近はもう、Rubyの埋め込みドキュメントはrdocがデファクトスタンダードになってしまった。rdocはRubyに標準添付されてるけどrdtoolはされてないしね。どうも将来が先細りのフォーマットな気がする。

とはいえ、私はRDが好きだ。汎用のマークアップ言語で、表現が簡易でかつ可読性が高く、ソースそのままで整形しなくても意味が通じる。rdtoolを使って自在に加工できる。私が文書を作成するとき第一のフォーマット選択肢はRDだし、rdtoolが動く限りRDを使うだろう。

■ 後半

後半はRedmineを触った。Railsで作られたBTSだ。

RedmineはRuby自体の開発のチケット管理に内定(それとも内々定くらいかな?)してるのだけれども誰も設置してなかったのだ。たぶん誰にもアサインされていないのが原因と思われるので、昨日、笹田さんと話して私がやることにした。とにかく設置してしまえばRuby開発陣も使うだろう。

いくつかの機能は足りないのでRedmineを改造することにする。なのだけれども、ちょっと段取りが悪かったのでRedmineの機能を調べてソースをちょっと覗くだけで時間が終わってしまった。

何にせよ、Redmineは便利で使いやすそうだ。ただ、0.6.3はUIが微妙に行き届いていない。trunkのバージョンのほうが良くできている。

■ Rubyの開発体制

Ruby処理系の開発はまだ人が足りていないという印象を受ける。「担当者がいないから放置されている」という類の問題が数多くある。一つ一つは細かいことではある。例えば、何とかのドキュメントを書くとか、何とかのどうでもいいようなバグを直すとか、日英のメーリングリストを通訳するとか。

こういうことにMatzやRubyコアメンバーの手を割くことはない。こういうのは、要は人を足せば解決するのだ。極端な話、どこかのお金のある会社が「新人3人好きなように使ってください」というのでも役に立つかもしれない。CRubyもそうだし、Sunがバックに付いたJRubyですら「やる人がいないからやっていないこと」があるみたいだ。

「新人3人」だけだと仕事を指示するのに手間がかかりすぎて逆効果かもしれない。でも、じゃあその頭として誰か「指示して割り当てる人」が付けばいい。その人がMatzにはっぱをかけて「この日までにfeature fixしてください」とか言って、あとは「新人」にドキュメントを書かせてレビューして。

そうすればRubyの開発はぐっと進んで、ドキュメントが充実し、処理系は安定するだろう。

あー、そう「マネージャー」ね。今のRuby 1.9には「マネージャー」が必要なんだ。開発者が開発に専念できるように、スケジュール管理とかリソース管理とかをこなして、適当に人員を使いながら雑用を片付けて行く人が。

笹田さんに「そんなに言うなら、その辺をYuguiがいくらかやってみたらどうか」と言われている。うん、できるだけのことはしたいと思ってる。あとは、どこかのお金持ちの会社が「Ruby処理系開発の雑用をやれ」って言ってフルタイムで雇ってくれれば本気でやるよ。リファレンスマニュアルも、今は趣味の時間にちびちび書いてるけど、仕事の時間に書いて良いならがしがし書くよ?

Rubyは今、産業的に大きく注目されている。「Rails案件」みたいなものが世の中に出てくるようになってきている。でもその基盤であるRuby処理系の開発は「お金や人手を出せば解決すること」が放置されている。こういうことにこそ、公的性質の強い組織や国がお金を出すべきじゃないのか? 私じゃなくても、少なくとも笹田さんとかmputさんにだけは行くべきじゃないのか。彼らの活動を支えるために「せめてお金ぐらいは出すべき」じゃないのか。こういうところで投資しておけばそれは人材を囲い込んで、Rubyにまつわる1つの市場に、支配的影響力を及ぼせるということだしね。NaClのように。

■ 私信

笹田さん、すんません。どうも最近スケジュールを1日間違えることが多いんです。植木算のやり過ぎかもしれませんw ……とか言って、草を植えすぎてどうかしたかもしれません。

よし来た、id:ululun。いわゆる「俺のターン」ってやつだね。

「＜性同一性障害＞「就職内定取り消しは違法」と損賠提訴」というニュースに関してid:ululunが書いた記事を読んだ。

• GIDと「本当の性別」

性同一性障害者で、転職経験があって、id:ululunが引いてるWikipedia記事を書いた張本人で、はてなユーザーで現在ニートの私が是非とも語らねばならないようだ。Ha, Ha, Ha!

「身元保証人の署名偽造」という要素もあるのだけれども、こっちは置いておこう。「戸籍とは異なる性別を記載したこと」についてのみ語る。

性同一性障害者が就職などの際に提出する書類の記載をどうしたらよいのか、そもそも不必要な性別記載を求めている社会こそが問題なのではないか、という論点について。

■ 何故、履歴書には性別欄があるのか

単純にJIS規格の履歴書様式例に性別欄があるからだろう。ま、その是非はおいとくとして。

JISは一々良い度胸してるよね、「JIS X0303 性別コード」は

• 1: 男
• 2: 女

しかなかったりして。ISO-5218は

• 0: Not Known
• 1: Male
• 2: Female
• 9: Not applicable

なのに。

JISの様式は変えるべきかも。

■ 何故、性別記載が必要なのか

むー。性別に応じて健康上のリスクも違うし、医療保険上の取り扱いも違うし。これまでに社会で受けてきて人格形成に影響を及ぼした文化的な扱いも違うと推定できるからなー。

あとは、採用における性差別の是正には、まず現状を把握しなきゃいけない。だから、基礎資料として社員の性別の把握は必要だよね。このあたりは、「差別是正の働きによって隠れていた差別が意識化されるとともに、明示化された対立構造に思考の枠組みが規定される虞」という一般的な問題に通じるわけだけれども。

• 参照: 私は乗り越える。私を乗り越えよ。

■ 私の場合

性別欄には"MtF-TS"と書く。欄が「男・女」で丸を付けるようになってる場合、二重線で元の書式を消してその上に"MtF-TS"と書く。それが一番正確だから。

それから、健康状態欄に「性同一性障害を除いて良好」と書く。性同一性障害がここで言うような意味での疾患であるかどうかには議論があるけれども、恒常的ストレスによって精神的に不安定になりがちな傾向が見られるのは指摘される(『性同一性障害の基礎と臨床』)ところだし。現に私は性同一性障害のストレスに耐えかねて抑鬱症状を発生していて、性別違和が引き金となってパニック発作を起こしたり、動けなくなる。これは、フェアネスのために書くべきことだよなー。

もっとも、あれだ。訊かれない限り、細かいリスクファクターまで事細かに説明する義理はないと思ってるけど。その手のことは、Wikipediaの記事に書いたし、私の提出した履歴書のソフトコピーはWikipediaの記事にリンクを張ってあるので。一般的な疾患だって、こちらから自発的に細かに説明する必要はないでしょ?　「入り口までは案内する。扉は自分で開けろ」(『マトリックス』)

■ 選択肢の場合

Webフォームやなんかで「男・女」から性別を選択しなければならない場合がある。あるいは、もう履歴書の話から離れてしまうけれども、どうでもいいような会員登録とかで、一々説明したくないとき。ま、店頭の人も説明されても困るだろうし。

こういうときは、「私が決める」。というか、「基準を私が決める」

■ 状態変数と射影

やー、だってねー。人間の性別って、そんな単純じゃないよ。昔、こんなのを書いた。人間の性別のあり方、状態変数の動き方を書いた。

• 性同一性障害の概要

発生の仕組みに関する部分だけは、その後に書いたWikipediaの記事のほうが詳しいかもしれない。こっちは他の人の手助けも入ってるし。

• 性別(Wikipedia)

これだけ沢山ある性別ファクターを、特定の視点に落とし込むといろいろな対立項が現れてくるわけだ。

• 「男・女」(文化的な振る舞いの意味で; Masculine, Feminine)
• 「男・女」(二次性徴的な意味で; Male, Female)
• 「Y染色体保持者・非保持者」(顕微鏡学的な意味で)
• 「SRY因子保持者・非保持者」(分子生物学的な意味で)
• 「異性愛者・同性愛者」(Heterosexual, Homosexual)
• 「男性愛好者・女性愛好者」
• 「性愛者・非性愛者」(Sexuals(?), Asexuals)
• 「異性装者・非異性装者」(Cross Dresser, Parallel Dresser(?))
• 「男性装者・女性装者」 (Masculine Dresser(?), Feminine Dresser(?))
• 「性転換または性別再割り当て経験者・非経験者」(Transsexual, Cissexual)
• 「性同一性定型者・性同一性障害者」(Gender Identity Ordered, Gender Identity Disordered)
• 「男性自認者・女性自認者」
• 「性自認保持者・性自認不定者」

つまりは、射影だな。性別というのは射影なので、射影関数を定義してくれないと答えようがない。

• 私の現在の血中ホルモン状態を訊いているか? 例えば保険リスクの評価のために? ならば「女性」だ。
• 私の戸籍上の性別記載を訊いているのか? 例えば法令上の処理のために? ならば「男性」だ。
• 私の生殖可能性を訊いているのか? 例えば生活プランの策定のために? ならば「不妊」だ。
• 私の消費スタイル類型を訊いているのか? 例えばマーケティングのために? ならば「腐女子」だ。敢えて二型に落とすなら「女性」だ。
• 私の外見を訊いているのか? 例えば本人確認のために? ならば「女性」だ。
  • そーいや、この前また「この書類、旦那さんのですか?」って言われたな。めんどくさい。
• 私の性自認を訊いているのか? 例えば、私が快適と感じる文化的取り扱いを推定するために? ならば「女性」だ

あらかじめ関数を提示されない場合は、相手の意図を察して私が対応を決めてあげることにしている。

• 営利企業の提供する会員サービスなら、知りたいのは消費スタイルだろう? 「女性」に丸をする。
• 初診受付なら、細かいことは医師に説明するとして、まず知りたいのは保険証の記載だろう? だったら「男性」に丸をする。
• 生命保険なら、知りたいのは健康リスクだろう? だったら、詳しく説明する。

だってそうでしょう。どうしても申し込みたいフォームに、住所の選択肢が「東京」「大阪」「名古屋」「四国」「九州」「札幌」しかなかったらどうする?　相手の意図を考えてとりあえず近そうなのに入力するし、それで問題になりそうなケースなら問い合わせるだろう。

■ 再び、履歴書について

就職時の履歴書っていうのは結構複雑で、法令上の性別の取り扱いの問題もある。健康リスクの問題もある。文化的にどういう形で社内の人間関係に取り込むべきかという推定材料の役割もあるし(決めつけの度が過ぎれば性差別だが)。だから、一番多くの情報を含んでいる"MtF-TS"と書く。

Webフォームの選択肢などでそれが許されないなら、とりあえず「女性」と書く。健康保険上の取り扱いとかそんなのは、健康診断の数値で何が出たとかそういうのと同じ「細かいこと」であって、社会生活上一番重要なのは文化的性別だからだ。で、詳しいことは面接で話す。

■ 会社にとっての性同一性障害

ま、実際のところ、性同一性障害なんて会社にとっては細かいことだ。本人にとっては重要なことだけれども、当事者としてそれだけは絶対に否定しないけれども。でも、赤の他人にとってはそれほど重要じゃない。なぜならば、身体的性別は重要じゃないからだ。

別に業務上で乱交するわけじゃなし、会社に勤めるにあたって身体的性別属性はそんなに重要じゃないでしょう†1。問題なのは文化的性別属性と法令上の取り扱いだ。確かに、文化的に背負っている性別属性と法令上の性別属性が異なるので人事担当者にはちょっとした手間を掛けることになる。そのあたりには一報しておく必要があるけれども、他の場面では法令上の性別も関係ない。だから、社内には文化的性別属性だけ通知しておけばそれで問題ない。

私の前の会社でも、上司と人事・総務にだけ話を通して、後はとくに「会社としては」話さなかったよ。その他の、同僚との個人対個人としてのつきあいの中では「個人として」話をした相手もいるけどね。

ま、これは私のつきあいのスタイルであって、「結婚を前提としたお付き合い」でもするんでなければ一般論としては知人に性同一性障害の問題を話さなくて良いと思うけど。だって、知人に自分の性器の形態や特定の遺伝子の発現状態について話さないでしょ?†2

■ 各方面に求めたいこと

うん。結論として、各方面にはいくつかのことをいいたい。

■ 様式を作る人事とかの人へ

様式を作る人は、その性別属性は何の役に立つのかもう一度自問して欲しい。必要がないなら訊かなくて良い筈だ。

履歴書に「生まれた時刻に天王星が位置していた星座の最も明るい星の絶対等級を2進整数で表した値に含まれる1の数(32bit整数値LE)をバイト列"dankogai"とXORしたものを出力するrrencode」は含まれない。知っても仕方がないからだ。同様に、知っても仕方がないならば性別を書かせる必要はない。

必要がないのに尋ねても良いことはない。「性差別をするつもりだ」と勘ぐられるかもしれないし、あなたにはそのつもりがなくても社内の誰かが性差別するかもしれない。必要のない情報は保持しないというのは情報化時代の大前提ですYO!　これからはインターネットでRSSがアルファギークなんですYO!

閑話休題。何か必要があって知りたいならその必要に合わせて射影関数を定義すべきだ。例えば「身体的に男性である正社員のお嫁さん候補を探しているので、男性に性的指向が向いているか否かを記述してください。左欄に水着姿の全身写真を貼付してください」とか(w

■ 性同一性障害当事者

私が性別欄に「MtF-TS」と書いているのは、より多くの情報を提供しようという求人側に対する個人的な親切心にすぎない。射影関数が定義されていない限り、どの関数を選択するかは記述側の裁量なわけで、「性自認」という関数を選択しても構わないと思う。

それから、少なくとも東京のweb業界に関しては、性同一性障害に偏見はない。おそれないで、普通に就職活動すればよいと思う。私は大学卒業の時に「性同一性障害ということを開示したら就職先なんかないだろう」と恐れを感じてしまって、私としては異様に活動が消極的だったのだけれども、この点だけは後悔している。あとで業界を見回してみたらそんなことなかった。消極的になりさえしなければ、キャリア上もっと有利な選択肢はあった。

今の真っ当な人の性同一性障害に対する感覚は、「聞いたことはある。深刻な問題らしいけれども、よく知らないので分からない」だ。差別的な見方はしていないし、さりとて同情的でもない。知識がないからだ。偏見を持ってる人もいるけど、持ってない人が沢山いる。だから、性同一性障害の問題を会社に対してオープンにしても内定は得られる。だったら、性同一性障害を理由に落とすような会社には落としてもらった方がよい。後で苦労せずに済む。

会社での人間関係も問題ない。オープンにした上で内定もらったなら、もう会社は味方だ。その上で上司と人事と総務にだけ話を通せばよい。同僚に開示する必要はない。気になるなら開示しなくていい。ただ、私の場合は開示しても人間関係に支障はなかった。

支障が出る可能性についてやたら悲観的に愚痴愚痴いう面接官がいたので「そりゃおまえの偏見を投影してるだけだろう。一般人はそんなに気にしないんだよ。氏ね」と思ってそのまま連絡を絶った会社もあるけど、大体において支障なんかない。だって、一般の社会人は同僚の性器の形態には興味を持たないからだ。ポスト・オペなら尚更に支障はない。

だいたいが、こちとら何年性同一性障害やってると思ってるんだ?　性同一性障害を前提に人間関係築くのは慣れてるんだよね。

■ 「本当の性別」論者

「本当の性別」という人は何が本当の性別だと思っているのだろう。

• 「戸籍上の性別」というなら、おまえは知人の戸籍を全部見たのかと言いたい。
• 「性器の形」というなら、おまえは知人の性器を全部見たのかと言いたい。このエロス人!
• 「遺伝子上の性別」というなら、おまえは遺伝子検査をしたのかと言いたい。ちなみに、数パーセントの確率であなたは自分が思っているのとは遺伝的には違う性別なのでショックを受けないように。
• 「産む性、産ませる性」というなら、じゃあ不妊はどちらでもないんだな、と。
• 性愛を問題にするなら、同性愛者、両性愛者、非性愛者はどうするのか、話はそれからだ。
• 「外見」、とはいわんだろう。結構、漂わせる雰囲気で変えられるものだしね。

しかし、これらの選択基準のいずれもが特定の場合には適切であり得る。それを私は射影関数と言っている。

本当の性別なんてものは、私がこの記事のずっと上のほうに書いたような長くて事細かな記述によって近似的に描写できるのみだ。ただ、時、場所、目的によって適切な射影関数というのは存在して、私は妥当な射影関数を提示されればそれに従う。

ただし、そもそも性差別とはなんだったのかというところを考えれば分かるように、射影関数を不適切に使用するとそれは差別的な取り扱いを生む可能性がある。射影関数の選択は政治的な行為であることを忘れるべきでない。

■ あとがき

所々不必要にテンションが高いのは、こうやってメタに茶化す視点を保持しないと性別違和や今までに遭遇した屈辱的な経験を思い出してダウンするからです。「会社にとってはそんなに重要でない」と書いた一方、やはり本人にとっては自己同一性にかかわる重要な問題です。当事者には「気にするな」と言いたいですが、それ以外には「やはり軽い問題ではない」と改めて強調したいと思います。

• †1: 性風俗産業を除く
• †2: 一部erogeekを除く

前にやったやつでもそれなりに満足だったのだけれども、

• 起動後にDock上のアプリケーションのアイコンがJava標準にやつになってしまう
• メニューバーにクラス名が出ていて厭な感じ

■ 改

Jude 5.2もリリースして、Macでもぬるぽらないようになったそうなので、もう一回やってみた。

■ 参考

• Mac 版 JUDE/Think!
• Java Deployment Options for Mac OS X : Mac OS X Application Bundles

■ やったこと。

• Jude Professional 5.2のzipを落としてくる。
• 次のツリーを作成
  • Jude
    • Contents
      • MacOS
      • Resources
• zipを展開したjude_professional/*を、Jude/Contents/Resources/に移動
• /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/MacOS/からJavaApplicationStubをJude/Contents/MacOS/にコピー
• ディレクトリJude/Contents/Resources/Javaを作成。
• ../jude-pro.jarへのシンボリックリンク、Jude/Contents/Resources/Java/jude-pro.jarを作成
• 前回と同じく、アイコンファイルを作成。
• 下の内容のJude/Contents/Info.plistを作成。
• JudeをJude.appに改名

■ Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>Japanese</string>
    <key>CFBundleDocumentTypes</key>
    <array>
      <dict>
        <key>CFBundleTypeExtensions</key>
        <array>
          <string>jude</string>
        </array>
        <key>CFBundleTypeIconFile</key>
        <string>jude-doc.icns</string>
        <key>CFBundleTypeName</key>
        <string>Jude Document File</string>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
      </dict>
    </array>
    <key>CFBundleExecutable</key>
    <string>JavaApplicationStub</string>
    <key>CFBundleIconFile</key>
    <string>jude.icns</string>
    <key>CFBundleIdentifier</key>
    <string>jp.co.esm.caddies.jomt.jude</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>Jude</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleVersion</key>
    <string>5.2</string>
    <key>Java</key>
    <dict>
      <key>MainClass</key>
      <string>JP.co.esm.caddies.jomt.Jude</string>
      <key>JVMVersion</key>
      <string>1.5*</string>
      <key>ClassPath</key>
      <string>$JAVAROOT/jude-pro.jar</string>
      <key>VMOptions</key>
      <string>-Xms16m -Xmx512m -Xss2m</string>
      <key>Properties</key>
      <dict>
        <key>apple.laf.useScreenMenuBar</key>
        <string>true</string>
        <key>com.apple.smallTabs</key>
        <string>true</string>
      </dict>
    </dict>
  </dict>
</plist>