Appendix B: VS Code Ruby Workflow

en/appendix_b_vscode_ruby_workflow

merged appendix page

Visual Ruby Study Workflow in VS Code ️

Purpose 🎯

This appendix is a presenter kit for a screen-recorded lesson. Its goal is not to teach more Ruby syntax. Its goal is to make students comfortable working inside VS Code with Ruby projects, Ruby extensions, and the command-line tools introduced in Appendix A.

By the end of the recording, students should feel:

• "I know which VS Code features matter first."
• "I know which Ruby extensions are useful and why."
• "I know how VS Code and terminal tools work together."
• "I can move from project setup into sprint work without feeling lost."

Teaching approach 🧭

The recording should follow the same life-cycle order as Appendix A:

1. open the project;
2. confirm Ruby environment;
3. install or inspect extensions;
4. use the integrated terminal for project setup;
5. navigate Ruby files and tests;
6. run a topic test;
7. use docs and lint feedback;
8. use the debugger;
9. connect the editor workflow back to daily sprint work.

What is included in this appendix 🗂️

• extensions_setup.md: which VS Code extensions to install first and why
• vscode_basics.md: the minimum VS Code features students should learn first
• recording_storyboard.md: what to show on screen in order
• running_tests_in_vscode.md: terminal-first, task-based, and debug-based test running
• talking_script.md: speaker notes and suggested narration
• slides.md: slide deck outline with diagrams
• demo_checklist.md: pre-recording and live-demo checklist
• recording_mode.md: how to make the recorded editor experience calm and readable

Core message 💡

VS Code is not replacing Ruby knowledge. It is giving students a visible, safe, repeatable workspace for the Ruby project lifecycle:

• interpreter
• dependencies
• tests
• docs
• debugging
• sprint loops

VS Code Basics for This Course

Purpose 🎯

Students do not need a full VS Code class before they can learn Ruby. They do need just enough editor confidence to move through this course without friction.

This file covers the minimum VS Code features that support the course directly.

1. Open the repository as a folder 📁

Recommended action:

• File -> Open Folder...
• choose the course root directory

Why this matters:

• the Explorer shows the full learning structure;
• the integrated terminal starts in the right workspace;
• search, tasks, and debugging all work with project-relative paths.

Real-life situation:

If a student opens only one Ruby file instead of the project folder, the editor loses the project shape. Then search, test commands, and launch configurations all become harder.

2. Learn the key panels only 🪟

Students should recognize:

• Explorer
• editor tabs
• integrated terminal
• Problems panel
• Extensions sidebar
• command palette

Suggested teaching line:

"You do not need to master all of VS Code. You need enough orientation to move calmly between files, terminal, diagnostics, and commands."

3. Use the Explorer like a study map 🗺️

Why it matters in this course:

• each topic contains notes, code, answers, and tests;
• students should see the topic as a structured unit;
• appendices are part of the workspace, not separate documents.

Good demonstration:

• open a topic folder
• expand tests/
• open overview.md, guide.md, example.rb, and the spec file

4. Use split editor intentionally ↔️

Good uses:

• notes on one side, code on the other
• spec on one side, implementation on the other
• markdown preview on one side, raw markdown on the other

Why this matters:

• this course is designed for movement between reading and coding
• split view reduces context switching

5. Learn the command palette early ⌘

Useful command palette actions:

• Tasks: Run Task
• Debug: Select and Start Debugging
• Markdown: Open Preview
• Preferences: Open Keyboard Shortcuts

Why it matters:

• students do not need to memorize every menu location
• VS Code becomes easier when one searchable command entry point is familiar

6. Use the integrated terminal as part of the editor 💻

This course depends on terminal-first commands:

• ruby -v
• bundle install
• ./run_tests.sh
• bundle exec rubocop
• ri Array#map

That means the terminal is not separate from the editor workflow. It is part of it.

7. Use the Problems panel 🚨

Why it matters:

• syntax errors and lint issues often surface here
• the panel helps students go from "something is wrong" to "this file and line need attention"

Good teaching point:

"The Problems panel is not where you solve the issue. It is where you locate it quickly."

VS Code Extension Setup for the Course

Core principle 💡

Use the minimum editor extensions that directly support the course workflow.

Students do not need a crowded editor. They need a reliable workflow for:

• reading Ruby files clearly;
• running tests;
• seeing diagnostics;
• formatting or linting consistently;
• debugging when runtime behavior becomes unclear.

