トップ 最新 追記

Eroge RSS Checker 運営記録

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

合計: 今日: 昨日:
2005年
10月
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-10-01 [J]

_ [雑記] 昨日の気になることを2つ対処

「LUKCY SEVENTH」に攻略の更新履歴がのったので、四苦八苦してなんとか正規表現で取る(漏れ、余分が出るかも)。かなり、法則性のない表記なので、致し方ない。レビューも』の後にあったらかなり楽なんですが・・。

レビュー・攻略・紹介の3本立ては不可にしました。紹介に値するコンテンツがあるサイトのみ自己申告+審査で対応したい。

後の問題は先送り。


2005-10-02 [J]

_ [メモ] 『レイアウトのデザインを読む。―情報デザインのロジックを学ぶ デザインを発見する本!

良さそうなので、買ってみました。

レイアウト・デザインは難しくて手に余ります。どこかに、見本になるようなサイトは無いものでしょうか?大量の更新情報を見やすく配列しているサイトは。


2005-10-04 [J]

_ [メモ] 先月の転送量は27GB

伸びたとしても今の3倍がやっとだと思っていますが、そうすると月100GB。さくらインターネットのスタンダードに言われている通り日10GBの上限があるとすると、月300GBが上限。ただ、日によりかなり変動があるので、今の3倍でも503エラーを出す可能性が高い。

_ [メモ] 『OpenOffice.org』は結構面白いかも?

最近では当たり前過ぎて話題にも上らないような気もしますが、面白いですね。データベース機能も付いていますし。Draw(図形描写)を使って説明図でも描いたら、分かりやすいかも?


2005-10-05 [J]

_ [感想] 『レイアウトのデザインを読む。―情報デザインのロジックを学ぶ デザインを発見する本!』を読んで

ノンデザイナーズ・デザインブック Second Edition』は役に立ったと思いますが、これは微妙。第一サイトについては、適応できないことが多すぎる。これ系の本として、普通のことですがサンプルも微妙。基礎知識はきちんと書かれていますが、目次を読んで最終章を読めば事が足りているように思う。感覚的なことで、具体的に書くのは難しいのは当然ですがサンプルと内容を見比べると飛んでいるのではないかと思う。実際に自分で作りながら確かめないと、いまいち実感できない。入門書、参考書としては、悪くはないと思うが、特出した何かが書かれているとは思わない。

_ [雑記] 文字コードの判別法

今日の今日まで、一番重要な点を失念しておりました。自分のことながら・・・・・。

ということで、今日から、head部分などに書かれる文字コード情報を活用することにしました。jcodeの自動認識、mb_detect_encoding、そして今回の申告された文字コード。この3つを使用することにしました。優先順位は何となくで、jcode、申告された文字コード、mb_detect_encodingにすることにしました。これで、多分全登録サイトのアンテナでも文字化けがなくなると思います。

ついでで、わざわざjcodeを使うのは、mb_convert_encodingに不具合があるためです。「〜」が太めの別文字になったり少し変化してしまいます。


2005-10-06 [J]

_ [メモ] 「見出し無断使用、ネット会社に賠償命令…読売逆転勝訴」

ということで、見出しを読売から無断使用してみました。営利目的でやっていたからなのかもしれませんが、非常に重大な判決だと思います。裁判の判決理由などはまだ分からないので、判断が付きませんが、ニュースサイトは当然として当サイトにとっても問題あり?


2005-10-08 [J]

_ [雑記] 見出し問題は大した事ないようで

見出し問題では、不当に利益を挙げているという所が問題視されただけのようで一安心ですが、営利目的というのはどうやって線引きするのでしょうか。

トップページのデザイン変更などやらないとならないことが多くありますが、何かと忙しい今日この頃です。休日中に、巡回スクリプトのクラス化(ほぼ終わっている)とその適応、自動すり合わせ部分の見直しを最低限やりたい。

できれば、表示部分の統一、そのためのデータ形式の統一と関数化をしたい。ただ、まだまだここは詰める必要がありそうだ。

