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

週刊Railsウォッチ: Ruby Struct入門、書籍『進化的アーキテクチャ』、AWS Web問題集ほか(20211116後編)

こんにちは、hachi8833です。

週刊Railsウォッチについて

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

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

お知らせ

来週の週刊Railsウォッチは祝日のためお休みをいただきます。

🔗Ruby

🔗 Ruby 3.1-preview1とYJIT

YJITを手元で少し試してみました。

Ruby 3.1.0-preview1がリリースされました


つっつきボイス:「手元で3.1.0-preview1をインストールしてごく簡単にYJITを試してみた感じでは、特定の機能というより全般に速くなっている印象でした」「わーい、preview1ぼくも入れてみよう〜」「リリースノートをざっと見た限りでは、breaking changeという言葉は見当たらなかったので安心度は高いかなと思いました」「たしかにありませんでしたね」

「YJITはベンチマークでも強いと思いますが、アプリなどでも速くなるでしょうね」「optcarrot以外でも速くなるといいな〜」「optcarrotはRubyのベンチマークによく使われるファミコンエミュレータですね↓」

mame/optcarrot - GitHub

🔗 RubyでGo処理系を書く


つっつきボイス:「Evil Martiansの記事、とても面白かった」「Matzもリツイートしていましたね」「mattnさんがツイートで見事に記事を要約してくれていました」「Rubyはこういうこともできてしまうのがホント面白い」


「そういえばこの記事のアイキャッチ画像が何かに似ているって言ってませんでした?」「そうそう、ジュラシック・パークのオープニングにあった、琥珀の中に蚊が閉じ込められている映像みたいだなと思って」「懐かしい〜、GopherくんがRubyの中に封印されている感じですね」「その蚊が吸った恐竜の血液からDNAを取り出して恐竜を現代に再生するんでしたっけ」

参考: ジュラシック・パーク - Wikipedia

🔗 Ruby Struct入門(Ruby Weeklyより)


つっつきボイス:「記事ではrefinementsまで登場してる」「RubyのStructは、いわゆるPORO(Plain Old Ruby Object)ですね: OpenStructは登場してから多少変わってきたようですが、RubyのStructはそれほど変わっていないかな」「StructはMarshalのdumprestoreも問題なくできたはず」

参考: class Struct (Ruby 3.0.0 リファレンスマニュアル)

参考: module Marshal (Ruby 3.0.0 リファレンスマニュアル)

「RubyのStructは弊社にも好きな人がいて、よくStructでValue Objectを作ったりしてます: 自分はハッシュでValue Objectを作ることが多いですが」「ふむふむ」

「ただ、RubyのStructはループ内でインスタンスをたくさん生成したりすると遅くなる傾向があるんですよ」「そういえばJeremy Evansさんの『Polished Ruby Programming』↓にも、RubyのStructはメモリ消費が少なめだけどアクセサメソッドが遅いとありました」「そうそう、Structは大量に生成するにはまだあまり向いていないかなと思っていますが、Marchal.dumpされていたStructをMarshal.loadとかするならたぶん速い」

『Polished Ruby Programming』(Jeremy Evans著)を読みました

同書では「Structはもっと注目されてもよい」「イミュータブルなStructが欲しいという意見もあるがまだRubyには入っていない」という記述もありました。探してみると#16769immutable: trueが提案されていましたがrejectされていました。

🔗 chruby: Rubyのバージョンを変更するツール

postmodern/chruby - GitHub


つっつきボイス:「Ruby 3.1.0-preview1で以下のyjit-bench↓を動かそうと思って調べていたら、このchrubyに依存していたことで知りました」「チェンジルビーって読むんですか」「rbenvのオルタナのようですね」「サイズが小さい(100行以下)とはスゴい」

Shopify/yjit-bench - GitHub

「chrubyちょっと入れてみたんですが、既存のrbenvとどう折り合いをつけたものかよくわからなかったのでいったん外しました」「自分はもうDocker環境で作業するのが当たり前になってきているので、Rubyのバージョン切り替えのことは最近あまり気にしていませんね」「そういえば自分もそうだった」「考える時間がもったいないので、迷ったら即Dockerにしてます」

🔗 benchmark_driver