Recommended core extensions ✅

1. Ruby LSP

Why it matters:

• provides Ruby language intelligence inside VS Code;
• helps with navigation, diagnostics, and editor awareness of Ruby code;
• supports normal coding across all course topics, from classes to lambdas to SQLite.

What to show in the recording:

• extension installed and enabled
• syntax awareness inside .rb files
• go-to definition or hover on a method/class
• diagnostics appearing in the editor

Real-life situation:

• a student forgets where a class or method is defined
• the editor helps them move through the project instead of manually searching every file

2. VS Code rdbg / Ruby debugger support

Why it matters:

• supports runtime inspection when tests fail or behavior is confusing;
• especially useful for recursion, closures, database queries, and iterative game state

What to show in the recording:

• launch debugger on a Ruby file or through the test command
• set a breakpoint
• inspect local variables

Real-life situation:

• a recursive function returns the wrong value only on nested input
• a student needs more than puts

3. RuboCop support in the editor or terminal

Why it matters:

• gives style and lint feedback
• reinforces that Ruby projects usually have a consistency tool

What to show in the recording:

• run bundle exec rubocop in the terminal
• optionally show inline diagnostics if the extension/editor integration is active

Real-life situation:

• the code runs, but the team wants consistent layout, naming, and basic style feedback

Optional supporting extensions 🌱

These are useful, but should be introduced as optional:

Markdown preview support

Why:

• this course now contains many .md study files
• students can preview notes, appendices, and slides directly inside VS Code

What to show:

• open a markdown file
• split editor with preview

Git support extensions

Why:

• helpful once students start making structured changes
• not essential for the first visual workflow lesson

Recommended install order for the lesson 🪜

1. Ruby LSP
2. Ruby debugger / rdbg
3. RuboCop support or at least terminal RuboCop use
4. Markdown preview support if you want to show course notes visually

Important teaching point 🎯

Do not tell students:

• "install everything that looks Ruby-related"

Tell them:

• "install the smallest set that supports the actual project lifecycle"

That keeps the editor from feeling magical or fragile.

Running Tests in VS Code ✅

Core principle 💡

Teach test running in layers:

1. terminal commands first
2. VS Code tasks second
3. debugger configurations when runtime inspection matters

Students should understand the underlying command before depending on the editor shortcut.

1. Run all tests from the integrated terminal 💻

./run_tests.sh

Why this is the baseline:

• it matches the course's normal verification flow
• it uses the project's own bootstrap logic
• it behaves the same inside or outside VS Code

2. Run one topic from the integrated terminal 📚

./topic_10_rock_paper_scissors/run_topic_tests.sh

Why this matters:

• topics are taught in small sprint-sized units
• students should get comfortable focusing on one topic at a time

3. Run one spec file directly 🎯

bundle exec rspec topic_14_functional_style_lambdas/tests/topic_14_functional_style_lambdas_spec.rb

Why this matters:

• useful when the student is focused on one spec file
• useful when debugging one piece of behavior

4. Use VS Code tasks for convenience 🛠️

This repository includes .vscode/tasks.json.

Suggested tasks to demonstrate:

• Run All Course Tests
• Run Current Spec File
• Run Current Topic Tests
• Run RuboCop

How to run them:

1. open the command palette
2. choose Tasks: Run Task
3. select the task

Why this matters:

• repeated commands become easier to discover
• the workflow becomes less intimidating for beginners

5. Use launch configurations for debugging 🐞

This repository includes .vscode/launch.json.

Suggested launch configurations to demonstrate:

• Debug Current Ruby File
• Debug Current Spec File
• Debug All Course Tests

Why this matters:

• debugging should feel like part of normal project work, not a special advanced trick

6. Recommended teaching order in the recording 🎥

1. run ./run_tests.sh
2. run one topic script
3. show Tasks: Run Task
4. show Debug Current Spec File

That order keeps the story grounded in the project rather than in editor buttons.

Demo Checklist for the Recording ✅

Before recording 🎬

• Open VS Code in the course root.
• Ensure the integrated terminal starts in the project directory.
• Confirm the Ruby version expected by the project is active.
• Confirm the core extensions are installed:
  • Ruby LSP
  • Ruby debugger / rdbg
  • optional RuboCop support
• Pre-open one or two good topics for demo:
  • topic_10_rock_paper_scissors
  • topic_13_recursion_closures

