2002年10月の日記です
サーバー不調 2002-10-02 00:45:56 COMP
えーっと、サーバー不調で４日近くもWEBが停止していました (^^;;
不調の原因もケアレスミスなら、４日も気づかなかったのもケアレスミス。
WEB 以外にもサーバー不調の影響は及んだようで、知人から「メールサーバー止まってるみたいだよ」と指摘を受けてはじめて気づきました。
どうやら、不調の原因は RedHat Linux のup2date。
これは Windows の「Windows Update」みたいなもので、最新のプログラムを探し出し、取って来てインストールしてくれるコマンド。今までにも何回かアップデートをして問題なかったから今回もそのつもりで使ったのだけど…
アップデートで大量にファイルを入れ替えたのですが、その際にディスクに不整合が起こった(?)ようで、ディスクアクセスが不調となりました。それがメールサーバー停止の原因の模様。
再起動したら、fsck しろ！ とシステムに怒られました。fsck は、おかしくなったファイルシステムを修復するためのツール。結構時間がかかり、報告が山ほど出ましたが無事修復に成功します。
再起動したところ、無事起動しますが、何か変です。
サーバーはルーターとしても動いているのですが、外に見に行くことが出来ません。
なにか設定をおかしくしてしまっているらしい…
こういう問題は google で検索すれば解決することが多いのですが、そもそも外に出られないので自力解決します。
３時間くらい悪戦苦闘して、やっと解決。今後同じ問題が起こらないように、再起動時に正しく動作するように設定を直します。
WEB を見てみます。変です。ぐちゃぐちゃのプログラムの一部が見えます。
うーん…この問題はとりあえずおいておいて、qmail の設定。
qmail もdaemontoolsで起動するように設定を変えてしまいました。これなら何かあっても安心です。
---
さて、WEB がおかしい原因究明。
調べるのに時間がかかりましたが、どういうわけか、PHP の「古い」バージョンを入れられてしまったようです。
まぁ、PHP は RedHat標準の RPM (インストーラ）を使わず、手動インストールしていたので新旧が認識できないのは仕方ないのかもしれません。
古いことよりも、PHP の設定を標準とは変えていたので、「普通の」PHP を入れられてしまったことで WEB が機能しなくなってしまったのが問題でした。
せっかくなので最新版の PHP …は、日本語関係にバグがあると言うので、一つ前のバージョンを入れます。
入れなおしたらうまく動作するようになりました。
結局、今日はサーバーの設定だけで１日終了。
仕事をしなくてはいけないのだが、コンピューターのトラブルは時間ばかりかかっていけない。
不調の原因もケアレスミスなら、４日も気づかなかったのもケアレスミス。
WEB 以外にもサーバー不調の影響は及んだようで、知人から「メールサーバー止まってるみたいだよ」と指摘を受けてはじめて気づきました。
どうやら、不調の原因は RedHat Linux のup2date。
これは Windows の「Windows Update」みたいなもので、最新のプログラムを探し出し、取って来てインストールしてくれるコマンド。今までにも何回かアップデートをして問題なかったから今回もそのつもりで使ったのだけど…
アップデートで大量にファイルを入れ替えたのですが、その際にディスクに不整合が起こった(?)ようで、ディスクアクセスが不調となりました。それがメールサーバー停止の原因の模様。
再起動したら、fsck しろ！ とシステムに怒られました。fsck は、おかしくなったファイルシステムを修復するためのツール。結構時間がかかり、報告が山ほど出ましたが無事修復に成功します。
再起動したところ、無事起動しますが、何か変です。
サーバーはルーターとしても動いているのですが、外に見に行くことが出来ません。
なにか設定をおかしくしてしまっているらしい…
こういう問題は google で検索すれば解決することが多いのですが、そもそも外に出られないので自力解決します。
３時間くらい悪戦苦闘して、やっと解決。今後同じ問題が起こらないように、再起動時に正しく動作するように設定を直します。
WEB を見てみます。変です。ぐちゃぐちゃのプログラムの一部が見えます。
うーん…この問題はとりあえずおいておいて、qmail の設定。
qmail もdaemontoolsで起動するように設定を変えてしまいました。これなら何かあっても安心です。
---
さて、WEB がおかしい原因究明。
調べるのに時間がかかりましたが、どういうわけか、PHP の「古い」バージョンを入れられてしまったようです。
まぁ、PHP は RedHat標準の RPM (インストーラ）を使わず、手動インストールしていたので新旧が認識できないのは仕方ないのかもしれません。
古いことよりも、PHP の設定を標準とは変えていたので、「普通の」PHP を入れられてしまったことで WEB が機能しなくなってしまったのが問題でした。
せっかくなので最新版の PHP …は、日本語関係にバグがあると言うので、一つ前のバージョンを入れます。
入れなおしたらうまく動作するようになりました。
結局、今日はサーバーの設定だけで１日終了。
仕事をしなくてはいけないのだが、コンピューターのトラブルは時間ばかりかかっていけない。
Write Once ...? 2002-10-02 12:54:37 COMP
１年半ほど前に作った i-mode 用の Java アプリを元に、AU 用のバージョンを作っている。
Java は Write Once, Run Anywhere （一度書けばどこででも動く）をキャッチコピーとして登場してきた。
しかし、実際には Java の実行環境(JavaVM)の実装の違いなどから、「Write Once, Test Anywhere」（一度書いたら、あらゆる場所でテストしろ）などと揶揄されてきた。
まぁ、今回も i-mode と AU の違いがあるのでそれなりの修正は必要だろう、と考えてはいたのだが…
小型機器用の Java 実行環境を KVM と呼ぶ。Kiro byte で動く JavaVM の意味だ。
実際には、Java は実行環境とともに「クラスライブラリ」というものが重要となる。
KVM と組み合わせるには、CLDC と呼ばれるライブラリ群を使う。
i-mode も AU も、KVM + CLDC を基本としていることに変わりはない。
携帯電話用に、CLDC に加えて使うライブラリを MIDP という。
これは、性能も解像度も低い携帯の画面で使うことを想定した、入出力ライブラリだ。
i-mode が Java 対応した時、MIDP はまだ開発中だった。そのため、DoCoMo は MIDP ではなく、独自のライブラリ群を使った…と、表向きには語られている。
しかし、MIDP をベースとして作られたものなので、大きな違いがあるわけでもない、とも語られている。
しかし、ぜんぜん違う。
i-mode では、画面出力を基本的に「HTML 互換」としていた。
i-mode で WEB は見られるのだから、その部品を使う分には難しくないという、非常にもっともな考え方だ。
以上が、i-mode の Java で使える主要な入力部品だ。
しかし、MIDP では、最後の２つ、ドロップリストとボタンがない。
ボタンに関しては通常は一連の入力に１個あればよいもので、携帯電話についているボタンに機能を割り振ることは可能なのでなくてもそれほど問題はない。
問題はドロップリストだ。
というようなインターフェイスを作ることが出来ない。こんな単純なことをラジオボタンで表現すると
という、非常にうざったい画面になってしまう。
実のところ、グラフィックを表示する画面はあるので、最悪の場合「すべてを自前で作る」と解決方法はある。
ただし、この場合文字入力と共存することは出来ない。グラフィック画面ではボタンの入力を直接知ることが出来るかわりに、文字入力が出来なくなるのだ。
加えて言えば、目に見えない「裏」の部分もずいぶん変わっている。
Java では、ユーザーの入力に即時に答えられるような割り込み機能を「Listener」と呼ばれる仕組みで実現している。
i-mode の Java では Listener が豊富に用意されていた。MIDP ではほんのわずか。
たしかに、同じようなことは出来るようになっているのだが、豊富に用意されているほうが使いやすいことは事実。
また、画面表示がらみだが、Font に関する設定も i-mode のほうが柔軟だった。Font というのは奥の深い世界で、英語の場合文字の位置は「ベースライン」を基準として考えられる。
文字は、 1. 文字の高さ 2. 文字の幅 3. 文字の、ベースラインより上の高さ 4.文字の、ベースラインより下の高さ の４つの「サイズ」がある。
i-mode では、すべてを知ることが出来た。長い文字列を指定のドット数以内で表示する時、どこで折り返すと良いかを調べる命令まであった。
しかし、AU では「ベースラインより下」を知ることが出来ない。高さから「上」を引き算すればわかるが、余計な手間がかかる。
折り返し位置も教えてくれない。任意の文字列が何ドットになるかという「幅」は教えてくれるので、少しづつ文字の長さを変えながら自分で調べることは出来るが、これも非常に余計な手間だ。
うむむむむむむむ…
最近、i-mode の Java は「MIDP がまだ出来ていなかったから」独自仕様にしたのではなく、「MIDP があまりにもダメだから」独自仕様にしたのではないかと疑っている。
だとすれば、それに気づかずに MIDP を導入した AU/J-Phone は…
Java は Write Once, Run Anywhere （一度書けばどこででも動く）をキャッチコピーとして登場してきた。
しかし、実際には Java の実行環境(JavaVM)の実装の違いなどから、「Write Once, Test Anywhere」（一度書いたら、あらゆる場所でテストしろ）などと揶揄されてきた。
まぁ、今回も i-mode と AU の違いがあるのでそれなりの修正は必要だろう、と考えてはいたのだが…
小型機器用の Java 実行環境を KVM と呼ぶ。Kiro byte で動く JavaVM の意味だ。
実際には、Java は実行環境とともに「クラスライブラリ」というものが重要となる。
KVM と組み合わせるには、CLDC と呼ばれるライブラリ群を使う。
i-mode も AU も、KVM + CLDC を基本としていることに変わりはない。
携帯電話用に、CLDC に加えて使うライブラリを MIDP という。
これは、性能も解像度も低い携帯の画面で使うことを想定した、入出力ライブラリだ。
i-mode が Java 対応した時、MIDP はまだ開発中だった。そのため、DoCoMo は MIDP ではなく、独自のライブラリ群を使った…と、表向きには語られている。
しかし、MIDP をベースとして作られたものなので、大きな違いがあるわけでもない、とも語られている。
しかし、ぜんぜん違う。
i-mode では、画面出力を基本的に「HTML 互換」としていた。
i-mode で WEB は見られるのだから、その部品を使う分には難しくないという、非常にもっともな考え方だ。
以上が、i-mode の Java で使える主要な入力部品だ。
しかし、MIDP では、最後の２つ、ドロップリストとボタンがない。
ボタンに関しては通常は一連の入力に１個あればよいもので、携帯電話についているボタンに機能を割り振ることは可能なのでなくてもそれほど問題はない。
問題はドロップリストだ。
というようなインターフェイスを作ることが出来ない。こんな単純なことをラジオボタンで表現すると
という、非常にうざったい画面になってしまう。
実のところ、グラフィックを表示する画面はあるので、最悪の場合「すべてを自前で作る」と解決方法はある。
ただし、この場合文字入力と共存することは出来ない。グラフィック画面ではボタンの入力を直接知ることが出来るかわりに、文字入力が出来なくなるのだ。
加えて言えば、目に見えない「裏」の部分もずいぶん変わっている。
Java では、ユーザーの入力に即時に答えられるような割り込み機能を「Listener」と呼ばれる仕組みで実現している。
i-mode の Java では Listener が豊富に用意されていた。MIDP ではほんのわずか。
たしかに、同じようなことは出来るようになっているのだが、豊富に用意されているほうが使いやすいことは事実。
また、画面表示がらみだが、Font に関する設定も i-mode のほうが柔軟だった。Font というのは奥の深い世界で、英語の場合文字の位置は「ベースライン」を基準として考えられる。
文字は、 1. 文字の高さ 2. 文字の幅 3. 文字の、ベースラインより上の高さ 4.文字の、ベースラインより下の高さ の４つの「サイズ」がある。
i-mode では、すべてを知ることが出来た。長い文字列を指定のドット数以内で表示する時、どこで折り返すと良いかを調べる命令まであった。
しかし、AU では「ベースラインより下」を知ることが出来ない。高さから「上」を引き算すればわかるが、余計な手間がかかる。
折り返し位置も教えてくれない。任意の文字列が何ドットになるかという「幅」は教えてくれるので、少しづつ文字の長さを変えながら自分で調べることは出来るが、これも非常に余計な手間だ。
うむむむむむむむ…
最近、i-mode の Java は「MIDP がまだ出来ていなかったから」独自仕様にしたのではなく、「MIDP があまりにもダメだから」独自仕様にしたのではないかと疑っている。
だとすれば、それに気づかずに MIDP を導入した AU/J-Phone は…
いまさら 2002-10-03 22:53:13 COOK
いまさらだがDrink! Smap!を入手。
当初は渋谷周辺でしか売っていなかったらしいが、田舎なうちの近所の自動販売機にも入っていたのを見つけたので。
一般には「まずい」と言う評価。
友人からは「本当にまずいなら飲んでみる価値があるのだが、計算された不味さでつまらない」という評価。
どんなものかと飲んでみるが…
…チェリーコーク？
別にまずいとも思わないが、たしかにいまいち。それほど面白くはなかった。
当初は渋谷周辺でしか売っていなかったらしいが、田舎なうちの近所の自動販売機にも入っていたのを見つけたので。
一般には「まずい」と言う評価。
友人からは「本当にまずいなら飲んでみる価値があるのだが、計算された不味さでつまらない」という評価。
どんなものかと飲んでみるが…
…チェリーコーク？
別にまずいとも思わないが、たしかにいまいち。それほど面白くはなかった。
さらに 2002-10-05 15:19:39 COOK
Drink! Smap!を飲んだ勢いで、冷蔵庫に眠っていたもうひとつの謎のジュースを飲んでみた。
インカコーラ。
名前からして南米産。あちらのほうでは、人気のある飲み物らしい。
コップに注いで見ると、鮮やかな黄色だった。ロゴの右下に書かれた「Golden Kola」とはそういう意味かっ！
見た目は少なくともコーラではないのだが、味はどうか…というと、メロンソーダの味。
見た目も味もコーラではない。
しかし、案外美味しくて拍子抜け。まずい飲み物を期待していたのだが。
→コーラ白書のページにあるINCA KOLA
インカコーラ。
名前からして南米産。あちらのほうでは、人気のある飲み物らしい。
コップに注いで見ると、鮮やかな黄色だった。ロゴの右下に書かれた「Golden Kola」とはそういう意味かっ！
見た目は少なくともコーラではないのだが、味はどうか…というと、メロンソーダの味。
見た目も味もコーラではない。
しかし、案外美味しくて拍子抜け。まずい飲み物を期待していたのだが。
→コーラ白書のページにあるINCA KOLA
Java 2002-10-11 23:54:21 COMP
AU 向け Javaプログラムを作っている。
前の日記では機能の低さを嘆いていたが、それなりにプログラムは形になってきた。
しかし、やはり機能が低いとプログラム量が多くなる。
以前作った i-mode 向けプログラムは 10K の制限内で作ったが、AU は 50K なので機能追加も多く、プログラム量が多くなる。
プログラムが多くなり、把握しにくくなるとバグの元なので、分割コンパイルを行いたいのだが、Java には分割コンパイルという概念はない。
というか、C 言語と違ってオブジェクト指向言語なので、分割は「オブジェクト」単位で自然に行われる。
---
オブジェクト指向というのは、一度完成した「プログラム」を後からいろいろ使いまわせるような仕組みをいう。
使いまわすためには、プログラムの中身はわからなくても、外部への窓口がしっかりしていれば良い。
というわけで、Java はやたらと「窓口」を作る。勝手に作る。作りすぎてメモリを食う。
しかし、携帯電話ではメモリが少ない。対処方法としては、オブジェクトを出来るだけ少なくして、外への窓口も出来るだけ作らないようにすればよい。
しかしこれは本来のオブジェクト指向が目指している方向と正反対だ。
無理なつくりをするので、プログラムは非常に読みにくい、厄介なものとなる。
対症療法としては、Obfuscatorというのがある。
「窓口」というのは、つまり中を覗くためのきっかけにもなりやすい。
Java のプログラムは中身を見られやすいのだ。仕事で使うには、これは困る。
そこで、中身を見えにくいように窓口を「変な形」にするツールが考え出された。
Obfuscatorとは「混乱させるもの」という意味だ。
たとえば、「OpenWindow」という名前がついた窓口があったとしよう。
名前からも、窓口とわかりやすい。Obfuscatorはこれを「a」というような、無味乾燥な名前に変えてしまう。
これは副作用として文字数を減らし、メモリの節約にもつながる。
実際のところ、フリーのObfuscatorはRetroGuardくらいしかないのでそれを使うことになる。
---
KDDI は、Java プログラム作成を促すためにKJX 作成キットを配布している。
(KJX というのは、KDDI の Java 配布形式の名称だ。EZPlus のプログラムのことと思って良い)
この中には、ややこしい Java プログラムのコンパイルを補佐する GUI ツールも含まれている。
…が、これが非常に性能が低い。
i-mode での開発をしていた時には、フリーウェアのiアプリ開発Toolを使用していた。
これは、ボタン一発でコンパイルを行って、RetroGuard までかけてくれた。
しかし、KJX 作成キットではそのようなことは出来ない。
いや、それどころか、KJX 作成キットでは、実は配布形式の KJX を作ることが出来ないのだ。
KJX は配布時に 2byte の CRC チェックを付加する必要があるのだが、KJX 作成キットはその「あたりまえのこと」をやってくれない。
MIDP Builder2というものがあるのを発見した。
このソフトは、KJX 作成キットでは出来ないことをほぼ解消している。
買おうかどうしようか…と迷っていたところ、自分が一番欲しいと思っている機能が欠けていることに気づく。
ここまで来たら、仕方がないので自分でコンパイル環境を組むことにした。
最初はバッチファイルで書こうとしていたが、無理っぽいので windows に perl を導入し、perl で書いた。
まずは KJX 作成ツールが行うのと同じことが出来るのを確認。
その後、RetroGuard でプログラムを縮小する処理を追加。
正常動作を確認。
---
さて、ここまで来て、再び最初の問題。
Obfuscator は解決ではなく、むしろ問題を悪化させる。
そもそも、問題は「プログラムのメモリ量」ではなく「ソースの量」が多いことだ。
読みにくいので分割したい。MIDP Builder2 にかけていたもの、というのもこれだ。
C 言語なら分割できる…というのは、２つの意味があるのだがここでは「プリプロセッサ」の仕組みを導入してみよう。
プリプロセッサを使うと、ファイルの一部として別のファイルを呼び出すことが出来る。
#include というやつだ。C言語を知っている人なら見たことあるだろう。
これは、厳密に言えば分割コンパイルではないのだが、ソースを分割できる。
ソースが分割できれば、プログラムの見通しというのはある程度良くなる。
その「ある程度」がプログラマにとっては非常に重要なのだ。
で、フリーで使えそうなプリプロセッサを探す。
pamulow preprocessorというのを発見。
#include もつかえる、と書いてあったので期待したのだが、実はこの include 文は、非常に限られた用法しか出来ないと判明。
ソースの分割には使えないのだ。これでは意味がない。
そもそもプリプロセッサというのは C言語のアイディアだし、C言語のプリプロセッサを流用するのも悪くない。
そう思って、MS-DOS 時代にはずいぶんとお世話になったLSI-C 試食版をダウンロード。
しかし、これも実は使えないことが判明。
機能的には十分なのだが、なにぶん MS-DOS 時代のものなので、ロングファイル名に未対応だったのだ。残念。
他にないかと探してみると、Borland C++の無料版が見つかった。
Borland C というのもずいぶん懐かしい。大学時代、授業では TurboPascal を使っていた。後に TurboC もつくられ、さらに Borland C/C++ となるわけだが、当時としては一番使いやすい環境だった。
そんなノスタルジーに浸りながらダウンロード。
というか、ファイルが巨大でダウンロード中に思い出に浸っていたというか。
ただプリプロセッサが欲しいだけで、８メガ以上のファイルをダウンロードするのもどうかと思う。
しかし、Borland C++ のプリプロセッサは期待以上の動きをした。
最初からいっしょに設計されたCなどでは問題ないのだが、プリプロセッサを通すと行番号がわからなくなってしまうのが難点だ。
しかし、Borland C++ のプリプロセッサは、「すべての行の先頭に、コメント形式で元のファイルと行数を入れる」という対処方法でこの問題をクリアしていた。すばらしい。
そんなわけで、理想的な開発環境は整った。
しかし、使いもしない C++ が、50M のハードディスクを食っている。
あまり人に勧められる環境構築ではない (^^;;
前の日記では機能の低さを嘆いていたが、それなりにプログラムは形になってきた。
しかし、やはり機能が低いとプログラム量が多くなる。
以前作った i-mode 向けプログラムは 10K の制限内で作ったが、AU は 50K なので機能追加も多く、プログラム量が多くなる。
プログラムが多くなり、把握しにくくなるとバグの元なので、分割コンパイルを行いたいのだが、Java には分割コンパイルという概念はない。
というか、C 言語と違ってオブジェクト指向言語なので、分割は「オブジェクト」単位で自然に行われる。
---
オブジェクト指向というのは、一度完成した「プログラム」を後からいろいろ使いまわせるような仕組みをいう。
使いまわすためには、プログラムの中身はわからなくても、外部への窓口がしっかりしていれば良い。
というわけで、Java はやたらと「窓口」を作る。勝手に作る。作りすぎてメモリを食う。
しかし、携帯電話ではメモリが少ない。対処方法としては、オブジェクトを出来るだけ少なくして、外への窓口も出来るだけ作らないようにすればよい。
しかしこれは本来のオブジェクト指向が目指している方向と正反対だ。
無理なつくりをするので、プログラムは非常に読みにくい、厄介なものとなる。
対症療法としては、Obfuscatorというのがある。
「窓口」というのは、つまり中を覗くためのきっかけにもなりやすい。
Java のプログラムは中身を見られやすいのだ。仕事で使うには、これは困る。
そこで、中身を見えにくいように窓口を「変な形」にするツールが考え出された。
Obfuscatorとは「混乱させるもの」という意味だ。
たとえば、「OpenWindow」という名前がついた窓口があったとしよう。
名前からも、窓口とわかりやすい。Obfuscatorはこれを「a」というような、無味乾燥な名前に変えてしまう。
これは副作用として文字数を減らし、メモリの節約にもつながる。
実際のところ、フリーのObfuscatorはRetroGuardくらいしかないのでそれを使うことになる。
---
KDDI は、Java プログラム作成を促すためにKJX 作成キットを配布している。
(KJX というのは、KDDI の Java 配布形式の名称だ。EZPlus のプログラムのことと思って良い)
この中には、ややこしい Java プログラムのコンパイルを補佐する GUI ツールも含まれている。
…が、これが非常に性能が低い。
i-mode での開発をしていた時には、フリーウェアのiアプリ開発Toolを使用していた。
これは、ボタン一発でコンパイルを行って、RetroGuard までかけてくれた。
しかし、KJX 作成キットではそのようなことは出来ない。
いや、それどころか、KJX 作成キットでは、実は配布形式の KJX を作ることが出来ないのだ。
KJX は配布時に 2byte の CRC チェックを付加する必要があるのだが、KJX 作成キットはその「あたりまえのこと」をやってくれない。
MIDP Builder2というものがあるのを発見した。
このソフトは、KJX 作成キットでは出来ないことをほぼ解消している。
買おうかどうしようか…と迷っていたところ、自分が一番欲しいと思っている機能が欠けていることに気づく。
ここまで来たら、仕方がないので自分でコンパイル環境を組むことにした。
最初はバッチファイルで書こうとしていたが、無理っぽいので windows に perl を導入し、perl で書いた。
まずは KJX 作成ツールが行うのと同じことが出来るのを確認。
その後、RetroGuard でプログラムを縮小する処理を追加。
正常動作を確認。
---
さて、ここまで来て、再び最初の問題。
Obfuscator は解決ではなく、むしろ問題を悪化させる。
そもそも、問題は「プログラムのメモリ量」ではなく「ソースの量」が多いことだ。
読みにくいので分割したい。MIDP Builder2 にかけていたもの、というのもこれだ。
C 言語なら分割できる…というのは、２つの意味があるのだがここでは「プリプロセッサ」の仕組みを導入してみよう。
プリプロセッサを使うと、ファイルの一部として別のファイルを呼び出すことが出来る。
#include というやつだ。C言語を知っている人なら見たことあるだろう。
これは、厳密に言えば分割コンパイルではないのだが、ソースを分割できる。
ソースが分割できれば、プログラムの見通しというのはある程度良くなる。
その「ある程度」がプログラマにとっては非常に重要なのだ。
で、フリーで使えそうなプリプロセッサを探す。
pamulow preprocessorというのを発見。
#include もつかえる、と書いてあったので期待したのだが、実はこの include 文は、非常に限られた用法しか出来ないと判明。
ソースの分割には使えないのだ。これでは意味がない。
そもそもプリプロセッサというのは C言語のアイディアだし、C言語のプリプロセッサを流用するのも悪くない。
そう思って、MS-DOS 時代にはずいぶんとお世話になったLSI-C 試食版をダウンロード。
しかし、これも実は使えないことが判明。
機能的には十分なのだが、なにぶん MS-DOS 時代のものなので、ロングファイル名に未対応だったのだ。残念。
他にないかと探してみると、Borland C++の無料版が見つかった。
Borland C というのもずいぶん懐かしい。大学時代、授業では TurboPascal を使っていた。後に TurboC もつくられ、さらに Borland C/C++ となるわけだが、当時としては一番使いやすい環境だった。
そんなノスタルジーに浸りながらダウンロード。
というか、ファイルが巨大でダウンロード中に思い出に浸っていたというか。
ただプリプロセッサが欲しいだけで、８メガ以上のファイルをダウンロードするのもどうかと思う。
しかし、Borland C++ のプリプロセッサは期待以上の動きをした。
最初からいっしょに設計されたCなどでは問題ないのだが、プリプロセッサを通すと行番号がわからなくなってしまうのが難点だ。
しかし、Borland C++ のプリプロセッサは、「すべての行の先頭に、コメント形式で元のファイルと行数を入れる」という対処方法でこの問題をクリアしていた。すばらしい。
そんなわけで、理想的な開発環境は整った。
しかし、使いもしない C++ が、50M のハードディスクを食っている。
あまり人に勧められる環境構築ではない (^^;;
ねずみあんか 2002-10-14 23:56:55 PET
久しぶりに我が家のハムスターの話題。
久しぶりに、といっても、この日記で話題を追っている人がいるとは思わないが(笑)
夏の暑い盛りには、さすがに動きが悪くなっていた。
もともと砂漠の生き物だから暑さは大丈夫そうなものだが、湿度の高い暑さはダメらしい。
昼間は本来寝ているのに、すぐに起きては水を飲むような状況。夜になって涼しくなってからやっと安心して眠るようで、一日に1Kmも走らないときもあった。
それが、９月頃からは走る走る…一日 10Km は走るという、ハムスター本来のペースを取り戻した。
回し車がぶっ壊れるほど走る。ツリロンアルファで修理したが。
（アロンアルファでは無いあたりに貧乏を感じる (^^; ）
しかし、今度はそろそろ冬が心配。
ハムスターは寒いのがダメで、あまり寒いと仮死状態(擬似冬眠)になって、その際の処置が遅いと死んでしまうのだ。
ペットショップに行くとハムスター用の暖房器具を売っている。
10cm 四方くらいの小さな「ホットカーペット」だと思えばよいが、そんなものが５千円近くもする。
もっと安いものでは、使い捨てカイロを中に入れるだけのものもある。
こちらは周囲の酸素を吸着する（使い捨てカイロは鉄粉の酸化反応だ）なので、注意しないと酸欠になったりするそうだ。
何よりも、実はランニングコストが非常に高い。
で、電気屋に行って人間用の「電気あんか」を買ってきた。
ハムスター用暖房機はケージ（籠）の中に入れて使うわけだが、電気あんかでケージごと暖めてしまえという考え。
薄いもの（ソフトあんか）の方が使いやすいかと思ったのだが、「平形あんか」が安かったのでそちらを購入。
なによりも、薄いものは温度調節が出来ないが、平形は調節可能なのが良い。
ちなみに、500円という破格値。ハムスター専用の 1/10 の値段だ(笑)
ランニングコストに関しては、一番低い温度で 15w 程度のようなのでぜんぜん問題なし。
これで冬の備えもばっちり。
久しぶりに、といっても、この日記で話題を追っている人がいるとは思わないが(笑)
夏の暑い盛りには、さすがに動きが悪くなっていた。
もともと砂漠の生き物だから暑さは大丈夫そうなものだが、湿度の高い暑さはダメらしい。
昼間は本来寝ているのに、すぐに起きては水を飲むような状況。夜になって涼しくなってからやっと安心して眠るようで、一日に1Kmも走らないときもあった。
それが、９月頃からは走る走る…一日 10Km は走るという、ハムスター本来のペースを取り戻した。
回し車がぶっ壊れるほど走る。ツリロンアルファで修理したが。
（アロンアルファでは無いあたりに貧乏を感じる (^^; ）
しかし、今度はそろそろ冬が心配。
ハムスターは寒いのがダメで、あまり寒いと仮死状態(擬似冬眠)になって、その際の処置が遅いと死んでしまうのだ。
ペットショップに行くとハムスター用の暖房器具を売っている。
10cm 四方くらいの小さな「ホットカーペット」だと思えばよいが、そんなものが５千円近くもする。
もっと安いものでは、使い捨てカイロを中に入れるだけのものもある。
こちらは周囲の酸素を吸着する（使い捨てカイロは鉄粉の酸化反応だ）なので、注意しないと酸欠になったりするそうだ。
何よりも、実はランニングコストが非常に高い。
で、電気屋に行って人間用の「電気あんか」を買ってきた。
ハムスター用暖房機はケージ（籠）の中に入れて使うわけだが、電気あんかでケージごと暖めてしまえという考え。
薄いもの（ソフトあんか）の方が使いやすいかと思ったのだが、「平形あんか」が安かったのでそちらを購入。
なによりも、薄いものは温度調節が出来ないが、平形は調節可能なのが良い。
ちなみに、500円という破格値。ハムスター専用の 1/10 の値段だ(笑)
ランニングコストに関しては、一番低い温度で 15w 程度のようなのでぜんぜん問題なし。
これで冬の備えもばっちり。
風邪治りかけ 2002-10-25 16:29:32 OTHER
１週間前に風邪惹いたのが、やっと治りぎみ。
月曜日に仕事で出かけたのが良くなかったようで、帰宅すると熱はあるし、体中痛くて寝ることも出来ない始末。
火曜日は外せない仕事…とはいっても在宅仕事があったので、とりあえず起きてはいた。
これで完全に悪化。水・木と寝込んでいた。
今日、午後になって仕事先からちょっとした相談の電話が入り、仕事復活。
とはいえ、まだふらふらしているのだけど。
週末、妹が久しぶりに演劇やるので見に行ってやらねば。
月曜日に仕事で出かけたのが良くなかったようで、帰宅すると熱はあるし、体中痛くて寝ることも出来ない始末。
火曜日は外せない仕事…とはいっても在宅仕事があったので、とりあえず起きてはいた。
これで完全に悪化。水・木と寝込んでいた。
今日、午後になって仕事先からちょっとした相談の電話が入り、仕事復活。
とはいえ、まだふらふらしているのだけど。
週末、妹が久しぶりに演劇やるので見に行ってやらねば。
妹主演の劇を見る 2002-10-27 23:44:46 OTHER
妹の所属する演劇ユニット東京天然デザートの旗揚げ公演を見に行く。
（おぉ、なんか旗揚げ公演ってかっこいい感じ。小さな劇団の旗揚げなんて、はいて捨てるほどあることは知っているが）
演劇の最中は当然撮影禁止なので、写真は終了後の舞台。
「とある新婚家庭」を舞台にしたコメディーで、その新婚家庭のリビングのみで話は進む。
いわゆるシチュエーションコメディーっぽいもので、旗揚げ公演にしてはよく出来ているんじゃないかと思う。
妹の役は、主役となる新婚夫婦の新妻。つまり、一応「ヒロイン」。
もっとも、お話は「夫が二股をかけていて、昔からの恋人が家に押しかけてきたのに、なんとかごまかそうとすることから起こるドタバタ劇」なので、本当の主役は夫。
（この内容だと女同士の喧嘩になりそうだが、夫のごまかしのせいで、女二人が相手が何者か知らないまま意気投合してしまうのが見所。話が微妙に噛み合わず、その状況で慌てまくる夫が非常に面白い）
ここで内容を紹介しても仕方が無いので書かないが、思ったよりも実力のある劇団だということはわかった。
主役の夫、その「昔からの恋人」、なぜか巻き込まれる準主役の「アパート管理人」…など、主要メンバーの演技力は悪くなかったし。
…妹の演技が劣って見えるのは、身内の厳しい目だからか？
（おぉ、なんか旗揚げ公演ってかっこいい感じ。小さな劇団の旗揚げなんて、はいて捨てるほどあることは知っているが）
演劇の最中は当然撮影禁止なので、写真は終了後の舞台。
「とある新婚家庭」を舞台にしたコメディーで、その新婚家庭のリビングのみで話は進む。
いわゆるシチュエーションコメディーっぽいもので、旗揚げ公演にしてはよく出来ているんじゃないかと思う。
妹の役は、主役となる新婚夫婦の新妻。つまり、一応「ヒロイン」。
もっとも、お話は「夫が二股をかけていて、昔からの恋人が家に押しかけてきたのに、なんとかごまかそうとすることから起こるドタバタ劇」なので、本当の主役は夫。
（この内容だと女同士の喧嘩になりそうだが、夫のごまかしのせいで、女二人が相手が何者か知らないまま意気投合してしまうのが見所。話が微妙に噛み合わず、その状況で慌てまくる夫が非常に面白い）
ここで内容を紹介しても仕方が無いので書かないが、思ったよりも実力のある劇団だということはわかった。
主役の夫、その「昔からの恋人」、なぜか巻き込まれる準主役の「アパート管理人」…など、主要メンバーの演技力は悪くなかったし。
…妹の演技が劣って見えるのは、身内の厳しい目だからか？
Synchronized, wait & notify 2002-10-31 17:58:01 COMP
今年の風邪はしつこくて、まだ病み上がりな感じだ。
体が完調でない間も、Java プログラムを細々と作りつづけている。
以前に i-アプリとして作ったものの移植…だったはずが、i-アプリと EZplus の機能があまりに違うことや、せっかくだから機能アップしたいという欲が出たこともあり、大幅な作り直しとなっている。
どのくらい違うかといえば、MS-DOS と Windows 3.1 くらい違う。 Win95 ほど違うという自信はない (^^;;
つまり「見た目が良くなりました」ってこと。
中身はそれほど変わらないのだが、見た目を整えるというのは思った以上に大変なことなのだ。
今月の頭から作っているのに、まだまだα版と呼べるレベルまでも達していない。
一から作っているので、以前は持っていた機能をまだ持っていなかったりもする。
---
Java は「マルチスレッド」を前提としたプログラム言語なので、スレッド同期の命令がしっかりしている。
UNIX などでもマルチスレッドなプログラムは組めるが、C で組むことになるので注意を払って同期するような処理を自分で加えないといけない。
Java では、命令を「synchronized」というブロックで囲むだけで、他の synchronized ブロックと同時に実行されないことが保証される。
synchronized の中で別の synchronized に動いて欲しい、というときはどうするか？
wait を使う。wait すると、その時点でスレッドは休止し、別のスレッドに処理を明け渡す。
休止してしまったプログラムを起こすにはどうするか？
notify を使う。notify すると、休止している別のスレッドを叩き起こす。
この３つの機能が非常に良く出来ていて、スレッドプログラムは Java の腕の見せ所のひとつだ。
---
実は、腕の見せ所であるだけに、ここらへんの命令はしっかり意味を理解して使わないとはまりやすい。
以前 i-アプリのプログラムを作った時に、結構はまった。
そして、今日また移植版のプログラムを作っていてはまった(笑）
学習してないなぁ、と思うが、Java なんてめったに使わないんだもん。
体が完調でない間も、Java プログラムを細々と作りつづけている。
以前に i-アプリとして作ったものの移植…だったはずが、i-アプリと EZplus の機能があまりに違うことや、せっかくだから機能アップしたいという欲が出たこともあり、大幅な作り直しとなっている。
どのくらい違うかといえば、MS-DOS と Windows 3.1 くらい違う。 Win95 ほど違うという自信はない (^^;;
つまり「見た目が良くなりました」ってこと。
中身はそれほど変わらないのだが、見た目を整えるというのは思った以上に大変なことなのだ。
今月の頭から作っているのに、まだまだα版と呼べるレベルまでも達していない。
一から作っているので、以前は持っていた機能をまだ持っていなかったりもする。
---
Java は「マルチスレッド」を前提としたプログラム言語なので、スレッド同期の命令がしっかりしている。
UNIX などでもマルチスレッドなプログラムは組めるが、C で組むことになるので注意を払って同期するような処理を自分で加えないといけない。
Java では、命令を「synchronized」というブロックで囲むだけで、他の synchronized ブロックと同時に実行されないことが保証される。
synchronized の中で別の synchronized に動いて欲しい、というときはどうするか？
wait を使う。wait すると、その時点でスレッドは休止し、別のスレッドに処理を明け渡す。
休止してしまったプログラムを起こすにはどうするか？
notify を使う。notify すると、休止している別のスレッドを叩き起こす。
この３つの機能が非常に良く出来ていて、スレッドプログラムは Java の腕の見せ所のひとつだ。
---
実は、腕の見せ所であるだけに、ここらへんの命令はしっかり意味を理解して使わないとはまりやすい。
以前 i-アプリのプログラムを作った時に、結構はまった。
そして、今日また移植版のプログラムを作っていてはまった(笑）
学習してないなぁ、と思うが、Java なんてめったに使わないんだもん。