แทรกภาพหน้าจอที่อัปเดตอัตโนมัติลงในเอกสาร
(interblah.net)- สร้างขั้นตอนการทำงานที่ จับภาพหน้าจออัตโนมัติ จากเว็บแอปพลิเคชันที่กำลังรันอยู่ แล้วอัปเดตไปพร้อมกับการบิลด์เอกสารช่วยเหลือ เพื่อให้ภาพในเอกสาร เป็นเวอร์ชันล่าสุด แม้หลังจาก 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 เฉพาะด้วย 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ใช้ CSSclip-pathเพื่อใส่เอฟเฟ็กต์ขอบกระดาษฉีกhideใช้ซ่อนองค์ประกอบชั่วคราว เช่น dev toolbar หรือ cookie banner ที่ไม่ควรปรากฏบนหน้าจอ
- ไปป์ไลน์ทั้งหมดรันได้ด้วยคำสั่งเดียวคือ
rails manual:buildซึ่งจะจัดการทั้ง การจับภาพหน้าจอทั้งหมด และ การบิลด์หน้าช่วยเหลือ ไปพร้อมกัน - ซอร์สเอกสารถูกจัดเก็บไว้ใต้
public/manual/โดยแยกเป็นหมวดอย่าง basics, setup, advanced - ในขั้นตอนบิลด์ ไฟล์ Markdown เหล่านี้จะถูกแปลงเป็น ERB view ใต้
app/views/help/พร้อมสร้าง breadcrumb และการนำทางภายในหมวดด้วย - การพัฒนาฟีเจอร์และการอัปเดตเอกสารช่วยเหลือสามารถทำร่วมกันได้ภายในโค้ดเบสเดียวกัน จึงทำให้รักษา การซิงก์ระหว่างโค้ดกับเอกสาร ให้อยู่ใน PR เดียวกันหรือ commit เดียวกันได้ง่ายขึ้น
- กรณีพิเศษอย่างองค์ประกอบที่ต้องเลื่อนจอจึงจะเห็น, popover ที่ต้องคลิกก่อนเปิด, หรือการ crop เพื่อหลบส่วนที่ไม่ต้องการ ต้องใช้เวลาในการทำเพิ่ม แต่หลังจากสร้างระบบเสร็จแล้วก็ทำให้มีการอัปเดตศูนย์ช่วยเหลือได้บ่อยขึ้นมาก
- เพียงเปลี่ยน UI รันบิลด์ใหม่ แล้ว commit ผลลัพธ์ ก็สามารถทำให้ภาพหน้าจอทันสมัยอยู่เสมอได้ ทำให้ความยุ่งยากจากการจับภาพและครอปด้วยมือลดลงแทบหมดสิ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในเมื่อสร้างสกรีนช็อตด้วยโปรแกรมอยู่แล้ว ก็ทำทั้งสองเวอร์ชันของแอปทั้ง 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 ก็ทำให้บันทึกอัตโนมัติได้ รวมหลายฉากไว้ด้วย และถ้ามีคนสนใจฉันคิดว่านี่เป็นหัวข้อที่น่าเขียนอธิบายแยกต่างหาก
เกมแคชชวลเล็ก ๆ ที่ฉันทำด้วย vibe coding มักเริ่มจากการที่ตัวแอปรองรับการรันแบบเฮดเลสผ่าน CLI ได้เสมอ พร้อมการเรนเดอร์ texture นอกจอ คำสั่งจับสกรีนช็อต และการวัดประสิทธิภาพ
ใช้เวลาเพิ่มสิ่งนี้เข้าไปแทบไม่มาก แถมยังเปิดทางให้อะเจนต์ทำ UI automation และตรวจดูจุดสำคัญต่าง ๆ ได้ด้วย
เพราะแบบนี้เลยทำให้ง่ายมากที่จะให้อะเจนต์เป็นคนอัปเดตสกรีนช็อต
ถึงจะยังไม่เนี้ยบเท่าการฝังเข้าไปในขั้นตอน build แบบสมบูรณ์ แต่ตอนนี้ก็คิดจะเพิ่มส่วนนั้นเหมือนกัน
มีทั้ง argument ของ CLI สำหรับ offscreen screenshot path กับ world pos/camera view vector และยังรัน benchmark แบบสคริปต์ด้วยฟอร์แมตอินพุตแบบข้อความ
ฟอร์แมตนี้ประกอบด้วยหลายบรรทัดของเซกเมนต์ที่มีชื่อ ความยาว
ngame 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 ที่ฉันทำก็มีฟังก์ชันคล้ายกัน
จุดประสงค์หลักคือ การสร้างบทสอน ดังนั้นมันจะใส่ผลลัพธ์ของคำสั่งที่รันกลับเข้าไปในเอกสารด้วย
เช่นฝัง live preview ของเครื่องมือไว้ในกรอบสี่เหลี่ยม
ถ้าเครื่องมือเบาพอ มันอาจเหมาะที่สุดทั้งในเชิงภาพ และยังสะท้อนค่าการเรนเดอร์อย่างการตั้งค่า accessibility ของเบราว์เซอร์หรือส่วนเสริมของผู้ใช้ได้ตรง ๆ ด้วย
เอกสารของ iommi ก็ทำแบบนั้นจริง ๆ: https://kodare.net/2025/01/14/iframes-not-screenshots.html
ถ้าเก็บ
docs/ไว้ใน repository เดียวกัน และเพิ่มเทสต์ใหม่ทุกครั้งที่อัปเดตเอกสารแล้วต้องใช้สกรีนช็อตใหม่ ก็น่าจะเข้ากันได้ดีเมื่อหลายปีก่อนฉันก็เริ่มทำสิ่งนี้แบบเดียวกันเป๊ะ ก่อนจะไป abstract มันให้ทั่วไปมากขึ้นเป็นอะไรอย่าง https://picshift.io/
ถึงอย่างนั้นฉันก็ยังชอบ use case ของสกรีนช็อต มากอยู่ดี และชื่อเดิมของโปรเจ็กต์นี้ก็คือ
ScreenSync