रूसी स्काला आंदोलन के नक्शेकदम पर। भाग 3

यह रूस में स्काला आंदोलन की जांच का अंतिम हिस्सा है। पहले भाग में, मैंने रोमन ग्रीबेनिकोव से वोरोनज़ो ब्यू मोंडे, सी ++ और एर्लैंग के बारे में सीखा , और रोमन टिमुशेव से पहले अक्का और मास्को बैठकों के जन्म के बारे में जाना। दूसरे भाग में, मैंने अलेक्जेंडर पोडखलुज़िन और मिखाइल मुत्सयानको के साथ बात की: स्काला, 2007, स्काला डेज़, स्काला नेटिव, कोटलिन से जाना, स्कैला की तुलना में, बैंकों के लिए अच्छा है, सेंट पीटर्सबर्ग, एक्लिप्स, जेसन जॉगग, आईडीई और स्काला में पहली घटना। प्लगइन।



दूसरे भाग की तैयारी के दौरान, व्लादिमीर उसपेन्स्की ( vuspenskiy ) ने मुझे अलेक्जेंडर पोडाक्लाइज़ुइन को निर्देशित किया, जिसके साथ हमने एक विशाल साक्षात्कार रिकॉर्ड किया। अगले दिन मुझे व्लादिमीर से एक संदेश मिला, लेकिन अब उनके व्यक्तिगत इतिहास के साथ: टिंकीऑफ में किवी, स्काला, पहली बैठक, पुराने ब्लॉग के लिंक (इसके लिए विशेष धन्यवाद), और 2008 में रूनेर से जावा में चलने वाला कार्यवाद, - यह अभी भी आंखों से खून है, कम से कम असामान्य है। इसके अलावा - रोमन एलिसैरोव , अलेक्सी फोमकिन और निकोलाई तातारिनोव की कहानियां। स्काला डेवलपर्स, कोरेसेरा, "सही कोड", "राक्षसी" संकलन, कोटलिन में डिजाइन, कोड की 10,000 लाइनें, टिंकॉफ इंटरनेट बैंकिंग, टिंकफ, प्ले फ्रेमवर्क, फिर से फ्लैश, "सनराइज" और सेंट पीटर्सबर्ग की बैठकों में शामिल हैं। कटौती के तहत त्रयी के अंतिम भाग में यह सब।

व्लादिमीर उसपेन्स्की: कोर्टेरा, टिंकॉफ और स्काला के लिए हायरिंग सुविधाएँ

व्लादिमीर : उस समय मैंने किवी में काम किया था और बहुत सारे जावा कोड को निष्क्रिय कर दिया था, लेकिन फिर भी मुझे बहुत पानी और बॉयलरप्लेट मिला। मुझे तड़पाया गया, लेकिन किसी तरह खुद को सँभाला।

कुछ समय बाद, मैं अलेक्जेंडर टेमेरेव और व्लाद पैट्रीशेव के ब्लॉग पर गया। जावा के कार्यान्वयन में व्लाद सबसे आगे था, जैसा कि मैं इसे समझता हूं। मैंने उनके साथ स्काला के बारे में पढ़ा, मेरे लिए अजीब तरह के निर्माणों का उल्लेख करना शुरू किया, जैसे कि जावा में विकल्प । मैंने इस विकल्प को उत्पादन में भी कहीं लॉन्च किया। जावा में अधिक विदेशी आलसी त्रुटि हैंडलिंग और रुनार बजरसन से उच्च-क्रम जावा समानांतरवाद थे। यह सब नारकीय रूप से दिमाग को उड़ा देता है और सोच रहा था कि यह सब कैसे लागू किया जाए।

जब मैंने विशिष्ट उदाहरणों का अध्ययन किया, उदाहरण के लिए, डैनियल स्पाइवाक : जावा रिफ्यूजी के लिए स्काला , तो यह वही था जो मुझे याद आ रहा था। जावा कोड से सभी पानी और अजीब विसंगतियां `_` vs `*` vs `?` हैं, और सार बना रहता है।

यह स्कैला 2.7 था और, इसे हल्के ढंग से रखने के लिए, यह स्थिर नहीं था। कई प्रोजेक्ट्स ने इसे यूनिट टेस्ट या केस क्लासेस के लिए आज़माया है। जावा प्रोजेक्ट में स्केल जोड़ने के लिए, आपको मावेन में संयुक्त संकलन को कॉन्फ़िगर करना होगा। लेकिन मैंने कोशिश की और किवी में एक गैर-महत्वपूर्ण परियोजना के लिए समर्थन जोड़ा। सब कुछ काम किया - मैं बहुत खुश था, लेकिन यह वह जगह थी जहां यह समाप्त हो गया।

