👣 🤜🏻 🚑 बिल्ड2019, जो हमने देखा उसे समझना 👨🏽‍🤝‍👨🏻 🧑🏿‍🤝‍🧑🏿 🐍

अभी पिछले हफ्ते, सबसे बड़ा Microsoft Build2019 डेवलपर सम्मेलन आयोजित किया गया था । वहां जाने के बाद, मैंने 2 गोल किए।

पहला लक्ष्य यह समझना है कि Microsoft विकास के मामले में कहां जा रहा है और यह किन तकनीकों और दृष्टिकोणों को बढ़ावा दे रहा है।
दूसरा लक्ष्य Microsoft के आसपास समुदाय की स्थिति को समझना है। बिल्ड - एक सार्वजनिक सम्मेलन - अपने कर्मचारियों के लिए आंतरिक Microsoft सम्मेलनों से बेहतर विचार देता है। एक सार्वजनिक कार्यक्रम में, आप सत्र में आने वाले लोगों की संख्या पर भी निष्कर्ष निकाल सकते हैं।

अपने लिए, मैंने कई प्रमुख विषयों की पहचान की है जिन पर मैं अपने विचार साझा करना चाहता हूं:

.नेट फ्रेमवर्क रोडमैप
Kubernetes
serverless
एज कंप्यूटिंग
बिग डेटा, मशीन लर्निंग, आर्टिफिशियल इंटेलिजेंस
विंडोज प्रस्तुति मंच

.नेट फ्रेमवर्क रोडमैप

Build2019 में, .NET प्लेटफॉर्म अवलोकन और रोडमैप द्वारा एक रिपोर्ट थी। मैं .NET 5 , C # 8 और C # 8 पर एक अलग रिपोर्ट - C # के भविष्य का परिचय देते हुए देखने और पढ़ने की अत्यधिक सलाह देता हूं ।

.Net कोर 3.0 की घोषणा के बाद से मेरी टिप्पणियों में निम्नलिखित हैं: .net कोर / .net मानकों का निर्माण बहुत, लेकिन इननेट, अन्य प्लेटफार्मों की तरह, बहुत सारे कोड जमा हो गए हैं जिन्हें इस तरह से नहीं लिया जा सकता और स्थानांतरित नहीं किया जा सकता है। और, इसलिए, आपको न्यूनतम संशोधन के साथ पुराने प्रोजेक्ट्स के लिए .net कोर / मानक बन्स लाने की आवश्यकता है। WinForms / WPF को ओपन सोर्स पर ले जाया गया था , अगली रिलीज पहले से ही .net मानक हुड के नीचे होगी, और आप csproj फ़ाइलों की पुरानी संरचना के बारे में भूल सकते हैं और कई और बोनस प्राप्त कर सकते हैं। चीजें निश्चित रूप से सही हैं, लेकिन वे इस तथ्य के कारण भी हैं कि विरासत का समर्थन भी किया जाना चाहिए।
यह अच्छा है कि मोबाइल प्लेटफॉर्म के लिए UWP को अब याद नहीं किया जाता है, और C # डेवलपर्स के लिए केवल Xamarin ही रहता है।
.नेट कोर टीम के स्टैंड पर मैंने सवाल पूछा: "और 6-7-8 .Net में क्या बड़े बदलाव करने की योजना है? और क्या आपके पास हर साल उत्पाद के प्रमुख संस्करण को बढ़ाने का एक कारण होगा? " मेरे द्वारा अनुवादित उत्तर का अधिकांश भाग मुझे पसंद आया, मैं समझ गया कि "यह कैसे अच्छी तरह से दृष्टि है, और यह आगे कैसे होगा, हम देखेंगे।" "
मेरे पास C # 8 के बारे में समान विचार थे, साथ ही async / प्रतीक्षा के बाद सभी रिलीज़ के बारे में, जिसने वास्तव में C # में प्रोग्रामिंग शैली को बदल दिया। और बाकी सब, निश्चित रूप से, मज़ेदार था और सिंटैक्टिक चीनी जोड़ा गया था, लेकिन Async / Await पृष्ठभूमि बल्कि फीका लग रहा था। लेकिन कोड क्लासिक सी # की तरह कम और कम होता जा रहा है। ऐसे कोड पर आप क्या कहेंगे, इसलिए 2012 में

