週刊Railsウォッチ: ヒアドキュメント拡張の提案、『組織に自動テストを根付かせる戦略』ほか（20221004後編）

こんにちは、hachi8833です。

🔗Ruby

🔗 提案: ヒアドキュメントの拡張（Ruby Weeklyより）

• issue: Feature #19015: Language extension by a heredoc - Ruby master - Ruby Issue Tracking System -- 現在オープン

---

つっつきボイス:「なるほど、事前に言語パーサーのハンドラを用意しておいて、<<!言語みたいな形でヒアドキュメントの言語を指定すると、パーサーで処理した結果をヒアドキュメントとして渡せるようにするという提案なのか↓」「シェルのshebangに近い書式なんですね」

# #19015より
require 'erb'

def heredoc_extension_erb str, b
  ERB.new(str).run(b)
end

name = 'ko1'

html = <<!erb
<div>Hello <%= name %></div>
erb

puts html #=> <div>Hello ko1</div>

参考: シバン (Unix) - Wikipedia

「まだ議論中だけどこの構文は面白いですね」「暗黙のパース処理が入るとコードベースが大きくなったときの副作用がちょっと心配かも: 自分は明示的にハンドラやパーサーを呼び出す処理が好みなのであまり使わないかな」「エディタのシンタックスハイライトがますます大変になりそうですね」「JetBrainsならコードのヒアドキュメントでハイライトする言語を指定できますよ: 自分は生SQLなどで使っています」

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

🔗 synvert: Rubyコードを書き換えるツール（Ruby Weeklyより）

---

つっつきボイス:「synvertってsyntaxとconvertの合成語っぽい」「以下のgemに依存しているんですね↓」「どういうときに使いたいのかな？」

「こういうDSLでRubyコードを書き換えられるんですね↓: ここではfactory_girlをfactory_botに置き換えている」「rubocop -aやエディタの正規表現置換よりも踏み込んだ書き換えができるんですね」

# xinminlabs/synvert-core-rubyより
Synvert::Rewriter.new 'factory_bot', 'convert_factory_girl_to_factory_bot' do
  description <<~EOS
    It converts FactoryGirl to FactoryBot

    ```ruby
    require 'factory_girl'
    require 'factory_girl_rails'
    ```

    =>

    ```ruby
    require 'factory_bot'
    require 'factory_bot_rails'
    ```

    ```ruby
    FactoryGirl.create(:user)
    FactoryGirl.build(:user)
    ```

    =>

    ```ruby
    FactoryBot.create(:user)
    FactoryBot.build(:user)
    ```
  EOS

  within_files Synvert::RAILS_TEST_FILES do
    find_node '.const[name=FactoryGirl]' do
      replace_with 'FactoryBot'
    end

    find_node ".send[receiver=nil][message=require][arguments.size=1][arguments.first='factory_girl']" do
      replace :arguments, with: "'factory_bot'"
    end

    with_node type: 'send', receiver: nil, message: 'require', arguments: { size: 1, first: "'factory_girl_rails'" } do
      replace :arguments, with: "'factory_bot_rails'"
    end
  end
end

「find_nodeでAST解析しているので、Rubyの構文に沿った置き換えができそう」「たしかに、正規表現で単純に置換すると構文を壊す可能性がありますね」「スニペットもいろいろ用意されているので、よく使うものをそこから選べるのか」

「byebugの消し忘れを消すとか、Rubyのbreaking changesや非推奨警告に対応するときなんかに使えそう」「理解して使う必要はあるけど、テストモードもあるのでとりあえず入れて動かしてみてもよさそう👍」

🔗 macOS VenturaでのRubyバグ修正

次期macOS VenturaでRubyのテストが失敗していたのをようやく直せました。
変更内容は単純だけど、多分今年１番調査がたいへんだったコミット。https://t.co/u0910cBylU

— kateinoigakukun (@kateinoigakukun) September 26, 2022

• PR: Initialize Objective-C classes before fork() for macOS 13 by kateinoigakukun · Pull Request #6426 · ruby/ruby

---

つっつきボイス:「RubyKaigi 2022のオープニングキーノートスピーカーを務めた@kateinoigakukunさんによるRubyコア修正です」「macOSの深い部分の変更によるバグか、これは調査大変そう」「Ruby以外の言語は大丈夫かしら」「CFはCore Foundationの略なんですね」

