トップ 最新 追記

Eroge RSS Checker 運営記録

Categories | メモ | 運営 | 感想 | 記号変更 | 雑記 | 雑文 | 思案

合計: 今日: 昨日:
2006年
2月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28

rss1.0

ここは、「Eroge RSS Checker」に関する運営の記録を書きとめておく場所です。第三者に説明する文体で書いていますが、大半は備忘録です。

  1. スクリプトを汎用化して公開する。---最終目標
  2. CSSを論理的に使う。---努力目標
  3. デザインを改善する。---努力目標
  4. 攻略の完全・不完全を出来る限り判別する。---努力目標
  5. 管理要員用のページの充実。---努力目標
  6. JANコードの入手先を探す。---躊躇中
  7. ブランドの複数登録。---大規模改修のとき
  8. 登録を簡潔にしつつ、marker登録を半自動化する。---暇なとき

2006-02-01 [J]

_ [メモ] ブログを別に始めたので

絶賛放置中だったブログを本格的に始めてみる。プライベートな駄目駄目ぶりを遺憾なく発揮できる場が出来たので安心。

ただ、ERCをやっていることを誰にも話していない自分が、そのERC運営記録上でさえ、打ち明けられないようなサイトを2つも持っている、そんな2重秘密生活がちょっぴり愉快です。


2006-02-05 [J]

_ [メモ] フィルターについて分かっていること

前提

・最新データは、クリックされる確率が高い。

・取得時には比較的多くクリックされる。

・発売日近辺がクリック数の山になっている。

・有名サイトがクリックされる傾向が少しながら存在する。

・(クリックする人が)クリックする段階ではコンテンツ評価は不可能。

・ゴミデータを含め3ヶ月間で一度もクリックされていないデータが半数近くある(総データ数59000程度)。

・3ヶ月間での総クリック数は、45万程度である。

・3ヶ月間で100クリック強は680ほど。

・同一ゲーム、同一分類での最大数は249。

・5500タイトルでデータがあり、880タイトルほどでデータは1つしかない(総タイトル数6693)。

目的

・同一タイトル、同一分類のデータに順位を付けること。

_ [メモ] 件数フィルターの実現方法

α = (データクリック数 ÷ ゲーム当たり月クリック総数)の平均

αに補足事項:取得月クリック数の最小値を取得月から除外する(更新日0000-00-00のデータを除く)。

総クリック数10以下で最新データが最多クリックの場合、サイト別クリック数の順位を用いて順位付けする。


2006-02-07 [J]

_ [運営] 1月15日と同様、データが消えて障害発生

もう絶対に起こらないと思っていたら、起こりました。今度は、中途半端にデータが送られてきて、尻切れトンボになっていたのが原因。データの件数のチェックと、消えたデータも保存しておく仕組みにしないと駄目みたいです。

件数チェックは-1%以下の場合は、その日は同期しないようにして、データ削除は2日間連続存在しなかった場合のみに行う。というふうにすれば、たぶん大丈夫かな。


2006-02-08 [J]

_ [メモ] 件数フィルターはかなり好評

オプションは使われないからオプションなんだと何度も言ってきましたが、今回ばかりは違うようです。出来たばかりで、保存も出来ないのに既存のオプションと同様の数の利用者がいるようです。

これは、精度を高めて(クリックデータが集まらないと限界はありますが)、使い勝手を良くしないとならないようです。後、設定を保存出来るようにしておきました。

_ [メモ] 「erc_erase」を非巡回サイトでも有効に

有効にしないとなりませんね。書いてもらっていたのに、気づいたのは今日でした。巡回してないので現在は意味ないわけですが。非巡回サイトもアンテナ更新時には(数日に1回)、巡回しているので有効にしておかないと。

本日のツッコミ(全2件) [ツッコミを入れる]

_ サガ夫Z [新規実装された件数フィルターですが設定する際に1/5/10/30と楽に設定出来ますがたとえば5で設定した後に10に再..]