लेकिन इस सत्र के बारे में मुझे जो पसंद नहीं आया वह एक बार फिर सभी .net / C # डेवलपर्स पर जोर देने का लगातार प्रयास था, दैनिक आधार पर मशीन लर्निंग, संज्ञानात्मक सेवाओं आदि को जानने, समझने और उपयोग करने की आवश्यकता।

बेशक, एक बुद्धिमान डेवलपर को यदि संभव हो तो ऐसी चीजों को समझना चाहिए, अध्ययन करना चाहिए और अभ्यास करना चाहिए। लेकिन, 99% मामलों में, इस परियोजना में आवश्यक नहीं है, और इस तरह के लगातार प्रचार, स्पष्ट रूप से, परेशान करना शुरू कर देता है।

सच कहूं तो, मैं वास्तव में स्पार्क.नेट जैसी परियोजनाओं के भविष्य में विश्वास नहीं करता, जिन पर इस सत्र में चर्चा की गई थी। अनुभव हमें याद दिलाता है कि सी # में रैपर्स लिखने या पिछले 10 वर्षों में सी # को पूरी तरह से एक डेटा प्रोजेक्ट को पोर्ट करने के समान प्रयास आमतौर पर कुछ भी नहीं के साथ समाप्त हो गए, क्योंकि समुदाय छोटा है और भाषा को बदलना इतना मुश्किल नहीं है।

Build2019 के बाद, एक घोषणा की गई थी कि .Net फ्रेमवर्क 4.8 .Net फ्रेमवर्क का नवीनतम प्रमुख संस्करण है और इसमें केवल छोटे बदलाव होंगे। सब सब में, यह .Net कोर के लिए समय है।

सर्विस फैब्रिक बनाम कुबेरनेट्स

Microsoft में 3 साल, और EPAM में लगभग आधे साल के लिए, मैं एक सामान्य तकनीकी स्पष्टीकरण दे सकता हूं कि आपको सर्विस फैब्रिक की आवश्यकता क्यों है (और आप, उसी समय, Microsoft पर काम न करें), अगर कुबेरनेट्स है।

लंबे समय तक, "दुभाषियों" ने कहा कि ये समान मंच हैं, लेकिन ऐसा नहीं है (Google प्राथमिक)।
तब चर्चा थी कि विंडोज के विकास के लिए एसएफ अधिक परिपक्व है, और लिनक्स के लिए कुबेरनेट्स।
ठीक है, एक ही समय में, वे कहते हैं, एसएफ में आपके डेवलपर्स विंडोज पर्यावरण में अपने कौशल का उपयोग करने में सक्षम होंगे, और के 8 में आपको लिनक्स और फिर से सीखना होगा। मैं सहमत हूं, विरासत कोड और पुनर्नवीनीकरण की आवश्यकता एक गंभीर तर्क है, लेकिन दूसरी ओर, एसएफ काफी जटिल था, और मेरी राय में यह के 8 से आसान नहीं है। वैसे, एक ओर, लिनक्स को वैसे भी अध्ययन करने और जानने की आवश्यकता है। यहां तक कि ऑसिफाइड "विंड फार्म" (जो मैं भी हूं)। दूसरी ओर, कुबेरनेट्स ने इससे बहुत सार निकाला।

Build2019 में, मैंने एसएफ के लिए खुद को समाप्त कर दिया, क्योंकि इस पर 1 रिपोर्ट थी (हालांकि शीर्षक मिशन क्रिटिकल *** के बारे में था) ।

और कुबेरनेट्स के अनुसार सभी वर्गों में 20-30 टुकड़े। मैं केवल वही हिस्सा दूंगा जिसे मैंने अपने प्रोजेक्ट में देखने की सिफारिश की थी।

DevOps

मेरी राय में, Microsoft ने आत्मसमर्पण किया और वास्तविकता को स्वीकार किया - .net समुदाय, वास्तव में, सर्विस फैब्रिक को स्वीकार नहीं किया। लेकिन कुबेरनेट वास्तव में .net दुनिया के लिए भी मानक बन गया है, जिसके साथ मैं आपको और मुझे बधाई देता हूं।

सभी के लिए ServerLess

फिर भी, ServerLess कंप्यूटिंग के बारे में बहुत कुछ कहा जाता है। लेकिन, अगर पहले केवल Azure Functions और Logic Apps को इस चटनी में लपेटा जाता था, तो अब भी Azure SQL Database ServerLess ने हुक कर दिया है (जब मैंने घोषणा को देखा, तो मुझे बहुत आश्चर्य हुआ क्योंकि कुछ गलत था, और ServerLess SQL दिलचस्प लगता है)।

