आख़िर ये क्या बकवास है..
तो किसकी hard drive हमेशा भरी रहती है?
नहीं, कभी-कभी ऐसे बेतरतीब, बेकार से लेख क्यों दिख जाते हैं जो बस यह समझने की कोशिश करते लगते हैं कि ऐसा क्यों है?
क्या लिखने वाला पढ़ने वालों के बारे में सोचता ही नहीं?
मैं Mac mini एक्सेस करते समय tailscale + macOS स्क्रीन शेयरिंग का इस्तेमाल करता हूँ, और वहाँ भी यही समस्या दिखती है
कुछ असुविधा तो थी, लेकिन लगता है कि अस्थायी उपाय के तौर पर इसे हल करने के लिए यह अच्छा रहेगा
यह बात Google पर ही आसानी से मिल जाती है, इसलिए मैं अलग से ढूँढकर नहीं दे रहा हूँ। हाल की Berkeley University की एक research भी है।
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.
ऊपर से, अगर शुरू से ही system trading या bots की जीतने की दर ज़्यादा होती, तो किसी न किसी तरह उनका इस्तेमाल करने का तरीका मुख्यधारा बन गया होता.
डेटा अतीत के निशान हैं। और निर्णायक भी। इस नज़रिए से देखें तो भविष्य की चीज़ें कभी डेटा नहीं हो सकतीं। stock trading भविष्य के लेन-देन पर आधारित है। ऊपर जाए या नीचे, वह इंसानी judgment का क्षेत्र है; bots उसका फैसला नहीं कर सकते। जब तक ऐसा stock market न हो जिसमें इंसान पूरी तरह बाहर कर दिए गए हों, वे जीत ही नहीं सकते।
डेटा से ही फर्क शुरू हो जाता है। इंसान आपस में इकट्ठा होकर फोन बंद करके पार्टी करते हुए जानकारी बाँटें, तो bots उसे कैसे जान पाएँगे?
हाँ, अगर आपका मतलब खुद को शामिल करते हुए individual retail investors से है, तो उसका इस चर्चा के दायरे से कोई संबंध नहीं है।
डुप्लिकेट execution detection के लिए (tool, arguments, output hash) के संयोजन का उपयोग करते हैं, यह काफ़ी प्रभावशाली लगा। हम भी इसी तरह की चिंता पर काम कर रहे हैं, और audit log में hash chain जोड़कर एक ही event के दो बार रिकॉर्ड होने से रोकने का तरीका प्रयोग कर रहे हैं.
जैसा आपने कहा, "दो बार call" बनाम "दो बार execution" का अंतर ही असली कुंजी है। हम भी हर agent task में idempotency key जोड़ने की दिशा पर विचार कर रहे हैं—क्या आपने इसे वास्तविक production service में लागू करके देखा है?
धन्यवाद। Gitleaks + ruff + Kyverno + Checkov का संयोजन लगता है कि हम भी तुरंत संदर्भ के तौर पर इस्तेमाल कर सकते हैं।
थोड़ा और साझा करूं तो — हमारी टीम थोड़े अलग ढांचे में काम करती है। पूरी टीम ही एक AI Agent ग्रुप है। मानव CEO के नीचे Steward AI वास्तविक development, review और deployment तक संभालते हैं।
इसलिए “AI की गलती track करना” हमारे लिए सिर्फ logging का मामला नहीं है, बल्कि Agent-वार Passport + Spirit Score + Audit Trail के जरिए “किसने किस अधिकार से निर्णय लिया” रिकॉर्ड करने वाला governance मुद्दा है।
bsh998 जी के तरीके की तरह, पहले से static validation (Gitleaks जैसे) को हमारे CI से जोड़ना अगला कदम है। आज भी environment variable छूटने की वजह से crash हुआ था — मुद्दा ठीक यही था।
मैंने ऐसा समझा कि terminal protocol से आपका पहला परिचय इसी development के दौरान हुआ था,
तो यह भी जानना चाहता हूँ कि development शुरू करने से पहले Rust के बारे में आपकी जानकारी कितनी थी।
मैंने Zig में development किया, लेकिन सच कहूँ तो Zig को मैंने पहले हाथ से इस्तेमाल नहीं किया था,
और terminal protocol, syntax, structure—इन सबके बारे में भी मेरी स्थिति यही थी कि मुझे बिल्कुल ज्ञान नहीं था, इसलिए मैंने zero base से पढ़ते हुए चुनौती लेने जैसा approach लिया।
इसी वजह से मैंने external library dependencies से भी ज़्यादा बचने की कोशिश की।
मैं सवाल पूछते-पुछते यह ज़्यादा स्वाभाविक रूप से समझना चाहता था कि चीज़ें कैसे बनती हैं, और AI के साथ मिलकर troubleshooting करना भी उसी इरादे का हिस्सा था,
क्योंकि मैं ऐसे मामलों से बचना चाहता था जहाँ चीज़ें चल तो रही हों, लेकिन उन पर मेरा नियंत्रण न हो।
आपने कहा था कि इसमें लगभग 4 महीने लगे,
मेरे मामले में भी, क्योंकि मैं remote से घर में चालू Mac पर development कर रहा था, ssh में Claude या Codex CLI पर image upload संभव बनाने वाला protocol बनाने के बाद, पहले जो terminal app इस्तेमाल करता था उसे मैंने लगभग छोड़ ही दिया था; अब बस कभी-कभार reference के लिए ही खोलता था।
व्यक्तिगत रूप से, मेरे लिए शायद terminal development का लगभग दूसरा या तीसरा हफ्ता रहा होगा।
जैसा आपने जवाब में कहा, आपने उसे तुरंत इस्तेमाल करना शुरू कर दिया था—तो क्या उसी समय से tmux से बाहर निकलने की प्रक्रिया भी शुरू हो गई थी?
और 4 महीने लगने की वजह, मेरी राय में, शायद यह रही होगी कि लगातार features और convenience जोड़ने में core functionality बनाने से भी ज़्यादा समय लगा होगा—क्या मेरी यह सोच सही है, यह जानना चाहता हूँ।
मेरे साथ तो ऐसा ही था, और जब दूसरे लोग भी इसी तरह के products बनाते हैं तो क्या उनके यहाँ भी कुछ ऐसा ही flow होता है—यह बात मैं हमेशा से व्यक्तिगत रूप से जानना चाहता था.. अगर असुविधा न हो तो जवाब दें, आभारी रहूँगा(__).
और, tmux की तुलना में यह कब से आपको स्पष्ट रूप से ज़्यादा सुविधाजनक लगने लगा, यह भी जानना चाहता हूँ।
एक और बात, मैं भी असल में इसी तरह के विषय पर terminal बना रहा हूँ और उससे संतुष्ट भी हूँ, लेकिन आखिरकार यह ऐसा program है जिसे लगातार maintain करना ही पड़ता है।
जैसा आपने blog में लिखा, Ocra, cmux, heder जैसे समान उद्देश्य वाले tools लगातार आ रहे हैं, और ज़्यादातर मशहूर libraries के मामले में चाहे कंपनी हो, sponsorship हो या contributions, उनकी गति व्यक्तिगत developer की तुलना में अनिवार्य रूप से बहुत तेज़ होती है, और उसी कारण वे feedback भी बेहतर पाते हैं।
तो competition(?) के नज़रिए से देखें तो, Korean IME को छोड़कर, detail convenience या UX improvements की speed के मामले में practically बहुत पीछे रह जाना लगभग तय लगता है।
ऐसे में maintenance के बारे में आप कहाँ तक को पर्याप्त मानते हैं, यानी ऊपर बताए गए समान प्रकृति के apps की तुलना में किस स्तर तक पहुँच जाए तो आपको लगता है कि ठीक है?
और, आपने Rust में GPU चुना है, तो क्या क्या आप किसी हद तक Windows तक भी ध्यान में रख रहे हैं??
यह मेरा भी व्यक्तिगत program development है, लेकिन ecosystem में हार भी जाऊँ(?) तो भी मेरा लक्ष्य कम-से-कम उन apps की quality तक पहुँचना है जिनका मैंने ज़िक्र किया।
और copad, Ocra जैसा दिखता है, लेकिन क्या आपका अंतिम लक्ष्य Electron-based नहीं बल्कि terminal-based ADE है?
इसी तरह के उद्देश्य वाला app बनाने वाले किसी Korean व्यक्ति को पहली बार देख रहा हूँ, इसलिए मैं सवालों की बौछार कर बैठा—आप चाहें तो हर सवाल का जवाब देने की ज़रूरत नहीं है..!
मुझे तो इसके उलट, इस पर Andrew Ng की प्रतिक्रिया ज़्यादा प्रभावशाली लगी।
"यह बिल्कुल भी वही मामला नहीं है। हर किसी को अपना code private रखने का अधिकार है। समस्या तब होती है जब कोई दूसरे लोगों को अपना code open source के रूप में public करने से भी रोकने की कोशिश करता है।" (https://x.com/AndrewYNg/status/2081103828859117908)
दूसरे 2FA के मुकाबले मुझे तो यह निश्चित रूप से ज़्यादा सुविधाजनक लगा, लेकिन लगता है कुछ लोगों को असुविधाजनक भी लगता है। स्पेक के हिसाब से यह किसी भी अन्य security तरीके से ज़्यादा सुरक्षित भी है।
मुझे लगता है कि Korean security regulations Face ID या fingerprint recognition जैसी व्यक्तिगत जानकारी पर आधारित authentication को बाहर रखने की दिशा में जा रहे हैं, लेकिन passkey में ऐसी चिंता भी नहीं है।
Apple करती है तो लगता है कि Face ID अच्छा है, लेकिन अगर कोई नया startup ऐसा करे तो शुरुआत में ही चेहरे की तस्वीर लेने की बात से लोगों को झिझक हो सकती है।
मुझे लगता है यह मूल रूप से इसलिए हुआ कि users 2FA इस्तेमाल नहीं करते या उसे समझते नहीं हैं।
उदाहरण के लिए, अगर पूछा जाए कि bank OTP इस्तेमाल करोगे या passkey? तो passkey बेहद सुविधाजनक लगेगा।
नमस्ते!
अच्छा अनुभव और विचार साझा करने के लिए धन्यवाद।
बेशक, code बनाने की unit cost कम होने से खुद बनाने का रास्ता खुला है, लेकिन निजी तौर पर मैं AI का दौर आ गया है या नहीं, इससे अलग होकर external libraries अपनाने को देखता हूँ।
मेरी requirements पूरी करने वाली library नहीं है
मिलते-जुलते tool को modify करने के बजाय उसे फिर से बनाना सस्ता है
सिर्फ जब मुझे लगता है कि ये दोनों बातें सही हैं, तभी मैं खुद बनाता हूँ।
कारण कई हैं, लेकिन आखिरकार, code का कितना भी छोटा टुकड़ा हो, अगर मैं उसे manage करना शुरू करता हूँ तो वह अंततः उस क्षेत्र में आ जाता है जहाँ मुझे review, testing, maintenance वगैरह करनी पड़ती है, और मुझे लगता है कि केवल code लिखने से आगे की लागत हमेशा साथ आती है।
Development process में भी जो issues आए, वे window manager जैसे काफी core programs से टकराव से जुड़े थे, इसलिए अगर इसे भी पूरी तरह build from scratch करता, तो external dependencies से टकराव के कारण debugging और testing में लगने वाले समय से कहीं ज्यादा समय implementation और validation में लगाना पड़ता, ऐसा मुझे लगता है।
इसके अलावा, development शुरू करने के बाद से मैंने लगातार दर्द झेलते हुए भी अपना बनाया tool इस्तेमाल किया, और मुझे लगता है कि यह संभव हो पाया क्योंकि मैंने कुछ हद तक dependencies के ऊपर development शुरू किया था।
MacOS में SwiftTerm हटाने वाले उदाहरण की तरह, पहले external dependency लाकर यह जांचा कि मेरी चाही हुई concept काम करती है या नहीं, और जब कुछ ऐसा आया जिसे मुझे implement करना था तो मैंने खुद implement करना शुरू किया; लेकिन उस समय भी external dependency की वजह से मेरे programs चल रहे थे, इसलिए मैं उसी के ऊपर stabilization और features जोड़ने पर लगातार मेहनत कर सका।
साथ ही, webkit जोड़ने पर ज्यादातर web apps वैसे ही काम करते हैं जैसे सामान्य browser खोलने पर करते हैं!
हाल में मैं headless browser को cli से control करने वाले tools और claude in chrome का भी सक्रिय रूप से उपयोग कर रहा हूँ, और terminal तक chromium चढ़ाकर memory का अत्यधिक उपयोग होने से बचाना चाहता हूँ, इसलिए अगर कोई बड़ा मामला न हो तो terminal के अंदर webview का tech stack शायद बहुत नहीं बदलूँगा।
हमारा demo तो बिल्कुल एक static HTML फ़ाइल है, इसलिए यह काफ़ी ठीक बैठेगा। अगर link fixed हो तो share करना भी आसान रहेगा। बताने के लिए धन्यवाद, demo खत्म होने के बाद इसे लागू करके देखूंगा। धन्यवाद!
अभी उद्देश्य logic की sophistication से ज़्यादा यह दिखाना है कि “input डालने पर matching job posting सच में दिखाई देती है।” यह demo non-developer internal decision-makers के सामने है, इसलिए completeness से ज़्यादा काम करते हुए दिखाने पर focus है। Logic को advanced बनाना अगला step मान रहा हूँ।
आख़िर ये क्या बकवास है..
तो किसकी hard drive हमेशा भरी रहती है?
नहीं, कभी-कभी ऐसे बेतरतीब, बेकार से लेख क्यों दिख जाते हैं जो बस यह समझने की कोशिश करते लगते हैं कि ऐसा क्यों है?
क्या लिखने वाला पढ़ने वालों के बारे में सोचता ही नहीं?
मैं Mac mini एक्सेस करते समय tailscale + macOS स्क्रीन शेयरिंग का इस्तेमाल करता हूँ, और वहाँ भी यही समस्या दिखती है
कुछ असुविधा तो थी, लेकिन लगता है कि अस्थायी उपाय के तौर पर इसे हल करने के लिए यह अच्छा रहेगा
यह बात Google पर ही आसानी से मिल जाती है, इसलिए मैं अलग से ढूँढकर नहीं दे रहा हूँ। हाल की Berkeley University की एक research भी है।
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.
ऊपर से, अगर शुरू से ही system trading या bots की जीतने की दर ज़्यादा होती, तो किसी न किसी तरह उनका इस्तेमाल करने का तरीका मुख्यधारा बन गया होता.
डेटा अतीत के निशान हैं। और निर्णायक भी। इस नज़रिए से देखें तो भविष्य की चीज़ें कभी डेटा नहीं हो सकतीं। stock trading भविष्य के लेन-देन पर आधारित है। ऊपर जाए या नीचे, वह इंसानी judgment का क्षेत्र है; bots उसका फैसला नहीं कर सकते। जब तक ऐसा stock market न हो जिसमें इंसान पूरी तरह बाहर कर दिए गए हों, वे जीत ही नहीं सकते।
डेटा से ही फर्क शुरू हो जाता है। इंसान आपस में इकट्ठा होकर फोन बंद करके पार्टी करते हुए जानकारी बाँटें, तो bots उसे कैसे जान पाएँगे?
हाँ, अगर आपका मतलब खुद को शामिल करते हुए individual retail investors से है, तो उसका इस चर्चा के दायरे से कोई संबंध नहीं है।
अंदर जाकर
विश्लेषण शुरूदबाया तो भुगतान करने को कह रहा है, लगता है यह मुफ़्त नहीं है।चाहे AR हो या भविष्य में आने वाले humanoid, मुझे लगता है कि interface धीरे-धीरे और ज़्यादा abstract होता जाएगा।
डुप्लिकेट execution detection के लिए
(tool, arguments, output hash)के संयोजन का उपयोग करते हैं, यह काफ़ी प्रभावशाली लगा। हम भी इसी तरह की चिंता पर काम कर रहे हैं, और audit log में hash chain जोड़कर एक ही event के दो बार रिकॉर्ड होने से रोकने का तरीका प्रयोग कर रहे हैं.जैसा आपने कहा,
"दो बार call"बनाम"दो बार execution"का अंतर ही असली कुंजी है। हम भी हर agent task में idempotency key जोड़ने की दिशा पर विचार कर रहे हैं—क्या आपने इसे वास्तविक production service में लागू करके देखा है?धन्यवाद। Gitleaks + ruff + Kyverno + Checkov का संयोजन लगता है कि हम भी तुरंत संदर्भ के तौर पर इस्तेमाल कर सकते हैं।
थोड़ा और साझा करूं तो — हमारी टीम थोड़े अलग ढांचे में काम करती है। पूरी टीम ही एक AI Agent ग्रुप है। मानव CEO के नीचे Steward AI वास्तविक development, review और deployment तक संभालते हैं।
इसलिए “AI की गलती track करना” हमारे लिए सिर्फ logging का मामला नहीं है, बल्कि Agent-वार Passport + Spirit Score + Audit Trail के जरिए “किसने किस अधिकार से निर्णय लिया” रिकॉर्ड करने वाला governance मुद्दा है।
bsh998 जी के तरीके की तरह, पहले से static validation (Gitleaks जैसे) को हमारे CI से जोड़ना अगला कदम है। आज भी environment variable छूटने की वजह से crash हुआ था — मुद्दा ठीक यही था।
LLM विश्लेषण के हिसाब से यह बहुत ही महंगा है।
धन्यवाद।
इस हफ्ते के भीतर साइट में भाषा सेटिंग फीचर लागू कर दूँगा :)
जवाब के लिए धन्यवाद!!
लगता है मैं आपसे और भी कई सवाल पूछूंगा..
मैंने ऐसा समझा कि terminal protocol से आपका पहला परिचय इसी development के दौरान हुआ था,
तो यह भी जानना चाहता हूँ कि development शुरू करने से पहले Rust के बारे में आपकी जानकारी कितनी थी।
मैंने Zig में development किया, लेकिन सच कहूँ तो Zig को मैंने पहले हाथ से इस्तेमाल नहीं किया था,
और terminal protocol, syntax, structure—इन सबके बारे में भी मेरी स्थिति यही थी कि मुझे बिल्कुल ज्ञान नहीं था, इसलिए मैंने zero base से पढ़ते हुए चुनौती लेने जैसा approach लिया।
इसी वजह से मैंने external library dependencies से भी ज़्यादा बचने की कोशिश की।
मैं सवाल पूछते-पुछते यह ज़्यादा स्वाभाविक रूप से समझना चाहता था कि चीज़ें कैसे बनती हैं, और AI के साथ मिलकर troubleshooting करना भी उसी इरादे का हिस्सा था,
क्योंकि मैं ऐसे मामलों से बचना चाहता था जहाँ चीज़ें चल तो रही हों, लेकिन उन पर मेरा नियंत्रण न हो।
आपने कहा था कि इसमें लगभग 4 महीने लगे,
मेरे मामले में भी, क्योंकि मैं remote से घर में चालू Mac पर development कर रहा था, ssh में Claude या Codex CLI पर image upload संभव बनाने वाला protocol बनाने के बाद, पहले जो terminal app इस्तेमाल करता था उसे मैंने लगभग छोड़ ही दिया था; अब बस कभी-कभार reference के लिए ही खोलता था।
व्यक्तिगत रूप से, मेरे लिए शायद terminal development का लगभग दूसरा या तीसरा हफ्ता रहा होगा।
जैसा आपने जवाब में कहा, आपने उसे तुरंत इस्तेमाल करना शुरू कर दिया था—तो क्या उसी समय से tmux से बाहर निकलने की प्रक्रिया भी शुरू हो गई थी?
और 4 महीने लगने की वजह, मेरी राय में, शायद यह रही होगी कि लगातार features और convenience जोड़ने में core functionality बनाने से भी ज़्यादा समय लगा होगा—क्या मेरी यह सोच सही है, यह जानना चाहता हूँ।
मेरे साथ तो ऐसा ही था, और जब दूसरे लोग भी इसी तरह के products बनाते हैं तो क्या उनके यहाँ भी कुछ ऐसा ही flow होता है—यह बात मैं हमेशा से व्यक्तिगत रूप से जानना चाहता था.. अगर असुविधा न हो तो जवाब दें, आभारी रहूँगा(__).
और, tmux की तुलना में यह कब से आपको स्पष्ट रूप से ज़्यादा सुविधाजनक लगने लगा, यह भी जानना चाहता हूँ।
एक और बात, मैं भी असल में इसी तरह के विषय पर terminal बना रहा हूँ और उससे संतुष्ट भी हूँ, लेकिन आखिरकार यह ऐसा program है जिसे लगातार maintain करना ही पड़ता है।
जैसा आपने blog में लिखा, Ocra, cmux, heder जैसे समान उद्देश्य वाले tools लगातार आ रहे हैं, और ज़्यादातर मशहूर libraries के मामले में चाहे कंपनी हो, sponsorship हो या contributions, उनकी गति व्यक्तिगत developer की तुलना में अनिवार्य रूप से बहुत तेज़ होती है, और उसी कारण वे feedback भी बेहतर पाते हैं।
तो competition(?) के नज़रिए से देखें तो, Korean IME को छोड़कर, detail convenience या UX improvements की speed के मामले में practically बहुत पीछे रह जाना लगभग तय लगता है।
ऐसे में maintenance के बारे में आप कहाँ तक को पर्याप्त मानते हैं, यानी ऊपर बताए गए समान प्रकृति के apps की तुलना में किस स्तर तक पहुँच जाए तो आपको लगता है कि ठीक है?
और, आपने Rust में GPU चुना है, तो क्या क्या आप किसी हद तक Windows तक भी ध्यान में रख रहे हैं??
यह मेरा भी व्यक्तिगत program development है, लेकिन ecosystem में हार भी जाऊँ(?) तो भी मेरा लक्ष्य कम-से-कम उन apps की quality तक पहुँचना है जिनका मैंने ज़िक्र किया।
और copad, Ocra जैसा दिखता है, लेकिन क्या आपका अंतिम लक्ष्य Electron-based नहीं बल्कि terminal-based ADE है?
इसी तरह के उद्देश्य वाला app बनाने वाले किसी Korean व्यक्ति को पहली बार देख रहा हूँ, इसलिए मैं सवालों की बौछार कर बैठा—आप चाहें तो हर सवाल का जवाब देने की ज़रूरत नहीं है..!
कमेंट्स पढ़ते हुए शर्म से चेहरा ढक लेने वाले पल याद आ गए।
असल में, ज़्यादातर development के लिए किसी super developer की ज़रूरत नहीं होती। मैं इसे बस आम लोगों के साथ मिलकर कुछ बनाने की प्रक्रिया मानता हूँ।
Open weight और open source में फर्क करने वाला लेख काफ़ी समय बाद देखने को मिला।
मुझे तो इसके उलट, इस पर Andrew Ng की प्रतिक्रिया ज़्यादा प्रभावशाली लगी।
अरे! इसे अलग से पोस्ट करने के लिए एक category भी थी! बताने के लिए धन्यवाद!
यह पुराने GOM Player गेम की याद दिलाता है..
👍 ऐसी चीज़ें बहुत अच्छी लगती हैं..
दूसरे 2FA के मुकाबले मुझे तो यह निश्चित रूप से ज़्यादा सुविधाजनक लगा, लेकिन लगता है कुछ लोगों को असुविधाजनक भी लगता है। स्पेक के हिसाब से यह किसी भी अन्य security तरीके से ज़्यादा सुरक्षित भी है।
मुझे लगता है कि Korean security regulations Face ID या fingerprint recognition जैसी व्यक्तिगत जानकारी पर आधारित authentication को बाहर रखने की दिशा में जा रहे हैं, लेकिन passkey में ऐसी चिंता भी नहीं है।
Apple करती है तो लगता है कि Face ID अच्छा है, लेकिन अगर कोई नया startup ऐसा करे तो शुरुआत में ही चेहरे की तस्वीर लेने की बात से लोगों को झिझक हो सकती है।
मुझे लगता है यह मूल रूप से इसलिए हुआ कि users 2FA इस्तेमाल नहीं करते या उसे समझते नहीं हैं।
उदाहरण के लिए, अगर पूछा जाए कि bank OTP इस्तेमाल करोगे या passkey? तो passkey बेहद सुविधाजनक लगेगा।
नमस्ते!
अच्छा अनुभव और विचार साझा करने के लिए धन्यवाद।
बेशक, code बनाने की unit cost कम होने से खुद बनाने का रास्ता खुला है, लेकिन निजी तौर पर मैं AI का दौर आ गया है या नहीं, इससे अलग होकर external libraries अपनाने को देखता हूँ।
सिर्फ जब मुझे लगता है कि ये दोनों बातें सही हैं, तभी मैं खुद बनाता हूँ।
कारण कई हैं, लेकिन आखिरकार, code का कितना भी छोटा टुकड़ा हो, अगर मैं उसे manage करना शुरू करता हूँ तो वह अंततः उस क्षेत्र में आ जाता है जहाँ मुझे review, testing, maintenance वगैरह करनी पड़ती है, और मुझे लगता है कि केवल code लिखने से आगे की लागत हमेशा साथ आती है।
Development process में भी जो issues आए, वे window manager जैसे काफी core programs से टकराव से जुड़े थे, इसलिए अगर इसे भी पूरी तरह build from scratch करता, तो external dependencies से टकराव के कारण debugging और testing में लगने वाले समय से कहीं ज्यादा समय implementation और validation में लगाना पड़ता, ऐसा मुझे लगता है।
इसके अलावा, development शुरू करने के बाद से मैंने लगातार दर्द झेलते हुए भी अपना बनाया tool इस्तेमाल किया, और मुझे लगता है कि यह संभव हो पाया क्योंकि मैंने कुछ हद तक dependencies के ऊपर development शुरू किया था।
MacOS में SwiftTerm हटाने वाले उदाहरण की तरह, पहले external dependency लाकर यह जांचा कि मेरी चाही हुई concept काम करती है या नहीं, और जब कुछ ऐसा आया जिसे मुझे implement करना था तो मैंने खुद implement करना शुरू किया; लेकिन उस समय भी external dependency की वजह से मेरे programs चल रहे थे, इसलिए मैं उसी के ऊपर stabilization और features जोड़ने पर लगातार मेहनत कर सका।
साथ ही, webkit जोड़ने पर ज्यादातर web apps वैसे ही काम करते हैं जैसे सामान्य browser खोलने पर करते हैं!
हाल में मैं headless browser को cli से control करने वाले tools और claude in chrome का भी सक्रिय रूप से उपयोग कर रहा हूँ, और terminal तक chromium चढ़ाकर memory का अत्यधिक उपयोग होने से बचाना चाहता हूँ, इसलिए अगर कोई बड़ा मामला न हो तो terminal के अंदर webview का tech stack शायद बहुत नहीं बदलूँगा।
पढ़ने के लिए धन्यवाद!
हमारा demo तो बिल्कुल एक static HTML फ़ाइल है, इसलिए यह काफ़ी ठीक बैठेगा। अगर link fixed हो तो share करना भी आसान रहेगा। बताने के लिए धन्यवाद, demo खत्म होने के बाद इसे लागू करके देखूंगा। धन्यवाद!
अभी उद्देश्य logic की sophistication से ज़्यादा यह दिखाना है कि “input डालने पर matching job posting सच में दिखाई देती है।” यह demo non-developer internal decision-makers के सामने है, इसलिए completeness से ज़्यादा काम करते हुए दिखाने पर focus है। Logic को advanced बनाना अगला step मान रहा हूँ।