ภาพหน้าจอที่อัปเดตตัวเอง

• เป็นเวิร์กโฟลว์ที่จับภาพหน้าจอโดยอัตโนมัติจากเว็บแอปพลิเคชันที่กำลังรันอยู่ และอัปเดตไปพร้อมกับการบิลด์เอกสารช่วยเหลือ ทำให้รูปภาพในเอกสารถูกเก็บไว้ในสถานะล่าสุดได้ง่ายแม้หลัง UI เปลี่ยน
• คอมเมนต์ SCREENSHOT ใน Markdown จะเก็บคำสั่งอย่าง path เป้าหมาย วิธีจับภาพ และ CSS selector แล้วในขั้นตอนบิลด์จะอ่านข้อมูลเหล่านี้เพื่อนำไปเติมเป็นรูปภาพจริง
• Rake task จะรัน headless Chrome ผ่าน Capybara และ Cuprite โดยจัดกลุ่มงานตามทีม ล็อกอินครั้งเดียวแล้ววนหลาย URL เพื่อจับภาพ
• การจับภาพรองรับ 3 โหมดคือ element, full_page, viewport และมีตัวเลือกอย่าง click, wait, crop, torn, hide เพื่อควบคุมทั้ง UI ที่ถูกเปิดอยู่หรือองค์ประกอบที่ไม่ต้องการ
• เพียงรัน rails manual:build ครั้งเดียว ก็จะสร้างภาพหน้าจอและบิลด์หน้าช่วยเหลือไปพร้อมกัน ทำให้ปรับโค้ดและเอกสารให้อยู่ในPR หรือ commit เดียวกันได้ง่าย และลดแรงเสียดทานจากการจับภาพและครอปด้วยมืออย่างมาก

---

แนวทางภาพหน้าจอที่อัปเดตตัวเอง

• ศูนย์ช่วยเหลือของ Jelly ถูกออกแบบให้จับภาพหน้าจออัตโนมัติจากเว็บแอปพลิเคชันที่กำลังทำงานอยู่ และอัปเดตร่วมกันทุกครั้งที่บิลด์ใหม่
• เอกสารถูกเขียนด้วย Markdown และอิงจากบทความ Self-updating screenshots โดยแปลงเป็น HTML ด้วย Redcarpet แล้วเรนเดอร์เป็น ERB view ของแอป Rails
• ภายใน Markdown จะมีคอมเมนต์ SCREENSHOT ซึ่งใช้เก็บคำสั่งอย่าง path เป้าหมาย วิธีจับภาพ และ CSS selector
  • <!-- SCREENSHOT: acme-tools/inbox | element | selector=#inbox-brand-new-section -->
  • แท็กภาพที่อยู่ถัดลงมาทันทีจะถูกใช้เป็นตำแหน่งสำหรับใส่ผลลัพธ์
• เมื่อสีของ UI ตำแหน่งปุ่ม หรือข้อความเปลี่ยนไปเพียงเล็กน้อย ภาพหน้าจอในเอกสารเดิมก็มักจะล้าสมัยได้ง่าย แต่เวิร์กโฟลว์นี้ช่วยลดภาระการอัปเดตแบบแมนนวลได้

ไปป์ไลน์การจับภาพและผลต่อการดูแลรักษา

• ภายในระบบ Rake task จะรัน headless Chrome ผ่าน Capybara และ Cuprite เพื่อสแกนคอมเมนต์ SCREENSHOT ในไฟล์ Markdown ทั้งหมด
• งานจับภาพหน้าจอจะถูกจัดกลุ่มตามทีม และภายในทีมเดียวกันจะล็อกอินเพียงครั้งเดียวก่อนวนเข้า URL หลายรายการ
• โหมดการจับภาพที่รองรับมี 3 แบบ
  • element: จับภาพ DOM element เฉพาะตาม CSS selector
  • full_page: จับภาพทั้งหน้า และถ้าจำเป็นสามารถตัดตามความสูงได้
  • viewport: จับเฉพาะพื้นที่ที่มองเห็นอยู่ในหน้าต่างเบราว์เซอร์