दूसरी ओर, सर्वरलेस को न केवल एज़्योर में, बल्कि स्थानीय रूप से कंटेनर में भी लॉन्च किया जा सकता है। इस प्रकार, सर्वर रहित अधिक समझदार और कम जादुई बन जाता है (इंजीनियर आमतौर पर जादू को पसंद नहीं करते हैं, क्योंकि वे यह नहीं समझते हैं कि यह कैसे काम करता है ... और यदि यह काम नहीं करता है, तो जादू को कैसे ठीक किया जाए)।

SQL ServerLess

एसक्यूएल सर्वरलेस का सार यह है कि आप उपभोग किए गए संसाधनों पर निचले और ऊपरी सीमा को निर्दिष्ट कर सकते हैं और आप निचले और ऊपरी सीमा के बीच उपभोग करने वाले निचले बाउंड प्लस पर भुगतान करेंगे। एक छोटी सी विशेषता जिसे आप SQL (और संसाधनों की गणना के लिए भुगतान नहीं कर सकते) यदि डेटाबेस उपयोग में नहीं है (आप अब 6 घंटे के लिए रोक सकते हैं), तो मैं इस पर विचार नहीं करूंगा, क्योंकि ताकि डेटाबेस में एक-दो घंटों के लिए एक भी अनुरोध न हो - यह एक बहुत ही अजीब स्थिति है, क्योंकि कम से कम निगरानी है, और आधार 30-60 सेकंड में शुरू होगा (जैसा कि वादा किया गया है), जो महत्वपूर्ण भी है।

Microsoft डेटा केंद्र से अधिक में सदस्यता बढ़त या क्लाउड कम्प्यूटिंग

एक बार, 2008-2010 में, Microsoft ने कुछ इस तरह कहा: "यहाँ आपके पास हमारी जादुई क्लाउड सेवा है, उनके लिए अपने अनुप्रयोगों (वेब / वर्कर रोल) को फिर से लिखें और आपको खुशी होगी"। खुशी काम नहीं आई, क्योंकि विरासत ने सब कुछ बिगाड़ दिया।
~~तब वर्चुअल मशीनें दिखाई दीं, लेकिन अब यह मायने नहीं रखता।~~
फिर, जब यह स्पष्ट हो गया कि अब भी कुछ लोग पूरी तरह से क्लाउड में जा सकते हैं, तब भी आपको हाइब्रिड समाधान बनाने की आवश्यकता है। शुरुआत में, इसका मतलब वीपीएन अज़ुरे से था। फिर एज़्योर स्टैक (एक हार्डवेयर-सॉफ़्टवेयर कॉम्प्लेक्स जो एपीआई में एज़्योर के समान है और अगर नियामक क्लाउड पर प्रकाशन की अनुमति नहीं देता है, और सार्वजनिक क्लाउड पर अज्ञात डेटा के साथ देव / परीक्षण रखने की अनुमति देता है) तो उस पर उत्पादन लोड पकड़ सकता है।
तब सभी प्रकार के IoT समाधान फैशनेबल और लोकप्रिय हो गए (Microsoft और अन्य बड़े खिलाड़ियों के लिए ... टेलीमेट्री लंबे समय तक लिखी गई थी)। पहले, कनेक्टेड फैक्ट्री (फैक्ट्री / असेंबली लाइन) के परिदृश्य में, उन्होंने एज़्योर क्लाउड से समाधान का उपयोग करने का सुझाव दिया, लेकिन उद्योग ने समझाया कि उनके कारखाने के बीच विलंबता अनुमेय की तुलना में बहुत अधिक हो सकती है और "ब्लिंकिंग" के कारण असेंबली लाइन को रोकना इंटरनेट व्यवहार्य नहीं है। निर्णय।
नतीजतन, पहली बार एज़्योर IoT एज दिखाई दिया, जो, हालांकि इसे एज़्योर से डाउनलोड किया गया था, लेकिन आपके हार्डवेयर पर काम किया और संसाधित डेटा (आपको एक डॉक संगत संगत होस्ट की आवश्यकता थी, जो कम से कम कभी-कभी इंटरनेट से जुड़ा हुआ है), लेकिन सबसे पहले इसमें बहुत मामूली सेट थे। इस विषय पर एक अच्छी बात थी Azure IoT Edge & AI: इंटेलिजेंट एज को सक्षम करना
तब, जब IoT एज उपयोगी साबित हुई (उपभोक्ताओं के लिए और Microsoft वित्त के लिए), पहले क्लाउड मानी जाने वाली सेवाएँ केवल मशरूम की तरह दिखाई देने लगीं। उदाहरण के लिए, कॉग्निटिव सर्विसेज एज में आए। एक असेंबली लाइन या कन्वेक्टर पर उत्पादों की दृश्य गुणवत्ता नियंत्रण स्थानीय डॉकटर कंटेनर से अज़्योर डेटा सेंटर में विलंबता को इकट्ठा करने की तुलना में बहुत आसान है।
लेकिन Build2019 में, इनमें से कई सेवाएं सार्वजनिक हो गईं या पूर्वावलोकन के रूप में दिखाई दीं (मुझे पूर्वावलोकन से भाषण संश्लेषण के लिए भाषण सेवाएं पसंद हैं। यह निरंतर इंटरनेट एक्सेस के बिना उपकरणों पर बहुत कमी थी)।
उसी समय, यह दिखाया गया था, SQL सर्वर द्वारा घोषित किया गया था , यह एज ( सरलीकृत एज आर्किटेक्चर एज़ुर SQL डेटाबेस एज के साथ )।

