हम 80% काम और 20% खाली स्पेस रखने की कोशिश तो करते हैं, लेकिन इसका मानदंड क्या हो, इसे लेकर हर बार सोचना पड़ता है। कभी-कभी लगता है कि शायद इसे सिर्फ समय के आधार पर तय करना चाहिए।
जब मैं शंघाई में कुछ समय, करीब एक साल, रहा था, तब एक बार हांगझोउ घूमने गया था (उस समय शायद किसी impression performance जैसी चीज़ देखने)। शहर भी साफ़-सुथरा था और West Lake का नज़ारा भी बहुत अच्छा था, इसलिए लगा था कि वहाँ रहना वाकई बहुत अच्छा होगा। अब लगता है कि वह बिज़नेस करने के लिए भी एक अच्छी जगह बन गया है।
SWC का फोकस Babel की तरह compatible JavaScript code जनरेट करने और bundling तक है, जबकि इसका फोकस TypeScript code को JavaScript में बदलने या errors को check करने पर है.
जब सरल लेकिन याद रखना मुश्किल कोड लिखना हो (जैसे file I/O handling, containers को संभालना आदि)
जब compile या runtime error आए और यह समझना हो कि यह किस तरह की error है और किस code की वजह से हुई है
जब पहले से लिखे हुए function से मिलता-जुलता, लेकिन थोड़ा अलग feature वाला function फिर से लिखना हो
जब किसी library पर निर्भर code को दूसरी library से बदलना हो या अपने खुद के function से replace करना हो
जब किसी specific feature को implement करना हो, या किसी specific environment में काम करना हो और यह समझने के लिए guidance चाहिए कि development किस तरह किया जाए
ऊपर जैसे मामलों में काफ़ी समय बचा है। कई बार Google + Stack Overflow के combination से भी चीज़ें आसानी से नहीं मिलतीं, और खासकर Stack Overflow पर अगर कोई answer होता भी है, तो comments में उस पर बहुत आपत्तियाँ आ जाती हैं, या यह कहा जाता है कि वह पुराने version का implementation तरीका है इसलिए उसे इस्तेमाल नहीं करना चाहिए — ऐसी वजहों से काफ़ी झुंझलाहट होती थी...
अगर इसे 1-2 हफ्तों में बांटा जाए, तो स्वाभाविक रूप से ऐसा लगता है कि किसी एक फीचर की पूरी तस्वीर सिर्फ सीमित लोग ही जान पाएंगे। कुछ वैसा ही जैसे process और thread के बीच का अंतर। क्योंकि फोकस को सीमित करके productivity बढ़ाई जा रही है.
भले ही पूरी तस्वीर साझा की जाए, यह मानकर चलना होगा कि लोग उस तस्वीर पर सवाल उठाएंगे। लेकिन मुझे लगता है कि मैंने स्वाभाविक रूप से यह भी मान लिया था कि हर sprint planning में थोड़ा-थोड़ा बदलती दिशा के साथ लोग इस बड़ी तस्वीर को कैसे ट्रैक कर रहे हैं, इसे वे ठीक से मिला नहीं पाएंगे.
जब काम को इतने छोटे tasks में बाँट दिया जाता है, तो बड़ी तस्वीर देखने वाला leader बहुत अधिक अधिकार अपने हाथ में ले लेता है। साथ काम कर रहे engineers उल्टा demotivated हो जाते हैं और सोचते हैं, "हम आखिर जा कहाँ रहे हैं?" यह sprint-based agile की सबसे प्रतिनिधि कमियों में से एक है.
यह लेख शायद title की तरह ही बहुत ज़्यादा leader के नज़रिए से लिखा गया लगता है.
engineer का momentum इस बात से भी बहुत प्रभावित होता है कि leader झंडा किस दिशा में उठा रहा है। customer को कौन-सी value देनी है, और हर sprint में output तथा delivery outcome क्या है, इसे प्रस्तुत करने के तरीकों पर भी थोड़ा और विचार करने की ज़रूरत लगती है। बेशक यह एक कठिन soft skill है, इसलिए इसे सही ढंग से करने वाले leaders भी कम दिखते हैं और इस पर अच्छे लेख भी बहुत कम हैं.
.NET समझ में आता है, लेकिन मुझे लगता है कि Rust, Go जैसी ही स्थिति में है। शायद पहले से बने हुए JS-संबंधित Go प्रोजेक्ट्स और लाइब्रेरीज़ ने भी इस फैसले को प्रभावित किया होगा।
हम 80% काम और 20% खाली स्पेस रखने की कोशिश तो करते हैं, लेकिन इसका मानदंड क्या हो, इसे लेकर हर बार सोचना पड़ता है। कभी-कभी लगता है कि शायद इसे सिर्फ समय के आधार पर तय करना चाहिए।
जब मैं शंघाई में कुछ समय, करीब एक साल, रहा था, तब एक बार हांगझोउ घूमने गया था (उस समय शायद किसी impression performance जैसी चीज़ देखने)। शहर भी साफ़-सुथरा था और West Lake का नज़ारा भी बहुत अच्छा था, इसलिए लगा था कि वहाँ रहना वाकई बहुत अच्छा होगा। अब लगता है कि वह बिज़नेस करने के लिए भी एक अच्छी जगह बन गया है।
कोरियन performance के बारे में कोई जानकारी नहीं है, लेकिन निकालकर देखा तो यह बुरा नहीं लगता।
अगर इसमें anti-macro prevention को bypass करने की क्षमता हो, तो लगता है कि यह बाज़ार का विजेता बन सकता है।
लगता है विवाद काफ़ी गर्म है, इसलिए Anders Hejlsberg ने खुद आकर टिप्पणी छोड़ी है
https://github.com/microsoft/typescript-go/…
हाँ, वही वाला!
एक व्यक्ति जो चाहता है कि TypeScript में compile करने पर आउटपुट सीधे binary के रूप में मिले
अच्छी सामग्री का परिचय देने के लिए धन्यवाद।
SWC का फोकस Babel की तरह compatible JavaScript code जनरेट करने और bundling तक है, जबकि इसका फोकस TypeScript code को JavaScript में बदलने या errors को check करने पर है.
मेरा अनुभव भी काफ़ी हद तक ऐसा ही रहा है.
ऊपर जैसे मामलों में काफ़ी समय बचा है। कई बार Google + Stack Overflow के combination से भी चीज़ें आसानी से नहीं मिलतीं, और खासकर Stack Overflow पर अगर कोई answer होता भी है, तो comments में उस पर बहुत आपत्तियाँ आ जाती हैं, या यह कहा जाता है कि वह पुराने version का implementation तरीका है इसलिए उसे इस्तेमाल नहीं करना चाहिए — ऐसी वजहों से काफ़ी झुंझलाहट होती थी...
अगर इसे 1-2 हफ्तों में बांटा जाए, तो स्वाभाविक रूप से ऐसा लगता है कि किसी एक फीचर की पूरी तस्वीर सिर्फ सीमित लोग ही जान पाएंगे। कुछ वैसा ही जैसे process और thread के बीच का अंतर। क्योंकि फोकस को सीमित करके productivity बढ़ाई जा रही है.
भले ही पूरी तस्वीर साझा की जाए, यह मानकर चलना होगा कि लोग उस तस्वीर पर सवाल उठाएंगे। लेकिन मुझे लगता है कि मैंने स्वाभाविक रूप से यह भी मान लिया था कि हर sprint planning में थोड़ा-थोड़ा बदलती दिशा के साथ लोग इस बड़ी तस्वीर को कैसे ट्रैक कर रहे हैं, इसे वे ठीक से मिला नहीं पाएंगे.
क्या बड़ी तस्वीर साझा करके, और यह सुनिश्चित करके कि सभी लोग समझ रहे हों, काम को छोटे-छोटे tasks में बाँटना ही सही तरीका नहीं होगा??
अच्छे लेख के लिए धन्यवाद
जब काम को इतने छोटे tasks में बाँट दिया जाता है, तो बड़ी तस्वीर देखने वाला leader बहुत अधिक अधिकार अपने हाथ में ले लेता है। साथ काम कर रहे engineers उल्टा demotivated हो जाते हैं और सोचते हैं, "हम आखिर जा कहाँ रहे हैं?" यह sprint-based agile की सबसे प्रतिनिधि कमियों में से एक है.
यह लेख शायद title की तरह ही बहुत ज़्यादा leader के नज़रिए से लिखा गया लगता है.
engineer का momentum इस बात से भी बहुत प्रभावित होता है कि leader झंडा किस दिशा में उठा रहा है। customer को कौन-सी value देनी है, और हर sprint में output तथा delivery outcome क्या है, इसे प्रस्तुत करने के तरीकों पर भी थोड़ा और विचार करने की ज़रूरत लगती है। बेशक यह एक कठिन soft skill है, इसलिए इसे सही ढंग से करने वाले leaders भी कम दिखते हैं और इस पर अच्छे लेख भी बहुत कम हैं.
फ़्रंटएंड के बारे में मुझे ज़्यादा जानकारी नहीं है.. क्या यह
swcसे अलग है?अभी सुबह के 8 बजकर 40 मिनट हैं, लेकिन यूँ ही देखा तो ठीक 7:40:28 PM EST दिख रहा है... कमाल है
McDonald's जाना आसान लगता है। यह एक मज़ेदार अनुभव होगा।
.NETसमझ में आता है, लेकिन मुझे लगता है कि Rust, Go जैसी ही स्थिति में है। शायद पहले से बने हुए JS-संबंधित Go प्रोजेक्ट्स और लाइब्रेरीज़ ने भी इस फैसले को प्रभावित किया होगा।वाकई यह एक बहुत ही नया आइडिया है, लेकिन दूसरे कमेंट्स की तरह यह भी जानने की जिज्ञासा है कि ट्रैफिक का दबाव बढ़ने पर इसे कैसे संभाला जाएगा।
मेरा ख्याल है कि आप Node जैसे runtime की बात कर रहे हैं, लेकिन यहाँ बात TS भाषा के compiler की हो रही है।