टिंकॉफ और स्काला कार्यान्वयन पर काम करें

अचानक, मुझे एक नए इंटरनेट बैंक के विकास का नेतृत्व करने के लिए टिंकॉफ के लिए आमंत्रित किया गया था, जो कंपनी के भीतर पूरी तरह से विकसित हुआ था। सबसे पहले मैंने मौजूदा कार्यों का पता लगाया, लेकिन जब मैं बैकएंड पर गया, तो मुझे महसूस हुआ कि यह स्काला को लागू करने का समय था।

बस स्कैला 2.9 आधुनिक, उस समय, वाक्य रचना के साथ बाहर आया था। यदि विवरण महत्वपूर्ण नहीं हैं, तो ट्रेंडी समानांतर संग्रह पूरी तरह से समानांतर में कुछ चलाने के लिए अनुकूल थे। और ग्रूवी के निर्माता जेम्स स्ट्रेचन ने जारी किया : "मैं ईमानदारी से कह सकता हूं कि अगर किसी ने मुझे मार्टिन ओडस्की, लेक्स स्पून और बिल वेनर्स द्वारा 2003 में प्रोग्रामिंग स्कैला किताब दिखाई थी तो मैंने शायद कभी ग्रूवी को नहीं बनाया।"

स्काला को चुनने का एक अन्य कारक यह है कि सभी लोग, जिन्होंने तब टूल, भाषा, लाइब्रेरी पर काम किया था या स्काला के बारे में लिखा था, सुपर स्मार्ट और ऊर्जावान थे। इसलिए, विश्वास था कि यह भविष्य के लिए सही विकल्प था।

बैंक में काम करते समय, मैंने विदेशी सम्मेलनों में जाना शुरू किया। 2012 में पहला स्काला डेज़ , ओस्लो में geeky फ़्लैटपास्ट। उस समय मैं जेन्या बर्माको से मिला। अब हम कभी-कभी कैलिफोर्निया में समुद्र के किनारे टहलते हैं।

स्कैला डेवलपर्स को किराए पर लेना

धीरे-धीरे एक ऑनलाइन बैंक लिखा। 2012 में, वह ग्लोबल फाइनेंस के अनुसार रूस में सर्वश्रेष्ठ बन गया। मेरे लिए, यह कथन की पुष्टि है "इसे सामान्य रूप से करें, यह सामान्य होगा", और कुछ असाधारण नहीं।

ओलेग टिंकोव ने बैंक के विषय को बढ़ावा दिया, जो हास्यास्पद था। शायद इससे हमें अच्छे डेवलपर्स को काम पर रखने में मदद मिली - लोग टीम में थे, लेकिन मैं विस्तार करना चाहता था। सबसे पहले, हमने रिक्ति में लिखा है "जावा-प्रोग्रामर, स्काला - प्लस।" लेकिन स्कैला डेवलपर्स के लिए नौकरियों में जावा का उल्लेख उन लोगों को काट देता है जो जावा के साथ कुछ भी नहीं करना चाहते हैं। इसलिए, हमने वैकेंसी को स्केल सीनियर डेवलपर में बदल दिया। इसने मुझे कुछ लोगों को काम पर रखने की अनुमति दी जिनके साथ मैं किसी दिन काम करना पसंद करूंगा।

फेसबुक ग्रुप

मैं यह समझना चाहता था कि सामान्य रूप से, रूस और मास्को में, स्काला में स्वतंत्र रूप से किस तरह की दिलचस्पी थी, और समुदाय के किस तरह के विचार थे। कोई बैठक या चैट नहीं थे, और विचार सभी को इकट्ठा करना था। उन्होंने फेसबुक पर एक समूह बनाया, जिसमें हमने पहले कुछ बैठकों की योजना बनाई। मीटअप में एक समूह के बिना एक बैठक क्या है? मैं बनाने गया था, लेकिन समूह पहले से मौजूद है - रोमन टिमुशेव ने बनाया। हमने सेना में शामिल होने का फैसला किया, और मिशा अक्षरीन को जोड़ा।