_ [雑記] (巡回)難易度の高いサイト

記号に挟まれた文字データを取得するのが当サイトです。正規表現が基本戦力です。その他様々な手段で取得できるように努めています。

ただ、それでも難しいサイトというのはあるものです。特に天敵なのは、ホームページ製作ソフトで作られたサイトです。タグに一貫性がない事が多く、無駄にフォントタグなどが挟まれます。攻略法はないものかと考えてみても、タグを完全に無視して見た目から取る、などのオプションを用意するといった、システム改造をする方法しか思いつきません。もう少し柔軟性のあるシステムにしないとならないのかも。

_ [運営] 今日の変更の理由

レビュー取得をやめさせてもらいました。初めてのことで、しかも理由をきちんと説明するのは無理です。強いて言えば、耐えられなかったから。

例えば、「Gift」や「はじめてのおいしゃさん」についての感想は許容範囲内なのですが、「ToHeart2」についてはちょっと・・・・。一口感想でも一覧性が確保されていれば、有用だとは思うのですが、各ページの最下部に表示されているので、他のゲームについての評価との比較もままなりません。感想の中身については、言及を避けさせてもらいます。

本当は、こういう区別・差別はいけないというのは分かっているのですが、突発的な発作のようなものなので許してもらえると幸いです。発作がまた起こるようなら、レビュー・攻略・改造・紹介のコンテンツ制限について、文書化しないと駄目かもしれません。基本的には、50人中1人くらい(該当サイト関係者除く)が有益だと思えればそれでいいと思っています。紹介は別(感想引く主観足す情報)。

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

_ 3-910 [>感想の中身については、言及を避けさせてもらいます。 巡回サイトの場合、中身をわざわざチェックしてられないので、それ..]

_ 管理人 [1つ1つチェックするのは確かに無理です。ただ、サイトをチェックするのは、必須です。 利用者の方々にこのチェック作業を..]


2005-10-10 [J]

_ [メモ] 自動すり合わせ部分の見直し終了

間違いを1つ見つけました。この修正で、人の手を煩わせずに決定する率が増えるはず。

_ [メモ] 巡回スクリプトのクラス化終了

現在試用中。テストでは問題なく動作しているので大丈夫かと。処女作(?)なので、色々と不備がありそうですがエラーがなければその他の該当箇所で使用し、スクリプトを公開します。


2005-10-11 [J]

_ [運営] 巡回スクリプトのバグ

バグありすぎです。順次修正・・・。

問題が発生したものについては、修正しました。;潜在的バグはまだあるかも?


2005-10-12 [J]

_ [雑記] 攻略の無断転載について

今回は登録を削除しました。ただ、もし大型サイトや自分の気に入っているサイトでこのようなことがあると悩む所です。そういうサイトがそういうことをするとは思いませんが万が一の話として。でも、無断転載してもいいことは何もないと思うのですが・・?ある程度のアクセス数のアップが見込めますし、コンテンツのない初期にそういう誘惑に駆られることもあるのかもしれませんが、今回の例のようにいくつかの無断転載で色々とした苦労・努力が水泡に喫してしまうわけで。無断転載をするようなサイト、最近明らかになった3サイトを見ると、拙いまたは不自然な印象を受けます。広告が不自然な位置にしかも大量にあったり、サイトデザインが数年前の水準だったり。ですから、そういうサイトがあると疑ってしまう今日この頃です。

後、当事者が見ているかもしれませんので一言。以前2回のWeb拍手送らせてもらいました。登録に関することと、HTMLのソースに関するあの重大なミスについてです。このままサイトを続けるのかもしれませんが、出来れば一度閉めて心機一転してまたレビューサイトとして頑張ってください。当然無断転載なしで、文章の中央揃えも出来ればなしで。

では、最後に。実は当サイトもErogameScapeのデータを大量に長期間無断転載中です(404などで使用を推奨されていたのでそうしているのですが、まぁ断りくらいはいれるでしょう、普通)。


2005-10-13 [J]

