ภาคผนวก B: Ruby Workflow ใน VS Code

th/appendix_b_vscode_ruby_workflow

merged appendix page

วิธีเรียน Ruby แบบมองเห็นภาพใน VS Code

จุดประสงค์

ภาคผนวกนี้เป็น presenter kit สำหรับบทเรียนแบบ screen recording มันไม่ได้มีไว้สอน Ruby เพิ่ม แต่มันมีไว้ทำให้ผู้เรียนคุ้นกับการทำงานใน VS Code เมื่อมีทั้งโปรเจกต์ Ruby, Ruby extensions และเครื่องมือจาก command line ที่ถูกแนะนำไว้ใน Appendix A

เมื่อจบวิดีโอ ผมอยากให้ผู้เรียนรู้สึกว่า:

• "ผมรู้แล้วว่าฟีเจอร์ไหนของ VS Code สำคัญก่อน"
• "ผมรู้แล้วว่า Ruby extensions ตัวไหนมีประโยชน์ และเพราะอะไร"
• "ผมรู้แล้วว่า VS Code กับ terminal tools ทำงานร่วมกันอย่างไร"
• "ผมย้ายจากการตั้งโปรเจกต์ไปสู่งานแบบ sprint ได้ โดยไม่รู้สึกหลง"

แนวทางการสอน

วิดีโอควรเดินตามลำดับวงจรชีวิตเดียวกับ Appendix A:

1. เปิดโปรเจกต์
2. ยืนยัน Ruby environment
3. ติดตั้งหรือเปิดดู extensions
4. ใช้ integrated terminal สำหรับ setup ของโปรเจกต์
5. เดินดูไฟล์ Ruby และ tests
6. รัน test ของหนึ่งหัวข้อ
7. ใช้ docs และ lint feedback
8. ใช้ debugger
9. ผูกวิธีทำงานใน editor กลับไปสู่งานประจำวันแบบ sprint

สิ่งที่อยู่ในภาคผนวกนี้

• extensions_setup.md: extensions ของ VS Code ที่ควรติดตั้งก่อน และเหตุผล
• vscode_basics.md: ฟีเจอร์ขั้นต่ำของ VS Code ที่ผู้เรียนควรรู้ก่อน
• recording_storyboard.md: ลำดับสิ่งที่ควรแสดงบนหน้าจอ
• running_tests_in_vscode.md: การรัน tests ผ่าน terminal, tasks และ debugger
• talking_script.md: speaker notes และตัวอย่างคำบรรยาย
• slides.md: โครงสไลด์พร้อม diagram
• demo_checklist.md: เช็กลิสต์ก่อนอัดและก่อนเดโมสด
• recording_mode.md: วิธีทำให้ประสบการณ์ในวิดีโอดูสงบและอ่านง่าย

แก่นของข้อความที่ต้องการสื่อ

VS Code ไม่ได้มาแทนความรู้ Ruby มันกำลังให้พื้นที่ทำงานที่มองเห็นได้ ปลอดภัย และทำซ้ำ ได้ สำหรับวงจรชีวิตของโปรเจกต์ Ruby:

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

พื้นฐานของ VS Code สำหรับคอร์สนี้

จุดประสงค์

ผู้เรียนไม่จำเป็นต้องเรียน VS Code แบบเต็มหลักสูตรก่อนจะเรียน Ruby ได้ แต่พวกเขาต้อง มีความมั่นใจใน editor พอที่จะเดินผ่านคอร์สนี้ได้โดยไม่สะดุด

ไฟล์นี้ครอบคลุมเฉพาะฟีเจอร์ขั้นต่ำของ VS Code ที่ช่วยคอร์สนี้โดยตรง

1. เปิด repository เป็นโฟลเดอร์

สิ่งที่แนะนำ:

• File -> Open Folder...
• เลือกไดเรกทอรีรากของคอร์ส

เหตุผลที่สำคัญ:

• Explorer จะเห็นโครงสร้างการเรียนทั้งหมด
• integrated terminal จะเริ่มใน workspace ที่ถูกต้อง
• search, tasks และ debugging จะใช้ project-relative paths ได้ถูก

สถานการณ์จริง:

ถ้าผู้เรียนเปิดแค่ Ruby file เดียว แทนที่จะเปิดทั้งโฟลเดอร์ของโปรเจกต์ editor จะมองไม่เห็น รูปของโปรเจกต์ แล้ว search, test commands และ launch configurations จะยากขึ้นทันที

2. รู้จักเฉพาะ panels หลัก

ผู้เรียนควรรู้จัก:

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

ประโยคที่เหมาะกับการสอน:

"คุณไม่จำเป็นต้องรู้ VS Code ทุกส่วน คุณแค่ต้องตั้งหลักได้พอจะเดินไปมาระหว่างไฟล์ terminal, ข้อความแจ้งปัญหา และคำสั่งต่าง ๆ อย่างสงบ"

3. ใช้ Explorer เหมือนแผนที่ของการเรียน

เหตุผลที่สำคัญในคอร์สนี้:

• แต่ละหัวข้อมีทั้ง notes, code, answers และ tests
• ผู้เรียนควรมองหนึ่งหัวข้อเป็นหน่วยที่มีโครงสร้าง
• appendices เป็นส่วนหนึ่งของ workspace ไม่ใช่เอกสารแยกต่างหาก

การเดโมที่ดี:

• เปิด topic folder หนึ่งอัน
• ขยาย tests/
• เปิด overview.md, guide.md, example.rb และ spec file

4. ใช้ split editor แบบมีเจตนา

ตัวอย่างการใช้ที่ดี:

• notes อยู่ข้างหนึ่ง code อยู่อีกข้าง
• spec อยู่ข้างหนึ่ง implementation อยู่อีกข้าง
• markdown preview อยู่ข้างหนึ่ง raw markdown อยู่อีกข้าง

เหตุผลที่สำคัญ:

• คอร์สนี้ถูกออกแบบให้ผู้เรียนต้องเดินไปมาระหว่างการอ่านกับการเขียน
• split view ช่วยลดการสลับบริบท

5. เรียน command palette ตั้งแต่ต้น

สิ่งที่ควรใช้ผ่าน command palette:

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

เหตุผลที่สำคัญ:

• ผู้เรียนไม่จำเป็นต้องจำทุกเมนู
• VS Code จะใช้ง่ายขึ้นเมื่อคุ้นกับจุดเข้าหลักแบบค้นหาได้จุดเดียว

6. ใช้ integrated terminal เป็นส่วนหนึ่งของ editor

คอร์สนี้พึ่งคำสั่งใน terminal เป็นหลัก เช่น:

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

เพราะฉะนั้น terminal จึงไม่ได้แยกจากวิธีทำงานใน editor แต่มันเป็นส่วนหนึ่งของมัน

7. ใช้ Problems panel

เหตุผลที่สำคัญ:

• ปัญหาไวยากรณ์และ lint issues มักโผล่ขึ้นมาที่นี่
• panel นี้ช่วยให้ผู้เรียนขยับจาก "มีบางอย่างผิด" ไปสู่ "ไฟล์นี้ บรรทัดนี้ ต้องดูต่อ"

ประเด็นที่ควรสอน:

"Problems panel ไม่ใช่ที่สำหรับแก้ปัญหา มันคือที่สำหรับหาตำแหน่งของปัญหาให้เร็วขึ้น"

การตั้งค่า VS Code Extensions สำหรับคอร์สนี้

หลักคิดแกนกลาง

ใช้ extensions เท่าที่จำเป็นต่อวิธีทำงานจริงของคอร์ส

ผู้เรียน ไม่จำเป็น ต้องมี editor ที่แออัด พวกเขาต้องการวิธีทำงานที่เชื่อถือได้สำหรับ:

• อ่านไฟล์ Ruby ได้ชัด
• รัน tests
• เห็นข้อความแจ้งปัญหา
• format หรือตรวจ lint อย่างสม่ำเสมอ
• debug เมื่อพฤติกรรมตอน runtime เริ่มไม่ชัด

extensions หลักที่แนะนำ

1. Ruby LSP

เหตุผลที่สำคัญ:

• ทำให้ VS Code เข้าใจภาษา Ruby มากขึ้น
• ช่วยเรื่องการกระโดดไปยังจุดที่ประกาศไว้, ข้อความแจ้งปัญหา และการรับรู้โค้ด Ruby ใน editor
• รองรับการเขียนโค้ดในทุกหัวข้อของคอร์ส ตั้งแต่ classes ไปจนถึง lambdas และ SQLite

สิ่งที่ควรโชว์ในวิดีโอ:

• extension ถูกติดตั้งและเปิดใช้งานแล้ว
• editor รู้จัก .rb files อย่างถูกต้อง
• go-to-definition หรือ hover บน method/class
• ข้อความแจ้งปัญหาแสดงขึ้นใน editor

สถานการณ์จริง:

• ผู้เรียนลืมไปว่ามี class หรือ method หนึ่งถูกประกาศไว้ตรงไหน
• editor ช่วยให้พวกเขาเดินในโปรเจกต์ได้ โดยไม่ต้องค้นทีละไฟล์ด้วยมือ

2. VS Code rdbg / การรองรับ Ruby debugger

เหตุผลที่สำคัญ:

• ช่วย inspect พฤติกรรมตอน runtime เมื่อ tests fail หรือ behavior ชวนงง
• มีประโยชน์มากกับ recursion, closures, database queries และ state ของเกมที่ค่อย ๆ เปลี่ยน

สิ่งที่ควรโชว์ในวิดีโอ:

• เริ่ม debugger จากไฟล์ Ruby หรือจากคำสั่งรัน tests
• ตั้ง breakpoint
• inspect local variables

สถานการณ์จริง:

• ฟังก์ชัน recursive คืนค่าผิดเฉพาะตอน input ซ้อนกัน
• ผู้เรียนต้องการอะไรที่มากกว่า puts

3. RuboCop support ใน editor หรือใน terminal

เหตุผลที่สำคัญ:

• ให้ feedback เรื่อง style และ lint
• ช่วยย้ำว่าปกติโปรเจกต์ Ruby จะมีเครื่องมือคุมความสม่ำเสมอ

สิ่งที่ควรโชว์ในวิดีโอ:

• รัน bundle exec rubocop ใน terminal
• ถ้ามี integration ใน editor ก็อาจโชว์ข้อความแจ้งปัญหาแบบ inline เพิ่มได้

สถานการณ์จริง:

• โค้ดรันได้ แต่ทีมต้องการความสม่ำเสมอเรื่อง layout, naming และ style พื้นฐาน

extensions เสริมที่มีประโยชน์

เครื่องมือชุดนี้มีประโยชน์ แต่ควรแนะนำในฐานะ optional:

Markdown preview support

เหตุผล:

• คอร์สนี้มีไฟล์ .md จำนวนมาก
• ผู้เรียนสามารถ preview notes, appendices และ slides ได้ตรงใน VS Code

สิ่งที่ควรโชว์:

• เปิด markdown file หนึ่งไฟล์
• แบ่งหน้าจอแล้วเปิด preview

Git support extensions

เหตุผล:

• มีประโยชน์เมื่อผู้เรียนเริ่มแก้ไฟล์แบบเป็นเรื่องเป็นราว
• แต่ยังไม่จำเป็นในบทเรียนแรกที่เน้นวิธีทำงานแบบเห็นภาพ

