こんにちは！

• 山本悠滋(@igrep) 26歳♂
• 前回から続けて失礼。
• Eightのサーバーサイド担当です。

こんにちは！

• マイブーム: レス画像にプリキュアの画像を使う。
• 
• 

きょうのおはなし！

• 前回と同じぐらい軽いノリでEightチームに「本当にあった怖い話」をしますよ！
• ちなみにこのスライドの見出しまで前回といっしょですね！
  • パワポとかじゃないからスライドのテーマを変えるのが面倒臭かったのはないしょだ！

Disclaimer!

（周りの出方を見て入れるか検討）

• このスライドはEightチームにあった出来事を淡々と描くものです。
• 意外と意識が高いため、実はあまり怖くないかもしれません。
• 過度な期待はしないでください。

その1: 見えない500

• それは、私がjoinして間もない2013年の春頃でした…。

その1: 見えない500

• なぜか通らないControlerのテスト
• デバッグコードを仕込んでも辿り着くことなく、何事もなかったかのように500が返る。
• Response bodyも空っぽ…

その1: 見えない500

• 標準出力が意味不明なので log/test.log とにらめっこしていると…
• なんかスタックトレースらしき文字列の配列をinspectした跡が。

その1: 見えない500

イメージ

その1: 見えない500

• ( ^o^)＜(Iさん（元自衛官）に聞いてみよう！)
• ( ◠‿◠ )☛
      (ApplicationControllerでrescue_from Exception)
• ▂▅▇█▓▒░(‘ω’)░▒▓█▇▅▂うわあああああ

その1: 見えない500

「ApplicationControllerでrescue_from Exception」
と言えば。

• （Controllerでの）すべて（の例外）を無に帰す最強の黒幕<ラスボス>
  • ただのNoMethodErrorも、
  • TypeErrorも、
  • ActiveRecord::ValidationErrorも、
  • すべては闇に葬られるという…。

その1: 見えない500

• 僕「…で、これ何してるんですか？」
• Iさん「起きた例外をDBに保存しています。開発中なにかおかしかったらこのページを見ます」
  • （保存した例外の一覧が見えるページを開く）
• 僕「…はぁ。(さっきのスタックトレースはこれにINSERTする時のか…)」

その1: 見えない500

• 僕「でも、テストだとdatabase_cleanerがあるから消えちゃうじゃないっすか。今まで例外が見えなくて困ったことはないんですか？」
• Iさん「σ(ﾟ･ﾟ*) うーん…」
• Iさん「そういえばすぐ気づいてコメントアウトしてますね…」

＿人人人人人人人人人人人人人人人人人人人人＿ ＞ すぐ気づいてコメントアウトしてますね ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

その1: 見えない500

教訓:

• rescue_from Exception に限らず、
• rescue Exceptionはマジで真剣に頼むから
  • 慎重に使おう。
• 怖いのはコードだけじゃない、怖くなったコードを受け入れてしまった人も（僕も含め）怖い。
• (^_^;) ちなみに、その後Rails.envがtestの時はrescue_from Exceptionしないよう変えて解決。

その2: 逆さ仕様

• 要件: iPhone版で、Passbookを応用した名刺交換機能を作りたい。
  • 名刺を送信するユーザーの、プロフィール名刺の画像をPassbookの仕様に合わせたサイズに変換したい。
  • ただし、縦横比は保ったまま。
  • Passbookが指定するアスペクト比に合わない画像の場合、余った部分を透明にする。

その2: 逆さ仕様

• ググったら出てきたGihyo.jpに載っていたコードを参考に
• 即実装・即確認・即PR・即マージ
• ステージングで確認！ところが…

その2: 逆さ仕様

なんか妙に左上にずれた画像に… (;_;)

その2: 逆さ仕様

• どうもステージングと開発環境とでImageMagickのバージョンが大きく離れているのが原因らしい。
  • （ステージングのほうが新しい）
• どっかでエンバグしたのか、と思いいろいろなバージョンでやってみるも、どうも開発環境のバージョン以外うまく行かない…。

その2: 逆さ仕様

• バグレポを送るべく再現コードを小さくするよういじっていたところ、
• 「(・－・)…ん？もしかして？」
• 使用していたMagick::Image#extentメソッドに渡す引数 x, y の正負を逆転させると、
• 元の通り普通に動いた！！！！！！１

その2: 逆さ仕様

• この不思議ビヘイビアに挑むべくImageMagickのChangeLog探検すると…

2010-09-13 6.6.4-2 Cristy quetzlzacatenango@image...

* Don’t negate the geometry offset for the -extent option.

• なんかそれっぽい記録が。

その2: 逆さ仕様

• 何言ってんだよ逆に反転してんじゃねぇかよ… （#^ω^）ﾋﾟｷﾋﾟｷ
• と思うも、どうやらこれはImageMagickのCLI版、convertコマンドの-extentオプションの話らしい。

