"यह फ्रंट-एंड से बाहर निकलने का समय है": एंड्रे सीटनिक समुदाय के ठहराव पर, खुला स्रोत और न केवल

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

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

वर्तमान परियोजनाओं के बारे में

दिमित्री: सबसे पहले, हमें अपने बारे में संक्षेप में बताएं - आप कहाँ हैं और आप क्या कर रहे हैं।

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

ओपन सोर्स के अलावा, मैं ट्विटर @LinguoPunk पर भाषाई विविधता, @LostInWiki पर विकिपीडिया और सेक्स पॉज़िटिविज़्म की लड़ाई को भी बढ़ावा देता हूं।

दिमित्री: अब आप किन परियोजनाओं पर काम कर रहे हैं?

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

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

दिमित्री: राहेल आपको एक साधन बनाने से कैसे रोक सकता है?

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

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

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

दिमित्री: आपने बहुत गोलीबारी की, लेकिन 2016 में होलीजेड में प्रस्तुति के बाद लॉगक्स के बारे में, आप वास्तव में नहीं सुनते कि उसके साथ क्या हुआ?

एंड्रयू: यह एक अच्छा सवाल है, क्योंकि यह एक बहुत ही दिलचस्प विषय उठाता है। तथ्य यह है कि सॉफ्टवेयर वितरित करने के विभिन्न तरीके हैं।

ओपन सोर्स का इस्तेमाल करना किसी तरह का तर्कसंगत निर्णय नहीं है। सॉफ्टवेयर विकास फैशन उद्योग द्वारा सबसे अच्छा वर्णित है। तकनीकी पसंद, सबसे पहले, फैशन, प्रचार और इसी तरह की चीजें हैं।

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

एक अच्छे तरीके से, आधे से अधिक लोकप्रिय ओपन सोर्स प्रोजेक्ट सिर्फ घृणित थे। बल्कि, उनके चारों ओर का प्रचार पूरी तरह से कोड की गुणवत्ता और आयोजकों के समर्थन के स्तर के साथ असंगत है। लेकिन जब से बहुत सारे लोग प्रचार ट्रेन पर बैठे, परियोजना बच गई और अस्तित्व में बनी रही।

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

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

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

मेरी राय है कि इस प्रकार के कार्य के लिए प्रचार ट्रेन काम नहीं करती है। हम एक निर्णय नहीं कर सकते हैं ताकि हर कोई इसमें कूद पड़े और सब कुछ हो जाए। जब हम फ्रंटएंड और बैकएंड के लिए तुरंत समाधान देते हैं, तो यह सभी हाईवे ट्रेन को समुदायों के बीच टकराव की ओर ले जाने का प्रयास करता है।

इसलिए, मैंने फैसला किया कि लोगक्स के साथ हम ऐसा नहीं करेंगे, लेकिन हम सावधानी से और धीरे-धीरे जाएंगे, इसे परियोजना के अंदर तैयार करेंगे। इस पूरे या दो साल में, हमने Amplifer के अंदर Logux को पकाया, विभिन्न परियोजनाओं पर इसका इस्तेमाल किया, और देखा कि कैसे बैकएड प्रतिक्रिया करते हैं। मैंने समझाने की कोशिश की, दिखाने के लिए, और अब दीमा सलाखुद्दीन, रूबी-कन्फ्यू में लॉगक्स के बारे में बात करने के लिए जाएगी, ताकि हम देख सकें कि वे कैसे प्रतिक्रिया करते हैं, हम पीआर को बैक-एंड कैसे देते हैं। क्योंकि हम उन्हें सामने वाले वेंडर्स को "इट्स हाइप" की भावना से कहते हैं कि यह गलत है, यह वहां काम नहीं करता है।

दिमित्री: यह काम क्यों नहीं करता है?

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

मैं बैकएंड और क्लाइंट पर इसे सही ढंग से वितरित करना चाहता हूं, मैं एक तैयार समाधान के साथ आना चाहता हूं जो वास्तव में काम करेगा, जिसे हमने वास्तव में उत्पादन पर परीक्षण किया था। 2017-2018 में, हमारे पास पहले से ही 0.2 का एक कार्यशील संस्करण था, लेकिन कोई मापनीयता नहीं थी। हमें अंदाजा था कि कैसे पैमाना है, और पीआर के लिए यह पर्याप्त होगा, लेकिन वास्तव में यह गलत है।

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

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

