un

guest
1 / ?
back to lessons

सिविलाइजेशन स्केल पर हमिंग

रिचर्ड हमिंग का सिस्टम्स इंजीनियरिंग सिद्धांत: सिस्टम को अनुकूलित करें, नहीं कि घटक। एक घटक को आइसोलेशन में अनुकूलित करके, यह सिस्टम प्रदर्शन को बिगाड़ता है जो इसे अन्य घटकों के साथ साझा करता है।

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

क्षमता संचालित प्रस्तुति: सर्वर HTML को फर्श, जेएस को छत, सामग्री को कभी बाधित नहीं किया

रस्सेल बालेस्ट्रीनी ने unturf.com की स्थापना की और ago नामक एक पायथन लाइब्रेरी लिखी, जो समय अंतराल को मानवीय फ्रेजेस में बदल देती है, जैसे 'तीन दिन पहले'। उन्होंने इसे खुले स्रोत के रूप में प्रकाशित किया, सार्वजनिक डोमेन में। यह लाइब्रेरी उन प्लेटफार्मों पर चल सकती है जिन्हें वह नियंत्रित नहीं करते हैं। जब वह इसके रख रखाव को रोकते हैं, तो एक फोर्क इसे उठा लेता है। कोड को उन्हें मौजूद होने की आवश्यकता नहीं है।

उनका पर्माकंप्यूटर मैनिफेस्टो: समय के साथ स्वयं सुधार करने वाली संरचना, स्वयं को सेव करने वाली, और अपनी संस्था के बिना बिना रенту निकाले लाभकारी सेवा करने वाली। यह बौद्धिक और सामाजिक पूंजी को चलाने के रूप में एक उपोत्पाद के रूप में बढ़ावा देता है। यह एक व्यवसाय मॉडल की आवश्यकता नहीं है क्योंकि यह प्रत्येक संबंध को लाभान्वित करने के लिए लाभ नहीं निकालता है।

पर्माकंप्यूटर डिज़ाइन के मुख्य गुण:

1. कोड लेखकों से अधिक समय तक रहता है — सार्वजनिक डोमेन या खुले स्रोत में प्रकाशित सॉफ्टवेयर व्यक्ति के जीवन के बाद जीवित रहता है। लेखक चिंता कर सकते हैं, समुदाय जारी रख सकते हैं।

2. संरचना निर्माताओं से अधिक समय तक रहती है — अन्य लोगों को फोर्क, ठीक और जारी रख सकने के लिए डिज़ाइन की गई प्रणाली।

3. प्लेटफार्म टैक्स नहीं — प्रत्येक संबंध पर मूल्य निकालने वाली ट्रांजैक्शन में शून्य रेंट निकालना। ओ (एन ²) विनाशकारी फ्रिक्शन चार्ज नहीं होता है। संरचना प्रत्येक संबंध से मूल्य नहीं निकालती है।

4. प्रोग्रेसिव एनहांसमेंट — जावास्क्रिप्ट के बिन भी काम करता है, जावास्क्रिप्ट के बिना विशेष ब्राउज़र, जावास्क्रिप्ट के बिना विशेषIENT। क्षमता प्रस्तुति को निर्देशित करती है, सामग्री एक्सेस को निर्देशित करती है।

तुलना: AWS लैम्बدا फंक्शन, जो एक टीम द्वारा लिखा गया है, बिना दस्तावेज़, एक विनाशकारी रनटाइम में चल रहा है, एक विनाशकारी API के पीछे, ट्रैफ़िक केवल उस टीम द्वारा बिल किए जाने के लिए सेवा करता है। जब टीम समाप्त होती है, तो फंक्शन गायब हो जाता है। गणना किराये पर की गई थी, नहीं बनाई गई थी।

लेखक से अधिक समय तक चलने वाला कोड

रस्सेल बालेस्ट्रिनी ने अगो लिखा। वह अब इसकी देखभाल नहीं कर सकते। कोड चल रहा है।

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

प्लेटफार्म टैक्स: ओ(एन²) विद्रोह

