シリコンバレー ２４時

« 2007年6月 3日 - 2007年6月 9日

メイン

2007年6月17日 - 2007年6月23日 »

2007年6月16日

Java についての調査

これから、少しずつ、Javaについても調査してみようと思うが、 今日は、まず Java に関する情報の収集方法について調査してみる。

「Java」は、ご存知のとおり、 サン・マイクロシステムズ(Sun Microsystems)社が開発した プログラミング言語である。 よって Javaに関する情報は サンが供給しているものがオリジナルとなる。 Javaについて調査していると、すぐに見つかるのが 「java.com」 であるが、これは どちらかと言うと ユーザー向けのサイトになっているようだ。 ここでは、各種OS向けの Java Runtime Environment が ダウンロードできるようになっている。

開発者向けの情報は Sun Microsystems 「The Source for Java Developers」 が本家。もちろん英語。 日本語では、 「JAVAテクノロジ」がホームページとなっているが、 詳細については、ほとんどの項目が英語サイトへのリンクとなっているようだ。 どうも、Javaの開発環境について、詳しく調査するには 英語を読むしかないようだ。 日本語としては、どちらかというと 「Sun Developer Connection（日本語版）」 の方が情報量が多いようだ。

それから Javaのチュートリアルは、もちろん英語ではあるが、 「The Java Tutorials」 からアクセスできる。 Java言語仕様は 「The Java Language Specification」 にある。現在のところ第3版になっている。 書籍として出版もされているが、 ウェブページ 「The Java Language Specification, Third Edition からでも読むことができる。 でも このサイトを読むのは よっぽどのことでもなければ読まないと思うが。

Javaに関する日本語の情報としては、＠ITの 「Java Solution」 に 多数の記事としてまとめられている。 ここにある記事を読みこなせば、立派なJavaスペシャリストになれるかもしれない。

【参考リンク】

• java.com
• Sun Microsystems 「The Source for Java Developers」
• JAVAテクノロジ（日本語）
• Sun Developer Connection（日本語版）
• The Java Tutorials
• The Java Language Specification
• The Java Language Specification, Third Edition
• ウィキペディア「Java」
• ＠IT「Java Solution」

カテゴリー: Java     22:06 | コメント (0) | トラックバック (0)

2007年6月15日

電波時計の受信には なぜ 時間がかかるのか

最近ちょうど電波時計を入手したのだが、 実際に 時間情報を受信させてみると、 結構 時間がかかっている。 その理由を探ってみた。

「日本標準時プロジェクト」 のサイト内には、 「標準周波数局の諸元」 というの掲載されている。それによると、 変調波が 1 Hz (秒信号) となっている。 これは単純に言うと、１秒間で１ビット、 つまり 1 bps の転送レートということになる。 最近のインターネットのDSLのスピードが 1Mbps とか 光ファイバーだと 100Mbps と言われているのと比較すると、 どれだけ「ゆっくり」としたスピードかが判る。

また、 「長波ＪＪＹ送信方法」 に 電波に乗せられている情報の詳細が記載されている。 それによると、 この標準電波に載せて送らなければならない情報は、

• 時: ４時間制日本標準時 ( 6 bit, 累積 6 bit)
• 分: 日本標準時の分 ( 7 bit, 累積 13 bit)
• 通算日: １月１日を１とした通算の日 ( 10 bit, 累積 23 bit)
• 年: 西暦年の下２桁 ( 8 bit, 累積 31 bit)
• 曜日: 日曜〜土曜を０〜６に割り当てた値 ( 3 bit, 累積 34 bit)
• うるう秒情報: うるう秒の有無と正負の別 ( 2 bit, 累積 36 bit)
• パリティ: 時と分に対応し、それぞれ１ビットの偶数パリティ ( 2 bit, 累積 38 bit)
• 予備ビット: 将来の拡張性用。夏時間が採用されるとこのビットを利用するようだ。 ( 2 bit, 累積 40 bit)
• 停波予告ビット: 保守作業等で標準電波の停波が予定されるときの情報( 6 bit, 累積 46 bit)

と、このように、全体のビットの合計は 46ビット。 つまり、標準電波上で これだけの情報を 送信（受信）するのに、 最低46秒は必要となる、ということだ。 実際問題として、私の電波時計では、時刻情報の取得に３分から５分ほど掛かっている。

【参考リンク】

• 日本標準時プロジェクト
• 標準周波数局の諸元
• 長波ＪＪＹ送信方法

カテゴリー: 便利グッズ・ガジェット , 通信     22:53 | コメント (0) | トラックバック (0)

2007年6月14日

電波時計 と アメリカの標準電波送信所

