अपने-आप अपडेट होने वाले स्क्रीनशॉट

• चल रहे web application से screenshots को अपने-आप capture करके help document build के साथ अपडेट करने वाला flow, जिससे UI बदलने के बाद भी document images को latest state में रखना आसान हो जाता है
• Markdown के भीतर SCREENSHOT comments में target path, capture method, CSS selector जैसी instructions होती हैं, और build process इन्हें पढ़कर वास्तविक image से भर देता है
• Rake task, Capybara और Cuprite के जरिए headless Chrome चलाता है, और team के हिसाब से काम को group करके एक बार login करने के बाद कई URL पर घूमते हुए capture करता है
• capture में element, full_page, viewport ये तीन modes supported हैं, और click, wait, crop, torn, hide जैसे options से खुले हुए UI state या अनावश्यक elements को भी control किया जा सकता है
• rails manual:build एक बार चलाने से screenshot generation और help page build साथ में चलते हैं, जिससे code और docs को same PR या commit में मिलाकर रखना आसान हो जाता है और manual capture व manual crop की friction काफी कम हो जाती है

---

अपने-आप अपडेट होने वाले स्क्रीनशॉट का तरीका

• Jelly का help center चल रहे web application से screenshots को अपने-आप capture करता है, और दोबारा build करने पर उन्हें साथ में update करने के लिए बनाया गया है
• documents Markdown में लिखे जाते हैं, और Self-updating screenshots लेख के अनुसार Redcarpet से HTML में process होने के बाद Rails app की ERB views में render किए जाते हैं
• Markdown के भीतर SCREENSHOT comment डाला जाता है, जिसमें target path, capture method, CSS selector जैसी instructions साथ में दी जाती हैं
  • <!-- SCREENSHOT: acme-tools/inbox | element | selector=#inbox-brand-new-section -->
  • उसके ठीक नीचे image tag उस जगह के रूप में इस्तेमाल होता है जहाँ result डाला जाएगा
• UI का रंग, button की position, या text थोड़ा भी बदल जाए तो पुराने document screenshots जल्दी outdated हो जाते हैं, और यह flow ऐसे manual update के बोझ को कम करता है

capture pipeline और maintenance के फायदे

• अंदरूनी रूप से Rake task, Capybara और Cuprite के जरिए headless Chrome चलाकर सभी Markdown files के SCREENSHOT comments को scan करता है
• screenshot काम को team के आधार पर group किया जाता है, ताकि एक ही team में सिर्फ एक बार login करके कई URL पर जाया जा सके
• supported capture modes तीन हैं
  • element: CSS selector से किसी खास DOM element को capture करता है
  • full_page: पूरे page को capture करता है, और जरूरत हो तो height के आधार पर crop किया जा सकता है
  • viewport: browser window में इस समय दिख रहे हिस्से को ही capture करता है
• detail options के रूप में click, wait, crop दिए जा सकते हैं, इसलिए button click के बाद दिखने वाली state या animation खत्म होने के बाद की screen भी अपने-आप capture की जा सकती है
  • <!-- SCREENSHOT: nectar-studio/manage/rules | full_page | click=".rule-create-button" wait=200 crop=0,800 -->
  • यह button दबाकर form खोलता है, फिर 200ms रुकता है, और किसी खास हिस्से में crop करके capture करता है
• अतिरिक्त options में torn और hide भी हैं
  • torn, CSS clip-path का इस्तेमाल करके फटे हुए कागज के किनारे जैसा effect लागू करता है
  • hide, dev toolbar या cookie banner जैसे उन elements को अस्थायी रूप से छिपाता है जिन्हें screen पर नहीं दिखना चाहिए
