Quantcast
Channel: hachi8833の記事一覧|TechRacho by BPS株式会社
Viewing all articles
Browse latest Browse all 1759

週刊Railsウォッチ: Rubyにdefp導入の提案、IRB 1.7.3リリースほか(20230727後編)

$
0
0

こんにちは、hachi8833です。

週刊Railsウォッチについて

  • 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
  • 「つっつきボイス」はRailsウォッチ公開前ドラフトを(鍋のように)社内有志でつっついたときの会話の再構成です👄
  • お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏

TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます(例:週刊Railsウォッチタグ)

🔗Rails

🔗 書籍『Layered Design for Ruby on Rails Applications』(8月末発売予定)


つっつきボイス:「TechRachoで多くの記事を翻訳させていただいたEvil MartiansのVladimir Dementyevさんから、この『Layered Design for Ruby on Rails Applications』を私に献本したいというメールをいただきました🙏😂」「お〜いい話🎉」「これまで私が翻訳した記事の内容の多くも書籍に盛り込まれているそうです」

「Layered Designとあるけどどんな内容なんだろう?」「リンク先にはこの書籍紹介↓ぐらいしか書かれていないけど、大規模なRailsアプリの設計が対象のようなので、業務寄りで実践的な内容っぽいかな」「目次が欲しいですね」「欲しいです」「まだ秘密なのかな?」

Ruby on Railsは、ゼロから完全な機能を備えた製品までのウェブアプリケーションを構築するためのオープンソースフレームワークです。Railsは生産性に焦点を当てており、設定より規約の力と明確に定義されたモデル/ビュー/コントローラパターンを活用しています。そのため、開発者は特徴の構築に時間を費やすことができ、コード自体と戦う必要がありません。しかし、この初期のシンプルさはしばしば制御不能な複雑さの成長につながり、整理されたコードベースも保守困難な状態に変わる可能性があります。本書では、Railsアプリケーションを管理可能な状態で保つ方法について説明します。まずはフレームワークの能力と原則を探求し、Railsパワーを最大限活用することができます。次に有用なパターンや抽象化レイヤーを導入することで多くの一般的な設計上の問題に取り組みます。その後はサービスの抽出など、Railsコードベースをスケーリングするためのさらなる手法について探求します。本書で述べられているアイデアは、拡張されたRails Wayと考えることができます。これらのパターンやアプローチは、フレームワークを楽しむために役立ち、Ruby開発者の幸福感を大きく高めるものです。本書を読み終える頃には、Railsフレームワーク原則に深い理解を持つコード設計の専門家になっているでしょう。
Layered Design for Ruby on Rails Applications | Packt書籍紹介より

「以下のGitHubリポジトリを見つけた↓」「これは書籍で使うサンプルコードみたいですね」

PacktPublishing/Layered-Design-for-Ruby-on-Rails-Applications - GitHub

🔗 TurboとStimulusとHotwireの違い(Ruby Weeklyより)


つっつきボイス:「HotwireとTurboとStimulusの違い、迷うといえば迷いますよね」「そのあたりを自分用に整理した記事っぽい」「Hotwireは総称で、その中にTurboやStimulusやStradaがあるという関係↓」「Turboの中にもTurbo DriveやTurbo Framesなどがありますね」


同記事より


Hotwireについては以下の記事もどうぞ↓

Railsの技: “プログレッシブエンハンスメント”でHotwire的思考を身につける(翻訳)

🔗 Rails風のビューをRubyで実装する(Ruby Weeklyより)


つっつきボイス:「Railsのビューテンプレートを手作りしたのかな?」「Railsでコントローラに書いたインスタンス変数がビューに伝搬するしくみがわからなくて調べているうちに、自分で同じようなものをRubyで実装した感じですね」

# 同記事より
# controllers/posts_controller.rb
class PostsController
  def show
    @post = Post.find(1)
  end
end
<!-- 同記事より -->
<!-- views/posts/show.html.erb -->
<%= @post.title %>

