トップ «前の日記(2005-12-19 [J]) 最新 次の日記(2005-12-23 [J])» 編集

Eroge RSS Checker 運営記録

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

合計: 今日: 昨日:
2005年
12月
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 31

rss1.0

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

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

2005-12-22 [J]

_ [メモ] なんだかおおごと?

うっすらと予想していた気もしますが、予想外におおごとです。そこでひとつ注意書きを。当たり前ですが、リンク集も登録サイトも同列です。どちらかといえば、コンテンツを創造しているわけですから登録サイトの方が上位にあると思っています。

それと今回の例に挙げたサイトさんは、どちらもこちらが勝手に登録したサイトです。例えば、勝手に登録されて、勝手に騒がれて迷惑だと思われても全くおかしなことではありません。

_ [運営] 登録サイト削除履歴

今まで注意深く見ていた人は気づいたかもしれませんが、登録サイトを閉鎖などの理由で削除した時に、閉鎖などその旨の情報も一緒になくなってしまっていました。

今回そこいらの処理を掲示板で確認されたので、ちょっとだけ修正。履歴を残すことにしました。

_ [雑記] ErogameScapeのデータベースと同期を取る方法の改善

今のところ、全データを消して、新規に挿入するという手順を1日1回行っている。それは、どれが変更されたとも分からなければ、なくなっているかもしれないからだ。それは、まぁ仕方がないのだけれど、全データを一旦消去するというやり方は、危険な気がする(今まで一度も問題は発生していないけれど)。

そこで、状態のためのフィールドを作って、同期をとるさいに、「f」、存在した場合に「t」、変更があった場合に、「r」と書き換えれば、非存在データと更新データの判別が可能になって、何かと便利かもしれない。

_ [思案] 内容がほぼ同じゲームタイトルの取り扱い

現状、ErogameScapeでは内容がほぼ同じタイトルについては最初に発売されたもののみの情報を保存している。レビューのみを扱う性質上、当然なのだが、攻略や改造を扱う当サイトにとっては少し都合が悪い。そこで、どうにかして独自にIDを拡張するもしくは、提案できるだけの案を考えられないか思っていた。だけれどこれが結構難しい。

まず独自にIDを持つ場合、競合を起こす可能性は否定できないので、最小限のタイトルのみに限定しなければならない。そのため、既存のタイトルに大しての付属情報という形でIDを割り当てればどうだろうかと考えた。例えば「9999」というIDのゲームのDVDPG版などを、「9999a」などというIDにして、別テーブルでデータを保存するという案だ(もしくは、別途テーブルは用意するが、親IDをそのまま使い、表示も統一する)。その際の登録情報は通常のタイトルと同様のものを持たせ、任意で修正できるようにする(ブランド、発売日、紹介ページ、GetchuのIDくらいだが)。ただ、管理が面倒になる可能性もある。数が比較的少ないので、今のところはこの案が現実的かもしれない。ただ、競合を心配するあまりに、既存のタイトルと無関係のタイトルについての拡張が不可能なため将来的に困る可能性がある。そこで考えられるのが、完全独自のID付けだ。競合する場合には別途テーブルを作成して読み替えを行うことになる。情報の正確さを管理するための何らかの仕組みを作らなければ少し難しい案だ。

この完全独自のID付けという案では、命名規則が非常に重要になる。番号付けが重複を避け、管理を簡単にする最良の方法だとは思うが、独自にやるとなるとこれは難しい。JANコードを使うという手もあるが、調べることが困難な場合もあり、パッケージを変えただけで変更される場合があるなど現実的ではないかもしれない。前にも考えてみたが、ゲーデル数の自然の文を一意の数列にするという考え方が使えないかと考えている(というより、情報をごちゃまぜにするというところだけだが)。検索を行う場合、情報を複合的に使用する。タイトル、ブランド、発売日など。それらから規則的に導き出せるようにすれば良いのではないか、発売日の月日の4桁+ゲームタイトルのフリガナの最初の4文字+ブランドフリガナの最初の4文字などのようにだ。少し長くなるが、そのIDを分解して解析、該当するゲームタイトルを探し出すというようにすれば、外部からリンクを張るのも容易になりはしないだろうか。その場合はErogameScapeのIDもその検索対象の一つとなる。ただ、読み替え表の製作が面倒になってしまうだろう。それならば、無理に競合を避けずに許容可能なシステムにするのもいいのかもしれないが、それをどう実現するのかは思い浮かばない。

_ [メモ] 0:58の巡回をしてなかった

今もしていないが、0:58に巡回するように設定していなかった。良く見ると、自分でそう書いてあるのですが、なぜそうしたかなぞ。負荷が掛かるからか?

_ [メモ] 1日5回以上巡回されているかも

確率的には、1日5.16回程度のはずが、1日7回も同一サイトを巡回することがまれにある。30回中1回余計に巡回するはずなのに、5回中2回も時に巡回されるということは、作成しているランダムの種に思っているより偏りがあるのかもしれない。

_ [メモ] 管理要員の処理履歴

今まで必要な情報を処理ごとに保存していたのだけれど、もしかしたら果てしない無駄だったかもしれない。変更、削除の場合、その該当レコードの以前のデータをフィールド名とその内容をペアだと認識できる形で画一的に保存すれば、万事問題がないように思えてきた。

お名前:
E-mail:
コメント: