أفضل 2018 في المحادثات التقنية

على مدار العامين الماضيين ، كنت أنشر قائمة بمحادثاتي التقنية المفضلة عن العام السابق (فيما يلي نسخة عام 2016 من هذا المنشور وإصدار 2017).

هذه القائمة ليست شاملة بأي حال من الأحوال ، وأنا متأكد من أن هناك العديد من المحادثات التقنية منذ عام 2018 والتي لن نكتشفها إلا بعد ذلك بكثير. ولكن من بين المحادثات التي حضرتها أو شاهدتها ، كانت هذه بعض من أفضل (في أي ترتيب معين).

  1. مستقبل المعالجات الدقيقة ، صوفي ويلسون

يبدو أن صوفي ويلسون ، الشركة الرائدة في رقاقة ARM الأصلية ، لديها اعتقاد بأن قانون مور يقترب من نهايته (إلى جانب بعض الشركات الأخرى المدرجة لاحقًا في هذا المنشور). كان هذا حديثًا هائلاً من JuliaCon يتناول تاريخ وتطور ومستقبل المعالجات الدقيقة.

فيديو

2. The Hurricane’s Butterfly: تصحيح أخطاء الأداء الباثولوجي ، براين كانتريل

كان من بين المحادثات التي أدخلت على قائمة العام الماضي Zebras على طول الطريق وتصحيح الأخطاء تحت النار: حافظ على رأسك عندما فقدت الأنظمة عقلها. كان هذا حديثًا في سياق مشابه وتم إلقاؤه بمهارة Cantrillian المثالية والحيوية والنشطة التي توقعناها. تم تصميم البرنامج كمكدس من التجريدات ، مع وجود مشكلات بسيطة في طبقة واحدة (الفراشات) لديها القدرة على التحول إلى مشكلات أداء مرضية منهجية في طبقة أخرى (الإعصار). بالنظر إلى هذا الإعصار ، كيف يجد المرء الفراشات؟

شرائح الفيديو

3. أغلق الحلقات وعقول الافتتاح: كيفية السيطرة على الأنظمة ، الكبيرة والصغيرة ، كولم ماك كارثاي

من المسلم به أنني لم أشاهد كل المحادثات من AWS re: اخترع ، ولكن تلك التي شاهدتها ، ربما كان هذا كلامي المفضل. يضع بعض مبادئ التصميم لبناء أنظمة مستقرة وموثوقة للغاية (مثل طائرات التحكم).

  1. اختباري كل الأشياء
  2. مصادقة التشفير
  3. الخلايا والأصداف و "خبراء السموم"
  4. اقتران غير متزامن
  5. مغلق ملاحظات الحلقات
  6. دفعات صغيرة وسحب كبيرة (للتكوين)
  7. تجنب البدايات الباردة والمخابئ الباردة
  8. الإختناقات
  9. دلتا
  10. طريقة والعمل المستمر

كان من الرائع معرفة كيف أن بعض التصميمات المضادة للرسومات والتصميمات غير السهلة قد تساعد في الواقع على تحسين استقرار النظم. ربما كان الجزء الأكثر إثارة للاهتمام من النقاش هو فكرة أن أنظمة التحكم المستقرة تتطلب "حلقة PID" - مكونات متناسبة ومتكاملة ومشتقة ، وأن القدرة على إلقاء نظرة على تصميم النظام وموقعه إذا كان يفتقد أيًا من هذه قوة خارقة. هذه هي المرة الأولى التي أسمع فيها "حلقة PID" هذه ؛ يوصي النقاش الكتاب "تصميم أنظمة التحكم الموزعة" لمعرفة المزيد حول كيفية تطبيق مبادئ نظرية التحكم على هندسة النظم الموزعة.

كان من المثير للاهتمام أيضًا معرفة التسلسل الهرمي أو الأولويات في AWS: الأمان والمتانة والتوافر والسرعة.

شرائح الفيديو

4. العصر الذهبي لهندسة الكمبيوتر ، ديفيد باترسون وجون هينيسي

