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

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

यह टीम में कठिन, लेकिन कठिन तकनीकी कौशल को पंप करने के तरीके के बारे में होगा। रिपोर्ट में दो भाग हैं: मानवीय और रचनात्मक। यहां तक कि अगर आप एक तकनीकी विशेषज्ञ नहीं हैं, तो दूसरे भाग में आपको अपने मानवीय दिमाग पर दबाव डालना होगा, क्योंकि तकनीकी जानकारी के बिना, कहीं नहीं - मैं कठिन कौशल और उनके स्तर के बारे में बात करूंगा।
आईटी जारी करता है
मेरा मानना है कि आईटी में एक बड़ी समस्या है - और यह
स्टाफ की कमी है । इस मुद्दे पर कई बार चर्चा की गई है, इस विषय पर
hh.ru और प्रकाशनों के
आंकड़े हैं। बस मामले में, आंकड़ों की स्वयं जांच करें। यदि आप hh.ru खोज इंजन में "जावा" दर्ज करते हैं, तो हम रूस में 5-6 हजार नौकरियां देखेंगे और उसी hh.ru पर रिज्यूमे की संख्या 100 हजार से अधिक है। ऐसा लगता है कि डेवलपर्स की कोई कमी नहीं है - फिर से शुरू करना रिक्तियों से बड़ा परिमाण का एक आदेश है। ।

दूसरी तरफ से देखते हैं। साइट hh.ru का एक विशेष सूचकांक है, जिसे
hh-index कहा जाता है। यह सक्रिय रिज्यूमे और रिक्तियों का अनुपात है। जावा अनुरोध के लिए, यह लगभग एक के बराबर है: एक रिक्ति के लिए, एक फिर से शुरू। फिर, यह पता चला है कि कोई कर्मियों की कमी है? कंपनी को एक प्रोग्रामर की जरूरत है, यह एक रिक्ति खोलता है, और, सूचकांक के अनुसार, वरिष्ठ को तुरंत आना चाहिए, नौकरी प्राप्त करना चाहिए और रिक्ति को बंद करना चाहिए।
स्वामी "आना" चाहिए, लेकिन नहीं आता है। आंकड़े कहते हैं कि कर्मियों की कमी नहीं है, लेकिन वास्तविक दुनिया में, और एचएच-इंडेक्स की दुनिया में नहीं है, यह है। जावा एक सुपर-दुर्लभ व्यवसाय है। जावा वरिष्ठों के लिए एक खूनी सिर-शिकार है: नौकरी पाने के लिए एचआर और रिक्रूटर्स जो उन्हें ऑफर करते हैं। औसतन, एक जावा डेवलपर
को 5-6 ऑफ़र मिलते हैं , भले ही वह नियोजित हो।
मामला क्या है? स्टाफ की कमी कहां से आई? मेरे व्यक्तिगत साक्षात्कार के अनुभव से, मेरा मानना है कि समस्या यह है कि अधिकांश नौकरी चाहने वाले जो रिज्यूमे भेजते हैं और साक्षात्कार के लिए आते हैं उनमें
अपर्याप्त शिक्षा और कम योग्यताएं होती हैं। लेकिन चूंकि स्टाफ की कमी है, इसलिए कंपनियों को इन लोगों को नियुक्त करने और अपने दम पर प्रशिक्षित करने के लिए मजबूर किया जाता है - उच्च योग्यता वाले लोग कम कौशल वाले लोगों को शिक्षित करने में अपना समय व्यतीत करते हैं।
हम कर्मियों की भुखमरी को नहीं हरा सकते - केवल राज्य के लिए। इसलिए, हम दूसरी ओर समस्या का अनुकूलन और समाधान करते हैं - हम प्रशिक्षित करते हैं। आइए इस बारे में सोचें कि आईटी उद्योग में लोगों को कैसे शिक्षित किया जाए।
आईटी उद्योग में सीखने के तरीके
1980 में, संयुक्त राज्य अमेरिका में राष्ट्रीय प्रशिक्षण प्रयोगशालाओं ने विभिन्न प्रशिक्षण विधियों की प्रभावशीलता पर शोध किया। यह पता चला है कि
व्याख्यान और पढ़ने की पुस्तकों की दक्षता बहुत कम है - केवल 5-10% । अगला वीडियो व्याख्यान देख रहा है और ऑडियो सुन रहा है। 90% की अधिकतम दक्षता अन्य लोगों के प्रशिक्षण द्वारा है - सलाह और व्यवहार में प्राप्त ज्ञान के तत्काल आवेदन।

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

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

