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

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

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

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


नाइके एयर मैक्स 97, एम्पायर स्टेट बिल्डिंग (न्यूयॉर्क)

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



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

समस्याओं

संक्षेप में, हमारे यूआई विकास की प्रक्रिया स्पष्ट रूप से संरचित नहीं थी।

व्यवहार में, इसका मतलब था कि किसी भी नए कार्य का शुभारंभ सबसे अप्रत्याशित परिणाम हो सकता है। उदाहरण के लिए:

• डिजाइनरों के साथ बातचीत करने के लिए कोई स्पष्ट नियम नहीं थे: सहकर्मियों को हमेशा हमारे काम के बारे में पता नहीं था, और इस तथ्य के कारण कि उन्होंने नए घटक बनाए, वास्तव में, मौजूदा लोगों के समान, लेकिन अलग दिख रहे थे;
  
• हमारे पास नए UI घटकों को लागू करने के लिए एक सार्वभौमिक मॉडल नहीं था: प्रत्येक डेवलपर ने अपने तरीके से घटकों को लागू किया, जो परियोजना के समर्थन को जटिल करता है;
  
• कोड डुप्लीकेशन भी कोडबेस को बेहतर नहीं बनाता था।
  

परिणामस्वरूप:

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

बेशक, ये सभी समस्याएं जादू से गायब नहीं हो सकती थीं। चीजों के क्रम को बदलने के लिए, विभिन्न टीमों के बीच एक समझौते पर आना और प्रक्रिया में सभी प्रतिभागियों को यह समझाने के लिए आवश्यक था कि परिवर्तन आवश्यक हैं।

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

यूआई फ्रेमवर्क

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

हमने कुछ जोड़े चौखटे बनाने का फैसला किया, जिन्हें ब्यूटुइकिट कहा जाता है। हमारे विचार के अनुसार, उनमें सभी आवश्यक UI घटक (जैसे Apple का UIKit) होना चाहिए। फ्रेमवर्क कक्षाओं में से प्रत्येक एक आवेदन के यूआई तत्व से मेल खाती है (हमारी कंपनी अन्य अनुप्रयोगों को विकसित कर रही है, लेकिन इस UIKit में हमने केवल घटकों का इस्तेमाल किया है)।

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



लेकिन क्या होगा अगर एक या दूसरे यूआई घटक का उपयोग विभिन्न अनुप्रयोगों में किया जा सकता है?

इस मामले के लिए, हमने एक और फ्रेमवर्क बनाया - Platform_UIKit। इसमें अन्य अनुप्रयोगों के लिए उपयुक्त सभी घटक शामिल हैं।

क्या आपने एक ही बार में सभी UI को नए ढांचे में स्थानांतरित कर दिया था?

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

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

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



हम Platform_UIKit से डेटा को BetUIKit में आयात कर सकते हैं, लेकिन इसके विपरीत नहीं: Platform_UIKit को स्वतंत्र रहना चाहिए।



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

UIKit का उपयोग करने के नियम:

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

बनाने के लिए गैलरी गैलरी

ब्यूट्यूइकिट ने हमें समस्याओं का एक महत्वपूर्ण हिस्सा हल करने में मदद की, लेकिन हमने समझा कि पूर्णता की कोई सीमा नहीं थी।

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

LoginUIKit को लॉन्च करके, हमने आंतरिक उपयोग के लिए एक सरल अलग एप्लिकेशन-निर्देशिका बनाने का निर्णय लिया। तो वहाँ थी बेसिक गैलरी।

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

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

• घटक खोज;
  
• नाम से घटकों को क्रमबद्ध करना;
  
• पसंदीदा में आइटम जोड़ें
  
• शैलियों के बीच स्विच करना - इसलिए आप देख सकते हैं कि किसी विशेष डिज़ाइन में घटक कैसा दिखेगा;
  
• फ्लेक्स ;
  
• एफपीएस काउंटर।

