KANGAROO-OASIS

コメント・トラックバックサムネイル改良

HTML_FEPでの改良をwritebackプラグインにも反映しました。
これまではSimpleAPIでしたが、MozShotに変更。

まず、普通のページなら少し待てば必ず表示される様になります。

試したい方はコメント投稿ないしはトラックバック送って、当該ページをブラウザで見て下さい。表示されるまで数分待たされるかもしれません。
ブラウザのキャッシュが残っている場合も有るので、ブラウザのリロードもしてみて下さい。一度表示される様になれば、その後はずっと表示されるはずです。

サムネイルが表示されると結構気持ちいいです。

HTML_FEPのサムネイルリンク変換機能変更 - 2

Moz Shot



も使える様にしました。

時間かかっても確実に表示させるにはHeartRailsが良いのですが、Moz Shotは比較的短い時間でほぼ確実に表示させる事が出来るので、バランスとしてはこちらの方が良い様です。

用途によってはこの差がひどく問題になる場合も有る様です。

HTML_FEPでは、httpアドレスを書けば自動的にLinkに変換、@,=,_のどれかをhttpの前に書く事でSimple API,Moz Shot,HeartRailsのサムネイルに変換、!をhttpの前に書くと無変換となります。
だんだん使い方を覚えるのが難しくなって来たので、編集ページに自分だけの使い方メモを追加する事に...。
うーん、そんなの無しで使える様にしたかったんだけどなー。

HTML_FEPのサムネイルリンク変換機能変更

これまで、SimpleAPI



を主に使って来ましたが、それほど重たくないページでも、Now Printing 表示の画像が非常に多いので、HeartRails Capture



も使える様にしました。
このAPIを使うと、数分待てば必ず表示出来る様になりますので、明らかに性能が上だと思います。

例えば、



のページは非常に重いので、中々うまくサムネイル変換出来ないですが、これも表示出来る様になります。
まあ、一度サムネイル変換してしまえばきっとキャッシングしているでしょうから、紹介しても意味無いですが...。


暫く、この状態で様子を見る事にします。

Ajaxで文字コード注意！

本日ちょっとはまった内容です。

Ajaxでサーバーファイルの内容を読み出して表示する場合の話です。

サーバー側のCGIでファイルを読み込み、一旦　uri_encode　してブラウザへ非同期通信で送り返し、ブラウザ側のJavaScriptの処理で、decodeURIComponent(oj.responseText)で元に戻している場合なのですが、ファイルの文字コードをUTF-8Nにしている時は問題無かったのですが、Shift-JISのファイルを読み込むと、JavaScript側の表示が出なくなりました。

ちょっと理由は分からないのですが100%再現するので、そういう動作が正しいのでしょう。

今回、Shift-JISのファイルを使う予定が無いので、とりあえず原因究明はせずにファイルの文字コードをUTF-8Nにして使います。

推測ですが、uri_encode/decodeとShift-JISの相性が悪いのでは無いでしょうか？

原因と対応をご存知の方は、今後の参考までに教えていただけると嬉しいです。

blosxomの他用途への活用

blosxomの長所・短所については、kyoさんの所でも見ていただくとして、blogシステムをblog以外に利用しようとした場合、エントリがhtml/textファイルであるblosxomは他用途へも使い易いと思います。

blogとしてはデータベースとかを使っていないので、大きなエントリ数になった場合、アクセス速度の問題が生じる可能性はあるけど、blogを記事作成及び編集システムとし、エントリ内容をhtmlで書いておけば、他のプログラムを使ってこれらのエントリを別のhtmlファイルの一部にそのまま組み込めます。

これは、プログラミングレベルがあまり高く無いアマチュアプログラマーでも、ちょっと頑張ればblog以外の用途にもblosxomを活用出来る事を意味しています。

blosxomをblogとして使う方が今後増えてゆくとは思いにくいですが、blosxomを別の用途にもっと活用出来るといいなと思います。

でも、もし、そういう用途を考えてみたいなら、やはりblogもblosxom使いませんか？

とか、言ってみる。

いや、blosxom仲間が増えてほしいだけのエントリです。

ここのサーバーの使用容量

解決した所で、そもそもの目的のここのサーバーの使用容量をFTPソフトで調べてみました。

　48.62MB

でしたので、こちらは丁度半分位ですね。

まだ暫くは大丈夫っすね。

とんでもないトラブル（解決編）

もうひとつの解決策ですが、それは自作のCGIでtmp内のファイルを消す事です。

昔、拡張子毎にファイルの一括削除をする file_del というCGIを作った事が有ります。

これは、まず、削除対象ファイルを表示し、その後、そのファイルを一括削除するという物です。

これを使えばどうなるでしょうか？