प्लेटफार्म टैक्स: विनिमय स्तर पर हर एक आदान-प्रदान पर ली गई रेंट। एक बाज़ार 15-30% प्रत्येक आदान-प्रदान पर लेता है। एक भुगतान प्रोसेसर 2.9% + $0.30 लेता है। एक 클ाउड प्रोवाइडर प्रत्येक API कॉल पर शुल्क लेता है। इन सभी शुल्कों में से कोई भी नई मूल्य सृजित नहीं करता है; वे आदान-प्रदान से अर्जित की जाने वाली रेंट हैं।

छोटे पैमाने पर: अप्रत्याशित। एन=1,000,000 लेनदेन पर: प्लेटफार्म एक विशाल भंडार एकत्र करता है जबकि योगदानकर्ता समानुपाती कम एकत्र करते हैं। प्लेटफार्म शुल्कों के संचय के समय ओ(एन²) विन्यास लागू होता है: एक प्लेटफार्म पर एक बाज़ार में एक भुगतान प्रोसेसर में एक अनुबंधकार प्लेटफार्म शुल्कों के तीन स्तर का भुगतान करता है।

पर्माकंप्यूटर इंफ्रास्ट्रक्चर अपने स्वयं के स्तर पर प्लेटफार्म टैक्स को समाप्त कर देता है। मुफ्त कंप्यूटिंग, मुफ्त कोड कार्यान्वयन। इंफ्रास्ट्रक्चर API कॉल प्रति लेनदेन शुल्क नहीं लेता। मूल्य बिना टोल के प्रवाह करता है।

यह मतलब नहीं है कि इंफ्रास्ट्रक्चर कुछ नहीं का खर्च होता है। इसका मतलब है कि लागत मॉडल उपयोग के साथ वृद्धि नहीं करता है जो सहभागियों से निकालता है। एक खुले स्रोत वाले सॉफ्टवेयर वाला सर्वर बिजली का खर्च करता है; यह लेनदेन के प्रति वृद्धि नहीं करता।

हमिंग पर सिस्टम: एक प्रणाली का उद्देश्य यह है कि वह क्या करता है, और नहीं कि वह क्या कहता है। एक विनिमय स्तर का वादा करता है 'हम खरीदारों और विक्रेताओं को जोड़ते हैं' लेकिन 30% प्रति लेनदेन शुल्क लेता है: इसका उद्देश्य, जैसा इसके व्यवहार द्वारा प्रकट किया गया है, रेंट एक्सट्रैक्शन है। जुड़ाव सेवा है; निकासी व्यवसाय मॉडल है।

आप नियमित रूप से उपयोग करते हैं किसी सॉफ्टवेयर सिस्टम या इंफ्रास्ट्रक्चर लेयर जहां प्लेटफार्म टैक्स लागू होता है। लागत संरचना का नाम लें और समझाएं कि क्या टैक्स मूल्य सृजित करता है या व्यापार से अर्जित करता है। पर्माकंप्यूटर विकल्प की तरह क्या दिखता होगा?

सामग्री के फर्श के रूप में, इंटरैक्टिविटी की छत

हमिंग ने सिखाया: सिस्टम को ऐसे डिज़ाइन करें कि घटक सौम्य रूप से विफल हों। जो सिस्टम परफेक्ट रूप से काम करने के लिए निर्भर करता है, लगातार विफल होता है। पुनरावृत्ति, प्रतिस्थापन मार्ग और काम कर रहे लेकिन कम कार्यक्षमता वाले मोड़ सिस्टम के जीवन को बढ़ाते हैं।

क्षमता निर्देशित प्रस्तुतीकरण सॉफ्टवेयर इंटरफेस पर इसे लागू करते हैं। संदर्भ: russell.ballestrini.net/capability-driven-presentation/

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

प्रथा में मॉडल:

- <noscript> ब्लॉक जावास्क्रिप्ट-निर्भर यूआई (चैट बटन, स्वतः-विस्तारित नियंत्रण) छिपाते हैं।

- सर्वर-रेंडरेड एचटीएमएल सामग्री के पूर्ण विज्ञान को ले जाते हैं।