_ 管理人 [改善してみました。 あんまり多用されると件数フィルターの影響が大きくなり過ぎて困ると思ったので、「気分」でちょっと面..]


2006-02-09 [J]

_ [メモ] え?オリンピック?

なんだか、この頃各種スポーツ選手がテレビに出ていると思ったら・・・・・・オリンピックがあるんだそうですねぇ・・・・。知らなかった。

_ [メモ] Amazonの情報が正しく表示されていない?

一見正しくとも、ソースを見ればすごいことになっているのは前からです。XSLの使い方がいまいち分かってなかったりする。その内、CSSで装飾するか、きちんと書くかしないと。


2006-02-10 [J]

_ [メモ] 迷惑メールが1000件突破

1日たったの10件以下ですから、大したことはありません。ああ、そういえば、マトモなメールはここ1年で10件でした。

_ [運営] PHPのバージョンが15日に上がるらしい

多分なんの問題もないと思います。さて、かなり前に要望を送っておいたようにバグが改善されるのかな。CRONの空メールが毎日毎時間送られてくるので、非常に邪魔だったのだけれど・・・。


2006-02-13 [J]

_ [メモ] 一番最初が空だと処理が止まる

前も同じ問題で悩んだ気がするけれど、気にしない。

応急処置的な解決法ならあるけれど、要素単独でデータを取得するなら仕方ないのかも。単純に空なら削除するのが最適でしょうが、title以外の要素も取得している場合は、同titleに関係があるデータも削除しないとならない。ただ、それが正しく関連してない場合取得ミスが多発する。

今のところは、応急処置で放置しよう。


2006-02-15 [J]

_ [運営] 一部のタイトルデータを取得出来ていないとの報告が

問題はカンマ区切り形式で、データ本体にカンマが含まれているから。

解決法は、カンマを含むデータをダブルクォートで括るかタブ区切り形式に変更してもらうように要望を出すか、個別に対応するか。

チキンな私は個別な解決法を採ります。ただ、この前のデータ消滅も応急処置だけで放置している状況なので、余裕がない。

といっても始まらないので、なんとかしましょう。


2006-02-17 [J]

_ [メモ] タイトルデータのみデータベース同期時にデータ削除しないように変更

題名通り、難物だった二つのゲームタイトルについては手動で登録済み。変更されたもの、削除されたものについてはステータスコードを付加することで見分けられるようにしてみた。ただ、応急処置に過ぎないので、同期の取り方を考え直さないと駄目。

_ [メモ] 変更で間違えてエラー

修正漏れでした。

で、同期の際にどうやっているかと言えば、同期時にステータスコードにプラス1する。同一データが存在した場合マイナス1する。同一IDで、変更された場合プラス100する。全く新しい場合は0を指定する(見分けを付ける為に、プラス1000して、次の同期時に1を指定するという手もある)。

こうすると、変更回数と、消去されてからの日にちが分かる。単純に最終更新日を付加してもいいような気もするんですが、はてさて最適な方法は何処。


2006-02-19 [J]

_ [運営] PHPのバージョンはあがったが・・・

やはり・・というか・・・なんというか・・・・ずっと前にさくらさんに要望しておいた、文字セットの話は・・・・忘れ去られたらしい。影響が非常に少なく、PHPの再コンパイルをしないとならないらしいので、また要望出しても忘れられることは必定です。まぁ、CRONの実行時に空メールが来るだけなのでいいんですが・・・・・「To Do」リストに入っていなかったのかな・・。


2006-02-21 [J]

_ [メモ] 「DALK外伝の各種パラメータMaxデータ」がなんとかいうメッセージが

よくわかりませんが、そんなメッセージがありました。愚者の館さん他、色々な所にそんな感じの改造ツールがあります。当サイトからも行けますし、Googleで「DALK外伝 改造」と検索しても出てきます。

お知らせで返信することでもないので、多分意味ないですがここに書いておきます、一応。


