Mojolicious + DBIx::SkinnyでWeb中央図書館2を書き直してる。
DBIx::Skinnyがすごい良い。自分にすごいマッチした感じ。まじべた褒め。
今までDBIを使ってきた(DBICは重そうだしうーーんとか思ってた)事もあって、一々SQLがガツガツ書いてたのだけど、一瞬で書けちゃうよ。複雑なSQLも書けちゃうし、生でもいけちゃう。
あと認証の部分とかのapiを見直してみるとなんでこんなん書いてるの?と思うくらいひどいので、それもガッツリ書き直してる。メソッド名からしておかしいよね、っていうのもある。
デメリットとして今まで出来るだけ使ってこなかったblessを使いまくってるので、パフォーマンスが下がってしまうのが少し不安だけど、Mojoの上に乗っかてるし、死ぬほど重くなったらサーバ変えてFastCGIで動かせば良いだけだなと思った。サーバ移転するお金ないけど。
githubのほう。
TagHelperとかも入って、良い感じ。
でも、lib/Mojolicious.pmとか無駄にblessするところがあって、なんで変数に入れないのか気になる。
数日前にMojoliciousを使って、トップを書き換えてみた。
特に新しいことがないので、書くことがない。困った。
あとMoe::GoogleAd::MobileJPってのを作ってたんだけど、Moe用だったのを書き直した。名前空間がちょっと気持ち悪い感じだけど、めんどいからそこまで気にしてない。
更新した。
メソッド名を変えたり、モジュール更新したり。
メソッド名変える時は、Devasが便利です。
アクセス出来ないとかあったら教えて下さい。
画像アップロードもサーバの関係で本当は実装出来ないんだけど、思い付きでそれっぽい機能が付けれたし、Image Girl3も萌える画像集めるよ!なんて言ってるけど、仕組は超簡単で1分に一回API叩いてるのみ。その1分に一回叩くのもサーバの関係上普通は出来ないけど、出来る様にしてるだけ。
色んな事を知っていれば、色んな事が思い浮かぶ。
昨日、アイディアをすごい持ってるベンチャー企業の中の人と話していて、ポケーッとそんな事を考えてた。
言いたい事
評価方法は、一択式の方が良い。
様々な評価方法
評価方法は、5段階評価、goodとbadで評価する方法(二択式)、goodのみで評価する方法(一択式)等がある。
五段階評価を行なっているのは、小説家になろう、リニューアル前のyoutube。
二択式は、リニューアル後のyoutube、nanapi。
一択式は、facebookのLikeボタン、Twitter、僕が運営しているWeb中央図書館2。
どれが信用出来る評価方法か
五段階評価については、youtubeがダメだと結論付けたという記事があるので是非見て欲しい。
YouTube Blog: Five Stars Dominate Ratings
解説記事:YouTubeが5つ星級の発見:評価システムは無意味だった
これで五段階評価が消え、残りは二択式、一択式になった。
僕は、二択式は、人によって押すボタン、押さないボタンが違う(様々な種類の評価者がいる)ので二択式によって得られた評価は信頼出来るものではない、と考えている。
例えば、同じ動画サイトを見ているAさんとBさんがいるとする。
Aさんは、良いと思ったらgoodを押すが、悪いと思ったらbadは押さない。
ところが、Bさんは良いと思ってもgoodは押さないが、悪いと思ったらbadを押す。
極端な話、そこそこ良い動画をAさんの様な人達が見たら、goodは増えるし、Bさんの様な人達が見たら、goodは増えない。むしろ微妙と思った人のbadが増えてくる。
Aさん、Bさんが必ず二択の内のどちらかを押せば、この評価方法は成立つ。
しかし、評価する人によって押すボタン、押さないボタンが出てくる事から二択式は信頼出来る評価ではない。
その一方で、一択式は敢えてgoodのみに絞る事で、評価を行なう人をAさんの様な人達のみにした。二択式でbadを押していた人は評価する人ではなくなり、評価を行なう人のタイプが統一出来る。よって、一択式の評価は信用出来る。
結論
五段階評価は、もう古い。
二択式は、評価する人の種類がごちゃごちゃになっており、評価が信用出来ない。
一択式は、評価する人の種類が統一されているので、評価が信用出来る。
だから、評価システムは一択式を採用するのが一番良い、と思った。
あと、あんまり関係ないけど、nanapi [ナナピ] – みんなで作る暮らしのレシピ -は、かなりオススメです。
nanapiの初期バージョンに検索窓がなかった理由 : ロケスタ社長日記
この記事を見て、少しずつステップアップさせる方法は間違ってなかったと気づけて良かった。けど、的確なステップアップが出来る様に勉強する必要があるなと思った。
まだ公開する気のない状態(適当に書きなぐった状態)でこの記事を公開してしまっていたので、一旦非公開にして色々と書きなおしました。恥ずかしい。
Image Girl3 | 萌える画像を集める憎めない奴。
更新効率が悪かったので、そこを改善しました。今までの数倍は余裕で更新されると思います。むしろ、数十倍までいってしまうかもしれない。恐ろしい…。
この極度に高い更新率が原因で出てくる問題が、RSSに関係するものです。
提供しているRSS自体は、最新15件をデータベースが更新される度に更新して表示していたので、RSSリーダーが頻繁に巡回してくれれば問題はありません。
しかし、RSSリーダーの巡回速度がほんの少し遅い為に、更新された画像がRSSリーダーに捉えられず、スルーされてしまいました。
((巡回速度がある程度遅いのは、当たり前。10分に数回アクセスされたらうざい人もいるだろう))
1 2 3 4 5
| RSS更新(画像: A-O)
↓
RSS更新(画像: E-S)
↓
RSSリーダー巡回(画像: E-Sをキャシュ) |
上の図だと、RSSリーダーにA-Dがキャッシュされていません。これでは、更新しまくる意味があんまりないのではないかと思いました。
というわけで、それを解決する為にRSSのitemの数を15件から100件に変更しました。正直な所、これでも漏れてしまいそうな程高い更新率ですが、これを機会に是非RSSを活用してみて下さい。
Image Girl3 | 萌える画像を集める憎めない奴。
説明するのって難しいなあ。
追記
バグがあったので、修正