参考: Ruby meets WebAssembly - RubyKaigi 2022
参考: CFString | Apple Developer Documentation

🔗 その他Ruby

Posted to Hatena Blog #はてなブログ
フルタイムOSSコミッタを始めて2か月経った - k0kubun's blog https://t.co/AsnxcIBKt9

— k0kubun (@k0kubun) September 28, 2022

つっつきボイス:「"カンファレンス登壇が主要な業務の一つ"、すごい」

---

とりあえず作りました https://t.co/cTVM8hX5H1

— yancya (@yancya) September 29, 2022

「こちらは11月のRubWorld Conference 2022に合わせた車内ミートアップだそうです」「サンライズ出雲ですか」「寝台特急か、いいな〜」（しばらく旅談義）

参考: サンライズ瀬戸・出雲：JRおでかけネット

【RubyWorld Conference 2022 開催】
今年もe-GridがGOLDスポンサーを務める #RubyWorld Conferenceが開催されます！
場所はRubyの聖地、島根県⛩️
今後も #Ruby が広く使用できる言語として、普及していく活動を応援します。
詳細はこちら👉https://t.co/EJx6hAAJAu👈#松江#くにびきメッセ pic.twitter.com/FjIYwXhb5C

— 株式会社e-Grid (@eGrid_official) September 12, 2022

🔗 設計

🔗 「組織に自動テストを根付かせる戦略」1〜4（Publickeyより）

• 元記事: 答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 － Publickey
  • 元記事: 開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022 － Publickey
  • 元記事: フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 － Publickey
  • 元記事: 自動テスト文化を根付かせる王道と、邪道を教えよう。和田卓人氏による「組織に自動テストを根付かせる戦略」（その4）。ソフトウェア品質シンポジウム2022 － Publickey

---

つっつきボイス:「お、@t_wadaさんの講演か」「最初は1を貼ったんですが、2〜4もあることに気づいて追加しました」「このボリュームを文字起こししたのすごい」

「その1でPMBOK↓が第7版で大きく変わった話にも触れられていますね」「PMBOKは前も話題にしたことあったかも」「講演で触れられている継続的デリバリーも今や定着しましたね」

参考: PMBOK - Wikipedia
参考: 継続的デリバリー - Wikipedia

「その2で生産性の高い組織とそうでない組織の差を数値化しているのも面白い」「生産性の高いエリート企業のリードタイムが日単位から時間単位になったことでローパフォーマー企業との差がますます広がっている、なるほど」「テスト容易性とデプロイ独立性は大事」「今思えば自分たちもテストコードを書いていなかった時期はありましたけど、テストコードを書くようになってから明らかにデリバリーが迅速かつ楽になりましたね」

参考: テスト容易性 - ProgrammersHandbook

「"ソフトウェアを外注している企業はローパフォーマーになりやすい"、これもわかる」「その3でも、買ってきた自動テストは腐りやすいといったことが述べられていますね」「外注して作ってもらったものは、そのときは動いてもその後メンテが滞りがち: さっきのPMBOKの話の中にもありましたけど、"作ったら終わり"の時代は終わったということですね」「たしかに」「テストコードもテストを駆動する環境も、継続的なメンテナンスが必要です」

「その3のフレイキー（不安定）なテストの悩みも常にありますね」「"Googleにおいては、フレイキーさが1％に接近するとテストは信頼性を喪失し始めると言われる"、これもわかる」「なかなかゼロにできないヤツですね」「プロジェクトのテストがフレイキーだと認識されてしまうと、CIで落ちたときにもう1回やってみないと本当の失敗かどうかわからないような状態になって、それだけでデプロイ速度が相当落ちますよね」

参考: Flaky Testとの戦い - Cybozu Inside Out | サイボウズエンジニアのブログ

「フレイキーなテストってフロントエンド側で多いんでしょうか？」「バックエンドでも多いですよ」「なるほど」「テストを並列実行したりすると起きやすい傾向があったり、他にも実行環境のリソースが不足したりして不安定になることもありますし、外部依存のテストも不安定になりやすい」「外部依存を安定させるのは難しそう...」「それでも問題発見のためにテストは必要ですね」

「その4の"テストを書かないから時間がなくなる"も昔から有名な言葉で、長期的にはほんとその通り」「"何もしていないから動かなくなる時代"、わかる」

---

