.NET समझ में आता है, लेकिन मुझे लगता है कि Rust, Go जैसी ही स्थिति में है। शायद पहले से बने हुए JS-संबंधित Go प्रोजेक्ट्स और लाइब्रेरीज़ ने भी इस फैसले को प्रभावित किया होगा।
> अगर TypeScript कोड अब TypeScript में लिखा ही नहीं जाएगा, तो टीम खुद TypeScript का सीधे इस्तेमाल नहीं करेगी, और इससे लंबे समय में developer experience पर असर पड़ सकता है।
कहते हैं न, अपना ही बनाया हुआ खुद इस्तेमाल करना चाहिए। लेकिन language के मामले में यह थोड़ा सोचने वाली बात लगती है।
junit-vintage-engine का इस्तेमाल करने पर बिना बड़े बदलाव के JUnit4 tests को JUnit5 में चलाया जा सकता है, लेकिन overhead काफ़ी ज़्यादा है। (लगभग 20% तक धीमा हो जाता है)
अगर संयोग से Android app build engineer के तौर पर टिक गए किसी व्यक्ति की राय छोड़ूँ तो..
बिल्ड : gradle
चाहे वह बहुत बड़ा हो या जटिल, gradle ही इस्तेमाल करना चाहिए... (दूर देखते हुए)
बहुत बड़े या जटिल प्रोजेक्ट्स में gradle की build performance बेहतर करने के लिए नीचे दिए गए प्रोजेक्ट्स पर काम चल रहा है, इसलिए अगर आप बड़े प्रोजेक्ट में gradle इस्तेमाल कर रहे हैं, तो पहले से migration की तैयारी कर लेना अच्छा रहेगा.
मेरी निजी राय में architecture layer को बेवजह build system में उजागर करने की ज़रूरत नहीं है.
मेरे द्वारा मैनेज किए जाने वाले app में feature-api / feature-impl मॉड्यूल को build system में उजागर करने की संरचना रखी गई है.
feature-app :
डेटा मॉडल, या दूसरे मॉड्यूल्स से जुड़ने वाला interface
feature-impl:
feature का वास्तविक implementation
इस तरह संरचना करने पर feature-impl के code changes का feature-api को refer करने वाले दूसरे मॉड्यूल्स पर असर नहीं पड़ता (dependency isolation), इसलिए incremental build या build cache hit rate बढ़ाने में काफी मदद मिलती है.
यूनिट टेस्ट - junit 4
लगता है इसमें Google के फैसले ने बड़ी भूमिका निभाई है.
आजकल उपयोग की संख्या या समय को सीमित करने वाली सेवाएं फिर से ट्रेंड में आ रही हैं, लेकिन मुझे लगता है कि कहीं यह भी कुछ समय पहले लोकप्रिय हुए उस ऐप की तरह, जिसका नाम मुझे ठीक से याद नहीं है और जो किसी प्रसारण जैसा बोलने वाला ऐप था, बस थोड़ी देर चमककर फीका न पड़ जाए।
C# भाषा का डेवलपमेंट रुका नहीं है, लेकिन C# का इस्तेमाल करने वाले frameworks के साथ ऐसा बहुत ज़्यादा महसूस होता है कि उन्हें उपेक्षित छोड़ दिया गया है।
हम्म.. वैसे हाल के कुछ वर्षों में एक अजीब-सी प्रवृत्ति देखी जा रही है कि ज़्यादातर startup Flutter चुनते हैं, जबकि META, OpenAI जैसी बड़ी कंपनियाँ native की ओर जा रही हैं..
यह वाकई खुशखबरी है! हैरानी की बात है कि MS की TypeScript भाषा उम्मीद के उलट सच में काफी अप्रत्याशित(?) विकल्प चुनती दिखती है। MS के नज़रिए से देखें तो यह लगभग उसका पहला open source project था, और JS को replace करने की कोशिश करने वाले Google के Dart के विपरीत JS को complement करने का फैसला भी बहुत समझदारी भरा लगा। इस बार native porting language के लिए भी, जबकि उसके पास अपनी भाषाएँ भी काफी होंगी, Google के Go को चुनना भी चौंकाने वाला है।
McDonald's जाना आसान लगता है। यह एक मज़ेदार अनुभव होगा।
.NETसमझ में आता है, लेकिन मुझे लगता है कि Rust, Go जैसी ही स्थिति में है। शायद पहले से बने हुए JS-संबंधित Go प्रोजेक्ट्स और लाइब्रेरीज़ ने भी इस फैसले को प्रभावित किया होगा।वाकई यह एक बहुत ही नया आइडिया है, लेकिन दूसरे कमेंट्स की तरह यह भी जानने की जिज्ञासा है कि ट्रैफिक का दबाव बढ़ने पर इसे कैसे संभाला जाएगा।
मेरा ख्याल है कि आप Node जैसे runtime की बात कर रहे हैं, लेकिन यहाँ बात TS भाषा के compiler की हो रही है।
> अगर TypeScript कोड अब TypeScript में लिखा ही नहीं जाएगा, तो टीम खुद TypeScript का सीधे इस्तेमाल नहीं करेगी, और इससे लंबे समय में developer experience पर असर पड़ सकता है।
कहते हैं न, अपना ही बनाया हुआ खुद इस्तेमाल करना चाहिए। लेकिन language के मामले में यह थोड़ा सोचने वाली बात लगती है।
लेकिन अगर नवीनतम तकनीक(?) अपनानी हो, तो कई बार JUnit4 अड़चन बन जाता है, इसलिए व्यक्तिगत रूप से मेरी एक छोटी-सी इच्छा है कि JUnit5 पर माइग्रेशन हो जाए।
https://docs.gradle.com/develocity/test-distribution/
junit-vintage-engineका इस्तेमाल करने पर बिना बड़े बदलाव के JUnit4 tests को JUnit5 में चलाया जा सकता है, लेकिन overhead काफ़ी ज़्यादा है। (लगभग 20% तक धीमा हो जाता है)अगर संयोग से Android app build engineer के तौर पर टिक गए किसी व्यक्ति की राय छोड़ूँ तो..
चाहे वह बहुत बड़ा हो या जटिल, gradle ही इस्तेमाल करना चाहिए... (दूर देखते हुए) बहुत बड़े या जटिल प्रोजेक्ट्स में gradle की build performance बेहतर करने के लिए नीचे दिए गए प्रोजेक्ट्स पर काम चल रहा है, इसलिए अगर आप बड़े प्रोजेक्ट में gradle इस्तेमाल कर रहे हैं, तो पहले से migration की तैयारी कर लेना अच्छा रहेगा.
मेरी निजी राय में architecture layer को बेवजह build system में उजागर करने की ज़रूरत नहीं है. मेरे द्वारा मैनेज किए जाने वाले app में feature-api / feature-impl मॉड्यूल को build system में उजागर करने की संरचना रखी गई है.
इस तरह संरचना करने पर feature-impl के code changes का feature-api को refer करने वाले दूसरे मॉड्यूल्स पर असर नहीं पड़ता (dependency isolation), इसलिए incremental build या build cache hit rate बढ़ाने में काफी मदद मिलती है.
लगता है इसमें Google के फैसले ने बड़ी भूमिका निभाई है.
लगता है यह Clubhouse जैसा होगा, मेरे दिमाग में भी बिल्कुल वही बात आई थी।
आजकल उपयोग की संख्या या समय को सीमित करने वाली सेवाएं फिर से ट्रेंड में आ रही हैं, लेकिन मुझे लगता है कि कहीं यह भी कुछ समय पहले लोकप्रिय हुए उस ऐप की तरह, जिसका नाम मुझे ठीक से याद नहीं है और जो किसी प्रसारण जैसा बोलने वाला ऐप था, बस थोड़ी देर चमककर फीका न पड़ जाए।
वाह, हमारे परिवार के लिए गर्व की बात है।
उस समय ट्रैफ़िक बहुत ज़्यादा केंद्रित होगा, इसलिए इसे कुशलता से संभालने की ज़रूरत पड़ेगी।
मुझे चिंता है कि कहीं बाद में मौजूदा TypeScript codebase के रखरखाव की अनदेखी न होने लगे।
C# भाषा का डेवलपमेंट रुका नहीं है, लेकिन C# का इस्तेमाल करने वाले frameworks के साथ ऐसा बहुत ज़्यादा महसूस होता है कि उन्हें उपेक्षित छोड़ दिया गया है।
मैं इसका टेस्ट कर रहा हूँ, और यह किसी all-in-one gift set जैसा महसूस हो रहा है।
ऐसी मिलती-जुलती बातें बार-बार लिखी जाती हैं, लेकिन इंसानी लालच की कोई सीमा नहीं होती और हम वही गलतियाँ दोहराते रहते हैं
कंप्यूटर में CPU load का 100% सामान्य नहीं माना जाता,
लेकिन इंसानों के काम का load 100% हो तो निष्कर्ष निकलता है कि और ज़्यादा मेहनत करनी चाहिए..
हम्म.. वैसे हाल के कुछ वर्षों में एक अजीब-सी प्रवृत्ति देखी जा रही है कि ज़्यादातर startup Flutter चुनते हैं, जबकि META, OpenAI जैसी बड़ी कंपनियाँ native की ओर जा रही हैं..
सही कहा, लेकिन .NET डेवलपर्स की भावना भी मैं समझ सकता हूँ...
यह वाकई खुशखबरी है! हैरानी की बात है कि MS की TypeScript भाषा उम्मीद के उलट सच में काफी अप्रत्याशित(?) विकल्प चुनती दिखती है। MS के नज़रिए से देखें तो यह लगभग उसका पहला open source project था, और JS को replace करने की कोशिश करने वाले Google के Dart के विपरीत JS को complement करने का फैसला भी बहुत समझदारी भरा लगा। इस बार native porting language के लिए भी, जबकि उसके पास अपनी भाषाएँ भी काफी होंगी, Google के Go को चुनना भी चौंकाने वाला है।
लगता है .NET और Rust डेवलपर्स काफ़ी नाराज़ हो गए हैं
Brother, third-party printer ink cartridge के इस्तेमाल को रोकने वाला मजबूरी firmware update