नहीं, SQL 2017 लंबे समय से डॉकर में लिनक्स पर चल रहा है, लेकिन इसके लिए 3.5 जीबी मेमोरी की आवश्यकता है। यह संस्करण मेमोरी के लिए भी अनुकूलित है (500 एमबी <और एआरएम प्रोसेसर पर चलता है), एज डिवाइस के लिए (आमतौर पर उन पर बहुत कम मेमोरी है)। और एक ही समय में बिल्ट-इन टाइम-सीरीज स्ट्रीमिंग और एनालिटिक्स का काम है, जो बहुत दिलचस्प लगता है।
इसके अलावा, Azure क्षेत्र- आधारित हार्डवेयर के लिए सुरक्षित IoT समाधान लॉन्च किया गया था।
उन्होंने एज़्योर एज कंप्यूट उपकरण दिखाए, जो इस बात पर कोई संदेह नहीं करता है कि इस विषय पर बारीकी से नज़र रखी जाती है।
सच बॉक्स, मुझे एज़्योर के लिए डेटा माइग्रेशन अधिक पसंद आया क्योंकि अधिक ठोस दिखता है।

बिग डेटा, मशीन लर्निंग, आर्टिफिशियल इंटेलिजेंस

इन क्षेत्रों में, मैं एक पूर्व डेवलपर (हालांकि कोई पूर्व डेवलपर्स नहीं हैं) के परिप्रेक्ष्य से लिखूंगा, और डेटा के विशेषज्ञ नहीं।

बहुत बार मैं कुछ ग्राहकों की "दिलचस्प" स्थिति से मिलता था जो IaaS Aws, PaaS in Azure और Data in GCP में किया जाना चाहिए। कोई भी इस बात से सहमत नहीं हो सकता है कि ऐतिहासिक रूप से प्रत्येक प्रदाता किसी चीज में विशेष है, लेकिन अब, यदि आप इसे बड़ी मात्रा में देखते हैं, तो कई सेवाओं में समानता हासिल की गई है (बारीकियों में अंतर, निश्चित रूप से, बनी हुई है)। विभिन्न क्लाउड प्रदाताओं के बीच समाधानों का एकीकरण, बेशक, एक दिलचस्प नौकरी और सोने की खान है, लेकिन एक नियम के रूप में, यह ग्राहक के लिए खुद के लिए बेहद अक्षम है (आपको हमेशा आउटगोइंग ट्रैफ़िक के लिए भुगतान करना होगा, लेकिन समाधान की विलंबता और जटिलता भी है)।