_ [雑記] 移り気

いやぁ、ヨーロッパでのことですが、宿木が、裸の木に結構あって不思議感が漂ってました。

ということで、移り気な今日この頃です。あれもしたいしこれもしたい。あれも知りたいしこれも知りたい。あれも読みたいしこれも読みたい。義務的なものもちらほら。アニメの新番組に面白そうなのが少ないのがせめてもの救いです。

なんでこんなことを書くのかというと当然、サイトの改善をサボりがちになっているからです。これからも今のようなゆっくりペースになってしまうかもしれません。デザインの改良、ページングの導入などをしないとならないのですが、裏方の整理を必要とします。この手の作業はやっていて面白くないのでやる気が起きず、別のことに興味が行く、という構図もちらほら。とにかく、以前の約束(?)は全て反故にして、(何度目かの)ちまちまやります宣言です。

_ [メモ] 巡回スクリプトのバグ2

実行時間が30秒を越えてエラーが出ることもしばしば。なんだか良く分からないエラーも発生。まずは無駄を減らす事から初めてみます。原因はなんなんでしょうか??


2005-10-14 [J]

_ [運営] バグを特定

巡回スクリプトでエラーが発生していた件について。

初歩的なミスでした。繰り返しの条件を変動可能にしていたために無限ループになってました。一定条件が揃わないと発生しないエラーだったためもあり見つけるのに手間取りました。メモリー不足と出るのもこの部分のせいだろうと思います。配列の要素を永遠と付け足していくので、30秒以内に溢れてしまった場合メモリ不足のエラー、そうでない場合30秒超過のエラーがでていたようです。


2005-10-15 [J]

_ [雑記] 今日の誤取得の原因

まずは、単位ごとの取得に対応していないため。要するに、あったりなかったりすると、なかった所に次の要素が適応される。ズレるわけ。RSSだけでも対応した方がいいかも。

後は、昨日のバグ取りで生まれた初歩的なバグのため。

RSSを2個用意してもらっているサイトについて、反応しておきます。2個用意してもらえるのはありがたいですが、日付から始まるデータにも「dc:subject」を「その他」なり「人気投票」「商品リンク」なりと適当に付けてもらえれば、全く問題ありません。

(お知らせに書いている、取得エラーというのはこの件とは無関係。あれはある意味通常のエラーです。)


2005-10-17 [J]

_ [運営] 「失敗」でのエラーについて

原因は不明ですが、取得ミスデータに対してなんらかの条件で処理が為されたようです。そのため、他サイトのデータとして該当不能に割り振られていました。サイトIDをErogameScapeと合わせる場合、取得ミスに振り分ける場合以外いじらないデータなのですが・・・・。過負荷でのエラーの可能性が高いですが、あまり使わない機能にバグがある可能性もあります。原因を調べようにもいつ、なぜ起きたのか特定できないのでどうしようもありません。

_ [雑記] 初級シスアド受けてみた

サイト運営とは直接関係ない話です、念のため。

今日というか昨日は初級シスアドを腕試しがてらに受験して来ました。前日に単語集を眺めて、(雑誌「合格情報処理」の)予想問題集を解いたので準備は万端(?)。テストを受けてみると、予想問題集(過去問の寄せ集め)と同じ問題が数問出てました。というか、問題の3割(?)くらいは国語や論理的思考の問題で、コンピューターとは全く関係ありません。内容的にも日本語なのに、下手をすると英語のTOEICより簡単な問題もちらほら。それに英語力があれば、コンプライアンスプログラム(個人情報保護のためのマネジメントシステム)とは?など知識なしでも解けそうな問題が多かった(英語力・皆無)。とはいえ、知らない単語が盛りだくさん。決定木の仕組みもテスト中は分かって無かったですし、ホットサイト?リポジトリ?CORBA?などなど。決定表に至ってはついさっきまで理解していませんでした。

