अच्छा लगा कि SQL इंटरफ़ेस को एकसमान कर दिया गया है।

क्योंकि वह void(0) नाम की कंपनी थी, इसलिए शायद उसे BM की ज़रूरत रही होगी।

और जैसा घोषणा की गई थी, अगर skills marketplace भी आ जाता है, तो ज़रूरत के skill ही लेकर उन्हें ज़रूरत पड़ने पर enable करके रखना काफ़ी ठीक लग रहा था।

लगता है कि अब vite की लोकप्रियता को प्रोडक्ट के रूप में उतारने के चरण तक ले जाया जा रहा है..

इसका कोई कारण तो होगा कि Vite ने इसे मर्ज नहीं किया, लेकिन Bun के real-world उपयोग का अनुभव कैसा है, यह जानने की जिज्ञासा है।

कोडिंग में Claude Code इस्तेमाल करते समय भी क्या यह जुड़ने लायक हिस्सा हो सकता है, ऐसा लगता है।
अभी भी मैं Claude.md में गाइड डालकर रखता हूँ, और डिटेल्ड गाइड को अलग-अलग बांटकर आगे बढ़ा रहा हूँ।

ओह, मुख्य व्याख्या के लिए धन्यवाद।

असलियत यह है... उसे जानते हों तब भी, उससे आगे बहुत कुछ होता है...

कम टोकन में ज़्यादा काम करने के लिए मुझे लगता है कि prompt optimization की बजाय multi-agent और summarization का इस्तेमाल करने वाला तरीका इसे काफ़ी सरलता से हल कर सकता है। समस्या पर मैं सहमत हूँ, लेकिन समाधान का तरीका सीमित लगता है।

Claude Skills शानदार हैं, शायद MCP से भी बड़ा innovation हों

Context handling और Claude Skills का आपस में क्या संबंध हो सकता है? मुझे पहले लगा था कि यह बस पुराने Claude Code custom commands से अलग क्या है? लेकिन दस्तावेज़ पढ़ते-पढ़ते मुझे लगा कि सबसे बड़ा फर्क शायद यह है कि एक ही skill के अंदर Python या JavaScript जैसी script code को शामिल करके चलाया जा सकता है।

ऐसा लग रहा था कि context में पूरा SKILLS.md नहीं, बल्कि ऊपर की तरह सिर्फ नाम और description वाला हिस्सा ही हमेशा पहले शामिल होता है.

name: skill-creator
description: प्रभावी skills बनाने के लिए गाइड. इस skill का उपयोग तब किया जाना चाहिए जब users एक नया skill बनाना चाहते हों (या किसी मौजूदा skill को अपडेट करना चाहते हों) जो specialized knowledge, workflows, या tool integrations के साथ Claude की capabilities को बढ़ाता हो.
license: LICENSE.txt में पूरी शर्तें

फिर भी, आखिरकार लगता है कि उन्होंने अच्छा काम किया।

लगता है कि वे कंपनियों द्वारा बिछाई गई copper lines का इस्तेमाल करते हुए, या फिर विकल्प कहकर satellite dish से इंटरनेट चलाते हुए भी, free software की philosophy को ज़रूरत से ज़्यादा स्तर तक आगे बढ़ा रहे हैं.
यहाँ लिखी हुई सारी बातें पूरी हो जाएँ, तब भी वे शायद यह तय करेंगे कि open source ने जीत हासिल नहीं की है.

यह सच है कि Livewire मज़ेदार है, लेकिन UI थोड़ा भी जटिल होते ही यह हेल बन जाता है। उस पल से Phoenix अपनी खूबियाँ काफ़ी हद तक खो देता है। जैसे-जैसे साइकल लंबा होता जाता है, इसे संभालना और मुश्किल हो जाता है, इसलिए मैं इसे ज़्यादा recommend नहीं कर सकता।

क्या Skills भी tokens का उपयोग नहीं करते? अगर ऐसा है, तो लगता है कि token usage की समस्या फिर से आएगी, लेकिन उस समय इसका सामना कैसे करेंगे, यह मुझे ठीक से समझ नहीं आ रहा।

यह वाकई हद से ज़्यादा बढ़ा-चढ़ाकर कहना है

मैं भी कभी लगभग serverless का कट्टर समर्थक था और serverless आर्किटेक्चर को हर जगह लागू करता था, लेकिन इन दिनों मैं ec2 एक और rds एक से बनी संरचना को ज़्यादा पसंद करता हूँ। और फिर ज़रूरत के हिसाब से धीरे-धीरे चीज़ों को एक-एक करके अलग करता हूँ। serverless अपनाने के बारे में अब बहुत सोच-विचार करके ही फैसला करता हूँ.
इसके कई कारण हैं, लेकिन अगर टीम में सिर्फ एक भी ऐसा व्यक्ति हो जिसे serverless की जानकारी न हो, तो communication/maintenance की लागत काफ़ी बढ़ जाती है। और जब फिर से सर्वर चलाकर देखा, तो एक बार फिर महसूस हुआ कि serverless उतना सस्ता भी नहीं था और उतना सुविधाजनक भी नहीं था, जितना मैंने सोचा था।

Claude Code के साथ काम करते समय बार-बार निर्देश या नियमों को context में खिलाना पड़ता है, और आखिर में token usage और context के बीच संतुलन को लेकर सोचना पड़ता है। फिर मेरे मन में यह तरीका आया कि एक folder बनाया जाए, उसमें feature के हिसाब से अलग-अलग md files में विस्तृत बातें लिखी जाएँ, और claude.md में सिर्फ यह बताने वाले बहुत-से pointers रखे जाएँ कि क्या करना हो तो क्या देखना है। यह तरीका काफ़ी सस्ता और अच्छा चला। Skills भी आखिरकार ऐसे ही चीज़ों का संग्रह होगा, इसलिए यह काफ़ी काम का लग रहा है।

MSA, OneDrive, Copilot वगैरह... यूज़र के मुंह में इन्हें जबरदस्ती ठूंसना अब बंद करना चाहिए।