[PIC]
あたっくぅ
あたっくぅ
|2008,07,17, Thursday 12:37 PM | comments (0) | trackback (x) |
いくつか気になったことがあって、「Webはくしゅ」の改造作業中です。（といってもあんまし進んでないけど）
んで、１つ目の懸案は、
さすがに第１弾の公開だけあって、「Webはくしゅ」の拍手カウントの仕様は
「設置後現在に至るまでのすべての対象ページへのカウントの合計」
を記録するものであって、具体的なログというと
タイトル１、カウント数
タイトル２、カウント数
タイトル３、カウント数
タイトル４、カウント数
とう具合に、ページ名とそのページに対するカウント数のリストになっており、１回の拍手ごとにその時間とかをも含めてを記録しているわけではありません。
もちろん、たとえ合計で何万回の拍手があったとしても、ログの行数の最大はページ数どまり、となって読み込むデータも少なくて済むことから、処理も早く終わります。
当初、普通のHPの各コンテンツに対する拍手を想定していたために、それでいいと思っていたわけですが、たとえばブログの各記事に拍手ボタンを設置したときのことを考えたら、いくつか不都合が生じてきます。
１例をあげると、過去にとっても評価された記事があって、それこそ群を抜いて拍手数が多い記事があったとすると、その記事が既に過去のものとなった１年後２年後になっても相変わらずその記事へのカウントが首位に君臨し続けることになります。
それはそれで、トータル的な指標にはなるのですが、たとえば、過去１週間でのランキング、過去１か月でのランキングというふうに、ある程度期間を区切った評価もできた方がいいだろう、と思い至ったわけです。
というわけで、１拍手１行の拍手ログをあらためて残すようにし、過去１週間、１か月、１年でのカウントをそれぞれ集計して表示させることができるように、しようと思っています。
もちろん、今までのページおよびカウント数のみのログも使い、期間別用のログは、そうですね１年以上古いものは過去ログに回していく感じでログの肥大を防げばいいのかなぁ。それでも重たくなるぐらい拍手がくるサイト（ブログ）って、個人が扱う限り考えにくいですしね。
続いて、もうひとつの懸案は、
私の場合、トップページに、と位置付けたHP版とブログ版とでサーバースペース（ドメインも）は同じものの、サブドメインを使って分けています。思えば、それが失敗だったのでしょうが、今さら変えるわけにもいかないとして、
この両方のサブドメインから送られてきた拍手（およびコメント）を１か所の「Webはくしゅ」本体で受け入れさせることができないか、という、いわゆる試行錯誤です。
せっかくほとんど見分けがつかないようにスタイルを揃えたHP版とブログ版ですし、小説などのコンテンツもブログの記事も、同じ扱いでWebはくしゅに乗っけることができれば、それにこしたことはないでしょう。
そんな、またもや「できるかなぁ」という興味に従い、そこでネックになるのが二重投稿防止に使ったトークンの扱いです。同じドキュメントルートであるからこそ成立するセッションのやり取りが、サブドメインが異なる場合は使えるとは思えません。（ひょっとしたら使えるかも知れませんが、極めて特殊な環境を想定することになります）
ということで、トークンに頼らず、拍手の呼び出し方法を単純化させる方向で検討中です。
例によって、開発中のテストはサンプルページのを使ってやってますので、いつの間にかレポートページの内容とかが変わっていくかも知れません。（もちろん、エラーが出て真白になっている可能性大）
もうひとつ、Webはくしゅ本体がVerUPすれば、それをまるごと（な～んも中身を変えずに）同軸させているだけのモジュール版も自動的にVerUPする予定です。
≪ 続きを隠す
さすがに第１弾の公開だけあって、「Webはくしゅ」の拍手カウントの仕様は
「設置後現在に至るまでのすべての対象ページへのカウントの合計」
を記録するものであって、具体的なログというと
タイトル１、カウント数
タイトル２、カウント数
タイトル３、カウント数
タイトル４、カウント数
とう具合に、ページ名とそのページに対するカウント数のリストになっており、１回の拍手ごとにその時間とかをも含めてを記録しているわけではありません。
もちろん、たとえ合計で何万回の拍手があったとしても、ログの行数の最大はページ数どまり、となって読み込むデータも少なくて済むことから、処理も早く終わります。
当初、普通のHPの各コンテンツに対する拍手を想定していたために、それでいいと思っていたわけですが、たとえばブログの各記事に拍手ボタンを設置したときのことを考えたら、いくつか不都合が生じてきます。
１例をあげると、過去にとっても評価された記事があって、それこそ群を抜いて拍手数が多い記事があったとすると、その記事が既に過去のものとなった１年後２年後になっても相変わらずその記事へのカウントが首位に君臨し続けることになります。
それはそれで、トータル的な指標にはなるのですが、たとえば、過去１週間でのランキング、過去１か月でのランキングというふうに、ある程度期間を区切った評価もできた方がいいだろう、と思い至ったわけです。
というわけで、１拍手１行の拍手ログをあらためて残すようにし、過去１週間、１か月、１年でのカウントをそれぞれ集計して表示させることができるように、しようと思っています。
もちろん、今までのページおよびカウント数のみのログも使い、期間別用のログは、そうですね１年以上古いものは過去ログに回していく感じでログの肥大を防げばいいのかなぁ。それでも重たくなるぐらい拍手がくるサイト（ブログ）って、個人が扱う限り考えにくいですしね。
続いて、もうひとつの懸案は、
私の場合、トップページに、と位置付けたHP版とブログ版とでサーバースペース（ドメインも）は同じものの、サブドメインを使って分けています。思えば、それが失敗だったのでしょうが、今さら変えるわけにもいかないとして、
この両方のサブドメインから送られてきた拍手（およびコメント）を１か所の「Webはくしゅ」本体で受け入れさせることができないか、という、いわゆる試行錯誤です。
せっかくほとんど見分けがつかないようにスタイルを揃えたHP版とブログ版ですし、小説などのコンテンツもブログの記事も、同じ扱いでWebはくしゅに乗っけることができれば、それにこしたことはないでしょう。
そんな、またもや「できるかなぁ」という興味に従い、そこでネックになるのが二重投稿防止に使ったトークンの扱いです。同じドキュメントルートであるからこそ成立するセッションのやり取りが、サブドメインが異なる場合は使えるとは思えません。（ひょっとしたら使えるかも知れませんが、極めて特殊な環境を想定することになります）
ということで、トークンに頼らず、拍手の呼び出し方法を単純化させる方向で検討中です。
例によって、開発中のテストはサンプルページのを使ってやってますので、いつの間にかレポートページの内容とかが変わっていくかも知れません。（もちろん、エラーが出て真白になっている可能性大）
もうひとつ、Webはくしゅ本体がVerUPすれば、それをまるごと（な～んも中身を変えずに）同軸させているだけのモジュール版も自動的にVerUPする予定です。
≪ 続きを隠す
|2008,07,16, Wednesday 02:57 AM | comments (0) | trackback (0) |
寝る間を惜しんで「sxDictionary」をはじめ、立て続けにバージョンUPやモジュールの公開なんかをやって、ついに体力の限界を突破して倒れていた……というわけではなく、時間が空いたら読もうと買い込んでいた文庫（ライトノベル）の乱読をしていたから。
ま、他のことができなくなるほど、といえば読書だろうが開発だろうが結局は一緒だったんでしょうが。
この１週間で１６冊……
１年のうち、数回、こんな時期があります。あと先考えずに買った小説のシリーズの一気読み……。もうなんというか、まっとうな読書家に言わせればろくでもない。
それが、性質（タチ）の悪いことに、「他によさそなの無いかなぁ」などと後を引く傾向があることでしょうか。
|2008,07,15, Tuesday 07:31 AM | comments (0) | trackback (0) |
少し前にできた「Webはくしゅ」をそのままBlognPlusで使えるようにするモジュールです。
各記事ごとに「拍手」ボタンを設置します。
インストールは、モジュールのアップロードとスキンへのタグ記述のみという単純設計です。
ただし、実装にあたってはnJOYさんの「タグ拡張モジュール」がインストールされていることが必要です。
各記事ごとに「拍手」ボタンを設置します。
インストールは、モジュールのアップロードとスキンへのタグ記述のみという単純設計です。
ただし、実装にあたってはnJOYさんの「タグ拡張モジュール」がインストールされていることが必要です。
ダウンロードは以下のページからお願いいたします。
＞＞Webはくしゅ モジュール＜＜
実装にあたっての裏話（あるいは言い訳）
本当はモジュールを使わないで既存のタグ等による拍手ボタンフォームを記述して済ませようと思ってました。しかし、「Webはくしゅ」開発時に発生した二重クリックの問題の解決のためにトークン（セッション）を使っており、その整合性をはかるのは不可能と結論付けました。
そこでモジュールになったわけですが……
本当は、モジュールの実装に際して、他の方のモジュールを前提にするのは、私としても気が引けましたが、一番簡単な方法での実装が望ましいのではないか、という視点で公開に踏み切りました。
「Webはくしゅ」の性格上、記事の個別化のための「タイトル」および戻り先アドレスを特定するための「記事ID」の取得が必要となり、これは、既にその独自タグを実装されているタグ拡張モジュールがそうであるように、index.phpの一部改造を伴うモジュールの開発が必要になってきます。
記事IDだけのことなら、たとえば動作を「個別表示モード時に拍手ボタンを表示」に限定するのであれば、自作の「表示モード別分岐モジュール」との組み合わせでなんとかなりますが、Web拍手報告画面等の「タイトル」にURL（あるいはその一部）が使われるなど、非常に味気ないものになってしまわざるを得ません。
もちろん、時間をかけて、独自でモジュールをくみ上げることも考えられましたが、私自身のモジュールでもすでに２つもindex.phpの改造を伴うモジュールを出しており、これ以上あまり複雑にしたくはなかったという思いもあります。BlognPlus自体のバージョンアップのたびに、煩雑な作業を繰り返すのは、面倒ですしね。
ということで、最終的には私が楽をしたかったという理由で、非常に安直な形でモジュールを公開することになった次第です。
ちなみに、このモジュールの動作は、BlognPlusの「モジュール読み込み（このときにスキンへの操作が可能）」→「各モード別ページ作成（このときにindex.phpの改造部分が実行）」という処理の流れの隙間を突いていますので、今後BlognPlusのバージョンUPに伴って動かなくなる可能性も否定はできません。
（もっとも、その場合は、私の以外でも既存のモジュールのかなりの部分が動かなくなると思われるので、可能性は極めて低いでしょうが。というか、ありえない／爆）
最後に、タグ拡張モジュールの作者であるCJさんには、改めて感謝の意を表したいと思います。
（また使わせてもらいましたぁ／笑）
≪ 続きを隠す
＞＞Webはくしゅ モジュール＜＜
実装にあたっての裏話（あるいは言い訳）
本当はモジュールを使わないで既存のタグ等による拍手ボタンフォームを記述して済ませようと思ってました。しかし、「Webはくしゅ」開発時に発生した二重クリックの問題の解決のためにトークン（セッション）を使っており、その整合性をはかるのは不可能と結論付けました。
そこでモジュールになったわけですが……
本当は、モジュールの実装に際して、他の方のモジュールを前提にするのは、私としても気が引けましたが、一番簡単な方法での実装が望ましいのではないか、という視点で公開に踏み切りました。
「Webはくしゅ」の性格上、記事の個別化のための「タイトル」および戻り先アドレスを特定するための「記事ID」の取得が必要となり、これは、既にその独自タグを実装されているタグ拡張モジュールがそうであるように、index.phpの一部改造を伴うモジュールの開発が必要になってきます。
記事IDだけのことなら、たとえば動作を「個別表示モード時に拍手ボタンを表示」に限定するのであれば、自作の「表示モード別分岐モジュール」との組み合わせでなんとかなりますが、Web拍手報告画面等の「タイトル」にURL（あるいはその一部）が使われるなど、非常に味気ないものになってしまわざるを得ません。
もちろん、時間をかけて、独自でモジュールをくみ上げることも考えられましたが、私自身のモジュールでもすでに２つもindex.phpの改造を伴うモジュールを出しており、これ以上あまり複雑にしたくはなかったという思いもあります。BlognPlus自体のバージョンアップのたびに、煩雑な作業を繰り返すのは、面倒ですしね。
ということで、最終的には私が楽をしたかったという理由で、非常に安直な形でモジュールを公開することになった次第です。
ちなみに、このモジュールの動作は、BlognPlusの「モジュール読み込み（このときにスキンへの操作が可能）」→「各モード別ページ作成（このときにindex.phpの改造部分が実行）」という処理の流れの隙間を突いていますので、今後BlognPlusのバージョンUPに伴って動かなくなる可能性も否定はできません。
（もっとも、その場合は、私の以外でも既存のモジュールのかなりの部分が動かなくなると思われるので、可能性は極めて低いでしょうが。というか、ありえない／爆）
最後に、タグ拡張モジュールの作者であるCJさんには、改めて感謝の意を表したいと思います。
（また使わせてもらいましたぁ／笑）
≪ 続きを隠す
|2008,07,12, Saturday 10:42 PM | comments (0) | trackback (0) |
完成しました。（ぇ？）
というか、想定した機能は一通り動くようになり、今のところ不都合はない（ハズ）です。
とはいえ、何が起こるかわかりませんけどね。
というか、想定した機能は一通り動くようになり、今のところ不都合はない（ハズ）です。
とはいえ、何が起こるかわかりませんけどね。
前回、「～作ろう(3)」までで、新規入力と投稿許可／保留までできるようになってました。
そこで、次に手がけたのは「削除」、これは本当はとっても簡単で、実際にファイルからデータを消去するのではなく、「許可」「保留」と同じ場所（ログデータ中）に「del」という属性をセットして、もっかいファイルに書き戻してやるだけ。
ほとんどの動きが「許可／保留」とおんなじなので、この３つをまとめて処理できるよう１つの関数内で調整しただけです。調整というのは「許可／削除」は管理者パスワードが必要ですが、「削除」には投稿者パスワードでも実行できる、という仕様なのでそのあたりの帳尻合わせでした。（簡単かんたん）
ここで「削除」をなぜこんな手抜き仕様にしたかというと、１クリックで削除作業が済んでしまうために、「もし間違って削除」してしまった場合のリカバリーが容易に行えるように、という配慮です。
嘘です
実は個人的な好みで、掲示板などでもデータの削除を行うとナンバリングに穴が空いてしまうのが前々から気に入りませんでした。
そこで新規投稿すると、自動的にその空いているナンバーを使えるようにと、レコードは残しました。同時に、データ自体は削除しないで残しておいても一緒（どうせ一般モードだと表示されない）だし、と属性を変えるだけで済ませたというのが本音です。
次いで編集画面
実は新規投稿画面、またそこでエラーが出て投稿しなおさせる画面の設計時に、１レコードの用語データを引数に登録画面を作る関数は作ってあったので、実質的には入口となってファイルから対象データを引っ張ってくる部分と、あとでファイルを書き出す部分を加えてやることで実現してます。ほとんどが新規投稿と同じようなコードなのですが、まとめてしまうほど最適化はしてません。
そして、休日を頼みに、一気に仕上げまで走ります。
実はトップページには投稿順に用語リストが表示されます。この出力部分を１つの関数に移し換え、検索結果の表示時にも使えるように引数の調整を行いました。
そして検索語がPOST（あるいはGET）で指定されていた場合についてのみ、ファイルからデータを読み込む際に検索一致するレコードのみ表示用バッファに格納し、それを表示用の関数に渡してやるだけです。もちろん、トップページの「新規投稿順」というのは、そのフィルタを通さないだけ、という安直な仕様でした。
もともと、新規投稿や編集時の保存の際に、ファイル中ではデータは日付順に並んでますからね。つまり検索結果の方でも、一致するデータの並びは投稿順です。
本来なら５０音順にでも並びかえておいてやるのが親切なんでしょうけど、そうそうパターン一致するデータが大量になるわけでもないだろう、と手抜きしました。（笑）
（単にソートするぐらい大した手間じゃないんだけどね）
そして最後に、検索語って、見出しだけじゃなくて本文の中でもできた方がいいよね、と検索モードを追加（ワイド検索）したぐらいです。
でもでも、実際にHPのコンテンツに入れ込むための設定をしてやるととたんに真白。（Xサーバーって、エラー表示しないで問答無用に真白画面になるんだなぁ、これが）
やはり、バグ取りに一番時間がかかるものですねぇ。
前回の「Web拍手」からの引き続きで、慣れてきたのか、（仕事が……）期間がかかった割にはスムーズに開発できました。
ずっと以前、別のHPのコンテンツに用語集を入れようとフリーのPHPスクリプトを探した時には、どうも機能的に満足のいくものが見当たらず、いずれ自前で、とは思っていました。（perlのならいいのがゴロゴロしてたのに）
ひとまず、目標達成です。そしてHP版に実装したものの……
スクリプトを作るのに必死になって、用語を登録する気力が残ってない……（なんだそりゃ／爆）
＞＞HP版用語集
≪ 続きを隠す
そこで、次に手がけたのは「削除」、これは本当はとっても簡単で、実際にファイルからデータを消去するのではなく、「許可」「保留」と同じ場所（ログデータ中）に「del」という属性をセットして、もっかいファイルに書き戻してやるだけ。
ほとんどの動きが「許可／保留」とおんなじなので、この３つをまとめて処理できるよう１つの関数内で調整しただけです。調整というのは「許可／削除」は管理者パスワードが必要ですが、「削除」には投稿者パスワードでも実行できる、という仕様なのでそのあたりの帳尻合わせでした。（簡単かんたん）
ここで「削除」をなぜこんな手抜き仕様にしたかというと、１クリックで削除作業が済んでしまうために、「もし間違って削除」してしまった場合のリカバリーが容易に行えるように、という配慮です。
嘘です
実は個人的な好みで、掲示板などでもデータの削除を行うとナンバリングに穴が空いてしまうのが前々から気に入りませんでした。
そこで新規投稿すると、自動的にその空いているナンバーを使えるようにと、レコードは残しました。同時に、データ自体は削除しないで残しておいても一緒（どうせ一般モードだと表示されない）だし、と属性を変えるだけで済ませたというのが本音です。
次いで編集画面
実は新規投稿画面、またそこでエラーが出て投稿しなおさせる画面の設計時に、１レコードの用語データを引数に登録画面を作る関数は作ってあったので、実質的には入口となってファイルから対象データを引っ張ってくる部分と、あとでファイルを書き出す部分を加えてやることで実現してます。ほとんどが新規投稿と同じようなコードなのですが、まとめてしまうほど最適化はしてません。
そして、休日を頼みに、一気に仕上げまで走ります。
実はトップページには投稿順に用語リストが表示されます。この出力部分を１つの関数に移し換え、検索結果の表示時にも使えるように引数の調整を行いました。
そして検索語がPOST（あるいはGET）で指定されていた場合についてのみ、ファイルからデータを読み込む際に検索一致するレコードのみ表示用バッファに格納し、それを表示用の関数に渡してやるだけです。もちろん、トップページの「新規投稿順」というのは、そのフィルタを通さないだけ、という安直な仕様でした。
もともと、新規投稿や編集時の保存の際に、ファイル中ではデータは日付順に並んでますからね。つまり検索結果の方でも、一致するデータの並びは投稿順です。
本来なら５０音順にでも並びかえておいてやるのが親切なんでしょうけど、そうそうパターン一致するデータが大量になるわけでもないだろう、と手抜きしました。（笑）
（単にソートするぐらい大した手間じゃないんだけどね）
そして最後に、検索語って、見出しだけじゃなくて本文の中でもできた方がいいよね、と検索モードを追加（ワイド検索）したぐらいです。
でもでも、実際にHPのコンテンツに入れ込むための設定をしてやるととたんに真白。（Xサーバーって、エラー表示しないで問答無用に真白画面になるんだなぁ、これが）
やはり、バグ取りに一番時間がかかるものですねぇ。
前回の「Web拍手」からの引き続きで、慣れてきたのか、（仕事が……）期間がかかった割にはスムーズに開発できました。
ずっと以前、別のHPのコンテンツに用語集を入れようとフリーのPHPスクリプトを探した時には、どうも機能的に満足のいくものが見当たらず、いずれ自前で、とは思っていました。（perlのならいいのがゴロゴロしてたのに）
ひとまず、目標達成です。そしてHP版に実装したものの……
スクリプトを作るのに必死になって、用語を登録する気力が残ってない……（なんだそりゃ／爆）
＞＞HP版用語集
≪ 続きを隠す
|2008,07,12, Saturday 07:40 PM | comments (0) | trackback (0) |