ActionMailerのparts_orderのバージョンによる挙動の差異
railsのmultipartのメール配信で、ActionMailerのバージョンの差異で詰まったのでメモ。
multipartのメールを送る場合、parts_orderというパラメータでメール形式の優先度を指定することができます。
class ApplicationMailer < ActionMailer::Base default parts_order: ["text/plain", "text/html"] end
こんなかんじで、parts_orderを指定します。 ぱっと見text/plainが一番優先されそうですが、RFCでは一番最後のものが優先される仕様になっています。 なので、上の場合だと、
text/html > text/plain
という優先度になり、htmlメールを閲覧できるクライアントではデフォルトでhtmlメールが表示されます。
ただ、ActionMailer4.0.0未満では、mailメソッドにブロックを渡すと、ブロック内で定義した形式順に優先度を上書きできる仕様になっていました。
class ApplicationMailer < ActionMailer::Base default parts_order: ["text/plain", "text/html"] def _multipart_mail(headers={}) mail(headers) do |format| format.html {...} format.text {...} # ActionMailer4.0.0未満ではparts_order関係なく後に書いた方が優先される end end end
なので、上記のようにparts_orderの順序とblock内の順序が異なると思わぬ挙動になる可能性があります。 multipartで意図した形式でメール配信されない場合にはこのあたりを疑ってみるとよいかもしれません。
上記のActionMailerの仕様変更は下記にまとまっています。
rails/CHANGELOG.md at 4-0-stable · rails/rails · GitHub
change logみると4.0.0に下記が含まれています。
Explicit multipart messages no longer set the order of the MIME parts. Nate Berkopec
2015年を振り返る
12月ですね。
もう一年が終わってしまうなんてはやいですね。
思えばこのブログは昨年転職を思い立ってからなにかアウトプットしていかなければということで立ち上げたものでした。
単純ですね。
1年前の記事みると興味ある会社とか知ってる会社の本とりあえず読もうと思ってとりあえず読了ポストしててうけます。
まあなんだかんだ、去年の年末もう限界だ会社無理だって思って仕事を休んでから、しばらく将来について悩み、5月になんとかうまく転職でき、晴れて事業会社のWebエンジニアとして仕事ができております。
新卒で入った会社はWebの受託をやっていて、恵比寿の地下で、オシャンティーな恵比寿の雰囲気とはかけはなれていて、とにかく毎日なにかと闘っていました。
なぜこんなに消耗しているのかわからなかったけどとにかく仕事をし続けていた気がします。それはそれでよかったこともあるけど。
思い返すと、その当時の同期と３年後にガーデンプレイスのてっぺんに入ろうぜなんて話を内定式のときにしていて、ガーデンプレイスの前で明るいうちからヱビスビールの缶ビールで乾杯して夢を描いていました。
3年のうちにそんな夢はどんどん夢になってしまってみんな別の道を歩んでいったけど、自分は３年越しに恵比寿に戻ってきてしかもガーデンプレイスで仕事をしていて、もちろん自分の功績でそうなったわけではないけど、なにかの因果を感じずにはいられません。
これからの3年はエンジニアとしてこれまでと違う3年を過ごしていきたいですね。
そして3年後はどこかの島か山奥かでリモートワークを謳歌していたいですね。
それを目指して頑張っていきたいと思います。
話が変わりますが、12月といえばAdvent Calendarですね。これまでで3本書きましたが、あと1、2本くらいチャレンジできたらいいなという所存です。
1年前と比べるとだいぶアウトプットできるようになったような。
ご指摘あればください！
技術メモ
Heroku Pipeline
9/1にbetaリリースされたpipelineという機能。 まだ使ってないけど、コードのチェンジログの可視化と環境ごとのマニュアルデプロイをやりやすくする機能みたい。 あまり日本語の記事がないので、使ったら書こう。
Hosted capistrano
capistranoのページにいったらポップアップででてきた。
harrow.ioがcapistranoのデプロイ機能をサービスとして提供してるかんじ？ harrow.ioというciサービスも今まで知らなかった。（使ったことあるのはwerckerとcircle ci, semaphoreのみ） これも使ってみたい。
bitbucket→wercker→herokuでCIをまわす
やりたいこと
- railsアプリケーションをbitbucketでprivateで管理、masterへのpushもしくはmergeで自動ビルド、herokuにデプロイ
- 極力タダ
参考にしたもの
Githubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみる | mah365
bitbucketとwerckerでhubotをherokuに自動deployしてslackに通知する - Qiita
つまったこと
wercker.ymlの書き方がわからない＆初回ビルドで落ちる
werckerで新しいアプリケーションを作成すると、リポジトリの連携のあとに、勝手にwercker.ymlをつくってくれるので、それをコピーしておく。
最初コピーせずにスルーしてそのままつくって、あとからネットで調べて拾ってきたてきとうなwercker.ymlを使うとyamlのvalidationエラーになって、通らなかった。
単純にスペースの数だとかyamlの記法に従っていなかっただけだと思うけど、werckerが生成してくれる雛形を使ってそこからカスタマイズしていくのが無難。（英語ちゃんと読めば書いてあるw）
テストで落ちる
これはrails newしたあと、rspecのインストールなどをしていなかったから。rspecの設定は、あらかじめ.rspecとかでやっとくといいでしょう。
js実行環境で落ちる
`autodetect': Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
autodetectするのにexecjsがみつからないよと怒られる。
gem 'therubyracer'を追加してやればおk。
デプロイの設定の仕方がわからない
これが一番こまった。なぜなら、参考記事ではwerckerでdeploy targetにherokuを設定しろと書いてあるのに、werckerでherokuが選べないからだ。
なんでなのかはあまり調べるのに時間かけたくなかったのでわからないままだったけど、custom deployでherokuの設定ができたのでよかった。
やったこととしては、
- wercker.ymlにheroku用の設定を書く
- werckerの環境変数に各値を設定
です。
wercker.ymlのデプロイに関する設定は、
deploy: steps: - heroku-deploy: install-toolbelt: true key: $HEROKU_KEY user: $HEROKU_USER app-name: $HEROKU_APP_NAME
こんなかんじにしておく。
で、werckerの環境変数の設定で上記をそれぞれ設定する。
HEROKU_KEYは、herokuのaccount manageの中にあるAPI KEYです。
HEROKU_USERは、ユーザー名（＝メールアドレス）。
HEROKU_APP_NAMEは、herokuで動かしているアプリの名前。
んで、デプロイすれば通るはず。
0円CIすばらしい！
