अरे, इस पोस्ट को देखकर मुझे पहली बार पता चला कि cppreference की Korean साइट भी है, तो खुशी हुई थी..
लगता है पहले की तरह English साइट ही इस्तेमाल करनी पड़ेगी।
3,197 मामलों को कारण के हिसाब से बाँटें तो तस्वीर ऐसी बनती है.
रिस्पॉन्स में ID फ़ील्ड ही नहीं है: 2,011 मामले (62.9%)
कॉल error से fail हुई: 1,037 मामले (32.4%)
रिस्पॉन्स में ID है, लेकिन हमारी mapping उसे पकड़ नहीं पाती: 149 मामले (4.7%)
यहाँ मैं एक बात सुधारना चाहूँगा। आपने पहले कहा था कि "ज़्यादातर duplicates उस हिस्से में हैं जहाँ tracking ही नहीं हो पाती", लेकिन 32% मामलों में तो कॉल fail हुई थी। कोई काम हुआ ही नहीं, इसलिए track करने के लिए कुछ है ही नहीं। सच में "कुछ हुआ, लेकिन track नहीं हो पाया" वाले मामले 2,011 हैं। यह अब भी बड़ा नंबर है, लेकिन 3,197 से छोटा है.
सिर्फ success/failure लौटाने वाले tools 24 थे। type के हिसाब से समूह करें तो:
इन 24 को दो तरह से बाँटा जा सकता है। यह spec design में काम आ सकता है, इसलिए जोड़ रहा हूँ.
वह पक्ष जहाँ ID दी ही नहीं जा सकती ब्राउज़र click या फ़ाइल editing में शुरू से कोई "generated entity" होती ही नहीं। click को ID नहीं दी जा सकती। फ़ाइल में path ही identifier है.
वह पक्ष जहाँ ID दी जा सकती है, लेकिन दी नहीं जाती github-create_repository इसका सबसे प्रतिनिधि उदाहरण है। अगर repository बनाई गई है, तो स्वाभाविक रूप से उसकी ID होती है, लेकिन response में नहीं है। emails-send_email में भी SMTP level पर message ID होती है, लेकिन वह लौटाई नहीं जाती। github-fork_repository और excel-write_data_to_excel भी ऐसे ही हैं.
दूसरी श्रेणी वही है जिसे ठीक किया जा सकता है। अगर आप internal tool spec में यह जोड़ें कि "creation-type operations में response में entity ID अनिवार्य है", तो यह विभाजन शायद यह तय करने का मानदंड बन सकता है कि इसे कहाँ लागू करना चाहिए.
आख़िरी 149 मामले हमारी mapping की समस्या हैं। notion database-query के 102 मामले, pptx open_presentation के 28 मामलों में ज़्यादा केंद्रित हैं, और दोनों ही वे tools हैं जिन्हें हमने जानबूझकर अपने scope से बाहर रखा था, इसलिए वे पकड़ में नहीं आए। यह tool design की समस्या नहीं, बल्कि हमारी coverage की समस्या है.
क्या आपकी मौजूदा production stack में write operations ज़्यादा किस तरफ़ केंद्रित हैं? हमने जो देखा वह benchmark था, इसलिए tool composition शायद वास्तविक production से अलग हो सकती है।
अगर आप रोज़ एक कदम भी आगे बढ़ सकते हैं, तो वही काफ़ी है.
उत्पादन आसान होता जा रहा है, सत्यापन अधिक परिष्कृत हो रहा है, और आखिरकार यह ऐसा दौर है जहाँ 'चयन' ही सबसे अहम बन जाता है. उसी अनुपात में, प्रवाह को ठीक-ठीक पढ़ लेने की दृष्टि पहले से भी ज़्यादा महत्वपूर्ण हो गई है.
आजकल coding agents अपनी कमियों की भरपाई करने में मदद कर सकते हैं, इसलिए अगर आप अपनी ताकतों को स्पष्ट रूप से समझकर उनका सही इस्तेमाल कर सकें, तो मुझे लगता है कि entry barrier कम हो सकता है।
मेरे लिए भी documentation हमेशा एक समस्या रही है, लेकिन जब मैंने उसका कुछ हिस्सा coding agent को सौंप दिया, तो बोझ कम हुआ। और उस documented सामग्री की समीक्षा करते-करते लगता है कि documentation को लेकर मेरी समझ भी विकसित हो रही है।
पढ़ने के लिए धन्यवाद! पहले दस्तावेज़, test cases, validation वगैरह जैसी कई चीज़ें थीं जिन पर लोगों को सीधे ध्यान देना पड़ता था, लेकिन अब काफ़ी बड़े हिस्से AI coding agents के साथ किए जा सकते हैं, इसलिए लगता है कि open source को maintain करने की कठिनाई भी पहले की तुलना में काफ़ी कम हो गई है!
हाँ, अगर सिर्फ clipboard history के हिसाब से देखें तो काफी overlap है। लेकिन Raycast में clipboard के अलावा भी बहुत सारे features हैं, इसलिए मुझे वह थोड़ा ज़्यादा भारी लगा।
मैंने जिन चीज़ों पर ध्यान दिया, वे ये हैं।
सबसे पहले, इसे हल्का रखा है और यह सिर्फ clipboard history को ही manage करता है; अभी इसका size करीब 2MB है।
और saved content को detail view में edit करके वापस रख सकते हैं। कई prompts को review करते समय और पहले से थोड़ा-थोड़ा tweak करते समय यह सुविधाजनक लगा।
Search और folders पर भी ध्यान दिया है। काम करते समय ज़रूरी जानकारी—जो one-time हो या जिसे फिर से ढूँढना झंझट लगे—उसकी समस्या हल करने की कोशिश की है।
Body, tags, title आदि से search करने योग्य बनाया है।
आगे चलकर मैं plugins के जरिए features या layouts को सीधे जोड़ने की सुविधा देना चाहता हूँ, लेकिन यह अभी पूरी तरह concretize नहीं हुआ है।
मुझे Raycast भी एक अच्छा app लगता है, और मैं कोशिश करना चाहता हूँ कि यह personal preference के हिसाब से एक विकल्प बन सके।
ऐसे tools में सबसे मुश्किल काम बनाना नहीं, बल्कि हटाना होता है, इसलिए garden को अलग lifecycle में बाँटना खास तौर पर ध्यान खींचता है.
एजेंट को दिया जाने वाला context पुराना हो जाए तो वह सिर्फ बेकार नहीं होता, बल्कि नुकसानदेह भी हो जाता है. इंसान दस्तावेज़ देखकर अंदाज़ा लगा लेता है कि "यह शायद पुरानी बात है", लेकिन मॉडल के पास वह समझ नहीं होती, इसलिए 3 महीने पहले सही रही किसी invariant condition को वह आज भी वैसा ही सही मानकर इस्तेमाल कर लेता है. कोड हो तो कम-से-कम compile टूट जाता है, लेकिन wiki चुपचाप गलत होती रहती है.
इसीलिए मुझे यह जानने की उत्सुकता है कि क्या पेज पर यह जुड़ता है कि वह किस समय को आधार मानकर लिखा गया है, और किस आधार पर लिखा गया है. इसे Markdown में repository में रखकर Git में review कराने का फैसला मुझे उस लिहाज़ से सही लगता है, लेकिन diff में यह दर्ज होता है कि दस्तावेज़ कब बदला, यह नहीं कि उसकी सामग्री कब तक वैध रही.
1,700 एंट्री के स्तर पर performance की बात practically मायने नहीं रखती; frontend पर सीधे process करें या backend रखें, दोनों ही तुरंत चलेंगे। इसलिए मेरा मानना है कि निर्णय का आधार speed नहीं, बल्कि यह होना चाहिए कि मौजूदा Python logic को दोबारा लिखना है या नहीं।
उस आधार पर Streamlit सबसे उपयुक्त लगता है। matching logic को वैसे ही import करके इस्तेमाल कर सकते हैं, और UI में 5 selectbox व एक result table हो तो काम पूरा हो जाता है, इसलिए frontend code लिखने की ज़रूरत नहीं पड़ती। इसे Streamlit Community Cloud पर deploy करें तो share करने लायक link भी मुफ्त में मिल जाता है, और अगर JSON को runtime पर read करने के लिए रखें तो सिर्फ file बदलने से ही नया data reflect हो जाएगा।
Static HTML का deployment ज़्यादा आसान है, लेकिन उसके बदले Python logic को JS में ले जाना पड़ेगा। अगर score calculation थोड़ा भी complex हुआ, तो वही porting कई दिन खा जाएगी। अगर लक्ष्य इस हफ्ते के भीतर working demo दिखाना है, तो मुझे लगता है वह risk न लेना ही बेहतर है।
एक बात और, Streamlit आखिरकार product से ज़्यादा एक tool जैसा दिखता है। अगर यह internal decision-makers के लिए demo है और उद्देश्य सिर्फ यह verify करना है कि "input देने पर सच में result आता है", तो कोई दिक्कत नहीं; लेकिन अगर यह external customer demo है, तो इस बात को ध्यान में रखना होगा.
ओह... Show GN पोस्ट्स में मैं हमेशा सिर्फ़ 'कुछ बनाया' से आगे बढ़कर ऐसे insights भी साथ में देखना चाहता था, इसलिए ऐसी पोस्ट देखकर काफ़ी उत्साहित हूँ haha
हर मामले के लिए अलग-अलग expert ढूँढकर सिर्फ़ उनके scope का काम सौंपने के बजाय, लोगों की psychology यही होती है कि एक ही व्यक्ति को दे दें और वह अपने-आप सब कुछ अच्छे से संभाल ले।
LLM में भी reward function शायद ऐसा ही बनाया जाएगा कि आप कुछ भी फेंक दें, वह सब स्वीकार कर ले, है ना?
मुफ़्त ऐप्स भी बहुत हैं और बनाना भी आसान है, तो अगर यह paid app है तो... हम्म...
जानकारी देने के लिए धन्यवाद। सुधार कर दिया गया है!!
तकनीकी श्वेतपत्र लिंक पर 404 आ रहा है!
https://edge.apt-insights.com/v1/public/whitepaper
अरे, इस पोस्ट को देखकर मुझे पहली बार पता चला कि cppreference की Korean साइट भी है, तो खुशी हुई थी.. लगता है पहले की तरह English साइट ही इस्तेमाल करनी पड़ेगी।
अरे, मैंने Windows काफ़ी समय से इस्तेमाल नहीं किया, इसलिए ठीक से पता नहीं था। ढूँढकर देखा तो यह काफ़ी मिलता-जुलता लगता है।
3,197 मामलों को कारण के हिसाब से बाँटें तो तस्वीर ऐसी बनती है.
रिस्पॉन्स में ID फ़ील्ड ही नहीं है: 2,011 मामले (62.9%)
कॉल error से fail हुई: 1,037 मामले (32.4%)
रिस्पॉन्स में ID है, लेकिन हमारी mapping उसे पकड़ नहीं पाती: 149 मामले (4.7%)
यहाँ मैं एक बात सुधारना चाहूँगा। आपने पहले कहा था कि "ज़्यादातर duplicates उस हिस्से में हैं जहाँ tracking ही नहीं हो पाती", लेकिन 32% मामलों में तो कॉल fail हुई थी। कोई काम हुआ ही नहीं, इसलिए track करने के लिए कुछ है ही नहीं। सच में "कुछ हुआ, लेकिन track नहीं हो पाया" वाले मामले 2,011 हैं। यह अब भी बड़ा नंबर है, लेकिन 3,197 से छोटा है.
सिर्फ success/failure लौटाने वाले tools 24 थे। type के हिसाब से समूह करें तो:
ब्राउज़र ऑपरेशन (9) — click, type, navigate आदि। सिर्फ click ही 719 मामले
फ़ाइल सिस्टम (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
डॉक्यूमेंट एडिटिंग (3) — add_paragraph, add_heading, format_text
अलग-अलग — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
इन 24 को दो तरह से बाँटा जा सकता है। यह spec design में काम आ सकता है, इसलिए जोड़ रहा हूँ.
वह पक्ष जहाँ ID दी ही नहीं जा सकती ब्राउज़र click या फ़ाइल editing में शुरू से कोई "generated entity" होती ही नहीं। click को ID नहीं दी जा सकती। फ़ाइल में path ही identifier है.
वह पक्ष जहाँ ID दी जा सकती है, लेकिन दी नहीं जाती github-create_repository इसका सबसे प्रतिनिधि उदाहरण है। अगर repository बनाई गई है, तो स्वाभाविक रूप से उसकी ID होती है, लेकिन response में नहीं है। emails-send_email में भी SMTP level पर message ID होती है, लेकिन वह लौटाई नहीं जाती। github-fork_repository और excel-write_data_to_excel भी ऐसे ही हैं.
दूसरी श्रेणी वही है जिसे ठीक किया जा सकता है। अगर आप internal tool spec में यह जोड़ें कि "creation-type operations में response में entity ID अनिवार्य है", तो यह विभाजन शायद यह तय करने का मानदंड बन सकता है कि इसे कहाँ लागू करना चाहिए.
आख़िरी 149 मामले हमारी mapping की समस्या हैं। notion database-query के 102 मामले, pptx open_presentation के 28 मामलों में ज़्यादा केंद्रित हैं, और दोनों ही वे tools हैं जिन्हें हमने जानबूझकर अपने scope से बाहर रखा था, इसलिए वे पकड़ में नहीं आए। यह tool design की समस्या नहीं, बल्कि हमारी coverage की समस्या है.
क्या आपकी मौजूदा production stack में write operations ज़्यादा किस तरफ़ केंद्रित हैं? हमने जो देखा वह benchmark था, इसलिए tool composition शायद वास्तविक production से अलग हो सकती है।
कोरियाई संस्करण का आखिरी अपडेट 2016 में हुआ था, इसलिए लगता है कि मूल स्रोत देखना बेहतर होगा
अगर आप रोज़ एक कदम भी आगे बढ़ सकते हैं, तो वही काफ़ी है.
उत्पादन आसान होता जा रहा है, सत्यापन अधिक परिष्कृत हो रहा है, और आखिरकार यह ऐसा दौर है जहाँ 'चयन' ही सबसे अहम बन जाता है. उसी अनुपात में, प्रवाह को ठीक-ठीक पढ़ लेने की दृष्टि पहले से भी ज़्यादा महत्वपूर्ण हो गई है.
क्या यह Windows की बिल्ट-इन सुविधा जैसा है? Windows + V
वाह, अगर बस यह एक चीज़ हो तो role-play जैसी चीज़ों की चिंता नहीं करनी पड़ेगी।
ओह, मैंने इसे ठीक कर दिया है।
आजकल coding agents अपनी कमियों की भरपाई करने में मदद कर सकते हैं, इसलिए अगर आप अपनी ताकतों को स्पष्ट रूप से समझकर उनका सही इस्तेमाल कर सकें, तो मुझे लगता है कि entry barrier कम हो सकता है।
मेरे लिए भी documentation हमेशा एक समस्या रही है, लेकिन जब मैंने उसका कुछ हिस्सा coding agent को सौंप दिया, तो बोझ कम हुआ। और उस documented सामग्री की समीक्षा करते-करते लगता है कि documentation को लेकर मेरी समझ भी विकसित हो रही है।
पढ़ने के लिए धन्यवाद! पहले दस्तावेज़, test cases, validation वगैरह जैसी कई चीज़ें थीं जिन पर लोगों को सीधे ध्यान देना पड़ता था, लेकिन अब काफ़ी बड़े हिस्से AI coding agents के साथ किए जा सकते हैं, इसलिए लगता है कि open source को maintain करने की कठिनाई भी पहले की तुलना में काफ़ी कम हो गई है!
@xguru लगता है लिंक गलत है~
हाँ, अगर सिर्फ clipboard history के हिसाब से देखें तो काफी overlap है। लेकिन Raycast में clipboard के अलावा भी बहुत सारे features हैं, इसलिए मुझे वह थोड़ा ज़्यादा भारी लगा।
मैंने जिन चीज़ों पर ध्यान दिया, वे ये हैं।
सबसे पहले, इसे हल्का रखा है और यह सिर्फ clipboard history को ही manage करता है; अभी इसका size करीब 2MB है।
और saved content को detail view में edit करके वापस रख सकते हैं। कई prompts को review करते समय और पहले से थोड़ा-थोड़ा tweak करते समय यह सुविधाजनक लगा।
Search और folders पर भी ध्यान दिया है। काम करते समय ज़रूरी जानकारी—जो one-time हो या जिसे फिर से ढूँढना झंझट लगे—उसकी समस्या हल करने की कोशिश की है।
Body, tags, title आदि से search करने योग्य बनाया है।
आगे चलकर मैं plugins के जरिए features या layouts को सीधे जोड़ने की सुविधा देना चाहता हूँ, लेकिन यह अभी पूरी तरह concretize नहीं हुआ है।
मुझे Raycast भी एक अच्छा app लगता है, और मैं कोशिश करना चाहता हूँ कि यह personal preference के हिसाब से एक विकल्प बन सके।
आपकी राय के लिए धन्यवाद।
ऐसे tools में सबसे मुश्किल काम बनाना नहीं, बल्कि हटाना होता है, इसलिए
gardenको अलग lifecycle में बाँटना खास तौर पर ध्यान खींचता है.एजेंट को दिया जाने वाला context पुराना हो जाए तो वह सिर्फ बेकार नहीं होता, बल्कि नुकसानदेह भी हो जाता है. इंसान दस्तावेज़ देखकर अंदाज़ा लगा लेता है कि "यह शायद पुरानी बात है", लेकिन मॉडल के पास वह समझ नहीं होती, इसलिए 3 महीने पहले सही रही किसी invariant condition को वह आज भी वैसा ही सही मानकर इस्तेमाल कर लेता है. कोड हो तो कम-से-कम compile टूट जाता है, लेकिन wiki चुपचाप गलत होती रहती है.
इसीलिए मुझे यह जानने की उत्सुकता है कि क्या पेज पर यह जुड़ता है कि वह किस समय को आधार मानकर लिखा गया है, और किस आधार पर लिखा गया है. इसे Markdown में repository में रखकर Git में review कराने का फैसला मुझे उस लिहाज़ से सही लगता है, लेकिन diff में यह दर्ज होता है कि दस्तावेज़ कब बदला, यह नहीं कि उसकी सामग्री कब तक वैध रही.
1,700 एंट्री के स्तर पर performance की बात practically मायने नहीं रखती; frontend पर सीधे process करें या backend रखें, दोनों ही तुरंत चलेंगे। इसलिए मेरा मानना है कि निर्णय का आधार speed नहीं, बल्कि यह होना चाहिए कि मौजूदा Python logic को दोबारा लिखना है या नहीं।
उस आधार पर Streamlit सबसे उपयुक्त लगता है। matching logic को वैसे ही import करके इस्तेमाल कर सकते हैं, और UI में 5
selectboxव एक result table हो तो काम पूरा हो जाता है, इसलिए frontend code लिखने की ज़रूरत नहीं पड़ती। इसे Streamlit Community Cloud पर deploy करें तो share करने लायक link भी मुफ्त में मिल जाता है, और अगर JSON को runtime पर read करने के लिए रखें तो सिर्फ file बदलने से ही नया data reflect हो जाएगा।Static HTML का deployment ज़्यादा आसान है, लेकिन उसके बदले Python logic को JS में ले जाना पड़ेगा। अगर score calculation थोड़ा भी complex हुआ, तो वही porting कई दिन खा जाएगी। अगर लक्ष्य इस हफ्ते के भीतर working demo दिखाना है, तो मुझे लगता है वह risk न लेना ही बेहतर है।
एक बात और, Streamlit आखिरकार product से ज़्यादा एक tool जैसा दिखता है। अगर यह internal decision-makers के लिए demo है और उद्देश्य सिर्फ यह verify करना है कि "input देने पर सच में result आता है", तो कोई दिक्कत नहीं; लेकिन अगर यह external customer demo है, तो इस बात को ध्यान में रखना होगा.
लगता है कि इसमें Raycast के लगभग सभी फीचर्स सपोर्ट हैं, तो क्या बता सकते हैं कि फर्क किस बात में है?
ओह... Show GN पोस्ट्स में मैं हमेशा सिर्फ़ 'कुछ बनाया' से आगे बढ़कर ऐसे insights भी साथ में देखना चाहता था, इसलिए ऐसी पोस्ट देखकर काफ़ी उत्साहित हूँ haha
हर मामले के लिए अलग-अलग expert ढूँढकर सिर्फ़ उनके scope का काम सौंपने के बजाय, लोगों की psychology यही होती है कि एक ही व्यक्ति को दे दें और वह अपने-आप सब कुछ अच्छे से संभाल ले।
LLM में भी reward function शायद ऐसा ही बनाया जाएगा कि आप कुछ भी फेंक दें, वह सब स्वीकार कर ले, है ना?