フロントエンドエンジニア、Railsしぐさを思い出す Railsアプリをコスパよく読むための環境整備 @ikuma-t GENBA #1 〜RubyとRails開発の現場〜 2023-11-15 19:30

ikuma-t IkumaTadokoro ikumatdkr ikuma-t.com ikumatadokoro 株式会社エンペイで働く、フロントエンドが好きなエンジニア。 学生時代はどうしても働きたいパン屋に電話して「雇ってください！」 とお願いしたりしてました。

エンペイのプロダクト それぞれ異なった技術スタックを採用 ここに在籍 1年くらい 復帰

フロントエンドエンジニアがRailsの現場にいくと… Railsのソースとの関わり： 専門領域ではないけど普通に触る 規模の小さなスタートアップなので、フロントエンドエンジニア = UI方面を割とよく書くエンジニア なのでバックエンドのソースコードについても、普通に読んだり書いたりする。 一定は読めるけど、Ruby/Rails特有の構造にはまりやすい😇 少なくとも1言語以上の基礎はあるので、基本的な制御構造はそれなりに読める。 突然道端からメソッドが生えてきたり、Ruby/Rails特有のおきまりごとやDSLが出てくると生産性が落ちる。

ダークサイド的需要の発生 RubyとかRailsをじっくり1から学んで理解したい 今の仕事をとりあえず進めるだけの力を！ 長期的にはRubyやRailsをちゃんと向き合った方が良いのは、それはそう案件 チカラガホシイカ... ヨクボウノママニ... ダークチップヲツカイナサイ...

今日のテーマ とりあえずRailsアプリケーションを読み書きするためのTips

目次 1. エディタに教えてもらう 2. テストをシュッと実行する 3. REPLこそ最速のフィードバックループ

Editor エディタに教えてもらう

Editor - 前提：VSCodeでのRuby開発 「RubyMineならそれ当たり前にできますよ！」それはそう。 昔はRubyMineを使っていたし、一応今も契約している なんならRubyMine入門 - Zennすら書いている 今回はVSCodeを例として紹介していく TypeScriptの開発元（MicroSoft）が提供しているエディタである、フロントエンドエコシステムの諸々の 拡張の提供が優先される等の点からフロントエンドではVSCode使っている人が多いイメージ

Editor - Error Lens RubyもRailsもなにも関係ない。エラーをインライン表示してくれる拡張。 VSCodeは Error Lens Intelij系はInspection Lens これをベースにRuby用の拡張を有効化する

Editor - Ruby LSP / Ruby LSP Rails / Solargraph Ruby LSP: Shopifyが提供しているRuby用LSP 名前の通りLSP。機能は色々あるので公式Docs参照。 コードジャンプや補完は個人的に足りない部分が多く、別のLSPである Solargraphと併用して利用（画像の補完はRuby LSPでは実行でき ず、Solargraphが必要） Ruby LSP Rails: Ruby LSPの公式Addon ・（Rails起動中限定）ModelのDB定義がHoverで表示される。 ・使用しているRailsのverでAPI DocのリンクがHover表示できる ・（補足）Ruby LSPのAddonは自分でも書くことができる 基本装備

Test テストをシュッと実行する

Test - Run テスト実行に手間がかかると、その分フィードバック が遅くなる。すぐに実行したい。 拡張機能なしであれば、tasks.jsonに定義登録する と、rspecの実行コマンドを省略できる。 Failした時にProblemとして登録するような仕組 みにすると、Error Lensが呼応して、落ちたテス トがすぐわかり便利。 自分で書いたテスト / 既存のテストに対しての mutation test。 誰が書いたコードであれ、挙動を確かめるのにテストを動かすのは有効 10 "problemMatcher": [ 11 { 12 "owner": "ruby", 13 "fileLocation": [ "relative", "${workspaceFolder}" ], 14 "pattern": { 15 "regexp": "^rspec\\s+(.*):(\\d+)\\s+#\\s+(.*)$", 16 "file": 1, "line": 2, "message": 3 17 } 18 } 19 ] 1 // tasks.json 2 { 3 "version": "2.0.0", 4 "tasks": [ 5 { 6 "label": "Run Rspec current file with line", 7 "type": "shell", 8 "command": "bin/rspec -fd -ff ${relativeFile}:${input:lineNumber}", 9 "group": "test", 20 } ], 21 "inputs": [ 22 { 23 "id": "lineNumber", 24 "type": "promptString", 25 "description": "Enter the line number to run RSpec on:" 26 } 27 ] 28 }

Test - Run 0:00

Test - Debug どうしても動かしてみないと挙動の詳細がわからない 時はデバッガで動かすのが便利。 debug.gem + vscode-rdbgでRSpec（Railsも） がシュッと動くようにlaunch.jsonを組んでおくと捗 る。 デバッグしたいと思った時には、デバッガが起動していないとダメなんだ 1 // launch.json 2 { 3 "version": "0.2.0", 4 "configurations": [ 5 { 6 "name": "Debug RSpec with Current Line", 7 "type": "rdbg", 8 "request": "launch", 9 "cwd": "${workspaceFolder}", 10 "rdbgPath": "bundle exec rdbg", 11 "command": "bin/rspec", 12 "script": "${file}:${input:lineNumber}", 13 "args": [], 14 } 15 ], 16 "inputs": [ 17 { 18 "id": "lineNumber", 19 "type": "promptString", 20 "description": "Enter the line number to run RSpec on:" 21 } 22 ] 23 }

