Laboratory of Mobile Agricultural Chemicals Searcher
携帯農薬検索実験室

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
38 / 114 ﾂﾘｰ <前へ | 次へ>
〔699〕新検索システム検討中 Hidemi Oya (07/08/20 15:19)
〔700〕PHP で SQLite3 を使う Hidemi Oya (07/08/20 16:22)
〔704〕PHP で SQLite3 を使う（２） Hidemi Oya (07/08/27 22:02)
〔706〕PHP で SQLite3 を使う（３） Hidemi Oya (07/08/28 22:37)
〔709〕嵌ってしまったorz Hidemi Oya (07/09/02 14:46)
〔710〕嵌ってしまった（２） Hidemi Oya (07/09/02 21:01)
〔708〕自前サーバが不要に Hidemi Oya (07/09/01 22:04)
〔711〕自前サーバがやっぱり必要 Hidemi Oya (07/09/03 22:45)
〔712〕自前サーバ立ち上げで決定 Hidemi Oya (07/09/04 21:36)
〔727〕自前サーバ中間報告 Hidemi Oya (07/11/08 0:52)
〔728〕Re:自前サーバ中間報告 Hidemi Oya (07/11/09 1:09)
〔729〕静かだが… Hidemi Oya (07/11/13 23:36)
〔764〕Re:静かだが… Hidemi Oya (07/11/23 22:44)
〔701〕ACFinder データベース流用伺い Hidemi Oya (07/08/20 16:32)
〔702〕Re:ACFinder データベース流用伺い kabe (07/08/21 21:02)
〔703〕Re:ACFinder データベース流用伺い Hidemi Oya (07/08/21 23:06)
〔705〕Re:ACFinder データベース流用伺い kabe (07/08/27 22:32)
〔707〕Re:ACFinder データベース流用伺い Hidemi Oya (07/08/28 22:46)
〔699〕新検索システム検討中
 Hidemi Oya WEB  (07/08/20 15:19)
引用なし
   　現在の薬検の検索システムをそのまま使って携帯用に翻訳する方法では、これ以上使い勝手を向上させるのは難しくなってきました。これ以上現行システムに手を入れるのは時間の無駄かなという気がしています。
　また、JPP-NET 版を作っても使える人は限られるし、翻訳システムの制約はそのまま残るので薬検版より使いにくそうです。今更ＰＣ→携帯翻訳システムには技術的興味もないので、食指も動きませんし…。

　で、やっぱり独自検索システムに移行しようかなということでいろいろ考えてたら、ACFinder のデータベースって屋号抜き農薬名とか毒性とかデータが充実してるんですよね。おまけに、このサイトで使っている XREA は SQLite2/3 のエンジンが標準搭載されていて、PHP4/5 (perl でも良いんですが)で簡単にアクセスできます。
　てえことは、ACFinder のデータベースをそのまま使えば、薬検の Excel データから新たにデータベースを作り直すこともなく、簡単に独自検索システムができるってえ寸法です。
　元データは薬検の Excel データなので、完成したら薬検に公開して良いかどうかのお伺いを立てる必要はありますが、現在この方向でいろいろ試験中です。　
〔700〕PHP で SQLite3 を使う
 Hidemi Oya WEB  (07/08/20 16:22)
引用なし
   　このサイトで使用している XREA のサーバでは、Apache モジュール版の PHP4 と CGI 版の PHP4/5 が使えます。SQLite は本来 PHP5 からの対応ですが、XREA の仕様では PHP4/5 ともに SQLite2/3 が使えることになっています。

