トップ 最新 追記

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-01 [J]

_ [メモ] アクセス統計

増えたり増えなかったり。SEOを追求すれば、倍増させられるかもしれませんが、今の3倍が上限になりそうです(同系列サイトを見る限り)。

アクセス統計7


2005-12-02 [J]

_ [メモ] 巡回漏れ

指摘されて気付きましたが、長い事巡回されていないサイトがある模様、理由は調査中。

理由判明。返される最終更新日がかなり以前のものなのが原因。サーバーの設定でそうなっている模様。広告を挿入する過程に問題がありそう。ファイル作成日がLast-Modifiedに入れられている可能性大。

よく分からないので、ヘッダデータに、mod_layoutという文字列を含む場合、Last-Modifiedを無視することにした。


2005-12-03 [J]

_ [メモ] 判定ミス

「まんきつ!〜コミックカフェへようこそ!〜」が「コミックカフェ」に。人の手を介した記録はないので、スクリプトにエラーがある模様。想像だと、まず失敗に送られ、「コミックカフェ」だととりあえず判断する。そして全く同名タイトルのデータを取得して、比較対照で、先ほどの失敗に送られたデータを発見、合致、新規分を「コミックカフェ」だと判定。次の巡回時に、失敗に送られていたデータも同様に判定される。

と想定外のサーバーエラーでもない限りこれしか思いつかない。というかすぐ思い付けるのは、そういう設定にしていたかもと、気にしつつチェックしていなかったから・・・修正完了。


2005-12-04 [J]

_ [メモ] 思いつき、「押しては駄目」なボタン

「押しちゃ駄目!!」とかいうボタンを目立たない所に作って、どれくらいの人が押すか確かめてみたい衝動に駆られる(2005-12-04 17:08:50)。


2005-12-05 [J]

_ [メモ] 巡回スクリプトの修正

ヘッダの取得に失敗した場合、処理を終了するように変更。

3度連続で「Last_modified」の取得に失敗した場合、ヘッダ取得のプロセスを飛ばすように変更。

どちらも、常識的な機能です。これで負荷が多少減るかも。通常は20秒程度で終わる作業なのでそれほど負荷が高いとも言えませんが(重いときには10倍程度の時間が掛かる)。


2005-12-06 [J]

_ [メモ] リンク元としてリンクを張るのに。

リンクを張り返すのに、ブログとか特設(?)で一時的に張ってくれているように見える場合も張り返すべきか。

とどうでもいいことに悩んだりする。ある意味これは娯楽かも。

それはそれとして、相互リンクというのはアクセスアップに非常に役立ちます、リンクされることで人が来るというのは当然ですが、検索エンジンで重要度が上がるのがもっと大事(PageRankでいうと当サイトは「2」です。慶応が日本で最大だそうです、、なぜ?)。まぁ、検索エンジンというのは直リンクの常習犯なので嫌いな人もいるのかもしれませんが。


2005-12-08 [J]

_ [メモ] Getchu.comのソースが変わった

