कोटलिन, एस्टोनिया में आईटी और (अचानक) तेलिन और हेलसिंकी के बीच सुरंग: एंटोन केक्स के साथ एक साक्षात्कार

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



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

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

- आपने कोटलिन में लिखना कैसे शुरू किया, और अब आप इसका उपयोग कैसे करते हैं?
- संस्करण 1.0 से, 2016 की शुरुआत में उपयोग करना शुरू किया। कोटलिन में मेरा पहला प्रोजेक्ट सबसे सुरक्षित था: इंटेलीजे आईडीईए के लिए एक प्लग-इन, जो मैंने एक जापानी ग्राहक के लिए किया था। उसके बाद, मैंने अपने व्यक्तिगत प्रोजेक्ट्स को जावा से कोटलिन में शुरू किया और स्थानांतरित किया, और बैकएंड के लिए इसका उपयोग करने की कोशिश की।

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

- चूँकि आपने संस्करण 1.0 से लेकर आज के 1.3 तक की भाषा को देखा - इस पर डेवलपर लेखन के दृष्टिकोण से यह कैसे बदल गया?
- शुरुआत में, मैंने सोचा था, रिलीज के संस्करण के बाद से, फिर सब कुछ पहले से ही भयानक है और समस्याओं के बिना काम करेगा। यह काफी हद तक नहीं निकला, और 1.0 और 1.1 के बीच पहला अंतर, बड़े पैमाने पर शेयरों का सुधार, प्रदर्शन में सुधार, और इसी तरह है। लेकिन संस्करण 1.2 और 1.3 नई सुविधाओं के बारे में हैं।

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

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

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

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

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

- यदि हम स्वयं भाषा के बारे में बात नहीं कर रहे हैं, लेकिन, उदाहरण के लिए, IDE के बारे में, तो विकास कहां हो रहा था? चीजें पहले कैसे थीं, और अब क्या हैं?
- चूंकि JetBrains भाषा, संकलक और उपकरण दोनों का उत्पादन करता है, इसलिए IDE में समर्थन के संदर्भ में एक अभूतपूर्व स्थिति थी। बहुत बार, जब किसी भाषा का जन्म होता है, तो प्रारंभिक रूप से शुरुआती पाठकों को बिना हाइलाइटिंग के पाठ संपादक में लिखा जाता है, और जैसे। और कोटलिन के साथ यह 1.0 संस्करण तक भी नहीं था, IDE में समर्थन तुरंत था।

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

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

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

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

- नई तकनीकों के साथ, "दिलचस्प का एक शाश्वत डर है, लेकिन आप इसे अभी तक उत्पादन में नहीं खींच सकते हैं", और एंड्रॉइड में ऐसी कोई समस्या नहीं है, लेकिन एंड्रॉइड के बाहर अभी भी एक सवाल है। यदि ऐसी चिंताएं कोडबोर्न के लिए प्रासंगिक हैं, तो उस समय में जब आप कोटलिन का उपयोग करते हैं, तो क्या बदल गया है?
- हम मुख्य रूप से स्वयं तकनीक का चयन करते हैं, लेकिन अक्सर ऐसा होता है कि ग्राहक निर्णय लेने में भी भाग लेना चाहता है। और फिलहाल, जब हम विभिन्न परियोजनाओं के लिए कोटलिन लाते हैं, तो कोई आपत्ति नहीं है। क्या बदल गया है: पहले, ग्राहकों ने कोटलिन के बारे में कुछ भी नहीं सुना था, लेकिन अब यह पहले से ही सुनवाई पर है। और अब, अगर हम कहते हैं, "हम कोटलिन पर स्विच करना शुरू कर रहे हैं," अब कोई डर नहीं है, उदाहरण के लिए, कि वह गायब हो जाएगा। वहाँ Kotlin Foundation है, वहाँ JetBrains और अन्य कंपनियां अच्छी वित्तीय स्थिति में हैं। और सामुदायिक समर्थन महान है। सामान्य तौर पर, पूरी तरह से विश्वास है कि कोटलिन कहीं नहीं जा रहा है।

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

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

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

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

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



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

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

माइनस की, केवल जलवायु। गर्मियों में यह बहुत अच्छा है, और सर्दियों में यह बर्फ से सुंदर है, लेकिन नवंबर एक बहुत ही निराशाजनक महीना है।

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

- यह अचानक लगता है: सहज रूप से, ऐसा लगता है कि इस तरह के आईटी केंद्र घाटी जैसी जगहों पर होंगे, और नोवोसिबिर्स्क की तुलना में कम आबादी वाले देश में नहीं।
- खैर, घाटी में यह सिर्फ एक आईटी व्यक्ति है जो बदतर हो सकता है, अवास्तविक अचल संपत्ति की कीमतें हैं और आमतौर पर रहने की लागत।

और, शायद, रूसी स्रोतों में एस्टोनिया के बारे में बहुत कम लिखा गया है, लेकिन यदि आप अंतरराष्ट्रीय प्रेस को देखते हैं, तो "इलेक्ट्रॉनिक राज्य, दुनिया में पहला" (यहां एक महान उदाहरण है ) की भावना में बहुत सारे ग्रंथ हैं। जब मैं दुनिया भर के आईटी सम्मेलनों में जाता हूं, तो वे मुझसे कहते हैं: “एस्टोनिया? ओह, आपके पास वहां ऐसा है! "

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

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

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

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

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

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

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

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

- साक्षात्कार की शुरुआत में, जापानी ग्राहक का उल्लेख किया गया था - क्या यह विशिष्ट है? जब विदेश में ग्राहक, और यहां तक ​​कि उन भाषाओं के साथ जो आपको किन भाषाओं से निपटना है?
- जापान के बारे में - हां, आमतौर पर, एस्टोनिया जापानी के साथ बहुत काम करता है, वे पूरे प्रतिनिधिमंडल के रूप में यहां आते हैं।

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

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

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

और मैं कहूंगा कि एक कंपनी बनाना एक अच्छा विकल्प है, लेकिन वास्तव में इस तथ्य के लिए तैयार रहें कि ज्यादातर समय (विशेष रूप से पहले) आपके पास ऐसे कार्य होंगे जो आईटी से संबंधित नहीं हैं। « », , — .

, - . — , .

— — « ». , « »?
— , flat-. « », , , — « ». , , , core team 10 , 30 - . .

— « »: ? ?
— : . ( ), — . . : , , , .

— , - . ?
— . , , , . Codeborne, — , , - . , ( ) , — , - . . .

इस सप्ताह के अंत में, एंटोन ने मॉबियस सम्मेलन में मॉस्को में कोटलिन गूढ़ लोगों के दूसरे सेट को प्रस्तुत किया । उनके अलावा, कार्यक्रम में मोबाइल डेवलपर्स के लिए बहुत सारी दिलचस्प चीजें भी हैं (उदाहरण के लिए, रिपोर्ट "एंड्रॉइड और आईओएस के लिए कॉमन कोड लिखने के लिए कोटलिन" )।