दिमित्री: यह काफी दिलचस्प लगता है। और, जैसा कि मैं इसे समझता हूं, निकट भविष्य के लिए योजनाएं काफी बड़ी हैं?

आंद्रेई: हां, हमने पहले ही व्यावहारिक अनुप्रयोग के लिए योजनाएं पूरी कर ली हैं, मैं अब 0.3 जारी करूंगा और डॉक लिखूंगा जो बड़े पैमाने पर आवेदन के लिए पर्याप्त नहीं हैं। और कोड अच्छा है।

नैनो आईडी और फास्ट इंटरनेट के बारे में

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

आंद्रेई: क्या मुझे यह प्रतीत नहीं होता कि यह "मैचों पर बचत" है जब सभी के पास सामान्य इंटरनेट है? अच्छा सवाल है।

नैनो आईडी 141 बाइट लाइब्रेरी है जो आईडी बनाती है। जब हमने इसे 200 बाइट्स से कम किया, तो इसका कोई व्यावहारिक अर्थ नहीं था, लेकिन यह एक "राजनीतिक घोषणापत्र" था जिसके बारे में सोचने का समय था।

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

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

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

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

आप एंट्रोपी विधि का उपयोग करके साइट का अध्ययन करने के प्रश्न को चालाकी से कर सकते हैं। हमारे पास एक वेबसाइट है जिसका वजन 1 एमबी है। "सूचना की मात्रा" की अवधारणा है। एक मेगाबाइट सिर्फ लाइनों की संख्या नहीं है, यह इस कोड में कितना अर्थ निहित है। और 1 एमबी की आवश्यकता के लिए साइट कितनी जटिल होनी चाहिए? क्या साइट पर वास्तव में इतने सारे उपयोगकर्ता मामले हैं कि उन्हें कवर करने के लिए कोड की इतनी मात्रा होनी चाहिए?

वास्तव में, ऐसे मामले बहुत कम हैं। लिनक्स कर्नेल में बहुत अधिक जरूरत है, लेकिन साइटों पर नहीं। और इसलिए, हमारे पास निरर्थक कोड का एक गुच्छा है।

नैनो आईडी आंदोलन का अर्थ हर बाइट को बचाना नहीं है, बल्कि यह सोचना है: “मेरे पास बंडल में क्या है? क्या मैं वहाँ 1 एमबी हूँ? मेरे पास ऐसे कार्य नहीं हो सकते हैं जहाँ ऐसी मात्रा की आवश्यकता होगी। " अधिकांश साइटों पर, 75% कोड का उपयोग नहीं किया जाता है। नैनो आईडी उपयोगकर्ताओं को इस कोड को भेजने के खिलाफ एक आंदोलन है।

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

और सबसे अधिक बार यह मात्रा पुस्तकालयों है। Moment.js के साथ प्रसिद्ध कहानी: आप इसे कनेक्ट करते हैं, और वेबपैक ऑपरेशन की ख़ासियत के कारण, यह आपकी वेबसाइट पर हर भाषा को लोड करता है । और इसी तरह के कई मामले हैं।

एक समय में, मुझे लॉगक्स में एक अद्वितीय आईडी बनाने की आवश्यकता थी, मैंने एक पुस्तकालय लिया, और फिर पाया कि इसका वजन 100KB है। एक यादृच्छिक आईडी बनाने के लिए मुझे इतनी आवश्यकता क्यों है?

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

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

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

दूसरी समस्या यह है कि वे गलती से Node.js. से कुछ API का उपयोग करते हैं उदाहरण के लिए, एक पुस्तकालय choo.js था - "कॉम्पैक्ट जेएस-फ्रेमवर्क", जहां उन्होंने Node.js- मॉड्यूल मुखर का उपयोग करते हुए आने वाले तर्कों की जांच की। और यह लगभग 4 केबी लोड करता है। और एक छोटे पुस्तकालय की खातिर, हम एक अतिरिक्त 4 केबी जहाज करते हैं।

