いわブロ - みんなのアイデンティティ: Identity Management & Developement Environment

東京の桜は散ってしまいましたが、SCSA　（Sun認定 Solaris システム管理者）試験のパートIIを受けてきました。今は、連休の谷間ということもあり、業務にも少し余裕があります。忙しくなる前に、パートIIの試験に合格しておきたかったのです。試験会場に行ってみると、かなり込んでいました。連休の後半が始まる前日にもかかわらずにです。同じような事情の人が多いためでしょうか。

結果は９０％の正答率　(55/61) で合格でした。問題はこれをどう見るかです。９割も合っていたと見ることも出来れば、１割も間違っていたと見ることも出来ます。しかし、我々の役割のひとつが、『Solarisを含めたSunの優れた技術を日本のお客様に正しく伝えること』であることを考えれば、１割も間違えることは問題です。１０回に１回は間違った情報が伝わってしまうと言うことですから。

言うまでもありませんが、弊社サポートから出される回答が、１０回に１回間違っているということではありません。複数の担当者が必要に応じて検証を行った上で回答を作成しています。気をつけなければならないのは、お客様を訪問して、その場で質問に答えるというようなケースです。簡単な質問でも、即答せず、持ち帰って検討する勇気が必要だと思いました。今回の試験でも、「上手く行けば満点か？」とも思ったのですが、そんなことは全くなかったので。

日曜日に立川にある昭和記念公園に行きました。天気も良く、桜、チューリップ、菜の花が満開でした。

チューリップは特にきれいです。

他にも色々撮ったので、ここを見て下さい。

SCSA (Sun Certified System Administrator for Solaris 10) の試験を受けてきました。この試験にはPart　IとPart　IIがありますが、今回はPart　Iの方に合格しました。

まずは、なぜSunの社員がSolarisの試験を受けるのかについて説明しなければなりません。タクシーの運転手が普通免許の試験を受けるようなもので、受かって当たり前、受からないと少し問題かも？という感じがあるかもしれません。しかし、実際は、そうでもないのです。社員にはそれぞれ担当分野があり、それ以外ではたとえSolarisの機能でも知らないことがあります。日常の業務に追われれば追われるほど、知識に偏りが生じます。また、Solarisは日々進化しています。定期的に勉強しなければ得た知識はすぐに古くなってしまいます。

私はと言えば、Solarisは、それ以前のSunOSの頃から使っていますし、開発や移植のターゲットには必ずSolarisが含まれていました。多くの場合、開発のプラットフォーム自体がSolarisでした。システム管理者として働いたことはありませんが、自分のワークステーションは自分で管理するという意味ではシステム管理もしています。ですから、『Solarisを知っているか？』と聞かれたら、『良く知っています』と答えるはずです。そのため試験にも自信がありました。

試験の準備のために、翔泳社から出版されている『SUN教科書　Solaris　１０』という本を買いました。「サン・マイクロシステムズ監修！」と背表紙に大きく書かれているので良い本に違いありません。本を読み始めると、ずいぶん知らないことが試験範囲に含まれていることに驚きました。これだとかなり勉強しないと受かりそうにありません。特にプリンタの設定は今までやったことがありません。また、バックアップとリカバリに関してもかなり知識があやふやです。その反面、セキュリティやアクセス制御に関しては、自分の担当分野に近いこともあり問題なさそうなことも分かりました。

心を入れ替えて勉強をしました。上記の教科書を良く読んで、主要な手順は実際にやってみました。SolarisのインストールについてはSPARCとx86について何種類かのパターンを試しました。いつも使っているOSが、突然、最新版のSolaris　１０になったのでびっくりした同僚もいるかもしれません。　――　これから文句がくるかも？　――　また、バックアップ、リカバリについても実際にやってみました。しかし、プリンタの設定に関しては、設定可能なプリンタがなかったのでやっていません。MANページやオンラインドキュメントを読んでオプション等を確認しました。１ヶ月くらい勉強しましたが、実際には２０日（祝日：春分の日）と土、日を合わせた「三夜漬け」です。

試験を受けるまでは自信がなかったのですが、結果は思ったよりも良く、５９問中、５５問正解しました。Sunの社員ならもっと出来て当然という考えもあるかもしれませんが、内容はかなり難しいと思いました。逆に言えば受かることに意味があります。時間のあるときに受験してみては如何でしょうか。

暖かくなりましたね。気の早いチューリップを見つけました。背の低い早生の品種です。

先日、SSHAの仕様について問い合わせを頂きました。そのとき気がついたことをお知らせします。

SSHA(Salted SHA)は弊社Sun Java System Directory Serverをはじめ、他のディレクトリ・サーバでも使用されているパスワードを保存するためのアルゴリズムです。パスワード保存のアルゴリズムは多くありますが、多くのサーバでSSHAがディフォルト設定になっています。

