Tech Racho エンジニアの「?」を「!」に。
  • Ruby / Rails関連

週刊Railsウォッチ(20210303後編)Bundlerのセキュリティ修正、Rubyのガベージコレクション記事、Rubyが2/24に誕生日ほか

こんにちは、hachi8833です。

週刊Railsウォッチについて

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

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

訂正(2021-03-04)

本記事タイトルの「Ruby24歳に」および本文に誤りがある旨ご指摘をいただき、本記事タイトルおよび本文を訂正いたしました。
関係者の皆様にご迷惑をおかけしたことをお詫び申し上げます(hachi8833)🙇。

🔗Ruby

🔗 Bundlerのセキュリティ修正(Ruby Weeklyより)


つっつきボイス:「Bundlerサイトのブログです」「Bundlerをよりセキュアに、ですか」

「なるほど、複数のgemサーバーを使っている状況でgemの名前がコンフリクトする場合に、以下のようにどのサーバーから取ってくるかを明示的に指定できるようになったんですね」「おぉ?」「たとえばmy-private-gemがrubygems.orgにもmy-private-serverにも置かれている場合、従来だとどちらからフェッチするかを指定できなかったのが、以下のようにsourceブロックで明示的に囲んで取得元を指定できるようになった」「あ、そういうことですか」

# Gemfile

source "https://rubygems.org"

source "https://my-private-server" do
  gem "my-private-gem"
end

「記事で引用されている"dependency confusion"↓という問題が従来のBundlerにもあったんですね」

参考: Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies | by Alex Birsan | Feb, 2021 | Medium

「上のdependency confusion記事は他の言語の話ですが、この図↓のnpm dependenciesの記述みたいに、自分が直接取得元を指定していない間接的なdependency confusionについては、たしかに従来のBundlerのgem依存関係でも起きる可能性がありますね: Bundlerがこういう問題に対処可能になったのはいいことだと思います👍」


Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companiesより


「お、同じ記事のこの図が、この問題を使った攻撃の手口を端的に表してますね: 複数リポジトリを使う場合、同じ名前でバージョン番号が大きいライブラリをリポジトリに置かれてしまうとそちらを参照してしまうことがあります」

🔗 必要がない限りインスタンス変数をattr_readerで公開するのは止めよう


つっつきボイス:「記事冒頭のコード例↓の2つ目でattr_reader: nameを書いている理由は、末尾の"#{name.upcase}!!!"name@を付けたくないからということらしい」「リファクタリングがしやすくなるからとかタイポに強くなるからとか理由が書かれていますね」

# 同記事より: 元のバージョン
class User
  def initialize(name)
    @name = name
  end

  def loud_name
    "#{@name.upcase}!!!"
  end
end
# 同記事より: attr_readerバージョン
class User
  attr_reader :name

  def initialize(name)
    @name = name
  end

  def loud_name
    "#{name.upcase}!!!"
  end
end

「でもそのためにattr_reader@nameを不必要にpublicにしてしまうのはよくない、やるならせめて以下のようなprivateなattr_readerにしましょうと: たしかに」「言われてみればそうですね」「著者としてはそれもあまり好きでないようですね」

# 同記事より: private化バージョン
class User
  def initialize(name)
    @name = name
  end

  def loud_name
    "#{name.upcase}!!!"
  end

  private

  attr_reader :name
end

「ところで、name@を付けたくない理由が他にあるとすれば、@nameだと変更できてしまうからでしょうね」「あ、たしかに」「attr_readerにすれば=で代入できなくなるので、その部分の安全度は上がります」「うっかり=で代入しても大丈夫になりますね」「あまり意識的に使ったことはありませんが、こんなふうにattr_readerをprivateにするテクニックは以前どこかで見たことがある気がします」


後で探すと、attr_readerを用いてインスタンス変数を隠蔽する方法はSandi Metz『オブジェクト指向設計実践ガイド(“Practical Object-Oriented Design in Ruby”)』に書かれていると以下の記事で知りました。私が持っている同書日本語PDF版(初版第1刷)で確認するとp46〜47にありました。以下の記事には、attr_readerprivateにする方法についても紹介されています。