• पूरा pipeline सिर्फ rails manual:build command से चल जाता है, और सभी screenshots capture करने तथा help pages build करने का काम साथ में करता है
• document source, public/manual/ के नीचे basics, setup, advanced जैसी sections के हिसाब से व्यवस्थित है
• build stage में ये Markdown files, app/views/help/ के नीचे ERB views में बदली जाती हैं, और breadcrumb तथा section navigation भी साथ में बनाई जाती है
• feature development और help update को एक ही codebase में साथ संभालने से, code और documentation का synchronization उसी PR या उसी commit में बनाए रखना आसान हो जाता है
• scroll की जरूरत वाले elements, click करके खुलने वाले popover, और अनावश्यक हिस्सों से बचने के लिए crop जैसे exception handling में implementation के समय ज्यादा मेहनत लगी, लेकिन एक बार setup हो जाने पर help center को कहीं अधिक बार update किया जाने लगा
• UI बदलकर build फिर से चलाने और result को commit करने वाले flow भर से screenshots को हमेशा latest state में रखा जा सकता है, इसलिए manual capture और manual crop की friction लगभग खत्म हो जाती है

[GN⁺]

Hacker News राय

• मैंने भी इसी तरह .#screenshots derivation जोड़ा हुआ है, और शुरुआती setup cost बड़ी होती है, लेकिन उसके बाद maintenance लगभग नहीं के बराबर रहता है
  जब प्रोग्राम से screenshot generate ही कर रहे हों, तो ऐप के light/dark theme दोनों version साथ में बना सकते हैं, और prefers-color-scheme: dark के हिसाब से उन्हें बदल सकते हैं
  ऐसे elements GitHub README में भी अच्छे से काम करते हैं: https://github.com/CyberShadow/CyDo#readme
  • मैं इस तरीके से पूरी तरह सहमत हूँ
    मोबाइल ऐप में मैंने Nix से एक बार इस्तेमाल होने वाला Android emulator चलाकर latest screenshots generate करवाए, और इसमें न पहले से setup की ज़रूरत पड़ती है, न run होने के बाद कोई data बचता है
    मेरे मामले में setup भी इतना मुश्किल नहीं था; idea सोचना उससे ज़्यादा कठिन था, और Nix code मैंने अपने पसंदीदा LLM से एक ही बार में बनवा लिया
    screenshots को manually update करना दुनिया का सबसे कठिन काम तो नहीं है, लेकिन upload-apk + take-screenshot + transfer-back-to-PC + edit वाला flow हमेशा हल्का-सा झंझट लगता है, इसलिए आख़िरकार मैं यह काम लगभग करता ही नहीं
• मोबाइल पर code examples के लिए horizontal scroll ज़रूरी है
  context से अंदाज़ा तो लग गया था, लेकिन फिर भी असुविधा हुई
• यह mobile projects में सच में बहुत उपयोगी है
  app stores में screenshots अनिवार्य होते हैं, लेकिन screen size की संख्या और localization की संख्या के हिसाब से image बनानी पड़ती हैं, इसलिए यह जल्दी ही झंझट बन जाता है
  पहले मैं इसके लिए खुद script लिखता था, और अब https://fastlane.tools/ जैसे Fastlane tools बहुत मदद करते हैं
  मैं अपनी logic puzzle game Nonoverse में भी Fastlane इस्तेमाल कर रहा हूँ, और app store page पर example screenshots देखे जा सकते हैं: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
  App Preview video recording भी कई scenes तक शामिल करके automate कर रखी है, और अगर किसी की दिलचस्पी हो तो यह अलग से लिखने लायक विषय है
  • इसमें दिलचस्पी तो काफ़ी बढ़ गई है, लेकिन यह paid service है या local पर चलने वाला OS app, यह साफ़ समझ नहीं आ रहा