"Salt" （塩）はサーバ側で生成する乱数です。サーバは、ユーザから送られて来たパスワードを保存する際に、パスワードにこの乱数を付加した上でハッシュ値を計算します。こうすることで同じパスワードをつけたユーザがいても、サーバ側では異なる値が保存されるため、セキュリティ・レベルが向上します。パスワードに塩で「味付け」するという感じでしょうか。

様々なサーバやツールのSSHAの実装を調べたのですが、気になることがありました。サーバやツール毎に"Salt"の長さが異なることです。弊社のDirectory ServerやOpenDSなどは８バイト派ですが、古くからある他のサーバやツールでは４バイトしかとっていないものがありました。これによりセキュリティ上の問題や互換性の問題が発生するというわけではありません。ユーザから送られてきたバスワードを確認する処理で固定の長さの"Salt"を想定していると困りますが、弊社のサーバを含め他のサーバも私が見た限りは問題ないようです。

と言うことは０バイトでも良いということになります。０バイトの"Salt"を付加するとは、付加しないことと同じです。そのため、０バイトの"Salt"が付加されたハッシュ値を使ったパスワード確認のアルゴリズムはSHAと全く同じということになります。試しにちょっとイタズラしてみましょう。まずSHAを使ってユーザのパスワードを保存します。保存した内容は以下のようになります。

userPassword: {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

パスワード保存のアルゴリズムを示す{SHA}の部分に"S"を追加して｛SSHA}にして見ます。その右側にあるハッシュ値自体には変更は加えません。