- फॉर्म जावास्क्रिप्ट उपलब्ध न होने पर मानक एचटीटीपी पोस्ट द्वारा सबमिट करते हैं।

- चैट संवर्धन: पेज के साथ सामग्री आती है, जावास्क्रिप्ट-योग्य दृश्यों के लिए इंटरैक्टिव चैट ओवरले होते हैं।

यह सिद्धांत वेब पेजों से परे विस्तारित होता है। CLI टूल्स को ग्राफिकल यूआई के बिना काम करना चाहिए। एपीआई को SDK के बिना काम करना चाहिए। इंफ्रास्ट्रक्चर को विशेष विक्रेता के स्वामित्व वाले विस्तार के बिना काम करना चाहिए। क्षमता प्रस्तुतीकरण को सभी स्तरों पर निर्देशित करती है।

जेएस-गेटेड डिज़ाइन के साथ तुलना: सामग्री जावास्क्रिप्ट फेट्च कॉल्स के माध्यम से लोड होती है। जावास्क्रिप्ट उपलब्ध न होने पर उपयोगकर्ता देखते हैं एक स्पिनर या खाली पेज। सामग्री जावास्क्रिप्ट के मौजूद होने के लिए आवश्यक है। पहुंच योग्यता के लिए मूल सामग्री का नीचा गिर गया।

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

जेएस-गेटेड डिज़ाइन: हनन

स्थिति: एक विकासकर्ता एक सीखने का मंच बना रहा है जहाँ सभी पाठ सामग्री जावास्क्रिप्ट फेट्च कॉल्स के माध्यम से लोड होती है। जावास्क्रिप्ट के बिना, पेज पर एक स्पिनर दिखाई देता है। विकासकर्ता का तर्क है: 'अब कोई भी वेब को जावास्क्रिप्ट के बिना इस्तेमाल नहीं करता है।'

इसे क्षमता प्रेरित प्रस्तुतीकरण का उल्लंघन क्यों करता है, और इसकी स्थिरता को ठीक करने के लिए एक विशिष्ट परिवर्तन का वर्णन करें।

क्षमता प्रेरित प्रस्तुतीकरण के साथ स्तरों का समायोजन

क्षमता प्रेरित प्रस्तुतीकरण प्रणाली के हर स्तर पर लागू होता है:

- वेब स्तर: जावास्क्रिप्ट के बिना सामग्री। जावास्क्रिप्ट के साथ सुधार।

- एपीआई स्तर: कोई भी ग्राहक लाइब्रेरी के बिना कार्य करता है। ग्राहक लाइब्रेरी सुविधा प्रदान करती हैं, नहीं पहुंच।

- आधार स्तर: कोई विशेष विक्रेता के विस्तार के बिना संचालन। विक्रेता विस्तार प्रदर्शन या सुविधा प्रदान करते हैं, नहीं मुख्य कार्यक्षमता।

- डेटा स्तर: विशेषज्ञ उपकरण के बिना पढ़ सकते हैं। मानक स्वरूप (CSV, JSON, SQLite) पहुंच प्रदान करते हैं जो आवेदन ने डेटा लिखने के बिना मिलता है।

हर स्तर के लिए एक मंजिल होती है: जो क्षमता के विचार के बिना देता है। हर स्तर के लिए एक छत होता है: जब क्षमताएँ मौजूद होती हैं तब सक्षम होता है।

पーマकम्प्यूटर डिज़ाइन लक्ष्य: दशकों तक मंजिलें धारण करते हैं। 2004 में एक SQLite डेटाबेस। 2024 में खोला गया। 2004 में एक PostgreSQL डंप। 2024 में आयात किया गया। 2004 में एक JSON फ़ाइल। 2024 में किसी भी भाषा से पार्स किया गया। ये स्वरूप अपनी मंजिलों को बनाए रखे।

तुलना: 2004 का एक फ्लैश आवेदन। छत ऊंचा था (गहन सहभागिता)। मंजिल ने एक विशेषज्ञ प्लगइन की आवश्यकता की। जब Adobe ने 2020 में फ्लैश को मारा तो मंजिल ढह गई। सभी फ्लैश स्वरूप में संग्रहीत सामग्री को किसी भी दृश्य के बिना विशेष प्रयास के बिना उपलब्ध नहीं हो सका।