Terminal commands to have ready 💻

ruby -v
which ruby
bundle install
./topic_10_rock_paper_scissors/run_topic_tests.sh
ri Enumerable#map
ri Array#zip
bundle exec rubocop

Good editor moments to capture 📸

• file tree navigation
• markdown preview or side-by-side markdown reading
• jump between a test and implementation
• one hover or go-to-definition moment
• one visible terminal run
• one task run from the command palette
• one simple breakpoint/debug moment

Debug demo recommendation 🐞

Best options:

• topic_13_recursion_closures
  • easy to explain call stack and recursive state
• topic_12_sqlite_queries
  • useful if you want to show variable inspection around query results

Things to avoid 🚫

• spending too long on VS Code settings
• browsing extension marketplaces during the recording
• introducing five optional tools before the core flow is visible
• turning the recording into a shell tutorial

Final reminder 🌱

The student should leave with:

• a clear first-use order for tools
• less fear of the integrated terminal
• comfort with the minimum VS Code panels
• awareness that test running can happen in terminal, tasks, or debugger flow
• confidence that VS Code can support the course workflow calmly

Recording Mode for VS Code Lessons

Purpose 🎯

A technically correct recording can still be hard to follow if the screen is crowded, the text is too small, or the presenter keeps rearranging panels mid-explanation.

This file is a practical guide for making the screen recording calm, readable, and consistent with the teaching goals of the course.

1. Use a clean workspace state 🧹

Before recording:

• close unrelated files and terminals
• open only the project folder for this course
• keep one or two topic folders expanded, not the entire tree
• avoid notification popups or chat overlays

Why:

• students should focus on the workflow, not on visual noise

2. Make text larger than your normal coding setup 🔍

Recommended baseline:

• editor font size around 15
• integrated terminal font size around 14
• line height slightly increased

Why:

• recordings compress detail
• students may watch in a browser, on a laptop, or at reduced resolution

This repository's .vscode/settings.json already provides a calm starting point.

3. Reduce visual clutter 🪶

Recommended choices:

• disable the minimap
• keep word wrap enabled for markdown
• avoid too many side panels open at once
• show only the Explorer and terminal when needed

Why:

• students should see structure and movement, not a busy IDE dashboard

4. Prefer stable layout changes 🧱

Good layout pattern for this course:

• Explorer visible on the left
• main editor in the center
• terminal in the editor area or bottom panel
• one split editor when comparing guide/spec or code/spec

Avoid:

• constant resizing
• opening and closing many panels rapidly
• jumping between too many tabs in one minute

5. Use a predictable theme 🎨

Recommendation:

• use a high-contrast but calm theme
• avoid novelty color themes for teaching

Why:

• students should learn the workflow, not decode the color palette

If you already have a preferred theme, keep it only if:

• comments are legible
• markdown headings are clear
• terminal output is readable
• error coloring is obvious

6. Zoom and pacing matter ⏱️

Recommended practice:

• use editor zoom if needed before recording starts
• scroll slowly when reading markdown
• pause briefly after terminal output appears
• leave the result visible long enough for students to orient themselves

Why:

• students need time to connect editor actions with terminal consequences

7. Show only one idea at a time 🎯

Bad sequence:

• open extensions
• jump to terminal
• jump to launch config
• jump to markdown
• start debugger

Better sequence:

• explain one stage
• show one action
• state why it matters
• move to the next stage

8. Recording checklist ✅

Before pressing record:

• confirm the project opens at the course root
• confirm Ruby version is correct
• confirm the terminal starts in the workspace
• confirm the key extensions are installed
• confirm the .vscode/tasks.json and .vscode/launch.json are present
• confirm font sizes are readable in the recording resolution
• pre-open the files you want to compare

9. Good moments to zoom in on 🔎

Useful close-focus moments:

• the command palette when running a task
• the integrated terminal when running ./run_tests.sh
• the debugger panel when inspecting recursive or query state
• markdown preview when connecting notes to code

10. Good moments to slow down verbally 🗣️

Slow down when:

• explaining why terminal commands still matter inside VS Code
• showing the difference between running a task and understanding the command
• introducing the debugger
• connecting the editor workflow back to the sprint cycle

11. Closing advice for the presenter 🌱

The best recording tone for this appendix is:

• calm
• ordered
• practical
• explicit about why a tool exists

Students should leave thinking:

• "I can do this setup."
• "I know what comes first."
• "I know how to run tests and debug inside VS Code."

That is more valuable than showing every available editor trick.

Recording Storyboard: VS Code Ruby Workflow

Recording goal 🎯

Produce one screen recording that helps students become comfortable with VS Code as the working home for the course.

This is not an extension review. It is a guided project workflow story.

Total recommended length ⏱️

20 to 30 minutes

Segment 1: Open the project and orient the student 🧭

Screen actions

• open VS Code in the course root
• show the file tree
• briefly point out:
  • topics
  • appendices
  • run_tests.sh

Teaching goal

Students should see the repository as a structured learning workspace, not a random set of files.

Segment 1.5: Show only the VS Code basics that matter 🪟

Screen actions

• point out the Explorer
• point out the integrated terminal
• point out the Problems panel
• use the command palette once
• preview one markdown file

Teaching goal

Students should feel that they already know enough VS Code to continue with the course.

Segment 2: Show the minimum useful extensions 🧩

Screen actions

• open the Extensions sidebar
• show Ruby LSP
• show the Ruby debugger extension / rdbg
• mention RuboCop support

Teaching goal

Students should understand:

• why each extension exists
• that the editor is helping the workflow, not replacing understanding

Segment 3: Connect VS Code to Appendix A tools 🔗

Screen actions

• open the integrated terminal
• run:

ruby -v
which ruby
bundle install

Teaching goal

Show that VS Code is not "instead of terminal." It is a place where terminal and editor work together.

Segment 4: Open one topic and read it like a student 📚

Screen actions

• open one topic, for example topic_10_rock_paper_scissors
• show:
  • overview.md
  • guide.md
  • example.rb
  • tests/...

Teaching goal

Students should see the learning rhythm:

• read
• inspect code
• inspect tests
• run tests
• implement in sprints

Segment 5: Run a topic test from the terminal ✅

Screen actions

• run:

./topic_10_rock_paper_scissors/run_topic_tests.sh

or another topic of your choice

Teaching goal

Students should connect the file they see in the editor with the behavior they see in the terminal.

Segment 5.5: Show the task-based workflow 🛠️

Screen actions

• open the command palette
• choose Tasks: Run Task
• run:
  • Run All Course Tests
  • Run Current Topic Tests
  • Run Current Spec File

Teaching goal

Students should understand that tasks are convenience wrappers around the same project commands.

Segment 6: Use editor navigation and diagnostics 🔎

Screen actions

• jump between example and test
• hover or navigate to a class/method
• show diagnostics if possible by introducing a tiny temporary typo and undoing it

Teaching goal

Students should feel that the editor helps them move and inspect, not just type.

Segment 7: Use ri and markdown docs during implementation 📖

Screen actions

• in terminal:

ri Enumerable#map
ri Array#zip

• in editor:
  • open a topic cheatsheet.md
  • preview a markdown file

Teaching goal

Students should see that:

• the editor is where they read project notes
• the terminal is where they ask Ruby for API help

Segment 8: Show RuboCop as workflow support ✨

Screen actions

• run:

bundle exec rubocop

• optionally show in-editor lint feedback if available

Teaching goal

Students should understand that style tools are part of normal Ruby team practice.

Segment 9: Show the debugger on one meaningful example 🐞

Best demo targets

• recursion from topic_13_recursion_closures
• SQLite query flow from topic_12_sqlite_queries

Screen actions

• set a breakpoint
• run debug
• inspect locals
• step once or twice

Teaching goal

Students should leave with:

• "I do not need to fear the debugger"
• "When runtime behavior is confusing, I have a tool for inspection"

Also show briefly:

• the .vscode/launch.json file
• the Debug Current Spec File configuration

Segment 10: Close by showing the sprint loop 🔁

Screen actions

• open appendix_a_project_lifecycle/sprint_flow.md
• summarize:
  • check runtime
  • install dependencies
  • run one test
  • read docs
  • code
  • lint
  • debug if needed

Teaching goal

Tie VS Code back to the course's bigger development rhythm.

Slide Deck Outline: VS Code Ruby Workflow ️

This slide outline is intentionally short. The screen recording should do most of the teaching, and the slides should support the transitions.

Slide 1: Title 🎬

From Empty Editor to Ruby Sprint Workflow

Subtitle:

• VS Code, Ruby extensions, and the real project lifecycle

Speaker point:

• This is not an editor-tour video
• It is a workflow-orientation lesson

Slide 2: The real story 📚

Text:

• Ruby version
• Project setup
• Dependencies
• Tests
• Docs
• Linting
• Debugging
• Sprint loop

Diagram:

flowchart LR
  A[Ruby Version] --> B[Project Folder]
  B --> C[Dependencies]
  C --> D[Run Tests]
  D --> E[Read Docs]
  E --> F[Code in Editor]
  F --> G[Lint]
  G --> H[Debug]
  H --> I[Repeat Sprint Loop]

Slide 3: Editor and terminal are partners 🤝

Text:

• VS Code is not replacing the terminal
• The terminal is where Ruby project truth is checked

Diagram:

flowchart LR
  A[Editor] <--> B[Integrated Terminal]
  B --> C[ruby -v]
  B --> D[bundle install]
  B --> E[bundle exec rspec]
  A --> F[Read topic docs]
  A --> G[Edit Ruby files]
  A --> H[Review diagnostics]

Slide 4: Minimum useful extensions 🧩

Text:

• Ruby LSP
• Ruby debugger / rdbg
• RuboCop support
• optional markdown support

Diagram:

flowchart TD
  A[Core Ruby Workflow] --> B[Ruby LSP]
  A --> C[rdbg]
  A --> D[RuboCop]
  A --> E[Markdown Preview]

Slide 5: How a student should open a topic 🧭

Text:

• overview.md
• guide.md
• example.rb
• tests/...
• run topic test

Diagram:

flowchart LR
  A[overview.md] --> B[guide.md]
  B --> C[example.rb]
  C --> D[tests]
  D --> E[run_topic_tests.sh]

Slide 5.5: How tests run in VS Code ✅

Text:

• terminal first
• tasks second
• debugger when runtime state matters

Diagram:

flowchart TD
  A[Integrated Terminal] --> B[./run_tests.sh]
  A --> C[topic_x/run_topic_tests.sh]
  D[VS Code Tasks] --> B
  D --> E[bundle exec rspec current_spec]
  F[Launch Configs] --> G[Debug Current Ruby File]
  F --> H[Debug Current Spec File]

Slide 6: Docs in the middle of the sprint 📖

Text:

• project docs in the editor
• Ruby docs through ri

Diagram:

flowchart LR
  A[Question during coding] --> B[ri in terminal]
  A --> C[topic cheatsheet in editor]
  B --> D[Continue coding]
  C --> D

Slide 7: When projects grow up 🌳

Text:

• rake for repeatable tasks
• rubocop for consistency
• rdoc and yard for maintainable docs
• rdbg for runtime inspection

Diagram:

flowchart TD
  A[Working Project] --> B[Repeatable Tasks]
  A --> C[Style Consistency]
  A --> D[Human Docs]
  A --> E[Runtime Debugging]
  B --> F[rake]
  C --> G[rubocop]
  D --> H[rdoc / yard]
  E --> I[rdbg]

Slide 7.5: Project config files support the workflow ⚙️

Text:

• .vscode/tasks.json
• .vscode/launch.json
• shared workflow, not personal magic

Slide 8: Final sprint loop 🔁

Text:

• check runtime
• sync dependencies
• run one test
• code
• look up docs
• lint
• debug if needed
• repeat

Diagram:

flowchart LR
  A[Check Runtime] --> B[Install/Sync Dependencies]
  B --> C[Run One Test]
  C --> D[Code]
  D --> E[Look Up Docs]
  E --> F[Lint]
  F --> G[Debug if Needed]
  G --> C

Slide 9: Closing 🌱

Text:

• The editor is not the lesson
• The workflow is the lesson
• Comfort comes from repetition, not from memorizing every command

Talking Script: VS Code Ruby Workflow Recording ️

Opening 👋

"In this recording, I am not trying to teach you more Ruby syntax. I am trying to make the Ruby project feel operationally comfortable inside VS Code. The goal is that when you open this course, the editor, terminal, extensions, tests, and docs all feel like one working environment instead of separate tools."

Part 1: Project orientation 🧭

"The first thing I want you to notice is the project structure. Each topic is not just code. It has study notes, exercises, and tests. That means VS Code is not only where you type Ruby. It is also where you read the course."

"When you work through a topic, your eyes will move between markdown, Ruby files, and tests. So getting comfortable with the file tree and editor tabs matters more than fancy customization."