ลำดับการติดตั้งที่แนะนำสำหรับบทเรียนนี้

1. Ruby LSP
2. Ruby debugger / rdbg
3. RuboCop support หรืออย่างน้อยการรัน RuboCop ผ่าน terminal
4. Markdown preview support ถ้าคุณอยากโชว์การอ่านโน้ตแบบเห็นภาพ

จุดสำคัญที่ควรสอน

อย่าบอกผู้เรียนว่า:

• "ติดตั้งทุกอย่างที่ดูเกี่ยวกับ Ruby ไปก่อน"

ให้บอกว่า:

• "ติดตั้งเท่าที่ช่วยวงจรชีวิตของโปรเจกต์จริง"

แบบนี้จะช่วยให้ editor ไม่กลายเป็นของที่ดูมหัศจรรย์แต่เปราะบาง

การรัน Tests ใน VS Code

หลักคิดแกนกลาง

สอนการรัน tests เป็นชั้น ๆ:

1. เริ่มจากคำสั่งใน terminal
2. ต่อด้วย VS Code tasks
3. ค่อยใช้ debugger configurations เมื่อจำเป็นต้อง inspect runtime state

ผู้เรียนควรเข้าใจคำสั่งจริงก่อนจะพึ่ง shortcut ของ editor

1. รัน tests ทั้งหมดจาก integrated terminal

./run_tests.sh

เหตุผลที่นี่ควรเป็นฐาน:

• มันตรงกับ flow ปกติของคอร์ส
• มันใช้ bootstrap logic ของโปรเจกต์เอง
• พฤติกรรมจะเหมือนกันทั้งในและนอก VS Code

2. รันหนึ่งหัวข้อจาก integrated terminal

./topic_10_rock_paper_scissors/run_topic_tests.sh

เหตุผลที่สำคัญ:

• คอร์สนี้สอนเป็นหน่วยเล็กขนาด sprint
• ผู้เรียนควรรู้สึกคุ้นกับการโฟกัสทีละหัวข้อ

3. รันหนึ่ง spec file ตรง ๆ

bundle exec rspec topic_14_functional_style_lambdas/tests/topic_14_functional_style_lambdas_spec.rb

เหตุผลที่สำคัญ:

• เหมาะเมื่อผู้เรียนกำลังโฟกัสที่ spec file เดียว
• เหมาะเมื่อกำลัง debug พฤติกรรมจุดเดียว

4. ใช้ VS Code tasks เพื่อความสะดวก

repository นี้มี .vscode/tasks.json

tasks ที่ควรเดโม:

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

วิธีรัน:

1. เปิด command palette
2. เลือก Tasks: Run Task
3. เลือก task ที่ต้องการ

เหตุผลที่สำคัญ:

• คำสั่งที่ทำซ้ำบ่อยจะหาง่ายขึ้น
• ขั้นตอนการทำงานดูน่ากลัวน้อยลงสำหรับผู้เริ่มต้น

5. ใช้ launch configurations เพื่อ debug

repository นี้มี .vscode/launch.json

launch configurations ที่ควรเดโม:

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

เหตุผลที่สำคัญ:

• การ debug ควรถูกมองว่าเป็นส่วนหนึ่งของงานปกติในโปรเจกต์ ไม่ใช่เครื่องมือระดับสูงพิเศษ

6. ลำดับที่แนะนำในการสอนผ่านวิดีโอ

1. รัน ./run_tests.sh
2. รัน script ของหนึ่งหัวข้อ
3. โชว์ Tasks: Run Task
4. โชว์ Debug Current Spec File

ลำดับนี้ช่วยให้เรื่องทั้งหมดยังเกาะอยู่กับโปรเจกต์จริง ไม่ใช่หลุดไปเป็นการกดปุ่มใน editor

เช็กลิสต์สำหรับเดโมและการอัดวิดีโอ

ก่อนเริ่มอัด

• เปิด VS Code ที่รากของคอร์ส
• ยืนยันว่า integrated terminal เริ่มต้นในไดเรกทอรีของโปรเจกต์
• ยืนยันว่า Ruby version ที่โปรเจกต์คาดหวังถูกเปิดใช้อยู่
• ยืนยันว่ามี extensions หลักครบ:
  • Ruby LSP
  • Ruby debugger / rdbg
  • RuboCop support ถ้าจะใช้
• เปิดหัวข้อที่เหมาะกับการเดโมไว้ล่วงหน้า 1 หรือ 2 หัวข้อ:
  • topic_10_rock_paper_scissors
  • topic_13_recursion_closures

คำสั่งใน terminal ที่ควรเตรียมไว้

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

จังหวะใน editor ที่ควรถ่ายให้เห็น

• การเดินไฟล์ผ่าน file tree
• markdown preview หรือการอ่าน markdown แบบแบ่งหน้าจอ
• กระโดดไปมาระหว่าง test กับ implementation
• หนึ่งจังหวะของ hover หรือ go-to-definition
• หนึ่งจังหวะที่รันผ่าน terminal ให้เห็นชัด
• หนึ่งจังหวะที่รัน task จาก command palette
• หนึ่งจังหวะง่าย ๆ ของ breakpoint/debug

ข้อแนะนำสำหรับเดโม debugger

ตัวเลือกที่เหมาะที่สุด:

• topic_13_recursion_closures
  • อธิบาย call stack และ state ของ recursion ได้ง่าย
• topic_12_sqlite_queries
  • เหมาะถ้าอยากโชว์การ inspect ตัวแปรรอบ query results

สิ่งที่ควรหลีกเลี่ยง

