ओ रेली वेग लंदन सम्मेलन: अवलोकन और स्लाइड

वेग एक सम्मेलन है जो वितरित प्रणालियों के लिए समर्पित है। यह ओ'रेली प्रकाशन हाउस द्वारा आयोजित किया जाता है, और यह वर्ष में तीन बार होता है: कैलिफोर्निया में एक बार, न्यूयॉर्क में एक बार और यूरोप में (और शहर हर साल बदलता है)।

2018 में, सम्मेलन 30 अक्टूबर से 2 नवंबर तक लंदन में था। बुश का मुख्य कार्यालय वहाँ स्थित है, इसलिए मेरे सहयोगियों और मेरे पास वेलोसिटी जाने के दो कारण थे।

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

इस समीक्षा में, मैं उन रिपोर्टों और मास्टर कक्षाओं के बारे में बात करूँगा जो मुझे याद हैं। मैं कुछ रिपोर्ट में अतिरिक्त सामग्रियों के लिंक संलग्न करता हूं। आंशिक रूप से, ये ऐसी सामग्रियां हैं जिन्हें लेखकों ने और आंशिक रूप से आगे के अध्ययन के लिए सामग्री के रूप में संदर्भित किया है, जो मैंने खुद पाया।

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

इस सम्मेलन का सबसे गर्म विषय कुबेरनेट्स है , जिसका उल्लेख लगभग हर दूसरी रिपोर्ट में किया गया है।

सोशल नेटवर्क के साथ काम बहुत अच्छी तरह से बनाया गया है: सम्मेलन के दौरान आधिकारिक ट्विटर अकाउंट में रिपोर्ट के साथ बहुत सारे ऑपरेशनल रीट्वीट थे। यह अन्य कमरों में क्या हो रहा था पर एक त्वरित नज़र की अनुमति दी।

मास्टर कक्षाएं

31 अक्टूबर वह दिन था जब कोई रिपोर्ट नहीं थी, लेकिन प्रत्येक शुद्ध समय के तीन घंटे के छह या आठ मास्टर वर्ग थे, जिनमें से दो को चुना जाना था।

PS मूल में, उन्हें ट्यूटोरियल कहा जाता है, लेकिन मुझे उन्हें "मास्टर क्लास" के रूप में अनुवाद करना सही लगता है।

अराजकता इंजीनियरिंग बूटकैंप

प्रस्तुतकर्ता: एना मदीना , ग्रेमलिन में इंजीनियर | विवरण

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

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

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

दिलचस्प: इस सम्मेलन में, वक्ताओं ने अक्सर "ब्लास्ट त्रिज्या" शब्द का उल्लेख किया, जो मैंने पहले नहीं देखा था। उन्होंने उस सिस्टम के हिस्से को निर्दिष्ट किया है जो एक विशिष्ट समस्या होने पर प्रभावित होता है।

अतिरिक्त सामग्री:

• अराजकता इंजीनियरिंग: इतिहास, सिद्धांत और अभ्यास
• इंजीनियरों के लिए कैओस बंदर गाइड
• सिस्टम में समस्याओं का अनुकरण करने के लिए लिपियों के साथ रिपॉजिटरी (मास्टर क्लास में लिपियों का उपयोग किया गया था और समान मास्टर क्लास से प्रस्तुति के लिंक भी हैं)
• अराजकता इंजीनियरिंग निगरानी और मैट्रिक्स गाइड
• अपनी खुद की अराजकता दिवस की योजना बनाना

विकासवादी अवसंरचना का निर्माण

प्रस्तुतकर्ता: एक कोड के रूप में केफ मॉरिस , इन्फ्रास्ट्रक्चर सलाहकार और इन्फ्रास्ट्रक्चर के लेखक | विवरण

मास्टर वर्ग के मुख्य बिंदुओं को दो चीजों में घटाया जा सकता है:

1. सिस्टम हर समय बदलता है, इसलिए यह सामान्य है कि बुनियादी ढांचे को भी बदलना होगा;
2. एक बार बुनियादी ढांचा बदल रहा है, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह सरल और सुरक्षित है, और यह केवल स्वचालन द्वारा प्राप्त किया जा सकता है।

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

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

रिपोर्ट

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

रंटैस्टिक बैकेंड का विकास

साइमन लैस्सेल्बर्गर (रुंटास्टिक जीएमबीएच) | विवरण और स्लाइड

उन कुछ रिपोर्टों में से एक जिसमें लेखक ने केवल यह नहीं बताया कि कुछ कैसे किया जाए, लेकिन एक विशिष्ट परियोजना का विवरण और उसके साथ क्या हुआ।

शुरुआत में, Runtastic के पास एक सामान्य Percona सर्वर डेटाबेस और कोड के साथ एक मोनोलिथ था जिसमें मोबाइल एप्लिकेशन और एक साइट थी। फिर उन्होंने कैसंड्रा में लिखना शुरू किया (मुझे याद नहीं है कि यह इसमें क्यों था) उस डेटा का वह हिस्सा जिसके लिए भंडारण का मुख्य मूल्य पर्याप्त था। धीरे-धीरे, डेटाबेस में बहुत वृद्धि हुई, और उन्होंने MongoDB को जोड़ा, जिसमें उन्होंने अधिकांश सेवाओं से डेटा लिखना शुरू किया। समय के साथ, उन्होंने एक सामान्य स्तर बनाया जो वेब और मोबाइल एप्लिकेशन (हमारे ऐप की तरह कुछ, जो मुझे समझ में आता है) से अनुरोध करता है।

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

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

एक प्रणाली में मॉड्यूल के डिजाइन के लिए एक दिलचस्प दृष्टिकोण, जिसके बारे में साइमन ने आकस्मिक रूप से उल्लेख किया: हेक्सागोनल वास्तुकला ।

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

