ستيفن كليري هو من بين
أفضل 100 مستخدم لـ Stack Overflow. في الغالب بفضل إجاباتها غير المتزامنة في .NET. لا تقتصر حياته على البرمجة: على تويتر ، يكتب أولاً عن نفسه "مسيحي" ، وعندها فقط "مطور".
الآن ، فيما يتعلق بظهور تيارات غير متزامنة ، فإن معرفته مهمة بشكل خاص: كمقرر حول هذا الموضوع ، فإن شخصية ستيفن تثير ذلك. وقريباً جداً على DotNext
سوف يخبرنا بذلك. في هذه الأثناء ، سألناه عن كل هذا: الدين ، وتكدس المكدس ، وعدم التزامن.
سيرة
- السؤال الأول بسيط: أخبرنا عن سيرتك المهنية.- أصبحت مهتمة بالبرمجة مبكرا ، كان عمري 7-8 سنوات. ثم في المدرسة ، تمكنت من كتابة برنامج صغير بلغة Logo ، وكانت هذه أول تجربة برمجة لدي. في وقت لاحق ، عندما كان عمري 12-13 عامًا ، قمت بحفظه على جهاز الكمبيوتر الأول الخاص بي. وعندما اخترت علوم الكمبيوتر عندما التحقت بالجامعة ، كان قرارًا واضحًا للغاية: لقد كنت مهتمًا بالفعل بأجهزة الكمبيوتر لفترة ملموسة.
في عام 1998 ، عندما تخرجت من الكلية ، بدأت أعمل في شركة محلية تعاملت مع الناقلات التي يتم التحكم فيها تلقائيًا بواسطة مركبات للصناعة وأتمتة المصنع الأخرى. بعد سبع سنوات ، انتقلت الشركة إلى ديترويت ، لكنني لم أرغب في الانتقال إلى هناك ، ومنذ ذلك الحين تمكنت من العمل في شركات مختلفة. منذ عام 2013 ، أعمل عن بعد ، في العام الماضي ونصف العام - في Faithlife.
- من المضحك أنك بدأت مع Logo ، والآن في شركة يُطلق على منتجها الرئيسي شعارات. وماذا تفعل بالضبط هناك؟- الخلفية: خدمات الويب التي تصل إليها الشعارات وغيرها من منتجات الشركة. لدى Faithlife مجموعة من المنتجات المتعلقة بالكنيسة. الشعارات - لدراسة الكتاب المقدس. وهناك أيضًا Proclaim ، المصممة لأولئك الذين يلقون العظات (يساعد في الشرائح وما شابه). صنعت Faithlife تاريخيا منتجات للقساوسة ، لكنها الآن تضيف أشياء تساعد الأشخاص العاديين.
أفعل في الخلفية ، غالبًا ما أتعامل مع ASP.NET Web API ، والآن أعمل مع Docker. الآن لدينا جزء في السحابة ، وجزء داخلي ، ولا ينبغي نقل شيء إلى السحابة على الإطلاق ، لكننا نريد نقل بعض الأشياء هناك - وأنا أفعل ذلك.
دين
- لا تقابل غالبًا شركة تقوم بصنع برامج "church" ، لذلك أريد أن أوضح: هل العمل على الواجهة الخلفية يبدو في أي مكان آخر ، أو هل له تفاصيله الخاصة؟ والمطورين وعادة ما يكون المؤمنين وأنفسهم استخدام منتجات الشركة ، أم لا؟- لا توجد اختلافات جوهرية في العمل: تحتاج إلى التفكير في التصميم المناسب لواجهة برمجة التطبيقات بقدر ما في أي مكان آخر. كانت بعض منتجاتنا (خاصة تلك الموجودة على سطح المكتب) موجودة لفترة طويلة جدًا ، وعلينا التعامل مع واجهات برمجة التطبيقات القديمة. وعند البدء في استخدام Docker ، من المهم التفكير في التوافق مع الإصدارات السابقة. بشكل عام ، لدينا نفس المخاوف مثل الآخرين.
على الرغم من أن Faithlife تصنع منتجات للكنيسة ، فإنها ليست شركة مسيحية. للوصول إلى هنا ، لا تحتاج إلى أن تكون مسيحيًا: أولاً ، مثل هذا الاختيار ينتهك القانون الأمريكي (سيكون تمييزًا دينيًا في التوظيف) ، وثانيًا ، لن ترغب الشركة في ذلك على أي حال.
ولكن بالنسبة للمطورين لاستخدام منتجات الشركة ، يتم تشجيعه بكل الطرق. على سبيل المثال ، قضى مؤخرًا يومًا تدريبيًا على استخدام الشعارات. لدينا أيضًا العديد من الأدوات الداخلية - في هذه الحالة ، نشجعنا على الذهاب إلى العمل في القسم الذي يستخدم أداتك لمعرفة كيفية حدوث ذلك شخصيًا.
- على تويتر الخاص بك في المجال الحيوي ، هناك عبارة "مسيحي" و "مطور". هل يتقاطع هذان الجزءان من هويتك بطريقة ما؟- أود أن أقول أنهم منفصلون. كنت أحاول دائمًا فصل الحياة العملية والمنزل عن العمل في أوقات فراغي (رغم أنه لم ينجح دائمًا). الكنيسة جزء كبير من شخصيتي ، ومعظم أصدقائي من هناك. في العمل ، لقد صنعت القليل من الأصدقاء.
"حسنًا ، يقول سيرتك الذاتية أيضًا" مدمن على كتابة برمجيات المصدر المفتوح "، ومنح الناس البرمجيات الحرة أصواتًا غير إنسانية ومسيحية. في هذه الحالة ، لا يوجد أي ارتباط؟- ربما ، ربما. أعتقد ، من وجهة نظر فلسفية ، أنه يمكنك رؤية العلاقة بين المصدر المفتوح والمسيحية: في كلتا الحالتين ، ينصب التركيز على "إعطاء الناس" الذي ذكرته.
هناك أيضًا نوع "إنساني" من المصادر المفتوحة. أنا نفسي لا أشارك في هذا ؛ لدي مكتبات للأغراض العامة. لكنني أعرف المطورين المسيحيين الذين عملوا مجانًا على شيء يؤثر بشكل مباشر على حياة الآخرين ، خاصة في الأماكن التي يعيش فيها الفقراء. على سبيل المثال ، البرنامج الذي يسمح لك بالتأكد من أن أجهزة الإنذار بالحريق تعمل بشكل صحيح. هنا ، بالطبع ، هناك علاقة.
- أنت أيضًا نشط في Stack Overflow - هل هذه طريقة لك أيضًا لتقديم شيء غير أناني للمجتمع؟- أنا لا أقول ذلك ، بالنسبة لي يبدو وكأنه "التدريس". على الرغم من أن "التدريس" يمكن أن يكون مرتبطًا بالمسيحية ... فقد كان لدى أسرتي العديد من المعلمين ، وأنا أواصل ذلك بطريقتي الخاصة - ليس كمهنة ، ولكن بمساعدة Stack Overflow والمؤتمرات. لذلك أنا تلبية حاجتي لهذا الغرض.
كومة الفائض
- لا يزال لدينا عدد من الأسئلة حول Stack Overflow ، أول سؤال أحمق. لقد تلقيت شارة هناك مؤخرًا للحصول على إجابات على Windows Phone 8:
كيف حدث أنك حصلت في عام 2019 على شارة للحصول على إجابات حول تقنية ميتة تقريبًا؟ هل ما زال هناك شخص يطرح أسئلة عليها؟
- للحصول على شارة ، عادة ما تحتاج إلى عدد معين على الأقل من الإجابات مع عدد معين من الأصوات لهذه الإجابات. أفترض أنني حصلت على هذه الشارة لأن شخصًا ما قام بالتصويت لبعض إجابتي ، التي نُشرت قبل سنوات ، ومعها حصلت في النهاية على العدد الصحيح من الأصوات. هذا أمر مضحك لأنني لم أر أسئلة Windows Phone 8 لفترة طويلة جدًا!
(يضحك)- على SO ، سمعتك هي 320،000 - وهذا أكثر من ربع سمعة John Skeet الأسطوري ، على الرغم من أنك أعطيت إجابات بحجم أقل منه. كيف حصلت على هذا؟- لست متأكدا تماما. من الأسهل الحصول على سمعة لأولئك الذين أتوا إلى الموقع قبل أي شخص آخر ، وعلى الرغم من أنني كنت من أوائل المستخدمين ، إلا أنني ما زلت أجيء إلى ما بعد الكثيرين. بدأت بالإجابة على الأسئلة - في البداية ، 1-2 في اليوم ، وهو بعيد كل البعد عن جون سكيت. ركز على موضوع المزامنة / الانتظار ، بالإضافة إلى التزامن وتعدد مؤشرات الترابط - ببساطة لأنه في ذلك الوقت ، في الواقع ، أصبح اختصاصي. قبل عدة سنوات كنت منخرطًا بالفعل في عدم التزامن ، وبعد ذلك كان الأمر مؤلمًا. لذلك عندما ظهرت / لم تنتظر ، رأيت على الفور معنى ذلك. لذلك كنت في الوقت المناسب في المكان المناسب ، وساعدت "دم المعلم" في شرح كل شيء بلغة يفهمها الناس. وفي حالة Stack Overflow ، تحولت إلى أخصائي محلي متزامن / انتظار. وجون سكاييت - حسنًا ، لم يقل ذلك مباشرةً ، لكنني أفترض ذلك - يترك معظم الأسئلة حول المزامنة / تنتظرني. لكنه ، بالطبع ، يجيب أكثر مني كثيرًا ، ولا يمكن أن يقبض عليه!
- بالنظر إلى أرقام السمعة ، من السهل التفكير في "أن الشخص يأخذ نصف حياته للإجابة" - وكم من الوقت تقضيه بالفعل في SO؟"ليس كثيرا." أتحقق من Stack Overflow عدة مرات في اليوم ، وعادةً ما أجيب على 1-3 أسئلة. وحصلت على غالبية الأصوات الإيجابية للإجابات التي تركت منذ سنوات. هذه هي الطريقة التي تساعد SO بها من جاءوا في وقت مبكر: كانوا أول من يجيب على الأسئلة قبل سنوات ، وتلقى الأصوات ، وأصوات تجعل هذه الإجابات أكثر وضوحًا ، وفي النهاية يحصلون على أصوات جديدة. هذا هو تأثير الانهيار تشجيع الإجابات القديمة.
يبدو لي أن هذا يسبب بعض المشاكل ، لأنه في بعض الأحيان توجد إجابات جديدة تشير إلى تقنيات أكثر حداثة وبالتالي فهي أفضل ، ولكن الإجابات القديمة لا يتم تحديثها. لكن ، بشكل عام ، أحصل على أغلبية الأصوات للإجابات القديمة ، لكنني ما زلت أحاول الإجابة على إجابة جديدة كل يوم. أنا لا أقضي الكثير من الوقت في هذا ، أنا فقط أفعل ذلك باستمرار لسنوات عديدة.
- عندما سافر جون سكاييت إلينا في DotNext ، سألناه عن الوضع الحالي لـ Stack Overflow وما يعتبره مشاكل في الموقع. من المثير للاهتمام مقارنة: ما رأيك في هذا؟"أعتقد أن SO يتحسن ، خاصة في العام الماضي." إنهم يحاولون الآن جاهدين تحسين جودة الأسئلة. غالبًا ما يكون الأشخاص الذين يسألون شيئًا ما على هذا الموقع غير معتادين على كيفية طرح الأسئلة الفنية بشكل صحيح.
وهذه مشكلة كانت موجودة دائمًا على الإنترنت. في التسعينيات ، عندما كان الجميع في مجموعات الأخبار ، كانت هناك أيضًا. بعد عشر سنوات ، حدث كل شيء في القوائم البريدية ومجموعات Google. الآن مورد جديد لأسئلة البرمجة Stack Overflow. ولكن كانت هناك دائمًا أسئلة حول البرمجة ، وطريقة طرح سؤال جيد كانت دائمًا مشكلة ، وكيفية الحفاظ على مجتمع ودود أيضًا. ربما لا يمكن حل هذه المشاكل بالكامل. أنا لا أقول أننا يجب ألا نعمل على هذا - بل يجب علينا بالتأكيد. لكن إذا نظرت إلى الماضي ، اتضح أنه حتى في التسعينيات ، كانت هناك دروس تعليمية مكتوبة بالفعل حول كيفية طرح الأسئلة الفنية.
هناك بعض المشكلات الجديدة في Stack Overflow. يمكنك أن تبدأ بحقيقة أن الكثيرين منهم لم يسألوا شخصًا آخر قبل طرح سؤالهم الأول. لذلك ، في كثير من الحالات ، فهم ببساطة لا يدركون كل تلك الأشياء التي يجب تقديمها في السؤال حتى يمكن الإجابة عليه.
ثم تخيل أنك تعمل في مهمة. كنت رأس على الكعب في رمز ، رأسك مليء كل هذا. وأنت تنظر إلى شيء محدد لا يفسح المجال بأي شكل من الأشكال. هذه تفاصيل ملموسة صغيرة لنظام كبير ، وعادة ما تسأل "كيف يمكنني أن أفعل هذا الشيء الصغير؟" دون أن تدرك أن لديك كل هذا السياق الذي تعرفه ، لكنك لم تضعه في السؤال. غالبًا ما يكون السؤال "كيف أجعل X" الإجابة الصحيحة هي "لا تفعل X ، افعل Y". هذا فخ يسقط عليه الناس غالبًا عند كتابة الأسئلة الأولى. إنهم لا يدركون أن إجابتهم بشكلها الحالي "لا تستجيب".
وإلى جانب مشكلة جودة الأسئلة ، هناك أيضًا ميل - وخاصة في Stack Overflow ، حيث يناضل الجميع للحصول على نقاط ، ويحاولون الإجابة في أسرع وقت ممكن - يغلق السؤال بسرعة أو يخربش بسرعة ليس أكثر الإجابات الممتعة. لا أقصد "حاقد" ، لقد رأيت عددًا قليلًا جدًا من التعليقات الحزينة بصراحة - بضع مرات فقط على مر السنين. بدلاً من ذلك ، فهي قاسية ، وبالنسبة لمؤلف السؤال ، تتم قراءة هذا على أنه غير ودي.
اتخذ Stack Overflow بعض الخطوات البسيطة لإصلاح ذلك. الآن ، عندما يسأل الناس أول سؤال ، يخبرك الموقع بما يجب تضمينه فيه. لقد أضافوا في السابق "انظر إلى هذه الأسئلة المشابهة" ، والتي كانت خطوة أولى جيدة. والآن هناك نظام كامل يحتاج إلى إكمال للسؤال الأول ، مما يساعد على تكوينه بشكل جيد.
يضيفون أيضًا تذكيرات لأولئك الذين يكتبون الإجابات. إنه مثل "هذا مبتدئ ، ودود" ، وهي طريقة جيدة لتذكيرك أن معظم الأشخاص لا يكتبون الأسئلة جيدًا في المرة الأولى ، وهذا طبيعي تمامًا. بشكل عام ، أنهم يعملون على ذلك. هل سيتم حل هذه المشكلة بالكامل؟ أنا أشك في ذلك. لكن التقدم ممكن.
اتواقت
- في منشور مخصص للذكرى العاشرة لـ iPhone ، تكتب أن مظهره قد أثر على البرمجة غير المتزامنة ، لأن تطبيقات الهاتف المحمول يجب أن تكون سريعة الاستجابة. وهل يمكنك إعطاء خلفية تاريخية عامة حول تطور عدم التزامن لأولئك الذين بدأوا في التطور مؤخرًا ولم يروا العالم دون التزامن / الانتظار؟- حسنا ، البرمجة غير المتزامنة كانت دائما ممكنة. أعتقد أنه في الستينيات من القرن الماضي كانوا يفعلون ذلك بالفعل. وكان لديه نفس المزايا لفترة طويلة: واجهة مستخدم أكثر استجابة وجزء خادم أكثر قابلية للتطوير. كان الدعم دائمًا يمثل مشكلة: كان من الصعب جدًا الحفاظ على التعليمات البرمجية غير المتزامنة. في البداية ، تم بناؤه على عمليات الاسترجاعات.
أعتقد أن الخطوة الكبيرة كانت ظهور الوعد. هذا ما أسموه في JavaScript ، وفي C # هو Task أو ValueTask. وكانت هذه خطوة كبيرة للأمام ، لأن لدينا الآن كائنًا يمثل العملية. يمكنك مراقبة تقدمه وما إلى ذلك. و async / تنتظر في أي لغة هو في الأساس مجرد السكر النحوي حول وعد.
أود أن أقول إن ظهور الوعد هو الحدث الذي كان له أكبر تأثير على الكود غير المتزامن. وفي حالة المزامنة / الانتظار ، من المهم أن يتم إنشاء جهاز الحالة لك. في الأيام الخوالي ، عندما عملنا مع عمليات الاسترجاعات ، كان علينا أن نصنع آلاتنا الخاصة. لقد كان الأمر دائمًا صعبًا لأنك نسيت حتماً بعض الشرط أو الانتقال ، ولم ينجح شيء. وكان من الصعب للغاية تصحيحه. لم يجلب التزامن / الانتظار القدرة على كتابة التعليمات البرمجية غير المتزامنة ، ولكن القدرة على كتابة التعليمات البرمجية التي يمكن دعمها.
- والآن هل ترى أن الوضع قد استقر ، أم أن التغييرات الجديدة ستنتظر منا قريبًا؟- أعتقد الآن أن كل شيء مستقر للغاية. يبدو التزامن / الانتظار ثوريًا - ولكن فقط لأولئك الذين لم يقوموا ببرمجة غير متزامنة من قبل. وبالنسبة لأولئك الذين عملوا ، شعرت أنها طبيعية للغاية. لكن ، بشكل عام ، كان هذا حدثًا كبيرًا.
والآن يأتي حدث آخر يأتي مع .NET Core 3. إنهم يفعلون ما يسميه الجميع تدفقات غير متزامنة ، على الرغم من أنها تعد في الواقع أعدادًا غير متزامنة. أعتقد أن هذا سيؤدي إلى إرباك الناس ، لأنه يوجد بالفعل نوع Stream لا علاقة له بالتيارات غير المتزامنة. بشكل عام ، سيكون هناك المزيد من التحسينات الإضافية. هل سنرى شيئًا ضخمًا كما هو الحال عند الإعلان عن المزامنة / الانتظار لأول مرة؟ لا أعتقد ذلك.
إذا كنت تريد نقلة نوعية جديدة ، فهناك دائمًا إمكانية وجود نظام قائم على الممثل. أو شيء من هذا القبيل goroutine ، حيث كل التزامن هو ضمني. في رأيي ، هذه الأشياء متشابهة إلى حد ما. المشكلة هي أنه في .NET ليس هذا سهل الإضافة. أعتقد أن هناك الكثير من القيود على .NET للقيام بذلك ، لذلك من غير المحتمل أن يحدث هذا. إذا رأينا انتقالًا واسع النطاق إلى عالم الممثلين أو عالم Goroutine ، حيث لن يكون نهج التوافق هو نفسه كما هو الحال في تعدد مؤشرات اليوم ، فإن هذا سيتطلب لغات وأوقات تشغيل جديدة تمامًا. و. NET لا يستحق الذهاب ل. ولا أعتقد أن البرمجة ككل ستأخذ قفزة كهذه. ربما أكون مخطئا ، لكن موقفي الحالي هو على النحو التالي.
- المزيد على السؤال عن مقدار كل شيء يتغير مع مرور الوقت. أصبحت العديد من كتب البرمجة قديمة بسرعة ، ولكن عندما تكون التغييرات أقل ، فإنها تستمر لفترة أطول. ماذا عن التزامن الخاص بك في C # Cookbook ، كم يتطلب الأمر تحديثات؟- سؤال جيد لقد نشرت مؤخرًا الإصدار الثاني ، وجاء الإصدار الأول في عام 2014. هذا هو ، لقد مرت خمس سنوات ، ونحن بالفعل في الطبعة الثانية - بالنسبة لي يبدو وكأنه تطور سريع.
أعتقد أنه لا يزال يعتمد على كيفية كتابة الكتاب. حاولت الكتابة حتى لا تصبح قديمة بأطول فترة ممكنة. عليك فقط ألا تحاول أن تشير إلى أشياء مثل Windows Phone 8. لكن سيصبح حتما متقادمًا على أي حال. تظهر تيارات غير متماثلة وما شابه ذلك ، وأردت تضمين هذه الأشياء في الكتاب. نتيجةً لذلك ، كان هناك شيء قديم ، لكن معظم المواد انتقلت إلى الإصدار الجديد بدون تغييرات.
وبالطبع ، كل هذا يتوقف على من هو الكتاب. بالطبع ، سينتهي كتاب استخدام Visual Studio 2008 بسرعة كبيرة. لكنني أعتقد أن هناك مكانًا للكلاسيكيات الأصلية. أنا أعتبر Code Complete واحدًا من أفضل كتب البرمجة في العالم. والى متى كانت مكتوبة؟ أنا لا أعرف حتى. عقود مضت. وهذا لا يزال كتاب رائع! شيء ما قديم ، لكنه بشكل عام لا يزال رائعًا.
- في الآونة الأخيرة ، كانت هناك تعديلات حول التزامن / تنتظر على Twitter ، والتي بدأت بتغريدة من Vaughn Vernon ، مؤلف العديد من الكتب على DTD ونماذج الممثلين:
إنه لا يحب المزامنة / في انتظار الاستيراد - في رأيه ، هذا ينتشر عبر الكود ويمكن أن يؤدي إلى حظر الخيط. ما رأيك في هذا؟ هل كان يستحق كل هذا العناء تصميم شيء آخر؟
- نعم ، ربما حقيقة أن ينتشر / تنتشر حول المشروع هو الشكوى الأكثر شيوعا. أود أن أذكر بعض الأشياء هنا.
أولاً ، تتطلب التعليمات البرمجية غير المتزامنة ، من أجل أن تكون غير متزامن حقًا ، عدم التزامن من كل من يطلق عليه. ولا يرحل. أيا كان النموذج الذي تستخدمه (حتى واحدة من القديمة) ، في النهاية واجهت فيه. لقد تلقيت تقريرًا عن الوقت الذي ذهبت فيه من خلال جميع النماذج وأظهر كيف أصبحت الشفرة أنظف وأفضل.
هناك طريقتان مختلفتان لتفادي الهيمنة الواسعة للالزمن / الانتظار. الأول هو عزل جميع المدخلات / المخرجات في كائنات منفصلة. يمكنك استخدام أنماط التصميم مثل الموانئ والمحولات: يتيح لك ذلك احتواء جميع I / O خارج منطق عملك ، ومن ثم لن يتطلب ذلك أي التزامن / الانتظار على الإطلاق. , «async », , - /. .
async/await, .NET. -, Go . , — async/await. async/await , .
. async/await - ( , ) , -: , .
— , (, , ). , programming concurrency?— , . . race condition, , .
, . . , , . . .
, , . eventual consistency. , , . : , .
— , TypeScript. , C# .NET? -, C#?— . C# . , — Python. . Python, , . enumerator blocks, C# Python. Python , Async streams, , C# .
. , Python, JavaScript TypeScript. JavaScript - . , Reactive Extensions, , .NET . JavaScript Rx .
— — DotNext. Asynchronous streams — .NET-, ?— , asyncronous streams: , . , . , async streams, , , async streams, .
— . — DotNext?— , , , . , : , .
, , , . - async streams , , , . , DotNext.
DotNext 2019 Moscow 6-7 . , — .