ursmから、このようなものが何故必要なのか、そしてidobataで実際にどう利用しているのか、ということを話してもらった。

なぜ必要なのか

Railsのプロセスはだいたい200Mくらいはメモリを使うので、たとえばそれを32個上げるとするとそれだけで 200M * 32 でだいたい6Gくらいのメモリを使うことになる。(そして、メモリは普通有限なのだ)

たとえば1秒かかる処理があると、同時に捌けるリクエストは32個になってしまい、33個目は1秒後に処理が開始されることになって、レスポンスを返すまで2秒かかる。

これが1秒ならまだいいが、普通、処理待ちをしている間にもどんどんリクエストは来るので、雪だるま式に処理待ちのリクエストが増えていくことだろう。

なので、同期処理が必要ない部分は、積極的に非同期処理に逃がしていかないといけない。

Background Job Workerはどれを使えばいいの？

2013年では以下の4つのライブラリを抑えておけば十分で、それぞれ特徴があるからアプリの特性やインフラと相談して決めるのがいいよということ。

• Resque
• Sidekiq
• queue_classic
• girl_friday

まず、ResqueとSidekiqについて。 仕組みはだいたい同じだが、Resqueは処理がプロセス、Sidekiqはスレッドになっている。

Ruby(MRI)はグリーンスレッドなのとMRIは1.9以降はネイティブスレッドだけどGVLがあるのと、マルチスレッドがらみのメモリリークやバグに悩まされたくないなら、とりあえずResqueという選択でもいいかもしれない。

queue_classicは、ジョブキューがPostgreSQLのPubSubを使っているので、ポーリングしている他のライブラリに比べて仕組みがクール。Redis等を入れなくてもいいので便利。

girl_fridayは、ジョブキューを自身のプロセスの中に持っている。ジョブを依頼する側と処理する側が同じプロセスになるので、ちょっと面白い(強引な)こともできたりする。ただ、Railsのプロセスが落ちるとジョブキューも無くなってしまうので、Redisバックエンドの仕組みを入れておいたほうがいいだろう。

因みに、私はとあるアプリでインフラにあまり手をいれたくなかったので、girl_fridayのオンメモリで実装したことがあります。ただ、それは運用の支援ツールみたいなやつで、「だめなら再実行すればいいからさくっと作ってほしいという話だったからなので、なるべくRedisバックエンドにしましょう。

まとめ

あまりこの辺に詳しくないなら、まずはResqueを使おう。ただ、Sidekiqでも実感できる程の処理の遅さはないと思う。

DBMSがPostgreSQLならqueue_classicは試してみる価値があるよ。

girl_fridayは、仕組みが面白いから教養として使ってみるといいかも。

ちなみに、idobataではSidekiqとgirl_fridayを使っているとのこと。(なんで2つあるのかは、忘れてしまったそうな)

今年の採血は痛かった。

最近ちょっと体重が増えたような気がしていたけど、1Kgくらいしか増えてなかった。ただ、お腹回りがたるんできたような気はするので、なにかしたほうがいいのかなぁ。

あとは、目がたぶん悪くなったかも。左右で差があるのはしょうがないにしても、今年は結構自覚できるくらい見え方に差があってちょっと凹んだのでした。(といっても両方1.0くらいはあるけど)

TDDBC長岡で主催の@dictavさんにお会いして「今度Niigata.rbやるならお手伝いさせてください」と話していたので、その約束を果すために「私がテスト駆動開発について思っていること」を発表してきました。

狙いとしては

• テスト駆動開発という言葉は聞いたことあるというくらいの人に「テスト駆動開発ってこんなことでいいんだ」と思ってもらう
• 日々テスト駆動開発をしている人には、自分だったらどう考えて、どう書くかを考えてもらう

ことができたら嬉しいなぁと思ってストーリーを考えました。

この思いが、少しでも伝わった方がいれば嬉しいです。

当日のスライドはこちら。

昔は蒸し暑いなぁと思っていた地元も、東京の暑さを知ってからは快適すぎて昔はごめんなさいという感じ。なにより夜ちゃんと気温が下がるというのがすばらしい。

近況として、まもなく家の前の小学校(実家は、文字通り小学校の校門の目の前にあるのだ)が統合されそうという話と、中学校は既に統合が決まっているという話を聞いて、田舎の厳しさを噛み締めている。

あと、ずっとカナブンが蛍光灯に突撃しててうるさい。

誕生日プレゼントに頂いた本シリーズ第1弾。

エモいプレゼンはもちろん、テクいプレゼンにも役立つ要素がぎっしり詰まったとてもよい本だった。

今まで他人に勧められるプレゼンの本と言えばプレゼンテーションZenかパブリックスピーカーの告白だったんだけど、それぞれ

• Zenはエモいけどね
• パブリックスピーカーの告白は具体的な技法とかの話はほとんどないけどね

という但し書きを付けて紹介せざるをえなかった。

しかしこの「プレゼンテーションパターン」は「技法」と「心構え」、その両方がバランス良く紹介されているので、どんな人が読んでも役に立つことがあると思う。

ページ数も少ないので、毎回プレゼンテーションの準備をする前にパラパラ見るだけも、その都度新しい発見があるんじゃないかと期待させる一冊だった。

誕生日プレゼントに頂いた本シリーズ第2弾。

立ち読みでパラパラ読んではいたんだけど、その時の感想は「この業界に興味のある人が一冊目に読む本としてはすごくよさそう」というものだった。

しかしちゃんと読んでみると、Webサービスを作り始めるところから公開した後まで、数多くのサービスを公開してきたゆーすけべーさんのノウハウの断片がちりばめられて、どんな人が読んでも勉強になることが多い本だと感じた。

また、もっと深く知りたい人向けの参考文献のチョイスも流石で、もちろん初学者の人にもお勧めできる。

ただ、唐突に「いかにおっぱい画像を」というような章が始まったりするので、電車の中で読むときは最新の注意が必要である。

めずらしく奥さんに言われる前に我慢できなくなっての散髪。前回が5/16だったので2ヶ月半くらい。夏だしまぁこんなもんかな。

今のプロジェクトは Jenkins に bundle update した上で Pull Request させる - @kyanny’s blog を参考に10弱くらいのリポジトリを週1で bundle update してるんですが、今朝のアップデートで mysql2 があがってちょっとだけはまったのでメモ。

問題が起きたのは、SELECT SUM(column_name) AS s FROM table_nameという感じでSQL的にSUMしたときなんだけど、もしかしたらSUM以外でも影響あるのかもしれない。

0.3.11では、SUMを入れると必ずBigDecimal(ただしfloatを除く)だったのが、0.3.13だと「その数値を表現するのに必要十分な型」で返すようになったような印象。

地味にDecimalのprecision: 10, scale: 0の結果が変わってるのがちょっと疑問が残るところ…

以下に例を上げておきますので「そうじゃねーよ」ということなら教えてください>< (ちなみに、Railsは3.2.11です)

例

以下のようなモデル(Point)があったとして、それぞれどんなかんじになるかというと

class CreatePoints < ActiveRecord::Migration
  def change
    create_table :points do |t|
      t.integer :i
      t.float :f
      t.decimal :d1, precision: 5, scale: 2
      t.decimal :d2, precision: 10, scale: 0

      t.timestamps
    end
  end
end

0.3.13の結果

irb(main):001:0> Point.create(i: 1, f: 1.1, d1: 1.2222, d2: 1)
   (0.0ms)  BEGIN
  SQL (0.3ms)  INSERT INTO `points` (`created_at`, `d1`, `d2`, `f`, `i`, `updated_at`) VALUES ('2013-07-22 11:30:40', 1.2222, 1, 1.1, 1, '2013-07-22 11:30:40')
   (0.1ms)  COMMIT
=> #<Point id: 1, i: 1, f: 1.1, d1: #<BigDecimal:7f930db7b4a0,E'0.12222E1',18(45)>, d2: 1, created_at: "2013-07-22 11:30:40", updated_at: "2013-07-22 11:30:40">