• มีตัวเลือกรายละเอียดอย่าง click, wait, crop จึงสามารถจับหน้าจอหลังคลิกปุ่มเพื่อเปิดสถานะบางอย่าง หรือหลังแอนิเมชันจบได้โดยอัตโนมัติ
  • <!-- SCREENSHOT: nectar-studio/manage/rules | full_page | click=".rule-create-button" wait=200 crop=0,800 -->
  • จะทำงานโดยกดปุ่มเพื่อเปิดฟอร์ม รอ 200ms แล้วครอปจับภาพเฉพาะพื้นที่ที่กำหนด
• ยังมีตัวเลือกเพิ่มเติมคือ torn และ hide
  • torn ใช้ CSS clip-path เพื่อสร้างเอฟเฟ็กต์ขอบกระดาษฉีก
  • hide ใช้ซ่อนองค์ประกอบชั่วคราว เช่น dev toolbar หรือ cookie banner ที่ไม่ควรแสดงบนหน้าจอ
• ไปป์ไลน์ทั้งหมดรันได้ด้วยคำสั่งเดียวคือ rails manual:build ซึ่งจะจัดการทั้งการจับภาพหน้าจอทั้งหมดและการบิลด์หน้าช่วยเหลือพร้อมกัน
• ซอร์สเอกสารถูกจัดไว้ใต้ public/manual/ แยกเป็นแต่ละหมวด เช่น basics, setup, advanced
• ในขั้นตอนบิลด์ ไฟล์ Markdown เหล่านี้จะถูกแปลงเป็น ERB view ใต้ app/views/help/ พร้อมสร้าง breadcrumb และ section navigation ไปด้วย
• การพัฒนาฟีเจอร์และการอัปเดตศูนย์ช่วยเหลือสามารถจัดการร่วมกันในโค้ดเบสเดียว ทำให้รักษาการซิงก์ระหว่างโค้ดกับเอกสารไว้ใน PR เดียวกันหรือ commit เดียวกันได้ง่ายขึ้น
• กรณีพิเศษอย่างองค์ประกอบที่ต้องเลื่อนจอ ป๊อปโอเวอร์ที่ต้องคลิกก่อนจึงเปิด หรือการครอปเพื่อหลีกเลี่ยงส่วนที่ไม่ต้องการ เป็นงานที่ต้องใช้เวลาในการทำเพิ่ม แต่เมื่อสร้างเสร็จแล้วก็ทำให้มีการอัปเดตศูนย์ช่วยเหลือได้ถี่ขึ้นมาก
• เพียงแค่เปลี่ยน UI รันบิลด์อีกครั้ง แล้ว commit ผลลัพธ์ ก็สามารถทำให้ภาพหน้าจออัปเดตล่าสุดอยู่เสมอได้ ทำให้แรงเสียดทานจากการจับภาพและครอปด้วยมือแทบหายไป

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันก็เพิ่ม .#screenshots derivation ที่คล้ายกันไว้เหมือนกัน ต้นทุนการตั้งค่าแรกเริ่มสูงหน่อย แต่หลังจากนั้นแทบไม่ต้องดูแลรักษาเลย
  ในเมื่อสร้างสกรีนช็อตด้วยโปรแกรมอยู่แล้ว ก็ทำทั้งสองเวอร์ชันของแอปทั้ง light/dark theme ไปพร้อมกัน แล้วสลับให้ตรงกับ prefers-color-scheme: dark ได้เลย
  องค์ประกอบแบบนี้ใช้ได้ดีใน GitHub README ด้วย: https://github.com/CyberShadow/CyDo#readme
  • เห็นด้วยกับวิธีนี้มาก
    ฝั่งแอปมือถือ ฉันให้ Nix เปิด Android emulator แบบใช้ครั้งเดียวเพื่อสร้างสกรีนช็อตล่าสุด โดยไม่ต้องตั้งค่าล่วงหน้า และไม่เหลือข้อมูลค้างหลังรันเสร็จ
    สำหรับฉัน การตั้งค่าเองก็ไม่ได้ยากขนาดนั้น สิ่งที่ยากกว่าคือการคิดไอเดีย และโค้ด Nix ก็ให้ LLM ที่ชอบช่วยเขียนให้ได้ในรอบเดียว
    การอัปเดตสกรีนช็อตด้วยมือนั้นไม่ใช่งานที่ทรหดที่สุดในโลก แต่ flow แบบ upload-apk + take-screenshot + transfer-back-to-PC + edit มันน่ารำคาญแบบจุกจิกอยู่เสมอ จนสุดท้ายแทบไม่ค่อยทำเลย
