JetBrains में समर इंटर्नशिप के बारे में

हेलो, हेब्र!

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

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

यहां एक इंटर्न अपने अभ्यास के बारे में बताता है, कंप्यूटर साइंस सेंटर में एक छात्र और पॉलिटेक्निक यूनिवर्सिटी, कोनोविल किरल:

KIRILL KONONOV:

मेरा अगस्त 2013 पूरी तरह से JetBrains में एक इंटर्नशिप के लिए समर्पित था। दिमित्री बोल्चेव के नेतृत्व में, मैंने व्यक्तिगत प्रोजेक्ट "कमांड लाइन प्लग इन इंटेलीज आईडीईए" के लिए काम किया।

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

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

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

परिचय

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

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

प्रोजेक्ट कमांड लाइन प्लगइन

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

यहाँ मुख्य बिंदु हैं जो मेरे सामने किए गए हैं:

• आवश्यक घटकों के साथ आईडीईए के लिए प्लग-इन का संगठन (विस्तार बिंदु सहित)
• स्थैतिक तर्कों के साथ प्रोटोटाइप वास्तुकला
• निर्मित चार टीमों का सेट
• स्वत: पूर्ण प्रोटोटाइप
• एक पॉप-अप घटक के रूप में इंटरफ़ेस

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

प्लगइन का नया संस्करण निम्नलिखित की विशेषता है:

• नाम तर्क वास्तुकला
• कुशल वृद्धिशील पार्सिंग
• ऑटो-पूर्णता के लिए पूर्ण समर्थन
• बहुआयामी सत्यापन
• प्रयुक्त टीमों का इतिहास
• स्थायी घटक इंटरफ़ेस

आगे, मैं संक्षेप में बात करूंगा कि इनमें से प्रत्येक बिंदु को कैसे लागू किया गया था।

1. नामांकित तर्क

नामांकित तर्कों का उपयोग करने से स्थिति संबंधी तर्कों का उपयोग करने की तुलना में अधिक लचीलेपन की अनुमति मिलती है। निम्नलिखित प्रारूप अपनाया गया था:



कुल मिलाकर, छह विकल्प संभव हैं - उद्धरण चिह्नों में लंबे मान (वे किसी भी वर्ण, रिक्त स्थान सहित) कर सकते हैं।

2. वृद्धिशील पार्सिंग

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


इस उदाहरण में, तर्क v3 को इसके मान के साथ पुराने राज्य से हटा दिया जाएगा, और तर्क v4 को नए राज्य में जोड़ा जाएगा (कमांड को क्लियर और री-पार्स किए बिना, तर्क v1 और v2)।

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

3. स्वतः पूर्ण

स्वतः पूर्णता उपयोगकर्ता इनपुट के दौरान पाठ के किसी भी भाग के पूर्ण स्ट्रिंग मान को प्रतिस्थापित करने की क्षमता है।



पूरक के लिए विकल्प उपलब्ध हैं:

• टीम का नाम
• तर्क नाम
• तर्क मान (जब संभव हो)

पहले दो दिशाओं में संकेत स्पष्ट हैं: प्लगइन के पास कमांड का अपना सेट है, एक्सटेंशन प्वाइंट के उपयोग के माध्यम से एक्सटेंशन से प्राप्त कमांड का एक सेट है, और प्रत्येक कमांड के लिए तर्क विकल्पों का एक निश्चित सेट है।

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

4. मान्यता

यहां सत्यापन अपने सभी तर्कों के साथ कमांड प्रविष्टि की शुद्धता की परिभाषा है।
इसमें केस विश्लेषण शामिल है:

• अमान्य आदेश, विकल्प या तर्क मूल्य
• परस्पर अनन्य तर्क
• एक आवश्यक तर्क का अभाव
• पहले से दर्ज किए गए के संबंध में एक आश्रित तर्क की अनुपस्थिति

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

5. टीमों का इतिहास

कमांड लाइन का उपयोग करते समय, पहले से दर्ज कमांड पर लौटना आम है। इस विचार के भाग के रूप में, प्लगइन के दो मुख्य कार्य हैं:

• कमांड के इतिहास के माध्यम से आंदोलन: Ctrl + up / down
• आदेशों की एक पूरी सूची प्रदर्शित करें

निम्नलिखित आदेशों की पूरी सूची दिखाने का एक उदाहरण है:


यह महत्वपूर्ण है कि कहानी पूरे आईडीई के जीवनकाल में जमा होती है (और जब आप कमांड-लाइन घटक को बंद करते हैं और इसे कहीं और खोलते हैं तो गायब नहीं होते हैं)।

6. इंटरफ़ेस

अपने नए रूप में, कमांड लाइन प्लगइन एक मजबूत घटक है। जब आप फ़ोकस या किसी अन्य क्रिया को खो देते हैं तो वह गायब नहीं होती है, जो इसके स्पष्ट कंटेनर को बंद करने या बंद करने से संबंधित नहीं होती है (पॉप-अप घटकों के विपरीत)।

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



एक उदाहरण विभिन्न परिस्थितियों में घटक व्यवहार के लिए रणनीति दिखाता है। उदाहरण के लिए, यह देखा जा सकता है कि इसका आकार न्यूनतम है और यह चरम विंडो स्ट्रेचिंग / कम्प्रेशन के तहत IDE की सीमाओं से आगे नहीं जाता है।

इस प्रकार, आईडीई विंडो में प्लगइन सहज महसूस करता है।

परियोजना का विकास

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

समय का 40%:

• वास्तु घटकों का पूरा होना
• इंटरफ़ेस में सुधार

समय का 60%:

• आदेशों के सेट का विस्तार करना

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

ट्रेनिंग

अब मैं थोड़ी बात करना चाहूंगा कि जेटब्रेन में मेरा काम कैसे हुआ।

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

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


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

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

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

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

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

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