　レガシー関数の sqlite_* 関数は PHP4/5 ともに使えましたが、SQLite2 のみで ACFinder の acis.db を sqlite_open() で開くことはできませんでした。
　では、どうやって SQLite3 のデータベースを操作するかというと、PHP4 の場合は、PHP マニュアルには載っていない sqlite3_* 関数が別途用意されていました。これで問題なく acis.db を操作できますが、sqlite3_num_rows と sqlite3_field_name 関数が実装されていません(この２つは SQLite2 版も実装されていません)。field_name の方は検索結果を取得するときにハッシュのキーとして渡されるのでなくてもなんとかなりますが、num_rows がないのはちょっと辛いです。
　PHP5 の場合は、元々 PDO モジュールで経由で SQLite3 データベースにアクセスするのが標準です。が、私の使用しているサーバでは、SQLite2 のドライバはインストール済みでしたが、残念ながら SQLite3 のドライバがインストールされていないようで、acis.db を操作することはできませんでした。とりあえずサポートに SQLite3 ドライバのインストールを要望中です。

　PHP で SQLite を扱うときに優れているのは、sqlite 関数、PDO_SQLITE 関数とも create_function がサポートされていて、PHP のユーザ関数を簡単に SQLite の関数として登録できるところです。私が使用しているサーバの SQLite3 エンジンには REGEXP 関数が実装されていませんでしたが(MATCH 関数は実装されてますが恐らく全文検索用です)、下記のような感じで簡単に REGEXP 関数(もちろん演算子も)が使えるようになりました(ユーザ関数のパラメータの順番が不明だったのと、create_function のパラメータの順番がマニュアルと異なったので若干悩みましたが^^;)。

function _regexp($pattern, $target) {
　return (int)(mb_eregi($pattern, $target) !== FALSE);
}

$db = sqlite3_open('acis.db');
sqlite3_create_function($db, 'regexp', 2, '_regexp');
〔701〕ACFinder データベース流用伺い
 Hidemi Oya WEB  (07/08/20 16:32)
引用なし
   >　元データは薬検の Excel データなので、完成したら薬検に公開して良いかどうかのお伺いを立てる必要はありますが、現在この方向でいろいろ試験中です。　
　薬検の前に、kabe さんに ACFinder のデータベースを流用して良いかどうか伺う必要がありましたね。ここで断られたら元の木阿弥です(^_^;)。kabe さん、よろしいでしょうか？

　本当は、s_kobayashi さんのシステムやできれば農薬ナビも含めて全て同じデータベースを使用して、みんなでデータベースを拡充していければもっと良いんですけどね。
〔702〕Re:ACFinder データベース流用伺い
 kabe WEB  (07/08/21 21:02)
引用なし
   ＞Hidemi Oyaさん
>　薬検の前に、kabe さんに ACFinder のデータベースを流用して良いかどうか伺う必要がありましたね。ここで断られたら元の木阿弥です(^_^;)。kabe さん、よろしいでしょうか？

私の方は何ら問題ありません。
Hidemi Oya さんの SQLite ライブラリを利用して作成しているデータベースでもありますので、ぜひ活用してください。

私も acis.db をサーバに置いて、検索するシステムを作れないかなと思ってはいるのですが、Web系はほとんど知識がないので、ソースの公開にも期待しております。
〔703〕Re:ACFinder データベース流用伺い
 Hidemi Oya WEB  (07/08/21 23:06)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>私の方は何ら問題ありません。
>Hidemi Oya さんの SQLite ライブラリを利用して作成しているデータベースでもありますので、ぜひ活用してください。
　ご快諾ありがとうございます。これで、安心して開発できます。

