仕事と晩飯とその他

日記です。

予想を上回る面白さ

連休明けにGOTを最終話まで。すっかり放心状態。次は何を見るかと思うが、TWDのシーズン9はアルファの登場で食傷気味なので別のを。「ブレイキング・バッドとGOTは現代の教養」という意見を見かけて『ブレイキング・バッド』の一話を視聴。なにこれ面白い。あるジャンルとの類似性に気がついて愕然。なるほどなるほど。納得しまくり。しかし、見始めると長いので他のを。ということで、気になっていた『クレイジー・リッチ』。メッチャ面白い。というか、この齢になって「オレはロマンティック・コメディというジャンルが好きだったのか」と気づくなど。で、なぜかその後は、「ちょっと前に話題になっていたけど観ていない邦画」を連発で。まずは『銀魂』。あー、なるほど、そういうことね。諸々納得。おかしいっちゃあ、おかしい。続いて『HK 変態仮面』。なるほど、馬鹿馬鹿しい。続編も見る。なるほど、馬鹿馬鹿しい。んー、でも、ムロツヨシ佐藤二朗はお腹いっぱいかも。ということで、『進撃の巨人』。評判悪いけど、どうだろう、そうでもないと思うのは原作読んだことがないからだろうか。続編も。脈絡ないっていうか、話つながってないだろみたいな指摘はわからないでもない。けど、オレは案外楽しめた。で、次何見るかと思って『寄生獣』、続編も。あー、これは面白いと言ってよいのではないだろうか。やっぱり演技なのか、そういうことなのか。で、その次は「そういえば、これ、観たことなかったな」ということで『下妻物語』。

 

マジか……。

 

下妻物語』、すげえ面白いじゃん。つうか、深キョン土屋アンナも、なにこの青春のいちページ、最高かよ!

 

予想を遥かに上回る面白さは『下妻物語』でした。これ、皆さんが絶賛するの分かるわ、確かにそういう映画だわ。いやあ、いいもの観させてもらった。ありがとうございます。

エラー処理

黒白表、アイテム・書店ともに絞り込みは完了。条件を指定したうえできれいにクロス集計できるようになった。

残るはPDOでSQLを実行した際のエラー処理のみ。いつもは「そもそもSQLのエラーが発生しない」を目指しているのだが、条件で指定するとなるとそういうわけにもいかないので、このあたり、しっかりとやっておきたい。それが終わったら社内で公開。

社内で公開したあとは、DBをSQLiteに置き換え汎用性をもたせたうえで他社向けに公開の予定。他のグラフ関連もついでに。しかし、いつになったらそこまでたどり着けるのか。予定は未定。

最終日はダラダラ

連休最終日、午前中は連休前に作っていた黒白表の続き。要はPHPで抽出したデータをクロス集計して二次元配列に格納するということなのだが、範囲の抽出で手順を間違えたようだ。やるべきことはわかったので、土日にでもなんとかしよう。

午後は録画してあった『アベンジャーズ エイジ・オブ・ウルトロン』やら久々にリアルタイムでTV番組を見たりなんだりとダラダラ。梅酒を飲みながらだったのだが、途中で急に、昨日までよくわかっていなかった例の誤差逆伝播法について納得したり。要は微分でそれ以上でもそれ以下でも無いということか。何がわからなくて悩んでいたのだろうか。

朝は豚肉と白菜のマスタード炒め、昼は納豆チャーハン、夜は西京焼き・サラダチキンを乗せたサラダ・若竹煮・ワカメの酢の物・冷奴・ミョウガと豆腐の味噌汁。

本を読むのと黒白表以外の宿題はあまり片付かず。楽器の練習は諸事情あって二日で中断。ミュートを使うと夜でもいけるとのことなので夜に練習しようかとも思うが「思いっきり音出さないと練習にならないでしょ」という家なので……。多分、土日に再開の予定。

連休中に壊れたのは眼鏡と風呂の追い焚き。眼鏡は度の合っていない古いものだったので、どのみちそろそろ作り直す時期だった。給湯器は9年ぐらい前に交換したのでまだ寿命ということではなさそう。故障しない道具はない。やむなし。

読んですぐ理解というわけにはいかないのが当たり前だなあ

『ゼロから作る Deep Learning』、githubから落としてきたコードを読んだり実際に動かしてみたり、どうしてもわからない話や使い方がイマイチ不明なメソッドを検索したりなんだりを何度も繰り返してなんとか読み終えた。とはいえ、後半は実際に動かすというより読む→わからないことを検索してなんとなく把握→読む→よくわかっていないようなので検索→なんとなく把握→読むの繰り返しとどん詰まり。誤差逆伝播法のあたり、やっぱりよくわかってない。あとレイヤーの実装についても、一度読んだ程度では自分には無理っぽい。

ということで、通読して得られたのは「Deep Learningというのはこういうことをやっていたのか」というざっくりとした把握(理解とは言ってない)と、用語に戸惑わない程度の基礎知識、あと、Pythonの書き方については随分と勉強になった(とはいえ、これも自由に書けるほどのモノにはなっていない)。

事前にほんの少しだけかじっておいてよかったなあと思ったのは、数年前にやり直した数Ⅲの微積+教養課程程度の解析幾何の基礎と画像認識(Computer Vision)の畳み込みと微分≒差分とかそのあたり。勾配って傾きだから微分≒差分でOKなんだなあ。解析的な諸々をプログラムで表すっていうのはなかなか面白いなあ(とはいえ、そこのツボである誤差逆伝播法はイマイチわかっていないのだが)。

なんというか、一度通読した程度の「分かる!」とか「実装できる!」とか、そういう類の本ではないことはよくわかった。ので、ちょっと時間をおいてから再読する予定。

プログラミングの本でも人文科学でもなんでもそうだと思うが、「通読すれば分かる」ではない本というのはたくさんある。というか、エンタメでもなんでも、前提知識が必要な本であればだいたいそうだろう。なので、自戒を込めて思うのは、「すぐに分かる」とか、そういうのはやっぱりちょっとアレなのかも知れない。

などと、そんなことを思った連休も残り一日。明日は残った宿題のいくつかを片付ける予定。

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

デルタのほう、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時半の更新で、ようやく全て完了。よかった。

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