Test - Debug 0:00

REPL REPLこそ最速のフィードバック ループ

REPL 細かい部分の挙動を調べる時には、やっぱりRails Consoleが便利 型が入っていなくても補完が結構効いてくれるので、積極的に使いたい。 Rails Console / IRB こそ 最速のフィードバックループ

REPL - Find & Open Definition メソッドの定義やルーティング定義をシュッと探す 9 # ENV['EDITOR'] | ENV['VISUAL'] で 指定したエディタでコードが開く(Ruby 3.2 から) 10 # もちろん 「$ 」でもOK （show_source のエイリアス：これもRUby 3.2 から） 11 > edit Foo 12 > edit Foo#bar 13 > edit path/to/foo.rb 1 # メソッドの定義元を探す： Method#source_location 2 > User.new.method(:full_name).source_location 3 # ["/path/to/user.rb", 8] 4 5 # 実際のURL から処理を調査したい: Rails.application.routes.recognize_path 6 > Rails.application.routes.recognize_path 'hoge/1/fuga' 7 # { :controller => "hoges/fugas", :action => "show"} 8

REPL - GPT どこからわからないのかがわからない / 調べ方がわからないケースもある。 railsjazz/ask_chatgptはRails ConsoleでOpenAI APIが叩けるGem。 Tell, Don’t Ask いや…やっぱり Ask しちゃう 4 ObjectSpace を使用することで、定義されているメソッドを探すことができます。 5 以下のようなコードをRails Console で実行してみてください。 6 7 method_name = : メソッド名 8 ObjectSpace.each_object(Class) do |klass| 9 if klass.method_defined?(method_name) 10 puts "#{klass} クラスで定義されています。" 11 end 1 > gpt.ask ' どこかのClass で定義されているメソッドなんだけど、どこで定義されているかわから 2 どう調べたら良い？' 3 12 end

REPL - GPT Custom Prompt Method 独自のプロンプトを発行するメソッドをinitializerで定義できる。Railsのコンテキストをメソッドで埋め込んだり、ソ ースそのものを含めることもできる（用法用量を守ってご利用ください）。 良い感じの独自メソッドを定義できる人は、そもそもこれいらない説もある。 1 # `gpt.make_cmd " 実際の画面のURL から対応するルーティングとコントローラーを出したい"` 2 config.register_prompt :make_cmd do |arg| 3 "#{arg} を実現するために、Rails Console 内で実行できるコマンドを、[ 回答] のフォーマットで 4 コマンドは必ず再利用可能なようにメソッドの形式で、もし可能であればワンライナーでお願いしま 5 6 [ 回答] 7 < 解説を記述してください。> 8 9 < コードブロックでコードを記述してください。> 10 " 11 end

REPL - GPT Setting デフォルトでもRuby、Rails、DBのバージョンをGPTの前提に含めてくれているが言語は英語。 Rails Consoleから離れて時間をロストしないためにも、Rails consoleにいることを明示しておくのはあり。 config/initializers/ask_chatgpt.rb 1 AskChatGPT.setup do |config| 2 # NOTE: included_prompts はcontent に応答する必要がある。 3 # なんでも良いが、お手軽にcontent を持つData を定義するのがいいかも。 4 Prompt = Data.define(:content) 5 content = [ 6 " 次のバージョンで動作するRails Console から質問をしています。" 7 "Rails #{Rails.version}, Ruby #{RUBY_VERSION}", 8 " 返答はすべて日本語でお願いします。", 9 ].join 10 config.included_prompts = [Prompt.new(content)] 11 end

Conclusion まとめ

即時性と再現性 学びの効果がさらに高まるのは、即時性のあるフィードバックが得られるときです 未知の技術を学ぶときは、公式のドキュメントを読むだけでなく、実際に手を動かしてみ ることが効果的です。学びの効果がさらに高まるのは、即時性のあるフィードバックが得 られるときです。手の動かしやすさと即時フィードバックが得られるという観点では、 REPL（Read-eval-print loop ）やデバッガ、開発者コンソールなどの対話的なUI（User Interface ）がまず候補に挙がるでしょう。 学びという観点でもう一つ大事なのが再現性です。再現性とは、学習内容をどのくらい簡 単に再現できるかどうかです。この観点では、対話的環境で動かしただけでは十分とは言 えません。過去の学習内容を手もとで再現するのがやや面倒だからです。 このサイトでは、ご利用体験の改善（セッション管理）に加えて外部のサービスを使用した広告配信

まとめ 即時性のあるフィードバックを得られる状況を作る 学びの効果が高まるのは即時性のあるフィードバックが得られるとき 実践的な状況で学ぶのが効果的なのは言わずもがな そのためにRuby/Railsの現場では... Ruby/Railsの言語・エコシステムの柔軟さを存分に利用し、高速なフィードバックループを整備する そのための具体的な手法を今日はいくつか紹介した エディタ（実際のコード）上に実行結果や情報などのフィードバックを反映させる テストをゼロコストで実行する もともと強いREPLとRubyに、さらにAIを追加して学習を加速させる Railsアプリケーションをコスパよく読み書きできるようにするために

ありがとうございました。 Slides on ikuma-t.com