यह काफ़ी हद तक उस देश के श्रम क़ानून के मानकों से जुड़ा होता है.. अमेरिका की बहुत-सी कंपनियाँ आम तौर पर इसे बस बारी-बारी से करती हैं, और जब किसी समय यह संभव नहीं होता तो क्रम बदल देती हैं। यह मुश्किल काम है, इसलिए.. कुछ कंपनियों में dedicated on-call टीम भी होती है.
यूरोप में तो सिर्फ़ काम की प्रकृति बदल जाने या overtime होने की वजह से ही लगभग अलग से compensation दिया जाता है.
हमारे यहाँ तो comprehensive wage system के जाल में फँसकर इसे बस जैसे-तैसे निपटा दिया जाता है। on-call भी साफ़ तौर पर काम ही है, लेकिन उस समय के लिए मिलने वाला भत्ता मानो कोई welfare benefit हो, ऐसा पैकेज करके पेश किया जाता है।
असल में उन सभी services को इस्तेमाल करना भी मुश्किल होगा, लेकिन इसमें MCP होना एक बड़ा फ़ायदा है।
आगे चलकर अगर API maintenance अच्छी तरह होती रही, तो यह उपयोगी लग रहा है।
Apple का hardware बेहतरीन है, लेकिन उसका software उपयोगकर्ताओं को बाँधकर रखने की मंशा से भरा हुआ है.
आप अपनी बनाई और build की हुई app को सिर्फ अपने ही device पर चलाना चाहें, तब भी 100 डॉलर का subscription चाहिए.
अगर आप छोटे या मध्यम स्तर के open source apps इस्तेमाल करते हैं और उन्हें खुद build करके चलाने वाले developer हैं,
तो Apple के device पर vulnerability का फायदा उठाकर jailbreak करके sideload करने से बेहतर है कि बस Android इस्तेमाल करें.
[लिंक हटाया गया] Android version का screenshot यहाँ डाल रखा है। जितना ज़्यादा इस्तेमाल करते हैं, यह उतना ही अजीब-सा लेकिन दिलचस्प tool लगता है। community भी geeky है और इसमें हैरान करने वाली कई बातें हैं।
अगर सिर्फ Emacs हो, तो इससे तरह-तरह के काम किए जा सकते हैं। हाल ही में यह Android पर भी इंस्टॉल होने लगा है, इसलिए desktop वाली वही सुविधाएँ ज्यों की त्यों इस्तेमाल कर पाना अच्छा लगता है। मैं इन दिनों Emacs knowledge management tool के विषय पर गहराई से काम कर रहा हूँ। मेरा बच्चा अभी kindergarten में जाता है; जब वह primary school जाएगा, तब तक शायद मैं Emacs से lifelogging bhi kar raha hoonga haha. क्योंकि सिर्फ एक ही tool सीखना होता है, इसलिए लंबी अवधि में देखें तो यह चिंताओं को कम करने का काम है.
लेकिन अगर आप बस यूज़र को obfuscation के सिद्धांत के बारे में बता देते, और यह कहकर सेवा देते कि किसी खास model से इसे bypass किया जा सकता है, इस तरह का disclaimer मान लेने के बाद, तो शायद refund देने की ज़रूरत नहीं पड़ती—आप सचमुच यूज़र्स का बहुत ख़याल रखते हैं haha
रिफैक्टरिंग करते समय अक्सर tsserver की code parsing धीमी हो जाती थी, जिससे पूरा editor ही फ्रीज़ हो जाता था। उम्मीद है यह जल्दी आए और इस परेशानी से छुटकारा मिले।
मुझे लगा कि लोग structural typing के बारे में सोचे बिना ही बात उछाल रहे हैं।
इसे C# या Rust जैसी nominal typing वाली भाषा में फिर से लिखना हो, तो प्रोजेक्ट की बुनियादी संरचना में बहुत ज़्यादा बदलाव करने पड़ते, इसलिए यह आसान नहीं रहा होगा।
structural typing अपनाने वाली भाषाओं में, मौजूदा JS-आधारित विकल्पों से बेहतर performance देने वाली चीज़ शायद C++ या Golang ही हो सकती है, लेकिन productivity तक को ध्यान में रखें तो कोई वास्तविक विकल्प नहीं है।
यह काफ़ी हद तक उस देश के श्रम क़ानून के मानकों से जुड़ा होता है.. अमेरिका की बहुत-सी कंपनियाँ आम तौर पर इसे बस बारी-बारी से करती हैं, और जब किसी समय यह संभव नहीं होता तो क्रम बदल देती हैं। यह मुश्किल काम है, इसलिए.. कुछ कंपनियों में dedicated on-call टीम भी होती है.
यूरोप में तो सिर्फ़ काम की प्रकृति बदल जाने या overtime होने की वजह से ही लगभग अलग से compensation दिया जाता है.
हमारे यहाँ तो comprehensive wage system के जाल में फँसकर इसे बस जैसे-तैसे निपटा दिया जाता है। on-call भी साफ़ तौर पर काम ही है, लेकिन उस समय के लिए मिलने वाला भत्ता मानो कोई welfare benefit हो, ऐसा पैकेज करके पेश किया जाता है।
असल में उन सभी services को इस्तेमाल करना भी मुश्किल होगा, लेकिन इसमें MCP होना एक बड़ा फ़ायदा है।
आगे चलकर अगर API maintenance अच्छी तरह होती रही, तो यह उपयोगी लग रहा है।
Apple का hardware बेहतरीन है, लेकिन उसका software उपयोगकर्ताओं को बाँधकर रखने की मंशा से भरा हुआ है.
आप अपनी बनाई और build की हुई app को सिर्फ अपने ही device पर चलाना चाहें, तब भी 100 डॉलर का subscription चाहिए.
अगर आप छोटे या मध्यम स्तर के open source apps इस्तेमाल करते हैं और उन्हें खुद build करके चलाने वाले developer हैं,
तो Apple के device पर vulnerability का फायदा उठाकर jailbreak करके sideload करने से बेहतर है कि बस Android इस्तेमाल करें.
हमारे यहाँ ऑन-कॉल के लिए प्रति घंटा वेतन का आधा, communication खर्च के लिए सहायता, और सपोर्ट के समय को overtime मानकर 1.5 गुना भुगतान किया जाता था।
बीच में C# गैंग छिपा हुआ है।
> साफ़ कहें तो आज Java development करते समय ज़रूरी नहीं कि JetBrains के products ही इस्तेमाल किए जाएँ, लेकिन
इस हिस्से से... थोड़ी सहमति जताना मुश्किल है, हाय...
[लिंक हटाया गया] Android version का screenshot यहाँ डाल रखा है। जितना ज़्यादा इस्तेमाल करते हैं, यह उतना ही अजीब-सा लेकिन दिलचस्प tool लगता है। community भी geeky है और इसमें हैरान करने वाली कई बातें हैं।
अगर सिर्फ Emacs हो, तो इससे तरह-तरह के काम किए जा सकते हैं। हाल ही में यह Android पर भी इंस्टॉल होने लगा है, इसलिए desktop वाली वही सुविधाएँ ज्यों की त्यों इस्तेमाल कर पाना अच्छा लगता है। मैं इन दिनों Emacs knowledge management tool के विषय पर गहराई से काम कर रहा हूँ। मेरा बच्चा अभी kindergarten में जाता है; जब वह primary school जाएगा, तब तक शायद मैं Emacs से lifelogging bhi kar raha hoonga haha. क्योंकि सिर्फ एक ही tool सीखना होता है, इसलिए लंबी अवधि में देखें तो यह चिंताओं को कम करने का काम है.
[लिंक हटाया गया]
लेकिन अगर आप बस यूज़र को obfuscation के सिद्धांत के बारे में बता देते, और यह कहकर सेवा देते कि किसी खास model से इसे bypass किया जा सकता है, इस तरह का disclaimer मान लेने के बाद, तो शायद refund देने की ज़रूरत नहीं पड़ती—आप सचमुच यूज़र्स का बहुत ख़याल रखते हैं haha
यह आजकल मेरी चिंताओं का जवाब देने वाला लेख था। इतना अच्छा लेख साझा करने के लिए धन्यवाद।
मैं
lspको सीधे build करके इस्तेमाल कर रहा हूँ। इसे Go में बदलने के बाद resources की खपत कम हुई है, यह काफ़ी स्पष्ट रूप से महसूस होता है।आजकल लोगों की छंटनी करके और मुश्किल हो चुके मेंटेनेंस को open source बनाकर कम्युनिटी पर थोपने जैसा लग रहा है।
ओह कमाल, आखिरकार...!!!
MS वाकई कमाल है
आजकल सिर्फ़ js को rust / go में शिफ्ट करके performance बढ़ाना ही ट्रेंड में है
ओह, कमाल
रिफैक्टरिंग करते समय अक्सर tsserver की code parsing धीमी हो जाती थी, जिससे पूरा editor ही फ्रीज़ हो जाता था। उम्मीद है यह जल्दी आए और इस परेशानी से छुटकारा मिले।
मुझे लगा कि लोग structural typing के बारे में सोचे बिना ही बात उछाल रहे हैं।
इसे C# या Rust जैसी nominal typing वाली भाषा में फिर से लिखना हो, तो प्रोजेक्ट की बुनियादी संरचना में बहुत ज़्यादा बदलाव करने पड़ते, इसलिए यह आसान नहीं रहा होगा।
structural typing अपनाने वाली भाषाओं में, मौजूदा JS-आधारित विकल्पों से बेहतर performance देने वाली चीज़ शायद C++ या Golang ही हो सकती है, लेकिन productivity तक को ध्यान में रखें तो कोई वास्तविक विकल्प नहीं है।
लगता है कि multi-write सक्षम Oracle RAC या Db2 pureScale जैसे commercial products पर विचार नहीं किया गया।
काली करतूतों को बहुत, बहुत बड़े पैमाने पर...