• ใช้เวลานานเกินไปกับ VS Code settings
• เปิด extension marketplace ไปเรื่อยระหว่างอัด
• แนะนำ optional tools จำนวนมาก ก่อนที่ flow หลักจะเริ่มชัด
• ทำให้การอัดวิดีโอกลายเป็นบทเรียน shell

สิ่งที่ผู้เรียนควรติดตัวกลับไป

• ลำดับการเริ่มใช้เครื่องมือที่ชัด
• ความกลัว integrated terminal ที่ลดลง
• ความคุ้นเคยกับ panels ขั้นต่ำของ VS Code
• การรู้ว่าการรัน tests ทำได้ทั้งผ่าน terminal, tasks และ debugger flow
• ความมั่นใจว่า VS Code รองรับวิธีทำงานของคอร์สนี้ได้อย่างสงบและเป็นระบบ

โหมดการอัดวิดีโอสำหรับบทเรียน VS Code

จุดประสงค์

วิดีโอที่ถูกต้องทางเทคนิค อาจดูตามยากได้เหมือนกัน ถ้าหน้าจอรก ตัวอักษรเล็กเกินไป หรือ ผู้สอนคอยย้าย panel ไปมาตลอดระหว่างอธิบาย

ไฟล์นี้เป็นคู่มือเชิงปฏิบัติ เพื่อให้การอัดวิดีโอดูสงบ อ่านง่าย และสอดคล้องกับเป้าหมายการ สอนของคอร์ส

1. ใช้สภาพ workspace ที่สะอาด

ก่อนอัด:

• ปิดไฟล์และ terminal ที่ไม่เกี่ยวข้อง
• เปิดเฉพาะโฟลเดอร์ของคอร์สนี้
• ขยายไว้แค่หนึ่งหรือสอง topic folders ไม่ใช่ทั้งต้นไม้
• หลีกเลี่ยง notification popups หรือ chat overlays

เหตุผล:

• ผู้เรียนควรโฟกัสกับวิธีทำงาน ไม่ใช่เสียงรบกวนทางสายตา

2. ทำตัวอักษรให้ใหญ่กว่าตอนเขียนโค้ดปกติ

ค่าตั้งต้นที่แนะนำ:

• editor font size ประมาณ 15
• integrated terminal font size ประมาณ 14
• เพิ่ม line height ขึ้นเล็กน้อย

เหตุผล:

• วิดีโอทำให้รายละเอียดถูกบีบ
• ผู้เรียนอาจดูผ่าน browser, laptop หรือที่ความละเอียดต่ำกว่าปกติ

.vscode/settings.json ของ repository นี้มีค่าตั้งต้นที่สงบใช้เป็นฐานได้อยู่แล้ว

3. ลดความรกของหน้าจอ

ตัวเลือกที่แนะนำ:

• ปิด minimap
• เปิด word wrap สำหรับ markdown
• อย่าเปิด side panels เยอะพร้อมกัน
• ให้เห็นแค่ Explorer และ terminal เมื่อต้องใช้

เหตุผล:

• ผู้เรียนควรเห็นโครงสร้างและการเคลื่อนไหว ไม่ใช่ dashboard ของ IDE ที่แน่นเกินไป

4. เปลี่ยน layout แบบนิ่งและคาดเดาได้

pattern ของ layout ที่ดีสำหรับคอร์สนี้:

• Explorer อยู่ซ้าย
• editor หลักอยู่กลาง
• terminal อยู่ใน editor area หรือ panel ด้านล่าง
• split editor แค่ตอนเทียบ guide/spec หรือ code/spec

หลีกเลี่ยง:

• ปรับขนาด panel ไปมาตลอด
• เปิดปิด panel หลายตัวเร็วเกินไป
• กระโดดข้าม tabs จำนวนมากในหนึ่งนาที

5. ใช้ theme ที่คาดเดาได้

คำแนะนำ:

• ใช้ theme ที่ contrast ดีแต่ไม่ลายตา
• อย่าใช้ color theme แปลกตาเพื่อการสอน

เหตุผล:

• ผู้เรียนควรได้เรียนวิธีทำงาน ไม่ใช่ต้องมานั่งถอดรหัสชุดสี

ถ้าคุณมี theme ที่ชอบอยู่แล้ว ก็ใช้ได้ ถ้า:

• comments อ่านออก
• markdown headings ชัด
• terminal output อ่านง่าย
• สีของ errors ดูออกชัด

6. zoom กับจังหวะการสอนสำคัญมาก

สิ่งที่แนะนำ:

• ถ้าจำเป็นให้ปรับ zoom ก่อนเริ่มอัด
• เลื่อนหน้าช้า ๆ ตอนอ่าน markdown
• เว้นจังหวะสั้น ๆ หลังจาก terminal output โผล่ขึ้นมา
• เปิดผลลัพธ์ค้างไว้นานพอให้ผู้เรียนตั้งหลักได้

เหตุผล:

• ผู้เรียนต้องใช้เวลาผูกการกระทำใน editor เข้ากับผลที่เกิดใน terminal

7. แสดงทีละหนึ่งไอเดีย

ลำดับที่ไม่ดี:

• เปิด extensions
• กระโดดไป terminal
• กระโดดไป launch config
• กระโดดไป markdown
• เปิด debugger

ลำดับที่ดีกว่า:

• อธิบายหนึ่งช่วง
• แสดงหนึ่งการกระทำ
• บอกว่ามันสำคัญเพราะอะไร
• ค่อยไปช่วงถัดไป

8. เช็กลิสต์ก่อนกดอัด

ก่อนกด record:

• ยืนยันว่าโปรเจกต์เปิดจากรากของคอร์ส
• ยืนยันว่า Ruby version ถูกต้อง
• ยืนยันว่า terminal เริ่มใน workspace
• ยืนยันว่า key extensions ถูกติดตั้งแล้ว
• ยืนยันว่า .vscode/tasks.json และ .vscode/launch.json อยู่ครบ
• ยืนยันว่าขนาดตัวอักษรอ่านได้ในความละเอียดของวิดีโอ
• เปิดไฟล์ที่จะเทียบกันไว้ล่วงหน้า

9. จังหวะที่ควร zoom ให้ผู้เรียนเห็นชัด

จังหวะที่เหมาะกับการเน้นภาพ:

• command palette ตอนรัน task
• integrated terminal ตอนรัน ./run_tests.sh
• debugger panel ตอน inspect state ของ recursion หรือ query
• markdown preview ตอนเชื่อม notes เข้ากับ code

10. จังหวะที่ควรพูดช้าลง

ควรชะลอเมื่อ:

• อธิบายว่าทำไม terminal commands ยังสำคัญ แม้อยู่ใน VS Code
• แสดงความต่างระหว่างการกดรัน task กับการเข้าใจคำสั่งจริง
• แนะนำ debugger
• ผูกวิธีทำงานของ editor กลับไปที่ sprint cycle

11. คำแนะนำสุดท้ายสำหรับผู้สอน

โทนที่ดีที่สุดของวิดีโอชุดนี้คือ:

• สงบ
• เป็นลำดับ
• ใช้งานได้จริง
• บอกเหตุผลของเครื่องมืออย่างชัดเจน

ผู้เรียนควรดูจบแล้วคิดว่า:

• "ผมตั้งค่านี้ได้"
• "ผมรู้แล้วว่าอะไรต้องมาก่อน"
• "ผมรู้แล้วว่าจะรัน tests และ debug ใน VS Code อย่างไร"

สิ่งนี้มีค่ามากกว่าการโชว์ลูกเล่นของ editor ทุกอย่างที่มี

Storyboard สำหรับการอัดวิดีโอ: VS Code Ruby Workflow

เป้าหมายของวิดีโอ

สร้าง screen recording หนึ่งชิ้นที่ช่วยให้ผู้เรียนรู้สึกคุ้นกับ VS Code ในฐานะบ้านหลัก ของการทำงานกับคอร์สนี้

นี่ไม่ใช่วิดีโอรีวิว extensions แต่มันคือเรื่องเล่าเชิงวิธีทำงานของโปรเจกต์

ความยาวที่แนะนำ

20 ถึง 30 นาที

Segment 1: เปิดโปรเจกต์และทำให้ผู้เรียนเห็นภาพรวม

สิ่งที่ควรทำบนหน้าจอ

• เปิด VS Code ที่รากของคอร์ส
• โชว์ file tree
• ชี้ให้เห็นสั้น ๆ ว่ามี:
  • topics
  • appendices
  • run_tests.sh

เป้าหมายการสอน

ผู้เรียนควรเห็น repository นี้เป็น workspace การเรียนที่มีโครงสร้าง ไม่ใช่กองไฟล์ที่สุ่มวางไว้

Segment 1.5: โชว์เฉพาะพื้นฐานของ VS Code ที่จำเป็น

สิ่งที่ควรทำบนหน้าจอ

• ชี้ให้เห็น Explorer
• ชี้ให้เห็น integrated terminal
• ชี้ให้เห็น Problems panel
• ใช้ command palette หนึ่งครั้ง
• preview markdown file หนึ่งไฟล์

เป้าหมายการสอน

ผู้เรียนควรรู้สึกว่ารู้ VS Code มากพอจะเรียนคอร์สนี้ต่อได้แล้ว

Segment 2: โชว์เฉพาะ extensions ขั้นต่ำที่มีประโยชน์

สิ่งที่ควรทำบนหน้าจอ

• เปิด Extensions sidebar
• โชว์ Ruby LSP
• โชว์ Ruby debugger extension / rdbg
• พูดถึง RuboCop support

เป้าหมายการสอน

ผู้เรียนควรเข้าใจว่า:

• ทำไมแต่ละ extension ถึงมีอยู่
• editor กำลังช่วยพยุงวิธีทำงาน ไม่ได้มาแทนความเข้าใจ

Segment 3: ผูก VS Code เข้ากับเครื่องมือใน Appendix A

สิ่งที่ควรทำบนหน้าจอ

• เปิด integrated terminal
• รัน:

ruby -v
which ruby
bundle install

เป้าหมายการสอน

ทำให้เห็นว่า VS Code ไม่ได้หมายถึง "ไม่ต้องใช้ terminal" แต่มันคือที่ซึ่ง terminal กับ editor ทำงานร่วมกัน

Segment 4: เปิดหนึ่งหัวข้อเหมือนที่ผู้เรียนควรเปิดจริง

สิ่งที่ควรทำบนหน้าจอ

• เปิดหนึ่งหัวข้อ เช่น topic_10_rock_paper_scissors
• โชว์:
  • overview.md
  • guide.md
  • example.rb
  • tests/...

เป้าหมายการสอน

ผู้เรียนควรเห็นจังหวะการเรียน:

• อ่าน
• เปิดดูโค้ด
• เปิดดู tests
• รัน tests
• ลงมือทำเป็น sprint

Segment 5: รัน test ของหนึ่งหัวข้อจาก terminal

สิ่งที่ควรทำบนหน้าจอ

• รัน:

./topic_10_rock_paper_scissors/run_topic_tests.sh

หรือหัวข้ออื่นที่คุณเลือก

เป้าหมายการสอน

ผู้เรียนควรเชื่อมไฟล์ที่เห็นใน editor เข้ากับพฤติกรรมที่เห็นใน terminal ได้

