Railsのmasterのコードを読んでいて、コメント行でvariantメソッドにresize_to_fitオプションを渡しているのが目についた。
rails/variant.rb at master · rails/rails
というのは、ImageMagickのオプションにresize_to_fitに相当するものがなかったから。minimagickはImageMagickにそのままオプション渡しているはずなのになんでだろう？
Command-line Options @ ImageMagick
と、調べたところ、Rails6からはminimagickに変わってImageProcessingがデフォルトになり、ImageProcessingがresize_to_fitを提供している、ということだった。
Mogrify unrecognized option resize-to-fit · Issue #39 · janko-m/image_processing
letter_openerをよく使います。ローカルの開発環境でメールが送信されたらブラウザのタブが新しく開き、メールが送信されたことがすぐにわかる。べんり。
しかし、最近Docker環境で開発することが増えたので、自動でホストマシンのブラウザタブを開くことができなくなってしまいました。どうしよう。
開発用のメールボックスをブラウザで確認するgemとして有名なのはletter_opener_webとMailCatcherです。ざっと調べて所感をまとめました。
deliver_laterでも問題なくメール受け取れるはず結論として、とりあえずYAGNIの精神でletter_opener_webにしておくのがいいかな、という気持ちになってきました
Railsアプリケーションを書くときに、turbolinksやstimulusなどを使い、なるべくサーバサイドはHTMLを返してjsをあまり書かずに楽をする、という方針でいくとします。このように割り切るとだいぶ楽なのですが、例えば次のようなケースで悩みます。
一番最後の「もっと読む」ボタンを消すやり方が悩みどころです。単にHTMLを受け取りコメントの末尾に差し込むやり方では対応できません。だからといってレスポンスをJSONで返し、そこからDOMを生成するのは面倒なのでやりたくない。
いくつかやり方を考えてみました。
3か4のどちらかがよさそうです。1はDOM構造がページングの仕様に引きずられてしまうのがよくないでしょうし、2はstimulusを使っている場合はjsの処理が散らばるので可読性が下がりそう(stimulusを使っていなければこれが楽でよさそうです)。3は悪くないですが、これも若干DOM構造がページングの仕様に引きずられる感じがありますね。直感的ではない。
stimulusを使っているので、最終的に4で実装しました。こんな感じ。
fetch(Routes.api_comments_path({ page: nextPage }), { credentials: 'include' }) .then(response => { if (response.headers.has('X-Comments-Last-Page')) { this.pagingButtonTarget.style.display = 'none' } return response.text() }) .then(html => { this.commentListTarget.insertAdjacentHTML('beforeend', html) this.data.set('page', nextPage) })
開発用に、127.0.0.1に解決されるドメインを/etc/hostsに登録する、ということはそれなりにあると思います。
そのときに、次のように複数行に分けて書くとなぜか example.com へのDNS lookupがめちゃくちゃ遅くなります。自分の環境ではだいたい5秒ほどかかりました。
127.0.0.1 localhost 127.0.0.1 example.com
これを次のように1行で書くと問題なくなります。
127.0.0.1 localhost example.com
なぜか開発用のサーバが遅い！となってからここにたどり着くまでめっちゃ大変でした…＞＜
macOS 10.13.6
参考リンクをたどると、ずっと前からある問題っぽいですね。
OmniAuthを利用したログインのsystem specで、ログインに失敗した場合のテストが次のようなエラーになった。
1) ユーザがログインする ログインに失敗したとき "ログインに失敗しました"と表示されること
Failure/Error: click_link 'Twitterでログイン'
OmniAuth::Error:
invalid_credentials
# ./spec/system/login_spec.rb:98:in `block (3 levels) in <top (required)>'
もとになったspecはこちら。
context 'ログインに失敗したとき' do around do |example| original_mock_auth = OmniAuth.config.mock_auth[:twitter] OmniAuth.config.mock_auth[:twitter] = :invalid_credentials visit root_path click_link 'Twitterでログイン' example.run OmniAuth.config.mock_auth[:twitter] = original_mock_auth end it '"ログインに失敗しました"と表示されること' do expect(page).to have_content 'ログインに失敗しました' end end
これまでは普通にテストが通っていたのでなんだろうと思って調べた。
つまりテストの実行順序の問題で、pumaの起動がOmniAuthのテストより前に来てしまうとRACK_ENVがdevelopmentになり期待していた挙動と異なる振る舞いをするようになってしまっていた。
とりあえず明示的に、次の行をconfig/rails_helper.rbに追加したところうまく動くようになった。
ENV['RACK_ENV'] ||= 'test'
これ、自分と同じようにハマる人が出てくると思うのでライブラリ側でどうにかしたいのだけど、どのライブラリにどのようにPR投げるか悩ましいですね…
のどれか。rspec-railsでrails_helper.rbのテンプレートをいじってRACK_ENVもRAILS_ENVと同様に設定するようにする、というのがいいだろうか。
どこでRACK_ENVが設定されているか調べるのに使った雑なスクリプトを置いておきます
module DebugEnv def []=(*args) key = args.first if key == 'RAILS_ENV' || key == 'RACK_ENV' p args p caller end super end end ENV.singleton_class.prepend DebugEnv
あと、この手の環境変数関連のデバッグではspringは切っておいたほうが良さそう(ちゃんと調べきれてないけど、設定されていないはずのタイミングでRACK_ENVが設定されていて、これでかなり時間を奪われた＞＜)
また、rake spec や rakeでテストを実行しているときにはこの問題は発生しなさそう。
Turbolinks5になってから「フォームでバリデーションエラーになったあとその画面をリロードしたときの挙動がTurbolinksを利用していないときと異なる」という問題がある。
2年半くらい前からIssueが立っている
POSTしたあとの画面をリロードしようとすると、通常は「フォームの内容を再送信しますか？」みたいな確認ダイアログが出る。しかしTurbolinks経由だと単にいまのURLをGETで取得しようとする*1。これは、Turbolinksがhistory apiを使って履歴を操作しているのが原因。history apiに履歴を足すときはGETとしてのURLしか足せないので、現状のTurbolinksの仕様では対応するのは無理ぽい(放置されている原因の一つはこれだと思う)
そもそもTurbolinks(というかBasecamp)的には、formは全部js経由にしてしまう方針なので上記の問題で困っていない、というのもありそう。Railsでform_withを使ったとき、デフォルトではremote: trueになる。
普通はajaxリクエストでリダイレクトはできないのだけど、turbolinks(turbolinks-rails)ではajaxでpostを受け付けたときのハックが書かれていて、redirect_toされたときはTurbolinks.visitを使うようにしてリダイレクトを実現している。なので正常系だけならremote: trueで問題ない。
バリデーションエラーになったときの対応が面倒で、これは独自に定義をしないといけない。DHHはSJR(Server generated Javascript Response)でやればいいと書いてる。ようするにcreate.js.erbみたいなやつ。
Provide form_with as a new alternative to form_for/form_tag · Issue #25197 · rails/rails
わかるんだけどバリデーションエラーを表示するためだけにそれをやるのってめんどいのですよね。画一的に処理できるgemをつくればいいのか。すでに誰か作っていそうだからそれでも良さそう。
*1:railsであればindexアクションのURLになるはず
いつ書いたのか忘れたけど、下書きに書いてあったので公開
次のように、同じモデルに対してdependent: :destroyを設定してしまうと、もとのモデルを削除したときに二重にDELETEが発行されてしまう
class User < ApplicationRecord has_one :latest_post, -> { order(created_at: :desc) }, class_name: 'Post', dependent: :destroy has_many :posts, dependent: :destroy end
user.destroy (0.1ms) begin transaction Post Load (0.3ms) SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = ? ORDER BY "posts"."created_at" DESC LIMIT ? [["user_id", 1], ["LIMIT", 1]] Post Destroy (0.4ms) DELETE FROM "posts" WHERE "posts"."id" = ? [["id", 2]] Post Destroy (0.1ms) DELETE FROM "posts" WHERE "posts"."id" = ? [["id", 1]] Post Destroy (0.1ms) DELETE FROM "posts" WHERE "posts"."id" = ? [["id", 2]] User Destroy (0.1ms) DELETE FROM "users" WHERE "users"."id" = ? [["id", 1]] (0.8ms) commit transaction
dependent: :destroyは片方だけにしておいたほうがよさそう