في 28 سبتمبر ، في مؤتمر
Evrone RubyRussia DevRel ، سيتحدث
غريغوري بيتروف عن كيفية تواصل الخدمات الدقيقة. في مقابلة اليوم ، تحدث
إيفان سولوفيوف مع غريغوري حول موضوع خطابه المرتقب وليس فقط عن ذلك.
أخبرنا عن نفسك ، ماذا تفعل في إيفرون؟أنا منخرط في علاقات المطورين - هذا شيء بين DevRel و Technology Evangelist ، مطور يمكنه التحدث في المؤتمرات. اعمل مثل Robin Hood: تواصل مع فرق التطوير داخل الشركة ، وجمع مختلف الأشياء المثيرة للاهتمام من ما يقومون به ، وتحدث عنه في المؤتمرات. سيكون روبي روسيا أحد المؤتمرات الأولى التي سأتحدث بالنيابة عن الشركة.
أعرفك كواحد من منظمي مؤتمرات بايثون المختلفة. أخبرني كيف أتيت إلى عالم روبي؟لم أغادر عالم روبي أبدًا. واحدة من أولى محاضراتي كانت بيثون ضد روبي. منذ عدة سنوات ، عندما كتبت في لغة C ++ ، كنت بحاجة إلى آليات أتمتة عالية المستوى لأي اختبار أو إنشاء مستندات. ثم كتبت في بيثون وروبي ، وقليلا في PHP. كنت أبحث عن أفضل الطرق لحل المشكلات التي واجهتني.
كم سيتم استعارة تقريرك من فرق التطوير داخل الشركة؟ أعلم أنك كتبت بعدة لغات: Ruby و Python و PHP و TypeScript و JavaScript و C ++ وليس فقط.سيكون التقرير حول توصيل الخدمات الصغيرة فيما بينها عبر الشبكة والبروتوكولات المستخدمة لهذا والصعوبات الناشئة. في الواقع ، لدي علاقة طويلة مع الشبكة. فعلت رادمن ، هذه هي أداة شبكة للتحكم عن بعد. مشروع NPTV (الذي عملت فيه أيضًا DevRel) هو تلفزيون تفاعلي يستخدم الشبكة بشكل فعال ويسيطر على روبي. Voximplant (حيث درست DevRel مرة أخرى) هي مهاتفة قابلة للبرمجة حيث قابلت VoIP. الشبكة قريبة جدا مني. يمكنني تقديم تقرير بناءً على تجربتي ، لكن بهذه الطريقة لن أحمل القيمة القصوى لضيوف المؤتمر ، لكنني أريد أن أحمل أقصى فائدة. أثناء الإعداد الأولي للتقرير ، قابلت عدة فرق من Evrone. يتمثل نشاط الشركة في تطوير برامج معقدة وعالية الجودة ، حيث تعمل العديد من الفرق في مشاريع مختلفة. اتصلنا في Zoom وتحدثنا لمدة ساعة أو أكثر. ناقشوا ماذا وكيف يفعلون ، ما الصعوبات ، ما هي الكدسات التي يستخدمونها. سيكون تقريري نصف الشبكة ، وبروتوكولات الشبكة ، والتعقيد والتطبيق ، ونصفها حول كيفية استخدامه في روبي من قبل فرق مختلفة.
لديك الكثير من التواصل مع المطورين. ما مدى محدودية رأيك في العمل مع شبكة في روبي؟تتكون الشبكة من عدة أجزاء. بادئ ذي بدء ، عمل لغة البرمجة ونظامها الإيكولوجي مباشرة مع وحدات البايت المنقولة عبر الشبكة. كومة الشبكة المستوى الأدنى. على سبيل المثال ، يستخدم نفس JS و Node
libuv ، وهو نموذج غير متزامن. هناك دفق رئيسي ، وكنت تعمل مع الشبكة في نهاية المطاف. لديك coroutines لهذا الغرض. لديك الكثير من التوقعات ، يمكنك الانتظار من أجل الحصول على البيانات ، يمكنك الانتظار حتى يتم إرسال البيانات. يوفر مؤشر الترابط الفردي هذا آلاف وعشرات الآلاف من الاستعلامات في الثانية.
على هذا الأساس ، يتم تطوير الأطر ، أيا كانت. على سبيل المثال ، ليس لدى JS أطر عمل جادة للعمل مع الشبكة (والتي يمكنك تهنئته عليها!). باستثناء التطبيق Express.js ، الذي لا يكاد يكون إطارًا متكاملًا. تحولت بيثون إلى نموذج مماثل ، وظل إطار جانغو الأكثر شعبية في النموذج السابق. يوجد الآن نوع من الخلاف - إطار عمل متزامن يحاول الانتشار عن طريق حظر الخيوط ، والعمليات باستخدام GIL يثبتها ، وعلى الجانب هناك بعض الأشياء الجديدة التي تحاول العمل على نموذج غير متزامن ، على سبيل المثال قنوات Django. لا يزال روبي في النموذج المتزامن وينشر بواسطة العمليات. لذلك ، هنا هو النظام الإيكولوجي المقابل ، المناهج والمواقف القوية للغاية لسكة الحديد.
ما هي قوة روبي؟ بادئ ذي بدء ، في DSL ، لغة محددة المجال. عندما نتحدث عن الشبكة ، يلعب روبي دورًا أفضل في المجال حيث يكون الأقوى. عندما نستخدم GraphQL ، فهذا يعني أن المكتبات لاستخدام GraphQL موجودة في كل مكان. في روبي ، سوف يستخدمون بناء جملة DSL جيدًا لتحديد المخطط. والتكامل بين بناء جملة DSL وبناء جملة DSL ORM في ActiveRecord. هذا هو بالضبط ما يمكن أن نتوقعه من روبي. في الوقت نفسه ، لن يكون لدينا أي عمليات غير متزامنة (في انتظار) ، وسوف يتم تحجيمها من خلال العمليات وسيكون لدينا متطلبات الخادم المقابلة.
ذكر تقريرك العديد من بروتوكولات التفاعل. نفس JSON: API وهلم جرا. ما الطريقة التي ترى بها مزيدًا من التطوير ، هل سننزل جميعًا إلى GraphQL؟سؤال رنان جدا. في رأيي ، بدأت مع حقيقة أن الشبكة بطيئة. التطبيقات في البداية بسيطة. وكقاعدة عامة ، تستخدم جميع التطبيقات ، روبي وبيثون والعقدة ، نقاط النهاية HTTP المعتادة للاتصال. داخل أنها تستخدم نوعا من الحمولة. سابقا XML ، الآن JSON. إنهم يحققون نتائج جيدة في الأشهر أو السنوات القليلة الأولى ، كما لو كانوا محظوظين. بعد ذلك ، يبدأ العمل في طرح أسئلة معقدة. على سبيل المثال ، تحتاج إلى الحصول على بعض المستخدمين ولكي يحصل كل مستخدم على قائمة بالشركات التي يعمل فيها. تكمن المشكلة هنا: إذا كنت تستخدم نقطة النهاية ، فستكون هناك عدة عشرات أو مئات الطلبات ، وتكون الشبكة مهللة: الطلب ، الاستجابة ، الحزم المفقودة. سيكون بطيئًا بشكل سيء وسيحتاج الأمر إلى نقل الكثير من البيانات عبر الشبكة. 100 مرة أكثر من البيانات المطلوبة. ينهار نظامنا ، لأن أنظمة أتمتة الأعمال الكبيرة تنهار في ظل هذه الطلبات ، والتي تتحول خلال 10 سنوات إلى وحوش ، حيث يمكن أن يستغرق سؤال صعب من الواجهة دقائق وساعات. طوال هذا الوقت ، ستعمل قاعدة البيانات الموجودة على الواجهة الخلفية على مجموعة من الطلبات المتطابقة ، وستطارد مجموعة من الطلبات المتطابقة عبر الشبكة. نحن نحاول حلها بطرق مختلفة.
إعطاء أمثلة حقيقية لهذه المشاكل؟لقد كان Facebook مميزًا بشكل خاص ، فهذه المشكلة حادة جدًا: هناك الكثير من البيانات التي يرغبون في إجراء استفسارات معقدة بشأنها. على سبيل المثال: أرني أولئك الذين علقوا على هذه المشاركة وأصدقائهم. من أجل عدم تقديم ملايين الطلبات ، يستخدم Facebook خيارات مختلفة. على سبيل المثال ، FQL ، Facebook Query Language. بعد أن جمعوا كل خبراتهم ، صنعوا GraphQL - وهو الشيء الذي يسمح لك بإجراء استعلامات شبيهة بـ SQL على العميل. ولكن هذا ليس SQL ، لأننا لا يمكن أن نعلقها على قواعد البيانات ، ولكن الاستعلام من حيث الواجهة الخلفية API. يمكنك إرسال طلب واحد وتحصل على إجابة (أو كيف تسير الأمور).
المشكلة الكبيرة الثانية هي ما يجب فعله إذا أردنا الحصول على الكثير من البيانات من الواجهة الخلفية. على سبيل المثال ، خمسة آلاف مستخدم أو سجل في 10 ميغابايت. إنه لأمر مخيف أن تفعل كل شيء مع واحد استجابة طلب HTTP. لأنه إذا انهارت الشبكة ، فسيتعين تكرار الطلب بالكامل ، وقد يستمر هذا إلى الأبد. العودة إلى Facebook: لقد صنعوا GraphQL ، عكازًا عبر الشبكة. ثم فعل الآخرون HTTP / 2 ، مما يحل مشكلة الشبكة. يقوم HTTP / 2 بإجراء اتصال غير متزامن واحد ، يمكننا من خلاله تقديم العديد من الطلبات الصغيرة. يحارب HTTP / 2 GraphQL إذا لم يكن لدى خادم GraphQL الكثير من السحر لتحسين عدد الاستعلامات إلى قاعدة البيانات على الواجهة الخلفية. وفي الحديث ، سنتحدث عن ما يقدمه روبي لهذا السحر. مع HTTP / 2 ، قد لا تكون هناك حاجة GraphQL. يمكننا تقديم 100 طلب HTTP / 2 لنقطة النهاية الخاصة بنا ، ومن وجهة نظر البايتات ، لن يكون الحمل أكبر مما لو استخدمنا GraphQL. تقوم Google Buffers Buffers و gRPC بمعالجة هذه المشكلة من النهاية الثالثة. يستخدمون بروتوكولات النقل الثنائية ، خاصة HTTP / 2 ، ويقدمون مخططًا معينًا لـ api. هنا يتنافسون مع REST المعتاد.
في الممارسة العملية ، في معظم الشركات التي تستخدم JSON ، يجلس المبرمج Vasya ويكتب هذا JSON بيديه. بعد ستة أشهر ، تعلمت Vasya أنه يمكن إرسال التاريخ والوقت بمئات الطرق المختلفة. الرعب يبدأ! ولكن إذا كان هناك مطورون جيدون في الشركة ، فإنهم لا يكتبون JSON فقط ، لكنهم يستخدمون نوعًا من المعايير. باستخدام OpenAPI أو JSON Schema ، كل هذه الأشياء المثيرة للاهتمام التي تتنافس مع gRPC. هذه الحديقة الحديثة كلها تحل بعض المشاكل التي عبرت عنها. وماذا سيحدث لهذه الحديقة في المستقبل ، لا يمكنني التنبؤ على الإطلاق. لكنني أدعو المطورين للحضور ومناقشة هذه المشكلة: ما الذي ينتظرنا في العام المقبل ، 3 ، 5 ، 10 وما هو تصرف القوات الآن.
لنتحدث عن مستقبل روبي كلغة برمجة؟من الصعب التنبؤ بالمستقبل. أود حقًا أن أرى أنواعًا جيدة في روبي. روبي 3 هو الآن في المرحلة الأولى من تنفيذ النوع. أود أن يكون بناء الجملة جميلًا. رأيت المقترحات ، وقفت بلدي بقعة أصلع على طرف منهم. بناء جملة فظيعة للغاية التي لن يستخدمها أحد.
لماذا تعتقد ذلك؟أنا عالم فيزيولوجي هواة. التفكير الحدسي الذي يحب الجميع أن يتخذ كل أنواع القرارات الغريبة. على سبيل المثال ، إذا كنت بحاجة إلى كتابة الكثير من الرسائل ، فهذا أمر سيء. يمكن أن تكون هذه الأنواع رائعة للغاية ، ولكن نظرًا لحقيقة أنه يتعين عليك كتابة شفرة أكثر من مرة ونصف ، سنشعر بالعاطفة "لا أريد ذلك". ونحن حساسون للغاية لمشاعرنا ، لذلك لن يستخدمها أحد. أنا حقًا أحب الطريقة التي تم بها نقل الأنواع في Python و TypeScript: من خلال القولون. وهذا يعطي الحد الأدنى من النفقات العامة. كتبنا معرف - بدا. أنا أعرف بالتأكيد أنه سيكون هناك عدد ، تحتاج إلى وضع فخ. المطور يكتب النقطتين وهذا كل شيء ، يتم تثبيت فخ. بعد مرور أسبوعين ، عندما يمر بطريق الخطأ بقائمة أو خط هناك ، سيعمل المصيدة على حفظ المطور لعدة ساعات أو أسابيع من تصحيح الأخطاء.
ماذا تريد أن ترى في روبي؟على مدى السنوات القليلة الماضية ، لقد رأيت الكثير من المزاح مع coroutines. يعجبني هذا حقًا لأن رمز المتزامن مع coroutines سهل القراءة. من المفهوم ، يسمح لك حشر الأشياء المعقدة في بناء جملة بسيط. هذا يتم تنفيذه جيدًا في أحدث بيثون ويتم تنفيذه جيدًا في JavaScript. أود حقًا أن يجلب روبي شيئًا كهذا ... في الواقع ، لدى روبي الألياف. سيكون من الرائع إضافة شيء مثل Node بحيث يمكنك كتابة تطبيقات Ruby غير المتزامنة باستخدام الألياف أو بعض البدائل الأخرى. وتحت غطاء محرك السيارة ، فإنه في حد ذاته يستخدم libuv أو بعض بدائل نظام التشغيل الأخرى للعمل مع الشبكة.
أو من شأنه أن يضع شيئا في الجداول. سوف تستخدم شيئًا من أجل تلبية جميع طلبات الشبكة هذه وطلبات قاعدة البيانات وطلبات نظام الملفات بشكل تنافسي. وأود فقط كتابة coroutine على مستوى أجزاء صغيرة من التعليمات البرمجية التي يتم تنفيذها بناء على طلب وارد أو توقيت ، ثم إعطاء الأوامر وانتظار تنفيذها. علاوة على ذلك ، تحت غطاء محرك السيارة الكثير من السحر ، كل هذا يتم بالتوازي ، ويستهلك سيارة أمازون ضخمة بنسبة 100 ٪ وله عشرات الآلاف من الطلبات في الثانية. في حالة Go ، مئات الآلاف من الاستعلامات في الثانية.
العودة إلى الأنواع. من المحتمل أن يكون هذا مقدمة تدريجية لأنواع ، الكتابة التدريجية؟الكتابة التدريجية هي صاروخ ضخم تم إضافته لأول مرة إلى بيثون. حققنا ذلك بحيث يمكن إضافة أنواع قليلا. في رأيي ، نشأ نموذج تطوير كامل عندما تتم كتابة التعليمة البرمجية في البداية بسرعة كبيرة بدون أنواع ، ثم عندما يرى المطور أن جزءًا من الكود قد استقر ، تبدأ الأنواع في الإضافة إلى هذا الجزء من الكود. إنه المكان الذي استقر فيه ، ومن الضروري ضبط الفخاخ بحيث لا يتم كسر أي شيء في المستقبل حول هذه الفخاخ. سيكون رائعًا إذا فعلوا شيئًا مماثلاً لروبي.
ما السؤال الذي تريد طرحه على يوكيهيرو ماتسوموتو في المؤتمر؟لقد كنت أدرس اللغة اليابانية منذ 4 سنوات ، وربما يكون اليابانيون كافيين ليقولوا "شكرًا لك". سوف اتدرب!
نراكم في RubyRussia!سجل ، ومن المتوقع أن الزيادة في الأسعار القادمة بعد 15 سبتمبر ، 700 مشارك بالفعل معنا.
وبفضل التقليدية للشركات التي تدعمنا:
المنظم -
إيفرونالشريك العام -
توبتالالشريك الذهبي -
Gettشركاء الفضة -
JetBrains ،
Bookmate و
Cashwagonالشريك البرونزي -
InSales