資格の大原』で解答速報やってました。そこで、採点してみたら、午前は問7・13・14・15・19・20・21・29・31・33・36・37・44・46・50・58・62・63・64・67・71・74・76・79の80問中24問不正解正答率70%、午後は問4e、問5h・m?、問6n・o、問7k・mの72問中7問不正解で正答率90%(『資格の学校TAC』によると86.5点)。午前の70%というのは下限ぎりぎりか割っているかも・・・・割っていたら不合格です。今回は簡単だったらしいので危ないかも。(後日『IT資格情報提供の部屋』で合格ラインの算出が行われるようなので、思い出した頃にでも見るとします。『情報処理推進機構』も念のため。)

と思って、不安になって『資格の学校TAC』でも採点してみました。午後の問3e・fが『資格の大原』と逆だった。で、考えたら『資格の大原』が間違っている可能性大(記述内容が元々不明瞭だけれど、『資格の大原』は明らかにユニークでないから)。となると午後2問追加で間違えたかも。まぁ午後の点数は問題ないのですが、問題は午前の問14合ってるかもしれないこと。ネットで調べても『ホットサイト』は「待機系サイトとして稼動させておき、ネットワークを介して常時データやプログラムの更新を行い、障害時に速やかに業務を再開する。」で良さそうなので『資格の学校TAC』を信頼しておきます。そうなると、71.2%の正答率になるけれど・・・微妙。

_ [メモ] 『IT資格情報提供の部屋』の配点、合格ライン予想での結果

午前70点(合格ライン66点、安全ライン71点)、午後82点(合格ライン65点、安全ライン70点)。一応安心しておくことにする。(と思ったら問79合ってた。で+1.25だけど、問1間違ってたかもで-1.75とすると69.5点。)


2005-10-18 [J]

_ [雑記] さくらちゃんたら上場したからって・・・・

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=

[メンテナンス]

作業日程 : 2005年10月25日(火) 11時00分 〜 12時00分

影響範囲 : データベースサーバ mysql2.db.sakura.ne.jp

mysql5.db.sakura.ne.jp

作業内容 : ソフトウェアのマイナーバージョンアップ及び設定変更のため

作業時間帯にデータベースサーバへの接続ができません。

今回の変更により使用できる文字コードが増加します。

デフォルト文字コードをlatin1からujis(EUC-JP)に変更致します。

---------------------------------------------------------------------

とのことです。ということは・・・・・・どうなるんでしょうか?もしかすると、当日文字化けするかもしれないので、確認作業しないとなりません。ここ「さくらインターネット」を借りた当初、この文字コードの問題でかなり四苦八苦しました。日本語のサイトしかないのだからと、今回の変更をしてくれるようにメールも出しましたし、他の人もこの要望を出していたはずです。それでも、

「データベースや、管理ツールのご利用については、サポート外とさせて頂いております。」

とのことですから返事もくれませんでした。

今現在「mysql9.db.sakura.ne.jp」まで存在します。新規の場合は最新番号のサーバーしか使用できないようになっているそうです。要するに、上記の変更予定サーバーは既存の人々用なわけです。なのに、変更するというのは・・・。多分、何事もないと思います。実際さくらに移転してくる前は、EUC-JPでサイトを作っていましたし、EUC-JP環境でUTF-8を使っていた記憶があります。だから大丈夫でしょうし、喜んでいる人もいるかもしれません。

ただ以前、要望出した時には返事もくれなかったはずなのに、今頃というのが気になります。格安で快適なサービスを受けている身としては、文句を言う口もないはずなんですがね。

後、マイナーバージョンアップでMySQLのバージョンもアップするなら影響が他の部分に出てくるかもしれません。

とにかく要チェック。

_ [雑記] 日付情報の取得部分にエラーがあった

日付が上手く取れていないことは数日前に判明していて、直したと思っていたのですが、直ってませんでした。どうも、かなり前に行った、2日以上未来の日付を無効にするという設定が原因らしい。ということは、かなり前から同じ症状が出ていたはずなのですが、起こる条件が限られているので気付きませんでした。

この制限を取り払うことで一時的な対策としますが、やはりきちんとなんとかしないとならないかも。

後は参考までに。MySQLのdate型やstrtotime関数を利用するとかなり表記のブレを吸収してくれます。それと参考サイト。

日付の表記に関するノート(The Web KANZAKI)』

phpとPostgreSQL ライブラリ / 日付関連文字列変換(Soft-inn)』


2005-10-23 [J]

_ [メモ] そろそろ巡回部分のクラスを公表できるかも

かも。バグも粗方抜けましたし、簡易的ながらエラー内容も返します。使っていない変数を宣言していたりしますが、前より使いやすいかも。

_ [メモ] AmazonがJANコードを返さなくなったかも

かも。一部でのことですが。

データベースとして使うなということなのか、ASINの業界(?)標準を確固たるものにするためか。とにかく、重要な情報が減ってしまいました。

_ [思案] コメントタグの活用、独自フォーマット

RSSにしろなんにしろ、既製品というものはいつも物足りないものだ。それが、自作ではないためか、それとも目的とのズレのためかは知らないが。

さて、ということで目的に完全に合致する既存フォーマットというのはない。ないなら作るしかない。あまり知られていないことだが、巡回対象のページに「erc_erase」と記述されていると登録を削除するようになっている(「erc_erase:url」でサイトアドレス変更)。それを拡張して登録データの編集を行えるようにすると便利なのかもしれない。

「<!--erc_up if(title:はぴねす;subject:レビュー;){subject:攻略;tourokubi:2005-10-23;}-->」(条件に一致したデータについて、指定の書き換えを行う)

「<!--erc_url http://.....-->」(アドレス変更)

「<!--erc_del if(title:はぴねす;game:4594;)-->」(条件に一致したデータを削除)

「<!--erc_erase -->」(登録削除)

やるとしたらこうだろうか。if構文の解釈が面倒なのでもう少し詰めなければならないが、サイト上に決まった記述をするだけで、変更・削除が簡単に出来るようになる。ただ、これでも難解かもしれないし、使われそうもないかも。


2005-10-24 [J]

_ [雑記] 『Eroge RSS Checker』と同系列の検索サイト

サイト名 Eroge RSS Checker ErogameScape ゲーム攻略への道 X-Navigator Game Leader
レビュー ×
↑データ数 最多
攻略 ×
↑データ数 最多
改造 × ×
↑データ数
アクセス数 最多
更新頻度 随時
最新タイトル情報 最多
古いタイトル情報
機能 最多
簡易性

以下は使ったことがないので除外

MagicalGirl

Gamers Relaxation Site

ぷりちーがーる

GC ゲーム派ドットコム

CG-Pocket

ゲーム駅

Gamers Forum

ゲーマーズターミナルプラス

CODE NAVI

以下は比較対照外

エロゲーレビューサーチ(独自コンセプトのため)』

erogmap(更新チェックには使えない、リニューアルの結果次第)』

以下は閉鎖

『ゲーム攻略リンク』

『アダルトゲーム レビュー・攻略 リンク集』


客観的なデータのみ表にしてみた。(自分のサイトは当然として)個人的には表にしたサイトはどれも良く見る。使い方としては、 レビューなら『ErogameScape』、攻略なら『ゲーム攻略への道』、更新頻度なら『Game Leader』、データの質(?)なら『X-Navigator』ということになるのだろうか。『X-Navigator』の更新の低下から多少勢力図に変化があった時期もあったと思うが、現在は更新頻度が回復し、システム改造を画策中の模様なのでまた独走することになるだろう。ただ、更新頻度でいったならば『Game Leader』に勝る所はない。管理人の人柄、仕事の具合など窺い知る事ができないためなんとも言えないが、独自に更新チェックしていることは間違いない、少なくとも『Eroge RSS Checker』より早いことが多い。しかも、最新のタイトルについての情報量は随一。上記2サイトが最新作の更新チェックとして最適。タイトルについての情報を知りたいなら、『ErogameScape』。となると『Eroge RSS Checker』の意義が薄いような・・・?