पहली बैठक कोर्टेरा पर प्रतिक्रियाशील प्रोग्रामिंग पर एक स्काला पाठ्यक्रम के बहाने एकत्र की गई थी। कई लोगों ने खुशी जताई, लेकिन करीब 20 लोग आए: उन्होंने मुलाकात की, बताया कि वे कौन थे और किसमें रुचि रखते थे, पाठ्यक्रम से अभ्यास पर चर्चा की और फिर से मिलने के लिए सहमत हुए।

तो यह शुरू हुआ।

रोमन एलिवरोव: स्काला, पूर्णतावाद और निर्दयी संकलन पर 10,000 लाइनें

रोमन एलिआरोव ( एलीजारोव ) - जेटब्रेन समूह के नेता, कोटलिन में कोरटाइन , पुस्तकालयों पर काम में भाग लेते हैं।

लेखक द्वारा ध्यान दें । साक्षात्कार रिकॉर्ड करने से पहले, मैंने सोचा कि अगर मैं उन्हें केवल स्काला में शामिल लोगों से लेता हूं तो यह एक आपदा होगी। लगातार "आराधना" या, इससे भी बदतर, "उत्तरजीवी की गलती"। इसलिए, मैंने फैसला किया कि मैं निश्चित रूप से मरहम में एक मक्खी जोड़ूंगा।

यह अधिक कठिन है - वास्तविक अनुभव वाले लोग जो किसी कारण से भाषा में प्रवेश नहीं करते हैं, वे स्काला में शून्य अनुभव वाले घृणा से छोटे परिमाण का एक क्रम हैं। लेकिन फिर मुझे रोमन एलिबरोव ( एलीजारोव ) का पद याद आया - जेटब्रेन्स समूह का नेता - जिसमें उसने मामलों के बीच स्काला पर हाथापाई की , जिससे मेरा सहित कई बर्नआउट हो गए। नकारात्मक होने के बावजूद, यह संभावना नहीं है कि रोमन ने भाषा के बारे में कुछ अफवाहों पर एक पोस्ट लिखा। एक कारण होना चाहिए, उपयोग से किसी प्रकार का नकारात्मक अनुभव - यह इस तरह से निकला। उसके साथ साक्षात्कार के नीचे बस इस बारे में है, और स्काला सीपीएस प्लगिन के साथ कोरटाइन के डिजाइन और कनेक्शन के बारे में कुछ चर्चाएं।

मामला 2010 में

रोमन एलिसारोव : वर्ष 2000 के आसपास, मैंने जावा में सभी प्रकार के एंटरपेसिस प्रोग्राम किए। इसलिए, मैंने स्काला सहित JVM भाषाओं का अनुसरण किया। ऐसा लगता है कि पहली बार मैंने 2005-2006 के आसपास की भाषा के बारे में पढ़ा।

जब आप सारगर्भित पढ़ते हैं, वाक्यविन्यास बहुत अच्छा है। मुझे याद है कि विवरण पढ़ना, आसपास खेलना और मुझे वास्तव में सब कुछ पसंद था। जावा में बहुत सी चीजें जो विस्तृत हैं और जिनके साथ काम करना मुश्किल है, स्काला में करना आसान है। यह सब मुझे पहले से ही दिलचस्पी था, एफपी के दृष्टिकोण से नहीं, बल्कि व्यावहारिक से - जैसा कि हम कोड लिखते हैं। लेकिन, चूंकि जावा कोडबेस पहले से ही बड़ा है, इसलिए वर्तमान कक्षाओं का एक समूह, 2010 में कहानी होने तक व्यवहार में उपयोग करना संभव नहीं था।

2010 में, उद्यम से संयुक्त राज्य अमेरिका के हमारे साथी ऊब गए। वे नवीनता चाहते थे, और उन्होंने पूरी तरह से स्काला पर एक नया सबसिस्टम लिखा। उसके पास किसी तरह का वेब-इंटरफ़ेस था, वह कुछ सरल कर रहा था। उसी समय, यह प्ले फ्रेमवर्क नहीं है - उपयोगकर्ताओं से केवल एक वेब-सेवा अनुरोध प्राप्त हुआ, जिसे जावा एपीआई कहा जाता है। किसी प्रकार के आंतरिक इंटरेक्टिव कार्यों को करने के लिए एक सामान्य वेब साइट। पार्टनर्स इसे गश करते हैं, यह सफलतापूर्वक काम करता है, सब कुछ ठीक है।