كان هذا حديثًا رائعًا عن تاريخ وتطور المعالجات الدقيقة ، والانتقال من آلات CISC إلى آلات RISC إلى نهاية قانون مور وتوسيع نطاق Dennard والذي يقدم بدوره فرصًا غير مسبوقة للتقدم في مجال "بنية المجال المحددة". تشمل "بنية المجال المحددة" كلاً من التقدم في الأجهزة (معالجات الشبكات العصبية لتعلم الآلة مثل TPU ، ووحدات معالجة الرسومات في NVIDIA إلى FGPAs) إلى جانب البرامج الخاصة بالمجال (مثل Swift for TensorFlow). يختتم الحديث بقصة بداية ونمو RISC V ISA.

بالنسبة لأولئك الذين يفضلون مقالًا مكتوبًا على مقطع فيديو ، تحتوي اتصالات هذا الشهر من ACM على مقال من تأليف Hennessy و Patterson (مؤلفي كتاب هندسة الكمبيوتر الشهير) حول هذا الموضوع بالذات. ربما انتهى قانون مور للترانزستورات ، لكن يبدو أن هناك قانون مور للنمو في عدد أوراق التعلم الآلي التي يتم نشرها في السنوات الأخيرة.

فيديو [هينيسي في ستانفورد ، حوالي ساعة واحدة]

فيديو [Patterson at Facebook'sScale Conference ~ 30 دقيقة]

5. سلوك العميل الآمن ، آرييل غوه

يجب أن يكون هذا واضحًا للأيدي القديمة للأنظمة الموزعة ، ولكن يجدر التأكيد على أن العملاء جزء مهم من النظام الموزع وبالتالي يجب عليهم المشاركة في جهود المرونة. هذا حديث رائع من SRECon Asia / Australia حول أفضل الممارسات لتصميم العميل لتحسين مرونة النظام بأكمله. تتضمن الأساليب المقترحة تذبذب طلبات العملاء ، وإضافة العشوائية بحيث لا ينتهي كل العملاء بالمزامنة عند تقديم طلبات ، وعندما لا تتم إعادة المحاولة ، ويعيدون المحاولة ، ويعيدون المحاولات المتسارعة الأسية (والمعايرات المصاحبة) ، و "إعادة محاولة الميزانيات" ) ، نقل بعض التحكم إلى الخادم وإنشاء حلقة تغذية مرتدة بين الخادم والعملاء ، والاختناق التكيفي على العملاء وأكثر من ذلك بكثير.

فيديو

6. كيفية الخدمة والحماية (مع عزل العميل) ، فرانسيس جونسون

هذا حديث ممتاز آخر من SRECon Asia / Australia حول حماية خدمة مثل خرائط Google (مع عدد كبير من العملاء الداخليين والخارجيين) من الحمل الزائد. يتطرق الحديث إلى مشكلات مثل التحميل الزائد للنظام (والمشاكل المصاحبة مثل انخفاض المراحل المبكرة من النسيان عن التحميل الزائد للنظام) ، والفشل المتتالي ، ومخاطر الحصص الثابتة ، وإيجابيات وسلبيات تطبيق تقنيات التدهور الرشيق في طبقات مختلفة من الرصة (العميل ، الحافة ، الواجهة ، الخلفية).

فيديو

7. نظرية الأداء التطبيقية ، كافيا جوشي

هذا حديث لا يصدق (كما هو الحال دائمًا) من قبل Kavya من QCon London حول كيفية استخدام تقنيات نمذجة الأداء لتتمكن من الإجابة على أسئلة مثل الحمل الإضافي الذي يمكن للنظام دعمه دون تقليل زمن الاستجابة وكيفية اكتشاف اختناقات استخدام النظام. ينقلنا الحديث أولاً عبر مثال نموذجي لخادم الويب لشرح كيفية تحليل الأداء في "الأنظمة المفتوحة" متبوعًا بمثال "الأنظمة المغلقة" ، وكيف يعتمد كلاهما على افتراضات مختلفة ويتطلبان تقنيات مختلفة للتحليل.

شرائح الفيديو

8. Amazon Aurora: اعتبارات التصميم لقواعد البيانات العلائقية السحابية عالية الإنتاجية ، Sailesh Krishnamurthy

