« 2007年12月 | トップページ | 2008年3月 »

2008年2月27日 (水)

日本に多元主義はありうるのか

これはまさに、利益団体の寡占独占が生み出した失敗だと思います。「公」って誰が決めるんでしょう。政府?マスコミ?ネット?

「公」は上から降ってくるものではないし、「私」と単純に区別できるものでもない。それは沢山の「私」のぶつかり合いの中からおのずと立ち上る一種の紳士協定であり、ルールです。多数の「私」による積集合が「公」になるのです。まあ唯一常に正当化される「公」があるとすれば、そういうぶつかり合い自体を阻害してはならない、ということになるでしょう。

アメリカは「セイフティネットを自前で用意する社会」である(赤の女王とお茶を)

多種多様な利益団体が、自らの信じる”公益”を主張し、ぶつかり合うことで、社会全体の公益が実現されていく社会。こういうのを多元主義と呼ぶのでしょうか。こうした面で、日本は、より混迷を深めているというのか、何が何だかわからなくなっているような気がします。

カレル・ヴァン・ウォルフレン氏によりますと、かっての日本医師会は、日本では稀有な”普通”の利益団体であったとか。

医師会は、圧力団体として日本以外の国では当然とされる機能を発揮、あるいは、それを上回る働きをして、一九五〇年代以来日本の圧力団体の中でもっともはでな存在となった。他の多くの圧力団体とは違い、医師会は、官僚を懐柔して意志を通すというやり方ではなく、官僚に真向から対決する姿勢をとった。

【略】

政治評論家や新聞の社説は、このようなことは民主的政治をくつがえそうとするものだと論評した。圧力団体は全体のための福祉を考える配慮に欠けており、自己の利益のみ図る、ごり押しをおこなうと非難された。ところが皮肉なことに日本人が圧力団体を非民主的と見ていた六〇年代に、西欧の観察者(オブザーバー)は、圧力団体がでてきたのは、ようやく日本にも”民主主義”が根付き始めたことを示すなによりの証拠として引き合いに出していたのである。八〇年代になっても、圧力団体は西欧では、より本格的な多元主義(プルーラリズム)を進展させる力とみなされている。

しかし、さらに詳しく見てみると、日本では圧力団体がかなり変わった多元主義を推進しているということが判る。医師会は例外としても、日本における力関係はちょうど逆の方向に進展する。つまり圧力団体が政府を”とりこむ”のではなくいくばくかの補助金と最小限の譲歩と引き換えに、官僚と自民党がそうした圧力団体を逆に利用することになるのである。

カレル・ヴァン・ウォルフレン 著, 篠原 勝 訳, 『日本/権力構造の謎 上』(文庫新版), 1994, 早川書房, p.141-144

「政治評論家や新聞の社説は」から「自己の利益のみ図る、ごり押しをおこなう」の部分なんて、今の話じゃないかと思えるほどでして、まあ、日本社会のメンタリティはこのころ(高度成長期)から変わってないなあ、と思います。

かっての日本医師会の”異例”であったところは、自分達の信じる”公益”を堂々と表立って主張したところではなかったか、と思います。逆に”普通”の日本の利益団体は、あまり表立ったことはせずに、政治家や官僚に、自分達の利益を代弁させていたのではないかと。日本社会では、表立って何かを主張すれば、それだけでバッシングの理由になったりしますから、政治家・官僚に”汚れ役”をやってもらう、というのが”普通”のやり方であるのかもしれません。

これが政治家・官僚、そして医師会が叩かれる理由なのかもしれない、と思ったのですが。そうすると、日本の民主主義ってのは・・・、やっぱり、なんだかよくわからない代物であります。

| | コメント (0) | トラックバック (0)

2008年2月22日 (金)

JDK API リファレンスのEclipseヘルプ化

とりあえずやってはみたのですが、便利かどうかは微妙です。

Eclipse_help_01

 

toc.xml の生成 (Java TOC Doclet)