• บนมือถือจำเป็นต้องมี การเลื่อนแนวนอนสำหรับตัวอย่างโค้ด
  ถึงจะเดาจากบริบทได้คร่าว ๆ แต่ก็ยังไม่สะดวกอยู่ดี
• อันนี้มีประโยชน์มากสำหรับ โปรเจ็กต์มือถือ
  App Store บังคับให้มีสกรีนช็อต และต้องสร้างภาพตามจำนวนขนาดหน้าจอและจำนวนภาษาที่แปลไว้ เลยยุ่งยากได้เร็วมาก
  เมื่อก่อนฉันเคยเขียนสคริปต์เองสำหรับเรื่องนี้ และตอนนี้เครื่องมืออย่าง Fastlane เช่น https://fastlane.tools/ ช่วยได้มาก
  ฉันก็ใช้ Fastlane กับเกม logic puzzle ของฉันชื่อ Nonoverse และดูสกรีนช็อตตัวอย่างได้ในหน้า App Store: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
  แม้แต่วิดีโอ App Preview ก็ทำให้บันทึกอัตโนมัติได้ รวมหลายฉากไว้ด้วย และถ้ามีคนสนใจฉันคิดว่านี่เป็นหัวข้อที่น่าเขียนอธิบายแยกต่างหาก
  • ฟังดูน่าสนใจมาก แต่ยังจับภาพไม่ค่อยได้ว่านี่เป็น บริการเสียเงิน หรือเป็นแอป OS ที่รันบนเครื่อง
• เจ๋งมาก
  เกมแคชชวลเล็ก ๆ ที่ฉันทำด้วย vibe coding มักเริ่มจากการที่ตัวแอปรองรับการรันแบบเฮดเลสผ่าน CLI ได้เสมอ พร้อมการเรนเดอร์ texture นอกจอ คำสั่งจับสกรีนช็อต และการวัดประสิทธิภาพ
  ใช้เวลาเพิ่มสิ่งนี้เข้าไปแทบไม่มาก แถมยังเปิดทางให้อะเจนต์ทำ UI automation และตรวจดูจุดสำคัญต่าง ๆ ได้ด้วย
  เพราะแบบนี้เลยทำให้ง่ายมากที่จะให้อะเจนต์เป็นคนอัปเดตสกรีนช็อต
  ถึงจะยังไม่เนี้ยบเท่าการฝังเข้าไปในขั้นตอน build แบบสมบูรณ์ แต่ตอนนี้ก็คิดจะเพิ่มส่วนนั้นเหมือนกัน
  • ฉันก็ทำเหมือนกันเป๊ะ
    มีทั้ง argument ของ CLI สำหรับ offscreen screenshot path กับ world pos/camera view vector และยังรัน benchmark แบบสคริปต์ด้วยฟอร์แมตอินพุตแบบข้อความ
    ฟอร์แมตนี้ประกอบด้วยหลายบรรทัดของเซกเมนต์ที่มีชื่อ ความยาว n game ticks ต่อเซกเมนต์ และอินพุตควบคุมของแต่ละเซกเมนต์
    ฉันใช้สิ่งนี้บ่อยมากเวลา A/B test ภาพและประสิทธิภาพระหว่างทำโค้ดเกม
  • อยากรู้ว่าจะช่วยแชร์ลิงก์เกมแคชชวลเหล่านี้ได้ไหม
    ฉันเองก็สนใจมากว่า vibe coding ทำให้การพัฒนาเกมง่ายขึ้นแค่ไหน
    สมัย Adobe Flash วงการเกมอินดี้คึกคักมากจริง ๆ และหลังจากนั้นแทบไม่มีอะไรแตะระดับความง่ายในการพัฒนาแบบนั้นได้
    vibe coding ดูเหมือนเป็นเครื่องมือแรกที่ก้าวข้ามระดับนั้นได้
  • คำว่า ใช้เวลาเพิ่มสิ่งนี้เข้าไปแทบไม่มาก นั้นขึ้นอยู่กับกรณีเหมือนกัน
    เลยอยากรู้ว่าใช้ เอนจิน อะไร
