コメントの管理のため、コメントのカテゴライズ機能を作ろうと思っています。
カテゴリー自体は実はもう既にあるのですが、それは表示切替のためのカテゴリーであり、普通に見えているコメントについては特に意味はありませんでした。
今度は、同じ表示状態であっても、情報提供や感想コメントなど、いくつかの種類に分けられます。
そして特筆すべきは、このカテゴリーがユーザーアクセス制御に連動しているということ。
例えばまだ書き込んだ経験のない人が書き込むと承認待ちのカテゴリーに入り、非表示状態で投稿されます。
逆に、たくさんまともな書き込みをしている人からの書き込みならば前例からして大体大丈夫なので、いきなり表示状態で投稿されます。
そして、いずれも管理人がチェックして、迷惑にならないちゃんとしたコメントならばそのユーザーにポイントをつけて、ポイントが一定以上になるといきなり表示状態になるようにします。
２ちゃんねるの忍法帖、なかなか興味深いですね。
・最初の利用時に自動的にユーザー登録される。
・登録に際しこちらから提供すべき情報は何もなし。
・登録は同じ環境から利用しているかどうかを判別するためのもの。
・登録したての頃は少しばかり制限がある。
・普通に使うのに支障が出るほどの制限ではない。
・普通に利用していくにつれて制限は解除されていく。
・普通の人が普通に使う分には実質無制限に使える。
・荒らしが手を変え品を変え荒らそうとしたら、制限に引っかかりまくる。
・使い込んだユーザーによる特定の操作により、荒らしに対し厳しい制限をかけることができる。
・厳しい制限を解除するにはユーザー登録の破棄しかないが、そうするとまた制限だらけの最初からやり直し。
つまり、不適切な言動をとるものやその可能性があるものに対し制限を与えることにより、そのような言動の発生頻度を抑えることができ、しかし普通の人には制限を感じさせない仕組みというわけです。
巨大掲示板群の自治のための機能なのでうちで真似するのには適さないと思いますが、部分的にでもTGscriptの参考にできたらなーと思っています。
アンパンマンDBに、アンパンマンの実際の映像から抜き出した静止画を表示するのを考えています。
著作権のこともあるので、あくまでも「引用」の範囲といえそうな範囲での実装を目指します。
また、正当に引用したものを第三者に不正に転用されるのは嫌なので、ある程度抑制できるように、定期的にURLを変更する機能なんかも付けてみようかと思っています。
引用の主な要件は、必然性、本文との主従関係、出典の明記ですが、前者二つは運営上気をつけることなので、システム上対応すべきは出典の明記です。
そこで、データベースには、一画像あたり、画像の元ファイル名、説明文、出典の三点を記録することになります。
画像の実際のURLは元ファイル名と現在時刻から生成、出典は基本的にアニメDBへのリンクでよさそうです。
アンパンマン商品DBについて、外部サイトとの連携があるから他のデータベースと同じような実装は難しいとかつて書きました。
しかし、よく考えてみると、連携が必要なのは商品説明文と画像程度のもの。
だとすれば、アンパンマンDB自体に外部サイト連携機能を付け、商品DBでのみその機能を呼び出せばよいのではないかと思いました。
アンパンマンコラム共々、他のデータベースと同じシステムを使った運用が可能そうです。
また、商品は他の項目と違って名前が長くなりがちだったり、毎回必要な注釈があったりと、運用の効率性の面から商品DBに実装したい機能もあります。
とりあえずこれらの機能は片っ端から実装していって、商品DBでは機能ON、それ以外では機能OFFという運用にしていったらよさそうだと思っています。
アキヤメの[アンパンマンキャラをポケモン風に]が動いていないという報告を受けました。
ローカルではばっちり動いているので、ローカルと公開用の違いを意識しつつ原因を究明したいと思います。
なんかTwitterの公式クライアントが気に食わないので、自作しようかと考えています。
ええ、自作です。他社クライアントなんて使いませんとも。
とりあえず、トレンドとかお勧めユーザーみたいな雑音は出さない。広告は言わずもがな。
検索は常に「全て」を検索。公式デフォルトの「トップ」は見たいものが隠されてしまううえ、まるで無関係なツイートがなぜか表示されてしまう。これは検索と呼べる代物ではない。
リツイートは原則として表示。ブラックリスト方式で非表示。「○○がリツイートしたツイートは無視」、「○○のツイートはリツイートされてもタイムラインに出さない」の2点でOK。
URLはリダイレクトを展開して直接表示。リンクは面倒なので貼らない。
ハッシュタグは普通に扱う。
自動ログイン方式について考えています。
うちみたいなサイトで細かいことを気にしても仕方ないような気もしますが、あまり安全でない方式と安全な方式があるなら安全な方式を選びたいわけで。
基本的にうちの参加型コンテンツでは、ログインIDとパスワードによる明示的なログインは用いない方針です。
原則として、勝手にIDを振って勝手に保存して、何もしなくてもパーソナライズされた結果が出るようにしたいのです。
次回アクセス時にIDを特定できるようにするため、クッキーにID読み出しのためのキーを格納しておいて、そのキーはアクセスごとに変わるようにします。
そうすると、保存すべきは毎回変わるキーだけで、ログインIDやパスワードといった情報はクライアント側には保存しなくて済みます。
この場合、ブラウザや接続元が変わるとログイン状態が切れてしまうので、明示的なログインも用意しておけば便利かと思っています。
イメージ的には、今の掲示板と似たような方式です。
アンパンマンDBのカテゴリやシリーズで、そのカテゴリに最もよく合うエピソードやキャラクターを優先表示とか、そういうのやってみようかな、って思っています。
たとえば「バトルもの」シリーズであれば、『アンパンマンとバイキン黒騎士』のように。
ただ、どのように表示するのかまでは特に考えていないのです。
アンパンマンDBバージョン3のデータベース構造の同期について。
データベース定義だけを記したファイルを用意しておいて、アンパンマンDBはデータベース中のデータ構造によらず定義ファイルにしたがって各種データ操作を行う。
そうすると、定義ファイルだけ最新でデータベース本体が古い形式であれば当然エラーが発生する。
そのときのエラーを捕捉して、データベース構造を自動的に最新のものに書き直し、改めてデータ操作を行う。
このようにすれば、普段はパフォーマンスを極力落とさず、データベース構造が変化したときには管理画面における更新手続きすらなしに最新版に更新されます。
このアイディア、すごくよさそうな気がしますが、果たして実装できるものなのか…。
脚本家の島田満さんに聞いてみたのですが、実はアンパンマン映画って「原作絵本」より先に「映画」ができるらしいです。
絵本の出版時期や情報の出てくる時期などを考えて、「まず原作絵本ありき」で作られているわけではないんだろうなとは予想していましたが、やっとはっきりわかりました。
もちろん年によってもこういった作り方が変わることはあるのでしょう。
たとえば同時上映の「うたっててあそび！アンパンマンともりのたから」は、対応する絵本「アンパンマンともりのたから」が昨年に出版されているので、文字通りの意味で、絵本が「原作」なのでしょう。
一方、「ばいきんまんＶＳバイキンマン！？」は、「アンパンマンとおえかきベレちゃん」が対応しますが、こちらは絵本のほうが後であり、映画のキャラを使って描き下ろされた別の作品です。
私はここTGWS以外でもいろんなサイトでいろいろやっているわけですが、そういった活動をどこかにまとめておきたいと感じています。
一応その役割はリンク集が果たしているのですが、奥まったところにありすぎていまいち使いやすそうにありません。
あのページの内容をトップページに移すなり何なりして利便性を図っていきたいところです。
バージョン3からですが、アンパンマン商品DBってのもやってみようかなって思っています。
理由はいくつかありますが、だいたい以下の3つです。広告収入は今更言うまでもないとして。
1.商品情報の入力補助機能をつけたい。
2.絵本など、アニメDBでは取り扱えない作品も載せたい。
3.商品つながりの検索機能をつけたい。
閲覧者側にとって意味があるのは3ですね。
私自身、商品の検索にアンパンマンDBを使っているので商品関連の利便性はとても大事なのです。
ふにゃさんのグラフィックについて。
いつまでも320x240の画面サイズでもないだろうということで、ウインドウサイズに合わせてゲーム画面を大きく描画するというのを考えました。
しかし、320x240の画面をそのまま拡大しては画像が荒くなってしまいます。
そこで考えたのが2つの方法。
1つは、SVGなどのベクターグラフィックを利用する方法。
これならば解像度を気にせず画面サイズに合わせて自由にきれいに拡大縮小できます。
単純なふにゃの造形とも相性抜群です。
しかし、SVGを読み込み表示するノウハウを私はまったく持っていませんし、それらしきライブラリの導入に成功したこともありません。
つまり、かなり難しそう、ということです。
もう1つは、あらかじめ大き目のビットマップを用意しておいて、実行時に縮小するという方法。
縮小アルゴリズムにもよりますが、小さい画像を拡大するよりはきれいに表示できますし、実装も比較的簡単です。
問題は、ファイルサイズおよびメモリ使用量が大きさに比例して増大するということ。
まあ、最近のパソコンなら大きな画像でもまったく平気かもしれませんが。
やっぱりゲーム記にアフィリエイトつけようかなぁ。と思っております。
以前日記に書いた検索性という点では意味がないけど、ゲーム記で興味を持ってそのまま買いに行けるというのはもしかしたら便利かもしれないと考えたためです。
しかし目ざわりで邪魔なアフィリエイトにはしたくはありません。
ゲーム記には実質的な内容が無いようなページも多いから、広告のためだけに作った手抜きページのように思われたくはないのです。
なので、せめて内容の薄いページでも内容＞広告の比重になるよう、広告の軽量化や、選択制ができるようにしたいと考えています。
CharaBoxをSQLiteなどのデータベースで置き換えようかなーなんて考えています。
まあ、考えているだけで今のところ実行に移すめどは立っていませんが。
うちのモバイル対応どうするか思案中。
携帯電話で自分のサイトを見るようになって気になりだしました。
プログラミングやダウンロードコーナーなど、携帯電話でわざわざ見ても意味のないコンテンツも多いのですが、一方でゲーム記やアンパンマンDBのように携帯電話で見ても充分意味のあるコンテンツもあるわけです。
しかし実際には横長のディスプレイにあわせて横幅を狭めるスタイルを適用しているので、横幅の狭い携帯電話では針のように細いページになってしまうのです。
うまくスタイルシートを切り替えて横幅だけでもなんとかしたいものです。
う～む、自己紹介のページがかなり重くなってきました。
そろそろページ分けできるようにしないといけませんね。
各質問ごとにページを分割して閲覧数によってランキングするとか、ランダムにピックアップするとかの工夫もしてみたいところです。
絵を使った何かを何かをやりたいんですよねぇ。
例えばアンパンマンDBの各ページにお絵かき掲示板機能をつけてみたりとか、それ以前に普通の掲示板のほうにお絵かき掲示板機能をつけてみたりとか。
凝ったことでなくてもいいから、何かやりたい、と思っています。
刑事ドラマがあって、検事ドラマがあって、弁護士ドラマがあって、捜査官ドラマがあって、裁判官ドラマがあって、裁判員ドラマがあって、ふと思ったのです。
裁判をはじめとする法律関係のドラマに被告人ドラマや証人ドラマが見当たらないことに。
例えば、「俺は松田美文。被告人だ。今日も無実の罪で逮捕された。」みたいに始まって毎回無実の罪で起訴される被告人が主人公とか。
そしてドラマが進むに連れて起訴される罪状がどんどんエスカレートするとか。
最終回、巨大な組織の国家的犯罪の濡れ衣を着せられた松田美文、果たして無罪を勝ち取ることができるのか！
窃盗から始まり殺人にいたるまで数々の濡れ衣が、巨大な陰謀へと繋がっていく！！
意外といいと思うのですが、誰かやらないでしょうかねぇ。
逆転裁判4のページを作りました。
まだ途中までしかクリアしていないので途中なりの内容で。
ゲーム記をリニューアルしようかと考えています。
今は各ゲームをハードごとに分類していますが、シリーズ作品やリメイク作品がマルチプラットフォーム展開していることが珍しくなく、ハードごとの分類だと不便な部分があるためです。
ただ、リニューアルしようかと「考えている」だけなので、実は今のところ実行に移す予定はありません。
アンパンマンDBの最近のTOP10が機能しなくなっていたので修正しました。
それはそうとちょっとニコニ・コモンズについて。
今はランダムに並べる機能がないのでなんとかこっち側で実装したい。
まず、サーチ結果のページ内容から「件中」を含む行を抜き出し、その行内でbタグに囲まれた最初の数字、または「件中」より前にある最後の数字を抜き出す。
0～抜き出した数字-1の範囲の整数の乱数(R)を生成する。
(R)を30で割った整数部分に1を足すとページ番号(P)、あまりがページ内オフセット(O)となる。
次にアクセスするURLは「http://www.niconicommons.jp/search/～?page=(P)&…」だとわかる。
「<!--thumb start -->」と「<!--thumb end -->」で囲まれた部分が一つ一つの素材。
正規表現などを使ってこの部分を順次抜き出せば(O)の値を使って目的の、つまりランダムな素材が見つかる。
偏りのある乱数生成器とニコニ・コモンズのソート機能を使えば新しいものや人気の素材が出やすいようなランダムセレクトも作れる。
これを順次繰り返せばランダムに並べる機能も作れるというわけ。
コモンズサーバーへの負荷を考えるならば同じページへのアクセスは極力減らして一回のアクセスで必要な情報を全部取り出すようにしたい。
アンパンマンDBのユーザーIDシステムについて考えています。
ただユーザーごとにIDを与えるのは簡単なのです。
しかしユーザーにとってのユーザーIDを使う利益というものが今のところないのです。
実際のところ導入したい理由というのが、ユーザーごとの制限を加えたいということなのです。
なので、サイト全体に通用するIDを用いるTGscriptのユーザーIDと一本化しようかということを考えてみました。
そうすれば掲示板の利便性との兼ね合いでどうにかなるかと…。