JavaTOC ドックレットと Javadoc を実行すると、Java API リファレンス・マニュアル、目次 (TOC) ナビゲーション、そしてプラグイン構造を生成することができます。あるいは JavaTOC ドックレットだけを実行し、開発者から提供された既存のマニュアルから TOC ナビゲーションを生成することも可能です。

JavaTOC ドックレットを使って生成する Eclipse Javadoc API リファレンス構造 (IBM developerWorks)

”%JDK_HOME%\src.zip"を展開して、APIのソースコードより、Eclipseヘルプのplugin.xmlファイル、toc.xmlファイルを生成します。JDK APIのJavadocドキュメントは、Sunのサイトよりダウンロードしておきます。

コマンドは以下のようにしました。

javadoc -J"-Xmx512m" @config @options @package-list

config ファイル :

-doclet com.ibm.malup.doclet.config.TOCDoclet
-docletpath C:\JavaTOC\bin\TOCNavDoclet.jar

options ファイル :

-sourcepath ./src
-d ./output/java.doc.api
-overview ./docs/api/overview-summary.html
-version "1.5.0" -provider "Sun Microsystems"

package-list ファイル:

JDK API ドキュメントの"docs\api"フォルダにあるものを使用。

plugin.xml, toc.xml の編集

生成されるファイルなのですが、微妙に違っていて、そのままでは使えません。何箇所か手を入れます。

1. plugin.xml に、生成された toc.xml をすべて追加

Eclipseヘルプシステムは、plugin.xml に記述された toc.xml だけを認識するようです。生成された当初は、 primary.plugin.toc.xml しかありませんので、toc.xml をすべて追加します。

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

<plugin>

  <extension point="org.eclipse.help.toc">

    <toc file="primary.plugin.toc.xml" primary="true"/>
    <toc file="java.applet.toc.xml" />
    <toc file="java.awt.color.toc.xml" />
    <toc file="java.awt.datatransfer.toc.xml" />
    <toc file="java.awt.dnd.toc.xml" />
    <toc file="java.awt.event.toc.xml" />

    <!-- 中略 -->     <toc file="org.xml.sax.ext.toc.xml" />
    <toc file="org.xml.sax.helpers.toc.xml" />
    <toc file="org.xml.sax.toc.xml" />
  </extension>

</plugin>

2. primary.plugin.toc.xml に ”anchor” 要素 を追加

id="java.packages" として ”anchor” 要素 を追加 します。

<?xml version="1.0" encoding="UTF-8"?>
<?NLS TYPE="org.eclipse.help.toc"?>

<toc label="Java 2 Platform Standard Edition 5.0 API Specification">
   <topic label="Overview" href="topics/overview-summary.html" />
   <topic label="Packages">
    <anchor id="java.packages" />
   </topic>
</toc>

3. "link_to" 属性のパスを編集

toc.xml ファイルの "toc"要素 "link_to"属性にあるパスを修正します。例えば、"java.applet.toc.xml"なのですが、なぜかパスが一段上になっています。パッケージのトップレベルに該当するファイルは全部こうなってますので、修正します。

<?xml version="1.0" encoding="UTF-8"?>
<?NLS TYPE="org.eclipse.help.toc"?>

<toc label="java.applet Package" link_to="../primary.plugin.toc.xml#java.packages">

<!-- 中略 --> </toc>

以下のように、パスを揃えます。

<?xml version="1.0" encoding="UTF-8"?>
<?NLS TYPE="org.eclipse.help.toc"?>

<toc label="java.applet Package" link_to="primary.plugin.toc.xml#java.packages">

<!-- 中略 --> </toc>

4. "build.properties" ファイル

"bin.includes"に必要なファイル・フォルダを含めます。

bin.includes = META-INF/,\
               plugin.xml,\
               primary.plugin.toc.xml,\
               java.applet.toc.xml,\
               java.awt.color.toc.xml,\

               ; 中略

               org.xml.sax.ext.toc.xml,\
               org.xml.sax.helpers.toc.xml,\
               org.xml.sax.toc.xml,\
               topics/

