アプレットやアプリケーションで使用される JRE は Windows コントロールパネル中の Java コントロールパネルで切り替えることができる。
http://fortunefield.blogspot.com/2005/12/thinkpad-r1-eclipse-311.html
ここでの変更は、コマンドラインや Cygwin で実行される java コマンドには影響しない。ユーザ環境変数 PATH での指定も効果がなかった。この理由は、設定した PATH の前に Windows が勝手にパスを付け加えてしまい、付け加えられる PATH の１つである
C:\WINDOWS\system32
には java.exe が存在しているからだ。そして、この java.exe は、レジストリに登録されている情報から使用する JRE の位置を取得するというわけだ。
Microsoft Windows プラットホームでの Java2 Runtime Environment
なお、javac コマンドは、system32 フォルダ中に存在しないので、ユーザ環境変数 PATH に設定したとおりに実行できた。
Thursday, March 29, 2007
Monday, March 12, 2007
Windows で "STOP 0x0000007B" エラーが出ちまった！
職場の Windows ２０００ サーバを起動しようとしたら、Blue Screen になって止まってしまった。ブートボリュームが破損していると判断し、復旧を試みる。
ドライブを取り外して、他の Windows マシンにつなぐのは面倒なので、Windows XP の OEM ディスクで CD-ROM ブートし、自動で実行されるコマンドプロンプトから
を実行。これにより、ハードディスクの不良セクタが修正され、元通りハードディスクから起動できるようになった。ちなみに、CHKDSK に指定する引数の順番に注意。オプション、ドライブ名の順でも実行できたが、復旧には失敗し、ハードディスクからのブートはできないままだった。
ドライブを取り外して、他の Windows マシンにつなぐのは面倒なので、Windows XP の OEM ディスクで CD-ROM ブートし、自動で実行されるコマンドプロンプトから
CHKDSK C: /F
を実行。これにより、ハードディスクの不良セクタが修正され、元通りハードディスクから起動できるようになった。ちなみに、CHKDSK に指定する引数の順番に注意。オプション、ドライブ名の順でも実行できたが、復旧には失敗し、ハードディスクからのブートはできないままだった。
Wednesday, February 21, 2007
信用取引メモ（買い方と売り方の関係、逆日歩など）
信用買いした株は証券会社に担保としてとられるわけだが、証券会社はその株を売り方にレンタルすることができる。
つまり、売り方にレンタルできる株は、証券会社が自分で持っている株と信用取引の買い方が担保としている株だ。トレーダーが現物買いしている株はレンタルにまわすことはできない。
買い方は、お金を借りて株を買い、その株をレンタルに出していることになる。したがって、借りた金の金利を支払い、レンタルに出した株のレンタル料を受け取ることができる。金利は必ずレンタル料より大きくなるようで、その差額が買い方が証券会社に支払う金利になる。
一方、売り方は、レンタルした株を売り、その代金を証券会社に預けているということになる。したがって、レンタルした株のレンタル料を支払い、預けた金の金利を受け取れる。買い方とは逆に、金利がレンタル料より小さくなることはなく、売り方は証券会社から支払いを受け取ることになる。金利が低い状況だと、これが 0 になることもある。
証券会社から見ると、買い方が買った株を売り方にレンタルし、買い方に貸した金は売り方が空売りした売却代金で穴埋めできることになる。全体として、買い方から売り方へ金が流れており、そこから証券会社は仲介手数料を抜き取る。先に述べたように、金利が低いと、買い方からの金を証券会社が全部とってしまうことになる。
このように、原則として、買い方から売り方へと金は流れる。ただし、例外が２つあって、それは
貸し株の需給が逼迫していると、売り方は追加のレンタル料を支払わねばならなくなる。これを逆日歩とよび、買い方に対して支払われる。
貸し株の需給状況を表すのが、信用倍率（貸借倍率）であり、信用買い残÷信用売り残、で計算される。
つまり、売り方にレンタルできる株は、証券会社が自分で持っている株と信用取引の買い方が担保としている株だ。トレーダーが現物買いしている株はレンタルにまわすことはできない。
買い方は、お金を借りて株を買い、その株をレンタルに出していることになる。したがって、借りた金の金利を支払い、レンタルに出した株のレンタル料を受け取ることができる。金利は必ずレンタル料より大きくなるようで、その差額が買い方が証券会社に支払う金利になる。
一方、売り方は、レンタルした株を売り、その代金を証券会社に預けているということになる。したがって、レンタルした株のレンタル料を支払い、預けた金の金利を受け取れる。買い方とは逆に、金利がレンタル料より小さくなることはなく、売り方は証券会社から支払いを受け取ることになる。金利が低い状況だと、これが 0 になることもある。
証券会社から見ると、買い方が買った株を売り方にレンタルし、買い方に貸した金は売り方が空売りした売却代金で穴埋めできることになる。全体として、買い方から売り方へ金が流れており、そこから証券会社は仲介手数料を抜き取る。先に述べたように、金利が低いと、買い方からの金を証券会社が全部とってしまうことになる。
このように、原則として、買い方から売り方へと金は流れる。ただし、例外が２つあって、それは
- 株の配当が支払われるとき
- 貸し株の需給が逼迫してるとき
貸し株の需給が逼迫していると、売り方は追加のレンタル料を支払わねばならなくなる。これを逆日歩とよび、買い方に対して支払われる。
貸し株の需給状況を表すのが、信用倍率（貸借倍率）であり、信用買い残÷信用売り残、で計算される。
Sunday, February 11, 2007
PostgreSQL 8.1.5 の設定
先日、インストールしたので、設定を進めてみた。昔 7.2 をセットアップしたときのメモや Web 上でのオンラインドキュメントを参考に
ユーザ、データベースの作成は、7.2 の頃と同様にできた。PostgreSQL 管理者ユーザで
のようにすればいい。このとき、7.2 のときと同様にデータベース作成の権限、ユーザ作成の権限を与えるかどうかが聞かれるが、新しく superuser の権限を与えるかどうかも聞かれた。
このままだとクライアント認証のときにパスワード認証ができないので、PostgreSQL 管理者ユーザで template1 データベースに psql コマンドで接続し、ALTER USER 文でパスワードを設定した。template1 データベースというのは、もともとある管理用のデータベース。7.2 と同じようにできた。
オンラインマニュアルにしたがい、pg_hba.conf を編集することでクライアント認証（ホストベースのアクセス認証）をセットアップした。
Unix ドメイン経由の接続だけでなく TCP/IP 経由の接続を認めるには、pg_hba.conf を設定するだけでなく、postmaster を起動するときに -i オプションをつけなければならない。これにより、TCP/IP 接続を受け付けるようになる。もちろん、TCP/IP 接続が成功してはじめて、サーバがクライアント認証をチェックすることができるようになる。
7.2 のころはソースからビルドしたときに JDBC ドライバが作成されたはずだが、今回はそうではなかった。PostgreSQL の JDBC サイトから、PostgreSQL と JDBC のバージョンにあったものをダウンロードした。JDBC 3 のドライバを入手した。ここで作成されているドライバは Type4 だ。つまり Pure Java であるから、どのプラットホームでも使うことが可能だ。
- ユーザとデータベースの作成
- クライアント接続とセキュリティの設定
- JDBC ドライバのセットアップ
ユーザ、データベースの作成は、7.2 の頃と同様にできた。PostgreSQL 管理者ユーザで
$ createuser user_name
のようにすればいい。このとき、7.2 のときと同様にデータベース作成の権限、ユーザ作成の権限を与えるかどうかが聞かれるが、新しく superuser の権限を与えるかどうかも聞かれた。
このままだとクライアント認証のときにパスワード認証ができないので、PostgreSQL 管理者ユーザで template1 データベースに psql コマンドで接続し、ALTER USER 文でパスワードを設定した。template1 データベースというのは、もともとある管理用のデータベース。7.2 と同じようにできた。
オンラインマニュアルにしたがい、pg_hba.conf を編集することでクライアント認証（ホストベースのアクセス認証）をセットアップした。
Unix ドメイン経由の接続だけでなく TCP/IP 経由の接続を認めるには、pg_hba.conf を設定するだけでなく、postmaster を起動するときに -i オプションをつけなければならない。これにより、TCP/IP 接続を受け付けるようになる。もちろん、TCP/IP 接続が成功してはじめて、サーバがクライアント認証をチェックすることができるようになる。
7.2 のころはソースからビルドしたときに JDBC ドライバが作成されたはずだが、今回はそうではなかった。PostgreSQL の JDBC サイトから、PostgreSQL と JDBC のバージョンにあったものをダウンロードした。JDBC 3 のドライバを入手した。ここで作成されているドライバは Type4 だ。つまり Pure Java であるから、どのプラットホームでも使うことが可能だ。
Saturday, February 10, 2007
信用取引メモ（委託証拠金率）
信用取引では、証券会社に担保となる委託証拠金を差し入れ、信用買い、または空売りをすることができる。空売りのことをショート・ポジション、信用買いや現物買いをロング・ポジションをとるという。株価が上がると利益になるポジションをロング、下がると利益になるポジションをショート、というわけだ。
委託証拠金は最低でも100万から200万程度を用意しなければならない。金額は証券会社によって異なる。昔は2000万円ほど必要だったりしたようだ。
ポジションをとるとき、建玉の総額に対する証拠金の比率が委託証拠金率となる。たとえば、100万円の証拠金に対し、200万円信用買い（つまり、200万円分の株を買う）か200万円空売り（つまり、200万円分の株を借りてきて売る）すると、100 万/200万 = 0.5 = 50% となり、証拠金率は 50% ということになる。逆に見れば100万円しか用意していないのに200万円の取引をしていることになり、2倍のレバレッジを効かせていることになる。すなわち、委託証拠金率の逆数がレバレッジ率ということになる。
委託証拠金は現金で用意してもいいが、利息はつかないので、不利である。そこで現金の代わりに債券や株式で用意してもいい。これらを代用有価証券という。ただし、値下がりのリスクがあるので有価証券の時価そのままで評価することはせず、いくらか割り引いた価格で評価される。何割で評価されるかということを掛目とよぶ。国債などは90から95%、東証上場株式などは８０％程度で評価される。
委託証拠金率 = 委託証拠金の評価額 / 建玉総額
であった。いったん信用取引をしたらポジションを変更しない限り、建玉総額は変わらない。ただし、委託証拠金の評価額は変わりうる。
まず、委託証拠金を有価証券で差し入れている場合は、価格の変動によって評価額が変わってくる。
また、建玉の損益によっても評価額が変わる。たとえば、ロング・ポジションとして200万円もっていて、それが１０％値下がりしたとすると、20万円の損失である。同様にショート・ポジションとして200万円もっていたとして、その銘柄が10%値上がりしたとすると 20万円の損失である。委託証拠金からこの損失分を引いたものが評価額となる。
ということは、建玉で利益が出たなら委託証拠金の評価額が上がるはずだが、オンライン証券会社ではそうはしないことが多いようだ。まとめると、
委託証拠金の評価額 = 委託証拠金の時価 + 建玉の損益 - 取引手数料
となる。
さて、前述したように委託証拠金率の逆数がレバレッジ率であった。そこで、証券会社では委託証拠金率の最低ラインを決めることによって顧客のレバレッジ率の上限を定めている。証拠金率を50%にするということは、顧客が2倍までレバレッジを効かせることを認めるということだ。40%にしたなら、2.5倍までのレバレッジを認めることになる。顧客の委託証拠金率がこのラインを下回ると証券会社は新たな建玉を認めなくなる。
証拠金率があまりに下がり過ぎると、証券会社はリスク回避のために顧客に委託証拠金の増額を求めてくる。これが追証（Margin call）である。この証拠金率を最低証拠金維持率と呼ぶ。制度信用取引では 30% に定められている。
さらに、顧客が追証にも応じず、証拠金率が下がり続け、20% を下回ったとき、証券会社は顧客のポジションを強制的に解消することができる。買い玉だったら、そのときの株価で売ってしまい、金を返してもらうことができる。売り玉なら、そのときの株価で株を買ってきて、レンタルしていた株を返してもらうことができる。
たとえば、委託証拠金として 125万円の株を差し入れれば掛目 80% として 100万円相当になる。そして、200万円の株を信用買いしたとする。このとき委託証拠金率は 50% である。その後、証拠金として差し入れていた株が20%下落し、信用買いした株も 20% 下落したとする。
このとき、委託証拠金の評価額は (125万 * 0.8 * 0.8) - (200万 * 0.2) = 40万 となり、委託証拠金率は、 40万 / 200 万 = 0.2 = 20% になってしまう。すなわち、証券会社に強制的に建玉を決済されてしまう。
この例だと、買玉をすべて売り払って 160万 を確保する。40万足りないから（証券会社は最初に 200万貸している）、代用有価証券も売り払って 100万を新たにつくり、そこから 40万円回収する。
したがって、証拠金率を一定以上に維持しなければならないのだが、そのためには、
の2点が絶対に必要になる。
ここで少し考えてみたのだが、委託証拠金率が 0 にならない限り、証券会社が貸した金やレンタルした株を回収できなくなることはないはずである。
なぜなら、証拠金率 > 0 ということは、
委託証拠金の評価額 = 委託証拠金の時価 - 建玉の損失 > 0
ということである（取引手数料は捨象）。回収しなければならないのは、建玉総額であり、建玉を処分しても足りない部分、すなわち、建玉の損失分は、委託証拠金の評価額でまかなえることが分かる。
つまり、委託証拠金率というのは、建玉をすべて決済し、貸した金やレンタルした株を回収した後に残る金額が建玉総額に占める割合だということもできる（証拠金が有価証券なら掛目だけ割り引いているので、決済後に残る金額が建玉総額に占める割合は委託証拠金率よりも高くなる）。
今までは金利のことは考えなかったが、当然、信用取引には金利がかかる。
一般信用取引では、証券会社が顧客と相対取引する。制度信用では、証券会社は顧客と証券金融会社との間を仲介するだけである。したがって、制度信用では、金利の他、返済期限や信用取引可能な銘柄（貸借銘柄）は証券金融会社や取引所が一律に決めている。一般信用の場合は、証券会社ごとに決めることができる。
委託証拠金は最低でも100万から200万程度を用意しなければならない。金額は証券会社によって異なる。昔は2000万円ほど必要だったりしたようだ。
ポジションをとるとき、建玉の総額に対する証拠金の比率が委託証拠金率となる。たとえば、100万円の証拠金に対し、200万円信用買い（つまり、200万円分の株を買う）か200万円空売り（つまり、200万円分の株を借りてきて売る）すると、100 万/200万 = 0.5 = 50% となり、証拠金率は 50% ということになる。逆に見れば100万円しか用意していないのに200万円の取引をしていることになり、2倍のレバレッジを効かせていることになる。すなわち、委託証拠金率の逆数がレバレッジ率ということになる。
委託証拠金は現金で用意してもいいが、利息はつかないので、不利である。そこで現金の代わりに債券や株式で用意してもいい。これらを代用有価証券という。ただし、値下がりのリスクがあるので有価証券の時価そのままで評価することはせず、いくらか割り引いた価格で評価される。何割で評価されるかということを掛目とよぶ。国債などは90から95%、東証上場株式などは８０％程度で評価される。
委託証拠金率 = 委託証拠金の評価額 / 建玉総額
であった。いったん信用取引をしたらポジションを変更しない限り、建玉総額は変わらない。ただし、委託証拠金の評価額は変わりうる。
まず、委託証拠金を有価証券で差し入れている場合は、価格の変動によって評価額が変わってくる。
また、建玉の損益によっても評価額が変わる。たとえば、ロング・ポジションとして200万円もっていて、それが１０％値下がりしたとすると、20万円の損失である。同様にショート・ポジションとして200万円もっていたとして、その銘柄が10%値上がりしたとすると 20万円の損失である。委託証拠金からこの損失分を引いたものが評価額となる。
ということは、建玉で利益が出たなら委託証拠金の評価額が上がるはずだが、オンライン証券会社ではそうはしないことが多いようだ。まとめると、
委託証拠金の評価額 = 委託証拠金の時価 + 建玉の損益 - 取引手数料
となる。
さて、前述したように委託証拠金率の逆数がレバレッジ率であった。そこで、証券会社では委託証拠金率の最低ラインを決めることによって顧客のレバレッジ率の上限を定めている。証拠金率を50%にするということは、顧客が2倍までレバレッジを効かせることを認めるということだ。40%にしたなら、2.5倍までのレバレッジを認めることになる。顧客の委託証拠金率がこのラインを下回ると証券会社は新たな建玉を認めなくなる。
証拠金率があまりに下がり過ぎると、証券会社はリスク回避のために顧客に委託証拠金の増額を求めてくる。これが追証（Margin call）である。この証拠金率を最低証拠金維持率と呼ぶ。制度信用取引では 30% に定められている。
さらに、顧客が追証にも応じず、証拠金率が下がり続け、20% を下回ったとき、証券会社は顧客のポジションを強制的に解消することができる。買い玉だったら、そのときの株価で売ってしまい、金を返してもらうことができる。売り玉なら、そのときの株価で株を買ってきて、レンタルしていた株を返してもらうことができる。
たとえば、委託証拠金として 125万円の株を差し入れれば掛目 80% として 100万円相当になる。そして、200万円の株を信用買いしたとする。このとき委託証拠金率は 50% である。その後、証拠金として差し入れていた株が20%下落し、信用買いした株も 20% 下落したとする。
このとき、委託証拠金の評価額は (125万 * 0.8 * 0.8) - (200万 * 0.2) = 40万 となり、委託証拠金率は、 40万 / 200 万 = 0.2 = 20% になってしまう。すなわち、証券会社に強制的に建玉を決済されてしまう。
この例だと、買玉をすべて売り払って 160万 を確保する。40万足りないから（証券会社は最初に 200万貸している）、代用有価証券も売り払って 100万を新たにつくり、そこから 40万円回収する。
したがって、証拠金率を一定以上に維持しなければならないのだが、そのためには、
- 建玉総額とその損益の管理 = 建玉管理（ポジション・コントロール）
- 委託証拠金の時価の管理 = 資産管理（アセット・マネジメント）
の2点が絶対に必要になる。
ここで少し考えてみたのだが、委託証拠金率が 0 にならない限り、証券会社が貸した金やレンタルした株を回収できなくなることはないはずである。
なぜなら、証拠金率 > 0 ということは、
委託証拠金の評価額 = 委託証拠金の時価 - 建玉の損失 > 0
ということである（取引手数料は捨象）。回収しなければならないのは、建玉総額であり、建玉を処分しても足りない部分、すなわち、建玉の損失分は、委託証拠金の評価額でまかなえることが分かる。
つまり、委託証拠金率というのは、建玉をすべて決済し、貸した金やレンタルした株を回収した後に残る金額が建玉総額に占める割合だということもできる（証拠金が有価証券なら掛目だけ割り引いているので、決済後に残る金額が建玉総額に占める割合は委託証拠金率よりも高くなる）。
今までは金利のことは考えなかったが、当然、信用取引には金利がかかる。
一般信用取引では、証券会社が顧客と相対取引する。制度信用では、証券会社は顧客と証券金融会社との間を仲介するだけである。したがって、制度信用では、金利の他、返済期限や信用取引可能な銘柄（貸借銘柄）は証券金融会社や取引所が一律に決めている。一般信用の場合は、証券会社ごとに決めることができる。
Saturday, January 20, 2007
PostgreSQL 8.1.5 をインストール
Ubuntsu 6.06.1 にインストール。サーバガイドにあるように apt-get でインストールしようとしたのだが、「使用できるパッケージがない」 というようなことを言われた。
そこで、ソースをダウンロードしてきてビルドしたのだが、下にあるようにいろいろ問題が発生した。なんとか解決したけど。。。
./configure --prefix=/opt/pgsql
を実行。7.2 のときとは違って、--with-mb=EUC_JP オプションは指定しなくていい。7.3 以降からデフォルトでマルチバイト文字対応がなされている。
configure を実行中、libreadline.so がないというエラーが出た。これは linker name が定義されていないためだと分かったので、/lib/libreadline.so というシンボリックリンクを /lib/libreadline.so.5 に張ってやった。
しかし今度は、readline/readline.h がないというエラーが発生。仕方ないのでヘッダファイルのためだけに libreadline ライブラリ を /usr/local/lib/ に新たにインストールした。/lib/ に作った linker name は消して、/usr/local/lib/ に新たに linker name をつくったが、今度もエラーになった。config.log を見ると
/usr/local/lib/libreadline.so: undefined reference to `tgetnum'
/usr/local/lib/libreadline.so: undefined reference to `tgoto'
/usr/local/lib/libreadline.so: undefined reference to `tgetflag'
/usr/local/lib/libreadline.so: undefined reference to `BC'
/usr/local/lib/libreadline.so: undefined reference to `tputs'
/usr/local/lib/libreadline.so: undefined reference to `PC'
/usr/local/lib/libreadline.so: undefined reference to `tgetent'
/usr/local/lib/libreadline.so: undefined reference to `UP'
/usr/local/lib/libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
というメッセージがある。どうも、新たに入れた libreadline が依存しているライブラリがあるようなのだ。仕方ないので、新しく入れた libreadline は使わずにヘッダファイルだけ使うことにして、linker name は /lib/ にもう一度作り直した。
しかし、
configure:7805: ./conftest
./conftest: symbol lookup error: /usr/local/lib/libreadline.so.5: undefined symbol: BC
configure:7808: $? = 127
configure: program exited with status 127
というエラーが出た。どうも /usr/local/lib/ のを見に行っている。ldconfig をやり直してみたがうまくいかない。仕方ないので、/usr/local/lib/libreadline.so.5 を削除したら、うまくいくようになったが、ldconfig をルートで実行すると、また同じエラーになる。仕方ないので /usr/local/lib/libreadline.* はすべて削除した。ヘッダファイルは、/usr/local/include/readline/ 内に残っているので、これでうまくいくようになった。
libz でも同じ問題が出たので、/usr/lib/ に linker name を作成し、ヘッダファイルがないのは、ダウンロードしてきてビルドすることで /usr/local/include/ にヘッダファイルが作成されて解決した。このとき/usr/local/lib/ にも静的ライブラリが作成された。ま、害はないので放置。
これでうまくいったので、
make
su
make install
でインストール。 --prefix=/opt/pgsql で指定したディレクトリは自動で作成された。
管理用ユーザ postgres を作成。PGDATA 等の環境変数も設定した。
そして、
# mkdir /opt/pgsql/data
# chwon postgres /opt/pgsql/data
のようにして、データベースクラスタとなるディレクトリを作成。その後、postgres ユーザで
$ initdb -E EUC_JP
としてデータベースクラスタを作成。デフォルトの文字セットとして EUC_JP を指定している。これは、createdb でデータベースを作成するときに同じオプションを使って文字セットを変更することもできる。initdb にはロケールも指定できるが、ここでは指定していない。
postgres ユーザで
$ postmaster -S
としてデータベースサーバを実行。これでデータベースクラスタに接続できるようになる。この後、postgresql-8.1.5/src/test/regress/ に移動し、
$ make installcheck
でリグレッションテストを行い、すべて OK であることを確認した。この際、ソースは別ユーザで展開してビルドしたので、postgresql-8.1.5/ 以下の所有者を一時的に postgres に変更してリグレッションテストを実行した。
そこで、ソースをダウンロードしてきてビルドしたのだが、下にあるようにいろいろ問題が発生した。なんとか解決したけど。。。
./configure --prefix=/opt/pgsql
を実行。7.2 のときとは違って、--with-mb=EUC_JP オプションは指定しなくていい。7.3 以降からデフォルトでマルチバイト文字対応がなされている。
configure を実行中、libreadline.so がないというエラーが出た。これは linker name が定義されていないためだと分かったので、/lib/libreadline.so というシンボリックリンクを /lib/libreadline.so.5 に張ってやった。
しかし今度は、readline/readline.h がないというエラーが発生。仕方ないのでヘッダファイルのためだけに libreadline ライブラリ を /usr/local/lib/ に新たにインストールした。/lib/ に作った linker name は消して、/usr/local/lib/ に新たに linker name をつくったが、今度もエラーになった。config.log を見ると
/usr/local/lib/libreadline.so: undefined reference to `tgetnum'
/usr/local/lib/libreadline.so: undefined reference to `tgoto'
/usr/local/lib/libreadline.so: undefined reference to `tgetflag'
/usr/local/lib/libreadline.so: undefined reference to `BC'
/usr/local/lib/libreadline.so: undefined reference to `tputs'
/usr/local/lib/libreadline.so: undefined reference to `PC'
/usr/local/lib/libreadline.so: undefined reference to `tgetent'
/usr/local/lib/libreadline.so: undefined reference to `UP'
/usr/local/lib/libreadline.so: undefined reference to `tgetstr'
collect2: ld returned 1 exit status
というメッセージがある。どうも、新たに入れた libreadline が依存しているライブラリがあるようなのだ。仕方ないので、新しく入れた libreadline は使わずにヘッダファイルだけ使うことにして、linker name は /lib/ にもう一度作り直した。
しかし、
configure:7805: ./conftest
./conftest: symbol lookup error: /usr/local/lib/libreadline.so.5: undefined symbol: BC
configure:7808: $? = 127
configure: program exited with status 127
というエラーが出た。どうも /usr/local/lib/ のを見に行っている。ldconfig をやり直してみたがうまくいかない。仕方ないので、/usr/local/lib/libreadline.so.5 を削除したら、うまくいくようになったが、ldconfig をルートで実行すると、また同じエラーになる。仕方ないので /usr/local/lib/libreadline.* はすべて削除した。ヘッダファイルは、/usr/local/include/readline/ 内に残っているので、これでうまくいくようになった。
libz でも同じ問題が出たので、/usr/lib/ に linker name を作成し、ヘッダファイルがないのは、ダウンロードしてきてビルドすることで /usr/local/include/ にヘッダファイルが作成されて解決した。このとき/usr/local/lib/ にも静的ライブラリが作成された。ま、害はないので放置。
これでうまくいったので、
make
su
make install
でインストール。 --prefix=/opt/pgsql で指定したディレクトリは自動で作成された。
管理用ユーザ postgres を作成。PGDATA 等の環境変数も設定した。
そして、
# mkdir /opt/pgsql/data
# chwon postgres /opt/pgsql/data
のようにして、データベースクラスタとなるディレクトリを作成。その後、postgres ユーザで
$ initdb -E EUC_JP
としてデータベースクラスタを作成。デフォルトの文字セットとして EUC_JP を指定している。これは、createdb でデータベースを作成するときに同じオプションを使って文字セットを変更することもできる。initdb にはロケールも指定できるが、ここでは指定していない。
postgres ユーザで
$ postmaster -S
としてデータベースサーバを実行。これでデータベースクラスタに接続できるようになる。この後、postgresql-8.1.5/src/test/regress/ に移動し、
$ make installcheck
でリグレッションテストを行い、すべて OK であることを確認した。この際、ソースは別ユーザで展開してビルドしたので、postgresql-8.1.5/ 以下の所有者を一時的に postgres に変更してリグレッションテストを実行した。
Tuesday, January 16, 2007
Windows で Tomcat
Tomcat 5.5 をインストールしてみた。サイトから Windows 用の Installer ファイルをダウンロードしてきて実行するだけなのでインストールは簡単にできる。
インストール時に admin 用のパスワードが聞かれるのでそれに答える。
「スタート」 から Tomcat をインストールしたディレクトリを開いて、bin\tomcat5.exe をダブルクリックすると Tomcat が起動し、インストール時に指定したポートでリクエストを待つようになる。この後、同じように 「スタート」 からアクセスできる Tomcat Manager をクリックすると、Web アプリケーションマネージャという管理用の Web アプリケーションを実行することができる。この際、admin 用のパスワードが聞かれる。
Tomcat の起動は、「スタート」 からアクセスできる Monitor Tomcat をクリックしてもいい。そうすると、ステータスバーにアイコンが表示される。ここを右クリックすることで、Tomcat 起動、その他の操作をすることができる。exe ファイルをダブルクリックするよりもこの方がいい。
Tomcat Manager における配備のところで、Web アプリケーションを配備することができる。いくつかやり方はあるが、Context Path で /hogehoge のように任意のパスを指定する。そして、「War ファイルまたはディレクトリのパス」 で war ファイル、またはWeb アプリケーションのルートとなるディレクトリのパスを指定すればいい。
Eclipse 上で Web アプリケーションをビルドできるようにプロジェクトを構成してやれば、上のようにしてテストすることができる。
インストール時に admin 用のパスワードが聞かれるのでそれに答える。
「スタート」 から Tomcat をインストールしたディレクトリを開いて、bin\tomcat5.exe をダブルクリックすると Tomcat が起動し、インストール時に指定したポートでリクエストを待つようになる。この後、同じように 「スタート」 からアクセスできる Tomcat Manager をクリックすると、Web アプリケーションマネージャという管理用の Web アプリケーションを実行することができる。この際、admin 用のパスワードが聞かれる。
Tomcat の起動は、「スタート」 からアクセスできる Monitor Tomcat をクリックしてもいい。そうすると、ステータスバーにアイコンが表示される。ここを右クリックすることで、Tomcat 起動、その他の操作をすることができる。exe ファイルをダブルクリックするよりもこの方がいい。
Tomcat Manager における配備のところで、Web アプリケーションを配備することができる。いくつかやり方はあるが、Context Path で /hogehoge のように任意のパスを指定する。そして、「War ファイルまたはディレクトリのパス」 で war ファイル、またはWeb アプリケーションのルートとなるディレクトリのパスを指定すればいい。
Eclipse 上で Web アプリケーションをビルドできるようにプロジェクトを構成してやれば、上のようにしてテストすることができる。
Wednesday, January 10, 2007
memcached インストール
memcached 1.2.1 をインストールしてみた。
http://www.danga.com/memcached/
ダウンロード・解凍し、README を読んでみると、libevent というライブラリが必要であり、libevent は epoll を実装したカーネルに依存するとある（Linux の場合）。epoll は必須というわけではなく、libevent は通常の select システムコールを使っても動くらしいが、その選択はいいとはいえないらしい。
http://www.linux.or.jp/JM/html/LDP_man-pages/man7/epoll.7.html
Linux カーネル 2.6 以降なら epoll は実装されているようで、これは問題なかった。
libevent 1.2a をダウンロードして、インストール。
http://www.monkey.org/~provos/libevent/
README にしたがい、
でインストール。最後のは、Regression テスト。これで /usr/local/lib/ にインストールされた。また、/usr/local/bin/ に event_rpcgen.py という Python スクリプトもインストールされる。
この後、memcached も次のようにインストール。
これで /usr/local/bin/ に memcached と memcached-debug というコマンドがインストール。
以上が済んで、
とすると、
というエラーメッセージが出た。どうも先にインストールした libevent を見つけることができないようだ。実際、
とやっても、libevent は出てこない。/usr/local/lib は /usr/lib, /lib と違って、常に検索されるライブラリではないからだ。そこで、/etc/ld.so.conf を作成し、そこに ld.so.conf を記述し、ldconfig を実行した。こうすると、/etc/ld.so.cache に登録されるので、検索されるようになる。実際、ldconfig -p で確認できた。
その後、
とすると、起動できた。-d オプションをつけるとデーモンになる。
で接続はできることを確認。後はクライアント API をセットアップしていろいろ試そう。
http://www.danga.com/memcached/
ダウンロード・解凍し、README を読んでみると、libevent というライブラリが必要であり、libevent は epoll を実装したカーネルに依存するとある（Linux の場合）。epoll は必須というわけではなく、libevent は通常の select システムコールを使っても動くらしいが、その選択はいいとはいえないらしい。
http://www.linux.or.jp/JM/html/LDP_man-pages/man7/epoll.7.html
Linux カーネル 2.6 以降なら epoll は実装されているようで、これは問題なかった。
libevent 1.2a をダウンロードして、インストール。
http://www.monkey.org/~provos/libevent/
README にしたがい、
$ ./configure && make
# make install
$ make verify
でインストール。最後のは、Regression テスト。これで /usr/local/lib/ にインストールされた。また、/usr/local/bin/ に event_rpcgen.py という Python スクリプトもインストールされる。
この後、memcached も次のようにインストール。
$ ./configure --with-libevent=/usr/local/lib/
$ make
# make install
これで /usr/local/bin/ に memcached と memcached-debug というコマンドがインストール。
以上が済んで、
$ memcached -m 256 -l 127.0.0.1 -p 11211
とすると、
memcached: error while loading shared libraries: libevent-1.2a.so.1: cannot open shared object file: No such file or directory
というエラーメッセージが出た。どうも先にインストールした libevent を見つけることができないようだ。実際、
$ ldconfig -p
とやっても、libevent は出てこない。/usr/local/lib は /usr/lib, /lib と違って、常に検索されるライブラリではないからだ。そこで、/etc/ld.so.conf を作成し、そこに ld.so.conf を記述し、ldconfig を実行した。こうすると、/etc/ld.so.cache に登録されるので、検索されるようになる。実際、ldconfig -p で確認できた。
その後、
$ memcached -m 256 -l 127.0.0.1 -p 11211
とすると、起動できた。-d オプションをつけるとデーモンになる。
$ telnet localhost 11211
で接続はできることを確認。後はクライアント API をセットアップしていろいろ試そう。
Tuesday, January 09, 2007
Eclipse でワークスペースにデフォルトの文字コード、改行コードを設定するには？
Window メニューから 「Preferences」 を選び、そこで Workspace を選択する。そこにある Text file encoding と New text file line delimiter でワークスペースデフォルトにしたいものを選択する。
Eclipse 上のエディタで、ファイルの内容すべてをコピーし、その後、そのファイルの Preferences で文字コードを変更し、オープンし直してから、ペーストするとファイルの文字コードを変換することができる。しかし、うっかり改行コードのことを忘れていると、Unix のシェルスクリプトの改行コードを Dos/Windows 風にしてしまい、いざ実行しようとして実行できない現象に悩まされたりするので要注意。今日は、まさにこれにはまってしまった。
Eclipse 上のエディタで、ファイルの内容すべてをコピーし、その後、そのファイルの Preferences で文字コードを変更し、オープンし直してから、ペーストするとファイルの文字コードを変換することができる。しかし、うっかり改行コードのことを忘れていると、Unix のシェルスクリプトの改行コードを Dos/Windows 風にしてしまい、いざ実行しようとして実行できない現象に悩まされたりするので要注意。今日は、まさにこれにはまってしまった。
改行コードが Unix 風でないとシェルスクリプトが動かない件について
Unix の改行コードは LF（\n）、Dos/Windows の改行コードは CRLF（\r\n） になるのが普通だが、改行コードが LF でないと Unix のシェルスクリプトがうまく動かない場合がある。改行コードが CRLF だと vi で開いたときに行末に ^M という文字が出ることが多いが、そうならずにきれいに表示される vi もあるので、そのために原因が分かりにくいときがあるので要注意。
今日はそれではまってしまった。シマリンによると Perl スクリプトでも改行コードが原因でうまくいかないことが多いらしい。
同じことは、文字コードの食い違いでも発生する場合がある。慎重を期すなら、スクリプト実行前にシェルの環境変数を設定するなどして文字コードをスクリプトで使っている文字コードにあわせるべきだろう。
今日はそれではまってしまった。シマリンによると Perl スクリプトでも改行コードが原因でうまくいかないことが多いらしい。
同じことは、文字コードの食い違いでも発生する場合がある。慎重を期すなら、スクリプト実行前にシェルの環境変数を設定するなどして文字コードをスクリプトで使っている文字コードにあわせるべきだろう。
Sunday, January 07, 2007
Subversion でのマージについてのメモ
マージには、次の３つのものが関係してくる。
マージがうまくいけば、マージ結果だけが作業領域に残る。しかし、うまく２つの差分がコンフリクトして、うまくマージできなかったときは、マージが適用されたファイル中に衝突マーカーが挿入されるとともに次の３つのファイルができる。
通常の更新（Update）もマージの一種である。更新の場合は、始点となるのが作業領域の BASE であり、終点となるのがリポジトリの HEAD であり、現在の作業内容が冒頭の 「マージ結果を保存する作業領域」 に相当する。この場合も、コンフリクトしてうまくマージできなかったときは、次の３つのファイルができる。
- マージの始点となるブランチのリビジョン
- マージの終点となるブランチのリビジョン
- マージ結果を保存する作業領域
マージがうまくいけば、マージ結果だけが作業領域に残る。しかし、うまく２つの差分がコンフリクトして、うまくマージできなかったときは、マージが適用されたファイル中に衝突マーカーが挿入されるとともに次の３つのファイルができる。
- *.merge-left.r{リビジョン番号}
- *.merge-right.r{リビジョン番号}
- *.working
通常の更新（Update）もマージの一種である。更新の場合は、始点となるのが作業領域の BASE であり、終点となるのがリポジトリの HEAD であり、現在の作業内容が冒頭の 「マージ結果を保存する作業領域」 に相当する。この場合も、コンフリクトしてうまくマージできなかったときは、次の３つのファイルができる。
- *.r{BASE のリビジョン番号}
- *.r{HEAD のリビジョン番号}
- *.mine
Friday, January 05, 2007
diff の出力の見方
Unix の diff コマンドは、 ファイルを１行ずつ比較していって、その差分を出力する。その出力の見方を今まであいまいにしてきたので、ひとつ調べてみた。
まず、1.txt を次のように作る。
数字とコロンは行番号を示すためのもので、ファイルには実際に書き込まれていない。もう１つ 2.txt として
この２つのファイルを diff に渡して
diff 1.txt 2.txt
とすると、その出力は、
となる。これはどういう意味かというと、１つめのファイルの４行目を change して２つ目のファイルの４行目から５行目にする。さらに１つ目のファイルの５行目の直ぐ下に２つ目のファイルの７行目から９行目を Add する。こうすると１つ目のファイルが２つ目のファイルと等しくなる、ということだ。
< で始まる行が１つ目のファイルの対応行であり、> で始まる行が２つ目のファイルの対応行だ。Add の場合は、１つ目のファイルの対応行は示されていないが、これはとくに必要ないからだ。
diff に渡すファイルの順序を入れ替えて
diff 2.txt 1.txt
とすると、さっきの出力と論理的に反対の結果が得られる。
7,9d5 というのは、先ほどの 5a7,9 とちょうど逆の操作なのだが、うまく文章にできない。要するに７行目から９行目を Delete しろということだ。
まず、1.txt を次のように作る。
1:Jan
2:Feb
3:Mar
4:Apr
5:May
6:
7:Jun
8:
9:Jul
10:Aug
11:Sep
12:Oct
13:Nov
14:Dec
数字とコロンは行番号を示すためのもので、ファイルには実際に書き込まれていない。もう１つ 2.txt として
1:Jan
2:Feb
3:Mar
4:4
5:four
6:May
7:6
8:six
9:sex
10:
11:Jun
12:
13Jul
14:Aug
15:Sep
16:Oct
17:Nov
18:Dec
この２つのファイルを diff に渡して
diff 1.txt 2.txt
とすると、その出力は、
4c4,5
< Apr
---
> 4
> four
5a7,9
> 6
> six
> sex
となる。これはどういう意味かというと、１つめのファイルの４行目を change して２つ目のファイルの４行目から５行目にする。さらに１つ目のファイルの５行目の直ぐ下に２つ目のファイルの７行目から９行目を Add する。こうすると１つ目のファイルが２つ目のファイルと等しくなる、ということだ。
< で始まる行が１つ目のファイルの対応行であり、> で始まる行が２つ目のファイルの対応行だ。Add の場合は、１つ目のファイルの対応行は示されていないが、これはとくに必要ないからだ。
diff に渡すファイルの順序を入れ替えて
diff 2.txt 1.txt
とすると、さっきの出力と論理的に反対の結果が得られる。
4,5c4
< 4
< four
---
> Apr
7,9d5
< 6
< six
< sex
7,9d5 というのは、先ほどの 5a7,9 とちょうど逆の操作なのだが、うまく文章にできない。要するに７行目から９行目を Delete しろということだ。
Thursday, January 04, 2007
RUP とは
Rational Unified Process（ラショナル統一プロセス）のこと。いわゆる Unified Process の原型はこれだろう。オブジェクト指向ソフトウェアエンジニアリングのベストプラクティスをまとめたものといえる。
UP は、ウォーターフォールプロセスと異なり、反復的で段階的な開発プロセスである。これは、プロジェクトの進展につれて、次のようなフェーズをたどり、
各反復でおこなわれる作業は次のような分野に分けられる。
RUP では、誰が（役割）、何を作成するために（成果物）、何をするのか（作業）ということが決められている。
４つのフェーズの各々は、その終点を特徴付ける目標とマイルストーンをもっている。各マイルストーンは、次のフェーズに進むときのリスクを軽減するために達成する必要があり、それを評価するために作成しなければならない成果物が決められている。
方向付けフェーズの終点では、
RUP で定義されている作業や成果物をすべて作成しなければならないということではない。プロジェクトの性格にあわせて柔軟に取捨選択すればいい。
UP は、ウォーターフォールプロセスと異なり、反復的で段階的な開発プロセスである。これは、プロジェクトの進展につれて、次のようなフェーズをたどり、
- 方向フェーズ
- 推敲フェーズ
- 作成フェーズ
- 移行フェーズ
各反復でおこなわれる作業は次のような分野に分けられる。
- ビジネスモデリング
- 要求
- 分析・設計
- 作成
- 移行
- 構成と変更管理
- プロジェクト管理
- 環境
RUP では、誰が（役割）、何を作成するために（成果物）、何をするのか（作業）ということが決められている。
４つのフェーズの各々は、その終点を特徴付ける目標とマイルストーンをもっている。各マイルストーンは、次のフェーズに進むときのリスクを軽減するために達成する必要があり、それを評価するために作成しなければならない成果物が決められている。
方向付けフェーズの終点では、
- プロジェクトの範囲（開発すべきもの）・予算・高水準のスケジュールについて、利害関係者（ユーザ、買主、開発者、プロジェクト管理者など）が合意していること。
- 要求（製品に対する期待と優先度）を利害関係者が理解していること。
- 気がついたリスクについて合意し、それに対する対処策が考えられていること。
- 主要なアーキテクチャの決定がなされ、それを実装した実行可能なアーキテクチャ（プロトタイプ）が完成する。
- それが製品に対する要求を満たしていることを確認すること。
- 作成フェーズの全体的な計画と各反復計画が立てられていること。
- 適切な支援環境と開発基盤が確立されていること。
- 製品の α ヴァージョン（最初のユーザへリリースできる程度の成熟度をもっている）が完成していること。
- ユーザがテストや使用の準備が整っていること。
- 開発された製品
- リリースノート
- 導入および設定手順書、スクリプト
- エンドユーザ支援資料
RUP で定義されている作業や成果物をすべて作成しなければならないということではない。プロジェクトの性格にあわせて柔軟に取捨選択すればいい。
Tuesday, November 14, 2006
Ubuntsu Linux でのロケール設定
.bash_profile で
LC_ALL=ja_JP.eucJP
というような 設定にしていたのだが、たとえば perl を起動したときに
のような Warning が発生していた。svn コマンドを実行したときも似たようなメッセージが出た。
これは、/usr/lib/locale/ にロケールの定義がないことが原因らしい。デフォルトでは
en_US.utf8/
ja_JP.utf8/
という２つがあり、この中でそれぞれのロケールが定義されている。そこで、/etc/locale.gen ファイルに
というエントリを定義して、ルート権限で locale-gen コマンドを実行した。これにより新しく ja_JP.eucjp/ ディレクトリが作成され、先ほどの Warning メッセージは出なくなった。
ただ、最初のうち、local.gen ファイルを編集し、locale-gen コマンドを実行しても ja_JP.eucjp/ は作成されなかった。locale-gen コマンドに直接 ja_JP.eucjp を指定したりして、いろいろ試しているうちに成功した。原因はよく分からない。。。
LC_ALL=ja_JP.eucJP
というような 設定にしていたのだが、たとえば perl を起動したときに
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "ja_JP:ja:en_GB:en",
LC_ALL = "ja_JP.eucJP",
LC_MESSAGES = "C",
LC_CTYPE = "ja_JP.eucJP",
LANG = "ja_JP.eucJP"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
のような Warning が発生していた。svn コマンドを実行したときも似たようなメッセージが出た。
これは、/usr/lib/locale/ にロケールの定義がないことが原因らしい。デフォルトでは
en_US.utf8/
ja_JP.utf8/
という２つがあり、この中でそれぞれのロケールが定義されている。そこで、/etc/locale.gen ファイルに
ja_JP.eucJP EUC-JP
というエントリを定義して、ルート権限で locale-gen コマンドを実行した。これにより新しく ja_JP.eucjp/ ディレクトリが作成され、先ほどの Warning メッセージは出なくなった。
ただ、最初のうち、local.gen ファイルを編集し、locale-gen コマンドを実行しても ja_JP.eucjp/ は作成されなかった。locale-gen コマンドに直接 ja_JP.eucjp を指定したりして、いろいろ試しているうちに成功した。原因はよく分からない。。。
Saturday, November 11, 2006
Apache2 でアクセス認証を設定したときのディレクトリインデックス表示の変化について
マイサーバに Apache2.0 をセットアップした。Ubuntsu の apt-get でパッケージをインストールしたら、デフォルトで
/~kazu/public_html/
へのアクセスができた。~kazu/public_html/ には DirectoryIndex ディレクティブに指定してある名前のファイルがないのでディレクトリ内がインデックス表示されるようになている。
このディレクトリには、private_html という名前の ~kazu/ へのシンボリックリンクがある。つまり、このリンクをたどれば自分のホームディレクトリへアクセスできるようになっている。
自分のホームは非公開にしたいので、auth_digest モジュールを Apatche に追加し、~kazu/ へ .htaccess ファイルも設定して private_html にアクセスしたときは Digest 認証がかかるようにした。ちなみに以前は Base 認証だったので多少セキュリティレベルが上がっている。
ここでタイトルの件が起こった。private_html に Digest 認証をかけたら public_html/ でのインデックス表示に private_html が表示されなくなったのだ。.htaccess をはずしたり、空の .htaccess をおいたりした場合は、問題なく表示される。
以前、Apache1.3 系列を使っていて、そこで Base 認証をかけていたときは、普通に private_html のリンクがインデックス表示されていたのだが。。。
Apache2 の新機能で認証がかかっているリンク先へのシンボリックリンクはインデックス表示されないようになっているのだろうか？それとも単なるバグなのか？
いったん、その認証がかかったリンク先にアクセスし、また戻ってくると、今度はそのリンクがインデックスに表示されるようになった。。。
/~kazu/public_html/
へのアクセスができた。~kazu/public_html/ には DirectoryIndex ディレクティブに指定してある名前のファイルがないのでディレクトリ内がインデックス表示されるようになている。
このディレクトリには、private_html という名前の ~kazu/ へのシンボリックリンクがある。つまり、このリンクをたどれば自分のホームディレクトリへアクセスできるようになっている。
自分のホームは非公開にしたいので、auth_digest モジュールを Apatche に追加し、~kazu/ へ .htaccess ファイルも設定して private_html にアクセスしたときは Digest 認証がかかるようにした。ちなみに以前は Base 認証だったので多少セキュリティレベルが上がっている。
ここでタイトルの件が起こった。private_html に Digest 認証をかけたら public_html/ でのインデックス表示に private_html が表示されなくなったのだ。.htaccess をはずしたり、空の .htaccess をおいたりした場合は、問題なく表示される。
以前、Apache1.3 系列を使っていて、そこで Base 認証をかけていたときは、普通に private_html のリンクがインデックス表示されていたのだが。。。
Apache2 の新機能で認証がかかっているリンク先へのシンボリックリンクはインデックス表示されないようになっているのだろうか？それとも単なるバグなのか？
いったん、その認証がかかったリンク先にアクセスし、また戻ってくると、今度はそのリンクがインデックスに表示されるようになった。。。
Wednesday, September 27, 2006
JMeter でのスレッド数、Ramp-Up 期間、ループ回数の解釈
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
スレッド数：３
Ramp-Up 期間（秒）：３０
ループ回数：６
にした場合のログが上のようになる。
ここから分かることは、３０秒間に３つの割合でスレッドが作成される。
各々が６回テストを実行することを指定しているということだ。
結果として、１０秒ごとに作成されたスレッドが６回のテストを実行する。
最初に３つのスレッドが１度に作成され、各々が３０秒の間に６回のテストを実行する、
つまり、３ユーザが５秒に１回リクエストを出すことをシミュレーションしているのでは
ないということだ。
どちらもテスト総数と１秒当たりのテスト回数は同じになるが、
この違いが大きな違いになるような場合もあるだろうから気をつけること。
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:10:57 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:07 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
133.217.248.30 - - [27/Sep/2006:18:11:17 +0900] "GET /inv/inv?id=kajikuni&aid=20000&method=getQuote&args=4%2C3553.T%3ACVQBI%2C3789.T%3ACVQBI%2C4464.T%3ACVQBI%2C4726.T%3ACVQBI HTTP/1.1" 200 3032
スレッド数：３
Ramp-Up 期間（秒）：３０
ループ回数：６
にした場合のログが上のようになる。
ここから分かることは、３０秒間に３つの割合でスレッドが作成される。
各々が６回テストを実行することを指定しているということだ。
結果として、１０秒ごとに作成されたスレッドが６回のテストを実行する。
最初に３つのスレッドが１度に作成され、各々が３０秒の間に６回のテストを実行する、
つまり、３ユーザが５秒に１回リクエストを出すことをシミュレーションしているのでは
ないということだ。
どちらもテスト総数と１秒当たりのテスト回数は同じになるが、
この違いが大きな違いになるような場合もあるだろうから気をつけること。
Saturday, September 23, 2006
暗号技術のはなし（６）
拡散と混乱を組み合わせた暗号を、「合成暗号」とよぶ。そして、拡散と混乱に使う各アプリケーションを「ラウンド関数」とよぶ。これらラウンド関数を何回も繰り返して適用することでより複雑な合成関数にしたものを「反復合成関数」とよぶ。DES は反復合成関数だ。
強固な暗号方式を使った暗号は、暗号文を統計分析してもパターンを見出すことができず解読することができない。そして潜在的な暗号化キーの数も膨大なため、総当り攻撃では現実的な時間で攻略することができない。したがって、安全ということができる。
暗号は、暗号化方式と暗号化キーの組み合わせである。そのうち秘密なのは暗号化キーだけである。方式そのものは公開しなければならない。これを「ケルクホフの原理」という。方式そのものはスパイや暗号製作者の買収などにより漏れることがあるため、暗号の安全性は方式が秘密であることに頼ってはいけない。キーが秘密であることに頼るべきである。したがって、キーは交換が容易でなくてはならないことになる。
強固な暗号方式を使った暗号は、暗号文を統計分析してもパターンを見出すことができず解読することができない。そして潜在的な暗号化キーの数も膨大なため、総当り攻撃では現実的な時間で攻略することができない。したがって、安全ということができる。
暗号は、暗号化方式と暗号化キーの組み合わせである。そのうち秘密なのは暗号化キーだけである。方式そのものは公開しなければならない。これを「ケルクホフの原理」という。方式そのものはスパイや暗号製作者の買収などにより漏れることがあるため、暗号の安全性は方式が秘密であることに頼ってはいけない。キーが秘密であることに頼るべきである。したがって、キーは交換が容易でなくてはならないことになる。
暗号技術のはなし（５）
換字暗号では、平文の統計的なパターンが暗号文に残ってしまう。ヴィゲネーレ暗号のようなポリアルファベティックでもキーの長さは有限なわけで、まだ十分ではない。
換字に転置を組み合わせても、ある文字が別の文字に対応しているという関係は残るわけで、パターンを十分に隠蔽できるわけではない。チンパンジーがタイプしたように完全にランダムに見える暗号文を作成したいのだ。
１つの文字を複数のコンポーネントからなるものに変換したらどうか？これをするのが、「ポリビウス暗号」。
ポリビウス暗号では、文字を２桁の数字に変換する。a を 11、b を 23 とかいうように。5x5 の表をつくり、そこにアルファベットを記入していき、座標を暗号文に使う。
これだけだと、単なるモノアルファベティックな換字暗号だが、これをさらに転置する。そのとき、２桁の数字を１つ１つに分割して転置する。たとえば、e が 15 に変換されているとしたら、1 と 5 を別々に転置する。こうすると、出現頻度がもっとも高い e に対応している 15 が暗号文中にもっとも高い頻度であらわれるというような統計的パターンを隠すことができる。
現代のコンピュータを使った暗号では、文字は複数のビットで表現されるから、各ビットを転置することで同じことをより効果的に実現できる。
このようにして、平文のもつ統計的なパターンを暗号文全体にうまく分散させて隠すことができる。これを「拡散」とよぶ。これにより、暗号文を統計分析してパターンを見出し、解読するということが困難になる。
拡散とは別の概念に「混乱」がある。これは、暗号方式を既知として、それを使った暗号文から暗号化キーを推測できないようにすることだ。これは複雑な換字方式を考案することに相当する。たとえば、現代の DES 暗号では、非線形の換字暗号方式を採用することでこれを実現している。
換字に転置を組み合わせても、ある文字が別の文字に対応しているという関係は残るわけで、パターンを十分に隠蔽できるわけではない。チンパンジーがタイプしたように完全にランダムに見える暗号文を作成したいのだ。
１つの文字を複数のコンポーネントからなるものに変換したらどうか？これをするのが、「ポリビウス暗号」。
ポリビウス暗号では、文字を２桁の数字に変換する。a を 11、b を 23 とかいうように。5x5 の表をつくり、そこにアルファベットを記入していき、座標を暗号文に使う。
これだけだと、単なるモノアルファベティックな換字暗号だが、これをさらに転置する。そのとき、２桁の数字を１つ１つに分割して転置する。たとえば、e が 15 に変換されているとしたら、1 と 5 を別々に転置する。こうすると、出現頻度がもっとも高い e に対応している 15 が暗号文中にもっとも高い頻度であらわれるというような統計的パターンを隠すことができる。
現代のコンピュータを使った暗号では、文字は複数のビットで表現されるから、各ビットを転置することで同じことをより効果的に実現できる。
このようにして、平文のもつ統計的なパターンを暗号文全体にうまく分散させて隠すことができる。これを「拡散」とよぶ。これにより、暗号文を統計分析してパターンを見出し、解読するということが困難になる。
拡散とは別の概念に「混乱」がある。これは、暗号方式を既知として、それを使った暗号文から暗号化キーを推測できないようにすることだ。これは複雑な換字方式を考案することに相当する。たとえば、現代の DES 暗号では、非線形の換字暗号方式を採用することでこれを実現している。
暗号技術のはなし（４）
換字暗号方式とは別の方式として、「転字暗号方式」というのがある。これは、平文の文字の位置を入れ替えるというもの。
単純な転置、たとえば、転置表に平文を横方向に書いていき、それを縦方向に読んだものを暗号文にする、などではすぐに暗号文に残ったパターンを見抜かれてしまう。この場合なら、何文字かごとに読んでいく、というのを試していけば解読されてしまうだろう。平文に含まれているキーワードや出現頻度の高い単語に注目すると解読がしやすくなる。
暗号文に単純なパターンを残さないために、転置を１回ではなく何回も繰り返したり、転置と換字を組み合わせるなどして、パターンを発見しにくくすることができる。
たとえば、現代の暗号 DES（Data Encryption Standard）でも、転置と換字を組み合わせている。
単純な転置、たとえば、転置表に平文を横方向に書いていき、それを縦方向に読んだものを暗号文にする、などではすぐに暗号文に残ったパターンを見抜かれてしまう。この場合なら、何文字かごとに読んでいく、というのを試していけば解読されてしまうだろう。平文に含まれているキーワードや出現頻度の高い単語に注目すると解読がしやすくなる。
暗号文に単純なパターンを残さないために、転置を１回ではなく何回も繰り返したり、転置と換字を組み合わせるなどして、パターンを発見しにくくすることができる。
たとえば、現代の暗号 DES（Data Encryption Standard）でも、転置と換字を組み合わせている。
Thursday, September 21, 2006
暗号技術のはなし（３）
平文の言語学的なパターンが暗号文にそのまま残ってしまうというモノアルファベティック暗号の欠点をなくすには、平文を暗号化するとき、１種類の文字が複数の種類の別の文字に換字されるようにすればいい。たとえば、a という文字がある場所では e に、別の場所では t に変換されるというようにすればいい。
このような換字暗号を「ポリアルファベティック暗号」という。その１つが「ヴィゲネーレ暗号」だ。
シーザー暗号では使用できる暗号化キーのうち１つだけを使って平文を暗号化していく。１つのキーで平文のすべての文字を変換するのでモノアルファベティックになってしまうのだ。ヴィゲネーレ暗号では、複数のキーを使って暗号化をおこなう。たとえば、キー番号 3, 25, 14 を使って暗号化するのであれば、平文の１番目の文字はキー番号 3 で、２番目の文字はキー番号 25 で、３番目の文字はキー番号 14 で変換する。以降、これを繰り返していく。こうすると、平文中で同じ文字でも、出現する場所によって異なる３つの文字のいずれかに変換されることになる。使用するキーの数を増やせばヴィゲネーレ暗号の強度は増す。複数のキーを１まとめにしたものを１つのキーにしているので、これはキーの長さということができる。
ヴィゲネーレ暗号のようなポリアルファベティック暗号では、平文の言語学的なパターンはモノアルファベティック暗号よりは隠蔽されている。したがって、「単純な」統計分析では破ることはできない。
このような換字暗号を「ポリアルファベティック暗号」という。その１つが「ヴィゲネーレ暗号」だ。
シーザー暗号では使用できる暗号化キーのうち１つだけを使って平文を暗号化していく。１つのキーで平文のすべての文字を変換するのでモノアルファベティックになってしまうのだ。ヴィゲネーレ暗号では、複数のキーを使って暗号化をおこなう。たとえば、キー番号 3, 25, 14 を使って暗号化するのであれば、平文の１番目の文字はキー番号 3 で、２番目の文字はキー番号 25 で、３番目の文字はキー番号 14 で変換する。以降、これを繰り返していく。こうすると、平文中で同じ文字でも、出現する場所によって異なる３つの文字のいずれかに変換されることになる。使用するキーの数を増やせばヴィゲネーレ暗号の強度は増す。複数のキーを１まとめにしたものを１つのキーにしているので、これはキーの長さということができる。
ヴィゲネーレ暗号のようなポリアルファベティック暗号では、平文の言語学的なパターンはモノアルファベティック暗号よりは隠蔽されている。したがって、「単純な」統計分析では破ることはできない。
Subscribe to:
Posts (Atom)