こんにちは、hachi8833です。
訂正(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記事は他の言語の話ですが、この図↓の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_readerをprivateにする方法についても紹介されています。
参考: 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
— Mohsen Mostafa Jokar (@Mohsen_jokar) February 24, 2021
つっつきボイス:「Rubyの誕生日って1993年の2/24なのか」「2/24って昨日じゃないですか（注: つっつき時点）」「Rubyという名前が付けられた日が誕生日なんですね」「Ruby作者自らが発信した情報で知ることができるのはいいですね」
「そういえば昨年JavaScriptも25歳になったらしいですね↓」「Rubyが1歳、いや2歳若い！」（訂正: 「Rubyは2/24で28歳」です。訂正し、お詫び申し上げます）
25 years ago this month the first prototype of JavaScript was created over ten days. Most likely May 6-15, 1995.
Read about how it happened in “JavaScript: The First 20 Years” https://t.co/aCMFx28GX0@BrendanEich
— Allen Wirfs-Brock (@awbjs) May 14, 2020
🔗クラウド/コンテナ/インフラ/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の方が多いかも」「そんなに！」
「自分は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ほか
- 20210222 ActiveRecord::Relationの新メソッドload_asyncとexcluding、Active Jobのperform_laterの改善ほか
- 20210209後編 Rubyでミニ言語処理系を作る、Kernel#getsの意外な機能、CSSのcontent-visibilityほか
- 20210208前編 Rails次期リリースがバージョン7に決定、thoughtbotのアプリケーションセキュリティガイドほか](/hachi8833/2021_02_08/103801)
- 20210202後編 Ruby 3 irbのmeasureコマンド、テストを関数型言語のマインドセットで考えるほか
- 20210201前編 Webpackerのガイドがマージ、RailsはRuby 3でどのぐらい速くなったかほか
- 20210126後編 Google Cloud FunctionsがRubyをサポート、Ruby 3のパターンマッチングでポーカーゲームほか
- 20210125前編 Railsリポジトリのデフォルトブランチがmainに変更、Rails 6.1はMySQLのENUM型に対応済みほか
- 20210120後編 Ruby 3.0の新機能で遊ぶ、RubyスニペットをJSに変換するRuby2JS、rspec-parameterized gemほか
- 20210113後編 Ruby 3.0 Ractor解説記事、Vercelホスティングサービス、教育用OS xv6ほか
- 20210112前編 Active Recordの範囲指定バリデーション改善、soleとfind_sole_byメソッド、AlgoliaとRailsほか
今週の主なニュースソース
ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSやruby-jp SlackやRedditなど）です。
週刊Railsウォッチについて
TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ）