2007年5月アーカイブ

和田アキ子。
マグナムドライのCM

え・・・？意外なほど上手い。
正直、ビックリしました。

古くは
８時だよ全員集合とか

今なら
アッコにおまかせとか

そんなイメージだったのに・・・。

何て言うか、この人、本当に歌手だったんだ・・・。と思った。

CMじゃ聞けないけど、ハイトーンがどうなるかも聞いてみたいな。
みたいな。

CSでやってたので、久々に観てみました。

・・・。何だ、全然悪くないじゃん。ってのが感想。思わず見入ってました。

昔観たときは面白くないって思ってたんだけど、確かに娯楽映画としては全然駄目な作品かも知れないけど・・・嫌いじゃないです。
どっちかって言うと、芸術作品。見るじゃなくって、観ればいいんだと気づいた。
直前に伊丹十三の大病人を見たので、余計に楽しめたのかも知れませんね。真逆だもの、作り手の思想が。作中で出てくるゴッホの如くただただ淡々と描いている。ゴッホの台詞から・・・「何故描かんのかね？」
しつこく繰り返すが、娯楽作品の映画として見るのはダメ。理屈をこねてもダメ。ただ、ぼけーっと観るのが正しいと思う。ちょっと説教クサイけどスルー力が試されてると思えば何てことは無い。

認証の件、Darwinportsで入れると何も問題は無い・・・。
なんで？？

# sudo port install dovecot

動作させる上では問題にならないのだが、気に入らないのが、Portsに依存すること。
オリジナルのソースがそのまま使えないってのが一番気になる。

MacOS Xでdovecotをインストールすると、どうも認証で変な挙動をする。
一回目の認証は上手くいくのだが、二回目以降に
「Error: imap-login: No authentication sockets found」,「Error: child 737 (login) returned error 89」となる。
かなり以前からMac OS Xでdovecotを動作させることはトライしてたもののいつも同じ結果になる。

UW-IMAPの認証に失敗する件として以下のページを発見した。

env_unix.c の中では getpwnam() をなんどか呼び出しますが、それ ぞれ情報のコピーはしていない。通常、getpwnam() をよぶのは認証 すべきユーザの情報だけしかなく、uw-imap 自身のコード以外にget- pwnam() を呼び出すところもないため、正しく動作する。
しかし、Mac OS X の PAM は、そのプロセスで最初に呼び出された時 に一度だけ、root ユーザの情報を getpwnam() で取得する。そう、この時に env_unix.c の内部で確保していると思われている認証すべきユーザの情報が、root のものに書き換えられてしまう。
よって、PAMによる認証そのものは成功したものの、その後ユーザ情報が壊れている(rootのものになっている)ため、その後の諸々のチェックで失敗し、認証が失敗したかのような返答が返される。
実は、これは最初一回目の認証の身に起こる現象でくじけずもう一度認証を行うと、今度はPAMは初期化されているためgetpwnam() を 呼ぶこともなく、認証に成功する。しかし、通常のメールソフトは一度 認証に失敗したら一旦回線を切断し、その後リトライする。uw-imap は接続ごとに起動されるため、そのたびにPAMの初期化が発生し、 そのたびに1度目の失敗が発生する。
これは env_unix.c という UNIX一般で使われるコードの中にあるか なり重大な欠陥である。しかし、10.2 時代に使われていた ckp_stdでは getpwnam() を呼ぶような事はなかったため、また、他のUNIXでは PAMライブラリが getpwnam() を呼ぶことがないのか、これが問題になったことはない模様である。

dovecot.confの中の認証部分で