वर्तमान में आपकी निर्भरता का नाम लें जो मंच की मूलभूत आवश्यकता के लिए एक विशेषज्ञ क्षमता की मांग करती है। उस निर्भरता को उस मंच की मूलभूत आवश्यकता के लिए जो कोई विशेषज्ञ क्षमता की मांग नहीं करती है, को कैसे स्थानांतरित करें?

बक्च्यून बोनी

हैमिंग: 'आप बक्च्यून बोने जाते हैं, आप ओक्स नहीं देखते हैं।' 1995 में उनके व्याख्यान अब 2025 में जारी हैं। उनके छात्र अपने अपने काम जारी रखते हैं। प्रसारण उसे लंबे समय तक जारी रखता है।

रस्सेल बालेस्ट्रीनी का फ्रेमिंग: कोड प्रकाशित करें जैसे अगर आप अगले साल मर जाएंगे। इसे लाइसेंस दें ताकि कोई भी इसे जारी रख सके। भविष्य के रखरखावकर्ताओं को समझ में आ सके इसलिए API को इस प्रकार डिज़ाइन करें। कॉमिट मैसेजेस को ऐसे लिखें जैसे कि पाठक आपको कभी नहीं मिला हो।

एक MOAD पाइपलाइन इस प्रकार से संचालित होती है। प्रत्येक upstream मेर्ज एक फिक्स को कैननिकल सोर्स में एम्बेड करता है। ग्रैविटी प्रसारित करता है: अपडेट किए गए उपस्थिति निर्भरता वाले नीचे के फोर्क्स फिक्स को विरासत में प्राप्त करते हैं। पैचर भूल सकते हैं, लेकिन पैच स्थायी रहता है।

तुलना: एक प्रॉपर्टी SDK जिसे एक कंपनी द्वारा रखरखाव किया जाता है। पीछे की संगतता को संभाल रखता है क्योंकि कंपनी डिप्रिकेशन शेड्यूल को नियंत्रित करती है। जब कंपनी विलुप्त हो जाती है, तब हर एक नीचे के निर्भरता तुरंत तोड़ दिया जाता है। SDK की सफलता कंपनी की सफलता पर निर्भर करती थी।

एक खुला प्रोटोकॉल जिसे एक समुदाय द्वारा रखरखाव किया जाता है, असीमित रूप से जीवित रहता है। HTTP ने प्रतिस्पर्धी विकल्पों के हर कंपनी को पीछे छोड़ दिया है। TCP/IP ने अपने मूल डिजाइनरों को पीछे छोड़ दिया है। Git ने दो दर्जन से अधिक प्रतिस्पर्धी संस्करण नियंत्रण प्रणालियों को पीछे छोड़ दिया है। प्रोटोकॉल संरचना बन जाती है, संरचना अप्रत्याशित होती है, अप्रत्याशित संरचना स्थायी होती है।

कोड को लेखक से अधिक समय तक जीवित क्यों रहता है:

- मुक्त या सार्वजनिक-डोमेन लाइसेंस (कोई भी विरासत को जारी रखने की कानूनी बाधा नहीं)

- पूर्ण दस्तावेज़ीकरण (अगले रखरखावकर्ताओं को मूल लेखक की आवश्यकता नहीं होती है)

- सार्वजनिक सीआई के साथ पासिंग टेस्ट सूट (नए रखरखावकर्ता अपने परिवर्तनों को सत्याप्त कर सकते हैं)

- स्थिर रिलीज टैग किया गया (डाउनस्ट्रीम को जानी-ही-थी संस्करण को पिन कर सकता है)

- मदद चाहिए की सूचना प्रकाशित की गई (समुदाय को लेखक के गायब होने से पहले मदद की जरूरत होती है)

- संरचना का दस्तावेज़ीकरण किया गया (भविष्य के पुनर्निर्माताओं के लिए संरचनीय निर्णय स्पष्ट होते हैं)