irb(main):002:0> Point.select("SUM(i) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(i) AS s FROM `points` LIMIT 1
=> 1

irb(main):003:0> Point.select("SUM(f) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(f) AS s FROM `points` LIMIT 1
=> 1.100000023841858

irb(main):004:0> Point.select("SUM(d1) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d1) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f930db243d0,E'0.122E1',18(18)>

irb(main):005:0> Point.select("SUM(d2) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d2) AS s FROM `points` LIMIT 1
=> 1

0.3.11の結果

irb(main):001:0> Point.create(i: 1, f: 1.1, d1: 1.2222, d2: 1)
   (0.0ms)  BEGIN
  SQL (0.3ms)  INSERT INTO `points` (`created_at`, `d1`, `d2`, `f`, `i`, `updated_at`) VALUES ('2013-07-22 11:30:40', 1.2222, 1, 1.1, 1, '2013-07-22 11:30:40')
   (0.1ms)  COMMIT
=> #<Point id: 1, i: 1, f: 1.1, d1: #<BigDecimal:7f930db7b4a0,E'0.12222E1',18(45)>, d2: 1, created_at: "2013-07-22 11:30:40", updated_at: "2013-07-22 11:30:40">

irb(main):001:0> Point.select("SUM(i) AS s").first.s
  Point Load (0.1ms)  SELECT SUM(i) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31daaf1730,E'0.1E1',9(18)>

irb(main):002:0> Point.select("SUM(f) AS s").first.s
  Point Load (0.3ms)  SELECT SUM(f) AS s FROM `points` LIMIT 1
=> 1.100000023841858

irb(main):003:0> Point.select("SUM(d1) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d1) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31da9b7e28,E'0.122E1',18(18)>

irb(main):004:0> Point.select("SUM(d2) AS s").first.s
  Point Load (0.3ms)  SELECT SUM(d2) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31da98b440,E'0.1E1',9(18)>

そろそろ音質()よりも利便性を取りたくなってきたお年頃なので、Bluetoothヘッドセットを買いました。

アキヨドで店員と話した感じだと、AT-PHA05BT はやっぱり鉄板で、次点で HA-FBT60 ということだった。

後者のやつはノーマークだったのでいろいろ聞いてみると

• 3種類あるけど受信機は一緒でイヤホンが違うだけ
• これに付いてるイヤホンが一番コスパがいい
• クリップのところが金属だから折れない

というあたりがオススメポイントらしい。

ただ、よほどの掘り出しものがなければ SBH50 にしようと決めていたので結局これを購入。

3日くらい使ってみた感想は概ね満足。思ったことを以下に書いてみるので、参考にどうぞ。

• ペアリングが切れたりすることもほとんどない(と思ってたら今日謎の切断があった…)
• 商品紹介にある Twitter や Facebook の通知を受けとるには「スマートコネクト」なるアプリを入れないといけないけど、これはこれで便利だった
  • ペアリング開始したら自動で音楽プレーヤーを起動したり
• ディスプレイには日本語もちゃんと出るが、日本語の読み上げはしてくれない
• NFC はペアリングを変えたりしないので使ってない…

付属のイヤホンはだいぶ残念な感じだけど、イヤホンを取り替えられるタイプのやつを買う人は大抵好きなイヤホンを使うと思うので、7,000 円で有機ELディスプレイ付きならまぁ満足できるのではと思います。

RubyKaigi 2013 で見て以来ずっと気になっていたんだけど、予想よりもずっとずっと面白くて2週くらい読んでしまったのでした。

私のように、一応情報系の大学は出ているけどコンピュータサイエンスを真剣に勉強してこなかった人にぴったりな感じ。

最後の方はかなり難解な言語が出てきて頭を抱えながら読んでみたけど、「とりあえず流し読み、最後の解説を読む、本編もう一度読む」とするとだいぶ理解が深まるのでオススメ。

参考文献も丁寧に紹介されていて、もっと深く勉強してみたいと思わせるようなすばらしい本でした。