• काफ़ी बढ़िया है
  मैं vibe coding से जो छोटे casual games बनाता हूँ, वे हमेशा ऐप के CLI से headless चलने, offscreen texture rendering, screenshot commands, और performance instrumentation की क्षमता के साथ शुरू होते हैं
  इसे जोड़ने में लगभग समय नहीं लगता, और agent के लिए UI automate करने और अहम points देखने का रास्ता भी बन जाता है
  इसी वजह से agent से screenshots update करवाना भी बहुत आसान हो जाता है
  build process में पूरी तरह घुले-मिले version जितना elegant तो नहीं है, लेकिन अब मैं वह हिस्सा भी जोड़ने के बारे में सोच रहा हूँ
  • मैं भी बिल्कुल यही करता हूँ
    मेरे पास offscreen screenshot path और world pos/camera view vector देने वाले CLI arguments भी हैं, और text-based input format से scripted benchmarks चलाता हूँ
    यह format कई named segments की lines, हर segment के लिए n game ticks की लंबाई, और हर segment के control inputs से बना होता है
    game code पर काम करते समय visuals और performance का A/B test करने में मैं इसका बहुत इस्तेमाल करता हूँ
  • क्या आप इन casual games के कुछ links share कर सकते हैं?
    मुझे भी यह जानने में काफ़ी रुचि है कि vibe coding game development को कितना आसान बनाता है
    Adobe Flash के दौर में indie game ecosystem सचमुच बहुत जीवंत था, और उसके बाद उस स्तर की development ease को छूने वाली चीज़ें बहुत कम रहीं
    vibe coding पहली ऐसी चीज़ लगती है जो शायद उस स्तर से आगे निकलती है
  • इसे जोड़ने में लगभग समय नहीं लगता वाली बात मामले पर निर्भर करती है
    आप कौन-सा engine इस्तेमाल कर रहे हैं, यह जानने की जिज्ञासा है
• सच में शानदार
  मुझे खास तौर पर यह बात पसंद आई कि Markdown document के अंदर screenshot declaration inline डाली जा सकती है
  अपने desktop app में मैंने कई भाषाओं और light/dark modes के screenshots generate करने, noise हटाने, और Windows/macOS window frames लगाने वाला solution बना रखा है
  उसे यहाँ संक्षेप में लिखा है: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
  अभी वह अलग script है, इसलिए maintenance काफ़ी झंझटभरा है, लेकिन markdown/mdx के हिस्से के रूप में शामिल करने वाला तरीका देखना चाहिए
  इससे अच्छी प्रेरणा मिली
• ऐसी चीज़ की सच में बहुत बार ज़रूरत पड़ी है
  इसे तो कोई नोटिस न करे, ऐसा X का बेहतरीन काम वाले meme की तरह इस्तेमाल किया जा सकता है
• यह अच्छा है
  मेरे https://github.com/zombocom/rundoc में भी ऐसा मिलता-जुलता feature है
  इसका मुख्य उद्देश्य tutorial generation है, इसलिए यह चलाए गए commands का output भी वापस document में डाल देता है
• यहाँ real-time rendering वाला approach भी संभव हो सकता है
  जैसे tool का live preview किसी rectangle के भीतर डाल दिया जाए
  अगर tool हल्का हो, तो यह visual तौर पर भी सबसे अच्छा हो सकता है, और browser की accessibility settings या user addons जैसी rendering settings भी वैसे की वैसे reflect हो सकती हैं
  • या फिर HTML को static build भी कर सकते हैं
    iommi docs में सचमुच ऐसा ही किया गया है: https://kodare.net/2025/01/14/iframes-not-screenshots.html
  • हालाँकि यह security issue भी बन सकता है
• e2e tests चलाते समय screenshot generation भी साथ में करने का मैंने सोचा है
  अगर documentation के docs/ को भी उसी repository में रखा जाए, और docs update करते समय जहाँ नए screenshots चाहिए हों वहाँ नया test जोड़ दिया जाए, तो यह काफ़ी अच्छी तरह फिट बैठ सकता है
• बढ़िया
  मैंने भी कुछ साल पहले बिल्कुल यही बनाना शुरू किया था, लेकिन बाद में इसे https://picshift.io/ जैसी ज़्यादा general दिशा में abstract कर दिया
  फिर भी screenshot use case मुझे अब भी बहुत पसंद है, और इस project का मूल नाम भी ScreenSync था
  • अच्छा है, बढ़िया बनाया है, और यह देखकर खुशी होती है कि ऐसे अलग-अलग approaches साथ-साथ मौजूद हैं