「今の時代はこういったトピックが昔に比べて随分知られるようになってきましたし、特にCPUやメモリやネットワークやストレージなどのリソースがとても潤沢になってきたことで、昔よりもずっと実践しやすくなりましたよね」「昔だとコンテナでのビルドやデプロイとかも計算リソース的に無理なことが多かったですよね」「大きなプロダクトだとビルド専門のエンジニアまでいましたね」「今ならテストをやらないという選択肢はほぼないでしょうね」「興味深いトピックが多いので後でちゃんと読んでみよう👍」

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

🔗 Amazon Linux 2のサポート期限

• 元記事: 【お知らせ】Amazon Linux 2のサポート期限が延長されました | SunnyCloud

---

つっつきボイス:「BPS社内Slackで話題になっていましたね」「上は今年7月の記事ですけどね: 現在のAmazon Linux 2のサポート終了日が2024年6月30日に延長されて、Amazon Linux 2022が今年後半にリリースされる」「Office製品みたいなネーミングになるんですね」

🔗 『Linuxのしくみ』が増補改訂

• 元記事: 「［試して理解］Linuxのしくみ ～実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】」が発売されます - 覚書

---

つっつきボイス:「Linuxのしくみはマジでいい本👍: 増補改訂版ではC言語のサンプルコードがGoとPythonに置き換えられたんですね」「自分も途中までサンプルコードを動かしてみたけどCは面倒だったので嬉しい」「10/17に販売予定か」「Kindleで予約入れました」

「お、今度は10〜12章に仮想化機能/コンテナ/cgroupも追加されていますね」「このあたりもカバーするとなるとボリュームが増えそう」「コンテナを学ぶうえでも1〜9章のOSの基礎が大事」

「cgroupはたぶんcgroup2の話が中心になるんじゃないかな↓」「cgroupはcontrol groupの略なんですね」「cgroupはコンテナよりも前からカーネルにあるリソース制御機能で、セキュリティにも関連します」「なるほど、後からコンテナで使われるようになったんですね」

参考: 第38回　Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2 ［2］ | gihyo.jp

🔗言語/ツール/OS/CPU

🔗 W3Techs.com

• サイト: W3Techs - extensive and reliable web technology surveys

Shopify is now the second most popular content management systemhttps://t.co/NVtPDUYk03@Shopify #Shopify pic.twitter.com/p1DDF3N5qr

— W3Techs (@W3Techs) May 25, 2020

---

つっつきボイス:「W3TechsはWebサイトを定期的にクロール調査した結果を掲載しているサービスで、これまでウォッチで取り上げてきた記事でもよく情報源として引用されていたので取り上げてみました」

トップページには以下の項目があります。

• CMS
• サーバーサイドプログラミング言語
• クライアントサイドプログラミング言語
• JavaScriptライブラリ
• CSSフレームワーク
• Webサーバー
• OS
• Webホスティングプロバイダ
• データセンタープロバイダ
• リバースプロキシサーバー
• DNSサーバープロバイダ
• メールサーバープロバイダ
• SSL証明書認証局
• JavaScript CDN
• トラフィック解析ツール
• 広告ネットワーク
• タグマネージャ
• ソーシャルウィジェット
• サイト要素
• 構造化データフォーマット
• マークアップ言語
• 文字エンコード
• 画像ファイルフォーマット
• トップレベルドメイン
• サーバーの場所
• コンテンツの言語

「CMSでWordPressがトップなのは前からですけど、ShopifyがUsageで2位につけているのがちょっと驚き: これまでいろんなCMSがあったはずだけど多くがこのあたりに移行したのかな」「CMSのコンテンツを移行するのってそれなりに大変なはずですよね」

w3techs.comより

「サーバーサイド言語のUsage 3位にRubyが入っているけどJavaScriptはランクインしていないんですね↓」「AWS Lambdaなどで処理の一部をサーバーサイドJavaScriptで動かしているサイトならそれなりにありそうですが、ドメインロジックのような大きな処理をサーバーサイドのJavaScriptで書いているサイトはまだそれほど多くないんじゃないかな」「なるほど」

w3techs.comより

「こういう情報は見ていて楽しいですね」「ですです」「こういうデータを調査などで使うときは、母集団の特徴・片寄りやデータ収集方法などを調べておく必要はありますね」

---

後編は以上です。

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

週刊Railsウォッチ: Kaigi on Rails 2022のタイムテーブル発表、書籍『Practicing Rails』ほか（20221003前編）

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

Ruby Weekly

Publickey