संभवतः नए पैसे के दृष्टिकोण से निकट भविष्य में Microsoft / Azure के लिए सबसे आशाजनक दिशा डेटा के साथ काम कर रही है - "हैलो" स्पार्क / Hadoop / Kafka, डेटा झीलों और कई और अधिक दिलचस्प सेवाएं, लेकिन एक ही समय में गर्म विषयों के साथ (किसी को पसंद नहीं है) बिक्री पर प्रचार के लिए) जैसे आर्टिफिशियल इंटेलिजेंस (वे फिर से हमें कोरटाना दिखाते हैं, फिर से वे हमें स्मार्ट कार दिखाते हैं)। सम्मेलन में एज़्योर में बिग डेटा सेवाओं के उपयोग पर घोषणाओं की संख्या, और सबसे महत्वपूर्ण मामले (कभी-कभी सिंथेटिक, और कभी-कभी एक खुश ग्राहक भी दिखाते हैं) सिर्फ ऑफ स्केल था। अकेले AI के अनुसार, 37 सत्र हैं (पूरे बिल्ड2019 के लिए उनमें से 171 हैं, अगर हम छात्रों के लिए 15 मिनट के गलियारे की रिपोर्ट और प्रोग्रामिंग सत्र को घटाते हैं।)। यहां तक कि बिग डेटा, विंडोज एआई प्लेटफॉर्म और पावरबीआई के लिए एआई के लिए भी DevOps रिपोर्टें थीं। इनमें से अधिकांश प्रौद्योगिकियां खुला स्रोत हैं, वे सभी समुदाय संचालित हैं और सभी 3 बड़े प्रदाताओं में मौजूद हैं। कुछ साल पहले, मैं मानता हूं, मुझे डेटा सेवाओं के लिए इस तरह के एक सक्रिय दृष्टिकोण को याद नहीं है।

विंडोज प्रस्तुति मंच

जिन सत्रों का मैं उल्लेख करना चाहूंगा उनमें से एक है विंडोज प्रेजेंटेशन प्लेटफॉर्म (डब्ल्यूपीपी) सत्र। ईमानदार होने के लिए, मैंने अनजाने में सोचा था कि यह विंडोज प्रेजेंटेशन फाउंडेशन (WPF) के बारे में था, लेकिन मुझे सुखद आश्चर्य हुआ कि यह विषय अपेक्षा से अधिक व्यापक था।

2009 में कुछ समय पहले, जब WPF बस दिखाई दिया था, तो यह विषय लोकप्रिय था: WPF अनुप्रयोगों में WinForms नियंत्रण की मेजबानी करना, या इसके विपरीत - WinForms में WPF नियंत्रण सम्मिलित करने का प्रयास करना। नए ढांचे पर एप्लिकेशन के विशाल टुकड़ों को लेना और फ्लिप करना अक्सर असंभव था। पहले रिलीज में, ऐसी विशेषताओं का विज्ञापन नहीं किया गया था, लेकिन जब यह स्पष्ट हो गया कि पिछड़े संगतता को खींचना है, तो वे सक्रिय रूप से बढ़ावा देने लगे।

तो, 2019 में, हम चर्चा करते हैं कि WPF (XAML द्वीप) में U WP नियंत्रणों की मेजबानी कैसे करें, और UI घटकों और WinUI 3.0 में ऑपरेटिंग सिस्टम को कैसे अपघटित करें (अर्थात आपूर्ति नियंत्रण / संकलक / रनगामी को नौसिखिए पैकेजों के रूप में और विंडोज अपडेट की प्रतीक्षा न करें) ।) विचार बहुत अच्छा है, लेकिन UWP के पहले संस्करण में इसे करना आवश्यक था, क्योंकि उस समय तक Entity Framework टीम ने विंडोज अपडेट के आधार पर EF को कई साल पहले .net फ्रेमवर्क से हटा दिया था। ~~और जो बन गया। नेट कोर विकास में था।~~

और सबसे महत्वपूर्ण बात, यह न केवल विंडोज 10 के नवीनतम संस्करणों के लिए उपलब्ध होगा, बल्कि काफी पुराना, लेकिन अभी भी प्रासंगिक है।

एक बड़ा हॉल सत्र के लिए आरक्षित था, लेकिन हॉल में पर्याप्त खाली जगह थी (विंडोज के लिए विकास लगभग 10 वर्षों के लिए दफन किया गया है), लेकिन यह बात नहीं है। हॉल में बहुत कम युवा लोग थे (मैं इसकी तुलना Asp.Net कोर या विशेष रूप से मशीन लर्निंग पर एक सत्र से करता हूं)। ये सिर्फ मेरे व्यक्तिपरक अवलोकन हैं; मैं विंडोज के लिए अंतिम संस्कार के विकास से नहीं निपटता।

डेवलपर्स के लिए Microsoft पारिस्थितिकी तंत्र

