थॉटवर्क्स के टेक्नोलॉजी रडार 27 से डेवलपर रुझान

थॉटवर्क्स का टेक्नोलॉजी राडार यह देखने का एक नियमित समय है कि उद्योग के अनुभवी विशेषज्ञ क्या सोचते हैं कि उपकरण, प्रथाओं और तकनीकों की अगली लहर क्या हो सकती है, जिस पर विचार किया जा सकता है या उपयोग करना बंद कर दिया जा सकता है।

मैं हमेशा अपनी सूची में कई नए "ब्लिप्स" जोड़ने के लिए तत्पर रहता हूं, या देख रहा हूं कि जब आपने आखिरी बार देखा था तब से गोद लेने में क्या बढ़ रहा है।

संस्करण 27 अब बाहर है, और यह कुछ प्रवृत्तियों को जारी रखता है जो कुछ समय के लिए राडार का अनुसरण कर रहे हैं, जैसे "प्लेटफ़ॉर्म एक सेवा के रूप में" या समूह प्रोग्रामिंग के रूप। यह राउंड-अप व्यापक से बहुत दूर है, लेकिन सिर्फ वह ब्लिप जो मुझे पसंद आया या मैंने सोचा, वह आपसे अपील कर सकता है।

यदि उनमें से कोई आपकी रुचि लेता है, या मेरे द्वारा प्रदर्शित किसी भी चीज़ पर आपकी कोई राय है, तो अपनी प्रोफ़ाइल पर जाएँ और हमारे पाठकों को बताएं !

मशीन लर्निंग की मुख्यधारा

यह वास्तव में ऐसा महसूस करता है कि पिछले 6 महीनों में, मशीन लर्निंग कुछ ऐसी चीज़ों से चली गई है जो ज्यादातर डेवलपर्स और डेटा वैज्ञानिकों ने जनता के बारे में जागरूकता के साथ बातचीत की थी।

एक और एमएल या एआई-आधारित टूल की घोषणा के बाद घोषणा की गई थी, जिसमें आपके द्वारा कुछ डालने के बाद मीडिया के कुछ प्रकार के बारे में बताया गया था, और हम हजारों अजीब-सी दिखने वाली छवियों और मशहूर हस्तियों के वीडियो से भर गए थे।

इसका मतलब यह भी है कि एमएल के साथ प्रयोग करने में रुचि रखने वाले डेवलपर्स के पास उन डेटा सेटों का उपयोग करने के लिए डेटा सेट और फ्रेमवर्क के आकार में बहुत अधिक संसाधन उपलब्ध हैं।

प्रयोग करने वाले डेवलपर्स के लिए प्रासंगिकता TinyML है, जो मशीन सीखने का एक क्षेत्र है जो विभिन्न प्रकार के उपयोग-मामलों को सक्षम करता है और बैटरी से चलने वाले उपकरणों को लक्षित करता है।

एक और फीचर स्टोर है, एमएल पाइपलाइन बनाने की एक विधि जो अन्य पृष्ठभूमि के डेवलपर्स से अधिक परिचित हो सकती है।

इस रडार ने बिल्डिंग और प्रशिक्षण मॉडल के डेवलपर अनुभव में सुधार के लिए एमएल-संबंधित टूल को भी कवर किया, उदाहरण के लिए, प्रारंभिक मॉडल परीक्षण के लिए प्रसंस्करण या सिंथेटिक डेटा के लिए मशीनों में मॉडल डेटा एकत्र करने के लिए "संघीय मशीन लर्निंग" का अभ्यास।

निरंतर अवलोकन

एक अपेक्षाकृत नया शब्द होने के बावजूद, "अवलोकनशीलता" तेजी से चल रही प्रणाली की एक बेहतर तस्वीर बनाने के लिए प्रथाओं और मानकों के ढीले संग्रह से बढ़ी है, जिसका मतलब है कि सभी प्रकार की चीजों का अर्थ व्यापक शब्द बन गया है।

अंतर्दृष्टि प्राप्त करने के लिए डेवलपर वर्कफ़्लो का नवीनतम क्षेत्र वह है जिसमें मुझे आश्चर्य है कि इसमें इतना लंबा समय लगा, निरंतर एकीकरण और वितरण पाइपलाइनों के लिए अवलोकन।

जबकि सीआई और सीडी निश्चित रूप से लाभ लाते हैं, प्रक्रियाएं अक्सर बहुत कम अंतर्दृष्टि के साथ गलत हो जाती हैं जब तक आप कोशिश नहीं करते, फिर से प्रयास करें।

अब, मुट्ठी भर मौजूदा ऑब्जर्वेबिलिटी वेंडर और ओपन-सोर्स प्रोजेक्ट निरंतर प्रक्रियाओं की ट्रेसिंग-शैली के विज़ुअलाइज़ेशन ला रहे हैं, जो उम्मीद है कि आपको काफी हद तक डिबग करने में मदद मिलेगी।

सामग्री का सॉफ्टवेयर बिल

जैसा कि डेवलपर्स अपने काम के लिए अर्ध-गुमनाम कंटेनरों और पैकेजों पर तेजी से झुकते हैं, जो सुरक्षा और कानूनीताओं पर ध्यान केंद्रित करते हैं और सोचते हैं, "क्या हम इस पर भरोसा करते हैं?"।

