仕事と晩飯とその他

日記です。

表紙画像を増やすことにしたのだが

Web制作 システム用メモ

デルタのほう、Pub DB との差別化を図るために、openbdに無い表紙画像をAから引っ張ってくることにした。と、その前に、openbdでの表紙画像の有無をテーブルに格納→それを使って表示するという流れを作ることに。TOPページでのランダム表示、今までは、テーブルからランダムに30件抽出→その分のopebdのjsonをget→coverの有無をチェック→coverがあった場合はファイルを読み込んでファイルサイズを取得→小さいもの（灰色一色）を除外→使える表紙画像を6件確保できたらbreak、という流れだった。これだと毎回coverのファイルを読み込んでファイルサイズを取得するので、時間がかかる（し、メモリも食ってる）。pagespeed insights でも、サーバーの応答速度は課題で必ず出てくる。なので、あらかじめcoverの有無と使用可不可を判定してDBのテーブルに持っておくと、そのあたりの速度は劇的に改善される、はず。

ということで、土日に作業。どうせやるならAの画像の使用可不可も判定して、テーブルに格納しておくと良さそうだ。

Aで表紙画像のないアイテムの時に表示されるタイトルが文字で書かれた青い画像だが、以前教わった「画像のヒストグラムを使って類似を判定」というのを使ってみることにした。まさにそのものというページを見つけたので、中身をよく読んで、しっかりと理解してからコピー。先日、最終的にはうまくいかなかったが、バーコードの読み取りに挑戦した際に画像認識などの仕組みを勉強した甲斐があって、割とすんなり理解できた。で、試してみたらあっさり成功。と思ったら、別の画像で試すと失敗。類似度というか差異度というかを表す数値を表示して他の画像も色々と試してみると、どうやら、「判定のもとになる画像と閾値の設定」が重要だということを知る。なるほど。

openbdの判定と合わせて一括で読み込むスクリプトを書いている最中に、「これって毎回ファイルを読み込んで判定してるわけだから、けっこう時間がかかるのでは」と思って試してみたら、案の定、かなり時間がかかる。とりあえず、使ってるレンタルサーバーでのcronの時間枠（処理は60秒以内）を超えるのは間違いない。ということは、つまり、Aからの読み込みもかなりの時間続く。それが原因でアクセスが禁止されたりするとつらい。

色々考えた結果、Aの一括判定→テーブルに登録は取りやめにして、openbd一括判定→flgの登録、だけにしたうえで、一括の対象を絞ってなんとか時間の問題はクリア。Aのほうは、個別書誌情報ページが表示されたタイミングでカバー画像テーブルにフラグが存在しなかった場合に限って、openbd判定（使用可ならフラグ登録して画像表示そうでなければA判定へ）→A判定（使用可ならフラグ登録して画像表示）という流れに。これだと、既刊にも対応できるので、結果的に良かったかも。

ということで、月曜日朝・昼休みまで費やして今回の仕組みは全て実装完了。思ったより上手く動いて満足。そして、気になるpagespeed insights のサーバー応答速度はようやく1秒を切った。よかった。

あとはopenbd一括判定のタイミングだけどうしようかと考えていたが、ちょっと前にテーブルを確認したら、カバー画像テーブルのフラグがごっそり増えてる。クローラーだろうか。これはこれでなんか良いのか悪いのか、イマイチ判断がつかない。そして、openbd一括判定は明け方、アクセスのほとんどない時間帯にひっそりと実行することにした。寝る前にcronの設定を書き直しておこう。

既刊まで含めて画像の問題が大きく解決できそうなので、これをどう使うか考えている。それとはまったく別に、分類についてもタギングというかフォークソノミーというか、そういうのを検討中。タグの仕組みについては会社のWebサイトで作ったので（その時にだいぶ調べた）、とりあえず、それと同じ要領で作るのは充分に可能。フォークソノミーということになると会員システムを用意しないといけないが、そっちは全く作ったことがない。そういうの、普通はwordpressやフレームワークを使うのが正解なんだろうけど、結局またフルスクラッチになるのではないかと今から懸念している。あと、これもまったく別に、出版社向けのサービスを準備中（ほとんど出来上がっている）。ただ、これ、今までになく「有料でもいけそう」なサービスなので、そのあたりも含めて会員システムの必要性を感じていたりというところもある。面倒なんだけど。ここ最近会社もデルタもガシガシいじっていて感じたのは「入力フォームとかバックヤードの仕組みを作るのは面倒で、正直あまり好きじゃない。それよりWebページを作るほうが面白い。どうやら、MVC（Model View Controller）で言うところのViewを作るのが楽しいみたいだ。でも、それで思い出すのは、前の会社のシステム構築をお願いしていたNさんが「データベースは入力フォームの作成が重要で、それが出来てしまえばあとの集計とかなんとかそういうのはなんとでもなる」と言っていた話と、亡くなったIさんが言っていた「昔は帳票（出力フォーム）の制作でいい金額が貰えたが今は無理だ」という話だ。やっぱりDBというかシステムのツボは入力フォームなんだろうな。