benchmark-driver/benchmark-driver - GitHub


つっつきボイス:「benchmark-driverはだいぶ前にウォッチで見た気がする」「当時ウォッチで取り上げたときは(ウォッチ20189330)日本語記事がなかったんですが、YJITのベンチマークを手元でやろうと思って調べていたらk0kubunさんがQiitaに書いていた記事をたまたま見つけました」

「こんなふうにRubyのバージョンを複数指定してベンチマークを実行できるのね↓」「これでYJITを試してみました」「便利そう」

# 同記事より: 複数のRubyバージョン
# require 'benchmark/driver'

Benchmark.driver do |x|
  x.rbenv '2.0.0', '2.4.2'
  x.prelude %{
    class Array
      alias_method :blank?, :empty?
    end
    array = []
  }
  x.report 'Array#empty?', %{ array.empty? }
  x.report 'Array#blank?', %{ array.blank? }
  x.compare!
end

「お、ベンチマーク設定をYAMLファイルを書ける↓」「CIでベンチマークを回すのによさそう👍」

# 同記事より: yamlコンフィグ
prelude: |
  class Array
    alias_method :blank?, :empty?
  end
  array = []
benchmark:
  Array#empty?: array.empty?
  Array#blank?: array.blank?

「なお以下はRuby Weeklyで紹介されていました」「Rubyのメモリプロファイリングができるベンチマークソフトですね」

michaelherold/benchmark-memory - GitHub

🔗 その他Ruby

つっつきボイス:「パッチを投げたいgemがあるのでRails/OSSパッチ会出席したいなと思っているんですが、なかなか機会がなくて」「従来はIdobataが使われていたんですが、半月ぐらい前にDiscordに移っていました」「Discordは使っている人多いですよね」


つっつきボイス:「メソッドのオーバーロード機能はC++などにありますね: 同じメソッド名でもパラメータの型や個数や順序が違うと別メソッドとして呼べるもので、そういう言語ではメソッド名とパラメータリストと型をまとめてメソッドシグネチャと呼んでたりします」「言語によっては戻り型も含まれますね」「そうそう、それも含めてメソッドの仕様になりますね」

参考: メソッドのシグネチャ(signature)とメソッドの構文(syntax)の違い - いっしきまさひこBLOG

「Rubyにオーバーロード機能はないので、既存のものと同じメソッド名を書くとオーバーライドされる仕様: その分メソッド名がかぶらないよう気にしないといけませんが」

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

🔗 AWS Lambdaによる進化的アーキテクチャの構築


つっつきボイス:「はてブでバズっていた記事です」「最近よく見かけるヘキサゴナルアーキテクチャにLambdaを絡めた設計の話ですね」「最近のAWSはこういう技術記事のようなメディア展開にも力を入れていますね」

参考: ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) | blog.tai2.net

「モノリスだとちょっとデータを取り出して調べたりというのは簡単なんですが、ヘキサゴナルアーキテクチャになると複数の業務を横断したデータをお互いに紐付けたまま取り出す(RDBのJOINなど)のが簡単にできなくなって、ベストプラクティスに従うと周辺サービスを購入してそれ経由でデータにアクセスすることになったりしがちなんですよ」「そうそう、ありがちです」「出費かさむんですね」「レイヤー化された設計はたしかにきれいなんですが、気がつくと追加費用が増えていたりしオーバーキルになったりしがち」

「もちろん大規模システムは最初からきちんと設計するべきですが、何をするにも大げさになりがちなので、モノリスの取り回しの良さが捨てがたいと思うときもあります」「それわかります」

「その一方で、モノリスは開発メンバーが異動したときの影響が大きいので、それを考えるとヘキサゴナルアーキテクチャのように設計を統一して担当範囲を絞っておくことも理にかなっていると思います」「たしかに」「メンバー異動のコストをヘキサゴナルアーキテクチャで先払いしていると思えばいいのかなという気もします」「う〜む考えさせられます」「ヘキサゴナルアーキテクチャは費用も大きいですし、簡単に結論を出せる話ではありませんね」

🔗 書籍『進化的アーキテクチャ』

