仕事と晩飯とその他

日記です。

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

デルタのほう、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というかシステムのツボは入力フォームなんだろうな。

怪我の功名

もう既にしばらく前の話だが、SEO絡み(特に会社の方)で、ああだこうだやってる最中に、ファイル名を変更したりディレクトリを移動したHTMLファイルを誘導するのに301リダイレクトを使うべきだということを今さら知った。ずっと meta refresh 使ってたわー。.htaccessをいじるのは気が進まないので、301リダイレクトについても知らないことにしていたのだが、改めてちゃんとした書き方を調べて対応。やってみると「こんなもんか」という感じで、それほどのこともない。とはいえ、正規表現がようやく少し使えるようになった今だから、そんなことが言えるのかも知れない。

その後、「.htaccessが使えないレンタルサーバでは meta refresh でしょうがない」ということを知る。そうだよなー、今使ってるレンタルサーバーの前は.htaccessいじれなかった。なので、その頃はそれでよかったということだ。

会社のほうだが、search console で調べる限りでは、昨年10月ぐらいから延々と続けているSEO対策の結果だと思うが、検索での表示回数は、対策以前の2.5倍ぐらいまで増えている。クリック数も、ここへ来てようやく増えてきた。が、GAで見るとPVやユーザーはほとんど増えていない。どうやら、PDFへのアクセスが増えているようなのだ。今は、そこへのアクセスをどうやってHTMLのページに誘導するかが課題。OBJECTでPDFをHTMLに埋め込めるそうなので、そういうファイルを用意するのが良さそう、と思ったら、safariがダメっぽい。色々難しい。

MySQLのバージョンアップ

デルタやですYO!のデータベースをバージョンアップ。MySQL5.5から5.7へ。

先週はうまくいかなかった。次の土日でやろうと色々調べたり試したりしていたのがよかったようで、予想以上にすんなり。というか、実質30分もかからず完了。よく考えたら、データベースからデータベースへテーブル(ファイル)をエクスポート・インポートして、あとはデータベースへの接続ファイルを書き換えるだけなんだから、そんなに時間もかからないか。先週失敗したのはよく調べずになんとなくやろうとしたからだったんだな。

と思っていたが、深夜になって急に「そういえばcronで設定したファイルがきちんと実行されているのだろうか」と気になって調べてみたら、なんということか、動いていない。cronで実行しているファイルを手動で動かしてみるが、エラー。そこから慌てて調べたら、移動し忘れているテーブルを発見。急いでそれを移動。再度実行。動いた。

もうひとつのPHPファイルも手動実行。動かない。エラーメッセージを書き出すように設定し直してエラーを調べる。変数の定義の問題があるのでエラーが大量に吐き出される。が、途中で止まった。そこを見るとSQLのエラーのようだ。該当するSQL文をMySQL5.7のほうのPHPMyAdminで実行。動かない。ここか。エラーメッセージを見ると、GROUP BYの問題らしい。カラムがGROUP BYされてないよということのようだ。んん? と思いつつ、該当のカラムをGROUP BYしてみたら動いた。なるほど。そこを修正したPHPファイルを実行。また途中で止まる。同じようなSQLがあったので、そこだった。修正して再実行。ようやく最後まで動作。よかった。

これで、cronで動かしていたPHPファイルの修正は完了。次のタイミングで、openBDの取り込み→既存のテーブルと比較して差分にフラグを立てた上でテーブルに格納→静的HTMLやランキング・検索用のテーブルなどを更新、という一連の手順が動くかどうか。

月曜になっても動いていない。調べてみると、動いていないわけではなく、深夜にやった作業で差分を作るためのテーブルが上書きされてしまっていたようで、差分が差分として取り込まれていなかったようだ(取り込み自体は成功)。それとは別にテーブルのエクスポート・インポートに失敗しているテーブルも発見。手作業で不足分をエクスポート・インポート。

結局、17時半の更新で、ようやく全て完了。よかった。

今回、テーブルサイズが大きくなるとエクスポート・インポートに手間取るのは誤算だったが、会社のレンタルサーバーの乗り換えのための良い予行演習になった。何事もやってみないと分からない。勉強になった。

土曜はすき焼き、日曜はハンバーグ

土曜日は金曜日に定期を忘れたせいで駅まで自転車を取りに行くところからスタート。定期入れに駐輪場のカードを入れておかないほうがよいのだろうか。その後、自転車で行ったり来たり。夕飯を作る気力も尽きて、手を抜くためにすき焼き。美味しゅうございました。

日曜日は家事三昧でへとへと。夜はハンバーグ。挽肉、室温に戻したつもりだったが、ちょっと冷たかったようで、中まで火が通らず。電子レンジで温め直し。失敗。しかし、味はなかなかよろしかったのではないか。サラダと付け合せを盛り盛り。スナップエンドウが好評。

月曜日、駅前のオリジン弁当がリニューアルとのことで唐揚げを売りまくっていたので大量に購入。レタスとタマネギとトマトのサラダ、さらに、カボチャとブロッコリとニンジンとスナップエンドウの温野菜サラダ。唐揚げにかけるネギダレも用意。ネギダレ大好評。唐揚げがいくらでも食える状態。それにしても、カボチャとブロッコリは冷凍のを買ってきて温めたほうが断然楽だ。冷凍庫の冷凍野菜が減ったので補充しておかないと。

食後に近所のスーパーに買物に行ったが財布を忘れるという失態。花粉かなあ、最近ぼーっとしてる。

 

2月は2回、話を聞きに

2月26日の出版学会産業部会セミナーと、2月28日出版学会電流協共催セミナーに参加。

書店による責任仕入の方向性は、どこまでカバーできるかという問題と絡んでいて、弊社は指定される方なのかそうでないのかが分からない。見計らいがなくなったら配本は激減するのではないかと見ている。
本の価格は高いか安いか。自分は常に「高い」と思っている。消費者が安いと思っていたらバカスカ売れている。書店からの「単価を上げて欲しい」は、最終的に店舗の売上に結びつく話でなければならないので、
(価格を少し上げても売上が減らない)安い本は上げて(総売上を増やしたい)、
(せっかく店に並べても価格が高すぎて売上に結びつかない)高い本は上げて(少しでも売上を増やしたい)
ということなのだと思う。店頭で売るのを諦めて高すぎる値段を付ける本が店に並ばないのは仕方が無いところもある。

本を売るのにSEOの話は、某社によるSEOの再発見というか再発明が面白くて。で、電子書籍のアンケートなのにSEOの項目が無いのはその場でなんとなく空気があって、「次回の調査からSEOについて項目を増やす」ということになったのは、まあ、そういうことだと思う。

データベースのバックアップというか引っ越しというか

25日に「注目度を示す表示」と「扱い社別の一覧」を作った。なかなかうまく行ったが、注目度のほうは閾値の設定が甘い。調整したほうが良さそう。

この土日は、「注目度」を定時に書き出す静的なページにも適用するつもりだったが、その前にデータベースの容量を確認したら、500MB超えてる。しょうがないから分割するか、などと準備を始めたら、よく見るとさくらインターネットのDB容量は1.5GBにまで拡大されたらしい。しかし、MySQLのバージョン5.7? デルタのDBは5.5だ。

まずはMySQLのアップデートが先のようだ。でも、どうやって? 調べると、PHPMyAdminにツールが用意してあるそうで、簡単にできるらしい。ということで、新しいDBを準備してシンクロ……と思ったら、うまくいかない。一度エクスポートしてからインポートしてもダメ。単純に容量の問題らしい。gzipで圧縮すると驚くほど減るので試してみたが、それでも16MiBを超えるのが複数。分割してエクスポート→インポートするか、SSHを使うかしかないようだ。

ああ、こんなことならもっと早い段階からSSHを使っておくべきだった。今回を機に使ってみるというのもあるが、とりあえず分割エクスポートで対応することにしよう。

と、その前に。会社のお問い合わせフォームは、お問い合わせ本文にURLが入っていると弾くようにしている。デルタのフォームはそれをしていないせいで迷惑メールがひどい。ので、特定のドメインと出版社名にURLというのを弾くようにした。これでかなり減るが、さて、一般的なドメインの場合はどうするかと思い、この段階でようやく検索。そうか、ワイルドカードか。ていうことは、正規表現でもいいのか。なるほど。

※その後、16時過ぎになってようやく移行を始めたものの、全然うまくいかない。分割して読み込めるファイルサイズにしたsql.gzをインポートしても、なぜか全部のデータがインポートできない。何度も繰り返すうち手順は慣れた。が、うまくいかん。

諦めて検索。PHPMyAdminで正確なレコード数が出てこないっていうのは常識だったのか。そこで完全にはまってた。分割エクスポート→インポートの手順はなんとかなりそう。巨大化してたDBは、試験的に使っていた不要なテーブルを削除することでとりあえず解決したので、DBの引っ越しは来週にする。

朝から着手してたら今頃終わってたかもなあ。ダラダラしていた自分が憎い。
表示速度が遅い気がしてたが、DBの容量だったのかも。不要テーブル削除して軽くしたらサクサク動いてる。MySQL5.5と5.7だとかなり速度も違うらしいので、早く移行すべきであった。
晩飯は雛祭りなんで、ちらしとはまぐりのお吸い物と刺し身。はまぐりのお吸い物が褒められたが、千代の一番が素晴らしいのだ。

出来てないということは余地があるということではなかろうか

今日は久しぶりに近刊検索デルタをいじって、
「扱い社別近刊一覧」
「扱い社別及び出版社別一覧等でアクセスをもとに注目商品を強調」
「個別書誌情報ページでの扱い社の表示」
「個別書誌情報ページに『同じ出版社の既刊から』セクションを追加(強調表示込み)
スタイルシートの細かい調整」
などを行なった。
扱い社別近刊一覧は、現状の貧弱な網羅性だと公開するかどうかかなり迷う。作業してる最中は「みんな全然情報公開してないじゃん。こんなんじゃ売れるわけないよ」と思っていたが、しばらく経って考えると「情報公開ひとつとってもこんだけ出来てない、ということは、余地がありまくり、つまり、スマホ時代のインターネットにきちんと対応できたら一気に売上取り戻せる可能性もあるんじゃないか」などと考えるように。ポジティブに過ぎるか……。