その2: 逆さ仕様

と、言うことは、

• convertコマンド-extentオプションがバグっていたのを直した結果、
• RMagick始め数多存在するImageMagickのバインディングのextentメソッドの仕様も反転してしまった模様…。

その2: 逆さ仕様

ちなみに

• RMagickのドキュメントでは、

The upper-left corner of the new image is positioned at -x, -y.

• と、すでに負の数で指定することが仕様であるかのように書かれているという現実…。

その2: 逆さ仕様

教訓:

• これに限らず、ImageMagickは結構アレらしいので気をつけよう！
  • ImageMagick has a ridiculous development workflow
• 当たり前だけどちゃんと影響範囲を考えてバグ修正や仕様変更をしよう！
• ちなみに、関連するコードは私のブログ記事に詳しくあるよ！

その3: ありえへんキー 1

ある日。

• わけあってSさん（イケメン）が書いたspecを実行すると…
• 大量の外部キーエラー！

その3: ありえへんキー 1

• 僕「ちょっと〜！Sさんちゃんとspec通してくださいよ〜！」
• Sさん「えっ、こっちでは通るんですけど…」
• 僕「えっ」
• （ちなみに、当時CIをこれから導入する、というところでした…）

その3: ありえへんキー 1

• 確かに、お互いのSHOW CREATE TABLEを見ると食い違っている。
• ?(ο´･д･)??
• Nさん（後の出戻り）
  「ああー、それeight.ymlが食い違っているからですね…。」
• 僕「えぇっ、そんなまさかそれって…」

その3: ありえへんキー 1

＿人人人人人人人人人人人人人人人人人人＿ ＞ 設定によって異なる外部キーの有無 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

その3: ありえへんキー 1

• 詳しい事情はわかりませんが、外部キーの扱いにあぐねてたどり着いた手段の模様…。
• もちろん現在は廃止済み。

その3: ありえへんキー 1

教訓:

• データベースのスキーマはみんなちゃんと合わせよう。
• 外部キー制約の追加は計画的に。

その4: ありえへんキー 2

とある新機能をテストしていた時のこと…。

• 僕「さぁ、ステージングでも確認するよ〜」

＿人人人人人人人人人人人人人人人人人人人＿ ＞ 突然のActiveRecord::RecordNotUnique ＜ ￣Y^YY^YY^YY^YY^YY^YY^YY^YY^Y￣

その4: ありえへんキー 2

• なぜかステージング環境のみに存在するユニークキーが…。
• 対象のテーブルのマイグレーションファイルを逆上ると、
• コメントアウトされた「:unique => true」がwww
• ボスに確認の上、手動で削除…。

その4: ありえへんキー 2

教訓:

• お願いだからデータベースのスキーマはみんなちゃんと合わせてくださいマジで (;_;)。

その5: >>突然の 0.truncate<<

• ※原因不明、未解決の問題です。

その5: >>突然の 0.truncate<<

ついに先月！

• わーい！ ヽ(=´▽`=)ﾉ
  弊社もRails 4系に上げたよ！（4.2とは言ってない）

その5: >>突然の 0.truncate<<

ところがやっぱり…

• varchar(255)に設定していたカラムに上限以上の長さの文字列が書き込まれ、エラーが出るケースが多発。

その5: >>突然の 0.truncate<<

補足:

• Rails 4以降、MySQLの接続設定 SQL_MODE=STRICT_ALL_TABLES というのがデフォルトで有効になりました。
• 例えば文字列がカラムによって決まった長さを超えてしまった場合、
  • これまでは長さが超えた分を切り捨てていたのを、
  • エラーを出すようになりました。

その5: >>突然の 0.truncate<<

そこで。

• 実際にエラーが起きたカラムの多くは本当に切り捨ててもよいカラムだったので、
• 参照しているActiveRecordクラスのbefore_saveで適当にtruncateすることに。

その5: >>突然の 0.truncate<<

ところが…

• 突如大量に落ちるspec
• 問題のtruncateメソッドを呼ぶところで

wrong number of arguments (1 for 0)

• なる謎のエラーが。

その5: >>突然の 0.truncate<<

• どうやら、どこかでStringではなく0(Fixnum)のtruncateが呼ばれてしまうらしい…。
• 同様の修正をした箇所で必ず発生する模様…。
  • (^_^;) 「同様の修正」をした時点で抽象化しろよ、というツッコミに対しては前向きに検討します。

その5: >>突然の 0.truncate<<

• こちらのコードの問題なのかなのかActiveRecord側の問題なのかさえわからず、
  
• 真相は闇の中…。
  • （調べる気がない）

その5: >>突然の 0.truncate<<

教訓:

• (^_^;) スライドを書いているうちに改善点が見つかることもある。
  • みんな積極的に自チームの闇を発表して、己のコードと向きあおう！
• お後がよろしいようで。