2006-02-25 [J]

_ [思案] Amazonをonにすると動作が非常に重い

実は規約をきちんと読んでいないので不確かですが、接続頻度や形態に制限がある。けれど、リアルタイムでアクセスしている、利用者が限られているのでそれでも大した問題ではないんですが、やはりキャッシュした方がいいかなと。

キャッシュは、基本的に全キャッシュを定期的に生成する方法と、随時アクセス後に一定期間キャッシュを利用する方法がある。アクセスされるゲームタイトルに大きな偏りがある当サイトの場合、前の方法は無駄にコストが掛かるだけなので、後の方法を採用したい。

しかし、後の方法もそれはそれで問題がある。この機能の利用者は極端に少ない。多分、10名いるかいないかだと想像しています。となると、同じタイトルを二度踏むということが果たして起こるのか。起こらないとすると、キャッシュが有効か検査する作業と、無効キャッシュの削除、キャッシュ(画像も含む)を保存するディスク容量、諸々の分だけ無駄になってしまう。

この機能を有効にすると重いから有効にしていないという利用者が一定数以上なら、それはそれでキャッシュを作るのも悪くはないかもしれない。

そう考えて、まずはその仕組みを考えて見る。

まず、保存媒体はDBか、画像とテキストをセットで保存するか。DBというのが一般的で一番簡単なのは確かなこと。ただ、さくらさんのDBは遅い時があり、編集管理を必要としない情報については積極的に使用することを躊躇してしまう。多分、これは論理的な思考ではなく趣向なんだと思う。

ということで保存媒体はテキストファイルにする。保存する要素は決まっているので、単純なタブ区切り形式で、ファイル名にJANコードを使い保存する。その際、有効期限を要素の一つとして保存。

実際の作業としては、ファイルの有無を確認、無いならばAmazonにアクセス、あったならば、内容を配列に格納、有効期限検査、期限切れならAmazonへ、期限内なら表示(当然画像もJANコードで名前付けして保存表示)。

で、Amazonにアクセスする場合は、XML形式から必要な要素を取り出し、ファイルに保存、その後そのファイルを呼び出し表示する。同時に表示した方が当然速いと思われるので、あまりに速度に違いがあるようなら、そのように変更する。ただ、ロジックは単純な方がいいので出来ればこのまま。

もう一つ。「Cache_Lite」を使用しないのは、画像と文字要素を一括にして保存して、それを読み出すというのがなんとなく迂遠に感じるから。別個に保存するのも、それはそれで。

さて、最後に一番大きな問題。Amazonの送ってくる情報はあったりなかったり、それをどう対処するか。有効期限内で再アクセスがある場合、再度アクセスして、補完する必要がある。画像は有無が確定できないので、その対象外として、あるはずの要素のみをその対象とする。それと画像は消去しない。

とこんなところで、後はやってみて随時。

_ [メモ] 半端な対応の結果分かったこと

ErogameScapeのデータと同期をとる方法を半端に変えてみて分かったことは、結構な数のタイトルデータが変更されていること。

半月で9回変更されたデータが十数個、2回が十個程度、1回が数百個、消去されたのが十個近く。

いやでも、あまりに多いので何か間違って気もする。

_ [メモ] 続・秘密のAmazon7

クリック数1日平均20人強、先月から+757円。今月もサーバー代超え。グラッチェ。


2006-02-26 [J]

_ [メモ] Amazon情報のキャッシュの実装詳細

キャッシュは、画像がないものは1日間有効、あるものは3日間有効。重かったのは、画像が主原因だったと思われるので初回以外は問題なくなったはずです。

キャッシュ内容については、画像は永久保存、その他は要素ごとに内容があった場合を優先。したがって、中古が売り切れたりした場合、反応が遅れます。永続的に古い情報が残らないように、一定確率で古い情報を無視します。

それと画像はあらかた保存したので新規以外を踏んでも表示が遅くなることはないはず。