प्रत्येक घटक उपयोगकर्ता के कार्यों और आवेदन के आंतरिक तर्क के आधार पर विभिन्न राज्यों में हो सकता है। उदाहरण के लिए, UIButton के पांच राज्य हैं: 1) डिफ़ॉल्ट रूप से, 2) हाइलाइट किया गया, 3) होवर पर, 4) क्लिक पर, और 5) लॉक किया गया।

रुचि रखते हैं? और पढ़ें यहाँ

इसके अलावा, हम एक ही स्थान पर सभी संभावित संयोजनों को प्रस्तुत करने में सक्षम होना चाहते थे - हम प्रत्येक घटक की प्रत्येक स्क्रीन के साथ ऐसा करते हैं। बेशक, हमारे बटन के राज्य UIKit Apple बटन के राज्यों से भिन्न हो सकते हैं।



सगाई गैलरी के मुख्य लाभ:

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

परीक्षण के बारे में थोड़ा सा

नए टूल ने लेख की शुरुआत में वर्णित अधिकांश समस्याओं को हल करने में मदद की, लेकिन कुछ प्रश्न अनुत्तरित रहे।



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

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

हमने सबसे लोकप्रिय ओपन-सोर्स उपयोगिताओं में से एक IOSSnapshotTestCase (जिसे फेसबुक द्वारा बनाया गया था, इसे पहले FBSnapshotTestCase के रूप में जाना जाता है) को पेश करके स्नैपशॉट परीक्षण करने का निर्णय लिया।

आप स्क्रीनशॉट का उपयोग करके परीक्षण करने के बारे में और इस लिंक के किसी एक का उपयोग करके इस रूपरेखा के बारे में अधिक जान सकते हैं:

• https://github.com/uber/ios-snapshot-test-case/
  
• https://www.objc.io/issues/15-testing/snapshot-testing/
  
• https://ashfurrow.com/blog/snapshot-testing-on-ios/
  

आवेदन घटकों को अद्यतन करते समय प्रतिगमन से बचने के लिए हमें पहले से ही यूट्यूइट में घटकों का परीक्षण करने का एक तरीका चाहिए था। हम नए स्नैपशॉट परीक्षणों को अधिकतम करने की प्रक्रिया को स्वचालित करना चाहते थे।

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

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

स्नैपशॉट के साथ परीक्षण के बारे में सबसे सामान्य प्रश्नों के उत्तर यहां दिए गए हैं।

स्नैपशॉट कहाँ संग्रहीत किए जाते हैं?

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

क्या आप सभी संभावित वातावरण में सभी संभावित अनुमतियों का परीक्षण कर रहे हैं?

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

क्या स्नैपशॉट परीक्षण पूरे इंटरफ़ेस को कवर कर सकते हैं?

मुझे नहीं लगता। हम एट द डिग्रेट आवेदन के विभिन्न स्तरों के लिए विभिन्न परीक्षण करते हैं। उदाहरण के लिए, कार्यात्मक (कैलाश और KIF फ्रेमवर्क का उपयोग करके) और एकीकरण।

निष्कर्ष

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

हमारे काम के दौरान हमने कुछ सबक यहां दिए हैं:

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

अगला - ब्रह्मांड

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



क्रिस्टियानो रैस्टेली ने कुछ आकर्षक लेख लिखे हैं कि कैसे कॉस्मॉस प्रणाली के बारे में आया। इसे याद मत करो!

धन्यवाद

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

हमारे अद्भुत डिजाइनरों के लिए धन्यवाद, जो डिजाइन प्रक्रिया में सुधार के लिए हर संभव प्रयास करने के लिए हमेशा तैयार रहते हैं।

अलेक्जेंडर ज़मीन के लिए विशेष धन्यवाद: कई प्रस्तावित सुधारों के लिए, अनगिनत ग्लाइडर्स का दौरा करना, साथ ही इस साहसिक कार्य में मुझे प्रदान किए गए समर्थन के लिए।

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