هذا هو الجزء الأخير من التحقيق في حركة سكالا في روسيا. في
الجزء الأول ، تعلمت من
رومان جريبينيكوف عن فورونيج بو موندي ، سي ++
وإرلانج ، ومن
رومان تيموشيف عن أول عكا وولادة اجتماعات موسكو. في
الجزء الثاني ، تحدثت مع
ألكساندر بودكالوزين وميخائيل موتسيانكو : التعرف على سكالا ، 2007 ، سكالا دايز ، سكالا
ناتيف ، والانتقال إلى كوتلين ، أفضل من سكالا للبنوك ، الأحداث الأولى في سان بطرسبرغ ، إيكليبس ، جاسون زوغ ، آي دي إي و سكالا المساعد.
أثناء التحضير للجزء الثاني ،
وجهني فلاديمير أوسبينسكي (
vuspenskiy ) إلى
ألكسندر بودكاليزين ، الذي سجلنا معه مقابلة ضخمة. في اليوم التالي تلقيت رسالة من فلاديمير ، لكن الآن مع سجله الشخصي: Qiwi ، Scala in Tinkoff ، الاجتماعات الأولى ، روابط إلى المدونات القديمة (شكر خاص لهذا) ، والوظيفية من عام 2008 من Rúnar ، والتي تعمل في Java ، - هذا
لا يزال دم من العينين ، على الأقل غير عادي. بالإضافة إلى ذلك - قصص
رومان إليزاروف ،
أليكسي فومكين ونيكولاي تاتارينوف . ميزات التعاقد مع مطوري Scala ، دورات تدريبية حول Coursera ، "رمز مثالي" ، تجميع "شيطاني" ، تصميم في Kotlin ، 10000 سطر من التعليمات البرمجية ، Tinkoff للخدمات المصرفية عبر الإنترنت ، مرة أخرى Tinkoff ، Play Framework ، توفي Flash و "Sunrise" و اجتماعات St. Petersburg - حول كل هذا في الجزء الأخير من ثلاثية تحت الخفض.
فلاديمير أوسبنسكي: كورسيرا ، تينكوف وميزات توظيف سكالا
فلاديمير : في ذلك الوقت كنت أعمل في Qiwi وأعيد تشكيل الكثير من أكواد جافا ، لكنني لا زلت أحصل على الكثير من الماء والمراجل. لقد تعذبت ، لكنني تذللت بطريقة ما.
بعد مرور بعض الوقت ، ذهبت إلى
مدونتي ألكساندر تيمرييف وفلاد باتريشيف . كان فلاد في الطليعة في تنفيذ جافا ، كما أفهمها. قرأت عن سكالا معهم ، بدأت تلاحظ إشعارات الإنشاءات الغريبة بالنسبة لي ، مثل
الخيارات في جافا . لقد أطلقت هذا الخيار حتى في مكان ما في الإنتاج. كان هناك المزيد من
الأخطاء الغريبة
في التعامل مع الأخطاء عند استخدام Java و
High -Order Parallelism لـ
Rúnar Bjarnason . كل هذا فجر بفرح الدماغ وتساءل عن كيفية تطبيق كل شيء.
عندما درست أمثلة محددة ، على سبيل المثال ، من
Daniel Spiewak :
Scala for Java Refugees ، كان هذا بالضبط ما كنت
أفتقده .
`_` vs `*` vs `?` كل المياه والتناقضات الغريبة مثل
`_` vs `*` vs `?` من كود Java ، ويبقى الجوهر.
كان سكالا 2.7 ، وبعبارة خفيفة ، لم يكن مستقراً. لقد جربت العديد من المشاريع اختبارات الوحدة أو فئات الحالات. لإضافة Scala إلى مشروع Java ، كان عليك تكوين ترجمة
مشتركة في Maven . لكنني قررت أن أحاول وأضفت الدعم لمشروع غير حاسم في Qiwi. كل شيء كان ناجحًا - كنت سعيدًا جدًا ، ولكن هذا هو المكان الذي انتهى فيه الأمر.
العمل في تطبيق Tinkoff و Scala
فجأة ، دعيت إلى Tinkoff لقيادة تطوير بنك إنترنت جديد ، تم تطويره بالكامل داخل الشركة. في البداية ، اكتشفت المهام الحالية ، لكن عندما وصلت إلى الواجهة الخلفية ، أدركت أن الوقت قد حان لتطبيق Scala.
خرج للتو سكالا 2.9 مع الحديث ، في ذلك الوقت ، بناء الجملة. كانت المجموعات المتوازية العصرية مناسبة تمامًا لتشغيل شيء ما بسرعة متوازية ، إذا لم تكن التفاصيل مهمة. نعم ،
وأصدر مؤلف Groovy
James Strachan : "يمكنني أن أقول بصدق ما إذا كان شخص قد عرض علي كتاب Scala Programming لـ Martin Odersky و Lex Spoon & Bill Venners مرة أخرى في عام 2003 ، من المحتمل أنني لم أقم بإنشاء Groovy أبدًا".
عامل آخر في اختيار Scala هو أن جميع الأشخاص الذين عملوا بعد ذلك على الأدوات أو اللغة أو المكتبات أو كتبوا عن Scala كانوا أذكياء وحيويين للغاية. لذلك ، كان هناك ثقة في أن هذا هو الخيار الصحيح للمستقبل.
فقط أثناء العمل في البنك ، بدأت في الذهاب إلى المؤتمرات الأجنبية. أول
أيام Scala في عام 2012 ، و flatMap العبقري غريب الأطوار في أوسلو. في ذلك الوقت التقيت
Zhenya Burmako . الآن نحن في بعض الأحيان نزهة على طول المحيط بالفعل هنا في ولاية كاليفورنيا.
التعاقد مع المطورين سكالا
كتب تدريجيا بنك على الانترنت. في عام 2012 ، أصبح الأفضل في روسيا وفقًا لشركة
Global Finance . بالنسبة لي ، هذا تأكيد على عبارة "افعلها بشكل طبيعي ، ستكون طبيعية" ، وليس شيئًا غير عادي.
روج
أوليغ تينكوف لموضوع البنك ، الذي كان مضحكا. ربما ساعدنا ذلك في توظيف مطورين جيدين - كان الناس في الفريق ، لكنني أردت التوسع. أولاً ، كتبنا في المنصب الشاغر "مبرمج جافا ، سكالا - زائد". لكن ذكر Java في وظائف لمطوري Scala يمنع الأشخاص الذين لا يريدون أن يكون لهم أي علاقة بـ Java. لذلك ، قمنا بتغيير الوظيفة الشاغرة إلى Scala Senior Developer. هذا سمح لي بتوظيف اثنين من اللاعبين الذين أود كثيرا أن أعمل معهم يوما ما.
مجموعة الفيسبوك
أردت أن أفهم من كان ، عمومًا في روسيا وموسكو ، مهتمًا بشكل مستقل بـ Scala ، وأي نوع من الأفكار كان لدى المجتمع. لم تكن هناك اجتماعات أو محادثات ، وكانت الفكرة هي جمع الجميع. لقد أنشأ
مجموعة على Facebook ، حيث خططنا للاجتماعات القليلة الأولى. ما هو الاجتماع بدون مجموعة في
Meetup ؟ ذهبت لإنشاء ، ولكن المجموعة موجودة بالفعل - تم إنشاء
رومان تيموشيف . قررنا توحيد الجهود ،
وأضفنا ميشا أكسارين .
تم جمع الاجتماع الأول بحجة دورة سكالا حول
البرمجة التفاعلية على كورسيرا . أطل الكثيرون ، ولكن جاء حوالي 20 شخصًا: التقوا ، وأخبروا من كانوا يفعلون ، وكانوا مهتمين ، وناقشوا التدريبات من الدورة واتفقوا على الاجتماع مجددًا.
لذلك بدأت.
رومان إليزاروف: ١٠٠٠٠ خط على سكالا والكمالية والتجميع بلا رحمة
شارك رومان إليزاروف ( إليزاروف ) - زعيم مجموعة JetBrains ، في العمل على coroutines والمكتبات في Kotlin.ملاحظة المؤلف . قبل تسجيل المقابلة ، اعتقدت أنها ستكون كارثة إذا أخذتها فقط من الأشخاص المشاركين في Scala. "العشق" المستمر أو الأسوأ "خطأ الناجين". لذلك ، قررت أن أضيف بالتأكيد ذبابة في المرهم.
هذا الأمر أكثر صعوبة - الأشخاص ذوو الخبرة الحقيقية والذين لم يدخلوا اللغة لسبب ما هم أقل من حجم الكارهين ذوي الخبرة الصفرية في Scala. ولكن بعد ذلك تذكرت
منصب رومان إليزاروف (
إليزاروف ) - زعيم مجموعة JetBrains - حيث خربش على سكالا بين الحالات ، والتي تسببت في حدوث حروق متعددة ، بما في ذلك حالاتي. على الرغم من السلبية ، فمن غير المرجح أن رومان كتب مقالاً عن بعض الشائعات حول اللغة. يجب أن يكون هناك سبب ، من نوع من تجربة سلبية من الاستخدام - اتضح بهذه الطريقة. أدناه المقابلة معه تدور حول هذا الموضوع ، وبعض المناقشات حول تصميم واتصال coroutine مع Scala CPS Plugin.
القضية في عام 2010
رومان إليزاروف : في حوالي عام 2000 ، قمت ببرمجة جميع أنواع الترفيه في جاوة. لذلك ، تابعت لغات JVM ، بما في ذلك Scala. يبدو أن أول مرة أقرأ فيها عن اللغة في الفترة 2005-2006.
عندما تقرأ بشكل تجريدي ، يكون بناء الجملة رائعًا. أتذكر قراءة الوصف ، والتجول ، وأحببت حقًا كل شيء. من السهل القيام بالعديد من الأشياء في Java المفصلة والتي يصعب التعامل معها في Scala. كل هذا اهتم بي بالفعل ، ليس من وجهة نظر FP ، ولكن من الناحية العملية - ونحن نكتب الكود. ولكن نظرًا لأن قاعدة Java codebase كبيرة بالفعل ، وهي مجموعة من الفئات الحالية ، لم يكن من الممكن استخدامها في الممارسة العملية حتى حدثت القصة في عام 2010.
في عام 2010 ، شعر شركاؤنا من الولايات المتحدة ، من المؤسسة ، بالملل. أرادوا الجدة ، وكتبوا نظامًا فرعيًا جديدًا بالكامل على سكالا. كان لديه نوع من واجهة الويب ، كان يفعل شيئًا بسيطًا. في الوقت نفسه ، ليست هذه هي "إطار عمل Play" - إنها مجرد خدمة ويب تتلقى طلبات من المستخدمين ، تسمى Java API. موقع ويب عادي لأداء نوع من الوظائف التفاعلية الداخلية. قام الشركاء بتصحيحه بنجاح ، كل شيء على ما يرام.
في ذلك الوقت كنا متعاقديهم. لقد لعب مطورو النظام الفرعي ما يكفي وقرروا القيام بأشياء أخرى. زبائننا يأتون إلينا ويقولون: "يا شباب ، خذوا هذا الشيء للحصول على الدعم؟ إنها تستخدم API الخاص بك على أي حال. " عظيم ، هنا - طريقة حقيقية لمحاولة مع Scala. لذلك لا أحد يسمح لنا بالبرمجة في سكالا ، لأن كل شيء صعب ، ولكن نظرًا لوجود مشروع بالفعل ، هذا هو السبب. هذه ، في الواقع ، أول تجربة إنتاج مع Scala.
الانطباع الأول عن Scala هو مدى ضغط الكود في Java . Scala يتيح لك كتابة الأشياء المعقدة بشكل مضغوط. استغرق النظام الفرعي ما يقرب من 10000 سطر من التعليمات البرمجية ، ولكن في Java سيستغرق الأمر ضعف المقدار بسبب الفئات. بناء الجملة ، وجميع الكائنات الداخلية لنقل البيانات ، وحتى التكيف الكامل لواجهة برمجة تطبيقات Java كلها مضغوطة.
أول وآخر 10،000 خطوط على سكالا
عندما غادر المطورون ، تركوا الكود مفككًا - بمعنى أنه كان
مجرد كود . حاولنا أخذها للحصول على الدعم ، ولكن كانت هناك مشكلة - التجميع.
ترجمة رمز Scala هو السعي. التعليمات البرمجية يجمع فقط مع إصدار محدد من Scala Compiler - دقيقة لإصدار نقطة ، إلى إصدار التصحيح.
لم يعد يتم تجميع إصدار أكبر أو أصغر .
هذا قرر بالنسبة لي في عام 2010 مصير Scala في المؤسسة ، حيث يوجد ملايين الأسطر من التعليمات البرمجية. من المخيف تخيل كيفية العيش إذا قمت بتغيير الإصدار الفرعي من المترجم ولن تقوم بذلك.
"أنت لن تتذكر بالضبط لماذا؟"رومان إليزاروف : لماذا تفكك الأمر ، لا أتذكره بالطبع. كان هناك شيء يتغير باستمرار من نسخة إلى أخرى. ربما كنا في الوقت الخطأ؟
لكنني واصلت مراقبة تطور سكالا ، على الرغم من حقيقة أننا فقط في الشركة لم ننفذ هذا. نتيجة لذلك ، تم نقل الوظيفة إلى تطبيقات Java الأخرى. في هذا Scala في هذه الشركة لم تعد موجودة.
وكانت هذه الخطوط 10000 الأولى والوحيدة. عملت الشفرة لفترة طويلة في الإنتاج ، ولكن بعد ذلك تم تحليلها بواسطة خدمات أخرى وتم إزالتها.
على وجه التحديد لنشاطي المهني ، تركت هذه التجربة علامة لا تمحى ، بمعنى أنه مع ذلك ، هناك حاجة إلى توافق كل هذا. الآن أنا أفعل Kotlin. ليس من المستغرب أننا ببساطة نقضي قدراً غير واقعي من الوقت وقوات إضافية لضمان توافق كل شيء وكل شيء. في بعض الأحيان ، لا يندرج مقدار كبير من الوقت في الوظائف ، ولكن ببساطة أن كل شيء متوافق. على وجه الخصوص ، تجربتي السابقة تؤثر على هذا.
لا تزال تتذكر باستمرار بيثون. فيما يتعلق بالتوافق ، لدينا خطأان: Scala و Python. عندما يتعلق الأمر بالتوافق ، لا أحد يريد تكرار الانتقال من 2 إلى 3 Python ، ولا يريد أحد أن يكون مثل Scala.
"كود مثالي"
- غالبًا ما تريد إعادة شيء ما بحيث يكون كل شيء "شوكولاتة"؟رومان إليزاروف : أنا منخرط في التصميم
وأريد دائمًا إعادة كل شيء . أنا لا أحب ما فعلت. أثناء إعداد شيء ما للإصدار ، أجد بعض الأشياء التي أريد تغييرها. حالما لم أفرج عن شيء ، أرى عيوبه بالفعل: لم يكتمل بعد ، وهنا يتعين علينا إعادة كتابته من البداية. ولكن هذا هو الطريق إلى أي مكان. هناك طريقتان فقط: إما أن أقوم بتحسين الشفرة إلى أجل غير مسمى ولن أصل إلى الإصدار مطلقًا ، أو سأطلق الإصدار وسيصبح Legacy.
لا يمكنك إصدار الكود المثالي .
ثم أقضي نصف الوقت في تحسين المنتج ، والثاني في التوافق مع ما قمت بإصداره بالفعل. تساعد التجربة على "وضع القش" مقدمًا. أرى أنه سيتعين عليَّ إعادة ذلك قريبًا ، وقضاء وقت طويل في إصداره على شبكة الأمان تحسباً للتغييرات المستقبلية. بالطبع ، القيام بشيء ما من نقطة الصفر وعدم القلق بشأن التوافق أسهل بكثير. لكن الحل الوسط هو أنك إما تقوم بذلك بشكل مثالي ، أو أنها تستخدم المنتج الخاص بك. واحد يستبعد الآخر.
التصميم في Kotlin
رومان إليزاروف : كنت أتابع سكالا باستمرار ، لأنه عندما نقوم بتصميم شيء ما في كوتلين ، ندرس اللغات الأخرى ، بما في ذلك سكالا. منذ حوالي عامين ، صممنا corotines Kotlin. "الإلهام" الرئيسي هو ، بالطبع ، C #. بدأ كل شيء معه ومن هناك وُلد بالفعل. ثم بدأنا في دراسة الذهاب.
عندما بدأ التصميم في الانحراف عن C # وظهرت "استمرارات" ، ثم "محددات مستمرة" ، بدأنا في دراسة لغات أخرى مرة أخرى. في Google ، أنا أتعثر على سكالا - اتضح أنه كانت هناك بالفعل "
إستمرارات محددة ".
- هل تتحدث عن البرنامج المساعد مترجم؟رومان إليزاروف : نعم. في الوقت نفسه ، كان التصميم مشابهًا تمامًا للتصميم الموجود الآن في Kotlin. هناك ، بالطبع ، اختلاف في النص: في Kotlin نكتب معدل التوقف المرحلي في البداية ، وفي Scala كتبت الشرح
csp على القيمة المرجعة. ولكن ما الفرق بين وضع المُعدل: في نوع قيم الإرجاع أو في البداية؟
كان التصميم في Scala مشابهًا جدًا للوضع الحالي في Kotlin. أصبحت مهتمة - كيف يتم ذلك ، لأن هذا التصميم الرائع ، لماذا لم يطير؟ لماذا لا يكتب أي شخص هكذا في سكالا الحديثة؟ أظهروا لي كيف يكتبون في Play Framework - لا يوجد مكون إضافي هناك.
الجميع يكتب العقود الآجلة ، وكان لدينا فكرة رائعة للتخلص من العقود الآجلة ، لأن هذا التصميم هو أكثر ملاءمة. وحدث ذلك في كوتلين: ليست هناك حاجة للعقود الآجلة ، هناك فروع. في سكالا ، تخلوا عن "الاستمراريات" ولم يطيروا. لماذا؟
بلا معنى ولا رحمة للتجميع
في عملية البحث ، وجدت
الإعلان الأكثر الأصلي. في تلك السنة ، ظهرت "استمرار محدد" في سكالا. في سكالا ، كل شيء تم فعل الشيء نفسه كما هو الحال الآن في Kotlin.
الإعلان بهذا المعنى يدل. قال: "لقد فعلنا" استمرارية محددة "، انظر ، يمكننا كتابة نفس الأشياء الرائعة كما هو الحال في Lisp." على سبيل المثال ، أخذنا مثالًا على Lisp من أعمال الثمانينات والتسعينات ، وأعدنا كتابته على Scala: القوائم موصولة ، هنا "shift / reset". في Lisp واللغات المماثلة ، هناك بنية
للاستمرارات المحددة ، والتي تم تحديدها على أنها "shift / reset". اسم ينفجر الدماغ - لا أحد يعرف ما هو التحول / إعادة تعيين. لا أحد درس ليسب ولا أحد لم يلتق به قط.
الشيء الرئيسي في هذا الإعلان هو تعليقات مثل هذا: "هذا الأمر لا معنى له. لقد قضيت بعض الوقت في ويكيبيديا بالإضافة إلى بعض الأماكن الأخرى لمحاولة فهم ذلك. من وجهة نظري ، هذه طرق معقدة لإضافة أرقام وليس لدي أي فكرة عما تم تحقيقه أو إنجازه. " يشرحون جوهر هذا المنصب.
لذلك ، مثل هذا الإعلان عن ميزة مهمة لا طائل منه على الإطلاق. إذا قرأها شخص يكتب رمز التطبيق ، فلن يتلقى إجابة على السؤال: "لماذا أحتاج إلى هذا على الإطلاق؟ ما المشكلة التي ستحلها؟ "لم يثر المؤلف مثل هذا السؤال.
لذلك ، لم تطير الميزة - ليس لأنها كانت سيئة ، ولكن لأنه لم تكن هناك مهمة تطير إليها .
"هل أسيء استخدامها؟"رومان إليزاروف : نعم ، لقد رفعوها خطأ. كان الأمر كما لو كان معلنًا ، لكنهم لم يوضحوا سبب الحاجة إليه والمشكلات التي يمكن أن يحلها. لكن المسألة ليست "الصواب" أو الجمال. بالمناسبة ، نحن في Kotlin لا نعرف أيضًا كيفية كتابة مشاركات المدونة الجميلة ، لكن كتابة منشور مناسب لا يكفي لكتابة إعلان جميل.
العرض التقديمي الصحيح ليس تفسيرًا للسبب ، بل هو تفسير من وجهة نظر واجهة برمجة التطبيقات .
قرأت الرمز ، وهناك طرق التحول / إعادة تعيين تستخدم. لماذا كان يسمى التحول / إعادة تعيين في 70s؟ حاولت أن أجد مؤلف الاسم من الماضي ، لكن لم أستطع. فقط جاء شخص بهذا الاسم. إلى مبرمج حديث ، هذه الكلمات لا تقول أي شيء على الإطلاق. لا تعني شيئًا.
إنني أتعامل مع كوريوتيني لدرجة أنني يجب أن أعرف كل شيء عنها ، لأنني قرأت مجموعة من الأوراق العلمية. لكن عندما أرى الرمز الذي يستخدم "shift / reset" ، فإنني أضغط في كل مرة لفهم ما يحدث هناك ولماذا هناك حاجة على الإطلاق. يبدو وكأنه نوع من السحر الأسود ، في حين لا معنى له.
أليكسي فومكين: فلاش المتوفى ، فوشخود وأول اجتماعات موسكو
أليكسي فومكين ( يلبوتا ) - مبرمج ، متحدث ، بودكاست ، مساهم مفتوح المصدر ، سكالا متحمس.ملاحظة المؤلف . بعد التراجع عن شؤون
تيموشيف وأوسبينسكي ،
استقرت الحركة برمتها في موسكو على
أليكسي فومكين . بالإضافة إلى ذلك ، أطلق البودكاست
Scalalaz ، ونظر في البودكاست الأخرى:
DevZen ،
Debriefing ،
Remote Talk . سيكون تخطيه في هذه السلسلة من المقالات خطأً كبيرًا.
من عملك إلى مطور سكالا
أليكسي فومكين : من المحتمل أن أشعر بالملل الشديد - لم يكن هناك شيء مثير للاهتمام. لدي قصتي الشخصية. إنه أمر مثير للاهتمام بالنسبة لي ، لكن بالنسبة للقراء قد يكون الأمر مملًا.
في الواقع ، شاركت في Action-Script ، وفي وقت لاحق كان لديّ نشاط تجاري صغير خاص بي. عندما أغلقت الشركة ، بقيت بدون أي شيء ، لأن فلاش قد توفي في ذلك الوقت. وفقا لذلك ، لم يكن هناك شيء آخر في سيرتي الذاتية. كنت أبحث عن عمل ، كنت مكتئبًا لأنني فقدت كل شيء.
لم أر نفسي كمدير فني ، ولا حتى قائد فريق. بعد فشل مع شركته ، كان هناك طموح فقط للمبرمج العادي. حاولت الحصول على مطور JS في ياندكس. لكنهم رفضوا لي لأنني لا أعرفه جيدًا - وهذا صحيح بالطبع.
ثم فكرت في سكالا. لقد جربتها عدة مرات ، بدءًا من عام 2010 - أحب اللغة. جربت ذلك لأنه في المكتب الذي عملت فيه في عام 2010 ، كان هناك Oaml. أردت ، مثل OCaml ، أن أحصل على JVM - أعجبتني. على الجانب الآخر ، كتبت عدة مشاريع على Scala ، وفي عام 2014 بدأت التقدم بطلب في شركتي.
كانت هناك فكرة للتحرك نحو Scala: هناك العديد من العروض ، والعديد من المشاريع ، والمطورين غير متاحين. ثم توترت في غضون بضعة أشهر وانسحبت وتحديث كل ما عندي من المعرفة. كنت محظوظًا - حصلت على مدير فني وكتبت فريق Scala.
Voskhod ، سكايب الدردشة وتنظيم الاجتماعات الأولى
في الوقت نفسه ، اعتقدت أنه يتعين علينا محاولة إثارة بعض الأشياء ، حتى لا يتم تطوير الموضوع في روسيا. تحدث مع
أوسبنسكي وتيموشيف وعسكرين . اتضح أن Askarin ترك وحده - Uspensky كان "على الحقائب". تحدثت عن القيام Meetup أم لا. "نعم نحن". وكان هذا هو mitap الأخير الذي رتبه الفريق القديم. كان ذلك في بعض المؤسسات الحكومية ، معهد الأبحاث "فوسخود" ، حيث ذهبت إلى هناك ، وأخبرت عن سكالا JS أو شيء ما ، ثم تلاشى هذا الموضوع تمامًا. نظرًا لأن كل شيء سيء للغاية وليس هناك أي نشاط ، فقد قررت تنظيم كل شيء بنفسي - لقد بدأت أن أصبح نشطًا في محادثة Skype ، حيث كانت موسيقى الروك معلقة.
- كم من الناس كانوا هناك؟أليكسي فومكين : لا أتذكر - لا يوجد الكثير منهم في الدردشة الحديثة. العمود الفقري الرئيسي هو 10-50 شخصا يتحدثون باستمرار. البقية تأتي ، اذهب ، اطرح أسئلة - تمامًا مثل الآن.
لقد كان عام 2015: Skype chat ، Scala.js ، أول لقاءات مع الشركة التي عمل فيها. استخدمنا Scala بقوة ، وقمت بترقية Scala.js. ذهبت إلى جميع أنواع مطوري JS ، في البودكاست ، وتحدثت عن Scala.js ودعا ميتوب.
في عام 2016 ، بدأنا البث. ألقيت صرخة وأجبت على الكثير من الناس. من حيث المبدأ ، ما زال جميعهم تقريبا ، باستثناء
تارانينكو . ثم
انضم غريغوري بومادشين وأوليا ماخاسيفا .
- هل ساعد أي شخص مع mitaps؟ لقد شعرت بالضيق عندما غادرت - كما لو أن كل شيء قد مات.أليكسي فومكين :
ساعد داخل الشركة ماكس بافلوف. إنه يعرف كيفية البرمجة ، ولكن المزيد من المدير. عملت على التقارير وساعد قسم Scala وماكس في التنظيم: المباني والمعدات والتسجيل.
تم رعاية كل شيء بواسطة
Data Monsters ، المعروف أيضًا باسم Flexis ، المعروف أيضًا باسم Adi Sait - أسماء مختلفة في أوقات مختلفة. كنت أعمل هناك بعد ذلك. ميتوب آخر قضيت في عام 2018. كان وحده.
نيكولاي تاتارينوف: إطار عمل اللعب ، الدورة الأولى وفرع سان بطرسبرغ
نيكولاي تاتارينوف هو مطور في SoundCloud ، منظم سابق لـ SPb Scala Meetup.ملاحظة المؤلف . الآن عن
فرع سانت بطرسبرغ من mitaps. على الرغم من أنها بدأت منذ وقت ليس ببعيد ، فقد وقعت بالفعل 9 أحداث. من حيث جودة الأداء ، فقد رفعوا إلى حد كبير الشريط:
قناتهم على YouTube ، البث المباشر.
أحد المنظمين هو
نيكولاي تاتارينوف . رغم أنه الآن تقاعد بالفعل بسبب النقل ، لكنني أتيت إليه مع أسئلة قياسية. تحدث نيكولاي عن الدخول إلى اللغة ، والحركة ، التي أثرت بشكل طفيف على وضع Play Framework قبل الإصدار 2.0 ومصير
رسائل الممثل .
لعب الإطار
نيكولاي تاتارينوف : في أول وظيفة لي في عام 2012 ، استخدمنا إطار عمل Play الأول. تم صنعه في شكل القضبان. لقد كان مثيرا للاهتمام لأنه كان لدينا تطبيق سهل فيه إجراء التغييرات. لكنها كانت في حالة نموذج أولي - لم تتطور إلى نوع من نظام الإنتاج. كان كل شيء مختلطًا هناك - وتم تطويره.
كان أول إطار للعب هو Java و Groovy. , - — - Python-. , Maven Sbt. —
Play Framework Play Framework .
, Play Framework , . — , « ».
Play Framework, , Scala, , — . - Play — . , — , . , . Play Framework , . , .
C Play Framework . , - , Scala . .
2013 — «
Secon »,
. , — , - . , Scala. - , Scala Coursera.
Coursera
«
Scala ». , , . , — , , . , , Scala .
Guava 7- Java. : . . , , , .
Scala
: 2014 . , , - Scala. 2015 ,
Actor . ,
Dialog , .
— Dialog Actor?: . , Actor, Dialog. , Actor. , , .
, Actor, . Scala — . , Scala, - , — .
- Scala , —
, . - , . , , .
, , . , , Java . — , . , - , . Scala.
, , Scala. SoundCloud. Scala.
: .
IT Global Meetup — IT-, 2-3 . . —
FProg Spb . : , , , , Coq.
. , Clojure, , — , Coq, , . .
, Scala. IT Global Meetup . , «Java Scala». , . , . , eLama, - , , Scala.
, Scala-, 50. Scala, .
2016 . , , . Slick, ,
Vodka .
Scala- 2017.
, , , . , . . eLama" — .
Meetup DINS. , . — . , Meetup . , , 60-70 — . - .
. . , - . , -
Excelsior JET, .
, , .
PartialFunction .« » —
eax.me , , Scala 2013 . , ,
.
ScalaConf 2019 — (15 ) . Scala 26 . , « Hskell», — , Scala. ScalaConf 2019. .