كان هذا حديثًا صارخًا تمامًا من مؤتمرScale على Facebook حول بعض قرارات التصميم والمفاضلات التي تقوم عليها Amazon Aurora ، محرك التخزين الذي يشغل العديد من عروض قاعدة بيانات AWS الشهيرة. يُدعى Aurora أن يصل حجمه تلقائيًا إلى 64 تيرابايت لكل مثيل لقاعدة البيانات ، ويوفر أداءً عاليًا وتوافرًا مع ما يصل إلى 15 نسخة متماثلة من قراءة زمن الانتقال المنخفض ، واسترداد في الوقت المحدد ، ونسخ احتياطي مستمر إلى S3 ، وتكرار في ثلاث مناطق توفر.

هناك صحيفتان [1] [2] مصاحبتان نشرتهما أمازون على أورورا. يشير النقاش إلى العديد من النقاط من الورقة الثانية على وجه الخصوص ، مع كون الوجبات الجاهزة الرئيسية هي أن الإجماع الموزع يقتل الأداء ويمكن أن تكون الحالة المحلية أمرًا جيدًا بالفعل. مع استخدام سجل ثابت كمصدر للحقيقة ، تتجنب Aurora إجماعًا موزعًا على تغييرات العضوية من خلال الاستفادة من بعض "واحات التناسق" مع استخدام الحقبات كحراس كشكل من أشكال النصاب القانوني للكتابة وتجنب القيام بنصاب النصاب القانوني تمامًا. إنه أمر مثير للاهتمام في عصر تصنع فيه أنظمة المعاملات شيئًا ما من جديد ، وتعتزم Google بالسبب وراء اختيار التماسك القوي ، كلما أمكن ذلك ، تختار أمازون مفاضلات مختلفة.

فيديو

9. مستقبل طبقة التخزين FoundationDB ، ستيف أثيرتون

كان هذا حديثًا مثيرًا حول مستقبل طبقة التخزين في FoundationDB من قمة FoundationDB. FoundationDB عبارة عن مخزن قيمة رئيسي موزع وموزع ، لكن طبقة التخزين نفسها غير موزعة ويمكن الوصول إليها من خلال عملية واحدة من مؤشر ترابط واحد. يتطرق الحديث إلى متطلبات محرك تخزين جديد ، وعدم متطلبات (كتاب متزامنون ، زمن استجابة منخفض) ، ثم يستكشف إيجابيات وسلبيات العديد من هياكل البيانات du jour (B + tree ، وأشجار LSM) والأسباب الكامنة وراء اختيار Redwood versioned شجرة ب +

فيديو

كان هناك حديث عظيم آخر من قمة FoundationDB هو ذلك الموجود على طبقة المستندات ، والذي يمكن العثور على الفيديو الخاص به هنا.

10. الاختبار الذاتي ومستقبل تطوير البرمجيات ، ويل ويلسون

بادئ ذي بدء ، ربما يكون Will أحد أفضل المتحدثين الذين سبق لي أن شاهدتهم وهم يتحدثون (حديثه السابق حول اختبار الأنظمة الموزعة باستخدام المحاكاة الحتمية من Strangeloop 2014 هو أحد أفضل المفضلين لدي على الإطلاق).

هذا حديث هائل من قمة FoundationDB الافتتاحية التي تقدم حجة قوية لنهج يحركها الذكاء الاصطناعى لاختبار. يحدد الحديث ثلاث مشاكل رئيسية في الاختبار: الهشاشة (يعتمد الاختبار على خصائص نظامك العارضة - التي ليست تلك التي اعتقدت أنك تختبرها) ، والافتقار إلى الشمولية والقلة.

يجادل النقاش بأن الاختبارات تعتبر رائعة بالنسبة إلى ظهور الانحدارات ، ولكنها غير مجدية تقريبًا لاكتشافها مجهولة. يمتد الحديث إلى اعتبار جميع المشكلات المذكورة أعلاه بمثابة الأعراض ، حيث تكمن المشكلة الأساسية الحقيقية في أن الاختبار ما زال يدويًا تمامًا. حتى "الاختبار الآلي" لا يشتمل على الإطلاق على جينكينز الذي يدير مجموعة اختبار مؤلفة يدويًا من قبل البشر. يضع الحديث بعد ذلك الحلم المتمثل في الاختبار المستقل باعتباره الحاجة إلى إنشاء الاختبارات تلقائيًا ، بالإضافة إلى التنفيذ التلقائي للاختبارات.

