Tech Racho エンジニアの「？」を「！」に。
  1. TOP
  2. Ruby / Rails関連
  3. 週刊Railsウォッチ: byebugからruby/debugへの移行ガイド、YJIT解説記事ほか（20220823後編）
  • Ruby / Rails関連

週刊Railsウォッチ: byebugからruby/debugへの移行ガイド、YJIT解説記事ほか（20220823後編）

こんにちは、hachi8833です。

週刊Railsウォッチについて

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

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

🔗Ruby

🔗 procとlambdaの違い（Ruby Weeklyより）

つっつきボイス:「procとlambdaの違いは年に1度は話題になるやつですね」「そうそう、returnとbreakの挙動が違うけど、どっちがどっちだったかわからなくなりがち」

参考: class Proc (Ruby 3.1 リファレンスマニュアル)
参考: Kernel.#lambda (Ruby 3.1 リファレンスマニュアル)

lambda と proc と Proc.new とイテレータの違い
Kernel.#lambda と Proc.new はどちらも Proc クラスのインスタンス(手続きオブジェクト)を生成しますが、生成された手続きオブジェクトはいくつかの場面で挙動が異なります。 lambda の生成する手続きオブジェクトのほうがよりメソッドに近い働きをするように設計されています。

Kernel.#proc は Proc.new と同じになります。引数に & を付けることで手続きオブジェクト化したブロックは、Proc.new で生成されたそれと同じように振る舞います。
Kernel.#lambda (Ruby 3.1 リファレンスマニュアル)より

ジャンプ構文の挙動の違い
return と break は、lambda と Proc.new では挙動が異なります。例えば return を行った場合、lambda では手続きオブジェクト自身を抜けますが、 Proc.new では手続きオブジェクトを囲むメソッドを抜けます。
class Proc (Ruby 3.1 リファレンスマニュアル)より

🔗 byebugからruby/debugへの移行ガイド（Ruby Weeklyより）

つっつきボイス:「ruby/debugにコントリビュートしているst0012さんの記事で、近々翻訳記事を出す予定です」「既に最新のRailsではbyebugが削除されているので、ruby/debugに乗り換えておくべきでしょうね」「もうbyebug使ってません」「自分にとってruby/debugのいいところは、ドキュメントを見なくてもフィーリングで使えることだと思っています」

ruby/debug - GitHub

🔗 今後のRuby高速化の展望（Ruby Weeklyより）

つっつきボイス:「SpiderMonkeyというプロジェクト↓をやっている人が書いたRubyの今後の高速化に関する記事だそうです」「インラインキャッシュは言語の高速化に有効、なるほど」「例のシェイプの話もあった↓」「Rubyは今後も速くなるだろうという結論で締めていますね」

参考: Home | SpiderMonkey JavaScript/WebAssembly Engine

Rubyオブジェクトの未来をつくる「シェイプ」とは（翻訳）

🔗 uart: シリアル通信gem

# 同リポジトリより
require 'uart'
require 'io/wait'

class Sample < Struct.new(:time,
                          :pm1_0_standard, :pm2_5_standard, :pm10_standard,
                          :pm1_0_env,      :pm2_5_env,
                          :concentration_unit,
                          :particle_03um,   :particle_05um,   :particle_10um,
                          :particle_25um,   :particle_50um,   :particle_100um)
end

uart = UART.open ARGV[0], 9600, '8N1'

p Sample.members # header

loop do
  uart.wait_readable
  start1, start2 = uart.read(2).bytes

  # According to the data sheet, packets always start with 0x42 and 0x4d
  unless start1 == 0x42 && start2 == 0x4d
    # skip a sample
    uart.read
    next
  end

  length = uart.read(2).unpack('n').first
  data = uart.read(length)
  crc  = 0x42 + 0x4d + 28 + data.bytes.first(26).inject(:+)
  data = data.unpack('n14')

  next unless crc == data.last # crc failure

  p Sample.new(Time.now.utc, *data.first(12)).to_a
end

つっつきボイス:「UARTとは懐かしい」「UARTはシリアル通信に関連しているやつですね」「tenderloveさんがこんなものを書いていたとは」「tenderloveさんは毎日使っているとツイートに書いてますね」「自分も一時期はよくUART触ってましたし、使う人は使うと思いますよ」

参考: UART - Wikipedia

「UARTをRubyで制御できるということですか？」「Linuxの/devの下にもシリアル通信がそのまま現れるので、このgemを使わなくても基本的にはそこにアクセスすればできますね（ボーレート制御のような細かいことは別途必要かもしれませんが）」「あ、なるほど」「Linuxの/devファイルシステムとドライバは、開くだけで取りあえず使えるところがよくできているなと改めて思いますね」「そうそう」

参考: linuxのデバイスファイル(/dev)一覧

🔗 YJITのLazy Basic Block Versioning

つっつきボイス:「YJITがやっていることの一部を解説した記事ですね」「詳しい解説ありがたい👍」

Lazy Basic Block Versioning（LBBV）は以下の記事でもBBVとして触れられています↓

YJIT: CRuby向けの新しいJITコンパイラを構築する（翻訳）

「RubyがYJITで速くなる理由にはいろんな要素が絡んできそう」「実行時に毎回型推論するとパフォーマンスが落ちる」「"現実のコードではほとんどの場合一つの変数はそのライフタイムにおいて同一の型を持ち続けることが多い"、たしかに普通に正しくRubyのコードを書いていれば、同じ変数の型がころころ変わることはほとんどないでしょうね」「ポリモーフィックなコードを書いたとしても、宣言した変数はローカルブロックの中で再代入せずに使い切る方が多そうですよね」