उस समय हम उनके ठेकेदार थे। सबसिस्टम के डेवलपर्स ने पर्याप्त खेला है और अन्य चीजों को करने का फैसला किया है। हमारे ग्राहक हमारे पास आते हैं और कहते हैं: “दोस्तों, इस बात का सहारा लो? वह वैसे भी आपके एपीआई का उपयोग करता है। ” महान, यहाँ यह है - स्काला के साथ प्रयास करने का एक वास्तविक तरीका। इसलिए कोई भी हमें स्काला में कार्यक्रम करने की अनुमति नहीं देगा, क्योंकि सब कुछ कठिन है, लेकिन चूंकि पहले से ही एक परियोजना है, यही कारण है। यह वास्तव में, स्काला के साथ पहला उत्पादन अनुभव है।

स्काला की पहली धारणा है कि जावा की तुलना में कोड कितना कॉम्पैक्ट है । स्काला आपको जटिल चीजों को कॉम्पैक्ट रूप से लिखने देता है। सबसिस्टम कोड की लगभग 10,000 पंक्तियों को ले गया, लेकिन जावा में यह वर्गों के कारण दोगुना होगा। सिंटैक्स, डेटा ट्रांसफर के लिए सभी आंतरिक ऑब्जेक्ट, यहां तक ​​कि जावा एपीआई का संपूर्ण अनुकूलन सभी कॉम्पैक्ट हैं।

स्काला पर पहली और आखिरी 10,000 लाइनें

जब डेवलपर्स चले गए, तो उन्होंने कोड को बिना कोड के छोड़ दिया - इस अर्थ में कि यह सिर्फ कोड था। हमने इसे समर्थन के लिए लेने की कोशिश की, लेकिन एक समस्या थी - संकलन।

कंपाइल स्काला कोड एक खोज है। कोड केवल स्केल कंपाइलर के एक विशिष्ट संस्करण के साथ संकलित करता है - बिंदु संस्करण के लिए सटीक, पैच संस्करण के लिए। बड़ा या छोटा संस्करण अब संकलित नहीं है ।

इसने मेरे लिए 2010 में उद्यम में स्काला के भाग्य का फैसला किया, जहां कोड की लाखों लाइनें हैं। यह कल्पना करना डरावना है कि यदि आप संकलक के मामूली संस्करण को बदलते हैं और कैसे नहीं जा रहे हैं तो कैसे जीना है।

"आपको ठीक-ठीक याद क्यों नहीं है?"

रोमन एलिसारोव : यह क्यों गिर रहा था, मुझे याद नहीं है, निश्चित रूप से। संस्करण से संस्करण में लगातार कुछ बदल रहा था। शायद हम गलत समय में थे?

लेकिन मैंने स्काला के विकास की निगरानी करना जारी रखा, इस तथ्य के बावजूद कि केवल उद्यम में हमने इसे लागू नहीं किया। परिणामस्वरूप, कार्यक्षमता को अन्य जावा अनुप्रयोगों में स्थानांतरित किया गया था। इस कंपनी में स्काला का अस्तित्व समाप्त हो गया।

ये 10,000 लाइनें पहली और एकमात्र थीं। कोड ने उत्पादन में लंबे समय तक काम किया, लेकिन फिर इसे अन्य सेवाओं द्वारा पार्स किया गया और समाप्त कर दिया गया।

विशेष रूप से मेरी पेशेवर गतिविधि के लिए, इस अनुभव ने एक अमिट छाप छोड़ी, इस अर्थ में कि, फिर भी, इस सभी की संगतता की आवश्यकता है। अब मैं कोटलिन कर रहा हूं। यह आश्चर्य की बात नहीं है कि हम हर चीज और हर चीज की अनुकूलता सुनिश्चित करने के लिए केवल समय और अतिरिक्त बलों की अवास्तविक राशि खर्च करते हैं। कभी-कभी समय की एक जंगली राशि कार्यक्षमता में नहीं जाती है, लेकिन बस इतना है कि सब कुछ संगत है। विशेष रूप से, मेरा पिछला अनुभव इसे प्रभावित करता है।

अभी भी लगातार पायथन को याद करते हैं। संगतता के बारे में, हमारे पास दो कीड़े हैं: स्काला और पायथन। जब संगतता की बात आती है, तो कोई भी 2 से 3 पायथन से संक्रमण को दोहराना नहीं चाहता है, और कोई भी स्काला की तरह नहीं बनना चाहता है।