فيديو

11. تصميم الأنظمة الموزعة باستخدام TLA + ، Hillel Wayne

كان هذا حديثًا سهل الوصول إليه من CodeMesh حول استخدام المواصفات الرسمية لتصميم الأنظمة الموزعة. فكر في الأمر كمقدمة لطيفة لـ TLA +. تشمل قائمة الأسعار ما يلي:

امنح النظام وقتًا كافيًا وسيفعل كل شيء ، بما في ذلك الفشل.
الكود ليس تصميم الكود لا يظهر لك كيف يعمل نظامك. إنه مجرد تطبيقك ؛ ليس من المفترض أن يكون التصميم الخاص بك ، لا يمكن أن يكون التصميم الخاص بك. وإذا كنت تعتقد أنه يمكنك تصميم نظام وفهم نظام به الكود فقط ، فلدي جسر لبيعه ، وسأبيعه لك مرتين ، في نفس الوقت.

فيديو

12. ما حصلنا عليه من خطأ: الدروس المستفادة من ولادة Microservices في Google ، Ben Sigelman

كان هذا كلامًا عنيفًا حول نواة الحوسبة الموزعة في Google ، حيث تناول كل شيء حصلت عليه Google في ممارسات لم تكن جيدة تمامًا ولكن كانت لها أوجه تشابه قوية مع ما نعرفه "خدمات ميكروية" هذه الأيام. يبرز الحديث أين تعمل الصناعة الأوسع في الواقع على بعض الأشياء بشكل أفضل من كيفية قيام Google بذلك (مثل شبكات الخدمة) ، ومتى ولماذا لا تعمل محاكاة خيارات Google التكنولوجية وممارساتها بشكل جيد بالنسبة لبقية لنا ولماذا يصبح من المهم بشكل خاص تكون قادرة على الإجابة على أنواع معينة من الأسئلة قبل اعتماد النماذج المعمارية du jour (مثل "serverless").

شرائح الفيديو

13. ورشة التصميم الموزعة لمعالجة الأخشاب ، لورا نولان ، فيليب تيشلر ، سالم فيرجي

هذا حديث لا يصدق على الإطلاق حول الجوانب العملية لتصميم نظام توزيع واسع النطاق ، بما في ذلك كيفية التعامل مع التوسع ، وكيفية تقييم المفاضلات على طول محاور مختلفة ، بالإضافة إلى أطنان من حسابات المغلف لتبرير كل قرار.

يشتمل كتاب SRE Workbook (المتاح مجانًا على الإنترنت) من Google على فصل كامل يسمى "تصميم النظام الكبير غير المستخلص" والمخصص لهذا الموضوع بالذات ، وقد سمعت أنها المقابلة الحاسمة في حلقة مقابلة Google SRE بأكملها ، لأنها الفصل الذي من المرجح إحصائيًا أن يصل المرشح إلى أعلى متبوعًا بمقابلات الترميز. شخصيا ، أعتقد أن هذا لا يتعلق فقط بـ SREs ولكن يجب أن يكون مطلوبًا القراءة لكل شخص يقوم ببناء وتشغيل الأنظمة الموزعة.

لسوء الحظ ، لم أتمكن من العثور على فيديو لهذا الغرض.

الشرائح

14. موازنة التحميل في Hyper Scale و Alan Halachmi و Colm MacCarthaigh

هذا حديث رائع حقًا في مؤتمر FacebookScale على Facebook حول تطور موازنة التحميل في AWS. إنه يلقي الضوء على HyperPlane ، وهو نظام يقوم على أساس موازن التحميل S3 لـ AWS وبوابة VPC NAT و PrivateLink والمزيد. لقد استمتعت بشكل خاص بالتعرف على مبدأ SHOCK المقترح (الشفاء الذاتي أو العمل الثابت) ، والذي يوحي بأنه عند إنشاء نظام ، يجب أن يكون مرنًا حتى للصدمات الكبيرة. أو بعبارة أخرى ، "إذا تغير شيء كبير ، يجب أن يكون النظام قادرًا على الاستمرار كالمعتاد". الحديث يقترح ما يلي:

1. الجهد المستمر والانتعاش من الفشل هي الحالات الطبيعية
2. تعمل دائما في وضع الإصلاح. عندما تفشل العقدة ، لا تعمل Hyperplane فعليًا في الواقع!
3. عند تصميم أنظمة كبيرة الحجم ، لا نريدها أن تكون معقدة. نريدهم أن يكونوا بهذه البساطة قدر الإمكان. تحقيقًا لهذه الغاية ، نريد أقل عدد ممكن من أوضاع التشغيل (لا تحتوي Hyperplane على وضع إعادة المحاولة ، على سبيل المثال. إنها حصالة على آلية إعادة المحاولة الفطرية لـ TCP). تتراكم على أوضاع تشغيل مختلفة ينتج عنها انفجار اندماجي من التعقيد مما يؤدي إلى صعوبة اختبار النظام بشكل لا يصدق. نريد نظامًا متسقًا ويقوم دائمًا بالطريقة التي نتوقعها.
4. يقدم الحديث أيضًا فكرة التقاسم العشوائي ، وهي تقنية تخفيف DDoS (حيث تكون العزلة هي تقنية التخفيف الأساسية) التي يتم نشرها الآن على نطاق واسع عبر العديد من خدمات AWS.

فيديو

15. العزلة بدون حاويات ، تايلر ماكمولين

أحد مجالات اهتماماتي هو ما أصفه للأصدقاء على أنه "طيف الحساب" - أجهزة VM وأجهزة microVM وأجهزة VM متداخلة وحاويات (ونكهات "حاويات رمل" مثل حاويات Kata) و "بدون خادم" (أو وظائف كخدمة). أنا مهتم بشكل خاص بـ "طيف العزلة" الذي تقدمه هذه العروض - من العزلة الصارمة على مستوى العملية إلى العزلة عبر صندوق رمل مثل V8. ظهرت العديد من التقنيات في السنوات الأخيرة في مساحة المحاكاة الافتراضية ، مثل gVisor (برنامج Hypervisor الذي يقوم بتنفيذ مجموعة فرعية من Linux kernel API في مساحة المستخدم) إلى Firecracker - شاشة جهاز افتراضي تم تصميمها لتشغيل أحمال عمل خفيفة الوزن وخوادم في أجهزة micro-VM ، نفسها مبنية على أعلى crosvm (Virtual Machine Monitor لـ Chrome OS). واحدة من أكثر التطورات الرائعة في هذا الفضاء هي WebAssembly. تم تصميم WASM في البداية كهدف لرمز أصلي ليتم تشغيله على المتصفحات ، ويتم الآن الاستفادة من مزودي CDN لتشغيل شفرة تعسفية دون أي شكل من أشكال العزلة القائمة على العملية. بينما لا أزال أعتقد أن هيئة المحلفين تدور حول ما إذا كان هذا الشكل من العزلة يجتاز حقًا حشدًا ، كان هذا حديثًا رائعًا من Strangeloop حول هذا الموضوع بالذات والذي يشرح ميزات WASM التي تجعل هذا الأمر ممكنًا إلى حد ما.

فيديو

16. كيف تعمل C ++ Debuggers ، سايمون براند

العنوان جميل جدا. تشرح المحادثات كل شيء من ماهية ثنائيات ELF ورموز DRAWF وآليات كيفية عمل نقاط التوقف وما يستتبعه التنقل عبر الكود فعليًا والعمل مع تطبيقات متعددة الخيوط في مصحح أخطاء وغير ذلك الكثير. هذا بالتأكيد أحد أفضل ثلاثة محادثات في قائمة المحادثات المذهلة هذه.

فيديو

17. فلسفة تصميم البرمجيات ، جون أوسترهوت