「記事の中で『進化的アーキテクチャの構築』というリンクがあるのでクリックしてみたらBuilding Evolutionary Architecturesという本が出てきました」「オライリーでも日本語版出ていて自分も持ってます↓」

「目次を見た限りでは、クラウドサービスのカタログというよりも、コンピュータサイエンスの基礎のようにアーキテクチャをみっちり学ぶ本のようですね」「そうそう、コンピュータサイエンス基礎という感じで、最初はモノリスだったのがだんだん大きくなってサーバーレスになって…みたいなことが解説されてました」「一般性が高くてなかなかよさそうな本👍: 買ってみよう」

🔗 aws.koiwaclub.comのAWS Web問題集


つっつきボイス:「BPS社内SlackでAWS受験対策おすすめとして貼っていただいたURLです」「自分は2016年頃にこのサイトに登録してます: おすすめ👍」

「まず当時から問題数がとても豊富: AWS公式の問題集より問題数が多くて、しかもAWS公式みたいに過去問が見られなくなることもない」「お〜」「無料のサンプル問題集だけでもかなり量があります(問題がどのぐらい更新されているかはわかりませんが)」「自分もこれで勉強して受けてみようかな」

「試験ってどのぐらい難しいんでしょうか?」「AWSのソリューションアーキテクトは、普段AWSのダッシュボードを操作している程度だとそれなりに対策が必要だと思いますが、顧客向けの提案書を書くときにAWSのSLAやサービスの制限事項や拡張性に関するドキュメントを詳しく読む機会が多ければ、それほど苦労しなくても取れると思いますよ」「お〜、ちょっと頑張って取ってみようという気持ちになりました」「とりあえずフリープランの問題集を解いて感触を確かめておくといいと思います」

参考: AWS サービスレベルアグリーメント — SLA

🔗CSS/HTML/フロントエンド/テスト/デザイン

🔗 HTTPのQUERYメソッド


つっつきボイス:「はてブで見つけた記事です」「お、これ読みました: GETで付けられないボディをQUERYだと付けられるんでしたっけ」「GETはボディが付けられないのでたくさん渡そうとするとURLパラメータを使うことになりますが、URLの長さに制限があるのと、URLパラメータがサーバーログに残るのが嬉しくないんですよ」「お〜」「記事にもあるように、QUERYならURLエンコードも不要でURL長さ制限にもかからないとありますね: 使えると嬉しいかも👍」

🔗言語/ツール/OS/CPU

GitHub Copilotのベータ申し込みしていたのがいつの間にか有効になっていたので、VSCodeでJSとRubyのAI補完を初めて体験できました。GitHub Spacesも待ってます。

github/copilot-docs - GitHub

🔗 シェル考古学


つっつきボイス:「どちらもとても長い記事でしたが読み応えあったので貼ってみました」「考古学だけあってものすごい量ですね」「ここまで詳しく書いているとは」「著者紹介にShellSpecというのもあった↓」「シェルスクリプトの単体テストフレームワークなんですね: カバレッジまでできるとは」

shellspec/shellspec - GitHub

「正しいシェルスクリプトを自信を持って書ける人」「貴重な情報ありがたいです🙏」「シェル芸の元締めとして知られるこの方のことも思い出しました↓」

🔗 OpenID Connect

つっつきボイス:「OpenID Connect(OIDC)がサポートされたというのはどのあたりが嬉しい感じでしょうか?」「OIDCはサーバーにAPIキーとして置かなくていいことに加えて、トークンの更新がプロトコルレベルでサポートされているのが嬉しい点かなと思います」「お〜」

「一度発行されたAPIキーを期限切れさせるにはAPIを発行したサーバー側が対応すればできますが、APIキーを使う側が自分自身のAPIキーを更新する仕組みは一般的にはないんですよ」「ふむふむ」「なのでAPIキーが漏洩したら大変」

「OIDCなら仕様の中にAPIキーの更新処理も含まれていてプログラムで更新できるので、その部分についての安心度は高いでしょうね」「なるほど」


後編は以上です。

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

週刊Railsウォッチ: Rails 7がRuby 3.1のClass#descendantsに対応、GitHub Issue風ファイルアップローダほか(20211115前編)

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

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

Ruby Weekly

Publickey

publickey_banner_captured


CONTACT

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