どれをとってもナンバー1でないのが痛い。労力が少ないというだけでは使えないかもしれない、リンク集として特化してみるといいのかな。はてなとか2ch過去ログにリンクして。「GATE DIVE」タイプの精力的な運営は無理だから。

_ [メモ] 完全網羅型リンク集の実現案

一つだけ思いついた。アンテナから誰でも自由に手動で登録出来るようにすればいいのかもしれない。予備登録的な意味合いでアンテナにサイトを登録すれば、少し面倒だが分担すればそれほど大変でもない。色々問題があるので実現しないとは思うけれど。

_ [メモ] 良質サイトの判別フィルター

どれが良質かは一人一人違うので自動でやるのは難しいが、案としては2つ。

ErogameScapeのみに登録されているサイトを非表示にする。

アクセスカウンターで上位○○だけ表示する。

_ [メモ] 続・秘密のAmazon3

クリック数1日平均20人前後、先月から+312円。先月今月とサーバー代に満たなかった。ただ、わざわざ、経由して買ってもらっているという、愛(!?)を感じるので気にしないでおく(予約分合わせると多分500円行くし)。それにしても、商品内訳でゲーム1本もないというのは、なんかすごい。


2005-10-25 [J]

_ [運営] さくらインターネットのメンテナンスでバグ

一部でエラーは表示されるが、特に問題はないらしい。こちらで何とか出来る問題でもないので、明日までは管理者が気付くまで静観することにします。

(PS 26日にメールで問い合わせてみました。)


2005-10-26 [J]

_ [運営] エラー報告、「青空絵日記」で検索可能で「絵日記」で検索不能

25日に行われた、MySQLのデフォルト文字コードの変更のためのエラーらしい。「where like」だと駄目で、「regexp」を使うといいらしい。調べてみると色々とヒットするのですが、文字コードの取り扱い方が違うらしいとしか分かりませんでしたが、想像はつきます。

16進表現で比較しているとすると、検索できたり、できなかったり不安定になるはずはない。文字として比較したとしたら、文字化け状態で比較することになり、同様の文字化けと比較するわけで・・・・例えば「絵日記」だと「文字+数字(?)」と解釈されることになる。ujisなどは2バイト、utf-8は可変バイトなのが原因のようです。

(ISO-8859-1 Latin1では日本語に割り当てられている範囲が使用されていないために、競合が起こらず、正しく検索できる。もしくは、1バイトごとに分けられるために、誤変換が起こらないといった方が正確かも。)

要するに、「where like」は文字列比較、「regexp」は16進表現での比較。問題は・・・・・全部書き換えないといけないらしいということ、果てしなく面倒だ。実行時間は若干「regexp」の方が早いかもしれないのがせめてもの救いだ。


2005-10-27 [J]

_ [メモ] 検索スクリプトの進行状況 独自・タイトル・ブランド・サイト終了

上記4つが動作確認済み。残りは手を付けていませんが、今日の夜にでもやります。

_ [メモ] MySQLのデフォルト文字コードの変更の影響

通常バックスラッシュで特殊文字を通常文字として認識させる。ただMySQLでは(/n)などを認識するため、二重にバックスラッシュしないとならないらしいが、PHPに専用の関数はないので、作らないとならない(非常に簡単だけれど)。

_ [雑記] 検索の利便性

今まではやってこなかったが、全角半角の差異は吸収した方がいいに決まっている。出来ればカタカナ、ひらがなの差異も吸収したい。ついでに、雑多な記号は全て無視するとなお良い。ただ、英単語の読み仮名はさすがに無理だが。

というか本当ならこれらはやっていて当然のことだろう。例えば、「ゲーム攻略への道」さんでは、英数字を必ず全角にしている。日本語環境以外から判別しにくいようにという意図だろう。そういえば、「Japanese only」と全角で表示しているサイトが昔あったらしい。

とにかく、まとめるべきだ。本当は当サイトでも統一していたのだけれど、拡張を進めるうちに、それがしっかりとされていない部分があったらしく、全角英数字が混じれ込んでいた。そこの所をどうにかします。

