मुझे लगता है कि startup में microservice के भी कई फायदे होते हैं। सबसे पहले, monorepo इस्तेमाल करने के फायदे मैं सच में recommend करूँगा।

  • जब product की दिशा बदलती है, तो microservice में monolithic की तुलना में बदलने वाले हिस्से ज़्यादा स्पष्ट होते हैं और कम भी। मुझे लगता है यह सच में बहुत बड़ा फ़ायदा है।
  • AI development के युग में, microservice की छोटी units को AI के ज़रिए develop करना आसान होता है। (यह नहीं कह रहा कि monolithic में नहीं हो सकता)
  • CI/CD का burden मैं मानता हूँ, लेकिन direction तय करने के चरण में ऐसे services भी होती हैं जिन्हें समेट दिया जाता है। आख़िर में जब दिशा तय हो जाए, तब भी इसे बनाना लगभग copy-paste के स्तर का होता है, इसलिए एक हफ़्ते के भीतर setup किया जा सकता है।
  • अलग-अलग languages के हिसाब से मज़बूत open source स्पष्ट रूप से मौजूद हैं। जैसे Security और business logic Java में, और AI Python में — इस तरह microservice architecture में जितना संभव हो उतना ज़्यादा open source इस्तेमाल किया जा सकता है.
 

क्या हम 1 और 0 से बनी इस दुनिया के बाहर अब एक दिन भी जी नहीं सकते.... लगता है यह सिर्फ़ किसी और की बात नहीं है...

 

स्कोप को सीमित करना ही scoping कहलाता है। इस तरह scoping करना कि आप जीत सकें, वही असली क्षमता है।

 

डिजिटल detox के बारे में तो सुना था, लेकिन डिजिटल botox पहली बार सुन रहा हूँ hahaha
मुझे खास तौर पर यह जानने की जिज्ञासा थी कि Starlink किस तरह काम करता है, और इसने मेरी बहुत-सी जिज्ञासाएँ दूर कर दीं।

 

इस लेख में जिस रेडियो-सुरक्षित बैंड का उल्लेख है वह 1400-1427 MHz है, और इसमें सिर्फ इस लेख में बताई गई मिट्टी या समुद्री अवलोकन ही नहीं, बल्कि radio astronomy में देखी जाने वाली आकाशगंगा के hydrogen gas से निकलने वाली रेडियो तरंगें (1420.405 MHz) भी शामिल हैं।
इसलिए कहा जाता है कि सैन्य संघर्षों में होने वाली शक्तिशाली electronic jamming, radio astronomy को बहुत कठिन बना देती है.

जानकारी के लिए, इस लेख में उल्लेखित satellite data के आधार पर हर महीने इस बैंड में पकड़ी गई radio interference को मानचित्र पर दिखाने वाला एक वेबपेज है।

इसे देखने पर सबसे असामान्य चीज़ जापानी द्वीपसमूह है। दूसरे क्षेत्रों में, अगर कहीं सैन्य तनाव न हो, तो ज्यादातर बिखरे हुए बिंदुओं के रूप में निशान दिखते हैं, लेकिन जापानी द्वीपसमूह लगभग पूरा का पूरा गहरे लाल रंग में दिखता है। यहाँ तक कि ऊपर दिए गए वेबपेज पर दिखाया गया सबसे पुराना डेटा अप्रैल 2015 का है, और उसी समय से पूरा देश पहले ही लाल रंग में रंगा हुआ था।

इसलिए मैंने खोजा कि सिर्फ जापान में ऐसा क्यों है, तो कारण जापान में व्यापक रूप से इस्तेमाल होने वाले digital satellite broadcasting receivers बताए गए हैं।
जापान ने जुलाई 2011 में analog TV broadcasting बंद कर दी थी और उसी साल दिसंबर में BS digital satellite broadcasting channels की संख्या 24 कर दी थी। इन satellite broadcasting signals की frequency 12 GHz जैसी ऊँची होती है, और डिवाइस के लिए इसे सीधे process करना कठिन होता है, इसलिए इसे अंदरूनी तौर पर IF (intermediate frequency) में बदलकर process किया जाता है।
समस्या यह है कि channel 21 के मामले में intermediate conversion frequency 1415-1450 MHz होती है, जो ऊपर बताए गए रेडियो-सुरक्षित बैंड से ओवरलैप करती है, और लगता है कि उस समय जापान के संबंधित मानक आज की तुलना में अधिक ढीले थे।
नतीजतन, इस बैंड में थोड़ा-थोड़ा रेडियो रिसाव करने वाले receivers और distribution amplifiers की लाखों इकाइयाँ पूरे जापान में फैल गईं, और इसी वजह से समस्या पैदा हुई। हर एक डिवाइस से निकलने वाला interference signal मानक सीमा के भीतर था, लेकिन जब ये लाखों की संख्या में एक साथ काम करने लगे, तो पूरा बैंड ही प्रभावित होने लगा।
2018 के बाद से जापान के Ministry of Internal Affairs and Communications ने satellite broadcasting receivers के निर्माण और स्थापना मानकों को कड़ा किया है और पुराने receivers को बदलने के लिए subsidy भी दी है, लेकिन यह समस्या अब तक पूरी तरह हल नहीं हुई है।