• ยอดมาก
  ฉันชอบเป็นพิเศษที่สามารถใส่ คำประกาศสกรีนช็อต แบบอินไลน์ไว้ในเอกสาร Markdown ได้
  สำหรับแอปเดสก์ท็อปของฉัน ฉันทำโซลูชันที่สร้างสกรีนช็อตหลายภาษาและหลายโหมด light/dark ลด noise และใส่กรอบหน้าต่าง Windows/macOS ให้ด้วย
  ฉันสรุปไว้ที่นี่: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
  ตอนนี้มันยังเป็นสคริปต์แยกต่างหาก เลยดูแลรักษาค่อนข้างน่าปวดหัว แต่คงต้องลองดูการรวมมันเข้าไปเป็นส่วนหนึ่งของ markdown/mdx
  ได้แรงบันดาลใจดีมาก
• ของแบบนี้จำเป็นบ่อยจริง ๆ
  ถึงขั้นเอาไปใช้เป็นมีมแนว ผลงานชิ้นเยี่ยมที่สุด X ที่ไม่มีใครสังเกตเห็น ได้เลย
• อันนี้ดีมาก
  https://github.com/zombocom/rundoc ที่ฉันทำก็มีฟังก์ชันคล้ายกัน
  จุดประสงค์หลักคือ การสร้างบทสอน ดังนั้นมันจะใส่ผลลัพธ์ของคำสั่งที่รันกลับเข้าไปในเอกสารด้วย
• ตรงนี้อาจใช้แนวทาง real-time rendering ได้เหมือนกัน
  เช่นฝัง live preview ของเครื่องมือไว้ในกรอบสี่เหลี่ยม
  ถ้าเครื่องมือเบาพอ มันอาจเหมาะที่สุดทั้งในเชิงภาพ และยังสะท้อนค่าการเรนเดอร์อย่างการตั้งค่า accessibility ของเบราว์เซอร์หรือส่วนเสริมของผู้ใช้ได้ตรง ๆ ด้วย
  • หรือจะ build HTML แบบ static build ไปเลยก็ได้
    เอกสารของ iommi ก็ทำแบบนั้นจริง ๆ: https://kodare.net/2025/01/14/iframes-not-screenshots.html
  • แต่ก็สงสัยเหมือนกันว่าอาจกลายเป็น ประเด็นด้านความปลอดภัย ได้ไหม
• ฉันเคยคิดว่าจะลองให้ตอนรัน e2e test มี การสร้างสกรีนช็อต ไปพร้อมกันด้วย
  ถ้าเก็บ docs/ ไว้ใน repository เดียวกัน และเพิ่มเทสต์ใหม่ทุกครั้งที่อัปเดตเอกสารแล้วต้องใช้สกรีนช็อตใหม่ ก็น่าจะเข้ากันได้ดี
• ดีเลย
  เมื่อหลายปีก่อนฉันก็เริ่มทำสิ่งนี้แบบเดียวกันเป๊ะ ก่อนจะไป abstract มันให้ทั่วไปมากขึ้นเป็นอะไรอย่าง https://picshift.io/
  ถึงอย่างนั้นฉันก็ยังชอบ use case ของสกรีนช็อต มากอยู่ดี และชื่อเดิมของโปรเจ็กต์นี้ก็คือ ScreenSync
  • ดีมาก ทำมาดีมาก และยินดีที่ได้เห็นว่า แนวทางที่หลากหลาย แบบนี้มีอยู่ร่วมกัน