यह सम्मेलन इस तथ्य से आकर्षित नहीं हुआ कि आप कॉरपोरेट खर्च पर यूरोप को प्राप्त कर सकते हैं, लेकिन आमंत्रित लेखकों के चयन से, जिनके बीच डैन नॉर्थ, माइकल फेयर्स, ब्रूस एकेल, एरिक इवांस, ग्रेग यंग थे। यह अजीब बात है कि हब पर उसका कोई उल्लेख नहीं था इस तथ्य के बावजूद कि सम्मेलन को डेवलपर्स के सम्मेलन के रूप में घोषित किया गया था, यह तकनीक के बारे में बिल्कुल भी नहीं था। विशिष्ट प्रौद्योगिकियों के उपयोग के बारे में कई रिपोर्टें थीं, लेकिन अधिकांश रिपोर्ट सामान्य रूप से विकास के बारे में थीं।
सम्मेलन का आदर्श वाक्य "एडाप्ट!" है। यह विचार इतनी सारी रिपोर्टों में सुना गया था। शायद आयोजकों ने प्रतिभागियों के पैकेज में नोटबुक नहीं दी - वे चाहते थे कि हम अनुकूलन करें? =) उसी समय, उन्होंने पेन दिया और आसपास के स्टोर में नोटबुक ढूंढनी पड़ी।
Cutscene के तहत, वर्णन और वीडियो रिपोर्ट जो मुझे सबसे दिलचस्प लगी।
वीडियो को सीधे डालें लेख में काम नहीं किया, इसलिए वीडियो को लिंक द्वारा दर्शाया गया है। अगर कोई भी खुद वीडियो डालने में मदद करता है, तो मैं आभारी रहूंगा।
अपने लिए, मैंने कुछ सबसे उपयोगी और दिलचस्प रिपोर्टों पर प्रकाश डाला, और बाकी को कालानुक्रमिक क्रम में व्यवस्थित किया।
सबसे उपयोगी और / या दिलचस्प रिपोर्ट (देखने के लिए अत्यधिक अनुशंसा)
कैसे मैंने चिंता करना बंद कर दिया और लचीलेपन को प्यार करना सीखा (गोजको एडज़िक)
रिपोर्ट वीडियो
एक बहुत ही जानकारीपूर्ण पहली रिपोर्ट जिसने पूरे सम्मेलन के लिए टोन सेट किया। मुख्य विचार: लचीले दृष्टिकोण केवल वहां लागू होते हैं जहां बदलती बाहरी दुनिया। यदि बाहर की दुनिया प्रणाली के संबंध में स्थिर है, तो जलप्रपात में विकृति उत्पन्न होती है , जो अतिरिक्त लाभ के साथ ओवरहेड लागत को बढ़ाती है । यदि बाहर की दुनिया अच्छी तरह से ज्ञात नहीं है या तेजी से बदल रही है, तो आपको अनुकूलन करने में सक्षम होने की आवश्यकता है। उदाहरण के रूप में, लेखक सुपरबाइक ट्रैक पर अपनी शुरुआत के दौरान डुकाटी टीम का अनुभव देता है। एक गंभीर स्थिति में, सब कुछ लचीला है, क्योंकि आपको जल्दी से अनुकूलित करने की आवश्यकता है, अन्यथा आप जीवित नहीं रहेंगे।
स्थिति के अनुकूल होने के तरीके के रूप में, लेखक उपयोगकर्ता कहानियां प्रदान करता है।
मुख्य विचार: उपयोगकर्ता कहानियों से आपको अपने इच्छित उद्देश्य के लिए रोडमैप की रचना और उपयोग करने की आवश्यकता है: " रोड मैप " के रूप में। लेखक का कहना है कि उसने जो रोडमैप देखा था, वह वास्तव में एक रोड मैप था, न कि सुरंग । एक सुरंग में केवल एक ही दिशा में चलना शामिल है, और कई मार्ग विकल्प नहीं हैं। एक उदाहरण के रूप में, लेखक एक कार नेविगेटर का हवाला देता है। यह योजना और जमीन पर उन्मुखीकरण के लिए आदर्श है, क्योंकि यह दो मुख्य सूचना ब्लॉकों को दर्शाता है जो वर्तमान स्थिति का वर्णन करते हैं:
- अगले मोड़ की दूरी;
- अगले मोड़ की दिशा
इसके अलावा, लेखक टिम हार्फोर्ड की पुस्तक एडैप्ट : व्हाई सक्सेस ऑलवेज स्टार्ट्स विद फेल्योर : के सिद्धांतों के बारे में एक उद्धरण के लिंक पर पाल्चिन्स्की के सिद्धांतों पर गया ।
लेखक दिखाता है कि उपयोगकर्ता कहानियों का उपयोग यह विश्लेषण करने के लिए किया जाना चाहिए कि ग्राहक वास्तव में क्या चाहता है, और फिर परियोजना की वर्तमान स्थिति के अनुकूल होने के लिए। सभी कहानियों को महसूस करने की कोशिश करने की आवश्यकता नहीं है, क्योंकि यह या तो आवश्यक नहीं हो सकता है, या बहुत महंगा हो सकता है। इसके बजाय, आपको उपयोगकर्ता कहानियों को विकल्प (रोड मैप) के एक सेट के रूप में विचार करना चाहिए जिसे आप चुन सकते हैं कि परियोजना के आसपास की स्थिति कब बदलती है।
उन्होंने कहा कि वह "आपकी उपयोगकर्ता कहानियों को बेहतर बनाने के लिए 50 त्वरित विचार" पुस्तक तैयार कर रहा था।
वास्तुकला युद्ध की कहानियां (स्टीफन टिलकोव)
रिपोर्ट वीडियो
की श्रेणी से एक रिपोर्ट "यह कैसे होता है कि स्मार्ट लोग बेवकूफ चीजें करते हैं।" उदाहरणों के साथ अपने व्यवहार की तुलना करने की कोशिश करना लायक है। वास्तविक परियोजनाओं के साथ उदाहरण सभी महत्वपूर्ण हैं। अंत में, लेखक से यह सवाल भी पूछा गया कि "क्या आपने सफल परियोजनाओं पर भी काम किया है।" उदाहरण और दिलचस्प बिंदुओं की प्रचुरता के कारण रिपोर्ट बहुत आसान लगती है, जिस पर आप हंस सकते हैं।
लेखक वास्तु विफलताओं का मज़ाक बनाता है - ऐसे निर्णय जो अलग-अलग समय में अलग-अलग परियोजनाओं में किए गए थे, जिसमें स्वयं भी शामिल हैं। वह इस बारे में बात करता है कि इस निर्णय का जन्म कैसे हुआ, यह विचार क्यों अच्छा लगा और क्यों विचार का मूर्त रूप भयानक हो गया। वह जिन प्रणालियों की बात करता है उनमें से अधिकांश का उपयोग वास्तविकता में किया जाता है। लेखक ऐसी समस्याओं से बचने के लिए क्या किया जा सकता है, या इसके विपरीत, के बारे में संक्षिप्त निष्कर्ष देता है। कुछ बुनियादी शोध (मैंने सब कुछ नहीं लिखा है - एक संदर्भ के बिना वे स्पष्ट नहीं होंगे):
- कैश कैश न करें।
- डेटा कोड निर्भरता से मुक्त होना चाहिए।
- पागलपन से लड़ो।
जैकस्टोन्स: मास्टरी की यात्रा (डैन नॉर्थ)
रिपोर्ट वीडियो - दुर्भाग्य से वीडियो लगभग 10 वें मिनट से शुरू होता है। पहले भाग में, दान चर्चा करता है कि विभिन्न क्षेत्रों में पेशेवर कैसे कौशल का अभ्यास करते हैं।
महारत की यात्रा कैसे करें और सामान्य रूप से महारत क्या है, इस बारे में एक रिपोर्ट। कहानी ओरिगेमी "जैकस्टोन" को तह करने पर आधारित है, जिसे लेखक 15 साल तक नहीं जोड़ सका।
मूल परिभाषा: महारत संदर्भ में अवसर है। इस रिपोर्ट के बारे में पूर्ण रूप से बताए बिना कुछ बताना कठिन है। मैं उन सभी को देखने की सलाह देता हूं जो अपने कौशल में सुधार के विषय में रुचि रखते हैं।
डोमेन मॉडल में (रूट एरिक इवांस) - रूट पर कैपिंग अभिस्वीकृत कैप
रिपोर्ट वीडियो
यह रिपोर्ट मेरे लिए सबसे अधिक अपेक्षित थी - मैं इन तीन पत्रों के बारे में पहले डीडीडी से सुनना चाहता था। लेकिन, आश्चर्यजनक रूप से, यह रिपोर्ट सम्मेलन में सबसे अधिक थकाऊ रिपोर्टों में से एक बन गई। यह भी हो सकता है क्योंकि मैं पहले से ही इस बारे में बहुत कुछ जानता हूं और रिपोर्ट से बहुत कम सुना है। इवांस ने बिना किसी अकादमिक लहजे में भावना के बात की। यह सुनना मुश्किल था, लेकिन सार काफी स्पष्ट रूप से व्यक्त किया।
रिपोर्ट का पहला भाग इस बात के विवरण के लिए समर्पित है कि समुच्चय और उनकी जड़ों को सही ढंग से अलग करना कितना महत्वपूर्ण है और यह भविष्य में प्रणाली के प्रदर्शन और उत्तरजीविता को कैसे प्रभावित कर सकता है। कहानी महासागरों में माल ढुलाई कंटेनरों के वितरण और वितरण अनुसूची के समन्वय के उदाहरण पर आधारित थी। उन्होंने दिखाया कि समुच्चय और उनकी जड़ों की पसंद के आधार पर, सिस्टम का व्यवहार बदलता है और प्रत्येक मामले में किस तरह की रेक प्राप्त की जाती है। मुख्य बिंदु: सिस्टम के लिए सही ढंग से प्रश्न तैयार करते हैं और सामान्यीकरण और अपभ्रंश के बीच संतुलन बनाते हैं।
समुच्चय के राज्यों के बीच असंगतता एक सामान्य घटना है और किसी भी जटिल प्रणाली में मौजूद है। इसलिए, यह उन समझौतों (SLAs) द्वारा शासित होना चाहिए जो इस व्यवस्था में कितनी देर तक असंगतता को नियंत्रित कर सकते हैं।
रिपोर्ट के अंत में, मैंने बंधे हुए संदर्भों पर थोड़ा स्पर्श किया। संदर्भों के बीच, एन्विचुअल कंसिस्टेंसी का उपयोग करें।
कालानुक्रमिक क्रम में सिर्फ अच्छी और दिलचस्प रिपोर्ट
प्रतिक्रियाशील जा रहा है: घटना-चालित, स्केलेबल, लचीला और उत्तरदायी सिस्टम (जोनास बोनर)
रिपोर्ट वीडियो
प्रतिक्रियाशील प्रोग्रामिंग और घटना-उन्मुख विकास के सिद्धांतों का एक अच्छा परिचय। लेखक का कहना है कि प्रतिक्रियाशील प्रोग्रामिंग की मुख्य समस्या एक बड़ी प्रविष्टि सीमा है, लेकिन इस सीमा पर काबू पाने के बाद, दृष्टिकोण स्पष्ट और सरल हो जाता है। मुख्य बिंदु:
- हमेशा कमजोर बंधन का उपयोग करें;
- यह डिजाइन करना आवश्यक है ताकि कभी भी ताले न हों;
- शुरू में अतुल्यकालिक बातचीत को डिजाइन करना आवश्यक है;
- अभिनेता केवल संदेश के माध्यम से संवाद करते हैं;
- साझा आर्किटेक्चर का उपयोग करना ;
- स्थान पारदर्शिता;
चपलता और सॉफ्टवेयर वास्तुकला का सार (साइमन ब्राउन)
रिपोर्ट वीडियो
मुफ्त में कुछ नहीं होता। आपको किसी भी वास्तुशिल्प समाधान के लिए भुगतान करना होगा, इसलिए कोई सही अमूर्त वास्तुकला नहीं है। एक वास्तुकला का लचीलापन (एक प्रणाली की तरह) हमेशा सापेक्ष और समय पर निर्भर होता है। इसलिए, आपको हमेशा पता लगाने और अनुकूलित करने की आवश्यकता है।
विभिन्न हितधारकों के विभिन्न हितों के कारण, एक सार्वभौमिक आरेख बनाना असंभव है। आरेखों के एक सेट को विभिन्न पैमानों के नक्शों के एक सेट के रूप में माना जाना चाहिए, जिसमें अमूर्त का एक सेट नोटेशन के सेट से कहीं अधिक महत्वपूर्ण है। यह C4 मॉडल का उपयोग करने का प्रस्ताव है:
- सिस्टम का संदर्भ
- कंटेनर
- अवयव
- कक्षाएं
आपको अवयवों में सोचने, और कक्षाओं में लागू करने की आवश्यकता है। इन दो बिंदुओं के बीच अंतर करना महत्वपूर्ण है। खैर, निष्कर्ष में, रिपोर्ट के लेखक का एक महत्वपूर्ण संदेश: डेवलपर्स को वापस वास्तुकला लौटाएं !
एक अच्छी विकास प्रक्रिया क्या है? (ब्रूस एकेल)
रिपोर्ट वीडियो
सामान्य रूप से विकास प्रक्रिया की गुणवत्ता क्या है, इस पर एक रिपोर्ट। न केवल कोड लेखन, बल्कि पूरी प्रक्रिया। प्रतिवेदन 50 मिनट के खाली समय का होने पर रिपोर्ट देखी जा सकती है। मुख्य बिंदुओं की स्पष्टता के बावजूद, उन्हें हर जगह लागू नहीं किया जाता है, जो खराब परिणामों की ओर जाता है। KO प्रसारण:
- वर्जनिंग के लिए रिपॉजिटरी का उपयोग करना, उन सभी चीजों का परीक्षण करना, जिनका परीक्षण किया जा सकता है, और उन सभी चीजों का स्वचालन जो कि परीक्षण सहित 1 से अधिक बार किया जाता है।
- परियोजना के जीवन भर संचार, ईमानदारी और पारदर्शिता । सबसे पहले, ग्राहक से पहले।
- न्यूनतम मूल्यवान उत्पाद (न्यूनतम मूल्यवान उत्पाद) में रिलीज। लेकिन आपको एक ऐसा उत्पाद तैयार करना होगा जो ग्राहक के लिए मूल्यवान हो, न कि डेवलपर के लिए। इसके आधार पर, विशिष्ट समस्याओं को हल करने में प्राथमिकताओं का निर्माण करना आवश्यक है।
- निरंतर संस्करण अद्यतन के लिए एक तंत्र के रूप में स्वचालित सतत वितरण (सतत वितरण)। यह आपको एमवीपी के पहले संस्करण को जल्द से जल्द जारी करने और सबसे महत्वपूर्ण कार्यों पर और अधिक परिष्कृत करने की अनुमति देता है।
- गलतियाँ अपरिहार्य हैं। उन्हें सीखने और अनुकूलित करने की आवश्यकता है (फिर से, "एडेप्ट!")।
- ब्रेनस्टॉर्मिंग को ब्रेनवॉटरिंग के साथ बदलें। ब्रेनवॉटरिंग के दौरान, प्रतिभागी लेखन में अपनी राय लिखते हैं, और फिर सभी लोग एक साथ मिलकर चर्चा करते हैं। यह ब्रेनस्टॉर्मिंग से बेहतर है, क्योंकि हर कोई बोल सकता है, न केवल सबसे जोर से।
- अधिकांश मामलों में सबसे समझ में आता है और समर्थित समाधान सबसे अच्छा विकल्प है।
- CodeReview करना आवश्यक है।
मैकडॉनल्ड्स, सिक्स सिग्मा और ऑफशोर आउटसोर्सिंग: इनसाइट के अप्रत्याशित स्रोत (चाड फाउलर)
रिपोर्ट वीडियो
डेवलपर बनने वाले एक पूर्व सैक्सोफोनिस्ट की रिपोर्ट। सम्मेलन के दूसरे दिन की परिचयात्मक रिपोर्ट, क्योंकि यह समग्र रूप से विकास की दुनिया के बारे में है। विकास में प्रेरणा और साहस के बारे में, सॉफ्टवेयर की गुणवत्ता के बारे में, डेवलपर्स और ग्राहकों के विचारों और लक्ष्यों में विरोधाभास जो कम-गुणवत्ता वाले समाधानों को जन्म देते हैं।
लेखक सिक्स सिग्मा के बारे में कहानी की प्रतिज्ञा में विकास प्रक्रिया का उल्लेख करता है, कि फ़ंक्शन ग्राहक के लिए महत्वपूर्ण है, और प्रपत्र डेवलपर के लिए महत्वपूर्ण है। हमेशा आंतरिक और बाहरी गुणवत्ता का टकराव होता है। यहां आपको संतुलन बनाने में सक्षम होने की आवश्यकता है, क्योंकि आंतरिक गुणवत्ता निर्धारित करती है, लेकिन हमेशा बाहरी नहीं। और यह "हमेशा नहीं" की पहचान करने में सक्षम होना चाहिए।
सॉफ्टवेयर इंजीनियरिंग में ज़िम्मेदारियों को अधिकतम करना (थियो श्लोसनागल)
रिपोर्ट वीडियो
सॉफ्टवेयर बेकार है। रिपोर्ट का बाकी हिस्सा इस थीसिस का स्पष्टीकरण और कारणों की खोज है कि ऐसा क्यों है। मुख्य कारण:
- उच्च-गुणवत्ता वाले सॉफ़्टवेयर का विकास एक बहुत ही मुश्किल काम है (व्यावहारिक रूप से असंभव)।
- इंजीनियर "परंपराओं" के अधीन हैं। यह यहां प्रथागत है और यह काम करता है, इसलिए इसे स्पर्श न करें।
- डेवलपर्स अकादमिक साहित्य नहीं पढ़ते हैं और मूल बातें नहीं जानते हैं।
- एक कंपनी या एक परियोजना के भीतर की टीमें अपनी सर्वोत्तम प्रथाओं को साझा नहीं करती हैं।
- इंजीनियर पूरी तरह से स्वायत्तता से काम करते हैं (लेकिन छोटी परियोजनाओं में), इसलिए बड़ी परियोजनाओं में समस्याएं पैदा होती हैं।
- स्क्रैच से रिफ्लेक्टर तक लिखना अक्सर आसान होता है, लेकिन ज्यादातर रिफ्लेक्टर को पसंद करते हैं।
पॉलीग्लॉट डेटा (ग्रेग यंग)
रिपोर्ट वीडियो
पारंपरिक सामान्यीकृत डेटाबेस पर इवेंट सोर्सिंग दृष्टिकोण के लाभों पर रिपोर्ट करें। कोई भी DBMS बेकार है (हर डेटाबेस बेकार है!)। लेकिन प्रत्येक अपने स्वयं के अनूठे और अनूठे तरीके से चूसता है। इसलिए, प्रत्येक विशिष्ट कार्य के लिए इस कार्य के लिए उपयुक्त उपकरण का उपयोग करना आवश्यक है। राज्यों के बजाय घटनाओं के प्रवाह को संग्रहीत करना यह अनुमति देता है। मैं विशिष्ट शोध को उजागर करने में सफल नहीं हुआ, इसके लिए सम्मेलन के दूसरे दिन अंतिम रिपोर्ट थी, लेकिन यह रिपोर्ट देखने लायक है।
खैर, रिपोर्ट जो समय के लायक नहीं है
अपने टेस्ट के लिए सही अमूर्त स्तर का पता लगाएं (जेरार्ड मेस्जारोस)
रिपोर्ट वीडियो
मेरे लिए, यह रिपोर्ट कैप्टन के साक्ष्य के खुलासे की श्रेणी से थी: ऑटोटेस्ट्स को सबसे स्वायत्त बनाते हैं। परीक्षण को अमूर्तता के सही स्तर पर कार्यक्षमता के एक कण का परीक्षण करना चाहिए। यदि अमूर्त के गलत स्तर को चुना जाता है, तो यूआई का परीक्षण करना स्वचालन असंभव है, क्योंकि आपको इसकी गुणवत्ता का मूल्यांकन करने के लिए यूआई को देखने की आवश्यकता है।
डेटा-संचालित सॉफ्टवेयर इंजीनियरिंग (जेवगेनी कबानोव)
रिपोर्ट वीडियो
अजीब रिपोर्ट। डेवलपर उत्पादकता रिपोर्ट से सांख्यिकी स्लाइड सेट
चंचल दुनिया में डेटाबेस और योजनाएं (एंड्रयू गॉडविन)
रिपोर्ट वीडियो
मैं रिपोर्ट से कुछ पवित्र ज्ञान की उम्मीद करता हूं कि वास्तव में लचीला डेटाबेस कैसे बनाया जाए, लेकिन सब कुछ ठीक हो गया:
- PostgreSQL का उपयोग करें क्योंकि यह स्कीमा बदलते समय न्यूनतम डाउनटाइम और ताले देता है;
- योजना को केवल लेन-देन के ढांचे के भीतर संशोधित किया जाना चाहिए;
- खैर, वह हाइब्रिड और टाइप किए गए कॉलम में डेटा का हिस्सा (टाइप्ड कॉलम में बाकी हिस्सा, और बूँद खेतों में शेष के रूप में) का उपयोग करके लचीलेपन और गति के बीच अनुकूलन करने का सुझाव देता है।