昨日のブログで、日本の標準電波送信所についてレポートしたが、 最近、日本で発売されている電波時計も 北米対応になってきているようだ。 それでは アメリカでの標準電波は、どうなっているのであろうか？

日本では標準電波の管理を 「独立行政法人情報通信研究機構 (NICT：National Institute of Information and Communications Technology)」 が行っている一方 アメリカでは 「NIST(National Institute of Standards and Technology)」 という組織が それを行っている。

アメリカの標準電波送信所のコールサインは「WWVB」。 コロラド(Colorado)州 フォート・コリンズ(Fort Collins)にある。 「Google Map」 で全米の地図を開いてみるとわかるが、アメリカ大陸のほぼ中央に位置している。 シリコンバレー(Silicon Valley)からすると、東北東くらいの向きになる。 ということは、電波時計を家の中で置いておく場合は、 東向きの窓際に置いておいた方が良いことになる。

この標準電波送信所「WWVB」について詳しくは、 「NIST Radio Station WWVB」 に掲載されている。 このページによると、発信周波数は60kHz。 ということは、昨日のブログで紹介した 日本国内に２つある標準電波送信所のうちの１つ、九州北部の 「はがね山標準電波送信所」 と同じ周波数ということになる。 また、空中線電力も 50kW と同じである。

考えてみると、日本の場合、 狭い国土に対し、２ヶ所の標準電波送信所があり、 それぞれが、空中線電力 50kW の出力である。 一方、アメリカの方は 広い国土にもかかわらず、 コロラド(Colorado)にある１ヶ所の標準電波送信所で 全米をカバーしよう、ということになる。 しかも空中線電力は、２つある日本の送信所の片方の送信所と同じ。 つまり、日本の半分ということになる。 感覚的に、広大なアメリカ大陸全体をカバーするなら、 もうチョット電波の出力を上げてもいいんじゃない、 っていう気がする。

【参考リンク】

• NIST(National Institute of Standards and Technology)
• NIST Radio Station WWVB
• Google Map 「フォート・コリンズ(Fort Collins)」
• はがね山標準電波送信所

カテゴリー: 便利グッズ・ガジェット , 通信     22:47 | コメント (0) | トラックバック (0)

2007年6月13日

電波時計 と 日本の標準電波送信所

先日の6月10日は「時の記念日」だったそうだが、 最近ちょうど電波時計を入手したので、 それについて調査してみた。

「電波時計」は最近 非常に普及してきたので 既にお使いの方も多いと思うが、 ご存知の通り、基準となる電波を受信して、 時刻の修正を行い、常に正確な時刻を刻み続ける時計のことである。

では一体、その電波は誰がどこから発信しているのか、という疑問がわいてくる。 調べてみると、日本国内での標準電波の発信は 「独立行政法人情報通信研究機構 (NICT：National Institute of Information and Communications Technology)」 が行っている。 実際には２つの標準電波送信所があり、 １つは、「福島局」と呼ばれている 福島県田村市都路町と双葉郡川内村境界の 大鷹鳥谷山（おおたかどややま）山頂の 「おおたかどや山標準電波送信所」。 もう一つは、「九州局」と呼ばれている 佐賀県佐賀市富士町と福岡県前原市境界の 羽金山（はがねやま）山頂の 「はがね山標準電波送信所」 である。

コールサインは「JJY」 空中線電力は それぞれ 50kWとなっている。 周波数は、福島局が「40kHz」、 九州局が「60kHz」となっており、 これは、電波の分類としては長波となる。 ちなみに通常のAMラジオの周波数が530kHz〜1600kHz であるから、どれだけ低い周波数であるかがわかる。

【参考リンク】

• 独立行政法人情報通信研究機構
• 日本標準時プロジェクト
• おおたかどや山標準電波送信所
• はがね山標準電波送信所
• カシオの電波時計技術

カテゴリー: 便利グッズ・ガジェット , 通信     22:54 | コメント (0) | トラックバック (0)

2007年6月12日

JUNBA 「行政官庁論　経済産業省 VS 文部科学省」

JUNBAの定例講演会として、 「行政官庁論　経済産業省 VS 文部科学省」 と仰々しい題目のパネル・ディスカッションが行われた。

これは、ベイエリアからこの６月末で帰任される 文部科学省の２名の方と 経済産業省の１名の方に 帰任を前にして、今までの在任期間を振り返っていただき、 今後のシリコンバレー、そして日本について 大いに語っていただこう、という企画。 さらに 折角 産業界を司る「経済産業省」と 教育界を司る「文部科学省」という 日本を代表する２つの行政官庁 の お役人に お越しいただくわけなので、 それぞれの組織の違いや、 取り組み方の違いについても、語って頂いた。