जापान से संबंधित सामग्री का स्रोत:

 

वाह... Starlink के बारे में सिर्फ़ सुना था, लेकिन इसे इस्तेमाल करने का असली अनुभव पढ़कर काफ़ी हैरानी हुई। बहुत मज़ेदार था, अच्छी तरह पढ़ा!

 

OpenSearch 2021 में Elasticsearch के license बदलने के बाद सामने आया, जिसका लक्ष्य एक compatible replacement बनना था। हालांकि यह काफी हद तक compatible है, खासकर version 1.x का Elasticsearch 7.10 के साथ, लेकिन यह पूरी तरह drop-in solution नहीं है। Elasticsearch आगे और विकसित हुआ है और इसमें ज़्यादा features व optimizations हैं, खासकर Kibana और aggregations में। Performance application पर निर्भर करती है, क्योंकि दोनों Lucene पर बने हैं। कुछ users को OpenSearch धीमा लगता है और इसके Kibana forks buggy लगते हैं। सितंबर 2024 में Elasticsearch के फिर से open source (AGPLv3) होने के बावजूद, कुछ लोग इसकी truly open-source nature और AWS support की वजह से OpenSearch को पसंद करते हैं। हालांकि vector search एक अहम differentiator है, बड़े पैमाने के implementations के लिए RAM management पर सावधानी से ध्यान देना पड़ता है। अंततः, चुनाव specific needs पर निर्भर करता है, और दोनों की अपनी strengths और weaknesses हैं। मैं Davidayo https://www.davidayo.com के साथ opensearch पर काम कर रहा हूँ, AI powerful tool "AskPromptAI" https://askpromptai.com.

 

टिप्पणियों में भी यह थोड़ा आया था, लेकिन beam/otp परिवार काफ़ी लचीला और अच्छा लगता है। Gleam के मामले में, go और rust दोनों की अच्छी syntax के साथ beam की स्थिरता जुड़कर यह काफ़ी प्रभावशाली भाषा बन गई है। इसे छोटे प्रोजेक्ट्स में धीरे-धीरे आज़माना चाहूँगा।

 

टीमों को बेवजह बहुत ज़्यादा बाँट दें, तो सिर्फ़ साथ बैठकर राय साझा करना भी बहुत बड़ा काम बन जाता है।

 

मुझे लगता है कि एक ही प्रजाति के बीच ऐसी बातचीत, अगर वे झुंड में नहीं रहते, तो शायद सिर्फ़ mating के लिए ही इस्तेमाल होती होगी, लेकिन यह वाकई दिलचस्प है।

 

जो कंपनी इंजन भी ढंग से नहीं बना पाती, वो ऐसी बेकार हरकतें भी सब कर रही है lol

 

एनिमेशन तो सब अच्छे हैं, लेकिन ऐसे पेज बहुत ज़्यादा हैं जहाँ कंटेंट से ज़्यादा ध्यान एनिमेशन पर चला जाता है.

खासकर जब एनिमेशन की वजह से पढ़ने का प्रवाह ही बाधित होने लगे, तो पढ़ना शुरू करने से पहले ही चिढ़ होने लगती है.

 

वाकई बहुत प्रभावशाली था!
काम में तुरंत लागू किए जा सकने वाले कई टिप्स भी हैं। साझा करने के लिए धन्यवाद ☺️

 

ऐसा लगता है कि ऐसी चीज़ चुन पाना भी एक अहम कौशल है, जिनके लिए आप जीत की घोषणा कर सकें।

 

हमारी कंपनी में हम Cursor जैसे इन दिनों आए AI editors को अपनाने के बजाय, बस VS Code में Continue extension इंस्टॉल करके इस्तेमाल करने जितना ही LLM का उपयोग कर रहे हैं। शायद 2~3 साल बाद जब कोई dominant code editor सामने आ जाएगा, तब उसे अपनाने के बारे में सोचेंगे...