「言われてみれば、コントローラのインスタンス変数がビューに渡るしくみって特に考えずに使ってました」「今も同じかどうかわかりませんが、以前読み会で取り上げたなつかしの『Crafting Rails 4 Applications』ではまさにそのあたりのしくみを解説していましたね」「そういえばそうでした」「パラメータフィルタを手作りすれば、たとえば特定のインスタンス変数を渡さないようにできます(少なくとも当時のRailsでは)」「そういえば今はもうRails 7なのか、早いな〜」

【勉強会報告】Crafting Rails 4 Applications読み会をはじめました+第一回資料

🔗 Railsのcomposed_ofでValue Objectを構築する(Ruby Weeklyより)


つっつきボイス:「thoughtbotの記事です」「そういえばcomposed_ofメソッドってありましたね」「あまり使ったことはないけど、たしかにこういうふうに↓書くとValue Objectをロジカルなモデルとしてすっきり書けますね」

# 同記事より
 class Run < ApplicationRecord
+  composed_of :measurement,
+              class_name: "Unit",
+              mapping: [ %w(distance scalar), %w(unit units) ]
+
   validates :unit, inclusion: { in: %w(mi m km) }

   def convert_to(new_unit)

参考: Rails API composed_ofActiveRecord::Aggregations::ClassMethods

🔗 ERBの<%==に注意(Ruby Weeklyより)


つっつきボイス:「<%== %>っていう書き方知らなかったけど、これは中身をエスケープせずにそのまま出力するときの記法なのか」「SafeBufferを使わなくても<%== %>で素通しできちゃうんですね」「記事では基本的にこういうのを使わずにコントローラでサニタイズしてから使えとある: これはもう当然ですね」

<!-- 同記事より -->
<%== @some_text_to_render %>

「ところでRubyのERBドキュメントには<%== %>が見当たらないですね」「これは明らかにRails固有の機能なので、Active Support拡張のはず」


後で探すと、Active Supportにありました↓。

何らかの理由で、エスケープされていない文字列をそのままの形で挿入したい場合は、html_safeを呼ぶのではなく、rawヘルパーをお使いください。

<%= raw @cms.current_template %> <%# @cms.current_templateをそのまま挿入 %>

あるいは、rawと同等の<%==を使います。

<%== @cms.current_template %> <%# @cms.current_templateをそのまま挿入 %>

§5.1 安全な出力 — Active Support コア拡張機能 – Railsガイドより

🔗Ruby

🔗 IRB 1.7.3リリース


つっつきボイス:「IRBが活発にリリースされていますね」「IRBが強力になったおかげでRailsコンソールもいろいろリッチになったのがありがたい」

その後早くもIRB 1.7.4がリリースされていました↓。

参考: Release v1.7.4 · ruby/irb

Ruby 3.2のIRBに導入された新機能(翻訳)

🔗 Ruby 2->3アップグレードのArgumentErrorsを修正する(Ruby Weeklyより)


つっつきボイス:「2023年にRuby を2から3にアップグレードしようとして苦労した記事を見かけるとは」「例のキーワード引数の仕様がRuby 3で変わった件に対応したんですね」「記事ではRailsのstringify_keysメソッドで対応している」

参考: §11.4.2 stringify_keysstringify_keys!
— Active Support コア拡張機能 – Railsガイド

「ところでこの図、キーワード引数の変更点の説明としてとてもわかりやすい↓」「たしかに!」「こうやって引数が吸い込まれる場所が変わるんですね」


同記事より

Ruby 2.7: ハッシュからキーワード引数への自動変換が非推奨に(翻訳)

🔗 SorbetをRuby 3.2互換にする(Ruby Weeklyより)


つっつきボイス:「Stripeが開発してShopifyなどが使っている型チェッカーSorbetがRuby 3.2に対応したそうです」「***による引数forwardingなどいろいろ対応している」「ShopifyがRubyやツール周りを強力に支援しているのは本当に頼もしい👍」「この記事もShopifyですね」

# 同記事より
def foo(*)
  bar(*)
end

def baz(**)
  quux(**)
end

🔗 Rubyにdefpを導入するかどうかを議論中(Ruby Weeklyより)


