2003/05/02(金) [n年前の日記]
#1 [pc][prog] zeus.cgiにおいて、timeの取得は正常動作してるようにみえる
Y氏が確認スクリプトを設置してくれた。thx。
◎ 予想が外れた :
結果を見てみたところ、$ENV{'TZ'} = "JST-9" の指定はたしかに反映されているらしく、日本時間が帰ってきている。となると昨日の自分の予想は外れた (;´Д｀)
◎ 他に考えられるのは :
他にあり得るとすれば、タイムゾーン指定をせずにtime値を取得してしまってる部分があるとか、あるいはファイルのタイムスタンプを時間の比較処理に利用してるとか、そういう感じだろうか。それとも、もっと別のところに…と言っても、国内サーバに設置すると正常動作するのに、海外サーバに設置すると異常動作するとなれば、やはりタイムゾーン関係ぐらいしかないような気も。なんにせよ、ソースとにらめっこしないと。
◎ クッキー関連の処理でgmtime使うのは問題無しみたい :
昨日、疑問に思った、
_クッキー関連の処理でgmtimeを使う云々
は特に問題無し、ていうかそうするのが正解みたい。なるほど、勉強になったス。
◎ 自分も海外サーバに設置してみようかな :
この記事へのツッコミ
[ ツッコミを読む(2) | ツッコむ ]
#2 [hns] ツッコミをhnfと同列に扱いたい
なんか前にも似たような事を書いたような気がするんだけど。もう一回まとめておこう。
hns導入後、各記事に、非常に為になる有用なツッコミを入れてもらえて助かってたり。これだけでもhns導入した甲斐があったかも。thxです。
hns導入後、各記事に、非常に為になる有用なツッコミを入れてもらえて助かってたり。これだけでもhns導入した甲斐があったかも。thxです。
◎ 現状のhnsにおけるツッコミ機能の問題点 :
しかし、hnsのツッコミ機能は、あくまで掲示板の一種として実装されてる為に問題点があって。hns導入時から懸念してた事だけど、仮に、ある記事で有用な議論が展開された場合、現状のhnsの仕様ではそれら議論を確実に残す事が出来ず、書き込み件数が指定数を超えるとちょっと困った事になる。と言っても今のところ、書き込み件数の設定値をかなり大きい値にしてるので、このペースならあと数年は余裕で持つだろうし、実際に問題は起きないような気もしつつ。
*1
それでも仕様的には、やはり問題として残っちゃってるわけで。
*2
◎ hnsの思想 :
例えばこういったところにも、hnsの思想が見え隠れしているような気もする。おそらく開発者達は、『「hns運用者＝書き手」の残すhnfファイル』と『読者によるツッコミ文章』を無意識 or 意識的に比較して、『情報の価値としては、hnf ＞ ツッコミ』と判断した上で仕様決定していたのかな、と。開発者達には、「自分達のほうが読者より、よほど優れた文章・情報を提供するはず」だから「ツッコミ内容は残らなくても問題無し」という自信なり考えなりがあったのではないかと。
しかし、自分などは、自分の書くタコ電波文章より、読者のツッコミの方が、客観性を持つ分、情報としては有用なものが多いのではないかなと思ったりしていて、こういった「読者より書き手のほうがとにかく偉いんだぞー」的思想には首を捻るというか。 *3 かと言って、自分にはガリガリ改造してくだけのスキルも無いわけで。困った。
しかし、自分などは、自分の書くタコ電波文章より、読者のツッコミの方が、客観性を持つ分、情報としては有用なものが多いのではないかなと思ったりしていて、こういった「読者より書き手のほうがとにかく偉いんだぞー」的思想には首を捻るというか。 *3 かと言って、自分にはガリガリ改造してくだけのスキルも無いわけで。困った。
◎ 現実的な対策 :
仮に、ツッコミ内容をhnfファイルと同列に扱おうとした場合、自分でも出来そうな対策としては、掲示板のログ内容を該当hnfに混入していくようなスクリプトを書くぐらいだろうか。とてもじゃないけどhns本体は難しくて弄れそうにないし。と思ったけど、ツッコミ内容をhnfに混入したら、ツッコミである事がパッと見てわかるようなコマンドを新規に用意しないといけない。うわー面倒臭そう。
◎ 本当に現実的な対策 :
とか考えると今現在のように、とにかく書き込み指定件数を大きい値で設定しておいて、自分がWeb日記を書くのに飽きてしまうまで運用するか、他のツールを選択・導入してしまうほうがよほど現実的な対策かもしれない。例えば、議論になりそうな（議論になってる）記事に関しては、Wikiを導入して、そちらにログを移行して話を進めるとか。となると、hnfフォーマットが流用できるWikiとか、hnf→Wikiフォーマット(っていうの？)変換スクリプトがあるとログの移行が楽になって便利、とかいう話になっていくのだろうか。
*1: そもそも数年後、こうして自分はWeb日記を書いてるだろうか…うーん。
*2: 「ログが残らないほうが嬉しい」という利用者も居る場合は、現在の仕様がプラスに働くだろうけど。
*3: 考え過ぎかもしれないけど、こういった部分にhns開発コミュニティの選民思想(？)っぽい雰囲気を感じたりもして。更にこのへん、一部のMTコミュニティにもなんだか同種のものを感じたり。…やっぱり考え過ぎかな。ていうかUNIX系OSを触ってる人達って、Winユーザに対してデフォルトで「俺達のほうが偉いぞ」的感情を持ってるみたいだし、同様にMacユーザ、あるいはWinユーザもそういった人がたまに居たりして、取り立てて○○コミュニティが云々、って話じゃないのかも。
*2: 「ログが残らないほうが嬉しい」という利用者も居る場合は、現在の仕様がプラスに働くだろうけど。
*3: 考え過ぎかもしれないけど、こういった部分にhns開発コミュニティの選民思想(？)っぽい雰囲気を感じたりもして。更にこのへん、一部のMTコミュニティにもなんだか同種のものを感じたり。…やっぱり考え過ぎかな。ていうかUNIX系OSを触ってる人達って、Winユーザに対してデフォルトで「俺達のほうが偉いぞ」的感情を持ってるみたいだし、同様にMacユーザ、あるいはWinユーザもそういった人がたまに居たりして、取り立てて○○コミュニティが云々、って話じゃないのかも。
[ ツッコむ ]
以上、1 日分です。
有料サイトだと広告バナーを張り付けるプログラムがありますが、
そいつが拡張子判断してて .html ファイルに自動的に広告バナー表示分の
ソースを書き足してたりする場合、 zeus.cgi が何かしら .html ファイルを
読み出し＆上書きするような処理してると、その追加された
広告バナー表示分のソースが邪魔してる可能性。
該当の spaceports.com は URL を見る限り、 .html と .cgi ファイルでは
設置されてる場所が別々のようだ。
http://cgi-bin.spaceports.com/
すると相対パスで指定されてたりすると、プログラム上削除処理してても
実際に削除されるファイルは別の階層にあるので、実際には消されないとか。
うーむ、それぐらいかな。
なるほど、広告表示のプログラム動作による影響の可能性か…
たしかにそのあたり、サーバによって処理内容がマチマチだし、
中には強制的に、問答無用でガリガリと埋め込んじゃうのもあるだろうし、
無料サーバで動かす場合には、そのへんも考えておかないとアレですな…
でも今回は、それについては問題無いような気もします。
zeus.cgiが読んでるのは、ログファイル(txt)と、
自身にinclude(require?)してる、cgi 又は plファイルだけで、
幸い、htmlファイルを読んで何か処理するような仕様になってないようなので。
他に扱うファイル種類といっても、アップロードされた画像ファイルや
zip云々の、広告表示とは関係無いファイル種類しかないし。
ていうか。
今、Y氏の設置したzeus.cgiを表示してみて「あっ！」と思ったけど
そもそもあのzeus.cgiの画面、広告が一切表示されてないヨ！(爆)
すると、spaceportsって、
cgi中に自分で広告表示用の文を書き込むタイプのサーバ、ってことかな。
しかし…今の状態がもし見つかったら、速攻で削除されちゃうのでは…
有料で借りてるとかそういうオチならともかく…
もう一つの可能性…ファイルの格納場所が異なるかも、ってやつですが、
仮にそういう状態にあるとしたら、
こりゃもう私如きには対処のしようがないですわ… (;´Д｀)
今のところ、件のcgiは、cgi-binの下位に利用するディレクトリを
作っておくような仕様（ありがち）ですが…
でもなぁ…仮に、実体となるディレクトリが別の場所にあるとしても、
そこへcgiから問題無くアクセス云々って、cgi側でどうこうする問題じゃなく、
Webサーバの設定でしておくべき事項のような気もしますな…
もしも、全く別の場所に入ってるファイルに対してもアクセスできるような
処理をcgiにさせるなら、いっそのこと、そもそも別サーバに対しても
処理が出来てしまうようなスクリプトを作るほうが色々と便利でしょうね。
…あー、なんだか以前、がんした氏からそういうスクリプトを
貰ってたような記憶も…たしかftpを使ってたんじゃなかったか…
なんにせよ、後者のように、
「ファイルの置かれてる環境」が不具合の原因になってそうな気もするんで、
そのへんも意識しながらソースを眺めてみますですよ。