11/10(Fri)
/** 懐かしい... */
健康診断→直帰で、ひさびさに午後5時代という驚異的な時間に、家に着きました。
学生時代(最初の1年だけ?)は、ちょうどその頃帰ってたので、
なんだか、妙に懐かしい気分になってしまいました(^^;
毎日がこうだったらなぁ...
やっぱり、引越した方がいいのかもなぁ。
11/9(Thu)
/** Office97 on Windows NT3.51 */
まずは、下のハードコピーをご覧下さい。
よくよく見れば分かると思いますが、
タイトルバーとメニューバーが、かなぁりミスマッチです。
これ、合成でもなんでもなくて、現実に起こっていることなのです。
(僕のマシンのみならず、職場の周りの人みんな。)
恐らくは、WindowsNT3.51のメニューバーコンポーネントではなく、
Office97に同梱されているものが使われている結果だと思われますが、
それにしても中途半端。
やっぱり、NT3.51が32bitだったってのが痛いのかねぇ(>_<;
こんなワケの分からない環境を使わされてる、僕の立場を少しでも分かってくれれば幸いです...
ちなみに、もう少し分かりたいと思う人は、
C:\Windows\Winfile.exe (互換性のために残されているファイルマネージャ, NTにはあるの?)
を起動してみましょう。
右クリックが効かないのも驚きなら、ディレクトリをどうやって作るのかも良く分からないはずです。
以上、過去探検のコーナーでした(^^;
11/6(Mon)
/** Yeah! Tomcat!! */
Servlet API2.2準拠のサーブレットエンジンとして、Tomcatをゲットしました。
ちなみにTomcatは、JSP1.1にも準拠しているので、JSPの実験とかも出来そう。
以前は、Apache + JServ + JSDKを使ってましたが、
サポートしているAPIが、Servlet API2.0と古かったし、
最近ではServlet回りもずいぶん様変わりしてしまって、
web.xmlというXMLのファイルに設定を書き込んだり、
warというJARファイルに一まとめに出来たりと、色々取り決めがあったりします。
Tomcatのインストール自体は難しいことはなく、
Apacheへの組み込みも、ドキュメント通りにやってれば出来ました。
問題は、既存アプリケーションの移植。
といっても、大したアプリケーションを持ってるわけではないのですが(^^;
そんなアプリの内の一つに、雑記帳の色々統計を取るアプリケーションがあります。
HTMLのリンク機能を使うのなら、Webアプリケーションにすべきだと思ったし、
どうせやるなら、Perl - CGIは既にレガシーだと感じていたから、
Servletでやるべきだと思ったので、Servletで構築してみました。
単にJava好きってのもあるけど(^^;
ところが、ここで一つ問題が生じました。
FileInputStreamを使っても、リソースファイルがカレントディレクトリから読めないのです。
/, /Web-Inf, /Web-Inf/classesなど、標準のディレクトリどこに置いても、
読み込んでくれないので、これはおかしいと思いました。
色々JDK回りのドキュメントを読み漁っているうちに、以下のドキュメントに当たりました。
$JDK_HOME/docs/ja/guide/resources/resources.htmlにある、
「位置に依存しない方法でのリソースへのアクセス」
ここで、「getSystemResourceAsStream」を見た瞬間に、(←IEのセキュリティホールで問題になったヤツね(^^;)
Servlet APIにも、似たようなのがあるんじゃないの? と思い、Servlet API Referenceを見ることに。
すると、ありました(^^;
javax.servlet.ServletContext#getResourceAsStream(java.lang.String path)
なるものが。
これさえ分かってしまえば、あっという間に問題解決♪
11/5(Sun)
/** PostgreSQL＆ODBC */
AccessDBからODBC経由で、Oracleデータベースにアクセスして、
テーブルをインポートするってのをよく仕事でやるので、
家でも同じように、Linux上のPostgreSQLのテーブルを、
WindowsのAccessDBに取り込めるのかっていうのを実験してました。
ちなみに、AccessDBに取り込むメリットは一つ。
telnetだと崩れがちな結果表を、Excelみたいな表で表示できること。
フォームで加工すれば、さらにきれいに出力できます。
特に、検証物件としてのデータベースの中身は重要で、
これは見やすい方が良いに決まってます。
まずは、PostgreSQLのODBCドライバのコンパイル。
これは、VC++4.0以降ならOKだったので、ギリギリセーフ。
こういう時のために必要なのね〜。
んで、これはあっさりOK。
だって、DLLプロジェクト作って、ファイルぶちこんで、ビルドするだけだもん(^^;
次に、ODBCドライバ(DLLファイル)の登録。
これが難儀で、コントロールパネル→ODBCデータソース(32ビット)では、
「新しいドライバをインストールするには、ドライバのセットアッププログラムを使用してください。」
とあるものの、当のドライバには、インストール方法らしきものは無かったです。
じゃあどうするか。
そりゃあもう、レジストリ直書き換えしかないですよね(^^;
Windowsディレクトリ以下に、「Odbc.ini」と「Odbcinst.ini」ファイルがあるものの、
これは無効らしいです。
いくら書き換えても、反応しなかったし。
で、当然書き換えるべき場所なんて分かるはずも無いので、
適当に検索してたら、意外とあっさり見つかりました。
「HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI」と「HKEY_LOCAL_MACHINE\Software\ODBC\ODBCINST.INI」
INIファイルがそのまま、レジストリになったらしい。
ODBCINST.INIの方に、PostgreSQLのキーを登録し、
中身は、DriverとSetupのみ記述。残りは勝手に設定されてた。
んで、ODBCINST.INI\ODBC Driversに、文字列: PostgreSQL、データ: "Installed"
を登録して完了。
なんか、こういうのがうまく行くと、結構快感(^^;;
いざつなぐべ〜(^^)/
...と思ったら、「User Authentication Failed」のエラーが(-_-;
何回やっても同じ結果。
もうちょいログを詳しく見てみると、コネクションから失敗しているらしい...
ここで悩むこと2時間...
と、昔にも同じ現象でハマったことを思い出す。
さっそく雑記帳の過去ログを検索すること数秒。
キーワード「pg_hba.conf」を1998年12月の雑記帳から発見。
Windowsマシンのアクセスパーミッションを与えて無事成功!!
しっかし...
仕事でやっているような操作を家でもすると、
家で仕事をしているような感覚に陥るねぇ...(-_-;
11/4(Sat)
/** なんで連休は... */
こんなに過ぎるのが速いんだろうねぇ。
平日も、このぐらいのスピードで過ぎてくれればいいのに。
まあ多分、昼過ぎまで寝てるからそう感じるんだろうけど。
/** Pythonのちょっと便利なところ。 */
今日は、モジュールについてお勉強。
Pythonのマルチプラットフォーム性は、Javaと同じ原理で、
バイトコードにコンパイルして、インタプリタであるVMが解釈、実行する。
ただ、Javaは、javacコンパイラで開発者がコンパイルしなければならないのに対し、
Pythonは、最初に一回実行する時点でコンパイルを行う。
二回目以降は、コンパイルされたバイトコードを使うので、速度が速くなるといった仕組み。
Javaみたいに、バイトコードだけ配布してもいいし、
ソースコードだけの配布もOKなら、両方配布してもOK。
Pythonで書かれたソフトウェアのユーザにとって、
ソースコードしか無かったとしても、
コンパイルの手間無く実行出来るってのは、便利かも知れない。
11/1(Wed)
/** おいおい(^^; */
プロジェクトが終わってヒマになったので、
新しく来る人のパソコンのセットアップとか、プライバシーマークのシール配りとか、
やってたおかげで、すっかり総務部とか呼ばれるようになってしまいました(^^;
そして、ヒマになるとなぜか、ISOがらみの仕事が回ってきます。
今回は、ISO監査の質問一覧みたいのがあって、
それに一個一個答えていくというもの。
うちの会社のえらい人たちが作った、ISOマニュアル類を見れば、
どこかに答えが載ってるらしいんですが、すっげぇ面倒です(-_-;
そんな中、ISO関連でそろえなければならない資料の中に、
「開発計画書」なるものがあるんですが、
この中に、システムの形態みたいな項目がありました。
これは、「汎用」「C/S」「Web・オブジェクト」「その他」
から選べるようになっています。
大体オチは見えてきたと思いますが(^^;
うちのプロジェクトがなぜか、「C/S」になってるんですねぇ。
そこでまさに、「おいおい(^^;」となったわけです。
思いっきり、汎用機かんでるだろっつーの!
世の中には、納得がいかないことが多いですね。