参考: Rubyのインスタンス変数の直接参照について - 雑草SEの備忘録

🔗 Rubyのガベージコレクションを深掘りする(Ruby Weeklyより)


つっつきボイス:「Rubyのガベージコレクション解説記事です」「Rubyで使われているというtri-color mark and sweepってどこかで聞いたかも」


同記事より

後で探すとWikipediaにTri-color markingの項がありました↓。

参考: Tri-color marking -- Tracing garbage collection - Wikipedia

「Rubyのガベージコレクション周りについてはRubyKaigiでよく発表されているので、そのあたりを探してみるといいかも」「そういえばAaron PattersonさんやNate BerkopecなどもRubyのガベージコレクション記事執筆や発表をよく行っていますね↓」

Rubyのヒープをビジュアル表示する(翻訳)

Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由(翻訳)

🔗 その他Ruby

つっつきボイス:「Rubyの誕生日って1993年の2/24なのか」「2/24って昨日じゃないですか(注: つっつき時点)」「Rubyという名前が付けられた日が誕生日なんですね」「Ruby作者自らが発信した情報で知ることができるのはいいですね」

「そういえば昨年JavaScriptも25歳になったらしいですね↓」「Rubyが1歳、いや2歳若い!」(訂正: 「Rubyは2/24で28歳」です。訂正し、お詫び申し上げます)

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

🔗 AWS CodeDeploy


つっつきボイス:「今日Webチーム内発表のお題になっていたことでCodeDeployを知りました」「AWSのCodeDeployって見たことなかったんですけど使われているんですか?」「お、普通に使われていますよ」

「AWS CodeDeployのいいところは、ALB配下で複数台冗長化している際にシステム全体を正常にゼロダウンタイムでデプロイするための機能が統合されている点ですね: ALBに設定されたリクエストタイムアウト値に合わせた待ち時間でインスタンス切り離しを行い、healthcheckに合わせた設定でサービスインするという、当たり前だけどロールバックなどを考慮すると地味にめんどくさい機能がAWSサービスとしてまるっと統合されている良さがあります」「そういうのを自動でやってくれるんですか」「そういう機能がビルトインされています: たぶんですけどAuto ScalingでオートスケールするものならCodeDeployを使うのが便利だと思いますよ」「へ〜」

参考: CodeDeploy と Elastic Load Balancing の統合 - AWS CodeDeploy
参考: Integrating CodeDeploy with Amazon EC2 Auto Scaling - AWS CodeDeploy

「デプロイではインスタンスをALBからいきなり切り離したらダメなんですよ: まずリクエストの流入を止める、次に処理中のリクエストがあるかもしれないのでタイムアウトまで待つ、そしてトラフィックが完全に来なくなったことを確認してからインスタンスを切り離してデプロイして、終わったらつなぎ直す、もし途中で失敗したらロールバックする」「ふむふむ」「そうした一連の処理をCodeDeployはひととおりやってくれるんですよ」「そこまでやってくれるんですね」「今度やってみようかな」


「ちなみにBPSの自分のWebチームでは、AWSに全部まとめたいときなどにAWS CodeDeployが結構使われています」「お〜、そうでしたか」「数で言うとたぶんGitHub ActionsよりAWS CodeDeployの方が多いかも」「そんなに!」

GitLab自社運用のための注意点とノウハウ(2018/06版)

「自分はCIをGitHub Actionsに乗せようかなと思っているところなんですよ」「GitHubでやっているならGitHub Actionsがいいでしょうね: BPSの場合はGitLabを使っているのでプロジェクトによってはGitLab CIを使うことがよくあります」

参考: GitLabの継続的インテグレーションと継続的デリバリー | GitLab.JP


後編は以上です。

バックナンバー(2021年度第1四半期)

週刊Railsウォッチ(20210301前編)Rails 6.1.3がリリース、Active Supportのbefore?とafter?、link_to_unless_currentほか

今週の主なニュースソース

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

Ruby Weekly

DB Weekly

db_weekly_banner


CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。