और इस तरह की समस्याएँ बहुत अधिक आम हैं, जिनका उपयोग पेड़ लगाने के लिए किया जाता है।

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

मैक्सिम: फिर यह पता चला है कि असेंबली के लिए वेबपैक का उपयोग करना खराब है?

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

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

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

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

क्यों ट्रेन और अभिजात वर्ग खराब हैं

मैक्सिम: आपने बस कूलर बंडलों के पक्ष में वेबपैक से बचने के बारे में बात की थी। शायद इस तथ्य में एक समस्या है कि आपके स्तर के लोगों की ऐसी सिफारिशें प्रचार का निर्माण करती हैं? कुछ नया उपयोग करने की सिफारिश करने के बजाय, शायद यह कहें कि "चलो धक्का दें और वेबपैक को फिर से महान बनाएं"?

एंड्रयू: अच्छा सवाल है। एक ओर, वास्तव में एक समस्या है जब इस तरह की टिप्पणियों को संदर्भ को समझने के बिना माना जाता है। लेकिन एक और समस्या है: मुझे ठहराव का डर है।

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

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

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

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

एक समुदाय है, और जहां इसे स्थानांतरित करना है - पुराने उपकरणों को स्थिर करने और जोड़ने के लिए या नए लोगों का उपयोग करने के लिए - मेरे पास कोई जवाब नहीं है।

एक आदर्श दुनिया में, हम यह महसूस नहीं करेंगे कि पुराने उपकरणों का उपयोग करना बुरा है, लेकिन हम नई परियोजनाओं पर नए का उपयोग करेंगे। और मुझे नहीं पता कि इसे कैसे बनाया जाए। दरअसल, गलत सिफारिशें की जाती हैं, और लोग "गलत" चीजों का उपयोग करने के लिए दूसरों को जहर देना शुरू कर देते हैं।

मैक्सिम: आपकी राय में, क्या यह संभव है कि माइक्रोसॉफ्ट और फेसबुक जैसे बड़े निगम वेबपैक और बैबेल जैसे बड़े ओपन सोर्स प्रोजेक्ट खरीदने लगें?

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

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

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

— , . , - , : , . , , , , . , , .

: « » - , ?

: . , , — . , , [] . ?

: , . - , , - , .

: , . , — , , 37signals DHH .

, , , . , , , - . , , .

, . , IT .

DHH , , : , , , . , .

: . -, - - , , ?

: Vue.js. , React, , React. , : , .

« , , », , 20–30% . — . , , Google .

Google , , . , - Instagram Facebook, , , , . . , Vue : , React .

, Vue , . , , . — , , win/win. - .

, , , -, - , , , , - .

: , .

: . : , , -.

, — : , , . « ». , , , , .

-, , 99- . , Size Limit, , , , , Size Limit .

, : - , , , , , , . , , . .

. — « , Google», « , Google, , 99% ».

, , . , , . : , , .

, - pull request Babel, , - . , , — , .

, , - . , , . , .

— - . , PostCSS , , CSS-. Autoprefixer , Compass, , Compass , , , , Opera .

, , , . Accessibility, , URL, , . , — , . , , , Autoprefixer.

, , , , , , , .

: ? , , , JavaScript , , . , ?

: , , — , . — .

: . , , , .

: , , , , , . , . , .

- , … PostCSS , , . , , . - -, , , , , .

: ?

: , , .

: , , , ?

: , , , , - , , , , , . : « Open Collective , , ».

, . . . , , , . « , , . Open Collective, , . , , , ».

, Babel webpack. : « , . issue, Open Collective , ». , . , — . , , . , .

, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .

: - , - ?

: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.

: , pet project . , , : , , -, , . , , ?

: - . , . , , .

« ». . , . , . — , , maintainer , , - .

, . , , . , , , issue, - , , , .

, ? . , , , . , , .

: , ?

: , . . . , .

: , , . , . , -, , . , , .

, . , 10, , , , , .

: , , ? , - : « , ».

: , , , . , . , . «» — , , — . , , - PostCSS. .

, - , . - : , , , , , .

— . , , , , , , . , . — , . , .

,