私は日本国内のことはよくわからないが、 おそらく、このような会合は 日本国内では行われたことがないのではないかと思う。

講演会では まず それぞれのパネラーに ご経歴や、シリコンバレーに赴任されるまでの経緯、 赴任後の活動等を語っていただいた。 その中には、アメリカでの子供さんの教育を通しての感想もあった。 それは、よく言われていることではあるが、 アメリカでの教育ではプレゼンテーションが重視されている、ということ。 その時の表現をお借りすると、 「トリビアの泉」の「へー」ボタンを いかに沢山 押してもらえるプレゼンテーションができるのか、ということ。 アメリカでは小学校からでも そのような教育が行われている。

その後、「経済産業省 VS 文部科学省」ということで、 経済産業省と他省との比較が議論された。 その時の資料に 中井 浩一 による 「徹底検証 大学法人化」 からの引用があった。 それを ここでいくつかご紹介させていただくと、

経産省は、外国との貿易交渉を使命とし、 広く国内全体を視野に入れて動いている官庁である。 そのために最初から横割り的な発想と行動が身についている。 それに比べると、他は縦割り行政の官庁なのだ。 そこで「攻める」経産省に「守る」他官庁という図式が構成される。 他省から見れば、経産省は自分のテリトリーに出てきているように見えるし、 経産省から見れば他は「自分の省益の範囲でしか頭が動かない」ように 見えるわけだ。

経産省の行動は、基本的に「問題提起型」だ。 現状に異議申し立てをするのが仕事なのだ。 一方、他の官庁は、基本的に「現状維持型」と言える。 経産省には、新たなプランの策定、新たな視点を絶えず提出する役割がある。 逆に言えば、それが自己確認であり、それをし続けないと、 自己を見失ってしまう官庁なのだ。

文科省は どんどん小さくなっていく。

文科省の使命は、この地方の時代への移行をスムーズに行い、 自らの「終わり」を完結することだろう。 しかし、文科省がなくなることはないだろう。 「監督官庁」としての役割を終え、情報サービスの官庁になっていくのではないか。

実際の パネル・ディスカッションも 内容を踏まえたものとなった。 その議論から、私なりに理解したことは、

• 経済産業省は他省と比べると異質な存在であり、 その原因は、他省と異なり、ビジネスの世界を対象としているためのようだ。
• 文部科学省は、確かに 経産省と比較すると保守的である。 また、いろいろな活動をやっているにも関わらず、国民からの誤解を受けやすい。 原因は PR下手。 省としてのプレゼンテーション能力に欠けているからのようだ。

なんとなく、文科省 より 経産省 の方が良い、と言った雰囲気の 論調で展開してしまったが、 将来の日本を背負う次世代の子供たちに必要なのは教育であり、 その教育を司るのは「文部科学省」であることには変わりない。 このシリコンバレーでの小さな会合が 日本の未来に少しでも お役に立つことを期待したい。

この日のJUNBA定例講演会終了後は、 親睦会を兼ねたテニス大会、それに引き続いて 帰任の御三方の送別会を兼ねての バーベキュー・パーティーとなった。

カテゴリー: JUNBA     22:43 | コメント (0) | トラックバック (0)

2007年6月11日

「Failed to enable the 'httpready' Accept Filter」エラーの AcceptFilter による解決方法

ここ数日で、FreeBSD上で Apache 2.2.x が吐き出す 「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」 というエラーへの対処方法について、その原因を調査してきた。 先日のブログで、それなりの対応方法をレポートしたが、 今日は、別の方法も探ってみる。

先日のブログでレポートした、accf_http.koをカーネルにロードする方法は、 自分で管理している場合はよいが、 これが、Jail環境等のバーチャル・サーバー環境等では、 必ずしも、accf_http.ko をカーネルにロードできるとは限らないであろう。 さて、そのような場合には、どのように対応したらよいのか？

昨日のブログで書いたとおり、 2.1.5 以降の Apache では、システムが FreeBSDだと、 デフォルトでAcceptFilterが有効となってしまうようだ。 それでは、強制的に AcceptFilter を無効にしてしまってもよいのではないだろうか。 つまり、強制的に AcceptFilter を無効にするための

AcceptFilter http none
AcceptFilter https none

の２行を httpd.conf に記述してしまえばよいのではないか。

では、実際に実験してみた。 実験なので、httpd.conf の先頭に、上記の２行を挿入し、 それから、/boot/loader.conf の

accf_http_load="YES"

を削除してから、システムをリブートしてみた。 結果として、Apacheを起動する際には何のエラーの表示されなかった。 また、確認として kldstat コマンドを実行してみたが