इस चिंता ने मानकीकृत और सामान्य (उद्यम में, विशेष रूप से) "सामग्रियों के सॉफ़्टवेयर बिल" को सामान्य करने के लिए प्रेरित किया है, जिसे अक्सर कॉमिक परिवर्णी शब्द, एसबीओएम द्वारा संदर्भित किया जाता है।

हालांकि, सिद्धांत रूप में, "कोई भी" एक ओपन-सोर्स प्रोजेक्ट में खुदाई कर सकता है और देख सकता है कि इसके घटक क्या हैं, यह आम तौर पर किया जाने से आसान है और बंद-स्रोत परियोजनाओं के साथ संभव नहीं है।

सॉफ्टवेयर में हाल की हाई-प्रोफाइल कमजोरियों से पता चला है कि कैसे छोटी निर्भरताएं इतनी बड़ी समस्याएं ला सकती हैं। जबकि एसबीओएम मदद करने के लिए एक लंबा रास्ता तय कर सकता है, मुझे आश्चर्य है कि कितनी कंपनियां अपने आंतरिक कामकाज को प्रकट करना चाहेंगी और उनके बारे में ईमानदार होंगी।

सतत कोडिंग

यह एक ऐसा विषय है जिसे मैं अपने कार्बन क्लाउड फुटप्रिंट टूल के बारे में थॉटवर्क्स के किसी व्यक्ति से बात करने के बाद खुद को कवर करने के लिए प्रेरित हुआ।

किसी समस्या पर नए ढांचे, उपकरण और क्लाउड ढांचे को अंतहीन रूप से फेंकने की प्रवृत्ति ने हम में से कई लोगों को यह भूल कर दिया है कि कोड की ये सभी पंक्तियां वास्तव में कहीं न कहीं किसी चीज पर चलती हैं।

और इससे कार्बन उत्सर्जन होता है। जल परोपकारी कारणों या वित्तीय से प्रेरित है, और एक पारिस्थितिक मंदी लागत बचत की ओर ले जाती है, यह एक ऐसा विषय है जिसके बारे में अधिक बात कर रहे हैं और सोच रहे हैं।

परियोजनाओं और उनके बुनियादी ढांचे की पर्यावरणीय लागत से निकटता से संबंधित है, और मैंने देखा है कि उत्पादन टीमों द्वारा उपयोग किया जाने वाला एक विकल्प इंफ्राकॉस्ट है जो टेराफॉर्म परिभाषाओं में आपके द्वारा किए गए परिवर्तनों के लागत प्रभाव का अनुमान लगाता है।

संहिता के रूप में उत्तरदायित्व

कोई भी SaaS कंपनी सेवा-स्तर के संकेतक (SLI) और सेवा-स्तर के उद्देश्यों (SLO) को परिभाषित करती है जिसकी उनके ग्राहक अपेक्षा कर सकते हैं।

हालाँकि, कंपनियों ने इन्हें कैसे परिभाषित किया है जो अक्सर थोड़ा अव्यवस्थित और गैर-मानक रहा है, और संहिताबद्ध पाइपलाइनों में बहुत कुछ परिभाषित होने के साथ, यह मूलभूत घटक भी क्यों नहीं?

कई ऑब्जर्वेबिलिटी प्रदाता अब इस विकल्प की पेशकश करते हैं और निश्चित रूप से, लोगों के एक समूह ने एक मानक OpenSLO शुरू किया है।

ए नो टू नोड

मैं जावास्क्रिप्ट और टाइपस्क्रिप्ट में दखल देता हूं और हाल ही में नोड के कुछ उभरते हुए रनटाइम विकल्पों पर ध्यान दिया है। मुझे यकीन नहीं है कि नोड के साथ क्या गलत है, अब काफी पुराने होने के अलावा, वारंट विकल्प के लिए, लेकिन मुझे लगता है कि प्रतिस्पर्धा अच्छी है 🤷‍♂️?

बन एक नया विकल्प है जिसे मैंने कुछ महीने पहले आज़माया था, और मैं मानता हूँ कि मैं वास्तव में निश्चित नहीं था कि इससे मुझे क्या लाभ हुआ, लेकिन यह क्रोम के V8 इंजन के बजाय WebKit के JavaScriptCore का उपयोग करता है।

फिर, विविधता कोई बुरी बात नहीं है। बन ज़िग में लिखा गया है, जिसके बारे में मैंने पहले कभी नहीं सुना था, और यह "ड्रॉप-इन" C/C++ प्रतिस्थापन होने का दावा करता है।

जो अच्छी तरह से जाता है ...

सी +++

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

भाषा अभी भी प्रायोगिक चरणों में है, लेकिन समझने में आसान होने और साथ चलने का दावा करती है। Google की कई प्रायोगिक परियोजनाओं को स्पिन करने और फिर उन्हें फिर से डंप करने की प्रवृत्ति है, इसलिए थॉटवर्क्स का सुझाव वर्तमान में "प्रतीक्षा करें और देखें" है।