"topics"以下に、JDK API ドキュメントの"docs\api"以下をコピーします。

5. Eclipseプラグイン・プロジェクトでテスト・ビルド

Eclipseプラグイン・プロジェクトでテストを行なった後、 jar ファイルをエクスポートして完成です。

| | コメント (0) | トラックバック (0)

2008年2月16日 (土)

モンティ・ホール問題

モンティ・ホール問題(Monty Hall problem)というのは、確率の読み物では、必ずといっていいほど、取り上げられる問題のようですね。

この問題は「Let's Make a Deal」(1960年代〜1970年代に人気を博した)というクイズ番組で、よくあった場面として紹介されているが、今日のクイズ番組でもまだ見られる状況である。「Let's Make a Deal」の司会者はモンティ・ホールで、問題の名前の由来となっている。

クイズ番組の筋書きとして、問題は次のように進行する。まず、モンティが解答者に3つのカーテンを見せる。モンティはそれぞれのカーテンの後ろに何があるかを知っていて、そのうちの1つに新車(当たりの商品)が隠されていることを説明する。残り2つのカーテンは 無価値の商品 (モンティは zonks と呼ぶ)である。ロバや巨大なロッキングチェアのようなものや、まったく役に立たないようなものがZonkとして用意されている。モンティは解答者にカーテンから1つを選ばせ、解答者はカーテンに隠されたものを獲得する。仮に、カーテンAを選んだとすると、モンティは選ばれなかったカーテン(例:カーテンB)を開けて、それがZonkだったことを示す。ここでモンティは、出場者が最初に選んだカーテンAを、最後に残ったカーテンCに変更してもよいと言うが、変更すべきだろうか?

Bruce Frey 著, 西沢 直木 訳, 『Statistics Hacks』, オライリー・ジャパン, p.152

最初に選択したものを変更しない場合、当たりを得る確率が 1/3(約33%) となり、変更した場合には、 2/3(約67%) となります。つまり、”変更すべきである”というのが答えとなります。直観的には納得し難い答えですよね。実際、この問題がとりあげられた当時、哲学者・数学者によって、相当数の反論があったとか。

私もどうも不思議の感が捨てきれないので、実際に試してみることにしました。以下のRubyプログラムは、このゲームを10万回実行して、最初に選択したものを変更しない場合の当たり数、および変更した場合の当たり数を出力します。

# monty_hall.rb
first_count = 0 second_count = 0 doors = [0, 1, 2] (1 .. 100000).each do |i|
  hit = rand(3)
  first_sel = rand(3)
  other_doors = doors - [first_sel]
  door_open = other_doors - [hit]
  door_open.delete_at(rand(2)) if door_open.size > 1
  second_sel = (other_doors - door_open)[0]

  first_count += 1 if first_sel == hit
  second_count += 1 if second_sel == hit
end puts "#{first_count}:#{second_count}"

以下が実行結果です。

>ruby monty_hall.rb
33365:66635

実際に試してみても、ちゃんと 33% と 67% になりますね。でもやっぱり不思議。

・・・

Statistics Hacks ―統計の基本と世界を測るテクニック Book Statistics Hacks ―統計の基本と世界を測るテクニック

著者:Bruce Frey
販売元:オライリー・ジャパン
Amazon.co.jpで詳細を確認する


 

| | コメント (5) | トラックバック (0)

2008年2月15日 (金)

テスト駆動開発はユニット・テストを駄目にする?

InfoQ の記事より。

Peter Ritchie recently  raised concern about what he considers a tendency for adherence to TDD and BDD to keep practitioners from writing good unit tests. In particular, it is the mantra of "interaction testing" that he suggests has the effect of creating incomplete unit tests; tests that fail to show proof that a unit - an object - works under any conditions it could potentially be used.

InfoQ: TDD/BDD Leading To Incomplete Unit Tests?

