- Tạo một quy trình tự động chụp ảnh màn hình từ ứng dụng web đang chạy và cập nhật chúng cùng lúc với quá trình build tài liệu trợ giúp, để hình ảnh trong tài liệu luôn ở trạng thái mới nhất ngay cả sau khi UI thay đổi
- Chú thích
SCREENSHOT trong Markdown chứa các chỉ thị như đường dẫn đích, cách chụp, CSS selector, và trong quá trình build sẽ được đọc để điền bằng hình ảnh thực tế
- Rake task chạy headless Chrome thông qua Capybara và Cuprite, nhóm các tác vụ theo từng team để chỉ đăng nhập một lần rồi đi qua nhiều URL và chụp
- Việc chụp hỗ trợ ba chế độ element, full_page, viewport, và có thể điều khiển cả UI đang mở hoặc các phần tử không cần thiết bằng các tùy chọn như
click, wait, crop, torn, hide
- Chỉ với một lần chạy
rails manual:build, việc tạo ảnh chụp màn hình và build trang trợ giúp sẽ diễn ra cùng nhau, giúp dễ đồng bộ code và tài liệu trong cùng một PR hoặc commit, giảm mạnh ma sát từ việc chụp và crop thủ công
Cách tiếp cận ảnh chụp màn hình tự động cập nhật
- Trung tâm trợ giúp của Jelly (dịch vụ hộp thư email dùng chung cho các nhóm) đang vận hành theo cách tự động chụp ảnh màn hình từ ứng dụng web đang chạy và cập nhật lại chúng mỗi khi build lại
- Tài liệu được viết bằng Markdown, sau đó được xử lý thành HTML bằng Redcarpet theo bài viết Self-updating screenshots, rồi render bằng ERB view của ứng dụng Rails
- Trong Markdown có chèn chú thích
SCREENSHOT, nơi chứa các chỉ thị như đường dẫn đích, cách chụp, CSS selector
<!-- SCREENSHOT: acme-tools/inbox | element | selector=#inbox-brand-new-section -->- Thẻ hình ảnh ngay bên dưới được dùng làm vị trí để chèn kết quả
- Chỉ cần màu sắc UI, vị trí nút bấm hoặc câu chữ thay đổi một chút là ảnh chụp trong tài liệu cũ sẽ nhanh chóng lỗi thời, và quy trình này giúp giảm gánh nặng cập nhật thủ công đó
Pipeline chụp và hiệu quả bảo trì
- Bên trong, một Rake task chạy headless Chrome thông qua Capybara và Cuprite để quét chú thích
SCREENSHOT trong toàn bộ các file Markdown
- Các tác vụ chụp ảnh được nhóm theo từng team, và trong cùng một team sẽ chỉ đăng nhập một lần trước khi đi qua nhiều URL
- Có ba chế độ chụp được hỗ trợ
- element: chụp một phần tử DOM cụ thể bằng CSS selector
- full_page: chụp toàn bộ trang, và nếu cần có thể cắt theo chiều cao
- viewport: chỉ chụp vùng hiện đang hiển thị trong cửa sổ trình duyệt
- Các tùy chọn chi tiết như click, wait, crop cho phép tự động ghi lại cả trạng thái xuất hiện sau khi bấm nút hoặc sau khi animation kết thúc
<!-- SCREENSHOT: nectar-studio/manage/rules | full_page | click=".rule-create-button" wait=200 crop=0,800 -->- Sau khi bấm nút để mở form, hệ thống sẽ chờ 200ms rồi cắt và chụp vùng cụ thể
- Ngoài ra còn có các tùy chọn torn và hide
torn áp dụng hiệu ứng mép giấy bị xé bằng CSS clip-pathhide tạm thời ẩn những phần tử không nên xuất hiện trên màn hình như dev toolbar hoặc cookie banner
- Toàn bộ pipeline được chạy chỉ bằng một lệnh
rails manual:build, xử lý đồng thời tất cả ảnh chụp màn hình và build các trang trợ giúp
- Mã nguồn tài liệu được sắp xếp theo các mục như basics, setup, advanced bên dưới
public/manual/
- Ở bước build, các file Markdown này được chuyển thành ERB view dưới
app/views/help/, đồng thời tạo luôn breadcrumb và điều hướng theo từng mục
- Vì có thể xử lý phát triển tính năng và cập nhật tài liệu trong cùng một codebase, việc giữ code và tài liệu đồng bộ trong cùng một PR hoặc cùng một commit trở nên dễ dàng hơn
- Những xử lý ngoại lệ như phần tử cần cuộn, popover chỉ mở khi click, hay crop để tránh các vùng không cần thiết đòi hỏi nhiều thời gian triển khai hơn, nhưng sau khi xây dựng xong thì trung tâm trợ giúp được cập nhật thường xuyên hơn rất nhiều
- Chỉ với quy trình thay đổi UI, chạy lại build rồi commit kết quả, có thể luôn giữ ảnh chụp màn hình ở trạng thái mới nhất, và gần như loại bỏ hoàn toàn ma sát từ việc chụp và crop thủ công
1 bình luận
Ý kiến trên Hacker News
Nhân lúc tạo screenshot bằng chương trình, có thể làm luôn cả hai phiên bản light/dark theme của ứng dụng rồi thay thế theo
prefers-color-scheme: darkNhững thứ như vậy cũng hoạt động tốt trong GitHub README: https://github.com/CyberShadow/CyDo#readme
Với app di động, tôi dùng Nix để chạy một Android emulator dùng một lần nhằm tạo screenshot mới nhất; không cần cấu hình sẵn và cũng không để lại dữ liệu sau khi chạy
Với tôi thì phần cấu hình cũng không quá khó, cái khó hơn là nghĩ ra ý tưởng, còn code Nix thì tôi tạo một phát bằng LLM yêu thích
Việc cập nhật screenshot thủ công không phải việc khổ nhất trên đời, nhưng quy trình
upload-apk + take-screenshot + transfer-back-to-PC + editlúc nào cũng hơi phiền, nên rốt cuộc tôi gần như không làmTôi vẫn có thể đoán đại bằng ngữ cảnh, nhưng dù vậy vẫn khá bất tiện
App store bắt buộc phải có screenshot, mà phải tạo ảnh theo từng kích thước màn hình và từng bản địa hóa nên rất nhanh thành phiền phức
Trước đây tôi từng tự viết script cho việc này, còn bây giờ những công cụ Fastlane như https://fastlane.tools/ giúp được rất nhiều
Tôi cũng đang dùng Fastlane cho game giải đố logic Nonoverse của mình, và có thể xem screenshot mẫu trên trang App Store: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
Tôi cũng đã tự động hóa cả việc quay video App Preview, bao gồm nhiều cảnh khác nhau; nếu ai quan tâm thì đây khá đáng để viết thành một bài riêng
Những game casual nhỏ mà tôi làm bằng vibe coding thì luôn bắt đầu trong trạng thái app có thể chạy headless bằng CLI, có render vào offscreen texture, lệnh chụp screenshot, và cả đo hiệu năng
Mất rất ít thời gian để thêm cái này vào, đồng thời cũng mở ra một lối cho agent tự động hóa UI và kiểm tra những điểm quan trọng
Nhờ vậy, việc để agent cập nhật screenshot cũng trở nên rất dễ
Dù chưa gọn gàng bằng kiểu tích hợp hoàn toàn vào quy trình build, nhưng giờ tôi cũng định thêm phần đó
Tôi có cả tham số CLI cho offscreen screenshot path và world pos/camera view vector, đồng thời chạy benchmark script bằng một định dạng input dạng text
Định dạng này gồm nhiều dòng segment được đặt tên, độ dài
ngame tick cho từng segment, và input điều khiển của mỗi segmentTôi dùng nó rất nhiều khi A/B test hình ảnh và hiệu năng trong lúc làm code game
Tôi cũng rất quan tâm việc vibe coding đã làm cho phát triển game trở nên dễ đến mức nào
Thời Adobe Flash, hệ sinh thái game indie thực sự rất sôi động, và từ đó đến nay hầu như không có thứ gì chạm tới mức dễ phát triển như vậy
vibe coding có vẻ là công cụ đầu tiên vượt qua được ngưỡng đó
Mất rất ít thời gian để thêm cái này vàocòn tùy trường hợpTôi tò mò không biết bạn dùng engine nào
Tôi đặc biệt thích điểm có thể nhúng khai báo screenshot ngay inline trong tài liệu Markdown
Với ứng dụng desktop của mình, tôi đã làm một giải pháp có thể tạo screenshot cho nhiều ngôn ngữ và chế độ light/dark, khử nhiễu, rồi còn thêm cả khung cửa sổ Windows/macOS
Tôi đã viết về nó ở đây: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
Hiện tại nó là một script riêng nên bảo trì khá phiền; chắc tôi nên tìm cách đưa nó vào như một phần của markdown/mdx
Tôi đã có thêm cảm hứng hay
Thậm chí có thể dùng làm meme kiểu tác phẩm tuyệt vời nhất mà chẳng ai nhận ra
https://github.com/zombocom/rundoc mà tôi làm cũng có tính năng tương tự
Mục đích chính là tạo tutorial, nên nó còn đưa cả output của lệnh đã chạy ngược trở lại vào tài liệu
Kiểu đặt live preview của công cụ vào trong một hình chữ nhật
Nếu công cụ nhẹ thì có thể còn tối ưu hơn về mặt hình ảnh, đồng thời cũng phản ánh nguyên trạng các thiết lập render như cài đặt accessibility của trình duyệt hay addon của người dùng
Tài liệu của iommi thực sự đang làm như vậy: https://kodare.net/2025/01/14/iframes-not-screenshots.html
Nếu để cả
docs/cho tài liệu trong cùng repository, rồi mỗi khi cập nhật tài liệu mà cần screenshot mới thì thêm test mới, có vẻ sẽ rất hợpVài năm trước tôi cũng bắt đầu làm đúng thứ này, rồi cuối cùng trừu tượng hóa nó theo hướng tổng quát hơn như https://picshift.io/
Nhưng tôi vẫn rất thích use case screenshot, và tên gốc của dự án này cũng từng là
ScreenSync