userPassword: {SSHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=

これでもちゃんと認証に成功しました。

以上です。何の役にも立たない情報ですみませんでした。

オースチンから帰ってきて、1週間ほど日本にいた後に、今度はサンタ・クララに来ています。時差ぼけのトリプルパンチで、体調を崩してしまいました。時差の他にも、英語でしゃべることや、道路の右側を車で走ることなど、慣れないことをするため、ストレスもあります。さらに、ミーティングでは、私が英語で一所懸命しゃべっているのにも関わらず、理解しない人もいます。不愉快極まりないことです。

 本当のことを言うと、英語の発音や聞き取りには自信がないのです。しかし、滅多にないことですが、今回に限り、私の方が正しく発音している単語がありました。それを紹介したいと思います。「SQL」というデータベースに問い合わせをする際に用いる言語があります。アメリカ人はこれを「シックル」というように発音します。初めて、「シックル・サーバ」という発音を聞いた時には、シック・サーバと聞こえたため（ルの音が聞こえませんでした）、サーバが病気に罹ったのかと思いましたが、これはSQL　Serverのことでした。

何かと話題になっているMySQLですが、アメリカ人はこれを「マイシックル」というように発音します。しかし、「マイエスキューエル」が正しいのだそうです。もちろんSunの社員はそれを知っています。しかし、「シックル」と言い慣れているため、どうしても会話では「マイシックル」と言ってしまいます。そんなときは、私が、「マイ・エス・キュー・エル」とわざとゆっくり発音すると、相手も慌てて言い直してきます。日本では昔からこう発音しているので、私は言い間違えません。私の人生で今までなかったことです。ちょっとしたストレス解消になっています。

昔、同じようなテレビ・コマーシャルがありましたよね！　――　若い人は知らないかも？。坊屋三郎が外国人の「クイントリックス（松下電器のテレビの名前）」の発音を純日本風の発音で直すというCMです。この情景が浮かんできて、可笑しくなってしまいました。はたから見れば、そんな感じなのかと思います。

ちなみに、 Vaau というロール管理用のソフトウェアもあります。こちらは、日本人の感覚で言えば、「バーウ」と発音すると思いますが、正しくは「バーユ」です。初めは私も間違えましたが今では大丈夫です。おばあさんがお風呂に入っている情景を思い浮かべるようにすようにすれば忘れません。

後一日で、日本に帰ります。 帰ったらソフトウェアの行商です。

前々回のブログでオースチンが普通の街というように書きましたが、間違いであったようです。こちらの人と話をしたら"Keep Austin Weird"というこの町のスローガンを教えて貰いました。米国でも大型ショッピングセンターが出来ることにより地域の商店街が寂れたり、大企業が進出することにより中小企業の経営が上手くいかなくなったりすることがあります。これは、ある程度は仕方がないことですが、あまり極端だと米国の町が全て均一になってしまします。そこで、地域の商店やビジネスを守ることによりオースチンの特色を大切にして行こうというのが、このスローガンの意味なのだそうです。実際、テキサス大学があるためもあり、テキサス州のなかでは突出してリベラルな土地柄であると言えます。また、ライブ演奏が盛んであるという特色もあります。

昨日は、Identity Manager開発部門のマネージャにライブ演奏を聴きにつれていって貰いました。とても楽しかったです。

宿泊しているホテルで早朝に火災警報機が鳴りました。テキサスでも朝はとても寒いです。結局、台所のトースターが加熱したとかで本当の火事にはならなかったのですが、びっくりしました。

出張でテキサス州オースチンに来ています。

通路側の席といつも予約している航空会社なのに、満席のため、窓側の席になってしまいました。出発からちょっと不満。その後、何が起こるかは、花木さんのブログを見て下さい。日本時間の真夜中に大きな荷物を抱えて全力疾走というのはかなりこたえました。ひとりなら絶対に走らないのですが、花木さんが走るので、仕方なく走りました。

良かった点は窓際だったので、きれいな虹が見えたことです。霧のような雲が点在する空模様で、乗っている飛行機の影が雲に映ります。時折その周りを丸く囲んで虹が見えることがありました。長く見ていると、太陽の位置、飛行機と雲との距離、雲の厚さなどから、次にどの雲に虹が見えるかが分るようになります。予想が当たると単純に嬉しかったりもします。

オースチンの印象です。着く前は、テキサスの砂漠で、映画のようにブーツを履いた大きな人が街を歩いていると予想していたのですが、全く違いました。カリフォルニアの街と言われても気が付かないかもしれません。普通に雨が降ったりもします。これだとテキサスに来たという特別なことが無くなってしまいます。そこで写真を載せることにしました。本日の朝食ワッフルです。

最後になってしまいましたが、31日（木）にはSun Software Showcase が行われます。是非おいで下さい。

ずいぶんと長い時間がかかってしまいましたが、ようやくOpenSSO/Access　Manager用の指静脈認証モジュールが出来上がりました。

これらの技術について未だ詳しくは知らないという方がいるかもしれません。まず、指静脈認証についてはゆびブロがお勧めです。ここからリンクをたどって行けばさらに詳細も分るようになっています。次にOpenSSOです。本家はここにあります。英語で分り難いという人には、工藤さんのブログが役に立つと思います。Access Managerは、オープン・ソース・ソフトウェアであるOpenSSOの製品版です。

今回作ったものは、認証方式のひとつとして指静脈認証を使えるようにするためにOpenSSO/Access Managerに追加するソフトウェア・モジュールです。指静脈認証は優れた認証方式であるため、様々なアプリケーションで利用したいという需要があるはずです。しかし、アプリケーション毎に新たな認証方式を追加するための改造を加えるとなると、コストがかかり過ぎてしまいます。そこで、OpenSSO/Access Managerに指静脈認証の機能を持たせることにより、認証済みのユーザがWeb上の様々なアプリケーションに対してシングル・サイン・オン出来るようすれば、ユーザの利便性も向上し、コストも削減できると考えました。これが開発の動機です。基本的に、既存のアプリケーションには改造が必要ありません。この点は大きいと思います。

 開発したものは出来る限り多くの人に使って頂きたいと考え、以下の点に留意して開発を進めました。

１）簡単にインストール出来ること

 多くの人に使って貰うには、簡単にインストール出来るものでなければなりません。サーバに標準で付属する機能を有効に利用することにより、インストールするモジュールを最小限に抑えました。

２）容易に入手可能なソフトウェアのみを利用すること

 簡単にインストールすることが出来ても、入手することが難しいソフトウェアに依存していては意味がありません。今回はOpenSSO, OpenDS, GlassFish等のOSS(オープン・ソース・ソフトウェア）を使うことにより、誰でも簡単に機能を試してみることが出来るようになっています。（注：日立指認証管理システムは別途ご購入して頂く必要があります。）

３）容易にカスタマイズ可能であること

 開発に際しては、様々な用途に合わせて柔軟な設定が可能であるようにしました。しかし対応できない用途が出てくる可能性はあります。その際、必要に応じてソースコードをカスタマイズすることが出来るように開発物のオープン・ソース化を予定しています。

次回からは、インストール方法について記述していく予定です。

まもなく1月１６日版ブログの翻訳が出来上がります。今回はMySQL　ABの買収の話なので興味のある人も多いでしょう。ひとつ面白い表現があったので紹介します。"arm's length"という表現です。ブログでは2箇所に出てきますが、微妙に異なる意味で使われています。

１） We've historically worked at arm's length to optimize MySQL on Sun's platforms.

２） I've asked our team to negotiate an arms' length commercial transaction, prior to closing,

 "arm's length"は文字通り「腕を伸ばせば届く距離」という意味ですが、これを近いと感じるかは状況によります。会社の同僚ならば「近い」という感じになりますが、恋人ならば「よそよそしい」感じにもなります。上記においては、１）は「近い」に力点があるのに対して、２）では、「近過ぎない」に力点があります。細かな部分ですが、まさにMySQLとSunの関係の変遷を反映しているのが面白いです。

ちなみに、"arm's length transaction"で検索して調べてみたところ、契約書等で使われる専門用語であることが分りました。互いに独立した主体として行う取引とのことです。翻訳では、正確を期すために「アームス・レングス取引」とする方法もありますが、これだと一般には何を言っているのか分らないという問題があります。さて、どうするか。。。

今回はIdentity Managerを使った「名寄せ」処理の実際を説明します。Identity ManagerはSunが一般企業向けに販売しているアイデンティティ管理のためのソフトウェア・パッケージです。

一般企業のアイデンティティ管理においては、個々の記録の持ち主を特定する「名寄せ」処理に付随して、その人に正しい権限を付与する処理も併せて行われます。例えば、ある職位以上の人が決裁権を持つという規則がある場合には、各自の職位属性に従って権限の付与と剥奪が「名寄せ」処理と同時に行われます。そのため、Identity Managerではこれらの処理を行う機能のことを「調整」機能と呼んでいます。各種システムの保存された個人に関するデータを照合することにより、本人を特定し、それに基づき適切な権限を付与するのが、企業向けのアイデンティティ管理製品の特徴です。「名寄せ」はその機能の一部として存在しています。

Identity Managerでは「相関規則」と「確認規則」を使って様々なシステムに散在する記録の持ち主の特定を行います。「相関規則」には、多くのシステムで管理されている、姓、名などの属性に基づき、個人を特定するための条件を記述します。企業では、この他にEMAILや従業員番号が良く使用されます。年金記録の場合は、氏名、性別および生年月日を使用しているそうです。「相関規則」を定める際に最も重要な点は、信頼できるデータを利用することです。企業の場合には、人事部で管理しているデータベースや、給与計算用のデータベースから直接データを取得できれば理想的ですが、情報の機密性から難しい場合もあります。

Identity Managerを使って「相関規則」をシステムに適用すると記録の持ち主が判ります。と、言えれば簡単ですが、実際には設定した規則が厳しすぎる場合には、持ち主がひとりも見つからない場合や、逆に緩過ぎる場合には、複数の候補（または、それらの候補が満たしている条件）が返されます。以下にそれぞれの場合について説明します。

１）ただひとりの持ち主が見つかった場合

 人事担当者などに確認をとった上で、記録と本人との結びつけを行います。企業システムでは、通常は、個人に連絡をして確認するということまでは行いません。

年金記録の場合には、本人宛に「ねんきん得別便」という確認の通知を行うそうです。これは、最終的には全国民に送られますが、初めは結び付くかもしれない記録がある人を優先するとのことです。この際、結びつく可能性がある記録を明示的に示すのではなく、確認を促すことのみを行います。実際の記録の追加や修正は本人が申し出る必要があるそうです。この点は企業のシステムとは大きく異なります。

２）持ち主の候補が複数見つかった場合

「確認規則」を利用します。「確認規則」には、複数の候補者の中から持ち主を特定するために、「相関規則」よるも細かな条件を指定します。企業のシステムでは、上司等の組織に関する情報や入社日などが良く使われます。「確認規則」を分けずに「相関規則」の一部にしてしまうことも可能ですが、これらを分離することにより、それぞれの条件を細かに変更して候補者を絞り込むことが容易になります。また、多くの場合、「確認規則」には「相関規則」に含めると処理に時間がかかり過ぎる条件を含めます。

年金の場合には払い込み期間を「確認規則」として利用することが出来るかもしれません。 確認対象の記録に対応する期間に年金を納めていたという他の記録がある人は、候補者から除いても良いと思われます。

３）持ち主の候補が全く見つからなかった場合

より緩い条件を「確認規則」に設定します。使用したデータ自体に誤りがある可能性があるからです。氏名が一文字を除いて一致し、その他の条件が完全に一致する等の条件が考えられます。どの条件を緩めるのが良いかは、どの様なデータの誤りが多いかに依存するため、試行錯誤が必要になります。緩めすぎれば、多数の候補者が抽出されるため、「確認規則」での絞り込みが難しくなります。

実際には、上記の作業を「相関規則」と「確認規則」に設定する条件を細かに変更しつつ繰り返し行うことになります。それにより、持ち主を特定できる記録を徐々に増やして行くことが可能です。

「Sun Java System Identity Manager 7.0 の配備に関する技術概要」の第３章ではActive　Directory,　SecurIDおよびSolarisに保存されたアカウントを結びつける方法について説明しています。こちらも参考にして下さい。

年金問題が毎日のようにニュースで取り上げられています。

人は誰でも年を取ります。そのため、年金問題に無関心でいられる人は少ないでしょう。私も国民のひとりとして、「もう少ししっかりやって欲しい」と心から願っています。また最近報道されることの多い「宙に浮いた」年金記録問題は、私が専門としているアイデンティティ管理（以降ID管理）の「名寄せ」と呼ばれる処理に深く関わっています。ひとりの技術者として「名寄せ」が、実際にはどのようなことを行う処理であるかを以下に説明します。それにより、問題を理解する手がかりを提供できれば、と思ったからです。

とは言っても、私自身は年金の業務に関わったことはありません。また、報道されている以上の情報も持ってはいません。しかし、「名寄せ」処理は、年金以外でも一般企業にID管理システムを導入するに際に必ず必要となるものです。実際の処理は企業毎に細かな点での相違はありますが、手順は基本的には同じです。年金は、その規模、運用してきた期間および関連するシステムの数から考えて、非常に複雑なその応用問題であると言えます。しかし基本を理解することにより、たとえ応用問題までは解けないとしても、「どこが難しいのか」を理解することは出来るようになるはずです。

言うまでもないことですが、実際にシステムを構築された方々を批判することは目的としていません。現在の技術に基づいて過去の技術を批判することはフェアではないからです。現在では、「名寄せ」処理は、パッケージ・ソフトウェアを使って簡単に行えるようになっていますが、それが過去から様々な「負の」遺産を引き継いでいる年金システムにそのまま適用できると考えるとしたら楽天的過ぎると批判されても仕方ありません。

まずは、「名寄せ」がなぜ重要であるかを説明します。当たり前のようですが、報道を見聞きする限り、十分に理解されているようには感じられないからです。「宙に浮いた」年金の前には、「消えた」年金が問題になりました。「消えた」年金問題は、納めたはずの年金の記録が無いという問題です。一方、「宙に浮いた」年金問題は、多量の年金記録が誰のものであるか、持ち主が分からなくなっているという問題です。これらは、同一の現象を異なる立場から見たものに過ぎません。国民の視点からは「消えた」ように見える記録も、実際には、その多くは存在しているはずです。ただ、持ち主が分からなくなっている記録が数多くあり、それが年金を納めた国民の側からは「消えた」ように見え、社会保険庁などの年金を管理する側には、「宙に浮いた」ように見えるだけです。そのため、これらの「宙に浮いた」年金記録の持ち主をはっきりさせる（これが「名寄せ」という処理です）ことにより、「消えた」年金の問題も、ほぼ解決することができます。「ほぼ解決」とまでしか言えないのは、本当に記録が残っていない可能性も考えられるからです。受け取ったにも関わらず記録しなかった場合や、記録を捨ててしまった場合です。しかし、それらは、ここで目的としている技術的な説明の範囲を超えています。また、ひとりの国民の立場からも、そのようなことが数多くあるとは信じたくありません。そのため「ほぼ」という言葉を用いています。

「消えた」年金と「宙に浮いた」年金は、同一現象を異なる立場から見たものであることを説明しましたが、現在では、それぞれの見方により、異なる対策が採られています。まず、「宙に浮いた」年金では、それぞれの記録を本来の持ち主に結びつける、「名寄せ」という処理が採られています。一方、「消えた」年金では、国民からの申し立てに基づき、「消えた」記録の回復を行う作業が進められています。しかし、この方法では、認定基準が「申し立て内容が明らかに不合理ではなく、一応確からしい」のような曖昧なものにならざるを得ず、最終的には「人柄や態度見て総合的に」判断することになってしまいます。これでは、迅速で正確な処理は到底期待できません。また、すべての人が申し立てを行うとは限らないため、網羅性にも問題があります。正しくは、まず、「名寄せ」を徹底的に行い、その結果を国民に知らせた後に、不審な点について国民からの申し立てを受け付けるという手順を踏むべきだと考えます。今のように、両方の作業を同時に進めるという方法では、時間とお金が費やされる割に成果が上がらないことが容易に予測できます。

次に実際の「名寄せ」処理について説明します。まず、それを行う時期についてです。企業にID管理システムを導入する場合には、通常は、構築が終わり、サービスを開始する直前に「名寄せ」が行われます。サービス開始直前は、他にも様々な作業があり、大変な時期ですが、不整合なデータを残したままID管理システムを稼動させても意味がありません。多量の監査エラーが出力されるだけのシステムになってしまいます。残念ながら、「名寄せ」を行って初めて様々なデータの不整合が明らかになることもしばしばです。これらはサービス開始を遅延させる要因となり、様々な方向から早く「名寄せ」の作業を終わらせるように圧力がかかってきます。そこを耐えて、データ整合性がとれた状態でシステムを稼動させるのが将来に禍根を残さない唯一の方法です。

 ここまでが前半です、後半では、弊社が販売しているIdentity Managerというパッケージ・ソフトウェアの機能を紹介するという方法で、「名寄せ」処理の実際を理解して頂く予定です。「名寄せ」はID管理の分野において、基本的な処理であるため、他社製品も同様な機能を持っています。ここで自社製品を例にあげるのは、製品を多くの方々に知って頂きたいという意図もありますが、それだけではなく、「名寄せ」は、現在では一般企業向けに販売されているID管理のソフトウェアに組み込まれている基本的な機能であることを理解して頂きたいからです。

日立指静脈認証をブログのカテゴリとして追加しました。

今は、Sun のAccess　Manager の認証方式として指静脈認証を使うためのモジュールを公開する準備をしています。ドキュメント等が出来たら順次こちらで公開して行く予定です。まず、入れ物を用意する、形から入ることも大切です。

それにあわせて、日立の原さんのやっている「ゆびブロ」 へのリンクも追加させて頂きました。指の夫婦？が温泉に入っている絵は大好きです。実は、「いわブロ」というタイトルも「ゆびブロ」のマネです。将来的には、クマとかタヌキが岩風呂に入っている絵を入れられたら、と思っています。

原さんには弊社Access Managerのことも紹介して頂いております。Microsoft社と一緒に紹介されていることは全く問題ありません。Microsoft社は今では弊社の大切なパートナーでもあります。私が言っても信じて貰えないかもしれないので、詳しくはCEOであるJonathanのブログを読んで下さい。

今日は私の住んでいる町の廃品回収の日でした。

廃品に限らず、日常出るゴミも、決められた時間帯に、決められた場所にきちんと出すのは、市民としての当然の義務です。そして、それは我が家では私の仕事です。毎朝、その日のゴミを確認して、家の前の所定の場所に置くことを正確に行う必要があります。最近は慣れてきたので、普通にできるようになりましたが、最初のうちは失敗もありました。

朝、カバンとゴミ袋を持って家を出るのですが、家を出たとたん会社のことを考え始めるためか、ゴミのことを忘れ勝ちです。駅の近くまで、ゴミ袋を運んでしまったこともありました。そのときは生ゴミでしたので、それをもって混んだ通勤列車に乗るわけにもいかず、家まで戻りました。目立つ色（オレンジ！）をした生ゴミの袋を持って朝の人の流れに逆らって歩くのは恥ずかしかったです。

それと言うのも、ゴミ回収車に 持っていって貰うためには、私が持っていてはダメで、所定の場所に置いて初めて正式にゴミとして認められるからです。これはJavaのGC(Garbage Collection)の仕組みと同じです。いらなくなったオブジェクトでも、それを持っている人がいる限りはゴミ回収の対象とはなりません。Javaのオブジェクトは、それへの参照が無くなって始めてGCの対象として認められます。

いらなくなったオブジェクトがそれへの参照があるために、GCの対象にならず、ヒープ・メモリ上に残ってしまうことをメモリー・リークと呼びます。これは、性能劣化の原因になるだけでなく、最悪の場合は、メモリ不足により、アプリケーションが動作不能になります。通勤列車に生ゴミを持って乗るようなものです。

長くなってしまいましたが、ここまでが前置きです。本日はSun　Tech　Days　２００７の話をするのでした。11/6-8 に開催されましたSun Tech Daysですが、盛況のうちに終了することが出来ました。ありがとうございました。資料はここからダウンロードすることが出来ます。

ここでは、ハンズオン・ラボのひとつとして行われた"Finding Memory Leaks Using the NetBeans Profiler" (NetBeans 6.0のプロファイラーを使ったメモリ・リークの検出方法）を振り返ります。手前味噌になってしまいますが、特に、Excercise 2. のNetBeansプロファイラーを使って"HttpUnit"のメモリーリークを特定する演習は出色の出来だと思います。

まず、この演習が事実に基づいていることが挙げられます。これは、スペインのAndrés Gonzálezという方がNetBeanプロファイラを使ってHttpUnitのメモリーリークを特定した事実に基づいています。実際にどう見つけたかはここから参照可能です（スペイン語ですが。。。。）。デバッガや、プロファイラ等のツールを使って問題を特定するという演習では、予めわざとらしいバグを仕込んでおいて、それを見つけさせるというものに成り勝ちです。この演習にはそのわざとらしさがありません。

さらに良い点は、問題のメモリーリークはNetBeansのプロファイラ無しでは特定困難であったことです。プロファイラの機能を十分に活用することにより、問題が解決出来ました。一般に、少量で、不定期的に起こるリークは特定が困難です。逆に定期的に大きくリークするのであれば、プロファイラ等のツール無しでも問題の特定は容易です。この演習では、エラー処理の部分で少しだけリークするためツール無しでは特定が困難なものであると言えます。

是非この演習をやってみてください。Exercise 2.だけでも十分な価値があります。正直に言うと、他の演習のなかにはわざとらしいものもあります。ソースコードや手順を含む全ての資料はここからダウンロード可能です。

最後に少しだけ、お詫びと修正です。お勧めしているExercise 2.ですが、添付のコードに少し問題があります。正確に言うと、問題がないことが問題です。メモリー・リークを修正した方のファイルを入れてしまいました。お手数ですが、ダウンロードしたZIPファイルを展開して、JavaScript.javaというファイルの２０４行目のコメントを外して下さい。

本能的に、修正を入れた方のファイルをアップロードしてしまったことが原因です。

カタカナ英語は、その元となった英語とは異なった意味で理解され、使われることが少なくありません。そのひとつが、「ダイエット」です。日本では「痩せること」という意味に理解している人が多いように感じます。私の周りでは、「痩せるための努力」と誤解しているのでは、と思われる人さえ見受けられます。

"diet"には「痩せる」という意味はありません。もともと食べ物や食事という意味ですが、規則に従って用意された美味しくないものという印象があります。"diet"が痩せることと幾分でも関連して使われるのは、食事制限の意味においてです。食べ物の量や質をコントロールすることにより、減量を図るという意味で使われることがあります。英語の表現で言えば"go on a diet"等がこれにあたります。商品名ですが"Diet Coke"も分りやすい例でしょう。日本語の使用例では、「りんごダイエット」とか「黒酢ダイエット」はまだ良いのですが、「ジョギング・ダイエット」とか「二の腕ダイエット」とかになると、わけが分らなくなってきます。

 今回のJonathanのブログで問題になったのは、次の表現です。

It's one thing for waist-conscious consumers to avoid high carb diets.

翻訳のドラフトでは『ウエスト・サイズが気になる消費者が高炭水化物ダイエッ トを避けることと、。。。』となっていましたが、これだと意味がとおりません。『ダイエットを避ける』ともっと太るのではないでしょうか。翻訳では"diets"を『ダイエット』とカタカナ表記にしているだけなので、間違いとまでは言えませんが、そもそも『ダイエット』の意味を誤解している日本の読者には分り難い表現です。そこで『高炭水化物食品を避けること』というように直しました。 『食品』という漢字を用いることにより誤解の余地はなくなったと思います。翻訳としては正しいにも関わらず、日本の読者には誤って理解される例として面白いと思いました。

今回のブログは、最新のNiagara 2 のチップが如何にエネルギー効率が良いかという話です。黒酢ダイエットや二の腕ダイエットとかとはあまり関係ありません。

私の所属する部署は、この数週間、てんてこ舞いの状態です。先週は、朝、出社すると机に突っ伏している人が見受けられました。動かないので、気にはなりましたが、時間がたつと、のろのろ動き出したので心配はなかったようです。

というのも、明日から始まるSun Tech Daysの準備のためです。最新の技術や製品を紹介する資料やデモを時間をかけて準備しました。だから、必ず来て下さい。

こう書くと、如何にも私が努力したように聞こえますが、実は何もしていないのです。しかし、当日は頑張るつもりです。「アイデンティティ管理ソリューション」の出展ブースとハンズオン・ラボにいます。「NetBeansのプロファイラを使ってメモリーリークを見つける」セッションと、「JavaFX」のセッションでは、会場を回ってラボのお手伝いをしています。

是非、来て下さい。

Jonathanのブログは日本語を含め10ヶ国語に翻訳されています。しかしその翻訳は簡単ではありません。Jonathanの新しいブログが出るたびに世界各地の翻訳者からの悲鳴が聞こえてくるようです。

翻訳を難しくしている理由のひとつがJonathanが多用する比喩です。最新の技術や業界の動向を良く理解していないと訳し損ねます。日本の読者にも比喩が正しく伝わるようにと努力しているのですが、あまり説明的になるとJonathanが比喩を使った意図からずれていってしまいます。

内容が理解出来ない場合には、インターネットで検索したり、人にたずねたりします。先日の「ボリウッド」は意味は分ったのですが、それがブログの内容とどう関連しているかについて、今ひとつ理解出来ませんでした。しかし、おかざきさんや工藤さんのおかげで疑問氷解です。確かにボリウッドにはたくさんの映像データがあるはずですので、ブログの内容　―　増えつづける映像産業のデータにSunはどう対応するか　―　に合致します。さらにその上に"Going Hollywood"という映画があったことまで指摘できれば満点かと思います。

翻訳では「ボリウッドで行こう」になっています。"Going Hollywood"からの連想では、「ボリウッドへ行こう」でも良かったかもしれませんが、実際に行くわけではないので、気弱に「で」になっています。

まもなく10月7日の翻訳が出来上がります。

そのタイトルが本日の話題です。「ボリウッド」、地名なのでそのままカタカナにしてありますが、これだと意味は分からないですよね。

調べてみるとBollywood(ボリウッド）は、Bombay（今のムンバイ）とHollywoodから成り、米国のハリウッドに対応するインドの映画産業を指す言葉であることが分かりました。しかし、Jonathanのブログの中ではBombayのこともインドの映画産業のことも触れられていません。では、なぜ、この言葉をタイトルに使ったのでしょう？これはJonathanの新たな造語ではないかというのが私の想像です。

Binary + Hollywood ! 

きっとそうだと思うのですが、根拠があるわけではありません。。。

もうじき10月1日のブログの翻訳が出来上がります。

"All the Wood Behind One Arrowhead"も"The Network is the Computer"ほどは有名ではありませんが、Sunの経営者が重要な決断をした際によく使われるスローガンのひとつです。最初は、それまで使っていたモトローラのチップを止めて、SPARCチップに注力することを宣言した際にScott McNealyによって使われました。私はそのときには社員ではなかったのですが、それがどれだけ重要な決断であったかは良く理解できます。

Sunは技術革新の会社です。技術の革新そのものは技術者によってもたらされるものですが、それをどう取捨選択して、経営資源を分配するかはSunのような会社の経営者にとって重要な決断となります。もちろん決断するだけでは不十分で、それを社内の人や組織に徹底しなければなりません。そのときに使われるのがこの"All the Wood Behind one Arrowhead"というスローガンです。その意味で、"The Network is the Computer"は外向けのメッセージであるのに対して、この"All the Wood Behind One Arrowhead"は内向けのメッセージであると言えるかもしれません。

さて今回Jonathanはどんな決断をしたのでしょうか。それはブログをお読み下さい。

昨日、日本に帰って来ました。疲れたので本日はお休みです。

床屋さんへ行こうと思って車のエンジンをかけようとしましたが、かかりません。バッテリーがあがってしまったようです。そう言えば、出張とその準備で、かなり乗っていないことに気がつきました。 仕方がないので歩いて出かけました。

今回の出張では移動や遊びでレンタカーをかなりの距離乗りました。考えてみると私の一年の走行距離よりも少し長いくらいです。もちろん運転したのは私ではありませんが。。。

これからは日本でももっと乗るようにしようと思います。そうしなければ、車も機械としてかわいそうです。

本日はMenlo Parkのオフィスで指静脈認証を使ったAccess Managerのデモを行いました。指静脈認証を見るのは初めてだという人ばかりで、指紋を使った認証とはどこが異なるのかから話を始めました。みなさん興味を持ったようで、質問が多く冷や汗でした。

最後にデモをしたのですが、 それが上手く動きませんでした。今朝、確認したときは何の問題も無く動作していたのに。。。せっかく日本から大事に持ってきたのに残念でなりません。

「こういうことはライブのデモでは良くあるんだよね。」とフォローしてくれた人がいたのはありがたかったです。

とほほ。

今週はAmbassador Conferenceに参加するためにMenlo Parkに来ています。

Ambassadorという名前のとおり色々な国の参加者がいます。内容は、新たにに開発された技術や製品の詳細説明です。とても面白いものがあるのですが、ここで紹介出来ないのが残念です。製品発表を待って下さい。
Access Managerの時期バージョンの説明にアーキテクトのPat Pattersonが来ました。そこで認証方式のひとつとして指静脈認証があることを紹介してくれました。他国の人も興味を持ってくれたようです。
開発したものはオープンソースとして公開して誰でも利用可能にする予定です。期待していてください。

私の所属する部署は近頃おめでた続きです。先日も私の同僚に赤ちゃんが誕生しました。

おめでとう！今は出張中で直接言えないのが残念です。



それもあって、最近は名前の付け方が部署内でしばしば話題になります。画数はどうだとか、いじめられやすいのではとか、呼びやすいかとか、実に様々なことが考慮の対象になります。はたから見ていても、これから親になる人の期待と不安が感じられ、微笑ましい限りです。

親が子どもに名前を付けるのとはレベルが異なりますが、プログラマにとってもプログラム中の変数や関数にどういう名前を付けるかは、身に付けなければならない大切な技能のひとつです。分かりにくい名前を付ければ、次にそれを読む人が理解し難くなるため、プログラムの保守性が下がります。プログラムの一生を左右すると言えば言い過ぎかもしれませんが。

最近、これに関連して面白いことがありました。あるプログラムは"pumpkin_hour"という変数を使っています。これは、特定の機能が動作しなくなる時間を制御するための変数なのですが、もちろん、シンデレラのかぼちゃの馬車からの連想です。私がこれを最初に見たのは、もう１０年近く前のことになります。とても印象が深かったせいか、最近またお目にかかったときに、すぐに内容を思い出しました。

このような名前の付け方が正しいか否かには議論の余地があるとは思います。全ての変数にこのような素敵な名前が付けられるはずはありません。しかし、私はこのような名前が所々に入ったプログラムを読むのが好きです。