"निराशा के पठार" के साथ सादृश्य द्वारा मैंने "निराशा की दीवार" की अवधारणा को पेश किया। यह 15 मोटी किताबों की एक दीवार है, जो hh.ru के साथ सैकड़ों हजारों शुरुआती डेवलपर्स को वरिष्ठ और मध्य की प्रतिष्ठित 5 हजार सक्रिय रिक्तियों में जाने की अनुमति नहीं देती है।

यह पता चला है कि एक डेवलपर बनने के लिए, एक शुरुआती स्व-शिक्षा पर समय बिताता है, न कि किसी परिवार या शौक पर। ऐसा लगता है कि यह तरीका भी बहुत अच्छा नहीं है।
मेंटरिंग और कोचिंग
यह सबसे प्रभावी तरीका है, सीखने के पिरामिड के अनुसार -
90% दक्षता । लेकिन उसके पास कमियां भी हैं जो इस पद्धति को "जादुई गोली" कहने की अनुमति नहीं देते हैं।
Mentoring हमेशा
1: 1 का अनुपात होता है , अर्थात एक संरक्षक और एक संरक्षक
- शिक्षार्थी । मेरे अभ्यास में, मैंने ऐसे मामलों को नहीं देखा है जहां एक संरक्षक 10 लोगों को प्रशिक्षित कर सकता है। मेंटरिंग बहुत
खराब तरीके से किया जाता है और मुख्य कार्य से
वरिष्ठों को
विचलित करता है। मैं व्यक्तिगत रूप से कह सकता हूं - मेरे पास 2 मेंटि थे, अधिकतम। और एक ही समय में, मेरे काम करने के समय का आधा, और कभी-कभी अधिक, मेंटीनेंस पर खर्च किया गया था, और उत्पादन कार्यों को हल करने पर नहीं जिसके लिए मुझे पैसे दिए गए थे। इसलिए, 3-4 लोग या उससे अधिक, यह सलाह देना असंभव है, अगर हम उच्च-गुणवत्ता वाले सलाह के बारे में बात करते हैं।
दीर्घकालिक अध्ययन - 1-2 वर्ष। मेरे अनुभव में, एक प्रोग्रामर एक कंपनी में औसतन 2 साल से काम कर रहा है। यह एक दुखद तस्वीर निकलती है: आप किसी व्यक्ति का उल्लेख करते हैं, उसके बारे में ज्ञान प्राप्त करते हैं, और फिर कोई कहता है - या तो आप या वह, और सभी परामर्श कहीं नहीं जाते हैं।
मेंटरिंग प्रभावी है, लेकिन कमियों के कारण, मैंने सोचा - क्यों न कोई ऐसा तरीका खोजा जाए जो सलाह देने के रूप में प्रभावी हो, लेकिन बिना मीनू के: मज़ेदार, दिलचस्प और स्केलेबल हो। सोचकर, मुझे खेलों का विचार आया - यह मजेदार है, मुझे लोग पसंद करते हैं और सलाह देने की समस्याओं को हल करते हैं।
खेल!
हम कौन से खेल जानते हैं? चेकर्स, शतरंज, स्पूल और डोमिनोज़ एक बौद्धिक व्यवसाय हैं, जो सादगी के बावजूद हैं।
कार्ड भी एक बौद्धिक खेल है। क्लासिक किसे पसंद नहीं है, "मैजिक: द गैदरिंग" है। कई आईटी लोग इस खेल से प्यार करते हैं, जिनमें मैं भी शामिल हूं। कई आईटी कंपनियां उसके लिए समर्पित पूरे टूर्नामेंट की मेजबानी करती हैं।