おそらく、ＦＴＰと同じ様にハングアップするか、サーバー側のタイムアウトで処理が途中でエラーするのではないでしょうか？

まあ、考えているより、やってみるのが早い。


結果、延々と削除対象ファイルが表示されます。


おい、おい、一体どこまで表示するんだ？

おや、ブラウザーの動きが固まって来た。

や、やばいぞ、これはハングしそう。

ブラウザの中止ボタンを押し、途中で表示を止めます。


じゃー、表示部分の処理をコメントアウトして、一斉に削除しちゃいましょう。

処理を実行すると、かなり時間経ってから５００サーバーエラーが出ます。

あー、これはタイムアウトかな？


今度は、表示部分を復活させ、再度実行してみます。

お、削除対象ファイルが減っています。

...。


これで解決の道筋が見えました。

上記作業をしつこく繰り返せば、きっと消せるはず。

で、結局、１００回程繰り返して何とかＦＴＰで表示出来る様になり、最後はＦＴＰソフトに任せてしまいましたが、やっと解決した次第。

ちなみに、tmpディレクトリに有ったファイルの数は、

　３４２８１８ヶ

でした。

何ですか、このとんでも無い数は...。

ＦＴＰが動く様になった時に残っていたログを見ると、特定の日に集中しています。

夏休み時期とか...。

...。

これ、いろいろブログのプラグインを直したりして、blosxomにエラーを出させた数だけファイルが出来ていたって事？

seeerrorプラグインは外す事にしました。

古いログを自動的に削除するような仕組みを入れないと、このプラグインは危険っす。

皆さん、ログを残すプラグインには注意しましょう。

ちなみに、spam_blockerは、ログファイル数は増えませんが、ログファイルサイズがとてつもなく大きくなるのを防ぐ為、途中のバージョンからはデフォルトで記録ログの制限をつけていますので、大丈夫です。

とんでもないトラブル（苦悩編）

前のエントリの続きです。

さて、これどう解決したら良いのでしょうか？
ＦＴＰソフトがハングアップしちゃうなんて…。

考えている内、思い出した事が有ります。

それは、blosxom starter kit の最初の頃、誰かがつけた文字化けコメントかトラックバックが消せないという事で、kyoさんにお助けをお願いした時に紹介していただいたCGIです。

GMW-managerというcgiですが、これ、なかなか優れもの。

そう、これがあるから何とかなるでしょ...。


あれ、駄目っす。ＦＴＰに同じ。


うーん、では、land.toが用意しているＦＴＰページを使ってみる。

そう、これも同じく、駄目。


おい、手が無いの？？？


仕方ない、land.toの管理人さん、何とかなりませんか？

⇒　返事なし


おーい。


本当に困りました。


しかし、「自分で作ったディレクトリなので、自分で消せないはずはない。」という所だけが気持ちのよりどころです。


で、どうしようか？


そういえば、もう一つ方法が有る。


⇒　解決編に続く

とんでもないトラブル（問題編）

非常に困ったトラブルが起きていました。

話せば長くなるので、連載エントリとしたいと思います。

事の始めは、KANGAROO-OASIS :: サーバー容量オーバーしてた
で、別サーバーで容量オーバーが起きていた事も有り、このブログの有るサーバーの容量も調べようとしたのですが…。

...。

調べられない！！！

えっ？

調べようとすると、ＦＴＰソフトがハングアップしてしまうんです。




これには困りましたが、こういう時はどこで問題が起きているかをまず突き止める必要が有ります。


ディレクトリ毎に容量を調査すると、このブログのディレクトリだけが問題で有る事が判明。

おーい、どうしたんだー。

これは非常にやばいぞー、と、徹底調査。更にサブディレクトリ毎に調査。

結果的に、tmpディレクトリが原因と判明。

tmpディレクトリの中を覗こうとしたとたん、ハングアップします。


これは一体どうした事か？


そもそも、このtmpディレクトリって何だったけ？


これは、実は　seeerror　という、blosxomのプラグインが使っているディレクトリで、blosxomでエラーが発生した場合に、エラーログをこのディレクトリに残しています。


tmpディレクトリの中を覗けないので、この時点では推測でしかないですが、

・エラーログファイル数が多すぎる
・エラーログファイルの容量が大きすぎる

のどちらかが原因で、ＦＴＰでこのディレクトリを開けないと思われます。

ただ、このエラーログは非常に簡単なログなので、容量ではなくファイル数ではないかと思われます。

で、どうしましょ？

エントリも長くなって来たので、続きは次のエントリで…。

カンガルーワールド２０検索 powered by Yahoo! JAPAN

color99管理 isweb/xrea/land.to サーバーより２０アイテム検索