Segment 5.5: โชว์วิธีทำงานแบบใช้ tasks

สิ่งที่ควรทำบนหน้าจอ

• เปิด command palette
• เลือก Tasks: Run Task
• รัน:
  • Run All Course Tests
  • Run Current Topic Tests
  • Run Current Spec File

เป้าหมายการสอน

ผู้เรียนควรเข้าใจว่า tasks เป็นตัวห่อคำสั่งของโปรเจกต์เพื่อให้สะดวกขึ้น ไม่ใช่เวทมนตร์

Segment 6: ใช้การเดินโค้ดใน editor และดูข้อความแจ้งปัญหา

สิ่งที่ควรทำบนหน้าจอ

• กระโดดไปมาระหว่าง example กับ test
• hover หรือ navigate ไปที่ class/method
• ถ้าทำได้ให้สร้าง typo เล็ก ๆ ชั่วคราวแล้ว undo เพื่อให้เห็นข้อความแจ้งปัญหา

เป้าหมายการสอน

ผู้เรียนควรรู้สึกว่า editor ช่วยให้เดินและ inspect ได้ ไม่ได้มีไว้พิมพ์อย่างเดียว

Segment 7: ใช้ ri และ markdown docs ระหว่างลงมือทำ

สิ่งที่ควรทำบนหน้าจอ

• ใน terminal:

ri Enumerable#map
ri Array#zip

• ใน editor:
  • เปิด cheatsheet.md ของหัวข้อหนึ่ง
  • preview markdown file หนึ่งไฟล์

เป้าหมายการสอน

ผู้เรียนควรเห็นว่า:

• editor คือที่อ่านเอกสารของโปรเจกต์
• terminal คือที่ถาม Ruby เรื่อง API อย่างแม่นยำ

Segment 8: โชว์ RuboCop ในฐานะเครื่องมือของวิธีทำงาน

สิ่งที่ควรทำบนหน้าจอ

• รัน:

bundle exec rubocop

• ถ้ามี integration ใน editor จะโชว์ inline lint feedback เพิ่มก็ได้

เป้าหมายการสอน

ผู้เรียนควรเข้าใจว่าเครื่องมือคุม style เป็นส่วนหนึ่งของชีวิตปกติในทีม Ruby

Segment 9: โชว์ debugger กับตัวอย่างที่มีความหมาย

เป้าหมายที่เหมาะกับการเดโมที่สุด

• recursion จาก topic_13_recursion_closures
• flow ของ SQLite query จาก topic_12_sqlite_queries

สิ่งที่ควรทำบนหน้าจอ

• ตั้ง breakpoint
• รัน debug
• inspect locals
• step ไปหนึ่งหรือสองครั้ง

เป้าหมายการสอน

ผู้เรียนควรกลับออกไปพร้อมความรู้สึกว่า:

• "ผมไม่จำเป็นต้องกลัว debugger"
• "ถ้าพฤติกรรมตอน runtime ชวนงง ผมมีเครื่องมือเอาไว้เปิดดู"

และควรโชว์สั้น ๆ ด้วยว่า:

• .vscode/launch.json อยู่ตรงไหน
• มี configuration อย่าง Debug Current Spec File

Segment 10: ปิดท้ายด้วย sprint loop

สิ่งที่ควรทำบนหน้าจอ

• เปิด appendix_a_project_lifecycle/sprint_flow.md
• สรุปเป็นลำดับ:
  • เช็ก runtime
  • sync dependencies
  • รันหนึ่ง test
  • เขียนโค้ด
  • เปิด docs
  • lint
  • debug ถ้าจำเป็น

เป้าหมายการสอน

ผูก VS Code กลับเข้าหาจังหวะการพัฒนาที่ใหญ่กว่าของคอร์ส

โครงสไลด์: VS Code Ruby Workflow

โครงสไลด์ชุดนี้ตั้งใจให้สั้น เพราะตัว screen recording ควรเป็นตัวสอนหลัก ส่วนสไลด์มีไว้ ช่วยเชื่อมแต่ละช่วง

Slide 1: Title

จาก editor ว่าง ๆ ไปสู่ Ruby Sprint Workflow

Subtitle:

• VS Code, Ruby extensions และวงจรชีวิตของโปรเจกต์จริง

ประเด็นที่ผู้พูดควรเน้น:

• นี่ไม่ใช่วิดีโอพาทัวร์ editor
• แต่มันคือบทเรียนเพื่อทำให้วิธีทำงานชัด

Slide 2: เรื่องจริงที่ต้องเดินผ่าน

ข้อความ:

• 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 กับ terminal เป็นคู่กัน

ข้อความ:

• VS Code ไม่ได้มาแทน terminal
• terminal คือที่ที่ความจริงของโปรเจกต์ Ruby ถูกตรวจสอบ

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 ข้อความแจ้งปัญหา"]

Slide 4: extensions ขั้นต่ำที่มีประโยชน์

ข้อความ:

• Ruby LSP
• Ruby debugger / rdbg
• RuboCop support
• markdown support ถ้าจำเป็น

Diagram:

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

Slide 5: ผู้เรียนควรเปิดหนึ่งหัวข้ออย่างไร

ข้อความ:

• overview.md
• guide.md
• example.rb
• tests/...
• รัน 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: Tests รันใน VS Code อย่างไร

ข้อความ:

• terminal มาก่อน
• tasks มาทีหลัง
• debugger ใช้เมื่อ runtime state สำคัญ

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 อยู่กลาง sprint ไม่ได้อยู่หลัง sprint

ข้อความ:

• project docs อยู่ใน editor
• Ruby docs เปิดผ่าน 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: เมื่อโปรเจกต์เริ่มโต

ข้อความ:

• rake สำหรับงานที่ทำซ้ำ
• rubocop สำหรับความสม่ำเสมอ
• rdoc และ yard สำหรับเอกสาร
• rdbg สำหรับดู runtime

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: ไฟล์ config ของโปรเจกต์ช่วยพยุงวิธีทำงาน

ข้อความ:

• .vscode/tasks.json
• .vscode/launch.json
• เป็นวิธีทำงานร่วมของโปรเจกต์ ไม่ใช่เวทมนตร์ส่วนตัวของใครคนหนึ่ง

Slide 8: Sprint loop สุดท้าย

ข้อความ:

• เช็ก runtime
• sync dependencies
• รันหนึ่ง test
• เขียนโค้ด
• เปิด docs
• lint
• debug ถ้าจำเป็น
• ทำซ้ำ

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

ข้อความ:

• editor ไม่ใช่บทเรียน
• วิธีทำงานต่างหากคือบทเรียน
• ความคุ้นมือเกิดจากการทำซ้ำ ไม่ใช่จากการจำทุกคำสั่ง

สคริปต์พูด: การอัดวิดีโอ VS Code Ruby Workflow

เปิดเรื่อง

"ในวิดีโอนี้ ผมไม่ได้พยายามสอนไวยากรณ์ Ruby เพิ่ม แต่ผมกำลังพยายามทำให้โปรเจกต์ Ruby ดูคุ้นมือและสบายขึ้นเมื่อทำงานใน VS Code เป้าหมายคือให้เวลาคุณเปิดคอร์สนี้ขึ้นมา editor, terminal, extensions, tests และ docs ดูเหมือนเป็น environment เดียวกัน ไม่ใช่ของหลายชิ้น ที่แยกขาดกัน"

Part 1: ทำให้เห็นภาพของโปรเจกต์

"อย่างแรกที่ผมอยากให้คุณสังเกตคือโครงสร้างของโปรเจกต์ แต่ละหัวข้อไม่ได้มีแค่โค้ด มันมี ทั้งโน้ต แบบฝึกหัด และ tests ด้วย นั่นแปลว่า VS Code ไม่ได้เป็นแค่ที่พิมพ์ Ruby แต่มัน ยังเป็นที่ที่คุณอ่านคอร์สนี้ด้วย"

"เวลาเรียนหนึ่งหัวข้อ สายตาของคุณจะไปมาระหว่าง markdown, Ruby files และ tests เพราะฉะนั้นการคุ้นกับ file tree และ editor tabs จึงสำคัญกว่าการปรับแต่งหวือหวา"

Part 1.5: พื้นฐานขั้นต่ำของ VS Code

"ผมไม่ได้อยากสอน VS Code ทุกอย่าง ผมอยากสอนเฉพาะส่วนที่ช่วยลดแรงเสียดทานของคอร์สนี้"

"สิ่งที่จำเป็นจริง ๆ มีแค่ Explorer, editor tabs, integrated terminal, Problems panel, command palette และ markdown preview"

"เท่านี้ก็พอสำหรับการเรียนคอร์สนี้อย่างสงบแล้ว"

Part 2: extensions มาทีหลัง ไม่ได้มาก่อน

"ผู้เรียนจำนวนมากเริ่มด้วยการติดตั้ง extensions เยอะมาก แต่ผมอยากเสนอหลักที่เข้มกว่า: ติดตั้งเท่าที่ช่วยวงจรชีวิตจริงของโปรเจกต์"

"extension แรกที่ผมแคร์คือ Ruby LSP เหตุผลไม่ใช่เรื่องแฟชั่นของ editor แต่เป็นเรื่อง การเดินโค้ดและข้อความแจ้งปัญหา พอคุณกระโดดตาม class และเห็น feedback ใน editor ได้ โปรเจกต์ก็จะอ่านง่ายขึ้น"

"extension ตัวที่สองคือ Ruby debugger ผ่าน rdbg มันเริ่มสำคัญเมื่อ tests fail ในแบบ ที่อ่านโค้ดอย่างเดียวแล้วยังไม่เห็น"

"RuboCop support ก็มีประโยชน์เหมือนกัน แต่ผมอยากให้คุณมองมันเป็นตัวช่วยเรื่องวิธีทำงาน ไม่ใช่หัวใจของประสบการณ์ Ruby"

Part 3: VS Code กับ terminal คือวิธีทำงานเดียวกัน

"การปรับวิธีคิดที่สำคัญที่สุดคือ VS Code ไม่ได้มาแทน terminal ในโปรเจกต์ Ruby editor กับ terminal เป็นคู่กัน"

"เพราะฉะนั้นก่อนทำอย่างอื่น ผมจะเปิด integrated terminal แล้วเช็ก runtime ก่อน"

คำสั่งที่พูดพร้อมพิมพ์:

ruby -v
which ruby
bundle install

"ตรงนี้เชื่อมกับ Appendix A โดยตรง ถ้า Ruby version ผิด ทุกอย่างถัดจากนั้นจะเริ่มไม่น่า เชื่อถือ เพราะฉะนั้นต่อให้อยู่ใน VS Code นิสัยแรกก็ยังเป็นเรื่อง environment awareness"

Part 4: เปิดหนึ่งหัวข้อเหมือนนักเรียนจริง

"ตอนนี้ผมอยากเปิดหนึ่งหัวข้อในแบบที่ผู้เรียนควรใช้จริง"

"ผมเริ่มจาก overview กับ guide ไม่ได้เริ่มจากโค้ดสุ่ม ๆ จากนั้นค่อยไปที่ example implementation แล้วค่อยเปิด test แบบนี้เราจะได้วงจรการเรียนครบ: อ่าน เปิดดู รัน แก้ แล้วตรวจซ้ำ"