"सही कोड"

- अक्सर आप कुछ फिर से करना चाहते हैं ताकि सब कुछ "चॉकलेट" हो?

रोमन एलिसारोव : मैं डिजाइन में लगा हुआ हूं और मैं लगातार सब कुछ फिर से करना चाहता हूं । मैंने जो किया वह मुझे कभी पसंद नहीं आया। जब मैं रिलीज के लिए कुछ तैयार कर रहा हूं, मुझे कुछ चीजें मिल रही हैं जिन्हें मैं बदलना चाहता हूं। जैसे ही मैं किसी चीज से अप्रयुक्त हो जाता हूं, मुझे पहले से ही इसमें खामियां दिखाई देती हैं: यह अभी तक पूरी नहीं हुई है, यहां हमें इसे स्क्रैच से फिर से लिखना होगा। लेकिन यह सड़क कहीं नहीं है। केवल दो दृष्टिकोण हैं: या तो मैं अनिश्चित काल के लिए कोड में सुधार करूंगा और कभी भी रिलीज के लिए नहीं पहुंचूंगा, या मैं रिलीज को लॉन्च करूंगा और यह लिगेसी बन जाएगा। आप सही कोड जारी नहीं कर सकते ।

फिर मैं उत्पाद को बेहतर बनाने पर आधा समय बिताता हूं, और जो मैंने पहले ही जारी किया है उसके साथ संगतता पर दूसरा। अनुभव अग्रिम में "तिनके बिछाने" में मदद करता है। मैं देखता हूं कि मुझे इसे जल्द ही फिर से तैयार करना होगा, और भविष्य के परिवर्तनों की प्रत्याशा में सुरक्षा नेट पर रिलीज के समय बहुत समय बिताना होगा। बेशक, खरोंच से कुछ करना और अनुकूलता के बारे में चिंता न करना बहुत आसान है। लेकिन समझौता यह है कि आप या तो इसे पूरी तरह से करते हैं, या वे आपके उत्पाद का उपयोग करते हैं। एक दूसरे को बाहर करता है।

कोटलिन पर डिजाइन

रोमन एलिसारोव : मैं लगातार स्काला का अनुसरण कर रहा था, क्योंकि जब हम कोटलिन में कुछ डिजाइन करते हैं, तो हम अध्ययन करते हैं कि स्काला सहित अन्य भाषाओं में क्या है। लगभग दो साल पहले, हमने कोटलिन कोरआउट्स को डिज़ाइन किया था। मुख्य "प्रेरणा", ज़ाहिर है, सी #। यह सब उसके साथ शुरू हुआ और वहाँ से पहले से ही पैदा हुआ था। फिर हमने गो का अध्ययन करना शुरू किया।

जब डिजाइन सी # से विचलन करना शुरू किया और "निरंतरता" दिखाई दिया, और फिर "सीमांकित निरंतरता", हमने एक बार फिर अन्य भाषाओं का अध्ययन करना शुरू किया। Google में, मैं स्काला पर ठोकर खाता हूं - यह पता चलता है कि इसमें पहले से ही " सीमांकित निरंतरता " थी।

- क्या आप कंपाइलर प्लगिन की बात कर रहे हैं?

रोमन एलिबरोव : हाँ। उसी समय, डिजाइन फंतासी के समान था जो अब कोटलिन में है। निस्संदेह, एक वाक्यात्मक अंतर है: कोटलिन में हम शुरुआत में सस्पेंड संशोधक लिखते हैं, और स्काला में आपने रिटर्न वैल्यू पर csp एनोटेशन लिखा है। लेकिन क्या अंतर है जहां संशोधक डालना है: रिटर्न मान के प्रकार या शुरुआत में?

स्काला का डिज़ाइन कोटलिन में वर्तमान के समान था। मुझे दिलचस्पी हो गई - यह कैसे है, इस तरह के शांत डिजाइन के बाद से, यह क्यों नहीं उड़ता है? आधुनिक स्काला में कोई भी ऐसा क्यों नहीं लिखता है? उन्होंने मुझे दिखाया कि वे प्ले फ्रेमवर्क में कैसे लिखते हैं - वहाँ कोई प्लगइन नहीं है।