>私も acis.db をサーバに置いて、検索するシステムを作れないかなと思ってはいるのですが、Web系はほとんど知識がないので、ソースの公開にも期待しております。
　もちろん、完成したらソースは公開します。が、現在 [#700] に書いたような理由で、まともに開発できる環境がありません。とりあえず、XREA にお願いはしていますが、時間がかかるようなら SQLite3 -> SQLite2 コンバータを作成して対処するしかないかなあと考えています。

　ところで、独自システム開発の上で、現行 ACFinder のデータベースにひとつ問題があります。それは、分類コードと結びついた作物 ID を持つ作物名テーブルが存在しないところです。これがないと、ウェブ検索システムで上位分類一括検索を実装するために、別途作物名テーブルを作成しなくてはなりません。
　現在、作物名テーブルは連番で作成していますが、これを sakumotu.htm の作物 ID 使って作成するように変更していただけると、新システムで非常に使いやすくなります。併せて、病害虫名テーブルも同様に作成していただけるとさらに good です。ぜひご検討ください。
〔704〕PHP で SQLite3 を使う（２）
 Hidemi Oya WEB  (07/08/27 22:02)
引用なし
   　XREA に PHP5 の PDO 用 SQLite3 ドライバのインストールを要望してから１週間以上経過しましたが、完全に放置状態です(;_;)。coreserver ができてから、サポートの体制が今まで以上に悪くなったような…。
　以前の要望に対して、コンパイルが必要なモジュールは PHP のアップデート時に対応しますというコメントがあったので、5.2.3 にアップデートする時までインストールしてもらえない可能性が大ですね。

　PHP で SQLite を使うには、レガシー関数や PDO のほかに、PEAR の DB, MDB2 などがありました。が、いずれも SQLite2 のみで(XREA にはオリジナルには存在しない DB_Driver_sqlite3.php が入っていたので、DB では SQLite3 が使えそうですが)、最大のネックは create_function や create_aggregate に対応していないところです。これができないと、今回のプロジェクトでは使えません。
　一応、レガシー関数版で num_rows, field_name 相当の機能は実装しましたが、あまりスマートではありません。やはり PDO 版が使いたいところです。

　perl では、DBI で問題なく SQLite3 が使用でき、create_function, create_aggregate にも対応してました。オブジェクトなので、PDO のように使いやすそうです。
　が、全角文字のハンドリングが perl より PHP の方が楽なんですよね。PHP なら mb_strtoupper で全角の 'ｍｅｐ' を 'ＭＥＰ' に変換できたりしますが、Unicode::Japanese でもここまでの機能はありません。

　ということで、PDO が使えるようになるまで待つか、あるいは perl で開発するか思案してました。最後の手段として coreserver の利用も睨みながら VALUE-DOMAIN の規約などを調べていたら、XREA+ 利用権の移転なんて手法があったんですね。とりあえず新しいサーバで無料アカウントを取得して、こちらが使えそうなら XREA+ の利用権を新サーバに移せるようです。
　当面、こいを検討してみることにします。

　それはそれとして、coreserver の CGI やモジュール版 PHP のリソース配分はなかなか魅力的です。この割り当てメモリ容量や実行制限時間なら、perl や PHP で xls -> acis.db 変換が可能かも…。中古の WindowsXP マシンを購入して自前サーバ立てるのと、どっちがいいかな。
〔705〕Re:ACFinder データベース流用伺い
 kabe WEB  (07/08/27 22:32)
引用なし
   ＞Hidemi Oyaさん

>　現在、作物名テーブルは連番で作成していますが、これを sakumotu.htm の作物 ID 使って作成するように変更していただけると、新システムで非常に使いやすくなります。併せて、病害虫名テーブルも同様に作成していただけるとさらに good です。ぜひご検討ください。
以前からの修正候補ではありましたが、未だに手をつけていません。
これについては、できるだけ早く実現できるようにしたいと思います。
〔706〕PHP で SQLite3 を使う（３）
 Hidemi Oya WEB  (07/08/28 22:37)
引用なし
   >とりあえず新しいサーバで無料アカウントを取得して、こちらが使えそうなら XREA+ の利用権を新サーバに移せるようです。
>　当面、こいを検討してみることにします。
　モジュール版 PHP が 5.2.3 のサーバで試してみました。PDO で SQLite3 が問題なく使え、regexp 演算子も簡単に実装できます。
　が、numRows は SELECT 文では使えず、sqlite_field_name に相当するメソッドも無いので、別途実装する必要があります。PDO を継承した拡張クラスを作成するのが良さそう…。
　検索速度は、PHP5 + PDO だとネイティブ関数の sqlite3_* にはやや劣る感じがします。明らかに体感できるほどの差ではないので、使いやすさも考えると、PDO の方が有利です。
　また、PHP5 にはさすがに sqlite3_* 関数が存在しませんでしたが、CGI 版の PHP 4.4.7 には実装されてました。

　PHP5 + PDO, PHP4 + sqlite3_*, perl + DBI のいずれで行くかまだ決めかねているところはありますが、どれでも使えるという面では、やはり新サーバに移行するのが正解でしょうね。で、新サーバに移行するなら、PHP5 + PDO が最右翼ではあります。

　サーバ移行にあたって、現行サーバのディスク使用量を調べてみたら、250MB 使ってました。無料サーバは 50MB なので、これを全部移行するのは無理ですね。でも、とりあえず評価中の CMS ２つがかなり容量を食っていたので、いらないものを全部削除したら、34MB にまで削減できてしまいました(全然使ってないなあ^^;)。金曜か土曜の深夜に、移行することにします。
〔707〕Re:ACFinder データベース流用伺い
 Hidemi Oya WEB  (07/08/28 22:46)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>これについては、できるだけ早く実現できるようにしたいと思います。
　まだ環境が整っていないので、それほどは急ぎません。余裕のあるときにでも対応していただければうれしいです。

　作物名／病害虫名テーブルは、新方式だとおそらくほとんど変更はないと思われます。acis.db に入れてしまうと、データ更新のたびにテーブル再作成が必要になって更新がさらに遅くなるので、別データベースで作成して ATTACH するのが良さそうですね。
〔708〕自前サーバが不要に
 Hidemi Oya WEB  (07/09/01 22:04)
引用なし
   >　それはそれとして、coreserver の CGI やモジュール版 PHP のリソース配分はなかなか魅力的です。この割り当てメモリ容量や実行制限時間なら、perl や PHP で xls -> acis.db 変換が可能かも…。中古の WindowsXP マシンを購入して自前サーバ立てるのと、どっちがいいかな。
　coreserver のお試しサーバを取得してみました。
　perl + SpreadSheet::ParseExcel で試してみたところ、OutOfMemory で登録適用部一の xls ファイルを読めませんでした。coreserver は CGI に 160MB まで割り当ててくれるので、それでもメモリ不足というのは、どうやら ParseExcel モジュールのメモリ管理に問題がありそうです。
　PHP + Spreadsheet_Excel_Reader では、登録適用部一.xls -> テキスト変換が 10 秒程度で実行可能です。現行 XREA 有料サーバが 33 秒なので、かなり速いです。
　また、xlhtml が標準搭載されていたので試してみたところ、登録適用部一.xls -> テキスト変換が１秒程度で可能でした。が、随所に String Table Error が入ってしまいます。

　ついでに、最近取得した XREA の無料サーバでも PHP で登録適用部一の変換をしてみたところ、12 秒となかなか高速でした。まだユーザ数が少ないため変換が速いのだと思われます。ユーザが増えてくると、おそらく現行有料サーバ並みの速度になってしまうんでしょうね。
　あと、先日 SSH で無料サーバと現行サーバに入って /usr ディレクトリ内を見ていたら、どちらも xlhtml が入っていました。これで試したところ、どちらも登録適用部一の変換が数秒で可能でした。ただし、coreserver 同様に String Table Error が入ります。

　ついでに、String Table Error になっているセルの元データを確認したところ、どうも空白セルに文字列を示す「'」が単独で入っているのが原因のようです。これなら、'String Table Error' の部分をヌルストリングに変換すれば良さそうです。
　ついでに、半角カタカナを全角カタカナに変換したり、「"」を「”」に変換するなどの正規化ルーチンを PHP で書いてみたところ、現行サーバでも登録適用部一の変換が３秒かからないで可能でした。xlhtml による xls -> テキスト変換と文字列正規化をあわせてもかかって５秒程度でしょう。この程度の時間なら、coreserver でなくても XREA で十分使い物になります。

　ってことで、coreserver も自前サーバも使うことなく、xls -> acis.db 変換ができそうです。せかっく FTTH を固定 IP でつかっているのに、また自前サーバの野望が遠のいてしまいました(^_^;)。
〔709〕嵌ってしまったorz
 Hidemi Oya WEB  (07/09/02 14:46)
引用なし
   >金曜か土曜の深夜に、移行することにします。
　土曜日の深夜に s70 から s301 に移行しました。
　XREA のサーバ間コピーを使ってデータは簡単に移せました。サーバ間コピーでは、/public_html 以下のディレクトリのみコピーするのが良さそうです。/Maildir にあるメールボックスをコピーしてもダメで、削除してメール設定を一からやり直しました。

　サーバを移行して、問題が２つ発生。ひとつは当サイトのトップページのトピックコラムが文字化けすること、もうひとつは CoolON Project の BBS が表示されなくなったことです。

　トピックコラムは MySQL にデータを保存して、PHP で読み出して表示しています。最初は PHP4 から PHP5 に変わったことで各種 encoding の設定も変わったのかと思ったんですが、いろいろ確認しても問題なしで、いろいろ試しても変化なし。CGI 版 PHP4 で実行しても同じなので、PHP の問題ではないと断定。
　じゃあ MySQL4 から MySQL5 に変わったのが原因かと、phpMyAdmin でデータベースの内容や各種 encoding を確認しても問題なし。しかも、同じデータベース、同じ encoding で使っている薬検ＤＢ検索 perl 版 3.0.RC4 は問題なく動作しています。てえことは、MySQL5 の問題でもなさそう。
　ここまで数時間を費やして、最後に残ったのが、PHP と MySQL5 のインターフェースの問題です。PHP と MySQL5 の各種 encoding を無視して、勝手な encoding でやりとりをしてるのではないかと…。今まで使っていた mysql_* 関数ではインターフェースの encoding が不明なので、mysqli_* で書き直してみたところ、インターフェースが latin1 になってました。mysqli_set_charset でようやく解決できました。
　でも、mb_* 系関数の encoding で UTF-8N は 'UTF-8'、mysqli_set_charset では 'utf8' という違いがあって、ここでもちょっと嵌っちゃったんですけどね(^_^;)。

　CoolON Project の BBS はこれから原因究明ですが、全く同じ掲示板システム、全く同じ PHP スクリプトによるメニューの FAQ と Report は表示されているので、こいつはかなり手強そうです。さて、どうしたものか…。
〔710〕嵌ってしまった（２）
 Hidemi Oya WEB  (07/09/02 21:01)
引用なし
   >　CoolON Project の BBS はこれから原因究明ですが、全く同じ掲示板システム、全く同じ PHP スクリプトによるメニューの FAQ と Report は表示されているので、こいつはかなり手強そうです。さて、どうしたものか…。
　こちらは、PHP しか使っていないので(掲示板システムは perl)、PHP4 と PHP5 の違いに起因するものだろうとは思ってました。で、Support メニューの PHP スクリプトを CGI 版 PHP4 で動かしてみたら、問題なく動作しました。
　いろいろ調べてみたところ、preg_replace の挙動が微妙に違うようです。とりあえず mb_ereg_replace に置き換えて OK となりました。どこがどのように違うのかまでは確認しませんでしたが、'm' モディファイアの挙動がクサイです。

　ついでに、英語版 CoolON Project は eXcite の自動翻訳を使ってたんですが、これの URL が微妙に変わってたりして、以前のように動作しなくなっていることに気づいたので、これも修正しました。
　なんだかんだで、やっぱり数時間かかってしまいました。
〔711〕自前サーバがやっぱり必要
 Hidemi Oya WEB  (07/09/03 22:45)
引用なし
   >　ってことで、coreserver も自前サーバも使うことなく、xls -> acis.db 変換ができそうです。せかっく FTTH を固定 IP でつかっているのに、また自前サーバの野望が遠のいてしまいました(^_^;)。
　新サーバで試してみたところ、現在の薬検の xls ファイルでは、登録適用部二／三が xlhtml でも PHP + Excel_Reader でも正常に読めません。いずれの場合でも、ほぼ同じ結果(ほとんど空白セルになる)になるので、OLE を読むライブラリが同じアルゴリズムなのかもしれません。
　xlhtml は buffer overrun が表示されるので、割り当てメモリ不足かメモリ管理上の問題だと思われます。後者が原因なら、リソース割り当ての多い coreserver でも同じ結果になりそうですが、すでにお試し coreserver は削除してしまったので未確認です。
　考えてみたら、去年の今頃も同じ問題に引っかかってたのですが、１年前のことなので、すっかり忘れてました(^_^;)。

　いずれにしても、xls -> acis.db は XREA+ ではやはり無理なようです。coreserver の方は可能性がありますが、もし使えたとしても変換ルーチンを新たに書く必要があります。
　やはり、自前サーバを立ち上げて、ACFinder でデータベースを更新するのが最も手っ取り早そうです。１台余ってはいるのですが、でかい＆うるさいので、中古の省スペースマシンを見繕わねば。

>　ついでに、最近取得した XREA の無料サーバでも PHP で登録適用部一の変換をしてみたところ、12 秒となかなか高速でした。まだユーザ数が少ないため変換が速いのだと思われます。ユーザが増えてくると、おそらく現行有料サーバ並みの速度になってしまうんでしょうね。
　これを確認したとき、新サーバは PHP5 で、前サーバは PHP4 で確認しました。今回、新サーバで CGI 版 PHP4/5 の両方で「登録適用部二.xls」を変換してみたところ、PHP5 で 16〜17 秒、PHP4 で 31〜32 秒でした。
　どうやら、負荷の問題ではなく、PHP4 と PHP5 の実行速度の差によるもののようです。しかし、PHP4 と PHP5 でここまで速度差があるとは思いませんでした。
〔712〕自前サーバ立ち上げで決定
 Hidemi Oya WEB  (07/09/04 21:36)
引用なし
   >　xlhtml は buffer overrun が表示されるので、割り当てメモリ不足かメモリ管理上の問題だと思われます。後者が原因なら、リソース割り当ての多い coreserver でも同じ結果になりそうですが、すでにお試し coreserver は削除してしまったので未確認です。
　本日公開の「2007年8月失効反映分」で確認したところ、xlhtml では「登録適用部三.xls」のみ空白セルばかりで正常に変換できませんでした。で、お試し coreserver を再取得して確認したところ、coreserver でも同様の結果となりました。coreserver では CGI に 160MB のメモリが割り当てられるので、リソース配分の問題ではなく、xlhtml のメモリ管理上の問題のようです。

　ということで、これで coreserver をすっぱりあきらめて、自前サーバを立てる決心が付きました。当面は手動で acis.db を更新するとして、本格的に新システムが稼働するようになったら、自前サーバで acis.db を自動更新しようと思います。

　それと、coreserver の ML システムは、VALUE-DOMAIN の Mail&Backup プランと同じ Mailman で、これがあまり使いやすくありません。Windows で自前サーバを立ち上げるなら、XMail で ML を立ち上げようかなと考えています。
　XMail の ML アーカイブ管理ソフトである kml がなかなか優秀で、ウェブブラウザからの投稿もできるので ML 兼 BBS システムが簡単に構築できます。今のところスレッド表示に対応していないのが難点ですが、TODO リストに入っているので大いに期待しています。
〔727〕自前サーバ中間報告
 Hidemi Oya WEB  (07/11/08 0:52)
引用なし
   >当面は手動で acis.db を更新するとして、本格的に新システムが稼働するようになったら、自前サーバで acis.db を自動更新しようと思います。
　新システムを作る前に、とりあえず自前サーバを立ち上げてしまいました。マシンは、中古の NetVista M42 Slim 6920-62J です。サイズ的には AcerPower くらいのものが良かったんですが、中古だとほとんどありません。スリム PC の中でもなるべく小型のもので、静かで省電力マシンということで、これになりました。価格は、増設メモリ 128MB と WindowsXp Professional (SP2 アップデート済み)付きで、DSP 版の WindowsXp Professional よりやや高いってことろでした。


　メモリは付いてきたものを外して、余りパーツで 1GB にしています。この状態で、ワットチェッカーで消費電力を確認したところ、起動時に 60W 前後(最大 68W)になるものの、起動完了後は 34W で安定してました。なかなかの省エネマシンです。
　音もかなり静かです。何でこんなに静かなのかと思ったら、起動の時に少し CPU ファンが回るだけで、WindowsXp の起動画面に切り替わる頃には CPU ファンが止まってしまいます。こんなんで大丈夫なのかなと思いましたが、CPU ファンが止まっていてもヒートシンクはぬるいままでした。Celeron 2.0GHz の特別仕様版はダテじゃないようです。とはいえ、熱伝導シートの劣化で CPU の熱が伝わらなくてヒートシンクがぬるいままということもあり、これで痛い目に遭ってますので、ちょっと心配(^_^;)。

　ELECOM のパソコン切替器が 2,980 円と安かったので、これでサーバと常日頃使うマシンを切り替えながら使っています。パソコン切替器は、昔は高くて 1024x768 くらいまでにしか対応していなかったりしましたが、今はこんな安くても 2048x1536 まで対応してるんですね。いや〜、時代は変わった…。
　ルータの LAN ポートが足りなかったので５ポートのスイッチングハブも購入しましたが、CATV 時代に使っていたルータが余っているので、DMZ にサーバ、DMZ の内側に家庭内 LAN という形にすることも検討中です。

　サーバソフトは、全てフリーソフトです。HTTP サーバは AnHttpd が設定が楽ですが、モジュール版 PHP を使えるようにしたかったので、Apache 2.2.6 にしました。これに、ActivePerl 5.8.8 と PHP 5.2.4 を入れています。あと SQLite を入れれば、LAMP (Linux Apache MySQL Perl|PHP)環境ならぬ、WASP 環境のできあがりです。
　DMZ にサーバを置くなら、FTP サーバも入れなきゃですね。
〔728〕Re:自前サーバ中間報告
 Hidemi Oya WEB  (07/11/09 1:09)
引用なし
   >あと SQLite を入れれば、LAMP (Linux Apache MySQL Perl|PHP)環境ならぬ、WASP 環境のできあがりです。
　PHP も perl も、SQLite ドライバが RDBMS を兼ねてるようで、特に sqlite3.dll 等を設定する必要はないようですね。逆に言うと、sqlite3.dll が新しくなっても、ドライバが更新されない限り使用可能な SQLite のバージョンは変わらないようです。
　う〜ん、便利なようで不便な仕様だ…。

　ようやく、apache が思った通りに動作する設定になりました。kabe さんのおかげで データベース自動更新のメドもついたので、いよいよ本格的なシステム開発です。
〔729〕静かだが…
 Hidemi Oya WEB  (07/11/13 23:36)
引用なし
   >　音もかなり静かです。何でこんなに静かなのかと思ったら、起動の時に少し CPU ファンが回るだけで、WindowsXp の起動画面に切り替わる頃には CPU ファンが止まってしまいます。
　CPU ファンは回ったり止まったりしますが、もうひとつのファンであるケースファンは常に一定回転で回っているようです(電源はファンレス)。で、自分の PC が立ち上がってたり、TV がついてたりするとケースファンの音は全く気になりませんが、他の物音がしない深夜や早朝は、ケースファンの音が結構気になります。
　ケースファンの静音化に取り組まねば…。
〔764〕Re:静かだが…
 Hidemi Oya WEB  (07/11/23 22:44)
引用なし
   >　ケースファンの静音化に取り組まねば…。
　ケースファンは、CPU ファンと違って停止してしまうことはありませんが、起動時に比べると風量が格段に減っているので、回転数の制御はしているようです。それでも、深夜・早朝で他に物音がしないときは、ケースファンの音がかなり大きく聞こえます。
　とりあえず、３年以上前に購入して、結局使わなかったダイポルギーのファンサイレンサーがあったので、取り付けてみました。わずかに静かにはなりますが、十分とはいえません。
　う〜ん、より低回転のファンに付け替えるしかないのかなあ…。
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
38 / 114 ﾂﾘｰ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.