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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
38 / 114 ツリー <前へ | 次へ>

〔699〕新検索システム検討中 Hidemi Oya (07/08/20 15:19)

〔704〕PHP で SQLite3 を使う(2) Hidemi Oya (07/08/27 22:02)
〔706〕PHP で SQLite3 を使う(3) Hidemi Oya (07/08/28 22:37)
〔709〕嵌ってしまったorz Hidemi Oya (07/09/02 14:46)
〔710〕嵌ってしまった(2) 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)

〔704〕PHP で SQLite3 を使う(2)
 Hidemi Oya WEB  (07/08/27 22:02)

引用なし
    XREA に PHP5 の PDO 用 SQLite3 ドライバのインストールを要望してから1週間以上経過しましたが、完全に放置状態です(;_;)。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 で全角の 'mep' を 'MEP' に変換できたりしますが、Unicode::Japanese でもここまでの機能はありません。

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

 それはそれとして、coreserver の CGI やモジュール版 PHP のリソース配分はなかなか魅力的です。この割り当てメモリ容量や実行制限時間なら、perl や PHP で xls -> acis.db 変換が可能かも…。中古の WindowsXP マシンを購入して自前サーバ立てるのと、どっちがいいかな。

〔706〕PHP で SQLite3 を使う(3)
 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 2つがかなり容量を食っていたので、いらないものを全部削除したら、34MB にまで削減できてしまいました(全然使ってないなあ^^;)。金曜か土曜の深夜に、移行することにします。

〔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 -> テキスト変換が1秒程度で可能でした。が、随所に String Table Error が入ってしまいます。

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

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

 ってことで、coreserver も自前サーバも使うことなく、xls -> acis.db 変換ができそうです。せかっく FTTH を固定 IP でつかっているのに、また自前サーバの野望が遠のいてしまいました(^_^;)。

〔709〕嵌ってしまったorz
 Hidemi Oya WEB  (07/09/02 14:46)

引用なし
   >金曜か土曜の深夜に、移行することにします。
 土曜日の深夜に s70 から s301 に移行しました。
 XREA のサーバ間コピーを使ってデータは簡単に移せました。サーバ間コピーでは、/public_html 以下のディレクトリのみコピーするのが良さそうです。/Maildir にあるメールボックスをコピーしてもダメで、削除してメール設定を一からやり直しました。

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

 トピックコラムは MySQL にデータを保存して、PHP で読み出して表示しています。最初は PHP4 から PHP5 に変わったことで各種 encoding の設定も変わったのかと思ったんですが、いろいろ確認しても問題なしで、いろいろ試しても変化なし。CGI 版 PHP4 で実行しても同じなので、PHP の問題ではないと断定。
 じゃあ MySQL4 から MySQL5 に変わったのが原因かと、phpMyAdmin でデータベースの内容や各種 encoding を確認しても問題なし。しかも、同じデータベース、同じ encoding で使っている薬検DB検索 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〕嵌ってしまった(2)
 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 は削除してしまったので未確認です。
 考えてみたら、去年の今頃も同じ問題に引っかかってたのですが、1年前のことなので、すっかり忘れてました(^_^;)。

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

> ついでに、最近取得した 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 ポートが足りなかったので5ポートのスイッチングハブも購入しましたが、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 ファンと違って停止してしまうことはありませんが、起動時に比べると風量が格段に減っているので、回転数の制御はしているようです。それでも、深夜・早朝で他に物音がしないときは、ケースファンの音がかなり大きく聞こえます。
 とりあえず、3年以上前に購入して、結局使わなかったダイポルギーのファンサイレンサーがあったので、取り付けてみました。わずかに静かにはなりますが、十分とはいえません。
 う〜ん、より低回転のファンに付け替えるしかないのかなあ…。

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
38 / 114 ツリー <前へ | 次へ>
ページ:  ┃  記事番号:   
(SS)C-BOARD vv3.8 is Free.