सभी लोग वायदा लिखते हैं, और हमें वायदा से छुटकारा पाने के लिए एक महान विचार था, क्योंकि यह डिजाइन अधिक सुविधाजनक है। और इसलिए यह कोटलिन में हुआ: वायदा की जरूरत नहीं है, कोरटाइन हैं। स्काला में, उन्होंने "निरंतरता" को त्याग दिया और उड़ान नहीं भरी। क्यों?

संकलन की संवेदनहीनता और निर्ममता

खोज प्रक्रिया में, मुझे सबसे मूल घोषणा मिली। उस वर्ष, स्कैला में "सीमांकित निरंतरता" दिखाई दी। स्काला में फिर सब कुछ वैसा ही किया गया जैसा अब कोटलिन में होता है।

इस अर्थ में घोषणा सांकेतिक है। इसने कहा: "हमने" सीमांकित निरंतरता "किया, देखो, हम लिस्प के समान ही शांत सामग्री लिख सकते हैं।" उदाहरण के लिए, हमने 80-90 के दशक के कार्यों से लिस्प पर एक उदाहरण लिया, और इसे स्काला पर फिर से लिखा: सूचियों को डॉक किया गया है, यहां "शिफ्ट / रीसेट" किया गया है। लिस्प और इसी तरह की भाषाओं में, सीमांकित निरंतरता के लिए एक निर्माण होता है, जिसे "शिफ्ट / रीसेट" के रूप में नामित किया जाता है। नाम मस्तिष्क में विस्फोट करता है - कोई नहीं जानता कि क्या बदलाव / रीसेट है। न तो जिसने लिस्प का अध्ययन किया है, न ही वह जो उससे कभी नहीं मिला है।

इस घोषणा में मुख्य बात इस तरह की टिप्पणियां हैं: “यह शून्य अर्थ के बारे में बताता है। मैंने इसे समझने की कोशिश करने के लिए विकिपीडिया के साथ-साथ कुछ अन्य स्थानों पर भी कुछ समय बिताया। मेरे नजरिए से, ये संख्या जोड़ने के जटिल तरीके हैं और मुझे नहीं पता कि क्या हासिल या पूरा किया जा रहा है। " वे पद का सार समझाते हैं।

इसलिए, एक महत्वपूर्ण सुविधा की ऐसी घोषणा बिल्कुल बेकार है। यदि यह उस व्यक्ति द्वारा पढ़ा जाता है जो आवेदन के लिए कोड लिखता है, तो उसे इस सवाल का जवाब नहीं मिलेगा: “मुझे इसकी आवश्यकता क्यों है? इससे क्या समस्या हल होगी? ”लेखक ने ऐसा कोई सवाल नहीं उठाया। इसलिए, सुविधा ने उड़ान नहीं भरी - इसलिए नहीं कि यह खराब थी, बल्कि इसलिए कि उड़ान भरने का कोई काम नहीं था ।

"क्या वह गलत था?"

रोमन एलिसारोव : हां, उन्होंने इसे गलत दर्ज किया। यह घोषणा के अनुसार था, लेकिन उन्होंने यह नहीं बताया कि इसकी आवश्यकता क्यों है और यह किन समस्याओं का समाधान कर सकता है। लेकिन बात "सही" या सुंदरता की नहीं है। वैसे, हम कोटलिन में यह भी नहीं जानते कि सुंदर ब्लॉग पोस्ट कैसे लिखें, लेकिन एक उचित पोस्ट लिखने के लिए एक सुंदर घोषणा लिखना पर्याप्त नहीं है। सही प्रस्तुति इतनी व्याख्या क्यों नहीं है, बल्कि एपीआई के दृष्टिकोण से भी एक स्पष्टीकरण है ।

मैं कोड पढ़ता हूं, और वहां शिफ्ट / रीसेट विधियों का उपयोग किया जाता है। 70 के दशक में इसे शिफ्ट / रीसेट क्यों कहा गया? मैंने अतीत से नाम के लेखक को खोजने की कोशिश की, लेकिन नहीं कर सका। बस इसी नाम से कोई आया था। एक आधुनिक प्रोग्रामर के लिए, ये शब्द कुछ भी नहीं कहते हैं। उनका मतलब कुछ भी नहीं है।

मैं कोरटाइन के साथ इतना व्यवहार करता हूं कि ऐसा लगता है कि मुझे उनके बारे में सब कुछ पता होना चाहिए, क्योंकि मैं वैज्ञानिक पत्रों का एक समूह पढ़ता हूं। लेकिन जब मुझे एक कोड दिखाई देता है जो "शिफ्ट / रीसेट" का उपयोग करता है, तो मैं हर बार यह समझने के लिए तनाव लेता हूं कि वहां क्या हो रहा है और इसकी आवश्यकता क्यों है। यह किसी तरह का काला जादू लगता है, जबकि अर्थहीन।