दिमित्री: आपने कहा कि पोस्टसीएसएस यात्रा करने में मदद करता है। आप कितना यात्रा करते हैं, और आप इसे काम के साथ कैसे जोड़ते हैं?

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

न्यूयॉर्क में बैठा, यूट्यूब देख रहा था। मैं सामान्य रूप से और कुशलता से काम करने के लिए यात्रा करता हूं। एक स्थान पर, मैं तुरंत एक वफ़ल बन जाता हूं, सोफे पर झूठ बोलता हूं। मैं अधिक उत्पादक बनने के लिए यात्रा करता हूं, इसलिए संयोजन आसान है।

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

मैक्सिम: हर कोई समझता है कि अंग्रेजी का ज्ञान आवश्यक है, लेकिन अच्छी तरह से सीखना इतना आसान नहीं है। क्या आपके पास एक अच्छी पृष्ठभूमि है? आपको अच्छी अंग्रेजी कहाँ से मिली?

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

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

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

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

दूसरा बिंदु - उपशीर्षक के साथ श्रृंखला देखें, यह वास्तव में मदद करता है।

यात्रा करें, बस भाषा सीखें।

और सबसे महत्वपूर्ण बात - बोलने की कोशिश करें।

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

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

रूस में अंग्रेजी बोलने वाली बैठकों में भाग लें, यह डरावना नहीं है, कोई भी आपको नाराज नहीं करेगा, सब कुछ ठीक है।

दिमित्री: क्या आप भाषा सीखने के लिए थोड़ी देर के लिए कहीं जाने की कोशिश कर रहे हैं, यदि हां, तो कहाँ?

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

और मैं कुछ और कह सकता हूं। रूस में, एक लोकप्रिय कथा है जिसे दोषी ठहराया जाना चाहिए, और हर जगह अच्छा है: "रूस में, सब कुछ बुरा है, मैं डंप कर दूंगा और मैं खुश रहूंगा।" ईमानदारी से - यह प्रेरणा है जिसे निर्देशित नहीं किया जाना बेहतर है। क्योंकि कथा बहुत पुरानी है, और ऐतिहासिक रूप से हम जानते हैं कि यह 18 वीं -19 वीं शताब्दी से काम नहीं करती है। अन्य देशों में, मौलिक रूप से बेहतर नहीं है। मूलभूत प्रबंधन समस्याएं हैं, लेकिन जितनी जल्दी या बाद में वे किसी भी देश में दिखाई देते हैं।

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

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

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

लेकिन ईमानदार होने के लिए, आप खुश नहीं होंगे, क्योंकि उत्प्रवास की पहली लहर हमेशा भयानक पीड़ा का अनुभव करती है, उदास रहने के लिए, आगे बढ़ने के बाद आप अपना संपूर्ण सामाजिक दायरा खो देंगे।

दिमित्री: मैं जानना चाहूंगा कि अन्य देशों में डेवलपर्स के रूसी समुदाय में क्या अंतर है।

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

मुख्य विचार यह है कि अच्छी प्रथाओं को जल्दी से फैलाने के लिए संस्कृति में बहुत रूढ़िवादी सोच है। वहाँ बड़ी संख्या में प्रोग्रामर बेवकूफ गलतियाँ नहीं करते हैं, क्योंकि सभी को इस तरह लिखने के लिए कहा गया था, हर कोई इस तरह लिखता है। इसके बजाय, अपने विचारों को बढ़ावा देना काफी कठिन है।

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

यह समुदाय में सबसे महत्वपूर्ण सामाजिक अंतर है। फायदे में से - वे चढ़ाई करना आसान है, और वास्तव में ध्यान रखते हैं कि लोग पीड़ित न हों। आप आते हैं, हर कोई मित्र है, सब कुछ ठीक है, जब तक आप एक साधारण व्यक्ति हैं जो नियमों से खेलते हैं।

दूसरी दिलचस्प विशेषता यह है कि वे अक्सर भोजन के लिए जाने वाले 5-10 डॉलर के प्रतीकात्मक मूल्य mitaps के लिए भुगतान करते हैं। फिर से, क्योंकि पूंजीवाद।

दिमित्री: और यदि यूएसए नहीं, लेकिन अन्य देशों में?

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

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

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