كان كتاب "فلسفة تصميم البرمجيات" هو أفضل كتاب فني قرأته في عام 2018. كل فصل في الكتاب يستحق ثقله بالذهب ، لكن الفصل الخاص بالوحدات النمطية العميقة ربما يكون أكثر ما أشرت إليه. يمس الحديث بعض الأفكار الرئيسية والأعلام الحمراء التي تم تقديمها في الكتاب ، لكن إذا كنت أنت ، فسوف أشتري الكتاب فقط وانتهي منه.

كتاب فيديو

18. Clangd: بنية خادم لغة C ++ قابل للتطوير ، Ilya Biryukov

أحد أكثر تطورات Microsoft إثارة للاهتمام في السنوات الأخيرة هو بروتوكول خادم اللغة. قدم الإصدار 5.0 من برنامج التحويل البرمجي clang تطبيق Clangd، LLVM لتطبيق بروتوكول خادم اللغة. Clangd هو تطبيق لبروتوكول خادم اللغة ، لتوفير ميزات مثل إتمام التعليمات البرمجية ، إصلاحها ، تعريف goto ، إعادة تسمية إلخ للعملاء مثل برامج تحرير مصدر C / C ++. كان هذا حديثًا جيدًا من CPPCon تطرق إلى بعض القيود المفروضة على libclang ، ويشرح الدوافع الكامنة وراء تطوير Clangd وكذلك هندسته العامة.

19. تمثيل Coroutine و ABIs في LLVM ، جون مكول

تمت إضافة Coroutines in LLVM لأول مرة من قِبل Gor Nishanov من Microsoft وتم تصميمه حول احتياجات C ++ coroutines TS. كان هذا حديثًا لا يصدق من اجتماع مطوري LLVM الذي يتناول بعض إيجابيات وسلبيات اعتبارات التنفيذ المختلفة مثل التحكم في التسوية (تبديل السياق ، تقسيم coroutine مع الاستئناف المشترك ووظائف استئناف العائد) ، تخزين الحالة المحلية (coroutines المكدس ، تخصيص جانبي ، تعايش مكدس) لإعطاء البيانات ، بالإضافة إلى تحديات إنشاء كود لميزات اللغة التي تدعمها coroutines مثل المولدات. يعالج الحديث بعد ذلك بعض التفاصيل الخاصة بنوع مختلف من التخفيضات يسمى "نكهة استمرار الإرجاع" للغة برمجة سويفت ، حيث تحدث بعض التحسينات في طبقة سويفت SIL وليس مباشرة على مستوى LLVM.

فيديو

ملحوظة: كل المحادثات من اجتماع LLVM Developer 's تعليمي عميق. لقد شاهدت هذا الكلام واحدًا فقط ، لكنني متأكد من أنني أوصى بسعادة جميع الآخرين أيضًا ، بمجرد أن أتجول لمشاهدتهم.

20. تطوير Kotlin / Native البنية التحتية مع LLVM / Clang ، نيكولاي ايجوتي

يعد Kotlin Native تطورًا مثيرًا للاهتمام للغاية في السنوات الأخيرة مما يسمح بتجميع كود Kotlin وصولًا إلى ثنائيات النظام الأساسي (ELF ، Mach-O ، WASM ، إلخ) ، بحيث يمكن تشغيله محليًا بالإضافة إلى القدرة على تشغيله داخل JVM. كان هذا حديثًا جيدًا من اجتماع مطوري LLVM الأوروبي حول آليات Kotlin / Native ، بما في ذلك بعض التحديات التي تواجه تطبيق إدارة الذاكرة خارج JVM ، والتعامل مع الاستثناءات ، والانتقال إلى WASM (الذي لا يوجد لديه وقت تشغيل ، لا يوجد مخصص ذاكرة ، لا استثناءات وما إلى ذلك) ، بالإضافة إلى بعض المشكلات العامة التي تواجه LLVM (الترميز البطيء والربط ، واجهة برمجة تطبيقات LLDB plugin العامة وما إلى ذلك).

شرائح الفيديو

21. الطازجة المتزامن مع Kotlin ، رومان إليزاروف