\>・(?!テレカ|イベン|<|CG|特典画像|場面写真|グッズ)[#on]

(?:<!--pc-->|<!--pg-->)・[#on]

上から下に登録記号を変えてみた。ニュースの種類によってマーキングするように変えたらしい。どれだけマーカーがあるのか良く分からないので暫定対応。

アニメ(18禁)、グッズなどの情報が欲しい人もいるのだろうか?(自分で書いた登録記号を見る限り、グッズ情報の取得は取得ミスに該当するようだけれど。)

_ [メモ] 『Yahoo!デベロッパーネットワーク

検索結果をXML形式で得られるらしい。ただ単純に検索を張るより、これを利用して情報を絞るといいかもしれない。

_ [メモ] リンクカウンターから除外されるアクセス

RSSを経由するもの、データが特定していない登録サイトへのリンク。この二つが除外されている。RSSは計っていないが、もう一方は一応計っている。8日間で最大42アクセスがある。無視していい数値か、少し微妙。

ついでに書けば、私はほとんどRSS経由(RSSリーダーではなくブラウザで)でしかアクセスしない。

_ [メモ] CSS作成は使われないようなので

さてどうしよう。とりあえず、目立たない所にリンクを表示だけさせておく。自分でなんとかしないとならないかも。まぁ、本来そうなので仕方ない。暇な時にでも、あちこちのレイアウトを真似して作ってみよう、今度は素材も使って。


2005-12-11 [J]

_ [メモ] 分類ごとの平均アクセス数

11/18日から今日までのアクセス数を元にしている。

除外データなし

データ数 / 平均アクセス数 / 分類名

5 / 44.4000 / 2次製作

22 / 26.2273 / まとめ

1 / 1.0000 / リンク集

36133 / 2.2107 / レビュー

7618 / 2.6494 / 改造

9290 / 3.0868 / 攻略

1100 / 5.4009 / 紹介

9 / 45.6667 / 解説

アクセス数0のデータを除外

5 / 44.4000 / 2次製作

13 / 44.3077 / まとめ

1 / 1.0000 / リンク集

17029 / 4.6903 / レビュー

4061 / 4.9692 / 改造

4514 / 6.3514 / 攻略

86 / 69.0814 / 紹介

9 / 45.6667 / 解説

アクセス数10以下のデータを除外

1269 / 33.7431 / レビュー

400 / 27.3725 / 改造

505 / 36.5802 / 攻略

51 / 115.3725 / 紹介

アクセス数30以下のデータを除外

288 / 96.8819 / レビュー

85 / 68.4588 / 改造

129 / 96.6589 / 攻略

45 / 128.1778 / 紹介

アクセス数100以下のデータを除外

84 / 207.6190 / レビュー

15 / 157.8000 / 改造

36 / 212.9167 / 攻略

29 / 166.6207 / 紹介

平均アクセス数を見ると、攻略>改造>レビューになってますね。

ただ、標本数が三倍以上違いますから実質的には、レビュー>攻略>改造かな。夜更けに統計学の本とか読みふけるような方は計算してみるといいかも。

使用したSQL

select count(*) as c, avg(all_count) as al, subject from counter inner join reviewpagelist on counter.id = reviewpagelist.id where error = "off" and all_count != 0 group by subject

_ [思案] 単位ごとの取得

面倒でずっと先延ばしにしていたが、なんとかしないとならないらしい。

なぜ面倒なのかといえば、marker登録との互換性の問題がある。要するに、RSSはRSS、markerはmarkerだと細かな部分で齟齬が生じる可能性があるというわけだ。一度出力フォーマットを同一にすれば、良いのだけれど頭を使うので回避していた。なぜ、単位ごとの取得は必要になるかといえば、取得要素が省略されている場合に、その要素がずれてしまい単位としてのまとまりを把握できないためだ。

では、どのような方法があるか。まず誰でも思いつき、かつ確実なのが、単位の始まりと終わりを登録してもらう方法がある。ただ、この方法には2つの問題がある。上でも書いたように、内部処理が全く別物になってしまうこと、そして新しく単位記号を登録する必要があることが問題になる。当然、単位記号を必要としない場合も考えられるので、なくとも個別で動くように作る必要もある。

この場合の実装案として、まず単位記号で、巡回対象ページの内容をくり貫き、配列に格納する。その配列データを個別に、登録記号で検索し、各要素配列に順番に格納する、単位記号がない場合はこの処理を1度だけ実行する。これで、最小限の変更で機能が実現できる。

次に、一般的な傾向を利用する方法が考えられる。普通単位というと、一箇所に固まっている(上の方法もそれを利用しているわけだが)。そこから、いくつかの要素を取り出すわけだが、その際、それ以外の情報は意味のない情報だ。しかも、要素間の順序は固定されていることが多い。そこで、何かの開始記号と何かの終了記号を組み合わせ、その記号部分も含めて単位と見ることが可能なはずだ。

この場合、それを確認するためのスクリプトを書けば、後は勝手に判断して、単位記号を決定してくれる。実装方法は上の案と同様だ。

これらを導入する場合の欠点としては、作業が少し煩雑になり、エラーの発生頻度が大きくなることだろう。RSSだけを対象にしてもタグの閉め忘れのようなミスに遭遇することがある。ましてや、手書き、ホームページ作成ツールによるサイトの場合ミスや法則から外れた書式は当たり前に存在する。

そこで、もうひとつだけ方法があるにはある。はじめに否定したRSS独自の処理の導入だ。RSSを配列に入れてくれるスクリプトは多くあり、それを導入すればなんの苦労もなく問題は解決する。ただ、齟齬が出るかもしれないことだけではなく、手直しではなく抜本的な見直しが必要になる可能性が高い。

元々、クラス化はほぼ完成しているが大きく2つのクラスから構成している。それを、ページ内容の取得保存、RSSパース、markerパース、整形・登録、の4つのクラスを作る必要が出てくるかもしれない。

バグとりから何か入れて、最低1ヶ月くらい掛かってしまうかもしれない。まずは二番目に挙げた案を頭の隅で検討してみます。

_ [メモ] RSSのみ単位取得に対応

とりあえず、簡易的にRSSの場合に別処理(といっても基本的には同じ)することにしてみた。少しずつ修正して完成したい。


2005-12-12 [J]

_ [メモ] 昨日の巡回スクリプトの変更で取得漏れ

昨日といっても数時間前ですが、取得漏れがあったので対応。


2005-12-13 [J]

_ [運営] 新規登録サイトの登録内容を暫定的に書き換え

登録用のスクリプトの不備があるのかも。書き換え途中で放置しているので、近い内に新しい方に変えたい。

では、本題。更新履歴にレビューの記述がまだない、RSSもない、レビュー済みゲームリストも50音順のみ、なので暫定的にリストから取得するように登録記号を書き換えました。どうなるか分かってから永続的に取れるように書き換えます。

_ [メモ] どこが更新されたのか分かりづらい

分かりづらいので、もう一つコーナーを作って、お知らせ、サイト別情報、新規登録分などの更新状況を見れるようにした方がいいかもしれない。とりあえず、新規登録分がある場合、目立つところで知らせるようにして見た。


2005-12-15 [J]

_ [雑記] アンケート回顧録?

今だから書くと、レイアウトを変更した時にしたアンケートで票数を意図的に操作しました。といっても、別に悪いことはしていませんが。ただ単純に、回答の順番をこちらが望む順番にしただけですが。アンケートに限らず、質問の仕方によって回答が変わるというのは一度は聞いたことがあると思います。それをやってみただけ。で、結果として、半々に持ち込みました。ということは、今のレイアウトに否定的な人の方が多分多かったんだと思います。

ついでに紹介しておくと、『人生と投資のパズル』は行動ファイナンス(行動経済学)の本ですが結構類似の例が載っていて、よく分からなくとも面白く読めるはず。ネタ元の本として、『人はなぜお金で失敗するのか(旧:『賢いはずのあなたが、なぜお金で失敗するのか』)』なんかはノーベル賞を著者が受賞していることもあり、有名ですが、、『人生と投資のパズル』の方が日本人が書いているので、例などが親しみやすく絶対面白い。もっと手っ取りばやい本としては、『投資戦略の発想法』という本もありますが、資金運用を語る部分が多すぎるのと、いろいろな本からいいとこどりしすぎているので、いまいちかも。

_ [雑記] 『RSS収集・分析サイト「BLOG360」開設、ブログで話題のキーワードを表示』という記事にちょっとびっくり

なぜこれが記事としてあちこちで流通するのか果てしなく謎です。『BLOG360』がそのサイトですが、なぜかGoogleの広告やAmazonへのID付きのリンクが張ってある。サイトデザインもあいまって、個人が儲かる聞いて即席で立ち上げたサイトに見えてきます。これが企業の運営するサイトなのかと驚くわけですが、売りは形態素分析(この場合は、フィード内で使われている単語を抽出して、それを対象に検索を行う)は当然として、「独自のアルゴリズムで重み付けが行なわれる」ところらしい。

ただ、カギ括弧などの強調表現を判別して、それで何に活用しているのかが不明。文書中の上部や強調語句を重み付けして、正確にホットキーワードを割り出そうとしているのかもしれませんが、多分その程度のことならば、いくつもある既存サイトもしているはず。宣伝して利用者を伸ばせれば市場(?)を独占することも可能と見たのかもしれませんが、ちょっと難しそう。

ただ、企業だけありこれだけあちこちで取り上げられているのに表示が非常に高速です。

_ [メモ] 情報処理

既存の手法集『サーチエンジン(特許庁)

情報処理学会

TJSAI : 人工知能学会論文誌

色々調べた限りだと、この系統の知識を得るには入門書をとにかく読んでから、学会の研究発表に行ったり、会誌、論文なんか読むしかないようです。本なんて数えるほどしか出ていませんし。でも、研究発表会とか平日にやるんですね。普通行けないと思うんですが・・・なぜ平日?まぁ、行けたとしても、論題見ても何言っているのかほとんど分からないので意味ありませんが。

_ [メモ] メールアドレスの公開を取りやめるかどうか

最後にメールが来てから半年経ちました。スパムだけは毎日くるので公開やめてアドレス変えたほうがいいかもしれませんね。もしくは、画像で公開するか。


2005-12-16 [J]

_ [メモ] 単位ごとの取得でのバグ

最初のデータで「description」が空だと配列が作られなかった。他の要素も同様。応急処置済み。


2005-12-17 [J]

_ [雑記] 『ビジュアルアーツ広告バナー』が再募集

4000円が高い安い、掲載ルールが厳しい、お誘いメールが広範に送られたらしい、宣伝効果が疑問など色々と話題になった広告バナーが再度、掲載サイトを募集しています。まぁ、今でも非常に多くのサイトが同様のバナーを掲載しているので、ここを読んでいるような人は知っているはずですが。

ある程度のアクセス数があるサイトにとって、

>掲載場所:WEBサイトメインページ上部より480ドット以内でしたら場所は自由です。

という条件はちょっと厳しい。ものにもよるけれど、他のアフェリエイトならもっと金額がいくでしょう。それでも、固定4000円というのはうちのようなサイトにとっては、サーバー代など諸々運営費として魅力的。バナーの一つくらい、しかも扱っている分野そのものの広告なので、違和感もなく、サイトを華やかにしてくれるかもしれない。Amazon広告をもう少し押し出せば、専用サーバーも夢ではない。

ただ、もう多くのサイトで掲載されていて認知度も高いと思われる。さすがに、一般的な利用者が「ああ、このバナーって月4000円もらえるんだよね。」とか知っていたら怖いが、それでもそこそこ知られている。それに、利用者にとって、多くのサイトに掲載されているので、同じバナーを何度も見せられることにもなる。個人情報も漏れるし・・・(問題は何もないはずなんですが、気分の問題)。やっぱりやめておこうか。

_ [雑記] 広告掲載報酬・固定制の利点

書く必要があるのかどうか悩むが、一応。ビジュアルアーツが報酬を固定にしたのはベストの方法だと思う。

広告では、クリック時、表示時、購入時の3通りの場合に一定の報酬を支払う方式がほとんどだ。ビジュアルアーツの広告は直接何かを売るわけではないので、購入時というものはほぼ存在しないはずだ。そうなると、クリック時、表示時に報酬を支払う方式が考えられる。ただ、これらはGoogleでも訴えられるくらいに、不当に報酬が得られやすい。それをある程度回避するためには、それらを出来るだけ回避するための仕組みと監視が必要になってくる。そして、報酬の支払いが個別に行われなくてはいけない。振り込み手数料はばかにならないので例えばAmazonなら1万円にならなければ振り込んでくれない。そういう処理も導入しないとならない。いつ振り込むのか、どのくらいクリック・表示されているのか。システムの導入費用もさることながら、もしかすると管理・運営に1人の社員を余分に雇う必要が出てくるかもしれない。少なくとも、片手間には少しあまる作業になる可能性がある。

それならば、一律固定の方が面倒がなくていいはずだ。ビジュアルアーツの社員が、休業サイトに新しいメールアドレスを知らせて欲しいと掲示板に書いていたことがあったので、それでも面倒かもしれないが。少なくとも、日常的に手間は掛からない。本当は、1000円の広告効果しかないサイトに4000円払ったとしても、10000円の広告効果があるサイトにも4000円払うだけでいい(広告効果をどう計るかは知りません)。そして、手間が減るということは給料を余分に払う必要がない(そう単純ではありませんが)、システム導入費用が安く済む(というか当然自前で十分)。トータルで考えると格安かと。

アフィリエイト・サービス・プロバイダー(というらしい)に頼んで、広告を出してもらうのもいいのかもしれないが、分野が分野だけに必ずしも適当なサイト、場合に広告が表示されるとは限らず、中間マージン含みで費用対効果は今の方式より落ちるだろう。

まぁ、そもそも広告見て買う人がどれだけいるのかが分からないので、広告を出すこと自体が有益かどうかは分かりません。


2005-12-18 [J]

_ [メモ] 関連タイトルの「その他」の使い方

「いいなり」と「い・い・な・り」を関連タイトルの「その他」と設定した人がいました。最初はどうかと思いましたが、良く考えるといいかも。間違ってどちらかにアクセスしてしまった場合に便利ですから。

それとは別に、明らかに間違ったタイトル同士が設定されたということが数回続いていました。説明書きが悪かったのか、少し様子見中。

_ [メモ] 『ErogameScapeの履歴(ERC製RSS)』のなぞ

重複を排除しているのですが、時々重複していることがあります。これは、ErogameScapeの方が早かった場合に起こります。翌日11時には消えますが、結構あったりします。


2005-12-19 [J]

_ [雑記] リンクカウンターを挟んだための弊害

アドレスがリンクカウンターのアドレス(例「http://kiisu.jpn.org/deny/rank.php?d=531994&url=http://www.getchu.com/soft.phtml?id=225445」)になってしまう場合があります。多分、解決方法はないと思いますが、ちらほらとそのアドレスをそのまま使っている例に出会います。特に問題はないのですが、外部からリンクされた場合にはカウントしないようにした方がいいかもしれません。

原因は遅延などだと思うのですが、まだよく調べていません。この問題が起こったときに、GoogleからGetchu.comにでもアクセスしてみれば分かるはず。上記のようなアドレスでページが表示されないのも同じ理由です。エラーメッセージが流れれば話はまた別ですが、エラーメッセージは抑制しているので、データベースが落ちている程度では転送先のページが表示されないということはないはず。

_ [思案] 再三、フィルターは必要か

データごと、サイトごとのフィルターをそろそろ導入してもよいくらいにはカウントデータが集まりました。ただ、本当に必要なのか眠気に襲われるまで考えてみます。

フィルターが必要になる、大前提としてデータが多すぎてどれを選んだらいいのか分からないという状況がなくてはいけません。データが20以上のゲームタイトルは618タイトルあり、30以上となると336、50以上なら134、70以上なら70、100以上なら34という具合になっています。全ゲームタイトル数が6648となっているので、50以上なら2%弱といったところです。ただ、実際に比較対照となるのは同一分類のデータなので、100以上なら21、50以上なら82タイトルとかなり減りはします。そうはいってもデータ数が多いということはそれだけ話題作であり色々な人が情報を求めているということにもなり、アクセス数という観点からは大きな割合を占めるはずです(ただ240のデータがある「Air」の1ヶ月間のアクセス数は127、最大11という少なさ)。そう考えるので、フィルターの要望があるならば、答えてみたいと思うわけです。

しかし、そうだとしてもフィルターを使う手間の方が大きいならば当然使われません。まず、検索エンジンから来た人を考えれば、当然お気に入りに入れて、フィルターの設定を保存しているということはありえません。そうなると、フィルター項目のひとつとしてメニューに表示されているだろう、ボタンを探し押して、絞り込まれた中から選ぶということになるわけですが、まずそのためにはフィルターがあることとどういう意味を持つのか知らなければなりません。そういうものがあると思わなければ、目立つ所においたとしても見つけることはできないでしょう。そうなると、フィルターはある程度の常連を対象にせざるおえません。

少し話が飛びますが、要はフィルターで絞り込んだその根拠が希薄であり、その絞り込むことによって差が拡大することに問題があるわけです。フィルターを使うというのは、極端な言い方をすれば、ランダムに絞り込むことと大差ありません。その根拠とするのは、期待もしくは目立った、なんとなくなどの希薄な理由でクリックされたその事実だけなのですから。もしこの根拠が確固たるものならば、その人気によって、表示順を変えたり、目立つように差別化をはかるのもいいでしょう。そうはいっても、数十のデータから選択するよりも多少の根拠を持ったフィルターによって絞り込んだ結果から選択した方が、希望のデータを得られる可能性が高いのもまた言うまでもないことです。とにかく、結果を原因として扱うのですから正負の循環が起こるのは絶対に避けられないので、オプションとしてしか提供できません。

ということで眠くなったので、まとめ。

フィルターを効かせる手間と、効かせないで選択する手間がどちらが少ないかどうしても微妙なところがある。そして、その絞込みにはそれほど根拠がなく、循環が起こる。

それともうひとつ、フィルターを望む場合、それは本当ならサイトに対するフィルターだというのもあるかもしれない。各データのスコアから、サイトのスコアを計算して、同様にフィルターを効かせるようにしようかとも思っているけれど、そうなると同種のフィルターが多すぎて混乱を生むかもしれない。

_ [感想] 『SEのトホホな舞台裏―システムはこうして作られる!

システムってなんだろう、どうやって作っているの、という疑問に答えてくれる本。ぱっぱと簡単に省力化が実現できそうなイメージのあるシステム(ハード+ソフト)ですが、実際そう簡単ではないという話が色々載っています。要求定義に半年掛けて、発注元からなかったことにされたり、いい加減にバージョンアップしていったら数億のシステムそのものが無駄になったり、ととことん詰めないと上手くいかないらしい。

それはそれとして、気になるのは、運営の話。バグはどうしてもとりきることは出来ないし、少しずつ育てながら運営しなければならない場合が多いという記述。やっぱりそうなのかもしれないとこの頃思います。

_ [思案] 攻略のパクリに対する対処

ついに来ました、この時が。リンク集の分際で登録を抹消するのか、黙認するのか、知らん振りをするのか。以前問題になったサイトは、誰が見ても小遣い稼ぎで、フライングで実際は攻略も何もなされていない、しかも特にそのサイトだけでされている攻略がなかったために何の抵抗もなく抹消してしまいましたが、今回はそうではなく、利用者の利便性をとるかどうするか。ということで考えてみます。

詳しくは「愚者の館」を参照してもらうとして、挙げられているサイトをここではMとSと呼びます。当サイトに登録されている分のみ調べると、Mはどこでも攻略されていないゲームを1つ攻略しています。Sは3つです(「攻略の館」調べ)。これが多いか少ないかはさておき、自力で攻略する場合もあるのは確かなようです。

対象が「To Heart2 XRATED」ということもあり、アクセスアップのためだとも考えられます。ただ、嘘記述は細かな所で、2chでも(「愚者の館」を情報源として)嘘情報が流れていたようです。そこを見て、一応成功したのでそのままコピーしたという可能性も十分考えられます。その場合、それがそれほどに悪いことになるかどうか。ただ、これを認めると「名無し」として2chに投稿しておけばパクリ放題ということになるわけですが、実質的にはその通りで難しい所です。

例えば、私も2chを見て攻略情報を修正したことがありました(当然真偽を確認してから)。その際、断り書きは書いていません。間違いなく、パクリなわけですが、他に攻略をしているサイトがあるわけでもなく、特に罪悪感もありませんでした。それが、普通にプレーしていてはなかなか見つけることが出来ないものだった場合、しかも正確な条件を確認できない場合(プログラムコードを見るなどは除外)。なおさらではないでしょうか。

要するに、攻略に煮詰まった場合、他の攻略サイトを覗かないで、全く自力で攻略すべきなのかが問題となるわけです。見てしまっては、もう答えが分かってしまうわけですから、見るか見ないかということになります。それはちょっとシビア過ぎるのではないのかと思ってしまうのですが、世間様ではどうなんでしょうか?

なんだか、擁護一辺倒になってしまったので、ちょっと攻めてみます。パクリは最悪です。実際にはプレーもせず、コピー&ペーストで自作に見せかけていたりするのならもうどうしようもありません。それが確定した場合、どう対応するべきでしょうか、登録抹消(大したダメージにもなりませんが)、その攻略だけ削除、さてどうしましょう。そもそも考え方自体がずれてはいないか。それはそれとして、登録抹消してどうなるか。そのサイトのアクセス数が若干減り、もしかしたら評判も落ちるかもしれません。ただ、もしそのサイトだけで攻略されているゲームがあったらどうしましょう。攻略を探しているのに見つからないのでは困ります。だからといって、その攻略だけ消さないでおくというのも都合が良すぎます。ここが困るところです。

悪質なら、多分困ることもなく、どこでも攻略をやっていないのは簡単過ぎるからでしょうから、登録抹消で問題ないのですが、悪質でなかったら、今回のような場合をどうすればいいのか。これはケースバイケースなのかもしれません。

ということでうやむやにして、次の問題、登録抹消を行う権利があるのかどうか。どっかのイケ面が「人に人を裁く権利なんてない」って言ってました(嘘)。それはそれとしてここで「裁く」といっても「村八分」にするという程度の意味しかありません。実際の「村八分」は火事と葬式という二分を残して関係を絶つことですが、ネットでそんなことが出来るのか。それは出来ません。そんな強固なコミュニティーを持ってはいませんし、入り口はいたるところにあります。そうなると、効果はそれほど期待できません。効果がそれほどなくともやるべきか。もう、道義的問題になってしまいます。そうなると、上にも書いたように「悪質なら登録抹消」という非常に主観的な理由を持ち出してしまいたくなります。誰のための登録抹消なのか、少なくとも私のため・・・ではないはずなんですが、さてどうなんでしょう。

なんにも、結論出ていませんが、今回は・・・どうしましょうか。

追記1:少なくとも攻略の著作権は成立するのだと思います、そうでないと攻略本を丸写しできることになりますから。となると法律的には訴えることも可能なはずです(裁判を開いてもらえるかは知りませんが)。

追記2:少し前に、「Mixi」で除名処分を受けた人がいました(『mixiの問題人物Kusakabe氏、強制退会に?』)。それについて、色々と話題になりましたが、この問題も構造上は同じなのかもしれません。

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

Before...

_ フビライ犯 [今回のことはあたかも全て自力で発見したかのように書くことが恥ずかしいのであって、論文にも参考文献と資料提供者くらい挙..]

_ ●ねこ [某Hみたいに露骨なパクリをしない限りは問題無いんじゃないかな まぁでも丸々ソースからコピペして、 多少改変してUPと..]

_ 管理人 [フビライ犯さん 確かに、情報提供元を書くのが常識的なことだろうとは思います。 ただ多くの攻略サイトの場合、情報提供を..]


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回も時に巡回されるということは、作成しているランダムの種に思っているより偏りがあるのかもしれない。

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

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


2005-12-23 [J]

_ [運営] 年末年始はまったりモード

必要最低限のことしかしない予定です。去年の年末にたてた目標の、スクリプト配布は目処さえたっていませんが、それでもまったり行く予定。

来年は、目先の問題を一つずつ解決していくか、登録サイトを無断で増やすか、とりあえずスクリプトを形にするか、検索エンジンを活用して新天地を目指すか、分類を増やして複数サイト化するか、自動化をとにかく追求するか、小難しい検索アルゴリズムを実験してみるか、レイアウト・デザインを追求するか、放置するか、SEO対策も含めてアクセス数アップを至上命題にするか、小遣い稼ぎに走ってみるか、地味にプログラミング技術の向上を目指すか、どれになろうとなるようになるでしょう。

とにかく、色々考えて、色々やって、半放置も出来るなかなか楽しいサイト運営です。

_ [メモ] 早すぎた登録削除

数日間アクセス不能だった、「國防研究會」というサイトの登録を削除しました(当然、無断登録)。何の気なしにもう一度検索してみると・・・・アクセスできました(当然、復帰済み)。原因は不明ですが、これからこういうこともあると思うので、やはり履歴を残すことは重要なようです。


2005-12-26 [J]

_ [メモ] 続・秘密のAmazon5

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

今年合計で、7671円。総売上225592円。少ないように見えて売り上げで見るとちょっと凄い。


2005-12-28 [J]

_ [雑記] RSSについて〜「title」には何を書くべきなのかなど〜

当サイトのようにゲームタイトルのみを書いて、「dc:subject」に「レビュー」などと書く方式が本当に正しいのかどうか実は謎。ブログの場合、記事にタイトルがあるのは当たり前で、それが即、RSSの「title」になるのだけれど、ホームページ(ここでは時代遅れの意)と呼ばれるようなサイト記事に必ずしもタイトルが存在しない場合が多い。その場合はタイトルではなく、コーナーの一コンテンツということになることがほとんどだろう。となると、「title」部分に何を書くべきか。一番道理に合っているのは、「○○の感想」とか「感想:○○について」といったように、当サイトでの分類と「title」を合わせたものだろう。人間が見ることを前提とするなら、「description」や「dc:subject」は任意の要素なので、重要な情報は書くべきではなく、必須要素である「title」で全てが判断できることが望ましい。ただ、RDFの理念としては、情報を分類し、各要素に分けることだろうから、当サイトのRSSのような方式もあながち間違えでもないのかもしれない(多分、間違っていると思うけれど)。念のためなぜ今の方式なのかと言えば、処理が簡単だからという以外に理由はない。

ついで書けば、RSSは直リンクを前提としているし、出来ることなら全文をRSSに格納するのが望ましい(と私は思う)。RSSはブラウジングするという、インターネット利用のマイナーチェンジ、もしくは別手段としての意味合いが強い。HTMLを対象にしてブラウザという道具でネットサーフィン(死後?)をするか、RSSを対象としてRSSリーダーでネットサーフィンするかだ。ただ、独立していたことはないし、流れとしてはそういう独立性をなくして効率的な情報収集機能の一つとなっていくようだ。