Part 1.5: The minimum VS Code basics 🪟

"I do not want to teach all of VS Code. I only want to teach the parts that remove friction from this course."

"So here are the essentials: Explorer, editor tabs, integrated terminal, Problems panel, command palette, and markdown preview."

"That is enough to work through the course calmly."

Part 2: Extensions come second, not first 🧩

"Students often start by installing many extensions. I want to show a stricter rule: install only what supports the real project lifecycle."

"The first extension I care about is Ruby LSP. The reason is not marketing or editor fashion. The real reason is navigation and diagnostics. When you can jump through classes and see feedback in the editor, the project becomes easier to read."

"The second extension is the Ruby debugger support through rdbg. This matters later when tests fail in ways that are hard to understand by reading alone."

"RuboCop support is useful too, but I want you to think of it as workflow support, not as the heart of the Ruby experience."

Part 3: VS Code and terminal are one workflow 🔗

"The most important mindset shift is this: VS Code does not replace the terminal. In a Ruby project, the editor and terminal are partners."

"So before doing anything else, I open the integrated terminal and check the runtime."

Suggested commands to speak while typing:

ruby -v
which ruby
bundle install

"This connects directly to Appendix A. If the Ruby version is wrong, the rest of the project becomes unreliable. So even inside VS Code, the first real habit is still environment awareness."

Part 4: Open a topic as a student would 📚

"Now I want to open one topic the way a student should actually use it."

"I start with the overview and guide, not with random code. Then I move to the example implementation. Then I open the test. This gives me the full learning loop: read, inspect, run, change, verify."

"That rhythm is more important than any shortcut key."

Part 5: Run the topic tests ✅

"Next I run the topic test script. This shows how the editor and terminal connect through the project conventions."

Suggested command:

./topic_10_rock_paper_scissors/run_topic_tests.sh

"The point is not just that the test passes. The point is that you can see the topic file, the test file, and the terminal output as one conversation."

Part 5.5: Tasks are convenience, not magic 🛠️

"Now I want to show the convenience layer. This repository includes VS Code tasks."

"I can run all tests, the current topic tests, or the current spec file from the command palette. But the important thing is that each task still wraps a normal project command. You should understand the command first and enjoy the shortcut second."

Part 6: Editor help is for navigation and confidence 🔎

"Now I want to show what the Ruby extension is doing for us."

"I can move between definitions. I can inspect names. If I introduce a typo, I can see feedback quickly. This reduces uncertainty. It does not remove the need to think, but it lowers the friction of reading and editing the project."

Part 7: Docs during the sprint, not after the sprint 📖

"When you forget how map or zip behaves, you do not need to leave your flow and open five browser tabs. Use ri in the terminal and the course notes in the editor."

Suggested commands:

ri Enumerable#map
ri Array#zip

"This is a habit I want you to build early: ask Ruby directly when you need precise method behavior."

Part 8: RuboCop is part of team life ✨

"At some point, passing tests is not enough. The code also has to be readable and consistent with team conventions. That is why RuboCop exists."

Suggested command:

bundle exec rubocop

"I do not want you to think of this as cosmetic. It is operational. It reduces noisy review comments and helps teams focus on logic."

Part 9: The debugger removes fear 🐞

"Students often avoid debuggers because they feel advanced. I want to normalize them."

"A debugger is not a sign that you failed. It is a sign that the runtime state is now the main thing you need to inspect."

"This is especially useful in our later topics: recursion, closures, SQLite queries, and iterative game state."

"The repository also includes a .vscode/launch.json file. So the run and debugging setup is not something each student has to invent from scratch."

Suggested narration during a recursion debug:

"Right now I am not guessing what the recursive call does. I am inspecting the actual current node, the next call, and the accumulated result. That is the value of the debugger."

Part 10: Close with the sprint loop 🔁

"I want to end by showing the full working rhythm. In a real Ruby project, your day usually looks like this:"

• check Ruby version
• sync dependencies
• run one test
• read docs if needed
• code in the editor
• lint
• debug if runtime behavior is confusing

"That is the real reason to learn the editor and these tools together. Not because each tool is exciting on its own, but because together they create a calm, repeatable development loop."

Closing line 🌱

"If you leave this recording remembering one thing, let it be this: VS Code is most useful when it helps you move through the Ruby project lifecycle with less friction, not when it tries to hide the lifecycle from you."