एलेक्सी फ़ोमकिन: मृतक फ्लैश, वोस्कोख और पहली मास्को बैठकें

एलेक्सी फ़ोमकिन ( येलबोटा ) - प्रोग्रामर, स्पीकर, पॉडकास्ट, ओपन सोर्स योगदानकर्ता, स्काला उत्साही।

लेखक द्वारा ध्यान दें । तिमुशेव और उसपेन्स्की के मामलों से पीछे हटने के बाद, मॉस्को में पूरे आंदोलन ने एलेक्सी फॉमकिन पर आराम किया । इसके अलावा, उन्होंने स्कलाज़ पॉडकास्ट लॉन्च किया, और अन्य पॉडकास्ट को देखा: डेज़ेन , डेब्रीकिंग , रिमोट टॉक । लेखों की इस श्रृंखला में इसे छोड़ना एक बड़ी गलती होगी।

आपके व्यवसाय से लेकर स्कैला डेवलपर तक

एलेक्सी फ़ोमकिन : मैं शायद बहुत ऊब जाएगा - कुछ भी दिलचस्प नहीं था। मेरी व्यक्तिगत कहानी है। यह मेरे लिए दिलचस्प है, लेकिन पाठकों के लिए यह उबाऊ हो सकता है।

वास्तव में, मैं एक्शन-स्क्रिप्ट में शामिल था, और बाद में मेरा अपना छोटा व्यवसाय था। जब व्यवसाय बंद हो गया, तो मुझे सब कुछ बिना छोड़ दिया गया, क्योंकि तब तक फ्लैश मर चुका था। इस हिसाब से मेरे रिज्यूम में और कुछ नहीं था। मैं काम की तलाश में था, मैं भावनात्मक रूप से उदास था क्योंकि मैंने सब कुछ खो दिया था।

मैंने खुद को एक तकनीकी निदेशक के रूप में नहीं देखा, टीम लीडर भी नहीं। उनकी कंपनी के साथ विफलता के बाद, केवल एक साधारण प्रोग्रामर के लिए महत्वाकांक्षा थी। मैंने यैंडेक्स में जेएस डेवलपर प्राप्त करने की कोशिश की। लेकिन उन्होंने मुझे मना कर दिया क्योंकि मैं उसे अच्छी तरह से नहीं जानता - जो कि सच था।

फिर मैंने स्काला के बारे में सोचा। मैंने इसे कई बार आज़माया, 2010 से शुरू करना - मुझे भाषा पसंद है। मैंने इसकी कोशिश की क्योंकि 2010 में मैंने जिस ऑफिस में काम किया था, वहां ओमाल था। मैं OCaml की तरह चाहता था, बस एक JVM है - मुझे यह पसंद आया। पक्ष में, मैंने स्काला पर कई परियोजनाएं लिखीं, और 2014 में मैंने अपनी कंपनी में आवेदन करना शुरू कर दिया।

स्काला की ओर बढ़ने का एक विचार था: कई प्रस्ताव हैं, कई परियोजनाएं हैं, और डेवलपर्स कम आपूर्ति में हैं। फिर मैं थक गया और कुछ ही महीनों में अपनी सारी जानकारी अपडेट कर दी। मैं भाग्यशाली था - मुझे एक तकनीकी निर्देशक मिला और मैंने स्काला टीम को टाइप किया।

वोसखोद, स्काइप चैट और पहली बैठकों का संगठन

उसी समय, मैंने सोचा कि हमें कुछ चीजों को उत्तेजित करने की कोशिश करनी चाहिए, जब तक कि विषय रूस में बहुत विकसित न हो। उन्होंने उसपेन्स्की , टिमुशेव और अस्करिन के साथ बात की। यह पता चला कि एस्कारिन अकेले रह गया था - उसपेन्स्की "सूटकेस पर था।" मैंने मीटअप करने या न करने की बात की। "हाँ, हम हैं।" और यह अंतिम म्यूटाप था जो पुरानी टीम ने व्यवस्थित किया था। यह कुछ राज्य संस्थान, रिसर्च इंस्टीट्यूट "वॉशकोड" में था। मैं वहां गया, स्काला जेएस या कुछ और के बारे में बताया, और फिर यह विषय पूरी तरह से समाप्त हो गया। चूंकि सब कुछ इतना बुरा है और कोई गतिविधि नहीं है, मैंने खुद को सब कुछ व्यवस्थित करने का फैसला किया - मैंने स्काइप चैट में सक्रिय होना शुरू कर दिया, जिसमें रॉकीज बाहर लटक रहे थे।

