في الأسبوع الماضي فقط ، تم عقد أكبر
مؤتمر مطوري Microsoft
Build2019 . بعد أن ذهبت إلى هناك ، تابعت هدفين.
- الهدف الأول هو فهم إلى أين تتجه شركة Microsoft فيما يتعلق بالتطوير والتقنيات والمناهج التي تروج لها.
- الهدف الثاني هو فهم حالة المجتمع حول Microsoft. Build - مؤتمر عام - يعطي فكرة أفضل عن مؤتمرات Microsoft الداخلية لموظفيها. في حدث عام ، يمكنك استخلاص النتائج حتى على عدد الأشخاص الذين حضروا الجلسة.
بالنسبة لي ، لقد حددت العديد من الموضوعات الرئيسية التي أود أن أشارك أفكاري فيها:
- الإطار الصافي لخارطة الطريق
- Kubernetes
- ServerLess
- الحوسبة الحافة
- البيانات الكبيرة ، التعلم الآلي ، الذكاء الاصطناعي
- منصة عرض ويندوز
الإطار الصافي لخارطة الطريق
في Build2019 ، كان هناك تقرير صادر عن
.NET Platform Overview و Roadmap . أوصي بشدة بمشاهدة وقراءة
Introducing .NET 5 و
C # 8 وتقرير منفصل عن C # 8 -
مستقبل C #
- ملاحظاتي منذ الإعلان عن .net core 3.0 هي التالية: إنشاء معايير .net core / .net كان صحيحًا جدًا ، ولكن في .net ، كما هو الحال في منصات أخرى ، تم تجميع الكثير من التعليمات البرمجية التي لا يمكن اتخاذها ونقلها على هذا النحو. وبالتالي ، تحتاج إلى إحضار .net الكعك الأساسية / القياسية إلى المشاريع القديمة مع الحد الأدنى من التعديل. تم نقل WinForms / WPF إلى مصدر مفتوح ، وسيكون الإصدار التالي بالفعل مع .net standard تحت غطاء محرك السيارة ، ويمكنك أن تنسى الهيكل القديم لملفات csproj والحصول على مكافآت أكثر. من المؤكد أن الأمور صحيحة ، ولكنها ناتجة أيضًا عن حقيقة أنه يجب أيضًا دعم الإرث.
- من الجيد أنه لم يعد يتم تذكر UWP في أنظمة الأجهزة المحمولة ، ويبقى Xamarin فقط لمطوري C #.
- في موقف فريق .Net Core ، طرحت السؤال: "وما هي التغييرات الكبيرة التي تنوي إجراؤها. صافي 6-7-8؟ وهل سيكون لديك سبب لزيادة الإصدار الرئيسي للمنتج كل عام؟ " والأهم من ذلك كله أنني أحببت جزء الإجابة الذي قمت بترجمته ، وفهمت مدى "هذه الرؤية جيدة ، وكيف ستكون بعد ذلك ، سنرى. "
- كانت لدي أفكار مماثلة حول C # 8 ، وكذلك حول جميع الإصدارات بعد المزامنة / الانتظار ، والتي غيرت بالفعل نمط البرمجة في C #. وكل شيء آخر ، بالطبع ، كان ممتعًا وأضاف السكر النحوي ، لكن الخلفية Async / Await بدت باهتة إلى حد ما. لكن الرمز أصبح أقل وأقل تشابهًا لـ C # الكلاسيكية. ماذا تقول في هذا الرمز ، حتى في عام 2012
ولكن ما لم يعجبني في هذه الجلسة هو المحاولات المستمرة للتأكيد مرة أخرى لجميع مطوري .net / C # على الحاجة إلى معرفة وفهم
واستخدام التعليم الآلي والخدمات المعرفية وما إلى ذلك يوميًا.
بالطبع ، يجب على المطور الذكي فهم مثل هذه الأشياء والدراسة والممارسة ، إن أمكن. لكن في 99٪ من الحالات ، هذا غير مطلوب في المشروع ، ومثل هذه التبشير المستمر ، بصراحة ، يبدأ في الإزعاج.
بصراحة ، أنا لا أؤمن حقًا بمستقبل مشاريع مثل Spark.Net ، والتي تمت مناقشتها في هذه الجلسة. تذكرنا التجربة أن المحاولات المماثلة لكتابة Wrappers في C # أو نقل مشروع بيانات بالكامل إلى C # على مدار السنوات العشر الماضية عادة ما تنتهي بدون شيء ، لأن المجتمع أصغر ولغته ليست صعبة التغيير.
بعد Build2019 ، كان هناك
إعلان بأن .Net Framework 4.8 هو أحدث إصدار رئيسي من .Net Framework وسيكون هناك تغييرات بسيطة فقط. الكل في الكل ، لقد حان الوقت ل. صافي كور.
خدمة النسيج مقابل Kubernetes
3 سنوات في Microsoft ، ولمدة نصف عام تقريبًا في EPAM ، لا يمكنني تقديم تفسير تقني عادي عن سبب حاجتك إلى خدمة النسيج (وأنت ، في الوقت نفسه ، لا تعمل في Microsoft) ، إذا كان هناك Kubernetes.
- لفترة طويلة ، قال "المترجمون الفوريون" إن هذه منصات متساوية ، لكن هذا ليس كذلك (google elementary).
- ثم كان هناك حديث عن أن SF أكثر نضجًا لتطوير Windows ، و Kubernetes for Linux.
- حسنًا ، في الوقت نفسه ، يقولون ، في SF ، سيكون بإمكان مطوريك استخدام مهاراتهم في بيئة Windows ، وفي K8s تحتاج إلى تعلم Linux وإعادة التعلم. أوافق على أن الكود القديم والحاجة إلى إعادة التعرُّف من جديد هي حجة جدية ، ولكن من ناحية أخرى ، كان SF معقدًا جدًا ، وفي رأيي ، لم يكن الأمر أسهل من K8s. حسنًا ، من ناحية ، يحتاج نظام Linux إلى الدراسة ومعرفة أي حال. حتى إلى "مزرعة الرياح" المتحجرة (التي أنا أيضًا). من ناحية أخرى ، يستخلص Kubernetes الكثير من هذا.
في Build2019 ، وضعت حدا لنفسي ل SF ، ل كان هناك
تقرير واحد عن ذلك
(على الرغم من أن العنوان كان عن Mission Critical ***) .
وفقا ل Kubernetes القطع 20-30 في جميع الأقسام. سأقدم فقط الجزء الذي أوصيت برؤيته في مشروعي.
DevOpsفي رأيي ، استسلمت Microsoft ووافقت على الواقع - مجتمع .net ، في الواقع ، لم يقبل خدمة النسيج.
لكن Kubernetes أصبح في الواقع المعيار حتى بالنسبة لعالم .net ، الذي أهنئكم به وأنا.ServerLess للجميع
ومع ذلك ، يقال الكثير عن الحوسبة ServerLess. ولكن ، في وقت سابق فقط تم تغليف Azure Functions وتطبيقات Logic في هذه الصلصة ، والآن حتى Azure SQL Database ServerLess تم ربطها (عندما رأيت الإعلان ، فوجئت جدًا لأن هناك شيئًا خاطئًا ، و SQL Server Server يبدو ممتعًا).
من ناحية أخرى ، يمكن تشغيل Serverless ليس فقط في Azure ، ولكن أيضًا محليًا في الحاوية. وبالتالي ، فإن Serverless يصبح أكثر قابلية للفهم وأقل سحرية (عادةً لا يحب المهندسون السحر ، لأنهم لا يفهمون كيف يعمل ... وإذا لم ينجح ذلك ، فكيف يصلح السحر).
جوهر
SQL Serverless هو أنه يمكنك تحديد الحدود الدنيا والعليا على الموارد المستهلكة وسوف تدفع في الحد الأدنى ، بالإضافة إلى ما تستهلكه بين الحدود الدنيا والعليا. ميزة بسيطة يمكنك إيقاف SQL مؤقتًا (وليس دفع تكاليف الموارد) إذا لم تكن قاعدة البيانات قيد الاستخدام (يمكنك التوقف لمدة 6 ساعات الآن) ، فلن أضعها في الاعتبار ، لأنه بحيث لن يكون هناك طلب واحد لقاعدة البيانات لبضع ساعات على الإطلاق - وهذا موقف غريب للغاية ، لأن هناك على الأقل مراقبة ، وسوف تبدأ القاعدة (كما وعدت) في 30-60 ثانية ، وهو أمر مهم أيضًا.
حافة الاشتراك أو الحوسبة السحابية في أكثر من مركز بيانات Microsoft
- ذات مرة ، في الفترة 2008-2010 ، قالت Microsoft بشيء من هذا القبيل: "هنا لديك خدمة السحابة السحرية لدينا ، أعد كتابة تطبيقاتك الخاصة بهم (Web / Worker Role) وستحصل على السعادة". لم تنجح السعادة تركة مدلل كل شيء.
بعد ذلك ظهرت الأجهزة الافتراضية ، لكن الأمر لا يهم الآن.- بعد ذلك ، عندما أصبح من الواضح أنه حتى الآن يمكن لعدد قليل من الناس الانتقال بالكامل إلى Cloud ، لا تزال بحاجة إلى تقديم حلول Hybrid. في البداية ، كان هذا يعني VPN إلى Azure. ثم جاء Azure Stack (مجمع برامج الأجهزة يشبه Azure في API ويمكنه تحميل حمل الإنتاج عليه إذا كان المنظم لا يسمح بالنشر على السحابة العامة ، واحتفظ بـ dev / test ببيانات مجهولة المصدر على Public Cloud)
- ثم أصبحت جميع أنواع حلول إنترنت الأشياء عصرية وشائعة (بالنسبة إلى Microsoft ولاعبين كبار آخرين ... تمت كتابة القياس عن بُعد لفترة طويلة). في البداية ، في سيناريو Connected Factory (خط المصنع / التجميع) ، اقترحوا استخدام حلول من Azure Cloud ، لكن الصناعة أوضحت أن زمن الانتقال بين المصنع قد يكون أعلى بكثير من المسموح به وإيقاف خط التجميع بسبب الإنترنت "الوامض" غير قابل للتطبيق القرار.
- نتيجةً لذلك ، ظهرت Azure IoT Edge لأول مرة ، والتي على الرغم من أنه تم تنزيلها من Azure ، إلا أنها عملت ومعالجتها على أجهزتك (كنت بحاجة إلى مضيف متوافق مع Docker ، مرتبط أحيانًا بالإنترنت على الأقل) ، ولكن في البداية كان لديه مجموعة متواضعة جدًا من الميزات. كان هناك حديث جيد حول هذا الموضوع كان Azure IoT Edge & AI: تمكين الحافة الذكية
- بعد ذلك ، عندما أثبتت IoT Edge أنها مفيدة (للمستهلكين ولتمويل Microsoft) ، بدأت الخدمات التي كانت تُعتبر سابقًا Cloud فقط تظهر كالفطر. على سبيل المثال ، جاءت الخدمات المعرفية إلى Edge. يعد التحكم في الجودة المرئية للمنتجات على خط التجميع أو الناقل أسهل من القيام به من حاوية عامل الرصيف المحلية بدلاً من تجميع زمن الوصول إلى Azure Data Center.
- ولكن في Build2019 ، أصبحت العديد من هذه الخدمات متاحة للجمهور أو ظهرت كمعاينة (أحب خدمات الكلام لتوليف الكلام قبل كل شيء من المعاينة. كانت تفتقر للغاية على الأجهزة دون الوصول المستمر إلى الإنترنت).
- في الوقت نفسه ، تم عرضه ، تم الإعلان عنه بواسطة SQL Server ، إنه Edge ( Simplify Edge Architecture مع Azure SQL Database Edge ).
لا ، تم تشغيل SQL 2017 لوقت طويل على نظام Linux في Docker ، لكنه يتطلب 3.5 جيجابايت من الذاكرة. تم تحسين هذا الإصدار أيضًا مع الذاكرة (500 ميجابايت <ويعمل على معالجات ARM) ، لأجهزة Edge (عادة ما تكون هناك ذاكرة صغيرة عليها). وفي الوقت نفسه ، هناك عمل لبث وتحليلات السلاسل الزمنية المضمّنة ، والذي يبدو مثيراً للاهتمام. - بالإضافة إلى ذلك ، تم إطلاق حلول Azure Sphere المستندة إلى حلول IoT المؤمنة.
- أظهروا معدات حساب Azure Edge ، والتي لا تترك أي شك في أن الموضوع يتم مراقبته عن كثب.
صحيح مربع ، أحببت ترحيل البيانات إلى أزور أكثر بسبب تبدو أكثر صلابة.
البيانات الكبيرة ، التعلم الآلي ، الذكاء الاصطناعي
في هذه المجالات ، سأكتب من منظور مطور سابق (على الرغم من عدم وجود مطورين سابقين) ، وليس خبيرًا في البيانات.
في كثير من الأحيان التقيت بالموقف "المثير للاهتمام" لبعض العملاء وهو أن IaaS يجب أن تتم في أوس ، بايس في أزور والبيانات في برنامج شركاء Google المعتمدون. لا يسع المرء إلا أن يوافق على أنه من الناحية التاريخية ، كان كل من مقدمي الخدمات متخصصين في شيء ما ، ولكن الآن ، إذا نظرت إليه بكميات كبيرة ، فقد تحقق التكافؤ في العديد من الخدمات (يبقى الفرق في الفروق الدقيقة ، بالطبع). يعد تكامل الحلول بين مزودي خدمة Cloud المختلفين ، بطبيعة الحال ، وظيفة مثيرة للاهتمام ومنجمًا للذهب ، ولكن كقاعدة عامة ، فإنه غير فعال للغاية بالنسبة للعميل نفسه (يجب عليك دائمًا الدفع مقابل حركة المرور الصادرة ، ولكن هناك أيضًا كمون وتعقيد / تعقيد للحل).
ربما يكون الاتجاه الأكثر واعدة لـ Microsoft / Azure في المستقبل القريب من وجهة نظر الأموال الجديدة هو العمل مع البيانات - "مرحبًا" Spark / Hadoop / Kafka ، بحيرات البيانات والعديد من الخدمات الأكثر إثارة ، ولكن في الوقت نفسه مع الموضوعات الساخنة (لا يحب شخص ما على الضجيج لجعل المبيعات) مثل الذكاء الاصطناعي (أنها تظهر لنا مرة أخرى كورتانا ، مرة أخرى أنها تظهر لنا السيارات الذكية). كان عدد الإعلانات ، والأهم من ذلك (في بعض الأحيان اصطناعيًا ، وأحيانًا تظهر عميل سعيد) على استخدام خدمات البيانات الكبيرة في أزور في المؤتمر بعيدًا عن النطاق. وفقًا لمنظمة العفو الدولية وحدها ، هناك 37 جلسة (هناك 171 جلسة لكامل Build2019 ، إذا طرحنا 15 دقيقة من تقارير الممرات وجلسات برمجة للطلاب.). كانت هناك تقارير DevOps لـ Big Data و Windows AI platform و AI لـ PowerBI. معظم هذه التقنيات مفتوحة المصدر ، كلها مدفوعة من قبل المجتمع وموجودة في جميع مقدمي الخدمات الثلاثة الكبار. قبل عامين ، أعترف أنني لا أتذكر هذا النهج النشط لخدمات البيانات.
إحدى الجلسات التي أود ذكرها هي جلسة Windows Presentation Platform (WPP). لكي أكون أمينًا ، اعتقدت عن غير قصد أن هذا يتعلق بـ Windows Presentation Foundation (WPF) ، لكنني فوجئت بسرور أن الموضوع أوسع من المتوقع.
مرة واحدة في عام 2009 ، عندما تم إطلاق WPF للتو ، كان الموضوع شائعًا: استضافة عناصر تحكم WinForms في تطبيقات WPF ، أو العكس - محاولة إدراج عناصر تحكم WPF في WinForms. كان كل شيء مما كان من المستحيل في كثير من الأحيان أن يأخذ والوجه قطعة ضخمة من التطبيق على الإطار الجديد. في الإصدارات الأولى ، لم يتم الإعلان عن هذه الميزات ، ولكن عندما أصبح من الواضح أنه يجب سحب التوافق مع الإصدارات السابقة ، فقد بدأت في الترويج بنشاط.
لذلك ، في عام 2019 ، نناقش كيفية استضافة
عناصر تحكم U
WP في WPF (جزر XAML) ، وكيفية
فصل مكونات UI ونظام التشغيل في WinUI 3.0 (أي توفير عناصر التحكم / برنامج التحويل البرمجي / وقت التشغيل كحزم nuget وعدم انتظار Windows Update .)
الفكرة رائعة ، ولكن كان من الضروري القيام بذلك في الإصدار الأول من UWP ، لأنه بحلول ذلك الوقت قام فريق Entity Framework بإزالة EF من .net Framework قبل عدة سنوات للتوقف عن الاعتماد على تحديثات Windows. وما أصبح .Net Core كان في التنمية.
والأهم من ذلك ، أنه سيكون متاحًا ليس فقط لأحدث إصدارات Windows 10 ، ولكن أيضًا قديم جدًا ، لكنه لا يزال صالحًا. تم تخصيص قاعة كبيرة للجلسة ، ولكن كان هناك مساحة كافية في القاعة (تم تطوير نظام Windows لمدة 10 سنوات تقريبًا) ، ولكن هذا ليس هو الموضوع. كان هناك عدد قليل جدًا من الشباب في القاعة (أقارنها بجلسة على Asp.Net Core أو ، بشكل خاص ، التعلم الآلي). هذه مجرد ملاحظاتي الشخصية ؛ لا أتعامل مع تطوير جنازة Windows.
مايكروسوفت النظام البيئي للمطورين
باعتباري مهندسًا ميدانيًا في Microsoft ، فقد دعمت رسميًا فقط ما قامت به Microsoft نفسها. من هذا النهج ، معرفة كل شيء ضمور آخر. الآن وقد تركت مايكروسوفت وأصبحت مهندس حلول ، أصبح من الضروري ملء هذه الفجوة. وفي Build ، كان هناك معرض كامل للحلول لشركاء التطوير والمطورين ، حيث يمكنك الذهاب إلى أي موقف وطرح الأسئلة ، وطرح عرض توضيحي. لقد أنقذت أسابيع بزيارة هذه المواقف.
- لا يزال بإمكانك استخدام SonarQube لإدارة الديون الفنية (جودة الكود ، وليس البنية بالطبع)
- هناك حلول DevOps متخصصة على Kubertenes أسهل في الاستخدام من Azure DevOps
- هناك حلول مثيرة للاهتمام مثل Aqua (aquasec) / Snyk لمراجعة محتويات صور عامل الميناء والحاويات التي تعمل بالفعل.
- هناك حلول مثيرة للاهتمام لرصد وتتبع التطبيقات الموزعة التي لها مزايا على شاشة banal ELK أو Azure Monitor (إحصاءات التطبيق + تحليلات السجل) مثل Signalfx
- أنا صامت بالفعل بشأن R # وبيئة التطوير على .net من Jetbrains (تذكرت عن R # لكنني لم أستخدمه ، لأنني كتبت قليلاً وبالتالي لم أسمع الكثير عن بيئة التطوير).
- كانت مليئة بجميع أنواع الحلول القائمة على AI / ML / Data ، إلخ ، لكنني لم أذهب إليهم كثيرًا ، لأن ليس لدي أي خبرة عملية في حلول البيانات الضخمة الصناعية ولن أكون قادرًا على تقييم الفوائد.
إعلانات
بصراحة ، لم تؤذني إعلانات هذا العام شخصيًا (
هنا وهنا ) ، ولم أتذكرها بشكل خاص. على أجهزة الكمبيوتر الكمومية ، من الجيد الضجيج ، لكن من غير المنطقي أن هذه هي تقنية اليوم. ولا شيء آخر كان حقا تذكرت.
خاتمة
في الحقيقة ، كنت أتوقع المزيد من ممثلي الصناعات غير الصناعية ، كما تقول Microsoft منذ فترة طويلة إنها تسعى إلى مساعدة الشركة في تنفيذ المشاريع ، وليس في أعمالها المهنية. نعم ، بالطبع ، كانت هناك تقارير مع
إيرباص ،
بي إم دبليو ... لكنني كنت أتوقع المزيد.
Office365 ليس موضوعي ، لذلك قررت عدم التفكير في هذه المشكلة.
كل ما سبق هو رأيي الشخصي ، بناءً على ملاحظاتي وتجربتي السابقة. أنا لا أدعي أنه موضوعي. يمكنك مناقشة أي أطروحة.