つっつきボイス:「defp?」「defpを足したのか!」「オーバーロード可能でパターンマッチングが使えるメソッドをdefpで定義できるようにするというアイデアらしい」「まだ議論中のようなのでしばらく様子見ですね」

# https://bugs.ruby-lang.org/issues/19764 より
defp call(String => s unless s in /^[a-z]/)
  puts "string: #{s.inspect} (capitalized)"
end

defp call(String => s)
  puts "string: #{s.inspect}"
end

defp call(Hash(foo:, bar:) => h)
  puts "hash: #{h.inspect}"
end

defp call(**nil)
  puts "no keyword args"
end

call("Example") # => string: "Example" (capitalized)
call("test")    # => string: "test"
call(foo: 1, bar: 2) 
# => hash: { :foo => 1, :bar => 2 }

「もしやと思ったら、このdefpはzverokさんの以下の記事が元になっているそうです↓」

Rubyの型アノテーションの現状についていくつか思うこと(翻訳)

🔗クラウド/コンテナ/インフラ/Serverless

🔗 IstioがCNCFの卒業プロジェクトに(Publickeyより)


つっつきボイス:「Istioが卒業ですか」「CNCFはLinux Foundationが主催しているオープンソースのプロジェクト管理団体で、Istioもそこが支援しているツールのひとつですね: 今やIstioは普及して成熟してきたのでステータスが”卒業”になったらしい」「なるほど」「Istioは卒業したらCNCFから離れるのかと思ったら開発は引き続きCNCF傘下で行われるらし」「あのEnvoyもCNCFの卒業組に入っていますね」

参考: Cloud Native Computing Foundation
参考: Cloud Native Computing Foundation – Wikipedia
参考: Envoy Visitors, Workplace, and Connect | Envoy

CNCFのプロジェクトを見ると、gRPCのステータスがまだ育成中(Incubating)になってる」「gRPCの知名度を考えると意外ですね」

参考: gRPC – Wikipedia

🔗 LazyDocker: CLI向けDockerフロントエンド


つっつきボイス:「動画を見るのが早そうです↓」「なるほど、Docker向けのダッシュボードをtopとかhtop風のインターフェイスで作った感じかな」「Dockerコマンドをいちいち実行しなくても動かせるようになるんですね、使ってみようかな」

参考: htop – Wikipedia
参考: top (UNIX) – Wikipedia

jesseduffield/lazydocker - GitHub

🔗 GitHubのパスキーをやってみた話


つっつきボイス:「ぼくのツイートだ〜」「GitHubのパスキーを使ってみたそうですが、どんな感じでした?」「実は少し前から友だちと勉強会でパスキーのことを調べていて、自分のプロダクトでも一度実装してみました: 便利といえば便利ですけど、デバイスごとの秘密鍵をどう管理すればいいのかが目下の課題という感じです」「パスキーはまさにそういう仕組みなので、デバイスごとに鍵を管理するのは仕方ないですよね」「はい、まさに」

参考: パスキーを使用した認証 – GitHub Docs

「Appleのパスキーだと秘密鍵がiCloudに保存されるのでiCloudの範囲では共有できるんですけど、Chromeだと”秘密鍵はこのChromeにのみ保存されます”みたいなメッセージが出るので、別のChromeでは認証し直しになりました」 「私もそのメッセージ見かけました」「そもそもパスキーをiCloudで共有していいのかという問題もありますよね」「そうそう、そのあたりで悩んでます…」


後編は以上です。

バックナンバー(2023年度第3四半期)

週刊Railsウォッチ: config.autoload_libとconfig.autoload_lib_onceが追加ほか(20230725前編)

ソースの表記されていない項目は独自ルート(TwitterやはてブやRSSやruby-jp SlackやRedditなど)です。

Ruby Weekly

Publickey

publickey_banner_captured

The post 週刊Railsウォッチ: Rubyにdefp導入の提案、IRB 1.7.3リリースほか(20230727後編) first appeared on TechRacho.


Viewing all articles
Browse latest Browse all 1759

Trending Articles