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 に変更してリグレッションテストを実行した。

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 アプリケーションをビルドできるようにプロジェクトを構成してやれば、上のようにしてテストすることができる。

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 にしたがい、

$ ./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 をセットアップしていろいろ試そう。

Eclipse でワークスペースにデフォルトの文字コード、改行コードを設定するには？

Window メニューから 「Preferences」 を選び、そこで Workspace を選択する。そこにある Text file encoding と New text file line delimiter でワークスペースデフォルトにしたいものを選択する。

Eclipse 上のエディタで、ファイルの内容すべてをコピーし、その後、そのファイルの Preferences で文字コードを変更し、オープンし直してから、ペーストするとファイルの文字コードを変換することができる。しかし、うっかり改行コードのことを忘れていると、Unix のシェルスクリプトの改行コードを Dos/Windows 風にしてしまい、いざ実行しようとして実行できない現象に悩まされたりするので要注意。今日は、まさにこれにはまってしまった。

改行コードが Unix 風でないとシェルスクリプトが動かない件について

Unix の改行コードは LF（\n）、Dos/Windows の改行コードは CRLF（\r\n） になるのが普通だが、改行コードが LF でないと Unix のシェルスクリプトがうまく動かない場合がある。改行コードが CRLF だと vi で開いたときに行末に ^M という文字が出ることが多いが、そうならずにきれいに表示される vi もあるので、そのために原因が分かりにくいときがあるので要注意。

今日はそれではまってしまった。シマリンによると Perl スクリプトでも改行コードが原因でうまくいかないことが多いらしい。

同じことは、文字コードの食い違いでも発生する場合がある。慎重を期すなら、スクリプト実行前にシェルの環境変数を設定するなどして文字コードをスクリプトで使っている文字コードにあわせるべきだろう。

Subversion でのマージについてのメモ

マージには、次の３つのものが関係してくる。

• マージの始点となるブランチのリビジョン
• マージの終点となるブランチのリビジョン
• マージ結果を保存する作業領域

始点となるリビジョンと終点となるリビジョンの差分を取るのは当然だが、同時に始点と作業領域との差分も取る。そして、始点と終点の差分と始点と作業領域の差分をマージしたものを始点に適用したものを作業領域に置くのだ。

マージがうまくいけば、マージ結果だけが作業領域に残る。しかし、うまく２つの差分がコンフリクトして、うまくマージできなかったときは、マージが適用されたファイル中に衝突マーカーが挿入されるとともに次の３つのファイルができる。

• *.merge-left.r{リビジョン番号}
• *.merge-right.r{リビジョン番号}
• *.working

最初のファイルは、始点となったファイルであり、２番めは終点となったファイルであり、３番目はマージ前の作業領域のファイルである。コンフリクトをマニュアルで解消し、svn コマンドで衝突の解消を実行すれば、この３つのファイルは消え、Commit ができる状態になる。

通常の更新（Update）もマージの一種である。更新の場合は、始点となるのが作業領域の BASE であり、終点となるのがリポジトリの HEAD であり、現在の作業内容が冒頭の 「マージ結果を保存する作業領域」 に相当する。この場合も、コンフリクトしてうまくマージできなかったときは、次の３つのファイルができる。

• *.r{BASE のリビジョン番号}
• *.r{HEAD のリビジョン番号}
• *.mine

*.mine というファイルがマージする前の作業ファイルの内容を保存したファイルだ。残り２つがそれぞれ始点、終点に相当する。結局、更新（Update）というのは、BASE を始点、HEAD を終点にしてのマージ作業に他ならないのだ。

diff の出力の見方

Unix の diff コマンドは、 ファイルを１行ずつ比較していって、その差分を出力する。その出力の見方を今まであいまいにしてきたので、ひとつ調べてみた。

まず、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 しろということだ。

RUP とは

Rational Unified Process（ラショナル統一プロセス）のこと。いわゆる Unified Process の原型はこれだろう。オブジェクト指向ソフトウェアエンジニアリングのベストプラクティスをまとめたものといえる。

UP は、ウォーターフォールプロセスと異なり、反復的で段階的な開発プロセスである。これは、プロジェクトの進展につれて、次のようなフェーズをたどり、

• 方向フェーズ
• 推敲フェーズ
• 作成フェーズ
• 移行フェーズ

各フェーズは１つ以上の反復から構成される。反復とは、時間を区切って、その中で達成すべき目標を明らかにしたものである。各反復終了後に、完了したものについて評価し、必要ならばプロジェクト計画を調整し、次の反復のための詳細な計画を練る。

各反復でおこなわれる作業は次のような分野に分けられる。

• ビジネスモデリング
• 要求
• 分析・設計
• 作成
• 移行
• 構成と変更管理
• プロジェクト管理
• 環境

この中で最後の３つは、各反復の評価期間になされるようなことだろうか。これらの作業はフェーズによって重みが違ってくる。たとえば、ビジネスモデリングや要求などは、方向付けフェーズ・推敲フェーズで比重が大きいだろうし、分析・設計などは推敲フェーズでの比重がもっとも大きいだろう。もちろん、要求作業が作成フェーズに入るような場合もある。要求漏れや要求の変更に対応できるようにするためであり、これがウォーターフォールと違い、反復・段階的なプロセスの利点である。

RUP では、誰が（役割）、何を作成するために（成果物）、何をするのか（作業）ということが決められている。

４つのフェーズの各々は、その終点を特徴付ける目標とマイルストーンをもっている。各マイルストーンは、次のフェーズに進むときのリスクを軽減するために達成する必要があり、それを評価するために作成しなければならない成果物が決められている。

方向付けフェーズの終点では、

• プロジェクトの範囲（開発すべきもの）・予算・高水準のスケジュールについて、利害関係者（ユーザ、買主、開発者、プロジェクト管理者など）が合意していること。
• 要求（製品に対する期待と優先度）を利害関係者が理解していること。
• 気がついたリスクについて合意し、それに対する対処策が考えられていること。

が求められる。推敲フェーズでは、

• 主要なアーキテクチャの決定がなされ、それを実装した実行可能なアーキテクチャ（プロトタイプ）が完成する。
• それが製品に対する要求を満たしていることを確認すること。
• 作成フェーズの全体的な計画と各反復計画が立てられていること。
• 適切な支援環境と開発基盤が確立されていること。

が求められる。作成フェーズでは、

• 製品の α ヴァージョン（最初のユーザへリリースできる程度の成熟度をもっている）が完成していること。
• ユーザがテストや使用の準備が整っていること。

が求められる。そして、移行フェーズでの成果物は、

• 開発された製品
• リリースノート
• 導入および設定手順書、スクリプト
• エンドユーザ支援資料

ということになる。

RUP で定義されている作業や成果物をすべて作成しなければならないということではない。プロジェクトの性格にあわせて柔軟に取捨選択すればいい。