طيف البرمجة غير المتزامنة واسع ومتنوع. كان هذا حديثًا رائعًا من Goto Copenhagen حول التحديات التي تقوم عليها بعض هذه النماذج من البرمجة غير المتزامنة ، ولا سيما النهج القائم على رد الاتصال مع العقود المستقبلية. يستمر الحديث بعد ذلك لمعالجة الكيفية التي تهدف بها Kotlin إلى حل هذه المشكلة بالكوروتينات من خلال توفير واجهة متزامنة للمستخدم (عبر البدائية الموقوفة) بينما تحت غطاء محرك السيارة باستخدام الاستمرارية ونقاط التعليق لبناء آلة الحالة. كان الجزء الأكثر روعة في النقاش هو المقارنة بين نهج Kotlin ونهج C # الخاص بعدم التزامن / الانتظار ، حيث يتمثل السبب الرئيسي وراء خيارات تصميم Kotlin في أن التزامن صعب ويجب أن يكون ergo واضحًا. وينتهي الحديث بكيفية تطبيق أنماط CSP-esque باستخدام بدائل corotine من Kotlin.

فيديو

22. Kotlin Native التزامن النموذجي ، نيكولاي ايجوتي

ليس لدى Kotlin أي بدائل التزامن على مستوى اللغة. كووتلين كوروتين كما هو موضح في نقاش أعلاه هو بناء مكتبة تستند إلى JVM. يتجنب Kotlin / Native كومة كائن JVM المشتركة وقفلها عن طريق الحفاظ على ثابت أن الكائن إما مملوك من قبل سياق تنفيذ منفرد ، أو أنه غير قابل للتغيير (مشترك XOR قابل للتغيير). كان هذا حديثًا رائعًا من KotlinConf يتطرق إلى كيفية تحقيق ذلك من خلال "الرسومات الفرعية للكائنات غير المشار إليها خارجيًا"

علاوة على ذلك ، فإن لغة Kotlin كلغة لا تملك قابلية ثابتة مضمنة في نظام الكتابة. يتم تحقيق الثبات عن طريق مفهوم التجميد ، والذي يجعل الإغلاق متعدية لجميع الكائنات قابلة للوصول من كائن معين غير قابل للتغيير. بالإضافة إلى ذلك ، يسمح Kotlin / Native أيضًا بنقل ملكية الكائنات عبر سياقات التنفيذ. يقدم الحديث الأوليات الأساسية المتزامنة الآمنة التي توفرها Kotlin / Native مثل "الرسوم البيانية للكائنات القابلة للانفصال" ، والذرات و "العمال" على غرار الممثل ، وكيف تعمل الإدارة المرجعية للاعتماد على الذاكرة في Kotlin / Native ، وكذلك كيف تحقق قابلية التشغيل البيني مع غيرها أوقات التشغيل.

شرائح الفيديو

23. هل حان الوقت لكتابة نظام التشغيل في راست ، براين كانتريل

لقد كنت غالبًا ما أتعرض لشخص أو نظري آخر لكرسي بذراعين مفاده أن الصدأ هو "لغة مصممة لكتابة نواة".

حسنا ، أليس كذلك؟

يعد هذا حديثًا رائعًا من قبل الخبير الأول حول موضوع لماذا Rust مناسب بشكل خاص لبرامج أنظمة الكتابة ، فضلاً عن بعض التحديات التي يحتمل أن تكتب نواة كاملة في Rust. إذا كنت ترغب في القيام برحلات عبر سجلات تاريخ الحوسبة وتلك العلامة التجارية النادرة التي تدور حولها بالفعل تلك التي يقوم عليها بالفعل تفكير مستنير ومنطق ، فقد يكون هذا هو الحديث عنك.

شرائح الفيديو

24. ماذا تقصد "آمنة موضوع"؟ ، جيفري رومر

كان هذا حديثًا رائعًا من CPPCon يهدف إلى إزالة الغموض عن مصطلحات مثل "مؤشر الترابط الآمن" أو مصطلحات أكثر دقة مثل "سباق البيانات" و "حالة السباق" التي تعمل غالبًا في المستوى الخاطئ من التجريد. يقترح الحديث استخدام مفهوم "سباق API" والمبادلات التي يمكن بناؤها حول "سباق API" ، متبوعة بتوصيات لكل من مكتبة C ++ ومؤلفي التطبيقات حول