「"型検査の分岐は90％以上で片方の分岐しかたどらなかった"とあるけど、残りの10%のほとんどは"nilまたは何かの型"みたいなものじゃないかと予想しちゃいますね」「それありそう」

「元記事にあったLBBVの元論文↓」

参考: Simple and Effective Type Check Removal through Lazy Basic Block Versioning（1411.0352v2.pdf） Maxime Chevalier-Boisvert and Marc Feeley

「以下はShopifyのNoah Gibbsさんが書いた別のJIT記事です」

「JITコンパイラを備えたスクリプト言語はコンパイラ言語と同じぐらいに速いと冒頭で述べられているのは、もうだいぶ前からそうなっていますよね」「大昔だと、スクリプト言語はコンパイラ言語より遅いとされていた時代もありましたね」「今ならケースによってはJITの方が速いこともある」「JavaのVMも大昔は遅い遅いと言われていたけど、今やめちゃくちゃ速くなっていますね」

参考: 実行時コンパイラ - Wikipedia

「自分たちが昔コンピュータサイエンスの授業などで学んできたそういう常識が覆されることってときどきありますよね」「最近だとどのあたりが変わっているんだろう？」「授業でそういう歴史的な変遷も含めて教えてくれているといいんですけどね」「最新の常識だけ教わるよりその方が理解しやすいかも」

🔗 その他Ruby

つっつきボイス:「Ruby Prizeのノミネート募集の季節ですね」「募集締切は9/11（日）か」「そういえばRubyKaigi 2022のチケットまだ買ってなかった...」

🔗 設計・セキュリティ

🔗 SSVC

つっつきボイス:「SSVCは、従来のCVSSのような脆弱性そのものの評価ではなく脆弱性対応方針の判断手法なのか」

参考: SSVC（Stakeholder-Specific Vulnerability Categorization）を活用した脆弱性管理 | PwC Japanグループ
参考: 共通脆弱性評価システムCVSS概説：IPA 独立行政法人 情報処理推進機構

「"CVSSの基準値とAVを見て、大体のアツさ（=精読するかどうか）を判断する"、あるある」「特定の脆弱性がどのぐらい危険なのかは利用のされ方次第で大きく変わるので、CVSSの評価基準を全面的に信用できるわけではないのもわかる」

「それに対してSSVCは利用のされ方や悪用時のインパクトなどを元に判断基準を示すのか: 誰にでも有効な脆弱性スコアは示しようがないので、記事にもあるようにSSVCに脆弱性情報や利用方法などを引数的に渡すことで対応方法を示すんですね」「これは面白い」


SSVCを参考にした脆弱性管理について本気出して考えてみている（進行中） - ペネトレーションしのべくんより

「こういうdecision tableの生成ルールをユーザーが構築するのは大変そう↑」「以下のツイートではこの図を生成するツールを作ったそうです↓」「なるほど」

「読んでいて思ったんですが、SSVCのdecision tableを生成する決定木のルールを人間が適切に選択できるかどうかはまた別の話ですね」「ルールを選択するときにリスクを低く見せたり逆に高く見せたりといった恣意的な操作は、たしかにやろうと思えばやれてしまいそう」「評価の元になるdecision ruleの決定木を適切に評価できる人が組織内にいるかどうかが重要になってきますね」

🔗 XSSの脅威の比較

つっつきボイス:「よく参照されている以下のLocal Storage記事に関連しているので取り上げてみました」「リンク先の記事にもあるように、いったんWebサーバーへのXSS攻撃を許してしまったらどの方式で保存していても危険であることに大きな違いはないと思いますね」「なるほど」「インメモリだと容量が大きい分データ抜き取りに手間がかかるとかはあるかもしれませんが、それでも程度差止まりでしょうね」

HTML5のLocal Storageを使ってはいけない（翻訳）

🔗JavaScript

🔗 JavaScriptの自動セミコロン挿入

JavaScriptの生みの親「自動セミコロン挿入やめときゃよかった……」 - Qiita

つっつきボイス:「JavaScriptの自動セミコロン挿入はいろいろ厄介ですね」「Bootstrapのコードで自動セミコロン挿入を当てにした書き方が揉めていたというのをこの記事で初めて知りました」

参考: 本の虫: JavaScriptの自動セミコロン挿入

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

🔗 HTTPieとTalend API Tester

つっつきボイス:「HTTPie？」「Web APIにアクセスするGUIツールのようですね」「アプリ版の他にWeb版やcurl風のCLI版もあるようです」

「この種のツールはいろいろありますけど、自分は以下のTalend API Testerを使ってます↓」「あ、こんなのもあるんですね」「こちらは単体アプリではなくChrome拡張なので、Chromeのセッションをそのまま引き継いで使えたりするのが便利👍」

参考: Talend API Tester - Free Edition - Chrome ウェブストア
参考: Talend Cloud API Testerの概要 • Talend Cloud API Testerユーザーガイド • Reader • Welcome to Talend Help Center

後編は以上です。

バックナンバー（2022年度第3四半期）

週刊Railsウォッチ: ビューテンプレートに渡せるローカル変数をマジックコメントでチェック可能にほか（20220822前編）

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

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

Ruby Weekly


タグ
この記事を書いた人

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版のコンテンツ監修、Railsガイドのコンテンツ作成を担当。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.comに移転。Amazonウィッシュリスト: https://bit.ly/32aAmiI

hachi8833の書いた記事一覧へ

本記事の内容へのお問い合せはTwitterで@techrachoへMentionまたはDMにてご連絡頂くか、運営会社であるBPS株式会社のお問い合せフォームよりお問い合せ下さい。

CONTACT

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