- कितने लोग थे?

एलेक्सी फ़ोमकिन : मुझे याद नहीं है - आधुनिक चैट में उनमें से कई नहीं हैं। मुख्य रीढ़ 10-50 लोग हैं जो लगातार बात कर रहे हैं। बाकी आते हैं, जाते हैं, सवाल पूछते हैं - जैसे अभी।

यह 2015 था: स्काइप चैट, Scala.js, कंपनी के साथ पहली बैठक जिसमें उन्होंने काम किया। हमने स्काला का शक्तिशाली रूप से उपयोग किया, और मैंने स्काला.जेएस को बढ़ावा दिया। मैं सभी प्रकार के जेएस डेवलपर्स के पास गया, पॉडकास्ट में, स्कैल्ज के बारे में बात की और मीटअप पर बुलाया।

2016 में, हमने एक पॉडकास्ट शुरू किया। मैंने रोना फेंक दिया और बहुत से लोगों को जवाब दिया। सिद्धांत रूप में, लगभग सभी अभी भी बने हुए हैं, तारानेंको को छोड़कर। फिर ग्रिगोरी पोमाडचिन और ओलेआ माखसोएवा शामिल हुए ।

- क्या किसी ने माइटैप्स की मदद की है? आपके चले जाने पर मैं परेशान था - मानो सब कुछ मर गया था।

एलेक्सी फॉमकिन : कंपनी के अंदर मैक्स पावलोव ने मदद की। वह प्रोग्राम करना जानता है, लेकिन अधिक प्रबंधक। मैं प्रस्तुतियों में व्यस्त था, स्काला भाग, और मैक्स ने संगठन के साथ मदद की: परिसर, उपकरण, पंजीकरण।

सब कुछ डेटा राक्षसों , उर्फ ​​फ्लेक्सिस, उर्फ ​​आदि सेत द्वारा प्रायोजित किया गया था - अलग-अलग समय पर अलग-अलग नाम। मैं तब वहां काम कर रहा था। 2018 में एक और मीटअप मैंने बिताया। वह अकेला था।

निकोलाई तातारिनोव: पहला फ्रेमवर्क और मिट्स की सेंट पीटर्सबर्ग शाखा

निकोलाई तातारिनोव साउंडक्लाउड में एक डेवलपर है, जो एसपीबी स्काला मीटअप का पूर्व आयोजक है।

लेखक द्वारा ध्यान दें । अब मिट्स की सेंट पीटर्सबर्ग शाखा के बारे में। हालांकि वे इतने समय पहले शुरू नहीं हुए थे, 9 घटनाएं पहले ही हो चुकी हैं। प्रदर्शन की गुणवत्ता के संदर्भ में, उन्होंने बहुत बार उठाया है: उनका YouTube चैनल , लाइव प्रसारण।

आयोजकों में से एक निकोलाई तातारिनोव है । हालांकि अब वह पहले से ही स्थानांतरण के कारण सेवानिवृत्त हो चुके हैं, लेकिन मैं उनके पास मानक प्रश्न लेकर आया था। निकोले ने भाषा में प्रवेश के बारे में बात की, आंदोलन, रिलीज 2.0 से पहले प्ले फ्रेमवर्क की स्थिति को थोड़ा प्रभावित किया और अभिनेता मैसेजिंग के भाग्य।

खेल ढाँचा

निकोलाई तातारिनोव : 2012 में मेरी पहली नौकरी में, हमने पहला प्ले फ्रेमवर्क इस्तेमाल किया। इसे रेल की समानता में बनाया गया था। यह दिलचस्प था क्योंकि हमारे पास एक आवेदन था जिसमें बदलाव करना आसान था। लेकिन यह प्रोटोटाइप की स्थिति में था - यह किसी प्रकार की उत्पादन प्रणाली में विकसित नहीं हुआ। सब कुछ वहाँ मिलाया गया था - और यह विकसित हुआ।

पहला प्ले फ्रेमवर्क जावा और ग्रूवी था। , - — - 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. .