ये सभी खेल मनोरंजन के लिए खेल हैं, न कि प्रोग्रामर के लिए, और मैंने सोचा - क्या प्रोग्रामर के लिए कोई खेल हैं? और मैंने पाया, उदाहरण के लिए, ऐसा खेल।

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

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

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

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

अगला तत्व
मौजूदा लाइनों का वैंड है । ये तार से बने रंगीन फ्रेम हैं।

प्रत्येक खिलाड़ी बदले में अपने स्ट्रीम स्टाफ को स्रोत कोड के माध्यम से स्थानांतरित करता है, इस प्रकार वर्तमान प्रगति बार प्रदर्शित करता है।

खेल के दो खेल मैदान हैं। पहली
एक राज्य मशीन है - शिलालेखों के साथ वर्ग और तीर।

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

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

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

खेल का अगला तत्व
मॉनिटर कार्ड है ।

ये कार्ड पहले आम स्टैक में पड़े होते हैं, और फिर खिलाड़ी उन्हें अपने हाथों में ले लेते हैं। प्रत्येक मॉनिटर एक जावा ऑब्जेक्ट से जुड़ा होता है, जिसमें से दो होते हैं: "एक" और "दो"।
अंतिम तत्व
प्रवाह के
घंटे हैं ।

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

यूजीन और स्वेतलाना अभी भी सो रहे हैं - उनके धागे नहीं बनाए गए हैं, और मिखाइल अपने स्ट्रीम स्टाफ को कोड की अगली पंक्ति में ले जाता है, जहां यह कहता है <code> थ्रेड t1 = नया थ्रेड () </ code> - इसका मतलब है कि स्ट्रीम यूजीन "t1" बनाया जाएगा ।

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

यह एक उदाहरण है कि टीम खेल के दौरान ज्ञान कैसे स्थानांतरित करती है। खेल चलता है ...
एक निश्चित कदम पर, माइकल पहले से ही यूजीन के लिए एक टिप्पणी करता है:
- यूजीन, आपने सिंक्रो ब्लॉक में प्रवेश किया, लेकिन कुछ करना भूल गए ...
- वास्तव में, मैं इस वस्तु की निगरानी करना भूल गया!
यूजीन "
एक" ऑब्जेक्ट का मॉनिटर लेता है। यह पता चला है कि स्ट्रीम "t1" यूजीन इस मॉनिटर का मालिक है।

फिर खेल आता है: कई चालें, चूक, घड़ी के साथ काम करना।
प्रस्तुति में वीडियो या
स्लाइड्स पर अधिक पढ़ें।
खेल के अंत में, यूजीन के पास एक मॉनिटर है, और स्वेतलाना के पास एक और है, और उनमें से प्रत्येक का प्रवाह
मॉनिटर की उम्मीद से अवरुद्ध है । नतीजतन, धारा "t1" और धारा "t2" दोनों "अवरुद्ध" अवस्था में हैं, अर्थात हम झुंड का निरीक्षण करते हैं।
खेल सत्र के दौरान, प्रत्येक खिलाड़ी व्यक्तिगत रूप से जांच करेगा, महसूस करेगा कि गतिरोध क्या है, यह कैसे उत्पन्न होता है और यह क्या है।
निष्कर्ष
खेल सत्र छोटा है । 20 , , ,
. , —
1:n .
— . , ,
. Deadlock — — , «» — heisenbug, .
— . , , , . .
. , . : Delphi, — C++, — Haskell.
, Java- 20 . 5 ,
.
, — , , , . .
deadlock, :
- Race conditions — , .
- wait/notify .
- join/isAlive .
?
, ,
. , .
JPA- JEE/Spring. , JPA-.
Google, « JPA-».

, , — .

, «» .
- JEE.
- SQL.
- : , , HashMap.
- java.util.concurrent.
, , .
, ,
- . , - , . - , .
, . ,
. , : , , , . - , , .
— «». , . , .
.
Linkedin- GitHub.
.
, , . 26 KnowledgeConf . , . , .