トップ 最新 追記

Eroge RSS Checker 運営記録

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

合計: 今日: 昨日:
2004年
11月
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 29 30

rss1.0

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

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

2004-11-07 [J] 単位ごとの取得

_ [運営]単位ごとか個別か

同一フォーマットが連続して現れる場合、「日付:タイトル 分類」のようになっているのが普通、例えば、RSSの場合。単位は「item」ということになる。

だが、現在このまとまりを識別できていないのが大きな問題のひとつ。解決法はというと、抜本的にこの単位ごとに取得するように変更する必要がある。

しかも、この単位の始まりと終わりを認識できなくてはならない。RSSの場合は決まっているので、問題はないが、Marker登録の場合もう1つ登録項目を設けなければならない。大抵既に登録されているものの開始記号と別の終了記号を組み合わせる事で可能だろうが・・・・・。作業が結構大変で、最初は不具合が多く出てくるだろうと予測されるので、保留中。


2004-11-11 [J] 登録以前のデータ登録

_ [運営]一括登録方法としてCSVを

今の所、登録以前のデータをユーザーサイドで登録する方法は非常に限られている。そこで1つ手段を講じようと思う。CSVデータでの一括登録を考えている。他にも、サイト上のほかのページを一時的に使用する方法もあるが、

ちょっと面倒なのでまずは、CSV。誰でも簡単に登録出来るようにしておけば便利だろう。ただ、当然CSV形式のファイルは、登録アドレス下にアップロードしてもらわないといけない。

用意するのが面倒かもしれないとも思うが、サイト運営する上で出来上がったCSVが役に立つときが来ると思うので、これでいいかも。

>12日

CSV形式を見分ける方法を考えて見た。ない。絶対ない。ということで、必須要素がない場合にCSV形式ではないと判断することにした。それも完全とは言えず、少し難解。まぁ使われる事が

あるかどうか分からないものなので、いい加減でいいのかも。


2004-11-24 [J] テーブル構成

_ [運営]テーブル構成について

「rss_content」「rss_list」テーブルを「reviewpagelist」「homepagelist」に統合する。これが必須だと思っていたが、情報が違うのだから分けて当然かもしれない。まずは「rss_list」「homepagelist」について書いてみる。同種のテーブルを継ぎ足してくれるUNION構文が使える事が分かったので、統合の必要性はかなり薄れた。本当はサブクエリを使って継ぎ足したテーブルのデータを抽出出来たらよいのだけれど、MySQLのバージョンが少し足りない。

問題は、継ぎ足す際のフィールドを増やすとレコードの重複が避けられない点だ。例えば、ErogameScape上の登録日とこちらの登録日が異なる場合、重複を判断する方法が無い。テンポラリーテーブルを使えば可能だろうが、実用さからどんどん離れてしまうような気がするので気が進まない。PHPサイドでの処理として、サイトごとに並べて2度目から無視するか、サイト名(ID)を配列にに格納して

重複をチェックするか、この方法だと並び順は自由に出来るが、今度はどちらを重複として消去すべきか判断できなくなる(前の方法の場合は多重ソートを使い判断可能)。まず、重複するものを選び出し、そこから消去するものを判断しなければならないので、MySQLサイドでないと結構大変な問題だったりする。それでも、各種情報を全ページで活用できるようになったのは、かなり有益だろう。書き換えに時間をとられたが、少しずつ使いやすくしていこう。

で、もう、「rss_content」「reviewpagelist」の統合だが、これはより必要ないかもしれない。「reviewpagelist」はあくまで対応表で、ここに該当する情報だけ書き写しても悪くは無いが、同じ情報が二箇所に分かれるのも面倒。「reviewpagelist」に書き写すにしても速報性を考えるとgame_idが確定する前にも情報を表示する必要がある。しかも出来るだけ。そうなると、書き写したとしてもそれが反映されるのは、現在は2箇所のみ。書き写して扱いやすくするか、

書き写さないで、情報量を求めるか、それとも完全に統合するか。今の所はこのままが一番のような気がする。(と思いながら「reviewpagelist」の重複チェックをしてみたら、最大で9個も重複していた。重複個数は全てで500個(?)ほどだろうか、結構多い。)