テスト駆動開発 Test Driven Development(TDD)/Behavior Driven Development(BDD)が奨めるプラクティス − 最初に、オブジェクトのインターフェイスに対してユニット・テストを書き、テストが失敗するのを確認し、オブジェクトを実装し、テストが成功するのを確認する − は、ちゃんとしたユニット・テストを作るのを妨げている、という話のようですね。

確か、”Behavior Driven Development” というのは、”テスト駆動”という言葉では誤解を招く、TDDで作成しているのは、ユニット・テストではなく、ソフトウエア・インターフェイスの”実行可能な仕様(要求)”である、という主張であったと思います。テスト駆動で開発することのメリットとして、インターフェイス仕様を明確にできる、というのは最近よく耳にする主張かと思います。ソフトウエア・デザイン的な部分を強調する方向性ですね。

元記事(の元記事になりますが)が主張しているのは、そうして作成した、一連のユニット・テスト群は、それがテストであることを明確に意識しないで作成されるがために、 テストとしては無価値になるのではないか、ということのようでして。逆に”テストとしての価値”を問い直しているようです。

TDD派からはいろいろ突っ込みが入りそうです。ちょっと、無理筋な感は否めませんけども(「それとこれとは話が別」とかね)、 ユニット・テストというものの位置付けを考える上で、必要な視点だと思います。それがテストでないなら、テストはどこでやるのか、開発工程上どう位置づけるのか、”仕様としての”ユニット・テストと、”テストとしての”ユニット・テストは、それぞれ別と考えるべきなのか、同じと考えて良いのか、といったことです。テストとプログラミングを同時にやろうとすると、注意が散漫になり、結局テストが中途半端になる、というのはわかるような気もします。

しかし、元記事の元記事で、 Wikipedia BDDエントリ から以下のサンプル・コードを取り上げていますけど、これは、あまりフェアじゃないですね。

public class PrimeNumberCalculatorTests extends junit.framework.TestCase {
   public void testIfPrimeAfter100() {
      PrimeCalculator calculator = new EratosthenesPrimesCalculator(100);
      int result = calculator.nextPrime();
      assertEquals("First prime after 100 should be 101 but is " + result, 101, result);
   }

   public void testIfFirstPrime() {
      PrimeCalculator calculator = new EratosthenesPrimesCalculator();
      int result = calculator.nextPrime();
      assertEquals("First prime should be 2 but is " + result, 2, result);
   }

   public void testIfPrimeAfter683() {
      PrimeCalculator calculator = new EratosthenesPrimesCalculator(683);
      int result = calculator.nextPrime();
      assertEquals("First prime after 683 should be 691 but is " + result, 691, result);
   }

   public void testFirst10Primes() {
      PrimeCalculator calculator = new EratosthenesPrimesCalculator();
      int[] primes = new int[] { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31 };
      for (int i = 0; i < primes.length; i++) {
         int result = calculator.nextPrime();
         assertEquals("Expected prime: [" + primes[i] + "], got: [" + result "]", primes[i], result);
      }
   }
}

このサンプル・コードに対して、以下のように書いてます。

The EratosthenesPrimesCalculator constructor interface accepts (or seems to) a signed integer.  The tests detailed only test 13 of 4,294,967,296 possibilities.  These tests may very well test the expected behaviour of one system, but don't really test EratosthenesPrimesCalculator as a unit.