auth default {
passdb pam {
args = dovecot
}

コナミの新人研修で「グラディウス」のソースコードが使われていたラシイです。
スゴイ話ですね。出来ることなら見てみたい。。

１９８５年ですから、当時のプログラムでオブジェクトの管理はどうしてるのか
とか、ソースの状態（綺麗、汚い）とか気になる点はいろいろあります。
当時のＰＣゲームって、やっとＢＡＳＩＣを脱してきたところでしたから。
ナムコのリブルラブルのプログラムが神レベルだったとか・・・。
もしかしたら、コード書きとしてハイレベルすぎて人が見たら謎だったりして？

そう言えば、ゲーム業界のプログラマって引退早いと聞くのですが、
ＩＴ系のプログラマって、４０代５０代でも現役の人がごくまれに居たりします。

先日ちょっと話を聞いたのですが、パッケージアプリの開発に関して
互換性を持たせる為に他社のアプリのデータのフォーマット解析とか
やってたりするそうです。

ちょっと考えたけど、この方法が簡単。

出力CSVファイルはデータベースの格納されているフォルダに出力される。
CSVなので区切り文字は ,（カンマ）、囲み文字は "（ダブルクォーテーション）が良いだろう。

select * from テーブル名 into outfile "出力CSVファイル" fields terminated by '区切り文字' optionally enclosed by '囲み文字';

逆にCSVを取り込むときは

load data infile "入力CSVファイル" into table テーブル名 fields terminated by '区切り文字' optionally enclosed by '囲み文字';

これで容易にデータベースからCSVで書き出したり、戻したり出来ますね。

そもそも、ApacheのログをMySQLで管理したいってのが目的。ApacheのログをMySQLに吐き出すには、mod_log_sqlを使う方法がある。それに問題は無いのだけど、どうせなら今までのログもSQLに取り込んでおきたい。という事で、Perlを使ってログをDBに吐き出す事にした。PHPでデータベースを使う例は良く見るんだけど、Perlでの例はあまり見たことがなかったので、メモしておく。

前準備として、CPANからDBIとDBD:mysqlをインストールしておく。

# perl -MCPAN -e shell
cpan[1]< install DBI
cpan[2]< install DBD:mysql

これでPerlでMySQLは簡単に使える。

前準備としてDBIを使う宣言

use DBI:

データベースへの接続

$dbh=DBI->connect("DBI:mysql:データベース名:サーバ", "ユーザ名", "パスワード");

SQL文の準備

$sql="INSERT INTO テーブル (...) VALUE (...);"
$sth=$dbh->prepare($sql);

SQL文の実行

$sth->execute;

ステートメントハンドルオブジェクトを閉じる

$sth->finish;

データベースハンドルオブジェクトを閉じる

$dbh->disconnect;

手順はこれだけ。DBIの作者に感謝してありがたく使わせてもらいます。

OpenGL・・・ちょっと飽きてしまった。
ライティング、フォグ、テクスチャの貼り付けまで上手くいったのでここらで一旦休憩。

今日は日本語文字コードの自動判断をやってみた。
UTF-8は難しいので今回はパス。

それでも、なかなかエレガントに実装するのは無理っぽい。。

どういう事かというと、そこそこ判断出来るのだが、色々問題はあって
・「JIS」は簡単だけど、「Shift JIS」と「EUC」の文字コードが被っていて判断できない事がある。
・半角かなを使うと完全に文字コードが被る。
という事から、利用済みの文字コードの範囲だけを考えると判断に優先順位をつけてそれなりに判定するほか無い。

結論としては誤判定が起きるのも仕方ないって事ですか。残念ですが。

簡単そうだな〜と思ってたんですが、未熟な故「ポインタのポインタ渡し」でハマったので、半日で作れなかったのは残念なところです。
きっともっと短いコードで書けたんだろうな。
でも、自動判断が実装出来ちゃうと、変換は容易なので、これ以上頑張る必要は無いか。

それにしてもMacOS XのXcodeは使い勝手がイイです。
単なるC言語のソースを書くにしても、一連の「エディタで編集」→「コンパイル」→「デバッガでテスト」という作業は何も考えずにクリック一発だったりします。正直emacs／viで編集→Makefile作ってmakeという作業に戻れないかも。
他のIDEでもこういう事は出来るのですが、タダで使えちゃったりするのがイイ所です。しかもCとかJavaとか、その他ファイルも自由に扱えるせいで、肝心の「Objective-C」を習得する気が全くおきないのはアップルにとっては問題かも知れませんが。

OpenGLのライティング、上手くいきました。
・gluLookAtの後でライティングの設定を行う。
・ライティングの設定自身は視点を意識しない。
という２点でした。

それにしてもOpenGLの資料って多いようで少ないですね。本屋も行ってみたんですが、資料になりそうな本も少ないし、Webで検索しても「とりあえずやってみましょう」的なページが多くて、なかなか先に進めませんでした。

視点変更を考えてみた。

取りあえず、角度a,bを定義する。
角度a
左向き=-90度、右向き=90度
角度b
下向き=-90度、上向き=90度
OpenGLの座標系で考えると
座標x
左=-1、右=1
座標y
上=-1、下=1
座標z
奥=-1、手前=1
となる。その条件で考えると、
gluLookAtで与える座標から見る視点の先は現在座標に(x,y,z)=(sin角度a,0,-cos角度a)を足した座標を与えることで、水平方向に視点を360度回転させることは出来た。（ぐるっと見渡す感じ）
問題は、そこに上下方向への視点変更を追加した場合。上下方向への座標は(x,y,z)=(0,sin角度b,-cos角度b,0)。したがって(x,y,-z)=(sin角度a,1,-cos角度a)(1,sin角度b,cos角度b)で上下左右に自由に視点が変更出来ると、単純にそう思っていたのだが、あくまで天地はひっくり返らないという結果になってしまった。冷静に考えると、自分の存在する座標点から後ろに振り返ったとしても、天地がひっくり返る事は無いわけだから、当たり前なんだが、想像上は天地がひっくり返ると思っていたので、何となく思っていた画と違ってしまった。
自分の勘違いは明白なので、理解は出来るのですが・・・。飛行機（戦闘機）の宙返りとかを表現する場合は、天地方向がひっくり返る処理も必要という事ですね。gluLookAtで上方向の指定(0.0,1.0,0.0)を(0.0,-1.0,0.0)とすれば良いのでしょうけど。。

ま、取りあえずココまでは上手くいったと思う。

angle_xは視点角度（左右）、angle_yは視点角度（上下）、M_PIは定数π=3.14159...。として、以下の計算値で視点は求められる。

/* 視点の元になる座標点を計算 */
x_x = sin(M_PI / 180 * angle_x);
x_z = -cos(M_PI / 180 * angle_x);
y_y = sin(M_PI / 180 * angle_y);
y_z = cos(M_PI / 180 * angle_y);
x = x_x * 1.0;
y = y_y * 1.0;
z = x_z * y_z;
/* 視点変更 */
gluLookAt(look_x, look_y, look_z, look_x + x, look_y + y, look_z + z,
0.0, 1.0, 0.0);

その後、ライティングで難航。。
自分の視点にスポットライトを置いて、ライトの方角を上記の座標(x,y,z）を与えてやることで、自分がライトで照らしながらモノを見ている感じに出来ると思っていたのだが、結果ライトの方向はライティングには反映されない。
色々いじってみたんだけど、どうも上手くいかない。