_ [メモ] 巡回スクリプトのバグ

まだバグがありました。分類の補完、複数分類の分離部分が問題で、登録サイトのレイアウト変更に対応すべく、四苦八苦している途中で見つけたわけです。まだ、あるかもしれません、バグ。

_ [メモ] スパムツッコミ

この頃、スパムツッコミが多くて困ってました。そこで、「最近多発しているツッコミspamへの対策」の通りに実行。これで、今のスパムは回避できるはず。でも、スパムの問題はスパムをする方が得だからなんですよね、引っかかる人がいて、規制もすくない(とはいえ、アメリカ、日本でも携帯などでは問題になり若干対応されています)。

_ [雑記] アクセス数

4月24日からの登録サイトへのアクセス数の推移を調べてみた。

合計857624

10月158102(11月1日計測184044)

09月166436

08月169549

07月136095

06月107929

05月119513

伸びているような、伸びていないような。大学生の休み期間中にアクセスが増えるのは当然のことなので、まぁ伸びているのかも。

_ [思案] アクセス数を使った厳選サイトのみの表示の実現

始めた理由とはかなり離れてしまいますが、サイト、ゲームタイトルのペアのアクセス履歴を残すと、不人気サイトの割り出しに役に立つので、やってみてもいいかなと思い始めています。上のアクセス数からも分かるように数ヶ月で数十万もしくは数百万のデータになりますが、限定的に利用すれば、日に一度だけ定点データを抽出するといった使い方であれば、重くとも問題ありませんし、厳選サイトのみを表示して欲しいという要望も根強いので。

ただ、個人的には不人気だから内容が良くないだとかそういうことはないと思いますし、用途によってサイトの良し悪しは変化すると思っています。アクセス数は、そうでなくとも偏りますし、不人気サイトにとっては機会自体が失われる事になりますから。

さて、では実現方法を簡単に書いてみます。

記憶するデータは、「アクセス日、ゲームID、サイトID、重複チェック項目」の4つになります。これを利用してデータごとの人気を割り出します、簡単に、「同一分類・タイトルのアクセス数の占有率」を割り出すのがいいのではないかと思っています。それを、全登録データで1日1回、直近1ヶ月ほどのアクセス履歴から計算し、記憶します。後は、フィルターで占有率何%以上を表示するというようにすれば、表示の自由度も上がりますし、登録データの多いサイトが有利だったり不利だったりということは起きません。

アクセス数が少ないか全くないタイトル、データについての取り扱いや、このフィルターによるアクセス数の格差の増大なども起きるかもしれません。それに、自作自演での人気取りの危険性もあります。

「君子危うきに近づかず」という言葉があります。ですが、これは明治期に作られたもので、孔子は真逆のことを言っています。まぁ、それは関係ないのですが、こういう刺激もあってもいいかな、とこの頃思うようになりました。


2005-10-31 [J]

_ [雑記] 登録用のスクリプトの書き換え中で、停滞中

どうも、書き換えをぶっつけ本番でやるのはよくないらしい。頭の中だけではなく、文章、グラフとして計画を立てないと手が進まない。今はちょっと違う方面の本を読んでいるので、プログラミング関係は読んでいなかったけれど、基礎本を少しずつでも読まないとならないらしい。

たとえば、今回の登録用のスクリプトで考えてみる。

機能的には、登録、登録内容の変更・削除、管理要員用の特別な変更を行えないといけない。これ自体は、考えるまでもなく関数にしてオプションで切り替えればいいと思うのだけれど、変数のチェック、正規の手続きを踏んだか、どの処理をするのか、ということを判断しないとならない。

ここまでは、書き出さなくとも頭の中で判断できるのだけれど、どの機能をどんな形で実装するのが最適かというのが難しい。

