こんにちは、hachi8833です。
Rails
ActiveSupport::OrderedOptions#dig!
の提案(現在オープン)
つっつきボイス:「ついさっき(注: つっつきが行われた10/19夕方)神速さんがこのプルリクを投げていたのをruby-jp Slackで見かけました: fetch
をチェインしなくてもこうやってdig
で書けるんですね」
# Before
Rails.application.credentials.fetch(:aws).fetch(:access_key_id)
Rails.application.config_for(:example).fetch(:foo).fetch(:bar)
# After
Rails.application.credentials.dig!(:aws, :access_key_id)
Rails.application.config_for(:example).dig!(:foo, :bar)
「ほほ〜、dig
は前からRubyにもRailsにもあるけど、ここで提案されているのは!
付きのdig!
だから、指定したキーが存在しなかった場合にエラーをraiseするということか」「なるほど」「たしかfetch
はキーが存在しなければエラーをraiseするけど、今のdig
はそうなっていないからdig!
を提案しているんですね: これはたしかにあっていいメソッド」
# activesupport/lib/active_support/ordered_options.rb#L53
def dig!(*keys)
keys.flatten.inject(self) do |h, key|
h[key.to_sym].presence || raise(KeyError.new(":#{key} is blank"))
end
end
参考: Hash#dig
(Ruby 3.2 リファレンスマニュアル)
参考: Rails API dig
-- ActiveSupport::OrderedOptions
参考: Hash#fetch
(Ruby 3.2 リファレンスマニュアル)
「Ruby本家でも以前からdig!
が提案されているそうです↓」「たしかにRuby本体にもあっても全然いいメソッドですね」
参考: Feature #14602: Version of dig that raises error if a key is not present - Ruby master - Ruby Issue Tracking System -- 現在オープン
「ところでRubyのハッシュのキーを厳密に扱おうとすると厄介な点があるんですよ: ハッシュのキーにアクセスしてnil
が返ってきたら"そのキーは存在していない"と解釈するのが普通ではあるんですが、実は"そのキーの値がnil
である"可能性もある」「あ〜、それ怖いヤツだ」「dig
の場合は、nil
が返ってきたときに"キーが存在しない"と解釈するか"キーの値がnil
である"と解釈するかが、ともすると曖昧になることがあるんですよ」「う〜む」「そこを厳密に判定するなら、キーが存在しなければ確実にエラーをraiseするdig!
が欲しくなるでしょうね」「やっぱりnil
値怖い...」
マイルストーンから: Rack::Sendfile
削除の提案と、フォームのremote
やlocal
オプション廃止の提案
- PR: Remove Rack::Sendfile from the default middleware stack by SValkanov · Pull Request #44556 · rails/rails -- 現在オープン
つっつきボイス:「RailsのGitHubリポジトリにマイルストーンが2つできていたので、そこから2つ取り上げてみました」
参考: 7.1.2 Milestone
参考: 7.2.0 Milestone
「1つ目は7.2.0マイルストーンにあった、Rack::Sendfile
ミドルウェアをデフォルトで削除してダミーのFakeSendfile
に置き換えようというプルリクです: send_file
で使われるRack::Sendfile
が、リバースプロキシなしだとセキュリティ的にあまりよろしくないという話が以前から指摘されているので、それに関連しているようです」「あらま」「以下の記事でもRack::Sendfile
は使わないなら外しておこうと書かれていますね↓」
参考: RailsでRack::Sendfileを使っていない場合は外しておいた方が良いという話
- PR: Forms: Deprecate
local:
andremote:
options by seanpdoyle · Pull Request #43418 · rails/rails -- 現在オープン
「2つ目も7.2.0マイルストーンにあったもので、form_for
やform_with
のremote
オプションやlocal
オプションの扱いを修正しようというプルリクです」「2年前のプルリクだけど、これ修正したくなるのわかる!: どっちのオプションがどう効くのかわからなくなること多すぎ」「ほんとそうですよね」「form_for
でremote
だったのがform_with
でlocal
に変わったんでしたっけ?」「えっと、そのはずです」
「上のform_with
APIドキュメント翻訳を更新したときも、local
オプションの説明がよくわからなくてさんざん確認したのを思い出しました↓」「実際に動かさないと確信が持てないレベル」
「form_for
は禁止ではないけど、とっくに非推奨なんだから、form_with
だけ使いやすくなってくれればそれでいいと思うんですけどね」「どんな形になるかわからないけど、よくなって欲しいです」
Rails 7.1で生成されるDockerfile
つっつきボイス:「Rails 7.1でrails new
するとproduction用のDockerfileも生成されるようになったんですが、そのあたりを試してみた記事です」「お〜、今どきのRailsはDockerで動くのがもう当たり前になってきてるので、Dockerfileの設定を考えなくて済むのはありがたい」「自分でも試したんですが、生成されるDockerfileには、rails new
に渡したオプションに応じてPostgreSQLやSQLite3の関連ファイルも自動追加してくれていて、Dockerのマルチステージビルドも取り入れられています」「いいですね〜」
# SQLite3の場合
# Install packages needed for deployment
RUN apt-get update -qq && \
apt-get install --no-install-recommends -y curl libsqlite3-0 libvips && \
rm -rf /var/lib/apt/lists /var/cache/apt/archives
# PostgreSQLの場合
# Install packages needed for deployment
RUN apt-get update -qq && \
apt-get install --no-install-recommends -y curl libvips postgresql-client && \
rm -rf /var/lib/apt/lists /var/cache/apt/archives
参考: マルチステージ ビルドを使う — Docker-docs-ja 24.0 ドキュメント
「自分でもRails 7.1アプリをrender.comにデプロイしてみたところ、無改造のDockerfileがそのままストンと使われました」「なるほど」「記事でもRails 7.1を例のkamal(旧MRSK)でデプロイした例を紹介していますけど、Rails 7.1のDockerfileはkamalでの利用を意識しているようです: ちなみにkamalはssh接続さえつながればクラウドの種類やベアメタルを問わずDockerベースのプロジェクトをデプロイできるそうです」
参考: Cloud Application Hosting for Developers | Render
TLDR: 速度重視の?minitest風テスティングフレームワーク(Ruby Weeklyより)
- 元記事: The TLDR on Ruby's new TLDR testing framework: jk this is totally the "too long; read anyway" post
つっつきボイス:「この間Railsコミッターの@tenderloveさんとtestdoubleの@sealsさんが発表していた高速なテスティングフレームワークだそうです」「"遅いテストを待っていられない人のためのフレームワーク"ですか」「TLDRって?」「"長すぎるから読んでない"(too long; didn't read)という人向けの要約を表す、英語圏でよく使われる略語ですね」「昔なつかし今北産業みたいなヤツですか」「同じこと思った」
参考: tldrの意味・使い方|英辞郎 on the WEB
同リポジトリより
「デフォルトでパラレルに動作するんですって」「minitestとほぼ互換とあるので、minitestとは別物ということかな」「直近で変更されたファイルを最初にテストするのね」
「最初はジョークだったけど本当に作ってみたということみたい」「んん、よく見ると"1.8秒経過したらテストの実行を止める"...だと?」「やっぱりジョークだった」「そりゃ速いわ」
なお、元記事の趣旨は「全部のテストをたまに実行するより、小さなテストを頻繁に実行する方が効果的である」「テストが1.8秒で強制的に打ち切られれば無意味なテストを削除するモチベにもつながるだろう」という、ジョークとも本気ともつかない味わいに満ちています。
Rails 7.1でテスト失敗のデフォルト出力が変わっていた話(Ruby on Rails Discussionsより)
つっつきボイス:「これは自分がたまたま見つけたもので、コントローラのテストが失敗したときの振る舞いがRails 7.0と7.1で違っていることに気づきました↓」「今まではActionNotFound
がraiseされてたのに、404 Not Foundに変わっちゃったのね」
# Rails 7.0の場合
$ bin/rails test
...
StaticPagesControllerTest#test_should_get_about:
AbstractController::ActionNotFound: The action 'about' could not be found for StaticPagesController
test/controllers/static_pages_controller_test.rb:16:in `block in <class:StaticPagesControllerTest>'
...
# Rails 7.1の場合
$ rails test
...
1) Failure:
StaticPagesControllerTest#test_should_get_about [/Users/hachi8833/deve/yasslab/environment/sample_app/test/controllers/static_pages_controller_test.rb:17]:
Expected response to be a <2XX: success>, but was a <404: Not Found>
「それで上のdiscuss.rubyonrails.orgで質問したところ、以下のコンフィグが7.1で変わったためではないかと教えていただきました(#45867): 設定を:none
に変更したら従来と同じ振る舞いに戻りました」
# 7.0まではtrueかfalseを設定できる
config.action_dispatch.show_exceptions = false # デフォルト
# 7.1では:all、:rescuable、:noneを設定できる
config.action_dispatch.show_exceptions = :rescuable # デフォルト
参考: §3.5.9 ActionDispatch::ShowExceptions
-- Rails アプリケーションの設定項目 - Railsガイド
Ruby
Ruvy: ShopifyによるRuby用WebAssemblyツールチェイン
つっつきボイス:「Shopifyがまた新しいものをリリースしました」「RubyコードとRuby VMをWasmにビルドできるのか!」「まだ始まったばかりみたいですが、Shopifyの実装力と実績からするとそう遠くないうちに仕上がるかも」「ちょうどこういう記事も出ていますし↓、WebAssembly周りがだんだん加速されている気がします」
参考: VSCodeがWebAssemblyの実行時デバッグに対応。C/C++やRust、Zigなどのソースコードと関連付け、変数参照、ブレークポイントなど可能に - Publickey
つっつき後に以下の記事も公開されていました↓。同記事で、ShopifyがJavyというJavaScriptをWasmにするツールチェインも2月に出していたことを今頃知りました。
参考: より高速なRubyのWebAssembly実装「Ruvy」、Shopifyがオープンソースで公開。Ruby仮想マシンとRubyアプリを組み合わせてビルド - Publickey
参考: Bringing Javascript to WebAssembly for Shopify Functions (2023)
その他Ruby
- イベント: 各社の技術広報が明かす「RubyKaigiスポンサーの裏話」運営ノウハウやコミュニティへの想い - connpass
- Twitter Comminuty: Ruby AI コミュニティ / X(Ruby Weeklyより)
つっつきボイス:「1件目は、マネーフォワードが主催するRubyKaigi 2023の振り返りイベントで、RubyKaigiに参加した人や来年沖縄で開催されるRubyKaigi 2024に関心のある人に加えて、スポンサー企業やスポンサーを検討中の企業の技術広報や採用担当者にもよさそうです」
「2件目はRuby AIというTwitterコミュニティです」「RubyをAIで書くのかな、それともRubyでAIを書くのかな?」「どっちだろう...どちらの話題もいけそうな気がします、たぶん」
A community for folks interested in learning about and building AI applications in Ruby
Community Descriptionより
CSS/HTML/フロントエンド/テスト/デザイン
Tailwind CSSがカオスにならないためのベストプラクティス5つ(Ruby Weeklyより)
- 元記事: 5 best practices for preventing chaos in Tailwind CSS—Martian Chronicles, Evil Martians’ team blog
つっつきボイス:「個人的にTailwind CSSが好きなんですが、Evil Martiansが使いこなしのコツを記事にまとめてくれていて、近々翻訳記事を出します(しばらくTailwind話)」
参考: Tailwind CSS - Rapidly build modern websites without ever leaving your HTML.
「Tailwindは使ったことないけど、CSSを別ファイルに書くというのが好きでないので、定義済みのCSSクラスをHTMLのclass
属性に書けるとか、CSSクラスの名前を考えなくていいみたいなのはちょっとよさそうですね」「記事によると、専門のデザイナーが作ったデザインシステムが何らかの形でプロジェクトで確立されていることと、いわゆるコンポーネント(ViewComponentやPhrexなど)がプロジェクトに導入済みであることがTailwind CSS導入に欠かせない要件だそうです」
参考: デザインシステムとは?|国内外の参考になる事例10選と共に解説|セブンデックス
つっつき後に以下のツイートを見つけました。Rails WorldでもTailwind CSSのトピックが登場していたんですね。
My talk from #RailsWorld is up!
Really happy with how it came out — it's a great overall intro to the framework but also includes a lot of fun tricks you might not know about even if you use Tailwind every day.https://t.co/43DRpb3HBm
— Adam Wathan (@adamwathan) October 19, 2023
後編は以上です。
バックナンバー(2023年度第4四半期)
週刊Railsウォッチ: 7.1アップグレードガイドにActive Record暗号化設定の注意事項が追加ほか(20231024前編)
- 20231018後編 Kaigi on Rails 2023関連イベント情報公開、複合主キーのlocality解説記事ほか
- 20231017前編 Active Storageのしくみを詳しく解説するDiscussion投稿ほか
- 20231011 Rails 7.1.0リリース、YARPがprismにリネームほか
- 20131004 Rails 7.1.0.rc1と7.1.0.rc2がリリース、SQLite3コンフィグの最適化ほか
ソースの表記されていない項目は独自ルート(TwitterやはてブやRSSやruby-jp SlackやRedditなど)です。
Ruby Weekly
Ruby on Rails Discussions
The post 週刊Railsウォッチ: ShopifyのWebAssemblyツールチェインRuvyほか(20231025後編) first appeared on TechRacho.
週刊Railsウォッチについて
TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます(例:週刊Railsウォッチタグ)