トップ «前の日記(2005-10-27 [J]) 最新 次の日記(2005-11-01 [J])» 編集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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