Microsoft में एक फील्ड इंजीनियर के रूप में, मैंने आधिकारिक तौर पर केवल वही समर्थित किया जो Microsoft ने स्वयं किया था। इस दृष्टिकोण से, बाकी सभी चीज़ों का ज्ञान। अब जब मैंने Microsoft को छोड़ दिया है और Solution Architect बन गया है, तो इस अंतर को भरना महत्वपूर्ण हो गया है। और बिल्ड में विकास भागीदारों और डेवलपर्स के लिए समाधानों की एक पूरी प्रदर्शनी थी, जहां आप किसी भी स्टैंड पर जा सकते हैं और सवाल पूछ सकते हैं, डेमो मांग सकते हैं। मैंने इन स्टैंडों पर जाकर हफ्तों की बचत की।

आप अभी भी तकनीकी ऋण का प्रबंधन करने के लिए सोनारक्यूब का उपयोग कर सकते हैं (कोड गुणवत्ता, निश्चित रूप से वास्तुकला नहीं)
Kubertenes पर विशेष DevOps समाधान हैं जो Azure DevOps की तुलना में उपयोग करने में बहुत आसान हैं
डॉक छवियों और पहले से ही चल रहे कंटेनरों की सामग्री के ऑडिटिंग के लिए एक्वा (एक्वासेक) / स्नेक जैसे दिलचस्प समाधान हैं।
वितरित अनुप्रयोगों की निगरानी और ट्रेसिंग के लिए दिलचस्प समाधान हैं, जो सिग्नलफैक्स की तरह ईएलके या एज़्योर मॉनिटर (एप्लीकेशन इनसाइट्स + लॉग एनालिटिक्स) पर फायदे हैं।
मैं पहले से ही R # और विकास के माहौल के बारे में चुप रहा हूँ। Jetbrains से .net (मुझे R # के बारे में याद है, लेकिन इसका उपयोग नहीं किया, क्योंकि मैंने थोड़ा लिखा था और इसलिए विशेष रूप से विकास के माहौल के बारे में नहीं सुना था)।
यह AI / ML / Data, आदि पर आधारित सभी प्रकार के समाधानों से भरा था, लेकिन मैं उनके पास ज्यादा नहीं गया, क्योंकि मुझे औद्योगिक बिग डेटा समाधान में कोई व्यावहारिक अनुभव नहीं है और मैं लाभों का आकलन नहीं कर पाऊंगा।

घोषणाओं

ईमानदार होने के लिए, व्यक्तिगत रूप से इस वर्ष की घोषणाओं ( यहां और यहां ) ने मुझे चोट नहीं पहुंचाई है, और मुझे विशेष रूप से याद नहीं है। क्वांटम कंप्यूटरों पर, प्रचार करना अच्छा है, लेकिन यह अस्वीकार्य है कि यह आज की तकनीक है। और कुछ नहीं वास्तव में याद किया गया था।

ठीक है, क्रोमियम इंजन के साथ एज (माइक्रोसॉफ्ट से एक ब्राउज़र) के प्रयोगात्मक संस्करण के बारे में नहीं है, लेकिन इसके स्रोत कोड की उपलब्धता के बारे में लिखें! ~~(इसे बिल्ड2019 से बहुत पहले जाना जाता था )~~
कुबेरनेट्स इवेंट - संचालित ऑटोस्कोलिंग (KEDA) बुरा नहीं लगता है, लेकिन किसी भी तरह वाह प्रभाव मेरे कारण नहीं होगा। हालांकि विचार अद्भुत है।

अंतभाषण

सच में, मुझे उम्मीद है कि गैर-औद्योगिक उद्योगों के प्रतिनिधि अधिक होंगे Microsoft लंबे समय से यह कह रहा है कि वह परियोजनाओं के साथ व्यवसाय की मदद करना चाहता है, न कि उसके इटानिकामी से। हां, निश्चित रूप से, एयरबस , बीएमडब्ल्यू के साथ रिपोर्टें थीं ... लेकिन मुझे अधिक उम्मीद थी।

Office365 मेरा विषय नहीं है, इसलिए मैंने इस मुद्दे पर विचार नहीं करने का निर्णय लिया।

उपरोक्त सभी मेरी व्यक्तिगत राय है, जो मेरी टिप्पणियों और मेरे पिछले अनुभव पर आधारित है। मैं वस्तुनिष्ठ होने का ढोंग नहीं करता। आप किसी भी थीसिस पर चर्चा कर सकते हैं।

बिल्ड2019, जो हमने देखा उसे समझना