"จังหวะนี้สำคัญกว่าการจำ shortcut keys มาก"

Part 5: รัน topic tests

"ต่อไปผมจะรัน test script ของหัวข้อนี้ เพื่อให้เห็นว่า editor กับ terminal เชื่อมกันผ่าน กติกาของโปรเจกต์อย่างไร"

คำสั่งที่แนะนำ:

./topic_10_rock_paper_scissors/run_topic_tests.sh

"ประเด็นไม่ใช่แค่ว่า test ผ่าน แต่คือคุณเห็นไฟล์หัวข้อ เห็น test file และเห็น output ใน terminal เป็นบทสนทนาเดียวกัน"

Part 5.5: Tasks คือความสะดวก ไม่ใช่เวทมนตร์

"ตอนนี้ผมอยากโชว์ชั้นของความสะดวก repository นี้มี VS Code tasks ให้แล้ว"

"ผมสามารถรัน all tests, current topic tests หรือ current spec file จาก command palette ได้ แต่สิ่งสำคัญคือ task พวกนี้ก็ยังห่อคำสั่งปกติของโปรเจกต์อยู่ดี คุณควรเข้าใจ คำสั่งก่อน แล้วค่อยชอบ shortcut ทีหลัง"

Part 6: ความช่วยเหลือจาก editor มีไว้เพื่อเดินและ inspect

"ตอนนี้ผมอยากให้เห็นว่า Ruby extension กำลังช่วยอะไรเรา"

"ผมกระโดดตาม definition ได้ inspect ชื่อได้ ถ้าผมทำ typo เล็ก ๆ ก็เห็น feedback ได้เร็ว สิ่งนี้ไม่ได้ทำให้เราไม่ต้องคิด แต่มันลดแรงเสียดทานของการอ่านและแก้โค้ด"

Part 7: Docs อยู่กลาง sprint ไม่ได้อยู่หลัง sprint

"ถ้าคุณลืมว่า map หรือ zip ทำงานยังไง คุณไม่จำเป็นต้องออกจาก flow แล้วไปเปิด browser ห้าหน้า ให้ใช้ ri ใน terminal แล้วอ่านโน้ตของคอร์สใน editor"

คำสั่งที่แนะนำ:

ri Enumerable#map
ri Array#zip

"นี่คือนิสัยที่ผมอยากให้คุณฝึกตั้งแต่ต้น: ถาม Ruby ตรง ๆ เมื่อต้องการรู้พฤติกรรมของ method อย่างแม่นยำ"

Part 8: RuboCop เป็นส่วนหนึ่งของชีวิตในทีม

"พอถึงจุดหนึ่ง การที่ tests ผ่านอย่างเดียวไม่พอ โค้ดยังต้องอ่านง่ายและสอดคล้องกับแนวทาง ของทีมด้วย นี่คือเหตุผลที่ RuboCop มีอยู่"

คำสั่งที่แนะนำ:

bundle exec rubocop

"ผมไม่อยากให้คุณคิดว่านี่เป็นเรื่องเครื่องสำอาง มันเป็นเรื่องเชิงปฏิบัติการ เพราะมันช่วยตัด review comments ที่ไม่จำเป็นออกไป"

Part 9: debugger ช่วยลดความกลัว

"ผู้เรียนมักหลีกเลี่ยง debugger เพราะรู้สึกว่ามันเป็นของระดับสูง ผมอยากทำให้มันเป็นเรื่องปกติ"

"debugger ไม่ได้แปลว่าคุณทำพลาด แต่มันแปลว่าตอนนี้สิ่งสำคัญที่สุดคือการดู runtime state"

"เรื่องนี้มีประโยชน์มากในหัวข้อหลัง ๆ ของเรา เช่น recursion, closures, SQLite queries และ state ของเกมที่ค่อย ๆ เปลี่ยน"

"repository นี้ยังมี .vscode/launch.json ให้ด้วย เพราะฉะนั้นผู้เรียนไม่ต้องประดิษฐ์ setup ของการรันและ debug เองตั้งแต่ต้น"

ตัวอย่างคำพูดตอน debug recursion:

"ตอนนี้ผมไม่ได้เดาว่า recursive call ทำอะไรอยู่ ผมกำลังดู node ปัจจุบัน ดู call ถัดไป และดูผลสะสมจริง ๆ นี่คือคุณค่าของ debugger"

Part 10: ปิดด้วย sprint loop

"ผมอยากจบด้วยการดึงทุกอย่างกลับมาเป็นจังหวะการทำงานจริง ในโปรเจกต์ Ruby วันปกติ ของคุณมักเป็นแบบนี้"

• เช็ก Ruby version
• sync dependencies
• รันหนึ่ง test
• เปิด docs ถ้าจำเป็น
• เขียนโค้ดใน editor
• lint
• debug ถ้าพฤติกรรมตอน runtime ยังชวนงง

"นี่คือเหตุผลที่เราควรเรียน editor กับเครื่องมือพวกนี้ไปพร้อมกัน ไม่ใช่เพราะแต่ละตัวน่าตื่นเต้น ด้วยตัวมันเอง แต่เพราะเมื่อรวมกันแล้ว มันสร้าง development loop ที่สงบและทำซ้ำได้"

ประโยคปิด

"ถ้าคุณจะจำจากวิดีโอนี้เพียงอย่างเดียว ผมอยากให้จำสิ่งนี้: VS Code มีประโยชน์ที่สุดเมื่อมัน ช่วยให้คุณเดินผ่านวงจรชีวิตของโปรเจกต์ Ruby ได้ด้วยแรงเสียดทานที่น้อยลง ไม่ใช่เมื่อมันพยายาม ซ่อนวงจรนั้นจากคุณ"