Testing the Units (Peter Ritchie's MVP Blog)

4,294,967,296 の可能な入力に対して、たった 13 の入力しかテストしてない、って... まあ、そりゃ、40億くらいの入力なら全部テストできなくはないでしょうけどね。 素数表を使って、テストコードを書けば、簡単にできるでしょうし。入力が大きすぎるなら、ランダム入力でも良いかもしれません。でも、しょせんは、サンプル・コードなんですから、それじゃ、BDDのサンプル・コードとしてはねえ、といいたくなります。

ただ、このサンプル・コードのテスト・ケースが 適当すぎる のも確かですねえ。私なら、テスト・ケースはこんな感じにしますかね。

1. プログラムが処理可能な最大の素数

2. 最大の素数 + 1

3. 最大の素数 - 1

4. 適当な大きさの素数

5. 適当な大きさの素数 + 1

6. 適当な大きさの素数 - 1

7. 2, 1, 0, -1

8. プログラムが処理可能な最大の正の整数

9. プログラムが処理可能な最小の負の整数

・・・

おまけ

テストに関する本には、あまり載っていないのですが(おそらくは、あまりに初歩的すぎるから)。テストケースの作成に関する基本の基本について。

問題

IF A THEN B

上のようなプログラムがあったとして、テストケースはどのように作るべきでしょうか?

解答

まずは、

命題: Aならば、Bである

が真となることを確かめます。つまり、Aを入力してBが出力されるのを確認します。

次に、この命題の対偶命題が真となることを確認します。

対偶命題: Bでないなら、Aではない。

つまり、出力がBとならないような入力で、A以外のものを試します。なお、これは”not A”であるとは限りません(裏命題は必ずしも真ならず)。

| | コメント (0) | トラックバック (0)

2008年2月14日 (木)

オープンソースへの貢献と職務著作

Geekなぺーじ : オープンソースに貢献する日本人エンジニアが少ない理由 のコメント欄、

海外ではどうか知りませんが,「就職してから書いたプログラムは,たとえプライベートであっても著作権は会社にある」と,新入社員研修で言われました. プライベートで書いたアプリをフリーで公開したのがバレたら怒られるし,シェアウェアで公開したらすべて没収されます.  (ゆいゆい さん)

をみて、こういうのって法律上は何て呼ぶのかと疑問に思いまして。 特許での”職務発明”というのは、色々報道されていたこともあって、知っているのですが。著作権ではなんと呼ぶのか、調べてみました。

(職務上作成する著作物の著作者)

第十五条 法人その他使用者(以下この条において「法人等」という。)の発意に基づきその法人等の業務に従事する者が職務上作成する著作物(プログラムの著作物を除く。)で、その法人等が自己の著作の名義の下に公表するものの著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

2 法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

著作権法

そのままですが、”職務著作”と呼ぶそうです。会社の従業員が書いたプログラムは、一定の要件が満たされる場合には、会社の著作物になるということです。その要件というのは、プログラムの場合には、著作権法第15条2項より、以下の4点となっているようです。

1. 法人等の発意に基づく
著作物を作成する意思が直接、または間接に法人等の判断による。
2. 法人等の業務に従事する者
雇用関係にある者、法人等の指揮監督下にある者。
3. 職務上作成するプログラム
直接命令されたものの他に、業務の過程において通常予期される範囲で作成したプログラム。
4. 契約、勤務規則その他に別段の定めがない
従業員の著作物とする旨の別段の定めがない場合に限られる。

要件4については、要件1, 2, 3のいずれかを満たさない場合は、『たとえ契約等に法人等を著作者とするとの特約があったとしても、法人等が著作者となることはできない』のだそうでして、従業員の著作物とする契約等がない場合に限定する趣旨であるようです(ややこしい...)。要件2は、雇用関係があるわけですから、当然該当するのでしょう。

そうすると、要件1と要件3に該当するかどうかですね。まあ、これだけ見ても、雲をつかむような抽象的な話でして。広く解せば、プログラム開発を業としている企業に勤めていれば、どんなプログラムを書いても該当しそうにも思えますし、狭く解せば、その企業が現に行なっているプログラム開発と直接には関係のない領域でのプログラムなら、該当しなさそうにも思えます。

業務用ソフトを開発している企業の従業員が、趣味でゲームのプログラムを書く場合とかは該当しないといえるのですかねえ。フレームワークだとか、ライブラリだとか、ミドルウエアのような、何でも使いまわしがききそうなプログラムはどうなのでしょうね。文字コードの変換処理みたいなものは、ほぼジャンルを問わずに使えるわけですが。

・・・

参考

宇宙開発事業団の職員が、人工衛星打ち上げやロケットに関係するコンピュータプログラムについて職務著作にあたるか否かを争った判例です。

知的所有権判例ニュース2006-3 コンピュータプログラムの作成が職務著作に該当すると認められた事例

裁判所 裁判例情報(判例検索システム) 知的財産裁判例 平成12(ワ)27552 平成17年12月12日 東京地方裁判所

以下のページ・書籍を参考にさせていただきました。

Scope::プログラムは職務著作?

コンピュータ・ソフトウェアと法人著作権について

知的財産法 第4版 (有斐閣アルマ)Book知的財産法 第4版 (有斐閣アルマ)

著者:角田 政芳,辰巳 直彦
販売元:有斐閣
Amazon.co.jpで詳細を確認する

| | コメント (2) | トラックバック (0)

2008年2月10日 (日)

産業の保護育成

そもそも産業政策がいいとかいうけど、産業を「保護」して「育成」するという考え方自体、どこまで有効なのかもはっきりしない。だってさ、どの産業を保護すればいいのか、どうやってわかるのよ(えらきゃ日本の十年後の成長産業をいま当ててごらん。わかんないでしょ。でも産業保護育成って、それができなきゃ成立しないでしょう)。さらに保護されなきゃ成長できないような産業って、ほんとうに有望といえるの?

山形浩生著 『要するに』, 河出文庫, 2008, p.41

えっ、今後有望な産業は何かって? そんなこと官僚に聞かないでくださいよ(笑)。市場競争に勝ち残ったところがそうなるでしょう、としか。

「続・インド人がやった方が儲かることは、インド人にやらせればいいじゃん。」, bewaad institute@kasumigaseki

確かに、次の成長セクターがどこなのか、などということは、誰にも予想できないですよね。まあ、産業の成長に対して、政府ができることというのは、実際のところ、ほとんど何もないのでしょう。ただ、新たな産業が生まれて、それが成長する元といいますか、タネに政府が深く関わっているのも事実なんですよね。

例えば、現在一般に使われているコンピュータ。ノイマン型とか、プログラム内蔵方式とか呼ばれています。このコンピュータが、マンハッタン・プロジェクトの予算で開発されたというのは有名な話。原子爆弾を開発するのに、核分裂反応について大量の偏微分方程式を解く必要があり、この仕事をやらせるために、汎用計算機を開発するという、迂遠にして壮大な話でして。コンピュータが出来上がったときには、戦争はとっくに終わっていたし、原子爆弾はもちろんとうに完成していたという顛末です。

第二次世界大戦で生まれた技術が、戦後の成長産業の礎になったという説は、昔からあって、おそらく今でも有効なのだと思います。化学産業やエレクトロニクス産業、それにコンピュータ産業などが、例として挙がります。つまり、これらの産業の基礎になっている技術は、政府のカネで開発されたわけですよね。

インターネットも、もとは、冷戦下にアメリカの国防総省が開発した軍事ネットワークです。コンピュータ・ソフトウエアについても、アメリカ政府が、もっぱら軍事目的で莫大な投資をしてきたというのはあるでしょう。たしか、オペレーティング・システムも、冷戦下では、共産圏への輸出が規制されていたという話を聞いたことがあります。OSの技術開発にも、軍事予算が相当使われていたんじゃないですかね。

米ソの冷戦が終わって、NASAなどの軍事関係で働いていた技術者がリストラされて、ウォール街で雇用され、金融工学を駆使した金融商品が大量に開発されるようになった、という話もありましたか。

こう考えると、90年代以降のアメリカの成長産業というのは、冷戦下で政府が軍事目的に行なってきた膨大な投資が実を結んだといえるのではないでしょうか。

とはいえ、実際どの技術がどう役立つかなどということは、全く予想の外ではあります。いえるのは、アメリカが冷戦下に、アポロ計画だの、スターウォーズ計画だのと、壮大な計画を色々ぶち上げて、莫大なカネをばら撒いた、ということ。下手な鉄砲数打ちゃ当たるというのか、物量作戦というのか...

将来の産業について、何が有望か何が無駄かは誰にもわからないでしょうが。確実にいえるのは、何もしなければ何も生まれることはない、ということですかねえ。とにかく良さげなことを何でもいいからやってみる、というのもひとつのやり方だとは思います。

| | コメント (0) | トラックバック (0)

2008年2月 9日 (土)

Eclipseのヘルプシステム

Eclipse のヘルプ・システムについての覚え書きです。

Eclipseのヘルプ・システムに(Help > Help Contentsで)アクセスすると、実際には埋め込まれた Apache Tomcatサーバーを起動します。次にWebブラウザに基づいたウィンドウが開き、サーバー上にある適切なページを指します(図1)。文書は縮小表示できる目次が左側にあり、右側にHTML文書がある形で提供され、(ApacheのLuceneサーチエンジンのおかげで)いつでも検索ができるのです。

Eclipseのヘルプ・システムを使ってプロジェクトを文書化する (IBM developerWorks Japan)

Webサーバを裏で立ち上げていたとは... どおりでやたらと重いと思いました。非力なマシンだと、画面が固まりますからねえ。改めて、ヘルプを立ち上げてみると、ステータスバーに、

”http://127.0.0.1/何たらを開いています”

とメッセージが、ちゃんと表示されていますね。

試しに、Eclipseのヘルプを起動して、Webブラウザから、

http://127.0.0.1:61973/help/index.jsp?topic=/org.eclipse.help.base/doc/help_home.html

などと打ち込んでみると、Webブラウザでもヘルプ画面が表示されました。なお、URLのパスはEclipseのバージョンによって違うようです。ポート番号もおそらく、空いた番号を適当に使っているのだと思います。URLはEclipseヘルプの方で調べました(使っているブラウザによりますが、例えば、右クリックでメニューを出して、文書プロパティなどを調べれば分かります)。

このヘルプ・システム、単体でサーバとして起動できるみたいです。infocenter と呼ぶらしいですね。

How to start or stop infocenter from command line

The org.eclipse.help.standalone.Infocenter class has a main method that you can use to launch infocenter from a command line. The command line arguments syntax is:

-command start | shutdown | [-eclipsehome eclipseInstallPath] [-data instanceArea] [-host helpServerHost] [-locales localeList] [-port helpServerPort] [-dir rtl] [-noexec] [platform options] [-vmargs JavaVMarguments]

Installing the help system as an infocenter (dev.eclipse.org)

例えば、"c:\eclipse"にEclipseをインストールしていて、ポート 8081 で listen したい場合には、コマンドラインから以下のコマンドを実行します。クラスパスに入れている jar の名前、"org.eclipse.help.base" 何たらは、Eclipseのバージョンによって違いますので、自分の Eclipse インストール先の中をみて、実際の名前を調べました。

java -classpath C:\eclipse\plugins\org.eclipse.help.base_3.3.1.v20070813_33x.jar org.eclipse.help.standalone.Infocenter -command start -eclipsehome C:\eclipse -port 8081

これでブラウザにURL

http://localhost:8081/help/index.jsp?topic=/org.eclipse.help.base/doc/help_home.html

を入力してアクセスしてみると、ヘルプの内容がブラウザに表示されます。

サーバを停止するには、以下のように、” -command shutdown” を指定します。

java -classpath C:\eclipse\plugins\org.eclipse.help.base_3.3.1.v20070813_33x.jar org.eclipse.help.standalone.Infocenter -command shutdown -eclipsehome C:\app\eclipse -port 8081

Eclipseのメニュー、”Window”・”Preferences”・”Help”・”Content”の箇所に、”Include help content from a remote infocenter" という項目があり、 "Location"でサーバを指定するようになっています。サーバ上にヘルプを置いて、それを、各クライアントマシンのIDEから使えるようにする仕組みのようですね。

| | コメント (0) | トラックバック (0)

« 2007年12月 | トップページ | 2008年3月 »