ब्राजील का एक अच्छा समुदाय है। हिस्पैनिक देशों के पास यह नहीं है, क्योंकि हर कोई अमेरिका के लिए उन्मुख है। फ्रांस में भी एक अच्छा आंतरिक समुदाय है।

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

मैं आपको चीनी और भारतीय सम्मेलनों में बोलने की सलाह देता हूं: वहां पहुंचना आसान है (वे बाहर से किसी व्यक्ति को सहर्ष स्वीकार करते हैं), और आप अंग्रेजी में ऐसे वातावरण में अभ्यास करते हैं, जहां आप डरेंगे नहीं, क्योंकि कोई भी वास्तव में अंग्रेजी नहीं जानता है और हर कोई त्रुटियों के साथ बोलता है।

आदर्श सम्मेलन

दिमित्री: अगर हम सम्मेलनों के बारे में बात करते हैं, तो एक वक्ता के रूप में भाग लेने के लिए निर्णायक कारक क्या है?

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

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

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

मैं अक्सर एक छोटी सी बैठक में जाने के लिए सहमत होता हूं, ताकि सभी की नेटवर्किंग की सामान्य पहुंच हो। और कई बैठकों में, उच्च टिकट मूल्य वाले सम्मेलनों की तुलना में संवाद बेहतर है। यह मेरा दृष्टिकोण है।

दिमित्री: एक सम्मेलन के बिना क्या अच्छा नहीं हो सकता? यह पहले से ही नेटवर्किंग, पहुंच और अन्य चीजों के बारे में स्पष्ट है?

आंद्रेई: एक वक्ता के रूप में, मैं वास्तव में सराहना करता हूं जब मंच के सामने टाइमर होता है। इस संबंध में, HolyJS में सब कुछ बहुत ही पेशेवर है, मुझे प्रदर्शनों का संगठन पसंद है। सामान्य तौर पर, नेटवर्किंग एक महत्वपूर्ण बात है, लोग सम्मेलनों में जाते हैं, ज्ञान के लिए नहीं, किसी रिपोर्ट की तुलना में लेख पढ़ना आसान है, लेकिन समुदाय से संबंधित होने की भावना के लिए।

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

दिमित्री: आपने कहा "ज्ञान के लिए नहीं", यह एक बहुत ही विवादास्पद मुद्दा है। क्या आप एक सम्मेलन में जाएंगे जहां बहुत ही बुनियादी विषयों वाले लोगों का संग्रह है, लेकिन बहुत अलग समुदायों से, इकट्ठा किया गया है?

आंद्रेई: हाँ, निश्चित रूप से, यह बहुत मज़ेदार होगा।

दिमित्री: और यह एक सम्मेलन से अधिक दिलचस्प होगा जहां गंभीर और शक्तिशाली रिपोर्टें हैं?

आंद्रेई: मुझे लगता है कि दोनों दृष्टिकोण अच्छे हैं, और यहां कोई समस्या नहीं है।

दिमित्री: शायद अंतिम सवाल। आप होलीजस से क्या उम्मीद करते हैं?

एंड्रयू: अच्छी पार्टी! 2016 में, इसे सीधे श्रेय दिया गया, मेरे जीवन में सर्वश्रेष्ठ में से एक, और फिर सब कुछ बहुत अच्छी तरह से व्यवस्थित था।

दिमित्री: इस बार और बेहतर बनाने के लिए आप क्या करने की सलाह देंगे? एक पार्टी की कामना करते हैं?

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

निकटतम होलीजेएस (सेंट पीटर्सबर्ग, 24-25 मई) में, आंद्रेई ओपन सोर्स परियोजनाओं को बढ़ावा देने के बारे में अधिक बात करेंगे। और उसके अलावा, जेएस ओपन-सोर्स के कई अन्य महत्वपूर्ण आंकड़े होंगे: रयान डाहल (Node.js, Deno) से लेकर मिशेल वेस्टस्ट्रेट (MobX, Immer)। रिपोर्ट के उनके विषयों के बारे में सभी विवरण वेबसाइट पर हैं , टिकट वहां खरीदे जा सकते हैं, और धीरे-धीरे वे अधिक महंगे हो जाते हैं।