% kldstat
Id Refs Address    Size     Name
 1    7 0xc0400000 7a05b0   kernel
 2    1 0xc0ba1000 5c304    acpi.ko
 3    1 0xc2447000 19000    linux.ko

のように、確かに accf_http.ko は ロードされていない。

結論として、FreeBSD上で Apache 2.1.5以降 が吐き出す 「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」 エラーに対応する方法は ２通りある。 一つは、カーネル・ロードモジュール accf_http.ko をロードすること（先々日のブログ参照）。 そして、もうひとつは、今日のブログのとおり、httpd.conf に

AcceptFilter http none
AcceptFilter https none

の２行を付け加える、 という方法である。

【参考リンク】

• (FreeBSD) apache-2.2.xの「httpd -DNOHTTPACCEPT」って何だ？ 〜 accf_http
• 「AcceptFilter ディレクティブ」

カテゴリー: Apache     22:13 | コメント (0) | トラックバック (1)

2007年6月10日

Apache の AcceptFilter ディレクティブ

昨日のブログで、Apache 2.2.x が吐き出す 「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」 というエラーへの対処方法について調査したが、 今日のブログで、もう少し根本原因ついて調査してみたいと思う。

いつものごとく、いろいろググっていたら、 (FreeBSD) apache-2.2.xの「httpd -DNOHTTPACCEPT」って何だ？ 〜 accf_http というページに出くわした。このページで非常に詳しく解説してあったので、その内容に基づいて、調査を進めてゆく。

まず、上記のエラーは アパッチの 「AcceptFilter ディレクティブ」 に関係があるそうだ。 マニュアルを引用させていただくと、

Listen しているソケットに対して、 OS が固有に持っているプロトコルについての最適化を 有効にするディレクティブです。 大前提となる条件は、データが受信されるか HTTP リクエスト全体がバッファされるかするまで、 カーネルがサーバプロセスに ソケットを送らないようになっている、 ということです。 現在サポートされているのは、 FreeBSD の Accept Filter と Linux のプリミティブな TCP_DEFER_ACCEPT のみです。

とある。 そして、FreeBSD のデフォルト値は :

AcceptFilter http httpready 
AcceptFilter https dataready

である、と記述されている。 ここでやっと エラーの中にある「httpready」というキーワードがみつかった。 さらに

httpready Accept Filter は HTTP リクエスト全体を、 カーネルレベルでバッファリングします。 リクエスト全体を受信し終わると、 その後サーバプロセスにそれを送ります。 詳細については accf_http(9) を参照してください。 HTTPS のリクエストは暗号化されているので accf_data(9) フィルタのみが使用されます。

と説明されている。

それでは FreeBSDマニュアルの 「accept_filter 「入力接続フィルタ」」 をみてみる。 その解説には、

accept フィルタは、カーネルが入力接続を前処理することを、 アプリケーションが要求することを可能にします。 accept フィルタは、SO_ACCEPTFILTER の optname で渡すことで、setsockopt(2) システムコールを介して要求されます。

とある。このように、accept_filter は カーネルが入力接続を前処理するために 汎用的なしくみを提供している。 その中でも、特に HTTP に関して バッファリングを行っているのが accf_http「ある完全な HTTP リクエストの到着までの間の入力接続バッファ」 のようだ。これを有効にすると、HTTPのリクエストが全て揃うまで、カーネル側でパケットをバッファリングしておく。 リクエストの全てが揃った段階でアプリケーションサイド（この場合はApache）へパケットを受け渡すことにより、 カーネルとアプリケーション間の無駄なタスク切り替えを少なくすることができ、 結果的にCPUの利用効率を向上されることができるようだ。

以上のことから、 「[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter」 エラーの原因を考えてみる。 前述の通り、2.1.5 以降の Apache では、システムが FreeBSDだと、 デフォルトでAcceptFilterが有効となってしまうようだ。 一方、FreeBSDを普通にインストールすると、accf_http.ko がカーネルにロードされていない。 よって、FreeBSDに Apache 2.1.5 以降 をインストールすると、 このエラーに遭遇する、と考えられる。

このことから、もう一つの解決方法が考えられるが、それについては、 明日のブログとしよう。

【参考リンク】

• (FreeBSD) apache-2.2.xの「httpd -DNOHTTPACCEPT」って何だ？ 〜 accf_http
• 「AcceptFilter ディレクティブ」
• FreeBSDマニュアル「accept_filter」
• FreeBSDマニュアル「accf_http」

カテゴリー: Apache     22:41 | コメント (0) | トラックバック (0)

« 2007年6月 3日 - 2007年6月 9日

メイン

2007年6月17日 - 2007年6月23日 »