最後の投稿から１年が経とうとしている

最後の投稿が２０１６年１２月２８日なので、もうすぐ１年が経とうとしている。 あっという間だったなあ。

仕事

仕事はAndroidを自動化するアプリをRuby（Ruboto）で作成していたのでAndroidアプリそのものの知識が深まった。 最初はPC接続してPCから操作していたけど、最終的には自動化用のAndroidアプリを作ってAndroid端末単体で自動化できるようにした。 もちろんデータベースは外部にある。 自動化する内容はRubyで書く。

苦労したのは画像マッチングするために必要な画面キャプチャのパフォーマンス。 普通に取得すると数秒かかったりするので非常に苦労した。

あとはRubotoかな。 自動化する内容はRubyで書き、それをAndroid端末内で実行する訳だけど、クラスの再ロードに苦労した。 意外と難しいもので、ファイルは更新されているのに古いクラスが動いていたりしてデバッグに苦労したこともあった。

ゲーム

ゲームは白猫プロジェクトをやった。 子供が面白そうに遊んでいたのを見て興味が湧いて、親の方が好きになってしまった。 Youtubeに動画をアップして楽しんだ。

仏教

仏教も継続して学んだ。 学ぶほどその教えの深さに驚く。 因果、無常、罪悪、この３つだけを突き詰めていけば、人生において何をすべきなのかがわかる。 逆に言うと、私がこの私の人生において唯一求めていること（それは私が幸福になることであるがこれ以上に難しいことはない）を獲得できない方法もわかるということ。 仏教は学び続けていく。

何だか今年の総括になってきた。

Macbook

そういえば、Macbook pro retina 15 (2016)を購入したが、まだ届いていない。 初日にポチったが構成変更するために一度キャンセルして再購入したため、発表から１ヶ月経った今でも待ち状態。 来週くらいに届く予定なので楽しみにしている。 現在使用しているearly 2013は、デスクトップ移動すると画面がかくつくし8GBしかないのでメモリ不足になる。 それが改善されると思うとワクワクが止まない。

来年

今年は外部との接触をほとんど取ってこなかったので、来年は接触を持って行こうかと思っている。 あと、サラリーマンを辞めてから時間はあるのに逆に勉強をしなくなったので、目標を決めて勉強していく。

MySQLの「Sending data」はクライアントへのデータ転送ではない・・・

MySQLのshow processlistで「Sending data」と表示されている処理はデータ転送だと思っていたが、そうではなかった・・・。先入観って恐ろしい。

今日はサーバが重かったので調べてみたらすべてのコネクションが「Sending data」となっており、処理に3分以上かかっていた。slow queryのログを見ると「limit 1」の検索ばかり。転送なんてあっという間のはず。と思って調べてみたら「Sending data」はクライアントへのデータ転送ではなかった。

「This is quite a misleading status. It should be called "reading and filtering data".」

→ http://stackoverflow.com/questions/10347193/what-does-it-mean-when-mysql-is-in-the-state-sending-data

「データの読み込みとフィルタリング」ということだ。データを保存している場所を主語として「Sending data 」と表現しているのかな。わからないでもないけど、MySQLの処理なんだから誤解しやすい。

updated_atが更新されなくて困った話

「変更がなくてもupdated_atを強制的に更新して欲しい」というクライアントの要望に応えるためにwill_change!を使用したが、うまくいかない時があったのでメモ。

update!の前に、「在庫数が変更されるよ！」というフラグを立てる１行を追加した。

@zaiko.num_will_change!
@zaiko.update!(zaiko_params)

しかし、updated_atは更新されない。変だなーと思ってrails consoleで調べてみたら、以下のようになった。

irb(main):080:0* z.num
=> 2
irb(main):081:0> z.num_will_change!
=> 2
irb(main):082:0> z.num_changed?
=> true
irb(main):083:0> z.attributes = {:num=>2}
=> {:num=>2}
irb(main):084:0> z.num_changed?
=> false

num_will_change!を使った後、そのnumを再設定してしまうと、以前のフラグが消えてしまい再度判定されてしまう。ということは、再設定される可能性がない属性に対してwill_change!をしなければならない。候補は、id, created_at, updated_atしかない。idは変な動きをされてしまうと嫌なので却下。まあ、ここはupdated_atを変更したいのだから、updated_at_will_change!を使うのが無難なのかな。ということで、採用したが、これがうまくいかない。というのも、updated文は実行されるが、前と同じ値が設定されてしまう。updated_atを明示的に設定したと判断されてしまうようだ。では、created_atを採用した場合はどうか、というと、この時に実行されるupdate文ではcreated_atも変更されてしまう。もちろん、変更前と同じ値なので無害ではあるのだけど、何だか気持ちが悪い。

ということで、結論は、updated_atを明示的に設定する！

@zaiko.updated_at = Time.now
@zaiko.update!(zaiko_params)

なお、@zaiko.touchも考えたが、実際に変更があった場合は２回SQLが実行されることになるので却下した。

なおなお、save!の時は、save!前に属性の設定をしているから問題にならない。

# save!前に属性への設定
@zaiko.num_will_change!
@zaiko.save!