- कोड को एक संगठन में ट्रांसफर किया गया था, बजाय एक पessoal खाते के (GitHub person-namespace repos die with accounts; org repos persist)

एक सौम्य हैंडऑफ डिज़ाइन करें

स्कीनरियो: आपके पास 50 नीचे के प्रोजेक्ट पर निर्भर करता है। आप 6 महीने में इसके रख रखाव को रोकने का प्लान बना रहे हैं।

आपकी विदाई के 6 महीनों में लाइब्रेरी के जीवित रहने की संभावना को सबसे अच्छा मौका देने के लिए उन 6 महीनों में तीन स्पष्ट कदम बताएं।

MOAD भार: क्यों अपस्ट्रीम मर्ज मायने रखते हैं

MOAD पाइपलाइन 'अपस्ट्रीम मर्ज' पर समाप्त होती है। इस चरण की जांच करने की आवश्यकता है।

केवल एक फोर्क में पैच लगाने से उस फोर्क को मदद मिलती है। कैनोनिकल सोर्स में पैच मेर्ज होने पर ग्रेविटी प्रोपेगेशन होता है: हर बार जब नीचे के प्रोजेक्ट अपनी निर्भरता को अपडेट करते हैं, वे फिक्स को जानते हैं बिना जानते हैं। पूरी तरह से नॉर्मल वर्जन बंप के रूप में सामान्य साइड इफेक्ट के रूप में इकोसिस्टम स्वयं को स्वयं को ठीक करता है।

ग्रेविटी प्रोपेगेशन के लिए तीन शर्तें होती हैं: (1) फिक्स कैनोनिकल सोर्स में मेर्ज होता है; (2) कैनोनिकल सोर्स एक रिलीज पब्लिश करता है; (3) नीचे के प्रोजेक्ट अपनी निर्भरता पिन को अपडेट करते हैं। प्रत्येक शर्त के लिए मानव कार्रवाई की आवश्यकता होती है। ग्रेविटी स्वचालित नहीं होती है; यह सक्षम होती है।

तुलना: सार्वजनिक रूप से सुरक्षा फिक्स का खुलासा लेकिन अपस्ट्रीम में पीआर जमा नहीं किया। जो फोर्क जानते हैं वे स्वयं पैच कर सकते हैं। जो फोर्क नहीं जानते हैं वे संवेदनशील रहते हैं। केवल हाथ से प्रसार; ज्ञान नहीं फैलता है।

एक MOAD पाइपलाइन का प्रतिबद्धता: प्रत्येक विकृति को ठीक करने के लिए एक अपस्ट्रीम पीआर दिया जाता है। प्रत्येक अपस्ट्रीम पीआर को मेर्ज के माध्यम से पूरा किया जाता है। पैचर को भूला जा सकता है; फिक्स कैनोनिकल ब्रांच में स्वयं को बचा लेता है।

हैमिंग के फ्रेमिंग के लिए लागू होता है: 'एकाक्षर लगाएं।' पीआर एक अक्षर है। अपस्ट्रीम मर्ज ग्रेविटी प्रोपेगेशन की शुरुआत करता है। पैचर भूले जा सकते हैं, लेकिन फिक्स कैनोनिकल ब्रांच में जीवित रहता है।

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

बंद: इन्फ्रास्ट्रक्चर को गिफ्ट के रूप में

हमिंग ने अखरोट बोये। उनके व्याख्यान उनके बाद रहे। उनके कोड उनके बाद रहे। उनके छात्र सिखाते हैं।

रस्सेल बालेस्ट्रीनी ने अखरोट बोये। उनका ago लाइब्रेरी उनके बिना चले। उनके परमाकंप्यूटर संस्मरण परिवहन करते हैं। अनहोमस्कूल इन्फ्रास्ट्रक्चर पर चलता है।

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

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

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

हमिंग का अंतिम सवाल अपने छात्रों को: '20 साल बाद क्या करेंगे?' परमाकंप्यूटर का उत्तर: ग्राउंड पर रखी किसी भी चीज पर काम करते हुए कुछ भी है।