فيديو

25. سريع آمن دولة قابلة للتغيير ، بن كوهين

عندما يتعلق الأمر بحالة قابلة للتغيير ، من المهم أن نتذكر أن الحالة القابلة للتغيير المشتركة سيئة وغير قابلة للتغيير في حد ذاتها. كان هذا حديثًا رائعًا من مؤتمر "Functional Swift" حول كيفية وكيفية استخدام الحالة المحلية القابلة للتغيير دون التضحية بالأمان أو الأداء. يتحدث الحديث من خلال بعض ميزات اللغة في Swift التي تضفي عليه نكهة وظيفية معينة عن طريق منع فئات معينة من الأخطاء المحتملة في تحوير الوظائف.

فيديو

26. The Dos and Donts of Error Handling، Joe Armstrong

كان من دواعي سروري مشاهدة هذا الحديث على الهواء مباشرة في GOTO Copenhagen. الهدف الرئيسي من هذا الحديث هو أنه من المستحيل تحقيق التسامح مع الأخطاء باستخدام جهاز واحد ؛ رسالة يمر وبالتالي يصبح لا مفر منه. بناء النظم الموزعة المتسامحة مع الأخطاء تتلخص في اكتشاف الأخطاء والتصرف فيها. إن فلسفة معالجة الأخطاء التي تعتبر الأكثر حكمة هي تلك التي يمكن إثبات صحة البرنامج فيها في وقت التحويل البرمجي وحيث يُفترض أن البرنامج غير صحيح بحكم الواقع ويتوقع أن يفشل في وقت التشغيل. التجمعات الكبيرة من الأشياء الصغيرة يستحيل إثبات صحتها ؛ وبالتالي يصبح من المهم أن تكون قادرًا على تحديد "kernel error" ، وهي مجموعة فرعية من النظام يجب أن تكون صحيحة. إذا كنت لا تعرف ما تفعل كمبرمج ، فعليك التعطل. ثم يصبح البرنامج أكثر بساطة.

ستغفر لك للتفكير في الأمر كشرح لمدة 45 دقيقة لوجود لغة برمجة Erlang.

فيديو

27. QUIC: تطوير ونشر استبدال TCP لبرنامج الويب ، Ian Swett و Jana Iyengar

كان هذا حديثًا رائعًا من NetDev والذي يقدم مقدمة لبروتوكول QUIC الذي تم تطويره في Google ، وقرارات التصميم (لماذا تضعه فوق UDP ، واستعادة أفضل للخسارة ، والتحكم المرن في الازدحام) وتطوره بالإضافة إلى عدد لا يحصى من المغامرات التي تقيس QUIC على نظام Linux .

شرائح الفيديو

28. تقديم شبكة Network.framework: بديل حديث عن Sockets ، Josh Graessley ، Tommy Pauly ، Eric Kinnear

قد يكون من الصعب استخدام المقابس عندما يتعلق الأمر بإنشاء التوصيل أو نقل البيانات (حتى مع المقابس غير المقيدة للحركة) أو التنقل.

Network.framework عبارة عن واجهة برمجة تطبيقات نقل حديثة تعد بديلاً للمآخذ على منصات Apple. كان هذا مسيرًا رائعًا من WWDC 2018 الذي سار خلال تشريح مؤسسة اتصال أولية إلى دورة حياة الاتصال ، إلى جانب التحسينات التي لا تعد ولا تحصى التي تمت في مراحل مختلفة. إنه أيضًا أفضل الكلام المعروض في هذه القائمة.

فيديو

29. Kubernetes والطريق إلى Serverless ، كيلسي هايتاور

إنه حديث من كيلسي هايتاور.

أحتاج أن أقول بعد الآن؟ لا أعتقد ذلك.

فيديو

30. باستخدام الصدأ لتطوير اللعبة ، كاثرين ويست

يبدأ الحديث بقوله "ربما يكون هذا هو الكلام الأكثر مملة ..."

ليست كذلك.

قد يكون في الواقع أفضل حديث في هذه القائمة.

فيديو