今日は朝刊（yyagi さんの「なるようになるブログ」）で取り上げられてた PR から ActiveModel::AttributeMutationTracker を読んだ。
属性変更をトラッキングするクラス。ActiveModel::Dirty とかで使われていそうで馴染みがあったのでシュッと読めたが、ForcedMutationTracker クラスが何のためのクラスかわからなかった。
コミットログから高速化の目的で切り出されているのが分かった。 force_change を track するために切り出したクラスなんだけど、ivar backed のものと attributes backed のものを一緒に動かすとすごく遅かったので切り出したとのこと。ソースとにらめっこしたりオブジェクトの中身見たりしたけど、いまいちなぜこれでここまで高速化されるかが分からない...ぐぬぬ。それにしてもすごい成果だ。
PR
良いテストコード、と言われて思い浮かぶ要素はいくつかあるだろう。
など。
たまたま良いテストコードについて議論する機会があったのだが、DRY 具合について話していたとき
過度なDRYを行わず、APIドキュメントだと思って書く 脳内メモリを消費させない“リーダブルなテストコード”の書き方 | ログミーBusiness
のようなリンクを見せ説明したが僕のいわんとすることがあまり伝わらなかった。そして相手が重要視していることも正直なところあまり理解できなかった。 価値観が違うのだろうということは話していて感じていたが、どうしてこういう違いが生まれるのだろうということを疑問に思った。「育ってきた環境が違うから」とは思うものの、より本質的に理解するにはもう少し何かが必要だなと感じ考えていた。
僕はテストを（特にユニットテストを）きれいな設計・実装を助ける道具だと捉えていて、そういう世界を実現するために使っている。依存関係を正常に切り出し、インターフェースを整え、ケースを整理しデバッグするための手段の一つだと捉えている。一方、おそらく議論した方はあまりテストを書くのが得意でないか、もしくは実装は開発環境で確認しすべて実装が終わったあとに品質のためある種の義務として書くものというように捉えているように見えた。
これでは良いテストについての価値観が違うのは当然で、どっちが良いというわけでなく使う道具の目的が違うんだからそれに求めるものや理想が異なるのは当然のことだろうと腹落ちした。（もちろんテストを使いこなすメリットは大きいとは思うが、色々な開発方法がありバリューを出しやすい方法を採用すれば良いと思うのでその是非はここでは問題にしていない。）
僕が PC に求めるものと営業の方が PC に求めるものは違うだろうし、趣味ランナーの僕がランニングシューズに求めるものとプロランナーがシューズに求めるものは違うだろう。
どっちが良いとか悪いではなく、そういうことなのである。
空いた時間に Rails コードリーディング。今日は ActiveRecord::Reflection をザーッと読んだ。
ActiveRecord::Reflection は model の関連付けに関するデータを保持するクラスという感じだった。例えば、belongs_to の実装では
def belongs_to(name, scope = nil, **options) reflection = Builder::BelongsTo.build(self, name, scope, options) Reflection.add_reflection self, name, reflection end
のように add_reflection を呼んでいる。
細かいオブジェクトのふるまいを見たかったのだが、binding.irb を使うと
SyntaxError: /home/vscode/.rbenv/versions/3.3.5/lib/ruby/gems/3.3.0/gems/irb-1.13.0/lib/irb.rb:1600: syntax error, unexpected `end'
というエラーが出てしまうの、IRB の不具合だったりするのだろうか。全然ちゃんと調べてないけど地味に困っている。
Rails のコードリーディング、久しぶりにしてみようと思いどこから読もうか眺めていたらたまたま見たことないモジュールが見つかったので読んだ。
ActiveRecord::Base#slice と ActiveRecord::Base#values_at を ActiveModel に移植したもの。non-Active Record なモデルで利用したかったからという理由。
テストを回して挙動を確認した
irb(#<AccessTest:0x00007f095f9d5bb0>):008> @point => #<AccessTest::Point:0x00007f095f504398 @vector=[123, 456, 789]> irb(#<AccessTest:0x00007f095f9d5bb0>):009> @point.x => 123 irb(#<AccessTest:0x00007f095f9d5bb0>):010> @point.y => 456 irb(#<AccessTest:0x00007f095f9d5bb0>):011> @point.z => 789 irb(#<AccessTest:0x00007f095f9d5bb0>):012> @point.slice(:x, :y, :z) => {"x"=>123, "y"=>456, "z"=>789} irb(#<AccessTest:0x00007f095f9d5bb0>):013>
今までMitamaeで管理していたが、例えば Ruby のインストールする場合 itamae の plugin を使うと便利なのだが依存関係が多くなり、dotfiles 管理・セットアップのためにはちょっと複雑すぎる印象があった。実際、Itamae を理解し使いこなすというより Ruby の中でシェルコマンドをたたいてあれこれする集合体になってしまっていた。それなら Mitamae である必要はないだろうと思い、かつ Windows でも使えるものが欲しいなと思い chezmoi を選んだ。
@mattn_jp さんの投稿で以下の比較表を知ったおかげできちんと比較し選べた。
シュッと WSL2 Ubuntu のセットアップスクリプトや設定ファイル群は移行して動くようにしたので、気が向いたときに Windows の方も育てていく。ちゃんと試していないが、会社用・個人用のような分岐もシュッとできるようなので便利そうだ。
昨年に引き続き、所属しているGMOペパボ株式会社の参加支援を受け参加しました。（去年に引き続き本当にありがとうございます。）
特に印象に残ったセッションについて書きます。
@tompng さんによる1日目のキーノート。初日のキーノートがMatzではないのは初とのことでしたが、本当に素晴らしかったです。発表内容の技術分野については度肝を抜かれるというか、「？？？」「すげー」「？？？」「すげー！おー！」みたいな繰り返しで、こんな書き方あるのかと思いつつ、理解できない部分も多かったのですが面白かったです。その中で沖縄にまつわる内容・その後のセッションの内容なども盛り込み「RubyKaigi 2024絶対おもしろいぞ！わくわくする！」と思える発表でした。例えばフィヨルドブートキャンプさんからの参加者などビギナーの方も一定数いたかと思いますが、どのようなレベルの人でもここから始まるRubyKaigi 2024がすごく楽しみになるような発表だったと思います。
@oshoyu さんによるGitHub - osyoyu/pf2: A sampling-based profiler for Rubyに関する発表です。C拡張ライブラリによる呼び出しのプロファイルもできるようになったおかげでHash#[]でのボトルネックを発見した話がとても印象的でした。他のprofilerとの比較を見る限り、実用性が高く今後が楽しみになる発表でした。
オブザーバビリティの観点で、OpenTelemetryで使えるとより細かい分析が可能になり、可用性向上・パフォーマンス向上への打ち手が打ちやすくなるだろうと思いました。どうやらOpenTelemetryでのprofilingの標準化の試みも進んでいるようなので、将来的にOTELで使えるようになると嬉しいなと思いました。
@coe401_さんによるRubyのsocketライブラリの改善に関する発表です。Issueについて「そんな実装になっていたんだ、たししかにのびしろがある」という印象を抱きました。その解決策としてRFCに規定されているアルゴリズムを実装するという方法をとっていて、素晴らしいなぁと思いました。
ところで、この課題はどのように発見しどのように RFC 8305 - Happy Eyeballs Version 2: Better Connectivity Using Concurrency にたどり着いたのか気になりました。
発表内でも名前が出ていた松下氏が2020年に同様の内容でRubyアソシエーション開発助成に採択されているので、この系譜を継ぎ進めた形なのでしょうか。
どちらにしろ素晴らしいことで、Rubyアソシエーションの開発助成についてきちんとウォッチしておくべきだなぁと意識させられました。
Rubyは停止時にメモリ開放しないので、Valgrindでメモリリークを検知するには偽陽性が多すぎる、ruby_memcheck ではheuristics approachで偽陽性を検出しているので根本解決にならず、停止時にメモリ開放をするように実装しその機能を利用するオプションをつけたという話です。
偉業！新しいRubyを使い恩恵を受けたくなるようなものでした。Valgrindも使ったことないので触って活用したいなと思える発表でした。
もともと興味があった発表の一つで、多少予習をして臨みました。Day1のOfficial Partyの移動の際、たまたまうづらさんとお話できて発表について説明を聞けてとてもありがたかったです。そのときの話と発表を聞いてめちゃくちゃ夢があるという印象を受けましたが、その時点では正直細かい部分などあまり内容を理解できませんでした。
この記事を書きながら改めてスライドや以下を始めとするうづらさんのブログ記事などを読みChatGPTに色々聞きながら復習していたら、そもそもmrubyにおけるRiteや.wasmのバイナリについての仕様についてわかってきて、なるほど！という感じだった。バイナリ楽しいですね。（ほんとに？）
wasmバイナリにどんなセクションがあるか、とか、使い方とは、みたいな話は以下の本をサクッと読んでください。
とのことで、興味が出てきたので読んでみようと思った。
「Drive Your Code: Building an RC Car by Writing Only Ruby」ではラジコンを作りたくなり、「The Journey of rubocop-daemon into RuboCop」ではは Rubocop Daemon 導入の裏話的なものを聞けておもしろかったです。movさん主催のAfter Partyでは@forteさんとこれについて話せたのもよかったです。
平衡二分木の一種である赤黒木を利用して高速化を行う話です。アルゴリズムの重要性やパワーを感じる発表でした。アルゴリズムやデータ構造、コンピューターサイエンスの基礎的な部分の知識の不足がボトルネックになっていると感じる場面が多く、腰を据えてやらねばと思っていた自分にはタイムリーな発表でした。
自分はStep-to-Rails-Expert.rbというRailsのコミュニティを立ち上げ2016年から5年ほどやっていました。（今は大倉さんが引き継いで開催してくださっている。）
そこで出会ったみなさんとかなり久々に再開できてStep-to-Rails-Expert.rbの同窓会みたいになったのが最高でした。当時初心者だった方はエンジニアとして活躍されていて、当時中・上級者だったみなさんは要職についてらっしゃって、年をとるはずだ...としみじみ。たくさん嬉しいことあったけど、参加者の方から「当時の中級者の集まる場所としてとても良い場所で、自分もとても楽しんでいた」と言ってもらえたのが特にうれしかったです。
主催してた #StepRailsEx で出会い参加して頂いてたみなさんと数年ぶりに #rubykaigi で数年ぶりに再開できてめちゃくちゃエモい #rubyfriends@cangineer @kuronekopunk @krpk1900_dev pic.twitter.com/UrECbUe4XU
— ebi (@ebihara99999) 2024年5月17日
昔コミュニティでめちゃくちゃお世話になったお礼が言えてよかったです！ありがとうございました！ @koheisg#rubykaigi #rubyfriends pic.twitter.com/vpTdDEycjQ
— ebi (@ebihara99999) 2024年5月17日
また、当時初心者だったころ、スタッフしてくださっていた方に
ぼくが立ち上げたコミュニティで吸収したあれこれがRubyistの原点ですみたいなこと言ってもらえてほんとエモすぎる
— ebi (@ebihara99999) 2024年5月17日
のようなことを言ってもらえて「やっていてよかったなぁ」とすごくうれしかった。新型コロナウィルスの影響でリモート開催を余儀なくされ、徐々にモチベーションがなくなり開催しなくなってしまい、StepRailsExが自分の中で良い感じに終わった感じや区切りがついた感じがなかったのだけど、何年か経ちこんな形で報われるとは思ってなくてうるっときました。
あっきーさん、触れてくれてありがとうございます！ note.com
僕も参加し再開したいなと思っていたので、今年何かしら動かしていこう。
やんちゃさんにRasberry Pi Picoを頂きました。hasumiさんの発表は聞けていないんだけど、ずっと触ってみたいなと思っていました。やんちゃさんが配っているのは知っていたがもっと適切な人がいるだろうと思っていたのでもらうつもりはありませんでしたが、Day2の夜に話す機会があり一枚余っているとのことで頂きました。会期中に試せず申し訳なかったのですが、この機会がなければ触ることなかったと思うので本当に感謝しています。帰ってすぐRasberry pi pico と picoruby でLチカさせる - ebihara99999 をやりました。面白いので何か作ろうと思います。
そのきっかけとなった 株式会社万葉さんと 合同会社春秋さんとの懇親会もとても楽しめました。普段お仕事のお礼や挨拶、沖縄開催本当に楽しいですーという話、テックの話、エンジニアリングマネジメントの話などいろいろ話せてとても有意義な時間でした
#rubykaigi #rubyfriends めちゃくちゃ楽しんでます！ pic.twitter.com/AjZDeBu4t3
— ebi (@ebihara99999) 2024年5月16日
その他各社との交流や社内メンバーとの懇親も時間をとってゆっくりできて、RubyKaigiならではだなぁと思いました。色々なトピック話せてとても面白かったです。特にmovさん主催のAfter Partyではたくさんの方と交流ができました。お話したみなさん・主催して頂いたmovさん、ありがとうございました。
学ぶこと・アウトプットすること・コードを書くことというのをもう少し気楽にやりたいなと思っていたところ、会期前に発見したしおいさんの GitHub - shioimm/til: Today I learned. がすごくいいなと思っていたので（どこかの文化かな）作り、 総合目次 - 苦しんで覚えるC言語 をやっている。
Rubyのソースコードをはじめ、ミドルウェアなどもC言語で実装されているもの多く、ソースコードリーディングするときに困っていたのでやっている。「わからない」と思うとき、それはC言語が分からないということではないだろうことは自覚しているが、それはそれとしてやっておいたほうが良いと思うので。また、前述したアルゴリズムの話で、回答例・解説などがC++で実装されていることも多く、そこでもC系列の言語の記法に不慣れで読みづらかったりしてあきらめてしまう経験があったので、その意味でもよいかなと思っている。
また、雑に何か書くのやはりScrapbox（現Helpfeel Cosense）が良いなと思いちゃんと使うことにした。
あとmrubyは会期中にビルドして使えるようにしておいたのと上述のLチカ周りも取り組んだ。
これから取り組むネタや課題を見つけるというのが大きなテーマだったが、いろいろ持ち帰れたので復習したり色々試しつつ、何かしらに取り組んでいきたい。