एलिस्टेयर कॉकबर्न

अतिरिक्त सामग्री:

• दूसरे सम्मेलन से एक ही रिपोर्ट की प्रस्तुति
• हेक्सागोनल वास्तुकला

कस्टम मेट्रिक्स की निगरानी करना; या, मैं पहले कैसे सीखूं और बाद में प्रश्न पूछूं

मैक्सिमे पेटाज़ोनी (सिग्नलफ़ैक्स) | विवरण और प्रस्तुति

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

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

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

अतिरिक्त सामग्री:

• USE और RED के साथ निगरानी और अवलोकन

कैसे सर्वरहीन आईटी विभाग को बदलता है

पॉल जॉनसन (राउंडअबाउट लैब्स) | विवरण और प्रस्तुति

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

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

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

अतिरिक्त सामग्री:

• सर्वरलेस बेस्ट प्रैक्टिस - बेस्ट प्रैक्टिस पर लेखक का लेख

घबराओ मत! अब कैसे सामना करें कि आप उत्पादन के लिए जिम्मेदार हैं

Euan Finlay (फाइनेंशियल टाइम्स) | विवरण और प्रस्तुति

उत्पादन की घटनाओं से निपटने के बारे में एक रिपोर्ट अगर कुछ गलत हो जाता है। मुख्य बिंदुओं को समय से भागों में विभाजित किया गया था।

घटना से पहले:

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

घटना के दौरान:

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

घटना के बाद:

• यह पता लगाएँ कि समस्या क्यों उत्पन्न हुई और इसने आपको क्या सिखाया;
• इस बारे में एक रिपोर्ट लिखना महत्वपूर्ण है ("घटना की रिपोर्ट");
• क्या सुधार किया जा सकता है और विशिष्ट कार्यों की योजना बनाएं।

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

जीवन की वेब (मुख्य) से सीखना

क्लेयर जानिस्क (BiomimicrySA) | विवरण

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

भाषण के एक टुकड़े के साथ एक वीडियो सम्मेलन वेबसाइट पर देखा जा सकता है।

गलत सूचना आयु (मुख्य)

जेन एडम्स (दो सिग्मा इन्वेस्टमेंट) | विवरण

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

कुबेरनेट्स की स्वतंत्रता (मुख्य)

क्रिस नोवा | विवरण

वहाँ से मुझे दो विचार याद आए:

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

रिपोर्ट काफी दार्शनिक थी, इसलिए, एक तरफ, मैं इससे बहुत बाहर नहीं निकल सका, लेकिन दूसरी तरफ, जो मैंने बाहर किया वह केवल कुबेरनेट्स के लिए लागू नहीं था।

जब हम ऑफ़लाइन-प्रथम जाते हैं तो क्या परिवर्तन होते हैं? (मुख्य)

मार्टिन क्लेप्पमन (कैम्ब्रिज विश्वविद्यालय), डिजाइनिंग डेटा-गहन अनुप्रयोगों के लेखक | विवरण

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

अतिरिक्त सामग्री:

• प्रदर्शन का टुकड़ा
• स्वचालित लाइब्रेरी
• CRDT
• संचालन परिवर्तन

एक प्रोग्रामर का गाइड सुरक्षित कनेक्शन

वक्ता: लिज़ चावल | विवरण और स्लाइड

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

सबसे उपयोगी: मुख्य गलतियों के साथ एक स्लाइड ( दूसरे सम्मेलन में लिज़ की रिपोर्ट से उर्फ ):

अतिरिक्त सामग्री:

• एक समान रिपोर्ट से कोड और स्लाइड

सब कुछ आप monorepos के बारे में जानना चाहते थे, लेकिन पूछने से डरते थे

साइमन स्टीवर्ट (सेलेनियम प्रोजेक्ट) | विवरण

रिपोर्ट की मुख्य थीसिस है कि मोनोरपो में कोड में निर्भरता को प्रबंधित करना बहुत आसान है, और यह व्यक्तिगत रिपॉजिटरी के सभी लाभों को शामिल करता है। उन्होंने इस तथ्य की अपील की कि Google और Microsoft एक रिपॉजिटरी (86 Tb और 300 Gb आकार में, क्रमशः) में डेटा स्टोर करते हैं, और फेसबुक रिपॉजिटरी (54 Gb फाइलें) "शेल मर्क्यूरियल" का उपयोग करता है।

"कर्मचारी के मुकाबले कंपनी में अधिक रिपॉजिटरी कौन है?" सवाल के बाद कमरा "विस्फोट" हुआ।

तर्क "धीरे-धीरे काम करने के लिए एक बड़े भंडार के साथ" इस प्रकार टूट गया:

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

अतिरिक्त सामग्री:

• चौकीदार पुस्तकालय
• फेसबुक पर मर्क्यूरियल को स्केल करना

एक वितरित वास्तविक समय धारा प्रसंस्करण प्रणाली का निर्माण

एमी बॉयल (नई अवशेष) | विवरण और प्रस्तुति

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

रिपोर्ट बहुत सारी सामग्री थी, मैं इसे फिर से लिखने की कोशिश नहीं करूंगा, लेकिन केवल प्रस्तुति को देखने की सलाह दूंगा (यह सम्मेलन वेबसाइट पर पहले से ही मौजूद है)।

टीवी के लिए वास्तुकला

डेविड बकहर्स्ट (बीबीसी), रॉस विल्सन (बीबीसी) | विवरण

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

मेरे लिए मुख्य निष्कर्ष यह है कि टीवी लोगों की तुलना में, मोबाइल एप्लिकेशन को पुराने ग्राहकों के साथ कोई समस्या नहीं है।