変数のチェックは、関数にしてif文で真偽を判断させて、真ならデータ処理をするというようにするべきか。それとも、変数のチェックの結果として、どの変数が偽だったのか返すようにして、個別的にエラーメッセージを表示させるべきか。そして、変数チェック関数の対象となる変数はどの範囲までにするか。他のチェック関数を作ると仮定して、互換性ある仕組みとしてはどのようなものがあるか。それになにより、javascriptでの事前のチェックも実装できるならそれに越した事はない(PEARのパッケージを使うという選択肢もあるが)。

正規の手続きを踏んだかどうかも、共通の関数にならないだろうか。判断を最後にしないと、解析されて手順を全て飛ばして登録される可能性があるので、最後にしないとならない。そうすると、他の全てのチェック(この場合はプレビューでデータが登録されることを確認してから)機械避けの文字を入力してもらわないとならない。間違った場合を考えて、入力データを保持しないとならない。

というようにざっと書いただけでも考える事が多くて、容量不足の我が心臓部には荷が重過ぎる。まぁ、実際は機能ごとに関数を作って、それらをまとめたクラスを作るだけなんですが、慣れていないのと、容量不足で進みません。

最後になんで登録用のスクリプトの書き換えをやっているかといえば、検索スクリプトの書き換えの延長線上です。以前も書いた大文字小文字の統一のための足がかりで、全書き換えを予定しているので、ついでに全面書き換えをやっているわけです。

_ [雑記] 情報が増えると

記憶<リスト化<カテゴライズ<全文検索<データベース検索

情報が増えると多分、こんな感じで情報の管理方法を変える。苗字を例にして説明すると次のような状況になっている。

昔、田中さんはひと家族だけだったので覚えていられた(記憶)、時が過ぎると田中さん一家はあちこちに散らばり覚えていられなくなったので家計図を作った(リスト化)、しかし田中さんはめいめい散らばったので家計図に書ききれなくなったそこで分家した(カテゴライズ)、分家していった田中さん同士は面識もなく共通点といっても「田中」である以外には見つけられなくなった(全文検索)、「田中」という共通点以外は接点のない人々が「全国田中さんの会」結成(データベース検索??)

カテゴライズまでは、人による情報の整理がなされるので、適合率、網羅率共に100%の状態にある。ただ、その管理が不可能になると全文検索のみに頼らざる負えない。そうると、適合率と網羅率はトレードオフの関係に陥る。あいまいさを増せば、検索に引っかかる件数が増えるが、目的以外の情報も合わせて付いてくる。正確さを追求すれば、目的の情報が漏れる可能性がある。これがまだ「人間に管理できない」程度の情報量ならば問題は少なく、網羅率を追求すればよいだろう。ただ、現在のような膨大な情報を対象とした場合は、網羅率を下げれば、情報が見つからず、適合率を上げようと思うと、情報が溢れてしまう。

適合率と網羅率という観点で情報量が増えるとなぜ困るかという問題もまた例で考えてみよう。

田中さんは模擬テストを自習して100点だった。田中さんは1位だ。

田中さんのクラスでテストをやった田中さんは90点だった。田中さんは5位だった。同順位に1人いた。

田中さんの学年でテストをやった田中さんは80点だった。田中さんは25位だった。同順位に5人いた。

以下・・・学区で・・・田中さん125位。同順位25人。日本で・・田中さん3125位。同順位125人。世界で・・・・9765625位。同順位15625人。

というように、同順位、差異のない情報が同一グループ内に多数入り込み、統計的に最善の適合率、網羅率が分かったとしても、最小単位のズレでカテゴライズ時代の全データ分を越えるような情報が引っかかるようになってしまう。その問題を解決しようとするのが、セマンティック・ウェブでありデータマイニングだと思っている。ただ、最終的には検索者の個体差によって情報の許容範囲にばらつきがあるので、なんらかの手段、例えば価値判断を共有する、価値判断のブックマークとでもいうべきものを作り、検索結果に検索者が作用を及ぼせるような仕組みを作り、適合判断の代替者を育てるなどの方法を考えないとならない。

ということが本に書いてある・・・・夢を見た。